X11 Forwarding Solaris Desktop
- Thread starter idavidson
- Start date
kenny
Registered
I can try... 
Here's a "simple" 5-step plan to getting a remote X application to display on your Mac running X11. Note that with the exception of pathing and the presence of the korn shell, this will also work the same way with a Linux, BSD, AIX, or even Darwin machine.
Step 1. Prepare to receive the application window.
Start X11.app, and allow it to bring up the first xterm. In that xterm, issue the following command:
xhost +
The message displayed as a response to this command should be "access control disabled, clients can connect from any host"
(alternately, you could issue an xhost command to limit exports from a specific host or group of hosts. See man xhost for details on how this works)
Step 2. Determine where you're going to send the display
Issue the command
ifconfig -a
This should produce output that looks similar to this:
What you're looking for here is the IP address of your local machine. This example comes from my TiBook running Airport, so I would look under the section for en1. On a machine connected with Ethernet, the interface is usually en0. My address from this output is 192.168.1.7, as seen above.
Make note of this address as it appears on your machine.
(If you're using DNS and the machines can resolve each other's hostnames, you could simply use the hostname to export the display. Troubleshooting DNS, though, can be tricky and probably a bit beyone the scope of this article. Using IP addresses is almost certain to work, regardless of the name resolution method in use.)
Step 3. Get connected to the remote host and get a reasonable shell.
Using telnet (or ssh, if available) connect to the remote host and log in. Once at a prompt, issue the following command:
ksh
The prompt should change to a single '$'. This is the korn-shell. I prefer it on Solaris (and every other *nix environment in which I work), and the following steps rely on its being the working shell to export the display with the commands that I am using.
(Note that this may not work against a default install of Linux or Darwin. For Linux, the default shell is Bash, which understands the export command. For Darwin, zsh seems to work.)
Step 4. Export the display and test.
Issue the following command to set the display variable. Note that it is case-sensitive. I am using the IP address from the example above. Obviously, you should use your own address:
export DISPLAY=192.168.1.7:0.0
If successful, there should be no message. You can verify that the variable is set correctly, if you wish, with the command echo $DISPLAY.
Next, make sure that the display actually worked. Issue the following command:
/usr/openwin/bin/xterm
In a second or two, a new xterm should appear on your desktop. If not, double-check your steps above, and note what errors may have occurred when issuing the command. Once you've verified this, you can close the exported xterm.
(On Linux, a simple xterm should work. On Darwin, an install of XFree86 of some kind is required for this to work)
Step 5. Profit!!
Once you've closed the test xterm window, you should return to a prompt. From here, you can run any X11 application you want, and it will show up on your Mac. You may have noticed that the control did not return to your first terminal window until you closed the test xterm. There are 2 additional parameters that you can use to prevent this, nohup and &.
The first, nohup prevents the launched application ending if the parent terminal window is closed. This can be very useful, but understand that if you close the terminal window, and then want to run another app, you will have to repeat step 3 and 4 to re-export the display. The second, &, causes the application to be run 'in the background' of the parent terminal. Once the command is issued, you should return to a prompt and can issue additional commands to open other applications.
So, for instance, if I wanted to launch a browser, say, Mozilla, on the remote machine, I would issue the command
nohup mozilla &
After a few seconds, the browser would show up on my machine. This is a fine way to run applications that are not installed locally. I've used this to run things like OpenOffice, Gimp, WebSphere consoles, etc...
Closing Notes
If you've never done this before, you may be wondering why this is worth so much work. I'm not sure I have a good answer that a self-confessed newbie would fully appreciate)). But I've found that with experience on *nix systems, being able to seamlessly run applications from multiple machines on a single workstation to be a fabulously useful thing. For instance, I can run admin consoles for an LDAP server on one machine, an application server admin console from another machine, and a browser from a third machine all in one place, and be able to copy/paste freely between them. Such is the power of XWindows, and although they've made some progress in remote windowing, neither Microsoft (using Terminal Server/RDC) nor Apple (using ARD) have quite reproduced this flexibility.
One final note. One thing I found supremely confusing the first few times I did this is that the context of the application is on the remote machine. So, opening a file in OpenOffice, for instance, will display the filesystem hierarchy on the remote machine, not the local one. If you have a file that you want to open with a remote application, you'd have to sort out how to get it to be accessible from the remote machine, either by copying it to the remote, copying it somewhere that the remote can find it, or sharing it from your local machine in such a way that the remote can access it.
Enjoy your new-found power, and remember to use it for good, not evil...
Here's a "simple" 5-step plan to getting a remote X application to display on your Mac running X11. Note that with the exception of pathing and the presence of the korn shell, this will also work the same way with a Linux, BSD, AIX, or even Darwin machine.
Step 1. Prepare to receive the application window.
Start X11.app, and allow it to bring up the first xterm. In that xterm, issue the following command:
xhost +
The message displayed as a response to this command should be "access control disabled, clients can connect from any host"
(alternately, you could issue an xhost command to limit exports from a specific host or group of hosts. See man xhost for details on how this works)
Step 2. Determine where you're going to send the display
Issue the command
ifconfig -a
This should produce output that looks similar to this:
Code:
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1
inet 127.0.0.1 netmask 0xff000000
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
ether 00:03:93:a3:37:30
media: autoselect (none) status: inactive
supported media: none autoselect 10baseT/UTP <half-duplex> 10baseT/UTP <half-duplex,hw-loopback>
10baseT/UTP <full-duplex> 10baseT/UTP <full-duplex,hw-loopback>
100baseTX <half-duplex> 100baseTX <half-duplex,hw-loopback> 100baseTX <full-duplex>
100baseTX <full-duplex,hw-loopback> 1000baseTX <full-duplex> 1000baseTX <full-duplex,hw-loopback>
1000baseTX <full-duplex,flow-control> 1000baseTX <full-duplex,flow-control,hw-loopback>
en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
inet [b]192.168.1.7[/b] netmask 0xffffff00 broadcast 192.168.1.255
ether 00:30:65:1b:ce:82
media: autoselect status: active
supported media: autoselectWhat you're looking for here is the IP address of your local machine. This example comes from my TiBook running Airport, so I would look under the section for en1. On a machine connected with Ethernet, the interface is usually en0. My address from this output is 192.168.1.7, as seen above.
Make note of this address as it appears on your machine.
(If you're using DNS and the machines can resolve each other's hostnames, you could simply use the hostname to export the display. Troubleshooting DNS, though, can be tricky and probably a bit beyone the scope of this article. Using IP addresses is almost certain to work, regardless of the name resolution method in use.)
Step 3. Get connected to the remote host and get a reasonable shell.
Using telnet (or ssh, if available) connect to the remote host and log in. Once at a prompt, issue the following command:
ksh
The prompt should change to a single '$'. This is the korn-shell. I prefer it on Solaris (and every other *nix environment in which I work), and the following steps rely on its being the working shell to export the display with the commands that I am using.
(Note that this may not work against a default install of Linux or Darwin. For Linux, the default shell is Bash, which understands the export command. For Darwin, zsh seems to work.)
Step 4. Export the display and test.
Issue the following command to set the display variable. Note that it is case-sensitive. I am using the IP address from the example above. Obviously, you should use your own address:
export DISPLAY=192.168.1.7:0.0
If successful, there should be no message. You can verify that the variable is set correctly, if you wish, with the command echo $DISPLAY.
Next, make sure that the display actually worked. Issue the following command:
/usr/openwin/bin/xterm
In a second or two, a new xterm should appear on your desktop. If not, double-check your steps above, and note what errors may have occurred when issuing the command. Once you've verified this, you can close the exported xterm.
(On Linux, a simple xterm should work. On Darwin, an install of XFree86 of some kind is required for this to work)
Step 5. Profit!!
Once you've closed the test xterm window, you should return to a prompt. From here, you can run any X11 application you want, and it will show up on your Mac. You may have noticed that the control did not return to your first terminal window until you closed the test xterm. There are 2 additional parameters that you can use to prevent this, nohup and &.
The first, nohup prevents the launched application ending if the parent terminal window is closed. This can be very useful, but understand that if you close the terminal window, and then want to run another app, you will have to repeat step 3 and 4 to re-export the display. The second, &, causes the application to be run 'in the background' of the parent terminal. Once the command is issued, you should return to a prompt and can issue additional commands to open other applications.
So, for instance, if I wanted to launch a browser, say, Mozilla, on the remote machine, I would issue the command
nohup mozilla &
After a few seconds, the browser would show up on my machine. This is a fine way to run applications that are not installed locally. I've used this to run things like OpenOffice, Gimp, WebSphere consoles, etc...
Closing Notes
If you've never done this before, you may be wondering why this is worth so much work. I'm not sure I have a good answer that a self-confessed newbie would fully appreciate
)). But I've found that with experience on *nix systems, being able to seamlessly run applications from multiple machines on a single workstation to be a fabulously useful thing. For instance, I can run admin consoles for an LDAP server on one machine, an application server admin console from another machine, and a browser from a third machine all in one place, and be able to copy/paste freely between them. Such is the power of XWindows, and although they've made some progress in remote windowing, neither Microsoft (using Terminal Server/RDC) nor Apple (using ARD) have quite reproduced this flexibility.One final note. One thing I found supremely confusing the first few times I did this is that the context of the application is on the remote machine. So, opening a file in OpenOffice, for instance, will display the filesystem hierarchy on the remote machine, not the local one. If you have a file that you want to open with a remote application, you'd have to sort out how to get it to be accessible from the remote machine, either by copying it to the remote, copying it somewhere that the remote can find it, or sharing it from your local machine in such a way that the remote can access it.
Enjoy your new-found power, and remember to use it for good, not evil...
Darkshadow
wandering shadow
Heh, I used to do that with a roomie of mine. Though I ticked him off a few times by running his 3D modelling program and totally making his machine unusable while I was using it. I was burnin up those CPU cycles. Heh
I liked playing jokes on him too. 'Course, he usually got me back for it.
I liked playing jokes on him too.
'Course, he usually got me back for it. Just a note because idavidson initially referred to X11 *forwarding* which is different from manually setting the DISPLAY variable:
If you ssh -X to a remote machine the X11 port is automatically forwarded to the remote machine. This means that the remote ssh daemon will setup an appropriate DISPLAY variable automatically which forwards the data through the encrypted ssh connection right to your local X server. This is most convenient IMO.
I modified the ForwardX11 configuration directive in the /etc/ssh_config file (set it to "yes"), this causes the same as specifying -X on the command line, since I almost always want to have X11 forwarding enabled.
Coming back to idavidson's initial question:
I don't think it's possible to forward the remote X desktop to the local X server unless the local X server supports the XDMCP (X Display Manager Control Protocol). I didn't yet find a way to configure this - which does not necessarily mean that this is not supported
If you ssh -X to a remote machine the X11 port is automatically forwarded to the remote machine. This means that the remote ssh daemon will setup an appropriate DISPLAY variable automatically which forwards the data through the encrypted ssh connection right to your local X server. This is most convenient IMO.
I modified the ForwardX11 configuration directive in the /etc/ssh_config file (set it to "yes"), this causes the same as specifying -X on the command line, since I almost always want to have X11 forwarding enabled.
Coming back to idavidson's initial question:
I don't think it's possible to forward the remote X desktop to the local X server unless the local X server supports the XDMCP (X Display Manager Control Protocol). I didn't yet find a way to configure this - which does not necessarily mean that this is not supported
kenny
Registered
Well, they say you learn something new every day...
I've not messed with X11 forwarding with ssh, and I have to agree, that's much simpler than the manual setting of the DISPLAY variable. Sadly, I can't use that @ work, because the Unix admin folks disallow ssh. Instead, they use Keon, which supports encrypted telnet, and does user/host group management as well, so that they can define what users can log into which hosts on the network. SSH, in its current form, is a bit tougher to manage across thousands of machines.
Still, where I can, I'll be using ssh -X from now on...
I've not messed with X11 forwarding with ssh, and I have to agree, that's much simpler than the manual setting of the DISPLAY variable. Sadly, I can't use that @ work, because the Unix admin folks disallow ssh. Instead, they use Keon, which supports encrypted telnet, and does user/host group management as well, so that they can define what users can log into which hosts on the network. SSH, in its current form, is a bit tougher to manage across thousands of machines.
Still, where I can, I'll be using ssh -X from now on...
kilowatt
mach-o mach-o man
ssh -X is also encrypted. Using xhost allows the x window application to connect to the x windowing systen directly.
With x11 forwarding, all packets are passed through the ssh session.
Make sure X11Forwarding is enabled on the ssh *server* that you are connecting to which has the applications installed on it. So, just edit sshd_config on the computer with the apps. Note the 'd'. sshd_config.
Also, if you're directly connected to the internet or a large extranet, don't issue xhost +.
Simply issue:
xhost +hostname
Where 'hostname' is the hostname, or ip address of the computer with the x11 application on it you wish to use.
use:
xhost -hostname
to remove it from the list of approved x11 connections, when you finish. Remeber, you are at the mercy of Mac OS X's ability to determin the true origin of all connections when you use an ip-based rule like this.
With x11 forwarding, all packets are passed through the ssh session.
Make sure X11Forwarding is enabled on the ssh *server* that you are connecting to which has the applications installed on it. So, just edit sshd_config on the computer with the apps. Note the 'd'. sshd_config.
Also, if you're directly connected to the internet or a large extranet, don't issue xhost +.
Simply issue:
xhost +hostname
Where 'hostname' is the hostname, or ip address of the computer with the x11 application on it you wish to use.
use:
xhost -hostname
to remove it from the list of approved x11 connections, when you finish. Remeber, you are at the mercy of Mac OS X's ability to determin the true origin of all connections when you use an ip-based rule like this.