Erste Tests mit Apache 2.0, mod-perl 2.0 und PHP 5.2

Bis jetzt habe ich noch nie den Zwang verspürt, vom stabil laufenden Apache 1.3 weg zur Version 2.0 zu wechseln. Wenn man abber subversion einsetzen will und den Apache dazu als Zugang nutzen will, benötigt man Apache 2.0. Es stellt sich nun die Frage, inwieweit ein Apache 1.3.X mit mod_perl 1.X und PHP 4.4 neben einem Apache 2.0.X mit mod_perl 2.X und PHP 5.X lauffähig ist.

Bis jetzt habe ich den Apache immer statisch mit seinen Erweiterungen installiert. Ich habe also nicht das DSO genutzt. Dies hat vermutlich nur noch historische Gründe. Früher lief der Apache bedeutend stabiler auf diese Weise. Außerdem blieb er so schön schlank, da ich nur die Module einkompiliert, die ich wirklich benötigte. Zum anderen konnte ich verschiedene Apache-Versionen z.B. unter /usr/local installieren und über einen Symlink /usr/local/apache immer den aktuellen ansprechen.

Auf jeden Fall scheint dieses statische bauen des Apache in der Version 2.0 und PHP 5 nicht mehr vorgesehen zu sein, wenn man der Installationsanleitung glauben schenken darf. Nun gut, so habe ich also zunächts den Apache gebaut:

$ ./configure --prefix=/usr/local/apache-2.0.59-dso  --enable-rewrite=shared --enable-so
$ make
$ make install

installiert den Apache (hier 2.0.59).

Nun zu mod_perl (hier 2.0.3):

Laut der Voraussetzungsseite benötigt man mindestens Perl Version 5.8.0 oder höher:

$ perl -v

Außerdem muss

$ perl -V:useithreads -V:usemultiplicity 
useithreads='define';
usemultiplicity='define';

liefern sowie

$ perl -V:use5005threads
use5005threads='undef';

Ist das geklärt, baut man und installiert man wie folgt mod_perl:

$ perl Makefile.PL MP_AP_PREFIX=/usr/local/apache-2.0.59-dso
$ make
$ make test
$ make install

Dann kommt PHP 5 (hier 5.2.0) an die Reihe. Hierfür musste ich noch folgende Pakete auf dem Debian sarge System nachinstallieren:

$ apt-get install libxml2 libxml2-dev
$ apt-get install g++
$ apt-get install libpng-dev libgd-dev
$ apt-get install libmysqlclient12-dev

Dann geht es so weiter:

$ ./configure --with-apxs2=/usr/local/apache-2.0.59-dso/bin/apxs  --with-zlib --with-gd 
--with-mysql --prefix=/usr/local/php-5.2.0
$ make
$ make test
$ make install

Damit kann dann der neue Apache 2.0.59 neben der alten Version 1.3.37 genutzt werden. Interessant wird es, wenn es um diverse Perl-Module geht, die für die Mod_perl Version 1.x entwickelt wurden und in die diversen Request-Phasen des Apaches eingreifen.

Durch den Aufruf von use Apache2::compat(); im startup-Skript scheinen diese weitestgehend weiterzulaufen. Zur Migration finden man auf den Seiten von mod_perl weitere Hinweise.

Einen ersten Schrecken erlebte ich bei Modulen, die Apache::Cookie nutzen. Diese laufen nicht weiter. Dafür gibt es aber nun das Modul Apache2::Cookie (welch Überraschung ;-). Nun gut, also das schnell installiert — Pustekuchen. Dafür musste ich erst libexpat1-dev nachinstalliern:

$ apt-get install libexpat1-dev

Dann benötigte man noch das Paket ExtUtils::XSBuilder (unter http://www.cpan.org/modules/by-module/ExtUtils/ExtUtils-XSBuilder-0.28.tar.gz zu finden), was seinerseits noch Parse::RecDescent (http://www.cpan.org/modules/by-module/Parse/Parse-RecDescent-1.94.tar.gz zu finden) benötigt.

Nun erst kann man per

$ perl Makefile.PL --with-apache2-apxs=/usr/local/apache2/bin/apxs
$ make
$ make test
$ make install

das Perl-Modul Apache::Cookie installieren. Und hier sieht man auch, was mich nachdenklich stimmt: Zur Installation eines Perl-Modules muss ich das Apache-Installationsverzeichnis angeben. Es stellt sich sofort die Frage, was passiert, wenn ich einen neueren Apache installiere. Muss ich dann das (oder ggf. die) entsprechenden Perl-Module neu installieren?

Dass aber Apache 1.3.x/Mod_perl 1.x und Apache 2.0.x/Mod_perl 2.x so schön neben einander zu betreiben sind, freut mich doch.

Auf den Spuren von Numb3rs oder: wann wurde eine Aufnahme von Google Earth gemacht?

Durch die Numb3rs-Folge vom Donnerstag wurde mir eine Fragestellung wieder in den Kopf gerufen, die mir beim Spielen mit Google-Earth-Bildern in den Sinn kam. In der Folge ermittelt Charlie Eppes zusammen mit seinem Kollegen Larry Fleinhardt aufgrund von verschiedenen Aufnahmen eines Hofes mit einem Basketballkorb die Position dieses Hofes. Er nutzt dazu den Schattenwurf des Korbes, die genaue Aufnahmezeit und die Pflastersteine des Hofes als Maßstab.

Mich beschäftigte die Frage, wann eine Aufnahme bei Google-Earth gemacht wurde. Betrachtet man die Richtung des Schattens eines Gebäudes, kann man den Azimut der Sonne ermitteln. Betrachtet man die Länge des Schattens und kennt die Höhe des Gebäudes, kann man die Höhe der Sonne über dem Horizont ermitteln. Nun muss man "nur" noch ermitteln, wann die Sonne an genau dieser Stelle am Himmel steht. Wollte man das analytisch lösen, wird es sehr aufwändig. Aber dazu später mehr.

Ich hatte nun das Problem, dass ich ein Objekt suchen musste, dessen Höhe ich kenne. Ein weiterer Punkt war der Abbildungsmaßstab. Auf den Karten, die man von maps.google.de herunterladen kann, ist zwar ein Maßstab angegeben. Allerdings soll der sowohl in x- wie auch in y-Richtung dienen. Wer sagt mir aber, dass die Bilder nicht doch verzerrt sind? Das sollte zwar nicht der Fall sein, da man ja auch die Karten über die Bilder legen kann, aber: sicher ist sicher….

Ich habe mir daher den Frankfurter Europaturm (oder Ginnheimer Spargel, wie wir Frankfurter sagen) ausgesucht. Über ihn liest man auf eben dieser Seite, dass er 337,5m hoch und, was für den Maßstab wichtig ist, dass seine Plattform einen Durchmesser von 59m hat.

Ich habe mir nun als erstes das folgende Bild zusammen gebaut:

Fernmeldeturm-klein

Dort habe ich zum einen den Abbildungsmaßstab ausgemessen, indem die Ausmaße der Plattform in x- und y-Richtung ausgemessen habe.

Daraufhin habe ich die Schattenlänge ausgemessen. Sie beträgt 343,4m. Dies ergibt eine Sonnenhöhe von 44,5°. Aus der Richtung des Schattens (und der Annahme, dass Norden oben ist) ergibt sich ein Azimut von 155,2°.

Mit Hilfe von Guide 8 von Project Pluto habe ich nun durch Ausprobieren im Jahr 2006 die zwei Termine gefunden, zu denen die Sonne dort steht:

  1. 8. April 2006; 11:16 MEZ
  2. 4. September 2006; 11:13 MEZ

Erfahrungsgemäß sind die Bilder bei Google-Earth ein knapps Jahr alt. Doch welcher der beiden Termine ist der richtige? Ich lege mich auf den 8. April aus zwei Gründen fest: Zum einen scheinen einige Bäume auf dem Bild zu blühen. Zum anderen ist der Verkehr auf der Rosa-Luxemburg-Straße östlich des Turmes recht schwach. Da der 8. April ein Samstag war, der 4. September aber ein Montag, halte ich den 8. April für wahrscheinlicher.

Ein netter Spaß war es auf jeden Fall 😉

Der Unterschied zwischen gespidert und im Index von Google.

Ich stolperte die Tage über diesen Artikel, der den Unterschied zwischen gespidert und im Index zu erklären versucht. Demnach würde eine Abfrage per site:domain.de die Anzahl der URLs im Index zurückliefern, die aber nicht notwendiger Weise auch bei einer Suche nach Keywords ausgegeben würden. Dies wäre erst möglich, wenn die Seiten auch gespidert worden sind.

Wie ist aber dann zu erklären, dass eine Suche nach site:heise.de 1.32 Mio Seiten liefert, eine Suche nach site:heise.de impressum aber 6.61 Mio Seiten liefert? Es ist zu beachten, dass zur Zeit jede dieser Abfragen relativ hohe Sprünge macht. Die Tendenz, dass die speziellere Suche aber mehr Seiten liefert als die allgemeinere, besteht aber immer.

Diese inhaltsleeren Zahlen belegen eigentlich, dass die knackigen Marketing-Sprüche von der Durchdringung einer Site bei Google nichts als heiße Luft sind. Ich wage sogar zu bezweifeln, dass Google selbst genau weiß, nach welchem System Treffer gefunden werden.

Auch die Webmaster-Tools sind in meinen Augen nach anfänglicher Euphorie recht nutzlos. Wären diese Tools wirklich sinnvoll einzusetzen, so dürfte es nicht vorkommen, dass bei zwei von mir betreuten Sites plötzlich keine Begriffe mehr angezeigt werden, die Google für wichtig erachtet (der Punkt Seitenanalyse unter dem Reiter Statistik). Über die Sinnlosigkeit der Abfragestatistik hat ich ja bereits früher geschrieben.

Mircosoft löst das Spam-Problem

Wie auf heise.de zu lesen ist, soll in Outlook 2007 nicht mehr der Internet Explorer das Rendern von HTML-Mails übernehmen sondern Word 2007. Dort heißt es weiter, das "Heulen und Zähneklappern" habe begonnen, da es mit Word nicht mehr möglich sei, HTML-Mails so aussehen zu lassen, wie das bis jetzt der Fall ist. So könne man kein CSS mehr nutzen und keine Hintergrundbilder und vieles mehr, was in E-Mails sowieso nichts zu suchen hat.

Ich sehe das so: Wenn es endlich keinen Sinn mehr macht, HTML-Mails zu verschicken, gibt es auch keinen Grund mehr, sie nicht zu blocken. Wenn ich aber jegliche HTML-Mails gleich wegwerfe, kommt kein Spam mehr in mein Postfach – genial!

Routing Änderungen bei der T-Com

Es scheint, dass sich das Routing bei der T-Com in Richtung auf meinen vServer in letzter Zeit geändert hat. So sah das Routing am 4.1.2007 wie folgt aus:

HOST: debian                      Loss%   Snt   Last   Avg  Best  Wrst StDev
1. firewall.mst 90.7% 1000 0.4 1.4 0.4 3.9 0.7
2. ??? 100.0 1000 0.0 0.0 0.0 0.0 0.0
3. 217.0.66.2 0.0% 1000 63.8 13.2 6.5 244.7 20.8
4. so2-1-0-622M.ar1.FRA2.gblx.n 0.0% 1000 64.0 15.2 6.7 256.8 22.0
5. so2-0-0-2488M.ar2.FRA3.gblx. 0.0% 1000 21.6 25.0 7.0 329.6 38.4
6. ge9-1-600.cr1.FRA3.ip-exchan 0.0% 1000 9.4 14.0 6.9 251.2 20.4
7. srp2-0.cr1.NBG1.content-core 0.0% 1000 14.0 17.6 10.1 262.1 20.5
8. srp8-0.cr1.NBG2.content-core 0.0% 1000 12.4 18.2 10.2 267.6 21.0
9. CC.DHK.NBG.V-BONE.net 0.0% 1000 13.3 18.4 10.6 249.9 21.2
10. AS33956.RS8600.v-bone.net 0.0% 1000 13.3 18.4 10.7 232.5 20.4
11. AS33956.RS8000.v-bone.net 0.0% 1000 13.2 18.5 10.6 240.7 21.0
12. m15s09.vlinux.de 0.0% 1000 11.5 17.9 10.3 775.7 31.5

bzw. in IP-Adressen:

HOST: debian                      Loss%   Snt   Last   Avg  Best  Wrst StDev
1. 192.168.99.5 55.5% 1000 0.5 1.2 0.4 3.1 0.5
2. ??? 100.0 1000 0.0 0.0 0.0 0.0 0.0
3. 217.0.66.2 0.0% 1000 7.5 12.9 6.6 242.6 20.2
4. 208.49.136.173 0.0% 1000 11.9 14.6 6.8 256.6 22.5
5. 67.17.65.58 0.0% 1000 7.5 23.7 7.0 329.7 35.8
6. 208.48.239.10 0.0% 1000 8.0 13.5 7.0 251.1 20.1
7. 212.123.127.17 0.0% 1000 10.3 16.8 10.0 254.7 20.2
8. 212.123.127.35 0.0% 1000 10.7 16.9 10.2 266.3 21.1
9. 212.123.111.62 0.0% 1000 11.1 16.8 10.5 249.9 20.7
10. 80.244.255.234 0.0% 1000 11.3 17.3 10.6 228.2 20.4
11. 80.244.255.242 0.0% 1000 11.8 17.6 10.8 240.7 21.4
12. 83.151.28.203 0.0% 1000 11.1 16.9 10.3 267.5 20.3

Am nächsten Tag, also am 5.1.2007 sah es dann so aus:

HOST: debian                      Loss%   Snt   Last   Avg  Best  Wrst StDev
1. firewall.mst 54.4% 1000 0.5 0.6 0.4 2.7 0.5
2. ??? 100.0 1000 0.0 0.0 0.0 0.0 0.0
3. 217.0.66.6 0.0% 1000 7.8 11.8 6.4 145.1 16.7
4. f-ea3.F.DE.net.DTAG.DE 0.0% 1000 14.0 19.6 6.8 206.0 34.0
5. oc48-pos8-0.cr1.FRA3.ip-exch 0.0% 1000 7.8 12.9 6.8 140.9 16.7
6. srp4-0.cr2.NBG1.content-core 0.0% 1000 12.8 16.2 9.8 143.2 16.8
7. srp8-0.cr1.NBG2.content-core 0.0% 1000 13.9 16.6 10.2 140.5 16.2
8. cbb.dhk.nbg.v-bone.net 1.0% 1000 10.7 23.5 10.2 3241. 143.9
9. AS33956.RS8600.v-bone.net 0.0% 1000 12.8 17.1 10.6 154.5 18.0
10. AS33956.RS8000.v-bone.net 1.8% 1000 14.0 27.9 10.7 4943. 201.6
11. m15s09.vlinux.de 0.0% 1000 11.9 16.4 10.3 155.7 17.5

bzw.

HOST: debian                      Loss%   Snt   Last   Avg  Best  Wrst StDev
1. 192.168.99.5 88.9% 1000 0.9 0.5 0.4 1.9 0.2
2. ??? 100.0 1000 0.0 0.0 0.0 0.0 0.0
3. 217.0.66.6 0.0% 1000 31.1 12.4 6.5 139.3 15.7
4. 62.154.17.50 0.0% 1000 7.6 20.5 6.8 240.1 35.5
5. 193.158.5.22 0.0% 1000 6.9 12.3 6.8 135.2 15.7
6. 212.123.127.18 0.0% 1000 10.5 16.1 10.0 170.5 17.0
7. 212.123.127.35 0.0% 1000 11.3 16.2 10.2 152.6 16.6
8. 81.95.15.30 1.0% 1000 11.6 26.8 10.5 3996. 184.9
9. 80.244.255.234 0.0% 1000 12.2 16.8 10.4 154.4 17.0
10. 80.244.255.242 2.1% 1000 12.0 25.9 10.6 4653. 188.7
11. 83.151.28.203 0.0% 1000 11.6 16.1 10.2 149.8 16.1

 Nun werden also die problematischen Hops gemieden. Das umgestellte Routing machte sich auch in leicht kleineren Ping-Zeiten bemerkbar.

 

Unterhaltung der Woche

Folgende Untrhaltung gab es eben (sinngemäß wiedergegeben) im c't tv:

Mathias Münch: So, Herr Schnurer, im BIOS kann  man also evtl. einstellen, dass der USB-Anschluss schneller ist. Am BIOS zu arbeiten, ist so ähnlich wie unter der Motorhaube zu schrauben. Wie kommt man eigentlich ins BIOS?

Georg Schnurer: Mit dem BIOS ist es wie mit der Motorhaube. Wenn man nicht weiß, wie man die Motorhaube öffnet, sollte auch nicht darunter schrauben. Und wer nicht weiß, wie man ins BIOS kommt, soll die Finger davon lassen.

Suchbegriffe: Google Webmastertools und die Realität stoßen aufeinander …?

Laut Webmaster-Tools soll heisec der am häufigsten benutzte Suchbegriff sein, mit dem von Google auf meine Seite gesprungen wird. Schaue ich mir aber meine eigne Logfile-Auswertung an, so taucht dieser Begriff kein einziges mal auf. Doch damit nicht genug. Angeblich lande ich damit durchschnittlich auf Platz 4 in der Trefferliste….

Entweder verstehe ich da etwas Grundsätzliches ziemlich falsch oder die Webmaster-Tools haben ein gespaltenes Verhältnis zur Wahrheit