more KDB-LDAP stuff

Ken Raeburn raeburn at MIT.EDU
Mon Mar 27 13:16:01 EST 2006


On Mar 27, 2006, at 08:03, Praveenkumar Sahukar wrote:
> My comments start with "> ".
>
> 1) Can the eDirectory support be made into a run- time test rather
> than a compile- time test?  (Preferably automatically detected rather
> than specified by command- line.)  It would be unfortunate if binary
> packages could either support eDirectory realms or support non-
> eDirectory realms, but not both.  (I don't think this is urgent.)
>
>> I guess you are talking about the build setup, detecting whether
> eDirectory is
>> installed on the system and if yes then build the eDirectory
> back-end.
>> Shouldn't this apply to OpenLDAP too ? So if OpenLDAP libraries are
> available
>> then the OpenLDAP based back-end should be built. We will have to
> handle the case
>> where both the libraries (eDirectory and OpenLDAP) are available may
> be
>> through command line.

Well, yes, we can do that too, but I was thinking of having a  
configure option that enables both, and at run time the code would  
figure out if eDirectory was in use or the plain LDAP setup.  Or, if  
the code size or performance difference is bigger than I'm guessing  
it is, the eDirectory detection and support could be enabled with a  
second option.

For the moment, until we've got better testing capability for the  
LDAP code (documentation, config files, scripts), I don't think I  
want to automatically enable LDAP use just yet if it's not explicitly  
requested.

> 2) The kdb- ldap code defines a bunch of symbols krb5_dbe_
> {lookup,update}_{last_pwd_change,mod_princ_data,tl_data} which are
> also defined in and exported from the kdb5 library.  Should the kdb-
> ldap code have its own implementation of the same functionality?  If
> so, they should be renamed.
>
>> The functions are defined in the DAL and not in DAL-LDAP.
>> At the first look I think these functions can be re-used from kdb5
> library.
>> I will try to remove these functions or rename the same if they can't
> be removed.

It should be easy, I can probably take care of it this week.  Just  
wanted to confirm that that's the way to go.  Thanks.

Ken



More information about the krbdev mailing list