Net::LDAP and Net:LDAP::LDIF read & add problems

[Rick Greene]

I'm trying to read in a simple LDIF file to add an entry to my LDAP
server. Here is the basic routine (extraneous details omitted for
brevity and security):

$ldif = Net::LDAP::LDIF->new($tmp,"r",onerror => 'warn');
$entry = $ldif->ready_entry();
$ldap = Net::LDAP->new($LDAPSERVER);
$result=$ldap->bind("$binddn",password=>"$bindpass",version=>"3");
$result=$ldap->add($entry);

Now, everything seems to work until I get to the $ldap->add method.
From that I get various versions of the following:

objectclass: value #0 invalid per syntax at ldap.cgi

I can get that error message to change to different attributes, but
basically keeps saying the same thing. I've tried adding the following
just before the $ldap->add but it didn't help:
$entry->add('changetype'=>'add');

I've even gone through a routine to save off the value of each
attribute, do a $entry->delete on the attribute, and then a $entry->add
to re-add the attribute, to no avail.

I've done extensive searching on the web and nothing I've found has
helped, so I'm really hoping someone here can aid me ASAP, for I have to
get this done in the next day or two.

Thanks,
Rick

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email
______________________________________________________________________

[Rick Greene]

[Quanah Gibson-Mount]

--On Friday, August 19, 2005 3:48 PM -0400 Rick Greene
<gree...@pobox.upenn.edu> wrote:

> I'm trying to read in a simple LDIF file to add an entry to my LDAP
> server. Here is the basic routine (extraneous details omitted for
> brevity and security):
>
> $ldif = Net::LDAP::LDIF->new($tmp,"r",onerror => 'warn');
> $entry = $ldif->ready_entry();
> $ldap = Net::LDAP->new($LDAPSERVER);
> $result=$ldap->bind("$binddn",password=>"$bindpass",version=>"3");
> $result=$ldap->add($entry);
>
> Now, everything seems to work until I get to the $ldap->add method. From
> that I get various versions of the following:
>
> objectclass: value #0 invalid per syntax at ldap.cgi

This looks like an error from the LDAP server saying that the objectclass
used for that entry is unknown to the server, and thus invalid.

--Quanah

--
Quanah Gibson-Mount
Principal Software Developer
ITSS/Shared Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

[Rick Greene]

Further update:

I have tried to just manually create a new entry within the PERL script
itself, and it fails on different message:

add error: addRequest.addRequest.objectName is undefined at
/usr/lib/perl5/site_perl/5.8.6/Net/LDAP/Message.pm line 178

Here is the code that leads up to the above message (the bind is done a
few lines before, authenticated and it does succeed):

$entry=Net::LDAP::Entry->new();
$entry->add(
'dn'=>'cn=kingr,o=PennLibraryStaff,dc=library,dc=upenn,dc=edu');
$entry->add( 'objectclass'=>
["person","organizationalPerson","inetOrgPerson","posixAccount","upennEduPerson"
]);
$entry->add( 'cn' => "kingr");
$entry->add( 'sn' => "kingr");
$entry->add( 'userid' => "kingr");
$entry->add( 'uidNumber' => "3019");
$entry->add( 'gidNumber' => "100");
$entry->add( 'homeDirectory' => "/home/kingr");
$entry->add( 'userPassword' => "{SHA}6wEWbSyjuY4/gp469HkIAxqj3vs=");
$entry->add( 'loginShell' => "/bin/bash");
$entry->add( 'gecos' => "Richard P. King");
$result=$ldap->add( $entry ) ;
$result->code && die "add error: ", $result->error;

I feel like I'm missing a key detail here. Can anyone see what it is?

Thanks in advance,
Rick

[Graham Barr]

On Mon, August 22, 2005 2:10 pm, Rick Greene said:
> Further update:
>
> I have tried to just manually create a new entry within the PERL script
> itself, and it fails on different message:
>
> add error: addRequest.addRequest.objectName is undefined at
> /usr/lib/perl5/site_perl/5.8.6/Net/LDAP/Message.pm line 178
>
> Here is the code that leads up to the above message (the bind is done a
> few lines before, authenticated and it does succeed):
>
> $entry=Net::LDAP::Entry->new();

You need to set the DN with

$entry->dn($dn);

Graham.

[Rick Greene]

Ok, Graham supplied the missing bit, so now I know at least the basics
are working.

Now the question remains, what is wrong with the original thing I was
trying, using the Net::LDAP::LDIF functionality? Here's the code (part
of a script fed from a web form, cut out extraneous details):

#Version to do it through LDIF read
use Net::LDAP::LDIF ;
local $tmp="/tmp/$$.ldif" ;
open OUTFILE,"> $tmp"; print OUTFILE $w->param('ldif') ; close OUTFILE ;

$ldif = Net::LDAP::LDIF->new($tmp,"r",onerror => 'warn');

$entry = $ldif->read_entry();
if ($debug) {
print "${redon}ldif loaded with dn=",$entry->dn(),"${redoff}$br";
@attributes=$entry->attributes;
print "${redon}read entry:<BR>"; foreach $key (sort @attributes) {
print "$key=" ; print $entry->get_value($key); print "${br}"; } print
"${redoff}${br}";

}
$ldap = Net::LDAP->new($LDAPSERVER);
$result=$ldap->bind("$binddn",password=>"$bindpass",version=>"3");
$result=$ldap->add($entry);

$result->code && die "add error: ", $result->error;

And here is the LDIF that is pasted into the form (a textarea field):

dn: cn=kingr,o=PennLibraryStaff,dc=library,dc=upenn,dc=edu
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: posixAccount
objectclass: upennEduPerson
cn: kingr
gn: Richard
sn: King
userid: kingr
uidNumber: 3019
gidNumber: 100
homeDirectory: /home/kingr
loginShell: /bin/bash
gecos: Richard P. King
ou: Reference
title: Systems Tech II

And here's the results (some debug statements were omitted from the code
above, but the output is below):
In sub process_ldif
creating /tmp/19277.ldif
/tmp/19277.ldif contains

dn: cn=kingr,o=PennLibraryStaff,dc=library,dc=upenn,dc=edu
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: posixAccount
objectclass: upennEduPerson
cn: kingr
gn: Richard
sn: King
userid: kingr
uidNumber: 3019
gidNumber: 100
homeDirectory: /home/kingr
userPassword: {SHA}6wEWbSyjuY4/gp469HkIAxqj3vs=
loginShell: /bin/bash
gecos: Richard P. King
ou: Reference
mail: ki...@wharton.upenn.edu
telephonenumber: 215-898-5928
title: Systems Tech II

ldif loaded with dn=cn=kingr,o=PennLibraryStaff,dc=library,dc=upenn,dc=edu
read entry:
cn=kingr
gecos=Richard P. King
gidnumber=100
gn=Richard
homedirectory=/home/kingr
loginshell=/bin/bash
mail=ki...@wharton.upenn.edu
objectclass=person organizationalPerson inetOrgPerson posixAccount
upennEduPerson
ou=Reference
sn=King
telephonenumber=215-898-5928
title=Systems Tech II
uidnumber=3019
userid=kingr
userpassword={SHA}6wEWbSyjuY4/gp469HkIAxqj3vs=

add error: objectclass: value #0 invalid per syntax at
/var/www/html/bin/ldappasswd.cgi line 117, line 1.

So, as far as I can tell the $entry reference has everything in it, and
I know the object classes in the LDIF are good, for they are the same as
every other entry in this particular LDAP instance. In fact, if I use
this LDIF file from the command line with an ldapadd statement, it works
fine. So again, I am missing something but can't tell what. It's not
the bit I was missing doing it manually that Graham pointed out, for you
can see the debug code is correctly outputting $entry->dn() and showing
the value is set.

Thanks again in advance,

[Rick Greene]

Ok, I found the problem. Somehow (probably a default action that I
didn't know about), when taking in the LDIF formatted text from the
textarea field of the web form, dumping to a local temporary text file,
and then using Net::LDAP::LDIF's $ldif->read_entry(), ALL the attributes
were ending up with a CR (ascii 13) character at the end, and the PERL
chomp function wasn't removing it. I got more brute-force-ish about it
and it all works now.

I did two things...after writing the $w->param('ldif') out to a file, I
then did:

system ("/usr/bin/dos2unix $tmp")

Which probably took care of everything, but I also put in the following
line in a couple of key places to be sure:

if ( ord(substr($line,-1)) <= 32 ) { chop($line) ; }

Sorry to have taken up everyone's time with this, thanks to Graham for
the one hint, hopefully this thread will help someone else along the line.

Rick

[Quanah Gibson-Mount]

--On Tuesday, August 23, 2005 12:46 PM -0400 Rick Greene <ri...@serve.com>
wrote:

> Ok, I found the problem. Somehow (probably a default action that I
> didn't know about), when taking in the LDIF formatted text from the
> textarea field of the web form, dumping to a local temporary text file,
> and then using Net::LDAP::LDIF's $ldif->read_entry(), ALL the attributes
> were ending up with a CR (ascii 13) character at the end, and the PERL
> chomp function wasn't removing it. I got more brute-force-ish about it
> and it all works now.
>
> I did two things...after writing the $w->param('ldif') out to a file, I
> then did:
>
> system ("/usr/bin/dos2unix $tmp")
>
> Which probably took care of everything, but I also put in the following
> line in a couple of key places to be sure:
>
> if ( ord(substr($line,-1)) <= 32 ) { chop($line) ; }
>
> Sorry to have taken up everyone's time with this, thanks to Graham for
> the one hint, hopefully this thread will help someone else along the line.

This was actually just recently discussed.

You could, I would think, use perl itself to clean up the \r\n fairly
easily. ;)

$line =~ s/\r\n//;

for example, rather than chomp.

--Quanah

--
Quanah Gibson-Mount
Principal Software Developer
ITSS/Shared Services
Stanford University
GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

"These censorship operations against schools and libraries are stronger
than ever in the present religio-political climate. They often focus on
fantasy and sf books, which foster that deadly enemy to bigotry and blind
faith, the imagination." -- Ursula K. Le Guin

[Chris Ridd]

On 23/8/05 5:51, Quanah Gibson-Mount <qua...@stanford.edu> wrote:

> This was actually just recently discussed.
>
> You could, I would think, use perl itself to clean up the \r\n fairly
> easily. ;)
>
> $line =~ s/\r\n//;
>
> for example, rather than chomp.

Or if you wanted to cope with other mutant kinds of line ends:

$line =~ s/[\r\n]+$//;

(Dunno if that's more efficient that /\r?\n?$/ but they'd both catch
old-style Mac linebreaks.)

Cheers,

Chris

[Peter Marschall]

Hi Rick,

would you be so kind to do the perl-ldap project a favour ?

Here's a patch for Net::LDAP::LDIF that should make it work with
LDIF files that have lines ending in CR+LF.

Would you mind to test it and report any problems with it

Thanks in advance
Peter

--
Peter Marschall
eMail: pe...@adpm.de

[Rick Greene]

I would have loved to assist, however the project I was on that was
utilizing this has ended for me, so I no longer have access to those systems.

I emailed myself copies of the config files and programs I wrote, if
I can get a home system working with the same set up I could try
there, but the next couple of weeks are going to be busy for me so
I'm not sure how soon I'll be able to get to this.

Sorry,

Rick