PageSpeed-Cache leeren mit SSH-User – ohne root

Code-Beispiel
Code-Beispiel

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 von Webseiten hat Google ein Plugin für die gängigen Webserver Apache und Nginx erstellt: PageSpeed. Beispielsweise werden Javascript- und CSS-Dateien zusammengefasst, erst nachträglich geladen. Bilder werden komprimiert, Scripte zusammengefasst, und vieles mehr. Was für den Produktiv-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.

PageSpeed-Cache leeren per SSH

Um den Cache von PageSpeed zu leeren, kann man sich mit einer Zeile behelfen:

touch `grep "^ *ModPagespeedFileCachePath" /etc/apache2/mods-enabled/pagespeed.conf | awk ' { print $2; } ' | sed 's/"//g'`/cache.flush

Das obige Beispiel funktioniert, hat aber zwei Nachteile: Es ist nicht bequem einzugeben, andererseits wird dafür ein Administrator-Zugang benötigt. Wenn sich der Nutzer “root” nicht direkt in SSH einloggen darf, muss man ein zweites Passwort eingeben, weil der normale Anwender nicht in den Cache-Ordner schreiben darf.

Shell-Script zum Leeren des PageSpeed-Cache

Die Lösung ist relativ einfach. Benötigt wird ein Script. Man kann es nennen wie man möchte. Wir nennen es aufgrund eines Wortspiels “stuhlgang” (von “flush” the “cache”) und packen es, um es global verfügbar zu machen, in den Ordner /bin. Dies muss alles mit root-Rechten geschehen:

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

Den PageSpeed-Cache für Apache kann man ab sofort mit dem einprägsamen Befehl “stuhlgang” leeren. Zunächst funktioniert das weiterhin nur als root.

Normalnutzer erlauben

Ruft man das Script als normaler Anwender auf, erhält man eine Fehlermeldung, der auf einen Schreibfehler hindeutet. Der Grund dafür ist die Arbeitsweise des Scripts: Es legt im Cache-Ordner von PageSpeed eine Datei namens cache.flush an. Sie weist PageSpeed an, beim nächsten Zugriff den Cache zu leeren (inkl. “cache.flush”). Wer sie anlegen will, benötigt Schreibrechte in diesem Ordner.

Um herauszufinden, welcher Ordner der richtige ist, muss der Befehl geringfügig modifiziert werden. Immer noch als root-Nutzer machen wir aus dem touch ganz am Anfang ein echo:

echo `grep "^ *ModPagespeedFileCachePath" /etc/apache2/mods-enabled/pagespeed.conf | awk ' { print $2; } ' | sed 's/"//g'`/cache.flush

Dies gibt exemplarisch eine Zeile wie /var/cache/mod_pagespeed//cache.flush aus. 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, normale Nutzer die Datei erstellen zu lassen, ist, einfach allen Nutzern Schreibrechte für diesen Ordner zu geben. Dies geschieht mittels 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?

Ja, aber es gibt zwei Faktoren, die erwogen werden sollten. Einerseits sollte man zusehen, dass kein Unbefugter per SSH auf den Server kommt. Ist diese Hürde überwunden, hat man ganz andere Sorgen als jemanden, der den Cache von PageSpeed leeren kann. Andererseits gibt es Sicherheitslücken in Web-Software, die Remote-Inclusions erlaubt. Hierfür gibt es Gegenmittel, beispielsweise in Form von open_basedir, das nur einen Zugriff innerhalb des eigenen Ordners erlaubt. Zudem erlauben wir mit der obigen Zeile nur das Erstellen neuer Dateien oder Ordner. Die vorhandenen gehören per Standardeinstellung dem Webserver-User (bspw. www-data). Das bedeutet, dass mit oder ohne diese Änderung eine unsichere Web-Software (ohne sonstige Gegenmaßnahmen) den Inhalt des Caches manipulieren könnte.

Potenziell kann ein gewisses Risiko entstehen. Nur Kompromisse sind nicht unnormal, wenn es um Sicherheit vs. Bequemlichkeit geht. Mit geeigneten Gegenmaßnahmen kann man das Risiko gering halten.

Geschrieben von:
Geschrieben am: 02.02.2016
Zuletzt aktualisiert: 02.02.2016
Zurück zu: Tipps und Tricks
Was sagst Du dazu? Kommentieren!
Special-Event mit iPhone 5se am 15. März?
Gene Munster: 4-Zoll-iPhone nicht im März

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>



Zuletzt kommentiert