Part 3 - Copying the same hosts file everywhere

In parts 1 and 2 we set up some skeleton manifests and ensured that communications between the clients and the puppet master is established, now lets actually copy some files around.

Improve the ''hosts'' class

We will start by putting a simple one-size-fits-all /etc/hosts file on all our servers, this is not ideal and we'll see later on how to improve on this, but it is important that we learn by baby steps.

Create a file with the following in /srv/puppet/fileserver/etc/hosts with the following text, please substitute IP addresses for your own:

127.0.0.1               localhost.localdomain localhost
192.168.1.10            dev1.devco.net dev1
192.168.1.5             puppet.devco.net puppet

• Puppetmaster runs as user "puppet" by default, you should be sure the user has access to these files and directories.

We will copy this file out to our node - dev1.devco.net - from the server using the File Type.

Now lets edit our previously created /etc/puppet/manifests/classes/hosts.pp file to look like this:

class hosts {
   file {"/etc/hosts":
      owner  => root,
      group  => root,
      mode   => 644,
      source => "puppet://puppet/files/etc/hosts"
   }
}

There's a lot happening here, lets run through the bits that we just added:

Each time a node includes the hosts class now they will have this file created (see /etc/puppet/manifests/nodes/dev1.devco.net.pp on the master), you've already done this on your node so if you wait maximum 30 minutes you should see something in the logs.

It's pretty simple stuff and you should be sure you understand each and every line in this file at this point else there will be issues later on, feel free to come ask for help on the #puppet irc channel.

Verify it worked

Lets verify the file is being created as it should be, go to your client node and tail the messages log file, after a few minutes you should see lines like these:

• You will see later on how to run tests interactively rather than wait 30 minutes after each change! You could also just restart the puppet service to kick it off.

dev1# tail -f /var/log/messages
Aug  7 19:57:16 dev1 puppetd[30144]: Starting catalog run
Aug  7 19:57:16 dev1 puppetd[30144]: (//Node[dev1.devco.net]/hosts/File[/etc/hosts]/checksum) checksum changed '{md5}cd0094053ff5fd61efbe6d2ee0ced49b' to '{md5}089c512a4b72a439ac232c04a081b037'
Aug  7 19:57:17 dev1 puppetd[30144]: (//Node[dev1.devco.net]/hosts/File[/etc/hosts]/source) replacing from source puppet://puppet/files/etc/hosts with contents {md5}489e8aaa49fb001e9330b733bf0073a8
Aug  7 19:57:17 dev1 puppetd[30144]: Finished catalog run in 0.32 seconds
^C

dev1# cat /etc/hosts
127.0.0.1               localhost.localdomain localhost
192.168.1.10            dev1.devco.net dev1
192.168.1.5             puppet.devco.net puppet

Why not do a simple test, edit the /etc/hosts file on the puppet client and you'll see that next time puppet wakes up it will undo your changes, you can also edit the copy on the master and you'll see this new version will go to the client.

Conclusion

We've now successfully copied a file from a central configuration management server to a client, you can do this now without a problem on 100s of clients, and if you edit the source file they will all get the new file within 30 minutes, similarly if some unexpected change happens on any of these 100s of clients that change will be reverted within 30 minutes. This will happen automatically and continuously.

It is crucial that you understand all the parts that has been involved to get you up to this point, you should be able to answer all these questions:

1. How does a client know which server to communicate with?
2. Where do you configure file serving on the puppetmaster?
3. What method is used to secure the communications between the master and a client?
4. How often will your client check in with the master?

5. What resource type is used to copy or manage files on clients?

6. How do we group several types into named groups that can then be applied to clients?
7. How does the master know which instructions should be executed on each client?

If you cannot answer all of these questions please ask on the #puppet irc channel on freenode, this is really the bare essential information you should know before we can move on to more advanced use cases. Some simple answers to these questions can be seen below, but you really should know this rather than simply reference the answers.

1. By default a dns lookup for the name puppet is performed

2. In the file /etc/puppet/fileserver.conf
3. SSL is used, the master is a certificate authority and should sign each client before they are allowed to talk to the master
4. 30 minutes by default, this is adjustable though

5. The file type is used to do this

6. We use classes that are stored in /etc/puppet/manifests/classes/

7. The node file in /etc/puppet/manifests/nodes/ for each host can include classes.

Move on to Part 4 now where we will build on this example to allow different nodes to get different hosts files using what we created thus far.