get_domain_user_groups() improvement.

[Andrew Bartlett]

On Thu, 2004-09-23 at 13:55, Igor Belyi wrote:
> Andrew Bartlett wrote:
> > While you are at it, we also need to improve the performance of the
> > 'users in this group' call.  I have the clients at my site making this
> > call, much to my frustration, as it currently does a 'getent passwd'
> > over the entire directory, looking for primary gids.  We should do an
> > LDAP search for that information too.
> 
> Well... This is a little bit trickier since you probably refer to the 
> get_memberuids() function...

I think so.

> If I understand philosophy behind Samba correctly (which I doubt) its 
> passwd/group/host databases are supposed to be maintained independently 
> of where local system keeps its own corresponding databases.
> 
> Unfortunately, with LDAP it is no more true - ldapsam too heavily 
> depends on Unix users and groups being in LDAP and being represented by 
> posixAccount and posixGroup. Somehow this dependance was not caried 
> completely through and some passdb code still uses NSS calls to retrieve 
> local user or group information showing the "independence of databases" 
> spirit regardless of what backend is used.

Yes, it's a mess.  Between conflicting design goals, and (frankly)
botched implementation of some parts, it's not pretty.  We had the goal
of 'independence of databases', but I do not feel this is in any way
practical with regard to ldapsam.  

> The change I've made did not change the functionality of the call since 
> it already had the "all information is in LDAP" attitude. The patch just 
> made this a little bit more optimal. That why I was quite comforable 
> suggesting the change.
> 
> On the other hand, suggestion for a similar change in get_memberuids() 
> will require another passdb function to give up its "independance" and 
> let ldapsam assume yet again that all local users and databases are in LDAP.

I'm happy with that assumption, with other backends doing whatever they
need to do to maintain the current situation.

> It would be quite helpful if somebody among real (older? more 
> experienced?) Samba maintainers would explain which of the two 
> directions Samba is heading.

My feeling is that for ldapsam, in Samba 3.0, it's more important to
have the performance hacks in place, than to try and hold on to the
'independence of ldap from ldap'.  It just isn't there with this code -
every samba group requires the posix group as a structural object
anyway.

The biggest problem in this area of code is that few people care about
it any more.  (Particularly since Samba4 development took off).

Andrew Bartlett
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.samba.org/archive/samba-technical/attachments/20040923/9c9bae1c/attachment.bin