Path: gama!etlcom!kusumoto From: kusumoto@etlcom.etl.JUNET (Hiroyuki Kusumoto) Newsgroups: fj.guide.admin Subject: 8.3 mail system administration: daily operation Message-ID: Date: 11 Feb 88 07:16:50 GMT Expires: 28 Feb 88 00:00:00 GMT Sender: kusumoto@etlcom.etl.junet Reply-To: kusumoto@etlcom.etl.junet Followup-To: fj.junet Distribution: fj Organization: Electrotechnical Laboratory, Tsukuba Science City Lines: 298 Approved: fjnews@junet Posted: Thu Feb 11 07:17:51 GMT 1988 <1> 日常の業務 [admin23] <1,1> チェックすべきこと すくなくとも、1日1度は自分の管理している計算機にログインして、自分の計算機の 状態や隣の計算機との接続の様子をチェックすることが必要です。 具体的には、次 のような事柄に注意を払って下さい。 <1,1,0> 接続のチェック uusnap などのコマンドを用いて、隣の計算機への接続が安定しているかどうかを確 認します。もし、異常に長い間接続が成立しないことがあったら、モデムがハングし ていないか、自分あるいは相手の計算機の環境に変化があったかどうか、相手の計算 機がダウンしていないかなどを調べます。 No Device や Login Failed が頻出するようならば、相手の計算機を呼ぶ時間など を見直したほうがよいでしょう。その際には、相手のポストマスターと相談しましょ う。 また、ときどき手で相手を呼んでみることも必要です。2400bpsで呼んでいると思っ ていたのに、なんらかの理由で 1200bps でのセッションが成立していたなどという ことがありますから。 最低でも月に一度は、/usr/spool/uucp/SYSLOG に残されたデータを用いて、他のサ イトとの接続関係をチェックします。そのために uurate (/usr/lib/uucp/UUAIDS/uu rate)という awk スクリプトがありますから、それを利用してください。 次のような点に注目します。 飛び抜けて転送量の多いサイトがあった場合 ループメールはないか 膨大な量のファイルを転送したユーザがいないか 同じニュースを何度も転送していないか ihave/sendme や history の設定の誤り モデムの実効速度が予想より低い場合 モデムの設定が間違っていないか 相手のモデムとの相性はどうか 転送エラーが頻発していないか（再送がおこっていないか） 　なお、1200bps 2400bps のモデムの実効速度は、あるサイトでは次のような値が経 験的に得られています（このマシンはきわめて負荷の大きなマシンです）。これより も低下することがあればどこかおかしい可能性がありますからチェックしましょう。 ---------------------------------- モデム 受信 発信 (bps) (byte/sec) (byte/sec) ---------------------------------- 1200 70- 90 100-120 2400 140-170 200-220 ---------------------------------- <1,1,0> メールにエラーは出ていないか postmaster にあてたエラーメールが来ていないかをチェックします。 宛先のタイプミスなど単純な間違いの場合 たいていは、無視します。しかし、それがしばしばあるようならば、送り手に注意を 促します メールがループしている場合／ドメインが存在しないという場合 未登録のドメインやホストがあるかもしれません たとえば、 JUNET Master - - - - のようなドメインの接続関係がある場合、D についての情報が A と C には登録され たのに、 B に登録されていないと、 JUNET Master から来る D あてのメールは A と B の間でループします。 自分のホストの sendmail.cf に間違いがあるかもしれません。desc.dat の記述を確 認しましょう。あるいは、隣のホストの sendmail.cf に間違いがあるかもしれませ ん root/daemon へのメールが異常に多い場合 誰かが間違ったメールアドレスを使っている可能性があります sendmail.cf を確認しましょう <1,1,0> ディスクに十分な余裕はあるか メールやニュースは、標準的には、/usr/spool というディレクトリの下の、mail, n ews というスプール領域に保存されます。また、 UUCP によって転送する／転送され たファイルは、 /usr/spool/uucp というディレクトリの下に一時的におかれます。 とりわけ、多量のニュースが送られてきているときなど、これらの領域が爆発的に増 えることがありますから、注意しましょう。 経験的には、ニュースを購読しているサイトで、ニュースの消去期間(expire)を2週 間にしている場合、余裕を見込んで30MB程度の /usr/spool/news が必要です。また 、そのニュースを隣のホストに転送している場合には、転送するための一時ファイル 領域として /usr/spool/uucp に十分なスペースがなくてはなりません。1つの転送相 手に対して1MB程度用意していれば大丈夫でしょう。もちろん、UUCP の接続が不安定 で長い期間それらのファイルを持っていなくてはならない場合には、もうすこし必要 になります。 【参考】 あるサイトの 1987年 10月現在のニュース関係のディスク使用量は以下の 通りです。参考にして下さい。なお、このサイトの expire 期間は、3週間です。（ 数値の単位は、KB） 実際の運用にあたっては、この 1.5 倍くらいの余裕を見込んでおかなくてはなりま せん。 1957 /usr/spool/news/control 1 /usr/spool/news/general 29 /usr/spool/news/junk 3006 /usr/spool/news/fj 17581 /usr/spool/news/comp （このうち /usr/spool/news/comp/sourcesは 3992 ） 673 /usr/spool/news/soc 1048 /usr/spool/news/news 147 /usr/spool/news/misc 1973 /usr/spool/news/sci 39 /usr/spool/news/talk 159 /usr/spool/news/rec 全体で、28689 KB（約 30MB、ただしローカルのニュースも含む）となります。 なお、サイトによっては、これ以外にそのサイトあるいはその地域だけのニュースグ ループがあります。 かりに、ある UUCP のセッションの途中でニュースやメールの領域がオーバーフロー してしまうと、その時転送中のニュースやメールは失われてしまいます。多くのシス テムでは、ニュースとメールは同じディスクシステムを共有していますから、ニュー スのせいでディスクがあふれれば、メールも同時に失われてしまいます。ニュースの 場合には回復する方法もありますが、メールの場合には不可能です。かりに、あるホ ストAの spool 領域がオーバーフローしてしまった場合、そのホストAにあてたメー ル（ニュース）だけでなく、ホストAを経由して他のホストにあてたメールまで失わ れてしまいますから、ディスクの容量の監視はきわめて重要です。 運悪くメールが失われてしまった場合の回復手段としては、 fj.news.config などの グループに「何月何日にディスクがあふれたので、その頃にメールを送られた方は再 度送って下さい」のように投稿して、送り手に再度のメール発送を頼むことしか手は ありません。重要なメールが失われてしまった可能性があると思われる場合には、そ のメールを転送してきた中継ホストの postmaster に依頼して、 /usr/spool/mqueue /syslog の中味から、自分のホストにあてた手紙の送り手／受取人を見つけ出すこと もできますが、その postmaster に迷惑をかけることになるので、そういうことをす るのは、よほどの緊急事態に限られます。 <1,1,0> JUNET の状況を知る 自分のホストの状況をチェックするだけではなく、 JUNET 全体がどのような状況に あるかを知ることが必要です。そのための情報源としては、次のようなニュースグル ープが参考になります。 【読むべきニュースグループ】 fj.general JUNETに関わる一般的な議論 fj.mail メールに関する議論 fj.news.newsite 新しい参加サイトについての情報 fj.news.config JUNET 参加サイトのダウン、ルート 変更などについての連絡 fj.news.sa システム管理者に役立つ情報 comp.mail.uucp UUCP によるメールリンクに関する情報 news.sysadmin USENET の管理者むけの情報 ときどき重要な情報がのる ・ニュースに関して fj.news.adm ニュース管理者にむけた情報 news.software.b ニュースのソフトウェアについての情報 （パッチなど）がながれる もしもあなたのホストがニュースを購読していない場合には、以上の情報を得ること はできません。その場合には、手近なニュースを購読しているホストのポストマスタ ーと緊密な連絡を取って情報を入手してください。また、あなたのドメインが JUNE T master に登録されていれば、postmasters@junet にあてたメールが届きます。重 要な情報は、このアドレスを用いて発信されるはずです。 <1,2> 他のサイトとの関係 <1,2,0> 新たなサイトの登録 ポストマスターの重要な仕事の中に、新しい計算機が JUNET に参加したときの処理 があります。この情報の登録がちゃんとなされないと、新しい計算機でメールを受け 取れなかったり、ループメールやゴミメールを出してしまいます。 他のドメインの場合 新たに、ある組織があなたのドメインを通じて JUNET に参加するときには、次のよ うな処理をします。 自分の隣に新しいドメインができた場合 JUNET master - * * * - emon - nobita - jaian たとえば、nobi というドメイン名の nobita というホストが、あなたのドメインの ホスト（ドメイン名 dora の emon）と接続したとします。その時、dora のポストマ スターであるあなたのすべきことは、次のようなことです。 新しい sendmail.cf を作成するための mailconf 用のデータベースである desc.da t を書き直す nobi あてのメッセージは、すべて nobita に送られるようにします。 新しいドメインが JUNET に参加したことのアナウンスを手伝う 次の項目は本来 nobi のポストマスターがすべきことですが、忘れていないかどうか をチェックしてあげてください。 dora から JUNET master までのすべての中継サイトに対して、sendmail.cf を更 新することを依頼する JUNET-admin@junet あてに、 JUNET 参加の依頼をメールで送る 自分の下流の方にドメインができた場合 たとえば、nobi というドメインのそのまた先に、gouda というドメインができたと します。そのときには、postmaster@gouda.junetあるいは、postmaster@nobi.junet から、sendmail.cf を変更するように依頼のメッセージが来ます。 それに基づいて、user@HOST.gouda.junet あてのメッセージはすべて nobita （nobi のドメインマスター）に転送するように sendmail.cf を変更します。 場合によっては、gouda の JUNET 接続についてのアナウンスはあなたには直接届か ずに、 fj.news.newsite の投稿によって気付くかもしれません（postmaster@gouda.junet があなたにメールを送るのを忘れたか、あなたがそのメールを見落としたのかもしれ ません）。その時には、確認の上、sendmail.cf を変更します。 自分のドメインの場合 自分のドメイン内部にホストが追加された場合には、基本的には、 desc.dat を修正 して新しい sendmail.cf を作成すればよいのです。必ずしも、junet-admin@junet や上流サイトに対する報告は必要ありませんが、ホスト名の重なりのチェック（8.2. 1 参照）をするためにも、情報を流すのはよい習慣です。 <1,2,0> システムダウンの連絡 あなたのホストが JUNET に参加している限りにおいて、あなたのホストが停止する というのはあなたのホストだけの問題ではありません。あなたのホストのユーザにあ ててメールを送ろうとしている人やあなたのホストを中継サイトとして利用する人の 両方に影響がおよびます。したがって、システムダウンや環境の変化など、 JUNET の接続に関係する自分のシステムの状態の変化があれば、あらかじめ情報を関係する ポストマスターや一般の人々に提供すべきでしょう。 連絡方法としては次の2つがあります 自分のドメインに接続されているドメインのポストマスターにメールで連絡する fj.news.config にニュースとして投稿する 連絡すべき事柄としては 1日以上のシステムの停止 （お正月、夏休みなどの停止も含む。保守のための2- 3時間の停止ならば連絡する必 要はない） OSのバージョンアップ 4.2BSD から 4.3BSD に変えた時など (UUCP 関係でも若干の変化がある可能性があ る) モデムなどの環境の変更 など、相手になんらかの形で影響する可能性があるものは、忘れずに連絡します。多 くの連絡は、関係するポストマスターまでに伝えればよいものですが、長期間にわた る停止、ホスト名の変更などは、一般ユーザにも関係してきますから、fj.news.conf ig に投稿すべきでしょう。