delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2014/06/18/04:33:33

X-Recipient: archive-cygwin AT delorie DOT com
DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
:list-unsubscribe:list-subscribe:list-archive:list-post
:list-help:sender:date:from:to:subject:message-id:reply-to
:references:mime-version:content-type:in-reply-to; q=dns; s=
default; b=PrLjR8CLm8naxDRGncNUo/FzjL15/SUG6/exsee4I7UmFcnbmHPrl
/kz4G7gA5Etxp8ezroAShW5j30fl+8YV6dnfP0MGJTxPjDYSquMy+To7aaSc04AC
RtOR0fBVgJfh+3gVmREPXkRHvQIPdoUB4b/IAq+cwyfLM5p3Y1BoY8=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
:list-unsubscribe:list-subscribe:list-archive:list-post
:list-help:sender:date:from:to:subject:message-id:reply-to
:references:mime-version:content-type:in-reply-to; s=default;
bh=3TRb00ZD0IMyniarlQElOk5Tg3o=; b=eb0ZLhKO44rGl9jAexWAOgzOy3hw
CDV3hphyNMoXfye2obcRvPEMXbMeVnxz1lhObhriBZRjjKIxxJjvm41HO6MVe8T1
s59yz5DwlzU5RlHsTOJBgIIKcQolbI0EztgPRt0DpbDbEMpYxwgMBafWHAlWpYDw
xrskf2kkFMl8H3I=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id: <cygwin.cygwin.com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-5.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2
X-HELO: calimero.vinschen.de
Date: Wed, 18 Jun 2014 10:33:04 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: timeout in LDAP access
Message-ID: <20140618083304.GV23700@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <F312783D-AD66-4614-922B-E44403C7E372 AT Denis-Excoffier DOT org> <20140617100011 DOT GL23700 AT calimero DOT vinschen DOT de> <C462E4F3-1E51-46DC-BD27-BC4786A5E8BB AT Denis-Excoffier DOT org>
MIME-Version: 1.0
In-Reply-To: <C462E4F3-1E51-46DC-BD27-BC4786A5E8BB@Denis-Excoffier.org>
User-Agent: Mutt/1.5.23 (2014-03-12)

--CVXKxAdNG2kQIXaJ
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Jun 18 00:41, Denis Excoffier wrote:
> Hi Corinna,
>=20
> On 2014-06-17 12:00, Corinna Vinschen wrote:
> >=20
> > So I expect an LDAP_SUCCESS with ldap_count_entries() =3D=3D 0 and then
> > repeat the request.  But the code doesn't expect LDAP_TIMEOUT in this
> > case.  Do I have to handle LDAP_TIMEOUT here as well?
> LDAP_TIMEOUT can occur there. I can even suppose it occurs more
> frequently for the _last_ 100-sid chunk (eg there are 5868 users in
> a domain, and timeout occurs after 5800 and the last 68 get lost). But
> it can also occur after 27 chunks while about 350000 users are still to be
> read in a given domain (yes, that makes about 352700 users in a single do=
main).
>=20
> I=E2=80=99m pretty convinced today that 300 is more than enough,

Much more than enough.  300 seconds?  5 minutes?  For 100 SIDs?

> and that with 3, only
> one or two timeouts are to be expected for an AD with 500000 users and no=
t so
> many domains (50 or 100). The flaw is that as soon as the first timeout o=
ccurs,
> the whole rest of the current domain is skipped, which can be much in som=
e cases.
> ldap_get_next_page_s() should perhaps deserve a second chance (with timeo=
ut 30s).
> After all, this function is called 3527 times (for the same domain).
>=20
> Also a simple observation: if LDAP_TIMEOUT is not to be expected, what is=
 the
> use of this timeval* parameter in ldap_get_next_page_s()?
>=20
> > I'm wondering if the timeout, at least for enumerating accounts, should
> > go away entirely.  In case of a connection problem this could result in
> > a hang for about 2 minutes by default I think (LDAP_OPT_PING_LIMIT).
> I think i like this (it it works). But in this case, it will not resume
> to the next domain, and the whole operation (eg getent) is interrupted?

I don't quite understand the question.  All LDAP operations have a
default timeout of 2 minutes if LDAP_OPT_TIMEOUT is not set.  The
operations we're doing here are pretty simple ones, the bunch of 100
SIDs per getpwent LDAP call is a really small dataset (about 4K bytes)
of indexed data, which should be readily available.  And there's a
certain (not Cygwin-specific) expectation that a simple LDAP operation
is fast.

Assuming the server takes more than just 3 seconds to reply to
a single request for some reason, let's say 30 seconds.  The call will
result in a laming output of getent, of course, but it would have no
other consequences.  If the server needs actually more than two minutes
to reply, and doesn't return a ping either, the timeout is a very likely
indication that we have network problems, or the server is down.
In that case, the normal code path applies.  The connection with the
server will be closed and we try the next domain.

The idea I was proposing was just to drop all attempts to seconds guess
how fast a DC replies.  We're going to use LDAP with default settings
and that's it.  Default settings means, every operation times out after
the default timeout period of 120 seconds, which should really be
sufficient.


Corinna

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

--CVXKxAdNG2kQIXaJ
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJToU7AAAoJEPU2Bp2uRE+gBeUP/1lLR5HTEypOfJgrel9Fkt94
wdlFDITDlRmb3DBZGAabnUwne3wExo+MCAzaAF9L6+/fNZbXlwprKdHXWgIegelp
/6IIwEFwwUEv+3eMZcYFypNYNam6Kzg8wKJ1ktX6Py94d+deSQv1mMNo2+7YAO4b
UPIALMD8aXhHPsVg+1L3DJgkzJYRuV4UxmMVorqh/kBV7LTnUIpt2XnHuEhHO9ML
OsRTJr28JunP+6mhJKKSSoHcQB7GOsPXrrt/rWYgU4e+O7lwrsQnBuHMvLyEpCUN
enPLd8UyTA5Bk5J/Ydo4yrMZDWakRu3XteseqsgP9sTE+afLQd35r7l2CfJKrx2P
maQw5AvYltDdk0LEaXDZOeZ4GrDkQ/B2nh5Ly7HDn8S+i1KBTvKBQlwiscyMBbvF
dgevQF3yDxjCdrPEqOIs+vs4e+fAyxHeYtbb/9bw2xQuUKvDow/wR5aJULAptYW9
8SXbxZl+SzQVtCaGJq3RGhJ7ujNozr6ku836yy9S7UCly257zE6USeraE4G8roiB
Pz6taEg22rT+wH/L+dGeACwZErQmgTN7lvH5K7Yy0KGMnOvg95+TA/rA+KZKuQ0x
Z9U3ommFtEt+3aTkFTFtuCksYYtPdMFuj6OL/wYB1UHO/KghiKKekNHIPRDLIOyj
tRvXfu0QoYxnQIxzSeQz
=yKjO
-----END PGP SIGNATURE-----

--CVXKxAdNG2kQIXaJ--

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019