|01:21||mmarconm has joined IRC (mmarconm!~mmarconm@unaffiliated/mmarconm)|
|01:22||alexxtasi[m] has left IRC (alexxtasi[m]!alexxtasim@gateway/shell/matrix.org/x-gvzbncigsssrtqlm, Ping timeout: 250 seconds)|
|01:23||Guest72033 has left IRC (Guest72033!enautmatri@gateway/shell/matrix.org/x-odwkiyksxwfhgola, Ping timeout: 276 seconds)|
|01:48||gdi2k has left IRC (firstname.lastname@example.org, *.net *.split)|
|01:48||josefig has left IRC (josefig!~josefig@unaffiliated/josefig, *.net *.split)|
|02:13||alexxtasi[m] has joined IRC (alexxtasi[m]!alexxtasim@gateway/shell/matrix.org/x-oxncmoopadhhinca)|
|02:19||mmarconm has left IRC (mmarconm!~mmarconm@unaffiliated/mmarconm, Quit: Leaving)|
|02:23||Guest72033 has joined IRC (Guest72033!enautmatri@gateway/shell/matrix.org/x-tplxpsnxlsvfkqdt)|
|02:27||nehemiah has joined IRC (email@example.com)|
What would be the downside of using a physical device or say a ZFS volume instead of a squashfs image for LTSP?
Provided that I export it read-only, the only thing I can think of is compression?
any bugs are yours to fix? :)
ZFS even can support compression, no?
Yes, it does.
in the past i've also used ext* images ... but haven't tested in a long time
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.
it can be done, sure
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?
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.
what are you trying to solve with these other methods?
|02:45||gdi2k has joined IRC (firstname.lastname@example.org)|
|02:45||josefig has joined IRC (josefig!~josefig@unaffiliated/josefig)|
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.
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.
Plus the ability to take snapshots...
I do not know about 'btrfs', but I do know about these similar topics: 'bts'
I do not know about 'precise', but I do know about these similar topics: 'precise-i386'
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.
nehemiah: I've done what you're asking with a btrfs compressed image ^
The decompression happens on the client, so it saves bandwidth
And, I'm daily using ext4 to netboot various VMs with the ltsp code
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
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
Does that sound OK?
Maybe with a verb, like systemd, `ltsp-image export-squashfs`, `ltsp-image update-tftp`...
|04:51||kjackal has joined IRC (kjackal!~quassel@2a02:587:311c:9d00:70ee:5f34:4c95:b67b)|
|06:04||kjackal has left IRC (kjackal!~quassel@2a02:587:311c:9d00:70ee:5f34:4c95:b67b, Ping timeout: 257 seconds)|
alkisg: sounds ok to me
especially if we can write some decent tab-completion rules :)
Haha, I'll leave that up to some contributor :D
gotta leave some low-hanging fruit
I've done some tab completion, not that hard
Salt-Stack implemented tab completion, but since they query things live from all connected minions it's extremely slow, hanging bash in the process
it's cool, but I wish they hadn't :D
(point of the story: it's easy)
|07:56||vagrantc has left IRC (vagrantc!~vagrant@unaffiliated/vagrantc, Quit: leaving)|
|08:09||ricotz has joined IRC (ricotz!~ricotz@ubuntu/member/ricotz)|
|08:12||kjackal has joined IRC (kjackal!~quassel@2a02:587:311c:9d00:70ee:5f34:4c95:b67b)|
alkisg: Yes, I came to the conclusion that I'll give lvm with btrfs a shot. I like the zstd compression in btrfs too.
nehemiah: is this for production or for testing?
You can also do local caching, if you care too much about performance, and you happen to have a bit of local disk available
One more thing I'd like to try is to replace nbd with iscsi.
I'd like that one too
I'm hearing it's much more stable
It is actually
Does it support reconnections?
Yes, that's the most beautiful part
nbd is supposed to support reconnections, but they seem to fail
And nowadays where there's no nbd-client, I'm not sure if the kernel thread does support reconnections
I've done iscsi booting, restarting a whole server and the client just continues after the server comes back up.
Which tool did you use for that? initramfs-tools? dracut? own code?
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.
Great, I'll give it a go a few months later
I'd like to try squashfs over nfs too
It should be fast because it's compressed etc, but more stable than nbd, and more widely supported
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.
Maybe we can work around that with ipxe scripts
But an initiator for every client... meh
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.
There's also xnbd
It's nbd on steroids; with reconnections, caching, balancing etc
I haven't tried it though
Btw, if you test all these and find good solutions, I'm interested in integrating them upstream
...but I don't have much time for tests now, as I'm rewriting ltsp5 into ltsp19.08...
Alright, would this be the right channel to discus such things?
Also have you looked in to ram compression?
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
I've looked into this for clients with less than 8GB of memory it does increase there stability.
I don't know if things have improved now; I did hear a couple of users mentioning it made things better for them
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.
Perhaps I should give it a shot and see if it does :)
|11:47||kjackal has left IRC (kjackal!~quassel@2a02:587:311c:9d00:70ee:5f34:4c95:b67b, Ping timeout: 258 seconds)|
|13:23||kjackal has joined IRC (kjackal!~quassel@2a02:587:311c:9d00:70ee:5f34:4c95:b67b)|
|13:30||dptech06 has joined IRC (dptech06!52f2df27@gateway/web/freenode/ip.22.214.171.124)|
Hello, could you help me why i've black screen with mouse in start since thinclient ? thanks
dptech06: did you have that issue before? when did it start?
does it happen in all clients? which distro/version?
|14:39||mmarconm has joined IRC (email@example.com)|
|14:39||mmarconm has joined IRC (mmarconm!~mmarconm@unaffiliated/mmarconm)|
|15:16||dptech06 has left IRC (dptech06!52f2df27@gateway/web/freenode/ip.126.96.36.199, Ping timeout: 256 seconds)|
|16:12||mmarconm has left IRC (mmarconm!~mmarconm@unaffiliated/mmarconm, Quit: Leaving)|
|17:16||adrianor1 has joined IRC (firstname.lastname@example.org)|
|17:19||adrianorg has left IRC (email@example.com, Ping timeout: 252 seconds)|
|18:10||nehemiah has left IRC (firstname.lastname@example.org, Remote host closed the connection)|
|18:10||nehemiah has joined IRC (email@example.com)|
|20:22||ricotz has left IRC (ricotz!~ricotz@ubuntu/member/ricotz, Remote host closed the connection)|
|21:05||vagrantc has joined IRC (vagrantc!~vagrant@unaffiliated/vagrantc)|