10 Cobbler

Cobbler configuration is mainly done in the /etc/cobbler/settings file. With the default settings unchanged, Cobbler runs as intended. All configurable settings are explained in detail in the /etc/cobbler/settings file with regard to how they affect functionality of Cobbler and whether it is recommended for users to adjust values to their environment.

Note: Supported Languages

If SUSE Manager complains about language “en” was not found within the list of supported languages available at /usr/share/YaST2/data/languages, remove the lang in /etc/cobbler/settings or add a proper value such as en_US.

For background info, see https://www.suse.com/support/kb/doc?id=7018334.

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 set up DHCP on the Cobbler server itself.

allow booting;
allow bootp; 1
class "PXE" 2
{match if substring(option vendor-class-identifier, 0, 9) = "PXEClient"; 3
next-server 192.168.2.1; 4
filename "pxelinux.0";} 5

<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'/> 1
</dhcp>
  </ip>
</network>

SUSE Manager uses the atftpd daemon, but it can also operate with Xinetd/TFTP. The atftpd is installed by default as 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 file as root and change the disable = yes line to disable = no.

Before TFTP can serve the pxelinux.0 boot image, you must start the Xinetd service. Start YaST and use System › Services Manager to configure the Xinetd daemon.

It is possible to sync cobbler generated TFTP contents to SUSE Manager Proxies to perform PXE booting via these proxies.

zypper install susemanager-tftpsync

zypper install susemanager-tftpsync-recv

10.2.4.3 Configuring SUSE Manager Server #

As root execute configure-tftpsync.sh on SUSE Manager Server:

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

Execute cobbler sync to initially push the files to the proxy systems. This will succeed if all listed proxies are properly configured.

Note: Changing the List of Proxy Systems

You can call configure-tftpsync.sh to change the list of proxy systems. You must always provide the full list of proxy systems.

Note: Reinstalling a Configured Proxy

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

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 with the cobbler check command.

If content, start the SUSE Manager server with the following command:

/usr/sbin/spacewalk-service start

Warning

Do not start or stop the cobblerd service independent of the SUSE Manager service. Doing so may cause errors and other issues.

Always use /usr/sbin/spacewalk-service to start or stop SUSE Manager.

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 may have a networking section 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

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

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 detail variable takes precedence.

Note

The template for the autoinstallation has syntax rules, using punctuation symbols. To avoid clashes, they need to be properly treated.

In case the autoinstallation scenario contains any shell script using variables like $(example), its content should be escaped by using the backslash symbol: \$(example).

If the variable named example is defined in the autoinstallation snippet, the templating engine will evaluate $example with its content. If there is no such variable, the content will be left unchanged. Escaping the $ symbol will prevent the templating engine to perform its evaluation 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

Also, pay attention to similar scenarios like the following:

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

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

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

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

If you have common configurations across all Kickstart templates and profiles, you can use 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 substituted with the contents of the snippet.

For example, you might have 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

Save this snippet of the configuration to a file like my_partition and place the 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')

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

If you have created a virtual machine profile as documented in Section 10.4, “Adding a Profile to Cobbler”, you can use koan to initiate the installation of a virtual guest on a system. For example, create a Cobbler profile with the following command:

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

This profile is for a fileserver running SUSE Linux Enterprise Server  12 with a 20 GB guest image size and allocated 1 GB of system RAM. To find the name of the virtual guest system profile, run the following koan command:

koan --server=hostname --list-profiles

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

Start creating the image file and 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 the system’s MAC address.

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

koan can replace a still running system with a new installation from the available Cobbler profiles by executing the following command on the system to be reinstalled:

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

This command, running on the 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.