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