Archiv des Autors: Jörg Kastning

Linux: Hotplugged SATA/SAS/SCSI-Festplatten ohne Neustart erkennen

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.

Empfehlungen für Raumklimaüberwachung erwünscht

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.

  1. Die Messstation soll frei im Raum platziert werden können.
  2. Die Stromversorgung erfolgt über Batterie, Akku oder Powerbank. Ein Anschluss an eine Steckdose ist nicht erforderlich.
  3. Die Messstationen übertragen die Messwerte über eine Funkverbindung (z.B. WLAN, Bluetooth, 433 MHz, etc.) an eine zentrale Empfangsstation.
  4. Die Empfangsstation muss an einem Raspberry Pi betrieben werden können, da dieser die Messdaten weiterverarbeiten soll.
  5. Die Verwendung freier und offener Standards/Protokolle wird bevorzugt.
  6. Messbereich für die Temperatur mindestens 0-70 °C bei einer Genauigkeit von +/- 0,5 °C.
  7. Messbereich für die Luftfeuchtigkeit mindestens 0-100% relative Luftfeuchtigkeit (RH) bei einer Genauigkeit von +/- 5% RH.
  8. Fühler für Temperatur und Luftfeuchtigkeit können in einem gemeinsamen oder in getrennten Sensoren untergebracht sein.
  9. Frei konfigurierbares Messintervall von 10-86400s.
  10. Frei wählbare Anzahl Messstationen. Es müssen jedoch mindestens 32 Sensoren an die zentrale Empfangsstation angebunden werden können.
  11. Unterstützung von Linux zur Entwicklung und Programmierung der Lösung.

Optionale Anforderungen

  1. Die Messstationen können mit einem Display zum Ablesen der Messwerte ausgestattet werden.
  2. Die Displays verfügen über eine per Knopfdruck zuschaltbare Displaybeleuchtung.
  3. Die Messstationen besitzen einen guten WAF.

Vorhandene Infrastruktur und Fähigkeiten

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.

20 Jahre LinuxDay AT

LinuxDay 2018 am 13. Okt in Dornbirn

Am 13. Oktober 2018 findet zum zwanzigsten Mal der LinuxDay in der HLT Dornbirn in Österreich statt.

Auf der Webseite der Veranstaltung findet sich in diesem Jahr daher neben reichlich Informationen zur Veranstaltung auch ein Abriss ihrer Geschichte.

Auch das Vortragsprogramm ist wieder gut gefüllt. Einen Überblick, über die geplanten Vorträge findet ihr unter: https://www.linuxday.at/vortraege/2018

Der Eintritt ist frei. Also packt eure Sachen und schaut vorbei. ;-)

Ein Gnuplot-Tutorial

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.

Wikipedia (letzter Abruf: 04.08.2018)

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:

# Energiepreise_Heizoel_Strom.csv
# https://www.destatis.de/DE/Publikationen/Thematisch/Preise/Energiepreise/Energiepreisentwicklung.html
# Elektrischer Strom in Cent/kWh inkl. Steuern
# Leichtes Heizöl Cent/l inkl. Mineralölsteuer und Erdölbevorratungsbeitrag, ohne Mehrwertsteuer
# Jahresdurchschnitt
# Berichtsjahr;leichtes Heizöl;Strom
2000;35,30;
2001;32,06;
2002;30,27;
2003;30,75;
2004;34,41;
2005;45,11;
2006;50,32;
2007;49,73;
2008;64,08;21,72
2009;43,77;22,88
2010;54,87;24,07
2011;69,26;25,3
2012;75,33;26,36
2013;70,36;29,2
2014;64,37;29,78
2015;48,79;29,49
2016;40,94;29,73
2017;47,51;30,48
2018;53,74;

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:

  1. Öffne ein Terminal
  2. Wechsle in das Verzeichnis, in dem die Datei Energiepreise_Heizoel_Strom.csv liegt
  3. 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.

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.

Datum,0-6 Uhr,6-12 Uhr,12-18 Uhr,18-24 Uhr
2018-07-17,2,4,6,4
2018-07-18,1,5,5,2
2018-07-19,0,8,4,3
2018-07-20,0,3,7,6

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.

Kommentar zum geplanten Umstieg auf Open Source in Schleswig-Holstein

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.

Update 2018-05-21: Mit einem Reverse-SSH-Tunnel zum Offsite-Backup

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:

  1. Die Datenübertragung erfolgt über gesicherte Verbindungen
  2. Die Daten werden in einem Format gespeichert, welches das Lesen ohne Abhängigkeit zu bestimmten Programmen ermöglicht
  3. Die Datenübertragung soll manuell angestoßen werden und optional zeitgesteuert ausgeführt werden können
  4. Eine Wiederherstellung der Daten soll über den gleichen Kanal wie die Datensicherung möglich sein
  5. Die Daten sollen nicht bei einem kommerziellen Anbieter gespeichert werden
  6. Die Daten sollen nicht in einem Speicher abgelegt werden, der sich des unmittelbaren Zugriffs entzieht
  7. 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:

  1. Ein Raspberry Pi
  2. Eine externe USB-Festplatte zum Anschluss an den Pi
  3. Einen Linux-Root-Server im Internet
  4. 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.

model of an offsite backup

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:

[Unit]
Description="Reverse ssh tunnel to proxy"
After=network.target

[Service]
User=pusemuckel
ExecStart=/usr/bin/ssh -NTi /home/pusemuckel/.ssh/id_rsa -o ServerAliveInterval=60 -R 22222:localhost:22 user@Linux-Server
RestartSec=73
Restart=always

[Install]
WantedBy=multi-user.target

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.

3-D Secure alias Verified by Visa alias SecureCode

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.

Quellen und weiterführende Links

[1] Wikipedia: 3-D Secure
[2] Sonderbedingungen für das 3D Secure-Verfahren bei Internet-Zahlungen mit der DKB-Kreditkarte
[3] smsTAN vs. pushTAN vs. chipTAN

Konzept zum Deployment meines Blogs mit Ansible

An dieser Stelle möchte ich ein Konzept erarbeiten, um meinen Blog mit Hilfe von Ansible1 2 auf einem Ubuntu-Server ausbringen zu können.

Dabei hoffe ich auch ein wenig auf eure Unterstützung. Habt ihr Anregungen, konkrete Verbesserungsvorschläge oder auch Fragen, freue ich mich über eure Kommentare. Denn ich selbst bin kein Ansible-Experte und führe dieses Projekt zum Selbststudium und zu Übungszwecken durch.

Die Testumgebung

Die Testumgebung besteht aus der Ansible Control Machine, basierend auf RHEL 73 und dem Zielsystem, basierend auf Ubuntu Bionic Beaver4. Zum Zeitpunkt der Erstellung dieses Artikels nutze ich Ansible in Version 2.4.2.

Zwar wurde bereits die Ansible-Version 2.5 veröffentlicht, in den RHEL-7-Paketquellen ist jedoch noch die Version 2.4.2 enthalten. Ich verwende diese Version auch auf der Arbeit und erhoffe mir so, Erkenntnisse aus diesem Projekt in meine dienstliche Tätigkeit einfließen lassen zu können.

Auf dem Zielsystem existiert ein Benutzer, welcher über volle sudo-Berechtigung verfügt. Dieser Benutzer muss sich mit seinem Passwort authentisieren, wenn er sudo verwendet.

Auf der Ansible Control Machine wird ein SSH-Schlüsselpaar5 generiert, dessen privater Schlüssel nicht mit einer Passphrase geschützt ist. Der öffentliche Schlüssel wird auf dem Zielsystem abgelegt. Damit wird sichergestellt, dass die Ansible Control Machine SSH-Zugriff auf das Zielsystem hat.

Die Konfiguration von Ansible (/etc/ansible/ansible.cfg) wird so angepasst, dass standardmäßig das oben erzeugte SSH-Private-Key-File beim Verbindungsaufbau genutzt wird.

Die Installation der benötigten Betriebssysteme und Ansible sind nicht Gegenstand dieses Artikels.

Geplante Vorgehensweise

Um eine Vorgehensweise zu erarbeiten, orientiere ich mich an dem Artikel Testinstanz für einen WordPress-Blog erstellen. In diesem habe ich bereits beschrieben, wie ein Blog auf einem weiteren System als Testsystem aufgesetzt werden kann. Die Vorgehensweise ist ähnlich, mit dem Unterschied, dass sämtliche Schritte nun durch Ansible orchestriert werden sollen.

Danach ergibt sich folgende (vorläufige) Reihenfolge:

  1. Vom Produktivsystem benötigte Dateien holen
  2. Sicherstellen, das alle benötigten Pakete auf dem Zielsystem installiert sind
  3. VirtualHost erstellen
  4. DocumentRoot aus Backup-Datei erstellen
  5. Datei-Attribute und Zugriffsrechte korrekt setzen
  6. Eine .httpasswd-Datei erzeugen/ausbringen
  7. Datenbank aus Backup wiederherstellen
  8. Datenbankbenutzer erstellen
  9. Troubleshooting

Mit hoher Wahrscheinlichkeit ist die obige Liste noch nicht vollständig. Daher werde ich diese im Laufe des Projekts anpassen, sobald weitere Erkenntnisse vorliegen.

Als Quelldaten für den Blog liegen das DocumentRoot meines Blogs als Tarball6 vor. Von der Datenbank wurde ein logisches Backup7 erstellt. Auf diese Datensicherung wird zurückgegriffen, um den Blog auf einem neuen Ubuntu-Server auszubringen bzw. wiederherzustellen.

Der erste Versuch

Im ersten Anlauf habe ich eine Ansible-Rolle8 mit folgendem Aufbau erstellt:

/etc/ansible/roles/
└── deploy-my-blog
    ├── files
    │   ├── backup-documentroot.tar.bz2
    │   ├── dh_params.pem
    │   ├── db_dump.sql.bz2
    │   ├── my-it-brain.vhost
    │   └── php-fpm-pool.conf
    ├── handlers
    │   └── main.yml
    ├── tasks
    │   └── main.yml
    └── vars
        └── main.yml

5 directories, 8 files

Unterhalb von files wurden Dateien abgelegt, welche vom aktuellen Produktivsystem stammen und für das Deployment auf einem neuen Server benötigt werden.

Im folgenden werde ich zuerst auf die eingesetzten Module eingehen und anschließend das Playbook zum Deployment des Blogs vorstellen.

Verwendete Module

ModulStatusVerwendung
aptstableinterfaceVerwaltet APT-Pakete
unarchivepreviewEntpackt Archiv-Dateien und kopiert sie ggf. vorher auf das Zielsystem
copystableinterfaceKopiert Dateien auf entfernte Rechner
filestableinterfaceErstellt Dateien, Verzeichnisse, symbolische Links und setzt deren Attribute
mysql_dbpreviewHinzufügen von MySQL-Datenbanken (aus Backup)
mysql_userpreviewHinzufügen (und Entfernen) von Benutzern in MySQL-Datenbanken

Die in der Spalte Status angegebenen Werte stableinterface und preview lassen Rückschlüsse auf die Stabilität der Schnittstellen eines Moduls zu.

So garantieren die Entwickler bei einem stableinterface, dass es in Zukunft keine Änderungen geben wird, die nicht abwärtskompatibel sind. Auch wenn sich keine explizite Angabe findet, wie lange diese Garantie gilt, kann man davon ausgehen, dass man seine Playbooks bei Verwendung dieser Module nicht so schnell aufgrund von Updates anpassen muss. Für Module mit dem Status preview wird genau dies hingegen nicht garantiert. Hier kann es von Version zu Version Änderungen geben, welche Anpassungen an Playbooks erforderlich machen, welche diese Module verwenden. Dadurch entsteht ggf. ein erhöhter Testaufwand, bevor man seine Ansible-Installation aktualisieren kann.

Das Playbook

Den Inhalt der Datei /etc/ansible/roles/deploy-my-blog/tasks/main.yml habe ich unter dem Namen deploy-blog-playbook.yml als Gist veröffentlicht. Um es in diesem Artikel anzeigen zu können, müsst ihr JavaScript in eurem Webbrowser aktiveren.

Die Zeilen 2-11 sorgen dafür, dass die benötigten Pakete auf dem Zielsystem installiert werden. Da es sich dabei um einen Ubuntu-Server handelt, verwende ich das Modul apt.

Die Zeilen 13-16 stellen das DocumentRoot und die SSL-Zertifikate aus dem Dateibackup auf dem Zielsystem wieder her.

In meiner aktuellen Konfiguration verwende ich PHP-FPM mit einem eigenen Pool, welcher in meinem VirtualHost referenziert wird. Um diese Konstellation auch auf dem neuen System nutzen zu können, stelle ich entsprechende Konfiguration mit den Zeilen 18-47 her. Vermutlich können die Zeilen 39-47 entfallen, da PHP-FPM das Logfile automatisch erstellt. Weitere Tests müssen dies noch zeigen. Ich habe diese Zeilen während des Troubleshootings eingefügt. Ursache für den Fehler wird vermutlich das fehlende Log-Verzeichnis gewesen sein, welches ich in den Zeilen 29-37 erzeuge.

Der NGINX auf meinem Produktivsystem verwendet die Datei dh_params.pem, welche ich in den Zeilen 49-57 auch auf den neuen Host kopiere. Anschließend wird in den Zeilen 59-66 die vHost-Datei auf das Zielsystem kopiert und durch die Zeilen 68-77 verlinkt und damit aktiviert.

Die letzten Zeilen kümmern sich um die Einrichtung der Datenbank. Zuerst wird die Dump-Datei auf das Zielsystem kopiert und dort anschließend in die neue Datenbank db_my_it_brain eingespielt. Zum Schluss wird noch der benötigte Datenbank-Benutzer erstellt.

In Zeile 94 und 95 habe ich Variablen eingesetzt, welche in vars/main.yml definiert wurden. Dort habe ich auch eine Variable für den Namen der Datenbank definiert, welche ich gern in Zeile 96 genutzt hätte. Leider ist es mir nicht gelungen, da sowohl priv: '"{{ DBNAME }}".*:ALL' als auch priv: "{{ DBNAME }}".*:ALL zu Fehlern führten. Falls hier jemand eine Idee hat, freue ich mich, wenn ihr mir die korrekte Syntax mitteilt.

Erstes Fazit

Das ging leichter als gedacht. Die benötigten Module waren schnell gefunden und ihre Anwendung aufgrund der hinreichend guten Dokumentation nicht schwierig.

Da die aktuell genutzten Variablen sensible Informationen beinhalten, möchte ich diese zukünftig mit Ansible Vault schützen.

Stand heute bin ich jedoch erstmal in der Lage meinen Blog aus der Datensicherung heraus erneut deployen zu können.

Chemnitzer Linux-Tage 2018 — Jeder fängt mal an.

Am 10. und 11. März 2018 finden fanden die Chemnitzer Linux-Tage (#clt2018) statt. Das Motto lautet in diesem Jahr lautete: „Jeder fängt mal an.“


Auch an dieser Stelle nocheinmal vielen Dank an die Veranstalter der #CLT2018 und die Hörer meines Vortrags „Webseiten mit HTTPS bereitstellen und mit HSTS sichern“. Die Folien zum Vortrag findet ihr auf der Seite Artikel und Vorträge sowie hinter diesem Direktlink.

Zum Ende meines Vortrags habe ich auf weitere Maßnahmen hingewiesen, mit denen sich die Angriffsfläche auf HTTPS verkleinern lässt. Weitere Informationen dazu findet ihr auf dieser Seite im Artikel „Über Pinning (HPKP), CAA und Certificate Transparency“.


Die Besucher erwartet in diesem Jahr erneut ein prall gefülltes Vortragsprogramm mit bis zu sieben parallel laufenden Tracks. War ich im vergangenen Jahr als Besucher zu Gast, steuere ich in diesem Jahr den Vortrag „Webseiten mit HTTPS bereitstellen und mit HSTS sichern“ bei. In diesem führe ich in das Thema HTTPS und die Internet-PKI ein und weise auf einige Stolpersteine hin, die auf dem Weg lauern.

Neben vielen interessanten Vorträgen werden an beiden Tagen jeweils sechs Workshops zum Lernen und Mitmachen angeboten. Für die Teilnahme ist eine Anmeldung erforderlich und es sind 5 Euro Teilnahmegebühr zu entrichten. Beeilt euch bei Interesse mit der Anmeldung, denn die Plätze sind begrenzt.

Darüber hinaus erwarten euch auf den CLT2018:

Die Praxis Dr. Tux bietet in ihrer Sprechstunde bei allen Problemen Hilfestellung, die der Anwender nicht alleine lösen kann.

Im Business Forum stellen sich bis zu 15 Open-Source-Firmen kurz vor. Hört entspannt zu, was diese Firmen genau tun, stellt Fragen und beteiligt euch an der Diskussion.

Auf der PGP-Party könnt ihr eure öffentlichen Schlüssel-Dateien signieren lassen. Weitere Informationen zur Vorbereitung und Durchführung findet ihr unter vorstehendem Link.

Retro Gaming wird während der Chemnitzer Linux-Nacht geboten. Ab 19:30 Uhr könnt ihr auf der Atari 2600 zeigen, aus welchem Holz ihr geschnitzt seid!

In der Projektküche präsentieren 15 Personen in jeweils fünf Minuten ihre Open-Source-Projekte. Möchtet ihr selbst euer Projekt vorstellen? Dann Beeilung, Anmeldeschluss ist der 1. März 2018.

Es wird also wieder viel geboten. Und neben den spannenden und interessanten Vorträgen freue ich mich natürlich auch, bekannte Gesichter wiederzusehen und abends über alte Zeiten zu plaudern. Bis neulich.