On 2013-12-06 09:37, Dave Dykstra wrote:
> Hi Amos,
>
> Some of us are still unable to move to squid3 because of missing
> critical features (http://bugs.squid-cache.org/show_bug.cgi?id=7 and
Which squid-3 did you last experiment with? I think that squid-3 is
reducing this difference greatly as a problem ...
* squid-2 'fix' for bug-7 has the flaw of re-writing the entire object
back to disk when any header changes. Since you have the unusual case of
dealing with many big files this is a case which hits you particularly
hard even though your Squid is 'fixed'. The presence of bug-7 in squid-3
UFS will actually protect you from this disk I/O issue.
* Squid-3 contains the behaviour of migrating objects between cache and
memory where squid-2 kept them on-disk and simply had a memory reference
to the disk copy. As a result any objects which are able to be stored in
memory by squid-3 are not affected by bug-7. The behaviour for them is
identical to the fixed squid-2.
* squid-3.3+ also do HTTP/1.1 revalidation a lot better and more
efficiently than squid-2 did.
Some experimentation in needed to check for your particular use-case
but I suspect as long as your backend servers are responding to IMS/INM
requests quickly that the lag/overheads of Squid-2 re-writing the large
disk objects fully may be offset against the small delay of updating
only the headers over network.
Eliezer is looking into bug #7 again and has independently come up with
the same plan I had years back for resolving the issues in squid-2
behaviour. If experiments actually show that last point to still be
problematic
> http://bugs.squid-cache.org/show_bug.cgi?id=3495).
Have you tried that collapsed-forwarding branch? As far as I know it is
useable, just some minor details found in review to be fixed before it
gets merged.
> I support a
> distribution of squid2.7 for a few hundred universities & research labs
> https://twiki.cern.ch/twiki/bin/view/Frontier/InstallSquid
> I have been assuming that if a security problem were ever found with
> 2.7, there would still be a security advisory, and it would be
> announced
> on this mailing list so I could distribute a patch. Do you think that
> is a reasonable assumption? I also assume the security advisory would
> say the only official thing to do is to upgrade to squid3, which is
> fine
> as long as I could still patch 2.7.
Well I hesitate to say anything on this as it is hard to know. Squid-2.7
is benefiting from both its long history of stable use (low level of
vulnerabilities existing) and from being outdated (nasties have less
incentive to seek vulnerabilities).
I'm not even testing recent vulnerabilities against 2.x myself any more
beyond a quick manual check to see if the 2.x and 3.x code is similar in
the particular area (SQUID-2012:1, SQUID-2011:3).
Most of the recent vulnerabilities have been in code which was changed
between the versions and somebody got something wrong (SQUID-2013:1,
SQUID-2013:3) or uncovered a code path protecting against some hidden
issue elsewhere (SQUID-2013:2). A few are long standing design
vulnerabilities which we finally re-designed squid-3.x in a way that
allowed fixing it - so squid-2 will definitely never be fixed
(SQUID-2011:1, SQUID-2011:2).
Amos
Received on Thu Dec 05 2013 - 22:17:40 MST
This archive was generated by hypermail 2.2.0 : Fri Dec 06 2013 - 12:00:04 MST