Konzept:/Backup

Aus wiki.freifunk.net
Zur Navigation springenZur Suche springen

Backup ist nur was für Feiglinge? - Lieber feige als tot und kein repeat-Knopf!

Backup, was für ein Backup?

In einem lokalen Mesh-Verbund kann es leicht dazu kommen, dass einige Router sehr unterschiedliche Konfigurationen haben, z.B.:

  • Freifunk-SSID und private SSID mit WPA2-Schlüssel im Parallelbetrieb
  • bestimmte SSH-Schlüssel zur Konsole-Konfiguration
  • Namen und Geolocation
  • Switch-Konfigurationen mit VLANs um
    • entweder das lokale Netz,
    • das Freifunk-Netz
    • oder beide per Kabel verfügbar zu machen.
  • individualisierte Cron-Jobs oder Scripte

Falls in einem solchen Verbund mal ein Knoten ausfällt und ersetzt werden muss, dann wäre es hilfreich dessen Konfiguration noch zur Hand zu haben. Dazu muss man diese natürlich im Vorfeld irgendwohin gesichert haben -> ein Konfigurations-Backup also.
Das Thema Backup & Restore tauchte schon öfter im Forum auf:

Hier ist eine modulare Möglichkeit vorgestellt die all diese Problemstellungen berücksichtigt und flexibel darüber hinaus erweiterbar ist.

prinzipieller Aufbau

Backup-Aufbau Konzept-Übersicht

Ein Raspberry Pi 2 Model B agiert als zentrales Element. Hier läuft ein Cron-Job, der

  • die Konfiguration von den Freifunk-Routern per SSH einsammelt, dort wird diese per cron-job in einem Verzeichnis gesammelt bereitgestellt.
  • die Konfigurationen lokal abspeichert, damit man vor Ort darauf Zugriff hat
  • zusätzlich die Konfigurationen an einen zentralen Server im Web sendet (optional hier z.B. via svn), damit
    • man unabhängig vom Ort sofort aktiv werden kann, wenn man über einen Ausfall informiert wird, z.B. über einen Knotenmonitor.
    • man bereits den neuen Router entsprechend vorbereiten kann, z.B. zu Hause. Dann hat man vor Ort mehr Zeit für dortige Dinge.
    • mehrere solche Ensembles zentral verwaltet und gesichert werden können.
    • zwei Backup-Orte zusätzlich die Redundanz erhöhen (lokaler PI + Webserver).
    • an einem Ort auch noch versioniert werden kann.

Diese Beschreibung basiert auf der Firmware von saar.Freifunk.net, Version 1.7.4 / gluon-v2018.2.2

die Umsetzung des Ganzen

Wie meist braucht man etwas Hardware, die passende Software und schon kann's losgehen.

Stückliste, woraus besteht es?

Die Stückliste bezieht sich auf die bei mir laufende Lösung. Je nach Ausbaustufe oder vorhandenem Material kann man natürlich entsprechend davon abweichen.

  • Raspberry-PI 2 (bin sicher auch ein Zero würde das hinbekommen). Idealerweise hat man einen Router mit USB-Buchse und Switch, z.B. den TP-Link Archer C7. Dort kann man dann sowohl die Stromversorgung wie auch ein stabile Netzanbindung herstellen.
    • Gehäuse für den PI
    • SD-Karte, bei mir 16Gb (gibt's wirklich an jeder Ecke)
    • Raspbian als Betriebssystem. Bei mir läuft die light-Version, d.h. ohne Desktop
  • Webserver von einem Anbieter des Vertrauens.
    • Ubuntu 18.04 in der LTS-Version mit entsprechendem ssh/rsync
    • Apache 2.4 als Webserver
    • Subversion um gezielt auch ältere Versionen meiner Konfig zu behalten und den Unterschied visualisieren zu können

Konfiguration der beteiligten Geräte

Vorbereitung

  1. Den Raspberry-PI mal. zum Laufen bringen.
  2. Auf dem PI braucht man neben den Scripten natürlich den entsprechenden Speicherplatz. Dazu bietet sich ein USB-Stick an, weil man den zur Not auch abziehen und woanders aufstecken/lesen kann.
  3. Desweiteren hilft eine Mail-Konfiguration, damit man sich selber auf dem Laufenden halten kann.
    Die Mailkonfiguration ist hoch individuell und soll hier nicht beschrieben werden.
    Beispiele finden sich allgemein unter https://raspberrytips.com/mail-server-raspberry-pi/
    oder speziell, wie in meinem Fall: postfix-konfig via SMTP-Relay.
  4. Man muss sich überlegen unter welchem user die Scripte später laufen sollen und dessen SSH-Schlüssel auf alle freifunk-Router verteilen, die später gesichert werden sollen. https://forum.freifunk.net/t/ssh-key-einrichten/2165
    Wichtig ist dabei: Es muss ein RSH-Schlüssel sein. Bei mir funktionierte weder DSA (sowie unsicher), noch ECDSA.
    • root bietet sich auf den routern an
    • auf dem Raspberry-PI reicht ein normler standard-user aus, z.B. "pi"

Knoten auf dem zentralen PI bekannt machen

Der zentrale PI steht sinnvollerweise im lokalen Netz, damit er unabhängig vom Freifunk-Netz die Informationen einsammeln kann. Deshalb müssen die entsprechenden Knoten in die /etc/hosts eingetragen werden. 

$ grep ffsaar /etc/hosts |grep tb
 2a03:abcd:3009:100:52c7:bfff:fe7d:84d8	ffsaar-tb1-unten
 2a03:abcd:3009:100:724f:57ff:fe7d:9e42	ffsaar-tb2-oben
 2a03:abcd:3009:100:16cc:20ff:fead:fb50	ffsaar-tb3-bh
 2a03:abcd:3009:100:c6e9:84ff:fee9:ce1	ffsaar-tb4-bhsaal
 2a03:abcd:3009:100:c6e9:84ff:fef9:b8bb	ffsaar-tb5-bhjugend
IP Adresse	Hostname

Falls lokale Knoten im gleichen Netz angesprochen werden sollen, dann ist noch ein zusätzlicher Schritt notwendig. Nur so ist sichergestellt, dass man darauf zugreifen kann: https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1254085 

$ echo 1 > /proc/sys/net/ipv4/tcp_mtu_probing

Einrichtung der Scripte auf den Routern

Die Haupt-Konfiguration der router kann man mittels eines Kommandozeilenaufrufs sichern und wieder herstellen. Hier sollen jedoch neben der UCI-Konfiguration auch die Cronjobs und ggfs. weitere Scripte und logfiles gesichert werden. Aus diesem Grund gibt ein Script, welches die Daten an einem Ort gesammelt ablegt config_sammeln.sh: Dieses Script lassen wir per root cron einmal täglich auf allen beteiligten Routern laufen, z.B. Um 05h01 morgends. 

1 5 * * * /bin/config_sammeln.sh

Darüberhinaus muss sichergestellt sein, dass der entsprechende user vom zentralen Rasperry-PI sich auf den Routern per ssh einloggen kann. 

 cat ~/.ssh/id_rsa.pub | ssh root@$IP-Adresse 'cat >> /etc/dropbear/authorized_keys'

Einrichtung des zentralen Raspberry-PI

Zunächst braucht man subversion 

 apt-get install subversion

dann checkt man im gewünschten Verzeichnis das Repository aus: 

 cd Pfad_wo_das_Subversion_Repository_liegen_soll #z.B. /var/space/.svnrepos/
 svn checkout https://URL-zum-zentralen-Subversion-Server/RepositryName

Das Script anpassen, welches die Konfiguration von den einzelnen Repeatern einsammelt: 

 vi config_zentralisieren.sh

Das Script einmal von Hand laufen lassen um sicherzustellen, dass

  1. alle konfigurierten Repeater erreicht werden können (Tippfehler ausmerzen, Namensauflösung sicherstellen, usw.)
  2. alle SSH-Schlüssel richtig ausgetauscht wurden und die Kopieraktion auch ordentlich funktioniert
  3. prüfen, ob der upload via svn zum zentralen Server richtig funktioniert sowohl die Funktion "svn add" wie "svn commit" automatisch und ohne manuelle Eingabe funktionieren

Im Cron einen Eintrag erstellen, damit dieses Script im gewünschter Frequenz ausgeführt wird: 

 31 5 * * * /bin/config_zentralisieren.sh

Am Folgetag schauen, ob das Script auch ordentlich gelaufen ist. Dazu braucht man sich gar nicht mehr auf dem PI einzuloggen, denn das muss auch zentral über den websvn-Server gehen. Dort muss zumindest die keep-alive Datei geändert worden sein.

Einrichtung des zentralen SVN-Servers

Zuerst den entsprechenden System-user anlegen 

 useradd ...

Dann die entsprechenden Module für Apache nachinstallieren 

 apt-get install libapache2-mod-svn

Apache Module zum authentifizieren verlinken/enablen 

 dav.load
 dav_svn.load
 dav_svn.conf

anschließend dav_svn.conf anpassen. Und zum Schluss das Repository anlegen 

 svnadm create /path/to/repository

Wenn man den Inhalt des/der Repositories komfortabel einsehen will, dann kann man noch websvn dazu installieren.

Überwachung des Backups

Das Script welches auf den Routern die Konfigurations-Dateien einsammelt schreibt beim Start einen Timestamp in eine Datei. Im Repository kann man dann nachsehen, ob dieser Timestamp auch dem geplanten Cron-Zyklus entspricht. Es ist geplant diesen Test in ein Monitoring-Tool einzubinden und damit auch die Alarmierung zu automatisieren. Zu anderen Zwecken (Messung des Füllstandes einer Zysterne sowie Luftfeuchte und Temperatur) ist bereits ein Xymon-Server im Einsatz; dieser kann entsprechend erweitert werden.
Sfinp.de, 27. Aug. 2019
Sobald erledigt, wird das hier eingepflegt.

Restore, im Fall des Falles

Im einfachsten Fall kommt man noch auf den Router per Kommandozeile drauf. Dann kann man die Einstellungen aus den Konfigurations-Dateien zurückkopieren. Falls nicht zuviel Zeit vergangen ist, nimmt man die Dateien auf dem Router selbst, andernfalls eben die aus dem Subversion Repository. Letztere kann man entweder auf dem zentralen PI wiederfinden, oder eben auf dem zentralen Webserver via websvn einsehen.
Falls die Hardware ganz ausgefallen ist, dann muss die neue Hardware zuerst ganz normal vorbereitet werden wie jeder andere Freifunk-Router auch. Sobald Zugang zur Kommandozeile besteht muss man eben die Konfiguration des alten Systems dorthin kopieren. Je nach Hardware kann man dann ggfs. die alten Dateien 1:1 übernehmen, oder man muss eben die entsprechenden Parameter raussuchen und setzen. Man hat durch das Backup jedenfalls die Möglichkeit, die alte Konfiguration zu lesen und an die neue Hardware anzupassen.

Warum gerade so

Es gibt sicher mehrere Möglichkeiten ein Backup zu realisieren. Hier also ein paar Gründe für genau diese Konstellation:

  • Würde man die Router, ihre Konfiguration direkt auf einen zentralen Server schreiben lassen, dann wäre es jedem möglich sich auf dem zentralen Server einzuloggen, der Zugriff auf einen Router hat. Die dezentralen Router sind schwerer zu sichern als ein zentraler Rasperry-PI. Deshalb die Entscheidung zum pull-Verfahren statt push-Verfahren.
  • Die Sammlung per cronjob sorgt dafür, dass es eine lokale Kopie der Konfig-Dateien gibt, auch wenn der zentrale PI mal ausfallen sollte. Ein single Point of failure wird so vermieden.
  • An zentraler Stelle könnte irgendein Gerät stehen, ein Rasperry-PI war hier vorhanden zwecks zentraler Dokumentation des Netzwerkes und Monitoring via Xymon, bzw. ursprünglich noch mit hobbit.
  • Dieses zentrale Gerät erlaubt auch den login von remote per ssh, so dass via Internet eine erste Fehleranlyse des gesamten lokalen Netzes möglich wird. Man muss nicht mehr für jedes Problem vor Ort fahren.
  • Das subversion Repository soll helfen Änderungen über die Zeit nachvollziehen zu können. Auch kann man damit nach missglückten Konfigurationen noch auf die älteren Versionen zugreifen, ohne der üblichen Rotation der Backups folgen zu müssen.
vorherige 2502050100250500nächste 250
Unterhalb werden 0 Seiten angezeigt.

Abgerufen von „https://wiki.freifunk.net/index.php?title=Konzept:/Backup&oldid=46553#smw-result“