Cobbler

Cobbler is an installation server that allows you to perform unattended system installations. Cobbler is installed on the SUSE Manager Server.

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

If you intend to use your installation with for Retail formulas, do not follow this guide to configure Cobbler on the branch server. In for Retail installations, the TFTPD formula manages these settings. For more information about the TFTPD formula, see salt:formula-tftpd.adoc.

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

  • The cobbler sync command is triggered from SUSE Manager Server and generate the TFTP boot environment

  • Installation environment analysis using the cobbler check 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 information about Cobbler, see https://cobbler.readthedocs.io.

Cobbler Requirements

To use Cobbler for system installation with PXE, you require a TFTP server. SUSE Manager installs a TFTP server by default. To PXE boot systems, you require a DHCP server, or have access to a network DHCP server.

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 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 runs with the default settings unchanged. All configurable settings are explained in detail in the /etc/cobbler/settings file.

The PXE boot process uses DHCP to find the TFTP boot server. The SUSE Manager Server can act as such a TFTP boot server and Cobbler can generate the content for it. You must have administrative access to the network’s DHCP server. Edit the DHCP configuration file so that it points to the SUSE Manager Server as the TFTP boot server:

Procedure: Example for Configuring the ISC DHCP Server

  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.

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

Procedure: Configuring PXE Boot in KVM

  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 also performs 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. For synchronization, HTTPS port 443 must be open.

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 interactively asks 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 fails 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.

Background Information about the Synchronization Process

A cobbler sync is a rebuild of every file Cobbler touched. On SUSE Manager, cobbler sync does the following actions:

  1. Run pre-sync triggers. This can be any number of shell scripts.

  2. Delete all files and directories that are not allowed in /srv/www/cobbler/.

  3. Create all needed directories.

  4. Delete all elements inside the directories.

  5. Create the TFTPD directory.

  6. Write the DHCP files if management is enabled (unsupported). For more information, see Configure Cobbler.

  7. Do the same with DNS (unsupported).

  8. Clean up the cache.

  9. Run rsync if rsync management is enabled.

  10. Run post-sync triggers. This can be any number of shell scripts (unsupported).

SUSE Manager also adds or removes, or edits systems that are in Cobbler. Those actions trigger a so-called lite sync process. This sync only touches files and directories that are related to the change which triggered it.

If you have created Cobbler profiles, distributions, or systems using the SUSE Manager Web UI, you must manage them in the Web UI. If you make changes at the command prompt, the profiles do not synchronize correctly, and the Web UI shows incorrect values.

Synchronize and Start the Cobbler Service

When tftpsync is configured, the SUSE Manager Server must be able to access the SUSE Manager Proxy systems directly.

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

Autoinstallation Templates

AutoYaST or Kickstart profiles are used to automate SUSE Linux Enterprise or Red Hat Enterprise Linux client installations. Templates are used to describe how to create autoinstallation profiles. You can create autoinstallation 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 profiles for each.

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

For more information on creating profiles, 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 evaluates it correctly. If there is no such variable, the content is left unchanged. Escaping the $ symbol prevents 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)

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 parses 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 appears 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 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 is automatically added to the organization when it is powered on. The process can take a few minutes, and the system automatically shuts down when it is complete. The system is now visible in the Systems  System list. Click on the name of the system to see basic information. For more details, go to the Properties, Notes, and Hardware tabs. 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 cannot schedule provisioning, it happens 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 are re-enabled if the bare metal systems are removed from the set.