Explaining the site.pp File

Dan Iverson

If you have customized any settings with the DPK’s, you have encountered the site.pp file. When you run the bootstrap script, there is a question at the end of the process asking you “Do you want to continue the default initialization process?”. If you answer “No”, the bootstrap script instructs you to make changes, and then run the command puppet apply site.pp. So, what is the site.pp file?

site.pp is a Puppet manifest and is what the DPK (aka Puppet) uses to build your server. A manifest describes what state the server should be after Puppet runs. Our site.pp file contains a role that describes how Puppet should configure the PeopleSoft components. We’ll cover those roles in a bit, but first let’s find out how the site.pp is populated.

Boostrap Parameters

When you run the bootstrap script (psft-dpk-setup), you can pass in a few parameters like env_type and domain_type. These parameters determine what components and software the DPK will install. The env_type parameter takes three options:

• fulltier
• midtier
• dbtier

The fulltier option will install everything needed to run PeopleSoft (Oracle DB, Web, App, Batch). This is the default option and used by the PeopleSoft Images. dbtier will only install the Oracle Database software, and midtier will install software to web/app/batch domains.

If you choose midtier, you can also pass in the additional parameter domain_type. This parameter let’s you narrow down the installation even more. You can choose:

• pia
• appserver
• batch
• appbatch

These options install some of the components rather than all of them.

Last, we can also pass in the deploy_only and deploy_type parameters to the bootstrap script. This option tells the DPK to install the midtier software (WebLogic, Tuxedo, etc) but not configure any domains.

The complete list of parameters can be found in the DPK Guide under the section “Using the PeopleSoft PeopleTools DPK Setup Script.”

Site.pp Roles

So, how do these parameters affect the site.pp file? Each combination of parameter relates to different roles assigned to the site.pp file. Let me explain.

This is a site.pp file after running the bootstrap script with the command psft-dpk-setup -env_type midtier -domain_type prcs:

node default {
  include ::pt_role::pt_tools_prcs
}

The second line is the important one. ::pt_role::pt_tools_prcs tells Puppet to apply the PeopleTools DPK role pt_tool_prcs. These roles are different than PeopleTools security; they are Puppet roles. We can take a look at these roles under the folder c:\programdata\puppetlabs\puppet\etc\modules\pt_role\manifests\.

Under the pt_role\manifests folder, you’ll see a long list of files. Each file is a Puppet role, and each role ties back to the parameters in the bootstrap script.

If we open the file pt_tools_prcs.pp, we can see what actions are taken by Puppet.

if $ensure == present {
    contain ::pt_profile::pt_tools_preboot_config
    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_prcs'] ->
    Class['::pt_profile::pt_tools_preboot_config'] ->
    Class['::pt_profile::pt_domain_boot']
  }

• pt_system makes some OS level changes for Linux
• pt_tools_deployment deploys all the PeopleTools components
• pt_psft_environment sets up PS_CFG_HOME, PS_APP_HOME and PS_CUST_HOME folders, and user information on Linux
• pt_prcs configures a process scheduler domain
• pt_tools_preboot_config runs the ACM app engine
• pt_domain_boot will start the configured domains

Let’s compare this file to pt_hcm_pum.pp. This file is used by the HCM PeopleSoft Images:

  if $ensure == present {
    Class['::pt_profile::pt_system'] ->
    Class['::pt_profile::pt_app_deployment'] ->
    Class['::pt_profile::pt_tools_deployment'] ->
    Class['::pt_profile::pt_oracleserver'] ->
    Class['::pt_profile::pt_psft_environment'] ->
    Class['::pt_profile::pt_psft_db'] ->
    Class['::pt_profile::pt_appserver'] ->
    Class['::pt_profile::pt_prcs'] ->
    Class['::pt_profile::pt_pia'] ->
    Class['::pt_profile::pt_samba'] ->
    Class['::pt_profile::pt_tools_preboot_config'] ->
    Class['::pt_profile::pt_domain_boot'] ->
    Class['::pt_profile::pt_tools_postboot_config'] ->
    Class['::pt_profile::pt_source_details'] ->
    Class['::pt_profile::pt_opa']
  }

There are many more actions in this file, which explains why setting up a PeopleSoft Image configures everything.

Changing Roles

What can we do with the site.pp file? Quite a bit, actually. If you ran the bootstrap script with defaults but want to change the components on the server, you can update the site.pp file to use another role.

If you ran the bootstrap script with -env_type midtier -domain_type prcs but now you want to add an app server, you can add change the role in site.pp from ::pt_role::pt_tools_prcs to ::pt_role::pt_tools_appbatch. Keep in mind, if you change roles in the site.pp file, you’ll want to verify the configuration settings in the psft_customizations.yaml file are correct.

Once you make the change to site.pp, run the command puppet apply site.pp to have Puppet update your server.

This is just the beginning of what the site.pp file can do for us. If you’ve listened to the podcast, you may have heard that I created a custom role for a webapp domain type. In a future post, I’ll document how we did that and how we used the site.pp file to create our web and app servers.

Note: This was originally posted by Dan Iverson and has been transferred from a previous platform. There may be missing comments, style issues, and possibly broken links. If you have questions or comments, please contact [email protected].