LTSP has the ability to offer thin or fat clients which boot from a centrally controlled image from a server using tftp network boot.
The following guide uses Xubuntu 18.04 (LTS desktop 64bit version), using a ‘chrootless’ (aka PNP ltsp) setup, which unlike the more common chroot-ed ltsp setups, uses the configuration of the server’s desktop to create the image the clients will boot from. The reason for not doing this in the past was related to the DHCP setups for such networks, but dnsmasq used in conjunction with a separate dhcp server makes for a simpler setup, as long as using the server’s desktop to create the client desktop is not an issue. With a chroot setup (my first attempt) a server can have no gui and multiple desktop environments can be deployed, independently of how the server is setup, if required. I found it more complex to administer and the script for resetting the clients upon each boot I found never worked.
The following is based on this guide, which in my opinion breathes new life into ltsp after what looked to me like it not being developed much recently. For those wanting to create public lab/ICT suite setups on a budget there is still much to be gained from using this approach, especially when combined with the possibilities that Dashamir Hoxha suggests. LTSP can offer normal user accounts for many users, but in the public lab situation clients that auto login and then reset themselves clean upon logging out is a real administrative boon. All the clients have a single point of control: updating, maintaining and adding new software for the lab is done once on the server using a template ‘guest’ account. This creates the settings for the all the individual client accounts to clone when they boot.
Create a clean Xubuntu 18.04 server
apt install --yes synaptic
add-apt-repository --yes ppa:ts.sch.gr
apt update
Choose the ‘chrootless’ option
apt install --yes --install-recommends ltsp-server-standalone ltsp-client epoptes gpasswd -a ${SUDO_USER:-$USER} epoptes ltsp-update-image --cleanup /
Choose the single NIC option
ltsp-config dnsmasq
Create the lts.conf
ltsp-config lts.conf
Auto-create ‘guest’ accounts using Dashmar’s script: https://gitlab.com/Virtual-LTSP/VirtualBox/blob/bionic/scripts/create-guest-accounts.sh
Suggested location for the creation of this file: /usr/local/bin Then: chmod 0700 create-guest-accounts.sh and execute the file (as root) from within that folder with: ./create-guest-accounts.sh
This creates 254 users: ltsp1 – ltsp254. These user accounts will be allocated per client machine based on the IP address given to each client by (in my case) the pfSense DHCP server. ie 192.168.14.100 will login with user ltsp100 . Nb. in pfSense DHCP server must be running for the ‘LTSP’ subnet, and the Ignore BOOTP queries option must be checked, becasue the LTSP server must respond to the bootp queries.
The script also does a number of other things: it creates a user called ‘guest’ which acts as a template master for all the client guest accounts. Any changes to the configuration of that account/desktop are replicated to all the ‘ltspxxx’ accounts. When those accounts logout they are reset to the guest account template each time (brill), means all the usual detritus of people logging in and using a pc is eliminated. Serious kudos to Dashamir Hoxha for this work. Strangely I had thought that this setup would be ltsp default, but it’s taken some time to find the solution and deploy it.
Adding:
[Default]
LDM_GUESTLOGIN=True[00:25:64:e6:b5:0a]
LDM_AUTOLOGIN = True
LDM_USERNAME = wesleyonline1
LDM_PASSWORD = wesley
to the lts.conf file, (on the chrootless setup it’s at /var/lib/tftpboot/ltsp/amd64/lts.conf ) adds a ‘Login as Guest’ button to the LTSP client login screen. Ideal for very large deployments. In my smaller lab I’ve edited the lts.conf file adding:
[00:25:64:e6:b5:0a]
LDM_AUTOLOGIN = True
LDM_USERNAME = ltsp100
LDM_PASSWORD = ltsp100
… for each pc. This is allows clients, per mac address, to be automatically logged in with a particular account number. In our context we are often dealing with people who have never used a PC before, so not requiring them to use a username and password as the first thing they have to do is advantageous.
Issue re: “Configured directory for incoming files does not exist Please make sure that directory “/home/guest/Downloads” exists or configure it with blueman-services”
remove the applications related with bluetooth because the ltsp123 client accounts cannot access the absolute path from the template ‘guest’ account. On the xfce desktop the ‘Application Autostart’ list is found in the ‘Session and Startup’ section of Settings Manager. Remove the ‘Blueman Applet (Blueman Bluetooth manager)’ on your guest template account from this list.
Ubuntu and the XFCE desktop which Xubuntu uses is usually not greeted with the excitement I get when logging into it. ‘Oh it’s not windows’ is often the fearful or dissapointed reaction. Users have soon realised that navigating a slightly different desktop isn’t as hard as they might have thought – not as hard as adapting to Windows 10 in my experience, however, to make things less fearful I have ‘made it look like windows’ (a bit!)
There are several places to get themes and icon sets to make the xfce desktop environment look a bit like windoze. I have used boomerang (google for it). To make them available (for all users) on a pc add the theme folder to: /usr/share/themes . Add the icons to /usr/share/icons . Add the win10 wall paper to /usr/share/xfce/backdrops/ ensure the file has permission set: 0644
You might need to create the icon cache: sudo gtk-update-icon-cache /usr/share/icons/Windows-10-Icons/
Printer:
To get the Xerox printer working with the LTSP clients use CUPS. This connects using ipps. On the guest login (template master) browse to: localhost:631 and the CUPS admin page appears. Although the Xerox C405 might be listed, I’ve had better success with adding the printer as a new one (couldn’t share the automatically detected ones); no need to install drivers for an ipp printer (which prints using http). Within the control webpage go to: Administration and choose: ‘Share printers connected to this system’ this allows the client PCs to see the printer. Only a sudo account can authorise these changes, not the guest account itself.