masarati(a)aero.polimi.it wrote: > I just checked with HEAD and re24 (basically 2.4.22) on Linux (CentOS > 5.2, > for what it matters, and db-4.6.21, for what it matters), and it works > fine if you explicitly ask for hasSubordinates, while this specific attr > is not returned if you request '+'. The fact hasSubordinates does not > appear means that the appropriate backend operational attrs hook was not > called, or its value was ignored. Since hasSubordinates is a generated attribute, it would be filtered out on the consumer anyway. There's no reason to ever include it in replication traffic.

> After a quick check, I figured out that bdb_hasSubordinates is passed a > copy of the original entry, thus without bdb information, and > bdb_hasSubordinates bails out. Apparently, syncprov copies the entry > instead of putting operational attrs in rs_operational_attrs in > SlapReply. > > p. > >> Full_Name: Matt Hardin >> Version: 2.4.22 >> OS: Red Hat AS 4 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (74.38.117.141) >> >> >> In test043 the test database defines a root entry of dc=example,dc=com. >> For this >> entry, the results of the ldapsearch do not include the hasSubordinates >> attribute at all, in spite of the fact that the entry does have >> subordinates. >> Test043 passes, due to the fact that this attribute is missing from the >> root >> entry in both the provider and the consumer. >> >> Other entries with subordinates do include this attribute and its value >> is >> correct in all the cases I examined. >> >> Here is the snippet from tests/testrun/server1.flt: >> >> dn: dc=example,dc=com >> dc: example >> objectClass: organization >> objectClass: domainRelatedObject >> objectClass: dcObject >> l: Anytown, Michigan >> st: Michigan >> o: Example, Inc. >> o: EX >> o: Ex. >> description: The Example, Inc. at Anytown >> postalAddress: Example, Inc. $ 535 W. William St. $ Anytown, MI 48109 $ >> US >> telephoneNumber: +1 313 555 1817 >> associatedDomain: example.com >> structuralObjectClass: organization >> entryUUID: e2d47ecc-f24a-102e-90fb-9f641f00f9d2 >> creatorsName: cn=Manager,dc=example,dc=com >> createTimestamp: 20100512194705Z >> entryCSN: 20100512194705.076849Z#000000#000#000000 >> modifiersName: cn=Manager,dc=example,dc=com >> modifyTimestamp: 20100512194705Z >> contextCSN: 20100512194748.621773Z#000000#000#000000 >> entryDN: dc=example,dc=com >> subschemaSubentry: cn=Subschema >> >> The version of BDB in use here is 4.8.30, although I note this happens >> with >> earlier releases of BDB as well. >> >> Also of interest is the fact that this test fails on some platforms >> (e.g. >> Windows), because the provider slapd correctly reports >> hasSubordinates=TRUE, >> while the consumer omits the attribute entirely, in spite of the fact >> that >> subordinate entries do exist on the consumer. >> >> -Matt >> >> >> > > > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/