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.
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:
- A Web server
and/or FTP Server for delivery of the RPMs that are to be installed.
- A DHCP server
for IP address assignments and to launch PXE Boot.
- A TFTP server
for download of PXE Boot components to the machines being kickstarted.
- An PXE Boot
capable network card.
- 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 "linuxhowto.in";
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.linuxhowto.in
{ hardware ethernet 00:15:17:1D:42:88 ;
fixed-address ems-lnc100.linuxhowto.in ;}
host
ems-lnx118.linuxhowto.in
{ hardware ethernet 00:04:23:B7:9A:15 ;
fixed-address ems-lnx118.linuxhowto.in ;}
host
ems-lnx145.linuxhowto.in
{ hardware ethernet 00:04:23:B5:6B:A9 ;
fixed-address ems-lnx145.linuxhowto.in ;}
}
#######################################################################
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
}
#######################################################################
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.linuxhowto.in/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.linuxhowto.in/pub/kickstart/rhel-AP-Min-ks.cfg
#######################################################################
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.
#######################################################################
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
#######################################################################
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
#######################################################################
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.linuxhowto.in/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.linuxhowto.in/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.linuxhowto.in/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 The Network Installation
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.
You can do some basic troubleshooting
by accessing the various installation status screens available.
- The installation logs can always be viewed by
hitting <CTRL-ALT-F3>
- Kernel messages can be seen by hitting
<CTRL-ALT-F4>
- Access to a limited BASH shell Kernel can be gained
by hitting <CTRL-ALT-F2>
- You can return to the main installation screen at
any time by hitting <CTRL-ALT-F1> for text based installations and
<CTRL-ALT-F7> when the GUI is used.
- Examine your server's
<code>/var/log/httpd/access_log, /var/log/httpd/error_log files for the HTTP method; the /var/log/vsftpd.log file for the FTP method; and your
/var/log/messages file for the
NFS method.
Note that this document comes without warranty of any kind. But
every effort has been made to provide the information as accurate as possible.
I welcome emails from any readers with comments, suggestions, and corrections
at webmaster_at admin@linuxhowto.in
Copyright © 2012 LINUXHOWTO.IN
Copyright © 2012 LINUXHOWTO.IN
Do I need a boot-able CD/DVD at client side for booting the client machine to use Kick-start method?
ReplyDeleteNo it is not mandatory to use CD / DVD for the kick start method. You can PXE Boot the server (Network Boot) and have your DHCP Server automatically tell the kick start client about the name of the kickstart file to use when it assigns the IP address.
DeleteWhat are the requirements/configuration required for PXE boot? How we can configure a client machine for PXE boot?
ReplyDeleteNice post...I look forward to reading more, and getting a more active part in the talks here, whilst picking up some knowledge as well..
ReplyDelete