This week on the podcast, Kyle and Dan share follow-up Tuxedo and Windows, discuss the difference between service accounts on Linux and Windows, and the PeopleTools release schedule.
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.
PS_HOME/utilities/psautolog.sh 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 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:
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:
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 JSL and WSL listening IP’s were using the %PS_MACH% variable.
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 JSL and WSL processes in the psappsrv.cfg file. You can assign a specific IP address using:
Address=//x.x.x.x
When assigning an IP address you have two options:
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 Address=// line.
When using the command line to rebuild a Tuxedo domain, there is a new flag to keep your settings:
The
–keepfeaturesswitch in the following command was introduced in PeopleTools 8.54.
For example:
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.