There was a time when it was non-trivial to get X to work *at all*
through the gateways which were provided for staff and students. I was
so overcome with glee once I discovered how the old system actually
worked, that I wrote a short missive about it:<
http://student.uq.edu.au/~s343905/using-x.html
This document is now entirely obsolete. Completely and utterly so. Not worth the electrons it's printed on. Now, with the kick-ass new student firewall, you can just ssh(1) into the Student UNIX servers and tunnel your X connection through that.
Just in case ssh stream compression didn't make your X session fast enough, you can make it faster by using an extension to the X protocol introduced in December 1996 in X11R6.3, LBX (Low Bandwidth X). The first XFree86 implementation was in XFree86 3.3.
LBX performs compression and caching of the X protocol, which improves the peformance of X over low-bandwith, high-latency links (such as modem lines). Although you never expect stellar performance over a modem link, X performs particularly badly. X was originally developed for a high-bandwidth, low-latency environment (such as a LAN or one machine). Typical X applications assume this, and the X protocol doesn't encourage doing things differently.
Never heard of LBX before? Neither had I until some smart people pointed it out to me. For some more information on LBX, you can wade through the results for a search on "lbx" on Google. Or, you can just see the following URLs, because that's all I did.
http://www.linuxdoc.org/HOWTO/mini/LBX.html
http://agamemnon.ucs.ed.ac.uk/faq/linux/LBX-FAQ.html
http://linuxmafia.com/pipermail/balug-talk-archive/1999q4/000110.html
http://molt.zdv.uni-mainz.de/doc_link/en_US/a_doc_lib/x11/specs/pdf/lbx.htm
http://www.xfree86.org/~keithp/talks/lbxpost/index.html
http://www.xfree86.org/~keithp/talks/lbx.tar.gz
http://www.person-place-or-thing.com/baz/thesis_proposal/node34.html
http://zeus.eed.usv.ro/misc/doc/unix/cwx/file.16.html
I found the following URL (or at least the information referenced by the URL) particularly helpful in trying to get LBX and ssh to play nicely with each other. You might too.
http://www.gelatinous.com/aaron/tips/lbxproxy
So, how can you get the fantastic benefits of this little-known and seldom-used feature of X? You just follow my fantastic instructions, that's what! I've got the following working pretty nicely between cardozo (my machine at home) and the Student UNIX servers. (For the record, cardozo's nothing special. It's just running Red Hat Linux 7.0 with the X server courtesy of XFree86 3.3.6, because the XFree86 4 server for my video card has issues with TrueType fonts.) I suspect you'll be able to do similar things if you've got a Linux- or BSD-based system at home.
If you're running a Windows operating system, it depends on the X server which you're running. I don't know how much (or little) of this is supported by X-Win32 or anything else. You may, however, through the magic of Cygwin, be able to have XFree86 and OpenSSH running natively and do it all as if you were box with a sensible operating system.[0]
If you're running a more exotic operating system then I really have no clue. Even less of a clue that I ordinarily have, hard as that may be to believe. Although you might have half a chance of getting it working under MacOS X, it being almost a BSD and all.
So, onto the instructions. (N.B. These instructions only reflect my personal experience. They didn't screw up anything for me, but they might for you. Caveat reader. YMMV. HAND.)
First, connect to one of the Student UNIX servers. By using ssh-agent and a Host clause in
~/.ssh/config (if you're using OpenSSH), this can be a very economical
command line. Enable X forwarding and stream compression.
[dbs@cardozo ~]$ ssh -X -C remote.students.itee.uq.edu.au -l s343905
Last login: Sat Mar 17 20:02:47 2001 from ip-192-168-105-
...
[s343905@studentunix ~]$
Now, you need to start up lbxproxy(1), which, to X clients[1] seems like a
normal X server, but talks to a real, LBX-aware X server in LBX. How do you
make sure your X server is LBX-aware? You use xdpyinfo(1), that's what. If
the output from xdpyinfo has "LBX" in the list of extensions, then you're
fine. If not, you're screwed. :-)
lbxproxy can do stream compression, but, in our case, that's already
being done by ssh. So, we disable it at the lbxproxy level, but
preserve the X-specific compression.
[s343905@studentunix ~]$ lbxproxy -nocomp &
[1] 3788
[s343905@studentunix ~]$ Using port number '76'
So, if we point our X clients at the display studentunix:76, the X client will
produce a (horribly inefficient) X stream. lbxproxy will do some smart
stuff, and pass it through the ssh tunnel, which will make sure it's
stream-compressed (and secure) over the wire. This all seems ready to
roll, but when you try to do something:
[s343905@studentunix ~]$ xlogo -display studentunix:76
Xlib: connection to "studentunix:76.0" refused by server
Xlib: Client is not authorized to connect to Server
Error: Can't open display: studentunix:76
[s343905@studentunix ~]$
There's one easy solution to this:
[s343905@studentunix ~]$ xhost +
access control disabled, clients can connect from any host
[s343905@studentunix ~]$ xlogo -display studentunix:76
And the X logo pops up. But using "xhost +" generally isn't the
smartest thing to do. In fact, I think most sensible people would say
that it's downright stupid. Idiotic, even.
http://www.acm.uiuc.edu/workshops/security/x.html
http://www.acm.uiuc.edu/workshops/security/xauth.html
http://oliver.efri.hr/~crv/security/bugs/mUNIXes/xhost.html
http://archives.neohapsis.com/archives/freebsd/2000-02/0341.html
However, xhost(1) isn't the only way to control what clients can connect
to an X server. A more precise way (although I'm unsure of the level of
support it enjoys on non-UNIX-based platforms) is provided by xauth(1)[2].
By judiciously using xauth, we can allow the X connections of the
clients which we run to pass through to our target X server and avoid
any unnecessary security lapses.
First, find out the hexkey for the display where you wish to display the
windows. In my case, that's :0 on cardozo.
[dbs@cardozo ~]$ xauth list
cardozo/unix:0 MIT-MAGIC-COOKIE-1 058e21f2766ed6a87ede0a3d4a2c2909
cardozo:0 MIT-MAGIC-COOKIE-1 058e21f2766ed6a87ede0a3d4a2c2909
[dbs@cardozo ~]$
Now, we add this into the xauth database on studentunix for the (virtual)
display which lbxproxy is providing.
[s343905@studentunix ~]$ xauth add studentunix:76 \
MIT-MAGIC-COOKIE-1 058e21f2766ed6a87ede0a3d4a2c2909
Make sure we remove our dalliance with xhost.
[s343905@studentunix ~]$ xhost -
access control enabled, only authorized clients can connect
And, hey presto, look what works.
[s343905@studentunix ~]$ !xlogo
xlogo -display studentunix:76
/Et voilą/.
If you want to use the LBX display by default, then put it in the
DISPLAY environment variable. (If you don't, then you'll need to use
"-display studentunix:76" on the command line of every X command you want to
use LBX.)
[s343905@studentunix ~]$ export DISPLAY=studentunix:76
[s343905@studentunix ~]$
And that, people, is how you can make X tolerable over a non-LAN link. I can
tolerably run Emacs over a 28.8k modem link, but I'm not sure
whether even this can provide enough performance to tolerably run a
GNOME session outside of ITEE, but if you're into masochism (and if
you're using GNOME, you probably are) then you may as well give it a
shot. Having cable or ADSL might help, too.
David.
dbs@itee.uq.edu.au
[0] I've never done it before, but then again I've never been stuck at a
Windows machine for long enough to care. Personally, though, I've
always found the two-hour session limits quite infuriating.
Plus, imbuing your Windows machine with some free software is
*always* a good thing. You too can become a free software zealot!
It's never too early (or late) to jump on the bandwagon!
http://www.gnu.org/music/free-software-song.html
[1] Remember, X reversed the traditional client-server notion and,
despite what some people might say, even when you think about it, it
still doesn't make sense. And don't just take my word for it, see:
http://catalog.com/hopkins/unix-haters/x-windows/disaster.html
[2] Ibid.