#83 – DPK – What We’d Do Different Next Time

This week on the podcast Dan and Kyle discuss changes they would make if they started working on the DPK for the first again. They also discuss setting up Elasticsearch clusters, monitoring Tuxedo queues with Elasticsearch and an annoying Bash on Windows bug.

Show Notes

  • Bash on Windows VPN Bug @ 3:15
  • 9.2 Upgrade Process @ 10:00
  • Monitoring Tuxedo Queueing in Elasticsearch @ 13:30
  • Tuxbeat Project @ 17:00
  • Elasticsearch DPK @ 21:45
  • Elasticsearch Clustering @ 27:00
  • Puppet on Linux @ 32:00
  • DPK Extract Only @ 34:30
  • What we’d do differently with the DPK @ 37:30
    • Co-locating Regions
    • Admin-only Test Servers
    • Config Homes
    • Use Git for managing code and YAML changes
    • Integrate all Puppet code into Classes and Modules
    • DPK Course
    • Use ACM via DPK
    • Go Vanilla

App Capacity Visualization

#71 – DevOps and Ansible w/ Jason Gilfoil and Eric Bolinger

This week we podcast from the Alliance 2017 Conference in Las Vegas. Jason Gilfoil and Eric Bolinger join us to talk about DevOps and Ansible with PeopleSoft. We talk about application orchestration, mixing Ansible and Puppet, customizing the DPK and more.

Show Notes

  • Introducing Jason Gilfoil @ 1:30
  • Introducing Eric Bolinger @ 2:45
  • What is Ansible? @ 3:30
  • What is Orchestration? @ 8:00
  • Differences between Puppet and Ansible @ 12:00
  • Puppet Master, Hiera Hash and the DPK @ 15:15
  • Managing infrastructure code with Git @ 20:45
  • Adjusting to a DevOps culture @ 27:00
  • Getting automation started in your organization @ 30:30
  • Calculating Time Saving for Automation @ 35:30
  • Choosing an automation tool @ 41:30
  • Docker @ 43:00
  • Personal Development Environments @ 45:45
  • Starting to think “cloud” @ 50:00

#61 – Jolt Failover

This week on the podcast, Dan and Kyle launch a new course about Deployment Packages. Dan tests out a new text editor and discovers you can run OPatch on MOS. Kyle digs into Jolt Failover options with the IB and brainstorms some great configuration ideas.

Show Notes

#59 – Security Deployment

This week on the podcast Dan and Kyle talk about the new CFO tool, applying CPU patches with the DPK, and how the DPK could improve with newer versions of Puppet. Then Dan digs into the new Security Deployment tool and how you can use it improve security migrations.

Show Notes

Encrypt psft_customizations.yaml Passwords

In the psft_customizations.yaml file we store configuration information for a server, including passwords. There is a project, hiera-eyaml, that supports encrypting and decrypting sensitive data in Hiera YAML files. Out of the box, the Windows-based DPK doesn’t work with hiera-eyaml. For Linux DPK, check out 2188771.1 – there is better support in the Linux DPK for hiera-eyaml.

In this post, we’ll walk through the steps to get hiera-eyaml working on Windows and how to encrypt data in the psft_customizations.yaml file.

Update RubyGems

The version of Ruby, and RubyGems, that ships with the DPK can’t install new Gems. The RubyGems version doesn’t support trust the site’s SSL certificate. To fix that, download the root certificate and tell RubyGems to trust it.

  1. Download the newer SSL certificate.
  2. Save the file as RubyGemsRootCA.pem
  3. Copy the new certificate to C:\Program Files\Puppet Labs\Puppet\sys\ruby\lib\ruby\2.0.0\rubygems\ssl_certs

Copying the new certificate to ssl_certs will tell RubyGems to trust any certificate signed by it. Now we can use RubyGems to install hiera-eyaml on the server.

Install hiera-eyaml

When Puppet is installed, it includes Ruby and RubyGems binaries because Puppet is written in Ruby. We’ll use the gem utility to install the hiera-eyaml RubyGem. First, we should update PATH to include Puppet’s Ruby binaries:

  1. $env:PATH += ";C:\Program Files\Puppet Labs\Puppet\sys\ruby\bin"
  2. gem install hiera-eyaml

RubyGems will install any dependencies and report the progress.

Fetching: trollop-2.1.2.gem (100%)
Successfully installed trollop-2.1.2
Fetching: highline-1.6.21.gem (100%)
Successfully installed highline-1.6.21
Fetching: hiera-eyaml-2.1.0.gem (100%)
Successfully installed hiera-eyaml-2.1.0
Parsing documentation for trollop-2.1.2
Installing ri documentation for trollop-2.1.2
Parsing documentation for highline-1.6.21
Installing ri documentation for highline-1.6.21
Parsing documentation for hiera-eyaml-2.1.0
Installing ri documentation for hiera-eyaml-2.1.0
3 gems installed


Hiera-eyaml uses it’s own Public and Private keys to encrypt and decrypt data. If you have inspected the puppet\ssl directory, you will see folders for public and private keys. These keys are used by Puppet to communicate with a Puppet Server. We use different keys for encrypting data in psft_customizations.yaml.

The keys should be created in the folder C:\ProgramData\PuppetLabs\puppet\etc\secure\keys\. To ensure the keys are created in the correct location, Hiera-eyaml and Hiera know where they are, we’ll create a configuration file for Hiera-eyaml.

  1. Create eyaml.yaml under C:\ProgramData\PuppetLabs\hiera\etc and add these values:

    pkcs7_private_key: C:\ProgramData\PuppetLabs\puppet\etc\secure\keys\private_key.pkcs7.pem  
    pkcs7_public_key: C:\ProgramData\PuppetLabs\puppet\etc\secure\keys\public_key.pkcs7.pem
  2. Set the EYAML_CONFIG environment variable:

  3. Create new encryption keys for Hiera-eyaml to use:

    eyaml createkeys

Keep these new keys safe and locked down; they decrypt your passwords!

Encrypt Passwords

Now that we have installed Hiera-eyaml and created keys, let’s do a quick test to make sure we can encrypt passwords. This test will encrypt the text “VP1”:

eyaml encrypt -s VP1

The output will look similar to this:

string: ENC[PKCS7,MIIBeQYJKoZIhvcNAQcDoIIBajCCAWYCAQAxggEhMIIBHQIBADAFMAACAQEwDQYJKoZIhvcNAQEBBQAEggEALsKtTfAXyHyE/k5r2U2ZZU98SqaQ5/ukfNR/FkOt9bNhoZ1EomqmqIc/06l7Tk5W4BYJA0mXV6ykLgOHYTAJbVPM8gXBuHsw1jh+/VC0er7evlzqtf7UjIvu3rTo+0LUm2X3imjbWHGhyrs2bxm0L1qpC2atlTSzEYrSc6OxkTpZA19Y8iEJxFb+F0fGwsQ3SRVJD1J3Jwf0hAsHN/SXX/p2ywn5qz2BnlJl4wa7ragYv4aVBGbGF3ThvYMCTzNiFHtyHdCFvPX9i/t0fpDUJY76ndAl/T4q/Stopnq6Gm9vLJH5EC6KMUQZzb0ssDHriojQgUH7uFt8/Wn9vFeTQTA8BgkqhkiG9w0BBwEwHQYJYIZIAWUDBAEqBBBFcUOesdHoJgYi5PnXGmkAgBDbEJsr/tDXbDpJu7+xz9uL]


block: >

Hiera-eyaml gives two options for output: string and block. For psft_customizations.yaml I’m using the string output. It’s cleaner and easier to insert into the file. We can request string output only and assign a label to the encrypted password:

eyaml encrypt -s VP1 -o string -q -l db_user_pwd

The output should look like this:

db_user_pwd: ENC[PKCS7,MIIBeQYJKoZIhvcNAQcDoIIBajCCAWYCAQAxggEhMIIBHQIBADAFMAACAQEwDQYJKoZIhvcNAQEBBQAEggEAV2y+yriBfuFlXspBIzZ8eBEOow7FU7mcwYL1HCpHd+XrwIliMTgDj+4X47XXQ3bce4WRvaezHUNahJQF4OZrwlGdCgXYeFG4dYvMEg/75T0704I2+y/XmLpI3Y5swd3L9LnHfxpAm6x8AJpf2yybSP4rsD1IxZgrpjy1CjFe3GuRW9ZcNFkNq5WofRweoX4C9QgNp1bmXQnJym+ZnVe1y7vQ9iEY336vF2FH3wJNgqRIy+74RWj9F+OaAg78meSxM0eM7jm4fLa32cMmOLzfU/FGFhLFcQJ2FaAa5/SWmBSgtwDUXsGaLcSa0R2nfQZrbRWmlP+s1WYL9MzkLFTEoDA8BgkqhkiG9w0BBwEwHQYJYIZIAWUDBAEqBBDMAfrBMvJ+HRA+iL4zyQppgBBcHlLe8hUl6JD1jFXH/N22]

We can pass the output of this command into the clipboard and then paste the line directly into psft_customizations.yaml:

eyaml encrypt -s VP1 -o string -q -l db_user_pwd | set-clipboard

set-clipboard requires WMF 5.0

Edit YAML Files

Encrypting passwords on the command line is great, but what if you want to edit all of the passwords in your psft_customizations.yaml file at once? Hiera-eyaml has an edit command that will decrypt the passwords in psft_customizations.yaml and open the file in a text editor for you. First, we need to set the EDITOR environment variable:

  1. $env:EDITOR="notepad.exe"
  2. eyaml edit .\psft_customizations.yaml

Notepad will open the psft_customizations.yaml file. At the top of the file, you will see a large comment block explaining how to add and edit passwords. (The comment block will go away when you close Notepad.)

Add New Passwords

To add a new password, you wrap the plain text password inside the brackets in this syntax: DEC::PKCS7[plaintextpassword]! For example,

db_user_pwd:     DEC::PKCS7[VP1]!

If you save and close the file, and open psft_customizations.yaml directly in Notepad, you will see the db_user_pwd: password is encrypted.

db_user_pwd:  ENC[PKCS7,MIIBeQYJKoZIhvcNAQcDoIIBajCCAWYCAQAxggEhMIIBHQIBADAFMAACAQEwDQYJKoZIhvcNAQEBBQAEggEAdGWx7WeuGw3lULsdDANpYotX66B1wzO3U9H47RLJA+s4cIVg5z2JtzTp+uHOp9L9SdcNyzsvo6+uPY29DxMsaIUv9Dfa5LWKv+GZypH4myJYxbNfhtRE5TcLWxxwTSji9WYxDyFu8FFJGIkdNcEzN4svG6CknDhmA/od/NPanQg+xWbjP2qJkiOMi2fDwPJd11dev7Qm4NcwkZzdcsMBpkSgL3eL2dZ/BzdJndWrsGlYfUAy0TLxJD9a4aBCiwYoWWmmS4smnmtmti0R1DPEs8BpAl5L76JItMUwzRsnmu5IZ8odxn8rQZQNJaOVk/oScp4SRIgCh5+tYp7FMvgM/jA8BgkqhkiG9w0BBwEwHQYJYIZIAWUDBAEqBBCqrQ+GokeF23Of2odDkv5JgBBulnH4XkLOrQBEy+fa7cMr]

Excellent – we have encrypted passwords!

Edit Passwords

The next step is to edit existing encrypted passwords in the psft_customizations.yaml file. The eyaml edit command will open the file and decrypt passwords. The password syntax will be slightly different – it will have a number assigned to the password: db_user_pwd: DEC(1)::PKCS7[VP1]!

The (1) is used internally by Hiera-eyaml, so don’t change it. But you can change the password inside the square brackets. After changing the password, save and close the file and your updated passwords will be encrypted.

Enable eyaml with the DPK

When we push psft_customizations.yaml out to servers, we also need to ensure each server has the keys used to encrypt the passwords, and also knows about Hiera-eyaml. First, if you are using the encrypted passwords on more than one server, copy the puppet\etc\secure\keys folder to each server.

Next, Hiera needs to know that we are using Hiera-eyaml. In C:\ProgramData\PuppetLabs\hiera\etc\hiera.yaml, enable eyaml as a back-end format by adding - eyaml to the ;backends: section:

    - yaml
    - eyaml

Verify that the :eyaml: section is at the bottom of hiera.yaml. Change the paths to the Public and Private keys. If you followed the steps above and created them in puppet\etc\secure\keys, the paths will look like this:

    :datadir: C:\ProgramData\PuppetLabs\puppet\etc\data
    :extension: yaml

    :pkcs7_private_key: C:\ProgramData\PuppetLabs\puppet\etc\secure\keys\private_key.pkcs7.pem
    :pkcs7_public_key:  C:\ProgramData\PuppetLabs\puppet\etc\secure\keys\public_key.pkcs7.pem

Save hiera.yaml and let’s test our configuration.

Testing Hiera-eyaml

To test Hiera-eyaml and Puppet working together, we’ll encrypt the a password in psft_customizations.yaml and update UserPswd= value in psappsrv.cfg.

  1. Open psft_customizations.yaml with eyaml edit and add the line:

    db_user_pwd: DEC::PKCS7[VP1]!
  2. Save and close psft_customizations.yaml.

  3. Save this code below as pwd.pp and save it to puppet\etc\manifests. Change the $configFile path to point to your psappsrv.cfg file.

    $configFile = 'C:/Users/vagrant/psft/pt/8.55/appserv/APPDOM/psappsrv.cfg' 
    ini_setting { "eyaml_test": 
        ensure => present, 
        path => $configFile, 
        section => 'Startup', 
        setting => 'UserPswd', 
        value => hiera('db_user_pwd'), 
  4. Change directories to puppet\etc\manifests.

  5. Run puppet apply .\pwd.pp --trace --debug

  6. After the run is done, open your psappsrv.cfg file. You should see UserPswd=VP1 in the file.

If the test above worked, you’re all set to use Hiera-eyaml with the DPK and Puppet. Once Hiera knows about Hiera-eyaml, any data in Hiera can be encrypted. Happy encrypting!

Enable Tuxedo Domain Features with the DPK

Since the DPK was released, there has a been a bug (for Windows) that is quite annoying. In the psft_customizations.yaml file, the feature_settings: section is supposed to turn Tuxedo domain features on or off.

  PUBSUB:           "Yes"
  QUICKSRV:         "No"
  QUERYSRV:         "Yes"
  JOLT:             "Yes"

On Windows, these settings were ignored and the default values were used when a domain was created or reconfigured. Thanks to Dale Haman from the psadmin.io Community, we have a fix for the bug. The issue is this:

The DPK (Puppet) takes the feature_settings: section in the psft_customizations.yaml file and combines it into a string. The string is passed into psadmin with the -u parameter. The code that creates this string used an incorrect separator for each feature, so psadmin would ignore the entire string.

To fix this, you can edit one file under the puppet/etc/modules folder:


if Facter.value(:osfamily) == 'windows'
  # feature_settings_separator = '#'
  # For Windows, we need to use the slash
  feature_settings_separator = '/'
  feature_settings_separator = '%'

If you re-run puppet apply .\site.pp, your app server and process scheduler domains features should match what you defined in psft_customizations.yaml.

Process Scheduler Features

After testing this on a process scheduler, I noticed my scheduler had 5 features listed in psadmin but only two were configured in my psft_customizations.yaml file: MSTRSRV and APPENG. I wanted to configure the other features in the domain, so I added them to my psft_customizations.yaml file:

  MSTRSRV:          "Yes"
  APPENG:           "No"
  PPM:              "No"
  DOMAIN_GW:        "No"

If you run puppet apply .\site.pp with these parameters in your psft_customizations.yaml file, you’ll get an error saying the Feature List is not valid. The feature_settings: section is compared to an array in the Process Scheduler Puppet Type to make sure you don’t mis-type anything, or try to add a non-existent feature. But in this case, the validation array was incorrect. It was missing the "PPM" feature.


prcs_features =
  # Add PPM because it is a scheduler feature...KIOSK is not.

Comment out the bad line and change "KIOSK" to "PPM" in the array. Now, you can configure all 5 process scheduler features from the psft_customizations.yaml file.

Check out the other bug fixes for the DPK too:

Introduction to Vagrant


As an admin, creating and testing new software with virtual machines has made our jobs easier. Using VirtualBox and your computer, we can set up a VM and test anything. With the PeopleSoft Images, we can quickly set up a new demo environment and test new features.

While setting up new virtual machines is easy, it does require many steps like downloading the base image, setting up users, installing software and more. Getting the same base virtual machine every time requires attention to detail and doing the same steps, over and over.


Vagrant is a tool that creates the same virtual machine for you every time. You can use Vagrant to create your own VM, or use someone elses VM. Vagrant also simplifies the creation and management of virtual machines on your computer. Here is an example of how to use Vagrant to start a new Puppet Enterprise server on Centos 6:

vagrant init puppetlabs/centos-6.6-64-puppet
vagrant up

That’s it!

The first command tells Vagrant that we want to create an image from the template puppetlabs/centos-6.6-64-puppet from Puppet Labs. The second command tell Vagrant to start the VM. The vagrant up command will download the base virtual machine file from Vagrant’s Atlas site, start the image in VirtualBox, and do any server configuration once the VM starts.


Vagrant is a front end to VirtualBox, but it will also work with VMWare, Hyper-V, Amazon Web Services, Docker and more. Using different providers is pretty easy (AWS takes a little more setup), and Vagrant handles each providers system for you. We only worry about our Vagrant configuration, not the platform our virtual machines are running on. For this post, and others, we’ll stick to VirtualBox since it’s a free option and works on multiple operating systems.


Atlas is service from Vagrant were you can find virtual machine templates created by community members. On Atlas you can search for an OS or software and find virtual machines that people have created. Some of the popular virtual machines are:

  • hashicorp/precise64 – Ubuntu 12.04 TLS 64-bit
  • centos/7 – Centos 7 64-bit
  • puppetlabs/centos-6.6-64-puppet – Puppet Enterprise on Centos 6.6.64
  • mwrock/Windows2012R2 – Windows 2012 R2 (Evaluation License – 180 days)

Install Vagrant

The first step to using Vagrant is to install the latest build. Go to the Vagrant Downloads page and grab the installer for your platform. Download the installer and run it.

Next we need VirtualBox installed. If you already have it installed, take this time to upgrade to the lastest version. You can download the latest version of VirtualBox here.

Create a Virtual Machine


Now we can use Vagrant to create a new virtual machine. Open a command prompt and navigate to the folder where you want to store the virtual machine.

cd ~/VirtualBox VMs/

Next, create a new folder to hold our first virtual machine:

mkdir elastic_test
cd elastic_test

We’ll use the centos/7 base image for our test.

vagrant init centos/7

The init command will create a new file in the folder: Vagrantfile. The Vagrantfile tell Vagrant how to configure the virtual machine. We use this file to give the VM a name, how much memory to use, what networking type, and more. We’ll come back to file later.

The next step is to start the virtual machine.

vagrant up

The up command does a few things:

  1. Checks to see if you have VM on the system
  2. If not, download the image from Atlas
  3. Start the VM in VirtualBox (headless VM)
  4. Configure port forwarding and connect to the VM with SSH
  5. Set up the Vagrant share
  6. Run any provisioning scripts in the VM

That one command handles a lot of work for us. Let’s look at some of the key steps.

vagrant Shared Folder

By default, Vagrant will share the folder where you create the virtual machine as /vagrant inside the VM. This share is convenient but is also important for Vagrant provisioning. Script inside the folder, in our case elastic_test, are accessible in the VM. We can configure different folders to share as well. In Vagrantfile, uncomment and modify `

config.vm.synced_folder "../data", "/vagrant_data" 

to point to the folder on your host you want to share. The next time you start the virtual machine the share will be configured.

Vagrant ssh

For Linux virtual machines, SSH is configured when the VM is created. To access the virtual machine via SSH, use

vagrant ssh

You can use traditional ssh commands, but using vagrant ssh will use pre-configured SSH keys and log you into the VM.

Port Forwarding and Networking

By default, Vagrant will set up the virtual machine to use a private IP address. This means you can only access the VM from the host machine. When the VM is created, port 2222 is configured to forward requests to port 22 (for SSH). vagrant ssh knows this, so it connects to localhost:2222 when you connect to the VM. To change the networking configuration so anyone on your network can access the VM, update this line in Vagrantfile:

config.vm.network "public_network"

Vagrant will create a second network adapter that grabs a public IP from your networks DHCP server.

Memory and More

The last change we’ll make to the virtual machine is setting the memory and enabling the GUI. When Vagrant starts a Linux VM, it starts a Headless session (no GUI window). If you are comfortable with SSH and command lines this won’t be an issue. If you want to see the VM window in VirtualBox, we’ll update the Vagrantfile to show the GUI.

  config.vm.provider "virtualbox" do |vb|
    # Display the VirtualBox GUI when booting the machine
    vb.gui = true

    # Customize the amount of memory on the VM:
    vb.memory = "1024"

For Windows virtual machines, except Windows Server Core/Nano, the GUI will display by default.

Restart, Shutdown and Delete VM’s

To restart or stop a virtual machine created by Vagrant, we use these commands:

  • Restart: vagrant reload
  • Shutdown: vagrant halt

If you are done with the virtual machine and want it removed from your system, use:

vagrant destroy



Those are the basics to using Vagrant. Once you spend a few minutes working with Vagrant, it is hard to go back to creating virtual machines by hand. But quickly creating VM’s is only one benefit of Vagrant. Vagrant has an excellent provisioning mechanism, which means you can create the same VM every time.

Let’s install Elasticsearch in our virtual machine. In the Vagrantfile, find the section config.vm.provision and update it:

config.vm.provision "shell", inline: <<-SHELL
  sudo yum install wget -y
  sudo yum install java -y
  sudo rpm --import https://packages.elastic.co/GPG-KEY-elasticsearch
  sudo wget https://gist.githubusercontent.com/iversond/a5d8985657a9a6c4332dd9a776bd195a/raw/88d3b1b3eb14a4f638ce07473550d108287e4e7e/yum-elasticsearch.repo -O /etc/yum.repos.d/elasticsearch.repo
  sudo yum install elasticsearch -y
  sudo systemctl daemon-reload
  sudo systemctl enable elasticsearch.service
  sudo systemctl start elasticsearch.service

Vagrant will run the provisioning script the first time a virtual machine is created, but we can re-run provisioning at any time. Run the command:

vagrant provision

After the provisioning scripts run, log into the virtual machine and check if Elasticsearch is running.

vagrant SSH
curl -X GET http://localhost:9200/

If Elasticsearch installed correctly, you’ll see a response like this:

  "name" : "Talia Josephine Wagner",
  "cluster_name" : "elasticsearch",
  "cluster_uuid" : "x1W8bOqBTEy8rdR0P6VUwg",
  "version" : {
    "number" : "2.4.1",
    "build_hash" : "c67dc32e24162035d18d6fe1e952c4cbcbe79d16",
    "build_timestamp" : "2016-09-27T18:57:55Z",
    "build_snapshot" : false,
    "lucene_version" : "5.5.2"
  "tagline" : "You Know, for Search"

Disposable and Consistent VM’s

Let’s say we messed up our VM by accidentally running a bad command, or updated some software that messed up our configuration. For example:

rm -rf / --no-preserve-root

Now our virtual machine is broken. Let’s use Vagrant to delete and recreate our VM. We should have the same VM we had before we “accidentally” ran that command.

First step is to shutdown and remove the virtual machine:

vagrant halt
vagrant destroy

If you look at the directory where Vagrant stored the virtual machine, you’ll see the Vagrantfile still exists, but the virtual machine files are gone. Now let’s recreate our virtual machine:

vagrant up

SSH into our rebuilt VM and test Elasticsearch:

vagrant ssh
curl -X GET http://localhost:9200/

That was easy 🙂 We build, broke, removed and rebuilt a virtual machine with a few commands. If you want to build more complex machines (think DPKs), Vagrant supports Puppet, Ansible and more for provisioning.

Chocolatey Package Manager for Windows

One advantage of Linux distributions is they include software package managers like yum or apt-get. Package managers make is easy to install software with a single command, like yum install vlc. There is a package manager for Windows that works well and integrates with Puppet: Chocolatey. Let’s explore how to use Chocolatey and how it works with Puppet.

Microsoft has a package manager, OneGet, but OneGet new enough that it’s not installed by default in PeopleSoft-certified versions of Windows.

Install Chocolatey via PowerShell

If you want to install Chocolatey with PowerShell, the Chocolatey installation page has example commands to do this. The scripts will download and execute a remotely signed PowerShell script which installs Chocolatey and configures it for you. I used:

iwr https://chocolatey.org/install.ps1 -UseBasicParsing | iex

to install Chocolatey on my server.


Using Chocolatey

After installation, restart your PowerShell window. Installing software with Chocolatey is a simple as running this command:

choco install notepadplusplus

Chocolatey will install Notepad++ for you. Simple!


Want to install git on your server?

choco install git


If you want to accept license agreements automatically, run this command to change Chocolatey’s global setting:

choco feature enable -n=allowGlobalConfirmation

I primarily use Chocolatey for server management, but you can use it to manager your workstation too. The library of chocolatey packages contains server and workstation software. To view the library, head over to the chocolatey website.

Install Chocolatey via Puppet

chocolatey can be used with Puppet to manage software package on your server. There is an official Puppet module for Chocolatey, so we can install the module and use it our own manifests.

puppet module install chocolatey-chocolatey

You may fine the the module install failed due because the Puppet Forge root certificate is not in the Windows keystore. You’ll also notice some warnings about the version number for the pt_xxx modules. You can ignore those warnings; the version numbers used by the PeopleTools team don’t follow the Puppet conventions.


To install the root certificate for Puppet Forge:

  1. Save this certificate (GeoTrust Global CA) as GeoTrustCA.pem.
  2. Run certutil -v -addstore Root .\GeoTrustCa.pem to add the certificate
  3. Re-run puppet module install chocolatey-chocolatey


The Chocolatey module depends on three additional Puppet libraries, so the installation windows shows you the dependencies it installed.

└─┬ chocolatey-chocolatey 
  ├── badgerious-windows_env 
  ├── puppetlabs-powershell 
  └── puppetlabs-stdlib 

Use Chocolatey with Puppet

Now we can use Chocolatey in Puppet manfiests. This is great because we can standardize software packages on our servers the same way we standardize configurations.

On my Windows Servers, I use Process Explorer to troubleshoot issues. It’s a free tool from Microsoft and is great for finding processes that are locking access to files. Let’s write a Puppet manifest to install Process Explorer using chocolatey.

On the Chocolatey Packages page, search for “Process Explorer”.


In the results, you’ll see the Chocolatey command to install Process Explorer. Copy the name of the package; we’ll use the name in our manifest.

Create windows_software.pp under puppet\etc\manifests. The first line of the manifest will be to include the “Chocolatey” library.

include chocolatey

Then, we need to define a Puppet resource. We use the package resource, give it the name of the Chocolatey package (from above), and set the ensure parameter.

package { 'procexp':
    ensure => present,

Finally, we tell Puppet to use Chocolatey as the package manager.

package { 'procexp':
  ensure => present ,
  provider => 'chocolatey',

Save windows_software.pp and run puppet apply:

puppet apply .\windows_software.pp


When the Puppet run is done, you’ll find Process Explorer installed into Chocolatey’s installation directory. The default directory is C:\ProgramData\chocolatey\lib\.


Update: 9/27/2016

Andy from the psadmin.io Community and podcast episode 42 suggested this tip for using Chocolatey to install git:

choco install -y git -params "/GitAndUnixToolsOnPath"

This will install additional tools like SSH with Git. Thanks Andy!

#46 – OpenWorld 2016 Predictions

This week, Dan and Kyle discuss decommissioning software that isn’t used, PeopleCode documentation pet-peeves and how to start using Puppet before upgrading to 8.55. We end the episode with predictions for OpenWorld 2016.

We want to make this podcast part of the community discussion on PeopleSoft administration. If you have comments, feedback, or topics you’d like us to talk about, we want to hear from you! You can email us at podcast@psadmin.io, tweet us at @psa_io, or use the Twitter hashtag #psadminpodcast.

You can listen to the podcast here on psadmin.io or subscribe with your favorite podcast player using the URL below, or subscribe in iTunes.

Podcast RSS Feed

Show Notes

  • OOW 2016 @ :30
  • psadmin.io Community Benefits @ 1:30
  • Hidden psadmin menu option @ 6:00
  • Elasticsearch Release Date Change @ 8:00
  • Missing Trace Files @ 10:45
  • PeopleTools Delta Projects @ 15:00
  • PeopleCode PeopleTools Check @ 27:15

    #If #ToolsRel >= "8.54" #Then
       import PTPN_PUBLISH:PublishToWindow;
  • PeopleCode Documentation Pet-Peeve @ 31:45

  • Two Roles for Applying PUM Maintenance @ 35:45

  • Adventures in MOS: UPK Support with 8.55 @ 37:00

  • Decomissioning Software @ 39:00
  • SR to Bug @ 41:30
  • Getting Started with Rundeck and PeopleSoft @ 43:00
  • Getting Started with Puppet before Upgrading to 8.55 @ 44:45
  • OOW 2016 Predictions @ 52:30

Advanced DPK: Building a PIA Domain

With the DPK, you can build many configurations: full systems like the PeopleSoft Images, a web server, a combination of domains, or deploy the middleware software only. The goal of the DPK is to build you a server for you from a single set of configuration files.

But, what if you want to spin up a temporary web domain and test something without impacting your standard configuration? You can add the temporary domain to the psft_customizations.yaml file, but the DPK will shut down every domain on the server before it builds the new domain. That’s not a good solution.

Behind the DPK are new Puppet types that provide interfaces to create domains using Puppet. If you look in the file puppet\etc\modules\pt_config\tests\test_pia_create.pp, you can see this in action. The test creates variables and array’s to pass into the pt_webserver_domain Puppet type. Calling pt_webserver_domain will create a new PIA domain. Let’s explore this Puppet type and see how we can use it to create temporary domain

I want to say, use this method only if you have a good understanding of Puppet. This post is showing how to build PIA domains directly so we can better understand how the DPK works.

Custom YAML files

In the test_pia_create.pp manifest, the arrays are created in the manifest. We’ll use a YAML file to store our data instead. I find writing arrays in Puppet to be tedious and can break easily. Hiera and YAML files are much easier to work with, and we can use this manfiest for more domains in the future.


hrdev.yaml is a small YAML file that stores data for a single PIA domain. It is important to keep the structure of the pia_domain_list section so we can easily take the YAML data and pass it into the pt_webserver_domain type. In the hrdev.yaml file, you can update any settings you want to configure the domain the way you want.

    os_user:            psadm
    ps_cfg_home_dir:    e:/psoft/hrdev-8.55.06
    gateway_user:       administrator
    gateway_user_pwd:   'Passw0rd'
    auth_token_domain:  .psadmin.io

      webserver_type:           weblogic
      webserver_home:           e:/psoft/pt/bea
      webserver_admin_user:     system
      webserver_admin_user_pwd: 'Passw0rd'
      webserver_admin_port:     10020
      webserver_http_port:      10020
      webserver_https_port:     10030

        LoggingEnabled:         true

        appserver_connections: app-d1:10010
        domain_conn_pwd:       'Passw0rd'

          profile_name:        DEV
          profile_user:        PTWEBSERVER
          profile_user_pwd:    'Passw0rd'
        report_repository_dir: e:/psreports

YAML Hashes and Arrays

YAML files can store data in various ways. The two common types the DPK uses are hashes and arrays. Hashes are key: value pairs, and can also contain nested hashes. The config_settings and pia_site_list sections are an example of a nested hash.

The DPK types use Arrays but the psft_customizations.yaml file (other others) use hashes. Hashes are often easier to work with because they are more descriptive. Thankfully, the DPK comes with some helper functions to convert a nested hash into a nested array.

Custom PIA Manifest

Next, we’ll start writing a Puppet manifest that will load hrdev.yaml and prepare our PIA domain. To start, let’s load our data and get the pia_domain_list hash into a variable:

$tempWebServer = loadyaml('c:\temp\hrdev.yaml')
$pia_domain_list = $tempWebServer['pia_domain_list']

Next, we’ll loop through the pia_domain_list hash and prepare the pt_webserver_domain DPK type to create our PIA domain.

$pia_domain_list.each |$domain_name, $pia_domain_info| {

The $domain_name value is the key of the hash, and $pia_domain_info is the nested hash. Those values will be accessible inside our loop. Next, we’ll take the webserver_settings, pia_site_list, and config_settings (if it exists in the YAML file) sections and turn them into nested arrays. The PeopleTools team delivers an excellent function hash_of_hash_to_array_of_array() function that does the heavy lifting.

$webserver_settings = $pia_domain_info['webserver_settings']
  $webserver_settings_array  = join_keys_to_values($webserver_settings, '=')

  $pia_site_list         = $pia_domain_info['site_list']
  $pia_site_list_array   = hash_of_hash_to_array_of_array($pia_site_list)

  $config_settings = $pia_domain_info['config_settings']
  if $config_settings {
    $config_settings_array = hash_of_hash_to_array_of_array($config_settings)

Last, we’ll instantiate the pt_webserver_domain Puppet type with our configuration data.

pt_webserver_domain { "${domain_name}":
  ensure                => hiera('ensure'),
  ps_home_dir           => hiera('ps_home_location'),
  os_user               => hiera('domain_user'),
  ps_cfg_home_dir       => $pia_domain_info['ps_cfg_home_dir'],
  webserver_settings    => $webserver_settings_array,
  config_settings       => $config_settings_array,
  gateway_user          => $pia_domain_info['gateway_user'],
  gateway_user_pwd      => $pia_domain_info['gateway_user_pwd'],
  auth_token_domain     => $pia_domain_info['auth_token_domain'],
  site_list             => $pia_site_list_array,

Running the Manifest

Save the piaDomain.pp manifest to your c:\programdata\puppetlabs\puppet\etc\manifests folder, and the hrdev.yaml file to c:\temp folder. From the puppet\etc\manfiests folder, run puppet apply piaDomain.pp --trace --debug. The PIA build process can take 5-10 minutes to run, but at the end you’ll have a PIA domain built using the DPK and Puppet.

Both hrdev.yaml and piaDomain.pp are on Github if you want to download the files and test.

Building Blocks

If you want to spin up a single PIA domain, this may feel like overkill. The value in learning Puppet and the DPK isn’t to build a single domain, it’s a building block to quickly (and consistently) build many domains. The piaDomains.pp manifest can scale to multiple domains and all you have to do is update the YAML file.

Not everyone may need (or want) to dig into the DPK this deep. But for anyone who wants more control over their environment build with the DPK, using the Puppet types that come with the DPK will be an invaluable skill.

If you are building an app server domain with this method, use this bug fix to ensure the app server features are correctly enabled.