Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I'm trying to load the password policy overlay but i'm having the following error

ldapadd  -Wx -D "cn=Manager,cn=config"  -f overlay.ldif 
Enter LDAP Password: 
adding new entry "olcOverlay=ppolicy,olcDatabase={0}bdb,cn=config"
ldap_add: No such object (32)
    matched DN: cn=config

This is the content of the file

dn: olcOverlay=ppolicy,olcDatabase={0}bdb,cn=config
olcOverlay: ppolicy
objectClass: olcOverlayConfig
objectClass: olcPPolicyConfig
olcPPolicyDefault: cn=default,ou=Policies,dc=site,dc=com
olcPPolicyHashCleartext: TRUE
olcPPolicyUseLockout: FALSE

In the log I found:

config_add_internal: DN="olcOverlay=ppolicy,olcDatabase={0}bdb,cn=config" not child of DN="cn=config"

I'm using centos 6.3 and openldap-servers-2.4.23-26.el6_3.2.x86_64

share|improve this question

2 Answers 2

Some of the records in the cn=config database of OpenLDAP use number prefixes ({0}, {1}, etc). So when you go to modify something in the cn=config database, you have to make sure you're using the right DN (Distinguished Name: the path to the record). In OpenLDAP when using cn=config, the first olcDatabase entry is usually the config database itself (olcDatabase={0}config,cn=config). On my specific system, my main database is olcDatabase={1}hdb,cn=config.

If you don't know the DN of the olcDatabase you need to modify, the only way to know is to do a search and look through the results.


As for what those numbers (the {0} bit) are, they serve 2 purposes.

  1. They allow you to have multiple entries of the same name.
    You could have 2 olcDatabase=bdb databases, in which you'd have a problem as you cant have 2 entries with the same DN.
  2. They allow ordering.
    The LDAP protocol does not care about order. But you can prefix RDNs with {X} to allow ordering. In this specific case, I can't think of any reason off hand why the databases need to be ordered. But there are other critical use cases, such as in cn=schema,cn=config. In cn=schema, a schema can define an object class which depends on an attribute from a previous schema. As such the schemes must be loaded in order.
share|improve this answer
    
Re: ordering - backend databases have historically been identified by the numeric index (implicit by the order of their definition) mostly for backup/restore purposes. Also, when multiple databases/suffixes are used, the subordinates must be defined before their superiors (parents). –  mr.spuratic Oct 18 at 18:38

olcDatabase={0}bdb,cn=config

needs to be changed to

olcDatabase={2}bdb,cn=config

share|improve this answer
1  
Thanks , that did the trick, but do not understand the difference between {0} and {2} –  user27238 Feb 13 '13 at 12:11

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.