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 :} Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
pgp4Ts4AWg4zf.pgp
Description: PGP signature
