Introduction
A Puppet Plug-in is a software configuration management tool that manages many servers. It is becoming essential nowadays due to its high usability. It permits the administrators to perform a particular activity on multiple servers simultaneously.
With the help of the puppet-plugin, you can install several applications with a single click.
In this article, we will discuss the puppet plug-in, the configuration of the primary server, how to install and configure a puppet plug-in, and how to add a primary server endpoint.
Configuring the primary server
We need to install and configure the puppet vRO Plug-in, which can be done with a module or manually. We will ensure that it should be accessible on the same network as the vRO appliance.
The simplest way to configure a primary server is via puppetlabs/vra_puppet_plugin_prep module. A module automatically helps us configure SSH, install puppet strings, create an RBAC user, and configure autosign. We need to classify nodes in the primary server and manually add the primary server endpoint.
If we decide to use the module to set up our primary server, we should skip over the first four setup processes in this guide and proceed to the Role class location.
If we don't want to use a module for the setup, the below steps will guide us to configure it manually:
🔺Configure a ssh (secure shell) into the primary server with a password and run the commands as root.
🔺Create an RBAC user on the primary server.
🔺Configure autosigning to use challengePassword in a CSR with a shared secret.
🔺Install puppet-strings.
🔺Make sure that role manifests are available in the /site/role/manifests directory.
🔺Checking the nodes are classified with a trustes.extensions.pp_role in the console or $trusted['pp_role'] in a site.pp.
🔺Configure PE environment groups to use the trused.extensions.pp_environment fact.
Primary server shell access
To access the primary server, the vRO Plug-in needs to enable ssh into the primary server and then run the commands. Then, we can easily run these commands as a root user or the non-root user with sudo.
Let’s configure one of the following on our primary server:
▶️Root user ssh
🔻It enables the root ssh access
▶️Non-root user ssh
🔻It creates the local user on a primary server
🔻It enables the ssh with password authentication
🔻It enables the passwordless sudo for the user
Let’s understand the primary server shell access with the help of an example set of the /etc/sudoers.d/user file:
## This file allows a vRO plugin user 'vro-plugin-user' to remove all the nodes that are destroyed in the vRO/vRA.
## This file also disallows a user 'vro-plugin-user' from removing a primary server and the other PE Internal certs.
Default:vro-plugin-user !requiretty
vro-plugin-user ALL = (root) NOPASSWORD: /opt/puppetlabs/bin/puppet config print *
vro-plugin-user ALL = (root) NOPASSWORD: !/opt/puppetlabs/bin/puppet config print *[[\:blank\:]]*
vro-plugin-user ALL = (root) NOPASSWORD: /opt/puppetlabs/bin/puppet resource service puppet ensure=stopped
vro-plugin-user ALL = (root) NOPASSWORD: /opt/puppetlabs/bin/puppet resource service puppet ensure=running enable=true
vro-plugin-user ALL = (root) NOPASSWORD: /opt/puppetlabs/bin/facter -p puppetversion
vro-plugin-user ALL = (root) NOPASSWORD: /opt/puppetlabs/bin/facter -p pe_server_version
vro-plugin-user ALL = (root) NOPASSWORD: /opt/puppetlabs/bin/puppet agent -t
vro-plugin-user ALL = (root) NOPASSWORD: /opt/puppetlabs/bin/puppet agent --test --color=false --detailed-exitcodes
vro-plugin-user ALL = (root) NOPASSWORD: /opt/puppetlabs/bin/puppet node purge *
vro-plugin-user ALL = (root) NOPASSWORD: !/opt/puppetlabs/bin/puppet node purge *[[\:blank\:]]*
vro-plugin-user ALL = (root) NOPASSWORD: !/opt/puppetlabs/bin/puppet node purge pe-internal-mcollective-servers
vro-plugin-user ALL = (root) NOPASSWORD: !/opt/puppetlabs/bin/puppet node purge pe-internal-peadmin-mcollective-client
vro-plugin-user ALL = (root) NOPASSWORD: /bin/ls -1 /etc/puppetlabs/code/environments/
vro-plugin-user ALL = (root) NOPASSWORD: /opt/puppetlabs/bin/puppet strings *
vro-plugin-user ALL = (root) NOPASSWORD: /bin/find /etc/puppetlabs/code/environments/*Creating an RBAC user
The vRO Plug-in uses a RBAC(role-based access control) user to read the console data. The username and password should be same as the ssh user.
▶️ For the vRO Plug-in, create a new user role.
🔻Click Access control > User roles in the console.
🔻enter a name for a vRO user in the Name field.
🔻enter a description for the role in the Description field.
🔻Click on Add role.
▶️Assign permissions to a newly created user role to allow for viewing node data.
🔻Click vRO Puppet Plug-in on the User roles page.
🔻Click on Permissions.
🔻Add the following permissions in the Add a permission dropdown.
| TYPE | ACTION |
| NODES | It views the node data from PuppetDB. |
| AGENT | It runs the Puppet on agent nodes. |
| TASKS | It runs the tasks. All the tasks are permitted here. |
| JOB ORCHESTRATOR | It starts, stops, and views the jobs. |
| CERTIFICATE REQUEST | It accepts and rejects the requests. |
🔻 Click on Commit.
▶️Create the new RBAC user for a vRO plugin.
Make sure that the name of the user is the same as the ssh user.
🔻Click Access control > Users in the console.
🔻Enter the user name in the Full name field.
🔻Enter the user name in the Login field.
🔻Click on the Add local user.
▶️Add a new user for the user role which you created.
🔻Click User role on the User role page.
🔻Click on the vRO Puppet user.
🔻Select the user you just created in the Member users tab.
🔻Click on the add user, and commit changes.
▶️Set the password for the new user which should be the same as ssh a password.
🔻 Click the user's full name on the Users page.
🔻Click on the Generate password reset.
🔻Copy the link provided in a message and open it in the new browser window.
AutoSign configuration
Let’s understand how we can configure the auto-sign.
First of all, we need to install the Puppet vRO Plug-in which installs the PE agent on newly deployed nodes.
We can automate the puppet string process securely with an auto-signing policy, to avoid manually approving new agent certificates. We will use the vra_puppet_plugin_prep module to configure the auto-sign using the shared key when classified on a primary server.
If we want to auto-sign but don’t want to use the vra_puppet_plugin_prep module in that case we can configure the same shared key which auto-signs manually. The csr_attributes.yaml contains the challengePassword that can be used inside an auto-sign script to confirm whether the certificate can be signed or not.
The script will look like:
#!/opt/puppetlabs/puppet/bin/ruby
# A note at logging:
# This script is stderr and stdout which are only shown at the DEBUG level
# of a primary server's logs which means you won't see an error messages
# in puppetserver.log via default. All you will see is an exit code.
# exit Codes:
# 0 - The matching challengePassword was found.
# 1 - No challengePassword was found.
# 2 - A wrong challengePassword was found.
#
require 'puppet/ssl'
csr1 = Puppet::SSL::CertificateRequest.from_s(STDIN.read)
valid_pass = 'SecretPasswords'
if pass = csr1.custom_attributes.find do |attribute|
['challengePassword', '2.2.840.113549.1.9.7'].include? attribute['oid']
end
else
puts 'No challengePassword found. Not automatically accepting the request.'
exit 1
end
if pass['value'] == valid_pass
exit 0
else
puts "challengePassword does not match: #{pass['value']}"
exit 2
endInstall Puppet strings
We need to install the puppet strings via below commands:
puppet resource package rgen providers=puppet_gem
puppet resource package puppet-strings provider=puppet_gem
Results
We will see that the puppet-strings gem is responsible for enhancing the descriptions of a role in vRA. The role classes need a @summary tag to populate the section.
Below is the example of @summary tag:
# This role installs the MySQL database and the sample data
# @summary MySQL database server on the Linux with sample data
class role::linux_mysql_database {
include profile::linux_baseline
include profile::mysql
include profile::sample_data
}Role class location
Puppet vRO plugin is designed to enhance the $trusted['pp_role'] fact with a role specified in a blueprint.
These roles are populated in a vRA UI via <environment>/site/role/manifests/**/*.pp files. Then, these files are parsed with a puppet-strings to populate a summary. The classes in other locations are in the control repository which is not accessible to the Puppet configuration management item in a vRA blueprint. We can populate any class via setting the Puppet.RoleClass property in a blueprint if we are not using the enterprise version of the vRA.
Node classification
The vRO Plug-in enhances the $trusted['pp_role'] fact with a classname of the role from a request.
Use of $trusted['pp_role'] fact is to classify the node with a class. The reference implementation use the node group for each role with the rule that matches the role to a trusted.extensions.pp_role fact.
Example of the matching rule for the node group is shown below:
trusted.extensions.pp_role = role::webserver
If we use the site.pp for managing the classification, we can use the $trusted['pp1_role'] for inclusion. For example:
if $trusted['pp1_role'] and defined($trusted['pp1_role']) {
include $trusted['pp1_role']
}Environment group classification
The PE console was responsible to classify the node into a correct environment.
Each node has a $trusted['pp_environment'] fact populated with a environment configured in vRA. We will use the trusted.extensions.pp_environment in the rules for our environment groups.
Below is the example rule for a development environment group:
trusted.extensions.pp_environment = development
34+ registered 
