Unfortunate dynamic linking for everything

[Richard Coleman]

Garrett Wollman wrote:

> You forgot:
> 
> 	* Allow statically-linked programs to use dynamic NSS modules
> 	  by forking a (dynamically-linked) resolver process when
> 	  needed.
> 
> This leads to a related, but widely disparaged option:
> 
> 	* Have a persistent NSS caching daemon with an RPC interface
> 	  that all programs can access for NSS lookups.  You might
> 	  call such a program `nscd'.  (Might as well be honest about
> 	  it.)
> 
> Both of these options may incidentally help to resolve threading
> issues in the C library (although that would not be the preferred way
> of doing so).

Regardless of how NSS is implemented, it will be useful to have some 
type of caching (even if optional).  On a large system, you can beat the 
hell out of your LDAP server otherwise.  Of course, you can use a local 
replica of your LDAP server.  But that doesn't help if are using a 
different database like Postgres as the backend for your nss/pam setup.

But if a nscd (or equivalent) is added to FreeBSD, we need to do a 
better job than the Linux nscd.  We had real problems with the Linux 
nscd in a previous project.  If I remember, it assumes that the mapping 
between username -> uid was 1-1.  We added an attribute to our LDAP 
schema so we could specify the reverse mapping in situations where more 
than one username mapped to the same uid.  But we could never get it to 
work correctly, since Linux nscd made some assumption that were 
difficult to change.

Richard Coleman
richardcoleman at mindspring.com