Chapter 20. Creating a Puppet Master
This chapter will cover installing and tuning the well-known Puppet master Rack application.
At this point, we’re going to spin up another virtual machine. You should open a new Terminal window, or add a new tab on your existing terminal for this virtual machine. This will allow you to switch back and forth between the machines, which is necessary in this chapter.
Starting the puppetmaster VM
In the new Terminal window, move into the directory where you checked out the learning-puppet4 Git repository. Start up the puppetmaster instance just like we did the client instance at the beginning of the book:
~$cdlearning-puppet4learning-puppet4$vagrantuppuppetmasterBringingmachine'puppetmaster'upwith'virtualbox'provider...==>puppetmaster:Importingbasebox'puppetlabs/centos-7.2-64-nocm'...==>puppetmaster:MatchingMACaddressforNATnetworking...==>puppetmaster:Checkingifbox'puppetlabs/centos-7.2-64-nocm'isuptodate.==>puppetmaster:SettingthenameoftheVM:learning-puppet4_puppetmaster_1437...snip...==>puppetmaster:Machinebootedandready!
Now that it is running, log in and get started:
learning-puppet4$vagrantsshpuppetmaster[vagrant@puppetmaster~]$
Installing the Puppet Master
The Puppet master is included in the Puppet agent all-in-one (AIO) package. Install the puppet-agent package exactly as you did on the client instance. You can refer back to Part I for the installation instructions, or simply run the fastsetup.sh script shown here. This script installs all the dependencies and symlinks discussed earlier:
[vagrant@client~]$/vagrant/bin/fastsetup.shInstallingutilitiesnecessaryforthelessonswarning:/var/cache/yum/x86_64/7/base/packages/gpm-libs-1.20.7-5.el7.x86_64.rpm:HeaderV3RSA/SHA256Signature,keyIDf4a80eb5:NOKEYPublickeyforgpm-libs-1.20.7-5.el7.x86_64.rpmisnotinstalledImportingGPGkey0xF4A80EB5:Userid:"CentOS-7 Key (CentOS 7 Official Signing Key) <[email protected]>"Fingerprint:6341ab2753d78a78a7c27bb124c6a8a7f4a80eb5Package:centos-release-7-0.1406.el7.centos.2.3.x86_64(@anaconda)From:/etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7InstallingPuppetPublickeyforpuppet-agent-1.10.9-1.el7.x86_64.rpmisnotinstalledImportingGPGkey0x4BD6EC30:Userid:"Puppet Labs Release Key (Puppet Labs Release Key)"Fingerprint:47b320eb4c7c375aa9dae1a01054b7a24bd6ec30Package:puppetlabs-release-pc1-1.0.0-1.el7.noarchFrom:/etc/pki/rpm-gpg/RPM-GPG-KEY-puppetlabswarning:/etc/puppetlabs/puppet/puppet.confcreatedas/etc/puppetlabs/puppet/puppet.conf.rpmnewEnablingconveniencesymlinks.Changingownerof/etc/puppetlabs
This has installed Puppet and the tools you installed in Part I. It has also changed the owner of /etc/puppetlabs to the vagrant user for your convenience:
[vagrant@puppetmaster~]$whichpuppet/opt/puppetlabs/bin/puppet[vagrant@puppetmaster~]$whichgitrsyncvimnanoemacs/usr/bin/git/usr/bin/rsync/usr/bin/vim/usr/bin/nano/usr/bin/emacs[vagrant@puppetmaster~]$ls-la/etc/puppetlabstotal12drwxr-xr-x5vagrantvagrant48Aug221:50.drwxr-xr-x.77rootroot8192Aug221:53..drwxr-xr-x5vagrantvagrant96Aug221:50codedrwxr-xr-x2vagrantvagrant145Aug221:50mcollectivedrwxr-xr-x3vagrantvagrant111Aug221:50puppet
If you prefer an editor other than the three listed here, you’ll need to install it as discussed in “Choosing a Text Editor”.
Configuring a Firewall for the Puppet Master
At this point, we’ll need to adjust the firewall on the server. Puppet clients connect to servers on TCP port 8140 by default. Use the following commands to allow incoming TCP connections to this port:
[puppetmaster~]$sudofirewall-cmd--permanent--zone=public--add-port=8140/tcpsuccess[puppetmaster~]$sudofirewall-cmd--reloadsuccess
This change allows incoming connections to the Puppet master.
Tip
It is safe to run these commands in a virtual instance on your personal workstation. In a production setting, you’d want to limit access to specific IP networks. Don’t make this change to a production system without reviewing your organization’s existing security setup.Guides for altering other firewalls can be found in Appendix B.
Running the WEBrick Server
In this section, we’ll start up the Puppet master manually so that it can set up the directories and files it needs to run as a service. It is necessary to do this once, even if you plan to run it under Passenger or another Rack server.
At this point, we need to stop and create a user and group under which to run the Puppet master service. This service doesn’t need any special permissions on the system that hosts it, as it is a typical application service that answers queries from nodes. It can and should run as a nonprivileged user.
Note
This is different from the Puppet agent, which must run as a privileged account to make changes to the managed node.It may surprise you that the installation package doesn’t create the user and group for you. This is because the Puppet master has been deprecated. The Puppet Server package does create the puppet user and group during installation, but to run a Puppet master, we’ll have to do it ourselves:
[vagrant@puppetmaster~]$sudogroupaddpuppet[vagrant@puppetmaster~]$sudouseradd-m-d/var/opt/puppetlabs-gpuppetpuppet
Now that everything has been prepared, let’s start the service as a foreground process so that we can observe the initialization process. You will notice that it creates a certificate authority based on the configured certname, and then signs its own certificate:
[vagrant@puppetmaster~]$sudo/opt/puppetlabs/bin/puppetmaster-v--no-daemonNotice:SignedcertificaterequestforcaNotice:puppet.example.comhasawaitingcertificaterequestNotice:Signedcertificaterequestforpuppet.example.comNotice:RemovingfilePuppet::SSL::CertificateRequestpuppet.example.comat'/var/opt/puppetlabs/puppetserver/ssl/ca/requests/puppet.example.com.pem'Notice:RemovingfilePuppet::SSL::CertificateRequestpuppet.example.comat'/var/opt/puppetlabs/puppetserver/ssl/certificate_requests/puppet.example.com'Warning:TheWEBrickPuppetmasterserverisdeprecatedandwillberemovedinafuturerelease.PleaseusePuppetServerinstead.Seehttp://links.puppetlabs.com/deprecate-rack-webrick-serversformore...Notice:StartingPuppetmasterversion4.4.0
By signing its own certificate, the Puppet master has become the root certificate authority for this Puppet installation. Only agents with certificates signed by this certificate authority will be able to access the service. We’ll discuss ways to handle distributed or third-party certificate authorities in “Using an External Certificate Authority”.
I recommend at this point that you skip forward and complete all the steps in Chapter 22. Leave the Puppet master running on this screen. Use other windows to execute the commands in that chapter. As you finish each step, check back here and view the messages output by the Puppet master.
After you are comfortable with the Puppet master service, you can press Ctrl-C to stop this process. Then you can configure it to run as a limited test service, or configure it to support many nodes with Passenger.
Testing with the Puppet Master Service
Use the following process to enable a Puppet master service for your host. This service will only support a single connection at a time, but may be sufficient for testing Puppet 4 manifests.
As Puppet 4 has deprecated the Puppet master in favor of Puppet Server, the installation package does not include a service startup script. You can find one in the /vagrant mount of the files from the Git repository used by this book:
[vagrant@puppetmaster~]$sudocp/vagrant/systemd-puppet/puppetmaster.service/usr/lib/systemd/system/puppetmaster.service[vagrant@puppetmaster~]$sudocp/vagrant/systemd-puppet/puppetmaster.sysconfig/etc/sysconfig/puppetmaster[vagrant@puppetmaster~]$sudosystemctldaemon-reload[vagrant@puppetmaster~]$systemctlstatuspuppetmasterpuppetmaster.service-PuppetmasterLoaded:loaded(/usr/lib/systemd/system/puppetmaster.service;disabled)Active:inactive(dead)[vagrant@puppetmaster~]$sudosystemctlenablepuppetmasterln-s'/usr/lib/systemd/system/puppetmaster.service''/etc/systemd/system/multi-user.target.wants/puppetmaster.service'
After you have run the service manually as shown in the previous section, you can use the files we just installed to start it as a normal service. Use the standard systemctl commands to start and stop the service:
[vagrant@puppetmaster~]$sudosystemctlstartpuppetmaster[vagrant@puppetmaster~]$sudosystemctlstatuspuppetmasterpuppetmaster.service-PuppetmasterLoaded:loaded(/usr/lib/systemd/system/puppetmaster.service;enabled)Active:active(running)sinceThu2015-08-2705:02:37UTC;10sagoMainPID:4100(puppet)CGroup:/system.slice/puppetmaster.service└─4100/opt/puppetlabs/puppet/bin/ruby/opt/puppetlabs/puppet/bin/puppetmaster--no-daemonizesystemd[1]:StartingPuppetmaster...systemd[1]:StartedPuppetmaster.puppet[4100]:Warning:TheWEBrickPuppetmasterserverisdeprecatedandwillberemovedinafuturerelease.PleaseusePuppetServerinstead.Seehttp://links.puppetlabs.com/deprecat...moreinformation.puppet[4100]:Notice:StartingPuppetmasterversion4.4.0Hint:Somelineswereellipsized,use-ltoshowinfull.
Warning
As discussed previously, thepuppetmaster service uses the Ruby WEBrick test server. This is only suitable for a few nodes. You should never use this for a production environment.Scaling the Puppet Master with Passenger
This section covers the installation of Puppet to run as a service under Passenger Rack.
Tip
Before installing Passenger, you should first start up the Puppet master manually as documented on the previous page. This will create all of the required directories with the appropriate permissions for running Puppet under Passenger.If you have enabled the puppetmaster service, you’ll need to disable it, as it will conflict with the master service running under Passenger:
[vagrant@puppetmaster~]$sudosystemctlstoppuppetmaster[vagrant@puppetmaster~]$sudosystemctldisablepuppetmasterrm'/etc/systemd/system/multi-user.target.wants/puppetmaster.service'
Installing Apache
To run Puppet under Passenger, we’ll use the Apache httpd to provide the base web service. Install Apache httpd, the Apache development tools, and the TLS module:
[vagrant@puppetmaster~]$sudoyuminstall-yhttpdhttpd-develmod_sslLoadedplugins:fastestmirror...snip...Installed:httpd.x86_640:2.4.6-31.el7.centoshttpd-devel.x86_640:2.4.6-31.el7.centosmod_ssl.x86_641:2.4.6-31.el7.centosDependencyInstalled:apr.x86_640:1.4.8-3.el7apr-devel.x86_640:1.4.8-3.el7apr-util.x86_640:1.5.2-6.el7apr-util-devel.x86_640:1.5.2-6.el7cyrus-sasl.x86_640:2.1.26-17.el7cyrus-sasl-devel.x86_640:2.1.26-17.el7expat-devel.x86_640:2.1.0-8.el7httpd-tools.x86_640:2.4.6-31.el7.centosmailcap.noarch0:2.1.41-2.el7openldap-devel.x86_640:2.4.39-6.el7libdb-devel.x86_640:5.3.21-17.el7_0.1Complete!
Installing Phusion Passenger
We’ll need to get some dependencies from the EPEL repository, so let’s install that first:
[vagrant@puppetmaster~]$sudoyuminstall-yepel-releaseLoadedplugins:fastestmirror...snip...Installed:epel-release.noarch0:7-5Complete!
Phusion provides a Yum repository with Passenger binaries. They don’t provide a release RPM, just the repo configuration file. Download and install it with the following commands:
[vagrant@puppetmaster~]$curl-sSLopassenger.repohttps://oss-binaries.phusionpassenger.com/yum/definitions/el-passenger.repo$sudomvpassenger.repo/etc/yum.repos.d/passenger.repo
Now install Passenger. Yum will acquire necessary dependencies from the EPEL repository:
$sudoyuminstall-ypassengermod_passengerLoadedplugins:fastestmirror...snip...Installed:passenger.x86_640:5.0.16-8.el7mod_passenger.x86_640:5.0.16-8.el7DependencyInstalled:rubygem-rack.noarch1:1.5.2-4.el7Complete!
Configuring the Puppet Master
Now we’ll configure the system to start Apache with the Puppet master running as a Rack service under Phusion Passenger.
First, let’s start up Apache and confirm that the Phusion Passenger configuration is correct:
$sudosystemctlenablehttpdln-s'/usr/lib/systemd/system/httpd.service''/etc/systemd/system/multi-user.target.wants/httpd.service'$sudosystemctlstarthttpd$sudopassenger-configvalidate-install--validate-apache2--auto*CheckingwhetherthisPassengerinstallisinPATH...✓*CheckingwhethertherearenootherPassengerinstallations...✓*CheckingwhetherApacheisinstalled...✓*CheckingwhetherthePassengermoduleiscorrectlyconfiguredinApache...✓Everythinglooksgood.:-)
Apache comes with several configuration files useful for providing a friendly environment for setting up websites. We don’t need and won’t be using this configuration, so let’s disable them. You can use either of the following commands:
[vagrant@puppetmaster~]$sudorm/etc/httpd/conf.d/*.conf
Or perhaps less drastically, this will achieve the same effect:
[vagrant@puppetmaster~]$cd/etc/httpd/conf.d[vagrant@puppetmasterconf.d]$forcfgin*.conf;dosudomv$cfg$cfg.dis;done
Instead, we’ll install our own virtual configuration file that will include the specific Apache directives we require. This file contains a complete, self-standing service definition for the Puppet master service:
[vagrant@puppetmaster~]$cd/etc/httpd/conf.d/[vagrant@puppetmasterconf.d]$sudocp/vagrant/etc-puppet/puppetmaster.conf./
The next step is to configure the Puppet master application Rack service. Now we’ll install a config.ru file with the Rack application configuration:
[vagrant@puppetmaster~]$mkdir-p/etc/puppetlabs/puppetmaster/public[vagrant@puppetmaster~]$cd/etc/puppetlabs/puppetmaster[vagrant@puppetmasterpuppetmaster]$sudocp/vagrant/etc-puppet/config.ru./
It is essential that the puppet user own all of the following files and directories. In particular, the Puppet master service will be started as the user who owns the config.ru file:
$sudochownpuppet:puppet/etc/puppetlabs/puppetmaster/config.ru$sudomkdir/var/run/puppetlabs/puppetmaster$sudochownpuppet:puppet/var/run/puppetlabs/puppetmaster$sudomkdir/var/log/puppetlabs/puppetmaster$sudochownpuppet:puppet/var/log/puppetlabs/puppetmaster
Finally, restart Apache to pick up the changes. Check the status to ensure it is running successfully. Here’s what it looks like when it is restarted successfully:
$sudosystemctlrestarthttpd$sudosystemctlstatushttpdhttpd.service-TheApacheHTTPServerLoaded:loaded(/usr/lib/systemd/system/httpd.service;enabled)Active:active(running)sinceThu2015-08-2705:24:38UTC;5sagoProcess:14661ExecStop=/bin/kill-WINCH${MAINPID}(code=exited,status=0)MainPID:14666(httpd)Status:"Processing requests..."CGroup:/system.slice/httpd.service├─14666/usr/sbin/httpd-DFOREGROUND├─14693Passengerwatchdog├─14696Passengercore├─14703Passengerust-router├─14714/usr/sbin/httpd-DFOREGROUND├─14715/usr/sbin/httpd-DFOREGROUND├─14716/usr/sbin/httpd-DFOREGROUND├─14717/usr/sbin/httpd-DFOREGROUND└─14718/usr/sbin/httpd-DFOREGROUNDAug2705:24:38puppetmastersystemd[1]:StartingTheApacheHTTPServer...Aug2705:24:38puppetmastersystemd[1]:StartedTheApacheHTTPServer.
There are two logs that may contain errors from the Puppet master. Check the Apache error log for Passenger startup failures, and your syslog daemon log for messages from the Puppet master. The following command can be useful to view both of these logs when investigating problems:
[vagrant@puppetmaster~]$sudotail-f/var/log/messages/var/log/httpd/error_log
IPv6 Dual-Stack Puppet Master
To enable IPv6 connections to a WEBrick Puppet master, add the bindaddress configuration setting to the [master] section of the Puppet configuration file, then restart the puppetmaster service:
[master]bindaddress=::
This is completely unnecessary when the Puppet master runs under Apache/Passenger, and should be removed.
If you query for listening services using netstat -an, you’ll see the Puppet master listening on a tcp6 socket. This socket accepts both IPv4 and IPv6 connections:
[vagrant@puppetmaster~]$netstat-an|grep8140tcp600:::8140:::*LISTEN
Clients will connect to the IPv6 or IPv4 port based on the configuration of the client node, and the addresses available from DNS or the hosts file. To force a node to connect using a specific protocol, only provide the address of the Puppet master in that format.