| 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:57 |
| 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:58 |
| 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 | 07:59 |
| 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:00 |
| 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:01 |
| vmlintu_ | have you thought about the kernel updating part? | 08:02 |
| 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:03 |
| 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:04 |
| 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:05 |
| 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:06 |
| vmlintu_ | local kernel would enable some kind of wireless use, though | 08:07 |
| 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:08 |
| 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:09 |
| alkisg | It's a bit less intrusive for PCs that already have windows in their disks, no partitioning / other boot manager are needed | 08:10 |
| alkisg | Finally, we also thought about the possibility to do the same thing with USB sticks, but currently they're a bit slow | 08:12 |
| 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:14 |
| 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:15 |
| vmlintu_ | I was thinking of storing two images on the disk: current and "next" | 08:16 |
| 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:17 |
| 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:18 |
| alkisg | Also squashfs isn't rsync'able, so I'd use compressed btrfs, so I'd have to wait for it anyway | 08:19 |
| 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:20 |
| vmlintu_ | I cannot twist my mind enough for that right now | 08:21 |
| alkisg | But for slow USB sticks, a compressed btrfs would make a big difference | 08:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| vmlintu_ | oh yes.. I just realised that we are using currently uncompressed squashfs images | 08:28 |
| alkisg | Uncompressed squashfs would be rsyncable, but compressed btrfs would be rsyncable too and twice as fast | 08:29 |
| alkisg | Uncompressed squashfs is too slow, I've never used it here | 08:30 |
| vmlintu_ | there were some stability issues with compressed images at some point | 08:31 |
| vmlintu_ | are the ubuntu images now compressed by default? | 08:32 |
| 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:52 |
| vmlintu_ | yes, I'm starting to remember those again.. I had forgotten the whole thing already | 08:56 |
| alkisg | bbl | 08:58 |
| === alkisg1 is now known as alkisg | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!