Managing a Domain Name System DNS nameserver file with Puppet

Question

I need to manage a nameserver file for internal resources that aren’t published in public nameservers. I have several employee-maintained servers as a part of my infrastructure, and the DNS network assigned to those servers use Google’s public nameserver located at 8.8.8.8. However, there are several resources behind company’s firewall that the employees need to access on a regular basis. How can i manage this using Puppet?

Sirajul · Answer 1 · Jul 26, 2019

In this case, you could build a private nameserver (for example at 10.16.22.10), and use Puppet to ensure all the servers in your infrastructure have access to it.

The example below shows how to:

Write a module that contains a class called resolver to manage a nameserver file called /etc/resolv.conf.
Enforce the desired state of that class from the command line of your Puppet agent.

The first step is creating the resolver module and a template.

While some modules are large and complex, this module module contains just one class and one template

By default, Puppet keeps modules in an environment’s module path, which for the production environment defaults to /etc/puppetlabs/code/environments/production/modules.

This directory contains modules that Puppet installs, those that you download from the Forge, and those you write yourself.

Modules are directory trees. For this task, you’ll create a directory for the resolver module, a subdirectory for its templates, and a template file that Puppet uses to create the /etc/resolv.conf file that manages DNS.

From the command line on the Puppet master, navigate to the modules directory:

cd /etc/puppetlabs/code/environments/production/modules

Create the module directory and its templates directory:

mkdir -p resolver/templates

Use your text editor to create a file called resolv.conf.erb inside the resolver/templates directory.
Edit the resolv.conf.erb file to add the following Ruby code:

# Resolv.conf generated by Puppet 
<% [@nameservers].flatten.each do |ns| -%> 
nameserver <%= ns %> 
<% end -%>

This Ruby code is a template for populating /etc/resolv.conf correctly, no matter what changes are manually made to /etc/resolv.conf, as you see in a later step.

Save and exit the file.

That’s it! You’ve created a Ruby template to populate /etc/resolv.conf.

2. Add managing aaaathe resolv.conf file to your main manifest.

On the master, open /etc/resolv.conf with your text editor, and copy the IP address of your master’s nameserver. In this example, the nameserver is 10.0.2.3.
Navigate to the main manifest:

cd /etc/puppetlabs/code/environments/production/manifests

Use your text editor to open the site.pp file and add the following Puppet code to the default node, making the nameservers value match the one you found in /etc/resolv.conf:

$nameservers = ['10.0.2.3'] 
file { '/etc/resolv.conf': 
ensure => file, 
owner => 'root', 
group => 'root', 
mode => '0644', 
content => template('resolver/resolv.conf.erb'), 
}

From the command line on your agent, run Puppet: puppet agent -t

To see the results in the resolve.conf file, run:

cat /etc/resolv.conf

The file contains the nameserver you added to your main manifest.

That’s it! You’ve written and applied a module that contains a class that ensures your agents resolve to your internal nameserver.

Note the following about your new class:

It ensures the creation of the file /etc/resolv.conf.
The content of /etc/resolv.conf is modified and managed by the template, resolv.conf.erb.

3. Finally, let’s take a look at how Puppet ensures the desired state of the resolver class on your agents. In the previous task, you set the nameserver IP address. Now, simulate a scenario where a member of your team changes the contents of /etc/resolv.conf to use a different nameserver and, as a result, can no longer access any internal resources:

On the agent to which you applied the resolver class, edit /etc/resolv.conf to contain any nameserver IP address other than the one you want to use.
Save and exit the file.
Now, fix the mistake you've introduced. From the command line on your agent, run: puppet agent -t --onetime
To see the resulting contents of the managed file, run: