Hello list.
I'm trying to achieve multi-master setup, starting from a working single-master setup. I took the master node configuration, added the following directives, and distributed it identically on two nodes:
# global serverID 1 ldap://10.202.11.8:389/ serverID 2 ldap://10.202.11.9:389/
# db ... syncrepl rid=1 provider=ldap://10.202.11.8:389/ starttls=yes tls_reqcert=never type=refreshAndPersist retry="60 +" logbase="cn=log" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog searchbase="dc=msr-inria,dc=inria,dc=fr" scope=sub schemachecking=off bindmethod=simple binddn="cn=syncrepl,ou=roles,dc=msr-inria,dc=inria,dc=fr" credentials=XYZ
syncrepl rid=2 provider=ldap://10.202.11.9:389/ starttls=yes tls_reqcert=never type=refreshAndPersist retry="60 +" logbase="cn=log" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" syncdata=accesslog searchbase="dc=msr-inria,dc=inria,dc=fr" scope=sub schemachecking=off bindmethod=simple binddn="cn=syncrepl,ou=roles,dc=msr-inria,dc=inria,dc=fr" credentials=XYZ
mirrormode on
The 'tls_reqcert=never' is needed because those two servers are accessed from a virtual interface under a load-balancing server, and the certificate name matches the name of this virtual interface, not the actual interface of the servers (I wonder if openldap would support altSubjName in x509 certs, but that's another issue).
Then I imported my base in the first server, and launched both of them.
When node1 (full) tries to access node2 (empty), it fails, because it can't authenticate with a DN still not present in other node database, which is quite understandable.
However, node2 connects successfully, sync the the OU object in the DIT, then fails to actually sync the first user object, with this error message in his logs: Jan 13 11:29:20 avron2 slapd[20939]: null_callback : error code 0x13 Jan 13 11:29:20 avron2 slapd[20939]: syncrepl_entry: rid=001 be_add uid=ingleber,ou=users,dc=msr-inria,dc=inria,dc=fr (19) Jan 13 11:29:20 avron2 slapd[20939]: syncrepl_entry: rid=001 be_add uid=ingleber,ou=users,dc=msr-inria,dc=inria,dc=fr failed (19) Jan 13 11:29:20 avron2 slapd[20939]: do_syncrepl: rid=001 rc 19 retrying
In node1 logs: Jan 13 10:28:31 avron1 slapd[15713]: conn=1000 op=1 BIND dn="cn=syncrepl,ou=roles,dc=msr-inria,dc=inria,dc=fr" method=128 Jan 13 10:28:31 avron1 slapd[15713]: conn=1000 op=1 BIND dn="cn=syncrepl,ou=roles,dc=msr-inria,dc=inria,dc=fr" mech=SIMPLE ssf=0 Jan 13 10:28:31 avron1 slapd[15713]: conn=1000 op=1 RESULT tag=97 err=0 text= Jan 13 10:28:31 avron1 slapd[15713]: conn=1000 op=2 SRCH base="dc=msr-inria,dc=inria,dc=fr" scope=2 deref=0 filter="(objectClass=*)" Jan 13 10:28:31 avron1 slapd[15713]: conn=1000 op=2 SRCH attr=* + Jan 13 10:28:31 avron1 slapd[15713]: send_search_entry: conn 1000 ber write failed. Jan 13 10:28:31 avron1 slapd[15713]: conn=1000 fd=21 closed (connection lost on write)
It's hard to tell if the failure occurs on the provider (ber write failed message) or consumer side (null_callback : error code 0x13).
Any hint welcome.
Le 13/01/2010 11:31, Guillaume Rousse a écrit :
It's hard to tell if the failure occurs on the provider (ber write failed message) or consumer side (null_callback : error code 0x13).
I finally found the issue: a constraint violation preventing to use an unknown gidNumber for any user:
constraint_attribute gidNumber uri
ldap:///ou=groups,dc=msr-inria,dc=inria,dc=fr?gidNumber?sub?(objectClass=posixGroup)
restrict="ldap:///ou=users,dc=msr-inria,dc=inria,dc=fr??sub?(objectClass=posixAccount)"
As the user get synced before the group, it fails :(
Is this really necessary to check constraint violations when using syncrepl ? We already have a 'schemachecking' directive, we may have an additional 'constraintchecking' one. At least, an explicit error message for 'sync' level would have been more meaningful.
On Mon, Jan 18, 2010 at 3:38 PM, Guillaume Rousse Guillaume.Rousse@inria.fr wrote:
Is this really necessary to check constraint violations when using syncrepl ? We already have a 'schemachecking' directive, we may have an additional 'constraintchecking' one. At least, an explicit error message for 'sync' level would have been more meaningful.
I haven't followed the beginning of this thread but I lately moved many replicas to OpenLDAP 2.4 and found it easier to just remove schemachecking in my case. That said, we don't have a big database nor big writes. A couple of additional schemas but all standard (courier, samba, etc...)
Cheers, Steph
openldap-software@openldap.org