Re: [cip-dev] [isar-cip-core] Support for systemd-sysusers?

Hi Matthijs, Hi Felix,

my two-cents on this :-)

On Mon, 2026-06-22 at 13:38 +0000, Berge, Matthijs ten via lists.cip-
project.org wrote:
> [You don't often get email from
> [email protected]. Learn why this is important
> at https://aka.ms/LearnAboutSenderIdentification ]
>
> MOESSBAUER, Felix <[email protected]> wrote:
> > Instead of the proposal from above, this should be implemented with
> > dh_installsysusers, which also takes care of creating the user at
> > package install time (untested!). Citing man dh_installsysusers
> >
> > > It  also  finds  the  systemd  sysusers  files  installed in a
> > > package and generates relevant integration snippets for enabling
> > > the
> > > users on installation.
>
> Thanks for the pointer, I will certainly investigate
> dh_installsysusers further!
>
> > > I'm not sure if this topic has already been discussed before on
> > > this list. But seeing the other thread about stable system user
> > > ids for swupdate/suricatta, would it be worth to consider
> > > including systemd-sysusers support in the image class recipes?
> >
> > Now I see where you are coming from (swupdate thread) :)
>
> Sideways;-) I've seen that thread and noticed them mentioning
> sysusers too. We are planning for the use of SWUpdate too, so
> certainly relevant.
> My actual use case is that I needed a newer version of NUT (network
> UPS tool) than available in Debian (and also apply a local patch for
> our UPS model), so I had to create a recipe to build from a newer
> tarball release from that project.
> Nut upstream now already provides the sysusers config file. That's
> where I bumped my head.
>
> > IMHO this is rather an isar topic, but the overlay part
> > (/etc/passwd
> > and alike) only affects CIP - and is already a pitfall as of today.

Absolutely! Imo, for many systems a complete (persistent) etc-overlay
is too broad! Unfortunately, systemd /etc/machine-id semantics kind of
forces users to do so, if they are not willing to work around that [1]
:-(

[1]: https://github.com/systemd/systemd/issues/39438#issuecomment-3527432723

> >
> > Apart from that, Debian does not enforce stable user ids, which
> > results
> > in issues with files owned by a different user after swupdate runs.
> >
> > Felix,
>
> The sysusers.d manpage [1] specifies the possibility to specify
> UID/GID numbers explicitly. But if Debian packages are not using
> that, or are even prohibited from using fixed numbers by deb policy,
> this can indeed become a real pain, both for /etc and for /var.
> Thanks for the heads-up on that!
> [1]
> https://manpages.debian.org/testing/systemd/sysusers.d.5.en.html#ID
>
> They do specify that creating accounts should be idempotent, so not
> fail if the accounts already exist. Unfortunately, the USERS and
> GROUPS are processed way too late (in do_rootfs_postprocess), so I'll
> probably go the route of trying to create the important accounts
> (with fixed numbers) somewhere earlier in the rootfs process.

Although you technically can, I'd not recommend to create system users
and groups with USERS or GROUPS. Those, most probably, are used to run
services, thus are coupled to specific packages shipping those.

sysusers.d is meant for system users only. So there shouldn't be a
conflict.

dh_installsysusers should do the trick and create the system users at
package installation [2] by invoking systemd-sysusers [3].


[2]:
https://salsa.debian.org/debian/debhelper/-/blob/main/dh_installsysusers?ref_type=heads#L103
[3]:
https://salsa.debian.org/debian/debhelper/-/blob/main/autoscripts/postinst-sysusers?ref_type=heads

Anyways, something like tmpfiles.d to fix ownership (z) of mutable data
is still required for updates (in case user/group-ids are not fixed or
may change).

BR Alexander


> Kind regards,
>
> Matthijs
>
>
> AWL Disclaimer: This e-mail is intended only for the addressee(s) and
> contains confidential information. If you have received this e-mail
> in error, please immediately notify the sender, delete the e-mail
> from your computer and destroy all copies or print-outs (if any).
> This e-mail is not intended to be relied upon by any person or entity
> without subsequent confirmation of its contents in the form of a
> (fax) letter. AWL accepts no liability for the use of the information
> contained in this e-mail. For our full disclaimer, please visit
> https://www.awl.nl/disclaimer/
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#23247):
> https://lists.cip-project.org/g/cip-dev/message/23247
> Mute This Topic: https://lists.cip-project.org/mt/119920445/8886423
> Group Owner: [email protected]
> Unsubscribe:
> https://lists.cip-project.org/g/cip-dev/unsub [[email protected]
> ]
> -=-=-=-=-=-=-=-=-=-=-=-

--
Alexander Heinisch
Siemens AG
http://www.siemens.com/