Got it! I read that you could have whatever you wanted as a rootdn for config as long as it was under "cn=config". My disconnect was I made my rootdn = 'cn=admin, dc=config" not "cn=admin, cn=config". Using dc, openldap rightly looks for the suffix specified however you don't specify a suffix for config. Doh!
Many thanks Antonio Alonso antonio.alonso@ericsson.com wrote: Hi !
In your "slapd.conf" you need to define a rootDN in the "database config" section:
---------------------------------------------------------------------------- database config #--- # rootdn can always read and write EVERYTHING! #--- rootdn "cn=manager,cn=config" rootpw secret -----------------------------------------------------------------------------
Binding with these credential you an access (read, modify) the "cn=config" database
BR / Antonio
--------------------------------- From: openldap-software-bounces+antonio.alonso=ericsson.com@OpenLDAP.org [mailto:openldap-software-bounces+antonio.alonso=ericsson.com@OpenLDAP.org] On Behalf Of Mike Johnston Sent: viernes, 25 de abril de 2008 12:27 To: openldap-software@openldap.org Subject: Re: Openldap 2.4 and the cn=config directory
Ah, makes perfect sense. I should be able to bind to cn=config and make standard LDAP searches and modifications while slapd is running correct?
If so, can someone provide a sample bind string and olcDatabase file for the cn=config? I can't seem to bind to the cn=config to make my modifications.
BTW, I can bind with no problems to my LDAP database in hdb.
TIA, Mike Howard Chu hyc@symas.com wrote: Mike Johnston wrote:
Hi, I used -f & -F options to build my cn=config from my slapd.conf file. Everything works however, I see a directory tree created and I got the impression from the Openldap 2.4 admin manual first page Chap 5 "the new style uses a slapd backend database to store the config". I assumed it meant a bdb/hdb backend database not an actual disk directory tree.
Obviously a poor assumption.
Can it use a hdb/bdb for the cn=config store?
No. Currently it is hardcoded to use back-ldif. While it may be possible to use different backends in the future, it's unlikely that back-bdb/hdb will ever be candidates for that purpose, since they require fairly complex configurations themselves. I.e., to avoid the chicken-and-egg problem of where to get the configuration info for the underlying backend, only extremely simple backends are suitable here.