6. User Guide

• 6.1. Configuration Management Integrations
  • 6.1.1. Background considerations
  • 6.1.2. General scheme
  • 6.1.3. Built-In Configuration Management
  • 6.1.4. Terraform Provider
  • 6.1.5. Ansible
  • 6.1.6. Saltstack
  • 6.1.7. Vagrant
  • 6.1.8. Puppet
  • 6.1.9. cfengine support
  • 6.1.10. bcfg2 support
  • 6.1.11. Chef support
  • 6.1.12. Conclusion
• 6.2. Automatic Installation
  • 6.2.1. Autoinstallation Support
  • 6.2.2. Automatic installation templating
  • 6.2.3. Automatic installation snippets
  • 6.2.4. Autoinstall validation
• 6.3. Automatic Windows installation with Cobbler
  • 6.3.1. Additional Windows metadata
  • 6.3.2. Preparing for an unattended network installation of Windows
  • 6.3.3. Final steps
  • 6.3.4. Legacy Windows XP and Windows 2003 Server
  • 6.3.5. Preparing boot files for RIS and legacy Windows XP and Windows 2003 Server
• 6.4. VMware ESXi installation with cobbler
  • 6.4.1. Installation Quickstart guide
  • 6.4.2. Providing Cobbler the ESXi bootloaders
  • 6.4.3. The boot.cfg file
  • 6.4.4. TFTP esxi directory
  • 6.4.5. Useful links
• 6.5. Extending Cobbler
  • 6.5.1. Triggers
  • 6.5.2. Modules
  • 6.5.3. Cheetah Macros
• 6.6. Terraform Provider for Cobbler
  • 6.6.1. Why Terraform for Cobbler
  • 6.6.2. Configure Cobbler
  • 6.6.3. Install Terraform
  • 6.6.4. Repository setup & configurations
• 6.7. Building ISOs
  • 6.7.1. Under the hood
  • 6.7.2. Common options for building ISOs
  • 6.7.3. Building standalone ISOs
  • 6.7.4. Building net-installer ISOs
  • 6.7.5. Examples
  • 6.7.6. Links with further information
• 6.8. GRUB and everything related
  • 6.8.1. Additional dependencies
  • 6.8.2. The command “cobbler mkloaders”
  • 6.8.3. Current workflow
  • 6.8.4. IMPORTANT FILES
• 6.9. Repository Management
  • 6.9.1. General
  • 6.9.2. Importing trees workflow
  • 6.9.3. Repository mirroring workflow
  • 6.9.4. Import Workflow
• 6.10. The TFTP Directory
  • 6.10.1. Behaviour
  • 6.10.2. Layout
• 6.11. Internal Database
  • 6.11.1. Items
  • 6.11.2. Collections
  • 6.11.3. Notes
• 6.12. HTTP API
  • 6.12.1. Error codes
  • 6.12.2. Http endpoints
• 6.13. HTTPboot
  • 6.13.1. Create Configuration
• 6.14. Power Management
  • 6.14.1. What’s Supported
  • 6.14.2. Example of Set Up
  • 6.14.3. Data Entry
  • 6.14.4. Defaults
  • 6.14.5. Using the Power Management Features
  • 6.14.6. Implementation
  • 6.14.7. Important: Security Implications
• 6.15. Boot CD
  • 6.15.1. DHCP Management
  • 6.15.2. DNS configuration management
• 6.16. Advanced Networking
  • 6.16.1. Arbitrary NIC naming
  • 6.16.2. Name Servers
  • 6.16.3. NIC bonding
  • 6.16.4. Static routes
  • 6.16.5. VLANs
  • 6.16.6. Kickstart Notes

6.17. API

Cobbler also makes itself available as an XML-RPC API for use by higher level management software. Learn more at https://cobbler.github.io

6.18. Triggers

Triggers provide a way to integrate Cobbler with arbitrary 3rd party software without modifying Cobbler’s code. When adding a distro, profile, system, or repo, all scripts in /var/lib/cobbler/triggers/add are executed for the particular object type. Each particular file must be executable and it is executed with the name of the item being added as a parameter. Deletions work similarly – delete triggers live in /var/lib/cobbler/triggers/delete. Order of execution is arbitrary, and Cobbler does not ship with any triggers by default. There are also other kinds of triggers – these are described on the Cobbler Wiki. For larger configurations, triggers should be written in Python – in which case they are installed differently. This is also documented on the Wiki.

6.19. Images

Cobbler can help with booting images physically and virtually, though the usage of these commands varies substantially by the type of image. Non-image based deployments are generally easier to work with and lead to more sustainable infrastructure. Some manual use of other commands beyond of what is typically required of Cobbler may be needed to prepare images for use with this feature.

6.20. Non-import (manual) workflow

The following example uses a local kernel and initrd file (already downloaded), and shows how profiles would be created using two different automatic installation files – one for a web server configuration and one for a database server. Then, a machine is assigned to each profile.

cobbler check
cobbler distro add --name=rhel4u3 --kernel=/dir1/vmlinuz --initrd=/dir1/initrd.img
cobbler distro add --name=fc5 --kernel=/dir2/vmlinuz --initrd=/dir2/initrd.img
cobbler profile add --name=fc5webservers --distro=fc5-i386 --autoinstall=/dir4/kick.ks --kernel-options="something_to_make_my_gfx_card_work=42 some_other_parameter=foo"
cobbler profile add --name=rhel4u3dbservers --distro=rhel4u3 --autoinstall=/dir5/kick.ks
cobbler system add --name=AA:BB:CC:DD:EE:FF --profile=fc5-webservers
cobbler system add --name=AA:BB:CC:DD:EE:FE --profile=rhel4u3-dbservers
cobbler report

6.21. Virtualization

For Virt, be sure the distro uses the correct kernel (if paravirt) and follow similar steps as above, adding additional parameters as desired:

cobbler distro add --name=fc7virt [options...]

Specify reasonable values for the Virt image size (in GB) and RAM requirements (in MB):

cobbler profile add --name=virtwebservers --distro=fc7virt --autoinstall=path --virt-file-size=10 --virt-ram=512 [...]

Define systems if desired. Koan can also provision based on the profile name.

cobbler system add --name=AA:BB:CC:DD:EE:FE --profile=virtwebservers [...]

If you have just installed Cobbler, be sure that the cobblerd service is running and that port 25151 is unblocked.

See the manpage for Koan for the client side steps.

6.22. Network Topics

6.22.1. PXE Menus

Cobbler will automatically generate PXE menus for all profiles it has defined. Running cobbler sync is required to generate and update these menus.

To access the menus, type menu at the boot: prompt while a system is PXE booting. If nothing is typed, the network boot will default to a local boot. If “menu” is typed, the user can then choose and provision any Cobbler profile the system knows about.

If the association between a system (MAC address) and a profile is already known, it may be more useful to just use system add commands and declare that relationship in Cobbler; however many use cases will prefer having a PXE system, especially when provisioning is done at the same time as installing new physical machines.

If this behavior is not desired, run cobbler system add --name=default --profile=plugh to default all PXE booting machines to get a new copy of the profile plugh. To go back to the menu system, run cobbler system remove --name=default and then cobbler sync to regenerate the menus.

When using PXE menu deployment exclusively, it is not necessary to make Cobbler system records, although the two can easily be mixed.

Additionally, note that all files generated for the PXE menu configurations are templatable, so if you wish to change the color scheme or equivalent, see the files in /etc/cobbler.

6.22.2. Default PXE Boot behavior

What happens when PXE booting a system when Cobbler has no record of the system being booted?

By default, Cobbler will configure PXE to boot to the contents of /etc/cobbler/default.pxe, which (if unmodified) will just fall through to the local boot process. Administrators can modify this file if they like to change that behavior.

An easy way to specify a default Cobbler profile to PXE boot is to create a system named default. This will cause /etc/cobbler/default.pxe to be ignored. To restore the previous behavior do a cobbler system remove on the default system.

cobbler system add --name=default --profile=boot_this
cobbler system remove --name=default

As mentioned in earlier sections, it is also possible to control the default behavior for a specific network:

cobbler system add --name=network1 --ip-address=192.168.0.0/24 --profile=boot_this

6.22.3. PXE boot loop prevention

If you have your machines set to PXE first in the boot order (ahead of hard drives), change the pxe_just_once flag in /etc/cobbler/settings.yaml to 1. This will set the machines to not PXE on successive boots once they complete one install. To re-enable PXE for a specific system, run the following command:

cobbler system edit --name=name --netboot-enabled=1

6.22.4. Automatic installation tracking

Cobbler knows how to keep track of the status of automatic installation of machines.

cobbler status

Using the status command will show when Cobbler thinks a machine started automatic installation and when it finished, provided the proper snippets are found in the automatic installation template. This is a good way to track machines that may have gone interactive (or stalled/crashed) during automatic installation.

6.23. Containerization

We have a test-image which you can find in the Cobbler repository and an old image made by the community: https://github.com/osism/docker-cobbler

6.24. Web-Interface

Please be patient until we have time with the 4.0.0 release to create a new web UI. The old Django based was preventing needed change inside the internals in Cobbler.