uw@o3si.de wrote:

Full_Name: Uwe Werler Version: 2.3.32 OS: SLES10 SP1 Kernel 2.6.16.54-0.2.3-xen URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (155.56.68.221)

The database backend "back_perl" expects LDIF entries beginning with "dn:" and ending with an empty line. RFC2849 only describes that an entry is everything except an empty line and a line not beginning (after a CR/LF) with a single white space character.

Wrong. The grammar in RFC2849 quite explicitly states:

ldif-file = ldif-content / ldif-changes

ldif-content = version-spec 1*(1*SEP ldif-attrval-record)

ldif-changes = version-spec 1*(1*SEP ldif-change-record)

ldif-attrval-record = dn-spec SEP 1*attrval-spec

ldif-change-record = dn-spec SEP *control changerecord

That means an LDIF file must start with 0 or 1 version-specs, then a dn-spec. And, all records must end with LF or CR/LF.

After some testing with back_perl I noticed that the LDIF entries produced by the perl module Net::LDAP::LDIF were not acceptet because they are beginning with an empty line and ending only with a simple CR charakter.

This behavior breaks RFC2849. After changing LDIF.pm from that module to produce the CR after the entry back_perl accepts this entries too.

IMHO this is a misbehavior so I'm very glad if You'll take a look at this issue.

Apparently it Net::LDAP::LDIF is broken. Since that is not a piece of OpenLDAP Software I don't see what we can do about it. This ITS will be closed. Contact the author of Net::LDAP::LDIF to pursue this further.