Re: [HEADS UP]: OpenLDAP+nss_ldap+nss_modules separated patch and more (SoC)

On 30. aug. 2006, at 10.58, Andre Oppermann wrote:

> Julian Elischer wrote:
>> John Baldwin wrote:
>>> On Saturday 26 August 2006 01:00, Robert Watson wrote:
>>>
>>> Agreed.  I also think LDAP would be a very useful thing to add.   
>>> I know that
>>> I currently use NIS/yp because it just works and is integrated  
>>> into the base,
>>> etc.  I think adding LDAP as the logical successor to NIS/yp  
>>> would be a good
>>> thing.
>>>
>> I agree with John. Historically things have moved to the base  
>> system when they
>> have reached some amount of public use, and they have been needed  
>> for a large number
>> of othre parts.. e.g. SSL.
>> I think that LDAP has reached this point (in fact did so many  
>> several years ago)
>> and having a standard ldap implementation in the base system  
>> allows us to make
>> FreeBSD machien splay better in many environments.
>
> The problem is that OpenLDAP is a very big thing.  It contains a  
> number
> of libraries and servers.  Importing the whole thing is clearly not  
> the
> right thing as we should only ship the LDAP library.  However more  
> complications
> come from the fact that you can build the LDAP library again with a  
> number
> of further options and dependencies on other libraries.  Depending  
> on your
> usage case you may need to turn one of those on or off for your  
> other applications.
> Topping it off OpenLDAP does quite a few releases a year with  
> important bug
> fixes.  This is quickly becoming backporting hell.  At the moment  
> I'm not sure
> if the slapd server refuses to run with an older library found in  
> the base system.

Actually, including the server might not be a bad idea. slapd has  
good support for replication and can if set up correctly serve well  
as a distributed lookup database, resilient to network outages and  
other challenges that come with centralized lookup databases.

Also with the efficiency of the Berkely DB backend and FreeBSD's  
excellent I/O scheduling one really have no need for a nss caching  
daemon when the database is on the local system.

But as you say, doing so means more hands needed to maintain the  
import, so we have to find out if the functionality gained is worth  
the extra work.

> For this LDAP library thing to work there has to be a painless way  
> to overwrite
> or override the base LDAP library with a custom, newer from ports  
> or self-compiled
> one.
>
> A quick glance into the OpenLDAP install instructions reveals that  
> it depends on
> OpenSSL (check, it's in the base system), KERBEROS (optional in  
> base system),
> Cyrus SASL library (not in base system) and POSIX threads (check).   
> I don't think
> we want to import Cyrus SASL into the base system.

Add Sleepycat Berkeley DB and necessary tools to the list if slapd  
was to be imported as well. It makes much sense in compiling it in  
statically, so that would not add to the library problems though.

--
Frode Nordahl