From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <gentoo-dev+bounces-79378-garchives=archives.gentoo.org@lists.gentoo.org> Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id AD977139085 for <garchives@archives.gentoo.org>; Sat, 28 Jan 2017 22:54:56 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 472B3254027; Sat, 28 Jan 2017 22:54:48 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id EADA5E0D0C for <gentoo-dev@lists.gentoo.org>; Sat, 28 Jan 2017 22:54:47 +0000 (UTC) Received: from moya.linuxfreak.ca (ip72-194-80-211.oc.oc.cox.net [72.194.80.211]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: chutzpah) by smtp.gentoo.org (Postfix) with ESMTPSA id B8CC733FECD; Sat, 28 Jan 2017 22:54:46 +0000 (UTC) Date: Sat, 28 Jan 2017 14:54:38 -0800 From: Patrick McLean <chutzpah@gentoo.org> To: James Le Cuirot <chewi@gentoo.org> Cc: gentoo-dev@lists.gentoo.org Subject: Re: [gentoo-dev] Requirements for UID/GID management Message-ID: <20170128145431.01f36171@moya.linuxfreak.ca> In-Reply-To: <20170128112845.363f7182@symphony.aura-online.co.uk> References: <9558d41c-17c0-4bbd-e2f8-02575c6d0ecd@gentoo.org> <CAGfcS_=biacBM0xsy0GX3_X0mOAd3BdgHDXYorSBkmwsoQ9sgQ@mail.gmail.com> <ee24eb83-4430-40ff-07d0-577bc188457d@gentoo.org> <CAGfcS_=V+xmBU+fFbMQBH39E9-y9CUaZt9Bok80Wg6_jboHcbQ@mail.gmail.com> <20170127183752.500f8910@patrickm> <20170128112845.363f7182@symphony.aura-online.co.uk> X-Mailer: Claws Mail 3.14.1 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Precedence: bulk List-Post: <mailto:gentoo-dev@lists.gentoo.org> List-Help: <mailto:gentoo-dev+help@lists.gentoo.org> List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org> List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org> List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org> X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Archives-Salt: 1be14b03-d746-42b2-8fae-ab028e59fc6c X-Archives-Hash: af74d375d8dde51fb9fd13502d13daf3 On Sat, 28 Jan 2017 11:28:45 +0000 James Le Cuirot <chewi@gentoo.org> wrote: > On Fri, 27 Jan 2017 18:37:52 -0800 > Patrick McLean <chutzpah@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.