Getting Started With Puppet: How to Write Your First Module

1361349665_puppet-logoThis post will walk you through the process of writing your first, albeit, a very simple Puppet module. Nothing fancy here, that can come later once we get the basics down.

Before we get started let’s take a minute to go through a couple of prerequisites.

First, we will assume that you are doing your work some sort of Linux workstation or server. Second, we will assume that you have already installed and configured a Puppet Master and a Puppet Client. In this particular case, I am working on my Fedora 20 desktop. It serves as both my master and client. Last, we are assuming that have a basic site.pp and are able to run the Puppet agent without issue or error.

Now lets get down to the meat and potato. Note we are working with opensource Puppet, not Puppet Enterprise.

First lets change directory to our Puppet module directory.

#cd /etc/puppet/modules/

Now lets create a basic manifest from a template, to do this we need to generate a module. Our very simple module is going to be called harden-cron. Run the command below to generate our bare-bones module

#puppet module generate harden-cron

Now that our module has been generated lets change directories once again. This time we need to change to the manifests directory in our newly created module.

#cd harden-cron/manifests/ && vim init.pp

Now we need to edit our manifest. This is, more or less, our playbook. It defines what “work” puppet needs to do.

Our end goal is to create a manifest that will ensure that /etc/cron.allow exists, is owned by root, and has specific file permissions. We also need to make sure that /etc/cron.deny does not exist. In order to accomplish this we use the simple code shown below. Note that we have defined our class has “harden-cron”. This is the same name that we used when creating our module above.

[code language=”css”]

class harden-cron {

file {"/etc/cron.deny":
ensure => absent,
}

file {"/etc/cron.allow":
ensure => present,
owner => "root",
group => "root",
mode => "600"
}
}

[/code]

Now we need to test our syntax and make sure that we have not made any errors. Use the command below to accomplish this. No output from the script below means that you do not have any syntax errors.

#puppet parser validate init.pp

Excellent, so now we have a new module, but its not going to do anything for us until we declare it in our site.pp. So lets change directories and do a bit of editing

# cd /etc/puppet/manifests/ && vi site.pp

Continue reading

Advertisements

Puppet: How Not To Generate a Certificate with Your Correct Hostname

954f7381089ac290b4690c5ffd9dd7d3_400x400So, I’ve been hacking away in my homelab as of late, building out a CentOS kickstart server, a Git server, and a puppet server. Right now, I am working on how to roll my puppet agent installs into my kickstart process. I just started on this, so I have yet to nail it down.

So currently, when kicking a VM, I am not yet setting my new CentOS node’s hostname before the install process. Sadly I am setting it manually as I am still building my kickstarts, and they are no where near where I want them to be.

Well, this whole hostname mumbo-jumbo just creates all sorts of issues for puppet… the hostname is one thing initially, then puppet installs as part of the post, and the hostname is set manually to finalize the install. Well this is no good, as you are are not going to be able to add your new node properly until you step in and provide a bit of manual persuasion.

Now while its not hard to find documentation on how to troubleshoot puppet node and master certificate issues — see here and here for example — none of it was written to help troubleshoot the mess that I had created.

Here was my specfic error.

Error: Could not request certificate: The certificate retrieved from the master does not match the agent’s private key.
Certificate fingerprint: BE:B6:B6:5E:AC:B8: ..truncated

And here verbatim, is the output that you get in response to the error above.

To fix this, remove the certificate from both the master and the agent and then start a puppet run, which will automatically regenerate a certficate.

On the master:
  puppet cert clean localhost.localdomain

On the agent:
  rm -f /etc/puppetlabs/puppet/ssl/certs/localhost.localdomain.pem
  puppet agent -t

So we try that and it doesn’t work. The next cert I generate identifies my node as localhost again.

So heres how to fix the issue.

# rm -rf /etc/puppetlabs/puppet/ssl

Now before we generate another certificate for our node, lets test what hostname a new cert would have using the command below.

#puppet agent –verbose –configprint certname

If the command above does not spit out the correct hostname, then you my friend, are in luck. Edit the file below

# vi /etc/puppetlabs/puppet/puppet.conf

Now change the entry below by removing the localhost.localdomain, and replacing that mess with the correct hostname

certname = correcthostname.localdomain

Now kickoff a puppet run on the node

#puppet agent -t

Log into the UI, or ssh into the puppet master, and accept the new node request.

Kick off another puppet run after you have accepted the request to seal the deal and update the new node properly.

Related articles

How to Create a Vagrant Base Box from an Existing One
Some brief notes on Docker