Tetrinet: Tester gesucht

Es müssen ja nicht immer nur Ego-Shooter sein, dachte ich mir und bin auf der Suche nach internetfähigen Spielen über Tetrinet gestolpert. Ich denke bei Tetris werden Erinnerungen wach. In Russland fing alles an, ich habe es zum ersten Mal anno dazumal auf dem Gameboy in schwarz-weiß gespielt und ich wette ohne nachgeschaut zu haben, dass man es als App für Smartphone X irgendwo in 10 verschiedenen Varianten herunterladen kann.
So viel sei verraten, Tetrinet bringt das Spiel zu neuen Höhen und erweitert den Spaß um den Faktor Mehrspieler und Internet. Bis zu sechs Spielerinnen und Spieler können gemeinsam gegeneinander oder in Teams antreten. Das Besondere an dem Spiel ist, dass durch erfolgreiches Abräumen neue Bausteine freigeschaltet werden, mit denen man zu Gunsten oder Ungunsten seiner Mitspieler in das Spiel eingreifen kann.

Das ist gtetrinet, der Gnome-Klient. Ihr startet das Programm, klickt auf „Verbinden“ und gebt als Server linuxiuvat.de ein und wählt einen beliebigen Spielernamen. Anschließend befindet ihr euch auf dem Spielfeld und könnt als nächstes den Partyraum (Chat) betreten oder die Gewinnerliste anschauen. Ich denke die restlichen Feature finden sich recht schnell. 😀
Wenn es einen Client gibt, existiert natürlich auch ein Server. Womit wir bei TetrinetX angekommen sind. Sollte die Resonanz positiv sein, stelle ich das Debian-Paket irgendwann genauer vor. Es bringt auf jeden Fall vom Init-Skript, über sauber kommentierte Konfigurationsdateien bis hin zur separaten Logdatei in /var/log alles mit, was man sich als Admin wünschen kann.
Moment, Moment natürlich gibt es auch einen Tetrinet-Client für die Konsole mit dem Namen…Tetrinet-Client.

Ich will nämlich nicht verschweigen, dass gtetrinet fast die gesamte Gnome-Desktopumgebung als Abhängigkeit zieht (ich übertreibe, aber auch nur fast). Für alle Retrozocker, die auch noch über einen Laptop aus dieser Zeit verfügen eine sehr ressourcensparende Alternative. Außerdem besitzt tetrinet-client ein interessantes Feature, was manche vielleicht als Cheat bezeichnen würden. Ich empfinde die grafische Andeutung, wo der Spielstein landen wird, auf jeden Fall als sehr nützlich.

Ihr verbindet euch zu meinem TetrinetX-Server, indem ihr tetrinet-client von der Konsole wie folgt aufruft.

tetrinet-client EuerSpielname linuxiuvat.de

Einfach oder nicht?
Auf was ich hinaus will und der Titel andeutungsweise schon erahnen lässt. Ihr müsst den Server testen und das Spiel wiederbeleben. 🙂 Tetrinet gab es schon vor mehr als einer Dekade, wovon die vielen Internetadressen a la tetrinet.TLD zeugen. Mittlerweile ist das Spielerfeld ein wenig ausgedünnt.
Deswegen mein Angebot: Wenn in den nächsten Wochen sich die Gewinnerliste ein wenig füllt, bastle ich noch eine Siegerliste auf linuxiuvat.de und nehme den Server offiziell in die Reihen der Spiele auf. Falls nicht, tja, dann seid ihr dran Schuld, dass ich ein weiteres Killerspiel installieren muss. 😈

Pyqscore: Spielstatistiken für OpenArena erstellen

Zurück zu meinem Steckenpferd. Im folgenden geht es darum, wie man aus einer Logdatei für OpenArena eine sinnvolle Spielstatistik erstellen kann. OpenArena ist kurz gesagt ein modifiziertes Quake3 mit Medieninhalten, die vollständig unter einer freien GPL-Lizenz stehen. Für meinen öffentlichen OpenArena-Server habe ich mich für Deathmatch entschieden, da ich das Gefühl hatte, die meisten Spieler bevorzugen diesen Spielmodus.
Ein weiterer Vorteil ist sicherlich, dass „Jeder-gegen-Jeden“ am einfachsten zu überwachen ist, denn im Prinzip geht es nur darum, dass Spieler X Spieler Y fraggt und alles ein Zeitspiel ist.
Es gibt verschiedene Werkzeuge und Programme, die einem beim Erstellen von Statistiken helfen können. Im Grunde läuft es aber immer auf das Parsen der Logdatei heraus. Das OpenArena-Wiki führt hier z.B. VSP, AEstats oder oastats an.
Für mich war nur eine Sache klar. Ich wollte keinen zusätzlichen Datenbank-Server. Irgendwie erschien mir das nicht die richtige Lösung zu sein, um eine einzelne Logdatei zu parsen.
Der Gewinner war schließlich Pyqscore.
Pyqscore ist ein in Python geschriebenes Programm, dass die Datei games.log analysieren kann und zusätzlich noch einen Cache benutzt, damit schon zuvor analysierte Werte nicht noch einmal ausgewertet werden müssen.
Das ursprüngliche Skript pyqscore.py habe ich auf meinem Server in /usr/local/bin abgespeichert. Es wird täglich mit Hilfe von Cron ausgeführt. Erwähnt hatte ich es schon bei meinem Cron- und Logrotate-Beispiel.
Jeden morgen wird deswegen die zuvor mit Logrotate rotierte Datei games.log.1 ausgewertet und als daily.htm abgespeichert. Mit Hilfe von cat addiere ich alle täglichen Logdateien in die Datei monat.log, worüber ich dann ein leicht modifiziertes Pyqscore ausführen lasse, dass die Statistik des Monats wiederum in der Datei monthly.htm abspeichert.
Für die täglichen Statistiken benutze ich dieses Skript

#!/bin/sh
# Tägliche Statistiken mit pyqscore erzeugen, im HTML-Format ausgeben und mit tidy säubern
set -e
Base="/var/games/openarena-server/.openarena/baseoa/"
cd $Base
if [ -f games.l_cache.p ]; then
        rm games.l_cache.p
fi
/usr/local/bin/pyqscore.py games.log.1
/usr/bin/tidy -utf8 -m -q daily.htm || true

Hier wird jeden Tag in das entsprechende Verzeichnis gewechselt und der alte Cache gelöscht. Das ist notwendig, weil Pyqscore bei einer größeren Logdatei den Cache zum schnelleren Analysieren heranzieht, bei kleineren Logdateien aber eine komplett neue Cache-Datei anlegt.
Damit keine Fehler entstehen, lösche ich den Cache bei der täglichen Statistik. Anschließend wird nur noch die games.log.1 ausgewertet und mit Hilfe von Tidy gesäubert.
Ein anderes Skript kopiert dann automatisch die erzeugte daily.htm in das Webserver-Verzeichnis.
Für die monatlichen Statistiken verfahre ich so:

#!/bin/sh
# Monatliche Statistiken mit pyqscore erzeugen und im HTML-Format ausgeben
set -e
Today=`/bin/date +%d`
Month=`/bin/date -d "last month" +%m`
Year=`/bin/date +%y`
Base="/var/games/openarena-server/.openarena/baseoa/"
if [ $Today -eq 02 ]; then
        rm ${Base}monat.log
        cp ${Base}monthly.htm ${Base}${Year}${Month}_stats.htm
fi
cd $Base
cat games.log.1 >> monat.log
/usr/bin/nice -19 /usr/local/bin/pyqscore_mon.py monat.log
/usr/bin/tidy -utf8 -m -q monthly.htm || true

Ok, hier werden folgende Sachen überprüft. Am Morgen jedes zweiten Tages im Monat wird die alte Datei monat.log gelöscht und die Auswertung beginnt von vorne. Ich sichere danach die alte Datei monthly.htm.
Ursprünglich hatte ich daran gedacht, so etwas wie eine „Siegerehrung“ zu machen, also eine Extraseite mit den ersten Plätzen. Sollte tatsächlich jemand das Bedürfnis nach einer solchen Seite haben, kann ich das nun immer noch nachtragen. 😉
Ansonsten wird die tägliche Logdatei an die monatliche angehängt und ausgewertet und das ganze wieder mit Tidy ordentlich aufbereitet. Damit ich nicht permanent E-Mails von Cron mit Fehlermeldungen erhalte, erzwinge ich den Exit-Status von Tidy mit „true“. Ansonsten kann man jeden Tag lesen, dass die ursprüngliche HTML-Datei Fehler enthalten hat.
Das war es im Prinzip auch schon. Der Vorteil von Pyqscore liegt darin, dass man statische HTML-Seiten mit Statistiken erhält ohne zuvor eine Datenbank installiert zu haben. Bei einem Projekt, wo es um jedes MB Arbeitsspeicher geht, sicher ein Vorteil.
Ich habe Pyqscore an meine Bedürfnisse angepasst. Im Laufe der Zeit sind mir bisher ein paar kleinere Schwächen aufgefallen, die ich versucht habe zu beseitigen. Für alle Interessierten biete ich Pyqscore hier zum Download an.

Wenn Quake heute veröffentlicht worden wäre

Was wäre wenn…Quake heute auf den Markt kommen würde. Passend zum letzten Artikel, konnte ich mir diesen Post nicht verkneifen. Mit ein wenig Augenzwinkern geht das folgende Video der Frage nach, was zur Hölle mit der heutigen (Spieler-)Generation los ist.
So nun reißt euch mal von Farmville los und schaut wie Oma und Opa das früher gemacht haben. 😀

Fünf coole Linuxspiele und ein Gewinner

Ich schreibe die ganze Zeit von der Konfiguration des Servers, da das wirklich unzählige interessante Aspekte sind, aber wo sind bitte schön die ganzen Spiele? Wer sich mal selbst an so ein Projekt wagt stellt bald fest, dass es gar nicht so schwer ist einfach mal ein Spiel zu installieren. Doch es fängt schon damit an, dass ein Ego-Shooter wie z.B. OpenArena mehrere Spielmodi anbietet, unzählige Servervariablen und dazu noch Dutzende weitere Server existieren, die genau den selben Fokus haben. Wie schafft man es also, dass das ganze nicht zu einem rein akademischen Projekt ohne Praxisbezug verkommt und tatsächlich irgendwann Leute auf dem Server spielen?
Ich brauchte eine Weile bis ich herausgefunden hatte, was die Spieler eigentlich wollen. Zumindest bin ich mit den bisherigen Einstellungen zufrieden. Eine Garantie für dauerhaften Erfolg ist es natürlich nicht. Kurzum man muss auch Zeit in das Spiel selbst investieren und kann sich nicht nur auf die Administration beschränken.
Da mittlerweile mehr als zwei Monate seit dem Start des Projekts vergangen sind, wird es Zeit auch mal die Spiele zu nennen, die es bisher auf meinen vServer geschafft haben.
Das sind OpenArena, Cube2:Sauerbraten, Teeworlds und XPilot NG.
Doch bevor ich etwas mehr über die bisherigen Favoriten erzähle, wollte ich noch ein paar potentielle Ego-Shooter-Kandidaten vorstellen, die es zwar nicht geschafft haben, weil sie die Kriterien für meinen Spieleserver nicht erfüllt haben, aber auf jeden Fall spielenswert sind.

AlienArena


AlienArena wurde vor acht Jahren zum ersten Mal veröffentlicht und noch immer orientiert es sich am klassischen Science-Fiction-Genre mit dazu passendem Look. Sowohl Spielermodelle und Waffen als auch Texturen und Objekte rufen einen zurück in die Welt der althergebrachten und oft auch etwas trashigen Alienfilme mit Marsianern und ihren übergroßen Köpfen. Die Effekte und Texturen sind detailreicher als bei OpenArena, die Atmosphäre ist dunkel und düster.
AlienArena basiert sowohl auf der Quake II als auch der Quake III Engine, die beide von id Software unter der GPL veröffentlicht wurden.
Der Hauptgrund warum es AlienArena nicht geschafft hat: Man darf das Spiel nur ohne Modifikationen weiterverbreiten und unter dem gleichen Namen, was in Debian gleichbedeutend mit „unfrei“ ist. Außerdem habe ich mit OpenArena schon ein 100 % freies Spiel gefunden, das auf der Quake III Engine basiert.
Verschiedene Spiele haben unterschiedliche Wege eingeschlagen um sicherzustellen, dass ihr „Markenkern“ unangetastet bleibt und Entwickler bei dem Projekt bleiben und es nicht abspalten. In einem späteren Artikel möchte ich näher auf diese Unterschiede eingehen und herausfinden, welche Wege FOSS-Spiele gehen, warum manche 100% frei sind und andere eben nicht und was das für den jeweiligen Erfolg bedeutet hat. Doch für das hier und jetzt heißt es erst einmal zu sagen:
Cooles Spiel, aber kein Gewinner.

Nexuiz


Nexuiz war zuerst in jeder Hinsicht der totale Gewinner. Das Spiel basiert auf einer stark modifizierten Form der ursprünglichen Quake-Engine, die allgemein unter dem Namen Darkplaces-Engine bekannt ist und als Freie Software vorliegt. Nexuiz hat exzellente grafische Effekte, darunter sehr detailreiche Licht- und Partikeleffekte. Texturen und Waffenmodelle sind äußerst sehenswert. Das Beste von allem ist, sie sind ebenfalls unter freien Lizenzen verfügbar.
Das Gameplay selbst ist hart und schnell, wie man das eben aus alten Tagen kennt. Auch das Drum-Herum ist schön gemacht. So gibt es z.B. ein Einführungsspiel mit Tutor und passender Anleitung, das einem sowohl Waffen als auch Bewegungen erklärt.
Der Haken an dem Spiel liegt an den vor zwei Jahren stattgefundenen Entwicklungen in der Nexuiz-Gemeinschaft. Die beiden wichtigsten Programmierer und Anführer, darunter der Macher der Darkplaces-Engine, verließen das klassische Nexuiz-Projekt. Die Rechte an dem Namen Nexuiz wurden an IllFonic verkauft, welches dieses Jahr ein Nexuiz-Remake auf Basis der CryEngine3 für Konsolen auf den Markt gebracht hat.
Große Teile der Nexuiz-Gemeinschaft waren von dieser Entwicklung nicht begeistert und haben daraufhin die Arbeit an Xonotic begonnen, dass die bisherige Arbeit an Nexuiz fortführen soll.
Da Nexuiz kaum noch weiterentwickelt wird und die Zukunft Xonotic gehört, habe ich mich schließlich gegen das Spiel entschieden.

Tremulous


In Tremulous geht es wieder einmal um das klassische Feindbild Aliens gegen Menschen. Das Spiel basiert auf der Quake3-Engine unterscheidet sich aber deutlich von seinem großen Vorbild, indem es die Ego-Shooter-Komponente um einen strategischen Aspekt erweitert. Jede der beiden Fraktionen hat die Fähigkeit Strukturen zu errichten, die für die Verteidigung der eigenen Basis und sogar den gesamten Spielerfolg unabdingbar sind. Hat das gegnerische Team nämlich all diese Objekte zerstört, endet das Spiel. Faszinierend ist auch, dass die Aliens die Fähigkeit besitzen sich an Wänden und Decken festzuhalten. dort entlang zu klettern und damit tatsächlich das Gefühl entsteht als sei man selbst der Hauptdarsteller in einem der besten SciFi-Filme aller Zeiten.
Nachdem ich die Probleme mit dem OpenArena-Server und der „getstatus“-Attacke per Fehlerbericht an Debian gemeldet hatte, stellte sich heraus, dass Tremulous ebenfalls gefährdet war. Daraufhin bot ich dem Paketverwalter an den Patch zu testen. Der Server lief äußerst stabil, zog aber kaum Aufmerksamkeit auf sich. In der Regel finden alle Schlachten auf einigen ausgewählten Servern statt.
Das Hauptproblem bei Tremulous sehe ich in der geringen Bereitschaft der Upstream-Entwickler kleinere Updates zu veröffentlichen. So datiert die aktuelle stabile Version immer noch von 2009. Dieses Zögern verhindert zum einen, dass ein fünf Jahre alter Bug beseitigt werden kann, der Tremulous sogar Einlass in Debians „Main“-Repos verschaffen würde und zum anderen werden Sicherheitslücken wie die „getstatus“-Attacke nicht zeitgerecht beseitigt.
Wenn es da draußen jemanden gibt, der Tremulous gerne weiterhin in Debian und seinen Derivaten sehen will, solltest du dich nun beeilen. Wahrscheinlich schon nächste Woche wird der momentane Paketverwalter beantragen, dass Tremulous aus Debian entfernt wird, weshalb auch dieses interessante Spiel es nicht längerfristig auf meinen Server geschafft hat.

Warsow


Dann wäre da noch Warsow. Während viele Actionspiele versuchen so realistisch wie möglich zu wirken, hat sich die Gemeinschaft rund um Warsow entschlossen auf comichafte Grafiken zu setzen, die mit Hilfe von Cel Shading erzeugt werden. Die Grafikengine basiert auf einer modifizierten Form der Quake-II-Engine namens QFusion.
Genauso wie in Nexuiz gibt es ein einsteigerfreundliches Tutorial, das grundlegende Spieltechniken und Bewegungen erklärt. Warsow legt insbesondere viel Wert auf „Movement“, sprich Sprünge und flüssige Bewegungsabläufe sind ein wesentlicher Schwerpunkt des Spiels. Interessant sind vor allem sogenannte „Wall Jumps“, mit denen die Spielfigur sich auch von Wänden abstoßen kann und somit neue Abkürzungen und Spielmöglichkeiten entstehen. Erwähnenswert ist auch die Einteilung von Munition in schwache und starke.
Das Spiel hat mir gut gefallen, hat sich aber auch nicht durchsetzen können, da es zum einen kürzlich aus den Debian-Repos wegen fehlender Betreuung durch den Paketverwalter entfernt wurde und zum anderen genauso wie Urban Terror oder Alien Arena nicht vollständig als Freie Software vorliegt.

Xonotic

Xonotic ist der direkte Nachfolger des klassischen Nexuiz und wurde auf Grund der oben beschriebenen Differenzen der Gemeinschaft mit den beiden Gründern von Nexuiz ins Leben gerufen. Das Spiel steht vollständig unter der GPL und verwendet weiterhin die Darkplaces-Engine. Es ähnelt in Optik und Gameplay natürlich Nexuiz, setzt jedoch auch eigene Akzente. So werden unter anderem nach und nach Texturen und Spielermodelle verbessert und sogar Fahrzeuge verfügbar sein.
Wirklich bemerkenswert ist aber der Ansatz ein zentrales System zu implementieren, welches jeden Spieler per sicherer Authentifizierung einzigartig erkennbar macht. So können dadurch serverübergreifend Statistiken realisiert werden, aber auch Spieler per ID serverweit bei Verstößen gebannt werden. Die relevante Bibliothek nennt sich d0_blind_id.
Xonotic befindet sich weiterhin in einer Betaphase, ist aber spielbar. Erst seit letztem Monat gibt es erste Bemühungen Xonotic in Debian verfügbar zu machen und ein genauer Plan wurde aufgezeigt, welche Schritte nach und nach erledigt werden müssen. Es sieht demnach aus, dass Xonotic Nexuiz bei Debian irgendwann ablösen wird.
Sobald das Spiel in Debian verfügbar ist, werde ich einen Server aufsetzen. Probleme sehe ich derzeit nur wegen des Ressourcenverbrauchs. Hier muss ich schauen, ob der kleine vServer dieses Spiel noch aufnehmen kann, ohne dass andere Spiele darunter leiden.
Schaut euch den coolen Xonotic-Trailer an, wenn ihr einen ersten Spieleindruck bekommen wollt. Mehr Bilder und Videos gibt es auf xonotic.org. (Ja, das ist tatsächlich ein 100% freies Spiel) 🙂

Fazit

Ego-Shooter sind zwar nicht für jeden das richtige Genre. Linux bietet aber Dank id Software und einer Menge Freiwilliger eine Vielzahl an ausgezeichneten Spielen an. Wirklich jedes hier erwähnte Spiel unterscheidet sich sowohl in der Optik als auch im Gameplay und man kann tatsächlich von jeweils eigenständigen und herausragenden Kreationen sprechen.
Dass das noch nicht alles war ist ja klar. (Aber irgendwann ist auch mal Redaktionsschluss). Neben Xonotic favorisiere ich zur Zeit noch Redeclipse als weiteren Kandidaten für den Spieleserver. Dranbleiben. 😉

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

Server automatisch mit Hilfe von Unattended-Upgrades und Apticron aktualisieren

Eine der wichtigen Aufgaben als Admin ist es, Sicherheitsaktualisierungen zeitnah auf dem Server einzuspielen. Bei meiner Suche zu Informationen zu Unattended-Upgrades habe ich diesen englischen Artikel auf howtoforge.com gefunden, der sowohl Unattended-Upgrades als auch Apticron vorstellt. Deswegen nur zur Dokumentation für das Spieleserverprojekt, drei wichtige Punkte.

1. Debians Sicherheitsankündigungen

Nicht nur für Serveradmins, sondern auch allgemein zu empfehlen ist Debians Mailingliste für Sicherheitsankündigungen. Hier werden nur sicherheitskritische Meldungen des Sicherheitsteams veröffentlicht, weswegen die Liste ruhig und äußerst informativ ist.

2. Unattended Upgrades

Unattended-Upgrades ist eine Software, die automatisch und unbeaufsichtigt Sicherheitsaktualisierungen herunterladen und aktualisieren kann.
aptitude install unattended-upgrades
/etc/apt/apt.conf.d/50unattended-upgrades:
Die Datei ist gut kommentiert. Hier lässt sich festlegen, welche Debian-Distribution aktualisiert werden soll, ob Pakete auf eine Schwarze Liste kommen und nicht erneuert werden dürfen, ob man per E-Mail informiert werden möchte, der Rechner nach dem Update neugestartet werden soll und so weiter. // leiten Kommentare ein.
Ein Auszug:

// Automatically upgrade packages from these (origin, archive) pairs
Unattended-Upgrade::Allowed-Origins {
„${distro_id} stable“;
„${distro_id} ${distro_codename}-security“;
// „${distro_id} ${distro_codename}-updates“;
// „${distro_id} ${distro_codename}-proposed-updates“;
};
// List of packages to not update
Unattended-Upgrade::Package-Blacklist {
// „vim“;
// „libc6“;
// „libc6-dev“;
// „libc6-i686“;
};
// Send email to this address for problems or packages upgrades
// If empty or unset then no email is sent, make sure that you
// have a working mail setup on your system. The package ‚mailx‘
// must be installed or anything that provides /usr/bin/mail.
Unattended-Upgrade::Mail „root@localhost“;

/etc/apt/apt.conf.d/02periodic
In 02periodic wird das eigentliche Paket aktiviert. Täglich wird dann auf Updates überprüft.

// Enable the update/upgrade script (0=disable)
APT::Periodic::Enable „1“;
// Do „apt-get update“ automatically every n-days (0=disable)
APT::Periodic::Update-Package-Lists „1“;
// Do „apt-get upgrade –download-only“ every n-days (0=disable)
APT::Periodic::Download-Upgradeable-Packages „1“;
// Run the „unattended-upgrade“ security upgrade script
// every n-days (0=disabled)
// Requires the package „unattended-upgrades“ and will write
// a log in /var/log/unattended-upgrades
APT::Periodic::Unattended-Upgrade „1“;
// Do „apt-get autoclean“ every n-days (0=disable)
APT::Periodic::AutocleanInterval „7“;

Das war es auch schon. Bei einem Update werden alle Nachrichten nach /var/log/unattended-upgrades geschrieben.
Zusätzlich besteht auch die Möglichkeit das Paket mit Hilfe von debconf zu konfigurieren.
dpkg-reconfigure -plow unattended-upgrades

3. Apticron

Als Alternative oder zur Ergänzung kann man apticron installieren, ein Shellskript, das regelmäßig auf Updates überprüft, im Gegensatz zu unattended-upgrades aber die Pakete nicht automatisch installiert. Mit Hilfe von apt-listchanges werden Veränderungen und Neuigkeiten per E-Mail an die eingestellten Adressen verschickt.
Diese werden in /etc/apticron/apticron.conf festgelegt.

QStat ist Quakestat und ist ein Muss für jeden Spieleserver

Es gibt ein paar Programme von denen man praktisch gar nichts hört, wenn man nicht tief in der speziellen Materie drinsteckt. Kommt man mit Spieleservern in Kontakt, stößt man zwangsläufig auf Qstat, mit dem sich auf der Konsole der Status des Servers abfragen lässt.
Da QStat auch der Name eines POSIX-Kommandos ist, heißt QStat bei Debian und Co. Quakestat und macht deutlich, wo die Wurzeln dieses Programms liegen. Die Anfänge reichen zurück in die 90iger Jahre und seit 2002 befindet sich QStat auch auf Sourceforge. Obwohl die Entwicklung mit den Jahren sich verlangsamt hat, gibt es immer noch Verbesserungen und Neuheiten, die vor allem in der Entwicklerversion sichtbar werden. Da aber die letzte Veröffentlichung schon wieder zwei Jahre her ist, gab es bis dato auch noch nichts Neueres in Debian.
Ich habe mich deshalb daran gemacht und die aktuellste SVN-Version „ausgecheckt“ und mir ein aktualisiertes Debianpaket gebaut. Zu meiner Freude kann ich sagen, dass es funktioniert und ich mit der neuen Version nun auch Teeworlds und Cube2:Sauerbraten-Server abfragen kann. Das Ergebnis habe ich mit Munin auf der Statistikseite dargestellt.
Mein Ziel ist es dieses Paket noch weiter zu verbessern und die Richtlinien für Debianpakete zu erfüllen. In den nächsten Wochen werde ich einen Wishlist-Bug für das Paket abschicken, mit der Bitte noch vor dem Freeze von Wheezy das aktuelle QStat-2.11 zu aktualisieren. Vielleicht habe ich auch Glück und es gibt in den nächsten Monaten tatsächlich noch ein „echtes“ Release.
Die groben Schritte zum Bauen von Qstat-2.12 waren.

  1. Aus Subversion auschecken.svn co https://qstat.svn.sourceforge.net/svnroot/qstat qstat
  2. Offizielle QStat-Quelldateien von Debian herunterladen.
    apt-get source qstat
  3. Den Debian-Ordner einfach in das neue QStat-SVN-Verzeichnis kopieren. Quilt3.0-Format sei Dank.
  4. Teeworlds mit Hilfe von Quilt patchen. Den Patch gibt es hier. Lesenswerte Dokumentation zu Quilt findet sich im Debian Wiki und bei Quilt for Debian Maintainers.
  5. Abhängigkeiten installieren.
    aptitude install build-essential autoconf automake autotools-dev
  6. Autogen.sh-Skript im Quellordner ausführen, Quellpaket neu bauen und anschließend mit einer der Debian-Methoden wie z.B. dpkg-buildpackage übersetzen.

Wer mein selbst gebautes QStat-2.12 gebrauchen kann, darf mich gerne anschreiben oder hier eine Nachricht hinterlassen, ich schicke es gerne zu.
Die Bedienung von QStat ist ziemlich einfach. In der neueren Version genügt folgender Befehl, um meinen OpenArena-Server abzufragen.
quakestat -openarenas 134.0.24.218:27961
In der aktuellen Version 2.11 müsst ihr in die /etc/qstat.cfg noch folgendes eintragen.

gametype OA081S new extend Q3S
name = Openarena Server 081
template var = OA081S
game rule = gamename
end
gametype OA081M new extend Q3M
name = Openarena Master
default port = 27950
master for gametype = OA081S
master protocol = 71
end

Der Server meldet den Status dann mit
quakestat -oa081s 134.0.24.218:27961
Als Ergebnis erscheint z.B. so eine Zeile.

ADDRESS PLAYERS MAP RESPONSE TIME NAME
134.0.24.218:27961 4/16 0/0 kaos2 21 / 0 Einherjer Europe Public FFA

Der „Trick“ ist es mit einem Munin-Plugin die Zahlenwerte für die Spieler regelmäßig abzugreifen, womit sich dann ein Graph mit der Anzahl der Spieler erstellen lässt. Thema für einen anderen Beitrag.

Cron und Logrotate: Ein Beispiel anhand eines Spieleservers

Genauso unabdingbar wie Liebe und guter Wein für Goethe waren, sind Cron und Logrotate das Lebenselixier für jeden Serveradmin. Vielleicht etwas übertrieben formuliert, aber auch nur fast. 🙂 Als „normaler“ Linuxnutzer kommt man nur sehr selten direkt mit den beiden in Berührung, da in der Regel einfach alles läuft.
Nur am Rande bemerkt: Wer an Debians und Ubuntus „Popularity Contest“ teilnimmt und ihn nicht auf einem Server laufen lässt, sollte auf jeden Fall noch anacron installiert haben, da das Senden der Berichte zu wechselnden Tageszeiten erfolgt und man unter Umständen den Rechner dann nicht eingeschaltet hat, weswegen der Cron-Job nicht ausgeführt werden kann.
Im Gegensatz zu Anacron arbeitet Cron präzise zu einem bestimmten Zeitpunkt Aufträge ab und setzt damit voraus, dass der Rechner kontinuierlich verfügbar ist. Im Zusammenspiel mit Logrotate, das Logdateien nach einem vorgegebenen Zeitintervall verschieben und komprimieren kann, ist er äußerst wichtig und nützlich für jeden Server.

Logrotate-Beispiel anhand von OpenArena

Der OpenArena-Server speichert den Verlauf der Spiele in der Logdatei games.log. Hierfür habe ich eine neue Konfigurationsdatei in /etc/logrotate.d/ angelegt, die wie folgt aufgebaut ist.

/home/openarena/.openarena/baseoa/games.log {
        daily
        missingok
        rotate 14
        compress
        delaycompress
        notifempty
        create 644 openarena openarena
        sharedscripts
        postrotate
                if [ -x /usr/sbin/invoke-rc.d ]; then
                        invoke-rc.d oa_ded restart > /dev/null 2>&1;
                else
                        /etc/init.d/oa_ded restart > /dev/null 2>&1;
                fi;
        endscript
}

Die Syntax ist sehr logisch.

  • Wann soll rotiert werden? Alternativen sind weekly und monthly
  • daily

  • Sollte die Logdatei nicht vorhanden sein, ignoriere den Fehler und gehe zur nächsten Datei.
  • missingok

  • Wie oft werden Logdateien rotiert? In diesem Fall werden für jeden Tag für insgesamt 14 Tage Logdateien vorgehalten. Am 15. Tag würde also die älteste Logdatei überschrieben werden. Wäre z.B. weekly und rotate 8 eingestellt, würde die Logdatei jede Woche für insgesamt 8 Wochen rotiert.
  • rotate 14

  • Um Platz zu sparen sollten die Dateien mit gzip komprimiert werden.
  • compress

  • Verzögere die Kompression um einen Rotationszyklus, da manche Programme noch in die letzte Logdatei schreiben können. Dadurch ist games.log.1 immer unkomprimiert.
  • delaycompress

  • Wenn die Datei leer ist, soll gar nichts gemacht werden.
  • notifempty

  • Eine neue games.log wird automatisch mit den Dateirechten 644 und Benutzer und Gruppe openarena erzeugt.
  • create 644 openarena openarena

  • Normalerweise wird die Anweisung prerotate und postrotate bei jeder Logdatei ausgeführt, also wenn anstelle von games.log z.B. eine Wildcard wie *.log angegeben worden wäre. In diesem Fall nicht entscheidend, sondern nur zur Sicherheit.
  • sharedscripts

  • Mit dem letzten Kommando postrotate kann eine Aktion nach der durchgeführten Logrotation ausgeführt werden. In meinem Fall starte ich danach den Server immer neu. Das hat den zusätzlichen Vorteil, dass eventuell durch Spieler geänderte Servervariablen wieder auf die Standardwerte zurückgesetzt werden. Für den Teeworlds-Server war ein Neustart sogar notwendig, da er ansonsten nicht in die neue Logdatei geschrieben hat.

Weitere Ideen und Anregungen finden sich im Verzeichnis /etc/logrotate.d/ und natürlich mit man logrotate. Die Konfigurationsdatei für logrotate ist /etc/logrotate.conf.

Cron in Kürze

Cron ist das Herzstück jedes Servers. Er arbeitet zeitgesteuert alle Shellskripte in /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly und /etc/cron.monthly ab und wertet die Informationen in /etc/crontab und den jeweiligen crontabs aus. Cron muss nicht neugestartet werden, wenn eine Einstellung verändert wird.
In meiner /etc/crontab habe ich z.B so etwas stehen:

 05 7    * * *   openarena       /usr/local/bin/oa_stats_daily.sh > /dev/null 2>&1

Hier wird mit den Rechten des Benutzers openarena ein kleines Skript ausgeführt, welches die täglichen Statistiken um 7 Uhr und fünf Minuten für OpenArena generiert.
Mehrere Beispiele für Cron aus der Wikipedia:

#M    S   T   M  W    Befehl
5     *   *   *  *    /usr/bin/message.sh     #Befehl wird fünf Minuten nach jeder vollen Stunde aufgerufen.
*/5   *   *   *  *    /usr/bin/message.sh     #Befehl wird alle 5 Minuten aufgerufen (die Schrittweite wird durch */Schrittweite angegeben).
59    23  *   *  0    gzip /var/log/messages  #Befehl wird einmal pro Woche sonntags um 23:59 Uhr ausgeführt.
0     0   *   *  *    gzip /var/log/auth.log  #Befehl wird täglich um 00:00 Uhr ausgeführt.
20,30 1   *   *  1-5  /usr/bin/work.sh        #Befehl wird montags bis freitags jeweils um 01:20 und 01:30 ausgeführt.
0     1   1-7 12 1    /usr/bin/work.sh        #Befehl wird am 1. bis 7. Dezember sowie an jedem Montag im Dezember um ein Uhr nachts ausgeführt.

Aus Sicherheitsgründen kann man die Erlaubnis für Cron-Jobs einschränken, indem eine Datei /etc/cron.allow mit den berechtigten Benutzern angelegt wird. (Ein Name pro Zeile). Ansonsten darf jeder Benutzer mit Eingabe von crontab -e seine eigenen Aufträge anlegen.
Cron bietet damit neben seinen typischen Aufräum- und Prüfarbeiten die Möglichkeit eigene Skripte zeitlich gesteuert auszuführen. In Zusammenspiel mit Logrotate lassen sich so ganz leicht Statistiken für den Spieleserver generieren, sofern das Spiel diese überhaupt mitloggt. Zu dem genauen Inhalt des Skripts ein anderes Mal mehr.

Links

http://de.wikipedia.org/wiki/Cron
http://linux.die.net/man/8/cron
http://www.debian-administration.org/articles/56

Hivelogic Enkoder: E-Mail-Adresse mit Javascript obfuskieren

Der Hivelogic Enkoder existiert schon ganze Weile und ist keine große Nachricht mehr. Wenn man aber ein kleines Webprojekt erstellt, möchte man auch seine E-Mail-Adresse und unter Umständen die anderer Leute auf der Seite zur Verfügung stellen, einfach um erreichbar zu sein.
In der Regel schreibe ich dann etwas auf die Seite wie admin [at] linuxiuvat [de] und hoffe, dass die Besucher verstehen, was ich damit gemeint habe. Der Sinn dahinter ist, es Bots beim Versenden von Spam schwieriger zu machen, obwohl das natürlich nur bedingt helfen kann. Es gibt aber auch schon seit geraumer Zeit Lösungen wie z.B. den Hivelogic Enkoder, der mit Hilfe von Javascript eine E-Mail-Adresse obfuskiert, also nur schwer nachvollziehbar macht.
Wandert man auf die verlinkte Seite findet man dort ein Formular, in das man die Adresse, den Linktext und einen Betreff eingeben kann. Wird das Ganze abgeschickt, erscheint z.B. so etwas:

<script type="text/javascript">// <![CDATA[
      <!--
   r x="function f(x){var i,o="",l=x.length;for(i=0;i<l;i+=2) {if(i+1<l)o+=" +
       "x.charAt(i+1);try{o+=x.charAt(i);}catch(e){}}return o;}f("ufcnitnof x({)av" +
       " r,i=o\"\"o,=l.xelgnhtl,o=;lhwli(e.xhcraoCedtAl(1/)3=!84{)rt{y+xx=l;=+;" +
    "lc}tahce({)}}of(r=i-l;1>i0=i;--{)+ox=c.ahAr(t)i};erutnro s.buts(r,0lo;)f}\" +
       ""(2),8\"\\yqns{dl%$~7-03\\\\TRV]7_00\\\\32\\0k\\XS24\\0_" +
       "\\P[J]14\\0q\\21\\0N\\]FSA06\\07\\00\\\\Fx7F01\\\\~Th" +
       "hcuwo{qx6a{,tldgk~n6ycmq(uehw3x01\\\\23\\05\\02\\\\27\\0:\\" +
       "27\\01\\02\\\\32\\02\\02\\\\24\\0N\\34\\06\\00\\\"+
       "\35\\01\\03\\\\16\\03\\00\\\\0O4V01\\\\14\\02\\03\"+
    "\\\17\\0F\\04\\0X\\JA17\\04\\01\\\\*:.4t,6-;27 6<\"\\"+
       "f(;} ornture;}))++(y)^(iAtdeCoarchx.e(odrChamCro.fngriSt+=;o27=1y%2;*=)yy)2" +
 "+(8i>f({i+)i+l;i<0;i=r(foh;gten.l=x,l\"\\\"\\o=i,r va){,y(x fontinc" +
    "fu)\"")";
      while(x=eval(x));       //-->
// ]]></script>

Als Mensch erkennt man nicht wirklich viel, aber der Browser ist dennoch in der Lage daraus eine E-Mail-Adresse abzuleiten. Für alle, die Javascript deaktivieren, kann man noch einen Noscript-Tag einbinden.

<noscript>
<p>write an e-mail to <strong>admin</strong> [at] <strong>linuxiuvat</strong> [dot] <strong>de</strong></p>
</noscript>

Die Kritik an jeder Art von „unkenntlich“ gemachten Code bleibt natürlich bestehen. Prinzipiell ist es natürlich möglich, dass Bots anstelle von @ auch nach [at] suchen können. Da die Spamfilter der Mailprovider mittlerweile ziemlich gut sind, bekomme ich jedoch immer seltener etwas von dem Spam mit.
Es ist zwar schwieriger aber nicht unmöglich, dass ein Bot den obfuskierten Javascript-Code wieder entziffern kann. Von daher, wer auf Nummer sicher gehen will veröffentlicht gar keine E-Mail-Adressen. Ich habe mich dennoch entschieden den Code des Hivelogic-Enkoder auf meiner Kontaktseite einzubinden.

Chronicle: Bloggen mit dem Blogkompilierer

Chronicle ist ein sogenannter Blogkompilierer, der aus einfachen Textdateien, Markdown und HTML ein vollständiges Blog mit Schlagworten, Archiv und RSS-Feeds erstellen kann. Ich hatte ursprünglich vorgesehen alle Webseiten von Hand zu erstellen, da linuxiuvat.de hauptsächlich zur Beschreibung von Spielen, Dokumentation und für Statistiken gedacht ist, für die ein CMS mit dynamischen Inhalten über das Ziel hinaus schießen würde. Auf die Idee nach einem statischen Webseitengenerator wie Chronicle zu suchen, hat mich ein Kommentator gebracht, der gerne mit Hilfe eines RSS-Feeds auf dem Laufenden bleiben wollte.
Wie man Chronicle konfiguriert und bedient, darum geht es in diesem Beitrag.

Installation und Konfiguration

aptitude install chronicle


Es gibt zwei Möglichkeiten Chronicle zu verwenden. Man kann den Blogkompilierer entweder direkt auf dem vServer installieren oder ebenso praktisch auf dem eigenen Rechner zu Hause und verschiebt dann die generierten Seiten per FTP/SSH zum Webserver. Die Einstellungen werden global entweder in /etc/chroniclerc oder für jeden Benutzer einzeln in ~/.chroniclerc vorgenommen.

# Hiervon werden die Blogeinträge gelesen
input = /home/apo/blog/input
# In diesem Verzeichnis liegt später das fertige Blog
output = /home/apo/blog/news
# Name des Themas. Die Themen liegen in /usr/share/chronicle/themes
theme = default
# Anzahl der Blogeinträge auf der Startseite
entry-count = 10
# Anzahl der RSS-Einträge
rss-count = 10
# Wir schreiben die Artikel in HTML. Alternativen sind Markdown und Textile
format = html
# Kommentarfunktion einschalten
no-comments = 0
# Der Name des Blogs
blog_title = Linux iuvat /news

Die Standardeinstellungen sind sinnvoll und es gibt nur noch wenige zusätzliche Optionen. Um einen Blogartikel zu erstellen, genügt es eine Textdatei im Input-Ordner mit dem folgendem Format zu erstellen.

Title: Hallo Welt
Tags: Neuigkeiten, Debian, Ubuntu
Date: 21st April 2012
<h2>Wichtige Nachrichten</h2>
<p>Mein Blog ist online!</p>

Lediglich die Datumsangaben müssen in englischer Notation erstellt werden. Die Ausgabe kann aber mit der Option –lang=german angepasst werden.
Nachdem auf die gleiche Weise alle Blogartikel geschrieben wurden, wird das gesamte Blog mit
chronicle
generiert und landet im vorher definierten Output-Verzeichnis.

Kommentare

Wie im letzten Artikel erwähnt, ist der Nachteil eines statischen Webseitengenerators, dass eine Kommentarfunktion entweder extern ausgelagert oder serverseitige Skripte zusätzlich installiert werden müssen. Im Falle von Chronicle wird aber schon ein CGI-Skript mitgeliefert, dass es möglich macht Kommentare zu verfassen. Diese werden in einer Textdatei gespeichert und beim Neukompilieren des Blogs in die statischen Seiten integriert.
Drei Einstellungen sind in der comments.cgi zu ändern.

my $COMMENT = „/var/www/comments/“
my $TO = ‚root@localhost‘;
my $FROM = ‚www-data@vps.example.com‘;

Der Ordner in dem die Kommentare gespeichert werden, sollte aus Sicherheitsgründen außerhalb des Webserver-Root-Verzeichnisses liegen. Die Benachrichtigungsadresse lässt sich beliebig wählen. Anschließend muss die Datei nur noch in das CGI-Verzeichnis des Webservers kopiert werden. Wer z.B. Lighttpd benutzt, kann das entsprechende CGI-Modul mit
lighty-enable-mod cgi
aktivieren. Zusätzlich muss noch folgendes bedingtes Konstrukt zur Konfiguration in der lighttpd.conf oder /etc/lighttpd/conf-available/10-cgi.conf hinzugefügt werden.

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

Die Kommentare werden mit dem Befehl
chronicle --comments=Pfad_zum_Kommentar_Ordner
eingebunden. Es gibt verschiedene Ansätze wie man dem Spamproblem entgegnen kann. Da ich bisher noch keine Probleme damit hatte, ein anderes Mal mehr dazu.

Fazit

Einige Ideen wie Chronicle aussehen kann, findet ihr im Blog des Machers, Steve Kemp, auf der Homepage von Kai Wasserbäch oder auf meiner News-Seite bei linuxiuvat.de.
Die Themen lassen sich mit etwas HTML-Kenntnissen gut anpassen. Chronicle ist schlicht, aber dadurch meiner Meinung auch einfach zu erlernen. Man erhält mit lediglich einem Befehl ein vollständiges Blog mit Schlagworten, Feeds und Archiven, dass ressourcenschonend und schnell ist. Wem das noch nicht zusagt, sollte auch einen Blick auf die Alternativen werfen.