Subject: Re: LDAP NSS for NetBSD
To: Timshel Knoll-Miller <timshel@shels.net>
From: Luke Mewburn <lukem@NetBSD.org>
List: tech-userlevel
Date: 02/22/2005 11:01:56
--ISA6zNVXmTIvvkD5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Feb 20, 2005 at 10:29:09PM +1100, Timshel Knoll-Miller wrote:
  | Hi,
  |=20
  | I'm not entirely sure that this is the right list - I'm fairly new to=
=20
  | NetBSD...
  |=20
  | I'm thinking about writing a BSD licensed LDAP nss backend for NetBSD=
=20
  | -current's modular nsswitch.

Sound's good; ldap is one of the services I'd like to see a clean
module for.


  | I know about padl's nss-ldap module, but it=20
  | is is under the GPL and also needs to be ported to use the BSD NSS API,=
=20
  | which is different to glibc and other implementations (which, AFAICT,=
=20
  | seem to look for symbols in the module named "_nss_<source>_<function>"=
=20
  | with the published prototype of <function>).

PADL's nss_ldap is actually LGPL; if it was GPLed it couldn't be used as a
dlopened shared library on non GPL-ed systems.

It's not too hard to add support for the (new) nsswitch API in
NetBSD-current into other nss implementations; I've done it for
Samba's winbind (which I will feed back to samba RSN).

That said, I won't object to a BSD licensed nss_ldap module for NetBSD.


  | Porting shouldn't really be too difficult, but neither should a=20
  | re-implementation. While I'm at it, I'm considering adding backend=20
  | databases for services and protocols (get{serv,proto}by*),  and=20
  | reentrant versions of getpwent and friends, which don't seem to have=20
  | been implemented yet (only the get*nam() have?).

There is no POSIX standard for getpwent_r(); only getpwnam_r() and
getpwuid_r() were standardized.  (Same goes for getgr*_r()).
Various vendors have implemented getpwent_r() in incompatible ways...


  | Has anyone else done any work on this stuff?

"Yes".  :-)


  | I'm interested to hear what | people think of it, and any advice
  or ideas regarding the implementation | of the ldap backend.
  Also, as I'm new to coding NetBSD any advice or | pointers to
  development documents would be appreciated.

I wrote some documentation on the nsdispatch(3) rework which I posted to
tech-userlevel on September 27, 2004.  Check the mail archives for
more details (and the followup discussion).

The summary of the defacto API used by rework is:
	For a given public function foo
		someretval foo(const char *arg1, int arg2)
	the va_list passed to the backend nss function has the members
		someretval *
		const char *
		int

For example, see how libc/gen/getgrent.c implements _*_getgrgid_r()
(in the argument decoding of va_list ap).

I intend to extend the nsdispatch(3) man page explaining this defacto
API and which "standardized" functions have been converted to using it.

There's also some work to be done in converting other functions to
nsswitch;. , getserv*() and getproto*() haven't been converted to
nsdispatch(), and getusershell/getnetgr*/gethost* are still using
adhoc APIs which makes it harder to write third party plugins.
These will need to be converted to the new defacto API.

(Jason Thorpe & I discussed a chunk of this recently; I really should
commit my "nsswitch todo" list so people can see the status).


Cheers,
Luke.

--ISA6zNVXmTIvvkD5
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (NetBSD)

iD8DBQFCGnZ0pBhtmn8zJHIRAgfvAJ0dfY3gR6gMbWCuStrPvLMVcwxoBgCguAD0
Y7d29IR3oPKkr++BTsnITTw=
=gY31
-----END PGP SIGNATURE-----

--ISA6zNVXmTIvvkD5--