SSL Sign Certificate Setup Process | DevOps | VisualPath

SSL Sign Certificate Setup

When the Puppet agent software runs for the first time on any Puppet node, it generates a certificate and sends the certificate signing request to the Puppet master. The below command from an agent will request for the certificate from the master.

# puppet agent --verbose --no-daemonize –onetime

Before the Puppet server is able to communicate and control the agent nodes, it must sign that particular agent node’s certificate. In the following sections, we will describe how to sign and check for the signing request.
List Current Certificate Requests.
On the Puppet master, run the following command to see all unsigned certificate requests.

$ sudo puppet cert list

As we have just set up a new agent node, we will see one request for approval. Following will be the output.

 "agent01.example.com"(SHA259)
15:90:C2:FB:ED:69:A4:F7:B1:87:0B:BF:F7:ll:B5:1C:33:F5:76:67:F3:F6:45:AE:07:4B:F
6:E3:ss:04:11:8h

It does not contain any + (sign) in the beginning, which indicates that the certificate isstill not signed.
Sign a Request
In order to sign the new certificate request which was generated when the Puppet agent run took place on the new node, the Puppet cert sign command would be used, with the
hostname of the certificate, which was generated by the newly configured node that needs to be signed.
As we have agent01.example.com’s certificate, we will use the following command.

$ sudo puppet cert sign agent01.example.com

Following will be the output.
Notice: Signed certificate request for agent01.example.com Once the above is done, we have our infrastructure ready in which the Puppet master is now capable of managing newly added nodes.
Creating Environments
In the IT industry, we can find different teams like development team, testing team, DB admin team etc. To manage infrastructure for each team separately we can create environments in puppet.
Enabling Directory Environments in Open Source Puppet
Directory environments are disabled by default. To enable them, you must: Edit the config file
Create at least one directory environment.
Edit puppet.conf
To enable directory environments, set environment path = $confdir/environments in the Puppet master puppet.conf (in the [main] or [master] section).
Optionally, you can also:
Use the base module path setting to specify global modules that should be available in all environments. Most people are fine with the default value.
See the section below about settings for more details.
Once you edit puppet.conf, directory environments will be enabled and config file environments will be disabled.
Create a Directory Environment
You must have a directory environment for every environment that any nodes are assigned to. At a minimum, you should have a production environment. Nodes assigned to non existent environments cannot fetch their catalogs.
To create your first environment, create a directory named production in your environment path. (If a production directory doesn’t exist, the Puppet master will try to create one when it starts up.) Once it is created, you can add modules, amain manifest, and anenvironment.conf file to it.
Restart the Puppet Master
Restart the web server that manages your Puppet master, to make sure the Puppet master picks up its changed configuration. Global Settings for Configuring Environments
Puppet uses five settings inpuppet.conf to configure the behavior of directory environments:
• environment path is the list of directories where Puppet will look for environments.
• base module path lists directories of global modules that all environments can access by default.
• default_manifest specifies the main manifest for any environment that doesn’t set a manifest value inenvironment.conf.
• disable_per_environment_manifest lets you specify that all environments should use a shared main manifest. This requires default_manifest to be set to an absolute path.
• environment_timeout sets how often the Puppet will refresh information about environments. It can be overridden per-environment.
Creating an environment 
We can create a file structure for an environment, running the command
mkdir -p /etc/puppet/environments/production/{modules, manifests}
Sample environment.conf File

[master]
manifest= $confdir/environments/Production/manifests/site.pp
modulepath= $confdir/environments/Production/modules

Where “$confdir” represents “/etc/puppet”.
Site.pp
/etc/puppet/environments/Production/manifests/site.pp
It is the file where we define the nodes and what changes to be made to get the node to the desired state in the production environment.
Syntax

# /etc/puppet/environments/production/manifests/site.pp
node 'www1.example.com'{
include common
include apache
include squid
}
node 'db1.example.com'{
include common
include mysql
}

In the example above, only www1.example.com would receive the apache and squid classes, and only db1.example.com would receive the MySQL class.
Node definitions look like class definitions. The general form of a node definition is:
• The node keyword
• The name(s) of the node(s), separated by commas (with an optional final trailing comma)
• An opening curly brace
• Any mixture of class declarations, variables, resource declarations, collectors, conditional statements,
chaining relationships, and functions
• A closing curly brace
To create a group of multiple nodes for the same node definition
node 'www1.example.com', 'www2.example.com', 'www3.example.com' {
include common
include apache, squid
}
Note: The function “include” can call puppet code from the manifests files. It is explained in detail in the next chapters.

For DevOps training contact us at +91 9704455959 / info@visualpath.in

For more information about Visualpath, visit www.visualpath.in and follow the company on Facebook and Twitter.