#134 – psadmin.conf 2018 Recap


This week on the podcast, Kyle and Dan recap the psadmin.conf 2018 conference.

Show Notes

  • Vulnerability Testing During Happy Hour @ 1:30
  • DPK Lab and Open Lab @ 4:45
  • Kyle and Team Save the World @ 11:30
  • JR Bing on Kuebernetes and Elasticsearch @ 13:00
  • Greg Wendt on GH Insights @ 18:00
  • Frank Dolezal on Monitoring PeopleSoft @ 21:30
  • David Vandiver’s Process Monitor 2.0 @ 29:00
  • Nate Werner on Protecting Secrets @ 31:30
  • Kyle and Dan on using Terraform with PeopleSoft @ 37:00
  • Brad Carlson on the open source IB Monitor @ 39:00
  • Scott Hirni on PeopleMobile UX @ 43:00
  • Tech Roundtable @ 47:00
  • Mark Hoernemann on the PeopleTools Roadmap @ 49:30

#133 – Off by One


This week on the podcast we review caching options for the app server, Kyle shares a bug with Unified Navigation and synchronizing User Preferences with Unified Navigation.

Show Notes

#132 – Works Like Magic


This week on the podcast, Dan shares a Vagrant plugin to help with Root Certificates and a change to WebLogic certifications with 8.56. Then Kyle and Dan discuss running VERSION and how to deal with bad cache.

Show Notes

#130 – Independent and Unsupported


This week on the podcast, Dan and Kyle discuss the Apache Axis vulnerability from the April 2018 CPUs, an Adventures in MOS, and some of the challenges in moving to the cloud. Kyle also shares an update about his new job.

Show Notes

#129 – Alliance 2018 Recap


This week on the podcast, Brad Carlson, Adam Wlad and Jim Marion join Dan to recap the Alliance 2018 conference. We discuss some CPU Patching issues, the 2027 date for PeopleSoft, and PeopleTools 8.57 announcements.

Show Notes

  • Technical and Reporting Advisory Group @ 1:45
  • CPU Patching and Security @ 5:15
  • PeopleSoft 2027 @ 15:00
  • PeopleTools 8.57 – Cloud First @ 19:30
  • PeopleTools 8.57 UI Changes @ 29:15
  • Page and Field Configurator @ 40:00
  • App Designer Improvements @ 49:45
  • Stop and Shares @ 56:30
  • Learning about Fluid @ 60:00

#128 – Extending PeopleSoft w/ Colton Fischer


This week on the podcast, Colton Fischer joins Dan to talk about hidden ACM plugins, using the Web Profile to extend HTML pages, and his experience working with the Page and Field Configurator.

Show Notes

Improve the Management of DPK Archives

In Episode 127 of the podcast, Kyle and I discuss some strategies for managing the DPK archive files. The discussion started because I am starting a PeopleTools 8.56. To upgrade each server we copy the new DPK archive files to every server and run the DPK. Having a copy of those archives on every server is redundant and not the best solution.

 

A better solution is to store the DPK archives in centralized place. We run into a problem in the DPK when the archive folder has multiple versions of the same archive. For example, if we have two versions of the Weblogic archive, the DPK will return an error because it doesn’t know which one to deploy.

This error is generated from the function get_matched_file(). get_matched_file() is a custom DPK function that looks at the DPK Archive location and returns a filename based on a tag. The tags are string values like weblogic, pshome, and jdk. The DPK looks for all the file names that match the tag. If there is more than one file, the function returns an error.

Specifying Archive Files

Instead of letting the DPK search a directroy for matching archive files, we could explicity define which archive files we want to deploy. While this isn’t as dynamic, the method would give us more control over which version of each software we deploy. It could also solve the issue with centralizing all our DPK Archives.

To use this method, we have to make two changes to the DPK:

  • Create a new hash to store the archives we want to deploy
  • Update the Puppet code to read from the new hash

Hash to Store Archive Data

In the psft_customizations.yaml file, we create a new archive_files: hash. This hash is where we can explicitly define which archive files we want to use.

archive_files:
  weblogic:             "%{hiera('archive_location')}/pt-weblogic12.2.1.2.20180116.tgz"
  tuxedo:               "%{hiera('archive_location')}/pt-tuxedo12.2.2.0.tgz"
  jdk:                  "%{hiera('archive_location')}/pt-jdk1.8.0_144.tgz"
  pshome:               "%{hiera('archive_location')}/pt-pshome8.56.06.tgz"
  oracleclient:         "%{hiera('archive_location')}/pt-oracleclient12.1.0.2.tgz"
  psapphome:            "%{hiera('archive_location')}/fscm-psapphome027.tgz"

The keys to use the hash are the DPK tags for each piece of software. This lets us leverage the built-in tagging system in the DPK. If you want to take it a step further, you can define the hash with additional variables for each version. For example, in a common.yaml file, configure the archive_files: hash like this:

archive_files:
  jdk:                  "%{hiera('archive_location')}/pt-jdk%{hiera('jdk_version')}.tgz"
  pshome:               "%{hiera('archive_location')}/pt-pshome%{hiera('tools_version')}.tgz"

Then, in your psft_customizations.yaml file you can specify:

jdk_version:    1.8.0_144
tools_version:  8.56.06

Update Puppet to Read the Hash

Next, in the tools_deployment.pp file (under dpk/puppet/modules/pt_setup/manifests) we need to modify the code to use our archive_list: hash. In the delivered code, the DPK archive location and software tag are passed to the Ruby function get_matched_files(). What we will do instead is check if the archive_list: hash is defined. If it is, we will use the path from the hash instead of calling get_matched_file. If the archive_files: hash does not have the tag defined (like pshome), the get_matched_file() function is called.

Here is the code for deplying WebLogic:

$archive_files = hiera('archive_files', '')

if $archive_files {
  $weblogic_archive_file   = $archive_files[$weblogic_tag]
} 
if $weblogic_archive_file == '' {
  $weblogic_archive_file = get_matched_file($tools_archive_location, $weblogic_tag)
}
if $weblogic_archive_file == '' {
  fail("Unable to locate archive (tgz) file for Weblogic in ${tools_archive_location}")
}

You can copy this code for the rest of the archive types in the tools_deployment.pp and app_deployment. For DPK types that you do not specify, the DPK will revert to the original behavior.

I like this setup better. We get more control over which DPK archives we deploy, we can store multiple archives in a central location, and we retain the delivered behavior as the default.

#127 – Managing DPK Archives


This week on the podcast Kyle and Dan discuss different strategies for managing DPK archive files. Dan also discovers a few small improvements in the 8.56 PS_HOME and where to find the mythical Application DPK files.

Show Notes

  • App Designer Bug in 8.56 @ 1:00
  • 8.56 PS_HOME @ 5:00
  • Client Tools Install @ 8:30
  • Application DPK @ 11:00
  • Mananging DPK Archives @ 14:30

#126 – Elasticsearch Backups


This week on the podcast, Dan and Kyle discuss options and considerations for backing up Elasticsearch. Kyle also shares a bug with the PIA startup scripts built by the DPK and Dan makes Vagrant work with a Web Filter.

Show Notes