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.
-----Original Message-----
From: Alex Rousskov [mailto:rousskov@measurement-factory.com]
Sent: ter�a-feira, 6 de Novembro de 2007 15:19
To: Jorge Bastos
Cc: squid-users@squid-cache.org
Subject: RE: [squid-users] 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@measurement-factory.com]
> Sent: segunda-feira, 5 de Novembro de 2007 16:31
> To: Amos Jeffries
> Cc: John Mok; squid-users@squid-cache.org
> Subject: Re: [squid-users] 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.
>
>
Received on Wed Nov 07 2007 - 02:18:09 MST
This archive was generated by hypermail pre-2.1.9 : Sat Dec 01 2007 - 12:00:02 MST