Tja, nun ist es schon wieder mehr als eine Woche her als Hermes, der “Handybote” mein neues Spielzeug vorbei gebracht hat. Das neue Motorola Milestone.
Die Ankunftsvorfreude hatte ich schon fleißig über Twitter kommentiert. Und über Twitter kam von Achim auch der Wunsch zu einem kleinen Erfahrungsbericht. Und genau diesen findet ihr hier…

Die Ankunft

Zuerst hatte ich schon Angst. Angeblich sollte das Handy mit DHL (wie „Dauert Halt Länger”) versendet werden. Schon auf das Schlimmste gefasst, da die von o2 im Bestellstatus verlinkte Tracking Auskunft nicht funktionierte, klingelte am 05.12.2009 der Hermes Paketdienst und übergab mir das kleine Päckchen.
Noch vor dem Wocheneinkauf musste ich den Neuankömmling aus der Verpackung befreien. Die Verpackung mag dem einen oder anderen eher missfallen, aber mich spricht die etwas andere Art positiv an und das Handy lag fest und sicher in der Umhüllung.

Software

Zuerst zur mitgelieferten CD. Diese bringt nichts wirklich Aufregendes mit sich. Der Installer packt die Motorola Multimedia Link Software – irgendein Ungetüm von Nero – und die benötigten USB Treiber (für Laden und Geräteerkennung) auf die Platte. Bei Windows XP, welches meinen Arbeitslaptop antreibt, stürzt der „MotoConnect Service” regelmäßig nach dem Starten ab, läuft jedoch weiter, so dass das Milestone dennoch erkannt wird. Ansonsten hab ich den Sinn hinter der Multimedia Link Software noch nicht erkannt. Für Tipps bin ich da immer dankbar…
Auf dem Milestone werkelt es nun – das Android 2.0. Es macht einen echt netten Eindruck, auch ohne Erweiterungen wie HTC Sense.
Die Installation läuft problemlos ab – ein paar Grundinformationen und schon erscheint der Home Screen. Und was einen besonderen Eindruck hinterlässt: Ich werde nicht dazu gezwungen ein Google Konto zu hinterlegen. Es würde also auch ganz ohne Google funktionieren, wenn auch nicht unbedingt so komplett rund.
Die erste Amtshandlung auf dem frisch gestarteten Milestone war das Konfigurieren des heimischen WLANs. Das ging mehr als problemlos und fühlt sich auch flüssiger und schneller an als auf meinem alten Orbit.
Ok, dann ab in den berühmt-berüchtigten Android Marketplace. Das Suchen und Installieren von Tools funktioniert auch hier rund. Allerdings haben die Kritiker recht, wenn sie meinen dass die Qualität der Software noch etwas zu wünschen lässt. Ich habe bis jetzt zwar nur kostenfreie Tools ausprobiert, aber auch hier würde ich mir etwas mehr Qualitätsanspruch der Programmierer wünschen.
Hier eine kleine Auswahl der Apps, die momentan auf meinem Androiden werkeln:

• NetCounter (http://www.jaqpot.net/netcounter)
• Barcode Scanner (http://code.google.com/p/zxing)
• Twidroid (http://twidroid.com)
• Aloqa (http://www.aloqa.com)

NetCounter Screenshot

Das ist nur ein kleiner Auszug, der allerdings nicht ganz ohne Hintergedanken ausgewählte Apps enthält. Denn die Tools zeigen recht eindrucksvoll, was für Potenzial hinter der Android Plattform steckt bzw. das es durchaus schon ordentliche Tools für die Google-Plattform gibt. So ist NetCounter ein kleiner Dienst, der den Traffic auf den Schnittstellen für WLAN und GPRS/UMTS zählt. Gerade für O2 Nutzer wie mich, die nicht auf eine kleine Übersicht wie Vodafone QuickCheck zurückgreifen können, ein echt nützliches App.
Barcode Scanner ist fast nicht von einem Android Phone wegzudenken. Viele Apps sind im Netz mittels eines QR Codes verlinkt. Dieser Code kann einfach mit dieser App „fotografiert” werden und schon kommt die App auf das Android. Natürlich kann das auch für Kontakte, normale Webseiten-Links und vieles mehr genutzt werden.
Twidroid ist eine echt super funktionierende Twitter-Anbindung für das Google Handybetriebssystem. Wer es wünscht kann es auch rund um die Uhr laufen lassen und verpasst so nie einen Tweet. Die Entwicklung geht echt fix voran und bis jetzt ist das App noch nicht einmal abgestürzt.
Zu guter Letzt Aloqa. Das Tool fasziniert von Anfang an. Mit Hilfe des GPS und ggf. mit Unterstützung des GSM Netzes lokalisiert Aloqa den aktuellen Standort und bietet alles, was ein „Einheimischer” auch sofort würde – Geldautomaten, Gaststätten, Bars und was noch so alles interessant sein könnte. Einmal für einen Standort entschieden führt Aloqa auf Wunsch auch noch zum Ziel. Alles eine runde und echt performante Sache.

Die Hardware

Also hier gibt es momentan nichts zu meckern – außer das ich gern etwas längere Akkulaufzeiten hätte. Momentan schafft mein Milestone so 1 bis 1 ½ Tage, dann hätte es gern wieder Strom. Allerdings bin ich noch dabei herauszufinden, was denn da so Strom verbraucht. Eventuell ist es einfach nur ein kleines App was ständig läuft.
Damit wären wir bei dem wohl gravierendsten Unterschied zwischen Windows Mobile und dem Android: Programme müssen nicht explizit beendet werden. Wenn das App keinen „Aus-Schalter” bietet läuft es einfach so lange auf Sparflamme im Hintergrund bis der Speicher benötigt wird. Bei Windows Mobile kaum zu denken, da war jeder laufende Prozess ein negativer Hauptgewinn für die Performance und die Akkulaufzeit.
Noch ein kurzer Blick auf die Hardware-Tastatur. Ich war ja erst etwas skeptisch. Bei der Größe eine benutzbare Tastatur? Die Antwort muss lauten: Ja. Sogar mit meinen – sagen wir: größeren – Fingern konnte ich nach kurzer Eingewöhnungszeit zügig und fehlerfrei schreiben. Warum allerdings die gut lernende T9 Unterstützung bei der Hardware-Tastatur nicht angeboten wird, ist mir noch rätselhaft.
Das Fehlen der Umlaute irritiert zuerst, aber ein kurzes Festhalten der Tasten u, a, o und s bringt allerdings alle Facetten der Umlaute zu Tage.

Das Web und Emails

Hmm, irgendwie passen die Themen nirgends so richtig rein. Sie hängen sowohl von der Hardware als auch von der Software ab. Daher ziehe sie einfach etwas heraus.

Browser

Der mitgelieferte Browser, auf Basis des Open Source Projektes WebKit, macht einiges her. Schon allein die MultiTouch Fähigkeit bringt Benutzbarkeit mit sich. Allerdings fehlt mir ein Werbeblocker wie AdBlock Plus (ABP) für den Firefox oder AdThwart für den Chrome.
Leider kann der Browser auch nicht mit WML Seiten umgehen, was bei Mamut-Seiten wie die der RMV durchaus negativ auffällt. Hier würde ich mich über Tipps freuen. Der Opera Mini ist leider nicht benutzbar auf dem Milestone und sonst habe ich noch keine Alternative gefunden.

Worauf ich auch noch Hoffe ist die Integration der Google Bookmarks in den Browser. Dann habe ich sogar auf dem Handy die gleichen Bookmarks wie in dem gesamten Browser-Zoo auf meinen Rechner.

Email

Also in punkto Email bleiben fast keine Wünsche offen. Natürlich werden die Mails von Google Mail in ihrer Gänze unterstützt – soll heißen: Tags, Archivieren, Suchen… alles ist dabei.
IMAP und POP3 Konten kann der integrierte Mailclient ebenfalls – auch wenn diese von einem Server mit SSL / TLS Serverzertifikat kommen, das nicht mitgeliefert wird. Leider sind es zwei Apps, die hier für Mails zuständig sind. Aber wirklich stören tut es nicht. Wer kein Google Mail nutzen will, wird es nicht vermissen und wer doch darauf zurückgreift lässt einfach die Mails von beiden Clients abrufen und bekommt die Benachrichtigungen entsprechend.
Exchange Konten werden auch direkt unterstützt – sogar die Synchronisation der Kontakte und Termine ist problemlos möglich. Wer jedoch gern Firmen- und Privatkalender auf dem Handy zusammen angezeigt bekommen will muss auch hier auf zwei Apps zurückgreifen oder fasst die Termine bereits im Firmenkalender zusammen. Alles in Allem funktioniert die Anbindung sehr gut.

Warten aufs Update

Android 2.0 – liebevoll auch Eclair genannt – ist gerade frisch, da gibt es schon Update-Informationen. Verizon Wireless, der Exklusivanbieter des Milestone in den USA, wo Motorola es Droid nennt, verteilt bereits das Update auf 2.0.1. In Deutschland sind die Server noch offline. Das Update soll unter anderem eine bessere Akkulaufzeit bringen. Ich bin jedenfalls gespannt.
Aber auch Android 2.1 steht vor der Tür. Ob und wann es das für das Milestone geben wird weiß ich noch nicht, aber ich kann es kaum erwarten.

Fazit

So viel Text und kein Ende? Doch – der Artikel ist fast zu Ende. Ich möchte den vielen Text in eine kurze Aussage pressen: Das Milestone als erstes Android 2.0 Phone macht Lust auf mehr und hat sexy Macken.
Die Ausstattung scheint mittlerweile auch in Deutschland zu variieren – die ersten Meldungen werden laut, dass Vodafone und O2 teilweise Versionen verschicken, bei denen eine Multimedia Station dabei ist. Die gibt es leider noch nicht in Deutschland – auch wenn ich sie gern mein Eigen nennen würde. Dafür fehlen aber teilweise die SD Karten. Also es bleibt spannend, in welcher Version das Milestone in Deutschland endgültig Fuß fassen wird. Aber eines ist Gewiss: Das Handy ist jeden Cent wert und macht Lust auf mehr. Wer eine eiFön Alternative sucht, die trotz Hardware-Tastatur noch super in der Hand liegt und das aktuellste alternative Betriebssystem mitbringt, der ist mit dem Milestone direkt dabei. Und die problemlose Integration in eine bestehende Exchange Infrastruktur macht es sogar für Firmen interessant!
Bleibt mir nur noch zu sagen: Wer Tipps oder Anmerkungen hat ist herzlich eingeladen die Kommentarfunktion zu nutzen. Und für alle Leser bedeutet mein neues Spielzeug vor allem eines: eine neue Rubrik in meinem Blog.

Jeder kennt wohl SSH. Viele kennen auch sftp – das was primär bei scp und WinSCP im Hintergrund werkelt und für den sicheren Dateitransfer gedacht ist. Nun, diese Komponenten können wir auch als Remote-Filesystem nutzen. Aber wie kam ich nun gerade (wieder) auf dieses Filesystem?

Die Anforderung

Eigentlich ist es eine einfache Anforderung, die ich momentan auf Arbeit habe: Über das Netzwerk soll ein Image verfügbar gemacht werden. Das Image darf auf dem Client nicht gespeichert werden, weil schlichtweg der Speicherplatz nicht zur Verfügung steht. Nun, soweit ist das alles nichts besonderes, wenn ich einmal davon absehe, das NFS keine Option ist.
Die erste Idee war WebDAV via davfs2 zu nutzen, da momentan nur HTTPS Verbindungen zulässig sind. Aber das Protokoll ist leider nicht für größere Dateien gedacht und kopiert stets im Hintergrund die komplette Datei bei Zugriffen (also vom Server beim Lesen und vom Client beim Schreiben). Damit fiel diese Lösung leider heraus.
Als nächstes fiel mir ein altes Experiment mit fuse wieder ein. Damals hatte ich versucht SSH Zugriffe über das Filesystem zu realisieren. Das funktionierte damals schon super und warum sollte es diesmal nicht funktionieren.

SSHFS, die Lösung

Unter Debian ist natürlich alles wieder zügig installiert:

aptititude install sshfs

Ist die Installation erst einmal durchgelaufen kann es theoretisch schon los gehen. Damit wir aber eine etwas lesbarere fstab Syntax erhalten, bauen wir noch einen kleinen mount-Helper, wie wir ihn schon bei der ntfs-3g Installation kennengelernt haben:

ln -s /sbin/mount.fuse /sbin/mount.fuse.sshfs

Nun kann ein Mount-Point in der fstab deklariert werden:

<user>@<host>:<remote path> <mount point> fuse.sshfs user,allow_other,noauto 0 0

Sieht noch etwas kryptisch aus. Aber nehmen wir mal als Beispiel, das es einen Server source.example.com gibt, welchen wir gerade einrichten. Außerdem existiert der Server target.example.com, welcher als SSH Server genutzt werden soll. Auf dem Server target.example.com existiert der Nutzer example, welcher Zugriff auf das Verzeichnis /var/sshfs hat. Dieses Verzeichnis soll nun auf source.example.com über das Verzeichnis /media/ssh verfügbar gemacht werden. Daraus ergibt sich folgende fstab Zeile:

example@target.example.com:/var/sshfs /media/ssh fuse.sshfs user,allow_other,noauto 0 0

Wenn ein User nun

mount /media/ssh

eingibt, wird versucht auf den Server target.example.com zuzugreifen. Ist das erfolgreich, wird entweder versucht mit dem SSH Key des Users eine Authentifikation durchzuführen oder das Passwort für den Account example wird abgefragt. Grundsätzlich empfehle ich den Weg über den SSH Schlüssel.

SSH Keys

SSH nutzt asymmetrische Verschlüsselung, welche einen öffentlichen und einen privaten Schlüssel benötigt. Wie die Namen schon andeuten ist der private Schlüssel unter keinen Umständen weiter zu geben und soweit möglich immer mit einem Passwort zu versehen. Der öffentliche Schlüssel kann frei verfügbar sein. Dieser wird zum Beispiel vom Administrator des Zielsystems benötigt um Zugriff auf das System mittels der Schlüssel zu ermöglichen. Aber eins nach dem anderen.

SSH Key erzeugen

SSH Keys sind zügig erstellt. Am einfachsten führt der User, welcher die Keys nutzen möchte, ssh-keygen aus. Ein Beispiel könnte so aussehen:

ssh-keygen -b 2048 -C "My SSH Key"

Damit erzeugen wir einen Schlüssel mit einer Bitlänge von 2048 (-b) und fügen den Kommentar “My SSH Key” ein. Nach dem Start fragt ssh-keygen nach dem Namen der Datei – im Falle das der Key auch gleich für den aktuellen User genutzt werden soll kann hier einfach Enter gedrückt werden. Wird der Key für einen anderen Nutzer erstellt, ist die Wahl grundsätzlich erst einmal frei. Damit openssh später den Key findet muss der private Schlüssel als identity oder als id_rsa bzw. id_dsa im Verzeichnis .ssh des Home-Verzeichnisses verfügbar sein. Ob rsa oder dsa der richtige Suffix ist hängt vom Algorithmus ab, mit dem der Schlüssel erzeugt wurde. Wenn der Schlüssel mit dem Beispielbefehl generiert wird, wird der Standard – RSA – genutzt. Wer mehr zum Thema wissen möchte kann sich bei Wikipedia die Artikel zu RSA und DSA einmal ansehen.

Aber zurück zum Generieren der Schlüssel. Ist die Frage nach dem Dateinamen geklärt fragt ssh-keygen noch nach einer Passphrase. Es ist verlockend hier kein Passwort zu nutzen – ist der Key doch das eigentliche Passwort – aber dieser Versuchung sollte so gut wie nie nachgegeben werden. Denn jeder, der diesen Key einmal in die Hände bekommt hat auch Zugang zu sämtlichen Systemen die für diesen Key freigegeben sind. Wird keine Passphrase vergeben so sollte noch mehr auf den Schlüssel geachtet werden und die Zugriffsrechte sollten auf ein Minimum beschränkt werden.
Und wo ich gerade bei guten Ratschlägen bin: Es ist gut, das hier nach einer Passphrase und nicht (nur) nach einem Passwort gefragt wird. Es ist wirklich besser einen ganzen Satz oder gar eine Redewendung zu nutzen. Diese lassen sich meist besser merken und sind durch Brute-Force-Attacken nicht so einfach mit vertretbarem Aufwand herausfindbar.

Nachdem nun auch eine Passphrase eingegeben wurde wird der Schlüssel generiert. Nach dem Generieren existieren zwei Dateien (daher ist auch immer die Rede von den Schlüsseln). Beide haben den Dateiamen der während des Generierens konfiguriert wurde. Eine Datei hat zusätzlich den Anhang .pub. Das ist der öffentliche Schlüssel. Beide Dateien sollte vorsichtshalber an einem sicheren Ort als Kopie gelagert werden. Für Firmenschlüssel bietet es sich an, beide Dateien auf Papier zu bannen (es ist schliesslich “nur” ein ganz großer String pro Datei) und zusammen mit einem Datenträger, welcher die Dateien digital enthält, in einen Safe zu packen.

Die Schlüssel einspielen

Wie bereits kurz angemerkt, gehört der private Schlüssel per default in das Verzeichnis .ssh, welches unterhalb des jeweiligen Nutzerverzeichnisses liegt. Der Dateiname sollte identity oder id_rsa bzw. id_dsa lauten.Wenn wir annehmen, das auf dem Server source.example.com der Nutzer bob existiert und den Schlüssel nutzen soll, so sollte der oben generierte Key unter dem Pfad /home/bob/.ssh/id_rsa existieren.

Auf dem Server target.example.com wird der Inhalt der Datei mit dem Suffix .pub an die Datei authorized_keys angehangen. Angehangen ist dabei das wichtigste Wort. Die Datei authorized_keys enthält eine Menge an öffentlichen SSH Schlüsseln von Nutzern, die ebenfalls Zugang zu dem Nutzeraccount bekommen sollen. Sobald der Inhalt eines öffentlichen Schlüssel einfach nur nach authorized_keys kopiert wird, haben alle anderen Schlüssel keinen Zugang mehr!
Wenn der öffentliche Schlüssel als Datei id_rsa.pub auf target.example.com kopiert wurde, kann er einfach durch die Befehlszeile

cat id_rsa.pub >> /home/example/authorized_keys

an die Datei mit den erlaubten Schlüsseln angehangen werden. Natürlich kann auch der Inhalt der Datei als String kopiert werden und in die Datei authorized_keys kopiert werden.

SSH konfigurieren

Eigentlich sollte SSH bereits so konfiguriert sein, das es sowohl SSH Keys als auch Passwörter akzeptiert. Da SSH Schlüssel nicht einfach erraten werden können, lasse ich normalerweise nur Anmeldungen via SSH zu, aber das nur am Rande und als kleiner Tipp.
Die magische Konfigurationszeile, welche SSH Keys zulässt, in der Datei /etc/ssh/sshd_config lautet:

PubkeyAuthentication yes

Wenn das gesetzt ist, akzeptiert der Server SSH Authentifikation. Zum Testen genügt es, einfach eine SSH Verbindung aufzunehmen. Angenommen, wir sind als User bob auf source.example.com angemeldet und die SSH Keys sind an Ort und Stelle, dann sollte

ssh example@source.example.com

nach dem SSH Key Passwort fragen.

Der finale Test

Ok, jetzt sollte ja alles vorhanden sein. Also kann der User bob los legen:

mount /media/ssh

Wenn alles geklappt hat, sollte jetzt nach dem Passwort des SSH Keys gefragt werden. Wenn dieser richtig eingegeben wurde, sollte unter /media/ssh das zu finden sein, was auf dem Server target.example.com im Verzeichnis /var/sshfs zu finden ist.

Links

Wer jetzt Blut geleckt hat, kann auch einen Blick auf folgende Links werfen:

• OpenSSH – Die freie SSH Implementierung
• PuTTY – Für alle, die noch unter Windows arbeien müssen, aber einen SSH Client brauchen.
• fuse Dateisysteme – eine Liste mit anderen Dateisystemen, die auf fuse aufbauen

Während es bei Eclipse 3.5 wohl eine größere Baustelle ist, wie u.a. hier zu lesen ist, gibt es bei Netbeans eine unschöne, aber funktionierende Lösung.

Die Lösung ist simpel und effektiv: Das Plugin ist zwar momentan nicht über die Update-Funktion von Netbeans verfügbar, aber es existiert ein Draft auf der Projektseite. Hier kann einfach über “Documents & files” das benötigte nbm File heruntergeladen werden. In Netbeans wird das Modul dann über “Tools -> Plugins -> Downloaded -> Add Plugins…” problemlos installiert.

Viel Spass damit.

Es ist jetzt ein paar Wochen her, wo Björn Schotte mich bei Xing ansprach, ob ich nicht Interesse an einem Zend Framework Poster hätte.
Nun ja, da ich gute Erfahrungen mit dem Zend Framework gemacht habe – wobei auch der Artikel zur Authorisierung mit dem Zend Framework entstanden ist – und Mayflower, die Firma von Björn, ja quasi die Firma im PHP Umfeld nach Zend ist, war ich von der Idee begeistert und habe sofort geantwortet.

Heute hatte ich dann endlich das ersehnte Poster im Briefkasten und ich muss sagen, ich bin verdammt positiv beeindruckt. Das Poster zeigt auf einer beeindruckenden Größe alle wichtigen Komponenten und bringt sogar noch Code-Beispiele mit! Das macht direkt Lust auf das kommende Poster “PHP Web Security”, was Mayflower zusammen mit Stefan Esser erstellen will.

Da bleibt mir eigentlich nur noch eins: Danke Mayflower, das ist eine super Aktion!

Ich bin mal wieder verzweifelt. Unter Debian ist der richtige Lese- und Schreibzugriff auf NTFS Partitionen mittels ntfs-3g (bzw. jetzt ntfsmount) schnell installiert, wie mein letzter Artikel kurz zusammen fasst. Das reine Vorhandensein des Moduls ntfs-3g ist allerdings noch kein schlagendes Argument für Debian, dieses auch standardmäßig beim Einhängen von NTFS Partitionen zu nutzen.

Aber Linux wäre nicht Linux, wenn es dafür nicht auch einen einfachen Lösungsweg gäbe. Das Zauberwort heißt “external helper” und wird nur am Rande der mount manpage erwähnt. Das dahinter stehende Prinzip ist jedoch denkbar einfach. Wenn unter /sbin ein Programm mit dem Namensschema mount. existiert, wird dieses kurzerhand von mount genutzt.

Nun, mit dem Installieren von ntfs-3g wurde schon ein /sbin/mount.ntfs-3g angelegt. Allerdings gibt es ja den Partitionstyp ntfs-3g nicht womit dieser Helper nur genutzt wird, wenn beim Einhängen via -t ntfs-3g explizit der “Typ” auf ntfs-3g gesetzt wird. Wir brauchen aber etwas, was bei “ntfs” genutzt wird. Also erstellen wir doch einfach einen Symlink auf den schon bestehenden external helper:

ln -s /sbin/mount.ntfs-3g /sbin/mount.ntfs

Und siehe da, jetzt wird per default ntfs-3g genutzt!

mount /dev/sdc1 /media/stick

meldet zwar erfolgreichen Vollzug, aber wirklich schreiben kann ich darauf nicht! So wird zum Beispiel der Versuch ein touch auszuführen mit

$ touch /media/stick/test
touch: kann '/media/stick/test' nicht berühren: Das Dateisystem ist nur lesbar

quittiert.

Nun, eigentlich ist ja seit ntfs-3g keine Probleme bei NTFS mehr zu erwarten. Deswegen schaute ich zuerst, was denn mount so an Informationen heraus gibt. Laut mount war der Stick mit ‘rw’ eingehangen. Aber halt – irgendwie sieht die Zeile für den Stick anders aus, als ich es von meinem Ubuntu sonst kenne… Also schaute ich kurz ob es denn Programme mit ‘ntfs’ am Anfang gibt und siehe da, es gibt keine. Das ist äußerst seltsam.

Aber genug der vielen Worte. Das Problem liegt schlichtweg daran, das ntfs-3g nicht installiert ist. Das lässt sich unter Debian schnell mit

aptitude install ntfs-3g

erledigen. Leider nutzt mount dann immer noch das Kernel-Modul ntfs. Aber mit dem Paket ntfs-3g kommt auch das Tool ntfs-3g mit und das kann genau wie mount genutzt werden:

ntfs-3g /dev/sdc1 /media/stick

Und siehe da: es schreibt!

Vielleicht hilft das dem Einen oder Anderen beim Suchen ja weiter. Für mich dient der kleine Artikel hier auf jeden Fall als Gedächtnisstütze.

Viel Spass beim Lesen und Inspirieren lassen!

Unterschiede und Gemeinsamkeiten

Bevor der fleißige Webmaster jetzt zu einem Tool greift sollte er sich darüber im Klaren sein, wie die verschiedenen Helferlein funktionieren. Es gibt hier durchaus gravierende Unterschiede. Es beginnt bei der Überlegung ob die Statistik und vor allem die dafür benötigten Daten auf dem eigenen Server vorgehalten werden oder ob ein Tool zum Einsatz kommt, was als Dienst über das Web verfügbar ist.
Google Analytics ist ein Beispiel für die Haltung der Daten auf einem entfernten Server. Das das nicht ohne rechtliche Probleme einhergeht wird auf Website Boosting gut beschrieben.
Die Alternative zu einer rein externen Anwendung ist natürlich das Installieren von Tools wie awstats und piwik auf dem eigenen Server. Diese werten die Daten aber auch wieder verschieden aus. So werten webalizer und awstats die Logdateien des Servers aus, piwik setzt hingegen auf Javascript und das Einbinden von Bildern. Und damit gibt es auch bei diesen Programmen Unterschiede, nämlich die Art und Weise, wie und welche Daten gesammelt werden.
Beim Einbinden von Javascript und externen Bildern sind die Programme vom Client abhängig. Vorteil ist, das gerade bei der Javascript Lösungen sehr granular festgestellt werden kann, was der Nutzer so alles auf der eigenen Seite macht. So genannte Heat-Maps, wie sie unter anderem auf Webmaster Pro beschrieben werden, können dank Javascript genauso erstellt werden wie eine genauere Auswertung der Ausstattung des Nutzers darüber erstellt werden kann.
Nachteil von Javascript und dem Nachladen von Bilddateien ist jedoch, das der Client es aktiv unterbinden kann. Plugins wie AdBlock Pro für den Firefox, ohne das ich auch nicht mehr online gehe, unterbinden recht zuverlässig solche Trackingversuche.
Was der Client nicht unterbinden kann sind Logeinträge. Diese kann er zwar bis zu einem gewissen Grad beeinflussen, aber Zugriffszahlen bekommen wir darüber recht zuverlässig. Hier setzen Programme wie webalizer und awstats an. Sie analysieren zyklisch die Logdateien des Servers und werten die Daten grafisch aus. Während webalizer einige Zeit nicht weiterentwickelt wurde, scheint 2008 wieder etwas Schwung in die Entwicklung gekommen zu sein, wie die “Whats New” Seite vermuten lässt. Für meinen Geschmack ist webalizer trotz seiner guten Dienste mittlerweile eher historisch interessant. Aktueller, mehr gepflegt und auch optisch – wie gesagt, meiner Meinung nach – ansprechender kommt hier awstats daher. Worin sich die Tools unterscheiden, stellt das awstats Projekt recht übersichtlich auf einer eigenen Seite gegenüber.

Installation von awstats

Um nun endlich mal etwas praktischer zu werden, schauen wir uns doch einfach mal zusammen an, wie awstats installiert wird. Voraussetzung für das Ausführen von awstats ist das Vorhandensein von Perl in Version 5.00503 oder höher. Außerdem muss der Webserver natürlich das Ausführen von Perl unterstützen, beim Apache reicht hier das Modul mod_perl aus. Unter Debian ist die Installation mit

apt-get install libapache2-mod-perl2 perl

schon erledigt. Wer es gern noch etwas ausführlicher haben möchte, kann noch

apt-get install libnet-dns-perl libnet-ip-perl libgeo-ipfree-perl

ausführen. Damit werden eventuelle Hostnamen in IPs aufgelöst und das geographische Einordnen der Besucher ist ebenfalls möglich. Beides kann später aber in der eigentlichen awstats Konfiguration konfiguriert werden.
Werfen wir noch einen Blick auf die Apache-Konfiguration. Es gibt ja schon fast Glaubenskriege, wie und wo Logdateien des Häuptlings abgelegt werden sollen. Einige Administratoren wollen ein großes Logfile, wo sie alles an einem Ort haben. Andere Serverhüter wollen die Logs in der relativen Nähe des eigentlichen Document Root vom dazugehörigen virtuellen Host und eine strikte Trennung der Logdateien pro Domain bzw. virtuellem Host.
Ich liege bei dieser Diskussion dazwischen. Ich finde schon, das Logdateien in ein separates Verzeichnis weit außerhalb der Dokumentenwurzel gehören. Aber es muss nicht eine große Datei sein, die ich durchforsten müsste, um an Daten zu kommen. Daher favorisiere ich folgende Struktur: Alle Logfiles sind unter /var/log/apache2 zu finden. Hier gibt es weiterhin 2 grundsätzlich verschiedene Logfiletypen – Zugriffs- und Fehlerlog. Diese Typen gibt es jeweils einmal pro virtuellem Host. Für den namensbasierten vhost, der zum Beispiel für diese Seite zuständig ist, sieht die Konfiguration so aus:

<VirtualHost *:80>
  # .... was auch immer da noch so konfiguriert ist
  ServerName www.holger-librenz.de
  CustomLog /var/log/apache2/access-www.holger-librenz.de.log combined
  ErrorLog /var/log/apache2/error-www.holger-librenz.de.log
</VirtualHost>

Das “combined” gibt übrigens das Logformat an. Combined ist bei den Debianinstallationen meist schon definiert und loggt die wichtigsten Daten mit. Falls der Apache beim Testen der Konfigration mittels

apache2ctl -t

meckern sollte, das er combined nicht kennt, hier die Definition aus der apache2.conf:

LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined

Warum wir uns das Ganze anschauen? Nun, auf irgendeiner Grundlage muss awstats später die Statistiken ermitteln können. Mit den eben beschriebenen Schritten haben wir ein Access-Log definiert, welches uns schon einmal mehrere Informationen zur Verfügung stellt, mit denen awstats später arbeiten kann.

Nun aber wirklich zu awstats. Für die meisten Distributionen existieren bereits Pakete. Diese Installationsweise hat den Vorteil, das beim routinemäßigen Update des System awstats auch mit aktualisiert wird. Allerdings kommt man bei einigen Distributionen so nicht unbedingt an die aktuellste stabile Version. Gut, “Bleeding Edge” muss ja nicht immer sein. Aber neben sicherheitskritischen Bugfixes kommen meist auch kleine, aber feine Verbesserungen – sei es in Form von aktualisierten Clientidentifikatoren (also dem Auswerten des User Agents und der Schlussfolgerung auf den genutzen Browser / Dienst), einer verbesserten Geo-Lokalisierung oder oder oder. Daher habe ich mich entschlossen, awstats manuell zu installieren. Dank der Perl-Implementierung und der recht guten Dokumentation funktioniert das auch recht einfach. So genügt es folgende kleine Liste abzuarbeiten:

1. Download der aktuellsten Version von awstats
   Beispiel auf der Konsole wäre für die aktuelle Version 6.9:

   wget "http://prdownloads.sourceforge.net/awstats/awstats-6.9.tar.gz"

2. heruntergeladenes Archiv entpacken, zum Beispiel mit:

   tar xzf awstats-6.9.tar.gz

3. Das Verzeichnis wwwroot, welches unterhalb des entpackten Verzeichnisses zu finden ist, an eine “zentrale” Stelle kopieren. Bei mir landet die Installation meist dort, wo die virtuellen Hosts ihre “Wurzel” haben. Dafür muss ich folgenden Kopierbefehl, für die hier beispielhaft genannte Version 6.9, benutzen:

   cp -R awstats-6.9/wwwroot /var/www/awstats

   Danach sollte der Inhalt von wwwroot direkt unter /var/www/awstats zu finden sein.

4. Verzeichnis data innerhalb von /var/www/awstats erzeugen. Natürlich nur, wenn awstats gerade das erste Mal installiert wird. Der magische Befehl:

   mkdir /var/www/awstats/data

5. Zugriffsrechte so setzen, das der Webserver die Perlscripte lesen und ausführen kann.
6. Aus dem Verzeichnis, welches nach dem Entpacken entstanden ist, sollte das tools Verzeichnis noch kopiert werden. Dafür würde ich unter /opt ein Unterverzeichnis awstats erstellen und das tools-Verzeichnis dort hinein kopieren:

   mkdir /opt/awstats
   cp -R awstats-6.9/tools /opt/awstats

So, der größte Teil ist nun erledigt. Jetzt werden wir noch einige Aliase beim Apache konfigurieren, damit können wir später einfacher die Konfigurationsdateien pflegen. Dafür einfach folgende Zeilen der apache2.conf (unter Debian, manchmal heißt die Datei auch httpd.conf oder einfach nur apache.conf) hinzufügen:

    ## awstat aliases
    Alias /awstatsclasses "/var/www/awstats/classes/"
    Alias /awstatscss "/var/www/awstats/css/"
    Alias /awstatsicons "/var/www/awstats/icon/"
    ScriptAlias /awstats "/var/www/awstats/cgi-bin/"
 
    <Directory "/var/www/awstats">
        AddHandler cgi-script .pl
        Options ExecCGI -MultiViews +SymLinksIfOwnerMatch
        AllowOverride None
        Order allow,deny
        Allow from all
    </Directory>

Der zusätzliche <Directory> Eintrag kümmert sich dann noch darum, das die Perlscripte auch ausgeführt werden. Der Zugang wird hier übrigens absichtlich von mir generell erlaubt. Die eigentliche Beschränkung werden wir nämlich später pro Host definieren.
Sollte der Apache Konfigurationstest mittels

apache2ctl -t

die Aliase nicht kennen, muss das Apache-Modul mod_alias noch installiert und geladen werden.
Wenn der Konfigurationstest problemlos durchläuft, kann der Häuptling neu gestartet werden:

/etc/init.d/apache2 restart

Da ich bis jetzt immer mit Servern zu tun hatte, die mehrere unabhängige Domains hosteten, werde ich hier auch nur diesen Fall betrachten. Andere Konfigurationen sind aber recht einfach zu adaptieren.
Weiter oben, in der allgemeinen Apache-Konfiguration, habe ich den Zugriff für alle erlaubt (allow from all). Da Statistiken nicht unbedingt für jedes Auge gedacht sind und die Domains auch nicht unbedingt die gleichen Personen zu interessieren haben, werde ich in den virtuellen Hosts, die ich in separaten Files pflege, eine HTTP Authentifizierung definieren.
Zuerst wollen wir den virtuellen Host anpassen. Die awstats-spezifischen Anpassungen sehen da bei mir immer so aus:

  <Location /awstats>
    AuthType Basic
    AuthName "Statistik-Bereich"
    AuthUserFile /path/to/htpasswd/des/vhosts
 
    Require valid-user
  </Location>

Diese Anweisungen bewirken, das beim Aufruf von /awstats eine Basic Authentifizierung stattfindet. Der Pfad “/path/to/htpasswd/des/vhosts” muss jetzt noch angepasst werden. Hier sollte die htpasswd referenziert werden, die für diesen virtuellen Host genutzt werden soll. Bei mir sähe das zum Beispiel so aus: “/var/www/holger-librenz.de/www/.htpasswd”.
Diese htpasswd kann mit folgendem Befehl einfach erzeugt werden:

htpasswd -c /var/www/holger-librenz.de/www/.htpasswd hlibrenz

Der Befehl legt die neue htpasswd Datei an (das bewirkt das -c im Befehl) und erzeugt einen Nutzer mit dem Namen hlibrenz. Das dazu gehörende Passwort wird danach zweimal abgefragt. Existiert die htpasswd bereits, funktioniert der selbe Befehl ebenso, nur das -c sollten Sie dann weg lassen, denn sonst überschreibt das Programm die gesamte Datei. Htpasswd fügt bei erneuten Aufruf, ohne -c, den Nutzer hinzu oder ändert das Passwort des Nutzers, wenn der angegebene Nutzername bereits existiert.

So, nun muss awstats noch wissen für was es Statistiken erzeugen soll. Dazu werden bei awstats pro Domain, für die es arbeiten soll, eigene Konfigurationsdateien gepflegt. Diese werden in einem bestimmten Verzeichnis gesucht. Dieses ist im Normalfall /etc/awstats. Wenn das Verzeichnis noch nicht existiert, wäre jetzt ein guter Zeitpunkt es zu erstellen:

mkdir /etc/awstats

In dem Verzeichnis, welches aus dem heruntergeladenen Archiv entpackt wurde (im Beispiel hier immer awstats-6.9) , gibt es eine Vorlage für die Konfigurationsdatei. Die Datei heißt “awstats.model.conf” und sollte, der Übersichtlichkeit halber, in das eben angelegte Verzeichnis kopiert werden. Nun geht es ans eingemachte. Awstats verbindet die Domain mit der zu lesendenen Konfigurationsdatei mittels des Dateinamens. Dieser setzt sich wie folgt zusammen:

awstats.<domain>.conf

Der Domainname sollte dabei auch eventuelle Subdomains, also zum Beispiel www oder extranet, beinhalten. Für meine Domain ist folgender Dateiname notwendig:

awstats.www.holger-librenz.de.conf

Bleiben wir doch einfach bei dem Beispiel. Erstellen wir für meine Seite die Konfigurationsdatei aus dem Modell, was uns awstats mitgeliefert hat. Führen dazu im Verzeichnis /etc/awstats folgenden Befehl aus:

cp awstats.model.conf awstats.www.holger-librenz.de.conf

Dann können wir die Datei bearbeiten. Der erste Wert, den ich für mich anpassen muss, ist der Pfad zur Logdatei des Apache. Dazu muss der Wert LogFile berichtigt werden. Für meine Domain und die dahinter liegende Verzeichnisstruktur ergibt sich folgender Wert:

LogFile="/var/log/apache2/access-www.holger-librenz.de.log"

Die Werte für LogType, LogFormat und LogSeparater können, wenn das “combined” Log genutzt wird, einfach so belassen werden. Der nächste Wert, den wir ändern, definiert den Seitennamen. Dafür muss der Wert SiteDomain gesetzt werden. Dieser sollte die Hauptdomain beinhalten. Für mich wäre das also wie folgt:

SiteDomain="www.holger-librenz.de"

Da aber viele Seiten auch Aliasnamen besitzen, kann das natürlich auch awstats mitgeteilt werden. Dafür kann der Wert HostAliases gesetzt werden. Dieser enthält, getrennt durch ein Leerzeichen, die Aliasnamen und kann auch reguläre Ausdrücke beinhalten. Für meine Domain gibt es momentan “nur” die Kombination mit und ohne www. Da es aber ggf. auch andere Subdomains geben kann, setze ich einen regulären Ausdruck der das beschreibt:

HostAliases="REGEX[holger-librenz\.de$]"

Soweit zu den Domain-spezifischen Angaben. Jetzt kommen wir zu den Angaben, die awstats zum Arbeiten benötigt. Diese können aber auch der allgemeinen Performance zuträglich sein. Das zeigt auch der erste Wert. Der Wert DNSLookup legt fest, ob zu den IP Adressen, von welchen die Seite aufgerufen wurde, die Hostnamen ermittelt werden sollen. Das kann entweder ganz deaktiviert, nur aus dem lokalen DNS Cache oder immer geschehen. Schön ist natürlich, wenn wir die Hostnamen angezeigt bekommen. Wenn die eigene Seite allerdings ordentlich frequentiert ist, kann das sehr schnell zu ordentlich spürbaren DNS Abfragen führen. Bis es soweit ist, können wir das komplette Auflösen aktivieren. Ich freue mich aber schon auf den Tag, wo ich den Wert anpassen muss.

DNSLookup=1

So, jetzt kommen wir zu einigen organisatorischen Werten. Damit awstats weiß, wo es Dateien findet und wo es andere evtl. ablegen soll, wird in der Konfiguration festgehalten, was im Filesystem so für awstats bereit gehalten wird.
Zu allererst legen wir den Ort fest, wo awstats die Datenbanken mit den ermittelten Zugriffszahlen ablegt und findet. Das wird über die Option DirData erledigt. Die Angaben können entweder absolut, also von der Wurzel des Dateisystems aus, oder relativ zur awstats.pl Datei geschehen. Ich habe mich für die relative Angabe entschieden:

DirData="../data"

Diese Einstellung beschreibt nun das data-Verzeichnis, welches wir weiter oben angelegt haben.
Die noch folgenden Werte passen wir einfach mal so an:

DirCgi="/awstats"
DirIcons="/awstatsicons"

Hier wird definiert, das die weiter oben definierten Aliase genutzt werden sollen.

Jetzt ist es auch gleich geschafft. Zwei Werte sind noch Pflicht, nämlich das Setzen der Rechte auf das Aktualisieren der Datenbank über das Web und den Zugriff auf die Jahresstatistik via Kommandozeile und via Web.
Das erste Recht, also ob die Datenbank über das Web aktualisiert werden darf, unterdrücken wir mit folgendem Wert:

AllowToUpdateStatsFromBrowser=0

Damit kann uns der Nutzer nicht den Tag vermiesen, in dem er bei stark frequentierten Seiten immer wieder auf “Neu generieren” klickt und damit den Server beschäftigt. Das Aktualisieren werden wir völlig automatisiert über Cronjobs erledigen. Wenn Sie allerdings keine Cronjobs zur Verfügung haben, sollten Sie den Wert auf 1 setzen oder einmal einen Blick auf cron-job.org werfen.
Das zweite Recht, nämlich das Auswerten für ein gesamtes Kalenderjahr, können wir mit folgendem Wert sowohl für die Kommandozeile (CLI) als auch für das Web (CGI) erlauben:

AllowFullYearView=3

Es gibt noch einige weitere Einstellungsmöglichkeiten. Diese sind aber auch in der gut kommentierten Konfigurationsdatei als “optional” gekennzeichnet. Einzig eine Option möchte ich noch kurz vorstellen. Und zwar soll das Aufrufen der Statistiken nur für angemeldete Nutzer möglich sein. Den Status “angemeldet” hat ein Nutzer, der erfolgreich eine HTTP Authentifizierung hinter sich gebracht hat. Um awstats dazu zu bringen, das es nur berechtigten Usern seine Wahrheiten offenbart, setzen wir einfach AllowAccessFromWebToAuthenticatedUsersOnly auf 1:

AllowAccessFromWebToAuthenticatedUsersOnly=1

So. Nun ist auch awstats konfiguriert. Natürlich gibt es da noch verschiedene weitere Schräubchen, die das Verhalten verändern / verbessern, aber für die ersten Aufrufe sind wir nun gewappnet. Ob auch wirklich alles geklappt hat werden wir jetzt sehen. Wir rufen jetzt nämlich das erste Mal awstats auf:

/opt/awstats/tools/awstats_updateall.pl now -awstatsprog=/var/www/awstats/cgi-bin/awstats.pl

Sollten Probleme in der Konfiguration oder bei den Dateirechten bestehen, sollte das in den Ausgaben zu sehen sein.

Ok, wäre das auch erledigt. Jetzt legen wir noch einen Cronjob an. Dafür habe ich eine kleines Shellscript geschrieben:

#!/bin/sh
CUR_DIR=`pwd`
 
cd /var/www/awstats/cgi-bin
 
/opt/awstats/tools/awstats_updateall.pl now -awstatsprog=/var/www/awstats/cgi-bin/awstats.pl > /dev/null
 
cd $CUR_DIR

Das Skript habe ich in /opt/awstats/cron/update-all.sh gespeichert. Das Unterverzeichnis cron muss natürlich vorher angelegt und das Skript ausführbar gemacht werden.
Dieses Skript rufe ich dann über den Cron 2 mal in der Stunde auf und zwar immer zur vollen und zur halben Stunde. Dafür steht in der neuen Dateien /etc/cron.d/awstats:

##
## updates all awstats statitistics
##
0,30 * * * * root /opt/awstats/cron/update-all.sh

Ok. Jetzt kann es los gehen. Rufen Sie Ihre awstats Installation mal über den Webbrowser auf. Zu finden ist es unter http://<ihre.konfigurierte.domain>/awstats/awstats.pl.

Gehts nicht noch schöner?

Im Gegensatz zu webalizer ist die awstats Oberfläche schon sehr ansehnlich und übersichtlich geworden. Wer es aber noch einen Tick “schicker” will, sollte sich das noch rechte junge Projekt jawstats ansehen. Das Projekt nutzt PHP, Javascript und Flash um die statistischen Werte von awstats zu visualisieren und als kleines Schmankerl ist die Oberfläche von jawstats über Templates anpassbar.

Wo Licht ist, fällt aber auch bekanntlich Schatten. So möchte ich nicht unerwähnt lassen, dass das Projekt noch in der frühen Entwicklungsphase steckt. Die Konfiguration ist leider noch nicht wirklich “massentauglich” und die eine oder andere Einstellung und Programmierung sollte noch angepasst werden. Aber ich bin mir sicher, das bei reger Beteiligung und Rückmeldung von Nutzern jawstats einen festen Platz finden wird.

Installieren lässt es sich wirklich, wie auf der Webseite auch angepriesen, simpel. Sie brauchen lediglich einen Webserver und PHP. Sind die Voraussetzungen erfüllt, können Sie das Paket herunterladen. Entpacken Sie den Inhalt in ein Verzeichnis, was für den Webserver erreichbar ist:

tar czf jawstats-<version>.tar.gz -C <Zielverzeichnis>

Dann kopieren Sie die Datei config.dist.php und benennen die neue Datei config.php:

cp config.dist.php config.php

Ist auch diese Aufgabe gemeistert, geht es ans Editieren der eben erstellten Konfigurationsdatei. Wir die Dateiendung bereits vermuten lässt, handelt es sich bei der Datei um ein PHP Skript. Um zum Beispiel die Daten für holger-librenz.de ein wenig aufzuwerten, muss der Inhalt wie folgt aussehen:

<?php

  // core config parameters
  $sDefaultLanguage      = "de-DE";
  $sConfigDefaultView    = "thismonth.all";
  $bConfigChangeSites    = true;
  $bConfigUpdateSites    = true;
  $sUpdateSiteFilename   = "xml_update.php";

  // individual site configuration
  $aConfig["holger-librenz.de"] = array(
    "statspath"   => "/var/www/awstats/data/",
    "updatepath"  => "/var/www/awstats/cgi-bin/awstats.pl",
    "siteurl"     => "http://www.holger-librenz.de",
    "sitename"    => "",
    "theme"       => "default",
    "fadespeed"   => 250,
    "password"    => "very secret password",
    "includes"    => "",
    "language"    => "de-DE"
  );

Die ersten Variablen (unter “core config parameters”) geben Standardwerte an. Hier lege ich fest, das ich gern Deutsch als Standardsprache, die Monatsübersicht bei Start sehen möchte und das ein Aktualisieren und evtl. Seitenwechseln möglich ist.

Danach folgt die eigentliche Konfiguration der Seite. Der Array-Feldschlüssel “holger-librenz.de” (Zeile 11) wird für die Anzeige genutzt. Die enthaltenen Werte im Array bedeuten folgendes:

statspath

Der absolute Pfad zu den Daten.

updatepath

Der absolute Pfad zur awstats.pl Datei

siteurl

Das ist die Domain, die als Hauptdomain bei awstats in der Konfiguration genutzt wurde und wonach auch die awstats-Konfigurationsdatei benannt wurde.

sitename

Ein beschreibender Titel für die URL

theme

Hier kann der gewünschte Theme, also das Aussehen, bestimmt werden. Mit ausgeliefert wird der “default” Theme.

fadespeed

Beeinflusst die Geschwindigkeit, in der Grafiken (visuell) in neue Zustände versetzt werden.

password

Passwort, welches für das Aktualisieren der Werte auf Knopfdruck benötigt wird.

includes

Diese Option bietet die Möglichkeit, zusätzliche PHP Dateien einzubinden. Die Dateien werden als kommaseparierte Liste ohne Freizeichen erwartet.

language

Die Sprache, die standardmäßig für die Auswertung dieser Domain genutzt werden soll.

Leider existiert noch keine ausführliche Dokumentation, aber zumindest die Webseite verspricht hier Nachbesserung. Mit den wenigen Schritten, die Sie bis jetzt befolgt haben, können Sie aber schon einmal einen ersten Eindruck erhalten.

Jetzt erhalten wir Antworten auf die oben genannten Fragen. Wie Sie die einzelnen Werte richtig lesen und was es noch an Möglichkeiten gibt awstats zu nutzen erfahren Sie in der Dokumentation des Projektes.

Der phpmailer ist objektorientiert entwickelt und es existieren verschiedene Methoden zum Setzen von Headern. So gibt es u.a. die Methoden phpmailer::HeaderLine() und phpmailer::CustomHeader(). Beide wollten aber nicht den Return-Path setzen. Also habe ich etwas weiter Google geknechtet. Dort gibt es genügend Informationen, wie ich mit PHP und der mail() Funktion den Header setzen können soll. Aber das brachte mir nichts. Also habe ich weiter gesucht. Und siehe da, ich kann mit den genannten Methoden durchaus Header setzen, aber der Return-Path wird vom phpmailer immer wieder überschrieben. Und zwar überschreibt der phpmailer den Header mit dem eigentlichen Absender. Es ist jedoch trotz allem möglich, den Header zu setzen. Die magische Zeile Code muss allerdings wie folgt aussehen:

/*
  vorher muss natuerlich phpmailer instanziiert werden,
  bei mir ist die Referenz in $oMail gespeichert
*/
$oMail->Sender = "mein@return-pa.th";

Sobald die Eigenschaft gesetzt ist, funktioniert die Sache mit dem Return-Path reibungslos. Manchmal können Dinge so einfach sein….

Was mir jetzt wirklich passiert ist? Nun, die genaue Syntax war mir mal wieder entfallen. Ich wußte, das ich einen Nutzer “wewiki” anlegen will und das dieser Datenbanknutzer auf alle Datenbanken mit dem Präfix “wewiki_” Zugriff haben und diese auch erstellen können soll. Natürlich soll “wewiki” auch auf alle enthaltenen Tabellen zugreifen können. Ein Verbinden soll aber nur vom lokalen Rechner erfolgen können.
Würde es sich um eine Datenbank handeln wäre das GRANT Statement schnell zur Hand:

GRANT ALL ON wewiki_wiki.* TO wewiki@localhost IDENTIFIED BY 'very secret password';

Dann hätte der Nutzer “wewiki” jedoch nur Rechte auf die Datenbank “wewiki_wiki”. Da ich nun zu den fauleren Administratoren gehöre, wenn es um Datenbanknutzer geht, ist mir der daraus resultierende Aufwand, für jede neue Datenbank dem Nutzer dediziert Rechte zu geben, irgendwie zu hoch. Den Platzhalter % kann man aber nicht einfach so notieren. Und genau das ist mir wieder entfallen. Wie, verdammt noch mal, war denn die Syntax?! Nun, für jeden, der sich diese Frage auch stellt, hier die Antwort:

GRANT ALL ON `wewiki_%`.* TO wewiki@localhost IDENTIFIED BY 'a much more secret password';

Die Backticks (`) sind das kleine Details, was mein Administratorherz höher schlagen lässt. Denn nach diesem SQL Befehl hat der Nutzer “wewiki” Rechte auf alle Datenbanken, die mit “wewiki_” beginnen – also genau das, was ich haben wollte.