[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#6549) test043 hasSubordinates attribute inconsistencies
> 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/
>
>
>