Hi All,
In a thread with subject "squid workers question" Alex Rousskov has
stated that AUFS is not compatible with SMP mode. I need this clarified.
I understand that AUFS is not SMP aware but if each worker has its own
AUFS cache is there any problem other than the inefficiencies of
duplicate cac
On 03/16/2017 07:37 PM, 钱国正 wrote:
> acl subnet src 192.168.0.0/16
> on_unsupported_protocol tunnel subnet
The on_unsupported_protocol directive does not (and cannot) work for
cases where Squid does not know where the client is trying to get to:
> Currently, this directive has effect on intercep
Hi guys:
I config squid.conf with
```
acl subnet src 192.168.0.0/16
on_unsupported_protocol tunnel subnet
```
But I still got the error message as below, did I do something wrong ?
2017/03/16 17:36:46.496| 5,2| TcpAcceptor.cc(226) doAccept: New connection on
FD 15
2017/03/16 17:36:46.496|
On 03/16/2017 02:27 AM, Amos Jeffries wrote:
> The global config options being ignored completely is correct because
> your peer have individual connect-timeout=5 settings.
Please note that [individual] peer connect-timeout settings are ignored
on the tunneling path in unpatched Squid v4 and v5 (
Ok I see Markus code moved into the main package for 4.
Quick question his code in there seems almost identical to 3.5 (at least on
github mirror)
Currently cache is on Centos v6 and I use Eliezer's excellent rpms.
Do you think this will work with squid and squid-helpers 3.5.23?
-Original Me
Thanks for your detailed explaination...
Well, the "default" option does not seem to be the right choice to achieve the
expected behaviour. Hopefully, the following change will make all the traffic
passing through the primary proxy when it is reachable:
# OPTIONS WHICH AFFECT THE NEIGHBOR SELEC
On 16/03/2017 11:12 p.m., Mike Surcouf wrote:
> @Amos
>
> Thanks for this
>
> so to recap if I currently have
>
> auth_param negotiate program /usr/lib64/squid/negotiate_kerberos_auth
> auth_param negotiate children 20
> auth_param negotiate keep_alive on
>
> external_acl_type InternetAccessBan
On 16/03/2017 10:39 p.m., Jens Offenbach wrote:
> This is the sceanrio;
>
> Squid 3.5.12 is installed on "squid-proxy.mycompany.com". The two parent
> proxies are:
> - Primary: proxy.mycompany.de:8080 (139.2.1.3)
> - Fallback: roxy.mycompany.de:8080 (139.2.1.4)
>
> I have misunderstood the "defa
@Amos
Thanks for this
so to recap if I currently have
auth_param negotiate program /usr/lib64/squid/negotiate_kerberos_auth
auth_param negotiate children 20
auth_param negotiate keep_alive on
external_acl_type InternetAccessBanking %LOGIN
/usr/lib64/squid/ext_kerberos_ldap_group_acl -u
ldaps:
This is the sceanrio;
Squid 3.5.12 is installed on "squid-proxy.mycompany.com". The two parent
proxies are:
- Primary: proxy.mycompany.de:8080 (139.2.1.3)
- Fallback: roxy.mycompany.de:8080 (139.2.1.4)
I have misunderstood the "default" option in "cache_peer". When I got it right,
it has the me
On 15/03/2017 10:18 p.m., Mike Surcouf wrote:
> This is bulleted as a new feature for v4.
> Yet there is no way to test this without a quick reply letting me know the
> basic usage.
> Anyone got a snippet on how this is setup
>
[ For TL;DR skip to the end of this mail. All this is first block
On 16/03/2017 7:05 p.m., Jens Offenbach wrote:
> Thanks for your quick response...
>
> I have also configured, but the value seems not to be honored:
> connect_timeout 30 seconds
>
> The primary peer is down, but Squid does not print any "Dead parent"
> in the logs. Every HTTPS request is forwar
12 matches
Mail list logo
