
This week on the podcast, Kyle shares an idea for a drop zone in Cloud Manager, and then he and Dan discuss the AutoMgrLock feature in the application server.
This week on the podcast, Kyle shares an idea for a drop zone in Cloud Manager, and then he and Dan discuss the AutoMgrLock feature in the application server.
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.
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.
Thanks to Graham Smith and Javier Delgado for their write-ups and everyone on Twitter who kept us up-to-date.
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.
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.
There are six styles in the project. The colors (except the purple theme) are based on the Bootstrap default theme.
Use the colors however you want, but the list below is how I’m using the colors:
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.
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.
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
).
Run the updateSystemBranding.sql
script to update the Branding System Options and insert the IO_LOGO
and IO_HDR_BLUE
stylesheets.
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.
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.
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');
To change the header colors, change the Additional Stylesheet on the “PeopleTools > Portal > Branding > Branding System Options” page.
There are two ways you can replace the logo with your own:
IO_LOGO
file under “PeopleTools > Portal > Branding > Branding Objects > Images”IO_LOGO
reference in the IO_LOGO
css file.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.
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.
E-xxx
for searchingFor 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:
$DPK_INSTALL/setup/psft-dpk-setup.log
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
.
grep "is needed by" psft-dpk-setup.log | awk '{print $1;}' >> os-packages.list
vi os-packages.list
sudo yum install $(cat os-packages.list)
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.
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.
cd /D
to change directory with a path @ 1:00curdir.bat
@ 11:45psconfig.sh
in newer PeopleTools versions @ 13:30
psft_patches.yaml
in 8.55.06 @ 26:45c:\temp
or Desktop
? @ 42:00In 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.
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.
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.