この章では、マシンに関連したデータベースファイルを変更した後で、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.3 93/02/02 SMI" # 48 8,12,16 * * * /usr/libuucp/uudemon.admin 45 23 * * * /usr/lib/uucp/uudemon.cleanup 0 * * * * /usr/lib/uucp/uudemon.poll 11,41 * * * * /usr/lib/uucp/uudemon.hour
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 |
エラーメッセージの最大番号 |