(Photo by Joël Assuied, on Unsplash)
I just started working on Exadata Cloud at Customer. And with this, come my first mistakes 😉
One of my compute node had all cloud tooling scripts located in the adequate directories :
# ls -l /var/opt/oracle/exapatch/ [...] -r-xr-xr-x 1 oracle oinstall 0 Feb 4 21:23 exadbcpatchsm -r-xr-xr-x 1 oracle oinstall 0 Feb 4 21:23 exadbcpatchmulti -r-xr-xr-x 1 oracle oinstall 0 Feb 4 21:23 exadbcpatch [..]
but for an obscure reason (made of failed update combined with full filesystem), they were all emtpy.
Cloud Tooling was considered installed :
# rpm -qa | grep -i dbaastools_exa dbaastools_exa-1.0-1+188.8.131.52.0_190204.1203.x86_64
But of course, unusable.
First, I cleanly deinstalled it :
# rpm -ev dbaastools_exa
Ok, but where can I get the rpm back ?
Since it is an Exadata Cloud at Customer, it should be available on the local Object Storage. After cross-checking documentation of Oracle Cloud Infrastructure (public cloud) and Exadata Cloud at Customer, I figured out the rpm should be available there :
Once I got the rpm, I re-installed it :
# rpm -ivh dbaastools_exa.rpm
Then, I tried to use Cloud Tooling again, to list available patches for example :
# /var/opt/oracle/exapatch/exadbcpatch -list_tools Starting EXADBCPATCH Logfile is /var/opt/oracle/log/exadbcpatch/exadbcpatch_2019-02-20_15:13:22.log Config file is /var/opt/oracle/exapatch/exadbcpatch.cfg Location of inventory.xml is set to /u01/app/oraInventory/ContentsXML/inventory.xml INFO: tools images available for patching oss_patch:Failure cannot get updated information from https://storage.us2.oraclecloud.com/v1/dbcsswlibp-usoracle29538/dbaas_patch/shome/exa_map [...]
What’s wrong ?
In the corresponding log file, I found the following message :
2019-02-20 15:13:25 - INFO: oss_container_url is not given, using the default
Indeed, the deinstall process also removed configuration file
/var/opt/oracle/exapatch/exadbcpatch.cfg and recreated a fresh one :
# rpm -qpil dbaastools_exa.rpm | grep exadbcpatch.cfg /var/opt/oracle/exapatch/exadbcpatch.cfg
The correct local URL, stored in variable
/var/opt/oracle/exapatch/exadbcpatch.cfg, was lost, and a default URL on public cloud was used instead (but no internet access 🙂 )
Setting the correct URL for variable
/var/opt/oracle/exapatch/exadbcpatch.cfg solved this final error.