Linbo Sync per WLAN?

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 :slight_smile:

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! :+1: :+1:

1 „Gefällt mir“

Hallo Michael!

Alternativ:

rsync 10.16.1.1::linbo/hulc-x64.cloop.torrent hulc-x64.cloop.torrent

und 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 :slight_smile:

Hi. Das macht die Sache natürlich noch viel einfacher. Damit wäre ja schnell ein Script gebastelt, was …

  • die cache-Partition mountet
  • ctorrent anwirft und das .cloop überträgt
  • die Partition wieder unmounted

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

1 „Gefällt mir“

… 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]
:scream: … 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

1 „Gefällt mir“

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

  • der Rechner nachts an sein (kann man häufig im Bios einstellen)
  • Linbo per Hand angestoßen werden, da es per WLan nicht möglich ist.

Ins Blaue gedacht:

  1. Idee: Wenn Linbo WLan könnte … : Das BIOS/EFI sorgt dafür, dass der Rechner nachts hochfährt. Linbo „schaut“ wie spät es ist, nach xx Uhr wird automatisch ein sync+neu durchgeführt. Dann wird er wieder runter gefahren.
    In einem Laptopwagen oder -koffer müsste man es zeitlich versetzt einrichten (Hitzeentwicklung, etc.)

Hat jemand schon mal versucht Linbo WLan-Funktionalität zu geben. Reicht es die Treiber zu kopieren oder muss der Kernel neu kompiliert werden?

  1. Noch eine Idee: Grml kann man problemlos so einrichten, dass es nach dem Booten im WLan ist. Für Grub gibt es ein Modul „datehook“, dass es ermöglicht zeitgesteuert zu entscheiden, was gebootet wird.
    Nun richtet man im BIOS ein, dass der Rechner um 22 Uhr gestartet wird. GRUB sorgt dafür, dass grml gestartet wird. GRMl führt ein Skript aus, dass das cloop etc. synchronisiert. Danach wird grub geupdatet, dass beim nächsten Start Linbo startet. Jetzt muss linbo nur noch wissen, dass es das neue cloop installiert …

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.