Tor Exit Nodes sind illegal....

Wer die Freiheit aufgibt, um Sicherheit zu gewinnen, wird am Ende beides verlieren.
      --Benjamin Franklin

Photos taken in Freie und Hansestadt Hamburg on Flickr!

Bei Flickr gibt es ein schönes, neues Feature: Photos taken in Freie und Hansestadt Hamburg on Flickr!

Die URL sit ganz einfach, hier mal als Beispiel:

• Hamburg: http://www.flickr.com/places/Germany/Hamburg


• Berlin: http://www.flickr.com/places/Germany/Berlin


• Tokyo: http://www.flickr.com/places/Japan/Tokio

HOWTO: Mit dem OpenVPN-Server unter Apple Mac-OS X mit Windows verbinden

Auf den im vorherigem Blog-Eintrag installierten OpenVPN-Server lässt sich natürlich auch von Windows aus zugreifen. Dazu benötigt der Windows-Rechner eigene Zertifikate. Diese heißen in diesem Beispiel:

• Zertifikat: windows-cert.pem


• Key: windows.pem

Wie Tunnelblick unter Apple Mac-OS X gibt es für den Client auch eine Windows-GUI: OpenVPN GUI. Diese lässt sich von openvpn.se herunterladen: openvpn-2.0.9-gui-1.0.3-install.exe auf http://openvpn.se/download.html.

Man kann die OpenVPN-GUI einfach per Doppelklick auf den Installer installieren. Die Warnung, dass der TUN/TAP-Treiber nicht signiert ist, ignoriert man einfach.

Die Konfigurationsdatei "openvpn.conf", die man auf dem Mac mit Tunnelblick erzeugt und angepasst hat, kopiert man nach "C:\Programme\OpenVPN\config\openvpn.ovpn" und bennent sie um in openvpn.ovpn. Sollte man die mit Tunnelblick erzeugte Konfigurationsdatei nicht zur Hand haben, kann man statt dessen auch eine Beispielkonfiguration aus dem OpenVPN-HOWTO als Template nehmen und anpassen.

Die Zertifikate (s.o.!) muss man ebenfalls in das Verzeichnis "C:\Programme\OpenVPN\config kopieren und in die Konfigurationsdatei eintragen, die Konfigurationsdatei also entsprechend anpassen.

    ca ca.crt
    cert windows-cert.pem
    key windows.pem

Nun kann man die OpenVPN-GUI starten. Im System-Tray erscheint ein neues Icon. Durch Rechtsklick auf dieses neue Icon erscheint ein Kontextmenü, indem man den Menüpunkt "connect" wählt. Der Tunnel sollte sich nun aufbauen.

HOWTO OpenVPN unter Apple MacOS-X als Client verwenden

Für MacOS-X Clients gibt es die bereits im vorherigen HOWTO (http://simonox.blogspot.com/2007/11/howto-openvpn-unter-apple-macos-x.html) angesprochene Software "Tunnelblick". Diese Software ist eine grafische Benutzeroberfläche für OpenVPN, die alle notwendigen Treiber gleich mitbringt. Einem Benutzer, der nur einen Client verwenden möchte, ist es i.d.R. nicht zuzumuten, auf der Kommandozeile Pakete zu installieren und einzurichten. "Tunnelblick" haben wir bereits im letzten Teil des HOWTOs heruntergeladen und auf einem USB-Stick gesichert. Auf dem USB-Stick befinden sich ebenfalls Zertifikate, die auf dem Server erzeugt wurden.

Kurz gesagt muss man nur "Tunnelblick" in das Application-Verzeichnis kopieren, einen Ordner "~/Library/openvpn" erstellen und dort die Zertifikate hinkopieren. Anschließend kann man Tunnelblick starten, den Server einrichten und OpenVPN benutzen. Trotzdem an dieser Stelle eine Step-by-Step-Anleitung.

Das Diskimage von Tunnelblick aktivieren wir und ziehen das Tunneblick-Icon in den Programm-Ordner. Anschließend legen wir mit dem Finder unter dem Heimverzeichnis (erkennbar am Haus-Icon) im Library-Unterverzeichnis ein Unterverzeichnis "openvpn" an (~/Library/openvpn). In dieses Verzeichnis kopieren wir mit dem Finder die Zertifikate und die Konfiguration vom USB-Stick:

* ca.crt
* iBook-cert.pem
* iBook-key.pem

Nun können wir Tunnelblick starten. Es erscheint in der Menüleiste als Icon, das aussieht wie ein Eisenbahntunnel. Tunnelblick legt automatisch eine openvpn.conf-Datei im gleichen Ordner an, in dem die Zertifikate liegen. Diese Konfigurationsdatei muss man bearbeiten, um sich mit dem eigenen Server zu verbinden. Dazu muss man die richtigen Textstellen finden und durch eigene Konfiguration ersetzten.

Um mit dem Server, der im letzten HOWTO installiert und gestartet wurde, eine Verbindung aufzubauen, sind folgende Stellen in der Konfigurationsdatei zu ersetzen. Die Host-Adresse "myserver.dyndns.org" ist entsprechend anzupassen:


remote myserver.dyndns.org 443

ca ca.crt
cert iBook-cert.pem
key iBook-key.pem

cipher AES-256-CBC

dev tun

proto udp

port 443


Nun können wir auf das Tunnelblick-Symbol klicken und "Verbinden: openvpn" wählen. Die Verbindung sollte zustande kommen. Falls die Verbindung zustande kommt, sollte man sich die Konfigurationsdatei unter "~/Library/openvpn" sichern, um sie als Template für weitere Client-Installationen verwenden zu können.

Nun kann man z.B. ein SMB-Share mounten, einen HTTP-Proxy ansprechen usw. Der OpenVPN-Server selbst ist unter der im Server konfigurierten IP-Adresse 10.8.0.1 zu erreichen. Tunnelblick hat die Option, automatisch eine Verbindung zum OpenVPN-Server aufzubauen. Dies ist praktisch, da diese auch aufgebaut wird, wenn das Client-Notebook einmal abhanden kommen sollte. Dazu muss allerdings eingestellt sein, dass sich ds iBook automatisch mit offenen Netzwerken konnektiert. OpenVPN läuft nämlich natürlich nur dann, wenn auch eine Internet-Verbindung besteht.

Wenn sich das iBook mit dem OpenVPN-Server konnektiert, kann man in der OpenVPN-Server-Log-Datei wenigstens erkennen, von welcher IP-Adresse aus sich das Notebook einloggt. In der Log-Datei des Servers kann man nämlich die einzelnen Verbindungen erkennen. Diese sehen wie folgt aus:

OpenVPN CLIENT LIST
Updated,Sat Nov 10 23:10:41 2007
Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since
iBook,XX.XX.XX.XX:60347,13180,13895,Sat Nov 10 22:49:34 2007
ROUTING TABLE
Virtual Address,Common Name,Real Address,Last Ref
10.8.0.6,iBook,XX.XX.XX.XX:60347,Sat Nov 10 22:49:35 2007
GLOBAL STATS
Max bcast/mcast queue length,0
END

Dies bedeutet, dass eine Verbindung vom Rechner, auf dem das iBook-Zertifikat liegt und der die IP-Adresse xx.xx.xx.xx hat, eine Verbindung aufgebaut wurde. Dieser Client-Rechner hat die VPN-IP-Adresse 10.8.9.6 bekommen.

Sollte das Notebook abhanden kommen, sollte man irgendwann natürlich das Zertifikat des Clients zurückziehen. Dies geschieht auf dem Server wie folgt:

sudo openssl ca -revoke /certs/iBook-cert.pem
sudo openssl ca -gencrl -out crl.pem

Das Zurückziehen des Zertifikats muss man dem OpenVPN-Server bekannt machen:

sudo /bin/sh -c "cat ca.crt crl.pem >/etc/openVPN/revoke.pem"

Das Überprüfen der zurückgezogenen Zertifikate muss man in der Konfigurationsdatei des OpenVPN-Servers einstellen:

crl-verify /etc/openvpn/revoke.pem

HOWTO OpenVPN unter Apple MacOS-X

Das OpenVPN-HOWTO (http://openvpn.net/howto.html) geht nur auf die Verwendung von OpenVPN unter Linux und Windows ein. MacOS-X wird dort nicht berücksichtigt. Zwar gab es in der c't einen Artikel zu OpenVPN unter MacOS-X, allerdings wurde in diesem Artikel nicht auf die Konfiguration des Servers eingegangen. Darum an dieser Stelle ein HOWTO für OpenVPN unter MacOS-X. Um dieses HOWTO nachzuspielen, sind keine Programmierkenntnisse erforderlich. Allerdings sollte man wissen, was eine Shell ist und auch den Texteditor "vi" rudimentär bedienen können (oder man verwendet einen anderen Texteditor wie Smultron oder TextMate).

Man verwendet ein VPN (Virtuelles Privates Netzwerk) um über öffentliche/unsichere Netzwerke eine Verbindung mit einem privaten/sicheren Netzwerk aufzubauen. Bei dem privaten Netzwerk kann es sich um das Mini-Home-Netzwerk hinter dem eigenen DSL-Router handeln.

Bei einem VPN wir ein Tunnel zwischen dem Client und dem VPN-Server aufgebaut. Durch den Tunnel fließen dann alle Datenpakete verschlüsselt. OpenVPN ist eine Software zur Realisierung eines solchen VPNs. OpenVPN baut eine verschlüsselte Verbindung zwischen zwei Rechnern (oder zwei Gateways oder Rechner und Gateway) über das offene, unverschlüsselte Internet auf.

OpenVPN kommt - im Ggs. zu IPSec usw. - mit nur einem Protokoll und einem Port aus, ist also recht schlank und einfach. So kann man auch NAT-Router einfach so einrichten, dass sie OpenVPN nicht blocken. Mehr zu OpenVPN findet man in der Wikipedia unter (http://de.wikipedia.org/wiki/OpenVPN).

OpenVPN bentutzt OpenSSL zur Verschlüsselung. Als Protokolle lassen sich TCP oder UDP einsetzen.

Ein Client kann sich gegenüber dem Server mit verschiedenen Verfahren authentifizieren. Für kleine Netze kommen zwar Preshared-Keys in Betracht, sicherer sind allerdings Zertifikate. Ein Client braucht ein gültiges (signiertes) Zertifikat, im sich gegenüber dem Server auszuweisen.

Der Aufbau einer OpenVPN-Verbindung läuft wie folgt ab: Ein Client baut eine Verbindung zum Server auf. Ein X.509-Zertifikat des Servers wird geprüft, um festzustellen, ob der Server wirklich der gewünschte OpenVPN-Server oder ein Man-in-the-Middle ist. Die Prüfung wird mit dem öffentlichen Schlüssel der CA (Certificate Authority) durchgeführt. Es gibt kommerzielle CAs, in diesem HOWTO wird allerdings selbst CA gespielt (demoCA).
Wenn das Zertifikat gültig ist, dann wird eine verschlüsselte Verbindung aufgebaut.

Diese Verbindung erfolgt über SSL aka. TLS. Dabei nutzt OpenVPN die offene SSL-Implementierung OpenSSL. Eine private IP-Adresse bekommt der Client vom Server über den Tunnel. Die Endpunkte des Tunnels sind virtuelle Interfaces (TUN/TAP). MacOS-X bringt diese nicht mit. Darum müssen diese nachinstalliert werden.

Unter Ubuntu-Linux (mit apt) oder Windows (mit einem Installer) lässt sich OpenVPN recht leicht mit Binär-Paketen installieren. Für MacOS gibt es solche Binärpakete leider (noch?) nicht. Darum muss man OpenVPN unter MacOS selbst bauen. Dazu sind die XCode-Tools von Apple (auf der Installations-CD #1 von MacOS-X) nötig.

Zunächst muss man zwei Pakete herunterladen:

* LZO: http://www.oberhumer.com/opensource/lzo/
* OpenVPN: http://openvpn.net

Beide Downloads kann man - sofern StuffIt o.ä. installiert ist - per Doppelklick auf dem Desktop entpacken und in das Home-Verzeichnis verschieben. Spätestens danach muss man die Shell öffnen und damit weiterarbeiten.

LZO ist eine Kompressionsbiliothek, die die Datenpakete von OpenVPN komprimiert. So reagiert das virtuelle Netzwerk über eine langsame Internet-Verbindung weniger träge, da die verschlüsselten Datenpakte komprimiert werden.

LZO baut man im Unix-üblichen configure--make--make-install-Dreischritt (btw: die Tilde (Schlangenlinie) "~" befindet sich bei MacOS unter Alt+n(+Leertaste)):

cd ~/lzo-2.02/
./configure

Sollte nun die Meldung "configure: error: no acceptable C compiler found in $PATH" erscheinen, scheinen die XCode-Tools nicht installiert zu sein. Ansonsten sollten rechte viele Checks über das Terminal laufen, bis die Meldung "Type `make' to build LZO. Type `make install' to install LZO. After installing LZO, please read the accompanied documentation." erscheint. Dieser Aufforderung folgen wir.

make
sudo make install

Nach dem dies erfolgreich durchgelaufen ist ("Libraries have been installed in: /usr/local/lib") wird OpenVPN installiert. OpenVPN ist die eigentliche VPN-Software.

Man wechselt in das Verzeichnis, in das OpenVPN entpackt wurde, baut und installiert es:

cd ~/openvpn-2.0.9/
./configure
make
make check
sudo make install

Nun sollte OpenVPN in usr/local/sbin/openvpn installiert worden sein. Aus bequemlichkeitsgründen trägt man OpenVPN in die PATH-Umgebungsvariable ein, die in der versteckten Datei .bash-profile gesetzt werden kann. Man editiert diese Datei mit VI:

cd ~
vi .bash_profile 

In diese Datei trägt man nun den zusätzlichen Pfad ein. Evtl. sind dort bereits Pfade (wie im Beispiel Python) eingetragen, die man dann nur erweitern muss:

PATH="/Library/Frameworks/Python.framework/Versions/Current/bin:/usr/local/sbin:${PATH}"
export PATH

Damit die Änderung am Bash-Profile gültig wird, muss man die das Terminal neu starten. Ob die Änderungen wirksam sind, kann man über den Befehl

env

kontrollieren. Die PATH-Umgebungsvariable sollte und den Pfad "/usr/local/sbin" enthalten.

Nun lässt sich OpenVPN testweise starten:

openvpn --version

Eine Meldung wie die folgende sollte erscheinen:

OpenVPN 2.0.9 powerpc-apple-darwin8.10.0 [SSL] [LZO] built on Oct 15 2007
Developed by James Yonan
Copyright (C) 2002-2005 OpenVPN Solutions LLC

Wie man an dem Text "[LZO]" erkennt, wurde von OpenVPN die Kompressionsbibliothek LZO erkannt und eingebunden :-)

Nun muss man einen Schlüssel für die Certificate Authority erzeugen:

cd /System/Library/OpenSSL/
sudo openSSL genrsa -des3 -out ca.key 2048

Auf die Frage "Enter pass phrase for ca.key:" sollte man mit einem möglichst komplizierten Passwort antworten, denn eine Verschlüsselung ist stets so stark (oder schwach) wie das gewählte Passwort. Eine best-practice ist, die Anfangsbuchstaben eines langen Satzes kombiniert man Zahlen und Sonderzeichen zu verwenden. Den erzeugen Schlüssel sollte man auf einem USB-Stick, auf dem auch der GPG/PGP-Key gesichert ist, sichern, damit er nicht verloren geht. Das Passwort sollte man nicht vergessen (oder im Schlüsselbund sichern).

mkdir /Volumes/USB\ DISK/OpenVPN
cp ca.key /Volumes/USB\ DISK/OpenVPN/

Nachdem man nun den Schlüssel hat, kann man die Certificate Authority selbst erzeugen:

sudo openSSL req -new -x509 -days 9999 -key ca.key -out ca.crt

Im folgenden Dialog beantwortet man die Fragen am "sinnvollsten" wie folgt:

Country Name (2 letter code) [AU]:KZ
State or Province Name (full name) [Some-State]:Kasachstan
Locality Name (eg, city) []:Astana
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Menin Kasachstanym Ltd.
Organizational Unit Name (eg, section) []:
Common Name (eg, YOUR name) []:borat
Email Address []:borat@whitehouse.gov

Die Aktionen, die man für die Certificate Authority durchführen musste, müssen nun auch für das Server-Zertifikat durchgeführt werden. Eigentlich ist für OpenVPN gar kein "richtiges" Server-Zertifikat nötig. Normalerweise wird ein Server-Zertifikat für viel Geld von Verisign u.a. gekauft. Normalsterbliche gebe das Geld lieber anders aus. Darum erzeugen wir uns das Server-Zertifikat selbst.

sudo openSSL genrsa -out server.key 2048 

Auch diesen Server-Key sichern wir auf dem USB-Stick.

cp server.key /Volumes/USB\ DISK/OpenVPN/

Nun legen wir eine Certifikate Signing Request an (nicht um diesen an Verisign zu stellen):

sudo openSSL req -new -key server.key -out server.csr

Die nun folgende Dialoge beantwortet man wie beim Erstellen der Certificate Authority. Den CSR sichert man wieder auf dem USB-Stick.

cp server.csr /Volumes/USB\ DISK/OpenVPN/

Um den CSR selbst zu signieren, legen wir eine geeignete Ordnerstruktur mit einigen Dateien an:

sudo mkdir -p demoCA/private
sudo cp ca.key demoCA/private/cakey.pem
sudo cp ca.crt demoCA/cacert.pem
sudo mkdir demoCA/newcerts
sudo touch demoCA/index.txt
sudo /bin/sh -c "echo "01" > demoCA/serial

Mit dieser Ordnerstruktur können wir den CSR selbst signieren.

sudo openSSL ca -policy policy_anything -in server.csr -out cerver.crt

Auf die Frage "Sign the certificate? [y/n]" antwortet man mit "y". Dito auf "1 out of 1 certificate requests certified, commit?" mit "y". Nun sollte das Zertifikat erzeugt sein. Dies lässt sich prüfen.

cd demoCA
openssl x509 -noout -in cacert.pem -issuer -subject -dates

Dieses Zertifikat sichert man auf den USB-Stick und sichert es gegen unbefugten Zugriff:

cd demoCA
cp cacert.pem /Volumes/USB\ DISK/OpenVPN
sudo chmod 700 newcerts/
sudo chmod 700 private/
sudo chmod 700 cacert.pem

Letztlich werden nur noch Parameter für die Verschlüsselung angelegt. Die Verschlüsselung wird über den Diffie-Hellman-Schlüsselaustausch (http://de.wikipedia.org/wiki/Diffie-Hellman-Schlüsselaustausch) realisiert. Darum muss die Datei dh2048.pem erzeugt werden:

cd ..
sudo openssl dhparam -out dh2048.pem 2048

Da dieses Tool meldet "This is going to take a long time", ist nun Zeit für eine Pause... puh!

Nun kann man für einzelne Client-Zertifikate erzeugen. Folgend für ein iBook:

sudo mkdir certs
sudo openssl req -new -newkey rsa:2048 -out certs/iBook-crs.pem -keyout  private/iBook-key.pem -nodes

Diese Client-Zertifikate muss man natürlich aus signieren:

sudo openssl x509 -req -in certs/iBook-crs.pem -out certs/iBook-cert.pem -CA demoCA/cacert.pem -CAkey demoCA/private/cakey.pem -CAserial demoCA/serial -days 9999

Die Server-Zertifikate kopiert man nun in eine Verzeichnis, in dem ein Nutzer, der OpenVPN startet, lesen kann:

sudo mkdir /etc/openVPN
sudo cp server.crt /etc/openVPN
sudo cp server.key /etc/openVPN
sudo cp dh2048.pem  /etc/openVPN
sudo cp ca.crt  /etc/openVPN

Für den Mac-Client saugt man sich gleich schon Sandro Laubs "Tunnelblick" (http://www.tunnelblick.net/) und kopiert es auf den USB-Stick. Die Client-Zertifikate kopiert man ebenfalls auf den USB-Stick, um sie auf einen Client (z.B. das oben schon angesprochene iBook) zu übertragen:

cp ~/Desktop/Tunnelblick-versal-3.0b6.dmg /Volumes/USB\ DISK/
sudo cp certs/iBook-cert.pem /Volumes/USB\ DISK/
sudo cp private/iBook-key.pem /Volumes/USB\ DISK/

Um OpenVPN nutzen zu können, benötigt man ein IP-Tunnel-Kernel-Extension. Einen Installer dafür findet man bei Mattias Nissler (http://www-user.rhrk.uni-kl.de/~nissler/tuntap/). Diesen installiert man mit dem Installer. Ein Client, der Tunnelblick verwendet, braucht diesen Treiber nicht, da Tunnelblick alles mitbringt.

Der OpenVPN-Server benötigt eine Konfigurationsdatei "server.conf". Diese Datei legt man unter "/etc/openVPN/server.conf" ab. Eine Beispiel-Konfigurationsdatei kann man direkt bei OpenVPN herunterladen (http://openvpn.net/howto.html#examples). Als Besonderheit wird OpenVPN auf dem HTTPS-Port 443 gestartet. Damit kommt man auch durch eine restriktive Firewall auf den Server. Des weiteren müssen unsere Keys und CAs in diese Konfigurationsdatei eingetragen werden. Da MacOS-X ein Unix-Betriebssystem ist, existiert dort der User und die Gruppe "nobody", unter dessen Account OpenVPN laufen soll. Dazu müssen die entsprechenden Stellen in der Konfigurationsdatei gefunden und geändert werden:

cipher AES-256-CBC

dev tun

proto udp

port 443

ca /etc/openVPN/ca.crt
cert /etc/openVPN/server.crt
key /etc/openVPN/server.key  # This file should be kept secret

dh /etc/openVPN/dh2048.pem

push "route 100.8.0.1 255.255.255.0"

user nobody
group nobody

Die Werte

cipher AES-256-CBC

dev tun

proto udp

port 443

sollte man sich notieren, da man diese auf dem Client genauso konfigurieren muss. Evtl. kann man gleich die Server-Konfiguration als Referenz auf dem USB-Stick ablegen.

Nun kann man testweise den OpenVPN-Server starten:

sudo openvpn /etc/openVPN/server.conf

Der Server sollte sich, wenn alles richtig konfiguriert ist, wie folgt melden:

"Initialization Sequence Completed"

Damit das Routing richtig funktioniert, muss man unter MacOS-X noch die Datei "/etc/hostconfig" bearbeiten:

sudo vi /etc/hostconfig

Dort fügt man einen Eintrag hinzu und startet den Rechner neu:

IPFORWARDING=YES

Der Name des eigenen Servers sollte über das Internet auflösbar sein. Also sollte man auf dem Server DynDNS ö.ä. verwenden. DynDNS lässt sich in den meisten DSL-Routern einstellen. Bitte dafür einfach mal auf der Konfigurations-Oberfäche des eigenen Routers herumspielen, bis es funktioniert. Außerdem muss der HTTPS-Port 443 auf den eigenen Rechner geforwardet werden. Auch das muss in der Router-Konfiguratione eingerichtet werden. Der Menüpunkt dafür heißt meist Virtueller Server o.ä.. Schließlich muss der HTTPS-Port noch in der MacOS-X-Firewall freigeschaltet werden.

OpenVPN lässt sich z.B. mit Lingon als Autostart-Item einrichten. Alternativ lässt sich auch ein Startup-Item unter "/Library/StartupItems/openvpn" anlegen und ein Start-Script dort erstellen:

openvpn:

#!/bin/sh

##
# OpenVPN-Server
##


. /etc/rc.common

StartService()
{
                ConsoleMessage "Starting OpenVPN-Server"
                /usr/local/sbin/openvpn --daemon --cd /etc/openVPN \
                        --config /etc/openVPN/server.conf \
                        --writepid /var/run/openvpn.pid
}

StopService()
{
        pid=$(GetPID openvpn)   
        if [ $? = 0 ]; then
                ConsoleMessage "Stopping OpenVPN-Server"
                kill -TERM "${pid}"
        fi
}


RestartService () { StopService; StartService; }

RunService "$1"

StartupParameters.plist:

<plist version="1.0">
<dict>
        <key>Description</key>
        <string>openvpn</string>
        <key>Provides</key>
        <array>
                <string>openvpn</string>
        </array>
        <key>Requires</key>
        <array>
                <string>Network Configuration</string>
                <string>tun</string>
        </array>
        <key>Uses</key>
        <array>
                <string>IPServices</string>
        </array>
</dict>
</plist>

Damit ist der OpenVPN-Server eingerichtet. Im zweiten Teil dieses HOWTOs (http://simonox.blogspot.com/2007/11/howto-openvpn-unter-apple-macos-x-als.html)wird der Client mit dem Server verbunden.

Blog Action Day

Umweltschutz ;-)

Blog Action Day

Frattinizer.js auf Spreeblick

Der für Sicherheit, Freiheit und Recht zuständige EU-Kommissar Franco Frattini schlägt vor, Wörter wie Bombe, Töten, Genozid oder Terrorismus aus dem Internet zu verbannen. Damit will er verhindern, dass Terroristen Bombenbauanleitungen aus dem Internet herunterladen. Eine Einschränkung der Meinungsfreiheit sieht der Kommissar darin nicht - wer „Bombe“ tippt, will wohl auch Bomben bauen.

Mehr: http://www.spreeblick.com/2007/09/15/bombenidee/

Blog Action Day

Am 15. Oktoper ist Blog Action Day: http://blogactionday.org

Mit dem Mac-Adressbuch auf GMail-Adressen zugreifen

Die Installation von GCalDaemon habe ich bereits im Post http://simonox.blogspot.com/2007/08/ical-mit-google-ber-das-opensource-tool.html beschrieben. Bevor man die folgenden Schritte unternehmen kann, muss man vorher diese Installation durchgeführt haben.

Nun ist der nächste Schritt mit dem Mac-Adressbuch auf die in GMail gespeicherten Kontakte zuzugreifen.

Dazu bearbeite ich wieder im conf-Verzeichnis von GCalDaemon die Konfigurationsdatei:

cd /Applications/GCALDaemon/conf
vi gcal-daemon.cfg


Folgende Properties passe ich dazu an, wobei spamme@gmail.com durch die eigene GMail-Adresse und das Passwort durch das eigene generierte Passwort zu ersetzen ist, das sich bereits in dieser Datei an einer anderen Stelle befinden sollte:

# Enable LDAP server
ldap.enabled=true

# Port of the LDAP server (default is "9080")
ldap.port=9080

# Gmail user (your full email address)
ldap.google.username=spamme@gmail.com

# Gmail password (use password encoder!)
ldap.google.password=XXXXXXXXXXXXXXXXXXX


Über Lingon (oder die Aktivitäts-Anzeige, der Prozess heißt "java") stoppe ich den bereits gestarteten GCalDaemon und rufe ihn testweise wieder über die Kommandozeile auf:

cd /Applications/GCALDaemon/bin
./standalone-start.sh


GCalDaemon sollte sich wie folgt melden:

INFO | GCALDaemon V1.0 beta 13e starting...
INFO | RSS/ATOM feed converter enabled.
INFO | Local time zone is Zentraleurop?ische Zeit.
INFO | HTTP server starting on port 9090...
INFO | HTTP server started successfully.
INFO | Start listening file /Users/spamme/Library/Application Support/iCal/Sources/770D9C33-FD94-41A1-8257-CF84AB7313F7.calendar/corestorage.ics...
INFO | File listener started successfully.
INFO | Offline file synchronization enabled.
INFO | LDAP server starting on port 9080...
INFO | LDAP server started successfully.
INFO | Gmail notifier disabled.
INFO | Sendmail service disabled.
INFO | Mail terminal disabled.


Neu ist die Zeile, dass ein LDAP-Server auf dem Port 9080 gestartet wurde.

Nun ist es Zeit, das Adressbuch zu öffnen:

open /Applications/Address\ Book.app


Unter Adressbuch -> Einstellungen -> LDAP kann man nun ein neues LDAP-Verzeichnis hinzufügen (vorher ein Backup des bereits existierenden Adressbuch erstellen, obwohl dem Adressbuch eigentlich nichts passieren sollte!).

Als Name trage ich "GCalDaemon" ein, unter Server "localhost", unter Port "9080".

Nun kann man das GMail-Adressbuch auch mit dem Mac-Adressbuch durchsuchen und per Mac-Mail auch Adressen aus dem GMail-Adressbuch verwenden.

Den GCalDaemon stoppe ich nun wieder (Ctrl+C) und aktiviere ihn mit Lingon erneut.

iCal mit Google über das OpenSource-Tool GCalDaemon synchronisieren

GCalDaemon ist eine Anwendung um iCal-kompatible Kalenderprogramme (z.B. iCal auf MacOS) mit dem Google Calendar zu synchronisieren.

Die Software gibt es für Linux, MacOS und Windows. Im folgenden möchte ich nur auf die Installation unter MacOS eingehen.

Wichtig ist, dass bei der unten beschrieben Installation ein MacOS-Kalender einen Google-Kalender zunächst überschreibt. In Goolge Calendar kann man mehrere Kalender einrichten. Darum sollte man in Goolge Calender zunächst ein SyncCalendar eingerichtet werden, der dann mit einem SyncCalendar auf MacOS-Seite synchronisiert werden kann. Sonst verliert man all seine Termin (ich fand dies beim Rumexperimentieren mehr als ärgerlich).

Nach der Installation kann man beide Kalender verwenden. Diese synchronisieren sich dann gegenseitig.

Den GCalDemon lädt man unter http://gcaldaemon.sourceforge.net/ herunter und entpackt ihn lokal auf den Desktop. Dauerhaft legt man ihn auf dem eigenen Rechner am besten im Anwendungsordner '/Applications' ab. Der eigene Nutzername wird hier mit "SpamMe" angegeben. Statt "SpamMe" ist natürlich der eigene Benutzerkurzname einzutragen:

cp -r /Users/SpamMe/Desktop/gcaldaemon-linux-1.0-beta13\ Folder/GCALDaemon /Applications


Nun sollte unter /Applications der Demon liegen. Dies lässt sich einfach überprüfen:



ls /Applications/GCALDaemon/


Nun wechselt man in dieses Verzeichnis und überprüft zuerst den Passwort-Encoder:

cd /Applications/GCALDaemon/bin
./password-encoder.sh


Ein Input-Prompt fragt nun nach dem Google-Passwort, dass man eingeben sollte:

Original password: XXXXXXX
Encoded password: XXXXXXXXXXXXXXX

Sample configuration options for GCALDaemon:

file.google.password=XXXXXXXXXXXXXXX
ldap.google.password=XXXXXXXXXXXXXXX

notifier.google.password=XXXXXXXXXXXXXXX
sendmail.google.password=XXXXXXXXXXXXXXX
mailterm.google.password=XXXXXXXXXXXXXXX


Das generierte Passwort sollte man sich - z.B. über die Zwischenablage - merken!

Unter MacOS verwende ich iCal als Kalender-Anwendung. Also wechsele ich nun in den iCal-Ordner,
starte iCal und erstelle dort einen neuen Kalender "GCalDaemon" oder "SyncCalendar":

open Library/Application\ Support/iCal/Sources/
open -a iCal


Der Backslash ist auf einer Apple-Tastatur übrigens auf Shift+Alt+7 ;-)

Den neu erstellen Kalender kann ich am Datum erkennen.

ls -Sc


In meinem Fall ist dies der Kalender mit dem kryptischen Dateinamen 770D9C33-FD94-41A1-8257-CF84AB7313F7.calendar.

Also wechsele ich ich das Verzeichnis des neuen Kalenders, um mich zu versichern, dass dies auch wirklich der neue Kalender ist:

cd 770D9C33-FD94-41A1-8257-CF84AB7313F7.calendar
less Info.plist


In dieser XML-Datei kann ich sehen, dass dies wirklich der neu erstellte Kalender ist:

<plist version="1.0">
<dict>
        <key>Key</key>
        <string>770D9C33-FD94-41A1-8257-CF84AB7313F7</string>
        <key>Title</key>
        <string>GCalDaemon</string>
        <key>Type</key>
        <string>com.apple.ical.sources.naivereadwrite</string>
</dict>
</plist>

GCalDaemon erwartet, dass unter dem conf-Verzeichnis Einstellungen vorgenommen werden. Eine dieser Einstellungen ist, dass man ein - wenn auch verschlüsseltes - Passwort einträgt. Dies ist fast schon ein Bug der Anwendung. Eine solche Information gehört nicht in das für jeden lesbare Application-Verzeichnis. Als Workaround schlage ich folgendes vor: ich verschiebe den conf-Ordner in mein Home-Verzeichnis und erstelle anschließend einen symbolischen Link auf mein Home-Verzeichnis im GCalDaemon-Verzeichnis:

cd /Applications/GCALDaemon
mv conf ~/.GCalDaemon
ln -s ~/.GCalDaemon conf


Auch das Log-Verzeichnis gehört eigentlich nicht in den Applikations-Ordner. Also verschiebe ich dieses Verzeichnis mit dem gleichen Workaround:

cd /Applications/GCALDaemon
sudo mv log /var/log/GCalDaemon
ln -s /var/log/GCalDaemon log


Ob die beiden symbolischen Links erstellt wurden, kann man einfach überprüfen:

cd /Applications/GCALDaemon
ls -l


Den oben ermittelten Kalender trage ich nun in die Konfigurations-Datei des GCalDaemons ein:

cd /Applications/GCALDaemon/conf
vi gcal-daemon.cfg


Unter file.ical.path trage ich die neu erstellte Kalender-Datei corestorage.ics im neu erstellten Kalender 770D9C33-7-CF84AB7313F7.calendar ein. Wichtig ist hier die komplette Pfadangame. Kalender-Name und Nutzerkurzname sind natürlich anzupassen:

file.ical.path=/Users/SpamMe/Library/Application Support/iCal/Sources/770D9C33-7-CF84AB7313F7.calendar/corestorage.ics


Das vorhin erzeugte Passwort (XXXXXXXXXXXXX) trage ich unter file.google.password ein:

file.google.password=XXXXXXXXXXXXXXXXXX


Meine GMail-Adresse trage ich file.google.username unter ein

file.google.username=spamme@gmail.com


Im Goolge-Kalender sollte man spätestens jetzt wie oben bereits beschrieben einen NEUEN Kalender anlegen ("z.B. SyncCalender"), da der GCalDaemon sonst die bereits vorhandenen Termine überschreibt!

Unter https://www.google.com/calendar/render kann man eine unter Einstellungen -> Kalender -> Privatadresse über das Kontextmenü auf das iCal-Icon eine iCal-URL in die Zwischenablage kopieren. Diese URL
http://www.google.com/calendar/ical/spamme%40gmail.com/private-XXXXXXXXXXXXXXXXXXX/basic.ics trage ich unter file.private.ical.url ein:

file.private.ical.url=/calendar/ical/spamme%40gmail.com/private-XXXXXXXXXXXXXXXXXXX/basic.ics


Die Zeile file.enabled setze ich auf true:

file.enabled=true


Nun kann ich den GCalDaemon starten:

cd ../bin
./standalone-start.sh


Der GCalDaemon sollte erfolgreich starten:


INFO | GCALDaemon V1.0 beta 13e starting...
INFO | RSS/ATOM feed converter enabled.
INFO | Local time zone is Zentraleurop?ische Zeit.
INFO | HTTP server starting on port 9090...
INFO | HTTP server started successfully.
INFO | Start listening file /Users/SpamMe/Library/Application Support/iCal/Sources/770D9C33-FD94-41A1-8257-CF84AB7313F7.calendar/corestorage.ics...
INFO | File listener started successfully.
INFO | Offline file synchronization enabled.
INFO | LDAP server disabled.
INFO | Gmail notifier disabled.
INFO | Sendmail service disabled.
INFO | Mail terminal disabled.


In iCal erstelle ich nun einen Testeintrag (z.B. morgen) und warte ab, ob dieser nach einiger Zeit im Google-Kalender erscheint und umgekehrt.

Wer nicht warten möchte kann eine Synchronisation auch sofort testen:

cd /Applications/GCALDaemon/bin
./sync-now.sh


Wenn der in GCal erstellte Termin nun im Google-Kalender erscheint, kann man mit der Anwendung "Lingon" (http://lingon.sourceforge.net/) den GCalDaemon als Startup-Item eintragen.

Ich starte Lingon, wähle "Assistant" in der Button-Leiste, wähle "Run a job at startup", vergebe als Label "GCalDaemon", aktiviere, dass der Job nur startet, wenn ich einlogt bin und trage als Job "/Applications/GCALDaemon/bin/standalone-start.sh" ein.

Tipp: Da es sich bei GCalDaemon um eine Java-Anwendung handelt, findet man GCalDaemon in der Aktivitäts-Anzeige NICHT unter GCalDaemon oder standalone-start.sh sondern unter "java".

Nun wird mein Google Calendar regelmäßig mit meinem iCal-Kalender synchronisiert.

Web 2.0 U-Bahn-Plan

Ich mag Informationsgrafiken, besonders U-Bahn-Pläne. Gleichgesinnte aus Japan haben einen Web 2.0 U-Bahn-Plan erstellt. Wirklich sehr gelungen: http://www.informationarchitects.jp/ia-trendmap-2007v2#more-403

http://www.informationarchitects.jp/slash/google_trend_2007.gif

Ich möchte das Blog an dieser Stelle nutzen, um einen Text weiterzuleiten:

Kick the Corruption Out of the BBC!

Today the BBC made it official—they have been corrupted by Microsoft. With today's launch of the iPlayer, the BBC Trust has failed in its most basic of duties and handed over to Microsoft sole control of the on-line distribution of BBC programming. From today, you will need to own a Microsoft operating system to view BBC programming on the web. And you must accept the Digital Restrictions Management (DRM) that the iPlayer imposes.

Read the story about the corruption of the BBC:
http://defectivebydesign.org/sites/nodrm.civicactions.net/modules/civicrm/extern/url.php?q=266275&u=346

Digg this story! http://defectivebydesign.org/sites/nodrm.civicactions.net/modules/civicrm/extern/url.php?q=266275&u=347

Join us in London on August 14th as we continue the fight against DRM and kick the corruption out of the BBC. Sign up now! -- August 14th, London at the BBC Television Centre.

In solidarity,
Josh, John, Peter and the DRM Elimination Crew.

iSync

Mit dem Update auf das neue Apple iSync Version 2.4 (501.2) hat iSync aufgehört, sich mit meinem K750i zu synchronisieren. Dabei galten Sony-Mobiltelefone bisher als "Mac"-Handies.

Im Apfeltalk-Forum stieß ich auf folgenden Tipp:

Im Finder auf das Programm iSync einen Rechts-Click (ctrl + Click) machen und auf Paketinhalt zeigen gehen. Dann durch diesen Pfad klicken:

/Contents/PlugIns/ApplePhoneConduit.syncdevice/Contents/PlugIns/PhoneModelsSync.phoneplugin/Contents/Resources

und dann die Datei MetaClasses.plist per Doppelklick öffnen. Dann links neben dem Root auf den Pfeil klicken, dann den Eintrag com.sony-ericsson.K700 suchen und den Pfeil links danben wieder anklicken. Dann unter InheritsForm den Eintrag auf "family.com.sony-ericsson.legacy" ändern (Ohne (!) die Anführungsstriche). Dann das über File Save speichern und dann schließen. Jetzt iSync starten und der Sync klappt wieder

Danach ließen sich zwar Termine nicht mehr synchronisieren. Allerdings hat das Synchronisieren von Kontakten wieder funktioniert.... scheinbar.

Anschließend waren nämlich alle Adressen weg. Nur noch die Telefonnummern waren vorhanden. Allerdings waren die Adressen noch auf einem iPod gesichert.

Also konnte ich den iPod an einen anderen Mac anschließen (automatische Synchronisation mit iTunes etc. war damit disabled).

Im Festplatten-Modus konnte ich die Datei iSync.vcf im Ordner “contacts” auf einen USB-Stick sichern.

Im Adressbuch meines Macs konnte ich die Datei dann importieren.

Seitdem funktioniert nicht nur das Synchronisieren von Kontakten wieder, auch der Kalender lässt sich synchronisieren, wenn man die Option "Ereignisse ignorieren, älter als 'Heute'" auswählt.

Ein weiters Problem: iTuneMyWalkman bricht manchmal die Synchronsiation richtig großer Podcasts (Videos wie der Elektrische Reporter oder den Podcast des FSK Sunday Service) ab und man hat Dateien von 0 Byte Größe auf der SD Card, die sich natürlich nicht abspielen lassen. Das Problem werde ich aber heute nicht mehr fixen ;-)

An open letter to Steve Jobs

Layout dieses Blogs - E-Mail-Bloging

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Wer sich über das Layout des letzten Postings wundert:

Ich bin seit einiger Zeit hinter einer ziemlich fiesen Firewall, die
ich auch - aus beruflichen Gründen - nicht hacken möchte. Außerdem
hat Google meinen Blogger-Account migriert. Im Moment kenne ich noch
kein Plugin, mit dem man auf dem migrierten Blogger-Acount blogen
könnte. Was spricht der überhaupt?

Darum gehe ich jetzt dazu über, per E-Mail zu blogen. E-Mail finde
ich übrigens immer besser. Z.B. fülle ich auch meine BackPack-To-Do-
Liste nur noch per E-Mail. Einfach eine Mail mit dem Betreff "to-do"
an meine Backpackit-Adresse schicken und der Content ist in meiner To-
Do-Liste. Perfekt und schnörkellos :-)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)

iD8DBQFF+GFkZf4PRw/GKLgRArsyAJ9CRXVqnM3rsFNIY7SLpYjcRFuprACfYqGr
6t7BvDiKZdljZ1DrtkrgpFM=
=8G8h
-----END PGP SIGNATURE-----

Audium -> Mabber -> Twitter

Ich habe heute Audium, Twitter und Mabber ausprobiert.

Mabber ist ein Jabber-Client, der außerdem noch für weitere Protokolle
ein Gatway anbietet. So kann man über Mabber auch an ICQ-Kontakte
senden. Außerdem gibt's für Mabber einen JavaClient fürs Mobile. So kann
man statt über SMS auch über IM kommunizieren.

Twitter ist das Aequivalent zum wall-Befehl unter Linux. Man schickt
eine
Message und auf der Wall erscheint, was man geschickt hat. Meistens
schickt man einfach, _was_ man gerade macht. Nicht besondern sinnvoll,
aber nett.

Allerdings kann man über Jabber an Twitter@twitter.com eine Message
senden. Das macht die Sache interessant.

Twitter hat zwar auch eine SMS-Funktion, diese funktioniert aber nur
über eine teuere, internationale Rufnummer.

Wenn man nun aber Twitter mit Mabber verknüpft, dann kann man auch
günstig twittern :-)

Audium ein - zugegeben feiner - Multiprotokoll-IM-Client für MacOS.
Sieht gut aus und _funktioniert_.