Re: nssd (was RFC: Going the LDAP/Kerberos way with NetBSD.)

[christos%astron.com@localhost (Christos Zoulas)]

In article <0A86E637-DAA7-4377-8C83-D3C81EE15A48%3am-software.com@localhost>,
Matt Thomas  <matt%3am-software.com@localhost> wrote:
>I'm wondering if this would be a good time to resurrect "nssd" (name
>service system daemon).
>
>Instead of adding all this libc, maybe this would be a good time to
>move this support for a multi-threaded daemon.  This would make libc
>and thereby most processes smaller and move the complexity to a single
>process.
>
>Libc could still retain file methods, or if in single user mode, fork
>a helper program to assist in the lookup.  For cruchgen'ed programs that
>need this support, the nssd itself could be crunched into the
>uber-executable.

My experience with nssd has only been pain. While it is a good idea if
properly implemented, I have not seen a proper implementation of it and
I don't think that it is easy to write one. Issues:

1. It introduces a level of cacheing which can lead to annoying
   consistency issues if there is more cacheing happening at the
   directory server level.  What would be ideal is to teach all
   the directory server backends to do uncached calls when they
   are contacted by nssd.

2. It introduces an extra context switch for each lookup. This is
   why sun invented doors.

christos