Ich habe nun die Lösung für meine Installationen gefunden:

Im Plugin-Verzeichnis (“wp-content/plugins/stats/“) befindet sich eine Datei namens “.htaccess“. Hierin steht eine Anweisung an den Webserver Apache, dass die Dateiendung “.swf” für Zugriffe ohne Einschränkung erlaubt ist. Es handelt sich um eine Überschreibung der Apache-Konfiguration. Das ist soweit auch vollkommen ok und erst mal unbedenklich.

Das Problem: Ich nutze für meine WordPress-Installationen einen Apache-Webserver mit einzelnen VirtualHosts. In diesen VirtualHost-Konfigurationen ist ein Überschreiben von Zugriffsberechtigungen nicht erlaubt. Der Webserver loggt daher beim Aufruf der “Site Stats” die Meldung: “[...] wp-content/plugins/stats/.htaccess: allow not allowed here [...]” und die Darstellung des Diagramms im Browser wird abgebrochen.

Lösung 1:

Die einfachste und schnellste Variante besteht darin, die Datei “wp-content/plugins/stats/.htaccess” entweder zu löschen oder den Inhalt Zeile für Zeile mit “#”-Zeichen aus zu kommentieren. Danach sollte das Site-Stats-Diagramm sofort wieder funktionieren. Leider wird es so sein, dass die gelöschte bzw. bearbeitete Datei beim nächsten Update des Plugins wieder vorhanden sein wird, somit müsste die Aktion dann wiederholt werden. Oder:

Lösung 2:

In der Apache-Konfiguration kann ein Directory-Eintrag angelegt werden (entweder im VirtualHost oder in der Hauptkonfiguration), der die “Allow”-Aktion der .htaccess-Datei erlaubt:

<Directory “/pfad/zu/wordpress/wp-content/plugins/stats”>
AllowOverride Limit
<Directory>

Nun muss noch ein Neustart des Webservers erfolgen. Mit dieser Lösung taucht das Problem auch nach einem Update des Plugins nicht mehr auf.

UPDATE:

Mittlerweile existiert eine neue Version des Plugins (1.6.3). In dieser Version ist die “.htaccess”-Datei entfernt worden. Damit sollte das Problem beseitigt sein.

Preface:

Ich betreibe u.a. einen DHCP-Server, einen Proxy-Server und einen Webserver.
Was liegt also näher, als diese drei Dienste miteinander zu koppeln, mit dem Ziel, die Information “Proxy-Server” automatisch zu verteilen, anstatt jedem Browser und jedem System im Netzwerk manuell einen Proxy-Server einzutragen. Außerdem betreibe ich auf verschiedenen Systemen “netz-interne” Webserver, die ich direkt aufrufen möchte, ohne den Proxy zu verwenden.

Hier also die Beschreibung des Zusammenspiels:

Ich arbeite hier mit Diensten unter Linux. Das Ergebnis (die automatische Verteilung der Proxy-Konfiguration) funktioniert für Linux und Windows. Möglicherweise bzw. bestimmt funktioniert das auch für den Mac, aber ich mache hier keine Aussagen zu etwas, das ich nicht selbst getestet habe.

Ziel:

• Verwendung eines Proxy-Servers für alle oder ausgewählte Systeme/Browser
• Subnetz-abhängige Verwendung des Proxy-Servers

Voraussetzungen:

• Linux-System (z.B. openSUSE)
• DHCP-Server (ISC)
• Proxy-Server (z.B. Squid)
• Webserver (z.B. Apache)

Wie diese Voraussetzungen geschaffen werden, ist nicht Teil dieser Anleitung. Ich gehe davon aus, dass diese Dienste eingerichtet sind und funktionieren. Mein Webserver heißt “wpad.mein.privates.netz.de” und der Proxy-Server läuft auf Port 3128 und trägt den Namen “proxy.mein.privates.netz.de”.

Erstellung der WPAD-Datei:

Diese Datei enthält einen “Fahrplan” für den Browser, damit er entscheiden kann, ob und wenn ja, welchen Proxy-Server er verwenden soll. Eine genaue Beschreibung des Aufbaus und der Funktionen einer WPAD-Datei findet sich hier.

Meine sieht folgendermaßen aus:

Das bedeutet: kein Proxy für den eigenen Rechner und kein Proxy für Webserver im eigenen Subnetz.

Diese Datei unter dem Namen “wpad.dat” (case-sensitive) auf dem Webserver abgelegt. Wichtig ist an dieser Stelle, dass die Datei direkt im Web-Root und nicht in einem Unterverzeichnis liegt

Konfiguration des DHCP-Servers:

Ich verteile den Proxy-Verweis für das gesamte Subnet, wer möchte, kann das natürlich auch anders (z.B. pro Host) machen.

Hier die Auszüge aus der /etc/dhcpd.conf:

Ganz besonders wichtig ist das Leerzeichen bei der Pfadangabe “…/wpad.dat ”.

Es existiert unter Umständen das Problem, dass der Internet Explorer beim Verarbeiten des Pfades das letzte Zeichen abschneidet und so die Datei nicht mehr gefunden werden kann. Das Leerzeichen am Ende stellt also einen Workaround dar.

Da nicht alle Browser die DHCP-Optionen abfragen können, ist es sinnvoll, im Nameserver einen Host namens “wpad” anzulegen, dessen Webserver die WPAD-Datei bereitstellt. Somit können “DHCP-unfähige” Browser dennoch eine Proxy-Konfiguration beziehen, denn der Hostname “wpad” wird dabei als Standard verwendet. Leider ist es mit dieser Variante nicht möglich, für Subnetze oder gar einzelne Hosts verschiedene WPAD-Dateien anzubieten. Der gemeinsame Nenner wäre hier das Domain-Suffix des Clients.

Ich habe mittels Wireshark zwei bei mir installierte Browser überprüft:
Der Internet Explorer 7 lässt sich Lease-Informationen vom DHCP-Server geben, um dort die entsprechende WPAD-Option zu erhalten, falls gesetzt. Der Firefox 2.0.0.8 sucht nach einem Gerät mit dem Namen “wpad” im Netz. Dabei werden die auf dem lokalen PC eingetragenen DNS-Suchsuffixe nacheinander abgearbeitet.

Browser-/Systemkonfiguration:

Nun muss dem Browser / dem System nur noch beigebracht werden, dass er die Proxy-Einstellungen automatisch beziehen soll. Im Internet-Explorer wird das über das Aktivieren der Option “Automatische Suche der Einstellungen” bei “Extras -> Internetoptionen… -> Verbindungen -> LAN-Einstellungen” erledigt. Beim aktuellen Firefox geschieht das über “Einstellungen -> Erweitert -> Netzwerk -> Einstellungen (Verbindung) -> Die Proxy-Einstellungen für dieses Netzwerk automatisch erkennen”.

Nachdem DHCP-Server und Browser neu gestartet wurden, kann man nun überprüfen, ob alles wie erwartet funktioniert. Der erste Schritt wäre, eine beliebige URL aufzurufen und im Webserver-Log zu überprüfen, ob die Datei “wpad.dat” erfolgreich vom surfenden Rechner abgerufen wurde. Ist das der Fall, kann man nun anhand des Proxy-Logfiles erkennen, ob der Proxy oder eine direkte Verbindung vom Browser genutzt wird. Dazu werden einfach interne und externe URLs aufgerufen.

Wichtiger Hinweis: Wenn die WPAD-Datei nicht abgerufen werden konnte, arbeiten Mozilla, Firefox und Internet-Explorer stillschweigend mit einer direkten Verbindung.

Nachwort:

Falls jemand diese Anleitung gebrauchen kann/konnte oder einen Fehler gefunden hat, würde ich mich über ein Feedback freuen.

UPDATE:

Bei Problemen mit WPAD und RSS-Feeds könnte eventuell diese Seite helfen.