perl-ldap-dev

Re: FUnny return codes

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

On Tue, Jun 13, 2000 at 12:43:30PM -0700, Yann Ramin wrote:
> Graham Barr wrote:
> > 
> > 83 is an LDAP_ENCODING_ERROR object is the name of the element in the ASN
> > packet that is currently being encoded and causing the problem.
> > 
> > The "object" is the dn, which by looking at your code is undef, which is your
> > problem. I think you want $entry, but you could just pass $entr as modify will
> > accept an ::Entry object for the dn.
> >
> 
> 
> This is the second time I've had this problem in a day and can't seem to
> pick it up :)  Obviously I'm passing an undef, its right there in front
> of me.  I promise not to complain it doesn't work until I've undergone
> several hours of torment figuring out what is going wrong :) (I only
> played with this one for one hour going through every permutation of
> modify :))

Hey, don't worry about it. At least you are highlighting where we need to
do some work :)

But I do suggest you use Net::LDAP::Util a bit more for diagnostics.

Graham.

Re: FUnny return codes

[Yann R. <at...@at...>]

Graham Barr wrote:
> 
> 83 is an LDAP_ENCODING_ERROR object is the name of the element in the ASN
> packet that is currently being encoded and causing the problem.
> 
> The "object" is the dn, which by looking at your code is undef, which is your
> problem. I think you want $entry, but you could just pass $entr as modify will
> accept an ::Entry object for the dn.
>


This is the second time I've had this problem in a day and can't seem to
pick it up :)  Obviously I'm passing an undef, its right there in front
of me.  I promise not to complain it doesn't work until I've undergone
several hours of torment figuring out what is going wrong :) (I only
played with this one for one hour going through every permutation of
modify :))


> Graham.
> 
> PS: Yes there are still places where error reporting needs to be improved. But
> if you ever get LDAP_ENCODING_ERROR  then it is worth double-checking the
> args passed.
------------------------------------------------------
> >

-- 

--------------------------------------------------------------------
Yann Ramin			at...@at...
Atrus Trivalie Productions	www.redshift.com/~yramin
Monterey High IT		www.montereyhigh.com
ICQ 				46805627
AIM				oddatrus
Marina, CA	

"All cats die.  Socrates is dead.  Therefore Socrates is a cat."
	- The Logician
	
	# fortune
"To be responsive at this time, though I will simply say, and therefore
this is a repeat of what I said previously, that which I am unable to
offer in response is based on information available to make no such
statement."
--------------------------------------------------------------------

Re: FUnny return codes

[Jim H. <ha...@us...>]

The problem with the returned error looking strange is with your printing
$mesg->error instead of Net::LDAP::Util::ldap_error_text($mesg->code).

  --Jim Harle
  US Naval Academy


On Tue, 13 Jun 2000, Yann Ramin wrote:

> Hi,
> Ok, I'm back and have a perplexing question to answer.  The code below
> is supposed to add a user to a group, but dies in a funny error.  I have
> the program output:
> 
> # ./X11UInfo
> Entry: cn=Student, ou=System Groups, ou=Groups, dc=montereyhigh, dc=com
> User: cn=He He, dc=montereyhigh,dc=com
> 83 object at /usr/lib/perl5/site_perl/5.6.0/Convert/ASN1/_encode.pm line
> 47. 
> 
> 
> 
> And code:
> 
> sub add_user_to_group {
>         my ($self, $user, $group) = @_;
> 
>         if ($self->user_in_group($user, $group) != 1) {
>                 # Already there my friend :)
>                 return 1;
>         }
> 
>         my $mesg = $self->{LDAP}->search (  # perform a search
>                 base   => "ou=Groups, ".$self->{ldap_config_base},
>                 filter => "(&(cn=".$group.")(objectclass=groupofNames))"
>         );
>         my @entries = $mesg->entries;
>         my $entr = @entries[0];
>         my $entry = $entr->dn;
> 
>         print "Entry: $entry\nUser: $user\n";
>         my $mesg = $self->{LDAP}->modify($dn,
>                 changes =>      [
>                         add     =>      [       member  =>      $user  
> ]
>                 ]
>         );
>         if ($mesg->code) {
>                 print $mesg->code." ".$mesg->error;
>                 return 1;
>         }
>         return 0;
> 
> 
> }
> 
> 
> 
> -- 
> 
> --------------------------------------------------------------------
> Yann Ramin			at...@at...
> Atrus Trivalie Productions	www.redshift.com/~yramin
> Monterey High IT		www.montereyhigh.com
> ICQ 				46805627
> AIM				oddatrus
> Marina, CA	
> 
> "All cats die.  Socrates is dead.  Therefore Socrates is a cat."
> 	- The Logician
> 	
> 	# fortune
> "To be responsive at this time, though I will simply say, and therefore
> this is a repeat of what I said previously, that which I am unable to
> offer in response is based on information available to make no such
> statement."
> --------------------------------------------------------------------
> 
> 

Re: FUnny return codes

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

83 is an LDAP_ENCODING_ERROR object is the name of the element in the ASN
packet that is currently being encoded and causing the problem.

The "object" is the dn, which by looking at your code is undef, which is your
problem. I think you want $entry, but you could just pass $entr as modify will
accept an ::Entry object for the dn.

Graham.

PS: Yes there are still places where error reporting needs to be improved. But
if you ever get LDAP_ENCODING_ERROR  then it is worth double-checking the
args passed.

On Tue, Jun 13, 2000 at 10:38:48AM -0700, Yann Ramin wrote:
> Hi,
> Ok, I'm back and have a perplexing question to answer.  The code below
> is supposed to add a user to a group, but dies in a funny error.  I have
> the program output:
> 
> # ./X11UInfo
> Entry: cn=Student, ou=System Groups, ou=Groups, dc=montereyhigh, dc=com
> User: cn=He He, dc=montereyhigh,dc=com
> 83 object at /usr/lib/perl5/site_perl/5.6.0/Convert/ASN1/_encode.pm line
> 47. 
> 
> 
> 
> And code:
> 
> sub add_user_to_group {
>         my ($self, $user, $group) = @_;
> 
>         if ($self->user_in_group($user, $group) != 1) {
>                 # Already there my friend :)
>                 return 1;
>         }
> 
>         my $mesg = $self->{LDAP}->search (  # perform a search
>                 base   => "ou=Groups, ".$self->{ldap_config_base},
>                 filter => "(&(cn=".$group.")(objectclass=groupofNames))"
>         );
>         my @entries = $mesg->entries;
>         my $entr = @entries[0];
>         my $entry = $entr->dn;
> 
>         print "Entry: $entry\nUser: $user\n";
>         my $mesg = $self->{LDAP}->modify($dn,
>                 changes =>      [
>                         add     =>      [       member  =>      $user  
> ]
>                 ]
>         );
>         if ($mesg->code) {
>                 print $mesg->code." ".$mesg->error;
>                 return 1;
>         }
>         return 0;
> 
> 
> }
> 
> 
> 
> -- 
> 
> --------------------------------------------------------------------
> Yann Ramin			at...@at...
> Atrus Trivalie Productions	www.redshift.com/~yramin
> Monterey High IT		www.montereyhigh.com
> ICQ 				46805627
> AIM				oddatrus
> Marina, CA	
> 
> "All cats die.  Socrates is dead.  Therefore Socrates is a cat."
> 	- The Logician
> 	
> 	# fortune
> "To be responsive at this time, though I will simply say, and therefore
> this is a repeat of what I said previously, that which I am unable to
> offer in response is based on information available to make no such
> statement."
> --------------------------------------------------------------------
> 

FUnny return codes

[Yann R. <at...@at...>]

Hi,
Ok, I'm back and have a perplexing question to answer.  The code below
is supposed to add a user to a group, but dies in a funny error.  I have
the program output:

# ./X11UInfo
Entry: cn=Student, ou=System Groups, ou=Groups, dc=montereyhigh, dc=com
User: cn=He He, dc=montereyhigh,dc=com
83 object at /usr/lib/perl5/site_perl/5.6.0/Convert/ASN1/_encode.pm line
47. 



And code:

sub add_user_to_group {
        my ($self, $user, $group) = @_;

        if ($self->user_in_group($user, $group) != 1) {
                # Already there my friend :)
                return 1;
        }

        my $mesg = $self->{LDAP}->search (  # perform a search
                base   => "ou=Groups, ".$self->{ldap_config_base},
                filter => "(&(cn=".$group.")(objectclass=groupofNames))"
        );
        my @entries = $mesg->entries;
        my $entr = @entries[0];
        my $entry = $entr->dn;

        print "Entry: $entry\nUser: $user\n";
        my $mesg = $self->{LDAP}->modify($dn,
                changes =>      [
                        add     =>      [       member  =>      $user  
]
                ]
        );
        if ($mesg->code) {
                print $mesg->code." ".$mesg->error;
                return 1;
        }
        return 0;


}



-- 

--------------------------------------------------------------------
Yann Ramin			at...@at...
Atrus Trivalie Productions	www.redshift.com/~yramin
Monterey High IT		www.montereyhigh.com
ICQ 				46805627
AIM				oddatrus
Marina, CA	

"All cats die.  Socrates is dead.  Therefore Socrates is a cat."
	- The Logician
	
	# fortune
"To be responsive at this time, though I will simply say, and therefore
this is a repeat of what I said previously, that which I am unable to
offer in response is based on information available to make no such
statement."
--------------------------------------------------------------------

BOF session at Open Source Convention

[Clif H. <c-h...@ti...>]

I have requested a formal Birds-Of-A-Feather session 
at the O'Reilly Open Source Convection.  Topic will 
be LDAP and Perl LDAP.

The day requested was Tuesday.
   
As information becomes available I will post it to
the list.

Regards,

Clif Harden           INTERNET:  c-h...@ti...

Re: resultCode vs API error code (Was: Testing successful bind)

[Kurt D. Z. <Ku...@Op...>]

At 03:46 PM 6/12/00 +0100, Graham Barr wrote:
>> You might consider using the value -1 instead of LDAP_LOCAL_ERROR
>> for this purpose.  A server (incorrectly) could (and, IIRC, have)
>> returned the localError code.  The "liberal in what you accept,
>> strict in what you produce rule" suggests the API should be able
>> to handle this as any other unknown or unrecognized result code.
>> It's my view that APIs should pass result codes through to the
>> application as the API may not be aware of the extension (extended
>> op/control) in use which caused the unrecognized (or unknown) result
>> code to be produced in the first place.  Of course, applications
>> should treat any unrecognized result code as an unknown error.
>
>Hm, good point. Given that protocol error codes are non-negative.

One minor clarification.  A really broken server could return
a negative value inside the PDU resultCode INTEGER.  I suggest
that this should be treated as you would any other API detected
protocol error.

Re: resultCode vs API error code (Was: Testing successful bind)

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

On Mon, Jun 12, 2000 at 07:20:16AM -0700, Kurt D. Zeilenga wrote:
> At 11:04 AM 6/12/00 +0100, Graham Barr wrote:
> >On Fri, Jun 09, 2000 at 07:15:36AM -0700, Kurt D. Zeilenga wrote:
> >> At 11:35 PM 6/8/00 -0700, Paul Heinlein wrote:
> >> >On Thu, 8 Jun 2000, Yann Ramin wrote:
> >> >
> >> >> I've noticed that no error code is returned when a bind operation uses
> >> >> invalid credentials.  ?  How can I test if a bind was successful or
> >> >> not?  This is my main LDAP authentication scheme :)
> >> 
> >> Return of a success resultCode.
> >
> >> For the upcoming C API specification, the authors and I
> >> are discussing two approaches to resolve this issue.
> >> 	1) have API routines return an API error code
> >> 		and provide separately protocol results
> >> 		(including resultCode)
> >> 	2) using negative values codes to indicate
> >> 		API error codes (because resultCodes must be
> >> 		non-negative).
> >> 
> >> If I was designing a new API, I'd choose option 1.  With
> >> the C API, some (not I) prefer option 2 because it is
> >> less intrusive to older programs.  And some are
> >> willing to assume that clients and servers will be
> >> well behaved (despite operational experience to the
> >> contrary).
> >> 
> >> It appears that net:::LDAP makes the same mistake.
> >
> >Maybe, but that is only because to some extent it was based on the C API.
> 
> Basing anything on RFC 1823 (Informational) C API (or latest IETF
> C API drafts) is unwise.  It's error handling is known to be
> inadequate and fundamentally flawed.  I've been working with the
> IETF on a new C API specification.  We are currently discussing
> how to redesign the API to provide appropriate error handling.
> 
> We've come done (I hope), to these basic conclusions:
> 	1) the application must be able to determine an API
> 	failure has occurred.
> 	2) the application must be able to distinguish an
> 	API failure from any and all possible protocol results.
> 	3) the application must be provided with unmodified
> 	protocol results.
> 
> Though we are still discussing the options, and they do vary,
> I suspect we'll either a) completely separate API error handling
> from protocol result handling or b) separate the code
> space (negative API error codes).

I would suggest a hybrid. Have one value in the protocol error code
space that indicates a client API error. Information about the exact
error in the client API can be help elsewhere.


> >Having to check two places for an error is not optimal.
> 
> But, given extensions and control unknown to the API,
> what result codes indicate a successful protocol operation?

That is the whole point. The API cannot know, only the user knows what codes
to expect. So unless local API codes and protocol codes can live in the
same space you are forcing the programmer to do two checks just to
determine if there was an error. IMO that is quite an overhead for error checking.

All I am suggesting is that one value in the protocol error codes be used
to indicate a local error. local error handling itself can have a different
space. That way there is only one place to initially check that there was an error.


> >I had always planned to extend the current scheme to allow better local
> >errors. But I intended to do this by using a single code from the protocol
> >(LDAP_LOCAL_ERROR) and then have the Message object store extended information
> >about the local error.
> 
> You might consider using the value -1 instead of LDAP_LOCAL_ERROR
> for this purpose.  A server (incorrectly) could (and, IIRC, have)
> returned the localError code.  The "liberal in what you accept,
> strict in what you produce rule" suggests the API should be able
> to handle this as any other unknown or unrecognized result code.
> It's my view that APIs should pass result codes through to the
> application as the API may not be aware of the extension (extended
> op/control) in use which caused the unrecognized (or unknown) result
> code to be produced in the first place.  Of course, applications
> should treat any unrecognized result code as an unknown error.

Hm, good point. Given that protocol error codes are non-negative.

Graham.

Re: newbie question: moddn

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

On Mon, Jun 12, 2000 at 02:00:15PM +0300, Vitaly Kroivets wrote:
> 
> Thanks! Now I upgraded to 0.19 (it is latest, isn't it?) and it seems to be ok.

Yes, it is right now. New releases will be announced on the list. Or you can watch
the Net::LDAP module on the sourceforge page http://sourceforge.net/project/?group_id=5050

Graham.

Re: resultCode vs API error code (Was: Testing successful bind)

[Kurt D. Z. <Ku...@Op...>]

At 11:04 AM 6/12/00 +0100, Graham Barr wrote:
>On Fri, Jun 09, 2000 at 07:15:36AM -0700, Kurt D. Zeilenga wrote:
>> At 11:35 PM 6/8/00 -0700, Paul Heinlein wrote:
>> >On Thu, 8 Jun 2000, Yann Ramin wrote:
>> >
>> >> I've noticed that no error code is returned when a bind operation uses
>> >> invalid credentials.  ?  How can I test if a bind was successful or
>> >> not?  This is my main LDAP authentication scheme :)
>> 
>> Return of a success resultCode.
>
>> For the upcoming C API specification, the authors and I
>> are discussing two approaches to resolve this issue.
>> 	1) have API routines return an API error code
>> 		and provide separately protocol results
>> 		(including resultCode)
>> 	2) using negative values codes to indicate
>> 		API error codes (because resultCodes must be
>> 		non-negative).
>> 
>> If I was designing a new API, I'd choose option 1.  With
>> the C API, some (not I) prefer option 2 because it is
>> less intrusive to older programs.  And some are
>> willing to assume that clients and servers will be
>> well behaved (despite operational experience to the
>> contrary).
>> 
>> It appears that net:::LDAP makes the same mistake.
>
>Maybe, but that is only because to some extent it was based on the C API.

Basing anything on RFC 1823 (Informational) C API (or latest IETF
C API drafts) is unwise.  It's error handling is known to be
inadequate and fundamentally flawed.  I've been working with the
IETF on a new C API specification.  We are currently discussing
how to redesign the API to provide appropriate error handling.

We've come done (I hope), to these basic conclusions:
	1) the application must be able to determine an API
	failure has occurred.
	2) the application must be able to distinguish an
	API failure from any and all possible protocol results.
	3) the application must be provided with unmodified
	protocol results.

Though we are still discussing the options, and they do vary,
I suspect we'll either a) completely separate API error handling
from protocol result handling or b) separate the code
space (negative API error codes).

>However, I think the current approach is close to what is wanted.

I understand that simplicity of interface is desirable.
However, overloading/masking protocol results is a dangerous
simplification.

>Having to check two places for an error is not optimal.

But, given extensions and control unknown to the API,
what result codes indicate a successful protocol operation?

>I had always planned to extend the current scheme to allow better local
>errors. But I intended to do this by using a single code from the protocol
>(LDAP_LOCAL_ERROR) and then have the Message object store extended information
>about the local error.

You might consider using the value -1 instead of LDAP_LOCAL_ERROR
for this purpose.  A server (incorrectly) could (and, IIRC, have)
returned the localError code.  The "liberal in what you accept,
strict in what you produce rule" suggests the API should be able
to handle this as any other unknown or unrecognized result code.
It's my view that APIs should pass result codes through to the
application as the API may not be aware of the extension (extended
op/control) in use which caused the unrecognized (or unknown) result
code to be produced in the first place.  Of course, applications
should treat any unrecognized result code as an unknown error.

Kurt

Re: newbie question: moddn

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

As long as the base of DN doesn't change, you can change your first
component (the RDN) to whatever you want, just as long as it remains
unique.

Mark
 On Mon, 12 Jun 2000, Vitaly Kroivets wrote:

> 
> Thanks! Now I upgraded to 0.19 (it is latest, isn't it?) and it seems to be ok.
> 
> BTW,Is it possible to change dn , so that it will contain uid instead of cn ?
> I.e,Can I change dn "cn=Tuzik,ou=People,o=tiogatech.com" to dn                
>  "uid=12345,ou=People,o=tiogatech.com" with  function moddn ?                
> 
> Thanks in advance,
> 	Vitaly
> 
> 
> > >    
> 
> On Mon, 12 Jun 2000, Graham Barr wrote:
> 
> > This sounds like the problem which was fixed on version 0.19,
> > what version do you have ?
> > 
> > Graham.
> > 
> > On Sat, Jun 10, 2000 at 12:06:49PM +0200, Vitaly Kroivets wrote:
> > > Hello,
> > >   I just downloaded the perl-ldap and try to use its functions.
> > >   I have  problem in following code:
> > > 
> > >   my $result = $ldap->moddn("cn=Tuzik,ou=People,o=tiogatech.com",
> > >                 newrdn => "cn=Ttuzzikk I");
> > > 
> > >   if ($result->code) {
> > >           print "Some error occured while moddn ... \n",
> > >                 ldap_error_name($result->code),":",
> > >                 ldap_error_text($result->code),"\n";
> > >         }
> > > 
> > > I get error message:
> > > 
> > > LDAP_ENCODING_ERROR:C<Net::LDAP> encountered an error while encoding the
> > > request packet that would
> > > have been sent to the server
> > > 
> > > 1)Can you please help me ? What is wrong with this code?
> > > 2)Can I change dn "cn=Tuzik,ou=People,o=tiogatech.com" to dn
> > > "uid=12345,ou=People,o=tiogatech.com" with  function moddn ?
> > > 
> > > Thanks in advance!
> > >                                 Vitaly
> > > 
> > 
> 
> ==============================================
> Vitaly Kroivets, System Manager  
> Email: vi...@si...
>        vi...@ti...
> Phones: 
>         Work: 972-2-6491424 
> ==============================================
> 
> 
> 

Re: newbie question: moddn

[Vitaly K. <vi...@ti...>]

Thanks! Now I upgraded to 0.19 (it is latest, isn't it?) and it seems to be ok.

BTW,Is it possible to change dn , so that it will contain uid instead of cn ?
I.e,Can I change dn "cn=Tuzik,ou=People,o=tiogatech.com" to dn                
 "uid=12345,ou=People,o=tiogatech.com" with  function moddn ?                

Thanks in advance,
	Vitaly


> >    

On Mon, 12 Jun 2000, Graham Barr wrote:

> This sounds like the problem which was fixed on version 0.19,
> what version do you have ?
> 
> Graham.
> 
> On Sat, Jun 10, 2000 at 12:06:49PM +0200, Vitaly Kroivets wrote:
> > Hello,
> >   I just downloaded the perl-ldap and try to use its functions.
> >   I have  problem in following code:
> > 
> >   my $result = $ldap->moddn("cn=Tuzik,ou=People,o=tiogatech.com",
> >                 newrdn => "cn=Ttuzzikk I");
> > 
> >   if ($result->code) {
> >           print "Some error occured while moddn ... \n",
> >                 ldap_error_name($result->code),":",
> >                 ldap_error_text($result->code),"\n";
> >         }
> > 
> > I get error message:
> > 
> > LDAP_ENCODING_ERROR:C<Net::LDAP> encountered an error while encoding the
> > request packet that would
> > have been sent to the server
> > 
> > 1)Can you please help me ? What is wrong with this code?
> > 2)Can I change dn "cn=Tuzik,ou=People,o=tiogatech.com" to dn
> > "uid=12345,ou=People,o=tiogatech.com" with  function moddn ?
> > 
> > Thanks in advance!
> >                                 Vitaly
> > 
> 

==============================================
Vitaly Kroivets, System Manager  
Email: vi...@si...
       vi...@ti...
Phones: 
        Work: 972-2-6491424 
==============================================

Re: newbie question: moddn

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

This sounds like the problem which was fixed on version 0.19,
what version do you have ?

Graham.

On Sat, Jun 10, 2000 at 12:06:49PM +0200, Vitaly Kroivets wrote:
> Hello,
>   I just downloaded the perl-ldap and try to use its functions.
>   I have  problem in following code:
> 
>   my $result = $ldap->moddn("cn=Tuzik,ou=People,o=tiogatech.com",
>                 newrdn => "cn=Ttuzzikk I");
> 
>   if ($result->code) {
>           print "Some error occured while moddn ... \n",
>                 ldap_error_name($result->code),":",
>                 ldap_error_text($result->code),"\n";
>         }
> 
> I get error message:
> 
> LDAP_ENCODING_ERROR:C<Net::LDAP> encountered an error while encoding the
> request packet that would
> have been sent to the server
> 
> 1)Can you please help me ? What is wrong with this code?
> 2)Can I change dn "cn=Tuzik,ou=People,o=tiogatech.com" to dn
> "uid=12345,ou=People,o=tiogatech.com" with  function moddn ?
> 
> Thanks in advance!
>                                 Vitaly
> 

Re: Trouble installing 0.19...

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

On Fri, Jun 09, 2000 at 02:59:28PM +0100, Hd...@DT... wrote:
> On Fri, 9 Jun 2000, Chris Ridd wrote:
> 
> > I recall seeing a note from Graham somewhere saying that this was OK. 
> > Just copy the contents of the 'lib' directory (not the directory 
> > itself) to where your perl gets site-specific modules from.
> 
> Thanks. I extracted the files from the tarball and noticed the documentation 
> contained an FAQ. In there I found the same info.

Wow, someone read the FAQ :)

> > Straight to Graham would be best, unless the changes are controversial 
> > in any way. (Fixing typos isn't too controversial though.)
> 
> OK, I'll check if the typos are still in the Net::Utils. If so, I'll send a
> diff file to Graham. 

Well I have been having problems with mail since Friday, so if you have sent it
I ahve not got it yet.

> First I need to rewrite a whole lot of scripts that used the older version. As 
> it is now the new install has broken them. I need to find out what precisely 
> has changed an get them up and running again before I do anything else (just
> hope that won't be too much work). 'Till then I've reverted back to the 
> previously installed package as that worked flawlessly for me (even though I 
> had to do some workarounds to prevent problems in some of the more peculiar 
> situations).

Well some people see it as a bad thing that Net::LDAP is still changing this much,
but other see it as good.

But then Net::LDAP is still very early in it's life and trying to find direction. Even
though it has now been around for over two years.

Hopefully with more people being interested and contributing Net::LDAP can find
it's direction and settle down. Who knows we may someday release version 1.00 :)

Graham.

Re: Trouble installing 0.19...

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

On Fri, Jun 09, 2000 at 12:40:59PM +0100, Chris Ridd wrote:
> On Fri, 09 Jun 2000 13:31:40 BST, Hd...@DT... wrote:
> > Alternatively, since there are no things to be compiled as far as I did
> > see, would it be a problem if I copied things by hand to their appropriate
> > directories (I should be able to figure those out myself)?
> 
> I recall seeing a note from Graham somewhere saying that this was OK. 
> Just copy the contents of the 'lib' directory (not the directory 
> itself) to where your perl gets site-specific modules from.

Yes for Net::LDAP this should be OK as AutoLoader is not used.

> > P.S. I noticed there were some typos in the LDAP_error message
> > descriptions (in my old version of perl-ldap that is). If they are still
> > in there (I'll check as soon as I get this thing running) where do I send
> > the corrected texts? Direct to Graham or to this list?
> 
> Straight to Graham would be best, unless the changes are controversial 
> in any way. (Fixing typos isn't too controversial though.)

Right. This goes for anything, code or docs. But I do prefer most communication
to be via the list, because there are many people on this list that know more about
LDAP than I do.

Graham.

Re: Testing sucessful bind

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

On Sat, Jun 10, 2000 at 01:23:58PM -0700, Yann Ramin wrote:
> I thought I sent this out in a second message, but here it goes again. 
> I have figured that Net::LDAP is not capable of keeping two server
> connections alive at any one time.  This following code example works,
> mainly because the first server is unbound and destroyed before the
> second connection is started.

There should be no reason why not. Net::LDAP does not use any local data
that would cause this problem.

Are you using a threaded perl by any chance ?

Graham.

Re: resultCode vs API error code (Was: Testing successful bind)

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

On Fri, Jun 09, 2000 at 07:15:36AM -0700, Kurt D. Zeilenga wrote:
> At 11:35 PM 6/8/00 -0700, Paul Heinlein wrote:
> >On Thu, 8 Jun 2000, Yann Ramin wrote:
> >
> >> I've noticed that no error code is returned when a bind operation uses
> >> invalid credentials.  ?  How can I test if a bind was successful or
> >> not?  This is my main LDAP authentication scheme :)
> 
> Return of a success resultCode.

> For the upcoming C API specification, the authors and I
> are discussing two approaches to resolve this issue.
> 	1) have API routines return an API error code
> 		and provide separately protocol results
> 		(including resultCode)
> 	2) using negative values codes to indicate
> 		API error codes (because resultCodes must be
> 		non-negative).
> 
> If I was designing a new API, I'd choose option 1.  With
> the C API, some (not I) prefer option 2 because it is
> less intrusive to older programs.  And some are
> willing to assume that clients and servers will be
> well behaved (despite operational experience to the
> contrary).
> 
> It appears that net:::LDAP makes the same mistake.

Maybe, but that is only because to some extent it was based on the C API.

However, I think the current approach is close to what is wanted.

Having to check two places for an error is not optimal.

I had always planned to extend the current scheme to allow better local
errors. But I intended to do this by using a single code from the protocol
(LDAP_LOCAL_ERROR) and then have the Message object store extended information
about the local error.

This still allows people to write code only check one place for an error.

Graham.

Re: Testing sucessful bind

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

My ISP has been having mail trouble, so I am behind on mail. I am only
able to reply to this because I downloaded the mbox from www.xray.mpe.mpg.de

On Fri, Jun 09, 2000 at 08:46:43AM +0100, Chris Ridd wrote:
> On Thu, 08 Jun 2000 22:18:26 CDT, Mark Wilcox wrote:
> > No that's not true (or at least shouldn't be, I haven't tested this in
> > Net::LDAP v .19 to make sure it wasn't broken). You should get error code
> > 49.
> > How are you checking, this is how the code should look:
> > my $mesg = $ldap->bind($dn, password=>"password");
> > 
> > die ("failed to bind ",$mesg->code(),"\n") if $mesg->code();
> > 
> > mark
> 
> You should use 'dn => $dn' instead of just a plain $dn, I think.

Actually they will both work.

> One additional point to note is that the following:
> 
> my $mesg = $ldap->bind(dn => $dn, password=>"password") or die;
> 
> does *not* call 'die' if the server rejects the bind. It only calls 
> 'die' if something nasty has happened inside Net::LDAP, which is not 
> the same thing at all.
> 
> Graham, would it be more sensible for Net::LDAP to just call die itself 
> instead of returning undef on failure? It would mean clients would have 
> to wrap more calls inside eval { } but I'm not sure that's a bad thing.

There should be no case in which it will return undef. It should always return
a Message object. If there were local errors Net::LDAP will set the error
code in the object.

Graham.

Re: Testing sucessful bind

[Yann R. <at...@at...>]

I thought I sent this out in a second message, but here it goes again. 
I have figured that Net::LDAP is not capable of keeping two server
connections alive at any one time.  This following code example works,
mainly because the first server is unbound and destroyed before the
second connection is started.

sub auth {
        my ($self, $uid, $passwd) = @_;

        $entry = $self->get_user_id($uid);	# Get DN based on uidNumber,
cn, or uid, which is $uid

        $self->{LDAP}->unbind;
        undef $self->{LDAP};

        $self->{AUTHLDAP} =  Net::LDAP->new("192.168.0.41") or die "$@";
        my $mesg = $self->{AUTHLDAP}->bind($entry, password => $passwd);



        $self->{LDAP} =  Net::LDAP->new("192.168.0.41") or die "$@";
        $self->bind;
        if ($mesg->code) {
                $self->{AUTHLDAP}->unbind;
                undef $self->{AUTHLDAP};
                return 1;
        }

        $self->{AUTHLDAP}->unbind;
        undef $self->{AUTHLDAP};
        return 0;


}


Graham Barr wrote:
> 
> There should be an error code. Can you show us some code that you
> are using.
> 
> Graham.
> 
> On Thu, Jun 08, 2000 at 02:57:51PM -0700, Yann Ramin wrote:


-- 

--------------------------------------------------------------------
Yann Ramin			at...@at...
Atrus Trivalie Productions	www.atrustrivalie.eu.org
				irm.it.montereyhigh.com
Monterey High IT		www.montereyhigh.com
ICQ 				46805627
AIM				oddatrus
Marina, CA	

"All cats die.  Socrates is dead.  Therefore Socrates is a cat."
	- The Logician
	
	# fortune
"To be responsive at this time, though I will simply say, and therefore
this is a repeat of what I said previously, that which I am unable to
offer in response is based on information available to make no such
statement."
--------------------------------------------------------------------

newbie question: moddn

[Vitaly K. <vi...@ti...>]

Hello,
  I just downloaded the perl-ldap and try to use its functions.
  I have  problem in following code:

  my $result = $ldap->moddn("cn=Tuzik,ou=People,o=tiogatech.com",
                newrdn => "cn=Ttuzzikk I");

  if ($result->code) {
          print "Some error occured while moddn ... \n",
                ldap_error_name($result->code),":",
                ldap_error_text($result->code),"\n";
        }

I get error message:

LDAP_ENCODING_ERROR:C<Net::LDAP> encountered an error while encoding the
request packet that would
have been sent to the server

1)Can you please help me ? What is wrong with this code?
2)Can I change dn "cn=Tuzik,ou=People,o=tiogatech.com" to dn
"uid=12345,ou=People,o=tiogatech.com" with  function moddn ?

Thanks in advance!
                                Vitaly

Re: Testing sucessful bind

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

There should be an error code. Can you show us some code that you
are using.

Graham.

On Thu, Jun 08, 2000 at 02:57:51PM -0700, Yann Ramin wrote:
> Hi,
> 
> I've noticed that no error code is returned when a bind operation uses
> invalid credentials.  ?  How can I test if a bind was successful or
> not?  This is my main LDAP authentication scheme :)

resultCode vs API error code (Was: Testing successful bind)

[Kurt D. Z. <Ku...@Op...>]

At 11:35 PM 6/8/00 -0700, Paul Heinlein wrote:
>On Thu, 8 Jun 2000, Yann Ramin wrote:
>
>> I've noticed that no error code is returned when a bind operation uses
>> invalid credentials.  ?  How can I test if a bind was successful or
>> not?  This is my main LDAP authentication scheme :)

Return of a success resultCode.

One of the major problems with the C API is that it confuses
server resultCodes with API error codes.  This was a MAJOR
mistake.  A server may return any non-negative value as a
resultCode and clients must treat any unknown value as
an unknown value.  So, say the API returns a non-reserved
code of 0x77.  Is this a resultCode or an API error code?
it could be either.

Note that RFC 2251 reserves a limited set of resultCodes
for API use.  However, API need more than this limited set.
And servers have been known to return resultCodes for
APIs.  This is problematic and will always be so.  The
only way to avoid the problem is to have a clear and
distinct separation of API error codes and protocol result
codes.

For the upcoming C API specification, the authors and I
are discussing two approaches to resolve this issue.
	1) have API routines return an API error code
		and provide separately protocol results
		(including resultCode)
	2) using negative values codes to indicate
		API error codes (because resultCodes must be
		non-negative).

If I was designing a new API, I'd choose option 1.  With
the C API, some (not I) prefer option 2 because it is
less intrusive to older programs.  And some are
willing to assume that clients and servers will be
well behaved (despite operational experience to the
contrary).

It appears that net:::LDAP makes the same mistake.

>  # Hmm. Probably the password is bad. We'll try an
>  # anonymous bind just to make sure the server's running

The server may disallow anonymous binds.  However, it
should return an bind response whether successful or not
and this can be used to test server availability.

Re: Testing sucessful bind

[Paul H. <hei...@cs...>]

On Thu, 8 Jun 2000, Yann Ramin wrote:

> I've noticed that no error code is returned when a bind operation uses
> invalid credentials.  ?  How can I test if a bind was successful or
> not?  This is my main LDAP authentication scheme :)

I noticed the same thing. Here's my workaround:

print qq(Binding to LDAP database...\n);
my $ldap = Net::LDAP->new( $ldaphost ) or die;
my $msg  = $ldap->bind( $rootuser, password => $pass );

if ( $msg->code ) {
  # Hmm. Probably the password is bad. We'll try an
  # anonymous bind just to make sure the server's running
  my $test = $ldap->bind;

  if ( $test->code ) {
    # hmm, the server's down
    print "*** The LDAP server seems to be down. Sorry. ***\n";
  } else {
    # yep, the password must be bad.
    $ldap->unbind;
    print "*** Please check the password and try again. ***\n";
  }

  exit 1;
}


. Paul Heinlein  <hei...@cs...> . . . . . . . .
.                                                     .
. Webmaster, Systems Administrator                    .
. Department of Computer Science and Engineering      .
. Oregon Graduate Institute of Science and Technology .
. Beaverton, Oregon, USA                              .
.                                                     .
. 503-748-1199      http://www.cse.ogi.edu/~heinlein/ .
. . . . . . . . . . . . . . . . . . . . . . . . . . . .

Re: Trouble installing 0.19...

[<Hd...@DT...>]

On Fri, 9 Jun 2000, Chris Ridd wrote:

> I recall seeing a note from Graham somewhere saying that this was OK. 
> Just copy the contents of the 'lib' directory (not the directory 
> itself) to where your perl gets site-specific modules from.

Thanks. I extracted the files from the tarball and noticed the documentation 
contained an FAQ. In there I found the same info.

> Straight to Graham would be best, unless the changes are controversial 
> in any way. (Fixing typos isn't too controversial though.)

OK, I'll check if the typos are still in the Net::Utils. If so, I'll send a
diff file to Graham. 

First I need to rewrite a whole lot of scripts that used the older version. As 
it is now the new install has broken them. I need to find out what precisely 
has changed an get them up and running again before I do anything else (just
hope that won't be too much work). 'Till then I've reverted back to the 
previously installed package as that worked flawlessly for me (even though I 
had to do some workarounds to prevent problems in some of the more peculiar 
situations).

Grx HdV

-- 
A television may insult your intelligence, 
but nothing rubs it in like a computer.

J.A. de Vries aka HdV
Delft University of Technology
Computing Centre

Email: J.A...@DT...
Email: Hd...@DT...

Re: Trouble installing 0.19...

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

On Fri, 09 Jun 2000 13:31:40 BST, Hd...@DT... wrote:
> Alternatively, since there are no things to be compiled as far as I did
> see, would it be a problem if I copied things by hand to their appropriate
> directories (I should be able to figure those out myself)?

I recall seeing a note from Graham somewhere saying that this was OK. 
Just copy the contents of the 'lib' directory (not the directory 
itself) to where your perl gets site-specific modules from.

> Thanks a lot.
> 
> Grx HdV
> 
> P.S. I noticed there were some typos in the LDAP_error message
> descriptions (in my old version of perl-ldap that is). If they are still
> in there (I'll check as soon as I get this thing running) where do I send
> the corrected texts? Direct to Graham or to this list?

Straight to Graham would be best, unless the changes are controversial 
in any way. (Fixing typos isn't too controversial though.)

Cheers,

Chris