Hallo,

die letzte Woche hatte es in sich… Kurzzusammenfassung:

1.

Ich habe noch einen kleinen, zweiten Server, den ich für das Monitoring, DNS, Achims Seiten, und Entwicklung nutze. Das ist ein billiger VServer, ich brauche weder die Netzwerkbandbreite noch den Hauptspeicher noch den bereitgestellten Plattenplatz jemals auch nur zur Hälfte - und die verbrauchte CPU-Laufzeit ist einfach lächerlich.
Die Kiste habe ich seit ungefähr 2011.

Am letzten Wochenende habe ich ein bisschen was am Monitoring getan, sprich "mehr Monitoring".

Und bald danach wunderte ich mich über sporadische Aussetzer im Monitoring. Frage #1: "Warum in aller Welt ist das Forum so oft nicht erreichbar?"

Nun, die Antwort war, dass das Forum durchaus erreichbar war, aber der Hoster (Strato, to name the not innocent), ein Limit auf die Zahl der Prozesse und Threads gesetzt hat. Spassigerweise gibt es auch keine Meldungen im Systemlog, wenn ein Thread nicht gestartet werden kann (wer muss so etwas schon wissen?), deshalb hat's eine Weile gebraucht, bis ich wusste, was los war.
Und es hat auch nichts geholfen, das Monitoring teilweise abzuschalten, weil nämlich das Limit immer wieder mal anders war. Mal war bei 96 Prozessen und 192 Threads Schluss, mal bei 64 / 150, mal dazwischen (und das sind nur die Werte, die ich mitbekommen habe).
Übrigens braucht schon der mysql-Daemon 29 Threads.

Nun, in meinen Vertragsbedingungen steht etwas von CPU-, Hauptspeicher- und Festplattenspeicherlimits. Nirgendwo steht etwas von einem Prozesslimit, dass zuschlägt, wenn man keines der anderen Limits auch nur ansatzweise ausschöpft.

Mir hat das ein paar Fehlalarme eingebrockt, und später ist dann mehrfach der Webserverprozess gestorben.

Strato, ich glaube, ihr spinnt. Übersetzung in Business-Sprech: Die Zahl eurer Kunden reduziert sich um einen.

Der neue Server ist schon da.

2.

Ich hab' vor ein paar Wochen auf dem richtigen Server (Forum und so) mal caddy (den Webserver-Prozess) aktualisiert (von 0.11.0 auf erst 0.11.4 und vor ein paar Tagen auf 0.11.5), und auf meiner Seite getestet. Lief.
Am Dienstag Abend habe ich dann mal die aktuelle Version im Forum eingespielt, ohne es zu merken (ein Script hat ein bisschen mehr gemacht als ich dachte).

Mittwoch morgen kam die erste Frage, wieso die Benutzerin denn mit ihrem Internet Explorer nicht mehr ins Forum kommt, wohl aber mit Firefox. Und bald darauf noch zwei...
Nun, ich muss ja zugeben, dass ich Menschen bewundere, die im Jahr 2019 den Internet Explorer verwenden. So wie man beispielsweise Menschen bewundert, die sich einen Arm brechen und dann daran herum wackeln, um das Gefühl auszukosten. Also mit etwas Mitleid und ganz viel Verständnislosigkeit.

Im Normalfall hätte ich gesagt: "Ihr habt Glück, und dürft endlich auf einen anderen Browser wechseln".

Aber... mich störte, dass es plötzlich Probleme gab. Also habe ich nachgesehen. Und festgestellt, dass caddy am Abend davor neu gestartet worden war. Moment. 0.11.5. ChangeLog lesen. Hm, was könnte "- tls: Removed CBC ciphers from defaults" wohl heißen? Okay, eine Antwort ist klar - die chained block ciphers sind aus der Liste der Default-Cipher entfernt worden.
Das ist nicht falsch - die Erfahrung zeigt, dass die CBCs eher häufiger als andere Cipher unsicher implementiert waren.

Und es ist 2019 - Zeit so etwas zu entfernen, zumal ja wohl niemand mehr auf solchen Kram angewiesen ist. Denn alle halbwegs aktuellen Browser bzw. Libraries implementieren die neueren Sachen. Oder?

Oder! Der IE benutzt nämlich die Systembibliotheken, und die sind auf alten Windowsversionen ziemlich alt.
Andere Browser liefern gleich aktuelle Cipher mit.

Also, was tun? Klar, die alten Cipher wieder re-aktivieren. Gut. Ich schätze, das löst das Problem - erstmal. Zumindest bis die Cipher ganz deaktiviert werden, und nicht nur aus der Defaultkonfiguration fliegen.

Aber, liebe Benutzer antiker Browser (Übersetzung: "Sicherheitslücken in Form eines vor 5 oder 10 Jahren aktuellen Microsoft-Browsers"): Es wird nicht so lange dauern, bis auch andere Websites die alten Cipher abschalten.

3.

Der neue Zweitserver ist da, also ziehe ich mal das DNS von der Kiste mit dem Namen x4 auf x8 um.
Geht schnell.

Dachte ich. Ahem. Klar.

Bei der Gelegenheit habe ich dann mal auf x7 (der große Server mit dem Forum drauf) den Container mit dem DNS-Zeug drin gestoppt und wieder gestartet. Nein, halt - gestoppt ja. Aber gestartet bekam ich ihn nicht mehr. Und auch die anderen Container ließen sich weder stoppen noch starten. Offenbar hatte sich da irgendetwas aufgehängt (bloß was?).

Irgendwann war ich es dann leid, und habe mir gesagt, dass das eine schöne Gelegenheit wäre, das Basissystem zu aktualisieren, und mal zu rebooten (das war eh' irgendwann fällig).
Datenbanken von Hand runter gefahren. Postgres wieder gestartet, schnell mal ein Backup gemacht, gestoppt. Reboot.

So weit, so gut. Schlüssel für das große Dateisystem eingegeben, Container gestartet. Sah gut aus.

Meine Seite aufgerufen. Au. Keine Verbindung zur Datenbank. Hm.
Ursache? Tja, die Datenbank ist defekt. Wieso das? Die war doch sauber runtergefahren worden…
Datenbankinhalte gelöscht, Backup eingespielt, getestet. Gut (wenn man davon absieht, dass wieder eine Stunde weg war).
Wieso die DB defekt war? Keine Ahnung. So gar keine. Ich hab' den Container noch ein paar mal runter- und raufgefahren, aber das hat der DB nichts ausgemacht (was gut so ist, auch wenn ich nicht reproduzierbare Probleme hasse).

Zurück zum DNS… Moment. PostgreSQL ist jetzt OK. Die anderen Datenbanken? MySQL sieht OK aus, ist aber eh nichts Wichtiges drauf (nur ein Piwik oder wie das heute heißt, für jemanden, der einen Wert darin sieht).
Die MongoDB? Oh Mist. Zeit für das Backup aus der letzten Nacht. Ist eigentlich auch nicht so wichtig, oder? Oh. Doch. Da läuft ja die experimentelle Volltextsuche. Backup oder Neuaufbau? Neuaufbau ist weniger Arbeit (geht automatisch, dauert 24 bis 48 Stunden), Backup wäre sofort wieder da, kostet aber ein paar Minuten Arbeit.
=> Backup.
Sagte ich "sofort wieder da"? Satz mit X, der Import des Backups schlägt fehl. Fehlermeldung? Wer braucht schon Fehlermeldungen (Ingo, das ist *Dein* Dreck. stderr gehört auch ins Log)?

Telefon klingelt. Forum funktioniert nicht. Die experimentelle Volltextsuche *sollte* das nicht verursachen, aber möglicherweise hab' ich da ja einen Fehler eingebaut. Moment. Welche Fehlermeldung? Bad Gateway.

Das ist dann 'was Anderes. Danke, liebe void linux Entwickler, dass ihr immer noch einen php-fpm-pool installiert, wo schon einer ist, und dann noch dazu einen, der nicht funktionsfähig ist.

Zurück zur MongoDB. Was sagt das Log jetzt? Platte voll? Nein, mit Sicherheit nicht. Da sind 54 GB frei. Inodes? Nein. strace anwerfen.
30 Minuten später: Nö… bitte nicht. Irgendein Stück Dreckssoftware denkt, dass jeder Fehler beim Öffnen einer Datei wohl bedeuten muss, dass das Dateisystem voll ist. Ist aber nicht. Die Fehlermeldung ist EMFILE, sprich, der Prozess hat zu viele Dateien oder Netzwerkverbindungen offen.
Heben wir das Limit mal an. Oder? Es ist jetzt schon 8000… Was ist das denn?

Ach was, jetzt ist es genug, ich schalte die externe Volltextsuche wieder ab.

4.

Der DNS-Container auf x7 ist wieder da, also kurz auf x8, der neuen Kiste, einen eingerichtet.
Wobei hier "kurz" wirklich mal kurz bedeutete.

Getestet. Funktionierte.

Jetzt müsste ich nur beim Registrar der Domain eben die IP-Adresse in Nameserver-Record von alt auf neu ändern.
Wo in aller Welt mache ich denn *das*? Die Nameserver einer Domain zu ändern - kein Problem. Aber wo ändert man die IP-Adresse der Nameserver?

Hm. Nichts gefunden. Vielleicht klappt es ja, die NS der Zone zu ändern (auf die alten Namen, mit neuem Glue). Fehlermeldung per Mail bekommen (unverständlich, unpräzise, ohne eine genaue Aussage, welcher Nameserver nicht geantwortet haben soll).
Nochmal. Andere Fehlermeldung. Nochmal. Wieder andere Fehlermeldung. Nochmal. Keine Fehlermeldung, keine Erfolgsmeldung.

Whois? Keine Änderung. Auch nach einer Stunde nicht.

Dann zufällig das falsche Menü beim Registrar aufgemacht. *Da* ist die Funktion, die ich suche.
Aber nur da - in der Doku ist sie nicht zu finden, und von anderen Stellen wird auch nicht darauf verwiesen.
Na gut, IP-Adresse geändert. Abgeschickt. Fehlermeldung. Nameserver antwortet nicht. So so.
tcpdump angeworfen, noch mal abgeschickt, Fehlermeldung, Nameserver antwortet nicht. Na ja, im tcpdump ist auch kein Paket angekommen. Ich liebe das Internet - irgendwo ist immer etwas kaputt, und das macht doch an einem Samstag Abend besonders viel Spaß. Äh. Nicht?

30 Minuten gewartet. Nochmal. Keine Fehlermeldung.
Fünf Minuten später kommt die Erfolgsmail, und ungefähr zum selben Zeitpunkt auf die vor 90 Minuten vermisste Fehlermeldung.

5.

Jetzt wird es Zeit, Achims Seiten umzuziehen.
Die Datenübertragung klappt, irgendwelche Probleme gibt es nicht, die Seite läuft bald.

Gut. Starten wir den Container mal eben neu, nur um zu sehen, ob das klappt.

Die Seite läuft nicht mehr. Datenbank nicht erreichbar.

Hm. Aber sie läuft doch. Hm. "Plugin 'auth_socket' is not loaded."

WTF? Das klappte doch eben noch?

Abhilfe: mysqld_safe, use mysql, update user set plugin='mysql_native_password'.
Warum das nötig ist? Keine Ahnung. Warum es vor dem Reboot funktioniert hat? Keine Ahnung.
Was da los ist? Auch keine Ahnung.

Aber ich hoffe, es hält - wenn nicht, muß ich noch mal ran. Systemadministration aus der Hölle.

6.

Und nun… das Monitoring. Prometheus, node_exporter, blackbox_exporter, php-fpm, caddy,

Total trivial. Damit ist man in 5 Minuten fertig.

Äh, nein. Nicht mal ansatzweise. Eher so 500 Minuten. Immerhin ist man ja bei den Sachen, die einem verraten, was alles schlechter läuft als vorher, und stellt die Sachen dann ab.
Und eine vernünftige Alarmierung ist noch nicht dabei.

7.

Bei der Gelegenheit ein Hinweis an die Leute, die bei Debian Pakete
zusammenstellen (vielen Dank für eure Mühe), oder aus irgendeinem Grund,
ähnlich mir, blöd genug oder gezwungen worden sind, Debian zu verwenden
(mein Beileid).

Es ist ja toll, dass /etc/default/sshguard die Variable LOGFILES setzt,
die von /etc/init.d/sshdguard auch benutzt wird…

Aber wehe, sshguard läuft auf einem System mit systemd - da wird LOGFILES
dann nämlich nicht beachtet, sondern nur ARGS.

Wie viele Jahre gibt es systemd nun schon?
Zu viele. Aber noch nicht genug, um eine Dokumentation hervor zu bringen,
die ich an einem Abend verstehen kann (Hinweis: 'Dokumentation', die mich
dazu zwingt, Lücken mit Google zu schließen, ist das Wort nicht wert -
außerdem führt mich Google dann meist weg von der Dokumentation).

Wie viele Jahre gibt es systemd nun schon in debian?
Die Antwort ist relativ einfach: 4 Jahre. Plus zwei Jahre, die an Debian
gewerkelt wurde, um eine reibungslose systemd-Umstellung zu ermöglichen.
Was, wie man sieht, ja hervorragend geklappt hat.

Abhilfe:
Möglichkeit 1: (empfohlen)

        https://itrig.de/index.php?/ar [verkürzt] n-und-SysV-Init-verwenden.html

Möglichkeit 2: (wenn 1 halt nicht geht, weil irgendwelche Dreckssoftware
systemd braucht - proxmox, ihr dürft euch angesprochen fühlen)

    in /lib/systemd/system/sshguard.service die Variable ARGS um
                -l /var/log/auth.log
    (und/oder andere Logfiles) ergänzen.

Seufz. Wenn ich alles richtig mitgezählt habe, waren Achims Seite 3 Tage (+- etwas), das Forum 2 bis 3 Stunden, und meine Seite 32 Stunden down.

Ich hoffe, jetzt ist erst mal Ruhe.

Gruß, Uwe