[EMAIL PROTECTED] wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > If a referral object's "ref" DN differs from the entry DN, and > you update a subordinate of the referral object, the DN part > of the referral from back-bdb is wrong. > > bash$ cat ref.ldif > dn: o=we > o: we > ref: ldap://elsewhere/o=they > objectClass: referral > objectClass: extensibleObject > > dn: cn=me,o=we > cn: me > objectClass: organizationalRole > > bash$ ldapadd ...< ref.ldif > adding new entry "o=we" > > adding new entry "cn=me,o=we" > ldap_add: Referral (10) > matched DN: o=we > referrals: > ldap://elsewhere/cn=me,o=we > > It works if NULL is changed to&e->e_name at back-bdb/referral.c line 96: > > rs->sr_ref = referral_rewrite( ref, NULL, > &op->o_req_dn, LDAP_SCOPE_DEFAULT ); > > I don't quite understand that function though: > Why does it use default_referral (slapd.conf 'referral')? That is for > use when no local backend database handles the operation, which I would > think means no database's be_chk_referrals() gets be called. And indeed > the function uses it if > !be_issuffix( op->o_bd,&op->o_req_ndn ) > which looks to me like a test for whether this function is _not_ to be > called for this database.
I've never understood that function either. ;) It seems completely unnecessary, since the individual operations' code also does referral checks. Can you try testing with be_chk_referrals NULL'd out? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
