macOS unterstützt Linux-Container mit neuem Framework
Apple hat einige Neuerungen für Entwickler angekündigt, die unter macOS arbeiten.
Apple hat einige Neuerungen für Entwickler angekündigt, die unter macOS arbeiten.
Apple hat einige Neuerungen für Entwickler angekündigt, die unter macOS arbeiten.
Seit vielen Jahren verwende ich Let’s Encrypt-Zertifikate für meine Webserver. Zum Ausstellen der Zertifikate habe ich in den Anfangszeiten das Kommando certbot
genutzt. Weil die Installation dieses Python-Scripts aber oft Probleme bereitete, bin ich schon vor vielen Jahren auf das Shell-Script acme.sh
umgestiegen (siehe https://github.com/acmesh-official/acme.sh).
Kürzlich bin ich auf einen Sonderfall gestoßen, bei dem acme.sh
nicht auf Anhieb funktioniert. Die Kurzfassung: Ich verwende Apache als Proxy für eine REST-API, die in einem Docker-Container läuft. Bei der Zertifikatausstellung/-erneuerung ist Apache (der auf dem Rechner auch als regulärer Webserver läuft) im Weg; die REST-API liefert wiederum keine statischen Dateien aus. Die Domain-Verifizierung scheitert. Abhilfe schafft eine etwas umständliche Apache-Konfiguration.
Ausgangspunkt ist also ein »gewöhnlicher« Apache-Webserver. Dieser soll nun zusätzlich eine REST-API ausliefern, die in einem Docker-Container läuft (localhost:8880). Die erste Konfiguration sah ziemlich simpel aus:
# zusätzliche Apache-Proxy-Konfigurationsdatei
# für einen Docker-Container
<VirtualHost *:443>
ServerName api.example.com
# SSL
SSLEngine on
SSLCertificateFile /etc/acme-letsencrypt/api.example.com.pem
SSLCertificateKeyFile /etc/acme-letsencrypt/api.example.com.key
# Proxy: localhost:8880 <-> https://api.example.com
ProxyPreserveHost On
ProxyPass / http://localhost:8880/
ProxyPassReverse / http://localhost:8880/
# Logging Konfiguration ...
</VirtualHost>
# HTTP -> HTTPS
<VirtualHost *:80>
ServerName api.example.com
Redirect permanent / https://api.example.com
</VirtualHost>
Das Problem besteht darin, dass acme.sh
zwar diverse Domain-Verifizierungsverfahren kennt, aber keines so richtig zu meiner Konfiguration passt:
acme.sh ... --webroot
scheitert, weil die API eine reine API ist und keine statischen Dateien ausliefert.acme.sh ... --standalone
scheitert, weil der bereits laufende Webserver Port 80 blockiert.acme.sh ... --apache
scheitert mit could not resolve api.example.com.well-known.Die Lösung besteht darin, die Apache-Proxy-Konfiguration dahingehend zu ändern, dass zusätzlich in einem Verzeichnis statische Dateien ausgeliefert werden dürfen. Dazu habe ich das neue Verzeichnis /var/www/acme-challenge
eingerichtet:
mkdir /var/www/acme-challenge
chown www-data:www-data /var/www/acme-challenge/
Danach habe ich die Konfigurationsdatei für Apache umgebaut, so dass Anfragen an api.example.com/.well-known/acme-challenge
mit statischen Dateien aus dem Verzeichnis /var/www/acme-challenge/.well-known/acme-challenge
bedient werden:
# Apache-Konfiguration wie bisher
<VirtualHost *:443>
ServerName api.example.com
# SSL
SSLEngine on
SSLCertificateFile /etc/acme-letsencrypt/api.example.com.pem
SSLCertificateKeyFile /etc/acme-letsencrypt/api.example.com.key
# Proxy: localhost:8880 <-> api.example.com
ProxyPreserveHost On
ProxyPass / http://localhost:8880/
ProxyPassReverse / http://localhost:8880/
# Logging Konfiguration ...
</VirtualHost>
# geändert: HTTP auf HTTPS umleiten, aber nicht
# für well-known-Verzeichnis
<VirtualHost *:80>
ServerName api.example.com
# Handle ACME challenges locally
Alias /.well-known/acme-challenge /var/www/acme-challenge/.well-known/acme-challenge
<Directory /var/www/acme-challenge/.well-known/acme-challenge>
Require all granted
</Directory>
# Redirect everything EXCEPT ACME challenges to HTTPS
RewriteEngine On
RewriteCond %{REQUEST_URI} !^/.well-known/acme-challenge/
RewriteRule ^(.*)$ https://api.example.com$1 [R=301,L]
</VirtualHost>
Nach diesen Vorbereitungsarbeiten und mit systemctl reload apache2
gelingt nun endlich das Zertifikaterstellen und -erneuern mit dem --webroot
-Verfahren. Dabei richtet acme.sh
vorübergehend die Datei /var/www/acme-challenge/.well-known/acme-challenge/xxx
ein und testet dann via HTTP (Port 80), ob die Datei gelesen werden kann.
# Zertifikat erstmalig erstellen
acme.sh --issue --server letsencrypt -d api.example.com --webroot /var/www/acme-challenge
# Zertifikat installieren und Renew-Prozess einrichten
acme.sh --install-cert -d api.example.com \
--key-file /etc/acme-letsencrypt/api.example.com.key \
--fullchain-file /etc/acme-letsencrypt/api.example.com.pem \
--reloadcmd "service apache2 reload"
# Renew-Prozess testen
acme.sh --renew -d api.example.com --force
Eine noch elegantere Lösung besteht darin, den Docker-Container mit Traefik zu kombinieren (siehe https://traefik.io/traefik/). Bei korrekter Konfiguration kümmert sich Traefik um alles, nicht nur um die Proxy-Funktionen sondern sogar um das Zertifikatsmanagment. Aber diese Lösung kommt nur in Frage, wenn auf dem Host nicht schon (wie in meinem Fall) ein Webserver läuft, der die Ports 80 und 443 blockiert.
Unraid 7.0 ist heute in stabiler Version freigegeben worden. Die umfangreichen neuen Entwicklungen und Änderungen betreffen unter anderem die Oberfläche sowie die Handhabung von Docker und VMs.
Mit der Veröffentlichung von Immich v1.109.0 haben die Entwickler optionale Lizenzen angekündigt. Man bekommt nun unten links angezeigt, dass man eine unlizenzierte Version einsetzt, sofern man keine Lizenz gekauft hat. Nachfolgend beide Lizenzoptionen und...
Das bei Red Hat entwickelte Podman ist eine Alternative zu Docker. Es benötigt keinen Daemon und läuft ohne Root-Rechte. Gerade ist Podman 5.0 erschienen.
Flox ist nach Angaben der Entwickler eine virtuelle Umgebung und ein Paketmanager in einem.
Ein MQTT-Broker ist die Schnittstelle zwischen vielen IoT-Sensoren und Geräten, die Sensordaten auswerten oder Aktoren steuern. Das MQTT-Protokoll ist offen und sehr weit verbreitet. Es findet in der Industrie Anwendungen, ist aber auch in Smart Homes ist MQTT weit verbreitet.
MQTT ist ein sehr schlankes und schnelles Protokoll. Es wird in Anwendungen mit niedriger Bandbreite gerne angewendet.
MQTT funktioniert, grob gesagt, folgendermaßen: IoT-Geräte können Nachrichten versenden, die von anderen IoT-Geräten empfangen werden. Die Vermittlungsstelle ist ein sogenannter MQTT-Broker. Dieser empfängt die Nachrichten von den Clients. Gleichzeitig können diese Nachrichten von anderen Clients abonniert werden. Die Nachrichten werden in sog. Topics eingestuft, die hierarchisch angeordnet sind, z.B. Wohnzimmer/Klima/Luftfeuchtigkeit.
Home Assistant, oder ein anderer Client, kann diesen Topic abonnieren und den Nachrichteninhalt („Payload„) auswerten (z.B. 65%).
In Home Assistant OS und Supervisor gibt es ein Addon, das einen MQTT-Broker installiert. Das ist sehr einfach, komfortabel und funktioniert wohl recht zurverlässig. In den Installationsarten Home Assistant Container und Core gibt es diese Möglichkeit nicht. Hier muss man manuell einen MQTT-Broker aufsetzen.
In diesem Artikel beschäftige ich mich damit, wie man den MQTT-Brocker Mosquitto über Docker installiert. Anschließend zeige ich, wie man die Konfigurationsdatei gestaltet und eine Verbindung zu Home Assistant herstellt. Das Ergebnis ist dann ungefähr so, als hätte man das Addon installiert. Los gehts!
Als MQTT-Broker verwende ich die weit verbreitete Software Mosquitto von Eclipse. Dieser wird auch von Home Assistant bevorzugt und ist derjenige Broker, den das Addon installieren würde.
Für diese Anleitung wird vorausgesetzt, dass Docker bereits installiert ist und eine SSH-Verbindung zum Server hergestellt werden kann.
Schritt 1: Zunächst erstellen wir ein paar Ordner, die wir später benötigen. Mosquitto wird später so konfiguriert, dass in diese Ordner alle wichtigen Dateien abgelegt werden. Dadurch kann man auf dem Filesystem des Servers Mosquitto konfigurieren und beobachten.
$ mkdir mosquitto $ mkdir mosquitto/config $ mkdir mosquitto/data $ mkdir mosquitto/log
Schritt 2: Nun wird die Konfigurationsdatei für Mosquitto erstellt. Über diese Datei kann man das Verhalten von Mosquitto steuern.
$ nano config/mosquitto.conf
persistence true persistence_location /mosquitto/data/ log_dest file /mosquitto/log/mosquitto.log log_dest stdout password_file /mosquitto/config/mosquitto.passwd allow_anonymous false listener 1883
Schritt 3: Mit dem folgenden Befehl lädt man sich das aktuelle Image von Eclipse Mosquitto auf den Server.
$ docker pull eclipse-mosquitto
Schritt 4: Mit dem folgenden Befehl wird der Docker-Container gestartet. Das ist der Schlüsselmoment, jetzt muss alles klappen.
$ docker run -it -p 1883:1883 -p 9001:9001 --name mosquitto -v /home/pi/mosquitto/config:/mosquitto/config -v /home/pi/mosquitto/data:/mosquitto/data -v /home/pi/mosquitto/log:/mosquitto/log eclipse-mosquitt
Die Flags bedeuten hierbei folgendes:
Wer lieber Docker Compose verwendet, trägt diesen Eintrag in seine *.yaml ein:
services:
eclipse-mosquitto:
stdin_open: true
tty: true
ports:
- 1883:1883
- 9001:9001
restart: unless-stopped
container_name: mosquitto
volumes:
- /home/pi/mosquitto/config:/mosquitto/config
- /home/pi/mosquitto/data:/mosquitto/data
- /home/pi/mosquitto/log:/mosquitto/log
image: eclipse-mosquitto
Schritt 5: Checken, ob der Container ordnungsgemäß läuft. In der folgenden Liste sollte eine Zeile mit dem Mosquitto-Docker auftauchen. Dieser sollte außerdem „up“ sein. Falls nicht, nochmal versuchen den Container zu starten und kontrollieren, ob er läuft.
$ docker container ls -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES xxxxxxxxx eclipse-mosquitto "/init" 3 minutes ago Up 2 minutes [...] mosquitto
Schritt 6: Sehr gut, der Container läuft. Es wird dringend empfohlen, den MQTT-Broker so abzusichern, dass nur angemeldete User darauf zugreifen können. Das ist ja schon in Schritt 2 in die Konfigurationsdatei geschrieben worden. Mit dem folgenden Befehl melden wir uns in der Shell innerhalb des Containers an und erstellen einen Benutzer. In diesem Beispiel mosquitto. Im Anschluss an diesen Befehl wird man zweimal gebeten, das Passwort für den User festzulegen. Ist das geschafft, läuft der MQTT-Broker auf dem Server. Herzlichen Glückwunsch!
$ docker exec -it sh // öffnet die Shell innerhalb des Dockers mosquitto_passwd -c /mosquitto/config/mosquitto.passwd mosquitto
Optional Schritt 7: Den MQTT-Broker bindet man in Home Assistant ein, indem man auf Einstellungen → Geräte und Dienste → + Integration hinzufügen klickt. Im Suchfenster nach „MQTT“ suchen und die Zugangsdaten eingeben.
Die Server-Adresse findet man übrigens am schnellsten über ifconfig heraus.
The post MQTT-Broker Mosquitto als Docker Container installieren first appeared on bejonet - Linux | Smart Home | Technik.
Aktuell setze ich mich ein wenig mit MongoDB auseinander und habe mir lokal mit Docker eine Test-Installation eingerichtet:
docker run --name mongo -d mongodb/mongodb-community-server:latest
docker exec -it mongo mongosh
Using MongoDB: 7.0.3
Using Mongosh: 2.1.0
test> ...
Je nachdem, wie Sie Docker installiert haben, müssen Sie sudo
vor jedes docker
-Kommando stellen.
Zum Kennenlernen hätte ich nun gerne ein paar Beispieldatenbanken. Und tatsächlich stellt Mongo für sein Cloud-Angebot Atlas eine ganze Palette von Testdatenbanken zur Verfügung. Eine Kurzbeschreibung der Datenbanken finden Sie hier:
https://www.mongodb.com/docs/atlas/sample-data
Genau die Datenbanken hätte ich gerne in meiner lokalen Installation als »Spielwiese«. Leider ist die Installation dieser Beispieldatenbanken bei der lokalen Verwendung von MongoDB umständlich. Auf GitHub gibt es Dumps (Backups) der Beispieldateien im JSON-Format:
git clone https://github.com/mcampo2/mongodb-sample-databases.git
cd mongodb-sample-databases
lstree sample_*
sample_airbnb/
listingsAndReviews.json
sample_analytics/
accounts.json
customers.json
transactions.json
sample_geospatial/
shipwrecks.json
...
Jetzt geht es darum, die Datenbanken zu importieren. Unter Linux oder macOS führen Sie dazu für jede JSON-Datei aus samples_xxx
ein Kommando nach dem folgenden Muster aus:
cat sample_airbnb/listingsAndReviews.json | \
docker exec -i mongo mongoimport --db sample_airbnb --collection listingsAndReviews
Beachten Sie, dass Sie docker exec
mit der Option -i
ausführen müssen (nicht -it
wie bisher für den interaktiven Betrieb), damit die Weitergabe von Daten über den Pipe-Operator |
funktioniert.
Anstatt nun jede JSON-Datei einzeln zu importieren, bietet sich die Formulierung eines winzigen Scripts an. Er richtet für jedes DB-Verzeichnis sample_xxx
eine gleichnamige Datenbank ein und importiert jedes JSON-Dokument als Collection. (Beachten Sie, dass die auf Atlas definierten Indize nicht eingerichtet werden. Wenn Sie zum Testen einen Index brauchen, müssen Sie diesen selbst einrichten.)
#!/bin/sh
for db in sample_*; do
for file in $db/*.json; do
collection="$(basename $file .json)"
cat $file | docker exec -i mongo mongoimport --db $db --collection $collection
done
done
Das Script muss in dem Verzeichnis ausgeführt werden, in dem sich die von GitHub heruntergeladenen sample_xxx
-Verzeichnisse befinden.
Nach dem Import können Sie sich in der Mongo Shell überzeugen, dass alles geklappt hat:
docker exec -it mongo mongosh
test> show dbs
admin 40.00 KiB
config 72.00 KiB
local 40.00 KiB
sample_airbnb 52.09 MiB
sample_analytics 9.39 MiB
sample_geospatial 784.00 KiB
sample_mflix 28.39 MiB
sample_supplies 968.00 KiB
sample_training 61.30 MiB
sample_weatherdata 2.55 MiB
samples_airbnb 52.09 MiB
test 112.00 KiB
test> use sample_airbnb
sample_airbnb> show collections
listingsAndReviews
sample_airbnb> db.listingsAndReviews.findOne()
{
_id: '10009999',
listing_url: 'https://www.airbnb.com/rooms/10009999',
name: 'Horto flat with small garden',
...
}
Immer wieder mal in den 8 Jahren LinuxNews kam die Idee auf, WordPress den Laufpass zu geben. Gescheitert ist es dann an der Migration.
Für die adminForge Mastodon Instanz kanoa.de haben wir kürzlich die Anleitung Mastodon Grafana Statistiken (Docker) geschrieben. Nun möchten wir den #MastoAdmin’s die Anpassungen der noch kleinen Mastodon Instanz nicht vorenthalten. Punkt 1: NGINX Caching...
by adminForge.