LDAP modules/advice

[jlongino]

Beginning Summer semester, my workplace will switch one of its email systems from fairly basic sendmail to one using the Sun ONE Messaging Server. I'm fairly certain that this means I'll be needing heavy duty Perl access to the Sun ONE Directory Server.

The problem is that several of the CPAN LDAP modules are based on/require Net::LDAP, which is designed for use with OpenLDAP (unfortunately not an option). That pretty much leaves me with perldap-1.4. Has anyone had any experience using it? Is it compatible with the Sun ONE Directory Server? I am somewhat leary of it since I had to edit its API.c program and define two variables that it was using (na and one I don't recall but set to NULL). Needless to say, I feel less than enthusiastic about using it.

Previously we were using OpenLDAP and I used Perl sans LDAP modules to create ldif update files. The schema we were using was very sparse but the ldif files took what seemed to me an inordinate amount of time to run (even though we stopped slapd during runtime). Once we have some test data loaded into the new Sun ONE schema I'll run some ldif updates against it to see if it is any faster.

BTW, I called Sun and they say that they don't have any recommendations or support for Perl interfaces to their directory server. Their resource kit/tools/SDK has some utility Perl scripts but is primarily java, c based.

We're still in the planning stages, so before I start any PM input would be appreciated.

--Jim

[perrin]

Wait a minute, are you saying that the Sun ONE Directory Server does not adhere to the LDAP standard? Or that Net::LDAP does not implement the standard correctly? The Net::LDAP FAQ specifically mentions the Netscape directory server, so it certainly sounds like it should work without any problems.

[jlongino]

My attempts to install Net::LDAP failed because of a missing prerequisite (IO::Socket::SSL which is supposedly optional, though perl Makefile.PL won't proceed without it). At the time, <duh>I mistakenly assumed the problem was an OpenLDAP rather than OpenSSL dependency</duh>. After reading through the FAQ it does indicate that the install can be performed by copying the perl-ldap-0.2701/lib files to the appropriate Perl installation library.

Thanks for nudging me to retrace my missteps. The request for advice on module use/experience is still open. Given that Net::LDAP will work, what is the PM concensus on DBD::LDAP (since I've just recently been using DBD::Oracle and DBD::ODBC)?

Update: after reading the DBD::LDAP documentation more closely, it appears to be an alpha distribution and has some limitations (and compilation problems) that I'd rather not deal with.

--Jim

[iguanodon]

I use perldap-1.4 (Mozilla::LDAP) with an iPlanet directory server and haven't had any problems at all. Mozilla::LDAP was developed for the Netscape LDAP C API, which became iPlanet Directory Server and is now Sun ONE Directory Server.

[Solo]

I use Net::LDAP on iPlanet without problems.

use strict;
use Net::LDAP;

my $ldap = Net::LDAP->new('hostname') or die "$@";
   $ldap->bind( "cn=Directory Manager", password => "..."); 

my $root = $ldap->root_dse();
   $root->dump;

I think cn=Directory Manager is standard, at least it is in my environment... but I don't get out much. YMMV.

--Solo

--
I think my eyes are getting better. Instead of a big dark blur, I see a big light blur.

[jlongino]

Thanks for the example. It worked minus the password requirement and returned results (even though it is empty).

--Jim

[atcroft]

I've had a script using Net::LDAP running against OpenLDAP since late September with no issues to date (*knocks on wooden head for luck*). I had more an issue with the learning curve for dealing with LDAP than with the module, since I was learning LDAP as I went from the docs for Net::LDAP and the section on LDAP from O'Reilly's Perl for System Administration (with a question or two in here as well, if memory serves).

I'll leave this with a piece of advice that may prove helpful: use callback routines if you do searches, especially if you do ones that could potentially return a large amount of data. I uhhh... (*looks down sadly*) kind of ran a machine out of both physical memory and swap more than once before I found out about that because of a query that returned several hundred thousand records (*sheepish grimace*).

I wish you the best of luck with the process, and hope you might consider letting us know how it goes (if you have the opportunity).

[jlongino]

Ouch! Fortunately we're already keen to limiting the number of records returned because we don't want to make it too easy for spammers to suck up all our email addresses.

The primary reason for the old OpenLDAP system was to provide an employee email directory (~5000 records). The new system will be used for that purpose also, but primarily for authentication purposes (20K records storing about 10 times more data than before).

Thanks for the references. I already have the O'Reilly book but wouldn't have thought to peruse it for LDAP info.

--Jim