Patching requires a full understanding of several concepts, and this section describes three Fusion Applications patching concepts
Oracle Fusion Applications is updated by the following patching frameworks:
Technical patches are geared toward delivering new or fixing existing technical capabilities in the underlying Fusion Middleware components that Fusion Applications is built on, as described in the following table:
Table 2-1 Types of Oracle Fusion Applications Technical Patches
Patch Type | Description | Frequency |
---|---|---|
One-Off Patch |
Contain a single bug fix |
As needed for critical fixes |
Critical Patch Updates (CPUs) |
Address security vulnerabilities |
On the Tuesday closest to the 17th day of January, April, July, and October |
Patch Bundle (P4FA) |
Collection of tech stack fixes (bundles or one-offs) for Fusion Applications customers |
Monthly |
Functional patches deliver new functional features or fix existing functional capabilities within Fusion Applications. Functional patches are delivered in three formats and all are applied using Patch Manager, as described in the following table:
Table 2-2 Types of Oracle Fusion Applications Functional Patches
Patch Type | Description | Frequency |
---|---|---|
Functional Patch Bundles |
Collection of one-off patches for a product family, which are cumulative and distributed for a specific baseline release. They include previously released Aggregated One-Off Patches (AOOs) and One-Off Patches |
Monthly |
Aggregated One-Off Patches (AOO) |
Collection of One-Off Patches for a product family |
Weekly, but not all product families release AOOs weekly |
Functional One-Off Patches |
Contain a single bug fix |
As needed for critical fixes |
The primary purpose of the Oracle Identity Management patching framework for Oracle Fusion Applications is to simplify and expedite the maintenance of the code and functionality shipped as part of Oracle Identity Management for the Oracle Fusion Applications suite of products.
The FUSION_env.properties
file is populated in the admin directory with complete environment setup information required by the patching framework. This is the source of information that patching framework utilities use when setting up the environment.
The patching framework configuration scripts are created to set the environment and call utilities. For example, it creates the fapmgr.sh
script, which sets up the environment and then calls Oracle Fusion Applications Patch Manager (Patch Manager) when applying the patch.
The primary function of Oracle Fusion Applications Patch Manager (Patch Manager) is to apply Functional Patches. It also validates whether patches can be applied and generates patching reports. Patch Manager supports parallel processing of non-dependent tasks, thereby improving the performance during patch application.
Patch Manager provides a command-line interface to coordinate its patching functions. A single patch may include changes to both Oracle Fusion Middleware and database artifacts, and these Oracle Fusion Middleware artifacts may be deployed to Managed Servers running on different nodes. The artifacts are updated in the Oracle Fusion Applications Oracle home that is shared by the different nodes. To patch both types of artifacts, two patching tools are called by Patch Manager to manage the actions involved: OPatch for the Oracle Fusion Middleware artifacts and Oracle Fusion Applications AutoPatch (AutoPatch) for artifacts associated with the database.
The same set of patching-related software and database tables is used by both Patch Manager and Oracle Fusion Middleware Extensions for Applications (Applications Core). Patch Manager and Applications Core each reside in their own separate Oracle home and use their specific shell scripts to support their product-specific patching requirements. These scripts are uniquely defined to reference the appropriate Oracle home, set the patching configuration and environment, and then call the AutoPatch utility for database patching.
WARNING: There can be only one patching session active for Oracle Fusion Applications or Applications Core at a time.
For detailed information about how to run Patch Manager, see the Patch Manager Command Reference section.
Table 2-3 Effect of Oracle Fusion Applications Patching Modes
Patching Mode | Online | Offline | Hot Patch |
---|---|---|---|
Users |
No Access |
No Access |
Active |
Servers Bounced |
Automatically |
Manually |
No Bounce |
Artifacts Deployed |
Automatically |
Manually |
Automatically |
Database Use |
Idle |
Idle |
Active |
MANDATORY: To apply any patch in online mode, the Administration Servers must be running.
Before applying the patch, review which servers will be impacted by the patch. For more information, see the Online Patch Progress Report and Diagnostics Report section.
In online mode, Patch Manager automates the post-apply steps, such as shutting down and starting the impacted Managed Servers, and deploying supported Oracle Fusion Middleware artifacts, such as SOA composites, Oracle Business Intelligence Publisher (Oracle BIP) artifacts, and Flexfields. When patching in online mode, Patch Manager provides messages about the steps to take after the patch is applied, to resolve any failures that occurred during the post-apply tasks. For more information, see the Oracle Fusion Applications Patch Manager Middleware Artifact Support section.
To enable online patching mode, specify the online
option and the stoponerror
option when running Patch Manager. Patch Manager determines which domains the patch affects by referencing the taxonomy URL, either by an environment setting or by using the taxonomyurl
option. For more information, see the Taxonomy URL section.
In online mode, only those impacted servers that are running are stopped and started. No stop or start operations are performed on those servers that are not in a running state even if the patch impacts an application that is deployed on this server.
In offline mode, server management is performed manually.
OPTIONAL: Before applying the patch, the Patch Impact report can be run to see which servers will be impacted by the patch.
In offline mode, all applications are unavailable to users, but only the servers impacted by the patch are shut down. The net effect is that the system is unavailable, but the system downtime is minimized if only certain servers are shut down and then started.
MANDATORY: All servers impacted by the patch must be shut down before applying patches in offline mode, and when applying a patch in offline mode, manually start and stop the impacted Managed Servers and manually deploy certain Oracle Fusion Middleware artifacts, such as SOA composites, Oracle BI Publisher artifacts, and Flexfields, after the patch applies.
OPTIONAL: To minimize downtime, servers can remain running during patching. The impacted server stop and start can occur after the patching session ends.
For information about deploying patch artifacts manually when applying a patch in offline mode, refer to the Manual Patching of Oracle Fusion Applications During Offline Patching section.
Hot patching mode allows a patch to be applied in online mode concurrent with active users and transactions. Hot patching is supported for only database, JEE, BIP, MAA (Mobile Artifact), SOA, and C artifacts.
MANDATORY: The patch must be enabled for hot patching.
During hot patching, an application is updated by deploying a new version of the application with modified artifacts from the patch. Any requests to the application are directed to the new version once it is available. A user may experience a small performance impact due to the added load on the system by patching sessions and also due to initialization when an updated application is accessed for the first time.
The following phases occur during hot patching mode before the patch is actually applied:
The system is placed in maintenance preparatory warning mode. In this mode users are informed of the upcoming maintenance window.
MANDATORY: All users impacted by the applications must complete their activities before the maintenance window begins.
During maintenance warning mode, the impacted ESS task schedulers are paused and the impacted SOA Event Delivery Network is paused.
When the specified waiting period ends, background processes are checked to ensure there are no active tasks. If the -forceterminateactivetasks
option is specified at the command line, all active tasks are terminated. Otherwise, a list of tasks is printed and the patching session exits with a failure.
See Apply Patches in Hot Patching Mode for more information about hot patching mode.
When a patch contains Database and Oracle Fusion Middleware changes, Patch Manager coordinates the application of both changes, applying database changes first, followed by Oracle Fusion Middleware changes. The patch is applied in a single operation, regardless of the type of artifacts that are updated.
Patch Manager examines patch metadata and determines which actions must be performed by OPatch and which must be performed by AutoPatch. If Patch Manager discovers that a patch contains only database changes, it assigns the patch directly to AutoPatch for processing. If the patch is related only to Oracle Fusion Middleware changes, Patch Manager orchestrates the application of the changes across domains and the Oracle home.
The following figure illustrates the patching process coordinated to Patch Manager:
Figure 2-1 Oracle Fusion Applications Coordinated Patching
The following high-level phases occur when applying a patch in online mode that contains an Oracle Application Development Framework (Oracle ADF) library and a seed data file:
Patch Manager interprets the contents of the patch by reading the patch metadata.
AutoPatch updates the seed data.
OPatch applies the change to the Oracle ADF library in the form of a JAR file.
Patch Manager coordinates with OPatch and forces an immediate shutdown and restart of the impacted Managed Servers so the change to the Oracle ADF library takes effect.
Patch Manager consolidates and provides results and status for the overall patching tasks in the Log Summary and the Diagnostics report.
A patch with database-related changes includes a patch driver file that provides instructions to AutoPatch about how to apply the patch. The patch driver file specifies the types of actions to be executed and the phases in which they are executed. To achieve efficient processing time, the database tasks are performed by worker processes and the number of tasks performed is minimized by file version verification.. See the About Worker Processes and the File Version Verification sections to understabd how Autopatch works.
When a patch contains updates to database artifacts, such as application seed data, the database schema, PL/SQL objects, and SQL scripts; Patch Manager calls AutoPatch to coordinate the following tasks:
Worker calculation: Calculates the default number of workers that are necessary. If patching is run on the same machine as the database server, the default number of workers is calculated as 0.5 times the number of Virtual CPUs (VCPUs) on the database server. If patching is run on a machine different from the database server on a Linux platform, the default number of workers is calculated as the minimum of the VCPUs available on the database server and the patching machine. On non-Linux platforms, the default number of workers is equal to the number of VCPUs on the database server. Reduce the number of workers If the machine where the patch is applied has a lower number of VCPUs when compared to those on the database server, then reduce the number of workers.
OPTIONAL: To override the default number of workers when applying a patch, specify the number of workers by using the workers
option.
The number of workers used for patching database artifacts also imposes a requirement on the open file descriptors configured for the system. Patching requires that the open file descriptors be set to a minimum of 8000 times the number of workers used for the patch session.
Patch validation : Validates whether the database portion of the patch is compatible with the environment and can be applied. If the patch is not valid and the patching session fails, see the Monitor and Troubleshoot Patches section. If the patch is valid, the following validations are performed:
Platform check: Compares the operating system platform for each Oracle Fusion Applications Oracle home against the platform metadata in the patch.
Prerequisite check: Validates that all patch prerequisites have been applied.
Patch Application: Copies the database artifacts to the Oracle home and then makes changes in the Oracle Fusion Applications database using the updated files.
Invalid Object Compilation: Compiles all invalid objects in the database.
Consolidation of log files: Collects the patching results and location of log files for reporting purposes.
An AutoPatch manager
process reads the patch driver file and determines the set of tasks to be performed. It then spawns processes called workers to execute the tasks. The manager and its workers communicate through a table in the database, which contains one row for each worker process. The manager assigns tasks to workers by updating the worker row in the table. Each worker process checks the table for updates to its row and carries out the task. When the task is complete, the worker updates the status in the table, and the manager then assigns another task to the worker.
AutoPatch performs file version verification to ensure that only new actions run during patch applications.
CONDITIONAL: AutoPatch runs the action only if the version in the patch is newer than the last version run.
Patch Manager uses the standard database-supplied compile utility, which compiles all invalid objects in the database, if no specific schema is supplied. If a schema is supplied it compiles all objects in the schema that are in an invalid state, including those invalid objects that were not affected by the patch. Dependencies between objects can be complex, such as when patching an object causes other objects to become invalid, even though those objects are not in the patch. The purpose of compiling invalid objects after a patch applies is to have a clean database where all objects are in a valid state.
During provisioning, the patching framework and the Oracle Fusion Applications software were installed into what is known as the Oracle Fusion Applications Oracle home. This Oracle home directory, /net/mount1/appbase/fusionapps/applications
, is a subdirectory under the Oracle Fusion Applications Middleware home. The top level directory, /net/mount1/appbase
, is referred to as the APPLICATIONS_BASE
, and is where all Oracle Fusion Applications binaries reside. There is one and only one set of patching-related software and database tables for each Oracle home. Unless otherwise specified, the use of "Oracle home" and FA_ORACLE_HOME
in this guide refers to the Oracle Fusion Applications Oracle home.
The following figure shows the related directory structure, beginning with APPLICATIONS_BASE
:
Figure 2-2 Oracle Fusion Applications Directory Structure
The Oracle home contains the following subdirectories:
lcm: Contains the patching framework software in the following subdirectories:
.../ad/bin
: Patching framework software and files, including C artifacts and configuration scripts that set the environment and start the corresponding utility
.../ad/java
: Java artifacts
.../ad/db/sql
: Database artifacts and SQL files
.../ad/lib
: Application libraries
.../ad/template
: Configuration files or templates delivered and used by the patching framework during configuration activities
bin: Contains applications artifacts called by Enterprise Scheduler Service jobs.
product family: Contains directories for artifacts specific to a product configuration.
admin: Contains the patching framework environment properties file (FUSION_env
.properties)
, Oracle Fusion Applications AutoPatch (AutoPatch) and the patching logs, reports, and administration files.
MANDATORY: These files are required by Patch Manager.
lib: Contains applications-specific libraries.
OPatch: Contains the OPatch utility called by Patch Manager when patching middleware artifacts. This version of OPatch is used to apply patches to the middleware files and software artifacts that reside within the Oracle Fusion Applications Oracle home, and is delivered as part of the Oracle Fusion Applications software. There may be multiple versions of OPatch to support the enterprise software. However, if a newer version is required it will clearly stated in the README of patch set to be applied.
CONDITIONAL: When applying patches to the Oracle homes, on hosts where Oracle Fusion Middleware Oracle homes co-exists with FA_ORACLE_HOME
, OPatch from FA_ORACLE_HOME
has to be used. For example, SOA (fusionapps/soa
) and ATGPF (fusionapps/atgpf
) Oracle homes exist on the same file system as FA_ORACLE_HOME
(fusionapps/applications
). When applying patches or executing any OPatch related commands for SOA and ATGPF, the OPatch from FA_ORACLE_HOME
(fusionapps/applications/OPatch/opatch
) must be used.
Oracle Fusion Middleware Oracle homes and Oracle Fusion Applications Oracle home are read only and customers are not expected to update or install any components manually to these home directories. These home directories can be updated only by Oracle Fusion Applications LifeCycle tools, such as Provisioning, Upgrade Orchestrator, and Patch Manager.
The patch top directory is any directory selected for downloading patch ZIP files. This directory is also called patch_top
or PATCH_TOP
. For example, if patch 1234567.zip is downloaded into /home/mypatches
and unzipped there, the patch top directory is /home/mypatches/1234567
.
When a patch with a later version of an existing database artifact is applied on the Oracle Home, Patch Manager automatically backs up the existing database artifacts and restores them into a backup directory. The default location for the backup directory is admin/pbackup
under the Oracle home. This location may be overridden by editing the PATCH_BACKUP_DIR
parameter in the FUSION_env
.properties
file.
The Oracle Universal Installer (OUI) inventory stores information about all Oracle software products installed in all Oracle homes. Each product, such as Oracle Fusion Applications, maintains its own local inventory and Oracle home. The Local inventory files for Oracle Fusion Applications are located in the Oracle Fusion Applications Oracle home where they are read and updated by the patching framework.
The OUI inventory has the following hierarchical structure:
Central Inventory Pointer File: The Central Inventory is located in the directory that the inventory pointer file specifies. Each Oracle software installation has its own Central Inventory pointer file that is unknown to another Oracle software installation. The following table shows the location of the default inventory pointer file for various platforms:
Table 2-4 Default Inventory Pointer File Locations
Platform | Default Inventory Pointer Location |
---|---|
Linux Linux.PPC64 AIX |
|
Solaris.SPARC Solaris.X64 HPUX HPIA HP.TRU64 Linux.IA64 Linux.xSeries |
|
Central Inventory File: This file, inventory.xml
, is present in the following location: central_inventory_location/
ContentsXML/inventory.xml
. It contains a list of Oracle homes installed on the node.
Oracle Home Inventory: The Oracle home inventory or local inventory is present inside each Oracle home and contains only information relevant to a specific Oracle home. This file is located in the $ORACLE_HOME/inventory
and contains the following files:
Components File
Home Properties File
Other Folders
Each Oracle home contains OUI components. In Oracle Fusion Applications, each product family is assigned an OUI component and other entities are also assigned a component. For example, the component oracle.fusionapps.fin
is assigned to Oracle Fusion Financials. The patching framework uses this information to identify and determine the specific contents of the patch that are applicable to the Oracle home, as well as to perform patch validation, patch verification, and reporting.
Patch Manager queries the taxonomy MBean URL (as defined by the environment property called taxonomy_url
) to determine which domain is affected by a specific patch. For example, to determine where a Java EE application is running or where a Service-Oriented Architecture (SOA) composite is deployed. The URL points to an Administration Server of the domain where taxonomy MBeans are hosted. This variable is set during the provisioning process in the FUSION_env
.properties
file. This value can be overridden during patching by providing the taxonomyurl
option when running Patch Manager. For example, if the server being referenced by the default taxonomy_url
is down, enter an overriding URL from the command line.
Oracle Fusion Applications patches often include content for both middleware artifacts and database artifacts. The patching framework examines the high-level contents of each patch and calls the appropriate patching tool to process the patch content.
If the patch only contained database artifacts, the 12345_MW
directory would not exist. If the patch only contained middleware artifacts, the 123456_DB
directory would not exist. Using patch number 123456 as an example of a patch that contains both database and middleware artifacts, the unzipped patch directory, PATCH_TOP/
123456, contains the files and subdirectories shown in the following figure:
Figure 2-3 Example Directory Structure of a One-Off Patch
A sample of the Patch Content is described below, using patch number 123456 as an example of a patch that contains both database and middleware artifacts:
README.txt
: Provides general instructions to apply the patch and to perform manual steps, if required by the patch. If there are patches listed under "Other Patches" in the README
file, they must be downloaded and applied before deploying the Oracle Fusion Applications patch.
obj123456.xml
: Contains information about each artifact included in the patch.
An example of the contents of the obj123456.xml
is described below:
<?xml version="1.0" encoding="UTF-8"?> <PATCH_OBJECT_MANIFEST VERSION="1.0"> <COMPONENT TYPE="MW"> <OBJECT_INFO NAME="AdfPjgTopPublicUi.jar" SUBDIR="prj/deploy/EARProjectsFinancials.ear/EARProjectsFinancials/WEB-INF/lib" SRCDIR="prj/deploy/EARProjectsFinancials.ear/EARProjectsFinancials/WEB-INF/lib" PRODUCTFAMILY="prj" PRODUCT="pjg" LBA="PjgTop" APPNAME="EARProjectsFinancials.ear" HEADERSTRING="$AppsHeader:fusionapps/prj/components/projectsFinancials/jlib/AdfPjgTopPublicUi.jar st_fusionapps_pt/63 level:0 00.S $" OUI_COMPONENT="oracle.fusionapps.prj.deploy" VERSION="63.0" TRANSLATION_LEVEL="0" ACTION="COPY" ARTIFACT_TYPE="JEE" /> </COMPONENT> <COMPONENT TYPE="DB"> <OBJECT_INFO NAME="pjf_event_type_data.sql" SUBDIR="prj/pjf/db/sql" SRCDIR="prj/pjf/db/sql" PRODUCTFAMILY="prj" PRODUCT="pjf" LBA="" APPNAME="" HEADERSTRING="$Header: fusionapps/prj/pjf/db/sql/pjf_event_type_data.sql" OUI_COMPONENT="oracle.fusionapps.prj.db" VERSION="st_fusionapp/1" TRANSLATION_LEVEL="0" /> </COMPONENT> <COMPONENT TYPE="DB"> <OBJECT_INFO NAME="pjf_event_type_data.sql" SUBDIR="prj/pjf/db/sql" PRODUCTFAMILY="prj" PRODUCT="pjf" LBA="" APPNAME="" HEADERSTRING="$Header: fusionapps/prj/pjf/db/sql/pjf_event_type_data.sql" OUI_COMPONENT="oracle.fusionapps.prj.db" VERSION="st_fusionapps/1" TRANSLATION_LEVEL="0" /> </COMPONENT> </PATCH_OBJECT_MANIFEST>
uw123456.xml
contains high-level information about the patch and provides the following information:
Translation and platform attributes
Prerequisite patches
Additional bug fixes that are included in the patch
Compatibility information for the patch, such as product family and application name
Type of patch content and attributes, such as the patch driver location and whether manual steps exist
An example of the contents of the uw123456.xml
file is described below:
<?xml version="1.0" encoding="UTF-8"?> <!--PATCHGEN_VERSION: 11.1.1.5.0--> <!--OPACK_LABEL: /net/sta.world.com/OPATCH_MAIN_GENERIC.rdd/opatch/OPack--> <!--OPACK_VERSION: null--> <!--VIEW_LABEL: FUSIONAPPS_PT.2000.S--> <!--PATCH_COMMAND: ant stFullPatchTransaction -Dtransaction=prj_adflib_db -Dinclude=ALL -Dbugid=123456 --> <PatchManifest Version="1.0"> <PatchList PatchType="SNOWBALL" Translatable="Y" PartialTranslations="N" HighAvailability="DERIVE" Merge="N" GUID="1004567" > <Patch Number="123456" Language="US" Platform="GENERIC" GUID="1004567" BaseBug="123456" BaseProductFamily="UNKNOWN" BaseProduct="UNKNOWN" BaseLBA="" Description="" /> </PatchList> <PreReqBugfixList> </PreReqBugfixList> <RequiredComponentList> <RequiredComponent ID="oracle.fusionapps.prj.deploy" Version="11.1.1.5.0" /> <RequiredComponent ID="oracle.fusionapps.prj.db" Version="11.1.1.5.0" /> </RequiredComponentList> <BugfixList> <Bugfix Number="123456" ProductFamily="" Product="" LBA="" Description=""/> </BugfixList> <Impact> <ProductFamilyList> <ProductFamily Name="prj"> <ProductList> <Product Name="pjf"> </Product> <Product Name="pjg"> <LBAList> <LBA Name="PjgTop"/> </LBAList> </Product> </ProductList> </ProductFamily> </ProductFamilyList> <ApplicationList> <Application Name="EARProjectsFinancials.ear"/> </ApplicationList> </Impact> <ContentList> </Product> <Product Name="pjg"> <LBAList> <LBA Name="PjgTop"/> </LBAList> </Product> </ProductList> </ProductFamily> </ProductFamilyList> <ApplicationList> <Application Name="EARProjectsFinancials.ear"/> </ApplicationList> </Impact> <ContentList> <Content Type="DB" PreApplySteps="N" PostApplySteps="N" PatchDriver="u123456.drv" PatchDriverLocation="123456_DB" DataModelChanges="N" SeedDataChanges="N" PlSqlChanges="N" SQLChanges="Y" FlexChanges="N" LDAPChanges="N" DataSecurityChanges="N" /> <Content Type="MW" PreApplySteps="N" PostApplySteps="N" PatchDriverLocation="123456_MW" /> </ContentList> </PatchManifest>
123456_DB
: Contains files related to changes for the database artifacts included in this patch, bundled so that they can be accessed and applied using AutoPatch.
The following files exist in the 123456_DB
directory:
u123456.drv
: Contains instructions for AutoPatch to make changes to an Oracle Fusion Applications database and is referred to as the patch driver file.
Product family directory: Contains the patch content for database artifacts in a form that is readable by AutoPatch.
123456_MW
: Contains files related to middleware artifact changes included in this patch, bundled so that they can be accessed and applied using OPatch. The patch content resides under the files
subdirectory in a form that is readable by OPatch. The patch metadata resides under the etc
subdirectory.
The middleware metadata files exist in the following subdirectories:
/etc/config/actions.xml
An example of the contents of the actions.xml
file is described below:
<oneoff_actions> <oracle.fusionapps.prj.deploy version="11.1.1.5.0" opt_req="R"> <copy name="AdfPjgTopPublicUi.jar" path="%ORACLE_HOME%/prj/deploy/EARProjectsFinancials.ear/EARProjectsFinancials/WEB-INF/lib" file_name="prj/deploy /EARProjectsFinancials.ear/EARProjectsFinancials/WEB-INF/lib/AdfPjgTopPublic Ui.jar" file_version="63.0"/> </oracle.fusionapps.prj.deploy> </oneoff_actions>
/etc/config/automation.xml
An example of the contents of the automation.xml
file is described below:
<automation xmlns="http://oracle.com/schema/opatch/Automation" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://oracle.com/schema /opatch/Automation ../../xsd/automation.xsd" opatch-version="11.1.0.6.0" deployment-type="fapps" deployment-sub-type="fapps-artifacts"> <post-patch-application> <deploy-action acts-on="SOAComposite"> <deploy-artifact file-name="sca_FinGlCurrencyUserPreferredCurrencyComposite.jar" destination-path="%ORACLE_HOME%/fin/deploy" name="FinGlCurrencyUser PreferredCurrencyComposite" revision="7_5512345"/> </deploy-action> </post-patch-application> </automation>
/etc/config/checksum.xml
An example of the contents of the checksum.xml
file is described below:
</checksum_info> <file path="%ORACLE_HOME%/fscm/security/policies/system-jazn-data.xml" checksum="-1"/> </checksum_info>
/etc/config/inventory.xml
An example of the contents of the inventory.xml
file is described below:
<oneoff_inventory> <opack_version version="11.1.0.6.0"/> <patch_id number="123456"/> <cannot_autorollback>false</cannot_autorollback> <date_of_patch year="2011" month="Feb" day="16" time="10:47:37 hrs" zone="PST8PDT"/> <base_bugs> <bug number="123456" description="fusionapps patch"/> </base_bugs> <required_components> <component internal_name="oracle.fusionapps.prj.deploy" version="11.1.1.5.0" opt_req="R"/> </required_components> <os_platforms> <platform name="Generic Platform 2" id="2000"/> </os_platforms> <executables></executables> <instance_shutdown>false</instance_shutdown> <instance_shutdown_message></instance_shutdown_message> <online_rac_installable>false</online_rac_installable> <run_as_root>false</run_as_root> <sql_migrate>false</sql_migrate> <wls_prereq_oneoffs></wls_prereq_oneoffs> <os_platforms> <platform name="Generic Platform 2" id="2000"/> </os_platforms> <executables></executables> <instance_shutdown>false</instance_shutdown> <instance_shutdown_message></instance_shutdown_message> <online_rac_installable>false</online_rac_installable> <run_as_root>false</run_as_root> <sql_migrate>false</sql_migrate> <wls_prereq_oneoffs></wls_prereq_oneoffs> <prereq_oneoffs></prereq_oneoffs> <coreq_oneoffs></coreq_oneoffs> <overlay_oneoffs></overlay_oneoffs> <patch_type value="snowball"/> <patch_language value="en"/> <product_family value="fusionapps"/> <patching_model value="snowball"/> <auto>false</auto> <translatable>true</translatable> <applicable_product/> <products></products> <update_components></update_components> </oneoff_inventory>
In Oracle Fusion Applications, credentials used for patching are stored securely based in the Lightweight Directory Access Protocol (LDAP) Credential Store Framework (CSF), where they can be retrieved when required and hidden when starting processes from the command line. Credentials are not stored in any format in the file system or in the database. Users are not prompted for passwords when using command-line utilities. A separate role is not used for patching purposes because all patch administrators log in as the same operating system user to apply patches.
MANDATORY: The patch administrator user must be an owner of the Oracle Fusion Applications Oracle home.
Patch Manager obtains passwords from the CSF based on the following criteria:
CSF APIs are used to obtain passwords from the CSF
A combination of a MAP
and a KEY
returns the user name, and its corresponding password, in decrypted format
All credentials are securely stored in a wallet that is stored in LDAP. Patch Manager credentials are available under the oracle.patching
MAP
name and each credential is identified by a KEY.
The patching framework uses CSF APIs to retrieve credentials. It does not pass the credentials at the command line when calling either AutoPatch or OPatch.
Security can be breached when prompted for a password while invoking patching from the command line. To avoid this situation, Patch Manager uses the Oracle Platform Security Services APIs to fetch passwords from the CSF.
Patch Manager uses a defaults file to store the arguments and other information required for a given session, but does not read or write credentials to or from the defaults file. Additionally, Patch Manager does not read or write credentials from restart files or log files.