-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi All,
The initial idea is to configure Koji and make it available to the community.
Thanks to Karanbir/Fabian we already got the hardware and installation is on going.
But first, we would like to ask for feedback:
1/ PKI setup, a proposal: - - koji-web use a certificate signed by an external CA (and obviously trusted) - - the rest of the koji architecture (hub and kojid) will use a self-signed CA that we'll use to also generate other certs. The proposal is to gpg encrypt the CA within a non-public GIT repo. Talking with Fabian, he already use this method for other infrastructure project. - - the clients (at the beginning git.c.o) will use self-signed CA.
This need to be discussed in the light of future integration of different user facing tools (koji, git, etc...) and if we want to provide koji client accesses, as Fedora project does.
2/ Hostnames to use: - - After a round on #centos-devel, cbs.centos.org was the best we can come up with. Comments ? - - For the builders machine, we should decide on a decent naming as this info appears in RPM metadata. i.e : builder01.cbs.centos.org, builder02.cbs.centos.org, etc... Do we want to deal with different "architecture family" within the name (e.g ARM) ? i.e : x86-builder01.cbs.centos.org, arm-builder01.cbs.centos.org
Your comments are very welcome!
cheers, - -- Thomas 'alphacc' Oulevey
Hi all,
just be careful with the self signed certs to use at least SHA256, not MD5, since openssl in Red Hat 7 does not support MD5 any more. For example if you want to run RHEL7/Centos7 as koji builder, you will have a problem with MD5 certs. I had the same problem with an existing koji and RHEL7 builders. :)
Cheers, Peter Bojtos ULX Ltd.
----- Eredeti üzenet -----
Feladó: "Thomas Oulevey" thomas.oulevey@cern.ch Címzett: centos-devel@centos.org Elküldött üzenetek: Csütörtök, 2014. Június 26. 14:56:52 Tárgy: [CentOS-devel] Community build system
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi All,
The initial idea is to configure Koji and make it available to the community.
Thanks to Karanbir/Fabian we already got the hardware and installation is on going.
But first, we would like to ask for feedback:
1/ PKI setup, a proposal:
- koji-web use a certificate signed by an external CA (and obviously
trusted)
- the rest of the koji architecture (hub and kojid) will use a
self-signed CA that we'll use to also generate other certs. The proposal is to gpg encrypt the CA within a non-public GIT repo. Talking with Fabian, he already use this method for other infrastructure project.
- the clients (at the beginning git.c.o) will use self-signed CA.
This need to be discussed in the light of future integration of different user facing tools (koji, git, etc...) and if we want to provide koji client accesses, as Fedora project does.
2/ Hostnames to use:
- After a round on #centos-devel, cbs.centos.org was the best we can
come up with. Comments ?
- For the builders machine, we should decide on a decent naming as
this info appears in RPM metadata. i.e : builder01.cbs.centos.org, builder02.cbs.centos.org, etc... Do we want to deal with different "architecture family" within the name (e.g ARM) ? i.e : x86-builder01.cbs.centos.org, arm-builder01.cbs.centos.org
Your comments are very welcome!
cheers,
Thomas 'alphacc' Oulevey -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQEcBAEBAgAGBQJTrBiUAAoJEH2Wn86OP8Ni5xYH/jYyRN+gr6r8v8zih/yF7fOi INws9FC9+U+kP1r9Wsfg6Ge92uQJdX7t5G6Oom89ZcHoshVY685Cv647Es5ySkMP ls5NBXQu92l5QcXFOSP6gcThOyd7bO7Kh5onziULmIkdDWkEdz12kBPI2bVPQqwI JrZVTwvHSEN+5sVBccMKGYmiqFhs/qt12i/EaK2bvWCs/CRcrjyKJiHhlej3Zo+7 nSo8pwFCsq2T08FWfvnWYfjzFs8RmpFclBGakYRRyKk74TV63jKExqAL1zJGhaSF yZxYt8XZeXrv5fdxXtKzA0WL8rf3tKN0rRC/mMcQUo28OaN53Wxuzw/YCRnN0po= =2Hqy -----END PGP SIGNATURE----- _______________________________________________ CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 26/06/14 14:56, Thomas Oulevey wrote:
Hi All,
The initial idea is to configure Koji and make it available to the community.
Thanks to Karanbir/Fabian we already got the hardware and installation is on going.
But first, we would like to ask for feedback:
1/ PKI setup, a proposal: - koji-web use a certificate signed by an external CA (and obviously trusted) - the rest of the koji architecture (hub and kojid) will use a self-signed CA that we'll use to also generate other certs. The proposal is to gpg encrypt the CA within a non-public GIT repo. Talking with Fabian, he already use this method for other infrastructure project. - the clients (at the beginning git.c.o) will use self-signed CA.
This need to be discussed in the light of future integration of different user facing tools (koji, git, etc...) and if we want to provide koji client accesses, as Fedora project does.
Well, I'll (obviously) agree with what we discussed previously. But just keep in mind that normally we'll not have a bunch of clients cert to generate, because the normal flow will go like this (if i'm not wrong) : SIGs -> git commit & push -> git.c.o -> hooks -> koji So in that case, all builds will be triggered by Git, and so we don't have to generate client certs for people submitting build jobs in the queue . That's also worth noting than when we say "community" that doesn't mean that we open buildservice to the wide world (no OBS here :-) ), just that SIGs will build packages on that Koji setup (in a automated way)
2/ Hostnames to use: - After a round on #centos-devel, cbs.centos.org was the best we can come up with. Comments ? - For the builders machine, we should decide on a decent naming as this info appears in RPM metadata. i.e : builder01.cbs.centos.org, builder02.cbs.centos.org, etc... Do we want to deal with different "architecture family" within the name (e.g ARM) ? i.e : x86-builder01.cbs.centos.org, arm-builder01.cbs.centos.org
Your comments are very welcome!
cheers,
I'm fine with the $arch in the fqdn (for logging purposes) so let's say : builder01-x86.cbs.centos.org ? (or the reverse, as you proposed : $arch-builder${num}.cbs.centos.org
Cheers,
- -- Fabian Arrotin gpg key: 56BEC54E | twitter: @arrfab
On 06/26/2014 02:13 PM, Fabian Arrotin wrote:
On 26/06/14 14:56, Thomas Oulevey wrote:
Hi All,
The initial idea is to configure Koji and make it available to the community.
Thanks to Karanbir/Fabian we already got the hardware and installation is on going.
But first, we would like to ask for feedback:
1/ PKI setup, a proposal: - koji-web use a certificate signed by an external CA (and obviously trusted) - the rest of the koji architecture (hub and kojid) will use a self-signed CA that we'll use to also generate other certs. The proposal is to gpg encrypt the CA within a non-public GIT repo. Talking with Fabian, he already use this method for other infrastructure project. - the clients (at the beginning git.c.o) will use self-signed CA.
This need to be discussed in the light of future integration of different user facing tools (koji, git, etc...) and if we want to provide koji client accesses, as Fedora project does.
Well, I'll (obviously) agree with what we discussed previously. But just keep in mind that normally we'll not have a bunch of clients cert to generate, because the normal flow will go like this (if i'm not wrong) : SIGs -> git commit & push -> git.c.o -> hooks -> koji So in that case, all builds will be triggered by Git, and so we don't have to generate client certs for people submitting build jobs in the queue .
I agree, but users should still be able to run scratch builds and get their logs and status / tags etc - so we will need some mechanism for those bits to happen, I assumed this would be via the koji clients rather than a web interface?
That's also worth noting than when we say "community" that doesn't mean that we open buildservice to the wide world (no OBS here :-) ), just that SIGs will build packages on that Koji setup (in a automated way)
2/ Hostnames to use: - After a round on #centos-devel, cbs.centos.org was the best we can come up with. Comments ? - For the builders machine, we should decide on a decent naming as this info appears in RPM metadata. i.e : builder01.cbs.centos.org, builder02.cbs.centos.org, etc... Do we want to deal with different "architecture family" within the name (e.g ARM) ? i.e : x86-builder01.cbs.centos.org, arm-builder01.cbs.centos.org
Your comments are very welcome!
cheers,
I'm fine with the $arch in the fqdn (for logging purposes) so let's say : builder01-x86.cbs.centos.org ? (or the reverse, as you proposed : $arch-builder${num}.cbs.centos.org
why not drop the word 'builder' completely, x8664-0.cbs.c.o etc
On 26/06/14 15:49, Karanbir Singh wrote:
On 06/26/2014 02:13 PM, Fabian Arrotin wrote:
On 26/06/14 14:56, Thomas Oulevey wrote:
Hi All,
The initial idea is to configure Koji and make it available to the community.
Thanks to Karanbir/Fabian we already got the hardware and installation is on going.
But first, we would like to ask for feedback:
1/ PKI setup, a proposal: - koji-web use a certificate signed by an external CA (and obviously trusted) - the rest of the koji architecture (hub and kojid) will use a self-signed CA that we'll use to also generate other certs. The proposal is to gpg encrypt the CA within a non-public GIT repo. Talking with Fabian, he already use this method for other infrastructure project. - the clients (at the beginning git.c.o) will use self-signed CA.
This need to be discussed in the light of future integration of different user facing tools (koji, git, etc...) and if we want to provide koji client accesses, as Fedora project does.
Well, I'll (obviously) agree with what we discussed previously. But just keep in mind that normally we'll not have a bunch of clients cert to generate, because the normal flow will go like this (if i'm not wrong) : SIGs -> git commit & push -> git.c.o -> hooks -> koji So in that case, all builds will be triggered by Git, and so we don't have to generate client certs for people submitting build jobs in the queue .
I agree, but users should still be able to run scratch builds and get their logs and status / tags etc - so we will need some mechanism for those bits to happen, I assumed this would be via the koji clients rather than a web interface?
yes, that's true, so using the certs we'll sign with our "self-signed" CA
That's also worth noting than when we say "community" that doesn't mean that we open buildservice to the wide world (no OBS here :-) ), just that SIGs will build packages on that Koji setup (in a automated way)
2/ Hostnames to use: - After a round on #centos-devel, cbs.centos.org was the best we can come up with. Comments ? - For the builders machine, we should decide on a decent naming as this info appears in RPM metadata. i.e : builder01.cbs.centos.org, builder02.cbs.centos.org, etc... Do we want to deal with different "architecture family" within the name (e.g ARM) ? i.e : x86-builder01.cbs.centos.org, arm-builder01.cbs.centos.org
Your comments are very welcome!
cheers,
I'm fine with the $arch in the fqdn (for logging purposes) so let's say : builder01-x86.cbs.centos.org ? (or the reverse, as you proposed : $arch-builder${num}.cbs.centos.org
why not drop the word 'builder' completely, x8664-0.cbs.c.o etc
fine for me too .. don't want to start a "pets vs cattle" debate here :-)
On 06/26/2014 03:21 PM, Fabian Arrotin wrote:
On 26/06/14 15:49, Karanbir Singh wrote:
On 06/26/2014 02:13 PM, Fabian Arrotin wrote:
On 26/06/14 14:56, Thomas Oulevey wrote:
Hi All,
The initial idea is to configure Koji and make it available to the community.
Thanks to Karanbir/Fabian we already got the hardware and installation is on going.
But first, we would like to ask for feedback:
1/ PKI setup, a proposal: - koji-web use a certificate signed by an external CA (and obviously trusted) - the rest of the koji architecture (hub and kojid) will use a self-signed CA that we'll use to also generate other certs. The proposal is to gpg encrypt the CA within a non-public GIT repo. Talking with Fabian, he already use this method for other infrastructure project. - the clients (at the beginning git.c.o) will use self-signed CA.
This need to be discussed in the light of future integration of different user facing tools (koji, git, etc...) and if we want to provide koji client accesses, as Fedora project does.
Well, I'll (obviously) agree with what we discussed previously. But just keep in mind that normally we'll not have a bunch of clients cert to generate, because the normal flow will go like this (if i'm not wrong) : SIGs -> git commit & push -> git.c.o -> hooks -> koji So in that case, all builds will be triggered by Git, and so we don't have to generate client certs for people submitting build jobs in the queue .
I agree, but users should still be able to run scratch builds and get their logs and status / tags etc - so we will need some mechanism for those bits to happen, I assumed this would be via the koji clients rather than a web interface?
yes, that's true, so using the certs we'll sign with our "self-signed" CA
could this CA be shared with gitblit as well ? that can do cert based auth too, and afaik, it will handle and external CA
That's also worth noting than when we say "community" that doesn't mean that we open buildservice to the wide world (no OBS here :-) ), just that SIGs will build packages on that Koji setup (in a automated way)
2/ Hostnames to use: - After a round on #centos-devel, cbs.centos.org was the best we can come up with. Comments ? - For the builders machine, we should decide on a decent naming as this info appears in RPM metadata. i.e : builder01.cbs.centos.org, builder02.cbs.centos.org, etc... Do we want to deal with different "architecture family" within the name (e.g ARM) ? i.e : x86-builder01.cbs.centos.org, arm-builder01.cbs.centos.org
Your comments are very welcome!
cheers,
I'm fine with the $arch in the fqdn (for logging purposes) so let's say : builder01-x86.cbs.centos.org ? (or the reverse, as you proposed : $arch-builder${num}.cbs.centos.org
why not drop the word 'builder' completely, x8664-0.cbs.c.o etc
fine for me too .. don't want to start a "pets vs cattle" debate here :-)
On 06/26/2014 07:19 PM, Karanbir Singh wrote:
On 06/26/2014 02:13 PM, Fabian Arrotin wrote:
On 26/06/14 14:56, Thomas Oulevey wrote:
Hi All, The initial idea is to configure Koji and make it available to the community. Thanks to Karanbir/Fabian we already got the hardware and installation is on going. But first, we would like to ask for feedback: 1/ PKI setup, a proposal: - koji-web use a certificate signed by an external CA (and obviously trusted) - the rest of the koji architecture (hub and kojid) will use a self-signed CA that we'll use to also generate other certs. The proposal is to gpg encrypt the CA within a non-public GIT repo. Talking with Fabian, he already use this method for other infrastructure project. - the clients (at the beginning git.c.o) will use self-signed CA. This need to be discussed in the light of future integration of different user facing tools (koji, git, etc...) and if we want to provide koji client accesses, as Fedora project does.
Well, I'll (obviously) agree with what we discussed previously. But just keep in mind that normally we'll not have a bunch of clients cert to generate, because the normal flow will go like this (if i'm not wrong) : SIGs -> git commit & push -> git.c.o -> hooks -> koji So in that case, all builds will be triggered by Git, and so we don't have to generate client certs for people submitting build jobs in the queue .
I agree, but users should still be able to run scratch builds and get their logs and status / tags etc - so we will need some mechanism for those bits to happen, I assumed this would be via the koji clients rather than a web interface?
+1, we need a way to do scratch builds for SIGs.
That's also worth noting than when we say "community" that doesn't mean that we open buildservice to the wide world (no OBS here :-) ), just that SIGs will build packages on that Koji setup (in a automated way)
2/ Hostnames to use: - After a round on #centos-devel, cbs.centos.org was the best we can come up with. Comments ? - For the builders machine, we should decide on a decent naming as this info appears in RPM metadata. i.e : builder01.cbs.centos.org, builder02.cbs.centos.org, etc... Do we want to deal with different "architecture family" within the name (e.g ARM) ? i.e : x86-builder01.cbs.centos.org, arm-builder01.cbs.centos.org Your comments are very welcome! cheers,
I'm fine with the $arch in the fqdn (for logging purposes) so let's say : builder01-x86.cbs.centos.org ? (or the reverse, as you proposed : $arch-builder${num}.cbs.centos.org
why not drop the word 'builder' completely, x8664-0.cbs.c.o etc
On Thu, Jun 26, 2014 at 5:56 AM, Thomas Oulevey thomas.oulevey@cern.ch wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi All,
The initial idea is to configure Koji and make it available to the community.
Thanks to Karanbir/Fabian we already got the hardware and installation is on going.
But first, we would like to ask for feedback:
1/ PKI setup, a proposal:
- koji-web use a certificate signed by an external CA (and obviously
trusted)
- the rest of the koji architecture (hub and kojid) will use a
self-signed CA that we'll use to also generate other certs. The proposal is to gpg encrypt the CA within a non-public GIT repo. Talking with Fabian, he already use this method for other infrastructure project.
- the clients (at the beginning git.c.o) will use self-signed CA.
This need to be discussed in the light of future integration of different user facing tools (koji, git, etc...) and if we want to provide koji client accesses, as Fedora project does.
2/ Hostnames to use:
- After a round on #centos-devel, cbs.centos.org was the best we can
come up with. Comments ?
- For the builders machine, we should decide on a decent naming as
this info appears in RPM metadata. i.e : builder01.cbs.centos.org, builder02.cbs.centos.org, etc... Do we want to deal with different "architecture family" within the name (e.g ARM) ? i.e : x86-builder01.cbs.centos.org, arm-builder01.cbs.centos.org
Your comments are very welcome!
cheers,
+1 on the PKI setup.
For the hostnames, I don't see a reason the architecture is needed in the hostname.
-Jeff
On 06/26/2014 06:26 PM, Thomas Oulevey wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi All,
The initial idea is to configure Koji and make it available to the community.
Thanks to Karanbir/Fabian we already got the hardware and installation is on going.
But first, we would like to ask for feedback:
1/ PKI setup, a proposal:
- koji-web use a certificate signed by an external CA (and obviously
trusted)
- the rest of the koji architecture (hub and kojid) will use a
self-signed CA that we'll use to also generate other certs. The proposal is to gpg encrypt the CA within a non-public GIT repo. Talking with Fabian, he already use this method for other infrastructure project.
- the clients (at the beginning git.c.o) will use self-signed CA.
This need to be discussed in the light of future integration of different user facing tools (koji, git, etc...) and if we want to provide koji client accesses, as Fedora project does.
2/ Hostnames to use:
- After a round on #centos-devel, cbs.centos.org was the best we can
come up with. Comments ?
- For the builders machine, we should decide on a decent naming as
this info appears in RPM metadata. i.e : builder01.cbs.centos.org, builder02.cbs.centos.org, etc... Do we want to deal with different "architecture family" within the name (e.g ARM) ? i.e : x86-builder01.cbs.centos.org, arm-builder01.cbs.centos.org
Your comments are very welcome!
What would the workflow of RPMs after they are created in koji. How would they land up in respective repos? Will it be a automated method or manual method? This is done using Bodhi in Fedora, so looking for a similar or better solution here too.
Thanks, Lala
On 06/26/2014 07:48 PM, Lalatendu Mohanty wrote:
What would the workflow of RPMs after they are created in koji. How would they land up in respective repos? Will it be a automated method or manual method? This is done using Bodhi in Fedora, so looking for a similar or better solution here too.
i dont think this is quite decided as yet, so were open to options.
Worth keeping in mind that we have a proper complex signing system in place, so requests-to-release and errata notices etc can be created via a UI and potentially automated to some extent - but the actual sign + push will need to be done manually.
At this point we have 4 people who are able to sign and push, so we have reasonable cover.
Is there a process that folks are most familiar with in the fedora lands ?
On Thu, Jun 26, 2014 at 08:53:38PM +0100, Karanbir Singh wrote:
Is there a process that folks are most familiar with in the fedora lands ?
From a packager perspective, it's bodhi, either from the web UI or the
`fedpkg update` command run from the git repo where you just made your updates. This is... not a perfect system, but the next version of bodhi is getting ready to be deployed soon and has some nice improvements. http://fedoraproject.org/wiki/Bodhi/2.0
I don't know how well the current state of things meets your needs, but it'd be awesome to have CentOS contributors to the infrastructure.
-
Bojtos Péter -
Fabian Arrotin -
Jeff Sheltren -
Karanbir Singh -
Lalatendu Mohanty -
Matthew Miller -
Thomas Oulevey