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

Indeed, syncprov_operational() is right: it duplicates the entry only if contextCSN is already present in the entry, and thus may need to be updated. What's wrong is back-bdb, which gives up when the entry does not have e_private set appropriately, while it could do more to find out about the entry's subordinates. This may explain why in some cases the attribute is present. This occurs whenever contextCSN is not already present in the entry. I'm preparing a fix for back-bdb.

p.

...

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/