PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Openldap und Replikation



Technikman
04.05.06, 22:32
Hallo,

ich versuch grad bei mir auf Debian sarge nen openldap-Server mit replikation zum laufen zu bekommen.
Das ganze funktioniert auch vom Master zum Slave hin. Jedoch will ich auch, das der Slave wenn er anfragen bekommt das er das ganze zum Master schickt. Nur irgendwie funktioniert das nicht so richtig. Jemand ne Idee an was das liegen könnte.

Config Master:



include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/samba.schema

schemacheck on

pidfile /var/run/slapd/slapd.pid

argsfile /var/run/slapd.args

loglevel 512

modulepath /usr/lib/ldap
moduleload back_bdb

backend bdb
checkpoint 512 30


database bdb

suffix "dc=my,dc=lan"

directory "/var/lib/ldap"

index objectClass eq

lastmod on

access to attrs=userPassword
by dn="cn=admin,dc=my,dc=lan" write
by anonymous auth
by self write
by * none

access to dn.base="" by * read

access to *
by dn="cn=admin,dc=my,dc=lan" write
by * read

access to *
by dn="cn=repadmin,dc=my,dc=lan" write

replogfile /var/spool/slurpd/replica/replogfile
replicationinterval 5
replica host=hackstock.muc.my.lan:389
binddn="cn=admin,dc=my,dc=lan"
bindmethod=simple
tls=no
credentials=passwort



Config Slave:


include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/samba.schema

schemacheck on


pidfile /var/run/slapd/slapd.pid

argsfile /var/run/slapd.args

loglevel 512

modulepath /usr/lib/ldap
moduleload back_bdb

backend bdb
checkpoint 512 30

database bdb
suffix "dc=my,dc=lan"

database #1
directory "/var/lib/ldap"

index objectClass eq


lastmod on

access to attrs=userPassword
by dn="cn=admin,dc=my,dc=lan" write
by anonymous auth
by self write
by * none
access to dn.base="" by * read

access to *
by dn="cn=admin,dc=my,dc=lan" write
by * read


updatedn "cn=admin,dc=my,dc=lan"
updateref "ldap://biber.muc.my.lan"



Besten Dank

fladi.at
05.05.06, 12:23
Jedoch will ich auch, das der Slave wenn er anfragen bekommt das er das ganze zum Master schickt.

Meinst du lesende oder schreibende Anfragen?
Wenns ums schreiben auf dem Slave geht, so wird das nur so funktionieren, indem der slave die Anfrage an den Master umleitet. Das erreichst du mit den Einstellungen in der slapd.conf am Slave:



updatedn "cn=benutzer-mit-passenden-rechten,dc=firma,dc=org"
updateref ldap://master.ldap.tld

Technikman
05.05.06, 14:29
Ich meine Schreibende Anfragen an den Master. Sprich ich will auf den Slave was schreiben, und das soll auf den Master ausgeführt werden und das ganze soll weiter zu den Slave(s) geleited werden.

ich hab ja schon mit


updatedn "cn=admin,dc=my,dc=lan"
updateref "ldap://biber.muc.my.lan"


den ldapadmin (Replikationsadmin hab ich noch nicht der einfachkeithalber) eingetragen und der host (biber.muc.my.lan) ist mein Master. Also ansich müßte es funktionieren vom verständis her.

mr_kaktus
05.05.06, 14:47
Habe ich das richtig Verstaden, du willst vom SLAVE auf dem Master schreiben ?

Technikman
05.05.06, 14:54
Also geplant ist das so, das ich mich via ldap am Slave authentifizieren und dort auch z.B. das passwort direkt ändere. Also für die Anwendung die änderung am Slave mache. Nur sollte das doch irgendwie gehen, das der Slave alles zum Master weiterleitet und der dann alles an den Slaves verteilt. Oder hab ich da noch was falsch verstanden?

mr_kaktus
05.05.06, 15:06
Ok, verstehe was du vorhast ...
Hm... an sich musste das schon gehen, muss mal schauen wo ich das noch mal gesehen hatte. Aber ich frage mich was das Bringen soll?
Wenn der Master Weg ist, dann Springt der Slave ein, dann kann der Slave nichts mehr an der Master schicken.
Warum willst das jetzt eigentlich so einstellen?

fladi.at
05.05.06, 19:21
Nur sollte das doch irgendwie gehen, das der Slave alles zum Master weiterleitet und der dann alles an den Slaves verteilt. Oder hab ich da noch was falsch verstanden?

Ja, genau so sollte es gehen. Was genau funktioniert denn noch nicht? Evtl. gibt es ja passende Fehlermeldungen bzw. wie generierst du denn die Schreib-Anfragen? Benutzt du es mit nss_ldap und pam_ldap?

Technikman
05.05.06, 20:00
Also,
ich hatte ursprünglich den Slave als Master... Dort hat alles funzt. Jetzt hab ich in der slapd.conf die 2 Zeilen für die Slave-Konfig reingeschrieben und das ganze Verzeichnis auf den Master kopiert. Dort die "Masterzeilen" reingeschrieben.
PAM (oder nssldap?) kreift weiterhin direkt auf den Slave zu wie es früher war, als der noch Master war.
Jetzt hätte ich gedacht, da der slave ja weiß, das es den Master gibt und den Host + Ldapadmin kennt, werden die änderungen gleich im Master gemacht und zum Slave runter gesendet.

Wenn ich jetzt jedoch das passwort ändere oder so geht das allerding nicht wirklich.
Ebenfalls versuch ich mit phpldapadmin oder ähnliches z.B. eine OU zu löschen. Das macht der auch nur lokal auf den Slave und gibt das nicht zum Master hoch.

Ich tippe immernoch darauf, das ich irgendwo nen Denkfehler hab.

Was ich Vorhab: Mich zu Authentifizieren und evenlt. nen Evolution-Adressbuch o.Ä. über ldap Einzurichten. Ist der Master nicht erreichbar, soll alles weiterhin lesend funktionieren (Aktualisieren halt nicht)
Ist halt gedacht für'n Laptop wenn der Mobil ist hab ich ja keinen Zugriff zum ldap-Master.

Ach ja. Nen gescheites Log hab ich noch nicht so wirklich gefunden. Hab sämtliche Logfiles im log-Verzeichnis durchgesucht, allerdings nirgends ne gescheite Aussage gefunden.

mr_kaktus
05.05.06, 20:05
Ok, jetzt verstehe ich dein Problem!
Du hast Master und Slave umgedreht und jetzt funkt das nicht mehr, richtig?
Ich vergleich das am Montag gleich mit meiner Config und geb dir mal bescheid, OK ?

Technikman
05.05.06, 20:13
Ne ich hate am anfang keinen Slave... aber im prinzip hast du recht.
Authentifizierung klappt ja auch noch. Nur das Aktualisieren halt nicht...

mr_kaktus
09.05.06, 15:09
Hi,

versucht mal in der auf dem SLAVE LDAP das updateref wie folgt zu schreiben:
updateref ldap://biber.muc.my.lan
Kannst du den Server ldap://biber.muc.my.lan anpingen?

Wenn das alles nicht klappt, dann starte mal den Slurpd in debugmodus und poste mal was er sagt:
/usr/lib/openldap/slurpd -t /var/lib/slurpd -d 4 Sag mir dann mal schnell bescheid, es interessiert mich :)

Technikman
09.05.06, 20:39
So hier das Log:




biber:~# slurpd -d4
@(#) $OpenLDAP: slurpd 2.2.23 (May 30 2005 08:57:10) $
@pulsar:/home/torsten/packages/openldap/openldap2.2-2.2.23/debian/build/
servers/slurpd

Retrieved state information for hackstock.muc.my.lan:389 (timestamp 1147199207.0
)
begin replication thread for hackstock.muc.my.lan:389
new work in /var/spool/slurpd/replica/replogfile
copy replog "/var/spool/slurpd/replica/replogfile" to "/var/spool/slurpd/replica
/slurpd.replog"
Initializing session to hackstock.muc.my.lan:389
request 1 done
TLS: can't connect.
Warning: ldap_start_tls failed: Connect error (-11)
Initializing session to hackstock.muc.my.lan:389
bind to hackstock.muc.my.lan:389 as cn=admin,dc=my,dc=lan (simple)
request 1 done
replica hackstock.muc.my.lan:389 - add dn "ou=as,dc=my,dc=lan"
request 2 done



so jetzt das teil auf den Slave gelöst...

Nix im Log

OU am Master gelöscht:


new work in /var/spool/slurpd/replica/replogfile
copy replog "/var/spool/slurpd/replica/replogfile" to "/var/spool/slurpd/replica
/slurpd.replog"
replica hackstock.muc.my.lan:389 - delete dn "ou=as,dc=my,dc=lan"
request 3 done
Error: ldap_delete_s failed deleting "": ou=as,dc=my,dc=lan
Error: ldap operation failed, data written to "/var/spool/slurpd/replica/hacksto
ck.muc.my.lan:389.rej"

Die Konfig hatte ich auch schon ohne "" :)

Jetzt die alles entscheidende Frage. slurpd muß das auch auf den Slave laufen? Das Tut's nämlich nicht...

Anpingen kann ich den slave

hackstock:/var/lib# ping biber.muc.my.lan
PING biber.muc.my.lan (192.168.1.20) 56(84) bytes of data.
64 bytes from biber (192.168.1.20): icmp_seq=1 ttl=64 time=1.06 ms

mr_kaktus
10.05.06, 08:51
Nein der Slurp muss nicht auf dem SLAVE Laufen! Der muss nur auf dem Master laufen.
Aber der Fehler steht doch in der LOG:
TLS: can't connect.
Warning: ldap_start_tls failed: Connect error (-11) Schalt mal das TLS aus. Dann müsste es funktionieren.

Technikman
16.05.06, 21:44
Sorry hatte bissl was um die Ohren.

Also TLS müsste aus sein. Hab's wenigstens nicht eingeschalten. In der Konfig oben ist's ja auch nicht mit drinn.

Außerdem sollte nicht wenn TLS ein wäre die OU am Slave nicht durchkommen. Die TLS-Fehlermeldung kommt ja beim anlegen der OU.

Also hab versucht was ich kann. Aber tut sich nix.

mr_kaktus
16.05.06, 22:40
Kein Problem :)
Und du hast wirklich geschaut, ob das TLS aus ist :ugly:
Warum kommt dann die Fehlermeldung?
Versuch es noch mal, starte aber dies mal den slapd im Debugmode und Leg alle LOGs rein (Die /var/log/messages, die vom SLAPD und die vom SLURPD)
Wär doch gelacht wenn wir das nicht hinbekommen. :D