odaconfigcli – The new utility on the block

If you’re managing an Oracle Database Appliance (ODA), then you must be familiar with tools like odacli, oakcli, or even odaadmcli. But there’s one command-line tool that recently popped up on my radar while patching to 19.26 odaconfigcli.

The odaconfigcli utility captures a comprehensive snapshot of your appliance configuration in just one command. Let’s explore this new utility and see how it helps simplify diagnostics and patching prep.

What is odaconfigcli?

The odaconfigcli utility is used to collect a detailed configuration snapshot of an ODA system It is nestled under /opt/oracle/odaconfig/bin and it generates:

• A unified HTML report
• Log bundles for diagnostics
  

odaconfigcli Usage

The core command is simple odaconfigcli collectconfig. The various options with which it can be executed are as follows

odaconfigcli collectconfig [--loc <custom_dir>] [--redact sanitize|mask] [--silent]

This command gathers system information and component metadata, generates JSON files along with an HTML report, and stores the output in a timestamped directory under /opt/oracle/odaconfig/cnr_data. Details about the prerequistes and other notes about the utility can be found here

Customize with JSON

You can extend what odaconfigcli collects by adding custom commands in a JSON file, giving you full control over what gets captured during the run.

For example, if you want to check the permissions on the ASM password files, you can add a command to do so within the ASM Insights section that executes ASM commands.

Note: In this example, I’m specifying a unique output filename, asm_asmcmdpw.out, to capture the output. If the file name is not unique, you risk overwriting previous outputs and losing data.

Additionally, it seems the utility reads the output from these files to generate the corresponding HTML report.

[root@oda]# pwd
/opt/oracle/odaconfig

[root@oda]# ls -l
bin/
customize/   ← custom JSON config here
odaconfig/
scripts/
templates/

## Editing /opt/oracle/odaconfig/customize/commands_output.json
## asm_asmcmdpw.out is the file in which I would want my output saved 

{
  "asm": {
    "name": "ASM Insights",
    "commands": [
...
....
.....
## Append my custom code
      {
        "command": "<TBREPLACED_CRS_HOME>/bin/asmcmd ls -l --permission +DATA/*/PASSWORD",
        "filename": "asm_asmcmdpw.out"
      }
    ]
  }
}

Sample Report

I tested odaconfigcli with both redaction modes: sanitize & mask, and noticed a couple of minor issues with redaction.

• Underscore in Attributes: If any attribute contains an underscore, the redaction doesn’t mask the part after the underscore. For example, db_boston will be redacted as tf_boston, leaving the latter part exposed.

• ODA System Name: The redaction process doesn’t mask the name of the Appliance name.

Below is a sample report, which is I must admit is reminiscent of an AWR Report along with the list of various sections.

Let’s also take a look at the output from the custom command we inserted. Below is the captured output showing the password file permissions, neatly sandwiched between the default ASM configuration details in the report.

Final Thoughts

This is a much-needed utility, and it effectively replaces many of the custom scripts we’ve traditionally relied on before and after patching. What really stands out is the customization support—giving ODA admins the flexibility to tailor the configuration collection to their specific environments and operational needs.

Beyond patching prep, odaconfigcli is also a great fit for:

• RCA and support diagnostics
• Auditing and compliance documentation
• Creating baselines before migrations or upgrades
• Capturing config states across environments (dev/stage/prod)
• Configuration drift detection
• Cross-checking system changes post-maintenance

The only real downside is that it introduces yet another standalone utility to manage. I assume this is the first version of an “odachk”, a tool modeled after utilities like Exachk and Orachk. Also, a feature I hope to see soon is native scheduling and automated configuration drift detection, something that is already available with AHF.

Infact, it would be great to see all diagnostic tools integrated into AHF, allowing the users to benefit from tighter alignment with Oracle’s diagnostic stack. That would certainly go a long way in reducing the overhead of maintaining the utility separately and make adoption even easier across environments.