/******************************************************/ /* Short note on how to use x with your ssh terminal */ /* from your PC, connecting to a remote Unix host. */ /* */ /* Version: 0.3 */ /* Date: 3/12/2010 */ /* By: Albert van der Sel */ /******************************************************/ Many people connect to a Unix host, using a terminal emulator, like putty. It readilly gives the user an ascii oriented (prompt based) terminal, which is fine for most purposes. One of the most popular emulators is "putty". Sometimes however, you need a graphical terminal, for example to install third party software, which may just only provide for a "graphical setup". Or, maybe you just want to run an XWindows system like KDE and the like. Collectively, all those xwindows based graphical systems are often just called "X". One of the basic ideas behind X is the idea of remote displays, just like a standard telnet terminallogin works. From your PC you connect to your sever over a network, perform a login, and do all kinds of neat command line things remotely, but the display is on your machine. X is the method that allows you to login to the server and use neat graphical things remotely, but it's displayed on your screen. 1. XServer and xclient: ------------------------ In X, the "notion" of Server (XServer) and client (xclient) are reversed from what you know from "normal" Client/Server systems, like a for example an Oracle client which connects to an Oracle Server (the backend). In X, it's different. On your computer (your PC) your are running an X server that among other things watches a port for incoming connections. Also the X server sets up a "view window" where all the X application (running on the Host) windows will be displayed. So your PC's display shows the graphical window, thanks to all libraries and code of your local X server. The x client, is just running on the Unix machine, and sends everything it wants to display to your window. If you use a Windows PC, then you need to install an X server, before you can get anyware. If you use a Linux machine as a workstation, the whole X stuff is probably installed and running. 2. Setting the DISPLAY environment variable: --------------------------------------------- Remember, If you use a Windows PC, then you need to install an X server, before you can get anyware. The x clients are running on the Host (the remote Unix machine). If you logon to that Host with a terminal, using some account like "winstonc", you will enter the prompt. In this example, you are using the "environment" of the user "winstonc", and typically a lot of "environment" variables are set. The "DISPLAY" environment variable stores the address for X clients to connect to. So, this value specifies some XServer address that's running on your PC. So, if you want to start some x client application, it should communicate to your PC's X server. That's why you need to check if your DISPLAY variable is correctly set. For checking, you might use; $ set | grep DISPLAY which shows you the presently set value (if present it all). If it's not ok, set the environment variable (in sh or ksh shells) like so: $ export DISPLAY=:number1.number2 # like e.g. 192.168.220.15:0.0 Since you might have running multiple XServers on your PC, the "number1" usually discriminates between them. But usually it will be simply "0". In principle, multiple display's are possible per XServer, and that's usually determined by "number2". So, here are a few examples: $ export DISPLAY=192.168.220.15:0.0 $ export DISPLAY=192.168.220.15:0.1 Usually 0.0 should work. If you now run a simple x client application, like xclock, the xclock should be shown on your PC. This way, you should be able to run almost all x client graphical applications. ~/.Xauthority: -------------- There are multiple implementations to secure X, and one popular method is using the ".Xauthority" file. It's probably best if an X server does not accept connections from just anywhere. You don't want everyone to be able to display windows on your screen. Or possibly even read what you type. The XAuthority method of access control, ensures that X applications have authorization before allowing them to connect to an X server. Authorization credentials are in the form of a display-specific "magic cookie" that the X application must present to the X server. If the cookie is what the X Server accepts, then it will allow access to that application. All unix and linux systems have their own maintenance commands to manage the .Xauthority file, but many use the "mkxauth" command, which aids in the creation and maintenance of .Xauthority files. Some others use the similar "xauth" command. If you are interrested, take a look at the specific commands for your specific unix/linux system. Maybe one application might be of interrest: -- Merging a working .Xauthority file in your file. Suppose user1 has a "good" .Xauthority file in it's home dir. Suppose user2 does not have such a "good" .Xauthority file in it's home dir. You might do the following: - As user user1: $ cd ~ $ chmod 755 . # maybe a bit too wide permissions, change accordingly $ chmod 755 .Xauthority $ set |grep DISPLAY DISPLAY=192.168.220.15:10.0 - As user user2 (from the same terminal): $ cd ~ $ export DISPLAY=192.168.220.15:10.0 $ xauth merge /home/user1/.Xauthority Or if mkxauth must be used: As user2, merging Keys from the Local .Xauthority file of user1: $ mkxauth -m user1 here, mkxauth adds the keys in user1/.Xauthority to user2/.Xauthority, replacing any keys which already exist. The ~user1/.Xauthority file, ofcourse must be readable by the user running mkxauth.