Archiv für die Kategorie: Tools

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

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

FRANZFON v1.1.0: Selbstgehostete Personalakte & VoIP-Fixes

Franzfon

FRANZFON v1.1.0 veröffentlicht: Integrierte Personalverwaltung und selbstheilende VoIP-Leitungen

Das deutsche Softwareprojekt FRANZFON hat am 17. Juli 2026 die Version 1.1.0 seiner selbst gehosteten Telefonanlage freigegeben. Während die Plattform bisher primär darauf spezialisiert war, die funktionalen Lücken der FRITZ!Box im geschäftlichen VoIP-Alltag zu schließen, markiert dieses Release einen echten Wendepunkt in der Produktstrategie. Mit der Einführung digitaler Personalakten wächst FRANZFON über die Telekommunikation hinaus und mutiert zum ganzheitlichen Betriebswerkzeug für KMUs, Kanzleien und Praxen.

Der neue Startbereich: Modularität zieht ein

Wer sich nach dem Update in der Weboberfläche anmeldet, landet nicht mehr standardmäßig im klassischen TK-Dashboard, sondern auf einem neu strukturierten Startbildschirm. Das System steuert die Ansicht intelligent über das zugewiesene Benutzermodell: Besitzt ein Mitarbeiter nur Zugriff auf ein einziges Modul, wird der Startbereich übersprungen. Administratoren und HR-Manager sehen hingegen eine Kachel-Übersicht, aufgeteilt in:

  • Telefonanlage: Die gewohnte, unveränderte Administration der Telefonie-Infrastruktur.

  • Mein Bereich: Der persönliche Workspace für Mitarbeiter (eingeführt im letzten Release).

  • Personal: Das Herzstück des neuen v1.1.0 Updates.

Ein Blick auf die inaktiven Kacheln verrät zudem die Roadmap der Entwickler: Die Module für Urlaub, Zeiterfassung und Schichtplan sind bereits visuell implementiert und dienen als Vorschau auf kommende Funktionserweiterungen.

Die digitale Personalakte auf dem eigenen Server

Mit der neuen Personalverwaltung können sensible Mitarbeiterdaten vollständig digitalisiert und lokal gespeichert werden – ein massiver Pluspunkt für die DSGVO-Konformität, da keine Drittanbieter-Cloud involviert ist. Eine Personalakte in FRANZFON v1.1.0 umfasst:

  • Persönliche Daten: Personalnummer, Geburtsdatum, Staatsangehörigkeit sowie private Notfallkontakte.

  • Beschäftigungsverhältnis: Position, Abteilung, zugewiesene Vorgesetzte, Ein- und Austrittsdaten sowie die wöchentliche Sollarbeitszeit.

  • Lohn & Steuer: Hinterlegung von IBAN, Steuer-ID, Steuerklasse, Krankenkasse und Sozialversicherungsnummer.

  • Schwerbehinderung: Erfassung der rechtlich relevanten Mindestangaben zur korrekten Berechnung von Kündigungsschutz und Zusatzurlaub.

Sicherheit und Protokollierung: Die Bearbeitung ist Administratoren oder Benutzern mit der Rolle „Personal“ vorbehalten. Mitarbeiter dürfen ihre eigene Akte jederzeit im Lesemodus einsehen. Zum Schutz vor unbefugten Zugriffen und zur Erfüllung von Compliance-Vorgaben wird jeder Lese- und Schreibzugriff im Hintergrund revisionssicher protokolliert. Ein automatischer Löschschutz markiert fällige Akten nach Ablauf von Fristen lediglich, anstatt Daten eigenmächtig zu vernichten.

Technische Highlights: Das Ende „stummer“ Leitungsausfälle

Ein gefürchtetes Szenario im VoIP-Alltag ist die verwaiste Verbindung: Die Telefonanlage signalisiert eine vermeintlich fehlerfreie, grüne Verbindung zur FRITZ!Box, im Hintergrund ist der SIP-Trunk jedoch abgebrochen. Eingehende Anrufe laufen ins Leere, ohne dass der Betrieb es merkt.

FRANZFON v1.1.0 schafft hier Abhilfe durch eine selbstheilende Verbindungsprüfung. Ein regelmäßiger, absolut stiller Selbsttest überprüft die Leitung im Hintergrund. Wird eine hängengebliebene Verbindung erkannt, baut die Anlage sie vollautomatisch und transparent wieder auf – ohne Einträge in der Anrufliste oder Signalgeräusche an den Endgeräten.

Bugfixes und Optimierungen aus der Praxis

1. Voller DECT-Support

DECT-Mobilteile werden nun unter der Sektion „Telefone“ endlich als eigenständige Endgeräte mit dedizierter Durchwahl und exaktem Online-Status aufgeführt. Zudem wurde ein schwerwiegender Bug bei Yealink-Mobilteilen (z. B. an einer W70B-Basis) behoben, bei dem die Signalisierung des Klingelzeichens zu einem sofortigen Verbindungsabbruch führte.

2. HD-Codec schlägt Hardware-Rauschen

Aufgrund eines Firmware-Fehlers neigten bestimmte Yealink-Tischtelefone beim Betrieb an Software-TK-Anlagen zu einem dauerhaften Hintergrundrauschen. FRANZFON erzwingt bei der provisionierten Einrichtung dieser Geräte nun den HD-Sprachcodec. Dies eliminiert das Rauschen vollständig und sorgt für eine verbesserte interne Sprachqualität.

3. Klartext bei der FRITZ!Box-Benennung

Wird die Telefonanlage hinter einem kaskadierten Router-Setup betrieben und ein eigener Hostname statt der Standardadresse fritz.box verwendet, quittierte das System Verbindungsfehler bisher mit einem kryptischen „Ursache unbekannt“. Die neue Version gibt nun eine präzise Fehlermeldung aus und schlägt die direkte IP-Eingabe vor.

Update-Hinweise für Administratoren

  • Backup-Pflicht: Vor dem Anstoßen des Updates in der Weboberfläche sollte die FRANZFON-VM zwingend gesichert werden (in Proxmox VE via Snapshot, in Hyper-V via Prüfpunkt).

  • Yealink-Telefone: Damit die neue HD-Codec-Konfiguration gegen das Hardware-Rauschen wirksam wird, müssen betroffene Telefone nach dem Update einmal kurz stromlos gemacht werden.

  • Fax-Erweiterung: In der Anrufliste wird bei Telefaxen nun das Label „Fax“ inkl. vollständiger Absenderkennung mit Vorwahl angezeigt. Nach dem Update erscheint auf der Fax-Seite ein Hinweis zur einmaligen Eingabe der eigenen Ortsvorwahl, um die Formatierung der Kopfzeilen auf ausgehenden PDFs zu vervollständigen.

FRANZFON Webseite: https://franzfon.de/

Paperless-ngx v3.0.0 Beta: Das DMS kriegt einen KI-Chat!

,

Paperless-ngx v3.0.0 Beta im Test: Einzug von lokalen LLMs und intelligenter Vektor-Suche

Paperless-ngx gehört für die meisten Server-Besitzer zur absoluten Standard-Ausstattung, wenn es um das papierlose Büro geht. Mit dem im GitHub-Pull-Request #12713 vorgestellten v3.0.0 Beta-Release macht das Community-Projekt nun den größten technologischen Sprung seiner Geschichte. Das System wandelt sich von einer reinen, OCR-basierten Archivierungssoftware hin zu einem intelligenten, KI-gestützten Wissensmanagement.

RAG und lokale LLMs: Die Dokumentenbox lernt sprechen

Die bahnbrechendste Neuerung in Version 3.0.0 ist das native AI-Feature-Set, das auf der RAG-Technologie (Retrieval-Augmented Generation) basiert. Über einen im Hintergrund aufgebauten Vektor-Index (unter Nutzung einer FAISS/ChromaDB-Struktur) liest das System die Dokumenteninhalte semantisch ein.

Über eine integrierte Chat-Oberfläche können Anwender fortan direkte, natürliche Fragen an ihr gesamtes Archiv richten. Die KI filtert die relevanten Dokumente heraus, generiert eine präzise Zusammenfassung und liefert die exakten Quellenverweise als anklickbare Links direkt mit. Als Backend dienen wahlweise lokale KI-Server wie Ollama (z. B. mit schlanken Modellen wie llama3.2:1b oder qwen2.5) oder externe API-Schnittstellen.

Die v3.0.0 Beta-Features in der Praxis:

  1. Intelligenter Metadaten-Assistent: Beim Bearbeiten eines Dokuments lässt sich über ein „Zauberstab“-Symbol eine KI-Analyse triggern. Das Modell liest den Kontext und schlägt auf Knopfdruck passende Korrespondenten, Kategorien und Tags vor.

  2. Erweiterte OCR-Pipelines: Neben Tesseract fließen Optimierungen für alternative Texterkennungs-Lösungen ein, darunter modernisierte Dokumenten-Parser und Schnittstellen zu spezialisierten Tools wie Mistral-OCR.

  3. Optimierte UI & Backend-Bereinigung: Das auf Django und Angular basierende Framework wurde weitreichend überarbeitet, um Datenbank-Migrationen für den finalen v3-Release vorzubereiten und Ladezeiten bei riesigen Archiven drastisch zu senken.

Wichtige Stolpersteine in der aktuellen Beta

Wie für eine Beta üblich, gibt es ein paar technische Aspekte, die Administratoren beachten müssen:

  • CPU-Timeouts bei NAS-Systemen: Wer Ollama rein auf einer CPU (ohne dedizierte Grafikkarte) betreibt, läuft bei komplexen Prompts Gefahr, in das harte 60-Sekunden-Limit von Paperless zu laufen. Hier empfiehlt sich der Einsatz von extrem kleinen, ressourcenschonenden KI-Modellen.

  • Datenbank-Konflikte (Error 500): Beim häufigen Wechsel der zugrundeliegenden Embedding-Modelle kann es zu Dimensionskonflikten im Vektor-Index kommen. Die Lösung hierfür ist das Stoppen des Containers und das Löschen des Ordners llm_index im Datenverzeichnis, woraufhin sich der Index beim Neustart sauber neu generiert.

Fazit: Die Zukunft des DMS ist smart

Mit der Version 3.0.0 hebt das Entwicklerteam Paperless-ngx auf eine völlig neue Stufe. Die nahtlose Verschmelzung von lokaler künstlicher Intelligenz und privater Dokumentenablage zeigt eindrucksvoll, was moderne Open-Source-Software im Jahr 2026 zu leisten imstande ist.

Zum offiziellen Pull Request und Diskussionsfaden: GitHub Pull Request #12713

Filery FileRenamer: Dateien massenhaft umbenennen leicht gemacht

,
Filery Renamer

Dateichaos adé: Effiziente Massenumbenennung mit dem Filery FileRenamer

Im digitalen Arbeitsalltag sammeln sich rasant riesige Mengen an Daten an. Das Problem: Automatisch generierte Dateinamen von Kameras, Scannern oder Softwaresystemen sind selten sprechend. Wenn es darum geht, hunderte oder tausende Dateien nach einem bestimmten Schema umzustrukturieren, stößt der windowseigene Explorer oder der macOS Finder schnell an seine Grenzen.

Hier setzt der FileRenamer von Filery an. Die schlanke Software hat sich darauf spezialisiert, komplexe Umbenennungs-Prozesse über eine übersichtliche Oberfläche extrem einfach gestaltbar zu machen. Ähnlich wie RenameClick und Datei-Buttler, die ich vorgestellt habe.

Flexibilität durch ein modulares Regelsystem

Die Stärke des FileRenamers liegt in seiner Vielseitigkeit. Anstatt starre Vorgaben zu machen, erlaubt das Tool das Kombinieren verschiedener Regeln, die nacheinander auf die Dateiliste angewendet werden. Man kann sich die Dateinamen nach seinem Wunsch bilden, bestehend aus den Dokumentinformationen, damit man am Ende ein sauberes und klares Namesbild erhält, was sich über alle Dateien erstreckt. Ein paar Bilder aus der Software und Einstellungen.

 

  • Filery -KI Renamer #1 - Übersicht
  • Filery -KI Renamer #6 - Einstellungen Eigene Firmen
  • Filery -KI Renamer #5 - Einstellungen Geschäftspartner
  • Filery -KI Renamer #4 - Einstellungen Dokumenttypen
  • Filery - KI Renamer #3 - Einstellungen Bennenung
  • Filery -KI Renamer #2 - Konto

 

Die Lebensversicherung: Echtzeit-Vorschau

Jeder Systemadministrator weiß, wie gefährlich das automatisierte Umbenennen von Dateien sein kann. Ein kleiner Fehler im Muster, und wichtige Systemzuordnungen gehen verloren.

Der FileRenamer löst dieses Problem durch eine interaktive Live-Vorschau. Jede Änderung an den Regeln wird sofort in einer Gegenüberstellung von „Alter Name“ und „Neuer Name“ angezeigt. Erst wenn das Ergebnis zu 100 % den Erwartungen entspricht, wird der Prozess mit einem Klick auf den Ausführen-Button gestartet.

Fazit: Ein unverzichtbares Utility-Tool

Der Filery FileRenamer glänzt dort, wo manuelle Arbeit versagt. Er spart wertvolle Lebenszeit, minimiert die Fehlerquote bei der Datenpflege und sorgt im Homelab wie auch im professionellen Office im Handumdrehen für eine saubere, standardisierte Verzeichnisstruktur. Es gibt die Möglichkeit, auch einen Test mit 50 Dateien durchzuführen, ob es den eigenen Anforderungen entspricht, und zwar in der Free Variante. Die Verwendung eines eigenen LLM oder eines eigenen API-Keys für LLM kostet hier 5€ monatlich.

Direkt zum Download: Filery FileRenamer Landingpage

FRANZFON: Die Lösung für VoIP-Probleme der FRITZ!Box

Franzfon

Die FRITZ!Box im Business-Einsatz: Welche Probleme FRANZFON im Büroalltag löst

In zahllosen kleinen Unternehmen, Arztpraxen und Kanzleien verrichtet eine AVM FRITZ!Box zuverlässig ihren Dienst als Router und Telefonzentrale. Doch im professionellen Alltag stoßen Administratoren und Mitarbeiter schnell an funktionale Grenzen. Bisher bedeutete der Schritt zu einer professionellen Telefonanlage meist den Umstieg auf eine kostspielige Cloud-Lösung mit monatlichen Gebühren pro Arbeitsplatz.

Mit FRANZFON gibt es nun eine selbst gehostete Alternative, die genau dort ansetzt, wo die FRITZ!Box an ihre Grenzen stößt. FritzBox ist sicherlich nichts, was im Mittelstand eingesetzt wird. Es gibt jedoch viele Büros und Kleinunternehmer, die damit arbeiten. Die Lösung ist ein schöner Ansatz für eine vernünftige TK-Anlage, angebunden an der Fritzbox. Projekt befindet sich noch im Beta-Stadium, bin selbst auch noch ein Beta-Tester, Viktor von IAP-IT haut derzeit auch täglich neue Updates raus. 😉 Sehr viele Funktionalitäten sind enthalten. Das Projekt ist durchaus anspruchsvoll und spannend. Apps für Android, iOS und Windows/Linux sind auch da. 30 Tage Demo-Phase: alle Features ohne Limits. Danach gelten die Free-Beschränkungen für alle, die es interessiert.

Die klassischen Baustellen im Büro-Alltag

1. Das Softphone-Problem: Telefonieren am Arbeitsplatz

Wer im Büro flexibel am PC oder Laptop mit dem Headset telefonieren möchte, sucht bei klassischen Routern vergeblich nach einer komfortablen Software. FRANZFON löst dies durch native Desktop- und Mobil-Apps für Windows, Linux, iOS und Android. Eingehende Anrufe werden auf dem Smartphone via Push-Dienst signalisiert, was den Akku schont und die ständige Erreichbarkeit unter der Büronummer sichert.

2. Das Synchronisations-Chaos im Adressbuch

Nichts ist im Kundenkontakt störender als veraltete Rufnummern auf den Telefonen der Mitarbeiter. Da die Synchronisation verschiedener Cloud-Telefonbücher mit der FRITZ!Box oft fehleranfällig ist, bietet FRANZFON ein zentrales, globales Kontaktmanagement. Ändert ein Mitarbeiter eine Telefonnummer, steht der Datensatz Millisekunden später dem gesamten Team auf allen Endgeräten zur Verfügung.

3. Effizientes Arbeiten mit Klingelgruppen und Makeln

Klassische Telefonie-Workflows wie „Ich verbinde Sie weiter mit der Buchhaltung“ oder das parallele Klingeln einer Support-Gruppe lassen sich mit Standard-Routern nur über komplexe Tastencodes abbilden. FRANZFON basiert im Kern auf der bewährten Open-Source-Telefonanlage Asterisk und stellt Funktionen wie Makeln, Halten, Weiterleiten mit/ohne Ankündigung sowie flexible Rufgruppen über eine intuitive Oberfläche bereit.

4. Zeitfresser Anrufbeantworter

Das manuelle Abhören von Voicemails kostet Zeit und Nerven. FRANZFON integriert hierzu eine moderne Whisper-KI: Hinterlässt ein Kunde eine Nachricht auf dem Band, transkribiert das System das gesprochene Wort vollautomatisch in Text. Der Mitarbeiter kann die Nachricht bequem lesen, anstatt sie minutengelang anzuhören.

Technische Umsetzung: Keine Cloud, volle Kontrolle

FRANZFON wird als schlüsselfertiges Virtual-Machine-Image (VMA) bereitgestellt und läuft hervorragend als ressourcensparende VM (ca. 3 GB) in der eigenen Proxmox VE-Umgebung. Die vorhandene FRITZ!Box bleibt dabei einfach als Schnittstelle zum Telefonanbieter (SIP-Gateway) bestehen.

Dadurch, dass alle Daten im eigenen Netzwerk verbleiben, entfällt das Risiko von Datenabflüssen an Drittanbieter komplett – ein unschätzbarer Vorteil für die DSGVO-Compliance in sensiblen Branchen wie dem Rechts- oder Gesundheitswesen.

Fazit

FRANZFON repariert die funktionalen Schwachstellen der FRITZ!Box, ohne dass Unternehmen ihre bewährte Hardware austauschen oder sich in langjährige Cloud-Knebelverträge stürzen müssen. Ein transparenter Festpreis statt Abo-Modell pro Nutzer macht die Lösung besonders für wachsende Teams attraktiv.

Detaillierte Problemanalysen und Dokumentation: FRANZFON – Was wir lösen

Flipper One angekündigt: Der neue Linux-Hacker-PC im Check

,

Flipper One offiziell angekündigt: Ein radikal offenes Linux-Cyberdeck für Hacker

Der Flipper Zero war ein globales Phänomen, das über 150 Millionen Dollar Umsatz generierte. Doch anstatt sich auf dem Erfolg auszuruhen, schlägt Flipper Devices nun einen völlig neuen Weg ein. Mit dem Blogpost „Flipper One — we need your help“ bricht das Team sein langes Schweigen und stellt eine Plattform vor, die das Konzept mobiler Pentesting- und Bastel-Hardware komplett neu definiert.

Kein Flipper Zero 2: Der Sprung in den Linux-Sektor

Das Wichtigste vorweg: Der Flipper One ist kein Ersatz für den Flipper Zero. Während der Zero als kompakter Mikrocontroller für Point-to-Point-Funkprotokolle (Sub-GHz, RFID, NFC) konzipiert war, agiert der Flipper One eine Ebene höher im Software-Stack. Es handelt sich um einen vollwertigen Arm-Linux-Computer im Hosentaschenformat.

Die Hardware-Architektur im Fokus

Das Herzstück bildet ein leistungsstarker 8-Kern-SoC (Rockchip RK3576), unterstützt von 8 GB RAM und einer Mali-G52 Grafikeinheit. Für die Zukunft gerüstet ist das Gerät durch eine integrierte NPU (Neural Processing Unit), mit der sich lokale KI-Modelle und LLMs direkt auf dem Gadget betreiben lassen.

Im Gegensatz zum Zero wurden klassische Funkmodule von der Hauptplatine verbannt. Der Flipper One setzt stattdessen radikal auf High-Speed-Netzwerke und Modularität:

  • Zwei native 1-Gbit/s-Ethernet-Ports für kabelgebundene Netzwerkananalysen.

  • Integriertes Wi-Fi 6E.

  • Ein hochflexibles Erweiterungssystem, das Verbindungen über PCI Express (M.2-Formfaktor), USB 3.0 und SATA erlaubt, um beispielsweise 5G-Modems oder SSDs anzubinden.

Das Experiment: Entwicklung als Reality-Show

Die eigentlich bemerkenswerte Nachricht dieses Releases ist nicht die Hardware, sondern der unkonventionelle Entwicklungsprozess. Der CEO Pavel Zhovner gibt offen zu, dass das Projekt das Team finanziell und technisch an die Grenzen bringt – verschärft durch die aktuelle weltweite RAM-Krise.

Deshalb hat sich das Unternehmen mit den Open-Source-Spezialisten von Collabora zusammengetan. Das erklärte Ziel: Den Rockchip-Prozessor vollständig in den Mainline-Linux-Kernel zu integrieren und proprietäre Binär-Treiber (Blobs) loszuwerden.

Es gibt noch kein Release-Datum und keinen Preis. Stattdessen hat Flipper das Flipper One Developer Portal ins Leben gerufen. Die gesamte Dokumentation und die 3D-Gehäusemodelle stehen ab Tag eins offen im Netz. Die Community soll aktiv mithelfen – sei es beim Kernel-Coding, beim Aufspüren von Treiber-Problemen oder beim Designen von Erweiterungsmodulen.

Fazit: Ein mutiger und richtiger Schritt

Der Flipper One ist ein Traum für ambitionierte Systemadministratoren, Netzwerktechniker und Hardware-Hacker. Durch den Verzicht auf eingebaute SDR- und RFID-Technik wird das Gerät zwar auf Module angewiesen sein, gewinnt dadurch aber die Flexibilität eines echten Mini-PCs. Dass Flipper den Weg der maximalen Transparenz wählt, anstatt ein unfertiges Produkt auf den Markt zu werfen, verdient großen Respekt.

Zum offiziellen Aufruf: Flipper Blog – Flipper One We Need Your Help

PatchMon 1.4.2 (Bare Metal Legacy) > Patchmon 2.0.2 Docker migration

Hier noch mal die Schritte, wie man die normale Bare-Metal-Legacy-Installation von PatchMon auf die aktuelle mit Docker migriert.

Wichtig immer vorher System sichern!

Migration:
Snapshot oder Backup  vom System erstellen bevor man beginnt!:

DB Backup:
sudo -u postgres pg_dump \
-d patchmon \
-Fc \
–no-owner \
–no-privileges \
-f /tmp/patchmon-$(date +%Y%m%d-%H%M%S).Dump

Docker installieren:
Debian repos:
sudo apt install ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/debian/gpg | sudo gpg –dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg
echo „deb [arch=$(dpkg –print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/debian $(lsb_release -cs) stable“ | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt update

Ubuntu repos:
sudo apt install ca-certificates curl gnupg
sudo install -m 0755 -d /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg –dearmor -o /etc/apt/keyrings/docker.gpg
sudo chmod a+r /etc/apt/keyrings/docker.gpg
echo „deb [arch=$(dpkg –print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu$(lsb_release -cs) stable“ | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null
sudo apt update

Neuen default Ordner für Patchmon erstellen, ins Verzeichnis wechseln und dann den DB Backup hineinverschieben:
mkdir /opt/patchmon
cd /opt/patchmon
mv /tmp/patchmon-*.dump /opt/patchmon

Während der Installation entsprechend die Fragen beantworten. Die CORS_ORIGIN URLs entsprechend eintragen. Nach der Installation Patchmon noch NICHT mit docker compose starten!

Patchmon Installation setup starten:
bash -c „$(curl -fsSL https://raw.githubusercontent.com/PatchMon/PatchMon/refs/heads/main/docker/setup-env.sh)“

Wir starten zunächst nur die Datenbank:
docker compose up -d database

Backup von der Datenbank wiederherstellen:
cd /opt/patchmon
docker compose exec -T database pg_restore \
-U patchmon_user \
-d patchmon_db \
–no-owner –no-privileges –role=patchmon_user \
< /opt/patchmon/patchmon-*.dump

Überprüfen Sie die .env ob die Ports identisch wie in der alten Installation sind; wenn nicht, passen Sie sie entsprechend an, wie man das System davor konfiguriert hat.
nano .env

Die docker-compose.yml überprüfen, ob die Ports richtig sind und die alten Ports entsprechen!
nano docker-compose.yml

Alle alten Services stoppen: Wenn man SSL eingerichtet hat, entsprechend die nginx Konfig anpassen.
systemctl stop nginx
systemctl disable nginx
systemctl stop patchmon

Jetzt können wir den Docker Container starten:
docker compose up -d