Sorry I realize my answer was a bit unclear. I should not try to rush
these things.
On 18/03/2014 9:49 a.m., Amos Jeffries wrote:
> On 2014-03-18 05:06, Alan wrote:
>> On Mon, Feb 3, 2014 at 4:18 PM, Amos Jeffries wrote:
>>> * Fix external_acl_type async loop failures
>>>
>>> This issue shows up as extra failed authentication checks if the
>>> external ACL uses %LOGIN format code and credentials are not already
>>> known. This can have nasty side effects when combined with NTLM in older
>>> 3.4 releases.
>>
>> Will this be backported to the 3.3 series?
> Doubtful. This was a regression fix for a bug added in the 3.4.0.1 ACL
> redesign as far as I can tell.
Hope that clarifies.
>> How bad is it when using
>> Kerberos instead of NTLM?
>>
This bug does not seem to affect Kerberos. Mainly due to the optimized
handshake process there.
* It may still show up a bit though if users login with wrong credentials.
* It will definitly still show up for Negotiate/NTLM handshakes as much
as native NTLM ones. This may be related to *some* negotiate_wrapper
failures, though the commonly reported issue with that helper is
something else entirely.
>> I can't update to 3.4 because of the cpu usage problem described in
>> the thread titled "squid 3.4. uses 100% cpu with ntlm_auth".
>>
>> Would it be too optimistic to think that this fix solves the cpu usage
>> problem?
>
I suspect it is at least part of that report, though some of the
mentions did not seem to have external ACL in a way to trigger this one.
There are also several configuration reasons possible for achieving 100%
CPU with NTLM that have nothing to do with bugs in Squid or even HTTP.
In short, it is worth checking again with 3.4.4 to be sure for your case.
If the 100% CPU issue still occurs a bit better analysis is still needed.
Amos
Received on Tue Mar 18 2014 - 04:21:10 MDT
This archive was generated by hypermail 2.2.0 : Tue Mar 18 2014 - 12:00:06 MDT