From Fedora Project Wiki

< FWN‎ | Beats

Line 8: Line 8:
Contributing Writer:  HuzaifaSidhpurwala
Contributing Writer:  HuzaifaSidhpurwala


=== Email aliases and new cvs requests  ===
== static F10 Alpha relnotes page ==


Toshio Kuratomi writes for fedora-infrastructure-list [1]
Karsten Wade writes for fedora-infrastructure-list [1]


Last week Seth implemented email aliases for the people who should be notified of changes to packages. Toshio used this new functionality to have getnotifylist, which looks up who to notify on cvs commits, stop querying the pkgdb directly (a slow operation with multiple points where it could fail) and instead just construct the alias from the packagename.
Karsten proposed that we turn [2] static. People should also be able to edit that page. Perhaps as part of making it static we can tell people to post changes to the talk page, then we'll
do irregular updates of the static content?


[1] https://www.redhat.com/archives/fedora-infrastructure-list/2008-July/msg00104.html


=== YUM security issues... ===
[1] https://www.redhat.com/archives/fedora-infrastructure-list/2008-August/msg00013.html


Toshio Kuratomi writes for fedora-infrastructure-list [2]
[2] https://fedoraproject.org/wiki/Releases/10/Alpha/ReleaseNotes


This is a re-post from Josh Bressers. Justin asked if the ability for mirror admins to select a
== Photo gallery ==
subnet where they'll serve all of the traffic has been removed?  There is a particular concern about this issue in the short term. There is a paper about this also [3]


[2] https://www.redhat.com/archives/fedora-infrastructure-list/2008-July/msg00082.html
Nicu Buculei writes for fedora-infrastructure-list [3]


[3] http://www.cs.arizona.edu/people/justin/packagemanagersecurity/
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.


=== cvsextras renamed to packager ===
[3] https://www.redhat.com/archives/fedora-infrastructure-list/2008-August/msg00028.html


Toshio Kuratomi writes for fedora-infrastructure-list [4]
== FAS authentication for Red Hat bugzilla ==


cvsextras has been renamed to packager. Any scripts that depends on querying the "cvsextras" group will now need to query "packager".
Rahul Sundaram writes for fedora-infrastructure-list [4]


[4] https://www.redhat.com/archives/fedora-infrastructure-list/2008-July/msg00128.html
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.


=== Server Monitoring - A replacement for Nagios? ===
[4] https://www.redhat.com/archives/fedora-infrastructure-list/2008-August/msg00039.html


Nigel Jones writes for fedora-infrastructure-list [5]
== RFC: script to run sqlalchemy migrations on the db ==


While this was intended to be a primary discussion point for the Infrastructure meeting there was a little bit of discussion first in #fedora-admin, and then in #fedora-meeting regarding Zabbix, a tool like Nagios that Nigel begun to setup for testing this week.
Toshio Kuratomi writes for fedora-infrastructure-list [5]


[5] https://www.redhat.com/archives/fedora-infrastructure-list/2008-July/msg00143.html
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

Revision as of 05:32, 11 August 2008

Infrastructure

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

http://fedoraproject.org/wiki/Infrastructure

Contributing Writer: HuzaifaSidhpurwala

static F10 Alpha relnotes page

Karsten Wade writes for fedora-infrastructure-list [1]

Karsten proposed that we turn [2] static. People should also be able to edit that page. Perhaps as part of making it static we can tell people to post changes to the talk page, then we'll do irregular updates of the static content?


[1] https://www.redhat.com/archives/fedora-infrastructure-list/2008-August/msg00013.html

[2] https://fedoraproject.org/wiki/Releases/10/Alpha/ReleaseNotes

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