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


Channel log from 22 April 2022   (all times are UTC)

06:05ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
06:36woernie has joined IRC (woernie!~werner@p50867728.dip0.t-ipconnect.de)
07:37bcg has left IRC (bcg!~b@dg4ybwyyyyyyyyyyyyyyt-3.rev.dnainternet.fi, Quit: bcg)
07:38bcg has joined IRC (bcg!~b@dg4ybwyyyyyyyyyyyyyyt-3.rev.dnainternet.fi)
07:44woernie has left IRC (woernie!~werner@p50867728.dip0.t-ipconnect.de, Ping timeout: 246 seconds)
07:44woernie has joined IRC (woernie!~werner@p50867728.dip0.t-ipconnect.de)
10:17woernie has left IRC (woernie!~werner@p50867728.dip0.t-ipconnect.de, Remote host closed the connection)
12:38lucascastro has left IRC (lucascastro!~lucascast@192-140-51-210.static.oncabo.net.br, Remote host closed the connection)
12:39lucascastro has joined IRC (lucascastro!~lucascast@192-140-51-210.static.oncabo.net.br)
12:59
<massimo_g[m]>
alkisg: thanks a lot for the tips.
12:59
Old .deb seem still installable on ubuntu 20, but we have to test a bit more if they work.
12:59
Are the source files and scripts used to generate all the old .deb packages publicly available somewhere? In that case we could use them as a "fallback solution" and also make ubuntu20 packages if needed while we get acquainted with the new LTSP code and try to see what's feasible๐Ÿค”
13:12lucascastro has left IRC (lucascastro!~lucascast@192-140-51-210.static.oncabo.net.br, Ping timeout: 246 seconds)
13:19
<quinox>
the new LTSP was very easy to set up for me
13:21
the initrd feature is especially great, saves me a lot of time rebaking images
13:25
idunno how thin your thin cliets are, but perhaps booting the new LTSP into x2go is a way to go. It's a very lightweight fat client then :)
13:28
For inspiration see https://github.com/search?q=org%3Altsp+x2go&type=discussions
13:29lucascastro has joined IRC (lucascastro!~lucascast@177-185-131-162.corp.isotelco.net.br)
13:32
<quinox>
(or xfreerdp, VNC, etc., whatever floats your boat)
13:41
<alkisg>
massimo_g: sure, the old sources are available in their project page on launchpad as they always were
13:42
<massimo_g[m]>
<quinox> "idunno how thin your thin cliets..." <- Thanks, "x2go" is a keyword I didn't know and I'm using it to search related stuff
13:42
Maybe I can simply launch xfreerdp from the xsession file
13:42
Also, I found this yesterday https://github.com/MAButz/ldm
13:42
I link it, maybe it can be useful to jannyboy too who was trying to achieve the same goal
13:43
<alkisg>
Which things do you need from the old ltsp that you think aren't there in the new one? E.g. for xfreerdp, there's a lightdm-based greeter for it in the arctica project, already packaged for debian etc
13:44
https://github.com/ArcticaProject/lightdm-remote-session-x2go
13:49at2f has joined IRC (at2f!~at2f@aputeaux-654-1-99-82.w90-2.abo.wanadoo.fr)
13:51
<massimo_g[m]>
<alkisg> "Which things do you need from..." <- Seems I was inadvertently reinventing the wheel ๐Ÿค”๐Ÿ™„
13:51
So thanks, I'll dig a more into this
13:51
This wiki page seems interesting too as it lists various methods, including that one with the arctica greeter (i link it for the other guy trying to make it)
13:51
https://github.com/ltsp/ltsp/wiki/RDP-Kiosks-on-Ubuntu
13:51
> <@alkis:matrix.org> Which things do you need from the old ltsp that you think aren't there in the new one? E.g. for xfreerdp, there's a lightdm-based greeter for it in the arctica project, already packaged for debian etc
13:51
* Seems I was inadvertently reinventing the wheel ๐Ÿค”๐Ÿ™„
13:51
So thanks, I'll dig more into this path
13:51
This wiki page seems interesting too as it lists various methods, including that one with the arctica greeter (i link it for the other guy trying to make it)
13:51
https://github.com/ltsp/ltsp/wiki/RDP-Kiosks-on-Ubuntu
13:52
<alkisg>
Heh I wrote that page, but after so many edits, I don't recognize it anymore :D
13:52
* Heh I think I wrote that
14:08
<at2f>
Hey! I'm coming back with my autologin issues. I created one user per client, with each one autologing. I generated the default `ltsp.conf` file, and added just a few things:
14:09
`[MAC_ADDRESS]`
14:09
`HOSTNAME=clienthostname`
14:09
`AUTOLOGIN=user-1`
14:11
For each client. My issue is that my clients do not recognise the sound devices (output and input) when using autologin. If I disable autologin, it works fine.
14:12
This is on Ubuntu 22.04. That's a fresh install made today from the newly released ISO. I added the LTSP PPA, and did not do any configuration to the default (minimal) install apart from creating a few users and adding LTSP.
14:13
<alkisg>
at2f: is that chrootless ltsp?
14:13
<at2f>
I tried the same setup on Ubuntu 20.04, but this time, autologin did not work at all, and I was just presented with GDM.
14:13
Yes, that's chrootless ltsp
14:14
<alkisg>
Currently do you have 20.04 or 22.04 to test with?
14:14
<at2f>
I currently have 22.04
14:14
I had to wipe 20.04
14:15
<alkisg>
OK. Do you have multiple clients, i.e. to test booting a client with different hardware?
14:15
I'm not sure if gnome / 22.04 started using pipewire or something else that has bugs / race conditions, and I don't know if they're related to hardware etc; I'm mostly testing with mate
14:16
Booting a client with autologin, and one without, and testing the processes and environment would be a good starting point
14:16
In general, LTSP doesn't do anything at all regarding sound, there's no code at all for that, so it's something to do with gnome/pipewire/etc
14:17
<at2f>
Yes, I have a few different clients. I already tested on different hardware, but the issue is consistent across all hardware: the sound devices are not recognised when autologin is on (though it works fine on maybe 1~5% of the boots), and it works flawlessly when autologin is off.
14:17woernie has joined IRC (woernie!~werner@p5b296a4b.dip0.t-ipconnect.de)
14:19
<at2f>
`ps -e | grep pipewire` shows `pipewire` and `pipewire-media-`
14:19
<alkisg>
Compare a client with autologin and one without it
14:19
Try to find the differences. It sounds like a race condition in pipewire; possibly related to SSHFS, which is networked and kinda slower than the modern SSD disks usually used for home
14:34
<at2f>
I have the same pipewire services launched on both clients: `pipewire` and `pipewire-media-session`
14:37
The client with autologin had iBus crash on login, and Firefox does not launch (this is the first time those two things happened). It seems autologin is the source of plenty of issues. I think I'll try another approach, then.
14:37
Probably by hiding other users from GDM.
14:41
<alkisg>
If you have time, test with NFS home instead of SSHFS, to see if it's just speed-related or also lock-related (NFS is better with locks than SSHFS)
14:42
Also, GDM should support a login delay, try to locate that option and add it to ltsp.conf, so that it autologins after 2 seconds
14:43
Finally, if you run `systemctl restart gdm`, which restarts gdm and applies autologin, does it work then? The idea is that the client is already up for some time and services should be fully started
14:43
In general GDM has many issues, it doesn't even support screen broadcasting; gnome has become rather unusable with all the wayland-related changes
14:58
<at2f>
I've read that using NFS for /home is unsafe. This is for public-facing machines in an internet cafe, so users often type sensitive information. Would that be an issue to use NFS?
15:14
So for, from what I've tried: `systemctl restart gdm` gets stuck a minute at `[OK] Reached target Sound Card.`, and then relaunches the desktop, with iBus now working, but the sound device still not recognised.
15:14
NFS works fine.
15:14
I found the lines I need to add to `/etc/gdm/custom.conf` in order to get a login delay, but how do I pass them to ltsp?
15:15
<alkisg>
man ltsp.conf, see GDM_CONF
15:15
*GDM3. You put the lines there, e.g GDM3_CONF="line1
15:15
line2"
15:16
NFS for /home is indeed unsafe out of the box; it can be secured but OK it was just for testing
15:20
If it's related to SSHFS locks it'll need a lot of time to send patches to the GNOME devs to fix their apps :/
15:20
E.g. for gnome-keyring-daemon, the bug has been reported like 10 years ago
15:27
<at2f>
I tried with:
15:27
`GDM3_CONF="[daemon]`
15:27
`TimedLoginEnable=true`
15:27
`TimedLogin=username`
15:27
`TimedLoginDelay=10`
15:27
This did not change the outcome: still unrecognised sound card.
15:28
(I closed the double quotes on the last line in my actual ltsp.conf)
15:37
So, if I understand correctly, it's related to SSHFS? Is there anything else I could try to do?
15:46
<alkisg>
There are various options in sshfs that could work around this, but you'd need to check the logs to find the specific app that breaks
15:48vagrantc has joined IRC (vagrantc!~vagrant@2600:3c01:e000:21:7:77:0:40)
16:00
<at2f>
I see. I think forgetting about autologin for now is probably my best option. I'm thinking I could use PWMERGE to only allow a single password-less non-sudoers user per client, and rsync a fresh /home after a logout to purge the user files. It sounds safe to me, with no risk of anyone accessing personal files of others, or am I missing something?
16:17
<alkisg>
at2f: well, autologin via sshfs is inherently unsafe, because you have to send the secret (password etc) to the client, which has no local storage
16:18
If you wanted to bypass that, you'd need to auto-generate some client-side secret based on the client hardware; I have a small how-to for that in the wireguard issue in github.com/ltsp/ltsp
16:20
<at2f>
OK, so password-less users restricted to a single client each would actually be safer?
16:22
<alkisg>
Not really because they could see the passwords for the other clients too, via ltsp.conf
16:22
Well, for simple users sure, but for anyone that can read the internals of ltsp etc, it wouldn't be secure
16:23
I.e. they would be able to ssh user2@server, even if they were restricted locally to just user1
16:29
<at2f>
Well, I'll have to think about it, then, thank you for everything.
16:29
I'll most likely pass on autologin, and look into auto-generating client-side secrets to secure the clients (if that's even possible to use without auto-login).
16:29
I'm still willing to help determine what's causing the autologin issue to report it upstream, if you're okay to guide me in the troubleshooting. If so, should I start a discussion, or a bug report on GitHub?
16:30
<alkisg>
https://github.com/ltsp/ltsp/issues/127#issuecomment-733511783
16:31
Unfortunately I don't have time for LTSP currently, many paying works pending; I'll work on that again in the summer
16:31
That link above ^ has an example on how to generate client secrets
16:31
Back later!
16:31
<at2f>
Understandable. While we're on the topic of paying work, that was my next question: do you plan to allow donations to the project?
16:32
And thanks again for your precious help.
16:38
<alkisg>
I think I already have a donations page on ltsp or epoptes somewhere, but it's seldomly used. Payments for new features or customized installations are usually more rewarding
16:39
<at2f>
This one? https://epoptes.org/sponsoring/
16:40
<alkisg>
Yup! Thanks!
16:40
<at2f>
Nice, I couldn't find a donation link on the GitHub page or ltsp.org.
16:41
<alkisg>
I think I was planning to work on that but never found enough time... ;)
16:45
<at2f>
I see. ^^
16:45
I'm leaving work for today, I'll look into my setup probably some time next week if I can find the time to do that. Thanks again for the help, I think I'm on the right track now!
16:45at2f has left IRC (at2f!~at2f@aputeaux-654-1-99-82.w90-2.abo.wanadoo.fr, Quit: Client closed)
20:12lucascastro has left IRC (lucascastro!~lucascast@177-185-131-162.corp.isotelco.net.br, Ping timeout: 276 seconds)
20:13vagrantc has left IRC (vagrantc!~vagrant@2600:3c01:e000:21:7:77:0:40, Quit: leaving)
22:03ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
23:36vagrantc has joined IRC (vagrantc!~vagrant@2600:3c01:e000:21:7:77:0:20)