Hi, I would like to get your feedback about COPR [1]
[1] http://miroslav.suchy.cz/blog/archives/2013/08/29/what_is_copr/index.html
We are the beggining and there are two options of where we can go: http://miroslav.suchy.cz/blog/archives/2013/08/29/copr_and_integration_with_... http://miroslav.suchy.cz/blog/archives/2013/08/30/copr_implemented_using_obs...
I would like to ask *you* what is your opinion?
Hi,
if you have a grudge against our infra team, OBS is the best option. More seriously, OBS has a major flaw: it's a pain to deploy or update and we need to have people able to fix bugs in a rails app.
I advise you to discuss this with infra team before considering further this option.
One quick remark:
build package in VM, which is safer then Koji (just chroot in Koji)
Safer, but it has an overhead. I'd rather add LXC support to Koji (much less overhead and pretty much as safe as heavier virtualization solutions).
best regards, H.
On Fri, Aug 30, 2013 at 11:57:19AM +0200, 80 wrote:
Hi,
if you have a grudge against our infra team, OBS is the best option. More seriously, OBS has a major flaw: it's a pain to deploy or update and we need to have people able to fix bugs in a rails app.
I advise you to discuss this with infra team before considering further this option.
One quick remark:
build package in VM, which is safer then Koji (just chroot in Koji)
Safer, but it has an overhead. I'd rather add LXC support to Koji (much less overhead and pretty much as safe as heavier virtualization solutions).
That statement about security is absolutely not the case.
With a shared kernel for LXC there is significantly higher security risk. A local root exploit will let a container take over the entire host, and there's nothing we can do with namespaces or selinux to prevent that attack vector. With KVM, a local root exploit only lets you compromise the one VM, they then still need to exploit QEMU/KVM and then get another local root exploit for the host.
Even ignoring the shared kernel aspects, having a secure LXC deployment requires use of user namespaces which are a new feature not yet available in Fedora since the conflict with XFS. With the user namespace feature enabled, many types of kernel flaw will have increased severity because functionality that was previously restricted to root, is now available to non-root process which have started a new user namespace. eg crashes that could be triggered by root only and thus not be classed as security flaws, could now become privilege escalation flaws.
Regards, Daniel
I'm not a native speaker so i assume that's a misunderstanding, when i said "pretty much", i meant "not as secure as KVM but much better than chroot". The overhead of using KVM/Xen/Whatever hypervisor is non-negligeable, container-based virtualization is a good compromise between security and performance.
Besides, most of our builders are already virtualized.
H.
On Fri, 2013-08-30 at 11:39 +0200, Miroslav Suchý wrote:
http://miroslav.suchy.cz/blog/archives/2013/08/30/copr_implemented_using_obs...
I would like to ask *you* what is your opinion?
I think it's absolutely essential that were COPRS to be an OBS instance, it still used mock to build. Anything else is just going to create too much divergence in the details of the build process.
On Fri, 2013-08-30 at 09:01 -0400, Colin Walters wrote:
On Fri, 2013-08-30 at 11:39 +0200, Miroslav Suchý wrote:
http://miroslav.suchy.cz/blog/archives/2013/08/30/copr_implemented_using_obs...
I would like to ask *you* what is your opinion?
I think it's absolutely essential that were COPRS to be an OBS instance, it still used mock to build. Anything else is just going to create too much divergence in the details of the build process.
Also, wow, I just followed and read the link: http://lists.opensuse.org/opensuse-buildservice/2013-07/msg00044.html
I know this is old code and stuff, but writing the data to the swap partition sounds very Rube Goldberg. Now that virtio-serial exists, it's easy to set up arbitrary private guest-host communication channels without involving networking/TCP.
Were OBS to use mock in a VM I'd expect it to basically do:
tar cf /dev/virtio-ports/org.fedoraproject.mock /var/lib/mock/result
and then the host could read that tar file.
On Fri, Aug 30, 2013 at 11:52:05AM -0400, Colin Walters wrote:
On Fri, 2013-08-30 at 09:01 -0400, Colin Walters wrote:
On Fri, 2013-08-30 at 11:39 +0200, Miroslav Suchý wrote:
http://miroslav.suchy.cz/blog/archives/2013/08/30/copr_implemented_using_obs...
I would like to ask *you* what is your opinion?
I think it's absolutely essential that were COPRS to be an OBS instance, it still used mock to build. Anything else is just going to create too much divergence in the details of the build process.
Also, wow, I just followed and read the link: http://lists.opensuse.org/opensuse-buildservice/2013-07/msg00044.html
I know this is old code and stuff, but writing the data to the swap partition sounds very Rube Goldberg. Now that virtio-serial exists, it's easy to set up arbitrary private guest-host communication channels without involving networking/TCP.
Were OBS to use mock in a VM I'd expect it to basically do:
tar cf /dev/virtio-ports/org.fedoraproject.mock /var/lib/mock/result
and then the host could read that tar file.
Or you could just map a directory on the host into /var/lib/mock/result in the guest, using the virtio-9p filesystem feature of KVM. Basically this gives you shared filesystem, but without any TCP/networking involved.
NB, works with KVM in Fedora hosts, but not RHEL which does not ship 9p support
Regards, Daniel
On Fri, 30 Aug 2013, Daniel P. Berrange wrote:
Or you could just map a directory on the host into /var/lib/mock/result in the guest, using the virtio-9p filesystem feature of KVM. Basically this gives you shared filesystem, but without any TCP/networking involved.
NB, works with KVM in Fedora hosts, but not RHEL which does not ship 9p support
We use that as basis for the libreswan testing infrastructure:
https://github.com/libreswan/libreswan/tree/master/testing/libvirt
Then based on MAC address (hardcoded in libvirt xml files) we can fire up VMs that mount our testing directory and source directory as 9p, and /testing/guestbin allows us to auto-config the VMs, and run the various tests, capture output files, even when IPsec breaks all networking on the VMs. On the host we run tcpdump on the bridge devices to capture all traffic.
Currently we use f17 guests, I hope rhel7 wil get writable 9p filesystems.
Paul
On 08/30/2013 05:59 PM, Daniel P. Berrange wrote:
On Fri, Aug 30, 2013 at 11:52:05AM -0400, Colin Walters wrote:
On Fri, 2013-08-30 at 09:01 -0400, Colin Walters wrote: Also, wow, I just followed and read the link: http://lists.opensuse.org/opensuse-buildservice/2013-07/msg00044.html
I know this is old code and stuff, but writing the data to the swap partition sounds very Rube Goldberg.
It sounds complicated. But the reason is: since during build, the code is run under root, you must assume very hostile environment. The packager can do on builder *anything*. Even modify file system. Directly on block device. And if you mount the guestfs as whole FS, there is potential to exploit kernel FS. In past there were problems where kernel oopsed because FS was damaged. So OBS team decided that this has potential for exploit and into swap data is written number of blocks where the files reside and from that guest FS are read just those blocks directly. Using virtio-serial can be used for that, but I guess that it was not available at that time (and AFAIK it will not work no s390 zVM).
Also reading that directly (instead of tar-ing) will save some time for big results (1.1 GB texlive or 9GB DVD image).
But personally I think this is just implementation detail. Not the biggest question on this decision.
Now that virtio-serial exists,
it's easy to set up arbitrary private guest-host communication channels without involving networking/TCP.
Were OBS to use mock in a VM I'd expect it to basically do:
tar cf /dev/virtio-ports/org.fedoraproject.mock /var/lib/mock/result
and then the host could read that tar file.
Or you could just map a directory on the host into /var/lib/mock/result in the guest, using the virtio-9p filesystem feature of KVM. Basically this gives you shared filesystem, but without any TCP/networking involved.
NB, works with KVM in Fedora hosts, but not RHEL which does not ship 9p support
Thanks for pointing me to these two technologies, I was not aware of them.
On 09/02/2013 10:54 AM, Miroslav Suchý wrote:
On 08/30/2013 05:59 PM, Daniel P. Berrange wrote:
On Fri, Aug 30, 2013 at 11:52:05AM -0400, Colin Walters wrote:
On Fri, 2013-08-30 at 09:01 -0400, Colin Walters wrote: Also, wow, I just followed and read the link: http://lists.opensuse.org/opensuse-buildservice/2013-07/msg00044.html
I know this is old code and stuff, but writing the data to the swap partition sounds very Rube Goldberg.
It sounds complicated. But the reason is: since during build, the code is run under root, you must assume very hostile environment. The packager can do on builder *anything*. Even modify file system. Directly on block device. And if you mount the guestfs as whole FS, there is potential to exploit kernel FS. In past there were problems where kernel oopsed because FS was damaged. So OBS team decided that this has potential for exploit and into swap data is written number of blocks where the files reside and from that guest FS are read just those blocks directly. Using virtio-serial can be used for that, but I guess that it was not available at that time (and AFAIK it will not work no s390 zVM).
Regular networking is also an option, I think. The networking stack is more robust than the file system stack. (Which puts the idea to use air-gapped machines and thumb drives for data transfer between them into an interesting light, by the way.)
On Fri, 30 Aug 2013 11:39:38 +0200 Miroslav Suchý msuchy@redhat.com wrote:
Hi, I would like to get your feedback about COPR [1]
[1] http://miroslav.suchy.cz/blog/archives/2013/08/29/what_is_copr/index.html
We are the beggining and there are two options of where we can go: http://miroslav.suchy.cz/blog/archives/2013/08/29/copr_and_integration_with_... http://miroslav.suchy.cz/blog/archives/2013/08/30/copr_implemented_using_obs...
I would like to ask *you* what is your opinion?
First of all: thanks very much for writing up all the information and pros and cons and such. Very helpful for discussion! :)
Personally, I like the idea of merging copr's into koji and in the process also improving koji. ;) I think some of the concepts used in copr's now would be great to add to koji and in the process make koji better for everyone.
OBS does have some compelling features, but if we want Fedora Infrastructure to host such a thing it would need to follow our Request For Resources process. In particular it would need a _group_ of people active and interested in maintaining it long term, as well as hardware resources which I'm not sure we have available right now. Also, it would mean we would have two different build systems which seems like a duplication of effort and infrastructure. If they don't build things exactly the same way it could cause people lots of headaches as well.
Just my 2 cents. :)
kevin
On Fri, 2013-08-30 at 11:39 +0200, Miroslav Suchý wrote:
Hi, I would like to get your feedback about COPR [1]
[1] http://miroslav.suchy.cz/blog/archives/2013/08/29/what_is_copr/index.html
We are the beggining and there are two options of where we can go: http://miroslav.suchy.cz/blog/archives/2013/08/29/copr_and_integration_with_... http://miroslav.suchy.cz/blog/archives/2013/08/30/copr_implemented_using_obs...
I would like to ask *you* what is your opinion?
I really do not like the name, but the tool is really useful, it already improves life of people that need to build packages for testing.
About koji vs obs I have no real good opinion, whatever works best for the job.
Simo.
On Fri, 2013-08-30 at 13:43 -0400, Simo Sorce wrote:
On Fri, 2013-08-30 at 11:39 +0200, Miroslav Suchý wrote:
Hi, I would like to get your feedback about COPR [1]
[1] http://miroslav.suchy.cz/blog/archives/2013/08/29/what_is_copr/index.html
We are the beggining and there are two options of where we can go: http://miroslav.suchy.cz/blog/archives/2013/08/29/copr_and_integration_with_... http://miroslav.suchy.cz/blog/archives/2013/08/30/copr_implemented_using_obs...
I would like to ask *you* what is your opinion?
I really do not like the name, but the tool is really useful, it already improves life of people that need to build packages for testing.
About koji vs obs I have no real good opinion, whatever works best for the job.
Btw it would be awesome to have copr as a feature for fedorahosted projects so that project owners can build 'official' upstream builds for fedora.
Simo.
On Fri, Aug 30, 2013 at 3:39 AM, Miroslav Suchý msuchy@redhat.com wrote:
I would like to ask *you* what is your opinion?
Koji has another advantage over OBS in that it's already in the distro.
I've found that packaging Rails apps for the long term (especially for EPEL) is an absolute nightmare. Looking at OBS's webui requirements, getting that to run on EL6 with the standard Ruby 1.8.7 would be a near-impossible undertaking. If Fedora's release engineering was going to try to implement this using a package stack that actually comes from Fedora or EPEL (and not some side repo), the OBS web server(s) would probably need to run Fedora or RHEL 7.
I don't mean to be down on OBS - I think it just has a long road ahead.
- Ken
On Fri, Aug 30, 2013 at 3:39 AM, Miroslav Suchý msuchy@redhat.com wrote:
Hi, I would like to get your feedback about COPR [1]
[1] http://miroslav.suchy.cz/blog/archives/2013/08/29/what_is_copr/index.html
We are the beggining and there are two options of where we can go: http://miroslav.suchy.cz/blog/archives/2013/08/29/copr_and_integration_with_... http://miroslav.suchy.cz/blog/archives/2013/08/30/copr_implemented_using_obs...
I would like to ask *you* what is your opinion?
-- Miroslav Suchy, RHCE, RHCDS Red Hat, Software Engineer, #brno, #devexp, #fedora-buildsys -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On 08/30/2013 08:42 PM, Ken Dreyer wrote:
I've found that packaging Rails apps for the long term (especially for EPEL) is an absolute nightmare. Looking at OBS's webui requirements, getting that to run on EL6 with the standard Ruby 1.8.7 would be a near-impossible undertaking. If Fedora's release engineering was going to try to implement this using a package stack that actually comes from Fedora or EPEL (and not some side repo), the OBS web server(s) would probably need to run Fedora or RHEL 7.
Partially agree. But with software collections this is just little bumper on the road. We can withing 2 weeks deliver Rails 4 to EL6.
On Mon, Sep 2, 2013 at 2:05 AM, Miroslav Suchý msuchy@redhat.com wrote:
On 08/30/2013 08:42 PM, Ken Dreyer wrote:
I've found that packaging Rails apps for the long term (especially for EPEL) is an absolute nightmare. Looking at OBS's webui requirements, getting that to run on EL6 with the standard Ruby 1.8.7 would be a near-impossible undertaking. If Fedora's release engineering was going to try to implement this using a package stack that actually comes from Fedora or EPEL (and not some side repo), the OBS web server(s) would probably need to run Fedora or RHEL 7.
Partially agree. But with software collections this is just little bumper on the road. We can withing 2 weeks deliver Rails 4 to EL6.
In my previous email when I wrote "not some side repo", I meant to imply "not SCL". It's not possible to build packages within EPEL that have hard dependencies on the ruby193 SCL. Without the legwork to get all of that into EPEL, we'd just have some RPMs in yet another side repo. To me, that feels like a step backwards when koji-web is already present in Fedora and EPEL.
- Ken
On 08/30/2013 05:39 AM, Miroslav Suchý wrote:
Hi, I would like to get your feedback about COPR [1]
[1] http://miroslav.suchy.cz/blog/archives/2013/08/29/what_is_copr/index.html
We are the beggining and there are two options of where we can go: http://miroslav.suchy.cz/blog/archives/2013/08/29/copr_and_integration_with_...
http://miroslav.suchy.cz/blog/archives/2013/08/30/copr_implemented_using_obs...
I would like to ask *you* what is your opinion?
Hi Miroslav,
I'd like to see some elaboration on why VMs instead of chroots would be required. I can draw my own conclusions (security) but I'd like to see them listed out first before continuing the discussion.
- Jay
On 30. 8. 2013 at 16:01:42, Jay Greguske wrote:
On 08/30/2013 05:39 AM, Miroslav Suchý wrote:
Hi, I would like to get your feedback about COPR [1]
[1] http://miroslav.suchy.cz/blog/archives/2013/08/29/what_is_copr/index.html
We are the beggining and there are two options of where we can go: http://miroslav.suchy.cz/blog/archives/2013/08/29/copr_and_integration_wit h_koji/index.html
http://miroslav.suchy.cz/blog/archives/2013/08/30/copr_implemented_using_o bs/index.html
I would like to ask *you* what is your opinion?
Hi Miroslav,
I'd like to see some elaboration on why VMs instead of chroots would be required. I can draw my own conclusions (security) but I'd like to see them listed out first before continuing the discussion.
I'm not directly involved in the COPR project but from what I know, it's really about security. The thing is that only a selected group of people can build on koji, as the process of becoming a maintainer includes mechanisms to prevent any random developer to put code into Fedora.
The use case for COPR is a bit different. Think of it as a tool for anyone who wants to have a repo with packages that are built on Fedora infrastructure. There will be just a minimal set of requirements to become owner of such repo and therefore to gain access to COPR. VMs that come and go seem more appropriate to prevent potential attacker gaining permanent access to a part of the buildsystem - this way the attacker's potential access will be limited to a temporary VM.
HTH Jan
On 08/30/2013 10:01 PM, Jay Greguske wrote:
I'd like to see some elaboration on why VMs instead of chroots would be required. I can draw my own conclusions (security) but I'd like to see them listed out first before continuing the discussion.
Koji builder has somewhere stored certificate. This certificate authorize him to Koji hub. Whoever has this certificate can act as Koji builder. Koji builder builds using mock, which means in chroot. There are known some exploits, which allows you to run out of chroots.
Now imagine evil package, which will run out chroot, read that certificate and deliver it to attacker. He now can build evil builder and start building modified packages.
While there are known exploits to affect host machine of VM, it is definitely harder than running out of chroot.
On 09/02/2013 04:29 AM, Miroslav Suchý wrote:
On 08/30/2013 10:01 PM, Jay Greguske wrote:
I'd like to see some elaboration on why VMs instead of chroots would be required. I can draw my own conclusions (security) but I'd like to see them listed out first before continuing the discussion.
Koji builder has somewhere stored certificate. This certificate authorize him to Koji hub. Whoever has this certificate can act as Koji builder. Koji builder builds using mock, which means in chroot. There are known some exploits, which allows you to run out of chroots.
Now imagine evil package, which will run out chroot, read that certificate and deliver it to attacker. He now can build evil builder and start building modified packages.
While there are known exploits to affect host machine of VM, it is definitely harder than running out of chroot.
If we had SELinux policy enabled on the builders and used MLS on the chroots that would mitigate chroot-to-chroot attacks. I'm not sure if policy could prevent a chroot'ed process from getting access to the builder's certificate. If it could, I think getting SELinux working on the builders would be an easier path than re-writing koji to use VMs.
Maybe someone with more expertise could comment on the latter issue.
- Jay
On Tue, Sep 3, 2013 at 3:10 PM, Jay Greguske jgregusk@redhat.com wrote:
On 09/02/2013 04:29 AM, Miroslav Suchý wrote:
On 08/30/2013 10:01 PM, Jay Greguske wrote:
I'd like to see some elaboration on why VMs instead of chroots would be required. I can draw my own conclusions (security) but I'd like to see them listed out first before continuing the discussion.
Koji builder has somewhere stored certificate. This certificate authorize him to Koji hub. Whoever has this certificate can act as Koji builder. Koji builder builds using mock, which means in chroot. There are known some exploits, which allows you to run out of chroots.
Now imagine evil package, which will run out chroot, read that certificate and deliver it to attacker. He now can build evil builder and start building modified packages.
While there are known exploits to affect host machine of VM, it is definitely harder than running out of chroot.
If we had SELinux policy enabled on the builders and used MLS on the chroots that would mitigate chroot-to-chroot attacks. I'm not sure if policy could prevent a chroot'ed process from getting access to the builder's certificate. If it could, I think getting SELinux working on the builders would be an easier path than re-writing koji to use VMs.
Maybe someone with more expertise could comment on the latter issue.
koji already uses VMs for x86.
Peter
On 09/03/2013 11:48 AM, Peter Robinson wrote:
On Tue, Sep 3, 2013 at 3:10 PM, Jay Greguske <jgregusk@redhat.com mailto:jgregusk@redhat.com> wrote:
On 09/02/2013 04:29 AM, Miroslav Suchý wrote: > On 08/30/2013 10:01 PM, Jay Greguske wrote: >> I'd like to see some elaboration on why VMs instead of chroots would be >> required. I can draw my own conclusions (security) but I'd like to see >> them listed out first before continuing the discussion. > > Koji builder has somewhere stored certificate. This certificate > authorize him to Koji hub. > Whoever has this certificate can act as Koji builder. > Koji builder builds using mock, which means in chroot. There are known > some exploits, which allows you to run out of chroots. > > Now imagine evil package, which will run out chroot, read that > certificate and deliver it to attacker. > He now can build evil builder and start building modified packages. > > While there are known exploits to affect host machine of VM, it is > definitely harder than running out of chroot. > If we had SELinux policy enabled on the builders and used MLS on the chroots that would mitigate chroot-to-chroot attacks. I'm not sure if policy could prevent a chroot'ed process from getting access to the builder's certificate. If it could, I think getting SELinux working on the builders would be an easier path than re-writing koji to use VMs. Maybe someone with more expertise could comment on the latter issue.koji already uses VMs for x86.
Peter
Not for RPM builds.
On Tue, Sep 03, 2013 at 03:33:10PM -0400, Jay Greguske wrote:
koji already uses VMs for x86.
Not for RPM builds.
I think we're talking about different things here. It happens that some of the x86 builders are VMs, but they're not taken down and rebuilt cleanly between each package build; they're long-running servers doing multiple builds. (Right?)
On Tue, Sep 3, 2013 at 8:43 PM, Matthew Miller mattdm@fedoraproject.orgwrote:
On Tue, Sep 03, 2013 at 03:33:10PM -0400, Jay Greguske wrote:
koji already uses VMs for x86.
Not for RPM builds.
I think we're talking about different things here. It happens that some of the x86 builders are VMs, but they're not taken down and rebuilt cleanly between each package build; they're long-running servers doing multiple builds. (Right?)
Correct, each build is done in mock which is essentially a chroot.
Peter
On Tue, 3 Sep 2013 15:43:38 -0400 Matthew Miller mattdm@fedoraproject.org wrote:
On Tue, Sep 03, 2013 at 03:33:10PM -0400, Jay Greguske wrote:
koji already uses VMs for x86.
Not for RPM builds.
I think we're talking about different things here. It happens that some of the x86 builders are VMs, but they're not taken down and rebuilt cleanly between each package build; they're long-running servers doing multiple builds. (Right?)
Correct.
kevin
On 09/03/2013 09:43 PM, Matthew Miller wrote:
On Tue, Sep 03, 2013 at 03:33:10PM -0400, Jay Greguske wrote:
koji already uses VMs for x86.
Not for RPM builds.
I think we're talking about different things here. It happens that some of the x86 builders are VMs, but they're not taken down and rebuilt cleanly between each package build; they're long-running servers doing multiple builds. (Right?)
Right. Koji builders are right now running as VM. But even if you reset them to snapshot after each build, it will not help you. Because each builder still have the certificate and the builds are done in mock (on that VM). Compare it to Copr and OBS approach, when package is build in VM and after that backend will retrieve the results from VM. So on builder (of OBS and COPR) is no sensitive information at all.
On Wed, Sep 04, 2013 at 09:04:10AM +0200, Miroslav Suchy wrote:
Compare it to Copr and OBS approach, when package is build in VM and after that backend will retrieve the results from VM. So on builder (of OBS and COPR) is no sensitive information at all.
Are we able to evaluate, how much slower this is? Currently Fedora Koji is pretty fast, I usually get near-to-instant build pick-ups.
I can imagine spawning a VM can be slower. At least when using full QEMU/KVM. I see the point that containers/selinux and such technologies can do better in here.
On 09/04/2013 04:29 PM, Lukas Zapletal wrote:
Are we able to evaluate, how much slower this is?
Just few seconds. I would say 15 seconds slower. I mean in current Copr, which does VM+mockchain.
OBS is actually little bit faster because it does not use mock. And if you use PreinstallImages (http://openbuildservice.org/help/manuals/obs-reference-guide/cha.obs.build_p...) e.g. for builds with SCLs - it can be even faster.
On Wed, Sep 04, 2013 at 04:29:27PM +0200, Lukas Zapletal wrote:
On Wed, Sep 04, 2013 at 09:04:10AM +0200, Miroslav Suchy wrote:
Compare it to Copr and OBS approach, when package is build in VM and after that backend will retrieve the results from VM. So on builder (of OBS and COPR) is no sensitive information at all.
Are we able to evaluate, how much slower this is? Currently Fedora Koji is pretty fast, I usually get near-to-instant build pick-ups.
I can imagine spawning a VM can be slower. At least when using full QEMU/KVM. I see the point that containers/selinux and such technologies can do better in here.
Please measure this before making incorrect statements.
I have done, and you should be able to boot up a Fedora VM in 3-5 seconds on c.2010 Intel hardware (which is what libguestfs does). Alternately you can restore the VM from a saved image in even less time.
There's no significant advantage to using containers for this. Containers are also *not* secure -- see Dan Berrange's reply a few days ago for the full details about that.
Rich.
Le 6 sept. 2013 20:19, "Richard W.M. Jones" rjones@redhat.com a écrit :
On Wed, Sep 04, 2013 at 04:29:27PM +0200, Lukas Zapletal wrote:
On Wed, Sep 04, 2013 at 09:04:10AM +0200, Miroslav Suchy wrote:
Compare it to Copr and OBS approach, when package is build in VM and after that backend will retrieve the results from VM. So on builder (of OBS and COPR) is no sensitive information at all.
Are we able to evaluate, how much slower this is? Currently Fedora Koji is pretty fast, I usually get near-to-instant build pick-ups.
I can imagine spawning a VM can be slower. At least when using full QEMU/KVM. I see the point that containers/selinux and such technologies can do better in here.
Please measure this before making incorrect statements.
I have done, and you should be able to boot up a Fedora VM in 3-5 seconds on c.2010 Intel hardware (which is what libguestfs does). Alternately you can restore the VM from a saved image in even less time.
There's no significant advantage to using containers for this. Containers are also *not* secure -- see Dan Berrange's reply a few days ago for the full details about that.
No, it's less secure than kvm but it still provides better isolation than a mere chroot. Secure containers as dwalsh described is a worthy improvement.
Rich.
-- Richard Jones, Virtualization Group, Red Hat
http://people.redhat.com/~rjones
Read my programming blog: http://rwmj.wordpress.com Fedora now supports 80 OCaml packages (the OPEN alternative to F#) -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On Fri, Sep 06, 2013 at 09:10:24PM +0200, 80 wrote:
No, it's less secure than kvm but it still provides better isolation than a mere chroot.
It doesn't matter if it's more secure than a chroot, because that's not what we're talking about. This is about whether you want random-person-off-the-internet to upload any software they like and run it on your server, and you *do not* want to do that with either a chroot or a Linux container [even if OpenShift got away with it].
And ...
Secure containers as dwalsh described is a worthy improvement.
... SELinux labels will not make that situation any better, because an exploit somewhere in the large kernel API bypasses SELinux.
Dan Walsh's two replies are much more nuanced than you understand.
Rich.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/06/2013 03:38 PM, Richard W.M. Jones wrote:
On Fri, Sep 06, 2013 at 09:10:24PM +0200, 80 wrote:
No, it's less secure than kvm but it still provides better isolation than a mere chroot.
It doesn't matter if it's more secure than a chroot, because that's not what we're talking about. This is about whether you want random-person-off-the-internet to upload any software they like and run it on your server, and you *do not* want to do that with either a chroot or a Linux container [even if OpenShift got away with it].
And ...
Secure containers as dwalsh described is a worthy improvement.
... SELinux labels will not make that situation any better, because an exploit somewhere in the large kernel API bypasses SELinux.
Dan Walsh's two replies are much more nuanced than you understand.
Rich.
Yes in the hierarchy of Security, I would say.
VM Wrapped with Svirt (SELinux), running a Container wrapped with SELinux, running mock... VM Wrapped with Svirt (SELinux), running mock wrapped with SELinux Container wrapped Selinux running mock Mock wrapped with SELinux Chroot root access.
As many layers as you can get away with and still perform ok. If we can get VMs to start and
On Fri, Sep 06, 2013 at 03:53:50PM -0400, Daniel J Walsh wrote:
VM Wrapped with Svirt (SELinux), running a Container wrapped with SELinux, running mock...
I see we need another layer in libguestfs :-)
Rich.
Le 06/09/2013 21:38, Richard W.M. Jones a écrit :
On Fri, Sep 06, 2013 at 09:10:24PM +0200, 80 wrote:
No, it's less secure than kvm but it still provides better isolation than a mere chroot.
It doesn't matter if it's more secure than a chroot, because that's not what we're talking about. This is about whether you want random-person-off-the-internet to upload any software they like and run it on your server, and you *do not* want to do that with either a chroot or a Linux container [even if OpenShift got away with it].
And ...
We're talking about a *fedora* infrastructure, not a public infrastructure such as SuSE OBS instance. As i said, if we were to open it to a larger set of people, i'd go with KVM too.
Secure containers as dwalsh described is a worthy improvement.
... SELinux labels will not make that situation any better, because an exploit somewhere in the large kernel API bypasses SELinux.
Dan Walsh's two replies are much more nuanced than you understand.
Rich.
That last phrase proves that you're being condescending with me, and that you didn't get my point at all.
best regards, H.
On Tue, 03 Sep 2013 10:10:32 -0400 Jay Greguske jgregusk@redhat.com wrote:
If we had SELinux policy enabled on the builders and used MLS on the chroots that would mitigate chroot-to-chroot attacks. I'm not sure if policy could prevent a chroot'ed process from getting access to the builder's certificate. If it could, I think getting SELinux working on the builders would be an easier path than re-writing koji to use VMs.
Maybe someone with more expertise could comment on the latter issue.
In the past we had selinux disabled on the builders, as mock didn't handle selinux very well at all and there were issues. (even in permissive mode).
With this switch to Fedora 19 for builders, we also enabled selinux in permissive mode to gather information on any outstanding issues/avcs.
Ideally I would like to get them all to enforcing and make sure we lock down the builds as much as we are able from the vm.
kevin
On Tue, Sep 03, 2013 at 09:48:52AM -0600, Kevin Fenzi wrote:
On Tue, 03 Sep 2013 10:10:32 -0400 Jay Greguske jgregusk@redhat.com wrote:
If we had SELinux policy enabled on the builders and used MLS on the chroots that would mitigate chroot-to-chroot attacks. I'm not sure if policy could prevent a chroot'ed process from getting access to the builder's certificate. If it could, I think getting SELinux working on the builders would be an easier path than re-writing koji to use VMs.
Maybe someone with more expertise could comment on the latter issue.
In the past we had selinux disabled on the builders, as mock didn't handle selinux very well at all and there were issues. (even in permissive mode).
With this switch to Fedora 19 for builders, we also enabled selinux in permissive mode to gather information on any outstanding issues/avcs.
Ideally I would like to get them all to enforcing and make sure we lock down the builds as much as we are able from the vm.
the main issue is that mock should do the transition to a different domain once it run anything in chroot. I do have a patch but I was not able to make a policy for the transition ( or my patch is buggy ) and I didn't look at it since a few weeks. I can send it if someone want to take a look.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/03/2013 12:29 PM, Michael scherer wrote:
On Tue, Sep 03, 2013 at 09:48:52AM -0600, Kevin Fenzi wrote:
On Tue, 03 Sep 2013 10:10:32 -0400 Jay Greguske jgregusk@redhat.com wrote:
If we had SELinux policy enabled on the builders and used MLS on the chroots that would mitigate chroot-to-chroot attacks. I'm not sure if policy could prevent a chroot'ed process from getting access to the builder's certificate. If it could, I think getting SELinux working on the builders would be an easier path than re-writing koji to use VMs.
Maybe someone with more expertise could comment on the latter issue.
In the past we had selinux disabled on the builders, as mock didn't handle selinux very well at all and there were issues. (even in permissive mode).
With this switch to Fedora 19 for builders, we also enabled selinux in permissive mode to gather information on any outstanding issues/avcs.
Ideally I would like to get them all to enforcing and make sure we lock down the builds as much as we are able from the vm.
the main issue is that mock should do the transition to a different domain once it run anything in chroot. I do have a patch but I was not able to make a policy for the transition ( or my patch is buggy ) and I didn't look at it since a few weeks. I can send it if someone want to take a look.
Yes The builders should run each mock with a unique MCS Label and then lock them down with SELinux. I would be willing to help with this.
This would be the easiest solution to the problem of separating out the chroots.
On 09/03/2013 01:54 PM, Daniel J Walsh wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/03/2013 12:29 PM, Michael scherer wrote:
On Tue, Sep 03, 2013 at 09:48:52AM -0600, Kevin Fenzi wrote:
On Tue, 03 Sep 2013 10:10:32 -0400 Jay Greguske jgregusk@redhat.com wrote:
If we had SELinux policy enabled on the builders and used MLS on the chroots that would mitigate chroot-to-chroot attacks. I'm not sure if policy could prevent a chroot'ed process from getting access to the builder's certificate. If it could, I think getting SELinux working on the builders would be an easier path than re-writing koji to use VMs.
Maybe someone with more expertise could comment on the latter issue.
In the past we had selinux disabled on the builders, as mock didn't handle selinux very well at all and there were issues. (even in permissive mode).
With this switch to Fedora 19 for builders, we also enabled selinux in permissive mode to gather information on any outstanding issues/avcs.
Ideally I would like to get them all to enforcing and make sure we lock down the builds as much as we are able from the vm.
the main issue is that mock should do the transition to a different domain once it run anything in chroot. I do have a patch but I was not able to make a policy for the transition ( or my patch is buggy ) and I didn't look at it since a few weeks. I can send it if someone want to take a look.
Yes The builders should run each mock with a unique MCS Label and then lock them down with SELinux. I would be willing to help with this.
This would be the easiest solution to the problem of separating out the chroots.
Are you confident we can protect the host itself from attacks from a mock chroot?
- Jay
Le mardi 03 septembre 2013 à 15:37 -0400, Jay Greguske a écrit :
On 09/03/2013 01:54 PM, Daniel J Walsh wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/03/2013 12:29 PM, Michael scherer wrote:
On Tue, Sep 03, 2013 at 09:48:52AM -0600, Kevin Fenzi wrote:
On Tue, 03 Sep 2013 10:10:32 -0400 Jay Greguske jgregusk@redhat.com wrote:
If we had SELinux policy enabled on the builders and used MLS on the chroots that would mitigate chroot-to-chroot attacks. I'm not sure if policy could prevent a chroot'ed process from getting access to the builder's certificate. If it could, I think getting SELinux working on the builders would be an easier path than re-writing koji to use VMs.
Maybe someone with more expertise could comment on the latter issue.
In the past we had selinux disabled on the builders, as mock didn't handle selinux very well at all and there were issues. (even in permissive mode).
With this switch to Fedora 19 for builders, we also enabled selinux in permissive mode to gather information on any outstanding issues/avcs.
Ideally I would like to get them all to enforcing and make sure we lock down the builds as much as we are able from the vm.
the main issue is that mock should do the transition to a different domain once it run anything in chroot. I do have a patch but I was not able to make a policy for the transition ( or my patch is buggy ) and I didn't look at it since a few weeks. I can send it if someone want to take a look.
Yes The builders should run each mock with a unique MCS Label and then lock them down with SELinux. I would be willing to help with this.
This would be the easiest solution to the problem of separating out the chroots.
Are you confident we can protect the host itself from attacks from a mock chroot?
That's what Openshift Online use, and according to Dan, it resisted so far, and not because no one tried.
You have to balance the density/efficiency/overhead vs the protection. Something like cubes running in a VM over a VM from a different technology would be more secure than a regular shared ssh server, but there is a price :)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/03/2013 03:37 PM, Jay Greguske wrote:
On 09/03/2013 01:54 PM, Daniel J Walsh wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/03/2013 12:29 PM, Michael scherer wrote:
On Tue, Sep 03, 2013 at 09:48:52AM -0600, Kevin Fenzi wrote:
On Tue, 03 Sep 2013 10:10:32 -0400 Jay Greguske jgregusk@redhat.com wrote:
If we had SELinux policy enabled on the builders and used MLS on the chroots that would mitigate chroot-to-chroot attacks. I'm not sure if policy could prevent a chroot'ed process from getting access to the builder's certificate. If it could, I think getting SELinux working on the builders would be an easier path than re-writing koji to use VMs.
Maybe someone with more expertise could comment on the latter issue.
In the past we had selinux disabled on the builders, as mock didn't handle selinux very well at all and there were issues. (even in permissive mode).
With this switch to Fedora 19 for builders, we also enabled selinux in permissive mode to gather information on any outstanding issues/avcs.
Ideally I would like to get them all to enforcing and make sure we lock down the builds as much as we are able from the vm.
the main issue is that mock should do the transition to a different domain once it run anything in chroot. I do have a patch but I was not able to make a policy for the transition ( or my patch is buggy ) and I didn't look at it since a few weeks. I can send it if someone want to take a look.
Yes The builders should run each mock with a unique MCS Label and then lock them down with SELinux. I would be willing to help with this.
This would be the easiest solution to the problem of separating out the chroots.
Are you confident we can protect the host itself from attacks from a mock chroot?
- Jay
I am confident it will protect the host better then we do now. You still end up running a root process on the system and depending on what capabilities we have to give the actual build procedure will determine the protection.
If we could at least get the systems running in permissive mode and the mock build running as mock_t we could look at the avc's that are generated and get an idea of the actual privs required. If we can separate mock into to sections, one to do the setup as a priv process, and the second part to do execute the code that was uploaded by the user, mock_t and mock_confined_t, we could probably lock the system down tighter.
This is a little different then openshift in that we are allowing them to run as root.
Once we have containers implemented on RHEL7 we would want to also take advantage of running the mock environments in a container with SELinux.
On 09/03/2013 12:29 PM, Michael scherer wrote:
On Tue, Sep 03, 2013 at 09:48:52AM -0600, Kevin Fenzi wrote:
On Tue, 03 Sep 2013 10:10:32 -0400 Jay Greguske jgregusk@redhat.com wrote:
If we had SELinux policy enabled on the builders and used MLS on the chroots that would mitigate chroot-to-chroot attacks. I'm not sure if policy could prevent a chroot'ed process from getting access to the builder's certificate. If it could, I think getting SELinux working on the builders would be an easier path than re-writing koji to use VMs.
Maybe someone with more expertise could comment on the latter issue.
In the past we had selinux disabled on the builders, as mock didn't handle selinux very well at all and there were issues. (even in permissive mode).
With this switch to Fedora 19 for builders, we also enabled selinux in permissive mode to gather information on any outstanding issues/avcs.
Ideally I would like to get them all to enforcing and make sure we lock down the builds as much as we are able from the vm.
the main issue is that mock should do the transition to a different domain once it run anything in chroot. I do have a patch but I was not able to make a policy for the transition ( or my patch is buggy ) and I didn't look at it since a few weeks. I can send it if someone want to take a look.
Please post it. :)
Le mardi 03 septembre 2013 à 15:37 -0400, Jay Greguske a écrit :
On 09/03/2013 12:29 PM, Michael scherer wrote:
On Tue, Sep 03, 2013 at 09:48:52AM -0600, Kevin Fenzi wrote:
On Tue, 03 Sep 2013 10:10:32 -0400 Jay Greguske jgregusk@redhat.com wrote:
If we had SELinux policy enabled on the builders and used MLS on the chroots that would mitigate chroot-to-chroot attacks. I'm not sure if policy could prevent a chroot'ed process from getting access to the builder's certificate. If it could, I think getting SELinux working on the builders would be an easier path than re-writing koji to use VMs.
Maybe someone with more expertise could comment on the latter issue.
In the past we had selinux disabled on the builders, as mock didn't handle selinux very well at all and there were issues. (even in permissive mode).
With this switch to Fedora 19 for builders, we also enabled selinux in permissive mode to gather information on any outstanding issues/avcs.
Ideally I would like to get them all to enforcing and make sure we lock down the builds as much as we are able from the vm.
the main issue is that mock should do the transition to a different domain once it run anything in chroot. I do have a patch but I was not able to make a policy for the transition ( or my patch is buggy ) and I didn't look at it since a few weeks. I can send it if someone want to take a look.
Please post it. :)
Sure, here it is.
I just rebased on newer mock yesterday, and didn't tested at all ( it didn't rebase well, so maybe there is something missing ). I also didn't spent much time on the integration on a config point of view, ie config for each domain, or that's not needed, etc, etc. But that's polish I plan to keep once I had it working (and i do not remember the status at all, maybe that's completely broken and will not have time to work on it before 2 weeks )
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/04/2013 03:48 PM, Michael Scherer wrote:
Le mardi 03 septembre 2013 à 15:37 -0400, Jay Greguske a écrit :
On 09/03/2013 12:29 PM, Michael scherer wrote:
On Tue, Sep 03, 2013 at 09:48:52AM -0600, Kevin Fenzi wrote:
On Tue, 03 Sep 2013 10:10:32 -0400 Jay Greguske jgregusk@redhat.com wrote:
If we had SELinux policy enabled on the builders and used MLS on the chroots that would mitigate chroot-to-chroot attacks. I'm not sure if policy could prevent a chroot'ed process from getting access to the builder's certificate. If it could, I think getting SELinux working on the builders would be an easier path than re-writing koji to use VMs.
Maybe someone with more expertise could comment on the latter issue.
In the past we had selinux disabled on the builders, as mock didn't handle selinux very well at all and there were issues. (even in permissive mode).
With this switch to Fedora 19 for builders, we also enabled selinux in permissive mode to gather information on any outstanding issues/avcs.
Ideally I would like to get them all to enforcing and make sure we lock down the builds as much as we are able from the vm.
the main issue is that mock should do the transition to a different domain once it run anything in chroot. I do have a patch but I was not able to make a policy for the transition ( or my patch is buggy ) and I didn't look at it since a few weeks. I can send it if someone want to take a look.
Please post it. :)
Sure, here it is.
I just rebased on newer mock yesterday, and didn't tested at all ( it didn't rebase well, so maybe there is something missing ). I also didn't spent much time on the integration on a config point of view, ie config for each domain, or that's not needed, etc, etc. But that's polish I plan to keep once I had it working (and i do not remember the status at all, maybe that's completely broken and will not have time to work on it before 2 weeks )
What happens when you tried to run it? Did it run in permissive mode?
On Fri, 2013-08-30 at 11:39 +0200, Miroslav Suchý wrote:
Hi, I would like to get your feedback about COPR [1]
[1] http://miroslav.suchy.cz/blog/archives/2013/08/29/what_is_copr/index.html
We are the beggining and there are two options of where we can go: http://miroslav.suchy.cz/blog/archives/2013/08/29/copr_and_integration_with_... http://miroslav.suchy.cz/blog/archives/2013/08/30/copr_implemented_using_obs...
I would like to ask *you* what is your opinion?
First,thank you very much for the blog post.
In regards to this I think it is difficult or should I say time consuming to get people to move from what they are already used to. I think OBS works differently from Koji. Personally I prefer what we have, but this is just a matter of preference. I think we need to consider what is easy for users/developers to use.
I think also security needs to be looked into as described in one of the earlier posts.
There are features that are there in the other system , I think we can easily get a team that can build something similar for us.
There are a lot of great minds here. The most attractive tip for me was:
build package in VM, which is safer then Koji (just chroot in Koji). And that VM is without network, which is safer then current COPR which allows network connections.
This is something that needs to be worked on.
Thank you again.
-- Miroslav Suchy, RHCE, RHCDS Red Hat, Software Engineer, #brno, #devexp, #fedora-buildsys
----- Original Message -----
Hi, I would like to get your feedback about COPR [1]
[1] http://miroslav.suchy.cz/blog/archives/2013/08/29/what_is_copr/index.html
We are the beggining and there are two options of where we can go: http://miroslav.suchy.cz/blog/archives/2013/08/29/copr_and_integration_with_... http://miroslav.suchy.cz/blog/archives/2013/08/30/copr_implemented_using_obs...
Do we consider third option - to replace Koji and Copr by OBS? The thing is - I really don't like idea of having two different build systems, forcing people to use two different set of tools (and yeah, I mean command here too;-), two different workflows... And yes, we already do it - consider package reviews. When you start review, you are on your own, then you have to go through the review process, then you have to learn dist-git/ Koji. Imagine - you start your review in Copr part of Koji, using one set of tools, once you're happy, you click review button somewhere in UI, automated tests are run based on fedora-review, reviewers get notified there's a new package, reviews/waives issues and voila package is in the main set of packages, you still use the same tools, same workflow. Even we can re-review packages in main repo periodically - mostly that automated one. This is my dream but if I understand OBS, it's definitely possible there (I had an account there even it was public but have not used it for several years). So short summary - make packagers life easier, let's have one solution, one set of tools and for really hostile packages (that do not fit main Fedora tree) separate instance of build system to be used for RPM Fusion like style packages.
Btw. this does not mean I want to replace Koji with OBS, just an option, I'd like to see Koji as that ultimate tool to solve our problems.
I would like to ask *you* what is your opinion?
That's my opinion and my 1 haler ;-).
Jaroslav
-- Miroslav Suchy, RHCE, RHCDS Red Hat, Software Engineer, #brno, #devexp, #fedora-buildsys -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Ultimately, we ended up (again) discussing "should we replace Koji by OBS ?"
Unless there is commitment from people to maintain this, we can't even consider this as a solution.
H.
On Tue, Sep 3, 2013 at 11:23 AM, 80 karlthered@gmail.com wrote:
Ultimately, we ended up (again) discussing "should we replace Koji by OBS ?"
Unless there is commitment from people to maintain this, we can't even consider this as a solution.
True.
I think we reallly need to pick out what we like about OBS . review that and ensure we modify koji to do it. I mean we have a really sharp crew here. Why not?
H.
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
On 09/03/2013 03:41 PM, Frankie Onuonga wrote:
I mean we have a really sharp crew here. Why not?
We have sharp crew, but they have a lot of other work to do. So thinking about how to offload some developer work with others make IMO sense.
On Wed, 2013-09-04 at 08:54 +0200, Miroslav Suchý wrote:
On 09/03/2013 03:41 PM, Frankie Onuonga wrote:
I mean we have a really sharp crew here. Why not?
We have sharp crew, but they have a lot of other work to do. So thinking about how to offload some developer work with others make IMO sense.
Thank you for the response. Yes I understand. It makes sense to me too. I meant the community in general :-) . And yes you are right.
-- Miroslav Suchy, RHCE, RHCDS Red Hat, Software Engineer, #brno, #devexp, #fedora-buildsys
On Tue, Sep 3, 2013 at 11:54 PM, Miroslav Suchý msuchy@redhat.com wrote:
On 09/03/2013 03:41 PM, Frankie Onuonga wrote:
I mean we have a really sharp crew here. Why not?
We have sharp crew, but they have a lot of other work to do. So thinking about how to offload some developer work with others make IMO sense.
Note: Our sysadmin limitations are a lot more severe than our developer constraints. With that in mind, I'd say if you're looking to run this in Fedora Infrastructure (as opposed to making it a RH service), OBS is not going to happen. There's too much additional burden in running it.
Getting things merged into koji is better. If mikem is willing to build the necessary features into koji then it is more desirable to run a second instance of koji than to run an entirely new system using an entirely new language stack. In the past we were a bit leary of building on top of koji as it is designed to do something quite different than what we need for implementing coprs. koji makes many demands in order to be able to track and make (at least theoretically) reproducible what has been built on it in the past. Coprs doesn't need this and in some cases (being able to build against arbitrary third-party repos at arbitrary points in time) is at odds with koji's goal of reproducability. Talking to mikem at flock, though, he seems interested in the use-cases so adding the necessary features and the ability to turn some features off may be doable for a separate koji instance that we run to implement coprs.
-Toshio
Hi, based on your feedback I decided to go with current code and integrate Koji as backend for Copr later.
I see three main reasons:
* A lot of you disagree with OBS. And no one is really excited from OBS.
* I'm the only full time developer of Copr; there is no community around OBS in Fedora. If something happen to me, there is no replacement and the project will probably stay in zombie state for quite long. If such issue happen with Copr+Koji, the changes will stay in Koji and rel-eng team can continue with development.
* OBS and Koji is soo much different (although I think OBS is superior). It really does not have sense to have two such different build systems for long term. And I do not think I can persuade Fedora Infrastructure team in long term to switch to OBS for main Fedora.
On the other hand, I do not think we can close the gap between Copr/Koji and OBS now nor in future as OBS have more resources. So I will try to get (in spare time) OBS to Fedora anyway and build some community around it. And revisit the decision in two-three years. If you are willing to help me with packaging of OBS and get there some Fedora stuff (e.g mock) please ping me off-list.
Right now I want to get current Copr out of the door as soon as possible. * which means package it, so it can be easily upgradable (frontend, cli are done, backend is on the way). * give backend more disk space * add chroots for building SCL I hope that I can do that during September. And I expect release during October.
After this release I plan to work with mikem on integration with Koji, which will last those 7 months, so around Spring 2014 we can roll out version with Koji as backend.
If you want to help me with Copr you are more then welcome. See https://fedorahosted.org/copr/ for mailing list address and git repository.
Mirek
On Thu, 05 Sep 2013 10:12:13 +0200 Miroslav Suchy msuchy@redhat.com wrote:
Hi, based on your feedback I decided to go with current code and integrate Koji as backend for Copr later.
Great. :)
Thanks for collecting all the data and keeping everyone in the loop. ...snip...
Right now I want to get current Copr out of the door as soon as possible.
- which means package it, so it can be easily upgradable (frontend,
cli are done, backend is on the way).
- give backend more disk space
- add chroots for building SCL
I hope that I can do that during September. And I expect release during October.
Please do coordinate/keep fedora infrastructure in the loop on these items.
After this release I plan to work with mikem on integration with Koji, which will last those 7 months, so around Spring 2014 we can roll out version with Koji as backend.
If you want to help me with Copr you are more then welcome. See https://fedorahosted.org/copr/ for mailing list address and git repository.
Thanks!
kevin
On Thu, Sep 5, 2013 at 2:12 AM, Miroslav Suchy msuchy@redhat.com wrote:
On the other hand, I do not think we can close the gap between Copr/Koji and OBS now nor in future as OBS have more resources. So I will try to get (in spare time) OBS to Fedora anyway and build some community around it. And revisit the decision in two-three years.
I think this is a good approach, and I'm happy to swap reviews for the rubygems you need. Like you implied, a lot could change in two or three years.
- Ken
-
Colin Walters -
Daniel J Walsh -
Daniel P. Berrange -
Florian Weimer -
Frankie -
Haïkel Guémar -
Jan Zelený -
Jaroslav Reznik -
Jay Greguske -
Ken Dreyer -
Kevin Fenzi -
Lukas Zapletal -
Matthew Miller -
Michael Scherer -
Miroslav Suchý -
Paul Wouters -
Peter Robinson -
Richard W.M. Jones -
Simo Sorce -
Toshio Kuratomi