Working on the OpenLDAP backend for Samba4, I'm wondering if this is expected:

Is 'cn' a special attribute in the OpenLDAP code? It seems that the builtin schema definition (or something else) requires that the 'cn' attribute be indexed with index cn eq Otherwise, searches for cn=foo fail, where cn=foo* succeeds...

I'm using current CVS, and trying to have Samba4 automatically generate configuration files for OpenLDAP, possibly based on the (AD) schema-data we will load into the directory. As such, knowing any (particularly other, similar) OpenLDAP-imposed constraints will be very useful, so that I can ensure these are met by the provision-backend script in Samba4. Thanks, Andrew Bartlett

On Mon, 2007-12-31 at 19:49 -0800, Howard Chu wrote: > Andrew Bartlett wrote: >> Working on the OpenLDAP backend for Samba4, I'm wondering if this is expected: > No, there's no special indexing requirements for any attributes. Indexing is > always optional. But of course, performance will suffer as DB sizes grow. It's > always recommended to index the "objectclass" attribute, since it's used so > frequently in internal searches as well as user searches, but nothing will > break without it. > >> Is 'cn' a special attribute in the OpenLDAP code? It seems that the >> builtin schema definition (or something else) requires that the 'cn' >> attribute be indexed with >> >> index cn eq >> >> Otherwise, searches for cn=foo fail, where cn=foo* succeeds... > Sounds like either a corrupt DB, or a bug. If you can provide a test case to > reproduce the problem, that'll help. More likely it's a misconfiguration... If you still have your Samba4 build around, then with current SVN try: TEST_LDAP=yes OPENLDAP_ROOT=/data/openldap/prefix make test with the patch attached to this mail, which simply removes the CN index. the provision will fail because it searches for cn= However, the database is setup, and slapd is still running, so you can prove it with:

>

Howard Chu wrote: > You have "index name eq" which is a supertype of cn. That means cn is going to > be indexed anyway. It could be that we have a bug here, not checking the > supertype's index. I'll look into that. There was a bug in HEAD due to the broken component matching support code. This bug doesn't occur in 2.4 or 2.3 since that code is already disabled in the releases. I've #if'd it out of HEAD as well. But in the meantime, you should rethink what you're indexing.