LTSP 5 is in minimal maintenance mode
The new LTSP is hosted at https://ltsp.github.io

IRC chat logs for #ltsp on irc.freenode.net (webchat)


Channel log from 16 June 2019   (all times are UTC)

00:09vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
01:09vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 250 seconds)
06:19ltsp has joined IRC (ltsp!bot@ltsp.org)
06:32ltsp has joined IRC (ltsp!bot@ltsp.org)
08:15ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
08:43woernie has joined IRC (woernie!~werner@p5B09D775.dip0.t-ipconnect.de)
09:37woernie has left IRC (woernie!~werner@p5B09D775.dip0.t-ipconnect.de, Remote host closed the connection)
12:13kjackal has left IRC (kjackal!~quassel@2a02:587:311b:3d00:747d:db0e:3537:792e, Ping timeout: 258 seconds)
12:13kjackal has joined IRC (kjackal!~quassel@athedsl-135895.home.otenet.gr)
13:50vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 268 seconds)
14:09vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi)
14:52epoptes_user9 has joined IRC (epoptes_user9!2972e898@gateway/web/freenode/ip.41.114.232.152)
15:55epoptes_user9 has left IRC (epoptes_user9!2972e898@gateway/web/freenode/ip.41.114.232.152, Ping timeout: 256 seconds)
16:23GodFather has left IRC (GodFather!~rcc@d53-64-7-141.nap.wideopenwest.com, Ping timeout: 248 seconds)
18:04vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
18:07woernie has joined IRC (woernie!~werner@p5B29636A.dip0.t-ipconnect.de)
18:17
<alkisg>
vagrantc: our new LDM is ready, everything works including DM/console/su - logins, and it even properly implements process and mount cleanup: https://github.com/eellak/gsoc2019-ltsp/blob/master/ltsp/initrd/ltsp/applets/init/pamssh
18:17
At 200 shell lines it does so much more than the old one! ;)
18:19
Autologins work on nfs3; I don't know if it makes sense to support them with sshfs (it's doable with pam_session instead of pam_auth, and the equivalent of LDM_PASSWORD in lts.conf)
18:22
<vagrantc>
alkisg: excellent!
18:22
<alkisg>
I think having an ssh password in lts.conf is worse than using nfs3 for those accounts, as it gives access to the server too, so maybe we should note that autologin=nfs3 (or local home) only
18:22
<vagrantc>
a documentation issue, really.
18:23
alkisg: so ... this is using lightdm or gdm or something?
18:23
<alkisg>
vagrantc: absolutely anything at all
18:23
Even wayland
18:23* vagrantc claps heartily
18:23
<alkisg>
:)
18:23
I tried with all my live cds and VMs (debian/ubuntu ones; not fedora yet)
18:24
From jessie and xenial to buster and 19.04 and kde/xfce/mate/gnome...
18:24
Everything worked fine
18:24
<vagrantc>
wow. jessie is quite old
18:24
<alkisg>
It needed 2-3 special cases in the codebase, and it worked fine after that
18:25
I think next year we'll be able to claim that we run in "anything systemd-based"
18:25
<vagrantc>
how heavily does it rely on systemd specifically?
18:26
<alkisg>
buster-live.iso works without modifications except for downloading any sshfs binary (or apt installing it on boot)
18:26
I avoided pxssh and screen scraping, using SSH_ASKPASS
18:26
So it should work fine with any locale too
18:27
The process cleanup and unmount is quite tricky
18:27
If one spent a week, he'd probably be able to make it work without systemd too
18:27
<vagrantc>
nice
18:27
<alkisg>
But it's already complicated, so I think I want to avoid the extra complexity involved in this
18:28
<vagrantc>
so now that you're hitting the complexities ... this is still sounding better than "the old ways" ?
18:28
<alkisg>
Oh, very very much so
18:28
<vagrantc>
i assumed so, but just wanted to ask :)
18:28
<alkisg>
The complexities involved are mostly caused by other software bugs, not by design
18:29
E.g. I spent half a day to find out why sshfs login needed 120 secs instead of 5 for nfs,
18:29
<vagrantc>
which, in theory, if we can get them fixed upstream, they're eventually go away
18:29
<alkisg>
only to rediscover the gnome-keyring hardlinks issue,
18:29
and after avoiding that, I bumped into the opposite ICEauthority issue :D
18:29
<vagrantc>
adventures
18:30
<alkisg>
It'd be hard to solve sshfs lock issues; they're already known; and it'd take a lot of time to solve all session managers and other software that use locking functions unavailable in sshfs
18:30
So yeah we can push for that, but it'll take a while; we'll need to use the old workarounds for a few years more
18:31
<vagrantc>
"# stretch-mate has an ltsp user, remove it" ?? what?
18:31
<alkisg>
Haha
18:31
At this point i'm creating a live ltsp user
18:31
But one already existed in my vm
18:31
So until I get the merging code ready (doing so just now), I had to deluser ltsp for the vm user
18:32
<vagrantc>
ok, so a temporary workaround
18:32
<alkisg>
Yes, completely local
18:32
<vagrantc>
so you're testing jessie just to be thorough? :)
18:32
<alkisg>
The current git code is not for public use yet; it's what I need for rapid development
18:32
Right
18:34
vagrantc: ah, have a look at lines 29-40 there: https://github.com/eellak/gsoc2019-ltsp/blob/master/ltsp/initrd/ltsp/applets/init/ltsp_pamssh.py#L29
18:34
That's the "merge users" interface; is it sane?
18:35
Source is the server users; destination is the chroot/VM users; I provide 4 regexes to match users/groups to transfer/preserve
18:36
I.e. reimplementing X01-localapps user merging, except now for all users instead of just one, as we need all users before DM starts
18:36
And since the algorithm is quite complex, I opted for python there
18:37
It's funny that the "new X01-localapps" is 300 lines, while the "new ldm" 200 :P
18:37
(the merging isn't finished yet, it needs a couple more days)
18:37
<vagrantc>
heh
18:38
alkisg: the logic looks reasonable enough
18:38
<alkisg>
Great
18:38
<vagrantc>
allows a lot of flexibility what to keep and such
18:38
<alkisg>
Right, the end result will even allow for roaming laptops with a local administrator etc
18:40
<vagrantc>
so, it's really sounding feasible to drop LTSP5 for debian bullseye
18:41
<alkisg>
I'd even aim for getting ltsp19 to testing before Ubuntu 20.04 import freeze
18:41
<vagrantc>
import freeze is when?
18:41
<alkisg>
Sometime in February or so
18:42
I'll already have schools using ltsp19 at that time
18:42
<vagrantc>
should be doable, providing no big surprises in the next few months
18:42
<alkisg>
I think it's downhill from now on; I don't think there are any unexplored areas for ltsp19
18:43
<vagrantc>
i'll finally have the excuse to rewrite or drop the debian-installer hooks :)
18:43
<alkisg>
Hehe
18:43
What's that supposed to do, create a chroot?
18:44
<vagrantc>
historically it ran ltsp-build-client, yes ... but i would say it's just to build an LTSP bootable environment
18:45
<alkisg>
I'm not sure it's useful enough nowadays to justify having code in debian/ that we won't be testing frequently
18:45
<vagrantc>
true
18:45
but it will most likely just be a few calls to "ltsp image|config|etc"
18:45
and, like i said, rewrite or drop :)
18:46
<alkisg>
We can have a single `ltsp pnp` or whatever command to do magic
18:46
<vagrantc>
i'm very curious how debian-edu will respond to the changes ...
18:47
since they set up a full LDAP environment and such
18:47
<alkisg>
Eh, even better now since we'll have a real DM
18:47
I hope they'll contribute code for the "thin client" setup
18:47
<vagrantc>
i suspect this will make their work easier in the long-run, but they'll have to sort through a lot of workarounds they've implemented
18:47
<alkisg>
I believe so too
18:48
I imagine "remote desktop" being a very light session right after login
18:48
<vagrantc>
i've not received much response when sending to their list about getting involved in big LTSP changes ... but maybe i'll nudge some at DebConf this year ...
18:49
<alkisg>
Nah, let them find their way; they'll need to review their code that relies on LTSP anyway, and once they make it run on LTSP19, then the "remote desktop" integration will be just a few days away
18:50* alkisg isn't really using that setup; but I guess some people might want it
18:50
<vagrantc>
yeah, i've had a couple clients who needed to run things on the central server
18:50
for various reasons...
18:51
<alkisg>
I think they've been focusing on x2go though, while I think xfreerdp has more future with wayland (and even from windows clients)
18:51
<vagrantc>
debian-edu ?
18:51
<alkisg>
Yeah, am I mistaken?
18:52
<vagrantc>
i don't really know what they're using ... i know the x2go developer was more involved in debian-edu in recent years ...
18:53
<alkisg>
sunweaver x2go has more google hits than sunweaver xfreerdp...
18:53
Eh, they'll find their way, ...land
18:57
<vagrantc>
sure
19:23adrianor1 has joined IRC (adrianor1!~adrianorg@179.177.212.52.dynamic.adsl.gvt.net.br)
19:26adrianorg has left IRC (adrianorg!~adrianorg@179.187.30.215.dynamic.adsl.gvt.net.br, Ping timeout: 248 seconds)
20:03
<alkisg>
Python merging = 0m0,038s, ok, acceptable
20:18ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
20:34
<alkisg>
Ready for testing: https://github.com/eellak/gsoc2019-ltsp/blob/master/ltsp/initrd/ltsp/applets/init/mergepw.py
20:34
It should also be useful for merging old passwd/group to new installations, unrelated to ltsp
21:05woernie has left IRC (woernie!~werner@p5B29636A.dip0.t-ipconnect.de, Remote host closed the connection)