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=GNNVSssol/CCTJym5bmmTr27sdPyp6Y2Etl4721RXkmZRe5f45eUI
	B39pTmOfVly4pia44hlHh/8GZO8w8Fbb3KlAaxerRqXIh/dww314xAOQqg/yNXSb
	W4mTtdH1UaOaKQPDB0jdope05Rx40nBJXcOiwgI1GNFo4SjCiGYQtw=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Date: Fri, 28 Feb 2014 18:14:24 +0100
From: Corinna Vinschen <corinna-cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: Testers needed:  New passwd/group handling in Cygwin
Message-ID: <20140228171424.GB2381@calimero.vinschen.de>
Reply-To: cygwin@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
References: <20140225200414.GA4238@calimero.vinschen.de> <87y50zaqjb.fsf@Rainer.invalid> <20140225215423.GA6065@calimero.vinschen.de> <loom.20140226T085959-119@post.gmane.org> <20140226100209.GR2246@calimero.vinschen.de> <20140226135222.GW2246@calimero.vinschen.de> <loom.20140227T095414-414@post.gmane.org> <loom.20140227T100638-8@post.gmane.org> <20140227094951.GD2246@calimero.vinschen.de> <8738j3dyvf.fsf@Rainer.invalid>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1;	protocol="application/pgp-signature"; boundary="V0207lvV8h4k8FAm"
Content-Disposition: inline
In-Reply-To: <8738j3dyvf.fsf@Rainer.invalid>
User-Agent: Mutt/1.5.21 (2010-09-15)

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

On Feb 28 16:45, Achim Gratz wrote:
> Corinna Vinschen writes:
> > 1 second?  That sounds still a bit slow.
>=20
> It appears that that there are multiple DC involved, either via
> delegation or redirection (as I've managed to get some partial group
> resolutions where groups from a particular domain were absent).  So all
> this slowness probably has to do with roundtrip times.  Based on that
> hypothesis I've done the same test again via DSL/VPN and got this:
>=20
> 1:49 stock-cvs
> 1:15 getgroups
> 0:13 noldap
>=20
> The times don't change all that much whether I've clogged the DSL
> connection or not, so the size of the response doesn't seem to be a
> major factor here.

I made some tests myself today, while debugging Frank's problem.  If I
had no network connection to my DC, the group names couldn't be
resolved.  This is using the stock LookupAccountSid function from
advapi32.dll so that means, the names of the groups are not cached
anywhere in LSA, not even the names of the current user's groups.

Given that, it was pretty surprising that the noldap code is so fast
compared to the getgroups version.  The LDAP connection is opened once
only, so the ldap request should be fast.  Even with a call to
LookupAccountSid and an additional call to ldap_search_st, I would
understand if the getgroups version takes twice as much as the noldap
version, but *8* times?

After some more testing it seems LookupAccountSid is asking the Global
Catalog (GC).  If I switch my LDAP queries to the GC port 3286, it's
getting a *lot* faster.  In fact, it's suddenly not 8 times slower,
but only two times, as expected.

Unfortunately that doesn't help us at all, because the POSIX attributes
are not duplicated to the GC by default, and I guess it's not exactly
helpful to ask administrators to duplicate the POSIX attributes to the
GC :(


Corinna

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

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

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

iQIcBAEBAgAGBQJTEMPwAAoJEPU2Bp2uRE+gXMEQAJJBWIIA1LEtlPmvxUHgTjK2
HWAZ7Tf/ftVlXbl2wAi/yXJQSQ16+zYKF69mvCVTYLGrz4fHOLyg1tJCpep/32qY
Z0bt9F8lJlnaoECeUm8VWrqnFCVjlnpgHy3vHYMeJWiY2DAsuTgqrtnAaidXW6vX
WkvSscQ1Nu++mOmTH8PCCgJ3pYHWp6R7peOuy9lm3r9iYyAafMYUVwBe9ZK/cKRZ
vA4W1MWwQMPNOQJkKxXd9GXi1VMmyVJNIHJlwOIed1i7mwrWY/CDkKkFByGxC7Jx
Eyk3xZYmyI6mKqQEoFdYo7OE97Bkn9e37lyGYuv3Xn7Yro2RLH0gQkpWHO+5BlJY
UOktml+JAoL+A0yu9JRNAz/ixG3EV3AP4nsu541O9CzrzNbLvShy5YBxVtgwaHLR
DJu+fRDPPwAIHioBnF93rQ2nNWAKbIs2abZJ5Lde0LXWCEytHHAprRi5y5lpL9zt
q69aPbpPrQnE/XqA9kVj4ndOJ/QEfgWkF543YNVMp6Yzl2n0H14S912quoNbFN+Z
+6SCf9BydJStvkeEw5ur7LXOKQoFWPrFA7tCICSX0QG6C4tgsmuUEj7FuqNHVxfJ
38vKURsMy8vcCwOyV+/PYdlIggjPSGsaNRdV9ie3Sprr+mOvr5FQBXedqapcLWwV
vgkcga71DL9k0BOER7pW
=wQVH
-----END PGP SIGNATURE-----

--V0207lvV8h4k8FAm--