- 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:
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 /etc/puppetlabs/puppet/ssl/certs/vrosvc.pem cat /etc/puppetlabs/puppet/ssl/private_keys/vrosvc.pem
Additionally the existing CA certificate (not the private key) is required:
Grant access to puppet APIs
The vrosvc account needs to be granted 2 specific rights:
Signing puppet node certificates:
Adding vrosvc to: puppet_enterprise::profile::console::whitelisted_certnames
- In the console, click Classification, and select the node group that contains the
puppet_enterprise::profile::consoleis 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” ]
- Click Add parameter and commit changes.
Adding vrosvc to: puppet_enterprise::profile::certificate_authority::client_whitelist
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
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
- 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.
- Create a SovLabs vCenter Endpoint (required)
- Create the Puppet Agent with vmware-tools as the Connection Type on the Puppet Agent Configuration tab.
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.
We have provided an example script that can be used in your windows template.
- Download activateWinRM.ps1
- Put the
activateWinRM.ps1script into a share OR incorporate it into your Windows Template in vCenter.
- In your Customization Specification, call the
activateWinRM.ps1script 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