Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Announcing LTSP 19.08 #4

Open
alkisg opened this issue Aug 18, 2019 · 20 comments

Comments

@alkisg
Copy link
Collaborator

commented Aug 18, 2019

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:

Linux Terminal Server Project helps in netbooting LAN clients from a single template installation that resides in a virtual machine image or a chroot on the LTSP server, or the server root (/, chrootless). This way maintaining tens or hundreds of diskless clients is as easy as maintaining a single PC.

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".

LTSP5 resources

Resources for the old LTSP5; will become obsolete when users switch to the new LTSP.

Thin clients

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.

Directories/files

The LTSP directories have changed for FHS compliancy:

  • /opt/ltsp: now in /srv/ltsp
  • /var/lib/tftpboot: now in /srv/tftp

The configuration files have also changed, and a single /etc/ltsp/ltsp.conf file now manages all client and server parameters.

Equivalents

Here is an alphabetical list with the new equivalents of LTSP5 tools, or their deprecation notices:

  • getltscfg: replaced by an internal shell function
  • init-ltsp.d: ltsp init
  • jetpipe: deprecated; may be rewritten in python3 if there's need; see also p910nd
  • ldm: replaced by pamltsp and pwmerge, which work with all display managers, like GDM, LightDM etc. The down side is that currently when a new user is added, the sysadmin needs to run ltsp initrd and reboot the clients.
  • ldminfod: deprecated
  • lts.conf: /etc/ltsp/ltsp.conf uses somewhat changed syntax and manages both the clients and the server
  • ltsp-build-client: use VMs or ltsp image / to generate an initial chroot, then unmksquashfs it; or use debootstrap
  • ltsp-chroot: deprecated; may be reincluded if there's need
  • ltsp-cluster-info: deprecated
  • ltsp-config dnsmasq: ltsp dnsmasq
  • ltsp-config isc-dhcp-server: may be reincluded if there's need
  • ltsp-config lts.conf: run man ltsp.conf to see how to create /etc/ltsp/ltsp.conf
  • ltsp-config nbd-server: deprecated; may be reincluded if there's need
  • ltsp-config nfs: ltsp nfs
  • ltspfs: deprecated
  • ltspfsd: deprecated
  • ltspfs_mount: deprecated
  • ltspfsmounter: deprecated
  • ltspfs_umount: deprecated
  • ltsp-genmenu: deprecated
  • ltsp-info: ltsp info
  • ltsp-localapps: deprecated
  • ltsp-localappsd: deprecated
  • ltsp-open: deprecated
  • ltsp-remoteapps: deprecated; they may be implemented with an ssh-keygen /
    ssh -X wrapper if they are needed
  • ltsp-update-image: ltsp image
  • ltsp-update-kernels: ltsp kernel
  • ltsp-update-sshkeys: its functionality is included in ltsp initrd
  • nbd-client-proxy: deprecated
  • nbd-proxy: deprecated
  • nbdswapd: deprecated; may be reincluded if there's need
  • screen.d: we don't handle VTs anymore
  • update-kernels: syslinux configuration was replaced by ltsp ipxe
@alkisg alkisg pinned this issue Aug 18, 2019
@enaut

This comment has been minimized.

Copy link

commented Aug 18, 2019

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!

@alkisg

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 18, 2019

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 mention it in https://github.com/ltsp/ltsp/wiki/installation:

Any .deb-based distribution that uses systemd should work; i.e. from Ubuntu 16.04 and Debian Jessie and onward.

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.

@enaut

This comment has been minimized.

Copy link

commented Aug 18, 2019

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.

@alkisg

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 18, 2019

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:

  1. Writing man pages in the source docs folder as it is now: https://github.com/ltsp/ltsp/tree/master/docs
  2. Writing additional documentation pages in the wiki: https://github.com/ltsp/ltsp/wiki
  3. Then periodically running a script that merges those and publishes them in https://ltsp.github.io; so at that point, it won't matter much if (2) will be a developer wiki or directly the ltsp.github.io git repository.

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! 😃

@alkisg

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 19, 2019

New build ltsp - 19.08-1~201908190925 uploaded in the PPA, fixes ltsp/ltsp#5 and adds support for the following ltsp.conf parameters:

X_DRIVER="vesa"
X_HORIZSYNC="28.0-87.0"
X_MODELINE='"1024x768_85.00" 94.50 1024 1096 1200 1376 768 771 775 809 -hsync +vsync'
X_MODES='"1024x768" "800x600" "640x480"'
X_PREFERREDMODE="1024x768"
X_VERTREFRESH="43.0-87.0"
X_VIRTUAL="800 600"
: If any of these parameters are set, the /usr/share/ltsp/client/init/xorg.conf
template is installed to /etc/X11/xorg.conf, while applying the parameters.
Read that template and consult man:xorg.conf(5) for more information.
The most widely supported method to set a default resolution is X_MODES.
If more parameters are required, create a custom xorg.conf as described in
the EXAMPLES section.

@rkwesk

This comment has been minimized.

Copy link

commented Aug 20, 2019

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.

Richard

@alkisg

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 20, 2019

Thank you Richard! Old fat clients like Pentium 4's will still be properly supported and run even better with the new than the old LTSP; but thin clients will now need to use x2go/xdmcp etc, we won't add ltspfs/localapps etc in the new code.

@alkisg

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 20, 2019

New build 19.08-1~201908200648~ubuntu18.04.1 uploaded in the PPA, implements LOCAL_SWAP, fixes ltsp/community#5 and adds support for passwordless logins:

PASSWORDS_x="teacher/cXdlcjEyMzQK [a-z][-0-9]/MTIzNAo= guest[^:]/"
: A space separated list of regular expressions that match usernames, followed
by slash and base64-encoded passwords. On boot, ltsp init writes those
passwords for the matching users in /etc/shadow, so that then pamltsp can
pass them to SSH/SSHFS. The end result is that those users are able to
login either in the console or the display manager by just pressing [Enter]
at the password prompt.

Passwords are base64-encoded to prevent over-the-shoulder spying and to
avoid the need for escaping special characters. To encode a password in
base64, run base64 -, type a single password, and then Ctrl+D.

In the example above, the teacher account will automatically use "qwer1234"
as the password, the a1-01, b1-02 etc students will use "1234", and the
guest01 etc accounts will be able to use an empty password without even
authenticating against the server; in this case, SSHFS can't be used,
/home should be local or NFS.

@alkisg

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 20, 2019

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.

@alkisg

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 21, 2019

New build 19.08-1~201908210816~ubuntu19.10.1 uploaded in the PPA, with the following changelog:

  • Support Ubuntu and Debian live isos as bootable images
  • Implement autologin
  • Correctly override image.excludes (#6)
  • Fix manpages path and ltsp --help

See man ltsp.conf(5) for documentation of all the options.
If the new LTSP already supports all the options one needs, it should be preferred for new installations.

@rkwesk

This comment has been minimized.

Copy link

commented Aug 23, 2019

report:

both times the ltsp dnsmasq, having created the conf file would report cannot start dnsmasq service

details:

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

Richard

@alkisg

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 23, 2019

Hi Richard,

I edited your comment to put the configuration files in code blocks, to have them display better.

I assumed that if systemd-resolve is present, then it should work; and if it fails, then LTSP should stop and notify the sysadmin (as it did) to fix the issue.

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. 😞
Could you file an issue with the same text as above, so that I do a commit against it? Ty.

@alkisg

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 23, 2019

Hmmm actually Richard after looking at the code, the systemd-resolve error is a warning, it's not the issue you're facing.

Could you paste the output of:

systemctl restart dnsmasq
systemctl status dnsmasq | tail -n 20
@rkwesk

This comment has been minimized.

Copy link

commented Aug 24, 2019

root@Buster64ltsp19:~# systemctl restart dnsmasq.service
Job for dnsmasq.service failed because the control process exited with error code.
See "systemctl status dnsmasq.service" and "journalctl -xe" for details.

oot@Buster64ltsp19:~# systemctl status dnsmasq | tail -n 20
● dnsmasq.service - dnsmasq - A lightweight DHCP and caching DNS server
Loaded: loaded (/lib/systemd/system/dnsmasq.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Sat 2019-08-24 13:11:30 EEST; 5min ago
Process: 857 ExecStartPre=/usr/sbin/dnsmasq --test (code=exited, status=0/SUCCESS)
Process: 858 ExecStart=/etc/init.d/dnsmasq systemd-exec (code=exited, status=1/FAILURE)

Aug 24 13:11:30 Buster64ltsp19 systemd[1]: Starting dnsmasq - A lightweight DHCP and caching DNS server...
Aug 24 13:11:30 Buster64ltsp19 dnsmasq[857]: dnsmasq: syntax check OK.
Aug 24 13:11:30 Buster64ltsp19 dnsmasq[858]: dnsmasq: bad IP address at line 33 of /etc/dnsmasq.d/ltsp-dnsmasq.conf
Aug 24 13:11:30 Buster64ltsp19 dnsmasq[858]: bad IP address at line 33 of /etc/dnsmasq.d/ltsp-dnsmasq.conf
Aug 24 13:11:30 Buster64ltsp19 systemd[1]: dnsmasq.service: Control process exited, code=exited, status=1/FAILURE
Aug 24 13:11:30 Buster64ltsp19 dnsmasq[858]: FAILED to start up
Aug 24 13:11:30 Buster64ltsp19 systemd[1]: dnsmasq.service: Failed with result 'exit-code'.
Aug 24 13:11:30 Buster64ltsp19 systemd[1]: Failed to start dnsmasq - A lightweight DHCP and caching DNS server.

, or

@alkisg

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 24, 2019

Hi Richard,

so the problem is that you have an IPv6 DNS server in that line:

dhcp-option=option:dns-server,192.168.1.1,10.72.251.10,fe80::b167:ea72:3350:81b8%enp1s0

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?

@rkwesk

This comment has been minimized.

Copy link

commented Aug 24, 2019

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.

root@Buster64ltsp19:~# dpkg -l | grep resol
root@Buster64ltsp19:~# 

gives nothing.

Now to give the output you requested:

root@Buster64ltsp19:~# cat /etc/resolv.conf
# Generated by NetworkManager
nameserver 192.168.1.1
nameserver 10.72.251.10
nameserver fe80::b167:ea72:3350:81b8%enp1s0

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

dhcp-option=option:dns-server,10.72.251.10

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.

Richard

@alkisg

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 24, 2019

Fix committed in ltsp/ltsp@01a0bc6.

@rkwesk

This comment has been minimized.

Copy link

commented Aug 24, 2019

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.

Richard

@rkwesk

This comment has been minimized.

Copy link

commented Aug 24, 2019

By logging out and then back I now see the new issues I submitted so please disregard my remark above.

Richard

@alkisg

This comment has been minimized.

Copy link
Collaborator Author

commented Aug 27, 2019

New build 19.08-1~201908271936~ubuntu18.04.1 uploaded in the PPA, with the following changelog:

  • Support setting iPXE menu titles from ltsp.conf (#14)
  • Implement NAT for dual NIC servers (#13)
  • Disable Ethernet flow control for better LAN speed (#13)
  • Various fixes (#9, LP: #1840965)

The issues tracker lists all the things that are known not to work yet with the new LTSP, along with their implementation plans.

@alkisg alkisg unpinned this issue Sep 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
3 participants
You can’t perform that action at this time.