Boehrsi.de - IT und Gaming Blog

Sofern man einen Server verwaltet ist die Pflege von selbigem durchaus wichtig. Häufige Updates, Monitoring und diverse weitere Puzzleteile sind nötig, um einen stabilen und sicheren Betrieb zu garantieren. Nachdem ich in meinen Anfangstagen als Serveradministrator mitunter auf die harte Tour gelernt habe wie wichtig aktuelle Server sind, beschäftige ich mich nun seit mehr als zehn Jahren durchaus tiefgehend mit dem Thema.
Solltet ihr Ubuntu als Betriebssystem nutzen, dann könnte Ubuntu Pro etwas für euch sein. Ich hatte nebenbei darüber gelesen und mich dann informiert. Dies brachte mich zu dem Punkt das man bis zu 5 Maschinen kostenlos versorgen kann. Dadurch schaute ich mir das Ganze weiter an und fand es durchaus spannend.
Ubuntu Pro ist prinzipiell wie eine LTS (Long Term Support) Version auf Steroiden. Bei LTS Versionen kann man sich auf fünf Jahre Updates für Pakete aus dem Ubuntu Main Repository verlassen. Mit Ubuntu Pro bekommt man zehn Jahre Support und zusätzlich zu den ca. 2.300 Paketen aus dem Main Repository, bekommt man auch noch Updates für die über 23.000 Pakete aus dem Ubuntu Universe Repository dazu.
Die Einrichtung ist darüber hinaus extrem einfach. Nach der Erstellung des Accounts muss man lediglich dafür sorgen das alle installierten Pakete aktuell sind, testen ob das Tooling des Systems bereits vorbereitet ist, was bei mir der Fall war und schon geht es los. Lediglich eine Zeile, die man dem Dashboard des eigenen Accounts entnehmen kann, muss auf der Kommandozeile ausgeführt werden und das war es. Ab diesem Zeitpunkt kann man mit den bekannten Abläufen via apt seine Updates machen und bekommt normale, wie auch Pro Updates. Die komplette Anleitung, wie auch die Ubuntu Pro Webseite habe ich in den Related Links hinterlegt.

Related Links

• Ubuntu Pro Tutorial open_in_new
• Ubuntu Pro Webseite open_in_new

Den Großteil meines Wissens im Bezug auf Softwareentwicklung habe ich mir initial selber beigebracht. Wenn ihr ähnliches vorhabt oder aber euer Wissen im Bereich Softwareentwicklung vertiefen wollt, dann schaut euch doch mal die folgenden zwei Bundles an.
Das Humble Tech Book Bundle: iOS, Android, and Flutter: Mobile Development ist nur noch etwas mehr als zwei Tage lang verfügbar und bietet euch bis zu 19 Bücher und Videos zum Thema Mobile Development. Die erste der drei verfügbaren Stufen ist bereits ab 1 € freigeschaltet und alle Inhalte gibt es ab 18,16 €. Unter anderem bekommt ihr Managing State in Flutter Pragmatically, Swift Cookbook und Kickstart Modern Android Development with Jetpack and Kotlin. Eine sehr aktuelle Sammlung von Inhalten zum Thema Mobile Development, welche definitiv einen Blick Wert ist.
Falls ihr eher in Richtung IT Security oder Hacking gehen wollt, dann ist vielleicht das Humble Tech Book Bundle: Hacking by No Starch Press etwas für euch. Hier habt ihr noch entspannte 16 Tage Zeit das Bundle zu erwerben. Vier Stufen, mit einer Preisspanne von 1 € bis 29,07 €, gibt es. Insgesamt könnt ihr 18 Bücher erhalten und mit dabei sind z.B. The Practice of Network Security Monitoring, Cyberjutsu, Black Hat Python, 2nd Edition und Designing Secure Software. Ein sehr spannendes Thema, welches in einer immer digitaleren Welt gefühlt immer relevanter wird.
Alle weiteren Informationen und die Links zu den Bundles findet ihr wie gewohnt in den Related Links.

Related Links

• Humble Tech Book Bundle: iOS, Android, and Flutter: Mobile Development open_in_new
• Humble Tech Book Bundle: Hacking by No Starch Press open_in_new

Nach meinen Server Problemen im letzten Jahr, habe ich versucht mein Setup zu optimieren. Dazu gehören diverse Anpassungen bei Abläufen wie Backups und der Statuserfassung, mehr Automatisierung z.B. bei der Einrichtung von Diensten und vor allem mehr Backups.
Im Bereich Software habe ich Lynis als zusätzliche Hilfe installiert. Ein Tool welches unter anderem diverse Einstellungen, die installierte Software und die Sicherheit überprüft. Am Ende erhält man dann eine Zusammenfassung mit Vorschlägen zur Verbesserung der Systemintegrität. Die Hinweise die man bekommt sollte man nicht blindlings anwenden, sondern sich informieren und bei Bedarf nutzen. Es sollte nicht das Ziel sein eine Wertung von 100 zu erhalten, denn die Hinweise sind zwar mitunter alle durchdacht, passen aber eben nicht zu jedem Setup.

Related Links

• Lynis Webseite open_in_new
• Boehrsi.de Statusseite open_in_new

Ich habe den einen oder anderen Raspberry Pi bei mir zu Hause und einer davon übernimmt kleinere NAS (Network Attached Storage) Aufgaben. Es handelt sich dabei um einen etwas betagten Raspberry Pi aus der ersten Generation. Selbigen wollte ich vor kurzem etwas auffrischen und entsprechend habe ich das Betriebssystem und alle Komponenten aktualisiert. Das lief auch alles problemlos, allerdings schalteten meine zwei am Pi angeschlossenen externen Festplatten plötzlich nicht mehr automatisch bei nicht Nutzung in den Standby Modus. Es sind zwei normale HDDs, in dafür nachträglich beschafften Gehäusen.
Nach einigem suchen und testen stieß ich auf das Tool hdparm, welches diverse Einstellungen bezüglich Festplatten erlaubt.

Related Links

• hdparm auf Sourceforge open_in_new
• hdparm Manual open_in_new
• Via unix.stackexchange.com open_in_new

Solltet ihr auf eurem Server Web-Services betreiben, die über einen Reverse Proxy von Apache angebunden sind und ihr wollt eure HTTPS-Only-Domains trotzdem automatisiert via Let’s Encrypt schützen lassen, dann könnte euch die folgende kleine mod_proxy Direktive vielleicht helfen.
Vorab kurz ein paar Worte zu meinem Setup. Ich habe einige Subdomains für selbst geschriebene Web-Services, die ich nur via HTTPS ansprechen möchte (automatische 3xx Weiterleitung für alle HTTP Requests). Für HTTPS Requests habe ich daher via mod_proxy die entsprechenden Weiterleitungen festgelegt, um die jeweiligen Web-Services via Apache Reverse Proxy verfügbar zu machen. Die SSL Zertifikate gibt es via Let’s Encrypt.
Nun kollidiert dieses Setup aber mit der automatischen Erneuerung von Let’s Encrypt Zertifikaten. Grund dafür ist der notwendige Zugriff des Let’s Encrypt Toolings auf den .well-known Ordner.

Related Links

• mod_proxy ProxyPass Dokumentation open_in_new
• Let’s Encrypt Website open_in_new

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.

Related Links

• 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.

Related Links

• 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.

Related Links

• 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.

Related Links

• 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.

Related Links

• Filesystem Hierarchy Standard via Wikipedia open_in_new