Cobbler

Cobbler is an installation server that allows you to perform unattended system installations. It can be used on server, client, or guest systems, and in virtual environments.

This section explains the Cobbler features most commonly used with SUSE Manager:

  • Installation environment analysis using the cobbler check command

  • Multi-site installation server configuration using the cobbler replicate command

  • Virtual machine guest installation automation with the koan client-side tool

  • Building installation ISOs with PXE-like menus using the cobbler buildiso command (for SUSE Manager systems with x86_64 architecture)

For more detailed Cobbler documentation, see http://cobbler.github.io/manuals/.

SUSE only supports Cobbler functions that are available in the SUSE Manager Web UI, or through the SUSE Manager API. All features documented here are supported.

Cobbler is not currently supported within SUSE Manager for Retail environments. If you intend to use your installation with SUSE Manager for Retail formulas, do not configure Cobbler.

Cobbler Requirements

To use Cobbler for system installation with PXE, you will require a TFTP server. SUSE Manager installs a TFTP server by default. To PXE boot systems, you will require a DHCP server, or have access to a network DHCP server. Edit the /etc/dhcp.conf configuration file to change next-server to the hostname or IP address of your Cobbler server.

Cobbler requires an open HTTP port to synchronize data between the Server and the Proxy. By default, Cobbler uses port 80, but you can configure it to use port 443 instead if that suits your environment.

Cobbler uses host names as a unique key for each system. If you are using the pxe-default-image to onboard bare metal systems, make sure every system has a unique host name. Non-unique host names will cause all systems with the same host name to have the configuration files overwritten when a provisioning profile is assigned.

Configure Cobbler

Cobbler configuration is primarily managed using the /etc/cobbler/settings file. Cobbler will run with the default settings unchanged. All configurable settings are explained in detail in the /etc/cobbler/settings file, including information on each setting, and recommendations.

Cobbler uses DHCP to automate bare metal installations from a PXE boot server. You must have administrative access to the network’s DHCP server, or be able to configure DHCP directly on the the Cobbler server.

If you have an existing DHCP server, you will need to edit the DHCP configuration file so that it points to the Cobbler server and PXE boot image.

Procedure: Configuring DHCP for Cobbler

  1. On the DHCP server, as root, open the /etc/dhcpd.conf file.

  2. 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";}

    This example:

    • Enables the bootp protocol for network booting.

    • Creates a class called PXE.

    • Identifies systems as PXEClient if they are configured with PXE as the first boot priority.

    • Directs PXEClients to the Cobbler server at 192.168.2.1.

    • Retrieves the pxelinux.0bootloader file.

  3. Save the file.

Procedure: Configuring PXE Boot in KVM

While it is possible to use KVM with PXE booting, it can be unreliable. We do not recommend you use this on production systems.

  1. Use the virsh command to produce a dump of the current network XML description:

    virsh net-dumpxml --inactive network > network.xml

  2. Open the XML dump file at network.xml and add a bootp parameter within the <dhcp>` element:

    <bootp file='/pxelinux.0' server='192.168.100.153'/>

  3. Use the virsh command to install the updated description:

    virsh net-define network.xml

    Alternatively, you can use the net-edit subcommand, which will also perform some error checking.

Example: Minimal Network XML Description for KVM
<network>
  <name>default</name>
  <uuid>1da84185-31b5-4c8b-9ee2-a7f5ba39a7ee</uuid>
  <forward mode='nat'>
    <nat>
      <port start='1024' end='65535'/>
    </nat>
  </forward>
  <bridge name='virbr0' stp='on' delay='0'/>
  <mac address='52:54:00:29:59:18'/>
  <domain name='default'/>
  <ip address='192.168.100.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.100.128' end='192.168.100.254'/>
      <bootp file='/pxelinux.0' server='192.168.100.153'/>
    </dhcp>
  </ip>
</network>

TFTP

SUSE Manager uses the tftp daemon. The tftp daemon is the recommended method for PXE services, and is installed by default. The default configuration works in most cases. However, if you need to change the configuration, use the YaST Services Manager.

The TFTP service must be running so it can serve the pxelinux.0 boot image. Start YaST and use System  Services Manager to configure the tftp daemon.

You can also synchronize Cobbler-generated TFTP contents to a SUSE Manager Proxy.

Procedure: Installing TFTP

  1. On the SUSE Manager Server, as root, install the susemanager-tftpsync package:

    zypper install susemanager-tftpsync

  2. On the SUSE Manager Proxy, as root user, install the susemanager-tftpsync-recv package:

    zypper install susemanager-tftpsync-recv
Procedure: Configuring TFTP on a Proxy

  1. On the SUSE Manager Proxy, as root, run the configure-tftpsync.sh script.

  2. The script will interactively ask you for details on the host names and IP addresses of the SUSE Manager Server and Proxy, as well for the location of the tftpboot directory on the Proxy.

For more information, use the configure-tftpsync.sh --help command.

Procedure: Configuring TFTP on a Server

  1. On the SUSE Manager Server, as root, run the configure-tftpsync.sh script.

    configure-tftpsync.sh proxy1.example.com proxy2.example.com

  2. Run the cobbler sync command to push the files to the proxy. This will fail if you have not configured the proxies correctly.

  3. If you want to change the list of proxies later on, you can use the configure-tftpsync.sh script to edit them.

If you reinstall an already configured proxy and want to push all the files again, you must remove the cache file at /var/lib/cobbler/pxe_cache.json before you call cobbler sync.

Synchronize and Start the Cobbler Service

The SUSE Manager Server must be able to access the SUSE Manager Proxy systems directly. You cannot push using a proxy.

Do not start or stop the cobblerd service independent of the SUSE Manager service. Doing so can cause errors. Always use /usr/sbin/spacewalk-service to start or stop SUSE Manager.

Check that all the prerequisites the Cobbler service requires, are configured according to your requirements. You can do this by running the cobbler check command.

When you had to change the configuration, restart the SUSE Manager service:

/usr/sbin/spacewalk-service restart

Kickstart Templates

Kickstart files are used to automate Red Hat Enterprise Linux client installations. Kickstart templates are used to describe how to create Kickstart files. To help with creating Kickstart templates, you can create Kickstart variables within the SUSE Manager Web UI. This allows you to create and manage large numbers of profiles and systems, without having to manually create Kickstart files for each.

Kickstart templates are shared by various profiles and systems that can each have their own variables and values. These variables modify the templates, and a template engine parses the template and variables into a usable Kickstart file.

Cobbler uses a template engine called Cheetah that provides support for templates, variables, and snippets.

For more information on creating Kickstart profile variables, see reference:systems/autoinst-distributions.adoc.

Kickstart Template Syntax

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

For example, a standard Kickstart file might have a networking section like this:

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

In a Kickstart template file, the networking section would look like this instead:

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

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

Kickstart templates use syntax rules that rely on punctuation symbols. To avoid clashes, they need to be properly treated.

If the template contains shell script variables like $(example), the content needs to be escaped with a backslash: \$(example). If the variable is defined in the template, the templating engine will evaluate it correctly. If there is no such variable, the content will be left unchanged. Escaping the $ symbol will prevent the templating engine from evaluating the symbol as an internal variable.

Long scripts or strings can be escaped by wrapping them with the \#raw and \#end raw directives. For example:

#raw
#!/bin/bash
for i in {0..2}; do
 echo "$i - Hello World!"
done
#end raw

Any line with a # symbol followed by a whitespace is treated as a comment and is therefore not evaluated. For example:

#start some section (this is a comment)
echo "Hello, world"
#end some section (this is a comment)

For more information about Kickstart templates and Cobbler, see https://cobbler.github.io/manuals/2.8.0/3/5_-_Kickstart_Templating.html.

Kickstart Snippets

Kickstart snippets are sections of Kickstart code that can be called by a $SNIPPET() function. The snippet is parsed by Cobbler and substituted with the contents of the snippet.

This example sets up a snippet for a common hard drive partition configuration:

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

Save this snippet of the configuration to a file in /var/lib/cobbler/snippets/, where Cobbler can access it.

Use the snippet by calling the $SNIPPET() function in your Kickstart templates. For example:

$SNIPPET('my_partition')

Cobbler will parse the function with the snippet of code contained in the my_partition file.

Build ISOs with Cobbler

Cobbler can create ISO boot images that contain a set of distributions, kernels, and a menu, that work similar to a PXE installation.

Building ISOs with Cobbler is not supported on IBM Z.

The Cobbler buildiso command takes parameters to define the name and output location of the boot ISO. For example:

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

The boot ISO includes all profiles and systems by default. You can limit which profiles and systems are used, with the --profiles and --systems options. For example:

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

If you cannot write an ISO image to a public tmp directory, check your systemd settings in /usr/lib/systemd/system/cobblerd.service.

Bare Metal Provisioning

Systems that have not yet been provisioned are called bare metal systems. You can provision bare metal systems using Cobbler. Once a bare metal system has been provisioned in this way, it will appear in the Systems list, where you can perform regular provisioning with autoinstallation, for a completely unattended installation.

To successfully provision a bare metal system, you will require a fully patched SUSE Manager server.

The system to be provisioned must have x86_64 architecture, with at least 2 GB RAM, and be capable of PXE booting.

The server uses TFTP to provision the bare metal client, so the appropriate port and networks must be configured correctly in order for provisioning to be successful. In particular, ensure that you have a DHCP server, and have set the next-server parameter to the SUSE Manager server IP address or hostname.

Enable Bare Metal Systems Management

Bare metal systems management can be enabled or disabled in the SUSE Manager Web UI by navigating to Admin  SUSE Manager Configuration  Bare-metal systems.

New systems are added to the organization of the administrator who enabled the bare metal systems management feature. To change the organization, log in as an Administrator of the required organization, and re-enable the feature.

When the feature has been enabled, any bare metal system connected to the server network will be automatically added to the organization when it is powered on. The process can take a few minutes, and the system will automatically shut down once it is complete. After the reboot, the system will appear in the Systems list. Click on the name of the system to see basic information, or go to the Properties, Notes, and Hardware tabs for more details. You can migrate bare metal systems to other organizations if required, using the Migrate tab.

Provision Bare Metal Systems

Provisioning bare metal systems is similar to provisioning other systems, and can be done using the Provisioning tab. However, you will not be able to schedule provisioning, it will happen automatically as soon as the system is configured and powered on.

System Set Manager can be used with bare metal systems. However, not all SSM features are available, because bare metal systems do not have an operating system installed. This also applies to mixed sets that contain bare metal systems. All features will be re-enabled if the bare metal systems are removed from the set.