#160 – Preloading Cache


This week on the podcast, Kyle shares his thoughts on apply CPU vs. PSU java patches and Dan explains the different options for preloading application server cache.

Show Notes

Using the DPK Redeploy Option for CPU Patching

There are lots of ways to apply CPU patching and how to automate it. We’ve covered a few methods on the blog, but I wanted to show another way with the DPK. This method combines using patched archives (discussed here) and an option in the DPK that isn’t really talked about: redeploying software.

Redeploy Option

In the DPK, there is an option to redeploy software that you have already installed. The redeploy option is supported for all the middleware, PS_HOME, and PS_APP_HOME. If you include

redeploy: true

in your psft_customizations.yaml file, the DPK will uninstall all the middleware, PS_HOME, and PS_APP_HOME (if your DPK role is an app role), and then reinstall those from your DPK archives folder. This is slick if you want fix a bad install, or in our case, apply a new version of the software. We can replace the archive file for JDK or WebLogic, trigger a redeploy by running Puppet, and the new version will be installed.

But, there are some downsides to how the DPK handles this. First, it’s all or nothing; you can redeploy all of the middleware or none of the middleware. If you redeploy, your PS_HOME (and PS_APP_HOME) will be redeployed and you’ll need to recompile your COBOL files (if you still use them). That’s too sledgehammer-y for me.

Also, we don’t always want to redeploy our software. We may only want to run a redeploy for new patches. To enable a redeploy, we have to update our configuration, run puppet, then remove our configuration change. I don’t like making transactional changes to my configuration files. Our configuration should be static.

A Better Redeploy Option

Given these downsides, I still like the redeploy option with the DPK. I made some changes to the DPK to make it work better. The changes had two goals:

  1. Don’t include transaction data in the configuration files
  2. Offer per-software redeploy options

To get the first goal, we’ll use Facter to control when we redeploy. Facter offers the ability to override facts by using environment variables. We can set a sane default for our fact (false) but when we want to run a redeploy we can set an environment variable.

For the second goal, we will modify some of the DPK code to read new variables. The global redeploy option will stay, but there will new per-software redeploy options.

My end state for applying CPU patches looks like this:

$env:FACTER_weblogic_redeploy="true"
puppet apply .\site.pp --confdir c:\psft\dpk\puppet

Puppet will run, redeploy only WebLogic from an updated archive file, and bring my system back up. The rest of the software (PS_HOME, Tuxuedo, etc) is left untouched.

DPK Modifications

The next section is a bit code heavy, but hang tight. This all fits together really well.

Custom Facts

We can include custom facts in the DPK to report whatever we want. In this case, we’ll create facts that report false for different software to redeploy. These go in the file modules/pt_role/lib/facter/redeploy.rb.

Facter.add(:jdk_redeploy) do
  setcode do
    'false'
  end
end

Facter.add(:weblogic_redeploy) do
  setcode do
    'false'
  end
end

Facter.add(:tuxedo_redeploy) do
  setcode do
    'false'
  end
end

We now have 3 custom facts:

  • ::jdk_redeploy
  • ::weblogic_redeploy
  • ::tuxedo_redeploy

If we want to set these values to true, we can set these environment variables:

  • FACTER_jdk_redeploy=true
  • FACTER_weblogic_redeploy=true
  • FACTER_tuxedo_redeploy=true

That’s all it takes to override these facts. (This isn’t true of all facts provided by Facter, but for our custom facts this works.)

YAML Configuration

Next, we will read these facts into our configuration. Include this section at the root of your psft_customizations.yaml file.

jdk_redeploy:           "%{::jdk_redeploy}"
weblogic_redeploy:      "%{::weblogic_redeploy}"
tuxedo_redeploy:        "%{::tuxedo_redeploy}"

Puppet Changes

Now the changes get a little more involved. First, we need to read our new variables into the pt_tools_deployment.pp manifest. We’ll set false as the default value in case we forget to add the values to our psft_customizations.yaml. Then, we need to update the call to ::pt_setup::tools_deployment so our new configuration options are passed to the class. (It’s a good practice to only do the hiera lookups in the pt_profile manifests and not in the pt_setup manifests.) These changes are made in modules/pt_profile/manifests/pt_tools_deployment.pp.

  $jdk_redeploy           = hiera('jdk_redeploy', false)
  $weblogic_redeploy      = hiera('weblogic_redeploy', false)
  $tuxedo_redeploy        = hiera('tuxedo_redeploy', false)


  class { '::pt_setup::tools_deployment':
    ensure                 => $ensure,
    deploy_pshome_only     => $deploy_pshome_only,
    db_type                => $db_type,
    pshome_location        => $pshome_location,
    pshome_remove          => $pshome_remove,
    inventory_location     => $inventory_location,
    oracleclient_location  => $oracleclient_location,
    oracleclient_remove    => $oracleclient_remove,
    jdk_location           => $jdk_location,
    jdk_remove             => $jdk_remove,
    jdk_redeploy           => $jdk_redeploy,
    weblogic_location      => $weblogic_location,
    weblogic_remove        => $weblogic_remove,
    weblogic_redeploy      => $weblogic_redeploy,
    tuxedo_location        => $tuxedo_location,
    tuxedo_remove          => $tuxedo_remove,
    tuxedo_redeploy        => $tuxedo_redeploy,
    ohs_location           => $ohs_location,
    ohs_remove             => $ohs_remove,
    redeploy               => $redeploy,
  }

Next, we have to update the API for ::ps_setup::tools_deployment so it knows what values we are passing. These changes are made in modules/pt_setup/manifests/tools_deployment.pp.

class pt_setup::tools_deployment (
  $db_type                = undef,
  $pshome_location        = undef,
  $pshome_remove          = true,
  $inventory_location     = undef,
  $oracleclient_location  = undef,
  $oracleclient_remove    = true,
  $jdk_location           = undef,
  $jdk_remove             = true,
  $jdk_redeploy           = false,
  $weblogic_location      = undef,
  $weblogic_remove        = true,
  $weblogic_redeploy      = false,
  $tuxedo_location        = undef,
  $tuxedo_remove          = true,
  $tuxedo_redeploy        = false,
  $ohs_location           = undef,
  $ohs_remove             = true,
  $redeploy               = false,
)

Last, we have to add some logic to handle our new redeploy options. We’ll keep the main redeploy option, but for each software we’ll evaluate the software-specific redeploy option.

    if ($redeploy == true) or ($jdk_redeploy == true) {
      $java_redeploy = true
    } else {
      $java_redeploy = false
    }
    pt_deploy_jdk { $jdk_tag:
      ensure            => $ensure,
      deploy_user       => $tools_install_user,
      deploy_user_group => $tools_install_group,
      archive_file      => $jdk_archive_file,
      deploy_location   => $jdk_location,
      redeploy          => $java_redeploy,
      remove            => $jdk_remove,
      patch_list        => $jdk_patches_list,
    }

That’s the end of the changes. It’s a little more invasive than I’d like, but the end result is worth it. We can now tell Puppet to do software-specific redeploys. This let’s us deploy new versions of the software by updating the archive file, setting an environment variable, and then running puppet apply.

#144 – Environment “Cluster”


This week on the podcast, Kyle has some follow-up on PIA installations and discovers some unpleasant Unified Navigation behavior. Dan shares some tips for Facter and testing out the redeploy option with the DPK.

Show Notes

  • PIA Installation FUP @ 1:30
  • Facter and FACTER_ override @ 4:30
  • Redeploy and WebLogic @ 8:00
  • CPU Patching @ 18:30
  • Unified Nav and SSO @ 23:00

#143 – Reconnect 2018 Recap


This week on the podcast, Kyle and Dan recap the Reconnect 2018 conference, what they learned about the PeopleTools Roadmap, and some highlights from their sessions.

Show Notes

  • PeopleTools Roadmap Session @ 6:00
  • Securing and Hardening PeopleSoft @ 15:30
  • Kyle’s CPU Talk @ 20:30
  • Dan’s Devops and DPK @ 27:00
  • Advanced PeopleSoft Adminstration @ 29:00
  • PeopleTools Product Panel @ 37:00

#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

#123 – ps_patch


This week on the podcast Dan and Kyle discuss Colton Fischer’s Web Profile discovery, Kyle shares his CPU Patching process and how he automated the process then Dan discusses how he resolved a PIA domain bug.

Show Notes

#117 – Invalid Views


This week on the podcast, Dan and Kyle discuss a WebLogic exploit used for currency mining, Dan revisits the Health Center in the latest PeopleSoft Images, and Kyle explains why you need to review the Invalid View project.

Show Notes

#106 – Purging Cache

This week on the podcast, Kyle finds the ProcessRestartMemoryLimit does not work as expected, Dan finds that the Purge Cache command has changed in 8.56, and Kyle recaps a successful Go-Live for PeopleTools 8.55 and Fluid Navigation.

Show Notes

  • Page and Field CONFIGURATOR Follow-up @ 1:00
  • October CVE Details @ 6:00
  • Understanding ProcessRestartMemoryLimit @ 11:30
  • Purge Cache Change in 8.56 @ 19:45
  • Elasticsearch 04 DPK, POC Patches @ 25:30
  • Unified Nav and My Favorites @ 31:30
  • 8.55 and Fluid Nav Go-Live Success and Issues @ 38:15