You are on page 1of 38

Complete Kickstart: How to Save Time Installing Linux

If you have to perform a lot of Linux installs, there's a fast and easy way to do so quickly and efficiently without having to babysit the installation process each time. By making use of Kickstart, you can save time and effort by setting up a Kickstart server and spend your time getting more useful work done. By David Both, Bruce Garland Thursday, August 28th, 2008

We work in a lab environment at Cisco Systems in RTP, North Carolina, and are responsible for the care and feeding of many Intel, Sun, and Cisco boxes that make up the lab environment. Because its a lab, developers and testers require frequent reinstallations of these systems to return them to a known state. We also need to install operating systems on new boxes fairly often. All of these installations can be time-consuming, so we were tasked with creating a locally available kickstart server for Red Hat Enterprise Linux 5.1. As we started to delve into the requirements for creating a kickstart server we discovered that, although much of the information required to do so is available from various places on the Internet, some necessary information is very difficult to find. This article will concentrate on the specific configuration details required for an unattended network Kickstart of Red Hat Enterprise Linux 5.1. It is intended to cover all aspects of setting up a Kickstart server, including some information that is not readily available. The basic function of a kickstart server is to allow an administrator to perform a network installation of Linux. It provides a single location to store files for installation and allows for ease of updating those files instead of dealing with multiple copies of DVDs. It also allows for very fast and hands-free installation as well as the ability to provide a menudriven interface for selection of the desired kickstart configuration from among two or more choices. The Requirements Our requirements were that kickstart, once launched and after making a menu selection to choose a particular kickstart configuration, needed to be completely unattended. We also needed to install some local tools and make configuration changes to the installed boxes before they would be ready for use. The Anaconda installer menu must provide us with options to install multiple versions of this kickstart or to boot from hard drive. If no menu

selection is made after a short timeout, the Anaconda installer is configured to boot from the hard drive. Heres what you need in order to perform a kickstart: 1. 1. A Web server and/or FTP Server for delivery of the RPMs that are to be installed. 2. 1. A DHCP server for IP address assignments and to launch PXE Boot. 3. 1. A TFTP server for download of PXE Boot components to the machines being kickstarted. 4. 1. An PXE Boot capable network card. 5. 1. The BIOSes on the computers to be kickstarted must be configured to allow a network boot. Each of the required servers can be located on a different system, or they can be combined onto a single computer. In addition, Cisco Core routers require special configuration to transport UDP PXE Boot packets across subnet boundaries. Our environment requires the use of a serial console during Kickstart for menu selection. This gives us the ability to select from two or more different kickstart installations. Initial Decisions and Sizing We chose to use HTTP for file delivery, but due to the possibility that some need might arise in the future for an FTP kickstart, we decided to configure our kickstart server directory structure so that both FTP and HTTP can be used. We also chose to house the HTTP, TFTP, and DHCP servers on a single computer. For our environment, we had no reason not to have all of the servers on one box, and the number of simultaneous kickstarts we expect to experience is well within the capability of the hardware and network infrastructure we have available. When sizing a prospective kickstart server the limiting factors are most likely to be the hard drive data transfer rates and the network. Experience has shown up to 20 or so systems can be kickstarted simultaneously in about an hour with a very modest Pentium 4, a single IDE hard drive, and a 100Mb connection. Using a 3.0GHz Intel Core-Duo with 4GB of RAM and dual 120GB hard drives in RAID 1 configuration on a Gigabit Ethernet connection should allow us to support multiple simultaneous kickstarts in numbers far larger than we currently expect. The only reason we used this particular hardware is that it is what we had available. Kickstart Sequence of Events A network-based kickstart can be initiated by an PXE Boot capable network card. The PXE Boot first requests an IP address from a DHCP server. It also obtains the location of

a PXE Boot file from the DHCP server. PXELINUX is a bootloader for Linux using the PXE network booting protocol. The PXE Boot file is loaded from the TFTP server along with the contents of a file which defines the location and name of the installation kernel and initrd.img file as well as some parameters for the boot kernel and a menu for the Anaconda installer. This configuration file for Anaconda also contains the location of the kickstart configuration file to be used during the installation. The PXE Boot file then loads the boot kernel and initrd image still using TFTP. After booting, Anaconda is started and Anaconda loads the menu and displays a window with a timer with several menu options. The Menu and time-out can be skipped if you do not need to make any choices here. After choosing the desired kickstart installation, Anaconda locates the kickstart configuration file from the HTTP server and reads it. The kickstart configuration file has a default name of ks.cfg, but can be named anything. We use several for our different configurations, so provide unique names for each. If all of the data required to perform a complete installation is included in the kickstart configuration file, the installation completes without further intervention from the administrator. The RPM files used during the installation are downloaded from the HTTP server as they are needed. The kickstart configuration file can also contain bash script commands that can be run both before and after the rest of the installation. We make extensive use of the postinstallation bash scripts to perform installations of locally required RPM packages and tarballs as well as to make configuration changes before the first reboot. Hardware configuration In order to boot from the network it is necessary not only to have a network card that is capable of a network boot, but also to configure the BIOS to boot appropriately. You have a couple of options. The first is to always attempt to boot from the network as the first choice, then CD/DVD, and then from the hard drive. The second is to boot from the CD/DVD first, then the hard drive, and finally from the network. Choose the option that best fits your needs. When booting from the hard drive prior to booting from the network, an additional step requiring some manual intervention would be required to force a boot from the network. It is necessary to overwrite the boot record to prevent booting from the hard drive. This can be done with a small script or from the command line using the dd command but it is another point of intervention. We chose to configure BIOS to boot first from the network. We then set a short timeout for Anaconda so that the default is to boot to the hard drive if no other action is taken. DHCP Configuration

The /etc/dhcpd.conf file must be configured correctly to provide an IP address for each client host as well as information necessary to initiate a PXE Boot sequence for each kickstart client host. DHCP determines the host name using the MAC address of the NIC making the request. Although the IP address can be specified in the dhcpd.conf file, we use DNS to maintain the addresses and DHCP does the lookup and then passes the address to the host. DHCP can also serve a range of addresses rather than a specific address for each host, but that is outside the scope of this article.
####################################################################### allow booting;allow bootp;dns-update-style ad-hoc; option domain-name "cisco.com"; option domain-name-servers 109.99.6.247; max-lease-time 604800; default-lease-time 604800; deny unknown-clients; # The next-server line is required even though we point to ourselves. # Resolves some issues relating to pxeboot across subnets. next-server 109.99.101.74; # 109.99.222 Subnets: subnet 109.99.222.0 netmask 255.255.255.0 { authoritative ; option routers 109.99.222.1 ; } # Red Hat Enterprise Linux 5.1 Kickstart boxes group { filename "RHEL/pxelinux.0"; host ems-lnc100.cisco.com { hardware ethernet 00:15:17:1D:42:88 ; fixed-address emslnc100.cisco.com ;} host ems-lnx118.cisco.com { hardware ethernet 00:04:23:B7:9A:15 ; fixed-address emslnx118.cisco.com ;} host ems-lnx145.cisco.com { hardware ethernet 00:04:23:B5:6B:A9 ; fixed-address emslnx145.cisco.com ;} } #######################################################################

Listing 1: The very basic dhcpd.conf required to support kickstarts. The filename RHEL/pxelinux.0; statement in the group stanza directs the PXE Boot to load the pxelinux.0 boot file from the specified directory, RHEL. The full path for this directory in our setup is /opt/tftpboot/RHEL where /opt/tftpboot is a symbolic link to /tftpboot. The TFTP root, /tftpboot, is defined in /etc/xinetd.d/tftp. In each host stanza we specify the MAC address of the NIC in the respective hosts and the hostname. DHCP queries DNS for the IP address and passes it back to the host along with the router and DNS server information.

We discovered during configuration of our server for the kickstart role that the nextserver line is required in dhcpd.conf to resolve some PXE Boot issues even though the next-server is really the same server in our case. You should use this statement no matter which box hosts the PXE Boot server, even if it is the same as the DHCP server. It took us a couple days to figure this out and it is one of the things we could not find documented anywhere. The allow booting and allow bootp statements are both required for kickstarts to function. All of the options pertaining to PXE Boot can be placed in the group or individual host stanzas as well as in the global section of the DHCP configuration. This allows you as much granularity as you need to have multiple servers and kickstart configurations as well as to ensure that only specific hosts or groups of hosts can be kickstarted. The PXE Boot files Three PXE Boot files are required to perform a network boot. The first is pxelinux.0, the network boot loader. The second is the network boot kernel, vmlinuz, and the third is the initial RAM disk image, initrd.img. We placed pxelinux.0 in /opt/tftpboot/RHEL/ as this is the location we specified in dhcpd.conf. We also have discovered that this is the only place from which it works. The kernel and RAM disk image files are placed in a distribution or release unique location such as /opt/tftpboot/RHEL/RHEL-server. We also have an RHEL workstation based release we use and place its files in /opt/tftpboot/RHEL/RHEL-workstation. This allows us to keep them separate and helps us to know which is which. We have seen configurations in which files for different distributions and releases are all located in a single directory and named differently. Our method works better for us because we like the additional organization it imposes. For the most part one set of PXE Boot files is pretty much like another. Most Red Hat Enterprise based distributions currently provide a set of these files. Most of these files should work with most distributions. However we did find that the Red Hat Enterprise Linux 5.1 files are specific to that distribution and that PXE Boot files from other distributions such as CentOS do not work with RHEL 5.1. TFTP Configuration The TFTP configuration file, /etc/xinetd.d/tftp, should look like the sample configuration below. We changed disable = yes to disable = no and server_args = -s -c -v -v -v /tftpboot to server_args = -s -c -v -v -v /opt/tftpboot.
####################################################################### # default: off service tftp

} #######################################################################

disable = no socket_type protocol wait user server server_args per_source cps flags

= = = = = = = = =

dgram udp yes root /usr/sbin/in.tftpd -s -c -v -v -v /opt/tftpboot 11 100 2 IPv4

Listing 2. The TFTP configuration file required only minor changes. Creating the PXE Boot configuration file Each host that is to be kickstarted requires a unique configuration file which is located in the /opt/tftpboot/RHEL/pxelinux.cfg directory. This file is used to specify the locations of specific files such as the kernel and the initrd image file. These files are named with the hexadecimal representation of the IP address of the computer to be kickstarted. Youll find an online IP to Hex converter at http://tinyurl.com/4lzthf and another tool, written in Perl, is available at http://tinyurl.com/4pz6g3. Usage is very straightforward for each of these tools. For example, the IP address 192.168.0.55 converts to C0A80037 in hex, so in this case the name of the configuration file for the host with ip address 192.168.0.55 is C0A80037. Loading the PXE Boot configuration file The PXE Boot configuration files contain information that allows PXEBoot to locate the kernel and initrd image files for the kickstart process. They also specify the serial console parameters and provide a menu for selection of the desired kickstart. The kernel and initrd images are not the files that will be installed on the kickstarted machine, but are used only as the running operating system during the kickstart itself. The PXE Boot process tries to load the correct file for the computer by using an interesting algorithm. First it tries to load a file with a name based on the MAC address of the system, then with names based on the hexadecimal IP address, removing one hex digit for each failure. The sequence would look like this:
/opt/tftpboot/RHEL/pxelinux.cfg/01-22-33-44-aa-cc-ee /opt/tftpboot/RHEL/pxelinux.cfg/C0A80037 /opt/tftpboot/RHEL/pxelinux.cfg/C0A8003 /opt/tftpboot/RHEL/pxelinux.cfg/C0A800 /opt/tftpboot/RHEL/pxelinux.cfg/C0A80 /opt/tftpboot/RHEL/pxelinux.cfg/C0A8 /opt/tftpboot/RHEL/pxelinux.cfg/C0A

/opt/tftpboot/RHEL/pxelinux.cfg/C0 /opt/tftpboot/RHEL/pxelinux.cfg/C /opt/tftpboot/RHEL/pxelinux.cfg/default

The contents of our files is identical for each of the installations this process is designed for, so only a single master file is located at /opt/tftpboot/RHEL/pxelinux.cfg. Then we use a soft link with the hexadecimal IP address as its name to point to a master file. We can do this because all of our Intel boxes have the same kickstart choices available. You could also use individual files if that suits your needs better. The contents of our master file are shown below:
####################################################################### # RHEL5 Kickstart configuration file. # # NOTE: The workstation and server versions of the RHEL 5.1 images require # different initrd.img files. default 1 prompt 1 timeout 200 display msgs/Main.msg F1 msgs/Main.msg F2 msgs/general.msg F3 msgs/expert.msg F4 msgs/param.msg F5 msgs/rescue.msg #F1 Main.msg # Hard drive label 1 localboot 1 # RHEL5.1-MAX label 2 kernel RHEL-workstation/vmlinuz append ksdevice=eth0 initrd=RHEL-workstation/initrd.img \ console=ttyS0,9600n8 ramdisk_size=6804 \ ks=http://emstools2b.cisco.com/pub/kickstart/rhel-AP-Max-ks.cfg # RHEL5.1-MIN label 3 kernel RHEL-server/vmlinuz append ksdevice=eth0 \ initrd=RHEL-server/initrd.img console=ttyS0,9600n8 \ ramdisk_size=6804 ks=http://emstools2b.cisco.com/pub/kickstart/rhel-AP-Min-ks.cfg #######################################################################

Listing 3. PXE Boot configuration files

In Listing 3 the PXE Boot configuration files contain data to create a menu for Anaconda and information that allows the PXE Boot process to locate the files needed to boot. The append lines have been split for formatting purposes, but should be on a single line when used. Note that there are multiple stanzas in the file. One for each possible kickstart installation that is defined. Each stanza specifies different files for the vmlinuz, initrd.img and the location and name of the kickstart file to be used. Console parameters are also specified in the PXE Boot configuration file because we use the console to make the menu choice for the desired kickstart and to monitor the installation. We also added the statement ksdevice=eth0 to the append line. This prevents manual intervention to choose the install NIC when more than one NIC is present. This information was also very hard to find. This file also contains the definitions of the various menu options we want the Anaconda installer to provide, as well as the Function Key definitions for various help options. The menu options are created by Anaconda using the labels in each stanza. So the menu choices we have are 1, 2 and 3. Note that option 1 is local boot from the hard drive and that the default 1 line specifies that the system will boot to the hard drive after the timeout. The timeout 200 line specifies the length of the timeout in tenths of a second. This is a strange unit, but the value of 200 results in a timeout of twenty seconds. The data to generate and display the menu itself is located in the file /tftpboot/RHEL/msgs/Main.msg. Separating the files that specify the options from the file that displays the available options allows us to define hidden options should we need to do that.
####################################################################### 0a 09Welcome to 0cThe Cisco Linux09 Installer!07 | | . | | | . | | | . ' ' C I S C O 07 Enter number of the Linux distribution you wish to install: 1. Cisco CEL 4 2. Red Hat Enterprise Linux MIN (Test) 3. Red Hat Enterprise Linux MAX (DEV test) 05[F1-Main] [F2-General] [F3-Expert] [F4-Kernel] [F5-Rescue]07 #######################################################################

Listing 4: The file /tftpboot/RHEL/msgs/Main.msg

Youll see that Listing 4 contains the menu for the Anaconda installer. We have added our own options to the menu. Cisco Core router configuration The DHCP and TFTP protocols both use UDP rather then TCP packets. Most UDP packets are not forwarded across subnet boundaries and we have many different subnets in our network. Many Cisco routers with current versions of IOS have the ability to configure helper addresses for UDP packets. This enables the router to forward UDP packets to the DHCP and TFTP servers or to specific subnet(s). Based on our experience, you should only configure this on the core router closest to your server.
####################################################################### ip forward-protocol udp ! interface ethernet 1 ip helper-address 10.44.23.7 interface ethernet 2 ip helper-address 192.168.1.19 #######################################################################

Listing 5. Sample Configuration Youll find a sample configuration from the Cisco IOS IP Configuration Guide, Release 12.2, in Listing 5 that provides an example of the commands required to set up a helper address. If a protocol is not specified on your router, the helper address will forward all UDP packets to your kickstart server. If this is not what you want, be sure to specify only those protocols that need to be forwarded. This is another piece of information that was very hard to locate. Refer to the Cisco IOS IP Configuration Guide, Release 12.2, for details of this and related commands. This will not be an issue if your DHCP and TFTP servers are located in the same subnet as all of the hosts you wish to kickstart. Web Server (Apache) configuration We chose Apache for our web server because it is supplied by all Red Hat distributions and because we use it on other internal servers so are familiar with its operation. Once you have Apache installed and running, nothing else needs to be done to the configuration to make it work for kickstarts. All you have to do is place the files in a location that is served by Apache. Because we wanted our server to be as flexible as possible, we decided to plan for the eventuality that we would eventually support both FTP and HTTP kickstarts even though

we are only using HTTP at this time. Therefore we chose a directory structure starting at /var/ftp/pub and created a symbolic link to this location from /var/www/html.
ln -s /var/ftp/pub /var/www/html/pub

Making the RPMs Available While we wanted to make the ISO images of RHEL 5.1 available for download so that users can burn their own installation DVDs, it is also necessary to make the RPMs located in the ISO images available for the kickstarts. In order to accomplish this without having to store the files on the hard drive twice, we chose to keep only the ISO images on the hard drive and mount them using the loopback device to make the individual files in the ISO available to the kickstart. To accomplish this, the following directories were created.
/var/ftp/pub/rhel/5.1/isos/i386/ /var/ftp/pub/rhel/5.1/os

The iso images for RHEL 5.1 client and server were copied to the /var/ftp/pub/rhel/5.1/isos/i386 directory. The following entries were added to /etc/fstab to mount the ISOs automatically at boot time.
####################################################################### /var/ftp/pub/rhel/5.1/isos/i386/rhel-5.1-client-i386-dvd.iso \ /var/ftp/pub/rhel/5.1/os/i386/workstation iso9660 \ loop=/dev/loop1,ro 0 0 /var/ftp/pub/rhel/5.1/isos/i386/rhel-5.1-server-i386-dvd.iso \ /var/ftp/pub/rhel/5.1/os/i386/server \ iso9660 loop=/dev/loop2,ro 0 0 #######################################################################

Listing 6: /etc/fstab The entries in Listing 6 for /etc/fstab mount the ISO images so that the files in the images can be available for the kickstarts. Note that we chose to use the loop1 and loop2 devices instead of the loop0 device so that the loop0 device would be available to anyone wanting to use a loopback. The Kickstart Configuration File The kickstart configuration file, by default named ks.cfg, is used by Anaconda to define the parameters of the installation. This file provides the answers to all of the questions and entries to all of the fields required by the installation process. Only by having answers to each and every question can the kickstart be fully automated. If any of the required fields does not have an entry the installation halts and waits for input.

Creating the Starting ks.cfg File We initially created the kickstart file using the kickstart GUI configurator. Using this configurator allowed selection of the major software groups to be installed. There are other ways to obtain a kickstart configuration file to use as a starting point. Each time Red Hat Linux is installed, a kickstart configuration is stored at /root/anaconda-ks.cfg. This file can be used to exactly recreate the installation as it was performed. You could generate a kickstart file by performing a manual installation with the exact configuration you want and then use the anaconda-ks.cfg file generated as the starting point. We renamed our kickstart files from anaconda-ks.cfg to something more meaningful, rhel-AP-Max-ks.cfg, and rhel-AP-Min-ks.cfg. This enables us to know from the names which type of installation the file is for, and also to keep multiple files in the same directory. The kickstart configuration files have several sections. Each section has statements pertaining to a specific portion of the installation. Some sections are optional. We did not use the %pre section which allows running scripts before the installation begins, so we will start with the command section. Most of this should be relatively selfexplanatory, but if you need more information on any portion, the Red Hat Enterprise Linux Installation Guide (see Resources) contains an excellent description of each section of a kickstart file and describes each of the possible statements and commands that can be used. For the sake of brevity we will only discuss certain key portions of our kickstart file.
####################################################################### # This is an installation not an upgrade install # The location of the RPM files url --url http://emstools2b.cisco.com/pub/rhel/server key 9a09007d99b6cd00 lang en_US # Use text mode install text keyboard us xconfig --defaultdesktop kde --resolution 640x480 --depth 8 network --device eth0 --bootproto dhcp --onboot=on rootpw --iscrypted $1$tihTg7ne$hohhkj87hGGddg9B4WkXV1 authconfig --useshadow --enablemd5 selinux --disabled timezone America/New_York firewall --disabled firstboot --disable # Reboot after installation reboot bootloader --location=mbr --append="console=ttyS0,9600n8" clearpart --all --initlabel # define partitions part /boot --fstype ext3 --size=512

part part part part part part part part

/opt --fstype ext3 --size=10000 --grow /usr --fstype ext3 --size=10000 /tmp --fstype ext3 --size=7500 /var --fstype ext3 --size=7500 /home --fstype ext3 --size=2500 swap --size=2048 / --fstype ext3 --size=2048 /usr/local --fstype ext3 --size=2000

#######################################################################

Listing 7: The command section of our kickstart file. We added a key line to this section. This is what Red Hat calls the Installation number and is required to enable all Linux functionality. Just what would not be enabled is not specified. If the key line is not included in the kickstart files, the installation stops and waits for input which is not what we want. We specified a text mode install because, as mentioned before, we need to use the console for installation and a graphical installation would not work for us. We specified our console parameters in the bootloader line to ensure that they matched those of our console servers. Due to issues we had with creating LVMs using kickstart, we only created EXT3 partitions, not Logical Volumes. We intend to revisit this and determine whether Logical Volumes can be used. It may be that, because our procedures are to simply re-kickstart systems that have any significant issues, such an effort would be more trouble than it is worth. The %packages section of our kickstart file defines which groups are installed. These are the names preceeded by an @ sign. Individual RPM packages can also be specified just by placing the appropriate package name on a line by itself in this section. You can specify RPM packages that are not to be installed even if they are part of a group that you otherwise need to install. These RPMs are specified on a line by themselves but are preceeded by a - sign.
####################################################################### %packages @engineering-and-scientific @mysql @development-libs @editors @system-tools @gnome-software-development @text-internet @gnome-desktop @core @base

@ftp-server @network-server @legacy-software-development @java-development @printing @kde-desktop @mail-server @server-cfg @sql-server @admin-tools @development-tools @graphical-internet festival audit kexec-tools bridge-utils device-mapper-multipath dnsmasq imake -sysreport mc festival audit libgnome-java libgtk-java libgconf-java kexec-tools xorg-x11-server-Xnest xorg-x11-server-Xvfb -compiz-kde -knetworkmanager -amarok #######################################################################

Listing 8: The %packages section of the kickstart file defines the groups and packages to install. Using Post-installation scripts We invested a great deal of effort developing the post-install scripts defined in the %post section of the kickstart configuration file. These scripts allow us to perform installation and configuration of RPMs and tarballs that are not part of the Red Hat installation. The important thing to remember about the post-installation scripts is that they are executed using the bash command interpreter in a chrooted environment that behaves as it will when rebooted after the installation. This allows virtually any action that you could possibly work into a script to be performed during the final stages of installation.
####################################################################### %post # Install the yum repository configuration files cd /tmp wget http://emstools2b.cisco.com/pub/local/lab-repos.tar

cd / tar -xvf /tmp/lab-repos.tar # Set an ID to be used for other scripts touch /LINUX_RHEL_MINIMAL_INSTALL # Install Kshell as a preference of some developers. yum -y install ksh # Configure some local NFS mount points service portmap start mount emsnfs:/export/linux/post /mnt cat /mnt/auto_localnfs >> /etc/auto.misc cat /mnt/auto_misc >> /etc/auto.misc # Get the command to create the motd and create it for the first time. cp /mnt/createMOTDLinux /etc/init.d/create_motd mv /etc/motd /etc/motd.orig /etc/init.d/create_motd > /etc/motd umount /mnt # Create symlinks for mount points # the links to /localnfs are to work around the issue with Linux # mount points not being browsable as they are in Unix mkdir /localnfs ln -s /misc/apps /localnfs/apps ln -s /misc/rtp-chaos /localnfs/rtp-chaos ln -s /misc/black-hole /localnfs/black-hole ln -s /misc/tools /localnfs/tools ln -s /misc/tftpboot /localnfs/tftpboot mkdir /opt/scratch ln -s /opt/scratch /scratch # Create ssh authorized keys # Make the directory mkdir /root/.ssh # Create the keys file cat << xxEOFxx >> /root/.ssh/authorized_keys sh-dss AAAAB3NzaC1kc3MAAACBAKyW6vv6uHKGKL54765VBHKJHhbfvfhJ/rkspGK2pmAM7awj7EwB / wUBZUucmQSYnyaOlbvS6NkdE+sUC/asU/mEZjzoQgP+kdahxfJvWATaJweVFjRdHrIZxPB4 nlO+MEBb cPmUP7cLLQ1KGbfUakr35qzb9RjpBPDcBSDW2GZRAAAAFQCD/qw8FCSfEyWAmtkXDioJBWU COwAAAIAm 4czfxx+Srm7FxGDTsiL52ojKzZCzddTi6YclknBXYpa3jhjhDfgkbGfHc746cVXm3hJ9ZgA 3RQpMypKn WS6EHimjkjEeqfw/viqPR1NCvj1xVs9XDjRtCelwsxUNj31Y2RHCsusa6DDwG765bnlk/BO 4lUGRQpNy QAAjKyDhPwAAAIAPJQcSf0tc4OrqNxy/gjkhkhgghfTRerthkljhGuyKarrmWan9ZkkFJQY np09GNasZ zI7Zwau3oqfutPTWJFehBskFKvRpSjYd59vKjWpDyCE5xHYxZfDORTj4pzjRSyiXDP/viA5 DBCUWieM4 zGWa1RKVdskjPFS56y5GAkEwcA== root@emsjumpsssh-dss AAAAB3NzaC1kc3MAAACBAOqZBr62GU

La+NwGUatvO7OVXqGDn4qXvR2GAUputz9uyYmcWTvoHG0D3eAQ2flqhpyhJQo63GyntUtmG kXIHFuM3z 4qDt19qcpFRj10ZzRbZGhf+QbJwkxA9fpOy/BmoYykW5l36Db/Dvlzk4zNgJAmGXb2rNv8R SqYC6kCZf aNAAAAFQDTb8EsksyknY++4zXC3TPNrH/ +MwAAAIEAz3OCUfZXo+e/lJ/KSFj1un378KGGo9qfGSpVMV Tva/z58KAZ174tJpgnfA8+fQOwq/ip8s9UyHA2qR+BICjjZo1KatevFN7l4rpNSqdLivEas rGBu6fRTP / kQ6vt+OLIAQyr8t9RqpZKUVdd9odFA9NLiuOhG//eh2cDSXmjFnkAAACAbgzdEMcCMeMT/X PJrkZ/md TX/EJ6VNQEuTP3fhrjKKjccYobXPOQhvliIhPGFbtrRZlYRPPFAkAAse0qRPOsy8XHKD18W nQr5JNJx+ C5PYMkb8APY55Ydwwrt4EFeqnFpF3RXFhPY1eiZNAI33GopEGVTiLTO4ZW9mYC8EI7e28= root@emstools xxEOFxx # Copy the logbanner and change sshd_config cat << xxEOFxx >> /etc/LogBanner WARNING!!! READ THIS BEFORE ATTEMPTING TO LOGON This System is for the use of authorized users only. Individuals using this computer without authority, or in excess of their authority, are subject to having all of their activities on this system monitored and recorded by system personnel. In the course of monitoring individuals improperly using this system, or in the course of system maintenance, the activities of authorized users may also be monitored. Anyone using this system expressly consents to such monitoring and is advised that if such monitoring reveals possible criminal activity, system personnel may provide the evidence of such monitoring to law enforcement officials. Cisco Acceptable Use Policy: http://wwwin.cisco.com/infosec/policies/acceptable_use.shtml xxEOFxx echo "Banner /etc/LogBanner" >> /etc/ssh/sshd_config #######################################################################

Listing 9: Post-installation Script Example Youll see that Listing 9 contains a partial listing of our post-installation script which installs both RPMs and tarballs designed for our unique lab environment as well as performing other necessary tasks. As you can see, our post-installation is quite extensive. In addition to performing installations of several software packages we require, it also sets up a login banner, creates the /root/.ssh directory and copies some public keys there. We have only shown one of these keys to save space.

Notice that we can also start services as in the line service portmap start and access files on NFS mounts during this last portion of the kickstart. Post-installation provides a very flexible environment for performing a great many automated tasks. Perform the kickstart Performing the kickstart is very easy because we have done all of the hard work in setting up the network kickstart. We have four basic steps to perform. 1. 2. 3. 4. Add the computer to DNS. Add the appropriate information to the dchpd.conf file. Boot the computer. Select the desired kickstart from the menu.

The automated kickstart does the rest. The first two steps only need to be performed the first time a computer is kickstarted; after that the DNS and DHCP information will already be there. Troubleshooting a failing Kickstart The most common problems with network kickstarts the way we have set it up are network failures, MAC addresses that are incorrectly entered in the dhcpd.conf file, using the MAC address for the wrong NIC. These problems will present themselves on the console with messages from PXE Boot on the NIC unable to obtain an IP address. An incorrectly named hexadecimal IP address file for a system or a problem with the TFTP server will allow the NIC to obtain the network data, but fails to load the PXE Boot configuration file for the system. Be sure your TFTP server is configured correctly using the tftp file in the /etc/xinetd.d directory. David Both is a Linux guru and works as a Software Engineer and part-time lab administrator at Cisco Systems in RTP, North Carolina. He has over 30 years in the IT industry and enjoys writing code. He is and RHCE and is currently working on his CCNA. Bruce Garland is a development and test lab manager for Cisco Systems in RTP, North Carolina. He has nearly 30 years of experience in computer systems and networking. Solaris certified and still remembers DCL (VAX/VMS)

Comments on "Complete Kickstart: How to Save Time Installing Linux"


internetbummer

Great guide except that its a little outdated now.

cobbler.et.redhat.com Cobbler does all of that almost automatically on install, and gives you a lot more flexibility in terms of scripting additional install options. August 28th, 2008 at 7:36 am Reply

Thank You Guys for an absolute wonderful detailed document you have created, this should teach some lesson to Red Hat Doc people. Im about to take RHCE myself. I just have one question in the paste below, what is the first line, im confused, and do we have to create all these file. /opt/tftpboot/RHEL/pxelinux.cfg/01-22-33-44-aa-cc-ee /opt/tftpboot/RHEL/pxelinux.cfg/C0A80037 /opt/tftpboot/RHEL/pxelinux.cfg/C0A8003 /opt/tftpboot/RHEL/pxelinux.cfg/C0A800 /opt/tftpboot/RHEL/pxelinux.cfg/C0A80 /opt/tftpboot/RHEL/pxelinux.cfg/C0A8 /opt/tftpboot/RHEL/pxelinux.cfg/C0A /opt/tftpboot/RHEL/pxelinux.cfg/C0 /opt/tftpboot/RHEL/pxelinux.cfg/C /opt/tftpboot/RHEL/pxelinux.cfg/default November 22nd, 2011 at 8:32 pm
troll666

Reply

Well, as one of the authors, outdated is not quite the right word. The info is current, it is just that the authors didnt find cobbler before rolling their own. Also, there are lots of admins out there that want to understand what is happening and why. when it breaks, they know the piece to fix on their own. Understanding the kickstart process can save hours of time debugging why the latest hardware fails to kick or to help trace a single byte error in a config file. cobbler does look interesting and I will probably install it at some point and give it a whirl. It may be better for future deployments or it may have functions that we will build into our existing server. BRuce August 28th, 2008 at 9:58 am
jrzagar

Reply

One of the main limitations I find in kickstart is in selecting the type of hard drive Some systems use SATA (/dev/sd[a-z]), others use IDE (/dev/hd[a-z]), and some vendors controllers dont follow either convention (e.g. HP raid controllers use /dev/cciss/) I use a %pre script to automatically generate the partition information:
###### # Disk configuration now handled by pre-install script %include /tmp/partitions

... %pre ###### # Auto-detect IDE/SATA/SCSI drive and adjust appropriately... # Doesn't work with HP/Compaq SmartArray controller # DISK="`egrep '[hs]d[a-z]( |$)' /proc/partitions | \ # awk 'NR==1 {print $4}'`" # echo $DISK # Regular expressions that match different kinds of disk drives # The HP cciss driver does not assign /dev/sd[a-z] names... # *** WARNING *** # Entering deep Bash quotation hell... # Work-around for busybox bug in RHEL-4.U3 DISK="" REGEXP01="'[hs]d[a-z]( |$)'" REGEXP02="'cciss/c[0-9]d[0-9]( |$)'" for regexp in `set | grep ^REGEXP | cut -d= -f1` do eval EXPR=`eval "echo \$\{$regexp\}"` CMD="egrep ${EXPR} /proc/partitions" DISK="`eval "$CMD"| \ awk 'NR==1 {print $4}'`" if [ -n "${DISK}" ] then echo $DISK break fi

done # Now leaving Bash quotation hell... # bug in RHEL-4 busybox-1.00rc1-5 # # cat - > /tmp/regexp.partitions /tmp/partitions August 28th, 2008 at 12:00 pm
jrzagar

Reply

# # # # # #

[hs]d[a-z]( |$) cciss/c[0-9]d[0-9]( |$) EOF DISK="`egrep -f /tmp/regexp.partitions /proc/partitions | \ awk 'NR==1 {print $4}'`"

cat > /tmp/partitions August 28th, 2008 at 12:15 pm


neiliss

Reply

You are not required to mount the .iso files to the loopback device. The installer is able to recognize and mount the .iso files. August 28th, 2008 at 12:18 pm
jrzagar

Reply

ARGH, things keep gettng chopped off


cat > /tmp/partitions &lt&ltEOF clearpart --linux --drives=${DISK} part /boot --fstype ext3 --size=256 --ondisk=${DISK} part pv.6 --size=1 --grow --ondisk=${DISK} volgroup vg00 --pesize=32768 pv.6 logvol / --fstype ext3 --name=rootfs --vgname=vg00 --size=20480 logvol swap --fstype swap --name=swapfs --vgname=vg00 --size=2048 logvol /opt/packages --fstype ext3 --name=packages --vgname=vg00 --size=8192 EOF

August 28th, 2008 at 12:18 pm


troll666

Reply

jrzagar, I am assuming you have a need to select the exact drive you want to kick start on. Since most of our machines have just one drive, we dont specify anything. In systems with more than one drive it just uses the first one. the code looks like it has the same functionality that i used a long time ago in differentiating drives on Solaris machines during pre jumpstart processing. August 28th, 2008 at 12:43 pm
troll666

Reply

thanks for the tip, we can simplify our config on the kickstart server. August 28th, 2008 at 12:53 pm
lashby

Reply

A typical LVM partitioning entry for our kickstarts (with a large /home):
## Base hard drive partitioning with LVM part /boot --fstype ext3 --size=128 --asprimary part swap --fstype swap --size=4096 --asprimary part pv.1 --size=1 --grow --asprimary

### LVM setup volgroup vg01 --pesize=16384 pv.1 logvol / --fstype ext3 --vgname=vg01 --size=2048 --name=root logvol /usr --fstype ext3 --vgname=vg01 --size=8192 --name=usr logvol /opt --fstype ext3 --vgname=vg01 --size=4096 --name=opt logvol /var --fstype ext3 --vgname=vg01 --size=4096 --name=var logvol /tmp --fstype "ext3" --vgname=vg01 --size=4096 --name=tmp logvol /home --fstype "ext3" --vgname=vg01 --size=1 --grow --name=home August 28th, 2008 at 7:27 pm
mohanpoddar

Reply

Very Helpfull to me, The information in this article is very useful. After reading this article, now i am able to implement installation using kickstart. August 30th, 2008 at 4:30 am
davidtangye

Reply

I have been doing similar stuff: autoinstalling Redhat years ago, and netbooting lately. I have not combined them yet.

I played with kickstart briefly under Redhat and see that it is an option still under Ubuntu. I have done similar to you with pxe-netbooting. However I am using a separate bootp server instead of dhcp to assign the ip address and provide the pxe config adn menu files. (Details are recorded as the first section of this page.). My main comment on your article: In the section Kickstart Sequence of Events After The PXE Boot file is loaded from the TFTP server, the rest of the section and the next section are confusing to me: I have done similar and still cannot follow you. The pxelinux boot kernel, and the installer linux kernel are confused. The former presents the PXE Boot configuration file, later referred to as our master file, and then within it as RHEL5 Kickstart configuration file. I believe its best name is the PXE Boot configuration file, and 3 different terms are confusing. The latter (the installer kernel and initrd chosen from the menu of the PXE Boot) actually runs the Anaconda installer does it not? So keep the terms clearly and consistently named. As I understand it: 1. You boot a pxe program via netboot and its pxe extension facility. 2. Pxe uses tftp to get the PXE Boot configuration file and its associated menu files and present them to you. 3. You choose an item based on a PXE menu file, and its boots whatever is in the associated relevant stanza of the PXE Boot configuration file. This is normally a linux kernel and its relevant initrd, which runs in this case Anaconda, the linux installer. The stanza in this case also includes a parameter to Anaconda which is the kickstart file Anaconda will use to automate itself, and thus automate an install. Hmm every time I write this stuff its gets written more clearly and concisely (I hope). Other comments: I also used ftp for a while, but dropped it and just stick with http now. I see no need for ftp at all anymore here. After installation I use mc too, and access remote hosts via its ssh mechanism (Shell link), so even nfs is dropping away for me too. tftp is limited in its functionality. It seems that it will not access files across symbolic links that traverse mount points. It jails you somewhat, and this is possibly a deliberatelyinbuilt security consideration. Like you I found information on some of these aspects difficult or impossible to find. Its a problem in the open-source world: good stuff badly presented or badly worded, or effectively hidden by omission to document at all.

Overall I found the article very good, and got a few good tips. (pxelinux.cfg/C0A80037 is based on the ip address (not the MAC address): good to know) ps Ubuntu has an alternative to kickstart. It is similar in concept, supposedly more powerful, but its very unfriendly to generate its response file (eg there is no GUI) or make sense of what it produces during an installation run (comparable file to your /root/anaconda-ks.cfg). September 2nd, 2008 at 3:31 am
dboth

Reply

Thanks for your comments. We are glad you were able to find some useful information. Your understanding does seem correct. We found the terminology quite confusing also in the various documents we found and had hoped that we were able to fix that; apparently we were not completely successful in that. September 3rd, 2008 at 5:33 am
kenshelby

Reply

Thank you! I found this to be a very helpful article. I thought that I must be going mad, until I read your comment, some necessary information is very difficult to find. Our field engineers need a way to update industrial compact-PCI machines that have no floppy and no CD/DVD, and while the BIOS supports PXE, it wont boot from a USB drive. (Yes, the boxes are *that* old.) After I get all my kickstart kinks ironed out, I plan to create a VM out of my kickstart server and have our field engineers run that on their laptops. Thanks again very much! for gathering all the disparate bits together in one easy-toread place! June 24th, 2009 at 8:03 am
altrunemorph

Reply

Hi! I want to thank you both David Both and Bruce Garland for such a complete guide to get kickstart running. This is the best and most complete HOWTO refering to this subject. Great work. March 31st, 2011 at 4:07 am
challaa

Reply

Thanks, it was very useful for me

September 7th, 2011 at 10:39 pm

Reply

Heya i?m for the first time here. I found this board and I to find It truly helpful & it helped me out much. Im hoping to present something again and aid others such as you aided me. November 10th, 2011 at 6:06 am Reply

I believe that is among the most important information for me. And i am happy studying your article. But should observation on few common things, The website style is perfect, the articles is in point of fact excellent : D. Excellent activity, cheers November 21st, 2011 at 1:24 am Reply

Wow, wonderful weblog structure! How lengthy have you ever been blogging for? you made running a blog look easy. The entire look of your web site is excellent, as neatly as the content! December 4th, 2011 at 12:18 pm Reply

Generally I do not read article on blogs, but I would like to say that this write-up very compelled me to take a look at and do so! Your writing style has been amazed me. Thank you, very nice article.

Close http://www.brainpulse.com/Knowledge Base/Linux/Types Of Kickstart Installation In Linux Hosting KB


Cpanel (105) Linux (35) Plesk Linux (92)

Plesk Windows (92) Tomcat (26) VPS Virtuozzo (36) WHM (50) Windows (42)

Web Hosting

Reseller Hosting Linux Hosting Windows Hosting Dedicated Server VPS Hosting Cloud Hosting

Types Of Kickstart Installation In Linux


Server administrators choose the criterion whether they need to perform new installation or an existing system upgrade. You may choose required type of installation methods that suit your needs. Choose the type of Kickstart installation or upgrade screen from the following options: CD-ROM: Choose this option to install or upgrade from the Red Hat Enterprise Linux CDROMs. NFS: To install or upgrade from an NFS shared directory. In the text field for the the NFS server, enter domain name or IP address. FTP: To install or upgrade from an FTP server. In the FTP server text field, enter domain name or IP address. HTTP: To install or upgrade from an HTTP server. In the text field for the HTTP server, enter the domain name or IP address. Hard Drive: To install or upgrade from a hard drive. Hard drive installations require the use of ISO (or CD-ROM) images. Be sure to verify that the ISO images are inta

Prev Next

Chapter 32. Kickstart Installations


32.1. What are Kickstart Installations? 32.2. How Do You Perform a Kickstart Installation? 32.3. Creating the Kickstart File

32.4. Kickstart Options 32.4.1. Advanced Partitioning Example 32.5. Package Selection 32.6. Pre-installation Script 32.6.1. Example 32.7. Post-installation Script 32.7.1. Examples 32.8. Making the Kickstart File Available 32.8.1. Creating Kickstart Boot Media 32.8.2. Making the Kickstart File Available on the Network 32.9. Making the Installation Tree Available 32.10. Starting a Kickstart Installation

32.1. What are Kickstart Installations?


Many system administrators would prefer to use an automated installation method to install Red Hat Enterprise Linux on their machines. To answer this need, Red Hat created the kickstart installation method. Using kickstart, a system administrator can create a single file containing the answers to all the questions that would normally be asked during a typical installation. Kickstart files can be kept on a single server system and read by individual computers during the installation. This installation method can support the use of a single kickstart file to install Red Hat Enterprise Linux on multiple machines, making it ideal for network and system administrators. Kickstart provides a way for users to automate a Red Hat Enterprise Linux installation. All kickstart scriptlets and the log files of their execution are stored in the /tmp directory to assist with debugging

30.10. Starting a Kickstart Installation


To begin a kickstart installation, you must boot the system from boot media you have made or the Red Hat Enterprise Linux CD-ROM #1, and enter a special boot command at the boot prompt. The installation program looks for a kickstart file if the ks command line argument is passed to the kernel. CD-ROM #1 and Diskette The linux ks=floppy command also works if the ks.cfg file is located on a vfat or ext2 file system on a diskette and you boot from the Red Hat Enterprise Linux CD-ROM #1. An alternate boot command is to boot off the Red Hat Enterprise Linux CD-ROM #1 and have the kickstart file on a vfat or ext2 file system on a diskette. To do so, enter the following command at the boot: prompt:
linux ks=hd:fd0:/ks.cfg

With Driver Disk If you need to use a driver disk with kickstart, specify the dd option as well. For example, to boot off a boot diskette and use a driver disk, enter the following command at the boot: prompt:
linux ks=floppy dd

Boot CD-ROM

If the kickstart file is on a boot CD-ROM as described in Section 30.8.1, Creating Kickstart Boot Media, insert the CD-ROM into the system, boot the system, and enter the following command at the boot: prompt (where ks.cfg is the name of the kickstart file):
linux ks=cdrom:/ks.cfg

Other options to start a kickstart installation are as follows:


askmethod

Do not automatically use the CD-ROM as the install source if we detect a Red Hat Enterprise Linux CD in your CD-ROM drive.
autostep debug dd dhcpclass= <class>

Make kickstart non-interactive. Start up pdb immediately. Use a driver disk. Sends a custom DHCP vendor class identifier. ISC's dhcpcd can inspect this value using "option vendor-class-identifier".

dns= <dns> driverdisk expert

Comma separated list of nameservers to use for a network installation. Same as 'dd'. Turns on special features:

allows partitioning of removable media prompts for a driver disk

gateway= <gw>

Gateway to use for a network installation.


graphical isa

Force graphical install. Required to have ftp/http use GUI. Prompt user for ISA devices configuration.

ip= <ip> keymap= <keymap>

IP to use for a network installation, use 'dhcp' for DHCP. Keyboard layout to use. Valid values are those which can be used for the 'keyboard' kickstart command.

ks=nfs: <server> :/ <path>

ks=http:// <server> / <path>

The installation program looks for the kickstart file on the NFS server <server> , as file <path> . The installation program uses DHCP to configure the Ethernet card. For example, if your NFS server is server.example.com and the kickstart file is in the NFS share /mydir/ks.cfg, the correct boot command would be ks=nfs:server.example.com:/mydir/ks.cfg. The installation program looks for the kickstart file on the HTTP server <server> , as file <path> . The installation program uses DHCP to configure the Ethernet card. For example, if your HTTP server is server.example.com and the kickstart

file is in the HTTP directory /mydir/ks.cfg, the correct boot command would be ks=http://server.example.com/mydir/ks.cfg.
ks=floppy

ks=floppy:/ <path>

The installation program looks for the file ks.cfg on a vfat or ext2 file system on the diskette in /dev/fd0. The installation program looks for the kickstart file on the diskette in /dev/fd0, as file <path> .

ks=hd: <device> :/ <file>

ks=file:/ <file>

The installation program mounts the file system on <device> (which must be vfat or ext2), and look for the kickstart configuration file as <file> in that file system (for example, ks=hd:sda3:/mydir/ks.cfg). The installation program tries to read the file <file> from the file system; no mounts are done. This is normally used if the kickstart file is already on the initrd image.

ks=cdrom:/ <path> ks

The installation program looks for the kickstart file on CD-ROM, as file <path> . If ks is used alone, the installation program configures the Ethernet card to use DHCP. The kickstart file is read from the "bootServer" from the DHCP response as if it is an NFS server sharing the kickstart file. By default, the bootServer is the same as the DHCP server. The name of the kickstart file is one of the following: If DHCP is specified and the boot file begins with a /, the boot file provided by DHCP is looked for on the NFS server. If DHCP is specified and the boot file begins with something other than a /, the boot file provided by DHCP is looked for in the /kickstart directory on the NFS server. If DHCP did not specify a boot file, then the installation program tries to read the file /kickstart/1.2.3.4-kickstart, where 1.2.3.4 is the numeric IP address of the machine being installed.

ksdevice= <device>

kssendmac

The installation program uses this network device to connect to the network. For example, consider a system connected to an NFS server through the eth1 device. To perform a kickstart installation on this system using a kickstart file from the NFS server, you would use the command ks=nfs: <server> :/ <path> ksdevice=eth1 at the boot: prompt. Adds HTTP headers to ks=http:// request that can be helpful for provisioning systems. Includes MAC address of all nics in CGI environment variables of the form: "X-RHN-Provisioning-MAC-0: eth0 01:23:45:67:89:ab".

lang= <lang>

loglevel= <level>

Language to use for the installation. This should be a language which is valid to be used with the 'lang' kickstart command.

Set the minimum level required for messages to be logged. Values for <level> are debug, info, warning, error, and critical. The default value is info.
lowres mediacheck

Force GUI installer to run at 640x480. Activates loader code to give user option of testing integrity of install source (if an ISO-based method).

method=cdrom method=ftp:// <path>

Do a CDROM based installation. Use <path> for an FTP installation.

method=hd: <dev> : <path> method=http:// <path> method=nfs: <path> netmask= <nm> nofallback nofb

Use <path> on <dev> for a hard drive installation. Use <path> for an HTTP installation. Use <path> for an NFS installation. Netmask to use for a network installation. If GUI fails exit. Do not load the VGA16 framebuffer required for doing text-mode installation in some languages.

nofirewire noipv6 nokill

Do not load support for firewire devices. Disable IPv6 networking during installation. A debugging option that prevents anaconda from terminating all running programs when a fatal error occurs. Don't automatically mount any installed Linux partitions in rescue mode.

nomount nonet

noparport nopass

Do not auto-probe network devices. Do not attempt to load support for parallel ports. Don't pass keyboard/mouse info to stage 2 installer, good for testing keyboard and mouse config screens in stage2 installer during network installs. Ignore PCMCIA controller in system.

nopcmcia noprobe noshell

Do not attempt to detect hw, prompts user instead. Do not put a shell on tty2 during install.

nostorage nousb

Do not auto-probe storage devices (SCSI, IDE, RAID). Do not load USB support (helps if install hangs early sometimes).

nousbstorage

Do not load usbstorage module in loader. May help with device ordering on SCSI systems.
rescue resolution= <mode> serial skipddc

Run rescue environment. Run installer in mode specified, '1024x768' for example. Turns on serial console support. Skips DDC probe of monitor, may help if it's hanging system.

syslog= <host> [: <port> ]

text

Once installation is up and running, send log messages to the syslog process on <host> , and optionally, on port <port> . Requires the remote syslog process to accept connections (the -r option). Force text mode install.

updates updates=ftp:// <path>

Prompt for floppy containing updates (bug fixes). Image containing updates over FTP.

updates=http:// <path> upgradeany vnc

Image containing updates over HTTP. Don't require an /etc/redhat-release that matches the expected syntax to upgrade. Enable vnc-based installation. You will need to connect to the machine using a vnc client application. Once installation is up and running, connect to the vnc client named <host> , and optionally use port <port> . Requires 'vnc' option to be specified as well.

vncconnect= <host> [: <port> ]

vncpassword= <password>

Enable a password for the vnc connection. This will prevent someone from inadvertently connecting to the vnc-based installation. Requires 'vnc' option to be specified as well.

Prev30.9. Making the Installation Tree Available Up Home NextChapter 31. Kickstart Configurator

Kickstart Installation on Red Hat/Fedora Core Linux

Kickstart is a system for automated installation of Red Hat Linux or Fedora Core Linux. Instead of answering all the installation questions manually, one can put configuation information and packages selection into a file which is read and executed by the installation program. This page provides general information, links and some tools for creating or manipulating kickstart configuration files and boot images. A separate page describes the "Kick Me" boot configuration disks in more detail.
Last updated: 25 August 2010

Red Hat Linux comes with a system for automatic installation called Kickstart. Instead of answering all the installation questions manually, including all the details of package selection, you can put your answers and list of packages into a file which will automatically be read by the installation program at startup. This can be very useful for installing a specific known configuration on a collection of machines, such as a grid cluster or a Beowulf cluster. It is also fairly easy to copy files or run shell scripts noninteractively to customize the installation. Listed below are:

A link to the Kick Me disk Kickstart boot disk images Sample Kickstart configuration file (ks.cfg) Information on alternate consoles Post-installation processing - files and scripts Rachael script to "clone" a machine Randy script to help edit a custom initial RAM disk

The scripts Rachael and Randy are pretty rough and should only be used as guides for helping you make your own Kickstart configurations. This is not highly automated or easy or clean. Good luck (you'll need it). Documentation about Kickstart is available from Red Hat at: http://www.redhat.com/docs/manuals/linux/RHL-7.3-Manual/custom-guide/chkickstart2.html Note that there have been some changes to the configuration files commands between RH 6.x and RH 7.x. Most notably, an FTP installation used to be done with the ftp command but is now performed using the url command. The current examples are for RH 7.3, but I plan to update them to Fedora Core 3 when I can.

Kick Me disks
"Kick Me" is a floppy disk image created to perform a custom installation of Red Hat or Fedora Core Linux over the network using Kickstart. Details of the "Kick Me" disk can be found here

Kickstart Disk Images


The disk images at the link below are slightly modified version of the standard Red Hat or CERN boot disks. They include a ks.cfg configuration file, but you can also replace this with your own modified version if you like. Here is how to use these images. 1. Download one of these disk images as a binary file (you'll probably need to right-click on the link to download): "Kick-Me" Kickstart Boot Disk Image 1.11 for Red Hat Linux 7.3 (as of 5 October 2003) Kickstart Boot Disk Image for CERN Red Hat Linux 7.2.1 (as of 1 July 2002) Kickstart Boot Disk Image for Red Hat Linux 6.2 (as of 18 December 2001) 2. Copy it to a floppy, as with:

dd if=kick-me-X.X.img of=/dev/fd0 bs=1k

3. Mount the floppy disk (it's in FAT format) and edit the file ks.cfg to your liking. Comments are included to help. You should at least change your NFS or FTP server IP address and the path to the RedHat directory, or you'll end up trying to load from mine (which probably won't work). 4. Boot from that flopppy, and at the boot prompt enter
linux ks=floppy

Sample Configuration File


A copy of this file, or something close to it, is already on the boot disk image, but I've put a copy here so that you can look through it without having to get the disk image.
ks.cfg

This file is for the CERN/Red Hat Linux 7.2.1 installations for our ATLAS Grid Testbed site. You should consider this as just a starting point for building your own ks.cfg file. In the least, you should edit it to change the networking and server information.

Alternate Consoles
A lot of information is made available during the installation process on alternate consoles. Press ALT and a function key to switch to a different console. This is especially useful if the installation fails, because you can get more detailed error messages this way, or even a shell.

Console 1 (ALT-F1): graphical installation status (what's normally shown during installation). Console 2 (ALT-F2): bash shell (once the installation has progressed far enough). Console 3 (ALT-F3): Installation progress log, including module insertion. The cause of an error can often be found here. Console 4 (ALT-F4): Appears to be a log of raw device/SCSI information. Console 5 (ALT-F5): Appears to be a log of filesystem operations.

Post-installation processing
It is possible to run shell commands after package installation. It is even possible to copy over files via FTP and install them, and to run shell scripts that have been copied over. Here is an outline of how our installation system works at U-M: 1. First, a few simple commands are executed from the ks.cfg file to copy over other files via FTP. (See the example ks.cfg file for an example of how this is done non-interactively. Look for the commands at the end of the file, after the %post directive.) 2. One of the files is linatX-install.tar which is unpacked under / to put configuration files in place. 3. Another file is a script called ks.sh which is copied to /root and then run to finish the configuration process. 4. The file /etc/rc.d/rc.local is also run once to finish configuration (and then it replaces itself with a simpler version of itself).

Rachael - creating a custom configuration file


This script will copy the configuration of a Red Hat Linux machine into a kickstart configuration file ks.cfg so that you can use it for a kickstart installation to make a replica of the original machine. The main thing it does is create a list of installed packages. It tries to verify that they are actually available from the installation source, which may or may not be too restrictive. (A Kickstart installation will fail if a package in the list of those to install is not available.)
Rachael

The name comes from the Rachael character from Blade Runner. She was was a "replicant". (Whether Deckard was a replicant is debatable.) The current version of Rachael creates a Kickstart file for RH 6.2, but I will probably update it for RH 7.2 soon.

Randy - creating a custom initial RAM disk


The original point of this script was to make a copy of an initial RAM disk (initrd) from one of the RedHat installation bootdisks while making it possible to remove unneeded modules to make space on the disk for a Kickstart configuration file. But you can also use it to add modules for devices that are not included in the original boot disk. Note: This is not an automatic tool, it just provides a lot of assistance. You still have to know what the hell you are doing.
Randy

If you are at the point of digging into this kind of thing in earnest then you may want to read the script /sbin/mkinitrd (and the man page for it) for a better idea of how an initrd is constructed.
Eric Myers <myers@vassar.edu> 5 August 2003 http://www.spy-hill.net/~myers/linux/kickstart/index.html

How Kickstart Works


This document will describe the pieces involved in the kickstart process and how they work together. What is Kickstart? The Bootdisk The Kickstart Server Postinstall Making better use of KickStart

What is Kickstart?
Due to the need for automated installation, Red Hat has created the kickstart installation method. With this method, a system administrator can create a single file containing the answers to all the questions that would normally be asked during a typical Red Hat interactive Linux installation. Kickstart files can be kept on single server system, and read by individual computers during the installation. The kickstart installation method is powerful enough that often a single kickstart file can be used to install Red Hat Linux on multiple machines, making it ideal for network and system administrators. Kickstart lets you automate most of a Red Hat Linux installation, including:

Language selection

Network configuration Keyboard selection Boot loader installation (LILO) Disk partitioning Mouse Selection X Window System configuration

Kickstart installations can only be performed using a local CD-ROM, a local hard drive, or NFS installation methods. FTP and HTTP installations cannot be automated using kickstart mode. (Starting with RedHat 7.0 and higher, FTP and HTTP are now supported) To use kickstart mode, you must first create a kickstart file (ks.cfg), and make it available to the Red Hat Linux installation program. Where to put a KickStart File: A KickStart file must be placed in one of two locations.

On a network On a bootdisk

To do a network-based KickStart installation, you must have a BOOTP/DHCP server on your network, and it must include configuration information for the machine on which you are attempting to install Red Hat Linux. The BOOTP/DHCP server will be used to give the client its networking information as well as the location of the KickStart file. To perform a diskette-based KickStart installation, the KickStart file must be named ks.cfg, and reside in the boot disk's top-level directory. Note that the RedHat Linux boot disks are in MS-DOS format, making it easy to copy the KickStart file under Linux using the mcopy command. In the case of the KickStart-Tools package the we have put together it was decited that we would go with locating the ks.cfg file on the floppy bootdisk. Even if we put the ks.cfg on the network somewhere, the client would still need to use a boot floppy to load the kernel so that it can ask the nework for the ks.cfg file. Since we have to use a boot floppy anyway, we figured it would be alot easier to just put the ks.cfg file on the floppy and not worry about changing the BOOTP/DHCP servers at all. As of RedHat Linux 7.0 there is now support for booting over the network using PXIE. However many of our systems don't support PXIE so we decided to still stay with the floppy bootdisk method.

( Go to top )

The Bootdisk
The Bootdisk accomplishes several things. It contains the Linux kernel which is booted so that it can run the KickStart process. It also contains a configuration files that is used to tell KickStart what to do. By default the "Redhat" bootdisk will do a regular interactive install. If at the boot prompt you specify: linux ks=floppy the installer will switch into KickStart mode and install linux using the configuration recorded in the ks.cfg file on the floppy. To simplify the creation of the boot disk a cgi was put together so that it would ask the user the pertinent questions, then create the ks.cfg file for them, and then create a batch/shell script that can be used to create the boot floppy. Specifically, the batch file or shell script will create a basic boot floppy and then copy across 3 files. They are: syslinux.cfg, boot.msg, and the ks.cfg.

is the file that is read before the kernel loads. It is similar in functionality to lilo.conf. We have modified syslinux.cfg so that it runs linux ks=floppy by default if you press enter at the boot prompt. If you want to do a regular interactive install using the floppy then you can just type linux at the boot prompt. boot.msg contains the text that is displayed at the boot prompt. ks.cfg is the KickStart configuration file.
syslinux.cfg

The kernel that is on the standard bootnet.img bootdisk image has been designed to work specifically for desktop PC's. It will not work with notebooks that require PCMCIA services in order to get onto the network. for that you need to use pcmcia.img. The various bootdisk images can be found the images directory on the RedHat installation CD.
( Go to top )

The KickStart Server


Once the bootdisk lauches the kernel, it looks in the ks.cfg file to figure out where it is going to get it's root file system. This is specified in the NFS line in ks.cfg. For example, here is the default nfs

line:
nfs --server KickStart.cisco.com --dir /export/ftp/pub/linux/redhat/linux/7.0/en/os/i386

It specify's the NFS server as well as the NFS export to be mounted from that server. The directory /export/ftp/pub/linux/redhat/linux/7.0/en/os/i386 contains the following files and directories.
COPYING README RELEASE-NOTES RPM-GPG-KEY RedHat/ autorun* boot.cat* doc/ dosutils/ images/ ls-lR.gz misc/

The only one that has to exist is the RedHat directory. Here is what is inside the RedHat directory and what each directory is for.
RPMS/ base/ i386 architecture. instimage/ system during Location of the RPMS that get installed during KickStart. Location of RPMS database and comps file. File used to identify this directory is for the i386 Location of the files that get mounted as the root file KickStart.

The above layout is taken from what you would see on a RedHat Linux 6.2 CD. Starting with Redhat Linux 7.1 there is no longer an instimage directory. The instimage directory is now located in a file which is kept in the base directory. The NFS server must be exported to the world so that KickStarts that are using DHCP address's (and therefore are not in the netgroup file) will be able to mount the share point. That is only if you are using netgroups to restrict access.

Postinstall
The end of the ks.cfg file contains a %post section. This is where the postinstall commands are kept. If we put all the postinstall commands here, the ks.cfg file would become rather large and

might not fit on the floppy disk anymore. So instead we install an RPM during the KickStart and in the %post section of the ks.cfg file we run a script in the RPM and pass it various options. The RPM is called postinstall and contains all the various things we want done during the postinstall. The last thing that the postinstall script does is removes the postinstall package.

Making better use of kickstart


Being able to do kickstarts is OK, but there are a few problems. 1. You may not want all the RPMS that RedHat provides 2. You may want to add your own RPMS. 3. If you list all the specific rpms you want in the %packages section of the ks.cfg then the ks.cfg file won't fit on boot floppy. 4. If you put complex postinstall commands in the ks.cfg file then the file might not fit on the boot floppy. 5. There are updates available for some packages. You don't won't to install old ones that would then need to be upgraded. So, what if you could choose exactly the RPM's that were available for Kickstart? What if you could choose the grouping of RPM's? What if you could pull out old RPM's and replace them with newer versions? Well, all of this is possible if you know how the inside of kickstart works and how to edit the files that kickstart uses. To make that much easier we have created some tools that do all of that for you. Let me explain a few things about how the inside of kickstart works so that you understand what these new tools are doing for you. The first thing you may want to do is replace some RPM's from the RPMS directory with your own versions or updated versions or whatever. So you cd into the RPMS directory that is described above. You remove a few RPM's and add a few. If you tried to Kickstart now, it would fail because Kickstart knows exactly which RPM's are in the RPMS directory and expects specific versions of RPM's to be there. It keeps track of all the RPM headers for each RPM in a file called hdlist in the base directory. Therefore, you need to generate a new hdlist. This is done by running a command that comes with anaconda-runtime called genhdlist . You also need to edit the comps file. The comps file is the file that lists all the packages that should get installed based on a particular profile. For example, when you do an interactive install and select Networked Workstation, that is a package group listed in the comps file. If you want to create your own package groups or make some new packages part of an existing package group then

you would list those packages in the comps file. The comps file is located in the base directory. One thing to note about this file is that the package names listed in it do not include the version number. This means that you could not use this file as an authorative list of packages installed by kickstart since you would only know the package name and not the package version. Now that you understand the basics of how to make changes to kickstart, you can forget it. Build_ks takes care of building the installer based on a configuration file that list all the rpms and what groups they should be in. It takes care of putting the correct RPM's in the RPMS directory. In also creates a new comps file and hdlist. What you need to do now is find out how to define a distribution .

You might also like