I just talked with Ken Reilly, one of RH's engineering managers. We are
trying to solve the CLA problem, where legal surprised us by allowing
Red Hat contributors to Fedora under Red Hat's CLA instead of Fedora's
CLA. We both realize there are potential problems in this, but there is
urgency to allow Red Hat CLA very soon because this blocks many Red Hat
engineers from creating Fedora Accounts as we approach the merge.
Below is an initial simple implementation to enable this very quickly.
Luckily however, the groups shouldn't get in our way to further improve
this process later.
One Time Changes
1) Existing cla_done is cloned to fedora_cla.
2) dell_cla group is created, Matt adds whoever he wants. Remove
dell_cla members from fedora_cla.
3) redhat_cla group is created, populated through various means.
4) Modify existing Fedora CLA signing process to join fedora_cla instead
Automatic Changes Thereafter
fedora_cla auto adds to cla_done
redhat_cla autoadds to cla_done
dell_cla autoadds to cla_done
Toshio's cvsextras -> fedorabugs code should work in these cases too?
1) (one time) Dump dist-fc7 package owners, match e-mail addresses with
FAS accounts, add all those to redhat_cla.
2) (one time) Add everyone else that we know about who currently doesn't
match e-mail addresses.
3) Give kreilly admin access to the redhat_cla group, so he can
add/remove members in an interim.
4) Later give RH GIS access, so they can make it part of their standard
"new employee" or "remove employee" process.
See any problems in this? Please comment.
We need this implemented REAL SOON, hopefully by tomorrow.
I'll be traveling to our colo tomorrow night through Friday. I may be
taking some boxes up and down for maintenance or upgrades. I'll give
you guys as much notice as possible and I won't be taking any critical
services down (so the wiki will be up even if I have to take one of the
proxies down and I won't be messing with the buildsys or CVS at all.
I'm working on getting our first production xen instance up and running
for things like koji, smolt, bodhi and the package database. Here are
some guidelines I'd like to put on the wiki as well as some changes I'd
like to make.
1) xen dom0 - RHEL5 (its just a black box, lets set it up and forget
2) after we update our RHEL4 boxes to RHEL5 We will maintain two types
of servers, RHEL5 and FC6 (this is because not all required packages are
in EPEL, and ultimately the FC6 boxes will probably become FC7,8,9
boxes. I'd like to keep just two types so we can create an appa[1-9]
and an appb[1-9]. I'd like to put appa and appb behind a vip that gets
balanced 1-9 RR. This will allow us to choose where we want to put our
apps, stable environments vs cutting edge.
3) test and production xen guests will exist only on test and production
xen hosts. (basically no mixing of production and test). Obviously
emergencies are one thing but in general this is just for organizational
purposes and because we may create a test network later and they won't
be able to mix.
4) xen instances will be named by hostname. Naming by purpose is
5) We will probably start mixing hardware. Unlike before where we had
builder hardware and app hardware, we'll be bluring this line as the
need requires. I plan on building out a few more wiki instances before
the F7 release.
6) Kickstarts - I'm working on a xen-host and xen-guest kickstart
script. All of our boxes will be based off of one of these two scripts
(they'll be sent to the list soon for examination / suggestions).
Beyond that configuration will happen with puppet. Note: puppet can
pull in config files, install packages and restart services.
7) Monitoring - I'm working on a monitoring piece (basically a web page)
that will list exactly what xen guests are running on what xen hosts, if
they are pingable, etc.
What do you guys think?
I have recently updatqed to fedora 2.6.20-1.2933. I would like to know how
to add a kernel debugger and kernel dump analysis utility.
1. Is KGDB the right tool? Or there is others?
2. How and where to download and enable KGDB, and the working version for my
3. any utility for analyzing the kernel core dump
4. where and how to download and enable 3.
I've gotten the approvals from kwade and stickster (paul frields) about
the old plone instance on fpserv.fedoraproject.org.
I'm going to shut it down and kill it now as a step in killing all the
extraneous services on fpserv.
So we've been thinking we're going to take fpserv.fedoraproject.org
which lives at duke and make it into fedorapeople.org and also
planet.fedoraproject.orgfedorapeople.org will provide all the fedora account holders and groups
with some quota-controlled space to put files up.
what I was thinking might be cool is to reinstall fpserv with el5 so we
can use Xen. Then setup 2 xen guests. 1 would be the system that people
use to put their files up, the other would be for the planet code that
makes the planet pages (planet.fedoraproject.org, etc)
Does that sound pretty good to everyone?
I'm a lurker from the list that decided to help a bit . I work as a
sysadmin here in Brazil, mostly with Fedora and Red Hat, but sometimes
with debian, slackware , sometimes even sco unix and windows. My current
focus is mail servers, so I guess I could help a bit in this area. My
deployments are usually built around fc/rh + postfix + clamav + amavis
(or maia mailguard) + postgrey .
I"ve also worked a bit with nagios (not much, since we had one person
who worked only with nagios at the time) and other network services. I'm
also a bsc in computer science, so I got a bit of programming knowledge,
even though most of my C is rusty, but my perl , php and shell script
skills are still working.