[squid-users] transparent caching and missing icmp redirects?
Presumably I am not the only one with a transparent caching setup. I have recently upgraded our firewall to openSUSE 13.1, including a newer kernel. With this, transparent caching has pretty much stopped working. For large complex pages, such as an on-line newspaper where a page will draw on several content sources, I always end up missing one source because it isn't being redirected. Simple pages with just one content source is not a problem. It seem like perhaps a kernel race issue? -- Per Jessen, Zürich (4.7°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland.
[squid-users] Re: Problem with squid tcp_outgoing_address
As I have a similar problem, just using this thread: How to use tcp_outgoing_address for load balancing (round robin) ? My idea was to write an ACL-helper doing the round-robin, which would be very easy; but how to detect a failed WAN-connection within ACL-helper ?) (One local interface, 3 WAN-interfaces to different ISPs, for redundancy and balanced load sharing) -- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/Problem-with-squid-tcp-outgoing-address-tp4657445p4665113.html Sent from the Squid - Users mailing list archive at Nabble.com.
[squid-users] Re: HTTP/1.1 pipelining
But mgr:client_list shows different type of info, as far as I can see. It shows current client connections, whereas mgr:pconn shows past connection statistics (effectiveness) My squid2.7: /usr/local/squid/etc# ../sbin/squid27 -v Squid Cache: Version 2.7.STABLE9-20110824 /usr/local/squid/etc# squidclient -p -h 127.0.0.1 -U manager -W ? mgr:pconn HTTP/1.1 200 OK Date: Mon, 10 Mar 2014 08:06:33 GMT Content-Type: text/plain Expires: Mon, 10 Mar 2014 08:06:33 GMT Connection: close Client-side persistent connection counts: req/ conn count - 0 15160 1 9681 2 2801 3 1547 . 203 2 208 1 216 1 220 1 231 1 250 1 Server-side persistent connection counts: req/ conn count - 1 95899 2 2066 3 1049 83 1 99 1 104 1 110 1 112 1 132 1 So the first part of 2.7-pconn statistics is dropped on later squid-versions, although quite interesting, I think. May be, I should file a bug or feuture request ? -- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/HTTP-1-1-pipelining-tp4658574p4665114.html Sent from the Squid - Users mailing list archive at Nabble.com.
[squid-users] Re: squid with muliwan
Is it for load balancing or FailOver? Load balancing, but taking failed connection into acccount, if possible. One LINUX-PC with 4 interfaces |--- ISP-1 LAN --squid--|ISP-2 |ISP-3 -- View this message in context: http://squid-web-proxy-cache.1019090.n4.nabble.com/squid-with-muliwan-tp4662760p4665115.html Sent from the Squid - Users mailing list archive at Nabble.com.
Re: [squid-users] Re: Problem with squid tcp_outgoing_address
On 10/03/2014 8:56 p.m., babajaga wrote: As I have a similar problem, just using this thread: How to use tcp_outgoing_address for load balancing (round robin) ? My idea was to write an ACL-helper doing the round-robin, which would be very easy; but how to detect a failed WAN-connection within ACL-helper ?) (One local interface, 3 WAN-interfaces to different ISPs, for redundancy and balanced load sharing) Simple answer is that tcp_outgoing_address is the wrong place for that. Use the OS routing/firewall rules instead. There are a few issues: 1) tcp_outgoing_address is a fast group ACL. Meaning it cannot use external ACL helpers directly, must rely on a cached result from some previous lookup of the helper. 2) In the recent Squid releases you can use the random type ACL to spread the outgoing connections between a lit of tcp_outgoing_address values. 2a) tcp_outgoing_address is checked for every *potential* connection. So load balancing using it does not work for any domains with multiple IPs. 2b) the OS is free to ignore tcp_outgoing_address if its rules assign an IP address (ie source-NAT). 2c) the choice of an outgoing IP address in no way limits what route the packets may use. The OS routing rues need to be configured explicitly for that. So may as well configure the load balancing there to begin with. Also the kernel already has all available information about up/down state of NIC. So trying to get that into Squid is a lot of extra work and latency on all connections for a very little benefit gain on uncommon occasions. Amos
Re: [squid-users] Squid not caching images/content from certain websites
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/03/2014 12:49 a.m., Peres Levente wrote: Dear Squid Users, Since this is my first email to this list, let me first say a big HELLO to everybody! I hope I can be of some use to everyone else in the future. For now however, I have a bugging issue, driving me crazy... I have attached a rather long debug output of what's a single image link request being processed, under effect of debug_options ALL,3 The URL is a simple picture (or can be assumed it is as per format of URL - no POST, no ? etc...). Or so it seems to me. Thus, it should be cached cleanly by Squid. Well, in my case not so. Actually it's so notorious that even when bruteforcing the config with acl KEPEK urlpath_regex . cache allow KEPEK refresh_pattern . 5259487 100% 9259487 ignore-no-cache ignore-private override-lastmod override-expire ignore-no-store ignore-must-revalidate store-stale offline_mode on (please note that this is no production config, only for demonstration, and has been used to generate the attached error.txt) ... squid still refuses to cache this picture. I noticed the same issue with SOME other websites - simple jpeg or gif, non cache whatever. Images from www.szerencsejatek.hu are one example... redbot.org tools say: * Vary: Host is not necessary. * This response allows a cache to assign its own freshness lifetime. * A ranged request returned another representation. * An If-Modified-Since conditional request returned the full content unchanged. * The ETag doesn't change between negotiated representations. * Cache-Control: public is rarely necessary. * The If-Modified-Since response is missing required headers. * The ETag header's syntax isn't valid. On MOST sites however, the caching works perfectly and as expected. I already emptied my barrage of config directives on this problem, like reload into ims etc etc to no avail and searched what I could on Google... So. Would you be please so kind as to look at this error log and try to point me into the right direction? Could be you have a version of Squid which had Vary caching bugs. Or one of the issues redbot points out. Cheers Amos -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTHbo+AAoJELJo5wb/XPRjY58H/RGPPlA54ceVdZWhuSyP++x4 ut16nxt0ZJIGDlItnEn3f/mu4vANvRtbrSAXEko/paG7NxezuvGBu07LlvGFg6Ty g4IdXXFVLMoINDSiEgSe8rs6vpkRknnDzb8WYeYqWgmbCACzNoSXZedB0aK6pE+r bbEsVbWHP6j0uLvgtTCn7ERLxfmWxEHaT7pMbhBeNEU1cnVPbVPAPLQ4ByUP08h5 UDXZtFpGkgAKB0GzOEBeqzfSvAnthk22afM76tRt+cn16xmCpotoDaZ7lBTI8fsZ eQ3P5QvDv8BTGqgGUcMvBTB7F2u965FwbUhzfmkM9ep6Y9SjnLfSqVhwpkylnVg= =+7PN -END PGP SIGNATURE-
Re: [squid-users] transparent caching and missing icmp redirects?
Per Jessen wrote: Presumably I am not the only one with a transparent caching setup. I have recently upgraded our firewall to openSUSE 13.1, including a newer kernel. With this, transparent caching has pretty much stopped working. For large complex pages, such as an on-line newspaper where a page will draw on several content sources, I always end up missing one source because it isn't being redirected. Simple pages with just one content source is not a problem. It seem like perhaps a kernel race issue? https://bugzilla.novell.com/show_bug.cgi?id=866443 -- Per Jessen, Zürich (11.4°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland.
[squid-users] Squid selinux audit review needed.
Since I am not selinux expret but I am looking at couple issues I am not
sure what the issue is.
I have a glusterfs squid machine as a client and then I restarted the
squid instance.
All of a sudden I got a Permission Denied(13) in the logs.
I took an audit.log output for the time of server restarting.
Please take a look on it.
it maybe related to fusefs?
##START
tail /var/log/audit/audit.log -f
type=AVC msg=audit(1394456998.422:4293): avc: denied { search } for
pid=17578 comm=squid name=/ dev=fuse ino=1
scontext=unconfined_u:system_r:squid_t:s0
tcontext=system_u:object_r:fusefs_t:s0 tclass=dir
type=SYSCALL msg=audit(1394456998.422:4293): arch=c03e syscall=59
success=no exit=-13 a0=7fffeb15b980 a1=7fffeb1598e0 a2=7fffeb15bce8
a3=376e018240 items=0 ppid=17577 pid=17578 auid=0 uid=23 gid=23 euid=0
suid=0 fsuid=0 egid=23 sgid=23 fsgid=23 ses=388 tty=(none) comm=squid
exe=/usr/sbin/squid subj=unconfined_u:system_r:squid_t:s0 key=(null)
type=AVC msg=audit(1394456998.470:4294): avc: denied { getattr } for
pid=17583 comm=squid path=/mnt/gluster dev=fuse ino=1
scontext=unconfined_u:system_r:squid_t:s0
tcontext=system_u:object_r:fusefs_t:s0 tclass=dir
type=SYSCALL msg=audit(1394456998.470:4294): arch=c03e syscall=4
success=no exit=-13 a0=254d830 a1=7fff24caccf0 a2=7fff24caccf0 a3=0
items=0 ppid=17577 pid=17583 auid=0 uid=23 gid=23 euid=23 suid=0
fsuid=23 egid=23 sgid=23 fsgid=23 ses=388 tty=(none) comm=squid
exe=/usr/sbin/squid subj=unconfined_u:system_r:squid_t:s0 key=(null)
type=AVC msg=audit(1394456998.509:4295): avc: denied { search } for
pid=17582 comm=squid name=/ dev=fuse ino=1
scontext=unconfined_u:system_r:squid_t:s0
tcontext=system_u:object_r:fusefs_t:s0 tclass=dir
type=SYSCALL msg=audit(1394456998.509:4295): arch=c03e syscall=2
success=no exit=-13 a0=1bc4d30 a1=2 a2=1a4 a3=1 items=0 ppid=17577
pid=17582 auid=0 uid=23 gid=23 euid=23 suid=0 fsuid=23 egid=23 sgid=23
fsgid=23 ses=388 tty=(none) comm=squid exe=/usr/sbin/squid
subj=unconfined_u:system_r:squid_t:s0 key=(null)
type=AVC msg=audit(1394456998.591:4296): avc: denied { create } for
pid=17579 comm=squid name=coordinator.ipc
scontext=unconfined_u:system_r:squid_t:s0
tcontext=unconfined_u:object_r:var_run_t:s0 tclass=sock_file
type=SYSCALL msg=audit(1394456998.591:4296): arch=c03e syscall=49
success=no exit=-13 a0=a a1=254f9ac a2=20 a3=98 items=0 ppid=17577
pid=17579 auid=0 uid=23 gid=23 euid=23 suid=0 fsuid=23 egid=23 sgid=23
fsgid=23 ses=388 tty=(none) comm=squid exe=/usr/sbin/squid
subj=unconfined_u:system_r:squid_t:s0 key=(null)
type=AVC msg=audit(1394456998.611:4297): avc: denied { search } for
pid=17580 comm=squid name=/ dev=fuse ino=1
scontext=unconfined_u:system_r:squid_t:s0
tcontext=system_u:object_r:fusefs_t:s0 tclass=dir
type=SYSCALL msg=audit(1394456998.611:4297): arch=c03e syscall=2
success=no exit=-13 a0=1375d30 a1=2 a2=1a4 a3=1 items=0 ppid=17577
pid=17580 auid=0 uid=23 gid=23 euid=23 suid=0 fsuid=23 egid=23 sgid=23
fsgid=23 ses=388 tty=(none) comm=squid exe=/usr/sbin/squid
subj=unconfined_u:system_r:squid_t:s0 key=(null)
type=AVC msg=audit(1394456998.625:4298): avc: denied { create } for
pid=17582 comm=squid name=kid-2.ipc
scontext=unconfined_u:system_r:squid_t:s0
tcontext=unconfined_u:object_r:var_run_t:s0 tclass=sock_file
type=SYSCALL msg=audit(1394456998.625:4298): arch=c03e syscall=49
success=no exit=-13 a0=a a1=1ff4f0c a2=1a a3=98 items=0 ppid=17577
pid=17582 auid=0 uid=23 gid=23 euid=23 suid=0 fsuid=23 egid=23 sgid=23
fsgid=23 ses=388 tty=(none) comm=squid exe=/usr/sbin/squid
subj=unconfined_u:system_r:squid_t:s0 key=(null)
type=AVC msg=audit(1394456998.675:4299): avc: denied { create } for
pid=17580 comm=squid name=kid-3.ipc
scontext=unconfined_u:system_r:squid_t:s0
tcontext=unconfined_u:object_r:var_run_t:s0 tclass=sock_file
type=SYSCALL msg=audit(1394456998.675:4299): arch=c03e syscall=49
success=no exit=-13 a0=a a1=17a5f0c a2=1a a3=98 items=0 ppid=17577
pid=17580 auid=0 uid=23 gid=23 euid=23 suid=0 fsuid=23 egid=23 sgid=23
fsgid=23 ses=388 tty=(none) comm=squid exe=/usr/sbin/squid
subj=unconfined_u:system_r:squid_t:s0 key=(null)
type=AVC msg=audit(1394457000.930:4300): avc: denied { search } for
pid=17589 comm=squid name=/ dev=fuse ino=1
scontext=unconfined_u:system_r:squid_t:s0
tcontext=system_u:object_r:fusefs_t:s0 tclass=dir
type=SYSCALL msg=audit(1394457000.930:4300): arch=c03e syscall=59
success=no exit=-13 a0=7c192040 a1=7c18ffa0 a2=7c1923a8
a3=376e018240 items=0 ppid=17515 pid=17589 auid=0 uid=23 gid=23 euid=0
suid=0 fsuid=0 egid=23 sgid=23 fsgid=23 ses=388 tty=(none) comm=squid
exe=/usr/sbin/squid subj=unconfined_u:system_r:squid_t:s0 key=(null)
type=AVC msg=audit(1394457001.475:4301): avc: denied { search } for
pid=17590 comm=squid name=/ dev=fuse ino=1
scontext=unconfined_u:system_r:squid_t:s0
tcontext=system_u:object_r:fusefs_t:s0 tclass=dir
type=SYSCALL msg=audit(1394457001.475:4301):
Re: [squid-users] Squid not caching images/content from certain websites
Dear Amos,
Thank you for taking the time to reply. I'll try to reflect in-line...
2014.03.10. 14:12 keltezéssel, Amos Jeffries írta:
redbot.org tools say:
* Vary: Host is not necessary.
* This response allows a cache to assign its own freshness lifetime.
* A ranged request returned another representation.
* An If-Modified-Since conditional request returned the full content
unchanged.
* The ETag doesn't change between negotiated representations.
* Cache-Control: public is rarely necessary.
* The If-Modified-Since response is missing required headers.
* The ETag header's syntax isn't valid.
Following your example, I went ahead and tested two pictures of note
from two sites. According to this direct test:
http://redbot.org/?uri=http%3A%2F%2Fwww.moovie.cc%2Fimages%2Fmovies%2F17031%2Fposter.jpg
General
The server's clock is correct.
The Content-Length header is correct.
Caching
The resource last changed 70 days 20 hr ago.
This response allows all caches to store it.
This response is fresh until 62 days from now.
This response may still be served by a cache once it becomes stale.
Cache-Control: public is rarely necessary.
Validation
If-Modified-Since conditional requests are supported.
Partial Content
A ranged request returned another representation.
... only the last one seems too problematic (for me), since most of
these like the modification time are overridden (if im correct) by that
exaggerating refresh pattern i constructed.
Looking at the other example:
http://redbot.org/?uri=http%3A%2F%2Fwww.szerencsejatek.hu%2Fbanner%2Fsegelyvonal.jpg
General
The server's clock is correct.
The Content-Length header is correct.
Caching
The resource last changed 131 days 23 hr ago.
This response allows all caches to store it.
Vary: Host is not necessary.
This response allows a cache to assign its own freshness lifetime.
Validation
If-Modified-Since conditional requests are supported.
If-None-Match conditional requests are supported.
Partial Content
A ranged request returned the correct partial content.
... my not-too-keen eyes dont see much in common. So I'm still baffled.
Could be you have a version of Squid which had Vary caching bugs. Or
one of the issues redbot points out.
I'm not sure but... Here's all the version and info I can give off the
top of my head:
#uname -a
Linux tradestation5.warbird 3.13.5-202.fc20.i686+PAE #1 SMP Mon Mar 3
19:26:26 UTC 2014 i686 i686 i386 GNU/Linux
# squid -v
Squid Cache: Version 3.3.11
configure options: '--build=i686-redhat-linux-gnu'
'--host=i686-redhat-linux-gnu' '--program-prefix=' '--prefix=/usr'
'--exec-prefix=/usr' '--bindir=/usr/bin' '--sbindir=/usr/sbin'
'--sysconfdir=/etc' '--datadir=/usr/share' '--includedir=/usr/include'
'--libdir=/usr/lib' '--libexecdir=/usr/libexec'
'--sharedstatedir=/var/lib' '--mandir=/usr/share/man'
'--infodir=/usr/share/info' '--exec_prefix=/usr'
'--libexecdir=/usr/lib/squid' '--localstatedir=/var'
'--datadir=/usr/share/squid' '--sysconfdir=/etc/squid'
'--with-logdir=$(localstatedir)/log/squid'
'--with-pidfile=$(localstatedir)/run/squid.pid'
'--disable-dependency-tracking' '--enable-eui'
'--enable-follow-x-forwarded-for' '--enable-auth'
'--enable-auth-basic=DB,LDAP,MSNT,MSNT-multi-domain,NCSA,NIS,PAM,POP3,RADIUS,SASL,SMB,getpwnam'
'--enable-auth-ntlm=smb_lm,fake'
'--enable-auth-digest=file,LDAP,eDirectory'
'--enable-auth-negotiate=kerberos'
'--enable-external-acl-helpers=file_userip,LDAP_group,time_quota,session,unix_group,wbinfo_group'
'--enable-cache-digests' '--enable-cachemgr-hostname=localhost'
'--enable-delay-pools' '--enable-epoll' '--enable-icap-client'
'--enable-ident-lookups' '--with-large-files' '--enable-linux-netfilter'
'--enable-removal-policies=heap,lru' '--enable-snmp' '--enable-ssl'
'--enable-ssl-crtd' '--enable-storeio=aufs,diskd,ufs' '--enable-wccpv2'
'--enable-esi' '--enable-ecap' '--with-aio' '--with-default-user=squid'
'--with-dl' '--with-openssl' '--with-pthreads'
'build_alias=i686-redhat-linux-gnu' 'host_alias=i686-redhat-linux-gnu'
'CFLAGS=-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
-m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -fpie'
'LDFLAGS=-Wl,-z,relro -pie -Wl,-z,relro -Wl,-z,now' 'CXXFLAGS=-O2 -g
-pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
-fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches
-m32 -march=i686 -mtune=atom -fasynchronous-unwind-tables -fpie'
'PKG_CONFIG_PATH=%{_PKG_CONFIG_PATH}:/usr/lib/pkgconfig:/usr/share/pkgconfig'
# yum info squid
Loaded plugins: langpacks, refresh-packagekit
Installed Packages
Name: squid
Arch: i686
Epoch : 7
Version : 3.3.11
Release : 3.fc20
Size: 8.7 M
Repo: installed
From repo : updates
Summary : The Squid proxy caching server
URL : http://www.squid-cache.org
License : GPLv2+
Re: [squid-users] Squid selinux audit review needed.
Hi Elizer,
I'm pretty far from selinux understanding, but I have two suggestions
for you:
1) sealert tool can be used for getting human-readable output. E.g.
sealert -a /var/log/audit/audit.log /path/to/mylogfile.txt
2) If you just want just to start squid again and do not care about
reasons of problem, you can just follow
http://wiki.centos.org/HowTos/SELinux#head-faa96b3fdd922004cdb988c1989e56191c257c01
Hope this will be helpful for you.
Best wishes,
Pavel
On 03/10/2014 04:34 PM, Eliezer Croitoru wrote:
Since I am not selinux expret but I am looking at couple issues I am
not sure what the issue is.
I have a glusterfs squid machine as a client and then I restarted the
squid instance.
All of a sudden I got a Permission Denied(13) in the logs.
I took an audit.log output for the time of server restarting.
Please take a look on it.
it maybe related to fusefs?
##START
tail /var/log/audit/audit.log -f
type=AVC msg=audit(1394456998.422:4293): avc: denied { search } for
pid=17578 comm=squid name=/ dev=fuse ino=1
scontext=unconfined_u:system_r:squid_t:s0
tcontext=system_u:object_r:fusefs_t:s0 tclass=dir
type=SYSCALL msg=audit(1394456998.422:4293): arch=c03e syscall=59
success=no exit=-13 a0=7fffeb15b980 a1=7fffeb1598e0 a2=7fffeb15bce8
a3=376e018240 items=0 ppid=17577 pid=17578 auid=0 uid=23 gid=23 euid=0
suid=0 fsuid=0 egid=23 sgid=23 fsgid=23 ses=388 tty=(none)
comm=squid exe=/usr/sbin/squid
subj=unconfined_u:system_r:squid_t:s0 key=(null)
type=AVC msg=audit(1394456998.470:4294): avc: denied { getattr } for
pid=17583 comm=squid path=/mnt/gluster dev=fuse ino=1
scontext=unconfined_u:system_r:squid_t:s0
tcontext=system_u:object_r:fusefs_t:s0 tclass=dir
type=SYSCALL msg=audit(1394456998.470:4294): arch=c03e syscall=4
success=no exit=-13 a0=254d830 a1=7fff24caccf0 a2=7fff24caccf0 a3=0
items=0 ppid=17577 pid=17583 auid=0 uid=23 gid=23 euid=23 suid=0
fsuid=23 egid=23 sgid=23 fsgid=23 ses=388 tty=(none) comm=squid
exe=/usr/sbin/squid subj=unconfined_u:system_r:squid_t:s0 key=(null)
type=AVC msg=audit(1394456998.509:4295): avc: denied { search } for
pid=17582 comm=squid name=/ dev=fuse ino=1
scontext=unconfined_u:system_r:squid_t:s0
tcontext=system_u:object_r:fusefs_t:s0 tclass=dir
type=SYSCALL msg=audit(1394456998.509:4295): arch=c03e syscall=2
success=no exit=-13 a0=1bc4d30 a1=2 a2=1a4 a3=1 items=0 ppid=17577
pid=17582 auid=0 uid=23 gid=23 euid=23 suid=0 fsuid=23 egid=23 sgid=23
fsgid=23 ses=388 tty=(none) comm=squid exe=/usr/sbin/squid
subj=unconfined_u:system_r:squid_t:s0 key=(null)
type=AVC msg=audit(1394456998.591:4296): avc: denied { create } for
pid=17579 comm=squid name=coordinator.ipc
scontext=unconfined_u:system_r:squid_t:s0
tcontext=unconfined_u:object_r:var_run_t:s0 tclass=sock_file
type=SYSCALL msg=audit(1394456998.591:4296): arch=c03e syscall=49
success=no exit=-13 a0=a a1=254f9ac a2=20 a3=98 items=0 ppid=17577
pid=17579 auid=0 uid=23 gid=23 euid=23 suid=0 fsuid=23 egid=23 sgid=23
fsgid=23 ses=388 tty=(none) comm=squid exe=/usr/sbin/squid
subj=unconfined_u:system_r:squid_t:s0 key=(null)
type=AVC msg=audit(1394456998.611:4297): avc: denied { search } for
pid=17580 comm=squid name=/ dev=fuse ino=1
scontext=unconfined_u:system_r:squid_t:s0
tcontext=system_u:object_r:fusefs_t:s0 tclass=dir
type=SYSCALL msg=audit(1394456998.611:4297): arch=c03e syscall=2
success=no exit=-13 a0=1375d30 a1=2 a2=1a4 a3=1 items=0 ppid=17577
pid=17580 auid=0 uid=23 gid=23 euid=23 suid=0 fsuid=23 egid=23 sgid=23
fsgid=23 ses=388 tty=(none) comm=squid exe=/usr/sbin/squid
subj=unconfined_u:system_r:squid_t:s0 key=(null)
type=AVC msg=audit(1394456998.625:4298): avc: denied { create } for
pid=17582 comm=squid name=kid-2.ipc
scontext=unconfined_u:system_r:squid_t:s0
tcontext=unconfined_u:object_r:var_run_t:s0 tclass=sock_file
type=SYSCALL msg=audit(1394456998.625:4298): arch=c03e syscall=49
success=no exit=-13 a0=a a1=1ff4f0c a2=1a a3=98 items=0 ppid=17577
pid=17582 auid=0 uid=23 gid=23 euid=23 suid=0 fsuid=23 egid=23 sgid=23
fsgid=23 ses=388 tty=(none) comm=squid exe=/usr/sbin/squid
subj=unconfined_u:system_r:squid_t:s0 key=(null)
type=AVC msg=audit(1394456998.675:4299): avc: denied { create } for
pid=17580 comm=squid name=kid-3.ipc
scontext=unconfined_u:system_r:squid_t:s0
tcontext=unconfined_u:object_r:var_run_t:s0 tclass=sock_file
type=SYSCALL msg=audit(1394456998.675:4299): arch=c03e syscall=49
success=no exit=-13 a0=a a1=17a5f0c a2=1a a3=98 items=0 ppid=17577
pid=17580 auid=0 uid=23 gid=23 euid=23 suid=0 fsuid=23 egid=23 sgid=23
fsgid=23 ses=388 tty=(none) comm=squid exe=/usr/sbin/squid
subj=unconfined_u:system_r:squid_t:s0 key=(null)
type=AVC msg=audit(1394457000.930:4300): avc: denied { search } for
pid=17589 comm=squid name=/ dev=fuse ino=1
scontext=unconfined_u:system_r:squid_t:s0
tcontext=system_u:object_r:fusefs_t:s0 tclass=dir
type=SYSCALL msg=audit(1394457000.930:4300): arch=c03e syscall=59
success=no
Re: [squid-users] Re: HTTP/1.1 pipelining
On 03/07/2014 08:00 PM, babajaga wrote: then the following in http://www.squid-cache.org/Doc/config/pipeline_prefetch/ is misleading: If set to N, Squid will try to receive and process up to 1+N requests on the same connection concurrently. Note the concurrently. I think the latest documentation is correct (but I am biased because I helped write it). I cannot see what is misleading about it. If, after Amos' clarifications, you still think that something is misleading here, please clarify what it is, and we will try to fix. For older versions of squid, it is stated differently. The old documentation was very vague, but worked borderline OK for the on/off case (N was either 0 or 1). Newer Squids support arbitrary N values (with the same old zero default). Cheers, Alex.
Re: [squid-users] Re: HTTP/1.1 pipelining
On 03/10/2014 02:20 AM, babajaga wrote: But mgr:client_list shows different type of info, as far as I can see. It shows current client connections, whereas mgr:pconn shows past connection statistics (effectiveness) ... So the first part of 2.7-pconn statistics is dropped on later squid-versions, although quite interesting, I think. May be, I should file a bug or feuture request ? FWIW, I agree that knowing the number of requests per from-client connection is useful. If this is not shown anywhere, a bug report or a feature request might help, and a quality patch adding those stats would be welcomed. mgr:pconn would be the right place to show those stats for all Squid sides that use persistent connections (whether pooled by Squid itself or by the clients talking to Squid). Reporting request concurrency level (i.e., the used pipeline depth) when pipelining with clients is enabled would also be useful. Thank you, Alex.
Re: [squid-users] squid cache manager question and snmp with smp question
Reviving this topic from the dead as I made a discovery that others
may find useful :)
i also revived some suspicious logs :
2013/11/08 16:51:26 kid3| snmpHandleUdp: FD 20 recvfrom: (11) Resource
temporarily unavailable
We are still trying to figure this one out. It seems not to be harmful
particularly, except a waste of effort somewhere.
I managed to suppress the SNMP-related Resource temporarily
unavailable error in SMP mode by putting snmp_port in a
worker-specific section:
if ${process_number} = 1
snmp_port 3401
endif
HTH,
Niki
[squid-users] [ADVISORY] SQUID-2014:1 Denial of Service in SSL-Bump
__ Squid Proxy Cache Security Update Advisory SQUID-2014:1 __ Advisory ID:SQUID-2014:1 Date: March 09, 2014 Summary:Denial of Service in SSL-Bump Affected versions: Squid 3.1 - 3.3.11, Squid 3.4 - 3.4.3 Fixed in version: Squid 3.3.12, 3.4.4 __ http://www.squid-cache.org/Advisories/SQUID-2014_1.txt http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0128 __ Problem Description: Due to incorrect state management Squid is vulnerable to a denial of service attack when processing certain HTTPS requests. __ Severity: This problem allows any client who can generate HTTPS requests to perform a denial of service attack on the Squid service. There are popular client software implementations which generate HTTPS requests and triggering this vulnerability during their normal activities. __ Updated Packages: This bug is fixed by Squid versions 3.3.12 and 3.4.4. In addition, patches addressing this problem can be found in our patch archives. Squid 3.3: http://www.squid-cache.org/Versions/v3/3.3/changesets/squid-3.3-12677.patch Squid 3.4: http://www.squid-cache.org/Versions/v3/3.4/changesets/squid-3.4-13104.patch If you are using a prepackaged version of Squid then please refer to the package vendor for availability information on updated packages. __ Determining if your version is vulnerable: All Squid versions without SSL-Bump feature configured are not vulnerable. All Squid-3.0 and older versions, including Squid-2 are not vulnerable. All unpatched Squid-3.1 versions are vulnerable. All unpatched Squid-3.2 versions are vulnerable. All unpatched Squid-3.3 versions up to and including 3.3.11 are vulnerable. All unpatched Squid-3.4 versions up to and including 3.4.3 are vulnerable. __ Workarounds: Either Disable SSL-bump for clients affected by adding ssl_bump none rule(s) at the top of the ssl_bump configuration directives. Or Disable SSL-bump featrue completely by removing ssl-bump option from all http_port and/or https_port configuration directives. Or Use TCP_RESET instead of all Squid-generated error pages. Note that this is only a partial workaround as some error pages cannot be overridden. __ Contact details for the Squid project: For installation / upgrade support on binary packaged versions of Squid: Your first point of contact should be your binary package vendor. If your install and build Squid from the original Squid sources then the squid-users@squid-cache.org mailing list is your primary support point. For subscription details see http://www.squid-cache.org/Support/mailing-lists.html. For reporting of non-security bugs in the latest STABLE release the squid bugzilla database should be used http://bugs.squid-cache.org/. For reporting of security sensitive bugs send an email to the squid-b...@squid-cache.org mailing list. It's a closed list (though anyone can post) and security related bug reports are treated in confidence until the impact has been established. __ Credits: The vulnerability was reported by Mathias Fischer and Fabian Hugelshofer from Open Systems AG. Fixes by Alex Rousskov from The Measurement Factory. __ Revision history: 2014-02-21 16:04 GMT Initial Report 2014-02-22 23:51 GMT Patch Provided 2014-03-09 00:14 GMT Packages Released __ END
Re: [squid-users] Re: Problem with squid tcp_outgoing_address
Hi,Amos, As tcp_outgoing_address support fast group ACL, can I use ACL base on some header? Regards Simon 于 14-3-10 19:20, Amos Jeffries 写道: On 10/03/2014 8:56 p.m., babajaga wrote: As I have a similar problem, just using this thread: How to use tcp_outgoing_address for load balancing (round robin) ? My idea was to write an ACL-helper doing the round-robin, which would be very easy; but how to detect a failed WAN-connection within ACL-helper ?) (One local interface, 3 WAN-interfaces to different ISPs, for redundancy and balanced load sharing) Simple answer is that tcp_outgoing_address is the wrong place for that. Use the OS routing/firewall rules instead. There are a few issues: 1) tcp_outgoing_address is a fast group ACL. Meaning it cannot use external ACL helpers directly, must rely on a cached result from some previous lookup of the helper. 2) In the recent Squid releases you can use the random type ACL to spread the outgoing connections between a lit of tcp_outgoing_address values. 2a) tcp_outgoing_address is checked for every *potential* connection. So load balancing using it does not work for any domains with multiple IPs. 2b) the OS is free to ignore tcp_outgoing_address if its rules assign an IP address (ie source-NAT). 2c) the choice of an outgoing IP address in no way limits what route the packets may use. The OS routing rues need to be configured explicitly for that. So may as well configure the load balancing there to begin with. Also the kernel already has all available information about up/down state of NIC. So trying to get that into Squid is a lot of extra work and latency on all connections for a very little benefit gain on uncommon occasions. Amos
[squid-users] Squid 3.3.12 is available
The Squid HTTP Proxy team is very pleased to announce the availability of the Squid-3.3.12 release! This release is a security fix release resolving several major issues found in the prior Squid releases. REMINDER: This and older releases are already deprecated by Squid-3.4 availablility. The major changes to be aware of: * CVE-2014-0128 : SQUID-2014:1 Denial of Service in SSL-Bump http://www.squid-cache.org/Advisories/SQUID-2014_1.txt This problem occurs in SSL-Bumped traffic and most severely when using server-first bumping. It allows any client who can generate HTTPS requests to perform a denial of service attack on Squid. There are popular client software implementations which generate HTTPS requests and triggering this vulnerability during their normal activities. * Bug #4026: SSL and adaptation_access on aborted connections When performing adaptation on SSL traffic it was possible for a trusted client to crash Squid. This was only possible during the very narrow time of selecting which adaptation service(s) to perform, so the security impact is very unlikely. However in configurations using slow ACL tests or external ACL helpers the risk is much increased. * Bug #3806: Caching responses with Vary header This bug was causing Squid to store all responses normally but MISS on traffic involving the Vary header. The result is a high churn on cached content combined with a very low HIT rate. * Bug #3769: client_netmask not evaluated since Comm redesign This bug caused the client_netmask directive in Squid-3.2 and Squid-3.3 releases to have no effect. The designed behaviour of masking client IPs in logs is now restored. * Bug #3969: credentials caching for Digest authentication This bug resulted in Digest authentication incorrectly authenticating requests against the wrong user credentials and forcing re-authentication. While this fail-closed behaviour is safe from a security viewpoint it can result in large bandwidth usage on affected Squid. See the ChangeLog for the full list of changes in this and earlier releases. All users are urged to upgrade as soon as possible. Please remember to run squid -k parse when testing upgrade to a new version of Squid. It will audit your configuration files and report any identifiable issues the new release will have in your installation before you press go. We are still removing the infamous Bungled Config halting points and adding checks, so if something is not identified please report it. Please refer to the release notes at http://www.squid-cache.org/Versions/v3/3.3/RELEASENOTES.html when you are ready to make the switch to Squid-3.3 Upgrade tip: squid -k parse is starting to display even more useful hints about squid.conf changes. This new release can be downloaded from our HTTP or FTP servers http://www.squid-cache.org/Versions/v3/3.3/ ftp://ftp.squid-cache.org/pub/squid/ ftp://ftp.squid-cache.org/pub/archive/3.3/ or the mirrors. For a list of mirror sites see http://www.squid-cache.org/Download/http-mirrors.html http://www.squid-cache.org/Download/mirrors.html If you encounter any issues with this release please file a bug report. http://bugs.squid-cache.org/ Amos Jeffries
[squid-users] Squid 3.4.4 is available
The Squid HTTP Proxy team is very pleased to announce the availability of the Squid-3.4.4 release! This release is a security and bug fix release resolving many portability issues found in the prior Squid releases. The major changes to be aware of: * CVE-2014-0128 : SQUID-2014:1 Denial of Service in SSL-Bump http://www.squid-cache.org/Advisories/SQUID-2014_1.txt This problem occurs in SSL-Bumped traffic and most severely when using server-first bumping. It allows any client who can generate HTTPS requests to perform a denial of service attack on Squid. There are popular client software implementations which generate HTTPS requests and triggering this vulnerability during their normal activities. * Bug #4029: intercepted HTTPS requests bypass caching checks This bug caused Squid to cache responses to HTTPS requests where the caching should have been rejected due to the method. Resulting in HITs short-circuiting transactions which should have been relayed to the origin server. * Bug #4026: SSL and adaptation_access on aborted connections When performing adaptation on SSL traffic it was possible for a trusted client to crash Squid. This was only possible during the very narrow time of selecting which adaptation service(s) to perform, so the security impact is very unlikely. However in configurations using slow ACL tests or external ACL helpers the risk is much increased. * Bug #3969: credentials caching for Digest authentication This bug resulted in Digest authentication incorrectly authenticating requests against the wrong user credentials and forcing re-authentication. While this fail-closed behaviour is safe from a security viewpoint it can result in large bandwidth usage on affected Squid. * Bug #3769: client_netmask not evaluated since Comm redesign This bug caused the client_netmask directive in Squid-3.2 and Squid-3.3 releases to have no effect. The designed behaviour of masking client IPs in logs is now restored. * Bug #3186 and #3628: Digest authentication always sending stale=false These bugs resulted in the client software wrongly determining Digest authentication as failed and/or re-authentication popups occuring on every nonce TTL expiry. * Several portability issues have also been resolved The resolved issues are largly visible as compile failure regarding cstdio, strsep(), and various CMSG symbols. These issue affected all BSD based systems as well as several Unix based. All users of Squid-3.4 with HTTPS traffic are urged to upgrade to this release as soon as possible. All users of Squid-3.4 are encouraged to upgrade to this release as soon as possible. All users of older Squid versions are encouraged to upgrade as soon as possible. See the ChangeLog for the full list of changes in this and earlier releases. Please refer to the release notes at http://www.squid-cache.org/Versions/v3/3.4/RELEASENOTES.html when you are ready to make the switch to Squid-3.4 Upgrade tip: squid -k parse is starting to display even more useful hints about squid.conf changes. This new release can be downloaded from our HTTP or FTP servers http://www.squid-cache.org/Versions/v3/3.4/ ftp://ftp.squid-cache.org/pub/squid/ ftp://ftp.squid-cache.org/pub/archive/3.4/ or the mirrors. For a list of mirror sites see http://www.squid-cache.org/Download/http-mirrors.html http://www.squid-cache.org/Download/mirrors.html If you encounter any issues with this release please file a bug report. http://bugs.squid-cache.org/ Amos Jeffries
