Chucks notes and stuff

You've loaded an old revision of the document! If you save it, you will create a new version with this data.

====== Rejoining a node to the UCS cluster ======

Die Replikation eines Replica/Slave findet initial beim Domänenbeitritt 
(Join) des Systems statt. -> 
https://docs.software-univention.de/manual/5.0/de/domain-ldap/domain-join.html#how-ucs-systems-join-domains

Danach werden weitere Änderungen über den Notifier/Listener-Mechanismus 
übertragen. Ein bestehendes System kann aber auch danach erneut gejoined 
werden. Dabei werden *alle* auf dem System *installierten* *Komponenten* 
über die "Join-Skripte" *neu initialisiert*.

Es ist somit einleuchtend, dass ein produktives System während des 
erneuten Systembeitritts nicht sinnvoll genutzt werden kann und man gut 
beraten ist, dafür zu sorgen, dass jeglicher Zugriff durch die Nutzer 
unterbunden wird. Meine Präferenz wäre, das betroffene System auf einem 
vorgeschalteten Loadbalancer zu deaktivieren. Das hat auch den Vorteil, 
dass man nach Abschluß der Arbeiten gezielte Funktionstests durchführen 
kann. Die von mir in der Vergangenheit genutzte Methode, die auf dem 
Loadbalancer konfigurierten Backendchecks, die bei Nichterreichbarkeit 
eines Dienstes auf die verbleibenden Server verteilen ist nicht ganz so 
günstig. Man muss sich dann darauf einstellen, dass die manuell 
gestoppten Dienste während der Arbeiten dann doch wieder durch 
eingebaute Automatismen gestartet werden und unbeabsichtigt 
Nutzeraktivitäten auf dem System, dessen Zustand man nicht genau kennt, 
stattfinden.

Der Zeitbedarf für den Re-Join liegt bei mehreren Stunden, wie lange 
genau, hängt von mehreren Faktoren ab zu denen nicht nur die Größe der 
LDAP-Datenbank, sondern auch aktuelle Softwareeinstellungen sowie die 
Leistungsfähigkeit des Systems bzw. eben auch die der 
Virtualisierungsplattform gehören. Bei den letzten Re-Joins haben wir 
etwa 3 Stunden gebraucht, auf meinem Testsystem, welches zwar nur 10000 
Nutzer hat, sich aber wesentlich mehr Ressourcen mit anderen VMs teilen 
muss, waren es gestern 4,5 Stunden.

Sicherheitshalber möchte ich an dieser Stelle darauf hinweisen, dass man 
einen Prozess mit dieser Laufzeit über ssh (univention-join) nur 
startet, wenn man z.B. mit "screen" dafür sorgt, dass ein 
Verbindungsabbruch keine Auswirkungen hat. "univention-join" wird 
während der Arbeit über Minuten oder vielleicht Stunden keine weiteren 
Ausgaben zeigen. Ich nehme dann immer weitere screen-Konsolen und lasse 
/var/log/univention/join.log mitlaufen und schaue z.B. mit "pstree" 
(watch "pstree | tail -20"), was konkret passiert.

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 
Änderung wieder rückgängig zu machen. Ansonsten könnte es bei einem 
Update der UCS OX AppSuite (oxse4ucs) dazu führen, dass eine evtl. dort 
gelieferte neue Version des Joinskripts nicht wie dann gewollt 
ausgeführt wird und dann andere Dinge nicht funktionieren.

Edit summary

Note: By editing this page you agree to license your content under the following license: CC Attribution-Noncommercial-Share Alike 4.0 International