Wenn Programmierer unterbezahlt sind…

…dann bauen sie fürchterlichen Mist, mit dem sich harmlose Kunden nachher rumschlagen müssen.

In diesem Fall waren es vermutlich die Programmierer der Firma Promise Technology. Diese Firma stellt Chips für RAID Controller her, vermarktet diese unter eigenem Namen und anscheinend ist ATI, seines Zeichens Hersteller von CPUs und Chipsätzen, auf Promise hereingefallen und hat solche RAID-Chips für die Integration in einige ihrer Chipsätze lizensiert. In meinem Fall ist dies ein ATI SB600 Controller auf einem ASUS M2A-VM Board.

Damit man diesen integrierten RAID Controller überwachen kann, darf man sich eine Software herunterladen, die sich “WebPAM” nennt. Diese Software startet im Hintergrund einen Dienst, der mit dem RAID Controller Treiber kommuniziert. Dieser Dienst kann nun per Webbrowser angesprochen werden, um z.B. zu überprüfen, ob die Platten im RAID Volume gesund sind.

Nun klingt sowas an sich nach einer netten Idee. Man kann die Verwaltung von beliebigen PCs aus dem LAN starten und braucht dort nicht extra eine Konsole zu installieren. Nun ja, wenn denn die Programmierer wohl völlig unterbezahlt gewesen sein müssen. Man kam nämlich auf die völlig dämliche Idee, den Hintergrunddienst samt Webserver und allem Drumherum in Java zu programmieren! Damit nicht genug, man bringt natürlich auch seine eigene Java Runtime mit, die keinesfalls durch eine neuere Java Runtime ersetzt werden darf. Nachdem Java Runtimes laufend wegen irgendwelche Sicherheitslücken aktualisiert werden müssen, ist das eigentlich schon der Moment, an dem man Software löscht. Selbst wenn man eine aktuelle JVM an die Stelle der mitgelieferten Version kopiert oder verlinkt, wirft der seltsame Webserver nur noch Fehlermeldungen. Zudem habe ich keine Möglichkeit gefunden, den Port des Dienstes zu verändern. Und ganz zuletzt ist natürlich für den Zugriff auch schon gleich ein Passwort gesetzt – es wird aber kein Handbuch mitgeliefert, in dem sich dieses findet (User: admin, Password: admin; muss man aber halt erst mal wissen). Aber das war noch gar nicht der Knüller – es kommt noch besser. Oder besser gesagt: schlechter.

Irgendeine dieser ganzen Hintergrundgeraffel-Komponenten kommt auf die Idee, im Hauptverzeichnis von C: ein Debug Logfile namens i2api_debug.log zu erstellen und ständig irgendwelche Statusinformationen in dieses Logfile zu schreiben. Endlos! Innerhalb von Minuten hat die Datei einige hundert Kilobytes an Größe. Im Netz finden sich Berichte von Usern, bei denen die i2api_debug.log mittlerweile 1,5 GB (!) erreicht hatte.

Ich muss also, wenn ich die Gesundheit der Platten im Blick haben möchte, bzw. im Falle ihres Ausfalles benachrichtigt werden möchte, einen in Java zusammengeschusterten Webserver auf einem festen Port laufen haben, der nur mit einer unsicheren und völlig veralteten Java Runtime läuft und mir auf dem Systemlaufwerk langsam aber sicher die Platte vollschreibt? Und nein, die Software ist nicht neu und das Problem könnte demnächst gefixt werden! Nein, diese Version ist seit 2006 nicht mehr verändert worden, wird es wohl auch nie mehr werden, und wird heute noch auf ahnungslose User losgelassen.

Sind die einfach nur völlig bescheuert?

Ach ja: das Anwachsen des Logfiles kann man übrigens verhindern, indem man es löscht und gleich, wenn die Anwendung es Sekunden später wieder neu erstellt hat, das Schreibschutzattribut setzt.