Extending psadmin with psadmin-plus

I have created a helper menu script to extend the delivered psadmin program. The script is called psadmin-plus and I have created a repository for it on psadmin.io’s GitHub account. This was built as a self-study side project while I was on paternity leave this summer. I wanted to learn a little more about bash scripting and how to use git, and at the same time try to make a useful tool for myself and others to use. As of this writing, the tool is usable but far from complete. At the moment it only has support for Linux. I hope to make improvements over time and would invite others to summit issues on GitHub for questions, bugs or enhancement ideas. If anyone wants to contribute themselves, that would be great too!

There are two main uses for psadmin-plus. The first is actually calling the delivered psadmin program. The value add here is that it will auto-discover all your PS_CFG_HOME directories for you and source environment variables as needed. This all assumes you follow a few conventions, which should be documented in the GitHub readme or wiki pages. As mentioned in a previous blog post, this is useful if you use a single user to run your PeopleSoft environments. If you have a different user for each environment and source at login, then this feature doesn’t really help.

The second use is executing actions against multiple PS_CFG_HOMEs and domains at once. An example would be to stop all Process Scheduler domains on a machine. With this tool, you can do this with a few key strokes. You also have the option to execute now or later. If you select later, a script will generate to file. This allows you to run at a future time, maybe during a maintenance window. Again, there are a few assumed conventions that must be followed.

If you want to try it out for yourself, I have created a setup script to run against a PeopleSoft Image(VBox or Linux DPK install only). This will create a few extra PS_CFG_HOMEs and domains for you to play with in the menu. You can find instructions in the GitHub readme.

Below is a quick demo of psadmin-plus in use. For more information please see GitHub.

psadmin-plus-demo

#34 – psadmin-plus

This week Kyle and Dan discuss the Diagnostic Plugin Framework, sourcing environment variables for PeopleTools, Kyle’s great new psadmin-plus project. Also, we find out who it a c:\temp person and who is a Desktop person.

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

Custom webApp DPK Role

In an earlier post, I talked about the site.pp file and how the DPK uses that file to determine what software to install. I covered the roles used by the DPK and in this post we’re going to create a custom role.

One of my criticisms of the DPK is the lack of a webApp role. You can install a scheduler, app server, web server, appBatch server, but not a webApp server. We are consolidating our web and app servers onto a single machine and I wanted to use the DPK to install the software and the initial configuration. The delivered roles didn’t work, so we created our own webApp role for the DPK.

pt_tools_webapp

To start, I copied the delivered role file pt_tools_midtier.pp and named it pt_tools_webapp.pp. In the pt_tools_webapp.pp file I removed the lines:

contain ::pt_profile::pt_prcs

contain ::pt_profile::pt_tools_preboot_config
contain ::pt_profile::pt_tools_postboot_config

Class['::pt_profile::pt_prcs'] ->
Class['::pt_profile::pt_tools_preboot_config'] ->
Class['::pt_profile::pt_tools_postboot_config'] ->

Remove the Class[] lines from both sections of the manifest.

The line Class['::pt_profile::pt_prcs'] -> calls the profile that will create/configure the process scheduler. By removing this line, Puppet will skip the process scheduler creation step.

I also removed the two lines that call the ACM: Class['::pt_profile::pt_tools_xxxboot_config']. When we built our servers, the database was already configured. I didn’t want to the ACM to run when built the web and app servers. We’ll run the ACM on our own schedule. If we left these two lines in, the ACM would run every time we built a new server with this role.

Last, update the class name to the new role: class pt_role::pt_tools_webapp inherits pt_role::pt_base {, and the notification to notify { "Applying pt_role::pt_tools_webapp": }. (I also removed the checks for env_type.)

This is what our role pt_tools_webapp.pp file looks likes:

class pt_role::pt_tools_webapp inherits pt_role::pt_base {
  notify { "Applying pt_role::pt_tools_webapp": }

  $ensure   = hiera('ensure')

  contain ::pt_profile::pt_tools_deployment
  contain ::pt_profile::pt_psft_environment
  contain ::pt_profile::pt_appserver
  contain ::pt_profile::pt_pia
  contain ::pt_profile::pt_samba
  contain ::pt_profile::pt_source_details

  if $ensure == present {
    contain ::pt_profile::pt_domain_boot

    Class['::pt_profile::pt_system'] ->
    Class['::pt_profile::pt_tools_deployment'] ->
    Class['::pt_profile::pt_psft_environment'] ->
    Class['::pt_profile::pt_appserver'] ->
    Class['::pt_profile::pt_pia'] ->
    Class['::pt_profile::pt_samba'] ->
    Class['::pt_profile::pt_domain_boot'] ->
    Class['::pt_profile::pt_source_details']
  }
  elsif $ensure == absent {
    Class['::pt_profile::pt_source_details'] ->
    Class['::pt_profile::pt_samba'] ->
    Class['::pt_profile::pt_pia'] ->
    Class['::pt_profile::pt_appserver'] ->
    Class['::pt_profile::pt_psft_environment'] ->
    Class['::pt_profile::pt_tools_deployment'] ->
    Class['::pt_profile::pt_system']
  }
}

To use the new role, change the site.pp file to this:

node default {
  include ::pt_role::pt_tools_webapp
}

Then run puppet apply site.pp to install and create your web-app servers.

There is a few bug with this custom role, but it is based on assumptions in the DPK. The pt_profile::pt_domain_boot profile doesn’t know about our webapp role. If you leave the pt_domain_boot profile in the role the DPK will attempt to start (or stop) a process scheduler domain. Since we don’t have one, you’ll see some errors in the output when you run puppet apply site.pp. You can ignore these, or you can modify the pt_domain_boot.pp manifest under etc\modules\pt_profile\pt_domain_boot.pp. I chose to ignore the errors.

We also added a new variable to the psft_customizations.yaml file called server_type:. We used server_type: webApp for our webApp servers, and then we can use that value in other Puppet manifests for any server-specific logic.

If you want to try this, keep in mind that the custom role won’t be supported by Oracle. It helps to have a basic understanding of Puppet when creating the roles, but this is also a great way to start learning Puppet and the DPK.

I also created an Idea on the Oracle Community Lifecycle Management site for the DPK webApp role. If you would like to see this supported in the DPK, go vote for it! I also posted the custom code to GitHub if you want suggest any changes.

#33 – Puppet and PeopleTools 8.55

This week on The PeopleSoft Administrator Podcast, we discuss various ways to manage environment variables and a great package from Chris Malek to use with JSON files. Then we dig into using Puppet with PeopleTools 8.55 and how you can extend the DPK’s with your Puppet modules.

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

Prevent WebLogic Install with prcs and app-only DPK Deployments

In this post, I introduced the site.pp file and how that relates to the DPK. I used the example of deploying a process scheduler with the DPK by using the bootstrap command psft-dkp-setup -env_type -domain_type prcs. This command will populate the site.pp file with the role ::pt_role::pt_tools_prcs.

For the most part, this works well. The DPK/Puppet will install Tuxedo, Java, Oracle Client, WebLogic and create your process scheduler domain. But there is one problem – we don’t need (or want) WebLogic on our process scheduler! Why does the DPK do this? The base profile that applies to all DPK server builds includes WebLogic and doesn’t check to see what type of install is happening.

Finding the WebLogic Deployment Manifest

Open the file for the role pt_tools_prcs. The file is under c:\programdata\puppetlabs\puppet\etc\modules\pt_role\manifests\ and named pt_tools_prcs.pp. This Puppet manifest lists the profiles that will be applied when creating a process scheduer.

Class['::pt_profile::pt_system'] ->
Class['::pt_profile::pt_tools_deployment'] ->
Class['::pt_profile::pt_psft_environment'] ->
Class['::pt_profile::pt_prcs'] ->
Class['::pt_profile::pt_tools_preboot_config'] ->
Class['::pt_profile::pt_domain_boot']

Each of these classes tied back to file under modules\pt_profile. The class that handles WebLogic and Tuxedo deployment is pt_tools_deployment. The pt_tools_deployment.pp manifest takes the configuration values from deployment.yaml (or psft_customizations.yaml if you overrode the defaults) and prepares the class pt_setup:tools_deployment.

In the file tools_deployment.pp under pt_setup\manifests\, you’ll see the base deployment configuration for any DPK installation. This file will install the software for a DPK run. Even if you aren’t familiar with Puppet (this file is a Puppet manfiest), you can read the file and get an idea of what’s happening.

The important section is roughly half way down and looks like this:

  pt_deploy_weblogic { $weblogic_tag:
    ensure                    => $present,
    deploy_user               => $tools_install_user,
    deploy_user_group         => $tools_install_group,
    archive_file              => $weblogic_archive_file,
    deploy_location           => $weblogic_location,
    oracle_inventory_location => $inventory_location,
    oracle_inventory_user     => $oracle_install_user,
    oracle_inventory_group    => $oracle_install_group,
    jdk_location              => $jdk_location,
    redeploy                  => $redeploy,
    remove                    => $weblogic_remove,
  }

Modifying the Manifest

In Puppet, the ensure variable will takes two options:

  • present – think of this as “install” (that isn’t technically accurate, but at a high level that’s what it means for the DPK)
  • absent – this value would uninstall WebLogic

In this manifest, there aren’t checks for each software package. Everything is installed, or everything is uninstalled. The simple fix is to update the ensure value to absent for WebLogic.

  pt_deploy_weblogic { $weblogic_tag:
    ensure                    => absent,
    deploy_user               => $tools_install_user,
    deploy_user_group         => $tools_install_group,
    archive_file              => $weblogic_archive_file,
    deploy_location           => $weblogic_location,
    oracle_inventory_location => $inventory_location,
    oracle_inventory_user     => $oracle_install_user,
    oracle_inventory_group    => $oracle_install_group,
    jdk_location              => $jdk_location,
    redeploy                  => $redeploy,
    remove                    => $weblogic_remove,
  }

After making this change, you can run puppet apply site.pp. If you are on working on a blank server, the DPK won’t install WebLogic. If WebLogic is installed, the DPK will uninstall WebLogic.

One big disclaimer, this is not supported by Oracle. So, make these changes knowing that Oracle won’t help you if you run into any issues. For my own experience, we made this change before deploying our process scheduler servers and it has worked well. But, that’s only my experience.

A better way to handle this fix would be to read in the domain_type setting from the defaults.yaml file.

Here is what that change would look like:

  if hiera('domain_type') == 'all' or hiera('domain_type') == 'pia' {
    $wl_ensure = 'present'
  } 
  else {
    $wl_ensure = 'absent'
  }
  pt_deploy_weblogic { $weblogic_tag:
    ensure                    => $wl_ensure,
    deploy_user               => $tools_install_user,
    deploy_user_group         => $tools_install_group,
    archive_file              => $weblogic_archive_file,
    deploy_location           => $weblogic_location,
    oracle_inventory_location => $inventory_location,
    oracle_inventory_user     => $oracle_install_user,
    oracle_inventory_group    => $oracle_install_group,
    jdk_location              => $jdk_location,
    redeploy                  => $redeploy,
    remove                    => $weblogic_remove,
  }

A quick lookup to the defaults.yaml file’s domain_type will tell us what type of installation was requested from the bootstrap script.

Closing Thoughts

This bug is annoying. But, one thing I really enjoy with the DPK (and Puppet), is that we have access to the code. That means we can research how the DPK is working and make changes are possible (if technically unsupported). But, we also have Puppet installed our servers and we can leverage it for our own modules. Coming up in future posts, I’ll be documenting some of the custom modules I’ve been writing to extend Puppet for our own use.

I have an SR open on this bug too, so if I get feedback I’ll update this post.

#32 – UMRUG 2016 Spring Meeting Recap

This week Dan gives a recap of the spring Upper Midwest Regional User Group meeting. The talks and roundtable discussions were great and we learned why PS_CUST_APP_HOME is gone in 8.55. Kyle and Dan also discuss IB development and the need for better App Class documentation.

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

  • Fun Twitter Accounts @ :30
  • Inconsistent Fluid Nav @ 3:45
  • IB Development @ 6:30
    • Helper Classes and JavaDoc
    • HCR_PUBLICATION_RULES:PersonBasicPublication
    • Undocumented App Class – %metadata
  • Kyle’s Oh No! Story @ 13:30
  • UMRUG Recap @ 20:00
    • New Development Tools Talk and Supplemental Data
    • NativeOS DPK Image upgrades
    • Security Automation Tool
    • Interface Data Stores
    • QAS for interfaces
    • PeopleTools/PUM Support
    • 8.56 – PT Patching will support Continuous Delivery
    • 8.56 Release date?
    • Refresh Script strategies
    • PS_CUST_APP_HOME Answers
    • Data Masking
  • PeopleTools 8.55 Certifications @ 49:00
  • Custom Type and Resources for Puppet? @ 53:00
    • pt_deploy and pt_config
  • SUSE Linux Support @ 55:00
  • 8.55 PT Upgrade Panel @ 57:00

Explaining the site.pp File

If you have customized any settings with the DPK’s, you have encountered the site.pp file. When you run the bootstrap script, there is a question at the end of the process asking you “Do you want to continue the default initialization process?”. If you answer “No”, the bootstrap script instructs you to make changes, and then run the command puppet apply site.pp. So, what is the site.pp file?

site.pp is a Puppet manifest and is what the DPK (aka Puppet) uses to build your server. A manifest describes what state the server should be after Puppet runs. Our site.pp file contains a role that describes how Puppet should configure the PeopleSoft components. We’ll cover those roles in a bit, but first let’s find out how the site.pp is populated.

Boostrap Parameters

When you run the bootstrap script (psft-dpk-setup), you can pass in a few parameters like env_type and domain_type. These parameters determine what components and software the DPK will install. The env_type parameter takes three options:

  • fulltier
  • midtier
  • dbtier

The fulltier option will install everything needed to run PeopleSoft (Oracle DB, Web, App, Batch). This is the default option and used by the PeopleSoft Images. dbtier will only install the Oracle Database software, and midtier will install software to web/app/batch domains.

If you choose midtier, you can also pass in the additional parameter domain_type. This parameter let’s you narrow down the installation even more. You can choose:

  • pia
  • appserver
  • batch
  • appbatch

These options install some of the components rather than all of them.

Last, we can also pass in the deploy_only and deploy_type parameters to the bootstrap script. This option tells the DPK to install the midtier software (WebLogic, Tuxedo, etc) but not configure any domains.

The complete list of parameters can be found in the DPK Guide under the section “Using the PeopleSoft PeopleTools DPK Setup Script.”

Site.pp Roles

So, how do these parameters affect the site.pp file? Each combination of parameter relates to different roles assigned to the site.pp file. Let me explain.

This is a site.pp file after running the bootstrap script with the command psft-dpk-setup -env_type midtier -domain_type prcs:

node default {
  include ::pt_role::pt_tools_prcs
}

The second line is the important one. ::pt_role::pt_tools_prcs tells Puppet to apply the PeopleTools DPK role pt_tool_prcs. These roles are different than PeopleTools security; they are Puppet roles. We can take a look at these roles under the folder c:\programdata\puppetlabs\puppet\etc\modules\pt_role\manifests\.

Under the pt_role\manifests folder, you’ll see a long list of files. Each file is a Puppet role, and each role ties back to the parameters in the bootstrap script.

If we open the file pt_tools_prcs.pp, we can see what actions are taken by Puppet.

if $ensure == present {
    contain ::pt_profile::pt_tools_preboot_config
    contain ::pt_profile::pt_domain_boot

    Class['::pt_profile::pt_system'] ->
    Class['::pt_profile::pt_tools_deployment'] ->
    Class['::pt_profile::pt_psft_environment'] ->
    Class['::pt_profile::pt_prcs'] ->
    Class['::pt_profile::pt_tools_preboot_config'] ->
    Class['::pt_profile::pt_domain_boot']
  }
  • pt_system makes some OS level changes for Linux
  • pt_tools_deployment deploys all the PeopleTools components
  • pt_psft_environment sets up PS_CFG_HOME, PS_APP_HOME and PS_CUST_HOME folders, and user information on Linux
  • pt_prcs configures a process scheduler domain
  • pt_tools_preboot_config runs the ACM app engine
  • pt_domain_boot will start the configured domains

Let’s compare this file to pt_hcm_pum.pp. This file is used by the HCM PeopleSoft Images:

  if $ensure == present {
    Class['::pt_profile::pt_system'] ->
    Class['::pt_profile::pt_app_deployment'] ->
    Class['::pt_profile::pt_tools_deployment'] ->
    Class['::pt_profile::pt_oracleserver'] ->
    Class['::pt_profile::pt_psft_environment'] ->
    Class['::pt_profile::pt_psft_db'] ->
    Class['::pt_profile::pt_appserver'] ->
    Class['::pt_profile::pt_prcs'] ->
    Class['::pt_profile::pt_pia'] ->
    Class['::pt_profile::pt_samba'] ->
    Class['::pt_profile::pt_tools_preboot_config'] ->
    Class['::pt_profile::pt_domain_boot'] ->
    Class['::pt_profile::pt_tools_postboot_config'] ->
    Class['::pt_profile::pt_source_details'] ->
    Class['::pt_profile::pt_opa']
  }

There are many more actions in this file, which explains why setting up a PeopleSoft Image configures everything.

Changing Roles

What can we do with the site.pp file? Quite a bit, actually. If you ran the bootstrap script with defaults but want to change the components on the server, you can update the site.pp file to use another role.

If you ran the bootstrap script with -env_type midtier -domain_type prcs but now you want to add an app server, you can add change the role in site.pp from ::pt_role::pt_tools_prcs to ::pt_role::pt_tools_appbatch. Keep in mind, if you change roles in the site.pp file, you’ll want to verify the configuration settings in the psft_customizations.yaml file are correct.

Once you make the change to site.pp, run the command puppet apply site.pp to have Puppet update your server.

This is just the beginning of what the site.pp file can do for us. If you’ve listened to the podcast, you may have heard that I created a custom role for a webapp domain type. In a future post, I’ll document how we did that and how we used the site.pp file to create our web and app servers.

#31 – Change Assistant

This week on the podcast, we share a new trace analyzer tool, a great tip for managing Oracle Client versions, a fun game to learn VIM, and discovering the Oracle Cloud Migration DPK. Then we go in depth on the new features (and bugs) with Change Assistant 8.55.

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

Managing Environment Variables When Using Decoupled Homes

As a reader of this blog or a listener of the podcast, you know I am a user of both Linux and decoupled homes. Traditionally with a Linux PeopleSoft installation you need to source the delivered psconfig.sh to set your environment variables. When an entire environment was contained under its own PS_HOME, you could tweak this psconfig.sh file if customizations were needed without fear of impacting other environments. Now with decoupled homes, the PS_HOME directory will likely be shared, so changing the psconfig.sh file located there is a bad idea.

When switching to decoupled homes, I was looking for a good way to manage sourcing the psconfig.sh file and the different environment variables. While attending Alliance 2015, I saw a presentation given by Eric Bolinger from the University of Colorado. He was talking about their approach to decoupled homes and he had some really good ideas. The approach I currently use is mostly based on these ideas, with a few tweaks. The main difference is that he has a different Linux user account specific to each environment. With this approach, he is able to store the environment specific configuration file in the users home directory and source it at login time. This is similar to the approach Oracle suggests and uses with their PIs(see user psadm2). My organization didn’t go down the road of multiple users to run PeopleSoft. Instead, we have a single user that owns all the environments and we source our environment specific configuration file before we start psadmin. We use a psadmin wrapper script to help with this sourcing(which I will discuss and share in a future post). The main thing to keep in mind is regardless of how these files are sourced, the same basic approach can still be used.

The idea here is to keep as much delivered and common configuration in psconfig.sh as possible and keep environment specific customization in their own separate files. I like to keep these config files in a centralized location, that each server has access to via a NFS mount. I usually refer to this directory as $PSCONFIGS_DIR. What I do is copy the delivered psconfig.sh file to $PSCONFIGS_DIR and rename it psconfig.common.sh. I then remove any configurations that I know I will always want to set in our custom environment specific file, mainly PS_HOME. I then add any needed configuration that I know will be common across all environments (Another approach would be to create a new psconfig.common.sh file from scratch, set a few variables and then just source the delivered file cd $PS_HOME && . psconfig.sh. Either way works, but I like the cloning approach). This common file will be called at the end of every environment specific file. Remember to take care when making any changes to this file, as it will impact any environment calling it. It is also a good idea to review this file when patching or upgrading your tools.

Next for the environment specific files, I create a new file called psconfig.[env].sh. The environment name is listed in its filename. An example would be psconfig.fdev.sh. You could really choose any name for this, but I found this approach to be handy. In this file you will set the environment specific variables as needed, then end with calling psconfig.common.sh. Here is an example file:

This approach allows you to be a little more nimble when patching or upgrading. You can install new homes or middleware, then update the psconfig.[env].sh file and build new domains. When you get to go-live for Production, you can have the domains all built ahead of time. When ready, just update the config file, upgrade the database, and you are good to go!

One final note, regarding directory naming conventions. My organization tends to always have our PS_CFG_HOME directory match the environment or database name exactly, ie. fdev. I’m considering changing this, however. During our last Tools patching project, I found it a little awkward to prebuild the domains and still end up with same directory name. It seems to make much more sense to include the PeopleTools version in the directory name. That way you can prebuild the domains in a new PS_CFG_HOME, and when you go-live just blow the old home away. Another great idea I took away from Eric’s presentation was how to dynamically generate a PS_CFG_HOME directory name:

export PS_CFG_HOME=/opt/pscfg/$ENV-`$PS_HOME/bin/psadmin -v | awk '{print $2}'`

If you use this technique, you will want this to be the last line in your config file – after sourcing the common file. What this does is concatenate your environment name with the PeopleTools version, using the psadmin version command – ie. fdev-8.55.03. This will give you more clarity on what tools version the domains under this PS_CFG_HOME were built with and it will make it easier to prebuild your domains.