WAMP - Windows, Apache, mySQL, php

Da ich mehrere Webhosting-Pakete bei Strato besitze und die dort zur Verfügung stehenden Stats (ab PowerWeb) kaum brauchbar sind, empfiehlt sich die zusätzliche Installation von awstats. Man kann zwar nicht direkt von awstats aus auf seine LogFiles zugreifen, aber man kann diese zumindest herunterladen. Allerdings scheinen die Logs nicht immer ganz sauber chronologisch zu sein, denn auch die aktuelle awstats-Version 6.6 wertet selbst bei auf einzelne Tage gesplitteten Logs ganz offensichtlich nicht immer alles aus. Falls da jemand ein kleines Tool kennt, welches Apache-Logs bei falscher Sortierung neu und richtig sortieren kann, bitte ich um eine Info per Kommentar ;)

Jetzt steht man vor der Wahl: entweder installiert man sich AWStats (ähnlich der unten beschriebenen Installation) auf dem jeweiligen WebHosting-Paket und schiebt die Logfiles zur Analyse wieder alle einzeln hoch (nach cgi-data, das kostet durchaus eine Menge Upload-Zeit) oder man löst das Problem auf einem anderen und idealer Weise lokalen Webserver. Ich habe hier zwar noch 2 Linux-Testrechner (sogar mit installiertem XAMP), möchte meine Logs aber lieber auf meinem Windows-Laptop auswerten, denn der steht nun mal direkt vor meiner Nase :) Also muss man sich alle benötigten Pakete für Windows beschaffen:

  • Apache externerLink (aktuell 2.2.4) - das msi-Paket nehmen und ruhig auch mal einen Blick auf die “important notes” zur Win32-Installation werfen! Da stehen einige Tipps, wie man die relativ häufig auftretenden Probleme mit Virenscannern, Firewalls etc. umschiffen kann
  • PHP externerLink (aktuell 5.2.3) - den Installer auswählen, ist ein msi-Paket
  • mySQL externerLink (aktuell 5.0.41 oder 6.0 beta) - ein msi-Paket, da muss man ein wenig herumnavigieren, um zum Ziel (Community-Download ohne Eingabe von persönlichen Daten) zu kommen. mySQL ist für die awstats-Installation zwar eigentlich überflüssig, aber der Vollständigkeit des WAMP-Systems zu Liebe installiere ich es trotzdem.
  • Perl externerLink (aktuell 5.8.8.820) - wieder das msi-Paket ziehen
  • AWStats externerLink (aktuell 6.6) - in diesem Fall nimmt man die zip-Datei

Insgesamt sind die 3 XAMP-Pakete, Perl und AWStats in den oben angegebenen Versionen ca. 65 MB groß. Installiert wird in der Reihenfolge der Downloads, also erst der Apache, dann PHP (dort Apache 2.2.x oder entsprechend anderen Webserver angeben und als der Pfad zur http.conf sollte Programme/Apacheverzeichnis/Apache2.2/conf sein), danach mySQL und anschließend noch Perl. Also theoretisch, praktisch hatte das von mir gezogene mySQL-Paket irgendwie einen Fehler und brach wärend der Installation mit einer Fehlermeldung ab. Nun gut, ich brauche mySQL vorerst nicht unbedingt, installiere ich es halt später bei Bedarf nach … Die Grundinstallation geht schnell und läuft (mal von meinem mySQL-Problem abgesehen) absolut problemlos - zumindest unter Windows XP, bei Vista könnte das wegen der immer noch bei mancher Software vorhandenen Kompatibilitätsprobleme durchaus noch anders aussehen. Nun, wer Windows Vista zum derzeitigen Zeitpunkt installiert hat, steht eh auf basteln und hat offensichtlich viel Geduld für aufwendige Adventures. Da kann man dann auch ruhig mal einen WAMP probieren - probieren geht über studieren ;) Da ich keinen immer ereichbaren Webserver wollte, wählte ich bei der Apache-Installation die Option “nur angemeldeter User nach manuellem Start”. Das spart ordentlich Ressourcen, wenn man den Server nur gelegentlich benötigt. Um den Server zu starten, geht man über das Startmenü in die vom Apache erzeugte Struktur und dort auf Control Apache Server - Start Apache in Console. Die Funktion des Apache kann man anschließend testen, indem man in die Adresszeile des Browsers ein http://localhost:8080 eingibt.

Da es sich um eine lokale Installation ohne besondere Ansprüche handelt, muss an der Apache-Konfiguration (httpd.conf) kaum etwa geändert werden. Wichtig ist nur, dass man in dem Bereich, wo eine Menge zur Funktionsweise von Perl eine der dort angebotenen Alternativen eingerichtet wird. Entweder sorgt man dafür, dass alle Dateien mit der Endung .pl von Windows automatisch an die perl.exe zur Ausführung übergeben werden oder man paßt in jeder(!) benötigten Perl-Datei den Pfad zum Interpreter an oder man entfernt das Kommentarzeichen (die Raute) vor ScriptInterpreterSource registry - in meinen Augen die einfachste Lösung. Ohne diese Änderung sind unter Windows sonst keine Perlscripte ausführbar und der Apache liefert eine 500er Fehlermeldung. Sinnvoll ist es außerdem, in der httpd.conf den unter Listen angegebenen Port auf 80 zu stellen und bei Bedarf auch die lokale IP-Adresse davor anzugeben. Wer möchte, kann natürlich auch ein anderes Verzeichnis zum DocumentRoot machen, um sich für lokale Webentwicklung etc. nicht so tief durch die Verzeichnisstruktur wühlen zu müssen. Auch wenn man dies nicht tut, muss man sich die drei wichtigen Pfade heraussuchen, weil man diese für die AWStats-Installation benötigt. Es handelt sich dabei um folgende Einträge in der httpd.conf (wer nichts ändert, findet die auch so im Apache-Verzeichnis):

  • DocumentRoot - in diesem Fall “htdocs”, bei vielen Installationen alternativ “httpdocs”
  • ScriptAlias /cgi-bin/
  • Alias /icons/

Jetzt geht man in das AWStats-Paket und kopiert einfach den kompletten Inhalt (classes, css und js sind nicht unbedingt erforderlich) des Verzeichnisses /wwwroot/ ins Apache-Verzeichnis, dabei kann der Inhalt des Verzeichnisses icon sinnvoller Weise im Apache-Standard-Verzeichnis icons untergebracht werden. Leider muss man bei dieser Vorgehensweise die Anpassungen für die AWStats-Konfigurationsdatei(en) per Hand vornehmen und die Pfade entsprechend einstellen, weil das automatische Installationsscript aus dem Tools-Verzeichnis, welches man sonst per perl awstats_configure.pl aufrufen würde, ein Verzeichnis namens wwwroot/ erwartet. Allerdings ist dieses Perl-Script auch nicht sooo wichtig, wenn man die Apache-Standardpfade für AWStats verwendet und einige der benötigten Pfadangaben innerhalb der awstats.domainname.conf direkt und eben ohne die sonst durch entsprechende automatische Einträge in die httpd.conf zur Verfügung stehenden Aliase vorgibt.

Als Hilfestellung zur Anpassung einer eigenen awstats.domainname.conf kann man folgenden um die Kommentare und einige nicht geänderte Einstellungen verkürzten Auszug aus meiner awstats.proteino.de.conf hier verwenden:

LogFile="/temp/log"
SiteDomain="proteino.de"
DNSLookup=0
DirData="../cgi-data"
DirCgi="../cgi-bin"
DirIcons="../icons"
AllowToUpdateStatsFromBrowser=1
AllowFullYearView=3
DefaultFile=""
SkipFiles="REGEX[^/blog/wp-content] REGEX[^/blog/wp-admin]"
LoadPlugin="decodeutfkeys"
LoadPlugin="hashfiles"

Das Verzeichnis cgi-data muss natürlich noch per Hand angelegt werden. Der Parameter LogFile=”…” muss übrigens bei einer Installation auf einem Strato-Server einen Pfad in der Form /home/strato/http/power/web4/xx/xx/xxxxxx/htdocs/…” enthalten. Das ist der lokale Pfad innerhalb des serverinternen Stratoverzeichnisbaums. Diesen Pfad erhält man mit Hilfe der Umgebungsvariablen, die man z.B. auch per php mit phpinfo(); abfragen kann. Dieser absolute Pfad wird dort auch für die Parameter DirData, DirCgi und DirIcons benötigt. Da man beim Hosting keinen direkten Zugriff auf die LogFiles hat, erübrigt sich die Pfadangabe bei MiscTrackerUrl. Über den Parameter HostAliases kann man bei Bedarf auch Subdomains (wie www.) oder weitere zu integrierende Domainnamen angeben. Die Angabe von wegzufilternden Domains mittels SkipHosts=”…” oder die Filterung von bestimmten Dateien über SkipFiles=”…” ist manchmal ganz hilfreich, um wertlose Informationen aus des Stats fern zu halten. Dafür ist oben ein Bsp. angegeben, wie man einige der durch WordPress erzeugten WebServer-Zugriffe aus den Logs filtert.

Ab jetzt sind die AWStats-Statistiken unter http://localhost/cgi-bin/awstats.pl?config=domainname abrufbar. Will man eine automatische Aktualisierung der Stats (was bei den manuell eingespielten Logfiles unnötig ist), so muss man im Taskplaner (Scheduler) folgenden Befehl, evtl. mittels einer extra erstellten Batch-Datei, ausführen lassen:

perl awstats.pl - update -config=domainname

Im hier vorliegenden Fall der manuellen Einspielung der Logfiles macht dies wenig Sinn und man benötigt auf jeden Fall den oben bereits angegebenen Parameter AllowToUpdateStatsFromBrowser=1.

4 Reaktionen zu “WAMP - Windows, Apache, mySQL, php”

  1. admin

    Falls irgendwas an obiger Anleitung nicht so ganz stimmig sein sollte, hinterlaße bitte einen Kommentar - die Dokumentation ist mir nämlich jetzt irgendwie zu groß geworden, um nochmal alles haarklein zu kontrollieren ;)
    Jedenfalls hoffe ich, damit nicht nur denjenigen weitergeholfen zu haben, die AWStats lokal unter Windows laufen lassen wollen, sondern auch den zahlreichen Strato-Kunden, denn genau für die dortige Problematik hatte ich in der Vergangenheit trotz mehrmaliger Suchen keinerlei Anleitungen finden können.

  2. Strato PowerWeb

    Ich habe wegen fehlender mod_rewrite gekündigt, der Aufwand den man betreiben muss um das umzubiegen, steht in keinem Verhältnis zum Nutzen eines Blogs. Das geht bei anderen Hostern ohne Probleme.

  3. admin

    Es ging hier zwar vordergründig um WAMP mit awstats und nicht um das mod_rewrite-Problem in den Strato-Webhosting-Paketen, aber das ist zweifelsfrei neben den verwursteten Logfiles auch recht nervig ;) Auf die mod_rewrite-Problematik und vor allem die schwere Geburt bei der Entfernung des überflüssigen www vor dem Domainnamen war ich bereits im ersten Beitrag dieses Blogs eingegangen. Das ganze ist schon wieder ein Jahr her und ganz offensichtlich hatte ich bisher immer noch kein ausreichend großes Bedürfnis danach, diese Domain hier von Strato abzuziehen, obwohl es dafür reichlich Gründe geben würde. Letztendlich kann man (mit einigem Zeitaufwand) die meisten Probleme irgendwie umschiffen und es läuft dann auch alles. Auch nach einem Umzug würde ich die komplette Namens-Struktur beibehalten und somit würde mir ein mod_rewrite höchstens bei neuen Subdomains oder Unterverzeichnissen mit eigenem CMS etwas bringen. Zur Not kann man Permalinks ohne den index.php-WorkAround und ohne mod_rewrite auch indirekt realisieren, wenn das verwendete CMS die Aufrufsyntax auswertet (so wie z.B. WordPress es auch macht) und man per Fehlerseite zum CMS weiterleitet. Allerdings sollte man um später noch in Suchmaschinen aufgefunden werden zu können, den Fehlercode im Header wieder durch den “erfolgreich”-http-Header mit dem Code 200 überschreiben ;) Bei der Einrichtung der beiden CMS für diese Domain fehlte mir damals einfach noch die Idee zum Überschreiben des Headers - meien Experimente mit der Fehlerseite hatte ich halt wegen dem falschen Header zu früh beendet und deshalb gibt’s hier überall die index.php-Lösung. Die Suchmaschinen stören sich nicht daran, die User auch nicht, also was soll’s …

  4. Michael

    Ich habe den ganzen Scheiß bei Strato gekündigt und habe mir bei Hostgator in den USA einen Account geholt. x-mal soviel Leistung, weniger Kosten und ein Service, den ich noch nie erlebt habe! Das ist der Wahnsinn !

Einen Kommentar schreiben