Author: apo

Posted on

vsftpd und OpenArena: Konfiguration eines sicheren FTP-Servers mit ausschließlich anonymen Zugang

Vor kurzem ergab sich die Gelegenheit einen FTP-Server aufzusetzen. Für ein anderes Vorhaben abseits von linuxiuvat.de brauchte ich zuerst nur einen OpenVPN-Server, da aber noch ausreichend Leistung zur Verfügung stand, installierte ich zusätzlich noch vsftpd.

Der FTP-Server eignet sich ideal, um PAK3-Dateien von meinem OpenArena-Server herunterladen zu können. Falls der Spiel-Client nicht kompatibel sein sollte, wird der Client automatisch beim Verbinden zum FTP-Server umgeleitet und lädt von dort Patches, Karten, Texturen und neue Sounds herunter.

Installation und Konfiguration

Vsftpd ist stark konfigurierbar und beherrscht noch viele weitere Optionen, die mit man vsftpd.conf einsehbar sind. Ein sicherer anonymer Zugang zum Herunterladen ohne Berechtigungen zum Dateiupload, lässt sich mit wenigen Handgriffen so verwirklichen.

aptitude install vsftpd
dpkg-reconfigure vsftpd


Mit Hilfe von DebConf wird der FTP-Benutzer und das FTP-Wurzelverzeichnis festgelegt.

    1. Den Systembenutzer "ftp" für vsftpd einrichten.

    1. Das FTP-Wurzelverzeichnis definieren, aus dem der anonyme Benutzer nicht wechseln kann.

Die Standardeinstellungen kann man hier problemlos beibehalten.
Die weitere Konfiguration befindet sich in /etc/vsftpd.conf. Im Prinzip halten sich auch hier die Veränderungen in Grenzen. An dieser Stelle dokumentiere ich nur die Veränderungen zur Standardinstallation mit Debian Squeeze.

nopriv_user=ftpsecure

Vsftpd verwendet einen weiteren unpriviliegerten und vollkommen isolierten Systembenutzer. In der Standardeinstellung ist das "nobody". Da dieser auch für andere Dienste oft verwendet wird, empfiehlt es sich aus Sicherheitsgründen noch einen weiteren, einzigartigen Systembenutzer anzulegen, z.B. ftpsecure.

adduser --system --no-create-home --disabled-login ftpsecure


Der FTP-Server wird zwar mit Root-Rechten gestartet, sobald aber eine Verbindung mit dem Client hergestellt wird, startet der Kindprozess mit den unpriviliegerten Rechten von ftpsecure und ftp.

# Die Dateiberechtigungen sollen für den anonymen Benutzer immer mit ftp:ftp angezeigt werden
hide_ids=YES
# Das FTP-Wurzelverzeichnis lässt sich mit dieser Variable ändern, wenn man
# nicht auf die DebConf-Methode zurückgreifen möchte.
# anon_root=/home/ftpsecure
# Maximale Anzahl an erlaubten gleichzeitigen Verbindungen. Entspricht bei
# mir der maximal möglichen Anzahl von Spielern auf dem OpenArena-Server.
max_clients=16
# Wieviele Verbindungen pro IP sind erlaubt
max_per_ip=4

Die gesamte vsftpd.conf sieht in meinem Fall so aus.

listen=YES
anonymous_enable=YES
dirmessage_enable=YES
use_localtime=YES
xferlog_enable=YES
connect_from_port_20=YES
nopriv_user=ftpsecure
ftpd_banner=Welcome to another FTP service.
secure_chroot_dir=/var/run/vsftpd/empty
pam_service_name=vsftpd
rsa_cert_file=/etc/ssl/private/vsftpd.pem
hide_ids=YES
max_clients=16
max_per_ip=4

Abschließend lässt sich mit mount --bind das Datenverzeichnis von OpenArena noch einmal im FTP-Wurzelverzeichnis im Unterordner /oa/baseoa nur lesbar einhängen. Um die Veränderung dauerhaft zu behalten, kann der Vorgang auch in /etc/fstab festgeschrieben werden.

/usr/share/games/openarena/baseoa       /srv/ftp/oa/baseoa      none     ro,bind        0       0

Nach diesem Schema lassen sich weitere Verzeichnisse nur lesbar im FTP-Wurzelverzeichnis einhängen.

Einstellungen für OpenArena

In der server.cfg von OpenArena kann man festlegen, ob der Download von Dateien erlaubt ist oder nicht.

sets sv_allowdownload 1

Ist das Herunterladen wie in diesem Fall mit 1 gestattet, wird mit sv_dlURL bestimmt, von welchem Web- oder FTP-Server der Client die Dateien beziehen soll, sofern sich seine Version von der des Servers unterscheidet. Der Vorgang ist auch als Fast Download bekannt und ein Feature, dass nach der Veröffentlichung des Quellcodes von Quake3 hinzugefügt worden ist.

sv_dlURL "ftp://123.123.123.123/oa"

Dabei kann man den letzten Schrägstrich nach dem Verzeichnis "oa" weglassen, da er automatisch durch den OpenArena-Server gesetzt wird. Im Verzeichnis "oa" auf dem FTP-Server muss das Unterverzeichnis baseoa erstellt werden, welches wiederum die PAK3-Dateien zum Spielen enthält.
Gibt man keine URL zum Herunterladen an, liefert der OpenArena-Server die Dateien nach der alten Quake3-Methode selbst aus, was sehr lange dauern kann. In neueren Versionen der ioquake3-Engine gibt es die Möglichkeit eine neue Variable zu definieren, welche die Download-Geschwindigkeit erhöht. Folgender Wert setzt diese auf 100 Kb/s pro Client fest.

sv_dlRate "100"

Wichtig
Wer bei Debian und Ubuntu einzelne Custom Maps zum Download anbieten möchte, muss diese bei OpenArena 0.8.8 im versteckten Verzeichnis /var/games/openarena/.openarena/baseoa ablegen, wo sich auch die server.cfg befinden kann, wenn man sich nicht für /etc/openarena-server/ entschieden hat. Auf dem FTP-Server hingegen verändert sich nichts und alle PAK3-Dateien liegen weiterhin im Verzeichnis baseoa.

Posted on

Logwatch der Loganalysierer: Ein Beispiel mit Lighttpd

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

Zur Zeit benutze ich Monit zur Überwachung von Prozessen wie Lighttpd oder den Spieleservern. Es kam in der Vergangenheit bei OpenArena z.B vor, dass der Server wegen eines unbekannten Fehlers unregelmäßig gecrasht ist. Dank Monit wird der Server automatisch neugestartet.
Für den langfristigen Trendverlauf bei Systemressourcen oder Benutzung der Spieleserver verwende ich Munin, womit die Werte grafisch anschaulich aufbereitet werden.
Die Mehrzahl der Daten wird natürlich in Logdateien gespeichert. Da die Menge an Informationen manuell nicht in annehmbarer Zeit zu überprüfen ist, braucht es einen Loganalysierer, der die Daten für Menschen lesbar aufbereitet und im Idealfall nur die "wichtigen" Informationen herausfiltert.
Ein bekannter Loganalysierer heißt Logwatch, den ich am längsten kenne und seit Anfang an für den Server benutze. Speziell für Berichte über die Vorgänge mit der Firewall gibt es aber auch noch FwLogwatch. Ebenfalls angeschaut habe ich mir Logcheck, Swatch und Tenshi. Snort steht auf jeden Fall noch auf der Todo-Liste und mit Tiger als Auditor habe ich auch schon gute Erfahrungen gemacht.

Logwatch

aptitude install logwatch

Ein großer Pluspunkt von Logwatch ist, dass es direkt nach der Installation einfach funktioniert und täglich eine Zusammenfassung als Textmail an Root und die externe Adresse schickt, sofern man zuvor einen Mailserver eingerichtet hat.
Logwatch ist in der Standardeinstellung auf einen niedrigen Detaillevel eingestellt. Die Werte reichen von 0 (low) über 5 (medium) bis 10 (high). Grundsätzlich werden die Logs der letzten 24 Stunden analysiert, wozu der Cronjob in /etc/cron.daily/00logwatch aufgerufen wird. Diese Zeitsteuerung lässt sich wie schon beschrieben über das Verschieben von 00logwatch in den entsprechenden Cron-Ordner oder durch die Bearbeitung der Crontabs ändern.
Die Reichweite der Loganalyse kann auch per Option direkt an Logwatch übergeben werden. Weitere Hinweise dazu finden sich mit logwatch --range Help.

Konfigurationsbeispiel mit Lighttpd

Für einen tiefergehenden Einblick in die Materie empfehle ich einen Blick in Howto-Customize-Logwatch.gz und Readme.Debian in /usr/share/doc/logwatch/ zu werfen. Das Konzept der Konfiguration ist dort ausführlich beschrieben.
Prinzipiell finden sich in den Unterverzeichnissen logfiles und services in /usr/share/logwatch/default.conf die Regeln, welche Logdateien analysiert werden sollen und Parameter, die den Output näher bestimmen. Die tatsächliche Arbeit verrichten aber die Skripte in /usr/share/logwatch/scripts.
Die zentrale Konfigurationsdatei ist logwatch.conf und befindet sich zusammen mit ignore.conf in /usr/share/logwatch/default.conf. Schon rein aus formalen Gründen habe ich aber alle Dateien dort unangetastet gelassen, da Debian selbst die Werte im Verzeichnis /usr/share/logwatch/dist.conf/ überschreibt und jede individuelle Einstellungen wie gewohnt in /etc/logwatch/ festgelegt wird.
Die Unterverzeichnisse in /etc/logwatch/ spiegeln die Verzeichnisstruktur in /usr/share/logwatch wider. Man muss also nur die modifizierten Dateien für Logfiles und Services dort ablegen.
In meinem Fall habe ich den Service http angepasst, der standardmäßig auf die Analyse von Apache ausgerichtet ist. Mit wenigen Handgriffen funktioniert er aber auch für Lighttpd.

Kopieren

/usr/share/logwatch/default.conf/logfiles/http.conf --> /etc/logwatch/conf/logfiles/
/usr/share/logwatch/default.conf/services/http.conf --> /etc/logwatch/conf/services/

Anpassen

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

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

wird der relative Pfad zu /var/log und meinen Logdateien festgelegt, wobei es noch drei weitere Zeilen in dieser Form gibt, die auf die anderen Logdateien verweisen.
Die zweite http.conf Datei ist der sogenannte Filter oder Service, der auf die Logdateien angewendet wird. Ich habe den Titel auf "Lighttpd" gesetzt und den Detaillevel auf 10 erhöht. Dadurch wird der Standard von 0 überschrieben und die Ausgabe von Lighttpd deutlich "lauter". Der Rest beschränkt sich darauf Parameter auszukommentieren, die nützlich sein können, z.B.

$HTTP_USER_DISPLAY = "$field{http_rc} >= 400"

womit alle HTTP-Fehlermeldungen >= 400 angezeigt werden.

override.conf

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

logwatch: Service = "-iptables"

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

Fazit

Das Kopieren und Editieren der Konfiguration ist bei Logwatch erst einmal Gewöhnungssache. Der Vorteil liegt darin, dass die Originaldateien unangetastet bleiben und man alles ordentlich dort hat, wo es hingehört, in /etc. Wer viele Veränderungen vornehmen muss und diese auf mehrere Server anwendet, sollte besser über eine Neukompilierung des Pakets nachdenken.
Mir gefällt Logwatch sehr gut, da es bisher die anderen Methoden gut ergänzt. Logwatch ist ein Teil der Lösung aber eben nicht alles. Für mich ist eine tägliche E-Mail-Benachrichtigung ausreichend. Außerdem ist die Standardkonfiguration sehr gut. Wer noch mehr Kontrolle und andere Voreinstellungen bevorzugt, sollte sich Logcheck anschauen. Dort wird man anfangs sogar stündlich informiert und kann durch Reguläre Ausdrücke festlegen, was man sehen möchte oder eben nicht.

Posted on

Blockorientierte Geräte und der Mythos mit dd

Den interessanten Thread zu Wheezy und dem Umgang mit begrenztem Platz auf Installations-CDs habe ich noch eine Weile weiterverfolgt. In den Kommentaren zu meinem letzten Beitrag gab es gemischte Stimmen, aber ich denke, die meisten waren sich einig, Daten-CDs stellen immer mehr eine Randerscheinung dar. Audio-CDs behalten noch eine Weile ihren nostalgischen Wert als "Musik zum Anfassen" und manchmal hat man sie einfach noch im Schrank, weil die 50er-CD-Spindel einfach nicht kleiner werden möchte.

Mir geht es ähnlich, die meisten CD-Rohlinge im meinem Schrank habe ich mal als Geschenk erhalten. Als Endnutzer bin ich von dem Thema nicht akut betroffen, ich verwende fast immer die Netzinstallation, installiere eine Basisinstallation und baue von dort mir mein eigenes Wunschsystem zusammen.
Der Thread spaltete sich danach ein wenig auf und verzweigte sich in verschiedene Richtungen. Plötzlich wurde auch das Thema angesprochen, wie Debian Benutzern die Installation von USB-Sticks vermittelt.

dd - suboptimale Performance

dd if=debian.img of=/dev/sdX

Bevor ich nun mit Korrekturmails überzogen werde, das ist nicht der Weg den Debian beschreibt. Ich persönliche hatte aber jahrelang im Hinterkopf: dd ist das sinnvollste Kommando für blockorientierte Geräte und ist eben auch für USB-Sticks gedacht.
Debian schlägt z.B vor

cat - Alternative und schneller

cat debian.img > /dev/sdX

Der Cat-Befehl vollbringt die gleiche Aufgabe, funktioniert aber auf den meisten Systemen effizienter als dd. Das ist aber nur der Fall, wenn man vergessen hat bs= als Option bei dd anzuführen.

dd - der bessere Weg

Für das Schreiben auf blockorientierte Geräte wurde eine Größe von 4 MB für die Option bs empfohlen. Jeder Eingabeblock wird dabei durch die Option oflag=sync zur maximalen Größe von 4 MB mit Nullen aufgefüllt, sollte er kleiner sein.
dd if=debian.img of=/dev/sdX bs=4M oflag=sync

cp - auch das ist möglich

Früher habe ich gelernt, dass man dd für Abbilder benutzt, das GNU-Kommando cp hingegen nur für das Kopieren von Dateien auf eingehängten Datenträgern. Man lernt bekanntlich nie aus, aber cp kann ebenfalls Abbilder auf blockorientierte Geräte schreiben.

cp debian.img /dev/sdX


Ein weiterer interessanter Tipp war anstelle von /dev/sdX z.B. in /dev/disk/by-id/ nach dem USB-Stick zu schauen und diese Datei zu benutzen, wenn man sicherer auf das eigene USB-Gerät verweisen möchte.
Am Ende erfüllen alle Kommandos ihren Zweck. Bei dd werde ich in Zukunft noch mehr auf die Option bs achten und in den alten Artikeln, wo ich darauf nicht hingewiesen habe, das nun nachholen.

Posted on

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. 😈

Posted on

XZ-Kompression, Wheezy Freeze und ab Ubuntu 12.10 keine CDs mehr

Auf der Mailingliste der Debian-Entwickler, debian-devel, wurde vorgestern ein interessantes Thema in Gang gesetzt: "Wheezy release: CDs are not big enough any more"
Irgendwann hat es die Floppies erwischt, nun scheint es so, als ob CDs das gleiche Schicksal ereilen würde. Der Platz geht aus. Debian und Ubuntu unterstützen bisher die Installation einer kompletten Desktopumgebung mit Gnome, KDE, Xfce und LXDE mit jeweils einer separaten CD. Zusätzlich existieren noch Live-CDs, die ich schon scherzhaft in Kebian, Lebian und Xebian umbenennen wollte. Für die restlichen mehr als 30000 Pakete werden weitere CD-Abbilder vorgehalten, die in der Regel nicht gebraucht werden, sofern man über einen Internetanschluss verfügt.
Da der Freeze für Wheezy immer näher rückt, angepeilt ist die zweite Hälfte des Juni, hat Steve McIntyre auf debian-devel die Frage gestellt, wie man nun alle notwendigen Daten auf nur eine CD unterbringen will.

XZ-Kompression

Tatsache ist, dass auch schon in der Vergangenheit nicht jede Komponente des Gnome-Desktops auf der ersten CD Platz fand und deswegen die fehlende Software über das Internet nachgeladen werden mussten. Ein möglicher Lösungsansatz ist die Verwendung von XZ-Kompression anstatt von gzip oder bzip2, das Aufgeben von CDs zu Gunsten von DVDs oder gar die Abkehr von Gnome als Standardinstallation hin zu leichtgewichtigeren Desktopumgebungen wie z.B. LXDE.
XZ-Kompression, auch bekannt unter dem Namen des verwendeten Algorithmus LZMA, bietet hier einige Vorteile. Wer die xz-utils installiert hat und z.B. mit tar und der Option "-J" Daten komprimiert, stellt schon bald die deutlich verbesserte Kompressionsrate fest. XZ scheint bei mir Daten förmlich zu "verdampfen". Große Abbilder von Festplatten oder Partitionen, die ich mit Partimage oder Partclone sichere, werden regelmäßig mit xz komprimiert und auch die ein oder andere SQL-Datei schrumpfte schon von 109 MB auf lediglich 15 MB zusammen. Gerade für Backupzwecke und zum Platzsparen, wenn Daten Monate oder gar Jahre unangetastet bleiben, ist das äußerst nützlich.
Der Nachteil liegt jedoch in der speicher- und zeitintensiveren Erzeugung der Kompression gegenüber den etablierten Formaten gz und bz2. Im Gegensatz dazu erfolgt die Dekompression der Daten nur unwesentlich langsamer als bei gzip und ist ungefähr doppelt so schnell als bei bzip2. Das macht XZ gerade für das Komprimieren von Binärdateien und Softwarepaketen interessant. Arch Linux hat hier schon vor zwei Jahren umgestellt.
Da die Rechenleistung auf den Build-Daemons zur Erzeugung von Binärdateien anfallen, bekommt der Endanwender von der Veränderung nichts mit, sieht man mal von der geringeren Dateigröße ab. Im gleichen Entwickler-Thread wurde aber auch ein Problem eines universellen Betriebssystem angesprochen, denn Debian lässt sich auch mit Hilfe von Debootstrap von fremden Systemen aus installieren. Da ältere Versionen von Debootstrap XZ noch nicht unterstützen, könnte das auch auf Android-Smartphones mit Debian zum Problem werden.

Was macht Ubuntu?

Wie geht Ubuntu mit der selben Herausforderung um? Steve Langasek, Debian-Entwickler, ehemaliger Release Manager und jetzt Angestellter von Canonical, kündigte hier schon mal für Ubuntu 12.10 an, dass es keine CDs mehr geben und die Größe des Installationsabbildes auf 800 MB anwachsen wird. In Zukunft werden also nur noch DVDs, USB-Sticks und natürlich die Netzinstallation unterstützt.
In Anbetracht des bevorstehenden Freeze bei Debian kann ich mir vorstellen, dass die Umstellung auf XZ-Kompression bei den Binärpaketen noch etwas aufgeschoben wird, die das eigentliche Problem leider auch nur verlangsamen können. Für eher wahrscheinlich halte ich da das Szenario "Keine CDs mehr" oder "CD1 + CD2" für eine Desktopinstallation.
Für mich steht aber schon heute fest, ich bleibe weiterhin bei der Netzinstallation bzw. alternativen Installation von Ubuntu. Wie seht ihr das? Sind CDs Geschichte?

Posted on

Iceweasel: Downgrade von libcairo2 beseitigt Grafikfehler

Update 04.08.2012: Der folgende Bug wurde für mich heute mit dem Paket xserver-xorg-video-nouveau 1.0.1-3 für Wheezy und meine Geforce 9600GT gelöst.
Ich konnte schon lange nichts mehr über einen Bug schreiben, weswegen ich mich heute natürlich sehr gefreut habe, dass es wieder was zum Bloggen gibt. Wer innerhalb der letzten 24 Stunden ein Upgrade gemacht hatte, konnte mitunter in Debian Testing feststellen, dass ganze Textpassagen in Iceweasel unleserlich geworden sind. Es schien so als ob sich Quadrate über den Text legen würden, Text wurde verzerrt und vollkommen unleserlich.
Näher nachgeforscht ist das ein Renderingproblem und auf einen Bug im X-Server zurückzuführen, der schon mindestens seit zwei Monaten im Debian-Bugtracker bekannt ist. Genauer gesagt brachte erst eine Veränderung in der Bibliothek libcairo2 den Fehler zum Vorschein.
Alles in allem nichts Ungewöhnliches, wenn man Unstable oder Testing benutzt. Mit einem Downgrade auf die Version 1.10.2-7 in den Backports von Debian Stable, konnte ich dieses Problem lösen.
Ich habe mich nur gefragt, warum die Version 1.12.2-1 von libcairo2 überhaupt nach Testing migrieren durfte, da ich noch nie so viele "Grave"-Bugs gesehen habe, die gegen ein Paket eröffnet worden waren. Sollte hier jemand mehr wissen, würde ich mich über einen aufklärenden Kommentar freuen.

Posted on

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.

Posted on

Drei Aufräumtipps mit Aptitude für Debian und Ubuntu

Ich stelle gerne von Zeit zu Zeit ein paar Tipps und Tricks vor, wie man mit Debians Systemwerkzeugen sein eigenes Betriebssystem sauber und minimal halten kann. Zum Installieren und Entfernen von Software benutze ich am liebsten Aptitude.
Nun bin ich mit Sicherheit nicht der Einzige, der Debian und Ubuntu benutzt. Andere Leute wie z.B. Raphaël Hertzog haben in der Vergangenheit schon viele nützliche Beiträge hierzu geschrieben. Da er selbst Debianentwickler ist und einige essentielle Werkzeuge für Debian mitentwickelt, möchte ich einige seiner Ideen gerne vorstellen, so wie ich das in der Vergangenheit beim Thema CUT getan habe.
Hier sind drei Tipps wie man mit Aptitude und einem Linuxterminal sein System aufräumen kann. Wer gerne grafische Programme bevorzugt, wird all diese Optionen auch mit Synaptic finden können. Die Aptitude-Methode ist meiner Meinung nach aber universeller (und ressourcenschonender 😉 ). Im folgenden gebe ich die entsprechenden Aptitude-Befehle immer in Kurz- und Langschreibweise an. Ihr könnt den Suchbefehl search natürlich jederzeit durch purge ersetzen, um die Dateien endgültig zu entfernen.

1. Nicht benötigte Konfigurationsdateien endgültig löschen

Wenn man ein Paket mit aptitude remove oder sogar aptitude purge löscht, kann es vorkommen, dass einzelne Pakete dennoch Konfigurationsdateien zurücklassen. Oft ist das sogar ein erwünschter Zustand, da bei einer Neuinstallation eben die Konfiguration nicht neu erstellt werden muss, sondern direkt aus den zuvor zurückgebliebenen Dateien wiederhergestellt wird.

Suchen und Löschen

aptitude search ~c
aptitude search ?config-files

2. Entfernen von obsoleten Paketen

Debian läuft über Jahre stabil. Um diesen Qualitätszustand zu erreichen, durchläuft jedes Paket verschiedene Zweige innerhalb der Distribution von Experimental, Unstable über Testing bis Stable.
Es kann jedoch vorkommen, dass das Qualitätssicherungsteam das Entfernen eines Pakets beantragt, weil es entweder nicht mehr durch den ursprünglichen Upstream-Entwickler weiterentwickelt wird oder das Paket nicht mehr innerhalb von Debian betreut wird. Genauso gut kann ein Paket aus wichtigen Gründen umbenannt worden sein, weil der Paketbetreuer dem Benutzer zu einem Zeitpunkt mehrere Versionen anbieten wollte oder die alten Pakete in Übergangspakete für eine Veröffentlichung umbenannt wurden, aber in der darauf folgenden nicht mehr gebraucht werden.
Zurück bleiben irgendwann nur noch obsolete Pakete, die keine Sicherheitsaktualisierungen mehr erhalten und im schlimmsten Fall nutzlos auf der Festplatte verkümmern.

Suchen und Löschen

aptitude search ~o
aptitude search ?obsolete


Nicht immer möchte man alle als obsolet eingestuften Pakete löschen. Wenn man Pakete von Drittanbietern (wie z.B. Brother-Treiber) installiert hat, würden diese mit purge ebenfalls entfernt. Hier ist es deshalb besser mit

aptitude why "Paketname"


nachzuforschen, warum das Paket installiert wurde.

3. Pakete aus Drittquellen suchen und entfernen

Es gibt kaum einen Grund, warum man Drittquellen in Debian freischalten sollte. Hilfreich fand ich bisher aber immer deb-multimedia.org, wenn es z.B darum ging einen WebM-kompatiblen MPlayer für Debian Stable zu installieren. Natürlich nur, wenn es die neuere Version nicht schon in Debian-Backports gibt.
Bei Ubuntu hingegen erliegt man öfter der Versuchung mal das ein oder andere PPA freizuschalten und ja, manche sind auch wirklich nützlich. Möchte man herausfinden, welche Pakete auf dem eigenen System aus Drittquellen stammen, lässt sich das mit Aptitude so lösen:

Suchen und Löschen

aptitude search '~S ~i !~ODebian !~o'
aptitude search '?narrow(?installed, !?origin(Debian))!?obsolete'


Will man hingegen wissen, welche Pakete nicht aus dem Debian-Zweig stammen, den man gerade verwendet (in diesem Fall "Testing"), funktioniert dieser Befehl.

aptitude search '?narrow(?installed, !?archive(testing)?origin(Debian))'


Hierbei werden alle Pakete angezeigt, die nicht der Version entsprechen, die gerade in Testing verfügbar ist oder die aus anderen Zweigen wie Experimental oder Unstable stammen.

Posted on

Schickes Booten mit Debian und eine Bitte

Vor kurzem war es auch in Debian Testing soweit. Dank einem Update von lsb-base ist das Booten nun endlich schick geworden. Ich kann mich noch dran erinnern, dass ich mich schon vor ungefähr zehn Jahren gefragt habe, warum Debian eine der wenigen Distributionen war, wo es keine farbige Anzeige gab, die signalisierte, ob Dienste erfolgreich gestartet worden waren oder eben nicht.
Hatte es vielleicht technische Gründe oder war man der Meinung, es würde den Benutzer verwirren und vom Wesentlichen ablenken? Ich wusste es nicht, schaute aber immer ein wenig neidisch zu RedHat, Mandriva, SuSe und Arch Linux. Zugegeben es war nicht wirklich kritisch und der bisherige Output gefiel mir sogar besser als die grafische Lösung mit Plymouth.
Ab sofort gibt es jetzt also Statusmeldungen wie

[ ok ]
[info]
[warn]
[FAIL]

in den passenden Signalfarben.
Nur noch ein Wunsch für das Booten bleibt. Bitte, bitte Ubuntu ich möchte nicht nach jedem Kernelupdate einen neuen Eintrag in GRUB vorfinden, weil sich die Versionsnummer wieder um eine Kleinigkeit geändert hat. Schlimmer noch, die alten Kernel nehmen unnötig Platz weg, weswegen ich schon vor vier Jahren den Weg zum Entfernen beschrieben habe...
Eine alte und eine aktuelle Kernelversion, so wie es sie bei Arch Linux gibt, das wäre was. Selbst bei Debian verändert sich momentan an dem 3.2 Kernel nichts. Nein, sonst habe ich keine Probleme. 🙂

Posted on

Tipp: Probleme mit Nvidia-Treibern lösen – Downgrade von Precise auf Oneiric

Nach meinem Upgrade auf Lubuntu 12.04 stellten sich, wenig überraschend, die gleichen Probleme wie mit Debian Sid ein. Die neuesten Nvidia-Treiber 295.40 verursachen bei mir, Kero und wahrscheinlich noch einer Reihe anderer Leute Verzögerungen beim Verschieben von Anwendungen, die teilweise bis zum Einfrieren des gesamtes Desktops führen können.
Das Problem ist bekannt und betrifft unter anderem Geforce 6, 7 oder 8800GTX/GTS Karten. Ich benutze jedoch eine Geforce 9600 GT, die bis zum Update auf Lubuntu 12.04 einwandfrei funktionierte.
Seid ihr von ähnlichen Problemen betroffen, habt ihr folgende Optionen zur Hand.

1. Nvidia-Treiber komplett entfernen

sudo aptitude purge nvidia-current


Die Treiber lassen sich mit diesem Befehl komplett entfernen. Nach einem Neustart wird der Nouveau-Treiber aktiv, dessen Performance in der Regel für "normalen" Desktopbetrieb ohne anspruchsvolle 3D-Spiele oder Compiz ausreichend ist.

2. Downgrade der Nvidia-Treiber von Precise auf Oneiric

Für diverse Setups sind weiterhin die Nvidia-Treiber notwendig. In diesem Fall könnt ihr einen Downgrade von Nvidia 295.40 (Precise) auf 280.13 (Oneiric) in Erwägung ziehen.

Ein Downgrade kann zu Problemen und anderen Inkompatibilitäten führen. Jetzt wäre der richtige Zeitpunkt für ein Backup. Wer sich bei den folgenden Schritten unsicher ist, sollte sie nicht ausführen!

Öffnet die /etc/apt/sources.list mit eurem bevorzugten Editor und schaltet das alte Apt-Repositorium für Oneiric und die "restricted"-Sektion frei, indem ihr diese Zeilen hinzufügt.

deb http://de.archive.ubuntu.com/ubuntu/ oneiric main restricted
deb http://security.ubuntu.com/ubuntu oneiric-security main restricted

Nvidia-Treiber downgraden

sudo aptitude update
sudo aptitude -t oneiric install nvidia-current


Apt warnt vor dem Downgrade, dass das virtuelle Paket xorg-video-abi-10 nicht gefunden werden kann. Mit "n" lehnt ihr die erste Lösung ab und akzeptiert die zweite. Dies solltet ihr nur tun, wenn ihr auf die zum Entfernen markierten Pakete auch tatsächlich verzichten könnt. Der Vorgang sah bei mir so aus:

sudo aptitude -t oneiric install nvidia-current
Die folgenden Pakete haben verletzte Abhängigkeiten:
 nvidia-current : Hängt ab von: xorg-video-abi-10 , welches ein virtuelles Paket ist.
Die folgenden Aktionen werden diese Abhängigkeiten auflösen:
     Beibehalten der folgenden Pakete in ihrer aktuellen Version:
1)     nvidia-current [Nicht installiert]
Diese Lösung akzeptieren? [Y/n/q/?] n
Die folgenden Aktionen werden diese Abhängigkeiten auflösen:
      Entfernen der folgenden Pakete:
1)      xserver-xorg-input-all
2)      xserver-xorg-input-synaptics
3)      xserver-xorg-video-all
4)      xserver-xorg-video-sisusb
5)      xserver-xorg-video-tdfx
6)      xserver-xorg-video-trident
7)      xserver-xorg-video-vesa
Downgrade der folgenden Pakete:
9)      xorg [1:7.6+12ubuntu1 (now, precise) -> 1:7.6+7ubuntu7.1 (oneiric)]
10)     xserver-xorg [1:7.6+12ubuntu1 (now, precise) -> 1:7.6+7ubuntu7.1 (oneiri
11)     xserver-xorg-core [2:1.11.4-0ubuntu10.1 (now, precise-updates) -> 2:1.
usw.

Nach dem Downgrade ist es am sinnvollsten die neuen Nvidia- und Xserver-Pakete auf "Halt" zu setzen, damit sie beim nächsten Update nicht erneuert werden.
sudo aptitude hold '~nnvidia'
sudo aptitude hold '~nxserver'
Welche Pakete das genau sind, erfahrt ihr mit
aptitude search '~ahold'
In meinem Fall hat das Downgrade das Problem vollständig beseitigt und das System läuft stabil. Ihr solltet nun von Zeit zu Zeit überprüfen, ob es eine neuere Nvidia-Version gibt, die das Problem lösen kann.
Die Pakete lassen sich mit
sudo aptitude unhold '~nnvidia'
sudo aptitude unhold '~nxserver'
wieder zum Aktualisieren freigeben.
Update: 06.05.2012

3. Upgrade auf nvidia-current in Quantal Quetzal

Als dritte Möglichkeit könnt ihr den Nvidia-Treiber auf die aktuelle Version in Ubuntu "Quantal Quetzal" bringen. (z.Z. 295.49). Dazu ersetzt ihr das Wort "oneiric" in den vorhergehenden Schritten durch "quantal".
Bei Lubuntu 12.04 und meiner Geforce 9600 GT funktionierten alle drei nur die ersten beiden Möglichkeiten. Nachdem ich jetzt noch etwas länger mit 295.49 experimentiert habe, treten ab und an immer wieder Ruckler und Verzögerungen beim Verschieben von Fenstern auf. Für mich ist daher diese Version nicht die richtige Lösung.