allow customer oracle client version#4327
Conversation
❌ 1 blocking issue (1 total)
|
There was a problem hiding this comment.
Findings (3 survived verification, most-severe first)
script/oracle/install-instantclient-packages.sh:15 — Glob never expands in bash variable assignment; the "use existing file" feature is completely broken.
Bash does not perform glob expansion in variable assignments (local f=path/*). The literal string vendor/oracle/instantclient-sdk-*.zip (with a literal *) is stored in existing_file. The [ -f "${existing_file}" ] test on line
17 always returns false because no file has a literal asterisk in its name. The code always falls through to download the hardcoded 19.18 version, defeating the entire purpose of the PR. Fix: use an array, e.g. local -a
existing_files=($path/${package}-*.zip) and then check [ -f "${existing_files[0]}" ].
script/oracle/install-instantclient-packages.sh:48 — Hardcoded instantclient_19_18 symlink paths break for any other Oracle version.
Lines 48-49 create symlinks referencing /opt/oracle/instantclient_19_18/, but a customer-provided Oracle 21.x zip extracts to /opt/oracle/instantclient_21_9/ (Oracle uses version-based directory names). Both symlinks become
dangling — libsqora.so and /opt/oracle/instantclient point to nonexistent paths, breaking Oracle ODBC connectivity at runtime. Since ln -sf succeeds even for dangling targets, this fails silently.
script/oracle/install-instantclient-packages.sh:38 — basiclite/basic detection still uses the hardcoded version, inconsistent with the PR's goal.
The special-case logic at line 38 constructs basiclite="vendor/oracle/instantclient-basiclite-${oracle_version}.zip" using the hardcoded 19.18 version string. A customer-provided basiclite zip at a different version will not
be found, so the script will attempt to download instantclient-basic from Oracle's 19.18 URL instead — ignoring the customer's file and potentially mixing incompatible versions.
|
@jlledom I haven't tested this. I'm more interested in the intention review than the AI implementation analysis. So give your opinion on the intention to allow customer downloaded version if it doesn't match the exact version script would download. Thanks! |
I'm not against it. What I'm not sure is if RH contract allows the customer to decide which DB version to use, or they are required to use a fixed version. If there's no legal requirement, of course, they should be able to provide their own oracle client. |
AFAIK they can use any database, whether they are supported depends on the product support matrix. This is not about the database used though but about the client libraries. And even if we want to make sure 19.x server is only used by 19.x client, we should still allow using the latest oracle published version if not for the fixed bugs, at least for the resolves potential security issues. |
Fine for me 👍 |
| local zip="${package}-${oracle_version}.zip" | ||
| local file="vendor/oracle/${zip}" | ||
| local file="$path/${zip}" | ||
| local existing_file="$path/${package}-"*".zip" |
Presently the oracle client version is hardcoded but it might be older than what customers want or need to use. This one would use any downloaded version instead of only acepting that particular minor version.