ando@sys-net.it wrote:
mhardin@symas.com 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.