winbindd uid and gid range assumptions

[Mike Gerdts]

On Mon, 2002-05-13 at 18:42, Andrew Bartlett wrote:
> Moving over the socket is a very expencive operation, particularly
> compared to a simple if statement.  Also, where we know that a uid is
> local, we need to check with code that winbind isn't linked to - the
> passdb backend.

So in a situation where you have UIDs interspersed between NIS and
domain users, it may be cheaper to check to see if it is local first
followed by winbind.  At least this may be better in my situation, as
each of my NFS/Samba servers is already an NIS slave.  Even though a UID
lookup may have to talk to nscd and/or ypserv, it is still on the same
machine, thus avoiding network delays.

Perhaps this would be a place where the plug-in architecture could be
useful as well.  Checks could all be relegated to idmap_ops->islocal(). 
The default op could be to check the winbind id range.  Others that are
willing to or need to pay the price of a socket operation will have the
option of doing so.  Presumably islocal() would not just be a straight
BOOL operation.  I could imagine it replying True, False, LocalFirst, or
DomainFirst.

> But yes, we need to deal with things like getting the uid from the SFU
> LDAP schema, so this may well change in the future. 

Do you have any relative time frame or rough release number that you are
shooting for? 

Do you see a plug-in that merges the functionality of the existing idmap
to the architecture present in the VFS, or should I start barking up a
different tree?

Mike