Inventory/docs/serverbetrieb.md

Serverbetrieb auf 192.168.188.45

Stand: 26. September 2026. Die Anwendung wurde auf dem Debian-Server homelab installiert und gegen PostgreSQL geprüft.

Zugriff

• Anwendung: https://192.168.188.45/
• Anmeldung: https://192.168.188.45/accounts/login/
• Der bisherige Port http://192.168.188.45:8001/ leitet auf HTTPS weiter.
• Die Benutzerkonten und Passwort-Hashes aus der lokalen Projektdatenbank wurden übernommen. Bestehende Anmeldedaten bleiben gültig.
• Installationsverzeichnis: /home/denis/csr-inventory

Die Anwendung läuft mit deaktiviertem Debugmodus, sicheren Cookies und einer separaten PostgreSQL-Datenbank. Nur Traefik veröffentlicht Webports; PostgreSQL und Gunicorn sind nicht direkt über veröffentlichte Docker-Ports erreichbar.

HTTPS im lokalen Netzwerk

Traefik verwendet für die private IP-Adresse eine lokale Zertifizierungsstelle. Das öffentliche Stammzertifikat liegt in homelab-root-ca.crt und auf dem Server unter /home/denis/csr-inventory-root-ca.crt.

Damit Windows-Browser dem Zertifikat vertrauen, kann es für den aktuellen Benutzer importiert werden. Dieser Schritt wurde auf dem Arbeitsplatz nicht automatisch ausgeführt. Im lokalen Projektverzeichnis:

Import-Certificate -FilePath .\docs\homelab-root-ca.crt -CertStoreLocation Cert:\CurrentUser\Root

SHA-256-Fingerabdruck des Stammzertifikats:

7B:15:0B:52:62:81:68:3D:93:AA:CE:96:63:FD:23:9E:37:E2:AE:F3:6C:F3:E7:AB:E4:91:A6:F7:F9:8F:ED:05

Die Serverdatei docker-compose.override.yml entspricht docker-compose.lan.yml und veröffentlicht zusätzlich den Weiterleitungsport 8001. Traefik verwendet den File-Provider ohne Docker-Socket und ohne veröffentlichtes Dashboard. Statische Dateien liefert Django über WhiteNoise aus.

Die bisherige Stamm-CA bleibt erhalten. Ihr privater Schlüssel liegt ausschließlich auf dem Host unter tls/ca/root.key. Traefik erhält nur die Serverzertifikate. Der Timer csr-inventory-tls.timer prüft täglich um 01:30 Uhr die Gültigkeit und erneuert 90-Tage-Zertifikate bei weniger als 30 Tagen Restlaufzeit. Traefik lädt neue Zertifikate automatisch. Einrichtung und Wartung: Traefik.

Verwaltung

Der SSH-Benutzer denis hat keine direkten Docker- oder sudo-Rechte. Zur Verwaltung wie bei der Installation eine Root-Sitzung öffnen:

ssh denis@192.168.188.45
su -
cd /home/denis/csr-inventory
docker compose ps
docker compose logs --tail 100 web traefik

Nach Änderungen am Anwendungscode neu bauen und starten:

sh scripts/backup.sh
docker compose up -d --build --wait web traefik

Die individuellen Anwendungs- und Datenbankgeheimnisse stehen ausschließlich in der geschützten .env auf dem Server. Bei Aktualisierungen diese Datei, die Serverüberschreibung und die persistenten Volumes beibehalten.

Datenbankzugriff mit DBeaver

PostgreSQL wird nur auf 127.0.0.1:15432 des Servers veröffentlicht. Für DBeaver einen PostgreSQL-Anschluss mit Host 127.0.0.1, Port 15432, Datenbank csr_inventory und Benutzer csr_inventory anlegen. Im Reiter SSH einen Tunnel zu 192.168.188.45:22 mit dem SSH-Benutzer denis einrichten. Die Datenbank bleibt über die LAN-Adresse auf Port 15432 unerreichbar.

Das Datenbankpasswort ist POSTGRES_PASSWORD in der geschützten .env. Als Root auf dem Server kann es mit sed -n 's/^POSTGRES_PASSWORD=//p' /home/denis/csr-inventory/.env für die Eingabe in DBeaver angezeigt werden. Das SSH-Passwort ist getrennt vom Datenbankpasswort. In DBeaver die Verbindung über die Host-Felder konfigurieren, nicht über eine fest eingetragene JDBC-URL.

Datensicherung

• PostgreSQL-Sicherungen: /home/denis/csr-inventory/backups/
• Automatische Sicherung: täglich um 02:00 Uhr Europe/Berlin.
• Timer: csr-inventory-backup.timer
• Dienst: csr-inventory-backup.service
• Der tägliche Job sichert die Datenbank. Upload-Dateien liegen im persistenten Media-Volume. Die TLS-Zertifizierungsstelle und Serverzertifikate liegen im Projektverzeichnis tls/. Diese Daten und die geschützte .env müssen separat gesichert werden.

systemctl list-timers csr-inventory-backup.timer
journalctl -u csr-inventory-backup.service --no-pager
sh scripts/backup.sh

Eine erste PostgreSQL-Sicherung wurde erfolgreich in eine separate temporäre Datenbank zurückgespielt und die Geräteanzahl verglichen. Die Prüfdatenbank wurde anschließend entfernt.

Ablösung der bisherigen Inventarsoftware

Die Container computerspende-inventar-web-1 und computerspende-inventar-db-1 sowie deren Compose-Netzwerk wurden entfernt. Die anderen Anwendungen auf dem Server laufen weiter.

Vor der Entfernung wurden Datenbank, Anwendungskonfiguration und Uploads unter /root/csr-retired-inventory-20260923/ gesichert. Die alten Docker-Volumes und das bisherige Quellverzeichnis wurden für eine mögliche Wiederherstellung erhalten. Die Daten dieser anderen Anwendung wurden nicht mit der neuen Datenbank vermischt.

Durchgeführte Prüfungen

• Alle 53 Tests mit PostgreSQL erfolgreich, einschließlich gleichzeitiger Bearbeitungen.
• Django-Produktionsprüfung ohne Beanstandungen.
• 109 exportierte Datensätze übernommen, darunter zwei Geräte und die vorhandenen Benutzerkonten.
• HTTPS-Zertifikatsprüfung, Healthcheck, Loginseite und statische Dateien vom Server und vom Arbeitsplatz geprüft.
• API-Zugriff ohne Schlüssel wird mit HTTP 401 abgewiesen.
• Weiterleitung vom bisherigen Port 8001 geprüft.
• Datenbank-Backup und Wiederherstellung in eine separate Prüfdatenbank erfolgreich.

Datenbank- und UI-Update vom 26. September 2026

Vor Migration 0009/0010 wurde eine neue PostgreSQL-Sicherung erstellt. 61 Tests bestanden mit PostgreSQL 17. Die drei vorhandenen Geräte blieben erhalten und besitzen jetzt jeweils einen Datensatz in inventory_computerspecification. Die alten Hardware-Spalten in inventory_device wurden entfernt. Beide Migrationen sind angewendet; der Web-Container ist gesund. Der neue Ablauf unter /ablauf/ antwortet für angemeldete Benutzer erfolgreich. Healthcheck, Login, CSS und API-Schutz wurden nach dem Neustart geprüft.

Arbeitsschritt-Formulare vom 26. September 2026

Vor Migration 0011 wurde erneut eine PostgreSQL-Sicherung erstellt. Die Migration ergänzt getrennte Tabellen für Inspektionsbefunde und Reparaturarbeiten. Im Ablauf-Board können Bearbeiter während der Inspektion Mängel und technische Daten, während der Reparatur die Arbeiten und während der Lagerung den Empfänger eintragen. 63 Tests bestanden auf PostgreSQL 17. Nach dem Neustart waren alle drei vorhandenen Geräte erhalten; das Board antwortete angemeldet mit HTTP 200 und der Web-Container war gesund. Healthcheck, Loginseite und CSS antworteten ebenfalls mit 200.

Gerätetyp-Schema vom 28. September 2026

Vor Migration 0012 wurde eine PostgreSQL-Sicherung erstellt. 64 Tests bestanden mit PostgreSQL 17. Die Migration verschob die vier vorhandenen Geräte in drei Laptop-Spezifikationen und eine Desktop-Spezifikation; die allgemeine Computertabelle enthält danach keine dieser Geräte mehr. Die Tabellen für AiO, Monitor und Drucker sind vorhanden. Geräteliste, Ablauf, Übersicht, Detailseite, Healthcheck und Loginseite wurden nach dem Neustart erfolgreich geprüft. Das Ablauf-Board antwortete angemeldet in etwa 0,3 Sekunden. Das Schema ist unter Datenbankschema beschrieben.