Archiv für das Monat: August, 2026

Paperless-ngx Docker Upgrade: von 2.20.15 auf 3.0.4

Paperless-ngx Docker Upgrade: von 2.20.15 auf 3.0.4

Paperless-ngx 3.0 bringt Breaking Changes. Diese Anleitung zeigt das Upgrade einer Docker-Installation, Schritt für Schritt.

Voraussetzung: Ausgangsversion muss 2.20.15 sein. Nur von dort aus ist der Sprung auf 3.0 offiziell unterstützt. Ältere Versionen zuerst auf 2.20.15 bringen.

Was sich in 3.0 ändert

  • Suchindex wechselt von Whoosh zu Tantivy (Rust). Volltextindex muss neu aufgebaut werden, passiert im Docker-Image automatisch beim Start.
  • PAPERLESS_SECRET_KEY ist jetzt Pflicht.
  • PAPERLESS_DBENGINE ist bei PostgreSQL/MariaDB jetzt Pflicht (vorher aus PAPERLESS_DBHOST abgeleitet).
  • Diverse SSL-/Timeout-/Pooling-Variablen der DB entfallen zugunsten von PAPERLESS_DB_OPTIONS.
  • API-Version 1 fällt weg.
  • Dokument-Prüfsummen wechseln auf SHA-256.
  • Datenbankmigrationen sind nicht rückwärtskompatibel. Ohne Backup kein Rollback.

Vollständige Liste: github.com/paperless-ngx/paperless-ngx/releases

Schritt 1: Backup

cd /opt/paperless

docker compose stop

# Datenbank (Beispiel PostgreSQL)
docker compose exec -T db pg_dump -U paperless paperless > /opt/backup/paperless-db-$(date +%F).sql

# Volumes sichern
sudo tar -czf /opt/backup/paperless-data-$(date +%F).tar.gz ./data
sudo tar -czf /opt/backup/paperless-media-$(date +%F).tar.gz ./media

# Compose-Files sichern
cp docker-compose.yml /opt/backup/docker-compose.yml.bak
cp docker-compose.env /opt/backup/docker-compose.env.bak

Alternativ den eingebauten Paperless-Exporter nutzen:

docker compose run --rm webserver document_exporter ../export

Schritt 2: Secret Key setzen

Falls bisher kein PAPERLESS_SECRET_KEY gesetzt war, lief 2.x mit einem eingebauten Default-Key. Für 3.0 wird ein expliziter Key Pflicht.

openssl rand -base64 64

In docker-compose.env oder direkt in docker-compose.yml unter environment eintragen:

YAML Datei
PAPERLESS_SECRET_KEY: "<generierter-wert>"

Wichtig: Wird ein neuer, zufälliger Key gesetzt statt des alten Default-Keys, werden bestehende Sessions und API-Tokens ungültig. Nutzer müssen sich neu anmelden.

Schritt 3: Datenbank-Engine explizit setzen

Nur bei PostgreSQL oder MariaDB nötig, nicht bei SQLite.

YAML Datei

# v2 (PostgreSQL wurde aus PAPERLESS_DBHOST abgeleitet)
PAPERLESS_DBHOST: postgres

# v3 (Engine muss explizit gesetzt sein)
PAPERLESS_DBENGINE: postgresql
PAPERLESS_DBHOST: postgres

Zulässige Werte: postgresql oder mariadb. Bisherige einzelne SSL-/Timeout-/Pooling-Variablen durch PAPERLESS_DB_OPTIONS ersetzen, falls verwendet:

YAML Datei
PAPERLESS_DB_OPTIONS: "sslmode=require,pool.max_size=20"

Alte Variablen funktionieren übergangsweise weiter, loggen aber eine Deprecation-Warnung beim Start.

Schritt 4: Image-Tag auf 3.0.4 setzen

In docker-compose.yml:

YAML Datei
services:
  webserver:
    image: ghcr.io/paperless-ngx/paperless-ngx:2.20.15

ändern zu:

YAML Datei

services:
  webserver:
    image: ghcr.io/paperless-ngx/paperless-ngx:3.0.4

Wer bisher :latest nutzt: :latest zeigt seit Juli 2026 bereits auf 3.x. Für kontrollierte Major-Upgrades empfiehlt sich grundsätzlich ein fester Versions-Tag statt :latest.

Schritt 5: Neues Image ziehen und Container neu erstellen

docker compose pull
docker compose up -d

Der Suchindex-Rebuild (Whoosh → Tantivy) läuft beim ersten Start automatisch im Container. Bei größeren Archiven dauert das spürbar.

Schritt 6: Logs beobachten

docker compose logs -f webserver

Auf Migrationsfehler, fehlende Env-Variablen oder Reindex-Fortschritt achten.

Schritt 7: Verifikation

  • Version in der Weboberfläche prüfen (Systemstatus zeigt 3.0.4).
  • Volltextsuche testen, auch nach Umlauten und mehreren Suchbegriffen (Tantivy verknüpft Begriffe standardmäßig mit OR statt AND wie zuvor Whoosh).
  • Ein Testdokument einscannen/konsumieren lassen, OCR-Ergebnis prüfen.
  • Download und Vorschau eines bestehenden Dokuments prüfen.
  • Login/API-Token testen, falls der Secret Key neu gesetzt wurde.
  • Containerstatus prüfen: docker compose ps.

Rollback

Bei Problemen:

docker compose down

Alten Image-Tag (2.20.15) in docker-compose.yml zurücksetzen, DB-Dump aus Schritt 1 einspielen, data/ und media/ aus dem Backup zurückkopieren, dann:

docker compose up -d

Bekannte Stolperfallen

  • Fehlender PAPERLESS_SECRET_KEY bricht den Start ab.
  • PAPERLESS_DBENGINE vergessen bei PostgreSQL/MariaDB führt zu Verbindungsfehlern.
  • Zusätzliche, verwaiste Container aus älteren Compose-Setups können mit dem neuen Consumer kollidieren.
  • Veraltete Syntax in globalen Dateinamensvorlagen kann nach dem Upgrade Fehler werfen.

Quelle: github.com/paperless-ngx/paperless-ngx/releases

Debian 12 auf 13 Upgrade im Proxmox LXC Container

Debian 12 auf 13 Upgrade im Proxmox LXC Container (Copy & Paste)

Debian 12 Bookworm auf 13 Trixie upgraden, direkt im LXC Container auf Proxmox. Fertiges Script zum Copy & Paste, plus Backup und Verifikation.

Vorher: Snapshot

Vor jedem Major-Upgrade einen Snapshot des Containers erstellen. Einzige einfache Rückfallebene bei Problemen.

pct snapshot <CTID> pre-debian13-upgrade

Das Upgrade-Script

Im Container als root ausführen:

cat <<EOF >/etc/apt/sources.list
deb http://ftp.debian.org/debian trixie main contrib non-free non-free-firmware
deb http://ftp.debian.org/debian trixie-updates main contrib non-free non-free-firmware
deb http://security.debian.org/debian-security trixie-security main contrib non-free non-free-firmware
deb http://ftp.debian.org/debian trixie-backports main contrib non-free non-free-firmware
EOF

apt-get update
DEBIAN_FRONTEND=noninteractive apt-get -o Dpkg::Options::="--force-confold" dist-upgrade -y

# Disable services that break in LXC / containers (harmless if not present)
systemctl disable --now systemd-networkd-wait-online.service || true
systemctl disable --now systemd-networkd.service || true
systemctl disable --now ifupdown-wait-online || true

# Install ifupdown2 (better networking stack for LXC/VMs)
apt-get install -y ifupdown2

# Cleanup
apt-get autoremove --purge -y
apt-get clean

reboot

Was das Script macht

  • Sources.list: ersetzt Bookworm-Quellen durch Trixie-Quellen, inklusive Security und Backports.
  • dist-upgrade: zieht alle Pakete auf Trixie, –force-confold behält bestehende Config-Dateien bei Konflikten.
  • Service-Disables: systemd-networkd-wait-online, systemd-networkd und ifupdown-wait-online können im LXC-Kontext beim Boot hängen bleiben, da sie auf Netzwerk-Hardware warten, die im Container nicht existiert. Deaktivieren verhindert das. || true sorgt dafür, dass das Script nicht abbricht, falls ein Dienst gar nicht installiert ist.
  • ifupdown2: modernerer Networking-Stack, funktioniert zuverlässiger in LXC/VM-Umgebungen als das klassische ifupdown.
  • Cleanup: entfernt nicht mehr benötigte Pakete und den apt-Cache.
  • Reboot: notwendig, damit Kernel-Userspace-Tools, systemd und Netzwerkstack sauber auf Trixie laufen.

Danach: Verifikation

cat /etc/debian_version
lsb_release -a
apt list --upgradable
ip a
systemctl --failed
  • debian_version sollte 13.x zeigen.
  • apt list –upgradable sollte leer sein.
  • ip a prüft, ob die Netzwerkschnittstelle nach dem Reboot korrekt hochgekommen ist.
  • systemctl –failed zeigt fehlgeschlagene Dienste nach dem Upgrade.

Bekannte Stolperfallen

  • Container-Config auf Proxmox-Host prüfen: sehr alte LXC-Templates können mit Trixie inkompatible Cgroup- oder AppArmor-Profile mitbringen.
  • Bei gepinnten Paket-Repos (Docker, PostgreSQL, etc.) müssen deren eigene sources.list-Einträge separat auf trixie umgestellt werden, das Script deckt nur die Debian-Basisquellen ab.
  • Nach dem Upgrade Dienste einzeln prüfen, die auf spezifische Paketversionen angewiesen sind (z. B. PHP, Python, Datenbanken).

Rollback

Bei Problemen: Container stoppen, Snapshot aus dem ersten Schritt zurückspielen.

pct rollback <CTID> pre-debian13-upgrade

Paperless-ngx Upgrade: von 2.20.15 auf 3.0.4 (Debian-VM auf Proxmox)

Paperless-ngx Upgrade: von 2.20.15 auf 3.0.4 (Debian-VM auf Proxmox)

Paperless-ngx 3.0 bringt Breaking Changes. Diese Anleitung zeigt das Bare-Metal-Upgrade auf einer Debian-VM unter Proxmox, Schritt für Schritt.

Voraussetzung: Ausgangsversion muss 2.20.15 sein. Nur von dort aus ist der Sprung auf 3.0 offiziell unterstützt. Ältere Versionen zuerst auf 2.20.15 bringen.

Was sich in 3.0 ändert

  • Suchindex wechselt von Whoosh zu Tantivy (Rust). Volltextindex muss neu aufgebaut werden.
  • PAPERLESS_SECRET_KEY ist jetzt Pflicht.
  • PAPERLESS_DBENGINE ist bei PostgreSQL/MariaDB jetzt Pflicht (vorher aus PAPERLESS_DBHOST abgeleitet).
  • Diverse SSL-/Timeout-/Pooling-Variablen der DB entfallen zugunsten von PAPERLESS_DB_OPTIONS.
  • API-Version 1 fällt weg.
  • Dokument-Prüfsummen wechseln auf SHA-256.
  • Consumer-/OCR-Variablen teils umbenannt, OCR_MODE=skip-Verhalten ändert sich.
  • Datenbankmigrationen sind nicht rückwärtskompatibel. Ohne Backup kein Rollback.

Schritt 1: Snapshot der Proxmox-VM

Vor allem anderen: VM-Snapshot in Proxmox erstellen. Das ist der schnellste Rollback-Weg, unabhängig vom Applikations-Backup. Backup wichtig! Es kann immer was schief laufen!

qm snapshot <VMID> pre-paperless-3-0-4

Schritt 2: Anwendungs-Backup

Zusätzlich zum Snapshot ein Paperless-eigenes Backup, da die DB-Migration nicht reversibel ist.

sudo systemctl stop paperless-webserver paperless-consumer paperless-scheduler paperless-task-queue

# Datenbank (Beispiel PostgreSQL)
sudo -u postgres pg_dump paperless > /opt/backup/paperless-db-$(date +%F).sql

# Daten- und Medienverzeichnisse
sudo tar -czf /opt/backup/paperless-media-$(date +%F).tar.gz /opt/paperless/media
sudo tar -czf /opt/backup/paperless-data-$(date +%F).tar.gz /opt/paperless/data

# Konfiguration
sudo cp /opt/paperless/paperless.conf /opt/backup/paperless.conf.bak

Bei SQLite genügt eine Kopie der .sqlite3-Datei aus dem Datenverzeichnis.

Schritt 3: Version prüfen

cd /opt/paperless
sudo -Hu paperless git describe --tags

Muss v2.20.15 zeigen. Falls nicht: erst dorthin updaten, dann weiter.

Schritt 4: Secret Key sichern/setzen

Falls bisher kein PAPERLESS_SECRET_KEY gesetzt war, lief 2.x mit einem eingebauten Default-Key. Für 3.0 wird ein expliziter Key Pflicht.

python3 -c "import secrets; print(secrets.token_urlsafe(64))"

Wert in paperless.conf eintragen:

ini
PAPERLESS_SECRET_KEY=<generierter-wert>

Wichtig: Wird ein neuer, zufälliger Key gesetzt statt des alten Default-Keys, werden bestehende Sessions und API-Tokens ungültig. Nutzer müssen sich neu anmelden.

Schritt 5: Datenbank-Engine explizit setzen

Nur bei PostgreSQL oder MariaDB nötig, nicht bei SQLite.

ini
PAPERLESS_DBENGINE=postgresql
PAPERLESS_DBHOST=postgres

Zulässige Werte: postgresql oder mariadb. Bisherige einzelne SSL-/Timeout-/Pooling-Variablen durch PAPERLESS_DB_OPTIONS ersetzen, falls verwendet, z. B.:

ini
PAPERLESS_DB_OPTIONS=sslmode=require,pool.max_size=20

Alte Variablen funktionieren übergangsweise weiter, loggen aber eine Deprecation-Warnung beim Start.

Schritt 6: Systemabhängigkeiten aktualisieren

bash
sudo apt update
sudo apt install --only-upgrade python3 python3-pip python3-dev imagemagick fonts-liberation \
  gnupg libpq-dev default-libmysqlclient-dev pkg-config libmagic-dev mime-support \
  libzbar0 poppler-utils unpaper ghostscript icc-profiles-free qpdf liblept5 \
  libxml2 pngquant zlib1g tesseract-ocr

Ergänzend benötigte OCR-Sprachpakete (tesseract-ocr-deu etc.) prüfen, falls sich Sprachvorgaben geändert haben.

Schritt 7: Dienste stoppen

Falls Schritt 2 nicht schon erledigt:

sudo systemctl stop paperless-webserver paperless-consumer paperless-scheduler paperless-task-queue

Schritt 8: Quellcode auf 3.0.4 bringen

cd /opt/paperless
sudo -Hu paperless git fetch --all --tags
sudo -Hu paperless git checkout tags/v3.0.4

Schritt 9: Python-Abhängigkeiten aktualisieren

Venv aktivieren und Requirements neu installieren:

sudo -Hu paperless bash -c '
  source /opt/paperless/venv/bin/activate
  pip install --upgrade pip
  pip install -r requirements.txt
'

Danach die installierten Pakete gegen die neue requirements.txt abgleichen und nicht mehr benötigte Pakete entfernen, um Konflikte zu vermeiden.

Schritt 10: Datenbankmigration

cd /opt/paperless/src
sudo -Hu paperless ../venv/bin/python3 manage.py migrate

Schritt 11: Statische Dateien und Suchindex

sudo -Hu paperless ../venv/bin/python3 manage.py collectstatic --clear --no-input
sudo -Hu paperless ../venv/bin/python3 manage.py document_index reindex --if-needed

Der --if-needed-Flag prüft Schema-Version und Sprach-Sentinels und baut den Tantivy-Index nur neu, wenn nötig. Bei größeren Archiven (mehrere zehntausend Dokumente) dauert das spürbar; Fortschritt im Log beobachten.

Schritt 12: Dienste starten

sudo systemctl start paperless-webserver paperless-consumer paperless-scheduler paperless-task-queue
sudo systemctl status paperless-webserver

Schritt 13: Verifikation

  • Version in der Weboberfläche prüfen (Systemstatus zeigt 3.0.4).
  • Volltextsuche testen, auch nach Umlauten und mehreren Suchbegriffen (Tantivy verknüpft Begriffe standardmäßig mit OR statt AND wie zuvor Whoosh).
  • Ein Testdokument einscannen/konsumieren lassen, OCR-Ergebnis prüfen.
  • Download und Vorschau eines bestehenden Dokuments prüfen.
  • Login/API-Token testen, falls der Secret Key neu gesetzt wurde.
  • Log auf Fehler prüfen: journalctl -u paperless-webserver -n 200.

Rollback

Bei Problemen: Dienste stoppen, VM-Snapshot aus Schritt 1 zurückspielen. Alternativ Git-Checkout auf v2.20.15, DB-Dump aus Schritt 2 einspielen, altes paperless.conf zurückkopieren, Venv-Requirements der 2.20.15 neu installieren.

Bekannte Stolperfallen

  • Fehlender PAPERLESS_SECRET_KEY bricht den Start ab.
  • PAPERLESS_DBENGINE vergessen bei PostgreSQL/MariaDB führt zu Verbindungsfehlern.
  • Veraltete Syntax in globalen Dateinamensvorlagen kann nach dem Upgrade Fehler werfen.
  • Zusätzliche, nicht mehr benötigte Container/Prozesse aus älteren Setups können mit dem neuen Consumer kollidieren.

PatchMon v2.1.1 – v2.1.3: Fixes für SSO, Webhooks & Compliance

,

PatchMon v2.1.1 bis v2.1.3: Maintenance-Releases bringen Bugfixes für SSO, Webhooks und Compliance

Direkt im Anschluss an das große v2.1.0-Release hat das Entwicklerteam von PatchMon mit den Versionen v2.1.1, v2.1.2 und v2.1.3 drei schnelle Bugfix-Updates veröffentlicht. Während das Hauptrelease v2.1.0 massive Architektur- und Performance-Änderungen mit sich brachte, kümmern sich die Point-Releases um die Beseitigung von Unschärfen bei Single Sign-On (SSO), Benachrichtigungen und der Compliance-Infrastruktur.

Die beste Nachricht für Betreiber: Bei allen drei Versionen handelt es sich um reine In-Place-Updates. Es sind keine Änderungen an der docker-compose.yml und keine manuellen Updates der Agents erforderlich.

Die zentralen Verbesserungen in den Updates

1. SSO-Stabilisierung für ADFS und Microsoft Entra ID

Beim OIDC-basierten Single Sign-On kam es bei spezifischen Anbietern zu Login-Abbrüchen:

  • Microsoft ADFS: ADFS übermittelt Einzelwerte in Claims (wie E-Mails) häufig als JSON-Array. PatchMon akzeptierte bisher nur Strings und brach den Login ab. Dies wurde korrigiert.
  • Microsoft Entra ID (Azure AD): Da Entra ID standardmäßig keinen email_verified-Claim mitsendet, schlug die Auto-Erstellung von Accounts fehl. PatchMon wertet nun das Microsoft-Signal xms_edov (Email Domain Owner Verified) aus, was das Setup ohne Sicherheitskompromisse ermöglicht.

2. Webhooks für Mattermost & Rocket.Chat

Webhooks an Plattformen wie Mattermost oder Rocket.Chat quittierte der Server bisher mit einem HTTP 400 Error. PatchMon erkennt diese Endpunkte ab v2.1.3 automatisch anhand des /hooks/-Pfads in der URL und passt das Payload-Format an. Generische Webhooks wurden zudem um ein Top-Level-text-Feld ergänzt, um out-of-the-box mit Slack-kompatiblen Ingest-Servern zu harmonieren.

3. Compliance-Fixes für Proxmox LXC

Bei Instanzen außerhalb des offiziellen Docker-Containers (insbesondere bei der Nutzung des populären Proxmox LXC-Installationsskripts) meldete die Plattform fälschlicherweise leere Verzeichnisse für Compliance-Regelwerke und antwortete mit einem HTTP 503. Ab v2.1.3 werden die Versionsdaten direkt aus den Datastreams gelesen, sodass die Auswertung auf LXC-Containern wieder reibungslos funktioniert.

4. Beseitigung des „Stale“-Status bei Laptops

Clients, die in den Energiesparmodus versetzt wurden (z. B. Notebooks im Feierabend), wurden vom Server nach dem Aufwachen tagelang als inaktiv/veraltet („stale“) geführt. Der Server prüft nun beim Reconnect des Agents, ob das Update-Intervall überschritten wurde, und fordert im Bedarfsfall sofort einen frischen Statusbericht an.

5. Wiederherstellung der Supply-Chain-Attestierung

Aufgrund eines Fehlers im Build-Prozess wurden die Releases v2.1.0, v2.1.1 und v2.1.2 ohne SHA256-Prüfsummen, SBOMs (Software Bill of Materials) und Provenance-Attestierungen ausgeliefert. Mit Version v2.1.3 sind sämtliche Signatur- und Lieferketten-Sicherheitsdateien wieder regulär in den GitHub-Downloads enthalten.

Fazit & Update-Empfehlung

Die Point-Releases v2.1.1 bis v2.1.3 unterstreichen das hohe Tempo, mit dem das PatchMon-Projekt Kinderkrankheiten nach großen Versionssprüngen behebt. Allen Betreibern von v2.1.0 wird ein zügiges Update auf v2.1.3 empfohlen, um von den SSO- und Alerting-Fixes zu profitieren.

Offizielle Release-Übersicht: GitHub PatchMon Releases

PatchMon v2.1.0: Neues Release bringt massives Performance-Tuning

PatchMon 2.1.0

PatchMon v2.1.0 veröffentlicht: Performance-Explosion, neue Agent-Timeline und gehärtete Security

Das Entwicklerteam hinter dem Open-Source-Patch-Management-Tool PatchMon hat die Version v2.1.0 freigegeben. Das Release legt den Fokus primär auf Skalierbarkeit, Zuverlässigkeit bei großen Serverflotten (1.000+ Hosts) und eine grundlegende Überarbeitung der Agent-Kommunikation sowie der Sicherheitsarchitektur.

🛠️ Achtung beim Upgrade: Manuelle Anpassung der docker-compose.yml

Da PatchMon die eigene docker-compose.yml nicht automatisch überschreibt, müssen Betreiber vor dem Ausführen von docker compose pull && docker compose up -d drei Zeilen manuell anpassen:

  1. Server-Port-Mapping: - "${PORT:-3000}:${PORT:-3000}" (bisher: "3000:3000")

  2. Server-Hostname: hostname: patchmon-server (neu hinzufügen)

  3. Guacd-Image-Tag: image: guacamole/guacd:1.6.0 (bisher: :latest)

Hinweis zur Datenbank-Migration: Beim ersten Start nach dem Update führen große Host-Flotten Index-Rebuilds durch. Auf langsamen Datenträgern kann der Bootvorgang einige Minuten dauern, in denen PatchMon keine Anfragen entgegennimmt.

Die wichtigsten Neuerungen in PatchMon v2.1.0

1. Extrem reduzierte Network-Payloads (2 MB ➔ 1 KB)

Bisher übermittelten Agents bei jedem Check-in den kompletten Inventarbestand. Ab v2.1.0 senden aktualisierte Agents nur noch deltabasierte Änderungen. Der Datenverkehr pro Routine-Check-in sinkt dadurch von 2 MB auf ca. 1 KB. Zur Nachverfolgung ersetzt die neue Agent Activity Timeline die alten Tabs für Paketberichte und Warteschlangen.

2. Präzisere Host-Zustände und Live-Uptime

Das Dashboard trennt den Systemstatus nun in vier eindeutige Indikatoren:

  • Connection: Verbindung zum Server (reagiert nun innerhalb von Sekunden via WSS).

  • Reporting: Frische der übermittelten Daten.

  • Reboot Pending: Ausstehender Systemneustart.

  • Updates: Ausstehende Sicherheitspatches oder normale Updates.

Zudem wurde der Zustand Awaiting Data eingeführt: Hosts ohne Paketdaten verfälschen nicht mehr die Kategorie „Up to date“.

3. Zuverlässige Patch-Ausführung (Keine Hänger mehr)

Stalled Patch-Runs gehören der Vergangenheit an. Über den neuen Umgebungsparameter PATCH_RUN_STALL_TIMEOUT_MIN (Standard: 30 Minuten) werden blockierte Updates automatisch beendet. Der Button Stop Run bricht den Prozess nun auch dann garantiert ab, wenn der Agent offline ist oder blockierte Child-Prozesse im Hintergrund hängen.

4. Umfassende Fixes für Windows & Linux-Paketmanager

  • Windows Registry-Fix: Ein einziges Null-Byte-Zeichen in der Registrierung (oft erzeugt durch Drittanbieter-Agents wie MeshCentral) führte bisher dazu, dass der gesamte Bericht verworfen wurde. Dies wurde gefixt.

  • Linux/BSD-Anpassungen:

    • RHEL/Fedora/Rocky: Korrekte Handling von DNF-Bannern, Erfassung von RLSA-Sicherheitsmeldungen.

    • Debian/Ubuntu: Volle Unterstützung für deb822-Sources und korrekte Handhabung von Kernel-Meta-Paketen.

    • Arch/Manjaro: Funktionsfähig ohne installiertes pacman-contrib.

    • LXC-Container: Uptime zeigt nun die echte Container-Laufzeit anstelle der Laufzeit des Proxmox-Hosts.

5. Sicherheits-Härtung (Security & SSO)

  • IP-Spoofing-Schutz: Über TRUSTED_PROXY_RANGES lässt sich festlegen, welchen Upstream-Reverse-Proxies (z. B. Cloudflare hinter Nginx Proxy Manager) vertraut wird, um echte Client-IPs für Rate-Limiting und Lockouts auszuwerten.

  • Session-Binding & Revocation: Ausgestellte Tokens sind strikt an Sitzungen gebunden. Das Abmelden, Ändern von Passwörtern oder Deaktivieren von Konten greift ab sofort unverzüglich.

  • E-Mail / SMTP: Explizite Auswahlmöglichkeiten für TLS (STARTTLS, SSL/TLS, None, Auto) verhindern das ungesicherte Versenden von Benachrichtigungen über fehlerhafte Relays.

Neue Umgebungsvariablen (.env)

Variable Standardwert Zweck
TRUSTED_PROXY_RANGES (leer) CIDRs für verkettete Reverse Proxies zur echten IP-Ermittlung
PATCH_RUN_STALL_TIMEOUT_MIN 30 Minuten bis ein hängender Patch-Run als abgebrochen markiert wird
AGENT_REPORTS_RETENTION_DAYS 30 Aufbewahrungsdauer der Agent-Activity-Historie (7–365 Tage)
SESSION_INACTIVITY_TIMEOUT_MINUTES (inaktiv) Automatischer Logout bei Inaktivität (0 = deaktiviert)

Fazit

Mit dem Update auf v2.1.0 beweist das PatchMon-Team rund um Lead-Entwickler Iby, dass die Software reif für den anspruchsvollen Enterprise-Einsatz ist. Wer eine performante On-Premise-Alternative zu kommerziellen Patch-Management-Lösungen sucht, sollte das Update zeitnah einspielen.

Offizielle Release-Notes & Discussion: GitHub PatchMon Tag v2.1.0