## Chapter 6. Cobbler¶

SUSE Manager features the Cobbler server that allows administrators to centralize their system installation and provisioning infrastructure. Cobbler is an installation server that collects the 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, automated installation file management, installation environment management, and more. Features of Cobbler include:

- Installation environment analysis using the cobbler check command

- Multi-site installation server configuration with cobbler replicate

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

## 6.1. Cobbler Requirements¶

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

- If you plan to use Cobbler to install systems using PXE, you must have `tftp-server` installed and configured.

- If you plan to use Cobbler to PXE boot systems for installation, you must have either the ability to act as a DHCP server for Cobbler PXE booting or access to your network DHCP server `/etc/dhcp.conf` to change `next-server` to the hostname or IP address of your Cobbler server.

### 6.1.1. Configuring Cobbler with /etc/cobbler/settings¶

Cobbler configuration is mainly 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.

### 6.1.2. Cobbler and DHCP¶

Cobbler supports bare-metal automated 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.

#### 6.1.2.1. 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.

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

Follow each action step-by-step in the above example:

1. Enable as administrator network booting with the `bootp` protocol.

2. Create as administrator a class called `PXE`. A system that is configured to have PXE first in its boot priority, identifies itself as `PXEClient`.

   You get the following results:

   - The DHCP server then directs the system to the Cobbler server at 192.168.2.1.

   - Finally, the DHCP server retrieves the `pxelinux.0` bootloader file.

### 6.1.3. Xinetd and TFTP¶

SUSE Manager uses the `atftpd` daemon, but it can also operated with Xinetd/TFTP. The `atftpd` is installed per default and the recommended method for providing PXE services. Usually you do not have to change its configuration, but if you have to, use the YaST Sysconfig Editor.

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, you must first enable the service via Xinetd. To do this, edit the `/etc/xinetd.d/tftp` as root and change the `disable = yes` line to `disable = no`.

Before TFTP can start serving the `pxelinux.0` boot image, you must start the Xinetd service. Start YaST and use System Services+Run Level to configure the Xinetd daemon.

### 6.1.4. Syncing and Starting the Cobbler Service¶

Once all the prerequisites specified in cobbler check are configured to your needs, you can now start the Cobbler service.

Start the SUSE Manager server with the following command:

    /usr/sbin/spacewalk-service start

Do not start or stop the cobblerd service independent of the SUSE Manager service, as doing so may cause errors and other issues. Always use /usr/sbin/spacewalk-service to start or stop SUSE Manager.

## 6.2. Adding a Distribution to Cobbler¶

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

For information about creating and configuring AutoYaST/Kickstart distributions from the SUSE Manager interface, refer to Section 3.4.9.8, “Autoinstallation+Distributions — [Prov]”.

Using cobbler to create a distribution from the command line is as follows:

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

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

The `--kernel=`path`` option specifies the path to the kernel image file

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

## 6.3. Adding a Profile to Cobbler¶

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

Cobbler profiles associate a distribution to additional options, like AutoYaST/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 and AutoYaST profiles from the SUSE Manager interface, refer to Section 3.4.9.3, “Autoinstallation Profiles (Kickstart and AutoYaST)”.

The usage of cobbler to create profiles from the command line is as follows:

    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 `sles11webserver` or `sles11workstation`.

The `--distro=`string`` option specifes the distribution that will be used for this particular profile. Distributions were added in Section 6.2, “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.

## 6.4. Adding a System to Cobbler¶

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

If you are provisioning via koan and PXE menus alone, it is not required to create system records, though they are useful when system-specific Kickstart templating is required or to establish that a specific system should always recieve a specific content installed. If there is a specific role inteded for a specified client, system records should be created for it.

For information about creating and configuring automated installation from the SUSE Manager interface, refer to Section 3.4.2.9.4, “System Details+Provisioning — [Prov]”.

The following command adds a system to the Cobbler configuration:

    cobbler system add --name=string --profile=string --mac=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 6.3, “Adding a Profile to Cobbler”.

The `--mac=`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 installed.

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

## 6.5. Cobbler Templates¶

Within the SUSE Manager web interface, there are facilities to create variables for use with Kickstart distributions and profiles. For example, to create a Kickstart profile variable, refer to Section 3.4.9.4.3, “Autoinstallation Details+Variables”.

Kickstart variables are a part of an infrastructural change in SUSE Manager 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, it can also be used simply to make Kickstart files without such complexity.

### 6.5.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 there are the same variables defined in both the profile and the system detail, then the system variable takes precedence.

For more information about Kickstart templates, refer to the Cobbler project page at the following URL:

https://fedorahosted.org/cobbler/wiki/KickstartTemplating

### 6.5.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 them.

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.

For more information about Kickstart snippets, refer to the Cobbler project page at the following URL:

https://fedorahosted.org/cobbler/wiki/KickstartSnippets

## 6.6. Using Koan¶

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

### 6.6.1. Using Koan to Provision Virtual Systems¶

If you have created a virtual machine profile as documented in Section 6.3, “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 such as the following:

    cobbler add profile --name=virtualfileserver --distro=sless11-x86_64-server --virt-file-size=20 --virt-ram=1000

This profile is for a fileserver running SUSE Linux Enterprise Server 11 with a 20GB guest image size and alloted 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.

### 6.6.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`.