Technik

Wie ich bereits berichtet hatte kann es für einen Anwender der IaaS Cloud Amazon EC2 Sinn ergeben den Simple Email Service (SES) von Amazon zu verwenden um E-Mails zu versenden.

Dabei kann man entweder die Amazon API/Tools verwenden, oder inzwischen auch die Mails per smtps an den Amazon Smarthost liefern. Amazon selbst bietet nur einen SMTP-SSL Server auf Port 465 an. Die meisten MTAs können dieses Protokoll nicht mehr sprechen und ziehen STARTTLS vor, deswegen empfiehlt Amazon in seiner Anleitung die Verwendung von stunnel als zwischengeschaltenen Proxy.

Diese Indirektion ist aber unschön, und kann mit einer aktuellen Exim Version vermieden werden. Ab der Version 4.77 unterstützt der SMTP Transport von Exim auch das smtps Protokoll (für ausgehende Verbindungen).

Mit folgenden Exim Einstellungen (Auszug) kann also ein EC2 Linux Rechner direkt an den Amazon Dienst die E-Mail ausliefern (wichtig: die Envelop-From und From: Addresse der versendeten Mails müssen in der Liste der verifizierten SES Absender sein. Als Empfänger kommen nur dann beliebige E-Mail Addressen in Frage, wenn man diese Funktion bei Amazon explizit freischalten hat lassen.

1. Alle Mails an dem Amazon Server leiten (dnslookup entfernen):

smarthost:
  driver = manualroute
  domains = ! +local_domains
  transport = remote_smtps
  route_data = email-smtp.us-east-1.amazonaws.com
  no_more

2. Einen neuen SMTP/SSL Transport definieren:

remote_smtps:
  driver = smtp
  protocol = smtps
  #port = 465
  hosts_require_auth = *
  hosts_require_tls = *

3. Zusätzlich einen Authenticator mit dem SES User/Passwort definieren:

client_login:
  driver = plaintext
  public_name = LOGIN
  client_send = : xxxxI6CIH2YIWSNxxxxx : Agcq00AEvA2ZDiQHNrDvTEODE3FWa1rxxxxx

Ich habe das ganze unter Amazon Linux mit Exim 4.77 aus dem AltCent Repository getestet:

wget http://centos.alt.ru/repository/centos/6/i386/exim-4.77-1.el6.i686.rpm
rpm -i exim-4.77-1.el6.i686.rpm

Es bietet sich an Exim so zu konfigurieren, dass nur auf localhost auf dem Submission Port E-Mails angenommen werden:

daemon_smtp_ports = 587
local_interfaces = 127.0.0.1

Dies stellt sicher, dass der Dienst nicht für Spam oder Sicherheitsangriffe ausgenutzt werden kann.

Die Bundesnetzagentur hat ein Eckpunktepapier zum Thema Smart Grids und Markets veröffentlicht. Damit will die Bundesbehörde

durch dieses Papier eine intensivere Diskussion der Thematik anstoßen zu können und die Veränderungen des Energieversorgungssystems weiter voran zu bringen. Dieses Eckpunktepapier soll die Diskussion zu dieser Thematik weiter befördern und besser strukturieren.

Das "Eckpunktepapier der Bundesnetzagentur zu den Aspekten des sich verändernden Energieversorgungssystems" enthält Leitgedanken und Begriffsdefinitionen und ist schon aus diesem Grund sehr lesenswert. Ob die einzelnen Thesen (Abnahme des Gesamtenergieverbrauchs) nun zutreffen wird sich zeigen, von einer Zunahme der Stromabnahme wird aber ausgegangen. Auch bei intelligenteren Verbrauchern (da zunehmend andere Energieformen verdrängt werden, was angesichts der Endlichkeit von fossilen Energieträgern nur logisch ist).

Das Paper baut darauf, dass Verbraucher sich über Marktsignale (Preise) steuern lassen. Das wird sich zeigen wie gut das funktioniert...

Ein wenig sehr optimistisch dürfte die Annahme der Transaktionskostensenkung bei "kleinteiliger Interaktion" sein (Fehlschläge im Smartmeter Markt wie in den Niederlanden oder Großbritannien deuten ja eher darauf hin, dass es sinnvoll sein kann alternative Lösungswege anzustreben und nicht alles über Informationstechnologie lösen zu wollen. Größtenteils wird der Smartmetermarkt von Anbietern getrieben die sich neue Einnahmequellen versprechen und die Vorteile werden in den meisten Haushalten weder gesehen - noch existieren diese). Das BNetzA Papier sieht dies aber auch (Leitgedanke 4).

Was mir persönlich im Papier fehlt ist ein klarere Fokus auf das Thema Datenschutz, Schutz von kritischen Infrastrukturen und Monokultur. Die Notwendigkeit von Datendrehscheiben wird nicht hinterfragt, und eine Vermischung der Messdaten von Prosumenten oder Industrieabnehmern mit den Messstellen in Haushalten führt meiner Meinung nach zu einer Übertechnisierung der Haushalte. Für eine zuverlässige Demand-Site Prognose ist meiner Meinung nach nicht notwendig den Tagesverlauf jedes einzelnen Haushaltes zu betrachten - ganz im Gegenteil das ist eher schädlich. Der Nutzen von mehr Transparenz beim Stromverbrauch eines einzelnen Haushaltes kann auch durch eine rein lokale Informationsanwendung (deutlich besser) gelöst werden. Eine feingranulare Übermittlung von Messwerten erscheint mir nicht zwingend notwendig und vor allem nicht Ökonomisch.

In dem Zusammenhang verweise ich auch auf den Artikel in der aktuellen Datenschleuder #95 (Power to the People, Das Stromnetz der Zukunft, Mathias Dalheimer, Seite 35-48) und die Projekte mySmartGrid sowie volkszaehler.org.

Wer ein Smartphone mit sich rumschleppt wird schon auf die Idee gekommen sein einen Web Kalender wie z.B. Google Calendar zu synchronisieren, um immer alle Termine im Blick zu haben. In meinem Fall habe ich einen Google Calendar Account in dem ich einige andere Kalender zusammenfasse, dieser wird dann per CalDAV auf dem iPhone eingebunden. So sehe ich zum Beispiel die Karlsruher IT Termine, die Familientermine und die Termine der Karlsruher Piraten.

Was mir bisher noch gefehlt hat, waren meine Facebook Events, da hier immer auch mal wieder eine Einladung dabei ist, der ich zwar bei Facebook zusage, diese dann aber nicht in einen der Google Calender übernehme. Es gibt hier aber eine einfache Möglichkeit, man kann die Events in Facebook als webcal/ical Feed exportieren. Diese URL kann man dann in Google als neuen Kalender von einer URL importieren.

Das hat aber leider das Problem, dass Google bei einigen Einträgen kein Titel oder Beschreibung anzeigt. Das ist ein bekanntes Problem, und es gibt im Web auch Anleitungen wie man das beheben kann. Bei mir hat das auch geklappt (allerdings musste ich nicht CLASS:CONFIDENTIAL in CLASS:PUBLIC ändern, sondern bei mir waren es CLASS:PRIVATE Einträge die Facebook produziert hat:

<?php
$ical="http://www.facebook.com/ical/u.php?uid=XXX&key=XXX";
$file=file_get_contents($ical);
$replace="CLASS:PUBLIC";
$output=str_replace("CLASS:CONFIDENTIAL",$replace,$file);
$output=str_replace("CLASS:PRIVATE",$replace,$output);
header("Content-Type: text/Calendar");
// Give the file a name and force download
header("Content-Disposition: inline; filename=events.ics");
print_r($output);
?>

Diese Lösung setzt allerdings voraus, dass man irgendwo ein PHP Script ablegen kann. Damit muss man jetzt nur die Export-URL von Facebook in dem PHP Script hinterlegen ("webcal:" in "http:" ändern), und in Google die PHP URL als Kalender importieren. Dabei ist zu beachten, dass jeder der das Script kennt und aufrufen kann so an alle Facebook Termine rankommt (auch die privaten).

Wer das mit dem eigenen PHP Script nicht machen will, der kann auch Yahoo! Pipes verwenden. Das ist ein Dienst bei den man eine Verarbeitungspipeline für Feeds zusammenstellen kann. Im Falle von ICS Dateien reicht es bei Yahoo aus diese nur als Source zu definieren, und dann direkt wieder zurückzugeben, denn die Yahoo Quelle für Feeds (die ICS versteht) filtert automatisch die CLASS Attribute ganz raus.

Bei Yahoo Pipes muss man immer etwas tricksen wenn man einzelne Komponenten verbinden möchte (auf den Typ achten), deswegen hat die von mir verwendete Pipe noch den Zwischenschritt mit dem URL-Builder. Die URL selbst ist in einem "Private String" abgelegt, damit niemand der die Sourcen sehen kann an meine Facebook Events herankommt. (Leider lässt sich aber die Pipe trotzdem nicht sinnvoll Sharen, aber ich denke mit dem Screenshot könnt Ihr Euch leicht eine eigene zusammenbauen). Beim Aufruf der Pipe ist es wichtig den Parameter "_render=ical" mitzugeben. Früher gab es hierfür wohl einen Menueintrag bei Yahoo, der scheint aber entfernt worden zu sein. Auch hier gilt, wer die Addresse Eurer Pipe kennt, kann Eure Facebook Terminzusagen lesen.

Amazon EC2 ist ein IaaS Anbieter bei dem man eigene virtuelle Systeme starten kann. Diese Systeme können dann alle Systemfunktionen die eine Anwendung benötigt bereitstellen. Dazu gehört zum Beispiel auch der E-Mail Versand (z.B. root Mails oder eben E-Mails der Anwendung wie z.B. Passwort Reminder oder Notifications).

Um sicherzustellen, dass die E-Mails die von einem Amazon EC2 System abgeschickt werden auch ankommen, und nicht in Spam Filter der Provider hängenbleiben sind folgende Punkte zu beachten:

a) wenn man einen Mailserver (MTA) verwendet der die Mails versendet so sollte dieser natürlich sicher konfiguriert sein, und kein Relaying von E-Mails zulassen - da sonst der EC2 Server zur Spamschleuder wird (was nicht nur Ärger mit Amazon nach sich zieht).

b) Der SMTP Server meldet sich mit einem Rechnername. Dort sollte er nicht den internen Amazon EC2 Namen verwenden der dem Rechner zugewiesen wird, denn dir dort verwendete .internal Domain wird von vielen E-Mail Empfängern als ungültig abgelehnt.

c) Die E-Mail Adresse des SMTP Servers (also in dem Fall der virtuelle EC2 Host) sollte in einen gültigen Hostnamen aufgelöst werden, denn sonst springt der Spamschutz der Empfänger an. Dies ist bei Amazon nur sinnvoll machbar wenn man eine Elastic IP verwendet. Dieses Verfahren wird PTR oder auch "reverse DNS" checks genannt.

d) Der Envelop-From (im Falle von Cron Mails z. B. root@host) der versendeten E-Mails sollte eine gültige E-Mail Adresse sein. Insbesondere prüfen E-Mail Server beim Empfang, ob die Domain existiert. Hier sollte also auch nicht der .internal Hostname von AWS verwendet werden.

e) Die Domain einer Absender E-Mail Adresse sollten nicht nur gültig sein, sondern mit dem SPF Mechanismus (Sender Policy Framework) kann der Betreiber der Domain auch angeben von welchen Rechnern legalerweise Mails mit dem Absender versendet werden. Einige Empfänger benutzen das, um das Spamaufkommen zu reduzieren. In der Regel kommt in der Liste der zugelassenen Server nur die MX Server der Domain vor, und eben nicht beliebige IP-Adressen aus den Amazon AWS Netzen. Es bietet sich auch nicht an das komplette EC2 Netz in die Liste aufzunehmen, da sonst alle Amazon Kunden wiederum E-Mails am SPF Filter vorbei versenden können (das ist zwar weniger ein Problem aber eben unschön).

Aus diesen Punkten ergeben sich zwar einige Konfigurationen die man vornehmen kann um von einem EC2 Host direkt an Endempfänger Mails zu versenden. Die Wahrscheinlichkeit dass diese aber häufig als Spam erkannt werden ist groß. Deshalb ist es anzuraten, dass ein Smarthost verwendet wird. (Das hat auch administrative Vorteile wenn die EC2 Hosts Ihre Mails schnell loswerden und man nicht mehrere Mailwarteschlangen überwachen muss).

Um kein eigenes Relay betreiben zu müssen bietet es sich z.B. an den Simple E-Mail Service (SES) von Amazon zu verwenden. Dann muss man nur die SES E-Mail Server von Amazon AWS zusätzlich in die SPF Liste der Absenderdomain aufnehmen. Dies ist hier beschrieben: http://docs.amazonwebservices.com/ses/latest/DeveloperGuide/SPF.html. Im Gegensatz zum kompletten IP-Subnetz von Amazon EC2 hat man bei dieser Vorgehensweise den Vorteil, dass Amazon ein hohes Interesse daran hat, dass nur autorisierte Benutzer die Absenderadresse verwenden. (Gleiches gilt übrigens auch für Google App Engine, hier kann man auch Mail Relays in die SPF Liste aufnehmen). Zudem kann man sich danke Amazon IAM ein Benutzername/Passwort erzeugen der außer dem E-Mail Versand keine weiteren Rechte hat. Dieser kann man dann bedenkenlos im EC2 Image hinterlegen - zumindest solange man dieses nicht mit anderen Amazon Anwendern teilt. Sonst bietet es sich eher an diese Credentials beim Start mit anzugeben.

Im nächsten Post beschreibe ich, wie man bei einem AMI auf Basis von Amazon Linux diese Varianten realisieren kann.

Ich hab ein wenig mit Powershell herumgespielt (weil ich das Script das auch in de.Hackin9.org 08/2011 abgebildet war nicht verstanden habe).

Dabei kam dann folgendes funktionierendes Script heraus, es sortiert mit alle Rechner des AD LDAPs und zeigt diese in einem grafischen Viewer mit Betriebsystemversion und Servicepack Level an:

$ldapSearcher = new-object directoryservices.directorysearcher;
$ldapSearcher.filter = "(objectclass=computer)";
$computers = $ldapSearcher.findall();
$pcs = @();
foreach ($c in $computers) {
  $pc = "" | Select-Object Name,OS,SP,SPN;
  $pc.Name=$c.properties["cn"];
  $pc.OS=$c.properties["operatingsystem"];
  $pc.SP=$c.properties["operatingsystemservicepack"];
  $pc.SPN=$c.properties["serviceprincipalname"];
  $pcs += $pc;
}
$pcs | sort-object OS,SP,Name | Out-GridView;

Ich habe aber keine Ahnung wie man einfacher aus den Dictionary Entries des $c.Properties Member direkte Properties machen kann ohne diese mit einer foreach Schleife und direktem Assignment aufwändig zu kopieren. Ich hoffe ein mitlesender Powershell Guru kann mir das kurz sagen? :)

Update: Max Trinidad (@MaxTrinidad) hat mich auf die Idee mit New-Object gebracht, damit lässt sich das Script etwas vereinfachen und die Attribute in Strings konvertieren:

$ldapSearcher = new-object directoryservices.directorysearcher;
$ldapSearcher.filter = "(objectclass=computer)";
$computers = $ldapSearcher.findall();
[Array] $pcs = $null;
foreach($c in $computers) {    
    $pcs += New-Object PSobject -property @{
        Name = [string]$c.properties["cn"];
        OS = [string]$c.properties["operatingsystem"];
        SP = [string]$c.properties["operatingsystemservicepack"];
        SPN = [string]$c.properties["serviceprincipalname"]; }
}

Und darauf aufbauend (aber ohne String Konvertierung) dann die Lösung mit der Automatischen Übernahme aller Dictionary Einträge aus dem AD Objekt:

$ldapSearcher = New-Object directoryservices.directorysearcher;
$ldapSearcher.filter = "(objectclass=computer)";
$computers = $ldapSearcher.findall();
[Array] $pcs = $null;
$computers | ForEach-Object { $pcs += New-Object PSobject -property $_.Properties; }
$pcs | Out-GridView;

Da bei IPv6 Nodes (also Rechner und andere Teilnehmer an einem Netzwerk) schon konzeptionell mehrere Adressen haben ist die Auswahl welche Quell- und Zieladresse verwendet werden soll eine wichtige Funktion. Insbesondere dann wenn ein Rechner im Dual-Stack Betrieb sowohl IPv4 als auch IPv6 Adressen erreichen kann.

Bei IPv6 kann jedes Netzwerkinterface mehrere IPv6 Adressen haben, die dann entweder in unterschiedlichen Bereichen (Scopes) genutzt werden können (localhost, link, site, global) oder die unterschiedliche Bevorzugt (valid, prefered) sind. Durch die Unterstützung von Renumbering (stateless autoconfiguration) haben Adressen unterschiedliche Lebenszeiten. Zudem gibt es Adressen die über eine Migrations-/Tunnel Technologie wie Toredo, ISATAP oder 6to4 bereitgestellt werden, und nicht immer benutzt werden sollen.

Idealerweise würde eine Anwendung oder das Betriebssystem alle möglichen Quell/Ziel-Adresskombinationen ermitteln, und alle (aussichtsreichsten zuerst) durchprobieren. RFC 3484 beschreibt ein Verfahren für die Default Address Selection für IPv6. Der von Microsoft Research verfasste Entwurf gibt Regeln vor wie die Auswahl von Ziel- und Quelladressen zu geschehen hat, und definiert auch eine Möglichkeit dass der Administrator eines Systems eigene Gewichtungen definieren kann.

Ideal wäre eine Laufzeit Funktion, der man einen Hostnamen übergibt, und die dann die Verbindung zur Gegenstelle herstellt und dabei alle Regeln des RFC 3484 (und dringend notwendiger zukünftiger Verbesserungen) beachtet. Durch die Trennung zwischen Kernel und Usermode, und aus Gründen der Kompatibilität mit existierendem Netzwerkcode verwenden die meisten* Systeme allerdings ein anderes Verfahren. Bestehende Funktionen wie z.B. getaddrinfo(3) wurden erweitert: die Auflösung von Hostnamen in Adressen liefert jetzt eine nach Präferenzen sortierte Liste der Zieladressen zurück. Dabei greift die Bibliotheksfunktion auf Adress- und Routinginformationen des Kernels zurück. Denn es müssen für jede zurückgelieferte Zieladresse auch die potentiellen Quelladressen bestimmt und bewertet werden.

Unter Windows kann die Sortierung mit der prefixpolicy (netsh.exe interface ipv6 show prefixpolicies) angezeigt werden. Linux Systeme speichern die Konfiguration in /etc/gai.conf, aktuelle Einstellungen können mit dem iproute2 Paket angesehen werden (ip addrlabel). Das ganze ist im Kernel und der glibc implementiert.

Auch bei Java wurde kein komplett neues Verfahren für den Verbindungsaufbau für IPv6 definiert**. Die Anwendung selbst ist dafür zuständig alle möglichen Zieladressen der Reihe nach durchzuprobieren. Wenn die Anwendung keine Quelladresse angibt (was sie vermeiden sollte) so wird dann der Kernel für jeden der Zieladressen eine Quelladresse auswählen. Wenn eine Adresse nicht erreichbar ist, so muss die nächste Adresse verwendet werden. Wenn alle Adressen nicht erreichbar sind, so sollte eine Fehlermeldung zurückgegeben werden die alle probierten Zieladressen benennt und den ersten (oder alle) Fehlermeldungen benennt.

Beispielhaft kann dies so aussehen:

Socket connectToHost(String host, int port)
	throws UnknownHostException, SocketException
{
	IOException firstException = null;

	InetAddress[] addressArray = InetAddress.getAllByName(host);
	for(InetAddress addr : addressArray)
	{
		try {
			return new Socket(addr, port);
		} catch (IOException ex) {
			if (firstException == null)
				firstException = ex;
		}
	}

        // build informative error message
	StringBuilder msg = new StringBuilder("Unable to connect to host=");
	msg.append(host); msg.append(" port="); 
        msg.append(String.valueOf(port)); msg.append(" [");
	
	for(int i=0;i < addressArray.length;i++)
	{
		if (i != 0)
			msg.append(',');
		msg.append(addressArray[i]);
	}
	msg.append("]: "); msg.append(firstException.getMessage());
	SocketException se = new SocketException(msg.toString());
	se.initCause(firstException);
	throw se;
}

Dieser Code überlässt die Auswahl einer Quelle dem Kernel (es werden also nicht alle möglichen Kombinationen durchprobiert). Ebenso ist kein Handling für Timeouts enthalten, und ein Cache der Verbindungszustände erinnert oder gar ein paralleler Aufbau zu mehreren Zielen ist noch nicht enthalten. Trotzdem ist der Code schon recht komplex, sollte also nicht mehrfach implementiert werden müssen.

Von InetAddress.getByName(String host) würde ich auf jeden Fall Abstand nehmen. Diese Methode gibt nur die bevorzugte Addresse zurück, und führt bei DualStack Anwendungen dazu, dass nicht IPv6 und IPv4 Adressen durchprobiert werden.


* Microsoft ist typischerweise Entwicklerfreundlicher und muss weniger Rücksicht nehmen auf etablierte APIs, deswegen gibt es die Funktion WSAConnectByName() die alle Addressen selbst durchprobiert.

** Java kennt Socket(String name, int port), dieser Konstruktor verwendet aber keine Schleife um alle möglichen Adressen zu kontaktieren.

Mir ist gerade zufällig aufgefallen (als ich diesen Bugreport nachgestellt habe) dass Windows 7 IPv4 Address-Einträge die eine führende 0 haben im hosts file ignoriert:

C:\Windows\system32>echo 9.20.187.06 TestHost
  >> %SystemRoot%\system32\Drivers\etc\hosts

C:\Windows\system32>ipconfig /displaydns | find "A-Eintrag"
    AAAA-Eintrag  . . . . : 2001::1
    AAAA-Eintrag  . . . . : fe80::20d:60ff:fe49:47
    AAAA-Eintrag  . . . . : 2001::2
    (Host-)A-Eintrag  . . : 9.20.187.96

C:\Windows\system32>echo 9.20.187.6 TestHost
  >> %SystemRoot%\system32\Drivers\etc\hosts

C:\Windows\system32>ipconfig /displaydns | find "A-Eintrag"
    AAAA-Eintrag  . . . . : 2001::1
    AAAA-Eintrag  . . . . : fe80::20d:60ff:fe49:47
    AAAA-Eintrag  . . . . : 2001::2
    (Host-)A-Eintrag  . . : 9.20.187.96
    (Host-)A-Eintrag  . . : 9.20.187.6

One advantage of running your own Diaspora pod is the fact, that you have access to the MongoDB which is used to store your Seed. This allows you to do some functions which do not yet have a UI (for example canging the E-Mail address of a user) or which is required to work around alpha hickups (deleting duplicate requests).

The mongo shell is a client to the mongodb, which can evaluate JavaScript expressions. It has some macros ("use", "show" and "help"), the other commands are typically JavaScript methods.

First you assign a Database Object to the variable "db", you can use that with "use". In the case of Diaspora, the database is named "diaspora-ENVIRONMENT". If you start mongo shell, it will start with the database "test", but you can list all existing databases, and pick one:

$ mongo
connecting to: test
> print('hello JavaScript!')
hello JavaScript!
> show dbs
admin
diaspora-development
local
magent
> use diaspora-development
switched to db diaspora-development
> db
diaspora-development
> show collections
aspects
comments
contacts
invitations
people
posts
requests
system.indexes
users

Note: you can specify non-existing databases and collections, they are initially empty but will be created, so do not misstype. You can use db.collection.help() to see the available methods on a collection object. find() is used to search and display documents. If you specify no parameters it will return a cursort with all documents. The first parameter can be a list of filter criterias, and the second parameters a list of properties to return. mongo shell will iterate and print the first ten entries of a cursor automatically:

> db.users.find({},{username:1,email:1})
{ "_id" : ObjectId("4cf1..02"), "username" : "bernd", "email" : "bernd-09@eckenfels.net" }
{ "_id" : ObjectId("4cf1..2d"), "username" : "mela", "email" : "mela@mela.de" }
{ "_id" : ObjectId("4cf2..3b"), "username" : null, "email" : "xx@example.com" }

Here you can see, that this pod has 3 users (seeds), two are already established, the third is a pending invite (token).

To change the e-mail address of a existing user you can assign the document to a variable, change the desired property and update the collection. For this we use the findOne method, which does return the first match instead of a cursor:

> var bernd = db.users.findOne({username:"bernd"})
> print(bernd.email)
bernd-09@eckenfels.net
> bernd.email = "bernd-10@eckenfels.net"
> db.users.save(bernd)
> db.users.findOne({username:"bernd"}).email
bernd-10@eckenfels.net

The above will not create a new document, since the variable "bernd" contains the property _id, and therefore it will update the existing entry in the collection.

You need to know that db.users contains the actual users of the pod (i.e. the seeds) and db.people contains a copy of the public part of other seeds (if you received a request from them, or if you added them to an aspect).

> db.requests.findOne()
{
        "_id" : ObjectId("4cf1...a3"),
        "sent" : true,
        "from_id" : ObjectId("4cf1...03"),
        "to_id" : ObjectId("4cee7...a9"),
        "into_id" : ObjectId("4cf1...9d")
}
> db.people.findOne({_id:ObjectId("4cf1...03")}).diaspora_handle
bernd@pod.eckenfels.net
> db.people.findOne({_id:ObjectId("4cee7...a9")}).diaspora_handle
daniel...@joindiaspora.com
> db.aspects.findOne({_id: ObjectId("4cf1...9d")}).name
Piraten

As you can see I sent a request to "Daniel", inviting him to my aspect "Piraten", but he has not yet responded.

Hope this helps you to find your way around in the object model of Diaspora. I recommend you read the MongoDB tutorial to better use the mongo shell, and check the JS API documentation for the details.

Diaspora* die Software für verteilte soziale Netze wurde in einer Alpha Version veröffentlicht.

Bei Diaspora ist vorgesehen dass es keine zentrale Plattform gibt, sondern Benutzer Ihre eigenen Server - Pods genannt - betreiben. Da es aktuell auch auf dem offiziellen pod von joindiaspora.com keine Benutzer freigeschalten werden, ergibt es Sinn einen eigenen Server aufzusetzen.

Im Diaspora Wiki findet man dazu eine Anleitung. Allerdings beschreibt diese nicht, wie man in einer Produktivumgebung die Ruby Anwendung mit einem Webserver versieht, der die Anfragen auf Port 80 entgegennimmt (und statische Assets direkt ausliefert).

Ich habe dazu einen virtuellen Host mit Apache eingerichtet, die Konfiguration sieht so aus:

LoadModule proxy_module ...
LoadModule proxy_http_module...

<VirtualHost *>
    ServerAdmin webmaster@example.com
    DocumentRoot /var/www/example.com/pod/data/public
    ServerName pod.example.com
    ErrorLog /var/log/httpd/pod.example.com-error_log
    CustomLog /var/log/httpd/pod.example.com-access_log combined

    Alias /uploads/ "/var/www/example.com/pod/data/public/uploads/"
    Alias /images/ "/var/www/example.com/pod/data/public/images/"
    Alias /stylesheets/ "/var/www/example.com/pod/data/public/stylesheets/"
    Alias /javascripts/ "/var/www/example.com/pod/data/public/javascripts/"

    ProxyPass / http://pod.example.com:3000/

  <Directory "/var/www/example.com/pod/data/public">
    Options Indexes FollowSymLinks MultiViews IncludesNoExec ExecCGI
    AllowOverride All
    Order Allow,Deny
    Allow from All
  </Directory>
</VirtualHost>

D.h. Diaspora ist im Verzeichnis /var/www/example.com/pod/data installiert, und der Ruby Server "thin" ist erreichbar auf dem Port 3000.

Falls es jemand testen will, mein Diaspora Seed ist damit unter bernd@pod.eckenfels.net erreichbar.

Vor einiger Zeit habe ich mich bei der PR Agentur von Trekstor beschwert, dass diese mir als Blogger zwar unverlangt Pressemitteilungen senden, aber ohne Testgeräte ich nicht viel berichten kann und will. Jetzt habe ich überraschend ein Testgerät von Trekstor erhalten, und will dies hier gerne besprechen:

In einem sehr kleinen Paket habe ich den "Trekstor Portable WLAN Hotspot" für einen 2-wöchigen Test erhalten. Ein Gerät in der Größe eines Mobiltelefons das als WLAN Hotspot eingesetzt werden kann, und dabei die Verbindung mit dem Internet mittels eingebauter UMTS Funktion herstellt. Es ist also ein UMTS WLAN Router, benötigt dabei aber keinen externen USB Stick, die SIM-Karte des Mobilfunkanbieters wird direkt in das UMTS fähige Gerät eingelegt.

Bis zu 5 WLAN Geräte können sich mit dem Hotspot verbinden, und dieser stellt dann die Verbindung zum Internet via UMTS/HDSPA (3G) oder GSM her. Zusätzlich hat das Gerät einen Mini-USB Anschluss über das es geladen werden kann. Über diesen USB 2.0 Anschluss kann auch ein weitere Rechner (Via Hi-Speed USB 2.0 Netzwerk Interface Treiber) angebunden werden.



Der kleine Hotspot kümmert sich dabei um NAT, Firewall, hat einen DNS Proxy und DHCP Server eingebaut. Konfiguriert wird das Gerät über den Web Browser. Die Knöpfe am Gerät beschränken sich auf ein Minimum (Ausschalter, WLAN Schalter, Manueller Connect).

Das Trekstor Gerätes ist Baugleich mit dem E5 von Huawei (dies wird auch nicht versteckt, das Logo ist auf der Rückseite zu sehen). Das Gerät ist Netlock frei, konnte in meinem Test mit Prepaid Standard SIM Karten von blau.de ebenso wie mit einem UMTS Datenvertrag von O2 genutzt werden. Es unterstützt UMTS im 2100MHz Band sowie Quad-Band GSM (EDGE, GPRS) 850/900/1800/1900MHz - ist also für Reisen geeignet. Das WLAN Modul kann im 2,4GHz Band die Kanäle 1-13 nutzen. (Es gibt bei den Europäischen Modellen eine Ortseinstellung bei der man auch "Japan" auswählen kann, diese schaltet aber keinen weiteren Kanal frei). Das Gerät unterstütz WPS, konnte ich aber mangels Gegenstelle nicht testen. Diese Funktion klingt aber kaum einfacher als das abtippen eines Passwortes von der Gehäuserückseite.

Die Anwendungsfälle sind vielfältig. Als Besitzer von Internet Tablets oder Game Consolen die keine UMTS-Stick Möglichkeit haben ist das Gerät auf jeden Fall eine praktische Option. Weiterhin kann das Gerät von kleinen Reisegruppen oder Arbeitsgruppen mit Note- oder Netbooks genutzt werden um einen (teuren) Internetzugang gemeinsam zu benutzen. Es ist damit Ideal geeignet die Wartezeit am Flughafen zu überbrücken ohne dass jeder der beteiligten einen eigenen Datentarif haben muss (einige Provider erlauben nicht den Betrieb von mehreren Geräten per NAT, dies muss im Einzelfall geprüft werden).

Praktisch an dem Prinzip der WLAN Anbindung ist, dass in der Regel alle Geräte ohne spezielle Treiber die Vermittlungsfunktion des Gerätes nutzen können. Es wird dabei WLAN nach 802.11 b/g mit WPA und oder WPA2.

Der WLAN Hotspot wird mit einem austauschbaren 3.7 V, 1500 mAh Akku geliefert. Es kann über USB vom Rechner geladen und mit Strom versorgt werden. Bei meinen Tests hatte es Laufzeiten von über 4h. Es kann dabei auch von USB Steckernetzteilen oder externen Akkus (Test mit einem Phillips Reserveakku, der zum Beispiel von iPhones nicht akzeptiert wird, war erfolgreich).

Als zusätzliche Funktion bietet das Gerät übrigens noch einen MicroSD Kartenslot in der Speicherkarten bis zu 32GB eingesteckt werden können. Diese können dann entweder über den USB Anschluss benutzt werden, oder der Zugriff auf den Inhalt steht über den Web Server des Geräts zur Verfügung.

Generell ist das Gerät und die Software gut durchdacht, es können mehrere Mobilfunk Profile angelegt werden; mutige Zeitgenossen können die Mobilfunk-PIN im Gerät speichern; wenn Roaming erkannt wird vermeidet das Gerät automatisch Online zu gehen. Bei der Auslieferung hat das Gerät einen eindeutigen Verschlüsselungskey (der auf der Geräterückseite aufgedruckt ist). Die NAT (ALG, DMZ) und Firewall Funktionen können mit guten Home Routern locker mithalten.

Das Gerät wird mit einem kurzen Mini-USB nach USB Kabel geliefert (aber keinem Netzteil) und einem Quick-Start Guide der keine der Optionen der Software auch nur ansatzweise erklärt. Er ist aber ausreichend um die erste WLAN Verbindung mit dem Gerät aufzubauen (Ich empfehle als einer der ersten Aktionen den WPA2 Modus zu aktivieren).

Ja, ich kann das Gerät fast nur loben, auf der Seite der Nachteile sehe ich vor allem den relativ hohen Preis (wobei es im direkten Vergleich mit anderen Geräten in der Leistungsklasse mit 139,- Eur günstig abschneidet), kleinere Lieblosigkeiten in der recht technischen Web Oberfläche (zum Beispiel die Deutsche Übersetzung "x Tag x Stunden x Protokoll") und die doch recht knappe Begrenzung auf 5 WLAN Clients.

Das OLED Dot Display ist recht übersichtlich aber unter vielen Lichtbedingungen kaum abzulesen (spiegelt). Dem Gerät fehlt auch eine VPN Funktion, allerdings sehe ich das nicht als Nachteil an, ein VPN sollte besonders in diesem Einsatzszenario (WLAN) auf dem Endgerät (Notebook) terminiert werden.

Für den stationären Einsatz würde ich das Gerät nicht empfehlen, ebenfalls nicht zur (Not)Versorgung von Veranstaltungen mit Internet (wegen der Anzahl der Clients und den fehlenden externen WLAN Antennen). Aber als Reisebegleiter macht es eine sehr gute Figur. Ich habe keine Erfahrungen mit der Stabilität des Gehäuses, beim Anfassen traut man dem Gerät keine große Robustheit zu. Das Gerät ist auf jeden Fall im Vergleich zum Mitbewerb (D-Link MyPocket, Novalink MiFi) sehr kompakt.