This week on the podcast, Kyle finds that Cloud Manager removed a feature and Dan discusses some architectural designs for Integration Broker.
The first set of psadmin.conf videos are available! The first batch of videos are focuses on automation for PeopleSoft Administration. Charlie Sinks talks about using Rundeck with PeopleSoft and Peyton Colburn shares how he expanded Hiera beyond psft_customizations.yaml.
We have released the videos as a free course so you can find the videos in one place. Head over to the psadmin.io courses page and sign up.
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.
This week on the podcast, Kyle recaps his successful HR 9.2 go-live and shares a few lessons learned. Dan and Kyle talk about encrypting password in YAML files, conditional navigation and PeopleTools CPU patches. Dan finishes the podcast by sharing his story about a spontaneous stress test.
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.
SET ENABLED_DATATYPE 9.2;
Since the DPK was released, there has a been a bug (for Windows) that is quite annoying. In the psft_customizations.yaml file, the feature_settings: section is supposed to turn Tuxedo domain features on or off.
feature_settings:
PUBSUB: "Yes"
QUICKSRV: "No"
QUERYSRV: "Yes"
JOLT: "Yes"
On Windows, these settings were ignored and the default values were used when a domain was created or reconfigured. Thanks to Dale Haman from the psadmin.io Community, we have a fix for the bug. The issue is this:
The DPK (Puppet) takes the feature_settings: section in the psft_customizations.yaml file and combines it into a string. The string is passed into psadmin with the -u parameter. The code that creates this string used an incorrect separator for each feature, so psadmin would ignore the entire string.
To fix this, you can edit one file under the puppet/etc/modules folder:
puppet/etc/modules/pt_config/lib/puppet/provider/psftdomain.rbif Facter.value(:osfamily) == 'windows'
# feature_settings_separator = '#'
# For Windows, we need to use the slash
feature_settings_separator = '/'
else
feature_settings_separator = '%'
end
If you re-run puppet apply .\site.pp, your app server and process scheduler domains features should match what you defined in psft_customizations.yaml.
After testing this on a process scheduler, I noticed my scheduler had 5 features listed in psadmin but only two were configured in my psft_customizations.yaml file: MSTRSRV and APPENG. I wanted to configure the other features in the domain, so I added them to my psft_customizations.yaml file:
feature_settings:
MSTRSRV: "Yes"
APPENG: "No"
PPM: "No"
DOMAIN_GW: "No"
SERVER_EVENTS: "No"
If you run puppet apply .\site.pp with these parameters in your psft_customizations.yaml file, you’ll get an error saying the Feature List is not valid. The feature_settings: section is compared to an array in the Process Scheduler Puppet Type to make sure you don’t mis-type anything, or try to add a non-existent feature. But in this case, the validation array was incorrect. It was missing the "PPM" feature.
puppet/etc/modules/pt_config/lib/puppet/type/pt_prcs_domain.rbprcs_features =
# [ "MSTRSRV", "APPENG", "KIOSK", "DOMAIN_GW", "SERVER_EVENTS" ]
# Add PPM because it is a scheduler feature...KIOSK is not.
[ "MSTRSRV", "APPENG", "PPM", "DOMAIN_GW", "SERVER_EVENTS"]
Comment out the bad line and change "KIOSK" to "PPM" in the array. Now, you can configure all 5 process scheduler features from the psft_customizations.yaml file.
Check out the other bug fixes for the DPK too:
A comment on the Build Images with DPK post had a great question. Instead of answering it there, I wanted to share the solution as a post so more people would see it. The question deals with enabling (or disabling) features on the app server using the DPK. With the current PI’s based on PeopleTools 8.55.01, you can change app server configuration when you create the PI’s using the DPK.
If you have already built the PI’s, the 8.55.01 DPK doesn’t handle changes to the current configuration well.
To enable the WSL and Debugger when you build a DPK:
psft-dpk-setup script.No to the “Do you want to continue with the default initialization” question.psft_customizations.yaml in the folder C:\ProgramData\PuppetLabs\Puppet\etc\data or /etc/puppet/datapsft_customizations.yaml file (notice the lines WSL: "Yes" and DBGSRV: "Yes" are different) c:\programdata\puppetlabs\puppet\etc\manifests or /etc/puppet/manifests. puppet apply site.ppIf you have already build the PI, you can do in manually through psadmin, but that’s no fun 😉 In PeopleTools 8.55.03, the DPK (Puppet modules) is better at handling configuration changes in the psft_customizations.yaml file. I’d guess the next PI’s will be based .04 (or higher), so this should be able to make the change after you built the PeopleSoft Image.
Update: If you want to learn more about the DPK, check out our new PeopleSoft DPK QuickStart course. This free course will introduce you to the DPK, show you how to use the DPK with PeopleSoft Images, and show you how to customize the DPK for your servers.