This is a directory for building a Cobbler server using Vagrant, Docker and various scripts and provisioners.

The configuration structure of Cobble is based on a set of registered objects. Each object represents an entity that is associated with another entity. When one object points to another object, it inherits the data of the pointed object and can override or add more specific information. The following types of objects are defined:

Distribution: Represents an operating system. It carries information about the kernel and initrd, plus other data such as kernel parameters.

Profile: Points to a distribution, a kickstart file, and possibly repositories, plus other data such as more specific kernel parameters.

System: Represents the machine to be provisioned. It points to a profile or an image and contains information about IP and MAC addresses, power management and more specialized data.

Repository: Holds mirroring information for a yum or rsync repository.

Image: Can replace a distribution object for a files that do not fit in this category.

Cobbler Object Relationships:

The options to configure and use Cobbler include command line, API, XML_RPC and it's web interface.

Cobbler has packages for many Linux distributions. We will base these instructions for Ubuntu system -

 sudo apt-get install cobbler cobbler-web debmirror mkisofs 

After installation, it is always great idea to check cobbler's configuration to see if everything is as it should. Cobbler provides the command

 sudo cobbler check

THe cobbler-web should be installed in location /etc/apache2/conf.d/cobbler_web.conf file that configures Apache to run the Cobbler web interface.

The cobbler web interface is served by apache at http:// <hostname>/cobbler_web. If cobbler does not prompt for a password, it should set the default username/password to cobbler/cobbler. If this default does not work, we can set the password by running

 htdigest /etc/cobbler/users.digest "Cobbler" cobbler

this will prompt us for a new password. Once we have updated the password, we must run

cobbler sync

The main configuration file is under /etc/cobbler/settings. Most of the options are self explanatory.

Make sure the options listed below are set as such:

• manage_dhcp: 1
• manage_dns: 1
• manage_tftpd: 1
• restart_dhcp: 1
• restart_dns: 1
• pxe_just_once: 1
• next_server: <server's IP address>
• server: <server's IP address>

The option next_server is used in the DHCP configuration file to tell the machines what is the address of the server that provides the boot file. The option server is used during the machine installation to refer to the Cobbler server address. Finally, the option pxe_just_once prevents installation loops in machines that are configure to always boot from the network.

Now that cobbler knows which services to manage, we must tell it which programs to use. The options are as follows:

• DHCP: ISC dhcpd or dnsmasq
• DNS: BIND or dnsmasq
• TFTP: in.tftpd or cobbler's internal TFTP

For our setting we will use ISC_dhcpd and in.tftpd. [DNS TBD]. Edit the file under in folder /etc/cobbler/modules.conf and make sure it include the statements below:

[dhcp]
module = manage_isc

[tftpd]
module = manage_in_tftpd

Install the services

 apt-get install isc-dhcp-server

and

 apt-get install xinetd  tftpd tftp

Cobbler uses a template to create the configuration files for these services. Editing the template files locate under /etc/cobbler is necessary to adjust the network information such as the gateway address and IP range.

Edit the dhcp.template file accordingly(i.e set the subnet, ip-range, gateway etc.) Show below is an example of the subnet setting from a dhcp.template file

subnet 192.168.2.0 netmask 255.255.255.0 {
     range 192.168.2.110 192.168.2.115
     option gateway 192.168.2.1
     option broadcast-address 192.168.2.255
     option domain-name-servers 192.168.2.1 10.70.7.7 10.70.7.6
     option subnet-mask         255.255.255.0;
     default-lease-time         21600;
     max-lease-time             43200;
     next-server                $next_server;

For the tftpd.template file, make sure you have the settings set as show below:

service tftp
{
        disable                 = no
        socket_type             = dgram
        protocol                = udp
        wait                    = yes
        user                    = $user
        server                  = $binary
        server_args             = -s /var/lib/tftpboot
        per_source              = 11
        cps                     = 100 2
        flags                   = IPv4
}

To add Ubuntu installation tree, first we download the ISO media and the run the following commands to mount the media and extract content.

mount -o loop ubuntu-14.04-x86_64.iso /mnt/iso

Cobbler now copies the media content to the filesystem. This operation may take a while.

cobbler import --arch=x86_64 --path=/mnt/iso --name=ubuntu14

The cobbler import automatically creates a distribution and a profile object for us. We can also point Cobbler to a network repository.

First step to creating a profile is specifying a kickstart file, that is based on the file available from /var/lib/cobbler/kickstarts. In this file, under the section %packages, define a variable $desktop_pkg_group, which will alter be substituted to determine which packages are installed. Cobbler will know the value, because we will define it under the option ksmeta.

We have the option of creating a profile for Xfce or GNOME. The command are listed below, respectively:

xfce option

 cobbler profile add --name=ubuntu14  
                     --ksmeta='desktop_pkg_group=@xfce-desktop'  
                     --kickstart=/var/lib/cobbler/kickstarts/example.ks   
                     --parent=ubuntu-x86

GNOME option

cobbler profile add --name=ubuntu14  
                        --ksmeta='desktop_pkg_group=@gnome-desktop'  
                        --kickstart=/var/lib/cobbler/kickstarts/example.ks   
                        --parent=ubuntu-x86_64

 cobbler profile report

The --parent parameter tell the profile to inherit from the Ubuntu Profile. To verify the kickstarter content, we can use the command:

cobbler profile getks --name=ubuntu14

The last step in the setup is associating a machine with the profile we want them installed with. The command is :

cobbler system add --name=desktop-xfce-1 --profile=ubuntu-xfce -mac=<MAHCHINE MAC ADDRESS>

 cobbler system report

The power management feature in Cobbler can power on, power off and reboot the machine for us. This function is also useful when we have many machines and must organize power management information such as user and passwords for each because Cobbler registers them in its base. Suppose machine desktop-xfce-1 is in an IBM Bladecenter at location bay2 and desktop-gnome-1 is a machine that is managed with an RSA board, we can set up our system as seen below

xfce option

 cobbler system edit --name=desktop-xfce-1 \
                     --power-type=bladecenter \
                     --power-id=2 \
                     --power-user=admin_user \
                     --power-pass=admin_password \
                     --power-address=192.168.122.2

GNOME option

cobbler system edit --name=desktop-gnome-1 \
                    --power-type=rsa \
                    --power-user=rsa_user \
                    --power-pass=rsa_password \
                    --power-address=192.168.122.3

We should always remember to apply our changes to the file system

 cobbler sync

We are ready to boot the machines and install them. They must be configured to boot from the network.

 cobbler system reboot --name=desktop-xfce-1

Cobbler offers a useful web interface, which allows us to do everything via the web

For communicating with cobbler remotely, via the web or xmlrpc, we have different authentication systems and different workflows. The settings for authentication and authorization is governed in the settings in /etc/cobbler/modules.conf

The default format for authentication is set to deny all. This disables all external modifications(eg apis) and disables cobbler web interface. Cobbler provides six modes of authentication settings

DIGEST: This option simply uses a file to identify the username and password information. We can always add more users by running the command

 htdigest /etc/cobbler/users.digest "Cobbler" $username

kERBEROS: This option lets cobbler defer the decision to Apace. We can modify it to do things other than Kerberos. more info

LDAP: This option authenticates against LDAP using the settings under /etc/cobbler/settings. The direct cobbection to LDAP does not rely on Apache. more info

SPACEWALK: This option uses spacewalk for the authorization scheme to login to cobbler, since Spacewalk uses cobbler service.

TESTING: This option is to be used during the development and never in production. Only the combination testing/testing is allowed and no other.

USER SUPPLIED: This option is for users programming their own module to handle to authentication. more info

more info

We discuss the limit of access to users to specific aspects of Cobbler. The authorization happens once users are authenticated. Authorization choices are also set in the /etc/cobbler/modules.conf document.

We have 3 different modes of authorizations:

Allow All: This module permits any user who has passed the authorization step. This step is not recommended if you are authenticating using LDAP

Config File: This uses a simle file in /etc.cobbler/users.conf to provide a list of what users can access. Users not in this file will hot have access.

Owenership: This is similar to config-file but the enforcement is dynamic. This allows to keep users from modifying distros or profiles and system records. This is a good choice for use of cobbler in large companies. More detail

Users Supplied Modules: This allows users to create a custom, more refined, access control. See here

File Format: This file /etc/cobbler/users.conf is ignored by defaults as the default modes are to allow all, but if we choose other modes, we can use this file to configure alternative authentication modes for the different options listed above

More explanation is given here.

Cobbler has a python api named cobbler, however, it strongly advices using the CobblerXmlrpc interface instead. We will only discuss the use of the xmlrpc.

To use Cobbler's XMLRPC API, first we must setup the Customizable Security(see above) and ensure that Apace and cobbler are running on our server.

We first define our connection with Cobbler xmlrpc api, and then we login. We get a token which expires every 60min. Once this token expires it is necessary to renew it for subsequent api calls.

The api provides information on the distros, systems, profiles, images and repos that are currently available. We can also do search, make changes, create new objects, remove objects, power management and much more. more info

import xmlrpclib

server = xmlrpclib.Server("http://192.168.2.199/cobbler_api")
token = server.login("cobbler","cobbler")

# Create a distro
distro_id = remote.new_distro(token)
remote.modify_distro(distro_id, 'distro1',   'example-distro',token)
remote.modify_distro(distro_id, 'kernel', '/opt/stuff/vmlinuz',token)
remote.modify_distro(distro_id, 'initrd', '/opt/stuff/initrd.img',token)
remote.save_distro(distro_id,token)

# Remove a distro
remote.remove_profile("distro1",token)

XMLRPC binds to localhost on port 25150 by default and uses a separate log file located at /var/log/cobbler/cobblerd.log, where remote exceptions are logged here.

The source code for the api is found here. It is instructive to through the code, especially the test section at the bottom.