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-06-22 08:00:57
|
Graham Barr <gb...@po...> wrote:
> ----- Forwarded message from Jim Dutton <ji...@ws...>
> Subject: LDAPv3 annoymous bind with perl-ldap-0.22?
> To: Graham Barr <gb...@po...>
> MIME-Version: 1.0
> Content-Type: TEXT/plain; charset=us-ascii
>
> How do I go about obtaining an LDAPv3 annonymous bind with
> perl-ldao-0.22? If I use "bind( version => 3)", I get an
> LDAP_INAPPROPRIATE_AUTH error message and the OpenLDAP (LDAPv3) debug
> trace shows an LDAPv2 bind request. If I bind with a defined DN and
> password I can obtain an LDAPv3 bind, but I don't want to have to fully
> authenticate just to get an LDAPv3 bind. Thank you.
>
>
> ----- End forwarded message -----
>
If you read the Net::LDAP manpage for 'bind', you should see that you need
to do this:
$ldap->bind(anonymous => 'ignored', version => 3);
Alternatively, this should also work:
$ldap = Net::LDAP->new('hostname', version => 3);
$ldap->bind();
Cheers,
Chris
|
|
From: Graham B. <gb...@po...> - 2001-06-21 21:19:29
|
----- Forwarded message from Jim Dutton <ji...@ws...> ----- Return-Path: <po...@mu...> Received: (from pobox@localhost) by monty.mutatus.co.uk (8.11.3/8.11.3) id f5LKkGB48447 for gbarr; Thu, 21 Jun 2001 21:46:16 +0100 (BST) (envelope-from pobox) Received: from dolly2.pobox.com (dolly2.pobox.com [208.210.125.92]) by monty.mutatus.co.uk (8.11.3/8.11.3) with ESMTP id f5LKkBU48434 for <po...@mu...>; Thu, 21 Jun 2001 21:46:15 +0100 (BST) (envelope-from ji...@ws...) Received: from dolly2 (localhost.localdomain [127.0.0.1]) by dolly2.pobox.com (Postfix) with ESMTP id 9137E25EE1 for <po...@mu...>; Thu, 21 Jun 2001 16:47:23 -0400 (EDT) Received: from ws179149.56kdialup.siu.edu (ws179149.56kdialup.siu.edu [131.230.179.149]) by dolly2.pobox.com (Postfix) with ESMTP id BE6B225F12 for <gb...@po...>; Thu, 21 Jun 2001 16:47:21 -0400 (EDT) Received: by ws17903.56kdialup.siu.edu (8.11.0/8.11.0) id f5K4acZ00701 for gb...@po...; Wed, 20 Jun 2001 04:36:38 -0820 (GMT) Message-Id: <200...@ws...> Date: Wed, 20 Jun 2001 04:36:37 +0000 (CDT) From: Jim Dutton <ji...@ws...> Reply-To: ji...@si... Subject: anonymous bind with "empty" DN and passwd? (perl-ldap-0.22) To: Graham Barr <gb...@po...> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii It appears that attempting to perform/request an annonymous bind while supplying "empty" DN and password parameters causes a bind failure. Using no parameters succeeds with an annonymous bind, but I am interested in using a static model that allows me to fill in the DN and password parameters as needed, but still affect an annonymous bind without having to include extra code and a seperate bind statement. Thank you. ----- End forwarded message ----- |
|
From: Graham B. <gb...@po...> - 2001-06-21 21:19:19
|
----- Forwarded message from Jim Dutton <ji...@ws...> ----- Return-Path: <po...@mu...> Received: (from pobox@localhost) by monty.mutatus.co.uk (8.11.3/8.11.3) id f5LKkD148437 for gbarr; Thu, 21 Jun 2001 21:46:13 +0100 (BST) (envelope-from pobox) Received: from dolly2.pobox.com (dolly2.pobox.com [208.210.125.92]) by monty.mutatus.co.uk (8.11.3/8.11.3) with ESMTP id f5LKk8U48432 for <po...@mu...>; Thu, 21 Jun 2001 21:46:12 +0100 (BST) (envelope-from ji...@ws...) Received: from dolly2 (localhost.localdomain [127.0.0.1]) by dolly2.pobox.com (Postfix) with ESMTP id 0EFDC25F04 for <po...@mu...>; Thu, 21 Jun 2001 16:47:22 -0400 (EDT) Received: from ws179149.56kdialup.siu.edu (ws179149.56kdialup.siu.edu [131.230.179.149]) by dolly2.pobox.com (Postfix) with ESMTP id 20BBA25EE7 for <gb...@po...>; Thu, 21 Jun 2001 16:47:18 -0400 (EDT) Received: by ws17903.56kdialup.siu.edu (8.11.0/8.11.0) id f5K4WvG00652 for gb...@po...; Wed, 20 Jun 2001 04:32:57 -0820 (GMT) Message-Id: <200...@ws...> Date: Wed, 20 Jun 2001 04:32:55 +0000 (CDT) From: Jim Dutton <ji...@ws...> Reply-To: ji...@si... Subject: LDAPv3 annoymous bind with perl-ldap-0.22? To: Graham Barr <gb...@po...> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii How do I go about obtaining an LDAPv3 annonymous bind with perl-ldao-0.22? If I use "bind( version => 3)", I get an LDAP_INAPPROPRIATE_AUTH error message and the OpenLDAP (LDAPv3) debug trace shows an LDAPv2 bind request. If I bind with a defined DN and password I can obtain an LDAPv3 bind, but I don't want to have to fully authenticate just to get an LDAPv3 bind. Thank you. ----- End forwarded message ----- |
|
From: Graham B. <gb...@po...> - 2001-06-21 21:18:20
|
----- Forwarded message from Jim Dutton <ji...@ws...> ----- Date: Wed, 20 Jun 2001 04:36:37 +0000 (CDT) To: Graham Barr <gb...@po...> From: Jim Dutton <ji...@ws...> Subject: anonymous bind with "empty" DN and passwd? (perl-ldap-0.22) It appears that attempting to perform/request an annonymous bind while supplying "empty" DN and password parameters causes a bind failure. Using no parameters succeeds with an annonymous bind, but I am interested in using a static model that allows me to fill in the DN and password parameters as needed, but still affect an annonymous bind without having to include extra code and a seperate bind statement. Thank you. ----- End forwarded message ----- |
|
From: Graham B. <gb...@po...> - 2001-06-21 21:18:11
|
----- Forwarded message from Jim Dutton <ji...@ws...> ----- Date: Wed, 20 Jun 2001 04:32:55 +0000 (CDT) To: Graham Barr <gb...@po...> From: Jim Dutton <ji...@ws...> Subject: LDAPv3 annoymous bind with perl-ldap-0.22? How do I go about obtaining an LDAPv3 annonymous bind with perl-ldao-0.22? If I use "bind( version => 3)", I get an LDAP_INAPPROPRIATE_AUTH error message and the OpenLDAP (LDAPv3) debug trace shows an LDAPv2 bind request. If I bind with a defined DN and password I can obtain an LDAPv3 bind, but I don't want to have to fully authenticate just to get an LDAPv3 bind. Thank you. ----- End forwarded message ----- |
|
From: tim f. <ful...@dr...> - 2001-06-21 14:46:41
|
Hi Got some odd behaviour with Net::LDAP which I've been using pretty solidly for some time now. When I run a simple script from the command line it binds to the LDAP server and does a search just fine. When I run the same script under Apache Registry, or the guts of the script inside a perl handler I get the following error on the LDAP bind() mesg code: 1 mesg error: I/O Error Resource temporarily unavailable And the search runs but only ever resolves to the root object in the directory. It doesn't matter if I bind anoymously or as the root user. The LDAP server is running on another machine to the Apache server. I figure this might have something to do with a different perl environment running under apache but comparing perl -V on the command line with a dump of myconfig & @INC running under Apache only gives a different @INC: using perl -V: /usr/local/lib/perl5/5.00503/sun4-solaris /usr/local/lib/perl5/5.00503 /usr/local/lib/perl5/site_perl/5.005/sun4-solaris /usr/local/lib/perl5/site_perl/5.005 dump of @INC under Apache /usr/local/apache/lib/perl /usr/local/apache/lib/perl /usr/local/lib/perl5/5.00503/sun4-solaris /usr/local/lib/perl5/5.00503 /usr/local/lib/perl5/site_perl/5.005/sun4-solaris /usr/local/lib/perl5/site_perl/5.005 . /usr/local/apache/ /usr/local/apache/lib/perl My environment: Solaris 2.6 Apache 1.3.20 mod_perl 1.25 Perl 5.00503 Any ideas ? Tim Fulcher |
|
From: Chris R. <chr...@me...> - 2001-06-21 09:35:50
|
Christian Gilmore <cgi...@ti...> wrote: > [ Sorry for the initial, icomplete post ] > > I've successfully queried an SSL-enabled LDAPv3 service with Net::LDAPS, > but the software continually dies when I attempt to verify the CA > certificate. I have followed the instructions for creating the hash-valued > symlink to the CA cert file. > > lrwxrwxrwx ce23b666.0 -> equifaxca2.crt > -r--r--r-- equifaxca2.crt > > tomcat% more ce23b666.0 > -----BEGIN CERTIFICATE----- > MIIC8DCCAlmgAwIBAgIBEDANBgkqhkiG9w0BAQQFADCBxDELMAkGA1UEBhMCWkEx > FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMR0wGwYD > VQQKExRUaGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UECxMfQ2VydGlmaWNhdGlv > biBTZXJ2aWNlcyBEaXZpc2lvbjEZMBcGA1UEAxMQVGhhd3RlIFNlcnZlciBDQTEm > MCQGCSqGSIb3DQEJARYXc2VydmVyLWNlcnRzQHRoYXd0ZS5jb20wHhcNOTkwNTI1 > MDMwMDAwWhcNMDIwNjEwMDMwMDAwWjBTMQswCQYDVQQGEwJVUzEbMBkGA1UEChMS > RXF1aWZheCBTZWN1cmUgSW5jMScwJQYDVQQDEx5FcXVpZmF4IFNlY3VyZSBFLUJ1 > c2luZXNzIENBLTIwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMYna8GjS9mG > q4Cb8L0VwDBMZ+ztPI05urQb8F0t1Dp4I3gOFUs2WZJJv9Y1zCFwQbQbfJuBuXmZ > QKIZJOw3jwPbfcvoTyqQhM0Yyb1YzgM2ghuv8Zz/+LYrjBo2yrmf86zvMhDVOD7z > dhDzyTxCh5F6+K6Mcmmar+ncFMmIum2bAgMBAAGjYjBgMBIGA1UdEwEB/wQIMAYB > Af8CAQAwSgYDVR0lBEMwQQYIKwYBBQUHAwEGCCsGAQUFBwMDBgorBgEEAYI3CgMD > BglghkgBhvhCBAEGCCsGAQUFBwMIBgorBgEEAYI3CgMCMA0GCSqGSIb3DQEBBAUA > A4GBALIfbC0RQ9g4Zxf/Y8IA2jWm8Tt+jvFWPt5wT3n5k0orRAvbmTROVPHGSLw7 > oMNeapH1eRG5yn+erwqYazcoFXJ6AsIC5WUjAnClsSrHBCAnEn6rDU080F38xIQ3 > j1FBvwMOxAq/JR5eZZcBHlSpJad88Twfd7E+0fQcqgk+nnjH > -----END CERTIFICATE----- > > I get the following information back regarding the certificates returned: > > Cipher used: DES-CBC3-SHA > Subject DN: /C=US/ST=Colorado/L=Boulder/OU=IBM Global > Services/O=IBM/CN=bluepages.ibm.com > Issuer Name: /C=US/O=Equifax Secure Inc/CN=Equifax Secure E-Business CA-2 > > This information matches the CA's certificate information. As soon as I > attempt to change the ldap object's verify status from none to require, > the software dies during connection establishment. Has anyone had a > similar problem? If so, how did you resolve it? > > perl-5.6.1 > perl-ldap-0.23 > IO-Socket-SSL-0.79 > Crypt-SSLeay-0.27 > Net_SSLeay-1.07 > > Regards, > Christian What is in the 'die' message? The IO::Socket::SSL interface changed a little bit a while ago, it is possible that I need to update the Net::LDAPS documentation to match. IIRC, the problem is that you *have* to set cafile and capath otherwise you get some useless default behaviour. Since you only usually want to set one of cafile or capath, I think you have to simply set the other one to an empty string. (It looks like you're using capath, so set cafile to '') So, please check that. Are you connecting to the right host, ie bluepages.ibm.com? I can't remember if OpenSSL checks that itself. Otherwise, can you try and make sure that there's no underlying OpenSSL problem? Use the OpenSSL s_client program and attempt to connect to your directory. The -verify, -state and -debug options are useful. (It doesn't matter that s_client doesn't understand LDAP, you're just trying to test the SSL handshake.) Cheers, Chris |
|
From: Christian G. <cgi...@ti...> - 2001-06-20 22:04:33
|
[ Sorry for the initial, icomplete post ] I've successfully queried an SSL-enabled LDAPv3 service with Net::LDAPS, but the software continually dies when I attempt to verify the CA certificate. I have followed the instructions for creating the hash-valued symlink to the CA cert file. lrwxrwxrwx ce23b666.0 -> equifaxca2.crt -r--r--r-- equifaxca2.crt tomcat% more ce23b666.0 -----BEGIN CERTIFICATE----- MIIC8DCCAlmgAwIBAgIBEDANBgkqhkiG9w0BAQQFADCBxDELMAkGA1UEBhMCWkEx FTATBgNVBAgTDFdlc3Rlcm4gQ2FwZTESMBAGA1UEBxMJQ2FwZSBUb3duMR0wGwYD VQQKExRUaGF3dGUgQ29uc3VsdGluZyBjYzEoMCYGA1UECxMfQ2VydGlmaWNhdGlv biBTZXJ2aWNlcyBEaXZpc2lvbjEZMBcGA1UEAxMQVGhhd3RlIFNlcnZlciBDQTEm MCQGCSqGSIb3DQEJARYXc2VydmVyLWNlcnRzQHRoYXd0ZS5jb20wHhcNOTkwNTI1 MDMwMDAwWhcNMDIwNjEwMDMwMDAwWjBTMQswCQYDVQQGEwJVUzEbMBkGA1UEChMS RXF1aWZheCBTZWN1cmUgSW5jMScwJQYDVQQDEx5FcXVpZmF4IFNlY3VyZSBFLUJ1 c2luZXNzIENBLTIwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMYna8GjS9mG q4Cb8L0VwDBMZ+ztPI05urQb8F0t1Dp4I3gOFUs2WZJJv9Y1zCFwQbQbfJuBuXmZ QKIZJOw3jwPbfcvoTyqQhM0Yyb1YzgM2ghuv8Zz/+LYrjBo2yrmf86zvMhDVOD7z dhDzyTxCh5F6+K6Mcmmar+ncFMmIum2bAgMBAAGjYjBgMBIGA1UdEwEB/wQIMAYB Af8CAQAwSgYDVR0lBEMwQQYIKwYBBQUHAwEGCCsGAQUFBwMDBgorBgEEAYI3CgMD BglghkgBhvhCBAEGCCsGAQUFBwMIBgorBgEEAYI3CgMCMA0GCSqGSIb3DQEBBAUA A4GBALIfbC0RQ9g4Zxf/Y8IA2jWm8Tt+jvFWPt5wT3n5k0orRAvbmTROVPHGSLw7 oMNeapH1eRG5yn+erwqYazcoFXJ6AsIC5WUjAnClsSrHBCAnEn6rDU080F38xIQ3 j1FBvwMOxAq/JR5eZZcBHlSpJad88Twfd7E+0fQcqgk+nnjH -----END CERTIFICATE----- I get the following information back regarding the certificates returned: Cipher used: DES-CBC3-SHA Subject DN: /C=US/ST=Colorado/L=Boulder/OU=IBM Global Services/O=IBM/CN=bluepages.ibm.com Issuer Name: /C=US/O=Equifax Secure Inc/CN=Equifax Secure E-Business CA-2 This information matches the CA's certificate information. As soon as I attempt to change the ldap object's verify status from none to require, the software dies during connection establishment. Has anyone had a similar problem? If so, how did you resolve it? perl-5.6.1 perl-ldap-0.23 IO-Socket-SSL-0.79 Crypt-SSLeay-0.27 Net_SSLeay-1.07 Regards, Christian ----------------- Christian Gilmore Infrastructure & Tools Team Lead Web & Multimedia Development IBM Software Group |
|
From: Christian G. <cgi...@ti...> - 2001-06-20 21:59:34
|
I've successfully queried an SSL-enabled LDAPv3 service with Net::LDAPS, but the software continually dies when I attempt to verify the CA certificate. I have followed the instructions for creating the hash-valued symlink to the CA cert file. ----------------- Christian Gilmore Infrastructure & Tools Team Lead Web & Multimedia Development IBM Software Group |
|
From: Chris C. <ch...@ka...> - 2001-06-19 20:24:35
|
Have a good time Graham, and send us a post card ! Chris... ---------- Forwarded Message ---------- Subject: Re: BOF at O'Reilly Open Source Convention Date: Tue, 19 Jun 2001 20:50:14 +0100 From: Graham Barr <gb...@po...> To: Clif Harden <c-h...@ti...> And I will be there Graham. |
|
From: Graham B. <gb...@po...> - 2001-06-19 19:51:58
|
And I will be there Graham. On Tue, Jun 19, 2001 at 02:47:42PM -0500, Clif Harden wrote: > > This is to let everyone on the list know that we have BOF > scheduled for upcoming O'Reilly Open Source Convention in > San Diego CA. > > Our BOF session currently does not show up on the > O'Reilly Open Source Convention BOF page, it will take a couple > of days for it to be posted. > > Here are the details. > > Date: Monday, July 23 > Time: 6-8 pm > Location: Harbor Island I (East Tower) > Topic: Perl - LDAP > Moderator: Clif Harden, Texas Instruments > Summary: Perl-LDAP is used to access LDAP directory services. We > are going to discuss current and future directions for this perl module. > > Regards, > > Clif Harden > > |
|
From: Clif H. <cl...@di...> - 2001-06-19 19:47:50
|
This is to let everyone on the list know that we have BOF scheduled for upcoming O'Reilly Open Source Convention in San Diego CA. Our BOF session currently does not show up on the O'Reilly Open Source Convention BOF page, it will take a couple of days for it to be posted. Here are the details. Date: Monday, July 23 Time: 6-8 pm Location: Harbor Island I (East Tower) Topic: Perl - LDAP Moderator: Clif Harden, Texas Instruments Summary: Perl-LDAP is used to access LDAP directory services. We are going to discuss current and future directions for this perl module. Regards, Clif Harden |
|
From: Clif H. <cl...@di...> - 2001-06-19 19:12:17
|
This is to let everyone on the list know that we have BOF scheduled for upcoming O'Reilly Open Source Convention in San Diego CA. Our BOF session currently does not show up on the O'Reilly Open Source Convention BOF page, it will take a couple of days for it to be posted. Here are the details. Date: Monday, July 23 Time: 6-8 pm Location: Harbor Island I (East Tower) Topic: Perl - LDAP Moderator: Clif Harden, Texas Instruments Summary: Perl-LDAP is used to access LDAP directory services. We are going to discuss current and future directions for this perl module. Regards, Clif Harden |
|
From: Graham B. <gb...@po...> - 2001-06-19 15:52:41
|
On Tue, Jun 19, 2001 at 11:03:05AM +0200, R. Reucher wrote: > I'll try your other hint (Convert::EBCDIC). But it will only simplify > the conversion itself, I still have to find the places where I have to > convert. I'll let you know my results. I would appreciate that. It's something that would be a good idea to have in the documentation (or FAQ) Graham. |
|
From: Chris R. <chr...@me...> - 2001-06-19 09:42:01
|
"R. Reucher" <ren...@cp...> wrote: > Chris Ridd wrote: > >> >> So basically everything that you pass into Net::LDAP objects *must* be >> >> ASCII or UTF-8 (if you are using LDAPv3.) >> > I know that. The question is, _where_ excatly do I need to convert >> > (back and forth) ? >> >> I think I said - every value you pass into Net::LDAP from your program >> and every value you get out again. Since Net::LDAP doesn't mess around >> with values at all, the bytes you pass in should ultimately end up 'on >> the wire'. > Ah... sorry for my "ignorance". > > So - when I understand you correctly - all I have to do is to pass > EBCDIC converted strings to every Net::LDAP subroutine (like bind, > search etc.) instead of their ASCII counterparts... correct ? Yes. > And the way back is to convert to EBCDIC as soon as I want to _work_ > with the results on the 390 system. also correct ? Yes. >> > 5: password => 'xxxxxxxx'); >> >> That's tricky. The password syntax is OCTET STRING, which means 'just the >> bytes, no character set is implied' so whatever the directory server >> thinks the bytes are is needed here. > Hmmmm... I should perhaps try an anonymous bind at first. That's a good idea. The lack of a character set for passwords is a bit of a tricky problem in the standards. I'm not sure what the fix is - avoid using passwords and use something like certificates, I guess. Good luck! Cheers, Chris |
|
From: R. R. <ren...@cp...> - 2001-06-19 09:32:17
|
Chris Ridd wrote:
> >> So basically everything that you pass into Net::LDAP objects *must* be
> >> ASCII or UTF-8 (if you are using LDAPv3.)
> > I know that. The question is, _where_ excatly do I need to convert (back
> > and forth) ?
>
> I think I said - every value you pass into Net::LDAP from your program and
> every value you get out again. Since Net::LDAP doesn't mess around with
> values at all, the bytes you pass in should ultimately end up 'on the wire'.
Ah... sorry for my "ignorance".
So - when I understand you correctly - all I have to do is to pass
EBCDIC converted strings to every Net::LDAP subroutine (like bind,
search etc.) instead of their ASCII counterparts... correct ?
And the way back is to convert to EBCDIC as soon as I want to _work_
with the results on the 390 system. also correct ?
> >> I really don't know anything at all about perl on the 390, so this might
> >> be a stupid question: what character set is used in the variables in your
> >> program?
> > It's EBCDIC, which (in more "standardized" form) is "IBM-1047" (as
> > opposed to "ISO8859-1", which is ASCII).
>
> ISO 8859-1 is not ASCII. There is an overlap, but ASCII is only a 7-bit
> character set and Latin-1 defines 8-bit characters.
Ok.
> But I guess your ISO 8859-1 converter will convert ASCII values correctly,
> since ISO 8859-1 is mostly a superset of ASCII.
I think so as well.
> >From your original message to Graham:
> > 1: #!/usr/local/bin/perl
> > 2: use Net::LDAP;
> > 3: $ldap = Net::LDAP->new('ldapsrv.ourdomain.com') or die "$@";
>
> Add debug => 12 after the hostname to get protocol debugging. This may help
> us a lot. Maybe debug => 3 is more useful, as it gives us plain hex.
Will do that ! Thanks for the tip...
> > 4: $ldap->bind(dn => 'cn=Directory Manager, o=OurCustomer',
>
> That dn will need to be converted into ASCII.
Yep, I think I understand now...
> > 5: password => 'xxxxxxxx');
>
> That's tricky. The password syntax is OCTET STRING, which means 'just the
> bytes, no character set is implied' so whatever the directory server thinks
> the bytes are is needed here.
Hmmmm... I should perhaps try an anonymous bind at first.
> > 6: $mesg = $ldap->search(base => "o=OurCustomer",
>
> That search base needs changing to ASCII.
> > 7: filter => "(uid=*)");
>
> That filter needs changing to ASCII.
>
> > 8: $ldap->unbind;
> > 9: $mesg->code && die $mesg->error;
> > 10: foreach $entry ($mesg->all_entries) { $entry->dump; }
>
> For testing, the dump() method's OK but for real use you'll need to convert
> all the values you get back from ASCII into EBCDIC.
Yes, of course !
> I'm guessing that you will want to use umlauts etc in your directory, in
> which case I would strongly recommend using LDAPv3 if possible - you need
> to explicitly request this in the bind operation - as then all values are
> UTF-8.
>
> You should do that because many LDAP servers handle character sets wrongly
> (more importantly, differently) when using LDAPv2, so your code will then
> not depend on the possibly non-standard behaviour of a particular LDAP
> server.
>
> (So whereever I said ASCII above, I mean UTF-8.)
Ok, thanks for all the infos !
I'll keep you informed...
Regards,
Rene
--
R. Reucher voice: +49/621/4803-174
COMPAREX GmbH, VL40 fax: +49/621/4803-141
Mannheimerstr. 105 e-mail: ren...@cp...
D-68535 Edingen-Neckarhausen
|
|
From: Chris R. <chr...@me...> - 2001-06-19 09:22:10
|
Graham Barr <gb...@po...> wrote: > On Tue, Jun 19, 2001 at 09:29:45AM +0100, Chris Ridd wrote: >> (Graham, Convert::ASN1's 'make test' should test that strings are being >> encoded using the correct character sets. Testing "PrintableString" would >> be a good start.) > > I am surprised that some of the tests don't already fail, as they assume > ASCII already. > > Graham. You're right, some do. Cheers, Chris |
|
From: Chris R. <chr...@me...> - 2001-06-19 09:15:37
|
"R. Reucher" <ren...@cp...> wrote:
> I subscribed to list meanwhile, no need to CC to me...
OK!
> Chris Ridd wrote:
>> One point you might need to consider is that many of the underlying
>> string types used in BER (which is the ISO standard that describes how
>> to encode the LDAP protocol for network transmission) are fundamentally
>> ASCII-based. If you mess with that, you've broken LDAP and won't be able
>> to talk to any LDAP servers :-(
> Correct, and that's part of the problem already ;-(...
>
>> (Graham, Convert::ASN1's 'make test' should test that strings are being
>> encoded using the correct character sets. Testing "PrintableString" would
>> be a good start.)
When happens when you run this code as is, and when you translate the
'cn=Chris Ridd' :-) string into ASCII:
---8<---
use strict;
use Convert::ASN1;
use Convert::ASN1::Debug;
my $asn = Convert::ASN1->new;
$asn->prepare(q<
name PrintableString
>);
my $pdu = $asn->encode(name => 'cn=Chris Ridd');
if ($pdu ne "\x13\x0D\x63\x6E\x3D\x43\x68\x72\x69\x73\x20\x52\x69\x64\x64")
{
print "The value you set for name uses the wrong character set.\n";
}
my $o = $asn->decode($pdu);
Convert::ASN1::asn_hexdump(*STDERR, $pdu);
---8<---
>> So basically everything that you pass into Net::LDAP objects *must* be
>> ASCII or UTF-8 (if you are using LDAPv3.)
> I know that. The question is, _where_ excatly do I need to convert (back
> and forth) ?
I think I said - every value you pass into Net::LDAP from your program and
every value you get out again. Since Net::LDAP doesn't mess around with
values at all, the bytes you pass in should ultimately end up 'on the wire'.
>> I really don't know anything at all about perl on the 390, so this might
>> be a stupid question: what character set is used in the variables in your
>> program?
> It's EBCDIC, which (in more "standardized" form) is "IBM-1047" (as
> opposed to "ISO8859-1", which is ASCII).
ISO 8859-1 is not ASCII. There is an overlap, but ASCII is only a 7-bit
character set and Latin-1 defines 8-bit characters.
But I guess your ISO 8859-1 converter will convert ASCII values correctly,
since ISO 8859-1 is mostly a superset of ASCII.
Is using single-quoted strings different from double-quoted strings?
>> If they're EBCDIC, you *need* to ASCII-ify (or UTF-8-ify) them first.
>> Similarly, you *need* to EBCDIC-ify all values that come back from the
>> LDAP server, as they are either ASCII-based or UTF-8 (if you are using
>> LDAPv3)
> That's what I want to do (or tried to do) using "iconv"...
>
> Here's what I did to convert:
>
> $ascii_data = `echo '$ebcdic_data' | iconv -f IBM-1047 -t ISO8859-1`
>
> or
>
> $ebcdic_data = `echo '$ascii_data' | iconv -f ISO8859-1 -t IBM-1047`
>
> There's also a C API iconv() routine (UNIX98), but that's trickier to
> use in perl... and it should make no difference, basically.
>
> The problem is, I'm searching for the correct portions of code within
> the Net::LDAP module _where_ I should convert _what_ !?!
From your original message to Graham:
> 1: #!/usr/local/bin/perl
> 2: use Net::LDAP;
> 3: $ldap = Net::LDAP->new('ldapsrv.ourdomain.com') or die "$@";
Add debug => 12 after the hostname to get protocol debugging. This may help
us a lot. Maybe debug => 3 is more useful, as it gives us plain hex.
> 4: $ldap->bind(dn => 'cn=Directory Manager, o=OurCustomer',
That dn will need to be converted into ASCII.
> 5: password => 'xxxxxxxx');
That's tricky. The password syntax is OCTET STRING, which means 'just the
bytes, no character set is implied' so whatever the directory server thinks
the bytes are is needed here.
> 6: $mesg = $ldap->search(base => "o=OurCustomer",
That search base needs changing to ASCII.
> 7: filter => "(uid=*)");
That filter needs changing to ASCII.
> 8: $ldap->unbind;
> 9: $mesg->code && die $mesg->error;
> 10: foreach $entry ($mesg->all_entries) { $entry->dump; }
For testing, the dump() method's OK but for real use you'll need to convert
all the values you get back from ASCII into EBCDIC.
> Anyhow, thanks for the answer ! Hope I'll get more input...
>
> Rene
> --
> R. Reucher voice: +49/621/4803-174
> COMPAREX GmbH, VL40 fax: +49/621/4803-141
> Mannheimerstr. 105 e-mail: ren...@cp...
> D-68535 Edingen-Neckarhausen
>
I'm guessing that you will want to use umlauts etc in your directory, in
which case I would strongly recommend using LDAPv3 if possible - you need
to explicitly request this in the bind operation - as then all values are
UTF-8.
You should do that because many LDAP servers handle character sets wrongly
(more importantly, differently) when using LDAPv2, so your code will then
not depend on the possibly non-standard behaviour of a particular LDAP
server.
(So whereever I said ASCII above, I mean UTF-8.)
Cheers,
Chris
|
|
From: R. R. <ren...@cp...> - 2001-06-19 09:03:34
|
Graham Barr wrote: > > On Tue, Jun 19, 2001 at 09:29:45AM +0100, Chris Ridd wrote: > > (Graham, Convert::ASN1's 'make test' should test that strings are being > > encoded using the correct character sets. Testing "PrintableString" would > > be a good start.) > > I am surprised that some of the tests don't already fail, as they assume > ASCII already. Sorry, missed that. They partially fail ;-(... I'll try your other hint (Convert::EBCDIC). But it will only simplify the conversion itself, I still have to find the places where I have to convert. I'll let you know my results. Rene -- R. Reucher voice: +49/621/4803-174 COMPAREX GmbH, VL40 fax: +49/621/4803-141 Mannheimerstr. 105 e-mail: ren...@cp... D-68535 Edingen-Neckarhausen |
|
From: Graham B. <gb...@po...> - 2001-06-19 08:58:21
|
On Tue, Jun 19, 2001 at 09:29:45AM +0100, Chris Ridd wrote: > (Graham, Convert::ASN1's 'make test' should test that strings are being > encoded using the correct character sets. Testing "PrintableString" would > be a good start.) I am surprised that some of the tests don't already fail, as they assume ASCII already. Graham. |
|
From: Graham B. <gb...@po...> - 2001-06-19 08:55:15
|
On Tue, Jun 19, 2001 at 10:44:47AM +0200, R. Reucher wrote: > Here's what I did to convert: > > $ascii_data = `echo '$ebcdic_data' | iconv -f IBM-1047 -t ISO8859-1` > > or > > $ebcdic_data = `echo '$ascii_data' | iconv -f ISO8859-1 -t IBM-1047` You may want to install Convert::EBCDIC See http://search.cpan.org/search?dist=Convert-EBCDIC > The problem is, I'm searching for the correct portions of code within > the Net::LDAP module _where_ I should convert _what_ !?! I am not sure we can do it all inside Net::LDAP. This is because Net::LDAP does not know what the value of an attribute holds. However there probably places where it can help, for example filter strings and attribute names. But everything else would need to be converted by the application as needed Graham. |
|
From: R. R. <ren...@cp...> - 2001-06-19 08:45:13
|
I subscribed to list meanwhile, no need to CC to me... Chris Ridd wrote: > One point you might need to consider is that many of the underlying string > types used in BER (which is the ISO standard that describes how to encode > the LDAP protocol for network transmission) are fundamentally ASCII-based. > If you mess with that, you've broken LDAP and won't be able to talk to any > LDAP servers :-( Correct, and that's part of the problem already ;-(... > (Graham, Convert::ASN1's 'make test' should test that strings are being > encoded using the correct character sets. Testing "PrintableString" would > be a good start.) > > So basically everything that you pass into Net::LDAP objects *must* be > ASCII or UTF-8 (if you are using LDAPv3.) I know that. The question is, _where_ excatly do I need to convert (back and forth) ? > I really don't know anything at all about perl on the 390, so this might be > a stupid question: what character set is used in the variables in your > program? It's EBCDIC, which (in more "standardized" form) is "IBM-1047" (as opposed to "ISO8859-1", which is ASCII). > If they're EBCDIC, you *need* to ASCII-ify (or UTF-8-ify) them first. > Similarly, you *need* to EBCDIC-ify all values that come back from the LDAP > server, as they are either ASCII-based or UTF-8 (if you are using LDAPv3) That's what I want to do (or tried to do) using "iconv"... Here's what I did to convert: $ascii_data = `echo '$ebcdic_data' | iconv -f IBM-1047 -t ISO8859-1` or $ebcdic_data = `echo '$ascii_data' | iconv -f ISO8859-1 -t IBM-1047` There's also a C API iconv() routine (UNIX98), but that's trickier to use in perl... and it should make no difference, basically. The problem is, I'm searching for the correct portions of code within the Net::LDAP module _where_ I should convert _what_ !?! Anyhow, thanks for the answer ! Hope I'll get more input... Rene -- R. Reucher voice: +49/621/4803-174 COMPAREX GmbH, VL40 fax: +49/621/4803-141 Mannheimerstr. 105 e-mail: ren...@cp... D-68535 Edingen-Neckarhausen |
|
From: Chris R. <chr...@me...> - 2001-06-19 08:29:57
|
Graham Barr <gb...@po...> wrote:
> ----- Forwarded message from "R. Reucher" <ren...@cp...> -----
>
> Date: Tue, 19 Jun 2001 08:45:11 +0200
> To: gb...@po...
> From: "R. Reucher" <ren...@cp...>
> Subject: perl-ldap on OS/390 ?!
> X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3 i686)
>
> Hello Graham,
>
> I don't know who is the right person to contact (within the project), so
> I'm contacting you...
>
> I'm trying to get your Perl LDAP module (0.23) working under OS/390 (the
> "UNIX" side), but am having some serious trouble. I suspect it's caused
> due to missing EBCDIC <-> ASCII conversion (as OS/390 is a pure EBCDIC
> platform). I've written a short perl script to test perl-ldap (taken
> from the Net::LDAP man page); it works fine under Linux (i386), but
> fails with "No such object" on line 9 under OS/390:
>
> 1: #!/usr/local/bin/perl
> 2: use Net::LDAP;
> 3: $ldap = Net::LDAP->new('ldapsrv.ourdomain.com') or die "$@";
> 4: $ldap->bind(dn => 'cn=Directory Manager, o=OurCustomer',
> 5: password => 'xxxxxxxx');
> 6: $mesg = $ldap->search(base => "o=OurCustomer",
> 7: filter => "(uid=*)");
> 8: $ldap->unbind;
> 9: $mesg->code && die $mesg->error;
> 10: foreach $entry ($mesg->all_entries) { $entry->dump; }
>
> Note that I have to use perl 5.005p03, because that's the latest stable
> version with EBCDIC support (5.6.x doesn't support it, 5.7.x is beta -
> as I need the LDAP support for a serious project for one of our
> customers, I decided to use the "stable" version).
>
> I already tried several things to convert the ASCII data to EBCDIC
> (using the iconv utility) without success. What do you think: which data
> needs to be converted at which point(s) ?
>
> Or is there any experience using perl-ldap under OS/390 already ?
>
> Would perl 5.7.x help in some way ?
>
> Sorry for all these questions, but I definitely need some help here. I'd
> appreciate any hints or advises, thanks in advance !
>
> Regards,
>
> Rene
> --
> R. Reucher voice: +49/621/4803-174
> COMPAREX GmbH, VL40 fax: +49/621/4803-141
> Mannheimerstr. 105 e-mail: ren...@cp...
> D-68535 Edingen-Neckarhausen
>
>
> ----- End forwarded message -----
>
One point you might need to consider is that many of the underlying string
types used in BER (which is the ISO standard that describes how to encode
the LDAP protocol for network transmission) are fundamentally ASCII-based.
If you mess with that, you've broken LDAP and won't be able to talk to any
LDAP servers :-(
(Graham, Convert::ASN1's 'make test' should test that strings are being
encoded using the correct character sets. Testing "PrintableString" would
be a good start.)
So basically everything that you pass into Net::LDAP objects *must* be
ASCII or UTF-8 (if you are using LDAPv3.)
I really don't know anything at all about perl on the 390, so this might be
a stupid question: what character set is used in the variables in your
program?
If they're EBCDIC, you *need* to ASCII-ify (or UTF-8-ify) them first.
Similarly, you *need* to EBCDIC-ify all values that come back from the LDAP
server, as they are either ASCII-based or UTF-8 (if you are using LDAPv3)
Cheers,
Chris
|
|
From: Chris R. <chr...@me...> - 2001-06-19 08:13:06
|
fh...@ts... wrote:
> faster. Net::LDAP outperformed PerLDAP. In the case of multiple entries
> though, the native methods were slower in both Net::LDAP and Mozilla.
It's interesting that pure perl is beating the mixed C & perl of perLDAP.
I don't know what these "native methods" are - are you calling something
like the ldapsearch program? More to the point, are you calling something
that talks (LDAP) protocol to get to the directory, or something that reads
from the databases directly?
If you're reading the databases directly then there's nothing that is going
to beat that, but if you're using protocol then Net::LDAP stands a chance...
> While mod_perl is not an option for me at this time. Are there other ways
> to optimize searches which could improve performance?
Net::LDAP uses a *lot* of memory when it receives large numbers of search
results. This might be slowing Net::LDAP down a lot.
One way to avoid this is to set a callback in the search method (ie
$ldap->search(..., callback => \&search_result_handler)) and in your sub
search_result_handler do something with the search result and arrange for
Net::LDAP not to keep hold of it. Something like this:
sub search_result_handler {
my ($mesg, $e) = @_;
if ($e && $e->isa('Net::LDAP::Entry')) {
# Do something with the entry in $e
$mesg->pop_entry; # See Net::LDAP::Search for details
}
# Could also get Net::LDAP::Reference objects
}
Does using callbacks help improve performance at all?
> Fred Hirsch
> Toronto Stock Exchange
>
>
Cheers,
Chris
|
|
From: Graham B. <gb...@po...> - 2001-06-19 06:49:40
|
----- Forwarded message from "R. Reucher" <ren...@cp...> -----
Date: Tue, 19 Jun 2001 08:45:11 +0200
To: gb...@po...
From: "R. Reucher" <ren...@cp...>
Subject: perl-ldap on OS/390 ?!
X-Mailer: Mozilla 4.77 [en] (X11; U; Linux 2.4.3 i686)
Hello Graham,
I don't know who is the right person to contact (within the project), so
I'm contacting you...
I'm trying to get your Perl LDAP module (0.23) working under OS/390 (the
"UNIX" side), but am having some serious trouble. I suspect it's caused
due to missing EBCDIC <-> ASCII conversion (as OS/390 is a pure EBCDIC
platform). I've written a short perl script to test perl-ldap (taken
from the Net::LDAP man page); it works fine under Linux (i386), but
fails with "No such object" on line 9 under OS/390:
1: #!/usr/local/bin/perl
2: use Net::LDAP;
3: $ldap = Net::LDAP->new('ldapsrv.ourdomain.com') or die "$@";
4: $ldap->bind(dn => 'cn=Directory Manager, o=OurCustomer',
5: password => 'xxxxxxxx');
6: $mesg = $ldap->search(base => "o=OurCustomer",
7: filter => "(uid=*)");
8: $ldap->unbind;
9: $mesg->code && die $mesg->error;
10: foreach $entry ($mesg->all_entries) { $entry->dump; }
Note that I have to use perl 5.005p03, because that's the latest stable
version with EBCDIC support (5.6.x doesn't support it, 5.7.x is beta -
as I need the LDAP support for a serious project for one of our
customers, I decided to use the "stable" version).
I already tried several things to convert the ASCII data to EBCDIC
(using the iconv utility) without success. What do you think: which data
needs to be converted at which point(s) ?
Or is there any experience using perl-ldap under OS/390 already ?
Would perl 5.7.x help in some way ?
Sorry for all these questions, but I definitely need some help here. I'd
appreciate any hints or advises, thanks in advance !
Regards,
Rene
--
R. Reucher voice: +49/621/4803-174
COMPAREX GmbH, VL40 fax: +49/621/4803-141
Mannheimerstr. 105 e-mail: ren...@cp...
D-68535 Edingen-Neckarhausen
----- End forwarded message -----
|
7902 messages has been excluded from this view by a project administrator.
