Nichts einfacher als :

# vi /usr/local/bin/cpu-temp-mqtt.sh

!/usr/bin/env bash
MQTT_SVR="IP.OF.THE.SRV"
TOPIC="server/status/${HOSTNAME}/cpu"
CPU=$(</sys/class/thermal/thermal_zone1/temp)
CPU=$((CPU/1000))
MESSAGE="${CPU}"
mosquitto_pub -h $MQTT_SVR -t $TOPIC -m $MESSAGE -q 1
exit 0

Dann noch die Datei ausführbar machen und via crontab regelmäßig aufrufen:

# chmod +x /usr/local/bin/cpu-temp-mqtt.sh
# crontab -e

# m h  dom mon dow   command
*/10 * *   *   *     /usr/local/bin/cpu-temp-mqtt.sh

... und den Service neu starten:

#service cron restart

... SD-Karte kaputt geschrieben - Crash - und was dagegen tun?

Ein Jeder, der seinen Home-Server mittels Raspberry Pi in Betrieb hat und dieser dann (hoffentlich) seit einiger Zeit störungsfrei in Betrieb ist, wird irgendwann vom Schicksal eingeholt:

CRASH !!

Man/frau wird den Pi noch einmal starten und glücklich sein, dass er wieder hochläuft. Aber ein ungutes Gefühl bleibt zurück. Warum ist er abgestürzt? Kann dies wieder passieren? Was, wenn die Daten verloren gehen? Liegt es wirklich daran, dass die SD-Karten kaputt-geschrieben werden?

Ursachenforschung:

Wir schauen uns zunächst einmal ein paar Daten an, dann entscheiden wir: Bedauerlicherweise gibt es kein allgemein gültiges Tool, mit dem man die Lebensparameter einer SD-Karte auslesen könnte, ähnlich dem SMART-System einer SSD.

Mit dem Tool dumpe2fs können wir uns aber vom Root-Dateisystem ein paar Informationen einholen:

# dumpe2fs /dev/mmcblk0p2 | grep Lifetime
dumpe2fs 1.44.5 (15-Dec-2018)
Lifetime writes:          35 GB

OK !!! Das ist eine Aussage! Innerhalb des "Lebenszyklus" dieses Dateisystem wurden bereits 35 GB geschrieben. Das ist viel, zu viel? Und, wie alt ist dieses Dateisystem eigentlich?

# dumpe2fs /dev/mmcblk0p2 | grep created
dumpe2fs 1.44.5 (15-Dec-2018)
Filesystem created:       Wed Dec  2 13:55:23 2020

# dumpe2fs /dev/mmcblk0p2 | grep "Last mount"
dumpe2fs 1.44.5 (15-Dec-2018)
Last mounted on:          /
Last mount time:          Wed Aug  4 17:17:01 2021

Entscheidend sind hier also die Differenz zwischen der "created"-Zeit und "Last mounted"-Zeitpunkt. Dies sind hier gerade einmal acht Monate. Definitiv zu viele GB pro Monat !!!

Frage also: Wer schreibt und warum so viel? Nun, hier hilft uns ein Programm iotop:

# iotop -aok

Dies lassen wir dann mal für einige Minuten laufen und kontrollieren:

Total DISK READ:         0.00 K/s | Total DISK WRITE:         0.00 K/s
Current DISK READ:       0.00 K/s | Current DISK WRITE:       0.00 K/s
TID  PRIO  USER   DISK READ  DISK WRITE  SWAPIN     IO>    COMMAND
1674 be/4 root      0.00 K     28.00 K  0.00 %  0.21 % portainer
83 be/3 root        0.00 K    172.00 K  0.00 %  0.13 % [jbd2/mmcblk0p2-]
591 be/4 root       0.00 K      4.00 K  0.00 %  0.00 % nmbd --fo~cess-g
643 be/4 root       0.00 K     16.00 K  0.00 %  0.00 % svlogd -t~/log/
887 be/4 root       0.00 K     24.00 K  0.00 %  0.00 % gammu-sms~d --dae
13062 be/4 roo      0.00 K     44.00 K  0.00 %  0.00 % rsyslogd ~ain Q

Hier wird also reichlich geschrieben. Nun, das Logging ist eine gute Lösung zur Fehlersuche, aber wenn das System erst mal läuft, wer kontrolliert dann permant die Logs? Ich nicht, dienstlich ja, meistens, aber privat? Also möchte ich, dass so wenig wie möglich geloggt wird. Die große Keule schwingen wir in der Datei:

# vi /etc/rsyslog.conf

###############
#### RULES ####
###############

*.*         ~           # keine LOGS MEHR SCHREIBEN

Also direkt unter der Rubrik RULES setzen wir den Filter, der dann alles erst einmal killt. Dann noch den rsyslogd neustarten und es herscht erstmal Ruhe.

# service rsyslog stop
# service rsyslog start

Sollte man das Logging zur Fehlersuche wieder benötigen, kann man die Schritte leicht wieder rückgängig machen.

Und so sollte die SD-Karte DEUTLICH länger halten, bis zum nächsten Crash.

Einfaches HOWTO zur Einrichtung des lokalen Netzwerk-Routing nach der
Installation von OpenVPN

Damit nach der erfolgreichen Installation von OpenVPN nicht nur der (OpenVPN)
Server erreichbar ist, sondern auch andere Hosts im Netzwerk erreicht werden
können, muss

(1) das Routing freigeschaltet werden
(2) die Firewall-Regeln ergänzt werden
(3) die neuen, nicht gespeicherten Regeln für den nächsten Reboot gesichert
werden

(1) generelles Routing freischalten:

vi /etc/sysctl.conf

In dieser Datei das Kommentarzeichen für diese Zeile entfernen, um die
Paketweiterleitung für IPv4 zu ermöglichen:

net.ipv4.ip_forward=1

service networking restart

(2) Firewall-Regeln ergänzen:
(ggfls. in den folgenden Anweisungen eth0 durch wlan0 ersetzen)

iptables -t nat -A  POSTROUTING -o eth0 -j MASQUERADEiptables -A FORWARD -i eth0 -o tun0 -m state --state RELATED,ESTABLISHED -j ACCEPTiptables -A FORWARD -i tun0 -o eth0 -j ACCEPT

(3) Firewall-Regeln permanent speichern:

apt-get install iptables-persistent

...oder, falls das Paket schon installiert war ...

dpkg-reconfigure iptables-persistent
reboot

KISS - "keep it simple, stupid"

Der Dateityp PDF/A ist perfekt für die Archivierung von Schriftstücken aller Art. Somit gelangt bei mir seit Jahren alle Briefpost zunächst auf den Scanner, der dann brav aus vielen Seiten handliche PDF-Dateien zaubert.
Soweit, so gut. Doch es sei angemerkt, dass es sich hierbei um SCAN's handelt, also nicht um maschinenlesbare und somit auswertbare, durchsuchbare PDF-Dateien. Doch dieses Manko lässt sich dank der Arbeit von OCR-Software schnell und einfach lösen. Genutzt wurde hier das Framework tesseract, welches aber bedauerlicherweise keine PDF-Dateien als Eingaben mag. Somit hat jbarlow83 sich die Mühe gemacht, dies zu verbessern. Und diesmal so, dass PDF-Dateien gelesen werden können, die Texterkennung gestartet wird und anschließend der erkannte Text als durchsichtige Maske über den Scan gelegt wird. Die Dateigröße ändert sich nur minimal, es werden automatisch zukunftssichere PDF/A-Dateien erzeugt und somit eignet sich diese Lösung perfekt für ein Langzeitarchiv.
Die Installation ist dank brew auch denkbar einfach:

# brew install ocrmypdf

Nun kann man testweise einmal eine Datei umwandeln lassen:

# ocrmypdf input.pdf output.pdf -l deu+eng

wandelt das input.pdf nach output.pdf und verwendet für die Texterkennung die Sprachen Deutsch und Englisch.

Je nach Seitenanzahl und CPU-Power dauert dies pro Dokument einige Sekunden.
Hiernach wird man zunächst keinen Unterschied feststellen. Wenn das nun gewonnene Dokument in "Vorschau" öffnet, kann man mit gedrückter Maustaste den Text markieren und per Zwischenablage in ein anderes Dokument übertragen.

PERFEKT - Oder doch noch nicht vollständig?

Nein, nicht ganz. Denn es haben sich um Laufe der Zeit hunderte Dokumente angesammelt. Und zu allem Überfluss wurde hier eine neue Datei erschaffen und die Zeit-/Datumsinformationen der Ursprungsdatei gingen verloren.

Also noch einmal zurück an Reissbrett:

Und nun zeigt sich die Stärke von Mac OS X: mit Automator wird die Sache hier rund, und zwar wirklich einfach.
Automator kennen Sie nicht? Sie arbeiten seit Jahren mit Apple-Rechnern? Gut, die wenigsten kennen die echte Power unter der Haube

Wir klicken auf Launchpad, suchen den grauen Kasten Andere und finden darin Automator

Dort wählen wir links unten Neues Dokument und anschließend Schnellaktion.
In das Suchfeld (Lupe, blinkender Cursor) geben wir shell ein und bestätigen das Ergebnis shell-Skript ausführen mit Enter.

In dem großen grauen Feld geben wir das folgende Script ein:

export PATH=/usr/local/bin:$PATH
for f in "$@"
do
    t="$(/usr/bin/GetFileInfo -d "$f")"
	ocrmypdf "$f" "$f" -l "deu+eng" --skip-text
    /usr/bin/SetFile -m "$t" -d "$t" "$f"
done

Erklärung:
Die erste Zeile Zeile erweitert den Suchpfad für das Programm um den Pfad /usr/local/bin, dann beginnt die Abarbeitung der Dateien:

1. Der Timestamp wird in die Variable t gerettet
2. Das Script ocrmypdf wird ausgeführt, die Originaldatei hierbei überschrieben. Sollte diese bereits bearbeitet worden sein, sorgt --skip-text dafür, dass keine Fehlermeldung den Vorgang abbricht:
3. Die gerettete Zeit-/Datumsinformation wird mit SetFile zurückgesichert.

WICHTIG: Beachten Sie die Groß-/Kleinschreibung in Zeilen 1. und 3.

Die Menüpunkte der Pull-Down-Menüs oben entsprechend einstellen:

Abschließend in Ablage - Sichern noch einen sprechenden Namen eintragen, unter dem das Script zukünftig erreichbar sein soll.

Alle Finder-Fenster nun schließen, Finder öffnen und mit einem Rechtsklick auf dem/den PDF's die Schnellaktion mit dem oben vergebenen Namen auswählen.

Ein sich drehendes Zahnrad ganz oben neben der Uhr/WLAN-Anzeige zeigt an, dass der Automator arbeitet. Etwas Geduld, dann sind auch viele Dateien einfach konvertiert.

Howto: Umzug eines konfigurierten Raspberry PI-Systems auf eine USB-SSD

Hier wird der Einsatz einer SSD als Root-Dateisystem zusammen mit einer SD-Karte als Boot-Medium beschrieben. Diese Vorgehensweise ist für alle RPI's möglich. Das native Booten von USB mit einem RPI3 wird hier beschrieben.

Der Raspberry Pi wird standardmäßig mit einer SD-Karte als Massenspeicher ausgeliefert. An diesem Ansatz ist prinzipiell nichts auszusetzen. Allerdings setzen viele Schreibzugriffe auf dieses Medium der Freude an der Stabilität schnell Grenzen, und auch ich habe bereits SD-Karten zerschrieben. Gerade mit dem Einsatz vieler Docker-Container ist die Gefahr gestiegen.

Benötigt werden:

• SD-Karte (bereits vorhanden, System bereits eingerichtet)
• SSD, 2,5", SATA (möglichst keine Harddisk, Stichwort Stromaufnahme)
• USB nach SATA-Adapter oder kleines Leer-Gehäuse für externe USB-Laufwerke

Die nachfolgenden Schritte werden hier unter macOS beschrieben und sind unter Linux ähnlich:

• (1) ein Image der SD-Karte erstellen
• (2) dieses Image auf die SSD schreiben
• (3) einen Eintrag in der cmdline.txt ändern
• (4) Neustart -> Fertig!

(1) Zunächst wird der RPI heruntergefahren und von der SD-Karte ein Image erstellt, welches als Backup dann auf die SSD geschrieben wird.
Also die SD-Karte in den Slot des Mac's gesteckt, kurz gewartet und auf dem Mac ein Terminal geöffnet (Strg-Leertaste und dann terminal eingeben)

# diskutil list 
...
/dev/disk3 (internal, physical):
   #:                       TYPE NAME                    SIZE       IDENTIFIER
   0:     FDisk_partition_scheme                        *8.0 GB     disk3
   1:             Windows_FAT_32 boot                    66.1 MB    disk3s1
   2:                      Linux                         7.9 GB     disk3s2
...

Hier werden nun die einzelnen Speichermedien des Mac's aufgelistet
ACHTUNG: WICHTIG: Hier nun das richtige Medium auswählen und sich merken ( in diesem Beispiel ist es die Platte /dev/disk3, erkennbar an zwei Partitionen FAT32 und Linux und der Größe 8GB.
Diese Bezeichnung gilt nun für alle nachfolgenden Schritte. Sollte es bei Ihnen also die /dev/disk2 verweisen, so gilt dies als "2" für alle Schritte.

Damit MacOS die Partitionen freigibt, werden diese zunächst ungemounted:

# diskutil umount /dev/disk3 

Dann kann ein Image der SD-Karte gezogen werden. ACHTUNG: Damit es schneller geht, werden wir nun auf das RAW Device zugreifen, d.h. aus disk3 wird nun rdisk3!!

# sudo dd if=/dev/rdisk3 of=raspi.img bs=8m 

Dies wird nun etwas dauern, Ungeduldige dürfen mit CTRL+t "nachschauen", wie viele Bytes denn schon geschrieben sind.

load: 1.04  cmd: dd 962 uninterruptible 0.00u 4.54s
723+0 records in
722+0 records out
6056574976 bytes transferred in 314.570090 secs (19253499 bytes/sec)

950+0 records in
950+0 records out
7969177600 bytes transferred in 440.643784 secs (18085306 bytes/sec)

Nach Beendigung liegt im Benutzerverzeichnis des Mac's eine Datei mit dem Namen raspi.img als Sicherheitskopie vor. Die SD-Karte kann nun ausgeworfen werden.

# diskutil umountDisk /dev/disk3 

Haben Sie den unterschied gesehen? Auch hier ist der Befehl ähnlich dem ersten Befehl "umount", allerdings wird hier mit "umountDisk" nun der gesamte Datenträger ausgeworfen, ähnlich dem "Rechtsklick - Datenträger auswerfen" auf dem Desktop.

(2) Nun wird dieses Image auf die SSD geschrieben. ACHTUNG: die Einträge von InputFile if und OutputFile of werden nun vertauscht.

SSD per USB verbinden und auch zunächst unmounten:

# diskutil umount /dev/disk3 

und zurücksichern:

# sudo dd if=raspi.img of=/dev/rdisk3 bs=8m 

(3) Abschließend muss dem Raspberry Pi nun noch mitgeteilt werden, dass er nach dem Einschalten und Booten von der SSD nach dem Laden des Kernels auf die SSD zugreifen soll. Dies passiert in der Datei cmdline.txt.
Die können wir über den Desktop editieren. Auf dem Desktop den Datenträger "Boot" öffnen, die Datei "cmdline.txt" mit Doppelklick öffnen und den Eintrag

root=/dev/mmcblk0p2 

durch

root=/dev/sda2

ersetzen. Ersteres war der Eintrag auf die zweite Partion der SD-Karte (MMC-Block-Device), zweiteres ist der neue Eintrag auf die zweite Partition der SSD.

(4) Nun die SSD auswerfen (Rechtsklick - "boot" auswerfen), alles an RasPi anschließen (SD-Karte und SSD via USB), füran startet der RasPi nach dem Boot von der SD mit dem Root-Dateisystem von der SSD schneller und sicherer. Und im "Fall des Knalls" hat man eine Datensicherung, die man einfach auf die SSD wieder zurücksichert.

Wie sind die Vital-Werte des Host? Laufen Container wild? Wie sind Netzwerk-Auslastung? Oder die Speicherplatzbelegung?

Viele Fragen ergeben sich beim Einsatz von Docker-Container, gerade beim Einsatz von vielen Container auf kleiner Hardware.
Um hier den Überblick zurückzugewinnen, empfiehlt sich der Einsatz eines Monitoring-Tools, examplarisch wird nun rpi-monitor vorgestellt.

# mkdir /docker/rpi-mon
# mkdir /docker/rpi-mon/usr-lib
# cd /docker/rpi-mon

In diesem Verzeichnis werden drei Dateien angelegt: Dockerfile, docker-compose.yaml und run.sh. Diese habe ich angepasst, um z.B. das persistente Speichern der Statistik-Daten RRD auch nach Neu-Build zu gewährleisten.

Dockerfile

# https://github.com/michaelmiklis/docker-rpi-monitor/blob/master/Dockerfile
FROM resin/rpi-raspbian:latest

LABEL maintainer="Michael Miklis / <info@michaelmiklis.de>"

RUN [ "cross-build-start" ]

ENV  DEBIAN_FRONTEND noninteractive

# Install RPI-Monitor form Xavier Berger's repository
RUN apt-get -y update && \
    apt-get install -y --no-install-recommends dirmngr apt-transport-https ca-certificates  && \
    apt-key adv --recv-keys --keyserver keyserver.ubuntu.com 2C0D3C0F && \
    echo deb http://giteduberger.fr rpimonitor/ > /etc/apt/sources.list.d/rpimonitor.list && \
    apt-get -y update && \
    apt-get install -y rpimonitor && \
    apt-get clean && \
    apt-get autoclean && \
    rm -rf /var/lib/apt/lists/* /tmp/* /var/tmp/* && \
    sed -i 's/\/sys\//\/dockerhost\/sys\//g' /etc/rpimonitor/template/* && \ 
    sed -i 's/\/etc\/os-release/\/dockerhost\/usr\/lib\/os-release/g' /etc/rpimonitor/template/version.conf && \
    sed -i 's/\/proc\//\/dockerhost\/proc\//g' /etc/rpimonitor/template/* && \
    echo include=/etc/rpimonitor/template/wlan.conf >> /etc/rpimonitor/data.conf && \
    sed -i '/^web.status.1.content.8.line/ d' /etc/rpimonitor/template/network.conf && \
    sed -i '/^#web.status.1.content.8.line/s/^#//g' /etc/rpimonitor/template/network.conf && \
    sed -i 's/\#dynamic/dynamic/g' /etc/rpimonitor/template/network.conf && \
    sed -i 's/\#web.statistics/web.statistics/g' /etc/rpimonitor/template/network.conf  
    
# Allow access to port 8888
EXPOSE 8888

# persistente Daten in den Container-Build kopieren
COPY ./usr-lib/ /var/lib/rpimonitor/stat/

# Start rpimonitord using run.sh wrapper script
ADD run.sh /run.sh
RUN chmod +x /run.sh
CMD bash -C '/run.sh';'bash'

RUN [ "cross-build-end" ]

docker-compose.yaml

rpi-monitor:
# https://rpi-experiences.blogspot.de/2018/02/rpi-monitor-docker-container.html
# https://github.com/michaelmiklis/docker-rpi-monitor/issues/1

  container_name: rpimon
  image: michaelmiklis/rpi-monitor
  restart: unless-stopped
  ports:
    - "8888:8888"
  devices:
    - "/dev/vchiq"
    - "/dev/vcs"
  volumes:
    - /opt/vc:/opt/vc/
    - /boot/:/boot/
    - /sys/:/dockerhost/sys/:ro
    - /etc/:/dockerhost/etc/:ro
    - /proc/:/dockerhost/proc/:ro
    - /usr/lib/:/dockerhost/usr/lib/:ro
    - ./usr-lib:/var/lib/rpimonitor/stat/

run.sh

#!/bin/bash

# Load shared libraries from /opt/vc/lib
echo /opt/vc/lib > /etc/ld.so.conf.d/00-vmcs.conf
ldconfig

# Link /opt/vc/bin binaries to /usr/bin
ln -s /opt/vc/bin/raspividyuv /usr/bin/raspividyuv
ln -s /opt/vc/bin/dtmerge /usr/bin/dtmerge
ln -s /opt/vc/bin/raspistill /usr/bin/raspistill
ln -s /opt/vc/bin/vcgencmd /usr/bin/vcgencmd
ln -s /opt/vc/bin/vcdbg /usr/bin/vcdbg
ln -s /opt/vc/bin/dtoverlay-pre /usr/bin/dtoverlay-pre
ln -s /opt/vc/bin/raspiyuv /usr/bin/raspiyuv
ln -s /opt/vc/bin/vchiq_test /usr/bin/vchiq_test
ln -s /opt/vc/bin/tvservice /usr/bin/tvservice
ln -s /opt/vc/bin/edidparser /usr/bin/edidparser
ln -s /opt/vc/bin/raspivid /usr/bin/raspivid
ln -s /opt/vc/bin/dtoverlay-post /usr/bin/dtoverlay-post
ln -s /opt/vc/bin/dtoverlay /usr/bin/dtoverlay
ln -s /opt/vc/bin/dtparam /usr/bin/dtparam

# Insert Docker Host hostname into raspbian.conf
DOCKERHOST=$(cat /dockerhost/etc/hostname)
sed -i "s/'+data.hostname+'/$DOCKERHOST/g" /etc/rpimonitor/template/raspbian.conf

# Update RPI Monitor Package Status
/etc/init.d/rpimonitor install_auto_package_status_update
/usr/share/rpimonitor/scripts/updatePackagesStatus.pl

# Start RPI Monitor
/usr/bin/rpimonitord -v

HINT:
Bei Testen wollte ich zunächst alle entstandenen Statistikdaten aus dem Container in den Host kopieren. In der Shell werden mit * alle Dateien eines Ordners angesprochen. Dies gilt NICHT für den docker cp-Befehl! Der "."-Punkt ist richtig.

# cd /docker/rpi-mon/usr-lib
# docker cp rpimon:/var/lib/rpimonitor/stat/. .  # KORREKT !!
# docker cp rpimon:/var/lib/rpimonitor/stat/* .  # FALSCH !!

Best Practice im Docker-Umfeld bedeutet, dass sinnvollerweise pro Service ein eigener Container benutzt wird. Da kommen schnell mehrere Hände voll Container zusammen. Auf der Kommandozeile sind die mit

# docker ps

schnell aufgelistet. Allerdings ist eine Weboberfläche, mit deren Hilfe Images, Container und die Netzwerke wenigstens rudimentär administriert werden können, schnell auf der Wunschliste. Hier kommt PORTAINER ins Spiel.

Hier sind alle Aktivitäten im Überblick verfügbar. Auch die Installation ist denkbar einfach:

# mkdir /docker/portainer
# mkdir /docker/portainer/data
# vi /docker/portainer/docker-compose.yaml

docker-compose.yaml:

version: '2'

services:
    portainer:
        image: portainer/portainer
        container_name: "portainer"
        restart: always
        expose:
            - "9000"
        ports:
          - "9000:9000"
        volumes:
          - ./data:/data
          - /var/run/docker.sock:/var/run/docker.sock
          # Automatically choose 'Manage the Docker instance where Portainer is running' by adding <--host=unix:///var/run/docker.sock> to the command
          #    command: --templates http://templates/templates.json

Das Image wird direkt aus dem Hub bezogen und per Browser über den Port 9000 administriert. Weitere Informationen sind unter https://hub.docker.com/r/portainer/portainer/ erreichbar.

... und natürlich alles auf einem Raspberry PI !

UPDATE 2020/2021 s. unten

Eigentlich war es anders geplant, lediglich ein paar statische HTML-Seiten auf meiner Webpräsenz, kein CMS, keine Datenbank ... nur Apache und gut.

Aber wenn ich schnell mal ein paar Gedanken zu Papier bringen möchte? Rein nur statisches HTML? Nein, das ist zu komplex!

Dann las ich etwas über Ghost, im Docker-Container, OK? Als Einzeiler auf meinem Raspberry Pi 2 getestet ... und begeistert ;-)

# mkdir /docker/ghost
# mkdir /docker/ghost/blog
# cd /docker/ghost
# docker run -d --name my-ghost \
  -v /docker/ghost/blog:/var/lib/ghost/content \
  -p 2368:2368  arm32v7/ghost:1

Es ist Magie, nach wenigen Sekunden steht unter http://IP-Raspberry:2368 eine erste Testseite des Ghost-Systems zur Verfügung. Ein paar erste Einträge, die den Eindruck vermitteln, was das System leisten kann.
Administriert wird alles via http://IP-Raspberry:2368/ghost , dort kann man den Default-User und die Test-Blogs löschen und seinen eigenen User anlegen.
Text einfügen, oben rechts auf das Zahnrad klicken, dort noch ein Bild hochladen und ein paar Ergänzungen .... Publish - Fertig!

UPDATE 2020/2021:

... und wenn man noch einen Ghost anlegen möchte, der als getrennte (Sub-)-Domain erreichbar sein soll? Und dann bitte auch die aktuelle Version?

Nun, die Änderungen sind marginal:

# mkdir /docker/ghost2
# mkdir /docker/ghost2/blog
# cd /docker/ghost2
# docker run -d --name my-ghost2 \
  -v /docker/ghost2/blog:/var/lib/ghost/content \
  -p 2369:2368 arm32v7/ghost

Derart marginal, dass sie fast nicht auffallen:

1. ein neues Unterverzeichnis (ghost2) und dessen Unterverzeichnis blog anlegen
2. mit dem docker run wird nun auch der neue Name und das neue Volume mitgeteilt
3. WICHTIG! Die Ports müssen nun umgebogen werden 2369 -> 2368 für die Administration und die Darstellung des Content für die ganze Welt
4. ...und wenn das ":1" hinter dem arm32v7/ghost weggelassen wird, dann zieht sich der RPI gleich das aktuellste Ghost

• DNS-Problem

Das VPN mit OpenVPN auf meinen OpenVPN-Server in der DMZ läuft problemlos, allerdings werden DNS-Anfragen mit Tunnelblick (MacBook mit macOS) NICHT getunnelt. Dies ist insbesondere vor dem Gesichtspunkt meines lokalen Werbeblockers PI-HOLE eines echtes Minus. Ich möchte, auch wenn ich nicht zuhause bin, mit dem Werbeblocker surfen.

Lösung:

Serverseitig in der /etc/openvpn/openvpn.conf den/die PUSHes eintragen:

push "dhcp-option DNS IP-des-PI-Hole"  <- hier die IP-Adresse eintragen

Client-seitig ist anzumerken, dass diese allerdings auf der älteren Version Tunnelblick 3.7.0 nicht aktiv wird. Ein Update auf die Version 3.7.5 gibt unter
- Einstellungen - Erweitert - Verbinden & Trennen -
den neuen Menüpunkt "Änderungen an manuell veränderten Netzwerkeinstellungen erlauben". Anklicken, verbinden und nun auch aus der Ferne mit dem heimischen Werbeblocker surfen ...

Pi-hole - Werbeblocker

Für die Docker-Umgebung wird das ⿻Image von diginc benutzt. Da sich hier in der Vergangenheit Änderungen ergeben haben (kein alpine mehr, stattdessen debian), wurde die URL auf die neue MultiArchitecture angepasst:

docker-compose.yaml:

version: '2'
services:
pihole:
container_name: pihole
restart: unless-stopped
image: diginc/pi-hole-multiarch:debian_armhf
environment:
- ServerIP=192.168.x.y  #<- IP des Docker-Servers !!!
- TZ=Europe/Berlin
- WEBPASSWORD=*leer*
- DNS1=1.1.1.1         #   <- DNS-Server Cloudflare
- DNS2=8.8.8.8         #   <- DNS-Server Google
volumes:
- ./pihole/:/etc/pihole/  # <- Konfiguration persistent 
- ./dnsmasq.d/:/etc/dnsmasq.d/
ports:
- "80:80"   # <-  kein anderer Webserver parallel !!
- "53:53/tcp"
- "53:53/udp"

Die Administration erfolgt via http://IP-Raspberry/admin , dort mit dem oben gesetzten Passwort einloggen und ggfls. hier noch weitere Config-Änderungen einpflegen.

Dann im DSL-Router den DNS-Server manuell eintragen, hier also die IP des Raspberry Pi. Dort antwortet dann Pi-hole auf Port 53 auf die DNS-Queries, prüft gegen die Block-/Black-/Whitelists ab und stellt die Anfragen an einen der beiden in der YAML eingetragenen DNS-Server von Cloudflare oder Google.

Werbung ade ;-) .....