On Jun 24 17:58, Corinna Vinschen wrote:
> On Jun 23 22:38, Denis Excoffier wrote:
> > On 2014-06-23 11:09, Corinna Vinschen wrote:
> > > On Jun 19 19:53, Denis Excoffier wrote:
> > > 
> > > Do you really *want* to enumerate 500K users when accessing the DCs
> > > remote over a slow DSL line?  Isn't this a situation in which you'd
> > > rather like to avoid enumerating accounts or restrict it to an
> > > essential subset?  That's what db_enum would be good for.
> > IMHO the line is not especially slow. Instead, the
> > server (and occasionally the client) is clobbered sometimes. For example it
> > seems more difficult (ie timeout occurs more frequently) for a server
> > to output the last sid’s in a domain than to output a full PageSize of
> > results.
> > 
> > Personally i don’t *want* to use /etc/nsswitch.conf at all. What bothers me
> > is that the user does not get any indication of a timeout (and several successive
> > and unrelated timeouts may be met in a single invocation of getent). Therefore
> > even if all servers are up, the user has no means to know that the list is exhaustive.
> > If the timeout occurs for the last chunk this is not so important, but if 
> > the timeout occurs in the middle it may be. That is the difference between
> > a large timeout and a timeout, say, too accurate.
> > [...]
> > >> 1) for most of the 100-sid chunks, the high timeout is not used, therefore
> > >> the global penalty in delay is not so high. And perhaps a 120s timeout is high
> > >> enough so that when it is met, we could abandon not only the current domain,
> > >> but also the whole search?
> > > 
> > > Would that be really a bright idea?  Assuming your ADs (and their DCs)
> > > are in different remote locations,  One of those connections being down
> > > would disable enumerating other domains.
> > It would be a means to have getent 'depend' on a unique timeout.
> > > 
> > >> 2) if value of timeout is not high enough (i have no figures…), timeout may
> > >> occur when the PC is in fact occupied with other tasks (eg antivirus scanning
> > >> or something else), unrelated to network delays or server latencies.
> > > 
> 
> Stay tuned.  I'm rewriting the LDAP access code to perform all critical
> LDAP calls in interruptible threads.  The Windows LDAP calls don't
> provide any kind of synchronization, only timeouts.  I hoped to get away
> with short timeouts but it seems I hoped in vain.
> 
> So the next iteration of this code will not use any timeout other than
> the default LDAP network timeout of 2 minutes, but the calls will be
> interruptible by signals.
> 
> I hope that fixes this the right way :}

I applied a matching patch and created new developer snapshots on
http://cygwin.com/snapshots/

No more artificial timeouts, but the LDAP calls will be interruptible by
a signal now.

Also, if an error occurs during ad enumeration, getpwent/getgrent will
return NULL with errno set accordingly.

But that won't help you much when running getent.  getent simply stops
the enumeration when getpwent/getgrent return NULL.  It does not check
the error code and therefore it won't indicate if the enumeration has
been stopped for a reason other than the end of the list has been
reached.


Please test,
Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Maintainer                 cygwin AT cygwin DOT com
Red Hat