|
|
| (52 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]] |
|
| |
|
| == So everyone is aware == | | === 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> |
|
| |
|
| Mike McGrath 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. |
|
| |
|
| This is the first notice when came out to the community that there will be outages and a lot of the servers are being rebuild. Mike pointed to the mail on fedora-announce-list [2]
| | There was a lot of discussion on this thread, with various people proposing different authentication mechanisms which could be used. |
|
| |
|
| [1] https://www.redhat.com/archives/fedora-infrastructure-list/2008-August/msg00108.html | | [[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. |
|
| |
|
| [2] http://www.redhat.com/archives/fedora-announce-list/2008-August/msg00008.html
| | <references/> |
| | |
| === securing FAS certs ===
| |
| | |
| Toshio Kuratomi writes for fedora-infrastructure-list [3]
| |
| | |
| | |
| The Fedora Certificates issued by FAS are currently set to be autogenerated if you have an account in FAS. This has one drawback. We have to keep the password for the CA keys that sign the FAS certificates in a file on the filesystem so that the automatic signing can use them.
| |
| Toshio suggested that we use a system which utilizes human interaction to sign the certs.
| |
| | |
| [3] https://www.redhat.com/archives/fedora-infrastructure-list/2008-August/msg00122.html
| |
| | |
| == Photo gallery ==
| |
| | |
| Nicu Buculei writes for fedora-infrastructure-list [3]
| |
| | |
| The Art team decided to start collecting photos which can be used as desktop wallpapers, make a best-of-breed selection and create one or more packages. The easiest way is to add all of them to the wiki.
| |
| However Nicu proposed that we use a better solution, either a gallery plug-in for trac or a stand alone gallery or something like that.
| |
| | |
| [3] https://www.redhat.com/archives/fedora-infrastructure-list/2008-August/msg00028.html
| |
| | |
| == FAS authentication for Red Hat bugzilla ==
| |
| | |
| Rahul Sundaram writes for fedora-infrastructure-list [4]
| |
| | |
| Rahul asked if configuring FAS Auth for Red Hat bugzilla was possible. At which Mike replies saying that it was not our call, and Red Hat will need to decide that.
| |
| | |
| [4] https://www.redhat.com/archives/fedora-infrastructure-list/2008-August/msg00039.html
| |
| | |
| == RFC: script to run sqlalchemy migrations on the db ==
| |
| | |
| Toshio Kuratomi writes for fedora-infrastructure-list [5]
| |
| | |
| FAS started using the python-migrate package to update its db. This is a good thing for third-parties that want to install their own FAS server as it lets us ship the database changes in a way that is easy for those users to apply to their own production databases.
| |
| | |
| However, it doesn't work very well in our particular environment because we're a bit more strict about our permissions than the migrate authors envision. In order to perform migrations, you need to have a user that can modify the schema for the db. This is either the owner of the db or the superuser. In our setup, we create the db with the superuser and then run our web apps with another user. This prevents the normal web app from modifying the db schema.
| |
| Toshio proposed a couple of solutions to this.
| |
| | |
| [5] https://www.redhat.com/archives/fedora-infrastructure-list/2008-August/msg00059.html
| |
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.
