PHPGangsta - Der praktische PHP Blog

Um das Zend Framework in der Webhosting-Umgebung bei 1und1 ans Laufen zu bekommen, gibt es ein paar Kleinigkeiten zu beachten:

Als erstes muss man bei 1und1 in der .htaccess-Datei angeben welche PHP-Version man benutzen möchte. Dies macht man mit der Zeile

AddType x-mapp-php5 .php

Außerdem muß man noch die folgenden 2 Zeilen hinzufügen, sonst erhält man einen 500er Fehler:

Options -MultiViews
RewriteBase /

Die RewriteBase gilt es natürlich anzupassen falls das Projekt über einen anderen Pfad erreicht werden muss.

Da PHP bei 1und1 als CGI läuft, muß man für die HTTP-Authentifizierung auch noch einen kleinen Workaround einbauen:

RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

Damit wird die Authentifizierungsinformation in die Variable $_SERVER[‚REDIRECT_HTTP_AUTHORIZATION‘] geschrieben. Das sieht dann ungefähr so aus:

echo $_SERVER['REDIRECT_HTTP_AUTHORIZATION'];
//  Basic: d2lraTpwZWRpYQ==

Das ist die Base64-Darstellung von „Username:Passwort“.

Die entgültige .htaccess sieht dann so aus:

AddType x-mapp-php5 .php
Options -MultiViews

RewriteEngine On
RewriteBase /

# workaround for 1und1 php cgi mode
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

RewriteCond %{REQUEST_FILENAME} -s [OR]
RewriteCond %{REQUEST_FILENAME} -l [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^.*$ - [NC,L]
RewriteRule ^.*$ index.php [NC,L]

Und so kommt man an Username + Passwort heran:

if (isset($_SERVER['REDIRECT_HTTP_AUTHORIZATION'])) {
 list($_SERVER['PHP_AUTH_USER'], $_SERVER['PHP_AUTH_PW']) = explode(':' , base64_decode(substr($_SERVER['REDIRECT_HTTP_AUTHORIZATION'], 6)));
}

Am 31.12.2009 war es wieder soweit: Google hat seine Pageranks aktualisiert, wie man auf dieser Update-Seite sehen kann. Und es gibt erfreuliches zu berichten:

Mein kleiner Blog ist bereits auf PR 4 gestiegen! Whao! Danke an euch, an alle Leser, Feed-Abonenten und anderen Blogger, die mich verlinken!

Das ist wirklich nochmal ein riesen Schritt, Anfang November 2009 war es Pagerank 2. Aber ab jetzt wird es härter, den Pagerank zu steigern, wie man auch beim bekanntesten deutschen PHP-Blog phphatesme.com von Nils sehen kann, der auch an PR 5 knabbert.

Beim Suchbegriff „php blog“ lande ich nach wie vor auf Rang 45-53, das schwankt ab und zu. Da muss ich noch dran arbeiten.

Seit gestern läuft der 26. Chaos Computer Congress (26C3). Da ich gestern Besuch hatte, konnte ich leider dem Stream nicht folgen, aber wie man hörte war er sowieso mehr offline als online. Bisher gibt es auch nur unoffizielle Mitschnitte zum Download, aber trotzdem ist der Andrang relativ groß, sodass ich auch bei den inoffiziellen Torrents mitseeden werden, damit der Server endlich mal an seine Traffic-Grenze kommt.

Gestern Nacht konnte ich noch einige Minuten des Chaos Familien Duells mit ansehen, und dort kam PHP zwei Mal vor. Einmal bei der Frage „Nennen Sie eine Scriptsprache“ war es auf Platz 3 (hinter Perl und Python), und bei der Frage „Nennen Sie eine schreckliche Programmiersprache“ war es wohl auf Platz 2 hinter Java 😉 Leider konnte ich die Frage nicht sehen, da der Stream tot war, aber es ging durch Twitter.

Cloud, CDN? Schonmal gehört. Es soll toll sein, aber im Detail weiß ich nicht, was das ist.

Wenn so oder ähnlich deine ersten Gedanken waren, habe ich hier ein paar interessante Informationen, wie man das ganze mal praktisch ausprobieren kann.

Man mag Google lieben oder hassen, zum kostenlosen Test kann man es ja nutzen, und dann entscheiden, wie man weiter machen möchte. Aktuell ist nämlich Google der einzige Anbieter, der bei geringen Trafficvolumen kostenlos ist, andere Größen der IT-Landschaft mit einer Cloud wie z.B. Amazon EC2 bzw CloudFront, GoGoGrid, AppNexus und wie sie alle heißen kosten sofort Geld, wenn auch für Testzwecke nur wenige Euros.

Die Wolke, die Cloud, über die alle seit Monaten reden, ist wirklich ein konfuser Bereich im Internet, wo man nicht weiß, was genau dahinter steckt, man kann es wie eine Blackbox nutzen. Das sieht man auch bereits beim groben Vergleich von Googles App Engine und Amazons EC2 Services. Während man bei Amazon einen kompletten (virtualisierten) Linux Server mit Root-Rechten bekommt und dort machen kann was man möchte, bekommt man bei Google „nur“ Zugriff auf ein skalierbares System, wo man seine Python-Scripts und Webseiten installieren kann, und beschränkt ist auf Googles Datenbanksystem.

Wer den Titel genau gelesen hat weiß, dass wir keine komplette Webseite installieren möchten in der Cloud, sondern die Infrastruktur nutzen wollen als CDN. Ein Content-Delivery-Network (CDN) ist dazu da, Daten möglichst schnell zum Webseitenbesucher zu bringen, indem statische Dateien (zB Bilder, Javascripts, CSS-Dateien, Streams etc) von einem geografisch möglichst nahen Server zum Besucher gesendet werden. Da Clouds dafür bekannt sind, ausfallsicher auf einer großen Menge von Servern zu laufen, die häufig auch in vielen Rechenzentren rund um die Welt verteilt sind, eignen sie sich für unser Vorhaben.

Soviel zur Theorie, auf zur Praxis. Als erstes wollen wir uns die Google App Engine ansehen. Dazu besorgen wir uns einen Account auf https://appengine.google.com . Nach der Registrierung können wir unsere erste Applikation anlegen. Dazu müssen wir uns noch authentifizieren mit unserer Handy-Nummer. Wir erhalten dann eine SMS mit einem Verifizierungscode. Google sammelt Daten.

Danach geben wir noch einen Titel für die Anwendung an (wir bekommen damit automatisch eine Subdomain <application>.appspot.com

Im Dashboard können wir uns später viele Details unserer Applikation ansehen, sowie auch die Rechnungsseite (Billing) und bekommen die Kosten zu Gesicht. Wir sehen, dass es einen großzügigen kostenlosen Pool gibt, den wir nutzen können, und erst dann Kontoinformationen etc. angeben müssen, um mehr zu nutzen.

Wir haben also täglich 1GB Traffic in jede Richtung und können 2000 Mails versenden, sowie 6,5 CPU-Stunden nutzen. Das reicht für erste Tests und kleinere Projekte auf jeden Fall aus.

Unter „System Status“ sehen wir die zur Verfügung stehenden Dienste und Systeme:

Nun wollen wir unsere Bilder und statischen Dateien hochladen. Dazu gibt es einige Möglichkeiten, die man sich auf der Download-Seite anschauen kann. Ich habe mich für das Eclipse-Plugin entschieden. Nach der Installation haben wir die Möglichkeit, Dateien und Ordner in unsere Google Applikation hochzuladen:

Nach der Installation des Plugins und Neustart von Eclipse haben wir 3 neue Buttons in Eclipse. Nun können wir ganz einfach ein neues „Web Application Project“ erstellen:

Wir kopieren die Dateien in den Ordner „war“, in diesem Fall möchte ich den Ordner img734/ mit einigen Bildern hochladen. Dort können wir auch Unterordner erstellen.

Mit einem Klick auf „Run“ (Der grüne Play-Button) wird ein lokaler Miniwebserver gestartet, wo man dann die Applikation testen kann:

http://localhost:8888/img734/appengine_billing.png

Wenn alles OK ist, klicken wir auf „Deploy“ (die blaue Turbine von Goole). Nach der Eingabe von Email und Passwort wird das Project hochgeladen und die Bilder sind online verfügbar.

Beim ersten Mal muss man noch die „Application ID“ eingeben. Das ist der eindeutige Application Name, den wir angelegt haben.

Überprüfen können wir das, indem wir im Browser nun die folgende URL eingeben:

http://phpgangsta.appspot.com/img734/appengine_billing.png

Damit die Bilder nun automatisch eine hohe Expiration-Time bekommen (und wir so vom Browsercache profitieren können) öffnen wir die Datei /war/WEB_INF/appending-web.xml und fügen dort Informationen hinzu:

 ...
 <application>phpgangsta</application>
 <version>1</version>

 <!-- Static Files for CDN -->
 <static-files>
 <include path="/img734/*" expiration="365d" />
 <include path="/css/*" expiration="1d" />
 <include path="/js/*" expiration="1d" />
 </static-files>

 <!-- Configure java.util.logging -->
 ...

Klick auf Deploy, und schon werden die Bilder mit einem hohen Expiration-Date ausgeliefert. Als Test habe ich alle Bilder in diesem Blogartikel in die Google Cloud geladen und verlinkt. Und es funktioniert! 😉

Wir haben nun also eine kostenlose Subdomain, wo wir statische Dateien ablegen können, und die wir in unsere Webseite einbinden können. Wir haben dadurch mehrere Vorteile:

• Wir sparen Traffic und CPU-Zeit auf unserem Server
• Wir haben eine Cookie-freie Domain (warum das gut ist: Siehe Präsentation in diesem Artikel)
• Die Dateien werden automatisch gzip’t ausgeliefert falls möglich (bei css und js zB)
• Die Verbindung der Besucher zur Google Cloud ist besser als zu unserem Server (CDN)

Der Besucher wird also eine kürzere Ladezeit beobachten, und wir entlasten unsere Server.

Aber es gibt nur Licht, wenn es auch Schatten gibt. Wir als Entwickler haben unsere Handy-Nummer preisgegeben und sie mit dem Google-Account verknüpft. Außerdem werden die IP-Adressen unserer Besucher bei Google preisgegeben, was evtl. ein Problem sein kann oder werden kann. Sobald wir über das freie Kontigent kommen, müssen wir Geld bezahlen. Das ist aber häufig günstiger als einen eigenen Server zu kaufen/mieten, der die Last und den Traffic übernimmt.

Viel Spass beim Ausprobieren, und berichtet von euren Erfahrungen!

Da öffnet man nichtsahnend seine Post, und was findet man? Infopost von .co.de!

Ich betreibe laut denen eine der wichtigsten Seiten im deutschen Markt, und werde nun gefragt, ob ich bei denen die tolle Domain „phpgangsta.co.de“ in der  Sunrise-Phase registrieren möchte, für schlappe 99 Euro pro Jahr. Dass es sich dabei nur um eine einfache Subdomain handelt wird verschwiegen, es wird sogar mit der „vollwertigen“ Domain „co.uk“ verglichen.

Wer sich eine solche Domain kauft, müßte sich eigentlich sämliche Domains kaufen, die irgendwie den eigenen Domainnamen enthalten, also auch phpgangsta.de.de, phpgangsta.com.de, phpgangs.ta.de usw. usw.

Ich würde aber tippen, dass sicherlich einige Leute darauf reinfallen, und die Firma aus Osnabrück sich damit ein tolles Weihnachtsgeld verdient. Von mir gibts jedenfalls kein Geld.