As part of Solaris to Linux migration, I am planning to migrate my application that uses SUN one C SDK to openldap C sdk (Linux). I have various questions that I need to address at the beginning. I am hoping I can get some help over here. The questions are as follows * Can client use openldap C sdk (Linux) while the server is still on Sun one LDAP server. * Is there a list of dos and don'ts and list of possible issues for migrating from SUN one LDAP TO openldap on Linux . Regards farhad
Far a wrote:
As part of Solaris to Linux migration, I am planning to migrate my application that uses SUN one C SDK to openldap C sdk (Linux). I have various questions that I need to address at the beginning. I am hoping I can get some help over here. The questions are as follows
- Can client use openldap C sdk (Linux) while the server is still on Sun one LDAP server.
The point of a standardized protocol like LDAP and the SDK is to allow you to talk to any server that speaks LDAP.
- 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.
Probably worth pointing out - Solaris 11 now bundles OpenLDAP by default. If there were any issues in migrating, the OpenSolaris guys must have already encountered them and they can surely provide you answers.
Howard Chu wrote:
Far a wrote:
As part of Solaris to Linux migration, I am planning to migrate my application that uses SUN one C SDK to openldap C sdk (Linux). I have various questions that I need to address at the beginning. I am hoping I can get some help over here. The questions are as follows
- Can client use openldap C sdk (Linux) while the server is still on Sun one LDAP server.
The point of a standardized protocol like LDAP and the SDK is to allow you to talk to any server that speaks LDAP.
- 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.
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
Clément.
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.
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.
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 doug.leavitt@oracle.com To: Howard Chu hyc@symas.com Cc: Clément OUDOT clem.oudot@gmail.com; Far a nynjfar@yahoo.com; "openldap-technical@openldap.org" 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.
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 doug.leavitt@oracle.com *To:* Howard Chu hyc@symas.com *Cc:* Clément OUDOT clem.oudot@gmail.com; Far a nynjfar@yahoo.com; "openldap-technical@openldap.org" 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 mailto: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 LinuxI 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.
- 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.
- 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.
- 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.
- 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.
- 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.
Doug Leavitt wrote:
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.
You might suggest to your colleagues at Oracle that they do this in other libraries they ship too.
http://www.openldap.org/its/index.cgi/Incoming?id=7599
On Thu, 6 Jun 2013, Howard Chu wrote:
Doug Leavitt wrote:
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.
You might suggest to your colleagues at Oracle that they do this in other libraries they ship too.
To be fair, that ITS is for Linux, and last I heard the direct linking support patches weren't accepted to glibc. So the Solaris-style "ld -Bdirect -Minterposers.mapfile" won't work for that report.
Aaron Richton wrote:
On Thu, 6 Jun 2013, Howard Chu wrote:
Doug Leavitt wrote:
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.
You might suggest to your colleagues at Oracle that they do this in other libraries they ship too.
To be fair, that ITS is for Linux, and last I heard the direct linking support patches weren't accepted to glibc. So the Solaris-style "ld -Bdirect -Minterposers.mapfile" won't work for that report.
We're getting a bit off-topic, but there's no reason for a vendor library whose purpose is not to provide an LDAP API to expose/export LDAP API symbols. They could use -Bsymbolic or an explicit list of exported symbols in a mapfile to prevent such symbol leaks from occurring. You don't *need* any particular Solaris-specific features to avoid these issues.
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.
- 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.
- 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.
- 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.
- 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.
- 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.
On Sun, 9 Jun 2013, Far a wrote:
Doug, Does this mean at the run time, a client using OPENLDAP C (Linux) can connect to LDAP server on SUN? Regards Farhad
OpenLDAP's libldap (pretty much) speaks the standards as defined in the various RFCs. If the Sun LDAP server adheres to those same RFCs, you shouldn't see an issue.
This is the entire point of a standards-track stack...
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.
- 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.
- 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.
- 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.
- 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.
- 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.
All of the Oracle/Sun LDAP servers follow LDAPv3 standards and will communicate with any client that is also follows LDAPv3 standards, including any client using the OpenLDAP libldap, because the OpenLDAP libraries support the LDAPv3 standards.
Doug.
On 06/09/13 12:51, Far a wrote:
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 mailto: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 LinuxI 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.
- 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.
- 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.
- 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.
- 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.
- 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.
Doug Leavitt wrote:
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 LinuxI 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.
- 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.
- 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.
- 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.
- 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.
- 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.
Thanks Doug, great info.
For a practical example, here's a patch I wrote to transition Mozilla Firefox off of the Mozilla C SDK and onto OpenLDAP, back in 2008. The patch did a number of the things Doug mentioned.
https://bug292127.bugzilla.mozilla.org/attachment.cgi?id=334117 (Read the bug report for more context. https://bugzilla.mozilla.org/show_bug.cgi?id=292127 )
openldap-technical@openldap.org
-
Aaron Richton -
Clément OUDOT -
Doug Leavitt -
Far a -
Howard Chu