systemd-sysusers seeks to unify user creation[1]. 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.[2]
Minimizing containers, both in the short term and long term, are important to the minimization team. We have opened an issue for this.[3]
Any ideas on what we recommend to users?
Troy Dawson
[1] - https://pagure.io/packaging-committee/issue/442 [2] - 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. [3] - https://pagure.io/minimization/issue/13
On Mo, 16.09.19 09:45, Troy Dawson (tdawson@redhat.com) wrote:
systemd-sysusers seeks to unify user creation[1]. 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.[2]
Minimizing containers, both in the short term and long term, are important to the minimization team. We have opened an issue for this.[3]
Any ideas on what we recommend to users?
systemd-tmpfiles runs without PID 1 being systemd. That said, something needs to run it. Typically that's a service manager of some kind, since the tool is wrapped as a service. If you don't have that, you need to call it yourself somehow differently...
That all said it's entirely sufficient to invoke the tool at container build time, and RPM scriptlets generally do that anyway. In that case there's no need to have it around at runtime.
Lennart
-- Lennart Poettering, Berlin
Why exactly is systemd-sysusers needed here anyway? Do you not have a passwd and shadow file?
On September 16, 2019 5:41:04 PM UTC, Lennart Poettering mzerqung@0pointer.de wrote:
On Mo, 16.09.19 09:45, Troy Dawson (tdawson@redhat.com) wrote:
systemd-sysusers seeks to unify user creation[1]. 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.[2]
Minimizing containers, both in the short term and long term, are important to the minimization team. We have opened an issue for this.[3]
Any ideas on what we recommend to users?
systemd-tmpfiles runs without PID 1 being systemd. That said, something needs to run it. Typically that's a service manager of some kind, since the tool is wrapped as a service. If you don't have that, you need to call it yourself somehow differently...
That all said it's entirely sufficient to invoke the tool at container build time, and RPM scriptlets generally do that anyway. In that case there's no need to have it around at runtime.
Lennart
-- Lennart Poettering, Berlin _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On Mon, Sep 16, 2019 at 06:45:09PM +0000, John M. Harris, Jr. wrote:
Why exactly is systemd-sysusers needed here anyway? Do you not have a passwd and shadow file?
systemd-sysusers is a tool to add entries to /etc/passwd and /etc/shadow. It does a similar job to useradd and groupadd.
Zbyszek
On Monday, September 16, 2019 11:49:52 AM MST Zbigniew Jędrzejewski-Szmek wrote:
On Mon, Sep 16, 2019 at 06:45:09PM +0000, John M. Harris, Jr. wrote:
Why exactly is systemd-sysusers needed here anyway? Do you not have a passwd and shadow file?
systemd-sysusers is a tool to add entries to /etc/passwd and /etc/shadow. It does a similar job to useradd and groupadd.
Zbyszek
In that case, it sounds like this could be avoided by simply using the traditional tools.. That way you wouldn't need to pull in systemd.
On Mon, Sep 16, 2019, at 12:45 PM, Troy Dawson wrote:
systemd-sysusers seeks to unify user creation[1]. 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.[2]
Minimizing containers, both in the short term and long term, are important to the minimization team. We have opened an issue for this.[3]
As I said in the big thread, what we should aim to minimize is containers built via multi-stage build; nothing else is going to be small.
The user ID is a very interesting topic...bigger picture for example, OpenShift defaults to the `MustRunAsRange` SCC[1] - ensuring a uid is dynamically allocated for the container. So the `useradd` and `sysusers` stuff isn't relevant. (We have a longstanding issue though that the uid isn't in the passwd database but I think podman is growing some code to fix that)
For non-Kubernetes systems (e.g. installing RPMs on a host) - I think in a lot of cases, using systemd dynamic users is best: http://0pointer.net/blog/dynamic-users-with-systemd.html Where possible - using it for e.g. postgres would probably be somewhat of a surprise for admins.
It'd be useful in this discussion to look at particular containers - I'm guessing it's things like nginx and postgres where we want to ship both an RPM and a container image? And where things intersect here is whether or not the RPM depends on systemd. Maybe the least bad thing is to introduce a `systemd-container-stub` package that is empty except for Provides? Dunno...it's messy.
A whole lot of service software is container-only - it doesn't make sense to make RPMs for them, which sidesteps a lot of this.
[1] https://docs.openshift.com/container-platform/3.11/architecture/additional_c...
On 9/17/19 8:04 AM, Colin Walters wrote:
On Mon, Sep 16, 2019, at 12:45 PM, Troy Dawson wrote:
systemd-sysusers seeks to unify user creation[1]. 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.[2]
Minimizing containers, both in the short term and long term, are important to the minimization team. We have opened an issue for this.[3]
As I said in the big thread, what we should aim to minimize is containers built via multi-stage build; nothing else is going to be small.
The user ID is a very interesting topic...bigger picture for example, OpenShift defaults to the `MustRunAsRange` SCC[1] - ensuring a uid is dynamically allocated for the container. So the `useradd` and `sysusers` stuff isn't relevant. (We have a longstanding issue though that the uid isn't in the passwd database but I think podman is growing some code to fix that)
Podman and CRI-O handle this now, by adding the runasuser to the /etc/passwd inside of the container, if it does not exists.
For non-Kubernetes systems (e.g. installing RPMs on a host) - I think in a lot of cases, using systemd dynamic users is best: http://0pointer.net/blog/dynamic-users-with-systemd.html Where possible - using it for e.g. postgres would probably be somewhat of a surprise for admins.
It'd be useful in this discussion to look at particular containers - I'm guessing it's things like nginx and postgres where we want to ship both an RPM and a container image? And where things intersect here is whether or not the RPM depends on systemd. Maybe the least bad thing is to introduce a `systemd-container-stub` package that is empty except for Provides? Dunno...it's messy.
A whole lot of service software is container-only - it doesn't make sense to make RPMs for them, which sidesteps a lot of this.
[1] https://docs.openshift.com/container-platform/3.11/architecture/additional_c... _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On Tue, Sep 17, 2019 at 10:34 AM Daniel Walsh dwalsh@redhat.com wrote:
On 9/17/19 8:04 AM, Colin Walters wrote:
On Mon, Sep 16, 2019, at 12:45 PM, Troy Dawson wrote:
systemd-sysusers seeks to unify user creation[1]. 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.[2]
Minimizing containers, both in the short term and long term, are important to the minimization team. We have opened an issue for this.[3]
As I said in the big thread, what we should aim to minimize is containers built via multi-stage build; nothing else is going to be small.
The user ID is a very interesting topic...bigger picture for example, OpenShift defaults to the `MustRunAsRange` SCC[1] - ensuring a uid is dynamically allocated for the container. So the `useradd` and `sysusers` stuff isn't relevant. (We have a longstanding issue though that the uid isn't in the passwd database but I think podman is growing some code to fix that)
Podman and CRI-O handle this now, by adding the runasuser to the /etc/passwd inside of the container, if it does not exists.
For non-Kubernetes systems (e.g. installing RPMs on a host) - I think in a lot of cases, using systemd dynamic users is best: http://0pointer.net/blog/dynamic-users-with-systemd.html Where possible - using it for e.g. postgres would probably be somewhat of a surprise for admins.
It'd be useful in this discussion to look at particular containers - I'm guessing it's things like nginx and postgres where we want to ship both an RPM and a container image? And where things intersect here is whether or not the RPM depends on systemd. Maybe the least bad thing is to introduce a `systemd-container-stub` package that is empty except for Provides? Dunno...it's messy.
A whole lot of service software is container-only - it doesn't make sense to make RPMs for them, which sidesteps a lot of this.
[1] https://docs.openshift.com/container-platform/3.11/architecture/additional_c...
One of the comments in the ticket was to try pulling out systemd-sysusers into it's own sub-package. systemd-sysusers requires libsystemd-shared Pulling libsystemd-shared into it's own sub-package shows that it requires cryptsetup-libs which sets up a circular dependency back to systemd. After many attempts, just using rpm packaging techniques, I have been unsuccessful in breaking the 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.
The "systemd-container-stub" is looking more and more like the way to go.
Troy
-
Colin Walters -
Daniel Walsh -
John M. Harris Jr. -
John M. Harris, Jr.
-
Lennart Poettering -
Troy Dawson -
Zbigniew Jędrzejewski-Szmek