|Home||Switchboard||Unix Administration||Red Hat||TCP/IP Networks||Neoliberalism||Toxic Managers|
May the source be with you, but remember the KISS principle ;-)
Bigger doesn't imply better. Bigger often is a sign of obesity, of lost control, of overcomplexity, of cancerous cells
|News||Installation||Recommended Books||Recommended Links||Modifying ISO image to include kickstart file||Creating a boot image that is using a remote kickstart file to install Red Hat||Kickstart Pre- and Postinstall Scripts|
|Installation of Red Hat from a USB drive||Installing RHEL via HTTP||Minimization of boot ISO||Kickstart Cheatsheet||Installing via NFS||VNC-based Installation in Anaconda||Loopback filesystem|
|Minimization of boot ISO||Networking||Move config files from one server to another||Sysadmin Horror Stories||Humor||Etc|
Note: This page is based on RHEL documentation
Automated installation method is useful if you have similar machines and absolutely necessary if you have cluster. Major Unix flavors such as Solaris used to have jumpstart. To compete, Red Hat created the kickstart which is implemented differently, as a special interface to Anaconda installer. Kind of Anaconda scripting interface.
At the end of each installation Anaconda writes the file with selected installation parameters in /root/anaconda-ks.cfg.
|Anaconda creates a sample kickstart file based on the options that you selected during installation and write it to /root/anaconda-ks.cfg at the end of each Red Hat install. A kickstart file is essentially a "response file" for the Anaconda installer;|
To install a new system you need to modify this file, changing the configuration to suit the specification of the new system. If system is identical then just static IP needs to be changed (DHCP systems can be cloned without any changed of kickstat file)
The kickstart file contains the answers to all the questions that Anaconda asked during installation.
Using it allows to automate a RHEL installation as all you need is to find sufficiently similar system, borrow existing /root/anaconda-ks.cfg and modify IP stack parameters and possibly some other (partitioning, packages).
Kickstart installations can be performed using a local CD-ROM, a local hard drive, or via NFS, FTP, or HTTP. We will discuss HTTP based installation.
To install a system using kickstart, you need to perform the following steps
Boot your system with a Red Hat Enterprise Linux 6 DVD and after it loads the installation screen,
press the "Tab" key on the first option that reads "Install or upgrade an existing system."
After pressing tab the following line should appear:
Edit the command line so that it retrieve kickstart file from the network. This assumes that the computer is connected to a network via the eth0 network interface and DHCK is present on the segment. For example:
vmlinuz initrd=initrd.img ks=http://10.10.10.1/srv/Kickstart/ks60_dl380.cfg ksdevice=eth0
ksdevice=eth0parameter specifies the interface to be used for network installation. If a system has multiple network interfaces, this prevents the installation from prompting you to choose an interface.
vmlinuz initrd=initrd.img ks=nfs:10.194.181.50:/Apps/ks.cfg ksdevice=eth0
see also a video Kickstart installation using a NFS server -- YouTube
Unlike current and crazy fashion of using XML configuration files even in cases where they definitely are not optional, the kickstart file is a simple text file, containing a list of items, each identified by a keyword. So it can be created and maintained with a regular text editor. And that's good, because in many case where XML is used, simple text file is sufficient. It is simpler to edit and less prone to errors.
Typically you borrow kickstart file from a similar system and then modify either using the Kickstart Configurator application, or manually. As at the end of each installation Anaconda writes the file /root/anaconda-ks.cfg. with all the installation parameters you specified for the system.
The only problem is that it assumed current partitioning preseved. So you need copy of MBR for the server to restore the sever from scratach.
If you are careful with the selection of packages and partitioning you should be able to reuse this file for similar servers.
Kickstart file is retrieved using either local storage (typically USB drive) or several networking protokols (NFS, HTTP. and FTP).
This allow the use of a single kickstart file to install Red Hat Enterprise Linux on multiple machines, for example belonging to a cluster.
The network option allows you to specify how Anaconda should configure your network card(s). You can choose automatic configuration through either DHCP or BOOTP, or you can specify the IP address mask and gateway manually.
You have a couple of options here. As already mentioned, you can create customized kickstart files for each server and then hard-code the IP address into them.
Or if the segment on which the server resides has DHCP you can specify DHCP and then manually change it to static IP.
You can also do this in the %post section. This could involve looking up the IP address on a remote server or anything else that you come up with. The network configuration tool does accept command-line arguments, so it is possible to script this setting IP address, netmask and gateway for the server. Of course, for this to work, the server would need some form of network connectivity to start with, either a fixed IP that all machines being built use (although that really restricts you to building one machine at a time) or ideally DHCP.
To use Kickstart Configurator, you must be running the X Window System and have Kickstart Configurator installed on your system.
Kickstart Configurator is not installed by default, so you might need to install it with yum or your graphical package manager.To start Kickstart Configurator, select Applications (the main menu on the panel) => System Tools => Kickstart, or type the command
As you are creating a kickstart file, you can select File => Preview at any time to review your current selections.To start with an existing kickstart file, select File => Open and select the existing file.
Choose the language to use during the installation and as the default language to be used after installation from the Default Language menu.Select the system keyboard type from the Keyboard menu.
From the Time Zone menu, choose the time zone to use for the system. To configure the system to use UTC, select Use UTC clock.Enter the desired root password for the system in the Root Password text entry box. Type the same password in the Confirm Password text box. The second field is to make sure you do not mistype the password and then realize you do not know what it is after you have completed the installation. To save the password as an encrypted password in the file, select Encrypt root password. If the encryption option is selected, when the file is saved, the plain text password that you typed is encrypted and written to the kickstart file. Do not type an already encrypted password and select to encrypt it. Because a kickstart file is a plain text file that can be easily read, it is recommended that an encrypted password be used.
Select the Specify installation key checkbox to provide an installation key.Choosing Target Architecture specifies which specific hardware architecture distribution is used during installation.
Choosing Reboot system after installation reboots your system automatically after the installation is finished.Kickstart installations are performed in graphical mode by default. To override this default and use text mode instead, select the Perform installation in text mode option.
You can perform a kickstart installation in interactive mode. This means that the installation program uses all the options pre-configured in the kickstart file, but it allows you to preview the options in each screen before continuing to the next screen. To continue to the next screen, click the Next button after you have approved the settings or change them before continuing the installation. To select this type of installation, select the Perform installation in interactive mode option.The Installation Method screen allows you to choose whether to perform a new installation or an upgrade. If you choose upgrade, the Partition Information and Package Selection options are disabled. They are not supported for kickstart upgrades. Choose the type of kickstart installation or upgrade from the following options:
GRUB is the default boot loader for Red Hat Enterprise Linux on x86 / x86_64 architectures. If you do not want to install a boot loader, select Do not install a boot loader. If you choose not to install a boot loader, make sure you create a boot diskette or have another way to boot your system, such as a third-party boot loader. You must choose where to install the boot loader (the Master Boot Record or the first sector of the /boot partition). Install the boot loader on the MBR if you plan to use it as your boot loader. To pass any special parameters to the kernel to be used when the system boots, enter them in the Kernel parameters text field. For example, if you have an IDE CD-ROM Writer, you can tell the kernel to use the SCSI emulation driver that must be loaded before using cdrecord by configuring hdd=ide-scsi as a kernel parameter (where hdd is the CD-ROM device). You can password protect the GRUB boot loader by configuring a GRUB password. Select Use GRUB password, and enter a password in the Password field. Type the same password in the Confirm Password text field. To save the password as an encrypted password in the file, select Encrypt GRUB password. If the encryption option is selected, when the file is saved, the plain text password that you typed is encrypted and written to the kickstart file. If the password you typed was already encrypted, unselect the encryption option. If Upgrade an existing installation is selected on the Installation Method page, select Upgrade existing boot loader to upgrade the existing boot loader configuration, while preserving the old entries.
The OS Deployment feature available in Lifecycle Controller enables you to deploy standard and custom operating systems on the managed system. You can also configure RAID before installing the operating system if it is not already configured. You can deploy the operating system using any of the following methods:
- Manual installation
- Unattended installation
The unattended installation feature requires an OS configuration or answer file. During unattended installation, the answer file is provided to the OS loader. This activity requires minimal or no user intervention. Currently, the unattended installation feature is supported only for Microsoft Windows and Red Hat Enterprise Linux 7 operating systems from Lifecycle Controller.
Note: This paper only covers unattended installation of Red Hat Enterprise Linux 7 operating system from Lifecycle Controller. For more information about unattended installation of Microsoft Windows operating systems, see the Unattended Installation of Windows Operating Systems
After the kernel and ramdisk loads and detects the Kickstart file, the installation process automatically starts without any intervention from user side needed. If you want to watch the installation process connect with a VNC client from a different computer using the address that the installer provides you and enjoy the view.
January 7, 2017 | tuxfixer.comLinux installation can be performed totally unattended using Kickstart file, which contains configuration, required setup and post installation tasks to fully automate installation process without being prompted for any input details. Kickstart file can be placed in the remote repository or can be included in ISO image in order to be read by Anaconda installer during system installation.
In this tutorial we present some practical solutions that can be placed in kickstart file to automate CentOS 7 / Red Hat 7 installation tasks.
Sept 6, 2007 | CentOS Bug Tracker
I'm passing "linux ks=hd:sdb1:/ks.cfg," but I get a message saying:"Unable to download kickstart file, Please modify parameters below or press cancel to proceed as an interactive installation."
I use the exact same boot options with CentOS 4 without any problems. It seems like the usb driver isn't loading properly. There was one time where I just hit okay at the anaconda dialog and it somehow found the usb drive. But, ever other time, the usb drive is simply not recognized.
With CentOS 4, the drive was always recognized as sdb1 during the boot process.
A: I can confirm this issue.
I managed to find a dirty solution for this bug, however.
When the error message appears, remove & re-insert the usb key and hit "OK". This will cause the drive to be recognized and the installation will continue.
Anyway, please fix this, because this sure takes a bite out of unattended installations.
I attempted to do a fully-automated install with a U3 USB key, with the following configured under /boot/grub/grub.conf, and /kickstart/ks.cfg on the key:
kernel /boot/vmlinuz ks=hd:sda1/kickstart/ks.cfg
A the point where the install is going to look-up the kickstart file, I see the following output to the anaconda log:
16:40:23 INFO: getting kickstart file from harddrive
16:40:23 INFO: Loading ks from device sda1 on path kickstart/ks.cfg
16:40:23 INFO: getFileFromBlockDevice(sda1, kickstart/ks.cfg)
16:40:24 ERROR: failed to mount /dev/sda1: No such device or address
16:40:30 INFO: getting kickstart file from harddrive
16:40:30 INFO: Loading ks from device sda1 on path kickstart/ks.cfg
16:40:30 INFO: getFileFromBlockDevice(sda1, kickstart/ks.cfg)
16:40:30 INFO: Searching for file on path /tmp/mnt/kickstart/ks.cfg
16:40:30 INFO: file copied to /tmp/ks.cfg
16:40:30 INFO: setting up kickstart
16:40:30 INFO: kickstartFromHD
The point where ******** are indicated, is where I was prompted to correct the path to ks.cfg. I only pressed the <enter> key, and the remainder of the log is from the successful reading of the kickstart file.
I did not have to remove the USB kick to re-register the dialog closure, but to only hit the OK button after the initial pop-up dialog.
I am using 2.6.18-53.el5xen, CentOS release 5 (Final).
Kickstart and usb may always be a problem as you are cannot be sure about the assigned device node (depending on other attached hardware components).
Have you tried to boot up Anaconda (with the USB device attached), switched to a virtual console and did a cat /proc/partitions to figure out the node of the USB device?
For full documentations, please see http://www.centos.org/docs/5/html/5.2/Installation_Guide/s1-kickstart2-howuse.html
Tuning the %packages section
When using %packages to define the set of packages that should be installed there are a number of more or less documented options that can be set:
- Dependencies between packages will be automatically resolved. This option has been deprecated in Centos 5, dependencies are resolved automatically every time now.
Skips the installation of files that are marked as documentation (all files that are listed when you do rpm -qld <packagename>)
- Skips installation of @Base. This won't work unless you know what you're doing as it might leave out packages required by post installation scripts
- Ignore missing packages and groups instead of asking what to do. This option has been deprecated in Centos 5, dependencies are resolved automatically every time now.
Example of minimal package selection for CentOS 4:%packages --resolvedeps --excludedocs --nobase kudzu
please note that essential stuff will be missing. There will be no rpm, no yum, no vim, no dhcp-client and no keyboard layouts. Kudzu is required, because the installer fails if it is missing.
Example of minimal package selection for CentOS 5:%packages --excludedocs --nobase @Core
Again, this will leave you with a *very* basic system that will be missing almost every feature you might expect.
The --resolvedeps used with CentOS 4 is not required for CentOS 5 as the newer installer always resolves dependencies.
If you start out with a unpartitioned disk, or a virtual machine on a unpartitioned image, use the --initlabel parameter to clearpart to make sure that the disklabel is initialized, or Anaconda will ask you to confirm creation of a disklabel interactively. For instance, to clean all partitions on xvda, and initialize the disklabel if it does not exist yet, you could use:clearpart --all --initlabel --drives=xvda
Running anaconda in real text-mode
You probably already know that you can make anaconda run with a ncurses interface instead of the X11 interface by adding the line "text" to your kickstart file. But there's another option: install in real shell-like textmode. Replace the "text"-line with a "cmdline"-line in your kickstart file and anaconda will do the whole installation in textmode. Especially when you use %packages --nobase or run complex %post scripts this will probably save hours of debugging, because you can actually see the output of all scripts that run during the installation.
You all know firstboot, the druid that helps you to set up the system after install. It can be enabled and disabled by adding either "firstboot --enable" or "firstboot --disable" to the command section of your kickstart file.
What the different terminals display
- The installation dialog when using text or cmdline
- A shell prompt
- The install log displaying messages from install program
- The system log displaying messages from kernel, etc.
- All other messages
- The installation dialog when using the graphical installer
Logging %pre and %post
When using a %pre or %post script you can simply log the output to a file by using --log=/path/to/file%post --log=/root/my-post-log echo 'Hello, World!'
Another way of logging and displaying the results on the screen would be the following:%post exec < /dev/tty3 > /dev/tty3 chvt 3 echo echo "################################" echo "# Running Post Configuration #" echo "################################" ( echo 'Hello, World!' ) 2>&1 | /usr/bin/tee /var/log/post_install.log chvt 1
Trusted interfaces for firewall configuration
You can use the --trust option to the firewall option multiple times to trust multiple interfaces:# Enable firewall, open port for ssh and make eth1 and eth2 trusted firewall --enable --ssh --trust=eth1 --trust=eth2
Use a specific network interface for kickstart
When your system has more than one network interface anaconda asks you which one you'd like to use for the kickstart process. This decision can be made at boot time by adding the ksdevice paramter and setting it accordingly. To run kickstart via eth0 simply add ksdevice=eth0 to the kernel command line.
A second method is using ksdevice=link. In this case anaconda will use the first interface it finds that has a active link.
A third method works if you are doing PXE based installations. Then you add IPAPPEND 2 to the PXE configuration file and use ksdevice=bootif. In this case anaconda will use the interface that did the PXE boot (this does not necessarily needs to be the first one with a active link).
Within the kickstart config itself you need to define the network interfaces using the network statement. If you are using method 2 or 3 then you don't know which device actually will be used. If you don't specify a device for the network statement anaconda will configure the device used for the kickstart process and set it up according to your network statement.
Forcing kickstart to ask for network configuration
Starting at CentOS 5, there a undocumented option that enable a prompt asking for network configuration during the installation. At the network statement, put the query keyword at the --bootproto= networking configuration, as we see below:network --device=eth0 --bootproto=query
And a dialog box will appear asking for IP addressing, as well the hostname configuration.
Google matched content
The ignoredisk option is also useful if you have multiple paths to your disks.The syntax is:
ignoredisk --drives=drive1,drive2,...where driveN is one of sda, sdb,..., hda,... etc.
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 library does not place a period . in front of the LHS and RHS values when performing a search. Therefore the LHS and RHS values need to have a period placed in front of them in order if they require this.
bootloader --location=mbr --append="hdd=ide-scsi ide=nodma"
bootloader --hvargs="dom0_mem=2G dom0_max_vcpus=4"
device <type> <moduleName> --opts=<options>
driverdisk <partition> [--type=<fstype>]Alternatively, a network location can be specified for the driver diskette:
driverdisk --source=ftp://path/to/dd.img driverdisk --source=http://path/to/dd.img driverdisk --source=nfs:host:/path/to/img
firewall --enabled|--disabled [--trust=] <device> [--port=]
The halt option is roughly equivalent to the shutdown -h command.For other completion methods, refer to the poweroff, reboot, and shutdown kickstart options.
BIOS partition to install from (such as 82).
Partition to install from (such as sdb2).
Directory containing the variant directory of the installation tree.
harddrive --partition=hdb2 --dir=/tmp/install-tree
Server from which to install (hostname or IP).
Directory containing the variant directory of the installation tree.
Mount options to use for mounting the NFS export. (optional)
nfs --server=nfsserver.example.com --dir=/tmp/install-tree
url --url http://<server>/<dir>or:
url --url ftp://<username>:<password>@<server>/<dir>
Specifies additional iSCSI storage to be attached during installation. If you use the iscsi parameter, you must also assign a name to the iSCSI node, using the iscsiname parameter. The iscsiname parameter must appear before the iscsi parameter in the kickstart file.We recommend that wherever possible you configure iSCSI storage in the system BIOS or firmware (iBFT for Intel systems) rather than use the iscsi parameter. Anaconda automatically detects and uses disks configured in BIOS or firmware and no special configuration is necessary in the kickstart file.
If you must use the iscsi parameter, ensure that networking is activated at the beginning of the installation, and that the iscsi parameter appears in the kickstart file before you refer to iSCSI disks with parameters such as clearpart or ignoredisk.
be-latin1, bg, br-abnt2, cf, cz-lat2, cz-us-qwertz, de, de-latin1, de-latin1-nodeadkeys, dk, dk-latin1, dvorak, es, et, fi, fi-latin1, fr, fr-latin0, fr-latin1, fr-pc, fr_CH, fr_CH-latin1, gr, hu, hu101, is-latin1, it, it-ibm, it2, jp106, la-latin1, mk-utf, no, no-latin1, pl, pt-latin1, ro_win, ru, ru-cp1251, ru-ms, ru1, ru2, ru_win, se-latin1, sg, sg-latin1, sk-qwerty, slovene, speakup, speakup-lt, sv-latin1, sg, sg-latin1, sk-querty, slovene, trq, ua, uk, us, us-acentosThe file /usr/lib/python2.2/site-packages/rhpl/keyboard_models.py also contains this list and is part of the rhpl package.
lang en_USThe file /usr/share/system-config-language/locale-list provides a list of the valid language codes in the first column of each line and is part of the system-config-language package.
Certain languages (mainly Chinese, Japanese, Korean, and Indic languages) are not supported during text mode installation. If one of these languages is specified using the lang command, installation will continue in English though the running system will have the specified language by default.
logvol <mntpoint> --vgname=<name> --size=<size> --name=<name> <options>The options are as follows:
part pv.01 --size 3000 volgroup myvg pv.01 logvol / --vgname=myvg --size=2000 --name=rootvol
Specify the minimum level of messages that appear on tty3. All messages will still be sent to the log file regardless of this level, however.
It defaults to dhcp. bootp and dhcp are treated the same.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. To direct a system to use DHCP:
network --bootproto=dhcpTo direct a machine to use BOOTP to obtain its networking configuration, use the following line in the kickstart file:
network --bootproto=bootpThe static method requires that you enter all the required networking information in the kickstart file. As the name implies, this information is static and is used during and after the installation. The line for static networking is more complex, as you must include all network configuration information on one line. You must specify the IP address, netmask, gateway, and nameserver.
Note that although the presentation of this example on this page has broken the line, in a real kickstart file, you must include all this information on a single line with no break.
network --bootproto=static --ip=10.0.2.15 --netmask=255.255.255.0 --gateway=10.0.2.254 --nameserver=10.0.2.1If you use the static method, be aware of the following two restrictions:
Note that although the presentation of this example on this page has broken the line, in a real kickstart file, you must include all this information on a single line with no break.
network --bootproto=static --ip=10.0.2.15 --netmask=255.255.255.0 --gateway=10.0.2.254 --nameserver 192.168.2.1,192.168.3.1
network --bootproto=dhcp --device=eth0
multipath --name=mpathX --device=device_name --rule=policyFor example:
multipath --name=mpath0 --device=/dev/sdc --rule=failoverThe available options are:
If more than one Red Hat Enterprise Linux installation exists on the system on different partitions, the installation program prompts the user and asks which installation to upgrade.
For a detailed example of part in action, refer to Section 31.4.1, "Advanced Partitioning Example".
For example, /, /usr, /home
The partition is used as swap space.To determine the size of the swap partition automatically, use the --recommended option:
swap --recommendedThe recommended maximum swap size for machines with less than 2GB of RAM is twice the amount of RAM. For machines with 2GB or more, this recommendation changes to 2GB plus the amount of RAM.
The partition is used for software RAID (refer to raid).
The partition is used for LVM (refer to logvol).
partition /home --onpart=hda1puts /home on /dev/hda1, which must already exist.
The poweroff option is roughly equivalent to the shutdown -p command.
For other completion methods, refer to the halt, reboot, and shutdown kickstart options.
raid <mntpoint> --level=<level> --device=<mddevice> <partitions*>
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.13For a detailed example of raid in action, refer to Section 31.4.1, "Advanced Partitioning Example".
The reboot option is roughly equivalent to the shutdown -r command.Specify reboot to automate installation fully when installing in cmdline mode on System z.
For other completion methods, refer to the halt, poweroff, and shutdown kickstart options.The halt option is the default completion method if no other methods are explicitly specified in the kickstart file.
repo --name=<repoid> [--baseurl=<url>| --mirrorlist=<url>]
rootpw [--iscrypted] <password>
If the selinux option is not present in the kickstart file, SELinux is enabled and set to --enforcing by default.
- --permissive Outputs warnings based on the SELinux policy, but does not actually enforce the policy.
- --disabled Disables SELinux completely on the system.
Do not include spaces in the list of servicesIf you include spaces in the comma-separated list, kickstart will enable or disable only the services up to the first space. For example:
services --disabled auditd, cups,smartd,nfslockwill disable only the auditd service. To disable all four services, this entry should include no spaces between services:
services --disabled auditd,cups,smartd,nfslock
The shutdown option is roughly equivalent to the shutdown command.For other completion methods, refer to the halt, poweroff, and reboot kickstart options.
timezone [--utc] <timezone>
user --name=<username> [--groups=<list>] [--homedir=<homedir>] [--password=<password>] [--iscrypted] [--shell=<shell>] [--uid=<uid>]
vnc [--host=<hostname>] [--port=<port>] [--password=<password>]
volgroup <name> <partition> <options>The options are as follows:
part pv.01 --size 3000 volgroup myvg pv.01 logvol / --vgname=myvg --size=2000 --name=rootvolFor a detailed example of volgroup in action, refer to Section 31.4.1, "Advanced Partitioning Example".
clearpart --drives=hda,hdc --initlabel # Raid 1 IDE config part raid.11 --size 1000 --asprimary --ondrive=hda part raid.12 --size 1000 --asprimary --ondrive=hda part raid.13 --size 2000 --asprimary --ondrive=hda part raid.14 --size 8000 --ondrive=hda part raid.15 --size 1 --grow --ondrive=hda part raid.21 --size 1000 --asprimary --ondrive=hdc part raid.22 --size 1000 --asprimary --ondrive=hdc part raid.23 --size 2000 --asprimary --ondrive=hdc part raid.24 --size 8000 --ondrive=hdc part raid.25 --size 1 --grow --ondrive=hdc # You can add --spares=x raid / --fstype ext3 --device md0 --level=RAID1 raid.11 raid.21 raid /safe --fstype ext3 --device md1 --level=RAID1 raid.12 raid.22 raid swap --fstype swap --device md2 --level=RAID1 raid.13 raid.23 raid /usr --fstype ext3 --device md3 --level=RAID1 raid.14 raid.24 raid pv.01 --fstype ext3 --device md4 --level=RAID1 raid.15 raid.25 # LVM configuration so that we can resize /var and /usr/local later volgroup sysvg pv.01 logvol /var --vgname=sysvg --size=8000 --name=var logvol /var/freespace --vgname=sysvg --size=8000 --name=freespacetouse logvol /usr/local --vgname=sysvg --size=1 --grow --name=usrlocalThis advanced example implements LVM over RAID, as well as the ability to resize various directories for future growth.
You can use a kickstart file to install every available package by specifying @Everything or simply * in the %packages section. Red Hat does not support this type of installation.Moreover, using a kickstart file in this way will introduce package and file conflicts onto the installed system. Packages known to cause such problems are assigned to the @Conflicts group. If you specify @Everything in a kickstart file, be sure to exclude @Conflicts or the installation will fail:
@Everything -@ConflictsNote that Red Hat does not support the use of @Everything in a kickstart file, even if you exclude @Conflicts.
Use the %packages command to begin a kickstart file section that lists the packages you would like to install (this is for installations only, as package selection during upgrades is not supported).Packages can be specified by group or by individual package name, including with globs using the asterisk. The installation program defines several groups that contain related packages. Refer to the variant/repodata/comps-*.xml file on the first Red Hat Enterprise Linux CD-ROM for a list of groups. Each group has an id, user visibility value, name, description, and package list. In the package list, the packages marked as mandatory are always installed if the group is selected, the packages marked default are selected by default if the group is selected, and the packages marked optional must be specifically selected even if the group is selected to be installed.
Available groups vary slightly between different variants of Red Hat Enterprise Linux 5, but include:
Here is an example %packages selection:
%packages @ X Window System @ GNOME Desktop Environment @ Graphical Internet @ Sound and Video dhcpAs you can see, groups are specified, one to a line, starting with an @ symbol, a space, and then the full group name as given in the comps.xml file. Groups can also be specified using the id for the group, such as gnome-desktop. Specify individual packages with no additional characters (the dhcp line in the example above is an individual package).
You can also specify which packages not to install from the default package list:
-autofsThe following options are available for the %packages option:
%pre #!/bin/sh hds="" mymedia="" for file in /proc/ide/h* do mymedia=`cat $file/media` if [ $mymedia == "disk" ] ; then hds="$hds `basename $file`" fi done set $hds numhd=`echo $#` drive1=`echo $hds | cut -d' ' -f1` drive2=`echo $hds | cut -d' ' -f2` #Write out partition scheme based on whether there are 1 or 2 hard drives if [ $numhd == "2" ] ; then #2 drives echo "#partitioning scheme generated in %pre for 2 drives" > /tmp/part-include echo "clearpart --all" >> /tmp/part-include echo "part /boot --fstype ext3 --size 75 --ondisk hda" >> /tmp/part-include echo "part / --fstype ext3 --size 1 --grow --ondisk hda" >> /tmp/part-include echo "part swap --recommended --ondisk $drive1" >> /tmp/part-include echo "part /home --fstype ext3 --size 1 --grow --ondisk hdb" >> /tmp/part-include else #1 drive echo "#partitioning scheme generated in %pre for 1 drive" > /tmp/part-include echo "clearpart --all" >> /tmp/part-include echo "part /boot --fstype ext3 --size 75" >> /tmp/part-include echo "part swap --recommended" >> /tmp/part-include echo "part / --fstype ext3 --size 2048" >> /tmp/part-include echo "part /home --fstype ext3 --size 2048 --grow" >> /tmp/part-include fiThis script determines the number of hard drives in the system and writes a text file with a different partitioning scheme depending on whether it has one or two drives. Instead of having a set of partitioning commands in the kickstart file, include the line:
%include /tmp/part-includeThe partitioning commands selected in the script are used.
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
This command is available in Red Hat Enterprise Linux 5.5 and later.
%post --log=/root/ks-post.logwith --nochroot:
%post --nochroot --log=/mnt/sysimage/root/ks-post.log
%post ( # Note that in this example we run the entire %post section as a subshell for logging. wget -O- http://proxy-or-sat.example.com/pub/bootstrap_script | /bin/bash /usr/sbin/rhnreg_ks --activationkey=<activationkey> # End the subshell and capture any output to a post-install log file. ) 1>/root/post_install.log 2>&1Register the system to a Red Hat Network Satellite, using the --log option to log the result in Red Hat Enterprise Linux 5.5 and later:
%post --log=/root/ks-post.log wget -O- http://proxy-or-sat.example.com/pub/bootstrap_script | /bin/bash /usr/sbin/rhnreg_ks --activationkey=<activationkey>Run a script named runme from an NFS share:
mkdir /mnt/temp mount -o nolock 10.10.0.2:/usr/new-machines /mnt/temp open -s -w -- /mnt/temp/runme umount /mnt/temp
Let us take a more in-depth look at where the kickstart file may be placed.
To perform a CD-ROM-based kickstart installation, the kickstart file must be named ks.cfg and must be located in the boot CD-ROM's top-level directory. Since a CD-ROM is read-only, the file must be added to the directory used to create the image that is written to the CD-ROM. Refer to Section 2.4.1, "Alternative Boot Methods" for instructions on creating boot media; however, before making the file.iso image file, copy the ks.cfg kickstart file to the isolinux/ directory.To perform a pen-based flash memory kickstart installation, the kickstart file must be named ks.cfg and must be located in the flash memory's top-level directory. Create the boot image first, and then copy the ks.cfg file.
To perform a network-based kickstart installation, you must have a BOOTP/DHCP server on your network, and it must include configuration information for the machine on which you are attempting to install Red Hat Enterprise Linux. The BOOTP/DHCP server provides the client with its networking information as well as the location of the kickstart file.If a kickstart file is specified by the BOOTP/DHCP server, the client system attempts an NFS mount of the file's path, and copies the specified file to the client, using it as the kickstart file. The exact settings required vary depending on the BOOTP/DHCP server you use.
Here is an example of a line from the dhcpd.conf file for the DHCP server:
filename "/usr/new-machine/kickstart/"; next-server blarg.redhat.com;Note that you should replace the value after filename with the name of the kickstart file (or the directory in which the kickstart file resides) and the value after next-server with the NFS server name.
If the file name returned by the BOOTP/DHCP server ends with a slash ("/"), then it is interpreted as a path only. In this case, the client system mounts that path using NFS, and searches for a particular file. The file name the client searches for is:
<ip-addr>-kickstartThe <ip-addr> section of the file name should be replaced with the client's IP address in dotted decimal notation. For example, the file name for a computer with an IP address of 10.10.0.1 would be 10.10.0.1-kickstart.
Note that if you do not specify a server name, then the client system attempts to use the server that answered the BOOTP/DHCP request as its NFS server. If you do not specify a path or file name, the client system tries to mount /kickstart from the BOOTP/DHCP server and tries to find the kickstart file using the same <ip-addr>-kickstart file name as described above.
If you are performing a CD-based installation, insert the Red Hat Enterprise Linux CD-ROM #1 into the computer before starting the kickstart installation.If you are performing a hard drive installation, make sure the ISO images of the binary Red Hat Enterprise Linux CD-ROMs are on a hard drive in the computer.
If you are performing a network-based (NFS, FTP, or HTTP) installation, you must make the installation tree available over the network. Refer to Section 2.5, "Preparing for a Network Installation" for details.
An alternate boot command is to boot off the Red Hat Enterprise Linux CD-ROM #1 and have the kickstart file on a vfat or ext2 file system on a diskette. To do so, enter the following command at the boot: prompt:
linux ks=floppy dd
Requires 'vnc' option to be specified as well.
Requires 'vnc' option to be specified as well.
Google matched content
Secure VNC Installation of Red Hat Enterprise Linux 6
Red Hat Enterprise Linux Anaconda customization guide
Unattended Installation of Red Hat Enterprise Linux 7 ... - Dell Unattended Installation of Red Hat Enterprise Linux 7 Operating System on Dell PowerEdge Servers Using iDRAC With Lifecycle Controller
Unattended Kickstart (Linux): http://en.wikipedia.org/wiki/Kickstart_(Linux)
Creating a Kickstart File: http://docs.oracle.com/cd/E37670_01/E41137/html/ch03s01.html
Kickstart Options: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/s1-kickstart2-options.html
Starting a Kickstart Installation: https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/s1-kickstart2-startinginstall.html
5. Kickstart Configurator (Basic Configuration): https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/ch-redhat-config-kickstart.html
6. Kickstart Configurator (Installation Method):
7. Kickstart Configurator (Boot Loader Options): https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Installation_Guide/s1-redhat-config-kickstart-bootloader.html
8. Kickstart Configurator (Partition Information):
9. Kickstart Configurator (Network Configuration):
10. Kickstart Configurator (Authentication):
11. Kickstart Configurator (Firewall Configuration):
Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers : Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism : The Iron Law of Oligarchy : Libertarian Philosophy
War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda : SE quotes : Language Design and Programming Quotes : Random IT-related quotes : Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce : Bernard Shaw : Mark Twain Quotes
Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 : Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law
Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds : Larry Wall : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS : Programming Languages History : PL/1 : Simula 67 : C : History of GCC development : Scripting Languages : Perl history : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history
The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month : How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Haters Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite
Most popular humor pages:
Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor
The Last but not Least
Copyright © 1996-2018 by Dr. Nikolai Bezroukov. www.softpanorama.org was initially created as a service to the (now defunct) UN Sustainable Development Networking Programme (SDNP) in the author free time and without any remuneration. This document is an industrial compilation designed and created exclusively for educational use and is distributed under the Softpanorama Content License. Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
FAIR USE NOTICE This site contains copyrighted material the use of which has not always been specifically authorized by the copyright owner. We are making such material available to advance understanding of computer science, IT technology, economic, scientific, and social issues. We believe this constitutes a 'fair use' of any such copyrighted material as provided by section 107 of the US Copyright Law according to which such material can be distributed without profit exclusively for research and educational purposes.
This is a Spartan WHYFF (We Help You For Free) site written by people for whom English is not a native language. Grammar and spelling errors should be expected. The site contain some broken links as it develops like a living tree...
|You can use PayPal to make a contribution, supporting development of this site and speed up access. In case softpanorama.org is down you can use the at softpanorama.info|
The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Last modified: February 28, 2018