Satellite 6 Duplicate Host Names with Puppet

Satellite 6, Red Hat’s patch, configuration, and deployment management one stop shop solution is a powerful tool. It is also a formidable and complicated piece of software. One of the big hurdles that I have run into when incorporating Puppet into Satellite 6 is that many of our systems do not use a fqdn (fully qualified domain name) for their host names. Which means that when I register “superawesomewebserver01” with Satellite 6 I get a host record that reflects the short name. This isn’t a problem until that same host connects with Puppet, its name is then recorded based on the certificate which is always the fqdn (i.e. “superawesomewebserver01.example.com” and results in duplicate host records showing up in Satellite, each as an independent object.

So, how can you fix this?

What you should not do… probably

Do not use  foreman-rake katello:unify_hosts on your Satellite server if you have connected it to a compute resource like VMware. Especially don’t do this if your Satellite user has full privileges to create, modify, and delete VM’s. Somewhere in the process of unifying the hosts, this script will delete the short name host record, which triggers Satellite to delete the host from VMware. Now in my case, I should note that people on our team had the foresight to not give Satellite the ability to delete virtual machines so I didn’t end up losing any critical data, or services. Instead, it ended up simply shutting down the target host, causing only a minor inconvenience for myself and the poor soul who happened to be on-call at the time.

If running this command is the best or only option you have, then I would suggest that you first disassociate all of your hosts from the compute resource that they are linked to. You can do this in the GUI from the “All Hosts” section. I’ve been trying to find a way to do this with hammer-cli but I haven’t seen anything that looks promising at the moment. Running the  foreman-rake katello:unify_hosts  command on a production Satellite 6 server, that has full permissions in your vm environment could be disastrous so be cautious…(I.E don’t run it just because someone from support asked you to) If you are not connected to a compute resource then this solution should work fine after registering all your hosts with Puppet.

A safer way to solve this problem

You can avoid the entire issue of duplicate host records by changing the name of each record (note I didn’t say the hostname of the actual machine) to the fqdn.

Foreman comes with a handy command line interface that will allow us to script this.

hammer host update --name <hostname> --new-name <hostname.example.com>

In my case, I gathered a list of the servers that I wanted to tack the domain name onto and put them into a file called “hostlist.txt” with each entry separated by a new line and used that list to iterate over a quick loop.

#!/bin/bash
hosts=$(cat shortnames.txt)
for h in $hosts
do
hammer host update --name $h --new-name $h.example.com
done

This will take a bit of time depending on how many records you are going to update, but it is far safer and quite a bit easier than many of the other solutions that I have found while digging through web forums.

Avoiding this problem in the first place

If you do use shortnames in your environment, one of the things you can do to avoid this problem in the first place is to use the fqdn when you initially register the host to Satellite. The subscription-manager package has an option to register a host with any name you choose.

sudo subscription-manager register --org='<organization>' --name <hostname.example.com> --activationkey='<key>'

I put this in an activation script and instead of hard coding a name I use –name $(hostname –fqdn) to make sure that I register each host with its proper fully qualified domain name.

This, I think, is the simplest way to avoid naming conflicts in the future. I’ve seen other suggestions about adding custom facts to new hosts to force subscription manager to use the fqdn, as outlined in this bugzilla report, and I’m sure that probably works just fine. I feel like this solution is a bit more flexible in that it allows you to use whichever name you want.

Author: Luke

Linux Systems Administrator RHCSA, LFCS, ITIL v3 Foundations.

Leave a Reply