On Apr 5, 2008, at 1:15 PM, Quanah Gibson-Mount wrote:
after some testing and playing around with Net::LDAP::LDIF and the
back_perl "database" from OpenLDAP I found that some entries will
not be
accepted by the latter if I use an entry (or a list of them)
produced by
the LDIF module. The cause of this is the "CR" at the beginning of
each
entry/DN and the missing empty line at the end.
I know that this doesn't break RFC2849 and so is not the problem of
Net::LDAP::LDIF. But for compatibility reasons I suggest to print
the
"\n" character not before but after each entry. This produces the
same
output as by ldapsearch and will be accepted by the perl backend
from
OpenLDAP.
Anyone see any issue with doing this?
Just to note, the perl backend of OpenLDAP is RFC compliant.
See Uwe's ITS at <http://www.openldap.org/its/index.cgi/?
findid=5456> and the follow up.
It looks like this is due to a bug in Net::LDAP::LDIF.
I disagree. Nowhere in the spec does it state that there must be a
blank line following each entry, which seem to be what Uwe thinks.
The RFC states that each entry is proceeded by 1 or more SEP and that
there does not have to be, but could be, blank lines after the
version line
I believe that Net::LDAP::LDIF is OK as per the RFC
Using 00-in.ldif from the perl-ldap distribution
use Net::LDAP::LDIF;
$r = Net::LDAP::LDIF->new("data/00-in.ldif","r");$w = Net::LDAP::LDIF-
>new(\*STDOUT,"w");$w->version(1);
$w->write_entry($r->read_entry);
Gives what is between the attched as output, which I think is
perfectly valid
version: 1
dn: o=University of Michigan, c=US
objectclass: top
objectclass: organization
objectclass: domainRelatedObject
objectclass: quipuObject
objectclass: quipuNonLeafObject
l: Ann Arbor, Michigan
st: Michigan
streetaddress: 535 West William St.
o: University of Michigan
o: UMICH
o: UM
o: U-M
o: U of M
description: The University of Michigan at Ann Arbor
postaladdress: University of Michigan $ 535 W. William St. $ Ann Arbor, MI 481
09 $ USpostalcode: 48109
telephonenumber: +1 313 764-1817
lastmodifiedtime: 930106182800Z
lastmodifiedby: cn=manager, o=university of michigan, c=US
associateddomain: umich.edu