Nachdem ich erfreulich viele Rückmeldungen auf meinen Artikel Empfehlungen für Raumklimaüberwachung erwünscht erhielt, habe ich mich für die Verwendung von FHEM [1], JeeLink [2] und LaCrosse-Sensoren [3] entschieden. Die Einrichtung folgt dem Artikel [4] von MeinTechBlog.DE.
An dieser Stelle werden die minimal notwendigen Befehle für meine Umgebung dokumentiert. Links zu weiterführenden Informationen finden sich am Ende des Beitrags.
JeeLink in den Paringmodus schalten: set <JeeLinkName> LaCrossePairForSec <seconds>
Batterien in LaCrosse-Sensor einlegen und Pairing abwarten
Sensor und Log umbenennen: rename <AlterName> <NeuerName>
Der OpenStack Summit 2018 fand vom 13.11.-15.11. im CityCube Berlin statt. Es war der erste Summit in Deutschland und ich nutzte die Gelegenheit, den Summit erstmals zu besuchen. Hier folgt nun ein Erfahrungsbericht.
Motivation
Privat interessiere ich mich bereits seit vielen Jahren für diverse Themen rund um Open Source Hard- und Software. Beruflich bin ich aktuell in ein Projekt involviert, welches sich inhaltlich mit der Speicher-Lösung Ceph [1], [2] und der Cloud-Umgebung OpenStack [3], [4] beschäftigt.
Bei beiden handelt es sich um äußerst komplexe Open Source Technologien und die Einstiegshürde liegt entsprechend hoch. Dies liegt unter anderem daran, dass man hier kein fertiges Produkt bekommt, sondern eher ein Framework, welches sich flexibel für diverse Anwendungsfälle eignet.
Mit dem Summit bot sich eine gute Gelegenheit, die Community kennenzulernen, Vorträge über Fallstudien und Neuentwicklungen zu hören sowie an Workshops zur weiteren Entwicklung teilzunehmen.
Der Ceph Day Berlin
Im Vorfeld des OpenStack Summits fand ebenfalls im CityCube Berlin der Ceph Day [5] statt. Eröffnet wurde dieser von Sage Weil, welcher einen Überblick über den aktuellen Entwicklungsstand und neue Funktionen im kommenden Release gab.
Es folgten Vorträge über die neuen Management- und Monitoring-Funktionalitäten des überarbeiteten Dashboards, eine Fallstudie vom MeerKAT Radio-Teleskop und noch einige mehr. Begleitend wurden die Teilnehmer mit Kaffee, Kaltgetränken und kleinen Snacks versorgt.
Besonders gefallen haben mir die Vorträge über den Entwicklungsstand, die Neuerungen und wie man mit Upmap das Backfilling bzw. Rebalancing in den Griff bekommt. Darüber hinaus habe ich die Gelegenheit genutzt, in den Pausen mit anderen Teilnehmern, über deren Anwendungsfälle und Erfahrungen mit Ceph zu sprechen. Auch in diesen Gesprächen gab es sowohl neue Einblicke, als auch Bestätigung für Dinge, die ich mir bisher aus der Literatur angelesen und in einem kleinen Proof of Concept erfahren habe.
Alles in allem war es ein guter Tag, welcher Lust auf die weiteren Tage machte.
Der OpenStack Summit
Am Dienstag startete dann der OpenStack Summit mit einer Reihe von Keynotes. Erste Erkenntnis: Da es auf diesem Summit nicht nur um OpenStack geht, wird sich die Veranstaltung einen neuen Namen geben und sich zukünftig Open Infrastructure Summit nennen.
Ganz grob lässt sich der Summit in das Vortragsprogramm, den Marktplatz und die Flurgespräche unterteilen.
Das Vortragsprogramm
Es gab ein reichhaltiges und abwechslungsreiches Vortragsprogramm [6]. Aufgrund des internationalen Publikums wurden sämtliche Vorträge in englischer Sprache gehalten.
Die Vorträge ließen sich erneut in Fallstudien, Projektvorstellungen, Neuigkeiten und Sponsoren-Vorträge unterteilen. Es gab ein breites Spektrum sowohl an Themen, als auch an deren Qualität.
Bei den vielen parallelen Strängen und interessanten Themen war es unmöglich, alle interessanten Vorträge zu besuchen. Zum Glück wurden sehr viele Vorträge aufgezeichnet, so dass man sie sich auch im Nachgang noch auf Video ansehen kann [7].
Eine interessante Erfahrung für mich war die Teilnahme an den Arbeitstreffen einiger Gruppen, welche sich unter anderem um die Weiterentwicklung der verschiedenen Deployment-Werkzeuge für OpenStack drehten. Die Teilnehmer hielten die Agenda in öffentlich zugänglichen Etherpads [8] fest und sammelten in diesen sowohl Fragen, Vorschläge als auch Antworten zu den gestellten Fragen.
Insgesamt wirkten diese Treffen zwar nicht sehr effizient, doch habe ich auch keine Idee, wie man ein Treffen mit so vielen Teilnehmern effizienter gestalten kann. Ich hoffe nun auf die Ergebnisse, da diese einem Neueinsteiger die Wahl eines geeigneten Deployment-Tools entscheidend vereinfachen könnten.
Der Marktplatz
Als Marktplatz wurde die Ausstellerfläche der Sponsoren im CityCube bezeichnet. Hier ergab sich die Gelegenheit, mit den Firmen in Kontakt zu treten, welche aktiv an der Entwicklung von Ceph und OpenStack beteiligt sind und ergänzende kommerzielle Lösungen und Support für diese anbieten.
Als SysAdmin habe ich mit großer Freude zur Kenntnis genommen, dass hier vor allem Techniker vor Ort waren und keine Vertriebsmitarbeiter. So konnte man sich darüber austauschen, was ein Produkt wirklich kann, wie es funktioniert und was davon zu erwarten ist. Und sind wir mal ehrlich, einen Preis dafür kann man immer noch anfragen. Dies gelingt in den meisten Fällen deutlich einfacher, als einen technisch versierten Ansprechpartner zu finden.
Selbstverständlich konnte man hier auch das ein oder andere Souvenir in Form eines T-Shirts, einer Tasse oder eines Huts abstauben. So war auch für Souvenir-Jäger gesorgt.
Flurgespräche
Flurgespräche nenne ich die vielen Gelegenheiten, die sich boten, um mit Menschen aus der Community Gespräche über verschiedenste Themen zu führen. Häufig sind diese informellen Gespräche genauso informativ, wenn nicht sogar noch erkenntnisreicher, als so mancher Vortrag.
Darüber hinaus besitzen sie selbstverständlich auch einen gewissen Unterhaltungswert. Am Dienstag Abend saß ich mit einem US-Amerikaner und einem Russen zusammen. Wir tauschten uns über kulturelle Unterschiede und Herangehensweisen beim Betrieb von Rechenzentren aus. Und wir hatten eine Menge Spaß dabei.
Grundsätzlich besitzen Ceph und OpenStack eine recht offene und freundliche Community. Man konnte schnell Anschluss finden und auch für die vermeintlich naiven Fragen eines Einsteigers nahm man sich Zeit, um diese ausführlich zu diskutieren.
Mein größter Dank gilt der Teilnehmerin oder dem Teilnehmer, welche/r mein verlorenes Portemonnaie gefunden und abgegeben hat. VIELEN DANK an die bzw. den Unbekannte/n!
Fazit
Ich persönlich ziehe ein gemischtes Fazit. Der Ceph Day sowie der OpenStack Summit waren toll. Sowohl das offizielle Programm als auch die Menschen waren spitze. Es war eine tolle Erfahrung, dabei zu sein. Ich hoffe, dass sich mir diese Möglichkeit noch einmal bietet.
Bezüglich Ceph und OpenStack habe ich viele Anwendungsszenarien kennengelernt und einen guten Einblick in diverse Projekte gewonnen. Deutlich wurde dabei jedoch auch, dass OpenStack noch lange nicht fertig ist und es vermutlich auch nie sein wird. Die Entwicklung wird in alle möglichen Richtungen weitergehen. Mit dabei sind eine Menge Haken, Ösen und Dinge, die einfach noch nicht ausgereift sind.
Doch muss man sich von diesen lebendigen Projekten nicht abschrecken lassen. Die Fallstudien bspw. des CERN, des MeerKAT oder des Human Brain Projects zeigen, dass man diese Projekte mit den richtigen Voraussetzungen sehr erfolgreich betreiben kann.
Was wir in unserer Einrichtung daraus machen, wird die Zukunft zeigen.
Unter VMware vSphere lassen sich neue Festplatten im laufenden Betrieb zu einer virtuellen Maschine hinzufügen. Damit man diese neuen Festplatten im Gastbetriebssystem auch verwenden kann, müssen sie dem Kernel jedoch noch bekannt gemacht werden. Wie dies ohne Neustart geht, möchte ich in diesem Artikel dokumentieren.
Um die neuen Festplatten zu erkennen, muss man den Kernel veranlassen die vorhanden Speicher-Adapter (SATA/SAS/SCSI) nach neuen Geräten abzusuchen. Leider habe ich dafür kein einfaches Kommando gefunden, weswegen ich folgendes Verfahren anwende.
Unter /sys/class/scsi_host findet man die dem Kernel bekannten Speicher-Adapter des Systems:
$ ls /sys/class/scsi_host
host0 host1 host2
Um einen Speicher-Adapter nach neuen Geräten abzusuchen, führt man folgendes Kommando auf dem entsprechenden Adapter aus:
# echo '- - -' > /sys/class/scsi_host/host0/scan
Ist man sich nicht sicher, an welchen Speicher-Adapter die neuen Festplatten angeschlossen wurden, können alle Adapter mit der folgenden kleinen Schleife abgesucht werden:
# for f in /sys/class/scsi_host/host*; do echo '- - -' > $f/scan; done
Anschließend tauchen die neuen Festplatten in der Ausgabe von parted -l oder fdisk -l auf und können wie gewohnt formatiert und genutzt werden.
Eines der beliebtesten Hobby-, Wochenend- bzw. Smart-Home-Projekte scheint die Überwachung von Temperatur und Luftfeuchtigkeit im In- und Außenbereich zu sein. Eine Internetrecherche zu diesem Thema liefert eine schier überwältigende Anzahl an Treffern zurück.
Auch ich habe mich in der Vergangenheit bereits mit diesem Thema befasst (siehe Beitrag „Wer viel misst, misst viel Mist“). Leider habe ich mit meinen bisherigen Versuchen noch kein zufriedenstellendes Ergebnis erreicht und bei den zahllosen Lösungsmöglichkeiten, die ich im Internet gefunden habe, den Überblick verloren. Daher möchte ich im Folgenden meine Anforderungen beschreiben und euch um eure Mithilfe in Form von Empfehlungen für mögliche Lösungen bitten.
Zielsetzung
In jedem Raum eines Hauses sollen Messstationen mit Sensoren zur Messung von relativer Luftfeuchtigkeit und Temperatur platziert werden, welche die gemessenen Werte über eine Funkverbindung an ein zentrales Gerät zur weiteren Verarbeitung übertragen. Als zentrale Datenverarbeitungsstelle soll ein Raspberry Pi dienen, welcher die Daten speichert und auf einer Webseite visualisiert.
Das ganze System soll zur Umsetzung und Überwachung eines Lüftungskonzepts dienen.
Beschreibung der Anforderungen
Um die beschriebene Zielsetzung zu erreichen, soll jeder Sensor bzw. jede Messstation folgende Anforderungen erfüllen. Optionale Anforderungen werden dabei als solche gekennzeichnet.
Die Messstation soll frei im Raum platziert werden können.
Die Stromversorgung erfolgt über Batterie, Akku oder Powerbank. Ein Anschluss an eine Steckdose ist nicht erforderlich.
Die Messstationen übertragen die Messwerte über eine Funkverbindung (z.B. WLAN, Bluetooth, 433 MHz, etc.) an eine zentrale Empfangsstation.
Die Empfangsstation muss an einem Raspberry Pi betrieben werden können, da dieser die Messdaten weiterverarbeiten soll.
Die Verwendung freier und offener Standards/Protokolle wird bevorzugt.
Messbereich für die Temperatur mindestens 0-70 °C bei einer Genauigkeit von +/- 0,5 °C.
Messbereich für die Luftfeuchtigkeit mindestens 0-100% relative Luftfeuchtigkeit (RH) bei einer Genauigkeit von +/- 5% RH.
Fühler für Temperatur und Luftfeuchtigkeit können in einem gemeinsamen oder in getrennten Sensoren untergebracht sein.
Frei konfigurierbares Messintervall von 10-86400s.
Frei wählbare Anzahl Messstationen. Es müssen jedoch mindestens 32 Sensoren an die zentrale Empfangsstation angebunden werden können.
Unterstützung von Linux zur Entwicklung und Programmierung der Lösung.
Optionale Anforderungen
Die Messstationen können mit einem Display zum Ablesen der Messwerte ausgestattet werden.
Die Displays verfügen über eine per Knopfdruck zuschaltbare Displaybeleuchtung.
Ein IP-basiertes Heimnetzwerk (IPv4 und IPv6) mit WLAN (2,4 und 5 GHz) ist vorhanden. Grundlegende Programmierkenntnisse in C und Python ebenso. Andere Sprachen stellen kein Ausschlusskriterium dar. Die grundlegende Fähigkeit zur Benutzung von Multimeter und Lötkolben ist ebenfalls vorhanden. Jedoch arbeite ich hier eher auf dem Niveau eines Grobschmieds denn eines Chirurgen. Ich bin also nicht traurig, wenn hier nur wenig gebastelt werden muss.
Die Lösung
Tja, ich habe noch keine. Falls ihr jedoch eine Lösung kennt oder sogar selbst umgesetzt habt, welche die oben genannten Anforderungen erfüllt, freue ich mich sehr, wenn ihr in den Kommentaren zu diesem Beitrag darüber berichten mögt und eure Empfehlungen und Erfahrungen hier teilt.
Gnuplot (Eigenschreibweise: gnuplot) ist ein skript– bzw. kommandozeilengesteuertes Computerprogramm zur grafischen Darstellung von Messdaten und mathematischen Funktionen (Funktionenplotter). Das Projekt Gnuplot wird seit 1986 kontinuierlich von einem internationalen Team ehrenamtlicher Entwickler vorangetrieben. Der Quellcode wird seit 2000 über SourceForge verwaltet.
Da die auf der offiziellen Projekt-Homepage verlinkten deutschsprachigen Tutorials allesamt auf eine Fehlerseite (404 – Page Not Found) führen, möchte ich hier ein eigenes Tutorial in deutscher Sprache anbieten. Darin werde ich zeigen, wie Messdaten aus Text- bzw. CSV-Dateien grafisch dargestellt und in den Formaten EPS, PNG und SVG ausgegeben werden können. Das Tutorial schließt mit einem Beispiel zur Histogramm-Erstellung.
Voraussetzungen
Um die Inhalte dieses Tutorials nachvollziehen zu können, benötigt Ihr eine gnuplot-Installation auf dem eigenen Rechner.
Benutzer von Linux können gnuplot für gewöhnlich über die Paketverwaltung ihrer Distribution installieren. Benutzer von Windows und anderer Betriebssysteme können unter gnuplot download nachschauen.
Die in diesem Tutorial verwendeten Beispiel-Dateien können direkt von dieser Seite heruntergeladen werden, um die Beispiele nachzuvollziehen.
Beispiel 1: Darstellung der Energiekostenentwicklung
Um dieses Beispiel nachvollziehen zu können, wird folgende Datei benötigt:
Das obige Listing zeigt den Inhalt der Datei Energiepreise_Heizoel_Strom.csv.
Die Datei enthält zu Beginn einige Kommentarzeilen (beginnend mit #) mit beschreibendem Text. Darunter befinden sich die drei Spalten Berichtsjahr, leichtes Heizöl und Strom, welche durch ein Semikolon voneinander getrennt sind. Diese Werte sollen nun in einem anschaulichen Diagramm dargestellt werden.
Daten mit gnuplot grafisch darstellen
Um die Daten aus obiger Datei grafisch darstellen zu können, sind zuerst folgende Schritte auszuführen:
Öffne ein Terminal
Wechsle in das Verzeichnis, in dem die Datei Energiepreise_Heizoel_Strom.csv liegt
Starte gnuplot durch Eingabe des entsprechenden Kommandos
Bildschirmfoto vom Verzeichniswechsel und Start von gnuplot
Wir befinden uns jetzt im interaktiven Eingabemodus. Durch Eingabe der folgenden Befehle erhalten wir eine erste grafische Darstellung unserer Daten. Die gezeigten Befehle werden im Einzelnen nach der folgenden Abbildung erläutert.
Erster Plot des Diagramms
gnuplot> set datafile separator ";"
gnuplot> set autoscale
gnuplot> set xlabel "Jahr"
gnuplot> set ylabel "Preis in Cent"
gnuplot> plot "Energiepreise_Heizoel_Strom.csv" using 1:2 title "leichtes Heiz\U+FFC3\U+FFB6l Cent/l", "Energiepreise_Heizoel_Strom.csv" using 1:3 title "elektrischer Strom Cent/kWh"
gnuplot>
Das obige Listing stellt die Befehle zum Plot des Diagramms im Bild darüber dar.
In der ersten Zeile wird das verwendete Trennzeichen angegeben. In diesem Fall handelt es sich dabei um das Semikolon, welches die einzelnen Spalten in unserer CSV-Datei voneinander trennt.
Zeile 2 gibt an, dass sich Gnuplot selbst um eine sinnvolle Skalierung der Achsen im Diagramm kümmern soll. Wie man die Skalierung manuell vorgibt, wird in einem späteren Beispiel gezeigt. Mit `set xlabel/ylabel` wird die Achsenbeschriftung festgelegt.
In der letzten Zeile wird schließlich der Befehl zum Zeichnen des Diagramms eingegeben. Eingeleitet wird die Zeile vom Kommando „plot“, gefolgt von der Angabe des Dateinamens. Mit „using 1:2“ wird angegeben, dass Gnuplot die Spalten 1 und 2 aus der Datei darstellen soll. Dabei wird der erste Wert an der X-Achse und der zweite Wert an der Y-Achse abgetragen. Mit dem Schlüsselwort „title“ kann noch eine Graphenbeschriftung für die Legende vergeben werden. Nach dem Komma wird die Angabe wiederholt. Hier sollen die Daten der ersten und dritten Spalte aus der Datei visualisiert werden. Man könnte an dieser Stelle auch eine andere Datei angeben, aus der man Werte im Diagramm darstellen möchte. Dazu ist lediglich der entsprechende Dateiname zu ändern.
Selbstverständlich kann auch die Darstellungsform der Graphen beeinflusst werden. Das folgende Beispiel zeigt, wie man den Graphen für leichtes Heizöl als Linie und den für elektrischen Strom als Linie mit Punkten darstellt.
gnuplot> plot "Energiepreise_Heizoel_Strom.csv" using 1:2 with lines title "leichtes Heizl Cent/l", "Energiepreise_Heizoel_Strom.csv" using 1:3 with linespoints title "elektrischer Strom Cent/kWh"
Diagramm mit Linie und Linienpunkten
Wie man im Listing sieht, kann hinter dem Schlüsselwort „with“ der zu verwendende Linientyp angegeben werden. Um zu sehen, welche Darstellungsformen möglich sind, kann man die eingebaute Hilfe aufrufen, indem man z.B. `help with` eingibt.
Gnuplot-Hilfe für die Funktion „with“
Die Hilfe in Gnuplot ist sehr umfangreich und bietet neben umfassenden Informationen zu allen Kommandos, Funktionen und Schlüsselwörtern auch einige schöne Beispiele. An ihr erkennt man in meinen Augen den hohen Reifegrad dieses Programms. Eine derart gute Dokumentation sucht man bei vielen anderen Projekten leider noch vergebens.
Die Entwickler von Gnuplot haben auch an die Tippmuffel unter uns gedacht. So lässt sich die Schreibweise etlicher Funktionen in Gnuplot abkürzen. Die beiden Zeilen im folgenden Listing sind äquivalent und führen zur gleichen Ausgabe.
gnuplot> plot "Energiepreise_Heizoel_Strom.csv" using 1:2 with lines title "leichtes Heizl Cent/l", "Energiepreise_Heizoel_Strom.csv" using 1:3 with linespoints title "elektrischer Strom Cent/kWh"
gnuplot> plot "Energiepreise_Heizoel_Strom.csv" u 1:2 w lines t "leichtes Heizl Cent/l", "Energiepreise_Heizoel_Strom.csv" u 1:3 w lines t "elektrischer Strom Cent/kWh"
Einstellungen speichern
Um nun nicht jedes Mal, wenn man Gnuplot startet, alle Einstellungen erneut eintippen zu müssen, können diese gespeichert werden.
gnuplot> save "Energiepreise_Heizoel_Strom.gp"
Diese Einstellungen können nun in einer neuen Gnuplot-Konsole mit load "Energiepreise_Heizoel_Strom.gp"geladen werden. Das Diagramm wird dabei automatisch mit den gespeicherten Einstellungen gezeichnet.
Ausgabe in PNG, SVG und EPS
Gnuplot bietet die Möglichkeit, Diagramme in verschiedensten Formaten auszugeben. Dazu wird in der interaktiven Gnuplot-Konsole das entsprechende Ausgabe-Terminal definiert und anschließend das Diagramm gezeichnet. Das folgende Listing zeigt den Code für Ausgabe des obigen Diagramms als PNG, SVG und EPS. Die Ergebnisse der Ausgabe befinden sich im aktuellen Arbeitsverzeichnis auf eurem Endgerät.
gnuplot> set terminal pngcairo size 640,480 enhanced font 'Verdana,10'
Terminal type set to 'pngcairo'
Options are ' background "#ffffff" enhanced font "Verdana,10" fontscale 1.0 size 640, 480 '
gnuplot> set output 'Energiepreise.png'
gnuplot> replot
gnuplot> set terminal svg size 640,480 fname 'Verdana' fsize 10
Terminal type set to 'svg'
Options are 'size 640,480 fixed enhanced fname 'Verdana' fsize 10 butt dashlength 1.0 '
gnuplot> set output 'Energiepreise.svg'
gnuplot> replot
gnuplot> set terminal postscript eps size 3.2,2.4 enhanced color font 'Helvetica,20' linewidth 2
Terminal type set to 'postscript'
Options are 'eps enhanced defaultplex \
leveldefault color colortext \
dashlength 1.0 linewidth 2.0 butt noclip \
nobackground \
palfuncparam 2000,0.003 \
size 3.20in, 2.40in "Helvetica" 20 fontscale 1.0 '
gnuplot> set output 'Energiepreise.eps'
gnuplot> replot
gnuplot>
Die Größenangaben (size) können selbstverständlich den eigenen Bedürfnissen angepasst werden.
Ist die Postscript-Ausgabe für ein Dokument bestimmt, welches in schwarz-weiß gedruckt werden soll, empfiehlt sich folgende Terminal-Konfiguration. Gnuplot bereitet dabei die Darstellung der Graphen für den Schwarz-Weiß-Druck auf.
gnuplot> set terminal postscript eps size 3.2,2.4 monochrome font 'Helvetica,20' linewidth 2
Terminal type set to 'postscript'
Options are 'eps enhanced defaultplex \
leveldefault monochrome colortext \
dashlength 1.0 linewidth 2.0 butt noclip \
nobackground \
palfuncparam 2000,0.003 \
size 3.20in, 2.40in "Helvetica" 20 fontscale 1.0 '
gnuplot> set output 'Energiepreise_sw.eps'gnuplot> replot
Beispiel 2: Darstellung einer Messreihe mit Zeitabtrag an der X-Achse
Dieses Beispiel setzt den Schwerpunkt bei der Abtragung von Datum und Uhrzeit an der X-Achse mit entsprechender Formatierung. Daneben wird gezeigt, wie man selbst die anzuzeigenden Intervalle an X- und Y-Achse konfiguriert.
Um dieses Beispiel nachvollziehen zu können, wird folgende Datei benötigt:
In der Datei befinden sich Messwerte von drei DHT22-Sensoren, welche Temperatur und Luftfeuchtigkeit messen können. Die Datei besteht aus insgesamt 3983 Zeilen und besitzt folgenden Aufbau:
$ head -n6 dht22data.csv
#Date,Temp1,Humd1,Temp2,Humd2,Temp3,Humd3
2018-06-04T17:57:26,23.80,61.50,23.90,51.50,22.70,52.80
2018-06-04T18:02:26,23.80,61.60,23.90,51.50,22.70,52.80
2018-06-04T18:07:27,23.80,61.50,23.90,51.50,22.70,52.80
2018-06-04T18:12:27,23.80,61.60,23.90,51.50,22.70,52.80
2018-06-04T18:17:28,23.80,61.30,23.90,51.50,22.70,52.80
In der ersten Spalte findet sich ein Zeitstempel, gefolgt von den jeweiligen Messwerten der drei Sensoren. Als Spaltentrennzeichen wird in dieser Datei das Komma verwendet. Als Dezimaltrennzeichen findet der Punkt Verwendung.
Im zu erstellenden Diagramm sollen Datum und Uhrzeit auf der X-Achse abgetragen werden. Auf der Y-Achse sollen die Temperaturwerte der drei Sensoren dargestellt werden. Die Luftfeuchtigkeit bleibt in diesem Beispiel unberücksichtigt.
set datafile separator ","
set xdata time
set timefmt "%Y-%m-%dT%H:%M:%S"
set xrange [ "2018-06-04T17:57:26" : "2018-07-11T12:44:50" ]
set yrange [ 18:25 ]
set format x "%m-%d\n%H:%M"
plot "dht22data.csv" u 1:2 title "Sensor 1", "dht22data.csv" u 1:4 title "Sensor 2", "dht22data.csv" u 1:6 title "Sensor 3"
Im obigen Listing wird zuerst das Spaltentrennzeichen definiert. In der zweiten Zeile wird Gnuplot mitgeteilt, dass auf der X-Achse Datum und Zeit abgetragen werden soll. Hinweis: Intern rechnet Gnuplot ausschließlich in Sekunden.
Zeile 3 teilt Gnuplot mit, in welchem Format Datum und Uhrzeit in der Datei vorliegen. In Zeile 4 werden die Grenzen definiert. Für die Angabe wurde der erste und der letzte Zeitstempel aus der Beispieldatei verwendet.
Mit set yrange [ 18:25 ] wird ein Intervall für die Y-Achse definiert, welches für eine Temperaturkurve sinnvoll erscheint. Das Kommando set format x "%m-%d\n%H:%M" gibt an, wie Datum und Uhrzeit an der X-Achse dargestellt werden sollen. In diesem Beispiel sollen erst Monat und Tag und nach einem Zeilenumbruch Stunde und Minute dargestellt werden. Der letzte Befehl zeichnet dann das folgende Diagramm.
Darstellung der Messwerte für die Temperatur
In der grafischen Darstellung ist auf den ersten Blick zu erkennen, dass es eine Lücke in der Messreihe gibt. Hierbei handelt es sich nicht um einen Fehler. Es fand in dem Zeitraum tatsächlich keine Messung statt. Zoomt man nun in das Diagramm hinein, kann man sehen, dass die Werte an der X-Achse automatisch skaliert werden.
Zoomansicht 1
Zoomansicht 2
Beispiel 3: Zweite Y-Achse
Im vorangegangenen Beispiel wurden nur die Temperaturwerte aus der Beispieldatei betrachtet. In diesem Beispiel soll die von einem Sensor gemessene Temperatur an der Y-Achse (links) und die Luftfeuchtigkeit an einer zweiten Y-Achse (rechts) abgetragen werden. Aus Gründen der Übersichtlichkeit wird dabei nur ein Ausschnitt der Werte für den ersten Sensor dargestellt.
set datafile separator ","
set xdata time
set timefmt "%Y-%m-%dT%H:%M:%S"
set xrange [ "2018-06-04T17:57:26" : "2018-07-11T12:44:50" ]
set yrange [ 23:25 ]
set y2range [ 40:65 ]
set y2tic
set format x "%m-%d\n%H:%M"
plot "dht22data.csv" u 1:2 title "Temp 1" axes x1y1, "dht22data.csv" u 1:3 title "Humd 1" axes x1y2
Mit set y2range [ 40:65 ] wird ein Intervall für die zweite Y-Achse festgelegt und mit set y2tic die Beschriftung der Achse aktiviert. Die letzte Zeile stellt den Plot-Befehl dar. Hier ist zu erkennen, dass bei Verwendung von zwei Y-Achsen stets mit anzugeben ist, an welcher Achse ein Wert abgetragen werden soll.
Darstellung von Temperatur und Luftfeuchtigkeit in einem Diagramm
Beispiel 4: Erstellung eines Histogramms
In diesem Beispiel wird aus den Daten einer CSV-Datei ein Histogramm erstellt. Die Datei selbst hat folgenden Aufbau und kann wie gewohnt von dieser Seite heruntergeladen werden, um das Beispiel nachvollziehen zu können.
Das Komma wird als Spaltentrennzeichen verwendet. Die erste Zeile enthält Spaltenüberschriften, gefolgt von den darzustellenden Werten in den folgenden Zeilen.
In diesem Beispiel wird dargestellt, wie viele Ereignisse pro Tag und Zeitraum erfasst wurden. Das Ergebnis soll dann wie folgt aussehen.
Darstellung von einer Anzahl Ereignisse pro Tag und Zeitraum
set datafile separator ","
set grid
set key top right outside vertical autotitle columnhead
set xtics rotate by 90 right out nomirror
set ytics out
set style fill solid border -1
set boxwidth 0.5 relative
set title "Ereignisse pro Tag und Zeitraum"
set style data histograms
set style histogram rowstacked
plot for [col=2:5] 'file.csv' u col:xticlabels(1)
Zu Beginn wird das Spaltentrennzeichen definiert. Die folgende Angabe schaltet ein Gitternetz innerhalb des Histogramms ein. Dies dient der besseren Übersicht.
Die dritte Zeile im Quelltext gibt an, dass die erste Zeile in der Beispieldatei genutzt werden soll, um passende Spaltenüberschriften zu generieren und als vertikale Legende rechts außerhalb des Diagramms darzustellen. Möchte man dies nicht verwenden, ist die erste Zeile der Beispieldatei auszukommentieren, da Gnuplot andernfalls einen Fehler meldet.
Da ein Histogramm mit einer wachsenden Anzahl Balken erstellt wird, ist die Beschriftung der X-Achse (mit den Werten aus Spalte 1) etwas anzupassen. Der Code in Zeile 4 dreht die Bezeichner um 90° und richtet sie rechtsbündig am dazugehörigen Balken aus. Die drei folgenden Zeilen kümmern sich um die Formatierung der Y-Achse und das Aussehen der Balken bzw. der Boxen in den Balken. Spielen Sie ruhig mit den Werten, um zu sehen, wie sich Änderungen auf die Darstellung auswirken.
Mit set title wird das Diagramm mit einem Titel überschrieben.
In den beiden vorletzten Zeilen wird angegeben, dass ein Histogramm gezeichnet werden soll und das die Daten Zeilenweise verarbeitet werden. Dies bedeutet, dass die in einer Zeile enthaltenen Werte anschließend als Boxen in einem Balken dargestellt werden. Pro Zeile wird ein Balken gezeichnet.
Die letzte Zeile zeichnet dann das Histogramm. Durch for [col=2:5] wird angegeben, dass die Werte in den Spalten 2 bis 5 als Boxen in einem Balken dargestellt werden. Mit col:xticlabels(1) wird erreicht, dass ein Balken einem Datum aus Spalte 1 zugeordnet wird.
Natürlich können auch die Einstellungen aus diesem Beispiel mit load "dateiname.gp" gespeichert und später wiederverwendet werden.
Fazit
Ich selbst bin erst vor relativ kurzer Zeit auf Gnuplot aufmerksam geworden, doch möchte ich es heute nicht mehr missen.
Hat man sich erstmal an die Bedienung gewöhnt, lassen sich schnell und effizient anschauliche Diagramme produzieren, ohne eine Tabellenkalkulation bemühen zu müssen.
Ich hoffe, dieses kleine Gnuplot-Tutorial hat euch gefallen und konnte euer Interesse an einem schönen und leistungsstarken Werkzeug wecken.
In diesem Artikel halte ich fest, wie ich Postfix unter RHEL 7 für SMTP-Authentifizierung an einem relayhost über STARTTLS mit den Authentifizierungsmethoden PLAIN und LOGIN konfiguriert habe. Da ich kein Postfix-Experte bin, mag dies weder der einzige noch der beste Weg sein, doch habe ich das Ziel erreicht. Verbesserungsvorschläge nehme ich gerne in den Kommentaren entgegen.
Ihr findet hier vor allem keine Schritt-für-Schritt-Anleitung und kein ausführliches Tutorial. Seid also nicht enttäuscht, wenn ihr auch die am Ende des Artikels verlinkten Quellen zu Rate ziehen müsst.
Der Artikel gliedert sich in die folgenden Abschnitte:
Für die SMTP-Authentifizierung am relayhost werden Benutzername und Passwort benötigt. Bevor ich Postfix (ver)konfiguriere, überprüfe ich, ob der SMTP-Server diese Zugangsdaten akzeptiert. Da die Zugangsdaten über STARTTLS übertragen werden, prüfe ich, ob der SMTP-Server dies überhaupt unterstützt. Im folgenden Listing wird der TCP-Port 25 verwendet. In Abhängigkeit zur konkreten Umgebung kann auch ein anderer Port wie z.B. 587 in Frage kommen. # telnet relayhost.example.com 25 Trying 192.168.0.1... Connected to relayhost.example.com. Escape character is '^]'. 220 ESMTP Messaging Multiplexor bla bla EHLO localhost 250-relayhost.example.com [...] 250-AUTH PLAIN LOGIN 250-AUTH=LOGIN PLAIN 250 STARTTLS
Mit der Zeile „250 STARTTLS“ ist die Voraussetzungen erfüllt, dass wir Klartext-Benutzernamen und -Passwort durch STARTTLS geschützt an den Server übermitteln können. Welche Authentifizierungsverfahren innerhalb von STARTTLS unterstützt werden, kann mit folgenden Kommandos überprüft werden:
Die Option -crlf ist nur anzugeben, wenn es sich bei dem Zielsystem um Microsoft Exchange handelt. An der Ausgabe ist zu erkennen, dass dieser relayhost die Authentifizierungsverfahren NTLM und LOGIN unterstützt.
Benutzername und Kennwort müssen dabei Base64-kodiert an den SMTP-Server übertragen werden. Der Base64-kodierte String kann mit folgendem Befehl erstellt werden. Dabei ist im folgenden Beispiel „Max“ der Benutzername und „pusemuckel“ das Passwort.
Kodierung für AUTH PLAIN
Hierbei werden Benutzername und Passwort in einem String kodiert.
Die letzte Zeile ist die Bestätigung, dass eine Authentifizierung mit dem bekannten Benutzernamen und dem dazugehörigen Passwort über STARTTLS und AUTH PLAIN möglich ist.
Für AUTH LOGIN sieht der Test wie folgt aus. Die zusätzliche Option -crlf ist dann zu verwenden, wenn es sich bei dem Zielsystem z.B. um ein Microsoft System handelt, da diese traditioniell andere Zeilenumbrüche verwenden.
Auch hier bestätigt die letzte Zeile die Gültigkeit unserer Benutzeranmeldeinformationen.
Installation fehlender Pakete und Konfiguration von Postfix
Da die Installation meines Hosts auf einer RHEL-Minimalinstallation basiert, werden zuerst zwei benötigte Pakete nachinstalliert: # yum install cyrus-sasl cyrus-sasl-plain
Datei mit Anmeldeinformationen erstellen
Es ist die Datei /etc/postfix/sasl_passwd mit folgendem Inhalt zu erstellen:
# cat /etc/postfix/sasl_passwd
smtp.example.com Max:pusemuckel
Zu Beginn der Zeile wird der FQDN des SMTP-Servers eingetragen, gefolgt von Benutzername:Passwort im Klartext. Damit nun nicht jeder diese Datei lesen kann, wird der Zugriff mit den folgenden Kommandos auf den Benutzer ‚root‘ eingeschränkt und anschließend eine Postfix-DB-Datei erstellt:
# chown root:root /etc/postfix/sasl_passwd && chmod 600 /etc/postfix/sasl_passwd
# postmap hash:/etc/postfix/sasl_passwd
# ls -l /etc/postfix/sasl_passwd*
-rw-------. 1 root root 52 26. Jul 08:57 /etc/postfix/sasl_passwd
-rw-------. 1 root root 12288 26. Jul 08:59 /etc/postfix/sasl_passwd.db
Konfiguration der /etc/postfix/main.cf
Für die Konfiguration habe ich mich an [2] orientiert. Um STARTTLS und die SMTP-Authentifizierung zu aktivieren, habe ich folgende Zeilen an meine /etc/postfix/main.cf angefügt:
# tail -n 10 /etc/postfix/main.cf
# SASL SUPPORT FOR SERVERS
#
# The following options set parameters needed by Postfix to enable
# Cyrus-SASL support for authentication of mail servers.
#
smtp_use_tls = yes # Aktiviert TLS für Postfix
smtp_sasl_auth_enable = yes # Aktiviert SMTP AUTH für Postfix
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd # Gibt an wo Postfix die Zugangsdaten findet
smtp_sasl_security_options = # Durch setzen der leeren Option wird die PLAIN- und anonyme Authentifizierung aktiviert
Für AUTH LOGIN ist zusätzlich noch die folgende Zeile einzufügen:
smtp_sasl_mechanism_filter = login
Abschließend ist die Postfix-Konfiguration neu zu laden:
# systemctl reload postfix.service
Test des Mailversands
Um den Mailversand zu testen, habe ich vom lokalen System aus eine kurze E-Mail versendet:
# mailx -s "Testmail mit SMTP-AUTH und STARTTLS" foo@example.com << EOT > EOT
Null message body; hope that's ok
Wie heise online in diesem Bericht verkündet, will das Land Schleswig-Holstein die Abhängigkeit von Microsoft-Produkten verringern und die Verwaltung zukünftig komplett auf freie Software umrüsten.
Mir persönlich gefällt an dem Antrag der Fraktionen von
CDU, Bündnis`90/Die Grünen und FDP, dass diesmal nicht die Kostenreduzierung als oberstes Ziel formuliert wurde. Denn dass man mit freier Software durch den Wegfall von Lizenzgebühren IT-Kosten drastisch senken kann, ist ein häufiger Irrglaube.
Statt dessen formuliert der Antrag eindeutig die Absicht, die Abhängigkeit zu einzelnen Herstellern und deren Lizenzmodellen soweit wie möglich zu reduzieren. Dabei handelt es sich jedoch nicht um eine Umstellung um jeden Preis. Es soll nun nicht damit begonnen werden, alle etablierten Verfahren ohne besonderen Anlass auf freie Software umzustellen. Jedoch soll dies stets dann geprüft werden, wenn Neubeschaffungen anstehen, oder wesentliche Änderungen an bestehenden Verfahren/Programmen vorgenommen werden müssen.
Damit die Anwender nicht (wie so oft) auf der Strecke bleiben, sollen diese laut Antrag von Beginn an mit einbezogen werden. Frühzeitige Anwenderschulungen und eine Kommunikation von Sinn und Zweck einer Umstellung sollen die Akzeptanz bei den Mitarbeitern und Mitarbeiterinnen fördern.
Für mich klingt dieser Antrag durchdacht und schlüssig. Mir gefällt daran besonders, dass er die Punkte in den Mittelpunkt stellt, an denen bereits viele Open Source Projekte gescheitert sind. Dies sind in meinen Augen:
Keine Umstellung um jeden Preis, sondern sukzessive dort, wo dies sinnvoll und nachhaltig erscheint
Einbeziehung und Schulung der Mitarbeiterinnen und Mitarbeiter von Beginn an
Kein Versprechen, das mit einer Umstellung eine drastische Kostenreduzierung einhergeht
Ob es wirklich so kommt, bleibt natürlich abzuwarten. Es besteht jedoch Hoffnung, dass hier mit Verstand und Augenmaß gehandelt wird und freie Software Schritt für Schritt Einzug in die Verwaltung des Landes Schleswig-Holstein erhält. Auf jeden Fall klingt es nach einem spannenden Unterfangen, welches sich im Auge zu behalten lohnt.
Im heutigen Beitrag aus der Kategorie Wochenend-Projekte geht es darum, wie man mit Hilfe eines Reverse-SSH-Tunnels ein Offsite-Backup für die heimische Datensammlung realisieren kann. Der Beitrag soll mir als Dokumentation und euch als Anregung für ähnliche Projekte dienen.
Anwendungsfall (Use Case)
In meinem Heimnetzwerk gibt es ein NAS, welches der Familie als allgemeines Datengrab dient. Lagen hier anfangs nur Datensicherungen anderer Geräte, verwalten wir heute, neben anderen Daten, unsere Familien- und Urlaubsfotos auf diesem Gerät. Es existiert eine lokale Datensicherung dieser Daten, die vor versehentlichem Löschen schützt.
Nun sind uns einige dieser Daten so wichtig, dass wir sie auch gern gegen Verlust durch z.B. Feuer oder Diebstahl schützen möchten. Dazu möchte ich die betreffenden Daten gern außerhalb der eigenen vier Wände an einem anderen Standort sichern. Diese Form der Datensicherung bezeichne ich im Folgenden auch als Offsite-Backup.
Anforderungen
An das Offsite-Backup stelle ich folgende Anforderungen:
Die Datenübertragung erfolgt über gesicherte Verbindungen
Die Daten werden in einem Format gespeichert, welches das Lesen ohne Abhängigkeit zu bestimmten Programmen ermöglicht
Die Datenübertragung soll manuell angestoßen werden und optional zeitgesteuert ausgeführt werden können
Eine Wiederherstellung der Daten soll über den gleichen Kanal wie die Datensicherung möglich sein
Die Daten sollen nicht bei einem kommerziellen Anbieter gespeichert werden
Die Daten sollen nicht in einem Speicher abgelegt werden, der sich des unmittelbaren Zugriffs entzieht
In den Routern der beteiligten Heimnetzwerke sollen keine eingehenden Portweiterleitungen konfiguriert werden müssen
Alles was ich benötige, um die obigen Anforderungen umzusetzen sind:
Ein Raspberry Pi
Eine externe USB-Festplatte zum Anschluss an den Pi
Einen Linux-Root-Server im Internet
Einen LAN-Port und Stromanschluss im Elternhaus
Zu meinem Glück sind all diese Dinge bereits vorhanden und ich muss nicht erst eine Einkaufstour unternehmen.
Die Lösung
In groben Zügen erklärt, sieht die Lösung wie folgt aus. An den Raspberry Pi wird eine USB-Festplatte angeschlossen, welche als Speicher für die zu sichernden Daten dient. Der Pi wird in meinem Elternhaus an das dortige Heimnetzwerk angeschlossen. Von dort ausgehend baut er einen Reverse-SSH-Tunnel zu meinem Linux-Server auf, welcher bei einem Hoster läuft und auf eingehende SSH-Verbindungen lauscht. So kann ich von dem Linux-Server aus auf den Pi zugreifen, ohne dass im DSL-Router in meinem Elternhaus eine Portweiterleitung eingerichtet werden muss. Darüber hinaus entfällt auch die Notwendigkeit, die Gegenstelle über die sich ändernde dynamische IP-Adresse auf dem Laufenden zu halten.
SSH-Verbindungen über eine Vermittlungsstelle für ein Offsite-Backup
Nun kann ich von dem NAS aus meinem Heimnetzwerk eine SSH-Verbindung über den Linux-Server zum Raspberry Pi in meinem Elternhaus aufbauen und Daten dorthin übertragen. Auch in meinem Heimnetzwerk muss dazu keine Portweiterleitung geschaffen werden.
Konfiguration auf dem Pi
Auf dem Raspberry Pi habe ich das Betriebssystem Raspbian installiert. Anschließend habe ich ein SSH-Schlüsselpaar erstellt und den öffentlichen SSH-Schlüssel auf dem Linux-Server hinzugefügt, um ohne die Eingabe eines Passworts eine SSH-Verbindung herstellen zu können. Für die Verbindung verwende ich normale Linux-Benutzer ohne besondere Privilegien. Nun kann mit dem Befehl ssh -R 22222:localhost:22 user@Linux-Server ein Reverse-SSH-Tunnel zum Raspberry Pi aufgebaut werden. Der Reverse-SSH-Tunnel ermöglicht es, vom Linux-Server aus mit dem Befehl ssh -p22222 localhost eine Verbindung zum Raspberry Pi aufbauen zu können.
Damit der Reverse-SSH-Tunnel nach der Provider-Zwangstrennung automatisch wieder aufgebaut wird, habe ich auf dem Raspberry Pi folgende Service-Unit erstellt:
Die Option RestartSec gibt an, dass bei einem Verbindungsabbruch 73 Sekunden gewartet wird, bevor ein erneuter Verbindungsversuch gestartet wird. Damit möchte ich dem DSL-Router Zeit für die Wiedereinwahl geben.
Konfiguration auf dem NAS
Auf dem NAS erstelle ich im HOME-Verzeichnis des Benutzers, welcher später die Datensicherung ausführen wird, die Datei ~/.ssh/config mit folgendem Inhalt, um auf einfache Weise eine SSH-Verbindung zum Raspberry Pi im entfernten Standort herstellen zu können.
Host raspi
HostName localhost
Port 22222
ProxyCommand ssh -i ~/.ssh/nas_rsa -A -W %h:%p user@linux-server
IdentityFile ~/.ssh/nas_rsa
ProxyCommand gibt an, dass der Linux-Server als Proxy bzw. Zwischenpunkt der Verbindung dient. In neueren SSH-Versionen kann man statt dessen auch die etwas einfacher zu handhabende Option JumpHost verwenden.
Neben der obigen Datei wurde auf dem NAS ein SSH-Schlüsselpaar erstellt, dessen öffentlicher Schlüssel auf dem Linux-Server und dem Raspberry Pi im entfernten Standort hinterlegt wurde. Dadurch ist für die Durchführung der Datensicherung keine Passworteingabe erforderlich. Da beide Endpunkte der Verbindung in vertrauenswürdigen Netzen liegen, halte ich diese Vorgehensweise für vertretbar.
Probleme
Leider läuft das Ganze noch nicht so rund und störungsarm, wie ich es mir wünsche. Bei der Zwangstrennung reißt die Verbindung ab, ohne dass der Raspberry Pi eine Chance hätte, den Socket auf dem Server zu schließen.
Da der verwendete Port noch auf dem Linux-Server gebunden ist, schlägt eine erneute Einwahl fehl. Erst wenn der Socket nach einem Timeout geschlossen wurde, ist eine erneute Wiederherstellung der Verbindung möglich.
Update 2018-05-21: Danke an Christian F., welcher mich auf die Optionen ClientAliveCountMax und ClientAliveInterval hingewiesen hat. Mit diesen Optionen kann der SSH-Server erkennen, dass die Verbindung zum Client abgerissen ist und den Socket schließen.
Der Standardwert für ClientAliveCountMax beträgt 3. Dabei handelt es sich um client alive messages, welche der Server zum Client sendet. Bleiben alle drei unbeantwortet, baut der Server die Verbindung ab und gibt den Socket frei. Den Wert für ClientAliveInterval habe ich auf 15 gesetzt. Er gibt an, dass nach 15 Sekunden Inaktivität eine client alive message vom Server an den Client gesendet wird, um zu überprüfen, ob der Client noch antwortet.
Antwortet der Client nicht, wird mit der obigen Konfiguration die Verbindung vom Server nach 45 Sekunden abgebaut und der Socket freigegeben. Der Client kann sich anschließend wieder neu verbinden. Auf dem Client habe ich den Parameter RestartSec auf 73 Sekunden gesetzt (einfach weil mir die Zahl so gut gefällt). Nach dem Abriss der Verbindung durch die Zwangstrennung wird der Tunnel nach 73 Sekunden wieder aufgebaut.
Fazit
Mit dieser kleinen Bastellösung kann ich meine Daten über einen gesicherten Kanal in einen entfernten Standort sichern. Das manuelle Offsite-Backup klappt bereits gut, wenn der SSH-Tunnel zwischen Linux-Server und Raspberry Pi steht.
Da das Problem mit der Zwangstrennung nun etwas entschärft werden konnte, steht auch einem zeitgesteuerten Backup grundsätzlich nichts mehr im Wege. Es bleibt lediglich das Restrisiko, dass sich der Zeitpunkt der Zwangstrennung ändert und diese dann das zeitgesteuerte Backup unterbricht. Mit diesem Risiko komme ich jedoch zurecht.
Wählt man bei Online-Händlern die Zahlungsweise Kreditkartenzahlung aus, wird man heute in den meisten Fällen mit dem Verfahren 3-D Secure [1] konfrontiert. Je nachdem welche Kreditkarte man verwendet, heißt das Verfahren Verified by Visa oder bei einer Mastercard SecureCode.
Durch das Verfahren sollen Zahlungsausfälle durch Kreditkartenmissbrauch reduziert werden. Teilnehmenden Online-Händlern wird zudem der Zahlungseingang garantiert, wenn sie 3-D Secure einsetzen.
Doch welche Vorteile bietet dieses Verfahren für den Kunden? Auf den ersten Blick gar keine. Statt eines Passwortes muss der Kunde sich nun eine PIN für die Banking-App bzw. für sein mobiles Endgerät merken.
Im Wikipedia-Artikel zu 3-D Secure [1] wird zudem ausgeführt:
Auch im Jahr 2018 gibt es jedoch noch Konstellationen, in denen die Haftungsfrage eindeutig zu Lasten des Kunden ausfällt und die Registrierung zu 3-D Secure ein im Vergleich zu anderen Zahlungswegen für den Kunden außergewöhnlich riskantes Verfahren sein kann, wie folgender Fall verdeutlicht: Die DKB hat vom statischen Sicherheitscode auf einen dynamischen Code per App oder mTAN umgestellt. In ihren Sonderbedingungen für 3-D Secure legt die DKB aktuell einen Haftungsausschluss für den Fall fest, „dass das mobile Endgerät verloren, gestohlen oder weitergegeben wird und dadurch Dritte ggf. Zugriff auf SMS erhalten und diese unberechtigt nutzen können“. Bei einem möglichen gleichzeitigen Verlust von Kreditkarte und Mobilfunkgerät kann ein Finder also beliebige Zahlungen zu Lasten des Besitzers auslösen und verifizieren, vorausgesetzt er bekommt Zugang zum Mobilgerät (etwa durch eine einfache Tastensperre). Für diese missbräuchlichen Zahlungen haftet der Kunde vollständig bis zur Sperrung der Karte, bei einer Zahlung ohne 3-D Secure haftet er dagegen nur bis maximal 50 €. Bei Verlust stellen weder die auf der Karte aufgedruckten Daten, noch das 3-D-Secure-Verfahren eine Hürde für den einfachen Missbrauch dar, sondern lediglich die PIN oder vergleichbare Sicherungsmechanismen des Mobilgeräts. Das Risiko für den Kunden ist in dieser Konstellation höher, als ohne Registrierung zum 3-D-Secure-Verfahren, unabhängig davon, ob der Kunde 3-D Secure überhaupt benutzt.
Diese Aussage ließ mich zunächst zweifeln, ob ich mich überhaupt noch zum dynamischen 3-D Secure Verfahren anmelden sollte. Ich beschloss daher, die Sonderbedingungen für das 3D Secure Verfahren bei Internet-Zahlungen mit der DKB-Kreditkarte [2] genau zu lesen und im Zweifel bei meiner Bank nachzufragen, wie es sich mit der Haftung verhält.
Aus den Sonderbedingungen für das 3D Secure Verfahren bei Internet-Zahlungen mit der DKB-Kreditkarte
Im Folgenden zitiere ich aus den oben genannten Sonderbedingungen [2] und liste die Fragen auf, welche durch die genannten Punkte aufgeworfen wurden.
Sorgfaltspflichten des Karteninhabers
Hier Punkt 1:
1) Der Karteninhaber
a) hat das Risiko eines unberechtigten Zugriffs auf sein mobiles Endgerät u. a. durch geeignete Schutzmaßnahmen zu minimieren (z.B. PIN auf mobiles Endgerät).
b) hat das Betriebssystem des von ihm verwendeten Endgerätes auf dem neuesten Stand zu halten.
c) hat die App nur aus offiziellen App-Stores (iTunes, Google Playstore, Windows Store) herunterzuladen und dafür vorgesehene Updates regelmäßig durchzuführen.
Während Punkt a) noch einleuchtet, wirft Punkt b) bereits erste Fragen auf. Was mache ich, wenn mein Endgerät schon älter ist und der Hersteller keine Updates mehr für das Betriebssystem veröffentlicht? Was ist, wenn ich mir im Handel ein neues Android-Gerät kaufe, welches mit einer älteren Android-Version ausgeliefert wird und vom Hersteller ebenfalls keine Updates mehr für das Betriebssystem erhält? Darf ich in oben genannten Fällen überhaupt noch am 3-D Secure Verfahren teilnehmen? Oder darf die DKB in diesen Fällen bereits die Haftung im Missbrauchsfall ablehnen?
Zu Punkt 3:
Die DKB AG haftet nicht für den Fall, dass das mobile Endgerät verloren, gestohlen oder weitergegeben wird und dadurch Dritte ggf. Zugriff auf SMS erhalten und diese unberechtigt nutzen können.
Dies ist der Punkt, welcher bereits im Wikipedia-Artikel [1] kritisiert wurde. Hier stellt sich die Frage, ob ich mich mit einer Teilnahme an 3-D Secure nicht schlechter stelle.
Verantwortlichkeit und Haftung
Punkt 7 der Sonderbedingungen [2] widmet sich dann konkret der Haftung:
[…] Die DKB AG übernimmt außerdem keine Haftung bei Manipulation des mobilen Endgeräts (z.B. Jailbreaking, Rooting).
Bedeutet dies, dass Nutzer freier bzw. alternativer Betriebssysteme das Verfahren nicht nutzen können? Schließlich sind Jailbreaks und Rooting oftmals Voraussetzung, um ein Custom-ROM auf ein Endgerät aufspielen zu können.
Mit obigen Fragen habe ich mich per E-Mail an die DKB gewendet und um schriftliche Antwort gebeten.
Die Antwort der DKB
Eine Antwort ließ nicht lange auf sich warten. Man bat darum, die Sache zunächst am Telefon zu erörtern. Auf Wunsch bestätigte man mir die wesentlichen Inhalte dann auch schriftlich.
Nach Aussage eines Mitarbeiters aus der Technik wurde die DKB Secure App so entworfen, dass sie den Patchlevel des mobilen Betriebssystems prüfen und erkennen kann, ob das Gerät gerootet bzw. gejailbreakt wurde. Ist letzteres der Fall oder ist der Patchlevel des Endgerätes zu alt, verweigert die App den Start.
Mir wurde bestätigt, dass dies im Umkehrschluss bedeutet, dass wenn die App startet, die Sorgfaltspflicht aus Punkt 1.b) als erfüllt angesehen werden kann.
Die schlechte Nachricht für die Freunde freier Betriebssysteme ist, dass die DKB jegliche Haftung ablehnt, wenn die App nicht aus den offiziellen App Stores bezogen wurde und/oder unter einem Custom-ROM betrieben wird. Der Haftungsausschluss gilt in diesem Fall übrigens auch, wenn man statt der App das mTAN-Verfahren via SMS nutzen möchte.
Steht noch die Antwort zu Punkt 3 aus. Hierzu teilte mir eine Mitarbeiterin aus der Fachabteilung Privatkundenservice mit, dass die Haftung bei Diebstahl des mobilen Endgeräts nur dann ausgeschlossen ist, wenn der Kunde grob fahrlässig gehandelt hat. Unter grobe Fahrlässigkeit fällt dabei zum Beispiel, dass:
das Endgerät nicht mit einer Zugangssperre (PIN) versehen ist,
oder die PIN des Endgeräts bzw. der App zusammen mit der Kreditkarte oder dem Endgerät aufbewahrt wird.
Die Beweislast, dass grobe Fahrlässigkeit vorliegt, liegt in diesem Fall bei der Bank.
Mein persönliches Fazit
Die DKB hat zeitnah auf meine Fragen reagiert und diese zu meiner Zufriedenheit beantwortet. Dies empfinde ich als positiv.
Dass die Nutzung freier bzw. alternativer Betriebssysteme quasi ausgeschlossen ist, da bei Jailbreak oder Rooting die Haftung komplett ausgeschlossen wird, bedaure ich. Da man mit einem Jailbreak bzw. Rooting jedoch elementare Sicherheitsmechanismen umgehen kann, kann ich den Haftungsausschluss an dieser Stelle nachvollziehen.
Ich selbst habe mein Telefon nun wieder mit einer PIN versehen und meine Kreditkarte registriert.
Ob es bei SecureCode für Mastercard genauso aussieht, kann ich noch nicht sagen. Sobald ich die Bedingungen hierfür gefunden, studiert und eventuelle Fragen geklärt habe, werde ich diesen Artikel aktualisieren.
