2.4. Templating


Kickstart templating allows the inclusion of variables, snippets, and flow control statements such as for loops and if statements in the kickstart files. This is achieved using the cheetah tool.
There are a variety of reasons why templating might be useful:
  • Reusing a particular section of a kickstart, such as a disk partitioning section, between multiple kickstarts.
  • Performing some %post actions consistently across multiple kickstarts.
  • Defining a snippet across multiple server roles such as DNS server, proxy server, and web server. For example, a web server might have the following snippet defined:
    httpd
    mod_ssl
    mod_python
    
    Copy to Clipboard Toggle word wrap
    To create a web server profile, include the web server snippet in the %package section of the kickstart file. For a profile to be both a web server and a proxy server, include both snippets in the package section. To add another package to the web server snippet, mod_perl for example, update the snippet, and all profiles that are using that snippet are dynamically updated.
Variables

Templating allows the defining of a variable to be used throughout a kickstart file. Variables are subject to a form of inheritance that allows them to be set at one level and overridden at levels below them. So, if a variable is defined at the system level, it will override the same variable defined at the profile or kickstart tree levels. Likewise, if a variable is defined at the profile level, it will override the same variable defined at the kickstart tree level.

Note

Note that kickstart tree variables cannot be defined for automatically generated kickstart trees, such as those created when a satellite synchronization is performed.
Snippets

Snippets reuse pieces of code between multiple kickstart templates. They can span many lines, and include variables. They can be included in a kickstart profile by using the text $SNIPPET('snippet_name'). A snippet can be made for a package list, for a %post script, or for any text that would normally be included in a kickstart file.

To manage snippets navigate to Systems Kickstart Kickstart Snippets.
The Kickstart Snippets page displays several default snippets that cannot be edited, but are available to be used by any organization. Default snippets can be used in kickstarts that have been either written on or uploaded to the RHN Satellite server. Default snippets are stored on the RHN Satellite server's file system in /var/lib/cobbler/snippets/. There is a template from a wizard-style kickstart located in /var/lib/rhn/kickstarts/wizard/, which explains the different default snippets and how they are used.
The redhat_register snippet is a default snippet that is used to register machines to a RHN Satellite server as part of a kickstart. It uses a variable called redhat_management_key to register the machine. To use the snippet, set the redhat_management_key variable at either the system, profile, or distribution level and then add $SNIPPET('redhat_register') to a %post section of the kickstart. Any wizard-style kickstarts that are generated by the RHN Satellite server will already include this snippet in the %post section.
The Custom Snippets tab allows the viewing and editing of snippets created for use by the organization. New snippets can be created by clicking create new snippet. Custom snippets are stored in the /var/lib/rhn/kickstarts/snippets/ directory. RHN Satellite stores snippets for different organizations in different directories, so custom snippets will be stored with a filename similar to the following, where 1 is the organization ID:
$SNIPPET('spacewalk/1/snippet_name')
Copy to Clipboard Toggle word wrap
To determine the text to use to insert the snippet in the kickstart, look for the Snippet Macro column on the snippet list, or on the snippet details page.

Note

Snippets exist at a global level and do not share the same inheritance structure as variables. However, variables can be used within snippets to change the way they behave when different systems request a kickstart.

Figure 2.3. Kickstart Snippets

Escaping Special Characters

The $ and # characters are used during templating for specifying variables and control flow. If these characters are needed for any other purpose in a script, they will need to be escaped so that they are not recognized as a variable. This can be achieved in several ways:

  • Placing a backslash character (\) before every instance of $ or # that needs to be ignored during templating.
  • Wrap the entire script in #raw ... #end raw
    All %pre and %post scripts created using the wizard-style kickstarts are wrapped with #raw...#end raw by default. This can be toggled using the Template checkbox available when editing a %post or %pre script.
  • Include #errorCatcher Echo in the first line of the snippet.

Example 2.1. Escaping Special Characters in templates

This example describes how to escape special characters in kickstart templates.
The following bash script needs to be inserted in a %post section:
%post 
echo $foo > /tmp/foo.txt
Copy to Clipboard Toggle word wrap
Without the $ being escaped, the templating engine will try to find a variable named $foo and would fail because foo does not exist as a variable.
The simplest way to escape the $ is by using a backslash character (\):
%post 
echo \$foo > /tmp/foo.txt
Copy to Clipboard Toggle word wrap
This will cause \$foo to be rendered as $foo.
A second method is to wrap the entire bash script in #raw ... #end raw, as follows
%post 
#raw  
echo $foo > /tmp/foo.txt 
#end raw
Copy to Clipboard Toggle word wrap
The final method is to include #errorCatcher Echo in the first line of the kickstart template. This instructs the templating engine to ignore any variables that do not exist and print out the text as is. This option is already included in the wizard-style kickstarts, and can be included in any raw kickstarts created manually.
Back to top
Red Hat logoGithubredditYoutubeTwitter

Learn

Try, buy, & sell

Communities

About Red Hat Documentation

We help Red Hat users innovate and achieve their goals with our products and services with content they can trust. Explore our recent updates.

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. For more details, see the Red Hat Blog.

About Red Hat

We deliver hardened solutions that make it easier for enterprises to work across platforms and environments, from the core datacenter to the network edge.

Theme

© 2025 Red Hat