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

Request log from specific day:

Channel log from 16 November 2022 (all times are UTC)

00:33	we6jbo has joined IRC (we6jbo!~we6jbo@2603-8001-5b43-4000-9b98-b768-55d7-4003.res6.spectrum.com)
01:15	vagrantc has left IRC (vagrantc!~vagrant@2600:3c01:e000:21:7:77:0:20, Quit: leaving)
04:35	Vercas6 has joined IRC (Vercas6!~Vercas@gateway/tor-sasl/vercas)
04:39	Vercas6 has left IRC (Vercas6!~Vercas@gateway/tor-sasl/vercas, Client Quit)
04:40	Vercas6 has joined IRC (Vercas6!~Vercas@gateway/tor-sasl/vercas)
04:44	Vercas6 has left IRC (Vercas6!~Vercas@gateway/tor-sasl/vercas, Client Quit)
04:45	Vercas6 has joined IRC (Vercas6!~Vercas@gateway/tor-sasl/vercas)
04:46	we6jbo has left IRC (we6jbo!~we6jbo@2603-8001-5b43-4000-9b98-b768-55d7-4003.res6.spectrum.com, Remote host closed the connection)
04:49	Vercas6 has left IRC (Vercas6!~Vercas@gateway/tor-sasl/vercas, Client Quit)
04:50	Vercas6 has joined IRC (Vercas6!~Vercas@gateway/tor-sasl/vercas)
04:54	Vercas6 has left IRC (Vercas6!~Vercas@gateway/tor-sasl/vercas, Client Quit)
04:55	Vercas6 has joined IRC (Vercas6!~Vercas@gateway/tor-sasl/vercas)
05:04	we6jbo has joined IRC (we6jbo!~we6jbo@2603-8001-5b43-4000-cba1-f7d1-a5ba-efa8.res6.spectrum.com)
06:29	we6jbo has left IRC (we6jbo!~we6jbo@2603-8001-5b43-4000-cba1-f7d1-a5ba-efa8.res6.spectrum.com, Remote host closed the connection)
06:38	woernie has joined IRC (woernie!~werner@p5b2962ea.dip0.t-ipconnect.de)
06:46	Vercas6 has left IRC (Vercas6!~Vercas@gateway/tor-sasl/vercas, Ping timeout: 255 seconds)
07:06	Vercas6 has joined IRC (Vercas6!~Vercas@gateway/tor-sasl/vercas)
07:44	ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
08:23	alkisg_irc has left IRC (alkisg_irc!~Thunderbi@srv1-dide.ioa.sch.gr, Ping timeout: 256 seconds)
08:24	alkisg_irc has joined IRC (alkisg_irc!~Thunderbi@2a02:587:744e:8500:c24a:ff:fe02:bc1e)
08:31	fiesh has left IRC (fiesh!~fiesh@2003:fb:1018::21, Read error: Software caused connection abort)
08:31	fiesh has joined IRC (fiesh!~fiesh@2003:fb:1018::21)
08:33	highvoltage has left IRC (highvoltage!~highvolta@shell.jonathancarter.org, Read error: Software caused connection abort)
08:33	highvoltage has joined IRC (highvoltage!~highvolta@shell.jonathancarter.org)
08:52	Vercas6 has left IRC (Vercas6!~Vercas@gateway/tor-sasl/vercas, Remote host closed the connection)
08:56	Vercas6 has joined IRC (Vercas6!~Vercas@gateway/tor-sasl/vercas)
09:20	Vercas6 has left IRC (Vercas6!~Vercas@gateway/tor-sasl/vercas, Quit: Ping timeout (120 seconds))
09:49	Vercas6 has joined IRC (Vercas6!~Vercas@gateway/tor-sasl/vercas)
09:53	Vercas6 has left IRC (Vercas6!~Vercas@gateway/tor-sasl/vercas, Remote host closed the connection)
09:54	Vercas6 has joined IRC (Vercas6!~Vercas@gateway/tor-sasl/vercas)
10:08	Vercas6 has left IRC (Vercas6!~Vercas@gateway/tor-sasl/vercas, Ping timeout: 255 seconds)
10:22	Vercas6 has joined IRC (Vercas6!~Vercas@gateway/tor-sasl/vercas)
11:37	Vercas6 has left IRC (Vercas6!~Vercas@gateway/tor-sasl/vercas, Quit: Ping timeout (120 seconds))
12:02	Vercas6 has joined IRC (Vercas6!~Vercas@gateway/tor-sasl/vercas)
12:08	Vercas6 has left IRC (Vercas6!~Vercas@gateway/tor-sasl/vercas, Quit: Ping timeout (120 seconds))
12:34	Vercas6 has joined IRC (Vercas6!~Vercas@gateway/tor-sasl/vercas)
13:09	we6jbo has joined IRC (we6jbo!~we6jbo@2603-8001-5b43-4000-6664-07c4-3f4b-7084.res6.spectrum.com)
13:26	Vercas6 has left IRC (Vercas6!~Vercas@gateway/tor-sasl/vercas, Quit: Ping timeout (120 seconds))
13:54	Vercas6 has joined IRC (Vercas6!~Vercas@gateway/tor-sasl/vercas)
14:18	we6jbo has left IRC (we6jbo!~we6jbo@2603-8001-5b43-4000-6664-07c4-3f4b-7084.res6.spectrum.com, Ping timeout: 260 seconds)
14:30	we6jbo has joined IRC (we6jbo!~we6jbo@2603-8001-5b43-4000-6202-9a83-fef2-028f.res6.spectrum.com)
14:55	we6jbo has left IRC (we6jbo!~we6jbo@2603-8001-5b43-4000-6202-9a83-fef2-028f.res6.spectrum.com, Remote host closed the connection)
15:34	john has joined IRC (john!~john@46-162-67-128.cust.bredband2.com)
15:34	john is now known as Guest3221
15:38	<Guest3221> Hi, total beginner at admin and servers. I have read about LTSP and plan to use it to setup a computer lab. I had two questions.
15:38	1. If I have a lab of laptops where I install Ubuntu onto them (on their own harddrives) what would be best to use to boot my LTSP image, chroot or VM? Does VM mean I need to install a VM software on the laptops or how does it boot from the VM image? I feel the docs don't go into details what these are, I suppose they assume people are familiar
15:38	what VM and chroot is
15:38	2. How easy is it to install a software and make sure every computer can use that software? Will software be "streamed" or are they run locally on the image?
15:38	<alkisg> Hi Guest3221
15:39	The typical LTSP setup would be like this:
15:39	Suppose you have 12 laptops. You completely ignore the hard drive of 11 of them. You don't install anything there. No OS. Or just throw the hard drive outside the window.
15:40	Then you label one of them as the "ltsp server", even if it's no different than the others. You install e.g. Ubuntu MATE 22.04 there.
15:40	And then you follow the https://ltsp.org/docs/installation/ page, the chrootless paragraph, and that way a clone of that single hard disk installation is published to the local network
15:41	You don't need any VMs or chroots; just do that ^
15:41	It takes 1 minute to run that commands, then 10 minutes of waiting, and the other laptops can then netboot over the network
15:43	<Guest3221> First of all, thank you so much!
15:43	Ah, and I can then setup user accounts for different users so they have their own home folder where they can put their work? And all software that are installed on the ltsp server will be available on the client machines? Do they need to be restarted or turned off while changes are made on the server?
15:44	<alkisg> You setup user accounts and software on the ltsp server. To make them available to the network, you need to run `ltsp initrd` for new accounts (=1 second), or `ltsp image` for new software (=10 minutes)
15:45	You can do that while the clients are used normally. But to get the changes, they'll need to be rebooted
15:45	All home directories will be stored on the server /home/username
15:46	The users will access them using "sshfs" (or nfs) over the network
15:47	<Guest3221> Okay! Sounds like chrootless is the way to go for me then. What is a typical usage where chrootless would not be a good way or not possible?
15:47	<alkisg> If your server is PC and the clients are Raspberries
15:48	<Guest3221> Do they need to actually use commands like "sshfs"? The usage is for computer illiterate students that can barely use keyboard and mouse.
15:48	<alkisg> If you server has webmin, ldap, apache, and a lot of other services, is headless etc, and you want the clients to be normal desktops
15:49	These setup is optimized for schools, we're using it here in Greece in more than 1000 schools. Administrators are IT teachers (not sysadmins), and users are kids from 5 to 18 years old
15:49	*This
15:50	So no, not even teachers need to use commands like sshfs
15:50	<Guest3221> Okay, I suppose I'll try installing it and see how intuitive it is to use. But I doubt using commands will be nice. Would be better if the home folder was mounted for each user by default
15:50	That's good to hear
15:50	<alkisg> Yes, the home folder is automatically mounted by just logging in
15:50	<Guest3221> What makes Raspberry Pis unsuited for chrootless?
15:50	<alkisg> You can login with either a password, or with a single click, or even autologin
15:51	PC is x86_64 architecture, raspberry pi is armhf or arm64. They can't be booted from the same installation
15:51	<Guest3221> Ahh I see! Thank you, then I understand the limitation there.
15:52	I suppose controlling the server remotely should be no issue either with ssh. And with epoptes I can issue commands to turn off computers if I'd like to service the image on the server?
15:53	<alkisg> Sure, but you don't need to turn them off while managing the server image
15:53	The clients can keep working normally while you do image maintenance
15:54	There's the "current image" and the "new image", they can coexist
16:06	<Guest3221> Ah, then I can force them to restart instead after servicing. What would be a typical usage for VM image then? Would that be a PC which should be used as a regular desktop and also virtualize the ltsp image to control both in the same environment?
16:07	<alkisg> Guest3221: no. In the VM image case, you maintain the VM, then you shut it off, then you run `ltsp image`. The VM doesn't need to be running for the clients to boot
16:07	You should only use a VM when the server installation is veeeeery different than the client installation
16:08	Eg. if the server is a headless rack mounted thing and the clients are desktops
16:08	<Guest3221> I see. Then for my case chrootless is best! Thank you, your help is really really useful and easy to understand
16:08	<alkisg> For example, teachers here use the ltsp server as their desktop PC, and they control the client PCs from there. There's no need to use a VM for that.
16:09	<Guest3221> Could a teacher logon to one of the clients with their credentials and access epoptes or is that run only on server-computer?
16:09	<alkisg> https://epoptes.org/documentation/run-fat/
16:09	There are two ways to do that, I documented them there ^
16:12	<Guest3221> Seems the remote is more flexible. In the other scenario the "epoptes-pc" is vulnerable and more valuable in an environment where the possible adminstrators are also quite computer illiterate.
16:12	In your experience, is the remote way slow or decent speed?
16:14	<alkisg> It's decent if you have gigabit lan
16:14	<Guest3221> Okay. Good I will make sure to implement gigabit bandwidth
16:16	I take it you are pretty active in developing LTSP and epoptes. Thank you so much for your contributions. This will be put to good use.
16:16	<alkisg> 👍️
16:40	<Guest3221> With this chrootless setup; configuring software or setting backgrounds is possible thanks to tmpfs I suppose, but when the users restart the computer and login again, or login to another computer, are their preferences such as settings for software and screen wallpaper saved?
16:45	vagrantc has joined IRC (vagrantc!~vagrant@2600:3c01:e000:21:7:77:0:20)
18:21	Guest3221 has left IRC (Guest3221!~john@46-162-67-128.cust.bredband2.com, Quit: Client closed)
18:45	<alkisg> Guest3221: tmpfs/overlayfs/squashfs are for the / root file system; there's nothing tmpfs about /home, it's sshfs
18:45	Change are immediately reflected to the server
19:11	woernie has left IRC (woernie!~werner@p5b2962ea.dip0.t-ipconnect.de, Remote host closed the connection)
19:54	Vercas6 has left IRC (Vercas6!~Vercas@gateway/tor-sasl/vercas, Remote host closed the connection)
19:55	Vercas63 has joined IRC (Vercas63!~Vercas@gateway/tor-sasl/vercas)
20:14	eu^broadband-46- has joined IRC (eu^broadband-46-!~eu^broadb@broadband-46-242-13-254.ip.moscow.rt.ru)
20:15	<eu^broadband-46-> Hello guys. Does somebody have experience with 2FA authentication based on LSTP?
20:17	NickolayZaytsev[ has joined IRC (NickolayZaytsev[!~madcmk2ma@2001:470:69fc:105::2:be6f)
20:17	<NickolayZaytsev[> 2 chats for the same room. That's interesting)
20:18	eu^broadband-46- has left IRC (eu^broadband-46-!~eu^broadb@broadband-46-242-13-254.ip.moscow.rt.ru, Client Quit)
20:18	<vagrantc> irc and matrix, from what i recall?
20:18	bridged together somehow...
20:19	<NickolayZaytsev[> yep)
20:19	It would be a huge help, if you'll gave me some information about it. Thanks in anyway
20:19	<vagrantc> i only use the irc interface, so no idea really
20:20	looks pretty much the same since i started using it in 2005 or 2006 ... before matrix was even an inkling of an idea :)
20:21	<NickolayZaytsev[> FYI. This is my question form the matrix: "Hello guys. Does somebody have experience with 2FA authentication based on LSTP?"
20:21	Any help will be appreciate
20:23	<vagrantc> yeah, saw it
20:24	but not experience with it
20:27	NickolayZaytsev[: that said, LTSP basically just uses pam authentication ... so if you can hook into pam with whatever 2FA you're doing ... that ought to work fine.
20:28	although it depends on what you're trying to use 2FA for
20:28	e.g. logging into the clients themselves, or using remote sites requiring 2FA ?
20:28	in any case, shouldn't be much different from just configuring it on a "regular" computer.
20:30	<alkisg> Nickolay Zaytsev: AFAIK you can e.g. enable google-authenticator and it'll show up in the DM login screen; indeed the same as on a non-ltsp installation
20:30	<NickolayZaytsev[> Ok.
20:30	Let come up from the other side: Is there any easy way, to change amount and content of visible on thin client side X-windows?
20:30	The standard flow is "username" windows, "password" after that and you are logged in.
20:30	But can I add some extra X-windows? Like an input for special "code" after "password", before logging in?
20:31	<alkisg> PAM is not username/password. PAM is a "stdin/stdout chat". It can keep asking questions and questions for ages if needed.
20:31	So yeh the google authenticator pam module hooks there and is displayed in the login screen
20:32	I would suggest that you test something like this: https://www.digitalocean.com/community/tutorials/how-to-set-up-multi-factor-authentication-for-ssh-on-ubuntu-20-04
20:32	...on a non-ltsp installation first, to see how 2FA and PAM works; then the same will also work in LTSP
20:34	<NickolayZaytsev[> Sry, I'm new in PAM/LTSP topics.
20:34	So if I will add a google authenticator pam module, extra X-window will appears automaticly, when the time has come to input the code?
20:34	<alkisg> Yes. It's not a new x-window, the same text box is reused throught the PAM conversation
20:34	<NickolayZaytsev[> > <@alkis:matrix.org> I would suggest that you test something like this: https://www.digitalocean.com/community/tutorials/how-to-set-up-multi-factor-authentication-for-ssh-on-ubuntu-20-04
20:34	> ...on a non-ltsp installation first, to see how 2FA and PAM works; then the same will also work in LTSP
20:34	Almost. Buyt we are using our own module. So if I understand you correct, all I need is create PAM module and add it to the flow
20:35	And the inputs will be controlled in the PAM module
20:35	<alkisg> Right, if you create a PAM module then it will hook into the login process, either the DM window or even the vt2 text login
20:36	And all that is unrelated to LTSP; it's just how PAM works
20:36	<NickolayZaytsev[> That's amazing! I thought it is only for the bash console conversation, not for the desktop things at all
20:38	alkisg: Thank you very much. You help me a lot.
20:38	Can I come back with some more complex questions, if I'll failure with my tries?)
20:39	<alkisg> Sure, although if they're PAM (=non LTSP) questions, it might be best to locate some PAM-related support channel...
20:39	pamltsp is just a python script, it's not a fully fledged pam module; these are typically written in C
20:42	<NickolayZaytsev[> alkisg: I see. I guest the last one question, is there any specialties in installation PAM modules for the LTSP clients? Or all I need is add apropriate PAM module to the client image (chroot folder) and correct the pma settings?
20:43	pam*
20:43	<alkisg> ls /usr/share/pam-configs/
20:43	<NickolayZaytsev[> Sorry if I sound stupid
20:43	<alkisg> As long as your pam module is registered properly, like these ^, then it will play well with all the others,like pamltsp
20:44	While hand-made changes to /etc/pam.d usually don't fare so well when more pam modules are added
20:44	Many tutorials on the internet skip the "correct configuration for pam-auth-update" step; make sure you use pam-auth-update
20:45	Vercas63 has left IRC (Vercas63!~Vercas@gateway/tor-sasl/vercas, Quit: Ping timeout (120 seconds))
20:45	<NickolayZaytsev[> For the better understanding: "pamltsp" is the special PAM module? He is like initializer and must be the first one?
20:46	Vercas6 has joined IRC (Vercas6!~Vercas@gateway/tor-sasl/vercas)
20:46	<NickolayZaytsev[> * the special kind of the PAM module?
20:49	alkisg: I'm comfused a little bit. Where I need to call "pam-auth-update" if I changing the client image? I thought it's just files, that I need to prepare in the proper way. All of the magic will be done while thin client will start. I'm wrong?
20:50	<alkisg> PAM is a stack of modules. They are organized in /usr/share/pam-configs/. Then pam-auth-update is called, and it generates /etc/pam.d/* files
20:50	So when LTSP boots, it injects a file in /usr/share/pam-configs/ and then calls pam-auth-update
20:51	When you'll create your own module, you'll do that same task inside the chroot/image/whatever you're preparing, you don't need to do it on boot
20:52	pamltsp is a "small" pam module written in python, using pam_exec. It's like other pam modules, but it doesn't have many abilities. The goal was to make it interpreted, so as to be able to inject it in any chroot of any architecture
20:52	You won't have that limitation, so you should use proper C code, not python
20:55	<NickolayZaytsev[> alkisg: Still confused about client/server folders. If I will call "pam-auth-update" at any place at the server, does it affect /usr only server folder, not the client one? Ot LTSP will merge it for me before client start?
20:56	> <@alkis:matrix.org> When you'll create your own module, you'll do that same task inside the chroot/image/whatever you're preparing, you don't need to do it on boot
20:56	* Still confused about client/server folders. If I will call "pam-auth-update" at any place at the server, does it affect only /usr folder of the server, not the client's one? Or LTSP will merge it for me before client start?
20:56	<alkisg> Are you using chrootless ltsp, or a chroot, or a VM image?
20:56	<NickolayZaytsev[> chrootless. Sry for disinformation
20:56	Like /ltsp/something/i386
20:57	<alkisg> You said chrootless and then you mentioned a chroot :)
20:57	What command are you using to build the image?
20:57	ltsp image /? ltsp image i386? ltsp-update-image?
20:58	<NickolayZaytsev[> That's a tricky question, cause I'm the guy how has deal with already builded image)
20:58	I gues ltsp image i386
20:59	<alkisg> In LTSP5 it was `ltsp-update-image i386`, in the new ltsp it's `ltsp image x86_64`, but anyway, I assume you're using a chroot
20:59	That then means that you do your changes inside the chroot
20:59	Then you run ltsp image i386, then you reboot the clients
21:00	<NickolayZaytsev[> We are using old version of LTSP, I gues. Cause it's for Debian 8 (Jessie)
21:00	<alkisg> The old ltsp isn't using PAM, so all this conversation was inappropriate :)
21:01	Using PAM was one of the basic reasons for rewriting LTSP
21:01	<NickolayZaytsev[> Oh, really? So it's only for the new versions?
21:02	<alkisg> Yes, although the new LTSP version does work on Jessie
21:02	You just need to add the PPA
21:03	<NickolayZaytsev[> alkisg: And swicth from Jessie to the something new, right?
21:03	<alkisg> No, the PPA supports Jessie
21:03	It's up to you if you want something newer or not
21:03	<NickolayZaytsev[> Ah, "does", not "doesn't"
21:04	oh207 has joined IRC (oh207!~oh207@pool-72-69-11-48.nycmny.fios.verizon.net)
21:08	<NickolayZaytsev[> Ok. Let me summorize our conversation please. I need to do following steps:
21:08	1. Add the PPA and update LSTP for the new one rewritted version
21:08	2. Seach for the proper command for the create the image
21:08	3. Add needed PAM modules. Or maybe I can just edit pamltsp, the python script
21:08	4. Do the image update
21:08	And it must works after all of it. Right?
21:20	<vagrantc> heh. i sometimes forget the old-style LTSP is still used by some people :)
21:21	even though i worked with that for many more years and was more involved, i'm not sure i know it better than the new stuff :)
21:22	<alkisg> Nickolay Zaytsev: sounds good. What are you going to use for 2FA, what will your module actually do?
21:23	vagrantc: do you maintain any ltsp installations currently?
21:23	<vagrantc> alkisg: no ... did a little consult with someone late last year
21:24	which actually was working with new, old and ancient versions of LTSP
21:24	<alkisg> Heh, challenging!
21:25	<vagrantc> i think we finally got them to drop ltsp 4.2
21:25	by ... supporting some ancient debian version with ltsp 5.x
21:25	<alkisg> ...I'm afraid to ask what was the initial kernel they were running!
21:26	<vagrantc> it's actually interesting ... not too hard to support ltsp 4.x, ltsp 5.x and modern ltsp all side-by-side
21:27	other than how hard it is to support ltsp 4.x at this poitn
21:31	<NickolayZaytsev[> <alkisg> "Nickolay Zaytsev: sounds good..." <- It will added another layer or login/password.
21:31	Let me explain it. We have LTSP installation with a few fixed login/passes. That logins is unpersonal, they are shared. Now we need to add some personalization for them. So every user will be needed add his personal ID and specal code after the login/pass, from the mobile application (like Google Authenticatior)
21:31	s///, s/is/are/
21:32	So shred login/pass, personal ID + code from mobile app
21:33	<alkisg> .... And why don't you switch to personalized logins with different accounts instead?
21:33	<NickolayZaytsev[> Is Virtual Box good enogh to create test environment for the LTSP installation? Or there is easy way?
21:33	<alkisg> Virtualbox is fine
21:34	<NickolayZaytsev[> alkisg: Smae question. But the answer is deadly horrible - it's business thing. And we can't do anighting with it :(
21:35	oh207 has left IRC (oh207!~oh207@pool-72-69-11-48.nycmny.fios.verizon.net, Quit: Konversation terminated!)
21:35	<NickolayZaytsev[> So it's a fixed context for us. Like Jessie at the mometn
21:35	oh207 has joined IRC (oh207!~oh207@pool-72-69-11-48.nycmny.fios.verizon.net)
21:35	<NickolayZaytsev[> alkisg: Thank you. Thank you for the conversation, Creator)
21:36	<alkisg> But if a user logins to a shared account then they have access to the authenticator secrets. It's completely unsafe
21:36	<NickolayZaytsev[> * - it's a business thing.
21:36	<alkisg> Anyway it's late here good night and good luck
21:36	<NickolayZaytsev[> alkisg: Why? Secrets will be stored on the server. One secret per eash user, in safe zone
21:37	alkisg: Yeah. Thank you again. And good night. I'll share with you my expirience after the success)
22:02	ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving)
22:58	Vercas6 has left IRC (Vercas6!~Vercas@gateway/tor-sasl/vercas, Ping timeout: 255 seconds)
23:24	oh207 has left IRC (oh207!~oh207@pool-72-69-11-48.nycmny.fios.verizon.net, Ping timeout: 256 seconds)
23:29	Vercas6 has joined IRC (Vercas6!~Vercas@gateway/tor-sasl/vercas)