Sets up the authentication options for the system. It's similar
to the authconfig command that can be run after
the install. By default, passwords are normally encrypted and are
not shadowed.
--enablemd5
Use md5 encryption for user passwords.
--enablenis
Turns on NIS support. By default,
--enablenis uses whatever domain it
finds on the network. A domain should almost always be set
by hand (via --nisdomain).
--nisdomain
NIS domain name to use for NIS services.
--nisserver
Server to use for NIS services (broadcasts by default).
--useshadow
Use shadow passwords.
--enableldap
Turns on LDAP support in
/etc/nsswitch.conf, allowing your
system to retrieve information about users (UIDs, home
directories, shells, etc.) from an LDAP directory. Use
of this option requires that the
nss_ldap package be installed. You
must also specify a server and a base DN.
--enableldapauth
Use LDAP as an authentication method. This enables the
pam_ldap module for authentication and password-changing
using an LDAP directory. Use of this option requires that the
nss_ldap package be installed. You must also specify a
server and a base DN.
--ldapserver=
The name of the LDAP server used if you use specified either --enableldap or
--enableldapauth. This option is set in the /etc/ldap.conf
file.
--ldapbasedn=
The DN (distinguished name) in your LDAP directory tree under which user
information is stored. This option is set in the
/etc/ldap.conf file.
--enablekrb5
Use Kerberos 5 for authenticating users. Kerberos itself has no notion of home
directories, UIDs, or shells, so if you enable Kerberos you'll still need to
enable LDAP, NIS, or Hesiod if you want to avoid having to use the
/usr/sbin/useradd command to make their accounts known to
this workstation. Use of this option requires the pam_krb5
package to be installed.
--krb5realm
The Kerberos 5 realm your workstation belongs to.
--krb5kdc
The 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, which can only
be run on the master KDC if you have more than one, handles password- changing
and other administrative requests.
--enablehesiod
Enable 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 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. This option is used by the Hesiod
library 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. This option is used by the Hesiod
library to determine the name to search DNS for when looking up information,
similar to LDAP's use of a base DN.
Tip
To look up user information for
"jim", the Hesiod library looks up
jim.passwd<LHS><RHS>,
which should resolve to a TXT record that looks like what
his passwd entry would look like
(jim:*:501:501:Jungle
Jim:/home/jim:/bin/bash). For groups,
the situation is identical, except
jim.group<LHS><RHS> would
be used.
Looking up users and groups by number is handled by making "501.uid" a CNAME for
"jim.passwd", and "501.gid" a CNAME for "jim.group". Note that the LHS and RHS
do not have periods . put in front of them when the library
determines the name to search for, so the LHS and RHS most often begin with
periods.
On most PCI systems, the installation program will autoprobe for
Ethernet and SCSI cards properly. On older systems, and some PCI
systems, kickstart needs a hint to find the proper devices,
however. The device command tells
Anaconda to install extra modules. It
is of the form:
device <type><moduleName> --opts <options>
<type> should be one of
"scsi" or "eth", and <moduleName>
is the name of the kernel module which should be installed.
--opts
Options to pass to the kernel module. Note that multiple
options may be passed if put in quotes. For example:
During kickstart, driver disks can be used by copying the contents
of a driver disk to the root directory of a partition on the
system's hard drive and using the driverdisk
command to tell the installation program where to look for it.
driverdisk <partition> [--type <fstype>]
<partition> is the partition
containing the driver disk.
Sets the default language for the installed system. The language
you specify will be used during the installation as well as to
configure any language-specific aspect of the installed system.
For example, to set the language to English, the kickstart file
should contain the following line:
Specifies how the boot loader should 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 will boot if the user types
dos at the
LILO: prompt).
--append<params>
Specifies kernel parameters.
--linear
Use the linear LILO option; this is
only for backwards compatibility (and linear is now used by
default).
--location
Specifies where the LILO boot record is written. Valid
values are mbr (default),
partition (installs the boot loader
on the first sector of the partition containing the
kernel), or none, which prevents any bootloader from being
installed.
If this is present, the installation program checks for LILO on
the MBR of the first hard drive, and reboots the system if it is
found -- No installation is done in this case. This can prevent
the kickstart from reinstalling an already installed system.
If the mouse command is given without any arguments, or it
is omitted, the installation program will attempt to autodetect the
mouse (which works for most modern mice).
Configures network information for the system. If it is not given,
and the kickstart installation does not require networking (in other
words, it's not installed over NFS), networking is not configured
for the system. If the installation does require networking,
Anaconda assumes that the install
should be done over eth0 via a dynamic IP address (BOOTP/DHCP),
and configures the final, installed system to dynamically determine its IP
address. The network command configures the networking information
for the installation for network kickstarts as well as for the
final, installed system.
--bootproto
One of dhcp,
bootp, or
static (defaults to DHCP, and
dhcp and
bootp are treated the same). Must
be static for static IP information
to be used.
--device<device>
Used to select a specific ethernet device for
installation. Note, using --device<device> will not be
effective unless the kickstart file is a local file (such
as ks=floppy), since the installation program will
configure the network to find the kickstart file. Example:
network --bootproto dhcp --device eth0
--ip
IP address for machine to be installed.
--gateway
Default gateway as an IP address.
--nameserver
Primary name server, 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. As you might guess, 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 will be used during the
installation, and after the installation as well.
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, as you must
include all network configuration information on one line. You'll
need to specify:
The <mntpoint> is where the partition
will be mounted, and must be of one of the following forms:
/<mntpoint>
(i.e. /,
/usr, /home)
swap
The partition will be used as swap space.
raid.<id>
The partition will be used for software RAID (see the
raid command later).
--size <size>
Sets the minimum size for the partition
--grow
Tells the partition to grow to fill available space (if
any), or up to maximum size setting.
--maxsize <size>
Sets the maximum partition size when the partition is set to grow.
--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 will put
/home on
/dev/hda1, which must already exist.
--ondisk <disk>
Forces the partition to be created on a particular disk.
For example, --ondisk sdb will put the
partition on the second disk on the system.
--onprimary <N>
Forces the partition to be created on primary partition
<N> or fail.
<N> can be 1 through 4.
--asprimary <N>
Forces auto allocation as a primary partition
<N> or
fail. <N> can be 1
through 4.
--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>
Sets partition type to
<X>, where
<X> is a numerical value.
All partitions created will be formatted as part of the
installation process unless --noformat and
--onpart are used.
Please Note
If --clearpart is used in the
ks.cfg file, then --onpart
cannot be used on a logical partition.
Please Note
If partitioning fails for any reason, diagnostic messages will appear on VC 3.
The <mntpoint> is the location to
mount the RAID filesystem. If it is /, the
RAID level must be 1 unless a boot partition
(/boot) is present in which the
/boot partition has to 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 m1). RAID
devices range from md0 to md7, and each may only be used
once.
Here's an example of how to create a RAID level 1 partition for
/, and a RAID level 5 for
/usr, assuming 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
Reboot after the installation is complete (no arguments). Normally,
kickstart displays a message and waits for the user to press a key
before rebooting.
Configures the X Window System. If this option is not given,
the user will need to configure X manually during the
installation, if X was installed; this option should not be used if X is
not installed on the final system.
--noprobe
Don't probe the monitor.
--card <card>
Use card <card>; this
card name should be from the list of cards in
Xconfigurator. If this argument
is not provided, Anaconda will
probe the PCI bus for the card.
--monitor <mon>
Use monitor <mon>; this
monitor name should be from the list of monitors in
Xconfigurator. This is ignored
if --hsync or
--vsync is provided; if no monitor
information is provided, the monitor is probed via
plug-and-play.
--hsync <sync>
Specifies the horizontal sync frequency of the monitor.
--vsync <sync>
Specifies the vertical sync frequency of the
monitor.
--defaultdesktop=(GNOME or
KDE)
Sets the default desktop to either GNOME or KDE (and
assumes that GNOME and/or KDE has been installed through
%packages).
--startxonboot
Use a graphical login (runlevel 5) for the
installed system.
If "zerombr" is specified, and "yes" is its sole argument, any
invalid partition tables found on disks are initialized. This
will destroy all of the contents of disks with invalid partition
tables. This command should be used as:
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
then 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, there are three other types of lines in the
comps file you may run across:
Architecture specific (alpha:, i386:, 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: netscape-common you only need to
use the netscape-common part for that
specific package to be installed.
Lines beginning with ?
Lines that begin with a ?, are specific to
the installation program. You do not have to do anything with
these type of lines.
Lines beginning with --hide
If a package name begins with --hide, you
only need to type in the package name, minus the
--hide. For example:
For --hide KDE Workstation you only need to
use the KDE Workstation part for that
specific package to be installed.
In most cases, it's only necessary to list the desired components and
not individual packages. Note that the Base
component is always selected by default, so it's not necessary to
specify it in the %packages section.
Here's an example %packages selection:
%packages
@ Networked Workstation
@ C Development
@ Web Server
@ X Window System
bsd-games
As you can see, components are specified, one to a line, starting with
an @ symbol, a space, and then the full component
name as given in the comps file. Specify
individual packages with no additional characters (the
bsd-games line in the example above is an
individual package).
Please Note
You can also direct the kickstart installation to use the workstation-
and server-class installations (or choose an everything installation
to install all packages). To do this, simply add
one of the following lines to the
%packages section:
@ Gnome Workstation
@ KDE Workstation
@ Server
@ Everything
You have the option of adding 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. Note, you can access
the network in the %pre section; however,
name service has not been configured at this
point, so only IP addresses will work. Here's an example
%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 containing the date the
kickstart installation took place, and gets around the
network command's "one name server only" limitation by
adding another name server to /etc/resolv.conf.
Please Note
Note that the pre-install script is not run in the change root
enviroment.
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.
Note, you can access the network in the %post
section; however, name service has not been
configured at this point, so only IP addresses will work. Here's an
example %post section:
%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
This section creates a message-of-the-day file containing the date the
kickstart installation took place, and gets around the
network command's "one name server only" limitation by
adding another name server to /etc/resolv.conf.
Please Note
Note that the post-install script is run in a chroot'ed environment;
therefore performing tasks such as copying scripts or RPMs from the
installation media will not work.
--nochroot
Allows you to specify commands that you would like to run outside
of the chroot'ed environment.
--interpreter /usr/bin/perl
Allows you to specify a different scripting language, such as
perl.
Download
