Univention Bugzilla – Bug 27625
Tool um eine DN neu zu replizieren
Last modified: 2012-12-12 21:07:46 CET
Der Notifier sollte ein Tool mitbringen, welches eine bestimmte DN oder einen ganzen Teilbaum in die transaction-Datei schreibt. Ablauf könnte so sein: - Notifier beenden - letzte ID aus der transaction auslesen - neue DNs in die transaction mit hochgezählter ID eintragen - Notifier starten
UCS 3.1 will be the next release.
univention-replicate-one wurde hinzugefügt, allerdings unterstützt es nur eine DN. Um das komplette LDAP neu zu replizieren, könnte beispielsweise folgendes gemacht werden: invoke-rc.d univention-directory-notifier stop univention-ldapsearch | sed -ne 's|^dn: ||p' | while read line; do univention-replicate-one --dn "$line" done invoke-rc.d univention-directory-notifier start Das Tool würde auch eigenständig den Notifier beenden, allerdings würde das dann jedes Mal gemacht.
Es sollte die listener/listener Datei berücksichtigt werden und das parallele Ändern von Objekten.
Der slapd wird jetzt auch noch beendet. Dadurch ändert sich das Skript für die Replikation aller DNs wie folgt: univention-ldapsearch | sed -ne 's|^dn: ||p' >ldap.dn invoke-rc.d slapd stop invoke-rc.d univention-directory-notifier stop cat ldap.dn | while read dn; do univention-replicate-one --dn "$dn" done invoke-rc.d slapd start invoke-rc.d univention-directory-notifier start Die Änderungen werden nicht mehr direkt in die transaction, sondern in die Datei listener geschrieben.
RFA: IMHO sollte erwähnt werden, daß es sich um ein "PUSH" handelt, um den Replikationsmechanismus zum Füllen von downstream-LDAP-Servern zu nutzen, und nicht um ein "PULL", um Daten aus einem upstream-LDAP-Server in ein lokales LDAP zu ziehen. FYI: invoke-rc.d ist vorwiegend für die Verwendung aus Debian {pre,post}{inst,rm}-Skripten heraus gedacht und dient dafür, bei der Installation und bei Upgrades in chroot-Umgebungen dem Administrator eine Möglichkeit zu geben, das Starten, Stoppen und Neustarten von Diensten zu unterbinden. Dazu muß der Admin eine policy-rc.d-Datei erstellen. Da univention-replicate-one hier aber unabhängig von irgendwelchesn Policies sicherstellen will, daß slapd und Notifier nicht mehr laufen, sollte es entweder --force benutzen oder die Skripte (zumindest zum Stoppeln) direkt aufrufen. Das ist im Skript nicht kritisch, weil danach nochmals per pidof überprüft wird, daß die Prozesse nicht mehr laufen. FAIL: Fehlermeldungen sollten nach STDERR geschrieben werden: usage >&2 echo "Abort: ..." >&2 ... QTA: Warum wird WARNING groß geschieben, aber "Abort" und "failed" nicht? FAIL: Die Meldung lautet "transaction file", geschrieben wird aber in die Listener-Datei. QTA: $last_line enthält bereits die letzte Zeile, warum nochmal "tail -n 1 ..."? OK: Code svn35094, svn35095 OK: ChangeLog svn14521→14796 (re-replicate[-d-]) # @Master /etc/init.d/univention-directory-notifier stop tail /var/lib/univention-ldap/notify/transaction /var/lib/univention-ldap/listener/listener # @Backup eval "$(ucr shell ldap/base)" ldapmodify -x -D "cn=update,$ldap_base" -w "$(cut -d\" -f 2 /etc/ldap/rootpw.conf)" <<__LDIF__ dn: cn=Domain Users,cn=groups,$ldap_base changetype: modify add: description description: Das ist ein Test __LDIF__ univention-ldapsearch -xLLLb "cn=Domain Users,cn=groups,$ldap_base" description /usr/share/univention-directory-listener/get_notifier_id.py # @Master eval "$(ucr shell ldap/base)" univention-replicate-one --dn "cn=Domain Users,cn=groups,$ldap_base" /etc/init.d/univention-directory-notifier start # @Backup univention-ldapsearch -xLLLb "cn=Domain Users,cn=groups,$ldap_base" description /usr/share/univention-directory-listener/get_notifier_id.py FAIL: univention-directory-notifier_7.0.5-2.66.201209110749
(In reply to comment #5) > RFA: IMHO sollte erwähnt werden, daß es sich um ein "PUSH" handelt, um den > Replikationsmechanismus zum Füllen von downstream-LDAP-Servern zu nutzen, und > nicht um ein "PULL", um Daten aus einem upstream-LDAP-Server in ein lokales > LDAP zu ziehen. Zumindest in der Hilfe steht, dass es so ist, als wenn das Tool direkt modifiziert wurde. > FYI: invoke-rc.d ist vorwiegend für die Verwendung aus Debian > {pre,post}{inst,rm}-Skripten heraus gedacht und dient dafür, bei der > Installation und bei Upgrades in chroot-Umgebungen dem Administrator eine > Möglichkeit zu geben, das Starten, Stoppen und Neustarten von Diensten zu > unterbinden. Dazu muß der Admin eine policy-rc.d-Datei erstellen. > Da univention-replicate-one hier aber unabhängig von irgendwelchesn Policies > sicherstellen will, daß slapd und Notifier nicht mehr laufen, sollte es > entweder --force benutzen oder die Skripte (zumindest zum Stoppeln) direkt > aufrufen. > Das ist im Skript nicht kritisch, weil danach nochmals per pidof überprüft > wird, daß die Prozesse nicht mehr laufen. Ist umgestellt. > FAIL: Fehlermeldungen sollten nach STDERR geschrieben werden: > usage >&2 > echo "Abort: ..." >&2 > ... Ist angepasst. > QTA: Warum wird WARNING groß geschieben, aber "Abort" und "failed" nicht? Warning ist an Abort angepasst. > FAIL: Die Meldung lautet "transaction file", geschrieben wird aber in die > Listener-Datei. Ist angepasst. > QTA: $last_line enthält bereits die letzte Zeile, warum nochmal "tail -n 1 > ..."? Der Wert wird nochmal aus der Datei gelesen, ich denke das ist OK.
Das Tool univention-directory-replication/univention-directory-replicate-one wurde noch entfernt. Das war nur noch im svn und wurde seit einiger Zeit nicht mehr installiert.
(In reply to comment #7) > Das Tool univention-directory-replication/univention-directory-replicate-one > wurde noch entfernt. Das war nur noch im svn und wurde seit einiger Zeit nicht > mehr installiert. Nochmal Reopen, das Tool wurde in 3.0 doch noch mit ausgeliefert.
(In reply to comment #8) > (In reply to comment #7) > > Das Tool univention-directory-replication/univention-directory-replicate-one > > wurde noch entfernt. Das war nur noch im svn und wurde seit einiger Zeit nicht > > mehr installiert. > > Nochmal Reopen, das Tool wurde in 3.0 doch noch mit ausgeliefert. Das Tool wurde jetzt endgültig entfernt, da es nicht funktionierte und IMHO auch teilweise am Listener / Notifier Mechanismus vorbei gearbeitet hat. dev r35646 + r35647 changelog r14800
(In reply to comment #6) > (In reply to comment #5) > > RFA: IMHO sollte erwähnt werden, daß es sich um ein "PUSH" handelt, um den > > Replikationsmechanismus zum Füllen von downstream-LDAP-Servern zu nutzen, und > > nicht um ein "PULL", um Daten aus einem upstream-LDAP-Server in ein lokales > > LDAP zu ziehen. > > Zumindest in der Hilfe steht, dass es so ist, als wenn das Tool direkt > modifiziert wurde. das Tool → eine DN Also ich kann das aus "The given LDAP DN will be replicated as if it has been modified." nicht heruaslesen, denn die Aussage macht auch sinn, wenn ich z.B. auf einem Slave eingeloggt bin und mich wundere, warum eine Änderung noch nicht im lokalen LDAP angekommen ist und ich das eben erneut "ziehen" möchte. Erst durch die nachfolgende Meldung "Abort: This tool must be run on the Domaincontroller Master!" erkennt ich, daß ich es vom Master aus machen muß und daß es damit alle Replikate betrifft (und nicht nur das eine Replikat auf dem lokalen Rechner) > > FYI: invoke-rc.d ... > Ist umgestellt. OK FAIL: Wenn ich es ganz genau nehme sollte der Error-Code nicht 0 sein, wenn slapd und der Listener sich am Ende nicht mehr korrekt starten lassen: rc=0 /etc/init.d/... || rc=$? exit $rc > > FAIL: Fehlermeldungen sollten nach STDERR geschrieben werden: > Ist angepasst. OK > > QTA: Warum wird WARNING groß geschieben, aber "Abort" und "failed" nicht? > Warning ist an Abort angepasst. OK > > FAIL: Die Meldung lautet "transaction file", geschrieben wird aber in die > > Listener-Datei. > Ist angepasst. OK (In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #7) > > > Das Tool univention-directory-replication/univention-directory-replicate-one wurde noch entfernt. Das war nur noch im svn und wurde seit einiger Zeit nicht mehr installiert. > dev r35646 + r35647 OK: Nicht mehr vorhanden OK: univention-directory-replication_6.0.3-1.58.201209171123 > changelog r14800 OK
(In reply to comment #10) > (In reply to comment #6) > > (In reply to comment #5) > > > RFA: IMHO sollte erwähnt werden, daß es sich um ein "PUSH" handelt, um den > > > Replikationsmechanismus zum Füllen von downstream-LDAP-Servern zu nutzen, und > > > nicht um ein "PULL", um Daten aus einem upstream-LDAP-Server in ein lokales > > > LDAP zu ziehen. > > > > Zumindest in der Hilfe steht, dass es so ist, als wenn das Tool direkt > > modifiziert wurde. > > das Tool → eine DN > > Also ich kann das aus "The given LDAP DN will be replicated as if it has been > modified." nicht heruaslesen, denn die Aussage macht auch sinn, wenn ich z.B. > auf einem Slave eingeloggt bin und mich wundere, warum eine Änderung noch nicht > im lokalen LDAP angekommen ist und ich das eben erneut "ziehen" möchte. > Erst durch die nachfolgende Meldung "Abort: This tool must be run on the > Domaincontroller Master!" erkennt ich, daß ich es vom Master aus machen muß und > daß es damit alle Replikate betrifft (und nicht nur das eine Replikat auf dem > lokalen Rechner) Das Tool ist normalerweise eh nur auf Master und Backup installiert, da es Bestandteil vom Notifier Paket ist. Wie auch immer, die Meldung ist angepasst. > FAIL: Wenn ich es ganz genau nehme sollte der Error-Code nicht 0 sein, wenn > slapd und der Listener sich am Ende nicht mehr korrekt starten lassen: > rc=0 > /etc/init.d/... || rc=$? > exit $rc Ist angepasst.
(In reply to comment #11) > > FAIL: Wenn ich es ganz genau nehme sollte der Error-Code nicht 0 sein, wenn > > slapd und der Listener sich am Ende nicht mehr korrekt starten lassen: > > rc=0 > > /etc/init.d/... || rc=$? > > exit $rc > > Ist angepasst. OK: Es wird zwar weiterhin "done" angezeigt, aber der Exit-Status ist jetzt wenigstens != 0. RFC: Allerdings hat das Tool noch eine prinzipbedingte Schwäche: Ich hatte auf einem Slave per eval "$(ucr shell ldap/base ldap/hostdn)" ldapmodify -xD "cn=update,$ldap_base" -w "$(cut -d\" -f2 /etc/ldap/rootpw.conf)" <<-__LDIF__ dn: $ldap_hostdn changetype: modify add: description description: Das ist ein Test $$ __LDIF__ eine direkte Änderung im LDAP vorgenommen. Ein anschließendes eval "$(ucr shell ldap/base ldap/hostdn)" univention-replicate-on --dn "${ldap_hostdn/master/slave}" vom Master aus zeigte keine Wirkung, weil zwar die DN vom Notifier an den Listener gemeldet wird, aber das replication-Modul keine Änderung zwischen dem Master-LDAP und dem Slave-Listener-Cache sieht und somit keine Modifikation an den lokalen slapd auf dem Slave schickt. Damit bleibt diese lokale Modifikation bestehen. Zugegeben das Beispiel geht ziemlich brachial mit dem lokalen slapd um, aber für welche Fälle sollte das Programm sonst gut sein? univention-directory-listener-verify -D cn=update,$ldap_base -w "$(cut -d\" -f2 /etc/ldap/rootpw.conf)" -b "$ldap_base" zeigt mir sowieso sehr viele Unterschiede an, von daher kann ich gerade nicht entscheiden, ob das so normal ist oder ob das Programm u.a. auch dazu diesen soll, diese weg zu bekommen. OK: univention-directory-notifier_7.0.6-2.68.201209171522
(In reply to comment #12) > RFC: Allerdings hat das Tool noch eine prinzipbedingte Schwäche: Ich hatte auf > einem Slave per > eval "$(ucr shell ldap/base ldap/hostdn)" > ldapmodify -xD "cn=update,$ldap_base" -w "$(cut -d\" -f2 > /etc/ldap/rootpw.conf)" <<-__LDIF__ > dn: $ldap_hostdn > changetype: modify > add: description > description: Das ist ein Test $$ > __LDIF__ > eine direkte Änderung im LDAP vorgenommen. Ein anschließendes > eval "$(ucr shell ldap/base ldap/hostdn)" > univention-replicate-on --dn "${ldap_hostdn/master/slave}" > vom Master aus zeigte keine Wirkung, weil zwar die DN vom Notifier an den > Listener gemeldet wird, aber das replication-Modul keine Änderung zwischen dem > Master-LDAP und dem Slave-Listener-Cache sieht und somit keine Modifikation an > den lokalen slapd auf dem Slave schickt. Damit bleibt diese lokale Modifikation > bestehen. > Zugegeben das Beispiel geht ziemlich brachial mit dem lokalen slapd um, aber > für welche Fälle sollte das Programm sonst gut sein? > univention-directory-listener-verify -D cn=update,$ldap_base -w "$(cut -d\" > -f2 /etc/ldap/rootpw.conf)" -b "$ldap_base" > zeigt mir sowieso sehr viele Unterschiede an, von daher kann ich gerade nicht > entscheiden, ob das so normal ist oder ob das Programm u.a. auch dazu diesen > soll, diese weg zu bekommen. > > OK: univention-directory-notifier_7.0.6-2.68.201209171522 Ich denke das wäre eher eine generelle Erweiterung für den Listener, dass dies geprüft wird. Aber ich weiß nicht, ob dein Szenario den Aufwand der Implementierung rechtfertigt. Dieses Tool ist beispielsweise dafür gedacht, dass man nach ACL Änderungen sehr einfach neue Bereiche replizieren kann und nicht direkt neu joinen muss.
UCS 3.1-0 has been released: http://forum.univention.de/viewtopic.php?f=54&t=2125 If this error occurs again, please use "Clone This Bug".