tiger rag

Zum 11. Mal fand in Finowfurt im schönen Brandenburg das “Race 61”, veranstaltet von “Roadrunner’s Paradise”, statt. Race bedeutet: Viertelmeile, und 61: Nur bis Baujahr 1961 … was nicht 1000%ig ernst zu nehmen ist, da bei manchen Hot Rods wohl nur einige wenige Blechteile tatsächlich so alt sind ;)

Ansonsten Motoren, Blech, Chrom und Rock’n’Roll satt … ein einziger Ohrenschmaus und eine einzige Augenweide, wohin man auch sah, trotz des feuchten Wetters am Sonnabend!

Statt vieler Worte lasse ich lieber die Bilder für sich sprechen …

Die folgenden Bilder stammen von meinem Freund IckeBilly, der meine eigenen Fotokünste diesmal bei weitem übertraf, mir aber freundlicherweise die Bilder zur Veröffentlichung überließ :)

Nun freuen wir uns alle auf das 8. “Headbanging”, veranstaltet von den “Hot Heads East”, das von 05.-07.09.2008 in Finsterwalde stattfinden wird!

Seit einiger Zeit bietet der Bergbautourismusverein “Stadt Welzow” e.V. Befahrungen des aktiven Braunkohle-Tagebaus Welzow-Süd an. Für einen Freund der Lausitzer Braunkohle wie mich natürlich ein Muß! Also nahmen wir am 10. Mai 2008 an einer solchen Tour teil.

Der Ausgangspunkt für die Befahrungen befindet sich in den Tagesanlagen des Tagebaus, die am besten von Haidemühl aus zu erreichen sind — oder wären, da Haidemühl für den Ortsunkundigen kaum noch aufzufinden ist. Der Abriß des Ortes schreitet sehr rasch voran, und keine Ortsschilder zeigen die Gemeinde Haidemühl mehr an …

Es geht also von den Tagesanlagen aus im Vattenfall-Mannschaftswagen zunächst zum Aussichtspunkt des Tagebaus, doch das kennen wir ja schon längst alles. Richtig interessant wird es erst, als der Mannschaftswagen auf abenteuerlich anmutendenen Fahrwegen in den Tagebau hinabschaukelt. Die zweite Station ist der Vorschnittbagger 1519, Typ SRs 6300. Dieser Schaufelradbagger bereitet die Sohle vor, an der der Arbeitsbereich des Förderbrückenverbundes beginnt.

SRs 6300 Nr. 1519

Die nächste Station ist schon der Gigant schlechthin – die Abraumförderbrücke AFB 32 mit der schlichten Typenbezeichnung F 60. Im Vergleich zu diesem Leviathan nehmen sich selbst die anderen Tagebaugroßgeräte, die nun wirklich keine geringen Dimensionen aufweisen, wie Zwerge aus. Die Abraumförderbrücke – oder besser gesagt, die drei Eimerkettenbagger, die mit ihr einen Verbund bilden – legen das Kohleflöz von dem darüber befindlichen sogenannten “Hangenden” frei und befördern dieses, zu Abraum geworden, quer über das Flöz hinweg direkt zum Kippenmassiv.

Die F 60 in voller Größe mitsamt den Baggern (vom Aussichtspunkt bei Haidemühl aus aufgenommen)

Nun ging es noch zur tiefsten Stelle des Tagebaus, wo die gewonnene Kohle mittels Bandanlage zu den Tagesanlagen gefördert wird, sowie zu einem bereits rekultivierten Bereich des Tagebaus, in dem Experimente mit Weinanbau unternommen werden, und zuletzt zum Füllort, von wo die Kohlebahn die Rohbraunkohle zu ihrem Bestimmungsort bringt – nämlich zum Kraftwerk und der letzten aktiven Brikettfabrik Deutschlands in Schwarze Pumpe.

Lok 4-1310 bei Haidemühl

Die Schwestern der AFB 32 existieren alle noch, und zwar sind vier weitere derzeit im Einsatz: in den anderen aktiven Lausitzer Tagebauen Cottbus-Nord, Jänschwalde, Nochten und dem unlängst wieder in Betrieb genommenen Reichwalde. Die sechste wurde, wenn auch ohne Bagger, nach der vorzeitigen Stillegung des Tagebaus Klettwitz-Nord aus diesem wieder herausgefahren und zum Besucherbergwerk umgewidmet, statt gesprengt zu werden, wie es das Schicksal aller anderen stillgelegten Abraumförderbrücken war.

Am nächsten Tag unternahmen wir noch eine kleine Exkursion zu Relikten von Brikettfabriken im Raum Senftenberg. Weithin sichtbar dampften und qualmten diese gewaltigen Industrieanlagen mit großem Fleiß, manche weit über hundert Jahre lang, um aus der Braunkohle die einst begehrten Briketts zu pressen. So zahlreich die Brifas noch vor zwanzig Jahren gewesen waren, erinnert doch jetzt so gut wie nichts mehr an ihre frühere Allgegenwart. In den meisten Fällen sind von ihnen nur große, öde Brachflächen übriggeblieben.

Von der Brikettfabrik Marga in Brieske, die 1992 stillgelegt wurde, steht zugemauert noch die kathedralenartige ehemalige Turbinenhalle neben dem mit sozialistischer Friedenstaube verzierten ehemaligen Werkseingang und harrt einer ungewissen Zukunft.

Turbinenhalle der Brikettfabrik Marga

An die hundertundsechsjährige Geschichte der 1995 stillgelegten Brikettfabrik Meurostolln in Hörlitz erinnert das alte Stollenmundloch, während die riesige Fabrik selbst vollständig verschwunden ist und sich an ihrer Stelle der Busch ausbreitet, als ob sie nie dagewesen wäre …

Der Meuro-Stolln

Dieser Stollen stammt noch aus der Zeit, als die Braunkohle unter Tage gewonnen wurde. Hier verließen die Kohlehunte auf der Kettenbahn die Grube, einer nach dem anderen in endloser Reihe, und fuhren direkt in den Bunker der Brikettfabrik Meurostolln, von wo sie leer zurückkehrten und an derselben Stelle wieder in die Grube einfuhren. Nach dem Ende des Tiefbaus und dem Aufschluß des Tagebaus Meurostolln wurde die Kohle weiterhin auf diese Weise durch den Stollen gefördert, der wie ein Tunnel im Tagebau mündete. In späteren Zeiten wurde die Kohle dann auf dem Kohlebahnnetz mit 900 mm Spurweite befördert, doch auch das ist längst Vergangenheit.

Wenigstens hat man hier vor kurzem dafür Sorge getragen, daß dieses Denkmal erhalten bleibt und vor Vandalismus geschützt wird. Leider ging dabei die historische Aufschrift des Portals verloren und wurde gegen eine nicht originalgetreue Nachfertigung ersetzt. Auch wurden in der Hörlitzer Ortsmitte eine Baggerschaufel, ein Kohlehunt, ein Fliehkraftregler sowie einige Informationstafeln aufgestellt. Im Sommer 2003 befand sich das Stollenmundloch in verwahrlostem Zustand, war aber noch mit der (bereits stark beschädigten) Originalaufschrift versehen.

Zustand im Sommer 2003 mit dem Schreiber dieser Zeilen

Dann existiert noch ein Relikt der Brikettfabrik Impuls am Nordrand von Senftenberg, unmittelbar am stillgelegten Tagebau Meuro in der Nähe der Straße nach der ehemaligen Ortschaft Rauno gelegen. Impuls wurde bereits 1973 durch eine Braunkohlestaubexplosion zerstört, die Ruine jedoch erst Anfang der 90er Jahre durch die LMBV beseitigt. Übrig blieben eine Brikettpresse und ein Kettenbahnhunt, die offensichtlich als Denkmal gepflegt werden und erst jüngst einen neuen Anstrich erhalten haben.

Erinnerung an die Brikettfabrik Impuls

Ganz anders die Situation in Plessa. Hier befand sich in der Nachbarschaft des zum Glück erhalten gebliebenen Kraftwerks Plessa die Brikettfabrik 63 des BKK Lauchhammer, auch bekannt als Brikettfabrik Agnes. Diese Fabrik war im Laufe ihrer neunundachtzigjährigen Geschichte mehrmals Opfer von Braunkohlestaubexplosionen – zuletzt 1983 –, wurde jedoch immer wieder repariert und erneut angefahren, bis 1991 das endgültige Aus kam. Hier etablierte sich auf dem Fabriksgelände eine Art Schrott- und Bauschuttverwertungsbetrieb, und noch immer wird das Gelände von hohen Trümmerbergen aus Stahlbeton und Ziegelschutt geprägt, die offensichtlich unter anderem von den Abbruchmassen der ehemaligen Brikettfabrik und ihren Nebenanlagen stammen. Inmitten dieser wenig pittoresken Szenerie steht jedoch noch die ehemalige Turbinenhalle der Fabrik, jetzt zu einer Art Garage umfunktioniert.

Turbinenhalle der Brikettfabrik Plessa

In Lauchhammer fiel uns am Eingangstor der ehemaligen Kokerei noch ein Kuriosum auf: Auf dem Gelände der Kokerei ist jegliche Abbruchtätigkeit längst zum Stillstand gekommen …

Hier gibt es nichts mehr zum Abreißen

Über die ehemaligen Brikettfabriken der Lausitz ist leider nur sehr wenig Information im Netz und auch sonst zu finden. Hier noch ein paar interessante Links für Liebhaber der Materie:
Bilder der Brikettfabrik Kausche
Bilder der Brikettfabriken in Welzow
Bilder der Brikettfabrik Haidemühl

Sehr freuen würde sich der Verfasser dieses über Zuschriften von anderen Fans der vergangenen Braunkohleindustrie der Lausitz. In diesem Sinne: Glück auf!

Beim Schreiben meines letzten Beitrags fiel mir auf, daß Firefox 3.0 unter Mac OS X und unter Windows Vista (nicht jedoch unter Linux) ein Problem mit dem CSS-Attribut overflow: auto hat. Über diesen Fehler fand ich nichts im Netz, daher hier eine Beschreibung und die Lösung des Problems.

Das Problem betrifft einzeilige Blockelemente, in meinem Fall Codebeispiele, die so notiert sind:

<pre><code>print "That's a string with plenty of characters, but not too much sense"</code></pre>

Theoretisch sollte es ausreichen, das <pre>-Element mit overflow: auto zu formatieren. Jedoch nicht so will es der Firefox. Im Gegensatz zu Safari und Opera zeigt er dort, wo er sollte, bei Einzeilern keinen Scrollbar an.

Beheben läßt sich das Problem relativ einfach. Hat man beispielsweise font-size: 11px; definiert, so läßt sich der Mac OS X-Firefox hiermit zu einer korrekten Anzeige überreden:

pre {
    min-height: 15px;
    overflow: auto;
}

Leider machen es einem weder Internet Explorer noch Windows-Firefox so einfach. Um auch diese beiden zur Anzeige eines Scrollbar zu bewegen, muß min-height: 20px; notiert werden. Das sieht dann leider nicht mehr ganz so hübsch aus … Wer möchte, kann ja noch eine Weiche einbauen ;)

Letztens wollten wir auf Arbeit aus Second Life heraus die Twitter-API benutzen. Sollte wohl kein Problem sein, gibt es doch eine schöne Dokumentation zu letzterer. Da heißt es unter anderem:

The Twitter API tries to conform as much as possible to the design principles of Representational State Transfer (REST) … Twitter presently supports the following data formats: XML, JSON, and the RSS and Atom syndication formats.

Na prima, dann gibt’s wohl keine Schwierigkeiten ;) Wenn man wie z.B. in Linden Scripting Language nicht die Möglichkeit hat, Authentifizierungsdaten mit in den HTTP-Header zu packen, kann man diese REST-Resource verwenden, um ein Update an einen Twitter-Account zu schicken:

http://<username>:<password>@twitter.com/statuses/update.xml

Das .xml bezeichnet keine Datei, sondern eine Resource, die in der HTTP-Response etwas im XML-Format liefert. Analog dazu gibt es auch diese Resource, die eine Antwort als JSON-String zurückgibt:

http://<username>:<password>@twitter.com/statuses/update.json

Jetzt will man natürlich ganz toll RESTful sein und einen POST an diese Resource schicken. Aber es will und will nicht funzen. Kein Twitter-Update ist zu sehen, auch keine Fehlermeldung, sondern ein braver Status 200 kommt zurück. Nach etlichen Stunden Haareraufens und unzähligen Verwünschungen fand ich dann endlich irgendwo in einer Google Group klitzeklein und ganz am Rande die Lösung.

Man muß zwar den Request als POST abschicken, aber trotzdem wie einen GET aufbauen. Also so:

http://<username>:<password>@twitter.com/statuses/update.xml?status="Dieser Text soll bei Twitter zu lesen sein!"

Vielleicht sollte man ein solches bizarres Feature auch dokumentieren, wenn man schon eine API zur Verfügung stellt und wohl auch wünscht, daß diese benutzt wird?!? Nicht jeder hat die Nerven dafür, sich sowas zu erärgern!

Zum Exportieren von MySQL-Datenbanken nach SQLite gibt es bei http://www.sqlite.org/ ein kleines Shellscript, das aber bei mir leider nicht so ganz zufriedenstellend funktionieren wollte. Vor allem nicht mit diesem Beitrag hier ;) Darum habe ich mir erlaubt, das Script ein wenig zu modifizieren:

#!/bin/sh
if [ "x$1" == "x" ]; then
    echo "Usage: $0 <dbname>"
    exit
fi

if [ -e "$1.db" ]; then
    echo "$1.db already exists.  I will overwrite it in 15 seconds if you do not press CTRL-C."
    COUNT=15
    while [ $COUNT -gt 0 ]; do
        echo "$COUNT"
        sleep 1
        COUNT=$((COUNT - 1))
    done
    rm $1.db
fi

mysqldump -u root -p --compact --compatible=ansi --default-character-set=binary $1 |
grep -v '^\(  KEY "\)' |
grep -v '^\(  UNIQUE KEY "\)' |
grep -v '^\(  PRIMARY KEY \)' |
grep -v '^\(SET \)' |
sed 's/ / /g' |
sed 's/ primary key autoincrement/ primary key autoincrement/gi' |
sed 's/ smallint([0-9]*) / integer /gi' |
sed 's/ tinyint([0-9]*) / integer /gi' |
sed 's/ int([0-9]*) / integer /gi' |
sed 's/ ]* / /gi' |
sed 's/ enum([^)]*) / varchar(255) /gi' |
sed 's/,]*//gi' |
sed 's/\\//g' |
sed 's/\\"/"/g' |
perl -e 'local $/;$_=<>;s/,\n\)/\n\)/gs;print "begin;\n";print;print "commit;\n"' |
perl -pe '
if (/^(INSERT.+?)\(/) {
    $a=$1;
    s/\\'\''/'\'\''/g;
    s/\\n/\n/g;
    s/\),\(/\);\n$a\(/g;
}
' > $1.sql

cat $1.sql | sqlite3 $1.db > $1.err
ERRORS=`cat $1.err | wc -l`
if [ "$ERRORS" == "0" ]; then
    echo "Conversion completed without error. Output file: $1.db"
    rm $1.sql
    rm $1.err
else
    echo "There were errors during conversion. Please review $1.err and $1.sql for details." fi

Leider werden mit dieser Version alle Zeilenumbrüche, die innerhalb eines INSERT INTO <table> in der Form \n erscheinen, durch tatsächliche Zeilenumbrüche ersetzt. In Codebeispielen innerhalb von Artikeln können aber auch \n vorkommen, siehe oben. Solche Codebeispiele werden dann zu wirrem Wirrwarr. Also muß noch eine weitere Verbessserung eingebaut werden.

Allerdings ist es etwas kniffelig, mit Regexen die zu ersetzenden \n von denen, die in Codebeispielen drinbleiben sollen, zu unterscheiden. Ich habe zwar ein paar Sachen mit Backreferences ausprobiert, aber aus Zeitmangel gab ich mich vorerst damit zufrieden, in obigem Script die Zeile

s/\\n/\n/g;

durch

s/(?<!(\s<code>))(\\n)(?!(\\\)|(\"))|(\/)|(\$)|(\)))/\n/g;

zu ersetzen. Das ist vielleicht nicht besonders elegant und deckt natürlich lange nicht alle denkbaren Fälle ab, in denen \n in Codebeispiel-Zeilen erscheinen kann. Wenn meine Muße es zuläßt, werde ich demnächst eine bessere Lösung suchen, hoffentlich finden und hier veröffentlichen.

Nun ist es wieder einmal Zeit für einen Relaunch meiner Homepage, nachdem ich bereits vor einiger Zeit beruflich unter die Django-Coder gegangen und ohnehin längst bei Wordpress an die Grenzen dessen kruden Codes gestoßen war. Auf der Suche nach einer Codebase für einen Django-basierten Blog stieß ich alsbald auf Byteflow, welches bereits sehr gut ausgereift ist und alles bietet, was ich brauche. Vielen Dank an die Byteflow-Programmierer aus der Ukraine für ihre exzellente Arbeit! Большое спасибо украинским программистам Byteflow за отличную работу!

Bei der Gelegenheit stand auch gleich ein Umstieg auf Lighty mit FastCGI an, da der Apache mir für meine Privatzwecke langsam zu schwerfällig wurde. Ebenso ist die Datenbank der Wahl nunmehr SQLite.

Was dagegen die Entwicklungsumgebung für’s Webworking angeht, bleibe ich sowohl auf der Arbeit als auch privat weiterhin Eclipse treu. Als Plugins verwende ich Pydev Extensions für Python, Amateras HTML Editor für HTML, CSS und Javascript sowie ByronStar für Linden Scripting Language. Die Anbindung an SVN übernimmt wie immer Subclipse.

Durch Zufall erfuhr ich einige Wochen zuvor von der bevorstehenden letzten Fahrt des T12, des vorletzten Schienenbusses der Prignitzer Eisenbahn, am 12.01.2008. Jahrelang war bereits ein Ausflug zur Prignitzer Eisenbahn geplant gewesen, liegt diese doch für mich beinahe vor der Haustür und war lange bekannt, daß dort noch einige der selten gewordenen geliebten Schienenbusse der Deutschen Bundesbahn, ehemals Baureihe 798, unterwegs waren … doch leider war immer irgendwas anderes wichtiger gewesen, und so kam ich erst zu dieser einigermaßen traurigen Gelegenheit noch einmal in den Genuß einer Fahrt mit dem ehemals roten Brummer.

Ein angenehmer Arbeitsplatz

Bereits seit einigen Jahren nicht mehr im Planeinsatz vertreten, war der Grund für diesen letzten Einsatz des T12 sein bevorstehender Fristablauf am 14.01.2008. Der T12 pendelte zwischen Pritzwalk und Plau am See, wobei der Abschnitt zwischen Pritzwalk und Meyenburg als Planverkehr sowie der zwischen Meyenburg und Plau als Sonderzug galt. Es hatten sich natürlich auch einige Eisenbahnfreunde sowohl im Zug als auch entlang der Strecke eingefunden, doch insgesamt hielt sich das Interesse in Grenzen.

Die PEG hatte am 29.09.1996 auf der Strecke Putlitz - Pritzwalk mit dem T1 die Ära des ex 798 in Nordbrandenburg und Mecklenburg-Vorpommern eingeläutet. Insgesamt waren zwölf Stück davon bei der PEG im Einsatz; ganz besonders interessant daran war die Tatsache, daß die PEG als Kraftstoff Pflanzenöl verwendete. Abgelöst wurden die Schienenbusse schließlich ab Herbst 2003 von den “zeitgemäßen” RegioShuttle-Triebwagen, die es nach der leider wenig maßgeblichen Meinung des Schreibers dieser Zeilen in punkto Komfort in keiner Weise mit den alten Schienenbussen aufnehmen können.

Im Bahnhof Pritzwalk war vor der Rückfahrt nach Plau am See genug Zeit, den Schienenbus noch einmal ausgiebig von allen Seiten abzulichten

Der T12 der PEG zeigte sich auf seiner letzten Fahrt in sehr gutem Zustand

Der T12 wurde nach seinem Fristablauf abgestellt. Seine Zukunft ist ungewiß, da nach Aussagen eines freundlichen Herrn von der PEG, der auf der Fahrt anwesend war, niemand für das Fahrzeug Interesse aufgebracht habe. Da nur eine Abstellung im Freien in Frage komme, sei auch absehbar, wann der Zustand aufgrund des allgegenwärtigen Vandalismus der Schrottreife nahekomme.

Allerdings dürften gewisse Animositäten, wie sie z.B. anscheinend zwischen der Prignitzer Eisenbahn und den Berliner Eisenbahnfreunden (welche seit Jahren Museumsbetrieb auf der alten Stammstrecke der Heidekrautbahn zwischen Berlin-Wilhelmsruh und Basdorf durchführen) bestehen, dem an sich vorhandenen gemeinsamen Anliegen aller Eisenbahnfreunde, historische Fahrzeuge möglichst zu erhalten, durchaus abträglich sein.

Im Bahnhof Meyenburg gab es noch einiges Interessante abzulichten:

T10 hat ebenso wie V25.01 bereits bessere Zeiten gesehen

Eine beträchtliche Anzahl formschöner Triebwagen dänischer Herkunft war in Meyenburg abgestellt: Ys 92/Ym 54 …

… und Ym 53 von der Helsingør-Hornbæk Gillele-Banen

Wie dem auch sei: Noch bleibt der PEG ein allerletzter betriebsfähiger ex 798, nämlich der T11, und den wird man hoffentlich noch häufig im Einsatz erleben dürfen. Möge dem T12 das Schicksal seines Bruders T10 erspart bleiben …

Wie die Erfahrung lehrt, tauchen bei PHP immer wieder seltsame undokumentierte Fehler auf, die ein bestimmtes Minor Release betreffen. So wieder einmal geschehen bei meinem ersten Ansatz, Typo3 auf meinem Entwicklungsrechner zu installieren.

Aber der Reihe nach. Der Einfachheit halber entschied ich mich für YAML für TYPO3, um schnell und ohne große Mühe eine vorgefertigte Seitenstruktur zu erhalten, die ich als Ausgangsbasis für meine Privathomepage benutzen konnte. Dessen Installation sowie die der Extensions, die ich vorderhand für eine schicke Ajax-Bildergalerie benutzen wollte (ce_gallery, dam, dam_catedit, dam_file und ameos_dragndropupload), lief auch problemlos ab. Schien ja eine feine Sache zu sein! Doch beim ersten Hineinfummeln in dam kam gleich die Ernüchterung. Der Aufruf von Media / Datei im Typo3-Backend lieferte diese “hübsche” Fehlermeldung:

Fatal error: Cannot re-assign $this in /home/user/public_html/typo3/typo3conf/
ext/static_info_tables/class.tx_staticinfotables_syslanguage.php on line 43

Nun war für mich als Typo3-Anfänger erstmal guter Rat teuer! Was kann das sein? Vielleicht braucht man eine neuere Version der Extension static_info_tables? Mit der scheint es ja irgendwas zu tun zu haben. Aber leider gibt’s keine neuere Version. Es muß wohl an was anderem liegen.

Irgendwo in den Tiefen des Web fand ich dann eine vage Vermutung, daß der Fehler mit PHP 5.2 zu tun haben könnte. Solche Sachen kamen mir irgendwie bekannt vor. Also wurde die bei mir vorhandene PHP-Version 5.2.4 kurzerhand mittels

~$ apt-get remove php5

entfernt und unter
http://museum.php.net/php5/php-5.1.6.tar.bz2
die Version 5.1.6 heruntergeladen. Leider sind in den offiziellen Debian-Repositories keine fertig kompilierten Pakete für diese “museumsreife” Version mehr vorhanden, also muß mal wieder selber kompiliert werden.

Dazu werden vorher gegebenenfalls noch ein paar zusätzliche Pakete benötigt:

~$ apt-get install flex libxml2-dev libmysqlclient15-dev \
libpng3 libpng3-dev libjpeg62 libjpeg62-dev \
libgmp3c2 libgmp3-dev libmcrypt4 libmcrypt-dev \
libreadline5 libreadline5-dev

Dann wird das Quellcodepaket von PHP 5.1.6 entpackt, in das entstandene Verzeichnis gewechselt und dort das configure-Skript mit einer Reihe von Parametern aufgerufen:

~$ ./configure --with-apxs2=/usr/bin/apxs2 --with-dom --with-ftp \
--with-gettext --with-gmp --with-mcal \
--with-mcrypt --with-mysql --with-readline \
--with-ttf --with-xml --with-zlib=yes \
--with-gd --with-openssl --with-iconv \
--with-soap --with-pear --disable-debug \
--enable-bcmath --enable-calendar --enable-ctype \
--enable-dbase --enable-discard-path --enable-exif \
--enable-filepro --enable-force-cgi-redirect --enable-ftp \
--enable-gd-imgstrttf --enable-gd-native-ttf --enable-inline-optimization \
--enable-magic-quotes --enable-mbstr-enc-trans --enable-mbstring \
--enable-mbregex --enable-memory-limit --enable-safe-mode \
--enable-shmop --enable-sigchild --enable-sockets \
--enable-sysvsem --enable-sysvshm --enable-track-vars \
--enable-trans-sid --enable-versioning --enable-wddx \
--enable-yp

Es folgt der Compilerlauf:

~$ make

Danach könnte das neu kompilierte PHP 5.1.6 mittels

~$ make install

installiert werden. Allerdings an der Debian-Paketverwaltung “vorbei”. Da ich jedoch Wert auf ein gepflegtes System lege, bei dem sich alle Pakete jederzeit wieder sauber deinstallieren lassen, verwende ich zum Installieren von selbstkompilierter Software stets das Programm checkinstall. Dieses wird gegebenenfalls installiert:

~$ apt-get install checkinstall

checkinstall erstellt aus den kompilierten Binaries zunächst ein Debian-Paket (in diesem Fall namens php_5.1.6-1_i386.deb) und installiert dieses danach mittels dpkg. Der Aufruf dazu lautet einfach:

~$ checkinstall make install

Dieses Paket läßt sich dann, falls man es jemals wieder loswerden möchte, einfach mit:

~$ dpkg -r php

sauber deinstallieren.

Weitere Informationen zu checkinstall finden sich auf der Projekthomepage:
http://www.asic-linux.com.mx/~izto/checkinstall/
und in Linuxwiki:
http://linuxwiki.de/CheckInstall

Wenn soweit alles geklappt hat, wird der Apache neugestartet:

~$ /etc/init.d/apache2 restart

Dabei kann es noch zu folgendem Fehler kommen:

apxs:Error: Activation failed for custom /etc/apache2/httpd.conf file..
apxs:Error: At least one `LoadModule' directive already has to exist..

Dann muß in /etc/apache2/httpd.conf folgender Eintrag vorgenommen werden:

<IfModule mod_php5.c>
AddType application/x-httpd-php .php .phtml .php3
AddType application/x-httpd-php-source .phps
</IfModule>
LoadModule php5_module /usr/lib/apache2/modules/libphp5.so

Nun nochmals ein Apache-Neustart:

~$ /etc/init.d/apache2 restart

Jetzt sollte alles wie gewünscht laufen – der Fehler im Typo3-Backend ist weg, und der Konfiguration der schicken Ajax-Bildergalerie steht nichts mehr im Wege.

Natürlich ist so ein Downgrade nicht gerade eine sehr elegante Angelegenheit. Besonders unschön finde ich, daß die seit PHP 5.2.0 vorhendene JSON-Funktionalität (JavaScript Object Notation; diese wandelt PHP-Arrays in Transportstrings um, die bei einem Ajax-Request auf der aufrufenden Seite mittels Javascript in Objekte “dekodiert” werden können, siehe http://www.json.org/) damit futsch ist. Tja … das sind halt so die Kompromisse, die man manchmal eingehen muß … Hauptsache ist, daß ich jetzt mit Typo3 weiterfrickeln kann :)

Leider gibt es im Moment keine einfache Möglichkeit, Tomcat aus Debian-Paketquellen zu installieren. Man hört auch häufig, Tomcat sei besonders schwierig und kryptisch zu installieren, aber so schlimm ist es wieder nicht, wenn man sich schon ein bißchen mit Linux auskennt ;)

Hier eine kleine Einführung dazu, was Tomcat eigentlich ist und was er macht:
http://tomcat.apache.org/tomcat-5.5-doc/jasper-howto.html

Ich gehe in diesem Tutorial davon aus, daß man sich eine lokale Entwicklungs- und Testumgebung für die JSP- und Servlet-Entwicklung schaffen möchte und daß Apache 2.2.x bereits installiert und lauffähig ist. Daher sollte man als allererstes nachsehen, welche Java-Version überhaupt installiert ist:

~$ java -version
java version "1.5.0_13"

Wenn eine Version älter als 1.5.0 (Java 5) vorhanden ist, sollte unbedingt ein Update auf diese gemacht werden. Unter Debian geschieht dies mittels

~$ apt-get install sun-java5-jre sun-java5-jdk

Zur Konfiguration von Eclipse als IDE der Wahl für die JSP- und Servlet-Entwicklung empfehle ich einen Blick auf dieses hervorragende Tutorial in deutscher Sprache:
Teil 1: http://dm.zimmer428.net/index.php/archives/238
Teil 2: http://dm.zimmer428.net/index.php/archives/239

Seit neuestem gibt es auch bereits fertig vorkonfigurierte Eclipse-Pakete für die JSP- und Servlet-Entwicklung, darauf werde ich jedoch in meinem nächsten Tutorial über die Installation von kompletten J2EE-Umgebungen mit JBoss unter Debian zurückkommen.

Tomcat installieren und konfigurieren

Dazu wird zunächst die neueste Version von Tomcat 5.5 von der Downloadseite heruntergeladen:
http://tomcat.apache.org/download-55.cgi

Das erhaltene Archiv hat eine Bezeichnung ähnlich dieser:

apache-tomcat-5.5.x.tar.gz

wobei das x die Versionsnummer des jeweiligen Minor Release anzeigt, im Moment also apache-tomcat-5.5.25.tar.gz. Unter der Annahme, daß das Archiv nach /home/user/tmp heruntergeladen wurde, wird das Archiv entpackt:

~$ cd /home/user/tmp
~$ tar xvzf apache-tomcat-5.5.25.tar.gz

Nun wird das Verzeichnis apache-tomcat-5.5.25 an das gewünschte Ziel kopiert, hier beispielhaft nach /opt:

~$ mv apache-tomcat-5.5.25 /opt
~$ cd /opt
~$ ln -s apache-tomcat-5.5.25 tomcat

Tomcat soll als Daemon laufen, daher benötigen wir das Tool jsvc. Dieses ist in dem heruntergeladenen Archiv enthalten, muß jedoch kompiliert werden:

~$ cd apache-tomcat-5.5.25/bin
~$ tar xvzf jsvc.tar.gz
~$ cd jsvc-src
~$ ./configure --with-java=/usr/lib/jvm/java-1.5.0-sun
~$ make
~$ cp jsvc /opt/tomcat/bin/

Als nächstes wird das mitgelieferte Init-Skript an die richtige Stelle kopiert …

~$ cd native
~$ cp Tomcat5.sh /etc/init.d/tomcat

… und angepaßt:

~$ vi /etc/init.d/tomcat
JAVA_HOME=/usr/lib/jvm/java-1.5.0-sun
CATALINA_HOME=/opt/tomcat
DAEMON_HOME=/opt/tomcat
TOMCAT_USER=tomcat
CATALINA_BASE=/opt/tomcat\n$DAEMON_HOME/bin/jsvc \

Achtung, die letzte Zeile kommt sowohl in der Sektion “start” als auch in der Sektion “stop” vor und ist an beiden Stellen zu ändern!

Dann werden noch für den gewünschten Runlevel, in dem Tomcat automatisch gestartet und gestoppt werden soll, die symbolischen Links gesetzt:

~$ cd /etc/rc5.d
~$ ln -s ../init.d/tomcat S65tomcat
~$ ln -s ../init.d/tomcat K65tomcat

Tomcat soll, wie das auf Linux-Systemen aus Sicherheitsgründen für solche Applikationen allgemein üblich ist, unter einem eigenen User laufen. Also fügen wir dem System einen User und eine Gruppe — beide namens “tomcat” — hinzu, wobei der User tomcat außerdem zu der Gruppe www-data gehören soll:

~$ groupadd -g 65 tomcat
~$ useradd -u 65 -g 65 -d /opt/tomcat -s /bin/false -c "Tomcat User" tomcat
~$ chown -R tomcat:tomcat /opt/apache-tomcat-5.5.25
~$ usermod -G www-data tomcat

Jetzt kann Tomcat gestartet werden:

~$ /etc/init.d/tomcat start

Die Beispielapplikationen, die Tomcat mitbringt, sind im Dateisystem unter /opt/tomcat/webapps zu finden. Daher wird jetzt, wenn alles richtig gemacht wurde, unter
http://localhost:8080
die Tomcat-Startseite zu sehen sein! Unter
http://localhost:8080/jsp-examples/
sind dann die mitgelieferten JSP-Beispiele zu bewundern.

Nun ist es aber sicher nicht sinnvoll, jeden Aufruf an den neu installierten Tomcat über dessen Default-Port 8080 am Webserver laufen zu lassen. Darum wird im nächsten Schritt der Tomcat Connector mod_jk installiert.

mod_jk installieren und konfigurieren

Dazu wird gegebenenfalls zunächst weitere Software benötigt, die mit folgendem Kommando installiert wird:

~$ apt-get install libtool autoconf \
gcc g++ apache2-prefork-dev

Nun wird die neueste Version von mod_jk 1.2, zur Zeit ist das 1.2.25, von der Downloadseite heruntergeladen:
http://tomcat.apache.org/download-connectors.cgi

Das Archiv hat eine Bezeichnung ähnlich tomcat-connectors-1.2.x-src.tar.gz, siehe oben.

Lustigerweise ist die Entwicklung des präsumptiven Nachfolgers mod_jk2 eingestellt und stattdessen mod_jk einer Auffrischung unterzogen worden, was aber nicht weiter stören soll ;)

Das Archiv wird entpackt und kompiliert:

~$ cd /home/user/tmp
~$ tar xvzf tomcat-connectors-1.2.25-src.tar.gz
~$ cd tomcat-connectors-1.2.25-src/native
~$ ./configure --with-apxs=/usr/bin/apxs2
~$ make
~$ make install

Als nächstes müssen eine Reihe von Skripten angelegt werden:

~$ cd /etc/apache2
~$ vi workers.properties
# Tomcat and Java configuration
workers.tomcat_home=/opt/tomcat
workers.java_home=/usr/lib/jvm/java-1.5.0-sun
ps=/
worker.list=mainworker
# Definition for local worker using AJP 1.3
worker.mainworker.type=ajp13
worker.mainworker.host=localhost
worker.mainworker.port=8009
worker.mainworker.cachesize=20

~$ cd /etc/apache2/mods-available
~$ vi jk.load
LoadModule jk_module /usr/lib/apache2/modules/mod_jk.so
~$ vi jk.conf
<IfModule mod_jk.c>
JkWorkersFile /etc/apache2/workers.properties
JkLogFile /var/log/apache2/mod_jk.log
JkLogLevel error
</IfModule>

Jetzt werden jk.load und jk.conf noch für Apache verfügbar gemacht …

~$ cd /etc/apache2/mods-enabled
~$ ln -s ../mods-available/jk.conf jk.conf
~$ ln -s ../mods-available/jk.load jk.load

.. und schließlich Tomcat neu gestartet:

~$ /etc/init.d/tomcat stop
~$ /etc/init.d/tomcat start

Nun ist nur noch ein letzter Schritt notwendig, nämlich dem Apachen zu sagen, was genau er an Tomcat weiterleiten soll.

Apache konfigurieren

Wie oben schon gesagt, bezieht sich dies alles auf Apache 2.2.x. Die Virtual Hosts, die der jeweilige Apache kennen soll, sind im Verzeichnis /etc/apache2/sites-available konfiguriert. Dort findet sich eine Datei namens “default”, in der die Vorgabe enthalten ist. Da im Moment keine weiteren Virtual Hosts benötigt werden, wird der Einfachheit halber diese Konfiguration verwendet.

Die Beispielapplikationen, die Tomcat mitbingt, sind wie erwähnt unter /opt/tomcat/webapps zu finden. Wenn nun eigene Projekte unter /opt/tomcat/webapps/myprojects abgelegt werden und im Browser unter
http://localhost/myprojects/
erreichbar sein sollen, wird in der Datei default innerhalb des Virtual Host ein Eintrag hinzugefügt:

~$ cd /etc/apache2/sites-available
~$ vi default
Alias /myprojects/ "/opt/tomcat/webapps/myprojects/"
<Directory "/opt/tomcat/webapps/myprojects/">
Options Indexes +FollowSymLinks
</Directory>
JkMount /myprojects/* mainworker

Die letzte Zeile weist Apache an, mittels des (siehe oben) in /etc/apache2/workers.properties definierten Workers “mainworker” alle Aufrufe an
http://localhost/myprojects/

an Tomcat weiterzuleiten.

Um dies zu testen, bietet es sich an, die Beispielapplikationen aus /opt/tomcat/webapps/jsp-examples nach /opt/tomcat/webapps/myprojects zu kopieren:

~$ cp /opt/tomcat/webapps/jsp-examples /opt/tomcat/webapps/myprojects

Nach einem Neustart von Apache mittels

~$ /etc/init.d/apache2 restart

sollte nun
http://localhost/myprojects/jsp-examples/
im Browser erreichbar sein!

Weiteres zur Konfiguration von Apache mit mod_jk ist hier zu finden:
http://tomcat.apache.org/connectors-doc/

Damit sind Installation und Konfiguration abgeschlossen, und der Entwicklung eigener JSPs und Servlets steht nichts mehr im Wege!

Leider habe ich bis jetzt noch keine Möglichkeit gefunden, wie man Apache und Tomcat dazu überreden kann, JSPs und Servlets aus User-Homeverzeichnissen heraus auszuführen. Sollte ein geneigter Leser über diesbezügliche Erfahrungen verfügen, freute ich mich sehr über Feedback!

Hier noch ein Link zu weiterführenden Informationen zum Finetuning von Tomcat in Produktionsumgebungen:
http://jspwiki.org/wiki/DeploymentOptimizations

Quellen:
http://daff.neyeon-digital.de/blog/2007/02/07/apache2-tomcat-55x-mod_jk-12x/
http://www.crazysquirrel.com/computing/debian/servers/tomcat55.jspx

Für alle Programmierer, die sich einen Überblick über J2EE verschaffen wollen, bietet Herr Sang Shin einen kostenlosen Online-Kurs an, der sich mit den Grundlagen von Servlet, JSP (Java Server Pages), MVC (Model View Controller), Struts, JSF (Java Server Face), EJB (Enterprise Java Beans), JPA (Java Persistence API), Hibernate und Spring Framework befaßt.

So ein Angebot findet man nicht alle Tage! Die Sache ist recht umfangreich und setzt einiges an persönlichem Engagement voraus. Zwar heißt es an vielen Stellen im Web und in den einschlägigen Printmedien, daß Ruby on Rails derzeit der hellste “Shooting Star” am Webhimmel sei, aber meiner eigenen Erfahrung nach werden die gängigen J2EE-Technologien real im Moment doch am meisten nachgefragt.

Der Kurs beginnt am 19. November 2007. Alles weitere gibt es unter:

http://www.javapassion.com/j2ee/

Allen Teilnehmern wünsche ich viel Erfolg, und vielen Dank für dieses tolle Angebot an Herrn Sang Shin!