Hi,
We have been running OpenLDAP 2.2.13 on RHEL4 for a few years without problems. We recently upgraded OpenLDAP to 2.4.11 to use the multi-master capability. After upgrade, we are having 2 problems with the new version.
1. We have an attribute c in the ou=People sub-tree. The value can be either US or CA. Now if we search "c=US" or "c=CA", we do not get any matches. But if we do "c=U*", it finds all the c=US entries. Same thing happens to c=C*.
2. LAM 2.5.0 (LDAP Account Manager) cannot browse the schema on the new server. It says "Unable to retrieve schema". LAM worked fine with OpenLDAP 2.2.13.
I would appreciate any information that would help us resolve the problem.
Thanks!
John
John Du jjohndu@gmail.com writes:
Hi,
We have been running OpenLDAP 2.2.13 on RHEL4 for a few years without problems. We recently upgraded OpenLDAP to 2.4.11 to use the multi-master capability. After upgrade, we are having 2 problems with the new version.
- We have an attribute c in the ou=People sub-tree. The value can
be either US or CA. Now if we search "c=US" or "c=CA", we do not get any matches. But if we do "c=U*", it finds all the c=US entries. Same thing happens to c=C*.
- LAM 2.5.0 (LDAP Account Manager) cannot browse the schema on the
new server. It says "Unable to retrieve schema". LAM worked fine with OpenLDAP 2.2.13.
I would appreciate any information that would help us resolve the problem.
Please provide some more information, i.e. configuration of indexes and access rules to cn=subschema, as well as examples of search strings.
-Dieter
Dieter Kluenter wrote:
John Du jjohndu@gmail.com writes:
Hi,
We have been running OpenLDAP 2.2.13 on RHEL4 for a few years without problems. We recently upgraded OpenLDAP to 2.4.11 to use the multi-master capability. After upgrade, we are having 2 problems with the new version.
- We have an attribute c in the ou=People sub-tree. The value can
be either US or CA. Now if we search "c=US" or "c=CA", we do not get any matches. But if we do "c=U*", it finds all the c=US entries. Same thing happens to c=C*.
- LAM 2.5.0 (LDAP Account Manager) cannot browse the schema on the
new server. It says "Unable to retrieve schema". LAM worked fine with OpenLDAP 2.2.13.
I would appreciate any information that would help us resolve the problem.
Please provide some more information, i.e. configuration of indexes and access rules to cn=subschema, as well as examples of search strings.
Thanks to all who have responded to my questions.
I fixed the two problems.
Problem one was fixed by adding an "access to dn.subtree="cn=SubSchema by * read".
Problem 2 was fixed by adding an index: "index c eq,sub"
I thought the root DN is not subject any access control rules but that does not seem to be the case. I do not understand why I have to add the index for the new server but not for the old one.
Anyways, thank you for your help.
-Dieter
John Du wrote:
I fixed the two problems.
Problem one was fixed by adding an "access to dn.subtree="cn=SubSchema by * read".
This should be sufficient since the subschema subentry is a single entry:
access to dn.base="cn=Subschema" by * read
I thought the root DN is not subject any access control rules but that does not seem to be the case.
Indeed no ACLs are applied when effectively binding as rootdn. What makes you think that this is not the case.
I do not understand why I have to add the index for the new server but not for the old one.
The problem is if you added an index directive to slapd.conf but did not re-index slapd looks into the index database file and the old entries are not there yet. So the entry is not returned as search result. This might make you think that access control prevents the entry from being returned.
Also be sure that all the database files have the right ownership/permissions when manually re-indexing them.
Ciao, Michael.
John Du wrote:
We have been running OpenLDAP 2.2.13 on RHEL4 for a few years without problems. We recently upgraded OpenLDAP to 2.4.11 to use the multi-master capability. After upgrade, we are having 2 problems with the new version.
There were many fixes to multi-master replication in recent releases. Please try first whether your problems are still in 2.4.16.
- We have an attribute c in the ou=People sub-tree. The value can be
either US or CA. Now if we search "c=US" or "c=CA", we do not get any matches. But if we do "c=U*", it finds all the c=US entries. Same thing happens to c=C*.
Did you change anything with your index configuration without re-indexing afterwards?
- LAM 2.5.0 (LDAP Account Manager) cannot browse the schema on the
new server. It says "Unable to retrieve schema". LAM worked fine with OpenLDAP 2.2.13.
ACLs set for subschema subentry?
Ciao, Michael.
John Du writes:
- We have an attribute c in the ou=People sub-tree. The value can be
either US or CA. Now if we search "c=US" or "c=CA", we do not get any matches. But if we do "c=U*", it finds all the c=US entries. Same thing happens to c=C*.
My guess: You added 'index c' to slapd.conf, but did not index your existing data. Stop slapd, run sbin/slapindex, restart slapd. Substring match of just one letter worked anyway because it does not use the index.
- LAM 2.5.0 (LDAP Account Manager) cannot browse the schema on the
new server. It says "Unable to retrieve schema". LAM worked fine with OpenLDAP 2.2.13.
No idea. I'd check the slapd log from loglevel 256 or 768. That's the default syslog level, or you could run slapd -d256 or -d768 ... to log to stderr. Note what requests LAM sends, and check the corresponding error code/description (err=... text=...) against RFC 4511, Appendix A.
openldap-software@openldap.org
-
Dieter Kluenter -
Hallvard B Furuseth -
John Du -
Michael Ströder