PageSpeed-Cache leeren mit SSH-User – ohne root
sk, den 2. Februar 2016
Wir zeigen, wie man den PageSpeed-Cache leeren kann, mit einem SSH-User ohne Root-Einsatz. Denn root ist normalerweise notwendig dafür.
Für die Optimierung der Auslieferung von Webseiten hat Google ein Plugin für alle gängigen Webserver erstellt: PageSpeed. Was für den produktiven Betrieb eine nützliche Erweiterung ist, bremst Entwickler-Umgebungen aus. Will man den Cache leeren, muss man das mit einem unhandlichen Befehl in der SSH-Shell tun. Wir vereinfachen das.
Um den Cache von PageSpeed zu leeren, kann man sich mit einer leicht umständlichen Zeile behelfen:
# touch `grep "^ *ModPagespeedFileCachePath" /etc/apache2/mods-enabled/pagespeed.conf | awk ' { print $2; } ' | sed 's/"//g'`/cache.flush
Das Vorgehen funktioniert, hat aber zwei Nachteile: Es ist einerseits nicht sehr bequem einzugeben, andererseits wird dafür ein Administrator-Zugang benötigt – und wenn sich der Nutzer „root“ nicht direkt in SSH einloggen darf, muss man ein zweites Passwort eingeben, weil der normale Anwender in den Cache-Ordner nicht schreiben darf.
Ein Script schafft Abhilfe
Die Lösung ist relativ einfach, benötigt wird ein Script. Wir nennen es aufgrund eines ziemlich erbärmlichen Wortspiels „stuhlgang“ und packen es, um es global verfügbar zu machen, in den Ordner /bin – wobei noch alles mit root-Rechten geschehen muss:
# touch /bin/stuhlgang
# chmod +x /bin/stuhlgang
Der Inhalt von „stuhlgang“ sieht entsprechend wie folgt aus:
#/bin/bash
touch grep "^ *ModPagespeedFileCachePath" /etc/apache2/mods-enabled/pagespeed.conf | awk ' { print $2; } ' | sed 's/"//g'/cache.flush
Fortan kann der PageSpeed-Cache für Apache mit dem einprägsamen Befehl „stuhlgang“ geleert (flush – daher auch der Wortwitz) werden, jedoch derzeit nur als root. Der Name hat aber zumindest den Vorteil, dass bei einer relativ gängigen Debian-Installation die Eingabe von „stu“ gefolgt von der Tab-Taste ausreicht, um die Command-Completion den Rest ergänzen zu lassen.
Normalnutzer erlauben
Ruft man das Script nun als normaler Anwender auf, erhält man einen Fehler, der auf einen Schreibfehler hindeutet. Der Grund dafür ist darin zu finden, wie das Script arbeitet: Es legt im Cache-Ordner von PageSpeed eine Datei namens „cache.flush“ an, die PageSpeed anweist, beim nächsten Zugriff den Cache zu leeren (inkl. „cache.flush“) – und wer sie anlegen will, benötigt logischerweise Schreibrechte in diesem Ordner.
Um herauszufinden, welcher Ordner überhaupt der richtige ist, muss der Befehl geringfügig modifiziert werden. Aus dem „touch“ ganz am Anfang muss ein „echo“ gemacht werden:
# echo `grep "^ *ModPagespeedFileCachePath" /etc/apache2/mods-enabled/pagespeed.conf | awk ' { print $2; } ' | sed 's/"//g'`/cache.flush
Dies gibt dann beispielsweise diese Zeile aus:
/var/cache/mod_pagespeed//cache.flush
Da wir wissen, dass „cache.flush“ eine Datei ist, die angelegt werden muss, ist der Ordner, der Schreibrechte benötigt, /var/cache/mod_pagespeed/. Die einfachste Methode dafür ist, einfach allen Nutzern Schreibrechte für diesen Ordner zu geben:
# chmod +w /var/cache/mod_pagespeed/
Ab sofort müsste jeder Benutzer in der Lage sein, „stuhlgang“ aufzurufen.
Schreibrechte für alle? Ist das nicht gefährlich?
Kurze Antwort: Klares Jaein! Lange Antwort: Im Prinzip schon, aber es gibt zwei Faktoren, die bei der Überlegung erwogen werden sollten. Einerseits sollte man zunächst einmal zusehen, dass kein unbefugter per SSH und Konsorten auf den Server kommt. Ist diese Hürde überwunden, hat man definitiv ganz andere Sorgen als dass „jemand“ den Cache von PageSpeed manipulieren kann. Andererseits gibt es gerne einmal Sicherheitslücken in Web-Software, die Remote-Inclusions erlaubt. Hierfür gibt es aber ebenfalls Gegenmittel, beispielsweise in Form von open_basedir, das nur einen Zugriff innerhalb des eigenen Ordners erlaubt. Zudem erlauben wir mit der obigen Zeile quasi nur das Erstellen neuer Dateien oder Ordner. Die vorhandenen gehören per Default dem Webserver-User (www-data bei uns) – das bedeutet, dass mit oder ohne diese Änderung eine unsichere Web-Software (ohne sonstige Gegenmaßnahmen) den Inhalt des Caches manipulieren könnte. Von daher: Potenziell kann von dem Vorgehen ein gewisses Risiko in Bezug auf Sicherheit ausgehen – andererseits sind Kompromisse nicht unnormal, wenn es um Sicherheit vs. Bequemlichkeit geht und man kann das Risiko mit geeigneten Gegenmaßnahmen gering halten.