re:oyd (17): Baikal 0.4.6@Raspberry Pi an Unitymedia Connect Box mit IPv6

matriochkaWarum sollte man alle seine Termine und die Adressen, Telefonnummern und Geburtstage seiner Bekannten irgendeinem Konzern frei Haus liefern? Das sollte man natürlich nicht. Besser sind solche Daten auf dem eigenen Server Zuhause aufgehoben. Und selbst wenn man die Daten mit Notebook und Smartphone abgleichen will, braucht es dafür keinen Hightech-Server – ein Raspberry Pi und der CardDAV / CalDAV Server Baikal machen es möglich.

Ich gehe im Folgenden einfach mal davon aus, dass der Raspberry Pi schon mit Raspbian läuft.

Große Einschränkung vorweg: Mit der folgenden Einrichtung ist der Raspberry Pi nur aus IPv6 Netzen heraus erreichbar (also nicht über noch auf IPv4 setzende Mobilfunknetze oder eduroam).

1. IPv6 Portweiterleitung an der Unitymedia Connect Box

Damit unser Server auch von außen erreichbar ist, muss bei der Connect Box das Port Forwarding auf die IPv6 Adresse des Raspberry Pi eingerichtet werden. Dafür muss das Administrationsmenü der Connect Box über den Browser aufgerufen werden (etwa durch http://192.168.0.1). Zunächst rufen wir in der  linken Seitenleiste unter „Erweiterte Einstellungen“ den Punkt „DHCP“ auf. Wenn man nach unten scrollt erscheint die Überschrift „Reservierte IP Adressen“. Hier setzen wir in der Tabellenzelle einen Haken/Punkt vor dem Raspberry Pi. Damit wird automatisch dessen MAC Adresse unter „Reservierte Regel hinzufügen“ eingesetzt. Jetzt noch die IP Adresse festlegen (etwa 192.168.0.10) und auf „Regel hinzufügen“ und dann „Änderungen übernehmen“ klicken.

Ebenfalls in der Tabelle unter „Reservierte IP Adressen“ finden wir in der Zeile des Raspberry Pi in der Spalte „IP Adresse“ dessen IPv6 Adresse in der Form 1111:111:1111:111:1111:1111:1111:1111. Diese kopieren wir uns. Jetzt rufen wir in der  linken Seitenleiste unter „Erweiterte Einstellungen“ den Punkt „Sicherheit“ und dort den Unterpunkt „IP und Port Filter“ auf. Unter dem Punkt „IPv6 Port Filter“ muss „Eingehend“ angehakt sein. Dann auf „Eine neue Regel erstellen“ klicken. Im folgenden Fenster muss „Aktiviert“ und Traffic policy „Ja“ angehakt sein. Als Protokoll wählen wir „TCP“ aus, als Quell IP-Adresse „Alle“ und als Ziel IP-Adresse „Single“. Im das aufgehenden Feld „IPv6 Adresse“ kopieren wir die IPv6 Adresse des Raspberry Pi. Die Quell Port Range stellen wir auf „Manuell“, Start auf „80“, Ende auf „80“ – das gleiche für die Ziel Port Range. Zum Abschluss auf „Regel hinzufügen“ klicken. Im Hauptfenster von IP und Port Filter dann noch auf „Änderungen übernehmen“ klicken. Jetzt wiederholen wir das ganz und fügen eine zweite Regel hinzu, nur das alle Port Wert statt 80 jetzt 433 lauten. Danach sollten alle HTTP und HTTPS Anfragen von Außen an den Raspberry Pi durchgereicht werden.

2. DNS – Domain für Weiterleitung auf IPv6 Adresse einrichten

Theoretisch ist der später auf dem Raspberry Pi laufende Webserver auch allein über die IPv6 Adresse von außen erreichbar (also bspw. mit „http://[1111:111:1111:111:1111:1111:1111:1111]/index.php“ im Browser aufrufbar). Aber kaum jemand möchte sich wohl die lange IPv6 Adresse merken. Außerdem funktioniert der Aufruf zwar im Browser, wenn man die Adresse für die Verbindung zum CalDav/CardDav etwa unter macOS für Kontakte und Kalender nutzen möchte, akzeptieren die Appel Programme eine solche Adresse nicht als Serveradresse. Daher brauchen wir noch eine Domain, die auf die IPv6 Adresse verweist. Kostenlos gibt es die etwa bei freedns.afraid.org. Einfach auf der Seite einen Account anlegen. Dann im linken Menü auf „Subdomains“ klicken und eine neue Subdomain anlegen und mit der kopierten IPv6 Adresse verknüpfen. Dafür muss im Formular der Type auf „AAAA“ geändert werden. Dann noch einen Namen für die Subdomain eintragen (im Folgenden „SUB“) und die Domain auswählen (im Folgenden „DOMAIN.XYZ“). Als Destination wird dann die IPv6 Adresse des Raspberry eingetragen, das Captcha gelöst und auf „Save!“ geklickt. ACHTUNG: Bis der Raspberry Pi tatsächlich über SUB.DOMAIN.XYZ erreichbar ist, kann es einige Zeit – bis zu mehreren Stunden – dauern.

3. Webserver installieren und SSL Verschlüsselung einrichten

Jetzt brauchen wir zur Vorbereitung nur den schnellen, kleinen Webserver nginx, die Scriptsprache php und sqlite als ressourcensparende Datenbank installiert. Dafür melden wir uns zunächst mittels ssh auf dem Raspberry Pi an (etwa mit „ssh pi@192.168.0.10“) und rufen dann folgenden Befehl auf:

sudo apt-get install nginx php5 php5-fpm php-pear php5-common php5-mcrypt php5-mysql php5-cli php5-gd sqlite php5-sqlite

Bevor wir den Webserver starten, sind noch zwei Einstellungen anzupassen, damit er auf dem nicht ganz so potenten Raspberry Pi anständiger läuft: in der Daten „/etc/nginx/nginx.conf“ reduzieren wir die Zahl der „worker_processes“ von 4 auf 1 und die der „worker_connections“ von 768 auf 128.
Damit wir später unsere wertvollen Daten nicht ungesichert durchs Netz schicken – sonst hätten wir nicht viel gewonnen – , muss die Datenübermittlung mittels SSL gesichert werden. Dafür erzeugen wir uns nun zunächst ein eigenes Zertifikat mit entsprechendem Schlüssel, indem wir folgende Befehle hintereinander ausführen:

sudo mkdir /etc/nginx/ssl
cd /etc/nginx/ssl
sudo openssl genrsa -out baikal.key 4096
sudo openssl req -new -sha256 -key baikal.key -out baikal.csr

Jetzt signieren wir das Zertifikat noch selber (daher moniert der Browser später auch unser Zertifikat, weil es nicht von einer „vertrauenswürdigen“ Institution signiert wurde – wir können ihm aber trotzdem beibringen, das Zertifikat dauerhaft zu akzeptieren). Bei den Abfragen braucht nur bei „Country Name“ „DE“ für Deutschland und bei „Common Name“ einfach SUB.DOMAIN.XYZ eingeben (oder wenn man keine will die IPv6 Adresse des Raspberry Pi).

sudo openssl x509 -req -sha256 -days 3650 -in baikal.csr -signkey baikal.key -out baikal.crt

Jetzt geht es daran, nginx richtig einzustellen, damit der Webserver unser Zertifikat kennt, die Verbindung immer verschlüsselt hergestellt und php genutzt wird. Dazu passen wir die Datei „/etc/nginx/sites-available/default“ wie folgt an:

server { 
    listen 80; 
    listen [::]:80 ipv6only=on;
    server_name SUB.DOMAIN.XYZ; # die IPv6Adresse muss in eckigen Klammern stehen, wenn der Domainname verwendet wird, keine Klammern benutzen
    rewrite ^ https://$server_name$request_uri? permanent; # immer https verwenden 
}
 
server {
    listen 443 ssl; 
    listen [::]:443 ssl ipv6only=on; 
    server_name SUB.DOMAIN.XYZ; # die IPv6Adresse muss in eckigen Klammern stehen, wenn der Domainname verwendet wird, keine Klammern benutzen
    ssl_certificate /etc/nginx/ssl/baikal.crt;  # unsere Zertifikat benutzen
    ssl_certificate_key /etc/nginx/ssl/baikal.key; # unseren Schlüssel benutzen

        root /var/www;
        index index.html index.htm index.php;

        location / {
                # First attempt to serve request as file, then
                # as directory, then fall back to displaying a 404.
                try_files $uri $uri/ /index.html;
                # Uncomment to enable naxsi on this location
                # include /etc/nginx/naxsi.rules
        }

        location /doc/ {
                alias /usr/share/doc/;
                autoindex on;
                allow 127.0.0.1;
                allow ::1;
                deny all;
        }

    location ~ ^(.+.php)(.*)$ { # damit PHP richtig genutzt wird
        try_files $fastcgi_script_name =404;
        fastcgi_split_path_info  ^(.+.php)(.*)$;
        fastcgi_pass   unix:/var/run/php5-fpm.sock;
        fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
        fastcgi_param  PATH_INFO        $fastcgi_path_info;
        include        /etc/nginx/fastcgi_params;
    }

    rewrite ^/.well-known/caldav /baikal/html/dav.php redirect;
    rewrite ^/.well-known/carddav /baikal/html/dav.php redirect;

    charset utf-8;

    location ~ /(.ht|Core|Specific) {
        deny all;
        return 404;
    }
}

Damit unsere Änderungen auch angenommen werden, starten wir alles neu:

sudo /etc/init.d/nginx restart
sudo /etc/init.d/php5-fpm restart

4. Baikal installieren

Als nächstes bereiten wir die Installation von Baikal vor (die aktuellste Fassung findet ihr unter https://github.com/fruux/Baikal/releases):

cd /var/www
sudo wget https://github.com/fruux/Baikal/releases/download/0.4.6/baikal-0.4.6.zip
sudo unzip baikal-*.zip
sudo rm baikal-*.zip
sudo chown -R www-data:www-data baikal/
cd baikal
sudo touch Specific/ENABLE_INSTALL
sudo chmod 755 Specific/
sudo chmod 755 Specific/db/

Um Baikal nutzen zu können, braucht der CalDAV / CardDAV Server jetzt nur noch unter „https://[IPv6Adresse]/baikal/html/admin/install/“ bzw. „https://SUB.DOMAIN.XYZ/baikal/html/admin/install/“ installiert werden. Damit unter Windows 10 die Anmeldung funktioniert, muss bei den Einstellung „WebDAV authentification type“ auf „Basic“ gestellt werden (außerdem muss beim Anlegen des Benutzers eine Mail-Adresse als Benutzername verwendet werden).

Nach Installation und der Einrichtung der Benutzer, Kalender und Telefonbücher können diese in den entsprechenden Programmen genutzt werden:
CalDav/CardDav (allgemein):

https://SUB.DOMAIN.XYZ/baikal/html/dav.php/calendars/BENUTZER/KALENDER/
https://SUB.DOMAIN.XYZ/baikal/html/dav.php/addressbooks/BENUTZER/TELEFONBUCH/

CalDav/CardDav (für iOS/macOS):

https://SUB.DOMAIN.XYZ/baikal/html/dav.php/principals/BENUTZER/

Weiterführende Links und Dank an:
Jan Karres
Andrew Oberstar
ruhezustand.net

---
Beitrag interessant? Ich freue mich über einen Kauf bei Amazon*.

re:oyd (15): Datensparsamkeit

Den Datenschutz verbessern und gegen Überwachung vorgehen ist das ein – sein eigenes Verhalten ändern das andere. Datensparsamkeit ist hier ein Stichwort. Wobei ich vorneweg feststellen will: ich möchte hier keinesfalls einer Selbstbeschränkung das Wort reden – sie kann und darf genauso wenig eine Antwort auf Datenmissbrauch und Überwachung sein wie Selbstzensur. Aber ein intelligenter Umgang mit den eigenen Daten und der Versuch, das Datenaufkommen die eigene Person und Persönlichkeit betreffend zu minimieren, ist oft möglich, ohne sich über ein erträgliches Maß hinaus einschränken zu müssen.
Hier also ein paar, eigentlich ganz einfache – und vielfach wohl auch bekannte, dann aber doch aus Faulheit/Gewohnheit/etc. häufig ignorierte – Punkte, die mir gerade so einfallen:

Zunächst aber noch etwas Allgemeines vorweg:

Im Kapitalismus/ in der Marktwirtschaft…
… verschenkt normalerweise niemand etwas. Daraus folgt erstens: die Teilnahme an einem Gewinnspiel beschert mir vielleicht die verschwindend geringe Chance, tatsächlich etwas zu gewinnen – sie bringt dem Anbieter aber auf jeden Fall meine Daten/Anschrift und vielleicht auch gleichzeitig noch die Einwillig zu Werbebombardements ein. Es folgt zweitens: auch Google und andere Unternehmen haben nichts zu verschenken. Die Nutzung von Google Mail, Search usw. ist nur vordergründig „kostenfrei/kostenlos“ – denn wir bezahlen sie mit unseren Daten. Daraus folgt drittens: auch wir sollten unsere Daten nicht verschenken. Daher wäre es angebracht, dass wir uns um Datenschutz und Datensparsamkeit bemühen oder meinetwegen auch darum, dass wir von den Unternehmen, die unsere Daten nutzen wollen, dafür fürstlich (oder zumindest anständig) bezahlt werden. Was natürlich nur geht, wenn wir die Hoheit über unsere Daten haben.

An der Kasse:

  1. „Haben Sie eine PayBack-/Deutschland-/Kundenkarte?“
    „Nein, ich habe keine solche Karte und will auch keine haben.“ Anfangen könnte man damit, mal darüber nachdenken, ob ein paar Bonuspunkte bzw. ein Rabatt von ein bis zwei Prozent tatsächlich die Selbstbeschränkung (den Besuch der immer gleichen Einzelhandelsunternehmen) rechtfertigen. Aber vor allem sollte man sich fragen, ob man seine Konsumdaten wirklich für diesen lächerlichen Rabatt „verkaufen“ will. 2014 wurde ein Umsatz von 23 Mrd. Euro in Deutschland über PayBack erfasst. Im gleichen Jahr hat PayBack Punkte im Umfang von 275 Mio. Euro ausgegeben. Bei über 20 Mio. aktiven Kunden verkaufen diese ihre Jahresdaten im Durchschnitt also für kaum mehr als 10 Euro. Man kann sich vorstellen, wieviel Gewinn dagegen bei PayBack hängen bleibt…
  2. „Dürfte ich Ihre Postleitzahl erfahren?“
    „Nein, dürfen Sie nicht.“ Nein sagen, hat rein gar nichts mit Unhöflichkeit zu tun! Mir fällt auch kein Grund ein, welchen Vorteil ich davon hätte, meine Postleitzahl an Geschäft XY weiterzugeben (außer man schließt die obige Antwort unter gegebenen Umständen mit „aber ich tausche Sie gerne gegen Ihre Telefonnummer“ ab…). Datensparsamkeit heißt, jede unnötigen Preisgabe von eigenen Daten zu vermeiden. Und eine Datenpreisgabe durch die Antwort auf die Frage nach der Postleitzahl ist sicherlich vermeidbar – und wesentlich konsequenter bzw. mehr Statement, als eine falsche Postleitzahl anzugeben.
  3. „Wie wollen Sie zahlen?“
    „Mit Bargeld.“ Wer bar bezahlt (EDIT: solange es noch geht…), kann ziemlich einfach vermeiden, dass unnötige Daten beim kartenausgebenden Institut darüber entstehen, wer, wo (und evtl. was) gekauft hat. Außerdem hat Barzahlung zwei positive Nebeneffekt: wenn ich bewusst in Abständen größere Geldmengen abhebe, habe ich erstens einen besseren Überblick über meine Ausgaben, als wenn ich bei jeder sich bietenden Gelegenheit die EC- oder Kreditkarte zücke. Zweitens ist erwiesen, dass das physikalische Weggeben von Geld viel schwerer fällt, als irgendwelche Nullen und Einsen von einem Konto auf ein anderes zu transferieren. Wer bar zahlt, konsumieren also überlegter und denken vielleicht eher mal darüber nach, ob er das in den Händen gehaltene Produkt überhaupt wirklich braucht. Ganz ohne EC- und Kreditkarte aus dem Haus zu gehen, bringt natürlich die potenzielle Möglichkeit mit sich, einmal nicht genug Geld dabei zu haben. Aber mal im Ernst, wie oft kaufen wir spontan unterwegs ein Auto oder ein Haus? Und überhaupt, man sollte ja sowieso nur mit einer Einkaufsliste shoppen gehen. Da sollte man ungefähr abschätzen können, wieviel Geld man voraussichtlich braucht.

Unterwegs mit dem Handy

  1. Wo bin ich?
    Am wenigsten Daten fallen natürlich an, wenn man das Handy einfach zuhause lässt oder es einfach mal ausschaltet. Vielleicht tut es dem einen oder anderen ja auch mal gut, wenn er nicht immer erreichbar ist (für den Arbeitgeber nach Feierabend/ in der Freizeit zum Beispiel). Wer aber tatsächlich wissen will, wo er gerade ist oder lang (fahren) muss, hat die Möglichkeit, sich nach einer offline funktionierenden Navigationsapp umzusehen, um nicht gleich alle Positions- und Zieldaten an die Server von Apple oder Google zu senden. Es gibt natürlich auch ganz altmodische Karten aus Papier… damit könnte man sogar ins Gespräch kommen, wenn man sich von „Einheimischen“ auf der Karte zeigen lässt, wo man lang muss.
  2. Nach Hause telefonieren
    Überhaupt sollte man sich mal Gedanken darüber machen, welche Apps so alltäglich auf unseren Smartphones laufen. Im Internet lässt sich mit ein bisschen suchen schnell feststellen, wie viele vermeintlich harmloser Programme (man denke nur an diverse Taschenlampen-Apps) unbegründeter Weise Daten (Adressbücher, Telefonnummern, Aufenthaltsort…) nach Hause senden. Dabei helfen nicht nur Google und Co mit, indem sie das Rechtsmanagement auf dem Handy nicht gerade einfach gestalten (oder Informationen einfach nicht anzeigen). Auch wir selber haben uns wohl in zu vielen Fällen daran gewöhnt, bei der Installation von Apps die eingeforderten Zugriffsrechte einfach abzunicken (und uns keine Gedanken darüber zu machen, warum App XY jetzt auch auf die Kontakte oder die Kamera zugreifen muss…).

Im Internet

  1. * Pflichtangaben
    Wer kennt es nicht? Wenn wir uns bei der Webseite XY anmelden wollen, müssen wir eine ganze Latte an privaten Details angeben. Bei jeder der Angaben (auch bei den Pflichtangaben) sollte man sich aber gut überlegen: braucht der Betreiber dieser Webseite diese Angabe wirklich? Wenn ich etwas bestellte, sollten Name, Anschrift und Bankverbindung wahrscheinlich schon stimmen. Aber braucht wirklich jemand mein Geburtsdatum auf den Tag genau, wenn ich eine neue Tastatur kaufen will? Aber nur weil etwas als Pflichtangabe markiert ist, heißt das ja noch lange nicht, dass man auch reale Daten eingeben muss… Bei Behördenseiten sieht das aber natürlich unter Umständen anders aus.
  2. Pseudonym/Benutzername
    Pseudonyme oder schlicht Benutzernamen sind eine feine Sache, wenn nicht jeder im Forum gleich wissen soll, wie ich mit richtigem Name heiße. Allerdings sollte man Pseudonyme und Anonymität nicht verwechseln. Das gilt nicht nur, weil die Betreiber von Webseiten durch die IP-Adresse natürlich über eine wichtige Voraussetzung zur Zuordnung von Pseudonym und realer Person verfügen. Vielmehr sollte man sich auch immer bewusst sein, dass es gefährlich ist, immer das gleiche Pseudonym zu verwenden. Wenn ich überall ChuckNorris1337 heiße, haben alle Webseite die auch über meinen Realnamen verfügen, wenig Probleme damit, ein umfassendes Internetprofil zu erstellen und mit meinem dort vorhandenen Kundenprofil zu verknüpfen (das gilt natürlich nicht weniger für alle Privatpersonen die mein Pseudonym kennen).
  3. Zum Suchen/Mailen/Shoppen/etc. nutze ich natürlich…
    … besser nicht immer nur die üblichen Verdächtigen. Statt alles über Google und Amazon zu machen, öfter mal über den Tellerrand schauen. Zum Suchen nicht einfach „googeln“, sondern zumindest eine anonymisierende (Meta)Suchmaschine benutzen (wie ixquick.de oder startpage.com. Schnell mal die Wegstrecke und Fahrdauer ausrechnen lassen? Statt Google Maps einfach mal openstreetmap.org benutzen. Email (mit eigener Domain sieht sowieso viel professioneller aus) über einen deutschen Hosting-Anbieter ist zwar Online leider nicht so komfortable wie Google Mail, aber im EMail-Programm mit IMAP sieht alles aus wie immer und niemand im Silicon Valley liest mit (was natürlich nur wirklich gilt, sofern du auch alle deine Freunde davon überzeugen kannst, Google den Rücken zu kehren). Und ob du es glaubst oder nicht, viele Produkte bekommt man tatsächlich noch im stationären Handeln und nicht nur auf Amazon – für diese Art der Datensparsamkeit kann es aber schon mal vorkommen, dass man etwas mehr bezahlen muss (dafür leistet man vielleicht sogar gleich einen Beitrag dafür, dass unsere Innenstädte nicht noch mehr verweisen). Und ja, auch in der Stadt muss es etwa beim Bücherkauf nicht immer Thalia oder Hugendubel sein – die kleinen, lokalen Händler werden es dir danken.
  4. Die richtigen Tools
    Um weniger Spuren während des Surfens durchs World Wide Web zu hinterlassen, sollte man auf die richtigen Tools setzen. Klar könnte man gleich Tor nutzen, aber ein Anfang ist ja schon mal gemacht, wenn man FireFox statt IE, Safari oder Chrome verwendet. Dann den Browser noch mit den richtigen Erweiterung in Form von AdBlocker, NoScript, HTTPS Everywhere und DoNotTrack/Ghostery weiter abschotten und man ist zumindest schon mal auf dem richtigen Weg (auch wenn sich nicht nur die Werbeindustrie mit Techniken wie Browser-Fingerpringing usw. immer neue Methoden der Useridentifikation einfallen lässt).

Was sagt uns das alles? Datensparsamkeit ist immer schon mal mit etwas Aufwand verbunden. Vielleicht macht es dem einen oder anderen aber ja sogar Spaß, eingefahrene Handlungsroutinen durch neues, überlegtes Vorgehen fit fürs digitale Zeitalter in der Post-Snowden-Ära zu machen.

---
Beitrag interessant? Ich freue mich über einen Kauf bei Amazon*.

re:oyd (14): Baikal@Raspberry Pi an Speedport W 724V

matriochkaAdressen und Termine zuhause auf dem eigenen Server speichern und mit Notebook und Smartphone abgleichen? Nichts leichter als das, mit einem Raspberry Pi und dem CardDAV / CalDAV Server Baikal.

Zur Vorbereitung muss zunächst der Webserver nginx, die Scriptsprache php und sqlite als Datenbank installiert werden.

sudo apt-get install nginx php5 php5-fpm php-pear php5-common php5-mcrypt php5-mysql php5-cli php5-gd sqlite php5-sqlite

Bevor wir den Webserver starten, sind noch zwei Einstellungen anzupassen, damit er auf dem nicht ganz so potenten Raspberry Pi auch anständig läuft: in der Daten „/etc/nginx/nginx.conf“ muss die Zahl der „worker_processes“ von 4 auf 1 und die der „worker_connections“ von 768 auf 128 reduziert werden.
Damit wir später unsere wertvollen Daten nicht ungesichert durchs Netz schicken, sollte die Datenübermittlung mittels SSL gesichert werden. Dafür erzeugen wir uns zunächst ein eigenes Zertifikat mit entsprechendem Schlüssel.

sudo mkdir /etc/nginx/ssl
cd /etc/nginx/ssl
sudo openssl genrsa -out baikal.key 4096
sudo openssl req -new -sha256 -key baikal.key -out baikal.csr

Jetzt signieren wir das Zertifikat noch selber (daher moniert der Browser später auch unser Zertifikat, weil es nicht von einer „vertrauenswürdigen“ Institution signiert wurde). Bei den Abfragen braucht nur bei „Country Name“ „DE“ für Deutschland und bei „Common Name“ die verwendete Dynamische DNS (DynDNS) (damit trotz wechselnder IP durch den Internetanbieter unser Server auch von außen erreichbar ist) wie etwa „abc.selfhost.xy“ angegeben werden.

sudo openssl x509 -req -sha256 -days 3650 -in baikal.csr -signkey baikal.key -out baikal.crt

Jetzt geht es daran, nginx richtig einzustellen, damit der Webserver unser Zertifikat kennt, die Verbindung immer verschlüsselt hergestellt und php genutzt wird. Dazu passen wir die Datei „/etc/nginx/sites-available/default“ an:

server { 
    listen 80; 
    listen [::]:80 ipv6only=on; # für den Fall, dass ihr schon ipv6 benutzt
    server_name abc.selfhost.xy; # alternativ kann zum Test auch die lokal IP 192.168.2.X genutzt werden
    rewrite ^ https://$server_name$request_uri? permanent; # immer https verwenden 
}
 
server {
    listen 443 ssl; 
    listen [::]:443 ssl ipv6only=on; # für den Fall, dass ihr schon ipv6 benutzt
    server_name abc.selfhost.xy; # alternativ kann zum Test auch die lokal IP 192.168.2.X genutzt werden
    ssl_certificate /etc/nginx/ssl/baikal.crt;  # unsere Zertifikat benutzen
    ssl_certificate_key /etc/nginx/ssl/baikal.key; # unseren Schlüssel benutzen

        root /usr/share/nginx/www;
        index index.html index.htm index.php;

        location / {
                # First attempt to serve request as file, then
                # as directory, then fall back to displaying a 404.
                try_files $uri $uri/ /index.html;
                # Uncomment to enable naxsi on this location
                # include /etc/nginx/naxsi.rules
        }

        location /doc/ {
                alias /usr/share/doc/;
                autoindex on;
                allow 127.0.0.1;
                allow ::1;
                deny all;
        }

    location ~ ^(.+.php)(.*)$ { # damit PHP richtig genutzt wird
        try_files $fastcgi_script_name =404;
        fastcgi_split_path_info  ^(.+.php)(.*)$;
        fastcgi_pass   unix:/var/run/php5-fpm.sock;
        fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
        fastcgi_param  PATH_INFO        $fastcgi_path_info;
        include        /etc/nginx/fastcgi_params;
    }

    rewrite ^/.well-known/caldav /baikal/cal.php redirect;
    rewrite ^/.well-known/carddav /baikal/card.php redirect;

    charset utf-8;

    location ~ /(.ht|Core|Specific) {
        deny all;
        return 404;
    }
}

Damit unsere Änderungen auch angenommen werden, starten wir alles neu:

sudo /etc/init.d/nginx restart
sudo /etc/init.d/php5-fpm restart

Als nächstes bereiten wir die Installation von Baikal vor (die aktuelle Fassung des „Flat package“ findet ihr unter http://baikal-server.com.

cd /usr/share/nginx/www
sudo wget http://baikal-server.com/get/baikal-flat-0.2.7.zip
sudo unzip baikal-flat-*.zip
sudo rm baikal-flat-*.zip
sudo mv baikal-flat/ baikal/
sudo chown -R www-data:www-data baikal/
sudo find baikal/ -type d -exec chmod 755 {} ;
cd baikal
sudo touch Specific/ENABLE_INSTALL
sudo chmod 755 Specific/
sudo chmod 755 Specific/db/
sudo chmod 755 Specific/db/db.sqlite

Damit unser Server auch von außen erreichbar ist, muss das Speedport W 724V entsprechend eingerichtet werden. Unter dem Punkt „Internet“ muss unter der Rubrik „Dynamisches DNS“ „Dynamisches DNS verwenden“ angehakt und die entsprechenden Zugangsdaten eingetragen werden. Anschließend muss unter der Rubrik „Portfreischaltung“ die TCP Port-Weiterleitung für 443-443 443-443 sowie 80-80 80-80 auf die IP (oder den vorher vergebenen Gerätenamen) des Raspberry Pi eingestellt werden.
Leider gibt es jetzt beim Speedport W 724V ein Problem: er kann kein NAT Loopback / Hairpin-NAT. Daher ist aus dem lokal Netzwerk unser Raspberry nicht über seine Dynamische DNS erreichbar, sondern nur über seine lokale IP. Für CalDAV und CardDAV, die sich ja wohl sowohl zuhause als auch von unterwegs synchronisieren sollen, ist das ein unhaltbarer Zustand. Eine einfache Lösung gibt es leider nicht. Da der Raspberry Pi aber ja sowieso immer läuft, gibt es einen Ausweg: wir nutzten diesen statt des Speedport als DNS-Server.
Dafür installieren wir DNS / DHCP Server dnsmasq:

sudo apt-get install dnsmasq

und passen anschließend die Datei „/etc/hosts“ folgendermaßen an:

127.0.0.1       localhost
::1             localhost ip6-localhost ip6-loopback
fe00::0         ip6-localnet
ff00::0         ip6-mcastprefix
ff02::1         ip6-allnodes
ff02::2         ip6-allrouters
192.168.2.X   abc.selfhost.xy

Jetzt noch sicherstellen, dass zunächst die hosts dabei und danach der DNS-Server des Speedport abgefragt wird, indem wir die Datei „/etc/resolv.conf“ wie folgt anpassen:

nameserver 127.0.0.1
domain Speedport_W_724V_01011602_00_001
search Speedport_W_724V_01011602_00_001
nameserver 192.168.2.1

Danach dnsmasq neu starten:

sudo /etc/init.d/dnsmasq restart

Damit jetzt auch der Raspberry Pi als DNS-Server genutzt wird, gibt es zwei Möglichkeiten: 1. ihn gleich mit dnsmasq auch als DHCP-Server betreiben oder 2. bei den Geräten, die auf Baikal zugreifen sollen die IP des Raspberry Pi unter den Netzwerkeinstellungen händisch als DNS-Server eintragen. Da ich die zweite Option nutze, gibt es für 1. hier leider keine Anleitung.
Um Baikal nutzen zu können, braucht der CalDAV / CardDAV Server jetzt nur noch unter „https://abc.selfhost.xy/baikal/admin/install/“ installiert werden.
Nach Installation und der Einrichtung der Benutzer, Kalender und Telefonbücher können diese in den entsprechenden Programmen genutzt werden:

CalDAV (allgemein): https://abc.selfhost.xy/baikal/cal.php/calendars/BENUTZER/KALENDER/
CalDAV (für iOS/OS X): https://abc.selfhost.xy/baikal/cal.php/principals/BENUTZER/
CardDAV (allgemein): https://abc.selfhost.xy/baikal/card.php/addressbooks/BENUTZER/TELEFONBUCH/
CarDAV (für iOS/OS X): https://abc.selfhost.xy/baikal/card.php/principals/BENUTZER/

UPDATE zu Baikal 0.4.5

Da Baikal jetzt auf dav.php statt cal.php / card.php setzt und die Hauptdateien nicht mehr in baikal sondern baikal/html/ liegen, sind folgende Änderungen notwendig:

Geänderte rewrite Rules:

rewrite ^/.well-known/caldav /baikal/html/dav.php redirect;
rewrite ^/.well-known/carddav /baikal/html/dav.php redirect;

CalDav/CardDav (für iOS/OS X):

https://abc.selfhost.xy/baikal/html/dav.php/principals/BENUTZER/

Weiterführende Links und Dank an:
Jan Karres
Andrew Oberstar
ruhezustand.net

---
Beitrag interessant? Ich freue mich über einen Kauf bei Amazon*.