Hallo Am Dienstag, 13. September 2005 01:44 schrieb Andreas Bauer:
Hallo,
die Replikation zwischen einem PDC(SL9.2) und einem BDC(SL9.3) funktioniert nicht. hat es schon einmal richtig funkt. und ist es ausgefallen oder bist du noch am installieren?
Ich hab hier ein log des BDC, beim ausführen von/etc/init.d/slurpd restart
auf dem PDC. Der PDC amd hat 192.168.0.7 und BDC ist linuxamd64:
Sep 12 23:54:33 linuxamd64 slapd[7594]: conn=20 fd=17 ACCEPT from IP=192.168.0.7:32860 (IP=0.0.0.0:389) Sep 12 23:54:33 linuxamd64 slapd[7594]: conn=20 op=0 BIND dn="cn=Manager,dc=samba,dc=org" method=128 Sep 12 23:54:33 linuxamd64 slapd[7594]: conn=20 op=0 BIND dn="cn=Manager,dc=samba,dc=org" mech=SIMPLE ssf=0 Sep 12 23:54:33 linuxamd64 slapd[7594]: conn=20 op=0 RESULT tag=97 err=0 text= Sep 12 23:54:33 linuxamd64 slapd[7594]: conn=20 op=1 ADD dn="uid=replikator,ou=people,dc=samba,dc=org" Sep 12 23:54:33 linuxamd64 slapd[7594]: conn=20 op=1 RESULT tag=105 err=10 text= Sep 12 23:54:33 linuxamd64 slapd[7594]: conn=20 op=2 MOD dn="uid=replikator,ou=people,dc=samba,dc=org" Sep 12 23:54:33 linuxamd64 slapd[7594]: conn=20 op=2 MOD attr=userPassword entryCSN modifiersName modifyTimestamp Sep 12 23:54:33 linuxamd64 slapd[7594]: conn=20 op=2 RESULT tag=103 err=10 text= Sep 12 23:54:33 linuxamd64 slapd[7594]: conn=20 op=3 MOD dn="cn=Next
Kann mit der Meldung nach ADD dn.......... :
RESULT tag=105 err=10 text= jemand etwas anfangen? hat der Slave das gleiche Schema? Es gibt nach meiner Erkenntnis abweichende mindestens zwei samba3.schema die nicht identisch sind.
Ein weiteres Problem ist das Mounten der Homeverzeichnisse beim wechseln der /home Verzeichnisse auf den
BDC. Es ist unmöglich auf dem BDC für die Suse Clients neue Homeverzeichnisse zu erstellen, indem man
auf dem Client in die auto.home einfach den BDC anstelle des PDC einträgt. Die Suse 9.2 Clients
melden dann KDE write access Fehler beim Anmelden am BDC, obwohl volle Rechte vergeben sind
und das Verzeichnis auf dem BDC nfs gemountet ist. Der BDC ist doch eigentlich zum
es könnte sein, dass die User UID/SID trotz Replikation (die ja nicht stimmt) nicht identisch sind.
sichern für worst case Fälle da!? Ich will ja einen BDC als Ausfallsicherung für den PDC.
hast du LDAP Master und Slave richtig konf? Stimmen die Einstellungen in den smb.conf? Meldet sich testparm richtig?
auto.home:
* -fstype=nfs amd:/home/& #* -fstype=nfs linuxamd64:/home/&
Ansonsten funktioniert die Suse client Anmeldung am BDC.
Auch ein Problem:
Die Windows XP clients wollen vom BDC neue Computerkonten, die
das stimmen die SIDs nicht. Es ist auch möglich, dass nur der BDC selbst an eine andere SID "glaubt".
müßten vom BDC nach Überspielen der LDAP Datenbank doch auch
vom BDC übernommen werden? Meine BDC Datenbank scheint auch ein bißchen
durcheinander gekommen zu sein. Die Datenbank hab ich mit slapcat > ldapbackup.linuxamd64
müsste eigentlich so gehen
auf dem PDC gesichert und mit slapadd > ldapbackup.linuxamd64 auf den BDC überspielt.
Mache doch die DB kpl. neu: - kommentiere den ganzen Replikator in LDAP aus - prüfe auf 100% identisches Schema - initialisiere die DB zB. mit smbladp-tools (brauchst die SID des PDC) - übertrage die Master-LDAP DB zB. mit "ldapbrowser" - ergänze mit dem Manager für die Replikation - teste das Login-Verhalten - schalte die Replikation wieder ein - teste es erneut
Dort hab ich das database verzeichnis /var/lib/ldap2 angegeben, das auch gefüllt ist. Oder
kann man die Datenbank mit ner anderen Methode sicherer überspielen?
ich arbeite sehr zufriedenstellend mit dem "ldapbrowser". Er kann nicht alles ist aber gut zu handhaben.
Wenn du den BDC zur Anmeldung einsetzten willst, musst du sicherstellen, dass zB. die Logonscripte und Startfiles "serverunabhängig" immer erreichbar sind. Grüsse Bernhard
Gruss und Danke
Andreas