Um es gleich vorweg zu nehmen: ich nutze diverse Google-Services und Dropbox und muss gestehen: das ist schon richtig geil. Nur der Gedanke damit meine Daten aus der Hand zu geben gefällt mir einfach nicht. Also wer Dropbox, Google Calendar usw. ohne schlechtes Gewissen nutzt – für den lohnt sich owncloud nicht. Auf diesem Level spielt owncloud einfach nicht, jedenfall jetzt noch nicht.

Vorbereitungen

Vorab muss dem lighttpd erstmal php beigebracht werden. Dazu werden erstmal diverse php-Packages gebraucht, bei mir sind zur Zeit installiert:

php5, php5-cgi, php5-sqlite, php5-suhosin, php5-gd, php5-curl, php5-cli

.
Dank irgendwelcher Abhängigkeiten ist damit auch gleich ein ganzer apache auf dem armen kleinen sheeva gelandet, dem wird per rcconf erstmal der automatische Start verboten. Still rumliegen darf er gerne weiter.

Dann wird dem lighttpd in der /etc/lighttpd/lighttpd.conf erklärt, was er mit dem php-Zeugs anfangen soll:

static-file.exclude-extensions = ( ".php", ".pl", ".fcgi" )
fastcgi.server = ( ".php" => ((
  "bin-path" => "/usr/bin/php5-cgi",
  "socket" => "/tmp/php.socket"
)))

Bis dahin erstmal testen, also eine index.php in das server.document-root gepackt und nachgeschaut, ob im Browser was ankommt.

Owncloud installieren

Das ist einfach: Package runterladen, unter dem server.document-root auspacken und per Webbrowser konfigurieren. Auf der Homepage liegt eine Installationsanleitung, der ist nichts hinzuzufügen.

Wichtig: der lighttpd kennt kein .htaccess, also folgt man der Anleitung von owncloud und verbietet den direkten Zugriff auf die Daten-Verzeichnisse:

$HTTP["url"] =~ "^/owncloud/data/" {
url.access-deny = ("")
}
$HTTP["url"] =~ "^/owncloud($|/)" {
dir-listing.activate = "disable"
}

Die Konfiguration erfolgt einfach im Browser. Clients gibt es für alle Plattformen oder man nutzt einfach den Zugang per webdav.

Die grundlegenden Funktionen tun was sie sollen. Ich nutze momentan nur die Dateiablage, Kalender und Co. habe ich noch nicht getestet. Die Clients sind ziemlich schlicht, mir ist es zB. weder und Windows noch Linux gelungen herauszufinden, wie der aktuelle Status des Synch ist. Man erfährt nur, ob er gerade synct oder nicht. Welche Dateien betroffen sind, wie lange das wohl noch dauert usw. – darüber wird höflich geschwiegen. Hier merkt man deutlich den frühen Status.

Unter Android warte ich geduldig, bis der ES-File-Explorer (mein Lieblings-File-Browser) owncloud kennt. Und unter Linux/Windows kann ich mit dem schlichten nativen Client bzw. einem Zugriff per Browser gut leben.

Also prinzipiell ganz einfach – Portweiterleitung an der FritzBox einrichten, entsprechende Dienste auf sheeva laufen lassen und schon fertig. Der Teufel liegt im Detail: unterwegs ist meist nur ein Zugriff auf Port 443 (https) möglich (oft auch Port 80 http – da aber der Traffic hier öffentlich einsehbar ist, schauen viele Firewalls sich die Pakete an und machen zu, wenn sie kein http-Protokoll sehen. Ein ssh-Zugang funktioniert so meist nicht. Über Port 443 geht verschlüsselter Verkehr, da kann eh niemand reinschauen. Aber ich will beides, ssh und https. Das Zaubertool hierfür ist sslh. Vorher müssen wir allerdings einiges erledigen.

Achtung: wir basteln hier an unserem Zugang zum System, wenn es dumm läuft, sind wir draussen. Ganz Vorsichtige schalten sich also für die Zeit noch ein telnet frei oder starten einfach einen sshd von Hand auf einem ganz anderen Port.

SSH einrichten

Die Konfig für den SSH-Server finden wir in /etc/ssh/sshd_config, Port 22 beschränke ich auf lokale Verbindungen – hier dockt später der sslh an. Um auch ohne sslh noch auf das System zu kommen, lasse ich den sshd zusätzlich noch auf Port 2022 lauschen. Dafür braucht es diese beiden Zeilen in der config:

ListenAddress 127.0.0.1:22
ListenAddress 0.0.0.0:2022

Ob das geklappt hat, kann man (nach einem Neustart des sshd) einfach anhand des netstat sehen:

root@sheeva:/# netstat -alpn |grep tcp | grep ssh
tcp        0      0 127.0.0.1:22            0.0.0.0:*               LISTEN      834/sshd        
tcp        0      0 0.0.0.0:2022            0.0.0.0:*               LISTEN      834/sshd        
tcp        0      0 127.0.0.1:22            127.0.0.1:57597         ESTABLISHED 4898/sshd: mathias

Die ersten beiden Zeilen zeigen, dass der sshd auf Port 22 auf localhost und Port 2022 auf allen interfaces lauscht. Die letzte Zeile ist meine aktuelle Session, ich bin schon über localhost:22 drin, also läuft offenbar der sslh schon.

Webserver einrichten

Passend zum sheeva ist das bei mir ein lighttpd. Dem muss ich also nun ssl beibringen und ihn auf die richtigen Ports biegen. Beides recht einfach, für Ersteres legen wir ein Verzeichnis /etc/lighttpd/certs/ und erzeugen dort das Zertifikat:

openssl req -new -x509 -keyout lighttpd.pem -out lighttpd.pem -days 3000 -nodes

Das ist natürlich nur ein self-signed, d.h. jeder Browser wird beim Zugriff da drauf erstmal genau deswegen meckern. Für mich reichts aber, der Verschlüsselung tut das keinen Abbruch.

Dann machen wir das Zertifikat noch beim Webserver bekannt und regeln die Sache mit den Ports, alles in der lighttpd.conf:

$SERVER["socket"] == "127.0.0.1:8443" {
ssl.engine = "enable"
ssl.pemfile = "/etc/lighttpd/certs/lighttpd.pem"
}

Den lighttpd neu starten und wieder per netstat prüfen:

root@sheeva:/# netstat -alpn |grep tcp |grep lighttpd
tcp        0      0 127.0.0.1:8080          0.0.0.0:*               LISTEN      2556/lighttpd   
tcp        0      0 127.0.0.1:8443          0.0.0.0:*               LISTEN      2556/lighttpd

sslh einrichten

Der letzte Schritt ist nun der Einfachste. In der /etc/default/sslh steht die Konfig vom sslh, für mich sind das die beiden Zeilen:

RUN=yes
DAEMON_OPTS="-v -u sslh -p 0.0.0.0:443 -s 127.0.0.1:22 -l 127.0.0.1:8443 -P /var/run/sslh.pid"

Also der sslh lauscht an allen Interfaces auf Port 443, schickt ssh-Traffic an localhost:22 und https-Traffic an localhost:8443, an die beiden Ports hatten wir ja zuvor sshd und lighttpd gebunden.

Jetzt noch einmal von Aussen einloggen und schauen ob alles geht.