Your message dated Sun, 30 Nov 2025 00:12:30 +0100
with message-id <[email protected]>
and subject line Re: Bug#1100564: postinst could be way easier regarding user
creation
has caused the Debian Bug report #1100564,
regarding postinst could be way easier regarding user creation
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
1100564: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1100564
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: python3-swift
Version: 2.34.0-5
Severity: wishlist
Hi,
this is unsolicited advice from the adduser maintainer. Please use it at
your discretion.
python3-swift's postinst is a rather complex beast. It could be easier
regarding adduser, since the postinst duplicates a lot of the safety
mechanism that adduser already offers.
You implement a lot of flexibility, allowing a caller to override the
swift user's home directory and its shell. However, python3-swift is the
first use case of adduser I see with a pre-allocated static uid/gid, and
this has given us as the adduser team important input to improve our
tests and checking of input data.
adduser's man page from bookworm:
| If called with one non-option argument and the --system option,
| adduser will add a dynamically allocated system user, often
| abbreviated as system user in the context of the adduser package.
|
| adduser will choose the first available UID from the range specified
| by FIRST_SYSTEM_UID and LAST_SYSTEM_UID in the configuration file.
| This can be overridden with the --uid option.
|
| By default, system users are placed in the nogroup group. To place
| the new system user in an already existing group, use the --gid or
| --ingroup options. If the --group is given and the identically named
| group does not already exist, it is created with the same ID.
|
| If no home directory is specified, the default home directory for a
| new system user is /nonexistent. This di‐ rectory should never exist
| on any Debian system, and adduser will never create it automatically.
|
| Unless a shell is explicitly set with the --shell option, the
| new system user will have the shell set to /usr/sbin/nologin. adduser
| --system does not set a password for the new account. Skeletal
| configuration files are not copied.
If you can live with the shell always being set to /usr/sbin/nologin,
you can remove the --shell option completely.
adduser --system defaults to --home /nonexistent. If you actually need
the home directory of the user set to /var/lib/${VAR_UG_PKG_NAME},
you'll need to continue using the --home option. If your user doesn't
need a formal home directory, changing to /nonexisting might be easier
here.
The --quiet option should be no longer needed in trixie (you still need
it during upgrades if you can't live with the probably not yet upgraded
adduser talking on the console during the upgrade).
The --disabled-password option is redundant with --system, the user is
always created without password.
The getent bracket you put around your adduser call is not needed any
more in trixie, adduser is idempotent.
Your forcing the shell of the user to ${VAR_UG_SHELL} is probably a
policy violation as you might overwrite a configuration change done by
the local admin. I'd think about removing that.
Sadly, you still need the explicit creation of the group. We're working
on that and will probably fix that before trixie.
If you have any questions in regard of what adduser does to make your
life as package maintainer easier, or have comments, please get in touch
with [email protected] or file a bug against adduser.
Greetings
Marc
--- End Message ---
--- Begin Message ---
On 3/15/25 11:41 AM, Marc Haber wrote:
Package: python3-swift
Version: 2.34.0-5
Severity: wishlist
Hi,
this is unsolicited advice from the adduser maintainer. Please use it at
your discretion.
python3-swift's postinst is a rather complex beast. It could be easier
regarding adduser, since the postinst duplicates a lot of the safety
mechanism that adduser already offers.
You implement a lot of flexibility, allowing a caller to override the
swift user's home directory and its shell. However, python3-swift is the
first use case of adduser I see with a pre-allocated static uid/gid, and
this has given us as the adduser team important input to improve our
tests and checking of input data.
adduser's man page from bookworm:
| If called with one non-option argument and the --system option,
| adduser will add a dynamically allocated system user, often
| abbreviated as system user in the context of the adduser package.
|
| adduser will choose the first available UID from the range specified
| by FIRST_SYSTEM_UID and LAST_SYSTEM_UID in the configuration file.
| This can be overridden with the --uid option.
|
| By default, system users are placed in the nogroup group. To place
| the new system user in an already existing group, use the --gid or
| --ingroup options. If the --group is given and the identically named
| group does not already exist, it is created with the same ID.
|
| If no home directory is specified, the default home directory for a
| new system user is /nonexistent. This di‐ rectory should never exist
| on any Debian system, and adduser will never create it automatically.
|
| Unless a shell is explicitly set with the --shell option, the
| new system user will have the shell set to /usr/sbin/nologin. adduser
| --system does not set a password for the new account. Skeletal
| configuration files are not copied.
If you can live with the shell always being set to /usr/sbin/nologin,
you can remove the --shell option completely.
adduser --system defaults to --home /nonexistent. If you actually need
the home directory of the user set to /var/lib/${VAR_UG_PKG_NAME},
you'll need to continue using the --home option. If your user doesn't
need a formal home directory, changing to /nonexisting might be easier
here.
The --quiet option should be no longer needed in trixie (you still need
it during upgrades if you can't live with the probably not yet upgraded
adduser talking on the console during the upgrade).
The --disabled-password option is redundant with --system, the user is
always created without password.
The getent bracket you put around your adduser call is not needed any
more in trixie, adduser is idempotent.
Your forcing the shell of the user to ${VAR_UG_SHELL} is probably a
policy violation as you might overwrite a configuration change done by
the local admin. I'd think about removing that.
Sadly, you still need the explicit creation of the group. We're working
on that and will probably fix that before trixie.
If you have any questions in regard of what adduser does to make your
life as package maintainer easier, or have comments, please get in touch
with [email protected] or file a bug against adduser.
Greetings
Marc
Hi Marc,
I carefully read, and read again all of your remarks above. If you
didn't know, swift's postinst is only calling what's in
openstack-pkg-tools, and which is used by *ALL* OpenStack packages.
In the case of swift, there's no need for a shell, but for example, Nova
needs one, and pkgos_adduser() will be called with a shell as argument
by nova-common.postinst. Changing that logic isn't IMO a good idea.
I don't think anyone will want to change the default swift shell, and I
wouldn't agree with the policy mandating it to be customizable.
I cannot do any of the changes that wont be backward compatible to at
least Bullseye, so all of your suggestions for Trixie are a bad idea for me.
At the end, the only thing which is actionable would be removing
--disabled-password, though if it's there and not annoying, I don't see
the point removing it and taking the time to rebuild all OpenStack
services just for it.
Anyways, thanks for this bug report, I've learn new stuff!
Cheers,
Thomas Goirand (zigo)
--- End Message ---
