TCP/IP とデータ通信

パート III UUCP 通信の管理

UUCP ファイル転送システムを使用すると、UNIX ベースのシステム間でファイルと電子メールを送受信できます。パート III では、複雑な UUCP システムを管理する方法について説明します。

パート III の内容は、モデム管理と広域ネットワークに関する実践的な知識を持つ、熟練のネットワーク管理者を対象としています。また、ネットワーク管理者が、電話回線を介して UUCP を使用しようとしていること、コンピュータにハードウェアを追加する手順を熟知していること、すでにモデムをマシンに接続してあること、tip または cu を用いたダイヤルアウトができることを前提として説明を進めます。

第 12 章 UUCP のデータベースとプログラム

この章では、UUCP のプログラムとデーモンを紹介します。その後で、UUCP 構成の一環として、UUCP データベースファイルを構成する方法について詳しく説明します。データベースの作成後、UUCP をどのように構成するかについては、第 13 章「UUCP の構成と保守」で説明します。

UNIX-to-UNIX Copy Program (UUCP) は、コンピュータが相互にファイルの転送、メールの交換を実現します。また、UUCP を使って Usenet のような大規模ネットワークにコンピュータを接続することも可能です。

Solaris 環境には、HoneyDanBer UUCP とも呼ばれる基本ネットワークユーティリティ (BNU) バージョンの UUCP が備えられています。UUCP という用語はシステムを形成するすべてのファイルとユーティリティを意味するものであり、uucp プログラムはそのシステムの一部にすぎません。UUCP のユーティリティには、コンピュータ間でファイルをコピーするためのもの (uucpuuto) から、リモートログインやリモートコマンド実行のためのもの (cuuux) まで、さまざまなものがあります。

UUCP のハードウェア構成

UUCP は次のハードウェア構成をサポートしています。

この章では、UUCP ハードウェアをすでに設置、構成してあるものとして、説明を進めます。モデムを設定する必要がある場合は、『Solaris のシステム管理 (第 2 巻)』と、モデムに付属しているマニュアルを参照してください。

UUCP ソフトウェア

Solaris インストールプログラムを実行するときに全体ディストリビューションを選択していれば、UUCP ソフトウェアは自動的に組み込まれています。あるいは、pkgadd を使って UUCP を単独で追加することもできます。UUCP のプログラムは、デーモン、管理プログラム、ユーザープログラムの 3 種類に分類されます。

デーモン

UUCP システムのデーモンには、uucicouuxqtuuschedin.uucpd の 4 つがあります。これらのデーモンは、UUCP のファイル転送とコマンド実行を取り扱います。必要な場合は、これらのデーモンをシェルから手動で実行することもできます。

管理プログラム

ほとんどの UUCP 管理プログラムは、/usr/lib/uucp にあります。基本データベースファイルの多くは、/etc/uucp に入っています。ただし、uulog だけは例外で、これは /usr/bin にあります。uucp ログイン ID のホームディレクトリは /usr/lib/uucp です。su または login を用いて管理プログラムを実行するときには、uucp ユーザー ID を使用してください。このユーザー ID は、プログラムとスプールデータファイルを所有しています。

ユーザープログラム

UUCP のユーザープログラムは /usr/bin にあります。これらのプログラムを使用するのに、特別な権限は必要ありません。

UUCP データベースファイルの紹介

UUCP の構成の主要部分の 1 つに、UUCP データベースを形成するファイルの構成があります。これらのファイルは /etc/uucp ディレクトリにあります。マシン上で UUCP または PPP を設定するには、これらのファイルを編集する必要があります。UUCP データベースファイルには以下のものがあります。

サポートデータベースの一部とみなすことのできるファイルがほかにもいくつかありますが、これらは、リンクの確立とファイルの転送に直接には関係しません。

UUCP ファイルの構成設定

UUCP データベースは、「UUCP データベースファイルの紹介」に示したファイルから構成されます。ただし、基本的な UUCP 構成に関係する重要なファイルは次に示すものだけです。

PPP は UUCP データベースの一部を使用するので、PPP を構成する予定がある場合は、少なくともこれらのデータベースファイルだけは理解しておく必要があります。これらのデータベースを構成してしまえば、その後の UUCP の管理はきわめて簡単です。一般に、Systems ファイルを最初に編集し、次に Devices ファイルを編集します。/etc/uucp/Dialers ファイルは、普通はデフォルトのままで使用できますが、デフォルトファイルに含まれていないダイヤラを追加する予定がある場合は編集が必要になります。基本的な UUCP 構成と PPP 構成には、さらに次のファイルを加えることもできます。

これらのファイルは互いに関係しながら機能するので、1 つでも変更する場合は、全部のファイルの内容を理解しておくことが必要です。あるファイルのエントリに変更を加えた場合に、別のファイル内の関連エントリに対しても変更が必要になることがあります。「UUCP データベースファイルの紹介」に挙げたその他のファイルは、上記のファイルほど緊密な相互関係を持っていません。


注 -

PPP が使用するファイルはこの節で説明するものだけであり、他の UUCP データベースファイルは使用しません。


この章の以降の部分では、UUCP データベースについて詳しく説明します。

/etc/uucp/Systems ファイル

/etc/uucp/Systems ファイルには、uucico がリモートコンピュータとの通信リンクを確立するために必要な情報が入っています。これは、UUCP を構成するときに編集しなければならない最初のファイルです。

Systems ファイルの中の各エントリは、このホストが通信するリモートコンピュータを表します。1 つのホストについて複数のエントリがある場合もあります。付加的なエントリは、順番に試される代替通信パスを表します。さらに、UUCP のデフォルト状態では、/etc/uucp/Systems ファイルに含まれていないコンピュータがこのホストにログインできないようになっています。

Sysfiles ファイルを使用して、Systems ファイルとして使用されるファイルをいくつか定義できます。詳細は、Sysfiles ファイルの説明を参照してください。

Systems ファイルのエントリの形式は次のとおりです。

System-Name
 Time
 Type 
Speed 
Phone  
Chat-Script 

例 12-1 に、Systems ファイルのフィールドの例を示します。


例 12-1 /etc/uucp/Systems のフィールド


System-Name Time Type  Speed Phone   Chat Script
Arabian     Any  ACUEC 38400 111222  Login: Puucp ssword:beledi  

System-Name フィールド

このフィールドには、リモートコンピュータのノード名が入ります。TCP/IP ネットワークでは、これは、マシンのホスト名でも、/etc/uucp/Sysname ファイルによって UUCP 通信用として特別に作成した名前でもかまいません。/etc/uucp/Sysname ファイル」を参照してください。例 12-1 では、System-Name フィールドにはリモートホスト arabian に関するエントリが含まれています。

Time フィールド

このフィールドには、リモートコンピュータを呼び出すことのできる曜日と時刻を指定します。Time フィールドの形式は次のとおりです。

daytime[;retry]

day の部分には、以下のエントリのいくつかを含むリストを指定できます。

表 12-1 Day フィールド

Su Mo Tu We Th Fr Sa

個々の曜日 

Wk

任意の平日 

Any

任意の日 

Never

このホストはこのリモートコンピュータの呼び出しをいっさい行わない。呼び出しはリモートコンピュータ側から行う必要がある。それを受けて、このホストは受動モードで稼動する

例 12-1 では、Time フィールドに Any が示されています。これは、ホスト arabian をいつでも呼び出せるということです。

time の部分には、24 時間表記で表した時間の範囲を指定します (たとえば、午前 8 時 00 分から午後 12 時 30 分までなら、0800-1230)。time の部分を指定しなかった場合は、どのような時刻にでも呼び出しができるものとみなされます。

0000 の前後にまたがる時間範囲も指定できます。たとえば、0800-0600 は、午前 6 時から午前 8 時までの間を除くすべての時間帯で呼び出し可能であることを示します。

retry サブフィールド

retry サブフィールドには、試行が失敗してから次の再試行までの間に最小限必要な時間 (分単位) を指定できます。デフォルトの待ち時間は 60 分です。サブフィールド区切り文字はセミコロン (;) です。たとえば、Any;9 は、呼び出しはいつでもできるが、失敗したときは次の再試行までに少なくとも 9 分は待たなければならないことを意味します。

retry エントリを指定しなかった場合は、待ち時間倍加アルゴリズムが使用されます。これは、UUCP がデフォルトの待ち時間から始めて、失敗した試行の回数が増えるほど待ち時間を長くしていくことを意味します。たとえば、最初の再試行待ち時間が 5 分であるとします。応答がない場合は、次の再試行は 10 分後となります。次の再試行は 20 分後というようになり、最大再試行時間の 23 時間に達するまで増加します。retry を指定した場合は、常にその値が再試行待ち時間となります。指定がなければ待ち時間倍加アルゴリズムが使用されます。

Type フィールド

このフィールドには、リモートコンピュータとの通信リンクを確立するために使用するデバイスタイプを指定します。このフィールドで使用するキーワードは、例 12-2 に示すように、Devices ファイル中のエントリの最初のフィールドと突き合わされます (表の見出しに示されているフィールドは Systems ファイル用のものであり、Devices ファイルには適用されないので、注意してください。Devices ファイルのフィールドの対応関係については、例 12-6 を参照してください)。


例 12-2 Type フィールドと /etc/uucp/Devices ファイル


File Name System-Name  Time  Type     Speed  Phone     Chap-Script
 
Systems   arabian      Any   ACUEC, g 38400  1112222   ogin: Puucp ssword:beledi
 
Device    ACUEC        cua/a -        38400  usrv32bis-ec
 

Type フィールドでは、さらに、システムとの接続に使用するプロトコルを定義できます。上記の例では、デバイスタイプ ACUECg プロトコルを組み合わせています (プロトコルの詳細は、Devices ファイル内のプロトコル定義」を参照してください)。

Speed フィールド

このフィールド (Class フィールドとも呼ばれます) は、通信リンクの確立に使用するデバイスの転送速度を指定します。このフィールドには、ダイヤラのクラスを区別するために、1 個の英字と速度を含めることができます (たとえば、C1200D1200) (詳細は 「Class フィールド」を参照してください)。

デバイスにはどのような速度でも使用できるものがあり、その場合はキーワード Any を使用できます。このフィールドは、例 12-3 に示したように、Devices ファイルの対応するエントリの Class フィールドに一致していなければなりません。


例 12-3 Speed フィールドと /etc/uucp/Devices ファイル


File Name System-Name  Time  Type     Speed  Phone     Chap-Script
 
Systems   eagle        Any   ACU, g   D1200  NY3251   ogin: nuucp ssword: Oakgrass
 
Device    ACU          tty11 --       D1200  penril

このフィールドに情報を入れる必要がない場合は、フィールドの数を合わせるためにダッシュ (-) を指定してください。

Phone フィールド

このフィールドには、自動ダイヤラ (ポートセレクタ) に与えるリモートコンピュータの電話番号 (トークン) を指定できます。電話番号は、オプションの英字による省略名と数字部分で構成されます。省略名を使用する場合は、例 12-4 に示すように Dialcodes ファイル内に列挙されているもののひとつでなければなりません。


例 12-4 Phone フィールドの対応関係


File Name System-Name  Time  Type  Speed  Phone     Chap-Script
 
Systems   nubian       Any   ACU   2400   NY5551212 ogin: Puucp ssword:Passuan
 
Dialcodes NY 1-1212

この文字列の中に等号 (=) が含まれている場合、二次発信音を待ってから残りの数字をダイヤルするという ACU への指示となります。文字列の中にダッシュ (-) があれば、4 秒間待ってから次の数字をダイヤルするという指示になります。

コンピュータがポートセレクタに接続されている場合は、そのセレクタに接続している他のコンピュータにアクセスできます。この種のリモートマシン用の Systems ファイルエントリの Phone フィールドには、電話番号を入れません。代わりに、このフィールドにはスイッチに渡すトークンを指定します。このようにすれば、このホストがどのリモートマシンとの通信を望んでいるかを、ポートセレクタが判断できます (この場合は、システム名だけを指定するのが普通です)。対応する Devices ファイルエントリでは、エントリの末尾に ¥D を指定して、このフィールドが Dialcode ファイルを使って解釈されないようにしなければなりません。

Chat-Script フィールド

このフィールド (Login フィールドとも呼ばれます) には、チャットスクリプトと呼ばれる文字列が入ります。チャットスクリプトには、ローカルマシンとリモートマシンが対話の最初の時点で互いに受け渡ししなければならない文字が含まれています。チャットスクリプトの形式は次のとおりです。

expect send [expect send] ....

expect は、対話を開始するために、ローカルホストがリモートホストから送られてくることを想定している文字列です。send は、ローカルホストが、リモートホストからの expect 文字列を受信した後で送信する文字列です。チャットスクリプトには、複数の expect-send シーケンスを含めることもできます。

基本的なチャットスクリプトには次の情報が含まれます。

expect フィールドは、次の形式のサブフィールドを持つことができます。

expect[-send-expect]...

-send は、その前の expect が正常に読み取れなかった場合に送られるものであり、send の後の -expect は、その次に送られてくると想定されている文字列です。

たとえば、login--login という文字列を指定した場合、ローカルホストの UUCP は login が送られてくることを想定します。リモートマシンから login を受信すると、UUCP は次のフィールドに進みます。login を受信しなかった場合は、キャリッジリターンを送信し、再度 login が送られてくるのを待ちます。ローカルコンピュータが、初期状態でどのような文字も想定していない場合は、expect フィールドで文字列 "" (NULL 文字列) を指定します。send 文字列が ¥c で終わっている場合を除き、send フィールドの送信の後には必ずキャリッジリターンが伴うという点に注意してください。

次に示すのは、expect-send 文字列を使用する Systems ファイルエントリの例です。


sonora Any ACUEC 9600 2223333 "" ¥r ¥r ogin:-BREAK-ogin: Puucpx ssword: xyzzy

この例は、ローカルホストの UUCP に、2 個のキャリッジリターンを送ってから ogin: (Login: という場合もあるため) を待つように指示しています。ogin を受信しなかった場合は、BREAK を送ります。ogin: を受信した場合は、ログイン名 Puucpx を送ります。ssword: (Password: を表す) を受け取ったら、パスワード xyzzy を送ります。

表 12-2 に、便利なエスケープ文字をいくつか紹介します。

表 12-2 Systems ファイルのチャットスクリプトで使用されるエスケープ文字
 文字 説明

¥b

バックスペース文字を送信または想定する 

¥c

文字列の末尾で使用すると、普通なら送信されるキャリッジリターンが抑止される。その他の場合は無視される 

¥d

後続の文字を送る前に 1 〜 3 秒の遅延が生じる 

¥E

エコーチェックを開始する (これ以降は、1 文字送信するたびに、その文字が受信されるのを待つ。以後の作業は、これを受信してから行われる) 

¥e

エコーチェックをオフにする  

¥H

ハングアップを 1 回無視する。このオプションはコールバックモデム用に使用する 

¥K

BREAK 文字を送信する 

¥M

CLOCAL フラグをオンにする

¥m

CLOCAL フラグをオフにする

¥n

改行文字を送信または想定する 

¥N

NULL 文字 (ASCII NUL) を送信する 

¥p

約 1/4 秒間または 1/2 秒間、一時停止する 

¥r

キャリッジリターンを送信または想定する 

¥s

スペース文字を送信または想定する 

¥t

タブ文字を送信または想定する 

EOT

EOT とそれに続く 2 個の改行文字を送信する 

BREAK

ブレーク文字を送信する 

¥ddd

8 進数 (ddd) で表される文字を送信または想定する

チャットスクリプトを用いたコールバックの有効化

組織によっては、リモートコンピュータからの呼び出しを処理するダイヤルインサーバーを設定する場合があります。たとえば、コールバックモデムを持つダイヤルインサーバーを配備し、社員が自宅のコンピュータから呼び出せるようにすることができます。ダイヤルインサーバーは、リモートマシンを識別すると、そのリモートマシンとのリンクを切断し、逆にそのリモートマシンを呼び出して、通信リンクが再確立されます。

Systems ファイルのチャットスクリプトで、コールバックが必要な箇所で ¥H オプションを使用することにより、コールバックの操作を簡素化することができます。ダイヤルインサーバーのハングアップが予想される箇所で、expect 文字列の一部として ¥H を使用します。

たとえば、ダイヤルインサーバーを呼び出すチャットスクリプトに、次のような文字列が含まれているとします。


INITIATED¥Hogin:

ローカルホストの UUCP ダイヤル機能は、ダイヤルインサーバーから INITIATED という文字列を受け取ることを想定しています。INITIATED 文字列を受け取ると、ダイヤル機能は、ダイヤルインサーバーがハングアップするまで、その後受信するすべての文字をフラッシュします。またダイヤル機能は、expect 文字列のその次の部分、つまり ogin: という文字列がダイヤルインサーバーから送られてくるのを待ちます。ogin: を受け取ると、ダイヤル機能はチャットスクリプトを先へ進めます。

上記のサンプルでは ¥H の前後に文字列が指定されていますが、これらはなくてもかまいません。

ハードウェアフロー制御

擬似送信文字列 STTY=value を使用して、モデム特性を設定することもできます。たとえば、STTY=crtscts を使用すると、ハードウェアフロー制御が可能になります。 STTY はすべての stty モードを受け入れます。詳細は、stty(1V)termio(7I) のマニュアルページを参照してください。

次の例は、Systems ファイルのエントリ内でハードウェアフロー制御を指定しています。


unix Any ACU 2400 12015551212 "" ¥r login:-¥r-login:-¥r-login: 
nuucp password: xxx "" ¥ STTY=crtscts 

擬似送信文字列は、Dialers ファイルのエントリの中でも使用できます。

パリティの設定

場合によっては、呼び出そうとしているシステムがポートのパリティを検査し、パリティに誤りがあると回線を切断することがあります。このようなときは、パリティのリセットが必要になることがあります。expect-send の文字列ペアとして "" P_ZERO を使用すると、上位ビット (パリティビット) が 0 に設定されます。たとえば次のように指定します。


unix Any ACU 2400 12015551212 "" P_ZERO "" ¥r login:-¥r-login:-¥r-login:
nuucp password: xxx

同様に、P_EVEN はパリティを偶数 (デフォルト) に設定し、P_ODD は奇数パリティを設定し、P_ONE はパリティビットを 1 に設定します。

パリティ設定は、チャットスクリプトのどこにでも挿入できます。この設定は、チャットスクリプト内の "" P_ZERO より後にあるすべての情報に適用されます。これは、Dialers ファイルのエントリの中でも使用できます。

/etc/uucp/Devices ファイル

/etc/uucp/Devices ファイルには、リモートコンピュータへのリンクを確立するために使用できるすべてのデバイスに関する情報が入っています。この種のデバイスには、ACU (が含まれます)、直接リンク、ネットワーク接続などがあります。

Devices ファイルのエントリの形式は次のとおりです。

Type

Line

Line2

Class

Dialer-Token-Pairs

次に示す /etc/uucp/Devices のエントリは、ポート A に接続され 38,400 bps で動作する US Robotics V.32bis モデムを表しています。


ACUEC cua/a - 38400 usrv32bis-ec

以下各フィールドについて説明します。

Type フィールド

このフィールドは、デバイスが確立するリンクの種類を記述します。このフィールドには次のセクションに示すキーワードのいずれかを入れることができます。

キーワード Direct

キーワード Direct は、主として cu 接続用のエントリ内で使用されます。このキーワードは、このリンクが他のコンピュータまたはポートセレクタへの直接リンクであることを示します。cu-l オプションで参照したい各回線について、それぞれ独立したエントリを作成する必要があります。

キーワード ACU

キーワード ACU は、(cu、UUCP、または PPP を介した) リモートコンピュータへのリンクを、モデムを介して確立することを示します。このモデムは、直接ローカルコンピュータに接続しているものでも、ポートセレクタを介して間接的に接続しているものでもかまいません。

ポートセレクタ

これは、ポートセレクタの名前で置き換えるものとして、Type フィールド内で使用される変数です。ポートセレクタは、ネットワークに接続されたデバイスで、呼び出し側モデムの名前を要求し、アクセスを許可します。 /etc/uucp/Dialers ファイルに入っている呼び出しスクリプトは、micom ポートセレクタと develcon ポートセレクタについてのものだけです。ユーザーは、Dialers ファイルに独自のポートセレクタエントリを追加できます (詳細は /etc/uucp/Dialers ファイル」を参照してください)。

Sys-Name

Type フィールド内のこの変数は、特定のマシンの名前で置き換えられます。これは、リンクがこのマシンへの直接リンクであることを示します。この命名スキーマは、この Devices エントリ内の行と、コンピュータ Sys-Name についての /etc/uucp/Systems ファイルエントリを対応付けるために使用されます。

Type フィールドと /etc/uucp/Systems ファイル

例 12-5 は、/etc/uucp/Devices のフィールドと、/etc/uucp/Systems のフィールドの対応を示しています。各列の見出しは Devices ファイルに対応するものです。

例 12-5 でフィールドの書体を変えて示したように、Devices ファイルの Type フィールドで使用されているキーワードは、Systems ファイルエントリの 3 番目のフィールドと突き合わされます。Devices ファイルの Type フィールドには ACUEC というエントリが入っており、これは自動呼び出し装置、つまりこの例では V.32bis モデムを示しています。この値は、Systems ファイルの 3 番目のフィールドと突き合わされます。このフィールドにも ACUEC というエントリが入っています (詳細は /etc/uucp/Systems ファイル」を参照してください)。


例 12-5 Type フィールドと /etc/uucp/Systems の対応関係


File Name  Type   Line  Line2  Class  Dialer-Token-Pairs
 
Devices    ACUEC  cua/a -      38400  usrv32bis-ec
 
System     nubian Any   ACUEC  38400  9998888 "" ¥d¥d¥r¥n¥c-ogin-¥r¥n¥c-ogin....... 
 

Line フィールド

このフィールドには、Devices エントリに対応付けられる回線 (ポート) のデバイス名が入ります。たとえば、特定のエントリに対応付けられているモデムが /dev/cua/a (シリアルポート A) に接続されている場合、このフィールドに入力する名前は cua/a です。Line フィールドでオプションのモデム制御フラグ M を使用すると、キャリアを待たないでデバイスをオープンすることを指定できます。たとえば次のようになります。


cua/a,M

Line2 フィールド

このフィールドは、フィールドの数を合わせるために存在しているだけです。ここには常にダッシュ (-) を指定します。Line2 フィールドを使用するのは 801 型のダイヤラですが、この種類は Solaris 環境ではサポートされていません。801 型以外のダイヤラは通常はこの設定を使用しませんが、このフィールドにダッシュだけは入れておく必要があります。

Class フィールド

Type フィールドでキーワード ACU または Direct を使用した場合は、Class フィールドにはデバイスの速度が入ります。ただし、このフィールドには、ダイヤラのクラス (Centrex または Dimension PBX) を区別するために、1 個の英字と速度値を含めることができます (たとえば、C1200D1200)。

大規模な事業所では複数種の電話ネットワークを使用することが多いため、このような指定が必要になります。たとえば、1 つのネットワークは事業所内の内線通信専用に使用し、もう 1 つのネットワークは外線通信に使用するといった方式が考えられます。このような場合は、内線回線と外線回線とを区別する必要があります。

例 12-6 に示すように、Devices ファイルの Class フィールドで使用するキーワードは、Systems ファイルの Speed フィールドと突き合わされます。各列の見出しは、Devices ファイルのフィールドのものであることに注意してください。


例 12-6 Class フィールドと /etc/uucp/Systems の対応関係


File Name  Type   Line  Line2  Class  Dialer-Token-Pairs
 
Devices    ACU    cua/a -      D2400  hayes
 
System     gobi   Any   ACUEC  D2400  3251 ogin: nuucp ssword: taheya
 

どのような速度でも使用できるデバイスでは、Class フィールドにキーワード Any を使用します。Any を使用した場合は、回線は、Systems ファイルの Speed フィールドで要求された任意の速度に適合します。このフィールドが Any で、Systems ファイルの Speed フィールドも Any である場合は、速度はデフォルトの 2400 bps となります。

Dialer-Token-Pairs フィールド

Dialer-Token-Pairs (DTP) フィールドには、ダイヤラの名前とそれに渡すトークンが入ります。DTP フィールドの構文は次のとおりです。

dialer token [dialer token]

dialer の部分は、モデムかポートモニターの名前あるいは直接リンクデバイスの場合は direct または uudirect です。ダイヤラとトークンのペアはいくつでも指定できます。指定しなかった場合は、Systems ファイル内の関連エントリから取得されます。token 部は、dialer 部の直後に指定できます。

対応するダイヤラによっては、最後のダイヤラとトークンのペアはない場合もあります。ほとんどの場合は、最後のペアには dialer 部だけが含まれます。token 部は、対応する Systems ファイルエントリの Phone フィールドから取得されます。

dialer 部の有効エントリは、Dialers ファイル内で定義されているものか、いくつかの特殊ダイヤラタイプのうちの 1 つとなります。これらの特殊ダイヤラタイプはコンパイル時にソフトウェア中に組み込まれているので、Dialers ファイル内に該当エントリがなくても使用できます。表 12-3 に、特殊ダイヤラタイプを示します。

表 12-3 ダイヤラとトークンのペア

TCP

TCP/IP ネットワーク 

TLI

トランスポートレベルインタフェースネットワーク (STREAMS を使わないもの) 

TLIS

トランスポートレベルインタフェースネットワーク (STREAMS を使うもの) 

詳細は、Devices ファイル内のプロトコル定義」を参照してください。

Dialer-Token-Pairs フィールドの構造

DTP フィールドの構造は、エントリに対応するデバイスに応じて 4 通りに設定できます。


例 12-7 Dialers フィールドと /etc/uucp/Dialers の対応関係


File Name Type  Line  Line2 Class Dialer-Token-Pairs
 
Devices   ACU   cua/b -     2400  hayes
 
Dialers   hayes =,-,  ""          ¥¥dA¥pTE1V1X1Q0S2=255S12=255¥r¥c
                                  ¥EATDT¥T¥r¥c CONNECT
 

Devices ファイルエントリの DTP フィールドには、dialer 部 (hayes) だけが示されている点に注意してください。これは、ダイヤラに渡すトークン (この例では電話番号) が、Systems ファイルエントリの Phone フィールドから取得されることを意味します (例 12-9 で説明する ¥T が暗黙で指定されます)。


例 12-8 Dialers フィールドと /etc/uucp/Dialers の対応関係


File Name  Type     Line  Line2  Class  Dialer-Token-Pairs
 
Devices    develcon cua/a -      1200   develcon
 
Dialers    develcon ,""   ""            ¥pr¥ps¥c est:¥007 ¥E¥D¥e ¥007
 

token 部が空である点に注意してください。これは、この部分が Systems ファイルから取得されることを示しています。このコンピュータ用の Systems ファイルエントリには、Phone フィールドにトークンが含まれています。このフィールドは、通常、コンピュータの電話番号用として確保されています (/etc/uucp/Systems ファイル」を参照してください)。この種類の DTP にはエスケープ文字 (¥D) が含まれています。これは、Phone フィールドの内容が、Dialcode ファイル内の有効エントリとして解釈されないことを保証します。


例 12-9 Dialers フィールドと /etc/uucp/Dialers の対応関係


File Name  Type     Line  Line2  Class     Dialer-Token-Pairs
 
Devices    ACU      cua/b -      1200      develcon    vent        ventel
 
Dialers    develcon ""    ""     ¥pr¥ps¥c  est:¥007    ¥E¥D¥e      ¥007
 
Dialers    ventel   =&-%   t""   ¥r¥p¥r¥c  $           <K¥T%¥r>¥c  ONLINE!
 

最初のペアでは、develcon がダイヤラで、vent が Develcon スイッチに渡されるトークンです。トークンは、コンピュータに接続するデバイス (たとえば Ventel モデム) をダイヤラに指示しています。各スイッチごとに設定が異なることがあるので、このトークンは各ポートセレクタに固有のものにします。Ventel モデムが接続されると、第 2 のペアがアクセスされます。このペアでは、Ventel がダイヤラで、トークンは Systems ファイルから取得されます。

DTP フィールドでは 2 つのエスケープ文字が使用できます。

Devices ファイル内のプロトコル定義

/etc/uucp/Devices では、各デバイスに使用するプロトコルを定義できます。通常は、デフォルトを使用するか、または呼び出そうとしている個々のシステムごとにプロトコルを定義できるので、この指定は不要です (/etc/uucp/Systems ファイル」を参照してください)。プロトコルを指定する場合は、次の形式を使用する必要があります。

Type,Protocol [parameters]

たとえば、TCP/IP プロトコルを指定するには、TCP,te を入力します。

表 12-4 に、Devices ファイルで使用できるプロトコルを示します。

表 12-4 /etc/uucp/Devices で使用されるプロトコル

プロトコル 

説明 

t

このプロトコルは、TCP/IP や、その他の信頼性のある接続を介した伝送に、最もよく使われる。このプロトコルはエラーのない伝送を前提としている 

g

UUCP のネイティブプロトコル。低速で信頼性があり、ノイズの多い電話回線を介した伝送に適している 

e

このプロトコルは、(TCP/IP のようなバイトストリーム指向ではなく) メッセージ指向でエラーのないチャネルを介した伝送を前提としている 

f

このプロトコルは X.25 接続を介した伝送に使用される。このプロトコルは、データストリームのフロー制御に関係している。特に X.25/PAD リンクなどのように、完全に (またはほとんど) エラーがないことが保証されるリンクでの使用を意図している。検査合計はファイル全体についてのみ実施される。伝送が失敗した場合は、受信側は再伝送を要求する 

次に、デバイスエントリ用のプロトコル指定の例を示します。


TCP,te - - Any TCP - 

この例は、デバイス TCP について t プロトコルの使用を試みるように指示しています。相手側がそれを拒否した場合は、e プロトコルが使用されます。

et のどちらも、モデムを介した通信には適していません。モデムがエラーのない伝送を保証するものであったとしても、モデムと CPU との間でデータが失われる可能性があります。

/etc/uucp/Dialers ファイル

/etc/uucp/Dialers ファイルには、よく使われる多くのモデムに関するダイヤリング指示が入っています。標準外のモデムの使用や、UUCP 環境のカスタマイズを予定している場合以外は、一般にこのファイルのエントリの変更や追加は必要ありません。しかし、このファイルの内容と、Systems ファイルや Devices ファイルとの関係は理解しておく必要があります。

このファイルの中のテキストは、回線をデータ転送に使用できるようにするために、最初に行わなければならない対話を指定します。チャットスクリプトと呼ばれるこの対話は、通常は送受信される一連の ASCII 文字列で、電話番号をダイヤルするためによく使われます。

/etc/uucp/Devices ファイル」の例に示したように、Devices ファイルの 5 番目のフィールドは、Dialers ファイルへのインデックスか、または特殊ダイヤラタイプ (TCP、TLI、または TLIS) です。 uucico デーモンは、Devices ファイルの 5 番目のフィールドを、Dialers ファイルの各エントリの最初のフィールドと突き合わせます。さらに、Devices の 7 番目の位置から始まる奇数番号の各フィールドは、Dialers ファイルへのインデックスとして使用されます。これらが一致すると、その Dialers のエントリがダイヤラ対話を行うために解釈されます。

Dialers ファイルの各エントリの形式は次のとおりです。

dialer 
substitutions 
expect-send

例 12-10 は、US Robotics V.32bis モデム用のエントリの例を示しています。


例 12-10 /etc/uucp/Dialers ファイルのエントリ


Dialer       Substitution  Expaec-Send
usrv32bis-e  =,-,  ""      dA¥pT&FE1V1X1Q0S2=255S12=255&A1&H1&M5&B2&W¥r¥c OK¥r
                           ¥EATDT¥T¥r¥c CONNECT¥s14400/ARQ STTY=crtscts

Dialer フィールドは、Devices ファイルの中の 5 番目以降の奇数番号のフィールドと突き合わされます。Substitutions フィールドは変換文字列です。各文字ペアの最初の文字が 2 番目の文字に変換されます。通常これは、=- を、「発信音待ち」と「一時停止」用としてダイヤラが必要とする文字に変換するために使用されます。

それ以降の expect-send の各フィールドは文字列です。

例 12-11 に、Dialers ファイルのエントリの例をいくつか示します。これは、Solaris インストールプログラムの一環として UUCP をインストールしたときに提供されるファイルです。


例 12-11 /etc/uucp/Dialers ファイルの抜粋

penril      =W-P "" ¥d > Q¥c : ¥d- > s¥p9¥c )-W¥p¥r¥ds¥p9¥c-) y¥c : ¥E¥TP > 9¥c OK
 
ventel  =&-%        "" ¥r¥p¥r¥c $ <K¥T%%¥r>¥c ONLINE!
 
vadic   =K-K    "" ¥005¥p *-¥005¥p-*¥005¥p-* D¥p BER? ¥E¥T¥e ¥r¥c LINE
 
develcon        ""      "" ¥pr¥ps¥c est:¥007
 
¥E¥D¥e ¥n¥007 micom     ""      "" ¥s¥c NAME? ¥D¥r¥c GO
 
hayes   =,-,    "" ¥dA¥pTE1V1X1Q0S2=255S12=255¥r¥c OK¥r ¥EATDT¥T¥r¥c CONNECT
 
#   Telebit TrailBlazer
tb1200  =W-,    "" ¥dA¥pA¥pA¥pTE1V1X1Q0S2=255S12=255S50=2¥r¥c OK¥r ¥EATDT¥T¥r¥c
CONNECT¥s1200
tb2400  =W-,    "" ¥dA¥pA¥pA¥pTE1V1X1Q0S2=255S12=255S50=3¥r¥c OK¥r ¥EATDT¥T¥r¥c
CONNECT¥s2400
tbfast  =W-,    "" ¥dA¥pA¥pA¥pTE1V1X1Q0S2=255S12=255S50=255¥r¥c OK¥r ¥EATDT¥T¥r¥c 
CONNECT¥sFAST
 
# USrobotics, Codes, and DSI modems
 
dsi-ec  =,-,    "" ¥dA¥pTE1V1X5Q0S2=255S12=255*E1*F3*M1*S1¥r¥c OK¥r ¥EATDT¥T¥r¥c
CONNECT¥sEC STTY=crtscts,crtsxoff
 
dsi-nec =,-,    "" ¥dA¥pTE1V1X5Q0S2=255S12=255*E0*F3*M1*S1¥r¥c OK¥r ¥EATDT¥T¥r¥c 
CONNECT STTY=crtscts,crtsxoff

usrv32bis-ec =,-,  "" ¥dA¥pT&FE1V1X1Q0S2=255S12=255&A1&H1&M5&B2&W¥r¥c OK¥r 
¥EATDT¥T¥r¥c CONNECT¥s14400/ARQ STTY=crtscts,crtsxoff

usrv32-nec =,-, "" ¥dA¥pT&FE1V1X1Q0S2=255S12=255&A0&H1&M0&B0&W¥r¥c OK¥r 
¥EATDT¥T¥r¥c CONNECT STTY=crtscts,crtsxoff

codex-fast =,-, "" ¥dA¥pT&C1&D2*MF0*AA1&R1&S1*DE15*FL3S2=255S7=40S10=40*TT5&W¥r¥c 
OK¥r EATDT¥T¥r¥c CONNECT¥s38400 STTY=crtscts,crtsxoff

tb9600-ec =W-,  "" ¥dA¥pA¥pA¥pTE1V1X1Q0S2=255S12=255S50=6¥r¥c OK¥r
¥EATDT¥T¥r¥cCONNECT¥s9600 STTY=crtscts,crtsxoff

tb9600-nec =W-, "" ¥dA¥pA¥pA¥pTE1V1X1Q0S2=255S12=255S50=6S180=0¥r¥c OK¥r 
¥EATDT¥T¥r¥c CONNECT¥s9600 STTY=crtscts,crtsxoff

表 12-5 に、Dialers ファイルの send 文字列でよく使われるエスケープ文字を示します。

表 12-5 /etc/uucp/Dialers で使用するエスケープ文字

文字 

説明 

¥b

バックスペース文字を送信または想定する 

¥c

改行、キャリッジリターンを抑止する 

¥d

遅延 (約 2 秒) 

¥D

Dialcodes 変換なしの電話番号またはトークン

¥e

エコーチェックを使用しない 

¥E

エコーチェックを使用する (低速デバイス用) 

¥K

ブレーク文字を挿入する  

¥n

改行文字を送信する 

¥nnn

8 進数値を送信する。使用できるその他のエスケープ文字は、/etc/uucp/Systems ファイル」を参照

¥N

NULL 文字 (ASCII NUL) を送信または想定する 

¥p

一時停止 (約 12 〜 14 秒) 

¥r

リターン  

¥s

スペース文字を送信または想定する 

¥T

Dialcodes 変換を伴う電話番号またはトークン

次に示すのは Dialers ファイルの penril エントリです。

penril =W-P "" ¥d > Q¥c : ¥d- > s¥p9¥c )-W¥p¥r¥ds¥p9¥c-) y¥c : ¥E¥TP > 9¥c OK 

最初に、電話番号引数の置換メカニズムが確立されます。その結果、= はすべて W (発信音待ち) で置き換えられ、- はすべて P (一時停止) で置き換えられるようになります。

上記の行の残りの部分に指定されているハンドシェークの働きは、次のとおりです。

ハードウェアフロー制御

擬似送信文字列 STTY=value を用いることによっても、モデムの特性を設定できます。たとえば、STTY=crtscts は出力ハードウェアフロー制御、STTY=crtsxoff は入力ハードウェアフロー制御を使用可能にし、STTY=crtscts、crtsxoff は入出力両方のハードウェアフロー制御を使用可能にします。

STTY はすべての stty モードを受け入れます。詳細は、stty(1V)termio(7I) のマニュアルページを参照してください。

次の例は、Dialers ファイルエントリ内でハードウェアフロー制御を使用可能にしています。


dsi =,-, "" ¥dA¥pTE1V1X5Q0S2=255S12=255*E1*F3*M1*S1¥r¥c OK¥r ¥EATDT¥T¥r¥c 
CONNECT¥sEC STTY=crtscts 

この擬似送信文字列は、Systems ファイルのエントリ中でも使用できます。

パリティの設定

場合によっては、呼び出そうとしているシステムがポートのパリティを検査し、パリティに誤りがあると回線を切断することがあります。そのため、パリティのリセットが必要になります。expect-send の対を成す文字列として ‾‾ P_ZERO を使用すると、パリティが 0 に設定されます。


foo =,-, "" P_ZERO "" ¥dA¥pTE1V1X1Q0S2=255S12=255¥r¥c OK¥r¥EATDT¥T¥r¥c CONNECT 

同様に、P_EVEN はパリティを偶数 (デフォルト) に、P_ODD はパリティを奇数に設定し、P_ONE はパリティを 1 に設定します。この擬似送信文字列は、Systems ファイルのエントリの中でも使用できます。

その他の基本構成ファイル

この節で紹介するのは、基本的な UUCP 構成を行うときに、SystemsDevicesDialers ファイルに加えて使用できるファイルです。

/etc/uucp/Dialcodes ファイル

/etc/uucp/Dialcodes ファイルにより、/etc/uucp/Systems ファイルの Phone フィールドで使用するダイヤルコードの省略名を定義できます。Dialcodes ファイルは、同じサイトにある複数のシステムが使用する基本的な電話番号について、付加的な情報を指定するために使用できます。

このファイルのエントリの形式は次のとおりです。

abbreviation dial-sequence

abbreviation は、Systems ファイルの Phone フィールドで使用される省略名で、dial-sequence は、個々の Systems ファイルのエントリがアクセスされたときにダイヤラに渡されるダイヤルシーケンスです。表 12-6 に、この 2 つのファイル間の対応関係を示します。

表 12-6 Dialcodes ファイルと Systems ファイルの間の対応関係

 

フィールド名 

 

 

 

 

 

Dialcodes 

Abbreviation

Dial-Sequence 

 

 

 

 

Systems 

System-Name 

Time 

Type 

Speed 

Phone

Chat Script 

表 12-7 に示すのは、Dialcodes ファイルのエントリの例です。

表 12-7 Dialcode ファイルのエントリ

Abbreviation 

Dial-sequence 

NY

1=212

jt

9+847

最初の行の NY は、Systems ファイルの Phone フィールドで使用される省略名です。Systems ファイルのエントリは、たとえば次のようになります。

NY5551212

uucico は、Systems ファイルから NY を読み取ると、Dialcodes ファイルから NY を探し、それに該当するダイヤルシーケンス 1=212 を取得します。これは、New York City への電話呼び出しに必要なダイヤルシーケンスです。このシーケンスは、1 という番号と、一時停止して次の発信音を待つことを示す等号 (=) と、地域コード 212 で構成されています。uucico はこの情報をダイヤラに送り、再び Systems ファイルに戻って残りの電話番号 5551212を処理します。

jt 9=847- というエントリは、Systems ファイル内の jt7867 などのような Phone フィールドを取り扱います。uucico は、jt7867 を含むエントリを Systems ファイルから読み取ると、ダイヤラとトークンのペアの中のトークンが ¥T であれば、9=847-7867 というシーケンスをダイヤラに送ります。

/etc/uucp/Sysfiles ファイル

/etc/uucp/Sysfiles ファイルでは、uucpcuSystemsDevicesDialers ファイルとして使用する別のファイルを割り当てます (cu についての詳細は、cu(1C) のマニュアルページを参照してください)。Sysfiles は次の目的に使用できます。

Sysfiles ファイルの形式は次のとおりです。


service=w systems=x:x dialers=y:y devices=z:z 

w には、uucicocu、またはその両方をコロンで区切って指定します。x には、Systems ファイルとして使用される 1 つまたは複数のファイルをコロンで区切って指定します。これらは指定された順序で読み込まれます。yDialers ファイルとして使用される 1 つまたは複数のファイルで、zDevices ファイルとして使用される 1 つまたは複数のファイルです。

フルパスで指定しない限り、各ファイル名は /etc/uucp ディレクトリからの相対パスとみなされます。

次に示すのは、標準の /etc/uucp/Systems に加えて使用するローカル Systems ファイル (Local_Systems) を定義する /etc/uucp/Sysfiles の例です。


service=uucico:cu systems=Systems :Local_Systems 

/etc/uucp/Sysfiles の中にこのエントリがある場合、uucicocu はどちらも、まず標準 /etc/uucp/Systems ファイルを調べます。呼び出そうとしているシステムのエントリがそのファイル内にないか、またはそのファイル内の該当エントリの処理に失敗した場合は、/etc/uucp/Local_Systems が調べられます。

上記のエントリの場合は、cuuucico は、Dialers ファイルと Devices ファイルを共有します。

uucico サービス用と cu サービス用に別の Systems ファイルを定義した場合は、マシンは 2 つの異なる Systems のリストを持つことになります。uucico リストは uuname コマンドを使って表示でき、cu リストは uuname -C コマンドを使って表示できます。このファイルのもう 1 つの例として、代替ファイルの方を先に調べ、デフォルトファイルは必要なときだけ調べる場合を示します。


service=uucico systems=Systems.cico:Systems
  dialers=Dialers.cico:Dialers ¥
devices=Devices.cico:Devices
  service=cu systems=Systems.cu:Systems ¥
dialers=Dialers.cu:Dialers ¥
  devices=Devices.cu:Devices

/etc/uucp/Sysname ファイル

UUCP を使用するすべてのマシンは、ノード名と呼ばれる識別名を持っている必要があります。この名前は、リモートマシンの /etc/uucp/Systems ファイルに、チャットスクリプトやその他の識別情報とともに格納されます。通常は、UUCP は、uname -n コマンドから返されるものと同じノード名を使用し、TCP/IP でもこの名前を使用します。

/etc/uucp/Sysname ファイルを作成することによって、TCP/IP ホスト名とは別の UUCP ノード名を指定できます。このファイルには、ローカルシステムの UUCP ノード名が入った 1 行のエントリが含まれています。

/etc/uucp/Permissions ファイル

/etc/uucp/Permissions ファイルは、ログイン、ファイルアクセス、コマンド実行に関するリモートコンピュータのアクセス権を指定します。リモートコンピュータがファイルを要求する権限と、ローカルマシンでキューに入れられたファイルを受け取る権限を制限するオプションがあります。また、リモートマシンがローカルコンピュータ上で実行できるコマンドを指定するオプションもあります。

エントリの構造

各エントリは 1 行の論理行で、行末にバックスラッシュ (¥) がある場合は次の行と継続していることを示します。エントリは、スペースで区切られたオプションから構成されます。各オプションは、次の形式の名前と値のペアです。

name=value

values はコロンで区切ってリストとすることもできます。オプション指定の中では、スペースは使用できないので注意してください。

コメント行はポンド記号 (#) で始まり、その行の改行文字までの全部分を占めます。空行は無視されます (複数行エントリの中の空行も同じです)。

Permissions ファイルのエントリには 2 つの種類があります。


注 -

リモートマシンがローカルマシンを呼び出すとき、固有のログインと検証可能なパスワードを使わない限り、そのリモートマシンの識別情報は正確なものとはなりません。


LOGNAME エントリには LOGNAME オプションが含まれ、MACHINE エントリには MACHINE オプションが含まれます。1 つのエントリに両方のオプションを含めることもできます。

考慮事項

Permissions ファイルを使って、リモートコンピュータに付与されているアクセスのレベルを制限するときは、以下のことを考慮に入れる必要があります。

REQUEST オプション

リモートコンピュータがローカルコンピュータを呼び出し、ファイルの受信を要求したときに、その要求を承認することも拒否することもできます。REQUEST オプションは、リモートコンピュータがローカルコンピュータからのファイル転送を要求できるかどうかを指定します。REQUEST=yes は、リモートコンピュータがローカルコンピュータからのファイル転送を要求できることを指定します。REQUEST=no は、リモートコンピュータがローカルコンピュータからのファイルの受信を要求できないことを指定します。後者は、REQUEST オプションを指定しなかった場合に使用されるデフォルト値です。REQUEST オプションは、LOGNAME エントリ (リモートコンピュータがローカルコンピュータを呼び出す場合) と、MACHINE エントリ (ローカルコンピュータがリモートコンピュータを呼び出す場合) のどちらにも使用できます。

SENDFILES オプション

リモートコンピュータがローカルコンピュータを呼び出す作業を完了した後で、ローカルコンピュータのキュー中のリモートコンピュータ用の作業を受け取ろうとすることがあります。SENDFILES オプションは、ローカルコンピュータが、リモートコンピュータ用にキューに入れた作業を送信できるかどうかを指定します。

文字列 SENDFILES=yes は、リモートコンピュータが LOGNAME オプションに指定されている名前の 1 つを使ってログインしていれば、ローカルコンピュータがキューに入れた作業を送信できることを指定します。/etc/uucp/Systems の Time フィールドに Never を入力してある場合は、この文字列の使用は必須です。Never を指定すると、ローカルマシンは受動モードに設定され、相手のリモートコンピュータへの呼び出しを開始することはできなくなります (詳細は /etc/uucp/Systems ファイル」を参照してください。

文字列 SENDFILES=call は、ローカルコンピュータがリモートコンピュータを呼び出したときに限り、ローカルコンピュータのキュー中のファイルを送信することを指定します。call の値は SENDFILES オプションのデフォルト値です。MACHINE エントリはリモートコンピュータへの呼び出しを送る場合に適用されるものなので、このオプションが意味を持つのは LOGNAME エントリの中で使用した場合だけです。MACHINE エントリでこのオプションを使用しても無視されます。

MYNAME オプション

このオプションを使用すると、hostname コマンドから戻される TCP/IP ホスト名以外に、固有の UUCP ノード名をローカルシステムに与えることができます。たとえば、偶然に他のシステムと同じ名前をローカルホストに付けてしまった場合などに、Permissions ファイルの MYNAME オプションを指定できます。あるいは、たとえば、自分の所属組織が widget という名前で認識されるようにしたいが、すべてのモデムが gadget というホスト名を持つマシンに接続されているという場合は、gadgetPermissions ファイルに次のようなエントリを含めることができます。


service=uucico systems=Systems.cico:Systems
  dialers=Dialers.cico:Dialers ¥
devices=Devices.cico:Devices
  service=cu systems=Systems.cu:Systems ¥
dialers=Dialers.cu:Dialers ¥
  devices=Devices.cu:Devices

これで、システム world は、あたかも widget にログインしているかのようにマシン gadget にログインできます。ローカルマシンから world マシンを呼び出したときにも、worldwidget という別名で認識するようにしたい場合は、次のようなエントリを作成します。


MACHINE=world MYNAME=widget

MYNAME オプションにより、ローカルマシンが自分自身を呼ぶこともできるので、テストの目的にも利用できます。しかし、このオプションはマシンの実際の識別情報を隠す目的にも使用できてしまうので、VALIDATE オプション」で述べる VALIDATE オプションを使用するようにしてください。

READ オプションと WRITE オプション

これらのオプションは、uucico がファイルシステムのどの部分を読み書きできるかを指定します。READ オプションと WRITE オプションは、MACHINE エントリと LOGNAME エントリのどちらにも使用できます。

次の文字列に示すように、READ オプションと WRITE オプションのどちらも、デフォルトは uucppublic ディレクトリです。


READ=/var/spool/uucppublic WRITE=/var/spool/uucppublic 

文字列 READ=/WRITE=/ は、Other 権を持つローカルユーザーがアクセスできるすべてのファイルにアクセスできる権限を指定します。

これらのエントリの値は、コロンで区切ったパス名のリストです。READ オプションはリモート側からのファイル要求のためのものであり、WRITE オプションはリモート側からのファイル送出のためのものです。値の 1 つは、入力ファイルまたは出力ファイルのフルパス名の接頭辞でなければなりません。公共ディレクトリのほかに /usr/news にもファイルにも送出する権限を付与するには、WRITE オプションに次の値を指定します。


WRITE=/var/spool/uucppublic:/usr/news 

パス名はデフォルトのリストに追加されるものではないので、READ オプションと WRITE オプションを使用するときはすべてのパス名を指定する必要があります。たとえば、WRITE オプションでパス名として /usr/news しか指定しなかったとすると、公共ディレクトリにファイルを送出する権限は失われます。

リモートシステムがどのディレクトリに読み書きのアクセスができるかは、注意して決定しなければなりません。たとえば、/etc ディレクトリには多数の重要なシステムファイルが入っているので、このディレクトリにファイルを送出する権限はリモートユーザーには付与しない方が賢明です。

NOREAD オプションと NOWRITE オプション

NOREAD オプションと NOWRITE オプションは、READ オプションと WRITE オプションおよびデフォルトに対する例外を指定します。たとえば次のようなエントリを指定したとします。


READ=/ NOREAD=/etc WRITE=/var/spool/uucppublic 

これは、/etc ディレクトリ (およびこの下の各サブディレクトリ。このパス名は接頭辞であることを忘れないでください) の中のファイルを除くすべてのファイルの読み取りを許可しています。デフォルトの /var/spool/uucppublic ディレクトリへの書き込みだけを許可しています。NOWRITENOREAD オプションと同じ形で働きます。NOREAD オプションと NOWRITE オプションは、LOGNAME エントリと MACHINE エントリのどちらにも使用できます。

CALLBACK オプション

LOGNAME エントリの中で CALLBACK オプションを使うと、呼び出し側システムがコールバックするまで、トランザクションをいっさい行わないことを指定できます。CALLBACK を設定する理由は 2 つあります。1 つはセキュリティを目的とするもので、マシンをコールバックすることで、それが正しいマシンであることを確認できます。 もう 1 つは課金を目的とするもので、大量のデータの伝送を行うときに、その長時間の呼び出しの料金を課すマシンを選択できます。

文字列 CALLBACK=yes は、ファイル転送を行う前に、ローカルコンピュータがリモートコンピュータをコールバックしなければならないということを指定します。

CALLBACK オプションのデフォルトは CALLBACK=no です。CALLBACKyes に設定する場合は、呼び出し側に対応する MACHINE エントリの中で、以後の通信に影響を与えるアクセス権を指定する必要があります。これらのアクセス権は、LOGNAME の中で指定してはいけません。また同様に、リモートマシンがローカルホストについて設定した LOGNAME エントリの中で指定してもいけません。


注 -

2 つのサイトが互いに CALLBACK オプションを設定すると、通信が開始されないので注意してください。


COMMANDS オプション


注意 - 注意 -

COMMANDS オプションは、システムのセキュリティを低下させる恐れがあります。このオプションは十分に注意して使用してください。


COMMANDS オプションは、リモートコンピュータがローカルコンピュータ上で実行できるコマンドを指定するために、MACHINE エントリの中で使用できます。uux プログラムは、リモート実行要求を生成し、それらの要求をリモートコンピュータに転送するためにキューに入れます。ファイルとコマンドはターゲットコンピュータに送られて、リモート実行されます。MACHINE エントリは、ローカルシステムが呼び出しを行う場合に限り適用されるという規則がありますが、このオプションは例外です。

COMMANDSLOGNAME エントリの中では使えないという点に注意してください。MACHINE エントリの中の COMMANDS は、ローカルシステムがリモートシステムを呼び出すのか、リモートシステムがローカルシステムを呼び出すのかに関係なく、コマンド権限を定義します。

リモートコンピュータがローカルコンピュータ上で実行できるデフォルトのコマンドは、文字列 COMMANDS=rmail となります。MACHINE エントリの中で COMMANDS=rmail 文字列を使用した場合は、デフォルトのコマンドは無効化されます。たとえば次のようなエントリを指定したとします。


MACHINE=owl:raven:hawk:dove COMMANDS=rmail:rnews:lp 

これは、COMMANDS のデフォルトを無効にして、owlravenhawkdove という名前の各コンピュータが、rmailrnewslp をローカルコンピュータで実行できるようにします。

上記で指定した名前に加えて、コマンドのフルパス名も指定できます。たとえば次のように入力します。


COMMANDS=rmail:/usr/local/rnews:/usr/local/lp 

これは、rmail コマンドがデフォルトの検索パスを使用することを指定しています。UUCP のデフォルトの検索パスは、/bin/usr/bin です。リモートコンピュータが、実行するコマンドとして rnews または /usr/local/rnews を指定した場合は、デフォルトのパスに関係なく /usr/local/rnews が実行されます。同様に、実行される lp コマンドは /usr/local/lp です。

リストに ALL という値を含めると、エントリに指定されたリモートコンピュータから、すべてのコマンドが実行できます。この値を使用した場合は、リモートコンピュータにローカルマシンへのフルアクセスを与えることになります。


注意 - 注意 -

これは、通常のユーザーが持っているよりもはるかに多くのアクセス権を与えることになります。この値を使用するのは、両方のマシンが同じサイトにあり、緊密に接続されていて、ユーザーが信頼できる場合に限定するようにしてください。


次の文字列を指定したとします。


COMMANDS=/usr/local/rnews:ALL:/usr/local/lp 

これは次の 2 点を示しています。

COMMANDS オプションで catuucp などのように、潜在的な危険性のあるコマンドを指定するときは、VALIDATE オプションを使用するようにしてください。UUCP リモート実行デーモン (uuxqt) により実行する場合、ファイルを読み書きをするコマンドは、どれもローカルセキュリティにとって危険性のあるものとなります。

VALIDATE オプション

VALIDATE コマンドは、マシンのセキュリティにとって危険性があると考えられるコマンドを指定するときに、COMMANDS オプションといっしょに使用します (VALIDATE は、コマンドアクセスを開放する方法としては ALL より安全ですが、COMMANDS オプションのセキュリティのレベルを補強するだけのものです)。

VALIDATE は、呼び出し側マシンのホスト名と、そのマシンが使用しているログイン名とを相互にチェックするものであり、呼び出し側の識別情報について、ある程度の検証機能を備えています。次のような文字列を指定したとします。


LOGNAME=Uwidget VALIDATE=widget:gadget 

この例では、widget または gadget 以外のマシンが Uwidget としてログインしようとすると、接続は拒否されます。VALIDATE オプションを使用する場合、権限が与えられたコンピュータは UUCP トランザクション用に固有のログインとパスワードを持っていなければなりません。この認証処理では、このエントリに対応するログインとパスワードを保護することが重要な条件の 1 つです。部外者がこの情報を入手してしまうと、VALIDATE オプションはセキュリティに関する役割をまったく果たさなくなります。

UUCP トランザクションについて、特権を持つログインとパスワードをどのリモートコンピュータに付与するかについては、十分に検討する必要があります。ファイルアクセスとリモート実行の権限をリモートコンピュータに与えるということは、そのリモートコンピュータのすべてのユーザーに対して、ローカルコンピュータに対する通常のログインとパスワードを与えるのと同じことです。したがって、リモートコンピュータに信頼の置けないユーザーがいると判断した場合は、そのコンピュータには特権的なログインとパスワードは付与しないようにしてください。

次のような LOGNAME エントリを指定したとします。


LOGNAME=uucpfriend VALIDATE=eagle:owl:hawk 

この例では、リモートコンピュータが eagleowlhawk のどれかとしてローカルコンピュータにログインする場合は、そのコンピュータはログイン uucpfriend を使用する必要があります。部外者が uucpfriend を入手したとすれば、簡単に偽装することができます。

それでは、MACHINE エントリの中でだけ使われる COMMANDS オプションに対して、このオプションはどのような効果を持つのでしょうか。 このオプションは、MACHINE エントリ (および COMMANDS オプション) を、特権ログインに対応する LOGNAME エントリにリンクします。このリンクが必要なのは、リモートコンピュータがログインしている時点では、実行デーモンはまだ動作していないためです。事実、このデーモンは、どのコンピュータが実行要求を送ったのかを認識しない非同期プロセスです。ここで問題になるのが、実行ファイルがどこから送られてきたのかを、ローカルコンピュータがどのようにして知るかという点です。

各リモートコンピュータは、ローカルマシン上にそれぞれ専用スプールディレクトリを持っています。これらのスプールディレクトリの書き込み権限は、UUCP プログラムだけに与えられています。リモートコンピュータからの実行ファイルは、ローカルコンピュータに転送された後に、このスプールディレクトリに入れられます。uuxqt デーモンが動作するときには、スプールディレクトリ名を使って、Permissions ファイルから MACHINE エントリを見つけ、COMMANDS リストを取得します。Permissions ファイル内に該当するコンピュータ名が見つからない場合は、デフォルトのリストが使用されます。

次の例は、MACHINE エントリと LOGNAME エントリの関係を示しています。

MACHINE=eagle:owl:hawk REQUEST=yes ¥
COMMANDS=rmail:/usr/local/rnews ¥
READ=/ WRITE=/
LOGNAME=uucpz VALIDATE=eagle:owl:hawk ¥
REQUEST=yes SENDFILES=yes ¥
READ=/ WRITE=/ 

COMMANDS オプションの値は、リモートユーザーが、rmail/usr/local/rnews を実行できることを示しています。

最初のエントリでは、リストされているコンピュータのどれかを呼び出したい場合に、実際には eagleowlhawk のどれかを呼び出すということを理解しておく必要があります。したがって、eagleowlhawk のスプールディレクトリに置かれるファイルはすべて、それらのコンピュータのどれかが投入したことになります。あるリモートコンピュータがログインし、この 3 つのコンピュータのどれかであることを主張した場合、その実行ファイルもこの特権スプールディレクトリに入れられます。したがって、ローカルコンピュータでは、そのコンピュータが特権ログイン uucpz を持っていることを確認する必要があります。

OTHER 用の MACHINE エントリ

特定の MACHINE エントリに記述されていないリモートマシンについて、異なるオプション値を指定したい場合があります。これが必要になるのは、多数のコンピュータがローカルホストを呼び出し、コマンドセットがそのたびに異なるような場合です。次の例に示すように、このようなエントリでは、コンピュータ名として OTHER という名前を使用します。


MACHINE=OTHER ¥
COMMANDS=rmail:rnews:/usr/local/Photo:/usr/local/xp 

他の MACHINE エントリに記述されていないコンピュータについても、MACHINE エントリに使用できるすべてのオプションを設定できます。

MACHINELOGNAME の結合

MACHINE エントリと LOGNAME エントリを結合して、同じ共通オプションを持つ単一のエントリにすることができます。たとえば、次の 2 つのエントリがあるとします。


MACHINE=eagle:owl:hawk REQUEST=yes ¥
READ=/ WRITE=/


LOGNAME=uupz REQUEST=yes SENDFILES=yes ¥
READ=/ WRITE=/

これらは、同じ REQUESTREADWRITE オプションを共有しています。この 2 つを組み合わせると次のようになります。


MACHINE=eagle:owl:hawk REQUEST=yes ¥
logname=uucpz SENDFILES-yes ¥
READ=/ WRITE=/

MACHINE エントリと LOGNAME エントリを結合することによって、Permissions ファイルは、効率的で管理しやすくなります。

転送

一連のマシンを介してファイルを送信するときは、中継マシンの COMMANDS オプションの中に uucp コマンドが含まれていなければなりません。たとえば次のコマンドを入力したとします。


% uucp sample.txt oak¥!willow¥!pine¥!/usr/spool/uucppublic

この転送操作が正常に機能するためには、マシン willowoak に対して uucp プログラムの実行を許可し、oak がローカルマシンに同じことを許可している必要があります。最終宛先マシンである pine は、uucp コマンドを許可する必要はありません。通常、マシンはこのように設定されていません。

/etc/uucp/Poll ファイル

/etc/uucp/Poll ファイルには、リモートコンピュータをポーリングするための情報が入っています。Poll ファイル内の各エントリには、呼び出すリモートコンピュータの名前と、それに続くタブ文字またはスペース、最後にそのコンピュータを呼び出す時刻が入ります。Poll ファイル内のエントリの形式は次のとおりです。

sys-name hour ...

たとえば次のようなエントリを指定したとします。


eagle 0 4 8 12 16 20 

これは、コンピュータ eagle を 4 時間おきにポーリングします。

uudemon.poll スクリプトは Poll ファイルを処理しますが、実際にポーリングを行うわけではありません。これは単にスプールディレクトリ内にポーリング作業ファイル (名前は常に C.file) を設定するだけです。uudemon.poll スクリプトはスケジューラを起動し、スケジューラは、スプールディレクトリ内のすべての作業ファイルを調べます。

/etc/uucp/Config ファイル

/etc/uucp/Config ファイルを使用すると、いくつかのパラメータを手動で上書きできます。Config ファイルの各エントリの形式は次のとおりです。

parameter=value

構成可能な全パラメータ名のリストについては、システムに付属している Config ファイルを参照してください。

次の Config ントリは、デフォルトのプロトコル順序を Gge に設定し、G プロトコルのデフォルト値を、ウィンドウ数 7、パケットサイズ 512 バイトに変更します。


Protocol=G(7,512)ge

/etc/uucp/Grades ファイル

/etc/uucp/Grades ファイルには、リモートコンピュータへのジョブをキューに入れるときに指定できるジョブグレードが入っています。また、個々のジョブグレードに関するアクセス権も含まれています。このファイルのエントリは、ユーザーがジョブをキューに入れるときに使用する、管理者が定義したジョブグレードの定義を表しています。

Grades ファイルのエントリの形式は次のとおりです。

User-job-grade System-job-grade Job-size Permit-type ID-list

各エントリには、スペースで区切ったいくつかのフィールドがあります。エントリの最後のフィールドは、同じくスペースで区切ったいくつかのサブフィールドから構成されます。1 つのエントリが複数の物理行にわたる場合は、バックスラッシュを使って、エントリを次の行に継続させることができます。コメント行はポンド記号 (#) で始まり、その行の全体を占めます。空の行は常に無視されます。

User-job-grade フィールド

このフィールドには、管理者が 64 文字以内で定義したユーザージョブのグレード名が入ります。

System-job-grade フィールド

このフィールドには、User-job-grade が対応付けされる 1 文字のジョブグレードが入ります。有効な文字は A 〜 Z、a 〜 z で、最も優先順位が高いのは A、最も優先順位が低いのは z です。

ユーザージョブグレードとシステムジョブグレードの関係

ユーザージョブグレードは複数のシステムジョブグレードに割り当てることができます。ここで重要なのは、Grades ファイルは、ユーザージョブグレードのエントリを見つけるために先頭から検索されるという点です。したがって、最大ジョブサイズの制限値に応じて、複数のシステムジョブグレードのエントリが列挙されます。

ユーザージョブグレードの最大数には制限はありませんが、システムジョブグレードの許容最大数は 52 です。その理由は、1 つの System-job-grade には複数の User-job-grade を対応付けできるが、個々の User-job-grade はファイル内でそれぞれ単独の行でなければならないという点にあります。次に例を示します。


mail N Any User Any netnews N Any User Any 

Grades ファイル内でこのような構成をした場合、2 つの User-job-grade が同じ System-job-grade を共有します。ジョブグレードに関するアクセス権は、System-job-grade ではなく User-job-grade に割り当てられるものなので、2 つの User-job-grade は同じ System-job-grade を共有しながら、それぞれ異なるアクセス権のセットを持つことができます。

デフォルトグレード

デフォルトのユーザージョブグレードとして、システムジョブグレードを割り当てることができます。そのためには、Grades ファイルの User-job-grade フィールドのユーザージョブグレードとしてキーワード default を使用し、そのデフォルトに割り当てるシステムジョブグレードを指定します。Restrictions フィールドと ID フィールドは Any と定義して、どのようなユーザー、どのようなサイズのジョブでも、このグレードでキューに入れることができるようにします。次に例を示します。


default a Any User Any 

デフォルトのユーザージョブグレードを定義しなかった場合は、組み込まれているデフォルトグレードである Z が使用されます。Restriction フィールドのデフォルトは Any なので、デフォルトグレードのエントリが複数存在していても検査されません。

Job-size フィールド

このフィールドは、キューに入れることのできる最大ジョブサイズを指定します。Job-size はバイト数で表され、表 12-8 に示すオプションを使用できます。

表 12-8 Job-size フィールド

nnnn

このジョブグレードの最大ジョブサイズを指定する整数 

nK

キロバイト数を表す 10 進数 (K はキロバイトの略号)

nM

メガバイト数を表す 10 進数 (M はメガバイトの略号)

Any

最大ジョブサイズが指定されないことを指定するキーワード 

次に例をいくつか示します。

Permit-type フィールド

このフィールドには、ID リストをどのように解釈するかを指示するキーワードを指定します。表 12-9 に、キーワードとそれぞれの意味を示します。

表 12-9 Permit-type フィールド

キーワード 

ID リストの内容 

User

このジョブグレードの使用を許可されているユーザーのログイン名 

Non-user

このジョブグレードの使用を許可されていないユーザーのログイン名 

Group

このジョブグレードの使用を許可されているメンバのグループ名 

Non-group

このジョブグレードの使用を許可されていないメンバのグループ名 

ID-list フィールド

このフィールドには、このジョブグレードへのキューイングが許可、禁止されるログイン名またはグループ名のリストが入ります。名前のリストはそれぞれスペースで区切り、改行文字で終了します。このジョブグレードへのキューイングを誰にでも許可する場合は、キーワード Any を使用します。

その他の UUCP 構成ファイル

この節では、UUCP の機能に影響を与えるファイルのうち、比較的変更頻度の低い 3 つのファイルについて説明します。

/etc/uucp/Devconfig ファイル

/etc/uucp/Devconfig ファイルを使用すると、サービス別、つまり uucp 用と cu 用とに分けて、デバイスを構成できます。Devconfig のエントリは、個々のデバイスで使用される STREAMS モジュールを定義します。エントリの形式は次のとおりです。

service=x device=y push=z[:z...]

x は、cuuucico、またはその両方をコロンで区切ったものです。y はネットワークの名前で、これは Devices ファイルのエントリに一致していなければなりません。z には、STREAMS モジュールの名前を、Stream にプッシュする順序で指定します。cu サービスと uucp サービスについて、それぞれ異なるモジュールとデバイスを定義できます。

次のエントリは STARLAN ネットワーク用のもので、このファイル内で最もよく使われるものです。


service=cu       device=STARLAN     push=ntty:tirdwr
service=uucico   device=STARLAN     push=ntty:tirdwr 

この例では、まず ntty、次に tirdwr がプッシュされます。

/etc/uucp/Limits ファイル

/etc/uucp/Limits ファイルは、uucp ネットワーク処理で同時に実行できる uucicouuxqtuusched の最大数を制御します。ほとんどの場合は、デフォルトの値が最適であり、変更の必要はありません。変更したい場合は、任意のテキストエディタを使用してください。

Limits ファイルの形式は次のとおりです。

service=x max=y:

xuucicouuxqtuusched のどれかで、y はそのサービスについての制限値です。フィールドは、小文字を使って任意の順序で入力できます。

次に示すのは、Limits ファイルの中で一般的に使われる内容です。


service=uucico max=5
service=uuxqt max=5
service=uusched max=2 

この例は、5 つの uucico、5 つの uuxqt、2 つの uusched を、マシンで実行できることを示しています。

remote.unknown ファイル

通信機能の使用に影響を与えるファイルとして、もう 1 つ、remote.unknown ファイルがあります。このファイルは、どの Systems ファイルにも含まれていないマシンが通信を開始したときに実行されるバイナリプログラムです。このプログラムはその通信をログに記録し、接続を切断します。


注意 - 注意 -

remote.unknown ファイルのアクセス権を変更して、このプログラムが実行できないようにすると、ローカルシステムはどのシステムからの接続も受け入れることになります。


このプログラムが実行されるのは、どの Systems ファイルにも含まれていないマシンが対話を開始した場合です。このプログラムは、その対話を記録し、接続を失敗させます。このファイルのアクセス権を変更して実行できないようにしてしまうと (chmod 000 remote.unknown)、ローカルシステムはすべての通信要求を受け入れることになります。妥当な理由がない限り、この変更は行わないようにしてください。

管理ファイル

以下、UUCP 管理ファイルについて説明します。これらのファイルは、デバイスのロック、一時データの保管、リモート転送や実行に関する情報の保存などのために、スプールディレクトリ内に作成されます。

表 12-10 UUCP ロックファイル

ファイル名 

説明 

LCK..sys

sys はファイルを使用しているコンピュータの名前を表す

LCK.dev

dev はファイルを使用しているデバイスの名前を表す

LCK.LOG

LOG はロックされている UUCP ログファイルを表す

通信リンクが予定外のときに切断された場合 (通常コンピュータがクラッシュしたとき)、これらのファイルがスプールディレクトリ内に残ることがあります。親プロセスが有効でなくなった後は、ロックファイルは無視 (削除) されます。ロックファイルには、ロックを引き起こしたプロセスのプロセス ID が入っています。

第 13 章 UUCP の構成と保守

この章では、マシンに関連したデータベースファイルを変更した後で、UUCP 操作を起動する方法について説明します。この章には、Solaris 環境が動作するマシンで UUCP を構成し保守するための、手順と障害の解明についての情報が記載されています。

UUCP のログインの追加

リモートマシンからの UUCP (uucico) 着信要求が正しく取り扱われるように、各リモートマシンはローカルシステム上にログインを持っていなければなりません。

UUCP 接続を介してローカルシステムにアクセスすることを許可されているリモートマシンについては、次の例に示すようなエントリを /etc/passwd ファイルに入力します。


Ugobi:*:5:5:gobi:/var/spool/uucppublic:/usr/lib/uucp/uucico 

リモートマシンのログイン名は慣例的に、そのマシン名の前に大文字の U を付けたものです。8 文字を超える名前は使用できないので、一部を短縮した名前や省略名を使用しなければならない場合もあります。

上記のエントリは、Ugobi からのログイン要求に /usr/lib/uucp/uucico が応答することを示しています。ホームディレクトリは /var/spool/uucppublic です。パスワードは /etc/shadow ファイルから取得されます。パスワードとログイン名は、リモートマシンの UUCP 管理者と協議して決める必要があります。リモート側の管理者は、ログイン名と暗号化されていないパスワードを含む正しいエントリを、リモートマシンの Systems ファイルに追加する必要があります。

同様に、ローカルマシンの管理者も、ローカルマシンの名前とパスワードについて、UUCP を介して通信する相手方のすべてのマシンの UUCP 管理者と協議する必要があります。

UUCP の起動

UUCP には、次に示す 4 つのシェルスクリプトが付属しています。これらのスクリプトは、リモートマシンをポーリングし、転送を再スケジュールし、古いログファイルと成功しなかった転送を処理します。

UUCP を円滑に運用するには、これらのスクリプトを定期的に実行する必要があります。Solaris の全体インストールを行なった場合は、これらのスクリプトを実行するための crontab ファイルが、インストールプロセスの一環として自動的に /usr/lib/uucp/uudemon.crontab の中に作成されます。全体インストールでない場合は、UUCP パッケージをインストールするときにこのファイルが作成されます。

UUCP シェルスクリプトは手動でも実行できます。次に示すのは、uudemon.crontab のプロトタイプです。このファイルは、マシンの運用の都合に合わせて適宜変更することができます。


#
#ident  "@(#)uudemon.crontab    1.5     97/12/09 SMI"
#
# This crontab is provided as a sample. For systems
# running UUCP edit the time schedule to suit, uncomment 
# the following lines, and use crontab(1) to activate the
# new schedule.
#
#48 8,12,16 * * * /usr/lib/uucp/uudemon.admin
#20 3 * * * /usr/lib/uucp/uudemon.cleanup
#0 * * * * /usr/lib/uucp/uudemon.poll
#11,41 * * * * /usr/lib/uucp/uudemon.hour

注 -

デフォルトでは、UUCP の操作は無効にされています。UUCP を有効にするには、タイムスケジュールを編集し、ファイル uudemon.crontab の適切な行のコメントを解除してください。


uudemon.crontab ファイルを有効にするには、スーパーユーザーになって次のように入力します。


# su uucp
# crontab < /usr/lib/uucp/uudemon.crontab

uudemon.poll シェルスクリプト

デフォルトの uudemon.poll シェルスクリプトは、1 時間に 1 回 /etc/uucp/Poll ファイルを読み取ります。Poll ファイル内のマシンのどれかに対するポーリングがスケジュールされると、作業ファイル (C.sysnxxxx) が /var/spool/uucp/nodename ディレクトリに入れられます。nodename は、そのマシンの UUCP ノード名です。

このシェルスクリプトは、1 時間に 1 回ずつ uudemon.hour の前に実行されるようにスケジュールされているので、uudemon.hour が呼び出されたときには、作業ファイルが存在しています。

uudemon.hour シェルスクリプト

デフォルトの uudemon.hour シェルスクリプトは次のことを行います。

デフォルトでは、uudemon.hour は 1 時間に 2 回実行されます。リモートマシンへの呼び出しの失敗の頻度が高いと予測される場合は、このスクリプトの実行頻度を増やすこともできます。

uudemon.admin シェルスクリプト

デフォルトの uudemon.admin シェルスクリプトは次のことを行います。

  1. p オプションと q オプション付きで uustat コマンドを実行する。q は、キューに入っている作業ファイル (C.)、データファイル (D.)、実行ファイル (X.) の状態を報告する。p は、ロックファイル (/var/spool/locks) 中に列挙されているネットワークプロセス用のプロセス情報を表示する

  2. 結果の状態情報を、メールにより uucp 管理ログインに送る

uudemon.cleanup シェルスクリプト

デフォルトの uudemon.cleanup シェルスクリプトは次のことを行います。

  1. /var/uucp/.Log ディレクトリから個々のマシンに関するログファイルを取り出し、それらをマージし、他の古いログ情報とともに /var/uucp/.Old ディレクトリに入れる

  2. 7 日以上経過している作業ファイル (C.)、7 日以上経過しているデータファイル (D.)、2 日以上経過している実行ファイル (X.) を、スプールファイルから削除する

  3. 配達できなかったメールを送信元に戻す

  4. その日に収集した状態情報の要約を、メールにより UUCP 管理ログイン (uucp) に送る

TCP/IP を介した UUCP の実行

/etc/inetd.conf 中で UUCP を有効にする

TCP/IP ネットワーク上での UUCP を実行するには、この節で説明するようにいくつかの変更が必要になります。

/etc/inetd.conf の中で、次のエントリの前にコメントマーク (#) が付いていないことを確認します。


uucp stream tcp nowait root /usr/sbin/in.uucpd in.uucpd 

TCP/IP 用に Systems ファイルエントリを修正する

/etc/uucp/Systems ファイルのエントリには、次のフィールドがあります。

System-Name Time TCP Port networkname Standard-Login-Chat

典型的なエントリは次のようになります。


rochester Any TCP - ur-seneca login: Umachine password: xxx

networkname フィールドには、TCP/IP ホスト名を明示的に指定できます。これは、一部のサイトにとっては重要な点です。上の例に示したサイトの UUCP ノード名 rochester は、TCP/IP ホスト名 ur-seneca と違っています。rochester という TCP/IP ホスト名を持ち、UUCP を実行する別のマシンがあっても問題はありません。

Systems ファイル内の Port フィールドには - を指定します。これは、uucp と指定するのと同じです。ほとんどの場合、networkname はシステム名と同じで、Port フィールドは - となります。これは、services データベースから標準 uucp ポートを使用することを意味します。in.uucpd デーモンは、認証のためにリモートマシンがログインとパスワードを送ることを想定しているので、gettylogin と同様に、ログインとパスワードを要求します。

UUCP のための /etc/inet/services の検査

次に示す /etc/inet/services のエントリは、UUCP 用のポートを設定します。


uucp 540/tcp uucpd # uucp daemon

このエントリを変更する必要はありません。しかし、マシンがネームサービスとして NIS または NIS+ を実行する場合は、/etc/services/etc/nsswitch.conf エントリを変更して、まず files、次に nis または nisplus が検査されるようにする必要があります。

セキュリティ、保守、障害追跡

UUCP の設定が終われば、その後の保守は簡単です。この節では、セキュリティ、保守、障害追跡に関連する UUCP の作業について説明します。

UUCP のセキュリティの設定

デフォルトの /etc/uucp/Permissions ファイルは、UUCP リンクに関する最大限のセキュリティを提供します。デフォルトの Permissions ファイルには、エントリは入っていません。

定義する各マシンについて、以下に示す追加パラメータを設定できます。

典型的な Permissions のエントリは次のようになります。


MACHINE=datsun LOGNAME=Udatsun VALIDATE=datsun
COMMANDS=rmail REQUEST=yes SENDFILES=yes

このエントリでは、(システム内のどこかからではなく、通常の UUCP ディレクトリとの間での) ファイルの送信と受信が可能となり、ログイン時に UUCP ユーザー名の認証が行われます。

日常の UUCP の保守

UUCP の保守に必要な作業の量はさほど多くはありません。uudemon.poll シェルスクリプト」で述べたように、crontab ファイルを正しい場所に配置してあることを確認する以外に注意する必要があるのは、メールファイルと公共ディレクトリが大きくなるという点だけです。

UUCP に関連する電子メール

UUCP のプログラムとスクリプトが生成する電子メールメッセージは、すべてユーザー ID uucp に送られます。管理者がユーザー uucp として頻繁にログインしていないと、メールが蓄積されている (このためディスク空間を浪費している) ことに気付かない場合があります。この問題を解決するには、/etc/aliases の中に別名を 1 つ作り、root か自分自身、そして他の UUCP 保守責任者に、電子メールをリダイレクトします。aliases ファイルを変更した後で、newaliases コマンドを実行するのを忘れないようにしてください。

公共ディレクトリ

ディレクトリ /var/spool/uucppublic は、UUCP がデフォルトでファイルをコピーできる場所として、すべてのシステムに対して提供されているディレクトリです。すべてのユーザーが、/var/spool/uucppublic への移動、その中のファイルの読み書きを行う権限を持っています。しかし、スティッキビットが設定されているため、このディレクトリのモードは 01777 です。したがって、ユーザーには、このディレクトリにコピーされ uucp に所有されているファイルを削除することはできません。このディレクトリからファイルを削除できるのは、root または uucp としてログインした UUCP 管理者だけです。このディレクトリ内に無秩序にファイルが蓄積するのを防ぐために、定期的に整理する必要があります。

このような定期的な整理がユーザーにとって面倒な場合は、スティッキビットを削除するよりも、各ユーザーに uutouupick を使用するよう奨励してください。スティッキビットはセキュリティのために設定されています (uutouupick の使い方については、uuto(1C) のマニュアルページを参照してください)。このディレクトリのモードの制限の度合を強めて、たとえば特定のユーザーグループだけに使用を限定することもできます。だれかがディスク空間を使い切ってしまうことが望ましくないのであれば、そのディスクへの UUCP アクセスを拒否することもできます。

UUCP の障害追跡

ここでは、UUCP に関する一般的な問題を解決するための手順について説明します。

障害のあるモデムや ACU の検査

モデムや ACU で、適正に動作していないものがないかどうかを、いくつかの方法で検査できます。

/etc/uucp/Systems ファイルの検査

特定のマシンと接続しようとすると障害が発生する場合は、Systems ファイルの中の情報が最新のものであるかどうかを確認してください。次のようなマシンに関する情報が、最新でなくなっている可能性があります。

伝送のデバッグ

特定のマシンに接続できない場合は、Uutryuucp を使って、そのマシンに対する通信を検査できます。

  1. 接続を調べるために、/usr/lib/uucp/Uutry -r machine を入力し、Return を押します。

    machine には、接続に問題のあるマシンのホスト名を指定します。このコマンドは次のことを行います。

    1. デバッグ機能を指定して転送デーモン (uucico) を起動する。root としてログインしていれば、さらに多くのデバッグ情報が得られます。

    2. デバッグ出力を /tmp/machine に送る。

    3. デバッグ出力を端末に表示する (tail -f).

      出力を終了するには Control-c を押します。この出力を保存したい場合は、/tmp/machine から出力内容をコピーします。

  2. Uutry を使っても問題の原因が分からない場合は、 uucp -r file machine¥!/dir/file と入力し Return キーを押すことによって、ジョブをキューに入れてみます。

    file には転送したいファイル、machine には転送先のマシンを指定します。/dir/file には、相手のマシンのどこにファイルを転送するかを指定します。r オプションを指定すると、ジョブはキューに入りますが、転送は開始されません。

  3. ここで、再度 Uutry を使用します。

    それでも問題が解決できないときは、ご購入先への連絡が必要になります。デバッグ出力を保存しておいてください。これは問題の診断に役立ちます。

Uutry-x n オプションを使用して、デバッグのレベルを増減することも考えてみてください。n はデバッグレベルを指定します。Uutry のデフォルトのデバッグレベルは 5 です。

デバッグレベル 3 では、接続がいつどのように確立されたかについての基本的な情報は提供されますが、転送自体について提供される情報は多くはありません。これに対して、デバッグレベル 9 では、転送処理に関するすべての情報が網羅されます。デバッグは転送の両端で行われるという点に注意してください。比較的大きいテキストについて 5 より高いレベルのデバッグを行いたい場合は、相手サイトの管理者に連絡して、デバッグを行う時期について同意を得てください。

エラーメッセージの検査

UUCP のエラーメッセージには、ASSERTSTATUS の 2 つの種類があります。

プロセスがアボートされた場合は、ASSERT メッセージが /var/uucp/.Admin/errors に記録されます。この種類のメッセージには、ファイル名、sccsid、回線番号、テキストが含まれています。この種類のメッセージが出るのは、一般にシステムに問題がある場合です。

STATUS エラーメッセージは /var/uucp/.Status ディレクトリに格納されます。このディレクトリ内には、ローカルコンピュータが通信しようとした各リモートマシンについて、それぞれファイルが作られます。これらのファイルには、試行した通信と、その通信が成功したかどうかについての状態情報が入っています。

基本情報の検査

以下のコマンドを使用して、基本的なネットワーク情報を検査するために使用できます。

UUCP のエラーメッセージ

この節には、UUCP に関連したエラーメッセージを示します。

UUCP の ASSERT エラーメッセージ

表 13-1 に ASSERT エラーメッセージをリストします。

表 13-1 ASSERT エラーメッセージ

エラーメッセージ 

説明と処置  

CAN'T OPEN

open() または fopen() が失敗した 。

CAN'T WRITE

write()fwrite()fprint()、または類似のコマンドが失敗した 。

CAN'T READ

read()fgets()、または類似のコマンドが失敗した。

CAN'T CREATE

creat() 呼び出しが失敗した。

CAN'T ALLOCATE

動的割り当てが失敗した 。 

CAN'T LOCK

LCK (ロック) ファイルを作成しようとしたが失敗した。場合によっては、これは重大なエラーとなる。

CAN'T STAT

stat() 呼び出しが失敗した 。

CAN'T CHMOD

chmod() 呼び出しが失敗した 。

CAN'T LINK

link() 呼び出しが失敗した 。

CAN'T CHDIR

chdir() 呼び出しが失敗した 。

CAN'T UNLINK

unlink() 呼び出しが失敗した 。

WRONG ROLE

内部ロジックの問題 。 

CAN'T MOVE TO CORRUPTDIR

不良な C. ファイルまたは X. ファイルを、/var/spool/uucp/.Corrupt ディレクトリに移動しようとしたが、失敗した。このディレクトリが存在しないか、モードまたは所有者が正しくない。

CAN'T CLOSE

close() または fclose() 呼び出しが失敗した 。

FILE EXISTS

C. ファイルまたは D. ファイルを作成しようとしたが、そのファイルがすでに存在している。これが起こるのは、シーケンスファイルのアクセスに問題がある場合である。これは一般にソフトウェアエラーを示す。

NO uucp SERVICE NUMBER

TCP/IP 呼び出しを試みたが、/etc/services 内に UUCP に関するエントリがない。

BAD UID

ユーザー ID がパスワードデータベース内にない。ネームサービス構成の検査が必要。 

BAD LOGIN_UID

前記と同じ 。 

BAD LINE

Devices ファイル内に不良な行がある。引数が足りない行が 1 つ以上ある。

SYSLST OVERFLOW

gename.c の内部テーブルがオーバーフローした。1 つのジョブが 30 を超えるシステムに接続しようとした。

TOO MANY SAVED C FILES

前記と同じ 。 

RETURN FROM fixline ioctl

失敗するはずのない ioctl(2) が失敗した。システムドライバに問題がある。

BAD SPEED

Devices ファイルまたは Systems ファイルの中に不適正な回線速度がある (Class フィールドまたは Speed フィールド)。

BAD OPTION

Permissions ファイルの中に不適正な行またはオプションがある。ただちに修正が必要。

PKCGET READ

おそらくリモートマシンがハングアップした。処置は不要。 

PKXSTART

リモートマシンが回復不可能な状態でアボートした。通常これは無視できる。 

TOO MANY LOCKS

内部的な問題がある (システムのご購入先にお問い合わせください)。 

XMV ERROR

ファイルまたはディレクトリのどれかに問題がある。この処理の試行の前に宛先のモードが検査されていると考えられるので、スプールディレクトリに問題がある可能性が高い。 

CAN'T FORK

forkexec を実行しようとしたが失敗した。現行ジョブは失われず、後で再試行される (uuxqt)。処置は不要。

UUCP の STATUS エラーメッセージ

表 13-2 に一般的な STATUS エラーメッセージを示します。

表 13-2 UUCP の STATUS エラーメッセージ

エラーメッセージ 

説明と処置 

OK

状態は良好。 

NO DEVICES AVAILABLE

現在この呼び出し用に使用可能なデバイスがない。 該当のシステムについて Devices ファイル内に有効なデバイスがあるかどうかを確認してください。そのシステムの呼び出しに使用するデバイスが Systems ファイル内にあるかどうかを検査してください。

WRONG TIME TO CALL

Systems ファイルに指定されている日時以外の時点で、システムに対する呼び出しが行われた。

TALKING

会話中。 

LOGIN FAILED

特定のマシンのログインが失敗した。ログインまたはパスワードが正しくないか、番号が正しくないか、きわめて低速のマシンであるか、Dialer-Token-Pairs スクリプトによる処理が失敗した。 

CONVERSATION FAILED

起動に成功した後で対話が失敗した。一方の側がダウンしたか、プログラムがアボートしたか、回線 (リンク) が切断されたことが考えられる。 

DIAL FAILED

リモートマシンがまったく応答しない。ダイヤラが不良であるか、電話番号が正しくないことが考えられる 。 

BAD LOGIN/MACHINE COMBINATION

あるマシンが、Permissions ファイルの条件を満たしていないログインとマシン名を使って、ローカルマシンを呼び出そうとした。偽装の疑いがある。

DEVICE LOCKED

使用しようとしている呼び出しデバイスは、現在ロックされ、他のプロセスに使用されている。 

ASSERT ERROR

ASSERT エラーが発生した。/var/uucp/.Admin/errors ファイルにエラーメッセージが入っているかどうかを検査し、「UUCP のエラーメッセージ」を参照してください。

SYSTEM NOT IN Systems FILE

システムが Systems ファイルの中に記述されていない。

CAN'T ACCESS DEVICE

アクセスしようとしたデバイスが存在しないか、またはモードが正しくない。Systems ファイルと Devices ファイルの中の該当のエントリを検査してください。

DEVICE FAILED

デバイスがオープンできない 

WRONG MACHINE NAME

呼び出されたマシンは、予期したのとは異なる名前を示している。 

CALLBACK REQUIRED

呼び出されたマシンは、そのマシンがローカルマシンをコールバックする必要があることを示している。 

REMOTE HAS A LCK FILE FOR ME

リモートマシンは、ローカルマシンに関連する LCK ファイルを持っている。そのリモートマシンがローカルマシンを呼び出そうとしている可能性がある。そのマシンの UUCP のバージョンが古い場合は、プロセスがローカルマシンに接続しようとして失敗し、LCK ファイルがそのまま残されたことが考えられる。UUCP のバージョンが新しく、そのマシンがローカルマシンと通信していない場合は、LCK を持っているプロセスはハングする。

REMOTE DOES NOT KNOW ME

リモートマシンの Systems ファイルの中に、ローカルマシンのノード名がない。

REMOTE REJECT AFTER LOGIN

ローカルマシンがログインのために使用したログインが、リモートマシンが予期している内容に一致していない。 

REMOTE REJECT, UNKNOWN MESSAGE

理由は不明だが、リモートマシンがローカルマシンとの通信を拒否した。リモートマシンが標準バージョンの UUCP を使用していないことが考えられる。 

STARTUP FAILED

ログインは成功したが、初期ハンドシェークに失敗した。 

CALLER SCRIPT FAILED

通常、これは DIAL FAILED と同じ。しかしこれが頻発する場合は、Dialers ファイル内の呼び出し側スクリプトに原因があることが考えられる (Uutry を使って検査してください)。

UUCP の数値エラーメッセージ

表 13-3 に、/usr/include/sysexits.h ファイルにより生成されるエラー状態メッセージの終了コード番号を示します。これらのすべてが現在 uucp で使用されているわけではありません。

表 13-3 番号による UUCP のエラーメッセージ

メッセージ番号 

内容 

説明 

64

Base value for error messages 

エラーメッセージはこの番号から始まる。 

64

Command Line Usage Error 

コマンドの使い方に誤りがある。たとえば、引数の数が正しくない、誤ったフラグ、誤った構文など。 

65

Data Format Error 

入力データになんらかの誤りがある。これはユーザーデータだけに使用されるもので、システムファイルには使用されない。 

66

Cannot Open Input 

入力ファイル (システムファイルでない) が存在しないか、または読み取れない。これには、メーラーに対する "No message" のようなエラーも含まれる (この種のエラーが捕捉できるようになっている場合)。 

67

Address Unknown 

指定されたユーザーが存在しない。これは、メールアドレスやリモートログインに使用される。 

68

Host Name Unknown 

ホストが存在しない。これは、メールアドレスやネットワーク要求に使用される。 

69

Service Unavailable 

サービスが使用不可。これは、サポートプログラムまたはファイルが存在しない場合に起こることがある。このメッセージは、何かが正常に働かずその理由が分からない場合の包括的なメッセージでもある。 

70

Internal Software Error 

内部ソフトウェアエラーが検出された。これは、可能な場合は、オペレーティングシステム関係以外のエラーに限定される。 

71

System Error 

オペレーティングシステムエラーが検出された。これは、「フォーク不可」や「パイプ作成不可」などのような状態を示す。たとえば、getuidpasswd ファイル内に存在しないユーザーを戻した場合などが含まれる。

72

Critical OS File Missing 

/etc/passwd/etc/utmp などのシステムファイルのどれかが、存在しないか、オープンできない。あるいは、構文エラーなどのようなエラーがある。

73

Can't Create Output File 

ユーザーが指定した出力ファイルが作成できない。 

74

Input/Output Error 

あるファイルについて入出力を行なっているときにエラーが起こった。 

75

Temporary Failure. User is invited to retry 

一時的な障害。実際のエラーではない何かを示す。たとえば sendmail では、これは、メーラーが接続を確立できなかったため、後で要求を再試行する必要があることなどを意味する。

76

Remote Error in Protocol 

プロトコルの交換中に、リモートシステムが「使用不可」を示す何かを戻した。 

77

Permission Denied 

この操作を行うための適正なアクセス権がユーザーにない。これはファイルシステムの問題を示すものではなく (その場合は NOINPUTCANTCREAT などが使用される)、より高いレベルのアクセス権が必要であることを意味する。たとえば、kre は、メールを送ることのできる学生を制限するために、このメッセージを使用する。

78

Configuration Error 

構成にエラーがある。 

79

Entry Not Found 

エントリが見つからない。 

79

Maximum Listed Value 

エラーメッセージの最大番号。