Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#54456 - [amule] groupadd should use --system, but doesn't
Attached to Project:
Community Packages
Opened by Peter Cordes (pcordes) - Wednesday, 14 June 2017, 21:33 GMT
Last edited by Antonio Rojas (arojas) - Thursday, 15 June 2017, 07:11 GMT
Opened by Peter Cordes (pcordes) - Wednesday, 14 June 2017, 21:33 GMT
Last edited by Antonio Rojas (arojas) - Thursday, 15 June 2017, 07:11 GMT
|
DetailsThe amule group has gid 1001 on my system, which clashes with GIDs for other real users on another system.
The cause is a still-present bug in the `amule.install` script. I think using `groupadd --system` is all that's needed to fix it. --- /var/lib/pacman/local/amule-10983-3/install 2017-05-17 10:54:01.000000000 -0300 +++ amule.install 2017-06-14 18:08:39.789805703 -0300 @@ -13,7 +13,7 @@ post_upgrade() { # create user/group that the daemon will run as by default, do not delete this on uninstall, as it will own files - getent group amule >/dev/null || groupadd amule + getent group amule >/dev/null || groupadd --system amule getent passwd amule >/dev/null || useradd --system -c 'aMule Client' -g amule -d '/var/lib/amule' -m -s /bin/false amule if [ ! -e /var/lib/amule/.aMule/amule.conf ]; then ----- Using `useradd --system --user-group` might be better. (And make the package install slightly faster, since `groupadd` would usually never run. getent group amule would find the group just created by useradd.) Or maybe this is worse, since it might break if the amule group exists but the user doesn't (IDK what useradd --user-group does in that case). # hand-edited diff --- /var/lib/pacman/local/amule-10983-3/install 2017-05-17 10:54:01.000000000 -0300 +++ amule.install 2017-06-14 18:08:39.789805703 -0300 @@ -13,7 +13,7 @@ post_upgrade() { # create user/group that the daemon will run as by default, do not delete this on uninstall, as it will own files - getent group amule >/dev/null || groupadd amule - getent passwd amule >/dev/null || useradd --system -c 'aMule Client' -g amule -d '/var/lib/amule' -m -s /bin/false amule + getent passwd amule >/dev/null || useradd --system --user-group -c 'aMule Client' -d '/var/lib/amule' -m -s /bin/false amule + getent group amule >/dev/null || groupadd --system amule if [ ! -e /var/lib/amule/.aMule/amule.conf ]; then ------------ There's no clean way to retroactively fix it for systems where the group already exists, so best not to try, especially since it doesn't hurt single-user systems at all. Maybe suggest something like this, for admins that want to do something about it: sudo vigr # change the gid manually sudo find /var/lib/amule -gid "old-numeric-gid" -exec chgrp amule {} + I ended up renumbering the brlapi group, too, so I could give the same numeric UID and GID to the amule user/group. |
This task depends upon
Closed by Antonio Rojas (arojas)
Thursday, 15 June 2017, 07:11 GMT
Reason for closing: Fixed
Additional comments about closing: switched to sysusers
Thursday, 15 June 2017, 07:11 GMT
Reason for closing: Fixed
Additional comments about closing: switched to sysusers