On 04/22/2016 09:19 AM, Odhiambo Washington wrote:
> Can I terminate based on time?
Yes. You can terminate based on any information except information
contained inside HTTP messages. Time is always available.
ssl::server_name will give you an approximation of what you call "site".
> By just
Can I terminate based on time? By just modifying the bits you wrote for me?
On 17:45, Fri, Apr 22, 2016 Amos Jeffries wrote:
> On 23/04/2016 12:39 a.m., Odhiambo Washington wrote:
> >
> > So is it possible to achieve such a non-intrusive setup, but without
> > 'terminate'?
On 23/04/2016 12:39 a.m., Odhiambo Washington wrote:
>
> So is it possible to achieve such a non-intrusive setup, but without
> 'terminate'?
You declared the requirement "Serve an error page.".
That is intrusive.
As Alex has said repeatedly:
terminate or produce an error. Pick one.
Amos
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
22.04.16 18:39, Odhiambo Washington пишет:
>
>
> On 22 April 2016 at 13:45, Amos Jeffries > wrote:
>
> On 22/04/2016 8:23 p.m., Odhiambo Washington wrote:
> >
> > Sure, I am really
On 22 April 2016 at 13:45, Amos Jeffries wrote:
> On 22/04/2016 8:23 p.m., Odhiambo Washington wrote:
> >
> > Sure, I am really struggling to understand this. I would like to serve
> > error pages. A complete example of this would really help. I am thinking,
> > based on
On 22/04/2016 8:23 p.m., Odhiambo Washington wrote:
>
> Sure, I am really struggling to understand this. I would like to serve
> error pages. A complete example of this would really help. I am thinking,
> based on the two templates you gave and going with the one where squid
> intrudes, that it
On 22 April 2016 at 02:16, Alex Rousskov
wrote:
> On 04/21/2016 03:26 PM, Odhiambo Washington wrote:
> > On 21 April 2016 at 23:14, Alex Rousskov wrote:
> > Logging aside, your latest random configuration is equivalent to
> > [...] not intercepting SSL
On 04/21/2016 03:26 PM, Odhiambo Washington wrote:
> On 21 April 2016 at 23:14, Alex Rousskov wrote:
> Logging aside, your latest random configuration is equivalent to
> [...] not intercepting SSL at all, which brings
> us back to the old question: What do you want Squid to do?
> If
On 21 April 2016 at 23:14, Alex Rousskov
wrote:
> On 04/21/2016 01:59 PM, Odhiambo Washington wrote:
> > On 21 April 2016 at 22:04, Amos Jeffries wrote:
> >
> > On 22/04/2016 6:20 a.m., Odhiambo Washington wrote:
> > > I have now changed to
On 04/21/2016 01:59 PM, Odhiambo Washington wrote:
> On 21 April 2016 at 22:04, Amos Jeffries wrote:
>
> On 22/04/2016 6:20 a.m., Odhiambo Washington wrote:
> > I have now changed to *configurations suggested specifically for your
> use
> > case, on this email thread* :)
> > acl
On 21 April 2016 at 22:04, Amos Jeffries wrote:
> On 22/04/2016 6:20 a.m., Odhiambo Washington wrote:
> > Hi Alex,
> >
> > I have now changed to *configurations suggested specifically for your use
> > case, on this email thread* :)
> >
> >
> >
> > acl no_ssl_interception
On 22/04/2016 6:20 a.m., Odhiambo Washington wrote:
> Hi Alex,
>
> I have now changed to *configurations suggested specifically for your use
> case, on this email thread* :)
>
>
>
> acl no_ssl_interception ssl::server_name
> "/usr/local/etc/squid/ssl_bump_broken_sites.txt"
> ssl_bump splice
On 04/21/2016 08:12 AM, Odhiambo Washington wrote:
> acl no_ssl_interception ssl::server_name ...
> ssl_bump splice no_ssl_interception
> ssl_bump stare step2
> ssl_bump splice all
You are mixing splice and stare now. There are two groups of actions:
* peek and then splice
* stare and then
On 21 April 2016 at 16:48, Alex Rousskov
wrote:
> On 04/21/2016 07:18 AM, Odhiambo Washington wrote:
> > Is is expected that using ssl_bump results into high CPU usage all the
> > time?
>
> Your question is impossible to answer in general: The CPU usage levels
On 04/21/2016 07:18 AM, Odhiambo Washington wrote:
> Is is expected that using ssl_bump results into high CPU usage all the
> time?
Your question is impossible to answer in general: The CPU usage levels
depend on the amount of Squid traffic, the portion of SSL traffic in the
overall traffic mix,
I will put the splice explicitly and observe.
Without ssl_bump I never saw such cpu usage with squid.
However, lemme watch and also listen to feedback..
On 21 April 2016 at 16:34, Amos Jeffries wrote:
> On 22/04/2016 1:18 a.m., Odhiambo Washington wrote:
> > Is is
On 22/04/2016 1:18 a.m., Odhiambo Washington wrote:
> Is is expected that using ssl_bump results into high CPU usage all the
> time?
>
Encryption adds CPU overhead, but how much depends on what your normal
use was. I dont think any of us have a good rule-of-thumb or educated
guess yet because
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Not necessary. May be bottleneck in OS.
21.04.16 19:25, Odhiambo Washington пишет:
> So, what could possibly be wrong with my setup, that squid consumes so much
> CPU?
>
> On 21 April 2016 at 16:22, Yuri Voinov
So, what could possibly be wrong with my setup, that squid consumes so much
CPU?
On 21 April 2016 at 16:22, Yuri Voinov wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> It must not be. My most active setup has 3% CPU all time dirung peak hours.
>
> Typical
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
It must not be. My most active setup has 3% CPU all time dirung peak hours.
Typical view:
https://i1.someimage.com/NzM1erI.png
21.04.16 19:18, Odhiambo Washington пишет:
> Is is expected that using ssl_bump results into high CPU usage all the
Is is expected that using ssl_bump results into high CPU usage all the
time?
This is squid-3.5.17
That is what I am seeing:
last pid: 26673; load averages: 2.24, 2.00, 2.10
up 0+03:47:56 16:08:30
160 processes: 2 running, 157 sleeping, 1 zombie
CPU: 86.1% user, 0.0% nice,
21 matches
Mail list logo