Seit ein paar Jahren lasse ich meine Server von Uptimerobot.com überwachen. Kürzlich habe ich entdeckt, dass der Monitoring-Service mittlerweile auch öffentliche schaltbare Statusseiten anbietet. Daher habe ich meine selbst gebastelte Statusseite abgeschaltet und wollte stattdessen das schönere Angebot von Uptimerobot nutzen. Die Statusseiten sind über Adressen nach dem Schema stats.uptimerobot.com/<ID> erreichbar, also z.B. https://stats.uptimerobot.com/rk3R0IDJq. Die Adressen sind schlecht zu merken. Viel lieber hätte ich etwas einfacheres, wie z.B. status.trashserver.net. Deshalb kann man die Statusseite auch mit einer eigenen Domain betreiben, indem man im DNS-Record für die jeweilige Domain auf den Uptimerobot-Server verweist. Allerdings schließt das HTTPS aus, denn Uptimerobot müsste dann die Zertifikate für meine Domain besitzen. Aber auch dafür habe ich eine Lösung gefunden:
Uptimerobot Statusseite mit eigener Subdomain und HTTPS nutzen
Let’s Encrypt ACME Challenge Responses sammeln [Nginx]
Im Manual Mode des Let’s Encrypt Referenzclients muss jede Domain über eine individuelle Datei im Unterverzeichnis /.well-known/acme-challenge/ derselben Domain bestätigt werden. Bei vielen Domains bremst das Wechseln zwischen den Verzeichnissen und das erstellen der notwendigen Verzeichnisstruktur den Arbeitsablauf. Damit die Domains schneller bestätigt werden können, sammle ich alle ACME Responses in einem gemeinsamen Verzeichnis /var/www/acme-challenges/. Egal, welche Domain gerade bestätigt werden soll: Die Datei zur Bestätigung wird hier abgelegt und steht dennoch unter der gewohnten URL bereit. Und so geht’s:
PHP-Anwendungen unter eigenen Benutzern ausführen
Kaum einer meiner Server läuft nur mit einer einzigen Anwendung. Der Webserver, auf dem dieser Blog läuft, beherbergt nicht nur thomas-leister.de, sondern auch noch zwei andere Blogs und weitere PHP-basierte Webdienste, die ich zur Verfügung stelle. Aus Sicht eines Hackers ein lohnenswertes Ziel: Wird über eine PHP-Anwendung wie z.B. einen schlecht gepflegten WordPress-Blog Zugriff auf das Dateisystem des Servers erlangt, kann der Hacker nicht nur die unsichere Webapplikation angreifen, sondern auch alle anderen Anwendungen, die unter dem PHP-User laufen. Aus diesem Grund ist es sinnvoll, die PHP-Anwendungen etwas voneinander abzuschotten, sodass ein Angreifer von der einen PHP-Anwendung aus keine andere PHP-Anwendung beeinträchtigen kann. Dies erreicht man, indem man für jede Anwendung einen eigenen User anlegt, der PHP ausführt. Die Verzeichnisrechte werden so gesetzt, dass nur der jeweils zugedachte PHP-User Zugriff auf die Anwendungsdateien hat und keine weiteren Änderungen im Dateisystem vornehmen kann.
Anleitung für Let’s Encrypt: Kostenlose TLS Zertifikate für alle
Das Let’s Encrypt Projekt (hinter dem unter anderem Mozilla, Facebook und Cisco als Sponsoren stecken) ist gestern in den Public Beta Betrieb übergegangen. Von nun an können nach belieben kostenlose TLS (aka SSL)-Zertifikate für die eigenen Domains erstellt werden. Für den Erhalt eines Zertifikats sind nur wenige, einfache Schritte erforderlich, die ich im Folgenden erkläre:
Nginx: Passwortschutz für Unterverzeichnis
In einigen Fällen ist es sinnvoll, den Zugriff auf vestimmte Verzeichnisse einer Website nur für bestimmte Nutzer zu erlauben. Die einfachste Möglichkeit für einen Passwortschutz ist die sog. HTTP Base Auth. Dabei wird dem Benutzer beim besuch einer bestimmten URL vom Browser ein Eingabefenster für Benutzername und Passwort angezeigt. Stimmen die Daten überein bzw sind im System vorhanden, wird der Zugriff ermöglicht – ansonsten wird er abgewiesen.
Nginx Proxy für TVHeadend mit Unterverzeichnis
Meine TVHeadend Instanz Zuhause sollte über das Internet erreichbar werden. Hinter dem DSL Router ist ein Webserver erreichbar, den ich dafür als Proxy zu meinem TVHeadend-Server nutzen will. Über den Webserver laufen allerdings noch ein paar andere Dienste, sodass ich TVH nicht das Rootverzeichnis überlassen will. Das THV Webinterface soll stattdessen über ein Unterverzeichnis „/tv/recorder“ erreichbar sein, also z.B. so: https://server.tld/tv/recorder.
TVHeadend läuft auf dem Server mit der IP 192.168.2.111 auf Port 9981. Die Konfiguration von Nginx kann z.B. so aussehen:
Nginx: Anderes Rootverzeichnis für Unterverzeichnis
In der Nginx Konfiguration kann neben dem default Rootverzeichnis „root“ auch für jedes Unterverzeichnis ein root-Pfad gewählt werden. Das ermöglicht es z.B. für http://server.tld/ die Dateien unter /var/www zu lagern, während sich die Dateien für http://server.tld/webuser/ unter /home/webuser/ befinden. Realisieren lässt sich das über die „alias“ Direktive:
server {
server_name server.tld;
listen 80;
listen [::]:80;
root /var/www;
location /webuser {
alias /home/webuser;
}
}
Natürlich muss dabei sichergestellt werden, dass das Zielverzeichnis für den User, unter dem Nginx läuft, zugänglich ist.
Fehlerbehebung: Plötzliche PHP-FPM Abstürze mit Nginx
Auf meinen Server setze ich mittlerweile nur noch den Nginx-Webserver ein. PHP gibt es dafür nicht als Modul (so wie bei Apache), sondern es läuft als Extra-Prozess mit Socket, über den Nginx mit dem PHP-Prozess kommuniziert. In den letzten Monaten hatte ich immer wieder Probleme mit PHP. Der PHP-FPM Prozess verabschiedete sich immer wieder spontan und ohne Fehler in den Logs. Nach viel Recherche bin ich schließlich auf den rettenden Tipp gekommen: Man solle doch mal APC für PHP deaktivieren.
Dazu wird in der Datei /etc/php5/fpm/conf.d/20-apcu.ini die Zeile „extension=apcu.so“ mit einem vorangestellten Semikolon „;“ einfach auskommentiert und der PHP-FPM Service neu gestartet.
Seit der Deaktivierung von APC habe ich keine PHP-Abstürze mehr und der Webserver tut seinen Job wieder zuverlässig.