Nginx

Nachdem die Migration zu Hugo sehr erfolgreich verlaufen ist, wurden auch Einstellungen in der Nginx-Konfiguration notwendig.

Nicht mehr vorhandene Seiten

Nicht mehr vorhandene Seiten müssen Suchmaschinen mitgeteilt werden. Dadurch wissen die Suchmaschinen, dass die Seite nicht nur temporär nicht gefunden werden kann, sondern permanent entfernt wurde. Mit Nginx setze ich dazu mit einer Map eine Variable, welche in der nachfolgenden Nginx-Konfiguration abgefragt wird um den Code HTTP-Statuscode 410 (gone) zurückzusenden. In der Map sind alle nicht mehr verfügbaren Pfade eingetragen.

Gegenüber Apache ist Nginx ein reiner Datenauslieferer. Anwendungen werden hier nicht wie beim Apache als Module geladen, sondern müssen als eigenständige Prozesse, über FastCGI erreichbar, bereitgestellt werden. Um PHP bereitzustellen kann PHP-FPM verwendet werden. Über FastCGI kann es entweder über einen Unix-Socket oder per TCP/IP angesprochen werden und mit Nginx kommunizieren.

Um die Serverlast im Auge zu behalten kennt man unter Apache die vom Modul mod_status bereitgestellt Statusseite. Unter Nginx kann mit stub_status on; ebenfalls an entsprechender Stelle eine Statusseite eingeschaltet werden. Für PHP-FPM müssen mehre Einstellungen vorgenommen werden.

Mit dem WordPress-Plugin Cachify steht eine Lösung zur Verfügung, die ein einfaches Zwischenspeichern von dynamisch erzeugten Webseiten bietet. Die Inhalte können mit unterschiedlichen Methoden zwischengespeichert werden. Unterstützt werden APC, Disk, DB und Memcached (nur mit Nginx). Da ich hier Nginx einsetze, bietet sich Memcached als schnellste Variante an. Wie Cachify und Nginx dann zu konfigurieren sind kann im Cachify-Wiki nachgelesen werden.

Die erfolgreiche Konfiguration läßt sich einfach überprüfen: es wird an das Ende der jeweiligen Webseite ein HTML-Kommentar von Cachify eingefügt. Ist dieser im Quelltext der Seite vohanden, dann wurde die Seite aus dem Cache, bei mir also von Nginx/Memcached ausgeliefert.

Nach der Umstellung auf Zertifikate von Let’s Encrypt hat sich das Ranking des Blogs in Bezug auf sichere Transportverschlüsselung gegenüber der vorherigen Konfiguration weiter erhöht. Gründe dafür sind der verwendete Signaturalgorithmus SHA256 für den Zertifikatskey und der Einsatz von HSTS.

HSTS kann in Nginx ganz einfach mit einer einzigen Zeile an entsprechender Stelle aktivieren werden:

add_header Strict-Transport-Security max-age=31536000;

Dadurch wird festgelegt, dass der Browser für den angegebenen Zeitraum (hier 31536000 Sekunden = 365 Tage) ausschließlich verschlüsselte Verbindungen mit dieser Domain nutzt. Da diese Einstellung im Browser des Besuchers gespeichert wird, sollte vor der Aktivierung unbedingt getestet werden, ob auf der Webseite auch wirklich nur Ressourcen eingebunden sind, die per HTTPS abgerufen werden können.

Munin wird dazu verwendet, Laufzeitwerte über verschiedene Dienste oder Rechner zu sammeln und diese statistisch in Grafiken auf einer eigenen Webseite aufzubereiten. Bei Über- oder Unterschreiten eines Grenzwertes können entsprechende E-Mails versenden. Die gesammelten Daten werden rollierend in RRDs (Robin-Round-Database) festgehalten.

In der Standardkonfiguration wird in den meisten RRDs nur jeweils ein Wert gespeichert. Das ergibt z.B. bei 10 Hosts á 20 zu speichernden Werten 200 RRDs, die von Munin alle 5 Minuten (dem Standard-Abfrageintervall) fast gleichzeitig geschrieben werden. Diese Häufung von IOs, zumal sie nicht gestreckt über den gesamten Zeitraum sondern punktuell auftritt, kann für große Installationen schnell zum Problem werden. Im Folgenden wird eine Methode vorgestellt, wie diese Festplatten-Last um den Faktor 10 gesenkt werden kann.

Mit dem Service von Let’s Encrypt steht die Möglichkeit zur Verfügung, kostenlos Zertifikate für Webserver zu erhalten um die Webseite per HTTPS, also verschlüsselt, zugänglich zu machen. Für den Webserver Apache kann das Zertifikat automatisch erzeugt, signiert und installiert werden. Für Nginx ist in der Let’s Encrypt-Installation zwar ein Modul enthalten, dieses ist nach eigenen Angaben jedoch noch nicht für den produktiven Einsatz ausgelegt.

In einer Standard-WordPress-Installation ist es sehr einfach möglich, die Namen der unterschiedlichen Autoren herauszubekommen. An die URL der Seite hängt man dazu ein /?author=1, /?author=2 usw. an. Diese Informationen könnten von mißliebigen Zeitgenossen unter Umständen dann dazu verwendet werden, Logins mit nun bekannten korrekten Benutzernamen auszuprobieren.

Verhindern kann man den Zugriff auf die Namen der unterschiedlichen Autoren (und damit auch die Information, ob es evtl. nur einen einzigen Autor im Blog gibt) mit dem Umschreiben der URL.

So merkwürdig der Titel klingt, denn im allgemeinen möchte man die Seiten seiner Webseite ja eher gerne in den Google-Suchmaschinen-Index aufgenommen sehen, so ergibt sich doch ab und an die Anforderung, eine Seite oder z.B. Bilder nicht in den Google-Index aufnehmen zu lassen.

Verzeichnisse mit robots.txt ausschließen

Früher konnte man das relativ einfach durch einen Eintrag in der Datei robots.txt, welche im Hauptverzeichnis der Webseite liegen muss regeln. Zu beachten ist jedoch, dass die Crawler der verschiedenen Suchmaschinen sich nicht daran halten müssen. Google jedenfalls beachtete den Inhalt dieser Datei. So z.B. konnte man mit folgendem Eintrag ein bestimmtes Verzeichnis ausschließen:

Ich wollte auf einem komplett neu aufgesetzten Raspbian FusionPBX entsprechend der Anleitung installieren. Verwenden wollte ich die vorgeschlagene Konfiguration mit Nginx und Sqlite. Leider schlägt nach ein paar Stunden Kompilieren der letzte Konfigurationsschritt im Webbrowser fehl, da das Timeout in Nginx für FastCGI-Skripte (in dem Fall PHP) in der Standardeinstellung zu kurz eingestellt ist. Der kleine Raspi müht sich nach Kräften, schafft es aber nicht in der vorgegebenen Zeit. Die Einrichtung im Webbrowser schlägt mit “Gateway-Timeout” fehl. Abhilfe schafft der Eintrag

Wer Memcached zusammen mit Nginx oder PHP einsetzt, der möchte in der Konfigurationsphase sicher einmal debuggen, ob die Einstellungen auch korrekt sind und Daten an Memcached übergeben und von dort gelesen werden. Leider bietet Memcached kein Kommandozeilentool, mit dem man sich einfach Statistiken zu Memcached anzeigen lassen könnte. Es existiert zwar ein Munin-Plugin, welches eine einfache Grafik der Memcached-Auslastung anzeigt, Inhalte sieht man dort jedoch auch nicht.

Mit phpMemcachedAdmin ist es möglich, umfangreiche Statistiken zu Memcached aufbereitet auf einer Webseite zu erhalten. Es lassen sich mehrere Memcached-Server verwalten und auch Inhalte zu einzelnen Keys abrufen. Außerdem können Kommandos an den Memcached-Server geschickt werden.