IRC chat logs for #ltsp on irc.libera.chat (webchat)
Channel log from 28 June 2021 (all times are UTC)
| 05:12 | ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz) | |
| 07:02 | woernie has joined IRC (woernie!~werner@p5b2965ee.dip0.t-ipconnect.de) | |
| 12:01 | alkisg_web has joined IRC (alkisg_web!~alkisg_we@srv1-dide.ioa.sch.gr) | |
| 12:29 | lucascastro has joined IRC (lucascastro!~lucascast@177-185-133-236.dynamic.isotelco.net.br) | |
| 17:10 | chabad360 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:18 | chabad360 has left IRC (chabad360!~chabad360@71.245.242.3, Quit: Client closed) | |
| 17:18 | chabad360 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:21 | MendelGreenberg[ has joined IRC (MendelGreenberg[!~pseudoniu@2001:470:69fc:105::525b) | |
| 17:21 | MendelGreenberg[ 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:33 | lucascastro 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:48 | lucascastro 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:59 | lucascastro 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:08 | lucascastro 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:12 | lucascastro 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:55 | shored has left IRC (shored!~shored@user/shored, Quit: ZNC 1.7.2+deb3 - https://znc.in) | |
| 18:56 | shored has joined IRC (shored!~shored@user/shored) | |
| 19:25 | chabad360 has left IRC (chabad360!~chabad360@71.245.242.3, Quit: Client closed) | |
| 19:56 | woernie has left IRC (woernie!~werner@p5b2965ee.dip0.t-ipconnect.de, Ping timeout: 272 seconds) | |
| 19:56 | woernie has joined IRC (woernie!~werner@p5b2965ee.dip0.t-ipconnect.de) | |
| 20:32 | ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Quit: Leaving) | |
| 20:59 | chabad360 has joined IRC (chabad360!~chabad360@71.245.242.3) | |
| 21:00 | alkisg_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:15 | chabad360 has left IRC (chabad360!~chabad360@71.245.242.3, Quit: Client closed) | |
| 21:50 | woernie has left IRC (woernie!~werner@p5b2965ee.dip0.t-ipconnect.de, Remote host closed the connection) | |