Boehrsi.de - 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.

• Boehrsi.de Statusseite open_in_new

Der Server-Crash ist nun schon ein paar Tage her und so langsam sind wirklich alle Systeme wieder online. Im Rahmen der Neuinstallation und des frischen Setups gab es wieder einige Kleinigkeiten die ich mitnehmen konnte und selbige möchte ich mit euch teilen.
Heute geht es dabei noch nicht ums Tooling oder gute Konfigurationen, sondern um die wichtigste Sache die ich im Rahmen dieses Crashs mal wieder lernen durfte. Macht Backups, macht sie häufig und verwaltet sie ordentlich. Ein Thema über welches ich schon häufiger geschrieben habe und eines welches ich normalerweise auch sehr ernst nehme. Auf meinem privaten System erfolgen mindestens wöchentliche Backups via Robocopy und auch auf dem Server sollte derartiges aktiv sein.
Hier sind wir nun beim eigentlichen Problem angekommen. Backups sollten da sein. Die Planung der Erstellung und Sicherung der Backups war quasi abgeschlossen, aber umgesetzt wurde sie nicht. Das Resultat waren stark veraltete vollständige Backups, welche manuell erzeugt wurden. Dazu diverse einzelne Backups und Dateien, die teilweise im Rahmen von spezifischen Sicherungen erzeugt oder zu anderen Zwecken herunterladen wurden.
Alles in allem also ein Durcheinander an Dateien und Ordnern, ohne konkrete Struktur. Ich habe Vergangenheits-Daniel in den letzten Tagen nicht nur einmal verflucht, doch am Ende muss man mit der Situation umgehen. Insgesamt verlief trotz miserabler Backups alles ziemlich gut, hier kann man also im wahrsten Sinne vom Glück im Unglück sprechen.

• Boehrsi.de Statusseite open_in_new

In der Nacht vom 17. auf den 18. August gab es einen Hardwarefehler, welcher meinen Server, der den Blog und alle meine weiteren Dienste beherbergt, in die Knie zwang. Im Rahmen des Debuggings war nach ersten Tests klar, dass es sich um ein größeres Problem handeln muss, denn nicht einmal das Backup-System konnte genutzt werden. Ein Hardware-Test zeigte dann recht schnell das es sich um einen kritischen Ausfall handelt und Hardware getauscht werden muss.
Bereits am Abend stand dann neue Hardware bereit und die Neueinrichtung konnte beginnen. Hier muss ich ein Lob an Strato aussprechen, denn die Bereitstellung der neuen Hardware ging schnell und problemlos über die Bühne.

• Boehrsi.de Statusseite open_in_new

Einen Server zu betreiben kann hin und wieder Arbeit sein. Der Webserver will gepflegt werden, der Voiceserver hätte gerne Updates und auch das Betriebssystem will versorgt werden. Doch die wirkliche Herausforderung ist und bleibt meiner Meinung nach das Mailservergespann (IMAP und SMTP Server). Denn während die meisten Serverkomponenten ihre Arbeit verrichten, sofern man sie halbwegs normal konfiguriert und eine Domain auf die IP zeigt, gibt es bei Mailservern einfach so viel mehr was man richtig bzw. falsch machen kann.
Nach einigen Jahren dachte ich nun so halbwegs alle Dinge ordentlich konfiguriert zu haben. Sodass zum einen alles funktioniert und sogar ein gewisses Maß an Sicherheit gegeben ist. Doch man lernt bekanntlich nie aus und so stolperte ich zuletzt über Mails von z.B. GMX die nicht bei mir ankamen, während quasi alle anderen zufrieden waren (z.B. Gmail).
Ein spannendes und leider auch nerviges Problem. Der Grund dafür war schlussendlich nicht der Mailserver selbst, denn dieser wurde trotz MX Record gar nicht erst kontaktiert. Der Empfang der Mails schlug quasi schon fehl bevor mein Server überhaupt die Möglichkeit hatte zu reagieren, was alles entsprechend schwer zu debuggen machte.
Das Problem war am Ende ein CNAME, welcher sich in die Konfiguration für die Mailserver-Subdomain geschlichen hatte, bzw. automatisch vorhanden war. Die meisten Anbieter haben damit, auch wenn es laut RFC nicht so gewollt ist, kein Problem und alles funktioniert, einige verwehren allerdings die Zustellung bei dieser Konfiguration. Spannenderweise dauerte das Debugging extrem lange, denn während die bekannten Checking-Tools, wie z.B. MxToolbox, keine konkreten Probleme anzeigten, war nur intoDNS schlussendlich genau genug, um mich auf das Problem hinzuweisen. Nach ordentlicher Konfiguration eines A Records ist nun auch GMX zufrieden und alle Mails, natürlich inklusive des glücklichen Spams, kommen problemlos an.
Generell ist es natürlich schön dass nun alles funktioniert, aber ich bin echt froh das ich Hauptberuflich Softwareentwickler bin und mich mit der Konfiguration von Mailservern nur selten beschäftigen muss.

• intoDNS Website open_in_new
• MxToolbox Website open_in_new

Während meiner letzten Neuinstallation des Servers habe ich versucht meine alten Skripte loszuwerden. Vor allem solche die automatisiert Dienste starten. Denn dies kann man sehr praktisch und verlässlich über das System selbst regeln (systemd open_in_new).
In diesem Rahmen konnte ich diverse Komponenten aufräumen und wollte dafür sorgen, dass Dateien dort liegen wo Ubuntu sie erwartet. Doch die Ordnerstrukturen von Ubuntu sind nicht implizit klar, zumindest mir nicht. Auf diesem Grund habe ich etwas gesucht und bin auf die Filesystem Hierarchy Standard Wikipedia Seite open_in_new gestoßen.
Die genannte Seite bietet nicht nur einen Überblick bezüglich den zu nutzenden Ordnern, auch Erklärungen sind dort zu finden. Falls ihr euch also fragt wo Konfigurationsdateien für Tools die vom Paketmanager installiert werden liegen sollten oder wo manuell installierte Tools ihre Datenbank vorhalten sollten, schaut mal auf der Seite vorbei.
Ich habe sie mir in die Favoriten gepackt, denn die Ordnerstrukturen auf Ubuntu Systemen ergeben zwar Sinn, sind allerdings komplex und verschachtelt. Einige der Regeln habe ich außerdem etwas flexibel ausgelegt und z.B. für meine Java / Kotlin Microservices einen etwas zentraleren Ansatz gewählt. Dabei habe ich im Ordner des Microservices die Top-Level-Ordnerstruktur, die Ubuntu vorgibt, repliziert. Nach einigen online Recherchen habe ich nämlich festgestellt, dass die Art und Weise wie Ordnerstrukturen unter Ubuntu verwaltet werden, durchaus variable ausgelegt werden kann. Es gilt also wie immer, grundlegende Regeln einhalten, am Ende sollte aber auch alles gut nutzbar und wartbar sein.

• Filesystem Hierarchy Standard via Wikipedia open_in_new

Heute gibt es mal wieder zwei Bücher Bundles aus der Welt der Produktivität, IT und Softwareentwicklung. Das Humble Book Bundle: Computer Productivity & Coding by Mercury Learning bringt euch noch etwas mehr als 12 Tage lang bis zu 26 Videos und Bücher aus der Welt der IT. Es will euch helfen Dinge schneller und effektiver zu erledigen. In den drei Stufen, welche zwischen einem und 15 Dollar kosten, gibt es unter anderem C Programming, Cloud Computing Basics, 3D Printing, Software Testing, Python 3 und TensorFlow 2. Es gibt also nicht nur Inhalte für Softwareentwickler oder Designer, sondern auch generellen Content zu wichtigen und interessanten IT Themen.
Sofern ihr mit Linux unterwegs seid oder z.B. vorhabt Server-Admin-Aufgaben zu erledigen, dürfte das Humble Book Bundle: Linux & UNIX by O’Reilly etwas für euch sein. Bis zu 15 Bücher, für maximal 15 Dollar und mindestens einen Dollar, gibt es in diesem Bundle, welches noch etwas mehr als 5 Tage lang verfügbar ist. Mit dabei ist unter anderem Classic Shell Scripting, Learning the vi and Vim Editors und der Linux Pocket Guide. Ich persönlich bin ein großer Fan von Linux, vor allem als Basis für Server. Im Desktopbereich bin ich aus verschiedenen Gründen weiterhin mit Windows unterwegs. Wie sieht es bei euch aus und interessieren euch die Bundles? Alle Humble Bundle Links sind Affiliate- / Partner-Links die meinen Blog unterstützen.

• Humble Book Bundle: Computer Productivity & Coding by Mercury Learning open_in_new

Server Logs sind wichtig für die Admins / Betreiber von Servern, doch wie oft sollte man sie automatisiert zur Begutachtung versenden? Ich selbst hatte tägliche Zusammenfassung zum Status meines Servers und meiner Dienste an mich gesendet und kann nur sagen, lasst es. Nach einiger Zeit tritt derselbe Effekt ein, wie bei zu häufigen und erzwungenen Passwortwechseln. Während man bei Passwörtern Zettel unter der Tastatur findet, mit dem aktuellen Passwort, landen Server-Logs, die z.B. via Mail ankommen, automatisiert in Ordnern wo sie vergessen werden.
Trotzdem bin ich generell der Meinung das Statusnachrichten gut sind, also proaktiv Informationen verteilen. Spezielle Hinweise auf ungewöhnliche Vorkommnisse sind natürlich ebenso nötig, doch eben diese „speziellen Vorkommnisse“ zu definieren kann dazu führen Dinge zu übersehen. Ab wann ist z.B. eine neue große Datei ein Problem? Ab wann sollte man sich vielleicht schnell um Updates kümmern und wie relevant sind eigentlich Logs bezüglich dem Serverzugriff durch andere Nutzer? Hier gibt es viele Regeln und grundlegende Ansätze die helfen, aber nichts davon dürfte absolut perfekt sein.
Entsprechend finde ich es sehr angenehm, mittlerweile einmal pro Woche, Informationen zum Zustand meines Servers zu erhalten. Update-Informationen, Daten zu Logins, offene Netzwerkverbindungen und automatisierte Virenscans gehören unter anderem zum Output. Einmal pro Woche hat sich für mich als praktischer Zeitraum bewährt, denn ich schaue mir die Mails meistens umgehend an und erhalte trotzdem mit eher wenig Verzug relevante Informationen. Wie sieht es bei euch aus, nutzt ihr derartige Funktionen?

Bis dato habe ich meine Server-Backups und das folgende einspielen der Daten meist via FTP oder SCP erledigt. Dafür habe ich alles heruntergeladen und anschließend wieder auf das neue System hochgeladen. Dadurch geht natürlich einiges an Zeit drauf, sodass ich mich nach Alternativen umschaute. Das Stichwort ist rsync, welches ich ausgiebig für die letzte Neuinstallation meines Servers genutzt habe. Mittels rsync könnt ihr unter Linux extrem gut Daten transferieren und synchronisieren. Die Syntax ist dabei einfach, bedarf aber genauer Kontrolle, da man sonst gerne Fehler macht.
rsync -a ordner1/ ordner2 sorgt z.B. dafür das alle Dateien aus ordner1 auch in ordner2 zu finden sind. Das Argument –a ist dabei ein Alias für diverse Parameter und sorgt dafür das rekursiv kopiert wird, also auch Unterordner mitgenommen werden und ebenfalls alle Rechte, Dateieigenschaften und Links erhalten bleiben. Dies dürfte in vielen Situationen gewünscht sein und war für mich extrem praktisch. Aufpassen muss man nun wenn man rsync -a ordner1 ordner2 ohne / nutzt. Dabei wird dann nicht der Inhalt von ordner1, sondern ordner1 selbst in ordner2 kopiert. Sodass selbiger als Unterordner, inklusive aller Daten, in ordner2 zu finden sein wird. Falls ihr euch unsicher seid, nutzt den Parameter –n, selbiger steht für –dry-run und zeigt euch was passieren wird, ohne den Befehl wirklich auszuführen.
Um Daten zwischen Systemen zu transferieren fügt man entweder vor der Quelle oder dem Ziel nutzer@remote-system: ein. rsync -a quelle nutzer@remote-system:ziel synchronisiert lokale Daten auf ein anderes System und rsync -a nutzer@remote-system:quelle ziel holt Daten von einem Remote-System auf euer System. Voraussetzung ist eine bestehende SSH Verbindung und alle Platzhalter müssen natürlich durch die echten Werte ersetzt werden. Ich bin auf den Geschmack gekommen, da mein Umzug von Server zu Server auf diesem Wege extrem einfach war. Falls ihr übrigens unter Windows ähnliches erreichen wollt könnte robocopy vielleicht etwas für euch sein. Abschließend sei noch gesagt, dass bei dieser Art von Dateiaktionen vorsichtig gehandelt werden sollte und alles lieber einmal zu viel, als einmal zu wenig kontrolliert werden sollte.

• rsync Website open_in_new
• rsync Manual open_in_new

Nachdem gestern bereits die erste News zur FOSDEM 2019 erschien, mit der Einleitung und der Zusammenfassung des ersten Tages, geht es heute mit dem zweiten Tag weiter. Ebenfalls thematisieren möchte ich meinen Gesamteindruck vom Event und dem ganzen Drumherum. Denn die FOSDEM ist keine Konferenz wie z.B. die Droidcon und entsprechend läuft hier vieles anders ab. Falls ihr übrigens sehen wollt was es so gab, folgt einfach den Related Links, dort ist das Video Archiv verlinkt.
Der Sonntag war geprägt vom Thema Real Time Communications, was wohl unter anderem meiner aktuellen Arbeit geschuldet ist. Zusätzlich hielten Kollegen von mir einen Talk in diesem Raum, welcher das Thema Break the Messaging Silos with COI open_in_new hatte. In diesem ging es um das Thema Chat Over IMAP und auch von mir aktuell entwickelte Software war Thema in diesem. Dazu gibt es in den nächsten Wochen noch mehr Informationen. Weiter ging es mit Talks zum Thema WebRTC open_in_new, Matrix open_in_new und XMPP open_in_new. Diese verschiedenen Plattformen / Protokolle sind alle für die Kommunikation über das Internet nutzbar, was sowohl für reines Chatten gilt, wie auch für Voice- und Video-Chats. Es war interessant zu sehen was die jeweiligen Techniken mittlerweile können und wo Unterschiede, bzw. Ähnlichkeiten liegen.

• FOSDEM Website open_in_new
• FOSDEM Video-Archiv open_in_new

Vor etwas mehr als einer Woche hatte ich die Chance meine erste FOSDEM zu besuchen und es war ein wirklich interessantes und spannendes Event, wenn auch sehr anstrengend. Am Freitag vor der FOSDEM kam ich zusammen mit diversen Kollegen in Brüssel an und wir bezogen unser Hotel. Am Samstag starteten wir sehr früh, denn auf der FOSDEM ist immer sehr viel los und möchte man sich sicher sein einen Talk hören zu können, so sollte man ca. 30 Minuten vorher beim entsprechenden Raum sein. Zusätzlich sollte man mit größeren Menschenmengen kein Problem haben, denn das Event ist sehr gut besucht und entsprechend auch die öffentlichen Verkehrsmittel Drumherum.
Der erste Tag stand bei mir dann interessanterweise überwiegend unter dem Stern Go open_in_new. Go hat als moderne Programmiersprache sehr viele praktische Funktionen und Konzepte, sodass ich nun überlege sie für die Serverentwicklung zu nutzen. Ganze vier Talks schaute ich mir zu Go an. Zwischendurch gab es dann noch Java open_in_new mit Docker open_in_new, ein bisschen was zu Nextcloud open_in_new und wie Open Source Contributions bei Mozilla open_in_new ablaufen. Insgesamt waren es sieben Talks, die alle in die Kategorie über den Tellerrand schauen fielen. Solltet auch ihr euch etwas anschauen wollen, folgt einfach den Related Links, dort ist das FOSDEM Video-Archiv hinterlegt.

• FOSDEM Website open_in_new
• FOSDEM Video-Archiv open_in_new