perl-ldap-dev

Re: AuthNetLDAP

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

Correct. I accidentally included a bunch of AutoLoader stuff when I built
it the first time. I've been trying to get time to rewrite the module from
scratch to take care of this & fill out my feature list. But the time just
hasn't been there ;).

Mark

On Fri, 28 Jul 2000, Graham Barr wrote:

> I guess from the error report it also has DynaLoader in @ISA which
> probably is not needed anymore either.
> 
> Graham.
> 
> On Fri, Jul 28, 2000 at 10:02:14AM -0500, Mark Wilcox wrote:
> > Oh, that's a 'bug' caused by the fact that I turned on the wrong swith
> > when I created the module.
> > 
> > There is a line in AuthNetLDAP.pm that says:
> > bootstrap Apache::AuthNetLDAP $VERSION;
> > 
> > Comment out this line and you'll no longer get this message.
> > 
> > The next version of AuthNetLDAP won't have this.
> > 
> > Mark
> > 
> > On Fri, 28 Jul 2000, wiLL wrote:
> > 
> > > Hello Again!
> > > 
> > > At last I got this thing working with my Apache, I just really needed to
> > > upgrade my apache ..
> > > but here's another error_log I just encountered again, I checked out the
> > > directories and Autnetldap is there ..            
> > > 
> > > [Fri Jul 28 17:42:35 2000] [error] Can't locate loadable object for module
> > > Apache::AuthNetLDAP in @INC (@INC contains:
> > > /usr/lib/perl5/5.00503/i386-linux /usr/lib/perl5/5.00503
> > > /usr/lib/perl5/site_perl/5.005/i386-linux /usr/lib/perl5/site_perl/5.005 .
> > > /etc/httpd/ /etc/httpd/lib/perl) at (eval 5) line 3
> > > 
> > > 
> > > 
> > > 
> > > FROM: Mark Wilcox
> > >            DATE: 07/26/2000 11:12:09
> > >             SUBJECT: RE:  AuthNetLDAP
> > >              
> > >             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 
> > >             > 
> > >             > 
> > > 
> > > 
> > > 
> > > 
> > > -------------------------------------
> > > wiLL S. Olivete Jr.
> > > wol...@sk...
> > > pgp key id : 0x2D85D7BF
> > > office voice: 63.74.443.5657
> > > mobile: 0917.972.6384
> > > pager: ec 963576 
> > > 
> > > 
> > 
> > 
> > 
> 

market research

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

I am currently talking with a publisher (no prizes for who) about
a Net::LDAP book, but they would like to know how widespread Net::LDAP
is used.

Now I am not asking for people to respond with "we use it here at our
corner shop", but if anyone has any knowledge of it being used on a
large-ish scale or being included in any distributions then please
let me know.

Please let me know privately, I don't want to fill the list.

However this has made me think that other Open Source projects often
have a webpage of names (well known comapanies etc.) who use thier code.
Maybe thats an idea for the Net::LDAP website

Graham.

Re: AuthNetLDAP

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

I guess from the error report it also has DynaLoader in @ISA which
probably is not needed anymore either.

Graham.

On Fri, Jul 28, 2000 at 10:02:14AM -0500, Mark Wilcox wrote:
> Oh, that's a 'bug' caused by the fact that I turned on the wrong swith
> when I created the module.
> 
> There is a line in AuthNetLDAP.pm that says:
> bootstrap Apache::AuthNetLDAP $VERSION;
> 
> Comment out this line and you'll no longer get this message.
> 
> The next version of AuthNetLDAP won't have this.
> 
> Mark
> 
> On Fri, 28 Jul 2000, wiLL wrote:
> 
> > Hello Again!
> > 
> > At last I got this thing working with my Apache, I just really needed to
> > upgrade my apache ..
> > but here's another error_log I just encountered again, I checked out the
> > directories and Autnetldap is there ..            
> > 
> > [Fri Jul 28 17:42:35 2000] [error] Can't locate loadable object for module
> > Apache::AuthNetLDAP in @INC (@INC contains:
> > /usr/lib/perl5/5.00503/i386-linux /usr/lib/perl5/5.00503
> > /usr/lib/perl5/site_perl/5.005/i386-linux /usr/lib/perl5/site_perl/5.005 .
> > /etc/httpd/ /etc/httpd/lib/perl) at (eval 5) line 3
> > 
> > 
> > 
> > 
> > FROM: Mark Wilcox
> >            DATE: 07/26/2000 11:12:09
> >             SUBJECT: RE:  AuthNetLDAP
> >              
> >             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 
> >             > 
> >             > 
> > 
> > 
> > 
> > 
> > -------------------------------------
> > wiLL S. Olivete Jr.
> > wol...@sk...
> > pgp key id : 0x2D85D7BF
> > office voice: 63.74.443.5657
> > mobile: 0917.972.6384
> > pager: ec 963576 
> > 
> > 
> 
> 
> 

Re: AuthNetLDAP

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

Oh, that's a 'bug' caused by the fact that I turned on the wrong swith
when I created the module.

There is a line in AuthNetLDAP.pm that says:
bootstrap Apache::AuthNetLDAP $VERSION;

Comment out this line and you'll no longer get this message.

The next version of AuthNetLDAP won't have this.

Mark

On Fri, 28 Jul 2000, wiLL wrote:

> Hello Again!
> 
> At last I got this thing working with my Apache, I just really needed to
> upgrade my apache ..
> but here's another error_log I just encountered again, I checked out the
> directories and Autnetldap is there ..            
> 
> [Fri Jul 28 17:42:35 2000] [error] Can't locate loadable object for module
> Apache::AuthNetLDAP in @INC (@INC contains:
> /usr/lib/perl5/5.00503/i386-linux /usr/lib/perl5/5.00503
> /usr/lib/perl5/site_perl/5.005/i386-linux /usr/lib/perl5/site_perl/5.005 .
> /etc/httpd/ /etc/httpd/lib/perl) at (eval 5) line 3
> 
> 
> 
> 
> FROM: Mark Wilcox
>            DATE: 07/26/2000 11:12:09
>             SUBJECT: RE:  AuthNetLDAP
>              
>             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 
>             > 
>             > 
> 
> 
> 
> 
> -------------------------------------
> wiLL S. Olivete Jr.
> wol...@sk...
> pgp key id : 0x2D85D7BF
> office voice: 63.74.443.5657
> mobile: 0917.972.6384
> pager: ec 963576 
> 
> 

website

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

OK, so I have the worst memory in the world.

At the TPC BOF someone volunteered to develop/maintain
the website, but I cannot remember who.

If that person is on the list, or if someone can remember who it was,
please let me know. Then I can give you access to the pages on
sourceforge.

Graham.

Re: ldap->ping?

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

On Fri, Jul 28, 2000 at 07:16:06AM -0700, Kurt D. Zeilenga wrote:
> At 02:30 PM 7/28/00 +0100, Graham Barr wrote:
> >Well if you cannot get a root DSE, assume version 2
> 
> That's actually a bad assumption.  You may just not have
> permission to access the root DSE or you may be talking

In which case the error code should indicate that.

> to an LDAPv2 server which has (improperly) instantiated
> an entry at the root.

That could be an issue.

> A better option is to use bind to determine if the
> directory supports the version you desire.

With that I agree.

I suppose the question to ask is if these kind of operations are common
enough to capture them in utility functions. Each function may have
side-effects which should be documented.

Graham.

Re: ldap->ping?

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

At 02:30 PM 7/28/00 +0100, Graham Barr wrote:
>Well if you cannot get a root DSE, assume version 2

That's actually a bad assumption.  You may just not have
permission to access the root DSE or you may be talking
to an LDAPv2 server which has (improperly) instantiated
an entry at the root.

A better option is to use bind to determine if the
directory supports the version you desire.

Kurt

Re: ldap->ping?

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

On Fri, Jul 28, 2000 at 08:20:49AM -0500, Clif Harden wrote:
> > > is it version 2 or version 3 compliant?
> > > does it support ssl/sasl/whatever?
> > > does it limit search requests? (and what are they)
> > > does it have timeouts? (and what are they)
> > 
> > IIRC, This is all avaliable from the root DSE. But I guess you are looking
> > for a simpler approach than
> > 
> >   $dse = $ldap->root_dse;
> >   $dse->get('supportedVersions'); # I forget the attribute name
> 
> 
> Different vendors give different pieces of information and use 
> slightly different attribute names in the root DSE.  
> 
> One of our vendors uses supportedLDAPVersion and another vendor uses
> supportedVersion.

Yeah right. Probably even more reason to have a method do it for you.

> What about version 2, it gives you nothing.  There are a lot of 
> version 2 ldap systems still in use.

Well if you cannot get a root DSE, assume version 2

> End of my 2 cents worth of opinion.
> Probably wasn't worth 2 cents.

Ah, but I bet it cost me more :)

raham.

Re: ldap->ping?

[Clif H. <cl...@di...>]

Well here is my 2 cents (US) worth of opinion on this matter.


> 
> On Fri, Jul 28, 2000 at 11:35:18AM +1000, David Bussenschutt wrote:
> > Anyone else see this as a potential for a new module (gee.. how about
> > ::Status or
> 
> Well I think there will be possibilities beyond status for this kind of
> thing so I would really like to see something more general.
> 
> > ::Util::Status ?)
> 
> Net::LDAP::Util::Status is too deep IMO for such an API. It
> really should be Net::LDAP::Something.
> 
> > containing functions/objects/whatever that query the ldap server to find
> > out what it's capable of?
> > ie:
> > is it "up"? - with an anonymous bind
> > is is "up"? - with a malformed packet request
> 

I have a script that does a lookup on any one of six uids from our 
directory servers.   It is simple, puts no load on anything, and 
it works.  Unfortunely it uses the old LDAPapi module but I know for
a fact that Net::LDAP could do the same thing.  In the future I intend
to convert it to Net::LDAP.  


> Do you really want to give the user control over what type of check to do ?
> 
> > is it version 2 or version 3 compliant?
> > does it support ssl/sasl/whatever?
> > does it limit search requests? (and what are they)
> > does it have timeouts? (and what are they)
> 
> IIRC, This is all avaliable from the root DSE. But I guess you are looking
> for a simpler approach than
> 
>   $dse = $ldap->root_dse;
>   $dse->get('supportedVersions'); # I forget the attribute name


Different vendors give different pieces of information and use 
slightly different attribute names in the root DSE.  

One of our vendors uses supportedLDAPVersion and another vendor uses
supportedVersion.

What about version 2, it gives you nothing.  There are a lot of 
version 2 ldap systems still in use.


> 
> > Mind you, if this was written, it'd be very tempting to include something
> > to test for "type" of ldap server eg Netscape/openldap/novell and introduce
> > server specific tests too.... is this a good or a bad thing?
> 
> I am not sure there is a way to determine the server type. Not reliably anyway.
> 
> > P.S. regarding the Ldap::Cooked (or whatever)...  I for one like the option
> > of a simple "foolproof" API that is smart enough to figure out things like
> > the ldap version to talk with(currently 3 falling back to 2),
> 
> You should bind to the version of which feature you need. If you don't use
> version 3 features bind as version 2. If you want v3 feature, falling back to binding as
> v2 is the wrong thing to do.
> 
> > whether ssl
> > is supported on the server end (with a fall-back if its not),
> 
> This is dangerous. If you want SSL it is normally for a reason, so falling
> back is REALLY the wrong thing.
> 
> > if searches
> > are limited then automatically do multiple searches invisibly, etc etc.
> 


Much of this would be better off being done with a SNMP agent and a
proper mib.  Our x.500 vender supplies a mib that will provide most of 
this information when queried.  I would think that most of the major
directory vendors provide SNMP mibs for monitoring their servers too.



> The Net::LDAPiranah module did this but I don't think it works with the
> latest version. But we will get it going again.
> 
> Graham.
> 
> 


End of my 2 cents worth of opinion.
Probably wasn't worth 2 cents.

Regards,

Clif Harden           INTERNET:  c-h...@ti...
Texas Instruments                
Directory Services
6500 Chase Oaks Blvd, M/S 8412  
Plano, TX 75023        
                         Voice:  972-575-0855
                           FAX:  972-575-2418

Re: ldap->ping?

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

On Fri, Jul 28, 2000 at 11:35:18AM +1000, David Bussenschutt wrote:
> Anyone else see this as a potential for a new module (gee.. how about
> ::Status or

Well I think there will be possibilities beyond status for this kind of
thing so I would really like to see something more general.

> ::Util::Status ?)

Net::LDAP::Util::Status is too deep IMO for such an API. It
really should be Net::LDAP::Something.

> containing functions/objects/whatever that query the ldap server to find
> out what it's capable of?
> ie:
> is it "up"? - with an anonymous bind
> is is "up"? - with a malformed packet request

Do you really want to give the user control over what type of check to do ?

> is it version 2 or version 3 compliant?
> does it support ssl/sasl/whatever?
> does it limit search requests? (and what are they)
> does it have timeouts? (and what are they)

IIRC, This is all avaliable from the root DSE. But I guess you are looking
for a simpler approach than

  $dse = $ldap->root_dse;
  $dse->get('supportedVersions'); # I forget the attribute name

> Mind you, if this was written, it'd be very tempting to include something
> to test for "type" of ldap server eg Netscape/openldap/novell and introduce
> server specific tests too.... is this a good or a bad thing?

I am not sure there is a way to determine the server type. Not reliably anyway.

> P.S. regarding the Ldap::Cooked (or whatever)...  I for one like the option
> of a simple "foolproof" API that is smart enough to figure out things like
> the ldap version to talk with(currently 3 falling back to 2),

You should bind to the version of which feature you need. If you don't use
version 3 features bind as version 2. If you want v3 feature, falling back to binding as
v2 is the wrong thing to do.

> whether ssl
> is supported on the server end (with a fall-back if its not),

This is dangerous. If you want SSL it is normally for a reason, so falling
back is REALLY the wrong thing.

> if searches
> are limited then automatically do multiple searches invisibly, etc etc.

The Net::LDAPiranah module did this but I don't think it works with the
latest version. But we will get it going again.

Graham.

Re: AuthNetLDAP

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

Hello Again!

At last I got this thing working with my Apache, I just really needed to
upgrade my apache ..
but here's another error_log I just encountered again, I checked out the
directories and Autnetldap is there ..            

[Fri Jul 28 17:42:35 2000] [error] Can't locate loadable object for module
Apache::AuthNetLDAP in @INC (@INC contains:
/usr/lib/perl5/5.00503/i386-linux /usr/lib/perl5/5.00503
/usr/lib/perl5/site_perl/5.005/i386-linux /usr/lib/perl5/site_perl/5.005 .
/etc/httpd/ /etc/httpd/lib/perl) at (eval 5) line 3




FROM: Mark Wilcox
           DATE: 07/26/2000 11:12:09
            SUBJECT: RE:  AuthNetLDAP
             
            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 
            > 
            > 




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

[Fwd] Re: (no subject)

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

----- Forwarded message from Alex Kilimnik <sac...@ya...> -----

Date: Thu, 27 Jul 2000 23:01:19 -0700 (PDT)
From: Alex Kilimnik <sac...@ya...>
Subject: Re: (no subject)
To: Graham Barr <gb...@po...>


Graham:

Thank you for your assistance regarding the version.
I have come to another roadblock and have not found
any documentation on the error I am receiving from
Perl during the execution of the script. The error I
am receiving from perl is "Died at ldap.pl line 9".

Below is a copy of my code which I modeled after
your example in the perldoc.  I apologize for
bothering
you, I am new to LDAP.

use Net::LDAP;

$ldap = Net::LDAP->new('x.x.x.x') or die "$@";
$ldap->bind;
$results = $ldap->search( base => "o=xxxxxx.com",
                          filter => ="(&(sn=Jones))"
                        );
$results->code && die $results->error;
foreach $entry ($results->entries) {
 print "$entry->dump\n";
}
$ldap->unbind;


Thanks in advance for any assistance.

Regards,
Alex

__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/


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

Re: ldap->ping?

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

What's listed here needs to be split into 2 objects.

To test for connectity, it could be Net::LDAP::isUp($ldap,[callback =>
\&callback]). by default it could try with anonymous bind. $ldap is an open
Net::LDAP connection. callback is an user defined function to determine LDAP
connection status.

As for things like what supported version,SASL,controls, etc. This all should
be in the server's root DSE (assuming it's LDAP 3, but an LDAP 2 server can't
give you this info).

Thus we could have an object like Net::LDAP::DSE.

You could get it by calling:
my $dse = $ldap->get_dse();

this could have methods like this:
$dse->version() #returns version
$dse->sasl() #returns an array of SASL elements
$dse->schema() #returns an array of names of schema entries
$dse->controls() #returns array of OIDS of supported controls
$dse->contexts() #return an array of contexts on the server
$dse->get("dse attribute") #returns an array of elements that for the attribute
passed to get

Now for SSL connectivity. I don't know how to easily test for that until we get
Net::LDAPS rolled into to Net::LDAP. Because Net::LDAPS does require a C
compiler (well Net::LDAPS doesn't but the underlying SSL modules it builds upon
do), we don't really want to make this a required object.

Mark
David Bussenschutt wrote:

> Anyone else see this as a potential for a new module (gee.. how about
> ::Status or ::Util::Status ?)
>
> containing functions/objects/whatever that query the ldap server to find
> out what it's capable of?
> ie:
> is it "up"? - with an anonymous bind
> is is "up"? - with a malformed packet request
> is it version 2 or version 3 compliant?
> does it support ssl/sasl/whatever?
> does it limit search requests? (and what are they)
> does it have timeouts? (and what are they)
>
> Mind you, if this was written, it'd be very tempting to include something
> to test for "type" of ldap server eg Netscape/openldap/novell and introduce
> server specific tests too.... is this a good or a bad thing?
>
> David.
>
> P.S. regarding the Ldap::Cooked (or whatever)...  I for one like the option
> of a simple "foolproof" API that is smart enough to figure out things like
> the ldap version to talk with(currently 3 falling back to 2), whether ssl
> is supported on the server end (with a fall-back if its not), if searches
> are limited then automatically do multiple searches invisibly, etc etc.
>
> At 01:21 PM 7/27/00 +0100, John Berthels wrote:
> >On Thu, 27 Jul 2000, Graham Barr wrote:
> >
> >> > 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 :)
> >
> >Heh. I didn't have the gall to suggest that.
> >
> >You could do something like issue a hopefully-low-impact search request.
> >(scope=single entry, pick a base, have an explicit filter
> >(cn=hopedoesntexist), ask for only 'cn' attribute back). But it still
> >feels icky.
> >
> >
> >On the issue of 'layers over Net::LDAP', I must have missed the "we don't
> >want sizelimit etc. management". Is there a real desire for a more
> >'cooked' API? (I quite like the current one...). Things like
> >$ldap->exists( $dn ) might be nice though.
> >
> >Whether that API lived in the Net::LDAP namespace/bundle or elsewhere
> >shouldn't be relevant to what it could do - what do people want? Do we
> >want a Net::LDAP::Cooked or Net::LDAPCooked module? If so what kind of
> >features would people want?
> >
> >jb
> >
> >
> >
> >
> >
>
> --------------------------------------------------------------------
> 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
> --------------------------------------------------------------------

ldap->ping?

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

Anyone else see this as a potential for a new module (gee.. how about
::Status or ::Util::Status ?)

containing functions/objects/whatever that query the ldap server to find
out what it's capable of?
ie:
is it "up"? - with an anonymous bind
is is "up"? - with a malformed packet request
is it version 2 or version 3 compliant?
does it support ssl/sasl/whatever?
does it limit search requests? (and what are they)
does it have timeouts? (and what are they)

Mind you, if this was written, it'd be very tempting to include something
to test for "type" of ldap server eg Netscape/openldap/novell and introduce
server specific tests too.... is this a good or a bad thing?

David.

P.S. regarding the Ldap::Cooked (or whatever)...  I for one like the option
of a simple "foolproof" API that is smart enough to figure out things like
the ldap version to talk with(currently 3 falling back to 2), whether ssl
is supported on the server end (with a fall-back if its not), if searches
are limited then automatically do multiple searches invisibly, etc etc.



At 01:21 PM 7/27/00 +0100, John Berthels wrote:
>On Thu, 27 Jul 2000, Graham Barr wrote:
>
>> > 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 :)
>
>Heh. I didn't have the gall to suggest that.
>
>You could do something like issue a hopefully-low-impact search request.
>(scope=single entry, pick a base, have an explicit filter
>(cn=hopedoesntexist), ask for only 'cn' attribute back). But it still
>feels icky.
>
>
>On the issue of 'layers over Net::LDAP', I must have missed the "we don't
>want sizelimit etc. management". Is there a real desire for a more
>'cooked' API? (I quite like the current one...). Things like
>$ldap->exists( $dn ) might be nice though.
>
>Whether that API lived in the Net::LDAP namespace/bundle or elsewhere
>shouldn't be relevant to what it could do - what do people want? Do we
>want a Net::LDAP::Cooked or Net::LDAPCooked module? If so what kind of
>features would people want?
>
>jb
>
>
>
>
>

--------------------------------------------------------------------
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: speed of Net::LDAP

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

haven't tested this particular routine, but here's atop of my head
Callback:
$ldap->(
       base => "ou=people,dc=unt,dc=edu",
       scope => "sub",
       filter => "uid=mewilcox",
       callback => \&callback()
      );

sub callback
{
  my ($mesg,$entry) = @_;

  $entry->dump() if (ref $entry eq 'Net::LDAP::Entry');
  
  $mesg->shift_entry(); 
}

As for the other LDAP modules:
1) Net::LDAPapi is completely dead. Clayton turned that over to Netscape
2) PerLDAP (aka the Mozilla LDAP module) hasn't been updated in quite a
long time. I'd say it's mostly dead. It should still work, but there's not
a lot of help out there and I have no idea if/when next version will be
coming out (though admittedly I haven't been on the mozilla LDAP newsgroup
in a long time).

As you can probably see is that the biggest penalty is paid during
startup. Thus if you can eliminate the startup costs, then you'll most
likely be fine. What I would recommend then is to put it entirely via HTTP
and use mod_perl so that the script is loaded once & run forever. 

You could also be a bit paranoid :). For example if the ultimate users who
use the application don't have anything else to compare it to, they likely
won't know or care (as long as it runs in something under an hour ;). We
use Net::LDAP for everything here at UNT with LDAP and performance has
never been a factor (e.g. we've never said, gee I wish it would run
faster). Like Chris Ridd said, portability and ease of use are much more
important to us.

Mark
          


On Thu, 27 Jul 2000, Luke Kanies wrote:

> Mark Wilcox wrote:
> > 
> > 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.
> 
> I understand that perl will be slower than C, but I didn't think that it
> would be an order of magnitude slower...
> 
> > 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.
> 
> What is a callback?  I have done most of my perl coding in what amounts
> to a vacuum, I guess.  I have seen callbacks mentioned in a couple email
> responses to my question, so what are they and how do I use them?
> 
> > 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?
> 
> Well, I am writing a suite of tools which will allow my admins (I'm an
> engineer at an ISP) to more easily maintain user accounts in our LDAP
> database; it pretty much needs to be synchronous, so I can't do it in
> batch mode, and I am willing to spend dev time now to avoid run time
> later.  Except that I really am not very good in coding anything other
> than perl (I learned it first, basically, and now I am spoiled).
> 
> > 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.
> 
> What about the mozilla ldap module?  Is it still being worked on?  
> 
> > 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.
> 
> Uh, no, I don't think you'd want my help writing C...  You could do more
> in an hour than I could in a week.
> 
> > 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).
> 
> Well, some of my scripts will be CGI based, but the script that prompted
> me to send this mail is actually command line, so that's not an issue.
> 
> > 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.
> 
> As I said, I did expect Net::LDAP to be slower, I just didn't expect it
> to be that much slower.  And portability isn't really a concern for me,
> since (a) my company uses solaris/sparc exclusively, and (b) this suite
> of tools will be run on only a few machines.
> 
> This is the second or third time I have tried to develop a bunch of
> tools using perl to talk to LDAP.  The first time was when I was first
> learning LDAP, and I basically just got frustrated; Net::LDAP was too
> slow to do what I needed it to do, Net::LDAPapi's api was so confusing
> that I never got it figured out (although I seem to be able to
> understand it much better now), and there didn't seem to be any other
> choices.  I ended up just running command line searches and parsing
> through them, but that means having passwords run as flags on the
> command line, and that's bad.
> 
> And then I went and destroyed all of that code accidentally.  Yay.
> 
> I took a hiatus for quite a while, but am now revisiting the problem,
> and I would like to do it right.  But I can't wait 20 seconds for a
> command line app to finish its very first search, much less do all the
> work it needs to.
> 
> Thanks for the quick response, BTW.
> 
> 

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

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

"Kurt D. Zeilenga" <Ku...@Op...> wrote:

> I should finish my morning coke before responding...  my suggested
> ping method works well only if that's all you want to do (as it
> returns the session to anonymous status).
>
> As a more general mechanism, I suggest you issue a base
> search upon an empty DN for attributes 1.1.  You should get
> some response.

The amount of response depending on your server vendor's philosophy ;-)

>> I can't think of a simple and portable way to do this in LDAPv2.
>
> Anonymous bind.  In fact, I suggest as a cheap general solution
> for all versions of LDAP.  Anonymous binds are generally quite
> cheap... in fact may be even cheaper than accessing the LDAPv3
> root DSE (depending on implementation).
>
> Kurt
>

Anonymous binds might be prevented by configuration, and some vendors don't 
support multiple binds on the same connection.

Doing a bind also has the nasty side effect of changing your credentials...

Apart from that, yes an anonymous bind is about the cheapest operation you 
can send a server.

Cheers,

Chris

Re: speed of Net::LDAP

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

Mark Wilcox wrote:
> 
> 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.

I understand that perl will be slower than C, but I didn't think that it
would be an order of magnitude slower...

> 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.

What is a callback?  I have done most of my perl coding in what amounts
to a vacuum, I guess.  I have seen callbacks mentioned in a couple email
responses to my question, so what are they and how do I use them?

> 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?

Well, I am writing a suite of tools which will allow my admins (I'm an
engineer at an ISP) to more easily maintain user accounts in our LDAP
database; it pretty much needs to be synchronous, so I can't do it in
batch mode, and I am willing to spend dev time now to avoid run time
later.  Except that I really am not very good in coding anything other
than perl (I learned it first, basically, and now I am spoiled).

> 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.

What about the mozilla ldap module?  Is it still being worked on?  

> 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.

Uh, no, I don't think you'd want my help writing C...  You could do more
in an hour than I could in a week.

> 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).

Well, some of my scripts will be CGI based, but the script that prompted
me to send this mail is actually command line, so that's not an issue.

> 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.

As I said, I did expect Net::LDAP to be slower, I just didn't expect it
to be that much slower.  And portability isn't really a concern for me,
since (a) my company uses solaris/sparc exclusively, and (b) this suite
of tools will be run on only a few machines.

This is the second or third time I have tried to develop a bunch of
tools using perl to talk to LDAP.  The first time was when I was first
learning LDAP, and I basically just got frustrated; Net::LDAP was too
slow to do what I needed it to do, Net::LDAPapi's api was so confusing
that I never got it figured out (although I seem to be able to
understand it much better now), and there didn't seem to be any other
choices.  I ended up just running command line searches and parsing
through them, but that means having passwords run as flags on the
command line, and that's bad.

And then I went and destroyed all of that code accidentally.  Yay.

I took a hiatus for quite a while, but am now revisiting the problem,
and I would like to do it right.  But I can't wait 20 seconds for a
command line app to finish its very first search, much less do all the
work it needs to.

Thanks for the quick response, BTW.

-- 
Luke A. Kanies  | "Love is a snowmobile racing across the tundra and
System Engineer | then suddenly it flips over, pinning you underneath.
615/778-7268    | At night, the ice weasels come."
pgr 800/415-1972|               --Matt Groening

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

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

On Thu, Jul 27, 2000 at 08:03:42AM -0700, Kurt D. Zeilenga wrote:
> At 12:20 PM 7/27/00 +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.
> 
> I suggest you attempt an anonymous bind.  This should always return
> a result (possibly indicating an error).  If you want to force an
> error, select version MAXINT.

Would that not be a problem if you are already bound as a user ?

Graham.

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

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

I should finish my morning coke before responding...  my suggested
ping method works well only if that's all you want to do (as it
returns the session to anonymous status).

As a more general mechanism, I suggest you issue a base
search upon an empty DN for attributes 1.1.  You should get
some response.

Kurt

At 12:20 PM 7/27/00 +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.

I suggest you attempt an anonymous bind.  This should always return
a result (possibly indicating an error).  If you want to force an
error, select version MAXINT.


>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.

Or ask for attribute "1.1"... (you'll have less to throw away).

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

Anonymous bind.  In fact, I suggest as a cheap general solution
for all versions of LDAP.  Anonymous binds are generally quite
cheap... in fact may be even cheaper than accessing the LDAPv3
root DSE (depending on implementation).

Kurt

Re: speed of Net::LDAP

[Benjamin J. <Ben...@Re...>]

Luke Kanies wrote:

> 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.

Those numbers are really bad. Searches do not take anywhere near that long
for me unless I am searching on an unindexed attribute.

I have a script that dumps the uid, givenname, and sn for groups (see
attached). It dumps a group with 1056 members in 44.72 seconds. There is a
total of 1057 searches run in that time. They are very specific searches,
so the LDAP server doesn't need to do much work for them. The output was
dumped to the screen, so the IO was also slowing the script down.

I have another script that dumps an ldap search as a CSV file. Using a
simple search it is able to dump 264 records with 15 attributes each in
4.86 seconds. Moving to a callback cut the time that these searches took in
half and the memory usage now stays constant. Without the callback the
memory usage went to about 100 times what it now uses when I dumped my
entire tree.

Both of these times are for the entire script run, including perl loading,
IO, ldap searches, etc. This is on a Red Hat 6.1 machine with a 266 MHz
PII.

When I first looked at this module I had a problem with the startup time
for loading scripts being on the order of 30 seconds. That was due to an
interaction between the module and a messed up perl install one one machine
only. That was with a really old version of Net::LDAP. Upgrading Net::LDAP
fixed the problem on that machine. My advise would be to make sure you have
a recent version of Net::LDAP, and check your perl install. You may also
need to use callbacks to get better results.


Ben

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

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

At 12:20 PM 7/27/00 +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.

I suggest you attempt an anonymous bind.  This should always return
a result (possibly indicating an error).  If you want to force an
error, select version MAXINT.


>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.

Or ask for attribute "1.1"... (you'll have less to throw away).

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

Anonymous bind.  In fact, I suggest as a cheap general solution
for all versions of LDAP.  Anonymous binds are generally quite
cheap... in fact may be even cheaper than accessing the LDAPv3
root DSE (depending on implementation).

Kurt

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

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

Graham Barr <gb...@po...> wrote:

> 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.
>

Well that's a bit *too* evil! V3 servers are at liberty to disconnect you 
if you do that, and I wouldn't be surprised if some v2 servers did 
something similar.

Cheers,

Chris

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

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

On Thu, Jul 27, 2000 at 01:21:47PM +0100, John Berthels wrote:
> On Thu, 27 Jul 2000, Graham Barr wrote:
> 
> > > 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 :)
> 
> Heh. I didn't have the gall to suggest that.
> 
> You could do something like issue a hopefully-low-impact search request.
> (scope=single entry, pick a base, have an explicit filter
> (cn=hopedoesntexist), ask for only 'cn' attribute back). But it still
> feels icky.

I suppose the question is "what is the result of ping supposed to mean"

If it just means the tcp connection is still alive then we can do anything.
But I suspect people want it to look at the result code to determine if
the server has decided to refuse to process requests or something.

> On the issue of 'layers over Net::LDAP', I must have missed the "we don't
> want sizelimit etc. management". Is there a real desire for a more
> 'cooked' API? (I quite like the current one...). Things like
> $ldap->exists( $dn ) might be nice though.
> 
> Whether that API lived in the Net::LDAP namespace/bundle or elsewhere
> shouldn't be relevant to what it could do - what do people want? Do we
> want a Net::LDAP::Cooked or Net::LDAPCooked module? If so what kind of
> features would people want?

I am happy with the idea, but yes the question of where does arise. Although
do they have to be methods ? We could just add functions to ::Util that accept
$ldap as the first argument. But I suspect people will want a sub-class.

Alternatively they could be added to Net::LDAP and would could AUTOLOAD them.
But then we really need to ask the question "what do they return?" If in the
exists example it returns a boolean, then it is limited to being used in a
sync mode.

Although I am sure we could do something with ::Message to allow hooks to
analyse results.

I would certainly invite discussion on the subject of adding extensions to Net::LDAP


Graham.

> jb
> 
> 
> 

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

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

On Thu, 27 Jul 2000, Graham Barr wrote:

> > 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 :)

Heh. I didn't have the gall to suggest that.

You could do something like issue a hopefully-low-impact search request.
(scope=single entry, pick a base, have an explicit filter
(cn=hopedoesntexist), ask for only 'cn' attribute back). But it still
feels icky.


On the issue of 'layers over Net::LDAP', I must have missed the "we don't
want sizelimit etc. management". Is there a real desire for a more
'cooked' API? (I quite like the current one...). Things like
$ldap->exists( $dn ) might be nice though.

Whether that API lived in the Net::LDAP namespace/bundle or elsewhere
shouldn't be relevant to what it could do - what do people want? Do we
want a Net::LDAP::Cooked or Net::LDAPCooked module? If so what kind of
features would people want?

jb

unsub

[OHarra, J. <Joh...@de...>]

unsub