[07:57] <vmlintu_> alkisg: we've just been thinking of ways of cloning the nbd image to the local disk
[07:57] <vmlintu_> alkisg: did you plan on installing the fat client chroot on the local disk and running from there?
[07:58] <alkisg> vmlintu_: I want to support that as a possible scenario for slow local networks, yes
[07:58] <alkisg> It involves 2 steps, as I thought it:
[07:59] <alkisg> 1) Boot all the clients as ltsp clients. It'll be slow as the network is slow.
[07:59] <alkisg> Run a "copy nbd image locally" script
[07:59] <alkisg> Since that's a fat chroot, it can also contain gparted etc
[07:59] <alkisg> I think here we'll do that part from epoptes, as it allows launching programs as root on the clients
[08:00] <vmlintu_> have you done any tests on that yet?
[08:00] <alkisg> 2) On boot, mount the nbd image and compare to the local version
[08:00] <alkisg> If the remote image is newer, run rsync to sync it locally
[08:00] <alkisg> So every time the sysadmin runs `ltsp-update-image`, the next boot will be a bit slower
[08:00] <alkisg> Depending on the changes, it might need a couple of minutes to complete the boot process
[08:01] <alkisg> That's all, it should allow for very slow networks to use LTSP
[08:01] <vmlintu_> your plan sounds quite similar to what I had in mind
[08:01] <alkisg> No, I haven't implemented anything about that part yet
[08:01] <alkisg> I don't know when I'll have time for it
[08:02] <vmlintu_> have you thought about the kernel updating part?
[08:03] <vmlintu_> or would you always boot and load the kernel from the network?
[08:03] <alkisg> That's on the (2) part as well
[08:03] <alkisg> The newer kernel is available in the nbd image, one can copy it over its local /boot as well
[08:04] <alkisg> (11:03:16 πμ) vmlintu_: or would you always boot and load the kernel from the network? => that's a possible variation, yes, and it has an additional advantage:
[08:04] <alkisg> one can just have a "sync-image-locally" kernel parameter,
[08:05] <alkisg> and when that's in effect, it would copy the nbd image to the first hd partition, whatever that is,
[08:05] <alkisg> so e.g. if it's a windows partition, it would sync the nbd image to C:\ltsp.nbd
[08:05] <vmlintu_> that'd be interesting
[08:06] <alkisg> The good side of it is that there's no step "1", so it can work even with student laptops
[08:06] <alkisg> And e.g. in the summer vacations students can just delete that file to free up space
[08:06] <alkisg> It'll be automatically synced on next boot
[08:07] <vmlintu_> local kernel would enable some kind of wireless use, though
[08:08] <vmlintu_> wireless updating would need to be done after wireless connection is up, though, so updating the image at boot time wouldn't work
[08:09] <alkisg> True. One other thought is to use wubi or win32loader (the debian equivalent) to have the ltsp entry appear in the windows boot loader
[08:10] <alkisg> It's a bit less intrusive for PCs that already have windows in their disks, no partitioning / other boot manager are needed
[08:12] <alkisg> Finally, we also thought about the possibility to do the same thing with USB sticks, but currently they're a bit slow
[08:14] <alkisg> I'm postponing the whole thing for later, for when btrfs snapshots are available out of the box
[08:14] <vmlintu_> how would you use snapshots in this?
[08:15] <alkisg> That way a client could boot with its older image and do a lazy rsync/update to the new one while students are working on it. When the update is done, it would take effect on the next boot.
[08:16] <vmlintu_> I was thinking of storing two images on the disk: current and "next"
[08:17] <alkisg> Currently storing images on NTFS volumes has problems; 100 % cpu usage for several seconds, making the system unresponsive and the students angry
[08:17] <vmlintu_> ouch
[08:18] <alkisg> So until that is solved, I'd go with the seperate partition solution, and I wouldn't want to have 2 of them, neither to have to duplicate the "old" into the "next" before rsync
[08:18] <vmlintu_> yes, snapshots could solve that problem quite nicely
[08:19] <alkisg> Also squashfs isn't rsync'able, so I'd use compressed btrfs, so I'd have to wait for it anyway
[08:20] <vmlintu_> squashfs isn't rsync'able?
[08:20] <alkisg> It's not writeable
[08:20] <alkisg> It's read only
[08:20] <alkisg> ...although it's possible to rsync from a squashfs network image to e.g. a local ext partition
[08:21] <vmlintu_> I cannot twist my mind enough for that right now
[08:22] <alkisg> But for slow USB sticks, a compressed btrfs would make a big difference
[08:23] <alkisg> What I would also like to test, is 10 clients using x2go to connect to the LTSP server over 54mbps wifi
[08:23] <alkisg> ...for older clients that are not good enough to be fat
[08:23] <vmlintu_> do you mean rsync from mounted nbd image to local disk?
[08:23] <alkisg> Yes
[08:24] <alkisg> "nbd" can be whatever, squashfs, ext, btrfs, that's why I was specifically mentioning squashfs, as that one doesn't have write support, it's read-only by design
[08:24] <alkisg> So you can't rsync it locally
[08:24] <alkisg> You can copy it, but not rsync its contents to a local squashfs image, the local image needs to be something else, ext, btrfs...
[08:25] <alkisg> $ sudo mount -o loop /opt/ltsp/images/i386.img /mnt
[08:25] <alkisg> mount: warning: /mnt seems to be mounted read-only.
[08:25] <vmlintu_> but you can rsync the whole image file from the server as a file to the local disk
[08:25] <alkisg> ...I can't write anything in /mnt after mounting it, it's like mounting a cdrom
[08:26] <alkisg> Yes, but since it's compressed, it's completely different
[08:26] <alkisg> Even if you recompress the same data, the result might be completely different
[08:26] <alkisg> So rsync makes no sense there, it's like doing "cp" from scratch
[08:28] <vmlintu_> oh yes.. I just realised that we are using currently uncompressed squashfs images
[08:29] <alkisg> Uncompressed squashfs would be rsyncable, but compressed btrfs would be rsyncable too and twice as fast
[08:30] <alkisg> Uncompressed squashfs is too slow, I've never used it here
[08:31] <vmlintu_> there were some stability issues with compressed images at some point
[08:32] <vmlintu_> are the ubuntu images now compressed by default?
[08:52] <alkisg> (11:31:20 πμ) vmlintu_: there were some stability issues with compressed images at some point ==> no the stability problems were caused by nbd-proxy
[08:52] <alkisg> (we never used nbd-proxy here)
[08:52] <alkisg> (11:32:09 πμ) vmlintu_: are the ubuntu images now compressed by default? => yes they're again compressed by default, and nbd-proxy is disabled by default as well
[08:56] <vmlintu_> yes, I'm starting to remember those again.. I had forgotten the whole thing already
[08:58] <alkisg> bbl