Re: drop obsolete static uid/gid allocations

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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
> <zbyszek@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux