From Fedora Project Wiki

< FWN‎ | Beats

 
(40 intermediate revisions by 3 users not shown)
Line 6: Line 6:
http://fedoraproject.org/wiki/Infrastructure
http://fedoraproject.org/wiki/Infrastructure


Contributing Writer:  HuzaifaSidhpurwala
Contributing Writer:  [[HuzaifaSidhpurwala|Huzaifa Sidhpurwala]]


=== New Key Repo Locations v2 ===
=== Intrusion update ===
[[MikeMcGrath| Mike McGrath]] sent a link <ref>https://www.redhat.com/archives/fedora-announce-list/2009-March/msg00010.html</ref> to the list about the intrusion which was sent to the fedora-announce-list earlier.<ref>https://www.redhat.com/archives/fedora-infrastructure-list/2009-March/msg00277.html</ref>


Warren Togami writes for fedora-infrastructure-list [1]
Mike said that he was waiting to discuss authentication mechanisms for the fedora-servers, Since passwords+ssh keys are not the most secure authentication mechanism. Also it seems that fedora does not have the budget for any RSA token like system for authentication.


Warren sent out a mail enlisting the new repo locations. Also the repo names have been changed so debuginfo and source are always at the end.
There was a lot of discussion on this thread, with various people proposing different authentication mechanisms which could be used.


[[Dennis Gilmore|DennisGilmore]] started a similar thread about Auth Mechanims<ref>https://www.redhat.com/archives/fedora-infrastructure-list/2009-March/msg00294.html</ref> on which he discussed using etoken or Yubikey for authentication.
It was a two factor authentication and therefore was more secure than passphrase or ssh keys.


[1] https://www.redhat.com/archives/fedora-infrastructure-list/2008-September/msg00001.html
<references/>
 
=== archives on secondary1 ===
 
Matt Domsch writes for fedora-infrastructure-list [2]
 
Matt asked if  archives.fp.o is on secondary1.fp.o There are 2 separate rsyncd.conf files in puppet, one for archives,one for secondary.  Given they land at the same place on the same
machine, only the one for secondary is actually in effect.  If they're going to be on the same machine, we need to merge them. On this Mike replied with an affirmative saying that they need to be merged.
 
[2] https://www.redhat.com/archives/fedora-infrastructure-list/2008-September/msg00030.html
 
 
 
=== rawhide, /mnt/koji and /pub/fedora ===
 
Jesse Keating writes for fedora-infrastructure-list [4]
 
Jesse created a user "masher" to have the ability to write to /mnt/koji/mash/ but not any of the other koji space.  This is useful to prevent too much damage from a horribly wrong
rawhide compose.  To make things easier in the rawhide compose configs, they decided to run the cron/scripts as the masher user.  This is also good because it means things run unprivileged.  However he ran into a snag.  They have another user, 'ftpsync' that has write access to /pub/fedora/.  Previously the rawhide script was ran as root, and thus it was no problem to su ftpsync for the rsync calls.  The masher user does not possess the capability of doing this.
 
 
[4] https://www.redhat.com/archives/fedora-infrastructure-list/2008-August/msg00174.html
 
=== New Key Repo Locations ===
 
Warren Togami writes for fedora-infrastructure-list [5]
 
Warren proposed the latest draft of New Key repo locations. Jesse Keating points out that the deep levels are necessary because mirrors exclude releases by directory name like "9/"
 
[5] https://www.redhat.com/archives/fedora-infrastructure-list/2008-August/msg00198.html

Latest revision as of 04:36, 6 April 2009

Infrastructure

This section contains the discussion happening on the fedora-infrastructure-list

http://fedoraproject.org/wiki/Infrastructure

Contributing Writer: Huzaifa Sidhpurwala

Intrusion update

Mike McGrath sent a link [1] to the list about the intrusion which was sent to the fedora-announce-list earlier.[2]

Mike said that he was waiting to discuss authentication mechanisms for the fedora-servers, Since passwords+ssh keys are not the most secure authentication mechanism. Also it seems that fedora does not have the budget for any RSA token like system for authentication.

There was a lot of discussion on this thread, with various people proposing different authentication mechanisms which could be used.

DennisGilmore started a similar thread about Auth Mechanims[3] on which he discussed using etoken or Yubikey for authentication. It was a two factor authentication and therefore was more secure than passphrase or ssh keys.