8 Kerne und nen Typ

Samstag ist mir noch eine Exception auf unserem Java6-Test-Tomcat aufgefallen, irgendwas mit Logging und ähnlichem. Da der Server prinzipiell lief, habe ich das dann erst mal verschoben.

Kern des Problems war die fehlende Berechtigung auf “logging.properties” zuzugreifen – eine Konfigurationsdatei, die wir weder haben noch brauchen. Es liegt dann übrigens daran, dass der Tomcat-Container zwingend Leserecht darauf braucht, um festzustellen, dass die Datei nicht existiert um dann ohne zusätzliche Konfiguration für den in Tomcat 5.5 neu eingeführten Logger JULI weiterzumachen.

Wer denkt sich denn so was aus?

Not listening Juli – Geile Zeit

Klassischerweise wird eine Race Condition ja vor allem in der Programmierung zum Problem (auch wenn ich in der englischen Wikipedia eine deutlich weitere Definition vorgefunden habe), doch ich habe hier ein schönes Beispiel für eine sehr langandauerende, die ich niemand vorenthalten möchte:

1. Bugmeldung, dass Attachments mit Umlauten nicht mehr korrekt in die Mails gepackt werden
2. Parallel zum Groupware-Upgrade Fehlersuche, dabei unter anderem an den locales rumdrehen
3. Irgendwann merken, dass ein Folgebug aus einem Hotfix das Problem verursachte
4. Tage später kurz vor Weihnachten schmiert der Server ab (Xen mit Windows-Virtualisierung ist einfach nicht produktionsreif – aber egal…)
5. Wieder etliche Zeit später poppt der Umlaut-Fehler wieder hoch
6. Verzweiflung, Programmiere verrückt machen, Testcases basteln, im Source wühlen, … -> vollen Programm eben

Was war passiert?

Bei dem parallelen Fehlereingrenzen und Update einspielen wurde der Tomcat gestartet, als locales zeitweise wieder auf UTF-8 stand, anschließend änderte ich dann das System auf ISO-8859-15, was dem Tomcat im Betrieb aber egal ist – er nutzt weiterhin UTF-8 als Charset.

Als dann die Box abschmierte wurde beim Reboot der Tomcat mit ISO-Codierung angestartet, was vom Fehlerbild her identisch zu dem durch den Fix verursachten Bug aussah – und es hat ziemlich lange gedauert, bis ich das Knäuel der gemachten Änderungen entwirrt hatte, vor allem weil sich der ganze Vorgang über insgesamt 20 Tage erstreckte und dazwischen auch mein Urlaub lag.

Memo an mich: Nicht zu sehr parallelisieren, ich bin doch einfach nur Single-Task-fähig…

So, heute war mal wieder Abschalttag.

Gestern habe ich die Kompilierung unserer Groupware auf einen anderen Server migriert – so wildes Bash- und Ant-Gepfuschel. Die spaßeshalber von mir kompilierte Kombination aus Client und Server lief einwandfrei, daher hatte ich keine großen Bedenken mit dem zügigen abschießen des alten Systems (braucht wer ‘ne 1-HE-Pizzabox mit unterirdischen Leistungsdaten? Der Gruseleffekt ist euch sicher, wenn ihr das irgendjemand zeigt…).

Heute morgen um halb drei (sic) hat ein Coder eine neue Version der Groupware rausgeschickt – und was war? Sie lief nach dem kompilieren natürlich nicht… Nachdem ich ewig nach dem Fehler in meinen Kompilaten gesucht habe hat er dann zugegeben, im Delivery-Package einen Fehler eingebaut zu haben – der Mensch sollte, wenn er schon morgens um halb drei irgendwas verschickt, doch sein Zeug wenigstens testen.

Wie dem auch sei: Die Kiste ist jetzt tot, was meine Quote anhebt auf 8 abgeschaltete und 3 neu in Betrieb genommene – von ursprünglich mal 16 Systemen.

Update Dieser Eintrag wird häufiger mal über Suchmaschinen gefunden, daher mal eine etwas ausführlichere Anleitung und nicht nur meine hingerotzten Kommentare…

Alles sehr verwirrend.

Laut einigen Meinungen läßt sich mit den Stable-Paketen von Debian Etch kein Windows als HVM-Gast installieren, bei anderen klappt’s.

Gestern schob ich meine mißglückten Versuche noch auf die Xen-Speicherverwaltung, allerdings war diese gar nicht das ursächliche Problem.

Solltet ihr jemals versuchen unter Xen ein Windows zu installieren sollte diese Zeile in der Gast-Config stehen:

shadow_memory = 8

Und jetzt gehe ich weinen – warum ist dieses Drecksteil nicht ordentlich dokumentiert? Aus der Hardwarevirtualisierung mit Xen wird wirklich ein riesiges Mysterium gemacht…

Bis in einem Monat will ich den Faxserver auf die neue Plattform umgezogen haben – dann muß ich mich beim einrichten des neuen Mitarbeites zum 01.10. nicht mehr mit diesen blöden handgeschnitzten und unverständlichen Skripten meines Vorgängers rumärgern, die nie so wirklich das tun, für was sie angeblich vorgesehen sind.

Die Zeit läuft.

Heute habe ich einen uralten Datenbankserver auf die Xen-Kiste migriert, und zwar genau den, vor dem ich ziemlichen Bammel hatte.

Ging dann eigentlich doch ganz problemlos über die Bühne, meine Vorbereitung hat sich ausgezahlt, innerhalb von vier Stunden hatte ich alles fertig und getestet war es auch.

Bis auf eine Kleinigkeit.

Diese ist ein sehr altes hier im Haus gestricktes Tool zur Bereitstellung von Auswertungsdatenbanken, nicht dokumentiert, extrem lange laufend, undurchschaubar. Selbst wenn ich einen Lauf nur auf ein Projekt einschränke dauert so ein Durchgang ca 30 Minuten, womit ich insgesamt drei Stunden am testen war.

Kann auch einer ahnen, dass das Biest nicht nur die mysqlclientlibs nutzt, sondern auch ODBCs? Und die Anmeldedaten aus den ODBCs (die ich für das Auslesen der Original-Daten ganz brav auf einen Read-Only-DB-User setzte) so in dem Programm verwurstet werden, dass es am Ende vom MySQL-Client als Authentifizierung für den _schreibenden_ Zugriff auf die erstellten Datenbanken genutzt wird?

Gerade letzteres nicht nur zu Finden sondern zu Begreifen und Glauben hat mich gefühlt Jahre meines Lebens gekostet…

In der Info-Mail letzter Woche an meine User stand

Bei solch einer Änderung bin ich sicher, dass ich irgendetwas vergesse oder übersehe, es werden daher in der folgenden Woche sicherlich Probleme und Fehler auftauchen.

drin, ich hoffe immer noch, dass es nicht zu heftig wird.

Freud:

Die Programmierer beginnen endlich, die Softwarevorraussetzungen für unsere Apllikationen aktuelleren Standards anzugleichen, statt Java 1.4.2 Java 6, statt MySQL 4.1 MySQL 5, statt Tomcat 5 Tomcat’  5.5. Dann wird es nicht mehr ganz so peinlich, bisher wird man häufiger mal von Admins ausgelacht, wenn wir die JRE-Anforderungen verraten.

Leid:

Die Programmierer weigern sich die Software für eine Übergangszeit zu forken, um alle Programmversionen zu unterstützen, das heißt für mich ich werde mir eine Strategie einfallen lassen müssen, die es uns ermöglicht gleichzeitig alle Server auf aktuellen Stand hochzuziehen und gleichzeitig bei den ca. 150 Nutzern der Applikationen (davon 130 externe) eine neuere JRE installieren zu lassen. Das wird ein logistischer Alptraum.

Disclaimer:

Bevor hier jemand was von “Abwärtskompatibiliät” von Java schreibt – bringt nichts, vor allem im Client sind ziemlich perverse Hacks drin, was ihn nur und ausschließlich unter 1.4.2 funktionieren läßt.

Nachdem gestern die neue Version der Groupware auf dem Testsystem eingespielt wurde, bat mich heute der Handbuchersteller, auf dem Testsystem wieder die Demo-Datenbank mit Dummy-Daten für Screenshots einzubinden – was jetzt etwas blöd kam, da auch die neue Version getestet werden soll, mit einem aktuellen Dump des Produktivsystems.

Endlich mal die Möglichkeit, mein neues Rollout-Konzept zu testen:

1. Auf SMB-Freigabe des Xen-Host den Ordner der J2EE-Applikation der Testgroupware kopieren
2. Konfiguration in den Textfiles anpassen (Datenbank,automatische Jobs deaktivieren und so)
3. Das neue Verzeichnis im webapps-Verzeichnis vom Applikationsserver mounten
4. minimale Servlet-XML-Datei erstellen (eigentlich nur Pfad und Applikationsname)
5. im Tomcat-Manager XML importieren und Anwendung starten
6. Java Web Start Client des Testsystems kopieren und Konfiguration anpassen (Servlet-Pfad des Servers)
7. Link an Auftraggeber schicken

Dauer: 10 Minuten

okay – war etwas gemogelt, da die Datenbank schon vorhanden war, aber lustig war es schon eine komplett neue Umgebung fertig zu haben bevor der User wieder von der Kaffemaschine zurück kam…

Die produktive Groupware ist inzwischen auf dem neuen Gastsystem untergekommen und es sieht so aus als würde sogar alles funktionieren.

Der Start war etwas holprig, als ich die auf dem Dateisystem gespeicherten Dateien per scp auf die neue Kiste umziehen wollte kam leider ein “Die Argumentliste ist zu lang”, als ob 326795 Dateien in irgendeiner Weise anstrengend seien. Na ja, beholfen habe ich mir dann mit ” find [Quelle]/ -exec cp ‘{}’ [Ziel]/ ‘;’ “, ging dann auch ganz gut und hat endlich mal etwas Last auf den Server gebracht.

(weiterlesen…)

Die Migration vom Produktivsystem der Groupware läuft, bisher ist folgendes erledigt worden:

• Aufsetzen eines neuen Gastsystems auf dem Xen-Host
• Einbinden in Serverüberwachung und Backup (Werbung: schaut euch mal BackupPC an, absolut simpel, wartungsarm und stabil)
• Installieren und konfigurieren des Tomcats
• Anpassen der Config-Files der Applikation an die neuen Gegebenheiten
• Herausfinden des Kennworts für die Signierung der JARs (bisher größtes Drama, war _nirgendwo_ aufgeschrieben)
• Benutzer informiert, dass morgen keiner mit der GW rumspielen darf (siehe auch hier)
• Anpassen der Client-JARs und signieren

(weiterlesen…)