Pulling Strings With Puppet - James Turnbull [47]
Now we need to add our node configuration to the LDAP server. Let's take a quick look at the Puppet LDAP schema in Listing 6-7.
Caution - As the schema in Listing 6-7 indicates, the OlDs have been invented by Reductive. They could potentially conflict with other OlDs.
The Puppet schema is made up of an object class, puppetClient, and two attributes, puppetclass and parentnode. The object class puppetClient is assigned to each host that is a Puppet node. The puppetclass attribute contains all of the classes defined for that node. At this stage, you cannot add definitions, just classes. The parentnode attribute allows you to specify node inheritance.
In addition, any attributes defined in your LDAP node entries are available as variables to Puppet. This works much like Facter facts; for example, if the host entry has the ipHost class, the ipHostNumber attribute of the class is available as the variable $ipHostNumber. Attributes with multiple values are created as arrays.
You can also define default nodes in the same manner you can in your manifest node definitions, by creating a host in your directory called default. The classes assigned to this host will be applied to any node that does not match a node in the directory. If no default node exists and no matching node definition is found, Puppet will return an error.
You can now add your hosts, or the relevant object class and attributes to existing definitions for your hosts, in the LDAP directory. You can import your host definitions using LDIF files or manipulate your directory using your choice of tools such as phpldapadmin. In Listing 6-8 is an LDIF file containing examples of node definitions.
Listing 6-8 includes a default node, a node called basenode, and a template node called webserver. Each node has particular classes assigned to it, and the webserver node has the basenode defined as its parent node and thus inherits its classes also. Lastly, we define a client node, called wwwl, which inherits the webserver node as a parent.
Tip - Also available to help manage nodes is the iclassify tool, which you can learn about at http: //oss. hj ksolutions. com/iclassify/. You can download the code using Git from git clone git://hjksolutions.com/iclassify.
Puppet Scalability
As discussed in Chapter 1, Puppet is not yet a fully scalable solution as it has no built-in capability for high availability or load balancing between multiple masters. Additionally, Puppet is not yet fully ready for an enterprise-wide deployment as the built-in WEBrick web server, used to service the REST connections from Puppet clients, cannot yet scale to large numbers of clients. When connected, large numbers of clients, especially those using file serving, can cause performance issues and connection failures.
There are some workarounds for both high availability and load balancing. Solutions like Heartbeat (http: //www.linux-ha.org/), VRRP, or hardware load balancers can allow multiple master servers to be represented by a single IP address. Configuration can be shared between multiple masters using a distributed version control system like SVK (a distributed enhancement to Subversion) or Git.
Another workaround uses the Mongrel web server in lieu of the built-in WEBrick web server with a web proxy load balancing the client connections. This approach was developed by Puppet author Luke Kanies, Debian developer Marcin Owsiany, and Jeff McCune of the Ohio State University. In this section, I'm going to explain how to make use of this method to allow your Puppet environment to service a larger number of clients.
Note -► Version 0.23.1 or later of Puppet is required to support this approach. Puppet masters and clients using earlier versions do not correctly sign certificates.
The Puppet master daemon, puppetmasterd, normally uses the WEBrick web server internally to connect clients, but Puppet also supports using Mongrel as an alternative web server. Mongrel is commonly