Logwatch der Loganalysierer: Ein Beispiel mit Lighttpd

Zum Thema Monitoring, Serverüberwachung und Intrusion Detection System (IDS) habe ich mir in den letzten Wochen ein paar Gedanken gemacht und neue Software ausprobiert. Ich habe das Thema noch nicht abgeschlossen und teste von Zeit zu Zeit noch das ein oder andere Programm an, was mir bei dieser Aufgabe für meinen Server helfen könnte. Heute stelle ich Logwatch näher vor.

Zur Zeit benutze ich Monit zur Überwachung von Prozessen wie Lighttpd oder den Spieleservern. Es kam in der Vergangenheit bei OpenArena z.B vor, dass der Server wegen eines unbekannten Fehlers unregelmäßig gecrasht ist. Dank Monit wird der Server automatisch neugestartet.

Für den langfristigen Trendverlauf bei Systemressourcen oder Benutzung der Spieleserver verwende ich Munin, womit die Werte grafisch anschaulich aufbereitet werden.

Die Mehrzahl der Daten wird natürlich in Logdateien gespeichert. Da die Menge an Informationen manuell nicht in annehmbarer Zeit zu überprüfen ist, braucht es einen Loganalysierer, der die Daten für Menschen lesbar aufbereitet und im Idealfall nur die „wichtigen“ Informationen herausfiltert.

Ein bekannter Loganalysierer heißt Logwatch, den ich am längsten kenne und seit Anfang an für den Server benutze. Speziell für Berichte über die Vorgänge mit der Firewall gibt es aber auch noch FwLogwatch. Ebenfalls angeschaut habe ich mir Logcheck, Swatch und Tenshi. Snort steht auf jeden Fall noch auf der Todo-Liste und mit Tiger als Auditor habe ich auch schon gute Erfahrungen gemacht.

Logwatch

aptitude install logwatch

Ein großer Pluspunkt von Logwatch ist, dass es direkt nach der Installation einfach funktioniert und täglich eine Zusammenfassung als Textmail an Root und die externe Adresse schickt, sofern man zuvor einen Mailserver eingerichtet hat.

Logwatch ist in der Standardeinstellung auf einen niedrigen Detaillevel eingestellt. Die Werte reichen von 0 (low) über 5 (medium) bis 10 (high). Grundsätzlich werden die Logs der letzten 24 Stunden analysiert, wozu der Cronjob in /etc/cron.daily/00logwatch aufgerufen wird. Diese Zeitsteuerung lässt sich wie schon beschrieben über das Verschieben von 00logwatch in den entsprechenden Cron-Ordner oder durch die Bearbeitung der Crontabs ändern.

Die Reichweite der Loganalyse kann auch per Option direkt an Logwatch übergeben werden. Weitere Hinweise dazu finden sich mit logwatch –range Help.

Konfigurationsbeispiel mit Lighttpd

Für einen tiefergehenden Einblick in die Materie empfehle ich einen Blick in Howto-Customize-Logwatch.gz und Readme.Debian in /usr/share/doc/logwatch/ zu werfen. Das Konzept der Konfiguration ist dort ausführlich beschrieben.

Prinzipiell finden sich in den Unterverzeichnissen logfiles und services in /usr/share/logwatch/default.conf die Regeln, welche Logdateien analysiert werden sollen und Parameter, die den Output näher bestimmen. Die tatsächliche Arbeit verrichten aber die Skripte in /usr/share/logwatch/scripts.

Die zentrale Konfigurationsdatei ist logwatch.conf und befindet sich zusammen mit ignore.conf in /usr/share/logwatch/default.conf. Schon rein aus formalen Gründen habe ich aber alle Dateien dort unangetastet gelassen, da Debian selbst die Werte im Verzeichnis /usr/share/logwatch/dist.conf/ überschreibt und jede individuelle Einstellungen wie gewohnt in /etc/logwatch/ festgelegt wird.

Die Unterverzeichnisse in /etc/logwatch/ spiegeln die Verzeichnisstruktur in /usr/share/logwatch wider. Man muss also nur die modifizierten Dateien für Logfiles und Services dort ablegen.

In meinem Fall habe ich den Service http angepasst, der standardmäßig auf die Analyse von Apache ausgerichtet ist. Mit wenigen Handgriffen funktioniert er aber auch für Lighttpd.

Kopieren

/usr/share/logwatch/default.conf/logfiles/http.conf –> /etc/logwatch/conf/logfiles/

/usr/share/logwatch/default.conf/services/http.conf –> /etc/logwatch/conf/services/

Anpassen

Meine http.conf für logfiles.

Meine http.conf für services.

Die Logdateien für meinen Lighttpd-Webserver liegen immer in /var/log/lighttpd/linuxiuvat.de/. Mit

LogFile = lighttpd/linuxiuvat.de/*access.log.1

wird der relative Pfad zu /var/log und meinen Logdateien festgelegt, wobei es noch drei weitere Zeilen in dieser Form gibt, die auf die anderen Logdateien verweisen.

Die zweite http.conf Datei ist der sogenannte Filter oder Service, der auf die Logdateien angewendet wird. Ich habe den Titel auf „Lighttpd“ gesetzt und den Detaillevel auf 10 erhöht. Dadurch wird der Standard von 0 überschrieben und die Ausgabe von Lighttpd deutlich „lauter“. Der Rest beschränkt sich darauf Parameter auszukommentieren, die nützlich sein können, z.B.

$HTTP_USER_DISPLAY = „$field{http_rc} >= 400“

womit alle HTTP-Fehlermeldungen >= 400 angezeigt werden.

override.conf

In /etc/logwatch/conf kann man die Datei override.conf anlegen, womit sich die globalen Einstellungen aus logwatch.conf überschreiben lassen. Ich brauchte z.B. nicht den Output des Service Iptables.

logwatch: Service = „-iptables“

Mit dem Schlüsselbegriff logwatch: wird die Veränderung eingeleitet, danach folgt der Name der Variable und der Wert. Weitere Ideen, was sich manipulieren lässt, finden sich in logwatch.conf.

Fazit

Das Kopieren und Editieren der Konfiguration ist bei Logwatch erst einmal Gewöhnungssache. Der Vorteil liegt darin, dass die Originaldateien unangetastet bleiben und man alles ordentlich dort hat, wo es hingehört, in /etc. Wer viele Veränderungen vornehmen muss und diese auf mehrere Server anwendet, sollte besser über eine Neukompilierung des Pakets nachdenken.

Mir gefällt Logwatch sehr gut, da es bisher die anderen Methoden gut ergänzt. Logwatch ist ein Teil der Lösung aber eben nicht alles. Für mich ist eine tägliche E-Mail-Benachrichtigung ausreichend. Außerdem ist die Standardkonfiguration sehr gut. Wer noch mehr Kontrolle und andere Voreinstellungen bevorzugt, sollte sich Logcheck anschauen. Dort wird man anfangs sogar stündlich informiert und kann durch Reguläre Ausdrücke festlegen, was man sehen möchte oder eben nicht.

Lighttpd: Webserver-Konfiguration mit SSL und Authentifizierung

Im folgenden Beitrag geht es mal nicht um die Stärken und Schwächen verschiedener Webserver, sondern um die Konfiguration des Webservers für mein Spieleserver-Projekt linuxiuvat.de, das weiter in der Entstehung ist und bei dem ich fast ausschließlich auf statische Inhalte setze. Wer selbst am überlegen ist, ob er einen Ubuntu-LTS- oder Debian-Server in Zukunft aufsetzen und einen Webserver betreiben möchte, findet hier vielleicht die richtigen Informationen.

Der Artikel kann nicht die gesamte Dokumentation zu Lighttpd ersetzen. Wer aber meine kommentierte Konfigurationsdatei liest und die Abschnitte zu den verschiedenen Modulen dazu in Beziehung setzt, sollte einen guten Überblick bekommen, wie man mit ein paar Handgriffen einen ressourcenschonenden Webserver mit SSL und Authentifizierung für einen eigenen Webauftritt gestalten kann.

Warum Lighttpd?

Für ein privates Projekt mit fast ausschließlich statischen Inhalten ist Lighttpd bestens geeignet. Sein Speicherverbrauch ist äußerst gering, was ihn ideal für eine vServer-Umgebung macht. Im Regelfall zeigt mir htop nach einer Basisinstallation an, dass Lighty ungefähr 1% von den verfügbaren 225 MB des vServers für sich beansprucht und auch mit ein paar zusätzlichen Modulen steigt dieser Wert kaum an.

Lighttpd hat in der Vergangenheit bei viel größeren Projekten bewiesen, dass er sich ideal zum Ausliefern von statischen Inhalten eignet. Außerdem ist die Dokumentation ausgezeichnet und die bedingte Konfiguration empfand ich als übersichtlich und logisch.

Das weitere Angebot an freien Webservern ist wirklich groß. Einen guten Überblick verschafft z.B.

aptitude search '~shttpd'

Nginx ragt hier als weitere sehr gute Alternative heraus. Doch alle müssen sich mit der Referenz, Apache, messen lassen. Die Wahl hängt wie immer von den eigenen Ansprüchen ab, weswegen man nicht pauschal einen Webserver zum Non plus ultra erklären kann.
Wer es wirklich genügsam haben möchte, sollte sich Busybox merken, denn das bringt neben vielen UNIX-Werkzeugen auch einen eigenen Webserver mit! 🙂

Installation

aptitude install lighttpd

Wichtige Fakten

  • Zentrale Konfigurationsdatei: /etc/lighttpd/lighttpd.conf
  • Zusätzliche Konfiguration: /etc/lighttpd/conf-available/
  • Aktivieren bzw. Deaktivieren von Modulen: lighty-enable-mod Name_des_Moduls bzw. lighty-disable-mod Name_des_Moduls. Konfigurationsdateien werden von /conf-available/ nach /conf-enabled/ verlinkt und somit aktiviert.
  • Einziger Benutzer: linuxiuvat
  • Standard-Webserver-Root: /var/www/server
  • Ohne SSL: Symlink von /var/www/linuxiuvat.de -> /home/linuxiuvat/linuxiuvat.de
  • Mit SSL: Zwei Subdomains munin.linuxiuvat.de und stats.linuxiuvat.de
  • Standardmodule: mod_access, mod_alias, mod_compress, mod_redirect, mod_expire
  • Zusätzliche Module: mod_ssl, mod_cgi, mod_auth, mod_status, mod_accesslog

Meine lighttpd.conf

Meine eigene lighttpd.conf in kommentierter Fassung. Fragen, Anregungen oder Kritik bitte jederzeit in die Kommentare posten.

lighttpd.conf

Konfiguration

Virtuelle Hosts

Um virtuelle Hosts zu verwalten, bietet Lighttpd verschiedene Möglichkeiten an. Für größere Projekte empfiehlt sich das schlichte und effektive mod_simple_vhost oder das verbesserte mod_evhost. Wer selbst zum Webhoster werden möchte und zahlreiche Domains verwalten muss, sollte sich die datenbankgestützte und programmierbare Lösung namens mod_mysql_vhost genauer anschauen.

Für kleine Projekte mit einer überschaubaren Anzahl von Domains und Subdomains ist aber Lightys bedingte Konfiguration vollkommen ausreichend.

Hauptseite ohne SSL

Die Inhalte werden auf der Hauptseite unverschlüsselt ausgeliefert, wozu die $SERVER[„socket“]-Bedingung Anwendung findet. Das Dokumenten-Wurzelverzeichnis wird in das Home-Verzeichnis des Benutzers linuxiuvat verlinkt. Neue Inhalte werden dort eingestellt. Die Host-Bedingung prüft, ob entweder www.linuxiuvat.de oder nur linuxiuvat.de aufgerufen wurde und führt danach alle Anweisungen im Konfigurationsblock aus. Zusätzlich zur Datei access.log, die später noch vorgestellt wird, ist hier noch der Pfad zu einer angepassten 404-Fehlerseite zu sehen, sowie der Pfad zur error.log.

$SERVER["socket"] == "134.0.24.218:80" {
	$HTTP["host"] =~ "^(www.)?linuxiuvat.de$" {
		server.document-root = "/var/www/linuxiuvat.de"
		server.error-handler-404 = "/e404.htm"
		accesslog.filename = "/var/log/lighttpd/linuxiuvat.de/access.log"
		server.errorlog = "/var/log/lighttpd/linuxiuvat.de/error.log"
    }
}

Mit der folgenden Bedingung lässt sich verhindern, dass die Webseite direkt über die Eingabe der IP-Adresse aufgerufen werden kann, wobei das Modul mod_access Anwendung findet.

$HTTP["host"] =~ "134.0.24.218" {
	url.access-deny = ( "" )
}

mod_cgi

Die einzige CGI-Datei, die ich z.Z. benutze, befindet sich im Verzeichnis /cgi-bin/. Sie kommt zum Einsatz, wenn jemand einen Kommentar in meinem mit Chronicle erzeugten Newsblog hinterlassen möchte.

Das Modul wird mit

lighty-enable-mod cgi

aktiviert.

$HTTP["url"] =~ "^/cgi-bin/" {
	cgi.assign = ( "" => "/usr/bin/perl" ) 
}

mod_accesslog

Mit dem Modul mod_accesslog werden alle Anfragen an den Webserver mitgeloggt. Aktiviert wird es mit

lighty-enable-mod accesslog

1. /etc/lighttpd/conf-available/10-accesslog

server.modules += ( "mod_accesslog" )
accesslog.filename = "/var/log/lighttpd/access.log"

Damit die Datei access.log für jeden Host einzeln angelegt wird, kann man sie wie bei Lighttpd üblich in eine bedingte Konfiguration einbinden.

accesslog.filename = „/var/log/lighttpd/linuxiuvat.de/access.log“

mod_expire

Das Modul mod_expire hilft dabei statische Inhalte aggressiv zu cachen, d.h. Bilder, CSS- und Javascriptdateien erhalten bei der Übertragung an den Webbrowser ein Verfallsdatum bis zu dem der Browser die Dateien aus seinem Cache lädt anstatt sie neu vom Server anzufordern. Das spart Bandbreite und führt zu schnelleren Ladezeiten.

Aktivieren mit

lighty-enable-mod expire

Die Bedingung lässt sich z.B. so schreiben, dass nur Dateien mit einer bestimmten Dateiendung zwischengespeichert werden sollen. In diesem Fall beträgt die Verfallszeit sieben Tage vom ersten Aufruf an.

	$HTTP["url"] =~ ".(jpg|gif|png|css|js)$" {
	     expire.url = ( "" => "access 7 days" )
	}

Natürlich kann man die Bedingung auch so schreiben, dass die Dateien nur aus zwei verschiedenen Verzeichnissen gecached werden sollen.

	$HTTP["url"] =~ "^/img/|/stats/oa/icons/" {
	     expire.url = ("" => "access 7 days") 
	}

Mit Hilfe des Firefox-Plugins Live-HTTP-Headers oder mit curl kann man schnell feststellen, ob tatsächlich der richtige HTTP-Header verschickt wird.

curl -I http://linuxiuvat.de/img/openarena.jpg

Quelle: Forum von nixcraft.com.

mod_ssl

Zum Aktivieren einer verschlüsselten SSL-Verbindung per HTTPS genügt wieder ein

lighty-enable-mod ssl

Das SSL-Zertifikat habe ich mir selbst ausgestellt, was ich für kleine Projekte, bei denen man der einzige Betrachter der verschlüsselten Seite ist auch empfehlen kann. Wer jedoch eine Shop-Seite zusammenzimmert sollte seine Kunden wenn möglich nicht mit einer Warnmeldung im Browser verschrecken und ein „richtiges“ Zertifikat kaufen. 🙂

Als Superuser:
openssl req -new -x509 -keyout linuxiuvat.de.pem -out linuxiuvat.de.pem -days 365 -nodes

Die Pem-Datei wurde nach /etc/lighttpd/ssl/linuxiuvat.de/linuxiuvat.de.pem kopiert und die Dateirechte aus Sicherheitsgründen mit chmod 400 eingeschränkt.

1. /etc/lighttpd/conf-available/10-ssl.conf

Ich habe die Konfiguration getrennt und den Teil, der sich um die SSL-Engine selbst dreht in der 10-ssl.conf belassen. Wichtig ist hier nur die richtige Adresse für den Socket einzutragen, also eure IP-Adresse und den Port des Webservers. Alternativ kann man auch :443 oder 0.0.0.0:443 schreiben, wenn man möchte, dass der Webserver auf allen Interfaces Anfragen entgegennimmt. Die Schreibweise muss aber überall die gleiche sein.

$SERVER["socket"] == "134.0.24.218:443" {
     ssl.engine = "enable"
     ssl.pemfile = "/etc/lighttpd/ssl/linuxiuvat.de/linuxiuvat.de.pem"

     ssl.cipher-list = "ECDHE-RSA-AES256-SHA384:AES256-SHA256:RC4:HIGH:!MD5:!aNULL:!EDH:!AESGCM"
     ssl.honor-cipher-order = "enable"
}

2. /etc/lighttpd/lighttpd.conf

Durch die bedingte Konfiguration sind die beiden Subdomains munin.linuxiuvat.de und stats.linuxiuvat.de nur über HTTPS zu erreichen. Es wurde jeweils das Dokumenten-Wurzelverzeichnis geändert, so dass es auf den Standardausgabepfad von Munin und Awffull zeigt. Die Statusseite ist über https://munin.linuxiuvat.de/status zu erreichen und wird durch das Modul mod_status aktiviert.

$SERVER["socket"] == "134.0.24.218:443" {
		$HTTP["host"] =~ "(^|.)munin.linuxiuvat.de$" {
			server.document-root = "/var/cache/munin/www"
			status.status-url = "/status"
		}
		$HTTP["host"] =~ "(^|.)stats.linuxiuvat.de$" {
			server.document-root = "/var/www/awffull/"
		}
}

mod_auth

Das Authentifizierungsmodul ist notwendig, um den Zugriff auf einzelne Verzeichnisse einzuschränken. In meinem Fall genügt es, dass ich die Munin- und Awffull-Statistiken anschauen kann. Das Modul mod_auth wird mit

lighty-enable-mod auth

aktiviert. Es gibt zwei verschiedene Methoden sich zu authentifizieren – Basic und Digest. Je nach Methode existieren unterschiedliche Backends, wie die Passwörter aufgebaut und gespeichert werden. Ich habe mich für Digest und htdigest entschieden, wodurch das Passwort nicht in Klartext übertragen wird und als MD5-Hash abgespeichert wird. Alle Methoden sind dennoch nur dann wirklich sicher, wenn das Passwort über eine verschlüsselte Verbindung übertragen wird.

1. /etc/lighttpd/conf-available/10-auth.conf

server.modules += ( "mod_auth" )

auth.backend = "htdigest"
auth.backend.htdigest.userfile = "/etc/lighttpd/.passwd"
auth.debug = 2

$HTTP["host"] =~ "(^|.)munin.linuxiuvat.de$" {
 auth.require = ( "" =>
    (
    "method" => "digest",
    "realm" => "privat",
    "require" => "valid-user"
    ),

 )
}

Auth.debug=2 ist sehr gesprächig, aber hilfreich, wenn man mehr über erfolgreiche und nicht erfolgreiche Loginversuche wissen möchte. Die versteckte Passwortdatei .passwd mit den benötigten Inhalten lässt sich wie folgt erstellen. Der „Realm“ kann beliebig gewählt werden.

htdigest -c /etc/lighttpd/.passwd 'privat' Bob

Das Programm htdigest befindet sich im Paket apache2-utils und wird nur für diese eine Aufgabe benötigt. Danach hat nur noch der Benutzer Bob mit dem zuvor eingegebenen Passwort Zugriff auf das Verzeichnis, wobei die gesamte Verbindung gegenüber Dritten per SSL abgesichert ist.

mod_status

Mit mod_status gibt es Auskunft über Uptime, Anfragen pro Sekunde und aktive Verbindungen, kurz zusammengefasst also über den Status des Webservers. Die HTML-Seite ist schlicht und übersichtlich. Um die Daten per Munin mit einem Graphen zu visualisieren kann man noch ein ?auto an die URL anhängen, wodurch die Ausgabe als Text dargestellt wird. Hierzu in einem anderen Artikel mehr.

Das Modul wird mit

lighty-enable-mod status

aktiviert. Die Zeile

status.status-url = „/status“

muss wie in der Konfiguration gezeigt innerhalb der bedingten Host-Konfiguration eingefügt werden.

Was sonst noch?

Lighttpd bietet noch weit mehr Möglichkeiten und Module. Das sind zur Zeit aber alle, die ich für mein Projekt und dieses Beispiel verwende. Man sollte im Hinterkopf noch mod_evasive und die Variablen

server.kbytes-per-second
connection.kbytes-per-second

behalten, wenn man den Traffic auf dem Webserver besser steuern möchte.

Für Lighttpd gilt: Fast jedes Problem lässt sich mit der bedingten Konfiguration lösen.

Links

Logdateien von Lighttpd auswerten mit Awstats und Awffull

Neben dem ausgezeichneten Piwik existieren zur Darstellung von Benutzerstatistiken und Auswertung von Logdateien noch eine Reihe von sogenannten Log-Analysierern. Da ich die Installation von PHP und MySQL möglichst vermeiden wollte, habe ich mir zwei altbekannte Helfer aus diesem Bereich näher angeschaut. Hier stehen nur noch einmal die wichtigsten Einstellungen, die ich verändert habe und ein kurzes Fazit.

Awstats

Das war meine erste Wahl, da mich die vielfältigen Funktionen auf der Webseite des Projekts überzeugt hatten. Awstats ist hauptsächlich in Perl geschrieben und lässt sich mit Hilfe eines CGI-Skripts in Echtzeit aktualisieren. Diese Funktionalität benötigte ich aber gar nicht und habe deshalb alle Statistikseiten mit Hilfe des mitgelieferten Skripts buildstatic.sh statisch generieren lassen. Die Funktion lässt sich in /etc/default/awstats aktivieren.

Die Konfiguration findet bei Debian z.B. in /etc/awstats/awstats.linuxiuvat.de.conf statt. Man sollte die Standardkonfiguration von awstats.conf für sein eigenes Projekt dementsprechend umbenennen und nach /etc/awstats kopieren. Debian erstellt dann automatisch verschiedene Unterordner in /var/cache/awstats/ auf Basis des Dateinamens. Um die Statistiken später darstellen zu können, müssen diese Ordner für euer gewünschtes Webserver-Verzeichnis freigegeben werden.

Die Konfiguration von Awstats ist äußerst gut dokumentiert. Die meisten Standardeinstellungen konnte ich beibehalten. Lediglich diese hier habe ich geändert oder sind erwähnenswert.

# Pfad zur Logdatei
LogFile=“/var/log/lighttpd/linuxiuvat.de/access.log“

# Webserver-Log deshalb Typ W
LogType=W

# Apache Logformat funktioniert auch mit Lighttpd
LogFormat=1

# Eure Domain und Aliase
SiteDomain=“linuxiuvat.de“
HostAliases=“linuxiuvat.de www.linuxiuvat.de localhost 127.0.0.1″

# Wir wollen die Namen der IP-Adressen nicht auflösen, weil es die Generierung der Statistiken verlangsamt
DNSLookup=0

# Reguläre Ausdrücke können unerwünschte Begriffe oder Benutzeragenten herausfiltern
SkipUserAgents=“REGEX[Python-urllib]“

# Awstats lässt sich durch eine Vielzahl von Plugins erweitern. Mit GeoIP lässt sich die Herkunft der Besucher anzeigen
LoadPlugin=“geoipfree“

Damit die IP-Adressen nach Ländern aufgelöst werden können, muss entweder die Bibliothek libgeo-ipfree-perl oder libgeo-ip-perl zusätzlich installiert werden.

Statische Seiten generieren und ein kleiner Hack

Debian stellt in /usr/share/awstats/tools/ mit buildstatic.sh ein Skript zur Verfügung, welches zum einen separate Awstats-Unterordner basierend auf den Konfigurationsdateien erstellt und zum anderen awstats_buildstaticpages.pl aufruft.

Die Statistiken werden in weiteren Ordnern nach Monaten sortiert. Damit jeder dieser Monats-Ordner noch eine index.html Datei erhält, muss dieser kleine Codeschnipsel am Ende der Datei hinzugefügt werden.

print "$cpt files built.n";
print "Main HTML page is 'awstats.$OutputSuffix.$StaticExt'.n";

my $command="/bin/cp $OutputDir" . "awstats.$OutputSuffix.$StaticExt $OutputDir" . "index.html";
$retour=`$command 2>&1`;

if ($QueryString =~ /(^|-|&)buildpdf/i) { print "PDF file is 'awstats.$OutputSuffix.pdf'.n"; }

0; # Do not remove this line

Den Tipp habe ich in diesem PDF-Dokument gefunden. Entscheidend ist die Zeile, die mit my $command beginnt und die normale Startseite in index.html umwandelt.

Zusätzlich sollte man noch einen Blick in /etc/cron.d/ werfen und überprüfen, wie oft Awstats und das zugehörige Update-Skript ausgeführt werden sollen. Mir genügte die tägliche Generierung der Statistiken.

Awffull

Awffull ist eine Abspaltung von Webalizer, die einige Verbesserungen mit sich bringt. Awffull ist noch einfacher einzurichten. Es genügt ein typisches

aptitude install awffull

und ein paar Veränderungen in /etc/awffull/awffull.conf.

# Pfad zur Logdatei
LogFile /var/log/lighttpd/linuxiuvat.de/access.log

# Auflösung der IP-Adressen nach Herkunftsland
GeoIP yes

# Pfad zur GeoIP-Datenbank
GeoIPDatabase /usr/share/GeoIP/GeoIP.dat

# 404 – Fehler anzeigen lassen.
Top404Errors 10

Die GeoIP-Datenbank für GeoIP ist frei und kostenlos und kann von maxmind.com heruntergeladen werden.

Sollten die Logdateien sehr groß sein, sollte man in Erwägung ziehen Incremental auf yes zu setzen. Für ein kleines Projekt wie linuxiuvat.de ist das aber (noch) unnötig. 🙂

Die HTML-Dateien mit den Statistiken befinden sich danach in /var/www/awffull/.

Fazit

Beide Werkzeuge erfüllen vollkommen ihren Zweck. Awstats hat mehr Funktionen, ist umfangreicher und lässt sich auch in Echtzeit per CGI-Skript aktualisieren. Awffull ist schlichter, sehr schnell und einfach einzurichten. Ich habe mich schließlich für Awffull entschieden, da für mich der Informationsgehalt vollkommen ausreichend ist. Piwik bietet zusätzlich z.B. noch Angaben über die Bildschirmauflösung und eine Echtzeitfunktion, die ein Programm zur reinen Loganalyse natürlich nicht liefern kann. Für jedes kleine Projekt tun es aber bedenkenlos auch Awstats und Awffull.

Ein Abstecher in die Welt der Web- und vServer

Zuerst die Vorgeschichte. Vor einigen Tagen wurde angekündigt, dass Debian Wheezy Kernel 3.2 an Bord haben wird und nicht alle scheinen damit glücklich zu sein. Eine interessante Randnotiz dieser Meldung war, dass Debian Wheezy keine zusätzlichen Kernel für die Virtualisierungslösungen OpenVZ und VServer anbieten wird. Als normaler Desktopkonsument bin ich davon zwar nicht betroffen, ich kann mir aber vorstellen, dass Anbieter von vServern auf Basis dieser Technologie schon nach Alternativen Ausschau halten.

Zwischen all den Beiträgen und Kommentaren auf der Mailingliste der Debianentwickler hob schließlich jemand hervor, dass einer der Vorteile von OpenVZ und des Linux VServer im geringen Speicherverbrauch läge und schon 128 MB RAM und weniger zum Betrieb ausreichen würden. Dagegen wurde gekontert, dass auch mit Xen virtualisierte Server schon ab 128 MB RAM angeboten werden.

Nun war mein Interesse geweckt und ich wollte wissen, welche weiteren Angebote in dieser Leistungs- und Preisklasse existieren. Nicht besonders überraschend: Die Auswahl ist groß. Leider ist nicht immer ersichtlich, welche Virtualisierungstechnologie verwendet wird und das Preis- Leistungsverhältnis schwankt gewaltig. Am interessantesten erscheint mir im Moment der vServer „Neptun Light“ von netcup.de zu sein, ein Einsteigermodell, aber das ist wie gesagt nur ein erster Eindruck. Ich bin weder Kunde noch anders mit dem Unternehmen verbunden und kann deswegen hier keine Empfehlung abgeben.

Während der Suche nach einem passenden vServer stolperte ich immer wieder mal über die Webserver-Frage. Welcher ist am besten für ein typisches vServer-Szenario mit wenig RAM und begrenzten Ressourcen geeignet? Das brachte mich dazu mir Lighttpd wieder einmal näher anzusehen und nginx durfte dieses Mal auch nicht fehlen.

Die englische Wikipedia bietet einen übersichtlichen Vergleich von Webservern, der deutlich macht, dass es noch weit mehr Alternativen gibt, darunter auch wesentlich kleinere Server wie thttpd, mini-httpd und micro-httpd.

Da ich den Apachen schon besser kenne und etwas Neues ausprobieren möchte, habe ich einige Zeit damit verbracht um nach geeigneter Dokumentation für Lighttpd zu suchen, der schon erfolgreich auf dem ältesten Laptop mit nur 16 MB RAM lief. Auch nach einer kompletten Installation mit PHP und MySQL auf meinem Portégé 3110CT hat Lighttpd immer noch nichts von seinem Charme verloren.

Bevor es gleich mit einem vServer ernst wird, bietet sich quasi als Trockenübung ein älterer Rechner an, der nur darauf wartet zum Web-, Mail- und Streamingserver ausgebaut zu werden. Die Dokumentation dazu ist ein wenig verstreut, aber es gibt einige hervorragende englische Quellen, die ich weiterempfehlen möchte.

  • lighttpd.net: Das Wiki und die vollständige Dokumentation zu Lighttpd mit vielen HowTos.
  • nanotux.com: Exzellente Anleitung wie man Lighty mit PHP und MySQL einrichtet und dazu noch weitere Tipps zum Einrichten eines vServers.
  • library.linode.com: WoW! Tutorials, Tutorials, Tutorials. Wer jemals mit dem Gedanken gespielt hat einen vServer produktiv zu nutzen, sollte sich diese Seite als Lesezeichen setzen.
  • howtoforge.com: Gute HowTos zu Lighttpd.
  • cyberciti.biz: Schon seit Jahren ein Quell ausgezeichneter Anleitungen, nicht nur für Lighty.

Ich war ziemlich begeistert, was es alles an ausführlicher Doku zum Thema Web- und vServer im Netz gibt. Zum Testen genügt mir im Moment einer der älteren Laptops mit Debian Squeeze. Ein Fazit? Es gibt immer wieder Neues mit Freier Software zu lernen. 🙂