Derzeit sind die Themen Datenschutz und Erfassung von IP-Adressen ja wieder sehr präsent. Im Fokus der Diskussion steht dabei zwar Analyse-Software Google Analytics, aber betroffen sind natürlich auch alle anderen Statistik-Anwendungen, die IP-Adressen der Webseitenbesucher erfassen. Ich habe mir daher auch Gedanken gemacht, welche Daten ich eigentlich erfasse.

Derzeit setze ich als Webserver lighttpd ein, auf diversen Webseiten laufen Google Analytics sowie Piwik zur Erfassung von Statistiken. Die beiden letztgenannten Anwendungen habe ich so konfiguriert, dass die IP-Adressen der Besucher anonymisiert werden. Für beide Dienste stehen entsprechende Anleitungen bereit.

Bei lighttpd wird standardmäßig ein Access-Log geschrieben. Die entsprechenden Einstellungen sind auf der Webseite dokumentiert: Lighttpd – Docs:ModAccessLog

Ich habe die Standardeinstellungen in meiner Konfigurationsdatei dahingehend angepasst:

accesslog.format = "%V %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\""

Vor dem %V war vorher ein %h zu finden, das für die Speicherung der Remote-Host-Adresse verantwortlich war. Nun enthalten meine Serverlogs keine IP-Adressen mehr.

Leider stand ich erneut bei einer Software vor dem Problem, dass sie für den Apache2 und dessen Erweiterung mod_rewrite geschrieben wurde. Dieses Mal ging es um conjoon, einen vielversprechenden persönlichen Informations-Manager bzw. eine Groupware. conjoon bietet momentan einen sehr gelungen Webmail-Client sowie RSS-Reader. Leider wird momentan nur POP3 unterstützt – ich warte schon sehnsüchtig auf die IMAP-Erweiterung.

Mit folgenden Einstellungen habe ich conjoon dann doch noch zur Zusammenarbeit mit dem lighttpd-Webserver bewegen können:

url.rewrite-final = (
".*\.(mp3|swf|js|ico|gif|jpg|png|css)" => "$0",
"blank\.html" => "$0",
"^/install/(.*)$" => "$0",
"^index\/redirect.+$" => "index.php",
".$" => "/index.php"
)

Das ist sicherlich nicht optimal (gerade die vorletzte Zeile sollte durch die letzte doch überflüssig sein, oder?), aber wie gesagt: Es funktioniert.

Genau das Problem hatte ich in den letzten Tagen wiederholt, nachdem ich auf meinem virtuellen Server Exim als MTA eingerichtet habe und auch noch SpamAsssassin und ClamAV hinzukonfiguriert habe.

In einem Forum habe ich dann einen schönen Hinweis darauf gefunden, wie man mit lsof eine übersichtliche Ausgabe erhält, welcher Prozess wie viele Dateien geöffnet hat:

lsof -n|grep -oE '^[a-z]+'|sort|uniq -c|sort -n

Auf diese Weise konnte ich SpamAssassin als Übeltäter ausmachen und die Anzahl der Child-Prozesse beschränken. Den Virenscanner ClamAV benötige ich ebenfalls nicht unbedingt, also habe ich ihn auch wieder deaktiviert. Ich bin zwar immer noch recht nah an der Obergrenze, die mir mein Hoster erlaubt, aber der Server läuft jetzt stabil.

Wenn man sein Typolight für Suchmaschinen etwas schicker gestalten möchte, klickt man im Backend bei den Einstellungen das Häkchen “URLs umschreiben” an:

Mit dieser Option können Sie TYPOlight dazu veranlassen, statische URLs ohne “index.php” zu erzeugen (z.B. alias.html anstatt index.php/alias.html). Dieses Feature benötigt das Apache Modul mod_rewrite!

Da ich den Apache nicht mehr benutze, musste ich meine Lighttpd-Konfiguration folgendermaßen anpassen:

url.rewrite-final = (
"^/typolight/(.*)$" => "$0",
"^/(.*\.php)" => "$0",
"^/(.*\.html)$" => "/index.php",
)


Damit läuft’s!

Update am 23. September 2011:

Mittlerweile heißt das CMS nicht mehr Typolight, sondern Contao. Ich habe es gerade mit einer frischen Installation und folgenden Rewrite-Rules getestet – das Ergebnis hier: http://contao.misterfu.de/

url.rewrite-final = (
"^/(contao|stats|typolight|javascript|system|images|plugins|tl_files)/(.*)$" => "$0",
"^/(.*\.css|.*\.xml|.*\.php)" => "$0",
"^/(.*)$" => "/index.php$0",
"^/(.*\.html)" => "/index.php",
)


Schon vor längerer Zeit habe ich einmal etwas über die Apache-Alternative lighttpd gelesen. Nachdem alle meine heutigen Versuche, den alten Indianer wieder auf flottes Pferd zu setzen, gescheitert sind, habe ich kurzerhand mal das Leichtgewicht ausprobiert. Die Perfomance hat sich dadurch wieder etwas verbessert – leider auf Kosten einiger liebgewonnerer Bekannter wie z.B. mod_rewrite. Natürlich gibt es auch ein Rewrite für den neuen HTTP-Server – für WordPress sieht das folgendermaßen aus:

$HTTP["host"] == "blog.misterfu.de" {
url.rewrite-final = (
"^/(wp-admin|wp-includes|wp-content|gallery2)/(.*)" => "$0",
"^/(.*\.php)" => "$0",
"^/(.*)$" => "/index.php/$1"
)
}

Auf so einem Testserver kann man das ja einfach mal ausprobieren. Und falls ich doch etwas entdecken sollte, was auch mit etwas Bastelei nicht funktioniert, liegt der Apache immer noch bereit und kann sofort reaktiviert werden.

Die Geschwindigkeit ist auf jeden Fall deutlich gestiegen – die Verzögerung nach dem Klick auf einen Link ist jedoch noch zu spüren. Der vServer scheint wohl einfach am Ende seiner Möglichkeiten zu sein…