From users-return-1786-apmail-directory-users-archive=directory.apache.org@directory.apache.org Sun Sep 14 18:48:35 2008 Return-Path: Delivered-To: apmail-directory-users-archive@www.apache.org Received: (qmail 46085 invoked from network); 14 Sep 2008 18:48:35 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 14 Sep 2008 18:48:35 -0000 Received: (qmail 80325 invoked by uid 500); 14 Sep 2008 18:48:31 -0000 Delivered-To: apmail-directory-users-archive@directory.apache.org Received: (qmail 80286 invoked by uid 500); 14 Sep 2008 18:48:31 -0000 Mailing-List: contact users-help@directory.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@directory.apache.org Delivered-To: mailing list users@directory.apache.org Received: (qmail 80275 invoked by uid 99); 14 Sep 2008 18:48:31 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 14 Sep 2008 11:48:31 -0700 X-ASF-Spam-Status: No, hits=1.2 required=10.0 tests=SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: 76.96.30.17 is neither permitted nor denied by domain of rich@remingtons.us) Received: from [76.96.30.17] (HELO QMTA10.emeryville.ca.mail.comcast.net) (76.96.30.17) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 14 Sep 2008 18:47:31 +0000 Received: from OMTA03.emeryville.ca.mail.comcast.net ([76.96.30.27]) by QMTA10.emeryville.ca.mail.comcast.net with comcast id EdHG1a0070b6N64AAio3eU; Sun, 14 Sep 2008 18:48:03 +0000 Received: from BigMac.local ([75.71.40.223]) by OMTA03.emeryville.ca.mail.comcast.net with comcast id Eio11a00B4ot8aK8Pio2hc; Sun, 14 Sep 2008 18:48:02 +0000 X-Authority-Analysis: v=1.0 c=1 a=3M6lAGHTv3nPV5LT_bYA:9 a=4U2acDq_bVzp4L1EuWKBxOs4fA8A:4 a=0HbQqGD8AL8A:10 Message-ID: <48CD5C61.4020801@remingtons.us> Date: Sun, 14 Sep 2008 12:48:01 -0600 From: Rich Remington User-Agent: Thunderbird 2.0.0.16 (Macintosh/20080707) MIME-Version: 1.0 To: users@directory.apache.org Subject: Re: weird caching behavior? References: <48CA686F.9090307@remingtons.us> <48CA6A7E.1060209@nextury.com> <48CA96FB.7000209@remingtons.us> <48CA9904.5090200@nextury.com> <48CAABEF.1070908@remingtons.us> <48CAB386.700@nextury.com> <48CAB9A8.5020306@remingtons.us> <48CCC12B.4020500@nextury.com> In-Reply-To: <48CCC12B.4020500@nextury.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Okay, for those who are on the edge of their seats waiting to find out the answer whether an upgrade fixed the issue I was experiencing... The answer is a definite yes - for now! We still need to test some more scenarios, but this still begs the question as to why I was seeing this behavior in version 1.0.2. At least I am able to move ahead, now. And, to answer your question below about binding with the new password using Studio: No, I was not able to bind with the new password using Studio or the webapp - even though I can see the new password value (for the user whose password was changed) when logged in as the admin user, so it appears this is an issue inside the (version 1.0.2) LDAP server. HTH, Rich Emmanuel Lecharny wrote: > Rich Remington wrote: >> I am using the standalone server. BTW, the password is seen right >> after the change AND after a reboot of the standalone server, so the >> password change is permanent - even if not written to disk >> immediately. The problem still remains that between the time it is >> changed by the webapp and before the reboot of the LDAP server, >> webapp attempts to bind with the new password fail, but binding with >> the old password works. > And you can bind with the new password using Studio ? >> >> Weird... >> >> I will upgrade to 1.5.4 in the meantime and let you know if this is >> fixed. Are there any config migration tools and/or tips? Will LDIF >> export/import just work? > 1.5.4 has been released, and is available. Export and re-import using > LDIF, there is no other way atm. (be carefull : if you have changed > the schema, then you have to modify it on the new version) > >