Peter's Blog

Xming is an X server for Windows. With it one can run linux applications on a remote linux box with the X user interface windows appearing on ones Windows desktop:

xming demo

Internet Explorer, xeyes and xterm in perfect harmony.

How to do this wonderous thing?

• install xming
• run xlaunch to fire up xming as your windows X server (should be added to quick launch), selecting the following options:
  • Multiple Windows (each app gets its own windows window)
  • Display Number 0
  • Start no Client (client is the program that runs)
  • No Access Control (I'm a trusting soul)
• you now have an X server on your windows box as display :0. An X server is something that displays the user interface for X client programs (X keeps you on your toes by using counter-intuitive terminology).
• open putty at the configuration of your favourite linux box.
• enable the X forwarding option:
  
  

  X forwarding in Putty

  the 127.0.0.1:0 means remote X clients will display on your new windows X server (:0) running on your pc (127.0.0.1)
• open the ssh connection in putty and enter a command such as xterm. Amazingly, an xterm window should open on your local pc! It's wonderous, xterm is running on the remote pc but the user interface is on your windows box.

Interestingly, the ssh session you open has a DISPLAY environment variable open that tells the X clients you launch from it where to stick their displays.

peter@server:~$ echo $DISPLAY
localhost:10.0
peter@server:~$

Through the miracle of ssh this is routed back to xming on the Windows box.

Now, how about if beyond your gateway ssh server is another ssh server and you want to run your X client applications on that? The answer is amazingly simple. Open the session on the gateway server as described above and then use the command:

ssh -X name-of-other-server

you now have a command prompt on the remote remote server and if you now run

xterm

then again you get a xterm display coming up on your local windows pc but this time from the remote^2 box.

UPDATE: troubleshooting

• may need this in /etc/ssh/sshd_config

  X11UseLocalhost yes
  

• may need to

  sudo apt-get install xauth
  

  I needed this on a previously x-less box where I had installed gitk to do some git study on a headless server box

Somebody at work was fiddling with the fuse box and took out all the servers in the IT room. I rebooted them all but our main file server wouldn't boot, the hard disk partition was fried.

I used a knoppix CD (excellent tool for any pc that won't boot from its hard disk) to delete the corrupt partition and then reinstalled Windows 2k server on it. Experience has taught me that there is little point in trying to repair windows installations. Fortunately this file server is set up with two disks, one for the OS and another for the data. This is a nice arrangement as if either disk dies, that's approximately half the work required to get the thing back up. I only had to reinstall Windows.

Things were back online by lunchtime, the only problem being that one of the computers in the building was unable to access the new shared file system: mine! Vista strikes again (this is one reason why I am using Vista, to iron out these sillies). It wouldn't connect to the file share without prompting for user name and password and it wouldn't accept any that I gave (apart from those for a local account on the PC, it wouldn't accept domain account details).

I decided the problem may be that in my haste to get the files online and people working, I omitting to install the latest service packs on the server. I ran the setup for service pack 4 and then remotely rebooted the server from home early this morning while nobody was using it. I connected to it using an ssh tunnel and ultravnc. For reference, the ssh tunnel command was:

ssh -L 5900:192.168.0.54:5900 me@work.com

This is saying, 'connect port 5900 on the pc 192.168.0.54 on the remote network to port 5900 on my local pc'. I connected to a linux server and used this as a relay to connect to the file server. I was able to open ultravnc at 127.0.0.1:5900 and see the windows desktop of the file server. Secure, magical, free. Yes, I could do all this with VPN's, Windows Remote Desktop, Terminal Services or whatever but ssh/vnc is much easier to set up and is immune to random weird Active Directory problems.

I opened 'Computer Management' and 'Shared Folders' and 'Open Files' which gives a nice list of who is using the file server. One user had 'desktop.ini' opened, nothing important so ZAP.

Anyway, the service pack did the trick and when I got to work Vista connected instantly.

Lessons learnt:

• Know where the Windows Install disks are
• Have the licence numbers printed and hung on the wall (not in a file on the server that just died, in an Access 2003 database, in a room full of servers with no copies of Access).
• Buy a UPS, although it runs the risk that nothing ever fails and everyone thinks administration is easy. With the right tools it is, but don't let the world know.

Just got X going over ssh again, so a reminder to self on how I did it:

• make sure

  X11Forwarding yes
  

  is in /etc/ssh/sshd_config at the server end
• then, in client:

  ssh -X -2 user@server
  

  • -X means X forwarding
  • -2 forces v 2 ssh protocol
• this should give you a remote terminal. In it start whatever application, e.g.

  xclock &
  

  this will be running on the remote system but will display locally.
• if you get the error "cannot connect to X server localhost:10.0" then you need to do

  xhost +
  

  in a local terminal: the error means the remote app cannot open an X window on your local system, xhost + releases this.

I tried a suggestion Breezer left in a comment. It allows you to create shortcuts to your ssh logins. Here is the recipe:

• Create a symbolic link from your hostname to something called ssh-argv0. You might have to find it first:

  $ which ssh-argv0
  /usr/bin/ssh-argv0
  $ ln -s /usr/bin/ssh-argv0 ~/mysshserver.org
  

• Now you can connect to mysshserver.org by typing:

  $ ~/mysshserver.org
  

That's it. If your username is different on the ssh server then you should use:

$ ln -s /usr/bin/ssh-argv0 ~/username@mysshserver.org

Combined with bash tab completion this is a handy little tip.

For my ssh server I have disabled root login and I have chosen a slightly less common username and reasonably tough password but still I get people testing the locks. In the log files it is typically shown as a burst of login failures due to unknown name/incorrect password. This is no more than an annoyance, log files full of rubbish, but I'd like to prevent it and who knows, some day someone may hit the jackpot.

Linux iptables has a neat trick to limit the rate of connection attempts: three failed connection attempts and you can ban whatever is trying to connect for a couple of minutes. This is cool as it will still allow you yourself in as long as you get the password right in the first attempt or two.

I use the firewall module in webmin to manage iptables and I figured out how to implement this feature. It can be edited through webmin but I found it easier to edit the /etc/webmin/firewall/iptables.save file directly and to use webmin to apply it. This is the important bit:

# Allow connections to our SSH server from my IP address
-A INPUT -p tcp -m tcp -s 12.34.56.78 --dport ssh -j ACCEPT
# Allow connections to our SSH server from my other IP address
-A INPUT -p tcp -m tcp -s 65.66.67.68 --dport ssh -j ACCEPT
# Allow connections to our SSH server from localhost
-A INPUT -p tcp -m tcp -s 127.0.0.1 --dport ssh -j ACCEPT
# Allow three connection attempts in 60 seconds for anyone else
-A INPUT -p tcp -m tcp -m state -m recent --dport ssh \
   --state NEW  --set
-A INPUT -p tcp -m tcp -m state -m recent --dport ssh \
   --state NEW -j DROP  --update --seconds 60 --hitcount 3

One objection I have read to this technique is that it can allow someone to lock you out of your own server by continually hitting it with spoofed IP packets of your own originating server. For this reason I added rules to let connections from my normal haunts straight in: if someone bothers to IP spoof these addresses then they are talking directly to sshd and cannot do much more than a DOS attack, no different to if the firewall was not there. This also means I can get the password wrong or open and close connections as often as I like from the computers I normally use.

I could simply deny access from any alien IP except that the IP address of my home PC is not technically static (although it doesn't change very often) and I don't want to lock myself out if it suddenly changes. Besides, who knows, I may be out and about and want to log in (putty and a USB memory key, the world is mine).

This appears to work in both ubuntu and debian.

This is the script I am using to back up my debian dedicated server to my ubuntu desktop. It uses ssh and rsync. It uses the cool rsync link-dest trick so that instead of creating multiple copies of the same file, it creates only one copy of the file with multiple hard links to it. I have my ssh keys set up so I don't need to give a password to log in via ssh.

This uses a 'pull' technique: the desktop reads the files from the server using this script.

This is not entirely efficent in that it will create a new set of backup files even if nothing changes: if you run the script ten times in a row then you will end up with ten identical sets of files. However, it backs up a web site that changes every day so running it once a day is valid.

Next job is to put selected files within the backup set into subversion. I decided against using subversion for everything, I can't see a way to automatically delete files bit I'd like to put the main sql dump into subversion.

   1  #!/bin/bash
   2  
   3  #
   4  # Rotate old backups:
   5  #   $1 = remote directory to backup
   6  #   $2 = local backup directory
   7  #
   8  function rotate {
   9      # Ripple old backups
  10      rm -rf $2/Backup9
  11      mv $2/Backup8 $2/Backup9
  12      mv $2/Backup7 $2/Backup8
  13      mv $2/Backup6 $2/Backup7
  14      mv $2/Backup5 $2/Backup6
  15      mv $2/Backup4 $2/Backup5
  16      mv $2/Backup3 $2/Backup4
  17      mv $2/Backup2 $2/Backup3
  18      mv $2/Backup1 $2/Backup2
  19      mv $2/latest $2/Backup1
  20  
  21      # Copy current version to latest, creating hard links where files have not changed.
  22      #
  23      rsync -avz --delete --exclude=.svn --link-dest=$2/Backup1 -e ssh $1/  $2/latest/
  24  
  25      #
  26      # Put a date stamp in the backup directory.
  27      #
  28      echo >`date +$2/latest/Backup-%Y-%m-%d` "Hello Peter"
  29  }
  30  
  31  rotate sshusername@ssh.server.address:/var/www/petersblog.org /home/peter/Backup/petersblog.org
  32  

I have implemented a daily backup from my oneandone dedicated server to my home desktop pc. I used rsync over ssh using the notes I wrote myself which work with ubuntu as well as windows. It is only backing up the websites, I'm not backing up the configuration yet, I could add a backup of /etc only that has to run as root.The PC is set up to turn itself on everyday via the BIOS, it will run the backup, do any other daily stuff I can think of, then switch itself off.

At the server end, just before the backup schedule, the mysql databases for the websites are all dumped. The sql for this site is now 9M although a lot of that appears to be server logs.

Once the backup has reached the desktop pc I'd like to create some form of historical backup and I am deciding whether to create incremental differences or chuck everything into subversion. I am leaning towards the latter.

One option for the servers daily activities could be to download podcasts and dump them onto my phone...

I found one advantage of using ssh (e.g. putty) over vnc: no error bells. I was using a terminal under vnc and the bells were driving me mad. I disabled them in vim with:

:set visualbell t_vb=

but still got them on the bash command line. Tried various things from google to disable them at the linux end but nothing worked. Tried disabling the sounds in vnc (Control Panel/Sounds, VNC = None) but not joy.

Don't especially want to unplug the speaker so I went with the flow and used ssh.

Sudden thought: maybe I WAS going mad?

Looking through the Linode control panel options I discovered that it is possible to request a 2.6 kernel instead of the standard 2.4. I tried this and it indeed booted up but ssh fails to work. I can still log in through the linode console which appears to emulate a tty console so you can watch the system boot and log in that way but if I try to ssh the connection gets suddenly closed with no clues as to why, not even in the sshd log wth full debugging enabled.

There is mention of some odd devpts thing in kernel 2.6 being to blame for these ssh problems but I haven't pinned it down yet.

I resized the disk space on my Linode to free up 400M for a debian linux install, to use to rescue the main ubuntu install if I ever break it. You can change the size of your partitions without losing all your data if you are using ext2 or ext3. Cool.

Linode is looking good.

Got a Linode and I've installed ubuntu on it. So far it seems really quick: ssh login is fast and responsive, better than site5. This may be because the server does not have many users yet or maybe because it's 8:30 on a sunday morning.

It is just like my Ubuntu box at work but 10x faster.

I'm paying monthly for the linode, just trying it for now. If I'm still using it in August I may ditch site5 as linode is far cooler.

Damn, have to go out