From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27500 invoked by alias); 28 Feb 2014 17:14:29 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Received: (qmail 27484 invoked by uid 89); 28 Feb 2014 17:14:28 -0000 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 Received: from aquarius.hirmke.de (HELO calimero.vinschen.de) (217.91.18.234) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 28 Feb 2014 17:14:27 +0000 Received: by calimero.vinschen.de (Postfix, from userid 500) id CFA4752044A; Fri, 28 Feb 2014 18:14:24 +0100 (CET) Date: Fri, 28 Feb 2014 17:43:00 -0000 From: Corinna Vinschen 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> <20140226100209.GR2246@calimero.vinschen.de> <20140226135222.GW2246@calimero.vinschen.de> <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) X-SW-Source: 2014-02/txt/msg00744.txt.bz2 --V0207lvV8h4k8FAm Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 2001 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 Content-length: 819 -----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--