Thread: Kusu Installation Overview

Kusu Installation Overview


This documentation is a brief overview of the installation process internals for the Kusu master node. This installation overview document will cover the following processes:

• Initial ISOLINUX bootup
• Initial boot process
• Procedure to inject Kusu installation code into the stock Anaconda installation process.
• High level overview of the steps performed by the Kusu installer
• Bootstrapping kits
• Automated install of the packages in the master node

What this documentation will not cover:

• Installation of compute nodes

While Kusu is intended to support and provision on non-redhat based linux systems, it currently does not support these systems. Hence this overview document is specific to installing Kusu compiled with Redhat derivative operating systems.


Operating systems for which the guide applies:

• Fedora 6, 8, 9
• Redhat 4.6 - 5.2
• CentOS 4.6 - 5.2
• Scientific Linux 5.0 - 5.2

Initial ISOLINUX Bootup

The standard ISOLinux boot procedure is part of the general SYSLINUX boot process for which documentation explaining the full process is available here. What is relevant about ISOLINUX to the installer is that the ISOLINUX configuration file accepts a number of arguments and the arguments not understood by ISOLinux are passed down the first program run in userspace, /sbin/init. This provides a method for developers to provide initial 'canned' arguments via the isolinux.cfg or to supply custom arguments in the boot prompt down to the init program all the way to the Kusu Installer.

The command line information passed to ISOLINUX is also available in /proc/cmdline for use by scripts and programs later.

The Kusu installer, as part of the cdrom, provides a custom initrd image. An initrd image is an "initial ramdisk image" which is specified by the "initrd=" option to isolinux. It is used as the first staging area and contains artefacts to help with this process.


A brief summary of the ISOLINUX boot process:

1. Isolinux system boots from media with a minimal kernel (e.g. support for RAM disks, initrd, a.out, and the Ext2 FS) and loads initrd.
2. /sbin/init determines what is needed to mount the "real" root FS (i.e. device type, device drivers, file system) and the distribution media (e.g. CD-ROM).
3. /sbin/init loads the necessary kernel modules.
4. /sbin/init creates and populates the root file system (this doesn't have to be a very usable system yet)
5. /sbin/init invokes - via chroot - a program that continues the installation

The init program launched by ISOLINUX is provided by the loader part of the anaconda distribution. This loader understands the ks.cfg option which is supplied in the isolinux.cfg to further instruct the installer.


Newer linux kernels, starting with 2.6 support the usage of populating a ramdisk from a compressed cpio archive known as an "initramfs".

This removes the need for using special block devices or loopbacks to create the device, this operation is moved to the runtime- the compilation does not require privileged actions. This has the negative effect of the initramfs boot process being more complicated than with an initrd. As initrd is a disk image, the kernel can directly mount the initrd as a loopback device. With an initramfs, this cpio archive would have to be loaded to memory, unpacked to create a ramfs and then mounted.

As part of the Kusu compilation process, a customized initrd based on a supported OS is used eg: Rhel5 initrd is patched to support a Kusu install and used as the initrd of the bootable Base iso.

As part of this customization, all initrds are converted to initramfs. This implies that Kusu installations are not supported in 2.4 kernels.

/sbin/init

The /sbin/init program is supplied by anaconda, and can understand the ks.cfg option.
The init program receives the ks.cfg option passed via ISOLINUX. This kickstart configuration file, ks.cfg is the first of 3 kickstart configuration files used in the installation process. This configuration file is very simple and only contains language and keyboard settings.


The init program performs the following steps when run:

• Mount /proc filesystem

• Create a bare /dev heirarchy in /

• Create and mount /dev/pts for pseudo terminal support

• Mount sysfs in /sys

More importantly, it copies /tmp to /oldtmp and mounts /tmp as a ramfs and copies the artefacts in /oldtmp over.
Now /tmp can be used as a staging area between the different boot stages.

This way, /sbin/init performs as a conduit between the initial bootup and the full featured installer, which is bootstrapped by /bin/loader, to which init passes control to.

/bin/loader

/bin/loader is called by /sbin/init. It parses a second ks.cfg file, which is present within the initrd. This initrd contains more information than the first, dummy ks.cfg.


The second kickstart configuration file contains the following information:

• Basic networking information
• Language selection
• Keyboard selection

Without this information, the installation will not be "zero touch". Providing this information in ks.cfg removes the prompting for language and keybord support.


More information on the kickstart configuration file, ks.cfg and using it to automate installations can be obtained here

/sbin/loader's scope:

The loader is responsible for screens to choose Language, Keyboard and finding the CDROM to load additional data contained outside the initial ram disk. It is a C program which performs further setup required for the python based anaconda installation.

At a high level, the loader performs the following functions

• Parses the second kickstart configuration file, which is shipped within the initrd image.
• Sets up ide devices.
• Sets up scsi devices.
• Sets up ipv6 support if needed.
• Initialises usb support.
• Prepares the python enabled environment "stage2" using the appropriate installation method.
• Incorporates updates into this stage2.
• Runs update script if present, or runs vanilla anaconda installer.

Note: To load additional modules pertaining to custom hardware, the 'device' directive can be supplied in the ks.cfg. For example, the line "device usb usb-storage" in the 2nd ks.cfg will cause the usb-storage driver to be force loaded. This can be useful in situations where some older hardware is not correctly recognised as requiring USB support.

Stage2 and updates.img

The key functionality of the loader in the installation is that it is responsible for preparing bootstrapping the environment in which the python anaconda runtime can be run. This stage2 is prepared in accordance to the installation method provided in the kickstart configuration file, ks.cfg.

The stage2 of an anaconda based installation is a heavier compressed image called stage2.img when compared to the initrd. The imaged filesystem is usually either cramfs or squashfs, and varies across systems. The stage2 is provided either in the the cdrom or a lighter one, ministg2.img provided over the network ( which is used in the case of nodeinstaller)

The stage2 image contains useful packages such as newt windowing toolkit, the python interpreter,additional modules to load and other useful information that is required to fully perform an anaconda based install.

Currently, stage2.img is not modified by Kusu and is used as-is from Redhat. However, the anaconda installation method provides means to inject additional updates into this stage2, after the initial stage2 has been loaded and chrooted into. This process to inject updates is verbosely documented here.

updates.img

Anaconda has the ability to incorporate updates at runtime. Such updates are packed in a disk image called updates.img. As with stage2.img, the imaged filesystem format varies across distributions.
The /sbin/loader program looks for and unpacks the updates in updates.img if present, after initialising stage2.

Kusu makes extensive use of updates.img and is the method by which it injects installer code into any Redhat derivative system.
The general rule for launching the anaconda script in updates.img instead of the default is:
If there is a script in /tmp/updates/anaconda AND it is executable,
launch the update script. Otherwise, launch the stock anaconda script in /usr/bin/anaconda.

Since Kusu ships with this updates.img as part of the installer , the anaconda script supplied in the updates.img is loaded instead of the vanilla updates.img shipped with the redhat derivative stage2.

This anaconda script shipped by Kusu ie: the 'faux anaconda' loader , is described in detail below.

Kusu 'faux anaconda' loader


Kusu ships with its own anaconda loader script in updates.img. It is responsible for the following:

• Cache the current environment.
• Initialise the kusu environment.
• Migrate and mount stage2.img.
• Launch the kusu installer.
• Restore cached environment in 1.
• Exec the real installer with the kusu-ks.cfg generated as the output of the Kusu installer.

Kusu installer

The kusu installer comprises of 11 screens.
See the installation guide for an in-depth discussion of the installer's functionality. See the installer architecture document for an in-depth discussion of the installer's internals.

The installer comprises of 11 screens including the welcome screen which are elaborated in the following subsections.

Welcome screen

This screen provides basic promotional information on Kusu.

Keyboard / Language Selection screens

Self explanatory.

Network Selection screen


The Kusu installer allows the user to configure the network. In a Kusu the master node, it is recommended to have at least 2 network devices. This is due to the fact that Kusu's clusters usually have the following topology:

• A public network public interface that connects the master node to the world.

• A provisioning network.
  • A provision network is an internal network managed by the master node.
  • All compute nodes will be associated within this network, and the master node will primarily manage nodes on this internal network.

Gateway/DNS settings screen

The master network needs an optional gateway and DNS argument if the public interface is configured as a static IP. Otherwise, the installer provides an option of sourcing these settings from DHCP configuration.

Hostname Selection, Root Password and Timezone configuration screens

These few screens deal with Hostname/Root password and Time zone settings and are straightforward.

Partitoning screen


One of the main components of the installer is the partitioning screen. The following points are key features of the partitioning code.

1. The partitioning code in the installer directly commits changes to the disk.
2. It is capable of configuring mutliple disk and supports LVM management.
3. The master node partitioning schema imposes the following restrictions
4. The disk size must at least be 40 GB.
5. The partitions / , /boot , /depot must be present.
6. /boot cannot be in an LVM.

Kits Selection screen

Once the partitioning schema is confirmed, installation proceeds to the Kit selection screen which allows additional kits to be added to the master node. At least 1 OS kit must be added at this stage for the installation to proceed.
More information on Kits and OS Kits can be obtained here.

While multiple OS kits are supported in Kusu, it is recommended that the OS kit being added as the initial OS correspond to the OS being installed.


Currently, the following OSes are supported across x86 and x86_64 bit archs.

• Fedora 6,7,8,9
• Rhel 4.6 - 5.2
• Centos 4.6 - 5.2
• ScientificLinux 5 - 5.2

Confirmation screen

At this point, the Kusu Installer requests a confirmation and stores and stages the relevant information for the real anaconda installer.

The kusu-ks.cfg is generated based on the inputs and is used to have a fully automated install from this point via the RH Anaconda installer. In a fully installed master node, this output can be found at /root/kusu-ks.cfg.

Kusu Kickstart file - kusu-ks.cfg

The custom kusu-ks.cfg is served up to the anaconda installer by a thttpd instance kicked off in the 'faux anaconda' loader script once the Kusu Installer exits successfully.

This kusu-ks.cfg is built as part of the final actions of the Kusu Installer, These actions are executed within the context of the last 2 screens - kits and confirmation screens.

1. Generate a Kusu repository
2. Create the auto installer script
3. For Redhat derivatives, generate a ks.cfg, at the moment these are fedora, redhat, centos, scientific linux
   1. Generate a kickstart profile from the autoinstall module.
   2. Populate the root password,network,DNS and timezone in this Kickstart profile.
   3. Create the final Kickstart script based on this generic profile by passing it to the Kickstart Factory object specific to the distribution. The resultant object is then passed to the Script generation class.
   4. Migrate kusudb into a location that can be accessed upon first boot, /root. This DB is migrated to a MySQL database upon first boot.
   5. Migrates logs into a location that can be accessed upon first boot.

Redhat Anaconda Installation

In a redhat derivative system, the custom kusu-ks.cfg is enough to complete a fully automated install of the system.

The process from this point is fully automated, no partitioning or further input will be required from the user. A component based installation is performed in the master node. The post install configuration is then run, as specified in the Kusu installer earlier. This persists configuration information such as the root password. The installation also reboots upon completion and boots into the Kusu master node.

Vbseo,

Thank you for this detailed explanation of the Kusu installation process. In the text below you describe the Kusu installation screen that allows kits to be added or removed during the installation of the installer node. But I'm wondering if you would mind explaining how the list of kits is generated, or more to the point, how a different set of kits could be included in the standard load set? For example, let's say that I want to remove the NTOP kit and the add Eclipse kit, so that the user is presented with a list that already includes Eclipse and excludes NTOP?

Kits Selection screen

Once the partitioning schema is confirmed, installation proceeds to the Kit selection screen which allows additional kits to be added to the master node. At least 1 OS kit must be added at this stage for the installation to proceed.
More information on Kits and OS Kits can be obtained here.

Thank you very much,

Job+2