Re: ldap->ping?

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

On Mon, Jul 31, 2000 at 09:44:56AM +0100, Chris Ridd wrote:
> Mark Wilcox <mew...@un...> wrote:
> 
> > 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.
> 
> I'm sort of nervous about this because of the side-effects. How can we 
> implement this without side-effects?

I too had the same concern. First I thought we could just document the
possible side effects, but I fear that is not enough. For example some
servers do not allow multiple binds, so using an anon bind is useless
as afterwards you will have to reconnect anyway. Plus if you are already
bound, you will loose that binding.

But then someone suggested doing a simple search. This could work with
minimal side effects. But the sync/async-ness troubles me. I suppose by
nature ->ping is a sync operation as you are trying to determine if the
connection is still live.  Personally I would say just catch the errors
to any operation and re-connect if you need to.

> > 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.
> 
> No, that's too generic - servers have lots of DSEs and you are only talking 
> about the root one. Net::LDAP::RootDSE would IMHO be a better choice.

Hm, I see your point. But could we make a more generic Net::LDAP::DSE ? Is
it worth it ?

> > 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.
> 
> Servers support SSL in two ways. The first is by listening on a separate 
> port (default 636) and requiring SSL connections on that port. That's what 
> Net::LDAPS uses.
> 
> The second is using the *normal* LDAP port (default 389) and allowing the 
> user to switch into SSL mode (actually, TLS mode) using the startTLS 
> extended operation. This is the recommended way of using SSL (er, TLS) with 
> a directory, and is standardized in RFC 2830.
> 
> To find out if the second mode is supported, check the supportedExtension 
> attribute contains the startTLS OID (1.3.6.1.4.1.1466.20037)
> 
> I don't think there's a way to find if the first mode's supported. You 
> can't go by vendor names and product versions, because administrators might 
> feasibly disable LDAPS support.

Sure there is. Just try to connect to the LDAPS port :)

Graham.