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. A Web server and/or FTP Server for delivery of the RPMs that are to be installed.
- 1. A DHCP server for IP address assignments and to launch PXE Boot.
- 1. A TFTP server for download of PXE Boot components to the machines being kickstarted.
- 1. An PXE Boot capable network card.
- 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 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.
#######################################################################
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.
#######################################################################
# 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:
#######################################################################
# 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. Theappend 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.
#######################################################################
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.
/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 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.
#######################################################################
# 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.
#######################################################################
%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.
#######################################################################
%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
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
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.
- 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.
