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

Request log from specific day:

Channel log from 21 March 2019 (all times are UTC)

00:00	adrianorg has left IRC (adrianorg!~adrianorg@189.114.158.245, Ping timeout: 246 seconds)
06:03	kjackal has joined IRC (kjackal!~quassel@2a02:587:3119:ef00:d972:2fda:fe23:da3e)
06:08	statler has joined IRC (statler!~Georg@p5489790B.dip0.t-ipconnect.de)
06:23	vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
06:28	kjackal has left IRC (kjackal!~quassel@2a02:587:3119:ef00:d972:2fda:fe23:da3e, Ping timeout: 252 seconds)
06:31	woernie has joined IRC (woernie!~werner@pD9E8B7B2.dip0.t-ipconnect.de)
06:59	kjackal has joined IRC (kjackal!~quassel@2a02:587:3119:ef00:d972:2fda:fe23:da3e)
07:34	ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
07:58	kjackal has left IRC (kjackal!~quassel@2a02:587:3119:ef00:d972:2fda:fe23:da3e, Ping timeout: 258 seconds)
08:33	kjackal has joined IRC (kjackal!~quassel@oy6r0e.static.otenet.gr)
08:58	statler has left IRC (statler!~Georg@p5489790B.dip0.t-ipconnect.de, Remote host closed the connection)
09:14	woernie has left IRC (woernie!~werner@pD9E8B7B2.dip0.t-ipconnect.de, Ping timeout: 272 seconds)
09:14	woernie has joined IRC (woernie!~werner@pD9E8B7B2.dip0.t-ipconnect.de)
09:50	statler has joined IRC (statler!~Georg@gwrz.lohn24.de)
11:48	Faith has joined IRC (Faith!~Paty_@unaffiliated/faith)
12:05	kjackal has left IRC (kjackal!~quassel@oy6r0e.static.otenet.gr, Ping timeout: 272 seconds)
12:27	kjackal has joined IRC (kjackal!~quassel@2a02:587:3119:ef00:d972:2fda:fe23:da3e)
14:41	statler has left IRC (statler!~Georg@gwrz.lohn24.de, Remote host closed the connection)
16:31	<uumas> Is it possible to disable some apps from some clients, but still have them on others (maybe in lts.conf)?
16:32	vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
16:35	<\|\|cw> uumas: only via normal linux means. if you can find a script for it, you can add that to run in lts.conf, but probably you just want to edit the user menus, or create group based exec permissions or something
16:37	<uumas> Ok, I guess I'll make a script that just moves some .desktop files to /usr/share/applications/ from some dir like /usr/share/disabled-apps. That would work right?
16:40	<mwalters> ghttps://askubuntu.com/questions/8149/how-can-i-restrict-program-access-to-other-users
16:40	https://askubuntu.com/questions/8149/how-can-i-restrict-program-access-to-other-users
16:40	this is a blacklisting approach, but probably the best way to handle it
16:41	the idea is the restrict "anyone" access to none, then use the group exec permission to allow certain group to execute
16:41	<uumas> Yeah, that's a good way. Thanks!
16:42	<mwalters> for clarity, if you use fatclients/chroot, you need to modify the permissions in the chroot
16:42	for thinclients or chrootless, then just on the server
16:42	server root*
16:47	<vagrantc> and you'll need to update the permissions every time you do a package upgrade...
16:48	<mwalters> reply to the answer says that you shouldn't
16:48	I'm not certain either way
16:49	<vagrantc> well, if a package installs a new file, i don't see how your old permissions would magically migrate, for example
16:50	unless it's using dpkg hooks
16:50	<mwalters> I have no idea
16:52	<vagrantc> the suggestion to use apparmor would be considerably less hacky
16:52	<\|\|cw> wtf nbd... "Error: Negotiation failed: Success"
16:53	<mwalters> lololol
16:53	<vagrantc> yeah, i've seen that before, can't remember when
16:53	<mwalters> reminds me of my developer days dealing with vendor APIs
16:53	HTTP 200, body: { status: "failed" }
16:53	<\|\|cw> so what's the "right" way to tell a client which server to connect to?
16:53	I'm using nbdroot=10.212.0.85:10809
16:54	<vagrantc> so it successfully tried to fail to negotiate
16:54	<mwalters> or did it successfully fail to negotiate
16:54	<vagrantc> well, since it was an error...
16:54	<\|\|cw> do I need more info on that append param?
16:55	<vagrantc> i don't think you need to specify the port
16:55	<\|\|cw> maybe nbdroot=10.212.0.85:10809/opt/ltsp/images/i386.img ?
16:55	<vagrantc> nbdroot=ip:/image/name/space/foo.img
16:55	<\|\|cw> it fails to connect at all if I don't specify the port, errors with soemthing about missing port
16:56	<vagrantc> do you have multiple clients booting to different servers?
16:56	normally, you'd just pass next-server via dhcp
16:56	<\|\|cw> yes
16:56	<vagrantc> and leave the ip address out
16:56	it's been a while since i messed with this, though
16:57	<\|\|cw> AD is my main dhcp server, I have one ltsp with proxydhcp, and that one doles clients out to other server. for my old 10.04 server just the ip:port works
16:57	<vagrantc> yes, that's a very old server
16:57	the nbd protocol entirely changed since then
16:58	<\|\|cw> so I should be able to do ip/path/img ?
16:59	<vagrantc> strictly speaking, it's not a path, it's actually a nbd configuration name
17:00	we just configured it to look like a path in ltsp so that you can use the same value for nfs
17:00	<\|\|cw> well, ip/path I get nbd_server[4379]: Negotiation failed: Success
17:00	<vagrantc> do you have it configured in /etc/nbd/conf.d/.conf ?
17:00	<\|\|cw> so i should just put /opt/ltsp/i386 since that's the name in /etc/nbd-server/conf.d/ltsp_i386.conf ?
17:01	<vagrantc> yes
17:01	<\|\|cw> also, update-kernels isn't honoring IPAPPEND
17:01	<vagrantc> alternately, you should be able to set root-path in dhcp
17:02	update-kernels, or ltsp-update-kernels?
17:02	<\|\|cw> ltsp-update-kernels
17:02	<vagrantc> ltsp-update-kernels just copies what was already generated
17:02	this is in a chroot?
17:02	<\|\|cw> no
17:03	<vagrantc> sudo /usr/share/ltsp/update-kernels && sudo ltsp-update-kernels ... if i'mrememberingcorrectly
17:03	oh... i made a mess of that years ago.
17:03	<uumas> I don't know if this helps in any way but this is how I have configured dhcp for multiple ltsp servers: https://pastebin.com/79anD2MU
17:03	<vagrantc> there are so many ways this can go wrong
17:04	<\|\|cw> heh
17:04	the nore in the default file says to edit in the conf, so i do. it overwrites and still uses 3 when i want 2
17:04	nbdroot=10.212.0.85/opt/ltsp/i386 also says Error: Negotiation failed: Success
17:05	root=/dev/nbd0 should remain, right?
17:06	<vagrantc> you still would need a colon
17:06	nbdroot=ip:name
17:06	ltsp-update-kernels is probably pulling it from the image
17:07	sudo /usr/share/ltsp/update-kernels && sudo ltsp-update-image --cleanup / && sudo ltsp-update-kernels
17:07	maybe that will work...
17:07	<\|\|cw> well that looks different...
17:08	<vagrantc> alkisg and i worked out a bad compromise for this years ago, and it would have probably gone better to just use alkisg's suggestion in the first place rather than mixing the two methods
17:09	<\|\|cw> hm, I seem to have nbd now, but it's stopped at just "Negotiation:" then a crng and urandom dmesg type messages
17:09	<vagrantc> really, ltsp just needs some time and energy and sustained maintenance :/
17:10	<\|\|cw> so say we all
17:10	<vagrantc> it's been lacking a few years...
17:11	<\|\|cw> I was hoping to move some 16.04 to 18.04, is that worth it at this point? I don't actually need the newer software yet
17:13	<vagrantc> isn't 16.04 out of support come ... next month?
17:14	oh, no, it's got some more years left in it
17:15	<mwalters> it's 14.04 that goes out of support
17:16	<vagrantc> yeah, i was comparing the wrong part of the version :)
17:22	* alkisg waves
17:22	<alkisg> \|\|cw: in Greek schools, I tell them "I don't support 16.04 anymore, use either 12.04 or 18.04"
17:22	So 18.04 actually has had more testing
17:23	12.04 is for ancient clients that won't boot with 16.04 or 18.04...
17:24	<\|\|cw> maybe the issue I'm at now is that I'm running a client in qemu-kvm?
17:24	I guess I can grab a real system to test
17:24	<alkisg> uumas: INIT_COMMAND_RM_APPS="cd /usr/share/applications; rm -f app1.desktop app2.desktop etc"
17:25	(06:53:56 PM) \|\|cw: I'm using nbdroot=10.212.0.85:10809 ==> nbdroot=1.2.3.4:/opt/ltsp/amd64
17:25	<\|\|cw> yeah, I got past nbd. still isn't completing a boot
17:25	<alkisg> What's the message now?
17:25	The logs are too long to catch up :)
17:26	<\|\|cw> just stops at "Negotiation:" then a crng and urandom dmesg type messages
17:26	doens't say what's it's negotiating
17:26	<alkisg> Do you get an initramfs prompt?
17:26	<\|\|cw> no, just freezes there
17:26	<alkisg> Try: break=premount in pxelinux.cfg/default
17:26	You should get a shell, from where you could try:
17:26	!nbd-client
17:26	<ltsp> nbd-client: To try mounting the NBD image from the client initramfs: nbd-client 192.168.67.1 -N /opt/ltsp/i386 /dev/nbd0
17:27	<alkisg> And, you could also `cat /proc/cmdline` and paste it here, to verify that everything is in order
17:27	<\|\|cw> ffs it booted this time lol
17:27	<alkisg> Hehe
17:27	This is 16.04?
17:28	<\|\|cw> 18.04
17:28	now I have squashfs errors
17:28	<alkisg> And that's a kvm client running on the ltsp server?
17:29	<\|\|cw> on another host
17:29	<alkisg> Is the nbd server from 18.04 as well?
17:29	<\|\|cw> e1000 nic, qxl video
17:29	yes
17:30	<alkisg> Are you using nbdroot= ?
17:30	<\|\|cw> nbd server is on the ltsp host, all 18.04. client is a kvm guest on my 18.04 workstation
17:30	<alkisg> So no nbdroot there, right?
17:30	<\|\|cw> I'm using ndbroot, yes, because the PXE server is on another system
17:30	<alkisg> OK
17:31	<\|\|cw> so whatever the default behaviour is, it connects to the wrong place
17:31	<alkisg> Are you using both IPAPPEND 3 and nbdroot=?
17:31	<\|\|cw> IPAPPEND 2
17:31	<alkisg> GReat
17:31	Do you have a shell on the client now?
17:31	E.g. cat /proc/cmdline \| nc termbin.com 9999
17:31	...would help
17:31	<\|\|cw> no
17:32	rebooting it, lets see what i can get
17:32	<alkisg> The nbd errors you say
17:32	are they from nbd9?
17:33	<uumas> alkisg: so that goes in lts.conf?
17:33	<\|\|cw> gets ot "stared daily cleanup..." then block nbd0: connection timeout
17:34	<alkisg> uumas: right
17:34	\|\|cw: sounds like networking issues, but I can't imagine why
17:34	<\|\|cw> on server I have nbd_server[1172]: Starting to serve, but nothing after
17:34	virtio nic should work too, right?
17:35	<uumas> I also get squashfs errors when trying to use a kvm client, but physical computers work, do didn't bother to debug it
17:35	<alkisg> I don't get issues with virtualbox clients
17:35	...with or without virto
17:40	<\|\|cw> it works connecting to my 16.04 server
17:41	it's just getting to a random point and stops for a while, then nbd timeout.
17:42	tried rtl nic too, same thing
17:42	gotta get lunch and setup some real hardware :/
17:42	<alkisg> You mean the 18.04 connecting to the 16.04 server?
17:42	Or the 16.04 image connecting to the 16.04 server?
17:45	<uumas> I think they meant the kvm client connecting to 16.04
17:46	<alkisg> Yes, but booting from which image?
17:46	The 16.04 one, or the 18.04, and then using nbdroot to connect to 16.04...
17:48	<uumas> Ah, I'd assume 16.04. I had this exact same problem. Old 18.04 server with 16.04 chroot (Yes, I know. That's why I made a new one!) works, but new 18.04 one fails on kvm client
17:48	vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 252 seconds)
17:49	<alkisg> That sounds like an issue with kvm in 18.04 then...
17:49	(or the virtio drivers, etc etc)
17:50	<uumas> Yeah, could be many things. Not worth debugging at least for me
17:53	<mwalters> I have 4 servers on 18.04, and kvm client works on all of them
18:06	<\|\|cw> yes, kvm client to 16.04 server/image
18:08	mwalters: booting 32bit or 64?
18:08	statler has joined IRC (statler!~Georg@p5489790B.dip0.t-ipconnect.de)
18:12	<\|\|cw> nope, doing the same thing on a laptop
18:13	gonna try rebiulding the image
18:24	lol now ipaddend is working but CMDLINE_NBD= didn't
18:42	nope. still errors. i5 laptop, atom/ndidia-ion nettop, kvm on desktop, kvm on same server the ltsp server is on, all get nbd timeouts
18:49	<mwalters> \|\|cw: all 64bit
18:51	<\|\|cw> i'm all 32, still trying to support some older thin clients. maybe that's my whole issue?
18:51	<mwalters> not sure, sorry!
18:54	<alkisg> \|\|cw: 32bit works fine here
18:54	<\|\|cw> in vbox tho, right?
18:54	<alkisg> Are you saying that nbd has issues even on read hardware?
18:54	In vbox and in hundreds of schools
18:54	with read servers/clients
18:55	I boot a couple of different clients per day in my office as well, for testing purposes, that schools send
18:55	No issues whatsoever
18:55	*real, not read
18:56	<\|\|cw> yes
18:56	<alkisg> Test nbd-client without booting from it
18:56	!nbd-client
18:56	<ltsp> nbd-client: To try mounting the NBD image from the client initramfs: nbd-client 192.168.67.1 -N /opt/ltsp/i386 /dev/nbd0
18:56	<alkisg> Just run that command after the client boots, with any means
18:56	Eg. initramfs, local disk, live cd...
18:57	Then hdparm -t /dev/nbd0, or dd if=/dev/nbd0 of=/dev/null bs=1M status=progress, things like that
18:57	If it's not stable, there's something very wrong, maybe with your server nic/drivers/nbd-server/other software?
18:58	and make sure that both nbd-client and nbd-server are the latest versions offered by 18.04
18:59	<\|\|cw> it's on a commercial vm cluster with 30 other VMs, including 3 other ltsp servers, that all work fine
19:00	<alkisg> Are you sure that the nic driver for 18.04 works fine with large load?
19:01	<\|\|cw> I have 18.04 VMs for a samba server for 80 clients and a email server for 50 clients, so yeah, seems fine
19:01	<alkisg> So what do you think is the problem?
19:01	<\|\|cw> no idea
19:02	<alkisg> Did you try that dd thing? Does it fail?
19:02	<\|\|cw> maybe I can get a tcpdump
19:03	Timing buffered disk reads: 226 MB in 3.01 seconds = 75.07 MB/sec
19:03	<alkisg> Try to minimize the test case that fails, before you start tcpdump
19:04	<\|\|cw> 1.5GB in 20 seconds
19:05	<alkisg> So it doesn't fail?
19:05	<\|\|cw> lol now my PC's cache has it, (1.5 GB, 1.4 GiB) copied, 0.182834 s, 8.4 GB/s
19:05	<alkisg> Are you using the greek schools ppa?
19:05	<\|\|cw> yes
19:05	<alkisg> Chroot or chrootless?
19:06	<\|\|cw> less
19:06	<alkisg> Hrm...
19:06	So dd works fine, i.e. nbd works fine, yet later on it fails?
19:06	I wonder if the network disconnects for some reason
19:07	E.g. without the greek schools ppa, network manager ifdown'ed the nic
19:07	...which then appeared as nbd issues, but it was no networking
19:08	When that happens, can you ping the client from the server?
19:11	<\|\|cw> that was an 64 client, let me try a x32
19:16	woernie has left IRC (woernie!~werner@pD9E8B7B2.dip0.t-ipconnect.de, Quit: No Ping reply in 180 seconds.)
19:16	<\|\|cw> dd worked on 32bit. ping from server does stop at the point it freezes
19:17	so it does seem to be a network issue
19:17	woernie has joined IRC (woernie!~werner@pD9E8B7B2.dip0.t-ipconnect.de)
19:18	<\|\|cw> same for the laptop
19:20	hm. I installed the server from the ubuntu-mate i386 iso that's linked from http://wiki.ltsp.org/wiki/Installation/Ubuntu
19:20	<alkisg> \|\|cw: did you install anything related to networking after the installation?
19:20	E.g. netplan, firewalls...
19:20	<\|\|cw> apt install vim aptitude bikeshed molly-guard pv iftop sysstat ethtool samba acl winbind libnss-winbind libpam-winbind ssmtp
19:21	config's samba for AD auth integrate to allow domain accounts to login
19:21	removed snapd
19:22	that's it.
19:22	I'm not opposed to a clean reinstall. I did manage to install when ubuntu was having keyserv issues so that was a struggle
19:23	<alkisg> INIT_COMMAND_RM_IFDOWN="rm -f /sbin/ifdown"
19:23	Does that work around the issue?
19:23	(in lts.conf)
19:23	<\|\|cw> in lts.conf?
19:24	anywhere in [default] right?
19:25	<alkisg> yup
19:25	<\|\|cw> no change
19:26	<alkisg> Try this in pxelinux.cfg/default: ltsp.break=50-fstab
19:26	This should give you a shell when the client has booted
19:26	There, type: cat /etc/network/interfaces \| nc termbin.com 9999
19:26	<\|\|cw> under ipappend?
19:27	or in the append line?
19:27	<alkisg> there
19:27	In the append line
19:29	<\|\|cw> just lo
19:30	but it should be using network manager, right? or should I disable that?
19:30	<alkisg> Sorry that was too soon
19:30	ltsp.break=50-swap
19:30	reboot, check again
19:31	<\|\|cw> ens3 is set got manual
19:32	that seems wrong?
19:32	<alkisg> It's correct
19:32	<\|\|cw> shouldn't it either not be there or be dhcp?
19:32	<alkisg> It prohibits network manager from breaking it
19:32	can you pastebin the results though?
19:33	E.g. I want to see if there are other nics or other things that could break it
19:33	<\|\|cw> no, this system doens't have internet permission
19:33	just lo and that one
19:33	<alkisg> ip a
19:33	this just shows one nic?
19:33	<\|\|cw> and lo, yes
19:33	the laptop would have a wifi card too probably
19:34	<alkisg> Eh, anyway go for a clean reinstall
19:34	Then try before you add more programs
19:34	If it works, and breaks after you install the additional software, it's something there that ifdowns the nic
19:34	<\|\|cw> yeah, that's my new plan. make it work clean
19:35	<alkisg> Or if you ever get internet access, i could have a look with vnc
19:35	(try the reinstall first, to save time :))
19:35	<\|\|cw> heh, it never gets that far
20:14	well, that booted. now to see what made it fail.
20:49	got it all config'd back where I was 2 hours ago and it's all working fine. must have had something to do with the initial install issues I had
20:49	woernie has left IRC (woernie!~werner@pD9E8B7B2.dip0.t-ipconnect.de, Remote host closed the connection)
20:49	<\|\|cw> I'm even able to login to a client as a domain user :)
20:57	Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving)
21:03	<\|\|cw> is there no longer a xfreerdp screen.d?
21:04	do i need to copy it from /usr/share/ltsp/screen.d to /usr/lib/ltsp/screen.d ?
21:16	!sudo
21:16	<ltsp> I do not know about 'sudo', but I do know about these similar topics: 'sudoers', 'fat-sudo'
21:16	<\|\|cw> !fat-sudo
21:16	<ltsp> fat-sudo: to allow members of the sudo group to execute "sudo" in fat clients without a password prompt, put this in lts.conf: RCFILE_01="echo '%sudo ALL=NOPASSWD: ALL' >> /etc/sudoers"
21:21	<\|\|cw> I take that back, xinit is running, xfreerdp is not
21:23	oh gdi, it's defaulting the servername
21:35	kjackal has left IRC (kjackal!~quassel@2a02:587:3119:ef00:d972:2fda:fe23:da3e, Ping timeout: 252 seconds)
22:02	statler has left IRC (statler!~Georg@p5489790B.dip0.t-ipconnect.de, Remote host closed the connection)
23:03	ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Remote host closed the connection)