Re: Unable to execute runInstaller

On 2015/10/22 22:49, Jack van Zanen wrote:

> We run similar way with putty and x-tunneling never an issue
> When we log on using our own account the DISPLAY is automatically set correctly
> Check this setting.
> When we su to oracle we need to use that setting and it does not always end in "0.0"

While setting the DISPLAY variable will work if your display is on the same network, there are cases where the tunneling only works in one direction, e.g. some VPN connections. The possibly-documented way of working around this is to recreate the magic cookie (great name!) created on the initial connection (assuming X11 forwarding is enabled in the sshd on the server), which does not carry over through su. After ssh'ing to the server, use something like:

$> echo $DISPLAY
localhost:10.0

$> xauth list

myserver01/unix:12 MIT-MAGIC-COOKIE-1 1548a1aa1ae1295d3a036e8742c86e5d
myserver01/unix:11 MIT-MAGIC-COOKIE-1 41831f199d1edf9402689b00801cd713
myserver01/unix:10 MIT-MAGIC-COOKIE-1 34f4c1c29a4be321ae1b274bfe90cf5d

Use the display number from the DISPLAY variable to find the magic cookie to use from the X authority list. In the above example, the DISPLAY number is "10", so use the last line from the X authority list, since it's display is also "10" ("unix:10").

$> su - oracle

Set the same DISPLAY variable as above:

oracle> export DISPLAY=localhost:10.0

Set the X authority as the one in use (the above example was the "10" display):

oracle> xauth add myserver01/unix:10 MIT-MAGIC-COOKIE-1 34f4c1c29a4be321ae1b274bfe90cf5d

I haven't tested, but this should also avoid needing to use the "xhost +" security hole for those environments where that would be a bad thing. Like if your coworkers enjoy spawning 100 xclocks on your display...

Rich

--
http://www.freelists.org/webpage/oracle-l