PHPGangsta - Der praktische PHP Blog

PHP Blog von PHPGangsta


Archive for Dezember, 2009

26C3 und PHP

without comments

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.

Written by Michael Kliewe

Dezember 28th, 2009 at 11:20 am

Posted in Allgemein

Tagged with , ,

Google’s Cloud kostenlos als CDN nutzen

with 6 comments

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.

appengine_sms

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.

appengine_billing

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:

appengine_status

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:

appengine_eclipse_plugin

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:

appengine_eclipse_newproject

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.

appengine_eclipse_add_files

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.

appengine_eclipse_deploy

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!

Written by Michael Kliewe

Dezember 24th, 2009 at 4:08 pm

eMail-Postfächer synchronisieren mit imapsync

with 5 comments

Einer der wenigen Artikel, die sich nicht um PHP drehen, aber trotzdem sehr interessant sind 😉

So häufig braucht es der Normalanwender nicht, aber wenn man mal seinen Email-Provider wechselt oder eine Kopie aller seiner Mails auf einem anderen Server haben möchte, gibt es nichts einfacheres als das imapsync-Script von Gilles Lamiral.

imapsync ist ein Perl-Script, das unter Linux, Windows und Mac läuft und die Emails zweier IMAP-Konten abgleichen kann. Dabei kopiert es nicht nur die Emails selbst, sondern auch deren Flags und das Interne Datum der Mails. Jede Nachricht wird auch nur einmal kopiert, sodass möglichst wenig Datentransfer stattfindet. Es ist also sowohl für Backupzwecke als auch Migrationszwecke von großem Nutzen, denn es unterstützt eine Vielzahl von verschiedenen IMAP-Servern.

Wenn ich hier alle Optionen aufzählen würde, die das Script unterstützt, würde der Artikel sehr lang werden. Das lassen wir also schön bleiben, nur ein paar Stichworte seien verraten: Es unterstützt SSL, Ordner können übersprungen werden, man kann Quellordner auf andere Zielordner mappen, Mails können nach der Synchronisierung gelöscht werden (dann ist es eher ein Verschieben von Mails statt einer Synchronisierung), Mails die größer als ein Limit sind können übersprungen werden, nur Mails der letzten X Tage können synchronisiert werden usw usw.

Genug Informationen, um es mal auszuprobieren? Dann los:

sudo apt-get install imapsync

Schon ist es installiert und wir können anfangen zu synchronisieren. Erstmal machen wir einen Trockendurchlauf (–dry), es wird also nur simuliert:

imapsync --dry --host1 10.0.0.2 --user1 "mkliewe@mail.de" --password1 "Passwort1" --host2 10.0.0.3 --user2 "backup@mail.de" --password2 "Passwort2"

Die Ausgabe sieht dann beispielsweise so aus:

$RCSfile: imapsync,v $ $Revision: 1.286 $ $Date: 2009/07/24 15:53:04 $
Here is a [linux] system (Linux xxxxx01 2.6.31-14-server #48-Ubuntu SMP Fri Oct 16 15:07:34 UTC 2009 x86_64)
with perl 5.10.0
Mail::IMAPClient  3.21
IO::Socket        1.30_01
IO::Socket::SSL
Digest::MD5       2.36_01
Digest::HMAC_MD5
Term::ReadKey
Date::Manip
 and the module Mail::IMAPClient version used here is 3.21
Command line used:
/usr/bin/imapsync --dry --host1 10.0.0.2 --user1 mkliewe@mail.de --password1 MASKED --host2 10.0.0.3 --user2 backup@mail.de --password2 MASKED
Turned ON syncinternaldates, will set the internal dates (arrival dates) on host2 same as host1.
TimeZone:[europe/berlin]
Will try to use CRAM-MD5 authentication on host1
Will try to use CRAM-MD5 authentication on host2
From imap server [10.0.0.2] port [143] user [mkliewe@mail.de]
To   imap server [10.0.0.3] port [143] user [backup@mail.de]
Banner: * OK mail.de Dovecot ready.
Host 10.0.0.2 says it has CAPABILITY for AUTHENTICATE CRAM-MD5
Success login on [10.0.0.2] with user [mkliewe@mail.de] auth [CRAM-MD5]
Banner: * OK mail.de Dovecot ready.
Host 10.0.0.3 says it has CAPABILITY for AUTHENTICATE CRAM-MD5
Success login on [10.0.0.3] with user [backup@mail.de] auth [CRAM-MD5]
host1: state Authenticated
host2: state Authenticated
From separator and prefix: [.][]
To   separator and prefix: [.][]
++++ Calculating sizes ++++
From Folder [INBOX]                             Size:     37258 Messages:     3
From Folder [Test2]                             Size:         0 Messages:     0
From Folder [Trash]                             Size:         0 Messages:     0
Total size: 37258
Total messages: 3
Time: 0 s
++++ Calculating sizes ++++
To   Folder [INBOX]                             Size:         0 Messages:     0
To   Folder [Test2]                            does not exist yet
To   Folder [Trash]                            does not exist yet
Total size: 0
Total messages: 0
Time: 0 s
++++ Listing folders ++++
From folders list: [INBOX] [Test2] [Trash]
To   folders list: [INBOX]
++++ Looping on each folder ++++
From Folder [INBOX]
To   Folder [INBOX]
++++ From [INBOX] Parse 1 ++++
++++ To   [INBOX] Parse 1 ++++
++++ Verifying [INBOX] -> [INBOX] ++++
+ NO msg #1 [jM2q9dB8TAvtUZDi0mNMyQ:30262] in INBOX
+ Copying msg #1:30262 to folder INBOX
flags from: [$notjunk]["21-Dec-2009 15:15:25 +0100"]
+ NO msg #2 [0RLbKdGjywBv4mLEANRUtg:5553] in INBOX
+ Copying msg #2:5553 to folder INBOX
flags from: [$notjunk]["21-Dec-2009 17:19:02 +0100"]
+ NO msg #3 [ctDrRzmFgf4W2lUbu/KlBQ:1443] in INBOX
+ Copying msg #3:1443 to folder INBOX
flags from: [$notjunk]["19-Dec-2009 19:34:30 +0100"]
Time: 1 s
From Folder [Test2]
To   Folder [Test2]
To   Folder Test2 does not exist
Creating folder [Test2]
From Folder [Trash]
To   Folder [Trash]
To   Folder Trash does not exist
Creating folder [Trash]
++++ End looping on each folder ++++
++++ Statistics ++++
Time                   : 1 sec
Messages transferred   : 0 (could be 3 without dry mode)
Messages skipped       : 0
Total bytes transferred: 0
Total bytes skipped    : 0
Total bytes error      : 0
Detected 0 errors

In diesem Fall gibt es also 3 Ordner auf dem Quellserver. Die Ordner „Trash“ und „Test2“ gibt es auf dem Zielserver noch nicht, sie würden also angelegt. Es existieren auch 3 Emails in der INBOX, die synchronisiert werden.

Wenn man den selben Befehl nochmal ohne –dry ausführt, dann wird wirklich synchroniert von host1 nach host2.

Um dann die Synchronisation stündlich zu wiederholen eignet sich ein Cronjob:

sudo crontab -u root -e

mit dem Inhalt

0 * * * 1-5 /usr/local/bin/myimapsync.sh

wobei in der myimapsync.sh natürlich der Befehl stehen sollte, beispielsweise:

#!/bin/bash

imapsync --dry --host1 imap.domain.de --user1 "user@domain.de" --password1 "Passwort1" --host2 10.0.0.3 --user2 "backup@domain.de" --password2 "Passwort2" >> /var/log/myimapsync.log

Hier für Administratoren noch ein kleines hilfreichen Script, welches mehrere Konten synchronisiert:

#!/bin/bash

inputfile="/etc/imapsyncbatch.conf"
host1="imap.domain.de"
host2="10.0.0.3"
logfile="/var/log/imapsyncbatch.log"

if [ ! -f $inputfile ]
then
{
	echo "The input file does not exist! Exiting..." >> $logfile
	exit;
}
fi

date=`date +%X_-_%x`
echo "$date IMAPSync started..." >> $logfile

tr "," " " <$inputfile | while read u1 p1 u2 p2
do
	date=`date +%X_-_%x`
	echo "$date Start Syncing User $u1 to $u2" >> $logfile
	imapsync $1 --buffersize 8192000 --nosyncacls --syncinternaldates \
		--host1 $host1 --user1 "$u1" --password1 "$p1" --ssl1 --port1 993 \
		--host2 $host2 --user2 "$u2" --password2 "$p2" --ssl2 --port2 993 \
		--noauthmd5
	date=`date +%X_-_%x`
	echo "$date Finished $u1 to $u2" >> $logfile
done

date=`date +%X_-_%x`
echo "$date IMAPSync Finished..." >> $logfile
echo "$date ------------------------------------" >> $logfile

wobei in der /etc/imapsyncbatch.conf die Zugangsdaten stehen:

user1@domain.de,Passwort1,user2@domain.de,Passwort2
bernd@domain.de,PasswortBernd,backup@domain.de,PasswortBernd

Falls mehrere Personen Zugriff auf diesen Rechner haben, sollte diese Datei gut geschützt werden (beispielsweise mit „sudo chmod 700 /etc/imapsyncbatch.conf“). Da das Script selbst keinen Root-Zugriff auf den Rechner braucht, kann man es auch mit einem normalen Benutzeraccount starten, dann muß allerdings der Lesezugriff auf die /etc/imapsyncbatch.conf und der Schreibzugriff auf /var/log/imapsyncbatch.log gewährleistet sein.

Written by Michael Kliewe

Dezember 21st, 2009 at 7:15 pm

co.de Domain

with 6 comments

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.

Written by Michael Kliewe

Dezember 19th, 2009 at 12:34 pm

Posted in Allgemein

Tagged with ,

Vergleich der großen PHP-Frameworks: Anzahl Jobs

with 9 comments

Wollte nur kurz einen Link in den Raum werfen, den man vielleicht mal länger beobachten kann, um zu sehen wie es mit den PHP Frameworks steht:


zend framework, cakephp, symfony, codeigniter Job Trends graph

zend framework, cakephp, symfony, codeigniter Job Trends zend framework jobscakephp jobssymfony jobscodeigniter jobs

Das wars auch schon 😉

Written by Michael Kliewe

Dezember 16th, 2009 at 9:43 am