perl-ldap-dev

Re: speed of Net::LDAP

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

On Thu, Jul 27, 2000 at 12:55:32PM +0100, John Berthels wrote:
> > Huh? alongside the .pm file.
> 
> Sorry - I meant a 'transparent' cache of recently used ASN.1 definitions.
> 
> Given a writable scratch area the Convert::ASN1 could in principle check
> to see if a compiled version exists whenever a request to load a set of
> ASN.1 definitions comes in. That way the modules/apps which use it would
> not need to explicitly save a compiled version at install time. Almost
> certainly not worth the effort, though.

I think it would be better just for Convert::ASN1 to provide a way to
dump and restore itself to disk.

> However, such a 'standard scratch area' for modules might be an
> interesting idea to feed into future perl6 lib discussions (the CPAN
> module would benefit, for one). I don't think its a good time to bring it
> up on perl6-bootstrap though :-)

I have been down that road before. And it is laid with security mine fields.

I once wrote Include.pm to do what h2xs does on the fly, but it needed a
scratch directory.

Graham.

Re: speed of Net::LDAP

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

> > Would a reasonable approach to be to have 'compile' and 'decompile'
> > methods in Convert::ASN1 which convert between 'readable' :-) ASN.1 and
> > something nearer the internal representation? Then, as you say, do a
> > 'compile' on install or first run and save the results? 
> 
> That is exactly what I was refering to.

Nod. Just making sure I understood.

> > (I guess there
> > isn't a sensible place to keep an on-disk cache of compiled ASN1
> > definitions).
> 
> Huh? alongside the .pm file.

Sorry - I meant a 'transparent' cache of recently used ASN.1 definitions.

Given a writable scratch area the Convert::ASN1 could in principle check
to see if a compiled version exists whenever a request to load a set of
ASN.1 definitions comes in. That way the modules/apps which use it would
not need to explicitly save a compiled version at install time. Almost
certainly not worth the effort, though.

However, such a 'standard scratch area' for modules might be an
interesting idea to feed into future perl6 lib discussions (the CPAN
module would benefit, for one). I don't think its a good time to bring it
up on perl6-bootstrap though :-)

regards,

jb

Re: speed of Net::LDAP

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

On Thu, Jul 27, 2000 at 11:21:21AM +0100, John Berthels wrote:
> Thats interesting, because it hints that XSing Convert::ASN1 might not
> help as much as might be expected (is parsing much quicker in C than
> perl?).

XSinf Convert::ASN1 is to help runtime, not startup. I do not expect to
place the parser into XS.

> Would a reasonable approach to be to have 'compile' and 'decompile'
> methods in Convert::ASN1 which convert between 'readable' :-) ASN.1 and
> something nearer the internal representation? Then, as you say, do a
> 'compile' on install or first run and save the results? 

That is exactly what I was refering to.

> (I guess there
> isn't a sensible place to keep an on-disk cache of compiled ASN1
> definitions).

Huh? alongside the .pm file.

Graham.

Re: how to handle connection to server if server runs away?

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

On Thu, Jul 27, 2000 at 12:20:44PM +0100, Chris Ridd wrote:
> Jonathan Leto <jon...@le...> wrote:
> > If I had problem with timeouts, you would just have to come up with a
> > heuristic of checking if the server is alive ( I dont' think anything
> > like $ldap->ping exists, THAT would be cool ) and then do a check at the
> > beginning of every function.
> 
> The best (ie cheapest in terms of protocol) way to do that in LDAPv3 would 
> be to read a specific attribute (eg supportedLDAPVersions) from the root 
> DSE, and throw away the results.
> 
> I can't think of a simple and portable way to do this in LDAPv2.

You mean instead of deliberatly sending a malformed packet and expecting
an error response. But thats probbaly too evil :)

Graham.

Re: how to handle connection to server if server runs away?

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

Jonathan Leto <jon...@le...> wrote:
> If I had problem with timeouts, you would just have to come up with a
> heuristic of checking if the server is alive ( I dont' think anything
> like $ldap->ping exists, THAT would be cool ) and then do a check at the
> beginning of every function.

The best (ie cheapest in terms of protocol) way to do that in LDAPv3 would 
be to read a specific attribute (eg supportedLDAPVersions) from the root 
DSE, and throw away the results.

I can't think of a simple and portable way to do this in LDAPv2.

Cheers,

Chris

Re: how to handle connection to server if server runs away?

[Jonathan L. <jon...@le...>]

I would really like to write/help write a FAQ, any body up for it? 

It isn't very hard to accomplish this, I write wrapper function for all
the things I am doing on the LDAP directory. I have functions like ldap_search,
ldap_modify,ldap_exists . The first argument they all take it the Net::LDAP connection
object. Sample code: 


sub ldap_connect{
        my $ldap = Net::LDAP->new($LDAP_HOST) or die $!;
        $ldap->bind($LDAP_BINDDN, password => $LDAP_PASS);
        return $ldap;
}     

sub ldap_disconnect{
        my $ldap = shift;
        $ldap->unbind;
}       

sub ldap_modify{
        my ($ldap,$dn,$mods ) = @_ ;
        my $result = $ldap->modify($dn, replace => { %$mods });
        return $result;
}

If I had problem with timeouts, you would just have to come up with a heuristic
of checking if the server is alive ( I dont' think anything like $ldap->ping exists,
THAT would be cool ) and then do a check at the beginning of every function. 

 David Bussenschutt (d.b...@ma...) was saying:

> There seem to have been a few people interested in either reconnecting on
> time-outs, or getting past search-limits...both of which are optionally
> imposed by the server.  
> Since it's clear that Graham et al think it shouldn't be part of the
> library, rather a function of the application, does anyone who's done this
> sort of thing have sample code that they'd like to share...perhaps it could
> be added to the as-yet-nonexistant-but-hopefully-soon-going-to-be FAQ.??
> 
> David.
> 

-- 
Jonathan Leto
T3 Link Inc.
www.t3link.com

Re: speed of Net::LDAP

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

> Net::LDAP already does this to some extent. But I think one of the big
> startup costs is that Convert::ASN1 must parse the ASN.1 for the protocol.
> 
> gbarr@chipper:~/src/ldap > time perl -Ilib -e0
> perl -Ilib -e0  0.00s user 0.00s system 0% cpu 0.000 total
> 
> gbarr@chipper:~/src/ldap > time perl -Ilib -MNet::LDAP -e0
> perl -Ilib -MNet::LDAP -e0  0.38s user 0.00s system 64% cpu 0.593 total
> 
> gbarr@chipper:~/src/ldap > time perl -Ilib -MNet::LDAP::ASN -e0
> perl -Ilib -MNet::LDAP::ASN -e0  0.25s user 0.00s system 32% cpu 0.763 total
> 
> As you can see it is a large % of the load time.
> 
> It should be possible to just parse this on install and dump it to a file.

Thats interesting, because it hints that XSing Convert::ASN1 might not
help as much as might be expected (is parsing much quicker in C than
perl?).

Would a reasonable approach to be to have 'compile' and 'decompile'
methods in Convert::ASN1 which convert between 'readable' :-) ASN.1 and
something nearer the internal representation? Then, as you say, do a
'compile' on install or first run and save the results? (I guess there
isn't a sensible place to keep an on-disk cache of compiled ASN1
definitions).

jb

Re: speed of Net::LDAP

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

On Thu, Jul 27, 2000 at 10:44:38AM +0100, John Berthels wrote:
> 
> > For what it is worth, I don't find Net::LDAP to be unusably slow - the 
> > nice API and the portability make up for a lot.
> 
> Ditto. I find that the startup time kills perceived performance for
> one-shot scripts, but once running it is fine. Whether or not this is a
> problem depends, of course, on your intended application.

Hopefully one day we might get good byte code in perl and that might
help a lot. This may be a thing for perl6 though.

> I posted some numbers on this some time ago which hinted that Net::LDAP
> was significantly slower than other perl modules to start up - but the
> problem is to find 'comparable' modules. It is slower than Net::SMTP - but
> that is a lot simpler. It is slower than Tk - but Graham pointed out that
> that defers loading of code until it is used, i.e. you take the hit later
> in the script.

It might be good to have a page on the web-site about performance as it
seems an FAQ (almost) but the answer is too long to go into an FAQ document IMO.

> Would there be any value in deferring some Net::LDAP module loading until
> it was needed or are we already as lean as we could get in that area?
> (sorry - being lazy and not checking).

Net::LDAP already does this to some extent. But I think one of the big
startup costs is that Convert::ASN1 must parse the ASN.1 for the protocol.

gbarr@chipper:~/src/ldap > time perl -Ilib -e0
perl -Ilib -e0  0.00s user 0.00s system 0% cpu 0.000 total

gbarr@chipper:~/src/ldap > time perl -Ilib -MNet::LDAP -e0
perl -Ilib -MNet::LDAP -e0  0.38s user 0.00s system 64% cpu 0.593 total

gbarr@chipper:~/src/ldap > time perl -Ilib -MNet::LDAP::ASN -e0
perl -Ilib -MNet::LDAP::ASN -e0  0.25s user 0.00s system 32% cpu 0.763 total

As you can see it is a large % of the load time.

It should be possible to just parse this on install and dump it to a file.

Graham.

Re: speed of Net::LDAP

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

On Thu, Jul 27, 2000 at 10:23:08AM +0100, Chris Ridd wrote:
> Mark's already commented that one of the bottlenecks is Net::LDAP's use 
> of a perl module for decoding the BER (ie Convert::ASN1). Writing a 
> Convert::ASN1 in C is a way around this, but as yet no-one has 
> volunteered.

I knew something was missing from my TODO list at TPC. Although I think
Convert::ASN1 still needs a little work, so it may not be ready to convert
to XS just yet. But if someone wants to try I would be happy to
discuss my thoughts.

> Another obvious issue with perl is that the first run of a piece of 
> code might be slow because it makes perl load in, parse and compile 
> lots more chunks of perl.

Personally I always use the Benchmark module for timing something.

Graham.

Re: speed of Net::LDAP

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

> For what it is worth, I don't find Net::LDAP to be unusably slow - the 
> nice API and the portability make up for a lot.

Ditto. I find that the startup time kills perceived performance for
one-shot scripts, but once running it is fine. Whether or not this is a
problem depends, of course, on your intended application.

I posted some numbers on this some time ago which hinted that Net::LDAP
was significantly slower than other perl modules to start up - but the
problem is to find 'comparable' modules. It is slower than Net::SMTP - but
that is a lot simpler. It is slower than Tk - but Graham pointed out that
that defers loading of code until it is used, i.e. you take the hit later
in the script.

Would there be any value in deferring some Net::LDAP module loading until
it was needed or are we already as lean as we could get in that area?
(sorry - being lazy and not checking).

regards,

jb

Re: speed of Net::LDAP

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

On Wed, 26 Jul 2000 18:31:18 CDT, Luke Kanies wrote:
> Hi all.  I have some questions about perceived speed of Net::LDAP.  I
> ran some quick comparisons between it and the command line, and am
> willing to do more if anyone wants more info.
> 
> My problem is that Net::LDAP appears to be about an order of magnitude
> slower for search operations than the corresponding command line
> function.

Mark's already commented that one of the bottlenecks is Net::LDAP's use 
of a perl module for decoding the BER (ie Convert::ASN1). Writing a 
Convert::ASN1 in C is a way around this, but as yet no-one has 
volunteered.

Another obvious issue with perl is that the first run of a piece of 
code might be slow because it makes perl load in, parse and compile 
lots more chunks of perl.

So you really need to make your perl test program do the same thing a 
couple of times without quitting the interpreter, and then ignore the 
first result.

It is also worth removing the stepping through the results and the 
output parts of each test to see how that affects things - obviously 
real world programs will step through results and do interesting stuff, 
but it'd be interesting to see where most of the slowdown is.

> For instance, I have an ldap database with 1768 ou's in it, and I
> performed three different types of searches on it using both the command
> line and Net::LDAP.  First I just dumped all of the entries to the
> screen; then I built a hash of all of the entries, of the form
> $hash{$dn}->{$attr} = $value.   Finally, I did another search and just
> counted the entries.
> 
> For the command line functions, to dump to screen I just used system(),
> to build the hash, I used open() and then match and split, and to count
> I used open() and counted blank lines.
> 
> For Net::LDAP, to dump I did the search and cycled through the entries
> with $entry->dump, to build the hash, I cycled through and used:
> $dn = $entry->dn;
> foreach $attr ($entry->attributes)
> {
> 	$hash{$dn}->{$attr} = $entry->get($attr);
> }
> 
> and for counting, I just did a $count++ for each entry.
> 
> For each Net::LDAP search I opened and closed the connection for each
> time test.
> 
> Here are the numbers that I found:
> 
> Net: dump 21
> Net: hash 14
> Net: count 16
> CLI: dump 2
> CLI: hash 1
> CLI: count 1

For what it is worth, I don't find Net::LDAP to be unusably slow - the 
nice API and the portability make up for a lot.

Cheers,

Chris

Re: speed of Net::LDAP

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

Well, duhhhhh :) (and what's one of the greatest Perl phrases, "You might
write faster code in C, but you'll write code faster in Perl"). Net::LDAP is
written in pure Perl, thus it will be slower than anything written in C. Now
we know where the bulk of the speed problems are and they are in
Convert::ASN1 because everything in LDAP must be encoded/decoded from BER
before transport. At some future point, Graham (or someone else??) may write
an optional C backend for ASN1 (e.g. it would compile in C if you had a C
compiler, otherwise it would remain pure Perl). But that will come after
Net::LDAP is more complete.

Now there are some things you can do to improve performance and efficiency,
namely callbacks. They'll reduce the amount of memory you consume & will
enable you to process results as soon as Net::LDAP gets them, instead of
having to wait until the end.

Speed is also in the eye of the beholder and CPU. For example, if most your
application delay is going to be in network latency regardless of language,
then write in C becuase it won't really matter. If the program is run in
batch mode, where perhaps the Perl program takes an extra 15 minutes to run,
but you can write it in less than 20 minutes, as opposed to an hour or more
in C,. is that worth it?

As for the other Perl modules, well, we're really the only one left :).
PerLDAP hasn't seen a release in over a year and I don't anticipate one
anytime soon. Plus the user community has dried up, heck the guy who wrote
the original code that PerLDAP is based on, uses us because it's so much
easier & functional (the next version will have real support for controls &
DSML & SSL!).  And we test against just about every LDAP server you'll ever
encounter.

Thus, the performance isn't going to dramatically improve anytime soon
(unless you go from a 200 MHZ to a 800MHZ CPU ;), but there are things that
can make your program to appear to run faster. Or you are free to work with
us to try to add the C backend to the ASN1 module.

I'm also willing to help you optimize your application (for example if it's
CGI based, use mod_perl instead of traditional CGI, keep a static connection
open to the server).

Net::LDAP may not be a total speed deamon, but I've been using it for over 2
years and it's portability has come in more handy than any speed concerns.

Mark

Luke Kanies wrote:

> Hi all.  I have some questions about perceived speed of Net::LDAP.  I
> ran some quick comparisons between it and the command line, and am
> willing to do more if anyone wants more info.
>
> My problem is that Net::LDAP appears to be about an order of magnitude
> slower for search operations than the corresponding command line
> function.
>
> For instance, I have an ldap database with 1768 ou's in it, and I
> performed three different types of searches on it using both the command
> line and Net::LDAP.  First I just dumped all of the entries to the
> screen; then I built a hash of all of the entries, of the form
> $hash{$dn}->{$attr} = $value.   Finally, I did another search and just
> counted the entries.
>
> For the command line functions, to dump to screen I just used system(),
> to build the hash, I used open() and then match and split, and to count
> I used open() and counted blank lines.
>
> For Net::LDAP, to dump I did the search and cycled through the entries
> with $entry->dump, to build the hash, I cycled through and used:
> $dn = $entry->dn;
> foreach $attr ($entry->attributes)
> {
>         $hash{$dn}->{$attr} = $entry->get($attr);
> }
>
> and for counting, I just did a $count++ for each entry.
>
> For each Net::LDAP search I opened and closed the connection for each
> time test.
>
> Here are the numbers that I found:
>
> Net: dump 21
> Net: hash 14
> Net: count 16
> CLI: dump 2
> CLI: hash 1
> CLI: count 1
>
> As you can see, Net::LDAP performed pretty abysmally.  My question is,
> does everyone else see this too, and is it going to be addressed?  If
> it's not going to be fixed, is Net::LDAPapi or Mozilla::LDAP any
> better?  I really can't afford 20 seconds for all of my searches, so if
> Net::LDAP is going to take that long, I can't use it.  And I want to
> avoid the command line if possible, since I don't like the idea of
> running long searches using the user's password on the command line.
>
> If anyone is interested, I can send my code, or I can run more tests.  I
> really would like to use Net::LDAP, since it is tons easier to use the
> Net::LDAPapi, but I can't if it is going to be this slow.
>
> Thanks, and please email me if you have any questions about my results.
>
> --
> Luke A. Kanies  | "Most people are born and years later die without
> System Engineer | really having lived at all.  They play it safe and
> 615/778-7268    | tiptoe through life with no aspiration other than to
> pgr 800/415-1972| arrive at death safely."-Tony Campolo, "Carpe Diem"

speed of Net::LDAP

[Luke K. <luk...@bl...>]

Hi all.  I have some questions about perceived speed of Net::LDAP.  I
ran some quick comparisons between it and the command line, and am
willing to do more if anyone wants more info.

My problem is that Net::LDAP appears to be about an order of magnitude
slower for search operations than the corresponding command line
function.

For instance, I have an ldap database with 1768 ou's in it, and I
performed three different types of searches on it using both the command
line and Net::LDAP.  First I just dumped all of the entries to the
screen; then I built a hash of all of the entries, of the form
$hash{$dn}->{$attr} = $value.   Finally, I did another search and just
counted the entries.

For the command line functions, to dump to screen I just used system(),
to build the hash, I used open() and then match and split, and to count
I used open() and counted blank lines.

For Net::LDAP, to dump I did the search and cycled through the entries
with $entry->dump, to build the hash, I cycled through and used:
$dn = $entry->dn;
foreach $attr ($entry->attributes)
{
	$hash{$dn}->{$attr} = $entry->get($attr);
}

and for counting, I just did a $count++ for each entry.

For each Net::LDAP search I opened and closed the connection for each
time test.

Here are the numbers that I found:

Net: dump 21
Net: hash 14
Net: count 16
CLI: dump 2
CLI: hash 1
CLI: count 1

As you can see, Net::LDAP performed pretty abysmally.  My question is,
does everyone else see this too, and is it going to be addressed?  If
it's not going to be fixed, is Net::LDAPapi or Mozilla::LDAP any
better?  I really can't afford 20 seconds for all of my searches, so if
Net::LDAP is going to take that long, I can't use it.  And I want to
avoid the command line if possible, since I don't like the idea of
running long searches using the user's password on the command line.

If anyone is interested, I can send my code, or I can run more tests.  I
really would like to use Net::LDAP, since it is tons easier to use the
Net::LDAPapi, but I can't if it is going to be this slow.

Thanks, and please email me if you have any questions about my results.

-- 
Luke A. Kanies  | "Most people are born and years later die without
System Engineer | really having lived at all.  They play it safe and
615/778-7268    | tiptoe through life with no aspiration other than to
pgr 800/415-1972| arrive at death safely."-Tony Campolo, "Carpe Diem"

Re: AuthNetLDAP

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

This sounds like your mod_perl install is screwed up or you don't have
your Apache configured so that you can change that authentication
mechanisms in your .htaccess file.


Mark

On Wed, 26 Jul 2000, wiLL wrote:

> 
> I have installed AuthNetLDAP on my server with no problem,  edited the
> .htaccess file  but I got the ff. errors when I tried to access the
> directory, here is ther error_log:
> 
> .... /home/httpd/html/casper/.htaccess: Invalid command 'PerlSetVar',
> perhaps mis-spelled or defined by a module not included in the server
> configuration
> 
> I'm new to this one and I dont know if  i'm missing something out ?  thanks
> for any help ...
> 
> wiLL
> 
> -------------------------------------
> wiLL S. Olivete Jr.
> wol...@sk...
> pgp key id : 0x2D85D7BF
> office voice: 63.74.443.5657
> mobile: 0917.972.6384
> pager: ec 963576 
> 
> 

Re: (no subject)

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

On Tue, Jul 25, 2000 at 09:50:17PM -0700, Alex Kilimnik wrote:
> Hello:
> 
> How do I resolve the following error:
> version not supported at line 9.
> 
> Where line 9 is:
> $mesg->code && die $mesg->error;

It sounds like you try to do a version 3 bind to a version 2 server.

Graham.

Re: how to handle connection to server if server runs away?

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

On Tue, 25 Jul 2000 16:11:09 CDT, "Bing Du" wrote:
> Greetings all...
> 
> I have a client script to do routine mass search and update on our ldap
> server. The script is set up to run at 1:30am in a crontab file and
> usually it takes about 5 hours to finish its work.  All the script's
> activities are recorded in a log file.
> 
> One day lately, I noticed in the log file that the script started at
> the designated time (1:30am).  But an error message 'I/O Error
> Connection reset by peer' on a search showed up at about 10:30am (about
> 10 hours later).
> 
> Was it because I did not set up any timelimit on 'new'ing a connection
> and search()?
> 
> According to 'perldoc Net::LDAP', if not set explicitly, the default is
> 120 (I assume the unit is second) will be used as the value of timeout
> in the following operation.
> 
>      $ld = new Net::LDAP($ldap_server,port => $ldap_port) || die "Can't
> connect!!!";
> 
> Also timelimit can be set in search(). If not set, the default is no
> limit.

Timelimits are not relevant when creating a new connection as there's 
no LDAP protocol going on at this point, just TCP connection 
establishment. Normal TCP timers should apply here.

In LDAP, sizelimits and timelimits are only specified in the search 
operation - no other operations use them (ie send them to the server.)

Cheers,

Chris

Re: Displaying Search Results

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

On Tue, 25 Jul 2000 17:52:50 +0800, "spencer" wrote:
> Hi,
> Thanks Chris, Reda for the suggestion. I just realised that the failure to
> display results might actually lie elsewhere. Reading a previous email,
> Cliff seemed to have the same problem too. The script runs without error,
> but without results too(sadly).
> 
> Does the following code look 'buggy'?
> 
> use Net::LDAP qw(:all);
> use Net::LDAP::Util qw(ldap_error_name ldap_error_text);
> 
> $ldap=Net::LDAP->new('coriander.mail.abs.com.my') or die "$@";
> $mesg=$ldap->bind;
> 
> $result=$ldap->search(
>   base=>"o=abs,c=my",
>   filter=>"sn=Jones",
>   attrs=>['cn','sn']
>   );

You ought to check the result code at this point, in case the server 
returned an error.

$code = $result->code;
die "Error " . ldap_error_name($code) . "\n" if $code;

> By the way, I am using perl-ldap-0.19 with Convert ASN1 module and Active
> Perl v5.6.0. Any problem with this, possibly?

As Graham has noted, that's highly likely.

Cheers,

Chris

(no subject)

[Alex K. <sac...@ya...>]

Hello:

How do I resolve the following error:
version not supported at line 9.

Where line 9 is:
$mesg->code && die $mesg->error;

Thanks,
Alex

__________________________________________________
Do You Yahoo!?
Get Yahoo! Mail – Free email you can access from anywhere!
http://mail.yahoo.com/

AuthNetLDAP

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

I have installed AuthNetLDAP on my server with no problem,  edited the
.htaccess file  but I got the ff. errors when I tried to access the
directory, here is ther error_log:

.... /home/httpd/html/casper/.htaccess: Invalid command 'PerlSetVar',
perhaps mis-spelled or defined by a module not included in the server
configuration

I'm new to this one and I dont know if  i'm missing something out ?  thanks
for any help ...

wiLL

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

Re: how to handle connection to server if server runs away?

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

There seem to have been a few people interested in either reconnecting on
time-outs, or getting past search-limits...both of which are optionally
imposed by the server.  
Since it's clear that Graham et al think it shouldn't be part of the
library, rather a function of the application, does anyone who's done this
sort of thing have sample code that they'd like to share...perhaps it could
be added to the as-yet-nonexistant-but-hopefully-soon-going-to-be FAQ.??

David.

At 04:20 PM 7/25/00 -0500, Mark Wilcox wrote:
>Net::LDAP should only attempt to connect once. To reconect its up to the
>application.
>
>Mark
>
>On Tue, 25 Jul 2000, Bing Du wrote:
>
>> Greetings all...
>> 
>> I have a client script to do routine mass search and update on our ldap
>> server. The script is set up to run at 1:30am in a crontab file and
>> usually it takes about 5 hours to finish its work.  All the script's
>> activities are recorded in a log file.
>> 
>> One day lately, I noticed in the log file that the script started at
>> the designated time (1:30am).  But an error message 'I/O Error
>> Connection reset by peer' on a search showed up at about 10:30am (about
>> 10 hours later).
>> 
>> Was it because I did not set up any timelimit on 'new'ing a connection
>> and search()?
>> 
>> According to 'perldoc Net::LDAP', if not set explicitly, the default is
>> 120 (I assume the unit is second) will be used as the value of timeout
>> in the following operation.
>> 
>>      $ld = new Net::LDAP($ldap_server,port => $ldap_port) || die "Can't
>> connect!!!";
>> 
>> Also timelimit can be set in search(). If not set, the default is no
>> limit.
>> 
>> Is it possible with Net::LDAP to specify reconnect attempts if the ldap
>> server goes away (with appropriate limits on time between attempts and
>> on the total number of attmepts to connect)? 
>> 
>> Any help would be greatly appreciated.
>> 
>> Bing
>> 
>> 
>
>
>
>

--------------------------------------------------------------------
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: how to handle connection to server if server runs away?

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

Net::LDAP should only attempt to connect once. To reconect its up to the
application.

Mark

On Tue, 25 Jul 2000, Bing Du wrote:

> Greetings all...
> 
> I have a client script to do routine mass search and update on our ldap
> server. The script is set up to run at 1:30am in a crontab file and
> usually it takes about 5 hours to finish its work.  All the script's
> activities are recorded in a log file.
> 
> One day lately, I noticed in the log file that the script started at
> the designated time (1:30am).  But an error message 'I/O Error
> Connection reset by peer' on a search showed up at about 10:30am (about
> 10 hours later).
> 
> Was it because I did not set up any timelimit on 'new'ing a connection
> and search()?
> 
> According to 'perldoc Net::LDAP', if not set explicitly, the default is
> 120 (I assume the unit is second) will be used as the value of timeout
> in the following operation.
> 
>      $ld = new Net::LDAP($ldap_server,port => $ldap_port) || die "Can't
> connect!!!";
> 
> Also timelimit can be set in search(). If not set, the default is no
> limit.
> 
> Is it possible with Net::LDAP to specify reconnect attempts if the ldap
> server goes away (with appropriate limits on time between attempts and
> on the total number of attmepts to connect)? 
> 
> Any help would be greatly appreciated.
> 
> Bing
> 
> 

how to handle connection to server if server runs away?

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

Greetings all...

I have a client script to do routine mass search and update on our ldap
server. The script is set up to run at 1:30am in a crontab file and
usually it takes about 5 hours to finish its work.  All the script's
activities are recorded in a log file.

One day lately, I noticed in the log file that the script started at
the designated time (1:30am).  But an error message 'I/O Error
Connection reset by peer' on a search showed up at about 10:30am (about
10 hours later).

Was it because I did not set up any timelimit on 'new'ing a connection
and search()?

According to 'perldoc Net::LDAP', if not set explicitly, the default is
120 (I assume the unit is second) will be used as the value of timeout
in the following operation.

     $ld = new Net::LDAP($ldap_server,port => $ldap_port) || die "Can't
connect!!!";

Also timelimit can be set in search(). If not set, the default is no
limit.

Is it possible with Net::LDAP to specify reconnect attempts if the ldap
server goes away (with appropriate limits on time between attempts and
on the total number of attmepts to connect)? 

Any help would be greatly appreciated.

Bing

Re: Question regarding Digital Certificates in LDAP

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

Graham,
  Can you be specific about what is involved with maintaining the FAQ?
  --Jim Harle


On Tue, 25 Jul 2000, Graham Barr wrote:

> On Sat, Jul 22, 2000 at 06:48:58PM -0500, Mark Wilcox wrote:
> > Yet another item for our mythical FAQ :)
> 
> Well at the perl conference we got many volunteers to do things, but the
> FAQ was not one of them.
> 
> If anyone wants fame and fortune^Wpoverty then please contact me.
> 
> Graham.
> 
> 
> 

Re: Displaying Search Results

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

On Tue, Jul 25, 2000 at 05:52:50PM +0800, spencer wrote:
> By the way, I am using perl-ldap-0.19 with Convert ASN1 module and Active
> Perl v5.6.0. Any problem with this, possibly?

Perl v5.6.0 may be causing a problem. Can you possibly try it with
5.005_03 ?

Graham.

Displaying Search Results

[spencer <sp...@co...>]

Hi,
Thanks Chris, Reda for the suggestion. I just realised that the failure to
display results might actually lie elsewhere. Reading a previous email,
Cliff seemed to have the same problem too. The script runs without error,
but without results too(sadly).

Does the following code look 'buggy'?

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

$ldap=Net::LDAP->new('coriander.mail.abs.com.my') or die "$@";
$mesg=$ldap->bind;

$result=$ldap->search(
  base=>"o=abs,c=my",
  filter=>"sn=Jones",
  attrs=>['cn','sn']
  );
print $result->entries;            #print statement
foreach $entry ($result->entries)
{
 print "Entry returned with DN:",$entry->dn,"\n";
 foreach $attr($entry->attributes)
 {
  foreach $val($entry->get($attr))
  {
   print "Attribute \"$attr\" with value \"$val\"\n";
  }
 }
}

My print statement to display $result->entries prints blank. I am very sure
that there are such entries that I am looking for in this script.

By the way, I am using perl-ldap-0.19 with Convert ASN1 module and Active
Perl v5.6.0. Any problem with this, possibly?

Please help.

Many thank.

spencer