On Sun, 19 Jun 2005, Linda W wrote:
Before you sent your question on "cachemgr.cgi", I'd already spent a
few hours trying to get that to work, to no avail. I'm not running a
web-server, but am just using squid's caching features. "cachemgr.cgi"
_looks_ like it wants to be run out of some server's cgi-bin directory. I
wasn't able to figure out how to get it to be called on my web-proxy.
cachemgr.cgi is a CGI executable meant to be called from a web server.
squidclient mgr: provides the same data in a slightly more raw format..
Please note that cachemgr.cgi does not need to be on the same server as
the proxy. Just some web server in your network allowed to access the
proxy as "manager" (see squid.conf).
Squid is not a web server, and can not run the cachemgr.cgi CGI program.
Also, curiosity and strangeness. I "thought" I had to recompile
squid to get a transparent proxy out of it, but then I was a bit
'confused'...on a 2.6 kernel...I wasn't sure if linux-netfilter was all
I needed or if I'm doing transparent relaying to specific IP's if I
would need IP filtering, and I had no clue as to what pf-transparent
was...(sigh)....
For correct operation your Squid need to be compiled with the
--enable-linux-netfilter option if you want to run it as a transparently
intercepting proxy intercepting port 80 traffic from your internal
clients to the Internet.
Many config options, but not clear what they all do.... Another
example why would one choose "poll" vs. "select"/"kqueue"/"epoll". Are
some available only on some architectures? Which are best for linux or
are their tradeoffs?
Normally configure selects the most suitable for you automatically.
The kqueue(FreeBSD)/epoll(Linux-2.6) support is still prelminary and
available in Squid-3 only. The benefit compared to poll is that they
handle lots of concurrent connections better. These come from the
different UNIX style connection readiness generations:
1: select, which has been with us for as long as UNIX almost
2: poll, came to UNIX when select was found limiting
3: various experimental approaches such as Linux RT-Signals
4: kqueue/epoll, todays "cutting edge". Also seeing a little potential
competition from AIO based approaches.
Regards
Henrik
