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

Request log from specific day:

Channel log from 24 February 2020 (all times are UTC)

07:07	woernie has joined IRC (woernie!~werner@p57A0E378.dip0.t-ipconnect.de)
07:10	stellasolitaria has joined IRC (stellasolitaria!~jhonny5@159.213.93.166)
09:03	statler has left IRC (statler!~Georg@p54897A88.dip0.t-ipconnect.de, Remote host closed the connection)
09:30	none-ltsp-ubuntu has joined IRC (none-ltsp-ubuntu!02cc10e8@dslb-002-204-016-232.002.204.pools.vodafone-ip.de)
09:37	<none-ltsp-ubuntu> bonjour. i have a strange issue: on ubuntu with latest chromium the window gets rendered in a yellow color, popups (notifications) also. i have reset the profiles to default, still. has anyone experienced this issue and knows a workaround? ubuntu 18.4/zotac (i5, integrated gpu) client.Exiting GPU process due to errors during initialization in
09:37	.xsession-errors.
09:40	stellasolitaria has left IRC (stellasolitaria!~jhonny5@159.213.93.166, Read error: Connection reset by peer)
09:41	statler has joined IRC (statler!~Georg@gwrz.lohn24.de)
09:42	<alkisg> none-ltsp-ubuntu: thin or fat clients?
09:42	If thin, try X_SMART_COLOR_DEPTH=False in lts.conf
09:42	<none-ltsp-ubuntu> thin, thank you i will try that
09:43	stellasolitaria has joined IRC (stellasolitaria!~jhonny5@159.213.93.166)
10:05	GodFather has left IRC (GodFather!~rcc@wsip-66-210-242-210.ph.ph.cox.net, Read error: Connection reset by peer)
10:06	GodFather has joined IRC (GodFather!~rcc@wsip-66-210-242-210.ph.ph.cox.net)
10:16	<none-ltsp-ubuntu> alkisg: X_SMART_COLOR_DEPTH=False did not work.
10:18	<alkisg> none-ltsp-ubuntu: do you have epoptes installed? can i see?
10:18	!vnc-edide
10:18	<ltspbot> vnc-edide: To share your screen with me, open Epoptes → Help menu → Remote support → Host: srv1-dide.ioa.sch.gr, and click the Connect button
10:20	<none-ltsp-ubuntu> nope, cannot install remote control software. will create a screenshot (later...)
10:20	<alkisg> np; today I'm at a school, so I'm not watching irc frequently; might be a good idea to try more tomorrow
10:20	You can also test with the new ltsp
10:20	!install\
10:20	<ltspbot> I do not know about 'install\', but I do know about these similar topics: 'install'
10:20	<alkisg> !install
10:20	<ltspbot> install: To install LTSP: https://ltsp.org/docs/installation/
10:21	<alkisg> ...which uses netbooted fat clients by default, not thin clients
11:35	none-ltsp-ubuntu has left IRC (none-ltsp-ubuntu!02cc10e8@dslb-002-204-016-232.002.204.pools.vodafone-ip.de, Ping timeout: 260 seconds)
13:53	mnevans has left IRC (mnevans!8008b09d@zero.geol.umd.edu, Remote host closed the connection)
14:32	mnevans2 has left IRC (mnevans2!8008b09d@zero.geol.umd.edu, Remote host closed the connection)
14:32	Teridon has joined IRC (Teridon!~Teridon@dragon.teridon.com)
14:44	<Teridon> hi, LTSP noob here. I got a basic LTSP 20.01 setup working with a image out of /. Now I'm trying to add another image from a chroot but I'm having trouble understanding some of the basics. It looks like since I put my chroot in /srv/ltsp/bionic that it will automatically be served by the LTSP server. What's the difference between using NFS to share the chroot and building an image from the chroot?
14:51	<\|\|cw> the image is squashfs compressed and served via nbd. any updates you have to build a new image and reboot clients, nfs you won't have to do that.
14:58	<Teridon> ok thanks. I'm missing something else basic. I'm attempt to boot the image I made and I'm getting "cp: can't create directory ' /root/usr/share/ltsp': Read-only file system " Is it trying to write to the LTSP server? I don't want it to write to the server except the /home mount shared via SSHFS
15:01	(that's while running /script/init-bottom -- /usr/sbin/ltsp initrd-bottom
15:08	sorry, that error was trying to boot from the NFS mount and not the image.
15:08	do I need to install the "ltsp" package in the chroot?
15:14	I ask because the boot error is " ln: /root/Iib/systemd/system/multi-user.target.wants/ltsp.service: No such file or directory"
15:29	answering my own question: I installed ltsp in the chroot, and now the client boots... If I'm doing something wrong please tell me!
15:29	MWALTERS is now known as h8er
15:29	h8er is now known as MWALTERS
15:41	alkisg_web has joined IRC (alkisg_web!6db2b33f@109-178-179-63.pat.ren.cosmote.net)
15:44	<alkisg_web> Teridon, yes normally ltsp should be installed in the chroot
15:45	<Teridon> Let me ask this a different way: Is there a document for the minimum package requirements for a chroot? The wiki page ( https://github.com/ltsp/community/wiki/chroots ) doesn't seem to have one, it just says "Then login as root and install whatever packages you need"
15:45	thanks alkisg_web
15:46	<alkisg_web> Ltsp recommends sshfs, so it gets installed along with ltsp
15:46	But if you're using nfs home, its not needed
15:47	Ltsp doesn't require other packages
15:48	<Teridon> hmm, I did do "apt install --install-recommends ltsp" in the chroot. as I said, the client now boots but when I attempt to login I get: "/usr/share/ltsp/client/login/pamltsp: 181: /usr/share/ltsp/client/login/pamltsp: sshfs: not found"
15:49	<alkisg_web> Did you run ltsp image?
15:50	<Teridon> yse
15:50	*yes
15:50	and ltsp ipxe
15:52	<alkisg_web> I can only imagine that you didn't run ltsp image thatchroot AFTER you installed sshfs
15:52	<Teridon> to double-check : do I need to define users in the chroot? I didn't define any because I assumed LTSP did some magic
15:52	<alkisg_web> Correct. You add users on the seevee and run ltsp initrd
15:52	<Teridon> I didn't explicitly install sshfs -- you're saying installing ltsp should have done that right?
15:52	<alkisg_web> Right
15:52	Just check if its there now
15:54	<Teridon> no it's not!
15:54	looking back in my terminal.. I did "apt install --install-recommends ltsp", and I see "Recommended packages: sshfs"
15:54	<alkisg_web> Do you have universe in your sources?
15:55	<Teridon> No, just main. i.e. just what debootstrapchroot installed by default
15:55	<alkisg_web> Debootstrap puts universe afaik
15:55	<Teridon> sources.list is literally just main "deb http://archive.ubuntu.com/ubuntu bionic main"
15:56	one line
15:56	<alkisg_web> Universe is needed for sshfs
15:56	<Teridon> thanks will add it and try again
15:56	<alkisg_web> For ltsp too, normally, except now we need the ppa
16:01	<Teridon> thanks, login works now.
16:01	alkisg_web has left IRC (alkisg_web!6db2b33f@109-178-179-63.pat.ren.cosmote.net, Remote host closed the connection)
16:02	<alkisg> \|\|cw: the new LTSP doesn't use nbd anymore, it was too unstable, so we use squashfs-over-nfs
16:02	Plain nfs can also be used, it's automatically put in an ipxe menu
16:02	It's slower, but it might be useful in some cases
16:03	<Teridon> I want to boot using the image only (I don't want anybody trying to boot from NFS) -- can I just put the chroot directory somewhere else (outside /srv/ltsp)?
16:04	If so, then I assume I have to give "ltsp image" the full path? ("ltsp image /var/chroots/bionic") ?
16:04	<alkisg> Sure, but then you'll need to specify the full path
16:04	<Teridon> :)
16:04	<alkisg> ;)
16:05	Teridon: you may also just disable the ipxe menu
16:05	And put the default entry to be the squashfs-over-nfs one
16:06	<Teridon> ok, is there a document for how to do that?
16:06	<alkisg> man ltsp.conf, man ltsp ipxe
16:07	See also the ltsp.ipxe contents; especially the timeout part
16:07	<Teridon> ok I'll check those out. at some point I'm going to have to select the image based on MAC (probably) due to different hardware on different clients
16:07	<alkisg> a -1 timeout hides the menu if I recall
16:07	...normally, a single chroot can boot all hardware
16:07	But if you have different architectures, sure
16:07	(x86 vs armhf etc)
16:08	<Teridon> oh really? I had talked to someone else about it -- but they were using thin clients and LTSP5
16:08	<alkisg> There too, the same chroot could be used
16:08	Dunno what the advice you heard was
16:09	<Teridon> ok maybe I misheard. I appreciate the help and pointers!
16:09	<alkisg> np
17:22	jhumpf has joined IRC (jhumpf!96d15ba0@150.209.91.160)
17:22	<jhumpf> Hello
17:23	I am planning on distributing LTSP into a few labs. Max clients working at one time will be 75 or less. Approximately how much Ram should the LTSP server have?
17:24	Or is RAM on the LTSP server not important?
17:28	<Teridon> depends if the clients are thin or fat clients. What version of LTSP are you planning on using. Anything after LTSP 19.08 will be fat client by default
17:28	<jhumpf> I am assuming the most recent version
17:29	I have it installed and running, follwing documentation
17:29	following*
17:31	<quinox> !server-ram
17:31	<ltspbot> server-ram: LTSP server RAM really depends on the usage. But anyway here's an approximation: Server RAM in MB = 1500 + 30number-of-fat-clients + 300number-of-thin-clients
17:32	<jhumpf> And how is one sure if they are thin or fat clients
17:33	<MWALTERS> if you're using the "new" install instructions, they'll be fat clients
17:33	thin isn't supported anymore
17:33	!install
17:33	<ltspbot> install: To install LTSP: https://ltsp.org/docs/installation/
17:34	<jhumpf> So if the math is correct, you're telling me that I only need less than 4 GB of ram for 75 clients?
17:34	Fat clients
17:35	Seems low is the only reason I ask
17:35	<MWALTERS> fat clients are essentially remote storage only... all CPU/memory is on the client
17:36	as opposed to thin, where the only thing the client does is establish a remote session on the server
17:37	<Teridon> fat clients running the OS out of local RAM, correct?
17:37	<MWALTERS> correct
17:37	<alkisg> !forget server-ram
17:37	<ltspbot> The operation succeeded.
17:38	<alkisg> !learn server-ram as LTSP server RAM really depends on the usage. But anyway here's an approximation: Server RAM in MB = 2000 + 50number-of-fat-clients + 500number-of-thin-clients
17:38	<ltspbot> The operation succeeded.
17:38	<alkisg> OK those get up every year :D
17:38	<MWALTERS> lol
17:38	<quinox> :)
17:39	<jhumpf> ALso, as of right now, my setup has a script run on login that configures the home directoies for all application with set defaults. Another reason this has to be done every time, is because the home directories are not saved. So I also have a folder created and NFS mounts done inside the home directories upon login.
17:39	If I so chose, is there a way to have the home directoies used actually save back to the server?
17:39	<alkisg> jhumpf: use enough ram to cache you image, 8 GB should be more than enough. And use an SSD disk for home, if you have many users
17:39	Home by default is SSHFS, and optionally NFS
17:40	If you want something different, LTSP is flexible
17:40	<jhumpf> Well it would appear that it is currently doing neither. Does it matter that I am using ltsp image /?
17:41	<alkisg> No, it shouldn't matter. So you're saying that with the defaults, home isn't saved for you?
17:41	<jhumpf> No sir
17:41	<alkisg> Or did you specify things in ltsp.conf to change the defaults?
17:41	<jhumpf> I have not changed defaults
17:41	<alkisg> Log in to a client, and type: grep home /proc/self/mountinfo
17:41	And paste the output here
17:45	<jhumpf> Working on it
17:45	Does it matter that I have sssd on?
17:46	Also, when logging in from client, every AD user say:
17:46	"Invalid passwd/shadow for username"
17:46	<alkisg> Yes, it does matter; it's pamltsp that does the sshfs mount
17:47	For ad, one easy solution is to use nfs home
17:47	I think it should be easy to make pamltsp work with both ad authentication AND sshfs mount, but I don't have any AD setups so I haven't looked into it
17:47	You can also use nfs4 with kerberos and all the bells and whistles, unrelated to sshfs
17:49	<Teridon> oh I was hoping to get AD auth with sshfs mount. You're saying that doesn't work out of the box? There's a wiki entry but it looks like he's joining the client to the domain (on every boot!) using a very insecure script https://github.com/ltsp/community/wiki/LTSP-and-Samba-Windows-NT-Domain
17:49	<jhumpf> I am also seeing, there is no ltsp.conf
17:50	<alkisg> Teridon: yes currently it doesn't work out of the box; I'm planning to work on that next autumn; of course if sponsoring is found, it can be done sooner
17:50	It shouldn't be hard, but I don't have any ad setups, so it would take a lot of time for me to test all this
17:51	<Teridon> sponsoring might be possible. I need to talk to my management about it.
17:51	<alkisg> nice
17:51	<jhumpf> I do not see an ltsp.conf in my configuraton
17:52	<alkisg> jhumpf: so, for starters, enable nfs home; read `man ltsp.conf` and `man ltsp nfs` about these
17:52	Once you get everything working fine that way, you can move on to more difficult customizations like nfs4 with kerberos etc
17:52	jhumpf: yeah there's no ltsp.conf by default; the ltsp.conf man page mentions how to create the initial one
17:56	!ltsp.conf
17:56	<ltspbot> ltsp.conf: Configuration file for LTSP: https://ltsp.org/man/ltsp.conf/
17:58	<Teridon> If I want to enable sshd on the LTSP clients -- are the instructions here accurate? (except ltsp-update-image is "ltsp image" now) https://help.ubuntu.com/community/UbuntuLTSP/ClientTroubleshooting
17:59	<alkisg> Teridon: no, completely ignore old documentation
17:59	<Teridon> well that makes things difficult; there's not a lot of new documentation :)
18:00	<alkisg> Oh it's more than the old one; if you count quality
18:00	<Teridon> I'll certainly add community wiki entries as I learn how to do stuff. Is there a document about enabling services?
18:00	<alkisg> Teridon: I'm preparing a tiny how-to, but in the meantime, keep in mind it's unsafe to have private keys exposed over nfs,
18:01	Teridon: man ltsp.conf => KEEP_SYSTEM_SERVICES, give me a minute,
18:01	<Teridon> which private keys? In the user's home? or system host private keys?
18:03	<alkisg> !learn sshd as `Exposing sshd host keys over NFS is unsafe, so it's disabled by default. To keep it, put in ltsp.conf OMIT_IMAGE_EXCLUDES="etc/ssh/ssh_host_*" under [server] and KEEP_SYSTEM_SERVICES="openssh-server" under [clients]`
18:03	<ltspbot> The operation succeeded.
18:03	<alkisg> !sshd
18:03	<ltspbot> sshd: Exposing sshd host keys over NFS is unsafe, so it's disabled by default. To keep it, put in ltsp.conf OMIT_IMAGE_EXCLUDES="etc/ssh/ssh_host_*" under [server] and KEEP_SYSTEM_SERVICES="openssh-server" under [clients]
18:03	<alkisg> !epoptes
18:03	<ltspbot> epoptes: Epoptes is a computer lab administration and monitoring tool. It works on Ubuntu and Debian based labs with LTSP or non-LTSP servers, thin and fat clients, standalone workstations, NX clients etc. More info: https://epoptes.org
18:03	<alkisg> !forget sshd
18:03	<ltspbot> The operation succeeded.
18:04	<alkisg> !learn sshd as `Exposing sshd host keys over NFS is unsafe, so it's disabled by default and !epoptes is recommended instead. To keep sshd, put in ltsp.conf OMIT_IMAGE_EXCLUDES="etc/ssh/ssh_host_*" under [server] and KEEP_SYSTEM_SERVICES="openssh-server" under [clients]`
18:04	<ltspbot> The operation succeeded.
18:04	<Teridon> does epoptes provide a shell or is it VNC-only?
18:06	<alkisg> It provides a shell as well
18:06	With socat + screen
18:11	<Teridon> I'm not sure what you mean. again I know this is old documentation, but something like: https://help.ubuntu.com/community/UbuntuLTSP/Troubleshooting/socat-screen ? i.e. tell epoptes to run a shell script like the one in that wiki page?
18:11	<alkisg> Teridon: no, just "right click from epoptes and open terminal"
18:11	<Teridon> lol oh
18:11	<alkisg> The epoptes server is supposed to have GUI, but you can get a shell/terminal of the clients
18:11	That is using screen/socat in the background, but you don't need to care about the implementation
18:12	The epoptes clients do not need xorg
18:15	<jhumpf> So when I have users login and it says: " invalid passwd/shadow for" what is that
18:16	<Teridon> right now epoptes is not detecting my LTSP client (i.e. "Detected clients" is empty). Is this another "missing package" issue on the client?
18:16	wait, does someone need to be logged in on the client for it to be detected?
18:16	right now it's at the login screen and no one is logged in
18:17	<alkisg> Teridon: the chroot one? You need to install epoptes-client in it, and fetch the certificate, see epoptes.org installation
18:18	<Teridon> ok thanks
18:18	<alkisg> jhumpf: either your passwd/shadow is actually broken (check with pwck), or, there's no entry there for that sssd user, and pamltsp just warns that it didn't find it
18:18	<jhumpf> What about my error on login?
18:20	<alkisg> https://github.com/ltsp/ltsp/issues/16 and https://github.com/ltsp/community/wiki/LTSP-and-Samba-Windows-NT-Domain have some notes about ldap and ltsp
18:24	<Teridon> is running "ltsp ipxe" required after every image update, or only when adding a new image?
18:25	<alkisg> Only when adding new image
18:25	(or changing ltsp.conf KERNEL_PARAMETERS)
18:29	<Teridon> In my chroot I installed epoptes-client and fetched the cert and rebuilt the image, and booted from it. epoptes now sees the client, and I can open a root/local terminal. But a user/local terminal isn't starting completely. I get a new xterm, but no shell prompt
18:29	<alkisg> Has the user logged in?
18:29	<Teridon> not the first time i tested it, but then I logged in on the client and tried again; same result
18:30	<alkisg> Run `ps faux \| grep epoptes-client` on the client, and see if there's an epoptes-client user process
18:30	There should be two, one root owned and one user owned
18:31	<Teridon> only one root-owned
18:31	<alkisg> Open a terminal locally as the user, and run epoptes-client from there
18:31	See if it can run without issues, and if then epoptes works fine (open user terminal etc)
18:32	<Teridon> I don't have X installed on the client/chroot (yet)
18:32	<alkisg> If that's the case, then it's only a matter of finding why /etc/xdg/autostart/epoptes-client.desktop didn't take effect
18:32	Ah, ok that's the one then
18:32	<Teridon> you said epoptes didn't require xorg :-D
18:32	<alkisg> Yup
18:32	/etc/xdg/autostart does though
18:33	So, just open a root terminal, and then su to whatever user you like
18:33	<Teridon> ok cool. Obviously a weird use case. I don't think many people are going to be running LTSP without X!
18:33	<alkisg> I do have epoptes connections to several headless servers
18:34	So I made sure that xorg isn't pulled in when installing epoptes-client
18:34	<jhumpf> According to those, I am doing the tight things
18:34	So it is not clear why I still see this error on login
18:35	<Teridon> hmmm.. I do have /etc/xdg/autostart/epoptest-client.desktop
18:35	<alkisg> jhumpf: if you're using sssd, you should disable pamltsp
18:35	Teridon: /etc/xdg/autostart isn't used on console logins, only on xorg logins
18:35	<Teridon> derp ok of course. sorry
18:36	<alkisg> jhumpf: but in any case, it's just a warning, it doesn't affect anything
18:36	<jhumpf> I agree, but I guarentee there will be people complaining that it shouldnt be there
18:37	guarantee****
18:38	<alkisg> jhumpf: which one, pamltsp? It's used by everyone that doesn't have ad
18:38	<jhumpf> The error
18:38	<alkisg> (ldap, ad, sssd, etc etc)
18:38	<jhumpf> THey will complain about the error
18:38	<alkisg> If you're not using pamltsp, you're supposed to remove it
18:38	It won't get automatically disabled
18:38	You use an ltsp.conf parameter for that
18:40	<jhumpf> There does not seem to be one
18:43	<alkisg> OMIT_FUNCTIONS="pam_main"
18:44	Under [clients], and `ltsp initrd`
18:53	<jhumpf> Fixed it
18:53	Thank you!
18:53	<alkisg> np
18:53	If you write a wiki page about all that, others will find it :)
18:53	So that they don't complain, as you said
19:25	<Teridon> anyone seen this before? I installed 'ubuntu-mate-desktop' in my bionic chroot. On login I get this error: https://teridon.com/pictures/ltsp-chroot-ubuntu-mate-error-2020-02-24.png
19:26	google results suggested changing the keyboard input method to "XIM"; I did that on my client but that didn't seem to fix the issue
19:26	also even if that did work it would only work for that boot (how to prevent it on next boot)? note that after clicking "OK" login worked fine
19:27	<alkisg> Teridon: it's probably missing some dependencies; what's the point of installing mate-desktop in a minimal chroot instead of extracting a usual mate-desktop installation into a chroot?
19:27	Also, why chroot and not VM?
19:28	<Teridon> I don't understand the distinction between "installing mate-desktop in a minimal chroot instead of extracting a usual mate-desktop installation into a chroot"
19:28	<alkisg> You install ubuntu-mate in virtalbox
19:28	then you copy the disk in a chroot
19:28	<Teridon> as for the second question: I don't know what I'm doing, I'm making it up as I go along :)
19:29	<alkisg> If you're planning to use mate-desktop, the best setup is chrootless, then vm.
19:29	chroot is last
19:29	bbiab
19:29	<Teridon> I did notice the installer while in chroot had a few errors (e.g. determining the run-level) ; I guess it didn't work fully.
19:34	I guess I went chroot first because my LTSP server is a VM (vSphere/ESXi) . I thought I should avoid multiple levels of virtualization
19:43	<alkisg> Teridon: your ltsp server is the template for the clients, nothing more
19:43	Just use chrootless
19:48	If you also want your home there, then use another vsphere vm as the "chroot"
19:49	<Teridon> hmmm I appreciate that, but I'm trying to design for robustness. Another reason I was going to use chroot was an attempt to scale the servers. My VMware cluster has three hosts; I was going to run one LTSP server per host, so that if a host went down I wouldn't lose all the clients. I was going to put the chroot (or VM I guess) on shared storage, so that all servers could build from it.
19:49	I hadn't figured out how to have a shared home on separate servers yet :-/
19:50	let me ask this: If I use SSHFS for home with only ONE server, and the host goes down -- what happens to the clients? They all freeze on write to /home, right?
19:50	<alkisg> Teridon: the basic idea is, "use whatever is usual for your image"
19:50	Desktops are meant to be maintained via GUI; many programs break if you don't use gui, even installers fail
19:51	There's load balacing, fail over, redundancy etc in lots of levels
19:51	For example, if you want the clients to survive when a server goes down, you'd use a network file system designed for that, glusterfs
19:51	etc
19:52	cephfs, rados, etc etc, many choices
19:53	You would have one VM, which publishes one chroot, which then goes to cephfs or to rados, so that it's available even if a server goes down
19:55	statler has left IRC (statler!~Georg@gwrz.lohn24.de, Remote host closed the connection)
20:54	vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
20:56	hank77 has left IRC (hank77!~erik@216.194.5.229, Quit: Konversation terminated!)
21:04	woernie has left IRC (woernie!~werner@p57A0E378.dip0.t-ipconnect.de, Remote host closed the connection)
21:08	jhumpf has left IRC (jhumpf!96d15ba0@150.209.91.160, Remote host closed the connection)