I would like to lend a helping hand to your project. I believe this is
the best way since I am not primarily a programmer, and I just read an
interview on /. saying Fedora doesn't need more packagers :)
Here is a quick introduction:
1- My name is Ahmed Kamal. I live in Cairo, Egypt. I am 26 years old.
2- I have a degree in Electronics engineering.
3- I have done some scripting mainly perl, tcl/tk, awk and shell.
4- I currently work in Linux-plus.com as a system engineer, and I instruct
RH253 course (I am an RHCE of course)
5- Since at work I do a lot of consulting for Egyptian companies, I tend to
interact with a lot of stuff (networking, security, monitoring, email, ldap,
... pretty much everything) but then again, I can't claim to be an expert in
My main target for helping, is two fold, giving back to the community, and
of course learning and leveraging my skill set interacting with a huge
project such as fedora.
Well, that's basically my introduction. I'd like to help. At least at first,
I think I will only be able to help at weekends, so I'd rather focus on the
nice to haves, over the immediately importants :)
Viewing the schedule, there doesn't seem to be much priority 2 tasks, for
priority 3 ones, maybe I can work on getting SSL support for
fedoraproject.org. Let me know guys if I can work on that and how to start.
Dell U2 rackmount Red Hat is purchasing:
Two dual core 5050 Xeon's
4 x 146GB drives
Hopefully will be delivered in time for Stacy's visit to the colo late
Dell's Donated 1950 1U rackmount:
Two dual core Woodcrest Xeon's
4GB RAM (reportedly)
2 x 73GB drives
Currently being shipped from LWE San Francisco to Raleigh, NC. (Oops)
Being redirected back to the colo in Arizona, should definitely arrive
in time for Stacy's visit to the colo late August.
Both boxes will make great Xen hosts. We can figure what to run and
Hey guys, I'm going to miss the meeting today unless my train happens
to have an internet connection.
The backups are mostly up and running. Right now we're getting about
120G worth of backups. Now we just have to go over the individual
machines and make sure we're getting all the important stuff like keys
the database etc. db1, fpserv and bastion are all I have left to add.
Mirror list: The mirror list has been working fine for the most part.
Every once in a while though it grabs a bad mirror
I've only caught it happening once.
Lyz, Abompard. Sign up for the group "sysadmin-general". This will
allow you guys to access my LDAP install on bastion.
I talked with Max Spevack today about the status of the Dell server
donation. To his knowledge as of yesterday nothing has arrived for him yet.
Max agreed generally that we need more boxes in the colo, and he wants
information of what type of servers (features, U sizes, cost). I assume
the type of serial console with access to BIOS is an important
requirement, but otherwise we need standard rackmount boxes? Does
anyone know any more details about our colo?
We need to get this information together, then Max can figure out if it
fits within budget, and coordinate with Red Hat GIS to get it installed
into the colo.
Ok, I have a virgin install of FDS up and running on bastion. It's
actually running under its own dir in my home directory so we can move
it around/back it up as needed. Connection info is fairly simple.
Since this is just a test I figure no need to request firewall
changes. SSH should be able to take care of it.
my name is pasqual milvaques, I'm a spanish dba and software developer
and I'm going to try to give a hand to you in creating a homepage for
the fedora infrastructure project and in other things I can help.
I have created a draft for the page which I send attached with this
mail. The idea is to have in this page a list of all infrastructure
pieces which are being used with their links and some basic information.
the draft has not all the links, I will review it to add more links that
I have seen in the fedora infrastructure mailing list and (of course)
any link you indicate to me. In the next days I will review it and will
take deeper look to the wiki to search for more information (all this
system is bigger than I expected) and to define the work methodology.
well, take a look to the draft as in it you will find some of my doubts
(what is docs-rawhide? where is nagios?) and make me any comments you
regards and will be in contact
Following up on what was discussed in the meeting and the list of
requirements from the previous email, here are the scripts I'm currently
working on to setup the bzr repository.
* scponly-repo.sh: This is the first script to run. It sets up the
chroot environment. A portion of this script should be made into a cron
job that periodically refreshes the programs and libraries within the
chroot (to limit the time that the chroot is vulnerable to exploits.)
- A portion of this script needs to be run by root.
- This script labels files for SELinux. If SELinux is not enabled on
the server this lands on we'll want to comment that out.
- A portion of the script sets up a passwd and group file within the
chroot. I suspect that this is not necessary.
* setup-repo.sh: This script imports one of the cvs-seed tarballs from
cvs.fedora.redhat.com into the new repository. It sets up a sample
within the embargo directory as well.
* repo.conf: Apache configuration file to enable access to the repo over
http. Note that this allows bzr to access the repository over ssh. It
is not a web-front end. There is a separate cgi script which I haven't
yet worked with that can be used for that.
* user.sh: Sets up one user with an account on the system; adding them
to appropriate groups and etc. This is incomplete until I tie it into
the accounts system to retrieve the ssh key. In the future, user
information should be created by the accountsdb.
* user-setup.sh: This script sets up default groups (vcsuser and
security) that are used by the acls. It also creates a vcsguest account
that allows anonymous logins. After implementing http retrieval on my
test machine, I don't think this is necessary any longer. Anonymous
access can use http to retrieve public information. Read-write access
and access to private information will go through sftp.
* sshd_config: Replacement sshd configuration. Changes:
- AuthorizedKeysFile is changed to explicitly reference /home/%u
instead of the user's home directory. This is so vcusers have their
keys extracted from /home/%u instead of their home directory (which is
within the chroot). vcsusers do not have access to change ssh keys on
the server, this has to be done through the accounts db.
- PermitEmptyPasswords, PasswordAuthentication: This is to enable
anonymous ssh login to the chroot. Since anonymous access is going to
happen over http, this should no longer be necessary.
- Subsystem sftp: enabled sftp for bzr.
Everything is a work in progress but my main thrust right now is
creating good ACLs and testing what the limitations are.
I just wanted to send my apologies for missing today's meeting.
Currently, I have work related meetings that back up to the Fedora Admin
meeting. So, it is going to be hit and miss on my attendance for a
while. Also, I have been disengaged for the past month, and I have been
trying to keep up with what is going on through the list and weekly
meetings. A number of home projects have taken their toll on my time.
I am hoping in the near future to become more active. In the meantime I
just wanted to make sure everyone knew I was still around.
whats the status of getting the backups online? Is it ready to go, yet?
I'm backing up fpserv and extras64 using rdiff-backup right now to a
server I have here but it's not accessible to all the infrastructure
folks and I'd like to not be the only guy who can get to it for the
future so the backups on lockbox would make sense.
I've been thinking about a possible LDAP schema for the new Account System,
I've discussed it with Lyz and we agree it should be able to do the job.
I'd like to discuss it with you now.
Here's a description of this new schema :
I have not described the additions to the inetOrgPerson yet, because they
are minor. I'd like to validate the groups system with you first.
http://aurelien.bompard.org ~~~~ Jabber : abompard(a)jabber.fr
No, I coded it crappily on purpose, just so that I could say:
"There's plenty of room for optimization."