Re: [squid-users] time to pack?

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Wed, 24 Feb 2010 19:41:08 +1300

Luis Daniel Lucio Quiroz wrote:
> Le Mercredi 10 Février 2010 16:07:17, Amos Jeffries a écrit :
>> On Wed, 10 Feb 2010 10:51:16 -0600, Luis Daniel Lucio Quiroz
>>
>> <luis.daniel.lucio_at_gmail.com> wrote:
>>> Le Mardi 9 Février 2010 22:57:58, Amos Jeffries a écrit :
>>>> Henrik Nordström wrote:
>>>>> tis 2010-02-09 klockan 15:18 -0600 skrev Luis Daniel Lucio Quiroz:
>>>>>> Le Mercredi 30 Juillet 2008 22:24:35, Henrik Nordstrom a écrit :
>>>>>>> On tor, 2008-07-31 at 11:26 +0900, S.KOBAYASHI wrote:
>>>>>>>> Hello developer,
>>>>>>>>
>>>>>>>> I'm looking for the evidence for accessing ICAP server. Is there
>> its
>>
>>>>>>>> log in any log files such as access.log, cache.log?
>>>>>>> The ICAP server should have logs of it's own.
>>>>>>>
>>>>>>> There is no information in the Squid logs on which iCAP servers
>> were
>>
>>>>>>> used for the request/response.
>>>>>>>
>>>>>>> Regards
>>>>>>> Henrik
>>>>>> I wonder if using squidclient mngr:xxXX we could see some info
>> about
>>
>>>>>> icap, where?
>>>>> Seems not.
>>>>>
>>>>> You can however increase the debug level of section 93 to have ICAP
>>>>> spew
>>>>> out lots of information in cache.log.
>>>>>
>>>>> debug_options ALL,1 93,5
>>>>>
>>>>> should do the trick I think.
>>>>>
>>>>> Regards
>>>>> Henrik
>>>> Squid-3.1 and later provide some little ICAP service logging in
>>>> access.log.
>>>> http://www.squid-cache.org/Doc/config/logformat/
>>>>
>>>>
>>>> Amos
>>> Do you think we could backport that logging in access.log capabilitie.
>> I
>>
>>> may
>>> do that but just tellme what file to
>>> backport.
>>>
>>> TIA
>>>
>>> LD
>> It was quite a major change. For only a small benefit. It won't be done
>> upstream sorry.
>>
>> 3.1 is out as stable in less than 60 days though if everything goes to
>> plan.
>> (one blocker bug to go. Major, but solo).
>>
>> Amos
>
> Thanx Amos,
>
> some strategic questions.
>
> how status of sq 3.1 is about:
> - ICAP support
> - SSLbump
> - ESI
> - Reverse proxy

The above are all stable and now well tested.

>
> I'd like to use ESI support to log some html payload of specifique sites. As
> far as I know, sslbump will help avoidme to inverse-proxying any site.

None of what you just said matches what I now about those two features.

  ESI is about having Squid assemble HTML pages from pieces at the
customer facing edge of a CDN network instead of on a web server.

I'm not sure what you means by 'inverse' proxy. But it does not sound
like an SSLBump situation.

SSLBump issues all seem to be admin misunderstanding what environments
it's relevant for: corporate business networks where all PCs are fully
locked down and certificate CA can be issued to permit Squid to decrypt
HTTPS requests.

>
> I'm mandriva squid maintainer and as far as i know, we will freze distro about
> april 2010. Do you thing 3.1 will be out by april? What kind of block bug
> are you talking about.

I'm hoping for March. The reports about todays 3.1.0.17 will determin if
its mid or late March formal release.

The main bug remaining (bug 2305) is really several doing the same
thing: Under certain conditions some of the auth systems 'leak'
credentials into the credential cache. Daily cleanup operations protect
most installs but in some large setups this can build up too fast and
get noticed. The same issue exists in 3.0 so its not a solid block, but
still is one of the 3.1 release goals.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE7 or 3.0.STABLE24
   Current Beta Squid 3.1.0.16
Received on Wed Feb 24 2010 - 06:41:17 MST

This archive was generated by hypermail 2.2.0 : Wed Feb 24 2010 - 12:00:07 MST