Inventory/docs/serverbetrieb.md

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