Dirks Logbuch

Meine Server laufen seit etwa fünf Jahren unter CentOS 7. In der Zeit gab es ordentlich Updates und tatsächlich keine Probleme, die auf der Software basierten.

Eigentlich läge damit CentOS 8 als neues Betriebssystem für die Server nahe. Allerdings schreibt schon Michael Kofler, dass CentOS 8 über sechs Wochen ohne Updates war und wirft Oracle Linux in die Waagschale.

Das hört sich auf den ersten und zweiten Blick komisch an, ist es auch. Aber Oracle bietet sein Linux als FLOSS-Lösung an, die gratis ist, solange man kein System hat, bei dem man für den Support durch Oracle bezahlt. In dem Fall werden alle Instanzen kostenpflichtig. Komisches Modell, oder?

Nebenbei: Ich nutze sehr gerne VirtualBox, ebenfalls von Oracle, da muss man aufpassen, dass sich die Lizenzbestimmungen mit der Nutzung des Extension Packs ändern.

Also, was tun?

Der Vorteil von CentOS war und ist, dass es sehr lange (rund zehn Jahre) unterstützt wird und tatsächlich bin ich auch noch nicht in der Not zu wechseln. Der Support für CentOS 7 läuft erst am 30. Juni 2024 (Tabelle) aus, also erst in viereinhalb Jahren. Der Nachteil ist, dass CentOS über die Lebenszeit garantiert, API-kompatibel zu bleiben, was zum Teil in sehr alter Software resultiert (Tabelle bei DistroWatch. Das wiederum bedeutet, dass man reichlich Fremdrepositories verwenden muss - bei mir EPEL, die Remi-Repostitories für PHP und Repos für MariaDB - um halbwegs aktuelle Webanwendungen betreiben zu können. Das Web ist voll von Fragen, wie man eine bestimmte Software unter CentOS zum Laufen bekommt.

Also Plan A ist, bei CentOS zu bleiben. Die "Synergien" zwischen dem, was ich beruflich mache(n muss), nämlich Red Hat Enterprise Linux zu betreiben, und dem, was ich dann privat mache, sind schon sehr gross. Bedingung dafür wäre, dass es regelmässiger Updates gibt.

Plan B wäre, die Distribution zu wechseln, hier bieten sich quasi sofort Ubuntu und Debian an, wobei ich im Fall eines Wechsels zu Debian tendieren würde.

Es gibt natürlich noch einen Plan C, das wäre ein Docker (bzw. Podman) basiertes Setup. Mich würde sehr reizen, das mit Alpine Linux als Basis zu versuchen. Eine Alternative könnte sogar Fedora Core OS sein.

Kein Plan D, aber eine interessante Alternative könnte tatsächlich Fedora in der Server-Variante sein. Allerdings sind die Wechsel zwischen den halbjährlichen Releases schon sehr drastisch und bedürfen der ständigen Nacharbeit (vermute ich). Fedora auf dem Desktop ist super (langweilig), das funktioniert einfach richtig gut, selbst mit aktiviertem SELinux sind keine Nacharbeiten nötig.

Jetzt Ihr. Was wären Eure Empfehlungen? Viel wichtiger als "was" wäre mir das "warum" Ihr ein bestimmtes Server-OS empfehlt. FreeBSD oder OpenBSD wären auch noch nachdenkenswerte Varianten.

Das ist ein Talk, den mein ehemaliger Arbeitskollege Ramon und ich vor knapp sechs Jahren auf der deutschen Ubucon gehalten haben. Das Prinzip, das dem zu Grund liegt, hat mir auch am vergangenen Wochenende den Hintern gerettet.

Ich werde mal ein Update des Vortrags machen und die neuen Skripte einbauen (die auch unter CentOS wirken).

Zu den Lehren, die ich aus dem Serverausfall gezogen habe, gehören die folgenden.

Wenn das RAID nicht fertig synchronisiert ist, brauche ich mich nicht mehr darum kümmern, die Daten sind weg. Die gesparte Zeit investiere ich besser in eine gute Planung des Restores, die ich eh machen muss.

Die Filekopie einer laufenden MariaDB-Datenbank-Instanz ist immer noch nicht möglich, auch wenn es anfänglich so aussieht. Die interne mysql-Datenbank und die Konfigurationsdatenbank meines Mailservers waren nicht korrupt, der Rest schon.

Einen Rettungsversuch der InnoDB-Datenbanken und MyISAM-Datenbanken kann ich mittels innodb_force_recovery = 1 bzw. myisam-recover = backup,force in den Konfigurationsdateien vornehmen. Wenn das nicht hilft, sollte ich die Optionen auch wieder entfernen, weil sonst der Import der Datenbanken aus dem "richtigen Backup" nicht klappt. Die Fehlermeldung beim Import ist übrigens "Mysql error “#1030 - Got error -1 from storage engine”, das könnte auch sinnvoller benamt werden.

Es ist sinnlos, die Kommunikation des Mailproviders über die Mailadresse zu führen, die auf dem ausgefallenen Server gehostet wird, vorher umstellen!

Sehr lohnenswert ist es ein Chattool zu nutzen, dass unabhängig von der eigenen Infrastruktur ist, dazu habe ich jetzt Slack eingerichtet, ich empfehle allen, die Dienste bei mir nutzen, sich bei mir per Mail zu melden. Künftig werde ich nicht mehr auf andere Anfragen reagieren.

TL;DR: Mein Server ist ausgefallen. Wenn Ihr uns am Samstag Mails geschickt habt, schickt sie bitte noch einmal. Das Backup war leider einige Stunden alt.

Am vergangenen Samstag Morgen hat sich eine von zwei Festplatten aus dem Spiegel verabschiedet. Diese wurde von Hetzner-Mitarbeitern innerhalb einer viertel Stunde ausgetauscht. Das ist echt klasse. Die Dokumentation im erstklassigen Wiki ist ebenfalls sehr hilfreich, insbesondere Festplattentausch im Software-RAID und Seriennummern von Festplatten und Hinweise zu defekten Festplatten.

Glücklicherweise habe ich noch ein schnelles Komplett-Backup per rsync gemacht - note to myself: das nächste Mal vorher die Datenbank runterfahren - so dass zumindest alle Mails noch da waren.

Am frühen Abend, gegen 17:30 Uhr - die Synchronisation des Datendateisystems im RAIDs ist bei 95% (30 Minutes left) - raucht die primäre Platte auch ab und hinterlässt nur noch Datenmüll.

An der Stelle sei erwähnt, dass es nicht hilfreich ist, wenn mir Leute sagen, dass sie deswegen RAID-6 einsetzen. Das würde ich auch gerne, geht bei diesen gemieteten Servern aber nicht.

BTW: Für zukünftige Probleme habe ich eine Slack-Community, wer darauf zugreifen möchte, schicke mir bitte eine Mail an dirk@deimeke.net.

Natzürlich hatte ich ein Backup, warum die Recovery so lange gedauert hat, schreibe ich in einem anderen Artikel.

Man, was ist das nervig.

Aufgrund eines Irrtums, der sich durch Hören dieser Folge (ab 01:29:32) des empfehlenswerten Podcasts Rechtsbelehrung aufklärte, werde ich mit meinem root-Server wieder nach Deutschland umziehen. Ich hatte das hier schon mal angemerkt.

Mit Bekannten teile ich mir einen Backupserver bei Hetzner und da liegt es natürlich nahe mit dem Server auch zu Hetzner zu gehen. Das Preis-/Leistungsverhältnis für den EX40 ist einfach ungeschlagen. Der Server, wie auch der andere Server der Bekannten, läuft mit CentOS und sehr schnell, also so wie er soll.

Mein neuer Server stand in Rechenzentrum 20 und "fühlte" sich immer sehr langsam an, vor allem das Installieren dauerte ewig. Nun, EPEL-Repositories sind aktiviert und ich bekam den Server kurz vor dem Release von Fedora 23, daher dachte ich, es lag daran. - So war es aber nicht.

Ich habe einen nmap auf Port 22 eines Servers in einem anderen Rechenzentrum bei Hetzner gemacht und der dauerte 16.5 Sekunden, von einem anderen Server bei Hetzner (ebenfalls nicht im gleichen Rechenzentrum) dauerte es 0.07 Sekunden und von zu Hause 0.2 Sekunden.

Das spricht sehr stark dafür, dass etwas im Routing nicht sauber funktioniert und die Pakete den "falschen (langsamen) Weg nehmen". Der Hetzner-Support versuchte das Problem mit dem Rettungssystem (Debian) nach zustellen, aber da funktionierte alles zufriedenstellend. Sie verweigerten Support für das installierte System, was ich verstehe, bei einem root-Server ist man auf sich alleine gestellt.

Also habe ich den Server mit dem offiziellen CentOS-Image neu installiert und danach nichts anderes gemacht als nmap zu installieren. Das Problem war wieder da.

Jetzt ist für mich klar, dass da irgendetwas im Zusammenspiel von CentOS mit dem Routing Probleme bereitet.

Aber auch jetzt fand der Support kein Problem, ich gehe davon aus, dass es nie unter CentOS nachgestellt haben und sie boten mir an, einen Austauschserver zu bekommen. Aufgrund der Prozesse sollte ich den alten Server kündigen und den neuen bestellen, sie würden dann an der gleichen Stelle einen neuen Server bereitstellen. Das hätte das Problem meiner Ansicht nach nicht gelöst.

Glücklicherweise kann man einen Server innerhalb von zwei Wochen stornieren, das habe ich gemacht. Dann habe ich einen neuen Server bestellt und darum gebeten ihn nicht im gleichen Rechenzentrum 20 bereitzustellen. Das dauert knapp 24 Stunden und, was soll ich sagen, im Rechenzentrum 21 gibt es das gleiche Problem.

Man, das nervt.

Also wieder storniert und neu bestellt und jetzt darauf geachtet, dass der Server in ein Rechenzentrum kommt, wo ich weiss, dass es funktioniert.

Das ist halt der Nachteil, wenn man zu einem Grosshoster geht und dort wirklich Probleme hat. Die grosse Anzahl an Systemen können nur durch einen standardisierten Prozess verwaltet werden. Lösungen, die ausserhalb dieser Prozesse liegen, funktionieren halt nicht. Nicht falsch verstehen, das ist kein Vorwurf, es geht nicht anders. Aber es nervt.

Die Migration unseres kleinen Internet-Universums auf die neuen root-Server verlief erfolgreich aber leider nicht genau so, wie Ramon und ich uns das vorgestellt haben. Es ist schon interessant zu sehen, wie viel man vergessen kann, wenn man nicht täglich damit umgeht. Insbesondere die Webkonfiguration hat uns unerwarteterweise vor ein paar mittlerweile gelöste Probleme gestellt.

Alle Software, mit Ausnahme von Jabber, läuft jetzt auf den neuen Trümmern.

Es ist immer gut, vernünftig zu planen und das hiess, die Migration nicht am letzten verfügbaren Tag zu machen, weil ja etwas dazwischen kommen kann. Doof nur, dass ich in der letzten Woche Bereitschaft - hier sagt man Pikett - hatte und ich am Wochenende arbeiten musste. Aber Ramon hat das mit einer Menge Einsatz und meinem sporadischen dazwischen funken hinbekommen. Danke!

Der alte Server läuft nur noch heute ...

Ach ja, das Thema Migration werden wir nebenan bei Adminstories noch näher beleuchten.

Schon seit Jahren benutze ich Tiny Tiny RSS als Feedreader. Auf dem root-Server installiert, werden auch in meiner Abwesenheit die Feeds aktualisiert.

Die zwei grössten Vorteile liegen auf der Hand: Ich kann die Feeds überall lesen und die irgendwo gelesenen Beiträge werden nicht mehr als neu angezeigt. Einige Feeds werden so schnell aktualisiert, dass ich etwas verpasst habe, wenn ich nur zwei Mal am Tag - morgens und abends - abgefragt habe.

Zwei grosse Nachteile gibt es natürlich auch: Es lohnt sich nur, wenn man das Programm auf einem Gerät installiert, was ständig mit dem Internet verbunden ist, also beispielsweise ein root-Server oder ein Server zu Hause. Dazu muss man ziemlich weitgehende Rechte haben, sonst ist es sinnlos, ich habe bei uns einen Daemon installiert, andernfalls hätte ein Cronjob für die regelmässige Aktualisierung erstellt werden müssen. Der zweite Nachteil ist, dass Tiny Tiny RSS in der neuesten Version nur Spass macht, wenn man einen Browser der neuesten Generation mit einer sehr schnellen JavaScript-Engine benutzt, beispielsweise Chromium oder Firefox 4.

Neben einer mobilen Ansicht der Webseite gibt es auch einen Tiny Tiny RSS Client für Android-Geräte. Ich merke aber, dass der Client der grossen Anzahl an Feeds, die ich lese, nicht gewachsen ist. Für Leute, die weniger Feeds benutzen, ist das aber sicher eine Empfehlung. Dem Autoren werde ich einmal schreiben und fragen, was man da machen kann.

Alles in allem bin ich sehr zufrieden damit.

Vielleicht ist das auch etwas für Euch?

... und zweitens als man denkt.

Es gibt Tage, da fühle ich mich wie ein absoluter Anfänger, der angesprochene Umzug wurde begonnen, aber wir sind am Wochenende nicht fertig geworden. Warum? Weil Tätigkeiten, die man nicht regelmässig ausführt, die Gehirnwindungen übermässig beanspruchen. Ziemlich doof so etwas.

Die Webseiten sind migriert und laufen bereits auf dem neuen System, die Mailmigration ist zu drei Vierteln fertig und muss noch abgeschlossen werden. Eine ganze Reihe an Aufräumarbeiten steht auch noch an ...

Na, ja, es gab keine Downzeit und das ist ja schon einmal etwas ...

Apropos: Man kann gar nicht oft genug, die Mail-Tutorials von workaround.org loben. Lob!

Ramon und ich werden am kommenden Wochenende, 19. und 20. Februar, unseren root-Server umziehen auf ein neues Serverdoppel. Ich vermute, dass Ihr davon nichts mitbekommen werdet, falls es aber hakt, wisst Ihr warum.

Details über den Umzug und warum wir uns wie entschieden haben, werdet Ihr drüben bei den Adminstories nachlesen können.

Foto des Users Doglandsboy auf Flickr zeigt Nagios in einer grösseren Installation.

So, ich habe mich entschieden, für das hier angekündigte Monitoring sollen die Werkzeuge Icinga, Munin und Smokeping zum Einsatz kommen. Jens hatte mir Zabbix empfohlen, was auch das Mittel der Wahl wäre, wenn ich nicht nur einen virtuellen Server mit 5 GB Platte und 200 MB RAM zur Verfügung hätte.

Icinga ist eine Abspaltung von Nagios und sehr gut skript- und erweiterbar.

Munin ist das Mittel der Wahl, wenn mal Grafiken gebraucht werden. Es gibt eine schier unerschöpfliche Menge an Plugins, eigene Plugins sind schnell entwickelt.

Smokeping ist vom Erfinder von RRDtool und eine hervorragende Möglichkeit, Latenzen zu zeigen.

Das Ganze ist ein Hobby-Projekt, was ich nur dann anfasse, wenn ich mal auf andere Gedanken kommen muss.

Jetzt habe ich doch tatsächlich einen vServer geschenkt bekommen. Die Frage war, was ich damit mache und ich habe mir überlegt, damit freies Monitoring anzubieten. Zum Einsatz kommen soll die Nagios-Abspaltung namens Icinga (damit ich auch etwas dabei lerne).

Über das Design muss ich mir noch ein paar Gedanken machen.

Um abschätzen zu können, wie viele Leute solch ein Angebot gebrauchen können und benutzen würden, bitte ich um einen kurzen Kommentar. Bitte auch dazu schreiben, welche Dienste überwacht werden sollen.

Anmerkung: Ich kenne den Dienstleister nicht und kann (noch) nichts über die Zuverlässigkeit sagen. Wer eine Monitoring-Lösung für sein Unternehmen sucht, sollte nicht auf den von mir angebotenen freiwilligen Dienst setzen.

ACHTUNG!

Der root-Server, auf dem dieses Blog (und einiges andere mehr) läuft, zieht heute Nacht in ein anderes Rechenzentrum.

Aus diesem Grund ist das Blog und die Domain von 22:30-07:30 Uhr nicht erreichbar.

Unser root-Server macht leider weiterhin Probleme. Seit letzten Donnerstag verabschiedet er sich sang- und klanglos (ohne irgendeine Meldung im Log). Meiner Meinung nach liegt das an Überhitzung, vermutlich hat sich ein oder haben sich mehrere Lüfter verabschiedet. Ein anderer Hardware-Schaden wäre auch denkbar, aber relativ unwahrscheinlich, weil es dann immer noch Meldungen in die System-Logdateien schaffen.

Vor zwei Monaten hatten wir das gleiche schon einmal, ein achtstündiger Hardwaretest hatte allerdings nichts ergeben. Ich bin gespannt, wie sich der Anbieter jetzt dazu stellt. So kann es in keinem Fall weitergehen.

Wir haben kein Glück mit unserem root-Server. Nach dem Ausfall im Januar haben wir momentan nach einer Aufrüstung auf 4 GB (von 2 GB) Probleme mit dem Speicher. Die Kernel-Meldungen lassen keinen anderen Schluss zu.

Aus diesem Grund wird es heute einen intensiven Speicher-Test geben und der Server wird zwischen 10:15 Uhr und voraussichtlich 12:15 Uhr nicht verfügbar sein.

Update: Speicherfehler wurde gefunden und der Speicher wurde komplett ausgetauscht.

Gestern Abend habe ich das Zertifikat unserer Verwaltungsdomain auf dem root-Server auf ein CAcert-Zertifikat umgestellt. Daher kann es sein, dass Ihr einen "Zertifikat-Alarm" bekommt, wenn Ihr auf das Blog hier zugreift, da das Tool, dass ich zur Zugriffs-Analyse benutze (Piwik) in der Verwaltungsdomain liegt und diese ausschliesslich per https erreichbar ist.

Um diesen Alarm dauerhaft abzustellen, gibt es zwei Möglichkeiten, das Zertifikat einmalig zu akzeptieren oder generell allen von CAcert signierten Zertifikaten zu vertrauen. Für das zweite müsst Ihr die CAcert-Webseite mit den root-Zertifikaten besuchen, dort das Intermediate Certificate (PEM Format) (Level 3) auswählen und akzeptieren, das Level 1 Root Certificate (PEM Format) könnt Ihr zusätzlich auch akzeptieren, das ist aber für diese Webseite hier nicht nötig.