vmlintu_alkisg: we've just been thinking of ways of cloning the nbd image to the local disk07:57
vmlintu_alkisg: did you plan on installing the fat client chroot on the local disk and running from there?07:57
alkisgvmlintu_: I want to support that as a possible scenario for slow local networks, yes07:58
alkisgIt involves 2 steps, as I thought it:07:58
alkisg1) Boot all the clients as ltsp clients. It'll be slow as the network is slow.07:59
alkisgRun a "copy nbd image locally" script07:59
alkisgSince that's a fat chroot, it can also contain gparted etc07:59
alkisgI think here we'll do that part from epoptes, as it allows launching programs as root on the clients07:59
vmlintu_have you done any tests on that yet?08:00
alkisg2) On boot, mount the nbd image and compare to the local version08:00
alkisgIf the remote image is newer, run rsync to sync it locally08:00
alkisgSo every time the sysadmin runs `ltsp-update-image`, the next boot will be a bit slower08:00
alkisgDepending on the changes, it might need a couple of minutes to complete the boot process08:00
alkisgThat's all, it should allow for very slow networks to use LTSP08:01
vmlintu_your plan sounds quite similar to what I had in mind08:01
alkisgNo, I haven't implemented anything about that part yet08:01
alkisgI don't know when I'll have time for it08: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
alkisgThat's on the (2) part as well08:03
alkisgThe newer kernel is available in the nbd image, one can copy it over its local /boot as well08: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
alkisgone can just have a "sync-image-locally" kernel parameter,08:04
alkisgand when that's in effect, it would copy the nbd image to the first hd partition, whatever that is,08:05
alkisgso e.g. if it's a windows partition, it would sync the nbd image to C:\ltsp.nbd08:05
vmlintu_that'd be interesting08:05
alkisgThe good side of it is that there's no step "1", so it can work even with student laptops08:06
alkisgAnd e.g. in the summer vacations students can just delete that file to free up space08:06
alkisgIt'll be automatically synced on next boot08:06
vmlintu_local kernel would enable some kind of wireless use, though08:07
vmlintu_wireless updating would need to be done after wireless connection is up, though, so updating the image at boot time wouldn't work08:08
alkisgTrue. One other thought is to use wubi or win32loader (the debian equivalent) to have the ltsp entry appear in the windows boot loader08:09
alkisgIt's a bit less intrusive for PCs that already have windows in their disks, no partitioning / other boot manager are needed08:10
alkisgFinally, we also thought about the possibility to do the same thing with USB sticks, but currently they're a bit slow08:12
alkisgI'm postponing the whole thing for later, for when btrfs snapshots are available out of the box08:14
vmlintu_how would you use snapshots in this?08:14
alkisgThat 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
alkisgCurrently storing images on NTFS volumes has problems; 100 % cpu usage for several seconds, making the system unresponsive and the students angry08:17
alkisgSo 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 rsync08:18
vmlintu_yes, snapshots could solve that problem quite nicely08:18
alkisgAlso squashfs isn't rsync'able, so I'd use compressed btrfs, so I'd have to wait for it anyway08:19
vmlintu_squashfs isn't rsync'able?08:20
alkisgIt's not writeable08:20
alkisgIt's read only08:20
alkisg...although it's possible to rsync from a squashfs network image to e.g. a local ext partition08:20
vmlintu_I cannot twist my mind enough for that right now08:21
alkisgBut for slow USB sticks, a compressed btrfs would make a big difference08:22
alkisgWhat I would also like to test, is 10 clients using x2go to connect to the LTSP server over 54mbps wifi08:23
alkisg...for older clients that are not good enough to be fat08:23
vmlintu_do you mean rsync from mounted nbd image to local disk?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 design08:24
alkisgSo you can't rsync it locally08:24
alkisgYou 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 /mnt08:25
alkisgmount: 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 disk08:25
alkisg...I can't write anything in /mnt after mounting it, it's like mounting a cdrom08:25
alkisgYes, but since it's compressed, it's completely different08:26
alkisgEven if you recompress the same data, the result might be completely different08:26
alkisgSo rsync makes no sense there, it's like doing "cp" from scratch08:26
vmlintu_oh yes.. I just realised that we are using currently uncompressed squashfs images08:28
alkisgUncompressed squashfs would be rsyncable, but compressed btrfs would be rsyncable too and twice as fast08:29
alkisgUncompressed squashfs is too slow, I've never used it here08:30
vmlintu_there were some stability issues with compressed images at some point08: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-proxy08: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 well08:52
vmlintu_yes, I'm starting to remember those again.. I had forgotten the whole thing already08:56
=== alkisg1 is now known as alkisg

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!