Seems the fakesystemd package is breaking some rawhide builds, particularly because it is getting pulled into the buildroot and that it contains: Conflicts: systemd
Example qt: https://koji.fedoraproject.org/koji/taskinfo?taskID=7452802
(which is no direct systemd dependencies, mind you)
I can guess why this fakesystemd package came into existence, but I question the wisdom behind it's implementation. As far as I can tell, it contains only: Provides: systemd (and a few other systemd-related dependencies)
systemd-related directories systemd macros
I'd argue * these last 2 items could easily be shared with the real systemd package (ie, systemd could grow systemd-filesystem and/or systemd-macros subpkgs) and should not be duplicated here. * fakesystemd should be untagged until the reasons behind these failures are better understood and fixed
-- Rex
On August 27, 2014 at 7:28 AM Rex Dieter rdieter@math.unl.edu wrote:
Seems the fakesystemd package is breaking some rawhide builds, particularly because it is getting pulled into the buildroot and that it contains: Conflicts: systemd
Example qt: https://koji.fedoraproject.org/koji/taskinfo?taskID=7452802
That has a sub-build[1] that is failing but for a different reason: Error: Package: harfbuzz-icu-0.9.35-2.fc22.x86_64 (build) Requires: libicuuc.so.52()(64bit)
Might be fallout from the gcc mass rebuild.
I don't see where fakesystemd is being pulled into the buildroot[2], can you point that out for me?
Jerry
1. https://koji.fedoraproject.org/koji/taskinfo?taskID=7453378 2. https://kojipkgs.fedoraproject.org//work/tasks/3378/7453378/root.log
Hi,
There is new fakesystemd build for F21 which should fix the breakage, sorry.
Vaclav
On St 27. srpen 2014, 15:23:27 CEST, Jerry Vonau wrote:
On August 27, 2014 at 7:28 AM Rex Dieter rdieter@math.unl.edu wrote:
Seems the fakesystemd package is breaking some rawhide builds, particularly because it is getting pulled into the buildroot and that it contains: Conflicts: systemd
Example qt: https://koji.fedoraproject.org/koji/taskinfo?taskID=7452802
That has a sub-build[1] that is failing but for a different reason: Error: Package: harfbuzz-icu-0.9.35-2.fc22.x86_64 (build) Requires: libicuuc.so.52()(64bit)
Might be fallout from the gcc mass rebuild.
I don't see where fakesystemd is being pulled into the buildroot[2], can you point that out for me?
Jerry
--
Lead Infrastructure Engineer Developer Experience Brno, Czech Republic
On Aug 27, 2014 9:23 PM, "Jerry Vonau" me@jvonau.ca wrote:
That has a sub-build[1] that is failing but for a different reason: Error: Package: harfbuzz-icu-0.9.35-2.fc22.x86_64 (build) Requires: libicuuc.so.52()(64bit)
Might be fallout from the gcc mass rebuild.
Not that case. icu was just bumped to v53.1 in rawhide days ago after the second mass rebuild.
On Wed, 27.08.14 07:28, Rex Dieter (rdieter@math.unl.edu) wrote:
Seems the fakesystemd package is breaking some rawhide builds, particularly because it is getting pulled into the buildroot and that it contains: Conflicts: systemd
Example qt: https://koji.fedoraproject.org/koji/taskinfo?taskID=7452802
(which is no direct systemd dependencies, mind you)
I can guess why this fakesystemd package came into existence, but I question the wisdom behind it's implementation. As far as I can tell, it contains only: Provides: systemd (and a few other systemd-related dependencies)
What is "fakesystemd" supposed to be? Wouldn't it be a good idea to pass such things by me or so before introducing this? I mean, people are welcome to ignore me, but it would be nice to at least inform me about this... There was already a systemd-mini, and now a fakesystemd, I mean, what is this all about?
Anyone?
Lennart
Hi Lennart,
It's a package that fakes systemd presence in system. It's solely intended for Docker images as we don't want systemd there (at least as long as it takes to prepare systemd-container Michal is working on). I made a mistake and it ended up being pulled in buildroot.
Ping me on IRC if you have more questions or comments.
Vasek
On St 27. srpen 2014, 20:16:20 CEST, Lennart Poettering wrote:
On Wed, 27.08.14 07:28, Rex Dieter (rdieter@math.unl.edu) wrote:
Seems the fakesystemd package is breaking some rawhide builds, particularly because it is getting pulled into the buildroot and that it contains: Conflicts: systemd
Example qt: https://koji.fedoraproject.org/koji/taskinfo?taskID=7452802
(which is no direct systemd dependencies, mind you)
I can guess why this fakesystemd package came into existence, but I question the wisdom behind it's implementation. As far as I can tell, it contains only: Provides: systemd (and a few other systemd-related dependencies)
What is "fakesystemd" supposed to be? Wouldn't it be a good idea to pass such things by me or so before introducing this? I mean, people are welcome to ignore me, but it would be nice to at least inform me about this... There was already a systemd-mini, and now a fakesystemd, I mean, what is this all about?
Anyone?
Lennart
--
Lead Infrastructure Engineer Developer Experience Brno, Czech Republic
On Wed, 27.08.14 20:20, Václav Pavlín (vpavlin@redhat.com) wrote:
Heya,
It's a package that fakes systemd presence in system. It's solely intended for Docker images as we don't want systemd there (at least as long as it takes to prepare systemd-container Michal is working on). I made a mistake and it ended up being pulled in buildroot.
Ping me on IRC if you have more questions or comments.
So what is "systemd-container" supposed to do? And what precisely is "fakesystemd" supposed to do? And that "mini" thing?
This sounds all very much not thought to the end.
Can you please explain what these packages precisely do, and why they exist?
Lennart
On St 27. srpen 2014, 20:27:51 CEST, Lennart Poettering wrote:
On Wed, 27.08.14 20:20, Václav Pavlín (vpavlin@redhat.com) wrote:
Heya,
It's a package that fakes systemd presence in system. It's solely intended for Docker images as we don't want systemd there (at least as long as it takes to prepare systemd-container Michal is working on). I made a mistake and it ended up being pulled in buildroot.
Ping me on IRC if you have more questions or comments.
So what is "systemd-container" supposed to do? And what precisely is "fakesystemd" supposed to do? And that "mini" thing?
fakesystemd owns same directories systemd does and has set provides to fulfill most RPM dependencies for systemd. For example you want to run httpd in your Docker container which brings systemd, devicemapper, kmod... in. If the base image contains fakesystemd none of these dependencies is installed. If you really need systemd in you container you can use following command:
yum swap -- remove fakesystemd -- install systemd systemd-libs
systemd-container (I think it's the same thing you refer to as "mini") should remove dependencies which does not make sense in container (again devicemapper, kmod...) and hwdb and should run as init in multi-service containers. Well I am not sure if it ends up being really "systemd-container" or simply "fixed" systemd. If I am not mistaken this was second topic for last Base WG meeting which we didn't get to:) So hopefully this week?
Vasek
This sounds all very much not thought to the end.
Can you please explain what these packages precisely do, and why they exist?
Lennart
--
Lead Infrastructure Engineer Developer Experience Brno, Czech Republic
On Wed, 27.08.14 20:35, Václav Pavlín (vpavlin@redhat.com) wrote:
So what is "systemd-container" supposed to do? And what precisely is "fakesystemd" supposed to do? And that "mini" thing?
fakesystemd owns same directories systemd does and has set provides to fulfill most RPM dependencies for systemd. For example you want to run httpd in your Docker container which brings systemd, devicemapper, kmod... in. If the base image contains fakesystemd none of these dependencies is installed. If you really need systemd in you container you can use following command:
yum swap -- remove fakesystemd -- install systemd systemd-libs
systemd-container (I think it's the same thing you refer to as "mini") should remove dependencies which does not make sense in container (again devicemapper, kmod...) and hwdb and should run as init in multi-service containers. Well I am not sure if it ends up being really "systemd-container" or simply "fixed" systemd. If I am not mistaken this was second topic for last Base WG meeting which we didn't get to:) So hopefully this week?
I am not on the base WG. I was not selected for it. If you come up with schemes like this, it is really a good idea to actually ask the people who work on the package you are trying to work on or work around...
Can we please do this stuff more systematically?
I also offered to split out the hwdb in Brno, if you remember. If this is about the hwdb, then let's just do that...
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?
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...
Lennart
On St 27. srpen 2014, 20:47:33 CEST, Lennart Poettering wrote:
On Wed, 27.08.14 20:35, Václav Pavlín (vpavlin@redhat.com) wrote:
So what is "systemd-container" supposed to do? And what precisely is "fakesystemd" supposed to do? And that "mini" thing?
fakesystemd owns same directories systemd does and has set provides to fulfill most RPM dependencies for systemd. For example you want to run httpd in your Docker container which brings systemd, devicemapper, kmod... in. If the base image contains fakesystemd none of these dependencies is installed. If you really need systemd in you container you can use following command:
yum swap -- remove fakesystemd -- install systemd systemd-libs
systemd-container (I think it's the same thing you refer to as "mini") should remove dependencies which does not make sense in container (again devicemapper, kmod...) and hwdb and should run as init in multi-service containers. Well I am not sure if it ends up being really "systemd-container" or simply "fixed" systemd. If I am not mistaken this was second topic for last Base WG meeting which we didn't get to:) So hopefully this week?
I am not on the base WG. I was not selected for it. If you come up with schemes like this, it is really a good idea to actually ask the people who work on the package you are trying to work on or work around...
Well you was very helpful on last meeting and I guess you'll be invited to the next one as systemd should be on the plate again.
Can we please do this stuff more systematically?
I also offered to split out the hwdb in Brno, if you remember. If this is about the hwdb, then let's just do that...
Talk to Michal Sekletar about it then - he is working on "something" we call systemd-container internally. We need systemd running in Docker container. I don't like to have needless stuff in images but if the result is "just drop the hwdb" then I am fine with that.
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 to have needless junk in base image - if we are not going to use systemd to manage services there, why should it be there with all it's dependencies?
Vasek
Lennart
--
Lead Infrastructure Engineer Developer Experience Brno, Czech Republic
On Wed, 27.08.14 21:00, Václav Pavlín (vpavlin@redhat.com) wrote:
I also offered to split out the hwdb in Brno, if you remember. If this is about the hwdb, then let's just do that...
Talk to Michal Sekletar about it then - he is working on "something" we call systemd-container internally. We need systemd running in Docker container. I don't like to have needless stuff in images but if the result is "just drop the hwdb" then I am fine with that.
As discussed in Brno, "not liking to have needless stuff around" alone is really not a convincing reason.
I mean, you could make the case for the size of things, but afaics this doesn't hold any water here... kmod is a 150K dep, and the other stuff, is that any bigger? For 150K we shouldn't complicate things this much...
You could also make the case for the dependencies, but this is kind the same as the size argument...
And you could make the case for "security", but that's really wrong too, since recent systemd versions have exactly zero suid binaries, and if you don't run the daemons, then you have exactly zero ways to raise your priviliges. And just having dead code lying around is not really an issue. I mean, if you managed to exploit something and smuggled in some code, then you smuggled in some code, why would make it any difference if there's dead code lying around or not in the container?
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?
to have needless junk in base image - if we are not going to use systemd to manage services there, why should it be there with all it's dependencies?
This sounds awfully like a "just because!" reason...
Lennart
----- Original Message -----
On St 27. srpen 2014, 20:47:33 CEST, Lennart Poettering wrote:
On Wed, 27.08.14 20:35, Václav Pavlín (vpavlin@redhat.com) wrote: I am not on the base WG. I was not selected for it. If you come up with schemes like this, it is really a good idea to actually ask the people who work on the package you are trying to work on or work around...
Well you was very helpful on last meeting and I guess you'll be invited to the next one as systemd should be on the plate again.
Hum, “invited”? The original intent was that the places on the WG are _voting_ places, not “allowed participation” places; i.e. that anyone not only can, but is very welcome to, join, participate in the discussions and the implementation. (And presumably that good ideas from non-voting members wouldn’t be gratuitously rejected.)
If the general perception is that one has to be “invited” into the WGs, that would explain why we ended up with several WGs that are often not much bigger than the 9 voting places, and it would be something we should urgently fix (or if Base wants to use that model, something we would want to certainly urgently fix for Server).
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.
For context, there are also efforts like https://fedorahosted.org/fpc/ticket/411 . I do not really understand how the tradeoff can be tiled so far in favor of saving space, but it is something that has been happening for some time now. Mirek
On Wed, 2014-08-27 at 16:43 -0400, Miloslav Trmač wrote:
If the general perception is that one has to be “invited” into the WGs, that would explain why we ended up with several WGs that are often not much bigger than the 9 voting places, and it would be something we should urgently fix (or if Base wants to use that model, something we would want to certainly urgently fix for Server).
I think you are readying way to much into a perfectly normal word that means: "hey we are discussing stuff related to your project, would you mind joining this sessions so we can have better understanding ?"
When you want someone to participate in something he usually do not do, you "invite" that person.
Simo.
Hi
On Wed, Aug 27, 2014 at 10:05 PM, Simo Sorce wrote:
I think you are readying way to much into a perfectly normal word that means: "hey we are discussing stuff related to your project, would you mind joining this sessions so we can have better understanding ?"
That's possible. The essential problem however is seemingly systemd related package and additional components are being introduced apparently without systemd developers being aware of that. That suggests that there is a communication problem irrespective of the words used
Rahul
Lennart Poettering píše v St 27. 08. 2014 v 21:15 +0200:
On Wed, 27.08.14 21:00, Václav Pavlín (vpavlin@redhat.com) wrote:
I also offered to split out the hwdb in Brno, if you remember. If this is about the hwdb, then let's just do that...
Talk to Michal Sekletar about it then - he is working on "something" we call systemd-container internally. We need systemd running in Docker container. I don't like to have needless stuff in images but if the result is "just drop the hwdb" then I am fine with that.
As discussed in Brno, "not liking to have needless stuff around" alone is really not a convincing reason.
I mean, you could make the case for the size of things, but afaics this doesn't hold any water here... kmod is a 150K dep, and the other stuff, is that any bigger? For 150K we shouldn't complicate things this much...
You could also make the case for the dependencies, but this is kind the same as the size argument...
And you could make the case for "security", but that's really wrong too, since recent systemd versions have exactly zero suid binaries, and if you don't run the daemons, then you have exactly zero ways to raise your priviliges. And just having dead code lying around is not really an issue. I mean, if you managed to exploit something and smuggled in some code, then you smuggled in some code, why would make it any difference if there's dead code lying around or not in the container?
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?
to have needless junk in base image - if we are not going to use systemd to manage services there, why should it be there with all it's dependencies?
This sounds awfully like a "just because!" reason...
Lennart
-- Lennart Poettering, Red Hat
I think that there was a problem in communication. We are *not* going to create systemd-container in fedora. That was just for rhel, because at least I wanted some quick and dirty solution. Our current plan in fedora is patch systemd to run in docker and split the hwdb, that's all.
Lukas
On Wed, Aug 27, 2014 at 11:01:45PM -0400, Rahul Sundaram wrote:
Hi
On Wed, Aug 27, 2014 at 10:05 PM, Simo Sorce wrote:
I think you are readying way to much into a perfectly normal word that means: "hey we are discussing stuff related to your project, would you mind joining this sessions so we can have better understanding ?"
That's possible. The essential problem however is seemingly systemd related package and additional components are being introduced apparently without systemd developers being aware of that. That suggests that there is a communication problem irrespective of the words used
We were discussing this issue on systemd hackfest during Flock in person. Hence as for fakesystemd I don't think there was anything done behind anybodies back. On the other hand, I acknowledge that there maybe doubts and concerns about overall implementation.
Rahul
Michal
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
It's a package that fakes systemd presence in system. It's solely intended for Docker images as we don't want systemd there (at least as long as it takes to prepare systemd-container Michal is working on). I made a mistake and it ended up being pulled in buildroot.
Ping me on IRC if you have more questions or comments.
So what is "systemd-container" supposed to do? And what precisely is "fakesystemd" supposed to do? And that "mini" thing?
fakesystemd owns same directories systemd does and has set provides to
Surely the proper, at least standard, way of dealing with creation/ownership of a directory structure that's needed by other packages would be systemd-filesystem like so many other packages handle it (yes, I'm aware this is just one of the issues attempting to be addressed by the above package).
Peter
On 08/27/2014 03:15 PM, Lennart Poettering wrote:
On Wed, 27.08.14 21:00, Václav Pavlín (vpavlin@redhat.com) wrote:
I also offered to split out the hwdb in Brno, if you remember. If this is about the hwdb, then let's just do that...
Talk to Michal Sekletar about it then - he is working on "something" we call systemd-container internally. We need systemd running in Docker container. I don't like to have needless stuff in images but if the result is "just drop the hwdb" then I am fine with that.
As discussed in Brno, "not liking to have needless stuff around" alone is really not a convincing reason.
I mean, you could make the case for the size of things, but afaics this doesn't hold any water here... kmod is a 150K dep, and the other stuff, is that any bigger? For 150K we shouldn't complicate things this much...
You could also make the case for the dependencies, but this is kind the same as the size argument...
And you could make the case for "security", but that's really wrong too, since recent systemd versions have exactly zero suid binaries, and if you don't run the daemons, then you have exactly zero ways to raise your priviliges. And just having dead code lying around is not really an issue. I mean, if you managed to exploit something and smuggled in some code, then you smuggled in some code, why would make it any difference if there's dead code lying around or not in the container?
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. 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.
to have needless junk in base image - if we are not going to use systemd to manage services there, why should it be there with all it's dependencies?
This sounds awfully like a "just because!" reason...
Lennart
On Thu, 28.08.14 08:40, Lukáš Nykrýn (lnykryn@redhat.com) wrote:
Heya,
I think that there was a problem in communication. We are *not* going to create systemd-container in fedora. That was just for rhel, because at least I wanted some quick and dirty solution. Our current plan in fedora is patch systemd to run in docker and split the hwdb, that's all.
Ah thanks! That makes a lot of sense, and is what we discussed in Prague!
Did the things change their name since Prague, though? I thought systemd-container was called "minimal" back then?
And fakesystemd was entirely news to me under this name...
Lennart
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....
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
On 28 August 2014 12:10, Lennart Poettering mzerqung@0pointer.de 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....
Past performance does not indicate future pains. It doesn't matter if an application even have had 0 in the past.. the idea of having to respin every image because of a piece of software which isn't needed but is included in everything will cause the bristles go up for any large organization that must pass audits. (or a company that hosts for companies that must pass audits). It doesn't matter that it can't be used to break out of the image etc.. it is more about potential work and what can cause that potential work.
[This is non-rational but is how things work and after twenty years of telling people that putting antivirus on a linux desktop doesn't solve a problem... it isn't the sort of problem which goes away with a rational argument.]
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
On Qua, 2014-08-27 at 07:28 -0500, Rex Dieter wrote:
Seems the fakesystemd package is breaking some rawhide builds, particularly because it is getting pulled into the buildroot and that it contains: Conflicts: systemd
Example qt: https://koji.fedoraproject.org/koji/taskinfo?taskID=7452802
(which is no direct systemd dependencies, mind you)
I can guess why this fakesystemd package came into existence, but I question the wisdom behind it's implementation. As far as I can tell, it contains only: Provides: systemd (and a few other systemd-related dependencies)
systemd-related directories systemd macros
I'd argue
- these last 2 items could easily be shared with the real systemd package
(ie, systemd could grow systemd-filesystem and/or systemd-macros subpkgs) and should not be duplicated here.
- fakesystemd should be untagged until the reasons behind these failures are
better understood and fixed
I'm getting this error: DEBUG util.py:257: Getting requirements for 1:kplayer-0.7.0-11.20081211cvs.fc21.src DEBUG util.py:257: --> desktop-file-utils-0.22-3.fc21.x86_64 DEBUG util.py:257: --> gettext-0.19.2-2.fc21.x86_64 DEBUG util.py:257: --> 6:kdelibs-devel-4.14.0-2.fc21.x86_64 DEBUG util.py:257: Error: fakesystemd conflicts with systemd DEBUG util.py:257: You could try using --skip-broken to work around the problem DEBUG util.py:257: You could try running: rpm -Va --nofiles --nodigest
I'm getting this on F21 buildroot , this is fixed ? have we a bugzilla report ? to follow
Best regards,
On Qua, 2014-08-27 at 15:30 +0200, Václav Pavlín wrote:
Hi,
There is new fakesystemd build for F21 which should fix the breakage, sorry.
Hi, I think this still breaking rpmfusion builds , in some packages like kplayer [1]. rpmfusion got a older version of Mock, Version: 1.1.21 [2]
ends with a strange : --> 6:kdelibs-devel-4.14.0-2.fc21.x86_64 DEBUG util.py:257: Error: fakesystemd conflicts with systemd
[1] http://buildsys.rpmfusion.org/logs/fedora-development-rpmfusion_free/21087-k... [2] http://buildsys.rpmfusion.org/logs/fedora-development-rpmfusion_free/21087-k...
On Seg, 2014-09-08 at 02:36 +0100, Sérgio Basto wrote:
On Qua, 2014-08-27 at 15:30 +0200, Václav Pavlín wrote:
Hi,
There is new fakesystemd build for F21 which should fix the breakage, sorry.
Hi, I think this still breaking rpmfusion builds ,
no longer breaks rpmfusion builds
Thanks,
in some packages like kplayer [1]. rpmfusion got a older version of Mock, Version: 1.1.21 [2]
ends with a strange : --> 6:kdelibs-devel-4.14.0-2.fc21.x86_64 DEBUG util.py:257: Error: fakesystemd conflicts with systemd
[1] http://buildsys.rpmfusion.org/logs/fedora-development-rpmfusion_free/21087-k... [2] http://buildsys.rpmfusion.org/logs/fedora-development-rpmfusion_free/21087-k...
-- Sérgio M. B.
-
Christopher Meng -
Daniel J Walsh -
Jerry Vonau -
Lennart Poettering -
Lukáš Nykrýn -
Michal Sekletar -
Miloslav Trmač -
Peter Robinson -
Rahul Sundaram -
Rex Dieter -
Simo Sorce -
Stephen John Smoogen -
Sérgio Basto -
Václav Pavlín