Genau so meinte ich das. Nicht per Linbo das neue Cloop holen, sondern während Ubuntu / Windows läuft - als Hintergrunddienst. Evtl. kann man dann einen Sync automatisch für den nächsten Neustart per Linbo einrichten (dann offline sozusagen).
vG Stephan
Hallo Michael, hallo Stephan,
ich hatte linbo via WLAN vor Jahren mal mit einer PCMCIA-WLAN-Karte
einzurichten versucht und war daran gescheitert, dass diese Karte von
linbo nicht erkannt wurde. Aber allein aufgrund der Netzlast (alle
WLAN-Clients teilen sich die Bandbreite eines AP und auch dessen
uplink!) kann linbo nicht der Weg sein.
Bei uns scheitert auch opsi via WLAN (was von der Sache her wunderbar
funktioniert), wenn mehrere Clients über einen AP an einem
100-MBit-Switch gleichzeitig ein Update ziehen wollen. Eine gewisse
Entzerrrung des „gleichzeitig“ ergibt sich durch die Verwendung von
SSDs. Eine Verbesserung erhoffe ich mir vom seitens unserer Behörde
avisierten Einbaus von Gigabit-Switches.
opsi ist natürlich ohne kostenpflichtigen Linux-Agenten erst mal auf
Windows-Notebooks beschränkt.
Gruß Jürgen
Hallo!
Interessanter Gedanke! Was ich probiere würde wenn ich jetzt mehr Zeit hätte. Ein extra minimales Linux-OS in Linbo anlegen, welches beim Start (manuell auszuwählen), nur den Cache via scp aktualisiert und sich dann wieder beendet.
Beste Grüße
Thorsten
Warum per scp? Man könnte doch auch unter ubuntu einen bittorrent Client laufen lassen, der den Server anzapft und die torrents dann (auf die noch zu mountende) Cache-Partition legt…??
Die .torrent-Dateien liegen ja bereits fix und fertig unter /srv/linbo … wenn ich das richtig sehe, müsste man die nur direkt auf dem Client zur Verfügung haben? Wie das mit den Zugriffsrechten auf den LINBO-Ordner bei laufendem System (Ubuntu-Client) aussieht, weiß ich nicht – wäre aber einen Versuch wert 
Nur als kurze Rückmeldung … ich habe die cache-Partition unter ubuntu gemountet … .darin befindet sich natürlich auch die .torrent-Datei vom Server!
Danach unter Ubuntu einen bittorrent-Client angeworfen (hier „Transmission“) und die .torrent-Datei geöffnet … und siehe da: der Download beginnt! Das kann man sicher weiter optimieren und automatisieren aber der Grundgedanke funktioniert! 
Hallo Michael!
Alternativ:
rsync 10.16.1.1::linbo/hulc-x64.cloop.torrent hulc-x64.cloop.torrentund dann
ctorrent -f -e 0 -M 40 -z 128 hulc-x64.cloop.torrent Quelle letztes Beispiel: https://wiki.linuxmuster.net/archiv/dokumentation:handbuch:linbo:postsync
Bleibt nur der Flaschenhals WLAN!
Beste Grüße
Thorsten
Ja, bei vielen gleichzeitigen Zugriffen ist das ein Problem… aber der „proof of concept“ ist ja zunächst mal geglückt
Hi. Das macht die Sache natürlich noch viel einfacher. Damit wäre ja schnell ein Script gebastelt, was …
Ein „Problem“ sehe ich aber dabei: Wenn ich das richtig überblicke, kann man per torrent keine inkrementellen/differrentiellen Übertragungen machen, richtig? Das heißt also, dass immer die komplette .cloop-Datei übertragen werden muss – obwohl sich uU nur sehr wenig geändert hat. DAS ist dann natürlich ein ziemlicher Flaschenhals, wenn das alles über’s WLAN gehen soll…
(Die LINBO-Alternative mit der zweiten rsync-Datei neben der cloop-Datei nutzt hier keiner (mehr), oder? Oder gibt’s noch/schon Erfahrungswerte, ob man mit v7 und dieser differentiellen .rsync-Datei auch zum Ziel käme?)
… daher eine weitere alternative Idee ins Blaue geschossen: Wie wäre es, wenn man die Cache-Partition auf dem Ubuntu-Client und die Partition auf dem Server, wo LINBO seine .cloops ablegt, mit ZFS/btrfs formatiert? Dann könnte man mit Snapshots arbeiten und könnte differentiell übertragen … das wäre dann je nach Änderungen in wenigen Sekunden erledigt … (Gerd (@gpeter), liest du mit?)
Schöne Grüße,
Michael
Hallo Zefania,
Puavo macht das „im Hintergrund syncen“.
Da Puavo angeblich OpenSource ist sollte man da Infos und Code bekommen können.
Gruß
Alois
Hi.
Ich stöbere zu diesem Thema regelmäßig weiter etwas herum …
Eine Frage an die Entwickler: Wäre es denkbar, im LINBO-Kernel die ZFS-Module zu integrieren/aktivieren?
Unter Ubuntu geht das einfach
Wenn LINBO seine Cache-Partition ebenfalls ZFS-formatiert vorhält, kann man meiner Meinung nach sehr einfach das Dateisystem per Snapshot vom/zum Server klonen und müsste nicht immer das komplette .cloop übertragen. Das wäre eine gigantische Zeitersparnis – wie seht ihr das?
Schöne Grüße,
Michael
… das ging schnell … und kann natürlich auch alle cloops, die es findet, synchron halten.
Aber die Alternative via Snapshot wäre mir weiterhin viel lieber. Wenn ZFS nicht ohne weiteres integrierbar ist, sollte es aber btrfs sein. Das ist ja im Gegensatz zu ZFS bereits im Linux-Kernel und müsste „nur noch“ hier (?) aktiviert werden?
#!/bin/bash
# Dieses Mini-Script lädt das aktuelle .cloop zur Laufzeit des Betriebssystems vom Server herunter.
cache=/dev/sda2
mountpoint=/mnt/cache
cloops="lmn-bionic.cloop.torrent"
mount $cache $mountpoint
cd $mountpoint
for i in $cloops; do
# Parameter c führt zZ nur einen Check durch; noch kein Download
ctorrent -c $i
done
cd ~
umount $mountpoint… man könnte sich so ein Script in den Autostart-Ordner oder auf den Desktop legen. Es ist natürlich bisher keinerlei Prüfung dabei, ob der Client den Server erreichen kann und bereits im WLAN angemeldet ist. Aber immerhin kann man auf diese Weise schon mal die .cloops auch via WLAN synchron halten …
Schönen Gruß,
Michael
… hab’s gerade eingebaut! Hier also Version 1.1 des Scripts. Damit kann man bereits arbeiten:
#!/bin/bash
#set -x
#############################################################################
# Scriptname : dl-cloops.sh
# Author : M.H.
# Date : 2020-01-15
# Requires : ctorrent
# Category : geeignet für linuxmuster 6.x/7.x
#Version :
VER='1.1'
#############################################################################
# Dieses Script lädt die aktuellen .cloops zur Laufzeit des Betriebssystems
# vom Server herunter. Das kann dazu verwendet werden, alle .cloops auf der
# Cache-Partition eines Linux-Clients auch dann synchron zu halten, wenn
# nur eine WLAN-Verbindung zum Server besteht. Der nächste synchronisierte
# LINBO-Start des Clients liefert dann ein aktuelles OS.
#--------------------------------------
# Variablen, die anzupassen sind:
cache=/dev/sda2
# Mountpoint muss existieren! mkdir -p /mnt/cache
mpoint=/mnt/cache
server=10.16.1.1
#--------------------------------------
if ping -c 1 -w 1 -n $server 2>&1 | grep -q '64 bytes' ;
then
echo "Server ist erreichbar. cloops werden synchronisiert..."
#Mountpoint abfragen:
if cat /proc/mounts | grep -F "$cache" > /dev/null; then
echo "Cache ist bereits gemounted!"
else
mount $cache $mpoint
fi
cd $mpoint
for i in `ls $mpoint|grep .torrent`; do
#Scharf stellen:
#ctorrent -f -e 0 -M 40 -z 128 $i
#Testbetrieb:
ctorrent -c $i
done
cd ~
umount $mpoint
else echo "Server nicht erreichbar. Client nicht online?"
fi
#EOF
Jetzt wäre mal es interessant zu erfahren, inwieweit das WLAN durch dieses Script in die Knie gezwungen wird und/oder ob man den torrent-Download ggf drosseln kann??
[etwas später]
… 
… es hätte so schön sein können … aber leider wird das cloop-File vom Server nicht heruntergeladen. Ich habe das Script gerade mal scharf gestellt, nachdem der Testdurchlauf immer erfolgreich lief. Dabei stellte sich dann aber heraus, dass der Download nicht beginnt und stattdessen bei
/ 0/0/1 [0/33306/0] 0MB,0MB | 0,0K/s | 0,0K E:2,0 Connecting
stehen bleibt. Das muss nun aber einer der LINBO-Entwickler erklären … wird da eine Authentifizierung am Server verlangt o.ä.?
Die Optionen, die man unter ctorrent mit h oder ? bei ctorrent bekommt, zeigen ja bereits die Möglichkeiten zur Drosselung an …
[noch etwas später]
Auf dem Server service linbo-bittorrent restart und ein Check mit screen -r – und schon lief der Download auf dem Ubuntu-Client an…
Options: Enhanced CTorrent User's Guide
Hi Michael,
ich möchte deine Euphorie nicht schmälern, aber das ist bei weitem nicht so einfach wie du dir das vorstellen magst.
Du kannst nicht einfach die LMN Cloops durch ein ZFS / BTRFS Snapshot ersetzen. Die Funktionalität dahinter ist doch eine gänzlich andere. Darüber hinaus verwenden >50% der LMN Nutzer wohl auch noch Windows was du hier gänzlich außer acht lässt.
Die Idee das CLOOP schon im Windows Betrieb zu aktualisieren hatte ich auch schon einmal, das Problem an welchem ich hängen geblieben bin war auch hier der MultiOS Support.
Hallo Andreas (@Till)
also ich denke, dass wir aneinander vorbei reden. Die Idee dahinter war die folgende: Nur die LINBO-Cache-Partition wird mit einem snapshotfähigen Dateisystem formatiert wie z.B. ZFS/btrfs. Auf dem lmn-Server befindet sich ebenfalls eine Partition, die mit dem gleichen Dateisystem formatiert wird. Wenn nun LINBO neben torrent/rsync in der Lage wäre, auch mit dem neuen Dateisystem zu reden, müssten nicht die vollständigen, riesigen cloops sondern nur die Änderungen/Snapshots übertragen werden. Dabei ist das OS völlig egal. Das würde natürlich auch mit Windows-cloops funktionieren, da LINBO diese Aufgabe erledigt. Auch das Ausrollen des cloops macht weiterhin LINBO. Dann kann natürlich auch wieder eine Partition mit Windows bestückt werden … mir ging es nur darum, dass man den Upload und den Download der cloops enorm beschleunigen könnte, wenn nur noch die Änderungen/Snapshots übertragen werden müssten und nicht jedes Mal alles über den Äther muss …
… das oben vorgestellte Script funktioniert übrigens. Aber auch das übrträgt halt immer alles und nicht nur die Änderungen.
[Es wäre natürlich noch flotter, wenn man den „Umweg“ über die .cloop-Datei gar nicht gehen müsste und vom laufenden OS direkt einen Snapshot (als Dataset) übertragen könnte. Man kann ja Ubuntu mittlerweile direkt auf ZFS installieren.
DAS würde die Funktion von LINBO dann tatsächlich gänzlich ändern und wäre eine völlig andere Herangehensweise. Unter Proxmox machen wir bei uns aber tatsächlich schon seit längerer Zeit „ZFS Storage Replication“ (so wie hier beschrieben). Das bedeutet: GAR kein Backup/Image, das ausgerollt und langwierig wieder hergestellt werden müsste sondern ein direkt laufender Zustand auf dem Replication-Server. Das ist genial … wir nutzen dazu „zfs-auto-snapshot“ und „zfs-backup“ …]
Natürlich ist diese Funktion so im Moment nicht in LINBO enthalten und es gibt sicher auch dringendere Baustellen, doch mit so einem Feature würde man enorm viel Zeit bei Erstellen und Übertragen der Snapshots auf die Cache-Partition des Clients sparen…
So long,
Michael
Hallo zusammen,
nur weil auch die Frage kam, wie man das bei 1:1 Geräten macht. Wir haben seit kurzem unsere selbstgebaute „Linbo-Station“ fertig und getestet:
Die Station kann als Raum „gebucht“ werden, Lehrkraft geht hinein, die Notebooks werden angeschlossen und gestartet (der Rest läuft dann automatisch dank linbo-remote -p …).
Das ganze dauert für einen Klassensatz zwischen 10 und 30 Minuten (Win10 mit 14GB, Ubuntu mit 6GB Imagegröße), bisher nicht länger.
Die Klasse kann in dieser Zeit z.B. im angrenzenden Computerraum arbeiten.
Ob sich das als Dauerlösung etabliert, da bin ich selbst gespannt. Eine Lösung, die im Hintergrund synchronisiert, wäre interessant. Aber so, dass das ganze zuverlässig läuft (haben die SuS Zugriff auf die Cache-Partition?) und ich vor allem die Kontrolle behalte, wer auf welcher Version eines Images ist (unsere Taschenrechner z.B. sind völlig out-of-sync, bis ich das „manuell“ anstoße)… Da schätze ich derzeit die doch ziemlich narrensichere Linbo-Variante.
Viele Grüße
Thomas
Hi.
Eure Station sieht krass aus – nutzen das die Kollegen bei euch bereits?
Das hast du doch über die /etc/fstab im Griff, ob sie irgendwer außer root mounten darf!? Per default ist es es imho nicht erlaubt…
Schönen Gruß,
Michael
Hallo Michael,
da wir derzeit nur eine Projektklasse haben, sind die Tests noch sporadisch - aber ja, die ist inzwischen „produktiv“.
Was die fstab angeht… wie so oft mache ich mir unter Linux überhaupt keine Sorgen.
Wenn das mit dem cloop-Sync auch unter Windows sicher und zuverlässig laufen soll…
Viele Grüße
Thomas
Hallo Thomas. @thoschi
Ich habe nochmal eine Rückfrage zu Eurer „Synchronisier-Wand“:
Auf dem Bild sind an den einzelnen Positionen keine Netzteilanschlüsse zu sehen. Habt ihr da keine Stromversorgung zum Laden installiert?
Ist also der LINBO-Sync völlig getrennt vom Laden der Akkus?
Falls ja: Aus welchem Grund?
Man wird die ganze Wand ja nicht über eine einzige Steckdose laden können, oder?
Schöne Grüße,
Michael
Hallo,
bei uns gestaltet sich das Problem etwas anders. Wir haben Medienschränke mit Laptops, die via WLan angeschlossen sind. Zum Updaten habe ich die immer rausgenommen, durch das halbe Gebäude getragen und dann an den Switch angeschlossen. Ziemlich umständlich.
Jetzt habe ich testweise das cloop nachts über WLan synchronisiert, da stört es keinen. Das funktioniert, allerdings muss
Ins Blaue gedacht:
Hat jemand schon mal versucht Linbo WLan-Funktionalität zu geben. Reicht es die Treiber zu kopieren oder muss der Kernel neu kompiliert werden?
Wir haben auch zwei mobile Schränke für Laptops und da dort ohnehin schon Stromkabel in jedes Fach zum Laden führen, war unsere Idee einfach noch ein LAN-Kabel daneben zu legen. Dann noch ein Switch rein und ein LAN-Kabel zur nächsten Dose. Das setzt natürlich eine Dose in der Nähe voraus und Platz im Schrank für den Switch, aber da gibt es auch kompakte Switche aus dem Industriebereich, die ggf. in ein Fach passen.
Für den Sync während ein Windows 10 läuft: Hat jemand schonmal versucht mit dem Windows Subsystem for Linux (WSL) auf die Cache-Partition zuzugreifen?
Alternativ könnte man ja gleich den Linux-Torrent-Client im WSL laufen lassen.
