This is how I installed x11vnc on our Debian Lenny LTSP5 server, these are my notes, nothing more. Use at your peril!

Installing x11vnc

Enter the chroot

$ sudo chroot /opt/ltsp/i386

And update the repositories that the ltsp environment uses for apt-get:

# apt-get update
# apt-get install x11vnc

Create start-up script

Still in the chroot, edit /etc/init.d/x11vnc and copy in the following script:

#!/bin/sh

### BEGIN INIT INFO
# Provides:x11vnc
# Required-Start:$remote_fs $syslog
# Required-Stop:$remote_fs $syslog
# Default-Start:2 3 4 5
# Default-Stop:0 1 6
# Short-Description:Start X11VNC
# Description:Start VNC server X11VNC at boot
### END INIT INFO

case "$1" in
        start) 
                sleep 6
                XAUTH=`find /var/run/ldm-xauth* -type f`
                logger -f /var/log/x11vnc "Starting with $XAUTH"
                start-stop-daemon --start --oknodo --pidfile /var/run/x11vnc.pid --background --nicelevel 15 --make-pidfile --exec /usr/bin/x11vnc -- -display :7 -loop -passwdfile /etc/x11vncpassword -nossl -logfile /var/log/x11vnc -auth $XAUTH
        ;;
        stop)  
                logger -f /var/log/x11vnc "Stopping"
                start-stop-daemon --stop --oknodo --pidfile /var/run/x11vnc.pid
        ;;
        restart)
                logger -f /var/log/x11vnc "Restarting"
                $0 stop
                $0 start
        ;;
        condrestart)
                PID=`cat /var/run/x11vnc.pid`
                RUNNING=`ps h --ppid $PID`
                if [ "$RUNNING" == "" ]; then
                        logger -f /var/log/x11vnc "No process matching /var/run/x11vnc.pid"
                        echo "No process matching /var/run/x11vnc.pid"
                        $0 restart
                else   
                        logger -f /var/log/x11vnc "Process matching /var/run/x11vnc.pid exists"
                        echo "Process matching /var/run/x11vnc.pid exists - no action taken"
                fi
        ;;
        *)
                echo "Usage: $0 start|stop|restart|condrestart"
                exit 1
        ;;
esac

exit 0

Finalise start-up script

Still in the chroot, make the script executable and link it into /etc/rc2.d:

# chmod 755 /etc/init.d/x11vnc
# update-rc.d x11vnc defaults
# ls -al /etc/rc2.d/*x11vnc

Set x11vnc password

Finally, create the /etc/x11vncpassword file with the password you want to use to connect to your thin clients:

# echo "thepassword" > /etc/x11vncpassword
# chmod 400 /etc/x11vncpassword
# chown root:root /etc/x11vncpassword

Replace “thepassword” with your chosen password.

Alternative Method

The issue with the above method is that if you user does not reboot their client after logging off, then x11vnc does not restart. An alternative, remove the above symlink from /etc/rc2.d/S99x11vnc and instead use an ldm start up script by adding the following two scripts:

# /opt/ltsp/i386/usr/share/ldm/rc.d/I99-x11vnc
# LDM Script to start x11vnc

XAUTH=`find /var/run/ldm-xauth* -type f`
start-stop-daemon --start --oknodo --pidfile /var/run/x11vnc.pid --background --nicelevel 15 --make-pidfile --exec /usr/bin/x11vnc -- -display :7 -loop -passwdfile /etc/x11vncpassword -nossl -logfile /var/log/x11vnc -auth $XAUTH

The “I” in I99-x11vnc denotes that this will be run after X and before LDM, which is perfect for VNC.

# /opt/ltsp/i386/usr/share/ldm/rc.d/X99-x11vnc
# LDM Script to stop x11vnc

start-stop-daemon --stop --oknodo --pidfile /var/run/x11vnc.pid

The “X” denotes that this script will be run upon logout, so this is closing down the x11vnc server, ready to restart with LDM.

This method will still not cope with X being terminated with ctrl+alt+backspace, in which scenario you can ssh onto the client and run /etc/init.d/x11vnc condrestart - you could also add this in as a local app to be accessible from the server desktop.

References

• https://wiki.edubuntu.org/InstallX11VncOnLtspClients

Step 1: Sign up for Dynamic DNS

The first problem is that most people’s Internet service do not have a static IP address. In practice it is fairly static on modern broadband services, but, if you do not want to be fiddling about trying to find out what the current IP address is, then you need a dynamic DNS service.

Dynamic DNS gives you an unchanging address which is automatically mapped to the current IP address, whatever that might be. So for example you might have daddy.dyndns.xyz as your address. To make this work, you need to have a client machine on the network, that will keep updating daddy.dyndns.xyz with the latest IP address. Some home routers have this functionality built in.

I did some research and determined that the very popular http://dyndns.com service is reliable, and so I went ahead and signed up a new account for my father, and set-up a hostname for his router’s WAN address.

Step 2: Configure Client

If you’re lucky your router will support dynamic DNS. My father’s did, so I just logged onto the router and entered the dyndns account information, and it just worked perfectly.

If your router does not support dynamic DNS, all is not lost, simply install ddclient on a computer on the network (presumably, but not necessarily, the one that you want to be supporting):

$ sudo apt-get install ddclient`

Configuration of ddclient is simple, the ncurses configuration process takes you step-by-step through the necessary steps.

Step 3: Configure port forwarding

The next problem is that your router has a firewall that is designed explicitly to stop people getting into your network. We need to punch a small hole in that firewall. Needless to say this does have security implications, so we need to be careful.

So we need to open a port on the router and forward it to the machine that we wish to support. This machine does need to have a static IP address.

Log onto your router via its web management page. The main difficulty here is in finding the port forwarding option, when it is probably called something user friendly like Game Sharing or some other perversely unhelpful name. If you can’t find it, then you’re best of Googling for “port forwarding routername” where routername is the make and model of your router. Or just read the manual, if by some miracle you have one to hand.

But which port to forward? Your router will probably make it easy to forward the standard ssh port - port 22 - the problem is that everyone knows that is the ssh port and you may experience a high number of attacks on that port. In theory you should be safe enough with secure passwords, but personally I would not choose to forward the standard ssh port, but would instead add a custom service “ssh_obscure” on a different TCP port number and forward that to port 22 on PC that you wish to support:

Name: ssh_obscure
Protocol: TCP
Source port: 2121 (or whatever you choose)
Destination IP: (enter the client PC's IP)
Destination Port: 22

If it won’t let you specify a Destination Port, then it will forward to the same custom port on the PC. This will then require a change in the configuration of sshd on the PC, which I will explain in the next step.

Step 4: Install openssh-server

On the client PC, i.e. the PC you will be supporting, install openssh-server and its dependencies:

$ sudo apt-get install openssh-server

If you didn’t bother with the ssh_obscure suggestion above, then you are simply forwarding from port 22 on the router to port 22 on the client and no further configuration of openssh is required.

If you did set-up the ssh_obscure, but forwarding to port 22 on the client, then again no further configuration is required.

If you set up ssh_obscure, but were unable to set a Destination Port, then you are forwarding the same port to the client, so you will need to change the relevant setting in /etc/ssh/sshd_config. E.g. Port 2121. Then reload the ssh configuration with:

$ sudo /etc/init.d/ssh force-reload

Step 5: Install Fail2ban

As stated above, we have reduced the security of your network by taking these steps and we are now going to attempt to rectify this somewhat by installing fail2ban.

Some argue that this is unnecessary, if you have set a custom port for ssh and maintain secure passwords, but I see no reason for relying on security by obscurity. The main benefit of using a custom ssh port is to prevent the attempts in the first place, but hiding your front door is no substitute for locking it.

Fail2ban will monitor your /var/log/auth.log and block any hosts that have repeatedly failed to login correctly, by blocking them in iptables (the standard Linux firewall).

$ sudo apt-get install fail2ban

Next you should create a new file /etc/fail2ban/jail.local, with the following contents:\

[ssh]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 600

Strictly speaking the above is already configured in /etc/fail2ban/jail.conf, but I think it makes sense to take ownership of those settings by redefining them in jail.local. If you have set a custom ssh port, then set it in jail.local as above, replacing port = ssh with port = 2121 or whatever. I have reduced maxretry to 3 from the default of 6, as I found it was giving nearer to 18 attempts, thanks to the peculiarities of the auth.log file.

Finally reload these new settings in fail2ban:

$ sudo /etc/init.d/fail2ban force-reload

In order to test fail2ban, try and log into the client from another machine on the same network. You will need attempt to log in with the wrong password a number of times. This may not be exactly 3 times, but if you get to 9 attempts and it still has not blocked you, then there is problem.

fail2ban will only block you for 10 minutes, after 3 failed login attempts (you can change these settings as above).

Step 6: Testing SSH

At this stage you should be able to log in remotely to your client PC.

$ ssh -p 2121 username@daddy.dyndns.xyz

Obviously change 2121 for your custom port, or leave out -p 2121 if you are using the standard ssh port 22.

Step 7: Installing VNC

Having ssh access is wonderful, but not much help when your Dad asks you where his OpenOffice toolbar has gone; so we need to add VNC on the PC you wish to support:

$ sudo apt-get install x11vnc

And on the PC from which you will be providing support you need to install vnc-viewer, or use your preferred vncviewer:

$ sudo apt-get install xvnc4viewer

Step 8: Testing VNC

Now, you could have set up x11vnc to be running permanently with a password, and then you could set your router to port forward a custom VNC port to the client PC. This approach does significantly degrade your security and is in any case unnecessary. Instead we can just run it when we need it by using ssh, by typing this command from the PC from which you will be providing support and changing as appropriate:

$ ssh -p 2121 -t -L 5900:localhost:5900 username@daddy.dyndns.xyz 'x11vnc -noxdamage -localhost -display :0'

This will connect by ssh to the client machine, run x11vnc bound only to localhost (so no-one else can connect to it) and build a tunnel between the remote VNC port to your local VNC port.

One caveat is that the username needs to be the currently logged in user, otherwise x11vnc will refuse to start.

And finally on the PC from which you are providing support we just run:

vncviewer localhost:0

And you should now be looking at your father’s (or whoever’s) PC.

Whilst this does all sound pretty involved, all but this final step is only required once, then a quick ssh command and vncviewer and you are connected.

Warning

After completing this installation, the clients received an error on login about port 5900 already in use. Upgrading italc-client (by temporarily adding the sid repository to /etc/apt/source.list in the chroot and re-installing italc-client) fixed this problem.

However, I was unable to get an acceptable performance from italc for shadowing, and ended up install x11vnc. See Install x11vnc on LTSP5 for more information.

Install italc-client in chroot

$ sudo chroot /opt/ltsp/i386
# mount -t proc /proc /proc
# mount -t sysfs sys /sys
# apt-get install italc-client
# umount sys
# umount /proc
# exit

If you are using ubuntu rather than debian, or have switched to nbd instead of nfs, remember to do an ltsp-update-client after leaving the chroot.

Install italc-master on server

$ sudo apt-get install italc-master

Generate Key Pairs

$ sudo ica -role teacher -createkeypair

I tried in vain to stipulate -role admin - could not get the keys to work.

Set Permissions

$ sudo addgroup italc
$ sudo addgroup <userid> italc
$ sudo chgrp -R italc /etc/italc/keys
$ sudo chmod -R 640 /etc/italc/keys/private/
$ sudo chmod -R ug+X /etc/italc/keys/private/

Transfer keys to client

This assumes a standard /opt/ltsp/i386 chroot, change path to suit your installation.

$ sudo mkdir /opt/ltsp/i386/etc/italc/keys
$ sudo cp -r /etc/italc/keys/public /opt/ltsp/i386/etc/italc/keys/

Create client start script

Enter the chroot:

$ sudo chroot /opt/ltsp/i386

And create the following script:

#!/bin/sh
# /usr/share/ldm/rc.d/S20-ica-launcher
/usr/bin/ica &
true

Test

• Reboot client
• Log into client
• Open a terminal on the server and run /usr/bin/ica -noshm
• Run italc

References

• https://help.ubuntu.com/community/UbuntuLTSP/iTalc
• http://indianalinux.blogspot.com/2007/02/howto-install-italc-from-source-on.html
• http://wiki.ubuntu-fi.org/LTSP5_iTalc (Finnish)
• http://www.mail-archive.com/debian-edu@lists.debian.org/msg15477.html

Following the installation of Italc on our LTSP Server, users reported that they had several green icons in their system tray. This transpired to be the KDE session manager, which automatically restores all applications running at time of logging-off. I have updated my Install Italc instructions to include excluding ica from KDE session manager.

In trying to kill off the multiple ica processes, I found that ps can do more than just ps aux. I found that ps -fHu username would provide a tree-view of the specified user, which is much neater than piping ps through grep.

And then our /tmp filesystem filled up, and I just simply could not work out why. Until, at least, I managed to trash our virtualised Windows Server 2003 (running under Qemu), by inadvertently disabling its network card and thus triggering the server monitoring - which automatically killed and restarted it; 600mb freed up in a second.

This turned out to be a complete nightmare, and took several days to resolve. I never did manage to get x11vnc working on the client, nor did I manage to get italc (which I think also uses x11vnc) working on the client. In the end I settled for installing italc-client on the server, so that the client runs when users log onto the server, allocating each user a unique port, and putting a little green italc icon in their system tray.

This required upgrading qt4 from lenny (hardly ideal) and still works like a pig. Well viewing is fine, but the remote control is unusably slow.

I found it impossible to manage the list of users in italc; which changes according to the whims of DHCP. I ended up writing a script to use the output of “who” to populate the globalconfig.xml file in /home/username/.italc; if I have time I will add the script to my install italc instructions.

Something that we have become used to having under Citrix is the ability to shadow users, and I have been missing this since our forays into LTSP. I know it is possible, and I have been attempting to use the KDE built-in Krfb Desktop Sharing module. The problem with this has been that, all users being on the same hardware, it’s difficult to know to which screen number to connect. I guess there probably is a way, but when I used trial and error to find the right display, the performance was less than impressive.

So I decided to follow the masses and install x11vnc on the client, but suffice don’t have it working yet!

You may recall my recent installation of Edubuntu at home. Well I was surprised to find that the Thin Client Manager, AKA the Student Control Panel, missing. I Googled without joy, and ended up finding that thin-client-manager-gnome needed to be installed via Synaptic. I reported this at #edubuntu and ogra informed that they have replaced this with iTalc. I therefore removed thin-client-manager-gnome, but again I could not find any reference to iTalc in the menus. Again I Googled fruitlessly and again the solution was as simple as installing italc-master (the client was already installed). And it worked, straight off including screen shadowing.

Now all I need to do is to work out how to install iTalc on Etch! Perhaps not. At least not just yet.