Introduction

We’ve covered a lot of ground already in our tutorials thus far.  In Tutorial I we installed our Puppet server.  In Tutorial II, the client, and in Tutorial III we configured the server and client to start communicating.

In this 4th installment, we’ll cover the signing of SSL certificates between your Puppet Master and Client, and running a simple test to ensure your setup is working and ready to function as a master=>slave pair.

On your server, be sure to start up the Puppet Master, so it can receive connections from outside sources, like so:

sudo service puppetmaster start sudo chkconfig puppetmaster on

Next, on your Puppet client, run a test run so the client will start, create an SSL certificate for the client host, and make an initial callout to the server.  It will exit immediately, but the server will now know about the client, and we can sign the certificate over there.

puppet agent -t

When you run this command, the output should look something like this:

[caption id=“attachment_625” align=“alignnone” width=“720”] Certificate Signing Request Example[/caption]

Now, SSH to your Puppet Master, and run the following command:

puppet cert –list

If everything has gone well, your server will have now seen your client and will report as much like so:

[caption id=“attachment_627” align=“alignnone” width=“719”] Server Cert Requests in Waiting[/caption]

Finally, so sign the certificate so there is an SSL connection between the client and server, and all future Puppet actions between the two pass over that connection, simply sign the certificate request on the master as follows:

puppet cert sign puppetclient.example.com (or whatever your hostname is)

 The server will sign the certificate and make a tabular listing of it in its database finalizing the connection.  You can see this output by using the “list all” options as follows:

puppet cert list –all

and see the output which should resemble the following:

[caption id=“attachment_635” align=“alignnone” width=“718”] Signed Certificate[/caption]

Conclusion

Now we’re ready to do work with Puppet.  You can actually stop here and fully manage your site with Puppet, however there are several addons and feature-sets yet you can install to expand Puppet’s functionality.  We will look at some of these tools in future installments.

I’ll be speaking Thursday evening at 7PM at the SE Puppet User Group meeting.  The topic will be “Intro to Puppet” and all are welcome.  Come early (6:30) and come hungry, as we’ll be having pizza to get started.

Current “Working” Agenda:

Agenda:

-630p - 700p Pizza/Networking -700p - 800p - Introduction to Puppet w/ Jerald Sheets

1. What is Puppet?
2. How does it work?
3. Puppet benefits?
4. Major components of Puppet (Server / Client)

-800p - 830p - Q/A

Location: 8302 Dunwoody Place, Suite 100 Atlanta, GA 30350

[wpgmza id=“1”]

I hope to see you all there.

By now you should have 1 Server installation completed and 1 Client installation completed.  The only thing you’re missing now is to link the two together.  The following client side configuration will be performed on ALL existing systems you have, to connect them to the server and to pull their configuration catalog down and apply the changes to the local host.

Certificates

By default, all communications in Puppet goes over SSL channels.  You can configure Puppet to use its own certificate signing mechanism or to use an external signing authority (outside the scope of this tutorial).  The signing process does two things.  First, it authorizes your client to communicate with the Puppet Master and receive configurations and keeps all that traffic secure from prying eyes.

Node Lists

Of course, the master needs a way to enumerate what hosts will be connecting, and how to apply what configuration where.  We’ll look at node classification both on and off the host as well.

Server Configuration

Here we go.

To get the server and client talking, there is a small amount of configuration that has to happen.  It essentially tells the server who will be calling, and tells the caller the server’s “phone number”.  Very short and simple.  So, let’s do that first.

Configs

Two files require editing on the server to prepare for your first Puppet run.  They are:

/etc/puppet/manifests/site.pp /etc/puppet/manifests/nodes.pp

As of this writing, the OSS installation does not place either file, so you will have to create them.  Make their content as follows:

site.pp

import ‘nodes.pp’ $puppetserver = ‘--FQDN--’

These two lines lay the foundation for the server’s self-declaration as authority on configuration.

The first line: “import nodes.pp” tells Puppet to look for the nodes.pp file you are about to create in the next step for node definitions (and thus their individual configurations) and the next line indicates this puppet servers' complete name.  This line is very important, as configurations throughout the Puppet software product and the client node software continually refer back to this variable.  This setting takes the form of the fully-qualified-domain-name of the server.  It is recommended you use “puppet” as the name of the server in your infrastructure.

So if your site’s name is “bob.com”, this line would be:

$puppetserver = 'puppet.bob.com'

While any hostname should do, I might mention one caveat you should be aware of should you decide to use something other than ‘puppet.x.x’ formatting.  In the event your Puppet server cannot see or read the $puppetserver value, the internals of Puppet cause it to default to “puppet”.  To avoid any strange outage-based silliness, I would recommend sticking with the puppet name.  While this may cut cross-grain with your particular host naming system, there is no reason why the root name of the system cannot be puppet.domain.com and you CNAME your super-special host naming to that.

Why not the other way around?  I’ve seen in the wild situations where Puppet (especially as it concerns certificate signing) take the output of gethostbyname() for signing over a designated CNAME, even when you set this variable to the appropriate value.  Rather than deal with the mess, I recommend the former.

Close the site.pp file.

Next, you’ll want to configure your nodes.pp file.  Now, keep in mind that while we are specifying our nodes manually in this file for the purposes of this tutorial, we will be doing all manner of really cool things with node designations in the future.  So, for now humor me, and I assure you we’ll step into the wonderful world of the ENC, Dashboard and other goodies all too soon.  Right now, we’re just trying to get Puppet up, connected, and talking.

nodes.pp

  node '--FQDN--' { }

Here we are specifying our very first node, letting the master know it’s allowed to connect, and eventually putting a number of things in-between the curly braces {} specifying the configuration for (or pointers to the configuration for) our client node.   Just as above, the “FQDN” piece in between the single tics should be replaced with the fully qualified domain name of the client host you wish to manage.  As above, in our fictitious domain of “bob.com”, we will simply call this host “puppetclient.bob.com”, thus making the content of the nodes.pp file:

  node 'puppetclient.bob.com' { }

For now, there’s no need to  add configuration.  This is all we need to get started.  Exit from the nodes.pp file, saving it into the aforementioned spot of “/etc/puppet/manifests/nodes.pp”

Here ends the server-side configuration for this portion of our tutorial.  On to the client configuration.

Client Configuration

For the client configuration, a base-level file has already been provided for you, and only needs some customization.

The client configuration file is found at /etc/puppet/puppet.conf on the client (as well as the server).  The puppet.conf configuration file is an “ini-style” configuration file with [bracketed] headings and “key = value” line by line variables.

For our initial configuration we will be adding a couple lines.  First of all, at the end of  the [main] section, add the following line:

server = FQDN of the server

or, as above

server = puppet.bob.com

Next, in the  [agent] section, the following three lines (for our fictitious “bob.com” domain)  should be added at the end:

report = true server = puppet.bob.com certname = puppetclient.bob.com

The server line appears to me to be somewhat redundant, but I’ve always placed it in both locations, and cannot comment as to whether it is NOT needed.  The certname, FYI, is the FQDN of the client host you are configuring to connect to the server.

The purpose of the “certname” variable should be explained here a bit.  This is the name you placed in the “nodes.pp” file, and is also the hostname that is passed to the master in the key signing process.  You want all locations in which you’re specifying your node name to agree (puppetclient.bob.com in our example), so it’s highly important to ensure consistency throughout.

Ready to Connect

Ok, let’s recap…

We’ve set our site.pp and nodes.pp files in place on the server, specifying the server name and ensuring there is a FQDN node designation in the nodes.pp.  Next up, we’ll make our first connection to the server and test the connection.

In our last installment “Puppet I - Server Installation”, we covered all the basic necessities of installing Puppet Open Source server.  Of course, a server in and of itself is no good unless we have a client on another host to connect to it.  This article will similarly lead you step-by-step through the process of installing the client.

Puppet Client

Installation of our client is not so very much different than the initial server install.  Both come from the same Yum repository, and both need the same support libraries and files.

As expected, a client will need the OS installed (again, we’re working on the assumption of RedHat Enterprise Linux, but CentOS, SecurityLinux, etc. should do fine.

Once your operating system is completely installed, just as before we’ll need to follow the same steps of getting RedHat registered, the RHEL Yum repo enabled, the Puppet Labs repo configured, the correct support repos added, and finally, the client installed.

Enabling the RHEL Yum Repo

Just as we did before, we register our RedHat installation via “subscription manager” from RedHat.

sudo subscription-manager register sudo subscription-manager auto-attach sudo subscription-manager attach –auto sudo subscription-manager refresh

As I mentioned before, RedHat’s tool isn’t 100% effective 100% of the time, and some level of redundancy in the commands above ensures all the appropriate bits get twiddled.

Installing the Puppet Labs Software Repository

Again, as before, we simply use RPM to get the repository installed (the below command is all on one line):

**_sudo rpm -ivh https://yum.puppetlabs.com/el/6/products/x86_64/puppetlabs-release-6-10.noarch.rpm_**

Enabling Additional Packages

Once again, the “optional” RedHat packages and the “development” PupeptLabs repositories have to be enabled.  You can either use the Yum Config Manager or edit the repo files directly, your choice.  Yum Configuration Manager commands are as follows:

sudo yum -y install yum-utils sudo yum-config-manager –enable rhel-6-server-optional-rpms sudo yum-config-manager –enable puppetlabs-devel

You should note that the “enable” command above actually has two hyphens in front of it instead of one long one.  WordPress concatenates those.

Get Current!

Now is the time to get RHEL completely up to date through the usual means:

yum -y update

Install the Client

yum -y install puppet

If all goes well, this will complete the client config on your client host and you are now ready to configure the server, configure the client, and then connect them via SSL as provided by Puppet Labs.

In our next edition, we’ll be doing just that.

Ok, so you’re interested in this whole Puppet thing, and you want to get a full install in your test environment, or on a set of VMs to work and play with the product.  PuppetLabs has a ton of really cool documentation, and you should certainly avail yourself of it, but I wanted to give you a quick “cookbook” style set of instructions to get you rolling.

Puppet Master

There is a lot of documentation surrounding the Puppet Master installation at Puppet Labs, but I find a bit of obfuscation when trying to parse through the huge pile of meat that is there, when all we’re looking for is the best of it… you know, the bacon.  :)

Puppet Code Repository & Package Source

Puppet Labs provides a myriad of repositories and methods by which to install Puppet.  I tend to stick with the main PuppetLabs repository whenever possible.  I also tend to like RedHat derivatives, so I’ll be talking about RHEL here, but the same applies to CentOS, Scientific Linux, and other RHEL “children” in the ecosystem.  In short, if you’re using something else other than RHEL, you may find yourself hunting packages and repos that contain packages you’ll need that the repositories I list here have by default.  As with any web-based documentation, YMMV.

Installing the Puppet Master

First, you’ll need a functioning Installation of RHEL upon which to install and configure Puppet.  I like to include only the “Base Install” and take the “Defaults” when doing a “special purpose” server, as it doesn’t muddy the waters and it gives you the cleanest slate possible upon which to build your Puppet platform.

Enabling the RHEL Yum Repo

As I’m sure you’re aware, to use RedHat’s repositories, you have to register and have active a subscription with RedHat.  To do a simple connection/attachment to the RedHat repositories, I’ve found a mixture of success with the Subscription Manager.  However, by performing the following commands (some are redundant), I’ve been able to get the configuration working with 100% reliability:

sudo subscription-manager register sudo subscription-manager auto-attach sudo subscription-manager attach –auto sudo subscription-manager refresh

Obviously, this is a RedHat topic, and not a Puppet one, so if you’re having issues with this process, contact Redhat for help.  The crux of this, however, is to just register your instance.

Installing the Puppet Labs Software Repository

Since I’m working with the current 6.10 release of Puppet, the package you need to install can be added by running:

_**sudo rpm -ivh https://yum.puppetlabs.com/el/6/products/x86_64/puppetlabs-release-6-10.noarch.rpm**_

This will install the current 6.10 release of the Puppet repo from which we can continue with the Puppet Master installation.

Enabling Additional Packages

Next, we need to have the “optional” set of packages from RedHat and the development packages from Puppet Labs.  There are two ways to do this.  First, you can edit each repo file in /etc/yum.repos.d (red hat.repo and puppet labs.repo respectively) and change the “enable” flag on each repository from “0” to “1”, or you can simply run the provided RedHat Yum configuration manager tool to do it for you as follows.

sudo yum -y install yum-utils sudo yum-config-manager –enable rhel-6-server-optional-rpms sudo yum-config-manager –enable puppetlabs-devel

Get Current!

Bring your current host completely up to date by querying the repositories and running the yum updater:

sudo yum -y update

As I’m sure you’re aware, depending on the updates released since the current major version of your repositories, the update time can vary from very short to quite some time.  Just be patient and get up to date before proceeding.

Install the Puppet Prerequisite Packages

This step name is a bit of a misnomer in that I am including a ton of packages that aren’t necessary for a “base” install of Puppet Server, but they do support later installations you may wish to do (like PuppetDB, Dashboard, Passenger, etc.).  I just wanted to give a complete list so there’s no after-installation required just to get moving with the next component.  Simply install the following via Yum:

sudo yum -y install gcc libcurl-devel gcc-c++ openssl openssl-devel ruby-devel httpd httpd-devel  mod_ssl policycoreutils-python apr-devel apr-utils-devel

Prep Your Firewall

You may or may not be using the IPTables Firewall, but you’ll want the following rule in place to support the Puppet Master port.  Simply insert the following line into your /etc/sysconfig/iptables file.

-A INPUT -m state –state NEW -m tcp -p tcp –dport 8140 -j ACCEPT

Note that if you intend to install the Puppet Dashboard as well, you can add that port here too.

-A INPUT -m state –state NEW -m tcp -p tcp –dport 3000 -j ACCEPT

Make sure you place your firewall rules in the appropriate place in the file.  While outside the scope of this article, IPTables has an order and a format you should follow.  You can find out more here.

Lastly, restart your firewall to pick up the new rules:

sudo service iptables reload

Install Puppet Server

After all the above work, if you’ve had no repository or package errors, your system should be ready to install Puppet Server.  Simply run the following:

yum -y install puppet-server

Conclusion

And that should be it.  All packages installed, base RedHat updated with all the latest Ruby & RedHat goodness, and the bad Puppet Server installed and ready for action.

Next time:  Installing the Puppet Client.

I’m speaking tonight at the Atlanta Perl Mongers meeting at the Central Cox building in Dunwoody at 7PM on Puppet Configuration management.  Please do feel free to drop by and say hello.  If you cannot make it, however, here’s my slide deck all compressed down and PDF-ified for your viewing pleasure.

Perl Mongers Puppet Presentation:Training

I hope to see you there!

I guess you Atlanta folk will get that one… :)

Howdy all, and a hearty hello.  I’m back from my exile to the land of single shiny glowing buttons and happiness, rainbows, and OSX, and have returned to Atlanta with SysAdmin bells on.  I’ve done a lot over the last couple years (much I cannot talk about), but have developed quite an affinity for the Puppet configuration Management system.  So much so, in fact, that I’ve found a need to start a whole new category right here on the ol' blog to accommodate.

Not in a long time have I liked something “new” that has come along to SysAdmin work… The moniker “Devops” still gives me hives, but I will endeavor to navigate the puppet-y waters without uttering the vile mantra but wading into the wonderful waters of automation and  managed infrastructure.

In short, “Puppet” in and of itself is quite a feat of engineering.  A series of platform tools to enforce a single “blessed” configuration upon your infrastructure in a consistent, premeditated way from a central location, eliminating the need for all manner of scripting and “loop lists” to do individual functions on each system, one at a time.  No no!

Puppet enforces policies you write in a uniform, secure way, rather quickly and scales rather well for most environments.  For the larger environments that cannot be scaled to, Puppet will utilize other “workhorse” industry standard products as modular replacements of various pieces of the Puppet system, to broaden and expand its abilities.

Puppet comes in two flavors, the commercial “Enterprise” system where everything is packaged together and all gets installed and configured at load time in an “automagical” sort of way so you don’t have any need to post-configure, but can just begin writing configurations immediately.

The “Open Source” Puppet has most of the same pieces, although named somewhat differently, and you can build a very solid, full-featured system of your own without the price tag.  All you need is time.  :)

In the coming sections, I will take apart Puppet for those of you wishing to know more, and give a rudimentary survey of all the different things it can do.  Hope you come along!

And just HAD to make my own.  Enjoy!

I think it is important to make a note about all of the people and places that have helped me ferret out a lot of this configuration.  I don’t find this stuff in a vacuum (like anything in the Open Source world), and find it quite important to give a nod where a nod is due.

First, to Turner Broadcasting who gave me my first shot at doing this in a relatively small environment.  There was a ton of time spent on the phone, in online forums, reading documentation, and the like.  Everything sort of proceeded from there.  I tried to get such a thing into the backend over at The Weather Channel, but the climate wasn’t right, and there was a great deal of change going on.  Trying to implement such a thing there just wouldn’t have worked out very well.

Next, to Incomm.  They needed a solution, and Brock (my boss) gave me ample time to get a lot of this together, and to do it right without interruption.  Big thanks there.

Finally, and most importantly, my best bud John Beamon.  He encountered and worked with LDAP long before I did.  And, while we have considerably different directories in place between our two mutual organizations, his help in putting together how all this works in my head has been invaluable.  I daresay I’ve been into his IM client twice (or more) often as he’d like, gave him props nowhere near as much as I should (like at all), and even with all his own work on his plate, he has helped me out immeasurably.  Add to that, he’s a long-time friend and fellow-minister, and that’s just good times right there.  They don’t come along like John very often, and I’m grateful to have him as both a friend and fellow nerd.

Kudos, JB!

I’m sure there’s still some inaccuracies here, and I’ll be sifting through all this as I continue to build and extend OpenLDAP in this environment.  Things will automagically correct before your eyes, most likely.  If you find anything that happens to scream “No!” to you, feel free to drop me a line, and I’ll be happy to make that change.

HappyLDAPping!

_This article goes hand in hand with “LDAP Administration - Part I” in regards to configuring the client. _

So, let’s see where we are.  We have a master server you will be doing all administration work on.  This master server replicates to two hosts in the environment that serve LDAP queries to your clients.  These servers are replicants and are load-balanced under a VIP that is pointed to by the name you choose.  (in our case, ldap.bob.com).  You can change passwords at the client level, and have it pushed back up to master and replicated out to the environment immediately.

Finally, we need to talk about security.  There’s a number of ways to do security, but RedHat has done a lot of the footwork for you.  Unfortunately, it’s very poorly documented, and they really Really REALLY want you to use RedHat Directory Server for everything, so I don’t guess it’s a priority.

Essentially, we want to secure all queries floating around the network with TLS.  In a RedHat world, you simply need to make a couple changes at the server, restart LDAP, and then connect from TLS-enabled clients and all works just as it did before, except now it runs over an encrypted channel.

First Steps

RedHat has tried to ease the pain of generating certificates by placing all you need in a Makefile on-box.  navigate to /etc/pki/tls/certs and see that there is a makefile there.  Next, run:

make slapd.pem

to generate the needed files.  If it has already been done for you by the system, you will get the answer:

make: `slapd.pem' is up to date.

If you get this message, you’re halfway there.

Next, edit the /etc/openldap/slapd.conf file.  You will need to refer to the appropriate files to allow for secure operation.  Insert the following lines into that file:

# TLS Security TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt TLSCertificateFile /etc/pki/tls/certs/slapd.pem TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem

Next, edit the file /etc/sysconfig/ldap.  Make the following lines:

SLAPD_LDAP=yes SLAPD_LDAPS=no SLAPD_LDAPI=no

look like:

SLAPD_LDAP=no SLAPD_LDAPS=yes SLAPD_LDAPI=no

Then, restart LDAP:  /sbin/service ldap restart. This does two things.  First, it tells the client where to look for the certificates, and then tells the system to only serve from the secure port 636.  (recall that we are on the replicants which are, in turn, servers themselves.  We have handled connecting to the master as well as setting the replicant up to receive queries)

Finally, we connect a client.

Connecting the Client

To allow a client to connect, you need the appropriate key on the client (public server key) to be able to exchange identities with the server, and establish the secure session.  To do this, you have to distribute this key you just made out to each client you wish to connect back to the server.

The key you will be distributing lives in /etc/pki/tls/certs and is named ca-bundle.crt.  Simply move this cert to your client (I use scp for such an operation) and place it into your openldap cacerts directory like so:

scp -rp ca-bundle.crt host.bob.com:/etc/openldap/cacerts

If you don’t have rights to copy straight into the destination, send it to your home directory, then just move the cert there using “sudo”.

Finally, you need to tell the system about the cert.  This is done in /etc/openldap/ldap.conf via three lines that tell the system how to connect, and where the cert lives:

TLS_CACERTDIR /etc/openldap/cacerts TLS_CACERT /etc/openldap/cacerts/ca-bundle.crt TLS_REQCERT allow

Next, we run the RedHat authentication gui tool (curses) called authconfig-tui. _**(Note: last time I had you hand-edit the /etc/openldap/ldap.conf file, and this is entirely still possible.  I am endeavoring to show you that there is a tool to do this work, should you desire to use it.  If not, simply add the above lines and change the URI to the one below, making sure /etc/nsswitch.conf is configured correctly, and you should be good to go.)

**_

In the left column, select “Use LDAP” and in the right column “Use LDAP Authentication”.  Tab down to the “Next” button and press “Enter”.

As misleading as “Use TLS” may be, do not select it.  :)  Instead, go down to your server line, and modify it like so:

ldaps://ldap.bob.com:636

Your base DN should already be filled out (in our case: dc=bob,dc=com).  Navigate to the “OK” button, and press “Enter”.

This should conclude your client configuration.  Now, you should be able to run a query against LDAP, and the whole path be secure:

id bob uid=123(bob) gid=123(users) groups=123(users),456(bob)

Conclusion

I’m sure I’ve missed or glossed over something highly important.  I am in the process of discovery on this particular topic, and this article is serving as my documentation store until I can get the whole thing cleaned up & finalized to push back into my work environment as official documentation.  I’ll correct here as I find mistakes and omissions.