Menu
▾
▴
perl-ldap-dev
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(200) |
Jun
(129) |
Jul
(184) |
Aug
(204) |
Sep
(106) |
Oct
(79) |
Nov
(72) |
Dec
(54) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(83) |
Feb
(123) |
Mar
(84) |
Apr
(184) |
May
(106) |
Jun
(111) |
Jul
(104) |
Aug
(91) |
Sep
(59) |
Oct
(99) |
Nov
(100) |
Dec
(37) |
| 2002 |
Jan
(148) |
Feb
(88) |
Mar
(85) |
Apr
(151) |
May
(80) |
Jun
(110) |
Jul
(85) |
Aug
(43) |
Sep
(64) |
Oct
(89) |
Nov
(59) |
Dec
(42) |
| 2003 |
Jan
(129) |
Feb
(104) |
Mar
(162) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Chris R. <chr...@me...> - 2001-07-11 16:11:42
|
Knut Sander <knu...@se...> wrote: > Lakshmi Marellapudy wrote: > > Hi - > > unfortunately OpenLDAP does not complain if the bind to the socket > doesn't work. > > slapd -f /opt/openldap/etc/openldap/slapd.conf -h ldap://0.0.0.0:389/ -d > 63 > > shows an error if you are not root and can't use ports <1024. > But you could use ldapsearch -h localhost -p 389 - so that couldn't be > the reason for your problem. > > Knut Unless something else was already listening to localhost:389... Cheers, Chris |
|
From: Knut S. <knu...@se...> - 2001-07-11 15:59:24
|
Lakshmi Marellapudy wrote:
Hi -
unfortunately OpenLDAP does not complain if the bind to the socket
doesn't work.
slapd -f /opt/openldap/etc/openldap/slapd.conf -h ldap://0.0.0.0:389/ -d
63
shows an error if you are not root and can't use ports <1024.
But you could use ldapsearch -h localhost -p 389 - so that couldn't be
the reason for your problem.
Knut
> Knut Sander wrote:
>
> > Hi Lakshmi,
> >
> > Lakshmi Marellapudy wrote:
> > > I have openldap running on my server(192.104.61.84), under my home
> > > directory.
> > > I assumed that it is on port 389.
> > > when I tried to connect through perldap I got an error.
> >
> > assumptions may be wrong, it's much better to proof them =)
> >
> > Which host and port did you specify at startup?
> >
> > Your commandline shold look like:
> >
> > slapd -f /opt/openldap/etc/openldap/slapd.conf -h ldap://localhost:389/
> >
> > This starts slapd on port 389 and binds only to localhost, so it is only
> > reachable via ldapsearch -h localhost -p 389 ...
> >
> > You can also use netstat to list all open sockets on your host and hav a
> > look into the slapd.args file (near slapd.pid).
> >
> > regards,
> > Knut
>
> Knut:
>
> I got "$ldap = new Net::LDAP" working.
> It is working with
> 1) slapd -f /opt/openldap/etc/openldap/slapd.conf -h
> ldap://0.0.0.0:3890/
> $ldap = new Net::LDAP('0.0.0.0', port => 3890);
> 2) slapd -f /opt/openldap/etc/openldap/slapd.conf -h
> ldap://192.014.61.84:3890/
> $ldap = new Net::LDAP('192.104.61.84', port => 3890);
>
> Somehow it didnot work with port 389.
>
> Thanks a lot,
>
> Lakshmi
|
|
From: Lakshmi M. <lm...@fl...> - 2001-07-11 15:45:58
|
Knut Sander wrote:
> Hi Lakshmi,
>
> Lakshmi Marellapudy wrote:
> > I have openldap running on my server(192.104.61.84), under my home
> > directory.
> > I assumed that it is on port 389.
> > when I tried to connect through perldap I got an error.
>
> assumptions may be wrong, it's much better to proof them =)
>
> Which host and port did you specify at startup?
>
> Your commandline shold look like:
>
> slapd -f /opt/openldap/etc/openldap/slapd.conf -h ldap://localhost:389/
>
> This starts slapd on port 389 and binds only to localhost, so it is only
> reachable via ldapsearch -h localhost -p 389 ...
>
> You can also use netstat to list all open sockets on your host and hav a
> look into the slapd.args file (near slapd.pid).
>
> regards,
> Knut
Knut:
I got "$ldap = new Net::LDAP" working.
It is working with
1) slapd -f /opt/openldap/etc/openldap/slapd.conf -h
ldap://0.0.0.0:3890/
$ldap = new Net::LDAP('0.0.0.0', port => 3890);
2) slapd -f /opt/openldap/etc/openldap/slapd.conf -h
ldap://192.014.61.84:3890/
$ldap = new Net::LDAP('192.104.61.84', port => 3890);
Somehow it didnot work with port 389.
Thanks a lot,
Lakshmi
|
|
From: Chris R. <chr...@me...> - 2001-07-11 08:31:25
|
rob...@bt... wrote: > Hello, > I'm trying to read all entries from 2 different types of ldap server, one > of which is MS Exchange. > I manage to bind OK and issue a request for data, I get a single entry > returned then an error 84 (0x54). > these are specific to API and in both cases seem to mean > LDAP_DECODING_ERROR which one of the manufacturers says means it's a > problem with the ldap i/f as te error means their server cannot decode > the type of request being asked for (Version 2 or version 3) > > Any ideas? > thanks > Robert > That sounds unlikely - the server's already sent you one response followed by something that can't be decoded by Net::LDAP, hence the internal error from Net::LDAP. See the man page for Net::LDAP::Constant. If you can turn up debugging to print out the packets perl is getting back, this should help find the problem. Add: $ldap->debug(2); # man Net::LDAP for more details before issuing your search, and send us the resulting output. Cheers, Chris |
|
From: Chris R. <chr...@me...> - 2001-07-11 07:38:14
|
Lakshmi Marellapudy <lm...@fl...> wrote: > Knut Sander wrote: > >> Hi Lakshmi, >> >> Lakshmi Marellapudy wrote: >> > I have openldap running on my server(192.104.61.84), under my home >> > directory. >> > I assumed that it is on port 389. >> > when I tried to connect through perldap I got an error. >> >> assumptions may be wrong, it's much better to proof them =) >> >> Which host and port did you specify at startup? >> >> Your commandline shold look like: >> >> slapd -f /opt/openldap/etc/openldap/slapd.conf -h ldap://localhost:389/ >> >> This starts slapd on port 389 and binds only to localhost, so it is only >> reachable via ldapsearch -h localhost -p 389 ... >> >> You can also use netstat to list all open sockets on your host and hav a >> look into the slapd.args file (near slapd.pid). >> >> regards, >> Knut > > I gave the below commands, and slapd is running. > ------------------------------------------------------------------- > [hugo.evanston.fluent.com 15%]./libexec/slapd -f ./etc/openldap/slapd.conf > -h ldap://localhost:389/ > [hugo.evanston.fluent.com 16%]./bin/ldapsearch -h localhost -p 389 > version: 2 > > # > # filter: (objectclass=*) > # requesting: ALL > # > > # search result > search: 2 > result: 10 Referral > ref: hugo.evanston.fluent.com > > # numResponses: 1 > [hugo.evanston.fluent.com 17%] > -------------------------------------------------------------- > but when I gave $server = "127.0.0.1:389" in the perl code, I still got > timeout error. > > Could anyone please help me. > > Lakshmi > > Your server is apparently listening to the localhost interface on port 389. However, you haven't said whether it is listening on any other network interfaces, eg 192.104.61.84. Listening on one interface does *not* imply listening on others! If you want to listen on 'all interfaces', use the IP address 0.0.0.0 when starting slapd (maybe '-h ldap://0.0.0.0:389/' in the command line arguments, but since I don't use slapd that may be incorrect.) The netstat command should tell you what interfaces your slapd is actually listening on. Since the localhost address apparently works for ldapsearch, try it in perl: $ldap = new Net::LDAP('127.0.0.1', port => 389); Cheers, Chris |
|
From: <rob...@bt...> - 2001-07-11 07:28:06
|
Hello, I'm trying to read all entries from 2 different types of ldap server, one of which is MS Exchange. I manage to bind OK and issue a request for data, I get a single entry returned then an error 84 (0x54). these are specific to API and in both cases seem to mean LDAP_DECODING_ERROR which one of the manufacturers says means it's a problem with the ldap i/f as te error means their server cannot decode the type of request being asked for (Version 2 or version 3) Any ideas? thanks Robert |
|
From: Eric P. <li...@gl...> - 2001-07-10 21:01:49
|
Hello,
I'd like to know if it's possible to use more than one LDAP
server, in other words, to connect to the slave ldap server if the
master is down.
And if so, how would I implement such a thing? Just test the
connection to the first (maybe set a timeout value that's not too
high), and if it fails to connect, try the 2nd?
Or is there an easier way to do it? All the other methods I've used
of connecting to an LDAP server allowed me to just specify multiple
ldap servers, seperated by a space...
Thanks in advance,
Eric Parusel
Systems Administrator
Global Relay Communications
|
|
From: Lakshmi M. <lm...@fl...> - 2001-07-10 20:16:04
|
Knut Sander wrote: > Hi Lakshmi, > > Lakshmi Marellapudy wrote: > > I have openldap running on my server(192.104.61.84), under my home > > directory. > > I assumed that it is on port 389. > > when I tried to connect through perldap I got an error. > > assumptions may be wrong, it's much better to proof them =) > > Which host and port did you specify at startup? > > Your commandline shold look like: > > slapd -f /opt/openldap/etc/openldap/slapd.conf -h ldap://localhost:389/ > > This starts slapd on port 389 and binds only to localhost, so it is only > reachable via ldapsearch -h localhost -p 389 ... > > You can also use netstat to list all open sockets on your host and hav a > look into the slapd.args file (near slapd.pid). > > regards, > Knut I gave the below commands, and slapd is running. ------------------------------------------------------------------- [hugo.evanston.fluent.com 15%]./libexec/slapd -f ./etc/openldap/slapd.conf -h ldap://localhost:389/ [hugo.evanston.fluent.com 16%]./bin/ldapsearch -h localhost -p 389 version: 2 # # filter: (objectclass=*) # requesting: ALL # # search result search: 2 result: 10 Referral ref: hugo.evanston.fluent.com # numResponses: 1 [hugo.evanston.fluent.com 17%] -------------------------------------------------------------- but when I gave $server = "127.0.0.1:389" in the perl code, I still got timeout error. Could anyone please help me. Lakshmi |
|
From: Knut S. <knu...@se...> - 2001-07-10 19:47:54
|
Hi Lakshmi, Lakshmi Marellapudy wrote: > I have openldap running on my server(192.104.61.84), under my home > directory. > I assumed that it is on port 389. > when I tried to connect through perldap I got an error. assumptions may be wrong, it's much better to proof them =) Which host and port did you specify at startup? Your commandline shold look like: slapd -f /opt/openldap/etc/openldap/slapd.conf -h ldap://localhost:389/ This starts slapd on port 389 and binds only to localhost, so it is only reachable via ldapsearch -h localhost -p 389 ... You can also use netstat to list all open sockets on your host and hav a look into the slapd.args file (near slapd.pid). regards, Knut |
|
From: Lakshmi M. <lm...@fl...> - 2001-07-09 21:50:05
|
I have openldap running on my server(192.104.61.84), under my home directory. I assumed that it is on port 389. when I tried to connect through perldap I got an error. the code is ; ----------------------------------------- #Package definitions use Net::LDAP qw(:all); #use for all code use Net::LDAP::Entry; use Net::LDAP::Util qw(ldap_error_name ldap_error_text); #use for error handlin g #Initializing $server="192.104.61.84"; $port=389; $ldap = Net::LDAP->new($server, port=>$port) or die "Unable to connect to server $server : $@\n"; -------------------------------------------------------- The error is : ------------------------------------------------------- Unable to connect to server 192.104.61.84 : IO::Socket::INET: Timeout ------------------------------------------------------------- Would anyone please tell me how to connect to openldap using Net::LDAP->new Thanks, Lakshmi |
|
From: Graham B. <gb...@po...> - 2001-07-06 19:05:20
|
----- Forwarded message from Sean Chen <sc...@sa...> -----
Date: Fri, 06 Jul 2001 11:04:43 -0700
To: gb...@po...
Cc: sc...@sa...
From: Sean Chen <sc...@sa...>
Subject: Perl-Ldap
X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i686)
Hello Mr. Barr,
Im currently using your LDAP module to interface with an
openLDAP server using SASL. Initially, I was unable to log into the
server, and repeatedly received the "no secret in database" error
message from the server. After some poking around, I discovered that
when a "sasl" field is passed, the "user" element of the sasl object is
set to "dn: $dn". I finally was able to get the connection to work by
removing the setting of "user", and manually setting it to just the
username(i.e. $sasl->name("joe") instead of $sasl->name("dn: cn=joe,
[...]")). I was wondering if this is a bug, or if other LDAP sasl
implementations use the "dn:" format. Thanks for your time and help!
Sean Chen
----- End forwarded message -----
|
|
From: Graham B. <gb...@po...> - 2001-07-06 18:13:47
|
Sure, Examples and documentation are always something that often gets left behind during releases. So patches and new submissions are always welcome. Graham. On Fri, Jul 06, 2001 at 01:09:04PM -0500, Rusty Biggs wrote: > Graham, on another subject, is there any interest in having the 'examples' > updated? > > I know some of the original calls have changed (i.e. have been deprecated) > so I figured that maybe an update would be in order. > > > Let me know. > > Rusty > > -- > > > Russell Biggs (Rusty) Internet: r-...@ti... > 6500 Chase Oaks Blvd, M/S 8412 > Texas Instruments > Plano Tx 75023 > > Phone: (972) 575-0826 > Fax: (972) 575-4853 > Home Page: http://dirtest3.itg.ti.com/~rgb > Calendar: http://dirtest3.itg.ti.com/cgi-bin/synchronize.cgi?name=Russell+Biggs > > |
|
From: <rg...@di...> - 2001-07-06 18:09:11
|
Graham, on another subject, is there any interest in having the 'examples' updated? I know some of the original calls have changed (i.e. have been deprecated) so I figured that maybe an update would be in order. Let me know. Rusty -- Russell Biggs (Rusty) Internet: r-...@ti... 6500 Chase Oaks Blvd, M/S 8412 Texas Instruments Plano Tx 75023 Phone: (972) 575-0826 Fax: (972) 575-4853 Home Page: http://dirtest3.itg.ti.com/~rgb Calendar: http://dirtest3.itg.ti.com/cgi-bin/synchronize.cgi?name=Russell+Biggs |
|
From: <rg...@di...> - 2001-07-06 17:52:04
|
(this time with the module attached :) Folks, my apologies if this isn't the correct forum for this. I was asked to present it to the list for your comments. In my past work on implementing LDAP applications (mostly WEB based), I'm always running into issues of building complex query strings dynamically and more important correctly. So, I wrote a PERL module to accomplish this. My dilemma is where to put it if folks think it it worthy of publishing. It's sole purpose is to create LDAP query strings, but is not dependent on any other modules (e.g. Net::LDAP) or programs (i.e. pure Perl). Graham commented that it might make sense to expand the Net::LDAP::Filter code. Anyway, I'm not going to proceed with publishing until I've gotten comments, criticism, or flames that I can use for direction. Thanks in advance for any response. Rusty On Jul 6, 4:50pm, Graham Barr wrote: > Subject: Re: seeking advice > > The module looks interesting. If you were to put it on CPAM as a module by itself, > I am not quite sure what to call it. However it does look very interesting. > > What I would suggest is to post it to the list and see what others think. > > Maybe it could be added to Net::LDAP::Filter as a class method and return > an Net::LDAP::Filter object instead of the string. This would give people > an alternative way to create filters. > > I have often wondered if it would be useful to add methods to Filter.pm > so you could do > > $new = $filt1->and($filt2,$filt3) > > etc... > > Anyway, I am waffling now. > > Send it to the list and lets see what people think. > > Graham. > -- Russell Biggs (Rusty) Internet: r-...@ti... 6500 Chase Oaks Blvd, M/S 8412 Texas Instruments Plano Tx 75023 Phone: (972) 575-0826 Fax: (972) 575-4853 Home Page: http://dirtest3.itg.ti.com/~rgb Calendar: http://dirtest3.itg.ti.com/cgi-bin/synchronize.cgi?name=Russell+Biggs |
|
From: <rg...@di...> - 2001-07-06 17:49:42
|
Folks, my apologies if this isn't the correct forum for this. I was asked to present it to the list for your comments. In my past work on implementing LDAP applications (mostly WEB based), I'm always running into issues of building complex query strings dynamically and more important correctly. So, I wrote a PERL module to accomplish this. My dilemma is where to put it if folks think it it worthy of publishing. It's sole purpose is to create LDAP query strings, but is not dependent on any other modules (e.g. Net::LDAP) or programs (i.e. pure Perl). Graham commented that it might make sense to expand the Net::LDAP::Filter code. Anyway, I'm not going to proceed with publishing until I've gotten comments, criticism, or flames that I can use for direction. Thanks in advance for any response. Rusty On Jul 6, 4:50pm, Graham Barr wrote: > Subject: Re: seeking advice > > The module looks interesting. If you were to put it on CPAM as a module by itself, > I am not quite sure what to call it. However it does look very interesting. > > What I would suggest is to post it to the list and see what others think. > > Maybe it could be added to Net::LDAP::Filter as a class method and return > an Net::LDAP::Filter object instead of the string. This would give people > an alternative way to create filters. > > I have often wondered if it would be useful to add methods to Filter.pm > so you could do > > $new = $filt1->and($filt2,$filt3) > > etc... > > Anyway, I am waffling now. > > Send it to the list and lets see what people think. > > Graham. > -- Russell Biggs (Rusty) Internet: r-...@ti... 6500 Chase Oaks Blvd, M/S 8412 Texas Instruments Plano Tx 75023 Phone: (972) 575-0826 Fax: (972) 575-4853 Home Page: http://dirtest3.itg.ti.com/~rgb Calendar: http://dirtest3.itg.ti.com/cgi-bin/synchronize.cgi?name=Russell+Biggs |
|
From: Richard L. <rl...@me...> - 2001-07-06 17:30:38
|
Hi, I am trying to break up the output or return from an LDIFprint command into seperate attribute/value pairs so that I can use only some of them. If I use "$entry->printLDIF();" how do I break the return into useful pieces? Is the returned value in the form of a hash? I can get the data back but not sure how to hack it up. Any help would be appreciated. Thanks in advance, Rich Lytle |
|
From: Graham B. <gb...@po...> - 2001-07-06 16:06:32
|
On Fri, Jul 06, 2001 at 11:01:12AM -0500, Christopher A Bongaarts wrote: > As Graham Barr once put it so eloquently: > > > Can you send a patch ? > > Done. Thanks. Graham. > > %% Christopher A. Bongaarts %% ca...@tc... %% > %% Internet Services %% http://umn.edu/~cab %% > %% University of Minnesota %% +1 (612) 625-1809 %% > ----snip---- > --- perl-ldap-0.23/lib/Net/LDAP/LDIF.pm Tue Apr 10 11:18:36 2001 > +++ site_perl/5.6.0/Net/LDAP/LDIF.pm Fri Jun 22 14:15:49 2001 > @@ -325,9 +325,9 @@ > next; > } > elsif ($type eq 'modrdn') { > - print _write_attr('newrdn',$entry->get_value('newrdn'),$wrap); > + print _write_attr('newrdn',$entry->get_value('newrdn', asref => 1),$wrap); > print 'deleteoldrdn: ',$entry->get_value('deleteoldrdn'),"\n"; > - my $ns = $entry->get_value('newsuperior'); > + my $ns = $entry->get_value('newsuperior', asref => 1); > print _write_attr('newsuperior',$ns,$wrap) if defined $ns; > next; > } |
|
From: Christopher A B. <ca...@tc...> - 2001-07-06 16:01:16
|
As Graham Barr once put it so eloquently: > Can you send a patch ? Done. %% Christopher A. Bongaarts %% ca...@tc... %% %% Internet Services %% http://umn.edu/~cab %% %% University of Minnesota %% +1 (612) 625-1809 %% ----snip---- --- perl-ldap-0.23/lib/Net/LDAP/LDIF.pm Tue Apr 10 11:18:36 2001 +++ site_perl/5.6.0/Net/LDAP/LDIF.pm Fri Jun 22 14:15:49 2001 @@ -325,9 +325,9 @@ next; } elsif ($type eq 'modrdn') { - print _write_attr('newrdn',$entry->get_value('newrdn'),$wrap); + print _write_attr('newrdn',$entry->get_value('newrdn', asref => 1),$wrap); print 'deleteoldrdn: ',$entry->get_value('deleteoldrdn'),"\n"; - my $ns = $entry->get_value('newsuperior'); + my $ns = $entry->get_value('newsuperior', asref => 1); print _write_attr('newsuperior',$ns,$wrap) if defined $ns; next; } |
|
From: Clif H. <cl...@di...> - 2001-07-06 15:44:46
|
> > Can you send a patch ? > > Graham. > > On Fri, Jul 06, 2001 at 09:31:14AM -0500, Christopher A Bongaarts wrote: > > As Graham Barr once put it so eloquently: > > > > > Does anyone know of any outstanding problems with 0.23 that have > > > not been fixed in CVS ? > > > > There's a bug in handling modrdn requests of Net::LDAP::LDIF. Around > > line 327 in version 0.23, there are a few calls to _write_attr using > > the results from calling Entry's get_value method. _write_attr needs a > > reference, but get_value by default returns a value. > > > > Two possible fixes: add asref => 1 to the options passed to the > > get_value method, or fix _write_attr to not dereference its parameter > > if it is not a reference. (I fixed it myself the first way and could > > probably provide the patch in a few days, but I suspect the latter fix > > would be more robust.) > > > > %% Christopher A. Bongaarts %% ca...@tc... %% > > %% Internet Services %% http://umn.edu/~cab %% > > %% University of Minnesota %% +1 (612) 625-1809 %% > > > > Thought someone are ready sent a patch about the dereference issue. Regards, Clif |
|
From: Graham B. <gb...@po...> - 2001-07-06 14:33:25
|
Can you send a patch ? Graham. On Fri, Jul 06, 2001 at 09:31:14AM -0500, Christopher A Bongaarts wrote: > As Graham Barr once put it so eloquently: > > > Does anyone know of any outstanding problems with 0.23 that have > > not been fixed in CVS ? > > There's a bug in handling modrdn requests of Net::LDAP::LDIF. Around > line 327 in version 0.23, there are a few calls to _write_attr using > the results from calling Entry's get_value method. _write_attr needs a > reference, but get_value by default returns a value. > > Two possible fixes: add asref => 1 to the options passed to the > get_value method, or fix _write_attr to not dereference its parameter > if it is not a reference. (I fixed it myself the first way and could > probably provide the patch in a few days, but I suspect the latter fix > would be more robust.) > > %% Christopher A. Bongaarts %% ca...@tc... %% > %% Internet Services %% http://umn.edu/~cab %% > %% University of Minnesota %% +1 (612) 625-1809 %% > |
|
From: Christopher A B. <ca...@tc...> - 2001-07-06 14:31:17
|
As Graham Barr once put it so eloquently: > Does anyone know of any outstanding problems with 0.23 that have > not been fixed in CVS ? There's a bug in handling modrdn requests of Net::LDAP::LDIF. Around line 327 in version 0.23, there are a few calls to _write_attr using the results from calling Entry's get_value method. _write_attr needs a reference, but get_value by default returns a value. Two possible fixes: add asref => 1 to the options passed to the get_value method, or fix _write_attr to not dereference its parameter if it is not a reference. (I fixed it myself the first way and could probably provide the patch in a few days, but I suspect the latter fix would be more robust.) %% Christopher A. Bongaarts %% ca...@tc... %% %% Internet Services %% http://umn.edu/~cab %% %% University of Minnesota %% +1 (612) 625-1809 %% |
|
From: Graham B. <gb...@po...> - 2001-07-06 13:44:33
|
On Fri, Jul 06, 2001 at 02:40:33PM +0100, Chris Ridd wrote: > Yes, I'm happy with that and for adding "use IO::Socket::SSL 0.80". We > probably want to wait until he's actually released 0.80 to make sure it > works correctly with perl-ldap, in case there are nasty surprises. Sure, but I can send you a copy :) Graham. |
|
From: Chris R. <chr...@me...> - 2001-07-06 13:40:50
|
Graham Barr <gb...@po...> wrote: > On Fri, Jul 06, 2001 at 02:17:03PM +0100, Chris Ridd wrote: >> Graham Barr <gb...@po...> wrote: >> > On Fri, Jul 06, 2001 at 01:35:47PM +0100, Chris Ridd wrote: >> >> Graham Barr <gb...@po...> wrote: >> >> > On Fri, Jul 06, 2001 at 01:03:16PM +0100, Chris Ridd wrote: >> >> >> The setting of capth/cafile to '' instead of undef is required by >> >> >> 0.78. Hm, we could make our code check the IO::Socket::SSL version >> >> >> and set the defaults appropriately... >> >> > >> >> > Hm, I have o.78 here and it works fine with undef or '' >> >> > >> >> > Graham. >> >> >> >> You have to actually try verifying a server's cert using capath to see >> >> this problem. >> > >> > Ah, that would explain it. >> > >> > Graham. >> >> Would this patch be appropriate? > > Yes. But it seems Marcus is going to release a new IO::Socket::SSL with > my fix. > > So rather than fill with version comparisons, I was thinking of the > Makefile.PL warning if the version was < 0.80 > > What do you think ? > > Graham. Yes, I'm happy with that and for adding "use IO::Socket::SSL 0.80". We probably want to wait until he's actually released 0.80 to make sure it works correctly with perl-ldap, in case there are nasty surprises. Cheers, Chris |
|
From: Graham B. <gb...@po...> - 2001-07-06 13:34:04
|
On Fri, Jul 06, 2001 at 02:30:34PM +0100, Graham Barr wrote: > Yes. But it seems Marcus is going to release a new IO::Socket::SSL with my fix. > > So rather than fill with version comparisons, I was thinking of the Makefile.PL > warning if the version was < 0.80 > > What do you think ? That would mean changing Net::LDAPS to have use IO::Socket::SSL 0.80; which would cause it to die id they have a lower version. Graham. |
|
From: Graham B. <gb...@po...> - 2001-07-06 13:32:15
|
On Fri, Jul 06, 2001 at 02:17:03PM +0100, Chris Ridd wrote:
> Graham Barr <gb...@po...> wrote:
> > On Fri, Jul 06, 2001 at 01:35:47PM +0100, Chris Ridd wrote:
> >> Graham Barr <gb...@po...> wrote:
> >> > On Fri, Jul 06, 2001 at 01:03:16PM +0100, Chris Ridd wrote:
> >> >> The setting of capth/cafile to '' instead of undef is required by
> >> >> 0.78. Hm, we could make our code check the IO::Socket::SSL version
> >> >> and set the defaults appropriately...
> >> >
> >> > Hm, I have o.78 here and it works fine with undef or ''
> >> >
> >> > Graham.
> >>
> >> You have to actually try verifying a server's cert using capath to see
> >> this problem.
> >
> > Ah, that would explain it.
> >
> > Graham.
>
> Would this patch be appropriate?
Yes. But it seems Marcus is going to release a new IO::Socket::SSL with my fix.
So rather than fill with version comparisons, I was thinking of the Makefile.PL
warning if the version was < 0.80
What do you think ?
Graham.
>
> Cheers,
>
> Chris
> Index: lib/Net/LDAPS.pm
> ===================================================================
> RCS file: /cvsroot/perl-ldap/ldap/lib/Net/LDAPS.pm,v
> retrieving revision 1.8
> diff -b -c -r1.8 LDAPS.pm
> *** lib/Net/LDAPS.pm 2001/07/06 11:53:01 1.8
> --- lib/Net/LDAPS.pm 2001/07/06 13:15:35
> ***************
> *** 49,56 ****
>
> (
> SSL_cipher_list => defined $arg->{'ciphers'} ? $arg->{'ciphers'} :
> 'ALL',
> ! SSL_ca_file => exists $arg->{'cafile'} ? $arg->{'cafile'} : '',
> ! SSL_ca_path => exists $arg->{'capath'} ? $arg->{'capath'} : '',
> SSL_key_file => $clientcert ? $clientkey : undef,
> SSL_use_cert => $clientcert ? 1 : 0,
> SSL_cert_file => $clientcert,
> --- 49,58 ----
>
> (
> SSL_cipher_list => defined $arg->{'ciphers'} ? $arg->{'ciphers'} :
> 'ALL',
> ! SSL_ca_file => exists $arg->{'cafile'} ? $arg->{'cafile'} :
> ! ($IO::Socket::SSL::VERSION >= "0.78" ? '' : undef),
> ! SSL_ca_path => exists $arg->{'capath'} ? $arg->{'capath'} :
> ! ($IO::Socket::SSL::VERSION >= "0.78" ? '' : undef),
> SSL_key_file => $clientcert ? $clientkey : undef,
> SSL_use_cert => $clientcert ? 1 : 0,
> SSL_cert_file => $clientcert,
|
7902 messages has been excluded from this view by a project administrator.
