Kategorie: re:oyd

  • 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

  • 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

  • MacBook absichern

    Nicht erst seit der NSA-Abhöraffäre sollte eigentlich das Thema Computer- und Datensicherheit an erste Stelle stehen, wenn ein neuer PC in Betrieb genommen wird – insbesondere wenn es sich um ein Notebook/Laptop handelt (das nicht nur leichter gestohlen werden kann, sondern auch eher für Unbefugte physikalisch zugänglich ist). Sicherheit sollte sich dabei aber nicht nur auf den unbefugten Zugriff auf die eigene Hardware und Daten beziehen, sondern natürlich auch auf die Vermeidung von Datenverlust.
    Hier also ein 8-Punkte-Plan, um das Macbook etwas besser abzusichern:

    1. Anmelde-Kennwort/Systempasswort
      Es kann nicht oft genug wiederholt werden: Geburtstage, Kosenamen oder Zahlenfolgen wie 1234 sind keine guten Passwörter… Da nach der Anmeldung alle Daten unverschlüsselt vorliegen und (über gespeicherte Zugangsdaten) auch der Weg zu Online-Diensten meist offensteht, kann die Wichtigkeit eines starken Anmelde-Kennworts nicht überbewertet werden. Also: min. 8 Zeichen (je mehr desto besser) mit Sonderzeichen, Groß- und Kleinschreibung sowie Zahlen. Aber das ganze muss merkbar und in vertretbarer Zeit einzugeben sein, da das Systempasswort ja des Öfteren gebraucht wird. Und bitte ein Passwort verwenden, dass ausschließlich hier Anwendung findet (damit nicht ein kompromitierter anderer Dienst mit dem gleichen Kennwort die ganze Schutzstrategie aushebelt). Die Systemanmeldung/Kennwortwiederherstellung bitte nicht mit der Apple-ID verknüpfen, wir wollen ja Apple nicht den Zweitschlüssel zum System geben! Der Gast-Zugang zum System sollte sowieso standardmäßig ausgestellt sein (zu sehen unter: „Systemeinstellungen->Benutzer&Gruppen“).
    2. EFI-Passwort
      Zur hardwareseitigen Absicherung des MacBook muss ein EFI/Firmware-Passwort gesetzt werden. Damit kann, wenn das Macbook entwendet wird, der Dieb auch nicht einfach Mac OS X neu aufspielen und das Gerät benutzen. Dafür einfach das Macbook im Recovery-Modus starten, indem man bei Neustart cmd+R gedrückt hält. Dann unter „Dienstprogramme->Firmware-Kennwort“ ein Passwort setzen (evtl. kann es Schwierigkeiten mit US- bzw. deutschem Tastaturlayout geben. Wenn also das Passwort beim nächsten Mal, wenn man im Recovery-Modus startet, nicht erkannt wird, einfach mal versuchen bei Sonderzeichen die entsprechenden Tasten im US Layouts zu drücken: etwa ß statt -).
    3. FileVault 2
      Apple bietet mit der zweiten Version von FileVault die Möglichkeit, die gesamte Festplatte/SSD zu verschlüsseln. Da nun für den Zugriff auf das MacBook das Anmeldekennwort erforderlich ist, sollte es entsprechend sicher sein – und nicht Wiederherstellung mit der Apple-ID verknüpft werden (s.o.)! Damit erhält jeder bei Apple den Schlüssel für deine Daten! Also die Verbindung von Anmeldekennung und Apple-ID gar nicht erst herstellen. Dann kann unter „Systemeinstellungen->Sicherheit->FileVault“ die Verschlüsselung aktiviert werden (den Wiederherstellungsschlüssel dabei ebenfalls nicht bei Apple speichern…).
    4. Ruhezustand/Passwort
      Solange das Macbook läuft und zugänglich ist, sind die Daten ungeschützt. Daher sollte das MacBook nach einer nicht all zu langen Zeit der Untätigkeit in den Ruhezustand geschickt werden und dieser sich nur nach Kennworteingabe beenden lassen! Dafür unter „Systemeinstellungen->Sicherheit->Allgemein“ Kennwort erforderlich nach Beginn des Ruhezustands oder Bildschirmschoners auf „sofort“ setzen (und den Ruhezustand unter „Systemeinstellungen->Energie sparen“ setzen). Zur maximalen Absicherung lässt sich auch noch einstellen, dass beim Standby das Passwort für FileVault nicht im EFI gespeichert wird. Hier ein Anleitung.
    5. Firewall
      Ich nehme an, um evtl. Nachfragen bei Kundenproblemen zu minimieren, hat Apple sich dafür entschieden, die Firewall in Mac OS X standardmäßig zu deaktivieren. Diese kann aber einfach über „Systemeinstellungen->Sicherheit->Firewall“ aktiviert werden.
    6. Datensicherung
      Zum Schutz vor Datenverlust ist eine regelmäßige Datensicherung unerlässlich. Mit Apples TimeMachine steht dafür ein einfach zu bedienendes Tool zur Verfügung. Die Sicherung kann auf eine externe Festplatte (direkt am Mac angeschlossen oder über eine AirPort-Extreme-Station) oder eine TimeCapsule erfolgen. Darauf achten, bei der Einrichtung von TimeMachine auch die Verschlüsselung des Backups zu aktivieren! Noch besser ist es natürlich, die Sicherung abwechselnd auf zwei Festplatten durchzuführen – auch das lässt sich über Time Machine einfach einstellen. Eine der Sicherungen sollte dann selbstverständlich an einem anderen Ort aufbewahrt werden (sonst bringt auch die doppelte Sicherung etwa bei einem Feuer wenig).
    7. Virenscanner
      Bei Daten/ USB-Sticks aus unsicheren Quellen kann es auch auf dem Mac nicht schaden, vor Nutzung/Sichtung einen Virenscanner drüberlaufen zu lassen. Über den App-Store lässt sich etwa leicht ClamXav installieren (dieser Virenscanner läuft nicht im Hintergrund, sondern muss bei Bedarf manuell gestartet werden).
    8. E-Mail-Kommunikation
      Wer Apple Mail nutzt und seine E-Mails mit GPG End-to-End verschlüsselt versenden will, findet dazu hier eine gute Anleitung.
  • re:oyd (13): SparkleShare@PogoPlug v2

    Eine andere Dropbox-Alternative ist die OpenSource-Software SparkleShare die auf GitHub aufbaut. Leider gibt es aber bisher keinen Client für iOS oder Android. Wer es dennoch ausprobieren will, hier eine kurze Anleitung zur Einrichtung:

    1. Installation von SparkleShare auf dem PogoPlug:
      pacman -S sparkleshare
    2. Host-Installationsscript herunterladen:
      curl https://raw.github.com/hbons/Dazzle/master/dazzle.sh \
        --output /usr/bin/dazzle && chmod +x /usr/bin/dazzle
    3. Setup ausführen:
      dazzle setup
    4. Im Router das Port-Forwarding für SSH Port 22 auf die IP-Adresse des PogoPlug einstellen.
    5. SparkleShare auf den Clients installieren. Im Installationsverzeichnis findet sich dann eine Daten „NAME link code.txt“. Den gesamten Code markieren und kopieren.
    6. Auf dem Pogoplug einen Link für jeden Client hinzufügen:
      dazzle link

      Bei der folgenden Abfrage muss der oben kopierte Code eingefügt werden.

    7. Jetzt muss mindestens ein neues Projekt angelegt werden (entspricht einem Hauptordner im Sparkleverzeichnis der Clients):
      dazzle create PROJEKTNAME

      Nach dem Anlegen wird Addresse und Remote Path angezeigt, beides muss auf den Clients über das Icon in der Taskleiste, Menüpunkt SparkleShare->Add hosted Project->On my own Server, eingetragen werden. Bei der angegebenen Addresse handelt es sich natürlich nur um die gerade zugewiesene dynamische IP, daher muss statt ssh://storage@IP einfach die DNSDynamic URL eingetragen werden: ssh://storage@royd.dnsd.me

      Alternativ kann auch über „dazzle create-encrypted PROJEKTNAME“ ein Hauptordner mit AES-256-CBC Verschlüsselung erstellt werden. Das Passwort zum Entschlüsseln liegt dabei ausschließlich auf Client-Seite.

  • re:oyd (12): WordPress, Permalinks, rewrite und nginx

    Wer bei WordPress die suchmaschinenfreudlicheren Permalinks benutzen möchte, muss entsprechende rewrite Rules erstellen. Da wir nginx als Webserver nutzen, muss die Datei „/etc/nginx/nginx.conf“ angepasst werden (statt etwa der mod_rewrite Rules in .htaccess für Apache-Server). „Rewrite“ müssen wir dabei aber gar nicht nutzen, da es eine effektivere Regel gibt („try_files $uri $uri/ /index.php?$args;“). Diese also einfach in die entsprechende location-Sektion des (richtigen) Servers eintragen:

    server {
       #...
       location / {
          root /srv/http/wordpress;
          index  index.php; 
          try_files $uri $uri/ /index.php?$args;  
     }
    

    Rewrite könnte man etwa einsetzen, um eine einfache php-Webseite mit Verweisen der Form „index.php?seite=impressum“ als statische Seite („impressum.html“) erscheinen zu lassen:

    server {
        #...
        location / {
           root   /srv/http;
           index  index.php;
           rewrite ^/([a-zA-Z0-9-_]+).html$ /index.php?seite=$1 last;
    }
    
  • re:oyd (11): Domains, dynamische IPs und nginx

    Dank DNSdynamic (oder jedem anderen dynamischen DNS Anbieter) ist unser Homeserver, trotz wechselnder IP-Adresse, einfach über royd.dnsd.me erreichbar. Schön ist aber anders und zufällig haben wir noch DOMAIN1.de und DOMAIN2.de. Eine davon soll auf unsere neue WordPress-Installation verweisen, die zweite auf unsere berufliche Webseite. Frame-Weiterleitung oder HTTP-Weiterleitung wollen wir natürlich nicht – also müssen wir an die DNS Einträger der Domains heran (sollte das nicht gehen, bleibt wohl nur ein Domainumzug).

    Die Auflösung des Domainnamens erfolgt zunächst über das A-Record. Hier steht die (feste) IP-Adresse des Webservers. Mit wechselnder IP-Adresse können wir damit also nichts anfangen. Zum Glück gibt es aber noch den CNAME Eintrag. Hier können wir eine Alias-Domain angeben, an die DOMAIN1.de weitergeleitet werden soll (ein CNAME Eintrag für http://DOMAIN1.de zur Weiterleitung ist leider nicht standardkonform, aber für http://www.DOMAIN1.de gibt es kein Problem. Dafür müssen wir die Subdomain www anlegen, sofern sie noch nicht existiert). Für CNAME können wir jetzt einfach „royd.dnsd.me“ eintragen.
    Das gleiche gilt für www.DOMAIN2.de . ACHTUNG! Eine Weiterleitung auf bspw. „royd.dnsd.me/wordpress/“ ist nicht möglich! Folglich müssen wir nginx so einrichten, dass wir bei Eingabe von www.DOMAIN1.de bzw. www.DOMAIN2.de auf der richtigen Webseite, bzw. im richtigen Verzeichnis des Webservers landen.

    Also ins Verzeichnis „/etc/nginx/“ wechseln und nginx.conf bearbeiten:
    Wir brauchen für jede Domain eine eigene „server“ Sektion. Die bereits existierende kann einfach kopiert werden. Die Anpassungen sehen dann etwa so aus (ACHTUNG: Darstellung nur auszugsweise):

    server {
       listen   80;
       server_name DOMAIN1.de;
       location / {
          root /srv/http/wordpress;
          index  index.php index.html; 
       }
    }
    server {
       listen   80;
       server_name DOMAIN2.de;
       location / {
          root /srv/http;
          index  index.php index.html; 
       }
    }
    

    Damit sollten jetzt beide Domains korrekt funktionieren.

  • re:oyd (10): WordPress@Pogoplug V2

    WordPress auf dem Pogoplug? Ob das so eine gute Idee ist…
    allein bei den Ressourcen die MySQL verbraucht. Theoretisch kann WordPress auch mit SQLite, dann funktionieren aber wohl viele Plugins nicht.

    1. Also erstmal MySQL installieren:
      pacman -S mysql

      Dann MySQL starten:

      service mysqld start

      (stattdessen ginge auch mysqld_safe: „/usr/bin/mysqld_safe &“) und gleich für sichere Verhältnisse sorgen:

      /usr/bin/mysql_secure_installation

      Damit MySQL nach einem Neustart automatisch gestartet wird, noch folgenden Befehl ausführen:

      systemctl enable mysqld
    2. Als nächstes ist WordPress an der Reihe. Also ins Webverzeichnis wechseln:
      cd /srv/http/

      und die aktuelle WordPress-Version herunterladen

      wget HIER LINK ZUR AKTUELLEN DATEI EINFÜGEN

      Dann schnell unzip installieren:

      pacman -S unzip

      und die wordpress entpacken:

      unzip DATENNAME.zip

      Die Datei kann jetzt gelöscht werden

      rm DATEINAME.zip

      Unsere WordPress-Dateien liegen jetzt unter „/srv/http/wordpress/“.
      Jetzt müssen wir php-fpm noch mitteilen, dass ab sofort MySQL genutzt werden kann. Dafür müssen wir die Datei „/etc/php/php.ini“ bearbeiten. Dort einfach die Raute „#“ vor dem Eintrag

      extension=mysql-so

      entfernen und php-fpm neustarten:

      systemctl restart php-fpm
    3. Nun muss MySQL noch vorbereitet werden, dazu melden wir uns bei MySQL an:
      mysql --user=root --password=PASSWORT mysql

      Als erstes legen wir nun die Datenbank für WordPress an

      CREATE DATABASE wpdatabase;

      ENTER. Dann einen neuen Nutzer mit Passwort und Zugriff auf diese Datenbank:

      GRANT ALL ON wpdatabase.* TO wordpress_user@localhost IDENTIFIED BY "PASSWORT";

      ENTER. Und abmelden

      EXIT

      ENTER.
      Jetzt können wir über den Browseraufruf von „localhost/wordpress/“ WordPress mit der gerade erstellten Datenbank und dem MySQL Benutzer einrichten.

    4. Wie bereits angesprochen verbraucht MySQL viele Ressourcen, genauer: Arbeitsspeicher – und der ist beim Pogoplug stark begrenzt. Es ist daher wenig hilfreich, wenn sich MySQL standardmäßig etwa allein für key_buffer_size bis zu 64 MB genehmigt. Diese Werte können in der Datei „/etc/mysql/my.cnf“ angepasst werden. Etwa wie folgt:
      key_buffer_size = 1M
      max_allowed_packet = 1M
      table_open_cache = 64
      sort_buffer_size = 100K
      net_buffer_length = 8K
      read_buffer_size = 100K
      read_rnd_buffer_size = 100K
      myisam_sort_buffer_size = 1M
      

      Jetzt noch MySQL neustarten, damit die Änderungen wirksam werden:

      systemctl restart mysqld

    Damit läuft WordPress auf dem Pogoplug. Man sollte sich bezüglich der Performance aber nicht all zu viele Hoffnungen machen. Eine einfacher Reload der Startseite bringt die CPU-Auslastung auf 70-90%…

  • re:oyd (9): Apple Kalender, Kontakte, iOS und OwnCloud CalDAV / CardDAV

    Der auf unserem Pogoplug V2 laufende OwnCloud Server nutzt CalDAV und CardDAV, um Kalender- und Kontaktdaten zu speichern und für Clients bereitzustellen. Zunächst stellt sich aber die Frage, wie wir unsere im Apple Mail und Kontakte Programm gespeicherten Daten auf den OwnCloud Server bekommen. Nichts leichter als das – OwnCloud unterstützt Drag&Drop!

    1. Als erstes starten wir daher Apple Kalender. Auf der linken Seite sollten die unterschiedlichen Kalender (etwa Privat, Geschäftlich etc.) angezeigt werden. Wenn nicht: einfach oben links auf „Kalender“ klicken.
    2. Jetzt einfach den ersten Kalender auswählen, Zwei-Finger-Klick und im Kontextmenü „Exportieren“ auswählen.
    3. Die so in einer Datei gespeicherten Kalenderdaten können jetzt einfach per Drag&Drop auf das im Browser geöffnete Kalender-Fenster von OwnCloud gezogen werden. OwnCloud importiert die Daten und es kann mit dem nächsten Kalender weitergehen.
      1. Nicht viel schwieriger läuft es mit unseren Apple Kontaktdaten ab.

        1. Apple Kontakte aufrufen.
        2. Einen Kontakt auswählen und dann mit cmd+A alle auswählen. Die Kontakte können nun einfach per Drag&Drop als eine einzelne Datei auf den Schreibtisch gezogen werden.
        3. Die Datei jetzt ebenfalls per Drag&Drop einfach auf das im Browser geöffnete Kontakte-Fester von OwnCloud ziehen. Fertig.

        Für die Verknüpfung von OwnCloud CalDAV und CardDAV mit iOS und Apple Kalender/ Kontakte gibt OwnCloud jeweils unter Einstellungen die zu nutzende URL an. Sie ist nach dem Schema „https://DOMAINNAME/OWNCLOUDVERZEICHNIS/remote.php/caldav/principals/USERNAME/“ bzw. „https://DOMAINNAME/OWNCLOUDVERZEICHNIS/remote.php/carddav/principals/USERNAME/“ aufgebaut.
        ACHTUNG! Diese Vorgaben funktionieren nicht immer bei iOS / OS X! Eventuell kommen beispielsweise Fehlermeldungen wegen der SSL Verschlüsselung. Die Lösung ist in vielen Fällen recht einfach:
        Es müssen „https://“ am Anfang und „/“ am Ende weggelassen werden.

  • re:oyd (8): OwnCloud@Pogoplug V2

    Unser Server läuft soweit, also geht es jetzt daran, OwnCloud zu installieren.

    1. Dafür wechseln wir zunächst in unser Webserververzeichnis
      cd /srv/http
    2. Dann laden wir die neueste OwnCloud Version herunter
      wget http://owncloud.org/releases/owncloud-4.5.5.tar.bz2
    3. die wir anschließend entpacken
      tar -xjf owncloud-4.5.5.tar.bz2
    4. und zu guter letzt noch den Besitzer der Dateien anpassen
      chown -R http:http /srv/http/owncloud/

    Unser OwnCloud-Server sollte dann am Ende unter https://royd.dnsd.me/owncloud/ erreichbar sein. Damit OwnCloud läuft, müssen wir aber noch unseren Webserver und unsere php-Installation anpassen. Beginnen wir mit den Änderungen an der
    nginx-Konfigurationsdatei (/etc/nginx/nginx.conf) (ACHTUNG, nur ausschnittsweise Darstellung der Datei):

    server {
           listen       443;
           client_max_body_size 1000M; # UPLOAD-DATEIGRÖSSE
           #...
           location / {
                server_name   royd.dnsd.me; #ACHTUNG server_name IN DER GESAMTEN DATEI ANPASSEN!
                root   /srv/http;
                index index.php index.html index.htm;
    
                rewrite ^/cloud/.well-known/host-meta /public.php?service=host-meta last;
                rewrite ^/cloud/.well-known/carddav /remote.php/carddav/ redirect;
                rewrite ^/cloud/.well-known/caldav /remote.php/caldav/ redirect;
                rewrite ^/cloud/apps/calendar/caldav.php /remote.php/caldav/ last;
                rewrite ^/cloud/apps/contacts/carddav.php /remote.php/carddav/ last;
                rewrite ^/cloud/apps/([^/]*)/(.*.(css|php))$ /index.php?app=$1&getfile=$2 last;
                rewrite ^/cloud/remote/(.*) /remote.php/ last;
                #error_page 403 /cloud/core/templates/403.php;
                #error_page 404 /cloud/core/templates/404.php;
    
                try_files $uri $uri/ @webdav;
                }
    
                # Direkten Zugriff auf Daten unterbinden
                location ~ /(data|config|.ht|db_structure.xml|README) {
                            deny all;
                }
    
        location @webdav {
                        fastcgi_split_path_info ^(.+.php)(/.*)$;
                        unix:/var/run/php-fpm/php-fpm.sock;
                        fastcgi_param SCRIPT_FILENAME /srv/http$fastcgi_script_name;
                        fastcgi_param HTTPS on;
                        fastcgi_param HTTP_AUTHORIZATION $http_authorization;
                        fastcgi_param htaccessWorking true;
                        include fastcgi_params;
         }
    }
    

    Als nächstes müssen wir noch in der php-Konfigurationsdatei (/etc/php/php.ini) einige Zeilen auskommentieren. Das Rautezeichen # muss vor den folgenden Zeilen gelöscht werden:

    xmlrpc.so
    zip.so
    gd.so
    pdo_sqlite.so
    sqlite3.so
    extension=iconv.so
    extension=openssl.so
    

    Zu guter Letzt starten wie noch nginx und php-fpm neu

    systemctl restart nginx
    systemctl restart php-fpm
    

    Jetzt sollte sich OwnCloud über https://royd.dnsd.me/owncloud/ einrichten lassen. Und natürlich muss noch der entsprechende Mac-Client heruntergeladen und eingerichtet werden. Wer für sein abzugleichendes OwnCloud-Verzeichnis auf dem Mac noch ein passendes Icon sucht, hier gibt es zwei die benutzt werden könnten:

    /System/Library/CoreServices/CoreTypes.bundle/Contents/Resources/SidebariCloud.icns
    /Programme/owncloud/Resources/ownCloud.icns
    

    OwnCloud muss zwischendurch diverse Aktualisierungen durchführen. Standardmäßig wird dafür AJAX verwendet, um diese bei Seitenaufruf auszuführen. Wir können diese Aufgabe allerdings auch in einen Cron-Job auslagern.

    1. Dafür muss im Administrationsmenü von OwnCloud unter Cron-Jobs die Einstellung von AJAX auf CRON umgestellt werden.
    2. Anschließend fügen wir einen entsprechenden Cron-Job der jede Minute ausgeführt wird in ArchLinux ein:
      crontab -e
      * * * * * php -f /srv/http/cloud/cron.php
      

    EDIT: Gerade diesen Blog gefunden, wo das gleiche Projekt verfolgt wird.

    EDIT2: Weiterführender Link zum Thema nginx und OwnCloud.

  • re:oyd (7): Dynamisches DNS@Pogoplug v2

    Damit unsere Server bei wechselnder IP-Adresse (aufgrund der 24h Zwangstrennung) von außen erreichbar bleibt, bietet es sich an, einen Anbieter von DDNS Services zu nutzen. Der wohl bekannteste, DynDNS bietet leider keine kostenlosen Accounts mehr an. Es gibt aber Alternativen, etwa DNSdynamic. Glück hat, wer einen Router sein eigen nennt, der mit entsprechenden kostenlosen Anbietern zusammenarbeitet. Mein Netgear DGND3800B kennt leider bisher nur DynDNS. Eine Anfrage beim Support stellt zwar in Aussicht, dass ein zukünftiges Firmeware-Update weitere Anbieter hinzufügen wird, aber bis dahin muss Abhilfe geschaffen werden. Da der pogoplug als Server ja sowieso den ganzen Tag läuft, kann er auch gleich die IP-Adresse bei DNSdynamic auf dem aktuellen Stand halten. Dafür brauchen wir nur ein Account, ein bisschen bash-Programmierung und eine cron-job.

    1. Als erstes richten wir unseren Account bei DNSdynamic ein: Accoutname: „MEIN@ACCOUNT.DE“, Passwort: „PASSWORT“, URL: „royd.dnsd.me“ – ist doch gut zu merken 😉
    2. Eine Datei myDNSdynamic.ip ohne Inhalt und eine Datei updateIP.sh mit folgendem Inhalt im Verzeichnis „/usr/sbin“ erstellen:
      #!/bin/sh
      FILE="/usr/sbin/myDNSdynamic.ip"; #DATEI IN DER DIE JEWEILS LETZTE IP GESPEICHERT WIRD
      MYOLDIP=`head -n 1 $FILE`;
      MYIP=$(wget -O - -q icanhazip.com); #AKTUELLE IP ABRUFEN
      if [ "$MYIP" != "$MYOLDIP" ]  #WENN SICH IP GEÄNDERT HAT, BEI DNSDYNAMIC AKTUALISIEREN
              then
              echo $MYIP > $FILE; 
              URL="https://www.dnsdynamic.org/api/?hostname=royd.dnsd.me&myip="${MYIP};
              wget -O - -q --user MEIN@ACCOUNT.DE --password PASSWORT $URL;
      fi 
      
    3. Die gerade erstellte Datei ausführbar machen:
      chmod +x /usr/sbin/updateIP.sh
    4. Und jetzt noch einen cron-job erstellen, der die Datei alle 5 Minuten aufruft:
      crontab -e

      Folgenden Inhalt einfügen:

      */5 * * * * /bin/sh /usr/sbin/updateIP.sh