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


Channel log from 28 June 2021   (all times are UTC)

05:12ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
07:02woernie has joined IRC (woernie!~werner@p5b2965ee.dip0.t-ipconnect.de)
12:01alkisg_web has joined IRC (alkisg_web!~alkisg_we@srv1-dide.ioa.sch.gr)
12:29lucascastro has joined IRC (lucascastro!~lucascast@177-185-133-236.dynamic.isotelco.net.br)
17:10chabad360 has joined IRC (chabad360!~chabad360@71.245.242.3)
17:12
<chabad360>
hey
17:13
I just discovered ltsp after basically deploying an entirely custom solution
17:14
my image is based on arch, and boots using dracut and nbd
17:14
is there a way I could move it over to running on LTSP without having to recreate it?
17:18chabad360 has left IRC (chabad360!~chabad360@71.245.242.3, Quit: Client closed)
17:18chabad360 has joined IRC (chabad360!~chabad360@71.245.242.3)
17:20
<alkisg>
chabad360: ltsp client doesn't yet work with dracut
17:20
So you could use ltsp only for the server part
17:21
<chabad360>
If I have to change the boot method, that's not really an issue
17:21MendelGreenberg[ has joined IRC (MendelGreenberg[!~pseudoniu@2001:470:69fc:105::525b)
17:21MendelGreenberg[ is now known as chabad360[m]
17:21
<alkisg_web>
Meh, the matrix room lags a lot today, I'll reply from here
17:21
<chabad360>
ok
17:21
<alkisg_web>
No it's not about the boot method, currently only "initramfs-tools" from debian is supported as the initrd
17:22
<chabad360>
mmm
17:22
<alkisg_web>
While dracut etc isn't
17:22
The nbd/nfs part doesn't matter
17:22
<chabad360>
right
17:22
what is ltsp doing with initramfs_tools?
17:22
<alkisg_web>
Normally the initrd is able to mount nfs/nbd read only
17:23
So ltsp basically creates a writable overlay in tmpfs over it
17:23
<chabad360>
I do that with dracut (and nbd cow)
17:23
<alkisg_web>
And , it applies all the ltsp.conf settings
17:24
This is also doable outside the initramfs, by specifying init=/usr/share/ltsp/client/init
17:24
<chabad360>
hmm
17:24
<alkisg_web>
So, that script will bypass the dracut limitation
17:24
The next issue will be pam; ltsp registers itself in pam in a debian-specific way, update-pam
17:25
If you use e.g. ldap, then ltsp client should also work in arch
17:25
<chabad360>
what does that allow it to do?
17:25
<alkisg_web>
It allows the client to log in to the server using sshfs
17:25
It's the poor man's ldap
17:25
<chabad360>
ah
17:26
btw, I noticed teamviewerd mentioned in the docs
17:26
<alkisg_web>
To sum up: ltsp could quickly work in arch with init= and without pam; but if you need these, it would require a bit of "porting to arch"
17:26
<chabad360>
does it give a consistent ID for the client?
17:26
<alkisg_web>
LTSP gives a machine id based on mac addresss
17:27
The teamviewerd mention in the docs is just to "remove the daemon from the clients", as it's usually not needed there
17:27
<chabad360>
right
17:27
<alkisg_web>
People usually install teamviewer on the server, then run `ltsp image /` to create the image
17:27
So they don't need the server services in the clients as well
17:27
<chabad360>
but in my case, one of my issues is remote access (for quick techsupport)
17:28
I'm afraid tv wouldn't provide a consistent ID for the same device on each boot
17:28
but whatever
17:29
welp, thanks for that
17:31
<alkisg_web>
chabad360, afaik teamviewer stores its id under /home, not in /
17:31
I.e. per user
17:31
So yeah, that would work fine
17:32
I haven't tested teamviewer, but I did test anydesk, and it worked fine
17:32
<chabad360>
the clients go in an internet cafe
17:32
so per user doesn't really work
17:32
<alkisg_web>
Why not?
17:32
<chabad360>
whole thing gets reset on boot
17:32
<alkisg_web>
Each user would be a /home/guest01, /home/guest02 et cuser
17:32
And they'd get reset on login, not on boot
17:32
As they'd be mounted over sshfs
17:33lucascastro has left IRC (lucascastro!~lucascast@177-185-133-236.dynamic.isotelco.net.br, Ping timeout: 272 seconds)
17:33
<alkisg_web>
Many people are using ltsp for kiosks and internet cafe scenarios
17:33
<chabad360>
I'm just skipping the whole user thing basically
17:33
<alkisg_web>
The best way to support that, is to have a guest template, which gets "cloned" for each pc
17:33
<chabad360>
mmm
17:34
<alkisg_web>
Linux desktop environments don't want to run as root anymore
17:34
<chabad360>
I have a kiosk user
17:34
<alkisg_web>
So the idea is that you login on the server as /home/guest, you customize things the way you want them, then you use that as a template
17:34
Right
17:34
<quinox>
https://epoptes.org/ ?
17:34
<chabad360>
heh, doesn't seem to support arch
17:34
<alkisg_web>
Heya quinox
17:34
<chabad360>
but I'm looking into it
17:35* quinox waves at the room, hiya
17:35
<alkisg_web>
I'm the epoptes developer, I've seen it in AUR
17:35
<chabad360>
even the client?
17:35
<alkisg_web>
But I haven't tried to run it in arch
17:35
Yeah
17:35
<chabad360>
hm
17:36
only other issue is I kinda want the server to run on windows
17:36
but I suppose WSL could manage that
17:37
<alkisg_web>
Haha, funny use case though, windows server and arch client
17:37
<chabad360>
no
17:37
the server is linux
17:37
but management happens on another pc
17:37
<alkisg_web>
Ah you mean about epoptes
17:37
<chabad360>
ye
17:37
<alkisg_web>
Eh ok you could remote desktop into the linux server
17:38
<chabad360>
seems a bit silly, no?
17:38
remote into one system to remote into another
17:38
<alkisg_web>
I don't know the use case
17:39
E.g. if the windows box is at one site, and the linux server/internet cafe at another, then this sounds find
17:39
*fine
17:39
<chabad360>
it's in one place
17:39
just my office is all windows
17:39
and the server is headless
17:40
<quinox>
to me it it sounds fine, I often bounce between hosts to do stuff
17:40
<chabad360>
is there a way to run the ltsp service and the GUI in separate places?
17:40
<alkisg_web>
You want to control the clients from any windows pc, or from a specific windows pc?
17:40
I think veyon also works on windows btw
17:40
<chabad360>
or do I just do this: https://epoptes.org/documentation/run-fat/#remotely
17:41
preferably any
17:41
<alkisg_web>
If the clients are all local, I could avoid sending the traffic via teamviewer/anydesk
17:42
I'd just automate vnc, either via epoptes or via veyon or even via little scripts
17:42
*I would avoid...
17:42
<chabad360>
rn I use vnc
17:42
curious if there are any other solutions that provide more features
17:42
(like allowing me to reboot them remotely)
17:43
<alkisg_web>
epoptes does support reboot and even wake on lan
17:43
And I think veyon also supports that
17:43
<chabad360>
veyon seems like it might do the trick
17:44
<alkisg_web>
epoptes uses reverse connections so it needs no secrets on ltsp clients
17:44
<chabad360>
hm
17:44
<alkisg_web>
while veyon isn't designed with netbooting in mind; and it will need a step to copy the per-pc state to the netbooted clients
17:44
It's not hard, it can be automated with ltsp.conf once you find out where it stores its state
17:45
<chabad360>
hmm
17:46
RN, I've gotten my systems to boot with a consistent hostname (mac addr), so that means I can do vnc directly
17:47
veyon seems to be a bit complicated...
17:48lucascastro has joined IRC (lucascastro!~lucascast@45-167-143-6.netfacil.inf.br)
17:49
<alkisg_web>
It's structured with forward connections, so it requires keys on each client. I guess the same key for all clients would also work, making things simpler
17:50
<chabad360>
is it possible to run the epoptes serivce and gui in different places?
17:51
<alkisg_web>
You've already seen https://epoptes.org/documentation/run-fat/,
17:51
the other options are ssh socket forwarding (I mention that somewhere in epoptes discussions),
17:52
while for real remote connections, the code would need to be updated a bit, to have the daemon listen on a tcp port as well as the local socket
17:52
<chabad360>
isn't there a way to forward a socket to a port?
17:53
<alkisg_web>
The main reason we haven't done it so far is because of security
17:53
<chabad360>
does the gui need modification too?
17:53
<alkisg_web>
Anyone can connect to a port, while only epoptes group members can connect to the socket
17:53
<chabad360>
ah
17:54
you could add a password
17:54
<alkisg_web>
Yeah, or better yet, keys and roles
17:54
So teachers can do this and that, while admin would have more control over the clients
17:54
Unfortunately the days only have 24 hours each :)
17:56
<chabad360>
yep
17:56
I feel ya
17:56
Kpgsso816
17:56
S#!T
17:56
stupid click to focus!!!
17:56
<alkisg_web>
:/
17:57
<quinox>
I once pasted a channel-relevant password on IRC in a room with 400 people in it :)
17:58
<chabad360>
oops
17:58
<alkisg_web>
The best way is to completely ignore it and continue with the conversation so that as few people as possible notice it :D
17:58
<chabad360>
yep
17:58
<quinox>
;)
17:59lucascastro has left IRC (lucascastro!~lucascast@45-167-143-6.netfacil.inf.br, Ping timeout: 268 seconds)
17:59
<alkisg_web>
Matrix does have "delete message"... irc doesn't
18:00
<chabad360>
epoptes not building on arch
18:00
<alkisg_web>
Wouldn't it be easier to use debian/ubuntu for the image?
18:00
You just want a browser, right?
18:00
<chabad360>
not at at this point
18:00
<alkisg_web>
OK
18:01
<chabad360>
browser and file explorer
18:01
but the whole image is basically done (just troubleshooting now)
18:01
so rebuilding it is a bit of a waste
18:01
<alkisg_web>
I don't know what else you customized, but doing a kiosk from scratch in ltsp takes less than an hour
18:01
<chabad360>
I had to start from scratch
18:02
didn't come across ltsp early enopugh
18:02
enough*
18:02
<quinox>
I've been a happy LTSP user for 10 years now
18:02
<chabad360>
I'm very happy for you
18:05
in terms of customization that I have: secure boot, autostart scripts, single efi for initramfs and kernel, some xfce configs, vnc, netdata, journald forwarding, nbd cow, reboot at midnight, etc.
18:05
way too much pain
18:05
now I'm not so ready to let it go
18:06
<quinox>
understandable
18:07
at some point many years ago I automated my customizations on top of LTSP so that I could start fresh with every new LTS version with a single push-of-the-button
18:07
<chabad360>
hmm
18:08
I was thinking about doing something based on nix
18:08lucascastro has joined IRC (lucascastro!~lucascast@45-167-143-6.netfacil.inf.br)
18:08
<chabad360>
oh, I also have a custom kernel
18:08
<alkisg_web>
cow is done by ltsp, reboot is CRONTAB_REBOOT in ltsp.conf, autostart scripts is a session.desktop file, vnc is epoptes or veyon
18:09
Do you need a custom kernel
18:09
?
18:09
<chabad360>
yea
18:09
<alkisg_web>
Yeah then it does sound rather customized
18:09
<chabad360>
smaller and has some big optimizations for the atom platform
18:09
<alkisg_web>
Eh smaller is just 1 sec difference in boot time, nothing major
18:09
<chabad360>
true
18:10
but I kinda wanna be able to reboot between sessions
18:10
so the faster the better
18:10
<alkisg_web>
Switching to kexec is a lot faster if that is the goal
18:10
<chabad360>
that's not a bad idea
18:11
not sure what's the best way to do that tho
18:12
mmm, simpler than I thought
18:12
<alkisg_web>
Although reboot isn't needed if you do things on login instead of on boot
18:12
<chabad360>
now that I'm looking at it
18:12
<alkisg_web>
(like, home cleanups)
18:12
<chabad360>
only thing that happens on boot is nbd and hostname
18:12
and home just gets reset, not cleaned
18:12lucascastro has left IRC (lucascastro!~lucascast@45-167-143-6.netfacil.inf.br, Read error: Connection reset by peer)
18:13
<alkisg_web>
Why would you reboot then?
18:13
<chabad360>
cause I want it fresh for the next guy
18:13
and I don't need to use my ram if I use nbd cow
18:13
<alkisg_web>
But the previous guy can't leave any state
18:13
<chabad360>
he can
18:13
<alkisg_web>
After logoff
18:13
What state?
18:13
<chabad360>
the user doesn't get reset at logoff
18:13
<alkisg_web>
Don't users only have access to /home/username?
18:14
<chabad360>
its a default user for the whole kiosk
18:14
system
18:14
not shared
18:14
just not special per user
18:14
(and people are bad at logging off here)
18:14
<alkisg_web>
If you reset things at logoff, then you don't need a reboot, correct?
18:14
Right, that's why it's best to do it both at logoff and at login
18:15
<chabad360>
I'm just lazy and have it reboot
18:15
<alkisg_web>
The way kiosks usually work is that the user template is at /etc/.guest; it gets cloned in /home/guest on user login, and it gets wiped on logout
18:15
<chabad360>
ik
18:15
but keep in mind, I started from scratch
18:16
<alkisg_web>
Yeah that takes time ;)
18:16
<chabad360>
so I didn't really have good best practices guide
18:16
I'm gonna look into the kexec angle
18:16
<alkisg_web>
Practices changed a lot in ltsp over its 20 years of history
18:17
Btw are you using encryption for nbd cow? Or do passwords (stored under /home/username) travel in plaintext in local network?
18:17
<chabad360>
it's probably the easiest option
18:17
no encryption currently
18:17
but it doesn't run on the guest wifi (or wifi at all)
18:17
so I'm not as worried
18:17
but it is something I need to setup at some point
18:18
<alkisg_web>
Any user can see that data, it doesn't even require root
18:18
But anyway it's best not to talk about it :)
18:19
(ltsp has switched to nfs, nbd had a very bad stability record)
18:19
<chabad360>
no passwords get stored
18:19
and the ones that do need root to have a peek
18:20
<alkisg_web>
E.g. when a user logs in to his gmail, the password may get leaked to nbd
18:20
Without pressing "save"
18:20
<chabad360>
right
18:20
but who can see that, other than the current user (other than through netowrk fraking)
18:20
network*
18:20
<alkisg_web>
Any other user
18:20
<chabad360>
kexec -h
18:21
how?
18:21
<alkisg_web>
The nbd protocol doesn't have security
18:21
No authentication etc, its data is essentially public
18:22
And it doesn't run in a restricted port; anyone can access 10809
18:22
<chabad360>
ah, but cow is per host
18:22
<alkisg_web>
Yes, but again with no security in its connections
18:22
Anyway, time to go. Good to hear about your project!
18:22
<chabad360>
right
18:22
thanks for the help
18:23
I really appreciate it
18:23
<alkisg_web>
👍️
18:55shored has left IRC (shored!~shored@user/shored, Quit: ZNC 1.7.2+deb3 - https://znc.in)
18:56shored has joined IRC (shored!~shored@user/shored)
19:25chabad360 has left IRC (chabad360!~chabad360@71.245.242.3, Quit: Client closed)
19:56woernie has left IRC (woernie!~werner@p5b2965ee.dip0.t-ipconnect.de, Ping timeout: 272 seconds)
19:56woernie has joined IRC (woernie!~werner@p5b2965ee.dip0.t-ipconnect.de)
20:32ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
20:59chabad360 has joined IRC (chabad360!~chabad360@71.245.242.3)
21:00alkisg_web has left IRC (alkisg_web!~alkisg_we@srv1-dide.ioa.sch.gr, Quit: Client closed)
21:00
<chabad360>
I'm getting an error when trying to launch tigervnc in epoptes
21:15chabad360 has left IRC (chabad360!~chabad360@71.245.242.3, Quit: Client closed)
21:50woernie has left IRC (woernie!~werner@p5b2965ee.dip0.t-ipconnect.de, Remote host closed the connection)