This script manipulates custom user groups. I.e. the user apache is deleted from a custom built group like: apandtt:x:116:ttrssd,apache Expected behaviour: The ebuild shouldn't touch custom user groups at all and never ever delete anything from them.
Sorry for the inconvenience. There's a workaround but I'm not sure if that one has other implications: echo "ACCT_USER_NO_MODIFY=1" >> /etc/portage/make.conf Please let me know if that is feasible for you.
I just ran into it as well, for apache AND rbot though. They both migrated to the acct-user/group eclass stuff and it looks like apache/rbot got removed and added again which resulted into deleting those from anywhere else. So this looks like a general an IMHO major issue with the acct* eclasses or at least when migrating to it.
(In reply to Christian Ruppert (idl0r) from comment #2) > I just ran into it as well, for apache AND rbot though. They both migrated > to the acct-user/group eclass stuff and it looks like apache/rbot got > removed and added again which resulted into deleting those from anywhere > else. So this looks like a general an IMHO major issue with the acct* > eclasses or at least when migrating to it. Yes, it looks like, that acct-* is removing user from all groups, which are not definied within acct-* ebuild. I am suprised here, as I would expect, that user+group is added, but other groups are not being touched.
(In reply to cilly from comment #0) > This script manipulates custom user groups. > > I.e. the user apache is deleted from a custom built group like: > > apandtt:x:116:ttrssd,apache > > Expected behaviour: > > The ebuild shouldn't touch custom user groups at all and never ever delete > anything from them. Steps to reproduce: emerge -v1 acct-user/apache-0-r1
(In reply to cilly from comment #4) > (In reply to cilly from comment #0) > > This script manipulates custom user groups. > > > > I.e. the user apache is deleted from a custom built group like: > > > > apandtt:x:116:ttrssd,apache > > > > Expected behaviour: > > > > The ebuild shouldn't touch custom user groups at all and never ever delete > > anything from them. > > Steps to reproduce: > > emerge -v1 acct-user/apache-0-r1 Confirmed. Merging it once again messes again with my users/groups...
*** Bug 803647 has been marked as a duplicate of this bug. ***
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=7012e620d5f6529ed702a8839382c4803d6eb3e7 commit 7012e620d5f6529ed702a8839382c4803d6eb3e7 Author: Conrad Kostecki <conikost@gentoo.org> AuthorDate: 2021-07-24 20:15:09 +0000 Commit: Conrad Kostecki <conikost@gentoo.org> CommitDate: 2021-07-24 20:16:26 +0000 www-servers/apache: revbump Bug: https://bugs.gentoo.org/802495 Bug: https://bugs.gentoo.org/803500 Package-Manager: Portage-3.0.20, Repoman-3.0.3 Signed-off-by: Conrad Kostecki <conikost@gentoo.org> www-servers/apache/{apache-2.4.48-r2.ebuild => apache-2.4.48-r3.ebuild} | 0 1 file changed, 0 insertions(+), 0 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d7f7d8a5eeef84e882688c89850db6376b42f766 commit d7f7d8a5eeef84e882688c89850db6376b42f766 Author: Conrad Kostecki <conikost@gentoo.org> AuthorDate: 2021-07-24 20:07:13 +0000 Commit: Conrad Kostecki <conikost@gentoo.org> CommitDate: 2021-07-24 20:15:28 +0000 Revert "eclass/apache-2.eclass: migrate to GLEP 81" This reverts commit 187721bffbea19bc37969fb70de400a391171611. Bug: https://bugs.gentoo.org/802495 Bug: https://bugs.gentoo.org/803500 Signed-off-by: Conrad Kostecki <conikost@gentoo.org> eclass/apache-2.eclass | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-)
I would like to say a big sorry. This was really not intended. As for now, until the acct-* issue is solved, how to handle this, I have reverted the eclass and bumped apache, so more users won't be for now migrated to GLEP 81.
(In reply to Larry the Git Cow from comment #7) > The bug has been referenced in the following commit(s): > > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=7012e620d5f6529ed702a8839382c4803d6eb3e7 > > commit 7012e620d5f6529ed702a8839382c4803d6eb3e7 > Author: Conrad Kostecki <conikost@gentoo.org> > AuthorDate: 2021-07-24 20:15:09 +0000 > Commit: Conrad Kostecki <conikost@gentoo.org> > CommitDate: 2021-07-24 20:16:26 +0000 > > www-servers/apache: revbump > > Bug: https://bugs.gentoo.org/802495 > Bug: https://bugs.gentoo.org/803500 > Package-Manager: Portage-3.0.20, Repoman-3.0.3 > Signed-off-by: Conrad Kostecki <conikost@gentoo.org> > > www-servers/apache/{apache-2.4.48-r2.ebuild => apache-2.4.48-r3.ebuild} | 0 > 1 file changed, 0 insertions(+), 0 deletions(-) > > https://gitweb.gentoo.org/repo/gentoo.git/commit/ > ?id=d7f7d8a5eeef84e882688c89850db6376b42f766 > > commit d7f7d8a5eeef84e882688c89850db6376b42f766 > Author: Conrad Kostecki <conikost@gentoo.org> > AuthorDate: 2021-07-24 20:07:13 +0000 > Commit: Conrad Kostecki <conikost@gentoo.org> > CommitDate: 2021-07-24 20:15:28 +0000 > > Revert "eclass/apache-2.eclass: migrate to GLEP 81" > > This reverts commit 187721bffbea19bc37969fb70de400a391171611. > > Bug: https://bugs.gentoo.org/802495 > Bug: https://bugs.gentoo.org/803500 > Signed-off-by: Conrad Kostecki <conikost@gentoo.org> > > eclass/apache-2.eclass | 8 +++++--- > 1 file changed, 5 insertions(+), 3 deletions(-) Thank you Larry, you need not to excuse, it is not your fault, we all know who borked the systems with acct and overwriting user settings without a warning. In my eyes, this is a no go.
@conrad Jul 25 15:00:01 pluto crond[12212]: (apache) PAM ERROR (User account has expired) Jul 25 15:00:01 pluto crond[12212]: (apache) PAM ERROR (User account has expired) Jul 25 15:00:01 pluto crond[12212]: (apache) FAILED to authorize user with PAM (User account has expired) Jul 25 15:00:01 pluto crond[12212]: (apache) FAILED to authorize user with PAM (User account has expired) btw, from now on, the nextcloud cron isn't working anymore - also the pam settings need to be restored, too (sudo -u apache php ....)
For all stumbling onto this s...: You also need to restore the apache entries from /etc/shadow, otherwise nextcloud's system cron fails from running.
bug 803932 might be related as well, as the existing user has been modified silently.
For now, everyone, who is affected with apache, can re-enable the account as follows: usermod -e '' -U apache 2>/dev/null
This has been discussed repeatedly on the -dev list (and is mentioned in the GLEP). If your "apache" user has requirements beyond what is actually needed by Gentoo, you should override the acct-user/apache ebuild in an overlay. That allows you to add it to additional groups, without losing all of the other GLEP81 benefits. It's also consistent with how the rest of the system works -- if you edit /usr/share/important-file.txt and then re-emerge the package that installs it, the file will be overwritten. Instead you have to patch the package in an overlay. For similar reasons, you should not be trying to modify system users directly.
Actually, these days you can do it via make.conf: ACCT_USER_APACHE_GROUPS_ADD="apandtt"
IMHO, this can be closed. As Michał said, we have two variables for that: ACCT_USER_<UPPERCASE_USERNAME>_GROUPS for overriding all default groups from ebuild. ACCT_USER_<UPPERCASE_USERNAME>_GROUPS_ADD for adding additional groups to default groups in ebuild. With Apache2 and Nginx, we should make it more clear, when they will be converted to GLEP-81.
