IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 16 June 2019 (all times are UTC)
| 00:09 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 01:09 | vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 250 seconds) | |
| 06:19 | ltsp has joined IRC (ltsp!bot@ltsp.org) | |
| 06:32 | ltsp has joined IRC (ltsp!bot@ltsp.org) | |
| 08:15 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
| 08:43 | woernie has joined IRC (woernie!~werner@p5B09D775.dip0.t-ipconnect.de) | |
| 09:37 | woernie has left IRC (woernie!~werner@p5B09D775.dip0.t-ipconnect.de, Remote host closed the connection) | |
| 12:13 | kjackal has left IRC (kjackal!~quassel@2a02:587:311b:3d00:747d:db0e:3537:792e, Ping timeout: 258 seconds) | |
| 12:13 | kjackal has joined IRC (kjackal!~quassel@athedsl-135895.home.otenet.gr) | |
| 13:50 | vsuojanen has left IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi, Ping timeout: 268 seconds) | |
| 14:09 | vsuojanen has joined IRC (vsuojanen!~vsuojanen@cable-hml-585686-205.dhcp.inet.fi) | |
| 14:52 | epoptes_user9 has joined IRC (epoptes_user9!2972e898@gateway/web/freenode/ip.41.114.232.152) | |
| 15:55 | epoptes_user9 has left IRC (epoptes_user9!2972e898@gateway/web/freenode/ip.41.114.232.152, Ping timeout: 256 seconds) | |
| 16:23 | GodFather has left IRC (GodFather!~rcc@d53-64-7-141.nap.wideopenwest.com, Ping timeout: 248 seconds) | |
| 18:04 | vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc) | |
| 18:07 | woernie 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:23 | adrianor1 has joined IRC (adrianor1!~adrianorg@179.177.212.52.dynamic.adsl.gvt.net.br) | |
| 19:26 | adrianorg 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:18 | ricotz 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:05 | woernie has left IRC (woernie!~werner@p5B29636A.dip0.t-ipconnect.de, Remote host closed the connection) | |