8 Autoinstallation

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

Some preparation is required for your infrastructure to handle AutoYaST installations. For instance, before creating AutoYaST profiles, you may consider:

While you can schedule a registered system to be installed by AutoYaST with a new operating system and package profile, you can also automatically install a system that is not registered with Uyuni, or does not yet have an operating system installed. One common method of doing this is to create a bootable CD-ROM that is inserted into the target system. When the system is rebooted or switched on, it boots from the CD-ROM, loads the AutoYaST configuration from your Uyuni, and proceeds to install SUSE Linux Enterprise Server according to the AutoYaST profile you have created.

To use the CD-ROM, boot the system and type autoyast at the prompt (assuming you left the label for the AutoYaST boot as autoyast). When you press Enter, the AutoYaST installation begins.

For more information about image creation, refer to KIWI at http://doc.opensuse.org/projects/kiwi/doc/.

In addition to CD-ROM-based installations, AutoYaST installation through a Pre-Boot Execution Environment (PXE) is supported. This is less error-prone than CDs, enables AutoYaST installation from bare metal, and integrates with existing PXE/DHCP environments.

To use this method, make sure your systems have network interface cards (NIC) that support PXE, install and configure a PXE server, ensure DHCP is running, and place the installation repository on an HTTP server for deployment. Finally upload the AutoYaST profile via the Web interface to the Uyuni server. Once the AutoYaST profile has been created, use the URL from the Autoinstallation Overview page, as for CD-ROM-based installations.

To obtain specific instructions for conducting PXE AutoYaST installation, refer to the Using PXE Boot section of the SUSE Linux Enterprise Deployment Guide.

Starting with Section 8.3, “Autoinstallation > Profiles (Kickstart and AutoYaST)”, AutoYaST options available from Systems › Kickstart are described.

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

Some preparation is required for your infrastructure to handle {kickstart}s. For instance, before creating Kickstart profiles, you may consider:

While you can schedule a registered system to be kickstarted to a new operating system and package profile, you can also {kickstart} a system that is not registered with Uyuni or does not yet have an operating system installed. One common method of doing this is to create a bootable CD-ROM that is inserted into the target system. When the system is rebooted, it boots from the CD-ROM, loads the {kickstart} configuration from your Uyuni, and proceeds to install Red Hat Enterprise Linux according to the Kickstart profile you have created.

To do this, copy the contents of /isolinux from the first CD-ROM of the target distribution. Then edit the isolinux.cfg file to default to 'ks'. Change the 'ks' section to the following template:

label ks
kernel vmlinuz
  append text ks=`url`initrd=initrd.img lang= devfs=nomount \
    ramdisk_size=16438`ksdevice`

IP address-based {kickstart} URLs will look like this:

http://`my.manager.server`/kickstart/ks/mode/ip_range

The {kickstart} distribution defined via the IP range should match the distribution from which you are building, or errors will occur. ksdevice is optional, but looks like:

ksdevice=eth0

It is possible to change the distribution for a Kickstart profile within a family, such as Red Hat Enterprise Linux AS 4 to Red Hat Enterprise Linux ES 4, by specifying the new distribution label. Note that you cannot move between versions (4 to 5) or between updates (U1 to U2).

Next, customize isolinux.cfg further for your needs by adding multiple Kickstart options, different boot messages, shorter timeout periods, etc.

Next, create the ISO as described in the Making an Installation Boot CD-ROM section of the Red Hat Enterprise Linux Installation Guide. Alternatively, issue the command:

mkisofs -o file.iso -b isolinux.bin -c boot.cat -no-emul-boot \
  -boot-load-size 4 -boot-info-table -R -J -v -T isolinux/

Note that isolinux/ is the relative path to the directory containing the modified isolinux files copied from the distribution CD, while file.iso is the output ISO file, which is placed into the current directory.

Burn the ISO to CD-ROM and insert the disc. Boot the system and type "ks" at the prompt (assuming you left the label for the Kickstart boot as 'ks'). When you press Enter, Kickstart starts running.

In addition to CD-ROM-based installs, Kickstart supports a Pre-Boot Execution Environment (PXE). This is less error-prone than CDs, enables kickstarting from bare metal, and integrates with existing PXE/DHCP environments.

To use this method, make sure your systems have network interface cards (NIC) that support PXE. Install and configure a PXE server and ensure DHCP is running. Then place the appropriate files on an HTTP server for deployment. Once the {kickstart} profile has been created, use the URL from the Kickstart Details page, as for CD-ROM-based installs.

To obtain specific instructions for conducting PXE {kickstart}s, refer to the PXE Network Installations chapter of the Red Hat Enterprise Linux 4 System Administration Guide.

Note

Running the Network Booting Tool, as described in the Red Hat Enterprise Linux 4: System Administration Guide, select "HTTP" as the protocol and include the domain name of the Uyuni in the Server field if you intend to use it to distribute the installation files.

The following sections describe the autoinstallation options available from the Systems › Autoinstallation page.

Click on the Create Kickstart Profile link from the Main Menu › Systems › Autoinstallation page to start the wizard that populates the base values needed for a Kickstart profile.

Depending on your base channel, your newly created Kickstart profile might be subscribed to a channel that is missing required packages. For {kickstart} to work properly, the following packages should be present in its base channel: pyOpenSSL, rhnlib, libxml2-python, and spacewalk-koan and associated packages.

To resolve this issue:

The final stage of the wizard presents the Autoinstallation Details › Details tab. On this tab and the other subtabs, nearly every option for the new Kickstart profile can be customized.

Once created, you can access the Kickstart profile by downloading it from the Autoinstallation Details page by clicking the Autoinstallation File subtab and clicking the Download Autoinstallation File link.

If the Kickstart file is not managed by Uyuni, you can access it via the following URL:

http://`my.manager.server`/ks/dist/ks-rhel-`ARCH`-`VARIANT`-`VERSION`

In the above example, ARCH is the architecture of the Kickstart file, VARIANT is either client or server, and VERSION is the release of Red Hat Enterprise Linux associated with the Kickstart file.

The following sections describe the options available on each subtab.

8.3.1.1 Autoinstallation Details > Details #

On the Autoinstallation Details › Details page, you have the following options:

• Change the profile Label.

• Change the operating system by clicking (Change).

• Change the Virtualization Type.

  

  Note

  Changing the Virtualization Type may require changes to the Kickstart profile bootloader and partition options, potentially overwriting user customizations. Consult the Partitioning tab to verify any new or changed settings.

• Change the amount of Virtual Memory (in Megabytes of RAM) allocated to virtual guests autoinstalled with this profile.

• Change the number of Virtual CPUs for each virtual guest.

• Change the Virtual Storage Path from the default in /var/lib/xen/ .

• Change the amount of Virtual Disk Space (in GB) allotted to each virtual guest.

• Change the Virtual Bridge for networking of the virtual guest.

• Deactivate the profile so that it cannot be used to schedule a {kickstart} by removing the Active check mark.

• Check whether to enable logging for custom %post scripts to the /root/ks-post.log file.

• Decide whether to enable logging for custom %pre scripts to the /root/ks-pre.log file.

• Choose whether to preserve the ks.cfg file and all %include fragments to the /root/ directory of all systems autoinstalled with this profile.

• Select whether this profile is the default for all of your organization’s {kickstart}s by checking or unchecking the box.

• Add any Kernel Options in the corresponding text box.

• Add any Post Kernel Options in the corresponding text box.

• Enter comments that are useful to you in distinguishing this profile from others.

8.3.1.3 Autoinstallation Details > Variables #

Autoinstallation variables can substitute values in Kickstart and AutoYaST profiles. To define a variable, create a name-value pair (name/value) in the text box.

For example, if you want to autoinstall a system that joins the network of a specified organization (for example the Engineering department), you can create a profile variable to set the IP address and the gateway server address to a variable that any system using that profile will use. Add the following line to the Variables text box.

IPADDR=192.168.0.28
GATEWAY=192.168.0.1

Now you can use the name of the variable in the profile instead of a specific value. For example, the network part of a Kickstart file looks like the following:

network --bootproto=static --device=eth0 --onboot=on --ip=$IPADDR \
  --gateway=$GATEWAY

The $IPADDR will be resolved to 192.168.0.28, and the $GATEWAY to 192.168.0.1

Note

There is a hierarchy when creating and using variables in Kickstart files. System Kickstart variables take precedence over Profile variables, which in turn take precedence over Distribution variables. Understanding this hierarchy can alleviate confusion when using variables in {kickstart}s.

Using variables are just one part of the larger Cobbler infrastructure for creating templates that can be shared between multiple profiles and systems. For more information about Cobbler and templates, refer to Chapter 10, Cobbler.

8.3.1.8 System Details › Details #

Displays subtabs that are available from the System Details tab.

On the System Details › Details page, you have the following options:

• Select between DHCP and static IP, depending on your network.

• Choose the level of SELinux that is configured on kickstarted systems.

• Enable configuration management or remote command execution on kickstarted systems.

• Change the root password associated with this profile.

partition /boot --fstype=ext3 --size=200
partition swap --size=2000
partition pv.01 --size=1000 --grow
volgroup myvg pv.01 logvol / --vgname=myvg --name=rootvol --size=1000 --grow

8.3.1.12 System Details > GPG & SSL #

From this subtab, select the GPG keys and/or SSL certificates to be exported to the kickstarted system during the %post section of the {kickstart}. For Uyuni customers, this list includes the SSL Certificate used during the installation of Uyuni.

Note

Any GPG key you wish to export to the kickstarted system must be in ASCII rather than binary format.

8.3.1.14 Software > Package Groups #

The image above shows subtabs that are available from the Software tab.

Enter the package groups, such as @office or @admin-tools you would like to install on the kickstarted system in the large text box. If you would like to know what package groups are available, and what packages they contain, refer to the RedHat/base/ file of your Kickstart tree.

8.3.1.16 Activation Keys #

Figure 8.2: Activation Keys #

The Activation Keys tab allows you to select Activation Keys to include as part of the Kickstart profile. These keys, which must be created before the Kickstart profile, will be used when re-registering kickstarted systems.

8.3.1.17 Scripts #

Figure 8.3: Scripts #

The Scripts tab is where %pre and %post scripts are created. This page lists any scripts that have already been created for this Kickstart profile. To create a Kickstart script, perform the following procedure:

1. Click the add new kickstart script link in the upper right corner.

2. Enter the path to the scripting language used to create the script, such as /usr/bin/perl.

3. Enter the full script in the large text box.

4. Indicate whether this script is to be executed in the %pre or %post section of the Kickstart process.

5. Indicate whether this script is to run outside of the chroot environment. Refer to the Post-installation Script section of the Red Hat Enterprise Linux System Administration Guide for further explanation of the nochroot option.

Note

Uyuni supports the inclusion of separate files within the Partition Details section of the Kickstart profile. For instance, you may dynamically generate a partition file based on the machine type and number of disks at {kickstart} time. This file can be created via %pre script and placed on the system, such as /tmp/part-include. Then you can call for that file by entering the following line in the Partition Details field of the System Details › Partitioning tab:

%include /tmp/part-include

8.3.1.18 Autoinstallation File #

Figure 8.4: Autoinstallation File #

The Autoinstallation File tab allows you to view or download the profile that has been generated from the options chosen in the previous tabs.

Click the Upload Kickstart/Autoyast File link from the Systems › Autoinstallation page to upload an externally prepared AutoYaST or Kickstart profile.

Once done, four subtabs are available:

Autoinstallation variables can be used to substitute values into Kickstart and AutoYaST profiles. To define a variable, create a name-value pair (name/value) in the text box.

For example, if you want to autoinstall a system that joins the network of a specified organization (for example the Engineering department) you can create a profile variable to set the IP address and the gateway server address to a variable that any system using that profile will use. Add the following line to the Variables text box.

IPADDR=192.168.0.28
GATEWAY=192.168.0.1

To use the distribution variable, use the name of the variable in the profile to substitute the value. For example, the network part of a {kickstart} file looks like the following:

network --bootproto=static --device=eth0 --onboot=on --ip=$IPADDR \
  --gateway=$GATEWAY

The $IPADDR will be resolved to 192.168.0.28, and the $GATEWAY to 192.168.0.1.

Note

There is a hierarchy when creating and using variables in Kickstart files. System Kickstart variables take precedence over Profile variables, which in turn take precedence over Distribution variables. Understanding this hierarchy can alleviate confusion when using variables in {kickstart}s.

In AutoYaST profiles you can use such variables as well.

Using variables are just one part of the larger Cobbler infrastructure for creating templates that can be shared between multiple profiles and systems. For more information about Cobbler and templates, refer to Chapter 10, Cobbler.

Default snippets coming with Uyuni are not editable. You can use a snippet, if you add the Snippet Macro statement such as $SNIPPET('spacewalk/sles_register_script') to your autoinstallation profile. This is an AutoYaST profile example:

<init-scripts config:type="list">
  $SNIPPET('spacewalk/sles_register_script')
</init-scripts>

When you create a snippet with the Create Snippet link, all profiles including that snippet will be updated accordingly.

This is the tab with custom snippets. Click a name of a snippet to view, edit, or delete it.

q The All Snippets tab lists default and custom snippets together.

After selecting Create › VMware-based enter the location of your VMware-based virtual host. Enter a Label, Hostname, Port, Username and Password. Finally click the Add Virtual Host Manager button. For detailed information on working with a VMware-based Virtual Host Manager, see Chapter 12, Inventorying vCenter/vSphere ESXi Hosts with Uyuni.

In a VMWare environment where direct connection to the SUSE Manager Server is not possible, a JSON file can be exported from the ESXi or vSphere host and later imported into Uyuni via this option.

After selecting Create › File-Based enter a label and URL leading to the location of this file.

Note: VMWare vCenter Installations without Direct Access

The file-based is not meant to be used with manually crafted files. It only meant to be used with the output of virtual-host-gatherer against some other module. File-based is suitable for VMWare vCenter installations for which no direct API access is possible from the SUSE Manager Server.

The solution is to run virtual-host-gatherer from somewhere else in the network and save the produced JSON data for further processing.

The following JSON data is an example of the exported information in the file:

{
    "examplevhost": {
        "10.11.12.13": {
            "cpuArch": "x86_64",
            "cpuDescription": "AMD Opteron(tm) Processor 4386",
            "cpuMhz": 3092.212727,
            "cpuVendor": "amd",
            "hostIdentifier": "'vim.HostSystem:host-182'",
            "name": "11.11.12.13",
            "os": "VMware ESXi",
            "osVersion": "5.5.0",
            "ramMb": 65512,
            "totalCpuCores": 16,
            "totalCpuSockets": 2,
            "totalCpuThreads": 16,
            "type": "vmware",
            "vms": {
                "vCenter": "564d6d90-459c-2256-8f39-3cb2bd24b7b0"
            }
        },
        "10.11.12.14": {
            "cpuArch": "x86_64",
            "cpuDescription": "AMD Opteron(tm) Processor 4386",
            "cpuMhz": 3092.212639,
            "cpuVendor": "amd",
            "hostIdentifier": "'vim.HostSystem:host-183'",
            "name": "10.11.12.14",
            "os": "VMware ESXi",
            "osVersion": "5.5.0",
            "ramMb": 65512,
            "totalCpuCores": 16,
            "totalCpuSockets": 2,
            "totalCpuThreads": 16,
            "type": "vmware",
            "vms": {
                "49737e0a-c9e6-4ceb-aef8-6a9452f67cb5": "4230c60f-3f98-2a65-f7c3-600b26b79c22",
                "5a2e4e63-a957-426b-bfa8-4169302e4fdb": "42307b15-1618-0595-01f2-427ffcddd88e",
                "NSX-gateway": "4230d43e-aafe-38ba-5a9e-3cb67c03a16a",
                "NSX-l3gateway": "4230b00f-0b21-0e9d-dfde-6c7b06909d5f",
                "NSX-service": "4230e924-b714-198b-348b-25de01482fd9"
            }
        }
    }
}

For more information, see the man page on your Uyuni server for virtual-host-gatherer:

{prompt.user}man virtual-host-gatherer

The README file coming with the package provides background information about the type of a hypervisor, etc.:

/usr/share/doc/packages/virtual-host-gatherer/README.md

The following APIs allow you to get a list of available virtual-host-manager modules and the parameters they require:

The following APIs allow you to create and delete VHMs. The module parameter map must match the map returned by virtualhostmanager.getModuleParameters to work correctly:

The following APIs return information about configured VHMs: