Fleet Patching and Provisioning Postinstallation Tasks

Authentication Options for Oracle Fleet Patching and Provisioning Operations

Authentication is handled automatically between trusted Oracle Fleet Patching and Provisioning Servers and Clients, except when provisioning a new Grid Infrastructure deployment before the client exists. Operations on client-less targets require root or sudo credentials supplied interactively, from an encrypted store, through stored credentials, or by SSH key. Passwordless SSH requires user equivalence between the server’s crsusr account and root or a privileged target user, with authentication parameters specifying the user, identity file, and optionally the sudo binary.

Read More: Authentication Options for Oracle Fleet Patching and Provisioning Operations

Oracle Fleet Patching and Provisioning Roles

Oracle Fleet Patching and Provisioning uses built-in roles to control permissions for role, client, series, image, working-copy, root-user-action, and general client operations. Composite roles such as GH_SA, GH_CA, and GH_OPER combine multiple basic roles for server administrators, client administrators, and operators. Permissions determine which resources users can create, modify, provision, or delete, and client-specific user-role mappings are scoped by client cluster. Users and roles can be assigned during client creation or managed afterward with grant and revoke commands; the maproles option is deprecated beginning with Oracle Grid Infrastructure 21c.

Read More: Oracle Fleet Patching and Provisioning Roles

Managing the Fleet Patching and Provisioning Client Password

The Fleet Patching and Provisioning Client password is stored internally and cannot be queried. To reset it, an administrator generates a new password on the server, exports updated client credentials to a file, securely transfers the file to the client cluster, updates the client with the credential data, and restarts the client daemon so the new authentication information takes effect.

Read More: Managing the Fleet Patching and Provisioning Client Password

Switching Oracle FPP Server to a New Custom Certificate

Replacing or updating the Oracle Fleet Patching and Provisioning Server certificate temporarily breaks server-client communication. The procedure requires generating a PKCS#12 file, configuring and restarting the server with the new certificate, exporting updated client credentials, securely transferring them to each client, updating client certificate and server-key information, restarting the clients, and verifying connectivity with rhpctl query server. The process must be repeated for every client cluster, and custom certificates are optional on individual clients.

Read More: Switching Oracle FPP Server to a New Custom Certificate

Switching Oracle FPP Client to a New Custom Certificate

To replace an Oracle Fleet Patching and Provisioning Client certificate, first verify connectivity, generate a PKCS#12 certificate file, configure the client with the new certificate, and restart it. Export the server’s client credential data, securely copy it to the client, update the client’s stored server public key, restart the client, and verify communication. The procedure can be repeated for other clients, and custom certificates need not be used consistently across all clients and the server.

Read More: Switching Oracle FPP Client to a New Custom Certificate

Oracle Fleet Patching and Provisioning Server Auditing

The Oracle Fleet Patching and Provisioning Server audits all operations, recording their processing details and whether they succeeded or failed. Administrators can query audit records across different dimensions and manage the audit log’s contents and size.

Read More: Oracle Fleet Patching and Provisioning Server Auditing

User-Defined Actions

User-defined shell scripts can run before or after operations such as image import, working-copy management, database changes, and Grid Infrastructure or software-home updates on servers, clients, or client-less targets. Actions are stored on the server, receive operation context through named parameters, and can optionally transfer associated files to the execution target. Image types can distinguish actions for different software releases, with base-type actions running before derived image-type actions. Administrators can create, modify, associate, and remove actions, control failure behavior and execution scope, and pass custom data through the user-action parameter.

Read More: User-Defined Actions

Oracle Fleet Patching and Provisioning Notifications

Oracle Fleet Patching and Provisioning supports email subscriptions for image-series events, including image additions and removals, with separate subscriber groups for each series. Notifications can also inform working-copy owners and additional users when working copies are added to or deleted from client-less targets. Further event notifications can be implemented through user-defined actions.

Read More: Oracle Fleet Patching and Provisioning Notifications

Job Scheduler for Operations

The Oracle Fleet Patching and Provisioning job scheduler queues supported operations for immediate or scheduled execution, stores job metadata and logs, and supports querying, deletion, role-based authorization, and, from Grid Infrastructure 26ai, pausing and resuming jobs. Scheduling uses a timer or PAUSE value and applies the server’s time zone with ISO-8601 timestamps. Jobs receive unique identifiers and progress through states including TIMER_RUNNING, EXECUTING, EXECUTED, UNKNOWN, TERMINATED, or PAUSED; paused jobs can be resumed after prerequisite validation.

Read More: Job Scheduler for Operations

Patching Oracle Grid Infrastructure and Oracle AI Database Using Batches

Fleet Patching and Provisioning supports rolling patching by restarting groups of cluster nodes in batches, maximizing service availability. Administrators can specify batches and advance through them with continue, skip, revert, or abort options, or allow smartmove to generate batches based on service placement and a specified service availability factor. Evaluation mode previews automatically generated batches without making changes. The same sequential batching approach applies to Oracle AI Database patching, while failures can be retried, skipped, reverted, or left for manual recovery when aborted.

Read More: Patching Oracle Grid Infrastructure and Oracle AI Database Using Batches

Combined Oracle Exadata Database Server and Grid Infrastructure Update

Combined patching integrates Exadata database-node updates with Grid Infrastructure home moves so each node requires only one database shutdown and startup sequence, reducing downtime. Administrators import an Exadata update image, deploy it to the target, and run move gihome with Exadata image, batch, ISO repository, and patch-manager parameters. Fleet Patching and Provisioning invokes patchmgr for database-node updates before Grid Infrastructure patching, can process nodes in parallel within batches, and allows operations to resume after patch-manager failures or timeouts.

Read More: Combined Oracle Exadata Database Server and Grid Infrastructure Update

Gold Image Distribution Among Oracle Fleet Patching and Provisioning Servers

Oracle Fleet Patching and Provisioning Servers can share gold images through peer relationships and image instantiation. Administrators export and exchange server configuration files, register each server as a peer, verify the relationship, and configure replication for all images or selected images, series, or image types. Replicated images can be queried and automatic synchronization can be stopped with uninstantiate; unregistering a peer ends replication but preserves images already instantiated. Peer relationships are not transitive, and each server can maintain multiple independent peers.

Read More: Gold Image Distribution Among Oracle Fleet Patching and Provisioning Servers

Error Prevention and Automated Recovery Options

The eval option performs prerequisite checks and predicts configuration effects without changing the environment, allowing administrators to validate operations before a maintenance window. For in-flight move failures, administrators can correct the cause and rerun the command, revert to the initial state, or abort while leaving the environment partially changed for manual recovery. Post-update issues can be addressed by reversing the source and destination homes in a new move operation, subject to managed and unmanaged home requirements.

Read More: Error Prevention and Automated Recovery Options

Fleet Patching and Provisioning Logs and Trace Files

Oracle Fleet Patching and Provisioning diagnostics rely on server logs, helper logs, Java application-server output, Grid Infrastructure and CRSD traces, and database deployment or upgrade logs. These files provide details for troubleshooting server, client, startup, shutdown, deployment, and upgrade failures. Trace File Analyzer can collect the relevant Fleet Patching and Provisioning diagnostics with the rhp option.
Read More: Fleet Patching and Provisioning Logs and Trace Files