wls opatch

Overview

This resource allows you to manage opatch patches on a specific middleware home.

wls_opatch {‘/opt/oracle/middleware12c:16175470’: ensure => “present”, jdk_home_dir => “/usr/java/jdk1.7.0_45”, os_user => “oracle”, source => “/vagrant/p16175470_121200_Generic.zip”, }

Attributes

disable_corrective_change

Disable the modification of a resource when Puppet decides it is a corrective change.

(requires easy_type V2.11.0 or higher)

When using a Puppet Server, Puppet knows about adaptive and corrective changes. A corrective change is when Puppet notices that the resource has changed, but the catalog has not changed. This can occur for example, when a user, by accident or willingly, changed something on the system that Puppet is managing. The normal Puppet process then repairs this and puts the resource back in the state as defined in the catalog. This process is precisely what you want most of the time, but not always. This can sometimes also occur when a hardware or network error occurs. Then Puppet cannot correctly determine the current state of the system and thinks the resource is changed, while in fact, it is not. Letting Puppet recreate remove or change the resource in these cases, is NOT wat you want.

Using the disable_corrective_change parameter, you can disable corrective changes on the current resource.

Here is an example of this:

crucial_resource {'be_carefull':
  ...
  disable_corrective_change => true,
  ...
}

When a corrective ensure does happen on the resource Puppet will not modify the resource and signal an error:

    Error: Corrective change present requested by catalog, but disabled by parameter disable_corrective_change
    Error: /Stage[main]/Main/Crucial_resource[be_carefull]/parameter: change from '10' to '20' failed: Corrective change present requested by catalog, but disabled by parameter disable_corrective_change. (corrective)

Back to overview of wls_opatch

disable_corrective_ensure

Disable the creation or removal of a resource when Puppet decides is a corrective change.

(requires easy_type V2.11.0 or higher)

When using a Puppet Server, Puppet knows about adaptive and corrective changes. A corrective change is when Puppet notices that the resource has changed, but the catalog has not changed. This can occur for example, when a user, by accident or willingly, changed something on the system that Puppet is managing. The normal Puppet process then repairs this and puts the resource back in the state as defined in the catalog. This process is precisely what you want most of the time, but not always. This can sometimes also occur when a hardware or network error occurs. Then Puppet cannot correctly determine the current state of the system and thinks the resource is changed, while in fact, it is not. Letting Puppet recreate remove or change the resource in these cases, is NOT wat you want.

Using the disable_corrective_ensure parameter, you can disable corrective ensure present or ensure absent actions on the current resource.

Here is an example of this:

crucial_resource {'be_carefull':
  ensure                    => 'present',
  ...
  disable_corrective_ensure => true,
  ...
}

When a corrective ensure does happen on the resource Puppet will not create or remove the resource and signal an error:

    Error: Corrective ensure present requested by catalog, but disabled by parameter disable_corrective_ensure.
    Error: /Stage[main]/Main/Crucial_resource[be_carefull]/ensure: change from 'absent' to 'present' failed: Corrective ensure present requested by catalog, but disabled by parameter disable_corrective_ensure. (corrective)

Back to overview of wls_opatch

ensure

The basic property that the resource should be in.

Valid values are present, absent.

Back to overview of wls_opatch

force_remove

Even if puppet “thinks” the patches are not installed, still use opatch to remove them. This parameter is ONLY used when applying a patch and not used when removing a patch.

Valid values are true, false.

Back to overview of wls_opatch

jdk_home_dir

The JDK home folder.

Back to overview of wls_opatch

logoutput

Whether to log command output in addition to logging the exit code. Defaults to on_failure, which only logs the output when the command has an exit code that does not match any value specified by the returns attribute. As with any resource type, the log level can be controlled with the loglevel metaparameter.”

Valid values are true, false, on_failure.

Back to overview of wls_opatch

name

The name.

Back to overview of wls_opatch

oracle_product_home_dir

The oracle product home folder.

Back to overview of wls_opatch

orainst_dir

The orainst folder.

Back to overview of wls_opatch

os_user

The weblogic operating system user.

Back to overview of wls_opatch

patch_id

The patchId of the OPatch.

Back to overview of wls_opatch

patch_type

The type of patch. Can be either single or sbp.

Recenly Oracle has started to distribute the PSU as spb patches. Opatch zip files contain one patch most of the times. While spb patches contain a set of patches.

With this parameter, you tell wls_opatch what kind of zip file it is.

When you specify spb as type, you also need to specify the sub_patches parameter to tell opatch which of the patches in the zip file you want Opatch to look for and ensure.

Back to overview of wls_opatch

provider

The specific backend to use for this wls_opatch resource. You will seldom need to specify this — Puppet will usually discover the appropriate provider for your platform.Available providers are:

prefetching

Apply Oracle OPatches

Back to overview of wls_opatch

remove_patches_before

Sepcify which patches to remove before applying the patch-id.

Here is an example on how to use this:

wls_opatch { '/oracle/home:12344:
  ensure                => 'present',
  remove_patches_before => ['23345', '45678']
}

This parameter is ONLY used when applying a patch and not used when removing a patch.

Back to overview of wls_opatch

source

A source directory, but can also contain a zip or a tar file.

This parameter can contain the following types of values:

• puppet: URIs, which point to files in modules or Puppet file server mount points.
• Fully qualified paths to locally available files (including files on NFS shares or Windows mapped drives).
• file: URIs, which behave the same as local file paths.
• http: URIs, which point to files served by common web servers

The normal form of a puppet: URI is:

puppet:///modules/<MODULE NAME>/<FILE PATH>

This will fetch a file from a module on the Puppet master (or from a local module when using Puppet apply). Given a modulepath of /etc/puppetlabs/code/modules, the example above would resolve to /etc/puppetlabs/code/modules/<MODULE NAME>/files/<FILE PATH>.

Container file

When the file is a container file, it will automaticaly be extracted. At this point in time the follwoing container types are supported:

• zip
• tar

Compressed files

When the file is compressed, it will be uncompressed before beeing procesed further. This means that for example a file https://www.puppet.com/files/all.tar.gz will be uncompressed before being unpackes with tar

Examples

Here are some examples:

Regular directories

... { '...':
  ...
  source  => '/home/software',
  ...
}

The /home/software will be used by the custom type. Other Puppet code must make sure the directory contains the right files.

A puppet url containing a zip file

... { '...':
  ...
  source  => 'puppet:///modules/software/software.zip',
  tmp_dir => '/tmp/mysoftware'
  ...
}

The software.zip file will be fetched from the puppet server software module and put in /tmp/mysoftware, it will be unzipped and used for the actions in the custom type. The file will be temporary put in

A http url containing a tar file

... { '...':
  ...
  source  => 'http:///www.enterprisemodules.com/software/software.tar',
  tmp_dir => '/tmp/mysoftware'
  ...
}

The software.tar file will be fetched from the named web server and put in /tmp/mysoftware, it will be untarred and used for the actions in the custom type.

A file url containing a compressed tar file

... { '...':
  ...
  source  => 'file:///nfsshare/software/software.tar.Z',
  tmp_dir => '/tmp/mysoftware'
  ...
}

The software.tar.Z file will be fetched from the named directory, it will be uncompressed and then untarred on and put in /tmp/mysoftware and used for the actions in the custom type.

Back to overview of wls_opatch

sub_patches

The individual patches contained in the spb patch file that you want to apply to the system.

Back to overview of wls_opatch

tmp_dir

The tmp extract directory of the patch.

Back to overview of wls_opatch