Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Announcing LTSP 19.08 #4
Announcing LTSP 19.08
LTSP has been redesigned and rewritten from scratch as part of a GSoC 2019 project, developed by Alkis Georgopoulos under the mentorship of vagrantc, fottsia and siahos, and the supervision of GFOSS - Open Technologies Alliance. Many thanks to everyone involved for this opportunity to radically improve LTSP!
The new LTSP comes with a new goal:
I.e. the focus now is in ease of maintenance, not in recycling old hardware. New technologies like diskless fat clients with UEFI, Wayland etc are supported, while thin client support is now reduced to "remote desktop with xfreerdp / x2go / VNC".
The old LTSP will now be called LTSP5 (it was first released in 2005), to distinguish it from the new versions that follow the year.month numbering. The first LTSP 19.08 release is considered an alpha version, which should work in many setups but isn't production ready nor feature complete yet.
To try out the new version, read the wiki. Note that in the 19.08 version, NBD swap and client-attached printers are not yet supported.
A list of LTSP5 sites/concepts/tools and their new equivalents follows, so that LTSP5 users can more quickly familiarize themselves with the new LTSP.
LTSP upstream resources
The following sites are maintained by LTSP developers. That usually means "only basic documentation/feedback, but accurate and well maintained".
LTSP community resources
The following sites are maintained by the LTSP community. That could mean "more documentation/feedback including unusual scenarios, but some information might not be very accurate or up to date".
Resources for the old LTSP5; will become obsolete when users switch to the new LTSP.
LTSP now doesn't natively support thin clients. But you can still netboot clients up to the login screen, and then set up a session that uses xfreerdp, x2go or vnc to access the server in a manner similar to thin clients. The community is invited to write wiki pages about that.
The LTSP directories have changed for FHS compliancy:
The configuration files have also changed, and a single /etc/ltsp/ltsp.conf file now manages all client and server parameters.
Here is an alphabetical list with the new equivalents of LTSP5 tools, or their deprecation notices:
Good job thank you! I did not try it yet.
Some missing information: what ubuntu version is the ltsp19.8 intended for? 18.04? 19.04 until out of alpha? How will you do release cycles?
In my opinion it is a bad decission to sepparate "community" and "developer" help. This usually means that the information is much more hidden. So my vote is for one single wiki and one single issue tracker.
But thank you again for the great work!
Thank you enaut,
there's too much information because it's three things in one, a complete rewrite, a new release, and a move in new sites etc. So it's easy to get lost.
I actually tested it in Debian Jessie, Stretch and Buster, in Ubuntu 16.04, 18.04 and 19.04, and in LinuxMint Tara. Everything worked fine; but of course there's some missing functionality like client printer sharing etc.
About the community wiki vs the developer wiki, unfortunately http://wiki.ltsp.org/ and https://help.ubuntu.com/community/UbuntuLTSP proved that it's hard to maintain a quality wiki. Personally I can maintain a small wiki with the man pages, an installation page, and a few advanced topics, but I can't oversee tens of other pages that others will write and do some quality assurance there. So users won't know how much to trust their sources of information.
As for the issues, https://github.com/ltsp/ltsp/issues is for bug reports and https://github.com/ltsp/community/issues for chat. When I have some time to work on LTSP, I don't want to go through hundreds of chat issues to see which things need to be worked upon; I want the bugs to be separate. It was the same in LTSP5 as well, bugs were in launchpad while chat in sourceforge.
Thanks for the answer!
Wow! You did a lot of testing!
I'd separate the "developer verified" information by putting it on the website https://ltsp.github.io (it's not really harder to edit than the wiki and people can contribute by pull request). A website has a much more static and verified touch than a wiki.
The wiki you can then let the community work on without developer approval which is very much the touch of a wiki. That would decrease the "documentation complexity" a lot for maintenance and for information seeking (I just see myself struggling with an issue just to find that there is a more recent version of the docs I followed somewhere else).
For issues I would use tags or "labels". Any new issues get the label "community" and/or "unsorted" then if something turns out to be a bug I'd promote the label to "bug". I guess otherwise there will be quite some community questions that turn out as bugs and on the other hand quite some bugs that turn out to be simply misconfigurations.
But all in all you are to decide! Those are just my thoughts on the matter.
https://ltsp.github.io is currently just an index page with links. I'm hoping that in the future we'll organize it like this:
But website management comes after code and documentation; if someone can help it can be done sooner. I think Jekyll might help there, not sure.
Re: issues, tags are nice, but they can't really transform chats to bug reports. Chats should be relaxed, bug reports should be more formal. Some people may even hesitate to use a formal issues tracker for informal chat. Anyway, the traffic will also matter, if there are very few issues then a single tracker will be enough, if there are many maybe it would be nice to create a stackexchange based site etc. Let's see how it goes. Thanks for all the input!
This is a welcomed progression. I would also like to thank Alkis, Vagrant, Fotis and Yiannis for their determination and contribution and support. I will try in my small way to ccontribute by testing and commenting. I take the point that Alkis put that the emphasis has shifted from reusing old hardware to ensuring that the project is easy for the administrator/user to install maintain and troubleshoot. I agree with this shift in emphasis while attempting to continue to use the old hardware that both I personally possess and that is still the norm in many public schools around me in Greece.
PASSWORDS_x="teacher/cXdlcjEyMzQK [a-z][-0-9]/MTIzNAo= guest[^:]/"
Note that since the new LTSP is still in rapid development, it could happen that a new build breaks someone's setup and clients won't boot anymore.
To work around that, you could periodically keep a copy of this small file:
cp /srv/tftp/ltsp/ltsp.img /srv/tftp/ltsp/ltsp.img.old
All the ltsp code is contained there, so if an updated version doesn't work for you, just copy the old one over it to be able to boot the clients within seconds, and then report an issue.
New build 19.08-1~201908210816~ubuntu19.10.1 uploaded in the PPA, with the following changelog:
See man ltsp.conf(5) for documentation of all the options.
both times the ltsp dnsmasq, having created the conf file would report cannot start dnsmasq service
done twice on two differnt pc's (both with old style bios and both with just one nic) a clean "expert install" of Debian Buster from a recent Debian iso
first pc had a disk partioned with gdisk so that sda1 was ef02 sda2 was 8200 and sda3 was 8300
I know you said this could lead to problems so on second pc I let Debian installer just use whole disk (80 GB) so sda1 was for ext4 with / and sda2 was swap.
On first pc I chose to have installer install mate desktop but on second I just had it put the basic system and afterwards I installed xorg and mate.
what follows is from the second pc:
root@Buster64ltsp19:~# history 3 apt clean 4 apt update 5 apt full-upgrade 6 apt clean 7 apt install xorg mate 8 apt clean 9 apt install lightdm 10 apt clean 11 vi /etc/lightdm/lightdm.conf 12 reboot 13 apt install firefox 14 apt-cache search firefox 15 apt install firefox-esr 16 apt clean 17 wget https://ltsp.github.io/misc/ltsp-ubuntu-ppa-bionic.list -O 18 apt install wget less rsync 19 apt clean 20 wget https://ltsp.github.io/misc/ltsp-ubuntu-ppa-bionic.list -O 21 wget https://ltsp.github.io/misc/ltsp-ubuntu-ppa-bionic.list -O /etc/apt/sources.list.d/ltsp-ubuntu-ppa-bionic.list 22 wget https://ltsp.github.io/misc/ltsp_ubuntu_ppa.gpg -O /etc/apt/trusted.gpg.d/ltsp_ubuntu_ppa.gpg 23 apt update 24 apt install ltsp dnsmasq nfs-kernel-server openssh-server squashfs-tools epoptes 25 apt clean 26 gpasswd -a administrator epoptes 27 gpasswd -a rkwesk epoptes 28 apt install Network-Manager-gnome 29 apt install network-manager-gnome 30 apt clean 31 vi /etc/network/interfaces 32 reboot root@Buster64ltsp19:~# ltsp dnsmasq Failed to get global data: Unit dbus-org.freedesktop.resolve1.service not found. LTSP command failed: systemd-resolve --status Installed /usr/share/ltsp/server/dnsmasq/ltsp-dnsmasq.conf in /etc/dnsmasq.d/ltsp-dnsmasq.conf Job for dnsmasq.service failed because the control process exited with error code. See "systemctl status dnsmasq.service" and "journalctl -xe" for details. LTSP command failed: systemctl restart dnsmasq Aborting ltsp root@Buster64ltsp19:~# apt-cache search dbus | less root@Buster64ltsp19:~# apt install dbus-user-session Reading package lists... Done Building dependency tree Reading state information... Done dbus-user-session is already the newest version (1.12.16-1). dbus-user-session set to manually installed. 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded. root@Buster64ltsp19:~# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 00:1e:8c:16:54:1a brd ff:ff:ff:ff:ff:ff inet 10.72.251.207/24 brd 10.72.251.255 scope global dynamic noprefixroute enp1s0 valid_lft 1811606sec preferred_lft 1811606sec inet6 2a02:587:2d24:1900:88f9:1ae:fd8d:b146/64 scope global dynamic noprefixroute valid_lft 62732sec preferred_lft 62732sec inet6 fe80::b468:8bf6:1037:f35b/64 scope link noprefixroute valid_lft forever preferred_lft forever
My lan is 10.72.251.0/24 and the router is 10.72.251.10 The conf file is default, untouched by me
root@Buster64ltsp19:~# cat /etc/dnsmasq.d/ltsp-dnsmasq.conf # This file is part of LTSP, https://ltsp.github.io # Copyright 2019 the LTSP team, see AUTHORS # SPDX-License-Identifier: GPL-3.0-or-later # Configure dnsmasq for LTSP # Documentation=man:ltsp-dnsmasq(8) # For additional local dnsmasq configuration like DNS blacklisting, it's # recommended to use separate /etc/dnsmasq.d/your-configuration.conf files, # so that they're not lost if you ever (re)run `ltsp --overwrite dnsmasq`. # port=0 disables the DNS service of dnsmasq port=0 # enable-tftp enables the TFTP service of dnsmasq enable-tftp # FHS 2.3+ recommends /srv for tftp (debian #477109, LP #84615) tftp-root=/srv/tftp # Log lots of extra information about DHCP transactions #log-dhcp # IP ranges to hand out, usually on the internal LTSP subnet of 2-NIC setups dhcp-range=192.168.67.20,192.168.67.250,12h # If another DHCP server is present on the network, a proxy range may be used # instead. This makes dnsmasq provide boot information but not IP leases. dhcp-range=set:proxy,10.72.251.0,proxy,255.255.255.0 # Specify the DNS server. 0.0.0.0 means the machine running dnsmasq. # DNS_SERVER in ltsp.conf is preferred as it reaches proxy DHCP clients. dhcp-option=option:dns-server,192.168.1.1,10.72.251.10,fe80::b167:ea72:3350:81b8%enp1s0 # Set some tags to be able to separate client settings later on. # "39" means "recent iPXE with menu support": http://ipxe.org/howto/dhcpd dhcp-match=set:iPXE,175,39 dhcp-match=set:X86PC,option:client-arch,0 dhcp-match=set:X86-64_EFI,option:client-arch,7 # Due to rfc4578 errata, sometimes BC_EFI=9 is misused instead of X86-64_EFI=7: dhcp-match=set:X86-64_EFI,option:client-arch,9 dhcp-mac=set:rpi,b8:27:eb:*:*:* dhcp-mac=set:rpi,dc:a6:32:*:*:* # In proxy DHCP mode, the server ONLY sends its IP and the following filename. # Service types: man dnsmasq or https://tools.ietf.org/html/rfc4578#section-2.1 # PXE services in non proxy subnets sometimes break UEFI netboot, so tag:proxy. pxe-service=tag:proxy,tag:!iPXE,X86PC,"undionly.kpxe",ltsp/undionly.kpxe pxe-service=tag:proxy,tag:!iPXE,X86-64_EFI,"snponly.efi",ltsp/snponly.efi pxe-service=tag:proxy,tag:iPXE,X86PC,"ltsp.ipxe",ltsp/ltsp.ipxe pxe-service=tag:proxy,tag:iPXE,X86-64_EFI,"ltsp.ipxe",ltsp/ltsp.ipxe pxe-service=tag:rpi,X86PC,"Raspberry Pi",unused # Specify the boot filename for each tag, relative to tftp-root. # If multiple lines with tags match, the last one is used. # See: https://www.syslinux.org/wiki/index.php?title=PXELINUX#UEFI dhcp-boot=tag:!iPXE,tag:X86PC,ltsp/undionly.kpxe dhcp-boot=tag:!iPXE,tag:X86-64_EFI,ltsp/snponly.efi dhcp-boot=tag:iPXE,ltsp/ltsp.ipxe # Proxy DHCP clients don't receive any DHCP options like root-path. # So we set root-path in the kernel cmdline from ltsp.ipxe. #dhcp-option=option:root-path,ipxe-menu-item
I edited your comment to put the configuration files in code blocks, to have them display better.
I assumed that if
This logic worked in Jessie/Mate, Stretch/Mate, and Buster/Gnome where I tested, but I now see that it doesn't apply in the default Buster/Mate installation.
root@Buster64ltsp19:~# systemctl restart dnsmasq.service
oot@Buster64ltsp19:~# systemctl status dnsmasq | tail -n 20
Aug 24 13:11:30 Buster64ltsp19 systemd: Starting dnsmasq - A lightweight DHCP and caching DNS server...
so the problem is that you have an IPv6 DNS server in that line:
If you manually remove it, then restarting dnsmasq should work. But to fix the LTSP code, could you please paste the contents of your /etc/resolv.conf?
By the by
I first installed only a basic system, so no X. Obviously the file /etc/network/interfaces was controlling the nic. I commented those lines out after I installed xorg and mate and lightdm and network-manager-gnome. - Debian assumes that you want to choose so all 4 packages were necessary to manually install. Then I rebooted so network manager was controlling the nic.
The package resolvconf is not installed.
Now to give the output you requested:
This accounts for that bad line in dnsmasq.conf
What I don't know is the proper context for that line but I made several attempts and finally found that
was accepted and now dnsmasq.service is running.
While you mull that over I will go on with the rest of the install and will report back.
Thank you for dealing with this. Since then I successfully created an ltsp19 server with one nic by editing the dnsmasq conf file. The client connected and seemed to run well.
I went on to try to create a server with two nics and discovered two issues that I tried to submit under new issues. However, I cannot find these issues now.
New build 19.08-1~201908271936~ubuntu18.04.1 uploaded in the PPA, with the following changelog:
The issues tracker lists all the things that are known not to work yet with the new LTSP, along with their implementation plans.