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

Re: ldap backend

Stephan Duehr wrote:

Pierangelo Masarati said:


Stephan Duehr wrote:



Hi all,

I'm trying to use the ldap backend with the following scenario:
one slapd instance which already works properly using syncrepl is
listening on localhost port 10389.

A second slapd instance using the ldap backend using this config:

modulepath      /usr/lib/openldap/modules
moduleload    back_ldap.la
# moduleload    back_meta.la
# moduleload    back_monitor.la
# moduleload    back_perl.la

loglevel -1

database        ldap
suffix          "o=My Test,c=de"
uri             "ldap://localhost:10389/";
binddn          "cn=replica,o=My Test,c=de"
bindpw          "secret"
lastmod         off

The problem is that i get the following error message:
Dec  7 16:09:48 server1 slapd[24458]: /etc/openldap/slapd-ldap.conf: line
11: suffix DN is invalid
Dec  7 16:09:48 server1 slapd[24458]: slapd shutdown: freeing system
resources.
Dec  7 16:09:48 server1 slapd[24458]: slapd stopped.

I also tried suffixes without spaces, doesn't matter.

How can I find out what's wrong here?




From the line number in the error message, it appears that the above is
your entire slapd.conf, not just a portion of it. Did you load the
schema files containing the definitions of "o" and "c"? You will need
as much schema as you can (e.g. the same as of the remote host)
otherwise the unknown attributeTypes and objectClasses will be (more or
less silently) dropped by the ldap backend.



Thanks, it works if I include at least core.schema. I find the error
message a bit misleading. And the documentation and man page does not
show a working example nor seems to mention this clearly. The way it
should be configured is to keep the schema in sync with the remote LDAP
server, which is easy if it's OpenLDAP, too.



Well, this has very little to do with back-ldap itself. Slapd is strongly schema-aware and schema-oriented, so it is implied that all LDAP stuff that's passing thru it is checked, prettified, normalized and eventually rejcted if it doesn't comply. I agree the error message should indicate that the error is an unknown attribute type, but I'm afraid that's too deep into the DN checking routines to be usable at that level. You may file an ITS for a feature enhancement.
To keep the schema in sync, in principle, is always "simple", since the remote host should publish its own schema in the subschemaSubentry;all one needs to do is download it (by reading the subschemaSubentry), stuff the items slapd doesn't support as builtin into a file, and include it. Unfortunately, some existing DSAs don't; others use extended schema items that cannot be directly used by slapd. I guess one feature we could add to back-ldap is the capability to download the schema (or the required bits of it) from the remote server at startup, if available, and add the missing items to the internal schema structure.

p.




   SysNet - via Dossi,8 27100 Pavia Tel: +390382573859 Fax: +390382476497