blog.t8d.de

Amazon bietet standardmäßig eine einfache Übersicht des angefallenen S3-Traffics über das eigene Webinterface an. Um genauer zu überprüfen wo die Daten hingehen, besteht die Möglichkeit erweiterte Logfiles anzufordern. Dies geschieht über den Amazon Simple Storage Service, sprich die S3-API. Die Logfiles werden dabei wiederum in einem Bucket auf S3 gespeichert und beinhalten, wie man es von apache-üblichen Logfiles kennt, die zugreifende IP, Zeit, etc. . S3 bietet seit einiger Zeit die Möglichkeit Buckets in Europa zu hosten. Leider haben es die Infos dazu bzw. zu den Unterschieden zu den US gehosteten Buckets bisher nicht in die Dokumentation geschafft.
Im folgenden beschreibe ich wie man das erweiterte Logging für ein Bucket, das in Europa gehostet ist aktiviert.

Zunächst benötigt man das perl-Script s3curl.pl, welches im Amazon Developer Portal heruntergeladen werden kann.
Dabei ist gleich der erste Fallstrick eingebaut. Die Authentifizierung benutzt den String des englischen Datums, also z.B. “Tue, 26 May 2009 14:47:42 GMT”. Möchte man s3curl auf einer deutschen Installation nutzen wird dies nicht funktionieren, da das Datum vom Skript als “Die, 26 Mai…” errechnet wird und folglich der Zugang verweigert wird. Schnelle Abhilfe bringt die Anpassung der entsprechenden Zeile im Skript von

my $httpDate = POSIX::strftime("%a, %d %b %Y %H:%M:%S +0000", gmtime );

zu

my $httpDate = POSIX::strftime("Tue, 26 May "."%Y %H:%M:%S"." GMT", gmtime);

Dies ist ein schneller Hotfix und hilft für einen Tag. Sinnvoller wäre ein Vergleich des UNIX-Timestamps im s3-curl Script, das hoffentlich bald diesbezüglich angepasst wird.

Nun fehlen noch 4 Schritte um das erweiterte Logging zu aktivieren:

1. Um nicht jedesmal seine Credentials angeben zu müssen, kann man die Login-Informationen in einer Datei namens .s3curl (im Verzeichnis in dem s3curl liegt) ablegen und ihnen dabei einen Alias-Namen geben. Näheres dazu steht in der README-Anleitung zum Script. Im folgenden werden die Credentials referenziert mit “company”.

2. Wir möchten ein EU based bucket überwachen, also muss das Bucket für die logfiles auch in Europa liegen. “logbucketname” im folgenden bitte ersetzen durch das Bucket, das die Logfiles halten soll.

./s3curl.pl --id company --createBucket=EU -- http://s3.amazonaws.com/logbucketname

3. Das Bucket benötigt erweiterte Rechte um Logfiles empfangen zu dürfen. Dafür  muss die Accescontrollist modifiziert werden

3.1 Accescontrollist holen. Bitte beachten, dass dies abweicht von der Amazon Dokumentation, die nur die spezifische URL für US Buckets angibt.

./s3curl.pl --id company -- -s -v 'http://logbucketname.s3.amazonaws.com?acl' > logbucketname.acl

3.2 Die geholte Datei logbucketname.acl ergänzen zu:

<grant>
  <grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="Group">
    <uri>http://acs.amazonaws.com/groups/s3/LogDelivery</uri>
  </grantee>
  <permission>WRITE</permission>
</grant>
<grant>
  <grantee xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="Group">
    <uri>http://acs.amazonaws.com/groups/s3/LogDelivery</uri>
  </grantee>
  <permission>READ_ACP</permission>
</grant>

3.3 Zurückschreiben
./s3curl.pl –id company –put logbucketname.acl — -s -v ‘http://logbucketname.s3.amazonaws.com/?acl’

4. Das Zielbucket für die Logfiles ist nun erstellt, also kann das Logging für das zu überwachende Bucket aktiviert werden.

4.1 Die logging Einstellungen holen. Bitte im folgenden “monitorbucketname” ersetzen durch den Namen des zu überwachenden Buckets.

./s3curl.pl –id company — -s -v ‘http://monitorbucketname.s3.amazonaws.com/?logging’ > monitorbucketname.logging

4.2 In der geholten Datei monitorbucketname.logging TargetBucket und TargetPrefix ergänzen, bzw. einkommentieren.

<?xml version="1.0" encoding="UTF-8"?>
<BucketLoggingStatus xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
  <LoggingEnabled>
    <TargetBucket>logbucketname</TargetBucket>
    <TargetPrefix>monitorbucketname-access_log-</TargetPrefix>
  </LoggingEnabled>
</BucketLoggingStatus>

4.3 zurückschreiben

./s3curl.pl --id company --put monitorbucketname.logging -- -s -v 'http://monitorbucketname.s3.amazonaws.com/?logging'

Fertig! Es kann einige Minuten dauern, bis die ersten Logfiles in das neue Bucket geschrieben werden.

Viel Erfolg beim Analysieren der erweiterten Logs!

Quellen:
http://docs.amazonwebservices.com/AmazonS3/latest/index.html?ServerLogs.html
http://blog.erichsen.net/2007/11/06/experimenting-with-amazon-s3-eu-edition/
http://solutions.amazonwebservices.com/connect/thread.jspa?messageID=51691

Ich habe in letzter Zeit wieder mehr mit OpenID gemacht und dabei “Attribute Exchange” entdeckt.
Diese OpenID Erweiterung ermöglicht es, Userdaten des Accounts an die anfragende Seite zu übertragen. Im Gegensatz zur verbreiteten sreg Erweiterung, unterstützt sie aber eine Reihe zusätzlicher Attribute (z.B. Trennung von Vorname und Nachname, mehrere Profil-Urls…). Neben Google (Doku) unterstützt auch myopenid diese Erweiterung.
Die Implementierung ist eigentlich recht schmerzfrei. Leider habe aber nirgends guten Beispielcode gefunden und die Dokumentation zu dem Thema ist insgesamt ungenügend, so dass ich die einfache Lösung unten erst mit viel Trial and Error gefunden habe:

Entscheidend war folgende Information (danke an Rakuno Futani):
Anders als in der Doku angebeben, muss als Namespace anscheinend http://schema.openid.net für die Attribute genutzt werden. Andere Namespaces, z.B. http://axschema.org/contact/email gunktionieren zumindest mit MyOpenid nicht. Erschwerend kommt während der Entwicklung hinzu, dass Google z.B. die Attribute nur bei der allerersten Anfrage  mitsendet und davon ausgeht, dass der anfragende Server diese Daten erfolgreich speichert. Eine leere Response heißt also nicht unbedingt, dass die Anfrage falsch war.

Hier die Beispielimplementierung mitilfe der Janrain PHP Library (die übrigens dringend mal als PHp5 Verison rauskommen sollte).

Request

Dem Request fügt man die AX-Erweiterung hinzu und gibt an, welche Userdaten geholt werden sollen.

<?php
  $axRequestProfileData = array(

    'email'   => 'http://schema.openid.net/contact/email',

    'username' => 'http://schema.openid.net/namePerson/friendly',

    'firstname'   => 'http://schema.openid.net/namePerson/first',

    'lastname'    => 'http://schema.openid.net/namePerson/last',

    'country' => 'http://schema.openid.net/contact/country/home',

    'birthday' => 'http://schema.openid.net/birthDate',

    'gender' => 'http://schema.openid.net/gender',

    'language'    => 'http://schema.openid.net/pref/language',

    'web'     => 'http://schema.openid.net/contact/web/default',

    'blog'     => 'http://schema.openid.net/contact/web/blog',

    'about' => 'http://schema.openid.net/media/biography',

    'image' => 'http://schema.openid.net/media/image/default',

    'fullname' => 'http://schema.openid.net/namePerson/'

  );

    $ax_request = new Auth_OpenID_AX_FetchRequest();    if ($ax_request) {

    foreach($axRequestProfileData as $alias => $url){

        $ax_request->add(Auth_OpenID_AX_AttrInfo::make($url, 1, true, $alias));

    }

    $request->addExtension($ax_request);

  }
?>

Response

Nach der Autentifizierung erhält man dann die Daten aus der Response so:

<?php

  $ax = Auth_OpenID_AX_FetchResponse::fromSuccessResponse($response);

  var_dump($ax->data);

?>

Beim Antesten von MAMP in Kombination mit dem aktuellen Symfony 1.2 musste ich feststellen, dass laut phpinfo() in dem php auf der Konsole (CLI) PDO nicht aktiviert ist. Der symfony doctrine:build-sql task steigt mit entsprechender Fehlermeldung aus:

unable to find a mysql driver

Der schnellste (aber nicht schöne) Fix den ich im Symfony-Forum fand ist, einen harten symlink auf das MAMP-php zu setzen.

$ sudo ln -f /Applications/MAMP/bin/php5/bin/php /usr/bin/php

Alternativ kann man ohne in /usr/bin/ einzugreifen und ohne die Gefahr, dies nach dem nächsten Systemupdate wiederholen zu müssen, kann man einfach die PATH-Variable in der Datei “.bash_profile” im eigenen Homeverzeichnis ändern:

PATH=.:~/home/bin:/Applications/MAMP/bin/php5/bin/php:"${PATH}"

Danach eine neue Kosole öffnen, damit die Änderung auch greift und viel Spaß mit MAMP+Symfony.

In eigener Sache: Internetworld.de hat ein Interview veröffentlicht, dass ich in Kooperation mit Anne Arndt von socialpudding.com mit Michael Otto von Xing geführt habe. Anlass ist die Einbindung von Googles OpenSocial auf Xing, die mittlerweile Gestalt annimmt in Form von ersten Applikationen.

Gute Unterhaltung…