Mein Laufwerk C: läuft regelmäßig voll, u.a. wegen den wachsenden Dateisystemen von Docker und der WSL. Bisher hab ich mich mehr schlecht als recht damit geholfen, die ext4.vhdx Dateien zu komprimieren.
Aber… es ist möglich, die Dateisysteme, also die ext4.vhdx Dateien auf ein anderes Laufwerk umzuziehen.
Hier am Beispiel meines Ubuntu-18.04 WSL, welches ich von C: nach E:\wsl\ubuntu umziehen möchte:
# Zielverzeichnis erstellen
mkdir E:\wsl\ubuntu
# WSL stoppen
wsl --shutdown
# Backup erzeugen
wsl --export Ubuntu-18.04 "E:\wsl\ubuntu\Ubuntu-18.04.tar"
# ggf. vorhandene originale ext4.vhdx von C: sichern, denn jetzt wird diese gelöscht
wsl --unregister Ubuntu-18.04
# Backup wieder importieren
wsl --import Ubuntu-18.04 "E:\wsl\ubuntu" "E:\wsl\ubuntu\Ubuntu-18.04.tar" --version 2
# ggf. default WSL und User setzen, wenn nötig
wsl --set-default Ubuntu-18.04
ubuntu1804 config --default-user <wsl_user_name>
# wenn die WSL startet und alles funktioniert, das Backup nun löschen
del E:\wsl\ubuntu\Ubuntu-18.04.tar
Auf E: ist mehr als genügend Platz und die ext4.vhdx Datei in E:\wsl\ubuntu kann (erstmal) wachen, wie sie möchte.
Benachrichtigen kann man sich dann z.B. via eMail, Discord oder Telegram. Oder über ganz viele andere Kanäle, dann im Endeffekt wird Apprise unter der Haube benutzt.
Es ist relativ einfach, Grafana Loki als Logging Stack zu nutzen. Dann lassen sich sehr bequem die Logs aller Container zentral sammeln und einsehen (via Grafana).
Um es kurz zu machen: Die Domain edge.activity.windows.com muss auf die Whitelist. Ansonsten hängt Edge dauerhaft bei „Synchronisierung wird eingerichtet“.
Auf meinem kleinen Ubuntu Server zu Hause tummeln sich ca. 30 Docker Container. Bisher habe ich mich via Docker-Update-Image-Notififier (DIUN) über Updates benachrichtigen lassen, wenn es neue Version der genutzten Images gab. Das Update hab ich dann aber trotzdem noch selbst gemacht bzw. machen müssen. Die Benachrichtung via eMail ist ganz ansprechend und die ganze Geschichte lässt sich sich schön individuell konfigurieren, ja nachdem, wie man es braucht.
Soweit, so gut. Heute habe ich dann zufällig Watchtower entdeckt. Da sehen die Benachrichtigungen zwar nicht so schön aus, aber dafür können automatische Updates gemacht werden, wenn neue Versionen der Images vorliegen.
Auch hier wieder eine komplette docker-compose.yml, inkl. eMail Relay via Postfix:
Wenn bestimmt Images nicht aktualisiert werden sollen, was z.B. bei auf dem System selbst gebauten Images der Fall ist, kann das mit diesem Label verhindert werden:
Out of the box kann Pi-hole bisher kein DoH, aber ein Docker Container eilt zur Hilfe: crazymax/cloudflared
Diesen kann man zusammen mit Pi-Hole starten und via TUNNEL_DNS_UPSTREAM einen oder mehrere DoH Server mitgeben. Pi-Hole bekommt dann den Container als DNS Server und nutzt dann (in-) direkt DoH.
Bei mir sind das dann 192.168.1.130#5053 und 192.168.1.105#5053. Redundanz muss sein. ? Und via Port 49312 gibt es noch ein paar Metriken im Prometheus Format.
DoT (DNS over TLS) wäre auch eine Alternative, habe ich bisher aber nicht ausprobiert. Vielleicht bekommt Pi-hole ja auch irgendwann einmal native DoH oder DoT Unterstützung, dann sind Bastellösungen wie diese überflüssig.
Abschließend: Braucht man das wirklich? Nein, kann man aber.
Kleines Update vom 04.02.2021: IPv6 Konfiguration hinzugefügt, damit Pi-Hole als auch Cloudflared via IPv6 erreichbar sind im LAN.
Mein etwas in Jahre gekommener Raspberry Pi hat seit einiger Zeit keine Updates mehr bekommen. Auch wenn auf dem System nur noch FHEM und ein Pi-hole (in Docker) laufen, sind (Sicherheits-) Updates nicht unwichtig. Ein Blick auf die Infoseite zu Debian LTS bestätigte dann, mein raspbian auf Basis von Jessie (8) bekommt keinen Support mehr. Leider ist ein direktes Update von Jessie (8) auf Buster (10) nicht möglich bzw. nicht sinnvoll. Daher ist ein Zwischenschritt auf Stretch (9) notwendig. Im Endeffekt dauert es nur alles etwas länger, die Schritte für die Updates sind identisch. Vorab hab ich ein Backup der SD Karte mit Win32DiskImager gemacht; für alle Fälle.
Auf einem Raspberry Pi oder einem anderen System mit einem Docker Daemon lässt sich Pi-hole sehr leicht betreiben. Hier das dazugehörige docker-compose.yml:
Angepasst werden müssen die IP Adresse (hier 192.168.1.105), VIRTUAL_HOST und am besten auch WEBPASSWORD. Die beiden hinterlegten DNS Server gehören zu Freifunk München bzw. UncensoredDNS. Über Port 8000 ist dann die Weboberfläche erreichbar. Die IP Adresse des Docker Hosts stellt dann via Port 53 Pi-hole für DNS Anfragen bereit.
Update: IPv6 funktioniert nur bis zur docker-compose Version 2.1 und mit der zusätzlichen Network Konfiguration unten.
Über die Telegram API kann man sich bequem benachrichtigen lassen, wenn sich ein Benutzer per SSH auf einem System eingeloggt hat. Dazu folgende Zeilen in die Datei /etc/ssh/sshrc einfügen.
IP=`echo $SSH_CONNECTION | cut -d " " -f 1`
HOSTNAME=`hostname`
MESSAGE="SSH Login on $HOSTNAME as $USER from $IP"
curl --output /dev/null -s -X POST -H 'Content-Type: application/json' -d "{\"chat_id\": \"-123456789\", \"text\": \"$MESSAGE\", \"disable_notification\": true}" https://api.telegram.org/bot123456789:hgDW0mvUcio_AF4Za1nh-aY7PX/sendMessage
Wie an die Chat ID und das Token für den Bot zu kommen ist, ist z.B. hier beschrieben.
Eigentlich ganz einfach: Runterladen, entpacken und in /usr/local verschieben.
# download current version (1.13.3)
mkdir golang-update
cd golang-update
wget https://dl.google.com/go/go1.13.3.linux-amd64.tar.gz
tar xvzf go1.13.3.linux-amd64.tar.gz
# remove old version
sudo rm -rf /usr/local/go
# move new version in place
sudo mv go /usr/local
# set GOPATH and add folders to PATH
export GOPATH=$HOME/go
export PATH=$PATH:/usr/local/go/bin:$GOPATH/bin
# run go version
go version
# result: go version go1.13.3 linux/amd64