I think I've come across a problem either with your PerLDAP library or with the Tie::Hash library on a Windows-NT system running ActiveState Perl5 build 506 (Perl 5.005_02). I'm using the version of PerLDAP available on ActiveState's Package library (which appears to be the most recent version you have available). The problem is that when I execute a simple query against my LDAP server (Microsoft Exchange Server v5.5, which works fine with the Net::LDAPapi library), I don't get access to all of the data that is returned. An example script attached below shows the results of a simple query where I am attempting to display the objectClass for a user. Unless I access the object behind the TieHash directly, I don't see the data. This is the case for about 60% of the attributes returned from the LDAP server (some of the attributes do make it into the TieHash, but there doesn't seem to be a pattern although the missing fields are the same for each query). Any insight you might be able to provide would be most useful. I also no not have access to the CVS system so can't check to see if there is a more recent version of the modules available. If you could either make a tarball available somewhere or mail it to me, I might be able to debug a bit further. Thanks, Stuart Schneider Stuart.Schneider@PacifiCorp.com -----Sample Script----- $ld{"host"}="pdxexc01"; $ld{"port"}=389; $ld{"root"}=""; $ld{"scope"}="sub"; $search = "uid=P75412"; $conn = new Mozilla::LDAP::Conn(\%ld); die "Could't connect to LDAP server $ld{host}" unless $conn; $entry = $conn->search($ld{root}, $ld{scope}, $search, 0); $conn->printError() if $conn->getErrorCode(); while ($entry) { print "objectClass=",join(",",@{ $entry->{objectClass} }),"\n"; print "objectClass=",join(",",@{ $entry->{_self_obj_}->{objectClass} }),"\n"; $entry = $conn->nextEntry; } $conn->close if $conn; ---------- -----Script Output----- objectClass= objectClass=organizationalPerson,person,Top ----------

From: Jeff Maaks <jmaaks@mdc.com> For the boeingPerson object class, I've found that like Stuart Grace (see http://cvs-mirror.mozilla.org/webtools/bugzilla/show_bug.cgi?id=1328) I can see the attributes when accessing the entry object directly. Here's some sample code that lets me see the attributes: ------------------------------------------------------- use Mozilla::LDAP::Conn; $root = "ou=people,o=boeing,c=us"; $conn = new Mozilla::LDAP::Conn("servername","port"); $entry = $conn->search($root,"subtree","(boeingClockNumber=m278891)", 0); while($entry) { # this prints nothing after the = print "objectClass=",join(",",@{ $entry->{objectClass} }),"\n"; # this prints the various object classes correctly (inetOrgPerson, # boeingPerson, etc) print "objectClass=",join(",",@{ $entry->{_self_obj_}->{objectClass} }),"\n"; # this prints the various returned attributed correctly (including # the previously unprintable boeingPerson print "objectClass=",join(",",@{ $entry->{_self_obj_}->{_oc_order_} }),"\n"; # and this prints the attributes and values OK foreach $attr (@{$entry->{_self_obj_}->{_oc_order_} }) { grep((print "$attr: $_\n"), @{$entry->{_self_obj_}->{$attr}}); } # this only prints cn,dn,mail, etc. - non-boeingPerson attributes $entry->printLDIF(); $entry = $conn->nextEntry(); } So, accessing the object internals works, but working through the provided methods does not. Thanks for any insight you could provide..... Jeff

More from Jeff Maaks <jmaaks@mdc.com>: I am running ActiveState Perl 5 build 506 (Perl 5.005_02). I just downloaded and installed build 508, and it didn't help. I've been poking around in Conn.pm's sub nextEntry, and a print "clocknum: ", $obj->{boeingClockNumber}, "\n"; just before the ldap_ber_free at the end of the routine correctly prints the value. One more clue:in sub nextEntry from Comm.pm, if I change the last line: return bless \%entry, Mozilla::LDAP::Entry; to: return bless $obj, Mozilla::LDAP::Entry; ..then everything seems to work great! However, I'm not enough of a Perl object/tie expert to know what this might be screwing up. Does this give you any ideas?

Status CLOSED is deprecated as per bug 169885

Re-resolving

verifying former CLOSED bug