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=P1UXaTuP2uCyPVwFg+Z8am44oNAq5JaKQMcsHOBHjskV5bbKBgJFJ
	tDKkVhmXMDybt4p1h9lIFqHaK8H8RE8szhxbzZTg8F7z42i5MGNsgHkd1qzb6xgG
	qUKzIGQIgCXaJ9p35s7ddbRTlYDz4KuQoplPSfZSbNl9cs3JHlI+yw=
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Date: Mon, 23 Jun 2014 11:09:59 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: timeout in LDAP access
Message-ID: <20140623090959.GA1803@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> <20140618083304 DOT GV23700 AT calimero DOT vinschen DOT de> <20140618180102 DOT GA27055 AT calimero DOT vinschen DOT de> <FEEBC1A4-B147-45C1-A5AC-F5B9108E998F AT Denis-Excoffier DOT org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb"
Content-Disposition: inline
In-Reply-To: <FEEBC1A4-B147-45C1-A5AC-F5B9108E998F@Denis-Excoffier.org>
User-Agent: Mutt/1.5.23 (2014-03-12)

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

On Jun 19 19:53, Denis Excoffier wrote:
> On 2014-06-18 20:01, Corinna Vinschen wrote:
> > On Jun 18 10:33, Corinna Vinschen wrote:
> >>=20
> >>=20
> >> 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.
> >=20
> > I'm not quite sure I understand the effect of all the timeout values in
> > LDAP entirely correctly and the API documentation leaves quite a bit to
> > be desired.
> >=20
> > For the time being I raised the timeout to 30 seconds, and colons in
> > the gecos field are converted to semicolons.  I uploaded a new developer
> > snapshot to http://cygwin.com/snapshots/  Please give it a try.
>=20
> I tried the last snapshot. First the ${tr =E2=80=98:=E2=80=99 =E2=80=98;=
=E2=80=99} operation works perfectly,
> and the last field (of 'getent passwd' is now always the homedir. You may
> like to correct a typo in the ChangeLog, should be =E2=80=98semicolon=E2=
=80=99 instead of
> =E2=80=98comma=E2=80=99.
>=20
> Also, i tried with several different values for CYG_LDAP_TIMEOUT. With 45=
s, 60s,
> 115s and 125s, i obtained no timeout (outputing 500000 users takes 1h).
> I tried 3 times with 30s and got once with no timeout, once with one time=
out
> and once with 3 timeouts (ie one timeout for 3 domains).
>=20
> In any case, if you wish to switch to timeout=3D120s is ok for me.

Here's another question, which occured to me over the weekend:

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.

What I'm really concerned about is not the enumeration functionality
getpwent/getgrent, but the "normal" functions accessing a single
account.  Accessing a single account, even over a slow line, shouldn't
be that slow.  And even if it is, it's only the supplementary
information (gecos, home, shell, *iff* any of them is set in AD at all)
which might be wrong.  Do we really want to introduce a long timeout
for this?  I don't think so.

I'm rather inclined to revert the timeout for single account access to a
smaller value again (5 or 10 secs) and introduce a second, longer
timeout value for enumeration (60 secs, for instance).

I've applied a patch to ldap.cc to this effect.  Would you mind to give
it a try?

> The PageSize
> (100) could also be changed?

Yes, the pagesize can be changed, too.  I'm just not sure about the
consequences.  In my pretty small AD environment 100 seemed to be a
good compromise in terms of performance and size (as I mentioned, just
4 KB per page).  Less than 100 slowed down getent noticably, more than
100 didn't provide a visible speedup.

Can you test in your big environment in how far raising this value
changes the performance and the chance for timeout?  Since the load is
on the server, it should be pretty fast in collecting the next X SIDs.
I'm just a bit concerned about the (unnecessary?) network traffic this
might generate.

> Here two remarks about timeouts:
> 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 doma=
in,
> 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.

> 2) if value of timeout is not high enough (i have no figures=E2=80=A6), t=
imeout may
> occur when the PC is in fact occupied with other tasks (eg antivirus scan=
ning
> or something else), unrelated to network delays or server latencies.

No timeout is prepared for a CPU being 100% in use :|


Thanks,
Corinna

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

--VS++wcV0S1rZb1Fb
Content-Type: application/pgp-signature

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

iQIcBAEBAgAGBQJTp+7nAAoJEPU2Bp2uRE+gEuEP/R31yIHDIC7Hr/S1cCPDk4Iz
eEMXhybTE7R5L5Sr4sHTXal6qC2K7BvPPRpxAm5NOtxaQ+j7/04Mxkyqb6n/hpnb
dd6qoov68bkyjPV3NDSFsW61yVRewAOtdye1gq7QX1JU7Hq9YcQ2Vv60Z7PH+N2S
xj7OrMfeC+9pUPRhi0S1v60cSTFMNRZZeGuTCX7LKz7eIBRxgCxffeMRJtaOnf2H
Xigk6vY36gs9c2SkMwDg0XrPvCQb3byMYg5PqId41iR2qEb+IUhsVRho6/BPpI1w
KmPu7ZmlF69PkFM/evgxzhUAuBMOsQ64fo6s8lye+yf1qSaFQAcrPyXZYOyVB9FH
fhodkyMq/DfCbMvWQTPktAc2cYTdrnq8WtpgwHY8oWYpPVWY2vjBXVV4qVZozunF
daMyEqrM3UdH8b7zcbxX0IWg9X2Z054SMYjMwWs3PlPxiTzyhkEYWyHtnUAwCiP1
OUIDp4eq+dGXkYEcmafq9Li2m3EZio2ywVdWUNOHJcq7Gw9pP5DgCNxaRNyEkjtl
1y57+YDwCAhr3vKaOGz3RuRHNrbdDOsSzMA6GdWWiyevgZc5xcypUIik10M55f/X
tdPLYxNxRjj3SKuO+11OyIpW6Wi47NebzTwtkK97ezdyG8R2DHQPAwdUtQd48z8u
lrLAAj/0DQ/h4XGqeCuP
=T+ir
-----END PGP SIGNATURE-----

--VS++wcV0S1rZb1Fb--