[squid-users] RPM for centos is out.. (i686 + x86_64) with StoreID

I compiled a new RPM for the beta testers and or people who want to test
newer code of ROCK and STOREID.

So now the RPM build is explicitly not using "march=native" which should
add couple more machines out-there that the RPM will work on...
The RPM build is design for 64bit CPU but has a 32bit version.

The tests that was done until now on the RPMs are:
- Compilation using the generic squid options (minus\less)march=native
of both 64 and 32 bit versions.
- Startup and usage on ram and rock cahce_dir.
- StoreID function works good.(appended small background on StoreID)
- StoreID helper that uses a DB file for pattern works in a format of
"regex - tab or more - response based on the request matches" examples
in the patter DB which is provided in the wiki.
- loading a page with more then 80 object which all took about 80 new
connections.
- stress testing the helper which doesn't have any ttl to cache the
response compared to external_acl.(add acls that will lower the stress
on the helper)
- init.d script seems to work well for now but maybe needs a tweak.

* yet to be tested using intercept\tproxy\accel.

more info can be found at the wiki:
http://wiki.squid-cache.org/KnowledgeBase/CentOS#Squid-3.4_-Beta

The RPM can be downloaded from here:
http://www1.ngtech.co.il/rpm/centos/6/x86_64/beta/

This is the second release of 3.4 branch.

There are couple bug fixes and couple new features in it.
There is, also the StoreID feature which has documentation at wiki:
http://wiki.squid-cache.org/Features/StoreID

A small introduction to StoreID.
================================
StoreID relays on the fact that a url identifies one content can also be
identified by another url which has different domain different port
different location and different headers.
Since all the above are true then there is an option to assume that two
urls can serve the same content using different properties of the HTTP
request such as url.
While all the above is true if I would for example ask a storage engine
that stores files content hash *only* I would just ask for the let say
md5 hash and it will retrieve the wanted content.
Squid works the other way then plain HASH.
Squid actually understands the request properties such as url headers
and other properties of the requests and verifies if the currently
stored *object* is the right one to return the client or in a case that
a re-validation with the server is needed the re-validation is done to
make sure the client is satisfied.

After all the above a small example will be:
http://www1.ngtech.co.il/rpm/centos/6/x86_64/beta/squid-3.4.0.2-1.el6.x86_64.rpm.asc
Which is the digital signatures that squid rpm V 3.4.0.2 has.
you can also get the same file at:
http://repo.ngtech.co.il/rpm/centos/6/x86_64/beta/squid-3.4.0.2-1.el6.x86_64.rpm.asc

The repo.ngtech.co.il is a nice resource and is a reliable one which
will verify that the file comes from www1.ngtech.co.il.

In a case an admin knows the above he can deduplicate any content under:
http://repo.ngtech.co.il/rpm/
http://www1.ngtech.co.il/rpm/
to:
http://repo.ngtech.co.il.squid.internal/rpm/

which the pattern will be identified by a line
^http:\/\/(www1|repo)\.ngtech\.co\.il\/rpm/(.*)
http://repo.ngtech.co.il.squid.internal/rpm/$2

There is a small mirror pattern DB which I look forward to expand at:
http://wiki.squid-cache.org/Features/StoreID/DB

You can see that there are patterns of ubuntu mirrors in the list but
There should be explicit rules to make sure that at least the repo DB
will be downloaded from a 100% reliable server to verify that all the
rpm files are not corrupted in any-way.

New log features
================
In 3.4.0.2 we can see how logs looks and will understand them better and
with example:
#start
1381024746.672 2211 192.168.10.146 TCP_REFRESH_UNMODIFIED/304 396 GET
http://repo.ngtech.co.il/rpm/centos/6/supported.txt -
HIER_DIRECT/58.28.153.233 -
1381024764.417 20 192.168.10.146 TCP_REFRESH_FAIL_OLD/200 779 GET
http://www1.ngtech.co.il/rpm/centos/6/supported.txt -
HIER_DIRECT/84.95.212.160 text/plain
#end

The Above logs describe that the client requested a refresh for already
cached object from the origin server and then requested the mirrored
file while the origin server was not running.
I shows how squid caches content in the extent of almost-offline situation.

If you see some log entries that start with TCP_XYZ_XYZ don't panic
since this is the way it should be.

Release 2 of the RPM
====================
Since there were intensive testing going on in the background on this
version there is a first release which works and there is a second release.
Second release supports ROCK cache_dir.
On the next beta 3.4.0.3 I will try to write more about ROCK cache_dir.

Eliezer

On 10/05/2013 09:25 AM, Amos Jeffries wrote:
> The Squid HTTP Proxy team is very pleased to announce the
> availability of the Squid-3.4.0.2 beta release!
>
>
> The Squid-3.4 series is dedicated to Dmitry Kurochkin who died
> in an accident on July 21, 2013. His work directly underpins several
> of the major and popular performance and stability changes for
> recent and upcoming Squid-3 series.
>
>
> This new 3.4 series of Squid brings useful new features and changes
> providing improved stability over earlier release series.
>
> More detailed descriptions of the major new features are available in
> the release notes and wiki:
> http://www.squid-cache.org/Versions/v3/3.4/RELEASENOTES.html
> http://wiki.squid-cache.org/Squid-3.4

<SNIP>

>
> If you encounter any issues with this release please file a bug report.
> http://bugs.squid-cache.org/
>
> Amos Jeffries
>
Received on Sun Oct 06 2013 - 02:42:21 MDT