On Sat, 28 Jan 2017 11:28:45 +0000 James Le Cuirot <ch...@gentoo.org> wrote:
> On Fri, 27 Jan 2017 18:37:52 -0800 > Patrick McLean <chutz...@gentoo.org> wrote: > > > I don't think we need to have stable UIDs/GIDs in the "normal" case of > > standalone users with a single Gentoo system at home. The people who > > need predictable UIDs/GIDs are the "enterprise" users or the home users > > who use things such as NFS. I work for a company that uses Gentoo, we > > have a bunch of workarounds to make sure that UIDs and GIDs are > > stable. To make something to solve our problem (and I suspect everyone > > else who cares about this), it would be sufficient to have a mechanism > > to override the default random assignment with a fixed UID/GID. > > Possibly some file in /etc/portage or in the profile (or both) that > > allows one to configure what UID/GID a user will get when the user is > > being created. One advantage of this is that user.eclass could be > > modified to support it, so we don't have to wait for a new EAPI before > > taking advantage of it. > > Is this really a problem in enterprise? What are the workarounds you're > using? NFS has long had idmapd, which takes care of this problem. I > still find people shy away from NFSv4 but I've not had any trouble with > it. There's also LDAP, usually coupled with sssd these days, in which > case the users and groups are created just once on a central server. > Samba with Active Directory effectively gives you the same thing and > can also be coupled with sssd. I recently tried mixing Samba, sssd, and > NFS, which was quite fascinating and surprisingly easy thanks to > realmd. This allowed me to use NFS with Kerberos, which is something > you really need in an enterprise environment. > We are using both NFSv3 and NFSv4, the UID stability is also important when you are using full-image deployments, and have local storage on the system, you don't want the new OS to have different UIDs/GIDs than the previous installation. We are using file in /etc/portage/env that define a pre_pkg_setup that creates the users before the standard pkg_setup does, with our stable UID/GID for that system. We have to do this for each package that creates a user that may be used to store stable data.