Differentielle Images nicht möglich / Linbo Update

Clientpflege linbo
1

Hallo zusammen,

ich habe soeben meinen ersten Computerraum mit Linuxmuster eingerichtet, ein Full-Image erstellt und auf alle Clients gezogen. Es hat soweit alle super geklappt. Nun nach habe ich ein Programm nachinstalliert und würde gerne ein differentielles Image erstellen. Das funktioniert nicht. Die Ursache war an sich schnell gefunden. In der Version 4.2.14, die mit Linuxmuster 7.2 installiert ist, geht es einfach nicht. Steht auf der offiziellen Github-Seite, dass es erst ab Version 4.3 wieder funktioniert:

Es gibt auch zwei Themen hier im Forum dazu, z.B.

Meine Fragen dazu sind:

  1. Stört das keinen, dass diff. Images nicht funktionieren? Es ist anscheinend seit über einem Jahr eine kaputte Linbo-Version in Linuxmuster 7.2 und es bleibt einfach so?
  2. Ich habe versucht wie im verlinkten Thread beschrieben von lmn72 main nach lmn72-testing main zu wechseln, aber dann kann Linbo trotzdem nicht upgedatet werden. Es wird zwar Linbo-Update gefunden, die Installation bricht aber ab mit: „Die folgenden Pakete haben unerfüllte Abhängigkeiten: linuxmuster-linbo7 : Hängt ab von: libowfat0t64 ist aber nicht installierbar“

Ich wäre sehr dankbar, wenn jemand helfen könnte.

Roman

2

Hallo Roman,

ich nutze nie differentielle Images.
Jedes Image ist bei mir ein volles Image.
So kann ich ganz einfach die alten weghauen und trotzdem läuft der Laden.
Also ich habe keine kaputte Linbo Installation sondern eine funktionierende.
Für dein Programm gilt: Den Rechner synchronisiert starten, das Programm nachinstallieren und wieder ein ganz normals volles Image erstellen. Dann verteilen.
Wenn es funktioniert auf den anderen Rechnern, dann kannst du das alte Image im Backup Verzeichnis aufräumen.
Viele Grüße Ralf

3

Hallo Ralf,

danke für die Rückmeldung. Das handhabe ich momentan genauso, aber das ist doch ziemlich umständlich, oder übersehe ich etwas? Meine Partition auf dem Client ist ca 80 GB groß (diverse Programme inkl. Office, Visual Studio mit MAUI, MSSQLServer etc). Daraus Image zu erstellen und dann auf 31 Clients zu ziehen dauert Stunden. Vor allem, weil man die Clients nicht alle gleichzeitig synchronisieren kann, da sonst teilweise die Verbindung abbricht. Ich war heute den halben Tag dran. Das kann man doch nicht einfach so bei jeder kleinen Einstellungsänderung oder Programminstallation machen.
Wie macht ihr das dann ganz praktisch? Oder benutzt ihr so ein kleines Linux Image und habt das Problem nicht?

Und ich will jetzt keine Haare spalten, aber wenn Linbo ein Feature anbietet, das man zwar auswählen und anklicken kann, es aber nicht funktioniert, dann sehe ich es schon als kaputt oder zumindest verbuggt an :slight_smile:

Viele Grüße
Roman

4

Guten Morgen,
ich muss Roman da Recht geben. Auch wir haben teilweise sehr große Images (unser Windowsimage für alle ist als qcow 70GB groß…) und das das Ausrollen mit ca 1h zwar nicht wirklich erträglich aber noch machbar ist liegt nur daran, dass wir inzwischen fast überall Gigabit liegen haben und wir torrent benutzen, so dass der Server die Verteilung nicht allein stemmen muss.
Differentielle Images wären an dieser Stelle ein großer Gewinn. Das gleiche gilt übrigens für die „normale“ Synchronisierung von WIndows als Alternative zur Vollrestauration. Laut eines alten Posts in irgendeinem Thread funktioniert das zwar, aber das entspricht nicht meiner Erfahrung aus dem echten Leben.
Und unabhängig davon, ob ich etwas brauche oder nicht: auch ich finde, dass ein feature, das nicht funktioniert und in absehbarer Zeit nicht gefixt wird nirgendwo als feature bezeichnet werden und aus der Doku ausgeklammert werden sollte.

Gruß
Sascha

5

Hallo Sascha,
bei dir klappt das Ausrollen von 30 Clients mit 70GB Image in einer Stunde? Dann stimmt bei mir etwas noch nicht. Bei mir gibt es bei mehr als 10 Clients die Meldung, dass torrent seit 10s,20,30s keine Verbindung hat. Ggf. läuft es dann bei einigen Clients weiter oder bricht auch ganz ab.

Ich bin noch mitten in der Einrichtung und werde zeitnah noch untersuchen, ob es bei mir an Netzwerk, Festplatten-IO oder VM-Ressourcen liegt, wenn es bei dir problemlos klappt. Switch ist bei mir mit 20 Gbit angebunden, Festplattenauslastung hält sich laut iostat auch noch in Grenzen. Was sind denn die für 30 Linbo-Clients sinnvollen Hardwarevoraussetzungen? Ich habe die Linuxmuster-VM auf 2 Cores mit 4 GB RAM installiert. Ich würde jetzt vermuten, dass es für Linbo zu wenig ist?
Gruß
Roman

6

Hallo @Sascha,
bei uns klappt das Ausrollen bei via LAN angebundenen Rechnern auch bei >15 Geräten relativ schnell, unser Switches sind aber auch alle recht schnell mit mindestens 10Gbit angebunden. Das scheint sogar so schnell, dass die Geräte gar nichts untereinander via Torrent teilen (Evlt. ist aber auch was bei uns falsch konfiguriert).
Problematisch wird es beim Verteilen via WLAN an unseren Laptops. Sobald hier mehr als ca. 5 Geräte pro Accesspoint ein Image vom Server laden, dann stalled die Verbindung wie von @lmnuser beschrieben. Der Flaschenhals sind dann die Unify APs.

Die differentiellen Images sind daher insbesondere für Laptops (welche nicht an einer LAN-Buchse hängen) von hohem Interesse! Denn Torrent bringt nichts, da das die Auslastung der APs auch nicht ändert.

LG
Simon

7

Hi Roman,
im Prinzip können bei uns (in den vernünftig verkabelten Räumen) auch 4 Räume parallel synchronisieren (also 60 oder mehr Rechner) weil das theoretisch durch die Torrent-Geschichte ja beliebig skalierbar ist.
Theoretisch deswegen, weil wir da durchaus schon Probleme hatten, vor allem in einem Raum wo wir immer 3 bis 4 Rechner auf nem kleinen Billigswitch zusammengehängt und erst dann auf die „echte“ Netzwerkdose hängen mussten – da gab es dann verstärkt das von der beschriene Problem mit den torrent-Aussetzern.
Aber seit bei uns in allen Räumen die Verkablung und Switche neu sind, ist das nicht mehr das Problem – die 1 Stunde ist die „Einzeldauer“, 20 min runterladen, 40 min Platte-Platte-Kopie und das würde ich sehr gerne reduzieren durch a) differentielles Image b) synchronisieren statt restaurieren…

Eventuell kannst Du auch noch an Deiner config für den torrent schrauben, wenn Du das Problem ab genau 10 peers hast schau mal, ob in Deiner /etc/default/linbo-torrent
MAXPEERS=10
steht und erhöh die Zahl (ich hab 100 drin stehen, bei Dir wäre ggf 35 sinnvoll)

Eine zeitlang hatte ich auch irgendwo in einer Ecke des Serverraums einen Client stehen, der als zusätzlich „torrent-seeder“ fungiert, sprich da habe ich per cronjob jede nacht einen initcache gemacht (damit immer das aktuellste image drauf ist) und dann hat der zusammen mit dem server „geseedet“.

Und wenn das Problem bestehen bleibt, dass Du nicht allzuviele Clients parallele saugen lassen kannst – Du braucht nicht dabei stehen um einen Raum sukzessive zu syncen! Ich habs so gemacht, alle Rechner anmachen (ggf. per wakeonlan), ein Skript gestartet in dem sinngemäss folgendes steht (Rechnernamen und Zeiten an Deine Gegebenheiten anpassen);

echo 'linbo-remote -i raum01-01 -c initcache,new:1,halt' | at 13:00
echo 'linbo-remote -i raum01-02 -c initcache,new:1,halt' | at 13:30
echo 'linbo-remote -i raum01-03 -c initcache,new:1,halt' | at 14:00
#...

Das Skript schmeißt Du an und gehst nach Hause, am nächsten Tag sind die Rechner synchronisiert

Gruß
Sascha

8

Hi. Ich hatte irgendwann mal ein Script gebastelt, das den Cache zur Laufzeit synchron mit dem Server hält (Linux-Clients only). Dann liegen die Images alle schon fertig auf den Clients und man muss das Netzwerk gar nicht mehr zusätzlich belasten … weiß aber nicht genau, ob das noch funktioniert:

Viele Grüße,
Michael

9

Hallo @Michael,
gute Idee. Ich vermute, dass das Netzwerkprobleme aber vor allem bei Windows-Images auftauchen.

Der Download/Synchronhalten während der Laufzeit belegt dann aber Netzwerkressourcen. Cool wäre eine Lösung, bei der man auf dem Server vorab definiert, wieviele Clients (pro Raum?) gleichzeitig zu Laufzeit den Cache ‚aktuell halten‘ dürfen. Es müsste dann auch möglich sein unterbrochene Downloads fortzuführen (vgl rsync). Wenn z.B. ein Laptop anfängt den Cache zu synchronisieren und dann heruntergefahren und verstaut wird…

Sollte jemand mal so eine Lösung basteln - ich nimms gerne.
LG
Simon

10

Hi.

Ja, auch das gibt es schon seit einiger Zeit:

Mit dem Script kann man festlegen, wie viele Clients in einem Rutsch versorgt werden sollen.
(Allerdings geht es hier um eine Variante, die auf linbo-remote beruht und daher „nur“ dann funktioniert, wenn LINBO gerade läuft…)

Viele Grüße,
Michael

11

Hallo,
sorry, ich hatte dazu gerade auch einen Faden aufgemacht, diesen nun wieder gelöscht.

Auch wir hätten Interesse an den inkrementellen Images, dann könnte man den Standard-Start auf „sync“ lassen.

Wir haben leider eine unzuverlässige Stromversorgung, ferner Einschubrechner in dig. Tafeln, die sich per WOL nicht anschalten lassen (weil dazu die Tafeln an sein müssten), deswegen kommt Linbo Remote am Wochenende für uns nicht in Frage.

12

Hallo,

meine Erfahrungen:

Das Hängen (die Timeouts) der Torrent-Downloads hat bei uns massiv abgenommen, als wir auf Seite des Servers den Upload auf 95% begrenzt haben. Das klingt erstmal widersprüchlich, aber es sorgt u. a. dafür, dass der Torrent-Upload nicht die Antworten der Torrent-Clients über eingegangene Pakete verzögert, was dann wieder protokollbedingt den Upload drosselt. Mein virtualisierter Server kann so bis zu 70 Clients zeitgleich bedienen. Bei mehr steigt wieder die Wahrscheinlichkeit von Timeouts. RSYNC ist sehr CPU-lastig. Sobald da eine handvoll Clients von Torrent auf RSYNC zurückfallen ist alles vorbei, weil die Rsync-Verbindungen dann 100% der Mehrkern-CPU verbrauchen und das den Torrent-Seed verlangsamt, was zu noch mehr RSYNC-Verbindungen führt. Dementsprechend hatte ich dann irgendwann den Rückfall auf rsync „deaktiviert“ bzw. Anzahl der Retries bzw. den Timeout sehr hoch gesetzt.

Ich verstehe nicht wieso man MAXPEERS überhaupt einstellen muss. Sollte es nicht egal sein, wie viele Clients ein Seed hat? War das nicht Sinn des BitTorrent-Protokolls?

Hilfreich wäre hier auch, wenn der Torrent-Client auf dem Server Super-Seeding unterstützten würde, d. h. erstmal jeden Chunk (Dateiteil) einmal hochlädt, bevor er denselben Chunk ein weiteres mal verteilt.

Wir haben auch die Einstellung für den Zeitintervall von Anfragen an den Tracker gesenkt, nachdem bei Tests festgestellt wurde, dass da nur alle 30min nachgefragt wird. Aufgefallen war dies, als >15 Clients im Abstand weniger Sekunden zeitverzögert gestartet wurden und der erste Torrent-Client nur 2 Torrent-Clients (sich und den Server) für eben diese 30min gesehen hatte, während der letzte gestartete Rechner alle Torrent-Clients gesehen hat.

Kleine Billigswitches können durchaus ein Problem sein, gerade wenn hohe Raten kleiner Datenpakete involviert sind, wie es bei BitTorrent der Falls sein kann. Wir haben da mindestens einen 8 Port TP-Link-Switch aus der SOHO-Kategorie, der hat schon mit zwei Torrent-Clients gleichzeitig zu kämpfen, d. h. die Summer beider Torrent-Downloadraten entsprach zeitweise nicht einmal 70% des 1 Gbps-Uplinks des Switches. Schlimmer noch, sobald ein Image hochgeladen wurde, brach ein Image-Download auf dem benachbarten Rechner auf wenige hundert KByte/s ein.

Torrent kann Downloads fortsetzen, aber dazu muss die vorhandene Datei geprüft werden. Das Dauert bei 50-70 GB großen Images durchaus mehrere Minuten bevor der Download gestartet werden kann und ist vermutlich auch der Grund wieso die Prüfung im Linbo-Client deaktiviert wird. Dazu kommt, dass das Image ein komprimierter Abzug der Partition ist und keine Sammlung aller Dateien der Partition. Dadurch ändert sich immer die komplette Imagedatei.
Es gibt prinzipiell die Möglichkeit vor einem update-linbofs die Skripte für den Linbo-Client auf dem Server anzupassen, um das mal auszuprobieren. Ich hatte nur selber noch keine Zeit mir das im Details anzusehen.

VG
Buster

13

Hallo Buster.
Kannst Du Deine /etc/default/linbo-bittorrent
mal hier posten, damit wir das abgleichen können?

Vielen Dank und viele Grüße,
Michael

14

Lieber Buster,

  1. wie begrenzt man den Serverupload auf 95% ?
  2. wie ändert man das Zeitintervall für die Trackeranfragen, so dass auch die zuerst gestarteten Rechner mehr als 2 Torrent-Clients sehen?

Wir hatten auch einige RSYNC Prozesse bei >50 Clients die den Server stillgelegt haben. Aber mit adaptierten Torrenteinstellungen (MAXBANDWITH setzen, RSYNC Timeout hochsetzen, und vor allem SLICESIZE heruntersetzen) ging es dann auch für 100 Clients. Das Problem 2 verlangsamt die ersten Rechner bei uns nach wie vor.

Hier unsere Einstellungen in /etc/default/linbo-torrent
#############
SEEDHOURS=„100000“
MAXPEERS=„100“
MINPEERS=„1“
SLICESIZE=„32“
MAXDOWN=„“
MAXUP=„102400“
TIMEOUT=„600“
CTUSER=„nobody“
#PIECELEN=„524288“
############

Besten Dank, Adrian

15

Hallo,

ich nutze die Betaversion für differentielle Images.

dazu habe ich in /etc/apt/sourceslist.d
die datei lmn72.list mit folgenden Eintrag ergänzt:

deb [arch=amd64 signed-by=/usr/share/keyrings/linuxmuster.net.gpg] https://deb.linuxmuster.net/ lmn72-testing main

Viele Grüße
Steffen

16

@steff66 Das funktioniert bei mir leider nicht. Dann wird libowfat0t64 als nicht installierbare Abhängigkeit angezeigt. Dieses Paket gibt es wohl erst in Ubuntu 24.04 und ich habe noch 22.04.

Sonst vielen Dank an alle für eure Tipps. Ich werde es bei Gelegenheit ausprobieren, wenn ich wieder ein neues Image erstellen muss.

Eine Frage zu Linbo hätte ich noch:
Ich habe fasziniert festgestellt, dass man mit Linuxmuster PXE Boot machen kann, auch wenn die Festplatte als erstes Bootmedium eingestellt ist. Nach der Synchronisierung bootet der Rechner ja direkt in Windows, wenn ich aber im Device-Manager Linbo-Remote Prestart wähle, kann ich zwar nur einzelne Rechner nacheinander einstellen, aber die booten dann in Linbo.

Kann mir jemand einen Tipp geben wie ich es richtig umschalten kann, ob alle Clients gleichzeitig in Linbo oder direkt in Windows booten sollen?

Viele Grüße
Roman