Jorge Bastos wrote:
I can help, both parts are interested in this, me and squid.
I asked the squid3 debian package maintainer to upload the daily sources
again to test.
I don't want to compile the sources since I always use binary's.
I'll let you know when I'll have news.
If you want to ask the maintainer to upload the daily sources again, that
may reforce my need for it and he may do it.
May be a login wait. Luigi seems to have a large workload and/or not
much time. There appears to be a few weeks worth of delay for things
outside the critical bugs or formal release cycle. Although this sot of
falls into both.
You can build your own squid easily enough, and the --suffix and
--prefix configure options allow you to segregate it nicely from any
packaged squid setup on the same machine.
Amos
-----Original Message-----
From: Alex Rousskov [mailto:rousskov@xxxxxxxxxxxxxxxxxxxxxxx]
Sent: terça-feira, 6 de Novembro de 2007 15:19
To: Jorge Bastos
Cc: squid-users@xxxxxxxxxxxxxxx
Subject: RE: squid3 WindowsUpdate failed
On Tue, 2007-11-06 at 09:24 +0000, Jorge Bastos wrote:
Alex,
The only ACL i have in squid.conf is:
---
acl all_cache src 0.0.0.0/0.0.0.0
no_cache deny all_cache
---
OK, thanks.
I'm one of the people who's having this problems.
Now I'm using 3.0.PRE6 until this is fixed.
Can you help us troubleshoot the problem? Can you run the latest Squid3
daily snapshot and collect full debugging (debug_options ALL,9) logs
when Windows Update is malfunctioning?
Thank you,
Alex.
-----Original Message-----
From: Alex Rousskov [mailto:rousskov@xxxxxxxxxxxxxxxxxxxxxxx]
Sent: segunda-feira, 5 de Novembro de 2007 16:31
To: Amos Jeffries
Cc: John Mok; squid-users@xxxxxxxxxxxxxxx
Subject: Re: squid3 WindowsUpdate failed
On Sun, 2007-11-04 at 19:30 +1300, Amos Jeffries wrote:
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.
Can other folks experiencing Windows Update troubles with Squid3 confirm
that their setup does not have the same ACL problem?
In general, if we do not find a way to get more information about the
Windows Update problem, we would have to assume it does not exist in
most environments and release Squid3 STABLE "as is". If you want the
problem fixed before the stable Squid3 release, please help us reproduce
or debug the problem.
Thank you,
Alex.
