Using Security Deployment with Custom Security

In recent PeopleSoft Image updates, a new tool for implementing security changes was introduced. The Security Deployment tool simplifies the application of new security changes to your environment. But, the Security Deployment tool can be used to automate the application of custom security to your environments.

In the video below, I cover how to use the Security Deployment for migrating custom security changes.

 

#47 – Oracle OpenWorld 2016

This week on the podcast, Kyle and Dan talk about announcements from Oracle Open World. We hit the highlights for PeopleSoft Administrators and grade our predictions from last week. Dan also shares why Windows 95 was connecting to PeopleTools 8.55 environments.

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

  • Windows 95 Users? @ 1:15
  • Elasticsearch/Kibana Graphs @ 6:00
  • psadmin Hidden Menu Follow-up @ 11:45
  • 8.56 Release Date @ 13:30
    • After recording the episode, we clarified that the PeopleTools 8.56 release date was not announced.
  • Classic Plus @ 16:30
  • Classic UI Support @ 21:15
  • Page Composer @ 28:00
  • Elasticsearch Updates @ 30:30
  • Re-delivering Mobile Expenses Module in Fluid @ 36:15
  • Oracle Cloud Manager @ 38:45
  • Oracle Cloud on Premise @ 39:30
  • Oracle Community Ideas @ 42:30
  • Grading Our OOW Predictions @ 44:00

Thanks to Graham Smith and Javier Delgado for their write-ups and everyone on Twitter who kept us up-to-date.

#45 – Go-Live Weekends

This week Dan talks about his 8.55 Go-Live weekend, simplifying patch download with getMOSPatch, and using Kyle’s Maintenance Backdoor. Then Kyle and Dan discuss strategies and tips to make Go-Live weekends successful.

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

psadmin.io Stylesheets for 8.54 and 8.55

I’m happy to release a set of stylesheets for PeopleTools 8.55 for everyone to use. The stylesheets are based on the TANGERINE theme (8.53 look and feel), so they won’t work with Fluid pages. For people who are using the Classic look, these stylesheets are a great way to ensure your users know which environment they are using.

I’ve used stylesheets for pre-8.50 environments from Duncan Davies in the past and built custom stylesheets for 8.53. But with the Branding Framework in 8.54 and 8.55, using custom styles are even easier. Thanks to Sasank Vemana for his great posts on using the Branding Framework as well. I used his posts to build these stylesheets.

Colors

There are six styles in the project. The colors (except the purple theme) are based on the Bootstrap default theme.

Green

Green Header

Light Blue

Light Blue Header

Purple

Purple Header

Red

Red Header

Grey

Grey Stylesheet

Yellow

Yellow Header

Environments

Use the colors however you want, but the list below is how I’m using the colors:

  • DEV1 – Green
  • DEV2 – Light Blue
  • DEV3 – Purple
  • TST – Red
  • QA/UAT – Grey
  • SBX (Sandbox and Nightly Refresh) – Yellow

Load Stylesheets and Branding Data

You can apply the stylesheets three ways: manually load the project with App Designer and Data Mover, apply a change package with Change Assistant, or follow Sasank’s post and use the stylesheets from the GitHub repository.

App Designer

Download the change package, updIO_STYLES_855.zip, from the GitHub repository. Extract the updIO_STYLES_855.zip file to get the project and scripts. In App Designer, copy the project IO_STYLES_855 from the change package folder into the target database.

CopyProject

Import the ptbr_io_theme.dat file using Data Mover and the script ptbr_theme_io_imp.dms (under updIO_STYLES_855\updIO_STYLES_855_batch\filereferences\scripts).

DataMoverCopy

Run the updateSystemBranding.sql script to update the Branding System Options and insert the IO_LOGO and IO_HDR_BLUE stylesheets.

UpdateSystemBranding

Change Package

Download the change package, updIO_STYLES_855.zip, from the GitHub repository. Apply the change package against any environment where you want to use the stylesheets. (You’ll need to use the “Apply Updates” mode in newer Change Assistant versions). The change package will import the IO_STYLES_855 project, import the Branding Framework theme data, and update System Branding Options.

Refreshes

If you want to use the styles in your non-production environments, you can import the project and Branding Framework setup and theme data into your production database. Skip the SQL script to update the System Branding Options. Add the SQL commands from the Change Package script updateSystemBranding.sql into your refresh scripts.

8.55 Homepage

After you load the project and run the scripts, Classic pages will show up with the new stylesheest. If you are on 8.55 and want to use the Classic homepage, you’ll need to run the SQL below:

update psuseroptndefn set user_option_value = 'C' where optn_category_lvl = 'PPTL' and useroptn in ('HPPC', 'HPTABLET');

Header Color

To change the header colors, change the Additional Stylesheet on the “PeopleTools > Portal > Branding > Branding System Options” page.

Change Header Color

Logo

There are two ways you can replace the logo with your own:

  1. Replace the IO_LOGO file under “PeopleTools > Portal > Branding > Branding Objects > Images”
  2. Upload your logo as a new image and replace the IO_LOGO reference in the IO_LOGO css file.

Contribute

I have created a GitHub project with the styleets used in the project. If you want to add any changes or suggest improvments, please send them in or contribute to the GitHub repository.

#37 – The REN Server

This week, Dan and Kyle talk about Event Mapping, Report Node Validation, search App Packages, and the REN server.

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

Linux DPK: Dealing with Missing Required OS Packages

For those of you using the NativeOS Linux install for Update Images, you have probably come across this scenario. You start the DPK install and once you get to the Puppet installation section, the script comes to an abrupt end. What the heck! Looking in the log file, you quickly figure out your OS is missing some required packages. So now what?

In the PeopleSoft Deployment Packages for Update Images Installation document, task 2-3-3 walks you through how to get the required OS packages needed for Puppet. They make it clear that it is your job to obtain these packages and install them – you’re on your own. They then list a few steps on how to accomplish this. The steps pretty much come down to this:

  1. Install DPK
  2. DPK will fail on missing packages
  3. Find missing OS packages by reviewing the log
    • $DPK_INSTALL/setup/psft-dpk-setup.log
  4. Run DPK cleanup
  5. Install missing OS packages
  6. Install DPK again

Following the steps is pretty straight forward, but I don’t like having to manually dig through a log file and pick out the missing OS Packages. So, what I did is write a little shell script to extract them for me. This script will generate the list of missing OS packages and write it to a file. After reviewing the list, you can then use this file for installing the packages.

Here are the steps I follow to ensure I have all the needed OS packages when installing NativeOS Linux DPKs. These steps assume your current directory is $DPK_INSTALL/setup.

  1. Install DPK
  2. DPK will fail on missing packages
  3. Generate missing packages list
    • grep "is needed by" psft-dpk-setup.log | awk '{print $1;}' >> os-packages.list
  4. Run DPK cleanup
  5. Review list, edit if needed
    • vi os-packages.list
  6. Install missing OS packages
    • sudo yum install $(cat os-packages.list)
  7. Install DPK again

Unfortunately, you may have to repeat this process a few times to identify all the missing packages. Once I have gotten through a DPK install on a particular OS, I save off the os-packages.list file for safe keeping. I then make sure I install this list of packages to any new VM that I am doing a fresh DPK install on. Doing this before DPK installs will ensure we don’t see any missing OS package errors. I’m sure this list will need to be updated as time goes on and we see different versions of Puppet, etc in our DPKs.

Hopefully you found this post helpful! This little tidbit was pulled out of the PeopleSoft Deployment Package QuickStart course. Feel free to enroll in this FREE course today for more DPK goodness.

os-packages

#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.