Re: Unable to execute runInstaller
- From: Rich J <rjoralist3@xxxxxxxxxxxxxxxxxxxxx>
- To: oracle-l@xxxxxxxxxxxxx
- Date: Fri, 23 Oct 2015 09:24:24 -0500
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
Other related posts:
