Ubuntu 14.04 LTSP Docker Container

Just finished creating a redundant LTSP server as a Docker container.  Using a Dockerfile, we can now build portable LTSP servers to host both thick and thin client PCs. This of course depends on the LAN having at least DHCP and DNS already provided.  DHCP is used to support the PXE boot process, while DNS is used by the Dockerfile to resolve Ubuntu APT Repository package host IPs.  Thus, an Internet connection is also needed.

In this scenario, the container is running on the "docker01.devops.mydomain.com" CentOS 6.5 server.  LTSP ports were forwarded through the "devops.mydomain.com" VLAN Gateway (Zentyal server with two ethernet cards) to the docker01 host.  This allows clients on the normal domain LAN to hit the docker01 host behind the gateway on the VLAN.  The container running LTSP then has the gateway's forwarded ports mapped to the docker01 host so the clients can access the LTSP services.

Port 69/udp - TFTPD, serves the PXE boot configuration to clients referred by DHCPd.
Port 10809/tcp - Network Block Device daemon (NBDd), serves the base chroot up as a block device for the client. The external port is 10809 as well.
Port 22/tcp - SSH, serves the authentication and home folder via "SSHFS".  The external port is 2222 so that it does not conflict with the default SSH port 22 on the docker01 host.

Initially had some trouble with SSHFS due to custom security configurations of the 'Dockerhub' provided Ubuntu 14.04 image.  Essentially my SSH connections were being closed by the server as soon as authentication was completed.  I speculated a PAM configuration, but didnt want to dig through all the undocumented changes.  So, I performed a fresh install of Ubuntu 14.04 Server edition (~900MB) on a VM and exported the file system as a gzipped tarball, excluding /sys and /proc.  I then imported the file system in to a new docker container.

Dockerfile:
FROM champion:ubuntu-base #custom ubuntu 14.04 image
MAINTAINER championofcyrodiil@blogspot.com

RUN apt-get update

RUN apt-get install -y ltsp-server
RUN ltsp-build-client --arch="amd64" --fat-client
RUN ltsp-config lts.conf

Mannually Update lts.conf:
Port 22 would likely conflict with the docker host's SSH port. So manually add 'SSH_OVERRIDE_PORT=2222' below the [Default] tag inside /var/lib/tftpdboot/ltsp/amd64/lts.conf.  Also add 'SERVER=' so that the client hits the docker host w/ mapped ports, since it can't see the container's resolved host that is used by default.  The value should be the IP of your Docker container's host.

Run Command:
$ docker run -h ltsp -it -p 2222:22 -p 10809:10809 -p 69:69/udp -v /data/ltsp-home/:/home/ -v /data/ltsp-opt/:/opt/ --privileged=true cott:ltsp /bin/bash

-h Sets the hostname to 'ltsp', although this does not really matter, it helps to know what container your attached to.
-p Maps specific ports. (Uppercase P will use the docker range, check docker run usage)
-v The first mount point specified is the docker host path, the second mount point (after the colon) is the mount point inside the container.
--privileged=true Gives the container permissions to access kernel parameters and other information from /proc, this is definitely needed when you build the LTSP fat client.  I left it on during run time as well, but may not be needed.

Once the container has started and you're at the bash prompt, here you just needed to fire up the daemons:

$ service ssh start
$ service tftpd-hpa start
$ service nbd-server start

Press Ctrl+P, Q to drop from the container's bash prompt w/o killing the container's root bash process.  Ultimately you would want these service calls in a custom bash script with the 'wait' command at the end, and specify it in your Dockerfile as the default command.  But for sanity's sake, above it is a manual process to get the gist of what needs to happen.

[user@docker01 ~]$ docker ps -a
CONTAINER ID        IMAGE                                      COMMAND                CREATED             STATUS              PORTS                                                                                                NAMES
2c09964e1882        champion:ltsp                                  /bin/bash              2 hours ago         Up 2 hours          0.0.0.0:69->69/udp, 0.0.0.0:2222->22/tcp, 0.0.0.0:10809->10809/tcp                                   ltsp_server

LTSP Client Login Screen

Ultimately the configuration needs to be adjusted so that the fat/thin client connects to the docker container's host, with ALL LTSP required ports (69, 10809, 22) mapped to the container using the -p options with the docker 'run' command, and modifications to the client's tftpd provided ltsp configuration (/var/lib/tftpboot/ltsp/amd64/lts.conf) to support the changed SSHFS port, which is modified to 2222 in this post.

nomachine (!M) NX client on ubuntu LTSP thick/fat clients

The NX client/server software released from the company NoMachine, is fantastic.  I did discover that their Linux x86 installer does not properly handle missing dependencies on a CentOS 6.5 Minimal installation.  But it was my fault for mistakenly choosing the wrong binary from their download site.  Nevertheless, A few yum installs later, and even their 32 bit client is fantastic! Of course, I'm running their x64 client in our development environment now.

There is a lot to take in when you first run the client tool.  Its classy simple icon, installer, and website pitch, leads you to believe this magic tool will just work without a lot of features.  And for me, it did.  Every time. On different platforms.  The streaming of multimedia through the nx client over seperate UDP port is genius. And there are tons of small features that make this worth the effort.

There isn't a custom view you can't get with their client.  All of your devices are integrated as well.  I haven't even started to use collaboration tools.  But they are there if you need them, and even include recording video sessions.

I am running their software on the newest Ubuntu 14.04 LTSP "fat" client desktop.  I initially ran into an issue with the thick client LDM sessions not properly locking the screen.  Filed a bug report with launchpad here: https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1316320.  I was able to work around by installing the classic xscreensaver package with the gl extras.  Not only is this batch of screen savers really cool, but it enables you to create a desktop and unity bar shortcut that will activate the xscreensaver-command lock.  Just make sure you enable the authentication dependencies on on the client image as well.  Otherwise your screen cannot be unlocked if your client session is logged in with a terminal server account that isn't also on the image.

The hardware I chose was the Intel NUC.  There are several variations to this model, but the model #D34010WYKA worked great for me.  With a modern monitor and using the display port as the primary output.  Running this PC without hard disk or wireless networking is very snappy.  With the NoMachine client on top of that, I can stream Youtube video with audio, flawlessly from a headless KVM running CentOS 6 and a "nohup" GDM session.  It was quite impressive.

My next investigation will be deeper into virus scanning solutions for the LTSP environment.  Although the client image is read-only.  A user can still execute downloaded code from their home folder, or temporary write space on the RAMfs (/tmp).  They could exploit vulnerabilities on your network systems and create back door entry points, causing information leakage, and more.  Often users who aren't intentionally malicious will pick up these Trojans and viruses from various websites.  Having a modern virus scanning engine will stop a lot of this junk.  It may not stop someone creating custom code and targeting your network specifically.  But it will help ensure avoidable accidents don't happen.

ClamAV is looking like a good bet.  It is an open source (GPL) antivirus engine.  But McAfee has a lot of years under their belt and is already on the approved list for a lot of organizations.  Corporate solutions tend to have a bit smaller footprint than the Best Buy 1st year free edition you often get with buying a PC from a partnered vendor.  And paid products usually include personal support.

Thin Client Computing with Ubuntu Linux

I used Ubuntu 12.04 ALTERNATIVE ISO to perform the F4 Mode "LTSP Installation" during ISO boot.

LTSP is a Thin Client solution for Linux operating systems.  This was chosen because of the preferred use of Ubuntu Linux for development.  Benefits of LTSP are as follows:

·      Reduced Costs – Thin Clients require fewer resources than traditional Thick clients and therefore have a lower procurement cost.

·      No Licensing Fees – LTSP is open source software released under GPLv2 License.

·      Less Maintenance – Single point of control is the operating system image on the thin clients.

·      Security – LTSP clients are secured via SSH and are restricted to their own LAN.

·      LTSP Display Manager (LDM) – Python application for remote desktop SSH sessions.  KDM/GDM do not support remote SSH sessions.

Typical LTSP Layout

LTSP is typically run from a single server with two network cards that piggyback the LTSP isolated LAN and the larger network.  The LTSP Server uses NAT to provide connections between thin clients and the rest of the resources on the larger network.  This allows more control over the connections between developers and network systems and services.  Developers still have access to web services and network bound APIs they need, without necessarily having access to sensitive management protocols and systems.

LTSP supports a concept called ‘screen scripts’.  Multiple screen scripts can be run at the same time on different virtual consoles. (Ctrl + Alt + F[1-9])  User’s can toggle between screens while Screen six (or seven?) is reserved for the LDM.   Screen scripts can also be used to enable rdesktop for connecting to a Windows Server. 

LTS Configuration allows many custom configurations to be applied per client machine.  Here are some examples:

[AA:BB:CC:DD:EE:FF]

# Use nvidia driver for this thin client, overriding auto-detected driver

XSERVER = nvidia

[FF:EE:DD:CC:BB:AA]

# Set Screen 7 of this client to an RDP session rather than LDM

SCREEN_07 = “rdesktop 192.168.0.253”

A new feature of LTSPv5 is the ability to run linux applications installed on the chroot (“change root”, the image used by the thin clients) environment from within the LDM session.  This means reduced server load, enables use of graphics intense multimedia applications, and enables use of applications that require direct hardware access.  Drawbacks include increased chroot maintenance and increased hardware requirements on thin clients.

Local devices can also be supported with thin clients; so removable media such as CDROM and USB Flash drives can still be used on the thin clients.

Printers are supported and spooling is done on the server. No client-side print driver management required.

Sound is redirected from the server to the client using PulseAudio.  This network-aware client-server sound system can easily go through NAT firewalls.

Although not yet tested, LTSP also supports use of “Thick” clients.  Also known as Fat Clients.  These client machines would have a larger network block device root file system containing a complete OS with all desired additional programs (i.e. Chrome). Since processes are running on the client rather than the server, an admin cannot kill them from a central location.  Internet connectivity is provided directly to the client, so the client needs to be directed to an Internet gateway.

https://help.ubuntu.com/community/UbuntuLTSP/