my life

Über ein Jahr lang war es hier komplett still und wenn man den einen Beitrag ignoriert, sind es sogar fast zwei Jahre. Machen wir uns also nichts vor, ich habe an dieser Seite ganz klar die Lust verloren. Ich kanns nichtmal erklären, denn es gab keinen besonderen Grund - sie war einfach plötzlich weg.

In der Zwischenzeit habe ich ein neues Hobby gefunden - um genauer zu sein ist es ein Auto. Ursprünglich war es als Nutztier geplant, aber wie das immer so ist, kommen die Dinge dann doch anders. Da es zu dem Thema relativ viel zu erzählen gibt, es aber thematisch so überhaupt nicht zu dieser Seite passt, habe ich einfach kurzerhand eine neue eröffnet.

Falls das hier überhaupt noch jemand liest und daran interessiert ist: Audi A4 B5/8D

Nach einem der letzten Updates des Systems, bei dem u.a. MySQL 5.1.23 installiert wurde, war hier leider - wie manchen vielleicht auch aufgefallen ist - nur noch sporadisch etwas zu sehen und selbst wenn, dann auch nur ohne den neusten Beitrag. Entgegen anderslautender Gerüchte lag das nicht daran, daß ich einfach so lange keinen Beitrag mehr geschrieben habe, daß Helma sich geweigert hat überhaupt noch irgendetwas anzuzeigen, sondern scheinbar schlicht an MySQL.

Ich hatte nie die Zeit gefunden das Problem mal etwas genauer unter die Lupe zu nehmen, da Updates aber nahezu automatisiert installiert werden können und seit kurzem MySQL 5.1.24 verfügbar ist, habe ich diese Version heute kompiliert und eingerichtet. Und siehe da - schon ist auch hier wieder etwas zu sehen.

Ich hatte bereits kurz nachdem ich das Problem bemerkt hatte, unter der Vermutung, daß es an MySQL liegen könnte, sämtliche von MySQL abhängenden Libraries neu übersetzt - leider ohne Erfolg. Ein Downgrade von MySQL selber hatte ich allerdings nicht probiert, denn ich erinnerte mich, daß beim Upgrade von 5.1.22 auf .23 Änderungen an den Systemtabellen vorgenommen werden mußten. Die jedoch wieder rückgängig zu machen, habe ich noch nie gemacht und wüsste auch nicht, ob das ohne Probleme üeberhaupt möglich ist. Sicherungen der Datenbank von vor dem Upgrade gibt es natürlich, aber dann wären ja alle Änderungen weg gewesen. An dem Punkt hatte ich beschlossen das Problem vorläufig erstmal zu ignorieren... Und diese Entscheidung war zwar vielleicht nicht ganz optimal, aber auch nicht ganz falsch.

Nachdem ich mir in der Nacht von Samstag auf Sonntag in einer unrühmlichen Aktion (OpenSSL Update) den SSH Daemon zersägt hatte und sämtliche Aufrufe nur noch mit einem

OpenSSL version mismatch. Built against 908070, you have 90807f

quittiert wurden, mußte ich leider das Angebot eines IP KVM Switches meines Hosters in Anspruch nehmen.
OpenSSH war schnell repariert, aber das Gerät war ja immer noch angeschlossen. Also schlug mein Ansprechpartner beim Hoster vor, ich könnte es doch nutzen um noch ein Update des Basissystems durchzuführen. Da das ohnehin schon länger überfällig war (der Support für FreeBSD 6.0 ist entweder schon ausgelaufen oder tut das sehr bald - meine ich gelesen zu haben), habe ich das auch gleich gemacht. Um beim Kompilieren der Welt nicht so ein Desaster zu erleben wie bei Java, hatte ich den speicherhungrigsten Prozess auf dem Server - Helma - bereits im Vorfeld beendet. Ich hätte ihn bestimmt irgendwie direkt nach Beendigung der Kompilierung automatisch wieder starten können, aber so wichtig ist diese Webseite dann auch nicht, daß sie 365 Tage im Jahr mit einer 99,99999%igen Verfügbarkeit laufen müßte.
Nach fast 13 Stunden war dann das "Projekt: Update" abgeschlossen und die Seite lief wieder. Im Anschluß habe ich noch das - kurz nach dem letzten Kompilieren erschienene (grmbl@#$%!) - Update für Java angeworfen. Das lief bis eben ohne Probleme neben dem normalen Betrieb durch und nun sollte die Kiste wieder erstmal für eine Weile ohne weitere Einschränkungen durchlaufen können. Hoffe ich.

Hrm. Diesmal war die Seite nicht ganz ausgefallen, aber seeeeehr .. naja .. sagen wir mal "bedacht" beim Beantworten der Anfragen.
Wiedermal ein RAM Problem, diesmal allerdings selbst induziert. Ich hatte gestern Mittag nach langem vor-mir-herschieben und mittlerweile sogar bekannten Sicherheitslücken endlich mal den Kompilationsprozess des Java Updates angeworfen. Hat laut Log übrigens von ca. 13:30 Uhr bis ca. 4 Uhr morgens gedauert. Ich erinnere mich jetzt, wieso ich das vor mir hergeschoben habe ;-)
Die Kompilation hat im späteren Verlauf anscheinend viele CPU Ressourcen belegt und als Konsequenz daraus war ein relativ häufiger etwas speicher- und rechenzeitintensivererer Cronjob entsprechend langsamer gelaufen. Die Ausführungszeiten haben sich irgendwann überschnitten (was der Coder *hust* nicht abgefangen hat), der Speicher war schnell voll und dann swappte die Kiste - bis ich eben alle Prozesse abgesägt habe.


Erfreuliche Nachricht bei dem ganzen Drama: Java ist nun wieder auf dem aktuellen Stand.

Huch. Da hatte mein Server auf einmal um 6 Uhr keinen RAM und keinen Swap Speicher mehr zur Verfügung und überlegte sich Helma zu killen...
Ich sollte tatsächlich nicht nur über die Anschaffung eines neuen Servers (oder zumindestens mehr RAM) nachdenken, sondern das auch in naher Zukunft umsetzen.

ich empfehle jedem, der auf mod_jk 1.2.23 updated, diesen absatz zu lesen: 18 May 2007 - JK-1.2.23 released.
dort wird auf The Apache Tomcat Connector - Reference Guide - Configuring Apache verlinkt, wo beschrieben wird, dass sich eine defaulteinstellung des connectors geändert hat:

The default value is "ForwardURICompatUnparsed" since version 1.2.23. Until version 1.2.22 the default value was "ForwardURICompat".

das fuehrt mit helma anscheinend zu problemen... durch ein einfaches

JkOptions +ForwardURICompat

in der httpd.conf ist nun aber wieder alles in ordnung.

nanu. da war die seite seit 13:47 nicht mehr erreichbar.. und ich merks erst kurz vor 0 uhr. und warum?
erst dachte ich helma wäre tot.. aber im log nichts zu sehen. dann dachte ich der apache hat sich verhaspelt - obwohl die anderen webseiten noch liefen.. das wars dementsprechend auch nicht. dann fiel es mir wie schuppen von den augen: letzte tage wurde der mod_jk port aktualisiert. straeflicherweise hatte ich das update zwar mitlaufen lassen, den apache aber nicht neu gestartet (trotz offenem sicherheitsloch). aus irgendeinem grund hat der apache den verpassten neustart dann heute um 13:47 nachgeholt. und warum war nun die seite nicht erreichbar?
ganz einfach.. das jk modul ist in der apache konfiguration durch den port per default deaktiviert. da frage ich mich doch.. was bewegt einen portmaintainer dazu einen port per default zu deaktivieren, den man explizit installieren muss und das wohl in aller regel auch tut, weil man ihn danach benutzen will? nun auf jeden fall fehlte dem apache nach dem neustart das jk modul und da fuer diese seite kein sonstiger documentroot existiert, wurde einfach das getan, was logisch ist: nichts.

update: und zu allem ueberfluss habe ich dann auch noch vergessen diesen artikel online zu schalten... das war nicht mein tag.

huch!
wer hatte denn da mod_jk auskommentiert in der webserverkonfiguration...

nachdem ich mir gestern noch nicht sicher war, haben mich die fast 300 spams, die vergangene nacht hier eingegangen sind, doch ueberzeugen koennen.. trackbacks sind hier ab sofort teil der vergangenheit.
wer einen alten trackbacklink aufruft wird automatisch zum beitrag umgeleitet..

mir waere noch wochen nicht aufgefallen, dass ein anderes blog in diesem antville mit trackbackspam voellig zugemuellt wird und ich auch ein paar abbekommen habe.. aber wenn auf einmal in der webstatistik eine trackback url mit exorbitant vielen zugriffen an 3. stelle steht, dann ist das schon auffaellig. da guckt man dann auch mal nach - entdeckt ungefaehr 2800 spams aus den letzten 10 tagen - und loescht die dann natuerlich.
da in den 621 tagen die ich hier nun schon schreibe insgesamt auch nur drei trackbacks gekommen sind, ueberlege ich nun, ob ich die funktion nicht eh ganz abschalte..