| Red Hat Linux 6.1: The Official Red Hat Linux Reference Guide | ||
|---|---|---|
| Prev | Chapter 9. Kickstart Installations | Next |
Now that you have some background information on kickstart installations, let's take a look at the kickstart file itself. The kickstart file is a simple text file, containing a list of items, each identified by a keyword. You can create it by editing a copy of the README.ks file found in the docs/ directory of a Red Hat Linux CD-ROM, or you can create it from scratch. You should be able to edit it with any text editor or word processor that can save files as ASCII text.
First, some ground rules to keep in mind while creating your kickstart file:
Items must be specified in order. It is not a good idea to try to change the order of the required items.
Items that aren't required can be omitted.
For kickstart upgrades, the following items are required:
language
installation method
device specification
keyboard setup
the upgrade keyword
LILO configuration
If any other items are specified for an upgrade, those items will be ignored (note that this includes package selection).
Omitting any required item will result in the installation process prompting the user for an answer to that question, just as during a normal installation. If this happens, once the answer is given the installation will continue unattended (unless it comes across another missing item).
Lines starting with a pound sign ("#") are treated as comments, and are ignored.
Let's take a look at each item in order.
The first item that must appear is the language setting. The language you specify will be used during the installation as well as to configure any language-specific aspect of the installed system. The language specification must be a two letter ISO language code, such as en for English, de for German, fr for French, and so on. For example, to set the language to English, the kickstart file should contain the following line:
lang en |
The next item is the network configuration information. This line is used to tell the system how it should configure networking for itself. It is optional, and if omitted, the system will be configured for stand-alone operation.
There are three different methods of network configuration:
DHCP
BOOTP
static
The DHCP method uses a DHCP server system to obtain its networking configuration. As you might guess, the BOOTP method is similar, requiring a BOOTP server to supply the networking configuration.
The static method requires that you enter all the required networking information in the kickstart file. As the name implies, this information is static, and will be used during the installation, and after the installation as well.
To direct a system to use DHCP to obtain its networking configuration, use the following line:
network --bootproto dhcp |
To direct a machine to use BOOTP to obtain its networking configuration, use the following line in the kickstart file:
network --bootproto bootp |
The line for static networking is more complex, as you must include all network configuration information on one line. You'll need to specify:
IP address
netmask
gateway IP address
nameserver IP address
Here's an example static line:
network --bootproto static --ip 10.0.2.15 --netmask 255.255.255.0 --gateway 10.0.2.254 --nameserver 10.0.2.1 |
Please Note: The entire network configuration must appear on one line! We've wrapped it here to make it easier to read.
There are two restrictions you must keep in mind should you use the static method:
All static networking configuration information must be specified on one line; you cannot wrap lines using a backslash, for example.
You can only specify one nameserver here. However, you can use the kickstart file's %post section (described in the section called %post -- Post-Installation Configuration Section) to add more nameservers, if needed.
The next required item is the installation method. This item directs the installation program for the rest of the files required to install Red Hat Linux. There are two choices: NFS or CD-ROM. Let's look at both, starting with NFS.
For the NFS installation method, you must include the NFS server's name and the directory to be mounted. Here's an example:
nfs --server hostname.of.server --dir /path/to/RH/CD/image |
For a CD-ROM-based kickstart installation, simply use the following line:
cdrom |
The next set of items in the kickstart file is used to specify optional hardware information. For most PCI-based hardware you can omit this step, as this information can be obtained directly from the hardware. Note that IDE hard disks and common PCI cards fall into this category. Any other hardware may need to be specified here.
To specify a device, start with the device keyword, followed by the type of device:
ethernet (for Ethernet cards)
scsi (for SCSI cards)
cdrom (for non-SCSI, non-IDE CD-ROM drives; usually sound cards with proprietary CD-ROM interfaces)
If a kernel module is required to support the device, the module name follows the device type.
Finally, if there are any parameters that are required by a device, they can be specified using the --opts option. Enclose the parameters in quotes after --opts. We'll show you some examples below.
Note that you can specify more than one type of device in a given kickstart file. For example, if you know the machines you'll be kickstart-installing have either an Adaptec 1542 or a Buslogic SCSI card, you can enter both in the kickstart file. But be aware that the installation program uses only the first card found, so order the device entries appropriately.
An example for an ISA 3Com Ethernet card would be:
device ethernet 3c509 --opts "io=0x330, irq=7" |
Here's an example line for an Adaptec 1542 SCSI card:
device scsi aha154x |
An example of a SoundBlaster CD-ROM might look like this:
device cdrom --opts "io=0x240" |
The next item you'll need to specify is the correct code for your keyboard type. For US keyboards, the type is us. For the others, please run the /usr/sbin/kbdconfig program on an already-installed Red Hat Linux system. (An alternative approach would be to set the keyboard type to us and run kbdconfig on the installed system to set it properly after the installation completes.)
An example of this would be:
keyboard us |
If you do not want your system device controllers to be automatically probed then you can issue the command:
noprobe |
If you configure this command, your system will not probe for any device controllers, SCSI or otherwise. Use this command only if you want to manually specify the devices that are on your system.
Please Note: You will not be prompted to enter devices at any point. You will have to manually enter them into the kickstart configuration file or else you will not be able to continue with the installation.
Your system is normally set up to take or find one device of a type. Without changes, the kickstart configuration will load the modules for one type of device, such as loading the module for one SCSI adapter type. Beyond that, the program will not load further modules for that type of device.
In order to load modules for more than one adapter type, (for example, two different SCSI adapters) you will need to add the following command:
device --continue |
So, if you need to have modules for a Adaptec and a BusLogic adapter, then you will need to have both of these specified in the configuration file and you will need to have --continue after the first one in the configuration file:
device scsi aic7xxx --continue device scsi BusLogic |
However, if you have multiple adapters of the same type, then you don't need to use this line, since the single module insertion is enough to control all adapters of that type. For example, if you have three Adaptec adapters, then the following single line:
device scsi aic7xxx |
will load and allow all three adapters to function.
The hard drive in the machine must be partitioned before Red Hat Linux can be installed. In this section, we will describe how to specify disk partitioning in the kickstart file.
First, if you are installing Red Hat Linux on a new machine, you should use the zerombr keyword to clear the current partition information. This is a good idea, because the partition table on new hard drives is usually bogus. Here's an example of zerombr on a new system:
zerombr yes |
On the other hand, if you are installing machines that have a valid partition table, even if you want to change part (or all) of it, you should use zerombr this way:
zerombr no |
The next command is optional, but can come in handy. If you'd like to remove all partitions, or just any Linux-related partitions, you can use clearpart. For example, to clear all partitions of type "Linux native" and "Linux swap," you could add this line:
clearpart --linux |
To clear all partitions from a disk, this line would do the trick:
clearpart --all |
The only options clearpart supports are --linux and --all.
The next step is to specify the partitions you want to create. These will only be created using the system's unpartitioned free space. (In other words, if the machine had Windows-related partitions, and you invoked clearpart --linux, those Windows partitions would remain untouched.) You must enter one partition per line using the following format:
part <mntpt> --size <size in megs> [--grow] [--maxsize <size in megs>] |
(This part line may be wrapped to make it more readable; your part line must be on one line.)
<mntpt> is the location where you are going to mount that partition in your installed system (for example, the root partition would have a mount point of /, while you may decide that another partition should have a mount point of /home).
<size in megs> is the size of the partition in megabytes. You can optionally specify that the partition is growable by adding the --grow option. Note that making a partition growable does not mean that you can later increase its size. Instead, a growable partition will be automatically resized to use all available unpartitioned free space (after all fixed-size partitions have been created).
Since the amount of unpartitioned free space can vary, and you probably want to use it all, by tagging partitions as growable you can easily make sure no space is wasted. If you have multiple partitions tagged as growable, the free space is split evenly among them.
Note that you can also limit the size of growable partitions with the optional --maxsize argument.
Here's an example of kickstart partitioning in action. Let's say you know the smallest disk out of a set of machines you plan to kickstart-install is 1GB. You'd like to use the same kickstart file. You could use the following partitioning scheme:
zerombr no clearpart --all part / --size 250 part swap --size 50 part /usr --size 500 --grow --maxsize 800 part /tmp --size 100 --grow |
When defined this way, the installation program will first clear all partitions. It will then set up a 250MB root filesystem, followed by a 50MB swap partition. Next the installation program will create a /usr partition of at least 500MB (remember, it's growable), but it cannot grow beyond 800MB. Finally, the last line will create a /tmp partition of at least 100MB (again, it's growable).
So for that 1GB system, you would end up with a 250MB root, a 50MB swap, a 550MB /usr, and a 150MB /tmp partition. If another system has a 2GB drive, you would get a 250MB root, a 50MB swap, a 800MB /usr, and a 900MB /tmp.
The next item to specify is whether you are doing a fresh install, or an upgrade of an already-installed system. For a fresh install, use:
install |
For an upgrade of an existing system, use:
upgrade |
Keep in mind that for upgrades, the only items that matter are:
installation media (CD-ROM or NFS)
device specification (if necessary)
keyboard setup
install/upgrade specification (which should be upgrade, of course!)
LILO configuration
To define the type of mouse your system has, you must use the mouse keyword. Run mouseconfig --help on an already-installed Red Hat Linux for a list of mouse types.
Depending on the type of mouse, you may also need to specify the device to which the mouse is attached. The default device is correctly set for bus mice. For serial mice, the default device is /dev/cua0, but can be overridden with the --device option followed by the device name, such as cua1.
Red Hat Linux is timezone-aware, so you'll need to specify the timezone in which the machine will operate. This is done using the timezone keyword. There are many different timezones; the best way to find yours is to run /usr/sbin/timeconfig on an already-installed Red Hat Linux system.
If you would like to have your system's hardware clock set to use GMT/UTC, add the --utc option to your timezone line. Here's an example that defines the timezone as US Eastern with the system clock set to GMT:
timezone --utc US/Eastern |
The next item is the X Window setup line. The installation program will normally find common PCI video hardware and will know which X server to install. The keyword for X configuration is xconfig.
If your video card isn't autoprobed properly, you can use the --card option to explicitly specify the card. You can use Xconfigurator --help on a running Red Hat Linux system to get a list of supported cards to choose from.
If your card isn't in the list but is supported by one of the existing servers, you can simply install the proper server by using the --server option. Again, use Xconfigurator --help to get the list of server names.
You also need to specify a monitor type. If you don't, the installation will assume a generic monitor capable of 640x480@60hz. Use the --monitor option to specify something other than the default. Again, Xconfigurator --help will list all valid monitor types.
If your monitor isn't listed, you can enter the actual monitor specifications by using the --hsync and --vsync options for horizontal and vertical sync rates, respectively. The rates may be single numbers (representing kilohertz and megahertz, as appropriate), groups of numbers separated by commas, or two numbers separated by a dash (signifying a range). For example:
xconfig --hsync "31.5,35.5,50-65" --vsync "50-70" |
An example for a machine where the video card can be autoprobed properly would be:
xconfig --monitor "tatung cm14uhe" |
An example for a machine where nothing is probed and the monitor isn't in the list might be:
xconfig --server "Mach64" --hsync "31.5,35.5,50-65" --vsync "50-70" |
You can put the root passwd in a kickstart file in the clear (in which case it would go over the network in the clear on an NFS install) or you can specify that an encrypted password is to be used. To specify an unencrypted password in the kickstart file, use the rootpw keyword, followed by the cleartext password:
rootpw mypasswd |
If you would rather use an encrypted password, grab it out of /etc/passwd (or wherever you have the encrypted version stored), and add the --iscrypted option:
rootpw --iscrypted encryptedpasswdstring |
After you have set the root password, you have the ability to set up different network password authentications:
Enable NIS -- allows you to run a group of computers in the same Network Information Service domain with a common password and group file. There are two options here to choose from:
NIS Domain -- this option allows you to specify which domain or group of computers your system will belong to.
NIS Server -- this option causes your computer to use a specific NIS server, rather than "broadcasting" a message to the local area network asking for any available server to host your system.
Enable Shadow Passwords -- provides a very secure method of retaining passwords for you.
MD5 Password allows a long password to be used up to 256 characters, instead of the standard eight letters or less.
The authconfig format for kickstart looks similar to:
auth --enablenis --nisdomain foo.redhat.com --nisserver server.foo.redhat.com [--useshadow] [--enablemd5] |
Please Note: The commands in the square brackets are optional. If you choose to set them up, you do not need to use the brackets.
You are able to change authconfig using these commands to set up the different password options:
--enablenis enable nis by default
--nisdomain <domain> default NIS domain
--nisserver <server> default NIS server
--useshadow use shadow passwords
--enablemd5 enable MD5 passwords
|
For machines that use LILO (Intel-based systems), you can specify the LILO configuration using the lilo keyword. The default line can be as simple as this:
lilo |
This will install LILO in the hard drive's master boot record (MBR), and automatically configure boot entries for your Linux installation as well as a DOS or Windows installation (if one is present).
If you don't want LILO installed in the MBR, you can do so with by using the --location option. There are three possible places where LILO can be installed:
mbr - put LILO on the master boot record (default)
partition - put LILO on the beginning of the root partition
none - don't install LILO at all (in which case you'll need your own method of booting the installed system)
You can also use the --append option to add an append= line to the Linux boot entry. This is handy if you need to do things like set memory sizes, etc. For example, to install LILO on the MBR on a machine with 128MB of RAM, add the following lilo line:
lilo --append "mem=128M" --location mbr |
(Due to the new kernel in Red Hat Linux 6.1, the mem boot-time option shouldn't be necessary, but we needed an example.)
You can use the %packages keyword to start the beginning of a kickstart file section that lists the packages you'd like to install (note that this is for installs only, as package selection during upgrades is not supported).
Packages can be specified by component or by individual package name. The installation program defines several components that group together related packages. See the RedHat/base/comps file on any Red Hat Linux CD-ROM for a list of components. The components are defined by the lines that begin with a number followed by a space, and then the component name. Each of the packages in that component are then listed, line-by-line, until the end keyword. Individual packages lack the leading number found in front of component lines.
In most cases, it's only necessary to list the desired components and not individual packages. Note that the Base component is always selected by default, so it's not necessary to specify it in the %packages section.
Here's an example %packages section:
%packages @ Networked Workstation @ C Development @ Web Server @ X Window System bsd-games |
As you can see, components are specified, one to a line, starting with an "@" symbol, a space, and then the full component name as given in the comps file. Specify individual packages with no additional characters (the bsd-games line in the example above is an individual package).
Please Note: You can also direct the kickstart install to use the workstation- and server-class intallations. To do this, simply add one of the following lines to the %packages section:
@ Workstation @ Server |
You have the option of adding commands to be run on the installed system after the installation is complete. This section must be at the end of the kickstart file and must start with the %post keyword. Note that you can access the network in the %post section; however, nameservice has not yet been configured at this point, so only IP addresses will work. Here's an example %post section:
%post # add comment to /etc/motd echo "Kickstart-installed Red Hat Linux `/bin/date`" > /etc/motd # add another nameserver echo "nameserver 10.10.0.2" >> /etc/resolv.conf |
This section creates a message-of-the-day file containing the date the kickstart installation took place, and gets around the network keyword's one-nameserver-only limitation by adding another nameserver to /etc/resolv.conf.