Bug#1104169: wish: adduser _radvd on new installs

[Geert Stappers]

Package: radvd
Wish: Do `adduser _radvd` on new installs.
Actual: Make it possible to increase Standards-Version.
Standards-Version 4.5.0
Released January, 2020.
9.2.1
When maintainers choose a new hardcoded or dynamically generated
username for packages to use, they should start this username with
an underscore.

radvd picked a username in the past,
it is not picking a new username.

The plan is to pick a new username ....

--- a/debian/radvd.postinst
+++ b/debian/radvd.postinst
@@ -3,8 +3,8 @@
set -e

if [ "" = configure ]; then
- if ! getent passwd radvd >/dev/null; then
- adduser --quiet --system --no-create-home --home /run/radvd radvd
+ if ! getent passwd _radvd >/dev/null; then
+ adduser --quiet --system --no-create-home --home /run/radvd _radvd
fi
for i in /run/radvd; do
if dpkg-statoverride --list >/dev/null; then
--- a/debian/radvd.init
+++ b/debian/radvd.init
@@ -16,7 +16,7 @@ DESC=radvd
CONFIG=/etc/radvd.conf
PIDDIR=/var/run/radvd
PIDFILE=/radvd.pid
-OPTIONS="-u radvd -p "
+OPTIONS="-u _radvd -p "
PROC_SYS_IP6_FORWARDING=/proc/sys/net/ipv6/conf/all/forwarding

. /lib/lsb/init-functions

There is no requirement to change the username

acknowledge

Advantage I see is that systems getting a system user
that can by the leading underscore easily identified as system user.

and it's probably a bad idea.

One disadvantage I see is upgraded systems getting user 'radvd' un-used.
And only upgraded systems get that unused system user.

Now asking debian-***@lists.debian.org for their view on this rename.


Groeten
Geert Stappers
Debian Maintainer of the radvd package

[Bastian Blank]

Post by Geert Stappers
The plan is to pick a new username ....

While you are at it, please switch to sysusers (see dh_installsysusers).

Post by Geert Stappers
--- a/debian/radvd.init
+++ b/debian/radvd.init
@@ -16,7 +16,7 @@ DESC=radvd
CONFIG=/etc/radvd.conf
PIDDIR=/var/run/radvd
PIDFILE=/radvd.pid
-OPTIONS="-u radvd -p "
+OPTIONS="-u _radvd -p "
PROC_SYS_IP6_FORWARDING=/proc/sys/net/ipv6/conf/all/forwarding

Where is the corresponding change in the systemd unit? Do you need to
store persistent data accessible by others, or could you just switch to
dynamic user allocation? (DynamicUser=true)

Bastian

[Marc Haber]

Post by Bastian Blank
While you are at it, please switch to sysusers (see dh_installsysusers).

While we're at this, I would like to ask the developer commiunity
whether it is true that we have dedided to go away from having
persistent /etc/passwd and /etc/group and that it will soon be
officially forbidden to use adduser in packages?

If that is actually the case, I'd like to see the discussion that I
must have overlooked.

And, if that is actually the case, adduser 3.150 will be the last
version of adduser maintained by me. Basically forbidding adduser will
spill months of my lifetime down the drain that I spent on the package
in the last 20 years. I'd rather stop wasting more of my life now than
in a month or so. I might even orphan adduser in that case.

Where are we going regarding user creation?

Greetings
Marc

[Chris Hofstaedtler]

Post by Marc Haber

Post by Bastian Blank
While you are at it, please switch to sysusers (see dh_installsysusers).

While we're at this, I would like to ask the developer commiunity
whether it is true that we have dedided to go away from having
persistent /etc/passwd and /etc/group and that it will soon be
officially forbidden to use adduser in packages?
If that is actually the case, I'd like to see the discussion that I
must have overlooked.

I have not seen a decision on this anywhere.

[..]

Post by Marc Haber
Where are we going regarding user creation?

Unsure about users, but a general thing I'm seeing is: moving away
from (adhoc) maintainer scripts to declarative configuration.

Now these also often use (automatically generated) maintainer script
fragments, but it seems to be a step towards having no maintainer
scripts one day.

Chris
-- just observing the trends

[Geert Stappers]

Post by Chris Hofstaedtler

Post by Marc Haber

Post by Bastian Blank
While you are at it, please switch to sysusers (see dh_installsysusers).

While we're at this, I would like to ask the developer commiunity
whether it is true that we have dedided to go away from having
persistent /etc/passwd and /etc/group and that it will soon be
officially forbidden to use adduser in packages?
If that is actually the case, I'd like to see the discussion that I
must have overlooked.

I have not seen a decision on this anywhere.
[..]

Post by Marc Haber
Where are we going regarding user creation?

Unsure about users, but a general thing I'm seeing is: moving away from
(adhoc) maintainer scripts to declarative configuration.
Now these also often use (automatically generated) maintainer script
fragments, but it seems to be a step towards having no maintainer scripts
one day.

For what it is worth: I use `adduser` outside maintainer script.

I think I'm not alone in that.



Groeten
Geert Stappers

[Marc Haber]

On Sun, 27 Apr 2025 12:52:57 +0200, Geert Stappers

Post by Geert Stappers
For what it is worth: I use `adduser` outside maintainer script.
I think I'm not alone in that.

Useradd has grown most of that functionality in the last two decades.
That leaves no space for adduser between useradd and sysusers. At
least not enouch space to waste any more life time on it.

Greetings
Marc

[Andrea Pappacoda]

Hi Marc,

Post by Marc Haber
Useradd has grown most of that functionality in the last two decades.
That leaves no space for adduser between useradd and sysusers. At
least not enouch space to waste any more life time on it.

I think I do not fully understand what you mean: are you saying that
adduser is useless outside of maintainer scripts?

I always use adduser interactively when I need to interact with users or
groups on my system, and I find it very nice. I also very much prefer
using sysusers files to create system users for my packages. I never
touch useradd.

In my opinion adduser has great value outside of maintainer scripts!
But I'm sure you know better than me, so I'm ready to change my mind.

Bye :)

[Marc Haber]

On Sun, 27 Apr 2025 15:08:18 +0200, "Andrea Pappacoda"

Post by Andrea Pappacoda

Post by Marc Haber
Useradd has grown most of that functionality in the last two decades.
That leaves no space for adduser between useradd and sysusers. At
least not enouch space to waste any more life time on it.

I think I do not fully understand what you mean: are you saying that
adduser is useless outside of maintainer scripts?

I am saying that adduser was written in a time when useradd had about
a fifth of its current features, and that the local admin can use
useradd to create local users as comfortably nowadays, and be portable
between distributions. adduser has developed into a helper for
maintainer scripts, and I was told a few weeks ago that the months of
my life I spent improving adduser are going down the drain.

Post by Andrea Pappacoda
In my opinion adduser has great value outside of maintainer scripts!
But I'm sure you know better than me, so I'm ready to change my mind.

Take a look at current useradd and decide wehther adduser actually
adds a value other than fitting your finger memory.

Greetings
Marc

[Andrew M.A. Cater]

Post by Marc Haber
On Sun, 27 Apr 2025 15:08:18 +0200, "Andrea Pappacoda"

Post by Andrea Pappacoda

Post by Marc Haber
Useradd has grown most of that functionality in the last two decades.
That leaves no space for adduser between useradd and sysusers. At
least not enouch space to waste any more life time on it.

To be strictly local: there are probably far more machines in the world
running Debian, Ubuntu and Debian derivatives than current Red Hat or
SUSE if you think of Linux machines with a full OS: for containers,
who knows :)

Post by Marc Haber

Post by Andrea Pappacoda
I think I do not fully understand what you mean: are you saying that
adduser is useless outside of maintainer scripts?

I am saying that adduser was written in a time when useradd had about
a fifth of its current features, and that the local admin can use
useradd to create local users as comfortably nowadays, and be portable
between distributions. adduser has developed into a helper for
maintainer scripts, and I was told a few weeks ago that the months of
my life I spent improving adduser are going down the drain.

I don't often add users, but when I do I use useradd to add the user and
than to add the user to a custom group. That's finger memory but it's
constant over 20+ years. It's a Debianism - but it works, and I'm grateful
to you for maintaining it.

Post by Marc Haber

Post by Andrea Pappacoda
In my opinion adduser has great value outside of maintainer scripts!
But I'm sure you know better than me, so I'm ready to change my mind.

Take a look at current useradd and decide wehther adduser actually
adds a value other than fitting your finger memory.

Will do - but thanks for your hard work. For a userbase value of one: *I*
appreciate it.

With every good wish, as ever,

Andy Cater

Post by Marc Haber
Greetings
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

[Johannes Schauer Marin Rodrigues]

Hi Marc,

Quoting Marc Haber (2025-04-28 08:39:17)

Post by Marc Haber
On Sun, 27 Apr 2025 15:08:18 +0200, "Andrea Pappacoda"

Post by Andrea Pappacoda

Post by Marc Haber
Useradd has grown most of that functionality in the last two decades.
That leaves no space for adduser between useradd and sysusers. At
least not enouch space to waste any more life time on it.

I think I do not fully understand what you mean: are you saying that
adduser is useless outside of maintainer scripts?

I am saying that adduser was written in a time when useradd had about
a fifth of its current features, and that the local admin can use
useradd to create local users as comfortably nowadays, and be portable
between distributions. adduser has developed into a helper for
maintainer scripts, and I was told a few weeks ago that the months of my life
I spent improving adduser are going down the drain.

I don't think that's true. Even if maintainer scripts are moving away from
adduser, maybe think about it this way:

- adduser has served many thousands of users for two decades directly as well
as indirectly via maintainer scripts or any program which relies on adduser.
All of these thousands of people would not've been able to do what they did
in these many years if you had not maintained adduser. Thousands of people
should be grateful of your work (and so am I) for what adduser has done for
them in the past. This is a fact and independent from wherever adduser is
going in the future. Your life time was far from wasted I think.

- useradd gained the features it did because adduser paved the way for them.
Your software was and is part of a wider ecosystem and you inspired other
software authors to improve their software. You are one of the giants that
others are standing on top of when they wrote their software. This is also
something that nobody can take away from you and which is independent of
wherever adduser is going in the future.

I understand that it feels very good to be the author/maintainer of a popular
piece of software. I like the feeling I get when the popcon graph of my own
packages is going up. We can also be upset about our own mortality and just as
we will not be here one day anymore: what we did in our life will always be
part of what the world is like today. Maybe you can think about it that way.
Your software has been the cornerstone of the computing use for many, many,
many people throughout the years. Nobody can take that away from you. I think
you can be very proud. :)

Thank you!

cheers, josch

[Marc Haber]

On Mon, 28 Apr 2025 10:46:39 +0200, Johannes Schauer Marin Rodrigues

Post by Johannes Schauer Marin Rodrigues
Quoting Marc Haber (2025-04-28 08:39:17)

Post by Marc Haber
I am saying that adduser was written in a time when useradd had about
a fifth of its current features, and that the local admin can use
useradd to create local users as comfortably nowadays, and be portable
between distributions. adduser has developed into a helper for
maintainer scripts, and I was told a few weeks ago that the months of my life
I spent improving adduser are going down the drain.

I don't think that's true. Even if maintainer scripts are moving away from
adduser,

It is GOOD that maintainer scripts are moving away from adduser.
sysusers is for most cases the better way to do it. I absolute hate
the idea that this is being forced because somebody decided that we
should be moving away from persistent /etc/passwd.

Post by Johannes Schauer Marin Rodrigues
- useradd gained the features it did because adduser paved the way for them.

Most of those features were already there when Roland hander over the
package to me two decades ago. About 80 % of my work was improving the
tool for package maintainers without impacting its usefulness for
local admins.

Post by Johannes Schauer Marin Rodrigues
Thank you!

Your kind words are appreciated. My frustration about the way we take
decision remains.

Greetings
Marc

[Chris Hofstaedtler]

Post by Marc Haber
On Sun, 27 Apr 2025 12:52:57 +0200, Geert Stappers

Post by Geert Stappers
For what it is worth: I use `adduser` outside maintainer script.
I think I'm not alone in that.

Useradd has grown most of that functionality in the last two decades.
That leaves no space for adduser between useradd and sysusers. At
least not enouch space to waste any more life time on it.

I'm not sure how much of the Debian-specific rules are encoded in
useradd. This lack of rules might also be a problem for sysusers,
but I have no clue, so let me ask: is there a lintian check for
sysusers files?

As long as people want to use adduser, I think/hope they'd be
grateful for its existence and continued maintenance?

Best,
Chris

[Marc Haber]

On Sun, 27 Apr 2025 15:13:00 +0200, Chris Hofstaedtler

Post by Chris Hofstaedtler
As long as people want to use adduser, I think/hope they'd be
grateful for its existence and continued maintenance?

As far as I was told, using sysusers is going to be mandatory soon, to
help with containers, immutable /usr and empty /etc.

Greetings
Marc

[Chris Hofstaedtler]

Post by Marc Haber
On Sun, 27 Apr 2025 15:13:00 +0200, Chris Hofstaedtler

Post by Chris Hofstaedtler
As long as people want to use adduser, I think/hope they'd be
grateful for its existence and continued maintenance?

As far as I was told, using sysusers is going to be mandatory soon, to
help with containers, immutable /usr and empty /etc.

I don't know about that. It probably helps.

Fedora is discussing what to do in a related context:
https://lwn.net/Articles/1018082/
But sysusers might or might not actually help them.

Chris

[Marc Haber]

On Mon, 28 Apr 2025 09:54:53 +0200, Chris Hofstaedtler

Post by Chris Hofstaedtler
https://lwn.net/Articles/1018082/
But sysusers might or might not actually help them.

Could somebody with an LWN subscription share a friends link?

Greetings
Marc

[Sune Vuorela]

Post by Marc Haber
On Mon, 28 Apr 2025 09:54:53 +0200, Chris Hofstaedtler

Post by Chris Hofstaedtler
https://lwn.net/Articles/1018082/
But sysusers might or might not actually help them.

Could somebody with an LWN subscription share a friends link?

https://lwn.net/SubscriberLink/1018082/c32532680eaebda6/

[Bastian Blank]

Post by Marc Haber
On Mon, 28 Apr 2025 09:54:53 +0200, Chris Hofstaedtler

Post by Chris Hofstaedtler
https://lwn.net/Articles/1018082/
But sysusers might or might not actually help them.

Could somebody with an LWN subscription share a friends link?

https://lwn.net/SubscriberLink/1018082/9da60ec5de229c84/

Bastian

[Matthias Urlichs]

Post by Marc Haber
Could somebody with an LWN subscription share a friends link?

Subscriptions to LWN are free for DDs, somebody (HP IIRC) sponsors them.

--
-- regards
--
-- Matthias Urlichs

[Marc Haber]

On Mon, 28 Apr 2025 14:20:45 +0200, Matthias Urlichs

Post by Matthias Urlichs

Post by Marc Haber
Could somebody with an LWN subscription share a friends link?

Subscriptions to LWN are free for DDs, somebody (HP IIRC) sponsors them.

Yes, but it is suggested that the resources are limited, and since I
know that I don't have the round tuits to read LWN at least weekly, I
have decided to leave those resources to people who make better use of
it.

Greetings
Marc

[Marc Haber]

On Mon, 28 Apr 2025 09:54:53 +0200, Chris Hofstaedtler

Post by Chris Hofstaedtler
https://lwn.net/Articles/1018082/
But sysusers might or might not actually help them.

Yes, that is about the idea, putting more burden on the since they
either have to get along without owning files, apply for a static
assignment, or to go through tempfiles.d to have their files reowned.
The suggested semi-static assignment has become possible with adduser
recently as we finally were able to fix a bug from the 243K range,
from 20 years ago. I was very proud of that and would like to thank
the people contributing the code. Sad that it will live for like a
fifth of the time the bug was open.

Greetings
Marc

[Simon Richter]

Hi,

Post by Marc Haber
As far as I was told, using sysusers is going to be mandatory soon, to
help with containers, immutable /usr and empty /etc.

FWIW, switching to sysusers would break most of my CI containers --
these are orchestrated by Jenkins, and use a shell script as the root
process. Changing this would require a deep dive into Java code.

My containers use "useradd" instead of "adduser" for the most part
though, because these are just generic "don't run this part as root"
users that require no configuration.

The same goes, I expect, for most of the Docker containers out there --
both systemd-nspawn containers and Docker containers running a copy of
systemd as pid 1 are fairly niche, and will remain so until they also
implement a replacement for Docker-style image distribution, and
k8s-style container orchestration, and provide a stable interface for
creating users inside a container during image creation.

People running Debian inside containers also do not care about immutable
/usr or empty /etc, because containers are immutable anyway, and the
contents of /etc are copied in from version control and switching to a
database style format that uses dedicated tools creates additional
overhead, and, again would require a stable interface for creating
registry entries inside a container during image creation.

Frankly, I don't see that happening any time soon now, and even if it
were, there would be no clear benefit to users, as they already have
working solutions that would be broken by such a change, and the path of
least resistance for them would be to switch to another distribution as
container base image.

To get back on the original topic: I (and everyone in the company I work
for) uses "adduser" to create users on shared machines, because it
works, and allows us to actually get on with our main goals. That is
actual value.

Simon

[Antonio Terceiro]

Post by Marc Haber
On Sun, 27 Apr 2025 12:52:57 +0200, Geert Stappers

Post by Geert Stappers
For what it is worth: I use `adduser` outside maintainer script.
I think I'm not alone in that.

Useradd has grown most of that functionality in the last two decades.
That leaves no space for adduser between useradd and sysusers. At
least not enouch space to waste any more life time on it.

From how you write, I have the impression that you might be frustrated,
but I don't think it's useful to think of it in terms of "wasting life
time".

We cannot foresee the future, so we don't really know whether the tools
we work on will be forever needed, or not. adduser has been useful to me
for a long time, and I assume to you as well.

The ecosystem moving away from it, or it not being needed in the future,
does *not* mean you wasted your time on it. Tools are just tools, and
can become obsolete. Having people with knownledge in the problem space
is way more important than having any specific tool, so the time you
invested in this was *not* wasted.

[Marc Haber]

On Sun, 27 Apr 2025 11:04:25 -0300, Antonio Terceiro

Post by Antonio Terceiro

Post by Marc Haber
That leaves no space for adduser between useradd and sysusers. At
least not enouch space to waste any more life time on it.

From how you write, I have the impression that you might be frustrated,

Totally.

This is one more example of Debian lacking technical leadership, with
small groups taking technical decisions for the entire distribution
without even mentioning. Most of those technical decisions are sound
and supportable, but there are technical decisions that have impact on
other packages, and it is bad that those packages learn about it after
spending weeks or even months of spare time without knowing that this
work is going to go down the drain.

Heck, I remember how I (back then, being one of the two main
maintainers of the exim4 packages) noticed that exim4 became the
default MTA. It was like, "Oh, we're Debian's default now. Well, it
would be nice if we didn't learn that from the Packages.gz file!"

I am pretty sure that we won't be contacted when the (long overdue)
switch to postfix will happen.

I am not going to list all the things that should have been discussed
before going into implementation, but for sure the idea of an "empty
/etc" goes against most of my expectations of what I'd like my system
to have. We have the superior conffile handling mechanism, with dpkg
and ucf, for 20 years. While even that mechanism leaves a lot to be
desired, why don't we just finish those tools instead of moving away
from them? Why do we reduce ourselves by using the crutches that other
distributions HAVE to use to reduce the pain caused by their inferior
(or not existend) conffile handling?

I fully do understand that it would be nice to have an empty /etc in a
container, but I'd hate that in the majority of MY fleet. When did we
decide that we will go for empty /etc?

Greetings
Marc

[Chris Hofstaedtler]

Post by Marc Haber
This is one more example of Debian lacking technical leadership, with
small groups taking technical decisions for the entire distribution
without even mentioning.

Yeah. There's always talk about some form of technical leadership
group, but it's always unclear how that should look like, and what
it powers should or even could be.

So we end up with informal SIGs (to not use "cabals"), and at best a
post to d-devel.

Chris

[Marc Haber]

On Mon, 28 Apr 2025 09:57:23 +0200, Chris Hofstaedtler

Post by Chris Hofstaedtler

Post by Marc Haber
This is one more example of Debian lacking technical leadership, with
small groups taking technical decisions for the entire distribution
without even mentioning.

Yeah. There's always talk about some form of technical leadership
group, but it's always unclear how that should look like, and what
it powers should or even could be.

That's my biggest gripe about Debian. It strongly influences the only
voice I have in that regard, the DPL vote.

Post by Chris Hofstaedtler
So we end up with informal SIGs (to not use "cabals"), and at best a
post to d-devel.

And that's bad.

Greetings
Marc

[Andreas Tille]

Post by Marc Haber
That's my biggest gripe about Debian. It strongly influences the only
voice I have in that regard, the DPL vote.

... speaking as DPL I was also not aware about the adduser issue and I
did not realised that this was a topic in any platform or question on
debian-vote. Honestly, I'm happy that I do not need to decide on this
kind of technical decisions and that we have some CTTE. Is there an
according bug documenting the problem?

Post by Marc Haber

Post by Chris Hofstaedtler
So we end up with informal SIGs (to not use "cabals"), and at best a
post to d-devel.

And that's bad.

If this is really the normal case that would be really bad. I have the
impression that there are other decisions that are better communicated.

Kind regards from a happy adduser user and thank you for spending so
much time into it
Andreas.

[Marc Haber]

Post by Andreas Tille

Post by Marc Haber
That's my biggest gripe about Debian. It strongly influences the only
voice I have in that regard, the DPL vote.

... speaking as DPL I was also not aware about the adduser issue and I
did not realised that this was a topic in any platform or question on
debian-vote. Honestly, I'm happy that I do not need to decide on this
kind of technical decisions and that we have some CTTE. Is there an
according bug documenting the problem?

Not that I know of. I was just told off-the-records that it does not
make sense to spend any more time on adduser since it's going to be
forbidden soon anyway.

Actually, as I said, this is not an adduser issue, it is a general
thing I have with Debian, and it might be misunderstanding on my side
n general. And I understand that this is not fixed without going into
the constitution and changing many of our processes and that this is
not going to happen any time soon.

Greetings
Marc

[Holger Levsen]

Post by Marc Haber
Not that I know of. I was just told off-the-records that it does not
make sense to spend any more time on adduser since it's going to be
forbidden soon anyway.

don't believe everything they say?


and many thanks for maintaining adduser for so long from me too!! i'm sure
i'll be a happy user for years to come! (because I have it's usage scripted.)
--
cheers,
Holger

⢀⣎⠟⠻⢶⣊⠀
⣟⠁⢠⠒⠀⣿⡁ holger@(debian|reproducible-builds|layer-acht).org
⢿⡄⠘⠷⠚⠋⠀ OpenPGP: B8BF54137B09D35CF026FE9D 091AB856069AAA1C
⠈⠳⣄

Der Spiegel: Herr Professor, vor zwei Wochen sah die Welt noch in Ordnung aus...
Adorno: HALT DIE FRESSE!

[Marc Haber]

On Mon, 28 Apr 2025 10:36:54 +0000, Holger Levsen

Post by Holger Levsen

Post by Marc Haber
Not that I know of. I was just told off-the-records that it does not
make sense to spend any more time on adduser since it's going to be
forbidden soon anyway.

don't believe everything they say?

The technical reasoning was sound (persistent /etc/passwd is going
away, so packages who need their uid better declare it via sysusers so
that it is recreated automatically on system boot) and I immediately
understood that the advice was correct.

Greetings
Marc

[Sune Vuorela]

Post by Marc Haber
The technical reasoning was sound (persistent /etc/passwd is going
away, so packages who need their uid better declare it via sysusers so
that it is recreated automatically on system boot) and I immediately
understood that the advice was correct.

Though some improvements are still quite much needed

https://lwn.net/Articles/1018082/

/Sune

[Marc Haber]

On Mon, 28 Apr 2025 10:59:30 -0000 (UTC), Sune Vuorela

Post by Sune Vuorela

Post by Marc Haber
The technical reasoning was sound (persistent /etc/passwd is going
away, so packages who need their uid better declare it via sysusers so
that it is recreated automatically on system boot) and I immediately
understood that the advice was correct.

Though some improvements are still quite much needed
https://lwn.net/Articles/1018082/

I totally hate that idea. But I need to accept that. Traditional Unix
is going away, traditional systems are going away. It's all
containers, and everything else has to adapt.

Greetings
Marc

[Daniel Gröber]

Hi Marc,

I was just told off-the-records that [...]

Consider the motives of those staying out of the public limelight.

Does consensus need to be spoken quietly and in the shadows?

Are they afraid of something?

--Daniel

[Andrey Rakhmatullin]

Post by Andrea Pappacoda
Hi Marc,

I was just told off-the-records that [...]

Consider the motives of those staying out of the public limelight.
Does consensus need to be spoken quietly and in the shadows?
Are they afraid of something?

This is even more wtf than some of the previous messages here.

[Marc Haber]

Post by Andrea Pappacoda
Hi Marc,

I was just told off-the-records that [...]

Consider the motives of those staying out of the public limelight.
Does consensus need to be spoken quietly and in the shadows?
Are they afraid of something?

Just for the record: All I see here is non-existent technical leadship
and bad communication. Not conspiracy.

Greetings
Marc

[Russ Allbery]

Post by Marc Haber
This is one more example of Debian lacking technical leadership, with
small groups taking technical decisions for the entire distribution
without even mentioning. Most of those technical decisions are sound and
supportable, but there are technical decisions that have impact on other
packages, and it is bad that those packages learn about it after
spending weeks or even months of spare time without knowing that this
work is going to go down the drain.

I just want to make a plug here that my hope when I first started working
on Policy was that Policy could be used for this. That's part of why I
spent a lot of time working on process and trying to identify gaps where
major architectural decisions had gone undocumented in Policy.

I have had almost no time and (to be honest the more directly relevant
problem) emotional energy for Debian since at least last summer and
honestly for some years before that, and I haven't been able to push that
vision forward or even keep up with the existing work. Sean has been doing
a fantastic job stepping into the gap I rather messily left, but Policy is
in general underresourced, not so much on the Policy Editor side, but on
the side of people doing the concrete work of documenting stuff. We need
people to be proactively picking up technical decisions, figuring out a
consensus, and writing up the results so that they can be merged into the
Policy document if we want Policy to be a collection of these decisions
for the project.

I do think that would help, but I'm not sure if it's possible, at least
following the current process. It's a fair bit of work and a lot of email
back and forth. But I'm not sure what a better solution would be that
would work with how Debian is structured.

My experience is that the biggest obstacle is timeliness. We have to be
able to document a technical decision within a reasonable amount of time
or people will just go do things because they're blocked and need to move
forward. When consensus is clear, I think we can mostly manage that, but
often consensus is murky. My plan to address that had been to promptly
refer such cases to the Technical Committee so that we could keep up
momentum and make a real decision, but (a) I was never entirely sure the
TC was on board with making that many decisions (the TC often decides to
not decide), and (b) I only managed to do this once or twice and then
stopped again so we never got into a rhythm.

I pretty thoroughly dropped this ball along with a whole bunch of other
balls, and I'm not sure my idea was even sound. Sean will certainly have
his own opinions, and he's been doing most of the work recently and I
would put more weight on his views than mine at this point. But maybe this
will get people thinking about how they might be able to step into this
decision-making gap and help out with it.

I should probably say explicitly that my guess is that having a high-level
process discussion about how Debian should do this in the abstract will
probably not be helpful. We're good at having those discussions and then
never acting on them. We probably instead need people to step in and start
trying to resolve concrete technical issues and document the resolution,
and then see if we can scale that process by having them identify the
bottlenecks they encountered and the places they got stuck.

[Aaron Rainbolt]

Post by Marc Haber
On Sun, 27 Apr 2025 12:52:57 +0200, Geert Stappers

Post by Geert Stappers
For what it is worth: I use `adduser` outside maintainer script.
I think I'm not alone in that.

Useradd has grown most of that functionality in the last two decades.
That leaves no space for adduser between useradd and sysusers. At
least not enouch space to waste any more life time on it.

adduser has one very useful piece of functionality useradd doesn't
have to my awareness, which my workplace absolutely depends on for
hardware we build and sell. That's the ability to execute a "hook
script" at user creation (/usr/local/sbin/adduser.local), which can
then do bits of user account specific setup that can't be done via the
skel mechanism. Yes, we could just write a script that calls useradd
and then runs our user setup stuff, but adduser is currently
integrated into KDE (the desktop environment our hardware uses), so
that when the end user creates a new user account in KDE's settings
UI, the hook script is automatically run. The loss of adduser (which I
think is what is being discussed here?) would be a severe loss for us;
we'd have to either dpkg-divert and wrap useradd (which doesn't sound
advisable), fork KDE (or part of it) so that the settings dialog would
call our own special script rather than useradd, or ship a copy of
adduser downstream (which of course will break when KDE stops
integrating adduser because Debian dropped it, I assume they'll do
that).

If no one else wants to maintain adduser, I would ask Debian to please
do a call for maintainers before abandoning it. I won't immediately
step up and say "I'll do it" since I don't know if my workplace will
want to allocate my time to that, but it's not beyond the realm of
possibility.

Post by Marc Haber
Greetings
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

[Otto Kekäläinen]

Hi,

Post by Aaron Rainbolt

Post by Marc Haber

Post by Geert Stappers
For what it is worth: I use `adduser` outside maintainer script.
I think I'm not alone in that.

Useradd has grown most of that functionality in the last two decades.
That leaves no space for adduser between useradd and sysusers. At
least not enouch space to waste any more life time on it.

..

Post by Aaron Rainbolt
If no one else wants to maintain adduser, I would ask Debian to please
do a call for maintainers before abandoning it. I won't immediately
step up and say "I'll do it" since I don't know if my workplace will
want to allocate my time to that, but it's not beyond the realm of
possibility.

I am pretty sure 'adduser' continues to remain useful and worth
maintaining. Thanks Marc for maintaining it!

Anyone who wants to help Marc is welcome to do it at
https://salsa.debian.org/debian/adduser/-/merge_requests or send
patches via BTS. There currently open MRs from contributors and over
the years there has been numerous contributors
(https://salsa.debian.org/debian/adduser/-/graphs/master) and the
package is in shared Debian namespace, so it is easy to contribute. If
Marc some days wants to pass on the torch to somebody else, I
recommend primairly reaching out to the contributors who already
worked with the package and who are not following this mailing list.

[Marc Haber]

On Sun, 27 Apr 2025 09:49:17 -0500, Aaron Rainbolt

Post by Aaron Rainbolt
adduser has one very useful piece of functionality useradd doesn't
have to my awareness, which my workplace absolutely depends on for
hardware we build and sell. That's the ability to execute a "hook
script" at user creation (/usr/local/sbin/adduser.local), which can
then do bits of user account specific setup that can't be done via the
skel mechanism. Yes, we could just write a script that calls useradd
and then runs our user setup stuff, but adduser is currently
integrated into KDE (the desktop environment our hardware uses), so
that when the end user creates a new user account in KDE's settings
UI, the hook script is automatically run.

Are you actually sure that KDE uses adduser? adduser as we are talking
about is a Debianism. The Red Hat World has its own adduser, which is
totally independent (and also totally incompatible), so I'd advise all
other programs which should be useful outside the Debian ecosystem to
not invoke adduser but to resort to standardized tools.

Greetings
Marc

[Aaron Rainbolt]

Post by Marc Haber
On Sun, 27 Apr 2025 09:49:17 -0500, Aaron Rainbolt

Post by Aaron Rainbolt
adduser has one very useful piece of functionality useradd doesn't
have to my awareness, which my workplace absolutely depends on for
hardware we build and sell. That's the ability to execute a "hook
script" at user creation (/usr/local/sbin/adduser.local), which can
then do bits of user account specific setup that can't be done via the
skel mechanism. Yes, we could just write a script that calls useradd
and then runs our user setup stuff, but adduser is currently
integrated into KDE (the desktop environment our hardware uses), so
that when the end user creates a new user account in KDE's settings
UI, the hook script is automatically run.

Are you actually sure that KDE uses adduser? adduser as we are talking
about is a Debianism. The Red Hat World has its own adduser, which is
totally independent (and also totally incompatible), so I'd advise all
other programs which should be useful outside the Debian ecosystem to
not invoke adduser but to resort to standardized tools.

I am very sure, yes. This is the behavior on Ubuntu at least, I assume
on Red Hat-ish systems it calls something different.

Post by Marc Haber
Greetings
Marc
--
----------------------------------------------------------------------------
Marc Haber | " Questions are the | Mailadresse im Header
Rhein-Neckar, DE | Beginning of Wisdom " |
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

[Matthias Urlichs]

Post by Marc Haber
That leaves no space for adduser between useradd and sysusers.

I have no idea exactly how many packages in Debian implement a
mostly-strict subset of the features of some other (set of) package(s) —
but the number is, um, definitely not expressible with one digit (or
even two IMHO).

Post by Marc Haber
At least not enouch space to waste any more life time on it.

That's your personal call.

--
-- regards
--
-- Matthias Urlichs

[Matthias Urlichs]

Post by Marc Haber
At least not enouch space to waste any more life time on it.

Owch. That's one way to look at it, but it does seem that it's not
really conductive to your emotional well-being.

Look at it another way. Quite a few admin scripts, both in
/var/lib/dpkg/info and not, use adduser, presumably because it did
something no other tool did at the time. Thus, IMHO you can safely
assume that you spent much less time on it than your collective users
saved, as they utilized adduser instead of re-inventing some wheels (or
the bits and pieces of them that they needed).

I'd count that as a win in my book.

The work people did on CVS and SVN and HG and whatnot didn't go down the
drain either, when git took over the world. People used them. They added
value. Yes, in 2025 it's probably not a good idea to set up a new SVN
repository, and there's probably not much point in working on improving
its code *now*, but that's a different problem.

--
-- regards
--
-- Matthias Urlichs

[Marc Haber]

On Mon, 28 Apr 2025 09:38:56 +0200, Matthias Urlichs

Post by Matthias Urlichs
The work people did on CVS and SVN and HG and whatnot didn't go down the
drain either, when git took over the world.

That's different. git won because it was the superior program. Noone
every forbid using svn. Other people deciding in the secret that
Debian will stop using /etc/passwd are forbidding adduser. Using
adduser will be an RC bug.

Greetings
Marc

[Andrej Shadura]

Hi,

Post by Marc Haber
On Mon, 28 Apr 2025 09:38:56 +0200, Matthias Urlichs

Post by Matthias Urlichs
The work people did on CVS and SVN and HG and whatnot didn't go down the
drain either, when git took over the world.

That's different. git won because it was the superior program.

No. Git won because of the network effects. It was not, and still isn’t superior to Mercurial, not in terms of the internal design, data model nor in terms of the user interface.
I only use Git myself because everyone else uses Git, including my work colleagues. If I were to use Mercurial, I’d be using it on my own, or use hg-git.

[Matthias Urlichs]

Post by Marc Haber
That's different. git won because it was the superior program. Noone
every forbid using svn.

I don't think the reason *why* previous work isn't useful any more,
today, matters much.

I mean, adduser isn't going to be somewhat-obsolete-for-some-usecases
(not all of them!) because somebody decided that Marc is a horrible
human being and/or his work is and has been completely useless, quite
the opposite in fact, but because of externals that prima facie have
nothing to do with you personally *or* the quality of your work.

--
-- mit freundlichen GrÌßen
--
-- Matthias Urlichs

[Marc Haber]

On Mon, 28 Apr 2025 14:17:18 +0200, Matthias Urlichs

Post by Matthias Urlichs
I mean, adduser isn't going to be somewhat-obsolete-for-some-usecases
(not all of them!) because somebody decided that Marc is a horrible
human being and/or his work is and has been completely useless, quite
the opposite in fact, but because of externals that prima facie have
nothing to do with you personally *or* the quality of your work.

It is still incredibly frustrating. I mean, I KNOW that the
declarative approach is superior for packages, but someone needs to
keep adduser usable for the three digit number of packages that are
sill using it.

And it's different to see the package slowly fade out but to get it
pulled away just because some other maintainer gets his pet feature
implemented and rolled out.

This has happened to me already once when volatile.debian.net went
official and ftpmaster decided that a package that I spent significant
time on wouldn't fit on the org label any more.

In both cases, it is incredibly frustrating to not having known a year
earlier. In the adduser case this is especially bad because I had two
volunteers, newcomers to Debian, contributing to adduser in the last
two years whose work could have made more impact in other parts of
Debian. So, it's not only my work going down the drain, but theirs as
well.

Greetings
Marc

[Marco d'Itri]

Post by Marc Haber
While we're at this, I would like to ask the developer commiunity
whether it is true that we have dedided to go away from having
persistent /etc/passwd and /etc/group and that it will soon be
officially forbidden to use adduser in packages?

I am (nominally) one of the systemd package maintainers and I am not
aware of anybody having decided this.
At this point I would say that using DynamicUser if possible, and
sysusers if not, is just a best practice.
As usual in policy matters, policy follows usage.

Like many others, I believe that adduser is generally useful outside of
maintainer scripts.

[Geert Stappers]

Post by Bastian Blank

Post by Geert Stappers
--- a/debian/radvd.init
+++ b/debian/radvd.init

Where is the corresponding change in the systemd unit?

Work in progress, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1104229


Groeten
Geert Stappers