第 27 章 UUCP リファレンス

この章では、UUCP を使用する場合のリファレンス情報について説明します。次の各項目について説明します。

• 「UUCP /etc/uucp/Systems ファイル」

• 「UUCP /etc/uucp/Devices ファイル」

• 「UCCP /etc/uucp/Dialers ファイル」

• 「その他の基本的な UUCP 構成ファイル」

• 「UUCP /etc/uucp/Permissions ファイル」

• 「UUCP /etc/uucp/Poll ファイル」

• 「UUCP /etc/uucp/Config ファイル」

• 「UUCP /etc/uucp/Grades ファイル」

• 「その他の UUCP 構成ファイル」

• 「UUCP の管理ファイル」

• 「UUCP のエラーメッセージ」

UUCP /etc/uucp/Systems ファイル

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

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

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

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

System-Name

 Time

 Type 

Speed 

Phone  

Chat-Script 

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

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

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

UUCP System-Name フィールド

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

UUCP Time フィールド

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

daytime[;retry]

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

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

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

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

UUCP retry サブフィールド

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

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

UUCP Type フィールド

このフィールドには、リモートコンピュータとの通信リンクを確立するために使用するデバイスタイプを指定します。このフィールドで使用するキーワードは、Devices ファイル中のエントリの最初のフィールドと突き合わされます。

例 27-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

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

UUCP Speed フィールド

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

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

例 27-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

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

UUCP Phone フィールド

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

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

File Name System-Name  Time  Type  Speed  Phone     Chap-Script

Systems   nubian       Any   ACU   2400   NY5551212 ogin: Puucp ssword:Passuan

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

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

UUCP 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 ファイルエントリの例です。

System-Name  Time  Type  Speed  Phone     Chap-Script
sonora Any ACUEC 9600 2223333 "" ¥r ¥r ogin:-BREAK-ogin: Puucpx ssword: xyzzy

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

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

チャットスクリプトを使用したダイヤルバックの有効化

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

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

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

INITIATED¥Hogin:

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

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

UUCP ハードウェアフロー制御

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

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

System-Name  Time  Type  Speed  Phone     Chap-Script
unix Any ACU 2400 12015551212 "" ¥r login:-¥r-login:-¥r-login: 
nuucp password: xxx "" ¥ STTY=crtscts 

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

UUCP パリティの設定

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

System-Name  Time  Type  Speed  Phone     Chap-Script
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 ファイルのエントリの中でも使用できます。

UUCP /etc/uucp/Devices ファイル

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

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

Type   Line  Line2 Class Dialer-Token-Pairs
 ACUEC  cua/a -     38400 usrv32bis-ec

各フィールドについて、次のセクションで説明します。

UUCP Type フィールド

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

キーワード Direct

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

キーワード ACU

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

ポートセレクタ

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

Sys-Name

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

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

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

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

例 27-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....... 

UUCP Line フィールド

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

cua/a,M

UUCP Line2 フィールド

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

UUCP Class フィールド

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

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

Devices ファイルの Class フィールドで使用するキーワードは、Systems ファイルの Speed フィールドと突き合わされます。

例 27-6 UUCP Class フィールド

File Name  Type   Line  Line2  Class  Dialer-Token-Pairs

Devices    ACU    cua/a -      D2400  hayes

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

UUCP 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 ファイル内に該当エントリがなくても使用できます。表 27-3 に、特殊ダイヤラタイプを示します。

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

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

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

• 直接接続モデム

  コンピュータのポートにモデムが直接接続されている場合は、対応する Devices ファイルエントリの DTP フィールドに入るペアは 1 つだけです。このペアは、通常はモデムの名前です。この名前は、Devices ファイルの特定のエントリと、Dialers ファイル内のエントリとを対応付けるために使用されます。したがって、Dialer フィールドは、Dialers ファイルエントリの最初のフィールドに一致している必要があります。

例 27-7 直接接続モデム用 Dialer フィールド

Dialers   hayes =,-,  ""          ¥¥dA¥pTE1V1X1Q0S2=255S12=255¥r¥c 
                                  ¥EATDT¥T¥r¥c CONNECT

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

• 直接リンク - 特定のコンピュータへの直接リンクの場合は、対応するエントリの DTP フィールドには、キーワード direct が入ります。これは、Direct、Sys-Name の両方の直接リンクエントリにもあてはまります (「UUCP Type フィールド」を参照)。

• 同じポートセレクタ上のコンピュータ - 通信したいコンピュータが、ローカルコンピュータと同じポートセレクタスイッチ上にある場合は、ローカルコンピュータはまずそのスイッチにアクセスする必要があります。そのスイッチが、相手のコンピュータとの接続を確立します。この種のエントリでは、ペアは 1 つだけです。dialer 部が Dialers ファイルのエントリと突き合わされます。

例 27-8 同一ポートセレクタ上のコンピュータ用 UUCP Dialer フィールド

Dialers    develcon ,""   ""            ¥pr¥ps¥c est:¥007 ¥E¥D¥e ¥007

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

• ポートセレクタに接続しているモデム - ポートセレクタに高速モデムが接続されている場合は、ローカルコンピュータはまずポートセレクタスイッチにアクセスする必要があります。そして、そのスイッチがモデムとの接続を確立します。この種類のエントリには、ダイヤラとトークンのペアが 2 つ必要です。各ペアの dialer 部 (エントリの 5 番目と 7 番目のフィールド) が、Dialers ファイル内のエントリと突き合わされます。

例 27-9 ポートセレクタに接続されたモデム用 UUCP Dialer フィールド

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 つのエスケープ文字が使用できます。

• ¥T - Phone (token) フィールドを、/etc/uucp/Dialcodes ファイルを使用して解釈することを指定します。通常、モデム (Hayes、US Robotics など) に対応する各呼び出しスクリプトについて、/etc/uucp/Dialers ファイルにこのエスケープ文字を組み込みます。したがって、呼び出しスクリプトがアクセスされるまでは、解釈は行われません。

• ¥D - Phone (token) フィールドを、/etc/uucp/Dialcodes ファイルを使用して解釈しないことを指定します。Devices エントリの末尾にエスケープ文字が何も指定されていないときは、デフォルトで ¥D があるものと想定します。¥D は、/etc/uucp/Dialers ファイルの中でも、ネットワークスイッチ (develcon と micom) に関連したエントリで使用されます。

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

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

Type,Protocol [parameters]

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

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

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

TCP,te - - Any TCP - 

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

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

UCCP /etc/uucp/Dialers ファイル

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

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

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

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

dialer 

substitutions 

expect-send

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

例 27-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 の各フィールドは文字列です。

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

例 27-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

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

次に示すのは 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 (一時停止) で置き換えられるようになります。

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

• "" - 何も待たない (つまり次へ進む)

• ¥d - 2 秒間の遅延の後キャリッジリターンを送信する

• > - > を待つ

• Q¥c - キャリッジリターンを付けずに Q を送信する

• : - : を待つ

• ¥d- - 2 秒間の遅延の後 - とキャリッジリターンを送信する

• > - > を待つ

• s¥p9¥c - s を送信し、一時停止し、9 を送信するが、キャリッジリターンは送信しない

• )-W¥p¥r¥ds¥p9¥c-) - ) を待つ。) が受信されない場合は、- 文字の間の文字列を処理する。つまり、W を送信し、一時停止し、キャリッジリターンを送信し、遅延し、s を送信し、一時停止し、9 を送信し、キャリッジリターンを送信しないで ) を待つ

• y¥c - キャリッジリターンを付けずに y を送信する

• : - : を待つ

• ¥E¥TP - エコーチェックを有効にする (この時点以降は、1 文字送信すると、その文字が受信されるまでほかの作業を行わない)。次に電話番号を送信する。¥T は、引数として渡された電話番号をとり、Dialcodes 変換を適用し、このエントリのフィールド 2 で指定されたモデム機能変換を適用することを意味する。次に、P とキャリッジリターンを送信する

• > - > を待つ

• 9¥c - 改行を付けずに 9 を送信する

• OK - 文字列 OK を待つ

UUCP ハードウェアフロー制御

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

STTY はすべての stty モードを受け入れます。詳細は、stty(1) と 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 ファイルのエントリ中でも使用できます。

UUCP パリティの設定

場合によっては、呼び出そうとしているシステムがポートのパリティを検査し、パリティに誤りがあると回線を切断することがあります。そのため、パリティのリセットが必要になります。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 構成ファイル

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

UUCP /etc/uucp/Dialcodes ファイル

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

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

abbreviation dial-sequence

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

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

最初の行の 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 というシーケンスをダイヤラに送ります。

UUCP /etc/uucp/Sysfiles ファイル

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

• 別の Systems ファイルにより、uucp のサービスとは異なるアドレスに対してログインサービスを要求できます。

• 別の Dialers ファイルにより、cu と uucp で異なるハンドシェークを割り当てることができます。

• 複数の Systems、Dialers、Devices ファイル。特に Systems ファイルはサイズが大きくなるので、いくつかの小さいファイルに分割しておくと便利です。

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

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

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

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

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

service=uucico:cu systems=Systems :Local_Systems 

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

上記のエントリの場合は、cu と uucico は、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

UUCP /etc/uucp/Sysname ファイル

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

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

UUCP /etc/uucp/Permissions ファイル

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

エントリの UCCP 構造

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

name=value

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

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

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

• LOGNAME - リモートマシンがローカルマシンにログインする (呼び出す) ときに有効なアクセス権を指定する。

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

• MACHINE - ローカルマシンがリモートコンピュータにログインする (呼び出す) ときに有効なアクセス権を指定する。

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

UUCP の考慮事項

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

• リモートコンピュータが、UUCP 通信を目的としてログインするために使用するすべてのログイン ID は、1 つの LOGNAME エントリだけに指定されていなければならない。

• 呼び出されたサイトの名前が MACHINE エントリにない場合、そのサイトには次に示すデフォルトのアクセス権または制約が適用される。

  • ローカルの送信要求と受信要求は実行される

  • リモートコンピュータは、ローカルコンピュータの /var/spool/uucppublic ディレクトリにファイルを送信できる

  • リモートコンピュータがローカルコンピュータで実行するために送信するコマンドは、デフォルトのコマンドのどれかでなければならない (通常は rmail)

UUCP REQUEST オプション

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

UUCP SENDFILES オプション

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

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

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

UUCP MYNAME オプション

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

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 マシンを呼び出したときにも、world が widget という別名で認識するようにしたい場合は、次のようなエントリを作成します。

MACHINE=world MYNAME=widget

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

UUCP 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 ディレクトリには多数の重要なシステムファイルが入っているので、このディレクトリにファイルを送出する権限はリモートユーザーには付与しない方が賢明です。

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

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

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

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

UUCP CALLBACK オプション

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

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

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

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

UUCP COMMANDS オプション

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

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

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

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

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

これは、COMMANDS のデフォルトを無効にして、owl、raven、hawk、dove という名前の各コンピュータが、rmail、rnews、および lp をローカルコンピュータで実行できるようにします。

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

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 点を示しています。

• ALL の値は文字列の中のどこでも使用できる

• 要求された rnews、lp コマンドにフルパス名が指定されていない場合は、デフォルトではなく、それぞれについて指定されているパス名が使用される

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

UUCP 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 

この例では、リモートコンピュータが eagle、owl、および hawk のどれかとしてローカルコンピュータにログインする場合は、そのコンピュータはログイン 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 を実行できることを示しています。

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

UUCP OTHER 用の MACHINE エントリ

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

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

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

UUCP の MACHINE エントリと LOGNAME エントリの結合

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

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

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

これらは、同じ REQUEST、READ、および WRITE オプションを共有しています。この 2 つを結合すると次のようになります。

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

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

UUCP の転送

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

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

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

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 スクリプトはスケジューラを起動し、スケジューラは、スプールディレクトリ内のすべての作業ファイルを調べます。

UUCP /etc/uucp/Config ファイル

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

parameter=value

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

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

Protocol=G(7,512)ge

UUCP /etc/uucp/Grades ファイル

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

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

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

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

UUCP User-job-grade フィールド

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

UUCP 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 を使用し、そのデフォルトに割り当てるシステムジョブグレードを指定します。Restriction フィールドと ID フィールドは Any と定義して、どのようなユーザー、どのようなサイズのジョブでも、このグレードでキューに入れることができるようにします。次に例を示します。

default a Any User Any 

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

UUCP Job-size フィールド

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

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

• 5000 は 5000 バイトを表す

• 10K は 10K バイトを表す

• 2M は 2M バイトを表す

UUCP Permit-type フィールド

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

UUCP ID-list フィールド

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

その他の UUCP 構成ファイル

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

UUCP /etc/uucp/Devconfig ファイル

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

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

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

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

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

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

UUCP /etc/uucp/Limits ファイル

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

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

service=x max=y:

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

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

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

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

UUCP remote.unknown ファイル

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

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

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

UUCP の管理ファイル

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

• 一時データファイル (TM) - これらのデータファイルは、他のコンピュータからファイルを受け取るときに、UUCP プロセスによりスプールディレクトリ /var/spool/uucp/x の下に作成されます。ディレクトリ x は、ファイルを送信しているリモートコンピュータと同じ名前です。一時データファイル名の形式は次のとおりです。

  TM.pid.ddd

  pid はプロセス ID、ddd は 0 から始まる 3 桁のシーケンス番号です。

  ファイルの全体が受信されると、TM.pid.ddd ファイルは、伝送を発生させた C.sysnxxxx ファイル (以下で説明します) の中で指定されているパス名に移されます。処理が異常終了した場合は、TM.pid.ddd ファイルは x ディレクトリ内に残されます。このファイルは、uucleanup を使用することにより自動的に削除されます。

• ロックファイル (LCK) - ロックファイルは、使用中の各デバイスごとに、/var/spool/locks ディレクトリ内に作成されます。ロックファイルは、対話の重複、複数の試行による同じ呼び出しデバイスの使用が発生するのを防ぎます。表 27-10 に、UUCP ロックファイルの種類を示します。

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

• 作業ファイル (C.) - 作業ファイルは、リモートコンピュータに送る作業 (ファイル転送またはリモートコマンド実行) がキューに入れられたときに、スプールディレクトリ内に作成されます。作業ファイル名の形式は次のとおりです。

  C.sysnxxxx

  sys はリモートコンピュータ名、n は作業のグレード (優先順位) を表す ASCII 文字、xxxx は、UUCP が割り当てる 4 桁のジョブシーケンス番号です。作業ファイルには次の情報が含まれています。

  • 送信または要求するファイルのフルパス名

  • 宛先、ユーザー名、またはファイル名を表すフルパス名

  • ユーザーのログイン名

  • オプションのリスト

  • スプールディレクトリ内の関連データファイルの名前。uucp -C オプションか uuto -p オプションが指定されている場合は、ダミー名 (D.0) が使用される

  • ソースファイルのモードビット

  • 転送完了の通知を受け取るリモートユーザーのログイン名

• データファイル (D.) - コマンド行でスプールディレクトリへのソースファイルのコピーを指定すると、データファイルが作成されます。データファイル名の形式は次のとおりです。

  D.systmxxxxyyy - systm はリモートコンピュータ名の最初の 5 文字で、xxxx は uucp が割り当てる 4 桁のジョブシーケンス番号です。4 桁のジョブシーケンス番号の後に続く yyy はサブシーケンス番号で、これは、1 つの作業 (C.) ファイルについて複数の D. ファイルが作成された場合に使用されます。

• X. (実行ファイル) - 実行ファイルは、リモートコマンドの実行の前にスプールディレクトリ内に作成されます。実行ファイル名の形式は次のとおりです。

  X.sysnxxxx

  sys はリモートコンピュータ名で、n は作業のグレード (優先順位) を表す文字です。xxxx は、UUCP が割り当てる 4 桁のシーケンス番号です。実行ファイルには次の情報が入ります。

  • 要求元のログイン名とコンピュータ名

  • 実行に必要なファイル名

  • コマンド文字列への標準入力として使用する入力

  • コマンド実行の標準出力を受け取るコンピュータとファイルの名前

  • コマンド文字列

  • 終了ステータスの要求のためのオプション行

UUCP のエラーメッセージ

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

UUCP の ASSERT エラーメッセージ

表 27-11 に ASSERT エラーメッセージを一覧にします。

UUCP の STATUS エラーメッセージ

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

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

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