Any decent cluster installation of any size can be done automatically to save time and effort. With just a few guidelines, you can make a kickstart install of your Red Hat Linux box to populate any number of machines quickly and easily. The good thing is that with minimal pre-planning, you can install all your Red Hat servers from a floppy. Install the floppy, turn on the box, come back about an hour later, and you’ve got a fully installed server ready to put into production. And it’s not an image, but a freshly installed machine. If you plan it right, you can even keep your installs up to date with the proper patches.
In fact, with a little planning, a kickstart plan can be a decent part of your disaster recovery solution, as long as you’ve got a kickstart server lying around. A kickstart server with a decent network can jump quite a few boxes at once.
These guidelines have been reprinted, and modified for this printing, from www.redhat.com/docs/manuals/linux/RHL-7.2-Manual/custom-guide/s1-kickstart2-options.html for quick reference.
autostep
is similar to interactive
except that it goes to the next screen for you. You use autostep
mostly for debugging.
auth
or authconfig
(required)—. Sets up the authentication options for the system. It’s similar to the authconfig
command, which can be run after the install. By default, passwords are normally encrypted and are not shadowed.
––enablemd5—
. Uses md5 encryption for user passwords.
––enablenis—
. Turns on Network Information Service (NIS) support. By default, ––enablenis
uses whatever domain it finds on the network. A domain is almost always set by hand (through ––nisdomain
).
––nisdomain—
. NIS domain name to use for NIS services.
––nisserver—
. Server to use for NIS services (broadcasts by default).
––useshadow
or ––enableshadow—
. Uses shadow passwords.
––enableldap—
. Turns on Lightweight Directory Access Protocol (LDAP) support in /etc/nsswitch.conf
, which allows your system to retrieve information about users (unique user identifiers (UIDs), home directories, shells, and so on) from an LDAP directory. To use this option, you must have the nss_ldap
package installed. You must also specify a server and a base distinguished name (DN).
––enableldapauth—
. Uses LDAP as an authentication method. This enables the pam_ldap
module for authentication and changing passwords by using an LDAP directory. To use this option, you must have the nss_ldap
package installed. You must also specify a server and a base DN.
––ldapserver=—
. If you specified either ––enableldap or ––enableldapauth, as the name of the LDAP server to use. This option is set in the /etc/ldap.conf
file.
––ldapbasedn=—
. The DN in your LDAP directory tree under which user information is stored. This option is set in the /etc/ldap.conf
file.
––enableldaptls—
. Uses Transport Layer Security (TLS) lookups. This option allows LDAP to send encrypted usernames and passwords to an LDAP server before authentication.
––enablekrb5—
. Uses Kerberos 5 for authenticating users. Kerberos itself does not know about home directories, UIDs, or shells. If you enable Kerberos you need to make users’ accounts known to this workstation by enabling LDAP, NIS, or Hesiod, or by using the /usr/sbin/useradd
command. If you use this option, you must have the pam_krb5
package installed.
––krb5realm—
. The Kerberos 5 realm to which your workstation belongs.
––krb5kdc—
. The key distribution center (KDC or KDCs) that serve requests for the realm. If you have multiple KDCs in your realm, separate their names with commas (,).
––krb5adminserver—
. The KDC in your realm that is also running kadmind
. This server handles password changing and other administrative requests. This server must be run on the master KDC if you have more than one KDC.
––enablehesiod—
. Enables Hesiod support for looking up user home directories, UIDs, and shells. More information on setting up and using Hesiod on your network is in /usr/share/doc/glibc-2.x.x/README.hesiod
, which is included in the glibc
package. Hesiod is an extension of the Domain Name System (DNS) that uses DNS records to store information about users, groups, and various other items.
––hesiodlhs—
. The Hesiod LHS (left-hand side) option, set in /etc/hesiod.conf
. The Hesiod library uses this option to determine the name to search DNS for when looking up information, similar to LDAP’s use of a base DN.
––hesiodrhs—
. The Hesiod RHS (right-hand side) option, set in /etc/hesiod.conf
. The Hesiod library uses this option to determine the name to search the DNS for when looking up information, similar to LDAP’s use of a base DN.
––enablesmbauth—
. Enables authentication of users against a Server Message Block (SMB) server (typically a Samba or Windows server). SMB authentication support does not know about home directories, UIDs, or shells. If you enable it you need to make users’ accounts known to the workstation by enabling LDAP, NIS, or Hesiod, or by using the /usr/sbin/useradd
command. To use this option, you must have the pam_smb
package installed.
––smbservers=—
. The name of the server(s) to use for SMB authentication. To specify more than one server, separate the names with commas (,).
––smbworkgroup=—
. The name of the workgroup for the SMB servers.
––enablecache—
. Enables the name service cache daemon (NSCD) service. The NSCD service caches information about users, groups, and various other types of information. Caching is especially helpful if you choose to distribute information about users and groups over your network using NIS, LDAP, or hesiod.
bootloader
(required)—. Specifies how the boot loader is installed and whether the bootloader is the Linux Loader (LILO) or Grand Unified Bootloader (GRUB).
––append
—. Specifies kernel parameters.
––location=
—. Specifies where the boot record is written. Valid values are the following: mbr
(the default), partition
(installs the bootloader on the first sector of the partition containing the kernel), or none
(does not install the boot loader).
––password=
mypassword
—. If using GRUB, sets the GRUB bootloader password to mypassword
. You use this to restrict access to the GRUB shell where arbitrary kernel options can be passed.
––md5pass=
mypassword
—. If using GRUB, similar to ––password
except that mypassword
is the password already encrypted.
––useLilo
—. Uses LILO instead of GRUB as the bootloader.
––linear
—. If using LILO, uses the linear LILO
option; this is only for backwards compatibility (linear is now the default).
––nolinear
—. If using LILO, uses the nolinear LILO
option (linear is now the default).
––lba32
—. If using LILO, forces use of lba32
mode instead of autodetecting
.
clearpart
(optional)—. Removes partitions from the system prior to the creation of new partitions. By default, no partitions are removed.
––linux
—. Erases all Linux partitions.
––all
—. Erases all partitions from the system.
––drives
—. Specifies which drives to clear partitions from.
––initlabel
—. Initializes the disk label to the default for your architecture (msdos for x86 and gpt for Itanium). The installation program does not ask if it should initialize the disk label if installing to a brand new hard drive.
device
(optional)—. On most PCI systems, the installation program properly autoprobes for Ethernet and SCSI cards. On older systems and some PCI systems, kickstart needs a hint to find the proper devices. The device command, which tells Anaconda to install extra modules, is in the following format:
device <type> <moduleName> ––opts <options>
<type> is either “scsi” or “eth”, and <moduleName> is the name of the kernel module that is to be installed.
––opts
—. Options to pass to the kernel module. Multiple options can be passed if they are put in quotes, as in the following example:
––opts "aic152x=0x340 io=11"
deviceprobe
(optional)—. Forces a probe of the PCI bus and loads modules for the devices found, if a module is available.
driverdisk
(optional)—. Driver disks can be used during kickstart installations. You need to copy the driver disk’s contents to the root directory of a partition on the system’s hard drive. Then you need to use the driverdisk
command to tell the installation program where to look for the driver disk.
driverdisk <partition> [––type <fstype>]
<partition>
is the partition that contains the driver disk.
––type
Filesystem type (for example, vfat, ext2, or ext3).
firewall
(optional)—. Firewall options can be configured in kickstart. This configuration corresponds to the Firewall Configuration screen in the installation program:
firewall [––high | ––medium | ––disabled] [––trust <device>] [––dhcp] [––ssh] [––telnet] [––smtp] [––http] [––ftp] [––port <portspec>]
Choose one of the following levels of security:
––high
––medium
––disabled
––trust
<device>
Listing a device here, such as eth0, allows all traffic coming from that device to go through the firewall. To list more than one device, use ––trust eth0 ––trust
eth1
. Do not use a comma-separated format such as ––trust eth0, eth1
.
Allow incoming—
. Enabling these options allows the specified services to pass through the firewall:
––dhcp
––ssh
––telnet
––smtp
––http
––ftp
––port
<portspec>
You can specify that ports be allowed through the firewall by using the port:protocol
format. For example, if you want to allow IMAP access through your firewall, you can specify imap:tcp
. You can also specify numeric ports explicitly; for example, to allow UDP packets on port 1234 through, specify 1234:udp
. To specify multiple ports, separate them by commas.
install
(optional) —. Tells the system to install a fresh system rather than upgrade an existing system. This is the default mode.
You must use one of these commands to specify what type of kickstart installation is being performed:
nfs
—. Installs from the Network File System (NFS) server specified.
––server
<server>—
. Server from which to install (hostname or IP).
––dir
<dir>
—. Directory that contains the Red Hat installation tree.
For example:
nfs ––server <server> ––dir <dir>
harddrive
—. Installs from a Red Hat installation tree on a local drive, which must be either vfat
or ext2
.
––partition
<partition>
—. Partition to install from (such as sdb2
).
––dir
<dir>
—. Directory containing the Red Hat installation tree.
For example:
harddrive ––partition <partition> ––dir <dir>
url
—. Installs from a Red Hat installation tree on a remote server through File Transfer Protocol (FTP) or Hypertext Transfer Protocol (HTTP).
For example:
url ––url http://<server>/<dir> url ––url ftp://<username>:<password>@<server>/<dir>
This optional command uses the information provided in the kickstart file during the installation, but allows for inspection and modification of the values given. You are presented with each screen of the installation program with the values from the kickstart file. You either accept the values by clicking Next or change the values and click Next to continue. See also the autostep section.
keyboard
(required) —. Sets the system keyboard type. The list of available
keyboards on i386 and Alpha machines is as follows:
ANSI-dvorak, azerty, be-latin1, be2-latin1, bg, br-abnt2, cf, croat, cz, cz-lat2, cz-lat2-prog, cz-us-qwertz, de, de-latin1, de-latin1-nodeadkeys, defkeymap, defkeymap_V1.0, dk, dk-latin1, dvorak, dvorak-l, dvorak-r, emacs, emacs2, es, es-cp850, et, et-nodeadkeys, fi, fi-latin1, fr, fr-latin0, fr-latin1, fr-pc, fr_CH, fr_CH-latin1, gr, gr-pc, hebrew, hu, hu101, is-latin1, it, it-ibm, it2, jp106, la-latin1, lt, lt.l4, lv-latin4, lv-latin7,mk, nl, nl-latin1, nl-latin1-nodeadkeys, no, no-latin1, pc-dvorak-latin1, pc110, pl, pl1, pt-latin1, pt-old, ro, ru, ru-cp1251, ru-ms, ru-yawerty, ru1, ru2, ru3, ru4, ru_win, se-latin1, sg, sg-latin1, sg-latin1-lk450, sk-prog, sk-prog-qwerty, sk-prog-qwerty, sk-qwerty, sk-qwertz, slovene, sr, sr, tr_f-latin5, tr_q-latin5, tralt, trf, trq, ua, ua-utf, ua-utf-ws, ua-ws, uaw, uaw_uni, uk, us, us-latin1, wangbe
The list for SPARC machines is as follows:
sun-pl-altgraph, sun-pl, sundvorak, sunkeymap, sunt4-es, sunt4-no-latin1, sunt5-cz-us, sunt5-de-latin1, sunt5-es, sunt5-fi-latin1, sunt5-fr-latin1, sunt5-ru, sunt5-uk, sunt5-us-cz
lang
(required)—. Sets the language to use during installation. For example, to set the language to English, the kickstart file must contain the following line:
lang en_US
—. Valid language codes are the following (please note that these are subject to change at any time):
cs_CZ, da_DK, en_US, fr_FR, de_DE, hu_HU, is_IS, it_IT, ja_JP.eucJP, no_NO, ro_RO, sk_SK, sl_SI, sr_YU, es_ES, ru_RU.KOI8-R, uk_UA.KOI8-U, sv_SE, tr_TR
langsupport
(required)—. Sets the language(s) to install on the system. The same language codes that you use with lang
can be used with langsupport
.
––default
—. Sets the default language to use for any language-specific aspect of the installed system.
The following example installs English and French and uses English as the default language:
langsupport ––default en_US fr_FR
lilo
(replaced by bootloader
)—. This option has been replaced by bootloader
and is only available for backwards compatibility. Refer to the bootloader section.
Specifies how the bootloader is to be installed on the system. By default, LILO installs on the MBR of the first disk, and installs a dual-boot system if a DOS partition is found (the DOS/Windows system boots if the user types dos
at the LILO:
prompt).
––append
<params>
—. Specifies kernel parameters.
––linear
—. Uses the linear LILO
option; this is only for backwards compatibility (linear
is the default).
––nolinear
—. Uses the nolinear LILO
option (linear
is now the default).
––location
—. Specifies where the LILO boot record is written. Valid values are the following: mbr
(the default) or partition
(installs the boot loader on the first sector of the partition that contains the kernel). If no location is specified, LILO is not installed.
––lba32
—. Forces the use of lba32
mode instead of autodetecting
.
If lilocheck
is present, the installation program checks for LILO on the MBR of the first hard drive, and reboots the system if it is found. In this case, no installation is performed. This can prevent kickstart from reinstalling an already installed system.
mouse
(required)—. Configures the mouse for the system, both in GUI and text modes.
––device
<dev>
—. Device the mouse is on (such as ––device ttyS0
).
––emulthree
—. If present, simultaneous clicks of the left and right mouse buttons are recognized as the middle mouse button by the X Window System. You use this option if you have a two-button mouse.
After options, the mouse type can be specified as one of the following:
alpsps/2, ascii, asciips/2, atibm, generic, generic3
genericps/2, generic3ps/2, genericusb, generic3usb
geniusnm, geniusnmps/2,geniusprops/2, geniusscrollps/2
thinking, thinkingps/2, logitech, logitechcc, logibm
logimman, logimmanps/2, logimman+, logimman+ps/2
logimmusb, microsoft, msnew, msintelli, msintellips/2
msintelliusb, msbm, mousesystems, mmseries, mmhittab
sun, none
If the mouse
command is given without any arguments, or it is omitted, the installation program attempts to autodetect the mouse. This procedure works for most modern mice.
network
(optional)—. Configures network information for the system. If the kickstart installation does not require networking (if it is not installed over NFS, HTTP, or FTP), networking is not configured for the system. If the installation does require networking and network information is not provided in the kickstart file, the Red Hat Linux installation program assumes that the installation is to be done over eth0 through a dynamic IP address (Bootstrap Protocol/Dyamic Host Configuration Protocol (BOOTP/DHCP)), and configures the final, installed system to determine its IP address dynamically. The network
option configures networking information for kickstart installations through a network and for the installed system.
––bootproto
—. One of dhcp
, bootp
, or static
(defaults to DHCP, and dhcp
and bootp
are treated the same). Must be static to use static IP information.
––device
<device>
—. Selects a specific Ethernet device for installation. Using ––device
<device>
is not effective unless the kickstart file is a local file (such as ks=floppy
) because the installation program configures the network to find the kickstart file.
For example:
network ––bootproto dhcp ––device eth0
––ip
—. IP address for the machine to be installed.
––gateway
—. Default gateway as an IP address.
––nameserver
—. Primary nameserver, as an IP address.
––netmask
—. Netmask for the installed system.
––hostname
—. Hostname for the installed system.
There are three different methods of network configuration:
DHCP
BOOTP
Static
The DHCP method uses a DHCP server system to obtain its networking configuration. The BOOTP method is similar, requiring a BOOTP server to supply the networking configuration.
The static method requires that you enter all the required networking information in the kickstart file. As the name implies, this information is static, and you use it during and after the installation.
To direct a system to use DHCP to obtain its networking configuration, use the following line:
network ––bootproto dhcp
To direct a machine to use BOOTP to obtain its networking configuration, use the following line in the kickstart file:
network ––bootproto bootp
The line for static networking is more complex because you must include all the network configuration information on one line. You need to specify the following:
IP address
Netmask
Gateway IP address
Nameserver IP address
Following is an example of a static line:
network ––bootproto static ––ip 10.0.2.15 ––netmask 255.255.255.0 ––gateway 10.0.2.254 ––nameserver 10.0.2.1
If you use the static method, be aware of the following two restrictions:
All static networking configuration information must be specified on one line; you cannot wrap lines using a backslash.
You can only specify one nameserver. However, you can use the kickstart file’s %post
section (see the section, “%post: Post-Installation Configuration Section”) to add more name servers, if needed.
part
or partition
(required for installs, ignored for upgrades)—. Creates a partition on the system.
<mntpoint>
—. Where the partition is mounted, and must be in this form:
/<mntpoint>
For example:
, /, /usr, /home
swap
—. The partition is used as swap space.
raid.
<id>
—. The partition is used for software RAID (see the raid section).
––size
<size>
—. The minimum partition size in megabytes. Specify an integer value such as 500. Do not append the number with MB.
––grow
—. Tells the partition to grow to fill the available space (if any), or up to the maximum size setting.
––maxsize
<size>
—. The maximum partition size in megabytes when the partition is set to grow. Specify an integer value. Do not append the number with MB.
––noformat
—. Tells the installation program not to format the partition, for use with the ––onpart
command.
––onpart
<part>
or ––usepart
<part>
—. Tells the installation program to put the partition on the already existing
device
<part>
. For example, partition /home ––onpart hda1
puts /home
on /dev/hda1
, which must already exist.
––ondisk
<disk>
or ––ondrive
<drive>
—. Forces the partition to be created on a particular disk. For example, ––ondisk sdb
puts the partition on the second disk on the system.
––asprimary
—. Forces automatic allocation of the partition as a primary partition or the partitioning fails.
––bytes-per-inode=
<N>
—. <N>
represents the number of bytes per inode on
the filesystem when it is created. It must be given in decimal format. This option is useful for applications where you want to increase the number of inodes on the filesystem.
––type=
<X>
(replaced by fstype
)—. This option is no longer available. Use fstype
.
––fstype
—. Sets the filesystem type for the partition. Valid values are ext
2, ext3
, swap
, vfat
.
––start
—. Specifies the starting cylinder for the partition. It requires that a drive be specified with ––ondisk
or ondrive
. It also requires that the ending cylinder be specified with ––end
or the partition size be specified with ––size
.
––end
—. Specifies the ending cylinder for the partition. It requires that the starting cylinder be specified with ––start
.
––badblocks
—. Specifies that the partition should be checked for bad sectors.
All partitions created are formatted as part of the installation process unless you use ––noformat
and ––onpart
.
If you use ––clearpart
in the ks.cfg file, you cannot use ––onpart
on a logical partition. If partitioning fails for any reason, diagnostic messages appear on virtual console 3.
raid
(optional)—. Assembles a software RAID device. This command has the following form:
raid <mntpoint> ––level <level> ––device <mddevice><partitions*>
The <mntpoint>
is the location where the RAID filesystem is mounted. If it is /
, the RAID level must be 1 unless a boot partition (/boot
) is present. If a boot partition is present, the /boot
partition must be level 1 and the root (/
) partition can be any of the available types. The <partitions*>
(which denotes that multiple partitions can be listed) lists the RAID identifiers to add to the RAID array.
––level
<level>
—. RAID level to use (0, 1, or 5).
––device
<mddevice>
—. Name of the RAID device to use (such as md0 or md1). RAID devices range from md0 to md7, and each can only be used once.
––spares=
N
—. Specifies that there should be N
spare drives allocated for the RAID array. Spare drives rebuild the array in case of drive failure.
––fstype
—. Sets the filesystem type for the RAID array. Valid values are ext2
, ext3
, swap
, and vfat
.
––noformat
—. Does not format the RAID array.
The following example shows how to create a RAID level 1 partition for /
, and a RAID level 5 for /usr
, assuming that there are three SCSI disks on the system. It also creates three swap partitions, one on each drive:
part raid.01 ––size 60 ––ondisk sda part raid.02 ––size 60 ––ondisk sdb part raid.03 ––size 60 ––ondisk sdc part swap ––size 128 ––ondisk sda part swap ––size 128 ––ondisk sdb part swap ––size 128 ––ondisk sdc part raid.11 ––size 1 ––grow ––ondisk sda part raid.12 ––size 1 ––grow ––ondisk sdb part raid.13 ––size 1 ––grow ––ondisk sdc raid / ––level 1 ––device md0 raid.01 raid.02 raid.03 raid /usr ––level 5 ––device md1 raid.11 raid.12 raid.13
reboot
reboots after the installation is complete (no arguments). Normally, kickstart displays a message and waits for the user to press a key before rebooting.
rootpw [––iscrypted]
<password>
—. Sets the system’s root password to the <password>
argument.
––iscrypted
—. If this is present, the password argument is assumed to already be encrypted.
text
performs the kickstart installation in text mode. Kickstart installations are performed in graphical mode by default.
timezone [––utc]
<timezone>
—. Sets the system time zone to <timezone>
, which can be any of the time zones listed by timeconfig
.
––utc
—. If present, the system assumes that the hardware clock is set to UTC (Greenwich Mean) time.
upgrade
tells the system to upgrade an existing system rather than install a fresh system.
xconfig
(optional)—. Configures the X Window System. If this option is not given, the user needs to configure X manually during the installation, if X was installed; this option is not used if X is not installed on the final system.
––noprobe
—. Does not probe the monitor.
––card
<card>
—. Uses card <card>
; this card name is from the list of cards in Xconfigurator. If this argument is not provided, Anaconda probes the PCI bus for the card. Because AGP is part of the PCI bus, AGP cards are detected, if supported. The probe order is determined by the PCI scan order of the motherboard.
––videoram
<vram>
—. Specifies the amount of video RAM the video card has.
––monitor
<mon>
—. Uses monitor <mon>
; this monitor name is from the list of monitors in Xconfigurator. This is ignored if ––hsync
or ––vsync
is provided. If no monitor information is provided, the installation program tries to probe for it automatically.
––hsync
<sync>
—. Specifies the horizontal sync frequency of the monitor.
––vsync
<sync>
—. Specifies the vertical sync frequency of the monitor.
––defaultdesktop=GNOME
or ––defaultdesktop=KDE
—. Sets the default desktop to either GNOME
or KDE
(and assumes that GNOME or KDE has been installed through %packages
).
––startxonboot
—. Uses a graphical login on the installed system.
––resolution
<res>
—. Specifies the default resolution for the X Window System on the installed system. Valid values are 640×480, 800×600, 1024×768, 1152×864, 1280×1024, 1400×1050, and 1600×1200. Be sure to specify a resolution that is compatible with the video card and monitor.
––depth
<cdepth>
—. Specifies the default color depth for the X Window System on the installed system. Valid values are 8, 16, 24, and 32. Be sure to specify a color depth that is compatible with the video card and monitor.
zerombr
(optional)—. If zerombr
is specified, and yes
is its sole argument, any invalid partition tables found on disks are initialized. This destroys all the contents of disks with invalid partition tables.
zerombr yes
—. No other format is effective.
Use the %packages
command to begin a kickstart file section that lists the packages you’d like to install (this is for installations only, as package selection during upgrades is not supported).
Packages can be specified by component or by individual package name. The installation program defines several components that group together related packages. See the RedHat/base/comps
file on any Red Hat Linux CD-ROM for a list of components. The components are defined by the lines that begin with a number, followed by a space and the component name. Each package in that component is then listed, line-by-line. Individual packages lack the leading number found in front of component lines.
Additionally, three other types of lines are in the comps
file:
Architecture specific (i386:, ia64:, alpha:, and sparc64:)
If a package name begins with an architecture type, you only need to type in the package name, not the architecture name. For example: For i386: apmd
, you only need to use the apmd
part for that specific package to be installed.
Lines beginning with ?
—Lines that begin with a ?
are used by the installation program and must not be altered.
Lines beginning with ––hide
—If a package name begins with ––hide
,you only need to type in the package name, without the ––hide
. For ––hide
Network Server
, you only need to use the Network Server
part for that specific package to be installed.
In most cases, it’s only necessary to list the desired components and not individual packages. The base component is always selected by default, so it’s not necessary to specify it in the %packages
section.
The following is an example of a %packages
section:
%packages @ Network Managed Workstation @ Development @ Web Server @ X Window System xgammon
As you can see, components are specified, one to a line, starting with an @
symbol, a space, and the full component name (as given in the comps
file). Specify individual packages with no additional characters (the xgammon
line in the preceding example is an individual package).
You can also direct the kickstart installation to install the default packages for a workstation (KDE
or GNOME
) or server installation (or choose an everything installation to install all packages). To do this, simply add one of the following lines to the %packages
section:
@ GNOME
@ KDE
@ Server
@ Everything
You can add commands to run on the system immediately after the ks.cfg
has been parsed. This section must be at the end of the kickstart file (after the commands) and must start with the %pre
command. You can access the network in the %pre
section; however, name service
has not been configured at this point, so only IP addresses work. The following is an example of a %pre
section:
%pre # add comment to /etc/motd echo "Kickstart-installed Red Hat Linux `/bin/date`" > /etc/motd # add another nameserver echo "nameserver 10.10.0.2" >> /etc/resolv.conf
This section creates a message-of-the-day file that contains the date the kickstart installation took place. It also gets around the network command’s limitation of only one name server by adding another nameserver to /etc/resolv.conf
.
You have the option of adding commands to run on the system once the installation is complete. This section must be at the end of the kickstart file and must start with the %post
command.
If you configured the network with static IP information, including a nameserver, you can access the network and resolve IP addresses in the %post
section. If you configured the network for DHCP, the /etc/resolv.conf
file has not been completed when the installation executes the %post
section. You can access the network, but you cannot resolve IP addresses. Thus, if you are using DHCP, you must specify IP addresses in the %post
section.
Following is an example of a %post
section that creates a message-of-the-day file that contains the date that the kickstart installation took place, and gets around the network command’s limitation of one nameserver only by adding another nameserver to /etc/resolv.conf
:
%post # add comment to /etc/motd echo "Kickstart-installed Red Hat Linux `/bin/date`" > /etc/motd # add another nameserver echo "nameserver 10.10.0.2" >> /etc/resolv.conf
The post-install script is run in a chroot
environment; therefore, performing tasks, such as copying scripts or RPMs from the installation media, does not work.
––nochroot
—. Allows you to specify commands that you might like to run outside of the chroot
environment.
The following example copies the file /etc/resolv.conf
to the file system that was just installed:
%post ––nochroot cp /etc/resolv.conf /mnt/sysimage/etc/resolv.conf
––interpreter
/usr/bin/perl
—. Allows you to specify a different scripting language, such as Perl. (Replace /usr/bin/perl
with the scripting language of your choice.)
The following example uses a Perl script to replace /etc/HOSTNAME
:
%post ––interpreter /usr/bin/perl # replace /etc/HOSTNAME open(HN, ">HOSTNAME"); print HN "1.2.3.4 an.ip.address ";
These Kickstart options are republished under the Open Publication License (www.opencontent.org/openpub). All material referring to Kickstart is under copyright by Red Hat, Inc. Original authors: Red Hat, Inc. and Tammy Fox. Original Publisher: Red Hat Inc.
3.142.133.180