auto-import changelog data from squid-2.4.STABLE3-1.7.2.src.rpm
Mon Feb 18 2002 Bill Nottingham <notting@redhat.com> - 2.4.STABLE3 + patches - turn off HTCP at request of maintainers - leave SNMP enabled in the build, but disabled in the default config Fri Jan 25 2002 Tim Powers <timp@redhat.com> - rebuild against new libssl Wed Jan 09 2002 Tim Powers <timp@redhat.com> - automated rebuild Mon Jan 07 2002 Florian La Roche <Florian.LaRoche@redhat.de> - require linuxdoc-tools instead of sgml-tools Tue Sep 25 2001 Bill Nottingham <notting@redhat.com> - update to 2.4.STABLE2
This commit is contained in:
cvsdist
parent
f078d2f692
commit
f4c5442577
@ -1 +1 @@
|
||||
squid-2.4.STABLE1-src.tar.gz
|
||||
squid-2.4.STABLE3-src.tar.gz
|
||||
|
||||
365
FAQ.sgml
365
FAQ.sgml
@ -237,7 +237,7 @@ gives information on our operational mesh of caches.
|
||||
<url url="http://www.squid-cache.org/Doc/FAQ/" name="The Squid FAQ"> (uh, you're reading it).
|
||||
|
||||
<item>
|
||||
<url url="http://cache.is.co.za" name="Oskar's Squid Users Guide">.
|
||||
<url url="http://squid-docs.sourceforge.net/latest/html/book1.htm" name="Oskar's Squid Users Guide">.
|
||||
|
||||
<item>
|
||||
<url url="http://www.ircache.net/Cache/FAQ/" name="The Information Resource Caching FAQ">
|
||||
@ -417,7 +417,7 @@ The following people have made contributions to this document:
|
||||
<item>
|
||||
<url url="mailto:nazard@man-assoc.on.ca" name="Doug Nazar">
|
||||
<item>
|
||||
<url url="mailto:hno@hem.passagen.se" name="Henrik Nordstrom">
|
||||
<url url="mailto:hno@squid-cache.org" name="Henrik Nordstrom">
|
||||
<item>
|
||||
<url url="mailto:mark@rts.com.au" name="Mark Reynolds">
|
||||
<item>
|
||||
@ -1864,7 +1864,7 @@ You can use the <em/no_cache/ access list to make Squid never cache any response
|
||||
<p>
|
||||
With Squid-2.4 and later you can use the ``null'' storage module:
|
||||
<verb>
|
||||
cache_dir null -1 1000
|
||||
cache_dir null /null
|
||||
</verb>
|
||||
|
||||
<sect1>Can I prevent users from downloading large files?
|
||||
@ -2023,7 +2023,7 @@ for each user. For example:
|
||||
gopher_proxy:http://mycache.example.com:3128/
|
||||
</verb>
|
||||
|
||||
<sect1>Redundant Auto-Proxy-Configuration
|
||||
<sect1>Redundant Proxy Auto-Configuration
|
||||
|
||||
<P>
|
||||
There's one nasty side-effect to using auto-proxy scripts: if you start
|
||||
@ -2089,6 +2089,13 @@ DHCP.
|
||||
name="Rodney van den Oever">
|
||||
</quote>
|
||||
|
||||
<sect1>Proxy Auto-Configuration with URL Hashing
|
||||
<p>
|
||||
The
|
||||
<url url="http://naragw.sharp.co.jp/sps/" name="Sharp Super Proxy Script page">
|
||||
contains a lot of good information about hash-based proxy auto-configuration
|
||||
scripts. With these you can distribute the load between a number
|
||||
of caching proxies.
|
||||
|
||||
<sect1>Microsoft Internet Explorer configuration
|
||||
<P>
|
||||
@ -3473,10 +3480,10 @@ Squid does not allow
|
||||
you to purge objects unless it is configured with access controls
|
||||
in <em/squid.conf/. First you must add something like
|
||||
<verb>
|
||||
acl PURGE method purge
|
||||
acl PURGE method PURGE
|
||||
acl localhost src 127.0.0.1
|
||||
http_access allow purge localhost
|
||||
http_access deny purge
|
||||
http_access allow PURGE localhost
|
||||
http_access deny PURGE
|
||||
</verb>
|
||||
The above only allows purge requests which come from the local host and
|
||||
denies all other purge requests.
|
||||
@ -4020,7 +4027,7 @@ represents the maximum size your Squid process has reached.
|
||||
<label id="malloc-death">
|
||||
|
||||
<P>
|
||||
by <url url="mailto:hno@hem.passagen.se" name="Henrik Nordstrom">
|
||||
by <url url="mailto:hno@squid-cache.org" name="Henrik Nordstrom">
|
||||
|
||||
<P>
|
||||
Messages like "FATAL: xcalloc: Unable to allocate 4096 blocks of 1 bytes!"
|
||||
@ -5296,16 +5303,35 @@ the client's IP address. The <em/src/ ACL is preferred over <em/srcdomain/
|
||||
because it does not require address-to-name lookups for each request.
|
||||
|
||||
|
||||
<sect1>I set up my access controls, but they don't work! why?
|
||||
<sect1>I set up my access controls, but they don't work! why?<label id="acl-debug">
|
||||
|
||||
<P>
|
||||
You can debug your access control configuration by setting the
|
||||
<em/debug_options/ parameter in <em/squid.conf/ and
|
||||
watching <em/cache.log/ as requests are made. The access control
|
||||
routes correspond to debug section 28, so you might enter:
|
||||
<p>
|
||||
If ACLs are giving you problems and you don't know why they
|
||||
aren't working, you can use this tip to debug them.
|
||||
<p>
|
||||
In <em>squid.conf</em> enable debugging for section 33 at level 2.
|
||||
For example:
|
||||
<verb>
|
||||
debug_options ALL,1 28,9
|
||||
debug_options ALL,1 33,2
|
||||
</verb>
|
||||
Then restart or reconfigure squid.
|
||||
<p>
|
||||
From now on, your <em/cache.log/ should contain a line for every
|
||||
request that explains if it was allowed, or denied, and which
|
||||
ACL was the last one that it matched.
|
||||
<p>
|
||||
If this does not give you sufficient information to nail down the
|
||||
problem you can also enable detailed debug information on ACL processing
|
||||
<verb>
|
||||
debug_options ALL,1 33,2 28,9
|
||||
</verb>
|
||||
Then restart or reconfigure squid as above.
|
||||
<p>
|
||||
From now on, your <em/cache.log/ should contain detailed traces
|
||||
of all access list processing. Be warned that this can be quite
|
||||
some lines per request.
|
||||
|
||||
<p>See also <ref id="debug" name="11.20 Debug Squid">
|
||||
|
||||
<sect1>Proxy-authentication and neighbor caches
|
||||
<P>
|
||||
@ -5546,20 +5572,9 @@ http_access deny all
|
||||
</verb>
|
||||
|
||||
<sect1>Debugging ACLs
|
||||
|
||||
<p>
|
||||
If ACLs are giving you problems and you don't know why they
|
||||
aren't working, you can use this tip to debug them.
|
||||
<p>
|
||||
In <em>squid.conf</em> enable debugging for section 32 at level 2.
|
||||
For example:
|
||||
<verb>
|
||||
debug_options ALL,1 32,2
|
||||
</verb>
|
||||
The restart or reconfigure squid.
|
||||
<p>
|
||||
From now on, your <em/cache.log/ should contain a line for every
|
||||
request that explains if it was allowed, or denied, and which
|
||||
ACL was the last one that it matched.
|
||||
See <ref id="acl-debug" name="1.9 I set up my access controls, but they don't work! why?"> and <ref id="debug" name="11.20 Debugging Squid">.
|
||||
|
||||
<sect1>Can I limit the number of connections from a client?
|
||||
<p>
|
||||
@ -5601,12 +5616,6 @@ you should write
|
||||
acl yuck dstdomain .foo.com
|
||||
http_access deny yuck
|
||||
</verb>
|
||||
To be safe, you probably want to list both forms in your
|
||||
access lists, for example:
|
||||
<verb>
|
||||
acl yuck dstdomain .foo.com foo.com
|
||||
http_access deny yuck
|
||||
</verb>
|
||||
|
||||
<sect1>I want to customize, or make my own error messages.
|
||||
<p>
|
||||
@ -5926,7 +5935,7 @@ If the peer is multihomed, it is sending packets out an interface
|
||||
which is not advertised in the DNS. Unfortunately, this is a
|
||||
configuration problem at the peer site. You can tell them to either
|
||||
add the IP address interface to their DNS, or use Squid's
|
||||
'udp_outgoing_address' option to force the replies
|
||||
"udp_outgoing_address" option to force the replies
|
||||
out a specific interface. For example:
|
||||
<P>
|
||||
<em/on your parent squid.conf:/
|
||||
@ -6314,6 +6323,13 @@ due to one of the following reasons:
|
||||
<item>
|
||||
Resource Limits. The shell has limits on the size of a coredump
|
||||
file. You may need to increase the limit.
|
||||
<item>
|
||||
sysctl options. On FreeBSD, you won't get a coredump from
|
||||
programs that call setuid() and/or setgid() (like Squid sometimes does)
|
||||
unless you enable this option:
|
||||
<verb>
|
||||
# sysctl -w kern.sugid_coredump=1
|
||||
</verb>
|
||||
<item>
|
||||
No debugging symbols.
|
||||
The Squid binary must have debugging symbols in order to get
|
||||
@ -6435,7 +6451,50 @@ If possible, you might keep the coredump file around for a day or
|
||||
two. It is often helpful if we can ask you to send additional
|
||||
debugger output, such as the contents of some variables.
|
||||
|
||||
<sect1>Debugging Squid
|
||||
<P>If you CANNOT get Squid to leave a core file for you then one of
|
||||
the following approaches can be used<label ID="nocore">
|
||||
|
||||
<P>First alternative is to start Squid under the contol of GDB
|
||||
|
||||
<verb>
|
||||
% gdb /path/to/squid
|
||||
handle SIGPIPE pass nostop noprint
|
||||
run -DNYCd3
|
||||
[wait for crash]
|
||||
backtrace
|
||||
quit
|
||||
</verb>
|
||||
|
||||
<P>The drawback from the above is that it isn't really suitable to run on a
|
||||
production system as Squid then won't restart automatically if it
|
||||
crashes. The good news is that it is fully possible to automate the
|
||||
process above to automatically get the stack trace and then restart
|
||||
Squid. Here is a short automated script that should work:
|
||||
|
||||
<verb>
|
||||
#!/bin/sh
|
||||
trap "rm -f $$.gdb" 0
|
||||
cat <<EOF >$$.gdb
|
||||
handle SIGPIPE pass nostop noprint
|
||||
run -DNYCd3
|
||||
backtrace
|
||||
quit
|
||||
EOF
|
||||
while sleep 2; do
|
||||
gdb -x $$.gdb /path/to/squid 2>&1 | tee -a squid.out
|
||||
done
|
||||
</verb>
|
||||
|
||||
<P>Other options if the above cannot be done is to:
|
||||
|
||||
<P>a) Build Squid with the --enable-stacktraces option, if support exists for your OS (exists for Linux glibc on Intel, and Solaris with some extra libraries..)
|
||||
|
||||
<P>b) Run Squid using the "catchsegv" tool. (Linux glibc Intel)
|
||||
|
||||
<P>but these approaches does not by far provide as much details as using
|
||||
gdb.
|
||||
|
||||
<sect1>Debugging Squid<label id="debug">
|
||||
|
||||
<P>
|
||||
If you believe you have found a non-fatal bug (such as incorrect HTTP
|
||||
@ -6677,7 +6736,7 @@ A forwarding loop is when a request passes through one proxy more than
|
||||
once. You can get a forwarding loop if
|
||||
<itemize>
|
||||
<item>a cache forwards requests to itself. This might happen with
|
||||
transparent caching (or server acceleration) configurations.
|
||||
interception caching (or server acceleration) configurations.
|
||||
<item>a pair or group of caches forward requests to each other. This can
|
||||
happen when Squid uses ICP, Cache Digests, or the ICMP RTT database
|
||||
to select a next-hop cache.
|
||||
@ -6949,7 +7008,7 @@ than a proper close.
|
||||
You probably don't need to worry about them, unless you receive
|
||||
a lot of user complaints relating to SSL sites.
|
||||
<p>
|
||||
<url url="raj at cup dot hp dot com" name="Rick Jones"> notes that
|
||||
<url url="mailto:raj at cup dot hp dot com" name="Rick Jones"> notes that
|
||||
if the server is running a Microsoft TCP stack, clients
|
||||
receive RST segments whenever the listen queue overflows. In other words,
|
||||
if the server is really busy, new connections receive the reset message.
|
||||
@ -7061,12 +7120,10 @@ Mikael Andersson reports that clicking on Webmin's <em/cachemgr.cgi/
|
||||
link creates numerous instances of <em/cachemgr.cgi/ that quickly
|
||||
consume all available memory and brings the system to its knees.
|
||||
<p>
|
||||
Changing the path to use Squid's own <em/cachemgr.cgi/ fixes
|
||||
this problem. You can change the path by logging into the
|
||||
Webmin GUI, select <em/Servers/ then <em/Squid Proxy Cache/.
|
||||
Next select <em/Module Config/. From here you'll be
|
||||
able to enter the pathname to the <em/cachemgr.cgi/ that came
|
||||
with Squid.
|
||||
Joe Cooper reports this to be caused by SSL problems in some browsers
|
||||
(mainly Netscape 6.x/Mozilla) if your Webmin is SSL enabled. Try with
|
||||
another browser such as Netscape 4.x or Microsoft IE, or disable SSL
|
||||
encryption in Webmin.
|
||||
|
||||
<sect1>Segment Violation at startup or upon first request
|
||||
|
||||
@ -7121,6 +7178,29 @@ only use the proxy.pac. Cydoor aps will use both and will generate the errors.
|
||||
Disabling the old proxy settings in IE is not enought, you should delete
|
||||
them completely and only use the proxy.pac for example.
|
||||
|
||||
<sect1>Requests for international domain names does not work
|
||||
<p>
|
||||
By Henrik Nordström
|
||||
<p>
|
||||
Some people have asked why requests for domain names using national
|
||||
symbols as "supported" by the certain domain registrars does not work
|
||||
in Squid. This is because there as of yet is no standard on how to
|
||||
manage national characters in the current Internet protocols such
|
||||
as HTTP or DNS. The current Internet standards is very strict
|
||||
on what is an acceptable hostname and only accepts A-Z a-z 0-9 and -
|
||||
in Internet hostname labels. Anything outside this is outside
|
||||
the current Internet standards and will cause interoperability
|
||||
issues such as the problems seen with such names and Squid.
|
||||
<p>
|
||||
When there is a consensus in the DNS and HTTP standardization groups
|
||||
on how to handle international domain names Squid will be changed to
|
||||
support this if any changes to Squid will be required.
|
||||
<p>
|
||||
If you are interested in the progress of the standardization process
|
||||
for international domain names please see the <url
|
||||
url="http://www.ietf.org/html.charters/idn-charter.html" name="IETF idn">
|
||||
working group or it's <url url="http://www.i-d-n.net/" name="dedicated
|
||||
page">.
|
||||
|
||||
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
|
||||
|
||||
@ -8040,7 +8120,16 @@ some other replacement algorithms by using the <em/--enable-heap-replacement/
|
||||
configure option. Currently, the heap replacement code supports two
|
||||
additional algorithms: LFUDA, and GDS.
|
||||
<p>
|
||||
The heap replacement code was contributed by John Dilley and others
|
||||
With Squid version 2.4 and later you should use this configure option:
|
||||
<verb>
|
||||
./configure --enable-removal-policies=heap
|
||||
</verb>
|
||||
<p>
|
||||
Then, in <em/squid.conf/, you can select different policies with the
|
||||
<em/cache_replacement_policy/ option. See the <em/squid.conf/ comments
|
||||
for details.
|
||||
<p>
|
||||
The LFUDA and GDS replacement code was contributed by John Dilley and others
|
||||
from Hewlett-Packard. Their work is described in these papers:
|
||||
<enum>
|
||||
<item>
|
||||
@ -8174,7 +8263,7 @@ the <em/bind()/ system call fails. Squid handles this as a failed
|
||||
ident lookup.
|
||||
<p>
|
||||
<it>
|
||||
So why bind in that way? If you know you are transparent proxying, then why
|
||||
So why bind in that way? If you know you are interception proxying, then why
|
||||
not bind the local endpoint to the host's (intranet) IP address? Why make
|
||||
the masses suffer needlessly?
|
||||
</it>
|
||||
@ -8631,7 +8720,7 @@ for more than 4 hours.
|
||||
<P>
|
||||
Because the problem appears to be with IPFilter I would guess that you
|
||||
would only run into this issue if you are trying to run Squid as a
|
||||
transparent proxy using IPFilter. That makes sense. If there is anyone
|
||||
interception proxy using IPFilter. That makes sense. If there is anyone
|
||||
with information that would indicate my finding are incorrect I am willing
|
||||
to investigate further.
|
||||
|
||||
@ -8737,8 +8826,8 @@ diff -p -u -r1.40 -r1.41
|
||||
* SUCH DAMAGE.
|
||||
*
|
||||
* @(#)uipc_socket.c 8.3 (Berkeley) 4/15/94
|
||||
- * $Id: FAQ.sgml,v 1.3 2004/09/09 12:36:55 cvsdist Exp $
|
||||
+ * $Id: FAQ.sgml,v 1.3 2004/09/09 12:36:55 cvsdist Exp $
|
||||
- * $Id: FAQ.sgml,v 1.4 2004/09/09 12:37:50 cvsdist Exp $
|
||||
+ * $Id: FAQ.sgml,v 1.4 2004/09/09 12:37:50 cvsdist Exp $
|
||||
*/
|
||||
|
||||
#include <sys/param.h>
|
||||
@ -8829,6 +8918,19 @@ to the following will appear:
|
||||
/dev/da2a on /usr/local/squid/cache (ufs, local, noatime, soft-updates, writes: sync 70 async 225)
|
||||
</verb>
|
||||
|
||||
<sect2>Internal DNS problems with jail environment
|
||||
<p>
|
||||
Some users report problems with running Squid in the jail environment. Specifically,
|
||||
Squid logs messages like:
|
||||
<verb>
|
||||
2001/10/12 02:08:49| comm_udp_sendto: FD 4, 192.168.1.3, port 53: (22) Invalid argument
|
||||
2001/10/12 02:08:49| idnsSendQuery: FD 4: sendto: (22) Invalid argument
|
||||
</verb>
|
||||
<p>
|
||||
You can eliminate the problem by putting the jail's network interface
|
||||
address in the 'udp_outgoing_addr' configuration option
|
||||
in <em>squid.conf</em>.
|
||||
|
||||
<sect1>OSF1/3.2
|
||||
|
||||
<P>
|
||||
@ -8985,15 +9087,45 @@ When using Squid, some sites may give erorrs such as
|
||||
although these sites work fine without going through Squid.
|
||||
<p>
|
||||
Some versions of linux implement
|
||||
<url url="ftp://ftp.isi.edu/in-notes/rfc2481.txt" name="Explicit
|
||||
<url url="http://www.aciri.org/floyd/ecn.html" name="Explicit
|
||||
Congestion Notification"> (ECN) and this can cause
|
||||
some TCP connections to fail. You can disable ECN with
|
||||
some TCP connections to fail when contacting some sites with broken firewalls
|
||||
or broken TCP/IP implementations.
|
||||
|
||||
To work around such broken sites you can disable ECN with
|
||||
the following command:
|
||||
<verb>
|
||||
echo 0 >/proc/sys/net/ipv4/tcp_ecn
|
||||
</verb>
|
||||
<p>
|
||||
See also the <url url="http://answerpointe.cctec.com/maillists/nanog/historical/0104/msg00714.html" name="thread on the NANOG mailing list">.
|
||||
Found this on the FreeBSD mailing list:
|
||||
<quote>
|
||||
<p>
|
||||
From: Robert Watson
|
||||
<p>
|
||||
As Bill Fumerola has indicated, and I thought I'd follow up in with a bit
|
||||
more detail, the behavior you're seeing is the result of a bug in the
|
||||
FreeBSD IPFW code. FreeBSD did a direct comparison of the TCP header flag
|
||||
field with an internal field in the IPFW rule description structure.
|
||||
Unfortunately, at some point, someone decided to overload the IPFW rule
|
||||
description structure field to add a flag representing "ESTABLISHED". They
|
||||
used a flag value that was previously unused by the TCP protocol (which
|
||||
doesn't make it safer, just less noticeable). Later, when that flag was
|
||||
allocated for ECN (Endpoint Congestion Notification) in TCP, and Linux
|
||||
began using ECN by default, the packets began to match ESTABLISHED rules
|
||||
regardless of the other TCP header flags. This bug was corrected on the
|
||||
RELENG_4 branch, and security advisory for the bug was released. This
|
||||
was, needless to say, a pretty serious bug, and good example of why you
|
||||
should be very careful to compare only the bits you really mean to, and
|
||||
should seperate packet state from protocol state in management structures,
|
||||
as well as make use of extensive testing to make sure rules actually have
|
||||
the effect you describe.
|
||||
</quote>
|
||||
<p>
|
||||
See also the <url url="http://answerpointe.cctec.com/maillists/nanog/historical/0104/msg00714.html" name="thread on the NANOG mailing list">,
|
||||
<url url="ftp://ftp.isi.edu/in-notes/rfc3168.txt" name="RFC3168 "The Addition of Explicit Congestion Notification (ECN) to IP, PROPOSED STANDARD"">
|
||||
or <url url="http://www.aciri.org/floyd/ecn.html" name="Sally Floyd's page on ECN and problems related to it">
|
||||
|
||||
|
||||
|
||||
<sect1>HP-UX
|
||||
@ -9055,7 +9187,7 @@ their own implementation.
|
||||
|
||||
<P>
|
||||
A redirector allows the administrator to control the locations to which
|
||||
his users goto. Using this in conjunction with transparent proxies
|
||||
his users goto. Using this in conjunction with interception proxies
|
||||
allows simple but effective porn control.
|
||||
|
||||
<sect1>How does it work?
|
||||
@ -9103,7 +9235,7 @@ it may be desirable to return an HTTP "301" or "302" redirect message
|
||||
to the client. This is now possible with Squid version 1.1.19.
|
||||
|
||||
<P>
|
||||
Simply modify your redirector program to append either "301:" or "302:"
|
||||
Simply modify your redirector program to prepend either "301:" or "302:"
|
||||
before the new URL. For example, the following script might be used
|
||||
to direct external clients to a secure Web server for internal documents:
|
||||
<verb>
|
||||
@ -9878,7 +10010,7 @@ information. However, the following instructions are correct as of
|
||||
this writing (July 1999.)
|
||||
|
||||
<P>
|
||||
Getting transparent caching to work requires four distinct steps:
|
||||
Getting interception caching to work requires four distinct steps:
|
||||
<enum>
|
||||
<item>
|
||||
|
||||
@ -9950,17 +10082,17 @@ forwarding commands.
|
||||
|
||||
<item>In the <em/httpd_accel_host/ option, <em/virtual/ is the magic word!
|
||||
|
||||
<item>The <em/httpd_accel_with_proxy on/ is required to enable transparent
|
||||
proxy mode; essentially in transparent proxy mode Squid thinks it is acting
|
||||
<item>The <em/httpd_accel_with_proxy on/ is required to enable interception
|
||||
proxy mode; essentially in interception proxy mode Squid thinks it is acting
|
||||
both as an accelerator (hence accepting packets for other IPs on port 80) and
|
||||
a caching proxy (hence serving files out of cache.)
|
||||
|
||||
<item> You <bf/must/ use <em/httpd_accel_uses_host_header on/ to get
|
||||
the cache to work properly in transparent mode. This enables the cache
|
||||
the cache to work properly in interception mode. This enables the cache
|
||||
to index its stored objects under the true hostname, as is done in a
|
||||
normal proxy, rather than under the IP address. This is especially
|
||||
important if you want to use a parent cache hierarchy, or to share
|
||||
cache data between transparent proxy users and non-transparent proxy
|
||||
cache data between interception proxy users and non-interception proxy
|
||||
users, which you can do with Squid in this configuration.
|
||||
|
||||
</itemize>
|
||||
@ -10195,7 +10327,7 @@ not host names and demon aren't generally asked for IP addresses by other
|
||||
users;
|
||||
|
||||
<item>
|
||||
Linux kernel 2.0.30 is a no-no as transparent proxying is broken (I use
|
||||
Linux kernel 2.0.30 is a no-no as interception proxying is broken (I use
|
||||
2.0.29);
|
||||
|
||||
<item>
|
||||
@ -10380,7 +10512,7 @@ Apply the route map to the ethernet interface.
|
||||
|
||||
<P>
|
||||
<url url="mailto:morgan@curtin.net" name="Bruce Morgan"> notes that
|
||||
there is a Cisco bug relating to transparent proxying using IP
|
||||
there is a Cisco bug relating to interception proxying using IP
|
||||
policy route maps, that causes NFS and other applications to break.
|
||||
Apparently there are two bug reports raised in Cisco, but they are
|
||||
not available for public dissemination.
|
||||
@ -10426,7 +10558,7 @@ Conversely, this set has worse performance, but works for all protocols:
|
||||
|
||||
<P>
|
||||
Just for kicks, here's an email message posted to squid-users
|
||||
on how to make transparent proxying work with a Cisco router
|
||||
on how to make interception proxying work with a Cisco router
|
||||
and Squid running on Linux.
|
||||
|
||||
<P>
|
||||
@ -10439,7 +10571,7 @@ running Linux 2.0.33.
|
||||
|
||||
<P>
|
||||
Many thanks to the following individuals and the squid-users list for
|
||||
helping me get redirection and transparent proxying working on my
|
||||
helping me get redirection and interception proxying working on my
|
||||
Cisco/Linux box.
|
||||
|
||||
<itemize>
|
||||
@ -10529,16 +10661,16 @@ this in /etc/rc.d/rc.local
|
||||
<P>
|
||||
I am using
|
||||
<url url="/Versions/1.1/1.1.20/" name="v1.1.20 of Squid"> with
|
||||
<url url="http://hem.passagen.se/hno/squid/squid-1.1.20.host_and_virtual.patch"
|
||||
<url url="http://devel.squid-cache.org/hno/patches/squid-1.1.20.host_and_virtual.patch"
|
||||
name="Henrik's patch">
|
||||
installed. You will want to install this patch if using a setup similar
|
||||
to mine.
|
||||
|
||||
<sect1>The cache is trying to connect to itself...
|
||||
<P>
|
||||
by <url url="mailto:hno@hem.passagen.se" name="Henrik Nordstrom">
|
||||
by <url url="mailto:hno@squid-cache.org" name="Henrik Nordstrom">
|
||||
<P>
|
||||
I think almost everyone who have tried to build a transparent proxy
|
||||
I think almost everyone who have tried to build a interception proxy
|
||||
setup have been bitten by this one.
|
||||
|
||||
<P>
|
||||
@ -10548,7 +10680,7 @@ Measures you can take:
|
||||
Deny Squid from fetching objects from itself (using ACL lists).
|
||||
<item>
|
||||
Apply a small patch that prevents Squid from looping infinitely
|
||||
(available from <url url="http://hem.passagen.se/hno/squid/" name="Henrik's Squid Patches">)
|
||||
(available from <url url="http://devel.squid-cache.org/hno/" name="Henrik's Squid Patches">)
|
||||
<item>
|
||||
Don't run Squid on port 80, and redirect port 80 not destined for
|
||||
the local machine to Squid (redirection == ipfilter/ipfw/ipfadm). This
|
||||
@ -10564,7 +10696,7 @@ front of Squid. Squid does not yet know how to interface to ipfilter
|
||||
<P>
|
||||
by Duane Wessels
|
||||
<P>
|
||||
I set out yesterday to make transparent caching work with Squid and
|
||||
I set out yesterday to make interception caching work with Squid and
|
||||
FreeBSD. It was, uh, fun.
|
||||
<P>
|
||||
It was relatively easy to configure a cisco to divert port 80
|
||||
@ -10650,7 +10782,7 @@ and the <em/squid.conf/ lines are:
|
||||
<P>
|
||||
by <url url="mailto:John.Saunders@scitec.com.au" name="John Saunders">
|
||||
<P>
|
||||
This is to do with configuring transparent proxy
|
||||
This is to do with configuring interception proxy
|
||||
for an ACC Tigris digital access server (like a CISCO 5200/5300
|
||||
or an Ascend MAX 4000). I've found that doing this in the NAS
|
||||
reduces traffic on the LAN and reduces processing load on the
|
||||
@ -10836,7 +10968,7 @@ Finally add "OPTION GRE" to your kernel config file and rebuild
|
||||
your kernel. Note, the <em/opt_gre.h/ file is
|
||||
created when you run <em/config/.
|
||||
Once your kernel is installed you will need to
|
||||
<ref id="trans-freebsd" name="configure FreeBSD for transparent proxying">.
|
||||
<ref id="trans-freebsd" name="configure FreeBSD for interception proxying">.
|
||||
|
||||
<sect2>Configuring Linux 2.2
|
||||
|
||||
@ -10918,7 +11050,7 @@ Finally you will need to load the module:
|
||||
<P>
|
||||
The machine should now be striping the GRE encapsulation from any packets
|
||||
recieved and requeuing them. The system will also need to be configured
|
||||
for transparent proxying, either with <ref id="trans-linux-1" name="ipfwadm">
|
||||
for interception proxying, either with <ref id="trans-linux-1" name="ipfwadm">
|
||||
or with <ref id="trans-linux-2" name="ipchains">.
|
||||
|
||||
<sect2>Configuring Others
|
||||
@ -10948,12 +11080,12 @@ is welcome to code it up and contribute to the Squid project.
|
||||
<p>
|
||||
by <url url="mailto:signal at shreve dot net" name="Brian Feeny">.
|
||||
<p>
|
||||
First, configure Squid for transparent caching as detailed
|
||||
First, configure Squid for interception caching as detailed
|
||||
at the <ref id="trans-caching" name="beginning of this section">.
|
||||
<p>
|
||||
Next, configure
|
||||
the Foundry layer 4 switch to
|
||||
transparently redirect traffic to your Squid box or boxes. By default,
|
||||
redirect traffic to your Squid box or boxes. By default,
|
||||
the Foundry
|
||||
redirects to port 80 of your squid box. This can
|
||||
be changed to a different port if needed, but won't be covered
|
||||
@ -10975,7 +11107,7 @@ squid2.foo.com 192.168.1.11
|
||||
|
||||
<p>
|
||||
We will assume you have various workstations, customers, etc, plugged
|
||||
into the switch for which you want them to be transparently proxied.
|
||||
into the switch for which you want them to be intercepted and sent to Squid.
|
||||
The squid caches themselves should be plugged into the switch as well.
|
||||
Only the interface that the router is connected to is important. Where you
|
||||
put the squid caches or other connections does not matter.
|
||||
@ -11037,6 +11169,12 @@ howto that would apply for most people, not meant to be a comprehensive
|
||||
manual of how to configure a Foundry switch. I can however revise this
|
||||
with any information necessary if people feel it should be included.
|
||||
|
||||
<sect1>Can I use <em/proxy_auth/ with interception?
|
||||
<p>
|
||||
No, you cannot. With interception proxying, the client thinks
|
||||
it is talking to an origin server and would never send the
|
||||
<em/Proxy-authorization/ request header.
|
||||
|
||||
<!-- %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% -->
|
||||
|
||||
<sect>SNMP
|
||||
@ -11279,14 +11417,14 @@ new disk and leave the existing ones in place.
|
||||
|
||||
<sect1>Squid 2 performs badly on Linux
|
||||
<P>
|
||||
by <url url="mailto:hno@hem.passagen.se" name="Henrik Nordstrom">
|
||||
by <url url="mailto:hno@squid-cache.org" name="Henrik Nordstrom">
|
||||
<P>
|
||||
You may have enabled Asyncronous I/O with the <em/--enable-async-io/
|
||||
configure option.
|
||||
Be careful when using threads on Linux. Most versions of libc5 and
|
||||
early versions of glibc have problems with threaded applications. I
|
||||
would not recommend <em/--enable-async-io/ on Linux unless your system
|
||||
uses a recent version of glibc.
|
||||
very early versions of glibc have problems with threaded applications.
|
||||
I would not recommend <em/--enable-async-io/ on Linux unless your system
|
||||
uses glibc 2.1.3 or later.
|
||||
|
||||
<P>
|
||||
You should also know that <em/--enable-async-io/ is not optimal unless
|
||||
@ -11549,7 +11687,7 @@ network.
|
||||
<P>
|
||||
For our local access we use a dstdomain ACL, and for delay pool exceptions
|
||||
we use a dst ACL as well since the delay pool ACL processing is done using
|
||||
'fast lookups', which means (among other things) it won't wait for a DNS
|
||||
"fast lookups", which means (among other things) it won't wait for a DNS
|
||||
lookup if it would need one.
|
||||
|
||||
<P>
|
||||
@ -12081,7 +12219,7 @@ squid.conf.
|
||||
<P>
|
||||
<url url="http://www.transproxy.nlc.net.au/" name="transproxy">
|
||||
is a program used in conjunction with the Linux Transparent Proxy
|
||||
networking feature, and ipfwadm, to transparently proxy HTTP and
|
||||
networking feature, and ipfwadm, to intercept HTTP and
|
||||
other requests. Transproxy is written by <url url="mailto:john@nlc.net.au" name="John Saunders">.
|
||||
|
||||
<sect2>Iain's redirector package
|
||||
@ -12207,32 +12345,45 @@ queue parameters for Squid. Message queue implementations
|
||||
normally have the following parameters:
|
||||
<descrip>
|
||||
<tag/MSGMNB/
|
||||
Maximum number of bytes in a single queue.
|
||||
Maximum number of bytes per message queue.
|
||||
<tag/MSGMNI/
|
||||
Maximum number of message queue identifiers.
|
||||
Maximum number of message queue identifiers (system wide).
|
||||
<tag/MSGSEG/
|
||||
Maximum number of message segments.
|
||||
<tag/MSGMAX/
|
||||
Maximum size of a message segment.
|
||||
Maximum number of message segments per queue.
|
||||
<tag/MSGSSZ/
|
||||
Size of a message segment.
|
||||
<tag/MSGTQL/
|
||||
Maximum number of messages in the whole system.
|
||||
Maximum number of messages (system wide).
|
||||
<tag/MSGMAX/
|
||||
Maximum size of a whole message. On some systems you may need to
|
||||
increase this limit. On other systems, you may not be able
|
||||
to change it.
|
||||
</descrip>
|
||||
|
||||
<p>
|
||||
The messages between Squid and diskd are 32 bytes. Thus, MSGMAX
|
||||
should be 32 or greater. You may want to set it to a larger
|
||||
value, just to be safe.
|
||||
The messages between Squid and diskd are 32 bytes for 32-bit CPUs
|
||||
and 40 bytes for 64-bit CPUs. Thus, MSGSSZ should be 32 or greater.
|
||||
You may want to set it to a larger value, just to be safe.
|
||||
|
||||
<p>
|
||||
We'll have two queues for each <em/cache_dir/ -- one in each direction.
|
||||
So, MSGMNI needs to be at least two times the number of <em/cache_dir/'s.
|
||||
|
||||
<p>
|
||||
I've found that 75 messages per queue is about the limit of decent performance.
|
||||
If each diskd message consists of just one segment (depending on your
|
||||
value of MSGSSZ), then MSGSEG should be greater than 75.
|
||||
|
||||
<p>
|
||||
MSGMNB and MSGTQL affect how many messages can be in the queues
|
||||
at one time. I've found that 75 messages per queue is about
|
||||
the limit of decent performance. Thus, MSGMNB must be
|
||||
at least 75*MSGMAX, and MSGTQL must be at least 75 times
|
||||
the number of <em/cache_dir/'s.
|
||||
at one time. Diskd messages shouldn't be
|
||||
more than 40 bytes, but let's use 64 bytes to be safe. MSGMNB
|
||||
should be at least 64*75. I recommend rounding up to the nearest
|
||||
power of two, or 8192.
|
||||
|
||||
<p>
|
||||
MSGTQL should be at least 75 times the number of <em/cache_dir/'s
|
||||
that you'll have.
|
||||
|
||||
<sect2>FreeBSD
|
||||
<p>
|
||||
@ -12245,11 +12396,11 @@ options SYSVMSG
|
||||
You can set the parameters in the kernel as follows. This is just
|
||||
an example. Make sure the values are appropriate for your system:
|
||||
<verb>
|
||||
options MSGMNB=16384 # max # of bytes in a queue
|
||||
options MSGMNI=41 # number of message queue identifiers
|
||||
options MSGSEG=2049 # number of message segments
|
||||
options MSGMNB=8192 # max # of bytes in a queue
|
||||
options MSGMNI=40 # number of message queue identifiers
|
||||
options MSGSEG=512 # number of message segments per queue
|
||||
options MSGSSZ=64 # size of a message segment
|
||||
options MSGTQL=512 # max messages in system
|
||||
options MSGTQL=2048 # max messages in system
|
||||
</verb>
|
||||
|
||||
<sect2>Digital Unix
|
||||
@ -12258,9 +12409,9 @@ Message queue support seems to be in the kernel
|
||||
by default. Setting the options is as follows:
|
||||
<verb>
|
||||
options MSGMNB="8192" # max # bytes on queue
|
||||
options MSGMNI="31" # # of message queue identifiers
|
||||
options MSGMAX="2049" # max message size
|
||||
options MSGTQL="1024" # # of system message headers
|
||||
options MSGMNI="40" # # of message queue identifiers
|
||||
options MSGMAX="2048" # max message size
|
||||
options MSGTQL="2048" # # of system message headers
|
||||
</verb>
|
||||
|
||||
<p>
|
||||
@ -12274,9 +12425,9 @@ If you have a newer version (DU64), then you can probably use
|
||||
To change them make a file like this called ipc.stanza:
|
||||
<verb>
|
||||
ipc:
|
||||
msg-max = 2049
|
||||
msg-mni = 31
|
||||
msg-tql = 1024
|
||||
msg-max = 2048
|
||||
msg-mni = 40
|
||||
msg-tql = 2048
|
||||
msg-mnb = 8192
|
||||
</verb>
|
||||
then run
|
||||
@ -12312,11 +12463,11 @@ name="Demangling Message Queues"> in Sunworld Magazine.
|
||||
I don't think the above article really tells you how to set the parameters.
|
||||
You do it in <em>/etc/system</em> with lines like this:
|
||||
<verb>
|
||||
set msgsys:msginfo_msgmax=2049
|
||||
set msgsys:msginfo_msgmax=2048
|
||||
set msgsys:msginfo_msgmnb=8192
|
||||
set msgsys:msginfo_msgmni=31
|
||||
set msgsys:msginfo_msgmni=40
|
||||
set msgsys:msginfo_msgssz=64
|
||||
set msgsys:msginfo_msgtql=1024
|
||||
set msgsys:msginfo_msgtql=2048
|
||||
</verb>
|
||||
<p>
|
||||
Of course, you must reboot whenever you modify <em>/etc/system</em>
|
||||
@ -12673,7 +12824,7 @@ want to make a cron job that regularly verifies that your proxy blocks
|
||||
access to port 25.
|
||||
|
||||
<verb>
|
||||
$Id: FAQ.sgml,v 1.3 2004/09/09 12:36:55 cvsdist Exp $
|
||||
$Id: FAQ.sgml,v 1.4 2004/09/09 12:37:50 cvsdist Exp $
|
||||
</verb>
|
||||
</article>
|
||||
<!-- LocalWords: SSL MSIE Netmanage Chameleon WebSurfer unchecking remotehost
|
||||
|
||||
2
sources
2
sources
@ -1 +1 @@
|
||||
6a3977716571a8459cf66b96306f7c05 squid-2.4.STABLE1-src.tar.gz
|
||||
5fdaf22d66d7b776325902adc0fd438d squid-2.4.STABLE3-src.tar.gz
|
||||
|
||||
49
squid.spec
49
squid.spec
@ -1,8 +1,8 @@
|
||||
Summary: The Squid proxy caching server.
|
||||
Name: squid
|
||||
Version: 2.4.STABLE1
|
||||
Release: 6
|
||||
Serial: 6
|
||||
Version: 2.4.STABLE3
|
||||
Release: 1.7.2
|
||||
Serial: 7
|
||||
License: GPL
|
||||
Group: System Environment/Daemons
|
||||
Source: http://www.squid-cache.org/Squid/v2/squid-%{version}-src.tar.gz
|
||||
@ -14,15 +14,11 @@ Patch0: squid-2.1-make.patch
|
||||
Patch1: squid-2.4-config.patch
|
||||
Patch2: squid-perlpath.patch
|
||||
Patch3: squid-location.patch
|
||||
Patch10: squid-2.4.stable1-diskd_fixed_path.patch
|
||||
Patch11: squid-2.4.stable1-force_valid_blksize.patch
|
||||
Patch12: squid-2.4.stable1-high_cpu_with_peers.patch
|
||||
Patch13: squid-2.4.stable1-htcp_assertion_fix.patch
|
||||
Patch14: squid-2.4.stable1-kill_parent_on_child_sigkill.patch
|
||||
Patch15: squid-2.4.stable1-wrong_sign_on_timestamp_check.patch
|
||||
Patch16: squid-2.4stable-ftpcrash.path
|
||||
Patch10: squid-2.4.STABLE3-SNMP_memory_leaks.patch
|
||||
Patch11: squid-2.4.STABLE3-ftp_coredump.patch
|
||||
Patch12: squid-2.4.STABLE3-htcp_off.patch
|
||||
BuildRoot: %{_tmppath}/%{name}-%{version}-root
|
||||
Prereq: /sbin/chkconfig logrotate shadow-utils /etc/init.d
|
||||
Prereq: /sbin/chkconfig logrotate shadow-utils
|
||||
Requires: bash >= 2.0
|
||||
BuildPrereq: openjade sgml-tools openldap-devel pam-devel
|
||||
Obsoletes: squid-novm
|
||||
@ -45,13 +41,9 @@ lookup program (dnsserver), a program for retrieving FTP data
|
||||
%patch1 -p1 -b .config
|
||||
%patch2 -p1 -b .perlpath
|
||||
%patch3 -p1
|
||||
%patch10 -p0 -b .diskd
|
||||
%patch11 -p0 -b .force_valid_blksize
|
||||
%patch12 -p0 -b .cpu_peer
|
||||
%patch13 -p0 -b .htcp
|
||||
%patch14 -p0 -b .kill_parent
|
||||
%patch15 -p0 -b .timestamp
|
||||
%patch16 -p0 -b .ftp-crash
|
||||
%patch10 -p1 -b .snmp
|
||||
%patch11 -p1 -b .ftp
|
||||
%patch12 -p1 -b .htcp
|
||||
|
||||
%build
|
||||
%configure \
|
||||
@ -60,7 +52,7 @@ lookup program (dnsserver), a program for retrieving FTP data
|
||||
--enable-poll --enable-snmp --enable-removal-policies="heap,lru" \
|
||||
--enable-storeio="aufs,coss,diskd,ufs" \
|
||||
--enable-delay-pools --enable-linux-netfilter \
|
||||
--enable-htcp --enable-carp --with-pthreads \
|
||||
--enable-carp --with-pthreads \
|
||||
--enable-auth-modules="LDAP,NCSA,PAM,SMB,MSNT" # --enable-icmp
|
||||
|
||||
# Some versions of autoconf fail to detect sys/resource.h correctly;
|
||||
@ -143,7 +135,7 @@ rm -rf $RPM_BUILD_ROOT
|
||||
%config /etc/squid/mib.txt
|
||||
/etc/squid/squid.conf.default
|
||||
/etc/squid/mime.conf.default
|
||||
/etc/squid/errors
|
||||
%config(noreplace) /etc/squid/errors
|
||||
/usr/lib/squid
|
||||
/usr/sbin/squid
|
||||
/usr/sbin/client
|
||||
@ -257,6 +249,23 @@ if [ "$1" -ge "1" ] ; then
|
||||
fi
|
||||
|
||||
%changelog
|
||||
* Mon Feb 18 2002 Bill Nottingham <notting@redhat.com>
|
||||
- 2.4.STABLE3 + patches
|
||||
- turn off HTCP at request of maintainers
|
||||
- leave SNMP enabled in the build, but disabled in the default config
|
||||
|
||||
* Fri Jan 25 2002 Tim Powers <timp@redhat.com>
|
||||
- rebuild against new libssl
|
||||
|
||||
* Wed Jan 09 2002 Tim Powers <timp@redhat.com>
|
||||
- automated rebuild
|
||||
|
||||
* Mon Jan 07 2002 Florian La Roche <Florian.LaRoche@redhat.de>
|
||||
- require linuxdoc-tools instead of sgml-tools
|
||||
|
||||
* Tue Sep 25 2001 Bill Nottingham <notting@redhat.com>
|
||||
- update to 2.4.STABLE2
|
||||
|
||||
* Mon Sep 24 2001 Bill Nottingham <notting@redhat.com>
|
||||
- add patch to fix FTP crash
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user