Bug#1108458: unblock: slurm-wlm/24.11.5-3
On Thu, Jul 17, 2025 at 07:53:02AM +0200, Gennaro Oliva wrote: On Tue, Jul 15, 2025 at 10:11:22AM +0200, Marc Haber wrote: > The slurm user is not actually used in the package where it is created, > but only in three other packages that depend on it. It is included there > to simplify the process of removing one of them while keeping the other. > It was placed in the preinst script out of an abundance of caution. I would recommend to have the adduser call (it SHOULD really just be one single line) in the postinst of every pakage needing the user. If you need scaffolding around adduser in postinst, it is likly that I would consider that a bug in adduser and act appropriately (but we're frozen at the moment). The only check I perform before calling adduser is verifying whether the user already exists. This allows the flexibility to use Slurm with a different UID in case our fixed UID conflicts with the site's policy. Please try what your adduser call does when the user already exists or when it exists with a different UID. Please consider sending the typescript of that session to me, maybe there is some behavior that aduser can improve in forky. I would also recommend to not remove your user on package deinstallation. This would greatly simplify things. Is this a common practice? It is a rather common practice. Justification is that you cannot make sure on deletion that the local admin didn't give any files to your user that your package doesn't know about and we should not leave "unowned" files laying around. Sadly, policy has not adapted to that in over a decade. Thank you. It is usually fine to have adduser in preinst but then your package must be prepared to be able to run with the adduser from oldstable during upgrade. This is kind of a challenge to test, and that's the reason I recommend not to do this without having a VERY good reason. I haven’t noticed any changes affecting the command-line options I use, and my invocation of adduser has remained more or less the same for years. Am I underestimating any potential pitfalls? I tink so. Frankly, I don't know. I didn't have that usecase on my radar during the last two cycles. > Regarding the coexistence of the two methods for adding the user, I > accepted the merge request as submitted because I assumed there might be > systems not using systemd. I haven't really thought about whether this might make sense, but just be aware that this is an unusual pattern that has been seldomly tried. Thanks for the advice and for all your comments in general. You're welcome. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#1108458: unblock: slurm-wlm/24.11.5-3
Hi Marc, On Tue, Jul 15, 2025 at 10:11:22AM +0200, Marc Haber wrote: > > The slurm user is not actually used in the package where it is created, > > but only in three other packages that depend on it. It is included there > > to simplify the process of removing one of them while keeping the other. > > It was placed in the preinst script out of an abundance of caution. > > I would recommend to have the adduser call (it SHOULD really just be one > single line) in the postinst of every pakage needing the user. If you need > scaffolding around adduser in postinst, it is likly that I would consider > that a bug in adduser and act appropriately (but we're frozen at the > moment). The only check I perform before calling adduser is verifying whether the user already exists. This allows the flexibility to use Slurm with a different UID in case our fixed UID conflicts with the site's policy. > I would also recommend to not remove your user on package deinstallation. This would greatly simplify things. Is this a common practice? > Thank you. It is usually fine to have adduser in preinst but then your > package must be prepared to be able to run with the adduser from oldstable > during upgrade. This is kind of a challenge to test, and that's the reason I > recommend not to do this without having a VERY good reason. I haven’t noticed any changes affecting the command-line options I use, and my invocation of adduser has remained more or less the same for years. Am I underestimating any potential pitfalls? > > Regarding the coexistence of the two methods for adding the user, I > > accepted the merge request as submitted because I assumed there might be > > systems not using systemd. > > I haven't really thought about whether this might make sense, but just be > aware that this is an unusual pattern that has been seldomly tried. Thanks for the advice and for all your comments in general. Best regards, -- Gennaro Oliva
Bug#1108458: unblock: slurm-wlm/24.11.5-3
Hello, thanks for your answers. On Tue, Jul 15, 2025 at 02:57:27AM +0200, Gennaro Oliva wrote: > Pardon me for jumping in. I am the adduser maintainer. slurm-wlm is > actually one of a low one digit number of packages that have adduser in > their pre inst. May I ask for the reason you have to create your users > in pre-inst and therefore need a pre-depends on adduser? The slurm user is not actually used in the package where it is created, but only in three other packages that depend on it. It is included there to simplify the process of removing one of them while keeping the other. It was placed in the preinst script out of an abundance of caution. I would recommend to have the adduser call (it SHOULD really just be one single line) in the postinst of every pakage needing the user. If you need scaffolding around adduser in postinst, it is likly that I would consider that a bug in adduser and act appropriately (but we're frozen at the moment). I would also recommend to not remove your user on package deinstallation. > Would it be possible that you don't need that and just create your users > in postinst and just need a regular dependency on adduser? I wasn't aware that having adduser as a Pre-Depends could be such a significant issue. I created a new version of the packagte with adduser in postinst that looks fine in my testing environment. Thank you. It is usually fine to have adduser in preinst but then your package must be prepared to be able to run with the adduser from oldstable during upgrade. This is kind of a challenge to test, and that's the reason I recommend not to do this without having a VERY good reason. > Using one method or the other seems to be unusual and sounds like asking > for trouble intentionally. I would like to know what led you to this > solution Regarding the coexistence of the two methods for adding the user, I accepted the merge request as submitted because I assumed there might be systems not using systemd. I haven't really thought about whether this might make sense, but just be aware that this is an unusual pattern that has been seldomly tried. Greetings Marc -- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Leimen, Germany| lose things."Winona Ryder | Fon: *49 6224 1600402 Nordisch by Nature | How to make an American Quilt | Fax: *49 6224 1600421
Bug#1108458: unblock: slurm-wlm/24.11.5-3
Hi Marc, thanks for your comments. > > Pardon me for jumping in. I am the adduser maintainer. slurm-wlm is > > actually one of a low one digit number of packages that have adduser in > > their pre inst. May I ask for the reason you have to create your users > > in pre-inst and therefore need a pre-depends on adduser? The slurm user is not actually used in the package where it is created, but only in three other packages that depend on it. It is included there to simplify the process of removing one of them while keeping the other. It was placed in the preinst script out of an abundance of caution. > > Would it be possible that you don't need that and just create your users > > in postinst and just need a regular dependency on adduser? I wasn't aware that having adduser as a Pre-Depends could be such a significant issue. I created a new version of the packagte with adduser in postinst that looks fine in my testing environment. > > Using one method or the other seems to be unusual and sounds like asking > > for trouble intentionally. I would like to know what led you to this > > solution Regarding the coexistence of the two methods for adding the user, I accepted the merge request as submitted because I assumed there might be systems not using systemd. Best regards, -- Gennaro Oliva
Bug#1108458: unblock: slurm-wlm/24.11.5-3
Control: reopen -1 Hi, On Thu, Jul 10, 2025 at 04:28:04PM +0200, Marc Haber wrote: > On Tue, Jul 08, 2025 at 10:19:59AM +0200, Gábor Németh wrote: > > In short, yes, it works* in any combination of the two prerequisites. > > > > What is expected is that both `adduser` and `systemd-sysusers` only kick in > > if the UID/GID doesn't yet exists, so there is no double creation of the > > same IDs. I've tested with all combinations of adduser is preinstalled, > > systemd-sysuser is preinstalled, both, neither; all finish installation > > fine. > > Pardon me for jumping in. I am the adduser maintainer. slurm-wlm is > actually one of a low one digit number of packages that have adduser in > their pre inst. May I ask for the reason you have to create your users > in pre-inst and therefore need a pre-depends on adduser? > > Would it be possible that you don't need that and just create your users > in postinst and just need a regular dependency on adduser? > > Using one method or the other seems to be unusual and sounds like asking > for trouble intentionally. I would like to know what led you to this > solution As the package hasn't migrated yet, I removed my unblock to get this sorted out first. Cheers, Ivo
Bug#1108458: unblock: slurm-wlm/24.11.5-3
On Tue, Jul 08, 2025 at 10:19:59AM +0200, Gábor Németh wrote: > In short, yes, it works* in any combination of the two prerequisites. > > What is expected is that both `adduser` and `systemd-sysusers` only kick in > if the UID/GID doesn't yet exists, so there is no double creation of the > same IDs. I've tested with all combinations of adduser is preinstalled, > systemd-sysuser is preinstalled, both, neither; all finish installation > fine. Pardon me for jumping in. I am the adduser maintainer. slurm-wlm is actually one of a low one digit number of packages that have adduser in their pre inst. May I ask for the reason you have to create your users in pre-inst and therefore need a pre-depends on adduser? Would it be possible that you don't need that and just create your users in postinst and just need a regular dependency on adduser? Using one method or the other seems to be unusual and sounds like asking for trouble intentionally. I would like to know what led you to this solution Greetings from Brest Marc
Bug#1108458: unblock: slurm-wlm/24.11.5-3
Hi Paul, thanks for checking. On Sat, Jul 05, 2025 at 04:51:22PM +0200, Paul Gevers wrote: > I'm not well versed in this systemd stuff, but don't you now have two > competing methods? I mean, if both adduser and systemd-sysusers are > installed and configured, what will happen? And I guess adduser can be not > yet configured if systemd-sysusers is already configured, will the logic in > your preinst then do the right thing? I tested the installation on a system with both adduser and systemd-sysusers installed, and encountered no issues. The preinst includes a conditional check that prevents adduser from running if the user already exists. On the other hand, systemd-sysusers can safely be executed even if the user is already present. When the user does not exist, adduser runs first since it is executed in the preinst phase. I hope this explanation addresses your question, but I'm available for any further comments or clarifications. Best regards, -- Gennaro Oliva
Bug#1108458: unblock: slurm-wlm/24.11.5-3
Hi,
On Sat, 5 Jul 2025 16:51:22 +0200 Paul Gevers wrote:
I'm not well versed in this systemd stuff, but don't you now have two
competing methods? I mean, if both adduser and systemd-sysusers are
installed and configured, what will happen? And I guess adduser can be
not yet configured if systemd-sysusers is already configured, will the
logic in your preinst then do the right thing?
In short, yes, it works* in any combination of the two prerequisites.
What is expected is that both `adduser` and `systemd-sysusers` only kick
in if the UID/GID doesn't yet exists, so there is no double creation of
the same IDs. I've tested with all combinations of adduser is
preinstalled, systemd-sysuser is preinstalled, both, neither; all finish
installation fine.
*: One minor thing is that systemd-sysuser is actually a virtual
package, and one of the providers is `opensysusers` which doesn't parse
the "u!" syntax recommended by `man sysusers.d` [1]:
Type u may be suffixed with an exclamation mark ("u!") to
create a fully locked account. This is recommended [..]
Changing it to "u" makes it work on systems that *only* have
opensysusers (on other systems the adduser variant will create the IDs
anyhow).
So questions is whether we should change the syntax (although that goes
against the recommendation) or disallow opensysusers as a prereq (and/or
file a bug against that package?).
BR,
--
Gábor (original author of the fix)
[1] https://www.man7.org/linux/man-pages/man5/sysusers.d.5.html
Bug#1108458: unblock: slurm-wlm/24.11.5-3
Control: tags -1 moreinfo Hi, On 29-06-2025 10:19, Gennaro Oliva wrote: [ Reason ] Fix #1104573 I'm not well versed in this systemd stuff, but don't you now have two competing methods? I mean, if both adduser and systemd-sysusers are installed and configured, what will happen? And I guess adduser can be not yet configured if systemd-sysusers is already configured, will the logic in your preinst then do the right thing? Paul OpenPGP_signature.asc Description: OpenPGP digital signature
Bug#1108458: unblock: slurm-wlm/24.11.5-3
Package: release.debian.org Severity: normal User: [email protected] Usertags: unblock X-Debbugs-Cc: [email protected], [email protected] Control: affects -1 + src:slurm-wlm Please unblock package slurm-wlm [ Reason ] Fix #1104573 [ Impact ] Problem installing the package [ Tests ] Usual local tests and autopkgtest successfully run [ Risks ] It only modify maintainers script for installation. No change can affect packages depending on this [ Checklist ] [X] all changes are documented in the d/changelog [X] I reviewed all changes and I approve them [X] attach debdiff against the package in testing unblock slurm-wlm/24.11.5-3 Thanks, -- Gennaro Oliva diffstat for slurm-wlm-24.11.5 slurm-wlm-24.11.5 changelog|7 +++ control |4 ++-- rules|1 + slurm-wlm-basic-plugins.preinst |2 +- slurm-wlm-basic-plugins.sysusers |1 + 5 files changed, 12 insertions(+), 3 deletions(-) diff -Nru slurm-wlm-24.11.5/debian/changelog slurm-wlm-24.11.5/debian/changelog --- slurm-wlm-24.11.5/debian/changelog 2025-06-13 08:21:08.0 +0200 +++ slurm-wlm-24.11.5/debian/changelog 2025-06-27 14:36:03.0 +0200 @@ -1,3 +1,10 @@ +slurm-wlm (24.11.5-3) unstable; urgency=medium + + [ Gábor Németh ] + * Fix preinst adduser (Closes: #1104573) + + -- Gennaro Oliva Fri, 27 Jun 2025 14:36:03 +0200 + slurm-wlm (24.11.5-2) unstable; urgency=medium * Binary upload for contrib diff -Nru slurm-wlm-24.11.5/debian/control slurm-wlm-24.11.5/debian/control --- slurm-wlm-24.11.5/debian/control2025-05-21 08:04:10.0 +0200 +++ slurm-wlm-24.11.5/debian/control2025-06-27 14:32:27.0 +0200 @@ -213,11 +213,11 @@ Package: slurm-wlm-basic-plugins Architecture: any +Pre-Depends: ${misc:Pre-Depends}, systemd-sysusers | adduser Depends: ${shlibs:Depends}, ${misc:Depends}, - libpmix2t64 [amd64 arm64 mips64el ppc64el riscv64 s390x alpha ia64 loong64 ppc64 sparc64], - adduser + libpmix2t64 [amd64 arm64 mips64el ppc64el riscv64 s390x alpha ia64 loong64 ppc64 sparc64] Recommends: slurm-wlm-plugins (= ${binary:Version}), Description: Slurm basic plugins The Slurm Workload Manager is an open-source cluster resource management and diff -Nru slurm-wlm-24.11.5/debian/rules slurm-wlm-24.11.5/debian/rules --- slurm-wlm-24.11.5/debian/rules 2025-05-21 08:04:10.0 +0200 +++ slurm-wlm-24.11.5/debian/rules 2025-06-27 14:32:27.0 +0200 @@ -47,6 +47,7 @@ override_dh_auto_install: dh_auto_install + dh_installsysusers # needed until DH compat 14 # Rename slurm(1) manpage before dh_installman run. It is not possible # to rename manpages in debian/*.manpages so hardcore `mv` is done here diff -Nru slurm-wlm-24.11.5/debian/slurm-wlm-basic-plugins.preinst slurm-wlm-24.11.5/debian/slurm-wlm-basic-plugins.preinst --- slurm-wlm-24.11.5/debian/slurm-wlm-basic-plugins.preinst2025-05-21 08:04:10.0 +0200 +++ slurm-wlm-24.11.5/debian/slurm-wlm-basic-plugins.preinst2025-06-27 14:32:27.0 +0200 @@ -16,7 +16,7 @@ case "$1" in install) - if [ ! $(id -u slurm 2>/dev/null) ]; then + if command -v adduser >/dev/null && [ ! $(id -u slurm 2>/dev/null) ]; then adduser --quiet --system --group --uid 64030 --no-create-home --home /nonexistent slurm fi ;; diff -Nru slurm-wlm-24.11.5/debian/slurm-wlm-basic-plugins.sysusers slurm-wlm-24.11.5/debian/slurm-wlm-basic-plugins.sysusers --- slurm-wlm-24.11.5/debian/slurm-wlm-basic-plugins.sysusers 1970-01-01 01:00:00.0 +0100 +++ slurm-wlm-24.11.5/debian/slurm-wlm-basic-plugins.sysusers 2025-06-27 14:32:27.0 +0200 @@ -0,0 +1 @@ +u! slurm 64030
