On 08/28/2014 02:10 PM, Lennart Poettering wrote: > On Thu, 28.08.14 07:24, Daniel J Walsh (dwalsh@xxxxxxxxxx) 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 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
