#84 – No Agenda

This week on the podcast Dan and Kyle talk with no agenda. We discuss our week and talk about Portal, PeopleTools Bugs, Fluid, Git, Deployment Packages, Puppet, OneNote, Kanban Boards and more.

Show Notes

  • Portal Projects @ 1:45
  • PeopleTools Bugs and Puppet @ 10:45
  • psadmin.io Community @ 21:00
  • Job changes @ 23:30
  • Spreading the Fluid Excitement @ 25:00
  • Selecting Fluid Nav Images @ 28:00
  • The Git “Trojan Horse” @ 31:30
  • Git Hooks, Puppet Server and getting crazy @ 39:30
  • Changes to the DPK? @ 47:00
  • Kanban Boards @ 57:00
  • Svchost.exe @ 58:30
  • OneNote Templates @ 60:30
  • Kanban Boards and Task Management @ 71:00

#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

#82 – Embracing Fluid Navigation

This week on the podcast, Kyle and Dan revisit Fluid Navigation and why they are fans of the new navigation model. Kyle shares his experiences working with the DPK and his method for managing the YAML and Puppet files on servers. Dan shares a top-notch “Dad Joke”.

Show Notes

#80 – Apply Your CPU Patches!

This week, Kyle and Dan talk about using Vagrant snapshots with Vagabond, strategies for managing psft_customizations.yaml files and demonstrating Fluid to end users. Dan shares a story of how an unpatched WebLogic server can leave your PeopleSoft application vulnerable to hackers.

Show Notes

  • Securing the Oracle Listener @ 1:30
  • Vagabond and Vagrant Snapshots @ 2:00
  • Vault and Hiera @ 7:45
  • Remote Desktop Spanning @ 14:00
  • Why You Apply CPU Patches – A Story @ 16:30
  • CPU Patching Wishlist @ 23:30
  • DPK and Middleware-only @ 33:15
  • psft_customizations.yaml strategies @ 39:00
  • Upgrading Interaction Hub @ 50:00
  • Demoing Fluid @ 57:00

Apply CPU Patches with Deployment Packages

We have talked on the podcast about different ways to apply CPU patches, but with the DPK we have another tool to help us quickly apply CPU patches. This post and video demo’s will show you how to use the DPK to quickly apply CPU patches to your servers.

Deployment Workflow

When you run the DPK, it will deploy WebLogic, Java, Tuxedo (and more) on your server. The DPK uses archives (also known as “tarballs”) of prepackaged installations and extracts those archives to your server. There is one big problem, the archives included in the DPK’s do not contain the latest security patches. So, let’s make our own tarballs that include the security patches to deploy. This process is also a great exercise to better understand how the DPK deploys software.

If you are on Linux you can use the patching functionality with the DPK, but that code has not been written for Windows. I’m not covering that feature in this post, but the DPK Install Guide has a section on using that functionality (Task 6-3-1: Using the DPK Setup Script to Apply Fixes).

Movement Scripts

There are Fusion Middleware scripts the DPK uses to deploy WebLogic and Tuxedo. (Thanks to Eric Bolinger for pointing me in this direction.) The movement scripts allow you to take a current install of WebLogic, package it up, and deploy it to additional servers. This is how the DPK deploys WebLogic. The PeopleTools team packages up a WebLogic installation and we deploy that install to our servers. The movement scripts also manage the Oracle Inventory file for you.

There are many parts to the movement scripts, but we’ll be using just one part: copyBinary. This script will take a current installation and create a .jar file from that installation. We’ll use copyBinary to package our patched WebLogic installation.

If you have errors with the pasteBinary.cmd on the target system, you may need to configure the $ORACLE_HOME\oui\oraparam.ini file. This is a configuration file used by the OUI software. To make this simple, I copied the settings in the current $BASE\dpk\archives\weblogic12.1.3.0.tgz to my $ORACLE_HOME\oui\oraparam.ini using Beyond Compare. (Yes, Beyond Compare can read inside a tarball and compare against a directory!) Then I recreated my tarball with the updated oraparam.ini file.

Create a Patched WebLogic Tarball

 

Next, it’s time to install the CPU patch and run the copyBinary.cmd script. Stop all your PIA services on the server so you can remove the existing installations.

First, let’s patch Java. For demonstration, I’m using the jdk-7u141-windows-x64 installer. I’m installing

Then, we’ll use OPatch to apply the CPU to WebLogic:

cd $PATCH
$env:ORACLE_HOME=e:\psoft\pt\bea
$env:ORACLE_HOME\OPatch\OPatch napply

Once OPatch is done, we’ll use the movement scripts to package up our installation.

$env:JAVA_HOME=e:\psoft\pt\jdk1.7.0_141
. ${env:ORACLE_HOME}\oracle_common\bin\copyBinary.cmd -javaHome ${env:JAVA_HOME} -archiveLoc ${env:TEMP}\pt-weblogic-copy.jar -sourceMWHomeLoc ${env:ORACLE_HOME}

The output file from this command needs to be named pt-weblogic-copy.jar. The DPK expects that is the name of the .jar file. Next, we create a tarball of the pt-weblogic-copy.jar and two files to do the deploy portion of the movement scripts: cloningclient.jar and pasteBinary.cmd. These movement scripts are used by the DPK to deploy WebLogic. I used 7-zip to create my tarball with these three files:

$WL_VERSION="12.1.3.170418"
7z a -ttar "${env:TEMP}\pt-weblogic${WL_VERSION}.tar" "${env:ORACLE_HOME}\oracle_common\jlib\cloningclient.jar"
7z a -ttar "${env:TEMP}\pt-weblogic${WL_VERSION}.tar" "${env:ORACLE_HOME}\oracle_common\bin\pasteBinary.cmd"
7z a -ttar "${env:TEMP}\pt-weblogic${WL_VERSION}.tar" "${env:TEMP}\pt-weblogic-copy.jar"

Last, we gzip the archive and drop it in the $BASE\dpk\archives folder:

$env:DPK_BASE="e:\psft"
7z a -tgzip "${env:DPK_BASE}\dpk\archives\pt-weblogic${env:WL_VERSION}.tgz" "${env:TEMP}\pt-weblogic${env:WL_VERSION}.tar"

One thing to note here – the DPK doesn’t handle multiple versions of software in the dpk\archives folder well. So, only have one pt-weblogic* file in there.

For Java, we don’t need to use the movement scripts. We’ll simply tarball up the new directory and include that in our $BASE\dpk\archives folder.

$JDK_VERSION="1.7.0_141"
7z a -ttar "${env:TEMP}\pt-jdk${JDK_VERSION}.tar" $env:JAVA_HOME\*
7z a -tgzip "${env:DPK_BASE}\dpk\archives\pt-jdk${JDK_VERSION}.tgz" "${env:TEMP}\pt-jdk${JDK_VERSION}.tar"

Deploy CPU Patches

 

Copy your updated tarballs to a new server. You’ll want to remove the existing tarballs from the $BASE\dpks\archive to prevent the DPK from raising an error.

We have two options for telling the DPK we want to install WebLogic. The first option is to delete the existing WebLogic and Java folders. If you stop your PeopleSoft domains, you can delete both folders. When you run the DPK it will see that WebLogic and Java are missing and reinstall them from the patched tarballs in the $BASE\dpk\archives folder.

The other option is use the redeploy: true flag in psft_customizations.yaml. If you set the redeploy variable to true, the DPK will redeploy all the software in your $BASE\dpk\archives folder. This option requires less work – set a variable in psft_customizations.yaml and run the DPK – but it can take longer because you will redeploy Java, Tuxedo, WebLogic, PS_HOME and more. I think of this option as “the Puppet way”.

For this post and demo, we’ll use the redeploy: true option in our psft_customizations.yaml file. We’ll also use one other trick for testing; we will only run the part of the DPK that handles the middleware. Instead of running the entire DPK that touches the OS, middleware, and domains, the manifest we call includes only the DPK role that ensures the middleware is installed and not touch other parts of the system. This will also speed up our CPU patch deployment.

middleware.pp

Let’s create a new file under c:\programdata\puppetlabs\puppet\etc\manifests called middleware.pp. You can start by cloning the site.pp file. Change the file to look like this:

node default {
  include ::pt_role::pt_tools_deployment
}

Save the file. That’s it!

What we have done is tell Puppet to only run the DPK role pt_tools_deployment instead of running a larger role like pt_hcm_pum.

In the video demo, we are applying patches to a PeopleSoft Image, which is a Fulltier setup. The default pt_tools_deployment.pp manifest won’t run on a Fulltier system. To get around that, I created a copy of pt_tools_deployment.pp manifest called io_tools_deployment.pp and removed the check on env_type: fulltier.

cpu.ps1

We have a few tasks to do before we can run the middleware.pp manifest. We’ll wrap those tasks in a Powershell script we can run on each server.

At a high level, here are the tasks our cpu.ps1 script will do:

  1. Copy new DPK archives to server
  2. Stop PeopleSoft Services
  3. Remove current Java and WebLogic installs (if redeploy: false)
  4. Run middleware.pp to install patched Java and WebLogic
  5. Start PeopleSoft Services

Get the Sample Code

The full code is in the ps-dpk-tarballs GitHub repository. You can find all the scripts from this post and demo on GitHub.

#72 – Alliance 2017 Recap

This week on the podcast, Dan and Kyle review some of the highlights from the Alliance conference. Then, they talk about about the history of PTF, hidden gems in PeopleTools, upcoming 8.56 changes and more.

Show Notes

  • Collaborate Sessions
  • PeopleTools Roadmap Session @ 2:30
    • 8.56 Supported Platform Changes
    • DPK Improvements
    • Virtual CD End of Life
  • Extending PeopleSoft the Fluid Way @ 12:00
    • Fluid Nav Collections
    • Update Save Event Mapping
  • DevOps and PeopleSoft @ 21:30
    • Calculating Automation Time Savings
  • PS Admin Toolbelt @ 25:30
  • PeopleSoft Automation and Deployment @ 31:30
    • PS_APP_HOME Patching
  • PeopleSoft Cloud Architecture Tips @ 38:00
  • PeopleTools Product Panel @ 42:15
  • Lifecycle Management Panel @ 51:45

#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

#62 – PeopleTools Patch Testing

This week on the podcast, Dan and Kyle talk about load balancing all environments or some environments, Diagnostic Plugins and syntax coloring code. Then, they dive into the getting current and how to test PeopleTools Patches.

Show Notes

Announcing the Deployment Packages Course

We are excited to announce a new course, Mastering PeopleSoft Administration: Deployment Packages. This course will teach you how to make Deployment Packages (DPK) work for you. We begin the course by exploring the different components that make up the DPK, how you can configure the DPK, and how to enhance it. Then, the course shows you how to extend the DPK beyond it’s current functionality and use it to build servers exactly the way you need them.

Out of the box, the DPK is great for building demo environments. But most organizations have requriements for their environments that go beyond what the DPK can do. Those requirements can include custom signon pages, deploying additional software, and more. Learning how to use the DPK to deploy those requirements as you build environments can significantly benefit you. With the DPK, environment and server builds are repeatable, consistent and fast.

To learn more about the course, check out the videos below.

  • A course introduction video
  • A segment from the podcast where Kyle and Dan discuss why we built the course and what you can learn from it
  • A video on why you should buy a course from psadmin.io
  • Dan’s 48-minute talk on Enhancing and Extending the DPK

Last, there are 5 free lectures from the course available to watch right now. Click here to visit the course page and make sure to watch all the free lectures.

Course Introduction

 

Podcast Segment about the Deployment Packages Course

Why Buy a psadmin.io Course

 

Enhancing and Extending Deployment Packages Talk

Dan presented at the Upper Midwest Regional User Group about Enhancing and Extending the DPK (October 2016). This 48 minute talk goes over some DPK basics, introduces configuring the DPK and your possibilities for extending the DPK. If this talk is exciting and you want to know more, The Deployment Packages Course will go into the details of this talk and show you how to accomplish it all.

 

#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