Linbo Sync per WLAN?

Hallo,

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?

Ich freue mich über eure Gedanken!

vG Stephan

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 :slight_smile:
Schönen Gruß,
Michael

Hallo,

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

  1. 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

  1. 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.

  2. 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.

LG

Holger

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 …

Schöne Grüße,
Michael

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 Like

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 Like

… 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: http://www.rahul.net/dholmes/ctorrent/userguide.html