UUCP ファイル転送システムを使用すると、UNIX ベースのシステム間でファイルと電子メールを送受信できます。パート III では、複雑な UUCP システムを管理する方法について説明します。
パート III の内容は、モデム管理と広域ネットワークに関する実践的な知識を持つ、熟練のネットワーク管理者を対象としています。また、ネットワーク管理者が、電話回線を介して UUCP を使用しようとしていること、コンピュータにハードウェアを追加する手順を熟知していること、すでにモデムをマシンに接続してあること、tip または cu を用いたダイヤルアウトができることを前提として説明を進めます。
この章では、UUCP のプログラムとデーモンを紹介します。その後で、UUCP 構成の一環として、UUCP データベースファイルを構成する方法について詳しく説明します。データベースの作成後、UUCP をどのように構成するかについては、第 13 章「UUCP の構成と保守」で説明します。
UNIX-to-UNIX Copy Program (UUCP) は、コンピュータが相互にファイルの転送、メールの交換を実現します。また、UUCP を使って Usenet のような大規模ネットワークにコンピュータを接続することも可能です。
Solaris 環境には、HoneyDanBer UUCP とも呼ばれる基本ネットワークユーティリティ (BNU) バージョンの UUCP が備えられています。UUCP という用語はシステムを形成するすべてのファイルとユーティリティを意味するものであり、uucp プログラムはそのシステムの一部にすぎません。UUCP のユーティリティには、コンピュータ間でファイルをコピーするためのもの (uucp と uuto) から、リモートログインやリモートコマンド実行のためのもの (cu と uux) まで、さまざまなものがあります。
直接リンク - 2 つのマシンのシリアルポート間を RS-232 ケーブルで結ぶことにより、他のコンピュータとの間の直接リンクを作成できます。2 つのコンピュータが常時互いに通信を行い、両者の間の距離が 15 m 以内の場合は、直接リンクを使用すると便利です。この制限距離は、短距離モデムを使用することである程度延長できます。
電話回線 - 高速モデムなどの自動呼び出し装置 (ACU) を使用すれば、通常の電話回線を介して他のコンピュータと通信できます。モデムは、UUCP が要求する電話番号をダイヤルします。受信側のモデムは、着信に応答できなければなりません。
ネットワーク - UUCP は、TCP/IP またはその他のプロトコルファミリが機能するネットワークを介しても通信できます。コンピュータがネットワーク上でホストとして確立されていれば、そのネットワークに接続されている他のどのホストとも通信できます。
この章では、UUCP ハードウェアをすでに設置、構成してあるものとして、説明を進めます。モデムを設定する必要がある場合は、『Solaris のシステム管理 (第 2 巻)』と、モデムに付属しているマニュアルを参照してください。
Solaris インストールプログラムを実行するときに全体ディストリビューションを選択していれば、UUCP ソフトウェアは自動的に組み込まれています。あるいは、pkgadd を使って UUCP を単独で追加することもできます。UUCP のプログラムは、デーモン、管理プログラム、ユーザープログラムの 3 種類に分類されます。
UUCP システムのデーモンには、uucico、uuxqt、uusched、in.uucpd の 4 つがあります。これらのデーモンは、UUCP のファイル転送とコマンド実行を取り扱います。必要な場合は、これらのデーモンをシェルから手動で実行することもできます。
uucico - リンクに使用するデバイスを選択し、リモートコンピュータへのリンクを確立し、必要なログインシーケンスとアクセス権の検査を行い、データを転送し、ファイルを実行し、結果をログに記録し、転送の完了を mail によりユーザーに通知します。uucico は、UUCP ログインアカウント用の「ログインシェル」として働きます。ローカル uucico デーモンはリモートマシンを呼び出して、セッションの間、リモート uucico デーモンと直接通信します。
uucp、uuto、uux の各プログラムは、必要なファイルをすべて作成してから、uucico デーモンを実行して、リモートコンピュータに接続します。uusched と Uutry は、どちらも uucico を実行します (詳細は uucico(1M) のマニュアルページを参照してください)。
uuxqt - リモート実行要求を処理します。uuxqt は、スプールディレクトリを検索して、リモートコンピュータから送られた実行ファイル (名前は常に X.file) を見つけます。X.file が見つかると、uuxqt はそのファイルをオープンして、実行に必要なデータファイルのリストを取得します。次に、必要なデータファイルが使用可能でアクセスできるかどうかを確認します。ファイルが使用可能であれば、uuxqt は Permissions ファイルを調べて、要求されたコマンドを実行する権限があるかどうかを確認します。uuxqt デーモンは、cron により起動される uudemon.hour シェルスクリプトから実行されます (詳細は uuxqt(1M) のマニュアルページを参照してください)。
uusched - スプールディレクトリ内でキューに入っている作業をスケジュールします。uusched は、cron から起動される uudemon.hour シェルスクリプトによって、ブート時に最初に実行されます (詳細は uusched(1M) のマニュアルページを参照してください)。uusched は uucico デーモンを起動する前に、リモートコンピュータを呼び出す順序をランダム化します。
in.uucpd - ネットワークを介した UUCP 接続をサポートします。リモートホスト上の inetd は、UUCP 接続が確立されるたびに in.uucpd を呼び出します。次に、uucpd がログイン名を要求します。呼び出し側ホストの uucico は、これに対してログイン名を応答しなければなりません。次に in.uucpd は、不要な場合を除いてパスワードを要求します (詳細は in.uucpd(1M) のマニュアルページを参照してください)。
ほとんどの UUCP 管理プログラムは、/usr/lib/uucp にあります。基本データベースファイルの多くは、/etc/uucp に入っています。ただし、uulog だけは例外で、これは /usr/bin にあります。uucp ログイン ID のホームディレクトリは /usr/lib/uucp です。su または login を用いて管理プログラムを実行するときには、uucp ユーザー ID を使用してください。このユーザー ID は、プログラムとスプールデータファイルを所有しています。
uulog - 指定したコンピュータのログファイルの内容を表示します。ログファイルは、このマシンが通信する各リモートコンピュータごとに作成されます。ログファイルには、uucp、uuto、uux の使用が記録されます (詳細は uucp(1C) のマニュアルページを参照してください)。
uucleanup - スプールディレクトリをクリーンアップします。これは通常、cron によって起動される uudemon.cleanup シェルスクリプトから実行されます (詳細は uucleanup(1M) のマニュアルページを参照してください)。
Uutry - 呼び出し処理機能をテストし、簡単なデバッグを行うことができます。uucico デーモンを呼び出して、このマシンと指定されたリモートコンピュータとの間の通信リンクを確立します (詳細は Uutry(1M) のマニュアルページを参照してください)。
uucheck - UUCP のディレクトリ、プログラム、サポートファイルの有無を検査します。また、/etc/uucp/Permissions ファイルの所定の部分に、明らかな構文エラーがないかどうかも検査します (詳細は uucheck(1M) のマニュアルページを参照してください)。
UUCP のユーザープログラムは /usr/bin にあります。これらのプログラムを使用するのに、特別な権限は必要ありません。
cu - このマシンをリモートコンピュータに接続して、ユーザーが両方のマシンに同時にログインできるようにします。cu を使用すれば、接続したリンクを切断することなく、どちらのマシンでもファイルを転送したり、コマンドを実行したりできます (詳細は cu(1C) のマニュアルページを参照してください)。
uucp - あるマシンから別のマシンへファイルをコピーします。uucp は作業ファイルとデータファイルを作成し、転送するジョブをキューに入れ、uucico デーモンを呼び出します。このデーモンは、リモートコンピュータへの接続を試みます (詳細は uucp(1C) のマニュアルページを参照してください)。
uuto - ローカルマシンから、リモートマシン上の公共スプールディレクトリ /var/spool/uucppublic/receive にファイルをコピーします。uucp はリモートマシン上のアクセス可能な任意のディレクトリにファイルをコピーするのに対して、uuto は所定のスプールディレクトリにファイルを格納し、リモートユーザーに uupick を使ってそのファイルを取り出すよう指示します (詳細は uuto(1C) のマニュアルページを参照してください)。
uupick - uuto を用いてコンピュータにファイルが転送されてきたときに、/var/spool/uucppublic/receive からファイルを取得します (詳細は uuto(1C) のマニュアルページを参照してください)。
uux - リモートマシン上でコマンドを実行するために必要な作業ファイル、データファイル、実行ファイルを作成します (詳細は uux(1C) のマニュアルページを参照してください)。
uustat - 要求された転送 (uucp、uuto、uux) の状態を表示します。また、キューに入っている転送を制御する手段も提供します (詳細は uustat(1C) のマニュアルページを参照してください)。
UUCP の構成の主要部分の 1 つに、UUCP データベースを形成するファイルの構成があります。これらのファイルは /etc/uucp ディレクトリにあります。マシン上で UUCP または PPP を設定するには、これらのファイルを編集する必要があります。UUCP データベースファイルには以下のものがあります。
Config - 変数パラメータのリストが入っています。これらのパラメータは、ネットワークを構成するために手動で設定できます。
Devices - 自動呼び出し装置 (モデム)、直接リンク、ネットワークデバイスの位置と回線速度に関する情報が入っています。これは、UUCP のほかに PPP でも使用されます。
Dialers - リモートコンピュータとの接続を確立するときに、モデムとのネゴシエーションを行うために必要な文字列が入っています。これは、UUCP のほかに PPP でも使用されます。
Dialcodes - Systems ファイルのエントリの電話番号フィールド内で使用できるダイヤルコード省略名が入っています。これは必須ではありませんが、UUCP のほかに PPP でも使用できます。
Grades - ジョブのグレードと、ジョブの各グレードに対応するアクセス権を定義します。これらは、リモートコンピュータに対するジョブをキューに入れる際に、ユーザーが指定できます。
Permissions - このマシンにファイルを転送したり、コマンドを実行しようとしているリモートホストに与えられるアクセス権のレベルを定義します。
Sysfiles - uucico と cu が、Systems、Devices、Dialers ファイルとして、別のファイルや複数のファイルを使う時に、その割り当てを行います。
Systems - uucico デーモン、cu、PPP が、リモートコンピュータへのリンクを確立するために必要とする情報が入っています。この情報には、リモートホストの名前、リモートホストに対応する接続デバイスの名前、そのホストに接続できる日時、電話番号、ログイン ID、パスワードが含まれます。
サポートデータベースの一部とみなすことのできるファイルがほかにもいくつかありますが、これらは、リンクの確立とファイルの転送に直接には関係しません。
UUCP データベースは、「UUCP データベースファイルの紹介」に示したファイルから構成されます。ただし、基本的な UUCP 構成に関係する重要なファイルは次に示すものだけです。
/etc/uucp/Systems
/etc/uucp/Devices
/etc/uucp/Dialers
PPP は UUCP データベースの一部を使用するので、PPP を構成する予定がある場合は、少なくともこれらのデータベースファイルだけは理解しておく必要があります。これらのデータベースを構成してしまえば、その後の UUCP の管理はきわめて簡単です。一般に、Systems ファイルを最初に編集し、次に Devices ファイルを編集します。/etc/uucp/Dialers ファイルは、普通はデフォルトのままで使用できますが、デフォルトファイルに含まれていないダイヤラを追加する予定がある場合は編集が必要になります。基本的な UUCP 構成と PPP 構成には、さらに次のファイルを加えることもできます。
/etc/uucp/Sysfiles
/etc/uucp/Dialcodes
/etc/uucp/Sysname
これらのファイルは互いに関係しながら機能するので、1 つでも変更する場合は、全部のファイルの内容を理解しておくことが必要です。あるファイルのエントリに変更を加えた場合に、別のファイル内の関連エントリに対しても変更が必要になることがあります。「UUCP データベースファイルの紹介」に挙げたその他のファイルは、上記のファイルほど緊密な相互関係を持っていません。
PPP が使用するファイルはこの節で説明するものだけであり、他の UUCP データベースファイルは使用しません。
この章の以降の部分では、UUCP データベースについて詳しく説明します。
/etc/uucp/Systems ファイルには、uucico がリモートコンピュータとの通信リンクを確立するために必要な情報が入っています。これは、UUCP を構成するときに編集しなければならない最初のファイルです。
Systems ファイルの中の各エントリは、このホストが通信するリモートコンピュータを表します。1 つのホストについて複数のエントリがある場合もあります。付加的なエントリは、順番に試される代替通信パスを表します。さらに、UUCP のデフォルト状態では、/etc/uucp/Systems ファイルに含まれていないコンピュータがこのホストにログインできないようになっています。
Sysfiles ファイルを使用して、Systems ファイルとして使用されるファイルをいくつか定義できます。詳細は、Sysfiles ファイルの説明を参照してください。
System-Name |
Time |
Type |
Speed |
Phone |
Chat-Script |
例 12-1 に、Systems ファイルのフィールドの例を示します。
System-Name Time Type Speed Phone Chat Script Arabian Any ACUEC 38400 111222 Login: Puucp ssword:beledi |
このフィールドには、リモートコンピュータのノード名が入ります。TCP/IP ネットワークでは、これは、マシンのホスト名でも、/etc/uucp/Sysname ファイルによって UUCP 通信用として特別に作成した名前でもかまいません。「/etc/uucp/Sysname ファイル」を参照してください。例 12-1 では、System-Name フィールドにはリモートホスト arabian に関するエントリが含まれています。
このフィールドには、リモートコンピュータを呼び出すことのできる曜日と時刻を指定します。Time フィールドの形式は次のとおりです。
daytime[;retry]
day の部分には、以下のエントリのいくつかを含むリストを指定できます。
表 12-1 Day フィールド
個々の曜日 |
|
任意の平日 |
|
任意の日 |
|
このホストはこのリモートコンピュータの呼び出しをいっさい行わない。呼び出しはリモートコンピュータ側から行う必要がある。それを受けて、このホストは受動モードで稼動する |
例 12-1 では、Time フィールドに Any が示されています。これは、ホスト arabian をいつでも呼び出せるということです。
time の部分には、24 時間表記で表した時間の範囲を指定します (たとえば、午前 8 時 00 分から午後 12 時 30 分までなら、0800-1230)。time の部分を指定しなかった場合は、どのような時刻にでも呼び出しができるものとみなされます。
0000 の前後にまたがる時間範囲も指定できます。たとえば、0800-0600 は、午前 6 時から午前 8 時までの間を除くすべての時間帯で呼び出し可能であることを示します。
retry サブフィールドには、試行が失敗してから次の再試行までの間に最小限必要な時間 (分単位) を指定できます。デフォルトの待ち時間は 60 分です。サブフィールド区切り文字はセミコロン (;) です。たとえば、Any;9 は、呼び出しはいつでもできるが、失敗したときは次の再試行までに少なくとも 9 分は待たなければならないことを意味します。
retry エントリを指定しなかった場合は、待ち時間倍加アルゴリズムが使用されます。これは、UUCP がデフォルトの待ち時間から始めて、失敗した試行の回数が増えるほど待ち時間を長くしていくことを意味します。たとえば、最初の再試行待ち時間が 5 分であるとします。応答がない場合は、次の再試行は 10 分後となります。次の再試行は 20 分後というようになり、最大再試行時間の 23 時間に達するまで増加します。retry を指定した場合は、常にその値が再試行待ち時間となります。指定がなければ待ち時間倍加アルゴリズムが使用されます。
このフィールドには、リモートコンピュータとの通信リンクを確立するために使用するデバイスタイプを指定します。このフィールドで使用するキーワードは、例 12-2 に示すように、Devices ファイル中のエントリの最初のフィールドと突き合わされます (表の見出しに示されているフィールドは Systems ファイル用のものであり、Devices ファイルには適用されないので、注意してください。Devices ファイルのフィールドの対応関係については、例 12-6 を参照してください)。
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 フィールドでは、さらに、システムとの接続に使用するプロトコルを定義できます。上記の例では、デバイスタイプ ACUEC に g プロトコルを組み合わせています (プロトコルの詳細は、「Devices ファイル内のプロトコル定義」を参照してください)。
このフィールド (Class フィールドとも呼ばれます) は、通信リンクの確立に使用するデバイスの転送速度を指定します。このフィールドには、ダイヤラのクラスを区別するために、1 個の英字と速度を含めることができます (たとえば、C1200、D1200) (詳細は 「Class フィールド」を参照してください)。
デバイスにはどのような速度でも使用できるものがあり、その場合はキーワード Any を使用できます。このフィールドは、例 12-3 に示したように、Devices ファイルの対応するエントリの Class フィールドに一致していなければなりません。
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 |
このフィールドに情報を入れる必要がない場合は、フィールドの数を合わせるためにダッシュ (-) を指定してください。
このフィールドには、自動ダイヤラ (ポートセレクタ) に与えるリモートコンピュータの電話番号 (トークン) を指定できます。電話番号は、オプションの英字による省略名と数字部分で構成されます。省略名を使用する場合は、例 12-4 に示すように Dialcodes ファイル内に列挙されているもののひとつでなければなりません。
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 ファイルを使って解釈されないようにしなければなりません。
このフィールド (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 ファイルのチャットスクリプトで使用されるエスケープ文字文字 | 説明 |
---|---|
バックスペース文字を送信または想定する |
|
文字列の末尾で使用すると、普通なら送信されるキャリッジリターンが抑止される。その他の場合は無視される |
|
後続の文字を送る前に 1 〜 3 秒の遅延が生じる |
|
エコーチェックを開始する (これ以降は、1 文字送信するたびに、その文字が受信されるのを待つ。以後の作業は、これを受信してから行われる) |
|
エコーチェックをオフにする |
|
ハングアップを 1 回無視する。このオプションはコールバックモデム用に使用する |
|
BREAK 文字を送信する |
|
CLOCAL フラグをオンにする |
|
CLOCAL フラグをオフにする |
|
改行文字を送信または想定する |
|
NULL 文字 (ASCII NUL) を送信する |
|
約 1/4 秒間または 1/2 秒間、一時停止する |
|
キャリッジリターンを送信または想定する |
|
スペース文字を送信または想定する |
|
タブ文字を送信または想定する |
|
EOT とそれに続く 2 個の改行文字を送信する |
|
ブレーク文字を送信する |
|
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 ファイルには、リモートコンピュータへのリンクを確立するために使用できるすべてのデバイスに関する情報が入っています。この種のデバイスには、ACU (が含まれます)、直接リンク、ネットワーク接続などがあります。
Type |
Line |
Line2 |
Class |
Dialer-Token-Pairs |
次に示す /etc/uucp/Devices のエントリは、ポート A に接続され 38,400 bps で動作する US Robotics V.32bis モデムを表しています。
ACUEC cua/a - 38400 usrv32bis-ec |
このフィールドは、デバイスが確立するリンクの種類を記述します。このフィールドには次のセクションに示すキーワードのいずれかを入れることができます。
キーワード Direct は、主として cu 接続用のエントリ内で使用されます。このキーワードは、このリンクが他のコンピュータまたはポートセレクタへの直接リンクであることを示します。cu の -l オプションで参照したい各回線について、それぞれ独立したエントリを作成する必要があります。
キーワード ACU は、(cu、UUCP、または PPP を介した) リモートコンピュータへのリンクを、モデムを介して確立することを示します。このモデムは、直接ローカルコンピュータに接続しているものでも、ポートセレクタを介して間接的に接続しているものでもかまいません。
これは、ポートセレクタの名前で置き換えるものとして、Type フィールド内で使用される変数です。ポートセレクタは、ネットワークに接続されたデバイスで、呼び出し側モデムの名前を要求し、アクセスを許可します。 /etc/uucp/Dialers ファイルに入っている呼び出しスクリプトは、micom ポートセレクタと develcon ポートセレクタについてのものだけです。ユーザーは、Dialers ファイルに独自のポートセレクタエントリを追加できます (詳細は 「/etc/uucp/Dialers ファイル」を参照してください)。
Type フィールド内のこの変数は、特定のマシンの名前で置き換えられます。これは、リンクがこのマシンへの直接リンクであることを示します。この命名スキーマは、この Devices エントリ内の行と、コンピュータ Sys-Name についての /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 ファイル」を参照してください)。
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....... |
このフィールドには、Devices エントリに対応付けられる回線 (ポート) のデバイス名が入ります。たとえば、特定のエントリに対応付けられているモデムが /dev/cua/a (シリアルポート A) に接続されている場合、このフィールドに入力する名前は cua/a です。Line フィールドでオプションのモデム制御フラグ M を使用すると、キャリアを待たないでデバイスをオープンすることを指定できます。たとえば次のようになります。
cua/a,M |
このフィールドは、フィールドの数を合わせるために存在しているだけです。ここには常にダッシュ (-) を指定します。Line2 フィールドを使用するのは 801 型のダイヤラですが、この種類は Solaris 環境ではサポートされていません。801 型以外のダイヤラは通常はこの設定を使用しませんが、このフィールドにダッシュだけは入れておく必要があります。
Type フィールドでキーワード ACU または Direct を使用した場合は、Class フィールドにはデバイスの速度が入ります。ただし、このフィールドには、ダイヤラのクラス (Centrex または Dimension PBX) を区別するために、1 個の英字と速度値を含めることができます (たとえば、C1200、D1200)。
大規模な事業所では複数種の電話ネットワークを使用することが多いため、このような指定が必要になります。たとえば、1 つのネットワークは事業所内の内線通信専用に使用し、もう 1 つのネットワークは外線通信に使用するといった方式が考えられます。このような場合は、内線回線と外線回線とを区別する必要があります。
例 12-6 に示すように、Devices ファイルの Class フィールドで使用するキーワードは、Systems ファイルの Speed フィールドと突き合わされます。各列の見出しは、Devices ファイルのフィールドのものであることに注意してください。
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 (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/IP ネットワーク |
|
トランスポートレベルインタフェースネットワーク (STREAMS を使わないもの) |
|
トランスポートレベルインタフェースネットワーク (STREAMS を使うもの) |
詳細は、「Devices ファイル内のプロトコル定義」を参照してください。
DTP フィールドの構造は、エントリに対応するデバイスに応じて 4 通りに設定できます。
直接接続モデム
コンピュータのポートにモデムが直接接続されている場合は、対応する Devices ファイルエントリの DTP フィールドに入るペアは 1 つだけです。このペアは、通常はモデムの名前です。この名前は、Devices ファイルの特定のエントリと、Dialers ファイル内のエントリとを対応付けるために使用されます。したがって、例 12-7 に示すように、Dialer フィールドは、Dialers ファイルエントリの最初のフィールドに一致している必要があります (各列の見出しは、Devices ファイルのフィールドの見出しです)。
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 が暗黙で指定されます)。
直接リンク - 特定のコンピュータへの直接リンクの場合は、対応するエントリの DTP フィールドには、キーワード direct が入ります。これは、Direct、Sys-Name の両方の直接リンクエントリにもあてはまります (「Type フィールド」を参照)。
同じポートセレクタ上のコンピュータ - 通信したいコンピュータが、ローカルコンピュータと同じポートセレクタスイッチ上にある場合は、ローカルコンピュータはまずそのスイッチにアクセスする必要があります。そのスイッチが、相手のコンピュータとの接続を確立します。この種のエントリでは、ペアは 1 つだけです。例 12-8 に示すように、dialer 部が Dialers ファイルのエントリと突き合わされます (各列の見出しは、Devices ファイルのフィールドの見出しです)。
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 ファイル内の有効エントリとして解釈されないことを保証します。
ポートセレクタに接続しているモデム - ポートセレクタに高速モデムが接続されている場合は、ローカルコンピュータはまずポートセレクタスイッチにアクセスする必要があります。そして、そのスイッチがモデムとの接続を確立します。この種類のエントリには、ダイヤラとトークンのペアが 2 つ必要です。例 12-7 に示すように、各ペアの dialer 部 (エントリの 5 番目と 7 番目のフィールド) が、Dialers ファイル内のエントリと突き合わされます (各列の見出しは、Devices ファイルのフィールドの見出しです)。
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 つのエスケープ文字が使用できます。
¥T - Phone (トークン) フィールドを、/etc/uucp/Dialcodes ファイルを使って解釈することを指定します。通常、モデム (Hayes、US Robotics など) に対応する各呼び出しスクリプトについて、/etc/uucp/Dialers ファイルにこのエスケープ文字を組み込みます。したがって、呼び出しスクリプトがアクセスされるまでは、解釈は行われません。
¥D - Phone (トークン) フィールドを、/etc/uucp/Dialcodes ファイルを使って解釈しないことを指定します。Devices エントリの末尾にエスケープ文字が何も指定されていないときは、デフォルトで ¥D があるものと想定します。¥D は、/etc/uucp/Dialers ファイルの中でも、ネットワークスイッチ (develcon と micom) に関連したエントリで使用されます。
/etc/uucp/Devices では、各デバイスに使用するプロトコルを定義できます。通常は、デフォルトを使用するか、または呼び出そうとしている個々のシステムごとにプロトコルを定義できるので、この指定は不要です (「/etc/uucp/Systems ファイル」を参照してください)。プロトコルを指定する場合は、次の形式を使用する必要があります。
Type,Protocol [parameters]
たとえば、TCP/IP プロトコルを指定するには、TCP,te を入力します。
表 12-4 に、Devices ファイルで使用できるプロトコルを示します。
表 12-4 /etc/uucp/Devices で使用されるプロトコル
プロトコル |
説明 |
---|---|
このプロトコルは、TCP/IP や、その他の信頼性のある接続を介した伝送に、最もよく使われる。このプロトコルはエラーのない伝送を前提としている |
|
UUCP のネイティブプロトコル。低速で信頼性があり、ノイズの多い電話回線を介した伝送に適している |
|
このプロトコルは、(TCP/IP のようなバイトストリーム指向ではなく) メッセージ指向でエラーのないチャネルを介した伝送を前提としている |
|
このプロトコルは X.25 接続を介した伝送に使用される。このプロトコルは、データストリームのフロー制御に関係している。特に X.25/PAD リンクなどのように、完全に (またはほとんど) エラーがないことが保証されるリンクでの使用を意図している。検査合計はファイル全体についてのみ実施される。伝送が失敗した場合は、受信側は再伝送を要求する |
次に、デバイスエントリ用のプロトコル指定の例を示します。
TCP,te - - Any TCP - |
この例は、デバイス TCP について t プロトコルの使用を試みるように指示しています。相手側がそれを拒否した場合は、e プロトコルが使用されます。
e と t のどちらも、モデムを介した通信には適していません。モデムがエラーのない伝送を保証するものであったとしても、モデムと CPU との間でデータが失われる可能性があります。
/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 モデム用のエントリの例を示しています。
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 をインストールしたときに提供されるファイルです。
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 で使用するエスケープ文字
文字 |
説明 |
---|---|
バックスペース文字を送信または想定する |
|
改行、キャリッジリターンを抑止する |
|
遅延 (約 2 秒) |
|
Dialcodes 変換なしの電話番号またはトークン |
|
エコーチェックを使用しない |
|
エコーチェックを使用する (低速デバイス用) |
|
ブレーク文字を挿入する |
|
改行文字を送信する |
|
8 進数値を送信する。使用できるその他のエスケープ文字は、「/etc/uucp/Systems ファイル」を参照 |
|
NULL 文字 (ASCII NUL) を送信または想定する |
|
一時停止 (約 12 〜 14 秒) |
|
リターン |
|
スペース文字を送信または想定する |
|
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 (一時停止) で置き換えられるようになります。
上記の行の残りの部分に指定されているハンドシェークの働きは、次のとおりです。
"" - 何も待たない (つまり次へ進む)
¥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 を送信する
擬似送信文字列 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 構成を行うときに、Systems、 Devices、 Dialers ファイルに加えて使用できるファイルです。
/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 ファイルでは、uucp と cu が Systems、 Devices、 Dialers ファイルとして使用する別のファイルを割り当てます (cu についての詳細は、cu(1C) のマニュアルページを参照してください)。Sysfiles は次の目的に使用できます。
別の Systems ファイルにより、uucp のサービスとは異なるアドレスに対してログインサービスを要求できます。
別の Dialers ファイルにより、cu と uucp で異なるハンドシェークを割り当てることができます。
複数の Systems、Dialers、Devices ファイル。特に Systems ファイルはサイズが大きくなるので、いくつかの小さいファイルに分割しておくと便利です。
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/Systems ファイルに、チャットスクリプトやその他の識別情報とともに格納されます。通常は、UUCP は、uname -n コマンドから返されるものと同じノード名を使用し、TCP/IP でもこの名前を使用します。
/etc/uucp/Sysname ファイルを作成することによって、TCP/IP ホスト名とは別の UUCP ノード名を指定できます。このファイルには、ローカルシステムの UUCP ノード名が入った 1 行のエントリが含まれています。
/etc/uucp/Permissions ファイルは、ログイン、ファイルアクセス、コマンド実行に関するリモートコンピュータのアクセス権を指定します。リモートコンピュータがファイルを要求する権限と、ローカルマシンでキューに入れられたファイルを受け取る権限を制限するオプションがあります。また、リモートマシンがローカルコンピュータ上で実行できるコマンドを指定するオプションもあります。
各エントリは 1 行の論理行で、行末にバックスラッシュ (¥) がある場合は次の行と継続していることを示します。エントリは、スペースで区切られたオプションから構成されます。各オプションは、次の形式の名前と値のペアです。
name=value
values はコロンで区切ってリストとすることもできます。オプション指定の中では、スペースは使用できないので注意してください。
コメント行はポンド記号 (#) で始まり、その行の改行文字までの全部分を占めます。空行は無視されます (複数行エントリの中の空行も同じです)。
Permissions ファイルのエントリには 2 つの種類があります。
リモートマシンがローカルマシンを呼び出すとき、固有のログインと検証可能なパスワードを使わない限り、そのリモートマシンの識別情報は正確なものとはなりません。
LOGNAME エントリには LOGNAME オプションが含まれ、MACHINE エントリには MACHINE オプションが含まれます。1 つのエントリに両方のオプションを含めることもできます。
Permissions ファイルを使って、リモートコンピュータに付与されているアクセスのレベルを制限するときは、以下のことを考慮に入れる必要があります。
リモートコンピュータが、UUCP 通信を目的としてログインするために使用するすべてのログイン ID は、1 つの LOGNAME エントリだけに指定されていなければならない。
呼び出されたサイトの名前が MACHINE エントリにない場合、そのサイトには以下に示すデフォルトのアクセス権または制約が適用される。
リモートコンピュータがローカルコンピュータを呼び出し、ファイルの受信を要求したときに、その要求を承認することも拒否することもできます。REQUEST オプションは、リモートコンピュータがローカルコンピュータからのファイル転送を要求できるかどうかを指定します。REQUEST=yes は、リモートコンピュータがローカルコンピュータからのファイル転送を要求できることを指定します。REQUEST=no は、リモートコンピュータがローカルコンピュータからのファイルの受信を要求できないことを指定します。後者は、REQUEST オプションを指定しなかった場合に使用されるデフォルト値です。REQUEST オプションは、LOGNAME エントリ (リモートコンピュータがローカルコンピュータを呼び出す場合) と、MACHINE エントリ (ローカルコンピュータがリモートコンピュータを呼び出す場合) のどちらにも使用できます。
リモートコンピュータがローカルコンピュータを呼び出す作業を完了した後で、ローカルコンピュータのキュー中のリモートコンピュータ用の作業を受け取ろうとすることがあります。SENDFILES オプションは、ローカルコンピュータが、リモートコンピュータ用にキューに入れた作業を送信できるかどうかを指定します。
文字列 SENDFILES=yes は、リモートコンピュータが LOGNAME オプションに指定されている名前の 1 つを使ってログインしていれば、ローカルコンピュータがキューに入れた作業を送信できることを指定します。/etc/uucp/Systems の Time フィールドに Never を入力してある場合は、この文字列の使用は必須です。Never を指定すると、ローカルマシンは受動モードに設定され、相手のリモートコンピュータへの呼び出しを開始することはできなくなります (詳細は 「/etc/uucp/Systems ファイル」を参照してください。
文字列 SENDFILES=call は、ローカルコンピュータがリモートコンピュータを呼び出したときに限り、ローカルコンピュータのキュー中のファイルを送信することを指定します。call の値は SENDFILES オプションのデフォルト値です。MACHINE エントリはリモートコンピュータへの呼び出しを送る場合に適用されるものなので、このオプションが意味を持つのは LOGNAME エントリの中で使用した場合だけです。MACHINE エントリでこのオプションを使用しても無視されます。
このオプションを使用すると、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 オプションにより、ローカルマシンが自分自身を呼ぶこともできるので、テストの目的にも利用できます。しかし、このオプションはマシンの実際の識別情報を隠す目的にも使用できてしまうので、「VALIDATE オプション」で述べる VALIDATE オプションを使用するようにしてください。
これらのオプションは、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 オプションは、READ オプションと WRITE オプションおよびデフォルトに対する例外を指定します。たとえば次のようなエントリを指定したとします。
READ=/ NOREAD=/etc WRITE=/var/spool/uucppublic |
これは、/etc ディレクトリ (およびこの下の各サブディレクトリ。このパス名は接頭辞であることを忘れないでください) の中のファイルを除くすべてのファイルの読み取りを許可しています。デフォルトの /var/spool/uucppublic ディレクトリへの書き込みだけを許可しています。NOWRITE も NOREAD オプションと同じ形で働きます。NOREAD オプションと NOWRITE オプションは、LOGNAME エントリと MACHINE エントリのどちらにも使用できます。
LOGNAME エントリの中で CALLBACK オプションを使うと、呼び出し側システムがコールバックするまで、トランザクションをいっさい行わないことを指定できます。CALLBACK を設定する理由は 2 つあります。1 つはセキュリティを目的とするもので、マシンをコールバックすることで、それが正しいマシンであることを確認できます。 もう 1 つは課金を目的とするもので、大量のデータの伝送を行うときに、その長時間の呼び出しの料金を課すマシンを選択できます。
文字列 CALLBACK=yes は、ファイル転送を行う前に、ローカルコンピュータがリモートコンピュータをコールバックしなければならないということを指定します。
CALLBACK オプションのデフォルトは CALLBACK=no です。CALLBACK を yes に設定する場合は、呼び出し側に対応する MACHINE エントリの中で、以後の通信に影響を与えるアクセス権を指定する必要があります。これらのアクセス権は、LOGNAME の中で指定してはいけません。また同様に、リモートマシンがローカルホストについて設定した LOGNAME エントリの中で指定してもいけません。
2 つのサイトが互いに CALLBACK オプションを設定すると、通信が開始されないので注意してください。
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 点を示しています。
COMMANDS オプションで cat や uucp などのように、潜在的な危険性のあるコマンドを指定するときは、VALIDATE オプションを使用するようにしてください。UUCP リモート実行デーモン (uuxqt) により実行する場合、ファイルを読み書きをするコマンドは、どれもローカルセキュリティにとって危険性のあるものとなります。
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 を持っていることを確認する必要があります。
特定の MACHINE エントリに記述されていないリモートマシンについて、異なるオプション値を指定したい場合があります。これが必要になるのは、多数のコンピュータがローカルホストを呼び出し、コマンドセットがそのたびに異なるような場合です。次の例に示すように、このようなエントリでは、コンピュータ名として OTHER という名前を使用します。
MACHINE=OTHER ¥ COMMANDS=rmail:rnews:/usr/local/Photo:/usr/local/xp |
他の MACHINE エントリに記述されていないコンピュータについても、MACHINE エントリに使用できるすべてのオプションを設定できます。
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 ファイルは、効率的で管理しやすくなります。
一連のマシンを介してファイルを送信するときは、中継マシンの COMMANDS オプションの中に uucp コマンドが含まれていなければなりません。たとえば次のコマンドを入力したとします。
% uucp sample.txt oak¥!willow¥!pine¥!/usr/spool/uucppublic |
この転送操作が正常に機能するためには、マシン willow が oak に対して uucp プログラムの実行を許可し、oak がローカルマシンに同じことを許可している必要があります。最終宛先マシンである pine は、uucp コマンドを許可する必要はありません。通常、マシンはこのように設定されていません。
/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 ファイルを使用すると、いくつかのパラメータを手動で上書きできます。Config ファイルの各エントリの形式は次のとおりです。
parameter=value
構成可能な全パラメータ名のリストについては、システムに付属している Config ファイルを参照してください。
次の Config ントリは、デフォルトのプロトコル順序を Gge に設定し、G プロトコルのデフォルト値を、ウィンドウ数 7、パケットサイズ 512 バイトに変更します。
Protocol=G(7,512)ge |
/etc/uucp/Grades ファイルには、リモートコンピュータへのジョブをキューに入れるときに指定できるジョブグレードが入っています。また、個々のジョブグレードに関するアクセス権も含まれています。このファイルのエントリは、ユーザーがジョブをキューに入れるときに使用する、管理者が定義したジョブグレードの定義を表しています。
Grades ファイルのエントリの形式は次のとおりです。
User-job-grade System-job-grade Job-size Permit-type ID-list
各エントリには、スペースで区切ったいくつかのフィールドがあります。エントリの最後のフィールドは、同じくスペースで区切ったいくつかのサブフィールドから構成されます。1 つのエントリが複数の物理行にわたる場合は、バックスラッシュを使って、エントリを次の行に継続させることができます。コメント行はポンド記号 (#) で始まり、その行の全体を占めます。空の行は常に無視されます。
このフィールドには、管理者が 64 文字以内で定義したユーザージョブのグレード名が入ります。
このフィールドには、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 はバイト数で表され、表 12-8 に示すオプションを使用できます。
表 12-8 Job-size フィールド
nnnn |
このジョブグレードの最大ジョブサイズを指定する整数 |
nK |
キロバイト数を表す 10 進数 (K はキロバイトの略号) |
nM |
メガバイト数を表す 10 進数 (M はメガバイトの略号) |
最大ジョブサイズが指定されないことを指定するキーワード |
次に例をいくつか示します。
5000 は 5000 バイトを表す
10K は 10K バイトを表す
2M は 2M バイトを表す
このフィールドには、ID リストをどのように解釈するかを指示するキーワードを指定します。表 12-9 に、キーワードとそれぞれの意味を示します。
表 12-9 Permit-type フィールド
キーワード |
ID リストの内容 |
このジョブグレードの使用を許可されているユーザーのログイン名 |
|
このジョブグレードの使用を許可されていないユーザーのログイン名 |
|
このジョブグレードの使用を許可されているメンバのグループ名 |
|
このジョブグレードの使用を許可されていないメンバのグループ名 |
このフィールドには、このジョブグレードへのキューイングが許可、禁止されるログイン名またはグループ名のリストが入ります。名前のリストはそれぞれスペースで区切り、改行文字で終了します。このジョブグレードへのキューイングを誰にでも許可する場合は、キーワード Any を使用します。
この節では、UUCP の機能に影響を与えるファイルのうち、比較的変更頻度の低い 3 つのファイルについて説明します。
/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 がプッシュされます。
/etc/uucp/Limits ファイルは、uucp ネットワーク処理で同時に実行できる uucico、uuxqt、uusched の最大数を制御します。ほとんどの場合は、デフォルトの値が最適であり、変更の必要はありません。変更したい場合は、任意のテキストエディタを使用してください。
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 を、マシンで実行できることを示しています。
通信機能の使用に影響を与えるファイルとして、もう 1 つ、remote.unknown ファイルがあります。このファイルは、どの Systems ファイルにも含まれていないマシンが通信を開始したときに実行されるバイナリプログラムです。このプログラムはその通信をログに記録し、接続を切断します。
remote.unknown ファイルのアクセス権を変更して、このプログラムが実行できないようにすると、ローカルシステムはどのシステムからの接続も受け入れることになります。
このプログラムが実行されるのは、どの Systems ファイルにも含まれていないマシンが対話を開始した場合です。このプログラムは、その対話を記録し、接続を失敗させます。このファイルのアクセス権を変更して実行できないようにしてしまうと (chmod 000 remote.unknown)、ローカルシステムはすべての通信要求を受け入れることになります。妥当な理由がない限り、この変更は行わないようにしてください。
以下、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 ディレクトリ内に作成されます。ロックファイルは、対話の重複、複数の試行による同じ呼び出しデバイスの使用が発生するのを防ぎます。表 12-10 に、UUCP ロックファイルの種類を示します。
ファイル名 |
説明 |
---|---|
LCK..sys |
sys はファイルを使用しているコンピュータの名前を表す |
LCK.dev |
dev はファイルを使用しているデバイスの名前を表す |
LCK.LOG |
LOG はロックされている UUCP ログファイルを表す |
通信リンクが予定外のときに切断された場合 (通常コンピュータがクラッシュしたとき)、これらのファイルがスプールディレクトリ内に残ることがあります。親プロセスが有効でなくなった後は、ロックファイルは無視 (削除) されます。ロックファイルには、ロックを引き起こしたプロセスのプロセス ID が入っています。
作業ファイル (C.) - 作業ファイルは、リモートコンピュータに送る作業 (ファイル転送またはリモートコマンド実行) がキューに入れられたときに、スプールディレクトリ内に作成されます。作業ファイルの名前の形式は次のとおりです。
C.sysnxxxx
sys はリモートコンピュータの名前、n は作業のグレード (優先順位) を表す ASCII 文字、xxxx は、UUCP が割り当てる 4 桁のジョブシーケンス番号です。作業ファイルには次の情報が含まれています。
データファイル (D.) - コマンド行でスプールディレクトリへのソースファイルのコピーを指定すると、データファイルが作成されます。データファイルの名前の形式は次のとおりです。
D.systmxxxxyyy - systm はリモートコンピュータの名前の最初の 5 文字で、xxxx は uucp が割り当てる 4 桁のジョブシーケンス番号です。4 桁のジョブシーケンス番号の後に続く yyy はサブシーケンス番号で、これは、1 つの作業 (C.) ファイルについて複数の D. ファイルが作成された場合に使用されます。
X. (実行ファイル) - 実行ファイルは、リモートコマンドの実行の前にスプールディレクトリ内に作成されます。実行ファイルの名前の形式は次のとおりです。
X.sysnxxxx
sys はリモートコンピュータの名前で、n は作業のグレード (優先順位) を表す文字です。xxxx は、UUCP が割り当てる 4 桁のシーケンス番号です。実行ファイルには次の情報が入ります。
この章では、マシンに関連したデータベースファイルを変更した後で、UUCP 操作を起動する方法について説明します。この章には、Solaris 環境が動作するマシンで 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 には、次に示す 4 つのシェルスクリプトが付属しています。これらのスクリプトは、リモートマシンをポーリングし、転送を再スケジュールし、古いログファイルと成功しなかった転送を処理します。
uudemon.poll
uudemon.hour
uudemon.admin
uudemon.cleanup
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 シェルスクリプトは、1 時間に 1 回 /etc/uucp/Poll ファイルを読み取ります。Poll ファイル内のマシンのどれかに対するポーリングがスケジュールされると、作業ファイル (C.sysnxxxx) が /var/spool/uucp/nodename ディレクトリに入れられます。nodename は、そのマシンの UUCP ノード名です。
このシェルスクリプトは、1 時間に 1 回ずつ uudemon.hour の前に実行されるようにスケジュールされているので、uudemon.hour が呼び出されたときには、作業ファイルが存在しています。
デフォルトの uudemon.hour シェルスクリプトは次のことを行います。
uusched プログラムを呼び出し、スプールディレクトリを検索して未処理の作業ファイル (C.) を見つけ、それらの作業ファイルをリモートマシンに転送するためにスケジュールする
uuxqt デーモンを呼び出し、スプールディレクトリを検索して、ローカルコンピュータに転送済みで、転送時に処理されなかった実行ファイル (X.) を見つける
デフォルトでは、uudemon.hour は 1 時間に 2 回実行されます。リモートマシンへの呼び出しの失敗の頻度が高いと予測される場合は、このスクリプトの実行頻度を増やすこともできます。
デフォルトの uudemon.admin シェルスクリプトは次のことを行います。
p オプションと q オプション付きで uustat コマンドを実行する。q は、キューに入っている作業ファイル (C.)、データファイル (D.)、実行ファイル (X.) の状態を報告する。p は、ロックファイル (/var/spool/locks) 中に列挙されているネットワークプロセス用のプロセス情報を表示する
デフォルトの uudemon.cleanup シェルスクリプトは次のことを行います。
/var/uucp/.Log ディレクトリから個々のマシンに関するログファイルを取り出し、それらをマージし、他の古いログ情報とともに /var/uucp/.Old ディレクトリに入れる
7 日以上経過している作業ファイル (C.)、7 日以上経過しているデータファイル (D.)、2 日以上経過している実行ファイル (X.) を、スプールファイルから削除する
配達できなかったメールを送信元に戻す
TCP/IP ネットワーク上での UUCP を実行するには、この節で説明するようにいくつかの変更が必要になります。
/etc/inetd.conf の中で、次のエントリの前にコメントマーク (#) が付いていないことを確認します。
uucp stream tcp nowait root /usr/sbin/in.uucpd in.uucpd |
/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 デーモンは、認証のためにリモートマシンがログインとパスワードを送ることを想定しているので、getty や login と同様に、ログインとパスワードを要求します。
次に示す /etc/inet/services のエントリは、UUCP 用のポートを設定します。
uucp 540/tcp uucpd # uucp daemon |
このエントリを変更する必要はありません。しかし、マシンがネームサービスとして NIS または NIS+ を実行する場合は、/etc/services の /etc/nsswitch.conf エントリを変更して、まず files、次に nis または nisplus が検査されるようにする必要があります。
UUCP の設定が終われば、その後の保守は簡単です。この節では、セキュリティ、保守、障害追跡に関連する UUCP の作業について説明します。
デフォルトの /etc/uucp/Permissions ファイルは、UUCP リンクに関する最大限のセキュリティを提供します。デフォルトの Permissions ファイルには、エントリは入っていません。
定義する各マシンについて、以下に示す追加パラメータを設定できます。
ローカルマシンからファイルを受け取る方法
読み取り権と書き込み権が与えられるディレクトリ
リモート実行に使用できるコマンド
典型的な Permissions のエントリは次のようになります。
MACHINE=datsun LOGNAME=Udatsun VALIDATE=datsun COMMANDS=rmail REQUEST=yes SENDFILES=yes |
このエントリでは、(システム内のどこかからではなく、通常の UUCP ディレクトリとの間での) ファイルの送信と受信が可能となり、ログイン時に UUCP ユーザー名の認証が行われます。
UUCP の保守に必要な作業の量はさほど多くはありません。「uudemon.poll シェルスクリプト」で述べたように、crontab ファイルを正しい場所に配置してあることを確認する以外に注意する必要があるのは、メールファイルと公共ディレクトリが大きくなるという点だけです。
UUCP のプログラムとスクリプトが生成する電子メールメッセージは、すべてユーザー ID uucp に送られます。管理者がユーザー uucp として頻繁にログインしていないと、メールが蓄積されている (このためディスク空間を浪費している) ことに気付かない場合があります。この問題を解決するには、/etc/aliases の中に別名を 1 つ作り、root か自分自身、そして他の UUCP 保守責任者に、電子メールをリダイレクトします。aliases ファイルを変更した後で、newaliases コマンドを実行するのを忘れないようにしてください。
ディレクトリ /var/spool/uucppublic は、UUCP がデフォルトでファイルをコピーできる場所として、すべてのシステムに対して提供されているディレクトリです。すべてのユーザーが、/var/spool/uucppublic への移動、その中のファイルの読み書きを行う権限を持っています。しかし、スティッキビットが設定されているため、このディレクトリのモードは 01777 です。したがって、ユーザーには、このディレクトリにコピーされ uucp に所有されているファイルを削除することはできません。このディレクトリからファイルを削除できるのは、root または uucp としてログインした UUCP 管理者だけです。このディレクトリ内に無秩序にファイルが蓄積するのを防ぐために、定期的に整理する必要があります。
このような定期的な整理がユーザーにとって面倒な場合は、スティッキビットを削除するよりも、各ユーザーに uuto と uupick を使用するよう奨励してください。スティッキビットはセキュリティのために設定されています (uuto と uupick の使い方については、uuto(1C) のマニュアルページを参照してください)。このディレクトリのモードの制限の度合を強めて、たとえば特定のユーザーグループだけに使用を限定することもできます。だれかがディスク空間を使い切ってしまうことが望ましくないのであれば、そのディスクへの UUCP アクセスを拒否することもできます。
ここでは、UUCP に関する一般的な問題を解決するための手順について説明します。
モデムや ACU で、適正に動作していないものがないかどうかを、いくつかの方法で検査できます。
cu -d -lline を実行する。line は /dev/cua/a である。これによって、特定の回線を介した呼び出しを行い、その試行に関するデバッグ情報を表示できる。この回線は、/etc/uucp/Devices ファイルの中で direct として定義されていなければならない (回線が自動ダイヤラに接続している場合は、コマンド行の終わりに電話番号を追加する必要がある。あるいは、デバイスを direct として設定する必要がある)。
特定のマシンと接続しようとすると障害が発生する場合は、Systems ファイルの中の情報が最新のものであるかどうかを確認してください。次のようなマシンに関する情報が、最新でなくなっている可能性があります。
特定のマシンに接続できない場合は、Uutry と uucp を使って、そのマシンに対する通信を検査できます。
接続を調べるために、/usr/lib/uucp/Uutry -r machine を入力し、Return を押します。
machine には、接続に問題のあるマシンのホスト名を指定します。このコマンドは次のことを行います。
Uutry を使っても問題の原因が分からない場合は、 uucp -r file machine¥!/dir/file と入力し Return キーを押すことによって、ジョブをキューに入れてみます。
file には転送したいファイル、machine には転送先のマシンを指定します。/dir/file には、相手のマシンのどこにファイルを転送するかを指定します。r オプションを指定すると、ジョブはキューに入りますが、転送は開始されません。
ここで、再度 Uutry を使用します。
それでも問題が解決できないときは、ご購入先への連絡が必要になります。デバッグ出力を保存しておいてください。これは問題の診断に役立ちます。
Uutry で -x n オプションを使用して、デバッグのレベルを増減することも考えてみてください。n はデバッグレベルを指定します。Uutry のデフォルトのデバッグレベルは 5 です。
デバッグレベル 3 では、接続がいつどのように確立されたかについての基本的な情報は提供されますが、転送自体について提供される情報は多くはありません。これに対して、デバッグレベル 9 では、転送処理に関するすべての情報が網羅されます。デバッグは転送の両端で行われるという点に注意してください。比較的大きいテキストについて 5 より高いレベルのデバッグを行いたい場合は、相手サイトの管理者に連絡して、デバッグを行う時期について同意を得てください。
UUCP のエラーメッセージには、ASSERT と STATUS の 2 つの種類があります。
プロセスがアボートされた場合は、ASSERT メッセージが /var/uucp/.Admin/errors に記録されます。この種類のメッセージには、ファイル名、sccsid、回線番号、テキストが含まれています。この種類のメッセージが出るのは、一般にシステムに問題がある場合です。
STATUS エラーメッセージは /var/uucp/.Status ディレクトリに格納されます。このディレクトリ内には、ローカルコンピュータが通信しようとした各リモートマシンについて、それぞれファイルが作られます。これらのファイルには、試行した通信と、その通信が成功したかどうかについての状態情報が入っています。
以下のコマンドを使用して、基本的なネットワーク情報を検査するために使用できます。
uucheck -v - このコマンドは、uucp が必要とするファイルとディレクトリが存在しているかどうかを検査するために使用します。また、Permissions ファイルも検査して、設定してあるアクセス権に関する情報を出力します。
この節には、UUCP に関連したエラーメッセージを示します。
表 13-1 に ASSERT エラーメッセージをリストします。
表 13-1 ASSERT エラーメッセージ
表 13-2 に一般的な STATUS エラーメッセージを示します。
表 13-2 UUCP の STATUS エラーメッセージ
エラーメッセージ |
説明と処置 |
---|---|
状態は良好。 |
|
現在この呼び出し用に使用可能なデバイスがない。 該当のシステムについて Devices ファイル内に有効なデバイスがあるかどうかを確認してください。そのシステムの呼び出しに使用するデバイスが Systems ファイル内にあるかどうかを検査してください。 |
|
Systems ファイルに指定されている日時以外の時点で、システムに対する呼び出しが行われた。 |
|
会話中。 |
|
特定のマシンのログインが失敗した。ログインまたはパスワードが正しくないか、番号が正しくないか、きわめて低速のマシンであるか、Dialer-Token-Pairs スクリプトによる処理が失敗した。 |
|
起動に成功した後で対話が失敗した。一方の側がダウンしたか、プログラムがアボートしたか、回線 (リンク) が切断されたことが考えられる。 |
|
リモートマシンがまったく応答しない。ダイヤラが不良であるか、電話番号が正しくないことが考えられる 。 |
|
あるマシンが、Permissions ファイルの条件を満たしていないログインとマシン名を使って、ローカルマシンを呼び出そうとした。偽装の疑いがある。 |
|
使用しようとしている呼び出しデバイスは、現在ロックされ、他のプロセスに使用されている。 |
|
ASSERT エラーが発生した。/var/uucp/.Admin/errors ファイルにエラーメッセージが入っているかどうかを検査し、「UUCP のエラーメッセージ」を参照してください。 |
|
システムが Systems ファイルの中に記述されていない。 |
|
アクセスしようとしたデバイスが存在しないか、またはモードが正しくない。Systems ファイルと Devices ファイルの中の該当のエントリを検査してください。 |
|
デバイスがオープンできない |
|
呼び出されたマシンは、予期したのとは異なる名前を示している。 |
|
呼び出されたマシンは、そのマシンがローカルマシンをコールバックする必要があることを示している。 |
|
リモートマシンは、ローカルマシンに関連する LCK ファイルを持っている。そのリモートマシンがローカルマシンを呼び出そうとしている可能性がある。そのマシンの UUCP のバージョンが古い場合は、プロセスがローカルマシンに接続しようとして失敗し、LCK ファイルがそのまま残されたことが考えられる。UUCP のバージョンが新しく、そのマシンがローカルマシンと通信していない場合は、LCK を持っているプロセスはハングする。 |
|
リモートマシンの Systems ファイルの中に、ローカルマシンのノード名がない。 |
|
ローカルマシンがログインのために使用したログインが、リモートマシンが予期している内容に一致していない。 |
|
理由は不明だが、リモートマシンがローカルマシンとの通信を拒否した。リモートマシンが標準バージョンの UUCP を使用していないことが考えられる。 |
|
ログインは成功したが、初期ハンドシェークに失敗した。 |
|
通常、これは DIAL FAILED と同じ。しかしこれが頻発する場合は、Dialers ファイル内の呼び出し側スクリプトに原因があることが考えられる (Uutry を使って検査してください)。 |
表 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 |
オペレーティングシステムエラーが検出された。これは、「フォーク不可」や「パイプ作成不可」などのような状態を示す。たとえば、getuid が passwd ファイル内に存在しないユーザーを戻した場合などが含まれる。 |
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 |
この操作を行うための適正なアクセス権がユーザーにない。これはファイルシステムの問題を示すものではなく (その場合は NOINPUT や CANTCREAT などが使用される)、より高いレベルのアクセス権が必要であることを意味する。たとえば、kre は、メールを送ることのできる学生を制限するために、このメッセージを使用する。 |
78 |
Configuration Error |
構成にエラーがある。 |
79 |
Entry Not Found |
エントリが見つからない。 |
79 |
Maximum Listed Value |
エラーメッセージの最大番号。 |