W3Perl

W3Perl verdaut neben Webserver Protokollen auch Logdateien von FTP-, Mail- und Squid-Servern [14] . Die erzeugten Statistiken bieten durchweg Standardkost auf Webalizer-Niveau, wobei die Ergebnisseiten eine etwas unübersichtliche Navigation mitbringen. Immerhin gibt es kontextsensitive Tooltipps, deren Hilfetexte jedoch meist auf Wikipedia-Einträge verweisen. Im Gegensatz zur Konkurrenz führt W3Perl alle auf dem Server ausgeführten Skripte in einer separaten Statistik. Mit ihrer Hilfe fallen Einbruchsversuche schneller ins Auge. Interessant und übersichtlich ist auch die Darstellung der Dateien in ihrer Verzeichnishierarchie aus Abbildung 8 .

Abbildung 8: W3Perl bereitet seine Statitiken auf mehrere Arten auf, versteckt diese aber hinter einer etwas unübersichtlichen Oberfläche.

Wie der Name bereits andeutet, besteht W3Perl aus mehreren Perl-Skripten und setzt somit den passenden Interpreter voraus. Grafiken generiert der Analyzer mit Hilfe des Werkzeugs Fly, dessen Haltbarkeitsdatum schon im Jahre 2001 abgelaufen ist. Damit nicht genug, verlangt W3Perl nach der noch einmal älteren Version 1.6.5, da alle Nachkommen um die Ausgabe von GIF-Grafiken kastriert wurden. Immerhin ließ sich Fly unter dem aktuellen Open Suse 10.3 ohne Probleme mit einem einfachen »make« übersetzten. Eine Installation im System ist übrigens nicht zwingend notwendig und offenbar von den Fly-Machern auch nicht vorgesehen. Wer noch die Perl Module »Geo::IP « oder »Geo::IPfree« spendiert, dem nennt W3Perl die Länder, aus denen die protokollierten Anfragen stammten. Ebenfalls optional ist »MIME::Lite« , über das W3Perl auf Wunsch die fertigen Auswertungen per E-Mail an den Administrator sendet.

Steht die Umgebung, kann der Admin das Quellcode-Paket von W3Perl auspacken. Im neuen erhaltenen Unterverzeichnis »w3perl« öffnet er dann die Datei »install.pl« . In ihr passt er die ersten drei Parameter an die eigenen Gegebenheiten an: Ganz am Anfang der Datei den Pfad zum Perl-Interpreter, hinter »$pathcgi« und »$pathw3perl« steht der Pfad zum »w3perl« -Verzeichnis. Stimmt soweit alles, ruft er die modifizierte » install.pl« an der Kommandozeile auf.

Im nächsten Schritt kopiert er die Beispielkonfiguration »config-onebigfile.pl« nach »config.pl« . Letztere öffnet er mit einem Texteditor und passt dort die folgenden Einstellungen an: In die Anführungszeichen hinter »$logfile_format« gehört ein Kürzel, welches das Format des Logfiles angibt. Welche Formate W3Perl kennt, steht direkt in den Kommentaren darüber. Passt keiner der angebotenen Standards, bastelt der Administrator unter »$struct_logfile« mit den angebotenen Platzhaltern sein eigenes Format zusammen. Hinter »$path« gehört das Verzeichnis, in dem später die Auswertung in Form einer Flut von HTML-Dateien landet. Den vollständige Pfad zum »W3Perl« -Verzeichnis stellt er hinter »$pathinit« (dabei unbedingt den Schrägstrich am Ende nicht vergessen, also beispielsweise »/home/tim/w3perl/« ). Unter »$fileroot« gibt man das Verzeichnis an, in dem die Logfiles lagern. Direkt darunter entfernt er hinter »$errorlog« den Text in den Anführungszeichen. Die Variable »$prefixlog« nennt den Namen der auszuwertenden Logfiles. Abschließend kommt noch hinter »$FLY« der Pfad samt Binärdatei zum gleichnamigen Werkzeug, also beispielsweise »/home/tim/fly-1.6.5/fly« ). Nachdem alle Änderungen vorgenommen wurden, darf er endlich die eigentliche Auswertung per »cron-w3perl.pl -a« auf der Kommandozeile anstoßen.

Die Installation auf dem Server läuft nach den gleichen Schritten ab. Je nachdem, welche Rechte der Webspace-Provider gestattet, muss man in der Konfigurationsdatei noch weitere Einstellungen anpassen. Sofern eine CGI-Schnittstelle zur Verfügung steht, darf man den Inhalt der Konfigurationsdatei sogar bequem über ein Web-Frontend festlegen.

AWStats

Das Werkzeug AWStats verdaut nach eigenen Angaben die Logfiles aller großen Web-, Wap-, Proxy-, Streaming-, FTP- und Mail-Server [15] . Wie könnte es anders sein, ist auch dieser Analyzer ein Perl-Skript. Mehr als einen passenden Interpreter setzt er erfreulicherweise nicht voraus. Die erzeugten Statistiken reihen sich in ihrem Umfang zwischen Lire und W3Perl ein ( Abbildung 9 ). Alle wichtigen und üblichen Informationen, wie eine Liste der häufigsten Suchbegriffe oder der verwendeten Browser, sind zwar vorhanden, darüber hinausgehende Interpretationshilfen sucht man jedoch vergeblich.

Abbildung 9: Die Ergebnisse von AWStats sind nicht ganz so übersichtlich angeordnet, wie bei anderen Kollegen.

Nach dem Entpacken des AWStats-Pakets startet der Anwender das Skript »awstats_configure.pl« aus dem »tools« -Verzeichnis. Die erste Frage nickt er mit einem »y« ab. Anschließend fragt das Installationsprogramm nach der Konfigurationsdatei des Webservers »httpd.conf« , aus der es die Information über das Log-Format übernimmt. Sofern AWStats nur auf dem heimischen Rechner laufen soll, tippt man hier »none« ein. Im anderen Fall modifiziert AWStats die vorgegebene »httpd.conf« , um sich so selbst die Ausführung als CGI-Skript zu gestatten. Damit die Änderungen wirksam werden, startet es anschließend den Apache-Server neu.

Im nächsten Schritt fragt das Skript, ob es eine neue Konfigurationsdatei erstellen soll. Dies beantwortet der Anwender mit »y« und tippt einen so genannten Profilnamen ein. Dies darf prinzipiell ein beliebiger Text sein, gemäß den AWStats-Konventionen wählt er hier jedoch am besten den Domainnamen der eigenen Site. Anschließend teilt er AWStats noch mit, wo es die Konfigurationsdatei ablegen soll. Hier übernimmt ist möglichst die Vorgabe zu akzeptieren, da man sich ansonsten durch die Konfiguration von AWStats wühlen muss. Die am Ende der Einrichtung angezeigten Befehle starten als Cronjobs AWstats periodisch.

Damit existiert eine einfache Konfigurationsdatei »awstats.<§§I>domainname<§§I>.conf« . Diese öffnet der Anwender mit einem Texteditor und sucht als erstes nach der mit »LogFile=« beginnenden Zeile. Dahinter gehört der vollständige Pfad zum Logfile. Wie schon beim Kollegen Analog darf man ihn mit den bereitstehenden Platzhaltern dynamisch gestalten: So wird ein »mylog.log.%MM-0« im November automatisch zu »mylog.log.11« .

Nach dem Verzeichnis ist das Dateiformat an der Reihe. Hinter »LogFormat« folgt eine Ziffer für das in den Kommentaren vorgegebenes Dateiformat. Alternativ darf kann der Admin mit Hilfe der angebotenen Platzhalter auch sein eigenes Format zusammenbauen. Weiter geht es zur Zeile »DirData« . Hinter dessen Gleichheitszeichen packt er das Verzeichnis, in dem die Ergebnisse der Auswertung im HTML-Format laden sollen.

Nach dem Speichern wirft der Sysop AWStats im Unterverzeichnis »wwwroot/cgi-bin« auf der Kommandozeile an:

perl awstats.pl -update -config=↩
<!-- START: including template: design/standard/templates/content/datatype/view/ezxmltags/emphasize.tpl (design:content/datatype/view/ezxmltags/emphasize.tpl) -->
Domainname
<!-- STOP: including template: design/standard/templates/content/datatype/view/ezxmltags/emphasize.tpl (design:content/datatype/view/ezxmltags/emphasize.tpl) -->

Domainname steht dabei für den Namen, den der Sysadmin während der Konfiguration vergeben hat und den auch die Konfigurationsdatei in ihrem Mittelteil trägt. Damit liest AWStats zunächst besagte Konfigurationsdatei ein, berechnet die Statistiken und schiebt das Ergebnis in einer zunächst noch unleserlichen Form in das zuvor bestimmte Verzeichnis. Aus ihr muss man abschließend noch via

perl awstats.pl -output -staticlinks ↩
-config=domainname > ausgabe.html

einen lesbaren Report generieren, wobei die Statistik in der HTML-Datei »ausgabe.html« landet.

comments powered by Disqus
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Ausgabe /2023