I just committed the first bits to the new updates system. At the
moment it doesn't do much, but I defined an initial database model
(which will also help us see how to integrate this with the package db)
and a couple of controllers.
I also updated the UpdatesSystem wiki page with screenshots of the current system that is used to push out core package updates. Hopefully this will give people some context as to the direction this project is going in.
The code should be pretty well commented, especially in places that *need* code.
This project is going to become a top priority for me in about week, after
finals. I'll try and produce a list of tasks at some point in the near
future that people can just pick up and work on. But in the mean time,
if you would like to help out, I recommend reading over the wiki and
getting familiar with the current update process/system. From there,
checkout the code, `yum install TurboGears` and start playing around
As many of you know we've been looking to make our configuration
management system a bit more robust. Primarily by trying to find a
technological solution to actually enforce our config management
One of the systems I've looked at is glump, provided by the Duke guys
and Seth. The system itself isn't *just* a configuration management
system. Its really a systems framework that is very modular in
nature. Its a bit rough around the edges right now but in true Fedora
spirit I'd like to suggest we adopt this technology and make it
better. It'll work for us out of the box, and with Duke as upstream
we're not alone in using it.
I've got one working sample that just copies a file to your /tmp/
directory. Interesting items to note is once /tmp/test1 is created,
if you alter it and re-run the script, a backup noting the date and
time is created. This is especially handy in our environment where
not everyone always follows the rules. Consider it a safe and gentle
Be warned, there is a slight learning curve. The actual 'config
management' stuff is done in a script here called 'head' glump itself
really just glues a bunch of files together into this one script.
Once you start poking around at it you'll see what I mean. But think
of the files listed in glue.xml as groups of config files. For
example, we could have a phx file and an app server file for app
servers in the phx colo. You get the idea. Check out the source if
http://mmcgrath.net/~mmcgrath/glump-example.tar.gz (The actual glump
source and configuration)
http://mmcgrath.net/~mmcgrath/configfiles.tar.gz (sample configs)
You can run the script by typing:
wget -qO - http://mmcgrath.net/cgi-bin/glump.py | sh
Don't take my word that it won't fark your system up, take a look for
yourself at what its running! It should just create two log files in
/tmp and a file called /tmp/test
We would use this in addition to our current CVS system though we
should probably give all the servers a good once-over and re-sync the
configs for those servers that are out of sync.
Seth, please correct or make more clear anything that I've munged up.
What do you all think?
I've recently joined the Fedora Community as a contributer and would like
to introduce myself to the list.
Professionally, I am a systems analyst with a Houston based consulting
company. Primarily I work with HPC compute clusters in the Oil & Gas
industry; but our client base truly has a wide variety of endeavors. I've
been working (professionally) with various Red Hat systems since about
1998-ish starting with RH4.x (I think it was 4.2; but that was a long time
ago). The current environments I work in run a range of FC/CentOS/RHEL on
5000+ servers. I am directly involved in the planning, development,
implementation, and maintains of different (proprietary and custom built)
monitoring and alerting solutions and also troubleshooting infrastructure
services for several organizations. Before my current position, I managed
much smaller environments (1-5 Linux servers).
Personally, I am a father of three and geek through and through (I have
the Star Wars Lego sets to prove it :). My wife tolerates my geekness -
sometimes. I've been a Fedora Core user since the first FC release and was
a Red Hat user for many years before that. My desktop of choice is Gnome
and the most used application on my system is probably gnome-terminal.
I think that about covers my 'brief' background. I hope to contribute
great work to the project to help Fedora continue to distribute a great
distribution for the community! Over the next couple weeks, I'll be
looking into the current open bugs to see where I can pitch in to get
Thanks a lot!
James T. Richardson, Jr.
There are several things happening with the package DB this week.
1) Jesse Keating reported that the Brew buildsystem has a packagedb
implementation. If approval goes through to open source brew, we'll get
the schema for that packageDB as part of the package. I know of a few
areas where we'll have to enhance the schema to support all the things
we want to do (ACLs for building, committing, and modifying packageDB
records) but am unclear on others (Does the brew packageDB have a web
interface? Does it tie into Core's CVS?)
2) I've finished an importer for owners.list and some information from
the CVS repository for the current schema. I haven't tested it
extensively but it has imported data into my local test DB. I'll have
to try it on the xen test server next. The importer separates the
exporting functionality from the importing so it shouldn't be too hard
to switch to a new packagedb schema later.
The importer is owners.py on test3:
Or available from a Bazaar repository:
bzr branch http://www.tiki-lounge.com/~toshio/fedora/fedora-packagedb
3) I've started a redesign of the schema to address ACLs and collection
inheritance. I've some questions about this that I'll try to take up
with Jesse this week. I'm writing up the schema in SQL now and will
post it this week for review.
4) While working on the schema, I've become a bit less enamoured with
SQLObject. It seems to make easy things easy and hard things difficult
to impossible. For instance, there doesn't seem to be a way to specify
multi-field primary keys (or multi-field unique constraints which would
do almost as well.) The latest TurboGears beta has preliminary support
for a second ORM, SQLAlchemy. I've installed the 0.3.1 of SQLAlchemy
here and it is much more flexible. SQLAlchemy is newer than SQLObject,
has excelent documentation, and a very active upstream. This is good in
that bugs are fixed quickly and features are often added once a user
requests them. It's downside is the potential that the API could change
and we'd have to port our applications or stay with an older version.
Any opinions on this?
We need some help for the following:
1. Some short-term Python fixes, documentation clean-up, etc. to get the
Google Summer of Code project we did through Moin Moin merged into the
2. Ongoing maintenance of this Wiki to DocBook conversion code.
This is a great chance to get involved in some upstream work for our
Wiki-of-choice; to help out the Documentation Project tremendously; and
to help out the overall Fedora Project when we all benefit from
upgrading to the 1.5+/1.6 Moin Moin.
A current status is found here:
Here is the history of the project:
The status page has a task list, that needs to be moved to the Moin Moin
main Wiki and then worked on. If you are interested in doing or
collaborating on this project, please contact us through
fedora-docs-list. Questions to the mailing list, or come by
#fedora-docs and we'll see what you need.
thx - Karsten
Karsten Wade, RHCE, 108 Editor ^ Fedora Documentation Project
Sr. Developer Relations Mgr. | fedoraproject.org/wiki/DocsProjectquaid.108.redhat.com | gpg key: AD0E0C41
or whatever that box is named or what chroot this goes to...
Either way its busted. The initial cgi loads up OK and displays a list of
repos, however clicking on any of the repos redirects to a location that
[Mon Nov 27 23:09:23 2006] [error] [client 10.8.34.200] File does not
exist: /var/www/html/hg/hg, referer: http://cvs-ext.fedora.redhat.com/hg/
which is what one gets while looking for
http://cvs-ext.fedora.redhat.com/hg/hg/fedora/livecd--devel which is a bit
wrong, it should be just one /hg, not two. I think modrewrite is screwing us
here, but I can't untangle the mess that is this box's setup to really
Does anybody grok this box enough to help out?
Release Engineer: Fedora
Hey guys, I'm checking in with everyone at once because a few people
had gotten back to me about mirror management and some of them were in
IRC so I don't have their email addresses. I know we had some
volunteers to create our master mirror management site where users
could add and delete mirrors. I haven't seen any actual code yet
though so I'm just interested in a status report.
If you are out there and working on this or interested please let me know.
xenbuilder1 is up and running it is the xen guest running on xen3 which was
hammer1 so we have 2 i386 / x86_64 builders again.
I have a cert ready for xenbuilder2 for when the new builder hardware from
Dell arrives. we will be back to full power then.
Dennis Gilmore, RHCE
It seems that the mock config files for fc6 are currently not in CVS?
( see also http://cvs.fedora.redhat.com/viewcvs/mock/etc/?root=fedora )
Don't know if this is due to the problems of cvs server recently (and
restoring the backup) or if these config files are stored somewhere