1 Oracle Fleet Patching and Provisioning

Oracle Fleet Patching and Provisioning is a software lifecycle management method for provisioning and maintaining Oracle homes.

Oracle Fleet Patching and Provisioning (Oracle FPP) enables mass deployment and maintenance of standard operating environments for databases, clusters, and user-defined software types. With Oracle Fleet Patching and Provisioning, you can also install clusters and provision, patch, scale, and upgrade Oracle Grid Infrastructure and Oracle Database 11g release 2 (11.2), and later. Additionally, you can provision applications and middleware.

Note:

Starting with Oracle Grid Infrastructure 19c, the feature formerly known as Rapid Home Provisioning (RHP) is now Oracle Fleet Patching and Provisioning (Oracle FPP).

This chapter includes the following topics:

About Oracle Fleet Patching and Provisioning

Oracle Fleet Patching and Provisioning (FPP) is a service in Oracle Grid Infrastructure.

You can use Oracle Fleet Patching and Provisioning in either of the following modes:
  • As a central server (Fleet Patching and Provisioning Server), that stores and manages standardized images, called gold images. You can deploy gold images to any number of nodes across a data center. You can use the deployed homes to create new clusters and databases, and patch, upgrade, and scale existing installations.

    The server manages software homes on the cluster hosting the Oracle Fleet Patching and Provisioning Server, itself, Oracle Fleet Patching and Provisioning Clients, and can also manage installations running Oracle Grid Infrastructure 11g release 2 (11.2.0.3 and 11.2.0.4), 12c release 1 (12.1.0.2), and later releases. The server can also manage installations running no grid infrastructure.

    An Oracle Fleet Patching and Provisioning Server can provision new installations and can manage existing installations without any changes to the existing installations (such as no agent, daemon, or configuration prerequisites). Oracle Fleet Patching and Provisioning Servers also include capabilities for automatically sharing gold images among peer Oracle Fleet Patching and Provisioning Servers to support enterprises with geographically distributed data centers.

  • As a client (Oracle Fleet Patching and Provisioning Client), that can be managed from the central Oracle Fleet Patching and Provisioning Server or directly by running commands on the Oracle Fleet Patching and Provisioning Client, itself. As with the Oracle Fleet Patching and Provisioning Server, the Oracle Fleet Patching and Provisioning Client is a service built in to Oracle Grid Infrastructure and is available with Oracle Grid Infrastructure 12c release 2 (12.2.0.1), and later. The Oracle Fleet Patching and Provisioning Client service can retrieve gold images from the Oracle Fleet Patching and Provisioning Server, upload new images based on policy, and apply maintenance operations to itself.

For patching operations, a third option is available with Oracle Database and Oracle Grid Infrastructure 18c, and later. The procedures for updating database and grid infrastructure homes have been modularized into independent automatons that are included with Oracle Database and Oracle Grid Infrastructure, and can be run locally without any central Oracle Fleet Patching and Provisioning Server in the architecture. This provides an immediate entry point to the capabilities of Oracle Fleet Patching and Provisioning as soon as you bring up an Oracle Database or cluster.

Note:

Combined Oracle FPP patching for Oracle Grid Infrastructure and Oracle Database is not supported for standalone configurations.

This topic includes information about the following:

Oracle Fleet Patching and Provisioning Advantages

Deploying Oracle software using Oracle Fleet Patching and Provisioning has the following advantages:

  • Ensures standardization and enables high degrees of automation with gold images and managed lineage of deployed software.

  • Minimizes downtime by deploying new homes as images (called gold images) out-of-place, without disrupting active databases or clusters.

  • Simplifies maintenance by providing automatons which are invoked with a simple, consistent API across database versions and deployment models.

  • Reduces maintenance risk with built-in validations and a dry run mode to test the operations.

  • Enables you to resume or restart the commands in the event of an unforeseen issue, reducing the risk of maintenance operations.

  • Minimizes and often eliminates the impact of patching and upgrades, with features that include:
    • Zero-downtime database upgrade with fully automated upgrade, executed entirely within the deployment without requiring any extra nodes or external storage.
    • Adaptive management of database sessions and OJVM during rolling patching.
    • Options for management of consolidated deployments.
  • The deployment and maintenance operations enable customizations to include environment-specific actions into the automated workflow.

Managing Oracle software using Oracle Fleet Patching and Provisioning

When you manage Oracle software using Oracle Fleet Patching and Provisioning, Oracle FPP:
  • Ensures standardization and enables high degrees of automation with gold images and managed lineage of deployed software.

  • Minimizes the maintenance window by deploying new homes (gold images) out-of-place, without disrupting active databases or clusters.

  • Simplifies maintenance by providing automatons that are invoked with an API across database versions and deployment models.

  • Reduces maintenance risk with built-in validations and a dry-run mode to ensure operations will succeed end-to-end.

  • In the event of an issue, commands are resumable and restartable, further reducing risk of maintenance operations.

  • Minimizes and, in many cases, eliminates the impact of patching and upgrades, with features that include:

    • Zero-downtime database upgrade: A fully-automated upgrade executed entirely within the deployment with no extra nodes or external storage required.

    • Adaptive management of database sessions and OJVM during rolling patching.

    • Options for fine-grained management of consolidated deployments.

The deployment and maintenance operations are extensible, allowing customizations to include environment-specific actions into the automated workflow.

Oracle Fleet Patching and Provisioning Automatons

  • Zero-downtime database upgrade automates all of the steps involved in a database upgrade to minimize or even eliminate application downtime while upgrading an Oracle database. It also minimizes resource requirements and provides a fallback path in case the upgrade must be rolled back.

  • Adaptive Oracle RAC Rolling Patching for OJVM Deployments: In a clustered environment, the default approach for Oracle Fleet Patching and Provisioning for patching a database is Oracle RAC rolling patching. However non-rolling may be required if the patched database home contains OJVM patches. In this case, Oracle Fleet Patching and Provisioning determines whether rolling patching is possible and does so, if applicable.

  • Dry-run command evaluation: Before running any command, Oracle Fleet Patching and Provisioning checks various preconditions to ensure the command will succeed. However, some conditions cannot be detected prior to a command running. And, while Oracle Fleet Patching and Provisioning allows a failed command to be reverted or resumed after an error condition is corrected, it is preferable to address as many potential issues as possible before the command is run. The command evaluation mode will test the preconditions for a given command, without making any changes, and report potential problems and correct them before the command is actually run.

  • Independent automatons: Prior to Oracle Database 18c, performing any Oracle Fleet Patching and Provisioning operation (for example, switching a database home to a later version) required the presence of a central Oracle Fleet Patching and Provisioning Server. Beginning with Oracle Database 18c, key functionality can be performed independently, with no central Oracle Fleet Patching and Provisioning Server in the architecture.

    Note:

    When you install Oracle Grid Infrastructure, the Oracle Fleet Patching and Provisioning Server is configured, by default, in the local mode to support the local switch home capability. If you must configure the general Oracle Fleet Patching and Provisioning Server product, then you must remove the current local-mode Oracle Fleet Patching and Provisioning Server, using the following commands, as root:
    # srvctl stop rhpserver

    Ignore a message similar to "Fleet Patching and Provisioning Server is not running".

    # srvctl remove rhpserver

    Refer to Oracle Clusterware Administration and Deployment Guide for information about srvctl remove rhpserver and srvctl stop rhpserver.

Global Fleet Standardization and Management

  • Sharing gold images between peer Oracle Fleet Patching and Provisioning Servers: Large enterprises typically host multiple data centers and, within each data center, there may be separate network segments. In the Oracle Fleet Patching and Provisioning architecture, one Oracle Fleet Patching and Provisioning Server operates on a set of targets within a given data center (or network segment of a data center). Therefore each data center requires at least one Oracle Fleet Patching and Provisioning Server.

    While each data center may have some unique requirements in terms of the gold images that target servers will use, the goal of standardization is using the same gold image across all data centers whenever possible. To that end, Oracle Fleet Patching and Provisioning supports peer-to-peer sharing of gold images to easily propagate gold images among multiple Oracle Fleet Patching and Provisioning Servers.

  • Gold image drift detection and aggregation: After you provision a software home from a gold image, you may have to apply a patch directly to the deployed home. At this point the deployed home has drifted from the gold image. Oracle Fleet Patching and Provisioning provides two capabilities for monitoring and reporting drift:
    • Oracle Fleet Patching and Provisioning compares a specific home to its parent gold image and lists any patches that are applied to the home but that are not in the gold image.

    • Oracle Fleet Patching and Provisioning compares a specific gold image to all of its descendant homes and lists the aggregation of all patches applied to those homes that are not in the gold image. This provides a build specification for a new gold image that could be applied to all of the descendants of the original gold image, such that no patches will be lost from any of those deployments.

    See Also:

  • Configuration collection and reporting: The Oracle Fleet Patching and Provisioning Server can collect and retain operating system configuration and the root file system contents of specified Oracle Fleet Patching and Provisioning Clients. If an Oracle Fleet Patching and Provisioning Client node is rendered unusable (for example, a user accidentally deletes or changes operating system configuration or the root file system), then it can be difficult to determine the problem and correct it. This feature automates the collection of relevant information, enabling simple restoration in the event of node failure.

Flexibility and Extensibility

  • RESTful API: Oracle Fleet Patching and Provisioning provides a RESTful API for many common operations, including provisioning, patching, upgrading, and query operations.
  • Customizable authentication: Host-to-host authentication in certain environments, particularly in compliance-conscious industries, such as financials and e-commerce, often uses technologies and products that are not supported, natively, by Oracle Fleet Patching and Provisioning. This feature allows integrating Oracle Fleet Patching and Provisioning authentication with the mechanisms in use at your data center.

  • Command scheduler: The ability to schedule and bundle automated tasks is essential for maintenance of a large database estate. Oracle Fleet Patching and Provisioning supports scheduling tasks such as provisioning software homes, switching to a new home, and scaling a cluster. Also, you can add a list of clients to a command, facilitating large-scale operations.

  • Configurable connectivity: As security concerns and compliance requirements increase, so do the restrictions on connectivity across the intranets of many enterprises. You can configure the small set ports used for communication between the Oracle Fleet Patching and Provisioning Server and its Clients, allowing low-impact integration into firewalled or audit-conscious environments.

Other Oracle Fleet Patching and Provisioning Features

  • Zero-downtime upgrade: Automation of all of upgrade steps involved minimizes or even eliminates application downtime while upgrading an Oracle Database. It also minimizes resource requirements and provides a fallback path in case you must roll back the upgrade. You can run a zero-downtime upgrade on certain versions of Oracle RAC and Oracle RAC One Node databases.

  • Provision new server pools: The Oracle Fleet Patching and Provisioning Server can install and configure Oracle Grid Infrastructure (11g release 2 (11.2.0.4), and 12c release 1 (12.1.0.2), release 2 (12.2), and later releases) on nodes that have no Oracle software inventory and can then manage those deployments with the full complement of Oracle Fleet Patching and Provisioning functionality.

  • Provision and manage any software home: Oracle Fleet Patching and Provisioning enables you to create a gold image from any software home. You can then provision that software to any Oracle Fleet Patching and Provisioning Client or target as a working copy of a gold image. The software may be any binary that you will run on an Oracle Fleet Patching and Provisioning Client or target.

  • Provision, scale, patch, and upgrade Oracle Grid Infrastructure: The Oracle Fleet Patching and Provisioning Server can provision Oracle Grid Infrastructure 11g release 2 (11.2.0.4) homes, and later, add or delete nodes from an Oracle Grid Infrastructure configuration, and can also be used to patch and upgrade Oracle Grid Infrastructure homes. In addition, there is a rollback capability that facilitates undoing a failed patch procedure. While patching Oracle Grid Infrastructure, you can use Oracle Fleet Patching and Provisioning to optionally patch any database homes hosted on the cluster.

  • Provision, scale, patch, and upgrade Oracle Database: You can use Oracle Fleet Patching and Provisioning, you can provision, scale, and patch Oracle Database 11g release 2 (11.2.0.4), and later releases. You can also upgrade Oracle Databases from 11g release 2 (11.2.0.3) to 11g release 2 (11.2.0.4); from 11g release 2 (11.2.0.4) to 12c release 1 (12.1.0.2); and from 11g release 2 (11.2.0.4) or 12c release 1 (12.1.0.2) to 12c release 2 (12.2).

    When you provision such software, Oracle Fleet Patching and Provisioning offers additional features for creating various types of databases (such as Oracle RAC, single instance, and Oracle Real Application Clusters One Node (Oracle RAC One Node) databases) on different types of storage, and other options, such as using templates and creating container databases (CDBs). The Oracle Fleet Patching and Provisioning Server can add nodes to an Oracle RAC configuration, and remove nodes from an Oracle RAC configuration. Oracle Fleet Patching and Provisioning also improves and makes more efficient patching of database software, allowing for rapid and remote patching of the software, in most cases, without any downtime for the database.

  • Support for single-instance databases: You can use Oracle Fleet Patching and Provisioning to provision, patch, and upgrade single-instance databases running on clusters or Oracle Restart, or on single, standalone nodes.

  • Advanced patching capabilities: When patching an Oracle Grid Infrastructure or Oracle Database home, Oracle Fleet Patching and Provisioning offers a batch mode that speeds the patching process by patching some or all nodes of a cluster in parallel, rather than sequentially.

    For Oracle Database homes, you can define disjoint sets of nodes. Each set of nodes is updated sequentially. By defining sets with reference to the database instances running on them, you can minimize the impact of rolling updates by ensuring that services are never taken completely offline. A “smartmove” option is available to help define the sets of batches to meet this goal.

    Integration with Application Continuity is another enhancement to help eliminate the impact of maintenance. This provides the ability to gracefully drain and relocate services within a cluster, completely masking the maintenance from users.

  • Notifications:The Oracle Fleet Patching and Provisioning Server is the central repository for the software homes available to the data center. Therefore, it is essential that administrators throughout the data center be aware of changes to the inventory which might impact their areas of responsibility.

    Oracle Fleet Patching and Provisioning enables you and other users to subscribe to image series events. Anyone subscribed will be notified by email of any changes to the images available in a particular image series. Also, users can be notified by email when a working copy of a gold image is added to or deleted from a client.

  • Custom workflow support: You can create actions for various Oracle Fleet Patching and Provisioning operations, such as importing images, adding or deleting working copies of the gold images, and managing a software home. You can define different actions for each operation, and further differentiate by the type of image to which the operation applies. Actions that you define can be executed before or after the given operation, and are executed on the deployment the operation applies to, whether it is the Oracle Fleet Patching and Provisioning Server, a target that is not running an Oracle Fleet Patching and Provisioning Client, or a target that is running an Oracle Fleet Patching and Provisioning Client.

  • Resume failed operations: If an operation, such as adding an image, provisioning a working copy of a gold image, or performing a scale, patch or upgrade fails, then Oracle Fleet Patching and Provisioning reports the error and stops. After the problem is corrected (for example, a directory permissions or ownership misconfiguration on a target node), you can rerun the RHPCTL command that failed, and it will resume from the point of failure. This avoids redoing any work that may have been completed prior to the failure.

  • Audit command: The Oracle Fleet Patching and Provisioning Server records the execution of all Oracle Fleet Patching and Provisioning operations and also records their outcome (whether success or failure). An audit mechanism enables you to query the audit log in a variety of dimensions, and also to manage its contents and size.

Note:

  • Oracle does not support Oracle Fleet Patching and Provisioning on HP-UX or Windows operating systems.

  • The Oracle Fleet Patching and Provisioning Server does not manage operating system images.

Oracle Fleet Patching and Provisioning Architecture

Conceptual information regarding Oracle Fleet Patching and Provisioning architecture.

Oracle Fleet Patching and Provisioning architecture consists of an Oracle Fleet Patching and Provisioning Server and any number of Oracle Fleet Patching and Provisioning Clients and targets. Oracle recommends deploying the Oracle Fleet Patching and Provisioning Server in a multi-node cluster so that it is highly available.

The Oracle Fleet Patching and Provisioning Server cluster is a repository for all data, of which there are primarily two types:

  • Gold images

  • Metadata related to users, roles, permissions, and identities

The Oracle Fleet Patching and Provisioning Server (FPPS) acts as a central server for provisioning Oracle Database homes, Oracle Grid Infrastructure homes, and other application software homes, making them available to the cluster hosting the Oracle Fleet Patching and Provisioning Server and to the Oracle Fleet Patching and Provisioning Client (FPPC) clusters and targets.

Users operate on the Oracle Fleet Patching and Provisioning Server or Oracle Fleet Patching and Provisioning Client to request deployment of Oracle homes or to query gold images. When a user makes a request for an Oracle home, specifying a gold image, the Oracle Fleet Patching and Provisioning Client communicates with the Oracle Fleet Patching and Provisioning Server to pass on the request. The Oracle Fleet Patching and Provisioning Server processes the request by taking appropriate action to instantiate a copy of the gold image, and to make it available to the Oracle Fleet Patching and Provisioning Client cluster using available technologies such as Oracle Automatic Storage Management Cluster File System (Oracle ACFS) and local file systems.

The Oracle Fleet Patching and Provisioning Server communicates with Oracle Fleet Patching and Provisioning Clients (running Oracle Grid Infrastructure 12c release 2 (12.2.0.1) or later), and targets (a target is an installation with Oracle Grid Infrastructure 12c release 1 (12.1.0.2) or release 11.2, or with no Oracle Grid Infrastructure installed) using the following ports, several of which you can configure, as described in Table 1-1. Additionally, differences in ports used when communicating with Oracle Fleet Patching and Provisioning Clients versus targets are noted.

Table 1-1 Oracle Fleet Patching and Provisioning Communication Ports

Client, Target, or Both Protocol Port Purpose Description

Target

TCP

22

SSH

Authentication-based operations involving clientless targets.

Client

TCP

22

SSH

Provisioning of Oracle Grid Infrastructure 12c release 2 (12.2.0.1) or later requires an SSH port. (Subsequent Oracle Fleet Patching and Provisioning Server/Client interactions use the JMX path.)

REST API invocation node

HTTPS

8894

Oracle FPPS must allow incoming and outgoing communication from the REST invocation node REST request response

REST invocation node initiates a HTTPS connection to FPPS on this port. FPPS should allow an incoming connection and outgoing response to the REST Invocation node for the established connection.

Client

TCP

8896

JMX registry and server port

For establishing Oracle Fleet Patching and Provisioning Server communication with Oracle Fleet Patching and Provisioning Clients.

You can configure this port using the srvctl modify rhpserver -port port_number command.

Note: The preceding command requires you to restart the service.

Client

UDP

Port 53 must be open only on the FPPS to accept incoming connections from FPPC nodes and should allow outgoing communication, GNS response to be sent back FPPC.

GNS port

GNS is used for Oracle Fleet Patching and Provisioning Clients to locate the Oracle Fleet Patching and Provisioning Server.

You can configure GNS with or without zone delegation.

Both

TCP

Specify one port for each RHPCTL command from ephemeral port range, or one port as specified with the srvctl modify rhpserver -pl_port port_number command.

Progress listener port must be open to accept incoming connections on the server where RHPCTL is run (whether a Oracle Fleet Patching and Provisioning Server or Client).

Command progress listener

Oracle Fleet Patching and Provisioning Server opens a random port from the ephemeral range to monitor progress on the client or target, or uses the fixed port you specify with the srvctl modify rhpserver -pl_port port_number and multiplexes across clients/targets.

Clients running Oracle Database 18c or Oracle Database 12c release 2 (12.2.0.1) with the January 2018 RU, or later

TCP

You must have six ports for gold image provisioning on an Oracle Fleet Patching and Provisioning Client server to accept incoming connections.

Gold image transfers to Oracle Database 18c clients and clients with the 2018 January RU (running the rhpctl add workingcopy command on the Oracle Fleet Patching and Provisioning Server)

Transferring copies of gold images from the Oracle Fleet Patching and Provisioning Server to clients uses six ports chosen from the ephemeral range, or six ports from the range you define using the srvctl modify rhpserver -port_range port_number_range. In this case, specify a range to accommodate the anticipated degree of parallelism (concurrent transfers) you will use. If the port_range value is specified and if RHPS manages 12.2 clients, then the client must be patched to 12.2.0.1.180717OCWJUL2018RU or later.

Oracle Fleet Patching and Provisioning Server

The Oracle Fleet Patching and Provisioning Server (FPPS) is a highly available software provisioning system that uses Oracle Automatic Storage Management (Oracle ASM), Oracle Automatic Storage Management Cluster File System (Oracle ACFS), Grid Naming Service (GNS), and other components.

The Oracle Fleet Patching and Provisioning Server primarily acts as a central server for provisioning Oracle homes, making them available to Oracle Fleet Patching and Provisioning Client and targets.

Features of the Oracle Fleet Patching and Provisioning Server:

  • Efficiently stores gold images and image series for the managed homes, including separate binaries, and metadata related to users, roles, and permissions.

  • Provides a list of available homes to clients upon request.

  • Patch a software home once and then deploy the home to any Oracle Fleet Patching and Provisioning Client or any other target, instead of patching every site.

  • Provides the ability to report on existing deployments.

  • Deploys homes on physical servers and virtual machines.

  • Notifies subscribers of changes to image series.

  • Maintains an audit log of all RHPCTL commands run.

Oracle Fleet Patching and Provisioning Targets

Computers of which Oracle Fleet Patching and Provisioning is aware are known as targets.

Oracle Fleet Patching and Provisioning Servers can create new targets, and can also install and configure Oracle Grid Infrastructure on targets with only an operating system installed. Subsequently, Oracle Fleet Patching and Provisioning Server can provision database and other software on those targets, perform maintenance, scale the target cluster, in addition to many other operations. All Oracle Fleet Patching and Provisioning commands are run on the Oracle Fleet Patching and Provisioning Server. Targets running the Oracle Fleet Patching and Provisioning Client in Oracle Clusterware 12c release 2 (12.2), and later, may also run many of the Oracle Fleet Patching and Provisioning commands to request new software from the Oracle Fleet Patching and Provisioning Server and initiate maintenance themselves, among other tasks.

Note:

The Oracle Fleet Patching and Provisioning Server communicates with Oracle Grid Infrastructure Clusters at version 12.2.0.1 and later through an Oracle Fleet Patching and Provisioning Client that can be configured and started up on the target cluster. The Oracle Fleet Patching and Provisioning Client is not supported for targets at Oracle Grid Infrastructure version 12.1 and earlier, on all versions of Oracle Restart and database standalone targets, such as database homes without an Oracle Grid Infrastructure home or Oracle Restart home.

Oracle Fleet Patching and Provisioning Clients

The Oracle Fleet Patching and Provisioning Client is part of the Oracle Grid Infrastructure. Users operate on an Oracle Fleet Patching and Provisioning Client to perform tasks such as requesting deployment of Oracle homes and listing available gold images.

When a user requests an Oracle home specifying a gold image, the Oracle Fleet Patching and Provisioning Client communicates with the Oracle Fleet Patching and Provisioning Server to pass on the request. The Oracle Fleet Patching and Provisioning Server processes the request by instantiating a working copy of the gold image and making it available to the Oracle Fleet Patching and Provisioning Client using Oracle ACFS or a different local file system.

The Oracle Fleet Patching and Provisioning Client:

  • Can use Oracle ACFS to store working copies of gold images which can be rapidly provisioned as local homes; new homes can be quickly created or undone using Oracle ACFS snapshots.

    Note:

    Oracle supports using other local file systems besides Oracle ACFS.

  • Provides a list of available homes from the Oracle Fleet Patching and Provisioning Server.

  • Has full functionality in Oracle Clusterware 12c release 2 (12.2) and can communicate with Oracle Fleet Patching and Provisioning Servers from Oracle Clusterware 12c release 2 (12.2), or later.

Authentication Options for Oracle Fleet Patching and Provisioning Operations

Some RHPCTL commands show authentication choices as an optional parameter.

Specifying an authentication option is not required when running an RHPCTL command on an Oracle Fleet Patching and Provisioning Client, nor when running an RHPCTL command on the Oracle Fleet Patching and Provisioning Server and operating on an Oracle Fleet Patching and Provisioning Client, because the server and client establish a trusted relationship when the client is created, and authentication is handled internally each time a transaction takes place. (The only condition for server/client communication under which an authentication option must be specified is when the server is provisioning a new Oracle Grid Infrastructure deployment—in this case, the client does not yet exist.)

To operate on a target that is not an Oracle Fleet Patching and Provisioning Client, you must provide the Oracle Fleet Patching and Provisioning Server with information allowing it to authenticate with the target. The options are as follows:
  • Provide the root password (on stdin) for the target

  • Provide the sudo user name, sudo binary path, and the password (stdin) for target

  • Provide a password (either root or sudouser) non-interactively from local encrypted store (using the -cred authentication parameter)

  • Provide a path to the identity file stored on the Oracle Fleet Patching and Provisioning Server for SSL-encrypted passwordless authentication (using the -auth sshkey option)

Passwordless Authentication Details

The Oracle Fleet Patching and Provisioning Server can authenticate to targets over SSH using a key pair. To enable this option, you must establish user equivalence between the crsusr on the Oracle Fleet Patching and Provisioning Server and root or a sudouser on the target.

Note:

The steps to create that equivalence are platform-dependent and so not shown in detail here. For Linux, see commands ssh-keygen to be run on the target and ssh-copy-id to be run on the Oracle Fleet Patching and Provisioning Server.
For example, assuming that you have established user equivalency between crsusr on the Oracle Fleet Patching and Provisioning Server and root on the target node, nonRHPClient4004.example.com, and saved the key information on the Oracle Fleet Patching and Provisioning Server at /home/oracle/rhp/ssh-key/key -path, then the following command will provision a copy of the specified gold image to the target node with passwordless authentication:
$ rhpctl add workingcopy -workingcopy db12102_160607wc1 -image db12102_160607
  -targetnode nonRHPClient4004.example.com -path /u01/app/oracle/12.1/rhp/dbhome_1
  -oraclebase /u01/app/oracle -auth sshkey -arg1 user:root -arg2
   identity_file:/home/oracle/rhp/ssh-key/key
For equivalency between crsusr on the Oracle Fleet Patching and Provisioning Server and a privileged user (other than root) on the target, the -auth portion of the command would be similar to the following:
-auth sshkey -arg1 user:ssh_user -arg2 identity_file:path_to_identity_file_on_RHPS
 -arg3 sudo_location:path_to_sudo_binary_on_target

Oracle Fleet Patching and Provisioning Roles

An administrator assigns roles to Oracle Fleet Patching and Provisioning users with access-level permissions defined for each role. Users on Oracle Fleet Patching and Provisioning Clients are also assigned specific roles. Oracle Fleet Patching and Provisioning includes basic built-in and composite built-in roles.

Basic Built-In Roles

The basic built-in roles and their functions are:

  • GH_ROLE_ADMIN: An administrative role for everything related to roles. Users assigned this role are able to run rhpctl verb role commands.

  • GH_SITE_ADMIN: An administrative role for everything related to Oracle Fleet Patching and Provisioning Clients. Users assigned this role are able to run rhpctl verb client commands.

  • GH_SERIES_ADMIN: An administrative role for everything related to image series. Users assigned this role are able to run rhpctl verb series commands.

  • GH_SERIES_CONTRIB: Users assigned this role can add images to a series using the rhpctl insertimage series command, or delete images from a series using the rhpctl deleteimage series command.

  • GH_WC_ADMIN: An administrative role for everything related to working copies of gold images. Users assigned this role are able to run rhpctl verb workingcopy commands.

  • GH_WC_OPER: A role that enables users to create a working copy of a gold image for themselves or others using the rhpctl add workingcopy command with the -user option (when creating for others). Users assigned this role do not have administrative privileges and can only administer the working copies of gold images that they create.

  • GH_WC_USER: A role that enables users to create a working copy of a gold image using the rhpctl add workingcopy command. Users assigned this role do not have administrative privileges and can only delete working copies that they create.

  • GH_IMG_ADMIN: An administrative role for everything related to images. Users assigned this role are able to run rhpctl verb image commands.

  • GH_IMG_USER: A role that enables users to create an image using the rhpctl add | import image commands. Users assigned this role do not have administrative privileges and can only delete images that they create.

  • GH_IMG_TESTABLE: A role that enables users to add a working copy of an image that is in the TESTABLE state. Users assigned this role must also be assigned either the GH_WC_ADMIN role or the GH_WC_USER role to add a working copy.

  • GH_IMG_RESTRICT: A role that enables users to add a working copy from an image that is in the RESTRICTED state. Users assigned this role must also be assigned either the GH_WC_ADMIN role or the GH_WC_USER role to add a working copy.

  • GH_IMG_PUBLISH: Users assigned this role can promote an image to another state or retract an image from the PUBLISHED state to either the TESTABLE or RESTRICTED state.

  • GH_IMG_VISIBILITY: Users assigned this role can modify access to promoted or published images using the rhpctl allow | disallow image commands.

  • GH_AUTHENTICATED_USER: Users assigned to this role can execute any operation in an Oracle Fleet Patching and Provisioning Client.

  • GH_CLIENT_ACCESS: Any user created automatically inherits this role. The GH_CLIENT_ACCESS role includes the GH_AUTHENTICATED_USER built-in role.

  • GH_ROOT_UA_CREATE: A role that enables users to create a root user action. Users assigned this role can run the rhpctl add useraction command with the -runasroot option.
  • GH_ROOT_UA_ASSOCIATE: A role that enables users to associate a root user action with the -imagetype option. Users assigned this role can associate an existing root user action to an image type.
  • GH_ROOT_UA_USE: A role that enables users to execute a root user action within the operation selected at user action creation.

Composite Built-In Roles

The composite built-in roles and their functions are:

  • GH_SA: The Oracle Grid Infrastructure user on an Oracle Fleet Patching and Provisioning Server automatically inherits this role.

    The GH_SA role includes the following basic built-in roles: GH_ROLE_ADMIN, GH_SITE_ADMIN, GH_SERIES_ADMIN, GH_SERIES_CONTRIB, GH_WC_ADMIN, GH_IMG_ADMIN, GH_IMG_TESTABLE, GH_IMG_RESTRICT, GH_IMG_PUBLISH, and GH_IMG_VISIBILITY.

  • GH_CA: The Oracle Grid Infrastructure user on an Oracle Fleet Patching and Provisioning Client automatically inherits this role.

    The GH_CA role includes the following basic built-in roles: GH_SERIES_ADMIN, GH_SERIES_CONTRIB, GH_WC_ADMIN, GH_IMG_ADMIN, GH_IMG_TESTABLE, GH_IMG_RESTRICT, GH_IMG_PUBLISH, and GH_IMG_VISIBILITY.

  • GH_OPER: This role includes the following built-in roles: GH_WC_OPER, GH_SERIES_ADMIN, GH_IMG_TESTABLE, GH_IMG_RESTRICT, and GH_IMG_USER. Users assigned this role can delete only images that they have created.

Consider a gold image called G1 that is available on the Oracle Fleet Patching and Provisioning Server.

Further consider that a user, U1, on an Oracle Fleet Patching and Provisioning Client, Cl1, has the GH_WC_USER role. If U1 requests to provision an Oracle home based on the gold image G1, then U1 can do so, because of the permissions granted by the GH_WC_USER role. If U1 requests to delete G1, however, then that request would be denied because the GH_WC_USER role does not have the necessary permissions.

The Oracle Fleet Patching and Provisioning Server can associate user-role mappings to the Oracle Fleet Patching and Provisioning Client. After the Oracle Fleet Patching and Provisioning Server delegates user-role mappings, the Oracle Fleet Patching and Provisioning Client can then modify user-role mappings on the Oracle Fleet Patching and Provisioning Server for all users that belong to the Oracle Fleet Patching and Provisioning Client. This is implied by the fact that only the Oracle Fleet Patching and Provisioning Server qualifies user IDs from an Oracle Fleet Patching and Provisioning Client site with the client cluster name of that site. Thus, the Oracle Fleet Patching and Provisioning Client CL1 will not be able to update user mappings of a user on CL2, where CL2 is the cluster name of a different Oracle Fleet Patching and Provisioning Client.

Oracle Fleet Patching and Provisioning Images

By default, when you create a gold image using either rhpctl import image or rhpctl add image, the image is ready to provision working copies. However, under certain conditions, you may want to restrict access to images and require someone to test or validate the image before making it available for general use.

You can also create a set of gold images on the Oracle Fleet Patching and Provisioning Server that can be collectively categorized as a gold image series which relate to each other, such as identical release versions, gold images published by a particular user, or images for a particular department within an organization.

Gold Image Distribution Among Oracle Fleet Patching and Provisioning Servers

Oracle Fleet Patching and Provisioning can automatically share and synchronize gold images between Oracle Fleet Patching and Provisioning Servers.

In the Oracle Fleet Patching and Provisioning architecture, one Oracle Fleet Patching and Provisioning Server manages a set of Oracle Fleet Patching and Provisioning Clients and targets within a given data center or network segment of a data center. If you have more than one data center or a segmented data center, you must have more than one Oracle Fleet Patching and Provisioning Server.

In the Oracle Fleet Patching and Provisioning architecture, one Oracle Fleet Patching and Provisioning Server manages a set of Oracle Fleet Patching and Provisioning Clients and targets within a given data center or network segment of a data center. If you have more than one data center or a segmented data center, then you must have more than one Oracle Fleet Patching and Provisioning Server to facilitate large-scale standardization across multiple estates.

Oracle Fleet Patching and Provisioning Servers retain the ability to create and manage gold images private to their scope, so local customizations are seamlessly supported.

You must first establish a peer relationship between two Oracle Fleet Patching and Provisioning Servers. Registration uses the names of the Oracle Fleet Patching and Provisioning Server clusters. The names of the two clusters can be the same but there is one naming restriction: an Oracle Fleet Patching and Provisioning Server, such as FPPS_1, cannot register a peer Oracle Fleet Patching and Provisioning Server if that peer has the same name as an Oracle Fleet Patching and Provisioning Client or target within the management domain of FPPS_1.

The following steps show how you can establish a peer relationship between two Oracle Fleet Patching and Provisioning Servers. Note that super user or root credentials are not required in this process.

  1. On the first Oracle Fleet Patching and Provisioning Server (FPPS_1), create a file containing the server configuration information.
    $ rhpctl export server -serverdata file_path
  2. Copy the server configuration file created on FPPS_1 to a second Oracle Fleet Patching and Provisioning Server (FPPS_2).
  3. On the second Oracle Fleet Patching and Provisioning Server (FPPS_2), complete the registration of FPPS_2.
    $ rhpctl register server -server FPPS_1_cluster_name 
        -serverdata server_cfg_file_copied_from_FPPS_1 
  4. On FPPS_2, create a file containing the server configuration information.
    $ rhpctl export server -serverdata file_path
  5. Copy the server configuration file created on FPPS_2 to FPPS_1.
  6. On the first Oracle Fleet Patching and Provisioning Server (FPPS_1), complete the registration ofFPPS_1.
    $ rhpctl register server -server FPPS_2_cluster_name 
        -serverdata server_cfg_file_copied_from_FPPS_2 
After you register an Oracle Fleet Patching and Provisioning Server as a peer, the following command displays the peer (or peers) of the server:
$ rhpctl query peerserver
You can inspect the images on a peer Oracle Fleet Patching and Provisioning Server, as follows:
$ rhpctl query image -server server_cluster_name

The preceding command displays all images on a specific peer Oracle Fleet Patching and Provisioning Server. Additionally, you can specify a peer server along with the -image image_name parameter to display details of a specific image on a specific peer server.

An Oracle Fleet Patching and Provisioning Server can have multiple peers. Oracle does not support chained relationships between peers, however, such as, if FPPS_1 is a peer of FPPS_2, and FPPS_2 is also a peer of FPPS_3, then no relationship is established or implied between FPPS_1 and FPPS_3, although you can make them peers if you want.

Retrieve a copy or copies of gold images from a peer Oracle Fleet Patching and Provisioning Server, as follows:
$ rhpctl instantiate image -server server_cluster_name
Running the rhpctl instantiate image command activates an auto-update mechanism. From that point on, when you create gold images on a peer Oracle Fleet Patching and Provisioning Server, such as FPPS_2, they are candidates for being automatically copied to the Oracle Fleet Patching and Provisioning Server that performed the instantiate operation, such as FPPS_1. Whether a new gold image is automatically copied depends on that relevance of the image to any instantiate parameters that you may include in the command:
  • -all: Creates an automatic push for all gold images created on FPPS_2 to FPPS_1

  • -image image_name: Creates an automatic push for all new descendant gold images of the named image created on FPPS_2 to FPPS_1. A descendant of the named image is an image that is created on FPPS_2 using the rhpctl add image command.

  • -series series_name: Creates an automatic push for all gold images added to the named series on FPPS_2 to FPPS_1

  • -imagetype image_type: Creates an automatic push for all gold images created of the named image type on FPPS_2 to FPPS_1

To stop receiving updates that were established by the rhpctl instantiate image command, run rhpctl uninstantiate image and specify the peer Oracle Fleet Patching and Provisioning Server and one of the following: all, image name, image series name, or image type.

End the peer relationship, as follows, on any one of the Oracle Fleet Patching and Provisioning Servers:
$ rhpctl unregister server -server server_cluster_name

Oracle Fleet Patching and Provisioning Server Auditing

The Oracle Fleet Patching and Provisioning Server records the execution of all Oracle Fleet Patching and Provisioning operations, and also records whether those operations succeeded or failed.

An audit mechanism enables administrators to query the audit log in a variety of dimensions, and also to manage its contents and size.

Oracle Fleet Patching and Provisioning Notifications

The Oracle Fleet Patching and Provisioning Server is the central repository for the software homes available to the data center. Therefore, it is essential for administrators throughout the data center to be aware of changes to the inventory that may impact their areas of responsibility.

You can create subscriptions to image series events. Oracle Fleet Patching and Provisioning notifies a subscribed role or number of users by email of any changes to the images available in the series, including addition or removal of an image. Each series may have a unique group of subscribers.

Also, when a working copy of a gold image is added to or deleted from a target, the owner of the working copy and any additional users can be notified by email. If you want to enable notifications for additional Oracle Fleet Patching and Provisioning events, you can create a user-defined action as described in the next section.

Oracle Fleet Patching and Provisioning Implementation

Implementing Oracle Fleet Patching and Provisioning involves creating an Oracle Fleet Patching and Provisioning Server, adding gold images to the server, and creating working copies of gold images to provision software.

After you install and configure Oracle Clusterware, you can configure and start using Oracle Fleet Patching and Provisioning. You must create an Oracle Fleet Patching and Provisioning Server where you create and store gold images of database and other software homes.

Creating a Fleet Patching and Provisioning Server

The Fleet Patching and Provisioning Server uses a repository that you create in an Oracle ACFS file system in which you store all the software homes that you want to make available to clients and targets.

To create a Fleet Patching and Provisioning Server:

  1. Use the Oracle ASM configuration assistant (ASMCA) to create an Oracle ASM disk group on the Fleet Patching and Provisioning Server to store software, as follows:
    $ Grid_home/bin/asmca

    Because this disk group is used to store software, Oracle recommends a minimum of 50 GB for this disk group.

    Note:

    You must set Oracle ASM Dynamic Volume Manager (Oracle ADVM) compatibility settings for this disk group to 12.1.

  2. Provide a mount path that exists on all nodes of the cluster. The Fleet Patching and Provisioning Server uses this path to mount gold images.
    $ mkdir -p storage_path/images
  3. As root, create the Fleet Patching and Provisioning Server resource, as follows:
    # Grid_home/bin/srvctl add rhpserver -storage storage_path
        -diskgroup disk_group_name
  4. Start the Fleet Patching and Provisioning Server, as follows:
    $ Grid_home/bin/srvctl start rhpserver

After you start the Fleet Patching and Provisioning Server, use the Fleet Patching and Provisioning Control (RHPCTL) utility to further manage Fleet Patching and Provisioning.

Adding Gold Images to the Fleet Patching and Provisioning Server

Use RHPCTL to add gold images for later provisioning of software.

The Fleet Patching and Provisioning Server stores and serves gold images of software homes. These images must be instantiated on the Fleet Patching and Provisioning Server.

Note:

Images are read-only, and you cannot run programs from them. To create a usable software home from an image, you must create a working copy of a gold image. You cannot directly use images as software homes. You can, however, use images to create working copies (software homes).

You can import software to the Fleet Patching and Provisioning Server using any one of the following methods:

  • You can import an image from an installed home on the Fleet Patching and Provisioning Server using the following command:

    rhpctl import image -image image_name -path path_to_installed_home
      [-imagetype ORACLEDBSOFTWARE | ORACLEGISOFTWARE | ORACLEGGSOFTWARE | SOFTWARE]
    

    ORACLEDBSOFTWARE is the default if -imagetype is not specified.

  • You can import an image from an installed home on a Fleet Patching and Provisioning Client, using the following command run from the Fleet Patching and Provisioning Client:

    rhpctl import image -image image_name -path path_to_installed_home
    
  • You can create an image from an existing working copy using the following command:

    rhpctl add image -image image_name -workingcopy working_copy_name
    

Use the first two commands in the preceding list to seed the image repository, and to add additional images over time. Use the third command on the Oracle Fleet Patching and Provisioning Server as part of the workflow for creating a gold image that includes patches applied to a pre-existing gold image.

The preceding three commands also create an Oracle ACFS file system in the Oracle Fleet Patching and Provisioning root directory, similar to the following:

/u01/rhp/images/images/RDBMS_121020617524
Image State

You can set the state of an image to TESTABLE or RESTRICTED so that only users with the GH_IMG_TESTABLE or GH_IMG_RESTRICT roles can provision working copies from this image. Once the image has been tested or validated, you can change the state and make the image available for general use by running the rhpctl promote image -image image_name -state PUBLISHED command. The default image state is PUBLISHED when you add a new gold image, but you can optionally specify a different state with the rhpctl add image and rhpctl import image commands.

Image Series

An image series is a convenient way to group different gold images into a logical sequence.

Fleet Patching and Provisioning treats each image as an independent entity with respect to other images. No relationship is assumed between images, even if they follow some specific nomenclature. The image administrator may choose to name images in a logical manner that makes sense to the user community, but this does not create any management grouping within the Fleet Patching and Provisioning framework.

Use the rhpctl add series command to create an image series and associate one or more images to this series. The list of images in an image series is an ordered list. Use the rhpctl insertimage series and rhpctl deleteimage series to add and delete images in an image series. You can also change the order of images in a series using these commands.

The insertimage and deleteimage commands do not instantiate or delete actual gold images but only change the list. Also, an image can belong to more than one series (or no series at all).

Image Type

When you add or import a gold image, you must specify an image type.

Oracle Clusterware provides the following built-in base image types:
  • ORACLEDBSOFTWARE
  • ORACLEGISOFTWARE
  • ORACLEGGSOFTWARE
  • SOFTWARE

Every gold image must have an image type, and you can create your own image types. A new image type must be based on one of the built-in types. The image type directs Fleet Patching and Provisioning to apply its capabilities for managing Oracle Grid Infrastructure and Oracle Database homes. Fleet Patching and Provisioning also uses image type to organize the custom workflow support framework.

Creating a Custom Image Type

Use the rhpctl add imagetype command to create custom image types.

For example, to create an image type called DBTEST, which is based on the ORACLEDBSOFTWARE image type:

$ rhpctl add imagetype -imagetype DBTEST -basetype ORACLEDBSOFTWARE

Note:

When you create an image type that is based on an existing image type, the new image type does not inherit any user actions (for custom workflow support) from the base type.

Provisioning Copies of Gold Images

Use RHPCTL to provision copies of gold images to Fleet Patching and Provisioning Servers, Clients, and targets.

After you create and import a gold image, you can provision software by adding a copy of the gold image (called a working copy) on the Fleet Patching and Provisioning Server, on a Fleet Patching and Provisioning Client, or a target. You can run the software provisioning command on either the Server or a Client.

  • To create a working copy on the Fleet Patching and Provisioning Server:
    $ rhpctl add workingcopy -workingcopy working_copy_name -image image_name
    
  • To create a working copy in a local file system on a Fleet Patching and Provisioning Client:
    $ rhpctl add workingcopy -workingcopy working_copy_name -image image_name
       -storagetype LOCAL -path path_to_software_home
  • To create a working copy on a Fleet Patching and Provisioning Client from the Fleet Patching and Provisioning Server:
    $ rhpctl add workingcopy -workingcopy working_copy_name -image image_name
       -client client_cluster_name

Note:

  • The directory you specify in the -path parameter must be empty.

  • You can re-run the provisioning command in case of an interruption or failure due to system or user errors. After you fix the reported errors, re-run the command and it will resume from the point of failure.

User Group Management in Fleet Patching and Provisioning

When you create a working copy of a gold image as part of a move or upgrade operation, Fleet Patching and Provisioning configures the operating system groups in the new working copy to match those of the source software home.

These operating system groups are used for operating system authentication, such as OSDBA and OSOPER. Oracle FPP configures operating system groups for both unmanaged and managed software homes from which you move or upgrade.

When you create a gold image of SOFTWARE image type, any user groups in the source are not inherited and images of this type never contain user group information. When you provision a working copy from a SOFTWARE gold image using the rhpctl add workingcopy command, you can, optionally, configure user groups in the working copy using the -groups parameter.

The rhpctl move database, rhpctl move gihome, rhpctl upgrade database, and rhpctl upgrade gihome commands all require you to specify a source home (either an unmanaged home or a managed home (working copy) that you provisioned using Fleet Patching and Provisioning), and a destination home (which must be a working copy).

When you have provisioned the destination home using the rhpctl add workingcopy command, prior to performing a move or upgrade operation, you must ensure that the groups configured in the source home match those in the destination home. Fleet Patching and Provisioning configures the groups as part of the add operation.

When you create a gold image of either the ORACLEGISOFTWARE or the ORACLEDBSOFTWARE image type from a source software home (using the rhpctl import image command) or from a working copy (using the rhpctl add image command), the gold image inherits the Oracle user groups that were configured in the source. You cannot override this feature.

You can define user groups for ORACLEGISOFTWARE and ORACLEDBSOFTWARE working copies using the rhpctl add workingcopy command, depending on the image type and user group, as discussed in the subsequent sections.

This section describes how Fleet Patching and Provisioning manages user group configuration, and how the -groups command-line option of rhpctl add workingcopy functions.

ORACLEGISOFTWARE (Oracle Grid Infrastructure 11g release 2 (11.2), and 12c release 1 (12.1) and release 2 (12.2))

When you provision an Oracle Grid Infrastructure working copy of a gold image, the groups are set in the working copy according to the type of provisioning (whether regular provisioning or software only, and with or without the -local parameter), and whether you specify the -groups parameter with rhpctl add workingcopy. You can define OSDBA and OSASM user groups in Oracle Grid Infrastructure software with either the -softwareonly command parameter or by using a response file with the rhpctl add workingcopy command.

If you are provisioning only the Oracle Grid Infrastructure software using the -softwareonly command parameter, then you cannot use the -groups parameter, and Fleet Patching and Provisioning obtains OSDBA and OSASM user group information from the active Grid home.

If you use the -local command parameter (which is only valid when you use the -softwareonly command parameter) with rhpctl add workingcopy, then Fleet Patching and Provisioning takes the values of the groups from the command line (using the -groups parameter) or uses the default values, which Fleet Patching and Provisioning obtains from the osdbagrp binary of the gold image.

If none of the preceding applies, then Fleet Patching and Provisioning uses the installer default user group.

If you are provisioning and configuring a working copy using information from a response file, then Fleet Patching and Provisioning:
  1. Uses the value of the user group from the command line, if provided, for OSDBA or OSASM, or both.

  2. If you provide no value on the command line, then Fleet Patching and Provisioning retrieves the user group information defined in the response file.

If you are defining the OSOPER Oracle group, then, again, you can either use the -softwareonly command parameter or use a response file with the rhpctl add workingcopy command.

If you use the -softwareonly command parameter, then you can provide the value on the command line (using the -groups parameter) or leave the user group undefined.

If you are provisioning and configuring a working copy of a gold image using information from a response file, then you can provide the value on the command line, use the information contained in the response file, or leave the OSOPER Oracle group undefined.

ORACLEDBSOFTWARE (Oracle Database 11g release 2 (11.2), and 12c release 1 (12.1) and release 2 (12.2))

If you are provisioning a working copy of Oracle Database software and you want to define Oracle groups, then use the -groups command parameter with the rhpctl add workingcopy command. Oracle groups available in the various Oracle Database releases are as follows:

  • Oracle Database 11g release 2 (11.2)

    • OSDBA
    • OSOPER
  • Oracle Database 12c release 1 (12.1)

    • OSDBA
    • OSOPER
    • OSBACKUP
    • OSDG
    • OSKM
  • Oracle Database 12c release 2 (12.2) and later

    • OSDBA
    • OSOPER
    • OSBACKUP
    • OSDG
    • OSKM
    • OSRAC

Regardless of which of the preceding groups you are defining (except for OSOPER), Fleet Patching and Provisioning takes the values of the groups from the command line (using the -groups parameter) or uses the default values, which Fleet Patching and Provisioning obtains from the osdbagrp binary of the gold image.

If any group picked up from the osdbagrp binary is not in the list of groups to which the database user belongs (given by the id command), then Fleet Patching and Provisioning uses the installer default user group. Otherwise, the database user is the user running the rhpctl add workingcopy command.

Storage Options for Provisioned Software

Choose one of three storage options where Fleet Patching and Provisioning stores working copies of gold images.

When you provision software using the rhpctl add workingcopy command, you can choose from three storage options where Fleet Patching and Provisioning places that software:

  • In an Oracle ACFS shared file system managed by Fleet Patching and Provisioning (for database homes only)

  • In a local file system not managed by Fleet Patching and Provisioning

Using the rhpctl add workingcopy command with the -storagetype and -path parameters, you can choose where you store provisioned working copies. The applicability of the parameters depends on whether the node (or nodes) to which you are provisioning the working copy is a Fleet Patching and Provisioning Server, Fleet Patching and Provisioning Client, or a non-Fleet Patching and Provisioning client. You can choose from the following values for the -stroragetype parameter:

  • RHP_MANAGED: Choosing this value, which is available for Fleet Patching and Provisioning Servers and Fleet Patching and Provisioning Clients, stores working copies in an Oracle ACFS shared file system. The -path parameter is not used with this option because Fleet Patching and Provisioning manages the storage option.

    Notes:

    • You cannot store Oracle Grid Infrastructure homes in RHP_MANAGED storage.

    • Oracle recommends using the RHP_MANAGED storage type, which is available on Fleet Patching and Provisioning Servers, and on Clients configured with an Oracle ASM disk group.

    • If you provision working copies on a Fleet Patching and Provisioning Server, then you do not need to specify the -storagetype option because it will default to RHP_MANAGED.

    • If you choose to provision working copies on a Fleet Patching and Provisioning Client, and you do not specify the -path parameter, then the storage type defaults to RHP_MANAGED only if there is an Oracle ASM disk group on the client. Otherwise the command will fail. If you specify a location on the client for the -path parameter, then the storage type defaults to LOCAL with or without an Oracle ASM disk group.

  • LOCAL: Choosing this value stores working copies in a local file system that is not managed by Fleet Patching and Provisioning.

    When adding a database working copy, specifying a path is optional. If a path is not specified, then a path under ORACLE_BASE is automatically chosen. This path is displayed on the terminal.

In cases where you specify the -path parameter, if the file system is shared among all of the nodes in the cluster, then the working copy gets created on this shared storage. If the file system is not shared, then the working copy gets created in the location of the given path on every node in the cluster.

Note:

The directory you specify in the -path parameter must be empty.

Related Topics

Provisioning for a Different User

If you want a different user to provision software other than the user running the command, then use the -user parameter of the rhpctl add workingcopy command.

Note:

The default user is the user as which the RHPCTL command is being run.

When the provisioning is completed, all files and directories of the provisioned software are owned by the user you specified. Permissions on files on the remotely provisioned software are the same as the permissions that existed on the gold image from where you provisioned the application software.

Propagating Images Between Fleet Patching and Provisioning Servers

With automatic image propagation, you can set up automated copies of software images across different peer Fleet Patching and Provisioning Servers. Gold images that you register at one site are copied to peer Fleet Patching and Provisioning Servers.

In a peer-to-peer relationship between two Oracle Fleet Patching and Provisioning Servers, one server is the source for software images and the other is the destination for software images.

The criteria for copying software images between servers can be based on certain policies, such as software image type, image series, or all software images. When you register an image that meets the criteria for software image propagation, a copy of this image propagates to all registered peer servers.

The following example procedure establishes a relationship between two Fleet Patching and Provisioning Server sites, FPPS-A and FPPS-B, where FPPS-A is the source and FPPS-B is the destination for software images.

  1. Run the following command on FPPS-B:
    $ rhpctl export server -server FPPS-A -serverdata file_path

    The preceding command creates a file named FPPS-B.xml in the directory path you specify for the -serverdata parameter.

  2. Run the following command to register a peer server to the current Fleet Patching and Provisioning Server:
    $ rhpctl register server -server FPPS-B -serverdata /tmp/FPPS-B.xml

    The preceding command copies the FPPS-B.xml file that was created in the previous step to a location on the server where you run the command, which is /tmp/FPPS-B.xml, in this case.

    The cluster in which you run the preceding command is the source site, and the server that you specify on the command line is the destination site to which software images are copied.

    Use the rhpctl unregister server command to remove the peer-to-peer relationship.

  3. Run the following command on FPPS-B to propagate software images from FPPS-A to FPPS-B:
    $ rhpctl instantiate image -server FPPS-A  -all

    The preceding command propagates all images from FPPS-A to FPPS-B. If an image already exists on FPPS-B, then it is not propagated again.

    Note:

    Propagation of images is based on the image name. RHPCTL does not compare the content of the images to determine whether they are different. If an image you want to propagate has a non-unique name, then RHPCTL assumes that the images are identical and does not propagate the image.

    The image propagation is anyshncronous and the propagation may not be immediate. You can check using rhpctl query image on the target.

    Use the rhpctl uninstantiate image command to cancel the propagation of a particular image. Any propagation already in progress is not affected by this command, and will continue until complete. The -all parameter removes any values for the -imagetype and -series parameters.