|
UNIX Hints & Hacks |
 |
||||||||||||||||||||||||||||||||||||
|
Chapter 7: Displays and Emulations |
|
||||||||||||||||||||||||||||||||||||
|
Flavors: AT&T, BSD
Shell: csh
setenv DISPLAY host:0 xhost [[+-]host ...] application -display host:0
This is one thing that should become routine and second nature to you. There always comes a time as a UNIX system administrator when you will need to remotely log in to another host and display an X Window application back to your local host. You have to first allow access to be granted to the remote host to display X Window-based applications on it. It is possible that the display is not even set. If it is not set, you will not be able to display any windows or applications.
rocket 10% xhost xhost: unable to open display ""
Use the command xhost by itself to the determine if any hosts are allowed to display back to a local host you are on. In this case, no remote hosts are allowed to display on the desktop of host rocket.
rocket 11% xhost +planet planet being added to access control list
Using a plus sign (+) with the remote hostname adds a host to the access list. The host planet is now added to rocket's local access control list. This means that anyone on the host planet can display any X Window applications on the desktop of rocket. Use the xhost command by itself again to display the current access list of remote hosts that can display X sessions on the local system.
rocket 12% xhost INET:rocket INET:planet INET:localhost LOCAL:
You can see that the host planet is included in the access control list with network access to write X Window applications over the network to the host rocket. It is also possible to grant permission to any host that wants to display on the local system by passing a + sign without a hostname to the xhost command. This is considered dangerous because it permits anything to be displayed by anybody on the local host.
% xhosts + access control disabled, clients can connect from any host
After permission is granted to a remote host, the application on the remote host needs to know where to display the X Window application. There are two ways to display an X application to a remote host that has granted permissions, by either passing it through the application as an argument or hard-coding it into your environment variables.
If you do not intend to display all your applications and windows over on a remote system or back to the local host you logged in from, you can pass the display parameter to the application. Use a small unobtrusive program such as xclock to test that everything works okay.
planet 1% xclock -display rocket:0
This tells the remote host planet that the xclock program will be displayed over on the host rocket. If you see yourself working on the remote system extensively, you can set the DISPLAY environment variable with the setenv command and continue to work as if you were working locally on the remote system.
planet 2% setenv DISPLAY rocket:0 planet 3% env | grep DISPLAY DISPLAY=rocket:0
After the global DISPLAY variable is set, any X application executed from the shell will be sent directly to the host that was defined to be displayed on. No other arguments need to be passed to the application.
planet 4% xclock &
I know...you're saying this is all good and routine, but I don't want to keep typing setenv or attaching the -display parameter to all the programs that I run. There are some simple ways to set this up so you don't have to. Here are some things you can try:
If you always plan to display everything back to one host, you can set the DISPLAY variable in your .cshrc file on all the remote hosts you plan on logging.
setenv DISPLAY localhost:0
You can set up aliases in your .cshrc file for all the potential machines you plan on displaying X applications back from. Then no matter which hosts you might be logged in to, you will always be able to set the display.
alias setrocket 'setenv DISPLAY rocket:0' alias setmoon 'setenv DISPLAY moon:0' alias setpluto 'setenv DISPLAY pluto:0'
Execute a remote shell that displays back an xterm window. When any applications within that window are executed, it automatically displays back on the local host.
% rsh remotehost -n /usr/bin/X11/xterm -display $DISPLAY
With the capability for displaying applications from a remote host to your local host, the need for traveling to each system to run specific applications can be eliminated, saving valuable time and energy.
Displaying an application to another desktop is a dream come true for UNIX administrators. Those who support large corporations, campuses, and remote locations can work over the local network and even the wide area network in some cases. Think of the possibilities!
When users call, you can display their applications and then re-create the problem on your desktop. You can install and test software from your desk without physically going to the remote system. A great timesaver is being able to run the same GUI command on many remote systems without going to each and every system in your environment.
Displaying applications over a network is not problem free. There are certain things you have to look out for that can cause you problems. You have to know your network, application, and the various hardware that is involved in making this work.
Network speeds--If the network bandwidth is too slow, the remote application being displayed can run extremely slow and sluggish at times.
Application--If the application is excessively large and memory intensive, expect possible slow response times. Many third-party applications are designed to run locally to a system.
There are those who attempt to license a single host and display the application back to the rest of the systems in the environment. This is a good thought at first, but in most cases these applications run unbelievably slowly over the network to the point where they are useless. When this is discovered too late, someone has to go back to management and ask for more money.
Man pages:
rsh, xclock, xhost, xterm
|
UNIX Hints & Hacks |
|
||||||||||||||||||||||||||||||||||||
|
Chapter 7: Displays and Emulations |
|
||||||||||||||||||||||||||||||||||||
|
© Copyright Macmillan USA. All rights reserved.