Re^2: Remote ptkdb behind firewall

but you don't have a BEGIN block, you have a subroutine called BEGIN, which isn't the same thing at all.

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

"These code blocks can be prefixed with "sub" to give the appearance of a subroutine (although this is not considered good style)."

Where would you think a functional difference lies?

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. The fact that it works via a separate ssh connection (with X forwarding) doesn't say much — it is because the ssh server sets up an appropriate DISPLAY/socket and cookie for the connection. But that cookie can be transferred to a different account, if desired. For this, list it from within the ssh connection's terminal with xauth. You'd get something like

$ xauth list $DISPLAY
somehost.domain.com:10  MIT-MAGIC-COOKIE-1  b412a470ac5605e443cd330f48
+bbc62e
[download]

Then switch to the www-data account and run (or run the same command from within the BEGIN block in the CGI)

xauth add somehost.domain.com:10 MIT-MAGIC-COOKIE-1 b412a470ac5605e443
+cd330f48bbc62e
[download]

and set DISPLAY to somehost.domain.com:10. This adds the cookie to the user's xauth database file (by default ~/.Xauthority), and hence allows www-data to connect to the X server via the same tunnel that is used by the ssh connection. Of course, this only works as long as the ssh connection is established (so you should keep it open while debugging).

Comment on Re^2: Remote ptkdb behind firewall Select or Download Code

Replies are listed 'Best First'.
Re^3: Remote ptkdb behind firewall by oko1 (Deacon) on Feb 19, 2012 at 18:38 UTC
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"	[reply]
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]