RackBlogger

Softwareentwickler kennen das: die eigene Software hat einen Fehler, und man findet ihn einfach nicht. Dummerweise tritt der Fehler nur in ganz seltenen Fällen und irgendwo zwischen dem eigenen Code und einer externen Bibliothek auf. Nun wäre es natürlich einfach, die Ursache auf die externe Bibliothek zu schieben - wenn die aber zig millionenfach im Internet genutzt wird, dann ist es doch eher wahrscheinlich, dass der Fehler im eigenen Code steckt.

So geschehen in einem aktuellen Fall bei uns: unter ganz besonderen Bedingungen sind Datenbankabfragen an eine SQLite-Datenbank schief gegangen. Nun “spricht” unsere Software aber nicht direkt mit SQLite, sondern nutzt eine zwischengeschaltete Bibliothek (ebenfalls von uns), welche alle Datenbankzugriffe abstrahiert und optimiert.

Gestern habe ich dann Testcode geschrieben, welcher das Fehlverhalten sowohl mit unserer Datenbank-Middleware als auch direkt mit SQLite reproduzieren ließ. Zeilenweise wurde der Test dann gekürzt, bis klar war, wo der Fehler steckte: in SQLite. Das hilft einem in diesem Moment zwar auch nicht viel weiter, ist aber schonmal eine gewisse Genugtuung. Hier ist der Bug Report - zwar “nur” ein Documentation Bug, aber durchaus mit weitreichenden Folgen wenn man sich auf die in der Dokumentation beschriebene Gültigkeit von Pointern verlässt.

Ja, da ist es nun: das Ergebnis monatelanger Arbeit wird in zwei Wochen (am 01.03.2011) auf der CeBIT präsentiert - unsere Serververwaltungssoftware LiveConfig.

Vor über sechs Jahren habe ich mich im Rahmen meiner Studienarbeit quasi “akademisch” mit dem Thema Serververwaltung beschäftigt. Eine umfangreiche Analyse der verfügbaren Produkte brachte einige gemeinsame Schwachpunkte zu Tage, die bis dato offenbar noch niemand angegangen ist. Außerdem hatte ich so die Gelegenheit, mal völlig frei die “Wunsch-Software” zur Serververwaltung zu skizzieren. Erst 2008 habe ich den Entschluss gefasst, die Ideen von damals in einem kommerziellem Produkt umzusetzen. Spätestens die Teilnahme am Businessplan-Wettbewerb Nordbayern brachte so viel positives Feedback, dass wir Mitte 2009 mit der Entwicklung “from scratch” begonnen haben - weitere Vollzeit-Entwickler wurden eingestellt, Fördermittel beantragt, Kontakte geknüpft - und nun isses soweit.

Wir sind tatsächlich mit einem eigenen Stand (Reihe 9, Stand B20) auf der CeBIT 2011 in Hannover vertreten (was ich mir vor 15 Jahren als Schüler nie hätte träumen lassen ). Dort werden wir LiveConfig in aller Ausführlichkeit präsentieren und den ersten 1000 Interessenten auch eine kostenlose Business-Lizenz anbieten.

Was ist nun das Besondere an LiveConfig? Das auffälligste Merkmal dürfte sein, dass LiveConfig in C/C++ programmiert ist. Alles was für die SSL-geschützte Weboberfläche notwendig ist, ist fest integriert. Administratoren können so also beliebige Versionen von Perl oder PHP auf dem Server installieren, ohne das Control-Panel zu zerschießen. Von manchen anderen Lösungen werden auch regelmäßige Probleme mit PHP-Extensions (insbesondere IonCube Loader) berichtet - das kann es mit LiveConfig nicht geben.

Dabei ist der Code nicht komplett “geschlossen”: die kniffligen Aufgaben, also die tatsächliche Erzeugung der Konfigurationsdateien, werden mit Lua-Scripts erledigt. Lua ist eine sehr einfach erlernbare Sprache und die Scripte liegen im Quelltext vor - können also ohne Probleme an eigene, eventuell exotische Anforderungen angepasst werden.

Der zweite große Unterschied zu vielen anderen Lösungen ist, dass sich LiveConfig minimal-invasiv verhält. Konkret bedeutet das, dass LiveConfig die jeweils eingesetzte Linux-Distribution automatisch erkennt und die von dieser bereitgestellten Softwarepakete konfiguriert. Wer mit LiveConfig etwa einen Webserver verwaltet, bekommt also nicht von uns irgendwelche “eigenen” Apache- und PHP-Pakete aufgedrückt, bei denen er dann bei Updates erstmal warten muss. Im Gegenteil - wir passen uns sogar der Konfigurationsstruktur der jeweiligen Distribution an. Das heißt bei Debian beispielsweise, dass wir unsere vHosts auch in /etc/apache2/sites-available/ anlegen und mit “a2ensite” aktivieren. Das geht so weit, dass man LiveConfig rückstandslos wieder vom Server deinstallieren könnte und alle Dienste im zuletzt konfigurierten Zustand weiter laufen würden.

Meiner Meinung nach hat es normalerweise seinen Grund, warum sich jemand für oder gegen eine bestimmte Distribution entscheidet - seien es persönliche Kenntnisse, Fortbildungen oder unternehmensinterne Richtlinien. Und LiveConfig orientiert sich eben möglichst an den Bedürfnissen des Administrators.

Das Ganze hat natürlich seinen Preis - wir brauchen hier im Team verschiedene Spezialisten für die einzelnen Distributionen, aber das bekommt man gut in den Griff. Nicht zuletzt haben wir eine echt coole Testplattform auf Xen-Basis aufgebaut, in der jede Nacht für alle von uns ausdrücklich unterstützten Distributionen die Software komplett compiliert, installiert, getestet und wieder deinstalliert wird. Sollte mal ein Bug auftauchen (nobody’s perfect), dann können wir über die Testplattform sicherstellen, dass dieser dauerhaft beseitigt ist.

So - genug getextet. Wer Interesse hat, den lade ich herzlich auf die Website http://www.liveconfig.com ein. Die Download-, Demo- und Shop-Seite schalten wir erst zur CeBIT frei - bis dahin wird noch etwas poliert und die letzten Feedbacks unserer heimlichen Betatester berücksichtigt. Diskussionen zu LiveConfig sowie jegliche Fragen dazu sollten am besten direkt im LiveConfig-Forum erfolgen (daher schließe ich auch die Kommentare zu diesem Blog-Beitrag).

Den Titel dieses Blog-Beitrags wusste ich schon seit Monaten, nur der genaue Zeitpunkt war unklar.

Ich bin nun ein vor Glück und Freude platzender Papa, und für einige Tage/Wochen erstmal nur sehr eingeschränkt erreichbar.

Auf die an dieser Stelle üblichen Nerd-Gags mit fork(), sleep(), usw. verzichte ich.

Einer der vielen Gründe, warum ich das iPhone nicht mag:

(dieses Bild wurde auf einem iPod Touch aufgenommen)

Ich glaube kaum, dass die Akzeptanz der AGB vor deutschen Gerichten gelten würde… wer liest sich denn bitte wirklich die 107 (!!) Seiten durch?

Unnötig zu sagen, dass ohne die obligatorische Zustimmung Apps weder installiert noch aktualisiert werden können…

Für unsere Serverkunden gibt’s auch eine Optimierung im Kundenmenü: eine überarbeitete Anzeige aller Leistungsdaten. Bisher haben wir die Werte mit MRTG gesammelt und dann relativ umständlich selber verwalten müssen, welcher Kunde welche PNG-Datei sehen darf. Eine Lösung wie Cacti wäre “oversized”, und auch nicht so eng in unser eigenes System integrierbar wie wir es gerne hätten.

Und da wir im Rahmen eines anderen Projektes eh gerade Know-How in der Graphen-Erzeugung aufbauen, war es nur konsequent, nun selber die Leistungsdaten per SNMP in eigene Round-Robin-Tabellen zu sammeln und selber die Graphen zu erzeugen. Die erste Version ist nun online und kann sich durchaus sehen lassen:

An einigen Details wird natürlich noch geschliffen (z.B. sinnvollere Aufrundung der Y-Skala, dynamische Zoom-Funktion, u.v.m.). Die Erzeugung der Graphen läuft übrigens komplett per JavaScript im Browser ab; für die SVG/VML-Erzeugung kommt RaphaelJS zum Einsatz. Die ganze Mathematik für die Umrechnung von Datenpunkten in Graphen kommt von uns, und wird wahrscheinlich mittelfristig auch als eigene Open-Source-Bibliothek freigegeben.

Nur noch bis heute stellt Microsoft den Windows 7 (Ultimate) Release Candidate zum kostenlosen Download zur Verfügung. Die Testlizenz gilt bis Juli 2010 ohne besondere Einschränkungen. Alle weiteren Informationen gibt’s hier.

Dazu noch zwei Tipps:

• wer keine Lust auf den Download Manager hat, findet mit der passenden Google-Suche (oder Bing ) auch direkte Download-Links.
• nach einer Anmeldung bei Windows Live und dem Ausfüllen eines kurzen Fragebogens erhält man einen Aktivierungscode für Windows 7 RC. Beim Reload dieser Seite mit dem Aktivierungscode erhält man bei jedem Reload einen Neuen…

Man kann lange versuchen, die MySQL-Funktion mysql_library_init() per dlopen()/dlsym() zu laden…

Die Lösung zeigt sich nach einem Blick in die Datei mysql.h:

#define mysql_library_init mysql_server_init

Die Funktion mysql_server_init() ist übrigens “deprecated”…

Vor rund drei Wochen hatten wir hier “Kick-Off” eines brandneuen Software-Projektes. Das Thema dieser Software liegt mir schon seit Jahren am Herzen, und endlich sind Zeit und Kapazitäten da um das umzusetzen (wer mich etwas genauer kennt weiß wahrscheinlich um was es da geht - aber bitte vorerst noch nichts verraten!).

Die Software wird in C/C++ geschrieben und täglich in einem automatisierten Test-Lauf auf (fast) allen unterstützten Plattformen geprüft, unter anderem auf OpenSolaris, FreeBSD und diversen Linux-Distributionen. Hierfür werkelt ein XEN-Server, auf dem per Cron-Job werktäglich jede Nacht auf jeder DomU der aktuelle Sourcecode aus dem zentralen Subversion-Repository ausgecheckt, compiliert und getestet wird.

Um dieses Setup kümmert sich ein eigener Mitarbeiter bei uns, der alleine mit der Portierung (systemspezifische Init-Scripte usw.) und der Pflege der Testumgebung fast Vollzeit beschäftigt ist. Noch ist der Code ja eher übersichtlich: es steht gerade mal ein Codegerüst, mit dem sich ein Serverprozess starten und kontrollieren lässt, die übliche Log-Datei und PID-Datei schreibt sowie seine Konfigurationsdatei liest.

Für das Lesen der Konfigurationsdatei habe ich “keine Kosten und Mühen gescheut”â„¢ und einen eigenen Parser mittels flex und bison geschrieben. War irgendwie ganz witzig - mein letzter Kontakt mit Parser-Entwicklung war im Studium, zum Nachgucken habe ich in meine damaligen Ãœbungsprogramme vom Herbst 2001 (!) geschaut. Da wir aber zukünftig noch mehr mit Parsern machen werden, war dieser Schritt schonmal eine ganz praktische Auffrischung.

Für das automatisierte Testen setzen wir nach einigen Überlegungen nun auf check. Hierbei handelt es sich um eine u.a. von JUnit inspirierte, kleine aber feine Test-Bibliothek für C/C++-Anwendungen; mit ein paar Patches läuft die sogar unter Windows. Für den Konfigurations-Parser habe ich eben gleich die ersten Unit-Tests geschrieben.

Wie wichtig (sinnvolle und umfangreiche) Unit-Tests für die Qualitätssicherung einer Software sind sollte ja hoffentlich bekannt sein. Die Entwicklung der Tests bremst natürlich anfangs ein wenig aus - dennoch ist es ein gutes Gefühl, mit dem Schreiben der Unit-Tests die Entwicklung einer Komponente ordentlich und ruhigen Gewissens abschließen zu können.
Das zweitwichtigste Werkzeug in unserer Entwicklung ist Valgrind. Die Unit-Test machen neben einer Funktionsprüfung nach Möglichkeit auch so eine Art “Lasttest”; dieser wird mit Valgrind analysiert um eventuelle Memory Leaks zu erkennen und dank Profiling zu optimieren.

Jedenfalls macht es schon jetzt viel Spaß, eine Software mal so “richtig ordentlich” zu entwickeln.