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.
I'd concur, but syncprov_operational steps in even for regular operations
(correctly, because a client might want to see the contextCSN), and
duplicates the entry unnecessarily, as contextCSN could be appended to
sr_operational_attrs, unless it needs to be in the entry for some reason.
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/