On Sunday, January 15, 2017 12:30:51 AM CET Nico Kadel-Garcia wrote: > On Sat, Jan 14, 2017 at 7:20 PM, Zbigniew Jędrzejewski-Szmek > <zbys...@in.waw.pl> wrote: > > On Sun, Jan 15, 2017 at 01:17:52AM +0100, Reindl Harald wrote: > >> > >> > >> Am 15.01.2017 um 01:13 schrieb Zbigniew Jędrzejewski-Szmek: > >> >== No need for static allocation, afaict > >> >games, man, slocate, squid, named, postgres, mysql, nscd, > >> >rpcuser, rpc, rpm, ntp, mailman, gdm, utempter, apache, smmsp, > >> >tomcat, frontpage, nut, beagleindex, avahi, tcpdmp, privoxy, radvd, > >> >imap, majordomo, polkituser, screen, clamav, saned, mock, ricci, luci > >> > >> this idea is horrible wenn you maintain many machines over many > >> years because the 27/27 for mysqld and 48/48 for apache as example > >> ensures that you can clone/move data between every redhat based > >> distribution of the last 15 years and you wnat to go that capability > >> to be gone > > > > How do you "clone/move data"? Normally tar/rsync/scp will use the user > > or group name, not the number. > > Except when it doesn't. The mysql use on one system may not *exist* at > the time of running rsync or tar, and it certainly does not work wekk > across mounted disk images or NFSv3 and most NFSv4 mounts. > > Let's not change static, stable content that there isn't a compelling > reason to change.
Agreed; at least for the databases, please don't drop postgres and mysql, thank you. The pattern to take into account might be that "external storage is often used to store data" of the service. Without central arbiter (which users are often a bit to setup for e.g. for "only" database server) it is non-trivial to keep UIDs/GIDs synced across VM deployments. Re-installation of VMs (e.g. by ansible) performs poorly (one has to ensure that UID is created before the volume is mounted, and that must be usually done before the package is installed). It is IMO worth keeping those for user's convenience, at least for such basic server tools like databases or webservers. Pavel _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
