[Watford] March Meeting Notes

[Yvan Seth]

Date: 2008-03-06
Open: 07:30
Close: 22:00
Location: Pitney Bowes Software, Leavesden Park
Attendees:
    Alan, Kat, Magnus, Marcin, Matt, Pete, Steven, Walt, Yvan

I'm afraid I'm guessing at a couple of the names again.  I don't have
much time to type this up, so please fill in any missing details if
there's points of interest to you.  Especially when it comes to further
ways to deal with displaying X clients on Windows boxen.

=======================================================================
=== A herd of ASUS Eees

While we waited for everyone to arrive Steven pulled out several new
boxes of Asus Eee PCs for people to play with.  These ones had not yet
been blatted with WinXP so were running the Xandros OS and attracted
much interest.

=======================================================================
=== Remote-X

I gave a rather choppy demonstration of connecting to a remote Linux
machine and using Cygwin to display X applications run on the remote
system.

To do this one thing is mandatory: an X-Server for windows.  The one I
demonstrated is X11 as provided by Cygwin:
    http://cygwin.com/
But the methods I demonstrated work just as well with XWin32 (non-free):
    http://en.wikipedia.org/wiki/X-Win32
Xming (free):
    http://www.straightrunning.com/XmingNotes/)
And others.

--- X windows via SSH

Using Cygwin you want to install the "X11-base" (under X11) and
"openssh" (under Net) packages.  Once installed start up the Cygwin
console (usually by clicking the icon the install puts on your desk)
and execute:
    startx
This will give you a Linux-like "xterm" running in windows and will run
an X-server that displays remote X windows as part of your Windows
environment.  Now, log into the remote system using by ssh-ing from this
xterm:
    ssh -C -Y user at remote.host.com
The -Y enables the X-forwarding and the -C is optional, it compresses
the data stream so less bandwidth is used.  The compression can result
in a performance enhancement over slow networks (the Internet) but
sometimes a degradation over LANs, I've honestly barely noticed a
difference between the two since I stopped using dial-up modems.
Anyway, after logging into the remote host with the above command you
can execute X applications, such as xclock, and they'll pop up on your
Windows box!

For this to work your remote Linux system must have the following line
in the /etc/ssh/sshd_config file:
    X11Forwarding yes
And it'll have to have X applications installed of course, you must
always have the "xauth" package installed too (not having this is a
common stumbling block.)  If the remote box supports normal local X
logins then you'll have no worries.

--- Using PuTTY instead

Steven outlined using Putty for the above instead of the 'ssh' command
from Cygwin.  First you'll still need a local X-environment running (so
'startx' for Cygwin).  In PuTTY configure the remote host as normal then
in the Connection->SSH->X11 configuration window tick "Enable X11
forwarding" and set "X display location" to "localhost:0.0".  Now log in
and you'll be able to execute the likes of 'xclock' as above.

An advantage of PuTTY is that you can save the profile and log in with
just a couple of clicks (with keys set up.)  

--- Non-SSH, using XDMCP

XDMCP is the X Display Manager Control Protocol and can be used to
directly log in to a remote system.  I demonstrated doing with with the
'gdm' login manager (default for Ubuntu) and Cygwin.  First you need to
ensure 'gdm' is configured to permit remote connections (by default it
is not), check the file '/etc/gdm/gdm.conf' and uncomment this line:
    RemoteGreeter=/usr/lib/gdm/gdmlogin
Then change this:
    Enable=false
To this:
    Enable=true
Now restart 'gdm' with
    /etc/init.d/gdm restart
Note that this will kill your current login if you're logged into the
machine locally via X.

With XDMCP enabled you can now authenticate your local X-server against
the remote system directly.  All the above systems can do this, in
Cygwin the method is to get the Cygwin console up as above then type:
    X -query remote.host.com :0.0
This should start up a full screen window and you'll be greeted by the
remote machines user login screen.  Log in and you'll have a full
X-session the same as if you'd logged into the Linux box locally.

--- Further...

There was more discussion about all of this but I don't have time to
write up further notes, in brief:
    1. The 'ssh' method is considered more secure.
    2. The 'XDMCP' method certainly should not be used across untrusted
       networks.
    3. You can get the equivalent of the 'XDMCP' method with 'ssh' by
       running a bare X server locally (i.e. run 'X' with no arguments)
       then use ssh via the Cygwin console or PuTTY to remotely execute
       a window manager (my example was 'wmaker')
    4. We tried to demonstrate the non-SSH method's insecurity but it
       was a bit too complex for us to work out on the night.

--- References

XDMCP: http://tldp.org/HOWTO/XDMCP-HOWTO/
    "both X and XDMCP is inherently insecure"
Cygwin: http://x.cygwin.com/docs/ug/using-remote-apps.html

=======================================================================
=== Questions

Walt has been having some trouble with his DHCP, where the machine does
not get the persistent lease on boot but will get the correct IP if
'dhclient' is run manually.  We discussed running the dhclient command a
second time as part of the init process, though I wouldn't recommend
doing this this is how to create your own init script (on Debian):

1. Edit/create a shell script in init.d, for example /etc/init.d/foo
   # cat /etc/init.d/foo
   #!/bin/sh
   echo foo
   read bar
   echo $bar
   read x

2. Insert it into the init process with the command 'updated-rc.d':
    # update-rc.d foo defaults
   You can get more usage information on what this does by consulting
   the man page "man update-rc.d"

That's it, this will install the custom script at default runlevels with
a default execution priority.  The methods for installing an init script
are different on Redhat and SuSE, there's also the "cross distro" LSB
compatibility effort and that may give you '/usr/lib/lsb/install_initd'
to install init scripts if you have a package such as "lsb" installed.

We went though the example above as a quick demonstration on the
evening.  One thing this showed is that if you don't add the right
metadata Ubuntu's new dependency-based init hack (parallel init script
execution) could give you slightly unexpected results.

END
-Yvan