[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: migrating from SUN one C SDK to openldap C sdk (Linux).



 
 
Doug,
Does this mean at the run time, a client using OPENLDAP C (Linux)  can connect to LDAP server on SUN? Regards
Farhad
 
 
 
 
 

From: Doug Leavitt <doug.leavitt@oracle.com>
To: Far a <nynjfar@yahoo.com>
Cc: Howard Chu <hyc@symas.com>; "openldap-technical@openldap.org" <openldap-technical@openldap.org>; Clément OUDOT <clem.oudot@gmail.com>
Sent: Thursday, June 6, 2013 12:56 PM
Subject: Re: migrating from SUN one C SDK to openldap C sdk (Linux).

The server can be migrated separately from the client applications.

To the best of my knowledge all the Sun servers are self contained,
as in they have their own copies  of whatever libldap (or equivalent)
library they need to function.  None of the servers use the libldap libraries
delivered with Solaris.  The libraries delivered in Solaris into /usr/lib/* are
available for the system tools (nss_ldap, ldap_cachemgr,
/usr/bin/*ldap*  and such) and of course third party client applications.

Also, Solaris 11 currently delivers both sets of libraries libldap.so.5
and the OpenLDAP libldap-2.4* libraries.    As long as you don't try to
link both libldap's in the same binary executable, you should be fine.

Finally, Solaris direct linking should protect the third party application
in the event that dynamically loaded Solaris library dynamically loads
one of the two libldaps for it's needs.  In this event even if both libraries
are loaded into the application, the Solaris library will use the one it needs
while the application will use the one it was linked with and they won't
cross name space or functional boundaries.

Doug.


On 06/06/13 11:38, Far a wrote:
Thank you Doug
 
This is great instruction for migrating the c code.
One main question that remains.  does the LDAP server needs to be migrated in the same time as client. Or,  can I have the client using OPENLDAP c SDK, while the LDAP server itself remain on Sun Solaris.
 
This party because I only own the client site of the.
 

From: Doug Leavitt mailto:doug.leavitt@oracle.com
To: Howard Chu mailto:hyc@symas.com
Cc: Clément OUDOT mailto:clem.oudot@gmail.com; Far a mailto:nynjfar@yahoo.com; mailto:openldap-technical@openldap.org mailto:openldap-technical@openldap.org
Sent: Thursday, June 6, 2013 12:16 PM
Subject: Re: migrating from SUN one C SDK to openldap C sdk (Linux).


On 06/06/13 09:51, Howard Chu wrote:
> Clément OUDOT wrote:
>> 2013/6/6 Howard Chu <hyc@symas.com>:
>>> Far a wrote:
>>>>    * Is there a list of dos and don'ts and list of possible issues for
>>>>
>>>>      migrating from SUN
>>>>      one LDAP TO openldap on Linux
>
>>> I haven't seen any such list.
>>
>> Hi,
>>
>> you can find some notes here:
>> http://www.linid.org/projects/openldap-manager/wiki/MigrationSunOracle
>
> This appears to be a list of differences between the SunOne DS and
> OpenLDAP slapd, not differences in the Sun LDAP C SDK and the OpenLDAP
> C SDK. Quite a different topic from the question in this thread.
>

I don't have a thorough list or document with specific guidance but I
can pass on a few pointers.
Assuming the goal is to move off Solaris (iPlanet/Mozilla vintage)
libldap.so.5 to a recent OpenLDAP
libldap-2.4.so.2 library, then here are a few things to think about.

1) for the most part if you are using any of the common APIs such as
ldap_search_ext_s etc. these
will work fine with just a recompile.  In my experience 80-90+% of your
LDAP code will remain unmodified.
Also you can probably catch everything you need to change by just
updating your build environment
to the OpenLDAP headers and libraries, and fix the compile errors that
show up.

2) Presumably your application uses the old ldap_init style interfaces
(the only ones that existed in libldap.so.5)
so you need to make a decision to either convert them to newer
ldap_initialize APIs or enable LDAP_DEPRECATE.

If you are using non-secure connections then you can stay with the old
APIs, but if you are using secure
connections and have tapped into the NSPR portions of libldap.so.5 (aka
any prldap* API) you need to
rip that stuff out and start using ldap_initialize.  My $0.02
regardless, just change over to ldap_initialize even
if you are not using SSL.

3) review your ldap_get_option and ldap_set_option calls.  There are a
few differences
such as LDAP_OPT_NETWORK_TIMEOUT instead of LDAP_X_OPT_CONNECT_TIMEOUT
and those differences need to be changed.  A test compile will expose
them all.

4) If you are using libldap.so.5 ldap_get_lderrno you will need to
change that code to call
    ldap_get_option and call
        (void) ldap_get_option(ld, LDAP_OPT_RESULT_CODE, &err);
        (void) ldap_get_option(ld, LDAP_OPT_DIAGNOSTIC_MESSAGE, &s);
        (void) ldap_get_option(ld, LDAP_OPT_MATCHED_DN, &m);
as needed.  Similarly a test compile will flag these places.

5) The function calls to manage controls (such as virtuallist) are
different between the libraries, and
if used, the application will need some adjustment there.

If you are using some other libldap.so.5 specific functions you might
have to do a little more
work, but in general everything above probably accounts for 99+% of an
application conversion.

The only other big difference is if your application specifically has
multiple threads sharing/multiplexing
requests over the same connection.  If it does you need to look at and
use the OpenLDAP
ldap_dup/ldap_destroy APIs.  Here you may need to rip out some more
prldap* functions and
rework the code, but that will be dependent on your application specifics.

In my experience, if you look out for these issues, then moving to the
OpenLDAP libldap library
is pretty straight forward.

Doug.