perl-ldap-dev

Re: ldap urls

[Mark W. <mew...@un...>]

Kurt Z might pop in, but you'll likey have better luck with this question
by asking on the openldap-server list.

Mark

On Wed, 23 Aug 2000, wiLL wrote:

> I tried to eliminate anonymous searches on my server , but it doesnt seem
> to like it ..
> the slapd daemon wont run if i put the ff. on my slapd.conf file, there
> arent any error messages though , is this correct ?...
> 
> ------------
> :
> :
> database ldbm
> suffix          "o=mycom, c=PH"
> rootdn          "uid=Manager, o=mycom, c=PH"
> # database directory  
> # this directory MUST exist prior to running slapd AND
> # should only be accessable by the slapd/tools  Mode 700 recommended.
> directory       /usr/local/var/openldap-ldbm
> access to *                          
>         by self write
>         by anonymous none
> 
> :
> :
> --------------------------------
> 
> 
> 
> At 11:09 PM 8/16/00 , Jim Harle wrote:
> >LDAP URLS basically just say "use the LDAP protocol to get some
> >information".  You need to deal with the general issue of LDAP access to
> >your server.  For example, we block access to that port at our router,
> >except for holes opened to 2 specific ports.  Your server may have some
> >type of control available also.
> >  --Jim Harle
> >
> >
> >On Wed, 16 Aug 2000, Mark Wilcox wrote:
> >
> >> Nobody (at least that I know of) supports authenticated operations via
> >> LDAP URLs. Just eliminate anonymous searches to your server and that will
> >> prevent LDAP URLs.
> >> 
> >> Mark
> >> 
> >> On Wed, 16 Aug 2000, wiLL wrote:
> >> 
> >> > 
> >> > I've been working with binding usernames with their corresponding
> paswd in
> >> > the LDAP tree, but this is just when a user would access a particular
> http
> >> > directory ... I just realized I needed also to restrict ldap urls from
> >> > being accessed by anyone .. Does anybody knows how this one goes?
> >> > 
> >> > will
> >> > 
> >> > -------------------------------------
> >> > wiLL S. Olivete Jr.
> >> > wol...@sk...
> >> > pgp key id : 0x2D85D7BF
> >> > office voice: 63.74.443.5657
> >> > mobile: 0917.972.6384
> >> > pager: ec 963576 
> >> > 
> >> > 
> >> 
> >> 
> >> 
> > 
> 
> -------------------------------------
> wiLL S. Olivete Jr.
> wol...@sk...
> pgp key id : 0x2D85D7BF
> office voice: 63.74.443.5657
> mobile: 0917.972.6384
> pager: ec 963576 
> 
> 

Re: getting attributes

[Mark W. <mew...@un...>]

my $cn = $entry->get("cn");

for my $v (@$cn)
{
   print "cn:$v\n";
}

to get just the first value:
my $v = $cn->[0];

you should read up on arrays in the Perl docs because they are used a lot.

Mark

On Wed, 23 Aug 2000 ms...@ma... wrote:

> hi,
> 
> how can i get the value of the attributes from the reference to array in an Entry object?
> 
> thanks,
> manuel.
> 
> 
> _____________________________________________________________
> Global Virtual Desktop
> Get your free Desktop at http://www.magicaldesk.com
> 
> 
> 

Re: ldap urls

[wiLL <wol...@sk...>]

I tried to eliminate anonymous searches on my server , but it doesnt seem
to like it ..
the slapd daemon wont run if i put the ff. on my slapd.conf file, there
arent any error messages though , is this correct ?...

------------
:
:
database ldbm
suffix          "o=mycom, c=PH"
rootdn          "uid=Manager, o=mycom, c=PH"
# database directory  
# this directory MUST exist prior to running slapd AND
# should only be accessable by the slapd/tools  Mode 700 recommended.
directory       /usr/local/var/openldap-ldbm
access to *                          
        by self write
        by anonymous none

:
:
--------------------------------



At 11:09 PM 8/16/00 , Jim Harle wrote:
>LDAP URLS basically just say "use the LDAP protocol to get some
>information".  You need to deal with the general issue of LDAP access to
>your server.  For example, we block access to that port at our router,
>except for holes opened to 2 specific ports.  Your server may have some
>type of control available also.
>  --Jim Harle
>
>
>On Wed, 16 Aug 2000, Mark Wilcox wrote:
>
>> Nobody (at least that I know of) supports authenticated operations via
>> LDAP URLs. Just eliminate anonymous searches to your server and that will
>> prevent LDAP URLs.
>> 
>> Mark
>> 
>> On Wed, 16 Aug 2000, wiLL wrote:
>> 
>> > 
>> > I've been working with binding usernames with their corresponding
paswd in
>> > the LDAP tree, but this is just when a user would access a particular
http
>> > directory ... I just realized I needed also to restrict ldap urls from
>> > being accessed by anyone .. Does anybody knows how this one goes?
>> > 
>> > will
>> > 
>> > -------------------------------------
>> > wiLL S. Olivete Jr.
>> > wol...@sk...
>> > pgp key id : 0x2D85D7BF
>> > office voice: 63.74.443.5657
>> > mobile: 0917.972.6384
>> > pager: ec 963576 
>> > 
>> > 
>> 
>> 
>> 
> 

-------------------------------------
wiLL S. Olivete Jr.
wol...@sk...
pgp key id : 0x2D85D7BF
office voice: 63.74.443.5657
mobile: 0917.972.6384
pager: ec 963576 

getting attributes

[<ms...@ma...>]

hi,

how can i get the value of the attributes from the reference to array in an Entry object?

thanks,
manuel.


_____________________________________________________________
Global Virtual Desktop
Get your free Desktop at http://www.magicaldesk.com

Re: utf8

[Chris R. <chr...@me...>]

Mark Wilcox <mew...@un...> wrote:
> as I understand it (I"m sure Chris or Kurt will correct me :), the
> 'native' string format for LDAP 3 is utf8.
>
> Many LDAP APIs use utf8 internally, but Net::LDAP isn't one of them
> because Perl doesn't have true, native support for utf8 yet (it's better
> in 5.6, but don't use 5.6, it's buggy & Net::LDAP is great bug bait for
> 5.6).
> 
> Until then, you might have to do something like you showed below.
> 
> Mark

Yup, I agree. We also should remember that Net::LDAP supports LDAPv2, and
will bind by default also using LDAPv2. It is not legal to use UTF-8 using
LDAPv2.

> 
> 
> On Fri, 18 Aug 2000, Stefan Poschenrieder wrote:
> 
>> Hi there,
>> 
>> is there any good way to read/write into the DS
>> in utf8 ?
>> i dont wanna do it that way :
>> print utf8($entry->get("configattributname"));
>> 
>> by the way, i am still using 0.14 ..
>> will the application still work when i upgrade ?

There are some minor API differences. The ChangeLog file should list all of
these:

http://perl-ldap.sourceforge.net/perl-ldap-0.20/ChangeLog

Cheers,

Chris (back from Japan!)

Re: Convert::ASN1 loading times

[John B. <joh...@ne...>]

> Attached is a gzipped tar with the patch for Convert/ASN1.pm, an
> 'ldap.asn' file and an 'Net/LDAP/ASN.pm.new' which you need to use the
> ->load method when you start Net::LDAP. Patch is against version 0.07 of
> ASN1.pm (i.e. the current CPAN rather than the current CVS).

Err. no. Attached was just the patch itself. To generate the 'ldap.asn'
file you'll need to play around a little and put a
->save() somewhere. Sorry about that.

regards,

jb

Re: Convert::ASN1 loading times

[John B. <jj...@be...>]

OK - here is the second cut of the Convert::ASN1 save/load. I've reworked
it in the light of Graham's comments. (Including those on recursion :-)

Attached is a gzipped tar with the patch for Convert/ASN1.pm, an
'ldap.asn' file and an 'Net/LDAP/ASN.pm.new' which you need to use the
->load method when you start Net::LDAP. Patch is against version 0.07 of
ASN1.pm (i.e. the current CPAN rather than the current CVS).

The fastest load time for this I've seen is 0.31s, against a fastest load
time of 0.55s for the current code. (This is looking at 'time
-MNet::LDAP::ASN -e exit').

Using '-d:DProf' and looking at the CumulS column: The new ->load function
takes ~0.07s and the old ->prepare function takes ~0.31s. These
measurements seem to agree with the 'time' method and suggest a nice
speedup.

The format of the ldap.asn file should now be more obvious to humans.

The empty tag bug should be fixed.

It tests out OK with my test app here. YMMV.

regards,

jb

Re: OID and the modifyTimestamp

[Mark W. <mew...@un...>]

While I've heard of the product, you're the first person I've ever heard
of actually using it.

You'll have to consult with Oracle's documentation (such as it's
schema) or support to find out if it supports the modifyTimestamp
attribute.

Mark

On Fri, 18 Aug 2000, Bouarich, Reda wrote:

> Hello everybody,
> I'm using Oracle Internet Directory and this last one seems to have problems
> with operationals attributs like the modifyTimestamp!!
> Does it support it? I thought that this attribut is maintained by the
> server!! Is it true??
> Thanks a lot.
> Reda.
> 
> 

OID and the modifyTimestamp

[Bouarich, R. <Red...@co...>]

Hello everybody,
I'm using Oracle Internet Directory and this last one seems to have problems
with operationals attributs like the modifyTimestamp!!
Does it support it? I thought that this attribut is maintained by the
server!! Is it true??
Thanks a lot.
Reda.

Re: utf8

[Mark W. <mew...@un...>]

as I understand it (I"m sure Chris or Kurt will correct me :), the
'native' string format for LDAP 3 is utf8.

Many LDAP APIs use utf8 internally, but Net::LDAP isn't one of them
because Perl doesn't have true, native support for utf8 yet (it's better
in 5.6, but don't use 5.6, it's buggy & Net::LDAP is great bug bait for
5.6).

Until then, you might have to do something like you showed below.

Mark



On Fri, 18 Aug 2000, Stefan Poschenrieder wrote:

> Hi there,
> 
> is there any good way to read/write into the DS
> in utf8 ?
> i dont wanna do it that way :
> print utf8($entry->get("configattributname"));
> 
> by the way, i am still using 0.14 ..
> will the application still work when i upgrade ?
> 
> 
> thanx,
> stefan
> 
> 

utf8

[Stefan P. <st...@me...>]

Hi there,

is there any good way to read/write into the DS
in utf8 ?
i dont wanna do it that way :
print utf8($entry->get("configattributname"));

by the way, i am still using 0.14 ..
will the application still work when i upgrade ?


thanx,
stefan

Re: Problems Retrieving Some Attributes...

[Mark W. <mew...@un...>]

1) are you sure they are there ? (as in they have values)
2) are you binded as a user who has rights to see these attributes.

i've never had problems retrieving them.

Mark

On Thu, 17 Aug 2000, Joshua Lavalleur wrote:

> Has anyone had problems retrieving certian attributes from a Netscape
> Directory Server 4 with Perl-LDAP v.20?. I can't get my program to return
> the followingattributes.
> 
> st
> labeleduri
> street
> l
> manager
> 
> Anyone have a ideas what the heck is wrong?
> 
> -Josh
> 
> 

Problems Retrieving Some Attributes...

[Joshua L. <Jos...@ip...>]

Has anyone had problems retrieving certian attributes from a Netscape
Directory Server 4 with Perl-LDAP v.20?. I can't get my program to return
the followingattributes.

st
labeleduri
street
l
manager

Anyone have a ideas what the heck is wrong?

-Josh

Re: deleting entries...

[Graham B. <gb...@po...>]

On Thu, Aug 17, 2000 at 05:24:34PM +0100, John Berthels wrote:
> 
> > Not really, not any more. Yes I started it and I may have written most
> > of whats there. But I see most of it's future development coming
> > from others, hopefully I can be a good guide in the process.
> 
> Yes. Someone needs to enforce taste and decency otherwise things become a
> mess.

I hope to be that person.

> > > >       unshift @dn, map { $_->dn() } $msg->entries;
> > 
> > No. base to ->search can be an Entry object. In which case ->search
> > will call ->dn for you.
> 
> Hmm. Has that changed recently in CVS? I actually tried it and got a 'Bad
> DN Syntax' error. But I was using an old version of Net::LDAP I think.

Veru old. It went in version 0.16, which was when I changed from Convert::BER
to Convert::ASN1

> > > Or perhaps you mean:
> > > 
> > > 	unshift @dn, $ldap->list( $dn );
> > > 
> > > instead :-)
> > 
> > Maybe, but then I loose the Message, so I don't know if there are no
> > children of if there was an error. I guess I could check $@.
> 
> Or save the original DN arg as $dn_orig and:
> 
> 	return !$ldap->exists( $dn_orig );
> 
> at the end.

But not existing may not be the only reason for failure.

Graham.

Re: deleting entries...

[John B. <joh...@ne...>]

> Not really, not any more. Yes I started it and I may have written most
> of whats there. But I see most of it's future development coming
> from others, hopefully I can be a good guide in the process.

Yes. Someone needs to enforce taste and decency otherwise things become a
mess.

> > I'm not sure I'll easily do the ->save/load as non-recursive though.
> 
> Oh, I don't know. There is normally a way. But write it as recursive
> if thats what you feel most comfortable with. Someone with some spare
> time can always change it later. Often there is not much to change,
> notice I made little change to your code for the tree delete.

Yes. I'm sure its do-able, just not sure *I'll* do it easily :-)

> > >       unshift @dn, map { $_->dn() } $msg->entries;
> 
> No. base to ->search can be an Entry object. In which case ->search
> will call ->dn for you.

Hmm. Has that changed recently in CVS? I actually tried it and got a 'Bad
DN Syntax' error. But I was using an old version of Net::LDAP I think.

> > Or perhaps you mean:
> > 
> > 	unshift @dn, $ldap->list( $dn );
> > 
> > instead :-)
> 
> Maybe, but then I loose the Message, so I don't know if there are no
> children of if there was an error. I guess I could check $@.

Or save the original DN arg as $dn_orig and:

	return !$ldap->exists( $dn_orig );

at the end.

jb

Re: deleting entries...

[Graham B. <gb...@po...>]

On Thu, Aug 17, 2000 at 04:56:56PM +0100, John Berthels wrote:
> > > would it be better to propogate the Net::LDAP::Message back to the caller?
> > 
> > How would you do that ? Return the message on error and undef otherwise ?
> 
> I guess you could (gack. 'undef' return means success). Or construct a new
> ::Message object with a success code? Or stay with what we have here?

Well the ::Message in CVS now has is_error, which could be changed to
->success

But you loose the usage of the return value as a meaning of success :(

> > Also I would rather avoid recursion if possible, I hate recursion.
> 
> Fair enough. Its your module.

Not really, not any more. Yes I started it and I may have written most
of whats there. But I see most of it's future development coming
from others, hopefully I can be a good guide in the process.

> I've got as far as putting the opening brace
> of a sub on the same line as the name, so I'm gradually getting in sync
> with your style :-)

:)

> I'm not sure I'll easily do the ->save/load as non-recursive though.

Oh, I don't know. There is normally a way. But write it as recursive if
thats what you feel most comfortable with. Someone with some spare
time can always change it later. Often there is not much to change, notice I made little change to your
code for the tree delete.

> 
> [snip nice non-recursive tree_delete]
> 
> Nice - except this bit:
> 
> >       my $msg = $ldap->search( base => $dn[0],
> >                                scope => 1,
> >                                filter => "(objectclass=*)",
> >                                attr => [ "1.1" ]
> >                                );
> >
> >       unless( $msg->code() == LDAP_SUCCESS ) {
> >           $@ = Net::LDAP::Util::ldap_error_text( $msg->code() );
> >           return undef;
> >       }
> > 
> >       unshift @dn, $msg->entries;
> 
> needs
> 
> >       unshift @dn, map { $_->dn() } $msg->entries;

No. base to ->search can be an Entry object. In which case ->search
will call ->dn for you.

> Or perhaps you mean:
> 
> 	unshift @dn, $ldap->list( $dn );
> 
> instead :-)

Maybe, but then I loose the Message, so I don't know if there are no
children of if there was an error. I guess I could check $@.

Graham.

Re: deleting entries...

[John B. <joh...@ne...>]

> > This one return true/false and sets $!. I realise this is a bit odd -
> 
> You cannot set $!, Reading $! always reads errno from C. Setting $@ would
> be better.

Gack. I should have read the complete perlvar entry. Apparently you can
set it but only numeric values, which would then get represented as the
relevent errno strings. Not useful, $@ it is.

> > would it be better to propogate the Net::LDAP::Message back to the caller?
> 
> How would you do that ? Return the message on error and undef otherwise ?

I guess you could (gack. 'undef' return means success). Or construct a new
::Message object with a success code? Or stay with what we have here?

> Also I would rather avoid recursion if possible, I hate recursion.

Fair enough. Its your module. I've got as far as putting the opening brace
of a sub on the same line as the name, so I'm gradually getting in sync
with your style :-)

I'm not sure I'll easily do the ->save/load as non-recursive though.

[snip nice non-recursive tree_delete]

Nice - except this bit:

>       my $msg = $ldap->search( base => $dn[0],
>                                scope => 1,
>                                filter => "(objectclass=*)",
>                                attr => [ "1.1" ]
>                                );
>
>       unless( $msg->code() == LDAP_SUCCESS ) {
>           $@ = Net::LDAP::Util::ldap_error_text( $msg->code() );
>           return undef;
>       }
> 
>       unshift @dn, $msg->entries;

needs

>       unshift @dn, map { $_->dn() } $msg->entries;


Or perhaps you mean:

	unshift @dn, $ldap->list( $dn );

instead :-)

regards,

jb

Re: deleting entries...

[Graham B. <gb...@po...>]

On Thu, Aug 17, 2000 at 09:06:07AM -0500, Mark Wilcox wrote:
> I'm +1 for returning Net::LDAP::Message because that's what we normally
> get. 

Hm..


> I think anything under Net::LDAP:: that's not part of the simple API, it
> should return the Message object.

Well I guess this is debatable if it is part of either.

I would not say it is part of the main API as it performs multiple requests
and so cannot be used in async mode. (well it could if it was re-written
to do everything with callback, an exercise for the reader :)

And I would not say it was part of the simple API because it's not
a simplified view of something the main API can do. Well it is, but
it's also useful to the main API. So it is a Util.

Now the question of what Util subs should return ?

Graham,

> Mark
> 
> On Thu, 17 Aug 2000, John Berthels wrote:
> 
> > On Wed, 16 Aug 2000, John Berthels wrote:
> > 
> > > 
> > > 
> > > > You must delete all children entries first before you can delete any
> > > > parent entries.
> > > 
> > > Net::LDAP::Util::ldap_delete_tree anyone?
> > 
> > 
> > This one return true/false and sets $!. I realise this is a bit odd -
> > would it be better to propogate the Net::LDAP::Message back to the caller?
> > 
> > jb
> > 
> > 
> > 
> > sub ldap_delete_tree {
> >     my $ldap = shift;
> >     my $dn = shift;
> > 
> >     my $msg = $ldap->search( base => $dn,
> > 			     scope => 1,
> > 			     filter => "(objectclass=*)",
> > 			     attr => [ "1.1" ]
> > 			     );
> >     unless( $msg->code() == LDAP_SUCCESS ) {
> > 	$! = Net::LDAP::Util::ldap_error_text( $msg->code() );
> > 	return undef;
> >     }
> > 
> >     #
> >     # Recursively get rid of children, if any
> >     #
> >     foreach my $entry ( $msg->entries() ) {
> > 	my $dn = $entry->dn();
> > 	return undef unless ldap_delete_tree( $ldap, $dn );
> >     }
> > 
> >     # And then ourselves
> >     $msg = $ldap->delete( $dn );
> >     unless( $msg->code() == LDAP_SUCCESS ) {
> > 	$! = Net::LDAP::Util::ldap_error_text( $msg->code() );
> > 	return undef;
> >     }
> > 
> >     return 1;
> > }
> > 
> > 
> > 
> > 
> 
> 
> 

Re: deleting entries...

[Mark W. <mew...@un...>]

I'm +1 for returning Net::LDAP::Message because that's what we normally
get. 

I think anything under Net::LDAP:: that's not part of the simple API, it
should return the Message object.

Mark

On Thu, 17 Aug 2000, John Berthels wrote:

> On Wed, 16 Aug 2000, John Berthels wrote:
> 
> > 
> > 
> > > You must delete all children entries first before you can delete any
> > > parent entries.
> > 
> > Net::LDAP::Util::ldap_delete_tree anyone?
> 
> 
> This one return true/false and sets $!. I realise this is a bit odd -
> would it be better to propogate the Net::LDAP::Message back to the caller?
> 
> jb
> 
> 
> 
> sub ldap_delete_tree {
>     my $ldap = shift;
>     my $dn = shift;
> 
>     my $msg = $ldap->search( base => $dn,
> 			     scope => 1,
> 			     filter => "(objectclass=*)",
> 			     attr => [ "1.1" ]
> 			     );
>     unless( $msg->code() == LDAP_SUCCESS ) {
> 	$! = Net::LDAP::Util::ldap_error_text( $msg->code() );
> 	return undef;
>     }
> 
>     #
>     # Recursively get rid of children, if any
>     #
>     foreach my $entry ( $msg->entries() ) {
> 	my $dn = $entry->dn();
> 	return undef unless ldap_delete_tree( $ldap, $dn );
>     }
> 
>     # And then ourselves
>     $msg = $ldap->delete( $dn );
>     unless( $msg->code() == LDAP_SUCCESS ) {
> 	$! = Net::LDAP::Util::ldap_error_text( $msg->code() );
> 	return undef;
>     }
> 
>     return 1;
> }
> 
> 
> 
> 

Re: interpreting error codes

[Mark W. <mew...@un...>]

65 is objectclass violation. it means that you either dont' have all of
the required attributes or you have an attribute is not allowed in your
entry's objectclass.

your server error log will generally tell you exactly what's wrong with
the entry.

mark

On Thu, 17 Aug 2000 ms...@ma... wrote:

> hi folks,
> 
> consider the following code fragment:
> 
> my($result) = $ldap->add(dn=>...,attr=>...);
> print $result->code, $result->error;
> 
> ok, the code got displayed, (some number, 65 for me this time, but nothing from error).  i assume anything other than 0 should be some sort of problem.  but how do i lookup what these numbers mean (for error handling)?  specifically, pls show me how to use Constant package, if that is the way to go.  thanx a lot.
> 
> manuel.
> 
> 
> _____________________________________________________________
> Global Virtual Desktop
> Get your free Desktop at http://www.magicaldesk.com
> 
> 
> 

Re: deleting entries...

[Graham B. <gb...@po...>]

On Thu, Aug 17, 2000 at 01:15:50PM +0100, John Berthels wrote:
> On Wed, 16 Aug 2000, John Berthels wrote:
> 
> > 
> > 
> > > You must delete all children entries first before you can delete any
> > > parent entries.
> > 
> > Net::LDAP::Util::ldap_delete_tree anyone?
> 
> 
> This one return true/false and sets $!. I realise this is a bit odd -

You cannot set $!, Reading $! always reads errno from C. Setting $@ would
be better.

> would it be better to propogate the Net::LDAP::Message back to the caller?

How would you do that ? Return the message on error and undef otherwise ?

Also I would rather avoid recursion if possible, I hate recursion.

Something like (untested)


sub ldap_delete_tree {
    my $ldap = shift;
    my @dn = @_;

    while (@dn) {

	my $msg = $ldap->search( base => $dn[0],
				 scope => 1,
				 filter => "(objectclass=*)",
				 attr => [ "1.1" ]
				 );

	unless( $msg->code() == LDAP_SUCCESS ) {
	    $@ = Net::LDAP::Util::ldap_error_text( $msg->code() );
	    return undef;
	}

	if ($msg->count) {
	    #
	    # We have children
	    #
	    unshift @dn, $msg->entries;
	    next;
	}


	# And then ourselves
	$msg = $ldap->delete( shift @dn );
	unless( $msg->code() == LDAP_SUCCESS ) {
	    $@ = Net::LDAP::Util::ldap_error_text( $msg->code() );
	    return undef;
	}
    }

    return 1;
}


Graham.

Re: deleting entries...

[John B. <joh...@ne...>]

On Wed, 16 Aug 2000, John Berthels wrote:

> 
> 
> > You must delete all children entries first before you can delete any
> > parent entries.
> 
> Net::LDAP::Util::ldap_delete_tree anyone?


This one return true/false and sets $!. I realise this is a bit odd -
would it be better to propogate the Net::LDAP::Message back to the caller?

jb



sub ldap_delete_tree {
    my $ldap = shift;
    my $dn = shift;

    my $msg = $ldap->search( base => $dn,
			     scope => 1,
			     filter => "(objectclass=*)",
			     attr => [ "1.1" ]
			     );
    unless( $msg->code() == LDAP_SUCCESS ) {
	$! = Net::LDAP::Util::ldap_error_text( $msg->code() );
	return undef;
    }

    #
    # Recursively get rid of children, if any
    #
    foreach my $entry ( $msg->entries() ) {
	my $dn = $entry->dn();
	return undef unless ldap_delete_tree( $ldap, $dn );
    }

    # And then ourselves
    $msg = $ldap->delete( $dn );
    unless( $msg->code() == LDAP_SUCCESS ) {
	$! = Net::LDAP::Util::ldap_error_text( $msg->code() );
	return undef;
    }

    return 1;
}

Re: interpreting error codes

[Graham B. <gb...@po...>]

The ->error method will return any error string that the server returned.
Sadly there is no requirment that they put anything in there, so for
many servers it is empty :(

Net::LDAP::Util does provide two subs for converting the error code
to a name or description.

  use Net::LDAP::Util qw(ldap_error_name ldap_error_text);

  print ldap_error_name($mesg->code),"\n";
  print ldap_error_text($mesg->code),"\n";

Graham.

On Thu, Aug 17, 2000 at 12:34:36AM -0700, ms...@ma... wrote:
> hi folks,
> 
> consider the following code fragment:
> 
> my($result) = $ldap->add(dn=>...,attr=>...);
> print $result->code, $result->error;
> 
> ok, the code got displayed, (some number, 65 for me this time, but nothing from error).  i assume anything other than 0 should be some sort of problem.  but how do i lookup what these numbers mean (for error handling)?  specifically, pls show me how to use Constant package, if that is the way to go.  thanx a lot.

interpreting error codes

[<ms...@ma...>]

hi folks,

consider the following code fragment:

my($result) = $ldap->add(dn=>...,attr=>...);
print $result->code, $result->error;

ok, the code got displayed, (some number, 65 for me this time, but nothing from error).  i assume anything other than 0 should be some sort of problem.  but how do i lookup what these numbers mean (for error handling)?  specifically, pls show me how to use Constant package, if that is the way to go.  thanx a lot.

manuel.


_____________________________________________________________
Global Virtual Desktop
Get your free Desktop at http://www.magicaldesk.com

CPAN Upload: M/ME/MEWILCOX/apache.authnetldap.018.tar.gz

[PAUSE <up...@p1...>]

The uploaded file

    apache.authnetldap.018.tar.gz

has entered CPAN as

  file: $CPAN/authors/id/M/ME/MEWILCOX/apache.authnetldap.018.tar.gz
  size: 3799 bytes
   md5: def6f1bc8f8a88511c2332141bc8ade5

No action is required on your part
Request entered by: MEWILCOX (Mark Wilcox)
Request entered on: Wed, 16 Aug 2000 15:41:16 GMT
Request completed:  Wed, 16 Aug 2000 15:41:47 GMT

	Virtually Yours,
	Id: paused,v 1.68 1999/10/22 14:39:12 k Exp k