PHP. Kennt Ihr die Situation, wenn man sich am Wochenende um seine Altlasten alten Applikationen und Software-Tools kümmert. Genau das mache ich gerade. Und ich stelle fest: “I hate PHP.” Diesen Mist trage ich nun seit dem ersten Semester mit mir rum. Und wenn man es genau betrachtet, dann ist PHP eine Skriptsprache, die zwar für einfache Dinge (wie z.B.: Blogs) durchaus geeignet ist. Aber sobald mal etwas komplexer wird, erfordert PHP oberste Disziplin, damit die Applikationen auch zukünftig gut wartbar bleiben. Professionelles WebDevelopment wird eben nicht mit PHP gemacht. Ich für meinen Teil empfehle Java/Spring WebMVC und Python/Django (plus eventuell Pinax). Java ist typsicher und stabil. Allerdings ziehen die meisten Java-Projekte auch immer einen riesigen Boilerplate-Code-Rattenschwanz hinter sich her. Wesentlich felxibler und schneller ist man mit Python/Django. Genau aus diesem Grund werde ich meine Webapps alle auf Python/Django umstellen. Dann bin ich den bösen Fluch PHP los.

Wenn man sich einen neuen Apache Tomcat installiert und versucht auf das Manager-Servlet (http://[Host]:[Port]/manager/html) zuzugreifen, wird man per Default von der folgenden wunderbaren Meldung begrüßt:

HTTP Status 403 – Access to the requested resource has been denied

Woran liegt das!?

Ganz einfach: Das ist ein Sicherheits-Aspekt. Der Nutzer des Tomcats soll die Konfiguration selbst vornehmen, damit der Tomcat produktiv niemals mit einem Default-Manager-User eingesetzt wird. Die Datei tomcat-users.xml ($CATALINA_HOME/conf/tomcat-users.xml) sieht per Default wie folgt aus:

1
2
3
4
5
6
7
8
9

<?xml version='1.0' encoding='utf-8'>
<tomcat-users>
    <role rolename="tomcat" />
    <role rolename="role1" />
    <role rolename="admin" />
    <user username="tomcat" password="tomcat" roles="tomcat" />
    <user username="role1" password="tomcat" roles="role1" />
    <user username="both" password="tomcat" roles="tomcat,role1" />
</tomcat-users>

Man erkennt auf den ersten Blick: Da gibt es ja gar keinen Manager-User. Aha!

Aber was ist zu tun, wenn man nun doch die Manager-Applikation nutzen möchte!?

Auch das ist wieder denkbar einfach. Man fügt einfach einen neuen Tomcat-User mit einer Manager-Rolle ein. Dazu muss die tomcat-users.xml ($CATALINA_HOME/conf/tomcat-users.xml) wie folgt angepasst werden:

1
2
3
4
5
6
7
8
9
10
11

<?xml version='1.0' encoding='utf-8'>
<tomcat-users>
    <role rolename="tomcat" />
    <role rolename="role1" />
    <role rolename="manager" />
    <role rolename="admin" />
    <user username="tomcat" password="tomcat" roles="tomcat" />
    <user username="role1" password="tomcat" roles="role1" />
    <user username="both" password="tomcat" roles="tomcat,role1" />
    <user username="manager" password="manager" roles="manager,admin" />
</tomcat-users>

Danach muss der Tomcat neu gestartet werden, so dass die Einstellungen übernommen werden können. Jetzt kann man sich mit dem User “manager” und dem Passwort “manager” bequem ins Manager-Servlet einloggen.

Wichtig!

Bevor der Tomcat produktiv eingesetzt wird, sollte diese Änderung jedoch abgewandelt oder rückgängig gemacht werden, da sonst von außen auf das Manager-Servlet zugegriffen werden könnte und ganze Anwendungen undeployt (vom Server entfernt) werden können.

Warum schreibe ich das hier?

Ich habe diese Lösung schon mehrfach gegoogelt und muss irgendwie jedes Mal wieder nachschlagen. Und weil mich das so nervt, pumpe ich die Lösung jetzt in meinen Blog, dann weiß ich wo sie steht.

Der Google-Browser ist da: Google Chrome. Eigentlich war es mir klar, dass soetwas irgendwann von Google kommt. Neben guten Testergebnissen überschattet den Release des neuen Browsers eine neue Diskussion um den Datenschutz. Als HTML-Rendering-Engine dient Webkit. Der JavaScript-Interpreter ist eine Eigententwicklung von Google und trägt den Namen V8. V8 weiß durch hohe Performance zu überzeugen. Der Browser soll scheinbar ein Direktangriff auf Microsoft sein. Dennoch gibt es Google Browser bisher nur für Windows User. Mac- und Linux-Versionen sollen bald folgen. Ich bin gespannt wie sich der Browser entwickelt. Ich selbst habe noch einige Datenschutz-Bedenken, die mich von der Installation des Browsers abhalten. Naja… Mal schauen ob Google mich da noch überzeugen kann.

Neben dem Release des Browsers hat Google aber noch etwas zu feiern. Google wird heute 10 Jahre alt. Dazu gratuliere ich.

Aktuell beschäftige ich mich mit der Google Maps API. Ob ich sie wirklich einsetze, weiß ich bisher noch nicht. Aber es macht schon Spaß ein paar Experimente mit der API zu machen.

Heute morgen bin ich nach dem Aufstehen mal wieder über alle meine Lieblingsblogs gesurft. Anders als sonst war, dass ich jetzt statt Ubuntu Gutsy Gibbon 7.10 und Firefox 2 mit Ubuntu Hardy Heron 8.04 und einer Firefox 3 Beta angetreten bin. Doch was ist das!? Da surfe ich auf Daniels Blog und erhalte vom Firefox eine Warnmeldung:

“Als attackierend gemeldete Webseite!”

Jetzt war ich neugierig. Schließlich ist Daniels Blog alles Andere als attackierend. Deshalb habe ich mir einmal den Spaß gegönnt und auf den “Warum wurde diese Seite blockiert?”-Button geklickt. Und schon wusste ich ein wenig mehr. Die Begründung für die Blockierung war:

“Google has found that some portion of blog.animeroot.org/ contains or links to badware or otherwise violates Google’s software guidelines.”

Nun gut. Da ich darüber sehr überrascht war, habe ich mir mal erlaubt ein curl auf Daniels Blog abzusetzen um zu schauen, was dort so schreckliches getan wird.

Die erste Möglichkeit:

Als erstes fiel mir dabei auf, dass Daniels WordPress-Theme sowohl das JavaScript-Framework “prototype” als auch “scriptaculous“. Das dürfte zwar insgesamt einige Kilobyte an JavaScript ausmachen, die geladen werden müssen, aber das ist für einen privaten Blog doch eher “unkritisch”. Deshalb denke ich nicht, dass der Blog deshalb gesperrt wurde.

Die zweite Möglichkeit:

Ein bißchen Stöberei ließ mich auf Daniels Last.fm-Playlist stoßen, die er als Widget eingebunden hatte. Ein ActiveX-Element. Ich das etwa der Grund? Don’t know… Natürlich können ActiveX-Elemente böse sein. Aber Last.fm sollte Google eigentlich erkennen. Auch hier glaube ich nicht, dass es problematisch ist.

Die dritte Möglichkeit:

Jetzt wird’s scary. Als Statistik-Tool setzt Daniel scheinbar nicht auf Google Analytics. Über einen Zugriff auf eine fremde Domain, wird die Statistik scheinbar mit “phpmyvisites” geschrieben. Soetwas bezeichnet man dann als “Cross Site Scripting”. Und obwohl die Funktionalität ähnlich zu Google Analytics ist, scheint Google dieses Verhalten als “böse” zu erkennen. Im Grunde ist es auch ein kleines Konkurrenz-Produkt zu Google Analytics. Ich vermute das der Einbau dieses Tools “böse” ist. Als Alternative empfehle ich den Einbau von Google Analytics. Das kann das Gleiche oder sogar mehr und ist ebenfalls kostenlos. Das wird Google sicher nicht als böse melden. Allerdings vermute ich, Daniel sich jetzt erstmal wieder mit Google “anfreunden” muss, in dem er sein Statistik-Tool für einige Tage/Wochen ausbaut damit Google erkennt, dass er ein guter ist.

Wer eine genaue statistische Auswertung der Aktivitäten seines Servers sehen möchte, der sollte sich mal Munin ansehen. Munin visualisiert unter anderem CPU-, Disk-, Speicher-, Netzwerk- und MySQL-Aktivitäten des Servers. Ein Tool, dass sehr gut die Überwachung eines Servers unterstützt. Die Installation unter Debian-Systemen ist denkbar einfach:

user@hostname: sudo apt-get install munin munin-node

Anschließend sollte noch die Konfiguration des Tools auf entsprechend den eigenen Einstellungen auf das Webserver-Verzeichnis gebogen werden, so dass Munin dort die Graphen und html-Dokumente für die Visualisierung anlegen kann:

user@hostname: sudo vi /etc/munin/munin.conf

In der Konfiguration sollte “htmldir” auf das Webverzeichnis des Webservers zeigen. Ich nutze den Apache 2 und habe mein Webverzeichnis unter “/var/www”. Im Verzeichnis “munin” legt Munin nun die Munin-HTML-Reports ab. Der Benutzer der den Munin-Cronjob ausführt, sollte sinnvollerweise im Munin-Webverzeichnis Schreibrechte besitzen.

# The next three variables specifies where the location of the RRD
# databases, the HTML output, and the logs, severally. They all
# must be writable by the user running munin-cron.
dbdir /var/lib/munin
htmldir /var/www/munin
logdir /var/log/munin
rundir /var/run/munin

Damit nicht jeder Benutzer, der den Link zum Munin-Webverzeichnis kennt, die Statistiken einsehen kann, lohnt es sich oft einen htaccess-Verzeichnisschutz auf das Munin-Webverzeichnis einzurichten.

Beispiele: