291 lines
5.1 KiB
Markdown
291 lines
5.1 KiB
Markdown
# Info-Board Neu - Server-Konzept
|
|
|
|
## Ziel
|
|
|
|
Der Server ist die zentrale Steuer- und Verwaltungsinstanz der Plattform.
|
|
|
|
Er soll:
|
|
|
|
- Benutzer, Firmen und Screens verwalten
|
|
- Medien und Playlists bereitstellen
|
|
- globale Templates und Kampagnen steuern
|
|
- Provisionierung neuer Screens ausloesen
|
|
- Status, Screenshots und Heartbeats sammeln
|
|
- MQTT und HTTPS sauber trennen
|
|
|
|
## Grundprinzip
|
|
|
|
Der Server ist die Quelle der fachlichen Wahrheit.
|
|
|
|
Der Player bleibt trotzdem lauffaehig, wenn der Server temporaer nicht erreichbar ist.
|
|
|
|
Das bedeutet:
|
|
|
|
- Server verwaltet Konfiguration und Inhalte zentral
|
|
- Player fuehrt lokal und robust aus
|
|
- Server sendet Steuerimpulse, Player synchronisiert aktiv nach
|
|
|
|
## Hauptkomponenten
|
|
|
|
### Reverse Proxy
|
|
|
|
Aufgaben:
|
|
|
|
- TLS-Terminierung
|
|
- Routing fuer API und Web-UIs
|
|
- optionale Auth-/Header-Regeln
|
|
|
|
### Backend-API
|
|
|
|
Bevorzugte Sprache:
|
|
|
|
- `Go`
|
|
|
|
Aufgaben:
|
|
|
|
- Authentifizierung und Autorisierung
|
|
- CRUD fuer Tenants, Users, Screens, Medien, Playlists
|
|
- Verwaltung globaler Templates und Kampagnen
|
|
- Player-Sync-Endpunkte
|
|
- Speicherung von Status und Screenshots
|
|
- Start von Provisionierungsjobs
|
|
|
|
### Admin-UI
|
|
|
|
Aufgaben:
|
|
|
|
- Gesamtübersicht aller Screens
|
|
- Vorschau und Status
|
|
- Template-/Kampagnenverwaltung
|
|
- Kommandos und Provisionierung
|
|
|
|
### Tenant-UI
|
|
|
|
Aufgaben:
|
|
|
|
- Uploads und Medienverwaltung pro Firma
|
|
- Pflege der monitorbezogenen Playlist
|
|
- Vorschau des eigenen Screens
|
|
|
|
### Datenbank
|
|
|
|
Empfehlung:
|
|
|
|
- PostgreSQL
|
|
|
|
Aufgaben:
|
|
|
|
- Speicherung fachlicher Daten
|
|
- Status, Jobs, Revisionen, Zuordnungen
|
|
|
|
### MQTT-Broker
|
|
|
|
Empfehlung:
|
|
|
|
- Mosquitto
|
|
|
|
Aufgaben:
|
|
|
|
- Heartbeats
|
|
- Statusmeldungen
|
|
- Events
|
|
- Kommandos und ACKs
|
|
|
|
### Dateispeicher
|
|
|
|
Aufgaben:
|
|
|
|
- Uploads
|
|
- Screenshots
|
|
- ggf. serverseitig vorbereitete Medien
|
|
|
|
V1:
|
|
|
|
- Dateisystem ausreichend
|
|
|
|
## Fachliche Bereiche
|
|
|
|
## 1. Mandanten und Benutzer
|
|
|
|
Der Server trennt:
|
|
|
|
- globale Admins
|
|
- tenantgebundene Nutzer
|
|
|
|
Regel:
|
|
|
|
- Firmen sehen nur ihren Bereich
|
|
- Admins sehen alles
|
|
|
|
## 2. Screen-Verwaltung
|
|
|
|
Der Server kennt jeden Screen mit:
|
|
|
|
- ID
|
|
- Name
|
|
- Klasse
|
|
- Orientierung
|
|
- Rotation
|
|
- Tenant-Zuordnung
|
|
- technischem Registrierungsstatus
|
|
|
|
## 3. Medienverwaltung
|
|
|
|
Der Server verwaltet:
|
|
|
|
- Uploads
|
|
- externe Medienreferenzen
|
|
- Metadaten
|
|
- tenant- oder screenspezifische Zuordnung
|
|
|
|
## 4. Playlist-Verwaltung
|
|
|
|
Der Server verwaltet tenantbezogene Inhalte pro Screen.
|
|
|
|
Wichtige Felder:
|
|
|
|
- Reihenfolge
|
|
- Dauer
|
|
- `valid_from`
|
|
- `valid_until`
|
|
- Fehlerstrategie
|
|
- Cache-Politik
|
|
|
|
## 5. Template- und Kampagnenverwaltung
|
|
|
|
Der Server stellt den globalen Orchestrierungsbereich bereit.
|
|
|
|
Funktionen:
|
|
|
|
- Templates erstellen
|
|
- Szenen pflegen
|
|
- Zielgruppen waehlen
|
|
- Kampagnen aktivieren/deaktivieren
|
|
- Zeitfenster setzen
|
|
- Uebersteuerung sichtbar machen
|
|
|
|
## 6. Provisionierung
|
|
|
|
Der Server startet Provisionierungsjobs fuer neue Screens.
|
|
|
|
Aufgaben:
|
|
|
|
- Eingaben aus Admin-UI entgegennehmen
|
|
- Job anlegen
|
|
- Secret-Handling absichern
|
|
- Worker oder Jobrunner starten
|
|
- Fortschritt speichern
|
|
- Fehler sauber rueckmelden
|
|
|
|
## API-Bereiche
|
|
|
|
Die API soll mindestens diese Domänen haben:
|
|
|
|
- `auth`
|
|
- `tenants`
|
|
- `users`
|
|
- `screens`
|
|
- `media`
|
|
- `playlists`
|
|
- `templates`
|
|
- `campaigns`
|
|
- `player`
|
|
- `commands`
|
|
- `provisioning`
|
|
|
|
## Revisionsmodell
|
|
|
|
Der Server arbeitet mit Revisionen, damit Player effizient synchronisieren koennen.
|
|
|
|
Mindestens:
|
|
|
|
- `config_revision`
|
|
- `playlist_revision`
|
|
- `media_revision`
|
|
- `campaign_revision`
|
|
|
|
## Status- und Vorschaukonzept
|
|
|
|
Der Server speichert:
|
|
|
|
- letzten bekannten Heartbeat
|
|
- letzten Status
|
|
- letzten Screenshot
|
|
- aktuelle Inhaltsquelle pro Screen
|
|
|
|
Die Admin-UI soll damit erkennen:
|
|
|
|
- online/offline
|
|
- normaler tenantbezogener Betrieb
|
|
- globale Kampagnen-Uebersteuerung
|
|
- Fallback-Betrieb
|
|
- Fehlerzustand
|
|
|
|
## Provisionierungsjobrunner
|
|
|
|
Die Provisionierung soll nicht direkt in Web-Requests laufen.
|
|
|
|
Stattdessen:
|
|
|
|
- API legt Job an
|
|
- dedizierter Worker/Jobrunnner arbeitet ihn ab
|
|
- Fortschritt wird in DB gespeichert
|
|
|
|
Zusaetzlich fuer v1 festzulegen:
|
|
|
|
- ACK-Timeout-Handling fuer `device_commands` ueber Worker
|
|
- Secret-Handling fuer Provisionierungs-Bootstrap ueber kurzlebige Secret-Referenzen
|
|
- physische Netzposition des Workers fuer SSH-Erreichbarkeit als Betriebsparameter
|
|
|
|
## Docker-Compose-Zielbild
|
|
|
|
Sinnvolle Komponenten in `compose/`:
|
|
|
|
- `reverse-proxy`
|
|
- `backend`
|
|
- `postgres`
|
|
- `mosquitto`
|
|
- optional `worker`
|
|
|
|
## Sicherheitsgrundsaetze
|
|
|
|
- Root-Bootstrap-Geheimnisse nur kurzlebig oder referenziert speichern
|
|
- API- und MQTT-Zugaenge getrennt behandeln
|
|
- alle Admin-Kommandos auditieren
|
|
- Tenant-Trennung strikt serverseitig erzwingen
|
|
|
|
## API-Fehlermodell
|
|
|
|
Vor Implementierungsbeginn gilt ein einheitlicher Fehlerumschlag.
|
|
|
|
Empfehlung:
|
|
|
|
```json
|
|
{
|
|
"error": {
|
|
"code": "screen_not_found",
|
|
"message": "Screen existiert nicht",
|
|
"details": null
|
|
}
|
|
}
|
|
```
|
|
|
|
## Zielstruktur im Repo
|
|
|
|
Empfohlene Unterstruktur fuer den Server:
|
|
|
|
- `server/backend/`
|
|
- `server/admin-ui/`
|
|
- `server/tenant-ui/`
|
|
- `server/worker/`
|
|
- `compose/`
|
|
|
|
## Testfaelle fuer den Server
|
|
|
|
- Tenant sieht nur eigene Daten
|
|
- Admin sieht alle Daten
|
|
- Kampagne ueberschreibt tenantbezogenen Content korrekt
|
|
- Screen-Provisionierung legt Job sauber an
|
|
- Player-Sync ueber Revisionen funktioniert
|
|
- MQTT-Kommandos werden protokolliert
|
|
- Screenshot-Upload erscheint im Admin-Dashboard
|