-- DavidBannon - 13 Sep 2005

The decision :

It has been decided that the gatway machines will :

• Use Centos as the default operating system
• Use XEN as the VM engine
• Use Scientific Linux for the os under NGLCG

For the record, this material was used during the decision making process :

Operating Systems

It would be nice (but not essential) if we could provide the same OS at host and client level. The host OS can be setup so its accessible only from internal (ie safe) systems but the client OS will definitely need to be maintained at a current patch level. It would be nice if we could use a 2.6 kernels because of better I/O performance. Folks, consider for the base OS that this is a production server, you don't get to do upgrades every 6 months. We will be lucky to get the sites to do regular patches, let alone major upgrades. True, but we will have to enforce upgrades or risk disaster - DRB

Please note that a lot of the decisions about operating system will be actually made for us when we choose our Virtual Machine Engine.

Options	Issues
Redhat EL? Suse	Considerable cost plus a certain lack of flexability
Fedora C4?	My Preferred (DRB) FC4 will include Xen, more SELinux, GCC 4.0. But not xfs! -DRB
Ubuntu Linux	Debian based distro with 6 month release cycle, up-to-date packages and big backing from the founder of Thawte, Mark Shuttleworth. Also paid support available from Canonical (his new company). Heaps of packages (over 19,000 if you include those from the Debian Universe). Same upgrade/install mechanism as Debian (apt).
Gentoo (shudder)	Has source packages for almost anything, just takes a while to build it..
Debian Stable (Sarge)	Not cutting edge (though has 2.6.8 by default), but with a huge reputation for stability and long support periods. Easily upgraded & maintained remotely. AMD64 release now available outside of the main release, may not include IA32 compatability libs unlike Ubuntu.
Centos 4	Free clone of RHEL 4. Same tools, well supported, 2.6 Kernel. (My preference FrankCrawford? )

Distribution method / Configuration Control

Send machine to each site as an empty box and allow each site to install, following a predetermined recipe.	1) Sites will have full control of config and will be aware of all decisions made along the process. 2) Would assume that upgrades / reinstalls will be as a result similar emailed instructions. 3) Serious danger that configs will diverge as time goes on.
VPAC builds first machine and clones remainder. Ships operational machines to other sites. Updates provided as new VM image.	1) Ensures uniform config. 2) Sites will need to apply their own site specific changes each and every time an update is required. Perhaps this can be scripted ? 3) Sites are less aware of whats in the box, more centralised responsibility and thats bad.
Hybrid - Boxes go direct to partner sites and partners install base OS. VM updates sent (from VPAC) as images, patched to suit local requirments.	Sounds like Rhys's prefered solution. Sites have local control, VMs are reasonably uniform. CS - If we use Xen or VMware who will take responsibility for making sure the VM system works ?

-- FrankCrawford - 09 Jun 2005

With regard to the distribution/configuration, I disagree that central control is bad. These are production servers, not development servers. We require a high degree of commonality between them so that the VM maintainers can be sure if it works on one, it will work on all.

I believe that the boxes should be installed and build before shipment, with just some instructions on how to localise the system (e.g. local IP addresses, etc). We should even go so far as to have a single DNS zone for them, such as gatekeeper-vpac.apac.edu.au.

There would also possibly be some issues with sorting out the licensing for VMWare with distributing the install. You will have to ship the binary download and license file to each installer. It would be simplier to do it locally and ship the box.

I'm not sure what you mean by "Root Passwords - Easy one - Yes". Are you saying that it locally they should have it, or it should be central? I don't think you can get away without having it local, but having it also central is a bit more of a security problem. Once we get a NOC going, we would want a normal account and sudo privs set up (or something like that).

-- FrankCrawford - 09 Jun 2005

Says David : Frank, local sites must have control of the local password, otherwise we'd have a security nightmare. Local sites must be able to overwrite security setttings to meet local rules or conditions, we at VPAC will not be able to produce customised VM images. And local sites will almost certainly need to do some fine tuning of the link between the Gateway and local queuing systems. -- DavidBannon - 10 Jun 2005