Dwb und Jumanji: Zwei Webkit-Browser mit vi-ähnlicher Steuerung

Letzte Woche hat mich Georg auf einen interessanten Webkit-Browser namens Jumanji aufmerksam gemacht. Ich ergreife hier die Gelegenheit und stelle sowohl Jumanji als auch Dwb kurz vor. Beide setzen auf die Webkit-Engine und eine vi-ähnliche Steuerung und eignen sich als leichtgewichtige Browser-Alternative nicht nur für ältere Rechner.
Die Bilder stammen alle von meiner ArchLinux-Installation auf dem Inspiron 4000.

Jumanji

Jumanji ist ein minimalistischer WebKit-Browser, dessen Interface schlicht und platzsparend und deswegen auch sehr übersichtlich ist.


Die Bedienung lässt sich tatsächlich mit dem Stichwort vi-ähnlich auf den Punkt bringen. Genauso wie bei seinem berühmten Vorbild betritt man mit dem Doppelpunkt den Kommandomodus und kann von dort diverse Befehle aufrufen. Besonders praktisch ist es mit Hilfe von Tab-Vervollständigung von Befehl zu Befehl zu wechseln. Noch schneller geht es nur noch mit Tastenkürzeln, die man wie bei vi durch das ":map"-Kommando definieren kann.

Neue Tabs öffnet man entweder mit :tabopen oder mit der Taste t. Sie erscheinen in dezentem schwarz hinterlegt am oberen Bildschirmrand. Aktive erkennt man durch die geänderte Schriftfarbe. Interessant ist auch, dass man durch den Browserverlauf mit Tab-Vervollständigung navigieren kann. Mit der rechten Maustaste lässt sich ein kleines Menü aufrufen, um die Seite neu zu laden oder vor- und zurück zu wechseln.

Jumanji lässt sich bei Arch Linux aus dem AUR installieren. Wer yaourt benutzt, erledigt das mit:

yaourt -S jumanji-git


P.S.: Als Randnotiz fiel mir noch der Webseitengenerator der offiziellen Jumanji-Homepage auf. Hakyll ist eine Haskell-Bibliothek, um statische Webseiten zu generieren. Nur falls jemand dachte, es gäbe keine weiteren Alternativen zu den schon im Artikel und Kommentaren genannten Blogkompilierern. 🙂

Dwb

Im Gegensatz zu Jumanji existiert von Dwb seit kurzem eine offizielle Debianversion in Sid und Wheezy.

Dwb basiert ebenfalls auf der Webkit-Engine, besitzt vi-ähnliche Tastaturkürzel und Kommandos und zeichnet sich durch eine ebenso schlanke und effiziente Benutzerschnittstelle aus. Tatsächlich ähneln sich Jumanji und Dwb in vielerlei Hinsicht.
Der große Unterschied ist jedoch, Dwb hat das Konzept schon deutlich weiter entwickelt. Er ist umfangreicher, bietet mehr Kommandos und Funktionen. Genauso wie bei Jumanji lässt sich ein Adblock-Skript einbinden, darüber hinaus besteht aber auch die Möglichkeit Javascript oder Flash zu blockieren. Neue Tabs lassen sich mit O öffnen und d schließen. Lesezeichen werden mit M hinzugefügt und übersichtlich mit gB angezeigt und in einem neuen Tab geöffnet. Links kann per Tastatur gefolgt werden.
Besonders erwähnenswert ist auch, dass sich Einstellungen und Optionen auf einer Extraseite innerhalb des Browsers konfigurieren lassen und die Dokumentation in einem guten Zustand ist. Die Handbuchseite ist vorbildlich.


Die Suche funktioniert genauso wie bei Vi/Vim, indem die Taste / benutzt, der Suchbegriff eingegeben und schließlich n zur Vorwärtssuche ausgeführt wird.

Fazit

Mir gefallen tastaturgesteuerte, leichtgewichtige Webbrowser. Dwb hat bei mir aber gegenüber Jumanji die Nase vorn. Beide ähneln stark dem Vimperator-Plugin des Firefox, setzen aber stattdessen auf die Webkit-Engine und ordnen sich in die Reihe von Webbrowsern wie Vimprobable, Uzbl oder Surf ein.
Webkit-Browser sind nicht wirklich ungewöhnlich, was für die Engine spricht.
Der Speicherverbrauch und auch die Reaktionsgeschwindigkeit lässt sich am besten mit der von Surf vergleichen. Wie im letzten Test, habe ich wieder ps_mem.py als Maßstab benutzt.

Jumanji:
Private: 19MB + Shared: 1,3MB = 20,3MB
Dwb:
Private: 21,1MB + Shared: 2MB = 23,1MB

Die Startzeiten waren sogar noch schneller als bei Surf, obwohl das auch an dem selbstkompilierten ArchLinux-Paket liegen kann. Für die Zukunft werde ich dwb häufiger benutzen und denke, dass es eine gute Wahl war ihn in Debian aufzunehmen, da er sich durch seine umfangreiche vi-ähnliche Steuerung von den anderen Browsern in Debian positiv unterscheidet.

Debian GNU/Linux Gerätetreiberüberprüfungsseite

Was für ein Wort, doch der Inhalt hat es in sich. Meine Suche nach freien Treibern für meine Hardware war in der Vergangenheit manchmal lang und steinig, die passende für den Internetzugang habe ich aber mittlerweile gefunden. Teilweise achte ich nicht mehr darauf, ob ein älteres Laptopmodell unter Linux vollständig erkannt wird. Sieht man mal von WinModems ab, hatte ich hier auch noch nie Probleme und alles wurde einwandfrei erkannt.
Anders kann die Sache bei sehr neuen Modellen aussehen, wenn viel Geld im Spiel ist und man sich nicht blind auf sein Gefühl verlassen möchte. Über den IRC bin ich in #debian schon öfter auf

http://kmuto.jp/debian/hcl/

gestoßen. Auf dieser Seite werden Informationen zur Kompatibilität von PCI-Geräten mit aktuellen Kerneltreibern bereitgestellt. Jeder der selbst Zugang zu einem Linux mit Terminal hat, kann mit lspci -n mehr über die Unterstützung seiner Hardware herausfinden. Einfach die Ausgabe in das Formularfeld kopieren und abschicken.
Eine ziemlich nützliche Seite, wie ich finde, nicht nur für Debianbenutzer.

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.

Gnome-Shell-Extensions mit Debian und Gnome 3.4

Einige Erweiterungen zur Gnome-Shell befinden sich mittlerweile in Debian Testing, weswegen ich mir vor einigen Wochen das Paket gnome-shell-extensions installiert habe. Nach dem großen Upgrade von Gnome 2 auf Gnome 3, habe ich bisher nur ganz wenige Aspekte des Standarddesktops geändert, darunter das Statusmenü.
Wer größeren Veränderungsbedarf hat findet viele weitere Erweiterungen auf extensions.gnome.org, wo sich die Alpha- zum Betastadium gewandelt hat. Ich persönlich kann der neuen Art und Weise wie Erweiterungen installiert werden einiges abgewinnen. Gnome ist weiterhin nicht der Desktop für die Do-it-yourself-Leute und besonders leichtgewichtig und für ältere Laptops geeignet ist er auch nicht gerade, aber er bleibt wenigstens seinen Zielen treu.
In der Vergangenheit habe ich die Debianentwickler und Mitglieder des Gnome-Teams in Schutz genommen und Verständnis dafür gezeigt, dass es mit dem Übergang von Gnome 2 zu Gnome 3 bei Debian länger dauert. Vor kurzem bin ich auch auf das Blog von Jordi Mallach, einer der Entwickler, gestoßen, dessen Artikel zum Thema "Gnome-Shell-3.2 in Wheezy" ich jedem empfehlen kann. Er unterstreicht noch einmal, dass Debian Gnome 3 eben für ein Dutzend Architekturen verfügbar macht, auch wenn wahrscheinlich nur die wenigsten jemals Debian GNU/kFreeBSD installieren werden.
Wie er selbst schreibt, sollte es nach den größten Veränderungen von nun an wieder schneller gehen. Der Status von Gnome 3.4 ist grün.
Hier sind ein paar Eindrücke der neuen Gnome-Shell-Erweiterungen als Ergänzung zur ersten Vorstellung.

Gnome-Shell-Erweiterungen


Die Gnome-Shell-Erweiterungen erscheinen als weitere Option im Gnome-Tweak-Tool. Ein An- und Aus-Schalter signalisiert den aktuellen Zustand. Installiert sind die offiziellen Erweiterungen, von denen ich lediglich das alternative Statusmenü und den CPU-Temperaturindikator gebrauchen konnte. Der Systemmonitor oder der zusätzliche Menüeintrag des Tweak-Tools im Statusmenü sind aber auch nicht verkehrt.

Statusicons


Einige Erweiterungen erscheinen nach der Installation direkt auf der oberen Leiste. Hier sind z.B. von links nach rechts der Wechselmedienumschalter, das Orte-Menü und der Arbeitsflächenindikator zu sehen.

Das Anwendungsmenü

Ist das nicht einer der Hauptgründe, warum viele doch lieber Cinnamon benutzen wollen? Das altbekannte Anwendungsmenü lässt sich ebenso leicht wie alle anderen Erweiterungen installieren und erscheint direkt neben den "Aktivitäten".

Vier ältere Laptops und ein Core Duo im April 2012

Ich weiß, es gab hier nicht wirklich viel Neues zu alternativen und leichtgewichtigen Betriebssystemen zu lesen, sieht man einmal von Haiku ab. Da ich selbst der kritischste Leser meines Blogs bin, fehlten mir auch ein paar Artikel zu coolen Konsolenprogrammen und noch ein paar Tipps und Tricks wie man sich ein effizientes Linuxsystem auf Basis von Fenstermanagern selbst zusammenstellen kann. Ich hoffe jemand schreibt diese Artikel noch für mich. 😉
Die Wahrheit ist auch, das Leben ist ein Karussell. Hätte ich einen Artikel über das Thema geschrieben, hätte er sich vermutlich wie der alte Sketch von Badesalz angehört: "Mir ist heute ein Waschlappen vom Haken gefallen, habe ich ihn halt wieder darauf gehangen." "Na toll." (kleine Übersetzung ins Hochdeutsche :)).
Gar nichts zu schreiben ist auch keine Lösung, deswegen hier die unglaublichen Erlebnisse mit vier älteren Laptops und einem Core Duo.

Core Duo

Letztes Jahr um diese Zeit war ich drauf und dran Ubuntu 10.10 gegen ein Multiboot-System auszutauschen. Ich wollte einfach mal wieder was anderes anstellen und nach und nach wurde Debian Testing zum Hauptsystem, Ubuntu der Dreh- und Angelpunkt für Experimente mit Videoeditoren und dem GIMP und Debian Sid zum Spielemekka.
Und heute...nun natürlich habe ich nicht schon wieder ein neues Multiboot-System aufgesetzt, Wiederholungen sind langweilig.
Seit November 2011 benutze ich mit Debian Testing Gnome 3 als meine Desktopumgebung der Wahl. Wer etwas kreuz und quer im Internet liest weiß, dass nicht jeder das neue Gnome toll findet. Nachdem ich die Extensions entdeckt und eine Erweiterung installiert hatte, die ich brauchte, gab es für mich keine großen Aufreger mehr.
Das lässt sich ganz leicht damit erklären, dass Gnome eben nur eine grafische Oberfläche für mich ist, die Regel jedoch mittlerweile alleinstehende Fenstermanager-Lösungen sind. Speziell auf den Status in Debian angesprochen, kann ich nur sagen, dass Gnome 3.4 langsam aber sicher Stück für Stück hier angekommen und nichts Aufregendes passiert ist. Die großen Veränderungen halten sich in Grenzen. Dennoch habe ich das Gefühl, dass insbesondere die Gnome-Shell nun reaktionsfreudiger reagiert. Insgesamt bin ich mit Gnome zufrieden und ich denke Debian leistet hier gute Arbeit.
Ab und zu sollte man sich mal selbst beobachten, wie viel Zeit man mit einzelnen Aufgaben und Anwendungen verbringt. Der Webbrowser scheint der Dreh- und Angelpunkt zu sein. Mein E-Mail-Programm Icedove landet auf einer Arbeitsfläche und bleibt dort ständig geöffnet, der Rest ist manchmal Mplayer, fast immer der Terminal mit Anwendungen wie Cmus*, ab und an LibreOffice, der Dateimanager und Virtualbox. Also genau die Programme, die bei mir in der linken Seitennavigation alias Dash untergebracht sind.
Ich brauche nicht zwangsläufig Gnome 3. Behindern tut es mich aber auch nicht und es ist eine gute Gelegenheit auf dem Laufenden zu bleiben und nicht die Trends zu verpassen ;). Von daher, bei Gnome 3 nichts Neues.

Quo vadis Ubuntu

Wenn ich sage Ubuntu, meine ich natürlich die Unity-Oberfläche. Ich habe nicht wirklich viel dazu in den letzten Monaten geschrieben und werde auch in Zukunft anderen das Feld überlassen. Unity ist mit Sicherheit eine Alternative, aber nicht mehr mein Schwerpunkt. Am ehesten lässt es sich mit Gnome 3 vergleichen und ich vermisse ehrlich gesagt nicht viel im Vergleich zu Unity, wenn ich Gnome 3 benutze.
Lubuntu ist es da schon eher wert weiter vorgestellt und verfolgt zu werden. Generell mag ich sowieso eher Underdogs. Aber wem erzähl ich da was Neues.

Fenstermanager, ein paar Laptops und die Konsole

Die Laptops gibt es natürlich noch. Ohne Veränderung, alles beim Alten. Der Dell Inspiron 4000 hat eine interessante Macke entwickelt. Ich denke, es ist nach dem Austausch der Festplatte passiert als ich Haiku installiert habe. Ab jetzt gelangt man nur noch in das GRUB-Menü, wenn man vorher ESC+F2 drückt und vorher im BIOS war. Scheinbar summieren sich die kleinen Alterserscheinungen. Doch solange er noch funktioniert, bleibt er natürlich an Bord.
Was den Rest angeht. Alte Laptops eignen sich hervorragend zur Administration eines Spieleservers. Von Konsole zu Konsole, wirklich kein Problem. Openbox ist weiterhin Nr.1, auch wenn sich DWM auf dem Thinkpad 600 ausgezeichnet schlägt.
Slitaz 4.0 ist erschienen! Eine Menge interessanter Vorschläge zu weiteren Betriebssystemen wurde an verschiedenen Stellen des Blogs gepostet. Es gibt also noch eine Menge zu tun. 🙂

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

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.