Pulling Strings With Puppet - James Turnbull [35]
Note - Remember, nodes can only inherit one node.
If we wanted to add multiple nodes of each template, we could add them in a list, each separated by commas, like so:
If we used our alternative include method, we'd create our nodes like so:
Again, if we wanted to apply our template classes to multiple nodes, we'd do it like so:
Our First Classes
As we defined our nodes, we also referenced our first classes. Let's create those classes now. We're going to create all our classes in a directory called classes under our manifest directory and import all of them into our configuration in our site. pp file (again, as we've already seen in Listing 4-1). I generally create each class in a separate file and giving the file the same name as the class itself, for example, baseapps.pp for the baseapps class. We then specify in our site. pp that Puppet should import the files in the classes directory. import "classes/*"
The previous import statement will import all files with an extension of . pp in the classes directory.
In Listing 4-4, you can see that the basenode class includes two classes, baseapps and sshd, in addition to including a class based on the operating system of the node we're managing, in this case the debian and fedora classes. In Listing 4-6, you can see our first two classes: baseapps and sshd.
Tip • To help with your manifest creation and editing, there is a VIM syntax validation file, puppet. vim, available athttp://reductivelabs.com/downloads/puppet/puppet.vim.
Our first two classes are simple. The baseapps class defines an array holding a number of packages: the joe editor, which my system administrators prefer, pert for our system administration scripts, and the rubygems Ruby package manager. This array is then added to the package type that will then install each package. The providers associated with the package type will then use each node's package management system to install the packages, for example, apt-get on Debian and yum on Fedora.
When we apply our class to each node, the packages will be installed if they are not already present. If a package needs to be installed, you'll see a log message indicating its change in status:
The second class, sshd, sets up the SSH daemon on all our nodes. The first resource ensures that, depending on the operating system on the node, the appropriate packages are installed. The second resource, Service[sshd], ensures that the SSH daemon is started. It uses the name attribute and a conditional statement to ensure the right service is started on each operating system.
We also defined two other classes, debian and fedora, which are loaded for the respective operating system. We're going to put these classes into the os directory and also import them into our site. pp file (again, we've already seen this in Listing 4-1).
In Listing 4-7, you can see both these classes.
In Listing 4-7, we've created two classes; the first is fedora, which loads whenever a node returns Fedora as the value of the $operatingsystem fact. It uses the yumrepo type to setup a yum repository for our environment. We've also used another fact, $lsbdistrelease, which returns the LSB release number to select the correct repository for the Fedora release we have installed.
On the following line, you can see the log entry indicating that the repository has been created:
The resulting repository will be created on your node.
The second class, debian, loads when Debian nodes connect, and it uses the service type to disable an array of services that we don't want running on our Debian hosts.
We could create and load classes for other operating systems and platforms or additional types to the operating system classes we've already created.
Managing Users and Groups
Once we've created our nodes, we're going to create some users and groups for our nodes. Puppet recommends that all users and groups be created as virtual resources and realized. We discussed virtual resources in Chapter 3 and why we use them. Virtual resources are not automatically configured on