Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Bug#981937: dh-sysuser: Reduce negative impact and assess overall utility
72 views
Skip to first unread message
Lorenzo Puliti
Feb 5, 2021, 4:20:03 AM2/5/21
to
Package: dh-sysuser
Version: 1.3.5
Severity: wishlist
X-Debbugs-Cc: plor...@disroot.org
Note: CC Helmut Grohne as he started the discussion,
CC Niels Thykier as he might want to say something here
Helmut Grohne <hel...@subdivi.de>, from #981683:
> Further development seems like a good idea. The package uses useradd
> instead of the policy-recommended adduser. Is there a good reason for
> doing so? The approach taken here entirely sidesteps the established and
> declarative sysusers.d format. Is there a reason for not cooperating
> with it? Niels Thykier is working a lot on removing maintainer scripts
> and turning them into declarative alternatives such as triggers.
> dh-sysusers works towards the opposite. Why? As far as I can tell,
> project consensus is that system users should not be removed on purge,
> but dh-sysuser does so. From my subjectively skewed perception,
> dh-sysuser has only created problems, not solved any. I acknowledge that
> this is not the whole picture.
Short answer:
Given that this is an alternative implementation for creating system users
related to an alternitive init system, and given the last GR results, it
make sense to drive the development of this package in a way that shift the
burden from Debian infrastructure and contributors to this package maintainance,
whenever this is possible.
If dh-sysuser creates problem, then people affected need to report bugs about that.
There is nothing i can and i will do if i'm not even aware of the existence
of an issue [ this package had 0 bug reported until the beginning of 2021].
I've already opened bugs for the 'adduser'and the 'remove on purge' issues,
but that's not the kind of bugs we are talking about.
Long answer:
Following the last GR, the overall state of 'creating system users' in Debian
is getting messy, currently we have
* systemd-sysusers [systemd package]:
this is destructive on systems with an alternative init system, as installing
systemd package will likely remove your Desktop Environment (due to conflict with
elogind). This was one of the reason for the existence of dh-sysuser at least
at the beginning
* opensysusers:
in Debian only since 2020; i'm doing some QA maintainance on it to allow it's inclusion
in Bullseye. Supposed to work fine with alternative init systems, possibly also with
systemd although this setup is not tested (and not sure someone is interested in this)
* dh-sysuser: alternative declarative interface to handle creation and removal of
users; known to work both with systemd and alternative init systems.
It's part of the runit infrastructure.
* systemd-standalone-sysusers [ future package ]
currently does not exists, not sure when it will, but has been discussed in TC list
and some other bug too. Will work fine for alternative init systems.
Not sure if it will work on BSD port, wich is relevant for runit
As of my personal efforts:
I plan to stop doing QA on opensysusers if the standalone package from systemd proves to
works fine on all cases that I care (including BDS port). At that point someone else steps
in for opensysusers or the package will end up removed (or limited to BDS port).
I don't plan to drop dh-sysuser soon as I may need it for runit future development.
More about dh-sysuser:
> doing so? The approach taken here entirely sidesteps the established and
> declarative sysusers.d format. Is there a reason for not cooperating
> with it? Niels Thykier is working a lot on removing maintainer scripts
> and turning them into declarative alternatives such as triggers.
> dh-sysusers works towards the opposite.
I don't see it that way, maybe I'm missing something?
It's declarative and it parses a file in the source.
It allows me to fix things uploading a new version of sysuser-helper,
without the need to rebuild the affected package from source.
It's probably able to handle many kind of transition without requiring
coordination form others maintainers (I guess I will find out soon if it
works as expected with the Merged-usr transition).
Also (looking at the patch from #981799) I don't see a clear advantage
of systemd-sysusers in simlpifying syntax of rules or other files in the
/debian directory.
One notable difference is that dh-sysuser parses on buildtime while
systemd-sysusers parses on runtime, but for Debian I'm not sure what can
be the advantage of one approach versus the other.
I plan to keep this bug open for the next release cycle so there is time
for people to highlight bug or other problems with this package.
Regards,
Lorenzo
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)
Versions of packages dh-sysuser depends on:
ii perl 5.32.0-6
dh-sysuser recommends no packages.
dh-sysuser suggests no packages.
-- no debconf information
Version: 1.3.5
Severity: wishlist
X-Debbugs-Cc: plor...@disroot.org
Note: CC Helmut Grohne as he started the discussion,
CC Niels Thykier as he might want to say something here
Helmut Grohne <hel...@subdivi.de>, from #981683:
> Further development seems like a good idea. The package uses useradd
> instead of the policy-recommended adduser. Is there a good reason for
> doing so? The approach taken here entirely sidesteps the established and
> declarative sysusers.d format. Is there a reason for not cooperating
> with it? Niels Thykier is working a lot on removing maintainer scripts
> and turning them into declarative alternatives such as triggers.
> dh-sysusers works towards the opposite. Why? As far as I can tell,
> project consensus is that system users should not be removed on purge,
> but dh-sysuser does so. From my subjectively skewed perception,
> dh-sysuser has only created problems, not solved any. I acknowledge that
> this is not the whole picture.
Short answer:
Given that this is an alternative implementation for creating system users
related to an alternitive init system, and given the last GR results, it
make sense to drive the development of this package in a way that shift the
burden from Debian infrastructure and contributors to this package maintainance,
whenever this is possible.
If dh-sysuser creates problem, then people affected need to report bugs about that.
There is nothing i can and i will do if i'm not even aware of the existence
of an issue [ this package had 0 bug reported until the beginning of 2021].
I've already opened bugs for the 'adduser'and the 'remove on purge' issues,
but that's not the kind of bugs we are talking about.
Long answer:
Following the last GR, the overall state of 'creating system users' in Debian
is getting messy, currently we have
* systemd-sysusers [systemd package]:
this is destructive on systems with an alternative init system, as installing
systemd package will likely remove your Desktop Environment (due to conflict with
elogind). This was one of the reason for the existence of dh-sysuser at least
at the beginning
* opensysusers:
in Debian only since 2020; i'm doing some QA maintainance on it to allow it's inclusion
in Bullseye. Supposed to work fine with alternative init systems, possibly also with
systemd although this setup is not tested (and not sure someone is interested in this)
* dh-sysuser: alternative declarative interface to handle creation and removal of
users; known to work both with systemd and alternative init systems.
It's part of the runit infrastructure.
* systemd-standalone-sysusers [ future package ]
currently does not exists, not sure when it will, but has been discussed in TC list
and some other bug too. Will work fine for alternative init systems.
Not sure if it will work on BSD port, wich is relevant for runit
As of my personal efforts:
I plan to stop doing QA on opensysusers if the standalone package from systemd proves to
works fine on all cases that I care (including BDS port). At that point someone else steps
in for opensysusers or the package will end up removed (or limited to BDS port).
I don't plan to drop dh-sysuser soon as I may need it for runit future development.
More about dh-sysuser:
> doing so? The approach taken here entirely sidesteps the established and
> declarative sysusers.d format. Is there a reason for not cooperating
> with it? Niels Thykier is working a lot on removing maintainer scripts
> and turning them into declarative alternatives such as triggers.
> dh-sysusers works towards the opposite.
I don't see it that way, maybe I'm missing something?
It's declarative and it parses a file in the source.
It allows me to fix things uploading a new version of sysuser-helper,
without the need to rebuild the affected package from source.
It's probably able to handle many kind of transition without requiring
coordination form others maintainers (I guess I will find out soon if it
works as expected with the Merged-usr transition).
Also (looking at the patch from #981799) I don't see a clear advantage
of systemd-sysusers in simlpifying syntax of rules or other files in the
/debian directory.
One notable difference is that dh-sysuser parses on buildtime while
systemd-sysusers parses on runtime, but for Debian I'm not sure what can
be the advantage of one approach versus the other.
I plan to keep this bug open for the next release cycle so there is time
for people to highlight bug or other problems with this package.
Regards,
Lorenzo
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 5.7.0-1-amd64 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_FIRMWARE_WORKAROUND, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /bin/dash
Init: runit (via /run/runit.stopit)
Versions of packages dh-sysuser depends on:
ii perl 5.32.0-6
dh-sysuser recommends no packages.
dh-sysuser suggests no packages.
-- no debconf information
Lorenzo
Feb 5, 2021, 4:40:04 AM2/5/21
to
Helmut Grohne
Feb 5, 2021, 9:40:04 AM2/5/21
to
On Fri, Feb 05, 2021 at 10:16:14AM +0100, Lorenzo Puliti wrote:
> Short answer:
> Given that this is an alternative implementation for creating system users
> related to an alternitive init system, and given the last GR results, it
> make sense to drive the development of this package in a way that shift the
> burden from Debian infrastructure and contributors to this package maintainance,
> whenever this is possible.
While we tend to like diversity, diversity in tools and interfaces comes
> Short answer:
> Given that this is an alternative implementation for creating system users
> related to an alternitive init system, and given the last GR results, it
> make sense to drive the development of this package in a way that shift the
> burden from Debian infrastructure and contributors to this package maintainance,
> whenever this is possible.
at a cost. For example, cdbs is being faded out with reason. We're
slowly moving the archive to a mostly debhelper-only ecosystem, because
this sort of uniformity really makes things easier. The same holds for
methods to create users. I strongly think that there should be one and
only one way to create users and dh-sysuser isn't that one. Not because
dh-sysuser would be technically inferior, but because it isn't popular.
> Following the last GR, the overall state of 'creating system users' in Debian
> is getting messy, currently we have
than you pictured it.
> * systemd-sysusers [systemd package]:
> this is destructive on systems with an alternative init system, as installing
> systemd package will likely remove your Desktop Environment (due to conflict with
> elogind). This was one of the reason for the existence of dh-sysuser at least
> at the beginning
"systemd-sysusers, the interface" and "systemd-sysusers from the
systemd package". Of course we do want to avoid the latter kind in
dependencies for the reasons you give. However, the former actually
makes sense and is not destructive, because there is another provider:
> * opensysusers:
> in Debian only since 2020; i'm doing some QA maintainance on it to allow it's inclusion
> in Bullseye. Supposed to work fine with alternative init systems, possibly also with
> systemd although this setup is not tested (and not sure someone is interested in this)
having to test whether it cooperates. Why would you want to install
opensysusers together with systemd? However, using dh_installsysusers
will nicely allow using opensysusers as an implementation thus removing
the "destructive on systems with alternative init systems" part while at
the same time leveraging user descriptions that a number of upstreams
include these days. dh-sysuser does not provide the same value here,
because it is not readily available on e.g. Fedora.
> * dh-sysuser: alternative declarative interface to handle creation and removal of
> users; known to work both with systemd and alternative init systems.
> It's part of the runit infrastructure.
binary package layer. The latter would be important.
> * systemd-standalone-sysusers [ future package ]
> currently does not exists, not sure when it will, but has been discussed in TC list
> and some other bug too. Will work fine for alternative init systems.
> Not sure if it will work on BSD port, wich is relevant for runit
standalone one.
> As of my personal efforts:
> I plan to stop doing QA on opensysusers if the standalone package from systemd proves to
> works fine on all cases that I care (including BDS port). At that point someone else steps
> in for opensysusers or the package will end up removed (or limited to BDS port).
> I don't plan to drop dh-sysuser soon as I may need it for runit future development.
materialize. Maybe you can refocus your effort into opensysusers? It'll
be even easier on your side: The dh-sysuser counterpart is maintained
inside debhelper. You only get to maintain the sysuser-helper
counterpart opensysusers. Even better, you avoid forcing sysuser-helper
on systemd systems and thereby avoid accidentally breaking those systems
or taking blame for any breakage (whether caused by you or not). You can
fully concentrate on the non-systemd part you are interested in.
> It's declarative and it parses a file in the source.
binary package.
> It allows me to fix things uploading a new version of sysuser-helper,
> without the need to rebuild the affected package from source.
> It's probably able to handle many kind of transition without requiring
> coordination form others maintainers (I guess I will find out soon if it
> works as expected with the Merged-usr transition).
> Also (looking at the patch from #981799) I don't see a clear advantage
> of systemd-sysusers in simlpifying syntax of rules or other files in the
> /debian directory.
technical details are similar enough, preference should be on the most
popular interface to reduce the transition effort.
> One notable difference is that dh-sysuser parses on buildtime while
> systemd-sysusers parses on runtime, but for Debian I'm not sure what can
> be the advantage of one approach versus the other.
dh-sysuser cannot. Thus dh-sysuser is a roadblock in making packaging
more declarative (i.e. lacking maintainer scripts).
> I plan to keep this bug open for the next release cycle so there is time
> for people to highlight bug or other problems with this package.
considering my fundamental criticism. Much appreciated.
Helmut
Lorenzo
Feb 5, 2021, 10:30:04 AM2/5/21
to
On Fri, 5 Feb 2021 15:32:29 +0100
Helmut Grohne <hel...@subdivi.de> wrote:
> The standalone package will not happen. Consider opensysusers to be
> the standalone one.
>
> [...]
Helmut Grohne <hel...@subdivi.de> wrote:
> The standalone package will not happen. Consider opensysusers to be
> the standalone one.
>
>
> I think you should rethink this. The standalone one will not
> materialize.
You have news that I don't have. Is there a statement from systemd
> I think you should rethink this. The standalone one will not
> materialize.
maintainers that says that they have give up with the standalone
package, maybe some IRC chat or it's just your sixth sense?
Lorenzo
Ricardo Fraile
Feb 22, 2022, 1:50:03 PM2/22/22
to
0 new messages