[email protected] wrote: > [email protected] wrote: >> Full_Name: Matthew Hardin >> Version: 2.4.13 >> OS: Red Hat Enterprise Linux 4 i686 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (74.38.114.185) >> >> >> Hi All, >> >> We have an LDAP server that is proxying for Active Directory. Periodically >> slapd >> throws an assertion: >> >> slapd: [....]/ldap24/servers/slapd/schema_init.c:524: octetStringIndexer: >> Assertion `i> 0' failed. >> /etc/init.d/solserver: line 192: 6620 Aborted (core dumped) >> "$EXEC_DIR/$PROC" $ARGS -h "$HOST_LIST" $EXTRA_SLAPD_ARGS >> >> Howard Chu's examination of the core file showed that the remote AD server >> returned a member attribute with no values. This is only legal in LDAP when a >> client sets the attrsonly flag in its search request, and that flag was not >> set >> here. >> >> The indexer rightly asserts because pcache handed it an attribute with >> nothing >> to >> index. >> >> I'm not sure what the correct thing to do might be here, but it should not >> take >> down the slapd. > > The entry should not be cached, IMHO.
Perhaps. But then the entire query cannot be cached, because its result set would be known to be incomplete. There's something more going on here, because the query in question was searching for (&(objectclass=posixgroup)(memberUid=foo)(member=foo-DN)). There was no memberUid at all in the returned entry, so it must have matched on member, so the member attr should not have been empty. AD is flaky enough already, but it's possible that back-meta may have dropped the attr values during rewriting, etc. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
