From: ikeda@osa.sci.jri.co.jp (Akisato IKEDA)
Real-Date: Wed, 6 Sep 95 21:15:12 +0900
Subject: [infotalk,05541] Access Control
Message-Id: <9509061215.AA19316@othp1.sci.jri.co.jp>
株式会社日本総合研究所 池田明聡 と申します。
お世話になります。
皆様にお知恵をお借りしてくてメール入れさせて頂きました。
「社内のインターネット利用の制御はどの様に行われていますか？」
インターネット回線は、まだまだ貴重ですが、一方で
社内からの Web 等へのアクセスニーズや、社外向けの
WWW サーバへのアクセス等、インターネットへのアクセスは
増える一方です。
お金があれば、NSP と太い回線を契約することもできるでしょうが、
何れその太い回線も一杯になってしまうでしょう。
そこで、何等かの方法でインターネットの利用の制限や
優先付など、制御しないと現実的なアクセスができない事態に
なってしまいます。（当社では、なりかけています。;;）
「何方か、良い方法やご経験はお持ちでないでしょうか？」
以下、私なりに検討してみた結果です。
尚、弊社は FireWall として、Gauntlet を某 NSP からお借りして
使っています。
（１）社内からのアクセスは、全て FireWall 経由で行って
いるので、FireWall のアプリケーションゲートウェイの
起動本数を制限する。
（NSP 殿から技術的には一部可能ではあるが、何が原因で
アクセスできないかユーザーが分らないため、運用
支障をきたすのでは、とお教え頂きました）
（２）DeleGate を使って FireWall を越えさせて、DeleGate の
機能で同時にサービスできる数を制限する。
（既に http のキャッシュとして使っていますので、有力な
方法かと考えています。マシンの都合でテストできていません）
（３）ルーターのサービスプロトコル毎の帯域制限機能を使う。
例えば http で細くて貴重な回線を食いつぶすことが避けれる
のでは。
（NSP 殿からお借りしているルーターではこの様な設定を行うことは、
サポート上困難とご連絡頂いており試せていません。
ルーターを買うしかないようですが、NSP 殿との接点ですので
運用を考えるとルーターはお借りしておいた方が良いとも
考えられ、踏ん切りがつきません）
以上です。
宜しくお願い申し上げます。
--------------------------------------------------------------------
（株）日本総合研究所 サイエンス事業部 エンジニアリンググループ
池田明聡
郵便番号550 大阪市西区新町 1-33-8 ISS ビル 4F
TEL:06-536-7631 FAX:06-532-9701 EXT:927-2471
Internet:ikeda@osa.sci.jri.co.jp NIFTY Serve:TCC02413
From: Tokio Kikuchi <tkikuchi@is.kochi-u.ac.jp>
Real-Date: Wed, 6 Sep 95 11:58:52 JST
Subject: [infotalk,05540] Re: httpd cache clean
Message-Id: <9509060258.AA02372@notos.is.kochi-u.ac.jp>
菊地＠高知大です。
だいぶ前の議論ですが、CERN httpd 3.0 について、
> > 現状で間違っていると思うのはCERNのProxyサーバ(with Cache)のキャッ
> > シングの方法で、(たとえ読み込み失敗でも)何でもかんでも溜めてしまう
> > のが悪いのでしょう。
>
> これも、そのとおりです。
>
>
> # CERN 3.0 の BUG List を斜読みしても、これはバグだと書いてない
> # ようなので、誰か教えてあげるとよいと思いますが。
>
というのがありました。ソースを見ると、（一見）転送でエラーが起こると
キャッシュしないようなコードになっていたので、news で聞いてみました。
開発者（らしい人）からの返事は「何、それ？」みたいでしたが、以下のよ
うなコメントも帰ってきたので、転送します。（disk full というわけでも
ないような気がするが）今から、コンパイルしなおして試してみます。
---------------------------------------------------
<a href="http://www.is.kochi-u.ac.jp/~tkikuchi/">
菊地時夫 tkikuchi@is.kochi-u.ac.jp
高知大学理学部情報科学科 Tel:0888-44-8336(direct)
780 高知市曙町2-5-1 Fax:0888-44-8361 </a>
---------------------------------------------------
Path: kochi-u!news.csi.ad.jp!wnoc-kyo-news!hakozaki.karrn!kyu-cs!hakata!newssinet!daffy!uwvax!uwm.edu!cs.utexas.edu!news.sprintlink.net!newsfeed.internetmci.com!news.mathworks.com!fu-berlin.de!news.belwue.de!News.Uni-Marburg.DE!news.th-darmstadt.de!c4.hrz.uni-giessen.de!irina!g087
From: g087@irina.hrz.uni-giessen.de (Thomas-Ingolf Seeling)
Newsgroups: comp.infosystems.www.servers.unix
Subject: Re: problem with CERN cache
Date: 5 Sep 1995 13:33:58 GMT
Organization: University of Giessen, Germany
Lines: 118
Distribution: world
Message-ID: <42hjk6$p3d@c4.hrz.uni-giessen.de>
References: <41rlca$dkj@postman.is.kochi-u.ac.jp>
NNTP-Posting-Host: irina.hrz.uni-giessen.de
X-Newsreader: TIN [version 1.2 PL2]
Tokio Kikuchi (tkikuchi@is.kochi-u.ac.jp) wrote:
> I have a problem that CERN httpd 3.0 sometimes has corrupted cache
> and don't reflesh it even if I `reload' it from a client (NCSA Mosaic etc)
This has got nothing to do with the type of client, it happens with all
of them.
The problem is that disk problems like "full" etc. are not noticed by
the server, and so there may be corrupted files in the cache, meaning
truncated. Since cache_info tells the server the file is there, it will
always be served from the cache, never updating/refreshing until it is
expired.
This problem has been discussed on the german mailing list www-de which
is available from informatik.tu-muenchen.de.
There have been two independent patches for this problem (one from me,
which is already incorporated in the new release of cern for OS/2. You
can get this one from http://www.uni-giessen.de/~g087/os2.html).
Here is my solution for this cache-problem:
Replace Daemon/Implementation/HTCache.c::cache_created with the
routine that follows and recompile with -DTHS_CACHE.
Perhaps you have to add the headerfiles
#include <sys/types.h>
#include <sys/stat.h>
PUBLIC void cache_created ARGS2(HTStream *, me,
time_t, cur_t)
{
#ifdef THS_CACHE
int thsnoerr=1;
#endif
if (!me || !me->url || !me->cfn) return;
/*
* Release lock
*/
{
#ifdef THS_CACHE
struct stat thsfile;
#endif
char * lockfile = (char*)malloc(strlen(me->cfn)+strlen(LOCK_SUFFIX)+1);
if (!lockfile) outofmem(__FILE__, "cache_created");
sprintf(lockfile, "%s%s", me->cfn, LOCK_SUFFIX);
#ifdef THS_CACHE
if (stat(lockfile,&thsfile)==0 &&
thsfile.st_size>=me->content_count) {
CTRACE(stderr,"Caching..... cache file could be stored\n");
rename(lockfile, me->cfn);
}
else {
CTRACE(stderr,"Killing..... cache file \"%s\"\n",me->cfn);
unlink(lockfile);
thsnoerr=0;
}
#endif
free(lockfile);
}
/*
* If we just did an IMS-GET remove the backup file -- it is
* really out of date.
*/
if (me->if_mod_since) {
char * backup = (char*)malloc(strlen(me->cfn) + strlen(TMP_SUFFIX) +1);
if (!backup) outofmem(__FILE__, "cache_created");
sprintf(backup, "%s%s", me->cfn, TMP_SUFFIX);
CTRACE(stderr, "Discarding.. backup version \"%s\"\n", backup);
unlink(backup);
free(backup);
}
/*
* Write entry to cache info file
*/
#ifdef THS_CACHE
if (thsnoerr) {
#endif
CTRACE(stderr, "Created..... cache file \"%s\"\n", me->cfn);
if (!HTCacheInfo_writeEntryFor(me->cfn,
cur_t - me->transfer_started,
cur_t,
me->expires,
get_unused(me->url),
me->last_modified)) {
HTLog_error2("Can't write cache info entry for",me->cfn);
}
#ifdef THS_CACHE
}
else
CTRACE(stderr,"Caching..... no because file system full\n");
#endif
}
and this is a pointer to the archive of the aforementioned mailing-list:
http://www.leo.org/hypermail/www-de/
--
Tschau...Thomas
---------------------------------------------------------
Thomas Seeling +49-6034-2588 ths@texbox.lahn.de
142:102/1@SFNet 54:491/1@TeXNet 21:491/1018@GerNet
Die TeX-Box, V32B, V42B, 24h, (FRequest) +49-6034-1455
Die TeX-Box, X.75, V.110 ISDN (FRequest) +49-6034-930022
Rechenzentrum der Justus-Liebig-Universitaet Giessen, FRG
thomas.seeling@math.uni-giessen.de +49-641-702-2514
<a href=http://www.uni-giessen.de/~g087/>ThS Homepage</a>