extending nss and examples/nss a bit

[tridge at samba.org]

Simo,

 > In any case I would prefer this option, as putting extensions on a
 > system lib is not very nice imho.

It's not a system library, it's a Samba library.

I should point out that I am not proposing that all external Samba
access go via this library, just access that "fits" with the nss way
of doing things. nss_nametosid() is so very close in style to all the
other nss_*() functions that putting it in a separate library just
doesn't make any sense to me.

It also completely solves (at runtime) the usual library versioning
problem with normal library linking, as an application can ask at
runtime whether the local system has a particular function, by just
calling dlsym(). Otherwise you have to use a compile time configure
test, which means you get into all the usual nightmare problems of
shared library versioning.

So if some application (such as squid) wanted to be able to use a SID
mapping function from Samba and it was linked via traditional
techniques to libwbclient.so then you would have a version dependency
between squid and version X.Y.Z of Samba (or version X.Y.Z of
libwbclient, depending on the packaging). By using dlopen() and the
extended nss interface squid can be always compiled to take advantage
of Samba SID mapping, and at runtime it can check for dlsym() failure
and fall back to another mechanism.

Cheers, Tridge