/******************************************************/

/* 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 f
ine for most purposes.
One of the most popular emulators is "putty".
Sometimes however, you need a graphical terminal, for example to install third p
arty 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 stan
dard telnet terminallogin works.
From your PC you connect to your sever over a network, perform a login, and do a
ll 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 th
ings 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 wh
at 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 o
n the Host) windows will be displayed.
So your PC's display shows the graphical window, thanks to all libraries and cod
e 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 ge
t anyware.
If you use a Linux machine as a workstation, the whole X stuff is probably insta
lled 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", y
ou will enter
the prompt.
In this example, you are using the "environment" of the user "winstonc", and typ
ically a lot
of "environment" variables are set.
The "DISPLAY" environment variable stores the address for X clients to connect t
o.
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 you
r 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=<IPaddress_or_hostname>:number1.number2
20.15:0.0

# like e.g. 192.168.2

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 de
termined 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 possibl

y even read what you type.

The XAuthority method of access control, ensures that X applications have author
ization before allowing
them to connect to an X server. Authorization credentials are in the form of a d
isplay-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 .Xa
uthority file,
but many use the "mkxauth" command, which aids in the creation and maintenance o
f .Xauthority files.
Some others use the similar "xauth" command.
If you are interrested, take a look at the specific commands for your specific u
nix/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:
$
$
y
$
$

cd ~
chmod 755 .

# maybe a bit too wide permissions, change accordingl

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 mkxa
uth.