Hope this is the right list for this, haven't been lurking here
previously so I don't have a feel for things yet.
I'm upgrading our OpenLDAP servers to use directory based configuration
under Ubuntu/Lucid and am having some problems including the provided
Cosine and iNetOrgPerson schemas.
It appears that if I symlink the LDIF files from /etc/ldap/schema/ into
/etc/ldap/slapd.d/cn=config/cn=schema/ slapd will not start.
Running slapd in debug mode gives me the following output:
ldif_read_file: read entry file:
=> str2entry: "# RFC1274: Cosine and Internet X.500 schema
<snip contents of the LDIF file being read in>
<<< dnPrettyNormal: <cn=cosine,cn=schema,cn=config>,
<= str2entry(cn=cosine,cn=schema,cn=config) -> 0xb9124344
=> access_allowed: search access to
<= root access granted
=> access_allowed: search access granted by manage(=mwrscxd)
<= test_filter 6
DN="cn=cosine,cn=schema,cn=config,cn=schema,cn=config" not child of
config error processing cn=cosine,cn=schema,cn=config,cn=schema,cn=config:
send_ldap_result: conn=-1 op=0 p=0
send_ldap_result: err=32 matched="" text=""
The DN specified in the LDIF file is as follows:
But it looks like when it's reading in the file, it's postpending
cn=schema,cn=config (presumably from the configuration directory path),
as opposed to using the fully qualified DN.
Is there a way to fix this? I'm using packages to deploy software
configurations, and it doesn't make sense for us to inject this schema
with ldapadd (what seems to be the prescribed way) of adding schema to
get around this DN problem (and handing adding/removing it when upstream
updates the defintions - however infrequent/unlikely this is).
We also roll out our own schema definitions, but these have been
converted to LDIF and it's no big deal to have the DN: line set to
whatever will make slapd happy.
I hope this makes sense and that someone is able to help me understand
directory based configuration a little better.
T: +61 (08) 6364 4880
F: +61 (08) 6364 4881