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:mime-version:content-type
	:content-transfer-encoding:message-id:date:from:to:subject
	:in-reply-to:references; q=dns; s=default; b=ibAAIbsLNF3du1BVbUY
	baoYpuJAqAKRauP3vZblOZ1xcV9ug7PRUcgcbYmw14jrWJYsF84FkqFy+QXqci6f
	1mzju/ARouTOg/HaImHTxwLNdvKUgY7r/ke42ALJCV1gHf0pwPQXD1D9xCiILhZM
	SYwML/5eOxz6uHWR51pD6y2k=
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:mime-version:content-type
	:content-transfer-encoding:message-id:date:from:to:subject
	:in-reply-to:references; s=default; bh=e917uTB6MBoGGeVxR0utYAN1Z
	1E=; b=vAdBzc9FA4E5PKbiVDo74GIrowfhPLpssydJbzi07ZhtXQsGz3AYBwfLC
	c873VvhgVgkS6ALHRcFGYYAiTuHbENfhMUhur5MZFTs9A9gfN5r8M7Tq2mbpLdIW
	bIBChhEo1SF4htzg7D37VEwtoY03I3QNvfeHSpXeyCI5K826jA=
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=0.3 required=5.0 tests=AWL,BAYES_00,HK_RANDOM_ENVFROM,HK_RANDOM_FROM,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2
X-HELO:	sneak2.sneakemail.com
MIME-Version:	1.0
Message-ID:	<6695-1424465180-282140@sneakemail.com>
Date:	Fri, 20 Feb 2015 13:46:17 -0700
From:	"John Hein" <3fbmqnhaz4 AT snkmail DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: TEST RELEASE: Cygwin 1.7.35-0.3
In-Reply-To:	<20150220102927.GR26084@calimero.vinschen.de>
References:	<20150220102927 DOT GR26084 AT calimero DOT vinschen DOT de>

Corinna Vinschen wrote at 11:29 +0100 on Feb 20, 2015:
 > On Feb 19 17:29, John Hein wrote:
 > > Corinna Vinschen wrote at 11:59 +0100 on Feb 18, 2015:
 > >  > Hi Cygwin friends and users,
 > >  >
 > >  > I released another very early TEST version of the next upcoming Cygwin
 > >  > release.  The version number is 1.7.35-0.3.
 > >  >
 > >  > This release introduces a revision of the LDAP calls done to fetch
 > >  > information from the DC.  By limiting the search scope, the calls should
 > >  > now be faster even in bigger environments.  Please give it a try with
 > >  > activated "db" settings for passwd and group entries in /etc/nsswitch.conf
 > >  >
 > >  >   passwd: db
 > >  >   group: db
 > >  >
 > >  > Please report back your experience, especially if you're suffering
 > >  > from "slow startup" problems.
 > >
 > > Without 'files' in /etc/nsswitch.conf or 'cygserver' running, the
 > > testing cycle here is slow.  So I've been a bit delayed at reporting
 > > back.  I know some people have alleged wonderful speedups with
 > > 1.7.35-0.3, but I can't report the same.
 > >
 > > Here I'm in an AD environment with ~8000 entries in AD (as determined
 > > by 'mkpasswd -d | wc') and I'm in 200+ groups.  I guess I'd call it
 > > somewhat large, and the network is geographically spread out and
 > > connected by links that vary in speed (the slowest is probably 10s of
 > > Mbps), although there is a local AD "slave" on the local LAN.
 > >
 > > It's particularly slow if I force using my shell of choice (tcsh)
 > > rather than forcing '/bin/dash' as the 'db_shell' entry in
 > > nsswitch.conf.  This is likely because of all the various things that
 > > get executed at shell startup (csh.cshrc, profile.d/*.csh).
 >
 > Just as Achim reported in
 > https://cygwin.com/ml/cygwin/2015-02/msg00608.html
 >
 > You may read my reply in
 > https://cygwin.com/ml/cygwin/2015-02/msg00610.html
 >
 > It would be nice to keep this stuff together in a single thread.
 >
 > I'm willing to work on this stuff, but I need patient testers :}


Understood.

I can move to the other tcsh related thread you mentioned (I don't
know if I'll have much to add at this point other than 'me too', but
I'll try to catch up).  I hadn't seen any mention of mkpasswd in that
thread.  Should I drag that discussion into the other thread?  I did
find what I thought were some interesting results on 'strace -t
mkpasswd -d'.  See below.  If you want this info in that thread, I'll
do so.



 > > Also mkpasswd -d seems to be taking a long time (haven't had it
 > > complete in hours now).  That didn't happen with 1.7.34 - maybe
 > > there's a local issue here on our network.
 >
 > In theory, the mkpasswd call should be the same as before.  The LDAP
 > call performed to enumerate the domain hasn't changed, unless...
 > I made a single change in the filter expression for the user search:
 >
 > Before
 >
 >   filter = "(&(objectClass=User)"
 > 	     "(objectCategory=Person)"
 > 	     "(userAccountControl:" LDAP_MATCHING_RULE_BIT_AND ":=512)"
 > 	     "(objectSid=*))";
 >
 > After:
 >
 >   filter = "(&(objectCategory=Person)"
 > 	     "(objectClass=User)"
 > 	     "(userAccountControl:" LDAP_MATCHING_RULE_BIT_AND ":=512)"
 > 	     "(objectSid=*))";
 >
 > So I just changed the order of the objectClass and objectCategory test.
 > If that's really the culprit, you can easily test it:
 >
 > Revert to the Cygwin 1.7.34-6   DLL, run `time mkpasswd -d >/dev/null'
 > Revert to the Cygwin 1.7.35-0.3 DLL, run `time mkpasswd -d >/dev/null'
 > Revert to the Cygwin 1.7.34-6   DLL, run `time mkpasswd -d >/dev/null'
 > Revert to the Cygwin 1.7.35-0.3 DLL, run `time mkpasswd -d >/dev/null'
 >
 > Does that clearly show that 1.7.34-6 is faster performing the enumeration?
 > If so, and despite my total puzzlement, the order in the expression seem
 > to have an effect.


mkpasswd w/1.7.35-0.3 finally finished - took about 5+ hours and only
returned ~1800 results instead of ~8000.

mkpasswd w/1.7.33 took about 50 minutes.  This was mostly after peak
business hours, however (not clear how much that matters).

Trying 1.7.34-6 now.  Looks like it's going to be slow.  It's been
two hours and only about 200 entries have trickled in.

Slow going here.  Note this last run is under strace (see below), so
not exactly what you suggested.  I'll try without strace and redirecting
to /dev/null to see if it matters after this test finishes (if ever).



 > > What's a good way to debug
 > > what's happening with mkpasswd?  Seems like its not doing anything.
 >
 > Well, it works for me.  And since mkpasswd basically calls into the
 > Cygwin DLL to enumerate, it's not mkpasswd as such, but the Cygwin DLL
 > which is the culprit.
 >
 > But, if you want to be sure mkpasswd is doing "something", just don't
 > redirect its output to a file, so the output goes to your terminal.

I did one better than running with output to the terminal.  As
mentioned above I ran strace on it.  I can see activity in the strace
output file.  But it's taking surprisingly long to get results -
trickling in one entry at a time with minutes between each.  Like so:

 .
 .
00:47:09 [main] mkpasswd 10164 pwdgrp::fetch_account_from_windows: line: <Joe.Blow:*:1103416:1049089:U-SOMEBIGCORP\Joe.Blow,S-1-5-21-1643024071-179607362-792003330-52840:/home/Joe.Blow:/bin/dash>
00:51:56 [main] mkpasswd 10164 pwdgrp::fetch_account_from_windows: line: <John.Doe:*:1103637:1049089:U-SOMEBIGCORP\John.Doe,S-1-5-21-1643024071-179607362-792003330-53061:/home/John.Doe:/bin/dash>
00:56:44 [main] mkpasswd 10164 pwdgrp::fetch_account_from_windows: line: <Jane.Doe:*:1103626:1049089:U-SOMEBIGCORP\Jane.Doe,S-1-5-21-1643024071-179607362-792003330-53050:/home/Jane.Doe:/bin/dash>
 .
 .

So it's chugging away... just really very slowly.  Sometimes as
"quickly" as a couple minutes per entry.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -