Remove Oracle Instant Client from Dockerfiles; Fix #419

[Geogouz]

Removes Oracle Instant Client and dependencies that have been specified as required by it only.
The affected containers are:

• daemons
• init
• probes
• server
• ui

however, would we prefer to keep the client in some of those for backwards compatibility (e.g. in probes)? Not sure. If so, I can leave it (may adding an inline comment that this needs to be removed in 2 years).

[rdimaio]

LGTM. On the backwards compatibility point: I think it's fine to remove the instant client from the latest versions of these containers, as they match the latest changes in the Rucio core code. That said, since 38 will be an LTS release, it might be worth keeping the instant client as part of this release at least, and then removing it from subsequent releases. @bari12 thoughts?

[bari12]

please rebase

[Geogouz]

@dchristidis @bari12 Regarding the probes image specifically mentioned at the top, the following:

https://github.com/rucio/probes/blob/main/common/check_oracle

is currently still requiring Oracle Instant Client / thick mode (importing cx_Oracle). Hence, we should migrate check_oracle to python-oracledb thin mode too I assume because it will start failing.

[dchristidis]

Wasn’t it the case that we couldn’t use thin mode at all at CERN?

[Geogouz]

Wasn’t it the case that we couldn’t use thin mode at all at CERN?

Is there any yes case here?:

• Do we use Kerberos, Radius, external OS authentication, or SEPS wallet credentials for the DB connection? (I assume no because the probe involved uses DB username/password)
• Do we use Oracle Native Network Encryption or crypto-checksumming? (that would be one unknown)
• Does the DSN require LDAP naming or Oracle Client config behavior that thin mode cannot reproduce? (that would be a second unkown to me)
• Do we require Oracle Client-only features such as FAN, TAF, Application Continuity, or ADR diagnostics? (for the probe I guess not because it just connects and runs a query)

I don't have access to ATLAS so I am walking in the dark here a bit. Maybe I could request a DaFab test instance to play with from "https://cern.service-now.com/service-portal?id=service_element&name=oracle-database-service" (if this is the service we expect to be using at Cern).

[dchristidis]

Comment from our DBA from 31 July 2025:

Oracledb thin client doesn't work at cern because of encryption

[Geogouz]

Comment from our DBA from 31 July 2025:

Oracledb thin client doesn't work at cern because of encryption

Hmmm, probably then NNE is involved in which case this might be indeed a blocker. But if TLS / TCPS is used, then thin mode can support such encrypted connections with proper configuration. I'll pm you to check something about this.

[Geogouz]

@bari12 Indeed after confirming with @dchristidis, the connections are using Encryption service and Crypto-checksumming service which means that we do need the thick client for those.

To avoid just reverting this, I suggest to reintroduce Instant Client, but in a cleaner/pinned way (via Oracle signed package verification). Maybe try to go even with 23ai to be future-proof (our databases are 19 or later, right?). And change probes from cx_Oracle to python-oracledb.

I could work on this today.

[Geogouz]

I started working on this and I'll have it ready by today to give it a check.