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: Kurt D. Z. <Ku...@Op...> - 2000-05-30 20:45:29
|
At 03:28 PM 5/30/00 -0500, Mark Wilcox wrote: >There is not a standard group object in LDAP, thus >they could be using something else. The 2 groups I picked are essentially >the de-facto standards, appearing in Netscape & openLDAP (which is derived >from UMich). Actually, groupOfNames and groupOfUniqueNames are both described by RFC 2256, which is an Internet "Proposed Standard" (like the rest of LDAPv3). Both of these object classes are derived from ITU X.500 series of recommendations. Kurt |
From: Mark W. <mew...@un...> - 2000-05-30 20:30:15
|
A couple of things to check. 1) make sure that you're binded as a user who can read group memberships 2) make sure that Novell uses either groupOfUniqueNames or groupOfNames as their group object. I've never used Novell LDAP server so I have no idea what they are using. There is not a standard group object in LDAP, thus they could be using something else. The 2 groups I picked are essentially the de-facto standards, appearing in Netscape & openLDAP (which is derived from UMich). If you can send me a sample LDIF of a group, I'll be happy to update my script to accomodate Novell if it does something else. Mark |
From: <Sim...@wi...> - 2000-05-30 20:22:51
|
Hi all, Having sorted out my binding problem (see previous posts, thanks to everyone for their help !), I now need to establish if my user is a member of a group. I've used Mark's ismember.pl script (from the distribution) but it always says that a user is not a member of a group, even when it is. Using the printmembers.pl script, I don't get any results. Looking at the trace on the server, the only result returned is the dn of the group itself. Question - Do I need to query in any unusual way to get the response I'm expecting ? I am using Perl 5.6.0, Net::LDAP 0.18 & Convert::ASN1 0.06 against a Novell NDS8 for NT server. Rgds, Simon Wilcox For the record, the server trace looks like this: *** NDS Trace Utility - BEGIN Logging *** Tue May 30 21:19:12 2000 LDAP: select activity LDAP: Accepting TCP connection LDAP: Starting new monitor thread LDAP: new connection on 0x5342af8 LDAP: Monitor thread 0x7d4 started LDAP: listening for activity in monitor thread 0x7d4 on: LDAP: 0x5342dd0r LDAP: 0x5342af8r LDAP: before select in monitor thread 0x7d4, active_threads 0 LDAP: select activity in monitor thread 0x7d4 LDAP: read activity on 0x5342dd0 LDAP: listening for activity in monitor thread 0x7d4 on: LDAP: 0x5342dd0r LDAP: 0x5342af8r LDAP: before select in monitor thread 0x7d4, active_threads 0 LDAP: select activity in monitor thread 0x7d4 LDAP: read activity on 0x5342af8 LDAP: listening for activity in monitor thread 0x7d4 on: LDAP: 0x5342dd0r LDAP: 0x5342af8r LDAP: before select in monitor thread 0x7d4, active_threads 1 LDAP: do_bind LDAP: bind: protocol version 2 dn () method 128 LDAP: accepting NULL bind LDAP: send_ldap_result 0:: LDAP: select activity in monitor thread 0x7d4 LDAP: read activity on 0x5342af8 LDAP: listening for activity in monitor thread 0x7d4 on: LDAP: 0x5342dd0r LDAP: 0x5342af8r LDAP: before select in monitor thread 0x7d4, active_threads 1 LDAP: do_search LDAP: SRCH base "o=wl" scope 2 deref 2 LDAP: sizelimit 0 timelimit 0 attrsonly 0 LDAP: begin get_filter LDAP: AND LDAP: begin get_filter_list LDAP: begin get_filter LDAP: EQUALITY LDAP: begin get_filter LDAP: EQUALITY LDAP: filter: (&(cn=permstaff)(objectclass=groupOfUniqueNames)) LDAP: attrs: LDAP: dn LDAP: => send_search_entry (cn=PermStaff,ou=Groups,o=wl) LDAP: send_ldap_result 0:: LDAP: select activity in monitor thread 0x7d4 LDAP: read activity on 0x5342af8 LDAP: listening for activity in monitor thread 0x7d4 on: LDAP: 0x5342dd0r LDAP: 0x5342af8r LDAP: before select in monitor thread 0x7d4, active_threads 1 LDAP: do_search LDAP: SRCH base "cn=PermStaff,ou=Groups,o=wl" scope 0 deref 2 LDAP: sizelimit 0 timelimit 0 attrsonly 0 LDAP: begin get_filter LDAP: PRESENT LDAP: filter: (objectclass=*) LDAP: attrs: LDAP: uniquemember LDAP: memberurl LDAP: Undefined LDAP attribute "memberurl" LDAP: => send_search_entry (cn=PermStaff,ou=Groups,o=wl) LDAP: send_ldap_result 0:: LDAP: select activity in monitor thread 0x7d4 LDAP: read activity on 0x5342af8 LDAP: listening for activity in monitor thread 0x7d4 on: LDAP: 0x5342dd0r LDAP: 0x5342af8r LDAP: before select in monitor thread 0x7d4, active_threads 1 LDAP: do_unbind LDAP: select activity in monitor thread 0x7d4 LDAP: read activity on 0x5342dd0 LDAP: listening for activity in monitor thread 0x7d4 on: LDAP: 0x5342dd0r LDAP: close conn in close_connection 0x56ab9cc on skt 0x5342af8 from opid -1 LDAP: called by "monitor_thread7" LDAP: freeing conn 0x56ab9cc at index 1 in monitor thread 0x584f008 LDAP: before select in monitor thread 0x7d4, active_threads 0 *** NDS Trace Utility - END Logging *** Tue May 30 21:19:20 2000 |
From: Chris R. <Chr...@me...> - 2000-05-30 16:13:31
|
On Tue, 30 May 2000 16:43:49 BST, Rui Monteiro wrote: > The patch woks perfectly. Thanks Graham. > > I can now rename DN's but i cannot move the to another branch on LDAP tree. > The server tells me it does not support moving of entries. > As i'm working with with LDAPV3, i should be able to move DN's, right ? > > Configuration: > Netscape Directory Server 4.1. > perl 5.005_3 > perl-ldap-0.18 No, not necessarily. RFC 2251 says that clients must not expect to be able to perform arbitrary movements of entries and subtrees between servers. NS simply might not be able to implement the newSuperior part of ModifyDNRequest, which is a not uncommon characteristic of directory servers. The way you avoid this problem is you read the entry from the original DN, and you simply add it with the new DN. (Then delete the old entry.) Cheers, Chris |
From: Rui M. <rmo...@wh...> - 2000-05-30 15:42:43
|
The patch woks perfectly. Thanks Graham. I can now rename DN's but i cannot move the to another branch on LDAP tree. The server tells me it does not support moving of entries. As i'm working with with LDAPV3, i should be able to move DN's, right ? Configuration: Netscape Directory Server 4.1. perl 5.005_3 perl-ldap-0.18 Graham Barr wrote: > A bug in Convert::ASN1 was masking an error in Net::LDAP, > > Here is a patch for Net::LDAP, a new release of Convert::ASN > will be released soon. > > Graham. > > ------------------------------------------------------------------------ > > moddn.patchName: moddn.patch > Type: Plain Text (text/plain) -- Rui Monteiro WhatEverNet Computing, SA rmo...@wh... Praca de Alvalade, 6 - Piso 6 Phone: +351 21 7994200 1700 036 Lisboa - Portugal Fax: +351 21 7994242 http://www.whatevernet.pt |
From: Graham B. <gb...@po...> - 2000-05-30 11:22:08
|
A bug in Convert::ASN1 was masking an error in Net::LDAP, Here is a patch for Net::LDAP, a new release of Convert::ASN will be released soon. Graham. |
From: Graham B. <gb...@po...> - 2000-05-30 08:57:40
|
On Mon, May 29, 2000 at 03:35:13PM +0100, Rui Monteiro wrote: > Hi all. > > I'm trying to use moddn to modify a dn entry, but all i get is an error > from ldap server: > LDAP_OPERATIONS_ERROR. Server encountered an internal error. > > I also tried with the script that comes with perl-ldap package > (ldapmodrdn) with no success. > > Net::LDAP=HASH(0xe08b8) sending: > > 30 03 02 01 02 __ __ __ __ __ __ __ __ __ __ __ 0.... That does not seem to be sending much does it ? I suspect this is a bug in Net::LDAP, I will look into it. Graham. |
From: Graham B. <gb...@po...> - 2000-05-30 08:54:44
|
Can you post some example code so we can see exactly what you are trying to describe. Graham. On Sun, May 28, 2000 at 05:29:12PM -0500, Chris Reahard wrote: > Just out of curiosity, is there anything special ya'll might know about > that would cause the Perl LDAP module to flip-out when trying to use arrays > in the modify method while talking to a version 2 LDAP tree? I can use hashes > all day long, but the second I try it with an array it gives me an error code > 2 (incorrect version number or incorrect PDU structure). I'm using OpenLDAP > 1.2.7 and my array is in the form of ('key', 'value'). The main problem is I > want to have multiple entries of the same key, and of course a hash would > "kindly" trunicate me down to one. > Also, I'm using perl 5.6.0 and perl-ldap 0.17 > > Thanks > -- > Chris > |
From: Mark W. <mew...@un...> - 2000-05-30 03:27:46
|
Hi, Here's an update that uses callbacks for processing. It also takes either a file name or an open file handle for writing. Mark |
From: Rui M. <rmo...@wh...> - 2000-05-29 16:19:36
|
Next is the code from the post "moddn bug ???": #!/usr/local/bin/perl use Net::LDAP qw(:all); # use for all code use Net::LDAP::Util qw(ldap_error_name ldap_error_text) ; # use for Error handling $ldap = Net::LDAP->new("ldapserver",debug => 3) or die "$@"; $mesg = $ldap->bind("cn=admin", password => "admin5admin", version => 3 ); # use for changes/edits my $newRDN = "cn=xxx"; my $dn = "cn=vhost1,ou=teste,o=whatevernet,c=pt"; my $result = $ldap->moddn($dn, newrdn => $newRDN, deleteoldrdn => '1' ); printf( "Code: %s, Error name: %s, Error text: %s\n", $result -> code, ldap_error_name( $result -> code ), ldap_error_text( $result -> code ) ); $ldap -> unbind; -- Rui Monteiro WhatEverNet Computing, SA rmo...@wh... Praca de Alvalade, 6 - Piso 6 Phone: +351 21 7994200 1700 036 Lisboa - Portugal Fax: +351 21 7994242 http://www.whatevernet.pt |
From: Rui M. <rmo...@wh...> - 2000-05-29 14:33:56
|
Hi all. I'm trying to use moddn to modify a dn entry, but all i get is an error from ldap server: LDAP_OPERATIONS_ERROR. Server encountered an internal error. I also tried with the script that comes with perl-ldap package (ldapmodrdn) with no success. The lines from ldap server access log: [29/May/2000:15:22:38 +0100] conn=47 fd=49 slot=49 connection from 192.168.1.10 to 192.168.1.11 [29/May/2000:15:22:38 +0100] conn=47 op=0 BIND dn="cn=admin" method=128 version=3 [29/May/2000:15:22:38 +0100] conn=47 op=0 RESULT err=0 tag=97 nentries=0 etime=0 [29/May/2000:15:22:38 +0100] conn=47 op=-1 fd=49 closed error 71 (Protocol error) - B3 <--- ?!?!?! The output of ldapmodrdn with debug level set to 3 is: Net::LDAP=HASH(0xe08b8) sending: 30 1F 02 01 01 60 1A 02 01 03 04 08 63 6E 3D 61 0....`......cn=a 64 6D 69 6E 80 0B 61 64 6D 69 6E 35 61 64 6D 69 dmin..admin5admi 6E __ __ __ __ __ __ __ __ __ __ __ __ __ __ __ n Net::LDAP=HASH(0xe08b8) received: 30 0C 02 01 01 61 07 0A 01 00 04 00 04 00 __ __ 0....a........ Net::LDAP=HASH(0xe08b8) sending: 30 03 02 01 02 __ __ __ __ __ __ __ __ __ __ __ 0.... Net::LDAP=HASH(0xe08b8) sending: 30 05 02 01 03 42 00 __ __ __ __ __ __ __ __ __ 0....B. The bind to ldap server was made with LDAPV3; The same test made with perldap-1.4 from mozilla works fine. Configuration: perl LDAP package: perl-ldap-0.18; perl version: 5.005_03 LDAP server: Netscape Directory Server 4.1 Am i doing something wrong or is this a (known) bug ? Any help is welcome. Thanks in advance -- Rui Monteiro WhatEverNet Computing, SA rmo...@wh... Praca de Alvalade, 6 - Piso 6 Phone: +351 21 7994200 1700 036 Lisboa - Portugal Fax: +351 21 7994242 http://www.whatevernet.pt |
From: Gary F. <fl...@jm...> - 2000-05-29 13:53:26
|
David Bussenschutt wrote: > > Setting The Home Directory Attribute in Novell's NDS (and which NDS > properties have to be assigned to LDAP attributes to do it)? > > Setting the new user's password via LDAP? (it's an attribute, but again I > don't know which one, or how to set it!) userPassword attribute. You'll have to supply a cleartext password as Novell doesn't understand crypt, SHA, etc. Ergo, you'll want an SSL connection for use over unsecure networks. Paraphrased from a Novell Technical Information Document dated 6/21/99 "LDAP Password Change Policy for NLDAP v3.10: The userPassword attribute will not appear in any search or compare result. A password change by a user requires an atomic ldapmodify containing both the existing and new passwords. The existing password is included as the value to be deleted (telling the server that the user knows the old password) and the new password is included as the value to be added. An administrator may simply specify the new password. |
From: David B. <D.B...@ma...> - 2000-05-29 03:40:33
|
Hi all, I've successfully populated my NDS with 15000 users (took about 5 minutes to run) ...but a few attributes still elude me.... Setting The Home Directory Attribute in Novell's NDS (and which NDS properties have to be assigned to LDAP attributes to do it)? Setting the new user's password via LDAP? (it's an attribute, but again I don't know which one, or how to set it!) Can anyone Help? 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 -------------------------------------------------------------------- |
From: Pythagoras W. <py...@ec...> - 2000-05-29 03:09:59
|
On Mon, May 29, 2000 at 11:59:45AM +1000, Jason Hellwege wrote: :>This is exactly the same results as I get from using OpenLDAP's :>ldapsearch, so I would say that there is a problem with your LDAP :>server. What server are you using? : :I haven't been able to find out yet, it came with our new PABX system :and was installed by the phone company. I do know that it isn't one :of the usual suspects (Netscape, Innosoft). I wish you luck, an LDAP server that cannot be reliably searched is not much use. :Mark said: :>Jason can you upgrade to NEt::LDAP .18 and send us a copy of :>$ldap->debug(3) (put this after you connect to server but before the bind). : :I've done the upgrade to perl-ldap-0.18 (with Convert-ASN1-0.06), :however the debug code is generating: : syntax error at /usr/local/lib/perl5/site_perl/Convert/ASN1/Debug.pm line 175 In v0.18, line 175 of Debug.pm is: dump_op($_,"",{},1) for @{$self->{script}}; This is definitely syntatically invalid before perl version 5.005, so perhaps you are using an earlier perl. In any case, I note that Graham is shooting for 5.004 and later compliance, and as it happens has already updated the CVS copy of Debug.pm to fix this, which is available at: http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/~checkout~/asn/lib/Convert/ASN1/Debug.pm?rev=1.2&cvsroot=perl-ldap -- Py (Amateur Radio: KF6WFP) -- 3.141592653589793238462643383... Pythagoras Watson -- "Live long and may all your kernels pop." === py...@cs... ==== http://www.ecst.csuchico.edu/~py/ === |
From: Jason H. <web...@la...> - 2000-05-29 02:01:51
|
Mark and Pythagoras - Many thanks for the help! It's now looking as though your suspicions are correct and there's something "odd" about the LDAP server which I'm trying to connect to. Some things want to connect to it, some things don't. I repointed my code to ldap.bigfoot.com and it worked fine, so I at least know that perl-ldap has installed and runs OK on my Digital Unix box. Pythagoras Said: >Perhaps Eudora is not bothering to inform you of a problem, >preferring to not >confuse users instead? Further testing is leading me to agree with this. >This is exactly the same results as I get from using OpenLDAP's >ldapsearch, so I would say that there is a problem with your LDAP >server. What server are you using? I haven't been able to find out yet, it came with our new PABX system and was installed by the phone company. I do know that it isn't one of the usual suspects (Netscape, Innosoft). Mark said: >Jason can you upgrade to NEt::LDAP .18 and send us a copy of >$ldap->debug(3) (put this after you connect to server but before the bind). I've done the upgrade to perl-ldap-0.18 (with Convert-ASN1-0.06), however the debug code is generating: syntax error at /usr/local/lib/perl5/site_perl/Convert/ASN1/Debug.pm line 175 All the Best, Jason -- ___________________________________________________________________________ Jason Hellwege "One can never have too La Trobe University, Melbourne, many giant robots.." Australia. Ja...@la... |
From: Chris R. <cre...@da...> - 2000-05-28 22:31:11
|
Just out of curiosity, is there anything special ya'll might know about that would cause the Perl LDAP module to flip-out when trying to use arrays in the modify method while talking to a version 2 LDAP tree? I can use hashes all day long, but the second I try it with an array it gives me an error code 2 (incorrect version number or incorrect PDU structure). I'm using OpenLDAP 1.2.7 and my array is in the form of ('key', 'value'). The main problem is I want to have multiple entries of the same key, and of course a hash would "kindly" trunicate me down to one. Also, I'm using perl 5.6.0 and perl-ldap 0.17 Thanks -- Chris |
From: Pythagoras W. <py...@ec...> - 2000-05-28 21:00:42
|
On Sun, May 28, 2000 at 03:10:04PM +1000, Jason Hellwege wrote: :- I'm connecting to a new PABX phone database which uses LDAPv2 (I believe). : HOST: pe-pabx-dna.stservices.latrobe.edu.au : BASE: o=Latrobe University, c=AU : LOGIN: Not required :I've been able to query this server using the "Directory Services" :window in Eudora. (Note: "o=Latrobe University" may change to "o=La :Trobe University" soon) Are you really getting ALL the entries that you would expect? My testing below indicates that some entries are returned, but not necessarily all. Perhaps Eudora is not bothering to inform you of a problem, preferring to not confuse users instead? :WHAT HAPPENS: :- When I run simplesearch.pl, I get the error message "failed to bind :with 1", so it's not even getting to make an anonymous bind to the :server. Trying it under Solaris with Net::LDAP version 0.18 and ASN1 version 0.06, I find that the server unceremoniously closes the connection after sending 46 entries with the '(objectclass=*)' filter. This causes an operations error (i.e. a code of 1) to be reported by Net::LDAP. By changing the "die" in the line: die ("search failed with ",$mesg->code(),"\n") if $mesg->code(); to a "warn", I was able to get the 46 entries printed out. This is exactly the same results as I get from using OpenLDAP's ldapsearch, so I would say that there is a problem with your LDAP server. What server are you using? Note that this behavior of the server dropping the connection is not consistent. While the server does drop while searching with a filter of '(title=Mr)' (although after returning 22 entries), the server completes successfully when using a filter of '(organizationalunitname=BOUVERIE FAMILY CENTRE)' which returns 23 entries. -- Py (Amateur Radio: KF6WFP) -- 3.141592653589793238462643383... Pythagoras Watson -- "Live long and may all your kernels pop." === py...@cs... ==== http://www.ecst.csuchico.edu/~py/ === |
From: Mark W. <mew...@un...> - 2000-05-28 17:00:34
|
Hi, I can bind, but the search fails with "protocol error (e.g. error code 1)". I can also verify that the search works fine in Netscape Messenger. I'm using Convert::ASN.1 and Net::LDAP .18 . My NT box at home won't let me capture the output of debug. Jason can you upgrade to NEt::LDAP .18 and send us a copy of $ldap->debug(3) (put this after you connect to server but before the bind). thanks, Mark Jason Hellwege wrote: > Hi, I'm new to LDAP and I'm trying to get a simple search to a new > LDAP server happening and I'm getting nowhere fast. Any help/advice > would be wonderful. > > SITUATION: > - I've installed: perl-ldap-0.16 and Convert-ASN1-0.06 onto a Digital > Unix box running Perl 5.004_04. > > - I'm connecting to a new PABX phone database which uses LDAPv2 (I believe). > HOST: pe-pabx-dna.stservices.latrobe.edu.au > BASE: o=Latrobe University, c=AU > LOGIN: Not required > I've been able to query this server using the "Directory Services" > window in Eudora. (Note: "o=Latrobe University" may change to "o=La > Trobe University" soon) > > - I've grabbed a copy of the "simplesearch.pl" code from Mark > Wilcox's article in PerlMonth to test things out with. > > WHAT HAPPENS: > - When I run simplesearch.pl, I get the error message "failed to bind > with 1", so it's not even getting to make an anonymous bind to the > server. > > WHAT NOW? > - I'm at a loss to know what to try from here. Any suggestions? > (grovel... grovel..) > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > SIMPLESEARCH.PL > > #!/usr/local/bin/perl > use strict; > use Net::LDAP; > > my $host = 'pe-pabx-dna.stservices.latrobe.edu.au'; > my $ldap = new Net::LDAP($host); > > #authenticate to the LDAP server anonymously > my $mesg = $ldap->bind(); > die ("failed to bind with ",$mesg->code(),"\n") if $mesg->code(); > > #now perform a simple search > $mesg = $ldap->search( > base => 'o=Latrobe University, c=AU', > scope => 'sub', > filter => '(objectclass=*)', > ); > > die ("search failed with ",$mesg->code(),"\n") if $mesg->code(); > > #display results and disconnect from the server > while (my $entry = $mesg->shift_entry()) { $entry->dump(); } > $ldap->unbind(); > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > The only other info that I have is that during the install of > Convert-ASN1 "make test" reported some failed tests (and the Unix > admin fella isn't around for me to query about what this means, > sorry): > > t/00prim............FAILED tests 43, 55, 59, 86, 132, 136 > Failed 6/137 tests, 95.62% okay > t/01tag.............ok > t/02seq.............ok > t/03seqof...........ok > t/04opt.............ok > t/07io..............ok > Failed Test Status Wstat Total Fail Failed List of failed > ------------------------------------------------------------------ > t/00prim.t 137 6 4.38% 43, 55, 59, 86, 132, 136 > Failed 1/6 test scripts, 83.33% okay. 6/208 subtests failed, 97.12% okay. > *** Exit 2 > Stop. > > "make test" for the install of perl-ldap-0.16 also reported some failures: > > t/53schema..........Can't emulate - > on #! line at t/53schema.t line 1. > dubious > Test returned status 2 (wstat 512, 0x200) > Failed Test Status Wstat Total Fail Failed List of failed > ------------------------------------------------------------------ > t/53schema.t 2 512 ?? ?? % ?? > Failed 1/7 test scripts, 85.71% okay. 0/143 subtests failed, 100.00% okay. > *** Exit 2 > Stop. > -- > > __________________________________________________________________ > Jason Hellwege J.H...@la... > Webmaster - Information Technology Services > La Trobe University Melbourne, Australia > __________________________________________________________________ |
From: Jason H. <gl...@LU...> - 2000-05-28 05:12:04
|
Hi, I'm new to LDAP and I'm trying to get a simple search to a new LDAP server happening and I'm getting nowhere fast. Any help/advice would be wonderful. SITUATION: - I've installed: perl-ldap-0.16 and Convert-ASN1-0.06 onto a Digital Unix box running Perl 5.004_04. - I'm connecting to a new PABX phone database which uses LDAPv2 (I believe). HOST: pe-pabx-dna.stservices.latrobe.edu.au BASE: o=Latrobe University, c=AU LOGIN: Not required I've been able to query this server using the "Directory Services" window in Eudora. (Note: "o=Latrobe University" may change to "o=La Trobe University" soon) - I've grabbed a copy of the "simplesearch.pl" code from Mark Wilcox's article in PerlMonth to test things out with. WHAT HAPPENS: - When I run simplesearch.pl, I get the error message "failed to bind with 1", so it's not even getting to make an anonymous bind to the server. WHAT NOW? - I'm at a loss to know what to try from here. Any suggestions? (grovel... grovel..) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= SIMPLESEARCH.PL #!/usr/local/bin/perl use strict; use Net::LDAP; my $host = 'pe-pabx-dna.stservices.latrobe.edu.au'; my $ldap = new Net::LDAP($host); #authenticate to the LDAP server anonymously my $mesg = $ldap->bind(); die ("failed to bind with ",$mesg->code(),"\n") if $mesg->code(); #now perform a simple search $mesg = $ldap->search( base => 'o=Latrobe University, c=AU', scope => 'sub', filter => '(objectclass=*)', ); die ("search failed with ",$mesg->code(),"\n") if $mesg->code(); #display results and disconnect from the server while (my $entry = $mesg->shift_entry()) { $entry->dump(); } $ldap->unbind(); =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= The only other info that I have is that during the install of Convert-ASN1 "make test" reported some failed tests (and the Unix admin fella isn't around for me to query about what this means, sorry): t/00prim............FAILED tests 43, 55, 59, 86, 132, 136 Failed 6/137 tests, 95.62% okay t/01tag.............ok t/02seq.............ok t/03seqof...........ok t/04opt.............ok t/07io..............ok Failed Test Status Wstat Total Fail Failed List of failed ------------------------------------------------------------------ t/00prim.t 137 6 4.38% 43, 55, 59, 86, 132, 136 Failed 1/6 test scripts, 83.33% okay. 6/208 subtests failed, 97.12% okay. *** Exit 2 Stop. "make test" for the install of perl-ldap-0.16 also reported some failures: t/53schema..........Can't emulate - on #! line at t/53schema.t line 1. dubious Test returned status 2 (wstat 512, 0x200) Failed Test Status Wstat Total Fail Failed List of failed ------------------------------------------------------------------ t/53schema.t 2 512 ?? ?? % ?? Failed 1/7 test scripts, 85.71% okay. 0/143 subtests failed, 100.00% okay. *** Exit 2 Stop. -- __________________________________________________________________ Jason Hellwege J.H...@la... Webmaster - Information Technology Services La Trobe University Melbourne, Australia __________________________________________________________________ |
From: Graham B. <gb...@po...> - 2000-05-26 19:11:22
|
On Fri, May 26, 2000 at 01:30:00PM -0500, Mark Wilcox wrote: > Hi, > I really like the idea of using IO::File for the filehandle passed to > Net::LDAP::DSML. However, what I need to know is should that file handle > already be open? Or should we open it? > > What about closing it? > > I'm leaning more towards assuming it's open and let the user open & > close. I'd hate to close a socket or pipe on someone. Allow the user to pass either an open handle or a file name. Don't force an IO::* anything either. ie my $file = shift; my $fh; my $close; if (ref($file) or ref(\$file) eq "GLOB") { $close = 0; $fh = $file; } else { local *FH; open(FH,"$file); $close = 1; $fh = \*FH; } ... close($fh) if $close; Graham. |
From: Mark W. <mew...@un...> - 2000-05-26 18:37:19
|
Hi, I really like the idea of using IO::File for the filehandle passed to Net::LDAP::DSML. However, what I need to know is should that file handle already be open? Or should we open it? What about closing it? I'm leaning more towards assuming it's open and let the user open & close. I'd hate to close a socket or pipe on someone. mark |
From: Graham B. <gb...@po...> - 2000-05-26 17:05:49
|
On Fri, May 26, 2000 at 02:31:30PM +0100, Graham Barr wrote: > On Fri, May 26, 2000 at 01:06:40PM +0100, Chris Ridd wrote: > > I am of the opinion that unbind leaves the TCP connection open, and it > > looks like Simon is too. Kurt was of the opinion that unbind closed the > > TCP connection. > > If you look at the packet trace there was no unbind() sent to the > server. The question is why was no password sent in the second > bind packet. And the answer is while(my($param,$type) = each %ptype) { if (exists $arg->{$param}) { ($auth_type,$passwd) = ($type,$arg->{$param}); last; } } the iterator for each %ptype is not reset and the last causes the loop to exit early. Adding keys %ptype before the while should fix it. (perldoc -f each will explain) Thanks to Simon for investigating this and nudging my memory :) Graham. |
From: Graham B. <gb...@po...> - 2000-05-26 16:24:39
|
On Fri, May 26, 2000 at 10:46:51AM -0500, Mark Wilcox wrote: > > $dsml->process( $file, entry => \&process_entry, schema => \&process_schema ) > > or die $dsml->error; > > > > Ok. I see. I'll start to work on it. I have attached what I started on. > > > > > Now for writing we could do > > > > $dsml->open($file,"w"); > > $dsml->write($entry); > > $dsml->write($schema); > > $dsml->close; > > Like this. Good. Graham. |
From: Graham B. <gb...@po...> - 2000-05-26 15:56:31
|
On Fri, May 26, 2000 at 08:37:40AM -0700, Paul Heinlein wrote: > On Fri, 26 May 2000, Graham Barr wrote: > > > Now for writing we could do > > > > $dsml->open($file,"w"); > > $dsml->write($entry); > > $dsml->write($schema); > > $dsml->close; > > > > The open would write the header and the close would write the footer. > > If you passed something like an IO::File object to open(), you might gain > some flexibility if you wanted to write() to a pipe or something other > than a file. True, we can allow that. Also I don't think the "w" is really needed as open would only be used for write. Graham. |
From: Mark W. <mew...@un...> - 2000-05-26 15:42:01
|
Graham Barr wrote: > OK, I have been thinking about this some more. > > On Fri, May 26, 2000 at 08:58:20AM -0500, Mark Wilcox wrote: > > > I have not tried the code, but from looking at it I have one concern. > > > It seems that the whole DSML file must be read into memory in one go. > > > > I'll have to double-check this. I can't remember if XML::Parser's callback functions use > > streaming or load the whole file. > > It's not that XML::Parser reads the whole file at one. It is that you read all > the entries from teh XML file into @results. So you are loading them all into > memory. Yeah, I took the quick and dirty route ;). > > > I have been considering if we really need an API like LDIF where the user does > read_entry() to get the next in the file. > > From my reading of XML::Parser there is no way to do this. When you tell > it to parse it parses the whole file. > > So I was thinking that maybe XML::DSML should just use callbacks itself. > > For example have the user pass a sub reference which will be called > whenever an entry is read. > > This can be extended when we start to read the schema, and we can have a different > sub to call. Or we can just have the user check the type of object passed. > > I don't think this would be too much of a setback as I would think that most of > the time the current LDIF is used in a loop anyway. > > So what we could end up with is something like > > $dsml = Net::LDAP::DSML->new(); > > $dsml->process( $file, entry => \&process_entry, schema => \&process_schema ) > or die $dsml->error; > Ok. I see. I'll start to work on it. > > Now for writing we could do > > $dsml->open($file,"w"); > $dsml->write($entry); > $dsml->write($schema); > $dsml->close; Like this. > > The open would write the header and the close would write the footer. > > Thoughts ? This is probably much better than what I had originally. I'll see what I get turned up. Mark > > > Graham. |