Skip to content

E-Mail versenden von Amazon EC2

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.

Rechner im AD LDAP mit Powershell auflisten

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;

IPv6 default address selection in Java

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.

Windows 7 hosts-file ignoriert IP Addressen mit 0 prefix

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

Database Administration for Diaspora pods (mongo shell)

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.

Apache als Reverse Proxy für Diaspora

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.

WLAN to go (Trekstor Portable WLAN HotSpot)

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.

iPhone 3g Soft-Unlock

Einstellungen / Allgemein / Info / Modem FW
Das DevTeam kündigt den Soft-Unlock für das iPhone 3G zum 1.1.2009 an. Damit werden sich dann die Sim-Lock Sperre umgehen lassen, falls man die Firmware des Baseband Moduls noch nicht geupdated hat. Bis einschliesslich 2.11.07 soll eine entsprechende Anpassung möglich sein. Das ganze läuft unter dem Codenamen "Yellowsn0w". Eine Video Demo gibt es auf Qik. Aktuell werden die Neuerwerbungen noch mit 2.11.07 ausgeliefert, bei einem regulären Update auf die 2.2 Firmware per iTunes wird allerdings das Baseband Modul auf die 2.28.00 gebracht, hierfür kann der Soft Unlock nicht mehr verwendet werden. Deswegen warnt das Dev-Team auch vor so einem Update. Auf dem CCC gibt es auch eine Session zum Thema "Hacking the iPhone". Deutsche (T-Online) iPhones scheinen übrigens als Modell Nummer z.B. die MB497DN zu haben. Eine Liste der Modell Nummern gibt es beim Apple Support. Die iPhones scheinen aber alle mehrsprachig zu sein, das amerikanische Modell dessen Versionsinfo ich hier zeige war auch nach dem ersten Anschliessen an ein deutsches iTunes deutschsprachig (ohne Update).

Terminkonflikt

Heute finden an der Uni-Karlsruhe gleich zwei interessante Termine statt. Die Java User Group Karlsruhe musste deswegen in den Raum -102UG in der Informatik Fakultät ausweichen, dort gibt es um 19:15Uhr (-21:15) einen Vortrag von Dr. Patrick Schemitz (Netpioneer GmbH) zum Thema Grundladen [Web] Security Auditing. In -101UG spricht Dr. York Sure von SAP Research im Rahmen der GI/ACM Regionalgruppe Karlsruhe über Internet of Services. Dabei geht es um den Einsatz von Semantischen Technologien bei der Vermarktung von Internet Services. Beide Termine finden sich auf dem IT-Kalender des Stadtblog KA. Dort findet sich auch eine Ankündigung für Morgen: Gründung des "Verein der Karlsruher Software-Ingenieure" um 16:00-18:00 am FZI. Näheres dazu in der Presseerklärung von FZI, KIT, adrena objects, 1&1, SAP und HsK. Ich werde wohl bei der JUG-KA vorbeischauen heute Abend und mir Morgen die Info Veranstaltung ansehen.