Wenn Du denkst, Du hast ihn, dann springt er Dir aus dem Kasten. Trotz guter Vorbereitung und gelungener Generalprobe kann die Premiere richtig in die Hose gehen.
Man kann sich vorbereiten wie man will, an alle Eventualiäten kann man nicht denken. Das Vorhaben ist schnell beschrieben: von einem Class-C-Netz in ein Class-B-Netz migrieren und in dem Zug die Belegung der IP-Bereiche strukturieren. Zwar soll der Mesh-Controller weiterhin DHCP bedienen, die auszuliefernden Adressen für die Clients aber fest definiert sein. So spart man sich Konfigurationsaufwand an den Clients und kann sie dennoch schnell adressieren. Abschließend noch alle bisherigen Server-Dienste in Docker packen und die nutzenden Cleints umkonfigurieren.
Die Docker-Generalprobe im alten Class-C-Netz lief einwandfrei und war in wenigen Stunden durch. Aus Bequemlichkeit wurde beschlossen, die alten statischen DHCP-Adressen nach der Migration anzupassen.
Das war der erste Fehler.
Nachdem das Subnetz eingestellt und der Router neu gestartet war, fing das Chaos an: einige Mesh-Knoten wollten nicht mehr mitspielen und die WLAN-Clients liefen Amok. Auf Druck der Anwender wurden diese freigeschaltet indem deren Adresseinträge gelöscht wurden (geändert werden konnten nur die Class-B-Anteile, was bei einem Umzug von 192.168.1.x auf 172.16.x.x nutzlos ist). Die Cleints rissen sich sofort Infrastruturadressen unter den Nagel, sodass die Mesh-Knoten nicht an ihren Platz konnten. Daher mussten zunächst alle Endgeräte in einen ungenutzten Bereich verlegt werden, um die Infrastruktur-Plätze frei zu bekommen. Nachdem die zentralen Komponenten eingebunden und am richtigen Platz waren, begann die Fleißarbeit: welche MAC gehört zu welchem Endgerät?
Alles in allem eine herbe Verzögerung schon direkt nach dem Start.
Nun kam die Server-Installation an die Reihe. Bei der Generalprobe beschränkte sich dies auf die Installation des OS mit anschließendem Docker/Portainer-Aufsatz. Abschließend dann die einzelnen Container – fertig. In diesem Fall wurde ein baugleiches Server-Modell mit einigen alten Platten innerhalb von knapp 2 Stunden hochgezogen.
Soweit zur Theorie.
In der Praxis war das OS auf dem Haupt-Server schnell installiert. Beim Anschließenden Neustart nach Einbau der gewechselten Festplatten dann die Überraschung: der Boot-Loader meldet 2 defekte Platten! Der Zweit-Server mit alter Systemplatte ausgestattet fraß die beiden angemeckerten Platten ohne Probleme. Nach langen verzweifelten aber erfolglosen Recherchen ging der Weg zur Datensicherung: erstmal alle privaten Dateien (Dokumente, Photos, Videos etc.) auf eine externe USB-Platte gespielt. Der Plan lautete, im Anschluss einen Reparaturlauf über die beiden betroffenen Platten zu jagen – mit dem Risiko des Datenverlustes. Allerdings verlief der Kopiervorgang dermaßen problemlos, dass ein Verdacht aufkeimte. Also schnell das OS neu auf dem Server installiert und für einen letzten Versuch die Platten eingebaut. Reboot – alles lief! Was war geschehen: Installationen sind der seltene Zeitpunkt, an dem für ein paar Minuten eine Tastatur am Server eingesetzt werden kann. Da aber nur ein Keyboard im Arbeitszimmer herumflog, wurde dieses kurzerhand zur Installation umgestöpselt. Da nebenbei noch die Clients richtig im Netz positioniert werden sollten, wurde laufend umgestöpselt und die ein oder andere Eingabe landete auf der falschen Maschine. Vermutlich wurde dabei eine Paketinstallation abgebrochen, sodass das OS einen Schaden im Boot-Prozess hatte. Evtl. wurde auch nur das Installationsmedium zu früh entfernt – wer weiss das schon?
Nachdem der Server also anstandslos auf die Füße kam, wurde er entsprechend konfiguriert: Systemeinstellungen, Freigaben etc. In diesem Zug erfolgte auch die Neustrukturierung der Verzeichnisse, also eine erhebliche Vereinfachung der Zugriffspunkte, was zukünftigen Administrationsaufwand minimieren sollte. Beim ersten Zugriff auf die Resourcen durch einen Client dann die Ernüchterung: weder SMB- noch NFS-Broadcasts brachten ein Ergebnis, sondern wurden mit Zeitüberschreitungen abgebrochen. Stundenlanges Suchen der Ursache brachte keinen Erfolg (vermutlich handelt es sich um Versionskonflikte SMB1/2/3 bzw NFS bis hin zur 4) und ein Workaround wurde erdacht: die Resourcen werden in den Clients direkt verdrahtet, was zwar nicht elegant aber zweckmäßig ist. Ergänzende Info zum timeout für alle, die ein ähnlich gelagertes Problem haben: laut Doku werden diverse Ports für die Kommunikation verwendet. Der Portmapper muss zur Ermittlung der Resource auf einem Port im 6xx-Bereich antworten- In Ermangelung notwendiger Netzwerkerfahrung erfolgte an dieser Stelle der Abbruch weiterer Recherchen.
Wer bei dem Befehl „showmount -e“ auf einen timeout stößt, hat das gleiche Problem – an einer sauberen Lösung besteht weiterhin Interesse.
Neben einigen Kleinigkeiten im Verbund TVheadend/OSCam war der Rest des Systems dann schnell aufgesetzt. Allerdings hatten die KODIs Probleme, über den Init hinwegzukommen,da in der advancedsettings.xml alte Zieladressen hinterlegt gewesen sind. Bei einigen konnte die SDCard gemountet und aktualisiert werden, bei anderen war eine Neuinstallation erforderlich (direkte Installation auf der Box – möglicherweise hätte ein Explorer geholfen, aber die Zeit war knapp).
Kaum 48 Stunden später war das System wieder up, die vermeintlich großzügig kalkulierten 12 Stunden also bei weitem überschritten. Derzeit liest das Mediasystem alle Daten ein, da eine Migration der Datenbank nicht geplant gewesen ist.
Unterschätze nie die Komplexität im Gesamtkontext eines Netzwerkes.