KSS: Kusu-Installer for SLES
by Chew Meng Kuan
2 December 2008


Overview

From the end-user's point of view, there is generally little difference between a kusu-installer for RHEL/CENTOS and a kusu-installer for SLES.

In the case of RHEL/CENTOS, kusu hijacks anaconda to run kusu-installer scripts to collect information necessary for a kusu master node install. For SLES, yast is similarly hijacked. There is no difference in the kusu-installer text-ui screens.

After the information is collected and the system is prepped, the kusu-installer exits and hands over the installation to anaconda or yast respectively. With the provided information, anaconda and yast performs an unattended install of a master node through to completion.


Scenarios

1. Winston is an experienced administrator of a kusu cluster that runs a mixture of RHEL and CENTOS compute nodes. He received requests from his users asking for SLES compute nodes to be made available. He wants to check out the new kusu sles installer to see if there are any differences.

2. David manages a cluster of SLES machines. He wants to try out the latest kusu-installer for SLES to see how it works. He downloads the latest kusu-sles10 ISO from osgdc website and gives it a spin on his VMWARE.


Non Goals

1. The provisioning of SLES compute nodes from a SLES master node.
2. The use of kusu tools like addhost, ngedit, cfm, etc.


Functional Requirements

1. The Kusu SLES Installer is able to install a master SLES10 SP2 node.
2. The resulting master SLES node is a working base install of SLES10 SP2 with services and environment set up for Kusu.



Non-functional Requirements

1. The SLES master node should be modified as little as possible.
Besides the dependencies and libraries required for kusu to function, the SLES master node should be no different from a vanilla SLES system installed with "base" pattern packages.


Use Cases

Use Case 1: Winston installs a SLES master node

Winston burns a latest daily build for SLES i386 to a CD and pops it into a spare machine in a test network.

The kusu-installer text UI is not expected to change except for the screens for keyboard, language and timezone selection. The respective selection lists should be those that SLES actually supports.

After collecting the required info and preparing the system (partitioning, formatting, setting up of OS kit, etc), kusu-installer will pass on the necessary set of info to the SLES native installer - in this case, yast - to perform the actual install. The yast install is fully-automated hereafter and no longer requires any user input. Unlike anaconda installation, yast installation goes through two stages.

Stage one is where the packages are installed and configured. After stage one completes, Winston sees that the system reboots.

After the reboot, yast continues with stage two. Stage two performs the remainder of the installation like configuring the user settings, timezone, set up network, etc.

When stage two completes, it will start executing the remaining startup scripts. The kusurc scripts are executed at this point to set up the system for kusu-related services like dhcpd, tftp, named, kusu database, etc.

Finally, once the startup scripts completes, Winston will be presented with the normal login prompt.

Use Case 2: SLES master installation completed

David has finished installing a SLES master node on a VM on his desktop. He can now login at the login prompt as root with the password he specified in one of the kusu installer screens. After he logs in, he can tell that the system is really running SLES. There will be services like apache2, dhcpd, named, named, postgresql, etc. that are enabled and running as required for kusu.

He can use familiar SLES tools like zypper or yast to further configure the system like install a fully functional gnome desktop, install build tools, add new package sources, etc.


Open Items

The CFM-related rc scripts are not ported in this sprint. This will be covered in the next sprint.