[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Problems reading schema information using ldapsearch


thanks alot!!

Placing acl for dn: "" and dn: "cn=subschema" fixed my problems.


Buchan Milne schrieb:
On Tuesday 11 July 2006 10:14, Daniel Eckstein wrote:
Dear listmember,

on RHEL4, openldap 2.3.24 Iam trying to read the schema information
using ldapsearch.

Iam using the standard schema core.schema, cosine.schema,
inetorgperson.schema and a
self made schema extension. The ldap is running happily and I set up a
synchronisation with other ldap "slaves". The ldap is fed with around
300k entries.

When Iam trying to

ldapsearch -D"mymanager-dn" -x -w mypass -b cn=schema -s base
ldapsearch -D"mymanager-dn" -x -w mypass -b cn=schema -"(objectclass=*)"
ldapsearch -D"mymanager-dn" -x -w mypass -b cn=subschema -s base
ldapsearch -D"mymanager-dn" -x -w mypass -b cn=subschema -s base
ldapsearch -D"mymanager-dn" -x -w mypass -b cn=subschema "(objectclass=*)"
ldapsearch -D"mymanager-dn" -x -w mypass -b cn=subschema "+"
ldapsearch -D"mymanager-dn" -x -w mypass -b cn=subschema -s base "+"

The above command should have worked, assuming you have some ACLs providing access to the cn=Subschema tree. Since there is no real database here (or, at least it's not the one you've set rootdn for) your rootdn from your "real" database doesn't get rootdn, you will need explicit ACLs.

I generally provide read access to the cn=Subschema, to allow schema-aware tools to work without requiring privileges, something like this should do:

# The root DIT should be accessible to all clients
access to dn.exact=""
        by * read

# So should the schema
access to dn.subtree="cn=Subschema"
        by * read