AHF 26.9 Upgrade on RAC: Fixing a Remote Node SSH Failure

Alhamdulillah. I recently upgraded Oracle AHF from 26.5.1.0.0 to 26.9.0.0.0 on a two-node RAC. Node 1 upgraded cleanly. Node 2 failed because the installer couldn’t authenticate over SSH as root. Here’s what happened and how I finished the job with a local upgrade.

Hostnames and client-specific details are omitted.

Environment

  • Platform: Linux x86-64
  • Setup: two-node Oracle RAC
  • Initial AHF version: 26.5.1.0.0
  • Target AHF version: 26.9.0.0.0
  • AHF home: /opt/oracle.ahf
  • AHF data directory: <oracle_base>/oracle.ahf/data

The paths in the examples below are placeholders. Replace them with your actual installer and staging directories. Run the signature check and ahf_setup from the extracted installer directory, and run each command with the privileges the target paths require.

The Problem

I launched the cluster-wide installer from Node 1:

cd /path/to/ahf_installer
./ahf_setup

Node 1 upgraded fine. When it moved on to Node 2, the installer kept asking for the root password, then failed:

[ERROR] : [node2] Failed to Upgrade AHF. Exit Status : 255

The summary showed Node 1 on 26.9.0.0.0 and Node 2 still on 26.5.1.0.0. The installer still printed a general success message at the end, even though the cluster was only half upgraded.

Lesson: read the per-node summary. Don’t trust the final success line.

The Fix: Local Upgrade on Node 2

Step 1: Copy and verify the package

I copied the installer ZIP from Node 1 to Node 2 using an approved transfer method, then checked its integrity:

unzip -t AHF-LINUX_v26.9.0.zip
sha256sum AHF-LINUX_v26.9.0.zip

The SHA-256 matched the checksum from the source node.

Step 2: Extract and verify the signature

mkdir -p /path/to/ahf_stage/26.9.0

unzip -o AHF-LINUX_v26.9.0.zip \
  -d /path/to/ahf_stage/26.9.0

cd /path/to/ahf_stage/26.9.0

openssl dgst -sha256 \
  -verify ./oracle-tfa.pub \
  -signature ./ahf_setup.dat \
  ./ahf_setup

Expected output:

Verified OK

Step 3: Run the local upgrade

Oracle’s upgrade guide says to run ahf_setup as root. My account had authorized sudo privileges, so I ran the installer locally with sudo:

sudo ./ahf_setup -local

The installer detected the existing AHF installation and prompted for confirmation. The local upgrade completed successfully. Its final summary reported both Node 2 and Node 1 at AHF version 26.9.0.0.0 with status UPGRADED. I then verified the version and TFA status from both nodes.

Step 4: Verify on both nodes

sudo /opt/oracle.ahf/bin/tfactl version
sudo /opt/oracle.ahf/bin/tfactl status

Results on both nodes:

  • AHF version: 26.9.0.0.0
  • Matching build ID: 260900020260911121902
  • TFA status: RUNNING
  • Inventory status: COMPLETE
  • No version mismatch between nodes

Observed Failure

The installer couldn’t authenticate as root over SSH to the remote node. Oracle documents secure daemon socket communication for upgrading an existing AHF cluster; in this case, the installer nevertheless prompted for root SSH authentication.

My logs show the immediate failure: the root SSH authentication attempt failed. They don’t show why the installer took that path or why the authentication failed, and I didn’t dig into it further.

Best Practices

  • Confirm the target version and compatibility before you start.
  • Verify the installer checksum and signature before running it.
  • Run the installer as root, or with sudo if your account is authorized.
  • Confirm the required privileges and cluster communication prerequisites before upgrading. If unexpected SSH authentication prompts occur, investigate the issue rather than changing SSH settings without approval.
  • If remote authentication fails, use the documented local-upgrade procedure. Don’t make unapproved SSH or security changes.
  • Check the per-node summary and TFA status on every node.
  • Keep the installer logs and record the final version and build ID for change management.

Conclusion

ما شاء الله, both RAC nodes are now on AHF 26.9.0.0.0. The takeaway: a success message from the installer doesn’t guarantee every node was upgraded. Check each node’s status and confirm TFA is running before you close the change.

Always follow the Oracle documentation and your organization’s change-management process for production work.

References


Discover more from Syed Anwar Ahmed – Oracle DBA Blog

Subscribe to get the latest posts sent to your email.

Comments

Leave a Reply

Discover more from Syed Anwar Ahmed – Oracle DBA Blog

Subscribe now to keep reading and get access to the full archive.

Continue reading