Kategorie: Internet

  • Adios 1blu, Hallo netcup

    Seit 2013 liefen meine Webseiten auf Servern von 1blu. Seit 2014 im Vertrag Homepage 12 für 2,69 € im Monat. 2023 erfolgte die erste Erhöhung auf 2,93 €. Ein Jahr später auf 3,21 €. Angesichts der allgemeinen Preisentwicklung fand ich das akzeptabel, auch wenn, meiner Erinnerung nach, in der Bewerbung des Angebots 2014 in Bezug auf den Preis durchaus von „dauerhaft“ die Rede gewesen war (siehe bspw. auch entsprechende Pressemitteilungen von 1blu; https://www.1blu.de/presse/meldungen/archiv/).

    Am 10.10.2024 schrieb 1blu dann, dass ab 28.1.2025 eine weitere Erhöhung der monatlichen Kosten auf mehr als das Dreifache des aktuellen Preises erfolgen würde, auf dann 9,99 € im Monat. Im Rahmen des deswegen angestoßenen Kündigungsprozesses war es dann aber doch möglich, den Vertrag zu den alten Konditionen weiterzuführen. Ende 2025 erfolgte allerdings die erneute Information über die Preisanhebung ab 2026. Eine „Umgehung“ war nicht mehr möglich und das Angebot von 1blu war nur, statt der regulären 9,99 € „nur“ einen „Treuepreis“ von 7,99 € zu bezahlen.

    Unabhängig von der absolut bodenlosen Frechheit der Bewerbung eines Angebotspreises als „dauerhaft“ und dann einer plötzlichen Preiserhöhung auf das Dreifache, keinem Hinweis auf Sonderkündigungsrecht o.ä. und ausschließlich einer Information über die Preiserhöhung ohne eine aktive Zustimmung einzufordern, ist auch der Treuepreis angesichts der aktuellen Preise und Leistungen anderer Anbieter leider so gar nicht konkurrenzfähig. Also habe ich mir die Arbeit gemacht und alle Webseiten auf netcup umgezogen. Jetzt habe ich mehr Leistungen und bezahle trotzdem deutlich weniger als beim „Treuepreis“ von 1blu.

  • 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
  • re:oyd (6): SSL web/php@Pogoplug v2

    Da private Dateien auf unserem Server gespeichert und übertragen werden sollen, macht es Sinn, alle Verbindungen über SSL abzusichern. Infos wie das geht, finden sich etwa hier oder hier.
    Zunächst brauchen wir die notwendigen Schlüssel, um eine sichere SSL-Verbindung aufbauen zu können. Normalerweise werden diese extern zertifiziert, wir zertifizieren uns die Schlüssel jedoch selber (das führt allerdings dazu, dass alle Browser uns später beim Aufrufen unsere Serverwebseite darauf hinweisen werden, dass die Identität des Schlüssels nicht festgestellt werden kann und daher nicht vertrauenswürdig sei).

    1. Als erstes wechseln wir in das Verzeichnis, wo später die Schlüssel liegen sollen:
      cd /etc/nginx/
    2. Dann erstellen wir den privaten Schlüssel:
      openssl genrsa -des3 -out server.key 1024
    3. Jetzt das Certificate Signing Request erstellen:
      openssl req -new -key server.key -out server.csr
    4. Um Nginx automatisch mit SSL starten zu können, ohne jedes mal unsere Passwort angeben zu müssen:
      cp server.key server.key.org
      openssl rsa -in server.key.org -out server.key
    5. Und zum Schluss signieren wir unsere Serverzertifikat mit einer Laufzeit von 10 Jahren:
      openssl x509 -req -days 3650 -in server.csr -signkey server.key -out server.crt

    Als nächsten müssen wir nginx mitteilen, dass wir ab jetzt eine SSL Zertifikat haben und ALLE Verbindungen über SSL aufbauen wollen. Dafür müssen wir die Konfigurationsdatei von nginx wie folgt (ACHTUNG, nur ausschnittsweise Darstellung der Datei) anpassen (/etc/nginx/nginx.conf):

    server {
           listen       80;
           server_name  localhost; # SPÄTER MUSS HIER DER DYNDNS NAME HIN
           rewrite ^ https://$server_name$request_uri? permanent; # ALLE http Anfragen in https Anfragen ändern
            
           location / {
                root   /srv/http;
                index  index.php index.html index.htm;
           }
     
           location ~ \.php$ {
                root   /srv/http;
                fastcgi_pass  unix:/var/run/php-fpm/php-fpm.sock; 
                fastcgi_index  index.php;
                fastcgi_param SCRIPT_FILENAME /srv/http$fastcgi_script_name;
                fastcgi_param HTTPS on;
                include  fastcgi_params;
           }
    }
    
    server {
            listen  443;
            server_name  localhost;   # SPÄTER MUSS HIER DER DYNDNS NAME HIN
            ssl     on;
            ssl_certificate      /etc/nginx/server.crt;
            ssl_certificate_key  /etc/nginx/server.key;
            ssl_session_timeout  5m;
            ssl_protocols  SSLv2 SSLv3 TLSv1;
            ssl_ciphers  HIGH:!aNULL:!MD5;
            ssl_prefer_server_ciphers   on;
    
            location / {
                root   /srv/http;
                index index.php index.html index.htm;
            }
    
            location ~ \.php$ {
            root   /srv/http;
            fastcgi_pass  unix:/var/run/php-fpm/php-fpm.sock; 
            fastcgi_index  index.php;
            fastcgi_param SCRIPT_FILENAME /srv/http$fastcgi_script_name;
            fastcgi_param HTTPS on;
            include  fastcgi_params;
            fastcgi_param HTTP_AUTHORIZATION $http_authorization;
            fastcgi_param htaccessWorking true;
    }
    

    Jetzt nur noch nginx neustarten

    systemctl restart nginx

    und unser pogoplug-Server sollte alle Verbindungen über SSL absichern.

  • re:oyd (5): Web/PHP-Server@Pogoplug v2

    Die begrenzten Ressourcen unseres Pogoplugs sprechen dagegen Arkansas 501 find phone , einen klassischen LAMP-Server mit Apache aufzusetzen. Eine bessere Wahl ist nginx oder lighttpd. Da es für lighttpd nur wenig weiterführende Artikel im Netz gibt, nehmen wir das verbreitetere nginx. Dazu kommt PHP mit einer alternativen FastCGI Implementation: PHP-FPM, PHP-GD für Grafikfunktionen und sqlite als Datenbank.

    pacman -S nginx php php-fpm php-sqlite sqlite php-gd
    

    Damit nginx und PHP immer automatisch starten fügen wir beide in den Service-Manager ein:

    systemctl enable nginx
    systemctl enable php-fpm

    Als nächstes müssen wir noch die Web-Verzeichnisse anpassen und nginx mit php-fpm verbinden.

    1. Dazu zunächst in das nginx-Verzeichnis wechseln:
      cd /etc/nginx
    2. Dort die Datei nginx.conf öffnen (etwa mit vi) undd die folgenden Zeilen anpassen:
      location / {
         root   /srv/http;
         index  index.php index.html index.htm;
      }
    3. sowie die folgende auskommentierten Zeilen finden und entsprechend anpassen:
      location ~ \.php$ {
          root   /srv/http;
          fastcgi_pass   unix:/var/run/php-fpm/php-fpm.sock;
          fastcgi_index   index.php;
          fastcgi_param   SCRIPT_FILENAME $document_root$fastcgi_script_name;
          include   fastcgi_params;
      }

    Jetzt müssen wir nur noch nginx und php-fpm starten und der Server läuft:

    systemctl start nginx
    systemctl start php-fpm
    

    Ein Aufruf der IP-Adresse des Pogoplug im Browser sollte jetzt zu einer Fehlermeldungsseite (403) führen. Das ist richtig, wir haben ja noch keinen Webinhalt erstellt. Dazu wechseln wir jetzt ins Hauptverzeichnis unsere Webinhalte

    cd /srv/http

    und erstellen die Datei index.php (etwa mit vi). In die Datei schreiben wir folgenden Inhalt, um unsere PHP-Konfiguration auf der Webseite anzeigt:

    
    

    Jetzt sollte ein Aufruf der Pogoplug-IP im Browser eine Webseite mit der PHP-Konfiguration anzeigen. Damit läuft unsere Web/PHP-Server.

  • re:oyd (4): ArchLinuxARM@Pogoplug v2

    Mit der Pogoplug eigenen Software können wir für unsere Serverpläne nichts anfangen. Eine geeignete Linux-Distribution auf dem Pogoplug einzuspielen, stand daher als erstes auf dem Plan. Aufgrund der beschränkten Hardware und dem guten Community-Support bietet sich Arch Linux ARM an. Eine Installationsanleitung gibt es direkt von ArchLinuxARM.org.

    Hier ein Überblick über die Installation:

    1. Pogoplug an Strom und Netzwerk anschließen
    2. USB Stick einstecken (Achtung! Alle auf dem Stick befindlichen Daten gehen verloren!)
    3. Im Routermenü die IP-Adresse des Pogoplug suchen (Router meist im Browser über 192.168.0.1 zu erreichen. Bei den verbundenen Geräten sollte der Pogoplug und die ihm zugewiesene IP auftauchen – unter der Annahme, dass beim Router DHCP an ist)
    4. Es bietet sich an, schon an dieser Stelle dem Pogoplug über den Router eine feste IP zuzuweisen. Spätestens für Dynamic DNS wird das sowieso notwendig. Im Folgenden gehen ich davon aus, dass der Pogoplug über 192.168.0.11 zu erreichen ist.
    5. Über ssh mit dem Pogoplug Kontakt aufnehmen:
      ssh -l root 192.168.0.11
    6. Das Passwort ist: ceadmin
    7. Jetzt stellen wir die auf dem Pogoplug laufenden Software aus:
      killall hbwd
    8. Ins temporäre Verzeichnis wechseln:
      cd /tmp
    9. Den nötigen Bootloader herunterladen:
      wget http://jeff.doozan.com/debian/uboot/install_uboot_mtd0.sh
    10. Die heruntergeladene Datei ausführbar machen…:
      chmod +x install_uboot_mtd0.sh
    11. …und ausführen
      ./install_uboot_mtd0.sh

    Als nächstes kümmern wir uns um die Vorbereitung des USB-Sticks:

    1. Partitionsprogramm fdisk für den Stick starten
      /sbin/fdisk /dev/sda
    2. Im Programm mit den folgenden Tasten, das folgende machen:
      • Alle Partitionen des Sticks löschen
        o
      • Liste aller Partitionen anzeigen, die jetzt hoffentlich leer ist
        p
      • Neue Partition erstellen
        n
      • Es soll eine primäre Partition werden
        p
      • Beide Vorgaben übernehmen mit zweimal
        Enter
      • Programm beenden
        w
    3. Programm mke2fs runterladen, um ext2 Dateisystem erstellen zu können
      wget http://archlinuxarm.org/os/pogoplug/mke2fs
    4. Benutzerrechte und Ausführbarkeit einstellen
      chmod 755 mke2fs
    5. USB-Stick mit ext2 formatieren
      ./mke2fs /dev/sda1
    6. Verzeichnis usb erstellen
      mkdir usb
    7. Die eben auf dem USB-Stick erstellte Partition in das Verzeichnis usb mounten
      mount /dev/sda1 usb

    Jetzt müssen wir ArchLinuxARM herunterladen und installieren:

    1. Zunächst ins neu erstellte Verzeichnis usb wechseln
      cd usb
    2. Dann Arch Linux laden
      wget http://archlinuxarm.org/os/ArchLinuxARM-armv5te-latest.tar.gz
    3. Das heruntergeladene Archiv muss entpackt werden, was etwas dauern kann
      tar -xzvf ArchLinuxARM-armv5te-*.tar.gz
    4. Die Archivdatei können wir jetzt wieder löschen
      rm ArchLinuxARM-armv5te-*.tar.gz
    5. Jetzt noch sicherstellen, dass alle entpackten Daten auch aus dem Speicher auf den USB-Stick gewandert sind
      sync

    Und jetzt noch aufräumen:

    1. Aus dem Verzeichnis usb ins darüber liegende Verzeichnis wechseln
      cd ..
    2. USB-Stick auswerfen
      umount usb
    3. Pogoplug neustarten
      /sbin/reboot

    Reconnect:

    1. Vor dem Reconnect muss bei Linux/Mac noch der alte SSH Schlüssel gelöscht werden
      ssh-keygen -R 192.168.0.11
    2. Jetzt wieder eine ssh-Verbindung aufbauen
      ssh -l root 192.168.0.11
    3. Das Passwort ist jetzt: root
    4. Daher sollten wir das schnell noch ändern
      passwd
    5. Bevor es mit dem Installieren von Programmen los gehen kann, müssen wir erstmal mit dem Paketmanager pacman die Paketliste aktualisieren und das System updaten
      pacman -Syu
    6. Und noch schnell den Namen des Servers anpassen
      hostname royd

    Daumen hoch, unser eigener ArchLinuxARM-Server läuft auf dem Pogoplug v2!

  • re:oyd (3): Der Server – Pogoplug v2

    PogoplugHeute ist der bestellte Pogoplug angekommen.
    Nach dem Auspacken machte sich erstmal Ernüchterung breit. Auf der Packung steht zwar POGO-P24, auf dem Gerät findet sich jedoch ein Aufkleber (mit der gleichen Seriennummer) mit der Angabe POGO-E2. Also das Gerät einfach mal aufgemacht und siehe da, tatsächlich ein Pogoplug der 2. Generation und nicht der 3ten. Die v2 hat im Gegensatz zur v3 keinen SATA-Anschluss auf dem Board. Damit hat sich die Überlegung, eine SSD per SATA anzuschließen erstmal erledigt (zum Glück hatte ich noch nicht alle dafür nötigen Kabel und Adapter gekauft). Außerdem gibt es nur einen Einkern-Prozessor statt eines DualCore. Immerhin ist der dafür aber höher getaktet und – für einen Server nicht gerade unwichtig – hat 256MB Ram statt 128MB beim v3.

    Hier also die vollständigen Daten des künftigen r:oyd-Server:

    • 1,2 GHz Marvell Kirkwood Prozessor
    • 256MB RAM
    • 128MB NAND Speicher
    • 4 USB-Anschlüsse
    • 1 Gigabit Lan-Anschluss
    • 4-5 Watt Verbrauch (ohne Festplatte)

    Zum Testen muss erstmal ein alten 8GB USB-Stick herhalten. Perspektivisch müsste dann mal einer rausgesucht werden, der die Schreib/Leseleistung des Pogoplug voll ausreizt (eine Festplatte würde ja wieder Lärm produzieren und den Stromverbrauch erhöhen). Das werden dann wohl aber auch nur je 20-30 MB/s werden. Mit SATA-Anschluss wäre das etwas schneller geworden… (zumindest ein User berichtet von 45 MB write/ 98 MB read). Bei SAMBA-Tests lagen aber beide Lösung bei rund 20 MB/s.

  • re:oyd (2): Welche Serverlösung?

    Die letzten Tage habe ich mit der Suche nach Serverlösungen zugebracht. Da wir ja unsere Daten zurückhaben wollen, kann ein gemieteter (V)Server natürlich keine Lösung sein. Der Server muss also in den eigenen vier Wänden stehen. Dafür müssen einige Dinge bedacht werden:

    1. Genug Bandbreite?
      Mit dem Umstieg auf VDSL sollte der Upstream zumindest so schnell sein, dass eine Homelösung tatsächlich halbwegs nutzbar ist. So große Dateien die oft geändert und synchrongehalten werden müssen habe ich eh nicht
    2. Kosten
      Nicht nur die Anschaffungskosten, sondern auch die Betriebskosten sind zu berücksichtigen.
    3. WAF (s. c’t)
      Das Ding muss irgendwo (in der Nähe des Routers) stehen, ohne viel Platz wegzunehmen und unansehnlich zu sein. Für mich aber noch wichtiger: LEISE muss er sein

    Um die Punkt 2. und 3. zu erfüllen, soll es keine „normale“ Serverlösung werden. Viel Leistung brauche ich ja auch nicht. Daher wird es ein MiniServer auf ARM Basis werden. Damit fällt schon mal ein Lüfter als Lärmquelle weg und viel Strom verbrauchen die auch nicht. Die in letzter Zeit am häufigsten genannte Produkte gibt es nicht um die Ecke und sie sind a) unansehnlich: Raspberry Pi oder b) teuer: Trim Slice

    Letztlich hat ibood auf die Sprünge geholfen. Heute gab es zufälligerweise den Pogoplug Pro im Angebot für 25,90 Euro. Den habe ich gleich bestellt – und später wieder abbestellt. Irgendwie hat ibood einen Fehler gemacht und hatte doch nicht die richtige Pro-Version im Angebot. Dafür gab es beim Hersteller die Classic-Version Pogoplug POGO-24 für nur 14,95 Euro (inkl. Versand). Für den Preis kann man ja gar nix falsch machen.

  • re:oyd (1): Welche Daten liegen wo?

    Zunächst eine Bestandsaufnahme, was es so alles an Daten gibt und erste Ideen, wie wir sie zurückholen.

    Profildaten:

    • Facebook
    • Xing
    • ResearchGate
    • Google+

    Nachdem ich mich schon vor einiger Zeit von Facebook verabschiedet hatte, müssen jetzt auch die anderen Profile dran glauben. Zum einen nutze ich sie nicht produktiv, zum anderen kostet es zu viel Zeit, die Profile auf dem neuesten Stand zu halten. Es reicht, wenn die Daten auf der privaten und berufliche Homepage stehen und aktuell sind. Kommunizieren kann man auch mit Telefon und eMail wunderbar. Womit wir schon beim zweiten Thema sind.

    eMails:

    • google-Mail
    • web.de
    • berufliche MailAdresse
    • MailAdressen der eigenen Domains

    Wer braucht schon viele verschiedene eMail-Adressen? Vor allem alte Adressen über Free-Hoster liefern eigentlich nur ungelesene Newsletter und Spam. Für kurzfristige Anmeldungen ist eh trash-mail.com besser geeignet. Also weg mit den alten Accounts. Bisher hatte ich alle Mails bei GMail zusammenlaufen lassen. Das ist zwar einfach, aber vielleicht nicht die beste Lösung… Online muss man sich mit Werbung rumärgern und wer weiß, was Google mit der Auswertung der Mails so alles treibt…
    Statt bei google liegen die beruflichen Mails jetzt also wieder auf dem Uni-Server und die Domain-Mails beim Webspace-Anbieter. Mehrere Accounts im Mailprogramm anzulegen ist ja nicht schwierig und es hat gleichzeitig den Vorteil, dass man sich überlegen kann, ob man die beruflichen Mails am Wochenende lesen will.
    Perspektive: Letztendlich sollen die Mails alle auf einem eigenen Server zusammenlaufen. Dieser Server wird das Herzstück meines r:oyd Projektes.

    Kalender und Kontakte:
    Zum Synchronisieren von Kalenderdaten und Kontakten habe ich bisher auch den google-Account genutzt.
    Perspektive: Zukünftig soll das über einen eigenen Server mit Hilfe von CalDAV und CardDAV laufen.

    Browser-Lesezeichen:

    Da ich Chrome benutze, wurden die Lesezeichen ebenfalls über den google-Account abgeglichen. Jetzt ist der Account weg, also muss eine neue Lösung her.
    Perspektive: Vielleicht geht ja was mit Chromium und dem eigenen Server, sonst heißt es vermutlich: zurück zum Firefox.

    Datei-Daten:

    Zum Datenabgleich/ Synchronisieren benutze ich Dropbox. Sobald die Serverlösung feststeht, muss hier eine Alternative her.
    Perspektive: Entweder eine einfache aber im Umgang umständliche Lösung wie WebDAV oder der Versuch die offen Dropbox Alternative OwnCloud oder Seafile auf dem eigenen Server laufen zu lassen.

    Homepage:

    Meine Webseiten liegen bei goneo. Ausreichend schnell und gut verfügbar, außerdem günstig.
    Perspektive: Nur noch die Domains verwalten lassen. Die Daten auf dem eigenen Server und über Dynamic DNS mit Domains verknüpfen.

    Bei mir lief tatsächlich ziemlich viel über Google. Zukünftig wird das Unternehmen nur noch dafür genutzt, womit es groß geworden ist: Die Internetsuche – und das auch möglichst nicht direkt über eine Google-Domain, sondern Startpage o.ä.

  • Project re:oyd – re:own your data

    Früher hatten wir Angst, den USB-Stick zu verlieren – häufig weniger, weil der Finder auf die eigenen Daten hätte zugreifen können (das wäre mit einer Verschlüsselung leicht zu umgehen gewesen), sondern, weil wir viel zu oft aktuellste Daten transportierte und die letzte Sicherung mit Sicherheit schon etliche Zeit zurücklag. Heute alles kein Problem mehr, es gibt ja Dropbox / iCloud / SkyDrive …

    Schöne neue Welt. Jetzt brauchen wir nicht mehr darauf vertrauen, dass wir den USB-Stick nicht verlieren. Jetzt vertrauen wir Firma XY, dass sie unsere Daten nicht verliert. Mehr noch, wir vertrauen darauf, dass unsere Daten nicht (ohne unsere Einwilligung) weitergegeben, verändert oder ausgewertet werden. Unsere Daten sind jetzt zwar immer und überall für uns verfügbar, die Kontrolle über sie haben wir aber abgegeben. Zeit sie uns wieder zu holen – die Kontrolle und die Daten.
    Das ist die Idee hinter meinem Projekt re:oyd – re:own your data.

    Es geht aber nicht nur um Datei-Daten, sondern auch um alle anderen persönlichen Daten. Wir sollte öfter mal darüber nachdenken, welche Informationen wir wo überall hinterlegen/ hinterlegt haben – und ob das überhaupt nötig ist. Zeit für eine umfassende „digitale Diät“ 😉