Puppet master post install tasks
In this chapter, we'll do post install tasks, and this is the continuation from puppet install on ubuntu 14.04 trusty.
After installing Puppet on a node that will act as a puppet master server, we need to:
- Get the master's names and certificates set up
- Configure any necessary settings
- Put Puppet modules and manifests in place
- Configure a production-ready web server
- Configure load balancing and CA service routing if using multiple masters
- Start the puppet master service
Decide on a main name for Puppet services at our site, and make sure our DNS resolves it to the puppet master (or its load balancer). Unconfigured agents will try to find a master at puppet, so if we use this name it can reduce setup time.
Edit the master's puppet.conf file:
$ sudo vi /etc/puppet/puppet.conf [main] logdir=/var/log/puppet vardir=/var/lib/puppet ssldir=/var/lib/puppet/ssl rundir=/var/run/puppet factpath=$vardir/lib/facter templatedir=$confdir/templates [master] # These are needed when the puppetmaster is run by passenger # and can safely be removed if webrick is used. ssl_client_header = SSL_CLIENT_S_DN ssl_client_verify_header = SSL_CLIENT_VERIFY
Delete the line with the 'templatedir' option, as that option is deprecated.
In the [main] section of the master's puppet.conf file, set the dns_alt_names setting to a comma-separated list of each hostname the master should be allowed to use. In the case of our example, we will use "puppet" and "puppet.localdomain", the short hostname and FQDN, respectively.Add the following two lines to the end of the [main] section:
certname = puppet dns_alt_names = puppet,puppet.localdomain
Then, it should look like this:
[main] logdir=/var/log/puppet vardir=/var/lib/puppet ssldir=/var/lib/puppet/ssl rundir=/var/run/puppet factpath=$vardir/lib/facter certname = puppet dns_alt_names = puppet, puppet.localdomain [master] # These are needed when the puppetmaster is run by passenger # and can safely be removed if webrick is used. ssl_client_header = SSL_CLIENT_S_DN ssl_client_verify_header = SSL_CLIENT_VERIFY
It is important to use assign certname to "puppet" because the Apache/Passenger configuration expects the certificate to be named "puppet". If we want a different certname setting, we should be sure to edit the Apache config file (/etc/apache2/sites-available/puppetmaster.conf) to change the name of the SSL certificate path.
Save and exit.
Let's set hostname (/etc/host):
127.0.0.1 puppet puppet.localdomain
In the file /etc/hostname
Puppet uses SSL certificates to authenticate communication between master and agent nodes. The Puppet master acts as a certificate authority (CA), and must generate its own certificates which is used to sign agent certificate requests. We will setup the master's certificates now.
Let's delete any existing SSL certificates that were created during the package install. The default location of Puppet's SSL certificates is /var/lib/puppet/ssl:
$ sudo rm -rf /var/lib/puppet/ssl
If this is the only puppet master in our deployment, or if it will be acting as the CA server for a multi-master site, let's create new CA certificates by running the following command:
$ sudo puppet master --verbose --no-daemonize Info: Creating a new SSL key for ca Info: Creating a new SSL certificate request for ca Info: Certificate Request fingerprint (SHA256): 5C:3C:2F:B3:BF:25:99:7E:DC:31:89:9A:1B:A8:A6:45:08:8C:0A:CC:86:9F:8C:01:53:25:6A:92:F4:36:A6:6C Notice: Signed certificate request for ca Info: Creating a new certificate revocation list Info: Creating a new SSL key for puppet Info: csr_attributes file loading from /etc/puppet/csr_attributes.yaml Info: Creating a new SSL certificate request for puppet Info: Certificate Request fingerprint (SHA256): 4A:6F:D7:89:26:2B:20:D9:AA:94:52:EA:B5:6D:7F:30:9E:3A:2C:5A:B4:85:77:E1:6F:60:81:B1:5D:C7:DD:19 Notice: puppet has a waiting certificate request Notice: Signed certificate request for puppet Notice: Removing file Puppet::SSL::CertificateRequest puppet at '/var/lib/puppet/ssl/ca/requests/puppet.pem' Notice: Removing file Puppet::SSL::CertificateRequest puppet at '/var/lib/puppet/ssl/certificate_requests/puppet.pem' Notice: Starting Puppet master version 3.7.3
We will see several lines of output saying that SSL keys and certificates are being created. Once we see Notice: Starting Puppet master version 3.7.3, the certificate setup is complete. Press CTRL-C to kill the process and return to the shell.
^CNotice: Caught INT; calling stop
We may get the following error when we try to create CA:
$ sudo puppet master --verbose --no-daemonize Notice: Starting Puppet master version 3.7.3 Error: Could not run: Address already in use - bind(2)
This message tells us the master is already running mostly because our master puppet runs when Apache is running. We can check this:
$ sudo netstat -ltnp Active Internet connections (only servers) Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 941/sshd tcp6 0 0 :::8140 :::* LISTEN 1170/apache2 tcp6 0 0 :::80 :::* LISTEN 1170/apache2 tcp6 0 0 :::22 :::* LISTEN 941/sshd tcp6 0 0 :::443 :::* LISTEN 1170/apache2
As we can see the port 8140 is already in use for listening. So, in this case, we need to stop 'apache2' service, and then run our puppet master after that:
$ sudo service apache2 stop
If we want to look at the cert info of the certificate that was just created, type in the following:
$ sudo puppet cert list -all
The previous command actually lists all of the signed certificates and unsigned certificate requests. Currently, only the master cert will display, because no other certificates have been added yet:
$ sudo puppet cert list -all + "puppet" (SHA256) 02:A9:6E:94:DD:98:C3:01:A6:BE:38:1A:BE:FD:FD:81:6A:0F:90:5F:71:F6:BE:EC:BE:13:66:84:96:95:3A:FF (alt names: "DNS:puppet", "DNS:puppet.localdomain")
We can see the CA certificate and the puppet master certificate have been created with the appropriate DNS names included.
The main puppet configuration file, /etc/puppet/puppet.conf, consists of three sections: [main], [master], and [agent]. The "main" section contains global configuration, the "master" section is specific to the puppet master, and the "agent" is used to configure the puppet agent. Aside from the changes we made earlier, the defaults will work fine for a basic setup.
It configures all of the Puppet commands and services, including puppet agent, puppet master, puppet apply, and puppet cert. It resembles a standard INI file, with a few syntax extensions. Settings may go into application-specific sections, or into a [main] section that affects all applications.
Here is a summary. Puppet uses four primary config sections:
- main is the global section used by all commands and services. It can be overridden by the other sections.
- master is used by the puppet master service and the puppet cert command.
- agent is used by the puppet agent service.
- user is used by the puppet apply command, as well as many of the less common Puppet subcommands.
A full description of the file is available at Puppet Labs: Main Config File (puppet.conf).
Puppet uses a domain-specific language (DSL) to describe system configurations, and these descriptions are saved to files called "manifests", which have a .pp file extension. The default main manifest file is located at /etc/puppet/manifests/site.pp.
Puppet always starts compiling with either a single manifest file or a directory of manifests that get treated like a single file. This main starting point is called the main manifest or site manifest.
A full description of the file is available at Puppet Labs: The Main Manifest(s).
We will cover some basic manifests later, but we will create a placeholder file for now:
$ sudo touch /etc/puppet/manifests/site.pp
Now, we are ready to start the Puppet master. Start it by running the 'apache2' service:
$ sudo service apache2 start
Our Puppet master is running, but it isn't managing any agent nodes yet.
Let's learn how to install and add Puppet agents in next chapter: Puppet agent post install tasks - configure agent, hostnames, and sign request.
Ph.D. / Golden Gate Ave, San Francisco / Seoul National Univ / Carnegie Mellon / UC Berkeley / DevOps / Deep Learning / Visualization