kdb ldap back end
psahukar at novell.com
Fri Mar 17 09:02:16 EST 2006
My comments start with ">>".
I'm (finally!) getting a chance to start digging into the LDAP back
end. One issue has jumped out at me: On some systems, dynamically
loadable objects and shared libraries are not the same. So for
portability, we'll assume the system can support loading an object
with dlopen (or other system- specific means), or linking against it
as a shared library, but not both.
The ldap- util program links against the ldap database plugin,
currently. I think the best fix is probably to split off most of the
plugin into a separate shared library that both the ldap- util program
and the database plugin are linked against. But that brings up the
question of how much should move and how much stay in the plugin, and
what should be exported from the new library. (Are we ready to
consider it a published interface that we'll maintain binary
compatibility with going forward? My guess is no, so we can do
whatever we want now and change it as needed later.)
>> A separate library can be derived out of the ldap database plug-in.
>> My guess is, with the separate library, ldap-util program need not
link to the ldap database plug-in. am i right ?
>> If yes, even with a separate library ldap-util will have to link to
the plug-in as the ldap-util is
>> making use of DAL apis for LDAP (like krb5_ldap_put_principal) and
>> will have to stay in the plug-in as they are needed by DAL.
>> We can write some wrapper routines that in turn will call DAL apis
for LDAP (like krb5_ldap_put_principal).
>> The wrapper functions will become part of the plug-in and will be
called by DAL.
>> The DAL apis (like krb5_ldap_put_principal) can be moved to the
>> and ldap-util can call the DAL apis directly. This way ldap-util
will not have to link to plug-in.
The alternative approach is probably to have the ldap- util program
dlopen the database module and go looking for the functions it wants
to call; I don't like that approach as much, myself, though it does
let us sidestep the shared- library questions for now.
>> I agree with this point.
More information about the krbdev