ich glaube das Thema gab es hier schon mal irgendwo, aber ich konnte es auf die Schnelle nicht finden. Bei uns haben wir mehr und mehr Laptops im Einsatz, die wir ebenfalls mit Linbo verwalten. Allerdings ist der Aufwand bei Laptops um einiges höher als bei den Desktops. Diese kann man ja schön aufwecken, syncen und wieder schlafen legen.
Bei den Laptops sieht das bei uns folgendermaßen aus:
Laptop(s) holen
nächste Netzwerkdose suchen und syncen.
bei Laptopwagen noch temporär einen Switch mitnehmen und dann syncen.
Wie macht ihr das mit euren Laptops?
Ein Sync per WLAN ist sicher nicht so schnell wie per LAN, aber wenn der Linuxclient im Hintergrund per Bittorrent sich ein neues Image holen würde, wäre das toll. Hat jemand schon mal so etwas probiert?
Wie könnte man möglichst leicht Laptops verwalten, z.B. auch zukünftig in einer 1:1 Umgebung? Ist Linbo dafür überhaupt die richtige Lösung?
Hallo Stephan.
Ja, das klingt in der Theorie gut … aber in der Praxis ist imho das Problem, dass es nicht (ohne weiteres) möglich ist, einen Laptop zunächst ins WLAN zu bringen und erst anschließend per PXE zu booten. Wenn ich mich richtig erinnere, scheitert das u.a. daran, dass PXE nicht 100%ig standatisiert ist!?
Suche mal nach „pxe over wlan“ und du wirst erschlagen mit Anfragen. Meiner Meinung nach wird das ohne Kabel aber schwer…
Aber ich glaube, dass dir etwas anderes vorschwebt – nämlich, dass das aktuelle .cloop zur Laufzeit (also nicht während LINBO läuft sondern während Ubuntu läuft) im Hintergrund auf die Cache-Partition per Bittorrent aktualisiert wird, richtig? Ob das schon mal jemand ausprobiert hat, weiß ich nicht – klingt aber nach einem Killer-Feature
Schönen Gruß,
Michael
immer mal wieder kommt die Idee eines syncs über WLAN zum Vorschein.
Ich meine, dass das nciht geht: aus mehreren Gründen: das im WLAN nicht
vorhandene PXE ist kein Problem: linbo ist ja schon auf der Platte
WLAN ist ein shared medium: man stellt sich das immer so nett vor,
weil ja einzelne Clietns immer mal ganz schnell arbeiten: wenn das aber
aml mehrere sind, dann bricht das genaz schnell ein: nicht nur weil die
Bandbreite verteilt werden muß (100MBit/s durch 10 Cleints sind halt nur
noch 10 MBit/s) sondern weil der vermehrte Traffic auch die verfübare
Bandbreite nochmal senkt, da die Verteilung der Bandbreite nochmal
Kapazitäten kostet.
Aber gut: sagen wir, dass wir immer nur zwei Laptops syncen an einem
extra dafür aufgestellten AP: dann schlägt das nächste Argument zu
Treiber von WLAN Chips in linbo.
linbo muss ja auf das WLAN zugreifen. Nun ist es gerade bei WLAN nicht
damit getan, einfach alle verfügbaren Treiber in linbo zu integrieren,
weil bei WLAN sehr viel properitärer Mist getrieben wird, was seit
Jahren dazu führt, dass währen Netzwerkkarten zu 99% einfach
funktionieren, es bei WLAN immer wieder zu problemen kommt: also nur 80%
„einfach“ funktionieren.
sagen wir, dass 2) egal ist, dann geht es wenigstens für manche
Geräte, dann schlägt folgendes zu: WLAN Treiber sind gartnicht klein und
es gibt viele viele viele.
Unser linbo ist derzeit ca. 24MB groß. Ich kann nicht seriös schätzen
wie viel das wird mit WLAN Treibern: aber sagen wir einfach mal, es
werden 36MB: das betrifft dann alle Rechner überall, die statt 24MB 36MB
über das Nettz laden müssen. Und ich erinnere an die MAvel Probleme beim
Umstieg von linbo 2.2.x (12MB) auf linbo 2.3.x (24MB): die erfüllen den
PXE Standard nicht, weil ihr Speicher auf der Netzwerkkarte zu klein
ist, linbo paßt nicht rein … mist. Wer weiß welche Probleme dann 36MB
bringen: wohl gemerkt: das betrifft alle Rechner, auch die, die gar kein
WLAN haben.
und zu guter LEtzt:
4) authentifizierung im WLAN. wollt ihr unverschlüsselt und ohne
Authentifizierung verteilen? habt ihr gerne einen offenen AP im Netz?
Auch wenn er nur während des syncens online ist? Wahrscheinlich nicht:
also authentifizierung: wpasupplicant mitgeben, einrichten, wer trägt
wann wo das Passwort SSID usw. ein? wie kommt die INfo auf den Client?
Abschließend: das kann man vielleicht alles machen: aber ich sehe das
Verhältnis von Nutzen zu Aufwand als so schlecht an, dass ich da keine
Lust drauf habe. Vor allem die potentiellen Nebenwirkungen halte ich für
Immens.
Also: wer mag kann linbo in die Richtung weiter entwickel: das geht ja
immer.
Ich sehe das für mich als keine Priorität an.
Sorry.
Hallo Holger und Stephan.
… wie gesagt: ich glaube, dass Stephan (@zefanja) es gar nicht auf LINBO abgesehen hat sondern das .cloop im Hintergrund aktuell halten will, während bereits Ubuntu läuft?! Damit sind alle WLAN-Treiber und -Passwort Probleme ja bereits „gelöst“.
Ich habe das nie ausprobiert – könnte mir aber vorstellen, dass man die vom Server bereitgestellten Torrents auch mit einem ganz normalen Bittorrent (völlig ohne LINBO) unter Ubuntu anzapfen kann??
Dann hätte man in der Tat ein „immer“ aktuelles .cloop auf der Cache-Partition. Ein sychronisierter Start wäre dann auch mit WLAN-Clients beim nächsten Systemstart ein Klacks, da das Image im Hintergrund ja bereits aktuell gehalten wurde …
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).
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.
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.
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!
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?)
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?
… 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 …
… 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
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…
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…
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.
… 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 