Anleitung zum Erstellen eines bootbaren USB-Stick als Installationsmedium unter OpenBSD – Teil 2

Vor etwas geraumer Zeit hatte ich hier ein HowTo erstellt, welches beschreibt wie man einen bootfähigen USB-Stick als Installationsmedium für OpenBSD erstellt. Seit Version 5.6 werden vom Projekt neben dem ISO-Image für die CD auch eine install56.fs zum Download angeboten. Es reicht lediglich, die Datei mit dd auf den USB-Stick hinüber zu kopieren.

dd if=install56.fs of=/dev/sd0

Im Beispiel ist die Laufwerkskennung des Sticks von OpenBSD mit sda angegeben. Je nach Betriebsssystem kann diese auch anders sein.
Statt der 56 im Dateinamen kann auch eine andere Kennung für die jeweilige Version stehen. Zum Beispiel install58.fs für die aktuelle Version 5.8.

Kobo Hacking Teil 2 – Bilder anzeigen

Da der Kobo-Mini über ein Touch-Display mit 800×600 Pixel verfügt, müssen Bilder erst einmal mit GIMP auf diese hinunter skaliert und in ein PNG-Datei mit 16 Graustufen (4 Bit) umgewandelt werden.
Anschliessend müssen die Bilder mit ffmpeg wieder in ein RAW-Format konvertiert werden.

ffmpeg -v quiet -vcodec png -i test.png -vcodec rawvideo -f rawvideo -pix_fmt rgb565 test.raw

Ist eine fertige Bilddatei auf den Kobo hinüber kopiert, so lässt sie sich mit:

cat test.raw | /usr/local/Kobo/pickel showpic

auf dem kleinen eBook-Reader darstellen.

Als ersten kleinen Hack habe ich mal ein paar Bilder umgewandelt und ein ganz simples Shell-Skript gebastelt, welches diese mit einer Zeitverzögerung in einer Endlosschleife darstellt. Somit lässt sich der Kobo als Digitalen Bilderrahmen umfunktionieren. – Wenn auch nur in schwarz-weiß.

#!/bin/sh
 
while true
do
	cat /mnt/onboard/Pictures/test01.raw | /usr/local/Kobo/pickel showpic
	sleep 60
	cat /mnt/onboard/Pictures/test02.raw | /usr/local/Kobo/pickel showpic
	sleep 60
	cat /mnt/onboard/Pictures/test03.raw | /usr/local/Kobo/pickel showpic
	sleep 60
	cat /mnt/onboard/Pictures/test04.raw | /usr/local/Kobo/pickel showpic
	sleep 60
	cat /mnt/onboard/Pictures/test05.raw | /usr/local/Kobo/pickel showpic
	sleep 60
done

Erstellen eines eigenen SSL-Server-Zertifikates

Nachdem ich mir vor sechs Wochen wieder ein vServerchen geleistet habe um meinen Senf in diesem Blog ablassen zu können, bin ich für mich mal die Frage durchgegangen wie ich das mit der Transportverschlüsselung löse. Denn früher hatte ich das nämlich bei dieser Domain noch nicht getan. Für mich war ganz klar, dass ich über meinem ISP keine zusätzliche 50,- Euro für ein von einer offiziellen Zertifizierungsstelle signiertes SSL/TLS-Zertifikat jährlich ausgeben werde. Die Lösung des Ganzen befindet sich sowieso in Form eigener Bordmittel in jedem Linux oder lässt sich im Zweifel auch auf anderen Systemen nachinstallieren. Im nachfolgenden werde ich meine eigene CA erstellen, um mir mein eigenes SSL-Zertifikat erzeugen zu können.

1. Erstellen der CA

Ist OpenSSL – beziehungsweise als Alternative neuerdings gerne auch LibreSSL – auf dem Rechner installiert, ist es mal der Ordnung halber praktisch sich einen Ordner ca anzulegen, wo die Dateien abgelegt werden sollen.

root@linux# mkdir /root/ca
root@linux# cd /root/ca

Die Gültigkeit setze ich mit 10 Jahren bewusst erst einmal sehr hoch an. Läuft die CA aus, so werden nämlich auch alle damit signierten Serverzertifikate ungültig. Die CA enthält einen geheimen Schlüssel, welcher automatisch erzeugt und in der Datei cakey.pem abgelegt wird. Das CA-Zertifikat wird nach cacert.pem geschrieben. Der folgende Befehl erzeugt einen Schlüssel für das Zertifikat mit einer Länge von 2048 Bit:

root@linux# openssl req -new -x509 -newkey rsa:2048 -keyout cakey.pem -out cacert.pem -days 3650
Generating a 2048 bit RSA private key
..............................................................
..............................................................
.........................................+++
......................................+++
writing new private key to 'cakey.pem'

Wer den geheimen Schlüssel der CA kennt, kann damit beliebige Serverzertifikate signieren. Deshalb wird diese Schlüsseldatei nicht im Klartext auf der Festplatte abgelegt, sondern mit einer Passphrase verschlüsselt. Diese Passphrase benötigt man immer dann, wenn mit dieser CA neue Zertifikate ausgestellt werden sollen.
Danach wird man gebeten, Daten einzugeben, welche die CA identifizieren. Diese werden dem Client angezeigt, wenn er aufgefordert wird, das Zertifikat zu akzeptieren oder abzulehnen. Der Code für Deutschland ist DE. Wenn ein Feld leer bleiben soll, so reicht es, einen Punkt ein zu geben. Ansonsten wird der in eckigen Klammern stehende Defaultwert eingetragen.
Das Feld Common Name (CN) ist hier der offizielle Name der Zertifizierungsstelle. Für die eigene CA reicht es, den eigenen Namen einzutragen.
Am Ende sind dann die Dateien cacert.pem und cakey.pem entstanden.
Vorsichtshalber sollten man die Rechte so setzen, dass die Schlüsseldatei nur für root lesbar ist.:

root@linux# chmod 600 cakey.pem

Mit dem Befehl

root@linux# openssl rsa -in cakey.pem -noout -text

kann man nun einmal prüfen, ob sich der Schlüssel mit der Passphrase öffnen lässt.

2. Schlüssel für das Serverzertifikat erzeugen

Nachdem nun die eigene CA vorhanden ist, kann diese nun endlich eigene Zertifikate herausgeben. Dazu wird zunächst ein 2048 Bit langer RSA-Schlüssel erzeugt, welcher mit AES 256 verschlüsselt auf der Platte abgelegt wird. Die Passphrase muss diesmal nicht sonderlich geheim sein, da sie ohnehin im Anschluss wieder entfernt wird. OpenSSL lässt allerdings keine leere Phrase zu.

root@linux# openssl genrsa -out serverkey.pem -aes256 2048 -days 3650

Jetzt ist es ganz praktisch die Passphrase wieder zu entfernen, da der Server auch ohne Zutun des Administrators in der Lage sein soll, den Schlüssel zu lesen. Sonst müsste bei jedem Booten der Machine ein Passwort eingegeben werden.

root@linux# openssl rsa -in serverkey.pem -out serverkey.pem

3. Certificate Signing Request erzeugen

Der nächste Schritt zum eigenen Zertifikat ist ein CSR. Dies muss dann nur noch von der CA signiert werden. Hier sind wieder Angaben analog zum Erstellen der CA nötig, was oft Verwirrung stiftet. Die allgemeinen Daten kann man gegebenfalls gleich wie oben eingeben.

root@linux#  openssl req -new -key serverkey.pem -out req.pem -nodes

ACHTUNG, jetzt kommt das Wichtige: Beim Serverzertifikat ist der Common Name von entscheidender Bedeutung. Hier muss der DNS-Name stehen, unter dem der Client den Server anspricht! Wird das Zertifikat für eine HTTPS-Verbindung zu www.domain.tld verwendet, so muss der Common Name eben genau www.domain.tld heißen. Andernfalls wird der Browser das Zertifikat nicht akzeptieren, da er davon ausgehen muss, auf dem falschen Server gelandet zu sein.

Common Name (eg, YOUR name) []: www.domain.tld
Email Address []: name@domain.tld

Weitere Optionen kann man einfach leer lassen.

A challenge password []:
An optional company name []:

4. OpenSSL-Konfiguration anpassen

Leider kann man bei OpenSSL nicht alle Daten als Kommandozeilenargumente übergeben. Einige Einstellungen müssen lästigerweise in der Datei /etc/ssl/openssl.cnf geändert werden, bevor man signieren kann. Dazu die Datei öffnen und folgende Zeilen in der Sektion [ CA_default ] anpassen.

dir             = .              # Where everything is kept
new_certs_dir   = $dir           # default place for new certs
private_key     = $dir/cakey.pem # The private key
RANDFILE        = $dir/.rand     # private random number file
default_days    = 3650           # how long to certify for

Das Feld default_days ist auf 365 Tage voreingestellt und gibt die Gültigkeit des Zertifikates an. Dieses setze ich wie im Beispiel auf 10 Jahre herauf.
Wenn bei dem Serverzertifikat kein Bundesstaat angegeben ist, wird folgende Änderung unter [ policy_match ] benötigt.

stateOrProvinceName     = optional

Nun muss man noch einige Dateien anlegen:

root@linux# echo 01 > serial
root@linux# touch index.txt

5. Serverzertifikat signieren

Als krönenden Abschluss signiert die eigene CA nun das Zertifikat

root@linux# openssl ca -in req.pem -notext -out servercert.pem

6. Zertifikate installieren

Wohin die erzeugten Zertifikate installiert werden sollen, hängt vom jeweiligen Serverdienst ab. Was ihnen aber allen gemeinsam ist, es werden nur die Dateien cacert.pem, servercert.pem und serverkey.pem benötigt. Die Datei cakey.pem wird nicht benötigt und sollte nicht auf dem Server liegen sondern am besten sicher auf einem anderen Rechner verwahrt werden.
Da es sich bei den Dateien im wesentlichen nur um Textdateien handelt, ist es prinzipiell egal wie sie heißen. Der Übersicht halber und zur besseren Ordnung kann man sie aber auch im Nachhinein in eine umgänglichere Form unbenennen.

cacert.pem -> ca.crt
servercert.pem -> server.crt
serverkey.pem -> server.key

Jetzt sind das aber alles keine neuen Erkenntnisse. Im letzen Jahr erst wurde mit Let’s Encrypt eine alternative Zertifizierungsstelle ins Leben gerufen, um für alle Server-Betreiber kostenlose Zertifikate anbieten und ausstellen zu können. Diese wird unter anderem von der Mozilla und der Electronic Frontier Foundation gesponsert. Man wird sehen wie sich das entwickeln wird.

Einen Telnet-Server unter Debian/Ubuntu-Linux installieren

Für eine bestimmte Anwendung brauche ich zur Zeit Telnet und da ja die SSH seit Ewigkeiten Telnet wegen des Sicherheitsaspektes abgelöst hat, muss man den Server manuell nach installieren.

sudo apt-get install telnetd

Da sowohl das aktuelle Debian- als auch Ubuntu-Linux auf systemd umgestiegen ist, so muss man mit

sudo /etc/init.d/openbsd-inetd  restart

diesen noch starten.

Auf die Diskussion, dass ja die SSH ja sicher ist, brauche ich mich hier jetzt nicht einlassen. Für die Anwendung wo Telnet eingesetzt wird, fallen keine Sicherheitsrelevanten Daten an. Im Gegenteil: Das Protokoll ist für die Client zu Server Kommunikation nach jetziger Implementierung eher besser geeignet. Für die eigentlichen Fernwartungsaufgaben steht ja nach wie vor die SSH auf dem Zielrechner zur Verfügung.

OS X von einem bootfähigen USB-Stick installieren

Erst vorgestern konnte ich einem gebeutelten Mac-Nutzer, welcher seine Systemplatte im Rechner zerschossen hatte, damit aushelfen, ihm einen bootfähigen USB-Stick so zu formatieren, dass er von diesem wieder ein frisches OS X Mavericks auf seinem Computer installieren kann. Im Internet gibt es inzwischen viele Seiten auf denen diese Vorgehensweise dazu bereits dokumentiert ist, aber der Vollständigkeit halber will ich mir das auch noch einmal notieren. Innerhalb von sechs Monaten ist das inzwischen aber auch schon das zweite Mal, wo ich diese Dienstleistung erfolgreich für andere erbringen konnte. – Ungeachtet um welches Release es sich dabei handelte.

Als erstes muss man sich mit seiner Apple-ID über den Mac App Store die gewünschte OS X Version herunterladen. Es gibt dabei die Empfehlung, dass man dieses Unternehmen eigentlich nicht für andere Nutzer machen sollte, da die eigene Apple-ID im Installer gespeichert wird. Dies war mir bisher allerdings nicht bewusst. Ich traue denen zu – und hoffe auch – dass wenn diejenigen, welchen ich damit ausgeholfen habe, meine ID ihnen über den Weg läuft, sie sie ignorieren und durch eine andere ersetzen.
Ist der Download fertig, bereitet man seinen USB-Stick, welcher über mindesten 8 GB Kapazität verfügen sollte, idealerweise mit dem grafischen Festplattendienstprogramm (Disk-Utility) vor. Im Karteireiter „Partition“ wählt man das Layout „1 Partition“, gibt dem Volume vielleicht noch einen passenderen Namen wie zum Beispiel „Stick“ und legt dieses mit dem Format „Mac OS Extended (Journaled)“ an. Man sollte dabei darauf achten, dass man vorher unter „Optionen“ die GUID-Partitionstabelle vorausgewählt hat. Mit „Anwenden“ wird der USB-Stick dann tatsächlich wie gewünscht formatiert.
Nun scheiden sich die Wege. Man kann den Installer auch mittels dem grafischen Disk-Utility auf den USB-Stick verfrachten. Dies birgt aber bei der späteren Mac OS X Installation auf den Computer einige Nachteile, welche wiederum auch nur erst wieder im Anschluss behoben werden können. So würde FileVault und die Funktion „Find my Mac“ erst einmal nicht verfügbar sein.
Eleganter ist es daher, den Kopierprozess mit einem einzigen Befehl im Terminal abzuarbeiten.:

sudo /Applications/Install\ OS\ X\ Yosemite.app/Contents/Resources/createinstallmedia --volume /Volumes/Stick/ --applicationpath /Applications/Install\ OS\ X\ Yosemite.app/ --nointeraction
  • Mit /Applications/Install\ OS\ X\ Yosemite.app/Contents/Resources/createinstallmedia wird im Installer-Paket das eigentliche Unix-Kommando ausgeführt.
  • Durch –volume /Volumes/Stick wird das Ziel-Volume übergeben. Also unser vorformatierter USB-Stick.
    Mit –applicationpath /Applications/Install\ OS\ X\ Yosemite.app teilt man mit, wo der Mavericks-Installer liegt. Dies Pfadangabe ist bereits bekannt.
  • Die Option –nointeraction sorgt schließlich dafür, dass der Befehl ohne weitere Rückfragen ausgeführt wird. Man muss sich also bewusst sein, dass hier mit Root-Rechten ein Volume ohne Sicherheitsabfragen gelöscht wird.

Jetzt ist der USB-Stick fertig. Bei eingesteckten Stick wird durch das Gedrückt Halten der „alt“-Taste während des Rechnerneustarts dieser als zu bootendes Volume dargestellt und man kann mit seinem Clean-Install beginnen.
Das Verfahren lässt sich natürlich auch auf die anderen Versionen von Mac OS X anwenden. Es ist dabei lediglich darauf zu achten, dass diese andere Namen im Installer tragen.

Alte Revisionen von WordPress-Einträgen löschen

Wenn man in WYSIWYG-Editor einen Beitrag bearbeitet, so erzeugt WordPress standardmäßig alle 60 Sekunden eine neue Revision. Auf Dauer kann dies zu überflüssigen Einträgen führen, welche die Datenbank sehr stark anwachsen lässt und in ihrer Performance beeinträchtigt. Im WordPress selber gibt es aber leider keine Möglichkeit, dies einzustellen und zu begrenzen. Durch folgende zusätzliche Einträge in die wp-config.php lässt sich das Verhalten dennoch steuern.

Mit

define('WP_POST_REVISIONS', 3);

wird definiert, wie viele Revisionen in der Datenbank maximal gespeichert werden sollen. Man kann aber anstatt der Zahl auch ein false als Variable einsetzen. Dann werden natürlich keine Einträge erzeugt.

Und mit

define('AUTOSAVE_INTERVAL', 300);

wird der Zeitintervall in Sekunden gesetzt, in der eine neue Revision gespeichert wird. In meinem Fall also immer nach 5 Minuten.

Sollten sich in der Datenbank bereits eine menge Einträge mit früheren Artikelrevisionen befinden, so kann man die auch manuell heraus löschen. Am besten aber vorher ein Backup der Datenbank erstellen, so kann man bei Problemen nach dem löschen diese wieder in ihrem Ursprungszustand wieder herstellen. Über PHPMyAdmin kann man auch mit folgendem Befehl die unnötigen Einträge löschen.:

DELETE * FROM wp_posts WHERE post_type="revision;"

Als Alternative dazu gibt es aber diverse PlugIn’s, welche für einem die sehr zuverlässig und sicher erledigen.

Autostart von irssi in einer screen-Session

Wenn man bestimmte Skripte oder andere Sachen automatisiert mit dem Systemstart zum rollen bringen will, so lassen sich diese in die Datei /etc/rc.local einbinden.

sudo -u $username screen -d -m -U -S irssi irssi

Egal ob Änderungen in der Datei vorgenommen werden oder auch nicht, am Ende muss in der letzten Zeile immer „exit 0“ stehen!

Da ich diese Konfiguration das erste Mal auf einem Raspbian zum starten bringen wollte, musste ich zu meinem Entsetzen feststellen, dass auf diesem standardmäßig erst einmal kein sudo installiert ist. Ist zwar kein Problem, weil lässt sich ja nach installieren, aber ich war schon erstaunt.

Automatische iCloud-Speicherung von Dokumenten verhindern

Wie sich heraus gestellt hat, speichern Programme mit iCloud-Anbindung auf dem Macintosh jedes noch ungesicherte Dokument ungefragt in diese hoch. Dies möchte man verhindern – gerade wenn man Dokumente soweit vertraulich behandeln möchte, dass sie selbst auf verschlüsselten Diensten von Dritten nichts zu suchen haben. Da es keine Möglichkeit in der GUI vom Mac OS X gibt dies zu verhindern, muss man folgenden Befehl auf der Kommandozeile absetzten.

defaults write NSGlobalDomain NSDocumentSaveNewDocumentsToCloud -bool false

Nach dem Beenden und erneutem Öffnen, speichern Programme mit iCloud-Unterstützung die neu angelegte Dokumente dann wieder lokal im Verzeichnis des jeweiligen Nutzers unter folgender Ordner-Struktur:

/Users/<Benutzername>/Library/Containers/<Ordnername_Applikation>/Data/Library/Autosave Information/

Möchte man hingegen das vorherige Verhalten mit der iCloud-Anbindung wieder zurück haben, reicht es den selben Befehl nur mit einem true am Ende aus zu führen.

Alternativ kann man sein Nutzungsverhalten in Bezug von Dokumentenverwaltung aber auch so einstellen, dass man auf die iCloud völlig verzichtet, oder nur einen selber gehosteten Dienst nutzt auf dem auch selbst administrativen Zugang hat.

Quelle des Tip bei Mac OS X Hints

Saubere MacPorts

Nach Jahren der Updaterei und neues Mac OS X Betriebssystem hinüber bügeln, tut es einfach mal gut, alle Programme via MacPorts mal zu deinstallieren und wieder neu zu installieren. Dabei werden automatisch alle Versions-Leichen, welche nicht mehr benötigt werden und Bibliotheken die einst mal mit installiert wurden weil ich Programm XY mal kurz ausprobiert habe, mit gelöscht.
Anbei eine Liste von Programme, die ich standartmässig auf einem Mac installiere:

sudo port -v -fp uninstall installed && sudo port -v install erlang gnupg2 irssi mc minicom mtr py27-ipython py-pip py-serial py-py2app nmap rtmpdump simh tcpdump tcpflow tmux w3m watch wget

Danach klappt’s auch wieder mit den Verlinkungen sauber.

Update:

Anmerkung vom Clemens:

In diesem Kontext auch hilfreich: wiederholt sudo port uninstall leaves ausführen. Das gleiche mit ein bisschen mehr Toolchain drumrum: sudo port install port_cutleaves; port_cutleaves.

Die Wolke in der eigenen Hand

Seit der iTunes-Version 11.2 und iOS 7.0.3 hat nun Apple das vollzogen, wovon ich nie gedacht hätte, dass es passieren würde. Man kann die Kalender- und Kontaktdaten nun nicht mehr lokal über WiFi oder USB zwischen Computer und iPhone/iPad synchronisieren. Stattdessen braucht man dazu seine Apple-ID um das über die iCloud abzugleichen. Aber die iCloud kommt für mich nicht in Frage, da die Daten nichts auf fremden Servern zu suchen haben, die zu allen Überfluss auch noch im Ausland stehen. Ich weis schliesslich nicht, ob sie dort auch verschlüsselt abgelegt werden und muss eventuell davon ausgehen, dass irgendwelche staatlichen Behörden auf diese Server zugriff haben. Deswegen habe ich nun beschlossen, einen meiner Raspberry Pi’s dazu zu nutzen und auf ihn ownClod installieren, der sicher in meiner eigenen Wohnung steht. Mit ihm werde ich meine Kalender- und Kontaktdaten über mein lokales Netz austauschen, währenddessen die Bilder-, Audio- und Applikationen sowieso ich über USB synchronisiere.

Raspberry Pi für ownCloud

Raspberry Pi für ownCloud

Anbei ein kleiner Workaround zur Installation von ownCloud.

Ich entscheide mich hierbei für den Webserver nginx, der wohl etwas Ressourcen schonender als der Apache-Webserver ist und flüssiger läuft.

Auf dem Server werden also folgende Komponenten zur ownCloud mit installiert:

  • nginx Webserver
  • PHP5
  • SQLite (Datenbank auf Dateibasis)
  • sowie diverse Pakete zum Performancegewinn

Nachdem man sich via http://www.raspbian.org/RaspbianInstaller mit den Raspbian-Installer ein Debian Weezy Grundsystem installiert hat, installiert man sich mit raspi-config ein sehr praktisches Konfigurationswerkzeug, um auf dem System ein paar grundlegende Einstellungen für das Gerät vorzunehmen.

sudo apt-get install raspi-config
sudo raspi-config
  1. change_locale zu „en_US.UTF-8“ für das komplette System (Ansonsten meckert ownCloud, dass es zu Fehlern bei Dateinamen mit Sonderzeichen kommen kann)
  2. memory_split auf „16“ MB einstellen. Dies ist die kleinst mögliche Einstellung. Die GPU bekommt somit 16MB.
  3. overclock auf „Medium“ 4. „Finish“ und danach die Frage nach dem Reboot mit „Yes“ beantworten.

Paketlisten aktualisieren

sudo apt-get update
sudo apt-get upgrade

Benutzer erstellen

sudo groupadd www-data
sudo usermod -a -G www-data www-data

Installation der Pakete

 sudo apt-get install nginx openssl ssl-cert php5-cli php5-sqlite php5-gd php5-curl php5-common php5-cgi sqlite php-pear php-apc curl libapr1 libtool curl libcurl4-openssl-dev php-xml-parser php5 php5-dev php5-gd php5-fpm memcached php5-memcache varnish

SSL Zertifikat erstellen (gültig für 1 Jahr)

sudo openssl req $@ -new -x509 -days 365 -nodes -out /etc/nginx/cert.pem -keyout /etc/nginx/cert.key
sudo chmod 600 /etc/nginx/cert.pem
sudo chmod 600 /etc/nginx/cert.key

nginx Webserver konfigurieren

sudo nano /etc/nginx/sites-available/default

Hier löscht man den kompletten Inhalt und fügt stattdessen den unten stehenden ein.
Darauf achten, dass man die IP-Adresse „192.168.XXX.XXX“ mit der des Raspberry Pi ersetzt.

server {
listen 80;
  server_name 192.168.XXX.XXX;
  rewrite ^ https://$server_name$request_uri? permanent;  # enforce https
}

server {
listen 443 ssl;
server_name 192.168.XXX.XXX;
ssl_certificate /etc/nginx/cert.pem;
ssl_certificate_key /etc/nginx/cert.key;
root /var/www;
index index.php;
client_max_body_size 1000M; # set maximum upload size
fastcgi_buffers 64 4K;


location ~ ^/owncloud/(data|config|\.ht|db_structure\.xml|README) {
  deny all;
}


location / {
  try_files $uri $uri/ index.php;
}

location @webdav {
  fastcgi_split_path_info ^(.+\.php)(/.*)$;
  fastcgi_pass 127.0.0.1:9000;
  fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
  fastcgi_param HTTPS on;
  include fastcgi_params;
}

location ~ ^(?.+?\.php)(?/.*)?$ {
  try_files $script_name = 404;
  include fastcgi_params;
  fastcgi_param PATH_INFO $path_info;
  fastcgi_param HTTPS on;
  fastcgi_pass 127.0.0.1:9000;
}
}

Danach in folgender Datei die Werte „upload_max_filesize“ sowie „post_max_size“ auf 1000M setzen.

sudo nano /etc/php5/fpm/php.ini
upload_max_filesize = 1000M
post_max_size = 1000M

Am Ende der Datei noch folgendes einfügen:

upload_tmp_dir = /srv/http/owncloud/data

Als nächstes muss folgender Ordner mit den dazugehörigen Rechten erstellt werden

sudo mkdir -p /srv/http/owncloud/data
sudo chown www-data:www-data /srv/http/owncloud/data

PHP konfigurieren

sudo nano /etc/php5/fpm/pool.d/www.conf

Hier ändert man folgende Zeile von:

listen = /var/run/php5-fpm.sock

zu

listen = 127.0.0.1:9000

Webserver und PHP neustarten

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

ownCloud installieren
Als letztes wird ownCloud installiert. Folgende Befehle müssen abgearbeitet werden.

wget http://download.opensuse.org/repositories/isv:ownCloud:community/Debian_7.0/Release.key
apt-key add - < Release.key echo 'deb http://download.opensuse.org/repositories/isv:ownCloud:community/Debian_7.0/ /' >> /etc/apt/sources.list.d/owncloud.list
apt-get update
apt-get install owncloud

Nun lässt sich der Server im lokalen Netz aufrufen. In meinem Fall ist das https://192.168.1.104/owncloud. Als letztes muss nur noch ein Administratorkennwort und ein Benutzername festgelegt werden. Somit ist die Installation vollends abgeschlossen.

Der schnellste Weg, Adressbücher und Kalender in die eigene Wolke zu laden, führt über die Webanwendung von Owncloud, die Dateien im VCF- und ICS-Format importieren kann.

Bei Adressbüchern (.vcf) klappte der Import im Versuch allerdings nicht immer reibungslos. Bei einem Adressbuch, in dessen Feldern Doppelpunkte vorkamen, brach der Import leider ab. Im Zweifel muss man vor dem Import noch an den Daten feilen. Auch Gruppen ließen sich nicht importieren, da ownCloud sie als regulären Adressbuch-Eintrag interpretierte. Ein Fehler, der hoffentlich bald behoben wird.

Weiterführende Links:
Artikel bei iRights.info
Das Howto im RaspberryPi-Forum