Introduction:-
Prerequisite : Ruby and all ruby Library
Rpm Repository for Puppet
rpm -Uvh facter-1.3.7-1.el5.noarch.rpm puppet-0.22.4-1.el5.noarch.rpm
puppet-server-0.22.4-1.el5.
Server Preparation
puppet-server-0.22.4-1.el5.
Server Preparation
The server (puppetmasterd) requires a manifest to be in place before it’s able to run. Lets write a manifest that tells puppet to create a file “/tmp/testfile” on the client.
puppet:# vim /etc/puppet/manifests/site.pp
# Create “/tmp/testfile” if it doesn’t exist.
class test_class {
file { “/tmp/testfile”:
ensure => present,
mode => 644,
owner => root,
group => root
}
}
# tell puppet on which client to run the class
node pclient {
include test_class
}
Managing nodes in Puppet
Once the puppet master is installed, we need to do some basic configuration and then start the daemon. Puppet operates not by executing scripts but by applying what are called manifests against target hosts. A manifest is a Puppet configuration document that describes the target configuration and the steps required to achieve it. Your manifest files also contain the definition of each of the hosts to be managed, which Puppet calls ‘nodes’.
Each puppet master server requires a master manifest, called a site manifest. The site manifest is stored in the file /etc/puppet/manifests/site.pp. You’ll need to create this directory like so:
# mkdir /etc/puppet/manifests
You can see an example of a site.pp file below.
You can see an example of a site.pp file below.
class base_etc {
file { “/etc/passwd”: owner => root, group => root, mode => 644}
file { “/etc/sudoers”: owner => root, group => root, mode => 440}
}
file { “/etc/passwd”: owner => root, group => root, mode => 644}
file { “/etc/sudoers”: owner => root, group => root, mode => 440}
}
node default {
include base_etc
}
The site manifest file can contain all the instructions you want to use on your managed hosts or can import the contents of other files to enable you to better structure your configuration instructions. Take a look at this example:
include base_etc
}
The site manifest file can contain all the instructions you want to use on your managed hosts or can import the contents of other files to enable you to better structure your configuration instructions. Take a look at this example:
import “nodes.pp”
import “classes/*”
The above configuration would import the file nodes.pp and all the files in the classes directory. All directories are assumed to be under the /etc/puppet/manifests directory.
import “classes/*”
The above configuration would import the file nodes.pp and all the files in the classes directory. All directories are assumed to be under the /etc/puppet/manifests directory.
In our example, site.pp file, we’ve specified a class called base_etc. Classes are containers for sets of instructions. In this case, the container holds two instructions, both using the file resource that sets the ownership and permission of the /etc/passwd and /etc/sudoers files. The file resource allows you to create files and directories or specify their permissions and ownership.
The file resource is one of a number of resource types, including types that can manage cron entries, host entries, manage packages, start and stop services or manage users. Each of these resource types can have multiple implementations, called providers, where each provider resource is designed for a different system. For instance, there are multiple file resource providers to cater for file operations on Linux, Unix, Windows and other platforms. This is one of the great strengths of Puppet; a single configuration language that can be interpreted appropriately on multiple target hosts running on different platforms.
We’ve also defined a node called default. The default node is a special definition that allows you to define sets of instructions that are applied to all nodes except those explicitly defined in your configuration. This allows you to specify a baseline configuration to all nodes without having to specifically define all nodes. We can also define other nodes in here (or in another file and import them).
A typical node definition looks like:
node goldfish {
include apache
}
node ‘salmon.testing.com’ inherits default {
include mysql}
Nodes are defined either by their simple name or a fully qualified domain name. If you use the fully-qualified domain name, then it must be encapsulated in single quotation marks. In our example, both the goldfish and salmon.testing.com nodes have been defined. Each node uses the include statement to specify particular classes that apply to them, which in this case are the apache and mysql classes, respectively. We’ve also specified that the salmon host also inherits the configuration of the default node.
node goldfish {
include apache
}
node ‘salmon.testing.com’ inherits default {
include mysql}
Nodes are defined either by their simple name or a fully qualified domain name. If you use the fully-qualified domain name, then it must be encapsulated in single quotation marks. In our example, both the goldfish and salmon.testing.com nodes have been defined. Each node uses the include statement to specify particular classes that apply to them, which in this case are the apache and mysql classes, respectively. We’ve also specified that the salmon host also inherits the configuration of the default node.
Starting and configuring Puppet
Once you’ve created your site.pp file you can start the puppermasterd daemon. The Puppet RPMs come with an init script for Puppet, but we’re going to start it manually on the command line:
# /usr/bin/puppetmasterd –verbose
The –verbose option tells the puppetmasterd not to daemonize and to output all logging messages on the command line. If you omit this option, Puppet will daemonize by default. The Puppet master listens on port 8140 (you’ll need to ensure your clients have network connectivity and access through any firewalls to this port on your Puppet server). You can also change a variety of configuration options for your Puppet master daemon by editing the /etc/puppet/puppetmasterd.conf file.
# /usr/bin/puppetmasterd –verbose
The –verbose option tells the puppetmasterd not to daemonize and to output all logging messages on the command line. If you omit this option, Puppet will daemonize by default. The Puppet master listens on port 8140 (you’ll need to ensure your clients have network connectivity and access through any firewalls to this port on your Puppet server). You can also change a variety of configuration options for your Puppet master daemon by editing the /etc/puppet/puppetmasterd.conf file.
Now you need to install Puppet on one of your client nodes. We also need to install Ruby and the Ruby libraries on the client node and then we need to download and install the Puppet and Facter RPMs.
# wget http://people.redhat.com/
# wget http://people.redhat.com/
# rpm -Uvh facter-1.3.7-1.el5.noarch.rpm puppet-0.22.4-1.el5.noarch.rpm
Next, we need to configure the puppet.conf configuration file to tell it about our Puppet master server. The puppet.conf file is installed into the /etc/puppet directory. You can see an example of this file below.
[puppet]
vardir = /var/lib/puppet
logdir = /var/log/puppet
rundir = /var/run/puppet
ssldir = $vardir/ssl
# wget http://people.redhat.com/
# rpm -Uvh facter-1.3.7-1.el5.noarch.rpm puppet-0.22.4-1.el5.noarch.rpm
Next, we need to configure the puppet.conf configuration file to tell it about our Puppet master server. The puppet.conf file is installed into the /etc/puppet directory. You can see an example of this file below.
[puppet]
vardir = /var/lib/puppet
logdir = /var/log/puppet
rundir = /var/run/puppet
ssldir = $vardir/ssl
[puppetd]
classfile = $vardir/classes.txt
localconfig = $vardir/localconfig
server = puppetmaster.testing.com
Client Preparation
Clients by default will connect to a server on your network with a hostname of “puppet.” If your server’s hostname isn’t “puppet” a directive needs to be inserted into the puppetd configuration file “puppetd.conf.” Even though we don’t need to in this case, we’ll do so for demonstration purposes.
classfile = $vardir/classes.txt
localconfig = $vardir/localconfig
server = puppetmaster.testing.com
Client Preparation
Clients by default will connect to a server on your network with a hostname of “puppet.” If your server’s hostname isn’t “puppet” a directive needs to be inserted into the puppetd configuration file “puppetd.conf.” Even though we don’t need to in this case, we’ll do so for demonstration purposes.
Open “/etc/puppet/puppetd.conf” with your favorite text editor and add “server = puppet.example.com” to the existing file as the example below indicates.
pclient:# vim /etc/puppet/puppetd.conf
[puppetd]
server = puppet.example.com
server = puppet.example.com
# Make sure all log messages are sent to the right directory
# This directory must be writable by the puppet user
logdir=/var/log/puppet
vardir=/var/lib/puppet
rundir=/var/run
Sign Keys
In order for the two systems to communicate securely we need to create signed SSL certificates. You should be logged into both the server and client machines for this next step.
# This directory must be writable by the puppet user
logdir=/var/log/puppet
vardir=/var/lib/puppet
rundir=/var/run
Sign Keys
In order for the two systems to communicate securely we need to create signed SSL certificates. You should be logged into both the server and client machines for this next step.
On the client side run.
pclient:# puppetd –server puppet.example.com –waitforcert 60 –test
You should see the following message.
err: No certificate; running with reduced functionality.
info: Creating a new certificate request for pclient.example.con
info: Requesting certificate
warning: peer certificate won’t be verified in this SSL session
notice: Did not receive certificate
info: Creating a new certificate request for pclient.example.con
info: Requesting certificate
warning: peer certificate won’t be verified in this SSL session
notice: Did not receive certificate
Next, on the server side, run the following command to verify the client is waiting for the cert to be signed.
puppet:# puppetca –list
pclient.example.con
Then sign the certificate.
puppet:# puppetca –sign pclient.example.com
Signed pclient.example.com
If everything went OK you should see this message on pclient.
info: Requesting certificate
warning: peer certificate won’t be verified in this SSL session
notice: Ignoring –listen on onetime run
info: Caching configuration at /etc/puppet/localconfig.yaml
notice: Starting configuration run
notice: //pclient/test_class/File[/
info: Creating state file /var/lib/puppet/state/state.
notice: Finished configuration run in 0.11 seconds
warning: peer certificate won’t be verified in this SSL session
notice: Ignoring –listen on onetime run
info: Caching configuration at /etc/puppet/localconfig.yaml
notice: Starting configuration run
notice: //pclient/test_class/File[/
info: Creating state file /var/lib/puppet/state/state.
notice: Finished configuration run in 0.11 seconds
Test
Check and make sure the file was created.
Check and make sure the file was created.
pclient:# ls -l /tmp/testfile
-rw-r–r– 1 root root 0 2007-02-18 18:28 /tmp/testfile
For a test lets edit the manifest and direct Puppet to modify the file mode. Change line, “mode => 644,” to “mode => 600,”
puppet:# vim /etc/puppet/manifests/site.pp
# Create “/tmp/testfile” if it doesn’t exist.
class test_class {
file { “/tmp/testfile”:
ensure => present,
mode => 600,
owner => root,
group => root
}
}
class test_class {
file { “/tmp/testfile”:
ensure => present,
mode => 600,
owner => root,
group => root
}
}
# tell puppet on which client to run the class
node pclient {
include test_class
}
On the client run puppetd in verbose mode (-v) and only once (-o).
node pclient {
include test_class
}
On the client run puppetd in verbose mode (-v) and only once (-o).
pclient:# puppetd -v -o
You should see the following message, which states that /tmp/testfile changed from mode 644 to 600.
notice: Ignoring –listen on onetime run
info: Config is up to date
notice: Starting configuration run
notice: //pclient/test_class/File[/
notice: Finished configuration run in 0.26 seconds
info: Config is up to date
notice: Starting configuration run
notice: //pclient/test_class/File[/
notice: Finished configuration run in 0.26 seconds
To verify the work was completed properly.
pclient:# ls -l /tmp/testfile
-rw——- 1 root root 0 2007-02-18 18:28 /tmp/testfile
Conclusion
Congratulations, testing is complete and you have a working Puppet setup. Your next step is to create a functional
manifest, test some more, and then fire up the puppetd daemon on the client side. Puppetd by default will automatically poll the server every 30 minutes.
Congratulations, testing is complete and you have a working Puppet setup. Your next step is to create a functional
manifest, test some more, and then fire up the puppetd daemon on the client side. Puppetd by default will automatically poll the server every 30 minutes.
pclient:# /etc/init.d/puppet start
