Installing
puppet on red hat linux based system
This
blog post will guide you through installing puppet as a master/agent
configuration in a RedHat Linux based systems. This is nothing other
than collecting the important information mentioned in the puppetlabs
web site. What I have done is collecting pieces of information which
is scettered through the puppet web site with adding my own
experiences which I have gathered during setting up on my
environment.
1.
Choose a Package Source
Puppet
Labs provides an official package repo at yum.puppetlabs.com. It
contains up-to-date packages, and can install Puppet and its
prerequisites without requiring any other external repositories.
This
information applies to RHEL itself, as well as any distributions that
maintain binary compatibility with it, including but not limited to
CentOS, Scientific Linux, Oracle Linux, and Ascendos.
Enabling
this repository will let you install Puppet without requiring any
other external repositories like EPEL.
To
enable the repository, run the command below that corresponds to your
OS version and architecture:
Enterprise
Linux 5
i386
x86_64
Enterprise
Linux 6
i386
x86_64
2.
Install the Puppet Master
On
your puppet master node, run
sudo
yum install puppet-server.
This
will install Puppet and an init script (/etc/init.d/puppetmaster) for
running a test-quality puppet master server.
3.
Install Puppet on Agent Nodes
On
your other nodes, run
sudo
yum install puppet.
This
will install Puppet and an init script (/etc/init.d/puppet) for
running the puppet agent daemon.
4.
Configure Puppet
Puppet’s
main configuration file is found at /etc/puppet/puppet.conf.
Most
users should specify the following settings:
On
Agent Nodes
Settings
for agent nodes should go in the [agent] or [main] block of
puppet.conf.
server:
The hostname of your puppet master server. Defaults to puppet.
report:
Most users should set this to true.
pluginsync:
Most users should set this to true.
certname:
The sitewide unique identifier for this node. Defaults to the node’s
fully qualified domain name, which is usually fine.
On
Puppet Masters
Settings
for puppet master servers should go in the [master] or [main] block
of puppet.conf.
Note:
puppet masters are usually also agent nodes; settings in [main] will
be available to both services, and settings in the [master] and
[agent] blocks will override the settings in [main].
dns_alt_names:
A list of valid hostnames for the master, which will be embedded
in its certificate. Defaults to the puppet master’s certname and
puppet, which is usually fine. If you are using a non-default
setting, set it before starting the puppet master for the first time.
5.
Start and Enable the Puppet Services
Some
packages do not automatically start the puppet services after
installing the software. You may need to start them manually in order
to use Puppet.
With
Init Scripts / Service Configs
Most
packages create init scripts or service configuration files called
puppet and puppetmaster, which run the puppet agent and puppet master
services.
You
can start and permanently enable these services using Puppet:
$
sudo puppet resource service puppet ensure=running enable=true
$
sudo puppet resource service puppetmaster ensure=running enable=true
Note:
If you have configured puppet master to use a production web server,
do not use the default init script; instead, start and stop the web
server that is managing the puppet master service.
With
Cron
Standalone
deployments do not use services with init scripts; instead, they
require a cron task to regularly run puppet apply on a main manifest
(usually the same /etc/puppet/manifests/site.pp manifest that puppet
master uses). You can create this cron job with Puppet:
$
sudo puppet resource cron puppet-apply ensure=present user=root
minute=30 command='/usr/bin/puppet apply $(puppet --configprint
manifest)'
In
an agent/master deployment, you may wish to run puppet agent with
cron rather than its init script; this can sometimes perform better
and use less memory. You can create this cron job with Puppet:
$
sudo puppet resource cron puppet-agent ensure=present user=root
minute=30 command='/usr/bin/puppet agent --onetime --no-daemonize
--splay'
6.
Sign Node Certificates
In
an agent/master deployment, an admin must approve a certificate
request for each agent node before that node can fetch
configurations. Agent nodes will request certificates the first time
they attempt to run.
It’s
usually best to start with your first client being Puppetmaster
server itself. However, since the Puppetmaster will be talking to
itself, that client will already have a certificate, so no signing
will be necessary to establish trust between the Puppetmaster server
and itself. In this example, we’ll configure a client that isn’t
the Puppetmaster server so we can demonstrate how to establish
cryptographic trust between the Puppetmaster server and its new
clients:
First,
start puppet agent on the client in verbose mode:
client%
sudo puppet agent --verbose
You
should see a message about not receiving a certificate, and on the
server you should get a message about a request waiting for you. On
the server, we’ll list the certificates waiting for signatures:
master%
sudo puppet cert --list
You
should see our client’s name listed, so we can give the
Puppetmaster the command to sign its certificate (thus creating a
trust relationship that client):
master%
sudo puppet cert --sign <client>
Periodically
log into the puppet master server and run sudo puppet cert list to
view outstanding requests.
Run
sudo
puppet cert sign <NAME> to sign a request, or
sudo
puppet cert sign --all to sign all pending requests.
An
agent node whose request has been signed on the master will run
normally on its next attempt.
Comments
Post a Comment