perl-ldap-dev

Net::LDAP Search Criteria returns null values

[anil m. <ani...@ya...>]

Hi,

I am using Net::LDAP and protocol version 3.
I am getting a typical problem that I am not
able to get values from server though receiving
attributes list.

My bind is successful.
Giving exact base, filter and attr parameters.
Still not getting values from server.
I am sure that the particular values are present
in the server.

I am using either cases like

my $href = $result->as_struct;
my @arrayOfDNs  = keys %$href ;
foreach (@arrayOfDNs) {
  print $_,"\n";
  my $valref = $$href{$_};

  my @arrayOfAttrs = sort keys %$valref; 
  my $attrName;	
  foreach $attrName (@arrayOfAttrs) {
    next if ( $attrName =~ /;binary$/ );
    my $attrVal =  @$valref{$attrName} ;
    print "\t $attrName: @$attrVal \n";
  }
}
#  end of as_struct method

--------------------------------------

#using the walk through method
my @entries = $result->entries;

my $entr ;
foreach $entr ( @entries )
{
  print "DN: ",$entr->dn,"\n";
  my $attr;
  foreach $attr ( sort $entr->attributes ){
    next if ( $attr =~ /;binary$/ );
    print "  $attr : ",$entr->get_value($attr),"\n";
  }
}
# end of walk through method

-----------------------------------------

I appreciate your cooperation in finding solution
for this.

Thanks,
Anil.


__________________________________________________
Do You Yahoo!?
Yahoo! Auctions - buy the things you want at great prices
http://auctions.yahoo.com/

Re: [Fwd] Net::LDAP patch

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

Chris Ridd <chr...@me...> wrote:
> Graham Barr <gb...@po...> wrote:
>> ----- Forwarded message from Scott Bruce <sc...@te...> -----
>> 
>> Date: Fri, 11 May 2001 22:14:27 -0700
>> To: gb...@po...
>> From: Scott Bruce <sc...@te...>
>> Subject: Net::LDAP patch
>> X-Mailer: Microsoft Outlook Express 6.00.2465.0000
>> 
>> Hi Graham,
>> 
>> attached is the diff output from a quick patch I had to hack into
>> Net::LDAP to get the schema stuff working with openldap 2.0.7 :-).  by
>> default openldap only returns attribute data for 'objectclass' and 'cn'
>> if you request the subschema object, weird, so appending the other
> 
> No, that's sort of OK. The root DSE is handled a bit vaguely in the LDAP
> RFCs - to access it you should really use a manageDsaIT Control (which is
> not defined by any RFCs) because it is not a normal entry in the DIT. In
> the absence of this standard control servers are either 'helpful' and
> return all the (operational) attributes - pretending the control's been
> set, effectively - or 'strict' and don't.

I should add that there is a non-standard manageDsaIT control. It is
described in section 8 of draft-zeilenga-ldap-namedref-00.txt, of which
this is an excerpt:

====
  The control type is 2.16.840.1.113730.3.4.2.  The control criticality
  may be TRUE or FALSE.  There is no value; the controlValue field is
  absent.
====

Cheers,

Chris

Re: [Fwd] Net::LDAP patch

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

Graham Barr <gb...@po...> wrote:
> ----- Forwarded message from Scott Bruce <sc...@te...> -----
> 
> Date: Fri, 11 May 2001 22:14:27 -0700
> To: gb...@po...
> From: Scott Bruce <sc...@te...>
> Subject: Net::LDAP patch
> X-Mailer: Microsoft Outlook Express 6.00.2465.0000
> 
> Hi Graham,
> 
> attached is the diff output from a quick patch I had to hack into
> Net::LDAP to get the schema stuff working with openldap 2.0.7 :-).  by
> default openldap only returns attribute data for 'objectclass' and 'cn'
> if you request the subschema object, weird, so appending the other

No, that's sort of OK. The root DSE is handled a bit vaguely in the LDAP
RFCs - to access it you should really use a manageDsaIT Control (which is
not defined by any RFCs) because it is not a normal entry in the DIT. In
the absence of this standard control servers are either 'helpful' and
return all the (operational) attributes - pretending the control's been
set, effectively - or 'strict' and don't.

For normal entries, servers are not supposed to return any operational
attributes that have not explicitly been requested. Clearly this is what
the OpenLDAP server is doing with the root.

> attribute names is neccessary if you want to do anything with the
> subschema object (like use it with Net::LDAP::Schema..).

That change was included as part of the rejig of the schema code in 0.23,
except that we also retrieve the ldapSyntaxes attribute as well.

> I found a small problem with Net::LDAP::Schema too; if an objectclass is
> missing MUST or MAY tokens (?) in the schema then Net::LDAP::Schema will
> barf when trying to construct a list of attributes for that
> objectclass....

There looks to be some code in the current Net::LDAP::Schema.pm file that
deals with this situation too.

Try getting the latest version of Net::LDAP!

Cheers,

Chris

new FAQ is out

[Clif H. <ch...@po...>]

I have updated the Perl-LDAP FAQ.


I added a section on deleting referrals. This needs
to be checked out to make sure I got everything correct.


I added a section on what happens when you delete
an attribute that does not exist.

The FAQ is currently available at the following URL
http://www.utdallas.edu/~charden/FAQ.html

The FAQ has been checked into CVS.

Due to a permission problem that was probably created
when sourceforge moved project and home directories, I have
NOT been able to update the FAQ on the perl-ldap web page.

As soon as the permission problem is corrected I will 
update the web page FAQ.
 
Regards,

Clif Harden          ch...@po...

The Perl Conference

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

As many already know I will be giving a tutorial on Net::LDAP at the perl
conference this year.

However here is your chnace at a sneak preview and hopefully give me
some feednack. The slides I have done so far are at

  http://monty.mutatus.co.uk/~gbarr/TPC/img0.htm

I am still writing the slides, but I am running out of time fast.

Any feeback is most welcome.

After the conference I will place the complete set of slides on the perl-ldap
website

Graham.

Re: FW: Net::LDAP::LDIF

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

On Fri, May 11, 2001 at 05:39:22PM -0700, Robbie Allen wrote:

> If the changes are acceptable, I'll also modify LDIF.pod to include the new
> syntax along with write_entry() examples.

Looks good to me, except the default for onerror should be undef IMO.

Excellent, Thanks,
Graham.

Re: FW: Net::LDAP::LDIF

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

On Thu, May 10, 2001 at 04:57:44PM -0700, Robbie Allen wrote:
> Which entry are you talking about in 52-mod.ldif that failed test 47?
> 
> I'll send out the changes to write soon.  I'm also going to add an eof()
> method so we can use that to test for completion of reading the file instead
> of read_entry (which can return undef).

Patch attached.

[Fwd] Net::LDAP patch

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

----- Forwarded message from Scott Bruce <sc...@te...> -----

Date: Fri, 11 May 2001 22:14:27 -0700
To: gb...@po...
From: Scott Bruce <sc...@te...>
Subject: Net::LDAP patch
X-Mailer: Microsoft Outlook Express 6.00.2465.0000

Hi Graham,

attached is the diff output from a quick patch I had to hack into Net::LDAP
to get the schema stuff working with openldap 2.0.7 :-).  by default
openldap only returns attribute data for 'objectclass' and 'cn' if you
request the subschema object, weird, so appending the other attribute names
is neccessary if you want to do anything with the subschema object (like use
it with Net::LDAP::Schema..).

I found a small problem with Net::LDAP::Schema too; if an objectclass is
missing MUST or MAY tokens (?) in the schema then Net::LDAP::Schema will
barf when trying to construct a list of attributes for that objectclass....

thanks for the great module.

-Scott



*** Net/LDAP.pm Fri May 11 20:57:31 2001
--- /usr/local/lib/perl5/site_perl/5.6.0/Net/LDAP.pm Thu Sep 14 11:53:39
2000
***************
*** 664,681 ****
    }

    $mesg = $self->search(
      base   => $base,
      scope  => 'base',
-     ## 2001-05-11 ; openldap 2.0.x only returns cn && objectclass by
default,
-     ## so explicitly request other attributes plus the defaults
-     attrs => [
-       'dITStructureRules', 'nameForms', 'ditContentRules',
-       'attributeTypes', 'objectClasses', 'matchingRules',
-       'matchingRuleUse', '*'
-     ],
-     ##
      filter => '(objectClass=*)',
    );

    $mesg->code
      ? undef
--- 664,673 ----
*** Net/LDAP/Schema.pm Fri May 11 20:31:05 2001
--- /usr/local/lib/perl5/site_perl/5.6.0/Net/LDAP/Schema.pm Wed Sep 13
08:08:05 2000
***************
*** 28,38 ****

    unless ($arg) {
      $schema->{error} = "Bad argument";
      return undef;
    }
!
    %$schema = ();

    my $entry;
    if( ref $arg ) {
      if (UNIVERSAL::isa($arg, 'Net::LDAP::Entry')) {
--- 28,38 ----

    unless ($arg) {
      $schema->{error} = "Bad argument";
      return undef;
    }
!
    %$schema = ();

    my $entry;
    if( ref $arg ) {
      if (UNIVERSAL::isa($arg, 'Net::LDAP::Entry')) {
***************
*** 202,214 ****
    my %res; # Use hash to get uniqueness

    foreach my $oc ( @oc ) {
      my $oid = $self->is_objectclass( $oc );
      if( $oid ) {
!       ## 2001-05-11 patch to avoid errors if MUST or MAY are undefined :-)
!       my $res = $self->{oid}->{$oid}->{$must_or_may} || [];
!       ## my $res = $self->{oid}->{$oid}->{$must_or_may};
        @res{ @$res } = (); # Add in, getting uniqueness
      }
    }

    return wantarray ? (keys %res) : [ keys %res ];
--- 202,212 ----
    my %res; # Use hash to get uniqueness

    foreach my $oc ( @oc ) {
      my $oid = $self->is_objectclass( $oc );
      if( $oid ) {
!       my $res = $self->{oid}->{$oid}->{$must_or_may};
        @res{ @$res } = (); # Add in, getting uniqueness
      }
    }

    return wantarray ? (keys %res) : [ keys %res ];




----- End forwarded message -----

RE: FW: Net::LDAP::LDIF

[Robbie A. <ra...@ci...>]

I've modified the write methods in LDIF.pm.  Attached is the patch for all
mod's I've made including the previous patch.  I got OpenLDAP setup on my
workstation, and LDIF.pm passed all the tests except for 47 and 56, which
was the case before my latest mods. 

To have a unified write_entry() method, I needed a way to distinguish when
someone wants to print out an $entry versus printing an $entry with a
changetype.  To do the latter, I'm requiring the user specify change => 1
when calling new().  I've made the write() and write_cmd() methods backward
compatible using the new write_entry() method and setting $self->{change}
appropriately.

I've also added an eof() method.

As I mentioned earlier, you used to have to do:
 
    $ldif = Net::LDAP::LDIF->new( "file.ldif", "r" );
    while( $entry = $ldif->read_entry() ) {
         # Do things with $entry
    }
    $ldif->done();

The problem is read_entry can return undef on errors.  So instead of
requiring the while loop to also check for $ldif->error, I added and
$ldif->eof method.  Now the above example would be written like this:

    $ldif = Net::LDAP::LDIF->new( "file.ldif", "r", onerror => 'undef' );
    while( not $ldif->eof ) {
        if ($entry = $ldif->read_entry) {
           # Do things with $entry
        }
        else {
           print "Error msg:\n",$ldif->error(),"\n";
           print "Error entry:\n",$ldif->error_entry(),"\n";
        }
    }
    $ldif->done();

If the changes are acceptable, I'll also modify LDIF.pod to include the new
syntax along with write_entry() examples.

Robbie Allen

> -----Original Message-----
> From: Robbie Allen [mailto:ra...@ci...]
> Sent: Thursday, May 10, 2001 4:58 PM
> To: 'Graham Barr'
> Cc: per...@li...
> Subject: RE: FW: Net::LDAP::LDIF
> 
> 
> Which entry are you talking about in 52-mod.ldif that failed test 47?
> 
> I'll send out the changes to write soon.  I'm also going to 
> add an eof()
> method so we can use that to test for completion of reading 
> the file instead
> of read_entry (which can return undef).
> 
> Robbie Allen
> 
> > -----Original Message-----
> > From: Graham Barr [mailto:gb...@po...]
> > Sent: Wednesday, May 09, 2001 5:44 PM
> > To: Robbie Allen; per...@li...
> > Subject: Re: FW: Net::LDAP::LDIF
> > 
> > 
> > OK, so this was down to bad test data.
> > 
> > The input LDIF for doing the modify had an entry which did 
> > not have a changetype: modify
> > line. Adding this in and the tests pass.
> > 
> > However the new code probably should have flagged a syntax 
> > error instead of what it
> > did.
> > 
> > Anyway the code looks good to me, so feel free to make 
> > similar changes to write
> > 
> > Graham.
> > 
> > On Thu, May 10, 2001 at 01:12:27AM +0100, Graham Barr wrote:
> > > Well it seems it is not 100% compatable.
> > > 
> > > $ SLAPD_EXE=/opt/openldap-1.2.11/libexec/slapd make test
> > > 
> > > t/00ldif-entry......ok
> > > t/01canon_dn........ok
> > > t/02filter..........ok
> > > t/50populate........ok
> > > t/51search..........ok
> > > t/52modify..........FAILED tests 47, 56
> > >         Failed 2/56 tests, 96.43% okay
> > > t/53schema..........ok
> > > Failed Test  Status Wstat Total Fail  Failed  List of failed
> > > 
> > --------------------------------------------------------------
> > -----------------
> > > t/52modify.t                 56    2   3.57%  47, 56
> > > Failed 1/7 test scripts, 85.71% okay. 2/347 subtests 
> > failed, 99.42% okay.
> > > *** Error code 2
> > > 
> > > I have not looked closly yet as it is getting late
> > > 
> > > Graham.
> > > 
> > > 
> > > On Thu, May 10, 2001 at 12:45:32AM +0100, Graham Barr wrote:
> > > > At first glance it looks OK to me.
> > > > 
> > > > Graham.
> > > > 
> > > > On Wed, May 09, 2001 at 04:09:52PM -0700, Robbie Allen wrote:
> > > > > Attached is a patch for LDIF.pm incorporating error 
> > handling using an
> > > > > onerror parameter in new() (just like in LDAP.pm) and a 
> > new read_entry()
> > > > > method.  read_entry() takes the place of read() and 
> > read_cmd() making both
> > > > > of those methods deprecated.  They will be removed in a 
> > future version.
> > > > > 
> > > > > Graham, let me know if I'm on the right track.  If so 
> > I'll work on the write
> > > > > methods next.
> > > > > 
> > > > > Robbie Allen
> > > > 
> > 
> 

RE: FW: Net::LDAP::LDIF

[Robbie A. <ra...@ci...>]

Which entry are you talking about in 52-mod.ldif that failed test 47?

I'll send out the changes to write soon.  I'm also going to add an eof()
method so we can use that to test for completion of reading the file instead
of read_entry (which can return undef).

Robbie Allen

> -----Original Message-----
> From: Graham Barr [mailto:gb...@po...]
> Sent: Wednesday, May 09, 2001 5:44 PM
> To: Robbie Allen; per...@li...
> Subject: Re: FW: Net::LDAP::LDIF
> 
> 
> OK, so this was down to bad test data.
> 
> The input LDIF for doing the modify had an entry which did 
> not have a changetype: modify
> line. Adding this in and the tests pass.
> 
> However the new code probably should have flagged a syntax 
> error instead of what it
> did.
> 
> Anyway the code looks good to me, so feel free to make 
> similar changes to write
> 
> Graham.
> 
> On Thu, May 10, 2001 at 01:12:27AM +0100, Graham Barr wrote:
> > Well it seems it is not 100% compatable.
> > 
> > $ SLAPD_EXE=/opt/openldap-1.2.11/libexec/slapd make test
> > 
> > t/00ldif-entry......ok
> > t/01canon_dn........ok
> > t/02filter..........ok
> > t/50populate........ok
> > t/51search..........ok
> > t/52modify..........FAILED tests 47, 56
> >         Failed 2/56 tests, 96.43% okay
> > t/53schema..........ok
> > Failed Test  Status Wstat Total Fail  Failed  List of failed
> > 
> --------------------------------------------------------------
> -----------------
> > t/52modify.t                 56    2   3.57%  47, 56
> > Failed 1/7 test scripts, 85.71% okay. 2/347 subtests 
> failed, 99.42% okay.
> > *** Error code 2
> > 
> > I have not looked closly yet as it is getting late
> > 
> > Graham.
> > 
> > 
> > On Thu, May 10, 2001 at 12:45:32AM +0100, Graham Barr wrote:
> > > At first glance it looks OK to me.
> > > 
> > > Graham.
> > > 
> > > On Wed, May 09, 2001 at 04:09:52PM -0700, Robbie Allen wrote:
> > > > Attached is a patch for LDIF.pm incorporating error 
> handling using an
> > > > onerror parameter in new() (just like in LDAP.pm) and a 
> new read_entry()
> > > > method.  read_entry() takes the place of read() and 
> read_cmd() making both
> > > > of those methods deprecated.  They will be removed in a 
> future version.
> > > > 
> > > > Graham, let me know if I'm on the right track.  If so 
> I'll work on the write
> > > > methods next.
> > > > 
> > > > Robbie Allen
> > > 
> 

Re: OpenLDAP and Net::LDAP

[Philip C. <pch...@go...>]

My answer to an extent lies in the following:

within the ## process entry section, a variable was being tested:

## $tmp is a hash ref, which contains keys which are attrs and
## values of $e->get_value(attr)

if($tmp->{uiCaps} =~ m#\brw\b#i) {
	## set vars
} else {
	## set vars
}

It was here that the code was failing. So this was a perl problem and not
a Net::LDAP one. Perl was for some reason unhappy to be accessing an undefined
key and simply hanging, to the point where it was not even processing the
if statement at all. I know becuase I put logging statements in both the if
and the else first, before the vars were set. Now I have the following:

if( exists($tmp->{uiCaps}) && $tmp->{uiCaps} =~ m#\brw\b#i) {
	## set vars
} else {
	## set vars
}


This works fine... I do not see why this would change things to the point that
my script does not hang... But it did fix the problem (this was the case with
both VA Linux/RH 7.0 (perl 5.6) and 6.2 (perl 5.005_03)  

Thus spake Philip Champon, on the year of our L*rd Thu, May 10, 2001 at 03:26:50PM -0400:
> ## PROCESSING USER ENTRIES
> ## 
> ## MIN is what ever the last page's MAX was + MAX + 1
> ## ie $oldmax = 5
> ##    $newmin = $oldmax + MAX + 1 # MAX == 5
> ##    $newmax = $newmin + MAX + 1
> for($i = $newmin; $i <= $newmax; $i++) {
> 	last if($i > $m->count()-1);
> 
> 	$e = $m->entry($i);
> 	## process entry
> }

-- 
Philip Champon Valueweb Developer
Ph - 954-334-8156
Em - pch...@va...

OpenLDAP and Net::LDAP

[Philip C. <pch...@go...>]

I have been experiencing a relatively strange problem using both OpenLDAP
and IBM Secure Way Directory. At this point I only care about OpenLDAP since
that is what we have chosen to go with...

In a nutshell, I am creating a CGI interface for maintaining email accounts.
One of its many functions is listing domains a reseller controls and listing
users within a given domain. The first time around I set the max records per
page (users or domains) to 25 and this worked... for a little while. I had some
problems, without changing code and decided to drop it to 20. Suddenly the
problems manifested again and I had to drop the limit of records to 10. That
worked for a bit and now I am down to 5 domains/users per page.

I setup some logging to see what was happening... Under some circumstances
I would get back the initial max records (5, 10, 20, 25) but if I hit the
'Next' button which had worked only moments before my processing would stop
prematurely on a record and not continue. It seems odd to me that I could
get the initial listing of x once but not again.

In a more detailed example, one domain has 100 users within it and for each
user there are two LDAP records totaling 201 records (one record for the user
and each user then posessing a branch from their user record) for the domain
(one for the domain itself). I search the base of the domain with Net::LDAP,
tho before I do that I need to do two other searches in the form of:

## in the interest of simplifying this already ugly example I have omitted error
## checking ... which really only checks to make sure the search returned ok

## summarize the total domain aliases
$m = $Ldap->search(
	base	=> 'dc=example, dc=com, dc=domains, dc=cluster00, dc=valuemail, dc=net',
	filter	=> '(&(objectclass=localMailRcpt)(objectclass=distList)(!(objectclass=user))(!(objectclass=autoResponder)))',

	## try to conserver mem by limiting amount returned
	attrs	=> [qw(mailLocaLaddr)],

	## only search directly above the domain entry in user name space
	scope	=> 'one'
);
$domainAliases = $m->count();

## hoping this frees resources?
$Ldap->abandon($m->mesg_id());

## summarize the total domain autoresponders
$m = $Ldap->search(
	base	=> 'dc=example, dc=com, dc=domains, dc=cluster00, dc=valuemail, dc=net',
	filter	=> '(&(objectclass=localMailRcpt)(objectclass=distList)(objectclass=autoResponder)(!(objectclass=user)))',

	## try to conserver mem by limiting amount returned
	attrs	=> [qw(mailLocaLaddr)],

	## only search directly above the domain entry in user name space
	scope	=> 'one'
);
$domainAutoReponders = $m->count();

## hoping this frees resources?
$Ldap->abandon($m->mesg_id());

## then grab a list of users
$m = $Ldap->search(
	base	=> 'dc=example, dc=com, dc=domains, dc=cluster00, dc=valuemail, dc=net',
	filter  => '(&(objectclass=localmailrcpt)(authname=*))',

	## try to conserver mem by limiting amount returned
	attrs   => [qw(objectclass dn uiCaps authName userQuota listMemeber)],

	## only search directly above the domain entry in user name space
	scope	=> 'one'
);

## at this point each entry is processed and I log which entry it is processing
## slowly but surely the number of entries capable of being processed is
## shrinking?????

## PROCESSING USER ENTRIES
## 
## MIN is what ever the last page's MAX was + MAX + 1
## ie $oldmax = 5
##    $newmin = $oldmax + MAX + 1 # MAX == 5
##    $newmax = $newmin + MAX + 1
for($i = $newmin; $i <= $newmax; $i++) {
	last if($i > $m->count()-1);

	$e = $m->entry($i);
	## process entry
}

## finally print it all to the user

Within this example $domainAliases and $domainAutoReponders only return 1
since that is how many of each are present which actually brings the total
number of records up to 204 (domainAliases only have one rec per entry).

Would a call back be appropriate to conserve memory here? I would assume
that is the problem... But I am not sure at this point... Are the
$Ldap->abandon()'s even helping to free memory? Am I looking at this all wrong?
Is there another issue which I am not even aware of at work here? It seems odd
that this happened on two different ldap servers and that at some points I
can list the initial page, but the processing of entries will halt half
way through another listing?


Please tell me someone has experienced this!?!?!?! Arrrrgh!!!


One more thing I think I should metion, this has happened to me using both
AIX/Secure Way and OpenLDAP on VA Linux... Running my code on two seperate
VA Linux boxes (not on the VA with OpenLDAP).

-- 
Philip Champon Valueweb Developer
Ph - 954-334-8156
Em - pch...@va...

Re: To unbind or not to unbind

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

I think there are 2 questions here.  Frist, whether or not unbinding is
useful/necessary I believe depends of the server.  Unbinds actually caused
a problem ith an earlier vertion of Novell, but it isn't an issue now.
I suspect that most servers won't be affected if you drop a conncetion
without unbinding or rebind on the same connection without unbinding.

As far as for how many simultaneous conncetions you can make, that is both
a hardware and software issue on the server side.  I would suggest writing
a perl app that forks a bunch of children each of which does repeated
connections and test, gradually cranking up the number of children until
something screams.  This assumes that you are running perl on a system
that does forking.

  --Jim Harle


On Thu, 10 May 2001, Dan G. Lunde wrote:

> Hi
>
> We experienced lags of several minutes with our LDAP-server yesterday.
> However this was caused by general network problems, and not our LDAP
> programs.
>
> For a while I suspected this was due to the fact that I never did
> $ldap->unbind when I was done with a connection. This is fixed now, but I was
> wondering if I in fact could connect too many times in a row and not be able
> to connect any more?
>
> We use LDAP for storing configuration data for mailaccounts, and we expect
> the LDAP-server to be severely hammered when we start using our new system
> with real accounts and hundreds of users at a time. Are there any limits on
> how many LDAP-connections you can make?
>
> Dan
> --
> Dan G. Lunde - dan...@c2...
> http://home.world-online.no/~danglund/pgp/pgp...@c2...c
>
>

To unbind or not to unbind

[Dan G. L. <dan...@ta...>]

Hi

We experienced lags of several minutes with our LDAP-server yesterday. 
However this was caused by general network problems, and not our LDAP 
programs. 

For a while I suspected this was due to the fact that I never did 
$ldap->unbind when I was done with a connection. This is fixed now, but I was 
wondering if I in fact could connect too many times in a row and not be able 
to connect any more?

We use LDAP for storing configuration data for mailaccounts, and we expect 
the LDAP-server to be severely hammered when we start using our new system 
with real accounts and hundreds of users at a time. Are there any limits on 
how many LDAP-connections you can make?

Dan
-- 
Dan G. Lunde - dan...@c2...
http://home.world-online.no/~danglund/pgp/pgp...@c2...c

Re: buglet

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

Graham,
I made the problem go away by changing my code in the application.
Occasionally, it could pass an uninitiazed password on a bind.  What I had
included below was indeed line 204, but the statement continued over to
line 205.

This becomes a philosophical question of whether modules such
as your wonderful Net::LDAP should be responsible for seeing that things
passed to it are defined or not.  I can see both sides of the question.
Novices would be easily confused by such a message.  Old hand like me
should be able to figure things out for themseleves.  This popped up a few
minutes before I left for the day, so I fired off the question without
looking carefully at line 204 to see that it was continued on 205.  On the
other hand, the developer of a module cannot be expected to be continually
paranoid about what is passed.  Here are lines 204 and 205.

      return _error($ldap, $mesg, LDAP_INAPPROPRIATE_AUTH, "No password,
did you mean noauth or anonymous ?")
        if $type eq 'simple' and $passwd eq '';

  --Jim harle

On Wed, 9 May 2001, Graham Barr wrote:

> On Wed, May 09, 2001 at 04:52:23PM -0400, Jim Harle wrote:
> > When running an app that invokes warnings, I received:
> >
> > Use of uninitialized value at
> > /usr/local/lib/perl5/site_perl/5.005/Net/LDAP.pm line 204.
> >
> > This is with version 0.22, where line 204 is
> >
> > return _error($ldap, $mesg, LDAP_INAPPROPRIATE_AUTH, "No password, did you
> > mean noauth or anonymous ?")
>
> That does not make any sense. There is no use of any variables that would
> trigger the warning.
>
> Graham.
>

RE: Iterative LDAP searches

[Rafael C. <Raf...@li...>]

Hi
The purpose of the module Net::LDAP::LDIF is to read/write entries in an
LDIF format.
The module does not interract with the server. If you want to generate an
LDIF file with the content of your server, you must do a search, and you
will have the problem with the server limit.
I think....
Rafael

-----Original Message-----
From: Bing Du [mailto:Bi...@ci...]
Sent: mercredi, 9. mai 2001 16:38
To: Da...@At...; d.b...@ma...
Cc: per...@li...
Subject: Re: Iterative LDAP searches


Maybe I don't get the whole picture of the story. 
But for retrieving all the entries, why not dump the directory in LDIF
and process LDIF instead?  See Net::LDAP::LDIF.

Bing

Bing Du <bi...@ta..., 979-845-9577>
Texas A&M University, CIS, Operating Systems, Unix

>>> David Bussenschutt <d.b...@ma...> 05/08/01
06:43PM >>>
David,
I have a server (Novell 5.1) that I can't get to return more than 500
entries, no matter what the documentation from novell says.  

I loop through 26 searches, one for each letter of the alphabet,
searching
for (cn=$x*) where $x is the letter I'm currently searching for.  I
can
guarantee that I don't have more than 500 'smith's (or whatever), so
this
works well for me. I then just tack all the results together before
fiddling with them.

If I had numerical UID's, then I could probably search for (UID=$y*)
where
$y is the number 1 through 10, and reduce the search cound
significantly.
Oh well.

David.

At 11:46 AM 5/8/01 +0300, you wrote:
>We use Net::LDAP to search for users on directory servers. We're
trying to
>figure out the best way to deal with the search limit that directory
servers
>impose on LDAP searches. For AD, this limit seems to be 1000, while
with
>Netscape it seems to default to 1000 but is configurable. If X is the
search
>limit and there are > X users, we don't get accurate results. We need
a way
>to get back all users, perhaps in smaller chunks.
>
>Someone suggested we use Paging, but that while it's supported by
Active
>Directory, the answer for other directory servers in the future will
be VLV.
>
>Can anyone suggest a good strategy for now?
>What's with VLV - when will there be a stable perl module for this?
>Which directory servers, if any, support Paging other than AD?
>Where can I finds helpful info and examples for either Paging or VLV?
>
> Thanks in advance.
>
>- David Cikk
>
>
>
>
>

--------------------------------------------------------------------
David Bussenschutt          Email: D.B...@ma... 
Senior Computing Support Officer & Systems Administrator/Programmer
Location: Griffith University. Information Technology Services
          Brisbane Qld. Aust.  (TEN bldg. rm 1.33) Ph: (07)38757079
--------------------------------------------------------------------

Re: FW: Net::LDAP::LDIF

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

OK, so this was down to bad test data.

The input LDIF for doing the modify had an entry which did not have a changetype: modify
line. Adding this in and the tests pass.

However the new code probably should have flagged a syntax error instead of what it
did.

Anyway the code looks good to me, so feel free to make similar changes to write

Graham.

On Thu, May 10, 2001 at 01:12:27AM +0100, Graham Barr wrote:
> Well it seems it is not 100% compatable.
> 
> $ SLAPD_EXE=/opt/openldap-1.2.11/libexec/slapd make test
> 
> t/00ldif-entry......ok
> t/01canon_dn........ok
> t/02filter..........ok
> t/50populate........ok
> t/51search..........ok
> t/52modify..........FAILED tests 47, 56
>         Failed 2/56 tests, 96.43% okay
> t/53schema..........ok
> Failed Test  Status Wstat Total Fail  Failed  List of failed
> -------------------------------------------------------------------------------
> t/52modify.t                 56    2   3.57%  47, 56
> Failed 1/7 test scripts, 85.71% okay. 2/347 subtests failed, 99.42% okay.
> *** Error code 2
> 
> I have not looked closly yet as it is getting late
> 
> Graham.
> 
> 
> On Thu, May 10, 2001 at 12:45:32AM +0100, Graham Barr wrote:
> > At first glance it looks OK to me.
> > 
> > Graham.
> > 
> > On Wed, May 09, 2001 at 04:09:52PM -0700, Robbie Allen wrote:
> > > Attached is a patch for LDIF.pm incorporating error handling using an
> > > onerror parameter in new() (just like in LDAP.pm) and a new read_entry()
> > > method.  read_entry() takes the place of read() and read_cmd() making both
> > > of those methods deprecated.  They will be removed in a future version.
> > > 
> > > Graham, let me know if I'm on the right track.  If so I'll work on the write
> > > methods next.
> > > 
> > > Robbie Allen
> > 

Re: FW: Net::LDAP::LDIF

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

Well it seems it is not 100% compatable.

$ SLAPD_EXE=/opt/openldap-1.2.11/libexec/slapd make test

t/00ldif-entry......ok
t/01canon_dn........ok
t/02filter..........ok
t/50populate........ok
t/51search..........ok
t/52modify..........FAILED tests 47, 56
        Failed 2/56 tests, 96.43% okay
t/53schema..........ok
Failed Test  Status Wstat Total Fail  Failed  List of failed
-------------------------------------------------------------------------------
t/52modify.t                 56    2   3.57%  47, 56
Failed 1/7 test scripts, 85.71% okay. 2/347 subtests failed, 99.42% okay.
*** Error code 2

I have not looked closly yet as it is getting late

Graham.


On Thu, May 10, 2001 at 12:45:32AM +0100, Graham Barr wrote:
> At first glance it looks OK to me.
> 
> Graham.
> 
> On Wed, May 09, 2001 at 04:09:52PM -0700, Robbie Allen wrote:
> > Attached is a patch for LDIF.pm incorporating error handling using an
> > onerror parameter in new() (just like in LDAP.pm) and a new read_entry()
> > method.  read_entry() takes the place of read() and read_cmd() making both
> > of those methods deprecated.  They will be removed in a future version.
> > 
> > Graham, let me know if I'm on the right track.  If so I'll work on the write
> > methods next.
> > 
> > Robbie Allen
> 

Re: FW: Net::LDAP::LDIF

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

At first glance it looks OK to me.

Graham.

On Wed, May 09, 2001 at 04:09:52PM -0700, Robbie Allen wrote:
> Attached is a patch for LDIF.pm incorporating error handling using an
> onerror parameter in new() (just like in LDAP.pm) and a new read_entry()
> method.  read_entry() takes the place of read() and read_cmd() making both
> of those methods deprecated.  They will be removed in a future version.
> 
> Graham, let me know if I'm on the right track.  If so I'll work on the write
> methods next.
> 
> Robbie Allen

FW: Net::LDAP::LDIF

[Robbie A. <ra...@ci...>]

Attached is a patch for LDIF.pm incorporating error handling using an
onerror parameter in new() (just like in LDAP.pm) and a new read_entry()
method.  read_entry() takes the place of read() and read_cmd() making both
of those methods deprecated.  They will be removed in a future version.

Graham, let me know if I'm on the right track.  If so I'll work on the write
methods next.

Robbie Allen

> -----Original Message-----
> From: Graham Barr [mailto:gb...@po...]
> Sent: Wednesday, May 09, 2001 12:49 AM
> To: Robbie Allen
> Cc: 'Chris Ridd'
> Subject: Re: Net::LDAP::LDIF
> 
> 
> On Wed, May 09, 2001 at 12:40:43AM -0700, Robbie Allen wrote:
> > Thanks.  Couple more questions.  BTW, if you'd rather I 
> move this to the perl-ldap list, just let me know.
> 
> Yes please.
> 
> > What was the reasoning for the 'changetype' and 'modify' 
> instance variables
> > defined in new()?  Is it so if you have an ldif file full 
> of entries with no
> > commands, that it could default to adding them all when 
> calling read_cmd?
> > It doesn't seem like it would work like that anyway given 
> the current code.
> > Do you want that behavior in the new code?
> 
> It's so that when an entry is read from a server it's 
> changetype defaults to modify.
> 
> Graham.
> 
> > 
> > Robbie Allen
> > 
> > > -----Original Message-----
> > > From: Graham Barr [mailto:gb...@po...]
> > > Sent: Wednesday, May 09, 2001 12:18 AM
> > > To: Robbie Allen
> > > Cc: 'Chris Ridd'
> > > Subject: Re: Net::LDAP::LDIF
> > > 
> > > 
> > > The data directory in the distribution has several.
> > > 
> > > And if you have openldap 1.something you can run the tests by 
> > > first setting
> > > the environment variable SLAPD_EXE to the slapd executeable and
> > > running make test
> > > 
> > > Graham.
> > > 
> > > On Wed, May 09, 2001 at 12:13:52AM -0700, Robbie Allen wrote:
> > > > Do you have any test cases you want me to make sure parses 
> > > correctly?
> > > > 
> > > > Robbie Allen
> > > > 
> > > > > -----Original Message-----
> > > > > From: Graham Barr [mailto:gb...@po...]
> > > > > Sent: Tuesday, May 08, 2001 11:52 PM
> > > > > To: Robbie Allen
> > > > > Cc: 'Chris Ridd'
> > > > > Subject: Re: Net::LDAP::LDIF
> > > > > 
> > > > > 
> > > > > I cannot remember. All I can think of is that the parser 
> > > is different.
> > > > > But we should be able to switch parser when we detect 
> changetype
> > > > > 
> > > > > Graham.
> > > > > 
> > > > > On Tue, May 08, 2001 at 11:23:23PM -0700, Robbie Allen wrote:
> > > > > > Maybe a dumb question, but what was the original 
> > > intent/function of
> > > > > > read_cmd?  Why is it separate from read?
> > > > > > 
> > > > > > Robbie Allen
> > > > > > 
> > > > > > > -----Original Message-----
> > > > > > > From: Graham Barr [mailto:gb...@po...]
> > > > > > > Sent: Tuesday, May 08, 2001 9:25 AM
> > > > > > > To: Robbie Allen
> > > > > > > Cc: 'Chris Ridd'
> > > > > > > Subject: Re: Net::LDAP::LDIF
> > > > > > > 
> > > > > > > 
> > > > > > > I have been thinking about this a bit more, and here are 
> > > > > my thoughts
> > > > > > > 
> > > > > > > Add a new method called read_entry() which will only read 
> > > > > one entry.
> > > > > > > It should also handle reading normal entries and 
> > > command entries,
> > > > > > > this is something I have been meaning todo.
> > > > > > > 
> > > > > > > Then change read() to call read_entry(), just returning 
> > > > > what it can.
> > > > > > > We then depricate read() (and read_cmd) and 
> remove them later.
> > > > > > > 
> > > > > > > Thought ?
> > > > > > > 
> > > > > > > Graham.
> > > > > > > 
> > > > > 
> > > > 
> > > 
> > 
> 




> -----Original Message-----
> From: Robbie Allen 
> Sent: Tuesday, May 08, 2001 8:33 AM
> To: 'Graham Barr'; 'Chris Ridd'
> Subject: Net::LDAP::LDIF
> 
> 
> Hi,
> 
> I'm currently modifying Net::LDAP::LDIF to do error handling. 
>  I'm emulating the same onerror behavior as in Net::LDAP.  
> Quick question.  Would it make sense to add an eof() method 
> to LDIF.pm and use that as the marker to determine when the 
> file has been completely read, or should we inform the user 
> that read() may return undef (when errors occur from parsing) 
> which does not necessarily indicate the end of the file?
> 
> From the docs, the example looks like:
> 
>       $ldif = Net::LDAP::LDIF->new( "file.ldif", "r" );
>       while( $entry = $ldif->read() ) {
>               # Do things with $entry
>       }
>       $ldif->done();
> 
> Based on my error handling, I now need to do this:
> 
>       $ldif = Net::LDAP::LDIF->new( "file.ldif", "r", onerror 
> => 'undef' );
>       while( $entry = $ldif->read() || $ldif->error() ) {
>           if ($ldif->error()) {
>               print "Error msg:\n",$ldif->error(),"\n";
>               print "Error entry:\n",$ldif->error_entry(),"\n";
>           }
>           else {
>              # Do things with $entry          
>           }
>       }
>       $ldif->done();
> 
> What I'm proposing is a litte more readable I think:
> 
>       $ldif = Net::LDAP::LDIF->new( "file.ldif", "r", onerror 
> => 'undef' );
>       while( not $ldif->eof() ) {
>           if ($entry = $ldif->read()) {
>              # Do things with $entry
>           }
>           else {
>               print "Error msg:\n",$ldif->error(),"\n";
>               print "Error entry:\n",$ldif->error_entry(),"\n";
>           }
>       }
>       $ldif->done();
> 
> 
> Then there is still the problem is read() in array context.  
> 
> We could change the docs to:
> 
>      @entries = $ldif->read while not $ldif->eof;
> 
> And get rid of the array context all together.
> 
> Let me know if I'm on the right track.
> 
> Robbie Allen
> 

Re: buglet

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

On Wed, May 09, 2001 at 04:52:23PM -0400, Jim Harle wrote:
> When running an app that invokes warnings, I received:
> 
> Use of uninitialized value at
> /usr/local/lib/perl5/site_perl/5.005/Net/LDAP.pm line 204.
> 
> This is with version 0.22, where line 204 is
> 
> return _error($ldap, $mesg, LDAP_INAPPROPRIATE_AUTH, "No password, did you
> mean noauth or anonymous ?")

That does not make any sense. There is no use of any variables that would
trigger the warning.

Graham.

buglet

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

When running an app that invokes warnings, I received:

Use of uninitialized value at
/usr/local/lib/perl5/site_perl/5.005/Net/LDAP.pm line 204.

This is with version 0.22, where line 204 is

return _error($ldap, $mesg, LDAP_INAPPROPRIATE_AUTH, "No password, did you
mean noauth or anonymous ?")

  --Jim Harle

Re: Iterative LDAP searches

[Bing D. <Bi...@ci...>]

Maybe I don't get the whole picture of the story. 
But for retrieving all the entries, why not dump the directory in LDIF
and process LDIF instead?  See Net::LDAP::LDIF.

Bing

Bing Du <bi...@ta..., 979-845-9577>
Texas A&M University, CIS, Operating Systems, Unix

>>> David Bussenschutt <d.b...@ma...> 05/08/01
06:43PM >>>
David,
I have a server (Novell 5.1) that I can't get to return more than 500
entries, no matter what the documentation from novell says.  

I loop through 26 searches, one for each letter of the alphabet,
searching
for (cn=$x*) where $x is the letter I'm currently searching for.  I
can
guarantee that I don't have more than 500 'smith's (or whatever), so
this
works well for me. I then just tack all the results together before
fiddling with them.

If I had numerical UID's, then I could probably search for (UID=$y*)
where
$y is the number 1 through 10, and reduce the search cound
significantly.
Oh well.

David.

At 11:46 AM 5/8/01 +0300, you wrote:
>We use Net::LDAP to search for users on directory servers. We're
trying to
>figure out the best way to deal with the search limit that directory
servers
>impose on LDAP searches. For AD, this limit seems to be 1000, while
with
>Netscape it seems to default to 1000 but is configurable. If X is the
search
>limit and there are > X users, we don't get accurate results. We need
a way
>to get back all users, perhaps in smaller chunks.
>
>Someone suggested we use Paging, but that while it's supported by
Active
>Directory, the answer for other directory servers in the future will
be VLV.
>
>Can anyone suggest a good strategy for now?
>What's with VLV - when will there be a stable perl module for this?
>Which directory servers, if any, support Paging other than AD?
>Where can I finds helpful info and examples for either Paging or VLV?
>
> Thanks in advance.
>
>- David Cikk
>
>
>
>
>

--------------------------------------------------------------------
David Bussenschutt          Email: D.B...@ma... 
Senior Computing Support Officer & Systems Administrator/Programmer
Location: Griffith University. Information Technology Services
          Brisbane Qld. Aust.  (TEN bldg. rm 1.33) Ph: (07)38757079
--------------------------------------------------------------------

Re: Iterative LDAP searches

[David B. <d.b...@ma...>]

David,
I have a server (Novell 5.1) that I can't get to return more than 500
entries, no matter what the documentation from novell says.  

I loop through 26 searches, one for each letter of the alphabet, searching
for (cn=$x*) where $x is the letter I'm currently searching for.  I can
guarantee that I don't have more than 500 'smith's (or whatever), so this
works well for me. I then just tack all the results together before
fiddling with them.

If I had numerical UID's, then I could probably search for (UID=$y*) where
$y is the number 1 through 10, and reduce the search cound significantly.
Oh well.

David.

At 11:46 AM 5/8/01 +0300, you wrote:
>We use Net::LDAP to search for users on directory servers. We're trying to
>figure out the best way to deal with the search limit that directory servers
>impose on LDAP searches. For AD, this limit seems to be 1000, while with
>Netscape it seems to default to 1000 but is configurable. If X is the search
>limit and there are > X users, we don't get accurate results. We need a way
>to get back all users, perhaps in smaller chunks.
>
>Someone suggested we use Paging, but that while it's supported by Active
>Directory, the answer for other directory servers in the future will be VLV.
>
>Can anyone suggest a good strategy for now?
>What's with VLV - when will there be a stable perl module for this?
>Which directory servers, if any, support Paging other than AD?
>Where can I finds helpful info and examples for either Paging or VLV?
>
> Thanks in advance.
>
>- David Cikk
>
>
>
>
>

--------------------------------------------------------------------
David Bussenschutt          Email: D.B...@ma...
Senior Computing Support Officer & Systems Administrator/Programmer
Location: Griffith University. Information Technology Services
          Brisbane Qld. Aust.  (TEN bldg. rm 1.33) Ph: (07)38757079
--------------------------------------------------------------------

Re: Iterative LDAP searches

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

There was once a module called Net::LDAPiranah which did this, but it was
written for a very old version of Net::LDAP and probably needs updating.

As for Paged results. Have you tried the example code in the docs ?

 perldoc Net::LDAP::Control::Paged

or

 http://perl-ldap.sourceforge.net/doc/Net/LDAP/Control/Paged.html

Graham.

On Tue, May 08, 2001 at 11:46:25AM +0300, David Cikk wrote:
> We use Net::LDAP to search for users on directory servers. We're trying to
> figure out the best way to deal with the search limit that directory servers
> impose on LDAP searches. For AD, this limit seems to be 1000, while with
> Netscape it seems to default to 1000 but is configurable. If X is the search
> limit and there are > X users, we don't get accurate results. We need a way
> to get back all users, perhaps in smaller chunks.
> 
> Someone suggested we use Paging, but that while it's supported by Active
> Directory, the answer for other directory servers in the future will be VLV.
> 
> Can anyone suggest a good strategy for now?
> What's with VLV - when will there be a stable perl module for this?
> Which directory servers, if any, support Paging other than AD?
> Where can I finds helpful info and examples for either Paging or VLV?
> 
>  Thanks in advance.
> 
> - David Cikk
> 
> 
> 
>