DragonFly BSD
DragonFly kernel List (threaded) for 2006-01
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: lookupd-style daemon


From: Eli Green <eli@xxxxxxxxxxxxxxxxxxx>
Date: Fri, 27 Jan 2006 12:14:21 -0500

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?




[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]