EdgeMax router retten …

Ich hatte die vergangene Woche relativ viel Pech und ich beide meiner EdgeMax-Router (EdgeMax Lire und EdgeMax 5PoE) in einen zustand gebracht, in dem sie nicht mehr ordentlich booteten. Beide Zustände waren selbst verschuldet: Bei einem Router hab ich scheinbar einen wichtigen BootSkript modifiziert, so dass in einem bestimmten Zustand ein Booten nicht mehr möglich war. Bei dem anderen Router hab ich wohl durch „ungünstiges“ Reseten das FileSystem geschrottet.

Es stehen nun zwei Varianten für das Recovery zur Verfügung.

  1. Recovery System vie TFTP booten und Fehler beheben
  2. Router aufschrauben, USB Stick ausbauen, Stick an anderem System mounten und die Reperatur starten

Alles setzt auf dem EdgeMax RecoveryKit auf. Will man via TFTP sein system retten, geht man nach dieser Anleitung vor: https://community.ubnt.com/t5/EdgeMAX/EdgeMax-rescue-kit-now-you-can-reinstall-EdgeOS-from-scratch/td-p/514857

In meinem fall musste ich jedoch nicht alles neu installieren. Wenn man das Rettungs-OS hoch gefahren hat, ist unter /root/w das overlay gemounted. Hat man im EdgeOS irgendein Script oder Config File geändert, taucht es hier auf. Löscht man es, hat man wieder die original Version. Im Zweifelsfall kann man einfach alle Änderungen in einen Sicherungs-Ordner verschieben und von Scratch starten …

Eine andere Hausnummer war der IO Defect. Hier musste ich erst mal den Stick ausbauen und testen. Nach mehrfachen „badblock“ Durchläufen war klar, dass es nur das FileSystem zerschossen hatte. Da nach den Durchlauf von Badblock die PartionsTabelle zerstört wurde muss ich komplett vom scratch aufsetzten.

Mit folgendem script habe ich angefangen: https://github.com/vyos/emrk/blob/master/bin/emrk-reinstall.

Da ich keine Risiko eingehen wollte, habe ich alle befehle einzeln per hand ausgeführt, man kann aber auch einfach die variablen korrekt setzten und das Skript im ganzen ausführen. Anschließend Stick wieder einbauen router hochfahren und neu konfigurieren…

Änderungen bei LVM

Wer wie ich regelmäßig einen Raid 1 (Mirror) mit LVM aufbaut/betreibt, wird seit neusten (zu mindestens wenn er auf den aktuellen Ubuntu LTS setzt) in folgendes Problem laufen. Der bisher gültige Befehl führt nicht mehr zum gewünschten Ergebnis:

lvconvert -m 1 volumeGroup/logicalVolume  --corelog
  Insufficient free space: 1 extents needed, but only 0 available

Das ganze liegt daran, dass sich die art wie LVM jetzt einen Raid aufbaut wohl geändert haben soll. Ich bin da nicht tiefer hinabgestiegen. Schlussendlich muss man einfach noch den Typ mit angeben, dann klappt es wieder.

lvconvert -m 1 volumeGroup/logicalVolume  --corelog --type mirror
  volumeGroup/logicalVolume: Converted: 0,0%
  ...
  volumeGroup/logicalVolume: Converted: 100,0%

Script beim Resume in Ubuntu Xenial (16.05)

Die Xenial Server Distribution deployed standardmäßig keine pm-utils mehr. Selbst wenn man diese nachinstalliert ziehen die Script-Hooks nur wenn man direkt die Kommandos aufruft. Bei Calls über d-bus werden die nicht ausgelöst. Will man systemweit scriptes bei einem Suspend oder Resume aufrufen muss man ein skript (service) in den systemd einhängen.

Die Service Datei muss unter /etc/systemd/system liegen und auf .service enden. Der Inhalt muss ungefähr so aussehen um nach jedem „aufwachen“ einen Skript auszuführen.

[Unit]
Description=Run start_my_connection
After=suspend.target
After=hibernate.target
After=hybrid-sleep.target

[Service]
ExecStart=/path/to/script/file

[Install]
WantedBy=suspend.target
WantedBy=hibernate.target
WantedBy=hybrid-sleep.target

CineS2 Treiber „OnTheFly“ laden

Wer wie ich eine CineS2 6.5 im einsatz hat, ist unter Ubuntu ein bisschen gekniffen. Der Treiber wird noch nicht mit dem offizjellen Kernel ausgeliefert. Das führt dazu das man leider auf einem Produktivsystem etwas selber bauen muss. Besonders nach einem Kernel Update nerft das ganze, da man den Treiber im laufenden Betrieb überschreiben muss.

Als erstes brauch man git. Via git clone oder gut pull von https://github.com/DigitalDevices/dddvb die neusten Sourcen downloaden.

Erst mal den alten Treiber „entladen“ (fals man noch weitere DVB-Karten hat müssen deren Treiber auch entladen werden)

sudo rmmod ddbridge
sudo rmmod dvb_core
sudo rmmod cxd2099 

anschließend geht es ans bauen

make clean
make -j 8
sudo make install

Treiber wieder laden …

depmod -a
modprobe ddbridge

So geht es auch ohne Neustart …

EdgeMax Router und die eigene DHCP-Server Config

Wer einen EdgeMax Router im Einsatz hat, kann über die Configschnittstelle seinen DHCP Server aufsetzten. Wer aber einen bestehenden DHCP Server migrieren will, wird blöde, alles über dieses Interface einzuhacken. Es geht auch einfacher. Die bestehende dhcpd.conf unter /config ablegen. Man kass es prinzipjell überall hinlegen, aber dort überlebt die Datei ein Firmware-Upgrade.

 

Anschließend die Datei /etc/init.d/dhcpd anpassen und von der automatisch generierten auf die /config/dhcpd.conf umbiegen. Wenn man im Configmenu den DHCP-Server abgeschaltet hat (kein Eintrag unter services) muss man nun noch den DHCP-Server beim Start mit starten lassen:

update-rc.d dhcpd default

Schon hat man seinen selbst-konfigurierten DHCP Server am Start.

OpenWrt im Langzeittest

Ich hab seit einer geraumen Zeit OpenWRT im Einsatz und will hier mal meine Meinung zu dieser „Linux-Distribution“ kundtun.

Bei OpenWRT handelt es sich wie DD-WRT um eine aus dem WRT54G-Basissystem entstandene, auf Router ausgerichtete Firmware. Viele weitere Projekte wie z.b Freifunk bauen auf OpenWRT auf.

Was zeichnet OpenWRT nun gegenüber anderen Router-Firmwares aus, was macht es empfehlenswert? Kurz und knapp: es ist ein „echtes“ Linux. Soll heißen, man hat ein schreibbares  Root-Dateisystem, vollen Zugriff auf /dev, /etc und alle Änderungen überleben einen Reboot. Man kann sämtliche Hilfs- und Automatisierungsfunktionen abschalten bzw. deinstallieren und ggf. auf einem „nackten“ System aufsetzen. Mittels des Paketmanagers opkg kann man bequem fast alles nachinstallieren was man so braucht, wenn mal etwas fehlt kann man es sich auch selber ein Paket bauen. Alles in allem ein Eldorado. Kniffelige Setups lassen sich relativ unkompliziert Umsetzen, Dinge die mit anderen Firmwares nicht funktionieren (VLAN  Konfiguration pro Port) sind mit OpenWRT ohne größeren Aufwand umgesetzt. All das hat dafür gesorgt, dass OpenWRT momentan auf allen meinen Routern im Einsatz ist.

Es gibt aber auch Schattenseiten. Die große Funktionsvielfalt geht meist mit einem Konfigurationswust einher. Bei OpenWRT versucht man das über eine einheitliche Konfigurationsschnittstelle  abzufangen (UCI). Dabei gibt es unter /etc/config eine reihe von Konfigfiles die immer „gleich“ gestaltet sind. Diese werden mittels Paketabhängiger Scriptes dann in die eigentlichen Konfigurationsfiles umgesetzt. Aus der WLAN-Config Datei /etc/config/wireless wird zb das /tmp/hostapd.conf erzeugt und anschließend der hostapd Dienst hochgefahren. Dieses Verfahren hat drei Schwächen. Wenn der Paketverwalter keine UCI Unterstützung vorsieht, ist man wieder mit der Hand am arm unterwegs. Manchmal wird sowohl UCI als auch die eine eigene Konfiguration benötigt, dann wird es schnell unübersichtlich. In seltenen Fällen empfinde ich das UCI Interface komplizierter als die ursprüngliche Konfigurationsmethoden. Die UCI-Firewall Konfig schmeiße ich immer als erstes runter und setzte mir alles selber mit iptables-befehlen auf.

Was noch Problematisch ist, ist der  Upgrade/Deploy-Prozess. Es gibt verschiedene Varianten OpenWRT auf seinen Router zu bekommen. Einmal die „stable“ Images, dann den Entwickler-Images und zu guter letzt kann man sich aus dem Entwickler-Repo auch das latest-Image zusammenbauen. Die komfortabelste Variante ist ein stable-Image. Diese wird über die gesamte zeit mit Packages versorgt. Das Entwickler-Image (trunk) benötigt man, wenn die eigene Hardware noch nicht von dem stable-Image unterstützt wird. Hier hat man mit zwei Problemen zu rechnen. Zum einen fliegen Pakete aus dem Repo einfach raus. Das würde einen normalerweise erst bei der nächsten stable-Version (mit Vorwarnung) ereilen. Das zweite Problem ist, sobald die Entwicklerversion auf einen neuen Kernel setzt, werden die module entsprechend hochgezogen. Will man ein Paket aktualisieren steht nun ein komplettes Router flashen an. Nach dem flashen hat man quasi wieder einer jungfräulichen Router. Einzig ein paar vor definierte Ordner und Dateien (inkl /etc)  werden erhalten. Pakete und Anpassungen muss man manuell nachziehen. Das macht die Fernwartung ein wenig kniffelig.

Das sind aber auch die einzigen Probleme, die ich mit dieser Distri hatte. Ansonsten sind in ca einem Jahr betrieb keine einziger störender Effekt aufgetreten. Die ganze Zeit liefen die Router stabil und ohne nennenswerten Konfiguration/Administrationsaufwand.

Moneyplex auf Ubuntu 12.04 64bit mit PCSC-Treiber

Wer Moneyplex mit auf einem 64Bit system betreibt, wird das ein oder andere Mal verärgert feststellen, dass es immer noch keine native 64 Bit Version des Programms gibt. Um es zu starten muss man unter Ubuntu schon immer das ia32-libs Package installieren. Will man dann auch noch den kartenleser via PC/SC-Treiber ansprechen (oder muss es, weill der Herrsteller nur solche Treiber ausliefert) musste man im 10.04 LTS basteln. Mittlerweile kann man einfach die benötigte Library im 32 Modus nachinstallieren. Einfach das Paket libpcsclite1:i386 nachinstallieren, Moneyplex neustarten und zb den Reiner-SCT ohne gefrickel ansteuern.

So nun muss matrica nur noch eine 64Bit Version raus bringen, dann bin ich 100% zufrieden 😉

LVM – Rolling Mirror

Rolling Backups sind eine beliebte Variante um zum einen alle BackupMedien gleich-verteilt zu ab zu nutzen und zum anderen mehrere Backupversionen zur Verfügung zu haben. Diese Arbeitsweise wird jedoch mit zunehmender Speichergröße unpraktisch. Ein Fullbackup ist bei 2TB nicht mehr Täglich möglich (6-8 Stunden IO nur durch Backup). Bei inkrementellen Backups ist das Wiederherstellen einzelner Dateien zeitaufwändiger.

Ein guter Kompromiss sind Tools wie „rdiff-backup“. Diese bietet quasi ein Full und Inkrementell Backup  in einem rutsch an. Da nur Änderungen geschrieben werden, bleibt die Dauer des einzelne Backuplaufes kurz und da immer ein FullBackup gehalten wird, kann man ohne Umwege auf die „aktuellste“ Version zurückgreifen. Nur wenn man auf ältere Versionen zurückgreifen will, muss man „ein bisschen“ Rechenzeit einplanen.

Jedoch muss bei rdiff-backup immer der letzte aktuelle Stand als Backup vorliegen. Tauscht man einfach platten durch, kann man beim „einlegen“ einer neuen Platte nicht mehr auf die alten Daten zugreifen. Mann muss die neue Platte also vorher mit den alten Daten bespielen.

Die Idee: Man richtet kurzzeitig einen Mirror zwischen HDD n und HDD n+1 ein. Die Syncronistation beeinflusst das Gesamtsystem kaum, da es sich Backupplatten handelt. Das Backup bleibt über die gesamte Zeit verfügbar, es können also weitere Inkrements gespeichert werden. Die Syncronisationsdauer spielt also keine Rolle. Ist der Mirror hergestellt entfernt man HDD n aus dem System und legt sie in einer anderen „Brandzone“ ab. HDD n+1 übernimmt jetzt die aktive Backupphase. Das kann man so lange treiben bis einem Entweder die Platten ausgehen oder man die gewünschte Datensicherheit/Speicherdauer erreicht hat.

Zum umsetzen kann man LVM nutzen. Das Backupdevice muss jedoch von Anfang schon ein LVM-Device sein.

Als erstes initialisiert man einen Mirror. In Fall wird dem Logischen Device vgBackup/lvBackup die Platte /dev/sda hinzugefügt.

pvcreate  #ggf  zu für die LVM Nutzung vorbereiten.
vgextend diskGroup  #Diskgruppe erweitern
lvconvert -m 1 diskGroup/logcalDevice  --corelog --type mirror -b
lvs #hiermit kann der Sync-Status abgefragt werden.

Nun muss der Spiegel aufgebrochen werden. Normalerweise kann man die Platte einfach so entfernen (HotSwap) wenn kein IO stattfindet. Wenn man sichergehen will, mountet man das Device mal kurz read only.

Anschließend werden ein Haufen fehlermeldungen auftrehten die auf die Fehlende Platte hinweisen. Die wird man mit folgendem Befehl los:

vgreduce --removemissing diskGroup --force