LPIC-3 323.1 Host Configuration Management Part 1

• Weight: 2
• Description: Candidates should be familiar with the use of RCS and Puppet for host configuration management.

Key Knowledge Areas

• RCS
• Puppet

Terms and Utilities

• RCS
• ci/co
• rcsdiff
• puppet
• puppetd
• puppetmasterd
• /etc/puppet/

Configuring Puppet Master

Centralized server management can be achieved on your Linux Server with products such as the long established Puppet project. The puppet server is rather aptly names the Puppet Master and this acts as a central configuration server that can be used to keep configuration files maintained across your server estate and ensure services are installed and running. Along with Puppet we look at RCS, version control software that allows you to check-out and check-in documents to both provide version control and effective access control where perhaps many administrators may update scripts.

Puppet is an open source framework based on Ruby for managing the configuration of computer system. Puppet is licensed under GPLv2 and can be used as a standalone or client-server model. We will use both models in the tutorials the first video being with the Puppet Master (Server) and applying local policies then extending to bring in more clients tutorial. To see information relating to the puppet master package:

The default configuration of the clients or puppet agents will look for the puppet server or puppet master as the host puppet or puppet.yourdomain.com. it is therefore easiest to ensure that the host that will act as the puppet master be configured with DNS or hosts entries as puppet. In the example the puppet master will be configured on the host 192.168.0.200 so the clients will have host file entries:

192.168.0.200     puppet

The lab does not use DNS.

The central puppet server is known as the puppetmaster and should be the host with the entry puppet in the hosts file or DNS. To install the puppetmaster package on Ubuntu

apt-get update
apt-get install puppetmaster

To install on SUSE and we use openSUSE in the video

zypper in puppet-server

With this in place we are ready to configure the server and in the first video we will use this as a standalone deployment bringing in clients in the second video. First we will check the resolution of the puppet master. The file /etc/sysconfig/puppet will define the hostname that the client expects the puppet master to be; it default to puppet. I have hostname records point to this machine as puppet. In your own environment you may use local host entries or a CNAME entry in DNS

On some distributions this is not required but on other such as SUSE the directory permissions need to be implemented correctly for the puppet master to work correctly. The directory /var/lib/puppet is owned by root and should be owned by the account that puppet users: puppet. The following command will correct the issue and don’t forget to double check on the user and group name from on your system from the /etc/passwd and /etc/group file. The following command is correct on the openSUSE system.

chown puppet:puppet /var/lib/puppet

We can now start the puppetmasterd, on SUSE we can use the sym-link:

rcpuppetmasterd start

On other systems

service puppetmasterd start

 

This will populate the directory /var/lib/puppet and will also create the /etc/puppet/manifests sub directory if it does not exists.

Some distributions will have the /etc/puppet/fileserver.conf already created and it will need to be modified. In SUSE you will need to create and populate the file. This is the default file that defines the puppet master’s fileserver configuration; you can specify a different file using the puppetmasterd –fsconfig flag.

As the name suggests it allows the puppet server to share files to clients. This was configuration files can be kept up-to-date on client machines. In the example we will distribute the /etc/motd file.

From the following /etc/puppet/fileserver.conf we have defines a share simply called files and have the path pointing though to /etc/puppet/files; if you are thinking of sharing more files then perhaps /var/puppet/files may be more appropriate than the /etc directory.

[files]
 path /etc/puppet/files
 allow *

 

The path directive may also take variables such as:

• %h : To represent the client’s host name
• %H : To represent the client’s FQDN
• %d : to represent the client’s domain name

Which can subsequently allow for more granularity when distributing files.

For security we can add allow and deny directives and specify hostnames or IP addresses as required. Here we allow all devices.

To deploy a file from this share we must add the file to the share and restart the puppetmasterd. We are distributing a standard motd file so we will create the directory:

mkdir /etc/puppet/files

We then create the file to distribute with:

echo “Only authorized access is a allowed” > /etc/puppet/files/motd

Now we can restart the service with the following command on SUSE. We will then be ready to create the first puppet manifest.

rcpuppetmasterd restart

Normally we would need to create the file /etc/puppet/manifests/site.pp. This file is the manifest or policy that all clients will look for when connecting to the Puppet Master. As we are first applying only local manifest we can create files with the names of our choice. We will create three files to demonstrate deployment of files, control of services, and finally a manifest to ensure a package is installed. These all could be in a single manifest but for the video demonstration in the video it will be shown as three files.

For ease of page space we will create a single file /etc/puppet/manifests/test.pp. PP is the normal suffix for manifests and these are just etxt files so using your text editor of choice is just fine.

package {'nmap': ensure => installed }
service { 'sshd': ensure => running, enable => true, }
file { “/etc/motd” : source => “puppet:///files/motd”, }

In the file we create three instructions:

• package
• service
• file

Each instruction has a name and attributes to look for. With the package we are just looking to installed nmap if it is not installed. We do not mind how it is installed but it just needs to exist in a repository. This could easily be Solaris, SUSE, Red Hat or Debian as we do not concern ourselves with the “how it is installed”.


The same for the service we just want to make sure that it is running and is enabled for auto start. How it is started does not matter, using the service command or rc symlinks and nor are we concerned of the chkconfig command ad the switches used. This is OS specific and not a concern for our instruction. In this way we keep as open as possible onto which platforms this will work.

The file command then is ensuring the centralized motd file is used from the puppet server. We have only set the source attribute but we could also add in the owner, group, and mode if we needed.

To test the manifest we can use the apply option to the client. This is used only in standalone configurations and is useful for testing. As we have not added in any client yet this is a great way to prove the manifest is working

puppet apply /etc/puppet/manifests/test.pp

This command will check the named manifest and the associated tasks; we then should see the file being updated, the service sshd will run and nmap will be installed. Certainly this shows how powerful Puppet can be and will give you some ideas of centralized management and machine configuration for your environment. In the next video we will add in more clients to test the full potential of puppet.