I looked but couldn't find a match to this issue, so was wondering if anyone else has seen something like it or can tell what might be wrong in my configuration. Thanks in advance!
I'm using OpenLDAP version 2.4.21-47.1 (here is the relevant output from "rpm -qa | grep ldap" on my server):
openldap2-client-2.4.21-51.1 openldap2-2.4.21-47.1 openldap2-back-meta-2.4.21-51.1
I'm trying to get Multi-master replication working between 2 servers. In my testing, I have discovered that when I try to reset the server (remove the configuration and start again) it crashes when trying to remove the olcOverlay={0}syncprov,olcDatabase={0}config,cn=config entry in the cn=config tree. I attached a screen shot of the output from tracing with slapd -d -1 when the fault happened in the attached file called * segFaultOutput.bmp.*
If I restart the server, I can run the test again (which configures the olcOverlay={0}syncprov entry and then removes it) and it will work the first time, but if I run it a second time it will crash.
Here is the configuration from the ldif files in /etc/openldap/slapd.d
*cn=config.ldif:*
dn: cn=config objectClass: olcGlobal cn: config structuralObjectClass: olcGlobal entryUUID: 8d35d270-286b-102f-998d-8313efe688a2 creatorsName: cn=config createTimestamp: 20100720165657Z entryCSN: 20100720165733.055688Z#000000#00c#000000 modifiersName: cn=manager,cn=config modifyTimestamp: 20100720165733Z contextCSN: 20100720165732.317584Z#000000#000#000000 contextCSN: 20100720165733.125549Z#000000#00c#000000
*cn=schema.ldif*:
dn: cn=schema objectClass: olcSchemaConfig cn: schema structuralObjectClass: olcSchemaConfig entryUUID: 8d35e49a-286b-102f-998e-8313efe688a2 creatorsName: cn=config createTimestamp: 20100720165657Z entryCSN: 20100720165657.613177Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20100720165657Z
*olcDatabase={0}config.ldif*:
dn: olcDatabase={0}config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by * none olcRootDN: cn=manager,cn=config olcRootPW:: Y29uZmln structuralObjectClass: olcDatabaseConfig entryUUID: 8d37bc20-286b-102f-9993-8313efe688a2 creatorsName: cn=config createTimestamp: 20100720165657Z entryCSN: 20100720165657.625245Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20100720165657Z
*olcDatabase={1}bdb.ldif:*
dn: olcDatabase={1}bdb objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {1}bdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=phoenix,dc=com olcRootDN: cn=manager,dc=phoenix,dc=com olcRootPW:: c2VjcmV0 structuralObjectClass: olcBdbConfig entryUUID: 8d37ea88-286b-102f-9995-8313efe688a2 creatorsName: cn=manager,cn=config createTimestamp: 20100720165657Z entryCSN: 20100720165733.125549Z#000000#00c#000000 modifiersName: cn=manager,cn=config modifyTimestamp: 20100720165733Z
*olcDatabase={-1}frontend.ldif:*
dn: olcDatabase={-1}frontend objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 0 olcReadOnly: FALSE olcSchemaDN: cn=Subschema olcSyncUseSubentry: FALSE olcMonitoring: FALSE structuralObjectClass: olcDatabaseConfig entryUUID: 8d37c1a2-286b-102f-9994-8313efe688a2 creatorsName: cn=config createTimestamp: 20100720165657Z entryCSN: 20100720165657.625397Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20100720165657Z
the cn=schema directory has the following (I'm not going to paste the contents of these files):
cn={0}core.ldif cn={1}cosine.ldif cn={2}inetorgperson.ldif cn={3}nis.ldif
