While these features are not required to run or maintain Oracle software, it is quite common for them to be used for product maintenance and installation, as most people have become quite dependent upon graphical user interfaces for new releases, patching, and installs. So, this presents a dilemma. Often, Oracle itself, a third party, or a systems engineer are tasks to install new linux versions. They have a checklist (often supplied by Oracle) to assure all needed options, features and packages are included in the new build, and will receive verification that they are complete and functional. It can be days/weeks/months before the next installation or maintenance is attempted, often in very tight windows. If such activities are dependent upon X11 features, they will fail. This happened to a client quite recently.
The solution is to identify this issue, and pre-install the needed packages. Then, any account which needs them need to be configured and hardened to use them safely (this is different than the prior configuration). For one thing, executables are no longer in /usr/bin, nor /usr/X11/bin. Oracle attempts to address support requests raised on their "My Oracle Support (MOS)" website with the following document:
Unable to run graphical tools (gui) (runInstaller, dbca and dbua) on Exadata 184.108.40.206.0 - 220.127.116.11.0 (Doc ID 1969308.1)
However, this document is not applicable to only Exadata, and is maddeningly incomplete in most circumstances. Two solutions are offered, with the first being recommended, but quite unwieldy and somewhat convoluted. It suggests basically downloading the entire linux package library to your machine, and then running a compare and merge for incomplete or missing components. This is great, but often undesirable on a production or heavily used system, and has numerous possibly negative consequences.
The second solution seemed simple and reasonable. The only downside is that future versions COULD possibly cause it to be re-applied. If you've been paying attention since the start of this discussion, that is quite unlikely, since linux and Oracle have decided to remove this feature and packages going forward. I will therefore submit that solution 2 is the most practical.
However, there are pitfalls, and downright incorrect/incomplete information in the instructions.
First off the following packages are listed and supplied as a zip in the document:
However, these have prerequisites of their own, and are incomplete. The following packages are additionally required (in most cases, as in after a linux upgrade to support OEL for Oracle 12c):
On some systems, these prerequisites would be flagged and listed as requirements in detail. Not so on a recent exadata installation. This required considerable time to research. Once the complete list of packages are added, then the instructions for implementation from the Oracle documentation can be added.
There are other problems, as well. If the "oracle" user, typically invoked to install products, is still pointing to the old set of executables for X, it won't find the new ones. This will have to be addressed. If this is a completely new build, sshd will need to be configured, stopped and then started to support X functionality. Finally, this configuration will have to be done for every node in a cluster, and verified. These things can take time, both in preparation and implementation. It might be wise to first implement in other environments, and work out these issues, including command and control, politically, as this was also an issue for some clients.
I am intentionally leaving some detail out of this document, under the assumption that the audience:
a) knows what X windows is.
b) knows how to use it to maintain oracle products.
c) have a certain familiarity with linux and services such as sshd.
d) can understand and work with linux package installation and configuration.
If any of the above is not the case, I suggest opening a support request with Oracle, as their document is insufficient in it's current form.