On 08/28/2014 02:10 PM, Lennart Poettering wrote:
On Thu, 28.08.14 07:24, Daniel J Walsh (dwalsh@redhat.com) wrote:
But regarding kmod/devicemapper, can we please get some stats about how big this individually are, and how much is saved by this? kmod at least is 150K or so only. Is there really any value in doing this weird stuff for a fricking 150K?! Fedora has no bigger fishes to fry?
I'll prepare stats for you tomorrow.
The systemd-container or fakesystemd stuff sounds awfully adhoc. Can we please always discuss this first, and see if we can find a different solution? We don't need three different "solutions", if one works too...
We've talked about this on Flock - it's not only about disk space but also about security reasons (CC'ing Dan Walsh). My goal was not
Dan, can you elaborate what the rationale for this is?
It is not about Security escalation is is about the need to update a container image if a CVE happens on any of the packages installed. Basically we want to keep the turn on images as small as possible. If systemd, kmod, udev ... have a CVE and they are not used within an image, then we would still need to update the image because it containers "Vulnerable" code, or potentially vulnerable code.
Is kmod/systemd really that bad with CVEs? I mean, if there was a large number of them, maybe that's something to think about, but I see 2 in 2012, and 5 in 2013, and 0 in 2014... and those are not really the biggest issues in the world either, and certainly not in any way relevant if you just leave the files lying around....
Well systemd just showed up in RHEL7, but as I said, the goal was to limit the exposure. We were seeing systemd, kmod, udev and a few other packages being sucked into a container that only needed httpd. Every package we add is a possibility of a CVE and forcing us to rebuild.
Fakesystemd was developed for RHEL/Centos images to help minimize the CVE footprint. This was discussed on on this fpc request. https://fedorahosted.org/fpc/ticket/425. I actually did not want fakesystemd to go into Fedora for exactly the fear of it screwing up builds. I like the idea of systemd-container, or some other minimal systemd environment which understands and works well within container, and am trying to get pull requests into docker to allow systemd to work well.
https://github.com/docker/docker/pull/7685 https://github.com/docker/docker/pull/7685
If we got a good version of systemd-container, (Or systemd) which did not suck in other requirements an stopped other random rpm sucking in stuff not needed in container, I would be all for dropping fakesystemd.
I don't think there's any value in having a second version of systemd for containers. We repeatedly made clear that we care about containers upstream, and want that systemd works fine in containers out of the box. I want a unified OS that works in any way executed. But by inventing thigns like "systemd-container" or "fakesystemd" you just create two more crappy options that don't fully work.
Really, we should emphasize the value of our platform and its APIs, what you are doing there is just splitting up things into a crude variety of half-working, half-supported hacks.
Let's just see what changes we can make upstream and in the systemd rpm in fedora, don't start doing things like fakesystemd/systemd-container without first trying to do these things properly, upstream and in the default RPM.
For example, let's split out the hwdb stuff in Fedora, and maybe some other things, and then you can drop that from the container images, but let's not wildly invent new hacks, without checking if there are better ways...
Thank you very much,
Lennart
I agree, as I said, I did not want any of these to show up in Fedora. My understanding of systemd-container (minimum) was just a rebuild of systemd code to not require these additional packages. If we can end up with regular systemd running within a container and not requiring kmod/udev and others that would be great. Similarly not starting any services/getty's/SySV Services.
I agree that systemd should just work and I hope that happens going forward with Fedora, so we can get it working in RHEL/Centos.
In the end a multi-service container with httpd and mariadb should end up with
systemd, journald, httpd* and mariadb* processes. Nothing else and as close to minimal packages as httpd and mariadb require to run.
Lennart, I think we are in agreement, and you understand our needs. My end goal is to make systemd the default multi-process container manager and never ship cruft like supervisord. I would also like to