Skip to content

Latest commit

 

History

History
150 lines (106 loc) · 5.56 KB

cobbler-migration.txt

File metadata and controls

150 lines (106 loc) · 5.56 KB
Raw

% Cobbler migration

As of version 0.9, Beaker no longer relies on Cobbler for provisioning systems. A new lab controller daemon, beaker-provision, executes power commands and manages the TFTP root. Kickstarts are generated by and served from the Beaker server.

Within Beaker itself, compatibility has been maintained and the change should be largely invisible. In particular, kickstart metadata for systems and recipes will behave the same as in previous releases.

However, if your site is using any Cobbler functionality directly you may need to take steps to migrate the configuration to Beaker.

Default root password for installed systems

Since version 0.8.2 the root password for installed systems can be set globally by the Beaker administrator, as well as individually by each user. However if no password was set, the Cobbler default root password was inherited from the default_password_crypted setting in /etc/cobbler/settings.

If you have not already set a global root password in Beaker, you may want to set it to the same password configured in Cobbler.

Default kernel options

Cobbler allows site-wide default kernel options to be configured in the kernel_options setting in /etc/cobbler/settings. If you have modified these, you may want to apply the same defaults in Beaker by setting beaker.kernel_options in /etc/beaker/server.cfg.

In addition, Cobbler has default kernel options specifically for S/390 systems in the kernel_options_s390x setting, which default to:

RUNKS=1 ramdisk_size=40000 root=/dev/ram0 ro ip=off vnc

If you are the lucky owner of an S/390 mainframe you should set these kernel options in the Install Options tab for your S/390 systems.

Install options for Cobbler distros

If you have set kickstart metadata, kernel options, or post-install kernel options for any distros in Cobbler (for example using cobbler distro edit) you will need to find the equivalent distro tree in Beaker's web UI and set the options there. The format and meaning of the install options in Beaker are the same as in Cobbler.

Power scripts

When executing power commands, Beaker uses shell scripts which are based on Cobbler's power templates which are installed in /etc/cobbler/power. If you have customised any of Cobbler's power templates you may need to add a custom Beaker power script with the same modifications. Refer to Customizing Power Commands in the Beaker Guide.

Note that Beaker uses shell scripts rather than Cheetah templates for power commands, even though the shell scripts look very similar because the variable names are the same. You can examine the default scripts in /usr/lib/python2.6/​site-packages/​bkr/labcontroller/​power-scripts for inspiration.

Netboot config files

Beaker does not use templates for generating bootloader configs when provisioning a system (Cobbler's /etc/cobbler/pxe/pxesystem.template etc). Customizing these configs is not supported.

Unlike Cobbler, Beaker does not manage the default bootloader config ($TFTP_ROOT/​pxelinux.cfg/​default, and equivalent files for other bootloaders). You can continue to let Cobbler put its PXE menu here, or you can manage this file by hand. Beaker's only requirement for automated provisioning is that the it must default to local booting with a sensible timeout (the Cobbler PXE menu does this).

Snippets

Snippets are now located on the Beaker server (rather than the lab controller), under /etc/beaker/snippets.

Beaker uses Jinja2 for templating, so templates will need to be rewritten. Refer to the Jinja2 documentation for details of the template syntax, and to Customizing Kickstarts in the Beaker Guide for details about the Beaker specifics.

For your convenience, some common Cobbler template constructs are shown below, along with their equivalent in Beaker.

Accessing a variable:

$getVar('ondisk', '')

{{ ondisk }}

Looping:

#set _devices = $getVar('scsidevices', '').split(',')
#for $device in $_devices:
device $device
#end for

{% for device in scsidevices|split(',') %}
device {{ device }}
{% endfor %}

Conditional on distro version:

#if $os_version == "rhel3"
#set $yum = "yum-2.2.2-1.rhts.EL3.noarch.rpm"
#end if

{% if distro is osmajor('RedHatEnterpriseLinux3') %}
{% set yum = 'yum-2.2.2-1.rhts.EL3.noarch.rpm' %}
{% endif %}

Other Cobbler system management features

Cobbler's func integration, managed config files, and RHN registration features are incompatible with Beaker.

DHCP and DNS services are outside the scope of Beaker, so if you are using Cobbler to manage these in the lab then you can continue to do so. However, if you are relying on Cobbler's network config scripts when provisioning systems (that is, the pre_​install_​network_​config, network_​config, and post_​install_​network_​config snippets) you must migrate this configuration to DHCP instead.

If a system has particular network configuration needs not covered by DHCP, you can add a per-system snippet for it as appropriate: system_pre for pre-installation scripts, network for Anaconda network commands, or system_post for post-installation scripts. Refer to Customizing Kickstarts in the Beaker Guide for details.