Ok, let me see If I can help here:
Let me see: Your clients are updating data on the slave ldap server?, Ok, you should not allow that (unless you try the "experimental" multi-master replication code, wich can fail).
You should use other ldap user, like this:
cn=adminmaster,dc=cosa,dc=int
Wich have write permitions to the master, but read-only access on slaves (by using different access statements in the master and the slave). I use something like this in the master:
access to *
by dn="cn=ldapadmin,dc=merkurio,dc=int" write
by * readAnd the updatedn would be the rootdn of the slave (so, it has write access to the slave).
Ok, hope this can help,
Sincerely,
Ildefonso Camargo [EMAIL PROTECTED]
McKeever Chris wrote:
On Fri, 18 Jun 2004 15:38 , Michael Gasch <[EMAIL PROTECTED]> sent:
Isn't the slave ldap directory suppose to be only read only?if it's readonly, slurpd can't update the slave (i've tested it, possibly i missed something ?)
the problem is: machines regularly change their passwords and if these changes are not done on the master, they're lost, if master comes back -> clients can't logon anymore and so on....
maybe I am missing something here - but why does your master ldap fail so often? I agree with the other poster, the slave LDAPS should be (and I would almost move to _need_ to be) read only .. I am also curious as to why you have a samba server contacting either the PDC/BDC ldap servers when it could just be running a replicated LDAP DB itself...which is how all the docs say to do it - maybe this is something new with 3.xx - not sure, but it alwyas seemed more logical to have all your samba boxes be thier own DC in terms of login/user information
If your master does fail - and I mean dead, need to rebuild, etc..I would make one of the slaves the write/master get the original MASTER back on line, but not in production until you can do a slapcat of the LDAP to it, change the everything back to what it needs to be, and have your system running again....
but like I said, maybe I am missing something
I'm having some troubles
getting the failover to work
what problems are you talking about?
these are my config files (/etc/ldap.conf for all machines not included but also very important in case of fail-over)
....... removed .......
Jason C. Waters schrieb:
Isn't the slave ldap directory suppose to be only read only? So when the master is down the users can't change their passwords, but everything else should work. What do you smb.conf and slapd.conf files look like for the master and the slave? I'm having some troubles getting the failover to work, so I wouldn't mind a peek. Thanks
Jason
Michael Gasch wrote:
hi
i'm looking for hints/experiences concering samba v3, openldap AND redundancy
my setup is:
Samba PDC with LDAP Master Samba BDC with LDAP Slave Samba Member Server, contacting first PDC, then BDC if the first fails
if all instances are working properly, everything is okay replication is also fine (from Master -> Slave)
and now imagine:
LDAP Master dies
all smbd are contacting LDAP Slave and make their changes in the Slave directory
cause replication only works from Master->Slave, if Master comes up again, i have inconsistency in my LDAP Backends
e.g. a machine changes its machine password in Slave directory and can't logon anymore cause the password change isn't replicated on Master
we also tried to setup slurpd (LDAP replication) on both LDAP Servers - if both are up, everything is okay, if one is down, changes are made in one directory, samba tells me it fails (e.g. changing passwords), allthough it changes the attributes and so on....
so the problem is: if Slave dies, everything should go on working, because PDC/BDC use at first LDAP Master
if slave comes up, replication is done properly
but if Master dies, i get an inconsistent domain
how do you get redundancy in your LDAP backend? PDC/BDC redundancy works well, the single-point-of-failure is LDAP
thx
------------------------------------------- Chris McKeever If you want to reply directly to me, please use cgmckeever--at--prupref.com <A href="http://www.prupref.com";>Prudential</A><A href="http://www.prupref.com";>Chicago Real Estate</A>
---- Prudential Preferred Properties www.prupref.com
Success Driven By Results
Results Driven By Commitment
Commitment Driven By Integrity
We Are Prudential Preferred Properties
-- To unsubscribe from this list go to the following URL and read the instructions: http://lists.samba.org/mailman/listinfo/samba
