systemd-sysusers versus containers

tdawson commented

2019-09-16 15:09:52 +00:00

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.

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.

tdawson commented

2019-09-16 16:36:20 +00:00

Author

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

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

lorbus commented

2019-09-16 17:21:13 +00:00

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)

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)

tdawson commented

2019-09-16 18:49:25 +00:00

Author

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.

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.

walters commented

2019-09-17 09:42:10 +00:00

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

> 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

asamalik commented

2019-09-17 15:29:03 +00:00

Metadata Update from @asamalik:

Issue tagged with: Meeting

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

tdawson commented

2019-09-17 16:07:28 +00:00

Author

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.

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

tdawson commented

2019-09-17 16:07:28 +00:00

Author

Metadata Update from @tdawson:

Issue untagged with: Meeting

**Metadata Update from @tdawson**: - Issue **un**tagged with: Meeting

tdawson commented

2019-09-17 16:14:14 +00:00

Author

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

tdawson commented

2019-09-18 14:28:21 +00:00

Author

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.

asamalik commented

2019-09-18 15:11:27 +00:00

Metadata Update from @asamalik:

Issue tagged with: Meeting

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

asamalik commented

2019-09-18 16:05:37 +00:00

Metadata Update from @asamalik:

Issue untagged with: Meeting

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

tdawson commented

2019-09-24 14:46:04 +00:00

Author

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

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

tdawson commented

2019-09-25 20:02:46 +00:00

Author

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

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

lorbus commented

2020-05-27 12:58:34 +00:00

I took a stab at packaging sysusers in a separate subpackage: https://src.fedoraproject.org/rpms/systemd/pull-request/25

Rows
Columns

systemd-sysusers versus containers #13