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.comReceived on Sat Nov 22 2003 - 08:06:00 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:30 UTC