getting x display of a linux bos on x env MacOSX, yet again...
 

In this thread, getting X display of a linux box on X enviroment on OS X , the original poster is referred to instrux at http://www.ibiblio.org/pub/Linux/doc...te-X-Apps.html

...

5. Telling the Client. The client program...knows which display to connect to by inspecting the DISPLAY environment variable. This setting can be overridden, though, by giving the client the command line argument -display hostname:0 when it's started...

The example given has the hostname determined as follows...

Our computer is known to the outside as light, and we're in domain uni.verse... [so where xfig is the program we want to run remotely...]
"setenv DISPLAY light.uni.verse:0
xfig &"

Question the First: Does my MacOS X computer need a DNS-recognized domain name in order for a client to know how to direct display to it? All I've got to work with is a DHCP-issued IP address.

Question the Second: Does each and every program running on the client box need to receive the instruction in order for its display to be available to the specified server?

Question the Third: In the example provided, the user has telnetted to the remote machine in order to issue the above commands. I would assume that since this means the user has logged in with a specific username and password, and that the redirection of DISPLAY is username-specific, possibly also session-specific (?). Could one just as easily, in lieu of telnetting, log on to the machine "up front and in person" rather than remotely, and type the designated commands on the command line? Could one then log off and have these DISPLAY parameters remain in effect when one connects later on, or must they be set at the beginning of the session? (In which case it would for practical reasons have to be telnet)?

I would be very, very worried to have to use telnet for anything. Use ssh instead or you risk telling the world about your passwords and doings. Besides, ssh "knows" about X to begin with. So if you connect with:

% ssh -X user@hostname

... everything X should work automatically. I don't know if that "-X" is still needed in Jaguar, but it's not the default behaviour in 10.1 anyway.

ssh -X will work with a dynamically allocated IP address -- I just tested this.

You only need to do this once per terminal window, not for each x application.

You also need to be running X-windows on your machine, BTW.

I would go so far as to say you should use tcpwrappers to make sure you (or a nefarious evildoer) has no other option but ssh -X to do this, and while you are at it, disable telnet.

That's IT??

I don't have to do complicated brain-bending permissions-settings on both ends to get the friggin' machines to play nicely with each other and trust each other and so forth?

OK, I'll definitely give it a try tomorrow.


Oh...I can use the IP address as the hostname? Or the computer name?

(he says, uncovering his newbiehood once again)

Yes, that's it. Unless you get strange "xauth" problems which you probably won't.

It doesn't matter if you use ip-number or hostname. What "ssh -X host" will do is open a "tunnel" from the remote to the local host that will transfer the X things. So the remote host will think the X display is something local to it. Check the value of the DISPLAY environment variable after having logged in with "ssh -X". It will show something like "hostname:14".

And yes, you'll need to issue the "ssh -X" from an XDarwin terminal window. At least that's what works for me.

What I'm getting is plain old "permission denied, please try again" messages. We are assuming at this time that the person running the Unix box does not correctly remember what username and password he put in for me to use. Are there any fairly common "gotchas" that might instead be the culprit here? It's a Red Hat Linux PC and neither he nor I are Linux folks (or Unix folks in general, minus my OS X dabbling and some out-of-date dabbling he remembers from back when).

I am authenticated and connected, but I have only a command-line connection; the command prompt (from within an X-Window Terminal, not an OS X Terminal, btw) shows me as myname@LocalLinux Allan but I don't have a gui window

??

That's great! Try run an X application then. I usually try "xclock" first.

I got all kinds of stuff to work, including the entire KDE environment and the Konqueror web browser / file browser application.


Then I tried it from home, on the other side of our firewall. I was able to make a command-line connection but GUI apps did nothing. I'm assuming it is because my IP address got NAT'ted by the VPN software to something local, so that when I redirected the display to my own machine, the Linux box obligingly did its best to broadcast it to that IP address to no avail. I guess I need to know what address the VPN has NAT'ted me to and enter that one instead?

I don't think so. Though I suspect when you say VPN you have a component there that you need to explain further. "ssh -X" works through any firewalls I have been behind. I'm almost always NAT:ed actually. But since I use ssh I have never had much need for any VPN things. ssh fills all my VPN needs since it supports tunneling other TCP communication.

osxpez, we have a firewall here at work. Whether we need one or not for a secure ssh connection is largely immaterial, it is there to protect the zillions of Windows PCs and Macs from outside intrusion and whatnot.

When I am at home, I'm on the other side of beforementioned firewall. If I want to connect via Timbuktu to one of my Macs or PCs at work, I must first establish a VPN connection. Similarly, if I want to open a FileMaker database remotely, mount a shared folder on my Desktop (whether via Dave or AppleTalk), or move files into or out of an ftp shared folder, I must have the VPN connection established first.

Once the VPN connection is established, I can also launch XDarwin and open a terminal window and make the ssh connection. However, in order to launch GUI apps and have them appear on my screen, I have to tell the Linux box (via commands issued in the terminal after connecting and validating with password):
where 123.45.67.89 is my IP address. This is not an instruction to my machine, this is an instruction to the Linux box telling it where to put the display. When I do this at work, (which is to say without VPN), I can then go on to launch apps ranging from XClock to KDE and it works fine. From home, it doesn't work.

Which takes me back to the part where I tell the Linux box where to send the display. With the firewall sitting in between, perhaps it cannot "see" my computer at home at its native IP address? Should I perhaps be telling it to export the DISPLAY to 111.11.11.11:0.0 where the net address translation provides me with 111.11.11.11 as my temporarily assigned IP as far as computers within the zone protected by the firewall are concerned?

(If so, the next question would be how the heck do I find out what my NAT'ted IP address is? Cisco 3000 VPN)

Oh wait a minute, are you saying I should be able to connect without bothering to use the VPN?

I'll try that tonight.

Did try it. Doesn't work. No VPN=no connection at all. With VPN connected, I can communicate with the Linux box via command line but GUI apps don't send their imagery to my screen (as they do at the office).

Aha. I never meant to imply you shouldn't need the firewall at work. :) We also have a firewall at work and I have a firewall at home as well. It's just that both these firewalls are set to trust eachother on ssh port (22). But this shouldn't matter. And you should't need to set your DISPLAY environment variable explicitly if you connect with "ssh -X". I'm beginning to suspect that the Linux box your'e connecting to doesn't allow forwarding of X11 connections through ssh. It's in the sshd setup. A parameter named something like "forwardX11". It should be set to "allow" if I remember correctly. If you can convince the admin of that Linux box to fix this then you just do "ssh -X user@host" and then "xclock" or whatever and it shoudl work. Do "echo $DISPLAY" directly after logging in and see if this variable is set before you fire of your "export DISPLAY ...".

But even if the Linux box admin refuses, you might still be able to solve this. SInce you are using a VPN connection this is. Try "who -l am i" when you have connected to the Linux box. You should then see the host you have connected from and could then possibly use that for the DISPLAY variable. If this is the path you end up using you really don't need use ssh. Since the VPN encrypts the communication you could use telnet instead.

Sorry if this sound confusing. I'm in a hurry.

No, it works fine when I am at work. I sit at my PowerBook, launch the XWindows environment, connect via ssh to the Linux box, export the display back to my PowerBook's IP address, and then run kdestart and I've got the whole world of Linux KDE running in a window.

I go home. Same PowerBook, same Linux box, DSL for internet connectivity, VPN to get past company's firewall. Command line only connection to Linux box. Inability to export display back to my PowerBook's IP addy.

Umm, yes. But when you are setting that DISPLAY variable you are not using ssh X11 forwarding. Have you checked the contents of the DISPLAY variable just after connecting before you export it?

Read my last post again. I think your answer is there even if I fail to explain it very good. Anybody who understands what I'm saying and who can explain it better?

Interesting. It doesn't work if I type my IP address in for the "export DISPLAY=my.powerbook.ip.address" command. But when I type my machine name in instead, as "export DISPLAY="powerbook_x.wins.mycompany.com", it works fine.

I'm at home and I'm "in" Linux / KDE :)

Yes, that's because that last host name is your virtual address as set up by the VPN. Think about what VPN means, a virtual private network (or virtual LAN if that's more familiar). When you're connected to that VPN you become a node on that local network. So the Linux box see's your powerbook as a closer neighbour than it might be physically. And the Linux box can send the X11 traffic to that closer neighbour. But if it tries to send you X11 thingys to your Internet address it is blocked by the firewall at your workplace.

Another way to view it is that the VPN solution opens a "tunnel" between your machine and the firewall. The tunnel is encrypted so nobody can listen in to what is said there. In order to send you X11 packages the Linux box must send them through the tunnel.

Good you got things to work anyway. And as I said, since you have the protection of that VPN you might as well use telnet to connect to the Linux box.

osxpez,

I learned from your post. Your explanations are very clear. Thanks a lot.


Cheers...

Yeah, that's more or less what I figured, except that I didn't know or realize that the text string "powerbook_x.wins.mycompany.com" would work (I figured it would have to be recognized by DNS to be useful. And in fact it doesn't work at the office, where only the "my.powerbook.ip.address" version obtains the desired results). Your explanation clarified things and I went back and tried the text string version and it worked.

I was figuring that I'd have to know the IP address that the VPN assigns me for internal use, and use that, and I didn't know how to obtain it.

Thanks a whole lot for your help. :)

Maybe I am going about this all wrong - so I am hoping someone can spot my ignorance.

I am trying to work remotely on an iBook running KDE FROM a G4 on the same LAN. I am working within my internal LAN so FW/VPN, etc is not a problem. I launch XDarwin from the G4 and it opens into WindowMaker. I then do the following (within xTerm).

ssh -X user@ibook

get logged in and I can run clockx, etc from KDE on iBook. Now I want to have the full KDE environment accessible from the G4 - as if I was using Timbuktu or VNC, etc. type experience. So I tried this from xTerm:

startkde

And strangely enough it seems to work. Tells me it won't start because another window manager is already running and then it continues to fire up and there I have my KDE desktop from the iBook layer with the WM from the XDarwin startup. Nevertheless - everything startsup and I can launch GUI, etc. Heck I was floored when I got this far!

What I am wondering though - is there anyway to get rid of the WindowMaker elements that are coexisting on the desktop with the KDE from teh iBook. Its like I have 2 window managers running at the same time. Seems a bit wasteful on the resources.

So am I even close to doing this correctly? Any tips/hints would be greatly appreciated.

Thanks for those words sao. I was beginning to think I couldn't explain it.

AHunter: I'm still a bit confused about which of my suggestions you have tried. Have you tried connecting with "ssh -X" to the Linux box and then checked "echo $DISPLAY"? Because I think X11 forwarding is default for most sshd installations. (sshd is the ssh server daemon running on that Linux box).