Bilder & Videos fürs Blog

Von Zeit zu Zeit will man in einem Blog Bilder und Videos veröffentlichen. Dabei würde ich gerne manches unter Kontrolle behalten. Deshalb dieser kurze Artikel, der einige Tricks verraten soll.

Bilder

Bilder erstelle ich inzwischen eigentlich immer mit einer Handy-Kamera. Dabei werden inzwischen über die Exif-Daten viele Informationen preis gegeben. Mobiltelefone fügen hier auch gerne Felder ein, die nicht jeden etwas angehen:

  • GPS Position der Aufnahme,
  • Informationen über das Gerät und
  • viele weitere

Einsehen kann man die Exif-Daten eines Fotos mit:

identify -verbose $BILD

Die Exif-Daten können (und sollten) mit folgendem Kommando entfernt werden:

convert $IN -strip $OUT

Für das Blog ist es ab und zu notwendig ein Bild in der Größe zu reduzieren (hier auf 50%):

covert $IN -resize 50% $OUT

Alternativ ist auch die Angabe der Größe in Pixeln (kann das Bild vergrößern):

covert $IN -resize 600@ $OUT

In beiden Fällen werden die Seitenverhältnisse bei behalten.

Videos

Da bei meinen Videos der Ton keine Rolle spielt, wird dieser mit folgendem Befehl entfernt:

ffmpeg -i $INPUT -an $OUTPUT

Oft möchte man das Video nach der Aufnahme um 90 Grad im Uhrzeigersinn drehen (transpose=2 für 90 Grad gegen den Uhrzeigersinn):

ffmpeg -i $INPUT -filter:v transpose=1 $OUTPUT

Einzelbilder können mit folgendem Kommando extrahiert werden:

ffmpeg -i $INPUT -ss $second -vframes 1 $OUTPUT.png

Einen Ausschnitt aus einem Video kann man mit folgendem Kommando erstellen:

ffmpeg -i $INPUT -filter:v crop=$WIDTH:$HEIGHT:$X:$Y $OUTPUT

Anschließend verwandelt man das Video in webm mit einer Bandbreite von 1 Mbit/s  (welches in WordPress direkt abgespielt werden kann):

ffmpeg -i $INPUT -vcodec libvpx-vp9 -b:v 1M $OUTPUT$.webm

 

FPGA: Erste Schritte

Um mal wieder über den berühmten Tellerrand zu blicken will ich mich mal mit etwas neuem beschäftigen. Die Wahl fiel auf FPGAs. Während des Studiums habe ich mich leider durch Wahl eines alternativen Praktikums um eine erste Erfahrung gebracht.

Für einen ersten Einstieg benötigt man nur Software, keine Hardware. Die Software (zumindest von Intel/Altera kann man gratis herunterladen. Dazu unten mehr. Da ich das am Anfang nicht wusste, habe ich über Amazon die im Folgenden genannten Produkte erworben.

Einkauf

Gesamtkosten: keine 30€, da der Klon deutlich günstiger als das Original mit fast 400€ ist.

Erste Erfahrungen

Zunächst sollen einige wichtige Erkenntnisse aufgeführt werden. Zu den beiden genannten Softwarepaketen:

  1. Der Cyclone II wird bis maximal Quartus II Web Edition 13.0sp1  unterstützt. Diese kann kostenlos mit einem myAltera-Account heruntergeladen werden (4.8GB). Nach der Installation sind es ca. 16 GB, wobei man hier beim Installationsumfang sicher sparen kann. Neuere Versionen unterstützen nur neuere FPGAs. Gestartet wird das Programm auf 64-bit Systemen über ./bin/quartus –64bit aus dem Installationsverzeichnis.
  2. JTAG einrichten: unter Ubuntu 17.10 benötigt man zusätzliche udev-Regeln (Datei /etc/udev/rules.d/usbblaster.rules):
    SUBSYSTEM=="usb",ATTR{idVendor}=="09fb",ATTR{idProduct}=="6001",MODE="0666"
    SUBSYSTEM=="usb",ATTR{idVendor}=="09fb",ATTR{idProduct}=="6002",MODE="0666"
    SUBSYSTEM=="usb",ATTR{idVendor}=="09fb",ATTR{idProduct}=="6003",MODE="0666"
    SUBSYSTEM=="usb",ATTR{idVendor}=="09fb",ATTR{idProduct}=="6010",MODE="0666"
    SUBSYSTEM=="usb",ATTR{idVendor}=="09fb",ATTR{idProduct}=="6810",MODE="0666"

    Diese ermöglichen den Zugriff auf für nicht root Nutzer. Anschließend kopiert man die Board-Descriptions nach /etc/jtagd:

    cp $INSTALLDIR/linux64/pgm_parts.txt /etc/jtagd/jtagd.pgm_parts
    

    Weiter Informationen findet man unter bitsnbites.eu.

  3. Mit ModelSim-Intel FPGA Edition 10.5c kann man auch im myAltera-Account herunterladen (3.1GB). Nach der Installation sind es ca. 7 GB. Vor dem Starten wird noch die Bibliothek freetype in Version 2.4.12 benötigt. Hinweise zur Installation liefert das Armadeus Project Wiki und ein Blog. Gestartet wird anschließend mit ./bin/vsim aus dem Installationsverzeichnis.

Spezifisch zu dem Basisboard gibt es noch folgendes zu sagen:

  1. Das Basisboard muss mit 5V über den entsprechenden Anschluss versorgt werden, sonst wird es nicht über den USB Blaster beim JTAG Scan erkannt. Hierbei liegen die 5V innen an! Es handelt sich um einen 2.1mm/5.5mm Hohlstecker. Update: Die Stromversorgung ist auch über P8 möglich, hier ist der 5V Pin weiter in Richtung Platinenmitte und GND Richtung Rand platziert.
  2. Wichtige Pins sind wie folgt belegt:
    Pin-NummerPin-Funktion
    Pin 3D2 (LED, Output)
    Pin 7D4 (LED, Output)
    Pin 9D5 (LED, Output)
    Pin 17CLK (50 MHz, Input)
    Pin 144Taster (Input)
    Pin 7310uF nach GND, 10K an Vcc
    Pin 26an 1.2V VCC angeschlossen
    Pin 27an GND angeschlossen
    Pin 80an GND angeschlossen
    Pin 81an 1.2V VCC angeschlossen
    Hier ist beim Anschluss von an weiterer Hardware entsprechend Vorsicht geboten.
  3. Der Schaltplan des Basisboards befindet sich u.a. hier:

    Schaltplan des Basisboards (Quelle: http://artofcircuits.com)

Erstes Projekt

Wir starten Quartus II und wählen den “New Project Wizard“. Zunächst wird das Projekt benannt:

Erster Schritt des Wizards

Anschließend kann man bereits existierende Dateien hinzufügen (wir haben allerdings noch keine):

Schritt 2 des Wizards

Die Auswahl des FPGAs (hier die Selektion für den FPGA auf dem Basisboard):

Schritt 3 des Wizards

Einige Informationen über den vorhandenen FPGA werden hier auch aufgezählt:

  • 8256 LEs (Logic Elements) sind die Basisbausteine, im Detail beschrieben auf Seite 2-2 im Cyclone II Architecture Dokument. Jeweils 16 davon werden zu einem LAB (logic array block) zusammengefasst (516 sind vorhanden).
  • 85 User I/Os (Ein/Ausgänge, die für den Entwickler verfügbar sind)
  • 165888 Bit Speicher in 36 M4K Blöcken
  • 36 9×9-Bit Mulitplizierwerke oder alternativ 18 18×18 Multiplizierwerke
  • 2 PLLs
  • 8 globale Takte

Nun hat man ein leere Projekt erzeugt. Mit  “File” und “New” erstellt man eine neue VHDL Datei.

library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
 
entity vhdl_example_1 is
 port( 
  clk: in std_logic;
  led: out std_logic
 );
end vhdl_example_1;
  
architecture bhv of vhdl_example_1 is
 signal count: integer := 1;
 signal tmp: std_logic := '0'; 
begin
 process(clk) begin
  if(clk'event and clk = '1') then
   count <= count + 1;
   if (count = 25000000 ) then
    tmp <= NOT tmp;
    count <= 1;
   end if;
  end if;
  led <= tmp;
 end process;
end bhv;

Diese speichert man unter dem Namen vhdl_example_1.vhd ab. Mit Processing und Start Compilation kann man das Übersetzen starten. Unter Assigments und Pin Planner starten wir die Zuordnung der unter Port definierten Ein-/Ausgänge. Folgende Zuordnung muss vorgenommen werden:

  • clk auf Location PIN 17
  • led auf Location PIN 3
Ausschnitt der konfigurierten Pins

Als letzten Schritt muss der FPGA noch ueber den JTAG Anschluss programmiert werden. Dazu verwendet man den unter Tools den Programmer. Zunächst wählt man unter Hardware Setup den USB-Blaster aus. Als Datei fügt man  output_files/vhdl_example_1.sof hinzu und als Device den FPGA des Basisboards. Anschließend kann man mit Start die Programmierung starten.

Einstellungen im Programmer

Sollte dies nicht (mehr) funktionieren, kann es helfen den USB-Blaster kurz vom USB zu trennen.

Hat alles funktioniert, sollte die LED D2 mit 1Hz blinken:

Update 2. März 2018 zum Thema alternative Stromversorgung.

Update 31. März 2018 zum Thema JTAG einrichten

Thread Dumps – auch für Python

Thread Dumps sind Momentaufnahmen des Aufruf-Stacks für jeden Thread einer laufenden multi-thread Anwendung. Dies ist in vielen Situationen zur Analyse hilfreich. Diese gestaltet sich gerade bei multi-thread Anwendung meist komplizierter.

Für Java gibt es das Programm jstack (u.a. mit jps im JRE enthalten) um Thread Dumps zu erzeugen.

Unter Python kann ein ähnliches Verhalten (getestet unter Linux) mit einem kleinen Umweg über einen Signal-Handler erreicht werden:

...
import faulthandler 
import signal
import os
...

def handler(signum, frame):
  file ='/tmp/threads'
  print('Writing thread dump to ', file)
  with open(file, 'w') as f:
    faulthandler.dump_traceback(file=f, all_threads=True)

...
if __name__ == '__main__':
  with open('/tmp/pid', 'w') as f:
    f.write(str(os.getpid()))
  signal.signal(signal.SIGUSR1, handler)
  ...

Nach dem Starten des Programms kann man über die PID aus /tmp/pid einen Thread Dump erzeugen:

kill -USR1 `cat/tmp/pid`

Dieser sieht exemplarisch so aus (extra in kleinerer Schriftart um die Zeilen ohne Umbrüche zu erhalten):

Thread 0xb3ccb460 (most recent call first):
 File "/home/jlusiardi/.local/lib/python3.4/site-packages/zeroconf.py", line 1102 in run
 File "/usr/lib/python3.4/threading.py", line 920 in _bootstrap_inner
 File "/usr/lib/python3.4/threading.py", line 888 in _bootstrap

Thread 0xb44ff460 (most recent call first):
 File "/usr/lib/python3.4/socketserver.py", line 154 in _eintr_retry
 File "/usr/lib/python3.4/socketserver.py", line 236 in serve_forever
 File "/home/jlusiardi/sources/smarthome/homekit_link/__init__.py", line 142 in run
 File "/usr/lib/python3.4/threading.py", line 920 in _bootstrap_inner
 File "/usr/lib/python3.4/threading.py", line 888 in _bootstrap

Thread 0xb4cff460 (most recent call first):
 File "/home/jlusiardi/sources/smarthome/influxdb/__init__.py", line 109 in run
 File "/usr/lib/python3.4/threading.py", line 920 in _bootstrap_inner
 File "/usr/lib/python3.4/threading.py", line 888 in _bootstrap

Thread 0xb6025460 (most recent call first):
 File "/usr/lib/python3.4/socketserver.py", line 154 in _eintr_retry
 File "/usr/lib/python3.4/socketserver.py", line 236 in serve_forever
 File "/home/jlusiardi/sources/smarthome/homematic/callback.py", line 42 in run
 File "/usr/lib/python3.4/threading.py", line 920 in _bootstrap_inner
 File "/usr/lib/python3.4/threading.py", line 888 in _bootstrap

Current thread 0xb6fb6300 (most recent call first):
 File "./main.py", line 19 in handler
 File "/usr/lib/python3.4/cmd.py", line 126 in cmdloop
 File "/home/jlusiardi/sources/smarthome/cli/__init__.py", line 32 in cmdloop
 File "./main.py", line 50 in <module>

Auch hier bieten sich verbesserte Analysemöglichkeiten analog zu Java.

Influxdb und Grafana

Aus meinem beruflichen Umfeld ist mir Grafana als Lösung zur grafischen Aufbereitung gut bekannt. Daten beziehen wir klassisch aus Graphite.

Für ein Projekt habe ich nun die Daten über öffentliches Netz (also das Internet) in die Datensenke einliefern müssen. Zunächst auch hier an Graphite gedacht, jedoch ergab sich schnell die Überlegung, das der Graphite Port 2003 (hier lauscht der Carbon Daemon) jedwede Daten ohne Authentifizierung annimmt. In einem  öffentlichen Netz sicher kein akzeptabler Zustand, da hier jeder mit Kenntnis von Port und IP beliebige Stördaten einliefern kann. Also auf die Suche nach Alternativen.

InfluxDB bietet laut db-engines.com  als Berechtigungskonzept mit einer “einfache[n] Rechteverwaltung mit Benutzeraccounts” mehr als Graphite. Auch verspricht die Implementierung in Go mehr Performance. Grund genug, sich InfluxDB näher anzusehen.

InfluxDB

Dank des offiziellen Docker Images ist InfluxDB schnell probeweise gestartet. Hinweise liefert die Seite des Docker-Hub. Zunächst wird die Standardkonfiguration extrahiert:

docker run --rm influxdb influxd config > influxdb.conf

In dieser Datei muss die Option auth-enabled nun aktiviert werden:

...
[http] 
...
auth-enabled = true
...

In Kombination mit meinen beiden Projekten docker_nginx_auto_proxy und docker_ssl_endpoint kann man nun einen Docker Container starten, der Daten über TLS abgesichert entgegen nimmt:

docker run --name=influxdb_1 -d \
 -e PROXY_DATA=server_names:$INFLUXDOMAIN,port:8086 \
 -v /data/influxdb/data:/var/lib/influxdb \
 -v /data/influxdb/conf:/etc/influxdb/influxdb.conf:ro \
 influxdb -config /etc/influxdb/influxdb.conf

Nun müssen wir mindestens einen Admin-Nutzer anlegen. Zunächst verbinden wir uns auf die InfluxDB-CLI:

docker run --rm --link=influxdb_1 -it influxdb influx -host influxdb_1

Anschließend legt folgendes Statement den Admin-Nutzer bofh an:

CREATE USER bofh WITH PASSWORD 'rrzs42' 
  WITH ALL PRIVILEGES

Anschließend die CLI beenden und beim Neuverbinden zusätzlich die Parameter username und password zur Authentifizierung verwenden. Weitere Informationen zur Nutzerverwaltung von InfluxDB findet man in der offiziellen Dokumentation.

Eine Datenbank sollte in der CLI ebenfalls erstellt werden:

CREATE DATABASE datensenke

Testweise können nun bereits Daten eingeliefert werden:

curl -X POST -u bofh:rrzs42 \
  --data-binary 'wert,key=value wert=42.23'\
  'https://$INFLUXDOMAIN/write?db=datensenke'

Die genaue Beschreibung über das Schreiben von Daten findet man in der offiziellen Dokumentation.

Grafana

Für Grafana gibt es ebenfalls ein offizielles Docker-Image. Der erste Schritt ist das Extrahieren der Konfiguration:

docker run --rm --name grafana grafana/grafana
docker cp grafana:/etc/grafana/grafana.ini .

Die wichtigste Anpassung der Konfiguration bezieht sich auf das Abschalten des selbständigen Anmeldens neuer Nutzer (allow_sign_up = false in der Kategorie users). Somit ist nur noch der Administrator (Login: admin) in der Lage, neue Nutzer anzulegen.

Gestartet wird der Grafana-Container mit folgendem Kommando:

docker run --name=grafana -d \
    -e PROXY_DATA=server_names:$GRAFANADOMAIN,port:3000 \
    -v /data/grafana/lib:/var/lib/grafana/ \
    -v /data/grafana/conf:/etc/grafana/grafana.ini \ 
    -e "GF_SERVER_ROOT_URL=https://$GRAFANADOMAIN" \
    -e "GF_SECURITY_ADMIN_PASSWORD=s3cr3t" \
    grafana/grafana

Nun kann die Grafana-Instanz unter  https://$GRAFANADOMAIN aufgerufen werden und der Login funktioniert mit den Credentials admin:s3cr3t.

Der nächste Schritt sollte das Ändern des Passworts des Administrators sein und das Anlegen neuer Nutzer sein. Dies geschieht unter Grafana-MenuAdminGlobal Users.

Um wie die Daten aus InfluxDB in Grafana nutzen zu können, legt man eine Datenquelle unter Grafana-MenuData Sources an. Die Einstellungen für InfluxDB sind in unserem Fall:

  • Type: InfluxDB
  • URL: https://$INFLUXDOMAIN
  • Access: Proxy
  • Http Auth: With Credentials
  • InfluxDB Details:
    • Database: datensenke
    • User: bofh
    • Password: rrzs42

Jetzt sind wir in der Lage, über Dashboards wie gewohnt Graphen an zu legen. Beispielsweise:Et voilà, flexible und ansehnliche graphische Aufbereitung von Zeitseriendaten.

ioBroker: Ergänzung zu Open Source Hausautomatisierung im Vergleich

Im Artikel zu Open Source Hausautomatisierungslösungen wurden bereits einige Lösungen verglichen. Auf der diesjährigen 17. Gulaschprogrammiernacht  hat Bluefox ein weiteres System vorgestellt: ioBroker

ioBroker soll nun an den gleichen Kriterien wie die anderen 7 Systeme gemessen werden:

  1. Die Software muss quell-offen und frei sein (OpenSource)
  2. Dokumentation auf Englisch bzw. Deutsch und in ausreichenden Qualität und Detailtiefe vorhanden (Dokumentation)
  3. Größe der Community
  4. Support für Komponenten von eQ-3 für Homematic und Homematic IP (Hardware-Unterstützung), da diese bereits vorhanden ist.
  5. Apps für iOS bzw. Android (Apps)
  6. Verwendete Programmiersprachen & Technologien (Technologie)
  7. Die Software muss Graphen zur historischen Analyse von Messwerten bieten (Graphen)
  8. Die Software muss über Regeln erweiterbar sein, z.B. Verknüpfung von Schalter, Reaktion aufs Verlassen der Wohnung (Regeln)

ioBroker ist ein bei Github gehostetes OpenSource-Projekt unter MIT-Lizenz und basiert auf Node.js, einer Server-seitigen Implementierung von JavaScript.

Anleitungen zur Installation sind auf Deutsch, Englisch und Russisch vorhanden. Allerdings sollten die Autoren hier noch etwas Zeit investieren und Fehler ausbessern, da diese den Lesefluss beeinflussen.

Laut dem Vortrag von Bluefox (Videomitschnitt exisitiert) wächst die Community von ioBroker rasant an. Dazu trägt sicher auch bei, dass bereits eine Integration für Amazon Alexa existiert, was das Gesamtsystem deutlich smarter erscheinen lässt.

Homematic und Homematic-IP werden laut Forum unterstützt. Auch scheint Anwesenheitserkennung über Fritz!Box und das Steuern von Samsung TV Geräten unterstützt zu werden.

Wichtig sind natürlich auch Apps für:

Da ioBroker auf Node.js basiert kann beim Entwickeln sowohl Front- als auch Backend  in einer Sprache entwickelt werden. Daten werden sowohl in relationalen Datenbanken (MySQL, PostgreSQL oder SQLite) als auch in InfluxDB für zeitbasierte Daten abgelegt. Die transparenten Verbindungen über TCP erlauben es hierbei, Teile der Software modular auf mehreren Hosts zu betreiben.

Zur Visualisierung bietet ioBroker einen Editor, der komplett im Browser läuft. Hierbei werden unterschiedliche Darstellungen für Zielgeräte angeboten.  Diese Funktionalität wird über den VIS-Adapter bereit gestellt. Graphen stellt das System hierbei über den Flot-Adapter dar.

Zur Eigentlichen Automatisierung bietet ioBroker das Definieren von Szenen über den Szenen-Adapter aber auch das Erstellen komplexer über Adapter für Blockly und node-red.

Zusätzlich zu den, für den Vergleich wichtigen, Punkten bietet eine Integration in Apples Homekit. Diese ist ebenso ein Pluspunkt wie auch der optionalen Clound-Zusatz, der einen Zugriff aus der Ferne auch ohne eigenes VPN ermöglicht.

Alles in Allem ist ioBroker eine weitere Software mit guten Ansätzen, die ich aber aus Zeitgründen und da ich weder mit Node.js noch Javascript besonders viel Erfahrung besitze, nicht weiter betrachten werde.

UML mit PlantUML

PlantUML ist ein ein GPL Tool zur Erstellung von folgenden UMLDiagramm Typen aus reinen Text-Dateien:

  • Klassendiagramm (class diagram)
  • Sequenzdiagramm (sequence diagram)
  • Objektdiagramm (object diagram)
  • Anwendungsfalldiagramm (use case diagram)
  • Aktivitätsdiagramm (activity diagram)
  • Komponentendiagramm (component diagram)
  • Zustandsdiagramm (state diagram)
  • Deploymentdiagramm (deployment diagram) BETA (Stand 1. April 2017)
  • Zeitverlaufsdiagramm (timing diagram) BETA (Stand 1. April 2017)

Verwendbar ist PlantUML entweder online über einen Demo-Bereich oder lokal über eine JAR-Datei. Für ein lokales Ausführen braucht man Java und die Graphviz-Software.

Zusätzlich bietet das Plugin PlantUML integration von Eugene Steinberg (erhältlich für alle IntelliJ IDEA basierenden Produkte) eine Integration in meine Lieblings-IDE. Features sind unter anderem:

  • Syntax Highlighting
  • Autocompletion bereits definierter Elemente
  • Parallele Darstellung von Definition und Ergebnisgrafik

Kleines Beispiel aus meinem aktuellen Projekt:

@startuml

package modes {
    interface Mode {
     + handle_input(code): Mode
     + display(device)
     + handle_mpd(data)
     + activate()
    }

    class ModeProxy {
      current_mode
     + handle_input(code): Mode
     + display(device)
     + handle_mpd(data)
    }

    class MenuMode <<Singleton>> {

    }

    ModeProxy ..|> Mode

    MenuMode ..|> Mode
    MenuMode -->"*" Mode : "topics"
}
@enduml

und das zugehörige Bild:

Ergebnis der Demo Datei
Ergebnis der Demo Datei

Fazit: Ein gutes Tool mit einigen Vorteilen (z.B. einfache Versionierung der Eingabedateien) unter einer der richtigen Lizenzen, welches nicht nur in IntelliJ und Co verwendet werden kann sondern in einer Vielzahl weiterer Tools.

Dynamische IP – Reagieren auf Änderungen

Als DSL Nutzer kommt man hierzulande meist nicht in den Genuss einer statischen IPv4 Adresse sondern bekommt regelmäßig eine andere IPv4 von seinem Provider zugewiesen. Als Nebeneffekt wird dadurch das Anbieten von Serverdiensten an Heimanschlüssen oder auch der Betrieb eines IPv6 Tunnels erschwert.

Die FRITZ!Box bietet Unterstützung für einige DDNS-Provider, manchmal möchte man aber auch einfach ein Skript ausführen. Den möglichen Anwendungen sind kaum Grenzen gesetzt.

Über Dienste wie https://icanhazip.com/ kann man sich seine öffentliche IP-Adresse, die zum Abrufen der Seite verwendet wurde, einfach anzeigen lassen und auch in Skripten verwenden. Möchte man die Aktualisierungen wirklich nur dann ausführen, wenn sich die IP geändert hat, so kann das Skript react_to_ip_change.sh helfen. Zu finden ist es im GIT.

Im wesentlichen Skript vergleicht das Skript eine gespeicherte IP mit der aktuell von https://icanhazip.com/ zurück gelieferten. Unterscheiden die beiden sich, so werden alle Skripte in /usr/local/etc/ipchange.d/ ausgeführt.

Kombiniert man das mit Cron, so aktualisiert man die eigene IP zeitnah in allen relevanten Systemen:

# m h dom mon dow command
* * * * * /usr/local/bin/react_to_ip_change.sh

Noch mal der Link zum GIT: https://code.nerd2nerd.org/n0ob/react_to_ip_changes

Mounten von Partitionen aus Image-Dateien

Ist das Backup einer SD-Karte nur als Image-Datei vorhanden und keine Zeit erst wieder auf SD-Karte zu schreiben? Dateimanager kann Image-Dateien nicht direkt einbinden? Hier die Lösung:

  1. Auslesen der Partitionen und ihrer Startsektoren:
    fdisk -l ${QUELLDATEI}

    (Hier in der Spalte Start nach dem Anfang der Partition suchen, unter Units steht die Größe der Sektoren)

  2. Einbinden der gewählten Partition:
    mount ${QUELLDATEI} /mnt -o offset=$((${ANFANGSSEKTOR}*${SEKTORGRÖßE}
  3. Und fertig!

 

Icinga2 mit Docker

Aus diversen Gründen hatte ich Bedarf nach einen Icinga2 Setup inklusive icingaweb2.

Einleitung

Wichtige Anforderungskriterien waren:

  • Alarmierung über Mails ist möglich
  • Neuste Versionen zum Testen
  • Docker-typische “Separation of Concerns” und nicht “alles in einen Container”

Images wie icinga/icinga2 oder jordan/icinga2 konnten entweder nicht alle Features oder waren Monolithisch angelegt. Muss man einen monolithischen Container, der seine Datenbank enthält, durch eine neue Version ersetzen, sind die Daten (ohne zusätzlichen Aufwand) verloren.

Also doch ein eigenes Image, oder besser gleich 2:

docker_icinga2_core

Das docker_icinga2_core-Image bietet folgende Features:

  • Ausführen des icinga2 Daemons und der Plugins aus monitoring-plugins-standard
  • Volume zum Ablegen der Icinga2-Konfiguration außerhalb des Containers
  • Versand von Alarm-Benachrichtigungen über einen Smarthost (z.B. gmail, siehe hierzu GmailAndExim4)
  • Speicherung der aktuellen Konfiguration und Statusinformationen in einer MySQL (IDO)
  • Integrierte Kommandozeilenoption zum einmaligen Einrichten der IDO-Datenbank mit passendem Schema
  • (Optionale) Anbindung von Graphite zur Speicherung der Messdaten und Aufbereitung als Graphen
  • (Optionale) Bereitstellung der Icinga2-API für andere Container auf Port 5665

docker_icinga2_web

Das docker_icinga2_web-Image bietet folgende Features:

  • Zugriff auf icingaweb2 über Container-Port 80 (eventuell empfiehlt sich der Einsatz von docker_nginx_auto_proxy)
  • Steuerung des icinga2_core über die Icinga2-API
  • Die aktuellen Statusinformationen werden der IDO Datenbank entnommen
  • Festlegung der berechtigten Nutzer finden über eine Auth Datenbank statt

Deployment

Darstellung der Zusammenhänge der einzelnen Komponenten

Weitere Informationen zum Starten der einzelnen Container finden sich in den Git-Repositories zu docker_icinga2_core und docker_icinga2_web.

Fazit

Das Container-Duo läuft nun seit einigen Tagen auf meinem NAS und überwacht diverse interne Geräte sowie einige externe Dienste und meldet mir deren Ausfall zeitnah per Mail. Graphite und/oder Grafana ist noch nicht aktiv angebunden ist aber während der Testphase verprobt worden.

Update 29. November 2017

Auf Wunsch eines meines Lesers Patrick finden sich die Quellen für die beiden Container unter:

Warnung: ist nicht explizit erneut geprüft und kann Fehler enthalten. Benutzen auf eigenes Risiko ;)

Debian Pakete bauen im Docker-Container

Leider gibt es wohl für Debian 8 Jessie kein (aktuelles) Netatalk gibt, hier eine kleine Beschreibung wie man sich mit Docker und checkinstall ein entsprechendes Paket selber erstellen kann, ohne seinen Host mit den zur Paketerstellung notwendigen Abhängigkeiten zu belasten. Als Einstieg diente mir das Wiki von Netatalk und das Blog von Daniel Lange.

Zunächst das Dockerfile:

# Wir wollen das Paket später auf Debian 8 einsetzen. Andere 
# Distributionen sind analog möglich
FROM debian:8

# Update der Paketbasis und Installation der benötigten Abhängigkeiten
RUN apt-get update -y; \
    apt-get install -y build-essential \
        devscripts debhelper cdbs autotools-dev dh-buildinfo \
        libdb-dev libwrap0-dev libpam0g-dev libcups2-dev libkrb5-dev \
        libltdl3-dev libgcrypt11-dev libcrack2-dev \
        libavahi-client-dev libldap2-dev libacl1-dev \
        libevent-dev d-shlibs dh-systemd wget libtdb-dev checkinstall

# Quellcode beziehen und extrahieren
RUN wget http://prdownloads.sourceforge.net/netatalk/netatalk-3.1.10.tar.bz2; \
    tar xvf netatalk-3.1.10.tar.bz2

Anschließend bauen wir das Docker-Image:

docker build --tag=docker_build_netatalk .

Auführen mit:

docker run -v /tmp:/target --rm -ti docker_build_netatalk

Im Container dann folgendes durchführen:

$ cd netatalk-3.1.10
$ ./configure \
    --with-init-style=debian-systemd \
    --without-libevent \
    --without-tdb \
    --with-cracklib \
    --enable-krbV-uam \
    --with-pam-confdir=/etc/pam.d \
    --with-dbus-daemon=/usr/bin/dbus-daemon \
    --with-dbus-sysconf-dir=/etc/dbus-1/system.d \
    --with-tracker-pkgconfig-version=1.0
$ make
# Legt einige Verzeichnisse an, wird ja eh weggeworfen
$ make install 
$ checkinstall \
    --default \
    --install=no \
    --requires="libtdb1,libcrack2"
# Benutze cp oder scp, um das erzeugte Paket zu sichern
$ cp /netatalk-3.1.10/netatalk_3.1.10-1_amd64.deb /target
$ exit

Nach dem Ende löscht sich der Container dank –rm selbst und wir haben mit netatalk_3.1.10-1_amd64.deb ein schönes Debian-Paket, welches auch sauber wieder entfernt werden kann.