X-Server access is denied on host
The situation is: I have a RHEL 7.3 VM that I am able to access via both ssh and VM console. I am able to run all of the standard commands for verifying that X11 forwarding/xhost permissions are working (xclock, nautilus, firefox, etc.) i can also run the runInstaller for Oracle client, No problems in any of these situations.
However, attempting to run the installation of Oracle WebLogic 12.1.3
with : cissys as user and the ligne command: java -jar fmw_12.1.3.0.0_wls.jar.
try with oracle user = same error.
results in the following :
Launcher log file is /tmp/OraInstall2017-07-25_03-14-27PM/launcher2017-07-25_03-14-27PM.log.
Extracting files.........
Java HotSpot(TM) Client VM warning: You have loaded library /tmp/orcl5779090421142529968.tmp/Disk1/install/linux/libjni.so which might have disabled stack guard. The VM will try to fix the stack guard now.
It's highly recommended that you fix the library with 'execstack -c ', or link it with '-z noexecstack'.
Starting Oracle Universal Installer
Checking if CPU speed is above 300 MHz. Actual 1696.120 MHz Passed
Checking monitor: must be configured to display at least 256 colors. Actual 16777216 Passed
Checking swap space: must be greater than 512 MB. Actual 7815164 MB Passed
Checking if this platform requires a 64-bit JVM. Actual 32 Passed (64-bit not required)
Checking temp space: must be greater than 300 MB. Actual 2956 MB Passed
Preparing to launch the Oracle Universal Installer from /tmp/OraInstall2017-07-25_03-14-27PM
Java HotSpot(TM) Client VM warning: ignoring option MaxPermSize=512m; support was removed in 8.0
Log: /tmp/OraInstall2017-07-25_03-14-27PM/install2017-07-25_03-14-27PM.log
X-Server access is denied on host
[Fatal Error] DISPLAY variable set incorrectly: 172.16.40.30:0.0
[Resolution] Verify that your DISPLAY environment variable is set correctly,
and that there is an X11 server on the system. If you are
running the Oracle Installer as a different user or on a different host,
you may need to use the xhost command to ensure that host/user
has permission to write to your display.
I've tried just about every troubleshooting step that I can think of and every troubleshooting step that Google has provided me.
If anyone has any idea of an obvious or less-than-obvious culprit, I would absolutely love to hear it.
Responses
You are probably overriding the DISPLAY variable set by X11-forwarding SSH session. As a result, the session data between 172.16.40.30 (which I assume is your workstation) and the installer is getting transmitted unencrypted over the network.
If 172.16.40.30 is actually the server to which you're currently installing Oracle, setting DISPLAY to 172.16.40.30:0.0 forces the X11 libraries to use a TCP socket for a local X11 server connection.
Most Linux systems today configure the X11 server to not listen for incoming connections over TCP sockets by default, as unencrypted X11 connections over the network are vulnerable to snooping and various attacks. In previous RHEL versions this was achieved by the system starting the X11 server with a command line like X -nolisten tcp, but in RHEL 7.x, the logic is inverted: to allow X11 server to listen for incoming TCP connections, you must start it with an explicit -listen tcp option instead.
But using a TCP socket to connect to a local X11 server is inefficient. If you instead specify DISPLAY=:0.0, the GUI applications will use the X11 server on their local system using an Unix socket instead: this socket is typically located in /tmp/.X11-unix/X0. This would be the best value for the DISPLAY variable if you are running a local X11 server on the VM while installing Oracle, as it also allows the X11 applications to use certain performance optimizations that can only be used when the X11 server is on the same system.
If you want to run the installer over a X11-forwarding SSH connection, make sure that the xauth RPM is installed on the VM: the sshd daemon requires it to set up the forwarding properly.
When the SSH X11 forwarding is correctly set up, you should see the DISPLAY variable being automatically set to a value like 127.0.0.1:10.0 or localhost:10.0 within your SSH session: although this may seem non-sensical, it is actually correct. The sshd daemon on the VM is acting as an encrypting proxy for the X11 connections, and this value tells the X11 applications to use a TCP socket to connect to the sshd X11 proxy, which will then forward the connection to your SSH client, which will then establish a regular X11 connection to your local X11 server.
Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.
