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

Der Beitrag Debian 12 auf 13 Upgrade im Proxmox LXC Container erschien zuerst auf Ivan Ivanov.

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:

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.

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.:

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

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.

Der Beitrag Paperless-ngx Upgrade: von 2.20.15 auf 3.0.4 (Debian-VM auf Proxmox) erschien zuerst auf Ivan Ivanov.

Was ist der Proxmox Datacenter Manager (PDM)?

Während Proxmox VE und PBS fantastische Tools für einzelne Cluster und Backup-Instanzen sind, fehlte es Unternehmenskunden mit mehreren Rechenzentren, dutzenden Clustern und hunderten Nodes bisher an einer zentralen, übergreifenden Steuerungsebene. Genau diese Lücke schließt der PDM.

Der PDM 1.0 agiert als zentrale Management-Konsole, die das gesamte Proxmox-Ökosystem in Ihrer Organisation an einem Ort zusammenführt.

Die wichtigsten Funktionen im Überblick

Der Fokus des PDM liegt auf Effizienz, Sicherheit und Skalierbarkeit für große Infrastrukturen:

• Zentralisierte Verwaltung: Schluss mit dem ständigen Wechsel zwischen verschiedenen Web-UIs. PDM bietet eine zentrale Oberfläche, über die Sie alle verbundenen Proxmox VE Cluster und Proxmox Backup Server Instanzen managen können.

• Single Sign-On (SSO): Dank integriertem SSO-Mechanismus können sich Administratoren einmal anmelden und haben sofort sicheren Zugriff auf alle verwalteten Proxmox-Ressourcen.

• Feingranulare Zugriffsverwaltung: Der PDM ermöglicht es Ihnen, präzise Zugriffsrichtlinien für Administratoren und Teams festzulegen, was für die Einhaltung von Unternehmensrichtlinien unerlässlich ist.

• Verbesserte Skalierbarkeit: Die Architektur des PDM wurde speziell entwickelt, um eine hohe Anzahl von Nodes und Clustern effizient zu handhaben, ohne dass die Performance leidet.

Warum ist PDM 1.0 ein Game Changer?

Die Einführung des PDM 1.0 ist ein entscheidender Schritt für Proxmox, da es die Suite nun zu einer vollwertigen, Enterprise-tauglichen Lösung für das Hyperscale-Management macht. Administratoren sparen wertvolle Zeit, indem sie Routineaufgaben zentral erledigen können und die Komplexität der Gesamtumgebung drastisch reduziert wird.

Gleichzeitig bleibt Proxmox seiner Open-Source-Philosophie treu und bietet Transparenz und Flexibilität.

Wir empfehlen allen Administratoren von größeren Proxmox-Umgebungen, sich die Features des PDM 1.0 genau anzusehen. Es ist das fehlende Puzzleteil für eine zentralisierte und skalierbare Proxmox-Strategie.

Quelle und weitere Details: https://www.proxmox.com/de/ueber-uns/details-unternehmen/pressemitteilungen/proxmox-datacenter-manager-1-0

Der Beitrag Proxmox revolutioniert Datacenter-Management: Proxmox Datacenter Manager (PDM) 1.0 ist da erschien zuerst auf Ivan Ivanov.

Mit ProxLB lassen sich VM-Gruppen intelligent bündeln oder gezielt trennen – das sorgt jederzeit für optimale Performance und Zuverlässigkeit auf allen Nodes. Die dynamische Lastverteilung basiert auf Messungen von CPU, RAM und Disk und verhindert dauerhaft überlastete Systeme. Besonders komfortabel: ProxLB arbeitet direkt und ausschließlich über die Proxmox API, ohne eigenen Authentifizierungsmechanismus – maximale Sicherheit inklusive.

Ob als One-Shot-Tool für akuten Ausgleich oder als periodischer Systemdienst für kontinuierliche Balance – ProxLB passt sich an jede Cluster-Strategie an. Free & Open-Source (GPLv3) und bequem per Paket, Container-Image oder GitHub-Repo installierbar.

Perfekt für alle, die echtes On-Premises-Cluster-Management wollen, ohne auf teure Zusatzlösungen zu setzen.

Projekt-Webseite: https://proxlb.de/
GitHub: https://lnkd.in/ekuXS5P4

Der Beitrag Prox Load Balancer (ProxLB) für Proxmox erschien zuerst auf Ivan Ivanov.

️ Übersicht & Vorbereitung

• Wichtig: Erstelle vollständige und getestete Backups aller VMs und Container (z. B. mittels Proxmox Backup Server oder vzdump). Teste auch die Wiederherstellung in einer Lab-Umgebung

• Stelle sicher, dass du mindestens 5 GB freien Speicherplatz auf dem Root-Dateisystem hast (10 GB empfohlen)

• Verwende eine alternative Management-Verbindung wie IPMI, iKVM oder direkten Konsolenzugriff – SSH allein kann riskant sein, wenn der Netzwerkstack während des Upgrades neu konfiguriert wird

Testen des Upgrades

• Richte eine Testinstanz ein (z. B. eine VM oder Testhardware mit Proxmox VE 8.4), und führe dort das Upgrade durch, bevor du es im Produktivsystem anwendest.

• Führe das Script pve8to9 mehrfach aus (am besten mit --full), um potenzielle Problempunkte frühzeitig zu erkennen.

Schritt-für-Schritt Anleitung

Schritt 1: Checkliste & Vorarbeiten

1. Sichere VMs/CTs vollständig.

2. Führe
   pve8to9 --full
   aus, behebe gemeldete Warnungen, und führe es erneut aus.

Schritt 2: Repositories aktualisieren

3. Aktualisiere dein System auf den neuesten Stand von Proxmox 8.4:

   apt update
apt full-upgrade

4. Ändere in /etc/apt/sources.list bzw. /etc/apt/sources.list.d/* Bookworm → Trixie:

   sed -i 's/bookworm/trixie/g' /etc/apt/sources.list
sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/pve-enterprise.list


5. Füge das Repository für Proxmox VE 9 hinzu (z. B. pve-test):

   echo "deb http://download.proxmox.com/debian/pve trixie pve-test" > /etc/apt/sources.list.d/pve9.list


6. Ergänze ggf. Ceph‑Repository, wenn du Ceph verwendest.

Schritt 3: Systemupgrade durchführen

7. Aktualisiere Apt-Indizes:

   apt update
apt full-upgrade -y


8. Falls behoben: Neuere Kernel und Software (Debian Trixie + Proxmox VE 9) werden installiert. Reboot erforderlich:

   reboot


Schritt 4: Nach dem Reboot

9. Kernel-Check: uname -r sollte auf die neue Version (6.14.x) hinweisen.

10. Überprüfe alle Dienste und VMs/CTs.

11. Führe nach Möglichkeit erneut pve8to9 aus, um weitere Hinweise nach dem Upgrade zu bekommen.

Besonderheiten & bekannte Fallstricke

• Ceph‑Upgrade nötig? Wenn du Ceph von Reef (8.4) nutzt, musst du ggf. vor dem VE‑Upgrade von Reef auf Squid upgraden

• Namensänderungen bei NICs: Der Kernel 6.14 kann neue Netzwerk-Interface-Namen verursachen. Proxmox VE 9 erlaubt die Verwendung von Aliasnamen, aber Firewall- oder Netzwerkkonfigurationen sollten überprüft werden

• cgroup‑v1 Entfernung, GRUB Probleme bei LVM‑UEFI, NVIDIA vGPU Inkompatibilitäten – siehe Abschnitt „Known Upgrade Issues“ der offiziellen Anleitung

Upgrade ein Beispielskript (CLI)

Der Beitrag Proxmox Upgrade 8.4.x > 9.x erschien zuerst auf Ivan Ivanov.

Ziel:

• Erstellen von Netzwerkbrücken für VMs/Container
• VLANs für segmentiertes Netzwerk

Schritt 1: Bridge konfigurieren

Bearbeite /etc/network/interfaces:

auto vmbr0
iface vmbr0 inet static
    address 192.168.1.10
    netmask 255.255.255.0
    gateway 192.168.1.1
    bridge_ports enp3s0
    bridge_stp off
    bridge_fd 0

Schritt 2: VLANs anlegen

Für VLAN 10 auf vmbr0:

auto vmbr0.10
iface vmbr0.10 inet static
    address 192.168.10.1
    netmask 255.255.255.0
    vlan-raw-device vmbr0

Tipps:

• VLAN-Tagging funktioniert nur mit VLAN-fähigem Switch

Der Beitrag Proxmox – Netzwerkbrücken und VLANs in Proxmox einrichten erschien zuerst auf Ivan Ivanov.

Schritt 1: Template herunterladen

Unter „Storage“ > „CT Templates“ ein passendes Template herunterladen

Schritt 2: Container erstellen

• „Create CT“ klicken
• Hostname, Passwort und Template wählen
• Ressourcen und Netzwerk konfigurieren

Schritt 3: Container starten

• Container starten, Konsole öffnen, System konfigurieren

Tipps:

• Container starten schneller, ideal für Webserver und kleine Dienste

Der Beitrag Proxmox – LXC-Container erstellen und verwalten erschien zuerst auf Ivan Ivanov.

Schritt 1: ISO-Image hochladen

Im Webinterface unter „Storage“ > „local“ > „Content“ das ISO hochladen

Schritt 2: Neue VM erstellen

• „Create VM“ klicken
• Name vergeben
• ISO wählen, Hardware (CPU, RAM, Festplatte, Netzwerk) konfigurieren
• Zusammenfassung prüfen, „Finish“

Schritt 3: VM starten

• VM auswählen, starten, Konsole öffnen und OS installieren

Tipps:

• VirtIO-Treiber für bessere Leistung verwenden
• Snapshots vor großen Änderungen machen

Der Beitrag Proxmox – Erstellung und Verwaltung von virtuellen Maschinen (VMs) erschien zuerst auf Ivan Ivanov.

Voraussetzungen:

• 64-Bit CPU mit Virtualisierungstechnologie (Intel VT-x oder AMD-V)
• Mindestens 8 GB RAM
• Zwei Festplatten (empfohlen für ZFS RAID1)
• Bootfähiger USB-Stick mit Proxmox VE ISO

Schritt 1: ISO herunterladen und USB-Stick erstellen

Lade die aktuelle Proxmox VE ISO herunter und erstelle mit balenaEtcher einen bootfähigen USB-Stick.

Schritt 2: BIOS/UEFI konfigurieren

• Aktiviere VT-x/AMD-V sowie IOMMU (Intel VT-d/AMD-Vi)
• Stelle die Boot-Reihenfolge auf USB-Start um

Schritt 3: Proxmox VE installieren

• Vom USB-Stick booten, „Install Proxmox VE“ wählen
• Lizenz akzeptieren, Ziel-Festplatte und Dateisystem (z.B. ZFS RAID1) auswählen
• Standort, Zeitzone, Tastatur, Root-Passwort und Netzwerk konfigurieren

Schritt 4: Webinterface aufrufen

Nach dem Neustart ist das Webinterface über https://ip-adresse-des-servers:8006 erreichbar.

Tipps:

• Nutze das No-Subscription-Repository, wenn du keine Enterprise-Lizenz besitzt
• Systemaktualisierung: apt update && apt full-upgrade

Der Beitrag Proxmox VE 8.x Installation auf Bare-Metal: Step-by-Step Anleitung erschien zuerst auf Ivan Ivanov.