Pulling Strings With Puppet - James Turnbull [37]
We can also create single users and groups for particular purposes, for example, a user and group to run a daemon or application. You can see an example of this in Listing 4-11.
We can then include both the user and the group when we configure the appropriate service. We don't make this user and group virtual, as we're only going to be using them in one class.
Tip -* There is a useful script available at the Reductive Labs site that can convert a passwd file into a class containing all the users defined in the file. You can see the script at http://reductivelabs.com/trac/puppet/wiki/PuppetBestPractice#conv-passwd.
File Serving
Before we configure the services on our nodes, we're going to look at how Puppet does file serving. Puppet can act as a file server to deliver files to your nodes when required. The files Puppet serves out via file servers are called distributable files.
File serving with Puppet has both a server and client function. The server function is configured and initiated by the Puppet master daemon. The client function is embedded into the Puppet client daemon and retrieves files from the Puppet master file server. The file retrieval is done in individual resource definitions. You can specify a Puppet file server for the file type resource using the source attribute like so:
Let's start by configuring our file server. File server configuration is controlled by the fileserver. conf file, by default located in the /etc/puppet directory. You can specify an alternative location for the file by starting the Puppet master daemon with the --fsconfig flag like so:
The fileserver.conf file defines paths to serve files from and the access controls around those paths. In Listing 4-12, you can see an example of a typical configuration.
Each path being served is called a nodule. Listing 4-12 shows a module called configuration. The use of modules allows Puppet to abstract and simplify file system configuration and paths. The path statement specifies the location on the Puppet master server where the files being served are located. The path can contain one or more %h, %d, and %H dynamic variables. They are the client's hostname, domain name, and fully qualified domain name. All are based on the host and domain name used by the Puppet client's SSL certificate. This allows you to specify particular files to be downloaded based on these names, for example:
In this path statement, the %h variable would be replaced with the hostname of the connecting node and retrieve files from a directory named after that node like so:
There are also simple host- and IP-based access controls for file serving using an allowand-deny model. In Listing 4-12, we've specified both an allow and a deny statement. We're allowing access to all nodes in the testing. com domain and denying access to all nodes in the production. com domain. In your Puppet master logs, when you start the daemon, you should see an informational message for each mount module you define like so:
If you do not specify any deny or allow statements, file serving is explicitly denied. When working out whether a node has access, deny statements are processed and matched before allow statements. If, after processing all statements, no allow statements provide access to the module, the request is denied.
You can specify which nodes to allow or deny using a variety of formats: name, IP address, or the * symbol. You can see a few example statements on the following lines:
On the previous lines, we have denied access to the 10.0.10.0 Class C subnet, the host dev.testing. com, and all the hosts in the 10.0.20.x subnet. Lastly, we used the * symbol to specify a global allow.
Tip -► The file server function can be performance intensive and can result in performance impacts on the Puppet master server. This is particularly evident when you retrieve large numbers of files on multiple nodes. At this stage, there are limited solutions to this issue, but some discussions on scalability