Oracle FPP Server Setup: Gold Image → Working Copy → Patched Baseline (Step-by-Step)

ORACLE DATABASE ADMINISTRATION

Configuring an Oracle Fleet Patching and Provisioning (FPP) Server

A Practical, Step-by-Step Field Guide

Munish Kumar Karna  |  Senior Database Solution Architect & Oracle DBA

 

Why This Matters

Oracle Fleet Patching and Provisioning (FPP) — formerly Rapid Home Provisioning (RHP) — is Oracle's framework for standardizing how Grid Infrastructure and database homes are imaged, distributed, and patched across a fleet of servers. Instead of patching each node manually, a certified FPP Server lets you build a validated 'gold image,' clone it into working copies, apply interim patches once, and roll the updated image out consistently — cutting patching effort and risk across large estates.

Below is a condensed walkthrough of standing up an FPP Server, importing a Grid Infrastructure 23ai gold image, applying a patch bundle to a working copy, and re-publishing it as a new certified image — based on a hands-on build I recently completed.

Prerequisites

•     Oracle Grid Infrastructure already installed and the cluster healthy.

•     A dedicated ASM disk group provisioned for the FPP repository and image store.

•     Any existing FPP "local mode" configuration removed from the cluster.

•     Sufficient swap space, staging disk, and network connectivity between fleet nodes.

STEP 1  Remove Any Existing Local-Mode FPP Configuration

Stop and remove any pre-existing rhpserver resource before reconfiguring:

[root@fleet ~]# srvctl stop rhpserver
[root@fleet ~]# srvctl remove rhpserver

STEP 2  Configure the Internal Metadata Repository

FPP stores its metadata in a dedicated repository database (here, PDB "PDBREPO" inside CDB "repo"), administrator-managed and running on the ASM disk group reserved for OCR/FPP:

[oracle@fleet ~]$ srvctl config database -d repo
Database unique name: repo
Oracle home: /u01/app/oracle/product/26.0.0/dbhome_1
Disk Groups: OCR
Database role: PRIMARY   Management policy: AUTOMATIC

[oracle@fleet ~]$ srvctl config pdb -db repo
Pluggable database name: PDBREPO
Pluggable database PDBREPO is enabled.

STEP 3  Create and Start the FPP Server Resource

[root@fleet ~]# srvctl add rhpserver \
  -storage /rhp_repo \
  -diskgroup FLEETDATA \
  -dbtype EXTERNAL \
  -connstr "fleet:1521/pdbrepo" \
  -dbadmin sys

[root@fleet ~]# srvctl start rhpserver
[root@fleet ~]# srvctl status rhpserver
Rapid Home Provisioning Server is enabled
Rapid Home Provisioning Server is running on node fleet

Note: The repository disk group, connect string, and OS credentials must all be validated before this step — a failed rhpserver start is almost always traced back to repository connectivity.

STEP 4  Import and Verify the Gold Image

A Grid Infrastructure software ZIP is imported as a named, versioned "gold image" that all working copies will be cloned from:

[oracle@fleet ~]$ rhpctl import image -image GI_23_26_2_GOLD \
  -zip /home/oracle/23.26.2GoldImage/Grid/p39099896_230000_Linux-x86-64.zip \
  -imagetype ORACLEGISOFTWARE

fleet.localdomain: Successfully executed clone operation.
'DetachHome' was successful.

⏱  Executed: Mon 10 Aug 2026, 11:51 AM  (from DetachHome install log)

[oracle@fleet ~]$ rhpctl query image -image GI_23_26_2_GOLD
Image name: GI_23_26_2_GOLD
Image state: PUBLISHED
Image size: 2774 Megabytes
Image Version: 23.0.0.0.0:23.26.2.0.0
Complete: TRUE

STEP 5  Configure Passwordless SSH

FPP orchestration relies on key-based SSH between the FPP server and target nodes:

[oracle@fleet ~]$ ssh-keygen -t rsa -N "" -f ~/.ssh/id_rsa
[oracle@fleet ~]$ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
[oracle@fleet ~]$ chmod 700 ~/.ssh
[oracle@fleet ~]$ chmod 600 ~/.ssh/authorized_keys

[oracle@fleet ~]$ ssh fleet date
Mon Aug 10 12:16:50 +0545 2026

⏱  Executed: Mon 10 Aug 2026, 12:14–12:16 PM (+0545)

STEP 6  Provision a Working Copy from the Gold Image

[oracle@fleet ~]$ rhpctl add workingcopy -image GI_23_26_2_GOLD \
  -workingcopy GI_23_26_wc \
  -path /rhp_repo/workingcopies/GI_23_26_wc \
  -softwareonly

fleet.localdomain: Oracle home provisioned.
fleet.localdomain: Working copy creation completed.

STEP 7  Validate Prerequisites and Apply the Patch Bundle

Before applying, every interim patch is checked for conflicts against the working-copy Oracle home using OPatch's prereq check, then applied in sequence:

[oracle@fleet 39568945]$ $ORACLE_HOME/OPatch/opatch prereq \
  CheckConflictAgainstOHWithDetail -phBaseDir .../39578879
Prereq "checkConflictAgainstOHWithDetail" passed.
Log file: opatch2026-08-10_14-10-47PM_1.log

[oracle@fleet 39568945]$ $ORACLE_HOME/OPatch/opatch apply \
  /u01/app/patches/PatchOracleGI23.26.3/39568945/39578879
...
Patch 39578879 successfully applied.
Log file: opatch2026-08-10_14-16-57PM_1.log

⏱  Executed: Mon 10 Aug 2026, 14:10–14:37 PM  (~27 min, 5 patches)

This was repeated for each interim patch in the January 2026 GI bundle (39578879, 39578865, 39578862, 39578859, 39578856) — each super-set patch cleanly superseding an existing sub-set patch already in the image. OPatch's own log timestamps show the full prereq-check-to-apply cycle for all five patches completed in under 30 minutes:

Patch ID	Prereq Check	Applied
39578879	14:10:47 PM	14:16:57 PM
39578865	14:11:19 PM	14:21:48 PM
39578862	14:11:33 PM	14:34:52 PM
39578859	14:11:48 PM	14:36:12 PM
39578856	14:12:04 PM	14:37:46 PM

 

STEP 8  Re-image the Patched Working Copy

Once verified, the fully patched working copy is captured back into a new, immutable gold image — ready to be distributed as the fleet's next certified baseline:

[oracle@fleet ~]$ rhpctl import image -image GI_23_26_3_GOLD \
  -path /rhp_repo/workingcopies/GI_23_26_wc \
  -imagetype ORACLEGISOFTWARE

[oracle@fleet ~]$ rhpctl query image -image GI_23_26_3_GOLD
Image name: GI_23_26_3_GOLD
Image state: PUBLISHED
Image size: 5700 Megabytes
Image Version: 23.26.3.0.0:23.26.3.0.0
Interim patches installed: 39578856, 39578859, 39578862, 39578865, 39578879
Complete: TRUE

Key Takeaways

•     FPP turns Grid Infrastructure patching from a per-node manual task into a repeatable, image-based workflow.

•     A gold image + working copy model lets you validate a patch once, then roll it out fleet-wide with confidence.

•     Re-capturing a patched working copy as a new gold image keeps the fleet's baseline continuously current.

•     SSH trust, repository health, and OPatch conflict checks are the most common points of failure — validate them early.

 

Munish Kumar Karna — Oracle Certified Professional | RAC · ASM · Data Guard · GoldenGate · OCI