perl-ldap-dev

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

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?

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

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

[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

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?

[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

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

Re: ldap->ping?

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

On Thu, Jul 27, 2000 at 09:33:18PM -0500, Mark Wilcox 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 think I would like to keep it called `ping'

> 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

I like this idea. And as root_dse already returns an entry and Net::LDAP::DSE
could just be a subclass of Net::LDAP::Entry it would also be backwards compatable.

Graham.

Re: ldap->ping?

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

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?

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

Good idea though.

> 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

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.

Cheers,

Chris

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.

Re: ldap->ping?

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

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

> 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?
[...]
> connection is still live.  Personally I would say just catch the errors
> to any operation and re-connect if you need to.

I agree.

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

Supporting other DSEs is tricky in LDAP because they're not really 
described properly in the LDAP RFCs, and the mechanism for getting them 
(via the manageDsaIT service control) is not a standard part of LDAP.

The only commonality between DSEs is an attribute called dseType. The value 
is a named bitstring, eg "( entry $ admPoint )", or "( root )".

If you want a more generic Net::LDAP::DSE, then it would need to hold the 
dseType, and construct the more specific RootDSE object if it found the 
dseType contained 'root'.

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

Which one? The default one?

> Graham.

Cheers,

Chris

Re: ldap->ping?

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

On Mon, Jul 31, 2000 at 10:26:22AM +0100, Chris Ridd wrote:
> > Hm, I see your point. But could we make a more generic Net::LDAP::DSE ? Is
> > it worth it ?
> 
> Supporting other DSEs is tricky in LDAP because they're not really 
> described properly in the LDAP RFCs, and the mechanism for getting them 
> (via the manageDsaIT service control) is not a standard part of LDAP.
> 
> The only commonality between DSEs is an attribute called dseType. The value 
> is a named bitstring, eg "( entry $ admPoint )", or "( root )".
> 
> If you want a more generic Net::LDAP::DSE, then it would need to hold the 
> dseType, and construct the more specific RootDSE object if it found the 
> dseType contained 'root'.

Hm, I think just ::RootDSE would be fine.

> >> 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 :)
> 
> Which one? The default one?

Yes, as you said there is no way to determine if they are supporting it,
so you can only try the default port.

Graham.

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

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

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

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

> 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

Yeah, close. RFC 2251 specifies supportedLDAPVersion (and supportedControl 
etc) so reading that attribute should suffice. If it ain't there the server 
almost certainly doesn't support LDAPv3 so you've pretty much got no way to 
work out what it does do.

(It might support LDAPv3 but prevent read access to that attribute. 
Unlikely perhaps, but permitted.)

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

There isn't. There was an Internet draft recently which specified a place 
to put a vendor string, but with the strict instructions that clients 
weren't to make use of it to switch behaviours. So that's out - I think the 
draft got stomped on anyway.

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

Absolutely this is a bad way to fall back. You should never fall back and 
change security silently.

Cheers,

Chris

Re: ldap->ping?

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

Hi all (again),

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

Why not... the best API is one that is simple to use with plenty of
defaults, but open enough to allow the user to use advanced options if they
prefer/require...  That's also the perl way of thinking isn't it?  I think
Marks suggestion is great, allow an optional call back, default to a decent
one(or more) if it's not provided... like:

Net::LDAP::isUp($ldap,[callback =>\&callback|callback
=>'anonymous'|callback =>'malformed']). 

>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

The fact that you forget the attribute name is a perfect reason for
allowing a simpler approach.

I'm hopeless at remembering standard attribute names,etc..and why should I
have to?  If it's used frequently enough, include it as an option/default.
eg: $dse->getSupportedVersions();
I know in this case the code is trivial, and probably not a good candidate
for it, but you see my point don't you?

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

What if I have the situation where I would prefer a secure connection to
keep away potential prying eyes, but I want the connection to succeed even
if that's not possible. (ie prefer a ssl connection using the version 3
protocol, but be happy to fall-back to version 2 on an unencrypted channel
if I have no other option) 

I'm big on fail-safes and fall backs..I like scripts to keep on working no
matter what goes wrong.... 

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

As above, I like scripts to keep on working no matter what goes wrong.
Which is worse.. having thousands of users that can't log in because a
script failed to update their LDAP settings (sorry attributes) correctly,
or having a potentially unsecure connection to do it?    I guess it depends
on the situation.

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

I'd Love to see it as an advanced option to the standard search function/s.

my 2c.
David.





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

Extended schema

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

Hi,
I have extended the ldap directory schema. However, the search based on the
newly defined attribute/object class yields nothing. How can I enable the
search to recognise the new attribute/object class?

Thanks.

spencer

Re: Extended schema

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

Did you populate your entries with values for these new attributes?

mark

spencer wrote:

> Hi,
> I have extended the ldap directory schema. However, the search based on the
> newly defined attribute/object class yields nothing. How can I enable the
> search to recognise the new attribute/object class?
>
> Thanks.
>
> spencer