MegBes Wiki - Benutzerbeiträge [de]

LUX

2026-08-07T13:56:56Z

Clawtronics: Mitreisenden Server und Router als mobiles vorkonfiguriertes Netz dokumentiert

= LUX – D’Lëtzebuerger Sprooch(en) =

== Projektüberblick ==

{| class="wikitable"
! Angabe
! Stand
|-
| Kunde / Träger
| Zenter fir d’Lëtzebuerger Sprooch
|-
| Ausstellung
| Wanderausstellung „D’Lëtzebuerger Sprooch(en)“
|-
| Interne Bezeichnungen
| LUX, Nowa Lux
|-
| Technischer Projektschlüssel
| <code>nowalux</code>
|-
| Projektstatus
| Wanderausstellung; nur zeitweise aufgebaut und in Betrieb
|}

Die Wanderausstellung beschäftigt sich mit der luxemburgischen Sprache und ihrer Vielfalt. Nach der Projektreferenz von tinetronics umfasst sie annähernd 15 Stationen und setzt MegBes ein, damit Besucherinnen und Besucher Medienangebote mit dem eigenen Smartphone steuern können.

Zu den beschriebenen Angeboten gehören Videostationen, deren Bild auf den Ausstellungsmonitoren und deren Ton auf dem eigenen Smartphone wiedergegeben wird, außerdem ein Quiz zu den luxemburgischen Sprachen und eine Dialektkarte. Medien- und Lichttechnik sind miteinander kombiniert.

Quelle: [https://www.tinetronics.de/index_de.html tinetronics – Projektübersicht und Referenzen]

== MegBes-Betrieb ==

{| class="wikitable"
! Bestandteil
! Aktueller Stand
|-
| Externer Container
| <code>megbes-external-nowalux</code>
|-
| External-Release
| <code>MARCH-2026-1-RELEASE</code>
|-
| Container-Port
| Host-Port <code>34615</code> auf Container-Port <code>8080</code>
|-
| Öffentliche MegBes-Adresse
| noch zu bestätigen
|-
| Erwarteter Internal-Betrieb
| startet mit dem mitreisenden Server, sobald das Ausstellungssystem mit Strom versorgt wird
|-
| Interner Server / DynDNS
| Server und Router gehören zum mobilen Ausstellungssystem und reisen mit
|-
| Internal-Release
| noch zu erfassen
|-
| Letzte technische Inventur
| 7. August 2026 – externer Container lief
|}

Die Angaben zum Container stammen aus der [[Zentraler MegBes-Server – Inventur und Administration|Serverinventur]]. Die Portangabe beschreibt den internen Serverbetrieb und ist keine Aufforderung, den Port direkt öffentlich freizugeben.

Da es sich um eine Wanderausstellung handelt, ist ein nicht erreichbares <code>megbes-internal</code> außerhalb eines Ausstellungszeitraums nicht automatisch eine Störung. Der MegBes-Server und der vorkonfigurierte Router reisen mit der Ausstellung. Sobald beide mit Strom versorgt werden, steht das interne Ausstellungsnetz wieder zur Verfügung; das Netzwerk muss am neuen Ausstellungsort nicht von Grund auf neu eingerichtet werden.

Nach jedem Aufbau ist dennoch ein kurzer Funktionstest sinnvoll: Server und Router starten, Stationen sind im internen Netz erreichbar und die vorgesehene Verbindung nach außen funktioniert, sofern sie am Standort benötigt wird.

== Noch zu ergänzen ==

* verantwortliche Ansprechpartner innerhalb von tinetronics
* öffentliche Domain und vorgesehene Zugriffsart
* aktueller Ausstellungsort und geplanter Betriebszeitraum
* feste Daten des mitreisenden Servers und Routers sowie benötigter Internetzugang am Ausstellungsort
* vollständige Stationsliste und projektspezifischer Timer
* aktuelles Internal-Release
* Sicherungs- und Wiederherstellungsweg
* Datum und Ergebnis der nächsten vollständigen Funktionsprüfung

Zugangsdaten, Tokens, Schlüssel und vollständige DynDNS-Aktualisierungsadressen werden nicht auf dieser Seite gespeichert. Stattdessen wird auf den entsprechenden Eintrag im Passwortmanager verwiesen.

[[Kategorie:Projekte]]
[[Kategorie:MegBes]]

Projektübersicht

2026-08-07T13:55:01Z

Clawtronics: MiQua Guide als eigenständiges Projekt aufgenommen und Sonderabschnitt entfernt

= Projektübersicht =

Die Übersicht enthält Kundenprojekte sowie interne, private und temporäre Umgebungen. Der Status beschreibt den erwarteten Betrieb; ein planmäßig nicht aufgebautes temporäres Projekt ist keine Störung. Technische Betriebsdaten werden auf getrennten Projektseiten ergänzt. Geheimwerte werden niemals im Wiki gespeichert.

{| class="wikitable sortable"
! Projekt
! Status
! Release external
! Release internal
! Letzte Prüfung
|-
| [[Tine|tine]] || Test; Internal dauerhaft || <code>MARCH-2026-1-RELEASE</code> || noch zu erfassen || 7. August 2026
|-
| [[HON]] || privat; Internal dauerhaft || <code>MARCH-2026-1-RELEASE</code> || noch zu erfassen || 7. August 2026
|-
| [[GSE]] || aktiv; Internal dauerhaft || <code>MARCH-2026-1-RELEASE</code> || noch zu erfassen || 7. August 2026
|-
| [[MiQua]] || aktiv; Internal dauerhaft || <code>MARCH-2026-1-RELEASE</code> || noch zu erfassen || 7. August 2026
|-
| [[MiQua Guide]] || aktiv; direkter Zugriff || <code>MARCH-2026-1-RELEASE</code> || noch zu klären || 7. August 2026
|-
| [[BayAM]] || aktiv; Internal dauerhaft || <code>MARCH-2026-1-RELEASE</code> || noch zu erfassen || 7. August 2026
|-
| [[GKP]] || aktiv; Internal dauerhaft || <code>MARCH-2026-1-RELEASE</code> || noch zu erfassen || 7. August 2026
|-
| [[LUX]] || Wanderausstellung; zeitweise || <code>MARCH-2026-1-RELEASE</code> || noch zu erfassen || 7. August 2026
|-
| [[Limes]] || aktiv; Internal dauerhaft || <code>MARCH-2026-1-RELEASE</code> || noch zu erfassen || 7. August 2026
|-
| [[Messe]] || nur bei Messeeinsatz || <code>MARCH-2026-1-RELEASE</code> || noch zu erfassen || 7. August 2026
|}

== Inhalt einer Projektseite ==

Jede Projektseite soll mindestens enthalten:

* vollständiger Projektname und internes Kürzel
* verantwortliche Ansprechpartner innerhalb von tinetronics
* Domain von megbes-external
* DynDNS-Adresse oder interne Erreichbarkeit
* Container-Namen und Portzuordnungen
* installierte Releases
* eingesetzte Server- und Stationshardware
* projektspezifischer Stations-Timer
* Datum und Ergebnis der letzten Funktionsprüfung
* bekannte Besonderheiten und offene Aufgaben

Zugangsdaten, Tokens und Schlüssel werden durch einen Verweis auf den Passwortmanager ersetzt.

[[Kategorie:MegBes]]
[[Kategorie:Projekte]]

MiQua

2026-08-07T13:55:01Z

Clawtronics: MiQua Guide als eigenständiges verwandtes Projekt verlinkt

= MiQua – MiQua Showroom =

== Projektüberblick ==

{| class="wikitable"
! Angabe
! Stand
|-
| Einrichtung / Umfeld
| MiQua – LVR-Jüdisches Museum im Archäologischen Quartier Köln
|-
| Projektbezug
| MiQua Showroom
|-
| Projektschlüssel
| <code>miqua</code>
|-
| Status
| aktiv
|}

Der MiQua Showroom wird in den Referenzen von tinetronics im Zusammenhang mit der medientechnischen Unterstützung der LVR-Museen geführt. Der genaue fachliche und technische Einsatz von MegBes wird noch projektspezifisch ergänzt.

Quelle: [https://www.tinetronics.de/projects_de.html tinetronics – weitere Projekte und Referenzen]

== MegBes-Betrieb ==

{| class="wikitable"
! Bestandteil
! Aktueller Stand
|-
| Externer Container
| <code>megbes-external-miqua</code>
|-
| External-Release
| <code>MARCH-2026-1-RELEASE</code>
|-
| Container-Port
| Host-Port <code>32779</code> auf Container-Port <code>8080</code>
|-
| Eigenständiges, verwandtes Projekt
| [[MiQua Guide]]
|-
| Erwarteter Internal-Betrieb
| <code>megbes-internal</code> soll dauerhaft laufen
|-
| Domain, Internal-Release und Standortdaten
| konkrete Angaben noch zu erfassen
|-
| Letzte technische Inventur
| 7. August 2026 – externer Container lief
|}

== Noch zu ergänzen ==

* genaue MegBes-Funktionen und Abgrenzung zu [[MiQua Guide]]
* Ansprechpartner, Domain und Zugriffsart
* lokaler Server, DynDNS, Stationsliste und Timer
* Internal-Release und letzte vollständige Funktionsprüfung

[[Kategorie:Projekte]]
[[Kategorie:MegBes]]

MiQua Guide

2026-08-07T13:55:01Z

Clawtronics: MiQua Guide als eigenständiges Projekt angelegt

= MiQua Guide =

== Projektüberblick ==

{| class="wikitable"
! Angabe
! Stand
|-
| Projektname
| MiQua Guide
|-
| Technischer Projektschlüssel
| <code>miquaguide</code>
|-
| Projektstatus
| aktiv
|-
| Zugriffsart
| direkter Zugriff ohne vorherige Anmeldung über einen Ticket-Monitor
|}

MiQua Guide ist ein eigenständiges MegBes-Projekt. Der Guide kann die vorgesehenen Stationen direkt ansprechen, ohne dass sich die Nutzerin oder der Nutzer zuvor über einen Ticket-Monitor anmeldet.

Der fachliche Inhalt, die Zielgruppe und die genaue Abgrenzung zum Projekt [[MiQua]] werden noch ergänzt.

== MegBes-Betrieb ==

{| class="wikitable"
! Bestandteil
! Aktueller Stand
|-
| Externer Container
| <code>megbes-external-miquaguide</code>
|-
| External-Release
| <code>MARCH-2026-1-RELEASE</code>
|-
| Container-Port
| Host-Port <code>32774</code> auf Container-Port <code>8080</code>
|-
| Erwarteter Internal-Betrieb
| noch zu klären
|-
| Domain, Internal-Release und Standortdaten
| noch zu erfassen
|-
| Letzte technische Inventur
| 7. August 2026 – externer Container lief
|}

== Noch zu ergänzen ==

* vollständige Projekt- und Ausstellungsbeschreibung
* genaue Abgrenzung und technische Verbindungen zu [[MiQua]]
* Ansprechpartner und öffentliche Domain
* Begründung und Schutzmaßnahmen für den direkten Zugriff
* lokaler Server, Stationsliste und projektspezifischer Timer
* Internal-Release und letzte vollständige Funktionsprüfung

Zugangsdaten, Tokens und Schlüssel werden nicht auf dieser Seite gespeichert.

[[Kategorie:Projekte]]
[[Kategorie:MegBes]]

Projektübersicht

2026-08-07T13:50:13Z

Clawtronics: Dauerhaften und temporären Internal-Betrieb unterschieden

= Projektübersicht =

Die Übersicht enthält Kundenprojekte sowie interne, private und temporäre Umgebungen. Der Status beschreibt den erwarteten Betrieb; ein planmäßig nicht aufgebautes temporäres Projekt ist keine Störung. Technische Betriebsdaten werden auf getrennten Projektseiten ergänzt. Geheimwerte werden niemals im Wiki gespeichert.

{| class="wikitable sortable"
! Projekt
! Status
! Release external
! Release internal
! Letzte Prüfung
|-
| [[Tine|tine]] || Test; Internal dauerhaft || <code>MARCH-2026-1-RELEASE</code> || noch zu erfassen || 7. August 2026
|-
| [[HON]] || privat; Internal dauerhaft || <code>MARCH-2026-1-RELEASE</code> || noch zu erfassen || 7. August 2026
|-
| [[GSE]] || aktiv; Internal dauerhaft || <code>MARCH-2026-1-RELEASE</code> || noch zu erfassen || 7. August 2026
|-
| [[MiQua]] || aktiv; Internal dauerhaft || <code>MARCH-2026-1-RELEASE</code> || noch zu erfassen || 7. August 2026
|-
| [[BayAM]] || aktiv; Internal dauerhaft || <code>MARCH-2026-1-RELEASE</code> || noch zu erfassen || 7. August 2026
|-
| [[GKP]] || aktiv; Internal dauerhaft || <code>MARCH-2026-1-RELEASE</code> || noch zu erfassen || 7. August 2026
|-
| [[LUX]] || Wanderausstellung; zeitweise || <code>MARCH-2026-1-RELEASE</code> || noch zu erfassen || 7. August 2026
|-
| [[Limes]] || aktiv; Internal dauerhaft || <code>MARCH-2026-1-RELEASE</code> || noch zu erfassen || 7. August 2026
|-
| [[Messe]] || nur bei Messeeinsatz || <code>MARCH-2026-1-RELEASE</code> || noch zu erfassen || 7. August 2026
|}

== MiQua Guide ==

'''MiQua Guide''' ist ein aktives Subprojekt von MiQua und kein eigenständiges Kundenprojekt. Es besitzt in der technischen Konfiguration den Schlüssel `miquaguide`. Der Guide kann die Stationen direkt ansprechen, ohne dass sich der Nutzer zuvor über einen Ticket-Monitor anmeldet.
== Inhalt einer Projektseite ==

Jede Projektseite soll mindestens enthalten:

* vollständiger Projektname und internes Kürzel
* verantwortliche Ansprechpartner innerhalb von tinetronics
* Domain von megbes-external
* DynDNS-Adresse oder interne Erreichbarkeit
* Container-Namen und Portzuordnungen
* installierte Releases
* eingesetzte Server- und Stationshardware
* projektspezifischer Stations-Timer
* Datum und Ergebnis der letzten Funktionsprüfung
* bekannte Besonderheiten und offene Aufgaben

Zugangsdaten, Tokens und Schlüssel werden durch einen Verweis auf den Passwortmanager ersetzt.

[[Kategorie:MegBes]]
[[Kategorie:Projekte]]

LUX

2026-08-07T13:50:13Z

Clawtronics: Erwarteten Betrieb von megbes-internal dokumentiert

= LUX – D’Lëtzebuerger Sprooch(en) =

== Projektüberblick ==

{| class="wikitable"
! Angabe
! Stand
|-
| Kunde / Träger
| Zenter fir d’Lëtzebuerger Sprooch
|-
| Ausstellung
| Wanderausstellung „D’Lëtzebuerger Sprooch(en)“
|-
| Interne Bezeichnungen
| LUX, Nowa Lux
|-
| Technischer Projektschlüssel
| <code>nowalux</code>
|-
| Projektstatus
| Wanderausstellung; nur zeitweise aufgebaut und in Betrieb
|}

Die Wanderausstellung beschäftigt sich mit der luxemburgischen Sprache und ihrer Vielfalt. Nach der Projektreferenz von tinetronics umfasst sie annähernd 15 Stationen und setzt MegBes ein, damit Besucherinnen und Besucher Medienangebote mit dem eigenen Smartphone steuern können.

Zu den beschriebenen Angeboten gehören Videostationen, deren Bild auf den Ausstellungsmonitoren und deren Ton auf dem eigenen Smartphone wiedergegeben wird, außerdem ein Quiz zu den luxemburgischen Sprachen und eine Dialektkarte. Medien- und Lichttechnik sind miteinander kombiniert.

Quelle: [https://www.tinetronics.de/index_de.html tinetronics – Projektübersicht und Referenzen]

== MegBes-Betrieb ==

{| class="wikitable"
! Bestandteil
! Aktueller Stand
|-
| Externer Container
| <code>megbes-external-nowalux</code>
|-
| External-Release
| <code>MARCH-2026-1-RELEASE</code>
|-
| Container-Port
| Host-Port <code>34615</code> auf Container-Port <code>8080</code>
|-
| Öffentliche MegBes-Adresse
| noch zu bestätigen
|-
| Erwarteter Internal-Betrieb
| nur während Aufbau, Test und Betrieb an einem Ausstellungsort
|-
| Interner Server / DynDNS
| konkrete Angaben je Ausstellungsort noch zu erfassen
|-
| Internal-Release
| noch zu erfassen
|-
| Letzte technische Inventur
| 7. August 2026 – externer Container lief
|}

Die Angaben zum Container stammen aus der [[Zentraler MegBes-Server – Inventur und Administration|Serverinventur]]. Die Portangabe beschreibt den internen Serverbetrieb und ist keine Aufforderung, den Port direkt öffentlich freizugeben.

Da es sich um eine Wanderausstellung handelt, ist ein nicht erreichbares <code>megbes-internal</code> außerhalb eines Ausstellungszeitraums nicht automatisch eine Störung. Für jeden neuen Aufbau müssen Standort, Laufzeit, lokales Netz und Funktionsprüfung neu dokumentiert werden.

== Noch zu ergänzen ==

* verantwortliche Ansprechpartner innerhalb von tinetronics
* öffentliche Domain und vorgesehene Zugriffsart
* aktueller Ausstellungsort und geplanter Betriebszeitraum
* lokaler Server, DynDNS und Routerkonfiguration am jeweiligen Ausstellungsort
* vollständige Stationsliste und projektspezifischer Timer
* aktuelles Internal-Release
* Sicherungs- und Wiederherstellungsweg
* Datum und Ergebnis der nächsten vollständigen Funktionsprüfung

Zugangsdaten, Tokens, Schlüssel und vollständige DynDNS-Aktualisierungsadressen werden nicht auf dieser Seite gespeichert. Stattdessen wird auf den entsprechenden Eintrag im Passwortmanager verwiesen.

[[Kategorie:Projekte]]
[[Kategorie:MegBes]]

Limes

2026-08-07T13:50:13Z

Clawtronics: Erwarteten Betrieb von megbes-internal dokumentiert

= Limes =

== Projektüberblick ==

<code>Limes</code> ist ein aktives MegBes-Projekt. Die eindeutige Zuordnung zu einer öffentlich beschriebenen Referenz auf tinetronics.de ist noch zu bestätigen; deshalb werden an dieser Stelle keine Museums- oder Ausstellungsangaben vermutet.

== MegBes-Betrieb ==

{| class="wikitable"
! Bestandteil
! Aktueller Stand
|-
| Projektschlüssel
| <code>limes</code>
|-
| Externer Container
| <code>megbes-external-limes</code>
|-
| External-Release
| <code>MARCH-2026-1-RELEASE</code>
|-
| Container-Port
| Host-Port <code>32780</code> auf Container-Port <code>8080</code>
|-
| Erwarteter Internal-Betrieb
| <code>megbes-internal</code> soll dauerhaft laufen
|-
| Domain, Internal-Release und Standortdaten
| konkrete Angaben noch zu erfassen
|-
| Letzte technische Inventur
| 7. August 2026 – externer Container lief
|}

== Noch zu ergänzen ==

* vollständiger Name von Kunde, Einrichtung und Ausstellung
* zugehörige Referenz auf tinetronics.de
* MegBes-Funktionen, Ansprechpartner, Domain und Zugriffsart
* lokaler Server, DynDNS, Stationsliste und Timer
* Internal-Release und letzte vollständige Funktionsprüfung

[[Kategorie:Projekte]]
[[Kategorie:MegBes]]

BayAM

2026-08-07T13:50:13Z

Clawtronics: Erwarteten Betrieb von megbes-internal dokumentiert

= BayAM – Bayerisches Armeemuseum =

== Projektüberblick ==

{| class="wikitable"
! Angabe
! Stand
|-
| Kunde / Einrichtung
| Bayerisches Armeemuseum, Ingolstadt
|-
| Ausstellung
| Dauerausstellung „Krieg und Frieden – Militär in Bayern 1870–1914“
|-
| Interne Bezeichnung
| BayAM
|-
| Technischer Projektschlüssel
| <code>bayam</code>
|-
| Projektstatus
| aktiv
|}

MegBes wird beim Bayerischen Armeemuseum für die Dauerausstellung „Krieg und Frieden – Militär in Bayern 1870–1914“ eingesetzt. Die ebenfalls von tinetronics realisierte Medienstation „Sonne Mond & Sterne“ gehört zwar zu den Referenzen für das Bayerische Armeemuseum, ist jedoch nicht Gegenstand dieses MegBes-Projekts.

Quelle: [https://www.tinetronics.de/index_de.html tinetronics – Projektübersicht und Referenzen]

== MegBes-Betrieb ==

{| class="wikitable"
! Bestandteil
! Aktueller Stand
|-
| Externer Container
| <code>megbes-external-bayam</code>
|-
| External-Release
| <code>MARCH-2026-1-RELEASE</code>
|-
| Container-Port
| Nur lokal gebundener Host-Port <code>32768</code> auf Container-Port <code>8080</code>
|-
| Öffentliche MegBes-Adresse
| noch zu bestätigen
|-
| Erwarteter Internal-Betrieb
| <code>megbes-internal</code> soll dauerhaft laufen
|-
| Interner Server / DynDNS
| konkrete Angaben noch zu erfassen
|-
| Internal-Release
| noch zu erfassen
|-
| Letzte technische Inventur
| 7. August 2026 – externer Container lief
|}

Die Angaben zum Container stammen aus der [[Zentraler MegBes-Server – Inventur und Administration|Serverinventur]]. Der Host-Port ist nur an <code>127.0.0.1</code> gebunden und wird nicht direkt aus dem Internet angesprochen.

== Noch zu ergänzen ==

* verantwortliche Ansprechpartner innerhalb von tinetronics
* genaue Rolle von MegBes innerhalb der Dauerausstellung und vorgesehene Zugriffsart
* öffentliche Domain
* lokaler Server, DynDNS und Routerkonfiguration
* Stationsliste und projektspezifischer Timer
* aktuelles Internal-Release
* Sicherungs- und Wiederherstellungsweg
* Datum und Ergebnis der nächsten vollständigen Funktionsprüfung

Zugangsdaten, Tokens, Schlüssel und vollständige DynDNS-Aktualisierungsadressen werden nicht auf dieser Seite gespeichert. Stattdessen wird auf den entsprechenden Eintrag im Passwortmanager verwiesen.

[[Kategorie:Projekte]]
[[Kategorie:MegBes]]

MiQua

2026-08-07T13:50:13Z

Clawtronics: Erwarteten Betrieb von megbes-internal dokumentiert

= MiQua – MiQua Showroom =

== Projektüberblick ==

{| class="wikitable"
! Angabe
! Stand
|-
| Einrichtung / Umfeld
| MiQua – LVR-Jüdisches Museum im Archäologischen Quartier Köln
|-
| Projektbezug
| MiQua Showroom
|-
| Projektschlüssel
| <code>miqua</code>
|-
| Status
| aktiv
|}

Der MiQua Showroom wird in den Referenzen von tinetronics im Zusammenhang mit der medientechnischen Unterstützung der LVR-Museen geführt. Der genaue fachliche und technische Einsatz von MegBes wird noch projektspezifisch ergänzt.

Quelle: [https://www.tinetronics.de/projects_de.html tinetronics – weitere Projekte und Referenzen]

== MegBes-Betrieb ==

{| class="wikitable"
! Bestandteil
! Aktueller Stand
|-
| Externer Container
| <code>megbes-external-miqua</code>
|-
| External-Release
| <code>MARCH-2026-1-RELEASE</code>
|-
| Container-Port
| Host-Port <code>32779</code> auf Container-Port <code>8080</code>
|-
| Zugehöriges Subprojekt
| [[Projektübersicht#MiQua Guide|MiQua Guide]], Projektschlüssel <code>miquaguide</code>
|-
| Erwarteter Internal-Betrieb
| <code>megbes-internal</code> soll dauerhaft laufen
|-
| Domain, Internal-Release und Standortdaten
| konkrete Angaben noch zu erfassen
|-
| Letzte technische Inventur
| 7. August 2026 – externer Container lief
|}

== Noch zu ergänzen ==

* genaue MegBes-Funktionen und Abgrenzung zum MiQua Guide
* Ansprechpartner, Domain und Zugriffsart
* lokaler Server, DynDNS, Stationsliste und Timer
* Internal-Release und letzte vollständige Funktionsprüfung

[[Kategorie:Projekte]]
[[Kategorie:MegBes]]

GSE

2026-08-07T13:50:13Z

Clawtronics: Erwarteten Betrieb von megbes-internal dokumentiert

= GSE – Gedenkstätte Esterwegen =

== Projektüberblick ==

{| class="wikitable"
! Angabe
! Stand
|-
| Einrichtung
| Landkreis Emsland, Gedenkstätte Esterwegen
|-
| Ausstellung
| Dauerausstellung „Die Emslandlager 1933–1945“
|-
| Projektschlüssel
| <code>gse</code>
|-
| Status
| aktiv
|}

Die Dauerausstellung umfasst laut tinetronics-Referenz etwa 30 AV-Stationen mit zeitgenössischem Filmmaterial, Zeitzeugeninterviews und interaktiven Elementen. MegBes wurde während der Corona-Pandemie für eine kontaktarme Nutzung eingeführt. Besucherinnen und Besucher können Medieninstallationen mit dem eigenen Smartphone steuern und das zugehörige Audio synchron auf dem eigenen Gerät hören.

Quelle: [https://www.tinetronics.de/index_de.html tinetronics – Projektübersicht und Referenzen]

== MegBes-Betrieb ==

{| class="wikitable"
! Bestandteil
! Aktueller Stand
|-
| Externer Container
| <code>megbes-external-gse</code>
|-
| External-Release
| <code>MARCH-2026-1-RELEASE</code>
|-
| Container-Port
| Host-Port <code>32805</code> auf Container-Port <code>8080</code>
|-
| Erwarteter Internal-Betrieb
| <code>megbes-internal</code> soll dauerhaft laufen
|-
| Domain, Internal-Release und Standortdaten
| konkrete Angaben noch zu erfassen
|-
| Letzte technische Inventur
| 7. August 2026 – externer Container lief
|}

== Noch zu ergänzen ==

* Ansprechpartner, Domain und Zugriffsart
* lokaler Server, DynDNS und Routerkonfiguration
* vollständige Stationsliste und Timer
* Internal-Release sowie letzte vollständige Funktionsprüfung

[[Kategorie:Projekte]]
[[Kategorie:MegBes]]

GKP

2026-08-07T13:50:12Z

Clawtronics: Erwarteten Betrieb von megbes-internal dokumentiert

= GKP – Garnisonkirche Potsdam =

== Projektüberblick ==

{| class="wikitable"
! Angabe
! Stand
|-
| Auftraggeber
| Stiftung Garnisonkirche Potsdam
|-
| Ausstellung
| Dauerausstellung „Glaube, Macht und Militär“
|-
| Projektschlüssel
| <code>gkp</code>
|-
| Status
| aktiv
|}

tinetronics entwickelte und installierte für die Dauerausstellung maßgeschneiderte Medienstationen, die die Geschichte des Ortes interaktiv vermitteln. Der genaue Funktionsumfang von MegBes innerhalb dieser Ausstellung wird auf dieser Seite noch ergänzt.

Quelle: [https://www.tinetronics.de/index_de.html tinetronics – Projektübersicht und Referenzen]

== MegBes-Betrieb ==

{| class="wikitable"
! Bestandteil
! Aktueller Stand
|-
| Externer Container
| <code>megbes-external-gkp</code>
|-
| External-Release
| <code>MARCH-2026-1-RELEASE</code>
|-
| Container-Port
| Host-Port <code>32769</code> auf Container-Port <code>8080</code>
|-
| Erwarteter Internal-Betrieb
| <code>megbes-internal</code> soll dauerhaft laufen
|-
| Domain, Internal-Release und Standortdaten
| konkrete Angaben noch zu erfassen
|-
| Letzte technische Inventur
| 7. August 2026 – externer Container lief
|}

== Noch zu ergänzen ==

* genaue MegBes-Funktionen, Ansprechpartner, Domain und Zugriffsart
* lokaler Server, DynDNS und Routerkonfiguration
* Stationsliste, Timer und Internal-Release
* Datum der letzten vollständigen Funktionsprüfung

[[Kategorie:Projekte]]
[[Kategorie:MegBes]]

HON

2026-08-07T13:50:12Z

Clawtronics: Erwarteten Betrieb von megbes-internal dokumentiert

= HON – House of Noise =

== Zweck ==

<code>HON</code> ist eine private Test- und Spaßumgebung. Besucherinnen und Besucher des Twitch-Kanals von '''misstinamyte''' können über die Fernbedienung unter [https://houseofnoise.de/remote houseofnoise.de/remote] live ausgewählte Geräte im privaten Wohnzimmer steuern – darunter Projektionen, Nebel und Stroboskop-Effekte.

Die Umgebung ist kein Kundenprojekt. Sie verbindet einen öffentlichen Zugriff mit realen Geräten in einem privaten Umfeld und muss deshalb besonders kontrolliert betrieben werden.

== Technischer Stand ==

{| class="wikitable"
! Angabe
! Stand
|-
| Projektschlüssel
| <code>hon</code>
|-
| Externer Container
| <code>megbes-external-hon</code>
|-
| External-Release
| <code>MARCH-2026-1-RELEASE</code>
|-
| Container-Port
| Nur lokal gebundener Host-Port <code>9997</code> auf Container-Port <code>8080</code>
|-
| Bedienoberfläche
| [https://houseofnoise.de/remote houseofnoise.de/remote]
|-
| Erwarteter Internal-Betrieb
| <code>megbes-internal</code> soll dauerhaft laufen
|-
| Letzte technische Inventur
| 7. August 2026 – externer Container lief
|}

== Besondere Betriebsregeln ==

* Die Steuerung darf nur die ausdrücklich vorgesehenen Geräte und Funktionen erreichen.
* Sicherheitskritische Effekte benötigen feste Laufzeitbegrenzungen und einen lokalen Abschaltweg.
* Nebel und Stroboskop werden nur unter persönlicher Aufsicht freigegeben.
* Die öffentliche Oberfläche darf keine privaten Netzwerk-, Geräte- oder Zugangsdaten offenlegen.
* Nach Ende eines Streams sollen nicht benötigte Steuerfunktionen deaktiviert werden.

== Noch zu ergänzen ==

* vollständige Liste der steuerbaren Geräte und Sicherheitsbegrenzungen
* Freigabe- und Abschaltablauf vor und nach einem Stream
* Daten des lokalen MegBes-Servers, Internal-Release und Erreichbarkeit
* projektspezifischer Timer und Missbrauchsschutz

[[Kategorie:Projekte]]
[[Kategorie:Testumgebung]]
[[Kategorie:MegBes]]

Tine

2026-08-07T13:50:12Z

Clawtronics: Erwarteten Betrieb von megbes-internal dokumentiert

= Tine – interne MegBes-Testumgebung =

== Zweck ==

<code>tine</code> ist die interne Test- und Entwicklungsumgebung von tinetronics. Sie dient dazu, MegBes-Funktionen, Frontends und Schnittstellen zu prüfen, ohne ein Kundenprojekt zu beeinflussen. Die Umgebung ist kein Referenz- oder Produktivprojekt.

== Technischer Stand ==

{| class="wikitable"
! Angabe
! Stand
|-
| Projektschlüssel
| <code>tine</code>
|-
| Externer Container
| <code>megbes-external-tine</code>
|-
| External-Release
| <code>MARCH-2026-1-RELEASE</code>
|-
| Container-Port
| Host-Port <code>32770</code> auf Container-Port <code>8080</code>
|-
| Öffentliche Testadresse
| <code>https://tine.megbes.de</code>
|-
| Erwarteter Internal-Betrieb
| <code>megbes-internal</code> soll dauerhaft laufen
|-
| Letzte technische Inventur
| 7. August 2026 – externer Container lief
|}

Die Umgebung kann bewusst von der Konfiguration produktiver Kundenprojekte abweichen. Testergebnisse müssen deshalb immer mit Datum, geprüftem Release und Versuchsaufbau dokumentiert werden.

== Noch zu ergänzen ==

* verantwortliche Personen und Freigaberegeln
* aktuell vorgesehene Testfälle
* Internal-Release und Daten des lokalen Testservers
* Regeln zum Bereinigen von Testdaten und temporären Zugängen

[[Kategorie:Projekte]]
[[Kategorie:Testumgebung]]
[[Kategorie:MegBes]]

Projektübersicht

2026-08-07T13:42:55Z

Clawtronics: Weitere Projektseiten verlinkt, Umgebungsarten und Inventurstand ergänzt

= Projektübersicht =

Alle nachfolgend aufgeführten Projekte sind aktiv. Technische Betriebsdaten werden schrittweise auf getrennten Projektseiten ergänzt. Geheimwerte werden niemals im Wiki gespeichert.

{| class="wikitable sortable"
! Projekt
! Status
! Release external
! Release internal
! Letzte Prüfung
|-
| [[Tine|tine]] || interne Testumgebung || <code>MARCH-2026-1-RELEASE</code> || noch zu erfassen || 7. August 2026
|-
| [[HON]] || private Testumgebung || <code>MARCH-2026-1-RELEASE</code> || noch zu erfassen || 7. August 2026
|-
| [[GSE]] || aktiv || <code>MARCH-2026-1-RELEASE</code> || noch zu erfassen || 7. August 2026
|-
| [[MiQua]] || aktiv || <code>MARCH-2026-1-RELEASE</code> || noch zu erfassen || 7. August 2026
|-
| [[BayAM]] || aktiv || <code>MARCH-2026-1-RELEASE</code> || noch zu erfassen || 7. August 2026
|-
| [[GKP]] || aktiv || <code>MARCH-2026-1-RELEASE</code> || noch zu erfassen || 7. August 2026
|-
| [[LUX]] || aktiv || <code>MARCH-2026-1-RELEASE</code> || noch zu erfassen || 7. August 2026
|-
| [[Limes]] || aktiv || <code>MARCH-2026-1-RELEASE</code> || noch zu erfassen || 7. August 2026
|-
| [[Messe]] || nur bei Messeeinsatz || <code>MARCH-2026-1-RELEASE</code> || noch zu erfassen || 7. August 2026
|}

== MiQua Guide ==

'''MiQua Guide''' ist ein aktives Subprojekt von MiQua und kein eigenständiges Kundenprojekt. Es besitzt in der technischen Konfiguration den Schlüssel `miquaguide`. Der Guide kann die Stationen direkt ansprechen, ohne dass sich der Nutzer zuvor über einen Ticket-Monitor anmeldet.
== Inhalt einer Projektseite ==

Jede Projektseite soll mindestens enthalten:

* vollständiger Projektname und internes Kürzel
* verantwortliche Ansprechpartner innerhalb von tinetronics
* Domain von megbes-external
* DynDNS-Adresse oder interne Erreichbarkeit
* Container-Namen und Portzuordnungen
* installierte Releases
* eingesetzte Server- und Stationshardware
* projektspezifischer Stations-Timer
* Datum und Ergebnis der letzten Funktionsprüfung
* bekannte Besonderheiten und offene Aufgaben

Zugangsdaten, Tokens und Schlüssel werden durch einen Verweis auf den Passwortmanager ersetzt.

[[Kategorie:MegBes]]
[[Kategorie:Projekte]]

Limes

2026-08-07T13:42:55Z

Clawtronics: Projektseite mit Basis- und Inventurdaten angelegt

= Limes =

== Projektüberblick ==

<code>Limes</code> ist ein aktives MegBes-Projekt. Die eindeutige Zuordnung zu einer öffentlich beschriebenen Referenz auf tinetronics.de ist noch zu bestätigen; deshalb werden an dieser Stelle keine Museums- oder Ausstellungsangaben vermutet.

== MegBes-Betrieb ==

{| class="wikitable"
! Bestandteil
! Aktueller Stand
|-
| Projektschlüssel
| <code>limes</code>
|-
| Externer Container
| <code>megbes-external-limes</code>
|-
| External-Release
| <code>MARCH-2026-1-RELEASE</code>
|-
| Container-Port
| Host-Port <code>32780</code> auf Container-Port <code>8080</code>
|-
| Domain, Internal-Release und Standortdaten
| noch zu erfassen
|-
| Letzte technische Inventur
| 7. August 2026 – externer Container lief
|}

== Noch zu ergänzen ==

* vollständiger Name von Kunde, Einrichtung und Ausstellung
* zugehörige Referenz auf tinetronics.de
* MegBes-Funktionen, Ansprechpartner, Domain und Zugriffsart
* lokaler Server, DynDNS, Stationsliste und Timer
* Internal-Release und letzte vollständige Funktionsprüfung

[[Kategorie:Projekte]]
[[Kategorie:MegBes]]

MiQua

2026-08-07T13:42:55Z

Clawtronics: Projektseite mit Basis- und Inventurdaten angelegt

= MiQua – MiQua Showroom =

== Projektüberblick ==

{| class="wikitable"
! Angabe
! Stand
|-
| Einrichtung / Umfeld
| MiQua – LVR-Jüdisches Museum im Archäologischen Quartier Köln
|-
| Projektbezug
| MiQua Showroom
|-
| Projektschlüssel
| <code>miqua</code>
|-
| Status
| aktiv
|}

Der MiQua Showroom wird in den Referenzen von tinetronics im Zusammenhang mit der medientechnischen Unterstützung der LVR-Museen geführt. Der genaue fachliche und technische Einsatz von MegBes wird noch projektspezifisch ergänzt.

Quelle: [https://www.tinetronics.de/projects_de.html tinetronics – weitere Projekte und Referenzen]

== MegBes-Betrieb ==

{| class="wikitable"
! Bestandteil
! Aktueller Stand
|-
| Externer Container
| <code>megbes-external-miqua</code>
|-
| External-Release
| <code>MARCH-2026-1-RELEASE</code>
|-
| Container-Port
| Host-Port <code>32779</code> auf Container-Port <code>8080</code>
|-
| Zugehöriges Subprojekt
| [[Projektübersicht#MiQua Guide|MiQua Guide]], Projektschlüssel <code>miquaguide</code>
|-
| Domain, Internal-Release und Standortdaten
| noch zu erfassen
|-
| Letzte technische Inventur
| 7. August 2026 – externer Container lief
|}

== Noch zu ergänzen ==

* genaue MegBes-Funktionen und Abgrenzung zum MiQua Guide
* Ansprechpartner, Domain und Zugriffsart
* lokaler Server, DynDNS, Stationsliste und Timer
* Internal-Release und letzte vollständige Funktionsprüfung

[[Kategorie:Projekte]]
[[Kategorie:MegBes]]

GKP

2026-08-07T13:42:55Z

Clawtronics: Projektseite mit Basis- und Inventurdaten angelegt

= GKP – Garnisonkirche Potsdam =

== Projektüberblick ==

{| class="wikitable"
! Angabe
! Stand
|-
| Auftraggeber
| Stiftung Garnisonkirche Potsdam
|-
| Ausstellung
| Dauerausstellung „Glaube, Macht und Militär“
|-
| Projektschlüssel
| <code>gkp</code>
|-
| Status
| aktiv
|}

tinetronics entwickelte und installierte für die Dauerausstellung maßgeschneiderte Medienstationen, die die Geschichte des Ortes interaktiv vermitteln. Der genaue Funktionsumfang von MegBes innerhalb dieser Ausstellung wird auf dieser Seite noch ergänzt.

Quelle: [https://www.tinetronics.de/index_de.html tinetronics – Projektübersicht und Referenzen]

== MegBes-Betrieb ==

{| class="wikitable"
! Bestandteil
! Aktueller Stand
|-
| Externer Container
| <code>megbes-external-gkp</code>
|-
| External-Release
| <code>MARCH-2026-1-RELEASE</code>
|-
| Container-Port
| Host-Port <code>32769</code> auf Container-Port <code>8080</code>
|-
| Domain, Internal-Release und Standortdaten
| noch zu erfassen
|-
| Letzte technische Inventur
| 7. August 2026 – externer Container lief
|}

== Noch zu ergänzen ==

* genaue MegBes-Funktionen, Ansprechpartner, Domain und Zugriffsart
* lokaler Server, DynDNS und Routerkonfiguration
* Stationsliste, Timer und Internal-Release
* Datum der letzten vollständigen Funktionsprüfung

[[Kategorie:Projekte]]
[[Kategorie:MegBes]]

GSE

2026-08-07T13:42:55Z

Clawtronics: Projektseite mit Basis- und Inventurdaten angelegt

= GSE – Gedenkstätte Esterwegen =

== Projektüberblick ==

{| class="wikitable"
! Angabe
! Stand
|-
| Einrichtung
| Landkreis Emsland, Gedenkstätte Esterwegen
|-
| Ausstellung
| Dauerausstellung „Die Emslandlager 1933–1945“
|-
| Projektschlüssel
| <code>gse</code>
|-
| Status
| aktiv
|}

Die Dauerausstellung umfasst laut tinetronics-Referenz etwa 30 AV-Stationen mit zeitgenössischem Filmmaterial, Zeitzeugeninterviews und interaktiven Elementen. MegBes wurde während der Corona-Pandemie für eine kontaktarme Nutzung eingeführt. Besucherinnen und Besucher können Medieninstallationen mit dem eigenen Smartphone steuern und das zugehörige Audio synchron auf dem eigenen Gerät hören.

Quelle: [https://www.tinetronics.de/index_de.html tinetronics – Projektübersicht und Referenzen]

== MegBes-Betrieb ==

{| class="wikitable"
! Bestandteil
! Aktueller Stand
|-
| Externer Container
| <code>megbes-external-gse</code>
|-
| External-Release
| <code>MARCH-2026-1-RELEASE</code>
|-
| Container-Port
| Host-Port <code>32805</code> auf Container-Port <code>8080</code>
|-
| Domain, Internal-Release und Standortdaten
| noch zu erfassen
|-
| Letzte technische Inventur
| 7. August 2026 – externer Container lief
|}

== Noch zu ergänzen ==

* Ansprechpartner, Domain und Zugriffsart
* lokaler Server, DynDNS und Routerkonfiguration
* vollständige Stationsliste und Timer
* Internal-Release sowie letzte vollständige Funktionsprüfung

[[Kategorie:Projekte]]
[[Kategorie:MegBes]]

Messe

2026-08-07T13:42:55Z

Clawtronics: Projektseite mit Basis- und Inventurdaten angelegt

= Messe – MegBes am Messestand =

== Zweck ==

Das Projekt <code>messe</code> wird nur aktiviert, wenn tinetronics den eigenen Messestand mit MegBes-Funktionen betreibt. Außerhalb eines Messebetriebs ist die Umgebung nicht als dauerhaft aktives Produktivsystem zu behandeln.

Auf der Projektseite werden je Einsatz die Veranstaltung, der Aufbau und die tatsächlich verwendeten Funktionen dokumentiert. Dadurch bleibt nachvollziehbar, ob die vorhandene Konfiguration zum nächsten Messestand passt oder vorab angepasst werden muss.

== Technischer Stand ==

{| class="wikitable"
! Angabe
! Stand
|-
| Projektschlüssel
| <code>messe</code>
|-
| Externer Container
| <code>megbes-external-messe</code>
|-
| External-Release
| <code>MARCH-2026-1-RELEASE</code>
|-
| Container-Port
| Host-Port <code>32771</code> auf Container-Port <code>8080</code>
|-
| Betriebsstatus
| nur bei einem konkreten Messeeinsatz aktiv
|-
| Letzte technische Inventur
| 7. August 2026 – externer Container lief
|}

== Checkliste je Messeeinsatz ==

* Veranstaltung, Ort und Zeitraum eintragen
* geplante MegBes-Funktionen festlegen
* Stations- und Geräteliste für den konkreten Aufbau erstellen
* Internetzugang und lokales Messe-Netz vorab klären
* Releases und Funktion vor dem Versand testen
* Auf- und Abbauverantwortliche benennen
* nach der Messe temporäre Zugänge deaktivieren und Ergebnis dokumentieren

[[Kategorie:Projekte]]
[[Kategorie:MegBes]]

HON

2026-08-07T13:42:55Z

Clawtronics: Projektseite mit Basis- und Inventurdaten angelegt

= HON – House of Noise =

== Zweck ==

<code>HON</code> ist eine private Test- und Spaßumgebung. Besucherinnen und Besucher des Twitch-Kanals von '''misstinamyte''' können über die Fernbedienung unter [https://houseofnoise.de/remote houseofnoise.de/remote] live ausgewählte Geräte im privaten Wohnzimmer steuern – darunter Projektionen, Nebel und Stroboskop-Effekte.

Die Umgebung ist kein Kundenprojekt. Sie verbindet einen öffentlichen Zugriff mit realen Geräten in einem privaten Umfeld und muss deshalb besonders kontrolliert betrieben werden.

== Technischer Stand ==

{| class="wikitable"
! Angabe
! Stand
|-
| Projektschlüssel
| <code>hon</code>
|-
| Externer Container
| <code>megbes-external-hon</code>
|-
| External-Release
| <code>MARCH-2026-1-RELEASE</code>
|-
| Container-Port
| Nur lokal gebundener Host-Port <code>9997</code> auf Container-Port <code>8080</code>
|-
| Bedienoberfläche
| [https://houseofnoise.de/remote houseofnoise.de/remote]
|-
| Letzte technische Inventur
| 7. August 2026 – externer Container lief
|}

== Besondere Betriebsregeln ==

* Die Steuerung darf nur die ausdrücklich vorgesehenen Geräte und Funktionen erreichen.
* Sicherheitskritische Effekte benötigen feste Laufzeitbegrenzungen und einen lokalen Abschaltweg.
* Nebel und Stroboskop werden nur unter persönlicher Aufsicht freigegeben.
* Die öffentliche Oberfläche darf keine privaten Netzwerk-, Geräte- oder Zugangsdaten offenlegen.
* Nach Ende eines Streams sollen nicht benötigte Steuerfunktionen deaktiviert werden.

== Noch zu ergänzen ==

* vollständige Liste der steuerbaren Geräte und Sicherheitsbegrenzungen
* Freigabe- und Abschaltablauf vor und nach einem Stream
* lokaler MegBes-Server, Internal-Release und Erreichbarkeit
* projektspezifischer Timer und Missbrauchsschutz

[[Kategorie:Projekte]]
[[Kategorie:Testumgebung]]
[[Kategorie:MegBes]]

Tine

2026-08-07T13:42:55Z

Clawtronics: Projektseite mit Basis- und Inventurdaten angelegt

= Tine – interne MegBes-Testumgebung =

== Zweck ==

<code>tine</code> ist die interne Test- und Entwicklungsumgebung von tinetronics. Sie dient dazu, MegBes-Funktionen, Frontends und Schnittstellen zu prüfen, ohne ein Kundenprojekt zu beeinflussen. Die Umgebung ist kein Referenz- oder Produktivprojekt.

== Technischer Stand ==

{| class="wikitable"
! Angabe
! Stand
|-
| Projektschlüssel
| <code>tine</code>
|-
| Externer Container
| <code>megbes-external-tine</code>
|-
| External-Release
| <code>MARCH-2026-1-RELEASE</code>
|-
| Container-Port
| Host-Port <code>32770</code> auf Container-Port <code>8080</code>
|-
| Öffentliche Testadresse
| <code>https://tine.megbes.de</code>
|-
| Letzte technische Inventur
| 7. August 2026 – externer Container lief
|}

Die Umgebung kann bewusst von der Konfiguration produktiver Kundenprojekte abweichen. Testergebnisse müssen deshalb immer mit Datum, geprüftem Release und Versuchsaufbau dokumentiert werden.

== Noch zu ergänzen ==

* verantwortliche Personen und Freigaberegeln
* aktuell vorgesehene Testfälle
* Internal-Release und gegebenenfalls lokaler Testserver
* Regeln zum Bereinigen von Testdaten und temporären Zugängen

[[Kategorie:Projekte]]
[[Kategorie:Testumgebung]]
[[Kategorie:MegBes]]

BayAM

2026-08-07T13:32:55Z

Clawtronics: MegBes korrekt der Dauerausstellung Krieg und Frieden zugeordnet

= BayAM – Bayerisches Armeemuseum =

== Projektüberblick ==

{| class="wikitable"
! Angabe
! Stand
|-
| Kunde / Einrichtung
| Bayerisches Armeemuseum, Ingolstadt
|-
| Ausstellung
| Dauerausstellung „Krieg und Frieden – Militär in Bayern 1870–1914“
|-
| Interne Bezeichnung
| BayAM
|-
| Technischer Projektschlüssel
| <code>bayam</code>
|-
| Projektstatus
| aktiv
|}

MegBes wird beim Bayerischen Armeemuseum für die Dauerausstellung „Krieg und Frieden – Militär in Bayern 1870–1914“ eingesetzt. Die ebenfalls von tinetronics realisierte Medienstation „Sonne Mond & Sterne“ gehört zwar zu den Referenzen für das Bayerische Armeemuseum, ist jedoch nicht Gegenstand dieses MegBes-Projekts.

Quelle: [https://www.tinetronics.de/index_de.html tinetronics – Projektübersicht und Referenzen]

== MegBes-Betrieb ==

{| class="wikitable"
! Bestandteil
! Aktueller Stand
|-
| Externer Container
| <code>megbes-external-bayam</code>
|-
| External-Release
| <code>MARCH-2026-1-RELEASE</code>
|-
| Container-Port
| Nur lokal gebundener Host-Port <code>32768</code> auf Container-Port <code>8080</code>
|-
| Öffentliche MegBes-Adresse
| noch zu bestätigen
|-
| Interner Server / DynDNS
| noch zu erfassen
|-
| Internal-Release
| noch zu erfassen
|-
| Letzte technische Inventur
| 7. August 2026 – externer Container lief
|}

Die Angaben zum Container stammen aus der [[Zentraler MegBes-Server – Inventur und Administration|Serverinventur]]. Der Host-Port ist nur an <code>127.0.0.1</code> gebunden und wird nicht direkt aus dem Internet angesprochen.

== Noch zu ergänzen ==

* verantwortliche Ansprechpartner innerhalb von tinetronics
* genaue Rolle von MegBes innerhalb der Dauerausstellung und vorgesehene Zugriffsart
* öffentliche Domain
* lokaler Server, DynDNS und Routerkonfiguration
* Stationsliste und projektspezifischer Timer
* aktuelles Internal-Release
* Sicherungs- und Wiederherstellungsweg
* Datum und Ergebnis der nächsten vollständigen Funktionsprüfung

Zugangsdaten, Tokens, Schlüssel und vollständige DynDNS-Aktualisierungsadressen werden nicht auf dieser Seite gespeichert. Stattdessen wird auf den entsprechenden Eintrag im Passwortmanager verwiesen.

[[Kategorie:Projekte]]
[[Kategorie:MegBes]]

Projektübersicht

2026-08-07T13:28:57Z

Clawtronics: LUX und BayAM mit neuen Projektseiten verlinkt und Inventurstand ergänzt

= Projektübersicht =

Alle nachfolgend aufgeführten Projekte sind aktiv. Technische Betriebsdaten werden schrittweise auf getrennten Projektseiten ergänzt. Geheimwerte werden niemals im Wiki gespeichert.

{| class="wikitable sortable"
! Projekt
! Status
! Release external
! Release internal
! Letzte Prüfung
|-
| tine || aktiv || noch zu erfassen || noch zu erfassen || noch zu erfassen
|-
| HON || aktiv || noch zu erfassen || noch zu erfassen || noch zu erfassen
|-
| GSE || aktiv || noch zu erfassen || noch zu erfassen || noch zu erfassen
|-
| MiQua || aktiv || noch zu erfassen || noch zu erfassen || noch zu erfassen
|-
| [[BayAM]] || aktiv || <code>MARCH-2026-1-RELEASE</code> || noch zu erfassen || 7. August 2026
|-
| GKP || aktiv || noch zu erfassen || noch zu erfassen || noch zu erfassen
|-
| [[LUX]] || aktiv || <code>MARCH-2026-1-RELEASE</code> || noch zu erfassen || 7. August 2026
|-
| Limes || aktiv || noch zu erfassen || noch zu erfassen || noch zu erfassen
|-
| Messe || aktiv || noch zu erfassen || noch zu erfassen || noch zu erfassen
|}

== MiQua Guide ==

'''MiQua Guide''' ist ein aktives Subprojekt von MiQua und kein eigenständiges Kundenprojekt. Es besitzt in der technischen Konfiguration den Schlüssel `miquaguide`. Der Guide kann die Stationen direkt ansprechen, ohne dass sich der Nutzer zuvor über einen Ticket-Monitor anmeldet.
== Inhalt einer Projektseite ==

Jede Projektseite soll mindestens enthalten:

* vollständiger Projektname und internes Kürzel
* verantwortliche Ansprechpartner innerhalb von tinetronics
* Domain von megbes-external
* DynDNS-Adresse oder interne Erreichbarkeit
* Container-Namen und Portzuordnungen
* installierte Releases
* eingesetzte Server- und Stationshardware
* projektspezifischer Stations-Timer
* Datum und Ergebnis der letzten Funktionsprüfung
* bekannte Besonderheiten und offene Aufgaben

Zugangsdaten, Tokens und Schlüssel werden durch einen Verweis auf den Passwortmanager ersetzt.

[[Kategorie:MegBes]]
[[Kategorie:Projekte]]

BayAM

2026-08-07T13:28:57Z

Clawtronics: Projektseite mit Referenz- und Inventur-Basisdaten angelegt

= BayAM – Bayerisches Armeemuseum =

== Projektüberblick ==

{| class="wikitable"
! Angabe
! Stand
|-
| Kunde / Einrichtung
| Bayerisches Armeemuseum, Ingolstadt
|-
| Medienstation
| „Sonne Mond & Sterne“
|-
| Interne Bezeichnung
| BayAM
|-
| Technischer Projektschlüssel
| <code>bayam</code>
|-
| Projektstatus
| aktiv
|}

tinetronics entwickelte und produzierte die Medienstation „Sonne Mond & Sterne“ für die Dauerausstellung des Bayerischen Armeemuseums in Ingolstadt. Sie vermittelt astronomische Phänomene und deren Bedeutung für militärische Navigation und Strategie. Historische Inhalte werden dabei mit moderner Medientechnik verbunden.

Quelle: [https://www.tinetronics.de/index_de.html tinetronics – Projektübersicht und Referenzen]

== MegBes-Betrieb ==

{| class="wikitable"
! Bestandteil
! Aktueller Stand
|-
| Externer Container
| <code>megbes-external-bayam</code>
|-
| External-Release
| <code>MARCH-2026-1-RELEASE</code>
|-
| Container-Port
| Nur lokal gebundener Host-Port <code>32768</code> auf Container-Port <code>8080</code>
|-
| Öffentliche MegBes-Adresse
| noch zu bestätigen
|-
| Interner Server / DynDNS
| noch zu erfassen
|-
| Internal-Release
| noch zu erfassen
|-
| Letzte technische Inventur
| 7. August 2026 – externer Container lief
|}

Die Angaben zum Container stammen aus der [[Zentraler MegBes-Server – Inventur und Administration|Serverinventur]]. Der Host-Port ist nur an <code>127.0.0.1</code> gebunden und wird nicht direkt aus dem Internet angesprochen.

== Noch zu ergänzen ==

* verantwortliche Ansprechpartner innerhalb von tinetronics
* Rolle von MegBes innerhalb der Medienstation und vorgesehene Zugriffsart
* öffentliche Domain
* lokaler Server, DynDNS und Routerkonfiguration
* Stationsliste und projektspezifischer Timer
* aktuelles Internal-Release
* Sicherungs- und Wiederherstellungsweg
* Datum und Ergebnis der nächsten vollständigen Funktionsprüfung

Zugangsdaten, Tokens, Schlüssel und vollständige DynDNS-Aktualisierungsadressen werden nicht auf dieser Seite gespeichert. Stattdessen wird auf den entsprechenden Eintrag im Passwortmanager verwiesen.

[[Kategorie:Projekte]]
[[Kategorie:MegBes]]

LUX

2026-08-07T13:28:57Z

Clawtronics: Projektseite mit Referenz- und Inventur-Basisdaten angelegt

= LUX – D’Lëtzebuerger Sprooch(en) =

== Projektüberblick ==

{| class="wikitable"
! Angabe
! Stand
|-
| Kunde / Träger
| Zenter fir d’Lëtzebuerger Sprooch
|-
| Ausstellung
| Wanderausstellung „D’Lëtzebuerger Sprooch(en)“
|-
| Interne Bezeichnungen
| LUX, Nowa Lux
|-
| Technischer Projektschlüssel
| <code>nowalux</code>
|-
| Projektstatus
| aktiv
|}

Die Wanderausstellung beschäftigt sich mit der luxemburgischen Sprache und ihrer Vielfalt. Nach der Projektreferenz von tinetronics umfasst sie annähernd 15 Stationen und setzt MegBes ein, damit Besucherinnen und Besucher Medienangebote mit dem eigenen Smartphone steuern können.

Zu den beschriebenen Angeboten gehören Videostationen, deren Bild auf den Ausstellungsmonitoren und deren Ton auf dem eigenen Smartphone wiedergegeben wird, außerdem ein Quiz zu den luxemburgischen Sprachen und eine Dialektkarte. Medien- und Lichttechnik sind miteinander kombiniert.

Quelle: [https://www.tinetronics.de/index_de.html tinetronics – Projektübersicht und Referenzen]

== MegBes-Betrieb ==

{| class="wikitable"
! Bestandteil
! Aktueller Stand
|-
| Externer Container
| <code>megbes-external-nowalux</code>
|-
| External-Release
| <code>MARCH-2026-1-RELEASE</code>
|-
| Container-Port
| Host-Port <code>34615</code> auf Container-Port <code>8080</code>
|-
| Öffentliche MegBes-Adresse
| noch zu bestätigen
|-
| Interner Server / DynDNS
| noch zu erfassen
|-
| Internal-Release
| noch zu erfassen
|-
| Letzte technische Inventur
| 7. August 2026 – externer Container lief
|}

Die Angaben zum Container stammen aus der [[Zentraler MegBes-Server – Inventur und Administration|Serverinventur]]. Die Portangabe beschreibt den internen Serverbetrieb und ist keine Aufforderung, den Port direkt öffentlich freizugeben.

== Noch zu ergänzen ==

* verantwortliche Ansprechpartner innerhalb von tinetronics
* öffentliche Domain und vorgesehene Zugriffsart
* lokaler Server, DynDNS und Routerkonfiguration
* vollständige Stationsliste und projektspezifischer Timer
* aktuelles Internal-Release
* Sicherungs- und Wiederherstellungsweg
* Datum und Ergebnis der nächsten vollständigen Funktionsprüfung

Zugangsdaten, Tokens, Schlüssel und vollständige DynDNS-Aktualisierungsadressen werden nicht auf dieser Seite gespeichert. Stattdessen wird auf den entsprechenden Eintrag im Passwortmanager verwiesen.

[[Kategorie:Projekte]]
[[Kategorie:MegBes]]

Neukunde

2026-08-07T13:19:47Z

Clawtronics: Seite als geführten, praxisnahen Ablauf für neue Projekte überarbeitet

= Neukunde / neues Projekt =

Diese Seite ist der rote Faden für die Einrichtung eines neuen MegBes-Projekts. Sie führt von den ersten Angaben bis zur Übergabe. Technische Einzelheiten stehen auf den jeweils verlinkten Fachseiten – hier geht es vor allem darum, '''was als Nächstes zu tun ist''' und woran du erkennst, dass eine Etappe abgeschlossen ist.

Nicht jedes Projekt benötigt alle hier genannten Bausteine. Wenn beispielsweise kein lokaler MegBes-Server vorgesehen ist, können die entsprechenden Schritte übersprungen werden.

== Der Weg zum fertigen Projekt ==

# Projekt und Ansprechpartner erfassen
# Betriebsart und benötigte Komponenten festlegen
# Öffentliche MegBes-Seite bereitstellen
# Technik am Standort vorbereiten
# Stationen anbinden
# Gesamtsystem abnehmen und dokumentieren

== 1. Projekt beginnen ==

'''Ziel dieser Etappe:''' Alle Beteiligten sprechen über dasselbe Projekt, und die wichtigsten Ansprechpartner sind bekannt.

Lege zunächst in der [[Projektübersicht]] eine eigene Projektseite an. Verwende dafür den Namen, unter dem das Projekt später auch intern wiedergefunden werden soll.

Auf der Projektseite sollten mindestens diese Angaben stehen:

{| class="wikitable"
! Angabe
! Beispiel oder Erläuterung
|-
| Kunde und Projektname
| Museum Beispielstadt – Dauerausstellung
|-
| Technischer Projektschlüssel
| Kurzer, eindeutiger Name ohne Leerzeichen, z. B. <code>beispielstadt</code>
|-
| Zuständige Personen
| Projektleitung, technische Betreuung und Ansprechpartner vor Ort
|-
| Geplanter Betriebsbeginn
| Eröffnung, Testbetrieb oder Übergabetermin
|-
| Anzahl der Stationen
| Einschließlich Reserve- oder Teststationen
|-
| Aktueller Stand
| Planung, Einrichtung, Test oder Betrieb
|}

Der technische Projektschlüssel wird später unter anderem für Container, Konfigurationsdateien und Adressen verwendet. Er sollte deshalb früh festgelegt und danach nicht mehr geändert werden.

'''Weiter, wenn …''' eine Projektseite vorhanden ist, der Projektschlüssel feststeht und mindestens je ein organisatorischer und technischer Ansprechpartner bekannt ist.

== 2. Gemeinsam festlegen, wie das Projekt funktionieren soll ==

'''Ziel dieser Etappe:''' Die grundlegenden Entscheidungen sind getroffen, bevor Server oder Container eingerichtet werden.

=== Was sollen Besucherinnen und Besucher sehen? ===

Kläre, welche Informationen auf der MegBes-Seite erscheinen sollen, zum Beispiel:

* aktuelle Verfügbarkeit oder Zustände der Stationen,
* Hinweise zu einzelnen Angeboten,
* eine für das Projekt gestaltete Oberfläche,
* mehrere Sprachen.

Halte Gestaltungswünsche, Sprachen und besondere Inhalte auf der Projektseite fest.

=== Wie wird die Seite aufgerufen? ===

Entscheide zwischen den üblichen Betriebsarten:

* '''Direkter Zugriff:''' Die Seite ist ohne vorherige Prüfung erreichbar.
* '''Zugriff über Ticket-Monitor:''' Der Aufruf wird anhand der vorgesehenen Berechtigung freigegeben.

Eine verständliche Gegenüberstellung steht unter [[Bedienung und Authentifizierung]].

=== Welche Technik wird benötigt? ===

Prüfe gemeinsam mit der technischen Betreuung:

* Wird nur die öffentliche MegBes-Seite benötigt?
* Gibt es vor Ort einen lokalen MegBes-Server?
* Wie melden die Stationen ihren Zustand – insbesondere per UDP oder über einen anderen vorgesehenen Weg?
* Wird für den Standort DynDNS oder eine feste öffentliche Adresse benötigt?
* Wer kann Änderungen an Router, Firewall und Standortnetz freigeben?

'''Weiter, wenn …''' Betriebsart, benötigte Komponenten, Stationenzahl und Verantwortlichkeiten für das Standortnetz feststehen.

'''Noch nicht weitermachen, wenn …''' unklar ist, ob ein lokaler Server benötigt wird oder wer Router- und Firewall-Änderungen genehmigen darf. Diese Entscheidungen beeinflussen den gesamten weiteren Aufbau.

== 3. Die öffentliche Seite vorbereiten ==

'''Ziel dieser Etappe:''' Das Projekt ist über seine spätere öffentliche Adresse erreichbar und zeigt die richtige Konfiguration.

Gehe in dieser Reihenfolge vor:

# Lege die gewünschte Adresse fest, normalerweise <code><projekt>.megbes.de</code>.
# Erstelle die Projektkonfiguration im Repository <code>tinetronics/megbes-config</code>. Die benötigten Felder sind unter [[Konfiguration]] beschrieben.
# Stelle unter Plesk einen eigenen <code>megbes-external</code>-Container für das Projekt bereit. Die technische Anleitung steht unter [[Megbes-external unter Plesk]].
# Verknüpfe Domain, Zertifikat und Container.
# Öffne die Adresse im Browser und kontrolliere Inhalt, Gestaltung und Verhalten.

Verwende grundsätzlich eine freigegebene Release-Version. Zugangsdaten, Tokens, private Schlüssel und vollständige DynDNS-Aktualisierungsadressen gehören '''nicht''' ins Wiki oder in die Projektkonfiguration, sondern in den vorgesehenen Passwortmanager.

'''Weiter, wenn …'''

* die öffentliche Adresse per HTTPS ohne Zertifikatswarnung erreichbar ist,
* die richtige Projektoberfläche erscheint,
* die vereinbarte Zugriffsart funktioniert,
* keine Zugangsdaten in Wiki, Repository oder Containerbeschreibung abgelegt wurden.

== 4. Den Standort vorbereiten ==

'''Ziel dieser Etappe:''' Der lokale MegBes-Server ist zuverlässig erreichbar und kann mit den Stationen sowie der öffentlichen Seite kommunizieren.

Dieser Abschnitt entfällt, wenn das Projekt keinen lokalen MegBes-Server benötigt.

=== Vor dem Aufbau klären ===

Besorge oder bestätige zunächst:

* Standort und Hardware des Servers,
* feste interne IP-Adresse,
* DNS- und Gateway-Angaben,
* Zugang zum Router beziehungsweise eine zuständige Kontaktperson,
* DynDNS-Name, falls erforderlich,
* Liste der Stationen mit Namen und IP-Adressen,
* geplante Sicherung und verantwortliche Person.

=== Server in sinnvollen Etappen einrichten ===

# Ubuntu installieren und aktualisieren: [[Ubuntu installieren]] und [[Ubuntu aktualisieren]]
# Eine feste interne Adresse einrichten: [[Feste IP-Adresse unter Ubuntu]]
# Docker installieren und prüfen: [[Docker installieren]]
# <code>megbes-internal</code> mit der Projektkonfiguration starten: [[Megbes-internal]]
# Router, DynDNS und erforderliche Weiterleitungen einrichten: [[DynDNS und Router]]
# Zertifikate einrichten oder übertragen: [[Zertifikate]]

Führe nach jeder Etappe einen kurzen Funktionstest durch. So ist bei einem Fehler sofort klar, in welchem Abschnitt er entstanden ist.

'''Weiter, wenn …'''

* der Server nach einem Neustart wieder erreichbar ist,
* der interne Container selbstständig startet,
* die Projektkonfiguration geladen wird,
* die benötigte Verbindung zwischen Standort und öffentlicher Seite funktioniert,
* keine unnötigen Dienste oder Ports aus dem Internet erreichbar sind.

== 5. Stationen Schritt für Schritt anbinden ==

'''Ziel dieser Etappe:''' Jede Station erscheint eindeutig und mit dem richtigen Zustand im System.

Beginne nicht sofort mit allen Stationen. Nimm zuerst eine gut erreichbare Teststation:

# Vergib oder bestätige Namen und IP-Adresse der Station.
# Trage sie in der Projektkonfiguration ein.
# Richte die vorgesehene Zustandsmeldung ein.
# Prüfe den Signalweg vom Gerät bis zur Anzeige. Hilfestellung: [[UDP und Stationszustände]] und [[Routing und Signalweg]].
# Simuliere mindestens einen Zustandswechsel und kontrolliere die Anzeige.

Wenn die Teststation zuverlässig funktioniert, übertrage das Vorgehen auf die übrigen Stationen. Arbeite die Stationsliste einzeln ab und markiere jede geprüfte Station auf der Projektseite.

'''Weiter, wenn …''' jede Station eindeutig zugeordnet ist, Zustandsänderungen korrekt erscheinen und ein Neustart der Station beziehungsweise des lokalen Servers erfolgreich getestet wurde.

== 6. Gemeinsame Abnahme ==

'''Ziel dieser Etappe:''' Das System funktioniert nicht nur technisch, sondern auch im vorgesehenen Arbeitsalltag.

Führe die Abnahme möglichst gemeinsam mit einer verantwortlichen Person des Projekts durch.

=== Besucheransicht ===

* Öffnet sich die richtige Seite auf Smartphone und einem normalen Rechner?
* Sind Texte, Logos, Farben und Sprachen korrekt?
* Ist die Bedienung verständlich?
* Funktioniert die vereinbarte Zugriffsart?

=== Technischer Betrieb ===

* Werden alle Stationen mit dem richtigen Namen und Zustand angezeigt?
* Werden Ausfall, Rückkehr und Neustart einer Teststation korrekt erkannt?
* Starten Server und Container nach einem Neustart automatisch?
* Sind HTTPS und Zertifikatskette fehlerfrei?
* Sind nur die tatsächlich benötigten Ports erreichbar?

=== Betrieb und Wiederherstellung ===

* Ist festgelegt, wer Störungen zuerst prüft?
* Sind Sicherung und Wiederherstellung beschrieben und mindestens einmal geprüft?
* Sind Zugangsdaten vollständig im Passwortmanager hinterlegt?
* Ist die eingesetzte Release-Version dokumentiert?

Für den späteren Betrieb dient [[Wartung, Backups und Fehlerdiagnose]] als zentrale Arbeitsseite. Der [[Status-Monitor]] hilft bei der laufenden Übersicht.

'''Das Projekt ist bereit zur Übergabe, wenn …''' alle Abnahmepunkte entweder bestätigt oder als bekannte Restpunkte mit Verantwortlichem und Termin dokumentiert sind.

== 7. Projekt sauber übergeben ==

Ergänze zum Abschluss die Projektseite um:

* öffentliche und interne Adressen ohne geheime Bestandteile,
* eingesetzte Container und Release-Versionen,
* Stationsliste,
* Betriebsart und besondere Konfiguration,
* zuständige Personen,
* Datum und Ergebnis der Abnahme,
* bekannte Restpunkte,
* Verweise auf Sicherung, Passwortmanager-Eintrag und weitere Betriebsdokumentation.

Setze den Projektstatus in der [[Projektübersicht]] anschließend auf '''Betrieb'''.

== Wenn etwas nicht wie erwartet funktioniert ==

Gehe vom letzten erfolgreichen Prüfpunkt aus zurück. Prüfe zunächst nur den betroffenen Abschnitt, statt mehrere Komponenten gleichzeitig zu ändern.

Eine hilfreiche Reihenfolge ist:

# Ist die betroffene Station oder der Server eingeschaltet und im Netz erreichbar?
# Läuft der zuständige Container?
# Ist die richtige Projektkonfiguration geladen?
# Funktioniert der Signalweg zwischen Station, lokalem Server und öffentlicher Seite?
# Gibt es aktuelle Meldungen in den Container-Protokollen oder im [[Status-Monitor]]?

Dokumentiere Ursache und Lösung auf der Projektseite, wenn der Fehler projektspezifisch war. Allgemein wiederverwendbare Erkenntnisse gehören nach [[Wartung, Backups und Fehlerdiagnose]].

[[Kategorie:Betrieb]]
[[Kategorie:Projekte]]

Wartung, Backups und Fehlerdiagnose

2026-08-07T13:08:24Z

Clawtronics: MongoDB-Sicherungsverfahren verknüpft

= Wartung, Backups und Fehlerdiagnose =

== Zweck ==

Regelmäßige Wartung hält zentrale und lokale MegBes-Komponenten sicher, nachvollziehbar und wiederherstellbar. Änderungen erfolgen projektweise und mit dokumentiertem Rückkehrweg.

== Status-Monitor ==

Der zentrale [[Status-Monitor]] unter [https://status.megbes.de status.megbes.de] zeigt die Health-Zustände der konfigurierten External- und Internal-Instanzen. Ein grüner Status bestätigt die Erreichbarkeit des jeweiligen Management-Endpunkts, aber nicht automatisch den vollständigen Signalweg bis zur Medienstation.

== Regelmäßige Kontrollen ==

{| class="wikitable"
! Bereich
! Prüfung
|-
| Container || Laufzustand, Neustarts und aktuelle Fehler im Log
|-
| Betriebssystem || verfügbare Sicherheitsaktualisierungen und freier Speicherplatz
|-
| Netzwerk || Erreichbarkeit, DynDNS-Auflösung und Routerweiterleitung
|-
| Zertifikate || Gültigkeitsende und korrekte Projektzuordnung
|-
| MegBes-Release || installierter Stand gegenüber freigegebenem Stand
|-
| Medienstationen || Erreichbarkeit, Rückmeldungen und automatischer Wiederanlauf
|-
| Dokumentation || Übereinstimmung von Projektseite und tatsächlichem System
|}

== Datenbanksicherung ==
Das tägliche logische Backup der zentralen Datenbank ist unter [[MongoDB sichern und wiederherstellen]] beschrieben.

== Vor einer Änderung sichern ==

Zu erfassen beziehungsweise zu sichern sind mindestens:

* projektspezifische Konfiguration ohne ungeschützte Weitergabe von Geheimwerten
* Containerdefinition, Portzuordnungen und Dateimounts
* aktuell eingesetzter MegBes-Release
* Zertifikats- und Keystore-Dateien in geschützter Ablage
* kundenspezifische Skripte und Stationssoftware
* für Raspberry-Pi-Stationen gegebenenfalls ein geprüftes SD-Karten-Abbild
* Datum, Anlass und verantwortliche Person der Sicherung

Eine Sicherung gilt erst als belastbar, wenn Ablageort, Lesbarkeit und vorgesehener Wiederherstellungsweg geprüft wurden.

== Sicherer Wartungsablauf ==

# Istzustand und konkrete Störung beziehungsweise Wartungsaufgabe dokumentieren.
# Projektbezogene Konfiguration und Release feststellen.
# Rückkehrweg und benötigte Sicherungen vorbereiten.
# Änderung nur an einer klar abgegrenzten Stufe durchführen.
# Logs und unmittelbare Erfolgskriterien prüfen.
# Gesamten Signalweg mit einem kontrollierten Test durchlaufen.
# Stationszustände und Wiederanlauf prüfen.
# Ergebnis und neuen Istzustand auf der Projektseite dokumentieren.

== Fehlerdiagnose nach Ebenen ==

# Bedienoberfläche und Authentifizierung
# `megbes-external` und dessen Containerlog
# DNS, DynDNS und öffentliches Routing
# Router, Portweiterleitung und lokale Firewall
# `megbes-internal` und dessen Anwendungslog
# UDP-Weg im Ausstellungsnetz
# Medienstation, Empfängersoftware und konkrete Befehle

Details: [[Routing und Signalweg]].

== Sichere Abbruchpunkte ==

Die Arbeit wird abgebrochen und der letzte bekannte Zustand wiederhergestellt, wenn die Projektzuordnung unklar ist, eine Änderung mehrere Kundencontainer unerwartet betrifft, Geheimwerte fehlen oder nicht eindeutig zugeordnet sind, keine belastbare Sicherung existiert oder sich der bisherige Release nicht bestimmen lässt.

== Nachkontrolle ==

* öffentliche Anwendung erreichbar
* interner Server erreichbar
* mindestens ein repräsentativer Steuerbefehl erfolgreich
* Rückmeldung einer stationsgesteuerten Station erfolgreich
* keine neue Fehlerserie in den Logs
* Dokumentation und tatsächlicher Zustand stimmen überein

== Zentraler Server ==
Der geprüfte Istzustand und das Berechtigungsmodell sind unter [[Zentraler MegBes-Server – Inventur und Administration]] dokumentiert.

[[Kategorie:MegBes]]
[[Kategorie:Wartung]]
[[Kategorie:Fehlerdiagnose]]
[[Kategorie:Betrieb]]

Zentraler MegBes-Server – Inventur und Administration

2026-08-07T13:08:24Z

Clawtronics: MongoDB-Backupautomatisierung und Wiki-Logo ergänzt

= Zentraler MegBes-Server – Inventur und Administration =

== Zweck und Status ==
Diese Seite dokumentiert den geprüften Istzustand, das Berechtigungsmodell und das Inventurverfahren des zentralen MegBes-Servers. Sie ist die technische Grundlage für Wartung, Fehlerdiagnose und das spätere Anlegen neuer Kundencontainer.

'''Stand der Bestandsaufnahme: 7. August 2026.''' System, Container, Mounts, Hostbindungen, Plesk-Proxy-Zuordnungen, Firewall-Grundzustand und vorhandene Plesk-Sicherungen wurden ausschließlich lesend aufgenommen. MongoDB-Authentisierung, Herkunft der Containerdefinitionen und ein praktischer Wiederherstellungstest bleiben offen. Vorläufige Beobachtungen sind ausdrücklich als solche gekennzeichnet.

== Serverbasis ==
{| class="wikitable"
! Merkmal !! Geprüfter Stand
|-
| Hosting || IONOS-Server mit Plesk
|-
| Betriebssystem || Ubuntu 24.04.4 LTS, x86_64
|-
| Plesk || Plesk Obsidian 18.0.79.5
|-
| Container-Laufzeit || Docker 29.7.2
|-
| Arbeitsspeicher || 15,55 GiB für die Container verfügbar
|-
| Massenspeicher || 464 GiB gesamt, rund 22 GiB belegt; zum Prüfzeitpunkt kein Kapazitätsengpass
|-
| Swap || nicht eingerichtet
|-
| Laufzeit des Hosts || rund 94 Tage zum Prüfzeitpunkt
|-
| Docker-Netzwerke || Standardnetzwerke `bridge`, `host` und `none`; keine benannten projektspezifischen Netzwerke
|-
| Docker-Volumes || Keine benannten Volumes; persistente Daten werden voraussichtlich über Bind-Mounts bereitgestellt und müssen noch geprüft werden
|}

Die öffentliche IP-Adresse, Zugangsdaten und weiteren sicherheitsrelevanten Verbindungsdaten werden nicht auf dieser Seite veröffentlicht. Sie liegen in der geschützten System- beziehungsweise Passwortdokumentation.

== Berechtigungsmodell für Administration ==
Für automatisierte Prüfung und unterstützte Administration existiert der eigene Serverbenutzer `clawtronics` mit separatem ED25519-Schlüssel.

Der Benutzer:

* besitzt keine Mitgliedschaft in der Gruppe `docker`,
* besitzt keinen pauschalen Root- oder sudo-Zugang,
* darf nur ausdrücklich freigegebene, root-eigene Hilfsskripte ohne Passwort ausführen,
* kann die freigegebenen Skripte selbst nicht verändern,
* erhält neue Rechte stufenweise und nur für einen dokumentierten Betriebszweck.

Der aktuelle Read-only-Befehl `/usr/local/sbin/megbes-discovery` liefert ausschließlich Plesk-Version, Container, Images, Docker-Netzwerke, Docker-Volumes und eine momentane Ressourcenübersicht. Containeränderungen, `docker exec`, Datenbankzugriffe und Dateisystemänderungen sind nicht freigegeben.

Die Gruppe `docker` wird nicht vergeben, da deren Mitgliedschaft praktisch Root-Rechte ermöglicht. Erweiterungen werden als eng begrenzte, root-eigene Hilfsskripte umgesetzt.

== Aktueller Containerbestand ==
Zum Prüfzeitpunkt liefen 13 Container ohne sichtbare Neustartschleife.

{| class="wikitable"
! Container !! Image beziehungsweise Release !! Hostbindung !! Aufgabe
|-
| `megbes-status` || `tinetronics/megbes-status:AUGUST-2026-2-RELEASE` || alle IPv4-Schnittstellen, Port 9990 || zentraler [[Status-Monitor]]
|-
| `megbes-external-tine` || `MARCH-2026-1-RELEASE` || alle IPv4-Schnittstellen, Port 32770 || Kundenprojekt Tine
|-
| `megbes-external-limes` || `MARCH-2026-1-RELEASE` || alle IPv4-Schnittstellen, Port 32780 || Kundenprojekt Limes
|-
| `megbes-external-gkp` || `MARCH-2026-1-RELEASE` || alle IPv4-Schnittstellen, Port 32769 || Kundenprojekt GKP
|-
| `megbes-external-bayam` || `MARCH-2026-1-RELEASE` || nur localhost, Port 32768 || Kundenprojekt BayAM
|-
| `megbes-external-miqua` || `MARCH-2026-1-RELEASE` || alle IPv4-Schnittstellen, Port 32779 || Kundenprojekt MiQua
|-
| `megbes-external-messe` || `MARCH-2026-1-RELEASE` || alle IPv4- und IPv6-Schnittstellen, Port 32771 || Kundenprojekt Messe
|-
| `megbes-external-hon` || `MARCH-2026-1-RELEASE` || nur localhost, Port 9997 || Kundenprojekt HoN
|-
| `mediawiki` || `mediawiki:latest` || nur localhost, Port 49155 || internes MegBes-Wiki
|-
| `mongodb` || `mongo:7.0.12` || alle IPv4-Schnittstellen, Port 49154 || zentrale MongoDB
|-
| `megbes-external-nowalux` || `MARCH-2026-1-RELEASE` || alle IPv4-Schnittstellen, Port 34615 || Kundenprojekt NowaLux
|-
| `megbes-external-miquaguide` || `MARCH-2026-1-RELEASE` || alle IPv4- und IPv6-Schnittstellen, Port 32774 || Kundenprojekt MiQua Guide
|-
| `megbes-external-gse` || `MARCH-2026-1-RELEASE` || alle IPv4-Schnittstellen, Port 32805 || Kundenprojekt GSE
|}

Die Hostbindung zeigt, an welchen Schnittstellen Docker lauscht. Sie beweist allein noch keine Erreichbarkeit aus dem Internet; dafür müssen zusätzlich Plesk-, Firewall- und Providerregeln geprüft werden.

== Containerbetrieb und Mounts ==
Alle Container verwenden die Restart-Policy `unless-stopped`. Kein Container besitzt einen Docker-Healthcheck. Die angezeigten Speicherlimits entsprechen jeweils dem gesamten Hostspeicher; damit sind keine individuellen Container-Speichergrenzen erkennbar.

Die persistenten beziehungsweise extern bereitgestellten Daten werden über beschreibbare Bind-Mounts eingebunden:

{| class="wikitable"
! Bereich !! Hostpfad !! Containerpfad !! Bemerkung
|-
| allgemeine Schlüsselablage || `/home/ssl` || `/opt/app/key` || bei Status-Monitor und mehreren External-Containern eingebunden
|-
| allgemeine Zertifikate || `/home/certs` || `/opt/app/certs` || beim Status-Monitor eingebunden
|-
| projektspezifische Zertifikate || `/home/certs/<projekt>` || `/opt/app/certs` || bei Tine, Limes, BayAM, MiQua, Messe, HoN, MiQua Guide und GSE
|-
| MediaWiki-Daten || `/home/megbeswiki` || `/var/www/data` || enthält die persistente Wiki-Konfiguration und -Daten
|-
| MongoDB-Daten || `/root/mdb/data` || `/data/db` || produktive Datenablage
|-
| MongoDB-Konfiguration || `/root/mdb/config` || `/data/configdb` || Konfigurationsdatenbank
|}

Alle ermittelten Mounts sind mit Schreibrecht eingebunden. Für reine Zertifikats- und Schlüsselablagen ist später zu prüfen, ob ein Read-only-Mount genügt. Eine solche Änderung darf erst nach Prüfung der Anwendung und mit Rückkehrweg erfolgen.

== Netzwerk und externe Erreichbarkeit ==
UFW ist auf dem Host inaktiv. `nftables` enthält von Docker erzeugte NAT- und Filterregeln sowie Fail2ban-Regeln. Zusätzlich muss eine vorgelagerte Provider- oder Plesk-Firewall wirken, da nicht alle lokal gebundenen Ports von außen erreichbar waren.

Ein externer TCP-Verbindungstest am 7. August 2026 ergab:

{| class="wikitable"
! Port beziehungsweise Gruppe !! Ergebnis
|-
| 22, 80 und 443 || öffentlich erreichbar; erwartete SSH- und Webdienste
|-
| 9990 || öffentlich direkt erreichbar; Status-Monitor zusätzlich zum Domainzugriff exponiert
|-
| 9997 und 32768 || nicht öffentlich erreichbar und lokal an `127.0.0.1` gebunden
|-
| 32769, 32770, 32771, 32774, 32779, 32780, 32805 und 34615 || trotz Bindung an alle Schnittstellen beim Test nicht öffentlich erreichbar
|-
| 49154 || MongoDB trotz Bindung an alle IPv4-Schnittstellen beim Test nicht öffentlich erreichbar
|-
| 49155 || MediaWiki nicht öffentlich direkt erreichbar und lokal an `127.0.0.1` gebunden
|}

Die externe Nichterreichbarkeit ist eine Momentaufnahme und ersetzt keine bewusst dokumentierte Firewallregel. Empfohlen ist, Reverse-Proxy-Ziele grundsätzlich an `127.0.0.1` zu binden, sofern kein direkter Zugriff erforderlich ist. Besonders Port 9990 und die MongoDB-Bindung sind vor einer Änderung zunächst gegen den betrieblichen Zweck und die Plesk-Konfiguration zu prüfen.

== Plesk-Domains und Reverse Proxy ==
Plesk verwaltet die Domains beziehungsweise Subdomains `bayam`, `gkp`, `hon`, `limes`, `megbes.de`, `messe`, `miqua`, `miquaguide`, `nowalux`, `status`, `tine`, `vserver` und `wiki` unter `megbes.de`.

Die nginx-Konfigurationen leiten die projektbezogenen Domains auf die jeweiligen Docker-Hostports weiter. Die Ziele sind derzeit überwiegend als `0.0.0.0:<port>` eingetragen. Funktional ist das möglich; als klareres internes Proxyziel sollte bei einer späteren Bereinigung `127.0.0.1:<port>` zusammen mit einer lokalen Containerbindung geprüft werden. Generierte Plesk-Konfigurationen dürfen nicht direkt und dauerhaft bearbeitet werden; Änderungen erfolgen über die zuständige Plesk-Einstellung beziehungsweise zusätzliche Konfiguration.

== Sicherungsstand ==
Im Plesk-Sicherungsverzeichnis liegen tägliche inkrementelle Sicherungen mit erfolgreichen Statusmarkern bis einschließlich 7. August 2026. Erfasst sind Plesk-Systembestandteile sowie die Domains `gkp.megbes.de`, `hon.megbes.de`, `megbes.de`, `nowalux.megbes.de`, `status.megbes.de`, `vserver.megbes.de` und `wiki.megbes.de`.

Für MongoDB wurde zusätzlich ein logisches Sicherungsverfahren mit `mongodump` eingerichtet. Der erste aktuelle, komprimierte Dump wurde erfolgreich erstellt und mittels Gzip-Test und SHA-256 geprüft. Ein Cronjob erstellt täglich um 02:17 Uhr UTC einen neuen Dump. Details und Wiederherstellungsregeln: [[MongoDB sichern und wiederherstellen]].

Noch offen sind automatische Aufbewahrung, eine externe Kopie außerhalb des Servers und ein praktischer Wiederherstellungstest. Aus der Plesk-Dateiliste lässt sich außerdem nicht ableiten, dass `/home/certs`, `/home/ssl` und alle Containerdefinitionen vollständig gesichert werden.

== Wiki-Logo und Persistenz ==
Das MegBes-Logo aus dem Status-Monitor ist im Wiki eingebunden. Die ausgelieferte Datei und das Quelllogo besitzen dieselbe SHA-256-Prüfsumme. Vor der Änderung wurde `LocalSettings.php` geschützt unter `/home/megbeswiki/config-backups` gesichert.

Logo und persistente Kopie liegen unter `/home/megbeswiki/assets`. Die aktive `LocalSettings.php` und die ausgelieferte Bilddatei befinden sich derzeit jedoch im beschreibbaren Layer des MediaWiki-Containers. Nach einer Neuerstellung des Containers muss die fest definierte Aktion `wiki-logo-install` erneut ausgeführt werden. Langfristig sollten `LocalSettings.php` und Logo als eigene Bind-Mounts in der Containerdefinition verankert werden.

== Erste Betriebsbeobachtungen ==
* Alle 13 Container liefen zum Prüfzeitpunkt seit rund sechs Stunden.
* Die momentane CPU- und Speicherauslastung war unauffällig.
* Der Status-Monitor nutzt den derzeit bekannten aktuellen Release `AUGUST-2026-2-RELEASE`.
* Die zehn Kundencontainer von `megbes-external` verwenden `MARCH-2026-1-RELEASE`, obwohl das Image `AUGUST-2026-1-RELEASE` lokal vorhanden ist. Daraus folgt kein automatischer Updateauftrag; Freigabe, Kompatibilität und Rückkehrweg sind projektweise zu prüfen.
* MediaWiki sowie BayAM und HoN sind nur an localhost gebunden.
* Die Bindung von MongoDB an alle IPv4-Schnittstellen ist sicherheitsrelevant. Der Port war extern nicht erreichbar; Authentisierung, vorgelagerte Filterregel und tatsächlicher Verwendungszweck bleiben dennoch zu prüfen.
* Mehrere MegBes-Ports sind an alle Schnittstellen gebunden, waren beim externen Test mit Ausnahme von Port 9990 jedoch nicht erreichbar. Ob die Bindungen erforderlich sind oder Plesk als lokaler Reverse Proxy genügt, wird projektweise geprüft.

== Inventurplan ==
Die folgenden Punkte werden ausschließlich lesend aufgenommen, bevor Betriebsänderungen erfolgen:

# Eigentümer, Rechte und Sicherungsumfang der ermittelten Datenpfade
# Herkunft und reproduzierbare Definition der Container
# Zertifikatszuordnungen und Erneuerungsverfahren
# MongoDB-Authentisierung und Netzwerkbindung, ohne Geheimwerte auszugeben
# konsistentes Backup der MongoDB- und MediaWiki-Daten
# Aufbewahrungsdauer und praktischer Wiederherstellungstest
# Logwachstum und Logrotation der Container
# standardisierter Ablauf für Update, Rollback und neuen Kundencontainer

== Regeln für Änderungen ==
* Vor jeder Änderung werden betroffene Container, Konfiguration, Mounts, Ports und aktueller Image-Stand gesichert beziehungsweise dokumentiert.
* Geheimwerte werden weder in Befehlsausgaben noch im Wiki gespeichert.
* Ein Container wird nur mit bekanntem Rückkehrweg ersetzt.
* Datenbank- und Volume-Änderungen erfolgen erst nach geprüfter Sicherung.
* Neustarts, Updates und neue Kundencontainer benötigen einen ausdrücklichen Auftrag.
* Nach Änderungen werden Anwendung, Logs, Status-Monitor und mindestens ein kontrollierter Projektablauf geprüft.

Siehe auch [[Megbes-external unter Plesk]] und [[Wartung, Backups und Fehlerdiagnose]].

[[Kategorie:MegBes]]
[[Kategorie:Betrieb]]
[[Kategorie:Plesk]]
[[Kategorie:Wartung]]
[[Kategorie:Sicherheit]]

MongoDB sichern und wiederherstellen

2026-08-07T13:08:23Z

Clawtronics: Geprüftes MongoDB-Dump-, Prüf- und Wiederherstellungsverfahren dokumentiert

= MongoDB sichern und wiederherstellen =

== Zweck und geprüfter Stand ==
Die zentrale MongoDB enthält betriebsrelevante MegBes-Daten. Sie wird deshalb mit `mongodump` logisch und konsistent in ein komprimiertes Archiv gesichert. Eine Kopie des laufenden Datenverzeichnisses `/root/mdb/data` gilt nicht als Ersatz für diesen Dump.

'''Stand: 7. August 2026.'''

* MongoDB läuft als Container `mongodb` mit Image `mongo:7.0.12`.
* Authentisierung ist aktiv; ein nicht angemeldeter Versuch, Datenbanken aufzulisten, wird abgewiesen.
* MongoDB Database Tools 100.10.0 mit `mongodump` und `mongorestore` sind im Container vorhanden.
* Der erste neue Dump wurde erfolgreich erstellt sowie per Gzip-Test und SHA-256-Prüfsumme verifiziert.
* Die automatische Sicherung läuft täglich um 02:17 Uhr Serverzeit (UTC), entsprechend im Sommer 04:17 Uhr in Deutschland.

== Sicherungsablage ==
Die Archive liegen ausschließlich root-lesbar unter:

`/root/backups/mongodb/megbes-mongodb-<UTC-Zeitstempel>.archive.gz`

Zu jedem Archiv gehört eine Datei mit SHA-256-Prüfsumme:

`/root/backups/mongodb/megbes-mongodb-<UTC-Zeitstempel>.archive.gz.sha256`

Dateien und Verzeichnis besitzen restriktive Rechte. Die Datenbankzugangsdaten werden weder im Dateinamen noch im Log oder Wiki ausgegeben. `mongodump` erhält das Passwort über eine kurzlebige, nur im Container lesbare Konfigurationsdatei, die anschließend entfernt wird.

== Automatisierung ==
Der Benutzer `clawtronics` besitzt einen Cron-Eintrag:

17 2 * * * sudo -n /usr/local/sbin/megbes-admin mongo-backup >> /home/clawtronics/mongo-backup.log 2>&1

Der Cronjob darf nur die fest implementierte Aktion `mongo-backup` des root-eigenen Werkzeugs `megbes-admin` aufrufen. Ein allgemeiner Docker- oder Root-Zugang wird dadurch nicht vergeben.

== Manuelle Sicherung ==
Eine zusätzliche Sicherung kann über den freigegebenen Administrationsweg erstellt werden:

sudo -n /usr/local/sbin/megbes-admin mongo-backup

Erfolgskriterien:

* Ausgabe nennt ein neues Archiv mit UTC-Zeitstempel.
* Archiv ist nicht leer.
* `gzip -t` endet erfolgreich.
* SHA-256-Datei wird erzeugt.

== Status und Integritätsprüfung ==
Der aktuelle Stand wird ohne Ausgabe von Datenbankinhalten geprüft:

sudo -n /usr/local/sbin/megbes-admin mongo-backup-status

Die Aktion listet die vorhandenen Archive und prüft beim jüngsten Dump Gzip-Struktur und SHA-256-Prüfsumme.

== Wiederherstellung ==
Eine Wiederherstellung wird nicht automatisiert gegen die produktive Datenbank ausgeführt. Vorher sind zwingend festzulegen:

# Zielsystem oder isolierter Testcontainer
# gewünschter Sicherungszeitpunkt
# Rückkehrweg und aktuelle zusätzliche Sicherung
# Umgang mit bestehenden Datenbanken und Collections
# erwartete Ausfallzeit
# Funktions- und Vollständigkeitsprüfung

Die Wiederherstellung erfolgt grundsätzlich mit `mongorestore`, `--archive`, `--gzip` und `--stopOnError`. Passwörter gehören in eine geschützte Konfigurationsdatei und nicht in die Prozessargumente. Der genaue Befehl wird für das konkrete Zielsystem erzeugt und vor Ausführung kontrolliert.

Mindestens einmal nach Einrichtung sowie anschließend regelmäßig ist ein Wiederherstellungstest in einer isolierten MongoDB-Instanz durchzuführen. Erst ein erfolgreich zurückgespielter und fachlich geprüfter Dump gilt als belastbare Sicherung.

== Aufbewahrung und externe Kopie ==
Eine automatische Löschung alter Dumps ist noch nicht aktiviert. Vor Einführung einer Rotation sind Aufbewahrungsdauer und externes Sicherungsziel festzulegen. Empfohlen sind mehrere Generationen sowie mindestens eine Kopie außerhalb des Servers; lokale Dumps allein schützen nicht vor Ausfall oder Verlust des gesamten Servers.

== Quellen ==
* [https://www.mongodb.com/docs/database-tools/mongodump/ MongoDB-Dokumentation zu mongodump]
* [https://www.mongodb.com/docs/database-tools/mongorestore/ MongoDB-Dokumentation zu mongorestore]

[[Kategorie:MegBes]]
[[Kategorie:MongoDB]]
[[Kategorie:Backup]]
[[Kategorie:Betrieb]]

Zentraler MegBes-Server – Inventur und Administration

2026-08-07T12:57:22Z

Clawtronics: Vertiefte Read-only-Inventur: Mounts, Ports, Proxy, Firewall und Sicherungsstand ergänzt

= Zentraler MegBes-Server – Inventur und Administration =

== Zweck und Status ==
Diese Seite dokumentiert den geprüften Istzustand, das Berechtigungsmodell und das Inventurverfahren des zentralen MegBes-Servers. Sie ist die technische Grundlage für Wartung, Fehlerdiagnose und das spätere Anlegen neuer Kundencontainer.

'''Stand der Bestandsaufnahme: 7. August 2026.''' System, Container, Mounts, Hostbindungen, Plesk-Proxy-Zuordnungen, Firewall-Grundzustand und vorhandene Plesk-Sicherungen wurden ausschließlich lesend aufgenommen. MongoDB-Authentisierung, Herkunft der Containerdefinitionen und ein praktischer Wiederherstellungstest bleiben offen. Vorläufige Beobachtungen sind ausdrücklich als solche gekennzeichnet.

== Serverbasis ==
{| class="wikitable"
! Merkmal !! Geprüfter Stand
|-
| Hosting || IONOS-Server mit Plesk
|-
| Betriebssystem || Ubuntu 24.04.4 LTS, x86_64
|-
| Plesk || Plesk Obsidian 18.0.79.5
|-
| Container-Laufzeit || Docker 29.7.2
|-
| Arbeitsspeicher || 15,55 GiB für die Container verfügbar
|-
| Massenspeicher || 464 GiB gesamt, rund 22 GiB belegt; zum Prüfzeitpunkt kein Kapazitätsengpass
|-
| Swap || nicht eingerichtet
|-
| Laufzeit des Hosts || rund 94 Tage zum Prüfzeitpunkt
|-
| Docker-Netzwerke || Standardnetzwerke `bridge`, `host` und `none`; keine benannten projektspezifischen Netzwerke
|-
| Docker-Volumes || Keine benannten Volumes; persistente Daten werden voraussichtlich über Bind-Mounts bereitgestellt und müssen noch geprüft werden
|}

Die öffentliche IP-Adresse, Zugangsdaten und weiteren sicherheitsrelevanten Verbindungsdaten werden nicht auf dieser Seite veröffentlicht. Sie liegen in der geschützten System- beziehungsweise Passwortdokumentation.

== Berechtigungsmodell für Administration ==
Für automatisierte Prüfung und unterstützte Administration existiert der eigene Serverbenutzer `clawtronics` mit separatem ED25519-Schlüssel.

Der Benutzer:

* besitzt keine Mitgliedschaft in der Gruppe `docker`,
* besitzt keinen pauschalen Root- oder sudo-Zugang,
* darf nur ausdrücklich freigegebene, root-eigene Hilfsskripte ohne Passwort ausführen,
* kann die freigegebenen Skripte selbst nicht verändern,
* erhält neue Rechte stufenweise und nur für einen dokumentierten Betriebszweck.

Der aktuelle Read-only-Befehl `/usr/local/sbin/megbes-discovery` liefert ausschließlich Plesk-Version, Container, Images, Docker-Netzwerke, Docker-Volumes und eine momentane Ressourcenübersicht. Containeränderungen, `docker exec`, Datenbankzugriffe und Dateisystemänderungen sind nicht freigegeben.

Die Gruppe `docker` wird nicht vergeben, da deren Mitgliedschaft praktisch Root-Rechte ermöglicht. Erweiterungen werden als eng begrenzte, root-eigene Hilfsskripte umgesetzt.

== Aktueller Containerbestand ==
Zum Prüfzeitpunkt liefen 13 Container ohne sichtbare Neustartschleife.

{| class="wikitable"
! Container !! Image beziehungsweise Release !! Hostbindung !! Aufgabe
|-
| `megbes-status` || `tinetronics/megbes-status:AUGUST-2026-2-RELEASE` || alle IPv4-Schnittstellen, Port 9990 || zentraler [[Status-Monitor]]
|-
| `megbes-external-tine` || `MARCH-2026-1-RELEASE` || alle IPv4-Schnittstellen, Port 32770 || Kundenprojekt Tine
|-
| `megbes-external-limes` || `MARCH-2026-1-RELEASE` || alle IPv4-Schnittstellen, Port 32780 || Kundenprojekt Limes
|-
| `megbes-external-gkp` || `MARCH-2026-1-RELEASE` || alle IPv4-Schnittstellen, Port 32769 || Kundenprojekt GKP
|-
| `megbes-external-bayam` || `MARCH-2026-1-RELEASE` || nur localhost, Port 32768 || Kundenprojekt BayAM
|-
| `megbes-external-miqua` || `MARCH-2026-1-RELEASE` || alle IPv4-Schnittstellen, Port 32779 || Kundenprojekt MiQua
|-
| `megbes-external-messe` || `MARCH-2026-1-RELEASE` || alle IPv4- und IPv6-Schnittstellen, Port 32771 || Kundenprojekt Messe
|-
| `megbes-external-hon` || `MARCH-2026-1-RELEASE` || nur localhost, Port 9997 || Kundenprojekt HoN
|-
| `mediawiki` || `mediawiki:latest` || nur localhost, Port 49155 || internes MegBes-Wiki
|-
| `mongodb` || `mongo:7.0.12` || alle IPv4-Schnittstellen, Port 49154 || zentrale MongoDB
|-
| `megbes-external-nowalux` || `MARCH-2026-1-RELEASE` || alle IPv4-Schnittstellen, Port 34615 || Kundenprojekt NowaLux
|-
| `megbes-external-miquaguide` || `MARCH-2026-1-RELEASE` || alle IPv4- und IPv6-Schnittstellen, Port 32774 || Kundenprojekt MiQua Guide
|-
| `megbes-external-gse` || `MARCH-2026-1-RELEASE` || alle IPv4-Schnittstellen, Port 32805 || Kundenprojekt GSE
|}

Die Hostbindung zeigt, an welchen Schnittstellen Docker lauscht. Sie beweist allein noch keine Erreichbarkeit aus dem Internet; dafür müssen zusätzlich Plesk-, Firewall- und Providerregeln geprüft werden.

== Containerbetrieb und Mounts ==
Alle Container verwenden die Restart-Policy `unless-stopped`. Kein Container besitzt einen Docker-Healthcheck. Die angezeigten Speicherlimits entsprechen jeweils dem gesamten Hostspeicher; damit sind keine individuellen Container-Speichergrenzen erkennbar.

Die persistenten beziehungsweise extern bereitgestellten Daten werden über beschreibbare Bind-Mounts eingebunden:

{| class="wikitable"
! Bereich !! Hostpfad !! Containerpfad !! Bemerkung
|-
| allgemeine Schlüsselablage || `/home/ssl` || `/opt/app/key` || bei Status-Monitor und mehreren External-Containern eingebunden
|-
| allgemeine Zertifikate || `/home/certs` || `/opt/app/certs` || beim Status-Monitor eingebunden
|-
| projektspezifische Zertifikate || `/home/certs/<projekt>` || `/opt/app/certs` || bei Tine, Limes, BayAM, MiQua, Messe, HoN, MiQua Guide und GSE
|-
| MediaWiki-Daten || `/home/megbeswiki` || `/var/www/data` || enthält die persistente Wiki-Konfiguration und -Daten
|-
| MongoDB-Daten || `/root/mdb/data` || `/data/db` || produktive Datenablage
|-
| MongoDB-Konfiguration || `/root/mdb/config` || `/data/configdb` || Konfigurationsdatenbank
|}

Alle ermittelten Mounts sind mit Schreibrecht eingebunden. Für reine Zertifikats- und Schlüsselablagen ist später zu prüfen, ob ein Read-only-Mount genügt. Eine solche Änderung darf erst nach Prüfung der Anwendung und mit Rückkehrweg erfolgen.

== Netzwerk und externe Erreichbarkeit ==
UFW ist auf dem Host inaktiv. `nftables` enthält von Docker erzeugte NAT- und Filterregeln sowie Fail2ban-Regeln. Zusätzlich muss eine vorgelagerte Provider- oder Plesk-Firewall wirken, da nicht alle lokal gebundenen Ports von außen erreichbar waren.

Ein externer TCP-Verbindungstest am 7. August 2026 ergab:

{| class="wikitable"
! Port beziehungsweise Gruppe !! Ergebnis
|-
| 22, 80 und 443 || öffentlich erreichbar; erwartete SSH- und Webdienste
|-
| 9990 || öffentlich direkt erreichbar; Status-Monitor zusätzlich zum Domainzugriff exponiert
|-
| 9997 und 32768 || nicht öffentlich erreichbar und lokal an `127.0.0.1` gebunden
|-
| 32769, 32770, 32771, 32774, 32779, 32780, 32805 und 34615 || trotz Bindung an alle Schnittstellen beim Test nicht öffentlich erreichbar
|-
| 49154 || MongoDB trotz Bindung an alle IPv4-Schnittstellen beim Test nicht öffentlich erreichbar
|-
| 49155 || MediaWiki nicht öffentlich direkt erreichbar und lokal an `127.0.0.1` gebunden
|}

Die externe Nichterreichbarkeit ist eine Momentaufnahme und ersetzt keine bewusst dokumentierte Firewallregel. Empfohlen ist, Reverse-Proxy-Ziele grundsätzlich an `127.0.0.1` zu binden, sofern kein direkter Zugriff erforderlich ist. Besonders Port 9990 und die MongoDB-Bindung sind vor einer Änderung zunächst gegen den betrieblichen Zweck und die Plesk-Konfiguration zu prüfen.

== Plesk-Domains und Reverse Proxy ==
Plesk verwaltet die Domains beziehungsweise Subdomains `bayam`, `gkp`, `hon`, `limes`, `megbes.de`, `messe`, `miqua`, `miquaguide`, `nowalux`, `status`, `tine`, `vserver` und `wiki` unter `megbes.de`.

Die nginx-Konfigurationen leiten die projektbezogenen Domains auf die jeweiligen Docker-Hostports weiter. Die Ziele sind derzeit überwiegend als `0.0.0.0:<port>` eingetragen. Funktional ist das möglich; als klareres internes Proxyziel sollte bei einer späteren Bereinigung `127.0.0.1:<port>` zusammen mit einer lokalen Containerbindung geprüft werden. Generierte Plesk-Konfigurationen dürfen nicht direkt und dauerhaft bearbeitet werden; Änderungen erfolgen über die zuständige Plesk-Einstellung beziehungsweise zusätzliche Konfiguration.

== Sicherungsstand ==
Im Plesk-Sicherungsverzeichnis liegen tägliche inkrementelle Sicherungen mit erfolgreichen Statusmarkern bis einschließlich 7. August 2026. Erfasst sind Plesk-Systembestandteile sowie die Domains `gkp.megbes.de`, `hon.megbes.de`, `megbes.de`, `nowalux.megbes.de`, `status.megbes.de`, `vserver.megbes.de` und `wiki.megbes.de`.

Aus der Dateiliste lässt sich noch nicht ableiten, dass `/root/mdb/data`, `/root/mdb/config`, `/home/certs`, `/home/ssl` und alle Containerdefinitionen vollständig und konsistent gesichert werden. Insbesondere die MongoDB benötigt ein anwendungsgeeignetes Backupverfahren; eine reine Dateikopie im laufenden Betrieb ist nicht automatisch konsistent. Ablageziel, Aufbewahrungsdauer und ein praktischer Wiederherstellungstest bleiben zu dokumentieren.

== Erste Betriebsbeobachtungen ==
* Alle 13 Container liefen zum Prüfzeitpunkt seit rund sechs Stunden.
* Die momentane CPU- und Speicherauslastung war unauffällig.
* Der Status-Monitor nutzt den derzeit bekannten aktuellen Release `AUGUST-2026-2-RELEASE`.
* Die zehn Kundencontainer von `megbes-external` verwenden `MARCH-2026-1-RELEASE`, obwohl das Image `AUGUST-2026-1-RELEASE` lokal vorhanden ist. Daraus folgt kein automatischer Updateauftrag; Freigabe, Kompatibilität und Rückkehrweg sind projektweise zu prüfen.
* MediaWiki sowie BayAM und HoN sind nur an localhost gebunden.
* Die Bindung von MongoDB an alle IPv4-Schnittstellen ist sicherheitsrelevant. Der Port war extern nicht erreichbar; Authentisierung, vorgelagerte Filterregel und tatsächlicher Verwendungszweck bleiben dennoch zu prüfen.
* Mehrere MegBes-Ports sind an alle Schnittstellen gebunden, waren beim externen Test mit Ausnahme von Port 9990 jedoch nicht erreichbar. Ob die Bindungen erforderlich sind oder Plesk als lokaler Reverse Proxy genügt, wird projektweise geprüft.

== Inventurplan ==
Die folgenden Punkte werden ausschließlich lesend aufgenommen, bevor Betriebsänderungen erfolgen:

# Eigentümer, Rechte und Sicherungsumfang der ermittelten Datenpfade
# Herkunft und reproduzierbare Definition der Container
# Zertifikatszuordnungen und Erneuerungsverfahren
# MongoDB-Authentisierung und Netzwerkbindung, ohne Geheimwerte auszugeben
# konsistentes Backup der MongoDB- und MediaWiki-Daten
# Aufbewahrungsdauer und praktischer Wiederherstellungstest
# Logwachstum und Logrotation der Container
# standardisierter Ablauf für Update, Rollback und neuen Kundencontainer

== Regeln für Änderungen ==
* Vor jeder Änderung werden betroffene Container, Konfiguration, Mounts, Ports und aktueller Image-Stand gesichert beziehungsweise dokumentiert.
* Geheimwerte werden weder in Befehlsausgaben noch im Wiki gespeichert.
* Ein Container wird nur mit bekanntem Rückkehrweg ersetzt.
* Datenbank- und Volume-Änderungen erfolgen erst nach geprüfter Sicherung.
* Neustarts, Updates und neue Kundencontainer benötigen einen ausdrücklichen Auftrag.
* Nach Änderungen werden Anwendung, Logs, Status-Monitor und mindestens ein kontrollierter Projektablauf geprüft.

Siehe auch [[Megbes-external unter Plesk]] und [[Wartung, Backups und Fehlerdiagnose]].

[[Kategorie:MegBes]]
[[Kategorie:Betrieb]]
[[Kategorie:Plesk]]
[[Kategorie:Wartung]]
[[Kategorie:Sicherheit]]

Megbes-external unter Plesk

2026-08-07T12:45:02Z

Clawtronics: Zentrale Serverinventur verknüpft

= Megbes-external unter Plesk =

== Zweck ==

`megbes-external` bildet die öffentlich erreichbare Ebene von MegBes. Auf dem zentralen IONOS-Server wird für jedes Kundenprojekt ein eigener Docker-Container über Plesk betrieben. Die Trennung verhindert, dass projektspezifische Domains, Ports, Konfigurationen und Releases unkontrolliert vermischt werden.

== Voraussetzungen ==

* Projekt ist nach [[Neukunde]] angelegt.
* Passende Konfiguration liegt im privaten Repository `tinetronics/megbes-config` vor.
* Freier externer Port und vorgesehene Domain beziehungsweise Subdomain sind festgelegt.
* Das freigegebene MegBes-Release ist bekannt.
* Adresse und Erreichbarkeit von `megbes-internal` sind geklärt.
* Benötigte Zertifikate sind vorhanden; siehe [[Zertifikate]].

== Grundaufbau je Projekt ==

Für jedes Projekt werden getrennt dokumentiert:

{| class="wikitable"
! Angabe
! Dokumentationsort
|-
| Projekt- und Containername || Projektseite
|-
| Domain oder Subdomain || Projektseite
|-
| externe Portzuordnung || Projektseite
|-
| verwendete Konfigurationsdatei || Projektseite, ohne Geheimwerte
|-
| installierter Release || Projektseite
|-
| Betriebsart und Authentifizierungsvariante || Projektseite
|-
| Adresse des internen Servers || Projektseite
|}

== Ablauf in Plesk ==

# Vorhandene Container prüfen und einen eindeutigen Projektnamen wählen.
# Den für das Projekt freigegebenen Image- beziehungsweise Release-Stand auswählen.
# Projektspezifische Umgebungsvariablen und benötigte Dateimounts eintragen.
# Portzuordnung so wählen, dass sie nicht mit einem bestehenden Container kollidiert.
# Domain oder Subdomain auf den vorgesehenen Container beziehungsweise Port routen.
# Falls erforderlich, Zertifikatsdateien ausschließlich aus der geschützten Ablage einbinden.
# Container starten und Startprotokoll auf Konfigurations-, Port- und Zertifikatsfehler prüfen.
# Erreichbarkeit der öffentlichen Anwendung testen.
# Einen kontrollierten Aufruf bis `megbes-internal` durchführen; siehe [[Routing und Signalweg]].
# Alle nicht geheimen Istwerte auf der Projektseite dokumentieren.

== Erfolgskriterien ==

* Der Container läuft ohne Neustartschleife.
* Die projektbezogene Domain liefert die vorgesehene Anwendung.
* Das Log enthält keine ungelösten Konfigurations- oder Zertifikatsfehler.
* `megbes-external` erreicht den korrekten internen Server.
* Ein Testbefehl erreicht ausschließlich das vorgesehene Projekt.

== Sichere Änderungen und Updates ==

Vor einer Änderung sind Containername, Portbelegung, eingebundene Dateien, Konfiguration und aktueller Release zu erfassen. Updates werden zunächst gegen die projektspezifische Konfiguration geprüft. Ein bestehender Container darf erst ersetzt werden, wenn Rückkehrweg und bisheriger Release bekannt sind.

== Typische Fehler ==

{| class="wikitable"
! Fehlerbild
! Prüfung
|-
| Container startet wiederholt neu || Startlog, Konfigurationsdatei, Mounts und Umgebungsvariablen prüfen.
|-
| Domain ist nicht erreichbar || DNS, Plesk-Routing, Portzuordnung und Containerstatus prüfen.
|-
| Anwendung ist erreichbar, interner Server nicht || Zieladresse, DynDNS, Routerfreigabe und Zertifikate prüfen.
|-
| Falsches Projekt reagiert || Domain-, Port- und Containerzuordnung sofort prüfen; keinen weiteren Funktionstest senden.
|-
| Zertifikatsfehler || Dateipfad, Gültigkeit und Zuordnung nach [[Zertifikate]] prüfen.
|}

== Sicherheitsregeln ==

Passwörter, Tokens, private Schlüssel, geheime Headerwerte und vollständige Zugangsdaten dürfen weder auf der Wiki-Seite noch in Befehlsbeispielen stehen. Das Wiki dokumentiert Bezeichnungen, Ablageorte und Zuständigkeiten, nicht die Geheimwerte selbst.

== Zentraler Server ==
Der geprüfte Istzustand und das Berechtigungsmodell sind unter [[Zentraler MegBes-Server – Inventur und Administration]] dokumentiert.

[[Kategorie:MegBes]]
[[Kategorie:Betrieb]]
[[Kategorie:Plesk]]

Wartung, Backups und Fehlerdiagnose

2026-08-07T12:45:02Z

Clawtronics: Zentrale Serverinventur verknüpft

= Wartung, Backups und Fehlerdiagnose =

== Zweck ==

Regelmäßige Wartung hält zentrale und lokale MegBes-Komponenten sicher, nachvollziehbar und wiederherstellbar. Änderungen erfolgen projektweise und mit dokumentiertem Rückkehrweg.

== Status-Monitor ==

Der zentrale [[Status-Monitor]] unter [https://status.megbes.de status.megbes.de] zeigt die Health-Zustände der konfigurierten External- und Internal-Instanzen. Ein grüner Status bestätigt die Erreichbarkeit des jeweiligen Management-Endpunkts, aber nicht automatisch den vollständigen Signalweg bis zur Medienstation.

== Regelmäßige Kontrollen ==

{| class="wikitable"
! Bereich
! Prüfung
|-
| Container || Laufzustand, Neustarts und aktuelle Fehler im Log
|-
| Betriebssystem || verfügbare Sicherheitsaktualisierungen und freier Speicherplatz
|-
| Netzwerk || Erreichbarkeit, DynDNS-Auflösung und Routerweiterleitung
|-
| Zertifikate || Gültigkeitsende und korrekte Projektzuordnung
|-
| MegBes-Release || installierter Stand gegenüber freigegebenem Stand
|-
| Medienstationen || Erreichbarkeit, Rückmeldungen und automatischer Wiederanlauf
|-
| Dokumentation || Übereinstimmung von Projektseite und tatsächlichem System
|}

== Vor einer Änderung sichern ==

Zu erfassen beziehungsweise zu sichern sind mindestens:

* projektspezifische Konfiguration ohne ungeschützte Weitergabe von Geheimwerten
* Containerdefinition, Portzuordnungen und Dateimounts
* aktuell eingesetzter MegBes-Release
* Zertifikats- und Keystore-Dateien in geschützter Ablage
* kundenspezifische Skripte und Stationssoftware
* für Raspberry-Pi-Stationen gegebenenfalls ein geprüftes SD-Karten-Abbild
* Datum, Anlass und verantwortliche Person der Sicherung

Eine Sicherung gilt erst als belastbar, wenn Ablageort, Lesbarkeit und vorgesehener Wiederherstellungsweg geprüft wurden.

== Sicherer Wartungsablauf ==

# Istzustand und konkrete Störung beziehungsweise Wartungsaufgabe dokumentieren.
# Projektbezogene Konfiguration und Release feststellen.
# Rückkehrweg und benötigte Sicherungen vorbereiten.
# Änderung nur an einer klar abgegrenzten Stufe durchführen.
# Logs und unmittelbare Erfolgskriterien prüfen.
# Gesamten Signalweg mit einem kontrollierten Test durchlaufen.
# Stationszustände und Wiederanlauf prüfen.
# Ergebnis und neuen Istzustand auf der Projektseite dokumentieren.

== Fehlerdiagnose nach Ebenen ==

# Bedienoberfläche und Authentifizierung
# `megbes-external` und dessen Containerlog
# DNS, DynDNS und öffentliches Routing
# Router, Portweiterleitung und lokale Firewall
# `megbes-internal` und dessen Anwendungslog
# UDP-Weg im Ausstellungsnetz
# Medienstation, Empfängersoftware und konkrete Befehle

Details: [[Routing und Signalweg]].

== Sichere Abbruchpunkte ==

Die Arbeit wird abgebrochen und der letzte bekannte Zustand wiederhergestellt, wenn die Projektzuordnung unklar ist, eine Änderung mehrere Kundencontainer unerwartet betrifft, Geheimwerte fehlen oder nicht eindeutig zugeordnet sind, keine belastbare Sicherung existiert oder sich der bisherige Release nicht bestimmen lässt.

== Nachkontrolle ==

* öffentliche Anwendung erreichbar
* interner Server erreichbar
* mindestens ein repräsentativer Steuerbefehl erfolgreich
* Rückmeldung einer stationsgesteuerten Station erfolgreich
* keine neue Fehlerserie in den Logs
* Dokumentation und tatsächlicher Zustand stimmen überein

== Zentraler Server ==
Der geprüfte Istzustand und das Berechtigungsmodell sind unter [[Zentraler MegBes-Server – Inventur und Administration]] dokumentiert.

[[Kategorie:MegBes]]
[[Kategorie:Wartung]]
[[Kategorie:Fehlerdiagnose]]
[[Kategorie:Betrieb]]

Zentraler MegBes-Server – Inventur und Administration

2026-08-07T12:45:01Z

Clawtronics: Geprüften Ausgangsstand, Berechtigungsmodell und Inventurplan dokumentiert

Client-Feedback und Stationsmeldungen

2026-08-06T19:43:44Z

Clawtronics: Tabellenzeilen korrekt trennen

= Client-Feedback und Stationsmeldungen =

== Zweck ==

Medienstationen können ihren Start und – bei stationsgesteuerten Projekten – ihren aktuellen Nutzungszustand per UDP an `megbes-internal` melden. Diese Rückmeldungen ermöglichen Betriebsinformationen und verhindern, dass zwei Bedienwege dieselbe Station gleichzeitig übernehmen.

== Voraussetzungen ==

* Die Medienstation erreicht den lokalen Server im Ausstellungsnetz.
* Zieladresse und UDP-Port entsprechen der Projektkonfiguration.
* Bei Nutzung von Stationszuständen ist der stationsgesteuerte Modus auf interner und externer Ebene aktiviert.
* Die Stationsnummer stimmt mit der Projektkonfiguration überein.

== Init-Meldung ==

Eine Nachricht, die mit `init` beginnt, wird als Start- oder Informationsmeldung verarbeitet. Der nachfolgende Text kann Geräte- oder Startinformationen enthalten. Abhängig von der Projektkonfiguration kann daraus eine Informationsmail erzeugt werden.

Die Init-Meldung bestätigt, dass der UDP-Sender der Station den lokalen Server grundsätzlich erreicht. Sie bestätigt noch nicht, dass Steuerbefehle in Gegenrichtung bei der Station ankommen.

== Zustandsmeldungen ==

Bei stationsgesteuerten Projekten erwartet der aktuelle Code Meldungen nach dem Muster:

<code><Schlüsselwort>: <Stationsnummer></code>

{| class="wikitable"
! Beispiel
! Wirkung
|-
| <code>idle: 1021</code> || Die Station wird als frei markiert.
|-
| <code>touchscreen: 1021</code> || Die Station wird als lokal über den Touchscreen benutzt markiert.
|-
| <code>open: 1021</code> || Die Station wird unabhängig von der üblichen Belegungsprüfung als offen markiert.
|}

Der Zustand `REMOTE` wird von der Anwendung bei erfolgreicher Übernahme durch einen entfernten Benutzer gesetzt. Er ist in der aktuellen Empfangslogik keine gleichartige UDP-Rückmeldung der Station.

== Lebenszyklus einer stationsgesteuerten Nutzung ==

# Die Station meldet `idle` und ist damit verfügbar.
# Ein entfernter Benutzer fordert die Station an.
# `megbes-internal` prüft den Zustand und ordnet die Station bei erfolgreicher Übernahme dem Benutzer zu.
# Steuerbefehle dieses Benutzers aktualisieren den letzten Nutzungszeitpunkt.
# Nach Ende der lokalen Wiedergabe meldet die Station wieder `idle`.
# Bleibt eine Rückmeldung aus, greift nach dem projektspezifisch konfigurierten Zeitraum die Fallback-Logik gegen dauerhaft blockierte Stationen.

== Funktionsprüfung ==

# Die Station beziehungsweise den UDP-Sender starten.
# Im Log von `megbes-internal` prüfen, ob die Init-Meldung empfangen wird.
# Eine Zustandsmeldung mit der korrekten Stationsnummer auslösen.
# Den Stationsstatus über den vorgesehenen Bedienweg abfragen.
# Eine Fernübernahme testen und anschließend sicherstellen, dass die Station wieder `idle` meldet.

== Typische Fehler ==

{| class="wikitable"
! Fehlerbild
! Prüfung
|-
| Keine Init-Meldung im Log || Ziel-IP, UDP-Port, lokale Firewall und Netzwerkverbindung prüfen.
|-
| Meldung kommt an, Status ändert sich nicht || Schlüsselwort, Doppelpunkt, Leerzeichen und Stationsnummer mit dem erwarteten Format vergleichen.
|-
| Falsche Station ändert ihren Zustand || Stationsnummer in Stationssoftware und Projektkonfiguration prüfen.
|-
| Station bleibt belegt || Prüfen, ob nach Wiedergabeende tatsächlich `idle` gesendet wird; danach den projektspezifischen Timer prüfen.
|-
| Lokale Nutzung wird nicht erkannt || Prüfen, ob beim Start der lokalen Touchscreen-Nutzung `touchscreen` gesendet wird.
|}

== Sicherheit und Dokumentation ==

Empfängeradressen, Ports und Stationsnummern sind projektspezifisch und werden auf der Projektseite dokumentiert. Geheimwerte gehören nicht in Beispielskripte oder Wiki-Seiten. Änderungen am Nachrichtenformat müssen mit der eingesetzten Stationssoftware und dem installierten MegBes-Release abgestimmt werden.

Siehe auch [[UDP und Stationszustände]] und [[Routing und Signalweg]].

[[Kategorie:MegBes]]
[[Kategorie:Schnittstellen]]
[[Kategorie:Fehlerdiagnose]]

Routing und Signalweg

2026-08-06T19:43:44Z

Clawtronics: Tabellenzeilen korrekt trennen

= Routing und Signalweg =

== Zweck ==

Diese Seite beschreibt den Weg eines Steuerbefehls vom Bediengerät bis zur Medienstation. Sie dient zugleich als Reihenfolge für die Fehlersuche: Jede Stufe muss erreichbar sein und den Befehl korrekt an die nächste Stufe übergeben.

== Signalweg ==

Web-Frontend oder App
↓ HTTPS
megbes-external im projektspezifischen Container
↓ HTTP oder HTTPS über die konfigurierte Adresse
Router beziehungsweise FRITZ!Box am Ausstellungsort
↓ Portweiterleitung
megbes-internal auf dem lokalen Server
↓ UDP im lokalen Ausstellungsnetz
Medienstation oder UDP-zu-GPIO-Umsetzer

=== 1. Web-Frontend oder App ===

Die Bedienoberfläche erzeugt eine Anforderung mit Stationsnummer und einem oder mehreren projektspezifischen Befehlen. Je nach Projekt ist vorher eine Anmeldung, Ticketprüfung oder direkte Berechtigung erforderlich.

=== 2. megbes-external ===

`megbes-external` prüft die projektbezogene Authentifizierung und leitet zulässige Anforderungen an den in der Konfiguration hinterlegten internen Server weiter. Pro Kunde beziehungsweise Projekt läuft ein eigener Container. Die konkrete Domain, Containerbezeichnung und Konfiguration gehören auf die jeweilige Projektseite.

=== 3. Öffentlicher Übergang zum Ausstellungsnetz ===

Die Zieladresse des internen Servers wird projektspezifisch konfiguriert. Bei wechselnder öffentlicher IP-Adresse kann eine DynDNS-Adresse verwendet werden. Der Router muss den vorgesehenen externen Port an die feste lokale Adresse und den Dienst-Port von `megbes-internal` weiterleiten.

=== 4. megbes-internal ===

`megbes-internal` nimmt die weitergeleitete Anforderung entgegen. Je nach Projekt wird die Verbindung mit Headern oder einem Client-Zertifikat abgesichert. Anschließend zerlegt die Anwendung die Kombinationen aus Stationsnummer und Befehl und übergibt sie an den UDP-Sender.

=== 5. UDP im Ausstellungsnetz ===

Aus der Stationsnummer wird mit dem projektspezifischen lokalen Subnetz die Zieladresse gebildet. Der Befehl wird als UDP-Nutzlast an den konfigurierten Port der Station gesendet. Subnetz und UDP-Port dürfen nicht ungeprüft von einem anderen Projekt übernommen werden.

=== 6. Medienstation ===

Die Medienstation verarbeitet den vereinbarten Befehl. Mögliche Empfänger sind BrightSign-Player, PCs, Raspberry Pis oder andere UDP-fähige Geräte. Bei stationsgesteuerten Projekten sendet die Station zusätzlich Zustandsmeldungen zurück; siehe [[Client-Feedback und Stationsmeldungen]].

== Fehlersuche entlang des Signalwegs ==

# Prüfen, ob das Web-Frontend geladen wird und die Anforderung tatsächlich absendet.
# Im Log von `megbes-external` prüfen, ob die Anforderung angenommen oder wegen Authentifizierung beziehungsweise Stationsbelegung abgelehnt wurde.
# Prüfen, ob die konfigurierte Adresse des internen Servers aufgelöst wird und von außen erreichbar ist.
# DynDNS-Eintrag, öffentliche IP-Adresse und Portweiterleitung am Router vergleichen.
# Im Log von `megbes-internal` prüfen, ob der Aufruf ankommt und ein UDP-Signal erzeugt wird.
# Lokale IP-Adresse, Subnetz, Zielstation und UDP-Port prüfen.
# Auf der Medienstation kontrollieren, ob der UDP-Empfänger läuft und der konkrete Befehl unterstützt wird.

== Typische Fehlerbilder ==

{| class="wikitable"
! Beobachtung
! Wahrscheinlicher Bereich
! Nächster sicherer Prüfschritt
|-
| Web-Frontend ist nicht erreichbar || Domain, Container oder `megbes-external` || Containerstatus und externes Anwendungslog prüfen.
|-
| Anmeldung funktioniert, Steuerung jedoch nicht || Verbindung zwischen externer und interner Ebene || Zieladresse, DNS-Auflösung und Log von `megbes-external` prüfen.
|-
| Interner Server ist von außen nicht erreichbar || DynDNS, Router oder Portweiterleitung || Öffentliche IP-Adresse und Routerregel abgleichen.
|-
| Aufruf erreicht `megbes-internal`, Station reagiert nicht || lokales Netz, UDP-Ziel oder Stationssoftware || Stations-IP und UDP-Port prüfen; anschließend Empfang auf der Station testen.
|-
| Einzelne Befehle funktionieren nicht || projektspezifisches Befehlsformat || Befehl mit der Projektkonfiguration und der Stationssoftware vergleichen.
|-
| Station bleibt als belegt angezeigt || fehlende oder falsche Zustandsmeldung || Rückkanal nach [[Client-Feedback und Stationsmeldungen]] prüfen.
|}

== Dokumentation je Projekt ==

Auf der Projektseite sind mindestens die verwendete externe Domain, die Art der Erreichbarkeit des internen Servers, die Portzuordnung, das lokale Subnetz, der UDP-Port, die Betriebsart und der installierte Release zu dokumentieren. Passwörter, Tokens, private Schlüssel und geheime Headerwerte gehören nicht ins Wiki.

Siehe auch [[DynDNS und Router]].

[[Kategorie:MegBes]]
[[Kategorie:Architektur]]
[[Kategorie:Netzwerk]]