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
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...
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:
ldapsearch -H ldapi://%2fdata%2fsamba%2fsamba4%2fsvn%2fsource%2fst%2fdc% 2fprivate%2fldap%2fldapi -x cn=administrators* and
ldapsearch -H ldapi://%2fdata%2fsamba%2fsamba4%2fsvn%2fsource%2fst%2fdc% 2fprivate%2fldap%2fldapi -x cn=administrators
Andrew Bartlett
Andrew Bartlett wrote:
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:
There's something very odd in your configuration.
database hdb suffix CN=Schema,CN=Configuration,DC=samba,DC=example,DC=com directory /home/software/SAMBA_4_0/source/st/dc/private/ldap/db/schema index objectClass eq index samAccountName eq index name eq index objectCategory eq index lDAPDisplayName eq index subClassOf eq #index cn eq <<
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.
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.
On Sat, 2008-01-05 at 22:37 -0800, Howard Chu wrote:
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.
Ahh, yes. I no longer use 'name' (instead adding a new attribute samba4RDN to hold the relative distinguished name), so I shall move the index to that attribute.
Andrew Bartlett
openldap-technical@openldap.org
-
Andrew Bartlett -
Howard Chu