Fehlerhaft eingerichtete openldap Replikation loswerden?

[sbrunthaler]

Hallo,

wie es dazu kam, ist mir nicht klar, aber jedenfalls habe ich auf einem Server eine ldap-Konfiguration, bei der das Attribut olcSyncRepl auf sich selbst zeigt, d.h. mein Server ist Provider und Consumer zugleich. Es gibt keine slapd.conf Datei, sondern ein /etc/openldap/slapd.d Verzeichnis, und die Konfiguration steht in der Datenbank (cn=config). Das Ganze hat yast2 angerichtet, deshalb wende ich mich an dieses Forum.

Problem: Wenn ich versuche, den Eintrag per ldapmodify zu löschen, bekomme ich einen Referral-Hinweis (10), dass ich bitte einen anderen Server fragen soll - bloss der bin "ich" ja selber. Der Server läuft übrigens, nur kann man die Konfiguration nicht mehr ändern, weil genau die Datenbank cn=config betroffen ist.

Frage: Kennt jemand einen Weg, wie man diesen olcSyncRepl Eintrag wieder los wird?

a) Bei runtergefahrenem slapd kann man slapadd verwenden, um zusätzliche Einträge anzulegen, aber löschen oder ändern?

b) Die .ldif Files unter /etc/openldap/slapd.d könnte man editieren, aber werden die denn beim Starten des Servers gelesen, oder ist nicht vielmehr die cn=config Datenbank die "Quelle"?

Bin für jede Hilfe dankbar!

Grüsse aus Berlin,
Stefan B.

 

[spoensche]

a) Bei runtergefahrenem slapd kann man slapadd verwenden, um zusätzliche Einträge anzulegen, aber löschen oder ändern?

Zum bearbeiten, also auch zum löschen muss der jeweilige User auch die Rechte dazu inne haben. Die Zugriffsrechte werden in der slapd.conf festgelegt. Wenn keine Rechte vergeben sind, dann wird der Zugriff verweigert.

b) Die .ldif Files unter /etc/openldap/slapd.d könnte man editieren, aber werden die denn beim Starten des Servers gelesen, oder ist nicht vielmehr die cn=config Datenbank die "Quelle"?

Diese Dateien sollte man besser nicht einfach in einem Editor ändern. Füge einen Benutzer in der slapd.conf ein, der die Berechtigung hat, die Konfiguration zu ändern und starte danach den slapd durch. Danach kannst du mit dem Benutzer die Konfiguration ändern.

 

[stka]

Ich weiß nicht, was suse bei der Grundkonfiguration über cn=config macht, aber ich weiß, dass Debian da nur Käse macht. Woher soll das System denn auch wissen, was du eigentlich willst. Also entweder man fängt ganz frisch an und konfiguriert den Server von Grund aus über cn=config selber und zwar mit eigen ldifs. Oder (in meinen Augen der viel einfachere Weg, man stellt um auf die statische Konfigurtion über dei slapd.conf und wenn alles läuft, dann konvertiert man auf die dynamische Konfiguration über cn=config.
Des weiteren ist der yast mit seinen Mitteln völlig überfordet wenn es um die Konfiguration des LDAP übert cn=config geht. Besser du steigst um auf z.B. Jxplorer.
Wenn du weißt was du tust, kannst du den LDIF aus dem Verzeichnis sysconf.d nehmen, dann anpassen und an einen andere Stelle sichern. De Server anhalten, das Verzeichnis slapd.d löschen den Server neu starten und dann mit ldapadd die Konfigration wieder einspielen.
Oder du nennst das Verzeichnis um und legst ein neues slapd.d an und startest da von neuem.
Wenn du nur einen LDAP-Server hast, brauchst du gar keine Replikation und es sollte auch keine eingerichtet werden. Wenn du eine frische slapd.conf suchst, die du für einen Neuanfang nutzen kannst, wirst du auf meiner Webseite zum Buch (siehe Signatur) fündig.

 

[sbrunthaler]

Füge einen Benutzer in der slapd.conf ein, der die Berechtigung hat, die Konfiguration zu ändern und starte danach den slapd durch. Danach kannst du mit dem Benutzer die Konfiguration ändern.

Berechtigungsprobleme sind es nicht. Wie löscht man mit slapadd - dazu habe ich keine Hinweise gefunden; und mit ldapmodify geht es nicht, weil die (fehlerhafte) Replikation im Wege ist.

@stka: Naja, alles wegschmeissen und neu starten wollte ich halt nicht bloß wegen dieses einen blöden Eintrages. Und die Replikation war zur Sicherheit gedacht; wenn wir alles auf single-signon umstellen, kann keiner mehr arbeiten, wenn der einzige ldap-Server nicht erreichbar ist.

Danke und Gruss,
Stefan B.

 

[stka]

HAAAALT Nicht ALLES wegschmeißen, nur die Konfiguration im cn=config. Deine Datenbank mit den Objekten ist davon ja nicht betroffen. Selbst wenn du das ganze cn=config rauswirfst und eine slapd.conf einrichtest läuft deine Datenbank wieder. Wenn du das auf beiden Server machst und dann die Replikation ERST in der slapd.conf einrichtest und erst wenn dann alles fehlerfrei läuft. DANN solltest du umstellen auf cn=config. Denn mit einer slpad.conf bist du mit Änderungen immer schneller wenn du die Grundeinrichtung machen willst.
Besonders wenn du nohc ein single-sign-on einrichten willst, dann kommt ja noch Kerberos dazu und dann wird es erst richtig spannend. Denn die Datenbank des Kerberos solltest du wenn dann auch in den LDAP packen. Wie das geht steht in unserem Buch "Linux-Server"
Wenn ihr das im Unternehmen nutzen wollt, solltest du auch mal über eine Ausgabe von 180.-€ für dem LDAP-Account-Manger PRO nachdenken, denn damit kannst du deine Benutzer dann inklusive der Kerberos-Informationen über ein Web-Frontend verwalten.