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@xxxxxxxxxxxxxxx
[mailto:Jason.Fitzpatrick@xxxxxxxxxxxxxxx]
Sent: quarta-feira, 31 de Outubro de 2007 11:09
To: mysql.jorge@xxxxxxxxxx
Cc: squid-users@xxxxxxxxxxxxxxx
Subject: RE: squid3 WindowsUpdate failed
As I said, just me being lazy,, sorry about that!
-----Original Message-----
From: Jorge Bastos [mailto:mysql.jorge@xxxxxxxxxx]
Sent: 31 October 2007 10:43
To: squid-users@xxxxxxxxxxxxxxx
Subject: RE: 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@xxxxxxxxxxxxxxx
[mailto:Jason.Fitzpatrick@xxxxxxxxxxxxxxx]
Sent: quarta-feira, 31 de Outubro de 2007 10:29
To: squid3@xxxxxxxxxxxxx; reinhard.haller@xxxxxxxxxxxxxxxxxx
Cc: squid-users@xxxxxxxxxxxxxxx
Subject: RE: 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@xxxxxxxxxxxxx]
Sent: 31 October 2007 02:43
To: Reinhard Haller
Cc: squid-users@xxxxxxxxxxxxxxx
Subject: Re: 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
