User Tools

Site Tools


univention:rejoining_a_node

Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
univention:rejoining_a_node [2024/05/05 05:29]
217.113.194.56 old revision restored (2023/09/30 12:34)
univention:rejoining_a_node [2024/05/06 15:10] (current)
114.119.138.111 old revision restored (2024/03/12 01:00)
Line 2: Line 2:
  
 The replication of a replica/slave happens initially during the joining The replication of a replica/slave happens initially during the joining
-https://docs.software-univention.de/manual/5.0/de/domain-ldap/domain-join.html#how-ucs-systems-join-domains+https://docs.software-univention.de/manual/5.0/en/domain-ldap/domain-join.html#how-ucs-systems-join-domains
  
 Afterwards all further changes are sent using the Notifier/Listener mechanism. A previously installed system can rejoin the cluster. During a rejoin all installed components would be reinstalled using the "Join Scripts". Afterwards all further changes are sent using the Notifier/Listener mechanism. A previously installed system can rejoin the cluster. During a rejoin all installed components would be reinstalled using the "Join Scripts".
Line 12: Line 12:
  
  
-Für beimx-000087-016 gibt es noch einige Besonderheiten. Dieses System  
-ist der erste Server mit der OX-Appsuite und wurde prinzipiell wie in  
-https://oxpedia.org/wiki/index.php?title=OXSE4UCS_Installation_en#Active_OX_App_Suite_instance  
-beschrieben installiert. Für die anderen beiden AppSuite-Frontend wurde  
-analog  
-https://oxpedia.org/wiki/index.php?title=OXSE4UCS_Installation_en#Additional_passive_instance_of_OX_App_Suite  
-verfahren. 
  
-Im letzten Link finden sich 2 wichtige Einstellungen: 
  
-ucr set ox/listener/enabled=no 
-ucr set ox/joinscript/skip=yes 
- 
-*Zu ox/listener/enabled*: 
- 
-Aktuell ist -016 der einzige Server, auf dem der OX-Listener aktiviert  
-ist. Dieser Listener sorgt dafür, dass OX betreffende Änderungen im LDAP  
-auch im OX landen. Da wir nicht wollen, dass dieselben Änderungen  
-parallel auf allen AppSuite durchgeführt werden und sich eventuell sogar  
-gegenseitig aufheben, gibt es eben nur ein System auf dem der Listener  
-aktiv ist. Der Listener verwendet die Kommandozeilenwerkzeuge der  
-AppSuite und benötigt dafür passende administrative Zugangsdaten. Die  
-Kennwörter für die jeweiligen Konten werden in /etc/ox-secrets erwartet.  
-Da diese Kennwörter während der Provisionierung (der OX-Contexts)  
-erzeugt wurden, liegen sie aber eben auch nur auf -016 vor. Würde man  
-den OX-Listener auf einem anderen Frontend aktivieren wollen, müsste man  
-die .secret-Dateien zuvor synchronisieren. 
- 
-In den Absprachen zu den Arbeiten wurde vereinbart, dass das MBJS die  
-Provisionierung über weBBschule gegen die Kelvin-API pausiert. Ich  
-denke, dass ist der einfachste Weg, mit dem OX-Listener umzugehen. 
- 
-*Achtung!* Nach meiner Erfahrung wird der Listener bei einem Re-Join so  
-wie alle anderen Listener-Module auch einen kompletten (re)sync machen.  
-Während wir das beim LDAP-Listener wollen, ist das beim OX-Listener  
-unnötig und im Hinblick auf den Zeitbedarf des Re-Join sogar  
-kontaproduktiv. Es würden alle AppSuite-Konten und -Gruppen der Reihe  
-nach durchgesehen umd festzustellen, dass nichts zu tun ist. Das kann  
-gerne 6-12 Stunden sauern. Wenn wirklich keine Änderungen in der Zeit  
-des Beitritts im System staffinden, empfehle ich, vor dem Re-Join auch  
-auf -016 
- 
-ox/listener/enabled=no 
- 
-zu setzen und danach wieder zu aktivieren. 
- 
-Im Kontext der Provisionierung ist auch der Punkt, an dem man noch mal  
-rekapitulieren sollte, was warum gesichert wird, ob das auch wirklich  
-passiert und wie man bei Bedarf an die Sicherung herankommt. Eigentlich  
-erwarte ich keine Notwendigkeit für einen Restore aber eine Kontrolle  
-ist immer sinnvoll. 
- 
-Die Kennwörter in /etc/ox-secrets hatte ich schon genannt. 
- 
-Konfigurationen der OX App Suite liegen in /opt/open-xchange/etc. Das  
-meiste wird über UCR-Variablen definiert, aber ich halte es für  
-sinnvoll, sicherheitshalber vor den Arbeiten noch mal einen Abzug zu  
-machen und den nach Abschluss zu vergleichen. 
- 
-(Das es eine nächtliche Sicherung der gesetzten UCR-Variablen in  
-/var/univention-backup gibt den man auch zum Vergleich nutzen kann  
-möchte ich der Vollständigkeit halber erwähnt haben). 
- 
-Bei der OX-Datenbank die auf einem vom ZIT-BB betriebenen Cluster  
-betrieben wird gehe ich davon aus, das eine Backup- und Restorestrategie  
-gibt. 
- 
-Der OX-Filestore liegt im NFS und wird von den Frontends als  
-/var/oxfilestore gemounted und von -016 gesichert. 
- 
-*Zu ox/joinskript/skip*: 
- 
-*Das ist ein kritischer Aspekt für die gesamte Konfiguration der OX App  
-Suite. *Bei der ersten Installation wird davon ausgegangen, dass eine  
-Datenbank angelegt und dort eine initiale Konfiguration erzeugt werden  
-muß. Weitere Instanzen müssen diese Konfiguration nur noch benutzen.  
-Auch hier haben wir ja schon eine Konfiguration die wir keinesfalls  
-überschreiben wollen und müssen daher *unbedingt vor dem re-join auf  
--016 ox/joinskript/skip=yes* setzen. 
  
 Nachdem die Arbeiten abgeschlossen sind, wäre meine Empfehlung, diese  Nachdem die Arbeiten abgeschlossen sind, wäre meine Empfehlung, diese 
univention/rejoining_a_node.txt · Last modified: 2024/05/06 15:10 by 114.119.138.111