Re: [squid-users] squid3 WindowsUpdate failed

Alex Rousskov wrote:
> On Wed, 2007-10-31 at 23:45 +0800, John Mok wrote:
>
>> But my problem is that I need ICAP client support in squid 3.0. As been
>> recommended by Christos Chtsanti, the ICAP support in squid 3.0 is
>> better and more stable than 2.6 + ICAP patch.
>
> Christos was right.
>
>> In that case, can anyone
>> advise whether I should go 2.6 + ICAP patch, or squid 3.0 RC1 for
>> production environment (approx. 300 users).
>
> What you should do is submit a Squid3 bug report with full debugging
> logs collected when the Windows Update problem is happening. Once there
> is enough information, Squid3 bugs are usually get fixed pretty fast.
> The developers that want to help you do not have enough information to
> fix the bug...
>
> An alternative is to file a bug report and explain exactly how to
> reproduce the bug for somebody who has a single Windows XP box and knows
> little about Windows Update.
>
> Thank you,
>
> Alex.
>
>
>> Jorge Bastos wrote:
>>> I forgive you.
>>> But just this once :P
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Jason.Fitzpatrick@leaseplanis.com
>>> [mailto:Jason.Fitzpatrick@leaseplanis.com]
>>> Sent: quarta-feira, 31 de Outubro de 2007 11:09
>>> To: mysql.jorge@decimal.pt
>>> Cc: squid-users@squid-cache.org
>>> Subject: RE: [squid-users] squid3 WindowsUpdate failed
>>>
>>> As I said, just me being lazy,, sorry about that!
>>>
>>> -----Original Message-----
>>> From: Jorge Bastos [mailto:mysql.jorge@decimal.pt]
>>> Sent: 31 October 2007 10:43
>>> To: squid-users@squid-cache.org
>>> Subject: RE: [squid-users] squid3 WindowsUpdate failed
>>>
>>> Not an option, at least for me.
>>> I think that is not the way to resolve things.
>>> This problem with WU may happen with other things, and the correct way if
>>> to fix this, not using other software.
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: Jason.Fitzpatrick@leaseplanis.com
>>> [mailto:Jason.Fitzpatrick@leaseplanis.com]
>>> Sent: quarta-feira, 31 de Outubro de 2007 10:29
>>> To: squid3@treenet.co.nz; reinhard.haller@interactive-net.de
>>> Cc: squid-users@squid-cache.org
>>> Subject: RE: [squid-users] squid3 WindowsUpdate failed
>>>
>>> Hi all..
>>>
>>> I know that this is not the answer that you are looking for, but why not
>>> just install a WSUS server internally? Then point all your clients to it
>>> via AD policy. (me being a lazy bugger here!)
>>>
>>> Jay
>>>
>>> -----Original Message-----
>>> From: Amos Jeffries [mailto:squid3@treenet.co.nz]
>>> Sent: 31 October 2007 02:43
>>> To: Reinhard Haller
>>> Cc: squid-users@squid-cache.org
>>> Subject: Re: [squid-users] squid3 WindowsUpdate failed
>>>
>>>> Amos Jeffries schrieb:
>>>>> John Mok wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I am using Squid3 nightly built 20071026 running on Ubuntu 6.06 LTS
>>>>>> with the compilation options :-
>>>>>>
>>>>>> ./configure --with-pthreads --enable-icap-client
>>>>>>
>>>>>> I tried both (i) the configurations with default option, or (ii)
>>>>>> icap-enabled options, the Windows client failed to get WindowsUpdate
>>>>>> (see the following log).
>>>>>>
>>>>> Where is this failure you speak of?
>>>>> The log you posted showed a proper link to WindowsUpdate, with all
>>>>> the static content coming from cache (TCP_HIT/TCP_IMS_HIT) and the
>>>>> dynamic pages and updates being brought in from M$ (TCP_MISS)
>>>>>
>>>>> If your client got the custom M$ "Windows Update failed" page.
>>>>> Then I suspect you have overlooked a M$ nasty:
>>>>> WU requires an HTTPS 'validation' test.
>>>>> You MUST permit an HTTP 'CONNECT' request to 65.55.184.125:443.
>>>>> (the IPA being that of www.update.microsoft.com from your current
>>>>> location)
>>>>>
>>>>> This bypass needs to be made on your firewall. WU will NOT always
>>>>> attempt it through the configured proxy :-(
>>>>>
>>>>> The best you can do is bypass it at the FW and also configure the
>>>>> proxy manually in IE, then run "proxycfg -u" in command line on the
>>>>> windows box, and hope that the particular box update level will use
>>>>> the proxy for it.
>>>>>
>>>>>
>>>>> Amos
>>>> Sorry Amos,
>>>>
>>>> the problem exists! It appeared with squid 3.0 RC1. After the
>>>> downgrade to 2.6 (urlgroup is missing in 3.0) I don't have any
>>>> problem
>>> with WU.
>>>> The bypass in the firewall is not needed for proper operation.
>>> Lucky you, looks like you have a good up-to-date user base then :). Mine
>>> have trouble in WinXP SP1 and some earlier versions of the ActiveX WU'er
>>> they call MicrosoftUpdate. GenuineAdvantage my a*%#.
>>>
>>>> Reinhard
>>>>
>>> IIRC others earlier found that WU used range requests to speed downloads.
>>> I have never confirmed this myself.
>>>
>>> Anyway, a bug has just been found in 3.0.RC1 that caused certain range
>>> requests to close prematurely.
>>> http://www.squid-cache.org/bugs/show_bug.cgi?id=2116
>>>
>>> A fix has been incorporated in the next daily snapshot. If anyone is
>>> having this problem with 3.0.RC1, please give the 31 Oct or later
>>> snapshots a try and see if that fixes your problem.
>>> If its still present it will need to be reported as a bug with traces,
>>> etc.
>>> Thank you.
>>>
>>> Amos
>>>

I have just had the opportunity to do WU on a customers box and
managed to reproduce one of the possible WU failures.

This one was using WinXP, and the old WindowsUpdate (NOT
MicrosoftUpdate, teht remains untested). With squid configured to permit
client access to:

# Windows Update / Microsoft Update
#
redir.metaservices.microsoft.com
images.metaservices.microsoft.com
c.microsoft.com
windowsupdate.microsoft.com
#
# WinXP / Win2k
.update.microsoft.com
download.windowsupdate.com
# Win Vista
.download.windowsupdate.com
# Win98
wustat.windows.com
crl.microsoft.com

AND also CONNECT access to www.update.microsoft.com:443

PROBLEM:
   The client box detects a needed update,
   then during the "Download Updates" phase it says "...failed!" and stops.

CAUSE:

This was caused by a bug in squid reading the ACL:
   download.windowsupdate.com
      ...
   .download.windowsupdate.com

  - squid would detect that download.windowsupdate.com was a subdomain
of .download.windowsupdate.com and .download.windowsupdate.com would be
culled off the ACL as unneeded.

  - That culled bit held the wildcard letting v4.download.* and
www.download.* be retrieved later in the process.

  - BUT, specifying JUST .download.windowsupdate.com would cause
download.windowsupdate.com/fubar to FAIL under the same circumstances.

during the WU process requests for application at
www.download.windowsupdate.com/fubar and K/Q updates at
v(3|4|5).download.windowsupdate.com/fubar2
would result in a 403 and thus the FAIL.

SOLUTION:
  Changing the wildcard match to an explicit for fixes this and WU
succeeds again.
OR,
  Changing the wildcard to .windowsupdate.com also fixes the problem for
this test.

Amos
Received on Sun Nov 04 2007 - 00:30:43 MDT