149 lines
6.8 KiB
Markdown
149 lines
6.8 KiB
Markdown
# Info-Board Neu - Umsetzungs-Todo
|
|
|
|
## Phase 0 - Projektbasis
|
|
|
|
- [ ] Projektverzeichnisstruktur unter `/srv/docker/info-board-neu` festlegen
|
|
- [ ] Namenskonventionen fuer Server, Player, Rollen und Pakete definieren
|
|
- [ ] Dokumentationsstruktur fuer Architektur, Betrieb und Deployment anlegen
|
|
- [ ] Entscheidung fuer Server-Tech-Stack dokumentieren
|
|
- [ ] Entscheidung fuer Player-Implementierung dokumentieren
|
|
- [ ] Sprachentscheidung dokumentieren: `Go` als bevorzugte Sprache fuer Agent und moeglichst viele Backend-Komponenten
|
|
|
|
## Phase 1 - Fachliches Fundament
|
|
|
|
- [ ] Rollenmodell fuer `admin` und monitorgebundene Nutzer final festschreiben
|
|
- [ ] Datenmodell fuer `tenant`, `screen`, `user`, `media_asset`, `playlist`, `playlist_item`, `screen_status`, `screen_snapshot` definieren
|
|
- [ ] Playlist-Semantik mit `duration`, `valid_from`, `valid_until`, `load_timeout`, `cache_policy`, `on_error` spezifizieren
|
|
- [ ] Fallback-Regel fuer ungeplante oder leere Inhalte verbindlich definieren
|
|
- [ ] Statusmodell fuer Online/Offline/Degraded/Error definieren
|
|
- [ ] Kommandokatalog fuer Admin-Aktionen finalisieren
|
|
- [ ] Template- und Kampagnenmodell fuer globale monitoruebergreifende Uebersteuerung finalisieren
|
|
- [ ] Prioritaetsregel `campaign > tenant_playlist > fallback` verbindlich festschreiben
|
|
|
|
## Phase 2 - Technische Zielarchitektur
|
|
|
|
- [ ] Server-Komponentenliste finalisieren
|
|
- [ ] API-Schnittstellen grob definieren
|
|
- [ ] MQTT-Topic-Struktur finalisieren
|
|
- [ ] HTTPS- und MQTT-Aufgabentrennung dokumentieren
|
|
- [ ] Screenshot-/Vorschaustrategie spezifizieren
|
|
- [ ] Offline- und Cache-Strategie bis auf Dateiebene festlegen
|
|
- [ ] Sicherheitsmodell fuer Uploads, Login und Rechte pruefen
|
|
- [ ] API fuer Templates, Kampagnen, Aktivierung und Deaktivierung ausarbeiten
|
|
- [ ] Provisionierungs-Workflow fuer neue Screens technisch durchplanen
|
|
- [ ] Secret-Handling fuer initiale Root-Passwoerter oder Bootstrap-Zugaenge definieren
|
|
|
|
## Phase 3 - Player-Design
|
|
|
|
- [ ] Minimalen Paketbedarf fuer den Player auf Raspberry Pi OS Debian 13 ermitteln
|
|
- [ ] X11-Minimalkonzept fuer Chromium-Kiosk dokumentieren
|
|
- [ ] Startmechanismus fuer Chromium ohne Desktop-Umgebung definieren
|
|
- [ ] Verzeichnislayout auf dem Player festlegen
|
|
- [ ] `player-agent` fachlich zuschneiden
|
|
- [ ] `player-ui` fachlich zuschneiden
|
|
- [ ] Watchdog-Konzept fuer Browser und Agent definieren
|
|
- [ ] Offline-Overlay-Verhalten spezifizieren
|
|
- [ ] Fehlerbehandlung fuer Web-Inhalte und Timeouts ausarbeiten
|
|
- [ ] Display-Steuerung fuer An/Aus, Rotation und Neustart planen
|
|
|
|
## Phase 4 - Server-Design
|
|
|
|
- [ ] API-Backend fachlich schneiden
|
|
- [ ] Admin-Oberflaeche in Hauptbereiche aufteilen
|
|
- [ ] Firmen-/Monitor-Oberflaeche in Hauptbereiche aufteilen
|
|
- [ ] Storage-Konzept fuer Uploads, Cache-Dateien und Screenshots festlegen
|
|
- [ ] Authentifizierungskonzept festlegen
|
|
- [ ] Mandantentrennung im Datenmodell und in den APIs absichern
|
|
- [ ] Logging- und Monitoring-Konzept definieren
|
|
- [ ] Template-Editor fuer globale Kampagnen fachlich schneiden
|
|
- [ ] Aktivierungsoberflaeche fuer saisonale oder temporäre Kampagnen planen
|
|
- [ ] Gruppierung oder Slot-Modell fuer monitoruebergreifende Layouts planen
|
|
- [ ] Provisionierungs-UI fuer neue Screens fachlich und technisch schneiden
|
|
- [ ] Jobrunner-Konzept fuer Ansible-gestuetzte Erstinstallation planen
|
|
|
|
## Phase 5 - Prototyping
|
|
|
|
- [ ] Minimalen Server-Prototyp bauen
|
|
- [ ] Minimalen Player-Agent-Prototyp bauen
|
|
- [ ] Minimale Player-UI bauen
|
|
- [ ] Lokale Test-Playlist mit Bild, Video, PDF und Webseite anlegen
|
|
- [ ] Fallback-Verzeichnisbetrieb demonstrieren
|
|
- [ ] `valid_from`/`valid_until` im Prototyp pruefen
|
|
- [ ] Offline-Sync mit lokalem Cache pruefen
|
|
- [ ] MQTT-Kommandos `reload`, `restart_player`, `reboot`, `display_on`, `display_off` testweise durchspielen
|
|
- [ ] globale Kampagne testen, die tenantbezogenen Content temporär ueberschreibt
|
|
- [ ] Rueckfall auf Normalbetrieb nach manueller Deaktivierung pruefen
|
|
|
|
## Phase 6 - Betriebsfaehigkeit
|
|
|
|
- [ ] Docker-Compose-Setup fuer den Server anlegen
|
|
- [ ] systemd-Units fuer den Player erstellen
|
|
- [ ] Chromium-Kiosk-Startskript erstellen
|
|
- [ ] Screenshot-Erzeugung auf dem Player integrieren
|
|
- [ ] Heartbeat- und Statusmeldungen integrieren
|
|
- [ ] Fehler- und Wiederanlaufverhalten verifizieren
|
|
|
|
## Phase 7 - Ansible-Automatisierung
|
|
|
|
- [ ] Rolle `signage_base` erstellen
|
|
- [ ] Rolle `signage_player` erstellen
|
|
- [ ] Rolle `signage_display` erstellen
|
|
- [ ] Rolle `signage_server` erstellen
|
|
- [ ] Rolle `signage_provision` erstellen
|
|
- [ ] Inventar-/Variablenmodell fuer mehrere Monitore entwerfen
|
|
- [ ] Screen-spezifische Variablen wie `screen_id`, Rotation und Aufloesung abbilden
|
|
- [ ] Erstinstallation eines neuen Players automatisieren
|
|
- [ ] Update-Rollout eines bestehenden Players automatisieren
|
|
- [ ] Bootstrap ueber Root-Passwort auf SSH-Key und dauerhafte Verwaltung umstellen
|
|
|
|
## Phase 8 - Pilotbetrieb
|
|
|
|
- [ ] Einen Referenzmonitor fuer den Pilotbetrieb auswaehlen
|
|
- [ ] Pilotmonitor neu aufsetzen
|
|
- [ ] Verbindung zum Zentralserver herstellen
|
|
- [ ] Upload- und Playlist-Pflege mit einem Testmandanten pruefen
|
|
- [ ] Admin-Funktionen am Pilotmonitor pruefen
|
|
- [ ] globale Template-Aktivierung fuer einen oder mehrere Monitore im Pilot testen
|
|
- [ ] Offline-Betrieb real testen
|
|
- [ ] Browser-/Renderer-Stabilitaet ueber laengeren Zeitraum beobachten
|
|
- [ ] komplette Neu-Provisionierung eines frischen Test-Screens aus dem Admin-Backend pruefen
|
|
|
|
## Phase 9 - Migration der Bestandsmonitore
|
|
|
|
- [ ] Migrationsreihenfolge fuer `info01` bis `info09` festlegen
|
|
- [ ] Rueckfallstrategie pro Monitor definieren
|
|
- [ ] Altinhalte in das neue Medienmodell ueberfuehren
|
|
- [ ] Playlists uebernehmen oder neu modellieren
|
|
- [ ] Monitore nacheinander umstellen
|
|
- [ ] Nach jeder Umstellung Stabilitaet und Fernsteuerung pruefen
|
|
|
|
## Phase 10 - Nacharbeiten
|
|
|
|
- [ ] Betriebsdokumentation schreiben
|
|
- [ ] Admin-Handbuch schreiben
|
|
- [ ] Kurzhandbuch fuer Firmen-Nutzer schreiben
|
|
- [ ] Backup- und Restore-Konzept dokumentieren
|
|
- [ ] Update- und Release-Prozess festlegen
|
|
- [ ] Langfristige Wayland-Neubewertung fuer spaetere Version vormerken
|
|
|
|
## Querschnittsthemen
|
|
|
|
- [ ] Datensicherung fuer Datenbank und Medien einplanen
|
|
- [ ] TLS-/Reverse-Proxy-Konzept festlegen
|
|
- [ ] Ressourcenverbrauch auf Raspberry Pi beobachten
|
|
- [ ] Verhalten bei grossen Videos optimieren
|
|
- [ ] Verhalten bei defekten externen Webseiten absichern
|
|
- [ ] Datenschutz- und Rechtefragen fuer Screenshots/Vorschauen pruefen
|
|
|
|
## Erste konkrete Abarbeitungsreihenfolge
|
|
|
|
- [ ] 1. Projektstruktur im neuen Verzeichnis vervollstaendigen
|
|
- [ ] 2. Datenmodell in eigener Datei ausformulieren
|
|
- [ ] 3. API- und MQTT-Vertrag definieren
|
|
- [ ] 4. Player-Minimalkonzept fuer Raspberry Pi OS Debian 13 festzurren
|
|
- [ ] 5. Server-Compose-Grundgeruest erstellen
|
|
- [ ] 6. Player-Prototyp mit lokalem Browser-Renderer bauen
|
|
- [ ] 7. Offline-Cache und Fallback robust machen
|
|
- [ ] 8. UIs fuer Admin und Firmen schrittweise aufbauen
|
|
- [ ] 9. Ansible-Rollen erstellen
|
|
- [ ] 10. Pilotmonitor migrieren
|