Main Navigation
Home Realm Linux
page title
The kickstart installation is the easiest form of installation for the Realm Kit, and also the most well supported. This install method uses a single CD or two floppies with a pre-built configuration file to determine what is installed on the target system. There are however some important differences (beyond simply a different OS being installed) and some additional functionality that kickstart provides. One of the biggest advantages of using kickstart is that an NCSU Administrator can completely automate installs of labs and workstations by using the web-kickstart system.
In order to perform a kickstart install you will need to have a
configuration file that will tell the installer exactly what it needs
to do. This is called the Kickstart file. In the Realm Linux install
tree on any mirror you can find an example kicstart file in
RealmLinux/docs/ks.cfg. Red Hat provides some
excellent online documentation for Kickstart as well as the many
different ways you can get the Kickstart configuration file to
the installer. Red Hat's documentation for Kickstart in Red Hat
Enterprise Linux 3 can be found in Red Hat's
System Administration Guide.
![[Note]](/images/note.png) | Note |
|---|---|
The Kickstart Generators are no longer supported in favor of the Web-Kickstart system. The Kickstart Generators and Web-Kickstart are completely separate entities. |
Once you have a kickstart configuration file, you can either use a floppy-based kickstart installation or an NFS-based kickstart installation. To perform a floppy-based kickstart install, copy the kickstart configuration file to the boot diskette. This can be done from a Sun or Linux workstation via:
eos% mcopy <configuration file name> a:ks.cfg eos%
or from a DOS or Win 9X/NT/200 machine through the command prompt via:
C:\> copy <configuration file name> A:ks.cfg C:\>
Please note that the name of the file on the diskette must be ks.cfg.
Once the configuration file is on the floppy diskette, simply use this diskette
to boot the machine. When the “boot:” prompt appears, you should
type linux ks=floppy, which will cause the installation
program to read in the ks.cfg file and use it to
determine what should be installed.
For an NFS kickstart, you will need to copy the kickstart configuration file to a directory that is NFS-mountable by the machine you wish to install to. This may seem confusing, because you have to have an OS to NFS mount a filesystem, but in this situation the installation program is itself enough of an OS to perform a simple NFS mount.
There is another requirement for NFS-based kickstart installs which is very important – the machine to be installed must be configured to receive a valid IP address through DHCP. The address it receives must be known; an address pulled randomly from a DHCP pool (i.e. automatic DHCP) will not work.
The reason for the IP address requirement is simple; most times, you will want
to have kickstart configurations for multiple systems in the same directory for
NFS installs. When you do this, you must name each kickstart configuration
file with the IP address of the machine it services:
[ip-address]-kickstart if the filename format. If you
have multiple machines that use identical kickstart configuration files, you
are able to have one 'master' configuration files with symbolic links of the
above naming convention pointing to it, but that name format is required.
Once the file is in place in the NFS-mountable directory, you have to then boot
the target machine with the boot installation disk. When the boot prompt
appears, you will need to specify an NFS kickstart configuration. Assuming
the NFS server you are mounting to get the configuration file from is named
nfs.server and the mounted directory is /export/kickstart,
the command would be as follows:
boot: linux ks=nfs:nfs.server:/export/kickstart/
Another note – the trailing “/” on the command is extremely important. Without this slash, the installation program will attempt to mount the directory “/export” and read the file “/export/kickstart” as the configuration file, which will obviously not work.
Once the installation process commences in either the floppy-based or NFS-based kickstart install, there is no further user input required. The machine should merrily install the operating system as requested, reboot once, and be usable immediately.
This type of kickstart install can only be done by an NCSU administrator and is the most supported method of setting up Realm Linux machines that are managed by NCSU staff. A configuration file must be put into the proper place in AFS, afterward you simply boot off the boot CD from the Web-Kickstart Web Site. No commands to type and the installation is completely automated. Complete documentation for Web-Kickstart is in its own section.
The manual installs of the Realm Linux operate in the same way manual installs of Red Hat operate. You will need to specify the same sort of information as you would for a normal out-of-the-box Red Hat install, and then select the “Realm Linux Workstation” installation option.
Although this installation option is not nearly as well supported as a kickstart installation, it does have some advanages in that it gives the user experience with the full installation process and all the stages that it must go through. Overall, however, we recommend you choose the kickstart method over a manual installation.
The term “overlay install” first requires some definition, as it's not really a standard installation type for most operating systems. We use this term to designate the Realm Linux installations which are performed on a pre-existing Red Hat Linux base through a series of RPM package installations. Though this may still be confusing now, it will become clear what an overlay install is momentarily.
The second most important thing to note about overlay installs, after the definition of the term, is that they are currently unsupported and will likely remain so for the forseeable future. There are currently several known issues with overlay installs on OEM-installed Red Hat Linux systems due to the OEMs' customization(s) of the base Red Hat Linux install. We strongly discourage the use of overlay installs.
Now that we've gotten that slight but necessary unpleasantness out of the way, we can explain how to perform an overlay install. There are two distinct stages to an overlay install; package installation and realm customization. The first part, package installation, simply involves downloading all the Realm Linux packages from the Realm Kit FTP site into an empty directory and installing them all simultaneously with rpm -Uhv *.rpm from inside that directory.
The second stage of an overlay install is somewhat more complicated. Because overlay installs are unsupported, I'm only going to give a very brief and high level explanation of the second stage; anyone performing an overlay install will be expected to have sufficient experience with Linux in general and Red Hat Linux in particular to understand the unwritten details.
In very short form, once all the Realm Linux packages have been installed, the system needs to be configured to use realm-based services as well as turning off insecure and unused services. The easiest way of doing this is to run the “%post” section of a kickstart configuration file as a script.
Some of the items that need to be examined, if you choose not to simply run a kickstart %post section, include (but are not limited to) authentication configuration, sendmail configuration, Hesiod clustering, local user access, nightly updating, and service (de)activation. Most of these tasks can currently be accomplished with the realmconfig utility. At this point, it is left as an exercise for the reader to actually plan out the remainder of the overlay installation.