Eine Beobachtung mit Debian Sid: Nvidia-Pakete auf hold setzen

Im Mai letzten Jahres habe ich ein Multiboot-System aufgesetzt und mir ein auf Spiele ausgerichtetes Debian Sid installiert. Es sind nur die notwendigen Programme für eine grafische Oberfläche mit Openbox installiert und ich bin sehr zufrieden mit dem Setup. Die Bedienung ist wie gewohnt reaktionsfreudig, einfach und schnell.
Das System ist dadurch immer topaktuell, insbesondere wenn es die Nvidia-Treiber betrifft, die für 3D-Spiele immer noch notwendig sind. Leider haben sie mir in der Vergangenheit auch Probleme bereitet. Ich habe deshalb vor mehreren Monaten beschlossen bei der letzten stabilen Version zu bleiben und die Pakete auf "hold" zu setzen und nicht mehr zu erneuern.
Das geht am einfachsten mit
aptitude hold '~nnvidia'
Mit ~n und dem folgenden Begriff werden alle Pakete, die "nvidia" im Namen führen bei einem Update zurückgehalten.
Mit dem Befehl
aptitude search '~ahold'
lassen sich alle geblockten Pakete anzeigen.
Nun, macht das wirklich Sinn? Ich denke ja. Voraussetzung ist, dass man gerne mit Unstable oder Testing arbeitet, ausprobiert und die neuste Software verwenden möchte. Updates für kritische Pakete, die in der Vergangenheit häufiger Probleme bereitet haben, sollen zurückgehalten werden. Im meinen Fall waren das die unfreien Nvidia-Treiber. Prinzipiell sollte sich das aber auch auf andere Software übertragen lassen.
Die Gefahr besteht natürlich, dass bei übertriebenem Einsatz von "hold" notwendige Updates verhindert werden, die z.B. sicherheitskritisch sind oder die Stabilität des Systems verbessern. Meine bisherige Erfahrung mit den Nvidia-Treibern hat mir aber gezeigt, dass es auch sehr sinnvoll sein kann Updates zu blockieren.
Für diesen Beitrag habe ich zuerst mit Partclone ein Backup der Partition gemacht, auf der das Spielesystem installiert ist. Die Vorgehensweise war die gleiche wie damals bei TinyCore Linux.

Sichern

partclone.extfs -c -d -s /dev/sda7 -o /home/apo/backup/20120422_loki_sda7.img

Wiederherstellen

partclone.restore -d -s /home/apo/backup/20120422_loki_sda7.img -o /dev/sda7
Wie sich mal wieder gezeigt hat, sind Backups einfach unheimlich nützlich. Nachdem ich mit
aptitude unhold '~nnvidia'
die Nvidia-Pakete freigegeben hatte, machte ich ein Update auf die aktuelle Version 290.40. Schon kurze Zeit später stellte ich fest, dass sich Spiele nicht mehr richtig beenden ließen, die grafische Oberfläche einfror und der Rechner nur noch mit Hilfe von SSH und der Konsole neugestartet werden konnte.
Ich bin daraufhin wieder zu Version 275 zurückgewechselt. Der Paketbetreuer für Nvidia kann in diesem Fall wenig machen. Diese Art von Regressionen treten häufig auf und können nur durch Nvidia selbst gelöst werden. Am besten man meldet das Problem im Support-Forum von Nvidia.
Meine Beobachtung ist, dass man bei Debian durchaus auch Pakete einmal auf Halt setzen kann, was der Stabilität keinen Abbruch tut. Eher im Gegenteil.

Sauerbraten: Cube Server Lister für Debian und Ubuntu kompilieren

Für Cube2: Sauerbraten gibt es ein nettes, grafisches Programm, mit dem sich Sauerbraten-Server überwachen lassen. Es existiert eine Übersicht sowohl über die Anzahl der Spieler, den Serverstatus, diverse Variablen und auch eine Mapvorschau gibt es. Mit einem simplen Mausklick kann man sich mit dem Server verbinden.


Kleiner Haken. Der Cube Server Lister wurde schon länger nicht mehr aktualisiert und es gibt keine offiziellen Debian- und Ubuntu-Pakete. Als Alternativen bieten sich zum einen die Trunk-Version oder ein Projekt auf GitHub an, welches CSL so gepatcht hat, dass es mit der aktuellen Justice-Version von Sauerbraten funktioniert.
Wenn man von dort die Quellen heruntergeladen hat, muss man nur noch der Anleitung auf ogros.org folgen, dort wo der Cube Server Lister auch von "WahnFred" entwickelt worden ist.

Die Kurzfassung

  1. aptitude install automake libtool libglib2.0-dev intltool g++ libwxgtk2.8-dev
  2. svn co http://cubelister.svn.sourceforge.net/svnroot/cubelister/trunk csl-svn
  3. In das csl-svn-Verzeichnis wechseln.
  4. make -f Makefile.cvs (bei der GitHub-Version nicht notwendig)
    ./configure
    make
    sudo make install

The Debian Way

Besser ist es natürlich direkt Deb-Pakete zu erstellen. Zuvor müssen die Quellen debianisiert werden.
Ihr müsst nur den Schritten in dem alten Beitrag folgen und das Quellverzeichnis richtig umbenennen (z.B. csl-0.81 und csl_0.81.orig.tar.gz) und das .orig.tar.gz-Archiv erstellen. Anschließend wechselt ihr in das Verzeichnis und führt dh_make aus. (Paket dh-make muss installiert sein. )
Das Paket lässt sich dann mit
dpkg-buildpackage -rfakeroot -us -uc
bauen und mit
dpkg -i csl_0.81-1_i386.deb
installieren.
Anmerkung:
Ich musste noch zwei Zeilen in /po/POTFILES.in nachtragen, bevor sich das Debian-Paket kompilieren ließ.

./src/engine/CslCharEncoding.cpp
./src/engine/CslCharEncoding.h

Es erwarten euch noch eine Reihe von Aufgaben, bevor ihr tatsächlich dieses Paket in die offiziellen Repos hochladen dürft. Für eine lokale und private Version reichen diese Schritte aber aus.
Der Cube Server Lister lässt sich schließlich mit csl starten. Unter Einstellungen müsst ihr noch den Pfad zur ausführbaren Sauerbraten-Datei setzen (/usr/games). Um ein Update vom Masterserver zu bekommen, einfach F5 drücken.

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.

Die eigene Homepage: CMS, Blogkompilierer und statisches XHTML

Ich stand vor der Entscheidung wie ich die Homepage für mein neues Spieleserverprojekt gestalten sollte. Ich schwankte anfangs zwischen einem dynamischen Portal für freie Spiele und selbst geschriebenen statischen HTML-Seiten. Ich habe mich schließlich gegen PHP und Datenbanken entschieden und auf statische Inhalte gesetzt, die zum einen durch Chronicle, einen Blogkompilierer, und zum anderen durch manuell erstelltes XHTML erzeugt werden. Die restlichen Statistiken und Graphen für die einzelnen Spiele werden täglich durch das Auswerten von Logdateien und mit Hilfe von Munin dargestellt.

Die Frage bei so einem Projekt ist: Wie viel Interaktion möchte man eigentlich haben?
Linuxiuvat.de ist keine Clan- oder Gildenseite, sondern lediglich das Erscheinungsbild des virtuellen Servers, auf dem einige freie Spiele laufen. Ich übernehme hier die klassischen Aufgaben als Serveradmin und Macher der Homepage, kann aber natürlich nicht alle Mitglieder eines Clans ersetzen.
Meiner Meinung nach sind Foren oder sogar ein Wiki nur dann sinnvoll, wenn man gleichzeitig eine Community rund um die Spiele aufbauen will, die das Projekt mit Leben füllt. In meinem Fall gibt es nur mich und die Idee irgendwann das Ganze abzuschließen und zum Fazit zu kommen, dass die Möglichkeiten des vServers ausgeschöpft sind. Danach möchte ich nur noch das Bestehende weiterpflegen, selbst eine Runde spielen und zum nächsten Projekt weiterziehen.
Vor diesem Hintergrund und der Tatsache, dass der Spieleserver auch ein praktisches Beispiel ist (es macht vor allem Spaß), wie man mit Freier Software, wenig Ressourcen und auch kostengünstig ein Projekt gestalten kann, wollte ich die Interaktion auf das Notwendige und Sinnvolle beschränken.

Hilfreiche Software

Es gibt sehr viele Möglichkeiten die eigene Homepage zu gestalten. Einige Ideen finden sich z.B. bei Debian und Ubuntu mit

aptitude search '~sweb'


In der Sektion "Web" stecken zahlreiche Content-Management-Systeme, Blogsoftware und Hilfsmittel statische Inhalte zu erschaffen. Eigenes Vorwissen, die verwendete Programmiersprache, Performance und verfügbare Angebote des Webhosters spielen natürlich eine Rolle. Bei einem eigenen VPS kann man aus dem Vollen schöpfen, da es keine technischen Beschränkungen gibt.

Bekannte Content-Management-Systeme

Es gibt hervorragende freie CMS darunter die großen Joomla, Drupal, Typo3, Movable Type und WordPress. Allen ist gemein, dass sie hochentwickelt, stark erweiterbar und vielfältig einsetzbar sind. Vom kleinen Linuxblog bis zur Unternehmenskette mit eigenem Franchise ist alles denkbar. Inhalte und Seitengestaltung sind unabhängig voneinander. Wissen über HTML oder Skriptsprachen ist nützlich jedoch nicht zwingend notwendig. Jeder kann Dank des umfangreichen Backends Inhalte einstellen und verwalten.

  • Anforderungen: PHP, MySQL/PostgreSQL
  • Vorteile: Dynamische Inhalte, Interaktion mit Benutzern ist einfach, unzählige vorgefertigte Plugins und Themen, große Gemeinschaft, gute Dokumentation, sehr flexibel
  • Nachteile: Speicherintensiv, Datenbank und PHP wird benötigt, potentielle Sicherheitslücken, komplexe Bedienung, Einarbeitungszeit notwendig

Eher unbekannte Content-Management-Systeme

Dann gibt es die eher unbekannten CMS, die meist weniger Feature als die großen haben, aber nicht weniger geeignet sind, um kleinere dynamische Projekte zu verwirklichen. Mir fielen insbesondere Zine, PyLucid und TDiary auf, da ich ein wenig mit Zine wegen der Programmierung in Python geliebäugelt habe. PyLucid ist ebenfalls in Python geschrieben und benutzt Django, während TDiary in Ruby verfasst wurde. Hier sind Japanisch- und Englischkenntnisse von Vorteil. Eine weitere interessante Alternative ist WebGUI in Kombination mit Perl und MySQL und DotClear. Leider forderten alle mindestens noch die Installation einer zusätzlichen Datenbank.

  • Anforderungen: Python, Ruby, Perl, MySQL/PostgreSQL
  • Vorteile: Dynamische Inhalte, einfache Interaktion mit Benutzern, einige zusätzliche Plugins und Themen, flexibel, interessante Programmiersprachen
  • Nachteile: Relativ speicherintensiv, Datenbank, Python oder Ruby notwendig, potentielle Sicherheitslücken, weniger umfangreich als die großen CMS

Die Welt der statischen Webseitengeneratoren

Ein Trend unter Techies sind sicherlich Webseitengeneratoren wie Jekyll für Ruby und Hyde für Python, die mit Hilfe von Templates aus Text, Markdown oder HTML die komplette Seitenstruktur einer Webseite unabhängig vom Inhalt erstellen können.
Etwas einfacher aufgebaut, aber nicht weniger effektiv, sind z.B PubTal (Python), WebGen (Ruby) und Blazeblogger.
Mein Favorit, für den ich mich schließlich entschieden habe, war Chronicle, den ich im nächsten Beitrag etwas ausführlicher vorstelle.

Was ist so toll an statischen Blogkompilierern und Webseitengeneratoren?

Ich habe mich für diesen Typ entschieden, weil ich sie für sicher, leichtgewichtig und effizient halte. Natürlich kann man auch Plugins für ein CMS benutzen, die den dynamischen Inhalt in statischen überführen (Stichwort: WP-Super-Cache). Ein Blogkompilierer wie Chronicle macht das von Haus aus. Statische Inhalte werden extrem effizient durch den Webserver ausgeliefert, so dass selbst bei einem mickrigen vServer die Performance selbst unter mittelgroßer Last nicht leiden wird.
Ein normales Projekt benötigt nicht einmal ansatzweise alle Funktionen eines CMS. Hier geht es auch darum realistisch zu bleiben. Weniger ist oft mehr. Außerdem sind diese Generatoren einfach zu bedienen und benötigen weder Datenbank noch eine Skriptsprache um zu funktionieren, was im Regelfall gleichbedeutend ist mit mehr Leistung und geringeren Kosten.
Einen Haken hat die Sache. Interaktion ist ohne zusätzliche Software nicht möglich, woraus ein neues Problem erwächst.

Disqus und Co. sind böse

Wirklich, ist das so? Fakt ist, wenn man auf ausschließlich statische Inhalte setzt, muss man dennoch irgendeine serverseitige Anwendung/Skript installieren, damit Kommentare von Besuchern irgendwie in die Webseite eingebunden werden können. Viele verfallen dann auf externe Dienstleister wie Disqus oder IntenseDebate.
Als Webseitenbetreiber muss man lediglich ein Stück Javascript-Code einbinden und schon werden Kommentare an die Server von Disqus und Co. weitergeleitet und dann auf der eigenen Webseite dargestellt. Disqus macht es wirklich einfach. Keine Spam-Probleme, keine Last auf dem Server, perfekte Integration mit Sozialen Netzwerken. Als Alternative könnten Besucher z.B. eine E-Mail schicken und man bindet dann den Inhalt manuell in die Seite ein, aber hey, wer macht das schon. 😉
Ich bin nicht wirklich der Typ, der hinter jedem erfolgreichen Internetunternehmen den nächsten faschistischen Weltbeherrscher vermutet. Man sollte sich aber schon die Frage stellen, ob man für jede Webseite die Kontrolle über seine Daten an eine externe Stelle abgegeben muss oder nicht. Diese Bedenken hat Jeremy Scheff auf den Punkt gebracht.
Ich persönlich denke, dass man Interaktion und Kontrolle über die Daten auch anders haben kann und das auch nutzen sollte. Im Falle von Chronicle war das z.B. das einfache Einbinden einer einzigen CGI-Datei. Andererseits vielleicht sollten wir einfach an einem wirklich quelloffenen und freien Disqus arbeiten!

Fazit

Die Wahl der Software hängt entscheidend von den eigenen Ansprüchen ab. Wem Geschwindigkeit und Sicherheit wichtig ist, sollte statische Inhalte veröffentlichen, die bevorzugt mit einem Blogkompilierer oder Webseitengenerator erzeugt werden oder auf die händische Methode zurückgreifen. Für mein kleines Projekt werde ich diesen Weg auf jeden Fall weitergehen.

Haiku: Poesie und ein freies Betriebssystem

Als Haiku bezeichnet man eine kurze japanische Gedichtform, deren Ideale stille Kraft, Eleganz und Einfachheit auch das gleichnamige Betriebssystem Haiku teilt. Es gehört zu der Gruppe von Freien Betriebssystemen abseits von Linux, die ich mir näher anschauen wollte, da Haiku nicht nur ein freies und quelloffenes Betriebssytem ist, sondern sich durch die geringen Hardwareanforderungen auch als Alternative zu Linux auf älteren Computern eignet.
Die Wurzeln von Haiku reichen in die 90iger Jahre zurück als BeOS sich aufmachte ein Konkurrent zu Microsoft Windows, MacOS und Linux zu werden. Be Inc., die treibende Kraft hinter BeOS, wollte das Beste aus allen drei Welten verbinden und richtete das Betriebssystem auf Privatanwender und den Heimbereich aus. Zentrale Merkmale des jungen BeOS waren ein sauberes und einheitliches Erscheinungsbild des Desktops und die besondere Ausrichtung auf Multimedia-Anwendungen.
Während Linux von seiner Vielseitigkeit und Freier Software profitierte, konnte das kommerzielle und proprietäre BeOS niemals die kritische Masse erreichen, um gewinnbringend am Markt bestehen zu können, weshalb 2001 Be Inc. Konkurs anmelden musste und die Entwicklung an BeOS offiziell eingestellt wurde.
In den Jahren des Bestehens gelang es BeOS jedoch, trotz wechselnder Ausrichtung auf verschiedene Zielgruppen, eine leidenschaftliche Gruppe von Benutzern und Entwicklern für sich zu gewinnen, die schon kurz nach dem Ende von BeOS zuerst OpenBeOS ins Leben riefen und dieses dann später in Haiku umbenannten. Die Idee zum Namen geht auf die Fehlermeldungen des BeOS eigenen Browsers NetPositive zurück, der diese in Form von Haikus darstellte. 2003 folgte dann eigens die Gründung von Haiku Inc., einem gemeinnützigen Verein, der durch öffentliche Spenden die Weiterentwicklung von Haiku bis heute unterstützt.
Wichtigstes Ziel von Haiku ist es BeOS so originalgetreu wie möglich nachzubauen und dabei die Stärken des einheitlichen Desktops in ein Freies Betriebssystem zu überführen. Viel Starthilfe im Sinne von Quellcode gab es leider nicht. Lediglich der Dateimanager und das Startmenü (Deskbar) wurden damals als Freie Software veröffentlicht, weswegen alle anderen Systemkomponenten inklusive Kernel, Dateisystem und Kernanwendungen von Grund auf neu geschrieben werden mussten. Damit ist Haiku ein von den verschiedenen Linuxdistributionen vollständig abgegrenztes und eigenständiges Projekt und unterscheidet sich auch deutlich von anderen BeOS-Nachfolgeprojekten wie z.B. ZevenOS, dass das Erscheinungsbild von BeOS zwar nachbildet, dabei aber beim Unterbau auf Ubuntu und Debian setzt.

Voraussetzungen und Installation

Laut offizieller Dokumentation wird zumindest ein Pentium III mit 256 RAM zur Inbetriebnahme empfohlen. Es gibt aber auch schon positive Berichte über 128 MB bzw. nur 64 MB RAM mit einem Pentium II Rechner. Wie der Zufall so spielt, benutze ich noch ein paar Laptops dieser Leistungsklasse, darunter auch den Dell Inspiron 4000, der für diesen Test wie geschaffen war.
Zum Herunterladen gibt es die zur Zeit aktuelle dritte R1 Alpha-Version von Haiku als empfohlenes "Anyboot-Abbild" und als ISO-Image, das sich auf eine CD schreiben lässt. Die Anyboot-Variante kann man auch auf USB oder, so wie ich es getan habe, direkt auf die Festplatte mit dd schreiben. Für alle, die sich nicht extra einen älteren Laptop zum Testen ersteigern wollen, bietet sich auch das Abbild für eine virtuelle Maschine an. Ein vorgefertigtes Image zum Ausprobieren für Virtualbox lässt sich auch von virtualboxes.org herunterladen, dass bei mir sehr gut funktionierte.

Ein Überblick

In meinem Fall gelang das Installieren von Haiku durch direktes Schreiben des Abbildes auf die Ersatzfestplatte des Laptops. Nach dem Einschalten begrüßt einen zu erst einmal der Bootsplash.

Trotz meiner immerhin 13 Jahre alten Ersatzfestplatte dauerte der gesamte Bootvorgang weniger als 30 Sekunden vom Start bis zum ersten Anblick des Desktops. Einen Loginmanager wie GDM oder KDM gibt es nicht. Haiku selbst ist zur Zeit noch ein Einbenutzer-System, erst später soll es möglich sein auch mehrere Benutzer gleichzeitig am Rechner arbeiten zu lassen. Eine Portierung auf andere Architekturen außer i386 hängt in großem Maße von der Zeit der Entwickler und weiterer Hilfe ab.
Es gab keine großen "Showstopper" während des Tests. Ich hatte Netzwerkzugang, konnte im Internet surfen und Filme abspielen. Die Anwendungen ließen sich flüssig bedienen. Lediglich das Herunterfahren dauerte unverhältnismäßig lange.

Arbeitsfläche

Haiku erinnert an mehr als nur einer Stelle an die Konzepte moderner Desktopumgebungen mit einer reinen Fenstermanager-Lösung. Wer Openbox oder Fluxbox kennt, wird sich schnell an das Rechtsklick-Menü gewöhnen. Anwendungen, Orte und Befehle lassen sich von dort aufrufen und ausführen.

Standardmäßig befindet sich am oberen rechten Rand die Deskbar, praktisch das Startmenü und die Taskleiste für Haiku. Je nach Vorliebe lässt sie sich ganz leicht mit der Maus an jeden gewünschten Bildschirmrand positionieren und so ausrichten, dass die Deskbar dem klassischen Erscheinungsbild entspricht. Fenster lassen sich wie bei Fluxbox gruppieren (Stack&Tile), so dass Webbrowser und Dateimanager in einem Fenster durch Tabs getrennt erscheinen und beide Anwendungen zusammen wie eine einzelne bewegt und verändert werden können. Das alles wird gut in Haikus Dokumentation zur Benutzeroberfläche erklärt.

Anwendungen

Haiku hat auch einige typische Unix-Elemente zu bieten. So gibt es zum Beispiel einen Terminal, indem sich bekannte Unix-Kommandos ausführen lassen, auch wenn nicht jeder gewohnte Befehl verfügbar ist.

Wie der Screenshot auch zeigt, ist der Ressourcenverbrauch von Haiku gering, so dass 256 MB RAM problemlos zum Ausprobieren ausreichten. Alle Bildschirmaufnahmen ließen sich mit dem Screenshot-Programm dokumentieren. Anschließend konnten sie entweder über den eingehängten USB-Stick oder per SSH auf einen anderen Rechner transferiert werden. Ein SSH-Server ist standardmäßig installiert.
Bei Verwendung von Datenträgern mit einem anderen Dateisystem als Haikus BFS, erscheint eine Warnung, dass man diese nur lesend einhängen sollte. Empfehlenswert, da Haiku noch in einem Alpha-Stadium ist. Ich hatte dennoch keine Probleme die Bilder auf den mit EXT3 formatierten Stick zu schreiben.

In Anlehnung an NetPositive heißt Haikus Browser "Webpositive". Das Web leitet sich von der zu Grunde liegenden WebKit-Engine her, womit Webpositive jetzt wohl der 24. Webkit-Browser ist. 🙂
Das Surfen im Internet gelang auf Anhieb Dank der Möglichkeit eines kabelgebundenen Internetzugangs für meinen Laptop. WLAN funktioniert hingegen zur Zeit nur eingeschränkt unter Haiku. Es wird zwar sowohl unverschlüsseltes als auch nach dem WEP-Standard verschlüsseltes WLAN angeboten, jedoch ist letzteres nicht mehr sicher und da WPA noch nicht möglich ist, ist es auch nicht für den täglichen Gebrauch in unsicheren Netzwerken zu empfehlen.
Die Bilder lassen sich z.B. mit Wonderbrush nachbearbeiten, eines der vielen weiteren Programme, die mit Haiku mitgeliefert werden. Der Philosophie entsprechend gibt es für jeden Anwendungsfall ein Programm. Mit den Applikationen lassen sich die wichtigsten Standardaufgaben erledigen, auch wenn ein Audiorecorder oder das TV-Programm noch auf der ToDo-Liste stehen.

Da Haiku sich als freier Nachfolger von BeOS sieht, durften Multimediafähigkeiten nicht fehlen. Der Media-Player nutzt als Backend ffmpeg, kann damit alle gängigen Formate abspielen und ist für die Zukunft erweiterbar. Verschiedene Anwendungen lassen sich wie bekannt auf mehrere Arbeitsflächen verschieben, die sich in Haiku wiederum frei auf dem gesamten Desktop bewegen lassen.

Den Fensterrahmen kann man beliebig mit der Maus verschieben. Fenster lassen sich nur schließen oder mit der Zoom-Funktion automatisch an den Inhalt anpassen. Eine Verkleinern- oder Vergrößernfunktion sucht man vergeblich, ist aber auch unnötig. Insgesamt ließen sich alle Anwendungen ruckelfrei bewegen und in der Größe anpassen.

Dokumentation und Gemeinschaft

Die hier kurz angesprochenen Anwendungen sind nur ein kleiner Teil dessen, was man sonst noch mit Haiku entdecken kann. Der Webauftritt sowie die bisherige Dokumentation laden zum Stöbern ein. Haikus User Guide bietet einen guten Überblick zum Umfang des Projekts. Der meiste Text ist auch in deutscher Sprache verfügbar, auch wenn hier und da Englisch sicher nützlich sein kann. Mehr Bilder zu Haiku finden sich auch bei einem Rundgang mit der Haiku-Tour.
Kommuniziert wird über Mailinglisten, Foren und dem IRC. Regelmäßig finden auch Treffen statt, wie z.B. vor zwei Wochen BeGeistert in Düsseldorf.

Fazit

Die erste Frage, die sich wohl jeder stellt: Warum brauchen wir Haiku? Die Antwort geben die Entwickler in der FAQ als Antwort auf die Frage: "Why not Linux?" Ziel ist es ein kohärentes System zu schaffen, dass sich nicht in einer Vielzahl von Details und Einstellungsmöglichkeiten verliert, sondern schlicht und einfach funktioniert. Eine Aussage, die Haiku mit ReactOS, mit dem Code ausgetauscht wird, teilt.
In der Tat wollen viele Menschen einfach nur einen Computer haben, der funktioniert und für die es keine Rolle spielt, ob ein X-Server für die Darstellung der Grafik verantwortlich ist oder nicht. Haiku bietet mit seiner leichtgewichtigen und einheitlichen Oberfläche ein Argument für diese Benutzer.
Dennoch finden sich unter Linux ebenfalls sehr gute Distributionen, die ein ebenso vollständiges und leichtgewichtiges Desktoperlebnis garantieren. Ich denke, womit Haiku wuchern kann, ist die Tatsache, dass es eben nicht Linux, sondern etwas Eigenständiges ist. Wenn es nur darum ginge, dass immer nur die größten und am weitesten verbreiteten Betriebssysteme eine Chance bekommen sollten, hätte es Linux sicher auch nicht gegeben.
Haiku funktioniert schon sehr gut und verdient meiner Meinung nach mehr als nur einen Blick. Problematisch kann hingegen die Hardwareunterstützung sein. Größtes Problem von Haiku ist weder Konzept noch Technik, sondern Zeit und eine relativ kleine Nutzergemeinde. Vielleicht hilft der Artikel ein wenig positiv in diese Richtung. 😉
Ich kann Haiku für alle empfehlen, die ein leichtgewichtiges Betriebssystem suchen und mit dem jetzigen Alpha-Status umgehen können oder einfach nur das Besondere wollen. Es macht auf jeden Fall mehr Spaß über Haiku (und die japanischen Gedichte) zu lernen als die x-te Linuxdistribution anzutesten, die nur die Desktopumgebung austauscht.

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.

Urban Terror: Warum frei nicht immer frei ist


Wie will man wissen, was gut ist, wenn man nichts Schlechtes kennengelernt hat? Bevor ich meine derzeit installierten Spiele auf dem Spieleserver vorstelle, wollte ich ein paar Worte darüber verlieren, warum Urban Terror für mein kleines Projekt nicht funktioniert.
Urban Terror ist kein Unbekannter. Frei heraus gesagt: Zu jeder Tageszeit spielen zwanzigmal mehr Menschen Urban Terror als OpenArena. Es gibt E-Sport-Ligen und es existieren mehr als 1000 verschiedene Server. Allein das große Interesse an diesem Spiel macht es für jeden Spieleserver interessant.
Meine erste Begegnung mit Urban Terror liegt schon Jahre zurück. Damals lernte ich es während einer Netzwerkparty unter dem Motto kennen: "Hey, das ist der Mod zu Quake3, der sich genauso wie Counter Strike spielt." An dem Spielprinzip hat sich seitdem natürlich nichts geändert. Das rote Team gegen das blaue Team. Terroristen gegen Polizei. Gut gegen Böse.

Ich denke es gibt kaum jemanden, der schon einmal einen klassischen Ego-Shooter gespielt und noch nie von Counter Strike oder Urban Terror gehört hat. Das Spiel ist taktisch geprägt. Die Bewegungen der Spielfigur sind eher realistisch, man kann sogar bluten und wird dadurch verlangsamt. Die Wahl der Waffen spielt eine entscheidende Rolle. Nicht das Vernichten beliebiger Spieler, sondern das Entschärfen von Bomben und planvolle Vorgehen mit anderen steht im Vordergrund.
Die Grafik war sicher vor Jahren auf der Höhe der Zeit. Heutzutage gibt es natürlich mehr Details und Formen. Für mich war das aber noch nie das entscheidende Argument. Urban Terror eignet sich durch die Spieldynamik hervorragend als Mehrspielerspiel und hat eine weiterhin aktive Gemeinschaft.
Wo ist also das Problem? Zum einen gibt es kein Debianpaket. Die freiwilligen Paketbetreuer waren mal wieder zu nachlässig, könnte man meinen. Die Probleme sitzen tiefer. Urban Terror lässt sich zwar wunderbar unter Linux spielen, es ist aber nicht frei. Schon 2008 war es als Paket für Debian gedacht, woraus aber leider nie etwas wurde.

Das Hauptproblem ist zum einen, dass Urban Terror zwar mittlerweile mit der freien Ioquake3-Engine ausgeliefert wird und somit ohne das Originalspiel Quake3 gespielt werden kann, große Teile stehen aber immer noch unter der Quake3-SDK-Lizenz, die ausdrücklich den Verkauf des Spiels oder Weiterverbreitung durch ein anderes Medium als das Internet verbietet. Software, die aber die kommerzielle Verwendung ausschließt, gilt bei Debian und anderen freien Softwareprojekten als unfrei.
Ein weiterer Punkt ist die schiere Größe des Spiels. Vor vier Jahren wurde in Debian schon diskutiert, wie man große Softwarepakete (>50 MB) eventuell in ein neues Archiv auslagern könne. Fakt ist, dass Urban Terror 1000 MB an Daten mit sich bringt und das normale Archiv zu stark belasten würde.


Zählt man alles zusammen ist Urban Terror zum einen nach Debians Richtlinien nicht frei und hat kein eigenständiges Debianpaket. Außerdem beansprucht es auf meinem vServer 25% des Arbeitsspeichers also ca. 50 MB. Das mag für einen richtigen Root-Server kein Problem sein. Bei mir haben all diese Punkte nach zwei Wochen dazu geführt, dass ich Urban Terror als Kandidaten nicht weiter verfolgt und es zum Schluss wieder vom Server entfernt habe.
Kurzes Fazit: Ein wirklich interessantes und gutes Spiel, dass sich problemlos mit Linux spielen lässt und eines der vielen Beweise dafür ist, welchen Einfluss die Quake3-Engine auf Freie Software hatte. Es erfüllt aber weder die hohen Ansprüche an Freie Software, noch ist es so in Debian integriert und ressourcenschonend, dass es mir leicht gefallen wäre, es für das kleine Spieleserver-Projekt zu nutzen.
[alle Screenshots via urbanterror.info]