Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
On Fri, Jan 8, 2021 at 1:31 PM Michał Górny wrote: > Again, I don't understand why you continue escalating this. I have > already indicated that I'm fine with adding an option to disable this, > given that 1) the current behavior remains the default, and 2) people > are given big fat warning that they are now responsible for updating > their users (and ideally 3) the eclass tells user how to update > the user). I've just asked for the option to override values via > make.conf goes first since that is the preferred solution that doesn't > destroy the foundations of GLEP 81. > > floppym has indicated an interest in this, so I've presumed he's going > to submit an updated patch to the ml. Sorry, I didn't mean to give that impression. I do not have any plans to submit patches myself. I asked if you would accept a similar patch to clarify your position for others (including Whissi) who may want to contribute.
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
On Fri, 2021-01-08 at 19:23 +0100, Thomas Deutschmann wrote: > On 2021-01-08 19:14, Michał Górny wrote: > > The one floppym suggested, i.e. the same as sent patch but with > > the default staying on the current behavior. > > Do I understand correctly? You are willing to accept my patch but with > > > ACCT_USER_ALLOW_EXISTING_USER_TO_BE_MODIFIED > > defaulting to a non-zero value to keep current behavior? > > This would be an acceptable compromise for me like it would allow users > like me at least to opt-out. I would still try to convince Gentoo to > change the default later because I believe this is a bad default but of > course I would accept any voting results on this implementation detail. In principle, yes. However, when such a patch is sent I may have more requests. For a start, shorter variable name, say, ACCT_USER_NO_MODIFY or ACCT_USER_NO_UPDATE. -- Best regards, Michał Górny
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
On Fri, 2021-01-08 at 19:10 +0100, Thomas Deutschmann wrote: > On 2021-01-08 18:06, Mike Gilbert wrote: > > I disagree with your premise: I argue that the eclass is not "broken", > > and the code works as designed. You just don't like aspects of its > > design. > > Several people, not just me... *users*, other devs like robbat2 and > antarus, all with experience in maintaining multiple systems not just as > a hobby, have expressed that the current design has a flaw. They did. What you're neglecting to repeat is that they've also indicated that your proposed design is flawed as well. You're conflating 'design A is flawed' into 'design B is better', while they really said 'both design A and B are flawed'. > I got feedback from other devs representing a large group in Gentoo and > they all agree on the problem. They haven't spoken up yet because they > don't care because the way how they use Gentoo is stateless. > > So why the hell is it acceptable for a small group (you and mgorny, > Michael told me already last year that he will be fine with an opt-in > change and I assume his opinion hasn't changed) to cause problems for > another group just because you don't want to acknowledge the problem? So what's you're basically saying is that there are people who like behavior A, people who like behavior B and people who don't care. Somehow you manage -- without any hard evidence -- to claim that people who dislike the current behavior are more numerous than the people who like the current behavior, and also implicitly count people who don't care towards them (why?). Even if you managed to prove that (how?), is this really a popularity contest? The current behavior has been the default for 1.5 years. There are ebuilds that literally depend on it. If you are going to change that, then you need to prove that 1) your proposed solution is much better for the vast majority of Gentoo users (again, how?), and 2) that the benefit from the change in behavior outweighs its costs. And given that you've pretty much admitted that the majority probably 'does not care', then 2) is not met. > Even soap, not sure if he has spoken for himself or as QA lead, has > acknowledged in this thread that we need a mechanism to disable this > behavior. > > Is it really not possible to solve this technical problem? Do we have to > escalate and need a vote or something to replace entire GLEP 81 with > something new just because a group believes there is no flaw and > everyone else having problems are doing things wrong so this group is > rejecting any attempts to address the problem? Again, I don't understand why you continue escalating this. I have already indicated that I'm fine with adding an option to disable this, given that 1) the current behavior remains the default, and 2) people are given big fat warning that they are now responsible for updating their users (and ideally 3) the eclass tells user how to update the user). I've just asked for the option to override values via make.conf goes first since that is the preferred solution that doesn't destroy the foundations of GLEP 81. floppym has indicated an interest in this, so I've presumed he's going to submit an updated patch to the ml. -- Best regards, Michał Górny
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
On 2021-01-08 19:14, Michał Górny wrote: The one floppym suggested, i.e. the same as sent patch but with the default staying on the current behavior. Do I understand correctly? You are willing to accept my patch but with > ACCT_USER_ALLOW_EXISTING_USER_TO_BE_MODIFIED defaulting to a non-zero value to keep current behavior? This would be an acceptable compromise for me like it would allow users like me at least to opt-out. I would still try to convince Gentoo to change the default later because I believe this is a bad default but of course I would accept any voting results on this implementation detail. -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
On Fri, 2021-01-08 at 19:11 +0100, Fabian Groffen wrote: > On 04-01-2021 17:14:47 +0100, Michał Górny wrote: > > Yes, I don't mind an option, as long as it spews a big fat ewarn that > > the user loses the right to support. However, that's still not > > the right solution to the immediate problem, and I'm currently working > > on a better patch, so I'd prefer if you waited with that to avoid merge > > conflicts. > > Could you please share your intended approach? The one floppym suggested, i.e. the same as sent patch but with the default staying on the current behavior. -- Best regards, Michał Górny
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
On 04-01-2021 17:14:47 +0100, Michał Górny wrote: > Yes, I don't mind an option, as long as it spews a big fat ewarn that > the user loses the right to support. However, that's still not > the right solution to the immediate problem, and I'm currently working > on a better patch, so I'd prefer if you waited with that to avoid merge > conflicts. Could you please share your intended approach? Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
On 2021-01-08 18:06, Mike Gilbert wrote: I disagree with your premise: I argue that the eclass is not "broken", and the code works as designed. You just don't like aspects of its design. Several people, not just me... *users*, other devs like robbat2 and antarus, all with experience in maintaining multiple systems not just as a hobby, have expressed that the current design has a flaw. I got feedback from other devs representing a large group in Gentoo and they all agree on the problem. They haven't spoken up yet because they don't care because the way how they use Gentoo is stateless. So why the hell is it acceptable for a small group (you and mgorny, Michael told me already last year that he will be fine with an opt-in change and I assume his opinion hasn't changed) to cause problems for another group just because you don't want to acknowledge the problem? Even soap, not sure if he has spoken for himself or as QA lead, has acknowledged in this thread that we need a mechanism to disable this behavior. Is it really not possible to solve this technical problem? Do we have to escalate and need a vote or something to replace entire GLEP 81 with something new just because a group believes there is no flaw and everyone else having problems are doing things wrong so this group is rejecting any attempts to address the problem? -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
On Fri, 2021-01-08 at 17:29 +0100, Thomas Deutschmann wrote: > On 2021-01-08 17:03, Mike Gilbert wrote: > > I strongly object to you pushing this patch as-is. There have been > > plenty of non-technical objections, including from the eclass > > maintainer. > > The eclass maintainer has disqualified himself going into a technical > debate with saying > > > So, over my dead commit access. > > in his first posting. Please remind me, who granted your the power to disqualify maintainers? > This is a technical mailing list. Currently, acct-* stuff is breaking > stuff. Nobody has challenged this yet. No, it is not. It is behaving as described. What really happens is that you rejected the design, deliberately broke your system and now are trying to push your design over false arguments. > It's not like we cannot address the other stuff later. It's about > getting the fix down to users who are currently affected by this. So why > take hostage when some user(s) ignore the problem for more than a year > and show that they are not interested in collaboration to find a > solution for a technical problem they created despite warnings before > this went live? Yes, surely me abandoning other work to provide a patch on the same day proves that I am 'not interested in collaboration to find a solution'. -- Best regards, Michał Górny
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
On Fri, Jan 8, 2021 at 11:29 AM Thomas Deutschmann wrote: > This is a technical mailing list. Currently, acct-* stuff is breaking > stuff. Nobody has challenged this yet. > > Now I proposed a way how to unbreak stuff. > > Please tell me why we should keep broken stuff for non-technical reason > and cause harm for those who are affected? I disagree with your premise: I argue that the eclass is not "broken", and the code works as designed. You just don't like aspects of its design. If you want to change the design, you need buy-in from the maintainer, or you need to override him.
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
On Fri, Jan 8, 2021 at 11:29 AM Thomas Deutschmann wrote: > > On 2021-01-08 17:03, Mike Gilbert wrote: > > I strongly object to you pushing this patch as-is. There have been > > plenty of non-technical objections, including from the eclass > > maintainer. > > The eclass maintainer has disqualified himself going into a technical > debate with saying > > > So, over my dead commit access. > > in his first posting. > > This is a technical mailing list. Currently, acct-* stuff is breaking > stuff. Nobody has challenged this yet. > > Now I proposed a way how to unbreak stuff. > > Please tell me why we should keep broken stuff for non-technical reason > and cause harm for those who are affected? > > It's not like we cannot address the other stuff later. It's about > getting the fix down to users who are currently affected by this. So why > take hostage when some user(s) ignore the problem for more than a year > and show that they are not interested in collaboration to find a > solution for a technical problem they created despite warnings before > this went live? > > Of course, if you are not affected by this problem it is very easy to > relax and sit back. You have all the time in the world... but when you > are affected by this at large scale it is not that funny anymore. Let me put it this way: if you push this without agreement from the maintainer, QA, or council, you can probably expect a swift revert.
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
On 2021-01-08 17:03, Mike Gilbert wrote: I strongly object to you pushing this patch as-is. There have been plenty of non-technical objections, including from the eclass maintainer. The eclass maintainer has disqualified himself going into a technical debate with saying So, over my dead commit access. in his first posting. This is a technical mailing list. Currently, acct-* stuff is breaking stuff. Nobody has challenged this yet. Now I proposed a way how to unbreak stuff. Please tell me why we should keep broken stuff for non-technical reason and cause harm for those who are affected? It's not like we cannot address the other stuff later. It's about getting the fix down to users who are currently affected by this. So why take hostage when some user(s) ignore the problem for more than a year and show that they are not interested in collaboration to find a solution for a technical problem they created despite warnings before this went live? Of course, if you are not affected by this problem it is very easy to relax and sit back. You have all the time in the world... but when you are affected by this at large scale it is not that funny anymore. -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
On Fri, Jan 8, 2021 at 10:48 AM Thomas Deutschmann wrote: > > Hi, > > since nobody posted any technical objections, I am going to push the > proposed patch on Saturday to address the current issue and allow any > professional Gentoo user relying on usermod/configuration management > tool to move on. I strongly object to you pushing this patch as-is. There have been plenty of non-technical objections, including from the eclass maintainer.
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
Hi, since nobody posted any technical objections, I am going to push the proposed patch on Saturday to address the current issue and allow any professional Gentoo user relying on usermod/configuration management tool to move on. If someone will spend time on further improvements like implementing the idea outlined by Robin or what Michael said about /etc/users.d and user-update tool, this is highly appreciated but will probably not happen anytime soon. -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
On Mon, Jan 4, 2021 at 11:50 AM Thomas Deutschmann wrote: > > On 2021-01-04 17:38, Michał Górny wrote: > > You've actually added 'portage' to group 'thomas'. > > Yes, I know that. > > Well, I understand why this might be confusing for you. Like I was using > portage as example for the described example when you give another > service access to a socket like shown in my memcached/redis example. That's a really weird example, but if that was your intent please disregard my last message.
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
On Mon, 2021-01-04 at 17:50 +0100, Thomas Deutschmann wrote: > On 2021-01-04 17:38, Michał Górny wrote: > > You've actually added 'portage' to group 'thomas'. > > Yes, I know that. > > Well, I understand why this might be confusing for you. Like I was using > portage as example for the described example when you give another > service access to a socket like shown in my memcached/redis example. > > This is confusing to me (as is probably to everybody else) because your text is saying the exact opposite. | Add your user to portage's group [...] You're doing the exact opposite. Maybe it's time to admit that you've made a mistake, and you've made the same mistake the second time in a row, and although it was proven wrong before you still keep trying to support your arguments with this mistake. -- Best regards, Michał Górny
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
On Mon, Jan 4, 2021 at 11:34 AM Thomas Deutschmann wrote: > > On 2021-01-04 17:30, Thomas Deutschmann wrote: > > On 2021-01-04 17:28, Michał Górny wrote: > >> It must be a bug in your version of the eclass. I've just reemerged > >> acct-group/wheel and to*my great surprise* I'm still there. How > >> unexpected! > > > > That's why I wrote > > > > > (luckily groups like wheel don't have users...) > > > > I meant that there is no acct-user/wheel because otherwise this group > > would get cleaned (reset), too. > > Best example is portage. Follow handbook. Add your user to portage's group: > > > usermod -aG portage I don't see any mention of usermod in the handbook, so I'm not sure where this came from. As mgorny pointed out, you are invoking usermod incorrectly. You want this instead: usermod -aG portage Don't use "id" to list group members. That lists groups of which a user is a member. Use getent instead: getent group portage
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
On 2021-01-04 17:38, Michał Górny wrote: You've actually added 'portage' to group 'thomas'. Yes, I know that. Well, I understand why this might be confusing for you. Like I was using portage as example for the described example when you give another service access to a socket like shown in my memcached/redis example. -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
On Mon, 2021-01-04 at 17:34 +0100, Thomas Deutschmann wrote: > On 2021-01-04 17:30, Thomas Deutschmann wrote: > > On 2021-01-04 17:28, Michał Górny wrote: > > > It must be a bug in your version of the eclass. I've just reemerged > > > acct-group/wheel and to*my great surprise* I'm still there. How > > > unexpected! > > > > That's why I wrote > > > > > (luckily groups like wheel don't have users...) > > > > I meant that there is no acct-user/wheel because otherwise this group > > would get cleaned (reset), too. > > Best example is portage. Follow handbook. Add your user to portage's group: > > > usermod -aG portage You've actually added 'portage' to group 'thomas'. -- Best regards, Michał Górny
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
On 2021-01-04 17:30, Thomas Deutschmann wrote: On 2021-01-04 17:28, Michał Górny wrote: It must be a bug in your version of the eclass. I've just reemerged acct-group/wheel and to*my great surprise* I'm still there. How unexpected! That's why I wrote > (luckily groups like wheel don't have users...) I meant that there is no acct-user/wheel because otherwise this group would get cleaned (reset), too. Best example is portage. Follow handbook. Add your user to portage's group: > usermod -aG portage Now re-emerge acct-user/portage... # usermod -aG thomas portage # id portage uid=250(portage) gid=250(portage) groups=250(portage),1000(thomas) # emerge -a1 acct-user/portage These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R] acct-user/portage-0::gentoo 0 KiB Total: 1 package (1 reinstall), Size of downloads: 0 KiB Would you like to merge these packages? [Yes/No] y Verifying ebuild manifests Running pre-merge checks for acct-user/portage-0 Emerging (1 of 1) acct-user/portage-0::gentoo Installing (1 of 1) acct-user/portage-0::gentoo Jobs: 1 of 1 complete Auto-cleaning packages... No outdated packages were found on your system. * GNU info directory index is up-to-date. # id portage uid=250(portage) gid=250(portage) groups=250(portage) -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
On 2021-01-04 17:28, Michał Górny wrote: It must be a bug in your version of the eclass. I've just reemerged acct-group/wheel and to*my great surprise* I'm still there. How unexpected! That's why I wrote > (luckily groups like wheel don't have users...) I meant that there is no acct-user/wheel because otherwise this group would get cleaned (reset), too. -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
On Mon, 2021-01-04 at 17:18 +0100, Thomas Deutschmann wrote: > On 2021-01-04 16:55, David Seifert wrote: > > This is what we agree on. We need an escape hatch, and it needs to be > > off by default. Any sysadmin overriding it gets to keep the pieces, but > > they need to have that option. > > See Mike's example again. > > In last chapter of Gentoo's handbook (Finalization) we recommend user to > call 'usermod' to put themselves into important groups like wheel or > portage. > > Now guess what's happening? Whenever acct-user/portage will get > remerged, PM will remove that user from portage group (luckily groups > like wheel don't have users...). It must be a bug in your version of the eclass. I've just reemerged acct-group/wheel and to *my great surprise* I'm still there. How unexpected! -- Best regards, Michał Górny
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
On 2021-01-04 17:14, Michał Górny wrote: as long as it spews a big fat ewarn that the user loses the right to support. Could you please elaborate this a little bit more? I cannot agree with the way I understand this at the moment but I might miss your point. -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
On 2021-01-04 16:55, David Seifert wrote: This is what we agree on. We need an escape hatch, and it needs to be off by default. Any sysadmin overriding it gets to keep the pieces, but they need to have that option. See Mike's example again. In last chapter of Gentoo's handbook (Finalization) we recommend user to call 'usermod' to put themselves into important groups like wheel or portage. Now guess what's happening? Whenever acct-user/portage will get remerged, PM will remove that user from portage group (luckily groups like wheel don't have users...). Do you really want to extend handbook and tell everyone, "OK, as last step, please create an overlay and fork acct-user/portage...". In case the answer will be yes, we now have successfully killed the idea of allowing maintainers to fix a user/group if this will ever be necessary which will add some kind of slap stick to the whole idea. That's why I am saying that we don't just need an opt-out option, that's why I am argue that all this stuff has to be opt-in by default. It's something special and unique in Gentoo. -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5 OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
On Mon, 2021-01-04 at 11:10 -0500, Mike Gilbert wrote: > On Mon, Jan 4, 2021 at 4:23 AM Michał Górny wrote: > > > > On Mon, 2021-01-04 at 02:35 +0100, Thomas Deutschmann wrote: > > > Modifying an existing user is a bad default and makes Gentoo > > > special because it is common for system administrators to make > > > modifications to user (i.e. putting an user into another service's > > > group to allow that user to access service in question) and it > > > would be unexpected to see these changes reverted during normal > > > world upgrade (which could break services). > > > > Not modifying an existing user is a horrible default that has already > > bricked one system (by removing /dev/null). So, over my dead commit > > access. > > As the eclass maintainer, would you be willing to merge a similar > patch that enables user modifications by default, but provides > sysadmins a way to disable it? Yes, I don't mind an option, as long as it spews a big fat ewarn that the user loses the right to support. However, that's still not the right solution to the immediate problem, and I'm currently working on a better patch, so I'd prefer if you waited with that to avoid merge conflicts. -- Best regards, Michał Górny
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
On Mon, Jan 4, 2021 at 4:23 AM Michał Górny wrote: > > On Mon, 2021-01-04 at 02:35 +0100, Thomas Deutschmann wrote: > > Modifying an existing user is a bad default and makes Gentoo > > special because it is common for system administrators to make > > modifications to user (i.e. putting an user into another service's > > group to allow that user to access service in question) and it > > would be unexpected to see these changes reverted during normal > > world upgrade (which could break services). > > Not modifying an existing user is a horrible default that has already > bricked one system (by removing /dev/null). So, over my dead commit > access. As the eclass maintainer, would you be willing to merge a similar patch that enables user modifications by default, but provides sysadmins a way to disable it? I have a feeling that there will not be a consensus on the default behavior, and I could see that getting escalated to council. However, it might be nice to provide people with the option in the meantime.
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
On Mon, 2021-01-04 at 10:24 -0500, Michael Orlitzky wrote: > 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. This is what we agree on. We need an escape hatch, and it needs to be off by default. Any sysadmin overriding it gets to keep the pieces, but they need to have that option.
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
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.
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
Hi, On 2021-01-04 04:18, Michael Orlitzky wrote: It would be nice if this was well-supported by the official way of modifying system users/groups; that is, by using an overlay with modified user/group ebuilds. No, this doesn't work: 1) It's conflicting with the goals other have. See Mike's first reply to my patch proposal: 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. 2) Thank you for outlining the process how to make changes to users using the new acct-* way. It's a nice 'hack'. But it is an own, new way, which makes Gentoo special, unique. And this creates additional problems: This maybe work for your local system. In environments where everything is Gentoo and everyone knows Gentoo. But in today's world you are using configuration management tools like Ansible, Puppet, Saltstack, Chef... People who are not necessarily familiar with every implementation detail must be able to write configurations (recipes) and the used tool is supposed to take care of the differences. In the end, in the ideal world, you are just looking at your code describing a state the system should have. But this doesn't work if you make Gentoo so special that you will break most tools, will require adjustments or special Gentoo support just for stuff Gentoo is doing differently and like everyone else. Don't get me wrong here: Yes, these tools already have to implement USE flags for example which are unique for Gentoo. But stuff like user management isn't or should *not*. 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? 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? Again, I understand the acct-* fork idea. But I think we have to admit that this will only work for the local system or small environments. For any professional environment this won't work nor scale. 4) Yet we have to talk about the idea in general that it is really not a good idea to automatically make changes to the user if you run the risk of overwriting changes explicitly made by the system administrator. It's one thing that multiple local users will get removed from portage group when you remerge acct-user/portage, but if you kill services because package maintainers are pushing their vision of how to run the package, it's not. -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
On 2021-01-04 10:23, Michał Górny wrote: Not modifying an existing user is a horrible default that has already bricked one system (by removing /dev/null). So, over my dead commit access. Have you seen how many user were hit caused by the recent rebuilt on 2020-12-28 and are already complaining/asking for help through various channels? It's like asking for service auto-restart support in PMS as requested as part of current OpenSSH upgrade because if you move from <8.3_p1 to >=8.3_p1 and don't restart OpenSSH in time, you can get locked out. However, an easily looking solution like Just add something like if [[ -d /run/systemd/system ]]; then systemctl try-restart sshd else rc-service -q --ifstarted sshd restart fi to pkg_postinst is wrong because even if it works for *some* users it won't work for all users but has the potential to cause major problems. That's why we have elog and newitem system. However, 8.3 is in repository for while and multiple people forgot about the newitem and didn't pay attention to elog messages. While I agree that it's a problem when you lose access to a remote box you don't have physical access to, this reached a level where I have to say, > We cannot rescue/protect everyone. Back to topic, acct-* stuff: Like already said in February 2020 when I joined a thread created by a user posting same concerns: There is a reason why *no* distribution on this planet is trying to mess with existing data/configurations: Every attempt trying to analyze given setup to apply required changes to fix/migrate something automatically has been prone to fail the long run. Please get some experience from real world. Preferable from running headless systems not just for yourself and where you are not the only person touching the system. When I worked on bug 605008 long time ago for example, I also ended up over-engineering. There is stuff you cannot fix. I am still thinking about creating everything the way it should look like in $D and report any difference like changed file permissions to user on merge to allow them to notice (an improvement, now user only have to pay attention and you need to solve the additional problem that the more information you present all the time, the more information will be ignored). But sometimes users are making changes we wouldn't do, not recommend or just don't understand at first. That all doesn't matter: We have to keep in mind that these aren't our systems and we have to respect whatever the user did on their system. -- Regards, Thomas Deutschmann / Gentoo Linux Developer fpr: C4DD 695F A713 8F24 2AA1 5638 5849 7EE5 1D5D 74A5
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
On Mon, 2021-01-04 at 02:35 +0100, Thomas Deutschmann wrote: > Modifying an existing user is a bad default and makes Gentoo > special because it is common for system administrators to make > modifications to user (i.e. putting an user into another service's > group to allow that user to access service in question) and it > would be unexpected to see these changes reverted during normal > world upgrade (which could break services). Not modifying an existing user is a horrible default that has already bricked one system (by removing /dev/null). So, over my dead commit access. -- Best regards, Michał Górny
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
Whissi's patch in itself is a good step forward, but I don't feel it goes far enough, nor promotes better defaults for the unmodified cases. On Mon, Jan 04, 2021 at 02:35:58AM +0100, Thomas Deutschmann wrote: > Modifying an existing user is a bad default and makes Gentoo > special because it is common for system administrators to make > modifications to user (i.e. putting an user into another service's > group to allow that user to access service in question) and it > would be unexpected to see these changes reverted during normal > world upgrade (which could break services). > > This commit will make Gentoo behave like any other Linux distribution > by respecting any user modifications by default. However, we will retain > the functionality to reset system user and groups and users interested > in this feature can opt-in by setting > ACCT_USER_ALLOW_EXISTING_USER_TO_BE_MODIFIED to a non-zero value in > their make.conf. No default is good, and that's the mess here. The problem has started to happen in other distros as well, not just Gentoo. usermod/gpasswd in RPM specfiles, as well as Debian controls. As a sysadmin, I don't want stuff messing with the system users I have in place; but if upstream requirements change on a package impacting user/group layout, I also expect packaging to track it. Many years ago, qmail did this, introducing an additional user to further separate privileges. Unfortunately, these two things are in conflict, and I don't feel there is an easy answer. It's NOT the binary decision of: - let packagers change system user - force sysadmins to always change users manually Nor a single knob that selects between that binary. We need a compromise. The best I can come up with at the moment, is that any packaging should detect if there are user modifications, and provide control to users based on that fact. - if unmodified: interactive, or auto-accept, or deny - if modified: interactive, or auto-accept, or deny These are two distinct config knobs (I'm ok with a default value that populates both of them). This leads to secondary parts: - what if the packaging change regarding users/groups is absolutely mandatory for the new version of a package to work correctly? - what about conflicting user requirements? Antarus raised the HOMEDIR of the git user for gitolite vs gitea. I think in this case, the packages should detect the problematic conditions and abort, in pkg_pretend and/or pkg_setup (thinking about binpkgs here, pkg_pretend might be too early if acct-user/X needs to merged before the check is expected to succeed). These checks MUST be in the package that consumes/depends on acct-user or acct-group packages. Yes, this means constants are likely to be duplicated, but I'm ok with that, because they are also likely to be specifically versioned. -- Robin Hugh Johnson Gentoo Linux: Dev, Infra Lead, Foundation Treasurer E-Mail : robb...@gentoo.org GnuPG FP : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85 GnuPG FP : 7D0B3CEB E9B85B1F 825BCECF EE05E6F6 A48F6136 signature.asc Description: PGP signature
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
On 1/3/21 8:35 PM, Thomas Deutschmann wrote:
Modifying an existing user is a bad default and makes Gentoo
special because it is common for system administrators to make
modifications to user (i.e. putting an user into another service's
group to allow that user to access service in question) and it
would be unexpected to see these changes reverted during normal
world upgrade (which could break services).
It would be nice if this was well-supported by the official way of
modifying system users/groups; that is, by using an overlay with
modified user/group ebuilds.
Right now it's awkward to do because of the way the eclasses are
structured. For example, some of our servers allow the "postfix" user to
write to OpenDKIM's socket, but only on our *outgoing* mail servers (not
on the incoming MX, where no signing takes place.) This is accomplished
by creating an acct-group/dkimsocket ebuild (ok so far), and then by
overriding the acct-user/postfix ebuild:
EAPI=7
inherit acct-user
DESCRIPTION="user for postfix daemon"
IUSE="dkimsocket"
ACCT_USER_ID=207
ACCT_USER_GROUPS=( postfix mail )
acct-user_add_deps
# This needs to be done outside of acct-user_add_deps because we can't
# test use flags in global scope, and therefore we can't add groups
# to ACCT_USER_GROUPS before calling acct-user_add_deps.
RDEPEND+=" dkimsocket? ( acct-group/dkimsocket )"
pkg_setup() {
# https://wiki.gentoo.org/wiki/OpenDKIM
#
# Even though we added the group to RDEPEND manually, we still
# need to add it to the array.
if use dkimsocket; then
ACCT_USER_GROUPS+=( dkimsocket )
fi
}
That's the common case of adding a system user to a group, and it's
pretty ugly, so it's no wonder that people want to use "usermod" and
then ignore subsequent changes by the PM.
And there's probably a backwards-compatible way we could support
USE-conditional supplementary groups.
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
On Sun, Jan 3, 2021 at 6:42 PM Mike Gilbert wrote:
>
> On Sun, Jan 3, 2021 at 8:35 PM Thomas Deutschmann wrote:
> >
> > Modifying an existing user is a bad default and makes Gentoo
> > special because it is common for system administrators to make
> > modifications to user (i.e. putting an user into another service's
> > group to allow that user to access service in question) and it
> > would be unexpected to see these changes reverted during normal
> > world upgrade (which could break services).
> >
> > This commit will make Gentoo behave like any other Linux distribution
> > by respecting any user modifications by default. However, we will retain
> > the functionality to reset system user and groups and users interested
> > in this feature can opt-in by setting
> > ACCT_USER_ALLOW_EXISTING_USER_TO_BE_MODIFIED to a non-zero value in
> > their make.conf.
>
> 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. Developers may want/need to deploy changes to user
> attributes. Changing group memberships seems like the best example,
> but I could foresee a want/need to change DESCRIPTION, HOME, or SHELL
> as well.
I think the TL;DR is I don't believe changes in HOME, or SHELL are
safe to do in later revisions. This means developers:
- Need to be careful when picking em!
- Can use later revisions to set sane defaults for fresh installs.
- Can't touch existing installs because changing HOME and SHELL can
cause user-facing breakage.
Often if HOME points somewhere that isn't /dev/null, you have to do
some kind of migration. I'd rather not enable that sort of breakage by
default because it's a per-app / per-user migration pain.
To pick an example:
The git user has a HOME in either /var/lib/gitea or /var/lib/gitolite.
If you change it, you will break whatever service is running.
This is the same for any service account whose $HOME stores
state...which is most of them with a HOME set.
-A
>
> Because of this, I think the new behavior should be opt-in, and people
> who use it should be aware that they will need to pay attention if any
> account changes are rolled out in new ebuild versions.
>
> > diff --git a/eclass/acct-user.eclass b/eclass/acct-user.eclass
> > index 22b0038fbff7..d60b1e53b4bb 100644
> > --- a/eclass/acct-user.eclass
> > +++ b/eclass/acct-user.eclass
> > @@ -309,6 +321,20 @@ acct-user_pkg_pretend() {
> > fi
> > }
> >
> > +# @FUNCTION: acct-user_pkg_setup
> > +# @DESCRIPTION:
> > +# Initialize internal environment variable(s).
> > +acct-user_pkg_setup() {
> > + debug-print-function ${FUNCNAME} "${@}"
> > +
> > + # check if user already exists
> > + ACCT_USER_ALREADY_EXISTS=
> > + if [[ -n $(egetent passwd "${ACCT_USER_NAME}") ]]; then
> > + ACCT_USER_ALREADY_EXISTS=yes
> > + fi
> > + readonly ACCT_USER_ALREADY_EXISTS
> > +}
>
> I don't think this pkg_setup function is necessary; you could do this
> in pkg_preinst instead, before enewuser gets called.
>
Re: [gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
On Sun, Jan 3, 2021 at 8:35 PM Thomas Deutschmann wrote:
>
> Modifying an existing user is a bad default and makes Gentoo
> special because it is common for system administrators to make
> modifications to user (i.e. putting an user into another service's
> group to allow that user to access service in question) and it
> would be unexpected to see these changes reverted during normal
> world upgrade (which could break services).
>
> This commit will make Gentoo behave like any other Linux distribution
> by respecting any user modifications by default. However, we will retain
> the functionality to reset system user and groups and users interested
> in this feature can opt-in by setting
> ACCT_USER_ALLOW_EXISTING_USER_TO_BE_MODIFIED to a non-zero value in
> their make.conf.
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. Developers may want/need to deploy changes to user
attributes. Changing group memberships seems like the best example,
but I could foresee a want/need to change DESCRIPTION, HOME, or SHELL
as well.
Because of this, I think the new behavior should be opt-in, and people
who use it should be aware that they will need to pay attention if any
account changes are rolled out in new ebuild versions.
> diff --git a/eclass/acct-user.eclass b/eclass/acct-user.eclass
> index 22b0038fbff7..d60b1e53b4bb 100644
> --- a/eclass/acct-user.eclass
> +++ b/eclass/acct-user.eclass
> @@ -309,6 +321,20 @@ acct-user_pkg_pretend() {
> fi
> }
>
> +# @FUNCTION: acct-user_pkg_setup
> +# @DESCRIPTION:
> +# Initialize internal environment variable(s).
> +acct-user_pkg_setup() {
> + debug-print-function ${FUNCNAME} "${@}"
> +
> + # check if user already exists
> + ACCT_USER_ALREADY_EXISTS=
> + if [[ -n $(egetent passwd "${ACCT_USER_NAME}") ]]; then
> + ACCT_USER_ALREADY_EXISTS=yes
> + fi
> + readonly ACCT_USER_ALREADY_EXISTS
> +}
I don't think this pkg_setup function is necessary; you could do this
in pkg_preinst instead, before enewuser gets called.
[gentoo-dev] [PATCH] acct-user.eclass: don't modify existing user by default
Modifying an existing user is a bad default and makes Gentoo
special because it is common for system administrators to make
modifications to user (i.e. putting an user into another service's
group to allow that user to access service in question) and it
would be unexpected to see these changes reverted during normal
world upgrade (which could break services).
This commit will make Gentoo behave like any other Linux distribution
by respecting any user modifications by default. However, we will retain
the functionality to reset system user and groups and users interested
in this feature can opt-in by setting
ACCT_USER_ALLOW_EXISTING_USER_TO_BE_MODIFIED to a non-zero value in
their make.conf.
Signed-off-by: Thomas Deutschmann
---
eclass/acct-user.eclass | 40 ++--
1 file changed, 38 insertions(+), 2 deletions(-)
diff --git a/eclass/acct-user.eclass b/eclass/acct-user.eclass
index 22b0038fbff7..d60b1e53b4bb 100644
--- a/eclass/acct-user.eclass
+++ b/eclass/acct-user.eclass
@@ -72,6 +72,11 @@ readonly ACCT_USER_NAME
# Overlays should set this to -1 to dynamically allocate UID. Using -1
# in ::gentoo is prohibited by policy.
+# @ECLASS-VARIABLE: ACCT_USER_ALREADY_EXISTS
+# @INTERNAL
+# @DESCRIPTION:
+# Status variable which indicates if user already exists.
+
# @ECLASS-VARIABLE: ACCT_USER_ENFORCE_ID
# @DESCRIPTION:
# If set to a non-null value, the eclass will require the user to have
@@ -79,6 +84,13 @@ readonly ACCT_USER_NAME
# the UID is taken by another user, the install will fail.
: ${ACCT_USER_ENFORCE_ID:=}
+# @ECLASS-VARIABLE: ACCT_USER_ALLOW_EXISTING_USER_TO_BE_MODIFIED
+# @DESCRIPTION:
+# If set to a non-null value, the eclass is allowed to make changes
+# to an already existing user which will include overriding any
+# changes made by system administrator.
+: ${ACCT_USER_ALLOW_EXISTING_USER_TO_BE_MODIFIED:=}
+
# @ECLASS-VARIABLE: ACCT_USER_SHELL
# @DESCRIPTION:
# The shell to use for the user. If not specified, a 'nologin' variant
@@ -266,8 +278,8 @@ eunlockuser() {
# << Phase functions >>
-EXPORT_FUNCTIONS pkg_pretend src_install pkg_preinst pkg_postinst \
- pkg_prerm
+EXPORT_FUNCTIONS pkg_pretend pkg_setup src_install pkg_preinst \
+ pkg_postinst pkg_prerm
# @FUNCTION: acct-user_pkg_pretend
# @DESCRIPTION:
@@ -309,6 +321,20 @@ acct-user_pkg_pretend() {
fi
}
+# @FUNCTION: acct-user_pkg_setup
+# @DESCRIPTION:
+# Initialize internal environment variable(s).
+acct-user_pkg_setup() {
+ debug-print-function ${FUNCNAME} "${@}"
+
+ # check if user already exists
+ ACCT_USER_ALREADY_EXISTS=
+ if [[ -n $(egetent passwd "${ACCT_USER_NAME}") ]]; then
+ ACCT_USER_ALREADY_EXISTS=yes
+ fi
+ readonly ACCT_USER_ALREADY_EXISTS
+}
+
# @FUNCTION: acct-user_src_install
# @DESCRIPTION:
# Installs a keep-file into the user's home directory to ensure it is
@@ -379,6 +405,16 @@ acct-user_pkg_postinst() {
return 0
fi
+ if [[ -z ${ACCT_USER_ALLOW_EXISTING_USER_TO_BE_MODIFIED} && -n
${ACCT_USER_ALREADY_EXISTS} ]] ; then
+ eunlockuser "${ACCT_USER_NAME}"
+
+ einfo "User ${ACCT_USER_NAME} already exists; Not touching
existing user."
+ einfo "NOTE: If you want to allow package manager to reset user
settings"
+ einfo " like home, shell, groups... set
ACCT_USER_ALLOW_EXISTING_USER_TO_BE_MODIFIED"
+ einfo " to a non-null value in your make.conf."
+ return 0
+ fi
+
# NB: eset* functions check current value
esethome "${ACCT_USER_NAME}" "${ACCT_USER_HOME}"
esetshell "${ACCT_USER_NAME}" "${ACCT_USER_SHELL}"
--
2.30.0
