Die Voraussetzungen zur Installation bei meinen Eltern könnten nicht stärker vom eigenen Haushalt abweichen: Es war nicht nur ist eine fast 30-fach größere Fläche abzudecken, sondern die Installation muss sich unauffällig, autonom und wartungsfrei verhalten. Die Abhängigkeit von Apps war (mangels geeigneter Telefone) ebenso zu vermeiden, wie proprieätere Cloud-Lösungen.

Aufgrund der deutlich größeren, abzudeckenden Fläche und den eher mässigen Erfahrungen mit Homematic-Hardware im eigenen Haus, wurde mit Zigbee diesmal auf ein „Mesh“-Netzwerk gesetzt. Dabei sind die Geräte auch untereinander und nicht nur mit einer zentralen Stelle (sternförmig) vernetzt. Theoretisch und praktisch sind damit auch größere Entfernungen zwischen dem adressierten Endgerät und der steuernden Einheit (Router) möglich.

Primäres Ziel der Installation war eine „smarte“ Außenbeleuchtung von Mühle und Garten, welche bis dato noch über Wandschalter bzw. mechanische Uhrwerke in Schaltkästen geregelt ist. Weitere Anwendungsfälle (z.B. Steuerung der Teichfilter) werden folgen.

Hardware

Probleme mit USB 3.0

Eine Warnung vorweg, damit ich als einziger mir die Nächte um die Ohren geschlagen habe: Die Verwendung eines USB 3.0 Gerätes, z.B. eines USB-Sticks in unmittelbarer Nähe des Raspbee II führt zu vielfältigen Problemen. Die Ursache ist bekannt, scheint grundsätzlich zu sein und lässt sich mit einer USB-Verlängerung, Alu-Folie oder der Verwendung einer SD-Karte lösen.

Die notwendige Hardware habe ich rechtzeitig vor Weihnachten im Versandhandel organisiert. Dass Einzelhändler vor Ort entsprechende Gerätschaften im Regal haben ist eh schon un­wahr­scheinlich, spätestens mit dem 2. Lockdown war dann auch der Weg dorthin obsolet.

Zigbee Koordinatoren (auch als „Hub“ oder „Bridge“ vermarktet) gibt es zu Hauf. Die bekannteste Variante ist sicherlich die Philips Hue Bridge. Üblicherweise sind diese „Appliances“ auf Apps und Cloud-Services des Herstellers ausgerichtet. Im Bereich Heim-Automatisierung ist Zigbee aber nur eine Komponente von vielen und darum kam auch in diesem Projekt ein alter Bekannter zum Einsatz.

Raspberry Pi 4B 4GB

Es hat sich bei meinen eigenen Installation gezeigt, das die CPU eines Raspberry Pi 3 ausreichend potent ist, aber der Speicher gerade beim Einsatz mit Home Assistant schnell an seine Grenzen gerät. Darum habe ich zum Raspberry Pi 4B mit 4GB gegriffen, welcher für ca. 60 EUR erhältlich ist.

Erstmalig kamen dabei auch das Orignal Raspberry Pi USB-C Netzteil, sowie das passende Gehäuse zum Einsatz.

Der Setup erfolgte natürlich wieder „headless“ (via LAN), auf ein Micro-HDMI-Kabel konnte also verzichtet werden.

Raspbee II

Beim Raspbee II handelt es sich um die on-board-Variante eines Zigbee Coordinator Moduls von dresden-elektronik, welches unter der Marke Phoscon vertrieben wird. Es wird auf die General Purpose IO (GPIO)-Leiste eines Raspberry Pi gesteckt und als serielles Gerät angesprochen.

Mit an Bord ist außerdem eine batteriegestützte Real Time Clock, also eine Echtzeituhr. Die Einrichtung und Nutzung ist aus der Produktseite des Raspbee II beschrieben und sei hier nur am Rande erwähnt.

Die Installation auf dem Raspberry Pi ist denkbar einfach: Das Raspbee II-Modul wird auf das äußerste Ende der GPIO-Leiste gesteckt, so dass die eigentliche Platine über den Raspberry kommt und in Richtung USB-C-Port zeigt.

Das Modul baut sehr flach, so dass sowohl der Einsatz eines moderaten CPU-Kühlkörpers, als auch eines flachen Gehäuses möglich ist. Das Gehäuse sollte aber aus Kunststoff sein, um die Reichweite der Funksignale nicht unnötig zu reduzieren. Ich habe – wie gesagt – auf das Original gesetzt.

Wer lieber auf eine externe Lösung setzt, der kann statt des Raspbee II auch die USB-Variante namens Conbee II verwenden. Dann kommen allerdings andere Einstellungen zum Einsatz, die ich hier nicht beschreibe.

OSRAM Smart+ Classic E27 / Plug 01

Die beiden „Smart+ Bulbs“ von OSRAM wurden als Proof-of-Concept beschafft. Es handelt sich um „retrofit“ Leuchtmittel für die E27 Fassung mit steuerbarer Helligkeit. Mit einem Preis von rund 10 EUR pro Stück sind sie erschwinglich, aber auch ohne Schnick-Schnack. Im Betrieb sind sie aktuell unauffällig.

Auch andere zertifizierte Zigbee-Leuchtmittel sollten funktionieren. Bei OSRAM gilt es aufzupassen, denn unter dem Schlagwort „Smart+“ werden auch andere Technologien wie WLAN oder Bluetooth vermarktet.

Ebenfalls gekauft wurde ein OSRAM Smart+ Outdoor Plug, also eine Steckdose für den Außenbereich. Ein Riesen-Trümmer (siehe Aufmacher-Bild), obwohl mit Schutzart IP44 nur grundsätzlich gegen Wettereinfluß geschützt. In Zukunft kommen sicherliche schmalere Lösungen zum Einsatz, aber für den Moment war diese intern „Plug01“ genante Steckdose verfügbar und preislich attraktiv – gekauft.

In Summe haben die oben genannten Hardware und weitere Teile wie Gehäuse, Netzteil, SD-Karte ca. 130 EUR gekostet. Deutlich mehr als ein Philips Hue Starter Kit, aber auch deutlich flexibler, leistungsfähiger und ohne App- oder Cloud-Zwang.

Software

Ursprünglich hatte ich vor, erstmalig Home Assistant OS (vormals HASS.IO) zu verwenden, eine Distribution welche auf den Betrieb von Home Assistant ausgerichtet ist und auf Docker und einen „Supervisor“ setzt.

Leider ist es mir innerhalb der persönlichen Toleranzzeit (ca. 30min) nicht gelungen, eine nutzbare Installation zu erstellen. Durch das Supervisor-Konzept sind notwendige Eingriffe in das Betriebssystem bzw. die Kernel-Konfiguration nur aufwändig zu realisieren.

Raspbian Linux

Also kam wieder Raspbian Linux zum Einsatz, welches auch als „Raspbian Pi OS“ vermarktet wird. Die eigentliche Installation beschreibe ich an dieser Stelle nicht mehr, es finden sich bereits entsprechende Artikel in diesem Blog. Die 32-Bit „lite“-Variante ohne Desktop ist ausreichend.

Bevor das fertige Installationsmedium (SD-Karte) in den Raspberry gesteckt und dieser gestartet wird, sollten noch folgende Änderungen am Inhalt der ersten Partition vorgenommen werden. Dabei ist ein Editor zu verwenden, welcher Zeichenkodierung und Zeilen-Enden beibehält. Unter Windows können das z.B. Wordpad oder Visual Studio Code sein:

1. aus der Datei cmdline.txt wird folgender Eintrag entfernt:
   console=serial0,115200
2. die Datei config.txt wird um folgende Zeilen ergänzt (die Leerzeile am Dateiende muss erhalten bleiben):
   enable_uart=1
core_freq=250
dtoverlay=miniuart-bt

Optional kann noch eine (leere) Datei namens „ssh“ angelegt werden, damit ein Login via Secure Shell möglich ist. Danach kann die SD-Karte in den Raspberry Pi und dieser mit Strom versorgt werden. Nach einigen Sekunden bis Minuten sollte ein neuer Host „raspberrypi“ im heimischen Netz auftauchen.

Docker

Docker ist eine Plattform zur Prozess-Virtualisierung mithilfe von Containern. Sie erleichtert den Betrieb von Home Assistant erheblich, weil hier Abhängigkeiten auf Bibliotheken und Versionen des Betriebssystems vermieden werden.

Die Installation von Docker habe ich bereits in einem eigenen Artikel beschrieben: Docker und Raspbian auf einem Raspberry Pi.

Home Assistant

Home Assistant ist meine bevorzugte Plattform zur Heim-Automatisierung, da sie einfach zu installieren ist (insbesondere unter Verwendung von Docker). Kein Grund also nach einer Alternative für das neue Projekt zu suchen.

Wurden das Raspberry Pi OS (AKA Raspbian) und die Docker-Umgebung korrekt aufgesetzt (inkl. Neustart), so ist die Ausführung von Home-Assistant ein Klacks.

Im Wesentlichen gibt es zu meinem Artikel „Home Assistant mit Docker auf Raspberry Pi betreiben“ nur eine relevante Änderung: Der Zugriff auf das Raspbee II Modul muss durch das „mappen“ des entsprechenden seriellen Devices in den Container ermöglicht werden. Der vollständige Aufruf lautet also:

docker run -d \
  --name=home-assistant \
  --restart=always \
  --publish 8123:8123 \
  -v $PWD/home-assistant:/config \
  -v /etc/localtime:/etc/localtime:ro \
  --device=/dev/ttyAMA0 \
  homeassistant/home-assistant:stable

Hinweis: Alternativ zu „–publish 8123:8123“ kann „–net=host“ verwendet werden. Dies bindet den den Home Assistant Container an das Netzwerk des Hosts und es werden beim Start Integrationen zu allen im Netzwerk gefundenen Geräten angeboten.

ZHA Integration

Finaler Schritt der Einrichtung ist die Installation und Konfiguration des Zigbee Coordinators in Home Assistant. Dazu gibt es für das Raspee II Modul zwei Möglichkeiten:

1. direkte Kommunikation mit dem Modul über die „Zigbee Home Automation“-Integration
2. indirekte Kommunikation über einen zwischengeschalteten deCONZ-Service und die entsprechende „deCONZ“ Integration.

Ich habe mich für Variante 1 entschieden, weil sie keine weitere Abhängig­keit erzeugt und für meine Zwecke ausreichend ist. Sie kann auch die Firmware für OSRAM/Ledvance und IKEA-Leuchten „over the air“ aktualisieren.

Sobald Home Assistant läuft, auf Port 8123 erreichbar ist und man die Basis-Einrichtung vorgenommen hat (Benutzer, Standort, Zeitzone, etc.), geht es über den Pfad „Einstellungen -> Integrationen“ zur Schaltfläche „+ Integration Hinzufügen“

Im resultierenden Dialog sucht man nach „zig“ (oder „zigbee“) und wählt das Ergebnis „Zigbee Home Automation“ aus.

Im folgenden Dialog ist das serielle Gerät für das Raspbee II Modul zu wählen. Der einzig angebotene Wert an dieser Stelle sollte /dev/ttyAMA0 sein.

Nach der Auswahl wird das serielle Gerät analysiert und es wird automatisch das deCONZ-Protokoll für die Kommunikation zwischen Raspberry Pi und dem Modul gewählt (auch ohne dedizierte deCONZ Installation nach Variante 2).

Mit der (optionalen) Auswahl eines Bereichs (also der Position des Raspberry Pi im Haus) ist die Installation abgeschlossen. Home Assistant ist nun bereit Zigbee-Geräte abzufragen und zu steuern.

Natürlich müssen die Geräte noch am Coordinator angelernt werden, dies ist aber in der Dokumentation der Integration beschrieben. Der schnellste Weg ist über Einstellungen -> Geräte und der Auswahl des Zigbee Coordinator. Alternativ kann auch Einstellungen -> Integrationen und die Auswahl der ZHA Integration verwendet werden.

Fazit

Die Installation von Hard- und Software war – wenn man von der USB-Problematik absieht – überraschend einfach, was natürlich meinem technischen Hintergrund und den Erfahrung im eigenen Haus geschuldet ist.

Das Raspbee II-Modul ist in der Installation idiotensicher und im Betrieb stabil. Seine Bauform erlaubt den Aufbau eines kompakten Zigbee Hubs mit deutlichem Mehrwert gegenüber einer fertigen „Appliance“, wie der Hue-Brige.

Die Zigbee-Geräte verhalten sich bis dato unauffällig und funktionieren einfach. Das Anlernen und die Visualiserung des Netzes in Home Assistent sind ein absolutes Plus.

Weiterführende Informationen

Software und Dokumentation

• Produktseite Raspberry Pi 4B
• Raspbian Linux (oder auch Raspberry Pi OS)
• Produktseite Phoscon Raspbee II
• Produktseite Phoscon Conbee II
• Homepage Home Assistant
• Home Assistant OS
• Zigbee Home Automation Integration
• Phoscon deCONZ Integration
• Webseite der Zigbee Home Alliance
• Webseite von Docker Inc.

Produkte*

• Phoscon Raspee II kaufen
• Raspberry Pi 4B 4GB kaufen
• Raspberry Pi Original Netzteil für Modell 4B
• Raspberry Pi Original Gehäuse für Modell 4B
• OSRAM Smart Classic E27 Zigbee Leuchtmittel
• OSRAM Smart Outdoor Plug
• Philips Hue Starter Kit mit Bridge und 2 Leuchtmitteln

Der Beitrag Zigbee Hub mit Raspberry Pi und Raspbee II erschien zuerst auf dahlen.org.

Bevor die eigentliche Installation beginnt, sind Vorarbeiten auf dem Raspberry notwendig, von dem ich an dieser Stelle ausgehe, dass er bereits mit einem aktuellen Raspbian 9 („Stretch“) bestückt ist. Auch solte der Kernel in der neuesten Version vorliegen, da es sonst zu Problemen mit den sog. Control Groups kommt.

sudo apt update
sudo apt full-upgrade
sudo rpi-update

Vor dem jetzt notwendigen Reboot werden die Kernel-Parameter in der Datei /boot/cmdline.txt noch angepasst, so dass die Control Groups (cgroup) für Speicher und CPU aktiviert sind. Sie werden für die Ressourcen-Vergabe an Container benötigt. Am einfachsten geht das wie folgt:

echo -n "$(head -n1 /boot/cmdline.txt) cgroup_enable=cpuset cgroup_enable=memory" | sudo tee /boot/cmdline.txt

Nun muss ein Reboot erfolgen, damit die Änderungen aktiviert werden. Danach beginnt die eigentliche Installation von Docker mit der De-Installation veralteter Versionen aus der Raspbian-Distribution. Warnungen an dieser Stelle wegen nicht installierter Pakete sind normal und können ignoriert werden:

sudo apt remove docker docker-engine docker.io containerd runc

Direkt im Anschluß wird die „offizielle“ Docker Version über das bereitgestellte „Convenience Script“ installiert. Laut der Docker Webseite ist dies aktuell die einzige Alternative für Raspbian, auch wenn ich schon andere Wege gesehen habe. Letztendlich fügt das Skript auch nur die geeigneten Paketquellen hinzu und installiert die aktuelle Version des docker-ce Paketes.

curl -fsSL https://get.docker.com -o - | sudo sh

Schließlich ist noch der eigene Nutzer der „docker“ Gruppe hinzufügen, damit auf den Einsatz des root-Users weitestgehend verzichtet werden kann:

sudo usermod -aG docker $(id -un)

Um die neue Gruppenzugehörigkeit zu aktivieren ist ein Ab- und erneutes Anmelden notwendig. Zur Überprüfung kann abschliessend ein Test gefahren werden.

docker run --rm hello-world

Fertig.

Weiterführende Informationen

Software und Dokumentation

• https://docs.docker.com/install/linux/docker-ce/debian/#install-using-the-convenience-script
• https://www.raspbian.org/

Der Beitrag Docker und Raspbian auf einem Raspberry Pi erschien zuerst auf dahlen.org.

Hardware

Beim Thema Heimautomatisierung / Smart Home setze ich vorwiegend auf Bauteile der „Homematic“ Serie von eq-3 bzw. ELV. Sie fügen sich diskret in den vorhandenen Wohnraum ein, weil sie als Unterputz-Lösung die klassischen Komponenten (wie Schalter und Taster) ersetzen, ohne deren Optik zu stören. Durch die Verwendung eines Funkprotokolls ist außerdem keine zusätzliche Verkabelung notwendig.

Leider wirken sich bautechnische Gegebenheiten vor Ort (Stahlbeton, Leitungen und „rustikale“ Treppenläufe) negativ auf die Übertragungsqualität aus, so dass die angeforderten Aktionen (Licht an/aus, Jalousie auf/zu) nicht ausgeführt werden. Um diesen Aussetzern zu begegnen, wurden bereits zwei Gateways für Versand und Empfang von Befehlen installiert, ein dritter soll nun die verbleibende Lücke schließen.

Die für die Realisierung des Vorhabens notwendigen Bauteile sind überschaubar und kosten insgesamt ca. 80 EUR. Damit liegt die Bastellösung im Preisebereich des Homematic LAN-Gateways, aber sie ist deutlich flexibler. Die größere Antenne wird außerdem zu einer höheren Sende- und Empfangsleistung führen.

Einkaufsliste

Folgende Teile habe ich beschafft:

• ein Raspberry Pi 3 (3B/3B+)
• ein CC1101 Modul nebst Antenne
• ein USB-Stick oder eine SD-Karte mit mindestens 16GB
• ein Steckernetzteil mit 5V und mindestens 2,5A
• ein einfaches Gehäuse aus stabilem Kunststoff

Je nach Gehäuse wird der Raspberry zunächst mit der Unterseite des Gehäuses verschraubt oder dort eingesteckt. Die daraus resultierende stabile Lage macht die späteren Arbeiten einfacher. Beim hier verwendeten Gehäuse von Aukru waren Kühlkörper vorhanden, welche im Vorfeld aufzukleben sind.

Das CC1101 Modul und die Antenne habe ich von cod.m GmbH bezogen, wie auch bei den anderen Gateways. Der Aufbau ist sauber, die Qualität gut und der Betrieb ist problemlos. Außerdem liegt eine exzellente Dokumentation bei und im Homegear-Forum ist unkomplizierter Support verfügbar.

Das Modul wird auf die Pins 17/18 – 25/26 gesteckt. Aus Richtung der USB-Ports müssen 7 Header-Pin-Paare frei bleiben und aus der anderen Richtung 8 Paare. Dabei wird das Modul natürlich mit der Antennenbuchse in Richtung HDMI-Buchse aufgesteckt.

Anschließend wird im Deckel des Gehäuses mit einem 6er Holzbohrer ein Loch gebohrt. Hier wird die Aufnahme für die Antenne eingesteckt und verschraubt. Die meines Erachtens ideale Position ist in Linie mit den inneren USB-Ports, zwischen CC1101 Modul und dem Chip direkt hinter dem USB-Port. Wichtig ist, dass im geschlossenen Zustand der Antennenadapter nicht gegen Bauteile des Raspberry Pi stößt.

Ist der Antennenadapter verschraubt, wird das andere Ende auf den Anschluss des CC1101 Moduls aufgesteckt. Anschließend wird die Stab-Antenne aufgeschraubt. Dann wird das Gehäuse geschlossen, die Hardware-Arbeiten sind damit erledigt.

Software

Raspbian

Im nächsten Schritt wird die Software eingerichtet, dabei kommt wieder Raspbian 9 Lite zum Einsatz, auf die Details der Installation gehe ich an dieser Stelle nicht ein und verweise auf den entsprechenden Artikel in diesem Blog. Ich verwende bei allen RPi3 übrigens USB-Sticks, weil diese mir im Gegensatz zu mancher SD-Karte noch nie kaputt gegangen sind.

Der vorbereitete USB-Stick wird in einen Port des Raspberry gesteckt, dieser per LAN mit meinem Netzwerk verbunden und schließlich mit Strom versorgt. Die Anbindung via WLAN wird seitens Homegear wegen der daraus resultierenden Latenzen nicht empfohlen. Wer es dennoch tun möchte – hier steht wie WLAN auch „headless“ eingerichtet werden kann.

Aus Gründen der Einfachheit wird im Folgenden davon ausgegangen, dass alle Aktionen als „root“-User auf den Systemen ausgeführt werden.

Nach dem Start von Raspbian auf dem Pi und dem Zugriff via SSH oder verbundener Tastatur ist über eine Einstellung das „Serial Peripheral Interface“ (SPI) zu aktivieren. SPI ist die Schnittstelle, über welches das CC1101 Modul mit dem Raspberry Pi „Mainboard“ kommuniziert.

Die Aktivierung erfolgt durch den Parameter dtparam=spi=on in der Datei /boot/config.txt. Dieser Parameter kann am einfachsten über das Programm raspi-config im Bereich „Interface Options“ angepasst werden. Mit raspi-config kann bei der Gelegenheit auch der Hostname des Raspberry Pi geändert werden. Ein Neustart des „Raspi“ ist auf jeden Fall fällig.

Homegear Gateway

Im nächsten Schritt wird die eigentliche Homegear Gateway Software installiert, dabei greife ich auf die offiziellen Paketquellen zurück und verwende die „stable“ Version. Entsprechend der Dokumentation sind folgende Befehle auf dem Raspberry auszuführen:

$ apt install apt-transport-https
$ curl https://apt.homegear.eu/Release.key | apt-key add -
$ echo 'deb https://apt.homegear.eu/Raspbian/ stretch/' | tee /etc/apt/sources.list.d/homegear.list
$ apt update
$ apt install homegear-gateway 

Durch die obigen Kommandos wird zunächst das Homegear-Repository der Paket-Verwaltung bekannt gemacht. Danach wird der Index aktualisiert und im letzten Schritt schließlich das Paket homegear-gateway mit seinen Abhängigkeiten installiert.

Dieser letzte Schritt nimmt einige Zeit (1-3 Minuten) in Anspruch, weil die Voraussetzungen für die spätere, verschlüsselte Kommunikation mit dem Homegear Master geschaffen werden.

Nun gilt es Homegear Gateway zu konfigurieren, so dass das verbaute CC1101 Modul verwendet und die Kommunikation mit Homegear ermöglicht wird. Die notwendigen Änderungen sind in der Datei /etc/homegear/gateway.conf vorzunehmen, welche in einem Editor (z.B. nano) zu editieren ist.

Basierend auf der Dokumentation zum CC1101 Modul von von cod.m zu ist der Abschnitt HomeMatic TICC1101 example config wie folgt zu ändern:

#{{{ HomeMatic TICC1101 example config
## The device family the gateway is for.
family = HomeMaticCc1101

## The device to use
device = /dev/spidev0.0

## The interrupt pin to use. "0" for GDO0 or "2" for GDO2.
## You only need to connect one of them. Specify the GPIO
## you connected the interrupt pin to below.
interruptPin = 0

## The GPIO GDO0 or GDO2 is connected to. Specify which GDO to use above.
gpio1 = 25

#}}}

Außerdem wird für die spätere Integration das automatisch generierte Konfigurationspassword (configurationPassword) benötigt. Dieses bitte in der Zwischenablage oder an geeigneter Stelle notieren.

Nach dem Speichern der Änderungen und dem Verlassen des Editors wird homegear-gateway noch für den automatischen Start nach einem Boot angemeldet und neu gestartet.

$ systemctl enable homegear-gateway
$ systemctl restart homegear-gateway

Damit sind die Vorbereitungen für den Gateway abgeschlossen, mit dem notierten configPassword, der IP-Adresse und dem Hostnamen des Gateway-Rechners geht es nun in Richtung Homegear „Master“, um die Verbindung zu initiieren.

Homegear Master

Wie gesagt agieren die Raspberry Pi als Gateways, welche Informationen zwischen den verbundenen Homematic-Geräten und dem Master austauschen. Die Anbindung der Gateways an den Master ist in der Dokumentation von Homegear ausreichend genau beschrieben. Für diesen Artikel ist daher die Kurzfassung ausreichend, wobei davon ausgegangen wird, dass auf dem Master die Pakete homegear, homegear-homematicbidcos und homegear-management nebst Abhängigkeiten installiert und konfiguriert sind.

Zunächst wird via Homegear Management eine sog. Certificate Authority (CA) erzeugt, welche später die Zertifikate für die verschlüsselte Übertragung zwischen Master und Gateway beglaubigt:

homegear -e rc 'print_v($hg->managementCreateCa());'

Der Befehl wird asynchron im Hintergrund ausgeführt. Der Fortschritt kann durch wiederholten Aufruf des folgenden Befehls überprüft werden. Er ist abgeschlossen, sobald das Feld exitCode im Ergebnis den Wert 0 hat:

homegear -e rc 'print_v($hg->managementGetCommandStatus());'

Sobald die CA angelegt wurde, kann das notwendige Client-Zertifikat für das Gateway erzeugt werden. Dabei ist der Platzhalter <HOSTNAME> durch den Hostnamen des Gateway-Raspberry zu ersetzen:

homegear -e rc 'print_v($hg->managementCreateCert("<HOSTNAME>"));'

Auch dieser Befehl wird asynchron im Hintergrund abgearbeitet. Wieder kann der Fortschritt über $hg->managementGetCommandStatus() (s.o.) überprüft werden.

Ist auch dieser Vorgang abgeschlossen, können alle erzeugten und notwendigen Zertifikate an das Gateway übertragen werden, welches unmittelbar danach seine Arbeit aufnimmt und für eingehende Verbindungen zur Verfügung steht.

Die Platzhalter sind wie folgt zu ersetzen:

• <IP> mit der IP des Gateways
• <HOSTNAME> mit dem Hostnamen des Gateways
• <PASSWORD> mit dem oben notierten Wert des Parameters
  configurationPassword aus der gateway.conf Datei.

homegear -e rc '$hg->configureGateway("<IP>", 2018, file_get_contents("/etc/homegear/ca/cacert.pem"), file_get_contents("/etc/homegear/ca/certs/<HOSTNAME>.crt"), file_get_contents("/etc/homegear/ca/private/<HOSTNAME>.key"), "<PASSWORD>");'

Vor einem Neustart von Homegear auf dem Master sind die Details des neuen Gateways noch in die Konfiguration der Homematic/BidCoS-Gerätefamilie einzutragen, welche unter /etc/homegear/families/homematicbidcos.conf abgelegt ist. Wieder sind die Platzhalter entsprechend zu ersetzen:

#######################################
########## Homegear Gateway  ##########
#######################################

## The device family this interface is for
[Homegear Gateway]

## Specify an unique id here to identify this device in Homegear
id = <HOSTNAME>

## When default is set to "true" Homegear will assign this device
## to new peers.
default = false

## Options: cul, cc1100, coc, cunx, hmcfglan, hmlgw, hm-mod-rpi-pcb, homegeargateway
deviceType = homegeargateway

## The host name or IP address of the gateway
host = <IP>

## The port of the gateway
port = 2017

## The CA certificate
caFile = /etc/homegear/ca/cacert.pem

## The client certificate
certFile = /etc/homegear/ca/certs/<HOSTNAME>.crt

## The client key file
keyFile = /etc/homegear/ca/private/<HOSTNAME>.key

## Use the ID defined above to verify the common name of the certificate
## Default: false
useIdForHostnameVerification = true

## Default: responseDelay = 95
## Should be "95" for CUL or COC, "100" for TI CC1101, "98" for Homegear Gateway and "60" for HM-CFG-LAN or HM-LGW
responseDelay = 98

Abschließend muss ein letztes Mal homegear auf dem Master neu gestartet werden und wenn alles korrekt installiert und konfiguriert wurde, sollten nach wenigen Minuten BidCoS Pakete über das neue Gateway empfangen werden. Entsprechende Logmeldungen in /var/log/homegear/homegear.log folgen dabei diesem Muster:

HomeMatic BidCoS packet received (<HOSTNAME>, RSSI: -45 dBm)

Weiterführende Informationen

Software und Dokumentation

• Certificate Authoritfy für Homegear einrichten
• Einen Homegear-Gateway verbinden
• Homegear: Pakete für Rasbpian 9 (Stretch), „stable“
• Homepage von Homegear
• Support im Homegear Forum
• Wikipedia: Serial Peripheral Interface

Produkte*

• cod.m CC1101 SPI Bundle 18cm/3.0dBi
• Raspberry Pi 3 Modell B
• Aukru Micro-USB Netzteil, 5V 3A
• Aukru Gehäuse für Raspberry Pi 3
• SanDisk Ultra Fit 16GB USB 3.0 Stick
• Homematic LAN Gateway

Der Beitrag Homegear-Gateway mit CC1101 und Raspberry Pi 3 erschien zuerst auf dahlen.org.

Laut der Projektbeschreibung auf Github handelt es sich bei esphomelib von Otto Winter um „a framework for using your ESP8266/ESP32 devices with Home Assistant“. Und tatsächlich ist esphomelib mehr als eine weitere Firmware für ESP8266/ESP32 MCUs: Neben entsprechenden Bibliotheken werden auch Werkzeuge geliefert, welche das Erstellen und Einspielen angepasster Firmware zum Kinderspiel machen. Vor allem aber ist esphomelib auf die einfache Verbindung mit Home Assistant ausgerichtet und nutzt hierfür das MQTT-Discovery Feature von HA

Home Assistant MQTT Discovery

Bei MQTT-Discovery wird die MQTT-Anbindung von Home Assistant aktiviert und es wird auf eingehende (Konfigurations-) Nachrichten auf vorgegebenen Kanälen (Topics) gelauscht. Die so gewonnenen Informationen werden von HA genutzt um automatisch neue Geräte (Entity) einzurichten. Details finden sich in der Dokumentation von Home Assistant.

Um MQTT-Discovery mithilfe des in HA eingebetteten MQTT Brokers zu aktivieren, ist folgende Ergänzung in der configuration.yaml von Home Assistant vorzunehmen:

mqtt: 
  discovery: true
  username: homeassistant
  password: mypassword

Sollte ein externer Broker eingesetzt oder weitere Einstellungen vorgenommen werden, ist entsprechend der Anleitung zu verfahren. Ein Passwort ist seit Home Assistant 0.76 Pflicht.

Anschließend ist Home Assistant neu zu starten. Wer – wie ich – Home Assistant in einem Docker-Container laufen lässt, muss entweder den Port 1883 durchschleifen (docker -p 1883:1883 …) oder das Host-Network verwenden (docker –net=host …). War die Konfiguration korrekt und der Neustart erfolgreich, taucht ein neues Symbol in den Entwickler-Werkzeugen von HA auf ().

esphomelib / esphomeyaml

Um die Installation und Verwendung von esphomelib erheblich zu vereinfachen, stellt Otto Winter ein Werkzeug namens esphomeyaml zur Verfügung. esphomeyaml unterstützt bei der Erzeugung einer esphomelib-Konfiguration auf YAML-Basis, sowie bei der Erzeugung und Übertragung der der daraus abgeleiteten Firmware. Es wird auch ein Docker-Image angeboten, welches alle Abhängigkeiten für esphomelib enthält.

Anlegen einer Konfiguration mit Docker und esphomeyaml

Der folgende Abschnitt ist im Wesentlichen eine Zusammenfassung der Getting Started with esphomeyaml Anleitung für die Verwendung mit Docker. Zunächst wird der Wizard von esphomeyaml verwendet, um eine Basis-Konfiguration zu erstellen.

docker run --rm -v "$PWD":/config -it ottowinter/esphomeyaml myfile.yaml wizard

Der Befehl startet einen temporären Docker-Container, in welchem der esphomeyaml-Assistent ausgeführt wird und interaktiv bei der Erstellung einer Konfiguration (Dateiname myfile.yaml) unterstützt. Die (aktuell) 5 Bereiche mit teilweise mehreren Fragen sind ausführlich dokumentiert, daher hier in aller Kürze:

Core und Platform

name

Ein symbolischer Name, welcher u.a. in Home Assistant Verwendung findet. Erlaubt sind Buchstaben, Ziffern und der Unterstrich. Empfohlen wird der Raumname, in welchem der MCU zum Einsatz kommt (z.B. wohnzimmer)

ESP32/ESP8266

Plattform, welcher der MCU zugeordnet wird. Neben ESP8266 werden auch die moderneren ESP32-Module unterstützt. Die Frage dient der Vorauswahl für die möglichen Antworten der nächsten Frage. Für den Wemos D1 Mini ist hier ESP8266 zu wählen.

board

Hier ist das verwendete Board genauer zu spezifizieren. Eine Liste der unterstützten Boards (und der jeweiligen Kürzel) findet sich bei platform.io. Für den Wemos D1 Mini ist hier d1_mini anzugeben.

Wifi

Der nächste Satz an Fragen beschäftigt sich mit dem zu nutzenden WLAN Netzwerk. Es werden nacheinander die Netzwerk-Kennung (SSID), sowie das Passwort (PSK) abgefragt.

MQTT

Schließlich werden Details zum zu nutzenden MQTT-Broker abgefragt, im Detail

• die IP-Adresse des MQTT-Brokers
• ein eventueller Benutzername für den Zugriff
• ein Passwort für den Zugriff auf den MQTT-Broker

Wird – wie in diesem Beispiel – der interne MQTT-Broker von Home Assistant verwendet, entspricht die IP-Adresse der des (Docker-) HA-Hosts, Username und Password sind entsprechend der MQTT-Konfiguration in Home Assistant vorzunehmen.

Over-the-Air

Ein weiteres cooles Feature ist die Möglichkeit zum Over-the-Air-Update (OTA), welches genutzt werden kann, sobald die esphomelib-Firmware erstmalig erfolgreich (via USB) auf die MCU überspielt wurde. Aus Sicherheitsgründen kann hierfür ein Kennwort vergeben werden.

Anpassen der Konfiguration

Als Ergebnis des vorherigen Abschnitts findet sich im aktuellen Verzeichnung nun eine Datei namens myfile.yaml, welche die Basics der Firmware definiert. Nun gilt es die mit dem Board verbundenen Geräte einzutragen und somit via MQTT (und damit über Home Assistant) steuerbar zu machen.

Für das auf dem Wemos D1 verbundene Relais aus dem letzten Post ist folgender Abschnitt in myfile.yaml zu ergänzen:

switch:
  - platform: gpio
    name: "steckdose"
    pin: D1

Damit wird esphomelib konfiguriert, gegenüber Home Assistant einen Schalter (switch) auszuweisen und eingehende Schaltbefehle über den GPIO-Pin D1 des Wemos D1 Mini abzubilden. Sind weitere Geräte (z.B. Sensoren) mit dem ESP8266 verbunden, ist die myfile.yaml entsprechend zu erweitern. Eine Liste der unterstützten Komponenten und entsprechende Konfigurationsbeispiele finden sich in der esphomeymal-Dokumentation.

Firmware erstellen und übertragen

Ist die Konfiguration vollständig, kommt wieder Docker zum Einsatz, um die Firmware zu erstellen, zu übertragen und auf dem ESP auszuführen. Vorher ist die MCU natürlich mit dem PC via USB zu verbinden. Unter Linux wird dabei ein serielles Device (z.B. /dev/ttyUSB0) angelegt, welches an den Docker-Container durchgeleitet werden muss. Außerdem muss der Container im „privileged“ Modus laufen, um die Firmware übertragen zu können. Alles nicht weiter schwierig:

 docker run --rm -v "$PWD:/config" -v /dev/ttyUSB0:/dev/ttyUSB0 \
  --privileged -it ottowinter/esphomeyaml myfile.yaml run

Der Prozess läuft weitestgehend automatisch ab. Lediglich der Weg zur Firmware-Übertragung ist zu wählen. Bei erstmaliger Bespielung ist hier der USB-zu-serielle Port zu wählen, sollte esphomelib bereits auf dem MCU sein, kann auch OTA gewählt werden.

Found multiple serial port options, please choose one:
[0] /dev/ttyUSB0 (USB2.0-Serial)
[1] Over The Air (d1mini_1.local)

Nach der Übertragung bleibt die Verbindung zum Wemos D1 Mini offen und das Gerät wird neu gestartet. Boot und andere Meldungen (z.B. die Verbindung zum WLAN und zum MQTT-Broker) werden via Docker-Container ausgegeben, bis dieser beendet wird (mittels Strg-c). Die eigentliche Firmware läuft natürlich auch danach weiter.

Nutzung in Home Assistant

Durch die Verwendung von MQTT-Discovery wird der an den Wemos angeschlossen Switch (das Relais) direkt in Home Assistant angelegt. In der Zustandsansicht () wird es – gemäß meinem Beispiel als switch.steckdose geführt. Dort besteht auch die Möglichkeit über das -Symbol einen Test-Dialog zu öffnen und sich vom (hoffentlich) erfolgreichen Ergebnis der Operation zu überzeugen.

Latenz

Das nachfolgende Video demonstriert die geringe Latenz zwischen der Anforderung in Home Assistant und der Umsetzung durch esphomelib. Home Assistant inkl. des eingebetteten MQTT-Brokers laufen dabei auf einem Raspberry Pi 3B. Das Mobiltelefon und der D1 Mini sind im gleichen WLAN, also per Access Point und Gigabit-LAN mit dem Raspberry verbunden. Das sichtbare Kabel geht zu einer USB Power-Bank. Eine Verzögerung zwischen Antippen des User Interfaces und Schalten des Relais (rote LED) ist faktisch nicht feststellbar.

Fazit

Die Verwendung von esphomelib bzw. esphomeyaml für ESP-Module in Verbindung mit dem MQTT-Discovery-Feature von Home Assistent ist aktuell die einfachste, mir bekannte Möglichkeit diverse Aktoren oder Sensoren zu kontrollieren und zu steuern. Die vom esphomelib-Projekt bereitgestellten Werkzeuge greifen sehr gut ineinander und erlauben die Konfiguration und Übertragung der Firmware auch ohne Programmier-Kenntnisse.

Für Verwender von HASS.io, der „Appliance“-Variante von Home Assistant existiert sogar ein entsprechendes Add-On, um esphomelib/esphomeyaml direkt aus HASS.IO anzusteuern. Sogar eine web-basierte Variante des Wizards wird hier geboten.

Weiterführende Informationen

Software und Dokumentation

• esphomelib-Homepage
• esphomelib-Projekt auf Github
• Getting Started with esphomeyaml
• durch esphomelib/platform.io unterstützte Komponenten
• Home-Assistant MQTT Auto-Discovery
• HASS.IO

Produkte*

Die folgenden Produkte wurden im Artikel besprochen bzw. verwendet:

• Wemos D1 Mini bei Ali Express
• Wemos D1 Mini bei Amazon
• Wemos Relay Shield (und Nachbauten) bei Ali Express
• Wemos Relay Shield bei Amazon

Der Beitrag ESP8266 via esphomelib mit Home Assistant verbinden erschien zuerst auf dahlen.org.

Im privaten Umfeld stehen die verwandten Themen Heimautomatisierung und Smart Home im Fokus. Eine sehr gute Basis dafür sind ein Raspberry Pi 3, Docker und Home Assistant …

In den letzten beiden Jahren habe ich viel Zeit (und Geld) in die Vernetzung unseres Heims gesteckt. Bereits vorhandene Gerätschaften (wie Computer, AV-Receiver und Fernseher) wurden um neue Aktoren zum Schalten und Sensoren zum Messen ergänzt.

Im Mittelpunkt der Installation stehen dabei ein Raspberry Pi 3 und Home Assistant.

Raspberry Pi 3

Der Raspberry Pi 3 ist die ideale Plattform für Heimautomatisierung, nicht nur für Home Assistant. Er ist ausreichend schnell, bietet ausreichend Speicher und seine USB- und GPIO-Ports können für die Anbindung diverser Systeme und Standards (ZWave, Zigbee) genutzt werden. Außerdem verbraucht er minimal Strom und kann daher ohne Belastung des Öko-Gewissens 24/7 betrieben werde.

Dieser Artikel geht entsprechend davon aus, dass ein Raspberry Pi 3 mit einem aktuellen Raspbian Linux versorgt wurde und im heimischen Netz via LAN der WLAN erreichbar ist. Für Unterstützung bei der Einrichtung kann auf meine anderen Artikel zu diesem Thema zurückgegriffen werden.

Die Zusammenführung der teilweise isolierten Systeme übernimmt dabei die Software Home Assistant. Es gibt viele Wege Home Assistant auf einem Raspberry Pi zu installieren und alle sind hervorragend dokumentiert. Allerdings habe ich mich weder für eine direkte Installation via pip, noch für die Verwendung von hass.io entschieden, sondern für einen Mittelweg: Docker.

Docker

Der Grund ist einfach: Ich verwende auf dem Raspberry Pi Raspbian, also ein Debian Derrivat. Und die Paketverwaltung von Debian ist apt. Die Verwendung anderer Paketmanager, wie pip für Python oder npm für NodeJS, führt m.E. nur zu Chaos.

Andererseits möchte ich den Raspi nicht in eine Appliance verwandeln, sondern durchaus auch mit anderen Aufgaben bedenken. Ansätze wie HASS.IO oder Hassbian erschwerden dies durch die notwendige Abschottung des unterliegenden Betriebssystems.

Software, welche nicht per apt zur Verfügung steht wird also in einem Docker Container betrieben, um die Auswirkungen auf das Hostsystem zu minimieren.

Installation von Docker

Docker ist aktuell in den Raspbian Repositories vorhanden (Paket docker.io) und könnte somit direkt via apt installiert werden. Doch die Entwicklung von Docker läuft schneller als die Release-Zyklen von Raspbian, so dass ich das offizielle Docker-Respository nutze, um die aktuellste Version via apt installieren zu können.

$ curl -sSL https://get.docker.com | sh

Wer sich in das ausgeführte Skript einarbeitet erkennt, dass hier lediglich die Schritte zur Anbindung des Docker Debian Respositories inkl. GPG-Key Download automatisiert werden. Sie können alle auch manuell ausgeführt werden, aber das Skript ist einfach convenient.

Damit wir docker als regulärer Benutzer ohne sudo ausführen können, fügen wir – wie empfohlen – den aktuellen Benutzer der Gruppe docker hinzu. Der hier bespielhaft genannte Account pi ist durch den tatsächlichen Benutzernamen zu ersetzen:

$ sudo usermod -aG docker pi

Nach einer Ab- und Anmeldung sollte sich nun ein erster Docker Container ausführen lassen:

$ docker run --rm hello-world

Home Assistant

Nun da Docker einsatzbereit ist, können wir Home Assistant installieren und im Container betreiben. Für diese Einführung belasse ich die Konfiguration von Home Assistant unverändert, d.h.:

• es wird die integrierte SQLite Datenbank verwendet
• die Home Assistant Oberfläche ist auf Port 8123 zu erreichen
• die discovery-Komponente durchsucht das lokale Netz nach bekannten IoT-Geräten

Installation von Home Assistant mit Docker

Docker Container sind vergänglich (ephemeral), ebenso wie die in ihnen verwendeten Daten. Um Konfiguration und andere Laufzeitdaten zu persistieren, müssen wir Docker einen Platz zum Speichern außerhalb des Containers zuweisen. Dort wird Home Assistant seine initiale Konfiguration erzeugen und dauerhaft verwenden.

Zunächst erstellen wir ein lokales Verzeichnis (der Name ist beliebig):

$ cd ~
$ mkdir home-assistant

Anschließend starten wir unseren Container auf Basis des offiziellen Home-Assistant Images für den Raspberry Pi 3:

$ docker run -d  \
  --name=hass --net=host --restart=always \
  -v $PWD/home-assistant:/config \
  -v /etc/localtime:/etc/localtime:ro \
  homeassistant/raspberrypi3-homeassistant:latest

Durch obigen Befehl wird die aktuelle Version des Docker Image (und seine Basis) von Home Assistant für Raspberry Pi 3 heruntergeladen und ein darauf aufbauender Container namens „hass“ wird gestartet. Das lokale Verzeichnis home-assistant und die Zeitzone werden in den Container eingebunden. Die genaue Bedeutung der Parameter kann per $ docker run --help ermittelt werden.

Der Vorgang dauert ein wenig, aber nach einigen Sekunden sollte das Web-Interface von Home Assistant über den DNS-Namen oder die IP-Adresse des Raspberry zugänglich sein, z.B. http://raspberrypi:8123/.

Der tatsächliche Inhalt des Willkommen-Bereichs kann sich unterscheiden, da die in Home Assistant enthaltene Discovery Komponente möglicherweise Geräte (z.B. Philips Hue, Google Home oder Sonos Lautsprecher) bereits aufgespürt und eingebunden hat.

Konfiguration von Home Assistant

Das lokale Verzeichnis (home-assistant) wurde dem Container zur Verfügung gestellt. Entsprechend hat Home Assistant hier seine initiale Konfiguration abgelegt. Da der Container mit den Rechten des aktuellen Benutzers gestartet wurde, sind auch die Konfigurationsdateien in seinem Besitz. So kann jetzt mit einem Editor (z.B. vi oder nano) die grundsätzliche Konfiguration unter home-assistant/configuration.yaml bearbeitet werden. Beispielhaft kann der Eintrag „introduction:“ (ca. Zeile 17) entfernt werden, um den Einführungstext zu verwerfen.

Neustart von Home Assistant

Bei Änderung der Core-Konfiguration ist Home Assistant neu zu starten. Auch wenn dies über die Web-Oberfläche möglich ist (unter Einstellungen), ist der Neustart des Docker Containers oft die schnellere Lösung:

$ docker restart hass

Aktualisierung des Containers

Etwa alle 2 Wochen erscheint eine neue Version von Home Assistant, dazwischen werden Minor Releases mit Korrekturen veröffentlicht. Auch die Docker Images werden dabei zeitnah aktualisiert und können für neue Container-Instanzen verwendet werden. Existierende Container verwenden jedoch immer ihr ursprüngliches Image, daher ist die laufende Instanz zunächst zu löschen (keine Sorge, die Konfiguration im lokalen Verzeichnis bleibt bestehen):

$ docker rm -f hass

Anschließend kann ein neuer Container wie oben beschrieben gestartet werden.

Fazit

Der Einstieg in die Heim-Automatisierung ist einfach und kostengünstig möglich. Viele Geräte im Haushalt sind bereits netzwerk-fähig und können über diese Schnittstelle überwacht oder gesteuert werden. Andere dienen als einfache Sensoren, so kann ein Router zur Erkennung anwesender Mobiltelefone beitragen. Und nicht zuletzt existiert bereits eine Fülle von Internet-Diensten, welche als Signale in der Steuerung des Smart Home genutzt werden können.

Home Assistant ist eine einfach zu installierende und leicht zu verwendende Software, welche wie geschaffen für einen Raspberry Pi (3) ist. Die gute Dokumentation und eine aktive Community erleichtern den Einstieg und stehen für Fragen und Ratschläge zur Verfügung.

Weiterführende Informationen

Software und Dokumentation

• Home Assistant
• Home Assistant: Getting Started
• Home Assistant: HASS.IO
• Home Assistant Forum
• Raspbian Linux
• Raspberry Pi 3 Modell B für USB Boot vorbereiten
• Raspberry Pi Zero W headless Setup – so geht’s
• Docker Comes to Raspberry Pi
• Home Assistant: Docker Image für Raspberry Pi 3

Produkte*

Die folgenden Produkte wurden im Artikel besprochen bzw. verwendet:

• Raspberry Pi 3 Modell B

Der Beitrag Home Assistant mit Docker auf Raspberry Pi betreiben erschien zuerst auf dahlen.org.

Raspberry Pi 3B+

Beim neuen Modell 3B+ wurde im Wesentlichen Modellpflege betrieben, in der Automobilindustrie wäre vermutlich die Rede von einem Facelift:

• die CPU Geschwindigkeit wurde von 1,2GHz auf 1,4GHz erhöht
• die Anbindung des LAN-Ports erlaubt jetzt bis zu 300MBit/s
• WLAN funkt jetzt nach 802.11ac auch im 5GHz Band
• Bluetooth 4.2 wird jetzt unterstützt

Weitere Details lassen sich der entsprechenden Ankündigung der Raspberry Pi Foundation entnehmen.

Booten von USB

Auch der 3B+ kann ab Werk nicht von USB-Medien booten. Doch analog zum Modell 3B (ohne Plus) kann dies mit wenigen Handgriffen geändert werden. Im Gegenteil, die für den 3B+ notwendige aktuelle Raspbian-Version macht den Vorgang sogar noch einfacher.

An dieser Stelle irrt der Autor, das 3B+ Modell des Raspberry Pi kann offenbar ohne Vorbereitung direkt von USB (und sicherlich auch via Netzwerk) booten. Die unten beschriebene Vorbereitung ist also für das Plus-Modell nicht notwendig, sondern nur für das Modell 3. Allerdings wird auch kein Schaden angerichtet, falls das Vorgehen für den 3B+ angewendet wird.

Für die Durchführung sind ein aktuelles Raspbian Linux, Etcher, ein guter USB-Stick (ab 16GB) und temporär eine Micro-SD-Karte (4GB) notwendig. Ich habe Produkte von SanDisk eingesetzt, welche noch in diversen Schubladen zu finden waren. Da der RPi 3B+ etwas stromhungriger ist, sollte außerdem auf ein gutes Netzteil (5,1V, 2,5A) geachtet werden.

Vorbereitung

Zunächst sind die aktuelle Raspbian (Lite)-Version und Etcher (Portable) herunterzuladen. Anschliessend sind die SD-Karte und der USB-Stick mit dem PC zu verbinden und Etcher zu starten. Evtl. Inhalte auf Stick und Karte müssen gesichert werden, denn ihr Inhalt geht durch das Flashen unwiderruflich verloren!

In Etcher wählt man folgendes Vorgehen:

• Über Select Image wählt man das heruntergeladene Raspbian-Abbild aus, z.B. 2018-03-13-raspbian-stretch-lite.zip. Das Archiv kann von Etcher direkt verarbeitet werden und muss nicht entpackt werden.
• Mittels Select Drive wählt man das zu beschreibende Medium aus. Für diesen Artikel wurde mit dem USB-Stick begonnen, aber die Reihenfolge ist letztendlich egal.
• Durch die Option Flash startet der Schreibvorgang, der je nach Rechnerleistung, Mediengröße und Lesegerät einige Sekunden bis Minuten dauert.
• Nach erfolgreicher Durchführung wählt man die Option Flash Another und beginnt mit der Vorbereitung des verbleibenden Speichermediums. In meinem Beispiel ist das die SD-Karte, welche in einem Lexar Lesegerät steckt.
• Wieder startet ein Klick auf Flash den eigentlichen Schreibvorgang. Nach Abschluss kann Etcher beendet werden.

Die Etcher-Dialog-Folge anbei nochmal in Bildern. Wie gesagt: Die Reihenfolge zwischen SD-Karte und USB-Stick ist unbedeutend, solange beide Medien mit dem selben Raspbian-Abbild beschrieben werden.

Wer den Raspberry „headless“ betreiben möchte, d.h. ohne Monitor und Tastatur, der kann jetzt auf dem USB-Stick noch die entsprechenden Vorbereitungen treffen, analog zu diesem Artikel. Andernfalls ist der Stick damit vorbereitet, er kann ausgeworfen, abgezogen und zur Seite gelegt werden.

Konfiguration

Der Inhalt der SD-Karte muss noch geändert werden, sie verbleibt zunächst im Lesegerät. Je nach Betriebssystem ist es evtl. notwendig die Karte zunächst zu entnehmen und dann wieder einzustecken, damit die Änderungen erkannt werden.

Auf der SD-Karte befindet sich nach dem Beschreiben eine Partition im DOS-Format (boot) und auf dieser wiederrum die Datei config.txt. In dieser Datei ist eine Zeile hinzuzufügen, wobei auf die Beibehaltung der Zeilenenden geachtet werden muss. Unter Windows ist daher Wordpad zu verwenden und nicht der Editor (Notepad).

Ans Ende der Datei fügen wir die Zeile program_usb_boot_mode=1 an, so dass (Stand 19.03.2018) die letzten 3 Zeilen von config.txt wie folgt aussehen:

# Enable audio (loads snd_bcm2835)
dtparam=audio=on
program_usb_boot_mode=1

Durch die neue Zeile werden beim nächsten Start des Raspberry Pi 3 (B/B+) unwiderruflich die USB- und Netzwerk- (PXE) Boot-Option aktiviert. Der Prozess ist nicht umkehrbar, da die Änderung im OTP-Speicher des RPi eingetragen wird. Details sind der Dokumentation zu entnehmen. Der Einsatz von SD-Karten ist allerdings unverändert möglich, die neue Boot-Reihenfolge lautet nun:

1. SD-Karte
2. USB-Medium
3. Netzwerk-Boot (PXE)

Aktivierung

Jetzt ist auch die SD-Karte fertig vorbereitet und kann ausgeworfen bzw. entnommen werden. Anschließend ist sie in den Raspberry einzustecken und dieser mit Strom zu versorgen. Der Startvorgang und die Aktivierung des USB-Boots läuft ohne manuellen Eingriff ab. Ein eindeutiges Zeichen für einen abgeschlossenen Boot-Vorgang gibt es leider nicht, bei meinem 3B blinkt die grüne LED jede Sekunde, beim 3B+ blitzt sie. Es ist wichtig, dass die rote LED dauerhaft leuchtet, andernfalls ist die Stromversorgung zu schwach.

Gebt dem Raspi einfach 1-2 Minuten, bevor er wieder vom Strom getrennt wird. Eventuellen Datenverlust der SD-Karte nehmen wir hin, denn sie wird nicht mehr benötigt.

Nun wird der USB-Stick in einen beliebigen Port des Raspberrys gesteckt und wieder mit Strom versorgt. Der Start sollte jetzt von USB erfolgen, wobei auch hier beim ersten Start zunächst das Filesystem auf die volle Partitionsgröße erweitert und dann automatisch neu gestartet wird.

Somit wurde der Raspberry Pi 3 auf USB-Boot umgestellt und kann nun dauerhaft ohne SD-Karte betrieben werden.

tl;dr;

Hier nochmal die Zusammenfassung:

• Für das Modell 3B+
  1. aktuelles Raspbian Lite via Etcher auf USB-Stick flashen
  2. USB-Stick einstecken und Raspberry Pi 3 starten und konfigurieren
• Für das Modell 3B:
  1. aktuelles Raspbian Lite via Etcher auf SD-Karte und USB-Stick flashen
  2. Zeile program_usb_boot_mode=1 an Datei config.txt auf SD-Karte anfügen
  3. SD-Karte in Raspberry Pi 3 einstecken, starten und wieder runterfahren
  4. SD-Karte entfernen, USB-Stick einstecken und Raspberry Pi 3 starten und konfigurieren

Links

1. Raspberry Pi Foundation: Ankündigung Raspberry Pi 3B+
2. Raspberry Pi Foundation: Dokumentation Boot-Modi
3. Raspbian Linux (Übersicht)
4. Raspbian Linux Lite (Download)
5. Etcher
6. Raspberry Pi Headless Setup

Produkte*

Die folgenden Produkte wurden im Artikel besprochen bzw. verwendet:

• Raspberry Pi 3 Modell B+
• SanDisk Ultra Fit USB Stick, 16GB, USB 3.0
• SanDisk Ultra 16GB microSDHC Speicherkarte
• RAVPower 4-Port USB Ladegerät 40W 5V /8A
• Lexar SD- und CF-Kartenleser USB 3.0

Der Beitrag Raspberry Pi 3 Modell B für USB Boot vorbereiten erschien zuerst auf dahlen.org.

Eine lösbare Herausforderung …

Den Zero W gibt es für unter 15 EUR (ohne Zubehör) bzw. für unter 30 Euro als Essential Paket (z.B. bei Amazon). Für die Installation wird eine geeignete Micro-SD-Karte mit mindestens 8GB Kapazität benötigt. Außerdem ein Kartenleser (z.B. von Lexar, bei Amazon), welcher an einen weiteren Rechner angeschlossen wird.

Vorbereitung

Das Bespielen der SD-Karte mit Raspbian lt. Install Guide ist schnell erledigt und mündet folgender Partitionierung:

1. die boot-Partition, welche das DOS-Dateisystem nutzt und
2. die root-Partition, welche das Linux Ext-Dateisystem nutzt.

Wir werden ausschließlich den Inhalt der boot-Partition erweitern, dank DOS-Dateisystem sind die folgenden Änderungen unter allen populären Betriebssystemen möglich.

OpenSSH-Service aktivieren

Gemäß offizieller Anleitung (Abs. 3) ist im Stammverzeichnis der boot-Partition eine Datei namens ssh zu erstellen. Die reine Existenz dieser Datei führt im Raspian-Boot-Prozess dazu, dass der OpenSSH Server automatisch aktiviert wird und eingehende Verbindungen auf Port 22 annimmt.

WLAN-Konfiguration vorbereiten

Der zweite Schritt ist etwas umfangreicher. Ebenfalls im Stammverzeichnis der boot-Partition wird die Datei wpa_supplicant.conf erstellt. Lt. ungeprüfter Aussagen muss sie Linux-Zeilenenden aufweisen. Wie in den Hintergrundinformationen angekündigt, wird diese Datei beim Start automatisch an die richtige Stelle /etc/wpa_supplicant/ verschoben.

Die Datei hat folgenden Inhalt:

country=DE 
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev 
update_config=1 
network={
     ssid="WLAN SSID"
     scan_ssid=1
     psk="WLAN PASSWORT"
     key_mgmt=WPA-PSK
}

Die Werte WLAN SSID und WLAN PASSWORT sind natürlich durch die tatsächlichen Angaben zu ersetzen. Befindet man sich nicht in Deutschland, ist DE durch den ISO-Code des aktuellen Landes zu ersetzen.

Start

Damit sind die Vorbereitungen für den ersten Start abgeschlossen. Die SD-Karte wird nun in den Raspberry Pi gesteckt und dieser mit Energie versorgt. Nach einigen Sekunden sollte der Raspberry Pi im WLAN auftauchen, als Standard-Hostname wird dabei raspberrypi verwendet. Im WLAN-Access Point sollte sich auch die vergebene IP-Adresse ermitteln lassen.

Mittels eines geeigneten SSH-Clients kann nun die Anmeldung erfolgen. Das Passwort zum Standard-Benutzer pi ist in der offiziellen Dokumentation zu finden und sollte nach der 1. Anmeldung unbedingt geändert werden.

Das Verfahren zur WLAN-Client-Definition kann übrigens wiederholt werden und eignet sich somit auch, um eine nachträgliche Änderung headless durchzuführen.

Der Beitrag Raspberry Pi Zero W „headless“ Setup – so geht’s erschien zuerst auf dahlen.org.

In diesem dritten und vorerst letzten Teil wird auf die Anbindung von stationären und mobilen Clients eingegangen. Dabei kommen vorerst iOS und Mozilla Thunderbird zum Einsatz. Der fiktive ownCloud Server ist dabei unter der URL https://owncloud.dahlen.org/ mit dem Benutzer cloudmaster zu erreichen.

Client-Geräte und -Software

Die Nutzungsmöglichkeiten von ownCloud via iPhone oder anderen mobilen Geräten sind vielfältig. Neben einem Zugriff über die entsprechende ownCloud App können Kontakte und Kalenderdaten über das CardDAV resp. CalDAV Protokoll verwaltet werden, welches von iOS direkt unterstützt wird.

Geräte mit Apples iOS

Die entsprechenden Assistenten zur Einrichung in iOS sind recht straight-forward, benötigen aber etwas Vorarbeit auf der Server-Seite. Zur automatischen Erkennung der Möglichkeiten fragt iOS zunächst die Pfade

• /.well-known/carddav bzw.
• /.well-known/caldav ab.

Diese existieren in ownCloud nicht, ihre Funktionalität allerdings sehr wohl, nur an anderer Stelle. Am einfachsten ist es jetzt, die Anfragen per HTTP Redirect umzuleiten. Dazu wird die Konfiguration unter /etc/lighttpd/lighttpd.conf um einen Eintrag ergänzt, z.B. ab Zeile 22:

url.access-deny = ( „~“, „.inc“ )
url.redirect = (
„^/.well-known/carddav$“ => „/remote.php/carddav/“,
„^/.well-known/caldav$“ => „/remote.php/caldav/“
)

Außerdem ist es wichtig, daß man den eigenen Kalender in ownCloud über den Browser mindestens 1x aufruft. Erst dann werden die notwendigen Strukturen in ownClouds CalDAV-Server eingerichtet.

Dann kann die Anbindung via iPhone beginnen. Die Assistenten befinden sich in Einstellungen – Mail, Kontakte, Kalender – Account hinzufügen …. Aus der Liste der Möglichen Anbieter (iCloud, Exchange usw.) wählt man den letzten Punkt (Andere):

Die Dialoge für CardDAV und CalDAV sind im Wesentlichen identisch. Durch unsere Vorbereitung reicht es, den Namen des Server (owncloud.dahlen.org, ohne https://), den Benutzernamen und das Paßwort einzutragen. Alles andere wird bei Wahl von Weiter oben rechts automatisch ermittelt.

Und das war es dann auch schon. Der neue Kalender taucht in der Kalender-App auf und nimmt Termine entgegen. Die Enrichtung eines Kontakt-Accounts geschieht völlig analog und wird hier nicht weiter beschrieben.

Mozilla Thunderbird mit Lightning Add-On

Mozillas Mail-Client Thunderbird wird durch das Kalender-AddOn Lightning in die Richtung eines Personal Information Assistents, wie z.B. Outlook gerückt. Als Vertreter der Open Source Idee war zu erwarten, daß eine Anbindung an offene Standards möglich ist.

Zumindest für den Kalender gilt das auch. Nach der Installation von Lightning und dem Neustart von Thunderbird wird über das Menü Datei – Neu – Kalender der Assistent für einen neuen Kalender gestartet. Zunächst entscheidet man sich für einen Kalender im Netzwerk.

Im folgenden Dialog wählt man das Kalender-Format, was hier CalDAV ist. Der Dialog erwartet auch die Adresse, unter welcher der Kalender erreichbar ist. An dieser Stelle ist es leider nicht ausreichend einfach nur die URL des ownCloud-Servers anzugeben. Vielmehr wird hier die vollständige URL zum persönlichen Kalender erwartet.

Diese URL kann in ownCloud ausgelesen werden. Dazu wählt man in der Web-Oberfläche von ownCloud den Kalender und klickt dann oben rechts auf das Kalender-Symbol. Ein weiterer Klick auf das Weltkugel-Symbol offenbart dann den CalDAV-Link.

Gemäß den Beispieldaten in diesem Artikel lautet die CalDAV-Adresse meines Default-Kalenders
https://owncloud.dahlen.org/remote.php/caldav/principals/cloudmaster/defaultcalendar. Diese trägt man in den offenen Dialog ein und bestätigt mit Weiter.

Im nächsten Dialog-Schritt hat man noch die Möglichkeit die Darstellung des Kalendars zu personalisieren und eine E-Mail-Adresse zuzuordnen. Außerdem werden in einem Popup die Anmeldedaten abgefragt.

Schließlich kommt es zum letzten Schritt des Dialogs, in welchem man einfach nur auf Fertigstellen klickt. Das war’s.

Damit hat mein Protokoll zur Einrichtung des eigenen, abgesicherten ownCloud-Servers auf dem Raspberry PI und die Anbindung an Clients sein vorläufiges Ende erreicht. Es ist nicht ausgeschlossen, daß Ergänzungen für weiter Clients wie Android oder Outlook folgen.

Ich hoffe, daß meine Ausführungen dem ein oder anderem zur Hilfe reichen und freue mich auf Feedback.

Der Beitrag Die eigene Cloud auf dem Raspberry PI (Teil 3: Anbindung von Clients) erschien zuerst auf dahlen.org.

Dazu wurde die Web-Server-Software lighttpd installiert und die Kommunikation via Transport Layer Security (TLS) abgesichert. Mein (fiktiver) Web-Server ist nun ausschließlich unter https://owncloud.dahlen.org/ erreichbar.

Installation von ownCloud

Wegen der begrenzten Ressourcen des Raspberry PI wurde nicht auf das ownCloud-Paket der Distribution (Raspian) zurückgegriffen, da hier eine Abhängigkeit zum Apache 2 http-Server besteht. Dennoch kann das Gros der notwendigen Software aus den Paketquellen der Distribution genommen werden, z.B. PHP5 mit seinen Modulen:
$ sudo apt-get install php5-gd php5-curl php5-sqlite php5-cgi

PHP5

Nach der Installation von PHP5 sind bei Bedarf zwei Einstellungen anzupassen, welche Auswirkung auf den gleichen Aspekt haben: Die maximale Größe für Uploads nach ownCloud. Es handelt sich um folgende Parameter, die sich in der Datei /etc/php5/cgi/php.ini befinden:

• upload_max_filesize
• post_max_size

Ich habe beide Werte auf 16M gesetzt. In erster Linie möchte ich ownCloud für Kalender- und Kontaktdaten nutzen, aber mit 16MB sind auch mal ein Bild oder ein größeres Dokument drin.

Vor dem Beginn der eigentlichen Installation von ownCloud muß PHP5 noch via FastCGI angebunden werden. Dazu ist auch ein Neustart des Web-Servers notwendig:
$ sudo lighttpd-enable-mod fastcgi-php
$ sudo service lighttpd force-reload

ownCloud

Jetzt kann das ownCloud-Setup-Skript direkt vom Anbieter gezogen werden. Abgelegt wird es im Document-Root des Web-Servers /var/www/:
$ sudo wget -O /var/www/setup-owncloud.php \
https://download.owncloud.com/download/community/setup-owncloud.php

Außerdem sind noch Berechtigungen anzupassen, damit ownCloud Daten nachladen und installieren kann:
$ sudo chown www-data:www-data /var/www /var/www/setup-owncloud.php

Schließlich wird das Skript im Browser aufgerufen, gemäß Beispiel lautet die URL zum Setup https://owncloud.dahlen.org/setup-owncloud.php.

Es erscheint der Begrüßungsbildschirm der Installation. Dieser kann ohne Änderungen per Next bestätigt werden.
Der Startbildschirm der OwnCloud Installation

Im folgenden Dialog kann man das Zielverzeichnis der Installation auswählen, relativ zum Document Root. Auch hier reicht ein Klick auf Next, auch wenn man mit owncloud nicht einverstanden ist (dazu später mehr):

Im Hintergrund lädt ownCloud nun die aktuelle Version vom ownCloud-Server und entpackt sie im vorhin gewählten Zielverzeichnis. Je nach Internet-Anbindung kann dieser Schritt etwas dauern. Sein Abschluß wird durch den dritten Dialog berichtet, den man wieder über Next bestätigt.

Schließlich wird nach den Anmeldedaten des ersten Benutzers gefragt. Dieser wird automatisch zum Administrator. Nachdem man Benutzernamen und Passwort eingetragen hat, kann die Installation über die entsprechende Schaltfläche abgeschlossen werden.

Im letzten Dialog war ein roter Textabschnitt zu sehen. Sinngemäß wird dadrin darauf hingewiesen, daß alle Daten, die man ownCloud anvertraut ohne jede Zugangskontrolle abrufbar sind. Darum wird lighttpd (und damit ownCloud) jetzt erstmal runtergefahren:
$ sudo service lighttpd stop

Nun zu Ursache und Beseitigung der Warnung: ownCloud speichert die meisten seiner Daten in einem Unterverzeichnis namens data. Dieses Verzeichnis wird in der Regel über eine Datei namens .htaccess vor direkten Zugriffen aus dem Internet geschützt. Nur indirekt, über die ownCloud-Software und das dort integrierte Rechtemanagement soll der Zugriff erfolgen.

lighttpd bietet aber keine Unterstützung für die Anweisungen in der .htaccess-Datei, darum besteht auch kein Zugriffsschutz. Zwar bietet auch lighttpd ähnliche Mechanismen, aber ich wähle einen anderen Weg.

Als erstes ersetze ich /var/www/owncloud durch /var/www, weil ich keine weitere Anwendung auf dem Raspberry PI laufen lassen werde.
$ sudo mv /var/www /var/www.off
$ sudo mv /var/www.off/owncloud /var/www
$ sudo rm -r /var/www.off

Dann verschiebe ich das data-Verzeichnis aus dem Bereich des Webservers.
$ sudo mkdir -p /srv/owncloud
$ sudo chown www-data:www-data /srv/owncloud
$ sudo mv /var/www/data /srv/owncloud

Den neuen Ort des data-Verzeichnisses müssen wir ownCloud bekannt machen, dazu wird der alte Wert in der Konfigurationsdatei /var/www/config/config.php geändert.

Aus
'datadirectory' => '/var/www/owncloud/data',
wird also
'datadirectory' => '/srv/owncloud/data',

Zeit lighttpd (und damit owncloud) neu zu starten.
$ sudo service lighttpd start

Damit ist die Installation von ownCloud abgeschlossen. Sie steht (nur lt. meinem Beispiel) jetzt direkt unter https://owncloud.dahlen.org/ zur Verfügung.

Im nächsten Teil gehe ich auf die Anbindung von Kontakten und Kalender via iOS und anderen Clients ein.

Der Beitrag Die eigene Cloud auf dem Raspberry PI (Teil 2: ownCloud Installation) erschien zuerst auf dahlen.org.

Jetzt habe ich auch endlich eine Verwendung für die Himbeere 3,1415 gefunden: Meine eigene, kleine Cloud – mein Wölkchen also.

Motivation

Zunächst möchte ich noch meine Zielsetzung schärfen: Trotz der Auswahl von ownCloud als Server-Software geht es mir primär nicht um die Einrichtung einer Dateiablage oder ähnlichem. Vielmehr steht der weltweite Zugriff auf Kontakte und Kalenderdaten via Browser oder mobilem Endgerät im Vordergrund. Die dafür notwendigen Protokolle CalDAV und CardDAV sind in ownCloud integriert und die Installation der ownCloud-Software ist um ein Vielfaches einfacher als der dedizierten Varianten (z.B. DaviCAL).

Zwar kann man alle Leistungen kostenlos bei Google bekommen, doch liegen die persönlichen Daten dann eben bei Google. Natürlich muß das nicht zwangsläufig zu Mißbrauch führen (Don’t be evil, sagt Google). Aber ab und an wird Google sicherlich mal einen Blick auf die Daten werden, um die Benutzererfahrung zu verbessern. Anders wären Dienste wie Google Now gar nicht möglich.

Hard- und Software-Basis

Meine Beschreibung orientiert sich dabei an den Möglichkeiten eines Raspberry Pi, Modell B, 256MB Variante. Als Betriebssystem kommt die Debian Wheezy basierte Raspbian-Distribution zum Einsatz. Wegen der begrenzten Ressourcen wird nicht auf das ownCloud-Paket der Distribution zurückgegriffen, da hier eine Abhängigkeit zum Apache 2 http-Server besteht. Stattdessen wird auf LigHTTPd zurückgegriffen:
$ sudo apt-get install lighttpd

Damit ist der Webserver bereits installiert und liefert sein Platzhalter-Seite über HTTP aus. Allerdings handelt es sich um eine unverschlüsselte Verbindung. Die später notwendigen Anmelde-, meine Kontakt- und Kalenderdaten sollen so nicht verschickt werden. Vielmehr muß eine Absicherung über TLS, besser bekannt als SSL.

Absicherung der Kommunikation

Ich will erreichen, daß die Kommunikation mit den Clients (iPhone, Browser, etc.) verschlüsselt abläuft. Dazu würde theoretisch ein einfaches, selbst-signiertes Zertifikat reichen. Allerdings würden dann unbedarfte Anwender mit Dialogen konfrontiert werden, in denen Begriffe wie Gefahr, Sicherheitshinweis und nicht empfohlen vorkommen.

Der Grund ist, daß ein selbst-signiertes Zertifikat zwar für den Aufbau einer verschlüsselten Verbindung ausreicht, aber die Identität des Servers nicht bestätigt. Dies geht nur über eine Zertifikatskette, welche ausschließlich aus dem Client bekannten Certification Authorities (CA) besteht. Das heißt: Eine dem Client bekannte und als vertrauenswürdig eingestufte CA hat die Validität meines Server-Zertifikats mit ihrer Signatur bestätigt.

In meiner Beschreibung verwende ich als Hostnamen owncloud.dahlen.org und einen Benutzer namens cloudmaster. Weder die Domäne, noch der Benutzer existieren in der Realität.

Leider verlangen die im Browser vorinstallierten CAs teilweise horrende Gebühren für ihre Signatur. Doch es gibt kostenlose Ausnahmen, welche für meinen Anwendungsfall auch völlig ausreichend sind. Eine davon ist die Firma StartSSL.

Wichtig: Für die Erstellung eines durch StartSSL-signierten Zertifikats wird die eigene Domäne benötigt (wie dahlen.org). Ohne diese Domäne bleibt euch nur die Möglichkeit eines selbst-signierten Zertifikats. Auch muß der ownCloud-Host über einen Fully Qualified Domain Name (FQDN) erreichbar sein, also über einen Namen wie owncloud.dahlen.org.

Das erforderliche Software (OpenSSL) sollte bereits bei der Installation von Raspian mitgekommen sein, ansonsten schadet eine erneuter Versuch auch nicht.
$ sudo apt-get install openssl

Schlüssel und Zertifikate

Zunächst erstellt man einen privaten Schlüssel, mit welchem das spätere Server-Zertifikat abgesichert ist. Auf die Möglichkeit, diesen private key mit einem weiteren Kennwort abzusichern wird bewußt verzichtet:
$ openssl genrsa -out server.key 2048

Dann erstellt man einen Certificate Signing Request (CSR), eigentlich ist das der öffentliche Teil des privaten Schlüssels, welcher zur Signatur bei der CA eingereicht wird (oder eben selbst signiert wird):
$ openssl req -new -key server.key -out server.csr

Die gestellten Fragen sind gemäß der eigenen Umgebung anzugeben. Wichtig dabei: Das Feld Common Name (CN) muß den Namen und die Domäne (Fully Qualified Domain Name, FQDN) des eigenen ownCloud-Servers beinhalten. Der vollständige Dialog kann also wie folgt aussehen:

Country Name (2 letter code) [AU]:DE
State or Province Name (full name) [Some-State]:Nordrhein-Westfalen
Locality Name (eg, city) []:Toenisvorst
Organization Name (eg, company) [Internet Widgits Pty Ltd]:dahlen.org
Organizational Unit Name (eg, section) []:
Common Name (e.g. server FQDN or YOUR name) []:owncloud.dahlen.org
Email Address []:cloudmaster@dahlen.org

Der erzeugte CSR wird jetzt bei StartSSL zur Signatur eingereicht. Diesen Prozeß muß ich glücklicherweise nicht beschreiben, denn das haben die Kollegen auf heise Security bereits getan. Im Ergebnis wird das signierte Zertifikat angezeigt, welches man kopiert und eine Datei namens server.crt speichert. Es ist dabei enorm wichtig, daß der Inhalt der Datei nicht durch Umbrüche oder ähnliches verändert wird.

Drei Dateien befinden sich nun im aktuellen Verzeichnis:

• server.key – der private Schüssel zum Zertifikat
• server.csr – der öffentliche, unsignierte Schlüssel
• server.crt – das öffentliche, signierte und damit „zertifizierte“ Schlüssel

Der CSR wird nicht mehr benötigt und kann gelöscht werden. Eine weitere Datei muss noch besorgt werden, um die Kette der Zertifikat-Signaturen zu schliessen: Das Intermediate Certificate von StartSSL. Diese lässt sich direkt abrufen:
$ wget -O ca.pem http://www.startssl.com/certs/sub.class1.server.ca.pem

Damit ist die Zertifikatskette geschlossen und die Gültigkeit des eigenen Server-Zertifikats kann überprüft werden:
$ openssl verify -CAfile ca.pem server.crt
Erwartetes Ergebnis:

server.crt: OK

Als letzten Schritt der Zertifikat-Vorbereitung müssen jetzt noch der private Schlüssel und das Zertifikat in eine Datei überführt werden.
$ cat server.key server.crt > server.pem

Installation in lighttpd

Nun ist es Zeit, die generierten Teile der SSL-Infrastruktur dem Webserver bekannt zu machen:
$ sudo cp server.pem /etc/lighttpd/
$ sudo cp ca.pem /etc/lighttpd/

Außerdem muß die Konfiguration unter /etc/lighttpd/lighttpd.conf angepasst werden. Die Änderungen beginnen mit der Änderung der Port-Nummer (ca. ab Zeile 15). Aus
server.port = 80
wird
server.port = 443
ssl.engine = "enable"
ssl.pemfile = "/etc/lighttpd/server.pem"
ssl.ca-file = "/etc/lighttpd/ca.pem"

Letztendlich wird damit der Zugriff über einfaches, unverschlüsseltes HTTP abgeschaltet. Durch einen Neustart wird dies aktiviert:
$ sudo service lighttpd restart

Danach ist der Dienst nur noch über HTTPS auf Port 443 zu erreichen, also https://owncloud.dahlen.org/.

Im nächsten Teil beschreibe ich, wie jetzt ownCloud ins Spiel kommt.

Der Beitrag Die eigene Cloud auf dem Raspberry PI (Teil 1: lighttpd und SSL) erschien zuerst auf dahlen.org.