perl-ldap-dev

Re: how to run ldap search fast?

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

At 05:28 PM 10/16/00 -0500, Bing Du wrote:
>Benchmark shows most 'search' operations contribute 0 seconds.  About
>20 or so contribute 1 seconds each.  So the total execution time is 20
>or even more seconds.  A note from vendor says the current DS version is
>6.1v0 and it can yield 50% speed improvement.  Just  want to know how
>much of this performance issue is server related?  Any suggestions on
>how to run ldap search fast on the client side?

Reduce the number of protocol operations.  For example,
you might be able to use one search operation instead of
500 hundred.  If multiple operations are needed, only
serialize operations were needed.  For example, you
could submit 500 search requests (using the async
interface) then await results.

how to run ldap search fast?

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

We are using 5.0v2p2 directory server from MessagingDirect.  

Given 500 studentIDs, Net::LDAP is used in a cgi script to retrieve
name, e-mail address, major, etc. for each ID.  Like this:

connect ldap
foreach (@studentids)
{
$t0 = new Benchmark;
$mesg = $ld->search(base => $BASEDN, scope => 'sub', filter => $filter,
attr
s => @$attributes, typesonly => 0);
$t1 = new Benchmark;
$td = timediff($t1,$t0);
}
disconnect ldap

Benchmark shows most 'search' operations contribute 0 seconds.  About
20 or so contribute 1 seconds each.  So the total execution time is 20
or even more seconds.  A note from vendor says the current DS version is
6.1v0 and it can yield 50% speed improvement.  Just  want to know how
much of this performance issue is server related?  Any suggestions on
how to run ldap search fast on the client side?

Thanks,

Bing    
 

Bing Du <bi...@ta..., 979-845-9577>
Texas A&M University, CIS, Operating Systems, Unix

[Fwd] LDAP::Entry question.

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

----- Forwarded message from dmckeon <dm...@ra...> -----

From: "dmckeon" <dm...@ra...>
To: gb...@po...
Subject: LDAP::Entry question. 
Date: Mon, 16 Oct 2000 14:46:46 GMT


Hello,
	I have a couple questions about your ldap perl module.  I'm very new to
using OO perl and to Ldap.  I'm kind of struggling, I was wondering if you
know of a simple example of how to get a single dn's attributes.  Is there
an online resource of a simple example? 

I seem to be binding ok, and even doing a new $entry call.  But when I go
to access the attribute hash I'm not very successful. :(


Thank you for your time, I hope I'm not bothering you with silly questions.

David McKeon
LDAP newbie.

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

Re: hash as multiple attrs value

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

Graham Barr <gb...@po...> wrote:
> On Mon, Oct 16, 2000 at 10:19:21AM +0100, Chris Ridd wrote:
>> Werner Reisberger <we...@pu...> wrote:
>> > On Fri, Oct 13, 2000 at 04:03:25PM -0500, Mark Wilcox wrote:
>> >> The value of the hash would have to contain an array. 
>> >> 
>> >> like this:
>> >>    my $array = ['value','value','value'];
>> >>    or
>> >>    $array->[0] = 'value';
>> >>    $array->[1] = 'value';
>> > 
>> > OK, this way I could create several attribute/value pairs where the
>> > attribute (key) doesn't change but I want to have several different
>> > attributes in my hash. Example:
>> > 
>> >  dc => 'mydom.com',
>> >  sn => 'Brown',
>> >  cn => 'C B'
>> > 
>> > I want to put these attribute/value pairs into a structure (hash ...)
>> > and supply this structure to the attrs method to avoid writing each
>> > attribute/value pair seperately:
>> > 
>> >            $ldap->add (
>> >                         dn   => $dn,
>> >                         attrs => [%myhash] );               
>> > 
>> > I used an array of anonymous hashes and an array and a hash within the 
>> > anonymous array. First case doesn't work at all, in the last two trials
>> > only  one attribute is added to the entry.
>> > 
>> >  Werner
>> 
>> Couldn't you just use:
>> 
>> 	$ldap->add (	dn => $dn,
>> 			attrs => [ keys %myhash ] );
> 
> No, thats not right. Look at the example in the docs
> 
>   $mesg = $ldap->add( $DN,
>     attrs => [
>       name  => 'Graham Barr',
>       attr  => 'value1',
>       attr  => 'value2',
>       multi => [qw(value1 value2)]
>     ]
>   );
> 
> This adds 4 attributes, each with a single value except 'multi' which has
> multiple values.
> 
> So if %myhash has an entry per attribute. The values need to
> be either the value (for single valued attributes) or a reference
> to an array of values (for multi or singled-valued attributes)
> 
> Graham.

Yup, you're right. Consider this a "Doh!"

Cheers,

Chris

Re: hash as multiple attrs value

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

On Mon, Oct 16, 2000 at 10:19:21AM +0100, Chris Ridd wrote:
> Werner Reisberger <we...@pu...> wrote:
> > On Fri, Oct 13, 2000 at 04:03:25PM -0500, Mark Wilcox wrote:
> >> The value of the hash would have to contain an array. 
> >> 
> >> like this:
> >>    my $array = ['value','value','value'];
> >>    or
> >>    $array->[0] = 'value';
> >>    $array->[1] = 'value';
> > 
> > OK, this way I could create several attribute/value pairs where the
> > attribute (key) doesn't change but I want to have several different
> > attributes in my hash. Example:
> > 
> >  dc => 'mydom.com',
> >  sn => 'Brown',
> >  cn => 'C B'
> > 
> > I want to put these attribute/value pairs into a structure (hash ...) and
> > supply this structure to the attrs method to avoid writing each
> > attribute/value pair seperately:
> > 
> >            $ldap->add (
> >                         dn   => $dn,
> >                         attrs => [%myhash] );               
> > 
> > I used an array of anonymous hashes and an array and a hash within the 
> > anonymous array. First case doesn't work at all, in the last two trials
> > only  one attribute is added to the entry.
> > 
> >  Werner
> 
> Couldn't you just use:
> 
> 	$ldap->add (	dn => $dn,
> 			attrs => [ keys %myhash ] );

No, thats not right. Look at the example in the docs

  $mesg = $ldap->add( $DN,
    attrs => [
      name  => 'Graham Barr',
      attr  => 'value1',
      attr  => 'value2',
      multi => [qw(value1 value2)]
    ]
  );

This adds 4 attributes, each with a single value except 'multi' which has
multiple values.

So if %myhash has an entry per attribute. The values need to
be either the value (for single valued attributes) or a reference
to an array of values (for multi or singled-valued attributes)

Graham.

Re: hash as multiple attrs value

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

Werner Reisberger <we...@pu...> wrote:
> On Fri, Oct 13, 2000 at 04:03:25PM -0500, Mark Wilcox wrote:
>> The value of the hash would have to contain an array. 
>> 
>> like this:
>>    my $array = ['value','value','value'];
>>    or
>>    $array->[0] = 'value';
>>    $array->[1] = 'value';
> 
> OK, this way I could create several attribute/value pairs where the
> attribute (key) doesn't change but I want to have several different
> attributes in my hash. Example:
> 
>  dc => 'mydom.com',
>  sn => 'Brown',
>  cn => 'C B'
> 
> I want to put these attribute/value pairs into a structure (hash ...) and
> supply this structure to the attrs method to avoid writing each
> attribute/value pair seperately:
> 
>            $ldap->add (
>                         dn   => $dn,
>                         attrs => [%myhash] );               
> 
> I used an array of anonymous hashes and an array and a hash within the 
> anonymous array. First case doesn't work at all, in the last two trials
> only  one attribute is added to the entry.
> 
>  Werner

Couldn't you just use:

	$ldap->add (	dn => $dn,
			attrs => [ keys %myhash ] );

Cheers,

Chris

Re: hash as multiple attrs value

[Werner R. <we...@pu...>]

On Fri, Oct 13, 2000 at 04:03:25PM -0500, Mark Wilcox wrote:
> The value of the hash would have to contain an array. 
> 
> like this:
>    my $array = ['value','value','value'];
>    or
>    $array->[0] = 'value';
>    $array->[1] = 'value';

OK, this way I could create several attribute/value pairs where the
attribute (key) doesn't change but I want to have several different attributes
in my hash. Example:

 dc => 'mydom.com',
 sn => 'Brown',
 cn => 'C B'

I want to put these attribute/value pairs into a structure (hash ...) and
supply this structure to the attrs method to avoid writing each
attribute/value pair seperately:

           $ldap->add (
                        dn   => $dn,
                        attrs => [%myhash] );               

I used an array of anonymous hashes and an array and a hash within the 
anonymous array. First case doesn't work at all, in the last two trials only 
one attribute is added to the entry.

 Werner

Re: hash as multiple attrs value

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

On Fri, Oct 13, 2000 at 04:03:25PM -0500, Mark Wilcox wrote:
> The value of the hash would have to contain an array. 
> 
> like this:
>    my $array = ['value','value','value'];
>    or
>    $array->[0] = 'value';
>    $array->[1] = 'value';
> 
> 
>    $hash->{$key} = $array;

Yes that is right.

>     or it might have to be
>    $hash->{$key} = @$array;

Um, no. That would assign the number 3 to  $hash->{$key}

Graham.

> 
> Mark
> 
> On Fri, 13 Oct 2000, Werner Reisberger wrote:
> 
> > I want to do something like
> > 
> >  $res = $ldap->add (
> >                     dn   => "dc=${dc},$base",
> >                     attrs => [%myhash] );
> > 
> > Unfortunately only one key/value pair of %myhash is used for the
> > entry. I want to use a hash since I have to create entries with a varying
> > set of attributes and I don't know how I could do this in a simple way.
> > 
> >  Werner
> > 
> 

Re: hash as multiple attrs value

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

The value of the hash would have to contain an array. 

like this:
   my $array = ['value','value','value'];
   or
   $array->[0] = 'value';
   $array->[1] = 'value';


   $hash->{$key} = $array;
    or it might have to be
   $hash->{$key} = @$array;

Mark

On Fri, 13 Oct 2000, Werner Reisberger wrote:

> I want to do something like
> 
>  $res = $ldap->add (
>                     dn   => "dc=${dc},$base",
>                     attrs => [%myhash] );
> 
> Unfortunately only one key/value pair of %myhash is used for the
> entry. I want to use a hash since I have to create entries with a varying
> set of attributes and I don't know how I could do this in a simple way.
> 
>  Werner
> 

hash as multiple attrs value

[Werner R. <we...@pu...>]

I want to do something like

 $res = $ldap->add (
                    dn   => "dc=${dc},$base",
                    attrs => [%myhash] );

Unfortunately only one key/value pair of %myhash is used for the
entry. I want to use a hash since I have to create entries with a varying
set of attributes and I don't know how I could do this in a simple way.

 Werner

Net::LDAP in Wrox's Professional Perl book

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

Hi,
I've just agreed (ok, we're still finalizing all of the paperwork but it's
essentially a done deal) to write a chapter on LDAP using the Net::LDAP
module for Wrox's upcoming Professional Perl Programming book.

If you'd like to be a reviewer for the chapter (and/or book) send an email
to Julia Gilber at Ju...@wr.... 

It doesn't take too much time, you get paid a little bit of money and you
get a free copy of the book (which is probably the best part of the deal). 

The chapter is due on Nov 5 (though I'm going to do my best to get it done
before then), so you'd probably get it for review between the 8-15 of
November.

The final book would probably be done around December/January.

Mark

(no subject)

[<ef...@21...>]

DQo=

Suscribe

[Javier R. <te...@rd...>]

Suscribe

Re: perl-ldap-dev digest, Vol 1 #139 - 1 msg

[Javier R. <te...@rd...>]

----- Original Message -----
From: <per...@li...>
To: <per...@li...>
Sent: Thursday, October 12, 2000 9:15 PM
Subject: perl-ldap-dev digest, Vol 1 #139 - 1 msg


> Send perl-ldap-dev mailing list submissions to
> per...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.sourceforge.net/mailman/listinfo/perl-ldap-dev
> or, via email, send a message with subject or body 'help' to
> per...@li...
>
> You can reach the person managing the list at
> per...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of perl-ldap-dev digest..."
>
>
> Today's Topics:
>
>   1. Net::LDAP::LDIF::write_cmd with unchanged entry (Chris Brierley)
>
> --__--__--
>
> Message: 1
> From: Chris Brierley <bri...@po...>
> To: per...@li...
> Subject: Net::LDAP::LDIF::write_cmd with unchanged entry
> Date: 11 Oct 2000 16:04:05 -0400
>
> I've noticed some behavior that I didn't expect with
> Net::LDAP::LDIF::write_cmd.  I don't know if this is a bug or
> planned, but it caught me off guard.
>
> It seems that write_cmd causes a fatal error if called on an entry
> that has not been changed.  E.g. I'm iterating over a bunch of
> entries, making changes if they are necessary, and writing out an
> LDIF file which represents the change with:
>
>     Net::LDAP::LDIF->new(\*LDIF_FINAL)->write_cmd($entry);
>
> If $entry has *not* been changed, my program dies with:
>
> ,----
> | Can't use an undefined value as an ARRAY reference at
/usr/lib/perl5/site_perl/5.005/Net/LDAP/Entry.pm line 278.
> `----
>
> That's the changes subroutine:
>
> ,----
> | sub changes {
> |   @{shift->{'changes'}}
> | }
> `----
>
> An entry which is returned from a search and not changed does not
> have a changes key, and thus the above routine dies.
>
> I can easily work around this by keeping track of whether I modify
> the entry or not and only call write_cmd if it's been modified
> .. but this behavior was very unexpected to me.  Should'nt
> write_cmd simply not write anything out if there is nothing to
> change?
>
> Thanks.
>
>
>
> --__--__--
>
> _______________________________________________
> perl-ldap-dev mailing list
> per...@li...
> http://lists.sourceforge.net/mailman/listinfo/perl-ldap-dev
>
>
> End of perl-ldap-dev Digest
>

Re: Net::LDAP::LDIF::write_cmd with unchanged entry

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

On Thu, Oct 12, 2000 at 09:03:16PM +0100, Graham Barr wrote:
> PLease try the attached patch.

Arrg, wrong file. Try this one :)

Graham.

Re: Net::LDAP::LDIF::write_cmd with unchanged entry

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

PLease try the attached patch.

On Wed, Oct 11, 2000 at 04:04:05PM -0400, Chris Brierley wrote:
> I've noticed some behavior that I didn't expect with
> Net::LDAP::LDIF::write_cmd.  I don't know if this is a bug or
> planned, but it caught me off guard.
> 
> It seems that write_cmd causes a fatal error if called on an entry
> that has not been changed.  E.g. I'm iterating over a bunch of
> entries, making changes if they are necessary, and writing out an
> LDIF file which represents the change with:
> 
>     Net::LDAP::LDIF->new(\*LDIF_FINAL)->write_cmd($entry);
> 
> If $entry has *not* been changed, my program dies with:
> 
> ,----
> | Can't use an undefined value as an ARRAY reference at /usr/lib/perl5/site_perl/5.005/Net/LDAP/Entry.pm line 278.
> `----
> 
> That's the changes subroutine:
> 
> ,----
> | sub changes {
> |   @{shift->{'changes'}}
> | }
> `----
> 
> An entry which is returned from a search and not changed does not
> have a changes key, and thus the above routine dies.
> 
> I can easily work around this by keeping track of whether I modify
> the entry or not and only call write_cmd if it's been modified
> ... but this behavior was very unexpected to me.  Should'nt
> write_cmd simply not write anything out if there is nothing to
> change?
> 
> Thanks.
> 

Net::LDAP::LDIF::write_cmd with unchanged entry

[Chris B. <bri...@po...>]

I've noticed some behavior that I didn't expect with
Net::LDAP::LDIF::write_cmd.  I don't know if this is a bug or
planned, but it caught me off guard.

It seems that write_cmd causes a fatal error if called on an entry
that has not been changed.  E.g. I'm iterating over a bunch of
entries, making changes if they are necessary, and writing out an
LDIF file which represents the change with:

    Net::LDAP::LDIF->new(\*LDIF_FINAL)->write_cmd($entry);

If $entry has *not* been changed, my program dies with:

,----
| Can't use an undefined value as an ARRAY reference at /usr/lib/perl5/site_perl/5.005/Net/LDAP/Entry.pm line 278.
`----

That's the changes subroutine:

,----
| sub changes {
|   @{shift->{'changes'}}
| }
`----

An entry which is returned from a search and not changed does not
have a changes key, and thus the above routine dies.

I can easily work around this by keeping track of whether I modify
the entry or not and only call write_cmd if it's been modified
... but this behavior was very unexpected to me.  Should'nt
write_cmd simply not write anything out if there is nothing to
change?

Thanks.

Re: problems with resolving groups (rescursive)

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

On Tue, Oct 10, 2000 at 10:23:21AM -0500, Mark Wilcox wrote:
> I'm all for this :). I think probably it's better to make it a subclass of
> Net::LDAP::Util like Net::LDAP::Util::GroupSearch or perhaps a method of
> util.

This all comes back to the discussion we had about APIs a long time ago.

For subs which return a message object like the normal methods then sub-class
makes sense. But then how do you use several subclasses, you have to create your
own sub-class which inherits from them all. Thats messy.

What I am considering is a Net::LDAP::Extn (althou thats too close to Extension
so I need a better name). This class will install extras methods into Net::LDAP.
So for example

Net::LDAP::Extn::groupsearch

would define and export a groupsearch method

use Net::LDAP::Extn qw(groupsearch);

will load the module and install the method into Net::LDAP, thus making
it avaliable to all Net::LDAP methods.

Graham.

> 
> Mark
> 
> On Mon, 9 Oct 2000, Jurgen Botz wrote:
> 
> > =?iso-8859-1?Q?Bj=F6rn_Nilsson_=28QDT=29?= wrote:
> > > I'm trying to modify the printMembers.pl script (which is included in the
> > > Example subdir of the distribution of the LDAP module) to suit my needs. My
> > > problem is that the script doesn't resolve the sublists at all, or that it
> > > just resolve the first member of a sublist. What I want is to get each and
> > > every members (person) attributes to insert them into another database,
> > > grouped by the mailinglist in question.
> > 
> > I have written a bunch of code to resolve all the members of a group, list
> > all the groups a person is a member of (memberships), and test for membership
> > in a group.  This works for nested groups and "dynamic groups" (groups with
> > memberURL attributes).
> > 
> > I packaged this up as a set of extensions to Net::LDAP by subclassing.  The
> > idea is that my functions work like searches but may actually do multiple
> > searches to do their work so they return a specialied Net::LDAP::Search
> > object.  In other words, you can do this:
> > 
> >   $result = $ldap->get_members($groupdn, 'attrs' => [ 'cn', 'uid', 'title' ]);
> > 
> > And $result will contain all the entries of the members with the specifed
> > attributes (or all attributes if not specified, just like search).
> > 
> > The code does some mildly interesting things to be efficient, such as
> > aggregating searches for entries under the same base and going to some 
> > lengths to avoid having to retrieve the same entry twice... this was
> > also the motivation for returning the same kind of object as a search, so
> > I don't have a function that retruns a list of the dn's of members and
> > then I have to retrieve each member entry again just to get some more
> > attributes for it.
> > 
> > I'm calling this kind of thing a "metasearch".  Ideally metasearches should
> > work exactly like normal ones to the consumer, including doing them async,
> > but I haven't actually implemented async yet.
> > 
> > I was going to handle async and improve some things before releasing this,
> > but if there's sufficient interest I'll see if I can package it up now and
> > pass it on.
> > 
> > I'm also in interested in what people (especially Graham) think about this
> > approach to doing complex or semantic searches.  Is subclassing Net::LDAP
> > and Net::LDAP::Search the right way to go?  What should I call this thing?
> > (right now it's called Eazel::LDAP because I work at Eazel and I wrote it
> > for a work-related project.)
> > 
> > - Jürgen Botz
> > 
> > 
> > 
> > 
> > 
> > 
> 

Re: advantages of ldap over dbms

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

You can't really say what is the difference between LDAP and a database
because LDAP is a species of database. What you probably mean is "why use
LDAP when I have a relational database"?

The most basic difference is that a directory server is  a
specialized database designed to provide fast searches. While a relational
database is optimized for transactions (where a series of operations is
counted as 1, thus if one of the steps fails, the RDBMS can roll-back to
the state it was in before you started).

Directories also typically are hierarchical in nature (RBBMS is typically
flat, but you can implement a hierachy using tables and queries),
networkable, distributed and replicated. 

LDAP provides an open-standard to a directory service. 

Typically we use LDAP for email directories (all popular email clients
provide an LDAP client now) and authorization services (authentication and
access control). 

Yes you could use an RDBMS for these types of queries but there's not a
set standard, in particular over TCP/IP to connect to databases over the
network. There's language specific protocols (like Perl's DBI and Java's
JDBC) that hide this problem behind an API abstraction, but that's not a
replacment for a standard access protocol.

And we're also starting to see LDAP eat up from the bottom on roles
traditionally played by RDBMS in terms of general data management because
it's easier to setup an LDAP server (once you understand the basic
nomenclature) and you don't need a DBA to write your queries AND more
importantly all LDAP servers speak the same essential protocol, thus you
don't have to fuss with your database driver trying to connect it to the
Internet. Once you have an LDAP server up and running, it'a automatically
available over the 'net. And it's possible to connect to it from a variety
of mechanisms, including just about every possible programming language.

hope that helps,

Mark


On 10 Oct 2000, Darren/Torin/Who Ever... wrote:

> ritu rani jaiswal, in an immanent manifestation of deity, wrote:
> >I am new to ldap. Can you please let me know the advantages of ldap over
> >using a database.
> 
> Well, it really depends on what you want to do. LDAP can't do
> everything.  But if you are looking for information retrieval where
> there are a lot more reads than writes, try:
> <URL:http://www.openldap.org/faq/data/cache/378.html>.
> 
> Darren
> 

Re: problems with resolving groups (rescursive)

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

I'm all for this :). I think probably it's better to make it a subclass of
Net::LDAP::Util like Net::LDAP::Util::GroupSearch or perhaps a method of
util.

Mark

On Mon, 9 Oct 2000, Jurgen Botz wrote:

> =?iso-8859-1?Q?Bj=F6rn_Nilsson_=28QDT=29?= wrote:
> > I'm trying to modify the printMembers.pl script (which is included in the
> > Example subdir of the distribution of the LDAP module) to suit my needs. My
> > problem is that the script doesn't resolve the sublists at all, or that it
> > just resolve the first member of a sublist. What I want is to get each and
> > every members (person) attributes to insert them into another database,
> > grouped by the mailinglist in question.
> 
> I have written a bunch of code to resolve all the members of a group, list
> all the groups a person is a member of (memberships), and test for membership
> in a group.  This works for nested groups and "dynamic groups" (groups with
> memberURL attributes).
> 
> I packaged this up as a set of extensions to Net::LDAP by subclassing.  The
> idea is that my functions work like searches but may actually do multiple
> searches to do their work so they return a specialied Net::LDAP::Search
> object.  In other words, you can do this:
> 
>   $result = $ldap->get_members($groupdn, 'attrs' => [ 'cn', 'uid', 'title' ]);
> 
> And $result will contain all the entries of the members with the specifed
> attributes (or all attributes if not specified, just like search).
> 
> The code does some mildly interesting things to be efficient, such as
> aggregating searches for entries under the same base and going to some 
> lengths to avoid having to retrieve the same entry twice... this was
> also the motivation for returning the same kind of object as a search, so
> I don't have a function that retruns a list of the dn's of members and
> then I have to retrieve each member entry again just to get some more
> attributes for it.
> 
> I'm calling this kind of thing a "metasearch".  Ideally metasearches should
> work exactly like normal ones to the consumer, including doing them async,
> but I haven't actually implemented async yet.
> 
> I was going to handle async and improve some things before releasing this,
> but if there's sufficient interest I'll see if I can package it up now and
> pass it on.
> 
> I'm also in interested in what people (especially Graham) think about this
> approach to doing complex or semantic searches.  Is subclassing Net::LDAP
> and Net::LDAP::Search the right way to go?  What should I call this thing?
> (right now it's called Eazel::LDAP because I work at Eazel and I wrote it
> for a work-related project.)
> 
> - Jürgen Botz
> 
> 
> 
> 
> 
> 

Re: advantages of ldap over dbms

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

"Darren/Torin/Who Ever..." <to...@da...> wrote:
> ritu rani jaiswal, in an immanent manifestation of deity, wrote:
>> I am new to ldap. Can you please let me know the advantages of ldap over
>> using a database.
> 
> Well, it really depends on what you want to do. LDAP can't do
> everything.  But if you are looking for information retrieval where
> there are a lot more reads than writes, try:
> <URL:http://www.openldap.org/faq/data/cache/378.html>.
> 
> Darren

Our CSO gave this white paper ("Combining Directories and Relational
Databases in the Enterprise") to EMA a while ago:

http://www.messagingdirect.com/publications/IC-6055.html

Cheers,

Chris

Re: problems with resolving groups (rescursive)

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

On Tue, Oct 10, 2000 at 12:08:03PM +0100, John Berthels wrote:
> 
> > Yes. What I have been working on is a way to easily sub-class ::Search etc.
> > 
> > The problem is that they are created from within Net::LDAP itself, so
> > somehow we need to tell Net::LDAP to create different objects.
> 
> Taking a very quick peek, isn't this vectored through Net::LDAP::message
> already? Could the subclass override this method?
> 
> I guess it could get a little hairy, though.

Um, yes. I was writing that forgetting that I have already introduced
->message.

But it does not solve the problem.

What if a sub-class has more than one type of search, and wants to
use two different subclasses of ::Search to implement them.

I think adding a class option to the methods in Net::LDAP could help
solve this. In fact I think it is probably a better approach all around.

Those who simply want to subclass would do

sub search { shift->SUPER::search(@_,class => 'My::Search') }

instead of

sub message {
  my $ldap = shift;
  my $type = shift;
  $type = 'My::Search' if $class eq 'Net::LDAP::Search';
  $type->new($ldap, @_);
}


Which really does require a bit too much knowledge of the Net::LDAP internals.

Graham.

Re: problems with resolving groups (rescursive)

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

> Yes. What I have been working on is a way to easily sub-class ::Search etc.
> 
> The problem is that they are created from within Net::LDAP itself, so
> somehow we need to tell Net::LDAP to create different objects.

Taking a very quick peek, isn't this vectored through Net::LDAP::message
already? Could the subclass override this method?

I guess it could get a little hairy, though.

jb

Re: problems with resolving groups (rescursive)

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

On Mon, Oct 09, 2000 at 08:25:42AM -0700, Jurgen Botz wrote:
> I have written a bunch of code to resolve all the members of a group, list
> all the groups a person is a member of (memberships), and test for membership
> in a group.  This works for nested groups and "dynamic groups" (groups with
> memberURL attributes).
> 
> I packaged this up as a set of extensions to Net::LDAP by subclassing.  The
> idea is that my functions work like searches but may actually do multiple
> searches to do their work so they return a specialied Net::LDAP::Search
> object.  In other words, you can do this:
> 
>   $result = $ldap->get_members($groupdn, 'attrs' => [ 'cn', 'uid', 'title' ]);
> 
> And $result will contain all the entries of the members with the specifed
> attributes (or all attributes if not specified, just like search).
> 
> The code does some mildly interesting things to be efficient, such as
> aggregating searches for entries under the same base and going to some 
> lengths to avoid having to retrieve the same entry twice... this was
> also the motivation for returning the same kind of object as a search, so
> I don't have a function that retruns a list of the dn's of members and
> then I have to retrieve each member entry again just to get some more
> attributes for it.
> 
> I'm calling this kind of thing a "metasearch".  Ideally metasearches should
> work exactly like normal ones to the consumer, including doing them async,
> but I haven't actually implemented async yet.

There was a package a while ago called LDAPiranah which did a similar
thing. I have several things on my todo list to enable this kind of
extension whithout having to know any internals of Net::LDAP

> I was going to handle async and improve some things before releasing this,
> but if there's sufficient interest I'll see if I can package it up now and
> pass it on.

I normally find that if you write it for async first, then sync comes
very easy. The other way is not so easy.

> I'm also in interested in what people (especially Graham) think about this
> approach to doing complex or semantic searches.  Is subclassing Net::LDAP
> and Net::LDAP::Search the right way to go?  What should I call this thing?
> (right now it's called Eazel::LDAP because I work at Eazel and I wrote it
> for a work-related project.)

Yes. What I have been working on is a way to easily sub-class ::Search etc.

The problem is that they are created from within Net::LDAP itself, so
somehow we need to tell Net::LDAP to create different objects.

I was going down the route that you call a method on the $ldap object
which will return the class needed. But that is not scalable. MAybe
we should add a class method to search() which states the class
to use for the message.

The next taks is to create chain-able messages. So a message is never
done() until all it's sub-messages are done. This should then work
for these kind of searches in an async mode.

Graham.

Garnering info on Domino LDAP

[Pete <pl...@oz...>]

Hi everyone,

This isn't specifically a perl-ldap issue (yet?), but I'd like to ask the 
list what experience people have had with ldap on the Lotus 
Domino servers.  R5, we are currently running 5.0 and 5.03.

I ask this because we syncronise address books between different 
exchange/notes environments via ldap using a product called 
MDDM.

The problem we are currently experiencing is one where values of 
an attribute are changed, say location=ACT to location=NSW, 
doing this on the Domino server creates a new entry in the 
directory, even with the same DN.  So it appears to us that the 
server sees that the object has changed, rather than the DN not 
chaging and doing a modification of the entry.

One thing I now have to do is whip up a script to test, add, modify 
and delete on the domino server through ldap to check that it's not 
a problem with the directory product, or with the Domino server.

If anyone has anything to offer, I'm happy to hear from you, off list 
might be best, I'm not sure something like this is really seen as On 
Topic (my apologies to the list owner/moderator)... but I thought 
since I'm going to do further testing using perl-ldap, I'd like to know 
if there is any issues with Domino others are aware of.

Thanks,


Pete.