Puppet Enterprise relies on having working name resolution available. Most commonly this is provided via a local hosts file, or organizational DNS servers. If you’ve installed Puppet Enterprise on a machine or two, and you find yourself staring at some alarming pink text (as shown below), you probably have an issue with name resolution in your environment.
Fortunately, there are good tools and procedures you can use to investigate name resolution problems.
When faced with resolution errors, I first like to test to see if they’re limited to the particular host I’m trying to reach, or symptomatic of a more general issue.
If you’re making use of the hosts file (e.g. /etc/hosts in most Linuxes) to locally define the mappings between the names of your machines and their IP addresses, you can very simply test whether that’s working as expected by trying to ping your master by name and seeing if the expected IP is used by the utility. If not, usually it’s an error in one of two places: the hosts file, or the configuration file that determines where your system will look for domain name mappings (e.g. /etc/nsswitch.conf in most Linuxes).
If you’re using DNS, you’ll need to break out some more interesting tools. In this example, I’ve used the dig utility to perform lookups of two fully qualified domain names (keep in mind that dig only performs lookups against name servers — it won’t use information from your hosts file). One is google.com, a known good name that should resolve successfully. The other is my Puppet master, puppet.ipa.vm. Google.com resolves successfully, but puppet.ipa.vm returns an “NXDOMAIN” status, indicating the request could not be resolved because the name does not exist.
This tells me I should double check my configuration and ensure I’m using the correct name for my Puppet server. If that checks out, the DNS server configuration needs to be examined to see if there is a bad or absent entry for the host.
Another possibility is receiving output like what you see below when testing resolution of a name.
This indicates that dig was unable to contact the configured DNS servers for some reason. The culprit in this case could be a number of things. We might have no network connectivity at all, or there could be something blocking the traffic. The locally configured DNS servers (found in /etc/resolv.conf on many Linuxes) might be incorrect, or be down.
The instructions above will point you in the right direction to remedy the most common name resolution issues we’ve seen. Once you’ve resolved yours, it’s time to get started with Puppet Enterprise. Here, too, there are just a few very common issues we often help people with. Ruth Linehan, a developer here at Puppet Labs, tells you which logs to check if something goes sideways.
Ken Johnson is a support engineer at Puppet Labs. When he's not helping people with a remarkable range of technical issues, he's fixing vintage arcade games or cars. Follow Ken on Twitter (@kjpdx) or connect with him on Google+.
- Download the Learning Puppet VM and get started right on your own laptop.
- Which logs to check if something goes wrong while using Puppet Enterprise.
- Quick start guide to using Puppet Enterprise.
- Extend your knowledge of Puppet Enterprise on your own or with instructor-led courses.
- Download Puppet Enterprise and try it out for free on 10 nodes.