Hallo zusammen,
in diesem Thema der "DECT Amnesie" haben wir wohl endlich die Fälle gefunden, wann genau die DECT Zell Ihre config verliert.
Im Kern ist das Thema auf drei Punkte zurückzuführen, wo es dann im Zusammenspiel leider schiefgeht:
1) Das genau Timing des Technikers in Bezug auf die Reihenfolge wann er was konfiguriert
1.1) Genauer gesagt: Zeitpunkt des Aktivierens der PBX LDAP Replikation
2) Die Architektur unseres LDAP Syncs
2.1) Genauer gesagt: Master überschreibt immer in Richtung Slave
3) Das Verhalten einer DECT Zelle bei LDAP Replikation
3.1) Genauer gesagt: Wenn vom LDAP-Master ein neues DECT Objekt (also die Master config) selbst kommt, wird die erhaltene config beim nächsten Reboot aktiv
Das grundlegende Thema ist die chronologische Reihenfolge des Setups und dem LDAP Sync:
1) Wird die DECT Config (auf dem Master) VOR aktivieren des LDAP Syncs gemacht endet das in "vergessener Config" nach dem nächsten Reboot
1.1) Sobald der LDAP Sync aktiviert wird, wird vom Master an den Slave überschrieben. Dadurch geht die lokale DECT config verloren.
1.2) Für die aktuelle running config des DECT Masters hat es noch keinen impact, da die config des replizierten (leeren) DECT Objektes erst nach dem nächsten Reboot aktiv wird
1.3) Bei einem Reboot in 30 Tagen - ist es in 30 tagen kaputt, obwohl keine Configänderungen mehr stattgefunden haben
2) Wird die DECT Config (auf dem Master) NACH aktivieren des LDAP Syncs gemacht aber die PBX ist während des SETUP nicht erreichbar endet das in "vergessener Config" nach dem nächsten Reboot
2.1) siehe oben
3) Richtet man einen zusätzlichen DECT Master/Slave ein kann man die config aus versehen leeren
3.1) Wenn man als erstes den LDAP Sync einrichtet und NICHT neu bootet, hat man die Configs noch nicht in der running config
3.2) Klickt man auf die DECT-GUI und klickt einmal OK, wird ein "leeres" oder "falsches" DECT Objekt zur PBX repliziert
3.3) Das sorgt dann beim nächsten Reboot auf dem anderen DECT Master für selbigen Fehler
Wir haben hier wohl entgegen der ursprünglichen Vermutung gar kein Problem im LDAP selbst, sodass eine korrupte/leere config erzeugt wird. Das was passiert ist genau das erwartete verhalten.
So funktioniert nun genau genommen der LDAP Sync.
Ich denke in diesem Bereich ist es wichtig in erster Linie für Transparenz zu sorgen. So ist es erklärbar, und wenn jeder brav "immer erst den LDAP Sync aktiviert, neu bootet und das konfiguriert" ist die Welt in Ordnung.
Wir prüfen aktuell intern wo genau wir noch Dokumentationen bzw. Schulungsunterlagen anpassen/erweitern müssen.
Ebenso haben wir in der Entwicklung eine Anpassung besprochen, die dieses Problem in einer kommenden Major Version dann auch nachhaltig lösen soll.
Vielen Dank für die fleißige mithilfe und Zusendung von configs/traces.
Mit ein wenig Zeit bekommen wir dieses Problem dann wohl nachhaltig gelöst
Sobald wir hier etwas Finales haben, geben wir bescheid.
Bis dahin bitte immer erst "LDAP, Reboot dann Config" und checken ob die Master online ist
Beste Grüße Basti
