Chapter 3. System Provisioning

3.1. Provisioning Through Red Hat Satellite

Provisioning is the process of configuring a physical or virtual machine to a predefined known state. Red Hat Satellite provisions systems using the kickstart process. To use the provisioning functionality, one or more target machines are required. The target machines can be either physical, bare metal systems, or virtual machines. To use Red Hat Satellite's virtual machine provisioning functionality, create the virtual machines using either Xen or KVM.

System administrators can use an automated installation method to install Red Hat Enterprise Linux on their machines through the kickstart installation method. Using kickstart, a system administrator can create a single file containing the answers to all the questions that would normally be asked during a typical installation.

Kickstart files can be kept on a single server system and read by individual computers during the installation. This installation method can support the use of a single kickstart file to install Red Hat Enterprise Linux on multiple machines.

Base images, kickstart files, and other content can be accessed using HTTP by using the Satellite server URL. For example, to access kickstart files for Red Hat Enterprise Linux 6 for 64-bit on the Satellite server, the base URL would be http://satellite.example.com/ks/dist/ks-rhel-x86_64-server-6-6.4, followed by the name of the package you wish to download, such as: http://satellite.example.com/ks/dist/ks-rhel-x86_64-server-6-6.4/GPL.

The Red Hat Enterprise Linux Installation Guide contains an in-depth discussion of kickstart.

Definitions

Some terms used throughout this section:

Kickstarting: The process of installing a Red Hat Enterprise Linux system in an automated manner requiring little or no user intervention. Technically, kickstart refers to a mechanism in the Anaconda installation program that allows concise description of the contents and configuration of a machine to be written into the installer, which it then acts on. Such a concise system definition is referred to as a Kickstart profile.
Kickstart profile: The kickstart file is a text file that specifies all of the options needed to kickstart a machine, including partitioning information, network configuration, and packages to install. In Red Hat Satellite, a Kickstart Profile is a superset of a traditional Anaconda kickstart definition, as Satellite's implementation builds on Cobbler's enhancements to kickstarting. A Kickstart Profile presumes the existence of a Kickstart Tree.
Kickstart Tree: The software and support files needed in order to kickstart a machine. This is also often called an "install tree". This is usually the directory structure and files pulled from the installation media that ships with a particular release. In Cobbler terminology, a Kickstart Tree is part of a distribution.
PXE (Preboot eXecution Environment): A low-level protocol that makes it possible to kickstart bare metal machines (usually physical, or real, machines) on power-up with no pre-configuration of the target machine itself. PXE relies on a DHCP server to inform clients about bootstrap servers. PXE must be supported in the firmware of the target machine in order to be used. It is possible to use the virtualization and reinstall facilities of Satellite without PXE, though PXE is very useful for booting new physical machines, or reinstalling machines that are not registered to Satellite.

Provisioning Scenarios

The types of provisioning scenarios supported by Red Hat Satellite:

New installations: Provisioning a system that has not previously had an operating system installed (also known as bare metal installations).
Virtual installations: Satellite supports KVM, Xen fully-virtualized guests, and Xen para-virtualized guests.
Re-provisioning: Both physical and guest systems can be re-provisioned, provided that they have been registered to the same Satellite instance. See Section 3.5, “Reprovisioning”.

3.1.1. Kickstart Explained

When a machine is to receive a network-based kickstart, the following events must occur in this order:

After being placed on the network and turned on, the machine's PXE logic broadcasts its MAC address and a request to be discovered.
If a static IP address is not being used, the DHCP server recognizes the discovery request and extends an offer of network information needed for the new machine to boot. This includes an IP address, the default gateway to be used, the netmask of the network, the IP address of the TFTP or HTTP server holding the bootloader program, and the full path and file name of that program relative to the server's root.
The machine applies the networking information and initiates a session with the server to request the bootloader program.
The bootloader, once loaded, searches for its configuration file on the server from which it was itself loaded. This file dictates which kernel and kernel options, such as the initial RAM disk (initrd) image, should be executed on the booting machine. Assuming the bootloader program is SYSLINUX, this file is located in the pxelinux.cfg directory on the server and named the hexadecimal equivalent of the new machine's IP address. For example, a bootloader configuration file for Red Hat Enterprise Linux 6 should contain:
```
default=0
timeout=5
splashimage=(hd0,0)/grub/splash.xpm.gz
hiddenmenu
title Red Hat Enterprise Linux Server (2.6.32-279.22.1.el6.x86_64)
	root (hd0,0)
	kernel /vmlinuz-2.6.32-279.22.1.el6.x86_64 ro root=/dev/sda2 crashkernel=auto ks=http://example.com/ks.cfg
	initrd /initramfs-2.6.32-279.22.1.el6.x86_64.img
```
The machine accepts and uncompresses the init image and kernel, boots the kernel, and initiates a kickstart installation with the options supplied in the bootloader configuration file, including the server containing the kickstart configuration file.
This kickstart configuration file in turn directs the machine to the location of the installation files.
The new machine is built based upon the parameters established within the kickstart configuration file.

3.1.2. Prerequisites

The provisioning entitlement is required in order for System Provisioning to work. Without this entitlement, the tab for Provisioning/Kickstarting will not appear on the Satellite.

The organization's infrastructure should also be prepared to handle kickstart. Some factors to consider before creating kickstart profiles are:

A DHCP server. This is not required for kickstarting, but a DHCP server will ease the need to configure network settings in the kickstart file. You may also boot from the network. If you do not have a DHCP server and are using a static IP addresses, you should select static IP while developing your kickstart profile.
An FTP server. It can be used in place of hosting the kickstart distribution trees via HTTP.

If you are conducting a bare metal kickstart:

Configure DHCP to assign required networking parameters and the bootloader program location.
Specify the kernel to be used and the appropriate kernel options within the bootloader configuration file.

3.1.2.1. Required Packages

If the system is using a custom distribution, it will require the following packages, which are available from any rhn-tools Red Hat Network (RHN) channel:

koan
spacewalk-koan

It is advisable to clone an existing rhn-tools channel in order to have access to these packages from your custom channel.

Red Hat Satellite expects the kernel and initrd files to be in specific locations within the kickstart tree. However, these locations are different for different architectures. The table below explains the different locations:

Table 3.1. Required Distribution Files by Architecture
Architecture	kernel	Initial RAM Disk image
IBM System z	TREE_PATH/images/kernel.img	TREE_PATH/images/initrd.img
PowerPC	TREE_PATH/ppc/ppc64/vmlinuz	TREE_PATH/ppc/ppc64/initrd.img
All other architectures	TREE_PATH/images/pxeboot/vmlinuz	TREE_PATH/images/pxeboot/initrd.img

3.1.2.2. Kickstart Trees

There must be at least one kickstart tree installed on the Satellite in order to use kickstart provisioning. Kickstart trees can be installed either automatically or manually.

Procedure 3.1. Installing Kickstart Trees Automatically

For all distributions that have a base channel in Red Hat Satellite, kickstart trees can be installed automatically. This occurs as part of normal channel synchronization via satellite-sync.

Choose which distribution to base the kickstarts on and locate that distribution's base channel, as well as its corresponding Red Hat Network Tools channel.
For example, to use Red Hat Enterprise Linux 6 with x86 architecture, the rhel-x86_64-server-6 channel and its corresponding Red Hat Network Tools channel rhn-tools-rhel-x86_64-server-6 are required.
If it is a connected Satellite, synchronize the Satellite server with the Red Hat servers directly using the satellite-sync command. If the Satellite server is disconnected, it is necessary to obtain disconnected channel dumps from the Red Hat servers and synchronize with those.
Synchronizing the channel will automatically create a corresponding kickstart tree for that distribution.

Procedure 3.2. Installing Kickstart Trees Manually

To kickstart a custom distribution, which is usually a distribution not supported by Red Hat, or a beta version of Red Hat Enterprise Linux, create the corresponding kickstart tree manually. An installation ISO is required for the distribution used for the kickstart.

Copy the installation ISO to the Satellite server and mount it to /mnt/iso.
Copy the contents of the ISO to a custom location. It is recommended to create a directory within /var/satellite for all custom distributions. For example, copying a Red Hat Enterprise Linux 6 beta distribution's contents to /var/satellite/custom-distro/rhel-x86_64-server-6-beta/.
Use the Red Hat Satellite web interface to create a custom software channel. Use Channels Manage Software Channels Create New Channel to create a parent channel with an appropriate name and label. For the example used above, use the label rhel-6-beta.
Push the software packages from the tree location to the newly created software channel using the rhnpush command:
```
# rhnpush --server=http://localhost/APP -c 'rhel-6-beta' \  -d /var/satellite/custom-distro/rhel-x86_64-server-6-beta/Server/
```
The sub-directory within the tree could be different depending on the distribution.
Once the software packages have been pushed, they can be deleted from within the tree path using the rm command. The packages are still stored on the Satellite server within the channel, and are no longer required in the tree.
```
# rm /var/satellite/custom-distro/rhel-x86_64-server-6-beta/Server/*.rpm
```
You can choose to leave the software packages within the kickstart tree. This will allow them to be installed with the yum command at any time later on.
Use the Red Hat Satellite web interface to create the distribution. Use Systems Kickstart Distributions create new distribution to create the distribution, using an appropriate label and the full tree path (such as /var/satellite/custom-distro/rhel-x86_64-server-6-beta/. Select the base channel that was created earlier, and the correct Installer Generation (such as Red Hat Enterprise Linux 6). To complete the creation, select Create Kickstart Distribution.
To maintain the same software across multiple environments and systems, the Red Hat Network Tools child channel from an existing Red Hat Enterprise Linux base channel can be cloned as a child channel of the newly created base channel. Cloning a child channel can be done by:
1. On the Satellite web interface, click on Channels Manage Software Channels Clone Channel
2. Choose the Child Channel you wish to clone from the drop down box Clone From: and choose the clone state.
3. Click Create Channel.
4. Fill in the necessary information and choose the parent channel that the cloned child channel needs to be under.
5. Click Create Channel.

3.1.2.3. Kickstart Profiles

Kickstart profiles specify the configuration options to be used for the installation.

Kickstart profiles can be created using a wizard interface, which generates a profile based on the answers you give to a series of questions. They can also be created using the raw method, which gives complete control over the contents of the profile.

Procedure 3.3. Creating a Kickstart Profile with a Wizard

Select Systems Kickstart Create a New Kickstart Profile
Provide an appropriate Label, and select the desired Base Channel and Kickstartable Tree
Select the desired Virtualization Type. See Section 3.1.2.3, “Kickstart Profiles” for more information about virtualization types. Click next to continue.
Select the download location for the kickstart profile. For custom distributions, enter the location of its tree as a URL (both HTTP and FTP are supported), otherwise, use the default option. Click next to continue.
Enter the root password and click finish to complete the profile creation.
The complete kickstart profile will be created. View the profile by clicking Kickstart File.

Procedure 3.4. Creating a Kickstart Profile with the Raw Method

Select Systems Kickstart Upload a New Kickstart File
Provide an appropriate label, and select the desired distribution
Select the desired Virtualization Type. See Section 3.1.2.3, “Kickstart Profiles” for more information about virtualization types.

If there is an existing kickstart profile, upload the file. Otherwise, write the kickstart profile in the File Contents text box.

Here is a sample raw kickstart that can be used as a starting point:

install
text
network --bootproto dhcp
url --url http://$http_server/ks/dist/org/1/ks-rhel-x86_64-server-6-6.4
lang en_US
keyboard us
zerombr
clearpart --all
part / --fstype=ext3 --size=200 --grow
part /boot --fstype=ext3 --size=200
part swap --size=1000   --maxsize=2000
bootloader --location mbr
timezone America/New_York
auth --enablemd5 --enableshadow
rootpw --iscrypted $1$X/CrCfCE$x0veQO88TCm2VprcMkH.d0
selinux --permissive
reboot
firewall --disabled
skipx
key --skip

%packages
@ Base

%post
$SNIPPET('redhat_register')

The Red Hat Satellite server does not handle the specified distribution as the url in the kickstart, so remember to include the url --url option in the profile, similar to the following:
```
url --url http://$http_server/ks/dist/org/1/my_distro
```
Replace my_distro with the distribution label and 1 with your org id.
Raw kickstart profiles use $http_server instead of the Satellite's host name. This will be filled in automatically when the kickstart template is rendered.
The redhat_register snippet is used to handle registration.

Figure 3.1. Raw Kickstart

Virtualization Types

All kickstart profiles have a virtualization type associated with them. This table outlines the different options:

Table 3.2. Virtualization Types
Type	Description	Uses
none	No virtualization	Use this type for normal provisioning, bare metal installations, and virtualized installation that are not Xen or KVM (such as VMware, or Virtage)
KVM Virtualized Guest	KVM guests	Use this type for provisioning KVM guests
Xen Fully-Virtualized Guest	Xen guests	Use this type for provisioning Xen guests Note This option requires hardware support on the host, but does not require a modified operating system on the guest.
Xen Para-Virtualized Guest	Xen Guests	Use this type for provisioning a virtual guest with Xen para-virtualization. Para-virtualization is the fastest virtualization mode. It requires a PAE flag on the system CPU, and a modified operating system. Only Red Hat Enterprise Linux 5 supports guests under para-virtualization.
Xen Virtualization Host	Xen hosts	Use this type for provisioning a virtual host with Xen para-virtualization. Xen para-virtualized guests and hosts are supported, if the hardware is compatible. Supported on Red Hat Enterprise Linux 5 only.

Kickstart profiles created to be used as Xen hosts must include the kernel-xen package in the %packages section.

Kickstart profiles created to be used as KVM hosts must include the qemu package in the %packages section.

Fully virtualized systems may require virtualization support to be turned on in the computer's BIOS menu.

Note

For more information about kickstart, see the Kickstart Installations section in the Red Hat Enterprise Linux Installation Guide.

3.1.2.4. Templating

Kickstart templating allows the inclusion of variables, snippets, and flow control statements such as for loops and if statements in the kickstart files. This is achieved using the cheetah tool.

There are a variety of reasons why templating might be useful:

Reusing a particular section of a kickstart, such as a disk partitioning section, between multiple kickstarts.
Performing some %post actions consistently across multiple kickstarts.
Defining a snippet across multiple server roles such as DNS server, proxy server, and web server. For example, a web server might have the following snippet defined:
```
httpd
mod_ssl
mod_python
```
To create a web server profile, include the web server snippet in the %package section of the kickstart file. For a profile to be both a web server and a proxy server, include both snippets in the package section. To add another package to the web server snippet, mod_perl for example, update the snippet, and all profiles that are using that snippet are dynamically updated.

Variables

Templating allows the defining of a variable to be used throughout a kickstart file. Variables are subject to a form of inheritance that allows them to be set at one level and overridden at levels below them. So, if a variable is defined at the system level, it will override the same variable defined at the profile or kickstart tree levels. Likewise, if a variable is defined at the profile level, it will override the same variable defined at the kickstart tree level.

Note

Note that kickstart tree variables cannot be defined for automatically generated kickstart trees, such as those created when a satellite synchronization is performed.

Snippets

Snippets reuse pieces of code between multiple kickstart templates. They can span many lines, and include variables. They can be included in a kickstart profile by using the text $SNIPPET('snippet_name'). A snippet can be made for a package list, for a %post script, or for any text that would normally be included in a kickstart file.

To manage snippets navigate to Systems

Kickstart

Kickstart Snippets.

The Kickstart Snippets page displays several default snippets that cannot be edited, but are available to be used by any organization. Default snippets can be used in kickstarts that have been either written on or uploaded to the Red Hat Satellite server. Default snippets are stored on the Red Hat Satellite server's file system in /var/lib/cobbler/snippets/. Once Kickstart profiles are created, review the contents of /var/lib/rhn/kickstarts/ to see how snippets are incorportated into the profiles.

The redhat_register snippet is a default snippet that is used to register machines to a Red Hat Satellite server as part of a kickstart. It uses a variable called redhat_management_key to register the machine. To use the snippet, set the redhat_management_key variable at either the system, profile, or distribution level and then add $SNIPPET('redhat_register') to a %post section of the kickstart. Any wizard-style kickstarts that are generated by the Red Hat Satellite server will already include this snippet in the %post section.

The Custom Snippets tab allows the viewing and editing of snippets created for use by the organization. New snippets can be created by clicking create new snippet. Custom snippets are stored in the /var/lib/rhn/kickstarts/snippets/ directory. Red Hat Satellite stores snippets for different organizations in different directories, so custom snippets will be stored with a filename similar to the following, where 1 is the organization ID:

$SNIPPET('spacewalk/1/snippet_name')

To determine the text to use to insert the snippet in the kickstart, look for the Snippet Macro column on the snippet list, or on the snippet details page.

Note

Snippets exist at a global level and do not share the same inheritance structure as variables. However, variables can be used within snippets to change the way they behave when different systems request a kickstart.

Figure 3.2. Kickstart Snippets

Escaping Special Characters

The $ and # characters are used during templating for specifying variables and control flow. If these characters are needed for any other purpose in a script, they will need to be escaped so that they are not recognized as a variable. This can be achieved in several ways:

Placing a backslash character (\) before every instance of $ or # that needs to be ignored during templating.
Wrap the entire script in #raw ... #end raw
All %pre and %post scripts created using the wizard-style kickstarts are wrapped with #raw...#end raw by default. This can be toggled using the Template checkbox available when editing a %post or %pre script.
Include #errorCatcher Echo in the first line of the snippet.

Example 3.1. Escaping Special Characters in templates

This example describes how to escape special characters in kickstart templates.

The following bash script needs to be inserted in a %post section:

%post
echo $foo > /tmp/foo.txt

Without the $ being escaped, the templating engine will try to find a variable named $foo and would fail because foo does not exist as a variable.

The simplest way to escape the $ is by using a backslash character (\):

%post
echo \$foo > /tmp/foo.txt

This will cause \$foo to be rendered as $foo.

A second method is to wrap the entire bash script in #raw ... #end raw, as follows

%post
#raw
echo $foo > /tmp/foo.txt
#end raw

The final method is to include #errorCatcher Echo in the first line of the kickstart template. This instructs the templating engine to ignore any variables that do not exist and print out the text as is. This option is already included in the wizard-style kickstarts, and can be included in any raw kickstarts created manually.

3.1.2.5. Kickstarting from Bare Metal

When a machine has no existing operating system or has the wrong operating system installed, it is referred to as a bare metal machine. There are three ways to provision a machine from bare metal:

Standard operating system installation media
PXE boot
Yaboot for PowerPC

Procedure 3.5. Booting from Installation Media

Insert installation media into the machine. The media must match the kickstart intended to use. For example, if the kickstart is configured to use the ks-rhel-x86_64-server-6-6.4 kickstart tree, use the Red Hat Enterprise Linux 6.4 64-bit installation media.
At the boot prompt, activate the kickstart by giving this command:
```
linux ks=http://satellite.example.com/path/to/kickstart
```
Once the system boots up, download the kickstart file, and install automatically.

Procedure 3.6. PXE Booting

To perform a PXE boot, each system must support PXE booting at the BIOS level. Additionally, a DHCP server is required, even if the systems are to be configured statically after installation.

Important
If a DHCP server is deployed on another system on the network, administrative access to the DHCP server is required in order to edit the DHCP configuration file.
Prerequisites
The latest cobbler-loaders package needs to be installed. This is to ensure that the pxelinux.0 boot image is installed and available on the Satellite before PXE booting. To install the latest version:
```
# yum install cobbler-loaders
```
If the machines reside on multiple networks, ensure that all of the machines can connect to the DHCP server. This can be achieved by multi-homing the DHCP server (using either a real or trunked VLAN) and configuring any routers or switches to pass the DHCP protocol across network boundaries.
Configure the DHCP server so that it points to the PXE server by setting the next-server address for the systems to be managed by Red Hat Satellite.
To use hostnames when performing the installation, configure the DHCP server to point to the domain and IP addresses, by including the following lines:
```
option domain-name DOMAIN_NAME;
option domain-name-servers IP_ADDRESS1, IP_ADDRESS2;
```
On the DHCP server, switch to the root user and open the /etc/dhcpd.conf file. Append a new class with options for performing PXE boot installation:
```
allow booting;
allow bootp;
class "PXE" {
  match if substring(option vendor-class-identifier, 0, 9) = "PXEClient";
  next-server 192.168.2.1;
  filename "pxelinux.0";
}
```
This class will perform the following actions:
1. Enable network booting with the bootp protocol
2. Create a class called PXE. If a system is configured to have PXE first in its boot priority, it will identify itself as PXEClient.
3. The DHCP server directs the system to the Cobbler server at the IP address 192.168.2.1
4. The DHCP server refers to the boot image file at /var/lib/tftpboot/pxelinux.0
Restart your DHCP server:
```
# service dhcpd restart
```
Configure Xinetd. Xinetd is a daemon that manages a suite of services including TFTP, the FTP server used for transferring the boot image to a PXE client.
Enable Xinetd using the chkconfig command:
```
# chkconfig xinetd on
```
Alternatively, switch to the root user and open the /etc/xinetd.d/tftp file. Locate the disable = yes line and change it to read disable = no.
Start the Xinetd service so that TFTP can start serving the pxelinux.0 boot image:
```
# chkconfig --level 345 xinetd on
# /sbin/service xinetd start
```
The chkconfig command turns on the xinetd service for all user runlevels, while the /sbin/service command turns on xinetd immediately.

Procedure 3.7. Yaboot Booting

Yaboot is the boot system that operates within the Open Firmware layer for PowerPC. Performing a kickstart requires some configuration to your environment and PowerPC clients.

Configure the boot order for your PowerPC clients. This involves accessing the Open Firmware interface and running the following commands at the prompt.

List the aliases of all devices on your system using the devalias command:

0 > devalias
ibm,sp              /vdevice/IBM,sp@4000
disk                /pci@800000020000002/pci@2,4/pci1069,b166@1/scsi@1/sd@5,0
network             /pci@800000020000002/pci@2/ethernet@1
net                 /pci@800000020000002/pci@2/ethernet@1
network1            /pci@800000020000002/pci@2/ethernet@1,1
scsi                /pci@800000020000002/pci@2,4/pci1069,b166@1/scsi@0
nvram               /vdevice/nvram@4002
rtc                 /vdevice/rtc@4001
screen              /vdevice/vty@30000000
 ok

Display the current boot order by checking the boot-device environment variable:

0 > printenv boot-device
-------------- Partition: common -------- Signature: 0x70 ---------------
boot-device              /pci@800000020000002/pci@2,3/ide@1/disk@0 /pci@800000020000002/pci@2,4/pci1069,b166@1/scsi@1/sd@5,0
 ok

Add the network device to the top of the boot order by setting the boot-device environment variable with the network device first and then the existing boot devices:

0 > setenv boot-device network /pci@800000020000002/pci@2,3/ide@1/disk@0 /pci@800000020000002/pci@2,4/pci1069,b166@1/scsi@1/sd@5,0

The system is now configured to boot from the network device first. If network fails, the system will boot from the remaining devices in the boot order.

Set the system configuration properties on the Satellite server. For example, the following command creates a new system called myppc01 using a specific MAC address on the network:
```
# cobbler system add --name myppc01 --hostname myppc01.example.com --profile rhel6webserver--kopts "console=hvc0 serial" --interface 0 --mac 40:95:40:42:F4:46
```
This also creates a set of directories for the Yaboot bootloader and configuration based upon the MAC address specified. For example, the command previously used would create the following directories:
```
/var/lib/tftpboot/ppc/40-95-40-42-F4-46
/var/lib/tftpboot/etc/40-95-40-42-F4-46
```
The first directory (/var/lib/tftpboot/ppc/40-95-40-42-F4-46) contains the ramdisk and vmlinuz files used for for Yaboot. The second directory (/var/lib/tftpboot/etc/40-95-40-42-F4-46) contains the configuration file (yaboot.conf) with the Yaboot settings.
See Section 3.1.4.6, “Adding a System to Cobbler” for more information about using Cobbler to provision systems.
On the DHCP server, switch to the root user and open the /etc/dhcpd.conf file. Append a new entry with options for performing Yaboot installation. For example:
```
allow booting;
allow bootp;
class "Yaboot" {
  match if substring(option vendor-class-identifier, 0, 9) = "AAPLBSDPC";
  next-server 192.168.2.1;
  filename "yaboot";
}
```
This class will perform the following actions:
1. Enable network booting with the bootp protocol
2. Create a class called Yaboot. If a system is configured to have Yaboot first in its boot priority, it will identify itself as AAPLBSDPC.
3. The DHCP server directs the system to the Cobbler server at the IP address 192.168.2.1
4. The DHCP server refers to the Yaboot image file at created previously with cobbler
Restart your DHCP server:
```
# service dhcpd restart
```
Configure Xinetd. Xinetd is a daemon that manages a suite of services including TFTP, the FTP server used for transferring the boot image to a PowerPC client.
Enable Xinetd using the chkconfig command:
```
# chkconfig xinetd on
```
Alternatively, switch to the root user and open the /etc/xinetd.d/tftp file. Locate the disable = yes line and change it to read disable = no.
Start the Xinetd service so that TFTP can start serving the Yaboot boot image:
```
# chkconfig --level 345 xinetd on
# /sbin/service xinetd start
```
The chkconfig command turns on the xinetd service for all user runlevels, while the /sbin/service command turns on xinetd immediately.

3.1.3. Using Activation Keys

Red Hat Network Management and Provisioning customers with the Activation Key Administrator role (including Satellite Administrators) can generate activation keys through the Red Hat Satellite website. These keys can then be used to register a Red Hat Enterprise Linux system, entitle the system to a Red Hat Satellite service level and subscribe the system to specific channels and system groups through the command line utility rhnreg_ks.

Note

System-specific activation keys created through the Reactivation subtab of the System Details page are not part of this list because they are not reusable across systems.

Procedure 3.8. Managing Activation Keys

To generate an activation key:

Select Systems Activation Keys from the top and left navigation bars.
Click the create new key link at the top-right corner.
Warning
In addition to the fields listed below, Red Hat Satellite customers may also populate the Key field itself. This user-defined string of characters can then be supplied with rhnreg_ks to register client systems with the Satellite. Do not insert commas in the key. All other characters are accepted. Commas are problematic since they are the separator used when including two or more activation keys at once. See Section 3.1.3, “Using Activation Keys” for details.
Provide the following information:
- Description - User-defined description to identify the generated activation key.
- Usage - The maximum number of registered systems that can be registered to the activation key at any one time. Leave blank for unlimited use. Deleting a system profile reduces the usage count by one and registering a system profile with the key increases the usage count by one.
- Base Channels - The primary channel for the key. Selecting nothing will enable you to select from all child channels, although systems can be subscribed to only those that are applicable.
- Add-on Entitlements - The supplemental entitlements for the key, which includes Monitoring, Provisioning, Virtualization, and Virtualization Platform. All systems will be given these entitlements with the key.
- Universal default - Whether or not this key should be considered the primary activation key for your organization. Any client registering to Satellite without an activation key specified will use the Universal Default activation key. Ideally, the Universal Default activation key would include a standard or minimum set of channels and entitlements for basic system registration. For more information on Universal Default activation keys, see https://access.redhat.com/solutions/1140083.
Click Create Activation Key.

After creating the unique key, it appears in the list of activation keys along with the number of times it has been used. Note that only Activation Key Administrators can see this list. At this point, you may associate child channels and groups with the key so that systems registered with it automatically subscribe to them.

To change information about a key, such as the channels or groups, click its description in the key list, make your modifications in the appropriate tab, and click the Update Activation Key button. To disassociate channels and groups from a key, deselect them in their respective menus by Ctrl-clicking their highlighted names. To remove a key entirely, click the delete key link in the top-right corner of the edit page.

A system may be set to subscribe to a base channel during registration with an activation key. However, if the activation key specifies a base channel that is not compatible with the operating system of the systems, the registration fails. For example, a Red Hat Enterprise Linux 6 for x86_64 system cannot register with an Activation Key that specifies a Red Hat Enterprise Linux 5 for x86_64 base channel. A system is always allowed to subscribe to a custom base channel.

To disable system activations with a key, deselect the corresponding checkbox under the Enabled column in the key list. The key can be re-enabled by selecting the checkbox. After making these changes, click the Update Activation Keys button on the bottom right-hand corner of the page.

Procedure 3.9. Using Multiple Activation Keys at Once

The provisioning entitlement allows multiple activation keys at the command line or in a single kickstart profile. This allows the organization to aggregate the aspects of various keys without recreating a new key specific to the desired systems, simplifying the registration and kickstart processes while slowing the growth of the key list.

Registering with multiple activation keys requires some caution; conflicts between some values cause registration to fail. Conflicts in the following values do not cause registration to fail: software packages, software child channels, and config channels. Conflicts in the remaining properties are resolved in the following manner:

base software channels - registration fails
entitlements - registration fails
enable config flag - configuration management is set

Create multiple individual activation keys. See Section 3.1.3, “Using Activation Keys” for instructions.
On the command line, include all the activation keys, separated by a comma, as an option in rhnreg_ks:
```
# rhnreg_ks --activationkey=activationkey1,activationkey2,activationkey3
```
This may also be added into the kickstart profile within the Post tab of the Kickstart Details page. See Section 3.1.2.3, “Kickstart Profiles” for instructions.

Warning

Do not use system-specific activation keys along with other activation keys; registration fails in this event.

3.1.4. Using Cobbler

Red Hat Satellite features the Cobbler server that allows administrators to centralize their system installation and provisioning infrastructure. Cobbler is an installation server that provides various methods of performing unattended system installations, whether it be server, workstation, or guest systems in a full or para-virtualized setup.

Cobbler has several tools to assist in pre-installation guidance, kickstart file management, installation environment management, and more.

Warning

This section explains supported uses of Cobbler, which include:

Kickstart template creation and management using the Cheetah template engine and Kickstart Snippets
Virtual machine guest installation automation with the koan client-side tool
Installation environment analysis using the cobbler check command
Building installation ISOs with PXE-like menus using the cobbler buildiso command for Satellite systems with x86_64 architecture.

Red Hat supports only those Cobbler functions that are either listed within our formal documentation, exposed within the Satellite Web UI and API, or articles listed in Red Hat Customer Portal under the subject of Supported Cobbler Usage.

3.1.4.1. Cobbler Requirements

To use Cobbler as a PXE boot server, check the following guidelines:

To use Cobbler for system installation with PXE, install and configure the tftp-server package.
To use Cobbler to PXE boot systems for installation, your Satellite server requires either the ability to act as a DHCP server for Cobbler PXE booting or access to your network DHCP server. Edit /etc/dhcp.conf to change next-server to the hostname or IP address of your Cobbler server.
The latest cobbler-loaders package needs to be installed. This is to ensure that the pxelinux.0 boot image is installed and available on the Satellite before PXE booting. To install the latest version:
```
# yum install cobbler-loaders
```

3.1.4.1.1. Configuring Cobbler with DHCP

Cobbler supports bare metal kickstart installation of systems configured to perform network boots using a PXE boot server. To properly implement a Cobbler installation server, administrators need to either have administrative access to the network's DHCP server or implement DHCP on the Cobbler server itself.

Procedure 3.10. Configuring an Existing DHCP Server

If you have a DHCP server deployed on another system on the network, you will need administrative access to the DHCP server in order to to edit the DHCP configuration file so that it points to the Cobbler server and PXE boot image.

Log in as root on the DHCP server.
Edit the /etc/dhcpd.conf file and append a new class with options for performing PXE boot installation. For example:
```
allow booting;
allow bootp;
class "PXE" {
match if substring(option vendor-class-identifier, 0, 9) = "PXEClient";
next-server 192.168.2.1;
filename "pxelinux.0";
}
```
Following each action step-by-step in the above example:
1. The administrator enables network booting with the bootp protocol.
2. The administrator then creates a class called PXE. A system that is configured to have PXE first in its boot priority will identify itself as a PXEClient.
3. The DHCP server directs the system to the Cobbler server at 192.168.2.1.
4. Finally, the DHCP server retrieves the pxelinux.0 bootloader file.

3.1.4.1.2. Configuring Xinetd and TFTP for Cobbler

Xinetd is a daemon that manages a suite of services, including TFTP, the FTP server used for transferring the boot image to a PXE client. To configure TFTP:

Log in as root.
Edit the /etc/xinetd.d/tftp and change the option:
```
disable = yes
```
to
```
disable = no
```

Start the xinetd service:

# chkconfig --level 345 xinetd on
# /sbin/service xinetd start

3.1.4.1.3. Configuring SELinux and IPTables for Cobbler Support

Red Hat Enterprise Linux is installed with SELinux support and a secure firewall. Both are enabled by default. To properly configure a Red Hat Enterprise Linux server to use Cobbler, you must first configure these system and network safeguards to allow connections to and from the Cobbler Server.

Procedure 3.11. Enabling Cobbler Support in SELinux

To enable SELinux for Cobbler support:

Log in as root.
Set the SELinux Boolean to allow HTTPD web service components:
```
# setsebool -P httpd_can_network_connect true
```
The -P switch is essential, as it enables HTTPD connection persistently across all system reboots.

Procedure 3.12. IPTables Configuration

Once SELinux has been configured, configure IPTables to allow incoming and outgoing network traffic on the Cobbler server.

Add the following rules to the existing IPTables firewall rule sets to open the Cobbler-related ports:

For TFTP:

# /sbin/iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 69 -j ACCEPT
# /sbin/iptables -A INPUT -m state --state NEW -m udp -p udp --dport 69 -j ACCEPT

For HTTPD:

# /sbin/iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
# /sbin/iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT

For Cobbler and Koan XMLRPC:

# /sbin/iptables -A INPUT -m state --state NEW -m tcp -p tcp --dport 25151 -j ACCEPT

Save the firewall configuration:

# /sbin/iptables-save > /etc/sysconfig/iptables

3.1.4.2. Configuring Cobbler with /etc/cobbler/settings

Most Cobbler configuration is done within the /etc/cobbler/settings file. The file contains several configurable settings, and offers detailed explanations for each setting regarding how it affects the functionality of Cobbler and whether it is recommended for users to change the setting for their environment.

Most of the settings can be left default and Cobbler will run as intended. For more information about configuring Cobbler settings, consult the /etc/cobbler/settings file, which documents each setting in detail.

3.1.4.3. Syncing and Starting the Cobbler Service

Before starting the cobbler service, run a check on the cobbler service to make sure that all the prerequisites are configured according to the organization's needs:
```
# cobbler check
```
Start the Satellite server with the following command:
```
# /usr/sbin/rhn-satellite start
```
Warning
Do not start or stop the cobblerd service independent of the Satellite service, as doing so may cause errors and other issues.
Always use /usr/sbin/rhn-satellite to start or stop Red Hat Satellite.

3.1.4.4. Adding a Distribution to Cobbler

If all prerequisites have been met and Cobbler is now running, you can now begin adding a distribution to the Cobbler.

Use cobbler to create a distribution with the following syntax:

# cobbler distro add --name=string --kernel=path --initrd=path

The --name=string switch is a label used to differentiate one distro choice from another (for example, rhel5server)

The --kernel=path switch specifies the path to the kernel image file

The --initrd=path switch specifies the path to the initial ramdisk (initrd) image file.

3.1.4.5. Adding a Profile to Cobbler

Once you have added a distribution to Cobbler, you can then add profiles to Cobbler.

Cobbler profiles associate a distribution to additional options, like kickstart files. Profiles are the core unit of provisioning and there must be at least one Cobbler profile for every distribution added. For example, two profiles might be created for a web server and a desktop configuration. While both profiles use the same distro, the profiles are for different installation types.

For information about creating and configuring kickstart profiles from the Red Hat Satellite interface, see Section 3.1.2.3, “Kickstart Profiles”.

Use cobbler to create profiles with the following syntax:

# cobbler profile add --name=string --distro=string [--kickstart=url] [--virt-file-size=gigabytes] [--virt-ram=megabytes]

The --name=string is the unique label for the profile, such as rhel5webserver or rhel4workstation .

The --distro=string switch specifies the distribution that will be used for this particular profile. Distributions were added in Section 3.1.4.4, “Adding a Distribution to Cobbler”.

The --kickstart=url option specifies the location of the kickstart file (if available).

The --virt-file-size=gigabytes option allows you to set the size of the virtual guest file image. The default is 5 gigabytes if left unspecified.

The --virt-ram=megabytes option specifies how many megabytes of physical RAM that a virtual guest system can consume. The default is 512 megabytes if left unspecified.

3.1.4.6. Adding a System to Cobbler

Once the distributions and profiles for Cobbler have been created, add systems to Cobbler. System records map a piece of hardware on a client with the cobbler profile assigned to run on it.

Note

If you are provisioning via koan and PXE menus alone, it is not required to create system records. However, system records are useful when:

System-specific kickstart templating is required
A specific system always receives specific set of content
There is a specific role intended for a specific client

The following command adds a system to the Cobbler configuration:

# cobbler system add --name=string --profile=string --mac-address=AA:BB:CC:DD:EE:FF

The --name=string is the unique label for the system, such as engineeringserver or frontofficeworkstation.

The --profile=string specifies one of the profile names added in Section 3.1.4.5, “Adding a Profile to Cobbler”.

The --mac-address=AA:BB:CC:DD:EE:FF option allows systems with the specified MAC address to automatically be provisioned to the profile associated with the system record if they are being kickstarted.

For more options, such as setting hostname or IP addresses, see the Cobbler manpage by typing man cobbler at a shell prompt.

Important

A system with the name default has a special function. It sets all undefined systems to use a specific profile through PXE. Without a default system, PXE falls to local boot for unconfigured systems. Include only default as the name and the profile, such as:

# cobbler system add --name=default --profile=rhel5webserver

3.1.4.7. Using Cobbler Templates

Within the Red Hat Satellite web interface, there are facilities to create variables for use with kickstart distributions and profiles.

Kickstart variables are a part of an infrastructural change in Satellite to support templating in kickstart files. In the context of kickstart files, templates are files that hold descriptions used to build actual kickstart files, rather than creating specific kickstarts.

These templates are then shared by various profiles and systems that have their own variables and corresponding values. These variables modify the templates and software called a template engine parses the template and variable data into a usable kickstart file. Cobbler uses an advanced template engine called Cheetah that provides support for templates, variables, and snippets.

Advantages of using templates include:

Robust features that allow administrators to create and manage large amounts of profiles or systems without duplication of effort or manually creating kickstarts for every unique situation
While templates can become complex and involve loops, conditionals and other enhanced features and syntax, they can also be used simply to make kickstart files without such complexity

3.1.4.7.1. Using Templates

Kickstart templates can have static values for certain common items such as PXE image filenames, subnet addresses, and common paths such as /etc/sysconfig/network-scripts/. However, where templates differ from standard kickstart files are in their use of variables.

For example, a standard kickstart file may have a networking passage that looks similar to the following:

network --device=eth0 --bootproto=static --ip=192.168.100.24 --netmask=255.255.255.0 --gateway=192.168.100.1 --nameserver=192.168.100.2

However, in a kickstart template file, the networking passage may look similar to the following:

network --device=$net_dev --bootproto=static --ip=$ip_addr --netmask=255.255.255.0 --gateway=$my_gateway --nameserver=$my_nameserver

These variables will be substituted with the values set in your kickstart profile variables or in your system detail variables. If the same variables are defined in both the profile and the system detail, then the system variable takes precedence.

3.1.4.7.2. Kickstart Snippets

If you have common configurations that are the same across all kickstart templates and profiles, you can utilize the Snippets feature of Cobbler to take advantage of code reuse.

Kickstart snippets are sections of kickstart code that can be called by a $SNIPPET() function that will be parsed by Cobbler and substitute that function call with the contents of the snippet.

For example, if you had a common hard drive partition configuration for all servers, such as:

clearpart --all
part /boot --fstype ext3 --size=150 --asprimary
part / --fstype ext3 --size=40000 --asprimary
part swap --recommended

part pv.00 --size=1 --grow

volgroup vg00 pv.00
logvol /var --name=var vgname=vg00 --fstype ext3 --size=5000

You could take that snippet, save it to a file (such as my_partition), and place the file in /var/lib/cobbler/snippets/ so that Cobbler can access it.

You can then use the snippet by using the $SNIPPET() function in your kickstart templates. For example:

$SNIPPET('my_partition')

Wherever you invoke that function, the Cheetah parser will substitute the function with the snippet of code contained in the my_partition file.

3.1.4.8. Using Koan

Whether you are provisioning guests on a virtual machine or reinstalling a new distribution on a running system, koan works in conjunction with Cobbler to provision systems.

3.1.4.8.1. Using Koan to Provision Virtual Systems

If you have created a virtual machine profile as documented in Section 3.1.4.5, “Adding a Profile to Cobbler”, you can use koan to initiate the installation of a virtual guest on a system.

For example, say you've created a Cobbler profile like the following:

# cobbler add profile --name=virtualfileserver --distro=rhel-i386-server-5 --virt-file-size=20 --virt-ram=1000

This profile is for a fileserver running Red Hat Enterprise Linux 5 with a 20GB guest image size and allocated 1GB of system RAM.

To find the name of the virtual guest system profile, run the following with koan:

# koan --server=hostname --list=profiles

This command lists all of the available profiles created with cobbler profile add.

Then, begin the process of creating the image file and starting the installation of the virtual guest system:

# koan --virt --server=cobbler-server.example.com --profile=virtualfileserver --virtname=marketingfileserver

The command specifies that a virtual guest system be created from the Cobbler server (hostname cobbler-server.example.com) using the virtualfileserver profile. The virtname option specifies a label for the virtual guest, which by default is labeled with the system's MAC address.

Once installation of the virtual guest is complete, it can be used as any other virtual guest system.

3.1.4.8.2. Using Koan to Re-install Running Systems

There may be instances where you need to re-install a machine with another operating system while it is still running. koan can help you by destructively replacing a running system with a new installation from the available Cobbler profiles.

To replace a running system and install a new one, run the following command on the system itself:

# koan --replace-self --server=hostname --profile=name

This command, when executed on the running system to be replaced, will start the provisioning process and replace its own system using the profile in --profile=name on the Cobbler server specified in --server=hostname.

3.1.4.9. Building ISOs with Cobbler

Some environments might lack PXE support. To overcome this, the cobbler buildiso command provides functionality to create a boot ISO image containing a set of distributions and kernels, and a menu similar to PXE network installations.

Define the name and output location of the boot ISO using the --iso option.

# cobbler buildiso --iso=/path/to/boot.iso

The boot ISO includes all profiles and systems by default. Limit these profiles and systems using the --profiles and --systems options.

# cobbler buildiso --systems="system1,system2,system3" \
    --profiles="profile1,profile2,profile3"

Note

Building ISOs with the cobbler buildiso command is supported for all architectures except the s390x architecture.

Note

The cobbler buildiso --standalone option is not supported with Red Hat provided kickstart trees. The standalone option is used for provisioning machines that have no network connectivity to the cobbler server, but all of the additional functionality Satellite provisioning provides requires a network connection to the Satellite. If you need to install Red Hat Enterprise Linux on a machine with no network connectivity, install Red Hat Enterprise Linux by downloading the ISO image.

Chapter 3. System Provisioning

3.1. Provisioning Through Red Hat Satellite

3.1.1. Kickstart Explained

3.1.2. Prerequisites

3.1.2.1. Required Packages

3.1.2.2. Kickstart Trees

3.1.2.3. Kickstart Profiles

3.1.2.4. Templating

3.1.2.5. Kickstarting from Bare Metal

3.1.3. Using Activation Keys

3.1.4. Using Cobbler

3.1.4.1. Cobbler Requirements

3.1.4.1.1. Configuring Cobbler with DHCP

3.1.4.1.2. Configuring Xinetd and TFTP for Cobbler

3.1.4.1.3. Configuring SELinux and IPTables for Cobbler Support

3.1.4.2. Configuring Cobbler with /etc/cobbler/settings

3.1.4.3. Syncing and Starting the Cobbler Service

3.1.4.4. Adding a Distribution to Cobbler

3.1.4.5. Adding a Profile to Cobbler

3.1.4.6. Adding a System to Cobbler

3.1.4.7. Using Cobbler Templates

3.1.4.7.1. Using Templates

3.1.4.7.2. Kickstart Snippets

3.1.4.8. Using Koan

3.1.4.8.1. Using Koan to Provision Virtual Systems

3.1.4.8.2. Using Koan to Re-install Running Systems

3.1.4.9. Building ISOs with Cobbler

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

Making open source more inclusive

About Red Hat

Red Hat legal and privacy links

Red Hat legal and privacy links