Creating Provisioning Templates for Satellite

Latest response

We have been Kickstart building systems in our environment for some time now but are transitioning to use Satellite 6 for provisioning.

We are currently doing lots of custom directory creation, permissions, and file copies in the %post section of our existing Kickstart builds.

There does not appear to be a way to just point at an existing Kickstart file and import or build with it like there appeared to be in Satellite 5 documentation I've seen.

I see that I need to create a partition table and then use the PXELinux, provision, finish, and user_data provisioning templates. It looks like I need to split my Kickstart file between these four provisioning templates and the partition table. There doesn't appear to be a way to just extract content from a Kickstart file to populate the templates and partition table.

Everything I am seeing in the documentation talks about using these templates to build but there is nothing I can find on creating custom templates themselves. The provision template has the most code in it and is essentially useless to me.

I have almost no experience with Puppet.

What I am looking for and having absolutely no success finding are very fleshed out practical examples of each of these templates and the partition table so I can figure out what should go in which template and how it should be written.

Unless, of course, there really is some simple way to provision with existing Kickstart files.



Hi Lyle,

I've been experimenting with a new 6.1 server in the migration from our old satellite, and have some working configs that might be applicable to what you're trying to accomplish here.

I ended up cloning the default Provision Server template and adding all my changes to that. As much as possible, I tried to keep any specific customization out of the cloned Provision Server template (let's call that cps for short). Instead, I pull in different code based on whether certain host parameters are defined.

Here's an example: We have a semi-open public network which we'd like to define in iptables as our-network, then set the default iptables (I throw firewalld completely out if I find the OS level is 7) to a pre-written config that does this. I created the org default iptables config as a snippet (it's parsed by the same embedded ruby as the rest of the templates, but I treat this as a flat file for all intents.)

My snippet is called, simply enough, "iptables" and is suitable for dropping into /etc/sysconfig/iptables . I also decided that there would be a host parameter called "iptables-snippet" which would name an alternative snippet in case more customization was needed. An admin could then clone my snippet "iptables" to "iptables-clone" then set a host parameter iptables-snippet = "iptables-clone" and the code in the cps would insert that instead.

Here's what the cps code looks like:

# Setup iptables with default config
echo "Setting up iptables firewall"
cat > /etc/sysconfig/iptables << EOF
<%= snippet @host.params['iptables-snippet'] || 'iptables' %>
chmod 600 /etc/sysconfig/iptables
/sbin/chkconfig --level 345 iptables on

You can stick this anywhere after the %post line in the cps. By the way, the code to kill firewalld looks like:

<%if os_major == 7 -%>
<% end -%>

Just stick that in the %packages section somewhere.

Yes, it's more painful than writing %post scripts directly, but it's actually much easier to handle the little customizations you end up doing for each host this way. If you can abstract the differences to host parameters, then you won't need a whole forest of cloned templates, nor a pile of kickstart templates that requires alphabetical indexing to sort through (like on rhs5).

And apologies to the firewalld people if they're watching... I can't assume one posture per network interface in my shop.

I would like to have also more, deeper, information about it but I didn't find it yet. Mainly how it works and not how we write something there (for that is there a lot information).

Using try and error tests, we found something interesting on the way that provisioning works but it is very specific in our company because we can not use DHCP nor PXE. So, we made the deployment on two ways:

VMware templates based: The template was already created only with the core packages. If a new machine is created on this way, only one provisioning template is needed:

  • User data template. The default one on Satellite 6 has the name: "Satellite Kickstart Default User Data" and that sets the host specific settings. Some modifications could be needed on that one.

Network based with a server boot ISO file: The server is created using Satellite's connection with VMware. Then we download the host specific ISO file of the new created server and attach it to the virtual machine using the VSphere cliente (Big bug: Satellite does not add a CD-ROM drive and the default boot order is always network based, DHCP/PXE, and it cannot be changed easily). Then the ISO file boots the server and he uses only the next to templates:

  • iPXE template. It has a default one with the name "Kickstart default iPXE" and is used to set the network settings from Satellite (no modifications needed).

  • Provisioning template. The default one is "Satellite Kickstart Default" and there you can find a %post section if you want to made some changes during the kickstart. Some modifications could be needed.

We cloned that templates to customized them to our needs . The other templates like the "Finish templates" or "kexec" are useless for us because only with the 3 mentioned ones is the provisioning working.

When the machine is already created/installed, we apply the post actions using a job (Job template) and then puppet is in charge of the rest, but that is another story.

I hope that it could help.

Just for the record, upcoming version of Satellite will have ability to automatically attach bootdisk ISO to a VMWare VM. This should save you one step. The code is upstream already.

And also the capability to change the boot order of a created machines using Satellite's interface (VMware)? Because it cannot be changed even if you try it on the guest bios and it is useless to boot with the network device every time.

Yes, I believe the goal was to have complete workflow so new VMs are starting from the ISO automatically, but I haven't tried this myself yet.

I am looking to get this process of installing the os from satellite itself without attaching the iso.


Satellite 6 is new product, new workflow. We try to make the transition easier, but not all things are same as in version 5. Provisioning, for example, has completely different design. If you do not want to use shipped and highly configurable Kickstart templates, you can of course create your own from scratch.

To use existing Kickstart template, simply create new blank template with "provision" type and paste whole content of the existing template (from Satellite 5 or generated by Anaconda), then associate the template with OS and select it as default template in the Operating System page.

You do not need to "split it", it can be as simple as one single text file. You do not need to use any snippets, any ERB code (that's the code in <% and %> characters), it will work. The only limitation is much less integration with fields set in Host or Hostgroups. Also you will not take any advantage from defining network interfaces, but it is required to define at least one "provisioning" interface in order to PXE boot a system. The information provided (MAC, IP address, subnet) will be ignored if you use custom "plain" template, you need to make sure that "network" Anaconda statement is correct.

If you decide not to use Partition Table snippet, you simply keep a "dummy" snippet (can be empty) and associate it with an Operating System, but in your template you will not use the snippet. Having it separate allows you to easily do "ad-hoc" disk layouts when needed.

You can use Satellite 6 provisioning without Puppet just fine, in fact many customers do not use Puppet at all. In that case, simply do not install Puppet agent and ignore the Puppet Master and Puppet CA flags and Puppet tab when creating new host.