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


Channel log from 12 May 2019   (all times are UTC)

01:21mmarconm has joined IRC (mmarconm!~mmarconm@unaffiliated/mmarconm)
01:22alexxtasi[m] has left IRC (alexxtasi[m]!alexxtasim@gateway/shell/matrix.org/x-gvzbncigsssrtqlm, Ping timeout: 250 seconds)
01:23Guest72033 has left IRC (Guest72033!enautmatri@gateway/shell/matrix.org/x-odwkiyksxwfhgola, Ping timeout: 276 seconds)
01:48gdi2k has left IRC (gdi2k!~gdi2k@58.69.160.28, *.net *.split)
01:48josefig has left IRC (josefig!~josefig@unaffiliated/josefig, *.net *.split)
02:13alexxtasi[m] has joined IRC (alexxtasi[m]!alexxtasim@gateway/shell/matrix.org/x-oxncmoopadhhinca)
02:19mmarconm has left IRC (mmarconm!~mmarconm@unaffiliated/mmarconm, Quit: Leaving)
02:23Guest72033 has joined IRC (Guest72033!enautmatri@gateway/shell/matrix.org/x-tplxpsnxlsvfkqdt)
02:27nehemiah has joined IRC (nehemiah!~nehemiah@156.19.21.242)
02:29
<nehemiah>
What would be the downside of using a physical device or say a ZFS volume instead of a squashfs image for LTSP?
02:30
Provided that I export it read-only, the only thing I can think of is compression?
02:30
<vagrantc>
any bugs are yours to fix? :)
02:31
ZFS even can support compression, no?
02:31
<nehemiah>
Yes, it does.
02:32
<vagrantc>
in the past i've also used ext* images ... but haven't tested in a long time
02:33
<nehemiah>
I do understand that when at any point two clients would have write access to the export, all hell will break loose. But as long as I export read-only. I don't see why that should matter.
02:35
<vagrantc>
it can be done, sure
02:35
<nehemiah>
But a ZFS zvol is a block device. It still needs a filesystem after that. So, providing I use that, I wonder who's if the data is send compressed to the client, saving bandwidth or the server is decompressing before send?
02:37
I guess that client isn't aware of the ZFS logic so can not be the end compressing/decompressing. Meaning that it would probably be better to use LVM with BTRFS and compression or a physical device.
02:44
<vagrantc>
what are you trying to solve with these other methods?
02:45gdi2k has joined IRC (gdi2k!~gdi2k@58.69.160.28)
02:45josefig has joined IRC (josefig!~josefig@unaffiliated/josefig)
02:48
<nehemiah>
vagrant: I guess it's more of a brainfart then that there are real issues. I think that SquashFS is excellent. I just wish sometimes that I would not have to build images.
02:51
<vagrantc>
been there.
02:53
<nehemiah>
Another thing is that I manage several location with LTSP. And I wish they all had the exact same image. So, I though that if I'd just be able to push updates using ZFS, then just a reboot would be enough to make those available.
02:55
Plus the ability to take snapshots...
04:39
<alkisg>
!btrfs
04:39
<ltsp>
I do not know about 'btrfs', but I do know about these similar topics: 'bts'
04:39
<alkisg>
!precise
04:39
<ltsp>
I do not know about 'precise', but I do know about these similar topics: 'precise-i386'
04:39
<alkisg>
!precise-i386
04:39
<ltsp>
precise-i386: Ubuntu 12.04 compressed btrfs chroot to boot really old clients (non-pae, >=64MB RAM): http://ts.sch.gr/repo/livecd/images. You can find the image, a screenshot and a README there.
04:39
<alkisg>
nehemiah: I've done what you're asking with a btrfs compressed image ^
04:39
The decompression happens on the client, so it saves bandwidth
04:39
And, I'm daily using ext4 to netboot various VMs with the ltsp code
04:40
I.e. I don't use ltsp-update-image at all; I just point my ltsp clients to the buster-gnome-flat.vmdk or to fedora30-flat.vmdk or to bionic-mate-64-flat.vmdk etc
04:45
vagrantc: I'm thinking of merging all the image handling commands to a single tool, e.g. `ltsp-image --squashfs` or `ltsp-image --chroot` or `ltsp-image --kernels`; it would make code organization better, e.g. ltsp-image-functions would only be sourced by these tools
04:46
Does that sound OK?
04:47
Maybe with a verb, like systemd, `ltsp-image export-squashfs`, `ltsp-image update-tftp`...
04:51kjackal has joined IRC (kjackal!~quassel@2a02:587:311c:9d00:70ee:5f34:4c95:b67b)
06:04kjackal has left IRC (kjackal!~quassel@2a02:587:311c:9d00:70ee:5f34:4c95:b67b, Ping timeout: 257 seconds)
06:22
<vagrantc>
alkisg: sounds ok to me
06:22
especially if we can write some decent tab-completion rules :)
06:23
<alkisg>
Haha, I'll leave that up to some contributor :D
06:23
<vagrantc>
gotta leave some low-hanging fruit
06:34
<quinox>
I've done some tab completion, not that hard
06:37
Salt-Stack implemented tab completion, but since they query things live from all connected minions it's extremely slow, hanging bash in the process
06:37
it's cool, but I wish they hadn't :D
06:49
(point of the story: it's easy)
07:56vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)
08:09ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)
08:12kjackal has joined IRC (kjackal!~quassel@2a02:587:311c:9d00:70ee:5f34:4c95:b67b)
10:21
<nehemiah>
alkisg: Yes, I came to the conclusion that I'll give lvm with btrfs a shot. I like the zstd compression in btrfs too.
10:22
<alkisg>
nehemiah: is this for production or for testing?
10:22
You can also do local caching, if you care too much about performance, and you happen to have a bit of local disk available
10:22
<nehemiah>
One more thing I'd like to try is to replace nbd with iscsi.
10:22
<alkisg>
I'd like that one too
10:22
I'm hearing it's much more stable
10:23
<nehemiah>
It is actually
10:23
<alkisg>
Does it support reconnections?
10:23
<nehemiah>
Yes, that's the most beautiful part
10:23
<alkisg>
nbd is supposed to support reconnections, but they seem to fail
10:24
And nowadays where there's no nbd-client, I'm not sure if the kernel thread does support reconnections
10:24
<nehemiah>
I've done iscsi booting, restarting a whole server and the client just continues after the server comes back up.
10:24
<alkisg>
Which tool did you use for that? initramfs-tools? dracut? own code?
10:25
<nehemiah>
But this was not LTSP some other project. It's just that nbd performs better but sooner or later it flunks out and you'll have to reboot your client.
10:25
initramfs-tools
10:26
<alkisg>
Great, I'll give it a go a few months later
10:26
I'd like to try squashfs over nfs too
10:26
It should be fast because it's compressed etc, but more stable than nbd, and more widely supported
10:27
<nehemiah>
The 'bad' part is that you have to make an initiator for every client and so you'll need a pxe boot file per mac.
10:27
<alkisg>
Ouch
10:27
Maybe we can work around that with ipxe scripts
10:27
But an initiator for every client... meh
10:30
<nehemiah>
squashfs over NFS sounds interesting too. I'd like to look into that. Anything to explore nbd alternatives really. It seems to me that nbd isn't ready for LTPS environments where stability is a hard requirement.
10:31
<alkisg>
There's also xnbd
10:32
It's nbd on steroids; with reconnections, caching, balancing etc
10:32
I haven't tried it though
10:32
Btw, if you test all these and find good solutions, I'm interested in integrating them upstream
10:32
...but I don't have much time for tests now, as I'm rewriting ltsp5 into ltsp19.08...
10:33
<nehemiah>
Alright, would this be the right channel to discus such things?
10:34
<alkisg>
Of course
10:34
<nehemiah>
Also have you looked in to ram compression?
10:34
<alkisg>
I did a lot of years ago; at the time it was actually wasting ram (instead of caching via nbd or whatever) and making clients unstable
10:34
<nehemiah>
I've looked into this for clients with less than 8GB of memory it does increase there stability.
10:35
<alkisg>
I don't know if things have improved now; I did hear a couple of users mentioning it made things better for them
10:54
<nehemiah>
Looking at the man page of xnbd, it look as if it's not much different from nbd. I'd consider giving it a shot if it would reconnect.
10:57
Perhaps I should give it a shot and see if it does :)
11:47kjackal has left IRC (kjackal!~quassel@2a02:587:311c:9d00:70ee:5f34:4c95:b67b, Ping timeout: 258 seconds)
13:23kjackal has joined IRC (kjackal!~quassel@2a02:587:311c:9d00:70ee:5f34:4c95:b67b)
13:30dptech06 has joined IRC (dptech06!52f2df27@gateway/web/freenode/ip.82.242.223.39)
13:32
<dptech06>
Hello, could you help me why i've black screen with mouse in start since thinclient ? thanks
14:33
<alkisg>
dptech06: did you have that issue before? when did it start?
14:33
does it happen in all clients? which distro/version?
14:39mmarconm has joined IRC (mmarconm!~mmarconm@191.217.39.181)
14:39mmarconm has joined IRC (mmarconm!~mmarconm@unaffiliated/mmarconm)
15:16dptech06 has left IRC (dptech06!52f2df27@gateway/web/freenode/ip.82.242.223.39, Ping timeout: 256 seconds)
16:12mmarconm has left IRC (mmarconm!~mmarconm@unaffiliated/mmarconm, Quit: Leaving)
17:16adrianor1 has joined IRC (adrianor1!~adrianorg@187.58.141.22)
17:19adrianorg has left IRC (adrianorg!~adrianorg@177.18.183.77, Ping timeout: 252 seconds)
18:10nehemiah has left IRC (nehemiah!~nehemiah@156.19.21.242, Remote host closed the connection)
18:10nehemiah has joined IRC (nehemiah!~nehemiah@156.19.21.242)
20:22ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Remote host closed the connection)
21:05vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)