Re: (ITS#7258) Possible suffixmassage and syncrepl bug

[masarati@aero.polimi.it]

> 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.