> Full_Name: Jon C. Kidder > Version: 2.4.30 > OS: rhel 5.0 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (167.239.77.30) > > > Gentlemen, I need some help. I've been working on a problem for a couple > of > weeks and I can't seem to find a solution. I have encountered at least one > bug > and possibly two. > > I am building a new directory for my company using OpenLDAP 2.4.30 and BDB > 5.3.15. I am trying to pull in records from a foreign directory and map > them > into my directory. All of the foreign records are proxied into 3 child > nodes of > my directory. I am able to do this successfully using back-ldif and > overlay-rwm. > The problem I am encountering is that I have setup multi-master > replication of > the entire new directory with a filter to exclude the proxied nodes > because each > of my directory servers independently proxies those nodes. When the > replication > starts syncrepl causes an ABEND on every node that attempts replication. I > have > discovered that the ABEND occurs because my filter does not work and > syncrepl is > trying to replicate the proxied records. I have also discovered that my > filter > is not working because rwm-suffixmassage does not appear to be rewriting > the > entryDN of my proxied records. If my entryDN problem is configuration > related I > could use some help figuring it out. I am still submitting this as a bug > because > even if the entryDN problem is not a bug syncrepl should detect the > replication/proxy conflict and abort the replication gracefully rather > than > ABEND the directory server. > > I love the work the OpenLDAP team is doing. I am a very strong advocate of > open > source products at my company. I would love to take a deep dive into the > code > and resolve this issue myself but unfortunately can not. I am an > administrator/operator by day and a single parent of 6 year old triplet > boys by > night. I am not afforded as many opportunities to exercise my development > skills > as I would like. Any assistance the OpenLDAP team can render would be > greatly > appreciated. I can try to build a complete test suite that will allow > recreation/testing of these 2 issues if needed. > > Sample ldapsearch result showing inconsistent DN rewrite (DN is rewritten > but > entryDN is not): > > /appl/openldap/bin/ldapsearch -x -D "cn=Directory > Manager,dc=Global,dc=aep,dc=com" -y $HOME/buildpwd -s sub -b > 'dc=Global,dc=aep,dc=com' '(cn=s012235)' '+' > # extended LDIF > # > # LDAPv3 > # base <dc=Global,dc=aep,dc=com> with scope subtree > # filter: (cn=s012235) > # requesting: + > # > > # s012235, Information Technology, AD_Corp, Employees, Users, > Global.aep.com > dn: cn=s012235,ou=Information > Technology,ou=AD_Corp,ou=Employees,ou=Users,dc=G > lobal,dc=aep,dc=com > entryDN: cn=s012235,ou=Information Technology,ou=LOB > Users,dc=corp,dc=aepsc,dc > =com > subschemaSubentry: cn=Subschema
slapo-rwm(5) explicitly skips entryDN (and removes it from attributes returned by searches) because entryDN is (re-)added by the frontend. Of course both events appear to be erroneous; unless they result from a misconfiguration (and in any case for the sigsegv) they need to be addressed. I suggest you create a minimal setup that shows the problem (either one for each problem, or one for both) and upload it according to instructions here <http://www.openldap.org/devel/contributing.html#submitting>. Attaching it to an email is not an option because the ITS does not handle attachments well. p.
