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

classic Classic list List threaded Threaded
39 messages Options
12
Reply | Threaded
Open this post in threaded view
|

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

Thomas Goirand-3
Package: systemd
Version: 244-3
Severity: important

Hi,

As I'm packaging opensysusers (see ITP: #947846), I would like my
package to also provide /bin/systemd-sysusers. Please install this
binary on another location, so that both systemd and opensysusers can
implement it. I am very much fine to have systemd have the priority over
opensysusers if you believe it should (I'm open to discussion about
priorities).

Cheers,

Thomas Goirand (zigo)

Reply | Threaded
Open this post in threaded view
|

Bug#947847: Should we standardize with /usr/bin/sysusers ?

Thomas Goirand-3
Hi Michael (and anyone else working on systemd),

To me, it looks like systemd is installing in /usr/bin/systemd-sysusers.
However, opensysusers is installing a binary in /usr/bin/sysusers.
Probably, we should standardize on /usr/bin/sysusers, rather than
/usr/bin/systemd-sysusers, and install alternative on /usr/bin/sysusers
then we can write this in the policy that everyone should use "sysusers"
rather than the specific implementation. I'd then install
/usr/bin/opensysuser-sysusers as the alternative for my package.

Also, opensysusers is providing man pages, but I'm not sure if we should
use them, install alternatives for them as well, or use use the ones
from systemd. Right now, I believe I'd prefer to use the ones from
systemd, as this is what opensysusers references to.

Your thoughts about the 2 points above?

Cheers,

Thomas Goirand (zigo)

Reply | Threaded
Open this post in threaded view
|

Bug#947847: opentmpfiles & opensysusers, and its use in the Debian policy

smcv
In reply to this post by Thomas Goirand-3
On Fri, 03 Jan 2020 at 09:18:58 +0100, Thomas Goirand wrote:
> ... after this discussion, it looks like we would prefer:
> /bin/systemd-tmpfiles and /bin/systemd-sysusers
>
> For this, we need systemd to use update-alternatives for them then, so
> that opentmpfiles & opensysusers do not need to use dpkg divertion.

Would it be simpler to have opentmpfiles (and opensysusers)
Conflicts/Replaces systemd, or even install the different implementations
under different names and make the postinst snippets try one and then
the other? I suspect we are not going to want a third implementation -
if a third implementation was added to the archive it would most likely
be because the OpenRC implementation had become problematic or been
superseded.

Using alternatives seems like an unexpectedly large number of moving
parts for something that, at most, I would expect to only be a sysadmin
choice at the level of "which packages do I install?" rather than "which
of several installed packages do I use?". We've seen with elogind and
its libsystemd0 implementation that offering choices at the bottom of
the dependency stack is hard to get right - I think that applies even
more so if those choices can't be represented in the dependency system.

I think the situations to be supported are:

* System booted with systemd. We should consistently use systemd's
  implementation of these tools, because otherwise, any missing features
  or behaviour differences in opentmpfiles could break systemd units that
  are (quite reasonably) relying on a versioned dependency on
  systemd (>= 321) being sufficient to provide all the interfaces of
  systemd 321.

* System booted with a different init system, or no init system at all
  (chroot or container). Either implementation could be OK; we should
  probably prefer the systemd implementation, because it's the reference
  implementation of these interfaces, but having it be possible to use
  opentmpfiles/opensysusers on Linux would make it easier to prototype
  those packages, even if we end up with only the non-Linux ports
  using them.

On -devel, Sam Hartman has recommended being consistent about which
implementation is used for each port (systemd-tmpfiles for Linux systems,
opentmpfiles for non-Linux), and there's certainly value in that.

> I'd like to understand how /usr/bin/systemd-sysusers got into my system,
> when others are saying they don't have it.

I have no idea. If systemd.deb contained both, then it would be
uninstallable on merged-/usr systems, which we would certainly have
noticed since they are the default for buster's d-i...

Do you have any dpkg diversions or statoverrides that look relevant?

You say they are the same file, which at least probably rules out dpkg
somehow failing to remove a /usr/bin/systemd-sysusers that might have
been shipped by an older systemd package.

    smcv

Reply | Threaded
Open this post in threaded view
|

Bug#947847: opentmpfiles & opensysusers, and its use in the Debian policy

Thomas Goirand-3
In reply to this post by Thomas Goirand-3
Hi Simon,

Thanks for your long message, and engaging in the discussion. I very
much appreciate that it looks like we're engaging in a passionate
technical discussion ! :)

> I think the situations to be supported are:
>
>* System booted with systemd. We should consistently use systemd's
>  implementation of these tools, because otherwise, any missing
>  features or behaviour differences in opentmpfiles could break systemd
>  units that are (quite reasonably) relying on a versioned dependency
>  on systemd (>= 321) being sufficient to provide all the interfaces of
>  systemd 321.

First, my understanding is that tmpfiles isn't there for .service files,
as the systemd units have their own implementation of this (see for
example the directives: RuntimeDirectory=, StateDirectory=,
CacheDirectory=). Do you agree? I have removed the use of these in the
past, because Stretch didn't have the feature (especially,
RuntimeDirectory, I have no experience with the other 2), though it
looks like working well in Buster, no?

Second, it looks like are you saying that only systemd is able to
implement new things. I don't believe that's the case. For example,
upstream in open{sysusers,tmpfiles} could decide to implement a new
feature, or even *us*, on the Debian side of things, could do that. This
would be especially easy with open{sysusers,tmpfiles} because they are
easy to understand shell scripts.

I also don't agree that systemd should have any kind of priority on
other implementation. It doesn't make sense, and this would only makes
Debian look like being obviously biased toward systemd. Let's try to
adopt a pragmatic view on this.

Reasonably, one possible path here, could be to drop the systemd
implementation, if we have at least feature parity, and prefer to avoid
difference of behavior (in such case, the open{tmpfiles,sysusers} would
be superior because working on all platforms). However, it is too early
to have an opinion about this right now (have you tested opemtmpfiles
and opensysusers? how does it compare to the systemd implementation? I
haven't done that work myself yet...).

>* System booted with a different init system, or no init system at all
>  (chroot or container). Either implementation could be OK; we should
>  probably prefer the systemd implementation, because it's the
>  reference implementation of these interfaces, but having it be
>  possible to use opentmpfiles/opensysusers on Linux would make it
>  easier to prototype those packages, even if we end up with only the
>  non-Linux ports using them.
>
> On -devel, Sam Hartman has recommended being consistent about which
> implementation is used for each port (systemd-tmpfiles for Linux
> systems, opentmpfiles for non-Linux), and there's certainly value in
> that.

Sorry to say it this way, but none of the point of argumentation above
look, to my eyes, valid: you aren't saying technically why the systemd
implementation would be better. The only point of argumentation that
you're giving, is that the systemd version is "the reference". This
looks like coming from an emotional feeling rather than a technical
analysis of the problem.

At this point in time, I'd say it is a way too early to be able to tell.
The only thing I'd like to see happen is being able to easily switch
from one implementation to another, so that we can easily test things.
*THEN* (and only then), we can discuss what to do, and what the Debian
policy should look like.

Now, let's go back to the reason why I opened this bug in the first
place: make it possible to switch from one implementation to the other.

There's a few way we can do it:
1- dpkg-divert in open{sysusers,tmpfiles}
2- have systemd split systemd-{sysusers,tmpfiles} into 2 separate packages
3- use update-alternatives

I think that 1- is overkill. Hopefully, you will agree.

The option 2- is probably too much of a micro-packaging practice, which
ftp masters don't really like (and I tend to not like it too). Though if
you are willing to split /bin/systemd-{sysusers,tmpfiles} into a
different package, and then we get open{sysusers,tmpfiles} conflict with
that package, that also works, it is easy to implement, and users will
be able to switch between the 2. However, I very much prefer the use of
update-alternatives, because we can have both installed at once, and
decide to use a specific one if we want to, though I'm ok with
conflicting packages (if that's really your proposal, though I'm not
really sure that it's what you're saying: please clarify).

Which is why I end up preferring option 3-. Which of the 3 options is
your preference? Are you also ok that we decide to use /bin/systemd-X as
the installed alternative? This way, we have nothing else to patch.

Cheers,

Thomas Goirand (zigo)

Reply | Threaded
Open this post in threaded view
|

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

Thomas Goirand-3
In reply to this post by Thomas Goirand-3
On 1/25/20 5:05 PM, Michael Biebl wrote:

> Control: tags -1 + wontfix
>
> Hi Thomas
>
> On Tue, 31 Dec 2019 17:29:29 +0100 Thomas Goirand <[hidden email]> wrote:
>> Package: systemd
>> Version: 244-3
>> Severity: important
>>
>> Hi,
>>
>> As I'm packaging opensysusers (see ITP: #947846), I would like my
>> package to also provide /bin/systemd-sysusers. Please install this
>> binary on another location, so that both systemd and opensysusers can
>> implement it. I am very much fine to have systemd have the priority over
>> opensysusers if you believe it should (I'm open to discussion about
>> priorities).
>
> Thanks for your interest in systemd-sysusers.
> After thinking more about this, I don't consider renaming
> systemd-sysusers and installing it via alternatives as a good idea.
>
> When systemd is installed and used, we definitely want to use its own
> implementation.
>
> My recommendation would be to install the opensysusers implementation
> under a different binary name.
>
> Alternative init systems can then decide to support sysusers by calling
> that opensysusers binary during boot.
> debhelper, should it get sysusers support, should generate code which
> calls the correct binary depending on the  current circumstances.
>
> Regards,
> Michael
>
>
>

Hi Michael,

It is my view that what you're proposing would be a lot more work for on
valid reason. I'm therefore re-assigning the bug to the tech-ctte,
asking them to decided instead.

It is my view that using update-alternatives is *very* easy to
implement, so that we can share the /usr/bin/systemd-sysuser location.

Besides the fact that, with the way you're suggesting, we'd need to fix
debhelper (which I don't think is reasonable, as it wont be the only
place to handle multiple cases, I'm foreseeing...), there's also the
concern that you don't seem to agree that it'd be ok for one to use
opensysuser instead of the systemd implementation if systemd is running.
I do not agree with this, and I believe it is up to the users to decide
what to do, even if we, as an operating system, must provide sensible
defaults (which also can be discussed, but that's not the point of this
bug report).

Moreover, I don't see why /usr/bin/systemd-sysusers would be any
different from let's say /usr/bin/awk. The update-alternatives system is
there exactly to handle the case we're facing today.

So, tech-ctte, please decide.

Cheers,

Thomas Goirand (zigo)

Reply | Threaded
Open this post in threaded view
|

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

Michael Biebl-3
Am 27.01.20 um 11:18 schrieb Thomas Goirand:

> It is my view that what you're proposing would be a lot more work for on
> valid reason.

opensysusers as implementation will always lag behind systemd-sysusers
and/or be incomplete, it might even be incompatible.
This has the potential to negatively effect a systemd installation
leading to a less robust system. Those issues will likely be hard to
diagnose where we as maintainers have to spend time which would be
better spent elsewhere.
And all that for what? I don't see a compelling use case why swapping
out the native reference implementation and running a combination which
is untested (and unsupported by systemd upstream) would be a good idea.

Regards,
Michael


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Anthony DeRobertis
In reply to this post by Thomas Goirand-3
It's different than awk because the decision the admin is making ("which
init system do I want to run"?) isn't done through alternatives. So you
can't use the alternatives system to coordinate swapping all the
different bits together.

It seems retty reasonable to me that the systemd maintainers don't want
to support systems which are running arbitrary combinations of systemd
with alternatives to some parts. And that a package with a Depends on a
particular systemd version should be able to depend on features from
that version; alternatives would allow an old version of opensysusers to
be used instead (unless systemd kept adding conflicts against
opensysusers whenever they add a new feature, something I doubt anyone
would be happy with).

Strikes me as there is a possible solution, though: have opensysusers
dpkg-divert it and put a shell script in its place that checks which
init system is running, and exec's the right sysusers based on that.
This wouldn't affect systemd-only machines (as opensysusers would not be
installed at all), and would do the right thing if someone has installed
two init systems to, e.g., consider switching. It'd need to be a script
that the systemd maintainers feel reasonably confident will always run
systemd's implementation when systemd is running, to avoid the mixed
implementations issue.

(Of course, there is the problem with temporarily having no file
there... but I suspect that could be documented around as the lesser of
evils. Especially if done with --no-rename, so it'd be a very short time.)

Reply | Threaded
Open this post in threaded view
|

Bug#947847: [Fwd: Re: Bug#947847: please install systemd-sysusers using update-alternatives]

Svante Signell-2
In reply to this post by Thomas Goirand-3



On Mon, 2020-01-27 at 11:01 -0500, Anthony DeRobertis wrote:
>
> Strikes me as there is a possible solution, though: have opensysusers
> dpkg-divert it and put a shell script in its place that checks which
> init system is running, and exec's the right sysusers based on that.

It is as simple as:
if ps -p1|grep -q "systemd"; then
 <install systemd-{sysusers,tmpfiles]>
else
 <install open{sysusers,tmpfiles}>
fi

> This wouldn't affect systemd-only machines (as opensysusers would not be
> installed at all), and would do the right thing if someone has installed
> two init systems to, e.g., consider switching. It'd need to be a script
> that the systemd maintainers feel reasonably confident will always run
> systemd's implementation when systemd is running, to avoid the mixed
> implementations issue.



Reply | Threaded
Open this post in threaded view
|

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

Michael Biebl-3
In reply to this post by Michael Biebl-3
Am 27.01.20 um 14:19 schrieb Michael Biebl:

> Am 27.01.20 um 11:18 schrieb Thomas Goirand:
>
>> It is my view that what you're proposing would be a lot more work for on
>> valid reason.
>
> opensysusers as implementation will always lag behind systemd-sysusers
> and/or be incomplete, it might even be incompatible.
> This has the potential to negatively effect a systemd installation
> leading to a less robust system. Those issues will likely be hard to
> diagnose where we as maintainers have to spend time which would be
> better spent elsewhere.
> And all that for what? I don't see a compelling use case why swapping
> out the native reference implementation and running a combination which
> is untested (and unsupported by systemd upstream) would be a good idea.
I'm not subscribed to this bug report, so if the CTTE want's further
feedback on this issue from my side, please CC me.

Michael


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Thomas Goirand-3
In reply to this post by Thomas Goirand-3

Anthony DeRobertis <[hidden email]>
> It's different than awk because the decision the admin is making
> ("which init system do I want to run"?) isn't done through
> alternatives. So you can't use the alternatives system to coordinate
> swapping all the different bits together.

You are mixing things here. We are *not* talking about init systems, but
about sysusers, which can be used with any init systems.

> It seems retty reasonable to me that the systemd maintainers don't
> want to support systems which are running arbitrary combinations of
> systemd with alternatives to some parts.

Absolutely nobody is asking them to do that. I'm just asking for a
solution to easily replace /bin/systemd-sysusers. There are 2 solutions,
one is to have /bin/systemd-sysusers packaged separately, though this
would probably be micro-packaging, which I'm not a fan of. The other
solution is to use update-alternatives. I'm fine with both solution, I
just don't think it's fine to say "get away, my implementation is
better", and leave no reasonable solution to install something else.

> Strikes me as there is a possible solution, though: have opensysusers
> dpkg-divert it and put a shell script in its place that checks which
> init system is running, and exec's the right sysusers based on that.

This is exactly what should be avoided. It's perfectly fine to try to
use opensysusers with systemd if one wants. In fact, that's exactly the
best way we could do to be able to test it. Also, dpkg-divert is really
ugly, and something you use as the last resort, when all other options
have been exhausted.

> This wouldn't affect systemd-only machines (as opensysusers would not
> be installed at all), and would do the right thing if someone has
> installed two init systems to, e.g., consider switching.

Again, you are mixing things (ie: what type of init system and
re-implementation of an independent component of systemd). We should be
able to allow to run opensysusers if systemd is running (exactly, why
not?). This is desirable, at least for testing. It would also be
desirable to use systemd-sysusers with other init system if one wants
(also: why not?).

> It'd need to be a script that the systemd maintainers feel reasonably
> confident will always run systemd's implementation when systemd is
> running, to avoid the mixed implementations issue.

Not at all. Systemd maintainers have no say if someone wishes to
implement things in another way, the same way there's gawk and mawk,
implementing the same thing. If we don't allow such things, then really,
Debian is doomed.

I am not buying into the "we will have wrong bug reports" argument. We
constantly get many types of wrong reports in the BTS. We just shall do
sensible bug triaging in a correct way, that's it.

Cheers,

Thomas Goirand (zigo)

P.S: Note that this bug also concerns systemd-tmpfiles, the very exact
same way, though I believe one single bug is enough to address both
cases which are similar.

Reply | Threaded
Open this post in threaded view
|

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

Philipp Kern-6
On 1/28/2020 1:33 PM, Thomas Goirand wrote:
>> It'd need to be a script that the systemd maintainers feel reasonably
>> confident will always run systemd's implementation when systemd is
>> running, to avoid the mixed implementations issue.
>
> Not at all. Systemd maintainers have no say if someone wishes to
> implement things in another way, the same way there's gawk and mawk,
> implementing the same thing. If we don't allow such things, then really,
> Debian is doomed.

The interface in question here is "awk". So if the interface would be a
hypothetical "update-sysusers", then this could be shared with
alternatives. I completely understand the view of the systemd
maintainers that "systemd-sysusers" as a binary should be provided by
their package rather than an alternative.

>> Strikes me as there is a possible solution, though: have opensysusers
>> dpkg-divert it and put a shell script in its place that checks which
>> init system is running, and exec's the right sysusers based on that.
>
> This is exactly what should be avoided. It's perfectly fine to try to
> use opensysusers with systemd if one wants. In fact, that's exactly the
> best way we could do to be able to test it. Also, dpkg-divert is really
> ugly, and something you use as the last resort, when all other options
> have been exhausted.

If the problem here is that everything embeds a call to systemd-sysusers
directly and you want to provide a different intermediate interface
eventually then diverting it as a workaround in the meantime seems sound
to me, no?

So far I see you present a single option rather than trying to negotiate
within the option space. Good escalations are not "Moreover, I don't see
why /usr/bin/systemd-sysusers would be any different from let's say
/usr/bin/awk." but trying to present the two opposing viewpoints and
potential solutions to them.

Kind regards
Philipp Kern

Reply | Threaded
Open this post in threaded view
|

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

Raphael Hertzog-3
In reply to this post by Thomas Goirand-3
On Tue, 28 Jan 2020, Thomas Goirand wrote:
> This is exactly what should be avoided. It's perfectly fine to try to
> use opensysusers with systemd if one wants. In fact, that's exactly the
> best way we could do to be able to test it. Also, dpkg-divert is really
> ugly, and something you use as the last resort, when all other options
> have been exhausted.

It's not that ugly if you consider that you are in an experimental phase
where you want to test opensysusers.

Also you seem to imply that the common interface is the systemd-sysusers
binary. I don't think that this is necessarily the case. The common
interface is the file format. The name of the program creating the users
is not important as long as it's properly hooked in the packaging system
and boot sequence.

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

Reply | Threaded
Open this post in threaded view
|

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

Thomas Goirand-3
On 1/29/20 11:34 AM, Raphael Hertzog wrote:

> On Tue, 28 Jan 2020, Thomas Goirand wrote:
>> This is exactly what should be avoided. It's perfectly fine to try to
>> use opensysusers with systemd if one wants. In fact, that's exactly the
>> best way we could do to be able to test it. Also, dpkg-divert is really
>> ugly, and something you use as the last resort, when all other options
>> have been exhausted.
>
> It's not that ugly if you consider that you are in an experimental phase
> where you want to test opensysusers.
>
> Also you seem to imply that the common interface is the systemd-sysusers
> binary. I don't think that this is necessarily the case. The common
> interface is the file format. The name of the program creating the users
> is not important as long as it's properly hooked in the packaging system
> and boot sequence.

Hi Raphael,

I'm replying to you, but it goes also for Phillip Kern too, which had a
similar answer.

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 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

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:

echo 'u radvd - "radvd daemon"' | \
   systemd-sysusers --replace=/usr/lib/sysusers.d/radvd.conf

which clearly, looks like something someone would write in a shell
script, manually calling /bin/systemd-sysusers, from anywhere, maybe
even from a running program / daemon (I haven't seen any designed
limitation, have you?).

So I am in the opinion that "as long as it's properly hooked in the
packaging system and boot sequence" simply doesn't work in this case, as
systemd-sysusers could be called from virtually anywhere.

As for the use of dpkg-divert, as you wrote above, it's ok for
experimentation, but I do think it's making a disservice to our users to
use that as the proper interface to implement. The update-alternatives
has the very nice advantage that it clearly shows the current status of
the system, and that it can be very easily tweaked, by hand or by some
kind of automation. It's also super easy to go from one state of the
system to another, compared to reinstalling / uninstalling a package.

Cheers,

Thomas Goirand (zigo)

Reply | Threaded
Open this post in threaded view
|

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

Raphael Hertzog-3
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 <[hidden email]>
  ⣾⠁⢠⠒⠀⣿⡁
  ⢿⡄⠘⠷⠚⠋    The Debian Handbook: https://debian-handbook.info/get/
  ⠈⠳⣄⠀⠀⠀⠀   Debian Long Term Support: https://deb.li/LTS

Reply | Threaded
Open this post in threaded view
|

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

Thomas Goirand-3
On 1/29/20 1:50 PM, Raphael Hertzog wrote:
> 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?

Yes it does.

> There's no need to predict the future, you must analyze the
> current situation and go forward from there.

Of course we are planning for the future. Let's say an important feature
appears to be needed (this is just a point or argumentation at this
time, please everyone: don't add unnecessary FUD), then of course, it's
always possible to fill the gap and implement the missing feature. The
clear goal is for opensysusers to become a full replacement of the
systemd implementation.

> 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 intend is for opensysusers to be a full replacement, I don't see why
we should bother users with some annoying debconf prompt that they
probably wont be able to understand without a an extensive knowledge of
the situation.

> 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.

I'm unsure what your above proposal is, so let's expand a little bit.
Sorry if it appears I'm distorting your words (that's not the intent).

This reasoning can make sense, if we agree that we should use something
else than /bin/systemd-sysusers and standardize on something else like
/bin/sysusers. Then we modify the Debian policy that /bin/sysusers is
*the* way to do things, and using /bin/systemd-sysusers becomes a bug of
severity "serious" (policy violation).

However, imposing everyone (for current or future use of sysusers) to
handle a specific case for opensysusers is IMO *not* the way to go. And
this is the very point of this bug entry.

Cheers,

Thomas Goirand (zigo)

Reply | Threaded
Open this post in threaded view
|

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

Didier 'OdyX' Raboud-5
In reply to this post by Thomas Goirand-3
Le mercredi, 29 janvier 2020, 12.41:52 h CET Thomas Goirand a écrit :
> I'm replying to you, but it goes also for Phillip Kern too, which had a
> similar answer.

Only words, I know, but let's try to answer technical points, not address
people. "Talk to the space, not to individuals"
 
> 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.

Software installed as /bin/systemd-* , created within the systemd project, to
fulfill systemd's view of the world, takes a reasonable hit on the binaries'
namespace: "systemd-*". Really, we should be thankful that the systemd project
actually started using /bin/systemd-sysusers and not just /bin/sysusers. To
extend on this, I think it's obvious that what the "systemd-sysusers" binary
name _says_ really is "this is a systemd-specific utility".

I'm of the opinion that noone should be allowed to take over this
/usr/bin/systemd-sysusers path, indeed. Much like I don't think anyone should
be allowed to provide an alternative to /usr/sbin/cupsd.

Let's see if I understand what you want correctly; you want Debian to allow
replacing systemd-specific software with alternatives, right? I'm sorry, but
this does not make any sense to me: /bin/systemd-sysusers _is_ systemd-
specific, and is used as such by systemd. If usages of it have appeared
outside of the systemd repository, I think it's fair to say (because of the
binary's name) that they were knowingly using a systemd-specific piece of
software (and hence, have correctly added a "{Pre-,}Depends: systemd".

Note that I'm not saying that /bin/systemd-sysusers _cannot_ be used without
systemd, or on a host booted with a different init system; I'm only saying
that usages of systemd-sysusers must have appeared with full knowledge of
using the systemd-sysusers binary from the systemd project.

> So I am in the opinion that "as long as it's properly hooked in the
> packaging system and boot sequence" simply doesn't work in this case, as
> systemd-sysusers could be called from virtually anywhere.

That's exactly the point: if it's so good that it has become used in many
places, changing the binary behind the scenes is clearly premature at this
point.

If I reformulate what it seems to me you're asking, it comes accross to me as
"/bin/systemd-sysusers comes from systemd and it should be possible to have a
system without systemd installed, therefore please force the systemd
maintainers to allow hosts to have a non-systemd /bin/systemd-sysusers".

My answer to this is that /bin/systemd-sysusers _is_ a systemd interface, with
a systemd-* name and I don't think it's reasonable to ask (or force) the
systemd maintainers to allow "their" interface to be implemented by other
software projects. Afterall, they came with the idea first, in their
namespace.

That said, taking a step back and looking at the larger picture, if what you
wish is a Debian in which one can pick their preferred sysusers'
implementation, what about discussing the pertinence of a "parent"
/bin/sysusers; with alternatives' setup there? (I wouldn't be surprised if the
systemd maintainers agreed to register /bin/systemd-sysusers as alternative to
/bin/sysusers).

With this in place, you could go to maintainers who _have_ already used
/bin/systemd-sysusers to try convince them to use the /bin/sysusers "standard"
interface instead. We have this for 'httpd', 'default-mta', what about having
a virtual 'sysusers' ?

All-in-all, I think the question you're asking is misguided: it's not because
we technically _can_ allow any /bin/systemd-* to be provided by another
implementation, that we should (actually, I think we should clearly _not_).
But not having a /bin/systemd-sysusers' implementation that can be toggled in-
place through alternatives doesn't hinder you from proving that the competing
implementation is better (faster, less systemd, etc); there are various ways
to do this; dpkg-divert, another non-"systemd-*" parent alternative, or
others. If /usr/bin/opensysusers-sysusers is really that good, have you tried
talking to maintainers using /bin/systemd-sysusers to see if they would like
to swap to it? It's not like having two competing implementations causes much
harm here.

Cheers,
    OdyX

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Didier 'OdyX' Raboud-5
In reply to this post by Thomas Goirand-3
Le mercredi, 29 janvier 2020, 16.07:21 h CET Thomas Goirand a écrit :
> This reasoning can make sense, if we agree that we should use something
> else than /bin/systemd-sysusers and standardize on something else like
> /bin/sysusers. Then we modify the Debian policy that /bin/sysusers is
> *the* way to do things, and using /bin/systemd-sysusers becomes a bug of
> severity "serious" (policy violation).

We'd first have to agree that an alternative is actually _needed_. And so far,
the only arguments I have read in favour of providing alternatives to
/bin/systemd-sysusers are:
* A) it is shipped in the systemd binary package;
* B) Having competing implementations is important;
* C) it comes from the systemd project;
* D) it has a systemd-* name;

Out of these, A is the most convincing, B is mildly so; C & D are absolutely
irrelevant IMHO. If you're concerned by A, the request becomes:
> Please ship systemd-sysusers in a separate package for finer granularity and
> smaller installation size for non-systemd systems

If you're concerned by B, I don't think you need anything from systemd; just
convince enough maintainers that a non-systemd implementation is important,
and get them to change their scripts and dependencies to opensysusers. If you
really want a single sysusers implementation per system (what's the argument
there?), then go the /usr/bin/sysusers alternatives' route, and convince
maintainers to move to that virtual package.

--
    OdyX

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Svante Signell-2
On Wed, 2020-01-29 at 16:49 +0100, Didier 'OdyX' Raboud wrote:

> We'd first have to agree that an alternative is actually _needed_.
> And so far,
> the only arguments I have read in favour of providing alternatives to
> /bin/systemd-sysusers are:
> * A) it is shipped in the systemd binary package;
> * B) Having competing implementations is important;
> * C) it comes from the systemd project;
> * D) it has a systemd-* name;

* E) systemd is not available on non-Linux

Reply | Threaded
Open this post in threaded view
|

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

Bastian Blank
On Wed, Jan 29, 2020 at 05:06:31PM +0100, Svante Signell wrote:
> * E) systemd is not available on non-Linux

- You don't need an alternative for something that does not exist.
- Have you ever tried to build those parts of the systemd package on
  your favorite glibc non-Linux?

Bastian

--
There's another way to survive.  Mutual trust -- and help.
                -- Kirk, "Day of the Dove", stardate unknown

Reply | Threaded
Open this post in threaded view
|

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

Gunnar Wolf via nm
In reply to this post by Didier 'OdyX' Raboud-5
I just want to subscribe with a very big +1 to what OdyX has said here:

Didier 'OdyX' Raboud dijo [Wed, Jan 29, 2020 at 04:31:09PM +0100]:

> (...)
> > So I am in the opinion that "as long as it's properly hooked in the
> > packaging system and boot sequence" simply doesn't work in this case, as
> > systemd-sysusers could be called from virtually anywhere.
>
> That's exactly the point: if it's so good that it has become used in many
> places, changing the binary behind the scenes is clearly premature at this
> point.
>
> If I reformulate what it seems to me you're asking, it comes accross to me as
> "/bin/systemd-sysusers comes from systemd and it should be possible to have a
> system without systemd installed, therefore please force the systemd
> maintainers to allow hosts to have a non-systemd /bin/systemd-sysusers".
>
> My answer to this is that /bin/systemd-sysusers _is_ a systemd interface, with
> a systemd-* name and I don't think it's reasonable to ask (or force) the
> systemd maintainers to allow "their" interface to be implemented by other
> software projects. Afterall, they came with the idea first, in their
> namespace.
>
> That said, taking a step back and looking at the larger picture, if what you
> wish is a Debian in which one can pick their preferred sysusers'
> implementation, what about discussing the pertinence of a "parent"
> /bin/sysusers; with alternatives' setup there? (I wouldn't be surprised if the
> systemd maintainers agreed to register /bin/systemd-sysusers as alternative to
> /bin/sysusers).
>
> With this in place, you could go to maintainers who _have_ already used
> /bin/systemd-sysusers to try convince them to use the /bin/sysusers "standard"
> interface instead. We have this for 'httpd', 'default-mta', what about having
> a virtual 'sysusers' ?
>
> All-in-all, I think the question you're asking is misguided: it's not because
> we technically _can_ allow any /bin/systemd-* to be provided by another
> implementation, that we should (actually, I think we should clearly _not_).
> But not having a /bin/systemd-sysusers' implementation that can be toggled in-
> place through alternatives doesn't hinder you from proving that the competing
> implementation is better (faster, less systemd, etc); there are various ways
> to do this; dpkg-divert, another non-"systemd-*" parent alternative, or
> others. If /usr/bin/opensysusers-sysusers is really that good, have you tried
> talking to maintainers using /bin/systemd-sysusers to see if they would like
> to swap to it? It's not like having two competing implementations causes much
> harm here.
/usr/bin/systemd-* is clearly implementation-specific. Now, if we are
to allow alternative implementations of /usr/bin/systemd-brewmycoffee,
we should first push to an alternative /usr/bin/brewmycoffee, get the
systemd maintainers to "subscribe" to it using our great alternatives
system, and provide our /usr/bin/open-brewmycoffee.

And I think that now, that not so many packages have yet adopted
systemd-derived facilities, is a great time to set this as a good
practice.

signature.asc (235 bytes) Download Attachment
12