Re: lookupd-style daemon

[Eli Green <eli@xxxxxxxxxxxxxxxxxxx>]

On Fri, Jan 27, 2006 at 02:56:43PM +0100, Emiel Kollof wrote:
> On Friday 27 January 2006 14:36, Eli Green wrote:
>
> > I've been thinking of throwing my hat in the ring and helping out but
> > since I'm mostly useless, wasn't sure where to start. A while back,
> > there was talk of somebody using libcaps to implement an NIS-style
> > daemon to do password/group/whatever else lookups that libc could use if
> > it was present and fall back to files if it wasn't. That seems about the
> > level of complexity I could handle.
>
> Cool! Yes, if you search the archives of the FreebSD lists and the dragonfly 
> lists for 'static linking', 'performance' or 'register' you might hit that 
> discussion. It was basically about static bins having no access to mechamisms 
> like the Name Service Switch. What you are proposing to build was a solution 
> that Matt came up with.

It sounds similar to how MacOS X does it with their lookupd, which has
an NIS compatibility module dating back from the NeXT days.

Would it be more clever to take advantage of the fact that we have a
persistent daemon that can maintain connections to database servers (I'm
thinking LDAP and SQL here) and cache things in memory, or would it be
in the best interest to be able to load other NSS modules?

Personally I'd rather do the former. The API for writing modules really
shouldn't be that complicated, IMHO.

I'm assuming, given the stated goals of the project, that libcaps
automatically provides network-transparent IPC, so the lookup daemon
could be sitting on a remote machine. Is this correct, or should the
daemon itself be able to forward requests to another machine and maybe
cache the results locally?