IT-COW

Wieder auf neuen Server umgestiegen

th-rzv@gmx.de — Tue, 28 Apr 2026 16:17:46 +0200

Ich bin zwischenzeitlich wieder auf einen neuen Server umgestiegen, diesmal einen UM790PRO von minisforum, in der Konfiguration mit AMD RYZEN 9 7940HS-Prozessor, 64GB RAM und 1 Terabyte SSD…. bis jetzt finde ich das Gerät top, die Performance ist gut und das Gerät selber absolut lautlos, kann ich nur weiterempfehlen. Die Migration von proxmox ging erstaunlich einfach, ich hatte mit Problemen gerechnet, aber es gab keine, wobei ich dazu sagen muss, dass mir Chatgpt sehr bei der Konfiguration geholfen hat…. Hoffentlich werde ich mein neues Handicap mit der gelähmten linken Hand (scheiss Schlaganfall) bald wieder los…chatgpt ist schon super, Respekt an die Programmierer davon, vor 5 Jahren hatte ich das Thema künstliche Intelligenz ehrlich gesagt nicht so ernst genommen…

Nextcloud, Paperless-ngx,Samba, Vaultwarden und Jellyfin funktionieren jetzt wieder, wobei ich diesmal aber keine kostenlose domain via duckdns genommen habe, sondern eine eigene domain bei netcup gemietet habe…die 10 euro pro Jahr kann ich noch verkraften….. Dieses Blog läuft aber nicht darüber, sondern wird von Comtrance gehostet…

An Anwendungen ist jetzt die kostenlose Datenbank Baserow hinzu gekommen, aber damit muss ich erst noch Erfahrungen sammeln…. Ich mache drei Kreuze, wenn ich meine linke Hand wieder normal benutzen kann, darauf hätte ich gerne verzichtet…. aber zumindest bin ich geistig noch gut da, schlimmer geht ja immer…

Vom Passwortmanager Bitwarden bin ich auf Vaultwarden umgestiegen, schön dass ich meine Passwörter problemlos übernehmen konnte…. auch meine ganzen eingescannten PDF-Dokumente aus Paperless-ngx konnte ich problemlos übernehmen…

Was noch fehlt sind der VPN Wireguard und TVHeadend, wobei ich auf Wiregard wohl auch verzichten kann, solange ich nicht mehr gehen kann,aber ich arbeite natürlich daran, das wieder hinzubekommen, aber so eine Rehabilitation ist leider langwierig… ich hätte mir gewünscht, dass man eine halbseitige Lähmung heute effektiver behandeln kann, oder man zumindest die neuesten Therapiegeräte schneller bekommt…

test

th-rzv@gmx.de — Wed, 15 Apr 2026 12:14:00 +0200

erster post nach langer Pause, nur ein kurzer test…

TEST...1..2..3.. haha

test

th-rzv@gmx.de — Mon, 13 Apr 2026 18:12:00 +0200

erster post nach meinem schlaganfall, nur ein kurzer test…

habe durch den Schlaganfall eine halbseitige Lähmung (hemiparese genannt) bekommen, hätte ich nie erwartet…

mit nur einer hand tippen ist blöd,ich hoffe das gibt sich noch wieder…

Monitoring mit Grafana

th-rzv@gmx.de — Sun, 12 Mar 2023 03:41:37 +0200

Ende 2016 hatte ich den Lowend-Mini-PC Z83 II von Bqeel mit Intel Atom x5-Z8350-Prozessor gekauft, der PC verfügt über 2 GB RAM und 32 GB Flash. Die Beelink Z83 TV Box sieht äußerlich und von den technischen Daten her identisch aus, wahrscheinlich sind die beiden Geräte baugleich.

Die Benutzung mit dem vorinstallierten Windows 10 wurde mir dann aber doch zu langsam, und der geringe Speicher bereitete bei den Windows-Updates auch Probleme. So lag die Box dann jahrelang ungenutzt im Keller herum. Vor ein paar Monaten habe ich dann aber nach einem sinnvollen Einsatzzweck für das Gerät gesucht.

Zuerst hatte ich Batocera auf dem Gerät getestet, das führte aber zu plötzlichen Hängern im Betrieb. Danach hatte ich mal Linux Mint auf dem Gerät installiert, das zeigte aber dieselbe Symptomatik – Freezes nach spätestens einer Stunde Betriebszeit. Ich vermutete eine grundlegende Inkompatibilität mit Linux, daher hatte ich mal nach alternativen Betriebssystemen gesucht.

Ich stieß auf interessante FreeBSD-Derivate wie GhostBSD und NomadBSD, von denen ich noch nie zuvor gehört hatte. Interessant ist auch Tribblix, das auf Illumos basiert, einem Fork von OpenSolaris. Anders als die anderen Illumos-Distributionen wie OmniOS und OpenIndiana adressiert Tribblix eher den Einsatz als Desktop-Distribution und wird von nur einer Person entwickelt.

Den Systemen war gemein dass sie Treiber-Probleme mit der Hardware hatten und den integrierten Flash-Speicher nicht erkennen konnten, das System sich also nicht installieren ließ. Für den Desktop-Einsatz ist die Rechenleistung des PCs ohnehin zu gering, daher zog ich den Einsatzzweck als Server unter Ubuntu Server in Betracht. Denn terminal-basierende Server benötigen unter Linux erstaunlich wenig Rechenleistung; sie werden ja auch vielfach auf den Raspberries benutzt.

Dann habe ich Ubuntu 22.04 in der Server-Variante auf dem Gerät installiert. Irritierend war dabei zunächst, dass der Installer scheinbar automatisch zum nächsten Schritt übergeht, wenn keine Eingaben vorgenommen werden. Unter dem System läuft das Gerät aber seit Wochen stabil im Dauerbetrieb und erwärmt sich dabei kaum. Stabilitätsprobleme konnte ich keine mehr entdecken, aber mir ist aufgefallen dass Lesefehler geloggt wurden sobald ich eine SD-Karte in den Kartenleser steckte. Die Karte war dabei übrigens noch leer.

Ein Monitoring-System mit Prometheus und Grafana fiel mir als Einsatzzweck für den PC ein. Ich habe zwar auch einen Intel NUC unter Proxmox im Einsatz, aber es macht schon Sinn dass ein Monitoring-System auf einem anderen PC als die zu überwachenden Geräte läuft. Übrigens hatte ich vor 12 Jahren mal Icinga als Monitoring-System getestet, aber habe schon lange keine laufende Installation dazu mehr im Einsatz. Ein paar grundlegende Metriken bietet Proxmox natürlich auch direkt an, aber der Node Exporter unter Prometheus erfasst schon mehr Daten.

Konkret habe ich momentan zwei Monitoring-Szenarien im Einsatz:

1. Monitoring der VMs, die unter Proxmox laufen

2. Monitoring meiner Docker-Container, die in einem LXC-Container unter Proxmox laufen

Für das Monitoring der VMs werden als Techniken der Node Exporter zusammen mit der Prometheus-Datenbank benutzt, als Anleitungen habe ich die Artikel bei Geekflare, devopscube.com und natürlich bei der Prometheus-Seite benutzt. Die Installation von Prometheus war einfach, denn beim Aufsetzen von Ubuntu Server konnte man bereits zusätzliche Pakete auswählen.

Die Installation des Node Exporters geschieht natürlich auf den zu überwachenden virtuellen Maschinen. Bei der Installation des Node Exporters muss man den wget-Befehl aus der Anleitung natürlich auf die URL der aktuellen Version aus dem Github-Repository anpassen. Den Node Exporter runterladen, einen Betriebssystem-Benutzer anlegen unter dem der Dienst laufen soll und anschließend den systemd-Dienst selber anlegen, das geht recht schnell von der Hand. Der Befehl

systemctl enable node_exporter

fehlte noch in der Anleitung, damit der Dienst automatisch beim Reboot gestartet wird.

Prometheus greift die Daten ab, die der Node Exporter über http und den Port 9100 ausliefert. Unter Ubuntu Server musste ich erst die genaue Bezeichnung des Prometheus-Dienstes mit systemctl status auslesen, diese lautet snap.prometheus.prometheus.service. Entsprechend lässt sich mit “systemctl status snap.prometheus.prometheus.service” der Status des Dienstes auslesen, da es als Snap-Paket installiert wurde.

Die Einstellungsdatei prometheus.yml musste ich auch erst suchen, die liegt unter /var/snap/prometheus/86/prometheus.yml. Dort fügt man die Zeilen

- job_name: '$Name'
static_configs:
- targets: ['$IP:9100']

für jede zu überwachende VM hinzu und startet anschließend Prometheus mit

systemctl restart snap.prometheus.prometheus.service

neu. Anschließend kontrolliert man nochmal den Status des systemd-Dienstes direkt und über die Weboberfläche auf Port 9090 unter “Service Discovery”.

Um meine Docker-Container zu überwachen installierte ich InfluxDB und Telegraf auf meinem Server. Theoretisch reicht dafür ein einfaches “apt install influxdb”, aber in den Ubuntu-Repositories wird noch die veraltete Version 1.6.7 der InfluxDB angeboten obwohl es schon längst die Version 2.6.1 gibt. Die 2er-Version hat auch ein schönes Webinterface, ähnlich Grafana.

Die Anleitungen für die Installation der InfluxDB auf Seiten wie devconnected.com, zeropage.io, cyberithub.com oder computingforgeeks.com sind dabei zum Teil bereits veraltet, weil sich laut influxdata.com am 26.01.2023 der GPG-Key für den Zugriff auf ihr Repository geändert hat. Trotzdem sind die Anleitungen noch hilfreich, nachfolgend verlinke ich auch noch eine deutschsprachige Anleitung von howtoforge.

In den alten Anleitungen wird über

https://repos.influxdata.com/influxdb.key

der alte Key heruntergeladen, der neue Key ist aber über die Adresse

https://repos.influxdata.com/influxdata-archive_compat.key

herunterzuladen. Eventuell hätte man besser den neuen Key über die alte Internetadresse angeboten, denn so funktionieren die Anleitungen zum Teil nicht mehr, weil dann der apt install-Befehl mit einer Fehlermeldung fehlschlägt.

Die Information muss man erst einmal haben, aber danach ging die Installation ohne Probleme. Aber es wurde noch mehr seit der 1er-Version umgestellt, das CLI-Interface wurde geändert und auch die Konfigurationsdateien. Die alten Anleitungen sind daher zu größeren Teilen nicht mehr aktuell.

Ich hatte zuerst die 1er Version der InfluxDB installiert und wahrscheinlich deswegen lag noch eine Konfigurationsdatei influxdb.conf im Verzeichnis /etc/influxdb. Meine Änderungen an dieser Datei hatten auch nach einem Neustart des Dienstes aber überhaupt keine Auswirkungen.

Wenn man die Anleitungen der 1er-Version mit der 2er-Version gegenüberstellt sieht man auch dass sich das Format der Konfigurationsdatei zu YAML, TOML oder JSON-Dateien geändert hat:

In der Datei /etc/default/influxdb2 stand der Verweis

, die Datei war nach der Installation aber noch gar nicht vorhanden. Wahrscheinlich wird mit Defaultwerten gearbeitet, solange keine Datei vorhanden ist. Nachdem ich die Datei dort anlegte konnte ich aber Änderungen an den Einstellungen vornehmen.

Wenn Ihr nach Anleitungen zu InfluxDB sucht daher besser darauf achten dass die für die korrekte Version erstellt wurden. Bei der 2er-Version gibt es auch ein schickes Webinterface mit einem Installer für die Erstkonfiguration, das macht den Einstieg etwas einfacher. Auf der Dokumentationsseite zur Konfiguration kann man übrigens bei den Befehlen über Karteireiter zwischen den Formaten YAML, TOML oder JSON umschalten; die Syntax unterscheidet sich dabei.

Die Installation von Telegraf und Grafana war dagegen ganz einfach über apt install-Befehle. Telegraf sammelt Metriken ein und gibt sie weiter, Grafana ist für die Visualisierung. Telegraf hat eine ganze Menge an Input und Output-Schnittstellen, da werde ich später nochmal reinschauen.

Als ich die Konfigurationsdatei für Telegraf /etc/telegraf/telegraf.conf anschaute stellte ich fest, dass Telegraf auch Prometheus bei den Output-Plugins unterstützt. Die Installation einer zweiten Zeitreihendatenbank InfluxDB (zusätzlich zu Prometheus) ist damit wahrscheinlich unnötig gewesen, aber der RAM-Footprint von allem zusammen ist minimal.

Da bei InfluxDB offenbar mit der Version 2 sehr viel geändert wurde, wundert es mich auch nicht dass in der Telegraf-Konfigurationsdatei bei den Output-Plugins für InfluxDB v1 und v2 zwei getrennte Abschnitte aufgeführt sind, natürlich als auskommentierte Beispiele:

und

Telegraf muss natürlich mit der InfluxDB verknüpft werden, daher ein API-Token in der InfluxDB anlegen und dann in der Telegraf-Konfigurationsdatei die Einträge zu urls, token, organization und bucket auf sinnvolle Werte setzen. Das Ganze ist jetzt ein Gedächtnisprotokoll, daher notfalls auch bei den verlinkten Anleitungen reinschauen da meine Installation schon wieder ein paar Tage her ist.

Da es Output-Plugins bei Telegraf gibt, gibt es natürlich auch Input-Plugins. Mein Telegraf soll erstmal primär Statistiken über meine wichtigsten Docker sammeln und in der InfluxDB speichern. Wahrscheinlich werde ich das Ganze später noch erweitern.

Wie immer gibt es dazu mehrere Möglichkeiten. Wenn der Telegraf auf einer anderen Maschine als der zu überwachende Docker Daemon läuft, muss der Docker Daemon dazu im Netzwerk freigegeben (exposed) werden. Natürlich stellt das eine Sicherheitslücke dar, daher sollte man das nicht machen wenn der Server direkt und vollumfänglich ins Internet freigegeben wurde. Bei einem privaten Netzwerk schützt in der Regel die Firewall einer Fritzbox, sofern man seinen Server dort nicht als Exposed Host freigegeben hat.

Jedenfalls, wenn man den Docker-Daemon im Netzwerk freigeben will muss man dazu unter Ubuntu die Einstellungsdatei des systemd-Dienstes unter /etc/systemd/system/multi-user.target.wants/docker.service bearbeiten und bei dem Eintrag ExecStart den Parameter –H $IP:2376 ergänzen, abspeichern und natürlich den Docker-Dienst neu starten.

Dabei sollte man erstens 0.0.0.0 als IP-Adresse vermeiden, weil er dann von allen Netzwerkschnittstellen Anfragen ohne Authentifizierung entgegen nimmt und zweitens besser den verschlüsselten Port 2376 statt 2375 benutzen. Wenn man schon den Docker Daemon im Netzwerk freigibt sollte man ihn besser nur an eine lokale IP-Adresse binden, dann ist er durch die NAT-Translation eures Routers von außen geschützt. Nachfolgend verlinke ich noch die Dokumentationsseite von Docker.

Wahrscheinlich die bessere Möglichkeit ist es aber, den Telegraf direkt auf den zu überwachenden Maschinen zu installieren und die gesammelten Daten remote mit Authentifizierung in eine Datenbank zu schieben. Das ist aber auch mit etwas Aufwand verbunden, insbesondere wenn mehrere Docker-Hosts überwacht werden müssen. Mehr über die Gefahren der Netzwerkfreigabe des Docker-Daemons steht auf cdex.cloud.

Bei der Desktop-Variante von Ubuntu heißt der Dienst übrigens docker.service, aber bei der Server-Variante wird Docker als snap-Paket installiert und daher heißt der Service dort snap.docker.dockerd.service.

Die Grafana-Installation war ganz einfach, da das Paket direkt in den Ubuntu-Repositories vorhanden ist. Bei der Konfiguration von Grafana muss man sich aber entscheiden, ob man für die Anbindung an der InfluxDB als Query Language Flux oder das ältere InfluxQL nimmt. Laut der Anleitung von Howtoforge wird bei der Verwendung von InfluxDB 2.x davon abgeraten das ältere InfluxQL als Query Language zu verwenden, da es mit der neuen Version schwieriger einzurichten ist.

Bei Grafana gibt es vorkonfigurierte Dashboards je nach Datenquelle über die Angabe einer ID zum importieren. Welche Dashboards zur Auswahl stehen kann man über grafana.com einsehen. Speziell für Telegraf ist es dann wichtig kein zu altes Dashboard zu verwenden, um Fehlermeldungen zu vermeiden. Man kann z. B. die Stichworte “Telegraf Flux” oder “InfluxDB 2.x” bei der Suche verwenden.

Abschließend wollte ich noch die Anleitung von turbogeek.co.uk verlinken, wie man ein selbstsigniertes SSL-Zertifikat für Grafana mit openssl erstellt. Das ist nützlich wenn Ihr Grafana ins Internet freigeben wollt, weil dann die Kommunikation verschlüsselt wird. Bei selbstsignierten Zertifikaten müsst Ihr dazu aber erstmalig eine Warnung in eurem Webbrowser wegklicken. Die nächste Stufe wäre dann wahrscheinlich der certbot, um kostenlose Zertifikate von Let’s Encrypt zu erstellen.

Somit kann ich nun meine virtuellen Maschinen und Docker über Grafana monitoren. Dafür eignet sich der Atom Z83 ganz gut, weil er kaum warm wird und der RAM-Verbrauch minimal ist. An Stromverbrauch habe ich vier bis fünf Watt gemessen. Die Links habe ich auf mein Heimdall-Board verlinkt, ich muss mich also nicht immer durch Grafana durchklicken.

Das Ganze ist natürlich noch ausbaufähig, bei den Geek Freaks z. B. haben sie ein sehr umfangreiches Grafana-Board gezeigt. Aber so gefällt mir das für den Einstieg schon ganz gut.

Zerschossenen Bootloader vom Proxmox Server reparieren

th-rzv@gmx.de — Wed, 14 Sep 2022 22:56:05 +0200

Bei meinem Server wurde vorgestern durch ein automatisches Update von Proxmox der Bootloader zerschossen. Der Start des Servers blieb immer beim Bootloader Grub mit der Fehlermeldung

proxmox error: disk lvmid not found

stehen und sprang nur in den “Grub Rescue”-Modus mit einem Eingabeprompt. Um den Grub-Eingabeprompt bedienen zu können, muss man sich auch erst einmal mit den Befehlen beschäftigen.

Je nachdem, ob man seinen Server im alten EFI-Modus oder im neueren UEFI-Modus mit Secure Boot benutzt, wird ein anderer Bootloader von Proxmox installiert. Für den EFI-Modus wird Grub benutzt, ansonsten systemd-boot. Da ich den Server mit Linux benutzen wollte und das Secure Boot-Feature mit Linux bekanntermaßen Probleme machen kann, hatte ich Secure Boot im BIOS deaktiviert. Übrigens berichtete heise jüngst, dass durch ein Windows-Update Linux-Bootloader deaktiviert wurden.

Jedenfalls haben noch mehr Leute diese Woche Probleme mit Proxmox gehabt, wie man im Proxmox-Forum sehen konnte: 1 2. Soweit ich lese ist jüngst Debian 11.5 mit einem Update für Grub erschienen, und Proxmox baut auf Debian auf. Wobei ich dazu sagen muss, dass ich für die automatischen Updates von Proxmox (privat) das kostenlose “No-Subscription Repository” benutze.

Normalerweise muss man für die automatischen Updates von Proxmox Geld bezahlen, dieses kostenlose Update-Repository wird aber nur für Testzwecke und nicht für Produktivsysteme empfohlen. Wie ich jetzt gesehen habe, wohl nicht ganz zu Unrecht. Dass er dann aber nach einem Update gar nicht mehr bootet, damit hatte ich nicht gerechnet. Hier ist übrigens der Link zu dem Grub-Bug von der GNU-Seite.

Auf den einfachsten Tipp das System wieder booten zu können, brachte mich dieser Eintrag auf reddit, bei dem auch ein Screenshot der Fehlermeldung zu sehen ist. Jemand hat da nämlich als Tipp geantwortet, ein Bootmedium wie einen USB-Stick mit dem Programm “Super Grub 2 Disk” zu bestücken und davon zu booten. Ich sehe da übrigens auch ein Programm Rescatux zum Download, das hätte ich auch noch testen können.

Wichtig ist dann im Menü von Super Grub 2 zuerst den LVM-Support von Grub zu aktivieren, und dann unter “Boot manually”, “Operating System” einen der gefundenen Linux-Kernel auszuwählen. Daraufhin bootet er dann einmalig wieder ins System, aber der Bootloader ist dann noch nicht wieder repariert.

Ich habe dann aber nochmal neu in den Grub Rescue-Eingabeprompt gebootet, weil ich sehen wollte wie man das System von dort aus booten kann. Eigentlich ist die Bedienung dort nicht so schwierig, aber man muss die Befehle schon kennen. Auf phoenixNAP gibt es eine Übersicht der verfügbaren grub rescue-Befehle.

Zuerst muss man, wenn auf dem System Proxmox läuft, den LVM-Support aktivieren. Das geschieht mit dem Befehl

insmod lvm

Eine Unterstützung für das ext2-Dateisystem von Linux zu aktivieren ist auch sinnvoll:

insmod ext2

Mit ls kann man sich dann die erkannten Laufwerke und Partitionen anzeigen lassen, die Anzeige ist aber etwas gewöhnungsbedürftig:

Bei proxmox ist unter /dev/hda2 der Bootloader installiert, und unter /dev/hda3 dann das root-Filesystem.

Mit ls (hd0,gpt2)/grub kann man sich dann den Inhalt des Laufwerks mit dem Bootloader unter dem Menü /grub anzeigen lassen. Mit set kann man sich auflisten lassen, welche Einstellungen von grub aktiv sind.

Man muss dann einstellen, wo der Bootloader und wo die Root-Partition installiert ist:

set prefix=(hd0,gpt2)

set root=(lvm/pve-root)

Danach dann die folgenden Befehle ausführen:

linux (lvm/pve-root)/boot/pve/vmlinuz ro root=/dev/mapper/pve-root

initrd (lvm/pve-root)/boot/pve/initrd.img

boot

Wenn er dann ins System gebootet hat, kann man dann den Bootloader mit den folgenden Befehlen reparieren:

update-grub

grub-install

Und danach konnte ich zum Glück wieder ganz normal ohne USB-Stick booten. Da ich seit ein paar Wochen ein Vollbackup über einen dedizierten Proxmox Backup-Server fahre, wäre ein Neuaufsetzen des Servers aber auch nicht weiter tragisch gewesen.

Die Befehle der Proxmox-Seite “Recover from Grub Failure”, die man über den Debug-Modus eines Proxmox-Bootmediums nutzen kann, sind übrigens auch interessant. Bei der Installation des Bootloaders hatte ich dabei aber Fehlermeldungen bekommen.

Ich hoffe, dass so ein harter Fehler nicht so schnell erneut auftritt.