#13 systemd-sysusers versus containers
Opened 3 months ago by tdawson. Modified 3 months ago

systemd-sysusers seeks to unify user creation. It also has the benefit of being able to create users on bootup. But, it pulls in the entire systemd infrastructure with all it's dependencies.

containers do not need systemd to run. They are trying to be as small as possible. But if a package in container needs to add a user, then systemd is pulled in and that container grows by up to 60M.[1]

We need a solution for this dilemma.

[1] - The amount a container grows when systemd is added depends on how many of the systemd dependencies are needed by the main container packages. As of F31, if they need none of these dependency packages, then a container grows by 60M by adding systemd.


It looks like sysusers isn't recommended yet
https://pagure.io/packaging-committee/issue/442

There is also at least one bug opened on it, that was never fixed/addressed.
https://bugzilla.redhat.com/show_bug.cgi?id=1610541

There are several packages that use systemd-sysusers to create users in their rpm's .

  • deepin-daemon
  • dnsmasq
  • ladvd
  • mydns
  • zincati

Could we package sysusers separately from the rest of systemd? I believe @lennart mentioned to me that all binaries can be used independently of each other..

Also, relatedly, the guidelines don't yet encourage the use of systemd to create users and packages as it is also not supported by rpm-ostree, yet (see https://github.com/coreos/rpm-ostree/issues/49)

I am going to try packaging systemd-sysusers seperately and see how many/if any dependencies are removed.

You are correct about the guidelines. I also found the original change proposal. https://fedoraproject.org/wiki/Changes/SystemdSysusers

It is interesting that in the "Benefits to Fedora" section it lists "Factory Reset" style installs (have a blank /etc) and rpm-ostree installs. As far as I can tell, having a blank /etc/ is going to break systemd, and this doesn't work with rpm-ostree. So, the two things this says will benefit, are really going to be broken instead.

And yet, it's still slowly growing.

it is also not supported by rpm-ostree, yet (see https://github.com/coreos/rpm-ostree/issues/49)

No - that issue is about having rpm-ostree do a very complicated dance to switch everything over to sysusers automatically and drop nss-altfiles.

Packages adding sysusers snippets works today with both yum+librpm and rpm-ostree; we ship one today in FCOS: https://github.com/coreos/zincati/blob/master/dist/sysusers.d/50-zincati.conf

Metadata Update from @asamalik:
- Issue tagged with: Meeting

3 months ago

It is interesting that in the "Benefits to Fedora" section it lists "Factory Reset" style installs (have a blank /etc) and rpm-ostree installs. As far as I can tell, having a blank /etc/ is going to break systemd, and this doesn't work with rpm-ostree. So, the two things this says will benefit, are really going to be broken instead.

Looks like I was wrong on both accounts.
Having a blank /etc/ does not break systemd, but simply boots it up with it's defaults.
And, as walters said above, rpm-ostree does work with it.

Metadata Update from @tdawson:
- Issue untagged with: Meeting

3 months ago

I am going to try packaging systemd-sysusers seperately and see how many/if any dependencies are removed.

Progress thus far.
systemd-sysusers requires libsystemd-shared
Pulling libsystemd-shared into it's own rpm ends up pulling in alot of the dependencies we were trying to drop. And most specifically it requires cryptsetup-libs, which requires device-mapper-libs which requires systemd

I have been unable to break the libsystemd-shared -> cryptsetup-libs -> systemd circular dependency. The only way I can see to do it is either remove some functionality, or do some type of re-writting of code in systemd and/or one of the packages in the circular dependency.

Metadata Update from @asamalik:
- Issue tagged with: Meeting

3 months ago

Metadata Update from @asamalik:
- Issue untagged with: Meeting

3 months ago

I opened an issue with the containerization sig. Asking their opinion.
https://pagure.io/ContainerSIG/container-sig/issue/38

Looks like they are going to try to fix the circular dependency so sysusers can go independent.
https://github.com/systemd/systemd/issues/13653

Login to comment on this ticket.

Metadata