[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#947847: please install systemd-sysusers using update-alternatives



On Wed, 29 Jan 2020, Thomas Goirand wrote:
> echo 'u radvd - "radvd daemon"' | \
>    systemd-sysusers --replace=/usr/lib/sysusers.d/radvd.conf

Does opensysusers support this use case?

If not, you just provided a good reason why it's not a good idea
to use an alternative for systemd-sysusers.

> My idea is to have a single entry point for programs to call the
> sysusers binary. If we collectively decide that it's going to be called
> /bin/foo, then by all means, let's do that. But I don't think it's
> reasonable to say it's going to be called /bin/systemd-bar, and nobody
> can take over this path. This is the wrong answer to the problem.

I do believe it's not a good idea to reuse a systemd binary name for a
generic API, even if that API is a subset of what's provided by
systemd-sysusers.

> I do agree that the data file is the interface, but can you predict
> *ALL* the cases where /bin/systemd-sysusers is called? As much as I
> understand, it could be called by:
> - something debhelper adds to postinst
> - something the maintainer adds manually to postinst
> - the init system itself

There's no need to predict the future, you must analyze the
current situation and go forward from there. AFAIK, we don't have
anything at the debhelper level yet and we can define that debhelper
will call your new /bin/foo^Wcreate-system-users. As for the
service creating users during boot, you can provide a debconf
question giving the option to the user to install an override
of systemd-sysusers.service which actually calls opensysusers.
The question would not be shown by default and would default
to not override systemd-sysusers. It would also not be shown
if systemd is not used.

> And more disturbingly, it could be called by any program that just wants
> to add a user the same way one would just call useradd or adduser. The
> man page for systemd-sysusers even gives a very clear example:

Given that both programs are doing the same thing based on the same input,
I don't see any problem in that. We have dependencies to ensure that
programs are available.

And when we get to the point where the lack of systemd-sysuvers is a
problem, we can always patch programs to use /bin/create-system-users
instead of systemd-sysusers.

Cheers,
-- 
  ⢀⣴⠾⠻⢶⣦⠀   Raphaël Hertzog <hertzog@debian.org>
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋    The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄⠀⠀⠀⠀   Debian Long Term Support: https://deb.li/LTS


Reply to: