Customizing provisioning templates in Red Hat Satellite using snippets

In this post:

• Learn what Kickstart default provisioning template on Red Hat Satellite can do and its limitations.

• Learn how to use the snippet_if_exists() function, called from within the Kickstart default template, to extend certain provisioning templates.

Red Hat Satellite's provisioning templates are very powerful, but also hard to customize and maintain. A recently introduced feature makes extending and customizing default templates much easier to accomplish and maintain. In this post, we’ll provide an overview of the Kickstart default provisioning template and how to create a custom provisioning template using snippets that better address your environment.

The good

The Kickstart default provisioning template on Red Hat Satellite is a wonderful piece of code. It contains the instructions for an unattended installation of Red Hat Enterprise Linux (RHEL) so you can hit the Submit button on Satellite's Create Host page and, after a few minutes, have that specific host built to the specs you gave it. 

Here is an excerpt from the Kickstart default provisioning template as rendered for one of my lab machines:

# This kickstart file was rendered from the Foreman provisioning template "Kickstart default".

install

url --url http://sat69a.example.com/pulp/repos/(...)/server/7/7.9/x86_64/kickstart/

lang en_US.UTF-8
selinux --enforcing
keyboard us
skipx
network --device=00:ca:fe:16:02:11 --hostname rhel79-img02.example69a.ipv6 --noipv4 --ipv6=2620:55:0:ab0:2ca:feff:fe16:211/64 --ipv6gateway= --mtu=1500 --nodns
rootpw --iscrypted $5$w5EAgNmbiKMHA721$cEj1S9WO8D5Xbt1oSmhimFufpMEOxNJQ4P6kYrft7
firewall --service=ssh
authconfig --useshadow --passalgo=sha256 --kickstart
timezone --utc UTC
services --disabled gpm,sendmail,cups,pcmcia,isdn,rawdevices,hpoj,bluetooth,...
bootloader --location=mbr --append="nofb quiet splash=quiet"
zerombr
clearpart --all --initlabel
autopart
text
reboot
%packages
yum
dhclient
(...)

The bad

On the other hand, customizing the Kickstart default provisioning template can be confusing if you are unfamiliar with the kickstart syntax or with embedded ruby. Of course you may rely on Ansible playbooks as a means of further configuring provisioned hosts, but this means the host will first reboot after provisioning, and only then will it run any Ansible roles. 

If you need to set up sshd before Ansible is even allowed to connect to the host, you need to customize your provisioning template. Other examples requiring such customization include configuring network routes which, if left unconfigured, would prevent the newly provisioned host from even being accessed from the Satellite or Capsule server. Simpler examples also include installing additional packages, enabling repositories hosted outside of the Satellite or Capsule server, adding custom entries to the /etc/hosts file, or running alternatives to choose a non-default MTA for the host.

In fact, modifying any provisioning template to accomplish something other than its default actions is often a dangerous undertaking, or at least a cumbersome one. So admins often prefer to add to, rather than modify or remove from, provisioning templates. This ensures provisioning templates will keep working as usual while also doing something in addition.

The beautiful

Provisioning templates shipped with Red Hat Satellite are locked, meaning you can't modify them. In order to customize these templates, admins usually need to clone the shipped template into a new, unlocked one. Then, admins need to add the custom template to the operating systems they apply to. 

It would be so much easier if we could simply tell Satellite to run a set of commands, with or without embedded ruby, as part of the template's %post section... Or if we could just add a list of packages, one per line, to have the host install as if they were part of the template's %packages section. Wait! You can!

Red Hat Satellite offers the ability to load arbitrary snippets into the Kickstart default provisioning template. All you have to do is create a new template of type snippet and name it Kickstart default custom post. Anything you add to this snippet will be added to the %post section of the Kickstart default provisioning template. 

Similarly, you may create another snippet-type template named Kickstart default custom packages to have it loaded into the %packages section, or name it Kickstart default custom pre to have it loaded into the %pre section of the Kickstart default provisioning template.

Demo

Let's add a custom %post command to add an entry to /etc/hosts containing:

203.0.113.1  server1.example.com

On Red Hat Satellite, navigate to Hosts > Provisioning Templates.

Click the blue Create Template button.

Name the new template Kickstart default post and check the Default box. For its contents, add:

/bin/echo "203.0.113.1  server1.example.com" >> /etc/hosts

Your custom template should look like this (But don't click Submit just yet!):

Finally, click the Type tab and then select the Snippet box:

You may finally hit Submit.

Will it work?

Yes it will! If you want to provision a new host to see if it will be provisioned with that new entry in /etc/hosts, be my guest.

Alternatively, if you simply want to check out if the Kickstart default template would be rendered with our custom command injected into its %post section, just try to preview the Kickstart default template. 

Navigate to Hosts > Provisioning Templates, then locate and click Kickstart default. Finally, click Preview on the code editor widget and choose a host from the list that is using the Kickstart default template (this would be all your provisioned hosts if you have never changed operating systems' default provisioning templates. The next picture shows our custom command injected into the host's kickstart template's %post section at line 65.

Other templates offering similar capabilities

This wonderful outcome is made possible by the snippet_if_exists() function called from within the Kickstart default template:

You will notice that this same template contains other calls to snippet_if_exists():

These pictures show we can easily extend Kickstart default with custom repositories, custom packages, and custom pre snippets in addition to the custom post snippet we just set up for this exercise.

If you want to find out what other templates currently offer snippet_if_exists() functionality, you cansearch for snippet_if_exists on the provisioning templates search box: navigate to Hosts > Provisioning Templates, then type snippet_if_exists on the search box and hit the Search button. 

The templates listed in the search result all contain at least one call to snippet_if_exists(). An example is the Kickstart default PXELinux template, which allows for defining custom menu entries with a snippet named Kickstart default PXELinux custom menu:

Conclusion

Provisioning templates are great, potentially complex pieces of code that play a very important role in the host provisioning process. Customizing provisioning templates can be necessary for a host of reasons. 

By having this very easy way to extend certain provisioning templates, you are encouraged to create custom snippets that can be automatically called from within existing templates, instead of customizing whole templates and facing a hard time maintaining your custom templates and even upgrading your Red Hat Satellite server.

Learn about more tips and tricks you can use with Red Hat Satellite on our blog channel.