directory-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rich Remington <>
Subject Re: weird caching behavior?
Date Sun, 14 Sep 2008 18:48:01 GMT
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.


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)

View raw message