perl-ldap-dev

New faq file

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

There is a new perl-ldap FAQ file available.
The new FAQ has been committed to CVS.

You can view a WEB version at URL:
http://www.utdallas.edu/~charden/FAQ.html

New addition is the discussion about LDAP servers
and relational databases.  References are included for 
the 2 URLs that were mention in the discussions.

Regards,

Clif Harden              email:  c-h...@ti...

Re: DLL error

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

Shalini Nagpal <sn...@ec...> wrote:
> Hi,
> I'm new to LDAP and I'm trying to run a example perl-ldap script which 
> came with the examples of Perl Ldap and whenever I try to run 
> the "qsearch.pl" it gives me a "perl.dll" error.
> 
>  The error says "The dynamic link library perl.dll could not be found 
> in the specified path."
> 
> But if i try to run some other perl script it runs fine.
> 
> I have following packages installed on my Windows NT machine running 
> Active Perl(5.6)
> 1. perl-Convert-ASN1-0.07
> 2. perl-ldap-0.22
> 3. NETSCAPE DIRECTORY SERVER
> LDAP C SDK Release 4.1
> 4. perldap-win32-5.005_03 (the binary files)
> 
> Do you know if i have to install any other package ??? Any 
> help /commments would be helpful.
> 
> Regards
> -Shalini
> Technical Consultant
> Eclipse Networks

You've got *two* LDAP interfaces for perl installed. Perl-ldap (the subject
of this mailing list) comprises of the modules Net::LDAP (using
Convert::ASN1), ie your first and second packages. These do not require any
C libraries or DLLs unless you want to do SSL-related things.

The confusingly named perldap module is from Netscape, and uses external
DLLs.

You only need one of perl-ldap or perldap. They ought to be able to coexist
on the same perl installation, but having 2 packages to do the same thing
seems ... wasteful ...

Which are you actually testing? Since perl-ldap is pure perl, I would
suspect given your error message you're actually testing the perldap
module. At which point, you should seek help from the perldap module's
maintainers.

The perl-ldap module is however known to tickle some problems in perl 5.6,
so that might be your problem instead.

Cheers,

Chris

Re: chasing referrals

[David B. <D.B...@ma...>]

>I'm pretty much on the fence. All I'd like a framework (within or without
>Net::LDAP) where I can find more cool things (LDAP referral following,
>complex attribute value handling, multilingual attribute handling, Tk
>widgets for syntaxes, whatever) and perhaps help create them.
>
>You could argue that that framework should be CPAN rather than Net::LDAP
>and you could well be right.
>
>Where does everybody else stand?

I tend to be on the more liberal side most of the time.  I would like to
see a Net::LDAP that has as many advanced features available, and as many
"cool things" as people are willing to write into it, the more the
merrier...so long as they are not "code for codes sake".   If people are
going to use/write them, include them I say.  

That said however, there obviously needs to be methods in place for people
to "try out" new "bloat", before it's included into the standard product
and regretted later for one reason or another.

Why not have a Net::LDAP-dev or something that gets everything that people
are willing to throw at it, and include only those that are
"tried-and-true" into the real release? That should please both sides of
the fence...  I mean, look at the name of this list, it's a DEVELOPERS
list, be game, try everything, have a shot, live once, carpe-deim,
seize-the-day....

<at about this point in time you find the author standing on his desk
peering off into the distance, wondering whether his desk set will fly....>







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

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

Clif Harden wrote:

> If you are talking about a referral callback function that the
> user/application defines, and controls when it is taken, then possibly
> you could say that this proposal meets this standard.

OK. Thats fair enough.

> It is quite possible that applications will implement referral-chasing
> functionality in similar code, in this case put the code in a
> "package/module" external to the perl-ldap module.  Then the user can
> decide to use or not to use the code.

Yes. I think this is the nub of the discussion. No one seems opposed to
having code around which could make life easier, but not everyone agrees
where that code should live.

> The speed of the perl-ldap module has become an issue with some
> people. I remmeber several discussions on this list about it.  The
> more we bloat the code the worse this problem is going to become.
> 
> If you can do this with a autoloading function that is compiled only
> when first called, then bloat is less a problem.

It seems to me that there are two reasons why people might not want this
(and other) code in Net::LDAP (please feel free to chip in with your own
reaons if I've not caught them here):

1 - bloat (generally considered bad, although one person's bloat is
another person's feature, obviously)

2 - cleanliness of abstraction (is Net::LDAP an interface to the LDAP
protocol or an API intended to be of use to LDAP using applications?)


We can try to attack (1) with autoloading and extensions etc. (2) seems
more problematic.

I'm pretty much on the fence. All I'd like a framework (within or without
Net::LDAP) where I can find more cool things (LDAP referral following,
complex attribute value handling, multilingual attribute handling, Tk
widgets for syntaxes, whatever) and perhaps help create them.

You could argue that that framework should be CPAN rather than Net::LDAP
and you could well be right.

Where does everybody else stand?


jb

Re: new LDAP site

[David B. <D.B...@ma...>]

At 07:04 PM 10/19/00 -0500, Mark Wilcox wrote:
>checkout http://www.ldapguru.com/
>
>Mark

but if you want to check out the LDAP Browser\Editor (v2.8 or 2.7vlv)

downloading it from the above site doesn't work. Try:

http://www.iit.edu/~gawojar/ldap/

It's actually looks really good, going by my 60 second review of it.
(source code available to!... for non-comercial use)

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

new LDAP site

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

checkout http://www.ldapguru.com/

Mark

DLL error

[Shalini N. <sn...@ec...>]

Hi,
I'm new to LDAP and I'm trying to run a example perl-ldap script which 
came with the examples of Perl Ldap and whenever I try to run 
the "qsearch.pl" it gives me a "perl.dll" error.

 The error says "The dynamic link library perl.dll could not be found 
in the specified path."

But if i try to run some other perl script it runs fine.

I have following packages installed on my Windows NT machine running 
Active Perl(5.6)
1. perl-Convert-ASN1-0.07
2. perl-ldap-0.22
3. NETSCAPE DIRECTORY SERVER
LDAP C SDK Release 4.1
4. perldap-win32-5.005_03 (the binary files)

Do you know if i have to install any other package ??? Any 
help /commments would be helpful.

Regards
-Shalini
Technical Consultant
Eclipse Networks

 

Re: chasing referrals

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

On Wed, Oct 18, 2000 at 11:14:48AM -0500, Mark Wilcox wrote:
> I agree with Chris. Auto-chasing referrals at the API level can cause a
> lot of headaches and problems.

Doing it automatically, yes I agree. But forcing the user to do everything
is cumbersome. BUt the API can provide a framework to help things along.

Graham.

Re: chasing referrals

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

On Wed, Oct 18, 2000 at 11:17:42AM -0500, Clif Harden wrote:
> The speed of the perl-ldap module has become an issue with some people.
> I remmeber several discussions on this list about it.  The more we bloat
> the code the worse this problem is going to become.  

This is true.

> If you can do this with a autoloading function that is compiled only
> when first called, then bloat is less a problem.

But it may not take much. If we can devise a message chaining scheme, then
that may be all that is needed.

A callback on a search can already detect if it has referrals, if it does
then it dould need to create the connection and chain in the response.

Right now the `naughty' way is to

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

  if (my @refs = $mesg->referrals) {
    $ldap = ... connect bind ...
    $mesg = ... do the search ...
    push @{$mesg->{entries}}, $mesg->entries;
  }
}

Graham.

Re: chasing referrals

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

Instead of a seperate callback, perhaps the entry object in the current
callback could be a referral:

my callback {
   my ($msg,$obj) = @_;

   if (ref ($obj) eq 'Net::LDAP::Referral')
   {
       ....
   } 
   elsif (ref ($obj) eq 'Net::LDAP::Entry')
   {
      ...
   }
}

IMHO that's a better way to handle it. The application programmer has the
choice (and responsiblility) of what to handle, it doesn't bloat
the current API and everyone should be happy :).

Then you could populate the @entries and @referrals structures after
checking for the callback.

The optimal solution, is the way the Netscape Directory SDK for Java does
it. Any referrals found get thrown as an exception, thus you can choose to
deal with the exception or ignore it. But since we don't have real
exceptions in Perl, that's not possible :).

 Mark


On Wed, 18 Oct 2000, John Berthels wrote:

> 
> > > Referral following is something that needs to be addressed in the
> > > application (eg GUI) rather than down at the API level. IMHO of course.
> > 
> > I agree with Chris on this issue.  Chasing referrals should be 
> > left up to the application that initiated the ldap action.
> 
> I'm prepared to be convinced. Why do you (and Chris) think this? (Given
> that a callback allows the 'which referral to follow' and the 'how do I
> bind to this server' problems to be addressed).
> 
> My point of view is that all/many/most applications which implement
> referral-chasing functionality will (apart from the decisions we need to
> pull out into the callbacks above) do so with very similar code.
> 
> Pushing that similar code into the API makes the app writer's life easier
> and leads to one code-base to debug. The best reason I see not to do this
> would be bloat. If we can get a good extension mechanism going I see no
> reason (excepting someone's time to write it) not to do it.
> 
> regards,
> 
> jb
> 
> 

Re: chasing referrals

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

I agree with Chris. Auto-chasing referrals at the API level can cause a
lot of headaches and problems.

Mark

On Wed, 18 Oct 2000, Chris Ridd wrote:

> Graham Barr <gb...@po...> wrote:
> > On Tue, Oct 17, 2000 at 05:27:49PM -0700, Robbie Allen wrote:
> >> Can Net::LDAP automatically chase referrals?  Sample code?
> > 
> > Not yet. Currently you have to follow them yourself. You can
> > get them with
> > 
> >   $mesg = $ldap->search( ... );
> >   @referrals = $mesg->referrals;
> > 
> > Graham.
> 
> I'm not sure Net::LDAP should ever automatically follow referrals - not
> knowing what authentication to use is a pretty major problem. Deciding
> which one to follow if there are several for the same point is another
> (equally critical in some environments) problem.
> 
> Referral following is something that needs to be addressed in the
> application (eg GUI) rather than down at the API level. IMHO of course.
> 
> Cheers,
> 
> Chris
> 

Re: chasing referrals

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

> 
> 
> > > Referral following is something that needs to be addressed in the
> > > application (eg GUI) rather than down at the API level. IMHO of course.
> > 
> > I agree with Chris on this issue.  Chasing referrals should be 
> > left up to the application that initiated the ldap action.
> 
> I'm prepared to be convinced. Why do you (and Chris) think this? (Given
> that a callback allows the 'which referral to follow' and the 'how do I
> bind to this server' problems to be addressed).


From everything I have read it is the industry standard to let the
application or client make the decision on what to do with the 
referral.  Is the right or wrong way to view the situation, I do not 
know. 

If you are talking about a referral callback function that the 
user/application defines, and controls when it is taken, then 
possibly you could say that this proposal meets this standard.  


> 
> My point of view is that all/many/most applications which implement
> referral-chasing functionality will (apart from the decisions we need to
> pull out into the callbacks above) do so with very similar code.
> 


It is quite possible that applications will implement 
referral-chasing functionality in similar code, in this case put 
the code in a "package/module" external to the perl-ldap module.  
Then the user can decide to use or not to use the code.

> Pushing that similar code into the API makes the app writer's life easier
> and leads to one code-base to debug. The best reason I see not to do this
> would be bloat. If we can get a good extension mechanism going I see no
> reason (excepting someone's time to write it) not to do it.
> 


The speed of the perl-ldap module has become an issue with some people.
I remmeber several discussions on this list about it.  The more we bloat
the code the worse this problem is going to become.  

If you can do this with a autoloading function that is compiled only
when first called, then bloat is less a problem.


> regards,
> 
> jb
> 
> 


John I am not saying that your idea is bad, I am just saying I do not
think it should be in the perl-ldap module.  

It might be a good starting point for a perl-ldap utilities module.

Regards,

Clif Harden           INTERNET:  c-h...@ti...

Re: chasing referrals

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

At 08:37 AM 10/18/00 +0100, Chris Ridd wrote:
>Graham Barr <gb...@po...> wrote:
>> On Tue, Oct 17, 2000 at 05:27:49PM -0700, Robbie Allen wrote:
>>> Can Net::LDAP automatically chase referrals?  Sample code?
>> 
>> Not yet. Currently you have to follow them yourself. You can
>> get them with
>> 
>>   $mesg = $ldap->search( ... );
>>   @referrals = $mesg->referrals;
>> 
>> Graham.
>
>I'm not sure Net::LDAP should ever automatically follow referrals - not
>knowing what authentication to use is a pretty major problem. Deciding
>which one to follow if there are several for the same point is another
>(equally critical in some environments) problem.
>
>Referral following is something that needs to be addressed in the
>application (eg GUI) rather than down at the API level. IMHO of course.

I concur that the low-level API should have not chase referrals.
The abstraction at the low-level should be a "protocol" session.

This, of course, doesn't mean you cannot have a higher level API
which provides different abstractions.  For example, one could
create a "Directory" abstraction which managed multiple protocol
sessions.

Kurt

Re: [Fwd] Net::LDAP

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

Have you tried binding as the directory manager (actually I think this is
the cn=manager in openLDAP) to make sure that it's not an ACL problem and
perhaps you're not finding the entry because you don't have permissions to
search it as anonymous.

Mark

On Wed, 18 Oct 2000, Graham Barr wrote:

> ----- Forwarded message from Matt Chudleigh <ma...@cr...> -----
> 
> From: "Matt Chudleigh" <ma...@cr...>
> To: <gb...@po...>
> Subject: Net::LDAP
> Date: Tue, 17 Oct 2000 17:27:08 -0600
> X-Mailer: Microsoft Outlook Express 5.50.4133.2400
> 
> Hello,
> 
> I am a technical support consultant for Critical Mass productions up here in Calgary, Canada. Over the recent weeks, I have been trying to setup a web interface to our OpenLDAP server to allow us to easily add/change/view the database. I am using your Net::LDAP module with some success in searching and deleting entries from the LDAP database. However, I am compleatly stumped trying to get Net::LDAP to add entries to the database. Our server name is called europa, and we have setup the OpenLDAP server to use dc=europa as a search base. When I use the following code, it seems to add just fine, however, when I search for the entry using the command line: ldapsearch -L -b dc=europa cn=Te*
> the entry is not returned. If I run this code first, then I try to add the same entry from the command line (Using ldapadd and a file) is says that the entry already exists. If you can provide any assistance whatsoever, it would be very much appreciated. If you can get this to work, I would owe my sanity to you as well.
> 
> Thanks in advance,
> 
> Matt Chudleigh
> Technical Support Consultant
> Critical Mass Productions
> ma...@cr...
> 
>  I am using the following code to attempt to add entries..
> 
> #!/usr/bin/perl
> 
> use Net::LDAP;
> 
> my $host = 'europa.criticalmass.com';
> my $name = 'cn=Manager, dc=criticalmass';
> my $pass = 'secret';
> my $vers = 2;
> my $DN = 'cn=test2 test2, dc=europa';
> 
> $ldap = Net::LDAP->new($host) or die $@;
> 
> my %bindargs;
> $bindargs{dn} = $name;
> $bindargs{password} = $pass;
> $bindargs{version} = $vers;
> 
> $ldap->bind(%bindargs) or die $@;
> 
> my $addname = 'test2 test2';
> my $addlast = 'test2';
> my $addclas = 'person';
> my $addmail = 'te...@te...';
> my $addhome = '222-2222';
> my $addwork = '2222';
> my $addloca = 'calgary';
> 
> my %addthing;
> $addthing{dn} = $DN;
> $addthing{cn} = $addname;
> $addthing{objectclass} = $addclas;
> $addthing{mail} = $addmail;
> $addthing{sn} = $addlast;
> $addthing{homephone} = $addhome;
> $addthing{phonenumber} = $addwork;
> $addthing{location} = $addloca;
> 
> $ldap->add (%addthing); 
>              
> $ldap->unbind() or die $@;
> 
> 
> 
> 
> ----- End forwarded message -----
> 

Re: chasing referrals

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

> > Referral following is something that needs to be addressed in the
> > application (eg GUI) rather than down at the API level. IMHO of course.
> 
> I agree with Chris on this issue.  Chasing referrals should be 
> left up to the application that initiated the ldap action.

I'm prepared to be convinced. Why do you (and Chris) think this? (Given
that a callback allows the 'which referral to follow' and the 'how do I
bind to this server' problems to be addressed).

My point of view is that all/many/most applications which implement
referral-chasing functionality will (apart from the decisions we need to
pull out into the callbacks above) do so with very similar code.

Pushing that similar code into the API makes the app writer's life easier
and leads to one code-base to debug. The best reason I see not to do this
would be bloat. If we can get a good extension mechanism going I see no
reason (excepting someone's time to write it) not to do it.

regards,

jb

Re: chasing referrals

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

> 
> Graham Barr <gb...@po...> wrote:
> > On Tue, Oct 17, 2000 at 05:27:49PM -0700, Robbie Allen wrote:
> >> Can Net::LDAP automatically chase referrals?  Sample code?
> > 
> > Not yet. Currently you have to follow them yourself. You can
> > get them with
> > 
> >   $mesg = $ldap->search( ... );
> >   @referrals = $mesg->referrals;
> > 
> > Graham.
> 
> I'm not sure Net::LDAP should ever automatically follow referrals - not
> knowing what authentication to use is a pretty major problem. Deciding
> which one to follow if there are several for the same point is another
> (equally critical in some environments) problem.
> 
> Referral following is something that needs to be addressed in the
> application (eg GUI) rather than down at the API level. IMHO of course.
> 
> Cheers,
> 
> Chris
> 

I agree with Chris on this issue.  Chasing referrals should be 
left up to the application that initiated the ldap action.

Regards,

Clif Harden           INTERNET:  c-h...@ti...

Re: chasing referrals

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

On Wed, Oct 18, 2000 at 10:12:04AM +0100, John Berthels wrote:
> As regular readers of this list are probably aware, I favour putting code
> which may be of use to many/some applications into this (or another) API
> (preferably in a way which doesn't incur bloat for the common case if
> possible). 
> 
> This probably brings us back to the 'what is the best way to extend
> Net::LDAP' issue. Should we implement this as a subclass of Net::LDAP to
> avoid bloating the core API?

The problem with this is that you either create many sub-classes, which means any
user needs to create a sub-class of those if they want to use many, or
you end up with one big subclass, which will be bloated.

My suggestion I posted a few days back was something like

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

which looked for the named extension and loaded it. this would make the
method my_extension avaliable on all Net::LDAP objects.

> Could/should this same mechanism be used to chase continuation references?

Not sure, but maybe.

Graham.

Re: chasing referrals

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

> I'm not sure Net::LDAP should ever automatically follow referrals -
> not knowing what authentication to use is a pretty major problem.

We could select chase/not chase with an option to the constructor.

I would suggest handling the different auth needs by permitting a callback
to be passed in. If the callback is absent then the same credentials are
re-presented. (Hmmm...this makes sense to me for usability reasons but it
feels pretty unpleasant from the security standpoint...maybe "represent
the same credentials" shouldn't be a default if we are chasing referrals).

> Deciding which one to follow if there are several for the same point
> is another (equally critical in some environments) problem.

Hmm. How about:

my $l = Net::LDAP->new( ..., referrals => &ref_callback );

sub ref_callback {
	my @ldap_urls = @_;
	...decide which order I want to contact these in
	...and how I should authenticate against them
	return \%hash_mapping_url_to_auth_info;
}

If you specify the string 'default' instead of a subroutine ref then you
get the default referral handler, which keeps the order returned by the
server and re-uses the credentials (I have qualms about this...see above).

If you don't specify the 'referrals' option to the constructor then you
get the current behaviour.

> Referral following is something that needs to be addressed in the
> application (eg GUI) rather than down at the API level. IMHO of course.

As regular readers of this list are probably aware, I favour putting code
which may be of use to many/some applications into this (or another) API
(preferably in a way which doesn't incur bloat for the common case if
possible). 

This probably brings us back to the 'what is the best way to extend
Net::LDAP' issue. Should we implement this as a subclass of Net::LDAP to
avoid bloating the core API?

Could/should this same mechanism be used to chase continuation references?


jb

Re: [Fwd] Net::LDAP

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

On Wed, Oct 18, 2000 at 08:15:00AM +0100, Voglmaier, Reinhard Erich wrote:
> Matt,
> 
> it seems to me that objectclasses need to be defined as:
> 
> @objectclasses = ['top','person']

>                                  'objectclass' => @objectclasses,

But you really mean

>                                  'objectclass' => \@objectclasses,

Graham.

Re: chasing referrals

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

On Wed, Oct 18, 2000 at 08:37:53AM +0100, Chris Ridd wrote:
> Graham Barr <gb...@po...> wrote:
> > On Tue, Oct 17, 2000 at 05:27:49PM -0700, Robbie Allen wrote:
> >> Can Net::LDAP automatically chase referrals?  Sample code?
> > 
> > Not yet. Currently you have to follow them yourself. You can
> > get them with
> > 
> >   $mesg = $ldap->search( ... );
> >   @referrals = $mesg->referrals;
> > 
> > Graham.
> 
> I'm not sure Net::LDAP should ever automatically follow referrals - not
> knowing what authentication to use is a pretty major problem. Deciding
> which one to follow if there are several for the same point is another
> (equally critical in some environments) problem.
> 
> Referral following is something that needs to be addressed in the
> application (eg GUI) rather than down at the API level. IMHO of course.

While I agree with your points, the API could allow the application to
register callbacks for these situations. For example to connect there
could be a callback which is passed the referral, this would return a
valid ldap object

Graham.

Re: chasing referrals

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

Graham Barr <gb...@po...> wrote:
> On Tue, Oct 17, 2000 at 05:27:49PM -0700, Robbie Allen wrote:
>> Can Net::LDAP automatically chase referrals?  Sample code?
> 
> Not yet. Currently you have to follow them yourself. You can
> get them with
> 
>   $mesg = $ldap->search( ... );
>   @referrals = $mesg->referrals;
> 
> Graham.

I'm not sure Net::LDAP should ever automatically follow referrals - not
knowing what authentication to use is a pretty major problem. Deciding
which one to follow if there are several for the same point is another
(equally critical in some environments) problem.

Referral following is something that needs to be addressed in the
application (eg GUI) rather than down at the API level. IMHO of course.

Cheers,

Chris

RE: [Fwd] Net::LDAP

[Voglmaier, R. E. <rv...@gl...>]

Matt,

it seems to me that objectclasses need to be defined as:

@objectclasses = ['top','person']

I rather use this syntax :

$result = $ldap->add (
                       dn => $DN ,
                       attr => [ 'sn' => $SN,
                                 'cn' => $CN,
                                 'objectclass' => @objectclasses,
                                 'userpassword' => $UserPw,
                                 'uid' =>$UserId,
]
                      );
# Everything's OK ?
$result->code && die "Failed to add entry \n, Reason: $result->error" ;

This gives You the possibility to see if the add method failed.

hope this helps.
cheers


				Reinhard 



> -----Original Message-----
> From:	Graham Barr [SMTP:gb...@po...]
> Sent:	mercoledì 18 ottobre 2000 07:19
> To:	LDAP Mailing List
> Cc:	Matt Chudleigh
> Subject:	[Fwd] Net::LDAP
> 
> ----- Forwarded message from Matt Chudleigh <ma...@cr...> -----
> 
> From: "Matt Chudleigh" <ma...@cr...>
> To: <gb...@po...>
> Subject: Net::LDAP
> Date: Tue, 17 Oct 2000 17:27:08 -0600
> X-Mailer: Microsoft Outlook Express 5.50.4133.2400
> 
> Hello,
> 
> I am a technical support consultant for Critical Mass productions up here
> in Calgary, Canada. Over the recent weeks, I have been trying to setup a
> web interface to our OpenLDAP server to allow us to easily add/change/view
> the database. I am using your Net::LDAP module with some success in
> searching and deleting entries from the LDAP database. However, I am
> compleatly stumped trying to get Net::LDAP to add entries to the database.
> Our server name is called europa, and we have setup the OpenLDAP server to
> use dc=europa as a search base. When I use the following code, it seems to
> add just fine, however, when I search for the entry using the command
> line: ldapsearch -L -b dc=europa cn=Te*
> the entry is not returned. If I run this code first, then I try to add the
> same entry from the command line (Using ldapadd and a file) is says that
> the entry already exists. If you can provide any assistance whatsoever, it
> would be very much appreciated. If you can get this to work, I would owe
> my sanity to you as well.
> 
> Thanks in advance,
> 
> Matt Chudleigh
> Technical Support Consultant
> Critical Mass Productions
> ma...@cr...
> 
>  I am using the following code to attempt to add entries..
> 
> #!/usr/bin/perl
> 
> use Net::LDAP;
> 
> my $host = 'europa.criticalmass.com';
> my $name = 'cn=Manager, dc=criticalmass';
> my $pass = 'secret';
> my $vers = 2;
> my $DN = 'cn=test2 test2, dc=europa';
> 
> $ldap = Net::LDAP->new($host) or die $@;
> 
> my %bindargs;
> $bindargs{dn} = $name;
> $bindargs{password} = $pass;
> $bindargs{version} = $vers;
> 
> $ldap->bind(%bindargs) or die $@;
> 
> my $addname = 'test2 test2';
> my $addlast = 'test2';
> my $addclas = 'person';
> my $addmail = 'te...@te...';
> my $addhome = '222-2222';
> my $addwork = '2222';
> my $addloca = 'calgary';
> 
> my %addthing;
> $addthing{dn} = $DN;
> $addthing{cn} = $addname;
> $addthing{objectclass} = $addclas;
> $addthing{mail} = $addmail;
> $addthing{sn} = $addlast;
> $addthing{homephone} = $addhome;
> $addthing{phonenumber} = $addwork;
> $addthing{location} = $addloca;
> 
> $ldap->add (%addthing); 
>              
> $ldap->unbind() or die $@;
> 
> 
> 
> 
> ----- End forwarded message -----

Re: chasing referrals

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

On Tue, Oct 17, 2000 at 05:27:49PM -0700, Robbie Allen wrote:
> Can Net::LDAP automatically chase referrals?  Sample code?

Not yet. Currently you have to follow them yourself. You can
get them with

  $mesg = $ldap->search( ... );
  @referrals = $mesg->referrals;

Graham.

[Fwd] Net::LDAP

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

----- Forwarded message from Matt Chudleigh <ma...@cr...> -----

From: "Matt Chudleigh" <ma...@cr...>
To: <gb...@po...>
Subject: Net::LDAP
Date: Tue, 17 Oct 2000 17:27:08 -0600
X-Mailer: Microsoft Outlook Express 5.50.4133.2400

Hello,

I am a technical support consultant for Critical Mass productions up here in Calgary, Canada. Over the recent weeks, I have been trying to setup a web interface to our OpenLDAP server to allow us to easily add/change/view the database. I am using your Net::LDAP module with some success in searching and deleting entries from the LDAP database. However, I am compleatly stumped trying to get Net::LDAP to add entries to the database. Our server name is called europa, and we have setup the OpenLDAP server to use dc=europa as a search base. When I use the following code, it seems to add just fine, however, when I search for the entry using the command line: ldapsearch -L -b dc=europa cn=Te*
the entry is not returned. If I run this code first, then I try to add the same entry from the command line (Using ldapadd and a file) is says that the entry already exists. If you can provide any assistance whatsoever, it would be very much appreciated. If you can get this to work, I would owe my sanity to you as well.

Thanks in advance,

Matt Chudleigh
Technical Support Consultant
Critical Mass Productions
ma...@cr...

 I am using the following code to attempt to add entries..

#!/usr/bin/perl

use Net::LDAP;

my $host = 'europa.criticalmass.com';
my $name = 'cn=Manager, dc=criticalmass';
my $pass = 'secret';
my $vers = 2;
my $DN = 'cn=test2 test2, dc=europa';

$ldap = Net::LDAP->new($host) or die $@;

my %bindargs;
$bindargs{dn} = $name;
$bindargs{password} = $pass;
$bindargs{version} = $vers;

$ldap->bind(%bindargs) or die $@;

my $addname = 'test2 test2';
my $addlast = 'test2';
my $addclas = 'person';
my $addmail = 'te...@te...';
my $addhome = '222-2222';
my $addwork = '2222';
my $addloca = 'calgary';

my %addthing;
$addthing{dn} = $DN;
$addthing{cn} = $addname;
$addthing{objectclass} = $addclas;
$addthing{mail} = $addmail;
$addthing{sn} = $addlast;
$addthing{homephone} = $addhome;
$addthing{phonenumber} = $addwork;
$addthing{location} = $addloca;

$ldap->add (%addthing); 
             
$ldap->unbind() or die $@;




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

chasing referrals

[Robbie A. <ra...@ci...>]

Can Net::LDAP automatically chase referrals?  Sample code?

Thanks,
Robbie Allen