>From the Debian repo. Stretch has 3.5.10 at the moment. Jessie has 3.4.8. Cheers MarkJ > On 1 Dec 2015, at 4:12 AM, Patrick Flaherty <vze2k3sa@xxxxxxxxxxx> wrote: > > Hi, > > Where did you find a 32-bit version of Squid? > > Thanks > Patrick > > -----Original Message----- > From: squid-users [mailto:squid-users-bounces@xxxxxxxxxxxxxxxxxxxxx] On Behalf Of squid-users-request@xxxxxxxxxxxxxxxxxxxxx > Sent: Monday, November 30, 2015 11:55 AM > To: squid-users@xxxxxxxxxxxxxxxxxxxxx > Subject: squid-users Digest, Vol 15, Issue 116 > > Send squid-users mailing list submissions to > squid-users@xxxxxxxxxxxxxxxxxxxxx > > 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@xxxxxxxxxxxxxxxxxxxxx > > You can reach the person managing the list at > squid-users-owner@xxxxxxxxxxxxxxxxxxxxx > > 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@xxxxxxxxxxxxxxxxxxxxxxx> > To: squid-users@xxxxxxxxxxxxxxxxxxxxx > Subject: Re: 32bit (i386) squid 3.5 cache dir size > limit? > Message-ID: <565C7DD9.1080803@xxxxxxxxxxxxxxxxxxxxxxx> > 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@xxxxxxxxxxx> > To: "squid-users@xxxxxxxxxxxxxxxxxxxxx" > <squid-users@xxxxxxxxxxxxxxxxxxxxx> > Subject: missing icap respmod request when the web > object is found in the cache? > Message-ID: <BLU184-W58CB5DE6176AE2A4F250FAFE000@xxxxxxx> > 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@xxxxxxxxxxxxxx> > To: Eliezer Croitoru <eliezer@xxxxxxxxxxxx> > Cc: squid-users@xxxxxxxxxxxxxxxxxxxxx > Subject: Re: 2 way SSL on a non standard SSL Port > Message-ID: > <CAMxDymcRnZi-j2y1PUFxRTrsky6Y1gw4xJG5sR1X3GwEWaan5A@xxxxxxxxxxxxxx> > 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@xxxxxxxxxxxx> > 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@xxxxxxxxxxxxxxxxxxxxx >>> http://lists.squid-cache.org/listinfo/squid-users >> _______________________________________________ >> squid-users mailing list >> squid-users@xxxxxxxxxxxxxxxxxxxxx >> http://lists.squid-cache.org/listinfo/squid-users > > > > -- > Bart Spedden | Senior Developer > +1.720.210.7041 | > *bart.spedden@xxxxxxxxxxxxxx <bart.spedden@xxxxxxxxxxxxxx>* > 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@xxxxxxxxxxxxxxxxxxxxx > http://lists.squid-cache.org/listinfo/squid-users > > > ------------------------------ > > End of squid-users Digest, Vol 15, Issue 116 > ******************************************** > > _______________________________________________ > squid-users mailing list > squid-users@xxxxxxxxxxxxxxxxxxxxx > http://lists.squid-cache.org/listinfo/squid-users _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
