Setting up a network environment can involve many steps until everything is ready to start the installation. You must:

Configure services such as DHCP, TFTP, DNS, HTTP, FTP, and NFS

Fill individual client machine entries in DHCP and TFTP configuration files

Create automatic deployment files (such as kickstart and autoinst)

Extract installation media to HTTP/FTP/NFS repositories.

The process is not straightforward, and manual registration of each client machine that must be provisioned can be annoying. Any parameter change to the provisioning of a machine — such as a different operating system to be used — demands a manual intervention in configuration and possibly automatic deployment files. When the number of machines increases, elements like the TFTP directory can get messy unless you pay close attention to the files organization.

Cobbler addresses these shortcomings by creating a central point of management for all aspects of machine provisioning. It can reconfigure services, create repositories, extract operating system media, act or integrate with a configuration management system, control power management, and more. Cobbler creates a layer of abstraction where you can run commands like "add new repository" or "change client machine operating system." Cobbler takes care of everything — creating or updating configuration files, restarting services, or extracting media to newly created directories. The intention is to hide all the system-related issues so you can focus on the task itself

Cobbler is a Linux installation server that allows for rapid setup of network installation environments. It glues together and automates many associated Linux tasks so you do not have to hop between many various commands and applications when deploying new systems, and, in some cases, changing existing ones. Cobbler can help with provisioning, managing DNS and DHCP, package updates, power management, configuration management orchestration, and much more.

Here in my example, my machine name is cobbler and its IP is 192.168.75.222 and its running CentOS 6.5 x86_64 version

1) For simplicity and testing purposes, disable SELinux
[root@cobbler ~]# vim /etc/sysconfig/selinux
selinux=disabled

2) Reboot your system after applying SELinux Changes

3) Install the EPEL Repo for Cobbler Packages
[root@cobbler ~]# rpm -ivh http://epel.mirror.net.in/epel/6/i386/epel-release-6-8.noarch.rpm

4) Install the following packages
[root@cobbler ~]# yum install dhcp cobbler pykickstart mod_python tftp -y

5) Enable xinetd tftp and rsync services
[root@cobbler ~]# vim /etc/xinetd.d/tftp
disable = no                    <- Change this line to "no"
[root@cobbler ~]# vim /etc/xinetd.d/rsync
disable = no                    <- Change this line to "no"

6) Start the xinetd, httpd, cobbler services and start the necessary at boot time
[root@cobbler ~]# for i in xinetd httpd cobblerd; do service $i restart; chkconfig $i on; done;
[root@cobbler ~]# chkconfig tftp on
[root@cobbler ~]# chkconfig rsync on

7) Download the network boot-loaders for cobbler
[root@cobbler ~]# cobbler get-loaders
8) Change the default template of the dhcp file included with cobbler to match your network
[root@cobbler ~]# cp /etc/cobbler/dhcp.template /etc/cobbler/dhcp.template.org
[root@cobbler ~]# vim /etc/cobbler/dhcp.templateallow booting;
allow bootp;
ignore client-updates;
set vendorclass = option vendor-class-identifier;
option pxe-system-type code 93 = unsigned integer 16;
subnet 192.168.75.0 netmask 255.255.255.0 {
     option routers             192.168.75.1;
     option subnet-mask         255.255.255.0;
     range dynamic-bootp        192.168.75.100 192.168.75.254;
     default-lease-time         21600;
     max-lease-time             43200;
     next-server                192.168.75.222;
     class "pxeclients" {
          match if substring (option vendor-class-identifier, 0, 9) = "PXEClient";
          if option pxe-system-type = 00:02 {
                  filename "ia64/elilo.efi";
          } else if option pxe-system-type = 00:06 {
                  filename "grub/grub-x86.efi";
          } else if option pxe-system-type = 00:07 {
                  filename "grub/grub-x86_64.efi";
          } else {
                  filename "pxelinux.0";
          }
     }

9) Change the cobbler setting file according to the below
[root@cobbler ~]# vim /etc/cobbler/settingsmanage_dhcp: 1
next_server: 192.168.75.222
server: 192.168.75.222
10) Mount your CentOS 6.5 DVD to a mount point, here I am mounting on /mnt
[root@cobbler ~]# mount /dev/sr0 /mnt
11) Import the Distro details into cobbler using the below command (It takes time to copy the distro data into /var/www/cobbler/. So be patient)
[root@cobbler ~]# cobbler import --path=/mnt --name=CentOS_6.5_x86_64

12) Copy the default anaconda-ks.cfg to the default location of cobbler kickstart files
[root@cobbler ~]# cp anaconda-ks.cfg /var/lib/cobbler/kickstarts/centos65.ks
13) Modify the centos65.ks file to the following or according to your requirement
[root@cobbler ~]# vim /var/lib/cobbler/kickstarts/centos65.ksinstall
url --url http://192.168.75.222/cobbler/ks_mirror/CentOS_6.5_x86_64/
lang en_US.UTF-8zerombr
keyboard us
network --onboot yes --device eth0 --bootproto dhcp --noipv6
rootpw --iscrypted $6$4t6CgzQlwQKVFUEb$.mWJx35kMLobSabwpoKzlVpTvmTjxapy5GjSJdWkWANgV9J0SE4tm/oYMQjOYFdAyp5FgpevxXmzyy5/3xcHS.
firewall --service=ssh
authconfig --enableshadow --passalgo=sha512
selinux --enforcing
timezone Asia/Kolkata
bootloader --location=mbr --driveorder=sda --append="crashkernel=auto rhgb quiet"
clearpart --linux --drives=sda
repo --name="CentOS" --baseurl=cdrom:sr0 --cost=100
%packages --nobase
@core
%end

14) Add the distro information to the cobbler for PXE Boot
[root@cobbler ~]# cobbler distro add --name=CentOS_6.5_x86_64 --kernel=/var/www/cobbler/ks_mirror/CentOS_6.5_x86_64/isolinux/vmlinuz --initrd=/var/www/cobbler/ks_mirror/CentOS_6.5_x86_64/isolinux/initrd.img

15) Add the kickstart profile to the distro
[root@cobbler ~]# cobbler profile add --name=CentOS_6.5_KS --distro=CentOS_6.5_x86_64 --kickstart=/var/lib/cobbler/kickstarts/centos65.ks
16) Restart and synchronize the changes that were made into cobbler
[root@cobbler ~]# service cobblerd restart
[root@cobbler ~]# cobbler sync
17) Configure the firewall to allow ports 80 (HTTP) and 69 (TFTP)
[root@cobbler ~]# iptables -I INPUT -p tcp -s 192.168.75.0/24 -d 192.168.75.222 --dport 80 -j ACCEPT
[root@cobbler ~]# iptables -I INPUT -p udp -s 192.168.75.0/24 -d 192.168.75.222 --dport 69 -j ACCEPT
[root@cobbler ~]# service iptables save

18) Restart the below services once again to make sure all the changes are applied to the services
[root@cobbler ~]# for i in xinetd httpd cobblerd; do service $i restart; chkconfig $i on; done;
19) Boot a new linux machine and make sure it boots via Network and at the menu prompt select the CentOS_6.5_KS option

Cobbler Quickstart Guide

Cobbler can be a somewhat complex system to get started with, due to the wide variety of technologies it is designed to manage, but it does support a great deal of functionality immediately after installation with little to no customization needed. Before getting started with cobbler, you should have a good working knowledge of PXE as well as the automated installation methodology of your choosen distribution.

This quickstart guide will focus on the Red Hat kickstart process, which is very mature and well-tested. In the future, we will be adding quickstart guides for other distributions, such as Ubuntu and SuSE. The steps below will be focused on Fedora (specifically version 17), however they should work for any Red Hat-based distribution, such as RHEL, CentOS, or Scientific Linux. Please see the Installing Cobbler section for details on installation and prerequisites for your specific OS version.

Finally, this guide will focus only on the CLI application. For more details regarding cobbler's web UI, go here: Cobbler Web User Interface

Disable SELinux (optional)

Before getting started with cobbler, it may be a good idea to either disable SELinux or set it to "permissive" mode, especially if you are unfamiliar with SELinux troubleshooting or modifying SELinux policy. Cobbler constantly evolves to assist in managing new system technologies, and the policy that ships with your OS can sometimes lag behind the feature-set we provide, resulting in AVC denials that break cobbler's functionality.

If you would like to continue using SELinux on the system running cobblerd, be sure to read the SELinux With Cobbler section in this manual.

Installing Cobbler

Installation is done simply through yum:

$ yum install cobbler

This will pull in all of the requirements you need for a basic setup.

Changing Settings

Before starting the cobblerd service, there are a few things you should modify.

Settings for cobbler/cobblerd are stored in /etc/cobbler/settings. This file is a YAML formatted data file, so be sure to take care when editing this file as an incorrectly formatted file will prevent cobbler/cobblerd from running.

Default Encrypted Password

This setting controls the root password that is set for new systems during the kickstart.

default_password_crypted: "$1$bfI7WLZz$PxXetL97LkScqJFxnW7KS1"

You should modify this by running the following command and inserting the output into the above string (be sure to save the quote marks):

$ openssl passwd -1

Server and Next_Server

The server option sets the IP that will be used for the address of the cobbler server. DO NOT use 0.0.0.0, as it is not the listening address. This should be set to the IP you want hosts that are being built to contact the cobbler server on for such protocols as HTTP and TFTP.

# default, localhost
server: 127.0.0.1

The next_server option is used for DHCP/PXE as the IP of the TFTP server from which network boot files are downloaded. Usually, this will be the same IP as the server setting.

# default, localhost
next_server: 127.0.0.1

DHCP Management and DHCP Server Template

In order to PXE boot, you need a DHCP server to hand out addresses and direct the booting system to the TFTP server where it can download the network boot files. Cobbler can manage this for you, via the manage_dhcp setting:

# default, don't manage
manage_dhcp: 0

Change that setting to 1 so cobbler will generate the dhcpd.conf file based on the dhcp.template that is included with cobbler. This template will most likely need to be modified as well, based on your network settings:

$ vi /etc/cobbler/dhcp.template

For most uses, you'll only need to modify this block:

subnet 192.168.1.0 netmask 255.255.255.0 {
     option routers             192.168.1.1;
     option domain-name-servers 192.168.1.210,192.168.1.211;
     option subnet-mask         255.255.255.0;
     filename                   "/pxelinux.0";
     default-lease-time         21600;
     max-lease-time             43200;
     next-server                $next_server;
}

No matter what, make sure you do not modify the "next-server $next_server;" line, as that is how the next_server setting is pulled into the configuration. This file is a cheetah template, so be sure not to modify anything starting after this line:

#for dhcp_tag in $dhcp_tags.keys():

Completely going through the dhcpd.conf configuration syntax is beyond the scope of this document, but for more information see the man page for more details:

$ man dhcpd.conf

Files and Directory Notes

Cobbler makes heavy use of the /var directory. The /var/www/cobbler/ks_mirror directory is where all of the distribution and repository files are copied, so you will need 5-10GB of free space per distribution you wish to import.

If you have installed cobbler onto a system that has very little free space in the partition containing /var, please read the Relocating Your Installation section of the manual to learn how you can relocate your installation properly.

Starting and Enabling the Cobbler Service

Once you have updated your settings, you're ready to start the service. Fedora now uses systemctl to manage services, but you can still use the regular init script:

$ systemctl start cobblerd.service
$ systemctl enable cobblerd.service
$ systemctl status cobblerd.service






or




$ service cobblerd start
$ chkconfig cobblerd on
$ service cobblerd status

If everything has gone well, you should see output from the status command like this:

cobblerd.service - Cobbler Helper Daemon
          Loaded: loaded (/lib/systemd/system/cobblerd.service; enabled)
          Active: active (running) since Sun, 17 Jun 2012 13:01:28 -0500; 1min 44s ago
        Main PID: 1234 (cobblerd)
          CGroup: name=systemd:/system/cobblerd.service
                  └ 1234 /usr/bin/python /usr/bin/cobblerd -F

Checking for Problems and Your First Sync

Now that the cobblerd service is up and running, it's time to check for problems. Cobbler's check command will make some suggestions, but it is important to remember that these are mainly only suggestions and probably aren't critical for basic functionality. If you are running iptables or SELinux, it is important to review any messages concerning those that check may report.

$ cobbler check
The following are potential configuration items that you may want to fix:







....


....







Restart cobblerd and then run 'cobbler sync' to apply changes.

If you decide to follow any of the suggestions, such as installing extra packages, making configuration changes, etc., be sure to restart the cobblerd service as it suggests so the changes are applied.

Once you are done reviewing the output of "cobbler check", it is time to synchronize things for the first time. This is not critical, but a failure to properly sync at this point can reveal a configuration problem.

$ cobbler sync
task started: 2012-06-24_224243_sync
task started (id=Sync, time=Sun Jun 24 22:42:43 2012)
running pre-sync triggers
...
rendering DHCP files
generating /etc/dhcp/dhcpd.conf
rendering TFTPD files
generating /etc/xinetd.d/tftp
cleaning link caches
running: find /var/lib/tftpboot/images/.link_cache -maxdepth 1 -type f -links 1 -exec rm -f '{}' ';'
received on stdout:
received on stderr:
running post-sync triggers
running python triggers from /var/lib/cobbler/triggers/sync/post/
running python trigger cobbler.modules.sync_post_restart_services
running: dhcpd -t -q
received on stdout:
received on stderr:
running: service dhcpd restart
received on stdout:
received on stderr:
running shell triggers from /var/lib/cobbler/triggers/sync/post/
running python triggers from /var/lib/cobbler/triggers/change/
running python trigger cobbler.modules.scm_track
running shell triggers from /var/lib/cobbler/triggers/change/
 TASK COMPLETE

Assuming all went well and no errors were reported, you are ready to move on to the next step.

Importing Your First Distribution

Cobbler automates adding distributions and profiles via the "cobbler import" command. This command can (usually) automatically detect the type and version of the distribution your importing and create (one or more) profiles with the correct settings for you.

Download an ISO Image

In order to import a distribution, you will need a DVD ISO for your distribution. NOTE: You must use a full DVD, and not a "Live CD" ISO. For this example, we'll be using the Fedora 17 x86_64 ISO, available for download here.

Once this file is downloaded, mount it somewhere:

$ mount -t iso9660 -o loop,ro /path/to/isos/Fedora-17-x86_64-DVD.iso /mnt

Run the Import

You are now ready to import the distribution. The name and path arguments are the only required options for import:

$ cobbler import --name=fedora17 --arch=x86_64 --path=/mnt

The --arch option need not be specified, as it will normally be auto-detected. We're doing so in this example in order to prevent multiple architectures from being found (Fedora ships i386 packages on the full DVD, and cobbler will create both x86_64 and i386 distros by default).

Listing Objects

If no errors were reported during the import, you can view details about the distros and profiles that were created during the import.

# list distros
$ cobbler distro list






list profiles




$ cobbler profile list

The import command will typically create at least one distro/profile pair, which will have the same name as shown above. In some cases (for instance when a xen-based kernel is found), more than one distro/profile pair will be created.

Object Details

The report command shows the details of objects in cobbler:

$ cobbler distro report --name=fedora17-x86_64
Name                           : fedora17-x86_64
Architecture                   : x86_64
TFTP Boot Files                : {}
Breed                          : redhat
Comment                        :
Fetchable Files                : {}
Initrd                         : /var/www/cobbler/ks_mirror/fedora17-x86_64/images/pxeboot/initrd.img
Kernel                         : /var/www/cobbler/ks_mirror/fedora17-x86_64/images/pxeboot/vmlinuz
Kernel Options                 : {}
Kernel Options (Post Install)  : {}
Kickstart Metadata             : {'tree': 'http://@@http_server@@/cblr/links/fedora17-x86_64'}
Management Classes             : []
OS Version                     : fedora17
Owners                         : ['admin']
Red Hat Management Key         : <<inherit>>
Red Hat Management Server      : <<inherit>>
Template Files                 : {}

As you can see above, the import command filled out quite a few fields automatically, such as the breed, OS version, and initrd/kernel file locations. The "Kickstart Metadata" field (--ksmeta internally) is used for miscellaneous variables, and contains the critical "tree" variable. This is used in the kickstart templates to specify the URL where the installation files can be found.

Something else to note: some fields are set to "<<inherit>>". This means they will use either the default setting (found in the settings file), or (in the case of profiles, sub-profiles, and systems) will use whatever is set in the parent object.

Creating a System

Now that you have a distro and profile, you can create a system. Profiles can be used to PXE boot, but most of the features in cobbler revolve around system objects. The more information you give about a system, the more cobbler will do automatically for you.

First, we'll create a system object based on the profile that was created during the import. When creating a system, the name and profile are the only two required fields:

$ cobbler system add --name=test --profile=fedora17-x86_64
$ cobbler system list
test
$ cobbler system report --name=test
Name                           : test
TFTP Boot Files                : {}
Comment                        :
Enable gPXE?                   : 0
Fetchable Files                : {}
Gateway                        :
Hostname                       :
Image                          :
IPv6 Autoconfiguration         : False
IPv6 Default Device            :
Kernel Options                 : {}
Kernel Options (Post Install)  : {}
Kickstart                      : <<inherit>>
Kickstart Metadata             : {}
LDAP Enabled                   : False
LDAP Management Type           : authconfig
Management Classes             : []
Management Parameters          : <<inherit>>
Monit Enabled                  : False
Name Servers                   : []
Name Servers Search Path       : []
Netboot Enabled                : True
Owners                         : ['admin']
Power Management Address       :
Power Management ID            :
Power Management Password      :
Power Management Type          : ipmitool
Power Management Username      :
Profile                        : fedora17-x86_64
Proxy                          : <<inherit>>
Red Hat Management Key         : <<inherit>>
Red Hat Management Server      : <<inherit>>
Repos Enabled                  : False
Server Override                : <<inherit>>
Status                         : production
Template Files                 : {}
Virt Auto Boot                 : <<inherit>>
Virt CPUs                      : <<inherit>>
Virt Disk Driver Type          : <<inherit>>
Virt File Size(GB)             : <<inherit>>
Virt Path                      : <<inherit>>
Virt RAM (MB)                  : <<inherit>>
Virt Type                      : <<inherit>>

The primary reason for creating a system object is network configuration. When using profiles, you're limited to DHCP interfaces, but with systems you can specify many more network configuration options.

So now we'll setup a single, simple interface in the 192.168.1/24 network:

$ cobbler system edit --name=test --interface=eth0 --mac=00:11:22:AA:BB:CC --ip-address=192.168.1.100 --netmask=255.255.255.0 --static=1 --dns-name=test.mydomain.com

The default gateway isn't specified per-NIC, so just add that separately (along with the hostname):

$ cobbler system edit --name=test --gateway=192.168.1.1 --hostname=test.mydomain.com

The --hostname field corresponds to the local system name and is returned by the "hostname" command. The --dns-name (which can be set per-NIC) should correspond to a DNS A-record tied to the IP of that interface. Neither are required, but it is a good practice to specify both. Some advanced features (like configuration management) rely on the --dns-name field for system record look-ups.

Whenever a system is edited, cobbler executes what is known as a "lite sync", which regenerates critical files like the PXE boot file in the TFTP root directory. One thing it will NOT do is execute service management actions, like regenerating the dhcpd.conf and restarting the DHCP service. After adding a system with a static interface it is a good idea to execute a full "cobbler sync" to ensure the dhcpd.conf file is rewritten with the correct static lease and the service is bounced.

Deploying Operating Systems Using Cobbler - PXE Boot