On Nov 5, 2009, at 2:54 AM, stephen mulcahy wrote:
> Hi Matthew,
>
> Apologies for asking but what is nss_ov? A quick google didn't shed
> any light on it.
Not at all- maybe a little history is in order:
Those of you familiar with Arthur's work will know that the nss-ldapd
project originally consisted of a very small nss_ldap library module
that communicated with a local daemon called ldapd, which in turn
communicated with a remote LDAP server. Many instances of the nss_ldap
library communicated with a single ldapd process. The ldapd process
performed the heavy lifting, and the nss_ldap module was therefore
much smaller, simpler and faster. In addition, consolidating the LDAP
communication functions into a daemon would make it easier to develop
caching strategies and enhanced access control features.
Unfortunately, since the ldapd was and is still relatively new, these
features are yet to be developed.
Howard Chu looked at Arthur's work and realized that the OpenLDAP
server daemon, slapd, already had everything needed to implement
caching, replication, and many more desirable features, and only
needed a listener to let it interface to the new nss_ldap module. Thus
was born nss_ov, a slapd overlay that listens for requests from nss-
ldapd's nss_ldap library and turns them into the appropriate internal
slapd operations for processing. A slapd server process could now
replace the original ldap process. For it's part, slapd could be
configured as a cache server, or as a full or partial replica of
another OpenLDAP server. The replication strategy allowed for fully
disconnected operation if desired. OpenLDAP's rich access control
policies enabled the creation of many more methods of managing login
access to systems.
The work done for nss_ldap was a great step forward, but any system
using it still had need of PAM functionality to handle LDAP
authentication. Configuring pam_ldap entailed installing and managing
much of the same infrastructure needed for the original nss_ldap code,
so it actually became more difficult to configure and manage systems
using pam_ldap and the new nss_ldap/ldapd combination. Our goal was to
only have to manage a single system, so Howard developed a small
pam_ldap module that could communicate with nss_ov/slapd and added the
necessary support functions to nss_ov. When Howard submitted the new
PAM module for inclusion in the nss-ldapd project, Arthur added the
requisite functionality to the ldapd daemon to support PAM operations.
So now the nss-ldapd pam_ldap and nss_ldap libraries can be used
either with Arthur's ldapd daemon, or with the OpenLDAP Project's
slapd daemon. Each has their advantages: ldapd is relatively small and
light, but at present doesn't support caching and is relatively
untested. The slapd daemon is larger and can consume more resources,
but offers caching, replication, a richer access control model, and
many more capabilities as discussed above. The need for additional
resources is mitigated by the fact that most systems these days can
provide them, and the fact that the functionality brought by using
slapd is well worth the additional resources.
With SUUM v4, Symas is providing an integrated package that blends the
nss_ldap and pam_ldap modules from the nss-ldapd project with a
version of OpenLDAP tailored to run on a client in any of several
modes. Sample configuration files will help the new user get started
quickly.
I should also point out that new work on OpenLDAP's pcache overlay
greatly enhances the ability of a client to run in disconnected mode
with master servers other than OpenLDAP, but that's a discussion for
another time.
Cheers,
-Matt
Matthew Hardin
Symas Corporation - The LDAP Guys
http://www.symas.com>
> Thanks,
>
> -stephen
>
> --
> Stephen Mulcahy, DI2, Digital Enterprise Research Institute,
> NUI Galway, IDA Business Park, Lower Dangan, Galway, Ireland
>
http://di2.deri.ie http://webstar.deri.ie http://sindice.com
