Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris

Re^3: Remote ptkdb behind firewall

by oko1 (Deacon)
on Feb 19, 2012 at 18:38 UTC ( #954906=note: print w/ replies, xml ) Need Help??

in reply to Re^2: Remote ptkdb behind firewall
in thread Remote ptkdb behind firewall

AFAIK, there's no functional difference between a BEGIN block with and without "sub".

Oh - that's a new one on me. :) Thanks!

As for the OP's problem, the issue presumably is that the www-data user doesn't have a cookie that would allow authentication with the X server.

Mmm... maybe. Or it might require having the remote X server listen for the connection on 6000+; depends on how 'ptkdb' is written, I would think. Most Linux distros these days run X with the '-nolisten tcp' option, which is quite the pain to disable (I needed to do it a while back, in similar circumstances); at that point, 'xhost hostname' allows communication from the other host, etc. As I'm sure you're aware, though, this has various security implications.

(Ah, good old X, with its annoyingly-high level of access to root privileges and infuriatingly-arcane protocols. Always such fun. :)

Update: I just tried it out. On my machines (Ubuntu "Oneiric Ocelot", both ends), setting the cookie didn't help; turning off '-nolisten tcp' and running 'xhost otherhost' popped up that 'ptkdb' window right away.

Actually, I'm not very happy with that. When I get a little more time (I've got to run off to my boat and do a bunch of maintenance), I'm going to see if I can force it to work in a more reasonable way - i.e., the way you suggested - or figure out how to patch ptkdb so it works with that model, if possible.

I hate storms, but calms undermine my spirits.
 -- Bernard Moitessier, "The Long Way"

Comment on Re^3: Remote ptkdb behind firewall
Re^4: Remote ptkdb behind firewall
by Eliya (Vicar) on Feb 19, 2012 at 19:00 UTC
    Or it might require having the remote X server listen for the connection on 6000+

    As the OP wants ptkdb's window to be displayed on the local X server, it doesn't matter how the remote X server is set up.   Anyhow, letting the remote server establish a connection to the local machine's X server directly from the outside network typically isn't the best idea...

    This is why I suggested to tunnel the ptkdb X requests through the ssh connection.  ssh knows how to handle "no-tcp" listening X servers, so it shouldn't matter how the local X server is set up. On the remote side ssh creates a socket (unix domain or tcp, depending on configuration), which the remote X clients can connect to  (this is what you get via xauth list $DISPLAY).  The respective requests are then forwarded to the local X server.  But for this to work, the remote X client application also needs to have a valid cookie, or else the local X server would reject the requests.  Hence the fiddling with xauth...

    On my machines (Ubuntu "Oneiric Ocelot", both ends), setting the cookie didn't help; ...

    Then you did it wrong :)  I'm doing this all the time (also on Ubuntu "Oneiric Ocelot"), and it works just fine.

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://954906]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (12)
As of 2014-09-19 17:35 GMT
Find Nodes?
    Voting Booth?

    How do you remember the number of days in each month?

    Results (143 votes), past polls