Bug 27625 - Tool um eine DN neu zu replizieren
Tool um eine DN neu zu replizieren
Status: CLOSED FIXED
Product: UCS
Classification: Unclassified
Component: Notifier (univention-directory-notifier)
UCS 3.0
Other Linux
: P5 enhancement (vote)
: UCS 3.1
Assigned To: Stefan Gohmann
Philipp Hahn
: interim-1
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-19 14:37 CEST by Stefan Gohmann
Modified: 2012-12-12 21:07 CET (History)
0 users

See Also:
What kind of report is it?: ---
What type of bug is this?: ---
Who will be affected by this bug?: ---
How will those affected feel about the bug?: ---
User Pain:
Enterprise Customer affected?:
School Customer affected?:
ISV affected?:
Waiting Support:
Flags outvoted (downgraded) after PO Review:
Ticket number:
Bug group (optional):
Max CVSS v3 score:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Gohmann univentionstaff 2012-06-19 14:37:08 CEST
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
Comment 1 Stefan Gohmann univentionstaff 2012-07-17 17:09:33 CEST
UCS 3.1 will be the next release.
Comment 2 Stefan Gohmann univentionstaff 2012-08-30 07:45:23 CEST
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.
Comment 3 Stefan Gohmann univentionstaff 2012-08-30 08:08:47 CEST
Es sollte die listener/listener Datei berücksichtigt werden und das parallele Ändern von Objekten.
Comment 4 Stefan Gohmann univentionstaff 2012-08-30 08:26:28 CEST
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.
Comment 5 Philipp Hahn univentionstaff 2012-09-14 16:00:29 CEST
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
Comment 6 Stefan Gohmann univentionstaff 2012-09-17 07:30:29 CEST
(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.
Comment 7 Stefan Gohmann univentionstaff 2012-09-17 08:37:03 CEST
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.
Comment 8 Stefan Gohmann univentionstaff 2012-09-17 08:54:26 CEST
(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.
Comment 9 Stefan Gohmann univentionstaff 2012-09-17 09:03:32 CEST
(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
Comment 10 Philipp Hahn univentionstaff 2012-09-17 15:10:23 CEST
(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
Comment 11 Stefan Gohmann univentionstaff 2012-09-17 15:44:03 CEST
(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.
Comment 12 Philipp Hahn univentionstaff 2012-09-18 19:20:49 CEST
(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
Comment 13 Stefan Gohmann univentionstaff 2012-09-18 20:38:56 CEST
(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.
Comment 14 Stefan Gohmann univentionstaff 2012-12-12 21:07:46 CET
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".