Prerequisites

  • Time synchronisation is configured on VRO and provisioned VMs (e.g. NTP)
  • DNS resolution of provisioned VMs from VRO appliance and of Puppet infrastructure from the provisioned VMs.

This article covers the following

  • Puppet authentication certificate
  • Granting access to puppet APIs
  • SSH access to Puppet Infrastructure
  • Template preparation for provisioning windows puppet agents

Puppet Infrastructure Configuration

The SovLabs Puppet Enterprise module uses a certificate to authenticate with the Puppet Console API and CA API. These steps outline generating the certificate and then granting it access to sign certificates and reconfigure machines.

Puppet Authentication Certificate

SSH to the Puppet Enterprise CA host. As root:

puppetserver ca generate --certname vrosvc

This command generates the following two files:

Type Location
API Certificate /etc/puppetlabs/puppet/ssl/certs/vrosvc.pem
Private Key /etc/puppetlabs/puppet/ssl/private_keys/vrosvc.pem

The contents of each of these files will need to be copied into the SovLabs configuration. To show the complete contents of each file you can use cat.

cat /etc/puppetlabs/puppet/ssl/certs/vrosvc.pem
cat /etc/puppetlabs/puppet/ssl/private_keys/vrosvc.pem
CA Certificate

Additionally the existing CA certificate (not the private key) is required:

cat /etc/puppetlabs/puppet/ssl/certs/ca.pem

Grant access to puppet APIs

The vrosvc account needs to be granted 2 specific rights:

  1. Node classification: puppet_enterprise::profile::console::whitelisted_certnames.

  2. Signing puppet node certificates: puppet_enterprise::profile::certificate_authority::client_whitelist

If these properties are managed differently in your environment, please amend accordingly.
Adding vrosvc to: puppet_enterprise::profile::console::whitelisted_certnames
  1. In the console, click Classification, and select the node group that contains the puppet_enterprise::profile::console class.

  2. By default puppet_enterprise::profile::console is attached to the PE Console group under PE Infrastructure On the Configuration tab, find puppet_enterprise::profile::console, select the Parameter name from the list and edit its value:

    Parameter Value
    whitelisted_certnames [ “vrosvc” ]
  3. Click Add parameter and commit changes.
Adding vrosvc to: puppet_enterprise::profile::certificate_authority::client_whitelist
In Puppet Enterprise 2018 there is a bug that prevents you from adding this as a class param (e.g. via GUI), so we recommend you add via hiera:

SSH to the Puppet Enterprise host. As root:

echo -e '\n\npuppet_enterprise::profile::certificate_authority::client_whitelist:\n - 'vrosvc'\n' >> /etc/puppetlabs/code/environments/production/data/common.yaml
Complete Configuration

Run puppet agent on the puppet master.

puppet agent -t

SSH access to Puppet Infrastructure

In order the SovLabs puppet module to perform some operations, e.g. pushing hiera data and executing pre/post scripts, SSH access is required to the puppet infrastructure hosts.

If these are separate servers in your environment, you need credentials with login and sudo rights to each of:

  • Puppet CA
  • Puppet Compile Master
  • Puppet database server

In a small environment (monolithic install), these will be installed on a single server.

The user account must fulfil the following requirements

  • Login via SSH
  • Have a valid shell, e.g. /bin/bash
  • sudo (or other elevation), to root shell without sudo password prompt

It is recommended to create a user specific to this integration so that use of the account can be audited. Please consult your Puppet administrator for the creation of this account as this process will be specific to your environment.

An example sudoers configuration for a user vrasvc is shown:

# /etc/sudoers.d/vrasvc
vrasvc        ALL=(ALL)       NOPASSWD: ALL
Defaults:vrasvc !requiretty

Provisioning Windows VMs

If you plan to provision Windows VMs with Puppet Enterprise, the SovLabs module will need to connect to the newly provisioned VM to install the Puppet agent. For Windows VMs, the SovLabs module supports WinRM in addition to VMware Tools and SSH connection options available on Linux. Whilst we recommend using VMware Tools, there may be scenarios you wish to use WinRM to execute the installation remotely.

Choose from one of the following options

  1. VMware Tools
  2. SSH
  3. WinRM
VMWare Tools

Before using the VMWare Tools Option a vCenter Endpoint connection must be defined. This connection to vCenter will be used to connect to the VM via the vSphere Guest API.

  1. Create a SovLabs vCenter Endpoint (required)
  2. Create the Puppet Agent with vmware-tools as the Connection Type on the Puppet Agent Configuration tab.
WinRM

Before using WinRM, your image (or domain GPOs) will need to be configured to ensure that WinRM is available when the machine has completed its initial startup.

As enabling WinRM is a key change to your Windows image please confirm these steps are appropriate for your environment with your Windows administrator.

We have provided an example script that can be used in your windows template.

  1. Download activateWinRM.ps1
  2. Put the activateWinRM.ps1 script into a share OR incorporate it into your Windows Template in vCenter.
  3. In your Customization Specification, call the activateWinRM.ps1 script in the Run Once section
Using activateWinRM.ps1 from a share location

cmd /c powershell -executionpolicy Bypass -noninteractive -file //example.sovlabs.net/SovlabsSoftware/activateWinRM.ps1
Using a local copy of activateWinRM.ps1 in the template:

cmd /c powershell -executionpolicy Bypass -noninteractive -file c:\example_dir\activateWinRM.ps1