I have an Multimaster/mirrormode replication that has worked for months.
Someone put some crappy data into the LDAP and then it crashed.
I've spent weeks cleaning up the data, thinking that was causing my replication to crash and core dump one of my two LDAP servers
I have cleaned up the data, loaded all the data from server1 to server2 and turned on the replication again, but I still get core dumps on server2. (server1 never has a problem)
I'm not sure where to go from here. Any suggestions or anyone else who came across the same problem. Below are some log and config entries. Host OS is Solaris10 on server1 and OpenSolaris on server2. (I have three other openLDAP servers running two with the same replication so I'm somewhat experienced with getting this to work so I'm thinking it's a strange problem I hope someone has run across)
log (server2): ========== Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 592946 local4.debug] <= root access granted Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 384072 local4.debug] => access_allowed: search access granted by manage(=mwrscxd) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 923158 local4.debug] => access_allowed: search access to "cn=manager,dc=nitle,dc=org" "obj ectClass" requested Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 592946 local4.debug] <= root access granted Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 384072 local4.debug] => access_allowed: search access granted by manage(=mwrscxd) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 525403 local4.debug] dn_callback : new entry is older than ours cn=manager,dc=nitle,dc=org ours 20080702134355.493573Z#000000#002#000000, new 20080107224745.105385Z#000000#002#000000 Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 819441 local4.debug] syncrepl_entry: rid=010 entry unchanged, ignored (cn=manager,dc=nitle ,dc=org) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 977386 local4.debug] syncrepl_entry: rid=010 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 580501 local4.debug] syncrepl_entry: rid=010 inserted UUID c76c7c0c-57fb-102c-9216-63c463e 7d505 Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 923158 local4.debug] => access_allowed: search access to "dc=nitle,dc=org" "entry" request ed Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 592946 local4.debug] <= root access granted Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 384072 local4.debug] => access_allowed: search access granted by manage(=mwrscxd) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 565591 local4.debug] syncrepl_entry: rid=010 be_search (0) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 709484 local4.debug] syncrepl_entry: rid=010 ou=guest,dc=nitle,dc=org Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 688566 local4.debug] syncrepl_entry: rid=010 be_add (68) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 923158 local4.debug] => access_allowed: search access to "ou=guest,dc=nitle,dc=org" "entry " requested Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 592946 local4.debug] <= root access granted Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 384072 local4.debug] => access_allowed: search access granted by manage(=mwrscxd) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 923158 local4.debug] => access_allowed: search access to "ou=guest,dc=nitle,dc=org" "objectClass" requested Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 592946 local4.debug] <= root access granted Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 384072 local4.debug] => access_allowed: search access granted by manage(=mwrscxd) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 525403 local4.debug] dn_callback : new entry is older than ours ou=guest,dc=nitle,dc=org ours 20080715143748.768257Z#000000#002#000000, new 20080115212254.445224Z#000000#001#000000 Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 819441 local4.debug] syncrepl_entry: rid=010 entry unchanged, ignored (ou=guest,dc=nitle,dc=org) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 977386 local4.debug] syncrepl_entry: rid=010 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 580501 local4.debug] syncrepl_entry: rid=010 inserted UUID 3a055df6-54c8-102c-9c74-3bd710846f22 Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 923158 local4.debug] => access_allowed: search access to "dc=nitle,dc=org" "entry" requested Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 592946 local4.debug] <= root access granted Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 384072 local4.debug] => access_allowed: search access granted by manage(=mwrscxd) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 565591 local4.debug] syncrepl_entry: rid=010 be_search (0) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 709484 local4.debug] syncrepl_entry: rid=010 uid=jbeckelm@coe.edu,ou=guest,dc=nitle,dc=org Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 923158 local4.debug] => access_allowed: search access to "dc=nitle,dc=org" "entry" requested Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 592946 local4.debug] <= root access granted Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 384072 local4.debug] => access_allowed: search access granted by manage(=mwrscxd) (** CRASHES HERE EVERY TIME **)
conf(server2): =========== syncrepl rid=010 provider=ldap://ldap1.site.org:389 binddn="cn=mirroracct,ou=replication,dc=nitle,dc=org" bindmethod=simple credentials=*** searchbase="dc=nitle,dc=org" type=refreshAndPersist scope=sub interval=00:00:00:10 retry="15 5 300 +" timeout=1 schemachecking=off starttls=yes
syncrepl rid=011 provider=ldap://ldap2.site.org:389 binddn="cn=mirroracct,ou=replication,dc=nitle,dc=org" bindmethod=simple credentials=*** searchbase="dc=nitle,dc=org" type=refreshAndPersist schemachecking=off scope=sub interval=00:00:00:10 retry="15 5 300 +" timeout=1 starttls=yes
overlay syncprov serverID 2 mirrormode true
Thanks in advance!
Sellers
++++++++++++++++++++++++++++++++++++++ Chris G. Sellers | Internet Engineer | NITLE 734.661.2318 | chris.sellers@nitle.org Jabber: csellers@nitle.org | AIM: imthewherd
Follow-up.
I'm rebuilding the servers and started from scratch.
I was able to get replication working just as it did before, but if I add an account like the one below to either server1 or server2, the other server crashes when it replicates. I get notices about it trying to insert UUID and then it crashes.
If memory serves me right, this problem started happening shortly after I changed my syncrepl statement to not include specific attributes, and instead used the default *,+. Is it possible that the syncrepl is conflicting with the built-in configuration for updating some of the hidden attributes ? I'm going to try to prove that by not specifying the hidden attributes will not cause my problem. (namely entry*)
I'm kind of at a loss now why it happens
---
cn=Subschema 20080715183635Z cn=manager,dc=nitle,dc=org FALSE b27c9922-e6e8-102c-8813-1b80b3c961ad uid=trogers@nitle.org,ou=guest,dc=nitle,dc=org 20080715183635.158002Z#000000#002#000000 cn=manager,dc=nitle,dc=org 20080715183635Z 10687 trogers@nitle.org Rogers /dev/null 10 Tommy Rogers top pwdPolicyChecker posixAccount person organizationalPerson inetOrgPerson eduPerson
On Jul 15, 2008, at 11:12 AM, Chris G. Sellers wrote:
I have an Multimaster/mirrormode replication that has worked for months.
Someone put some crappy data into the LDAP and then it crashed.
I've spent weeks cleaning up the data, thinking that was causing my replication to crash and core dump one of my two LDAP servers
I have cleaned up the data, loaded all the data from server1 to server2 and turned on the replication again, but I still get core dumps on server2. (server1 never has a problem)
I'm not sure where to go from here. Any suggestions or anyone else who came across the same problem. Below are some log and config entries. Host OS is Solaris10 on server1 and OpenSolaris on server2. (I have three other openLDAP servers running two with the same replication so I'm somewhat experienced with getting this to work so I'm thinking it's a strange problem I hope someone has run across)
log (server2):
Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 592946 local4.debug] <= root access granted Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 384072 local4.debug] => access_allowed: search access granted by manage(=mwrscxd) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 923158 local4.debug] => access_allowed: search access to "cn=manager,dc=nitle,dc=org" "obj ectClass" requested Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 592946 local4.debug] <= root access granted Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 384072 local4.debug] => access_allowed: search access granted by manage(=mwrscxd) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 525403 local4.debug] dn_callback : new entry is older than ours cn=manager,dc=nitle,dc=org ours 20080702134355.493573Z#000000#002#000000, new 20080107224745.105385Z#000000#002#000000 Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 819441 local4.debug] syncrepl_entry: rid=010 entry unchanged, ignored (cn=manager,dc=nitle ,dc=org) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 977386 local4.debug] syncrepl_entry: rid=010 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 580501 local4.debug] syncrepl_entry: rid=010 inserted UUID c76c7c0c-57fb-102c-9216-63c463e 7d505 Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 923158 local4.debug] => access_allowed: search access to "dc=nitle,dc=org" "entry" request ed Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 592946 local4.debug] <= root access granted Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 384072 local4.debug] => access_allowed: search access granted by manage(=mwrscxd) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 565591 local4.debug] syncrepl_entry: rid=010 be_search (0) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 709484 local4.debug] syncrepl_entry: rid=010 ou=guest,dc=nitle,dc=org Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 688566 local4.debug] syncrepl_entry: rid=010 be_add (68) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 923158 local4.debug] => access_allowed: search access to "ou=guest,dc=nitle,dc=org" "entry " requested Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 592946 local4.debug] <= root access granted Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 384072 local4.debug] => access_allowed: search access granted by manage(=mwrscxd) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 923158 local4.debug] => access_allowed: search access to "ou=guest,dc=nitle,dc=org" "objectClass" requested Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 592946 local4.debug] <= root access granted Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 384072 local4.debug] => access_allowed: search access granted by manage(=mwrscxd) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 525403 local4.debug] dn_callback : new entry is older than ours ou=guest,dc=nitle,dc=org ours 20080715143748.768257Z#000000#002#000000, new 20080115212254.445224Z#000000#001#000000 Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 819441 local4.debug] syncrepl_entry: rid=010 entry unchanged, ignored (ou=guest,dc=nitle,dc=org) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 977386 local4.debug] syncrepl_entry: rid=010 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 580501 local4.debug] syncrepl_entry: rid=010 inserted UUID 3a055df6-54c8-102c-9c74-3bd710846f22 Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 923158 local4.debug] => access_allowed: search access to "dc=nitle,dc=org" "entry" requested Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 592946 local4.debug] <= root access granted Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 384072 local4.debug] => access_allowed: search access granted by manage(=mwrscxd) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 565591 local4.debug] syncrepl_entry: rid=010 be_search (0) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 709484 local4.debug] syncrepl_entry: rid=010 uid=jbeckelm@coe.edu,ou=guest,dc=nitle,dc=org Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 923158 local4.debug] => access_allowed: search access to "dc=nitle,dc=org" "entry" requested Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 592946 local4.debug] <= root access granted Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 384072 local4.debug] => access_allowed: search access granted by manage(=mwrscxd) (** CRASHES HERE EVERY TIME **)
conf(server2):
syncrepl rid=010 provider=ldap://ldap1.site.org:389 binddn="cn=mirroracct,ou=replication,dc=nitle,dc=org" bindmethod=simple credentials=*** searchbase="dc=nitle,dc=org" type=refreshAndPersist scope=sub interval=00:00:00:10 retry="15 5 300 +" timeout=1 schemachecking=off starttls=yes
syncrepl rid=011 provider=ldap://ldap2.site.org:389 binddn="cn=mirroracct,ou=replication,dc=nitle,dc=org" bindmethod=simple credentials=*** searchbase="dc=nitle,dc=org" type=refreshAndPersist schemachecking=off scope=sub interval=00:00:00:10 retry="15 5 300 +" timeout=1 starttls=yes
overlay syncprov serverID 2 mirrormode true
Thanks in advance!
Sellers
++++++++++++++++++++++++++++++++++++++ Chris G. Sellers | Internet Engineer | NITLE 734.661.2318 | chris.sellers@nitle.org Jabber: csellers@nitle.org | AIM: imthewherd
++++++++++++++++++++++++++++++++++++++ Chris G. Sellers | Internet Engineer | NITLE 734.661.2318 | chris.sellers@nitle.org Jabber: csellers@nitle.org | AIM: imthewherd
Nope, that didn't seem to impact it (as some of you probably were about to say).
I do notice that after it crashes a few times my dc=nitle,dc=org gets clobbered and becomes objectClass=glue instead of objectClass=dcObject - which renders the tree useless.
I'll keep digging
Sellers
On Jul 15, 2008, at 2:42 PM, Chris G. Sellers wrote:
Follow-up.
I'm rebuilding the servers and started from scratch.
I was able to get replication working just as it did before, but if I add an account like the one below to either server1 or server2, the other server crashes when it replicates. I get notices about it trying to insert UUID and then it crashes.
If memory serves me right, this problem started happening shortly after I changed my syncrepl statement to not include specific attributes, and instead used the default *,+. Is it possible that the syncrepl is conflicting with the built-in configuration for updating some of the hidden attributes ? I'm going to try to prove that by not specifying the hidden attributes will not cause my problem. (namely entry*)
I'm kind of at a loss now why it happens
cn=Subschema 20080715183635Z cn=manager,dc=nitle,dc=org FALSE b27c9922-e6e8-102c-8813-1b80b3c961ad uid=trogers@nitle.org,ou=guest,dc=nitle,dc=org 20080715183635.158002Z#000000#002#000000 cn=manager,dc=nitle,dc=org 20080715183635Z 10687 trogers@nitle.org Rogers /dev/null 10 Tommy Rogers top pwdPolicyChecker posixAccount person organizationalPerson inetOrgPerson eduPerson
On Jul 15, 2008, at 11:12 AM, Chris G. Sellers wrote:
I have an Multimaster/mirrormode replication that has worked for months.
Someone put some crappy data into the LDAP and then it crashed.
I've spent weeks cleaning up the data, thinking that was causing my replication to crash and core dump one of my two LDAP servers
I have cleaned up the data, loaded all the data from server1 to server2 and turned on the replication again, but I still get core dumps on server2. (server1 never has a problem)
I'm not sure where to go from here. Any suggestions or anyone else who came across the same problem. Below are some log and config entries. Host OS is Solaris10 on server1 and OpenSolaris on server2. (I have three other openLDAP servers running two with the same replication so I'm somewhat experienced with getting this to work so I'm thinking it's a strange problem I hope someone has run across)
log (server2):
Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 592946 local4.debug] <= root access granted Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 384072 local4.debug] => access_allowed: search access granted by manage(=mwrscxd) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 923158 local4.debug] => access_allowed: search access to "cn=manager,dc=nitle,dc=org" "obj ectClass" requested Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 592946 local4.debug] <= root access granted Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 384072 local4.debug] => access_allowed: search access granted by manage(=mwrscxd) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 525403 local4.debug] dn_callback : new entry is older than ours cn=manager,dc=nitle,dc=org ours 20080702134355.493573Z#000000#002#000000, new 20080107224745.105385Z#000000#002#000000 Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 819441 local4.debug] syncrepl_entry: rid=010 entry unchanged, ignored (cn=manager,dc=nitle ,dc=org) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 977386 local4.debug] syncrepl_entry: rid=010 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 580501 local4.debug] syncrepl_entry: rid=010 inserted UUID c76c7c0c-57fb-102c-9216-63c463e 7d505 Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 923158 local4.debug] => access_allowed: search access to "dc=nitle,dc=org" "entry" request ed Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 592946 local4.debug] <= root access granted Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 384072 local4.debug] => access_allowed: search access granted by manage(=mwrscxd) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 565591 local4.debug] syncrepl_entry: rid=010 be_search (0) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 709484 local4.debug] syncrepl_entry: rid=010 ou=guest,dc=nitle,dc=org Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 688566 local4.debug] syncrepl_entry: rid=010 be_add (68) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 923158 local4.debug] => access_allowed: search access to "ou=guest,dc=nitle,dc=org" "entry " requested Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 592946 local4.debug] <= root access granted Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 384072 local4.debug] => access_allowed: search access granted by manage(=mwrscxd) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 923158 local4.debug] => access_allowed: search access to "ou=guest,dc=nitle,dc=org" "objectClass" requested Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 592946 local4.debug] <= root access granted Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 384072 local4.debug] => access_allowed: search access granted by manage(=mwrscxd) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 525403 local4.debug] dn_callback : new entry is older than ours ou=guest,dc=nitle,dc=org ours 20080715143748.768257Z#000000#002#000000, new 20080115212254.445224Z#000000#001#000000 Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 819441 local4.debug] syncrepl_entry: rid=010 entry unchanged, ignored (ou=guest,dc=nitle,dc=org) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 977386 local4.debug] syncrepl_entry: rid=010 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 580501 local4.debug] syncrepl_entry: rid=010 inserted UUID 3a055df6-54c8-102c-9c74-3bd710846f22 Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 923158 local4.debug] => access_allowed: search access to "dc=nitle,dc=org" "entry" requested Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 592946 local4.debug] <= root access granted Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 384072 local4.debug] => access_allowed: search access granted by manage(=mwrscxd) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 565591 local4.debug] syncrepl_entry: rid=010 be_search (0) Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 709484 local4.debug] syncrepl_entry: rid=010 uid=jbeckelm@coe.edu,ou=guest,dc=nitle,dc=org Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 923158 local4.debug] => access_allowed: search access to "dc=nitle,dc=org" "entry" requested Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 592946 local4.debug] <= root access granted Jul 15 15:02:50 jy1nitle11.nitle.org ldap2[13468]: [ID 384072 local4.debug] => access_allowed: search access granted by manage(=mwrscxd) (** CRASHES HERE EVERY TIME **)
conf(server2):
syncrepl rid=010 provider=ldap://ldap1.site.org:389 binddn="cn=mirroracct,ou=replication,dc=nitle,dc=org" bindmethod=simple credentials=*** searchbase="dc=nitle,dc=org" type=refreshAndPersist scope=sub interval=00:00:00:10 retry="15 5 300 +" timeout=1 schemachecking=off starttls=yes
syncrepl rid=011 provider=ldap://ldap2.site.org:389 binddn="cn=mirroracct,ou=replication,dc=nitle,dc=org" bindmethod=simple credentials=*** searchbase="dc=nitle,dc=org" type=refreshAndPersist schemachecking=off scope=sub interval=00:00:00:10 retry="15 5 300 +" timeout=1 starttls=yes
overlay syncprov serverID 2 mirrormode true
Thanks in advance!
Sellers
++++++++++++++++++++++++++++++++++++++ Chris G. Sellers | Internet Engineer | NITLE 734.661.2318 | chris.sellers@nitle.org Jabber: csellers@nitle.org | AIM: imthewherd
++++++++++++++++++++++++++++++++++++++ Chris G. Sellers | Internet Engineer | NITLE 734.661.2318 | chris.sellers@nitle.org Jabber: csellers@nitle.org | AIM: imthewherd
++++++++++++++++++++++++++++++++++++++ Chris G. Sellers | Internet Engineer | NITLE 734.661.2318 | chris.sellers@nitle.org Jabber: csellers@nitle.org | AIM: imthewherd
--On Tuesday, July 15, 2008 3:20 PM -0400 "Chris G. Sellers" Chris.Sellers@nitle.org wrote:
Nope, that didn't seem to impact it (as some of you probably were about to say).
I do notice that after it crashes a few times my dc=nitle,dc=org gets clobbered and becomes objectClass=glue instead of objectClass=dcObject - which renders the tree useless.
What release are you running?
You may want to try the OPENLDAP_REL_ENG_2_4 tree. 2.4.11 will hopefully be out this week.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration
I was able to stop the crashing, but I made a few changes and I need to regress to see what change was causing the crash. The stack trace idea may prove fruitful as well.
I'll report more tomorrow.
Thanks!
Sellers
On Jul 15, 2008, at 5:04 PM, Quanah Gibson-Mount wrote:
--On Tuesday, July 15, 2008 3:20 PM -0400 "Chris G. Sellers" <Chris.Sellers@nitle.org
wrote:
Nope, that didn't seem to impact it (as some of you probably were about to say).
I do notice that after it crashes a few times my dc=nitle,dc=org gets clobbered and becomes objectClass=glue instead of objectClass=dcObject - which renders the tree useless.
What release are you running?
You may want to try the OPENLDAP_REL_ENG_2_4 tree. 2.4.11 will hopefully be out this week.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc
Zimbra :: the leader in open source messaging and collaboration
Okay,
Follow-up for the good of the group. I regressed, and it seemed the errors started to trigger when I enabled indexing of the attributes of entryCSN and entryUUID.
I've kept those off now, along with the unique overlay for the attribute uidNumber because that seemed to be causing me problem too but that could be my bad data. I'm going to let it run this way for a while to see if it's stable.
I'll keep the thread up-to-date with details for the good of others. A trace may be in the future
Sellers
On Jul 15, 2008, at 5:04 PM, Quanah Gibson-Mount wrote:
--On Tuesday, July 15, 2008 3:20 PM -0400 "Chris G. Sellers" <Chris.Sellers@nitle.org
wrote:
Nope, that didn't seem to impact it (as some of you probably were about to say).
I do notice that after it crashes a few times my dc=nitle,dc=org gets clobbered and becomes objectClass=glue instead of objectClass=dcObject - which renders the tree useless.
What release are you running?
You may want to try the OPENLDAP_REL_ENG_2_4 tree. 2.4.11 will hopefully be out this week.
--Quanah
--
Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc
Zimbra :: the leader in open source messaging and collaboration
++++++++++++++++++++++++++++++++++++++ Chris G. Sellers | Internet Engineer | NITLE 734.661.2318 | chris.sellers@nitle.org Jabber: csellers@nitle.org | AIM: imthewherd
Chris G. Sellers wrote:
Okay,
Follow-up for the good of the group. I regressed, and it seemed the errors started to trigger when I enabled indexing of the attributes of entryCSN and entryUUID.
Did you run slapindex(8) with slapd(8) down after enabling those indexes?
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando@sys-net.it -----------------------------------
Ohhhh, good point. I did not do that. I gotta read more on indexing - thanks!!
Sellers
On Jul 16, 2008, at 12:49 PM, Pierangelo Masarati wrote:
Chris G. Sellers wrote:
Okay, Follow-up for the good of the group. I regressed, and it seemed the errors started to trigger when I enabled indexing of the attributes of entryCSN and entryUUID.
Did you run slapindex(8) with slapd(8) down after enabling those indexes?
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it
Office: +39 02 23998309 Mobile: +39 333 4963172 Email: ando@sys-net.it
++++++++++++++++++++++++++++++++++++++ Chris G. Sellers | Internet Engineer | NITLE 734.661.2318 | chris.sellers@nitle.org Jabber: csellers@nitle.org | AIM: imthewherd
Chris G. Sellers wrote:
Follow-up.
I'm rebuilding the servers and started from scratch.
I was able to get replication working just as it did before, but if I add an account like the one below to either server1 or server2, the other server crashes when it replicates. I get notices about it trying to insert UUID and then it crashes.
When something crashes, get a stack trace. Don't guess, and don't make us guess.
openldap-software@openldap.org
-
Chris G. Sellers -
Chris G. Sellers
-
Howard Chu -
Pierangelo Masarati -
Quanah Gibson-Mount