Sil53r Surf3r

Codemasters Online kündigen auf ihren Webseiten und im LotRO-Client seit drei Tagen eine Systemwartung für den kommenden Donnerstag an. Von 7:00 Uhr bis 14:00 Uhr GMT wird man weder Account-Dienste nutzen noch sich in eines der Online-Spiele einloggen können. Zur Begründung wird angegeben:

"Während der Wartung erweitern wir die Stromversorgung im Datenzentrum. Aus Gründen der Sicherheit müssen daher alle Systeme während dieser Zeit ausgeschaltet werden."

Wie bitte? Alle Systeme!? Auf einmal?!1!! Besteht das Datenzentrum aus einem PC-Schräppelchen an einer Normalstromleitung unter dem Schreibtisch eines der Entwickler, oder was?

Folgendes Szenario: Ich bin ein Hersteller und Anbieter von Online-Spielen. Diese stellen gleichzeitig eine meiner Kernkompetenzen und einen relevanten Geschäftszweig dar. Nun gehen wir großzügigerweise einmal von einem zwölfstündigen Arbeitstag aus. Dann bedeutet die obige Meldung eine Komplettabschaltung aller kundenrelevanten Dienste für den Online-Spielesektor für einen halben Arbeitstag. Weil die Stromversorgung im Datacenter verstärkt wird?!

Zufälligerweise arbeite ich selbst in und mit einem nicht eben kleinen Rechenzentrum. Eine solche Vorgehensweise zeugt nicht gerade von einer beruhigenden Ausbaustufe des Centers oder gar sorgfältiger (Voraus-)Planung. Im Gegenteil, unter den gegebenen Ausgangsbedingungen möchte ich sie als in hohem Maße unprofessionell bezeichnen. Es sei denn, Spieler wären Kunden, auf die man leichten Herzens und luftiger Geldbörse einen halben Arbeitstag lang verzichten könnte.
Das geht auch anders.

LotRO ist ein tolles Spiel, keine Frage. Ich spiele es seit der Betaphase im März 2007 immer noch gerne. Man muß den Betreibern zugutehalten, daß es im Großen und Ganzen stabil läuft und die gröbsten Fehler relativ schnell behoben wurden. Mit den anderen, den kleineren, kann man sich meiner Meinung nach arrangieren. Es ist und bleibt immerhin bloß eines: ein Spiel.

Einige der technischen Gegebenheiten rund um "Der Herr der Ringe Online" ernten allerdings immer wieder mein Kopfschütteln. Wie zum Beispiel halbtägige Wartungsfenster während allgemein üblicher Geschäftszeiten.

Wir könnten uns das jedenfalls nicht leisten.

Auf unserem Mediacenter-Rechner, dessen Basis Debian Lenny ist, läuft seit ein paar Minuten Kernel 2.6.28.7 mit LIRC 0.8.3 und ndiswrapper 1.54.

Vanilla-Kernel baue ich grundsätzlich als Debian-Pakete mit den dazugehörigen für die Header und Quellen. Aus diesem Grund wollte ich für LIRC und ndiswrapper ebenfalls installierbare Pakete erzielen. Einerseits kann man sie dann in einem lokalen Repository ablegen, andererseits lassen sie sich sauber installieren und wieder entfernen. Überdies erscheinen sie in den Paketlisten für die Systeme, auf denen sie installiert sind, was die Verwaltung vereinfacht.

Hier stehen drei Rechner, die weitestgehend baugleich zum Mediacenter sind. Insofern ergeben diese Vorgehensweise und der daraus entstehende Aufwand größeren Sinn, als auf jeder dieser Maschinen Module separat aus den Quellen zu kompilieren.

Nach der Installation von lirc-modules-source ließen sich die Module für LIRC über den Aufruf von "module-assistant build lirc-modules" zunächst nicht bauen. Ursache war eine Pfadänderung für Headerdateien, die zwischen dem aktuellen Kernel und früheren Versionen stattgefunden hatte. Nach der Anpassung eines Includes in jeweils lirc_dev.c und lirc_i2c.c konnte das Modulpaket schließlich erzeugt werden:

/* #include <asm/semaphore.h> */
#include <linux/semaphore.h>

Der ndiswrapper war etwas aufwendiger. Auch dessen Kernel-Modul ließ sich über den module-assistant nicht bauen. Aufgrund früherer Erfahrungen mit dem Wrapper wollte ich auf jeden Fall die aktuelle Upstream-, also die Sourceforge-Version verwenden. Daher habe ich das Debian-Quellpaket der Version 1.5.3 zunächst auf die 1.5.4 aktualisiert. Dazu mußten die enthaltenen Debian-Patches deaktiviert bzw. teilweise manuell appliziert werden.
Sauberer wäre es gewesen, einen oder mehrere Patches für die neue Version und die zugehörige Patchliste zu erzeugen. Weil ich meiner Paketvariante aber keine allzu hohe Lebensdauer zurechne, habe ich aus Zeitgründen darauf verzichtet.

Nach der Aktualisierung des Debian-Quellpaketes ließen sich sowohl die ndiswrapper-utils als auch die ndiswrapper-modules problemlos erzeugen. Nach der Installation sieht das jetzt so aus:

ii  liblircclient-dev                        0.8.3-3.2
ii  liblircclient0                           0.8.3-3.2
ii  linux-headers-2.6.28.7-ks-srv-686        0.01.ks
ii  linux-image-2.6.28.7-ks-srv-686          0.01.ks
ii  linux-source-2.6.28.7-ks-srv-686         0.01.ks
ii  lirc                                     0.8.3-3.2
ii  lirc-modules-2.6.28.7-ks-srv-686         0.8.3-3.2+0.01.ks
ii  lirc-modules-source                      0.8.3-3.2
ii  ndiswrapper-common                       1.54-1
ii  ndiswrapper-modules-2.6.28.7-ks-srv-686  1.54-1+0.01.ks
ii  ndiswrapper-source                       1.54-1
ii  ndiswrapper-utils-1.9                    1.54-1

Sauber ist das nicht, denn die LIRC-Pakete habe ich als Non-Maintainer-Upload gekennzeichnet. Richtig wäre stattdessen die Markierung als lokaler Build gewesen. Ebensowenig tragen die ndiswrapper-Pakete die passenden Versionsnummern. An dieser Stelle bleibt also noch Raum für Verbesserungen. Nun müssen aber erst einmal der Windows-Treiber für die WLAN-Karte installiert und Netzwerk sowie Infrarot-Fernbedienung konfiguriert werden.