[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.
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/
>
>