perl-ldap-dev

Re: sorted method of LDAP::search

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

First off be warned that ->sorted does a simple byte-wise compare.

Right now it can only sort on a single attribute too. So to
order on sn

 $mesg = $ldap->search(...);
 @entries = $mesg->sorted('sn');

Of course you need to handle errors by checking $mesg->code too.

Graham.

On Wed, Feb 14, 2001 at 04:12:52PM -0700, Tina Sweet wrote:
> Does anyone have an example of how to use the sorted method of 
> LDAP::search?? I have all the entries returned form the search , now I want 
> to sort all entries by sn and givenName.  I have tried everything and 
> cannot get close.
> Thanks
> ************************************************
> * Tina M. Sweet NIS-8					
> * Nonproliferation and International Security	
> * Nonproliferation & International Technology
> * Los Alamos National Laboratory 		
> * Phone:  (505)665-9581		
> * Fax:	     (505)665-2274			
> * email:    ts...@la...			
> ************************************************
> 
> 
> 

sorted method of LDAP::search

[Tina S. <ts...@la...>]

Does anyone have an example of how to use the sorted method of 
LDAP::search?? I have all the entries returned form the search , now I want 
to sort all entries by sn and givenName.  I have tried everything and 
cannot get close.
Thanks
************************************************
* Tina M. Sweet NIS-8					
* Nonproliferation and International Security	
* Nonproliferation & International Technology
* Los Alamos National Laboratory 		
* Phone:  (505)665-9581		
* Fax:	     (505)665-2274			
* email:    ts...@la...			
************************************************

Re: Getting * from a directory.

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

Pete <pl...@oz...> wrote:
> Hi everyone,
> 
> Every now and then I have a need to delete all entries from a 
> directory.  The problem is though that the directory server is set to 
> a maximum number of entries to return.  Setting the server to a 
> larger number isn't the answer.
> 
> What I need to do is search on sn=*, which returns an error, 
> something like too many entries to return, I need this to do this to 
> get the DN value to delete all the entries  
> 
> Reading through the doco it doesn't appear there is an inbuilt 
> capability to do this.  I'm sure this could be another exercise in 
> programing to do the task, but not re-inventing the wheel is prefered 
> lately.
> 
> Thanks in advance,
> 
> 
> Pete.

When you get an error of LDAP_SIZELIMIT_EXCEEDED, you *also* get back some
of the entries that the directory could return. This probably isn't obvious
from the documentation. (The LDAP_TIMELIMIT_EXCEEDED error has the same
feature, which is similarly not obvious from the documentation.)

So what you could try is a loop which repeatedly did a search of (sn=*) (or
whatever matched your entries) and removed any it did found. Terminate the
loop when 0 entries are returned.

For efficiency in your searches, don't instruct the server to return all
user attributes (which is the default), ask it for a single attribute
instead. This will make the results come back just that little bit quicker,
as less data needs to be transferred across the network.

Cheers,

Chris

Re: Getting * from a directory.

[<ne...@na...>]

On the Netscape Directory Server the special account "cn=Directory Manager"
dosen't have any limitation so if you have access to that account and your
using NS you can do that.  Another option is creating a vlv index.

SteveN





"Pete" <pl...@oz...>@lists.sourceforge.net on 02/13/2001 05:03:24
AM

From: "Pete" <pl...@oz...>@lists.sourceforge.net on 02/13/2001
      05:03 AM

Please respond to pl...@oz...

Sent by:  per...@li...

To:   per...@li...
cc:
Subject:  Getting * from a directory.


Hi everyone,

Every now and then I have a need to delete all entries from a
directory.  The problem is though that the directory server is set to
a maximum number of entries to return.  Setting the server to a
larger number isn't the answer.

What I need to do is search on sn=*, which returns an error,
something like too many entries to return, I need this to do this to
get the DN value to delete all the entries

Reading through the doco it doesn't appear there is an inbuilt
capability to do this.  I'm sure this could be another exercise in
programing to do the task, but not re-inventing the wheel is prefered
lately.

Thanks in advance,


Pete.

Getting * from a directory.

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

Hi everyone,

Every now and then I have a need to delete all entries from a 
directory.  The problem is though that the directory server is set to 
a maximum number of entries to return.  Setting the server to a 
larger number isn't the answer.

What I need to do is search on sn=*, which returns an error, 
something like too many entries to return, I need this to do this to 
get the DN value to delete all the entries  

Reading through the doco it doesn't appear there is an inbuilt 
capability to do this.  I'm sure this could be another exercise in 
programing to do the task, but not re-inventing the wheel is prefered 
lately.

Thanks in advance,


Pete.

Re: Filter problems

[<ne...@na...>]

 This being the case I would highly recommend (if possible) change some of
the examples in the
documentation that use bigfoot since I'm sure other issues like this will continue to crop up.

eg in the Net::LDAP::Conn

     $ldap = Net::LDAP->new('ldap.bigfoot.com') or die "$@";

Unfortunately I don't have any suggestions what to change it to...

SteveN





Chris Ridd <chr...@me...>@lists.sourceforge.net on
02/13/2001 06:43:51 AM

From: Chris Ridd <chr...@me...>@lists.sourceforge.net on
      02/13/2001 06:43 AM

Sent by:  per...@li...

To:   Guruprasad S <sgu...@no...>
      perl-ldap-dev <per...@li...>
cc:
Subject:  Re: Filter problems


Guruprasad S <sgu...@no...> wrote:
> Hi,
>
> I am having problems using the filter.
>
> $filter = Net::LDAP::Filter->new( '(cn=Babs Jensen)');
>
> The above will return 2 entries from ldap.bigfoot.com.  If I add
> o=bigfoot.com as shown below, even then I get 2 entries
>
> $filter = Net::LDAP::Filter->new( '& (cn=Babs Jensen) (o=bigfoot.com)');
>
> Can any of you please help me.  Also I am unable to filter on mail field.
>
> Thanks
> Guru

I think you've really got problems with the server.

Ldap.bigfoot.com is not a "real" and complete LDAP server, it is just a
simple and very restricted LDAP front-end onto some kind of database. I
wouldn't be surprised if it ignored lots of operations and parts of
filters.

Cheers,

Chris

Re: Filter problems

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

Guruprasad S <sgu...@no...> wrote:
> Hi,
> 
> I am having problems using the filter.
> 
> $filter = Net::LDAP::Filter->new( '(cn=Babs Jensen)');
> 
> The above will return 2 entries from ldap.bigfoot.com.  If I add
> o=bigfoot.com as shown below, even then I get 2 entries
> 
> $filter = Net::LDAP::Filter->new( '& (cn=Babs Jensen) (o=bigfoot.com)');
> 
> Can any of you please help me.  Also I am unable to filter on mail field.
> 
> Thanks
> Guru

I think you've really got problems with the server.

Ldap.bigfoot.com is not a "real" and complete LDAP server, it is just a
simple and very restricted LDAP front-end onto some kind of database. I
wouldn't be surprised if it ignored lots of operations and parts of filters.

Cheers,

Chris

Re: DN comparision not using compare function

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

It is in CVS now. Please test and supply some additions for t/01canon_dn.t

Graham.

On Mon, Feb 12, 2001 at 11:22:28PM -0600, Clif Harden wrote:
> 
> 
> Graham Barr wrote:
> 
> > On Mon, Feb 12, 2001 at 11:15:47AM -0500, ne...@na... wrote:
> > >
> > > Thanks Chris.  I think that Mozilla::LDAP might have a canonicalization
> > > function that should work and be a little bit more complete than my hack :
> > > -P  I haven't tried it yet so I may be wrong.
> >
> > I am sure I have posted this before, and I am considering adding it to
> > Net::LDAP::Util
> 
> I would like to see them added to the next release.
> 
> Clif
> 
> 
> 
> >
> >
> > Graham.
> >
> >   -
> 
> 

Filter problems

[Guruprasad S <sgu...@no...>]

Hi,

I am having problems using the filter.

$filter =3D Net::LDAP::Filter->new( '(cn=3DBabs Jensen)');

The above will return 2 entries from ldap.bigfoot.com.  If I add o=3Dbigfoo=
t.com as shown below, even then I get 2 entries

$filter =3D Net::LDAP::Filter->new( '& (cn=3DBabs Jensen) (o=3Dbigfoot.com)=
');

Can any of you please help me.  Also I am unable to filter on mail field.

Thanks
Guru

Re: DN comparision not using compare function

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

Some example DNs to test it out would be great. What I would like
is multiple DNs that have been encoded two or more different ways.

Graham.

On Mon, Feb 12, 2001 at 11:43:39AM -0500, ne...@na... wrote:
> 
> That would be awesome!  Let me know if I can be of any help.
> 
> SteveN
> 
> 
> 
> 
> 
> Graham Barr <gb...@po...> on 02/12/2001 11:38:40 AM
> 
> From: Graham Barr <gb...@po...> on 02/12/2001 11:38 AM
> To:   ne...@na...
> cc:   Chris Ridd <chr...@me...>
>       per...@li...
> Subject:  Re: DN comparision not using compare function
> 
> 
> On Mon, Feb 12, 2001 at 11:15:47AM -0500, ne...@na... wrote:
> >
> > Thanks Chris.  I think that Mozilla::LDAP might have a canonicalization
> > function that should work and be a little bit more complete than my hack
> :
> > -P  I haven't tried it yet so I may be wrong.
> 
> I am sure I have posted this before, and I am considering adding it to
> Net::LDAP::Util
> 
> Graham.
> 
> 
> (See attached file: dn)
> 
> 
> 
> 

Re: DN comparision not using compare function

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

On Mon, Feb 12, 2001 at 10:11:25PM -0800, Kurt D. Zeilenga wrote:
> At 04:38 PM 2/12/01 +0000, Graham Barr wrote:
> >On Mon, Feb 12, 2001 at 11:15:47AM -0500, ne...@na... wrote:
> >> 
> >> Thanks Chris.  I think that Mozilla::LDAP might have a canonicalization
> >> function that should work and be a little bit more complete than my hack :
> >> -P  I haven't tried it yet so I may be wrong.
> >
> >I am sure I have posted this before, and I am considering adding it to 
> >Net::LDAP::Util
> 
> I note your code treats:
>    1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB
> as
>    1.3.6.1.4.1.1466.0=\04\02Hi,O=Test,C=GB
> 
> These are not equivalent.  That is, the RDN
> 1.3.6.1.4.1.1466.0=#04024869 can be represented
> as 1.3.6.1.4.1.1466.0=Hi.  This is because later
> RDN value is the BER encoding of the value, the
> former is the hex escaped encoding of the value.
> 
> I suggest you don't to muck with BER encoded values.

If we don't then we cannot compare two DNs where one is BER encoded
and the other is not.

Hm, maybe we just list that as a limitation of the code.

Graham.

problems with dependancies for LDAPS

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

Has anyone had any problems installing the modules:

Net_SSLeay and IO::Socket::SSL ? (both required for Net::LDAPS)

I'm getting a bundle of failed tests from the IO:Socket:SSL module when I
'make test' ? 

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

Re: DN comparision not using compare function

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

At 04:38 PM 2/12/01 +0000, Graham Barr wrote:
>On Mon, Feb 12, 2001 at 11:15:47AM -0500, ne...@na... wrote:
>> 
>> Thanks Chris.  I think that Mozilla::LDAP might have a canonicalization
>> function that should work and be a little bit more complete than my hack :
>> -P  I haven't tried it yet so I may be wrong.
>
>I am sure I have posted this before, and I am considering adding it to 
>Net::LDAP::Util

I note your code treats:
   1.3.6.1.4.1.1466.0=#04024869,O=Test,C=GB
as
   1.3.6.1.4.1.1466.0=\04\02Hi,O=Test,C=GB

These are not equivalent.  That is, the RDN
1.3.6.1.4.1.1466.0=#04024869 can be represented
as 1.3.6.1.4.1.1466.0=Hi.  This is because later
RDN value is the BER encoding of the value, the
former is the hex escaped encoding of the value.

I suggest you don't to muck with BER encoded values.

Re: DN comparision not using compare function

[Clif H. <ch...@po...>]

Graham Barr wrote:

> On Mon, Feb 12, 2001 at 11:15:47AM -0500, ne...@na... wrote:
> >
> > Thanks Chris.  I think that Mozilla::LDAP might have a canonicalization
> > function that should work and be a little bit more complete than my hack :
> > -P  I haven't tried it yet so I may be wrong.
>
> I am sure I have posted this before, and I am considering adding it to
> Net::LDAP::Util

I would like to see them added to the next release.

Clif



>
>
> Graham.
>
>   -

Re: DN comparision not using compare function

[<ne...@na...>]

That would be awesome!  Let me know if I can be of any help.

SteveN





Graham Barr <gb...@po...> on 02/12/2001 11:38:40 AM

From: Graham Barr <gb...@po...> on 02/12/2001 11:38 AM
To:   ne...@na...
cc:   Chris Ridd <chr...@me...>
      per...@li...
Subject:  Re: DN comparision not using compare function


On Mon, Feb 12, 2001 at 11:15:47AM -0500, ne...@na... wrote:
>
> Thanks Chris.  I think that Mozilla::LDAP might have a canonicalization
> function that should work and be a little bit more complete than my hack
:
> -P  I haven't tried it yet so I may be wrong.

I am sure I have posted this before, and I am considering adding it to
Net::LDAP::Util

Graham.


(See attached file: dn)

Re: DN comparision not using compare function

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

On Mon, Feb 12, 2001 at 11:15:47AM -0500, ne...@na... wrote:
> 
> Thanks Chris.  I think that Mozilla::LDAP might have a canonicalization
> function that should work and be a little bit more complete than my hack :
> -P  I haven't tried it yet so I may be wrong.

I am sure I have posted this before, and I am considering adding it to 
Net::LDAP::Util

Graham.

Re: DN comparision not using compare function

[<ne...@na...>]

Thanks Chris.  I think that Mozilla::LDAP might have a canonicalization
function that should work and be a little bit more complete than my hack :
-P  I haven't tried it yet so I may be wrong.

I think your suggestion of  a compare on the server is probably the correct
way to do things to avoid all kinds of possible nastiness.

     Cheers,

          SteveN







Chris Ridd <chr...@me...>@lists.sourceforge.net on
02/12/2001 04:05:12 AM

From: Chris Ridd <chr...@me...>@lists.sourceforge.net on
      02/12/2001 04:05 AM

Sent by:  per...@li...

To:   Steve Neruda <ne...@na...>
      per...@li...
cc:
Subject:  Re: DN comparision not using compare function


Steve Neruda <ne...@na...> wrote:
> I have written a script that makes sure that the indexes on the slave
> servers are consistent with the master server.  I am having problems
> finding a good way to compare DNs correctly. I do a search on each
> server for to get all the indexes, then I need to compare the DN's to
> see if the indexes exist on all the servers.
>
> It appears that Net::LDAP does not normalize the DN before hashing it
> into a structure.  Therefore if I do a comparison of the DN's and one
> happens to be capitalized (or spaces differently, or ??) then comparing
> DNs will fail.

That looks about right. Net::LDAP simply uses the bytes that were sent by
the server as the DN without trying to interpret them too much.

I'm not sure it is a Net::LDAP bug, rather just the "way it works".

> I want to do a single search on each server rather than do a ->compare
> on each attribute.  Is there a better method for comparing DNs between
> two servers to find out if they match?

I can't think of one. Your canonicalization (lower-casing the entire DN)
will of course not work for many cases, but I guess you're aware of that.
It might be good enough to solve your immediate problem.

To be complete I think Unicode says that you should convert to upper-case,
and you need to deal with the different ways to encode accented characters,
the different ordering of multi-AVA RDNs (cn=Foo Bar+uid=baz,...), the
different ways of encoding the attribute types and values, etc etc etc.
Pretty hard to do it all correctly!

And that's assuming you're using LDAPv3 to access the directory. For LDAPv2
there are more problems. :-)

How painful would it be to use compare operations against one of the
servers? It strikes me that would be a *lot* easier, assuming the server
did these things correctly.

Cheers,

Chris

IO::Socket::INET error when initializing

[<alw...@pl...>]

Hi,

I have a strange problem. I can run my Perl script (with routine
to query a LDAP directory) without any problems on command line.
But when I use it in a web environment I face the following CGI
error:

IO::Socket::INET: Unknown error at E:\Data\Web\Host
scripts\ldaptest.pl line 181.

This is caused by the initialize call:

my $ldap = new Net::LDAP("server.com", port => $port) or die
"$@";

I'm running on Windows 2000 and IIS5.
And yes I did configure IIS to use the Perl interpreter for .pl
files.
Anyone any ideas what's wrong?

Thanks in advance,
Vincent.

Re: DN comparision not using compare function

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

Steve Neruda <ne...@na...> wrote:
> I have written a script that makes sure that the indexes on the slave
> servers are consistent with the master server.  I am having problems
> finding a good way to compare DNs correctly. I do a search on each
> server for to get all the indexes, then I need to compare the DN's to
> see if the indexes exist on all the servers. 
> 
> It appears that Net::LDAP does not normalize the DN before hashing it
> into a structure.  Therefore if I do a comparison of the DN's and one
> happens to be capitalized (or spaces differently, or ??) then comparing
> DNs will fail.

That looks about right. Net::LDAP simply uses the bytes that were sent by
the server as the DN without trying to interpret them too much.

I'm not sure it is a Net::LDAP bug, rather just the "way it works".

> I want to do a single search on each server rather than do a ->compare
> on each attribute.  Is there a better method for comparing DNs between
> two servers to find out if they match?

I can't think of one. Your canonicalization (lower-casing the entire DN)
will of course not work for many cases, but I guess you're aware of that.
It might be good enough to solve your immediate problem.

To be complete I think Unicode says that you should convert to upper-case,
and you need to deal with the different ways to encode accented characters,
the different ordering of multi-AVA RDNs (cn=Foo Bar+uid=baz,...), the
different ways of encoding the attribute types and values, etc etc etc.
Pretty hard to do it all correctly!

And that's assuming you're using LDAPv3 to access the directory. For LDAPv2
there are more problems. :-)

How painful would it be to use compare operations against one of the
servers? It strikes me that would be a *lot* easier, assuming the server
did these things correctly.

Cheers,

Chris

Re: Protocol error

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

Geert Premereur <Gee...@in...> wrote:
> Hi,
> 
> I just downloaded and installed from CPAN Bundle::Net::LDAP (so I should
> have the latest version).
> 
> I do have trouble however performing even the simplest function. Whatever
> LDAP function I call, the library returns a protocol error. Yet, I use the
> most simple program I can think of :

Are you by any chance using perl 5.6 with threading support compiled in?
That is known to cause problems with Convert::ASN1. The only way out for
now is to rebuild perl without thread support.

Cheers,

Chris

Protocol error

[Geert P. <Gee...@in...>]

Hi,

I just downloaded and installed from CPAN Bundle::Net::LDAP (so I should
have the latest version).

I do have trouble however performing even the simplest function. Whatever
LDAP function I call, the library returns a protocol error. Yet, I use the
most simple program I can think of :

----
#/usr/bin/perl -w

use Net::LDAP;

my $server= 'localhost';
my $ldap = Net::LDAP->new($server, debug => 15) or die "$@" ;
$ldap->bind ();
$ldap->unbind;   # take down session
----

What I get is (text continued below...): 

----
Net::LDAP=HASH(0x804c048) sending:

30 0C 02 01 01 40 07 02 01 02 04 00 80 00 __ __ 0....@........

0000 30   12: SEQUENCE {
0002 02    1:   INTEGER = 1
0005 40    7:   [APPLICATION 0]
0007        :     02 01 02 04 00 80 00 __ __ __ __ __ __ __ __ __ .......
000E        : }
Net::LDAP=HASH(0x804c048) received:

30 38 02 01 00 78 33 0A 01 02 04 00 04 14 75 6E 08...x3.......un
6B 6E 6F 77 6E 20 4C 44 41 50 20 72 65 71 75 65 known LDAP reque
73 74 8A 16 31 2E 33 2E 36 2E 31 2E 34 2E 31 2E st..1.3.6.1.4.1.
31 34 36 36 2E 32 30 30 33 36 __ __ __ __ __ __ 1466.20036

0000 30   56: SEQUENCE {
0002 02    1:   INTEGER = 0
0005 78   51:   [APPLICATION 24] {
0007 0A    1:     ENUM = 2
000A 04    0:     STRING = ''
000C 04   20:     STRING = 'unknown LDAP request'
0022 8A   22:     [CONTEXT 10]
0024        :       31 2E 33 2E 36 2E 31 2E 34 2E 31 2E 31 34 36 36
1.3.6.1.4.1.1466
0034        :       2E 32 30 30 33 36 __ __ __ __ __ __ __ __ __ __ .20036
003A        :   }
003A        : }
Net::LDAP=HASH(0x804c048) sending:

30 05 02 01 02 42 00 __ __ __ __ __ __ __ __ __ 0....B.

0000 30    5: SEQUENCE {
0002 02    1:   INTEGER = 2
0005 42    0:   [APPLICATION 2]
0007        : }
----

The really weird part is that when I use perl debug mode everything does
work :

----
Net::LDAP=HASH(0x8586204) sending:

30 0C 02 01 01 60 07 02 01 02 04 00 80 00 __ __ 0....`........

0000 30   12: SEQUENCE {
0002 02    1:   INTEGER = 1
0005 60    7:   [APPLICATION 0] {
0007 02    1:     INTEGER = 2
000A 04    0:     STRING = ''
000C 80    0:     [CONTEXT 0]
000E        :   }
000E        : }
Net::LDAP=HASH(0x8586204) received:

30 0C 02 01 01 61 07 0A 01 00 04 00 04 00 __ __ 0....a........

0000 30   12: SEQUENCE {
0002 02    1:   INTEGER = 1
0005 61    7:   [APPLICATION 1] {
0007 0A    1:     ENUM = 0
000A 04    0:     STRING = ''
000C 04    0:     STRING = ''
000E        :   }
000E        : }
Net::LDAP=HASH(0x8586204) sending:

30 05 02 01 02 42 00 __ __ __ __ __ __ __ __ __ 0....B.

0000 30    5: SEQUENCE {
0002 02    1:   INTEGER = 2
0005 42    0:   [APPLICATION 2]
0007        : }
----

Does anyone have an explanation for this? The debug output suggests that
the message was not encoded correctly. I dug into the source, but the
encoding code is a little too heavy for the uninitiated...

I don't think that it matters, but I'm using openLDAP 2.0.7, which is
responding as it is supposed to using the C library.

Thanks for reading through this (not too?) long post,
Geert

DN comparision not using compare function

[Steve N. <ne...@na...>]

I have written a script that makes sure that the indexes on the slave
servers are consistent with the master server.  I am having problems
finding a good way to compare DNs correctly. I do a search on each
server for to get all the indexes, then I need to compare the DN's to
see if the indexes exist on all the servers. 

It appears that Net::LDAP does not normalize the DN before hashing it
into a structure.  Therefore if I do a comparison of the DN's and one
happens to be capitalized (or spaces differently, or ??) then comparing
DNs will fail.

I want to do a single search on each server rather than do a ->compare
on each attribute.  Is there a better method for comparing DNs between
two servers to find out if they match?


----code snippet below showing an ugly incomplete hack----


 my $server1 = $ldap1->search (        # perform a search
                   base   => "cn=index,cn=config,cn=ldbm",
                   filter => "objectclass=*",
                   attrs => [qw(cn, nsindextype)]

  my $server2 = $ldap2->search (        # perform a search
                   base   => "cn=index,cn=config,cn=ldbm",
                   filter => "objectclass=*",
                   attrs => [qw(cn, nsindextype)]
                  );

  my $href1 = $server1->as_struct;
  my $href2 = $server2->as_struct;

  my @arrayOfDNs1  = keys %$href1 ; # use DN hashes
  my @arrayOfDNs2  = keys %$href2 ; # use DN hashes

  #bug in Net::LDAP where DNs are stored in case sensitive manner
  # cannocialize everything to lower case entries
  my $dn;
  foreach $dn  (@arrayOfDNs1){
    $$href1{lc "$dn"} =$$href1{"$dn"};
  }
  foreach $dn  (@arrayOfDNs2){
    $$href2{lc "$dn"} =$$href2{"$dn"};
  }

Re: Problem found: Problems with schema changes

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

Clif Harden <cl...@di...> wrote:
> 
> Jim and Graham,
> 
> What I find strange is why the schema code could parse the record
> before the patches and not afterwords.  I/we did not change anything
> in the parse code.
> 
> I also think that the ' in I'M should be escaped with a
> \ if it is going to be used this way.
> 
> Clif Harden

RFC 2252 doesn't say how to deal with this. Incidentally this issue has
just come up on the ldapbis mailing list, and there are a couple of
suggestions on how to fix it - \hex, \char, or doubling-up-the-quote eg ''.
(I think \hex is more like the quoting used in other bits of LDAPv3 and
therefore more sensible to use. Other peoples' mileage varies. Handling
doubling-up in a regex is a bit of a pain.)

I'd say it is a pretty dubious thing to have in a schema token, and the
vendor should certainly be notified (which Jim's done.)

Cheers,

Chris

Re: Connecting apache via perl-ldap to Netscapes Directory Server...

[Dworatzek D. <dam...@sv...>]

;-);-);-);-);-);-);-);-);-);-);-)

that´s the way, aha aha, i like it,.....

Thanks Mark, got it today from your hp and will run it imm.

damian

------------------- 
Mit freundlichem Gruß


Damian Dworatzek
Assistent der Geschäftsführung
Sparkassen-Versicherung 
Baden-Württemberg Informatikdienste GmbH (SVI)
dam...@sv...
www.svi.de

Re: Net::LDAP::bind problems under Apache

[Gary Ashton-J. <gas...@f2...>]

I haven't fixed the problem but I have identified the circumstances which
cause Net::LDAP::bind to always fail under Apache.

I accidentally left a PerlAuthenHandler Apache::AuthNetLDAP in one
<Location> while testing my variation of AuthTicket which uses NetLDAP in
another <Location>. Calls to bind were always failing. Eventually I realised
the clash, commented out the AuthNetLDAP call and it works beautifully.

Thanks Graham Barr for the patch to ASN1.pm which stops the method
redefinition warnings but I think now the patch might be better left out.
They were obviously correct warnings because Net::LDAP was being called
twice and I should have been willing to look further.

OTOH maybe Net::LDAP needs to handle(!) being called by two different
handlers...

Rgds

Gary