目立つ所で Japan Web Cache Workshopの宣伝を…
【訳者注】
ひとまず翻訳終了。校正中。
本文各節の見出しを、 オリジナルのFAQの対応する位置にリンクしてあります。 日本語が良くわからない場合は、見出しをクリックして英語を参照して下さい。
malloc(3)がメモリを確保できなかったと文句をいっているのをみつけました。でも、私のシステムはたくさんのRAMを積んでいるんです！
Squidには、メインのサーバプログラムであるsquidと、 ドメインネームを検索するdnsserver、FTPデータを獲得するための ftpget、その他の管理とクライアントのプログラムから構成されています。 squidが起動を開始すると、設定された数のdnsserverプロセスを 生成します。そのプロセスは、それぞれが単一でブロック化されたDNS検索を行なう ことが出来ます。このことは、キャッシュがDNS検索を待つ時間の総量を減少させます。
Squidは、APRAによって支援されていたHarvestプロジェクトが起源です。 http://harvest.cs.colorado.edu/
Harris' Lament says, "All the good ones are taken."
ハリスの哀歌で、“よいものがすべて得られる。”と言っています。
（【訳者注】
これは、どういう意味だろう。fortuneコマンドの出力の一つだな。）
我々は、Harvestキャッシュと、この新しいバージョンを区別する必要がありました。 Squidは、初期の開発コード名で、そのあだ名がいつまでも残っているのです。
次のリストに挙げられた、世界中の多くのミラーサイトがあります。
多くの寿司屋でも、ヤリイカを飼っています。(^^)
【訳者注】
日本語を主に用いるメーリングリストでは、"Proxy JP ML"において Squidの話題が時々出ます。が、名前の通りProxy技術について語るのが目的で、 Squid cacheのメーリングリストというわけではありません。 参加希望は、 proxy-jp-request@is.aist-nara.ac.jpまで。
【訳者注】
日本語で書かれたものについて、squidに関しては ヤリイカのおいしい料理法があり、キャッシュ一般については、 http://w3.lab.kdd.co.jp/technotes/WWW/Server/cached/cached.htmlがあります。 さらに、 Cache Now!キャンペーンの日本語訳も参考になるでしょう。
This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
Jonathan Larmour
<JLarmour@origin-at.co.uk>
Cord Beermann
<cord@cc.fh-lippe.de>
Tony Sterrett
<tony@nlanr.net>
Gerard Hynes
<ghynes@compusult.nf.ca>
Duane Wessels
<wessels@nlanr.net>
K Claffy
<kc@nlanr.net>
Paul Southworth
<pauls@locust.cic.net>
集めたものや、更新、コメントを squid-faq@nlanr.net に送って欲しい。
【訳者注】
次の人々が、このFAQを日本語に翻訳するのに貢献してくれました。
片山 健夫 (KATAYAMA, Takeo) <tkatayam@pi.titech.ac.jp>
喜瀬 浩 (KISE, Hiroshi) <kise@imicom.or.jp>
松井 健一 (MATSUI, Kenichi) <matsui.kenichi@nslab.ntt.co.jp>
さらに、次の人々が、このFAQに有用な事項を追加してくました。
飯島 昭博 (IIJIMA, Akihiro)さん <aki@noc.titech.ac.jp>
大日本インキの立川さん<yutaka@souken.dic.co.jp>誤字、誤訳、このFAQに付け加えた方が良い事項、コメントを、 squid-faq-j@pi.titech.ac.jp に送って欲しい。なお、翻訳者は決してSquidについて 詳しいわけではないので、Squidについて質問されても答えられるわけではない。 japan.www.proxy.squid, fj.net.www.servers などのニュースグループで質問して欲しい。
% gzip -dc squid-x.y.z-src.tar.gz | tar xvf -
次に、コンフィギュアし、コンパイルし、インストールします。
% cd squid-x.y.z
% ./configure
% make all
% make install
Squidの構築には、GNU C (gcc)コンパイラを使うのが、最も良いでしょう。 最近のバージョンは、ANSI C用に変更されていて、古典的な コンパイラーでは、うまくコンパイル出来ないでしょう。 GNU C コンパイラは、 ftp://prep.ai.mit.edu/pub/gnu/にあります。 （【訳者注】 日本国内では、 ftp://ftp.cs.titech.ac.jp/GNU/が良い。） コンフィギュアは、多くのオプションを付けることが出来きます。 最も良く使うのが、標準とは異なったディレクトリにインストールするための、 --prefixです。標準で、インストールされるディレクトリは、 /usr/local/squidです。この標準を変えるためには、次のようにします。
% cd squid-x.y.z
% ./configure --prefix=/some/other/directory/squid
/usr/local/squid/bin/RunCache &
% client http://www.netscape.com/ > test
これ以外のコマンドラインのHTTPクライアントプログラムも存在しています。 ftp://ftp.pasteur.fr/pub/Network/url_get/にあるurl_getと、 ftp://ftp.pasteur.fr/pub/Network/echoping/にあるechopingの 2つが良く使われます。 最も重要なaccess.logとcache.logなどのログファイルも 確認しなさい。
cd squid-1.1.x
patch < /tmp/fixes.patch
とすれば良いだけです。しかし時々、'src'ディレクトリから生成される
パッチファイルがあります。その様な時は、
cd squid-1.1.x/src
patch < /tmp/fixes.patch
とします。
もし、あなたが使っているpatchプログラムが、エラーを起こしたり、 きちんと動かなかった場合は、例えば、GNU FTP siteにある、より新しいバージョンを手に入れて下さい。 （【訳者注】 日本国内では、 ftp://ftp.cs.titech.ac.jp/GNU/が良い。）
例えば、次のchildcache.example.comというホスト上の squid.confファイルでは、1つのparentキャッシュと、2つの siblingキャッシュからデータを獲得するようにそのキャッシュを設定します。
# squid.conf - On the host: childcache.example.com
#
# Format is: hostname type http_port udp_port
#
cache_host parentcache.example.com parent 3128 3130
cache_host childcache2.example.com sibling 3128 3130
cache_host childcache3.example.com sibling 3128 3130
cache_host_domain指定では、特定のドメインに関して、特定の
キャッシュをsiblingにするか、parentにするかを指定できます。
# squid.conf - On the host: sv.cache.nlanr.net
#
# Format is: hostname type http_port udp_port
#
cache_host electraglide.geog.unsw.edu.au parent 3128 3130
cache_host cache1.nzgate.net.nz parent 3128 3130
cache_host pb.cache.nlanr.net parent 3128 3130
cache_host it.cache.nlanr.net parent 3128 3130
cache_host sd.cache.nlanr.net parent 3128 3130
cache_host uc.cache.nlanr.net sibling 3128 3130
cache_host bo.cache.nlanr.net sibling 3128 3130
cache_host_domain electraglide.geog.unsw.edu.au .au
cache_host_domain cache1.nzgate.net.nz .au .aq .fj .nz
cache_host_domain pb.cache.nlanr.net .uk .de .fr .no .se .it
cache_host_domain it.cache.nlanr.net .uk .de .fr .no .se .it
cache_host_domain sd.cache.nlanr.net .mx .za .mu .zm
上記の設定では、uk, de, fr, no, se, itドメインについて、
pb.cache.nlanr.netとit.cache.nlanr.netが、
mx, za, mu, zmドメインについて、sd.cache.nlanr.netが、
au, aq, fj, nzドメインについて、cache1.nzgate.net.nzが
キャッシュとして利用されるようになっています。
【訳者注】
日本のサイトが、無闇にNLANRのキャッシュ階層に直接加わることは、決して得策では ありません。ネットワーク的な距離を考えてキャッシュ階層を 設定しましょう。ISPをまたがった相手を指定することは、無駄な通信を 増やすだけという意見もあります。
(Ref. <news:AKI.97Jan9170259@nocs3.noc.titech.ac.jp>)
cache_announce 24 announce_to sd.cache.nlanr.net:3131注意:あなたのキャッシュをアナウンスすることは、 NLANRのキャッシュの階層構造に加わるのと、同じではありません。 登録をしないでNLANRのキャッシュの階層構造に加わることが出来ますし、 階層構造に加わらないで登録を行なうことも出来ます。
【訳者注】
日本のサイトは、ネットワークトポロジーを考えた上で、 日本のパブリックなSquidのリストを参照すると良いでしょう。 しかし、自分の組織が属するISP(プロバイダ)よりも 先に位置する相手を キャッシュ階層で指定するのはよく考えてからにしましょう。 みんながこれをやり始めるとデータの再利用によって回線の効率化をねらう はずのSquidが、無駄な問い合わせを増やし、余計に回線を圧迫する という結果になります。 ISPをまたがった階層を作るよりも ISPにSquidサーバを用意して もらいそれがISP間の階層を作るようにお願いするほうが得策です。
アクセラレータと代理キャッシュの理解に関して、問題を抱えている人が 時々います。その多くは、“入ってきた”のと“出ていく”データの解釈を 混同していることが原因です。私は、要求の観点から考えます。つまり出ていく 要求とは、ローカルなサイトから、広大なインターネットに対する要求です。 もちろん、応答として受けとるデータが、入ってくるデータです。 他の人の中には、“入ってきたデータとは、要求である”という 私の考えと逆の考え方をする人もいる。
アクセラレータは、出ていくデータに関する、入ってくる要求を蓄えます。 つまり、あなたが世界に向けて公表するようなものです。それは、 あなたのHTTPサーバと、内部のネットワークの負荷を取り除きます。 80番ポートもしくは、あなたが公表しているポートからサーバを移動して、 アクセラレータに置き換えます。そうすることで、アクセラレータは、 本当のHTTPサーバからHTTPデータを取ってきます。（アクセラレータのみが 本当のサーバがどこにあるかを知っていれば良いのです。）外の世界からは、 全く違いは見えません。（ただ、運の良いことに、スピードは、速くなります。）
サイトのwebサーバの負荷を取り除くこととは全く別のこととして、 アクセラレータは、外部に対する防火壁や、その他のネットワークに対する ボトルネックの役割もします。さらに、ボトルネックを越えるトラフックの減少や、 設定の単純化のために、内部のHTTPサーバと話すようにすることも出来ます。 ICPで互いに通信する2台かそれ以上のアクセラレータは、スピードや、サーバの1つが 落ちても大丈夫なように、webサービスの弾力性を増すことが出来ます。
Squidのredirectorは、1台のアクセラレータを、複数のサーバの単一の フロントエンドのように見せることが出来ます。あなたのファイルシステムの いくつかをあるサーバから、別のサーバに移動する必要があるか、または、 わかれて管理されているHTTPサーバを、論理的に単一のURL階層構造に 見せたい時には、アクセラレータで適切に対応できます。
もしあなたが、自分のところのローカルなユーザの検索の効率を向上させる ために、“世界の残りの部分”を蓄積したいだけなら、アクセラレータモードは、 不適切なものです。URLの階層構造を所有し、公表しているサイトは、 他のサイトからのアクセスを向上するために、アクセラレータを使用します。 ローカルなユーザの、他のサイトのURLへのアクセスを向上したいサイトは、 代理キャッシュをします。私達と同じように、多くのサイトは、その両方を望み、 両方を動かしているます。
SquidキャッシュとそのライバルであるHarvestキャッシュの測定値は、 CERNやその他広く用いられているキャッシュソフトより、能力が数十倍も 向上されていることを示しています。キャッシュにヒットした時の能力が 数十倍向上しているということは、キャッシュを、80番のポートで動かして、 サイトの主たるhttpdサーバとして振舞うように設定し、ミスした時は、 81番のポートで動いているサイトの本当のhttpdサーバに照会することで、 このキャッシュが、httpdのアクセラレータとして情報を提供出来ることを 示しています。
こうした設定のもとでは、webの管理者は、全ての蓄積されないURLを、81番の httpdのポートに変更する。HTMLのページや、GIFのような、蓄積可能な オブジェクトは、キャッシュサーバが参照して、問合せやcgi-binプログラムのような 蓄積されないオブジェクトは、81番ポートの本当のhttpdが参照します。 もし、あるサイトの利用の特徴に、蓄積可能なオブジェクトが多いという傾向が あるなら、この設定はそのサイトのwebの仕事量を劇的に減少することが出来ます。
httpdアクセラレータと、代理キャッシュサーバの2つのモードでは異なった 動作の傾向があるので、両方を、単一のsquidプロセスで実現しない 方が良いことに注意しなさい。 2つの別の機械で、別のキャッシュとして実行した方がより良い特性が 得られます。しかし、管理者が、CERNのように代理機能とWebサーバの 両方の機能をもつような他のサーバになれているなら、その統一性のために、 squid.confの設定ファイルの中で、httpd_accel_with_proxy の値をonにすることで、Squidは、代理機能とアクセラレータ機能の 両方をサポートします。
squid.confのinside_firewallの項目で、 あなたのインターネット・ファイアーウォールの内部のドメインのリストを 指定することが出来ます。例えば、
inside_firewall example.com
複数のドメインを指定することも出来ます:
inside_firewall example.com example.org example.net
inside_firewallの使用は、サーバ選択のアルゴリズムに 2種類の影響を与えます。そのドメインのリストに該当しないオブジェクトは、 防火壁を越えるとみなされるでしょう。そうしたことから、
gethostbyname(3))が、ブロッキングされる（つまり、
それを呼び出すプロセスは、応答の待たなければならない）ために、
dnsserverプロセスは、squidに利用されます。
squidプロセスは一つしかないので、キャッシュを利用する人は皆、
ルーチンが呼び出されるそれぞれの時間を待たなければならない。
dnsserverのプロセスが複数ある理由は、それぞれのプロセスを
ブロックでき、squid本体がブロックされないようにするためです。
あなたが必要とする、全てのアクセスを処理するのに、十分なだけの dnsserverプロセスが存在することは、とても重要です。そうでなければ、 squidは時々停止してしまうでしょう。 squidがあなたのシステムで、これまでに必要とした dnsserverの最大値を確認して、安全のために、その値に2つ加える というのは、なかなか良い経験則です。 言い替えるならば、これまでに、最大で3つのdnsserverプロセスしか 使用されていなくても、少なくとも5つのプロセスを立ち上げるべきです。 dnsserverは小さく、利用されない時は、スワップアウトされている であろうということは、覚えておきなさい。
OptionsメニューからNetwork Preferencesを 選びます。Proxiesのページで、Manual Proxy Configurationボタンをクリックし、そして、View ボタンをクリックしなさい。あなたのSquidサーバがサポートしているプロトコル （初期設定では、HTTPとFTP, gopher）毎に、Squidサーバのホスト名かIPアドレスを 入力し、Portの項に、SquidサーバのHTTPポート番号 （初期設定では、3128）を入力します。あなたのSquidがサポートしていない プロトコルのところは、空欄のままにしておきます。
ここに、Netscape Navigatorの代理機能についての手動設定の画面の スクリーン・ショット があります。
ここに、Netscape Navigatorの代理機能についての自動設定の画面の スクリーン・ショット があります。 さらに、 http://home.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html から、Navigatorの代理機能を自動設定するためのJavaScriptに関する、 Netscapeの文章を調べることが出来ます。
以下に、Oskar Pearsonによる、自動設定のためのJavaScriptの例を載せておきます。
//We (www.is.co.za) run a central cache for our customers that they
//access through a firewall - thus if they want to connect to their intranet
//system (or anything in their domain at all) they have to connect
//directly - hence all the "fiddling" to see if they are trying to connect
//to their local domain.
//Replace each occurrence of company.com with your domain name
//and if you have some kind of intranet system, make sure
//that you put it's name in place of "internal" below.
//We also assume that your cache is called "cache.company.com", and
//that it runs on port 8080. Change it down at the bottom.
//(C) Oskar Pearson and the Internet Solution (http://www.is.co.za)
function FindProxyForURL(url, host)
{
//If they have only specified a hostname, go directly.
if (isPlainHostName(host))
return "DIRECT";
//These connect directly if the machine they are trying to
//connect to starts with "intranet" - ie http://intranet
//Connect directly if it is intranet.*
//If you have another machine that you want them to
//access directly, replace "internal*" with that
//machine's name
if (shExpMatch( host, "intranet*")||
shExpMatch(host, "internal*"))
return "DIRECT";
//Connect directly to our domains (NB for Important News)
if (dnsDomainIs( host,"company.com")||
//If you have another domain that you wish to connect to
//directly, put it in here
dnsDomainIs(host,"sistercompany.com"))
return "DIRECT";
//So the error message "no such host" will appear through the
//normal Netscape box - less support queries :)
if (!isResolvable(host))
return "DIRECT";
//We only cache http, ftp and gopher
if (url.substring(0, 5) == "http:" ||
url.substring(0, 4) == "ftp:"||
url.substring(0, 7) == "gopher:")
//Change the ":8080" to the port that your cache
//runs on, and "cache.company.com" to the machine that
//you run the cache on
return "PROXY cache.company.com:8080; DIRECT";
//We don't cache WAIS
if (url.substring(0, 5) == "wais:")
return "DIRECT";
else
return "DIRECT";
}
MosaicやLynxについては、それらのアプリケーションを開始する前に、 環境変数を設定しておくことで、代理機能が設定されます。cshやtcshを使っていると すると、次の例のようにします。
% setenv http_proxy http://mycache.example.com:3128/
% setenv gopher_proxy http://mycache.example.com:3128/
% setenv ftp_proxy http://mycache.example.com:3128/
Lynxでは、lynx.cfgファイルを編集して、代理機能を使用する設定を 行なうことも出来ます。この方法は、それぞれのユーザ毎に環境変数を 変更して廻ることなく、全てのLynxユーザに代理サーバにアクセスさせることが 出来るという利点もあります。例は、次の通りです、
http_proxy:http://mycache.example.com:3128/
ftp_proxy:http://mycache.example.com:3128/
gopher_proxy:http://mycache.example.com:3128/
表示のメニューからオプションを選びます。 接続のタブをクリックします。プロキシ サーバ 経由で接続するをチェックして、設定のボタンを 押します。あなたのSquidサーバがサポートしているプロトコル （初期設定では、HTTPとFTP, gopher）毎に、Squidサーバのホスト名かIPアドレスを 入力し、ポートの項に、SquidサーバのHTTPポート番号 （初期設定では、3128）を入力します。あなたのSquidがサポートしていない プロトコルのところは、空欄のままにしておきます。
ここに、Internet Explorerで代理機能を設定する画面の スクリーン・ショットがあります。
マイクロソフトも、代理機能を自動的に設定する、Netscapeと同じような JavaScriptをサポートすることを始めました。現在のところ、Windows 3.1と Windows NT 3.51に対応した、MSIE version 3.0aだけが、この機能に対応している。 （つまり、Windows 95とNT 4.0に対応したversion 3.01 build 1225に関しては、 この機能は含まれていない。）
もしあなたが、この機能に対応したバージョンのMSIEを使用しているなら、 ViewメニューからOptionsを選びます。 次にAdvancedタブをチェックします。そして左下の隅にある、 Automatic Configurationボタンをクリックします。 表れたダイアログボックスに、JavaScriptファイルのURLを記入します。 そして変更を有効にするために、MSIEを終了して、再スタートします。 次からは、実行する度に、MSIEはJavaScriptファイルを読み込みます。
Netmanage WebSurferは、手動による代理機能の設定と、代理サーバ経由で 取ってこないホストやドメインについてのリストを設定する機能があります。 （この情報は、WebSurfer 5.0という現時点でのものです。） Settingsメニューから、Preferencesを 選択します。次に、Proxiesタブをクリックします。 そして、HTTPやFTP, gopherについてのUse Proxyを選択します。 それぞれのプロトコル毎に、Squidサーバのホスト名かIPアドレスを 入力し、ポートの項に、SquidサーバのHTTPポート番号 （初期設定では、3128）を入力します。あなたのSquidがサポートしていない プロトコルのところは、空欄のままにしておきます。
手順にわからないことがあれば、 スクリーン・ショット を見ると良いでしょう。
同じ設定のウィンドウに、代理サーバ経由で取ってきたくないホストや、 サーバを登録しておく、排除リストのダイアログボックスを開くボタンが あるはずです。この設定は自明でしょうが、取り敢えず スクリーン・ショット を載せておきます。
LinuxやSolarisでは、透過的なキャッシングという手法が使えます。 この仕組みは、オペレーティングシステムが、特定のIPパケットを、 アプリケーションに転送することで実現している。この文章では、今のところ、 Linuxにおける透過キャッシングの設定方法のみを述べています。
[Contributed by Rodney van den Oever <Rodney.van.den.Oever@tip.nl>]
警告： この方法には、いくつかの重大な欠点がある！
getsockname(2)システムコールで決定されるためです。
その結果、parentやsiblingの効用は、もはや正確には働かなくなります。
parentやsibling自体は、IPアドレスではなく、ホスト名でURLが記録されます。
「それらのURLは、どのキャッシュにHITしないので、異なっています。
These URLs are different so no cache HIT occurs.」
つまり、透過キャッシュを用いると、キャッシュの階層構造による
トラフィックの減少という利点が得られないことになります。
こうした副作用を我慢できるなら、先に進み、防火壁とリダイレクションを サポートするように、あなたのカーネルを再構築しましょう。 次に、/usr/src/linux/.configの中で、重要なパラメータを書いておきます。
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
#
# Networking options
#
CONFIG_FIREWALL=y
# CONFIG_NET_ALIAS is not set
CONFIG_INET=y
CONFIG_IP_FORWARD=y
# CONFIG_IP_MULTICAST is not set
CONFIG_IP_FIREWALL=y
# CONFIG_IP_FIREWALL_VERBOSE is not set
CONFIG_IP_MASQUERADE=y
CONFIG_IP_TRANSPARENT_PROXY=y
CONFIG_IP_ALWAYS_DEFRAG=y
# CONFIG_IP_ACCT is not set
CONFIG_IP_ROUTER=y
http://www.xos.nl/linux/ipfwadm/ へ行って、ipfwadmのソース配布を手に入れ、それをインストールします。 そして、リダイレクションの規則を設定して、ipfwadmを使用します。 私は、起動時にインターフェイスの設定を行なう/etc/rc.d/rc.inet1 (Slackware)から実行されるスクリプトに、この規則を付け加えました。 リダイレクションの設定は、その他の入力を受け付ける規則の設定より、 先に行なうべきです。通常は実行可能なフォワーディング(masquerading)が、 出来なくなっていることを、きちんと確認しなさい。
/etc/rc.d/rc.firewall:
#!/bin/sh
# rc.firewall Linux kernel firewalling rules
FW=/sbin/ipfwadm
# Flush rules, for testing purposes
for i in I O F # A # If we enabled accouting too
do
${FW} -$i -f
done
# Default policies:
${FW} -I -p rej # Incoming policy: reject (quick error)
${FW} -O -p acc # Output policy: accept
${FW} -F -p den # Forwarding policy: deny
# Input Rules:
# Loopback-interface (local access, eg, to local nameserver):
${FW} -I -a acc -S localhost/32 -D localhost/32
# Local Ethernet-interface:
# Redirect to Squid proxy server:
${FW} -I -a acc -P tcp -D default/0 80 -r 80
# Accept packets from local network:
${FW} -I -a acc -P all -S localnet/8 -D default/0 -W eth0
# Only required for other types of traffic (FTP, Telnet):
# Forward localnet with masquerading (udp and tcp, no icmp!):
${FW} -F -a m -P tcp -S localnet/8 -D default/0
${FW} -F -a m -P udp -S localnet/8 -D default/0
これで、ローカルなLANから、いかなる目的地へのトラフィックも、全てローカルの 80番ポートにリダイレクトされる。規則は、次の通りです。
IP firewall input rules, default policy: reject
type prot source destination ports
acc all 127.0.0.1 127.0.0.1 n/a
acc/r tcp 10.0.0.0/8 0.0.0.0/0 * -> 80 => 80
acc all 10.0.0.0/8 0.0.0.0/0 n/a
acc tcp 0.0.0.0/0 0.0.0.0/0 * -> *
次の項目は、squid.confの重要な設定です。
http_port 80
icp_port 3130
httpd_accel virtual 80
httpd_accel_with_proxy on
注意：virtualは、ここでのマジック・ワードです。
私は、Windows 95上でMicrosoft Internet Explorer 3.01と、プレリリース版の Netscape Communicatorの両方で、いくつかのテストを行ないました。その結果、 両方のブラウザとも、代理設定を行なわないでちゃんと動きました。
一度だけ、ローカルの80番ポートをブラウザで見ようとした時に、 squidがループに陥ったようです。しかし、次のように、 このアドレスをクライアントにとっての、排除規則に加えることで、 この問題を回避できます。
${FW} -I -a rej -P tcp -S localnet/8 -D dec/32 80
IP firewall input rules, default policy: reject
type prot source destination ports
acc all 127.0.0.1 127.0.0.1 n/a
rej tcp 10.0.0.0/8 10.0.0.1 * -> 80
acc/r tcp 10.0.0.0/8 0.0.0.0/0 * -> 80 => 80
acc all 10.0.0.0/8 0.0.0.0/0 n/a
acc tcp 0.0.0.0/0 0.0.0.0/0 * -> *
名称解決に関する注意： URLを代理サーバに渡す代わりに、ブラウザ自身がURLの名称解決をしなければ なりません。ワークステーションが、ローカルなネームサーバに問い合わせて、 外に出ていくトラフィックが最小になるよう設定されていることを確認しましょう。
防火壁か代理サーバ上で既に ネームサーバが動いているなら、ワークステーションがそのネームサーバを 使うようにしましょう。
access.log, 共通フォーマット(common format):
Host Ident - [D/M/Yr:H:M:S TZ] "Method URL" Status Size
access.log, Squid 1.0独自フォーマット(native format):
Time Elapsed Host Status/HTTP/Hier_Status Size Method URL
access.log, Squid 1.1独自フォーマット(native format):
Time Elapsed Host Status/HTTP Size Method URL Ident Hier_Status/Hier_Host
hierarchy.log, Squid 1.0のみ:
[D/M/Yr:H:M:S TZ] URL Hier_Status Hier_Host
それぞれのログのフォーマットの要素の定義は次の通りです。
【訳者注】
ログの各項目の意味や、その値の持つ意味などは、Squidの配布ファイルに 含まれているリリースノートに詳しく書いてあります。 Ver. 1.0と Ver. 1.1の 「胡散臭い」日本語訳があります。
kill -USR1 `cat /usr/local/squid/logs/squid.pid`
注意：squid.confの
logfile_rotate行で、必要のないログファイルを消去する
設定を行ないます。logfile_rotateに、保存しておきたい古い
ログファイルの個数を設定します。logfile_rotateの値に達する
たびに、もっと古いログファイルが自動的に消去されます。残しておきたい
古いログファイルの個数を、logfile_rotateに設定しておいて、
crontabで、squidにSIGUSR1を送るようにしておくのが
簡単な方法です。次のcrontabの設定で、毎日、真夜中にログファイルを
更新するようになります。
0 0 * * * /bin/kill -USR1 `cat /usr/local/squid/logs/squid.pid`
絶対に消去してはいけない唯一のログファイルは、 通常cache_dirに最初に書いてあるディレクトリにある logという名前のファイルです。このファイルは、squidが スタートした時に、キャッシュを再構築するのに必要な、メタデータが含まれて います。このファイルを削除することは、あなたのキャッシュを 消してしまうことと同じです。
sort -r -n +4 -5 access.log | awk '{print $5, $7}' | head -25
【訳者注】
もちろんこれは、native formatのときのみ有効な手法です。
コマンドラインで-zをつけて起動するという方法があります。
別の方法ですが、こちらが簡単かもしれません。 cache_dirディレクトリの最初のlogファイルを消去するだけです。
【訳者注】
6章は 少し古い cache manager をもとにした記述となっているようです。 最新の cache manager をお使いの方は、適宜読み替えてご利用ください。
[作者注: 皆さんからの、他のサーバ(例えば Netscapeなど)における cachemgr.cgi の設定方法に関する投稿をお待ちしています。おそれずにどん どん投稿して下さい。]
サーバの設定ファイルを編集した後は、おそらくWWWサーバを再起動するか、
もしくは設定ファイルを再度読み込ませるために SIGHUP を送
る必要があるでしょう。
サーバの設定が終わりましたら、WWWブラウザを使って例えば次に示すような URLにアクセスすることで、cache manager にアクセスすることができるで しょう。
http://www.example.com/Squid/cgi-bin/cachemgr.cgi
Protection MGR-PROT {
Mask @(workstation.example.com)
}
ここでは ワイルドカード(*)やIP addresses が使用できます。また複
数のサーバを設定するには、コンマ(,)で区切られたIP addressesのリストを
与えます。ここに挙げた他にも、まだ多くの安全策のための方法があります。ご
自分のサーバの説明書には、それらに関する記述があるはずです。
以下の設定も加える必要があります:
Protect /Squid/* MGR-PROT
Exec /Squid/cgi-bin/*.cgi /usr/local/squid/bin/*.cgi
この設定例はMGR-PROTにあるスクリプトを実行可能にします。
ScriptAlias /Squid/cgi-bin/ /usr/local/squid/cgi-bin/Squidの実行ファイルが全て入った /usr/local/squid/bin のような ディレクトリを、そのまま全て ScriptAliasに指定するのは良 くない方法と考えられます。
次に、特定のワークステーションだけが cache manager にアクセス できるよう安全策をとる必要があります。この設定は squid.conf ではなく、Apache の access.conf で行います。 access.confの最終行に、次のような記述を加えて下さい。
<Location /Squid/cgi-bin/cachemgr.cgi>
order deny,allow
deny from all
allow from workstation.example.com
</Location>
上の例では１行しか設定していませんが、複数行設定することももちろん可能
です。またそれらはドメイン名やネットワークで設定可能です。
もしくは上記方法の代わりに、パスワードでcachemgr.cgiへのアク セスを制限することができます。次のような記述を access.confへ 加えて下さい。
<Location /Squid/cgi-bin/cachemgr.cgi>
AuthUserFile /path/to/password/file
AuthGroupFile /dev/null
AuthName User/Password Required
AuthType Basic
<Limit GET>
require user cachemanager
</Location>
上の例における"user"に対するパスワードの作成には htpasswd を
用います。
htpasswd の使用方法は Apache のドキュメントを参照して下さい。
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl all src 0.0.0.0/0.0.0.0
上記のACLを用い、次のようにアクセス制限を行います。
http_access deny manager !localhost
http_access allow all
上の例における最初のACLはもっとも重要な設定です。 cache manager プログ ラムはcache_objectという特殊なプロトコルを用いて、squidに 対し質問を行います。 ご自分で次のようにして、cache_objectプロトコルを試してみ て下さい:
telnet mycache.example.com 3128
GET cache_object://mycache.example.com/info HTTP/1.0
デフォルトのACLでは、cache_objectによる要求があり、かつその要求 がlocalhostからではない場合、アクセスを拒否します。その他の場合は、アク セスを許可します。
localhostからのアクセスのみを許可するということは、 cachemgr.cgi の入力フォームの最初のページで、情報を見ることの できる "cache host"を localhost のみに制限することを意 味します。 私達は以下のような設定を推奨します:
acl manager proto cache_object
acl localhost src 127.0.0.1/255.255.255.255
acl example src 123.123.123.123/255.255.255.255
acl all src 0.0.0.0/0.0.0.0
123.123.123.123はあなたのWWWサーバのIP address です。
上記のACLを使って、アクセス制限を次のように変更します:
http_access deny manager !localhost !example
http_access allow all
デフォルトのACLは、WWWサーバとsquidが同じ計算機上にあると仮定してい ます。cache manager プログラムから squid へのアクセスは WWWサーバから 発生するものであって、ブラウザからは発生しないことに注意して下さい。 ですから、もしcachemgr.cgiがインストールしてあるWWWサーバが、 どこか別の計算機上にあった場合は、その計算機の IP address が、上記の ACLの例にあることを確認して下さい。
squid.confファイルを変更したあとは、squid に
SIGHUPシグナル を送ることを忘れないで下さい。
HOST_OPT = # -DCACHEMGR_HOSTNAME="getfullhostname()"
cachemgr.cgiが動いているWWWサーバが Squid が動いているサーバ
と同じ場合は、#を取り除くだけで可能です。もしWWWサーバが
どこか別の計算機にある場合は、次のように設定して下さい:
HOST_OPT = -DCACHEMGR_HOSTNAME=\"mycache.example.com\"
上記の変更を加えた場合は、cachemgr.cgi を再コンパイル・再インストール
しないと変化が現れません。
これらの示す情報は、基本的に cache ディレクトリ中の "log"ファイルに似ています。
もしsquidがその領域の示す値よりもとても小さかったならば、大急 ぎで修復にかかって下さい！なにかがとても悪くなっています。おそらく squidを再起動すべきでしょう。
【訳者注】
最新版のcache managerでは、Other項はなくなっています。
read(2) call毎にネットワークから得たバイト数
の度数分布です。上限バッファサイズを推定するのに少しは役立つでしょう。
Flagsの項のアルファベットの意味は以下の通りです:
Nの項は、DNS正引きによって得られたIPアドレスの数を示して います。
残りの項は、そのホストに対してDNS正引きによって得られた全てのIPアドレ スのリストです。
【訳者注】
最新版の cache manager の出力とは若干異なります。
Memory usage for squid via mallinfo():
Total space in arena: 94687 KB
Ordinary blocks: 32019 KB 210034 blks
Small blocks: 44364 KB 569500 blks
Holding blocks: 0 KB 5695 blks
Free Small blocks: 6650 KB
Free Ordinary blocks: 11652 KB
Total in use: 76384 KB 81%
Total free: 18302 KB 19%
Meta Data:
StoreEntry 246043 x 64 bytes = 15377 KB
IPCacheEntry 971 x 88 bytes = 83 KB
Hash link 2 x 24 bytes = 0 KB
URL strings = 11422 KB
Pool MemObject structures 514 x 144 bytes = 72 KB ( 70 free)
Pool for Request structur 516 x 4380 bytes = 2207 KB ( 2121 free)
Pool for in-memory object 6200 x 4096 bytes = 24800 KB ( 22888 free)
Pool for disk I/O 242 x 8192 bytes = 1936 KB ( 1888 free)
Miscellaneous = 2600 KB
total Accounted = 58499 KB
まずはじめに、mallinfo()が、ホスト"arena"ではsquidによっ
てメモリ領域の94Mが使用されている、と報告しているのに注目して下さい。こ
の値はtopが示す値にとても近いです。
その94Mの内、81% (76M)がこの瞬間、実際に使用されています。残りは解放さ
れているか、もしくはmalloc(3)によって予約され
(pre-allocated)まだ使われていません。
その使われている76Mの内、58.5M (76%)を使用することができます。使用でき
ない領域に対しては、malloc(3)によって call が行われていま
す。
Meta Data(【訳者注】最新版では Accounted Memory Usageです)は使用したメモリがどこで利用されたかに関する分析 を示しています。45%はStoreEntryと URL stringsに使用されま した。その他の42%は、オブジェクトを取って来てユーザに渡すまでVMに保持 しておくためのバッファに使用されました(メモリに保管されるオブジェ クトのための領域のことです)。
領域のサイズはsquid.confのパラメータで設定できます。
バージョン1.0では、それらの領域は幾分こわれていました: メモリブロック
を解放する代わりに、使用していないメモリページのスタックを保持していた
からです。メモリに保管されるオブジェクトのための領域にお
いて、使用されていないスタックのサイズはcache_memの1/2で
した。disk I/Oのための領域は プログラム中で 200 と指定さ
れていました。MemObjectとRequestは、
FD_SETSIZEの1/8の値でした。
squid プロセスのサイズを小さくする必要がある場合は、設定ファイル中で 'http', 'ftp', 'gopher'の上限オブジェクトサイズを小さくすることを勧め ます。cache_memもあなたの要求にあった適切な大きさに小さく したいことでしょう。しかし cache_memを小さくしすぎると、 高負荷時にはいくつかのオブジェクトに対して収得やキャッシュが行われない でしょう。より新しいバージョンのSquidでは、空きメモリ領域をなくすため に memory_pools off と設定することが可能です。
IPCacheはホスト名からIPアドレス(数字)への対応データを持っています。
FQDNCacheはその逆です。
【訳者注】
IPCacheはDNS正引きのデータを持ち、FQDNCacheはDNS逆引きのデータを持つということです。
例:
==============================================================================
IP Cache Contents:
Hostname Flags lstref TTL N [IP-Number]
gorn.cc.fh-lippe.de C 0 21581 1 193.16.112.73
lagrange.uni-paderborn.de C 6 21594 1 131.234.128.245
www.altavista.digital.com C 10 21299 4 204.123.2.75 204.74.103.37 204.123.2.66 204.123.2.69
2/ftp.symantec.com DL 1583 -772855 0
Flags: C --> Cached
D --> Dispatched
N --> Negative Cached
L --> Locked
lstref: Time since last use
TTL: Time-To-Live until information expires
N: Count of addresses
==============================================================================
FQDN Cache Contents:
IP-Number Flags TTL(?) N Hostname]
130.149.17.15 C -45570 1 andele.cs.tu-berlin.de
194.77.122.18 C -58133 1 komet.teuto.de
206.155.117.51 N -73747 0
Flags: C --> Cached
D --> Dispatched
N --> Negative Cached
L --> Locked
TTL: Time-To-Live until information expires
N: Count of names
http_accel_with_proxy on
そうでなければ、ALCの設定ミスでしょう。 access.logやsquid.confが手掛りになるので調べてみてください。
Squidがローカル・サーバのオブジェクトもキャッシュしています。
local_domain命令は、ローカルのオブジェクトをキャッシュさせないための命令ではありません。 ローカルのオブジェクトを取るときにsibling cacheに問い合わせをさせないための命令です。 もし、キャッシュをさせたくなければ、cache_stoplistかhttp_stop命令(バージョンによります)を使用してください。
Linuxの場合はここを参照してください。 linux-tweak.html
Solarisの場合、/etc/systemに以下の内容を追加して、1プロセスあたりのファイル記述子の最大数を増やしてください。
set rlim_fd_max = 4096
set rlim_fd_cur = 1024
また、include/config.hの#define SQUID_FD_SETSIZEをrlim_fd_maxで指定した値まで自由に設定ができます。
4096を越えると、カーネルがおかしくなるかもしれません。
Solarisのselect(2)は1024ファイル記述子しか扱うことができません。
もしもっと必要ならば、src/Makefileを編集して、$(USE_POLL_OPT)を有効し、squidを再コンパイルしてください。
FreeBSDの場合(Torsten Sturm <torsten.sturm@axis.de>氏による)
多くのBSDからの流れを持つシステム(SunOS, 4.4BSD, OpenBSD, FreeBSD, NetBSD, BSD/OS, 386BSD, Ultrix)では、"brute force"法を使ってカーネル内のこの値を増やすことができます(カーネルの再構築が必要です)。
param.cファイルを探し、maxusersとオープンできるファイル数の最大値との関係を調べて変更することです。
/usr/kvm/sys/conf.common/param.cの次の式に従って変更してください。int nfile = 16 * (NPROC + 16 + MAXUSERS) / 10 + 64;NPROCは以下のように定義されています。#define NPROC (10 + 16 * MAXUSERS)
/usr/src/sys/conf/param.cの
maxusersとmaxfiles、maxfilesperprocを以下の式に従って変更してください。int maxfiles = NPROC*2;int maxfilesperproc = NPROC*2;NPROCは以下のように定義されています。#define NPROC (20 + 16 * MAXUSERS)options OPEN_MAX=128
/usr/src/sys/conf/param.cを編集して、maxfilesを次の式で計算して調整します。int maxfiles = 3 * (NPROC + MAXUSERS) + 80;NPROCは次の行で定義されています。#define NPROC (20 + 16 * MAXUSERS)OPEN_MAXを設定する必要があります。
configureスクリプトは使用できるファイル記述子の数を調べて記録しているため、気をつけてconfigureスクリプトの再実行をする必要があります。
例えば、
cd squid-1.1.x
make realclean
./configure --prefix=/usr/local/squid
make
のようにします。
malloc(3)がメモリを確保できなかったと文句をいっているのをみつけました。でも、私のシステムはたくさんのRAMを積んでいるんです！options DFLDSIZ=67108864 # 64 meg default max data size (was 16) options MAXDSIZ=134217728 # 128 meg max data size (was 64)この方法は、カーネルの再構築と再起動が必要です。
Digital UNIXでデータ・サイズを増加させるには、/etc/sysconfigtabを編集して、以下の行を加えてください。
proc:
per-proc-data-size=1073741824
または、cshを使用して、limitコマンドを以下のように使ってください。
/etc/sysconfigtabを編集した場合は再起動が必要ですが、limitコマンドの場合はその必要はありません。
97/01/23 22:31:10| Removed 1 of 9 objects from bucket 3913 97/01/23 22:33:10| Removed 1 of 5 objects from bucket 4315 97/01/23 22:35:40| Removed 1 of 14 objects from bucket 6391この記録は正常です。Squidがcache_swap_highに到達したことを表示できていません。
cachemgr.cgiによるキャッシュ情報ページの、次のような行を調べてください。
Storage LRU Expiration Age: 364.01 days
この時間使用されなかったオブジェクトは、定期的なメンテナンス作業中に削除されます。
configファイルのreference_ageによって、LRU Expiration Ageを設定することができます。
FATAL: Don't run Squid as root, set 'cache_effective_user'!というメッセージを出した、という報告をもらっています。 しかし、cache_effective_userにnobody以外のどんな値を設定してもうまくいくことがわかっています。 解決方法の1つは、Squidのためのユーザ・アカウントを作成して、それをcache_effective_userに設定することです。
ほかの方法としては、nobodyアカウントのUIDを65535から65534に変更することで解決できます。
【訳者注】
Squid-1.1.6の配布物中に含まれている、 ICPドラフトの日本語訳もあります。
ICPv2は RFC2186 、その応用については RFC2187になりました。 RFC2186の日本語訳も作りました。
ICPは第1に、キャッシュ階層で目的のオブジェクトがsiblingキャッシュのどこにあるのかを示すものです。 もし、squidキャッシュが要求されたドキュメントを持っていなければ、squidはICP要求をsiblingに送ります。 そして、siblingは“HIT”または“MISS”というICP応答を返します。 キャッシュはその応答によって、どのsiblingキャッシュからオブジェクトを受け取ることができるか判断します。
ICPは1回のTCP接続でオブジェクトを複数転送することもできます。 ICPは現在UDPの上で実装されています。 Squidの現在のバージョンでは、マルチキャストを利用したIPCもサポートしています。
gethostbyname(3)関数は、DNS要求が完全に終了するまで停止してしまう関数ですので、このような仕組みが必要になります。
Squidは常にnon-blocking I/Oができなればならないため、DNS検索はメインのプロセスから切り離して実装される必要があります。 dnsserverはDNS検索をキャッシュしません。 DNS検索のキャッシュは、squidプロセス内で行なわれています。
squidを介したFTP putは動かないようです。 この機能が動くために修正中または作成中という話はありませんか？
今のところそのような話はありません。 ftpputプログラムが必要になると思います。
親子関係に加えて、Squidはsibling(兄弟姉妹)もサポートします。 これは、階層で同じレベルにあるキャッシュ同士で、キャッシュ・サーバの負荷を分散する機能を提供します。 階層でのそれぞれのキャッシュは、オブジェクトを本物がある場所から取ってくるか、parentやsiblingキャッシュから取ってくるかを、簡単な解決プロトコルによって各自で決めています。 キャッシュは、sibling関係にある別のキャッシュから問い合わせが来たときに、そのオブジェクトを持っていなくても、そのオブジェクトを取ってくることはしません。
アルゴリズムは、ファイアウォールを含めた構成の場合、やや複雑になります。
近くに1つのparentキャッシュしか存在しないときの場合、single_parent_bypass命令によってICP問い合わせを省略することができます。 (つまり、オブジェクトを取れるところが1つしかないのなら、わざわざ問い合わせすることもない、ということ)
現在のto-doリストは http://squid.nlanr.net/Squid/Devel/todo.html にあります。
開発に加わってみたい方は、まず http://squid.nlanr.net/Squid/Devel/ の情報をみてみましょう。
階層的キャッシングの利点(つまり、ネットワークの帯域幅の使用度の減少、アクセスの遅延、resiliencyの向上)は価格になってきます。 階層の上位のキャッシュは、自分の子孫のキャッシュミスのめんどうをみる必要があります。 もし、(階層構造の)葉のキャッシュのヒット率が50%としたら、すべての葉の半分の参照は、直接オブジェクトのソースを参照せずに、第2レベルのキャッシュを通して解決されます。 もし、この第2レベルのキャッシュがほとんどの文書を持っていれば、まだ常に良好です。 しかし、高いレベルのキャッシュがあまり文書を持っていなければ、負荷が限界を越え、アクセス頻度がむしろ増加するでしょう。