Prevent WebLogic Install with prcs and app-only DPK Deployments

Dan Iverson

In this post, I introduced the site.pp file and how that relates to the DPK. I used the example of deploying a process scheduler with the DPK by using the bootstrap command psft-dkp-setup -env_type -domain_type prcs. This command will populate the site.pp file with the role ::pt_role::pt_tools_prcs.

For the most part, this works well. The DPK/Puppet will install Tuxedo, Java, Oracle Client, WebLogic and create your process scheduler domain. But there is one problem – we don’t need (or want) WebLogic on our process scheduler! Why does the DPK do this? The base profile that applies to all DPK server builds includes WebLogic and doesn’t check to see what type of install is happening.

Finding the WebLogic Deployment Manifest

Open the file for the role pt_tools_prcs. The file is under c:\programdata\puppetlabs\puppet\etc\modules\pt_role\manifests\ and named pt_tools_prcs.pp. This Puppet manifest lists the profiles that will be applied when creating a process scheduer.

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']

Each of these classes tied back to file under modules\pt_profile. The class that handles WebLogic and Tuxedo deployment is pt_tools_deployment. The pt_tools_deployment.pp manifest takes the configuration values from deployment.yaml (or psft_customizations.yaml if you overrode the defaults) and prepares the class pt_setup:tools_deployment.

In the file tools_deployment.pp under pt_setup\manifests\, you’ll see the base deployment configuration for any DPK installation. This file will install the software for a DPK run. Even if you aren’t familiar with Puppet (this file is a Puppet manfiest), you can read the file and get an idea of what’s happening.

The important section is roughly half way down and looks like this:

  pt_deploy_weblogic { $weblogic_tag:
    ensure                    => $present,
    deploy_user               => $tools_install_user,
    deploy_user_group         => $tools_install_group,
    archive_file              => $weblogic_archive_file,
    deploy_location           => $weblogic_location,
    oracle_inventory_location => $inventory_location,
    oracle_inventory_user     => $oracle_install_user,
    oracle_inventory_group    => $oracle_install_group,
    jdk_location              => $jdk_location,
    redeploy                  => $redeploy,
    remove                    => $weblogic_remove,
  }

Modifying the Manifest

In Puppet, the ensure variable will takes two options:

• present – think of this as “install” (that isn’t technically accurate, but at a high level that’s what it means for the DPK)
• absent – this value would uninstall WebLogic

In this manifest, there aren’t checks for each software package. Everything is installed, or everything is uninstalled. The simple fix is to update the ensure value to absent for WebLogic.

  pt_deploy_weblogic { $weblogic_tag:
    ensure                    => absent,
    deploy_user               => $tools_install_user,
    deploy_user_group         => $tools_install_group,
    archive_file              => $weblogic_archive_file,
    deploy_location           => $weblogic_location,
    oracle_inventory_location => $inventory_location,
    oracle_inventory_user     => $oracle_install_user,
    oracle_inventory_group    => $oracle_install_group,
    jdk_location              => $jdk_location,
    redeploy                  => $redeploy,
    remove                    => $weblogic_remove,
  }

After making this change, you can run puppet apply site.pp. If you are on working on a blank server, the DPK won’t install WebLogic. If WebLogic is installed, the DPK will uninstall WebLogic.

One big disclaimer, this is not supported by Oracle. So, make these changes knowing that Oracle won’t help you if you run into any issues. For my own experience, we made this change before deploying our process scheduler servers and it has worked well. But, that’s only my experience.

A better way to handle this fix would be to read in the domain_type setting from the defaults.yaml file.

Here is what that change would look like:

  if hiera('domain_type') == 'all' or hiera('domain_type') == 'pia' {
    $wl_ensure = 'present'
  } 
  else {
    $wl_ensure = 'absent'
  }
  pt_deploy_weblogic { $weblogic_tag:
    ensure                    => $wl_ensure,
    deploy_user               => $tools_install_user,
    deploy_user_group         => $tools_install_group,
    archive_file              => $weblogic_archive_file,
    deploy_location           => $weblogic_location,
    oracle_inventory_location => $inventory_location,
    oracle_inventory_user     => $oracle_install_user,
    oracle_inventory_group    => $oracle_install_group,
    jdk_location              => $jdk_location,
    redeploy                  => $redeploy,
    remove                    => $weblogic_remove,
  }

A quick lookup to the defaults.yaml file’s domain_type will tell us what type of installation was requested from the bootstrap script.

Closing Thoughts

This bug is annoying. But, one thing I really enjoy with the DPK (and Puppet), is that we have access to the code. That means we can research how the DPK is working and make changes are possible (if technically unsupported). But, we also have Puppet installed our servers and we can leverage it for our own modules. Coming up in future posts, I’ll be documenting some of the custom modules I’ve been writing to extend Puppet for our own use.

I have an SR open on this bug too, so if I get feedback I’ll update this post.

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].