# Historische Betriebsnotizen: 192.168.188.45 Die aktuelle Arbeitsanleitung für Kollegen steht vollständig in [LOCAL_DEPLOY.md](LOCAL_DEPLOY.md). Die folgenden Abschnitte dokumentieren frühere Installationen und Prüfungen; sie bestätigen nicht den heutigen Serverzustand. 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 damalige öffentliche Stammzertifikat wurde als `homelab-root-ca.crt` verteilt und lag auf dem Server unter `/home/denis/csr-inventory-root-ca.crt`. Die frühere Repository-Kopie wurde entfernt; für die aktuelle Installation das in [LOCAL_DEPLOY.md](LOCAL_DEPLOY.md) beschriebene Zertifikat beziehen. 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. Das damalige Importbeispiel setzte eine separat bereitgestellte Zertifikatsdatei im lokalen Verzeichnis `docs/` voraus: ```powershell Import-Certificate -FilePath .\docs\homelab-root-ca.crt -CertStoreLocation Cert:\CurrentUser\Root ``` SHA-256-Fingerabdruck des Stammzertifikats: ```text 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](traefik.md). ## Verwaltung Der SSH-Benutzer `denis` hat keine direkten Docker- oder sudo-Rechte. Zur Verwaltung wie bei der Installation eine Root-Sitzung öffnen: ```sh 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 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. ```sh 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](datenbankschema.md) beschrieben.