[Date Prev][Date Next]
Re: (ITS#6549) test043 hasSubordinates attribute inconsistencies
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.
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.
> Full_Name: Matt Hardin
> Version: 2.4.22
> OS: Red Hat AS 4
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (18.104.22.168)
> 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
> Test043 passes, due to the fact that this attribute is missing from the
> 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
> 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
> while the consumer omits the attribute entirely, in spite of the fact that
> subordinate entries do exist on the consumer.