more KDB-LDAP stuff

[Praveenkumar Sahukar]

>>> On Mon, Mar 27, 2006 at 11:46 pm, in message
<1F81598B-BD55-4906-992C-56D469EB3657 at MIT.EDU>, Ken Raeburn
<raeburn at MIT.EDU>
wrote: 
> 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.

I checked out and found that only ldap_util needs these functions. So
they cannot be straight away removed. I will dig more to see what 
will be a better way to fix this. 

Regards,
Praveen Kumar