Boehrsi.de - IT und Gaming Blog

Mein Server-Crash und die damit verbundene Neuinstallation ist nun ca. einen Monat lang her und mittlerweile kann ich mir relativ sicher sein, dass alle relevanten Dienste wieder laufen. Außerdem wurden Anpassungen und Modernisierungen vorgenommen, die nötig waren damit alles mit Ubuntu 20.04 läuft.
Alles in allem ist das System nun wieder auf dem vorherigen Stand, allerdings mit verbesserten Tools zum Testen der Server Integrität (Lynis open_in_new) und endlich Backups auf verschiedenen Ebenen (Dateiebene und Managementebene). Ebenfalls entfernt wurden Altlasten und einige Abläufe wurden vereinfacht. Im Gegensatz zur letzten Installation habe ich außerdem wieder meine wöchentlichen Status Info Mails aktiviert. Selbige hatte ich zuvor nicht mehr aktiv genutzt, da ich selbige etwas überfrachtet hatte und sie entsprechend nicht mehr las.
Der Weg zum fertigen frischen System verlief relativ gut und auch die Anpassungen an meinen vorhandenen Todo-Listen waren vertretbar. Trotzdem gab es ein paar Lessons Learned, die ich heute mit euch teilen möchte. Auf einige der im Folgenden genannten Tools und auch auf die Backups gehe ich übrigens noch einmal gesondert ein.

Die erste Lesson Learned kommt aus der SSH Welt und ist etwas verwirrend. Denn nachdem ich meinen Server mit dem gewünschten Public Key Setup für Logins ausgestattet hatte und den Key nutzen wollte, stellte sich heraus das der Key fehlerhaft generiert wurde. Während der Erstellung wählte ich damals einen 2048 Bit Key, so wie es sich gehört. Nun einige Jahre später war dieser Wert nicht mehr nur empfohlen bei diversen Tools, sondern das Minimum. Das Ganze sollte kein Problem sein, bis zu dem Moment wo sich herausstellte das mein Key nur mit 2047 Bit erstellt wurde. Nach einer Runde Google stellte sich heraus, ich bin mit diesem Off-by-One Fehler nicht alleine. Wer mehr darüber erfahren will kann z.B. diesen Artikel open_in_new lesen. Ich muss gestehen ich habe ihn nur überflogen und mir in diesem Zuge einfach einen neuen Key erstellt, angepasst an heutige Sicherheitsstandards.
Leider war dieser SSH Key zu neu für eines meiner lokalen Tools, was die genutzte Verschlüsselung anging. Bemerkt habe ich dies, da Tortoise Git open_in_new nicht in der Lage war den Key zu laden. Tortoise Git nutze ich unter Windows, um mir Diffs anzusehen und Commit Messages komfortabler zu verfassen. Beheben konnte ich das Problem indem ich manuell die genutzten Putty Komponenten im Tortoise Git Ordner durch aktuelle von der Putty Webseite open_in_new ersetzte.

Auf der positiven Seite habe ich im Tools Bereich festgestellt, dass FileZilla open_in_new auch SFTP Verbindungen herstellen kann. Dadurch kann ich mir nun WinSCP open_in_new sparen. Selbiges war auf keinen Fall ein schlechtes Tool, aber für jeden Verbindungstyp ein eigenes Tool nutzen zu müssen wurde etwas anstrengend.
Neu war für mich tatsächlich das MariaDB open_in_new ein Fork von MySQL open_in_new ist, da merkt man mal wieder wie wenig ich in der letzten Zeit in der relationalen Datenbankwelt gemacht habe. Meist kommen bei mir aktuell leichtgewichtige NoSQL Lösungen oder auf Client Seite SQLite open_in_new zum Einsatz. Hin und wieder arbeite ich auch direkt auf einer kleinen JSON Datei, sofern es der Kontext des jeweiligen Projektes hergibt.
Sehr nützlich war für mich tatsächlich die Status Seite (status.boehrsi.de open_in_new) meines Servers, über welche ich eventuell interessierten Nutzern Informationen hinterlassen konnte, aber vor allem auch für mich selbst eine Log erstellen konnte. Das Live Monitoring über einen externen Dienst war natürlich umso wichtiger, denn nur so wurde ich auf den Ausfall überhaupt aufmerksam. Generell ist auch für mein kleines Projekt Monitoring entsprechend interessant und zum Glück mit wenig Aufwand erledigt.
Neu ist für mich auf Server Tooling Seite Lynis open_in_new, dafür ein Dankeschön an Marcel open_in_new. Mit Lynis könnt ihr eurer Setup des Servers auf verschiedenen Ebenen überprüfen und erhaltet Hinweise, mit welchen ihr mitunter für mehr Sicherheit sorgen könnt. Dieses Thema hier mit abzuarbeiten wäre etwas viel, deswegen gibt es wie oben erwähnt einen gesonderten Beitrag. An dieser Stelle sei aber schon einmal gesagt, dass auch wenn viele hilfreiche Tipps dabei sind, alles durchdacht und gemäß des jeweiligen Kontexts angewendet werden sollte. Ansonsten zerschießt ihr euch mitunter mehr als das ihr Dinge verbessert.

Abschließend hat sich für mich wieder einmal etwas sehr offensichtliches gezeigt: Automatisierung und Scripte sind extrem Hilfreich. Ich habe diverse kleine Shell Scripte, egal ob für die Erstellung von Nutzern meines Automated Hugo Deployments oder für Backups und selbige konnte ich einfach wieder auf den Server werfen und nutzen. Diese Scripte, kombiniert mit einer relativ umfassenden Dokumentation, haben mir die Arbeit tatsächlich wesentlich leichter gemacht.
Einzig die Verwaltung meiner Checklisten für den Ablauf der Wiederherstellung möchte ich noch in ein geordneteres Format überführen. Aktuell habe ich lose, an den Markdown Standard angelehnte, Textdateien. Ich habe überlegt ein Tool zu nutzen oder sogar selber eine Kleinigkeit zu schreiben, aber am Ende werde ich alles gemäß KISS open_in_new umsetzen. Ich werde einfache Markdown Dateien nutzen, diese in einem Git verwalten und mir vermutlich einige wiederverwendbare Vorlagen erstellen. Keine extra Tools, kein Cloud Sync und auch kein Multi-Client Support, denn dergleichen brauche ich einfach nicht. Sobald das kleine Setup fertig ist, werde ich auch darüber noch einmal schreiben.
Abseits von den hier genannten Dingen gab es noch diverse Kleinigkeiten, die ich vielleicht nebenbei noch einmal erwähne. Solltet ihr noch Fragen oder Hinweise haben, meldet euch doch gerne in den Kommentaren.