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. > >
