(/newsletter.

html) Advertiser
(https://mobile.linuxtoday.com) Disclosure

 
Advertisement

Complete Kickstart: How to Save Time Installing Linux

Thursday May 9th 2019 by David Both

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 it's a lab,
developers and testers require frequent re-installations of these systems to return them to a known
state. We also need to install operating systems on new boxes fairly often.

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 it's a lab, developers and testers require frequent re-installations of these systems
to return them to a known state. We also need to install operating systems on new boxes fairly often.
Advertisement

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 menu-driven 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.
Here's 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
 (/newsletter.html)
systems can be kickstarted simultaneously in about an hour with a very modest Pentium 4, a single IDE hard drive,Advertiser
and a 100Mb
connection. (https://mobile.linuxtoday.com) Disclosure

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 post-installation  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.
 (/newsletter.html) Advertiser
(https://mobile.linuxtoday.com)
####################################################################### Disclosure
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 ems-lnc100.cisco.com ;}
host ems-lnx118.cisco.com
{ hardware ethernet 00:04:23:B7:9A:15 ; fixed-address ems-lnx118.cisco.com ;}
host ems-lnx145.cisco.com
{ hardware ethernet 00:04:23:B5:6B:A9 ; fixed-address ems-lnx145.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 next-server 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 .
 (/newsletter.html) Advertiser
(https://mobile.linuxtoday.com)
####################################################################### Disclosure
# default: off
service tftp
{
disable = no
socket_type = dgram
protocol = udp
wait = yes
user = root
server = /usr/sbin/in.tftpd
server_args = -s -c -v -v -v /opt/tftpboot
per_source = 11
cps = 100 2
flags = 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.

You'll 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:

 (/newsletter.html) Advertiser
(https://mobile.linuxtoday.com)
####################################################################### Disclosure

# 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.
 (/newsletter.html) Advertiser
(https://mobile.linuxtoday.com)
####################################################################### Disclosure

09Welcome to 0cThe Cisco Linux09 Installer!07

0a
| |
. | | | . | | | .
' '
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

You'll 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

You'll 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.

 (/newsletter.html) Advertiser
(https://mobile.linuxtoday.com)
/var/ftp/pub/rhel/5.1/isos/i386/ Disclosure
/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 self-explanatory, 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.
 (/newsletter.html) Advertiser
(https://mobile.linuxtoday.com)
####################################################################### Disclosure
# 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 /opt --fstype ext3 --size=10000 --grow
part /usr --fstype ext3 --size=10000
part /tmp --fstype ext3 --size=7500
part /var --fstype ext3 --size=7500
part /home --fstype ext3 --size=2500
part swap --size=2048
part / --fstype ext3 --size=2048
part /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.
 (/newsletter.html) Advertiser
(https://mobile.linuxtoday.com)
####################################################################### Disclosure
%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
chroot'ed 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.
 (/newsletter.html) Advertiser
(https://mobile.linuxtoday.com)
####################################################################### Disclosure
%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+kdahxfJvWATaJweVFjRdHrIZxPB4nlO+MEBb
cPmUP7cLLQ1KGbfUakr35qzb9RjpBPDcBSDW2GZRAAAAFQCD/qw8FCSfEyWAmtkXDioJBWUCOwAAAIAm
4czfxx+Srm7FxGDTsiL52ojKzZCzddTi6YclknBXYpa3jhjhDfgkbGfHc746cVXm3hJ9ZgA3RQpMypKn
WS6EHimjkjEeqfw/viqPR1NCvj1xVs9XDjRtCelwsxUNj31Y2RHCsusa6DDwG765bnlk/BO4lUGRQpNy
QAAjKyDhPwAAAIAPJQcSf0tc4OrqNxy/gjkhkhgghfTRerthkljhGuyKarrmWan9ZkkFJQYnp09GNasZ
zI7Zwau3oqfutPTWJFehBskFKvRpSjYd59vKjWpDyCE5xHYxZfDORTj4pzjRSyiXDP/viA5DBCUWieM4
zGWa1RKVdskjPFS56y5GAkEwcA== root@emsjumpsssh-dss AAAAB3NzaC1kc3MAAACBAOqZBr62GU
La+NwGUatvO7OVXqGDn4qXvR2GAUputz9uyYmcWTvoHG0D3eAQ2flqhpyhJQo63GyntUtmGkXIHFuM3z
4qDt19qcpFRj10ZzRbZGhf+QbJwkxA9fpOy/BmoYykW5l36Db/Dvlzk4zNgJAmGXb2rNv8RSqYC6kCZf
aNAAAAFQDTb8EsksyknY++4zXC3TPNrH/+MwAAAIEAz3OCUfZXo+e/lJ/KSFj1un378KGGo9qfGSpVMV
Tva/z58KAZ174tJpgnfA8+fQOwq/ip8s9UyHA2qR+BICjjZo1KatevFN7l4rpNSqdLivEasrGBu6fRTP
/kQ6vt+OLIAQyr8t9RqpZKUVdd9odFA9NLiuOhG//eh2cDSXmjFnkAAACAbgzdEMcCMeMT/XPJrkZ/md
TX/EJ6VNQEuTP3fhrjKKjccYobXPOQhvliIhPGFbtrRZlYRPPFAkAAse0qRPOsy8XHKD18WnQr5JNJx+
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
(/newsletter.html) Advertiser
(https://mobile.linuxtoday.com)
system monitored and recorded by system personnel. In the course Disclosure

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

You'll 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. Add the computer to DNS.
2. Add the appropriate information to the dchpd.conf file.
3. Boot the computer.
4. 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.

Previous Article Next Article

(/blog/multiplexed-i0-with-poll.html)Multiplexed I/0 with poll... (/blog/command-line-audio-simple-as-
(/blog/multiplexed-i0-with-poll.html) mpg123.html)Command Line Audio: Simpl...
(/blog/command-line-audio-simple-as-
mpg123.html)

Home (/)
Mobile Site | Full Site

An eWEEK Property

Copyright 2019 QuinStreet Inc. All Rights Reserved.

Advertiser Disclosure: Some of the products that appear on this(/newsletter.html)
site are from companies from which QuinStreet receives
Advertiser
compensation. This
(https://mobile.linuxtoday.com)
compensation may impact Disclosure
how and where products appear on this site including, for example, the order in which they appear. QuinStreet does not
include all companies or all types of products available in the marketplace.