fakesystemd package breaking builds

[Daniel J Walsh]

On 08/28/2014 02:10 PM, Lennart Poettering wrote:
> On Thu, 28.08.14 07:24, Daniel J Walsh (dwalsh at 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