Join failed: failed.ldif exists

Hallo. Da ein DC Slave Änderungen aus dem LDAP nicht mehr übernommen hatte, wollte ich diesen erneut joinen. Dabei kam dies heraus.
Ich hab wohl alle möglichen Threads hier und PDFs darüber gelesen. Allerdings halfen die Tips die failed.ldif einfach zu löschen oder mit univention-directory-replication-resync einzuspielen nicht weiter.

[code]univention-join: joins a computer to an ucs domain
copyright © 2001-2010 Univention GmbH, Germany

Insert DC Master Account : Administrator
Insert DC Master Password:

Search DC Master: done
Check DC Master: done
Stop LDAP Server: done
Search ldap/base done
Start LDAP Server: done
Search LDAP binddn done
Sync time done
Join Computer Account: done
Stopping univention-directory-listener daemon: done
Sync ldap-backup.secret: done
Check TLS connection done
Download host certificate done
Restart LDAP Server: done
Sync Kerberos settings: done
Configure 01univention-ldap-server-init.inst done
Configure 03univention-directory-listener.inst done


  • Join failed! *
  • Contact your system administrator *

  • Message: FAILED: failed.ldif exists.
    **************************************************************************[/code]

Hier der Thread sieht interessant aus. So eine ähnliche Konstellation hab ich nämlich auch:

forum.opsi.org/viewtopic.php?f=6&t=2273

Hallo,

bei einer gestörten LDAP Replikation werden alle Objekte im LDIF-Format in eine Datei geschrieben, um die Änderungen, wenn der LDAP-Server wieder erreichbar ist, nachträglich einspielen zu können. Daher sollten failed.ldif Dateien niemals gelöscht werden ohne Sie angesehen bzw. geprüft zu haben.

Bzgl “des Löschens” wäre es interessant zu erfahren wo empfohlen wurde das eine failed.ldif Datei gelöscht werden soll?

In dem folgenden Dokument ist unter anderem beschrieben wie eine failed.ldif Datei eingespielt werden kann: Listener/Notifier-Mechanismus

Sie schrieben:

Dazu wurde der folgende Bug-Eintrag vorgenommen und kommentiert: 21433

Die Prüfung bzw. Ausgaben der folgenden Punkte auf dem DC Master wären in diesem Fall interessant:

[code]# eval “$(ucr shell)”

ldapsearch -x -LLL -D cn=admin,$ldap_base -w $(cat /etc/ldap.secret) cn=hostGroups[/code]

  • Die Opsi Schema Datei?

  • Wurde die opsi4ucs Version irgendwann aktualisiert?

  • In einer Testumgebung bitte das folgende auf dem DC Master testen:

[code]# /etc/init.d/slapd stop

slapcat >ldif

mkdir /var/lib/univention-ldap/ldap.BACKUP

mv /var/lib/univention-ldap/ldap/* /var/lib/univention-ldap/ldap.BACKUP/

ucr commit /var/lib/univention-ldap/ldap/DB_CONFIG

slapadd <ldif

/etc/init.d/slapd start

[/code]

Mit freundlichen Grüßen
Murat Odabas

[quote=“odabas”]Hallo,

bei einer gestörten LDAP Replikation werden alle Objekte im LDIF-Format in eine Datei geschrieben, um die Änderungen, wenn der LDAP-Server wieder erreichbar ist, nachträglich einspielen zu können. Daher sollten failed.ldif Dateien niemals gelöscht werden ohne Sie angesehen bzw. geprüft zu haben.

Bzgl “des Löschens” wäre es interessant zu erfahren wo empfohlen wurde das eine failed.ldif Datei gelöscht werden soll?[/quote]


Vorher hab ich übrigens gemmäß Ihrer Anleitung schon erstmal einen rsync versucht, welcher allerdings darin mündete, daß immer mehr solcher Dateien in /tmp angelegt wurden ohne daß diese kleiner wurden.
[/quote]

Die Ausgabe vom ersten Befel ist leer. Die vom anderen:

dn: cn=hostGroups,cn=groups,cn=opsi,dc=home,dc=dg
objectClass: organizationalRole
cn: hostGroups

Die opsi.schema-Datei hab ich angehängt. Ich werd versuchen den Test so schnell wie möglich durchzuführen. Vielen Dank schon mal

EDIT: Datei angehängt

Ich hab den Test durchgeführt. Ein Join ließ sich hinterher immer nocch nicht durchführen. Er brach mit der selben Fehlermeldung wie vorher ab.
Achja, ein Update von opsi wurde nicht durchgeführt.
opsi.schema.txt (23.1 KB)

Hallo,

wenn eine failed.ldif Datei existiert und sicher ist dass das System anschließend gejoint wird, so kann die failed.ldif Datei gelöscht werden. Beim Joinen des Systems wird unter anderem auch die LDAP-Replikation durchgeführt, so dass die LDAP-Server anschließend wieder synchron sind.

Können Sie uns noch mitteilen welche UCS und OPSI Versionen Sie derzeit auf Ihren Systemen einsetzen?

Zusätzlich können Sie noch erweiterte Debug-Meldungen erzeugen in dem Sie den Debug-Level des Univention Directory Listener auf dem DC Master auf 4 erhöhen und den Member-Server erneut Joinen. Anschließend können sie Log-Datei /var/log/univention/listener.log als Anhang beifügen. Beachten Sie bitte dass der Debug-Level nach dem Test wieder herabgesetzt werden sollte.

# ucr set listener/debug/level=4
# /etc/init.d/univention-directory-listener restart

Mit freundlichen Grüßen
Murat Odabas

Hallo,

die Log-Datei hab Ihnen an feedbakc@univention.de gemailt.Ich setze UCS 2.4-1-2 mit der aktuellen opsi-Version aus dem Repository bei opensuse.org ein.

Hallo bei mir hat es mit dem Workaround aus dem Bug-Report auch funktioniert :slight_smile:

Das war leider etwas zu früh gefreut. Das joinen klappt zwar jetzt, aber beim reboot tritt wieder eine failed.ldif auf und das anmelden mit Domänenbenutzern klappt nicht mehr.

EDIT: Nach nem weiteren Domänenbeitritt und reboot tritt keine failed.ldif mehr auf, aber ein anmelden ist weiterhin nicht möglich.

Nach einer Neuinstallation des SDCs scheint alles wieder zu laufen.

Mastodon