Open vSwitch + SDN – aus dumm mach schlau

Verbindet man Open vSwitch mit einem SDN-Controller (z.B. OpenDaylight), ist das Netzwerk ersteinmal tot. Erst mit dem Hinzufügen von Regeln bekommt das Netz wieder in Gang. Für Basiskommunikation benötigt es Regeln, welche ARP- und IP-Traffic berücksichtigen. Dazu müssen folgende Fälle berücksichtigt werden:

  1. ARP-Traffic an die Broadcastdomain
  2. ARP-Traffic an einen bestimmten Host
  3. IP-Traffic an deinen bestimmten Host

Die Regel für den ersten Fall muss alle ARP-Pakete an die Broadcastdomain über alle Interfaces weiterleiten, damit es den Zielhost erreichen kann:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<flow xmlns="urn:opendaylight:flow:inventory">
    <flow-name>arp2broadcast</flow-name>
    <table_id>0</table_id>
    <id>0</id>
    <priority>100</priority>	
    <instructions>
        <instruction>
            <order>0</order>
	     <apply-actions>		
                <action>
                    <order>1</order>
                    <output-action>
                        <output-node-connector>ALL</output-node-connector>
                        <max-length>200</max-length>
                    </output-action>
                </action>    
	     </apply-actions>
        </instruction>
    </instructions>
    <match>
   <ethernet-match>
            <ethernet-type>
                <type>2054</type>
            </ethernet-type>
	   <ethernet-destination>
                <address>ff:ff:ff:ff:ff:ff</address>
            </ethernet-destination>
   </ethernet-match> 
  </match>
</flow>

Für Fall 2 muss die Ethernetzieladresse und der Output-Port angepasst werden. Jeder Host im Netzwerk benötigt einen solchen Eintrag, damit die Pakete entsprechend geroutet werden können:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<flow xmlns="urn:opendaylight:flow:inventory">
    <flow-name>arp2linuxadmin</flow-name>
    <table_id>0</table_id>
    <id>3</id>
    <priority>100</priority>	
    <instructions>
        <instruction>
            <order>0</order>
            <apply-actions>
                <action>
                    <order>1</order>
                    <output-action>
                        <output-node-connector>4</output-node-connector>
                        <max-length>200</max-length>
                    </output-action>
                </action>
            </apply-actions>
        </instruction>
    </instructions>
    <match>
   <ethernet-match>
            <ethernet-type>
                <type>2054</type>
            </ethernet-type>
	   <ethernet-destination>
                <address>52:54:00:34:85:00</address>
	   </ethernet-destination>
   </ethernet-match> 
  </match>
</flow>

Der Rechner mit der MAC-Adresse 52:54:00:34:85:00 ist über Port 4 erreichbar, der Ethernet-Type 2054 matcht ARP-Pakete. In diesem Fall wird das einfachste Szenario, die VMs sind direkt an den Switch angeschlossen, betrachtet. Sind VMs über einen weiteren Switch angeschlossen, muss der Output-Port der Regeln entsprechend angepasst werden.

Um IP-Pakete zu erfassen, wird der Ethernet-Type entsprechend angepasst:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<flow xmlns="urn:opendaylight:flow:inventory">
    <flow-name>linuxadmin</flow-name>
    <table_id>0</table_id>
    <id>102</id>
    <priority>100</priority>
    <instructions>
        <instruction>
            <order>0</order>
            <apply-actions>
            	<action>
		    <order>1</order>
                    <output-action>
                        <output-node-connector>4</output-node-connector>
                        <max-length>200</max-length>
                    </output-action>
                </action>
            </apply-actions>
        </instruction>
    </instructions>
    <match>
   <ethernet-match>
            <ethernet-type>
                <type>2048</type>
            </ethernet-type>
            <ethernet-destination>
                <address>52:54:00:34:85:00</address>
            </ethernet-destination>
   </ethernet-match>
   </match>
</flow>

Damit ist eine Grundkommunikation im Netzwerk hergestellt. Weitere, tiefer greifende Konfigurationsmöglichkeiten – wie das setzen von VLAN-Tags oder filtern von bestimmten Pakettypen – ist möglich: https://wiki.opendaylight.org/view/Editing_OpenDaylight_OpenFlow_Plugin:End_to_End_Flows:Example_Flows

HTTP-BASIC-AUTH nach Umleitung auf HTTPS

Eine HTTP-BASIC-AUTH-Authentifizierung sollte man nicht unverschlüsselt durchs Netz jagen. Doof ist es, wenn die Umleitung per .htaccess erst nach der Authentifizierung greift, da die erste Anfrage über HTTP läuft, von der Authentifizierung abgefangen wird und erst danach umgeleitet wird.
Eine Möglichkeit dies zu umgehen sieht so aus:

SetEnvIf %{SERVER_PORT} ^80$ IS_NON_SSL

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

AuthUserFile /pfad/zur/.htpasswd
AuthName "HTTP-BASIC-AUTH über TLS"
AuthType Basic
require valid-user
Allow from env=IS_NON_SSL

via http://stackoverflow.com/questions/10267102/apache-htaccess-redirect-to-https-before-asking-for-user-authentication

Let’s encrypt!

Seit einiger Zeit bietet “Let’s encrypt” seine SSL-Zertifikate in einer geschlossenen Beta-Phase an.
Die CA möchte schnell und einfach Zertifikate für jeden anbieten. Dies geschieht über ein Tool, welches über die Shell ausgeführt wird. Es kümmert sich um die Erstellung des Private-Keys, des CSR, die Validierung der Domain und die Erzeugung des Zertifikates.
“Let’s encrypt” wird direkt aus den GIT-Repos heruntergeladen und ausgeführt. Dabei werden z.T. noch benötigte Pakete nachinstalliert.
Zertifikate werden anschließend über
systemctl stop httpd
cd letsencrypt
./letsencrypt-auto --agree-dev-preview --rsa-key-size 4096 --server https://acme-v01.api.letsencrypt
.org/directory certonly
systemctl start httpd

angefragt. Dabei wird über Port 80 des Servers kommuniziert, was ich etwas unschön finde, da man vorher einen laufenden Webserver beenden muss.
Die Zertifikate sind nur 90 Tage lang gültig, danach müssen sie erneuert werden. Dies kann automatisch über einen Cronjob geschehen, ein weiteres Eingreifen durch den Benutzer ist nicht mehr nötig.
./letsencrypt-auto --agree-dev-preview --renew-by-default --server https://acme-
v01.api.letsencrypt.org/directory -d johnassel.de -d www.johnassel.de certonly
erneuert schon vorhandene Zertifikate. Auch hier muss ein laufender Webserver für den Vorgang beendet werden.
Leider kann man “Let’s encrypt” nicht schon vorhandene CSRs signieren lassen. Diese Schritte übernimmt die Software. Mir wäre es lieber, wenn ich Key und CSR selbst generieren könnte, einen Einfluss kann man aktuell auf die Länge des Schlüssels wohl noch nicht haben.
Auch bietet “Let’s encrypt” die Möglichkeit, direkt die Konfiguration von Apache etc für die generierten Schlüssel und Zertifikate anzupassen. Irgendwie habe ich dabei Bauchschmerzen, wenn eine Software versucht meine Konfiguration anzupassen.
Mit entsprechenden Scripten sollte es aber kein Problem sein, den Vorgang der Zertifikaterstellung so zu scripten, dass “Let’s encrypt” nicht noch in der Konfiguration rumwurschteln muss.

OpenStack schnell und einfach auf einem Host installieren

OpenStack auf einem einzigen Host aufzusetzen kann viel Handarbeit bedeuten, muss aber nicht. Über packstack des RDO-Projekts lässt sich OpenStack schnell und einfach installieren und konfigurieren. Zwar bringt Ferdora 22 Packstack von Haus aus mit sich, das Skript scheint aber noch nicht angepasst zu sein. Auf CentOS 7 lief die Installation ohne Probleme durch – nach 30 Minuten war OpenStack installiert und einsatzbereit.

Kompletten Netzwerkverkehr per iptables umleiten

Um den kompletten Netzwerkverkehr per iptables zu einer anderen Adresse umzuleiten, muss zunächst die Weiterleitung von IP-Paketen im System aktiviert werden (sysctl -w net.ipv4.ip_forward=1).
Als nächstes aktiviert man die eigentliche Weiterleitung mit folgenden Regeln:
iptables -t nat -A PREROUTING -s 0.0.0.0/0 -p all -j DNAT --to-destination $ipdeszielsystems
iptables -t nat -A POSTROUTING -j MASQUERADE

Bei mir kommt die Umleitung immer dann zum Einsatz, wenn ich einen vServer migriert habe, sich die IP gewechselt hat und nur noch die neuen Einstellungen des DNS-Servers wirksam werden müssen. Dies kann 24h dauern, wodurch Zugriffe auf das alte und neue System erfolgen können. Damit dies nicht passiert, leitet das alte System auf das neue um.
Nachteil: Auch der SSH-Zugriff wird umgeleitet, sodass auf dem Altsystem nur noch per VNC-Konsole über den Host zugegriffen kann. Zudem erscheinen alle umgeleiteten Zugriffe auf dem neuen System mit der IP-Adresse des alten Systems.

Mit Netz und doppeltem Boden – Backup für den vServer

Wer einen eigenen Server betreibt sollte auf jeden Fall eine Backup-Strategie fahren, um im Falle eines Crashes/Angriffes keine wichtigen Daten zu verlieren. Bis jetzt bestand meine Lösung aus einem NFS-Share, welches mein Hoster zur Verfügung stellte, und einem Scrip, welches den kompletten vServer in ein TAR-Archiv schob, komprimierte und verschlüsselte:


#!/bin/sh
mount $ADRESSEDESNFSSHARES /storage/ -t nfs
systemctl stop mariadb
key=`openssl rand 128 -hex`
echo $key > key
path=/storage/`date +"%d-%m-%y"`
mkdir $path
openssl rsautl -encrypt -inkey public.key -pubin -in key -out $path/key.`date +"%d-%m-%y"`.enc
rm key
tar -cO --exclude='/proc' --exclude='/sys' --exclude='/backup' --exclude='/storage' --exclude='buildroot.img' /* | pbzip2 -c | ccrypt -K $key > $path/backup.`date +"%d-%m-%y"`.tar.bz2.cpt
systemctl start mariadb
umount /storage

Was tut dieses Script? Es generiert einen 128 Bit langen Verschlüsselungsschlüssel, welcher mit einem öffentlichen Schlüssel verschlüsselt wird. Der Verschlüsselungsschlüssel wird zur (symmetrischen) Verschlüsselung des komprimierten TAR-Archives genutzt. Beides wird anschließend auf dem NFS-Share gespeichert. Damit das TAR-Archiv nicht zwischengespeichert werden muss, werden alle Vorgänge (Packen, Komprimieren und Verschlüsseln) durch Pipes miteinander verbunden. Der große Nachteil dieser Lösung ist, dass es sehr zeitaufwändig ist, eine einzelne Datei wiederherzustellen. Zuerst muss das Archiv entschlüsselt, dekomprimiert und entpackt werden, was entsprechend dauern kann.
Auf der Suche nach einer besseren Lösung bin ich über duplicity gestolpert. Das Tool bietet die Möglichkeit, verschlüsselte, inkrementelle und einfach wieder herzustellende Sicherungen zu erstellen.


#!/bin/sh
mount $ADRESSEDESNFSSHARES /storage/ -t nfs
#systemctl stop mariadb
PASSPHRASE='GPGSCHLÜSSELHIERREIN'
SIGN_PASSPHRASE='GPGSCHLÜSSELHIERREIN'
export PASSPHRASE
export SIGN_PASSPHRASE
duplicity --exclude /var/tmp --exclude /tmp --exclude /proc --exclude /sys --encrypt-key 987AAD58 --sign-key 987AAD58 -v 8 / file:///storage > /var/log/backup/backup.log
duplicity remove-older-than 3W file:///storage > /var/log/backup/backup_cleanup.log
#systemctl start mariadbi
unset PASSPHRASE
unset SIGN_PASSPHRASE
umount /storage

Die Handhabung ist relativ einfach. Zunächst erstellt man einen GPG-Schlüssel. Anschließend läuft bei mir obiges Script, gesteuert per Cronjob, alle zwei Stunden durch. Über duplicity remove-older-than 3W werden alle Sicherungen, welche älter als 3Wochen sind, gelöscht. Die Wiederherstellung von Dateien erfolgt über duplicity –file-to-restore. Im Moment macht die Lösung einen ganz soliden Eindruck. Hoffentlich tut sie das im richtigen Ernstfall weiterhin.
Ach ja:
Auf jeden Fall die GPG-Schlüssel und den zugehörigen Key extra sichern! Ohne ist das Backup nicht mehr zu entschlüsseln!

Alles unter Kontrolle

Mittlerweile muss ja alles irgendwo in der Cloud liegen. Kalender, Kontakte und Mails bei Google, Bilder bei Flickr/Picasa, Dateien bei Dropbox/Box/SkyDrive und so weiter… Es ist ja ganz praktisch, alles immer und überall verfügbar zu haben. Doch was ist, wenn es Anbieter xyz nicht mehr gibt, sein Geschäftsmodell ändert oder man einfach Bedenken hat, seinen ganzen Kram irgendwelchen Diensten anzuvertrauen? Gerade die ersten beiden Punkten waren für mich ausschlaggebend, so viel wie möglich selbst in die Hand zu nehmen.
Auslöser dafür war Google mit der Einstellung des Google Readers. Nur weil der RSS-Reader (vermutlich) kein Geld eingebracht hat und für Google überflüssig erschien, wurde er kurzerhand eingestampft. Im Prinzip kann dies auch mit allen anderen Diensten passieren – wobei das schon der Worst-Case ist. Seit dem habe ich versucht, so viel wie möglich von irgendwelchen externen Anbietern wegzubekommen und selbst zu hosten.

Mails
Angefangen hat es mit E-Mails. Die Einrichtung eines Mailservers war eigentlich das schwierigste – bis das Ding gemacht hatte, was ich wollte hat es schon etwas gedauert. Doch es hat sich auf jeden Fall gelohnt. Keine Beschränkungen mehr, dass man z.B. nur x Filter oder y Unterordner einrichten darf. Auch speichertechnisch war es ein gewaltiger Fortschritt. Die Mailbox war plötzlich so groß was die Festplatte des Servers hergab. Ein weiterer Vorteil: Irgendwelche Anbieter konnten jetzt nicht mehr in den Mails rumschnüffeln – und vor allem war sie werbefrei!

RSS
Als nächstes habe ich einen Ersatz für den Google Reader gesucht. Meine Wahl viel hier sehr schnell auf TinyTinyRSS (TT-RSS). Für TT-RSS reicht es, einen Webserver mit PHP Unterstützung zu haben. Im Prinzip sollte es also auch auf einem simplen Webspace laufen. Ein wichtiges Entscheidungskriterium war für mich die Android-Unterstützung. Und die hat TT-RSS in Form einer Android-App. Neben der offiziellen App gibt es auch diverse Alternativen.

Kalender und Kontakte
Dann kamen Kalender und Kontaktdaten an die Reihe. Bis dahin hatte ich alles bei Google liegen. Doch warum sollte ich Google all meine Kontakte und Termine offenbaren? Die Auslagerung hier ist etwas schwierig, da auch der Sync mit Android gegeben sein muss. Vorher hatte ich schon mal mit SyncML und eGroupware experimentiert, was aber mehr schlecht als recht lief. Alternativen sind CalDAV/CardDAV oder MS-Exchange. Für die erste Möglichkeit bietet Android keine native Unterstützung und man ist auf externe Tools angewiesen. Für die Umsetzung von MS-Exchange gibt es mehrere Tools – meine Wahl ist dabei auf Tine 2.0 gefallen, einer Open-Source Groupware. (Gut, andere Programme habe ich nicht wirklich getestet, da Tine auf Anhieb funktionierte ;-))
Die Synchronisation mit Android funktioniert ohne Probleme und auch ein WebOS-Gerät habe ich damit im Einsatz. Zudem bietet Tine ein (meiner Meinung nach) schickes Webinterface an, welches eine Desktop-Software durchaus ersetzen kann.
Der große Vorteil von Tine 2.0 ist u.a., dass Repositories für diverse Linux-Distributionen angeboten werden und es so bequem per Paketmanager aktuell gehalten werden kann. Eine manuelle Installation ist aber auch möglich, sodass Tine auch auf einem Webspace lauffähig ist.

Dateien
Wenn man schon mal dabei ist alles mögliche selbst zu hosten, war bei mir der nächste Punkt die Ersetzung von Dropbox, Box und Skydrive. Hierzu bietet sich OwnCloud an. Die PHP-Software bietet neben der Synchronisation von Dateien zwischen mehreren Geräten auch Funktionen Kalender, Aufgaben, Kontakte etc an. Der große Vorteil von OwnCloud ist, dass die Schnittstelle für die Synchronisation auf offenen Standards (WebDAV, CalDAV, CardDAV) aufsetzt. Dadurch ist man nicht unbedingt an die offiziellen Clients (welche es für Windows, Linux, MacOS, Android und iOS gibt) gebunden. Auch wird der Up- und Download nur durch die Anbindung des Servers begrenzt. Bei Dropbox kam es bei mir oft vor, dass ich nicht die volle verfügbare Bandbreite ausnutzen konnte. Weiterhin ist es möglich, beliebig viele Quellverzeichnisse zu synchronisieren. Man ist so nicht auf einen einzelnen Ordner beschränkt. Freigaben für z.B. Freunde, auf welche dann ohne Anmeldung zugegriffen werden kann, sind natürlich auch möglich.

Bilder
Bevor Flickr für die kostenlose Nutzung die Beschränkungen entfernt bzw. stark gelockert hat, war der Dienst für mich eher uninteressant. Alternativen waren entweder gruselig zu benutzen oder verlangten schon für den kleinsten Account Geld. Also hieß es auch hier: selbst hosten!
Meine Wahl viel hierbei auf Coppermine. Das Tool bietet viele Schrauben, an denen man es einstellen und nach seinen Bedürfnissen einrichten kann. Neben öffentlichen Galerien ist es möglich, Alben mit einem Passwort zu schützen, das Design anzupassen wie man es gerne hätte, mit mehreren Benutzern zu arbeiten etc.
Clients für Android gibt es leider nicht, wobei ich den auch nicht wirklich brauche (habe ich auch bei Flickr nie genutzt).

DynDNS
Ein weiterer großer Brocken (neben E-Mails) war die Einrichtung eines eigenen DyDNS-Dienstes. Da dyn.com sein Modell für kostenlose Accounts umgestellt hat, mit dem Ziel einen Richtung Bezahl-Accounts (mit dessen Preisen ich nicht so wirklich einverstanden war) zu drängen, war es Zeit für mich zu wechseln. Irgendwann kam dann die Idee, diesen Dienst selbst umzusetzen (siehe Bastelstunde: Der eigene DynDNS-Dienst), was mit einer mehr oder weniger großen Bastelaktion verbunden war, welche zudem nicht ganz ungefährlich war (wenn man mit dem DNS-Server Mist baut, läuft man Gefahr für die nächsten maximal 24h “offline” zu sein).

So viel wie möglich selbst hosten hat Vorteile und Nachteile. Man hat all seine Daten unter Kontrolle und kann mehr oder weniger machen was man möchte.
Andererseits benötigt man mehr oder wenig gute Kenntnisse darüber, was man macht. Auch steht und fällt alles mit dem Anbieter, bei dem man den Server, vServer oder Webspace gemietet hat. Andererseits hat man die freie Auswahl, bei welchem Anbieter man hosten möchte und kann bei Bedarf wechseln. Natürlich ist es auch möglich, alles auf einem Homeserver bei sich zu Hause unter dem Tisch zu betreiben. Allerdings ist es dann eher schwierig, einen eigenen Mailserver (Mail-Anbieter wie GMX, web.de, Yahoo!, Google… nehmen aus Gründen der Spamvermeidung keine Mails von dynamischen IP-Adressen an) oder DynDNS Dienst zu betreiben. Die anderen Dienste sind aber problemlos nutzbar.

Bastelstunde: Der eigene DynDNS-Dienst

Seit, ich glaube 2007, war ich Nutzer des DynDNS-Dienstes des gleichnamigen Anbieters. Auf die Arbeitsweise von DynDNS will ich hier nicht genauer eingehen, da verweise ich lieber auf den entsprechenden Wikipedia-Eintrag: http://de.wikipedia.org/wiki/Dynamisches_DNS
In Kürze: wie bei statischem DNS wird hier ein Hostname einer IP zugeordnet, nur mit dem Unterschied, dass die IP dynamisch ist und sich jederzeit ändern kann.
Bis vor kurzem musste sich die IP-Adresse zu einem Hostnamen mindestens einmal im Monat ändern, damit der Eintrag aktiv blieb. Seit neustem reicht dies aber nicht mehr: Nun muss man sich mindestens einmal im Monat über die Webseite einloggen, sonst wird der komplette Account gelöscht. Alternativ hat man die Möglichkeit auf “Dyn Pro” umzusteigen, für 10 USD im ersten Jahr, danach 25 USD – für mich also keine wirkliche Option. Also mussten weitere Alternativen her.
Möglichkeit 1: no-ip.com – hier muss im Moment nur die IP mindestens 1x alle 30 Tage aktualisiert werden, aber wer weiß wann man auch hier sich 1x aktive einloggen muss.
Möglichkeit 2: Die Do-It-Yourself Methode. Etwas umständlich, aber dafür hat man den Kram komplett unter der eigenen Kontrolle.
Und um Möglichkeit 2 geht es jetzt hier.
Was man benötigt:
– Linux-Kenntnisse
– einen vServer/root-Server
– eine Domain
– einen Nameserver, dem man neue Tricks beibringen kann ;-)

Grundlage meiner Basteleien war folgende Anleitung, welche ich zum Teil abgewandelt habe: http://andrwe.org/linux/own-ddns.
Umgesetzt habe ich sie unter Debian 7 mit Bind9.
Zuerst habe ich den TSIG-Key über
dnssec-keygen -a hmac-sha256 -b 256 -n HOST dyndns.johnassel.de
generiert und unter /etc/bind abgelegt. Der wichtige Teil liegt in der erzeugten .private Datei: Über den dort hinterlegten Key wird es später möglich sein, die DNS-Einträge zu aktualisieren. Dafür habe ich in /etc/bind/named.conf.default-zones die folgenden beiden Einträge hinzugefügt:

key dyndns.johnassel.de. {
algorithm HMAC-SHA256;
secret "generierterganzgeheimerKey";
//Festlegung des Schlüssel, über welchen man sich authentifiziert um die Einträge für die Subdomain ändern zu können
};
zone "dyndns.johnassel.de" {
type master;
file "/var/cache/bind/zones/johnassel.de.zone"; //Definition der Zonen-Datei
allow-update {
key dyndns.johnassel.de.; //Verweis auf den Key
};
};

Jetzt weiß der Nameserver, dass er für die Zone “dyndns.johnassel.de” zuständig ist.
Damit Hostnamen auch IP-Adressen zugeordnet werden können, muss die oben definierte Zonendatei angelegt werden:

$ORIGIN .
$TTL 300 ; 5 minutes
dyndns.johnassel.de IN SOA ns.johnassel.de. root.johnassel.de. (
2013051307 ; serial
3600 ; refresh (1 hour)
1800 ; retry (30 minutes)
604800 ; expire (1 week)
1800 ; minimum (30 minutes)
)
NS ns.johnassel.de.
$ORIGIN dyndns.johnassel.de.

Da es sich hier um dynamische DNS-Einträge handeln wird, habe ich die TTL-auf 5 Minuten gesetzt. Bei den üblichen 24 Stunden müsste man im schlechtesten Fall einen Tag warten, bis IP-Änderungen der dynamischen Hosts wirksam werden – was doch sehr unpraktisch ist ;-)
Theoretisch wäre es möglich, die Zone-File schon mit Einträgen zu füllen. Allerdings wären diese dann statisch und würden bei einer Änderung der IP-Adresse des DynDNS-Clients ins Leer führen.
Also muss noch etwas Dynamik in die Sache gebracht werden.
Dafür kommt folgendes PHP-Script zum Einsatz:


<?php
$ip = $_SERVER['REMOTE_ADDR'];
shell_exec("/usr/bin/nsupdate -k /etc/bind/Kdyndns.johnassel.de.*.private <<EOF
server localhost
zone dyndns.johnassel.de
update delete home.dyndns.johnassel.de A
update add home.dyndns.johnassel.de 300 A $ip
send
EOF
");
shell_exec("/usr/sbin/rndc reload");
print("updated home.dyndns.johnassel.de to $ip" . PHP_EOL);
?>

Dieses wird irgendwo auf dem Webserver (welcher auf der gleichen Maschine laufen muss, auf welchem der DNS-Server läuft) abgelegt. Wird das Script nun abgerufen, so wird für den Eintrag “home.dyndns.johnassel.de” die aufrufende IP gesetzt. Damit der Vorgang auch automagisch abläuft, habe ich auf meinem Homeserver einen cronjob eingerichtet, welcher das Scipt jede Minute abruft.

*/1 * * * * wget --http-user="home" --http-passwd="geheimsageichnicht" http://url/zum/php/script > /dev/null

Damit nicht jeder die IP-Adresse ändern kann, empfiehlt es sich das Script per .htaccess und .htpasswd zu schützen, optimalerweise über eine SSL-gesicherte Verbindung, da sonst das Passwort im Klartext übertragen wird (unschön, macht man nicht ;-))

Jetzt fehlt nur noch eine Sache: Die Delegation der Namensauflösung der Subdomain auf den gerade konfigurierten DNS-Server.
Dies muss am Nameserver geschehen, der die Domain (in meinem Fall johnassel.de) verwaltet. Über die Einträge
dyndns 300 IN NS ns.johnassel.de.
und
ns A 46.38.242.191
wird die Delegation realisiert.
Anschließend sollten die DynDNS-Clients über ihre Adresse erreichbar sein.
Möchte man weitere Clients hinzufügen, so reicht es das obige PHP-Script zu kopieren und entsprechend anzupassen.
Im Prinzip ganz einfach, oder? ;-)

Die eigene Cloud mit ownCloud – Der Anfang

Die neuen NetCup KVM-vServer bringen im Vergleich zu den alten Angeboten gleich einiges mehr an Speicher mit sich. Dies bietet sich doch geradezu für eine eigene Cloud an wie ich finde.
Meine Wahl fiel dabei auf ownCloud, da man dieses System auch mit einem Desktop- und Android-Client nutzen kann (nen iOS Client gibts auch, war für mich aber eher uninteressant).
Die Installation war eher simpel, für Debian gibt es eigene Repos welche man einbindet und dann die Installation mit “apt-get update && apt-get install owncloud” beginnt. Pakete, die nicht installiert sind aber benötigt werden, werden automatisch mit installiert (Abhängigkeiten und so ;-)). ownCloud benötigt einen eigenen Apache2, dieser war bei mir schon eingerichtet, so musste ich nur einen neuen VirtualHost zum ownCloud Verzeichnis hinzufügen. Da sich ownCloud unter Debian nach /var/www/owncloud installiert, konnte ich einen bestehenden vHost einfach als Grundlage nehmen. Die entsprechende Konfigurationsdatei sah anschließend so aus:

root@johnassel:/# cat /etc/apache2/sites-enabled/owncloud-ssl
<IfModule mod_ssl.c>
<VirtualHost *:443>
        SSLProxyEngine on
        ServerAdmin webmaster@localhost
        ServerAlias owncloud.johnassel.de
        DocumentRoot /var/www/owncloud
        <Directory />
                Options FollowSymLinks
                AllowOverride All
        </Directory>
        <Directory /var/www/owncloud>
                Options Indexes FollowSymLinks MultiViews
                AllowOverride All
                Order allow,deny
                allow from all
        </Directory>		
        LogLevel warn
        CustomLog ${APACHE_LOG_DIR}/ssl_access.log combined
        SSLEngine on
        SSLCertificateFile    /pfad/zum/ssl/zertifikat
        SSLCertificateKeyFile /pfad/zum/ssl/key
        SSLCertificateChainFile /pfad/zur/ca/kette
        <FilesMatch "\.(cgi|shtml|phtml|php)$">
                SSLOptions +StdEnvVars
        </FilesMatch>
        <Directory /usr/lib/cgi-bin>
                SSLOptions +StdEnvVars
        </Directory>		
        BrowserMatch "MSIE [2-6]" \
                nokeepalive ssl-unclean-shutdown \
                downgrade-1.0 force-response-1.0
        BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown
</VirtualHost>
</IfModule>

 

Anschließend musste ich nur noch den Apache neu starten, dann war die neue Cloud unter https://owncloud.johnassel.de erreichbar. Beim ersten Zugriff musste ein Admin-Account angelegt werden, eine Datenbank oder sowas muss nicht eingerichtet werden. Danach konnte es auch sofort losgehen – der Desktop-Client und Android-Client hatten sofort Zugriff auf den Speicher. Die ersten Tests sahen ganz gut aus, neue und geänderte Dateien im ownCloud Verzeichnis auf dem PC wurden erkannt und hochgeladen, ganz so wie man es auch von Dropbox her kennt.
Ein paar kleine Dinge, die wünschenswert sind gibt es allerdings doch: So gibt es beim Client keine Bandbreitenbeschränkung und es wird genutzt was verfügbar ist – ohne Rücksicht auf Verluste. Auch fehlt mir eine Statusanzeige, beispielsweise wie schnell der Datentransfer gerade läuft und wie lange der Upload/Download noch dauern wird. Man sieht quasi nur das etwas passiert, mehr nicht.
Davon abgesehen sieht ownCloud eigentlich ganz gut aus, mal sehen wie es sich im Produktivbetrieb macht. ;-)