Re^3: 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

Replies are listed 'Best First'.

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.

[reply]
[d/l]
[select]


We don't bite newbies here... much
	PerlMonks