This week on the podcast, Dan and Kyle talk about Tuxedo blocking IP addresses, the Kibana Dashboard and building custom visualizations, and Dan talks about using mitmproxy to troubleshoot integration errors.
This week on the podcast, Kyle shares how the Navigator knows your last folder location and a bug with it and Dan discusses the TM_CPAU setting for Tuxedo on Windows. Then Dan and Kyle talk about cloud-init.
This week on the podcast, Dan shares some tips on monitoring Tuxedo domains and Kyle discusses how to secure portal registries when accesses externally.
- Data Mover Follow-up @ 3:00
- PeopleTools POC Business Case Document @ 5:45
- Tuxedo Service Monitoring @ 7:30
- Limiting Access to Portal Registries @ 17:45
- Role Flipping
- Separate Registry and Obscurity
- LB/RPS/WL Filter Security
- VPN Access
- Conditional Navigation
This week on the podcast, Kyle and Dan discuss memory usage in PSAPPSRV with the JVM, how to work with network resources and Tuxedo, and Dan shares an “Adventures in MOS” about “huge” customizations.
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
if 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
Process Scheduler Features
After testing this on a process scheduler, I noticed my scheduler had 5 features listed in
psadmin but only two were configured in my
APPENG. I wanted to configure the other features in the domain, so I added them to my
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
prcs_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
"PPM" in the array. Now, you can configure all 5 process scheduler features from the
Check out the other bug fixes for the DPK too:
The other day we had an app server that stopped responding to requests after it restarted. The domain was running, but our web server wasn’t able to talk to the app server. When we attempted to log in, we received the
CHECK APPSERVER LOGS. THE SITE BOOTED WITH INTERNAL DEFAULT SETTINGS, BECAUSE OF: bea.jolt.ServiceException: Invalid Session error.
You can get this from a few errors:
- The Domain Connect Password doesn’t match.
- The Web Profile user or password is wrong (or locked).
- The app server domain is actually down.
But, none of these applied to us. We knew the domain was up, we hadn’t changed the Domain Connect Password, and the Web Profile user account was correct. I then ran a
netstat -an command to make sure I could see the ports where listening. That’s when I found that our app server was listening on the wrong IP address.
In our environment, we have our regular IP addresses for the network, but our VM’s have a management network on a different IP range. The app server had booted up and was listening on the management network IP. I opened up the
psappsrv.cfg file and the
WSL listening IP’s were using the
%PS_MACH% variable will grab the first network card’s IP address on the machine. With Windows, that’s not a consistent way to get the IP address if you have more than one netword card.
The fix is to assign an IP address to the
WSL processes in the
psappsrv.cfg file. You can assign a specific IP address using:
When assigning an IP address you have two options:
- Listen to a specific IP address
- Listen to all IP addresses
If you want to listen on all IP addresses, use
0.0.0.0 for the listening address value.
You may not want to do this if you have more than one network card on the machine. Often, the second (or more) network cards are for different networks that specific uses. In our case, the second network card was for VM management and I don’t want our app server accepting any connections from that network segment. Our network traffic should be limited to our internal PeopleSoft network segment. To do specify an IP, list the specific IP address you want your app server to listen on in the
When using the command line to rebuild a Tuxedo domain, there is a new flag to keep your settings:
–keepfeaturesswitch in the following command was introduced in PeopleTools 8.54.
psadmin –c import [PS_CFG_HOME] –d [old domain name] –n [new domain name] -keepfeatures
This came from the Best Practices guide for Mid-tier Deployment White Paper. At the end of the document, there is a good overview for the steps needed with a PeopleTools upgrade and the commands to help you script the upgrade.