From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 1C6BE1382C5 for ; Mon, 4 Jan 2021 15:24:33 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id DEB45E09BC; Mon, 4 Jan 2021 15:24:29 +0000 (UTC) Received: from smtp.gentoo.org (mail.gentoo.org [IPv6:2001:470:ea4a:1:5054:ff:fec7:86e4]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id A6E25E09AB for ; Mon, 4 Jan 2021 15:24:29 +0000 (UTC) Subject: Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default To: gentoo-dev@lists.gentoo.org References: <20210104013558.20072-1-whissi@gentoo.org> <60fac781-e080-999c-e83e-c657d5b89d18@gentoo.org> From: Michael Orlitzky Message-ID: Date: Mon, 4 Jan 2021 10:24:23 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@lists.gentoo.org Reply-to: gentoo-dev@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Archives-Salt: 1fa11ecb-f931-4e69-be3e-398da0029678 X-Archives-Hash: bb966416467fe26478a0ef70096f2a33 On 1/4/21 9:46 AM, Thomas Deutschmann wrote: > >> So the main problem I see with doing this is that it becomes >> impossible to reliably make changes to a user in later ebuild >> revisions. > > He is obviously looking for a way to allow maintainers to change users > afterwards. But if we tell people, "If you need customization, fork the > user/group ebuild in your overlay" we will disconnect these users from > future changes. There's pretty much no reason to change a user's settings unless you've completely fucked them up the first time around. This is precisely why the original GLEP had mailing list reviews. If a package depends on a user having e.g. a specific home directory so that upgrading the package requires a corresponding revision bump of the user, then the package is broken. I tried really hard to document this, and to enforce it back when we had mailing list reviews. It's all in the devmanual now. > ... > When you will get LPIC certification one can expect that you have some > basic knowledge in Linux stuff allowing you to do common tasks on all > different Linux systems. Now there comes Gentoo where you aren't allowed > to use standard Linux tools like 'usermod' when deploying another > service if you don't want to risk that your service will go down when > following best practice and do regular world upgrades. Really? You also can't use the standard linux tools to edit scripts in /usr/bin without your changes being overwritten. This is no different... some things need to belong to the package manager if you want package management to work. > 3) More important, the idea of forking acct-* packages whenever you need > to make modifications don't scale. Like I already outlined in February > 2020, you cannot create overlays for each different user configuration: > > I.e. using memcached/redis: You grant permission to socket via group. So > you put other services belonging to that application you are deploying > into your user running the key value store. Do you really expect that > one would create multiple overlays per application using one of these > services? How would you maintain hundreds of overlays? How would you > keep track that each box will use the correct overlay to get the > specific customized acct-* package? How do you deal with scenarios where > you don't just deploy single instances? This is literally the example I gave. Our acct-user ebuilds can be added to additional groups based on USE flags. Every server uses the same overlay/ebuilds, but different machines get different package.use files, pushed out by the configuration management tool. I understand that creating an overlay with acct-user overrides will not be for everyone, so I have no problem with adding an escape hatch. I do think it should be off by default though, and that missing future ::gentoo changes will not be a problem unless some other error has been committed first.