Kategorie: Indianer, Kater und andere Serverbewohner

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.

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

Ich habe hier ja mal behauptet, dass ich einen funktionierenden MySQL 4.1 auf Debian Etch AMD64 habe – stimmt aber nicht ganz…

Prinzipiell läßt sich mit der Kiste alles machen, was das Herz begehrt – nur nicht über den MySQL-Java-Connector ein prepared statement ausführen, was unsere J2EE-Applikationen leider dauernd machen. Ein ähnliches Problem wurde bei Ubuntu beschrieben, diesen Lösungsansatz habe ich dann auch gewählt.

Ich nutze also meine neu gebauten Debian-Pakete um das ganze „schöner Wohnen“ für die Administration zu haben, habe jedoch das offizielle Release von MySQL AB dazu auf den Server geklatscht und die Daemon-Binary ausgetauscht.

Eine perverse Konstruktion, für niemanden außer mir wartbar – aber erlaubt ist was funktioniert….

Update bei mytso gibt es inzwischen ein apt-Repository für AMD64-mysql-4.1 – nie von mir getestet, Verwendung also ohne auf eigene Gefahr…

[Update: So erstellte Pakete haben Probleme mit prepared statements über die Java-API, siehe hier]

Heute habe ich versucht eine unserer anderen J2EE-Applikationen zum laufen zu kriegen – leider nur mit der harten Anforderung an einen MySQL-Server der Version 4.1. Die Version 4.0 aus Sarge ließ sich ohne weitere Probleme installieren, 4.1 zickte jedoch wegen nicht erfüllter Abhängigkeiten rum.
In diesem Blog ist sehr schön beschrieben, wie Debian-Sourcen neu kompiliert werden können, bei MySQL ist es notwendig, die build-dep von libreadline4 nach libreadline5 zu ändern.
Das ganze kompiliert dann auch eifrig durch, läßt sich nur nicht installieren, da das Paket libdbd-mysql-perl bei Etch auf libmysqlclient15 basiert – also auch das noch neu packen, mit der geänderten build-dep auf libmysqlclient14 aus dem eben neu gepackten MySQL 4.1…

Zu guter letzt lief das also – bei weitem nicht so schön wie hier gepostet, auf das Anpassen der Paketnamen und neu signieren habe ich dann doch verzichtet, auch ein eigenes Repository richtete ich nicht ein – aber es geht, und das ist erst mal die Hauptsache.

… eine Tomcat-Installation dann kein Problem ist, wenn auf Java-Sicherheitspolicies verzichtet wird?
… solche lieblos aufgesetzten Server mancherorts nicht nur zum testen genutzt werden, sondern durchaus produktiv?
… Directory Listings von J2EE-Applikationen unterbunden werden sollten, wenn ansonsten _jeder_ Zugriff auf die Management-Seite erhält auf der beispielsweise der Server heruntergefahren werden kann?
… auf eben genannte Management-GUI sinnigerweise auch eine Zugriffskontrolle eingerichtet sein sollte?
… ein Tomcat mit java.security.debug=all innerhalb weniger Augenblicke gigabyte-große Logfiles erzeugen kann?
… das Raid des neuen Servers immerhin 180 MiB pro Sekunde wegschreibt?
… manchmal sowohl

permission java.io.FilePermission „file:[verzeichnis]“, „read“

als auch

permission java.io.FilePermission „[verzeichnis]“, „read“

benötigt werden?