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

Request log from specific day:

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

00:54	<mwalters> no idea, that's just the "defacto" link from here
00:55	like I said, I use the brix ones and some old custom built things with asus mini-itx boards
03:03	vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Ping timeout: 252 seconds)
03:35	jgee has left IRC (jgee!~jgee@190.159.118.121, Ping timeout: 272 seconds)
04:14	jgee has joined IRC (jgee!~jgee@190.159.118.121)
07:55	nehemiah has joined IRC (nehemiah!~nehemiah@185.64.41.125)
08:14	ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
08:35	kjackal has joined IRC (kjackal!~quassel@2a02:587:3101:f300:11c8:94ba:36fa:6264)
09:06	<Hyperbyte> highvoltage, you scared me a little. ;-) I should be going to FOSDEM as well, but not next weekend. ;-)
09:07	<highvoltage> admittedly I do like to scare people a little
09:10	<Hyperbyte> Hehe
12:11	kjackal has left IRC (kjackal!~quassel@2a02:587:3101:f300:11c8:94ba:36fa:6264, Ping timeout: 252 seconds)
12:19	kjackal has joined IRC (kjackal!~quassel@2a02:587:3101:f300:11c8:94ba:36fa:6264)
12:33	mads2 has joined IRC (mads2!~ltsp@2804:14c:878d:9e87:708b:3c52:a554:432d)
12:44	<mads2> I just did a fresh `ltsp-build-client`, chrooted it and did `apt install openssh-server && systemctl enable ssh` but when I log in the client it doesn`t work.
12:44	And I noticed that if I remove LDM and reinstall the sshd it works but I lose the lts.conf configs. Can I start sshd on the clients without losing the LDM functionalities?
12:57	Faith has joined IRC (Faith!~Paty_@unaffiliated/faith)
13:23	<mads2> It looks like I was missing "KEEP_SYSTEM_SERVICES=ssh" on lts.conf.
14:28	spaced0ut has joined IRC (spaced0ut!~spaced0ut@unaffiliated/spaced0ut)
14:40	<\|\|cw> mads2: you have to build the images again after changing the chroot.
15:30	josefig has joined IRC (josefig!~jose@unaffiliated/josefig)
15:31	<josefig> hello gm everybody, have you tested LTSP over the WAN ?
15:33	<alkisg> josefig: yup
15:34	<josefig> alkisg: and how was your experience?
15:34	<alkisg> Are you interested in thin or ltsp fat clients?
15:34	<josefig> fat clients, i have a development group in different location and would be awesome if we can do that
15:35	<alkisg> !local-boot
15:35	<ltsp> local-boot: If you want LTSP fat clients on a low-speed network, you can put i386.img on e.g. C:\Boot\LTSP\i386.img and use this command line in pxelinux.cfg: APPEND ro initrd=ltsp/i386/initrd.img init=/sbin/init-ltsp root=/dev/sda1 rootflags=ro loop=/Boot/LTSP/i386.img; IPAPPEND 3
15:35	<alkisg> Doing this ^ you then only dynamically share /home over ssh, and you minimize network bandwidth over wan
15:36	And you make things easier as you don't need specially configured dhcp servers on the remote locations
15:37	Of course it also works completely diskless, you just need a dhcp server remotely and a bit better wan
15:37	What is your upload WAN speed?
15:37	<josefig> but one question, does the i386.img should be on LAN location ?
15:37	<alkisg> It's faster if you put it remotely, a bit slower if you leave it locally
15:38	(faster if it is copied on the client before it boots)
15:40	<fiesh> since an update (I believe it's the kernel update, but could also be something else), the fat clients seem to disrespect the umask. the server and the clients have a umask of 022, a `touch ~/test` on the server results in 644, but on the clients it results in 666
15:40	(nfs mounted home)
15:40	anyone had this before?
15:40	<alkisg> NFS is great, but just because it's not the default, I haven't used it in a long time, sorry, no idea
15:41	<fiesh> ok, thanks
15:43	<josefig> alkisg: i was thinking using something like boot iso over image PXE boot something like http://ipxe.org/ just to do the dhcp over the WAN
15:43	<alkisg> Yup, that works
15:43	(05:37:19 μμ) alkisg: What is your upload WAN speed?
15:44	<josefig> alkisg: but what if I include the image in that linux ? that should be faster
15:44	<alkisg> (05:37:19 μμ) alkisg: What is your upload WAN speed?
15:44	<josefig> my upload WAN speed is 10mbps
15:44	<alkisg> Is that download or upload?
15:44	<josefig> 10mbps, dedicated link
15:44	<alkisg> And how many users are going to be downloading the image simultaneously?
15:45	<josefig> around 5 not many to be honest with you
15:45	<alkisg> That means 2 mbps per client, which is 0.2 MB/sec
15:45	For libreoffice to open, 120 MB are needed
15:45	120 MB / 0.2 MB => 600 secs to open libreoffice
15:46	That is, 10 minutes
15:46	Is that OK for you? :)
15:46	<josefig> on fat clients?
15:46	<alkisg> Yes
15:46	<josefig> no, that's too much
15:46	:(
15:46	<alkisg> Because of the very slow link :)
15:46	If you have the whole image locally, then it will load in 10 seconds
15:46	And there's also x2go
15:46	!x2go
15:46	<ltsp> x2go: x2go is an NX-based suite of applications that allow logging in to a remote X server from any OS. It's much more efficient than VNC over slow network. More info: http://www.x2go.org/
15:47	<alkisg> And xrdp
15:47	<josefig> give me 5 min, i have a call
15:47	<alkisg> Which is only remote desktop
15:47	I need to leave now, bbl
15:48	<\|\|cw> you can have x2go side by side on an ltsp server so thin and remote get the same desktop view
15:49	with chroot-less fat would also get the same view
15:51	if you can have a small server at the remote you could set it up as an ltsp fat client server, but direct homes over the wan. you could even biuld the base on an raspberrypi and copy over the images and pxe files from the real server, so the pi serves the x86 images
15:51	though then you're limited to usb2 speeds, which is better than your WAn speed, but still not great
15:59	<fiesh> fiesh@ltsp117 ~ % umask
15:59	022
15:59	fiesh@ltsp117 ~ % touch t
15:59	fiesh@ltsp117 ~ % ls -l t
15:59	-rw-rw-rw- 1 fiesh fiesh 0 Jan 21 16:59 t
15:59	wtf... how is that even possible
16:01	https://bugs.launchpad.net/ubuntu/+source/nfs-utils/+bug/1779736
16:01	<josefig> i'm back
16:01	alkisg: ok, i'll be around all day.
16:02	\|\|cw: I see, let me read about x2go.
16:02	<fiesh> zfs set acltype=posixacl indeed functions as a workaround, hurray
16:22	mads2 has left IRC (mads2!~ltsp@2804:14c:878d:9e87:708b:3c52:a554:432d, Remote host closed the connection)
16:32	<\|\|cw> fiesh: ah yes, zfs and nfs get weird, posixacl is needed
16:33	you might also want xattr=sa
16:36	and if you ever make smaba share on zfs, turn off samba's store dos attributes and maps
16:36	<fiesh> \|\|cw: ah we do have samba on zfs, what does that do?
16:37	<\|\|cw> big performance boost. zfs stores them in a slow way. you don't need them unless you actually have DOS clients that use them
16:38	and if you do have those, well, $diety help you
16:38	<fiesh> \|\|cw: also thanks for pointing out the xattr=sa, wasn't aware of it
16:39	<\|\|cw> I'm using samba on zfs for my primary file server on a windows domain, battled the hell out of it
16:39	<fiesh> heh we only have like two Windows users, so I never really noticed it sucked, if it did, not sure ;)
16:39	<\|\|cw> actually on my 2nd revision of it, first still ha bottleneck because i laid out my pool wrong
16:40	<fiesh> you forgot to set the block size? ;)
16:40	OK set the samba settings too, thanks for letting me know
16:41	<\|\|cw> na, it's in a VM that's raid backed and I had one vdisk
16:41	<fiesh> ah yeah raid backed doesn't really make sense if you can opt for a raid-z instead I guess
16:41	<\|\|cw> now I have I bunch of 500GB vdsisks
16:42	mostly using it for compression for certain shares, snapshots and for zrep
16:42	<fiesh> it's really a shame linux still has no decent filesystem apart from zfs whose integration is just so-so I feel
16:43	like I am dead-afraid of upgrading our zroot lest grub cannot handle the zfs features and won't boot any more
16:43	and its support of zfs features is, as far as I can tell, not documented
16:43	<\|\|cw> the dos attribs I really only felt on large folders, but one of our more active folder has 16,000 items. I wish i could talk them into reorganizing that one
16:44	<fiesh> and then btrfs sucks, so you're still stuck with ext4 on vanilla server installations :(
16:47	nehemiah has left IRC (nehemiah!~nehemiah@185.64.41.125, Remote host closed the connection)
17:10	<alkisg> I was wondering if it would be ever possible to do this: ltsp-update-image would create a snapshot of the server /, it would cleanup all passwords etc in that snapshot, and then export the whole / snapshot to the users. I.e. immediate ltsp-update-image, instead of using mksquashfs.
17:10	Can btrfs/zfs snapshots work that way?
17:15	kjackal has left IRC (kjackal!~quassel@2a02:587:3101:f300:11c8:94ba:36fa:6264, Ping timeout: 252 seconds)
17:36	<\|\|cw> snapshots are read only
17:37	you can make a clone of a snap, but I've not tried that on linux
17:38	https://linoxide.com/ubuntu-how-to/using-zfs-filesystem-clone-snapshot/
17:39	so yeah, that could work
17:39	snap, clone, edit, snap again to make it read only, export that.
17:40	then you can update the root, snap again, clone again, etc. when the first one is no longer used you can delete all its snaps and clones
17:42	mksquashfs advantage is that it's compressed on the network, right? the client extracts?
17:49	<alkisg> Right, but don't btrfs/zfs also support compression? OK, it would be e.g. 40% compression instead of 50%, but still it should be good enough...
17:50	And, if we ever support local caching in the future, the server-side compression won't matter that much
17:51	(e.g. if we ever cache to small local ssd devices, maybe super fast ssd-based usb3 sticks, to take advantage of that 500MB/sec transfer rates per client, compared to the 100MB/sec per server, of a gigabit network ....)
18:09	kjackal has joined IRC (kjackal!~quassel@2a02:587:3101:f300:11c8:94ba:36fa:6264)
18:17	<\|\|cw> the compression is server side though, it would be uncompressed on the wire
18:29	<alkisg> No, nbd exports /
18:29	The whole block device
18:36	I mean, in this scenario, nbd would export e.g. the whole /dev/sda, and the client would only mount the readonly snapshot, so it wouldn't be affected by changes on the server "main" file system, and the decompression would happen on the client since nbd would get the whole block device
18:37	Now ideally, nbd-server could be configured to only return the "sectors" that are indeed part of that readonly snapshot, so that the client wouldn't ever be able to read sensitive data, outside of the clean'ed up phase; but that's just wishful thinking, something for a phd maybe :D
19:09	<\|\|cw> that's not going work with zfs snaps
19:09	hm.
19:09	thing is, it mount the snap, you have to first mount, or at least define, the root
19:09	vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)
19:11	<\|\|cw> I also don't think zfs would allow booting off a snap. they are hidden in userspace by default anyway
19:29	nikoh77 has joined IRC (nikoh77!~nikoh77@host88-180-dynamic.53-79-r.retail.telecomitalia.it)
19:30	<alkisg> nbd mounts the whole root
19:31	snapshots are mounted from the initramfs later on
19:31	At least that's what i saw in the btrfs initramfs mount script...
19:34	Faith has left IRC (Faith!~Paty_@unaffiliated/faith, Quit: Leaving)
19:38	<\|\|cw> interesting.
20:40	<alkisg> !kvm
20:40	<ltsp> kvm: Virtual thin client: kvm -m 256 -vga vmware -ctrl-grab -no-shutdown -net nic,model=virtio -net user,tftp=/var/lib/tftpboot,bootfile=/ltsp/i386/pxelinux.0
21:03	nikoh77 has left IRC (nikoh77!~nikoh77@host88-180-dynamic.53-79-r.retail.telecomitalia.it, Ping timeout: 268 seconds)
21:21	nikoh77 has joined IRC (nikoh77!~nikoh77@host88-180-dynamic.53-79-r.retail.telecomitalia.it)
21:23	kjackal has left IRC (kjackal!~quassel@2a02:587:3101:f300:11c8:94ba:36fa:6264, Ping timeout: 268 seconds)
21:36	mwalters has left IRC (mwalters!~ubox@c-73-152-61-86.hsd1.va.comcast.net, Ping timeout: 268 seconds)
21:38	mwalters has joined IRC (mwalters!~ubox@c-73-152-61-86.hsd1.va.comcast.net)
22:10	nikoh77 has left IRC (nikoh77!~nikoh77@host88-180-dynamic.53-79-r.retail.telecomitalia.it, Ping timeout: 246 seconds)
22:14	ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Remote host closed the connection)
22:30	gdi2k has left IRC (gdi2k!~gdi2k@host86-185-232-114.range86-185.btcentralplus.com, Quit: Leaving)