Cobbler is an open source provisioning system that provides a framework for managing your PXE-based installs. It is embedded in the Spacewalk project (and Red Hat Satellite Server 5.x) and can be used standalone if you require a management framework for your PXE boot environment (rather than managing it by hand as we did in Chapter 6, Custom Builds with PXE Booting).
Although the actual use of Cobbler is beyond the scope of this book, it serves as an excellent example for our dynamic inventory section of this book because it is extremely easy to get up and running with.
To get started with this example, you will need a demo system that Cobbler is packaged for—at the time of writing, there are no native packages for Ubuntu Server 18.04, so we will install our Cobbler server on CentOS 7. Your dynamic inventory script can be run from an Ubuntu Server machine, though—the only requirement is that it can communicate with your Cobbler server on the network:
- To get started, install the minimum required Cobbler packages on your CentOS 7 system using the following command:
$ sudo yum -y install cobbler cobbler-web
- The default configuration for Cobbler should be fine for our simple dynamic inventory test purposes, so we will start the server with this command:
$ sudo systemctl start cobblerd.service
- Next, we will create distro and profile for our systems—when using Cobbler for actual PXE-based installs, distro describes the operating system and specifies items such as the kernel and initial RAMDisk to be used. These commands should work on your CentOS 7 test system, but be aware that if you don't have these specific kernel files installed, you must change these to reference the kernel you have installed:
$ sudo cobbler distro add --name=CentOS --kernel=/boot/vmlinuz-3.10.0-957.el7.x86_64 --initrd=/boot/initramfs-3.10.0-957.el7.x86_64.img
$ sudo cobbler profile add --name=webservers --distro=CentOS
- It appears that Cobbler does not function with the out of the box SELinux policy that runs on CentOS 7—in a production environment, you would modify the policy to support Cobbler correctly. For the sake of this simple demo, you can simply disable SELinux using this command:
$ sudo setenforce 0
Just don't do this in a production environment!
- With our prerequisite steps completed, we can now commence adding our actual systems to the Cobbler inventory. We will add two frontend web servers to our webservers group using the following commands:
$ cobbler system add --name=frontend01 --profile=webservers --dns-name=frontend01.example.com --interface=eth0
$ cobbler system add --name=frontend02 --profile=webservers --dns-name=frontend02.example.com --interface=eth0
The --dns-name parameter should be an actual resolvable DNS name in your test environment for this test to work—I am adding them to /etc/hosts on my Ansible server for this test but, again, in a production environment, you would not do this.
- Cobbler is now set up and has an inventory of two hosts in a group (profile) called webservers. Now, we can move back to our Ansible server. On this machine, download the Cobbler dynamic inventory script and its associated configuration file by running this:
$ wget https://raw.githubusercontent.com/ansible/ansible/devel/contrib/inventory/cobbler.py
$ wget https://raw.githubusercontent.com/ansible/ansible/devel/contrib/inventory/cobbler.ini
$ chmod +x cobbler.py
- Now, edit the configuration file, cobbler.ini—near the top of this file, you will see a few lines that look like this:
[cobbler]
host = http://PATH_TO_COBBLER_SERVER/cobbler_api
Change the PATH_TO_COBBLER_SERVER string to the hostname or IP address of the machine you just installed Cobbler on. That's all there is to it!
- Now, you can run Ansible and use an ad hoc command to test your dynamic inventory—simply run this:
$ ansible webservers -i cobbler.py -m ping
You will observe that we are telling Ansible to only perform this action on the webservers group from the inventory specified by the -i parameter—which, in this case, is our Cobbler dynamic inventory script. If all has gone well, your output should look something like this screenshot:
In this case, the deprecation warning is about the output from the Cobbler dynamic inventory script, which suggests it might need updating to work with Ansible 2.10 onward. However, we can see that Ansible can extract the inventory from the Cobbler server and use it for our simple ad hoc command—this would work just as well with a whole playbook!
Play with the Cobbler server; try adding and removing systems and see how Ansible retrieves the up to date inventory each and every time. Using other dynamic inventory scripts can be a little more involved, but it is not complicated provided you refer to the documentation and examples that ship with each. The time spent learning this will more than pay off later in terms of making your life easier and your inventories more accurate.
In the final section of this chapter, we will look a little deeper at ad hoc commands and how they can help you with one-off tasks.