Re: Metalink support
On Tue, Mar 11, 2008 at 06:16:09PM +0100, Bram Neijt wrote: > Hi everybody, > > My name is Bram and I'm one of the developers the metalink tools > project. I've heard that somebody tried to implement metalinks as part > of the mirrormanager project and failed to get an agreable patch. > > I'm new to mirrormanager but I would like to see if I can find a way > to help you guys with hosting metalinks in a usefull way. Even if it > means it has to be done outside of the mirrormanager. > > Are there any opinions floating around about how metalinks could be > implemented/created? > > Greetings, > Bram > > PS I have some ideas, but as I'm new to this list I don't want to > start dictating solutions. Feel free to invite me to do so ;-) Rene Leonhardt looked into this in early February and had a start on it, but I haven't heard back in several weeks. -- Matt Domsch Linux Technology Strategist, Dell Office of the CTO linux.dell.com & www.dell.com/linux ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
FAS2 ships!
FAS2 has shipped. Its getting a bit late in the evening so I'm not going ot enable the cron job qute yet so don't be surprised if your account information for shell access is stale until tomorrow morning. Most of our end users should be unaffected though. -Mike ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: another issue to fix with the FAS2 switch: Kojis ssl certificate
On Tue, 11 Mar 2008, Dennis Gilmore wrote: > On Tuesday 11 March 2008, Till Maas wrote: > > On Tue March 11 2008, Dennis Gilmore wrote: > > > On Tuesday 11 March 2008, Till Maas wrote: > > > > Hiyas, > > > > > > > > now that everyone needs to change his password, can we now also deploy > > > > the new certifcate for koji? This will make it possible to verify > > > > whether or not one can trust the certificate for koji and the ticket[1] > > > > is now 7 months old, i.e. about a full Fedora release cycle. Therefore > > > > I guess there won't be a better time than now. > > > > > > > > Regards, > > > > Till > > > > > > > > [1] https://fedorahosted.org/fedora-infrastructure/ticket/88 > > > > > > No, Because it will break user certs. To make it work would require > > > that users all get entirely new server cert files. We need to redo our > > > entire CA system. We also need to consider the ramifications for > > > Secondary arches, deploying a new CA would require each and every > > > Secondary arch to purchase a cert from the same CA. or somebody to > > > purchase a cert that covered *.koji.fedoraproject.org from the same CA. > > > > > > we are looking at deploying the hub on a separate box from the frontend > > > which would allow us to do what you are wanting but would not look after > > > secondary arches. > > > > How about making the hub (I assume this is only used by automated processes > > and not manually) listen on a different port than 443? Then the web > > interface could use the new well know certificate. The automated processes > > the internal ones, where imho using a own ca does not hurt. Also using a > > different port should be only a matter of configuring it once. > > The secondary arch instances could then use a cacert[0] certificate, which > > are free and are trusted by some browsers already for the web interface. > > if we use CACert we would have ship it in the browsers we supply. currently > no browser shipped with fedora does and if we did such we would use it for > all services. and would require changes to all users koji configs. people > who are not using fedora would be in the same situation as they are now. > AFAIK only CentOS ships browsers with CACerts root cert. > Side note about this, I'm pretty sure if we do it we can't call "firefox" "firefox" anymore. -Mike ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: another issue to fix with the FAS2 switch: Kojis ssl certificate
On Tuesday 11 March 2008, Till Maas wrote: > On Tue March 11 2008, Dennis Gilmore wrote: > > On Tuesday 11 March 2008, Till Maas wrote: > > > Hiyas, > > > > > > now that everyone needs to change his password, can we now also deploy > > > the new certifcate for koji? This will make it possible to verify > > > whether or not one can trust the certificate for koji and the ticket[1] > > > is now 7 months old, i.e. about a full Fedora release cycle. Therefore > > > I guess there won't be a better time than now. > > > > > > Regards, > > > Till > > > > > > [1] https://fedorahosted.org/fedora-infrastructure/ticket/88 > > > > No, Because it will break user certs. To make it work would require > > that users all get entirely new server cert files. We need to redo our > > entire CA system. We also need to consider the ramifications for > > Secondary arches, deploying a new CA would require each and every > > Secondary arch to purchase a cert from the same CA. or somebody to > > purchase a cert that covered *.koji.fedoraproject.org from the same CA. > > > > we are looking at deploying the hub on a separate box from the frontend > > which would allow us to do what you are wanting but would not look after > > secondary arches. > > How about making the hub (I assume this is only used by automated processes > and not manually) listen on a different port than 443? Then the web > interface could use the new well know certificate. The automated processes > the internal ones, where imho using a own ca does not hurt. Also using a > different port should be only a matter of configuring it once. > The secondary arch instances could then use a cacert[0] certificate, which > are free and are trusted by some browsers already for the web interface. if we use CACert we would have ship it in the browsers we supply. currently no browser shipped with fedora does and if we did such we would use it for all services. and would require changes to all users koji configs. people who are not using fedora would be in the same situation as they are now. AFAIK only CentOS ships browsers with CACerts root cert. > > We currently use 2 different CA's in our setup. One that is used only > > for user certs and one that is used for the builders and frontend. I > > would like to move to a new Single CA setup. In this world when you > > import your fedora user cert for browser authentication you would > > automatically recognise the CA. though this would only be valid for > > Fedora contributors. > > Is this only about Koji or Fedoraprojet in general? Imho it is better to > use a well known CA for the frontend (website) and an own one for internal > stuff instead of using an own one for everything. the user certs are used to authenticate the user for uploading new tarballs and koji/plague access. there is work underway to allow them to be used to authenticate for other fedora webapps also. Dennis signature.asc Description: This is a digitally signed message part. ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: another issue to fix with the FAS2 switch: Kojis ssl certificate
On Tue, 11 Mar 2008, Mike Bonnet wrote: > On Tue, 2008-03-11 at 21:52 +0100, Till Maas wrote: > > On Tue March 11 2008, Dennis Gilmore wrote: > > > On Tuesday 11 March 2008, Till Maas wrote: > > > > Hiyas, > > > > > > > > now that everyone needs to change his password, can we now also deploy > > > > the new certifcate for koji? This will make it possible to verify > > > > whether > > > > or not one can trust the certificate for koji and the ticket[1] is now 7 > > > > months old, i.e. about a full Fedora release cycle. Therefore I guess > > > > there won't be a better time than now. > > > > > > > > Regards, > > > > Till > > > > > > > > [1] https://fedorahosted.org/fedora-infrastructure/ticket/88 > > > > > > No, Because it will break user certs. To make it work would require that > > > users all get entirely new server cert files. We need to redo our entire > > > CA system. We also need to consider the ramifications for Secondary > > > arches, deploying a new CA would require each and every Secondary arch to > > > purchase a cert from the same CA. or somebody to purchase a cert that > > > covered *.koji.fedoraproject.org from the same CA. > > > > > > we are looking at deploying the hub on a separate box from the frontend > > > which would allow us to do what you are wanting but would not look after > > > secondary arches. > > > > How about making the hub (I assume this is only used by automated processes > > and not manually) listen on a different port than 443? Then the web > > interface > > could use the new well know certificate. The automated processes the > > internal > > ones, where imho using a own ca does not hurt. Also using a different port > > should be only a matter of configuring it once. > > The secondary arch instances could then use a cacert[0] certificate, which > > are > > free and are trusted by some browsers already for the web interface. > > The Koji cli communicates with the hub for all operations, so it would > require everyone to update their Koji config. In addition, I'm sure > running ssl on a non-standard port would mess with some people's > proxy/firewall setups. I don't think this is the best solution. > It's really not that we don't want to do this. It's a lot of work with high potential for breakage and annoyance to everyone and the benefit to most people is unclear. -Mike ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: another issue to fix with the FAS2 switch: Kojis ssl certificate
On Tue, 2008-03-11 at 21:52 +0100, Till Maas wrote: > On Tue March 11 2008, Dennis Gilmore wrote: > > On Tuesday 11 March 2008, Till Maas wrote: > > > Hiyas, > > > > > > now that everyone needs to change his password, can we now also deploy > > > the new certifcate for koji? This will make it possible to verify whether > > > or not one can trust the certificate for koji and the ticket[1] is now 7 > > > months old, i.e. about a full Fedora release cycle. Therefore I guess > > > there won't be a better time than now. > > > > > > Regards, > > > Till > > > > > > [1] https://fedorahosted.org/fedora-infrastructure/ticket/88 > > > > No, Because it will break user certs. To make it work would require that > > users all get entirely new server cert files. We need to redo our entire > > CA system. We also need to consider the ramifications for Secondary > > arches, deploying a new CA would require each and every Secondary arch to > > purchase a cert from the same CA. or somebody to purchase a cert that > > covered *.koji.fedoraproject.org from the same CA. > > > > we are looking at deploying the hub on a separate box from the frontend > > which would allow us to do what you are wanting but would not look after > > secondary arches. > > How about making the hub (I assume this is only used by automated processes > and not manually) listen on a different port than 443? Then the web interface > could use the new well know certificate. The automated processes the internal > ones, where imho using a own ca does not hurt. Also using a different port > should be only a matter of configuring it once. > The secondary arch instances could then use a cacert[0] certificate, which > are > free and are trusted by some browsers already for the web interface. The Koji cli communicates with the hub for all operations, so it would require everyone to update their Koji config. In addition, I'm sure running ssl on a non-standard port would mess with some people's proxy/firewall setups. I don't think this is the best solution. ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: another issue to fix with the FAS2 switch: Kojis ssl certificate
On Tue March 11 2008, Dennis Gilmore wrote: > On Tuesday 11 March 2008, Till Maas wrote: > > Hiyas, > > > > now that everyone needs to change his password, can we now also deploy > > the new certifcate for koji? This will make it possible to verify whether > > or not one can trust the certificate for koji and the ticket[1] is now 7 > > months old, i.e. about a full Fedora release cycle. Therefore I guess > > there won't be a better time than now. > > > > Regards, > > Till > > > > [1] https://fedorahosted.org/fedora-infrastructure/ticket/88 > > No, Because it will break user certs. To make it work would require that > users all get entirely new server cert files. We need to redo our entire > CA system. We also need to consider the ramifications for Secondary > arches, deploying a new CA would require each and every Secondary arch to > purchase a cert from the same CA. or somebody to purchase a cert that > covered *.koji.fedoraproject.org from the same CA. > > we are looking at deploying the hub on a separate box from the frontend > which would allow us to do what you are wanting but would not look after > secondary arches. How about making the hub (I assume this is only used by automated processes and not manually) listen on a different port than 443? Then the web interface could use the new well know certificate. The automated processes the internal ones, where imho using a own ca does not hurt. Also using a different port should be only a matter of configuring it once. The secondary arch instances could then use a cacert[0] certificate, which are free and are trusted by some browsers already for the web interface. > We currently use 2 different CA's in our setup. One that is used only for > user certs and one that is used for the builders and frontend. I would > like to move to a new Single CA setup. In this world when you import your > fedora user cert for browser authentication you would automatically > recognise the CA. though this would only be valid for Fedora contributors. Is this only about Koji or Fedoraprojet in general? Imho it is better to use a well known CA for the frontend (website) and an own one for internal stuff instead of using an own one for everything. Regards, Till [0] https://cacert.org signature.asc Description: This is a digitally signed message part. ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Metalink support
Hi everybody, My name is Bram and I'm one of the developers the metalink tools project. I've heard that somebody tried to implement metalinks as part of the mirrormanager project and failed to get an agreable patch. I'm new to mirrormanager but I would like to see if I can find a way to help you guys with hosting metalinks in a usefull way. Even if it means it has to be done outside of the mirrormanager. Are there any opinions floating around about how metalinks could be implemented/created? Greetings, Bram PS I have some ideas, but as I'm new to this list I don't want to start dictating solutions. Feel free to invite me to do so ;-) ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: another issue to fix with the FAS2 switch: Kojis ssl certificate
On Tuesday 11 March 2008, Till Maas wrote: > Hiyas, > > now that everyone needs to change his password, can we now also deploy the > new certifcate for koji? This will make it possible to verify whether or > not one can trust the certificate for koji and the ticket[1] is now 7 > months old, i.e. about a full Fedora release cycle. Therefore I guess there > won't be a better time than now. > > Regards, > Till > > [1] https://fedorahosted.org/fedora-infrastructure/ticket/88 No, Because it will break user certs. To make it work would require that users all get entirely new server cert files. We need to redo our entire CA system. We also need to consider the ramifications for Secondary arches, deploying a new CA would require each and every Secondary arch to purchase a cert from the same CA. or somebody to purchase a cert that covered *.koji.fedoraproject.org from the same CA. we are looking at deploying the hub on a separate box from the frontend which would allow us to do what you are wanting but would not look after secondary arches. We currently use 2 different CA's in our setup. One that is used only for user certs and one that is used for the builders and frontend. I would like to move to a new Single CA setup. In this world when you import your fedora user cert for browser authentication you would automatically recognise the CA. though this would only be valid for Fedora contributors. right now we have up ia64.koji.fedoraproject.org and sparc.koji.fedoraproject.org in addition to koji.fedoraproject.org you can log into any of them using your fedora cert. We need to ensure that this is always the case. in addition we will soon have s390.koji.fedoraproject.org and eventually arm.fedoraproject.org and alpha.fedoraproject.org as well as any others that come along say mips/mips64, hppa, whatever arch someone wants to support. all of which we need to be able to provide authentication for users across all servers with one usercert. Please bring up ideas on redoing our CA infrastructure We need to start a project to do it. Im hope that Red Hat open sources Red Hat Certificate System soon as id like to evaluate it to see if it will work for us. the secondary arch hubs know about the user CA and have a cert from the builder CA and know about it as well. in addition they use their own 3rd CA for identifying the builders, kojira, garbage collection, etc Dennis signature.asc Description: This is a digitally signed message part. ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
Re: Rename cvsextras during FAS2 switch?
On Tue, 11 Mar 2008, Dimitris Glezos wrote: > On Mon, Mar 10, 2008 at 7:18 AM, Warren Togami <[EMAIL PROTECTED]> wrote: > > Hi folks, > > > > I am wondering, might it be a good time to s/cvsextras/packager/ during > > the move to FAS2? It might be an opportune time because everything will > > be down anyway? > > > > I am just afraid if we don't do it now we might still have it a year > > from now. =) > > Same for cvsl10n to l10n/translator. > It doesn't seem anyone claimed this so it looks like it won't get done. Man we need more people around, there's a ton of stuff that just isn't getting done. -Mike ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
another issue to fix with the FAS2 switch: Kojis ssl certificate
Hiyas, now that everyone needs to change his password, can we now also deploy the new certifcate for koji? This will make it possible to verify whether or not one can trust the certificate for koji and the ticket[1] is now 7 months old, i.e. about a full Fedora release cycle. Therefore I guess there won't be a better time than now. Regards, Till [1] https://fedorahosted.org/fedora-infrastructure/ticket/88 signature.asc Description: This is a digitally signed message part. ___ Fedora-infrastructure-list mailing list Fedora-infrastructure-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-infrastructure-list
