> [email protected] 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/ > >
