SSH-Audit

Jemand hat sich mal hingesetzt und eine Sammlung an Python-Skripten geschrieben, mit dem sich ein SSH-Server auf die verwendete Version, den Algorithmen und Sicherheitsinformationen abklopfen lässt, sowie die dazu passenden Empfehlungen ausgibt. Das Programm ist auf GitHub verfügbar und mit Python 2.6, Python 3.x und PyPy kompatibel.

ssh-audit

Link: https://github.com/arthepsy/ssh-audit

Speichermedien grundieren mit f3write / f3read

Das Thema ist zwar schon älter, aber es kommt wohl immer noch vor, dass USB-Sticks oder SD-Karten mit gefälschten Kapazitätsangaben in Umlauf gebracht werden. Auch wenn diese aus seriösen Quellen stammen, sollte man sie auf die korrekte Kapazität und Funktionsfähigkeit prüfen, bevor man darauf unwiederherstellbare Daten aufzeichnet. So schreibt beispielsweise eine Kamera fröhlich 32 GB auf eine Karte, die tatsächlich nur 8 GB fasst. Die Daten sind dann hinüber. Außerdem kann die Karte auch einfach nur defekt sein, oder die versprochene Schreibgeschwindigkeit nicht halten.

Für die gängigen Unixoiden Betriebssysteme kann man f3write / f3read benutzen. Dabei wird der Datenträger mit einem verifizierbaren Muster beschrieben und dieses wird im Anschluss wieder gelesen.

Vorher muss der Source-Code aber an einem Ort der Wahl innerhalb des Dateisystems entpackt und mit ‚make‚ kompiliert werden.

sommteck:f3-6.0 franky$ ./f3write /Volumes/USB-Stick/
Free space: 3.78 GB
Creating file 1.h2w ... OK!
Creating file 2.h2w ... OK! 
Creating file 3.h2w ... OK!
Creating file 4.h2w ... OK!
Free space: 0.00 Byte
Average writing speed: 4.40 MB/s
sommteck:f3-6.0 franky$ ./f3read /Volumes/USB-Stick/
                  SECTORS      ok/corrupted/changed/overwritten
Validating file 1.h2w ... 2097152/        0/      0/      0
Validating file 2.h2w ... 2097152/        0/      0/      0
Validating file 3.h2w ... 2097152/        0/      0/      0
Validating file 4.h2w ... 1631936/        0/      0/      0
 
  Data OK: 3.78 GB (7923392 sectors)
Data LOST: 0.00 Byte (0 sectors)
	       Corrupted: 0.00 Byte (0 sectors)
	Slightly changed: 0.00 Byte (0 sectors)
	     Overwritten: 0.00 Byte (0 sectors)
Average reading speed: 20.70 MB/s

Idealerweise kann man vielleicht noch Aliases in der .profile erstellen, um die Tipperei auf der Konsole zu reduzieren.

Außerdem gibt es das Programm als native Cocoa-GUI-Variante. Aber diese gefällt mir persönlich nicht so gut, weil sie keine so detaillierten Statusinformationen liefert.

Update

Inzwischen kann man f3write/f3read auch mittels MacPorts und HomeBrew automatisiert installieren. Zudem ist der Quellcode auf GitHub verfügbar.

Link: https://github.com/AltraMayor/f3

Apache Logfiles anonymisieren oder abschalten

Soweit ich das richtig verstanden habe, dürfen nach dem deutschen Recht Webserver keine IP-Adressen abspeichern, solange sie aus technischen oder geschäftlichen Gründen nicht zwingend erforderlich sind. (siehe TMG §15)

Das gilt sowohl für den Webserver als auch für Kommentare in den Content-Managemand-Systemen. Ein Apache ist in der Standardeinstellung aber nicht nach der deutschen Rechtslage voreingestellt. Mit ein paar Zeilen in der Konfiguration lassen sich die Logfiles eines Webservers anonymisieren oder ganz abschalten.

Logfiles anonymisieren

Eine Möglichkeit ist das anonymisieren von Logfiles. Die Einträge werden dabei weiterhin in die Dateien geschrieben – doch mit entfernter IP-Adresse. Unter Ubuntu 14.04 wechselt man in das Konfiguraionsverzeichnis /etc/apache2/conf-available/ und öffnet die Datei other-vhosts-access-log.conf, um die Logeinstellungen für vHosts zu ändern. Eine neue Zeile wird hinzugefügt:

LogFormat "[IP] %l %u %t \"%r\" %>s %b" vhost_combined

Danach muss der Webserver neu gestartet werden:

service apache2 reload

Statt der echten IP eines Clients erscheint nun „[IP]“ in den Logfiles.

Auf ähnliche Weise wird die Einstellung für die Errorlogs geändert. Die Datei /etc/apache/apache2.conf öffnen und folgende Zeile hinzu fügen:

ErrorLogFormat "[%t] [%l] [pid %P] %F: %E: [client [IP]] %M"

Logfiles abschalten

Wer ganz auf den Accesslog verzichten kann, kann diesen auch ganz abschalten und so Ressourcen sparen. Dazu wird in /etc/apache2/conf-available/other-vhosts-access-log.conf einfach die Zeile „CustomLog …“ mit einem vorangestellten „#“-Zeichen auskommentiert. Dasselbe gilt für den Errorlog: Hier muss in /etc/apache/apache2.conf die Einstellung „ErrorLog“ auskommentiert werden.

Nach jeder Konfigurationsänderung ist ein Neuladen der Konfiguartionsdateien nötig, damit die Einstellung aktiv werden.

service apache2 reload

wego-Wetterclient für das Terminal

wego ist ein ASCII-Wetterclient für das Terminal, welcher eine go-Bibliothek um einen python-Wrapper schnürt, um via curl Wetterinformationen auf das Unix-Terminal zu holen. Eine schöne nerdige Art, wie man die aktuelle Wettervorhersage auch ohne HTTP-Overhead und Webbrowser hübsch auf den Computer dargestellt bekommt. Ich habe mir diesen mal auf meinem Mac installiert.

Features:

wego-forecast

  • zeigt forecast-Wetterdaten für den Zeitraum von 1 bis 7 Tagen
  • hübsche ASCII-Art Icons
  • angezeigte Informationen (Metrische, imperiale und SI-Einheiten)
    • Temperatur
    • Windrichtung und Geschwindigkeit
    • Vorhersage
    • Niederschlagsmenge und Wahrscheinlichkeit
  • SSL
  • Unterstützung mehrerer Sprachen
  • automatisches Konfigurationsmanagement mit ingo

Abhängigkeiten:

  • eine laufende Go-Umgebung ab Version 1.5
  • UTF-8 Terminal mit 256 Farben
  • eine vernünftige proportionale Schrift
  • einen API-Key für das BackEnd

Installation

Mit MacPorts oder jedem anderen beliebigen Paket-Manager Go installieren:

sudo port install go

Einen separaten Ordner für die Source-Files und Binaries von Go im Heimatverzeichnis anlegen:

mkdir Applications/Go

Umgebungsvariable setzen:

export GOPATH=/Users/franky/Applications/Go

Zum Installieren oder Updaten des wego-Binaries in der gesetzten $GOPATH-Variable ausführen:

go get -u github.com/schachmat/wego

Setup

  1. Einmal wego ausführen. Dies führt zu einem Programmabbruch und einer Fehlermeldung. So wird aber im Heimatverzeichnis die Datei .wegorc erzeugt.
  2. Mit forecast.io einen Account erzeugen
    1. Unter https://developer.forecast.io/register einen Account erzeugen
    2. Folgende Konfigurationsvariablen in der Datei .wegorc anpassen:
      backend=forecast.io
      location=40.748,-73.985
      forecast_api_key=YOUR_FORECAST.IO_API_KEY_HERE
  3. Danach weitere persönliche Einstellungen, wie Verwendete Einheit, Sprache usw. anpassen.
  4. wego erneut ausführen. Und schon wird das Wetter von forecast für die nächsten Tage vorhergesagt.

Mit dem Befehl Applications/Go/bin/wego wird dann die Wetterabfrage gestartet. Alternativ kann man sich aber noch einen passenden Alias in der .profile im Heimverzeichnis anlegen.

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.

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.

WLAN am Raspberry PI einrichten

Der Net-Installer des Debian-Port Raspbian für den Raspberry Pi ist recht übersichtlich und auf der Projektseite hier dokumentiert. Da ich in dem Fall zu Anfangs lediglich immer nur ein Grundsystem mit einem SSH-Server auf eine SD-Karte werfe, gibt es keine Möglichkeit, dass man sich mit dem Pi out of the Box via WiFi ins Netz verbinden kann. Leider fehlt bei einer Standart-Debian-Installation auch das Toolkit um WLAN-Adapter zu konfigurieren. Also muss dieses als erstes nach installiert werden:

apt-get install wireless-tools wpasupplicant

Da ich mich auch für den allgemein bei den Pi’s sehr beliebten Edimax EW7811Un USB-Adapter entschieden habe, hilft es auf folgende Weise zu verifizieren ob dieser vom System im eingesteckten Zustand ordentlich erkannt wurde.
Durch Eingabe von lsusb sollte das WLAN-Gerät über den USB-Host-Adapter mit seinen vollen Namen aufgelistet werden.
Mit lsmod kann man prüfen, ob das entsprechende Kernelmodul zu den Realtek-Chip mit geladen wurde. In diesem Fall heisst dies 8192cu.
Als finale Möglichkeit zu Überprüfen ob der Edimax einsatzbereit ist, kann man sich mit iwconfig mal die „aktuelle“ Konfiguration des WLAN-Interface anzeigen lassen. Entscheidend dabei ist, das es einen Eintrag mit wlan0 gibt.

Wenn das alles gegeben ist, kann man mit restlichen Konfiguration weiter machen.

Als erstes muss das WLAN-Gerät in die Datei /etc/network/interfaces hinzugefügt und die Konfigurationsparameter mitgegeben werden. In diesem Fall soll die IP-Adresse via DHCP bezogen werden und es wird in der letzten Zeile ein Verweis auf die Konfigurationsdatei wpa_supplicant.conf gesetzt.

/etc/network/interfaces:

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary LAN-network interface
allow-hotplug eth0
iface eth0 inet dhcp

# The Edimax USB-WiFi interface
auto wlan0
allow-hotplug wlan0
iface wlan0 inet dhcp
        wpa-driver wext
        wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

Die eigentliche WLAN-Konfiguration mit den Parametern zum Aufbau der (verschlüsselten) Verbindung wird unter /etc/wpa_supplicant/wpa_supplicant.conf definiert. In dem Fall WPA/WPA2 verschlüsselt. Sollte die Datei noch nicht existieren, dann erstellt man sie einfach.

/etc/wpa_supplicant/wpa_supplicant.conf:

network={
        ssid="_Name_des_Netwerk_"
        scan_ssid=1
        proto=RSN
        key_mgmt=WPA-PSK
        pairwise=CCMP TKIP
        group=CCMP TKIP
        psk="_Absolut_sicheres_Passwort_"
}

Mit dem Befehl ifup wlan0 wird dann das Interface neu gestartet und soll eine IP-Adresse beziehen mit der es sich dann versucht ein zu wählen. Ein Neustart des gesamten Raspbian tut aber auch nicht weh. Wenn ein ifconfig wlan0 als Ausgabe plausible Adress- und Netzmaskenwerte gibt, dann wurde alles richtig gemacht.

Im Wiki des Ubuntu-Forum gibt es auch sehr hilfreiche Howtos und Erklärungen zu Thema, die einem weiter bringen.
http://wiki.ubuntuusers.de/WLAN/Installation
http://wiki.ubuntuusers.de/WLAN/wpa_supplicant

Floppy’s an einem Android

Neulich kam der Joshi mit der Idee es zu versuchen, ob es möglich ist, ein Android-Tablett-Computer mit einem externen Diskettenlaufwerk zu verbinden, um auf die Daten einer 3,5″-Diskette zu zugreifen. Schliesslich besitzen die meisten Android-Geräte einen Mini- oder Micro-USB-Anschluss.
Also habe ich mal mein externes Diskettenlaufwerk mitgebracht. Joshi hat auch noch ein USB-OnTheGo-Kabel mitgebracht, welches nötig ist, damit die mobilen Touch-Geräte als Host-Controller die Peripherie-Geräte anbinden können. Dieses OnTheGo-Kabel dient damit praktisch als Adapter von Mini-USB auf eine normale USB-Buchse Typ A. Das Tablet war ein Nexus-Gerät mit dem CyanogenMod als Betriebssystem.
Nach dem erstmaligen Zusammenschluss der Hardware und einlegen einer Diskette in das Laufwerk, hat das Nexus das Laufwerk direkt als USB-Massenspeicher erkannt. Solch ein Diskettenlaufwerk mit einem Medium, welches maximal eine Speicherkapazität von 1,44 Megabyte besitzt, als Massenspeicher zu bezeichnen, muss mal hier aber wohl als Euphemismus bezeichnen. Die kleinsten USB-Sticks, die man derzeit für Geld im Laden kaufen kann, sind welche mit 2 Gigabyte.

Unbenannt

Wie sich später aber heraus stellte, war die eine Diskette des ersten Versuch bereits defekt, denn das Android versuchte allzeit den Datenträger mit einem FAT32-Dateisystem neu zu formatieren.
Mit einer anderen Diskette hatte es dann schliesslich geklappt. Das Betriebssystem erkannte das Medium und über den eigenen Dateimanager konnte man auf die Dateien zugreifen. Beweis dafür, dass Android sogar noch das alte FAT12-Dateisystem beherrscht. Anders als vermutet muss ausserdem im Kernel des Android wahrscheinlich kein Treibermodul für Floppy enthalten sein, da das Gerät logischerweise ja über USB-Massenspeicher angesprochen wird. Allerdings konnte man noch nicht auf eine Diskette schreiben, da offensichtlich für die Möglichkeit allgemein auf USB-Massenspeicher ausserhalb eines Android-Gerät die Schreibzugriffe fehlen. Hier muss wahrscheinlich das Gerät gerootet werden.
Es ergab sich aber noch ein anderer Nebeneffekt. Da auf einer weiteren Diskette, welche tatsächlich noch funktionierte, MIDI-Dateien gespeichert waren, stand natürlich der Versuch im Raum, diese zu öffnen. Auch dies klappte. Erkenntnis: Der Standartmedienplayer Apollo des CyanogenMod kann auch noch MIDI-Dateien abspielen.

Unbenannt

Die Essenz aus diesem kleinen Versuch ist, dass man auf die alten Daten von den kleinen 3,5″-Floppy’s auch mit den modernen smarten Geräten zugreifen kann.

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