| The X Terminal
page: How to use our
GNU/Linux
box as
an X Terminal. |
| As described in TipMe
and GraphMe pages, the
graphics mechanism is modular and transparent. Page Overview: A boring paragraph From the X Terminal's side From the Application Server's side A boring paragraph: We know by now that when we run a graphics application, in reality we run: the X Server a Window Manager a Desktop the X Client(s). X Server is the graphics mechanism. We can think of it as a Display Manager for ease of understanding. X Client is the graphics application that needs the X service. It can call all the prequisites needed, including libs, widgets (buttons etc.) etc. The two components in the middle can as well be absent. Then, no window or desktop behaviour is present, but the application can still run. A UNIX - GNU/Linux - *BSD - MS Windows Desktop can easily emulate a real (hardware) X Terminal's role because: a) An X Server can be installed and run b) It contains all the hardware needed: keyboard - mouse - graphics card - network interface. Let's call the local host that runs the X Server "X Terminal" Let's call the remote host that runs the X Clients "Application Server". Using an old computer as an X Terminal can be very practical as it only runs the X Server and all that we see inside running, in reality runs from a remote machine. I have revived an old P133 this way. From the X Terminal's side: There are two ways that I know best to connect to the Application Server. No root privileges are required for either way. 1) Remote commands to the Application Server In a shell like bash type: X & xterm -ls -display localhost:0.0 This will bring up X in the backround (active) and then call xterm to connect to this server. Q: Why the display command for xterm? A: xterm is called from the command line, after X is called. Therefore,xterm is called outside X, so it needs to know the X server to connect to, in our case, the local machine. Then in xterm type: xhost +filer This will add host "filer" (for example) to the list of hosts to accept X Client connections from. Then, give to filer an rsh or ssh command: ssh filer 'xterm -ls -display athlon:0.0' in which filer will assume the same username that you have in host athlon (in my case "micro") or change the user login approprietly. You can issue the remote command after a succesful telnet login also. The X Client is owned by the user logged in the second xterm (the one called in filer) When the new xterm comes up, call a Window Manager or a Desktop with its own Window Manager: blackbox or startkde or gnome-session or fluxbox or xfce4-session Then you can call an X Client (you could call it without the Desktop or WM previous calls) Q: This solution in very manual A: And very modular too. Alternatively we can start X locally, start Desktop os WM locally and run only the X Client from the Application Server. 2) XDMCP reguest to a running X Desktop Manager in the Application Server Desktop Managers are login managers for X that perform authentication and launch WM or Desktop as chosen from a list. This solution is very practical because: There will not be terminals and manual commands. The user can be chosen easily from a menu, just like in a local Desktop Manager. But it's not very "modular". After the remote login procedure, all X Clients as well as desktops and window managers will originate from the application server. Just issue: X -query filer The above command will be successful if: filer's Desktop Manager is configured to accept remote connections and a Desktop manager is actually running in filer. From the Application Server's side: 1) Remote commands from the X Terminal The first method is pretty straightforward if telnet or ssh are properly configured in host filer. As root, see /etc/inetd.conf or something relevant, uncomment the proper lines, kill and rerun inetd. A page for this will soon be up in ConfigMe. 2) XDMCP reguest from a remote X Server For the second method, keep in mind that if filer is not running in runlevel 5 (or the equivalent to Graphics login screen for your distro), in runlevel 3 chances are that a Desktop Manager is not called by the basic configuration files. Furthermore, the Desktop Manager has to be configured to accept connections from remote hosts. There are 3 Desktop Managers, all fine. xdm from the X package kdm the Kde one gdm from Gnome Let's see xdm configuration: /etc/X11/xdm/Xaccess /etc/X11/xdm/xdm-config /etc/X11/xdm/Xservers In Xaccess, uncomment the line containing #* (by erasing "#") to allow xdm to accept remote connections. Careful, uncommenting "*", xdm will accept connections from everywhere, which is possibly unsafe if you do not run a firewall. You can write a more sophisticated rule here than "*" of course, like 192.168.0.0/24 In xdm-config, comment the line: Display.Manager.requestPort: 0 Then switching to runlevel 5 will bring up a Desktop Manager and X. Or in the present runlevel call xdm: xdm or kill it first and call it afterwards: killall xdm ; xdm That's it. So, by now X Desktop Manager is up and listening to requests. For gdm study: /etc/X11/gdm (directory) For kdm study: /opt/kde/share/config/kdm or /usr/share/config/kdm (directory) Specifics for Kdm: In the relevant configuration directory, edit Xaccess and Xservers as you did for xdm In file kdmrc comment the line: Enable=false, because otherwise kdm will not accept the request from the remote (from the server's view) X Server. |