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 [EMAIL PROTECTED]
_______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
