161 lines
7.3 KiB
Markdown
161 lines
7.3 KiB
Markdown
# 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](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:
|
|
|
|
```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.
|