Bootstrapping a RHEL Clone

A good model

A good example of how to run a distro is Fedora. Their infrastructure team is very open and inclusive. They do have a system which allows for automated timely builds as well.

Yes, the Fedora project does slip it's release dates, but when it does so there is good reason and things are done in a very open manner. A release date slipping because it's "not done yet" is one thing. Helping your users understand what "not done yet" *IS, is a much more important part of managing a project.

Bootstrapping

A lot of these ideas come from observation of the Fedora Infrastructure team.

Account management

The Fedora Account system is central to the management of the Fedora Project. It's a directory service which handles accounts and access to various infrastructure resources.

A good directory service should be the first thing a RHEL clone would need to bring up.

The most robust I'm aware of is FreeIPA.

Build system

Fedora uses Koji to manage the builds of their packages. This allows for a fully open and automate-able build of packages from an upstream vendor. This is truly the key to a distro which needs to move fast.

There should also be a system in place for feedback of the packages in the distro. Bodhi is a good tool for such a task.

Public internet presence

A distro also needs an internet presence, a way of managing content, interaction with users, interaction with developers and testers, and a means for wide communication. All of these tasks can be done pretty cheaply if not freely.

• Github for source code related to the project (you could even use it as an issue tracker)

• Google Groups for mailing lists -- mailing lists are a great way to manage a diverse group of help.

• A public website is also needed to host www.$PROG.org and the project's documentation.

• There should also be a downloads.$PROJ.org for hosting things such as isos, yum repos, etc. This should be available via FTP, RSYNC, and HTTP.

Semi-public internet presence

In order for a distro like this to survive there needs to be multiple mirrors of the downloads server. These would be primed via a mirror host which is restricted to everyone except a few first-level mirror sites. The update of the mirrors would use rsync.

Internal Infrastructure.

There should also be an infrastructure host whose job it is to manage the other hosts mentioned. This host would have no public-facing interfaces except SSH. This host would act as the configuration management system's server, as well as the bastion host for the trusted infrastructure users to access and configure other servers.

EVERYTHING would be configured using a configuration management system (puppet, chef, etc). This allows for the infrastructure team to quickly adjust for demand or utilization of resources.

Bottom line

If such a project were to exist, the bootstrap resources needed would be:

• Four servers minimum -- SuperMicro has a 4-node 2-RMU server

• Some storage of some sort -- An inexpensive SAN solution would allow for the most flexibility. This Coraid Appliance would be nice.

• People interested in being open and willing to work in this endeavour.

This may be a pie-in-the-sky idea, but I think it has merit. Can you think of anything missing from the above proposal?

Cheers
Goozbach