Nachvollziehbarkeit von Konfigurationsänderungen mit Git

Wenn Sie eine Lösung suchen, um eine vollständige Nachvollziehbarkeit von Konfigurationsänderungen zu erhalten, die von (verschiedenen) Benutzern an Ihrer Firewall vorgenommen wurden, könnte das git-backup-Plugin eine nützliche Ergänzung zu Ihrer Einrichtung sein.

Um diese Funktion nutzen zu können, muss man zunächst das Git-Backup-Plugin installieren (unter System ‣ Firmware ‣ Erweiterungen nach os-git-backup suchen).

Konzept

Da sich das Git-Backup ein wenig von den Standard-Backup-Optionen unterscheidet, werden wir die Funktionsweise anhand des folgenden Diagramms kurz erläutern.

Wenn config.xml durch Benutzer- oder API-Interaktion geändert wird, wird ein Ereignis ausgelöst, das von Handlern abonniert werden kann (mit Syshook). Unser Git-Backup-Plugin abonniert diese Ereignisse, um die empfangenen Backups hinzuzufügen und diese mit den aus der empfangenen xml-Datei extrahierten Informationen zu committen. Um zu verhindern, dass sich das System während der Backups sperrt, wählen wir diese lose gekoppelte Methode. Ereignisse, die noch nicht verarbeitet sind, werden im (bestehenden) Backup-Verzeichnis belassen.

Ereignisse werden ab dem Zeitpunkt der Konfiguration des ersten Backups verarbeitet, beim Deaktivieren von Backups bleibt das (lokale) Changelog selbst aktiv.

In regelmäßigen Abständen (den Standardintervallen des Backup-Schedulers) werden die gesammelten Commits in das konfigurierte Upstream-Repository übertragen. Um diese Standardintervalle zu verkürzen, kann ein benutzerdefinierter Cronjob (siehe Settings) eingerichtet werden, wobei als Befehl Remote Backup gewählt wird. Die reguläre Backup-Prozedur (die auch über die Schaltfläche test in der Benutzeroberfläche ausgelöst wird) ist für die Initialisierung des leeren lokalen Repositorys und die Konfiguration des Upstream-Ziels zuständig.

Man kann das Upstream-Ziel jederzeit ändern, solange das neu konfigurierte Ziel entweder „blank“ (leer) ist oder genau denselben Inhalt (/Änderungshistorie) enthält wie das auf dieser Firewall verwendete.

Ersteinrichtung

Der Konfigurationsteil dieses Plugins ist recht einfach und bietet zwei Arten von Transportmodi, https unter Verwendung einer Kombination aus Benutzernamen und Passwort oder ssh unter Verwendung der Public-Key-Infrastruktur.

Aktivieren	Aktivieren der Sicherung auf das Upstream-Ziel
URL	Zielort, der das Transportprotokoll definiert, Optionen wie ssh://server/project.git oder https://server/project.git sind hier erlaubt.
Niederlassung	Der Zweig, in den Ihre Übertragungen auf der konfigurierten URL verschoben werden sollen
Privater SSH-Schlüssel	Wenn Sie ssh verwenden, stellen Sie sicher, dass Sie hier einen privaten Schlüssel hinzufügen
Benutzername	Benutzername, bei Verwendung von gitlab und ssh lautet die Vorgabe hier `git` (die meisten dieser Anbieter verwenden einen einzigen Benutzer und identifizieren den Benutzer anhand seines Schlüssels)
Passwort	Wenn Sie die https-Authentifizierung verwenden, wählen Sie hier ein Passwort.

Stellen Sie sicher, dass Sie zu einem „nackten“ Upstream-Repository pushen. Wenn Sie „Setup/Test Git“ drücken, sollten die ersten Commits an Ihren Git-Server gesendet werden.

Lösung von Konflikten

Über die Benutzeroberfläche wird keine Konfliktlösung angeboten. Sie müssen ein Upstream-Repository konfigurieren und für die gesamte Lebensdauer der Firewall bei diesem bleiben. Wenn aus irgendeinem Grund ein Backup wiederhergestellt werden muss und man bei demselben Git-Repository bleiben möchte, könnte eine manuelle Konfliktlösung eine Option sein. Support für diese Szenarien wird nicht angeboten.

Das Repository befindet sich auf dem Schulrouter Plus-Rechner im folgenden Verzeichnis /conf/backup/git.

Die Lösung von Konflikten kann sehr kompliziert sein (Zusammenführen, Vorspulen, ….), aus diesem Grund werden wir keine Funktionsanfragen annehmen, die versuchen, in bestehende (verwendete) Repositories zu pushen.

Fehlerbehandlung

Wenn Fehler auftreten, werden diese in die normale Systemprotokollierung geschrieben, suchen Sie nach git-backup in der allgemeinen Systemprotokollierung (System ‣ Protokolldateien ‣ Allgemein).

Einige Standardfehler können über die Testtaste zurückgegeben werden, die eine klare Richtung vorgeben sollten, bekannte sind:

Authentifizierungsfehler -> Benutzername/Passwort-Kombination ist nicht gültig oder der angegebene ssh-Schlüssel stimmt nicht mit dem erwarteten überein
ssh hostkey changed -> es sieht nach einem Man-in-the-Middle-Angriff aus, wenn das nicht der Fall ist und die entfernte Kennung aus triftigen Gründen geändert wurde, ist ein manuelles Eingreifen erforderlich (entfernen Sie den offensiven Schlüssel von /root/.ssh/known_hosts)
git out of sync -> kann nicht synchronisieren, siehe „Konfliktlösung“ für weitere Informationen.

Bereinigung

Das Repository wird lokal auf der Firewall in /conf/backup/git gespeichert. Wenn man aus irgendeinem Grund den gesammelten Verlauf entfernen und von vorne beginnen möchte, kann man dieses Verzeichnis sicher entfernen.

Melden Sie sich über eine (ssh) Konsole an und entfernen Sie in diesem Fall das git-Verzeichnis (rm -rf /conf/backup/git)

Solange das Plugin installiert ist und /conf/backup/git ein Git-Repository enthält, werden die Änderungen erfasst (auch ohne einen Upstream). Man könnte dieses Wissen auch nutzen, um ein lokales (nur) Repository zu behalten, indem man ein Repository ohne Zuweisung eines Upstreams anlegt und die Backup-Option deaktiviert lässt.

Die Firewall enthält eine lokale Sicherung der letzten Änderungen (konfiguriert in System ‣ Konfiguration ‣ Verlauf), die der Config-Changed-Event-Handler verwendet, um sie an die Verbraucher weiterzuleiten. Wenn man nach einer Bereinigung die gesammelten Änderungen erneut an den Upstream-Provider flushen möchte, könnte die /conf/event_config_changed.json entfernt werden, um die bereits behandelten Config-Events zu „vergessen“ (in diesem Fall werden alle Backups erneut an alle Config-Syshook-Handler signalisiert)