[squid-users] 32bit (i386) squid 3.5 cache dir size

Mon Nov 30 17:12:34 UTC 2015

Hi,

Where did you find a 32-bit version of Squid?

Thanks
Patrick

-----Original Message-----
From: squid-users [mailto:squid-users-bounces at lists.squid-cache.org] On Behalf Of squid-users-request at lists.squid-cache.org
Sent: Monday, November 30, 2015 11:55 AM
To: squid-users at lists.squid-cache.org
Subject: squid-users Digest, Vol 15, Issue 116

Send squid-users mailing list submissions to
	squid-users at lists.squid-cache.org

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.squid-cache.org/listinfo/squid-users
or, via email, send a message with subject or body 'help' to
	squid-users-request at lists.squid-cache.org

You can reach the person managing the list at
	squid-users-owner at lists.squid-cache.org

When replying, please edit your Subject line so it is more specific than "Re: Contents of squid-users digest..."

Today's Topics:

   1. Re: 32bit (i386) squid 3.5 cache dir size limit? (Alex Rousskov)
   2. missing icap respmod request when the web object is found in
      the cache? (Giray Simsek)
   3. Re: 2 way SSL on a non standard SSL Port (Bart Spedden)

----------------------------------------------------------------------

Message: 1
Date: Mon, 30 Nov 2015 09:48:25 -0700
From: Alex Rousskov <rousskov at measurement-factory.com>
To: squid-users at lists.squid-cache.org
Subject: Re: [squid-users] 32bit (i386) squid 3.5 cache dir size
	limit?
Message-ID: <565C7DD9.1080803 at measurement-factory.com>
Content-Type: text/plain; charset=utf-8

On 11/30/2015 04:28 AM, Amos Jeffries wrote:
> On 30/11/2015 11:59 p.m., TarotApprentice wrote:
>> I am setting up a backup proxy server using an old P4 machine which 
>> can only do 32bit. As its only got 1Gb of RAM its not going to hit 
>> the 32bit limit on memory, but what about the cache_dir? Is it 
>> limited to 32bit addressability (ie 4Gb) max size?

> No. It should still be capable of using a larger cache_dir size. The 
> 32-bit limits apply on a per-file basis (unless large-file support has 
> been built in).

but note that Rock store uses a single disk file for the entire cache_dir and, hence, is at your file system mercy as far as cache_dir size limits are concerned.

Alex.

------------------------------

Message: 2
Date: Mon, 30 Nov 2015 08:53:22 -0800
From: Giray Simsek <giray_simsek at hotmail.com>
To: "squid-users at lists.squid-cache.org"
	<squid-users at lists.squid-cache.org>
Subject: [squid-users] missing icap respmod request when the web
	object is found in the cache?
Message-ID: <BLU184-W58CB5DE6176AE2A4F250FAFE000 at phx.gbl>
Content-Type: text/plain; charset="iso-8859-1"

Hi,I am using squid + c-icap for content adaptation.I noticed that when squid is able to find the requested html page in its cache, it does the following;1) It does not send an http get request to the external web server since the html is already in the cache. I think this makes sense.2) It does NOT send an icap RESPMOD request to the Icap server. I was expecting it to still send the icap request to the icap server in this case.Is there a way to tell squid to send the Respmod request to the icap server in the case when the requested html page is found in the cache?By the way, I am verifying that the object is found in the cache since I see the following line in squid's access.log:1448901021.850     96 10.0.0.9 TCP_MEM_HIT/200 315485 GET http://192.168.0.12/poems.html - HIER_NONE/- text/htmlAlso, here is how my squid configuration looks like:icap_enable onicap_send_client_ip onicap_send_client_username onicap_client_username_header X-Client-Usernameicap_service service_req_14 reqmod_precache bypass=on icap://127.0.0.1:1344/request_checkadaptation_access service_req_14 allow allicap_service service_resp_14 respmod_precache bypass=off icap://127.0.0.1:1344/response_checkadaptation_access service_resp_14 allow allThanks,Giray

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20151130/03e85feb/attachment-0001.html>

------------------------------

Message: 3
Date: Mon, 30 Nov 2015 09:55:11 -0700
From: Bart Spedden <bart.spedden at 3sharecorp.com>
To: Eliezer Croitoru <eliezer at ngtech.co.il>
Cc: squid-users at lists.squid-cache.org
Subject: Re: [squid-users] 2 way SSL on a non standard SSL Port
Message-ID:
	<CAMxDymcRnZi-j2y1PUFxRTrsky6Y1gw4xJG5sR1X3GwEWaan5A at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

Thanks Eliezer. I'll grab the source for 3.5.12 and compile - I'll you know how it goes.

On Mon, Nov 30, 2015 at 9:43 AM, Eliezer Croitoru <eliezer at ngtech.co.il>
wrote:

> Well I am packing for CentOS and not RH which might have some differences.
> I will try to test my RPM on a clean CentOS machine and see if there 
> is any regression in the build.
>
> Eliezer
>
> On 30/11/2015 18:17, bspedden wrote:
>
>> I'm on RedHat 6.7
>>
>> lsb_release -i -r
>> Distributor ID: RedHatEnterpriseServer
>> Release:        6.7
>>
>> Following the instructions here:
>> http://wiki.squid-cache.org/KnowledgeBase/CentOS - I added the 
>> squid.repo file and receive the following error:
>>
>> Downloading Packages:
>> squid-3.5.11-1.el6.x86_64.rpm
>> | 3.0 MB     01:18
>> Running rpm_check_debug
>> Running Transaction Test
>> Transaction Test Succeeded
>> Running Transaction
>>    Updating   : 7:squid-3.5.11-1.el6.x86_64
>> 1/2
>> Error unpacking rpm package 7:squid-3.5.11-1.el6.x86_64
>> error: unpacking of archive failed on file /usr/share/squid/errors/zh-cn:
>> cpio: rename
>> 7:squid-3.4.3-1.el6.x86_64 was supposed to be removed but is not!
>>    Verifying  : 7:squid-3.4.3-1.el6.x86_64
>> 1/2
>>    Verifying  : 7:squid-3.5.11-1.el6.x86_64
>> 2/2
>>
>> Failed:
>>    squid.x86_64 7:3.4.3-1.el6
>> squid.x86_64 7:3.5.11-1.el6
>>
>>
>>
>> --
>> View this message in context:
>> http://squid-web-proxy-cache.1019090.n4.nabble.com/2-way-SSL-on-a-non
>> -standard-SSL-Port-tp4674807p4674896.html
>> Sent from the Squid - Users mailing list archive at Nabble.com.
>> _______________________________________________
>> squid-users mailing list
>> squid-users at lists.squid-cache.org
>> http://lists.squid-cache.org/listinfo/squid-users
>>
>>
> _______________________________________________
> squid-users mailing list
> squid-users at lists.squid-cache.org
> http://lists.squid-cache.org/listinfo/squid-users
>

--
Bart Spedden  |  Senior Developer
+1.720.210.7041  |
*bart.spedden at 3sharecorp.com <bart.spedden at 3sharecorp.com>*
3 | S H A R E  |  Adobe Digital Marketing Experts  |  An Adobe®  Business Plus Level Solution PartnerConsulting  |  Training  |  Remote Operations Management <http://www.3sharecorp.com/en/services/rom.html>
<http://www.3sharecorp.com/en/services/rom.html>
<http://www.3sharecorp.com/en/services/rom.html>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20151130/8c15884b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: rom-email-sig4_600x100.png
Type: image/png
Size: 16361 bytes
Desc: not available
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20151130/8c15884b/attachment.png>

------------------------------

Subject: Digest Footer

_______________________________________________
squid-users mailing list
squid-users at lists.squid-cache.org
http://lists.squid-cache.org/listinfo/squid-users

------------------------------

End of squid-users Digest, Vol 15, Issue 116
********************************************