Daily Archives: 10. November 2016

PANIC: fatal region error detected; run recovery

Posted on by

Ok, vorweg, es geht nicht um GeoIPs, Zeitzonen oder andere Sachen die mit geografischen Regionen zutun hat 🙂

PANIC: fatal region error detected; run recovery

Das ist eine Meldung der BerkeleyDB, einer filebasierten einfachen Datenbank, die Programme gern benutzen, wenn Sie keinen richtigen Datenbankbackend brauchen/wollen. Eins der Programme ist der Webalizer, ein Analysetool , das jedem statistiksüchtigen  Apachenutzer  ein Begriff sein dürfte.

Es kann vorkommen, daß diese Datenbank beschädigt wird. Die Anwendung gibt dann die obige Fehlermeldung aus, oder auch nicht, weil nach >dev/null umgeleitet.

Woran merkt man das also, wenn dieser Fehler auftritt ?

Zunächst mal, macht Webalizer nichts mehr, er kommt nicht mehr voran, weil … keine Ahnung wie man so fehlerintolerant programmieren kann, ich weiß es nicht. Also das Teil bleibt einfach stehen. Das sieht dann so aus:

           |-sshd(878)-+-sshd(3593)---sshd(3619)---bash(3631)---webalizer(13066)---java(13074)-+-webalizer(16621)-+-webalizer(16623+
           |           |                                                                       |                  |-webalizer(16624+
           |           |                                                                       |                  |-webalizer(16625+
           |           |                                                                       |                  |-webalizer(16626+
           |           |                                                                       |                  |-webalizer(16627+
           |           |                                                                       |                  |-webalizer(16628+
           |           |                                                                       |                  |-webalizer(16629+
           |           |                                                                       |                  |-webalizer(16630+
           |           |                                                                       |                  |-webalizer(16631+
           |           |                                                                       |                  `-webalizer(16632+

im TOP und IOTOP sieht man Webalizer kann auch nicht mehr auftauchen, weil die Prozesse in einem QuasiSleep sind.

Wenn man jetzt auf den Hauptprozess (oben die PID 16621 ) ein strace anwendet mit „strace -s 1024 +f +p 16621“ bekommt man das zu sehen:

strace: Process 16621 attached
write(2, "BDB0060 PANIC: fatal region error detected; run recovery", 56

und nichts passiert mehr. In dem Fall kann man strace einfach abbrechen und getrost die dns_cache.db löschen:

rm -f /var/lib/webalizer/dns_cache.db

Dann bricht man den Webalizer Hauptprozess mit kill ab, und startet das Ganze von vorn. Fertig.

WordPress: Let’s Encrypt Zertifikate und PHP CURL

Posted on by

Let’s Encrypt Zertifikate und PHP CURL sind wie es scheint eine unheilige Verbindung, denn sie wollen nicht zusammen arbeiten. Aber der Reihe nach:

Am Anfang war das Update…

… und nach dem WordPressupdate, kommt auch die WordPress-Netzwerk-Updatefunktion, die, wenn man wie Bloggt-in-Braunschweig.de eine MultiSite betreibt, alle Blogs auf Stand bringt. Das war bislang kein Problem, weil die ohne SSL im Spiel zu haben, updated WordPress die Subinstallationen per HTTP aufruf. Nun, wenn man wie unsere Admins aber ein Lets Encrypt Zertifikat für die WordPressseite benutzt, ruft man den WP-Admin auch mit HTTPS auf, weil sonst das Zertifikat vollkommen umsonst wäre.

Solange man selbst den Adminteil aufruft, ist alles ok, weil der Browser kennt das LE Root Zert schon. Will man jetzt aber das Netzwerk updaten, ruft WordPress die Subseiten auch per HTTPS auf, auch wenn die gar nicht per HTTPS erreichbar sind, weil sie mit Subdomains arbeiten, für die der Webserver auch konfiguriert sein muß. Ab 100 Subdomains spielt LE auch bei der Zertifikaterstellung nicht mehr mit, was bedeutet, MultiSites mit über hundert Blogs müssen ein Wildcard-Zertifikat kaufen und das kann ins Geld gehen.

Jetzt gibt es zwei Wege das Problem mit LE zu lösen, ohne Geld auszugeben :

Man wechselt unschön auf HTTP und aktualisiert die Blogs so, oder man manipuliert den ROOT.CA Speicher von PHP und parkt das LE Root CA dort. Der letztere Teil rein technisch nicht weiter tragisch:

  1. Firefox aufmachen -> Einstellungen -> Erweitert -> Zertifikate  und das LE ROOT unter DST suchen und als /home/username/LEROOTCA.cert abspeichern.
  2. im PHP Code vor das curl_exec() folgende Anweisung schreiben:
    curl_setopt ($ch, CURLOPT_CAINFO, ‚/home/username/LEROOTCA.cert‘);
  3. Dann sollte das PHP Script auch das LE Zertifikat akzeptieren

Hier ein paar Wege um an so ein Zertifikat zu kommen:

Im FireFox auf der Seite mit dem benötigten Zertifikat einfach die Seiteninformationen aufrufen, dann Sicherheit und Zertifikat ansehen ( Details ) :

Wie man Zertifikate Exportiert Ein Klick auf Export und

Und speichern...

Jetzt der Haken an der Sache: im WordPress sind einfach zu viele Curl Calls drin, als das man als Laie mal eben die obige Operation durchführen kann. Ergo: Melden wir WP-User uns jetzt mal bei WP, auf das die den Support für LE bei WordPress einfach mitbringen 🙂