PPP の概要情報
PPP の計画情報
ダイアルアップ PPP リンクのセットアップの手順説明
専用回線 PPP リンクのセットアップの手順説明
PPP リンクに対する認証のセットアップの手順説明
DSL 機器を介した PPP リンクをサポートする PPPoE トンネル作成の手順説明
PPP リンクの保守および問題を解決する手順の説明
PPP の使用方法についての詳細なリファレンス情報
前のバージョンの Solaris PPP (asppp) から Solaris PPP 4.0 に移行する際の手順説明
UUCP の背景情報
UUCP のセットアップと障害追跡の手順説明
UUCP データベースファイル、UUCP 構成ファイル、UUCP シェルスクリプト、UUCP 障害追跡情報の参考資料
Solaris PPP 4.0 では、ポイントツーポイントプロトコル (PPP) を使用することで、物理的に離れた場所にある 2 つのコンピュータがさまざまな媒体を介して互いに通信することができます。Solaris 9 オペレーティング環境には、基本インストールの一部に Solaris PPP 4.0 が組み込まれています。
この章では Solaris PPP 4.0 について紹介します。ここでは、次の内容を説明します。
Solaris PPP 4.0 は、TCP/IP プロトコル群に含まれるデータリンクプロトコルとしてポイントツーポイントプロトコル (PPP) を実装しています。PPP は、2 つの端点にあるマシン間でデータを電話回線などの通信媒体を介して転送する方法について記述しています。
PPP は、1990 年代の初期から、通信リンクを介してデータグラムを送信するために幅広く使用されてきたインターネット標準です。PPP 標準は、Internet Engineering Task Force (IETF) のポイントツーポイントワーキンググループによって RFC 1661 に定義されています。PPP は一般に、リモートコンピュータがインターネットサービスプロバイダ (ISP) を呼び出したり、着呼を受信するように構成されている企業サーバーを呼び出したりするときに使用されます。
Solaris PPP 4.0 は、広く普及している Australian National University (ANU) PPP–2.4 に基づいて PPP 標準を実装しています。PPP リンクは非同期と同期の両方をサポートしています。
さまざまなバージョンの PPP 標準がインターネットコミュニティで広く使用されています。ANU PPP-2.4 は、Linux、Tru64 UNIX、および次の BSD 系統の主要 OS で採用されています。
FreeBSD
OpenBSD
NetBSD
Solaris PPP 4.0 は、Solaris オペレーティング環境で実行されているマシンに ANU PPP-2.4 の高度な構成機能を提供します。Solaris PPP 4.0 が実行されているマシンでは、PPP 標準が実行されているマシンに PPP リンクを簡単に設定できます。
ANU ベースの PPP 以外で Solaris PPP 4.0 と正常に相互運用できるものは、次のとおりです。
Solaris 2.4 から Solaris 8 までのオペレーティング環境で稼働する Solaris PPP (別名 asppp)
SolsticeTM PPP 3.0.1
Microsoft Windows 98 DUN
Cisco IOS 12.0 (同期)
Solaris PPP 4.0 は、Solaris 9 オペレーティング環境がサポートする PPP です。Solaris 9 オペレーティング環境には、 以前の非同期 PPP (asppp) ソフトウェアは組み込まれていません。非同期 PPP の構成については、『Solaris 8 System Administrator Collection』(http://docs.sun.com) を参照してください。
現在 asppp を使用しているユーザーには、Solaris PPP 4.0 への移行をお勧めします。2 つの Solaris PPP 間の技術的な相違点は次のとおりです。
転送モード
asppp は非同期通信だけに対応します。Solaris PPP 4.0 は非同期通信と同期通信の両方に対応します。
構成プロセス
asppp の設定には、asppp.cf 構成ファイル、3 つの UUCP ファイル、および ifconfig コマンドが必要です。さらに、マシンにログインするユーザーのために、あらかじめインタフェースを構成しておく必要があります。
Solaris PPP 4.0 の設定では、PPP 構成ファイルのオプションを定義するか、オプションを指定して pppd コマンドを発行します。また、構成ファイルとコマンド行の両方の方法を組み合わせて使用することもできます。Solaris PPP はインタフェースを動的に作成して削除します。各ユーザーのために PPP インタフェースを構成する必要はありません。
asppp が提供しない Solaris PPP 4.0 の機能
MS-CHAPv1 および MS-CHAPv2 認証
ADSL ブリッジをサポートする PPP over Ethernet (PPPoE)
PAM 認証
プラグインモジュール群
IPv6 アドレス指定
Deflate 圧縮または BSD 圧縮を使用するデータ圧縮
既存の asppp 構成を Solaris PPP 4.0 に変換する場合は、このリリースが提供する変換スクリプトを使用できます。詳細は、asppp から Solaris PPP 4.0 に変換する方法を参照してください。
PPP に関する多くの情報は印刷物やオンラインで入手可能です。参考資料のいくつかを以降で示します。
ANU PPP など、幅広く使用されている PPP については、次の図書を参照してください。
Carlson, James 著、『PPP Design, Implementation, and Debugging』第 2 版、Addison-Wesley、2000
Sun, Andrew 著、『Using and Managing PPP』、O'Reilly & Associates、1999
PPP の一般的な情報については、次の Web サイトを参照してください。
pppd に関するよくある質問 (FAQ) などについては、Sun Microsystems の Internet Engineering グループが提供する Web サイト (http://playground.sun.com/pppd) を参照してください。
ANU PPP については、Australian National University の PPP リポジトリ (http://.pserver.samba.org/cgi-bin/cvsweb/ppp/) を参照してください。
技術情報、FAQ、Solaris システム管理、および前バージョンの PPP については、Sun Microsystem のシステム管理者の資源 (http://www.sun.com/bigadmin/home/index.html) を参照してください。
さまざまな PPP のモデム構成とアドバイスについては、Stokely Consulting が提供する Web Project Management & Software Development の Webサイト ( http://www.stokely.com/unix.serial.port.resource/ppp.slip.htm) を参照してください。
PPP に関する有用な Internet RFC は次のとおりです。
RFC 1661 と RFC 1662。PPP プロトコルの主な機能を解説している
RFC 1334。パスワード認証プロトコル (PAP) とチャレンジハンドシェーク認証プロトコル (CHAP) などの認証プロトコルを解説している
RFC 2516。PPP over Ethernet (PPPoE) を解説している
PPP RFC のコピーを入手するには、IETF RFC の Web ページ (http://www.ietf.org/rfc.html) で RFC の番号を指定してください。
Solaris PPP 4.0 の実装については、次のマニュアルページを参照してください。
pppd(1M)
chat(1M)
pppstats(1M)
pppoec(1M)
pppoed(1M)
sppptun(1M)
snoop(1M)
この節では、PPP 構成について説明します。また、このマニュアルで使用する用語についても説明します。
Solaris PPP 4.0 は次の構成をサポートします。
スイッチ型のアクセス構成 (ダイアルアップ)
固定型の構成 (専用回線)
上図は、基本的な PPP リンクを示しています。リンクの構成要素は、次のようになります。
2 つのマシン。通常、ピアと呼ばれ、物理的に互いに離れた場所に配置されている。ピアは、サイトの要件によってパーソナルコンピュータ、エンジニアリングワークステーション、大規模サーバー、商用ルーターなどが考えられる
各ピアに対するシリアルインタフェース。Solaris マシンのインタフェースは、構成する PPP が非同期か同期かによって、cua、hih などが考えられる
シリアルケーブル、モデム接続などの物理リンク、またはネットワークプロバイダが提供する T1 回線や T3 回線などの専用回線
もっともよく使用される PPP 構成は、ダイアルアップリンクです。ダイアルアップリンクでは、ローカルピアがリモートピアをダイアルアップして接続を確立し、PPP を実行します。ダイアルアッププロセスでは、ローカルピアがリモートピアの電話番号を呼び出してリンクを開始します。
一般的なダイアルアップの使用例では、ユーザーの自宅にあるコンピュータが、着呼を受信するように構成されている ISP 側のピアを呼び出します。別のダイアルアップの使用例では、企業サイトでローカルマシンが PPP リンクを使用して、別の建物内にあるピアにデータを転送します。
このマニュアルでは、ダイアルアップ接続を開始するローカルピアは、ダイアルアップマシンと呼びます。着呼を受信するピアは、ダイアルインサーバーと呼びます。このマシンは実際にはダイアルアウトマシンがターゲットにするマシンに過ぎず、真の意味でのサーバーではない場合もあります。
PPP はクライアントサーバープロトコルではありません。PPP のドキュメントの中には、「クライアント」や「サーバー」という用語を、電話呼び出しによる確立のことを示すために使用しているものがあります。ダイアルインサーバーは、ファイルサーバーやネームサーバーのような真の意味でのサーバーではありません。ダイアルインサーバーという用語は、ダイアルインマシンが複数のダイアルアウトマシンにネットワークでのアクセス可能性を「提供」していることから、PPP 用語として幅広く使用されています。それでもダイアルインサーバーは、現実には、ダイアルアウトマシンのターゲットピアにすぎません。
リンクのダイアルアウト側 (場所 1) の構成は、次の要素から成ります。
ダイアルアウトマシン。一般に、個々の家庭のパーソナルコンピュータやワークステーション
ダイアルアウトマシン上のシリアルインタフェース。/dev/cua/a または /dev/cua/b は、Solaris ソフトウェアが実行されているマシン上で発呼に使用する標準のシリアルインタフェースである
電話のジャックに接続される非同期モデムまたは ISDN 端末アダプタ (TA)
電話会社の電話回線やサービス
電話ネットワークに接続される電話のジャックまたは類似のコネクタ
非同期モデムまたは ISDN TA
ダイアルインサーバー上のシリアルインタフェース。ttya または ttyb は、ダイアルインサーバー上で着呼に使用するシリアルインタフェースである
ダイアルインサーバー。企業のイントラネットなどのネットワークや ISP のインスタンス内からグローバルインターネットに接続される
外付けの ISDN TA はモデムよりも高速ですが、両者の構成方法は基本的に同じです。両者の主な相違は chat スクリプト間の構成にあります。ISDN TA の場合、chat スクリプトの記述では、TA の製造元に固有のコマンドが必要になります。ISDN TA 用の chat スクリプトについては、外部 ISDN TA 用 chat スクリプト を参照してください。
ダイアルアウトとダイアルインの両方のピアにある PPP 構成ファイルには、リンクを設定するための命令群が含まれています。ダイアルアップリンクが開始されると、次のプロセスが発生します。
ダイアルアウトマシン上のユーザーまたはプロセスは、pppd コマンドを実行してリンクを開始する
ダイアルアウトマシンは PPP 構成ファイルを読み取る。次に、シリアル回線を介して、ダイアルインサーバーの電話番号などの命令群をモデムに送信する
モデムは電話番号をダイアルして、ダイアルインサーバー側のモデムと電話接続を確立する。
ダイアルアウトマシンは、必要に応じて、ダイアルインサーバーにコマンドを送信し、サーバー側の PPP を呼び出す
ダイアルインサーバーに接続されているモデムは、ダイアルアウトマシン側のモデムとリンクのネゴシエーションを開始する。
ダイアルアウトマシンが、モデムとダイアルインサーバーに送信する一連のテキスト文字列は、chat スクリプトと呼ばれるファイルに格納されている
モデム同士のネゴシエーションが完了すると、ダイアルアウトマシン側のモデムは「CONNECT」を通知する
両方のピア側の PPP は確立フェーズに入る。このフェーズでは、リンク制御プロトコル (LCP) が基本的なリンクパラメータと認証の使用をネゴシエートする
ピアは、必要に応じて、互いを認証する
PPP のネットワーク制御プロトコル (NCP) は、IPv4 や IPv6 などのネットワークプロトコルの使用をネゴシエートする
固定型の専用回線の PPP 構成には、リンクで接続された 2 つのピアが含まれます。リンクは、プロバイダからリースされたスイッチ型または非スイッチ型のデジタルサービスで構成されています。Solaris PPP 4.0 は、全二重でポイントツーポイントの専用回線媒体を介して動作します。通常、会社では、ネットワークプロバイダから専用リンクをレンタルして、ISP または他のリモートサイトに接続します。
ダイアルアップと専用回線のリンクはともに、通信媒体で接続されている 2 つのピアから成っています。次の表は、2 つのリンクタイプの相違をまとめています。
専用回線 |
ダイアルアップ回線 |
---|---|
システム管理者による電源切断または電源障害による電源切断がないかぎり常時接続されている |
ユーザーがリモートピアを呼び出そうとするとき開始される |
同期通信を使用する |
非同期通信を使用する |
プロバイダからのレンタル |
既存の電話回線を使用する |
同期装置を必要とする |
低コストのモデムを使用する |
専用インタフェースを必要とする |
通常のコンピュータに組み込まれている標準のシリアルインタフェースを使用する |
専用回線リンクの構成要素は次のとおりです。
2 つのピア。リンクの両端に 1 つずつ存在する。各ピアは、ワークステーションかサーバーである。通常ピアは、ネットワークまたはインターネットともう一方の側のピアとの間のルーターとして機能する
同期インタフェース。各ピア上に存在する。Solaris ソフトウェアが実行されている一部のマシンは、専用回線に接続するために、HSI/S などの同期インタフェースカードを購入する必要がある。UltraSPARCTM ワークステーションなどのマシンには同期インタフェースが内蔵されている
CSU/DSU 同期デジタル装置。各ピア上に存在し、同期ポートを専用回線に接続する。
現場の事情によって、CSU は DSU に組み込まれていたり、個人で所有していたり、プロバイダからリースしていたりする。DSU はマシンに標準の同期シリアルインタフェースを提供する。フレームリレーを使用する場合、フレームリレーアクセスデバイス (FRAD) が、シリアルインタフェースに適合するように調整する
専用回線。スイッチ型または非スイッチ型のデジタルサービスを提供する。専用回線のデジタルサービスには、SONET/SDH、Frame Relay PVC、T1 などがある
SONET は、オクテット同期リンクと呼ばれています。PPP は、SONET 回線で非同期フレームと類似のフレーム機構を使用します。PPP は予想されるビット同期プロトコルは使用していません。
ほとんどのタイプの専用回線では、ピアは互いにダイアルすることはありません。会社では専用回線サービスを購入して、2 つの定められた場所の間を明示的に接続します。場合によって、専用回線の各端にある 2 つのピアは同じ会社でも物理的に離れた場所に存在することもあります。別の事例では、会社が、ISP に接続されている専用回線上にルーターを設定している場合があります。
専用回線の固定型のリンクは設定が簡単ですが、ダイアルアップリンクほどは普及していません。固定型のリンクは chat スクリプトを必要としません。専用回線の場合、両方のピアは互いを知っているので、認証を使用しないのが普通です。2 つのピアがリンクを介して PPP を開始すると、リンクはアクティブな状態を続けます。専用回線に障害が発生したり、どちらかのピアが明示的にリンクを終了したりしないかぎり、専用回線の固定型のリンクはアクティブな状態を続けます。
Solaris PPP 4.0 が実行されている専用回線上のピアは、ダイアルアップリンクを定義する構成ファイルとほぼ同じものを使用します。
専用回線を介した通信を開始する場合、次のプロセスが発生します。
両方のピアは自分の PPP 構成ファイルを読み取る
両方のピアは通信パラメータをネゴシエートする
IP リンクが確立される
認証は、要求しているのがユーザー本人であることを確認するためのプロセスです。UNIX のログインの流れは、次のように簡単な認証形式です。
login コマンドを入力すると、ユーザーに名前とパスワードの入力を求めるプロンプトが表示される
次に login は、ユーザーを認証するために、入力された名前とパスワードをパスワードデータベースから探そうとする
データベース中にユーザー名とパスワードが存在する場合、ユーザーは認証されて、システムへのアクセスが許可される。データベース中にユーザー名とパスワードが存在しない場合、ユーザーはシステムへのアクセスを拒否される
デフォルトでは、Solaris PPP 4.0 は、デフォルトの経路が指定されていないマシン上では認証を要求しません。したがって、デフォルトの経路が指定されていないローカルマシンはリモート呼び出しを認証しません。逆に、マシンにデフォルトの経路が定義されていれば、マシンは、デフォルトでリモート呼び出しを認証します。
必要な場合、自分のマシンに PPP リンクを設定しようとしている呼び出し側の識別情報を、PPP 認証プロトコルを使って確認できます。逆に、呼び出し側を認証するピアをローカルマシンが呼び出す必要がある場合は、PPP 認証情報をローカルマシンに構成しておく必要があります。
PPP リンク上の呼び出し側マシンは、リモートピアに対して識別情報を示す必要があるので、認証される側とみなされます。ピアは、認証する側とみなされます。認証する側は、呼び出し側の識別情報をセキュリティプロトコル用の適切な PPP ファイルから探し、その呼び出し側を認証したり認証を拒否したりします。
多くの場合、PPP 認証をダイアルアップリンクに構成します。呼び出しが開始されると、ダイアルアウトマシンが認証される側になります。ダイアルインサーバーは認証する側になります。サーバーはデータベースを秘密ファイルの形式で保持します。このファイルには、サーバーに PPP リンクを設定する許可が与えられているすべてのユーザーが記述されています。許可が与えられているユーザーは信頼できる呼び出し側とみなされます。
一部のダイアルアウトマシンには、ダイアルアウトマシンの呼び出しに対する応答でリモートピアに認証情報の提供を要求するものがあります。このような場合は、役割が逆転し、リモートピアは認証される側になり、ダイアルアウトマシンは認証する側になります。
PPP 4.0 は専用回線でピアによる認証を禁止していませんが、通常は専用回線で認証を使用することはありません。専用回線規約では、回線の両端に存在する両者が互いをよく知っており、信頼していることが特徴となっています。しかし、PPP 認証は管理が簡単なので、専用回線にも認証を実装することをまじめに検討する必要があります。
PPP の認証プロトコルは、パスワード認証プロトコル (PAP) とチャレンジハンドシェーク認証プロトコル (CHAP) です。 各プロトコルは、ローカルマシンにリンクする許可が与えられている各呼び出し側に対して、識別情報が格納された秘密データベースやセキュリティ資格情報を使用します。PAP については、パスワード認証プロトコル (PAP)を参照してください。CHAP については、チャレンジハンドシェーク認証プロトコル (CHAP)を参照してください。
PPP リンクでの認証は任意です。また、認証では、ピアが信頼されていることは確認しますが、PPP 認証に機密保護を提供していません。機密保護では、IPsec、PGP、SSL、Solaris セキュアシェルなどの暗号化ソフトウェアを使用します。
Solaris PPP 4.0 は、RFC 1968 に記述されている PPP Encryption Control Protocol (ECP) を実装していません。
次の場合に、PPP 認証の実装を検討してください。
会社が、公衆電話交換網を介してユーザーから着呼を受け取る
会社のファイアウォールを介してネットワークにアクセスする場合やセキュリティで保護されたトランザクションに関係する場合に、会社のセキュリティポリシーでリモートユーザーに認証資格情報の提供を要求している
標準の UNIX パスワードデータベース (/etc/passwd、NIS、NIS+、LDAP、または PAM) と照合して呼び出し側を認証したいとする。この場合は PAP 認証を使用する
会社のダイアルインサーバーがネットワークのインターネット接続も提供する。この場合は PAP 認証を使用する
シリアル回線が、リンクのどちらか端にあるネットワークやマシン上のパスワードデータベースよりもセキュリティの保護が弱い。この場合は CHAP 認証を使用する
多くのネットワークプロバイダと自宅で仕事している個人は、デジタル加入者回線 (DSL) 技術を使用して、高速なネットワークアクセスを実現します。DSL ユーザーをサポートするために、Solaris PPP 4.0 は PPP over Ethernet (PPPoE) 機能を組み込んでいます。PPPoE 技術を使用することで、複数のホストが 1 つの Ethernet リンクを介して 1 つ以上の地点に PPP セッションを実行できます。
DSL ユーザー (自分自身も含む場合もある) をサポートする。DSL サービスプロバイダは、DSL 回線を介してサービスを受け取るために、ユーザーに PPPoE トンネルの構成を要求することがある
サイトが、顧客に PPPoE を提供する ISP である
PPPoE は、RedBack Networks が生み出した独自のプロトコルです。PPPoE は、別バージョンの標準 PPP ではなく検出プロトコルです。PPPoE のシナリオでは、最初に PPP 通信を開始するマシンが、PPPoE を実行しているピアを検出する必要があります。PPPoE プロトコルは、Ethernet ブロードキャストパケットを使ってピアを検出します。
検出プロセスを終了したら、PPPoE は、開始したホスト (PPPoE クライアント) からピア (PPPoE アクセスサーバー) まで Ethernet ベースのトンネルを設定します。トンネリングとは、あるプロトコルを、別のプロトコルで実行する方法です。PPPoE を使用して、Solaris PPP 4.0 は PPP に Ethernet IEEE 802.2 を介したトンネルを作成します。PPP と Ethernet IEEE 802.2 はともにデータリンクプロトコルです。設定された PPP 接続は、PPPoE クライアントとアクセスサーバーの間で専用リンクのように動作します。PPPoE については、DSL サポート用の PPPoE トンネルの作成を参照してください。
次の図に示すように、PPPoE 構成には、消費者、電話会社、およびサービスプロバイダという 3 つの関係者が存在します。
システム管理者として、消費者の PPPoE 構成を助けることがあります。PPPoE 消費者の一般的なタイプは、DSL 回線を介して PPPoE を実行する個人です。別の PPPoE 消費者は、上図に示すように、従業員が PPPoE トンネルを実行できるように DSL 回線を購入する会社です。
企業消費者が PPPoE を使用する主な理由は、高速の DSL 機器を介して多くのホストに PPP 通信を提供するためです。通常、単独の PPPoE クライアントは、個人で DSL モデムを持ちます。また、ハブに接続されているクライアントのグループは、Ethernet 回線によって同じハブに接続されている DSL モデムを共有することがあります。
DSL 機器は技術的にはモデムではなくブリッジです。ただし、実際にはこれらのデバイスをモデムと呼んでいるので、このマニュアルでは、「DSL モデム」という用語を使用します。
PPPoE は、DSL モデムに接続されている Ethernet 回線上のトンネルを介して PPP を実行します。その回線はスプリッタに接続され、スプリッタは電話回線に接続しています。
PPPoE のシナリオでは、電話会社は中間に位置します。 電話会社は、電話回線を介して受信する信号を、デジタル加入者線アクセスマルチプレクサ (DSLAM) と呼ばれるデバイスを使って分割します。 DSLAM は分割した信号を別の線、電話サービス用アナログ線、および PPPoE 用デジタル線に送り出します。デジタル線は ATM データネットワークを介してトンネルを DSLAM から ISP まで延長します。
ISP は、ATM データネットワークから渡される PPPoE 転送をブリッジを介して受信します。ISP では、PPPoE が実行されているアクセスサーバーが PPP リンクのピアとして機能します。アクセスサーバーは、図 25–2 で紹介したダイアルインサーバーと機能的に類似していますが、アクセスサーバーがモデムを使用しない点が異なります。アクセスサーバーは、個々の PPPoE セッションをインターネットアクセスなどの通常の IP トラフィックに変換します。
ISP のシステム管理者は、アクセスサーバーの構成と維持を行います。
PPPoE トンネルは最初からセキュリティ対策が行われていません。PAP または CHAP を使用することで、トンネルを介して実行している PPP リンクにユーザー認証を提供できます。
PPP リンクの設定には、作業計画や PPP と無関係な作業など、さまざまな個別の作業が含まれています。この章では、もっとも一般的な PPP リンク、認証、および PPPoE を計画する方法について説明します。
第 26 章「PPP リンクの計画 (手順)」に続く各章では、特定リンクの設定方法について構成例を使って説明します。これらの構成例はこの章で紹介します。
PPP では、実際にリンクを設定する前に作業計画を立てる必要があります。さらに、PPPoE トンネルを使用する場合は、まず PPP リンクを設定し、それからトンネルを提供する必要があります。次の作業マップは、この章で説明する大規模な作業計画を示しています。構成するリンクタイプによっては、一般的な作業だけで十分な場合があります。また、リンク、認証、および PPPoE の各作業が必要になる場合もあります。
表 26–1 PPP 計画 (作業マップ)
作業 |
説明 |
参照先 |
---|---|---|
ダイアルアップ PPP リンクを計画する |
ダイアルアウトマシンまたはダイアルインサーバーの設定に必要な情報を収集する | |
専用回線リンクを計画する |
専用回線にクライアントを設定するための必要情報を収集する | |
PPP リンクの認証を計画する |
PPP リンクに PAP 認証または CHAP 認証を構成するための必要情報を収集する | |
PPPoE トンネルを計画する |
PPP リンクが実行できる PPPoE トンネルを設定するための必要情報を収集する |
ダイアルアップリンクはもっともよく使用される PPP リンクです。この節では、次の内容について説明します。
ダイアルアップリンクの計画情報
第 27 章「ダイアルアップ PPP リンクの設定 (手順)」で使用されるリンク例の説明
ダイアルアウトマシンを構成する前に、次の表に示されている情報を収集します。
この節の計画情報には、認証や PPPoE について収集する情報は含まれていません。 認証計画については、リンクへの認証計画を参照してください。 PPPoE 計画については、PPPoE トンネルを介した DSL サポートの計画を参照してください。
情報 |
作業 |
---|---|
最大モデム速度 |
モデムの製造元が提供するマニュアルを参照する |
モデム接続コマンド (AT コマンド) |
モデムの製造元が提供するマニュアルを参照する |
リンクの一方の端で使用するダイアルインサーバーの名前 |
ダイアルインサーバーの識別が簡単な名前を作成する |
ダイアルインサーバーで必要なログインシーケンス |
ダイアルインサーバーの管理者に問い合わせるか、ダイアルインサーバーが ISP 側に存在すれば、ISP のマニュアルを参照する |
ダイアルインサーバーを構成する前に、次の表に示されている情報を収集します。
この節の計画情報には、認証や PPPoE について収集する情報は含まれていません。 認証計画については、リンクへの認証計画を参照してください。 PPPoE 計画については、PPPoE トンネルを介した DSL サポートの計画を参照してください。
情報 |
操作 |
---|---|
最大モデム速度 |
モデムの製造元が提供するマニュアルを参照する |
ダイアルインサーバーの呼び出しが許可されている人のユーザー名 |
ダイアルインサーバーのユーザーを構成する方法 で説明するようなホームディレクトリを設定する前に、予想されるユーザーの名前を入手する |
PPP 通信の専用 IP アドレス |
会社での IP アドレスの委譲に責任を持つ担当者からアドレスを入手する |
第 27 章「ダイアルアップ PPP リンクの設定 (手順)」 で紹介する作業では、従業員が週に 2、3 日自宅で作業することを許している小さい企業の要件を実施します。一部の従業員は、ホームマシンに Solaris オペレーティング環境が必要になります。また、社内イントラネット上にある作業マシンにリモートログインすることも必要になります。
作業では、次の機能を持つ基本的なダイアルアップリンクを設定します。
ダイアルアウトマシンが、社内イントラネットを呼び出す従業員の自宅に存在する
ダイアルインサーバーは、従業員からの着呼を受信するように構成された社内イントラネット上のマシンである
UNIX スタイルのログインを使用して、ダイアルアウトマシンを認証する。Solaris PPP 4.0 の強力な認証方法は、この会社のセキュリティポリシーには必要ない
次の図は、第 27 章「ダイアルアップ PPP リンクの設定 (手順)」で設定されているリンクを示します。
この図では、リモートホストが電話回線上のモデルを介して Big Company 社のイントラネットにダイアルアウトしています。もう一台のホストが Big Company 社にダイアルアウトするように構成されていますが、現在アクティブではありません。Big Company 社のダイアルインサーバーに接続されているモデムが、リモートユーザーからの呼び出しに順に応答しています。PPP 接続はピア間で確立しています。ダイアルアウトマシンは、イントラネット上のホストマシンにリモートログインできます。
作業 |
参照先 |
---|---|
ダイアルアウトマシンを設定する | |
ダイアルインマシンを設定する | |
ダイアルアップリンクの概要を把握する | |
PPP のファイルとコマンドについて理解する |
専用回線リンクの設定では、プロバイダからリースしているスイッチ型または非スイッチ型サービスの一方の端にピアを構成する必要があります。
専用回線リンクの計画情報
図 26–2 に示されているリンク例の説明
会社がネットワークプロバイダから専用回線リンクをレンタルしている場合は、リンクの自分側の端だけにシステムを構成します。リンクのもう一方の端にあるピアは、別の管理者が維持しています。この管理者は、会社から離れた場所にいるシステム管理者か、ISP 側のシステム管理者のどちらかです。
リンク媒体の他に、リンクの端には次のハードウェアが必要です。
システム用の同期インタフェース
自分の同期装置 (CSU/DSU)
自分のシステム
一部のネットワークプロバイダでは、顧客宅内機器 (CPE) として、ルーター、同期インタフェース、および CSU/DSU が必要です。ただし、必要な機器は、プロバイダや国別の政府規制によって変わります。ネットワークプロバイダでは、必要な装置で専用回線と共に提供されないものは、それに関する情報を提供しています。
ローカルピアを構成する前に、次の表に示されている項目を調べておく必要があります。
表 26–4 専用回線リンクの計画
情報 |
作業 |
---|---|
インタフェースのデバイス名 |
インタフェースカードのマニュアルを参照する。 |
同期インタフェースカードの構成手順 |
インタフェースカードのマニュアルを参照する。この情報は、HSI/S インタフェースを構成する場合に必要である。他のタイプのインタフェースカードでは、構成する必要がない場合がある |
(任意) リモートピアの IP アドレス |
サービスプロバイダのマニュアルを参照するか、リモートピアのシステム管理者に問い合わせる。この情報は、2 つのピア間で IP アドレスがネゴシエートされない場合にだけ必要である |
(任意) リモートピアの名前 |
サービスプロバイダのマニュアルを参照するか、リモートピアのシステム管理者に問い合わせる |
(任意) リンクの速度 |
サービスプロバイダのマニュアルを参照するか、リモートピアのシステム管理者に問い合わせる |
(任意) リモートピアで使用する圧縮 |
サービスプロバイダのマニュアルを参照するか、リモートピアのシステム管理者に問い合わせる |
第 28 章「専用回線 PPP リンクの設定 (手順)」の作業は、中規模会社 (LocalCorp 社) で従業員がインターネットにアクセスできるように、専用回線リンクの構成を実装する方法を示しています。現在、従業員のコンピュータは、会社の私設イントラネットに接続されています。
LocalCorp 社では、高速なトランザクションとイントラネット上の多くの資源に迅速にアクセスすることが必要となっています。LocalCorp 社は、サービスプロバイダの Far ISP 社との間に専用回線を設定する契約を結びます。これにより、LocalCorp 社は電話会社の Phone East 社から T1 回線をリースします。Phone East 社は LocalCorp 社と Far ISP 社との間に専用回線を設置します。その後 Phone East 社は LocalCorp 社に構成済みの CSU/DSU を提供します。
LocalCorp 社はシステムをゲートウェイルーターとして設定する。これにより、パケットは専用回線を介してインターネット上のホストに転送される
Far ISP 社でも顧客からの専用回線を接続するルーターとしてピアを設定する
この図では、LocalCorp 社側の PPP にルーターが設定されています。 ルーターは、hme0 インタフェースを介して社内イントラネットに接続されています。さらにマシンは、HSI/S インタフェース (hih1) を介して CSU/DSU デジタル装置に接続されています。CSU/DSU は設置された専用回線に接続しています。LocalCorp 社の管理者が HSI/S インタフェースと PPP ファイルの構成を終了した後で、 /etc/init.d/pppd と入力すると、LocalCorp 社と Far ISP 社間でリンクが開始されます。
作業 |
参照先 |
---|---|
専用回線にクライアントを設定する | |
専用回線の概要を把握する |
この節では、PPP リンク上で認証を行うための計画情報を提供します。第 29 章「PPP 認証の設定 (手順)」は、自分のサイトで PPP 認証を実装するための作業を示しています。
PPP には、PAP と CHAP の 2 種類の認証があります。PAP の詳細は、パスワード認証プロトコル (PAP)を参照してください。CHAP の詳細は、チャレンジハンドシェーク認証プロトコル (CHAP)を参照してください。
認証をリンクに設定する前に、自分のサイトのセキュリティポリシーに最適な認証プロトコルを選択する必要があります。認証プロトコルの選択が終了したら、ダイアルインマシンまたは呼び出し側のダイアルアウトマシンあるいは両方のマシンに秘密ファイルと PPP 構成ファイルを設定します。自分のサイトに最適な認証プロトコルを選択するには、PPP 認証を使用する理由を参照してください。
認証の設定作業については、第 29 章「PPP 認証の設定 (手順)」を参照してください。自分のサイトに認証を設定することを必須として PPP の全体計画に組み込む必要があります。認証を実装する前に、ハードウェアの組み立てや、ソフトウェアの構成、リンクの動作確認を行なってください。
表 26–5 認証構成の前提条件
情報 |
参照先 |
---|---|
ダイアルアップリンクの構成作業 | |
リンクのテスト作業 | |
サイトのセキュリティ要件 |
会社のセキュリティポリシーポリシーを設定していなければ、PPP 認証の設定を機にセキュリティポリシーを設定する |
自分のサイトに PAP または CHAP を選択する場合のヒント |
PPP 認証を使用する理由。これらのプロトコルについては、接続時の呼び出し元の認証を参照してください。 |
この節では、第 29 章「PPP 認証の設定 (手順)」の手順で使用されている認証事例について説明します。
PAP 認証の設定での作業は、PPP リンク上で PAP 認証を設定する方法を示しています。手順では、例 — ダイアルアップ PPP の構成で紹介した架空の Big Company 社の PAP 事例を使用します。
Big Company 社では、自社のユーザーが自宅で仕事できるようにしたいと考えています。システム管理者は、ダイアルインサーバーに接続するシリアル回線にセキュリティ対策をしたいと考えています。NIS パスワードデータベースを使用する UNIX スタイルのログインは、これまで Big Company 社のネットワークで問題なく機能を果たしてきました。システム管理者は、PPP リンクを介してネットワークに進入してくる呼び出しに UNIX スタイルの認証機構を設定したいと考えています。その結果、システム管理者は PAP 認証を使用する次のシナリオを実装します。
システム管理者は専用のダイアルイン DMZ を作成します。これは、ルーターによって会社のネットワークの後方部と分離されています。DMZ の用語は、軍隊用語の「非武装地帯」から来ています。DMZ はセキュリティ目的のために分離されたネットワークです。通常、DMZ には、Web サーバー、匿名 (anonymous) ftp サーバー、データベース、モデムサーバーなど、会社が一般に公開する資源が含まれています。ネットワーク設計者は通常、DMZ をファイアウォールと会社のインターネット接続の中間に設置します。
図 26–3に示すように、DMZ に存在するのは、ダイアルインサーバーの myserver とルーターだけです。ダイアルインサーバーはリンクの設定時に、呼び出し側に PAP 資格 (ユーザー名とパスワードを含む) の提出を要求します。さらに、ダイアルインサーバーは PAP の login オプションも使用します。したがって、呼び出し側の PAP のユーザー名とパスワードは、ダイアルインサーバーのパスワードデータベースにある UNIX のユーザー名とパスワードに正確に一致する必要があります。
PPP リンクが設定されたら、呼び出し側のパケットはルーターに転送されます。ルーターはパケットを会社のネットワーク上かインターネット上の宛先に転送します。
CHAP 認証の設定 での作業は、CHAP 認証の設定方法を示しています。手順では、例 — 専用回線リンクの構成で紹介した架空の LocalCorp 社の CHAP 事例を使用します。
LocalCorp 社は、ISP の専用回線を介してインターネットに接続できます。LocalCorp 社のテクニカルサポート部では、大量のネットワークトラフィックが発生するので、独立した私設ネットワークが必要になっています。部署のフィールドエンジニアは、問題解決のための情報を入手するために遠隔地からテクニカルサポートのネットワークに頻繁にアクセスする必要があります。私設ネットワークのデータベース内の機密情報を保護するには、リモートでの呼び出し側にログインの許可を与えるために、それらを認証する必要があります。
したがって、システム管理者は、ダイアルアップ PPP 構成に次の CHAP 認証シナリオを実装します。
テクニカルサポート部のネットワークから外部世界にリンクするのは、リンクのダイアルインサーバー側の端に接続しているシリアル回線だけです。システム管理者は、各フィールドサービスエンジニアが所持する PPP 用ラップトップコンピュータを CHAP シークレットなどを組み込んだ CHAP セキュリティで構成します。ダイアルインサーバー上の CHAP シークレットデータベースには、テクニカルサポート内のネットワークに対する呼び出しが許されているすべてのマシンの CHAP 資格が含まれています。
作業 |
参照先 |
---|---|
PAP 認証を設定する | |
CHAP 認証を設定する | |
PPP 認証の詳細を理解する |
接続時の呼び出し元の認証 と pppd(1M) マニュアルページ |
一部の DSL プロバイダは、プロバイダの DSL 回線と高速のデジタルネットワーク上で PPP を実行するために、ユーザーのサイトに PPPoE トンネルを設定するように要求しています。PPPoE の概要については、PPPoE による DSL ユーザーのサポートを参照してください。
PPPoE トンネルには、消費者、電話会社、ISP の 3 つの関係者が存在しています。 PPPoE は、消費者 (会社の PPPoE クライアントか自宅の消費者) 向けか ISP 側のサーバー上のどちらかに構成します。
この節では、クライアントとアクセスサーバーの両方で PPPoE を実行するための計画情報について説明します。次の項目について説明します。
PPPoE ホストとアクセスサーバーの計画情報
例 — PPPoE トンネルの構成で紹介されている PPPoE シナリオの説明
構成前の作業は、トンネルをクライアント側に構成するかサーバー側に構成するかによって異なります。どちらの場合も、電話会社と契約を結ぶ必要があります。電話会社では、クライアントには DSL 回線を提供し、アクセスサーバーにはある形式のブリッジと ATM パイプを提供します。ほとんどの契約では、電話会社はユーザーのサイトに機器を設置します。
PPPoE クライアントの実装は、通常、次の機器から構成されます。
個人が使用するパーソナルコンピュータまたはシステム
DSL モデム。通常は、電話会社かインターネットのアクセスプロバイダが設置する
(任意) ハブ。複数のクライアントが関係するような会社の DSL 消費者向け
(任意) スプリッタ。通常はプロバイダが設置する
多くの異なる DSL 構成が可能です。DSL 構成は、ユーザーや会社のニーズ、プロバイダが提供するサービスによって異なります。
表 26–6 PPPoE クライアントの計画
情報 |
作業 |
---|---|
個人や自分自身のために自宅の PPPoE クライアントを設定する場合に、PPPoE の領域外の設定情報を入手する |
設定の手続きが必要なら、電話会社や ISP に問い合わせる |
会社のサイトに PPPoE クライアントを設定する場合に、PPPoE クライアントシステムの情報を得るためにユーザーの名前を入手する。PPPoE リモートクライアントを構成する場合は、DSL 機器を自宅に設置するための情報をユーザーに提供する必要がある |
認可されたユーザーのリストを会社の管理者に問い合わせる |
PPPoE クライアント上で使用できるインタフェースを探す |
各マシン上で ifconfig -a コマンドを実行し、インタフェース名を探す |
(任意) PPPoE クライアントのパスワードを入手する |
ユーザーに、パスワードの希望を問い合わせる。または、ユーザーにパスワードを割り当てる。このパスワードは UNIX のログイン用ではなく、リンクの認証用に使用する |
PPPoE アクセスサーバーの計画は、データサービスネットワークへの接続を提供する電話会社と共同で行います。電話会社はユーザーのサイトに回線 (通常は ATM パイプ) を設置し、ユーザーのアクセスサーバーに、ある形式のブリッジを提供します。会社が提供するサービスにアクセスする Ethernet インタフェースを構成する必要があります。たとえば、インターネットにアクセスするためのインタフェースのほか、電話会社のブリッジが提供する Ethernet インタフェースも構成します。
表 26–7 PPPoE アクセスサーバーの計画
情報 |
作業 |
---|---|
データサービスネットワークの回線に使用するインタフェース |
ifconfig -a コマンドを実行して、インタフェースを特定する |
PPPoE サーバーが提供するサービスの種類 |
管理者やネットワーク計画者に要件やヒントを問い合わせる |
(任意) 消費者に提供するサービスの種類 |
管理者やネットワーク計画者に要件やヒントを問い合わせる |
(任意) リモートクライアントのホスト名とパスワード |
ネットワーク計画者や契約交渉の担当者に問い合わせる。ホスト名とパスワードは UNIX のログインではなく、PAP 認証や CHAP 認証に使用する |
この節では、第 30 章「PPPoE トンネルの設定 (手順)」で説明する作業の例として、PPPoE トンネルの例を示します。図では、トンネル内のすべてのパーティシパントを示していますが、ユーザーはクライアント側かサーバー側のどちらかの端を管理するだけです。
この例では、MiddleCo 社は従業員に高速なインターネットアクセスを提供することを望んでいます。MiddleCo 社は Phone East 社から DSL パッケージを購入し、Phone East 社はサービスプロバイダの Far ISP 社と契約を結びます。Far ISP 社は、Phone East 社から DSL を購入する顧客にインターネットサービスや IP サービスを提供します。
MiddleCo 社は、サイトに DSL の 1 回線を提供する Phone East 社からパッケージを購入します。パッケージには、MiddleCo 社の PPPoE クライアント用に認証された ISP への専用接続が含まれています。システム管理者は予想される PPPoE クライアントをハブに配線します。Phone East 社の技術者はハブを DSL 機器に配線します。
FarISP 社では、Phone East 社との契約を履行するために、同社のシステム管理者がアクセスサーバー (dslserve) を構成します。このサーバーには、次の 4 つのインタフェースがあります。
le0 – ローカルネットワークと接続する主要なネットワークインタフェース
hme0 – FarISP 社が顧客にインターネットサービスを提供するためのインタフェース
hme1 – 認証された PPPoE トンネル用に MiddleCo 社が使用するインタフェース
hme2 – PPPoE トンネル用に別の顧客が使用するインタフェース
作業 |
参照先 |
---|---|
PPPoE クライアントを設定する | |
PPPoE のアクセスサーバーを設定する | |
PPPoE の詳細情報を入手する |
DSL サポート用の PPPoE トンネルの作成 および pppoed(1M)、pppoec(1M)、sppptun(1M) のマニュアルページ |
この章では、もっとも一般的な PPP リンクであるダイアルアップリンクの構成作業について説明します。ここでは、次の内容を説明します。
ダイアルアップ PPP の設定は、モデムの構成、ネットワークデータベースファイルの変更、および 表 32–1 で説明している PPP 構成ファイルの変更によって行います。
次の表は、ダイアルアップ PPP リンクの両側を構成するための主な作業を示しています。通常は、リンクのどちらか一方 (ダイアルアウトマシンかダイアルインサーバー) だけを構成します。
表 27–1 ダイアルアップの PPP リンクの設定 (作業マップ)
作業 |
説明 |
参照先 |
---|---|---|
1. 構成前の情報を収集する |
リンクを設定する前に、ピアのホスト名、ターゲットの電話番号、モデムの速度など必要なデータを集める | |
2. ダイアルアウトマシンを構成する |
リンクを介して呼び出しを行うマシンに PPP を設定する | |
3. ダイアルインサーバーを構成する |
着呼を受信するマシンに PPP を設定する | |
4. ダイアルインサーバーを呼び出す |
pppd コマンドを入力して、通信を開始する |
この節の作業では、ダイアルアウトマシンの構成方法について説明します。この作業では、図 26–1 で紹介した自宅からのダイアルイン事例を使用します。 予想されるユーザーにマシンを渡す前に、会社での作業があります。経験豊富なユーザーであれば、自宅のマシンの設定を指導することもできます。ダイアルアウトマシンを設定する人は必ずそのマシンのスーパーユーザー権限を持つ必要があります。
作業 |
説明 |
参照先 |
---|---|---|
1. 構成前の情報を収集する |
リンクを設定する前に、ピアのホスト名、ターゲットの電話番号、モデムの速度など必要なデータを集める | |
2. モデムとシリアルポートを構成する |
モデムとシリアルポートを設定する | |
3. シリアル回線通信を構成する |
シリアル回線上の伝送特性を構成する | |
4. ダイアルアウトマシンとピア間の対話を定義する |
chat スクリプトを作成するときに使用する通信データを収集する | |
5. 特定のピア情報を構成する |
個々のダイアルインサーバーを呼び出すための PPP オプションを構成する | |
6. ピアを呼び出す |
pppd コマンドを入力して、通信を開始する |
Solaris PPP 4.0 はテンプレートファイルを提供します。各テンプレートファイルには、特定のPPP 構成ファイルのために一般的なオプションが含まれています。次の表は、ダイアルアップリンクの設定に使用できるテンプレートのサンプルと、それらと同等の Solaris PPP 4.0 ファイルを示します。
テンプレートファイル |
PPP 構成ファイル |
参照先 |
---|---|---|
/etc/ppp/options.tmpl |
/etc/ppp/options | |
/etc/ppp/options.ttya.tmpl |
/etc/ppp/options.ttyname | |
/etc/ppp/myisp-chat.tmpl |
chat スクリプトを格納するためのユーザー指定の名前を持つファイル | |
/etc/ppp/peers/myisp.tmpl |
/etc/ppp/peers/peer-name |
テンプレートファイルを使用するように決めたら、そのテンプレートファイルの名前を同等の PPP 構成ファイルの名前に変更します。chat ファイルのテンプレート (/etc/ppp/myisp-chat.tmpl) だけは例外です。chat スクリプトには任意の名前を指定できます。
ダイアルアウト PPP マシンを設定するための最初の作業は、シリアル回線にデバイス (モデムとシリアルポート) を構成することです。
モデムに適用する作業は、通常 ISDN TA にも適用します。
以降の手順を実行する前に、次の作業を終了しておく必要があります。
Solaris 9 オペレーティング環境をダイアルアウトマシンにインストールする
モデムの最適速度を決定する
ダイアルアウトマシンに使用するシリアルポートを決定する
ダイアルアウトマシンのルートパスワードを取得する
計画情報については、表 26–2 を参照してください。
モデムの設定を行う
さまざまなタイプのモデムを使用できますが、通常のモデムは Solaris PPP 4.0 用に正しく設定されて出荷されています。次の表は、Solaris PPP 4.0 を使用するモデムの基本的な設定を示しています。
表 27–3 ダイアルアップ PPP のモデム設定
パラメータ |
設定 |
---|---|
DCD |
キャリアに従う |
DTR |
モデムがハングアップするように Low に設定する (モデムをオンフックにする) |
Flow Control |
全二重ハードウェアのフロー制御用 RTS/CTS |
Attention Sequences |
使用不可 |
リンクの設定で問題が発生し、原因がモデムにあれば、まずモデムの製造元のマニュアルを参照します。また、Web 上の多くのサイトが、役に立つモデムの設定情報を提供しています。最後に、モデムの問題を診断する方法 でモデム問題を解決するためのヒントを見つけることができます。
モデムケーブルをダイアルアウトマシンのシリアルポートと電話ジャックに接続します。
ダイアルアウトマシン上でスーパーユーザーになります。
『Solaris のシステム管理 (上級編)』の「シリアルポートツールによる端末とモデムの設定」で説明するように admintool を実行します。
モデムを接続しているポート (ポート a かポート b) をクリックします。
「シリアルポートの設定」ウィンドウが表示されます。
モデム方向を「発信専用」として指定します。
モデムを「発着信両用」としても設定できます。これは admintool のデフォルトのテンプレートです。「発信専用」を選択すると、侵入者に対してセキュリティが強力になります。
admintool でボーレートやタイムアウトを設定できますが、pppd デーモンはこ れらの設定を無視します。
「OK」をクリックして変更を有効にします。
この節の手順では、ダイアルアウトマシンのシリアル回線に通信を構成する方法を示します。これらの手順を使用する前に、モデムとシリアルポートの構成方法 (ダイアルアウトマシン) で説明しているように、モデムとシリアルポートを設定しておく必要があります。
次の作業は、ダイアルアウトマシンがダイアルインサーバーとの通信を正常に開始できるようにする方法を示します。通信は、PPP 構成ファイルで定義されているオプションに基づいて開始されます。次のファイルを作成する必要があります。
/etc/ppp/options
/etc/ppp/options.ttyname
chat スクリプト
/etc/ppp/peers/peer-name
Solaris PPP 4.0 は、PPP 構成ファイルにテンプレートを提供します。これらのテンプレートは要求に合わせてカスタマイズできます。これらのファイルについては、ダイアルアップ PPP のテンプレートファイルを参照してください。
ダイアルアウトマシン上でスーパーユーザーになります。
次のオプションを指定して、/etc/ppp/options と呼ばれるファイルを作成します。
lock |
/etc/ppp/options ファイルは、ローカルマシンが実行するすべての通信に適用されるグローバルパラメータの定義に使用されます。lock オプションによって、/var/spool/locks/LK.xxx.yyy.zzz 形式の UUCP スタイルのロックが可能です。
ダイアルアウトマシンが /etc/ppp/options ファイルを持たない場合は、スーパーユーザーだけが pppd コマンドを実行できます。 ただし、/etc/ppp/options は空でもかまいません。
/etc/ppp/options については、/etc/ppp/options 構成ファイルを参照してください。
(省略可能) 特定のシリアルポートから通信を起動する方法を定義するために、/etc/ppp/options.ttyname と呼ばれるファイルを作成します。
次の例は、デバイス名として /dev/cua/a を持つポートの /etc/ppp/options.ttyname ファイルを示しています。
# vi /etc/ppp/options.cua.a crtscts |
PPP オプション crtscts は、pppd デーモンに、シリアルポート a のハードウェアフロー制御をオンにするように指示します。
/etc/ppp/options.ttyname ファイルについては、/etc/ppp/options.ttyname 構成ファイルを参照してください。
モデム速度を モデム速度を設定する方法で説明しているとおりに設定します。
ダイアルアウトマシンが PPP リンクを開始する前に、ピアになるダイアルインサーバーの情報を収集する必要があります。情報を収集したら、この情報を使用して chat スクリプトを作成します。chat スクリプトには、ダイアルアウトマシンとピア間の実際の対話を記述します。
ダイアルアウトマシンのモデムの実行速度を決定します。
詳細は、モデム速度の設定を参照してください。
サーバーの電話番号
必要な場合、使用している認証プロトコル
chat スクリプトでピアが必要とするログインシーケンス
ダイアルインサーバーサイトのネームサーバーの名前と IP アドレスを入手します。
特定ピアへの呼び出しを開始するための命令群を chat スクリプトに置きます。
たとえば、次の chat スクリプト (/etc/ppp/mychat) を作成して、ダイアルインサーバー (myserver) を呼び出します。
SAY "Calling the peer\n" TIMEOUT 10 ABORT BUSY ABORT 'NO CARRIER' ABORT ERROR REPORT CONNECT "" AT&F1&M5S2=255 TIMEOUT 60 OK ATDT1-123-555-1234 CONNECT \c SAY "Connected; logging in.\n" TIMEOUT 5 ogin:--ogin: pppuser TIMEOUT 20 ABORT 'ogin incorrect' ssword: \qmypassword "% " \c SAY "Logged in. Starting PPP on peer system.\n" ABORT 'not found' "" "exec pppd" ~ \c |
chat スクリプトを直接呼び出さないでください。connect オプションの引数に chat スクリプトのファイル名を指定して、スクリプトを呼び出します。
ピアが Solaris または類似のオペレーティングシステムを実行する場合は、ダイアルアウトマシンのテンプレートとして前述の chat スクリプトの利用をお勧めします。
ダイアルアウトマシン上でスーパーユーザーになります。
次の /etc/resolv.conf ファイルを作成して、DNS データベースを更新します。
domain bigcompany.com nameserver 10.10.111.15 nameserver 10.10.130.8 |
ピアの DNS ドメインが bigcompany.com であることを示す
bigcompany.com 側にあるネームサーバーの IP アドレスの一覧を示す
DNS の実装については、『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』の「DNS の管理 (参照情報)」を参照してください。
ホスト情報として最初に DNS データベースが検索されるように、/etc/nsswitch.conf ファイルを編集します。
hosts: dns [NOTFOUND=return] files |
/etc/ppp/peers ディレクトリを作成して、ピア用のファイルを追加します。
たとえば、次のファイルを作成して、ダイアルインサーバー (myserver) を定義します。
# cd /etc/ppp # mkdir peers # cd peers # vi myserver /dev/cua/a 57600 noipdefault defaultroute idle 120 noauth connect "chat -U 'mypassword' -T 1-123-555-1213 -f /etc/ppp/mychat" |
myserver を呼び出すためのシリアルインタフェースとして、デバイス (/dev/cua/a) を使用する必要があることを示す
リンクの速度を定義する
ピア (myserver) のトランザクションでは、ダイアルアウトマシンは最初に 0.0.0.0 の IP アドレスを持つことを示す。 myserver は、すべてのダイアルアップセッションのダイアルアウトマシンに IP アドレスを割り当てる
120 秒のアイドル時間が経過するとリンクがタイムアウトになることを示す
ダイアルアウトマシンとの接続をネゴシエートするとき、ピア (myserver) は認証資格を提供する必要がないことを示す
connect オプションとその引数を示す。引数には、ピアの電話番号、呼び出しの命令群を持つ chat スクリプト (/etc/ppp/mychat) などが指定されている
作業 |
参照先 |
---|---|
別のダイアルアウトマシンを構成する | |
別のコンピュータにダイアルアウトすることで、モデムの接続性をテストする |
cu(1C) と tip(1) のマニュアルページ。 これらのユーティリティを使用すると、モデムが正しく構成されているかをテストできる。また、別のマシンとの接続が確立できるかもテストできる |
PPP 構成ファイルの詳細情報を入手する | |
ダイアルインサーバーの構成を開始する |
この節の作業では、ダイアルインサーバーを構成します。 ダイアルインサーバーは、ダイアルアウトマシンからの呼び出しをPPP リンクを介して受信するピアマシンです。作業では、図 26–1 で紹介したダイアルインサーバー (myserver) の構成方法を示します。
作業 |
説明 |
参照先 |
---|---|---|
1. 構成前の情報を収集する |
リンクを設定する前に、ピアのホスト名、ターゲットの電話番号、モデムの速度など必要なデータを集める | |
2. モデムとシリアルポートを構成する |
モデムとシリアルポートを設定する | |
3. ピア情報の呼び出しを構成する |
ダイアルインサーバーへの呼び出しが許可されているすべてのダイアルアウトマシンにユーザー環境と PPP オプションを設定する | |
4. シリアル回線通信を構成する |
シリアル回線上の伝送特性を構成する |
次の手順では、モデムとシリアルポートをダイアルインサーバーに構成する方法について説明します。
手順を実行する前に、ピアであるダイアルインサーバー上で次の作業を終了しておく必要があります。
Solaris 9 オペレーティング環境のインストール
モデムの最適速度を決定する
使用するシリアルポートの決定
モデムの製造元が発行するマニュアルに従ってモデムのプログラムを作成します。
詳細は、モデムとシリアルポートの構成方法 (ダイアルアウトマシン)を参照してください。
モデムをダイアルインサーバー上のシリアルポートに接続します。
ダイアルインサーバー上でスーパーユーザーになります。
『Solaris のシステム管理 (上級編)』の「シリアルポートツールによる端末とモデムの設定」で説明しているように、admintool を使ってシリアルポートを構成します。
admintool を使用して、次の作業を行います。
次の手順では、ダイアルインサーバーのモデム速度を設定する方法について説明します。Sun Microsystems のコンピュータを使用する際のモデム速度については、モデム速度の設定を参照してください。
ダイアルインサーバーにログインします。
tip コマンドを使用して、モデムにアクセスします。
tip によるモデム速度の設定については、tip(1) のマニュアルページを参照してください。
固定 DTE レートでモデムを構成します。
『Solaris のシステム管理 (上級編)』の「シリアルポートツールによる端末とモデムの設定」で説明しているように、ttymon または admintool を使ってシリアルポートをそのレートで固定します。
作業 |
参照先 |
---|---|
ダイアルインサーバーに別のシリアルポートとモデムを構成する | |
ダイアルインサーバーを呼び出すユーザー情報を構成する |
ダイアルインサーバーの設定プロセスでは、既知の各リモート呼び出し側に関する情報を構成する必要があります。
この節の手順を開始する前に、次の作業を終了しておく必要があります。
リモートダイアルアウトマシンからログインが許されているすべてのユーザーの UNIX ユーザー名を入手する
モデムとシリアルポートの構成方法 (ダイアルインサーバー) で説明しているとおりに、モデムとシリアル回線を設定する
IP アドレスを専用化して、リモートユーザーからの着呼に割り当てる。呼び出し側の数がダイアルインサーバー上のモデムとシリアルポートの数を超える可能性がある場合、着呼専用の IP アドレスの作成を検討する。専用 IP アドレスについては、呼び出し元の IP アドレス指定スキーマの作成を参照してください。
ダイアルインサーバー上でスーパーユーザーになります。
各リモート PPP ユーザーに対して、ダイアルインサーバー上で新しいアカウントを作成します。
admintool または Solaris 管理コンソールを使用して、新しいユーザーを作成できます。Solaris 管理コンソールを使って新しいユーザーを作成するには、『Solaris のシステム管理 (基本編)』の「ユーザーアカウントの設定 (作業マップ)」を参照してください。admintool を使って新しいユーザーを作成するには、admintool(1M) を参照してください。
残りの手順では、admintool を使ってアカウントを作成する方法を示します。Solaris 管理コンソールを使ってアカウントを作成する場合と同じパラメータを使用できます。
「ユーザーの追加 (Add User)」テンプレートを使用して、新しいユーザーを作成します。
たとえば、次の表は、ダイアルアウトマシン (myhome) 上の user1 に対して pppuser と呼ばれるアカウントを PPP 関連パラメータに記入する方法を示しています。
テンプレートパラメータ |
値 |
定義 |
---|---|---|
ユーザー名 |
pppuser |
リモートユーザーのユーザーアカウント名。このアカウント名は、chat スクリプトのログインシーケンスで指定されているアカウント名と一致する必要がある。たとえば、pppuser は、ピアを呼び出すための命令群を作成する方法 の chat スクリプトにあるアカウント名である |
ログインシェル |
/usr/bin/pppd |
リモートユーザーのデフォルトのログインシェル。ログインシェル (/usr/bin/pppd) は最初から呼び出し側を専用 PPP 環境に制限する |
「ホームディレクトの作成」のパス |
/export/home/pppuser |
ホームディレクトリ (/export/home/pppuser) は、呼び出し側が正常にダイアルインサーバーにログインするとき設定される |
各呼び出し側に対して、$HOME/.ppprc ファイルを作成します。このファイルには、ユーザーの PPP セッションに固有のさまざまなオプションが格納されています。
たとえば、pppuser に対して、次の .ppprc ファイルを作成します。
# cd /export/home/pppuser # vi .ppprc noccp |
作業 |
参照先 |
---|---|
ダイアルインサーバーに追加のユーザーを設定する | |
ダイアルインサーバーを介した通信を構成する |
次の作業は、ダイアルインサーバーが任意のダイアルアウトマシンと通信を開始できるようにする方法を示します。通信がどのように確立されるかは、次のPPP 構成ファイルで定義されているオプションに基づいて決まります。
/etc/ppp/options
/etc/ppp/options.ttyname
モデムとシリアルポートの構成方法 (ダイアルインサーバー) で説明しているとおりに、ダイアルインサーバーにシリアルポートとモデムを構成する
ダイアルインサーバーのユーザーを構成する方法 で説明しているとおりに、ダイアルインサーバーの予想されるユーザー情報を構成する
ダイアルインサーバー上でスーパーユーザーになります。
次の引数を指定して、/etc/ppp/options ファイルを作成します。
nodefaultroute |
nodefaultroute は、サーバーの経路が定義されていないことを示します。
ダイアルインサーバーが /etc/ppp/options ファイルを持たない場合は、スーパーユーザーだけが pppd コマンドを実行できます。 ただし、/etc/ppp/options ファイルは空でもかまいません。
/etc/options.ttyname ファイルを作成して、シリアルポート (ttyname) を介して受信される呼び出しの制御方法を定義します。
次の /etc/options.ttya ファイルでは、ダイアルインサーバーのシリアルポート (/dev/ttya) が着呼を制御する方法を定義しています。
:10.0.0.80 xonxoff |
この章のすべての手順を実行すると、ダイアルアップリンクの構成が完成します。
作業 |
参照先 |
---|---|
別のコンピュータにダイアルアウトすることで、モデムの接続性をテストする |
cu(1C) と tip(1) のマニュアルページ。 これらのユーティリティを使用すると、モデムが正し く構成されているかをテストできる。また、別のマシンとの接続が確立できるかもテストできる |
ダイアルインサーバーのオプションを追加して構成する | |
ダイアルアウトマシンを追加して構成する | |
リモートマシンがダイアルインサーバーを呼び出す |
ダイアルアウトマシンがダイアルインサーバーを呼び出すことで、ダイアルアップ PPP リンクを確立します。ローカルの PPP 構成ファイルに demand オプションを指定することで、ダイアルアウトマシンがサーバーを呼び出すように指示できます。リンクの確立でもっとも一般的な方法は、ユーザーがダイアルアウトマシン上で pppd コマンドを実行することです。
次の作業に進む前に、次のどちらかの作業か両方の作業を終了しておく必要があります。
ダイアルアウトマシンの構成で説明しているとおりに、ダイアルアウトマシンを設定する
ダイアルインサーバーの構成で説明しているとおりに、ダイアルインサーバーを設定する
root ではなく、通常のユーザーアカウントを使用して、ダイアルアウトマシンにログインします。
pppd コマンドを実行して、ダイアルインサーバーを呼び出します。
たとえば、次のコマンドは、ダイアルアウトマシンとダイアルインサーバー (myserver) 間のリンクを開始します。
% pppd 57600 call myserver |
pppd デーモンを呼び出すことで呼び出しを開始する
ホストとモデム間の回線速度を設定する
pppd の call オプションを呼び出して、個々のピアとの接続を定義する方法 で作成された /etc/ppp/peers/myserver ファイルのオプション群を読み取る
サーバーのネットワーク上にあるホスト (図 26–1 に示されている lindyhop ホストなど) にアクセスします。
ping lindyhop |
リンクが正しく動作している場合、標準的な Telnet のログインシーケンスが端末のウィンドウに表示されます。リンクが正しく動作していない場合は、第 31 章「一般的な問題の解決 (手順)」を参照してください。
PPP セッションを終了します。
% pkill -TERM -x pppd |
この章のすべての手順を実行すると、ダイアルアップリンクの構成が完成します。
作業 |
参照先 |
---|---|
ユーザーがダイアルアウトマシン上で作業を開始する | |
リンク上の問題を修正する | |
この章で使用するファイルとオプションについてさらに学習する |
この章では、専用回線を使用した、ピア間での PPP リンクを設定する方法について説明します。 主に次の内容について説明します。
専用回線リンクの設定は、ダイアルアップリンクのそれに比べて、比較的簡単です。 ほとんどの場合、CSU/DSU、ダイアルサービス、または認証を設定する必要はありません。CSU/DSU の設定は複雑なので、これを設定する必要がある場合は、製造元のマニュアルを参照してください。
次の表の作業マップでは、基本的な専用回線リンクの設定に必要な作業について説明しています。
専用回線の中には、対するピアのアドレスを「ダイアル」するために、CSU/DSU を必要とするものもあります。例としては、SVC (Switched Virtual Circuit) や Switched 56 サービスを使用するフレームリレーなどがあります。
作業 |
説明 |
参照先 |
---|---|---|
1. 構成前の情報を収集する |
接続の設定に必要な情報を収集する | |
2. 専用回線への接続に使用するハードウェアを設定する |
CSU/DSU および同期インタフェースカードを取り付ける | |
3. 必要に応じて、インタフェースカードを設定する |
専用回線に接続する際に使用するインタフェーススクリプトを設定する | |
4. リモートピアに関する情報に基づいて設定する |
ローカルマシンとリモートピア間の通信方法を定義する | |
5. 専用回線への接続を開始する |
起動プロセスの一部として、PPP が専用回線を介して開始されるようにマシンを設定する |
この節では、専用回線のトポロジに必要な機器を設定する方法について説明します。専用回線のトポロジについては、例 — 専用回線リンクの構成 で紹介しています。専用回線への接続に必要な同期デバイスには、インタフェースとモデムが含まれています。
次の手順に従う前に、下記の項目を確認する必要があります。
プロバイダによって設置された専用回線が動作していること
同期装置 (CSU/DSU)
システムに Solaris 9 オペレーティング環境リリースがインストールされていること
システムに必要な同期インタフェースカード
必要に応じて、インタフェースカードをローカルマシンに取り付けます。
製造元のマニュアルの手順に従います。
CSU/DSU とインタフェースをケーブルで接続します。必要に応じて、CSU/DSU と専用回線のジャックまたは同等のコネクタをケーブルで接続します。
製造元またはネットワークプロバイダのマニュアルの手順に従って、CSU/DSU を設定します。
専用回線を貸し出しているプロバイダが、接続用の CSU/DSU を提供および設定する場合もあります。
必要に応じて、インタフェースのマニュアルの手順に従って、インタフェースカードを設定します。
インタフェースカードの設定時に、インタフェースの起動スクリプトを作成します。図 26–2 のような専用回線設定では、LocalCorp にあるルーターは、HSI/S インタフェースカードを使用します。
次のスクリプト hsi-conf によって、HSI/S インタフェースが開始されます。
#!/bin/ksh /opt/SUNWconn/bin/hsi_init hih1 speed=1536000 mode=fdx loopback=no \ nrzi=no txc=txc rxc=rxc txd=txd rxd=rxd signal=no 2>&1> /dev/null |
使用されている同期ポートが HSI/S であることを示す
CSU/DSU の速度を 1536000 に設定する
作業 |
参照先 |
---|---|
専用回線上のローカルマシンの設定 |
この節では、ルーターを専用回線の終端でローカルピアとして機能するように設定する方法について説明します。ここでは、例 — 専用回線リンクの構成で紹介した専用回線を例として使用します。
以降の手順を実行する前に、次の作業を終了しておく必要があります。
専用回線上の同期デバイスの設定の説明に従って、接続に使用する同期デバイスをセットアップおよび設定する
専用回線上のローカルマシンのスーパーユーザーパスワードを取得する
ローカルマシンがネットワークのルーターとして動作し、専用回線プロバイダのサービスを使用するように設定する
リモートピア用のエントリをルーターの /etc/hosts ファイルに追加します。
# vi /etc/hosts # # Internet host table # 127.0.0.1 localhost 192.168.130.10 local2-peer loghost 192.168.130.11 local1-net 10.0.0.25 farISP |
サンプル /etc/hosts は、架空の LocalCorp のローカルルーター用のファイルです。サービスプロバイダのリモートピア farISP の IP アドレスおよびホスト名をメモしておきます。
プロバイダのピアに関する情報を保持する /etc/ppp/peers/peer-name ファイルを作成します。
サンプルの専用回線への接続用に、/etc/ppp/peers/farISP ファイルを作成します。
#vi /etc/ppp/peers/farISP init '/etc/ppp/conf_hsi' local /dev/hih1 sync noauth 192.168.130.10:10.0.0.25 nodefaultroute passive persist noccp nopcomp novj noaccomp |
次の表では、/etc/ppp/peers/farISP で使用されているオプションおよびパラメータについて説明しています。
demand という初期設定スクリプトを作成します。こうすると、起動プロセスの一部として PPP リンクが開始されます。
# cd /etc/ppp/ # vi demand if [ -f /var/run/ppp-demand.pid ] && /usr/bin/kill -s 0 `/bin/cat /var/run/ppp-demand.pid` then : else /usr/bin/pppd call farISP fi |
demand スクリプトには、専用回線リンクを確立するための pppd コマンドが含まれています。次の表では、$PPPDIR/demand の内容について説明しています。
コーディング例 |
説明 |
---|---|
echo "Starting Solaris PPP 4.0\c" |
起動プロセス中に、「Starting Solaris PPP 4.0」と表示する |
if ps -e | grep '\<pppd\> /dev/null 2>&1 ; then echo "\npppd daemon is still running" echo "or in the process of exiting" exit 0 |
既存の pppd デーモンを検索する
pppd が検出されたら、メッセージを送信し、demand スクリプトを終了する |
echo "\nEstablishing PPP session...\n" |
起動中に、「Establishing PPP session」と表示する |
/usr/bin/pppd call farISP |
/etc/ppp/peers/farISP にあるオプションを使用して、pppd コマンドを実行する |
Solaris PPP 4.0 の起動スクリプト /etc/rc2.d/S47pppd によって、demand スクリプトが、Solaris の起動プロセスの一部として呼び出されます。 /etc/rc2.dS47pppd にある次の行は、$PPPDIR/demand というファイルが存在するかどうかを調べます。
if [ -f $PPPDIR/demand ]; then . $PPPDIR/demand fi |
$PPPDIR/demand が検出された場合は、それが実行されます。$PPPDIR/demand の一連の処理の実行中に、接続が確立されます。
この章のすべての手順を実行すると、専用回線接続の構成が完了します。
作業 |
参照先 |
---|---|
ユーザーに、インターネット上のマシン、またはリモートピアによって提供されている他のネットワーク上のマシンとの通信を開始するように指示する |
ユーザーに、telnet、ftp、rsh、またはローカルネットワークの外部にあるマシンにアクセスするための同様のコマンドを実行させる |
リンク上の問題を修正する |
障害追跡の情報については、専用回線の問題の解決を参照 |
この章で使用するファイルとオプションについてさらに学習する |
この章では、PPP 認証の設定手順について説明します。ここでは、次の内容を説明します。
ここでは、ダイアルアップリンクに認証を実装する方法について説明しています。これは、ダイアルアップリンクの方が、専用回線リンクよりも認証を設定することが多いためです。企業のセキュリティポリシーにより認証が必要な場合には、専用回線に認証を設定することもできます。専用回線に認証を設定する場合は、この章の手順をガイドラインとして参照してください。
PPP 認証を使用する場合で、どのプロトコルを使用したらいいのかわからないときには、PPP 認証を使用する理由を参照してください。PPP 認証の詳細については、pppd(1M) のマニュアルページおよび 接続時の呼び出し元の認証を参照してください。
次の作業マップに、PPP 認証に関連する作業を示します。
表 29–1 一般的な PPP 認証 (作業マップ)
作業 |
参照先 |
---|---|
PAP 認証を設定する | |
CHAP 認証を設定する |
この節では、パスワード認証プロトコル (PAP) を使用して、PPP リンクに認証を実装する方法について説明します。 ここでは、例 — PPP の認証構成の例を使用して、ダイアルアップリンクで PAP を動作させる方法について説明します。 PAP 認証を実装する場合は、この手順を基準として使用してください。
以降の手順を実行する前に、次の作業を終了しておく必要があります。
ダイアルインサーバーと信頼できる呼び出し元が所有するダイアルアウトマシン間で、ダイアルアップリンクを設定しテストします。
ダイアルインサーバーでの認証に備えて、LDAP、NIS、またはローカルファイルなどでネットワークパスワードデータベースを管理しているマシンに対するスーパーユーザーとしてのアクセス権を取得することが理想的です。
ローカルマシン、およびダイアルインサーバーまたはダイアルアウトマシンに対するスーパーユーザーとしての権限を取得します。
次の作業マップに、ダイアルインサーバーおよびダイアルアウトマシン上の信頼できる呼び出し元に対して実行する PAP 関連の作業を示します。
表 29–2 PAP 認証についての作業マップ (ダイアルインサーバー)
作業 |
説明 |
参照先 |
---|---|---|
1. 構成前の情報を収集する |
ユーザー名など、認証に必要なデータを収集する | |
2. 必要に応じて、パスワードデータベースを更新する |
候補となるすべての呼び出し元が、サーバーのパスワードデータベースに含まれていることを確認する | |
3. PAP データベースを作成する |
将来接続する可能性のあるすべての呼び出し元のセキュリティ資格を /etc/ppp/pap-secrets に作成する | |
4. PPP の構成ファイルを変更する |
PAP 特有のオプションを /etc/ppp/options と /etc/ppp/peers/peer-name に追加する |
表 29–3 PAP 認証についての作業マップ (ダイアルアウトマシン)
作業 |
説明 |
参照先 |
---|---|---|
1. 構成前の情報を収集する |
ユーザー名など、認証に必要なデータを収集する | |
2. 信頼できる呼び出し元のマシン用の PAP データベースを作成する |
信頼できる呼び出し元のセキュリティ資格と、必要であれば、ダイアルアウトマシンを呼び出す他のユーザーのセキュリティ資格を /etc/ppp/pap-secrets に作成する | |
3. PPP の構成ファイルを変更する |
PAP 特有のオプションを /etc/ppp/options と /etc/ppp/peers/peer-name に追加する |
PAP 認証を設定するには、次の手順に従う必要があります。
PAP 資格データベースを作成します。
PAP をサポートするように PPP 構成ファイルを変更します。
ここでは、/etc/ppp/pap-secrets ファイルを変更します。このファイルには、接続時に呼び出し元の認証に使用する PAP セキュリティ資格が含まれています。PPP リンクを行う両方のマシンに /etc/ppp/pap-secrets が必要です。
図 26–3 で紹介した PAP 構成のサンプルでは、PAP の login オプションが使用されています。このオプションを使用する場合は、ネットワークのパスワードデータベースも更新する必要がある可能性があります。 login オプションの詳細については、/etc/ppp/pap-secrets での login オプションの使用を参照してください。
候補となる信頼できる呼び出し元のリストを作成します。信頼できる呼び出し元とは、自分のリモートマシンからダイアルインサーバーを呼び出す権限を与えられているユーザーです。
ダイアルインサーバーのパスワードデータベースに、信頼できる呼び出し元全員の UNIX ユーザー名およびパスワードがあることを確認します。
この確認は、この PAP 構成のサンプルにとって重要です。このサンプルでは、呼び出し元の認証に、PAP の login オプションを使用しています。PAP に login を実装しない場合は、呼び出し元の PAP ユーザー名と UNIX ユーザー名を一致させる必要はありません。標準の /etc/ppp/pap-secrets については、/etc/ppp/pap-secrets ファイルを参照してください。
候補となる信頼できる呼び出し元に UNIX 名とパスワードがない場合は、次の手順に従います。
ダイアルインサーバーのスーパーユーザーとなり、/etc/ppp/pap-secrets ファイルを編集します。
Solaris PPP 4.0 では、/etc/ppp に pap-secrets ファイルがあります。このファイルには、PAP 認証の使用方法についてのコメントが含まれています。ただし、オプションについてのコメントは含まれていません。 コメントの最後に、次のオプションを追加することができます。
# user1 myserver "" * user2 myserver "" * myserver user2 serverpass * |
/etc/ppp/pap-secrets の login オプションを使用するには、信頼できる呼び出し元の UNIX 名をすべて入力する必要があります。3 番目のフィールドのどこに二重引用符 (" ") が記述されても、呼び出し元のパスワードは、サーバーのパスワードデータベースで参照できます。
エントリ myserver * serverpass * には、ダイアルインサーバー用の PAP ユーザー名およびパスワードが含まれています。図 26–3 では、信頼できる呼び出し元である user2 は、リモートピアに認証を要求します。 そのため、myserver の /etc/ppp/pap-secrets ファイルには、user2 との接続を確立する場合に使用する PAP 資格が含まれています。
作業 |
参照先 |
---|---|
PPP 構成ファイルを変更し、PAP 認証をサポートする | |
信頼できる呼び出し元のダイアルアウトマシンで、PAP 認証を設定する |
この節では、ダイアルインサーバーで PAP 認証をサポートするように、既存の PPP 構成ファイルを更新する方法について説明します。
ここでは、シリアル回線を介した通信を定義する方法 (ダイアルインサーバー)で紹介した PPP 構成ファイルを例として使用します。
ダイアルインサーバーにスーパーユーザーとしてログインします。
認証オプションを /etc/ppp/options ファイルに追加します。
たとえば、既存の /etc/ppp/options ファイルに、次の太字のオプションを追加すると、PAP 認証を実装することができます。
lock idle 120 nodefaultroute name myserver auth require-pap user myserver remotename user2 login |
シリアル回線を介した通信を定義する方法の説明に従って、/etc/ppp/optons.ttyname ファイルを作成します。
ダイアルインサーバーのユーザーを構成する方法の説明に従って、リモート呼び出し元の $HOME/.ppprc ファイルをそれぞれ設定します。
作業 |
参照先 |
---|---|
ダイアルインサーバーの信頼できる呼び出し元の PAP 認証資格を設定する |
この節では、信頼できる呼び出し元のダイアルアウトマシンで、PAP 認証を設定する手順について説明します。 システム管理者は、システムで PAP 認証を設定し、それらを将来接続する可能性のある呼び出し元に配布することができます。また、リモート呼び出し元にすでにマシンがある場合は、この節の手順を指示することもできます。
信頼できる呼び出し元に PAP を設定するには、次の 2 つの手順を実行します。
呼び出し元の PAP セキュリティ資格を設定します。
呼び出し元のダイアルアウトマシンが PAP 認証をサポートするように設定します。
ここでは、2 人の信頼できる呼び出し元の PAP 資格を設定する方法について説明します。これらのうちの 1 人は、リモートピアに認証資格を要求します。この手順では、システム管理者が、信頼できる呼び出し元のダイアルアウトマシンで PAP 資格を作成することを前提にしています。
ダイアルアウトマシンのスーパーユーザーになります。
図 26–3で紹介した PAP 構成のサンプルでは、user1 がダイアルアウトマシンを所有しています。
呼び出し元の pap-secrets データベースを変更します。
Solaris PPP 4.0 には、/etc/ppp/pap-secrets ファイルがあります。このファイルには、便利な情報が含まれていますが、オプションについては触れていません。 次のオプションをこの /etc/ppp/pap-secrets ファイルに追加できます。
# user1 myserver pass1 * |
user1 のパスワードである pass1 は、接続を通して、読み取り可能な ASCII 形式になることに注意してください。myserver は、呼び出し元 user1 がピアで使用する名前です。
他のダイアルアウトマシンのスーパーユーザーになります。
PAP 認証の例では、呼び出し元 user2 がこのダイアルアウトマシンを所有しています。
呼び出し元の pap-secrets データベースを変更します。
次のオプションを既存の /etc/ppp/pap-secrets ファイルの終わりに追加できます。
# user2 myserver pass2 * myserver user2 serverpass * |
この例では、/etc/ppp/pap-secrets に 2 つのエントリがあります。最初のエントリには、user2 が認証のためにダイアルインサーバー myserver に渡す PAP セキュリティ資格が含まれています。
user2 は、接続のネゴシエーションの一部として、ダイアルインサーバーに PAP 資格を要求します。そのため、/etc/ppp/pap-secrets の 2 つ目の行に、myserver に要求される PAP 資格も含まれています。
ほとんどのISP は認証資格を提供しないため、ここで検討しているシナリオは、ISP との通信に関しては現実的ではありません。
作業 |
参照先 |
---|---|
その他の呼び出し元に、PAP 資格を作成する | |
ダイアルアウトマシンが PAP 認証をサポートするように設定する |
以下の作業は、信頼できる呼び出し元のダイアルアウトマシンで PAP 認証をサポートするように、既存の PPP 構成ファイルを更新する方法について説明します。
ここでは、次のパラメータを使用して、図 26–3 で紹介した user2 が所有するダイアルアウトマシン上で、PAP 認証を設定します。user2 は、ダイアルイン myserver からの呼び出しを含む着信呼び出し元に、認証を要求します。
ここでは、シリアル回線を介した通信を定義する方法で紹介した PPP 構成ファイルを例として使用します。 この手順に従って、図 26–3 で示した user2 が所有するダイアルアウトマシンを設定します。
ダイアルアウトマシンにスーパーユーザーとしてログインします。
次の /etc/ppp/options ファイルには、太字で示した PAP サポート用のオプションが含まれています。
#vi /etc/ppp/options lock nodefaultroute name user2 auth require-pap |
リモートマシン myserver 用の /etc/ppp/peers/peer-name ファイルを作成します。
次のサンプルは、個々のピアとの接続を定義する方法で作成した既存の /etc/ppp/peers/myserver ファイルに、PAP サポートを追加する方法を示しています。
# cd /etc/ppp # mkdir peers # cd peers # vi myserver /dev/cua/a 57600 noipdefault defaultroute idle 120 user user2 remotename myserver connect "chat -U 'mypassword' -f /etc/ppp/mychat" |
太字で示した新しいオプションにより、ピア myserver に関する PAP 要件が追加されます。
user2 をローカルマシンのユーザー名として定義する
myserver をローカルマシンに認証資格を要求するピアとして定義する
作業 |
参照先 |
---|---|
ダイアルインサーバーを呼び出して、PAP 認証の設定をテストする |
ダイアルインサーバーを呼び出す手順については、ダイアルインサーバーの呼び出し方法 を参照 |
PAP 認証の詳細を理解する |
この節では、チャレンジハンドシェーク認証プロトコル (CHAP) を使用して、PPP リンクに認証を実装する方法について説明します。 ここでは、図 26–4 の例を使用して、私設ネットワークへのダイアルアップで CHAP を動作させる方法について説明します。 CHAP 認証を実装する場合は、この手順を基準として使用してください。
以降の手順を実行する前に、次の作業を終了しておく必要があります。
ダイアルインサーバーと信頼できる呼び出し元が所有するダイアルアウトマシン間で、ダイアルアップリンクを設定しテストします。
ローカルマシン (ダイアルインサーバーまたはダイアルアウトマシン) に対するスーパーユーザーとしてのアクセス権を取得します。
作業 |
説明 |
参照先 |
---|---|---|
1. CHAP シークレットをすべての信頼できる呼び出し元に割り当てる |
CHAP シークレットを作成する、または呼び出し元に作成させる | |
2. chap-secrets データベースを作成する |
すべての信頼できる呼び出し元のセキュリティ資格を /etc/ppp/chap-secrets ファイルに追加する | |
3. PPP の構成ファイルを変更する |
CHAP 特有のオプションを /etc/ppp/options と /etc/ppp/peers/peer-name に追加する |
表 29–5 CHAP 認証についての作業マップ (ダイアルアウトマシン)
作業 |
説明 |
参照先 |
---|---|---|
1. 信頼できる呼び出し元のマシン用の CHAP データベースを作成する |
信頼できる呼び出し元のセキュリティ資格と、必要であれば、ダイアルアウトマシンを呼び出す他のユーザーのセキュリティ資格を /etc/ppp/chap-secrets に作成する | |
2. PPP の構成ファイルを変更する |
CHAP 特有のオプションを /etc/ppp/options ファイルに追加する |
CHAP 認証を設定するには、最初に /etc/ppp/chap-secrets ファイルを変更します。このファイルには、CHAP シークレットを含む CHAP セキュリティ資格が含まれています。このセキュリティ資格を使用して、接続時に呼び出し元を認証します。
UNIX の認証メカニズムまたは PAM の認証メカニズムを CHAP とともに使用することはできません。たとえば、PAP 資格データベースの作成方法 (ダイアルインサーバー)で説明したような PPP login オプションを使用することはできません。認証時に、PAM または UNIX スタイルの認証が必要な場合は、代わりに PAP を選択してください。
次に、私設ネットワークにあるダイアルインサーバーの CHAP 認証を実装します。PPP リンクは、外部のネットワークに接続する場合にだけ使用します。ネットワークにアクセスできるのは、ネットワーク管理者からアクセス権を与えられている呼び出し元だけです。その中には、システム管理者が含まれることもあります。
信頼できる呼び出し元のユーザー名をすべて含むリストを作成します。信頼できる呼び出し元とは、私設ネットワークを呼び出す権限を与えられているユーザーです。
各ユーザーに CHAP シークレットを割り当てます。
CHAP シークレットには、容易に予想しにくいものを選択してください。CHAP シークレットの内容については、予想しにくいものにするということ以外の制限はありません。
CHAP シークレットを割り当てる方法は、企業のセキュリティポリシーにより違います。管理者がシークレットを作成するか、呼び出し元が自分のシークレットを作成する必要があります。自分が CHAP シークレットを割り当てる立場にない場合は、信頼できる呼び出し元によって、または信頼できる呼び出し元のために作成された CHAP シークレットを取得することを忘れないでください。
ダイアルインサーバーのスーパーユーザーとなり、/etc/ppp/chap-secrets ファイルを変更します。
Solaris PPP 4.0 には、/etc/ppp/chap-secrets ファイルがあります。このファイルには、便利な情報が含まれていますが、オプションについては触れていません。 サーバー CallServe 用の次のオプションを既存の /etc/ppp/chap-secrets ファイルの最後に追加することができます。
account1 CallServe key123 * account2 CallServe key456 * |
key123 は、信頼できる呼び出し元 account1 の CHAP シークレットです。 key456 は、信頼できる呼び出し元 account2 の CHAP シークレットです。
作業 |
参照先 |
---|---|
その他の信頼できる呼び出し元に、CHAP 資格を作成する | |
PPP 構成ファイルを更新し、CHAP をサポートする | |
信頼できる呼び出し元のダイアルアウトマシンで、CHAP 認証を設定する |
この節では、ダイアルインサーバーで CHAP 認証をサポートするように、既存の PPP 構成ファイルを更新する方法について説明します。
ダイアルインサーバーにスーパーユーザーとしてログインします。
/etc/ppp/options ファイルを変更します。
太字で表示されているオプションを追加して、CHAP がサポートされるようにします。
# vi /etc/ppp/options lock nodefaultroute name CallServe auth require-chap |
信頼できる呼び出し元をサポートするために必要なその他の PPP 構成ファイルを作成します。
ダイアルインサーバーのユーザーを構成する方法および シリアル回線を介した通信を定義する方法 (ダイアルインサーバー)を参照してください。
作業 |
参照先 |
---|---|
信頼できる呼び出し元の CHAP 認証資格を設定する |
この節では、信頼できる呼び出し元のダイアルアウトマシンで、CHAP 認証を設定する手順について説明します。 企業のセキュリティポリシーによって、管理者と信頼できる呼び出し元のどちらが CHAP 認証を設定するのかが決まります。
リモート呼び出し元が CHAP を設定する場合は、呼び出し元のローカルの CHAP シークレットが、ダイアルインサーバーの /etc/ppp/chap-secrets ファイルに記述されている CHAP シークレットと一致していることを確認します。その後、呼び出し元に、この節で説明している CHAP 設定の手順を指示します。
信頼できる呼び出し元に CHAP を設定するには、次の 2 つの手順を実行します。
呼び出し元の CHAP セキュリティ資格を作成します。
呼び出し元のダイアルアウトマシンが CHAP 認証をサポートするように設定します。
ここでは、2 人の信頼できる呼び出し元に、PAP 資格を設定する方法について説明します。この手順では、システム管理者が、信頼できる呼び出し元のダイアルアウトマシンで CHAP 資格を作成することを前提にしています。
ダイアルアウトマシンのスーパーユーザーになります。
例 — CHAP 認証による構成の CHAP 構成のサンプルでは、信頼できる呼び出し元 account1 がダイアルアウトマシンを所有しています。
chap-secrets データベースを呼び出し元 account1 用に変更します。
Solaris PPP 4.0 には、/etc/ppp/chap-secrets ファイルがあります。このファイルには、便利な情報が含まれていますが、オプションについては触れていません。 次のオプションをこの既存の /etc/ppp/chap-secrets ファイルに追加できます。
# account1 CallServe key123 * |
CallServe は、account1 がアクセスを試みているピアの名前です。key123 は、account1 と CallServer 間での接続に使用する CHAP シークレットです。
他のダイアルアウトマシンのスーパーユーザーになります。
呼び出し元 account2 がこのマシンを所有しているとします。
/etc/ppp/chap-secrets データベースを呼び出し元 account2 用に変更します。
# account2 CallServe key456 * |
account2 に、シークレット key456 が、ピア CallServe への接続に使用する CHAP 資格として設定されます。
作業 |
参照先 |
---|---|
信頼できる呼び出し元のダイアルアウトマシンで、CHAP 資格を作成する | |
ダイアルアウトマシンが CHAP 認証をサポートするように設定する |
次の手順に従って、例 — CHAP 認証による構成で紹介した呼び出し元 account1 が所有するダイアルアウトマシンを設定します。
ダイアルアウトマシンにスーパーユーザーとしてログインします。
/etc/ppp/options ファイルが次のオプションを持つことを確認します。
# vi /etc/ppp/options lock nodefaultroute |
リモートマシン CallServe 用の /etc/ppp/peers/peer-name ファイルを作成します。
# mkdir /etc/ppp/peers # vi CallServe /dev/cua/a 57600 noipdefault defaultroute idle 120 user account1 connect "chat -U 'mypassword' -f /etc/ppp/mychat" |
オプション user account1 により、account1 が、CallServe に提供される CHAP ユーザー名として設定されます。前のファイルの他のオプションについては、個々のピアとの接続を定義する方法 の /etc/ppp/peers/myserver ファイルにある同様のオプションの説明を参照してください。
作業 |
参照先 |
---|---|
ダイアルインサーバーを呼び出して、CHAP 認証をテストする | |
CHAP 認証の詳細を理解する |
この章では、PPPoE トンネルの両端、つまり PPPoE クライアントと PPPoE アクセスサーバーを設定する方法について説明します。 ここでは、次の内容を説明します。
ここでは、PPPoE トンネルを介した DSL サポートの計画で紹介したシナリオを例として使用します。 PPPoE の概要については、PPPoE による DSL ユーザーのサポートを参照してください。
次の表に、PPPoE クライアントと PPPoE アクセスサーバーを構成するための主な作業をリストします。サイトで PPPoE を実装するには、PPPoE トンネルの自分の側だけ、つまりクライアント側かアクセスサーバー側のどちらかを設定します。
表 30–1 PPPoE クライアントの設定 (作業マップ)
作業 |
説明 |
参照先 |
---|---|---|
1. PPPoE のインタフェースを構成する |
Ethernet インタフェースを PPPoE トンネルで使用するために定義する | |
2. PPPoE アクセスサーバーに関する情報を構成する |
PPPoE トンネルのサービスプロバイダ側にあるアクセスサーバーのパラメータを定義する | |
3. PPP 構成ファイルを設定する |
まだクライアントの PPP 構成ファイルを定義していない場合は、定義する | |
4. トンネルを作成する |
アクセスサーバーを呼び出す |
表 30–2 PPPoE アクセスサーバーの設定 (作業マップ)
作業 |
説明 |
参照先 |
---|---|---|
1. PPPoE のインタフェースを構成する |
Ethernet インタフェースを PPPoE トンネルで使用するために定義する | |
2. アクセスサーバーが提供するサービスを構成する |
予想される PPPoE クライアントがサービスを「発見」できるように、提供するサービスを説明する | |
3. PPP 構成ファイルを設定する |
まだクライアントの PPP 構成ファイルを定義していない場合は、定義する | |
4. (省略可能) インタフェースの使用を限定する |
PPPoE オプションと PAP 認証を使用して、特定の Ethernet インタフェースの使用を特定のクライアントに限定する |
DSL を介してクライアントシステムに PPP を提供するには、まずモデムまたはハブに接続されているインタフェースで PPPoE を構成する必要があります。次に、PPP 構成ファイルを変更して、PPPoE の反対側のアクセスサーバーを定義する必要があります。
PPPoE クライアントを設定する前に、以下を行っておく必要があります。
PPPoE トンネルを使用するため、クライアントマシンに Solaris 8 Update 6 以降のリリースをインストールする
サービスプロバイダに連絡して PPPoE アクセスサーバーに関する情報を得る
クライアントマシンが使用するデバイスを電話会社またはサービスプロバイダに取り付けてもらう。たとえば DSL モデムやスプリッタなどのデバイスがあるが、これらは自分で取り付けるのではなく、電話会社が取り付ける
PPPoE クライアント上でスーパーユーザーになります。
DSL 接続のある Ethernet インタフェースの名前を /etc/ppp/pppoe.if ファイルに追加します。
たとえば、DSL モデムに接続するネットワークインタフェースに hme0 を使用する PPPoE クライアントの場合は、/etc/ppp/pppoe.if に次のエントリを追加します。
hme0 |
/etc/ppp/pppoe.if の詳細は、/etc/ppp/pppoe.if ファイルを参照してください。
PPPoE を使用するためのインタフェースを構成します。
# /etc/init.d/pppd start |
(省略可能) インタフェースが PPPoE に plumb されたことを確認します。
# /usr/sbin/sppptun query hme0:pppoe hme0:pppoed |
/usr/sbin/sppptun コマンドを使ってインタフェースを手動で PPPoE に plumb することもできます。 手順については、/usr/sbin/sppptun コマンドを参照してください。
/etc/ppp/peers/peer-name ファイルでアクセスサーバーを定義します。アクセスサーバーで使用されるオプションの多くは、ダイアルインサーバーをダイアルアップシナリオで定義するのにも使用できます。/etc/ppp/peers.peer-name の詳細は、/etc/ppp/peers/peer-name ファイル を参照してください。
PPPoE クライアント上でスーパーユーザーになります。
/etc/ppp/peers/peer-name ファイルでサービスプロバイダのPPPoE アクセスサーバーを定義します。
たとえば、次のファイル /etc/ppp/peers/dslserve は、例 — PPPoE トンネルの構成で紹介した FarISP にあるアクセスサーバー dslserve を定義しています。
# cat /etc/ppp/peers/dslserve sppptun plugin pppoe.so connect "/usr/lib/inet/pppoec hme0" noccp noauth user Red password redsecret noipdefault defaultroute |
このファイルのオプションの定義については、 アクセスサーバーピアを定義するための /etc/ppp/peers/peer-name ファイル を参照してください。
PPPoE クライアント上の他の PPP 構成ファイルを変更します。
ダイアルアウトマシンの構成 で説明したダイアルアウトマシンを構成する手順に従って、/etc/ppp/options を構成します。
/etc/ppp/options.sppptun ファイルを作成します。/etc/ppp/options.sppptun ファイルは、PPPoE に plumb されているインタフェースのシリアルポートの PPP オプションを定義します。
/etc/ppp/options.ttyname 構成ファイル で説明する /etc/ppp/options.ttyname ファイルで使用できるオプションは、すべて使用できます。sppptun は pppd 構成で指定されているデバイス名なので、ファイル名には /etc/ppp/options.sppptun を使用する必要があります。
すべてのユーザーがクライアント上で PPP を起動できることを確認します。
# touch /etc/ppp/options |
PPP が DSL 回線上で動作できるかどうかをテストします。
# pppd debug updetach call dslserve |
dslserve は、例 — PPPoE トンネルの構成 で示した ISP のアクセスサーバーに指定されている名前です。debug updetach オプションにより、デバッグ情報が端末のウィンドウに表示されます。
PPP が正しく動作した場合、端末の出力には、接続がアクティブになることが表示されます。PPP が動作しない場合は、次のコマンドを実行してサーバーが正しく動作しているかどうかを確認します。
# /usr/lib/inet/pppoec -i hme0 |
作業 |
参照先 |
---|---|
別の PPPoE クライアントを構成する | |
PPPoE についてさらに学ぶ | |
構成した PPPoE クライアントのユーザーが DSL 回線上で PPP の実行を開始する |
pppd call ISP-server-name と入力してアプリケーションやサービスを実行する方法について説明する |
PPPoE および PPP の障害追跡 | |
PPPoE のアクセスサーバーを構成する |
サービスプロバイダ会社の場合、DSL 接続を介してサイトに到達するクライアントに対してインターネットサービスやその他のサービスを提供できます。まず、PPPoE トンネルに使用するサーバー上のインタフェースを決定する必要があります。次に、ユーザーが使用できるサービスの内容を定義します。
アクセスサーバー上でスーパーユーザーになります。
PPPoE トンネル専用の Ethernet インタフェースの名前を /etc/ppp/pppoe.if ファイルに追加します。
たとえば、次の /etc/ppp/pppoe.if ファイルを 例 — PPPoE トンネルの構成 で示したアクセスサーバー dslserve に使用します。
# cat /etc/ppp/pppoe.if hme1 hme2 |
PPPoE を使用するためのインタフェースを構成します。
# /etc/init.d/pppd start |
(省略可能) サーバー上のインタフェースが PPPoE に plumb されていることを確認します。
# /usr/sbin/sppptun query hme1:pppoe hme1:pppoed hme2:pppoe hme2:pppoed |
この例は、インタフェース hme1 および hme2 が現在 PPPoE に plumb されていることを示しています。/usr/sbin/sppptun コマンドを使ってインタフェースを手動で PPPoE に plumb することもできます。 手順については、/usr/sbin/sppptun コマンドを参照してください。
アクセスサーバー上でスーパーユーザーになります。
/etc/ppp/pppoe ファイルで、アクセスサーバーが提供する広域サービスを定義します。
次の /etc/ppp/pppoe ファイルは、図 26–5 で示したアクセスサーバー dslserve によって提供されるサービスをリストしています。
device hme1,hme2 service internet pppd "proxyarp 192.168.1.1:" service debugging pppd "debug proxyarp 192.168.1.1:" |
このファイルの例では、dslserve の Ethernet インタフェース hme1 および hme2 でインターネットサービスが宣言されています。また、Ethernet インタフェース上の PPP リンクでデバッグがオンに設定されています。
ダイアルインサーバーと同じ方法で PPP 構成ファイルを設定します。
手順については、ダイアルインサーバーを介した通信を構成するを参照してください。
# /etc/init.d/pppd start |
pppd もまた、/etc/ppp/pppoe.if にリストされるインタフェースを plumb します。
アクセスサーバー上でスーパーユーザーになります。
必要に応じて /etc/ppp/pppoe を変更します。
pppoed デーモンに新しいサービスを認識させます。
# pkill -HUP pppoed |
次に、インタフェースを PPPoE クライアントのグループに限定する手順を説明します。この作業を実行する前に、インタフェースに割り当てているクライアントの実 Ethernet MAC アドレスを取得する必要があります。
システムによっては、Ethernet インタフェース上で MAC アドレスを変更できます。この機能は便利ですが、セキュリティ対策としては考えないでください。
次の手順では、例 — PPPoE トンネルの構成 で示した例を使用して、dslserve のインタフェースのうちの 1 つ hme1 を MiddleCo のクライアントに予約する方法を示しています。
アクセスサーバーの PPPoE 用インタフェースを構成する方法 で示した手順に従ってアクセスサーバーのインタフェースを構成します。
アクセスサーバーのクライアントにサービスを提供する方法 で示した手順に従ってサービスを定義します。
サーバーの /etc/ethers データベースにクライアントのエントリを作成します。
次は、Red、Blue、および Yellow というクライアントのエントリの例です。
8:0:20:1:40:30 redether 8:0:20:1:40:10 yellowether 8:0:20:1:40:25 blueether |
この例では、クライアントの Red、Yellow、および Blue の Ethernet アドレスに redether、yellowether、および blueether という記号名を割り当てています。MAC アドレスへの記号名の割り当ては任意です。
特定のインタフェース上で提供されるサービスを限定するには、次の情報を /etc/ppp/pppoe.device ファイルで定義します。
このファイル名で、device は定義するデバイスの名前です。
# vi /etc/ppp/pppoe.hme1 service internet pppd "name dslserve-hme1" clients redether,yellowether,blueether |
dslserve-hme1 はアクセスサーバーの名前で、pap-secrets ファイル内の同じエントリで使用されます。clients オプションは、インタフェース hme1 の使用を Ethernet 記号名が redether、yellowether、および blueether であるクライアントに限定します。
/etc/ethers でクライアントの MAC アドレスに記号名を定義していない場合は、clients オプションの引数として数値アドレスを使用できます。このとき、ワイルドカードも使用できます。
たとえば、clients 8:0:20:*:*:* のような数値アドレスを指定できます。このアドレスは、/etc/ethers にリストされているクライアントのうち 8:0:20 で始まる MAC アドレスを持つクライアントに対してだけアクセスを許可します。
アクセスサーバーの /etc/ppp/pap-secrets ファイルを作成します。
Red dslserve-hme1 redpasswd * Blue dslserve-hme1 bluepasswd * Yellow dslserve-hme1 yellowpassd * |
エントリは、dslserve の hme1 インタフェース上で PPP を実行することを許可されたクライアントの PAP 名およびパスワードです。
PAP 認証の詳細は、PAP 認証の設定を参照してください。
作業 |
参照先 |
---|---|
PPPoE についてさらに学ぶ | |
PPPoE および PPP の障害追跡 | |
PPPoE クライアントを構成する | |
クライアントの PAP 認証を構成する | |
サーバー上の PAP 認証を構成する |
この章では、Solaris PPP 4.0 で発生する一般的な問題の障害追跡に関する情報を提供します。次の項目について説明します。
James Carlson による「PPP Design, Implementation, and Debugging」やオーストラリア国立大学の Web サイトなどの情報源も、PPP の障害追跡に詳細なアドバイスを提供しています。詳細は、PPP に関する専門技術者向けのリファレンスブックおよび PPP に関する Web サイトを参照してください。
次の作業マップを使用すれば、一般的な PPP の問題のためのアドバイスや解決方法をすばやく探すことができます。
表 31–1 PPP の障害追跡 (作業マップ)
作業 |
定義 |
参照先 |
---|---|---|
PPP リンクに関する診断情報を取得する |
PPP 診断ツールを使って障害追跡の出力を取得する | |
PPP リンクのデバッグ情報を取得する |
pppd debug コマンドを使って障害追跡の出力を生成する | |
ネットワークレイヤーでの一般的な問題を障害追跡する |
一連の確認作業を行いネットワーク関連の PPP 問題を特定し解決する | |
一般的な通信の問題を障害追跡する |
PPP リンクに影響を与える通信の問題を特定し解決する | |
構成の問題を障害追跡する |
PPP 構成ファイルで問題を特定し解決する | |
モデム関連の問題を障害追跡する |
モデムの問題を特定し解決する | |
chat スクリプト関連の問題を障害追跡する |
ダイアルアウトマシン上の chat スクリプトの問題を特定し解決する | |
シリアル回線の速度の問題を障害追跡する |
ダイアルインサーバー上で回線速度の問題を特定し解決する | |
専用回線の一般的な問題を障害追跡する |
専用回線の問題を特定し解決する | |
認証に関連する問題を障害追跡する |
認証データベースに関連する問題を特定し解決する | |
PPPoE の問題領域を障害追跡する |
PPP 診断ツールを使用して、PPPoE の問題を特定し解決するための出力を得る |
PPP リンクは、一般に次の 3 つの主要な領域で障害が発生します。
接続の確立に失敗する
通常の使用の中で接続パフォーマンスが低下する
接続のどちらかの側でネットワークに原因と考えられる問題が発生する
この節では、pppd および関連するログファイルから診断情報を取得する方法について説明します。この章の残りの節では、PPP 障害追跡ツールを使って発見し解決できる PPP に関する一般的な問題を説明します。
次に、ローカルマシン上の接続の現在の動作を表示する手順を説明します。
ローカルマシン上でスーパーユーザーになります。
PPP に設定されているシリアルデバイスを引数として pppd を実行します。
# pppd /dev/ttyname debug updetach |
# pppd /dev/cua/b debug updetach have route to 0.0.0.0/0.0.0.0 via 172.21.0.4 serial speed set to 230400 bps Using interface sppp0 Connect: sppp0 <--> /dev/cua/b sent [LCP ConfReq id=0x7b <asyncmap 0x0> <magic 0x73e981c8> <pcomp> <accomp>] rcvd [LCP Ident id=0x79 magic=0x0 "ppp-2.4.0b1 (Sun Microsystems, Inc., Dec 6 2000 09:36:22)"] Peer Identification: ppp-2.4.0b1 (Sun Microsystems, Inc., Dec 6 2000 09:36:22) rcvd [LCP ConfRej id=0x7b <asyncmap 0x0>] sent [LCP Ident id=0x7c magic=0x0 "ppp-2.4.0b1 (Sun Microsystems, Inc., Nov 15 2000 09:38:33)" sent [LCP ConfReq id=0x7d <magic 0x73e981c8> <pcomp> <accomp>] rcvd [LCP ConfAck id=0x7d <magic 0x73e981c8> <pcomp> <accomp>] rcvd [LCP ConfAck id=0x78 <magic 0xdd4ad820> <pcomp> <accomp>] sent [LCP ConfAck id=0x78 <magic 0xdd4ad820> <pcomp> <accomp>] sent [LCP Ident id=0x7e magic=0x73e981c8 "ppp-2.4.0b1 (Sun Microsystems, Inc., Nov 15 2000 09:38:33)"] sent [IPCP ConfReq id=0x3d <addr 0.0.0.0> <compress VJ 0f 01>] rcvd [LCP Ident id=0x7a magic=0xdd4ad820 "ppp-2.4.0b1 (Sun Microsystems, Inc., Dec 6 2000 09:36:22)"] Peer Identification: ppp-2.4.0b1 (Sun Microsystems, Inc., Dec 6 2000 09:36:22) rcvd [IPCP ConfReq id=0x92 <addr 10.0.0.1> <compress VJ 0f 01> sent [IPCP ConfAck id=0x92 <addr 10.0.0.1> <compress VJ 0f 01> rcvd [IPCP ConfNak id=0x3d <addr 10.0.0.2>]] sent [IPCP ConfReq id=0x3e <addr 10.0.0.2> <compress VJ 0f 01>] rcvd [IPCP ConfAck id=0x3e <addr 10.0.0.2> <compress VJ 0f 01>] local IP address 10.0.0.2 remote IP address 10.0.0.1 |
# pppd /dev/se_hdlc1 default-asyncmap debug updetach pppd 2.4.0b1 (Sun Microsystems, Inc., Oct 24 2001 07:13:18) started by root, uid 0 synchronous speed appears to be 0 bps init option: '/etc/ppp/peers/syncinit.sh' started (pid 105122) Serial port initialized. synchronous speed appears to be 64000 bps Using interface sppp0 Connect: sppp0 <--> /dev/se_hdlc1 sent [LCP ConfReq id=0xe9 <magic 0x474283c6><pcomp> <accomp>] rcvd [LCP ConfAck id=0xe9 <magic 0x474283c6><pcomp> <accomp>] rcvd [LCP ConfReq id=0x22 <magic 0x8e3a53ff><pcomp> <accomp>] sent [LCP ConfReq id=0x22 <magic 0x8e3a53ff><pcomp> <accomp>] sent [LCP Ident id=0xea magic=0x474283c6 "ppp-2.4.0b1 (Sun Microsystems, Inc., Oct 22 2001 14:31:44)"] sent [IPCP ConfReq id=0xf7 <addr 0.0.0.0> <compress VJ Of o1>]] sent [CCP ConfReq id=0x3f <deflate 15> <deflate(old#) 15> <bsd v1 15>] rcvd [LCP Ident id=0x23 magic=0x8e3a53ff "ppp-2.4.0b1 (Sun Microsystems, Inc., Oct 22 2001 14:31:44)"] Peer Identification: ppp-2.4.0b1 (Sun Microsystems, Inc., Oct 22 2001 14:31:44) rcvd [IPCP ConfReq id=0x25 <addr 10.0.0.1> <compress VJ Of 01>] sent [IPCP ConfAck id=0x25 <addr 10.0.0.1> <compress VJ Of 01>] rcvd [CCP ConfReq id=0x3 <deflate 15> <deflate(old#) 15 <bsd v1 15>] sent [CCP ConfAck id=0x3 <deflate 15> <deflate(old#) 15 <bsd v1 15>] rcvd [IPCP ConfNak id=0xf8 <addr 10.0.0.2>] rcvd [IPCP ConfReq id=0xf7 <addr 10.0.0.2> <compress VJ Of 01>] rcvd [CCP ConfAck id=0x3f <deflate 15> <deflate(old#) 15 <bsd v1 15>] Deflate (15) compression enabled rcvd [IPCP ConfAck id=0xf8 <addr 10.0.0.2> <compress VJ Of 01>] local IP address 10.0.0.2 remote IP address 10.0.0.1 |
次に、pppd コマンドを使ってデバッグ情報を取得する方法を示します。
手順 1 から手順 3 までは各ホストごとに 1 度実行するだけでかまいません。その後、手順 4 に進んでホストのデバッグをオンに設定できます。
pppd からの出力を保持するためのログファイルを作成します。
% touch /var/log/pppdebug |
次の pppd 用の syslog 機能を /etc/syslog.conf に追加します。
daemon.debug;local2.debug /var/log/pppdebug |
syslogd を再起動します。
% pkill -HUP -x syslogd |
pppd の次の構文を使用して、特定のピアに対する呼び出しのデバッグをオンに設定します。
% pppd debug call peer-name |
peer-name は、/etc/ppp/peers ディレクトリにあるファイル名でなければなりません。
ログファイルの内容を表示します。
% tail -f /var/log/pppdebug |
ログファイルの例については、例 31–3 を参照してください。
PPP リンクがアクティブになっているのに、リモートネットワーク上のホストにほとんど接続できない場合、ネットワークに問題のある可能性があります。この節では、PPP リンクに影響を与えるネットワークの問題を特定し解決する方法について説明します。
ローカルマシン上でスーパーユーザーになり、問題のある接続を切断します。
次のオプションを PPP 構成に追加して、構成ファイルのオプションのプロトコルを無効にします。
noccp novj nopcomp noaccomp default-asyncmap |
このオプションは、もっとも単純で圧縮を行わない PPP を使用可能にします。コマンド行でこれらのオプションを引数として pppd を実行してみます。これまで接続できなかったホストに接続できれば、次のいずれかの位置にオプションを追加します。
/etc/ppp/peers/peer-name、call オプションの後
/etc/ppp/options、オプションを広域的に適用する場合
リモートピアを呼び出します。次に、デバッグをオンに設定します。
% pppd debug call peer-name |
chat の -v オプションを使用して、chat プログラムから冗長ログを取得します。
たとえば、PPP 構成ファイルで次の形式を使用します。
connect 'chat -v -f /etc/ppp/chatfile' |
Telnet または他のアプリケーションを使ってリモートホストに接続し、問題を再度発生させてみます。
デバッグログを調べます。これでもリモートホストに接続できない場合は、PPP の問題はネットワークに関連している可能性があります。
リモートホストの IP アドレスが登録されているインターネットアドレスであることを確認します。
組織によっては、ローカルネットワーク内では通用するが、インターネットへは経路指定できない内部 IP アドレスを割り当てる場合があります。リモートホストが社内にある場合、インターネットに接続するためには、管理者は、NAT (名前- アドレス変換) またはプロキシサーバーを設定する必要があります。リモートホストが社内にない場合は、遠隔組織に問題を報告する必要があります。
経路指定テーブルを調べます。
(省略可能) マシンがルーターである場合、オプションの機能を確認します。
# ndd -set /dev/ip ip_forwarding 1 |
ndd の詳細は、ndd(1M) のマニュアルページを参照してください。
netstat -s および同様のツールから取得した統計を確認します。
netstat の詳細は、netstat(1M) のマニュアルページを参照してください。
netstat -s によって生成されたメッセージを使用すると、次の表に示したネットワークの問題を解決できます。
表 31–2 PPP に影響を与える一般的なネットワークの問題
メッセージ |
問題 |
解決方法 |
---|---|---|
IP packets not forwardable |
ローカルホストで送信経路が見つからない |
ローカルホストの経路指定テーブルに欠如している送信経路を追加する |
ICMP input destination unreachable |
ローカルホストで送信経路が見つからない |
ローカルホストの経路指定テーブルに欠如している送信経路を追加する |
ICMP time exceeded |
2 つのルーターが同じ着信アドレスを互いに送信し、パケットが互いに何度も往復し、TTL (存続時間) の値を超過した |
traceroute を使ってルーティングループの源を見つけ、エラーになっているルーターの管理者に連絡する。traceroute の詳細は、traceroute(1M) のマニュアルページを参照 |
IP packets not forwardable |
ローカルホストで送信経路が見つからない |
ローカルホストの経路指定テーブルに欠如している送信経路を追加する |
ICMP input destination unreachable |
ローカルホストで送信経路が見つからない |
ローカルホストの経路指定テーブルに欠如している送信経路を追加する |
DNS 構成を確認します。
ネームサービス構成に問題があると、IP アドレスを解釈処理できないため、アプリケーションは障害を発生します。
ネームサービスの問題を解決するための情報については、『Solaris のシステム管理 (ネーミングとディレクトリサービス : DNS、NIS、LDAP 編)』の「DNS の障害追跡 (参照情報)」を参照してください。
通信の問題は、2 つのピアが接続の確立に失敗したときに発生します。これらの問題は、実際は、chat スクリプトの構成が不適切であるために発生するネゴシエーションの問題であることがしばしばあります。この節では、通信の問題を解決するための情報を提供します。問題のある chat スクリプトによって発生するネゴシエーションの問題の解決方法については、表 31–5 を参照してください。
ローカルマシン上でスーパーユーザーになり、ピアを呼び出します。
リモートピアを呼び出します。次に、デバッグをオンに設定します。
% pppd debug call peer-name |
通信の問題によっては、問題解決のためにピアからデバッグ情報を取得する必要がある場合があります。
次の表に示す通信問題のリストに、取得したログの内容に対応する症状があるかどうかを確認します。
表 31–3 PPP に影響を与える一般的な通信の問題
症状 |
問題 |
解決方法 |
---|---|---|
too many Configure-Requests メッセージ |
あるピアが他のピアを認識できない |
次の問題を確認する
|
pppd debug の出力は LCP が起動していることを示しているが、より上位のプロトコルが失敗したか、あるいは CRC エラーを示している |
非同期制御文字マップ (ACCM) が正しく設定されていない |
default-async オプションを使用して ACCM を標準のデフォルトである FFFFFFFF に設定する。まずコマンド行で pppd のオプションとして default-async を使用してみる。問題が解決したら、default-async を /etc/ppp/options または call オプションの後の /etc/ppp/peers/peer-name に追加する |
pppd debug の出力は IPCP が起動していることを示しているが、すぐに終了してしまう |
IP アドレスの設定が間違っている可能性がある |
|
接続のパフォーマンスが非常に低い |
フロー制御構成のエラー、モデム設定のエラー、不適切に設定された DTE レートなどにより、モデムが適切に構成されていない可能性がある |
モデム構成を確認し、適宜調整する |
PPP の問題には、PPP 構成ファイルの問題が原因となっているものがあります。この節では、一般的な構成の問題を特定して解決するための情報を提供します。
ローカルマシン上でスーパーユーザーになります。
リモートピアを呼び出します。次に、デバッグをオンに設定します。
% pppd debug call peer-name |
次の表に示す構成問題のリストに、取得したログの内容に対応する症状があるかどうかを確認します。
表 31–4 一般的な PPP 構成の問題
症状 |
問題 |
解決方法 |
---|---|---|
pppd debug の出力に「Could not determine remote IP address.」というエラーメッセージが含まれる |
/etc/ppp/peers/peer-name ファイルにそのピアの IP アドレスが存在しない。ピアが、接続ネゴシエーション時に IP アドレスを提供しない |
次の形式を使用して、pppd コマンド行、あるいは /etc/ppp/peers/peer-name でピアの IP アドレスを指定する :10.0.0.10 |
pppd debug の出力がCCP データ圧縮が失敗したことを示す。出力には接続が解除されたことも表示する |
ピアの PPP 圧縮設定が衝突している可能性がある |
ピアの 1 つで /etc/ppp/options に noccp オプションを追加して CCP 圧縮を無効にする |
モデムは、ダイアルアップリンクで問題の発生しやすい領域です。モデム構成でもっともよく発生する問題は、ピアからの応答がないことです。しかし、接続の問題の原因が本当にモデム構成の問題なのかどうかを判定することは難しい場合があります。
モデムの基本的な障害追跡に関するヒントは、『Solaris のシステム管理 (上級編)』の「端末とモデムの問題を解決する方法」を参照してください。モデムメーカーのマニュアルや Web サイトも、特定の装置に関する問題の解決に役立ちます。この節では、モデムの問題を特定して解決するためのヒントを提供します。
次の手順は、問題のあるモデム構成が接続の問題の原因となっているかどうかを判定するのに役立ちます。
PPP デバッグをオンに設定する方法 で説明した手順で、デバッグをオンに設定してピアを呼び出します。
作成された /var/log/pppdebug ログを表示します。
出力に次の症状が認められる場合は、モデム構成に問題がある可能性があります。
ピアから「recvd」メッセージが返されない
出力にピアからの LCP メッセージが含まれるが、接続は失敗し、ローカルマシンから「too many LCP Configure Requests」のメッセージが送信される
このメッセージは、ローカルマシンはピアを認識できるが、ピアはローカルマシンを認識できないことを示します。
接続が SIGHUP 信号で終了する
ping を使用してさまざまなサイズのパケットを接続上に送信します。
ping の詳細は、ping(1M) のマニュアルページを参照してください。
小さいパケットは受信されるが、大きいパケットはドロップされる場合、モデムに問題があることを示します。
インタフェース sppp0 上のエラーを確認します。
% netstat -ni Name Mtu Net/Dest Address Ipkts Ierrs Opkts Oerrs Collis Queue lo0 8232 127.0.0.0 127.0.0.1 826808 0 826808 0 0 0 hme0 1500 172.21.0.0 172.21.3.228 13800032 0 1648464 0 0 0 sppp0 1500 10.0.0.2 10.0.0.1 210 0 128 0 0 0 |
インタフェースのエラーが時間がたつにつれて増えている場合は、モデム構成に問題がある可能性があります。
chat スクリプトは、ダイアルアップリンクで問題が発生しやすい領域です。この節では、chat からデバッグ情報を取得する手順と、一般的な問題を解決するためのヒントを示します。
ダイアルアウトマシン上でスーパーユーザーになります。
/etc/ppp/peers/peer-name ファイルを編集してピアが呼び出されるようにします。
connect オプションで指定されている chat コマンドに引数として -v を追加します。
connect "/usr/bin/chat -v -f /etc/ppp/chat-script-name" |
/etc/ppp/connect-errors ファイルの chat スクリプトのエラーを表示します。
以下は、chat で見られる主なエラーです。
Oct 31 08:57:13 deino chat[107294]: [ID 702911 local2.info] expect (CONNECT) Oct 31 08:57:58 deino chat[107294]: [ID 702911 local2.info] alarm Oct 31 08:57:58 deino chat[107294]: [ID 702911 local2.info] Failed |
この例は、(CONNECT) 文字列を待つ間にタイムアウトしたことを示します。chat が失敗すると、pppd から次のメッセージを受け取ります。
Connect script failed |
次の表に、chat スクリプトの一般的なエラーと、エラー解決のためのヒントを示します。
表 31–5 chat スクリプトの一般的な問題
ダイアルインサーバーは、速度の設定の衝突が原因で問題が発生する可能性があります。次に示す手順は、接続の問題の原因がシリアル回線速度の衝突であることを特定するのに役立ちます。
/bin/login のようなプログラムを介して PPP を起動し、回線の速度を指定した
PPP を mgetty から起動し、誤ってビットレートを指定した
ダイアルインサーバーにログインします。デバッグをオンに設定してピアを呼び出しま す。
手順については、PPP デバッグをオンに設定する方法を参照してください。
作成された /var/log/pppdebug ログを表示します。
出力に次のメッセージがないか確認します。
LCP too many configure requests |
PPP が /bin/login のようなプログラムを介して起動されているかどうかを調べ、設定されている回線速度を調べます。
このような状況では、pppd はもともと設定されていた回線速度を /bin/login で指定されている速度に変更します。
ユーザーが PPP を mgetty コマンドから起動し、偶然にビットレートを指定していないかどうか確認します。
この処理もまた、シリアル回線速度の衝突を引き起こします。
次のようにしてシリアル回線速度の衝突の問題を解決します。
専用回線でもっとも一般的な問題は、パフォーマンスの低下です。ほとんどの場合、問題を解決するためには、電話会社に相談する必要があります。
表 31–6 一般的な専用回線の問題
症状 |
問題 |
解決方法 |
---|---|---|
接続が開始しない |
CSU BPV (CSU 極性違反) が原因の可能性がある。接続の一方の側が AMI 回線用に設定されており、もう一方の側が ESF の B8ZS (Bit 8 Zero Substitute) 用に設定されている。 |
米国またはカナダのユーザーは、この問題を CSU/DSU のメニューから直接解決できる。詳細は、CSU/DSU メーカーのマニュアルを参照。 その他の地域のユーザーは、プロバイダが CSU BPV の解決策を用意している可能性がある |
接続のパフォーマンスが非常に低い |
接続上でトラフィックが持続しているときに、pppd debug の出力が CRC エラーを示す。回線に、電話会社とネットワークの間の誤った設定によって生じた刻時の問題がある可能性がある。 |
電話会社に連絡し、「ループ刻時」を使用していたことを確認する。 構造化されていない専用回線では、刻時を提供する必要がある場合がある。北米のユーザーはループクロックを使用すること。
|
症状 |
問題 |
解決方法 |
---|---|---|
pppd debug の出力が「Peer is not authorized to use remote address address」というメッセージを示す |
PAP 認証を使用しており、リモートピアの IP アドレスが /etc/ppp/pap-secrets ファイルに存在しない |
/etc/ppp/pap-secrets ファイルで、ピアのエントリの後にアスタリスク (*) を追加する |
pppd debug の出力は LCP が起動していることを示しているが、その直後に終了してしまう |
特定のセキュリティプロトコルのデータベースでパスワードが間違っている可能性がある |
/etc/ppp/pap-secrets または /etc/ppp/chap-secrets ファイルでピアのパスワードを確認する |
PPP および標準の UNIX ユーティリティを使用して PPPoE の問題を特定できます。この節では、PPPoE のデバッグ情報を取得する方法について説明します。また、PPPoE 関連の問題を解決する方法についても記述します。
接続上の問題の原因が PPPoE だと思われるとき、次の診断ツールを使って障害追跡情報を取得できます。
PPPoE トンネルを実行しているマシン、つまり PPPoE クライアントまたは PPPoE アクセスサーバーでスーパーユーザーになります。
PPP デバッグをオンに設定する方法 で説明した手順で、デバッグをオンに設定します。
ログファイル /var/log/pppdebug の内容を表示します。
以下の例は、PPPoE トンネルとの接続で生成されたログファイルの一部です。
Sep 6 16:28:45 enyo pppd[100563]: [ID 702911 daemon.info] Plugin pppoe.so loaded. Sep 6 16:28:45 enyo pppd[100563]: [ID 860527 daemon.notice] pppd 2.4.0b1 (Sun Microsystems, Inc., Sep 5 2001 10:42:05) started by troot, uid 0 Sep 6 16:28:46 enyo pppd[100563]: [ID 702911 daemon.debug] connect option: '/usr/lib/inet/pppoec -v hme0' started (pid 100564) Sep 6 16:28:46 enyo pppd[100563]: [ID 702911 daemon.info] Serial connection established. Sep 6 16:28:46 enyo pppd[100563]: [ID 702911 daemon.info] Using interface sppp0 Sep 6 16:28:46 enyo pppd[100563]: [ID 702911 daemon.notice] Connect: sppp0 <--> /dev/sppptun Sep 6 16:28:46 enyo pppd[100563]: [ID 702911 daemon.debug] /etc/ppp/pap-secrets is apparently empty Sep 6 16:28:46 enyo pppd[100563]: [ID 702911 daemon.debug] /etc/ppp/chap-secrets is apparently empty Sep 6 16:28:46 enyo pppd[100563]: [ID 702911 daemon.debug] sent [LCP ConfReq id=0xef <mru 1492> asyncmap 0x0 <magic 0x77d3e953><pcomp><acomp> Sep 6 16:28:46 enyo pppd[100563]: [ID 702911 daemon.debug] rcvd [LCP ConfReq id=0x2a <mru 1402> asyncmap 0x0 <magic 0x9985f048><pcomp><acomp |
デバッグの出力によって問題を特定できない場合は、次の手順に進みます。
# pppd connect "/usr/lib/inet/pppoec -v interface-name" |
pppoec は、診断情報を stderr に送信します。pppd をフォアグラウンドで実行する場合、出力が画面に表示されます。pppd をバックグラウンドで実行する場合、出力は /etc/ppp/connect-errors に送られます。
次の例は、PPPoE トンネルがネゴシエートされたときに生成されるメッセージです。
Connect option: '/usr/lib/inet/pppoec -v hme0' started (pid 100564) /usr/lib/inet/pppoec: PPPoE Event Open (1) in state Dead (0): action SendPADI (2) /usr/lib/inet/pppoec: Sending PADI to ff:ff:ff:ff:ff:ff: 18 bytes /usr/lib/inet/pppoec: PPPoE State change Dead (0) -> InitSent (1) /usr/lib/inet/pppoec: Received Active Discovery Offer from 8:0:20:cd:c1:2/hme0:pppoed /usr/lib/inet/pppoec: PPPoE Event rPADO+ (5) in state InitSent (1): action SendPADR+ (5) /usr/lib/inet/pppoec: Sending PADR to 8:0:20:cd:c1:2: 22 bytes /usr/lib/inet/pppoec: PPPoE State change InitSent (1) -> ReqSent (3) /usr/lib/inet/pppoec: Received Active Discovery Session-confirmation from 8:0:20:cd:c1:2/hme0:pppoed /usr/lib/inet/pppoec: PPPoE Event rPADS (7) in state ReqSent (3): action Open (7) /usr/lib/inet/pppoec: Connection open; session 0002 on hme0:pppoe /usr/lib/inet/pppoec: PPPoE State change ReqSent (3) -> Convers (4) /usr/lib/inet/pppoec: connected |
診断メッセージによって問題を特定できない場合は、次の手順に進みます。
snoop を実行します。次にトレースをファイルに保存します。
snoop の詳細は、snoop(1M) のマニュアルページを参照してください。
# snoop -o pppoe-trace-file |
snoop トレースファイルを表示します。
# snoop -i pppoe-trace-file -v pppoe |
ETHER: ----- Ether Header ----- ETHER: ETHER: Packet 1 arrived at 6:35:2.77 ETHER: Packet size = 32 bytes ETHER: Destination = ff:ff:ff:ff:ff:ff, (broadcast) ETHER: Source = 8:0:20:78:f3:7c, Sun ETHER: Ethertype = 8863 (PPPoE Discovery) ETHER: PPPoE: ----- PPP Over Ethernet ----- PPPoE: PPPoE: Version = 1 PPPoE: Type = 1 PPPoE: Code = 9 (Active Discovery Initiation) PPPoE: Session Id = 0 PPPoE: Length = 12 bytes PPPoE: PPPoE: ----- Service-Name ----- PPPoE: Tag Type = 257 PPPoE: Tag Length = 0 bytes PPPoE: PPPoE: ----- Host-Uniq ----- PPPoE: Tag Type = 259 PPPoE: Tag Length = 4 bytes PPPoE: Data = Ox00000002 PPPoE: . . . ETHER: ----- Ether Header ----- ETHER: ETHER: Packet 5 arrived at 6:35:2.87 ETHER: Packet size = 60 bytes ETHER: Destination = 8:0:20:78:f3:7c, Sun) ETHER: Source = 0:2:fd:39:7f:7, ETHER: Ethertype = 8864 (PPPoE Session) ETHER: PPPoE: ----- PPP Over Ethernet ----- PPPoE: PPPoE: Version = 1 PPPoE: Type = 1 PPPoE: Code = 0 (PPPoE Session) PPPoE: Session Id = 24383 PPPoE: Length = 20 bytes PPPoE: PPP: ----- Point-to-Point Protocol ----- PPP: PPP-LCP: ----- Link Control Protocol ----- PPP-LCP: PPP-LCP: Code = 1 (Configure Request) PPP-LCP: Identifier = 80 PPP-LCP: Length = 18 |
この章では、Solaris PPP 4.0 について詳細で概念的な情報を提供します。トピックは次のとおりです。
Solaris PPP 4.0 には、PPP 構成を定義するのに使用するオプションが多数含まれます。これらのオプションは、PPP 構成ファイルまたはコマンド行で使用するほか、ファイルでの使用とコマンド行での使用を組み合わせることもできます。この節では、PPP オプションの構成ファイルでの使用と PPP コマンドの引数としての使用について詳細に説明します。
Solaris PPP 4.0 は柔軟に構成できます。PPP オプションを次の場所で定義できます。
PPP 構成ファイル
コマンド行で実行される PPP コマンド
前記 2 つの場所の組み合わせ
次の表に、PPP 構成ファイルとコマンドをリストします。
表 32–1 PPP 構成ファイルとコマンドの概要
ファイルまたはコマンド |
定義 |
参照先 |
---|---|---|
/etc/ppp/options |
たとえば、マシンがピアにピア自身の認証を要求するかどうかなど、システム上のすべての PPP リンクにデフォルトで適用される特性を含むファイル。このファイルがない場合、スーパーユーザー以外のユーザーは PPP の使用を禁止される | |
/etc/ppp/options.ttyname | ||
通常、ダイアルアウトマシンが接続するピアに関する情報を含むディレクトリ。このディレクトリ内のファイルは、pppd コマンドの call オプションで使用される | ||
リモートピア peer-name の特性を含むファイル。通常、リモートピアの電話番号やピアとの接続をネゴシエートするための chat スクリプトなどの特性が含まれる | ||
パスワード認証プロトコル (PAP) の認証に必要なセキュリティ資格を含むファイル | ||
チャレンジハンドシェーク認証プロトコル (CHAP) の認証に必要なセキュリティ資格を含むファイル | ||
PPP ユーザーのホームディレクトリ内のファイル。ダイアルインサーバーでもっともよく使用される。このファイルには、各ユーザーの構成に関する特定の情報が含まれる | ||
PPP リンクの開始および PPP リンクの特性の説明のためのコマンドとオプション |
PPP ファイルの説明については、pppd(1M) のマニュアルページを参照してください。 pppd(1M) には、pppd で使用できるすべてのオプションに関する詳細な説明もあります。すべての PPP 構成ファイルのサンプルテンプレートは、/etc/ppp にあります。
Solaris PPP 4.0 のすべての操作は、ユーザーが pppd コマンドを実行すると起動する pppd デーモンによって処理されます。ユーザーがリモートピアを呼び出すと、以下が発生します。
/etc/ppp/options
$HOME/.ppprc
/etc/ppp/options または $HOME/.ppprc の中で file または call オプションによって開かれたファイル
pppd がコマンド行を走査して使用中のデバイスを判定する。デーモンはまだ遭遇したオプションを解釈しない
pppd は次の条件に基づいて使用するシリアルデバイスを検出しようとする
シリアルデバイスがコマンド行またはそれ以前に処理した構成ファイルで指定されている場合、pppd はそのデバイス名を使用する
シリアルデバイスが指定されていない場合、pppd はコマンド行で notty、pty、または socket オプションを検索する。これらのオプションが指定されている場合、pppd はデバイス名が存在しないとみなす
上記以外の場合で、標準入力が tty に接続されていることを pppd が検出した場合は、tty の名前を使用する
それでも pppd がシリアルデバイスを見つけられない場合は、接続を終了し、エラーを発生させる
pppd は次に、/etc/ppp/options.ttyname ファイルが存在するかどうかをチェックする。ファイルが見つかると、pppd はそのファイルを構文解析する
pppd はコマンド行のオプションを処理する
pppd はリンク制御プロトコル (LCP) のネゴシエーションを行い、接続を確立する
(省略可能) 認証が必要な場合、pppd は、/etc/ppp/pap-secrets または /etc/ppp/chap-secrets を読み取り、反対側のピアを認証する
pppd デーモンがコマンド行または他の構成ファイルで call peer-name オプションに遭遇すると、/etc/ppp/peers/peer-name ファイルが読み取られます。
Solaris PPP 4.0 構成には特権の概念が含まれます。特権は、特に、同じオプションが複数の場所で呼び出されたときに、構成オプションの優先度を判定します。特権ソースから呼び出されたオプションは、非特権ソースから呼び出された同じオプションよりも優先されます。
唯一の特権ユーザーは、UID の値が 0 のスーパーユーザー (root) です。その他のすべてのユーザーは特権を与えられません。
次に、所有者にかかわらず特権を与えられる構成ファイルを示します。
/etc/ppp/options
/etc/ppp/options.ttyname
/etc/ppp/peers/peer-name
$HOME/.ppprc は、ユーザーが所有するファイルです。$HOME/.ppprc およびコマンド行から読み取られたオプションは、pppd を起動しているユーザーが root である場合にだけ特権が与えられます。
file オプションの引数は特権が与えられます。
オプションの中には、呼び出したユーザーまたはソースが特権を与えられていないと動作しないものがあります。コマンド行で呼び出されたオプションは、pppd コマンドを実行中のユーザーの特権を割り当てられます。これらのオプションは、pppd を起動しているユーザーが root でなければ、特権が与えられません。
オプション |
状態 |
意味 |
---|---|---|
domain |
特権がある |
使用には特権が必要 |
linkname |
特権がある |
使用には特権が必要 |
noauth |
特権がある |
使用には特権が必要 |
nopam |
特権がある |
使用には特権が必要 |
pam |
特権がある |
使用には特権が必要 |
plugin |
特権がある |
使用には特権が必要 |
privgroup |
特権がある |
使用には特権が必要 |
allow-ip addresses |
特権がある |
使用には特権が必要 |
name hostname |
特権がある |
使用には特権が必要 |
plink |
特権がある |
使用には特権が必要 |
noplink |
特権がある |
使用には特権が必要 |
plumbed |
特権がある |
使用には特権が必要 |
proxyarp |
noproxyarp が指定されている場合、特権がある |
特権のない使用はこのオプションを優先指定できない |
nodefaultroute が特権ファイルで、または特権ユーザーによって設定されている場合、特権がある |
非特権ユーザーはこのオプションを優先指定できない |
|
disconnect |
特権ファイルで、または特権ユーザーによって設定されている場合、特権がある |
非特権ユーザーはこのオプションを優先指定できない |
bsdcomp |
特権ファイルで、または特権ユーザーによって設定されている場合、特権がある |
非特権ユーザーは特権ユーザーが指定したサイズより大きいコードサイズを指定できない |
deflate |
特権ファイルで、または特権ユーザーによって設定されている場合、特権がある |
非特権ユーザーは特権ユーザーが指定したサイズより大きいコードサイズを指定できない |
connect |
特権ファイルで、または特権ユーザーによって設定されている場合、特権がある |
非特権ユーザーはこのオプションを優先指定できない |
init |
特権ファイルで、または特権ユーザーによって設定されている場合、特権がある |
非特権ユーザーはこのオプションを優先指定できない |
pty |
特権ファイルで、または特権ユーザーによって設定されている場合、特権がある |
非特権ユーザーはこのオプションを優先指定できない |
welcome |
特権ファイルで、または特権ユーザーによって設定されている場合、特権がある |
非特権ユーザーはこのオプションを優先指定できない |
ttyname |
特権ファイルで設定されている場合、特権がある
非特権ファイルで設定されている場合、特権がない |
pppd を誰が起動したかに関係なく、スーパーユーザー特権で開かれる
pppd を起動したユーザーの特権で開かれる |
ローカルマシン上のすべての PPP 通信にグローバルオプションを定義するには、/etc/ppp/options ファイルを使用します。/etc/ppp/options は特権ファイルです。pppd の規則ではありませんが、/etc/ppp/options はスーパーユーザーが所有してください。/etc/ppp/options で定義するオプションは、他のすべてのファイルおよびコマンド行内で定義される同じオプションより優先されます。
/etc/ppp/options で使用する可能性がある代表的なオプションを次に示します。
lock – UUCP 形式のファイルロックを有効にする
noauth – マシンが呼び出し元を認証しないことを示す
Solaris PPP 4.0 ソフトウェアには、デフォルトの /etc/ppp/options ファイルは含まれていません。pppd の動作に、/etc/ppp/options ファイルは必要ありません。マシンに /etc/ppp/options ファイルがない場合、そのマシンで pppd を実行できるのは root だけです。
シリアル回線を介した通信を定義する方法の説明に従って、テキストエディタを使用して /etc/ppp/options を作成する必要があります。マシンがグローバルオプションを必要としない場合は、空の /etc/ppp/options ファイルを作成できます。これで、root および一般ユーザーの両方がローカルマシン上で pppd を実行できます。
/etc/ppp/options.tmpl には、/etc/ppp/options ファイルに関する有用なコメントのほかに、グローバルな /etc/ppp/options ファイルに共通の次の 3 つのオプションが含まれます。
lock nodefaultroute noproxyarp |
オプション |
定義 |
---|---|
lock |
UUCP 形式のファイルロックを有効にする |
nodefaultroute |
デフォルトの送信経路を定義しないことを指定する |
noproxyarp |
proxyarp を許可しない |
/etc/ppp/options.tmpl をグローバルオプションファイルとして使用するには、/etc/ppp/options.tmpl の名前を /etc/ppp/options に変更します。次に、サイトの必要に応じてファイルの内容を変更します。
/etc/ppp/options の例 |
参照先 |
---|---|
ダイアルアウトマシン用 | |
ダイアルインサーバー用 | |
ダイアルインサーバー上での PAP サポート用 | |
ダイアルアウトマシン上での PAP サポート用 | |
ダイアルインサーバー上での CHAP サポート用 |
シリアル回線上の通信の特性を /etc/ppp/options.ttyname ファイルで設定できます。/etc/ppp/options.ttyname は特権ファイルです。 既存の /etc/ppp/options および $HOME/.ppprc ファイルを構文解析した後で pppd によって読み取られます。$HOME/.ppprc が存在しない場合、pppd は /etc/ppp/options を構文解析した後に、/etc/ppp/options.ttyname を読み取ります。
ttyname は、ダイアルアップリンク、専用回線リンクの両方で使用されます。ttyname は、モデムまたは ISDN TA が接続されている可能性があるマシン上の特定のシリアルポート (cua/a、cua/b など) を表します。
/etc/ppp/options.ttyname ファイルに名前を付けるときは、デバイス名にあるスラッシュ (/) をドット (.) に置き換えます。たとえば、デバイス cua/b 用の options ファイルの名前は /etc/ppp/options.cua.b. になります。
Solaris PPP 4.0 が正常に動作するうえで、/etc/ppp/options.ttyname ファイルは必要ありません。 サーバーがPPP 用のシリアル回線を1 つだけ持ち、オプションはほとんど必要ない場合、必要なオプションを別の構成ファイルまたはコマンド行で指定することができます。
ダイアルアップリンクでは、ダイアルインサーバー上のモデムが接続されているすべてのシリアルポートごとに、/etc/ppp/options.ttyname ファイルを個別に作成することもできます。通常のオプションは次のとおりです。
ダイアルインサーバーが必要とする IP アドレス
シリアルポート ttyname に着信する呼び出し元に特定の IP アドレスを使用させる必要がある場合は、このオプションを設定する。使用するアドレス空間により、予想される呼び出し元の数に比べて、PPP で使用可能な IP アドレスの数に制限がある場合がある。その場合は、ダイアルインサーバー上の PPP で使用されるシリアルインタフェースごとに IP アドレスを割り当てることを考える。この割り当ては、PPP に動的なアドレス指定を実装する
asyncmap map_value
asyncmap オプションは、特定のモデムまたは ISDN TA がシリアル回線上で受け取らない制御文字を割り当てる。xonxoff オプションを使用すると、pppd は自動的に 0xa0000 の asyncmap を設定する。
map_value は、16 進数で入力し、問題のある制御文字を指定する
init "chat -U -f /etc/ppp/mychat"
init オプションは、chat —U コマンド内の情報を使用して、シリアル回線上で通信を開始するようにモデムに指示する。モデムは、/etc/ppp/mychat ファイル内の chat 文字列を使用する
pppd(1M) のマニュアルページにリストされているセキュリティパラメータ
ダイアルアウトマシンでは、モデムが接続されているシリアルポート用に /etc/ppp/options.ttyname ファイルを作成することも、あるいは /etc/ppp/options.ttyname を使用しないでおくこともできます。
Solaris PPP 4.0 が正常に動作するうえで、/etc/ppp/options.ttyname ファイルは必要ありません。 ダイアルアウトマシンがPPP 用のシリアル回線を 1 つだけ持 ち、オプションはほとんど必要ない場合、必要なオプションを別の構成ファイルまたはコマンド行で指定することができます。
/etc/ppp/options.ttya.tmpl ファイルには、/etc/ppp/options.tty-name ファイルに関して有用なコメントが含まれています。また、テンプレートには /etc/ppp/options.tty-name ファイルに共通の次の 3 つのオプションが含まれます。
38400 asyncmap 0xa0000 :192.168.1.1 |
オプション |
定義 |
---|---|
38400 |
ポート ttya でこのボーレートを使用する |
asyncmap 0xa0000 |
ローカルマシンが接続に失敗したピアと通信できるように asyncmap 値 0xa0000 を割り当てる |
:192.168.1.1 |
接続上で着信しているすべてのピアに IP アドレス 192.168.1.1 を割り当てる |
サイトで /etc/ppp/options.ttya.tmpl を使用するには、/etc/ppp/options.tmpl の名前を /etc/ppp/options.ttya-name に変更します。ttya-name をモデムが接続しているシリアルポートの名前に置き換えます。次に、サイトの必要に応じてファイルの内容を変更します。
/etc/ppp/options.ttyname の例 |
参照先 |
---|---|
ダイアルアウトマシン用 | |
ダイアルインサーバー用 |
この節では、ダイアルインサーバー上でユーザーを設定する方法について詳細に説明します。
$HOME/.ppprc ファイルは、独自の PPP オプションを設定するユーザーを対象としています。管理者が、ユーザーのために $HOME/.ppprc を設定することもできます。
$HOME/.ppprc 内のオプションは、ファイルを呼び出しているユーザーに特権がある場合だけ、特権を与えられます。
呼び出し元が pppd コマンドを使って呼び出しを開始した場合、pppd デーモンは、.ppprc ファイルを 2 番目に確認します。
ダイアルインサーバーで $HOME/.ppprc を設定する手順については、ダイアルインサーバーのユーザーを設定するを参照してください。
$HOME/.ppprc は、ダイアルアウトマシン上で Solaris PPP 4.0 が正常に動作するのに必要ではありません。
ダイアルアウトマシンでは、特別な場合を除いて、$HOME/.ppprc は必要ありません。以下を行う場合は、1 つ以上の .ppprc ファイルを作成します。
通信のニーズが異なる複数のユーザーが同じマシンからリモートピアを呼び出すのを許可する場合。このような場合は、ダイアルアウトする必要がある各ユーザーのホームディレクトリに個別の .ppprc ファイルを作成する
Van Jacobson 圧縮を無効にするなど、接続に固有の問題を制御するオプションを指定する必要がある場合。接続に関する問題の障害追跡については、James Carlson による「PPP Design, Implementation, and Debugging」および pppd(1M) のマニュアルページを参照。
.ppprc ファイルは、ダイアルインサーバーを構成するときにもっとも頻繁に使用されるため、.ppprc の構成手順については ダイアルインサーバーのユーザーを構成する方法を参照してください。
ダイアルインサーバーと通信するには、サーバーに関する情報を収集し、いくつかのファイルを編集する必要があります。特に大切なのは、ダイアルアウトマシンが呼び出す必要があるすべてのダイアルインサーバーについて通信要件を設定する必要があることです。ダイアルインサーバーに関する ISP 電話番号などのオプションは、/etc/ppp/options.ttyname ファイルで指定できます。 ただし、ピア情報は、/etc/ppp/peers/peer-name ファイルで設定するのが最適です。
/etc/ppp/peers/peer-name ファイルは、ダイアルアウトマシン上で Solaris PPP 4.0 が正常に動作するのに必要ではありません。
特定のピアと通信するための情報を指定するには、/etc/ppp/peers/peer-name ファイルを使用します。/etc/ppp/peers/peer-name を使用すると、一般ユーザーは、自分で設定することを許可されていない、あらかじめ選択された特権オプションを呼び出すことができます。
たとえば、非特権ユーザーの場合、noauth オプションが /etc/ppp/peers/peer-name ファイルで指定されていると、このオプションが優先されます。ユーザーが、認証資格を提供されていない peerB への接続を設定したいとします。スーパーユーザーは、noauth オプションを含む /etc/ppp/peers/peerB ファイルを作成できます。noauth は、ローカルマシンが peerB からの呼び出しを認証しないことを示します。
pppd デーモンは、次のオプションを検出すると、/etc/ppp/peers/peer-name を読み取ります。
call peer-name |
ダイアルアウトマシンが通信する必要があるターゲットピアごとに /etc/ppp/peers/peer-name ファイルを作成できます。これは、スーパーユーザーの権限がなくても特定のダイアルアウト接続を呼び出すことを一般ユーザーに許可できる点で特に便利です。
/etc/ppp/peers/peer-name で指定する代表的なオプションを次に示します。
PAP または CHAP 認証を行う場合に、ダイアルアウトマシンのログイン名として user_name をダイアルインサーバーに指定する
peer-name をダイアルインマシンの名前として使用する。remotename は、/etc/ppp/pap-secrets または /etc/ppp/chap-secrets ファイルを走査するときに、PAP または CHAP 認証と連携して使用される
chat スクリプト内の命令を使ってダイアルインサーバーへの通信を開く
通信開始時に、ピア peer-name の認証を行わない
ピアとのネゴシエートに使用する初期 IP アドレスを 0.0.0.0 に設定する。ほとんどの ISP への接続を設定するときに noipdefault を使用すると、ピア間で容易に IPCP ネゴシエーションを行うことができる
接続上で IP が確立されたときに、デフォルトの IPv4 経路指定をインストールする
特定のターゲットピアに適用する可能性がある上記以外のオプションについては、pppd(1M) のマニュアルページを参照してください。
/etc/ppp/peers/myisp.tmpl ファイルには、/etc/ppp/peers/peer-name ファイルに関して有用なコメントが含まれています。 また、テンプレートには、/etc/ppp/peers/peer-name ファイルで使用する可能性がある次の一般的なオプションが含まれます。
connect "/usr/bin/chat -f /etc/ppp/myisp-chat" user myname remotename myisp noauth noipdefault defaultroute updetach noccp |
オプション |
定義 |
---|---|
connect "/usr/bin/chat -f /etc/ppp/myisp-chat" |
chat スクリプト /etc/ppp/myisp-chat を使ってピアを呼び出す |
user myname |
このアカウント名をローカルマシンに使用する。myname は、ピアの /etc/ppp/pap-secrets ファイル内でのこのマシンの名前 |
remotename myisp |
myisp をローカルマシンの /etc/ppp/pap-secrets ファイル内のピア名として認識する。 |
noauth |
認証資格を提供するためのピアの呼び出しを要求しない |
noipdefault |
ローカルマシンにデフォルトの IP アドレスを使用しない |
defaultroute |
ローカルマシンに割り当てられているデフォルトの経路指定を使用する |
updetach | |
noccp |
CCP 圧縮を使用しない |
サイトで /etc/ppp/peers/myisp.tmpl を使用するには、/etc/ppp/peers/myisp.tmpl の名前を /etc/ppp/peers/peer-name に変更します。peer-name は、呼び出されるピアの名前に置き換えます。次に、サイトの必要に応じてファイルの内容を変更します。
/etc/ppp/peers/peer-name の例 |
参照先 |
---|---|
ダイアルアウトマシン用 | |
専用回線上のローカルマシン用 | |
ダイアルアウトマシン上での PAP 認証サポート用 | |
ダイアルアウトマシン上での CHAP 認証サポート用 | |
クライアントシステムでの PPPoE サポート用 |
この節では、モデムの設定について説明します。
モデムの設定で重要なのは、モデムが動作する速度の指定です。Sun Microsystems のコンピュータで使用するモデムには、次のガイドラインを適用してください。
旧 SPARC システム – システムに添付されているハードウェアマニュアルを確認する。SPARCstationTM マシンの多くは、38400 bps を超えないモデム速度を要求する
UltraSPARCTM マシン – モデム速度を 115200 bps に設定する。これは、最新のモデムで使用でき、ダイアルアップリンクに十分な速度である。デュアルチャネル ISDN TA を圧縮して使用する場合は、モデム速度を上げる必要がある。UltraSPARC での最大値は非同期接続で 460800 bps
ダイアルアウトマシンでは、/etc/ppp/peers/peer-name などの PPP 構成ファイルでモデム速度を設定するか、あるいは pppd のオプションとして速度を指定します。
ダイアルインサーバーでは、ダイアルインサーバーにデバイスを構成する で説明したように、ttymon 機能または admintool を使って速度を設定する必要があります。
ダイアルアウトマシンとそのリモートピアは、さまざまな命令をネゴシエーションしたり交換したりして PPP リンク上で通信します。ダイアルアウトマシンを構成するときは、ローカルおよびリモートモデムから要求される命令の内容を判定する必要があります。次に、その命令を含む chat スクリプトと呼ばれるファイルを作成します。この節では、モデムの設定および chat スクリプトの作成について説明します。
ダイアルアウトマシンが接続する必要があるリモートピアは、通常、それぞれピア自身の chat スクリプトを必要とします。
chat スクリプトは、通常、ダイアルアップリンクだけで使用されます。専用回線リンクは、起動時の設定が必要な非同期インタフェースを使用しないかぎり、chat スクリプトを使用しません。
chat スクリプトの内容は、モデムまたは ISDN TA の要件、およびリモートピアの要件によって決まります。スクリプトの内容は、一連の送信予期文字列として表示されます。 ダイアルアウトマシンとリモートピアは、この文字列を通信の開始処理時に交換します。
予期文字列には、会話を開始するためにダイアルアウトホストマシンがリモートピアから受け取ると予想される文字が含まれます。送信文字列には、ダイアルアウトマシンが、予期文字列を受け取った後でリモートピアに送信する文字が含まれます。
chat スクリプト内の情報には、通常、以下が含まれます。
モデムコマンド 。しばしば AT コマンドと呼ばれる。モデムが電話を通じてデータを伝送することを可能にする
ターゲットピアの電話番号
この電話番号は、ISP または企業サイトのダイアルインサーバー、あるいは個別のマシンが要求する番号の場合がある
タイムアウト値 (必要な場合)
リモートピアからの予想されるログインシーケンス
ダイアルアウトマシンが送信するログインシーケンス
この節では、独自の chat スクリプトを作成する際の参考になる chat スクリプトの例を紹介します。モデムメーカーのガイドや ISP および他のターゲットホストからの情報には、モデムおよびターゲットピアの chat の要件が含まれています。また、数多くの PPP Web サイトで chat スクリプトのサンプルが提供されています。
以下は、独自の chat スクリプトを作成するためのテンプレートとして使用できる基本の chat スクリプトです。
ABORT BUSY ABORT 'NO CARRIER' REPORT CONNECT TIMEOUT 10 "" AT&F1M0&M5S2=255 SAY "Calling myserver\n" TIMEOUT 60 OK "ATDT1-123-555-1212" ogin: pppuser ssword: \q\U % pppd |
スクリプトの内容 |
説明 |
---|---|
ABORT BUSY |
モデムが反対側のピアからこのメッセージを受け取った場合、伝送を中止する |
ABORT 'NO CARRIER' |
ダイアル時にモデムが 'NO CARRIER' を報告した場合、伝送を中止する。 このメッセージは、通常、ダイアルまたはモデムのネゴシエーションが失敗したときに発生する |
REPORT CONNECT |
CONNECT 文字列をモデムから収集し、その文字列を出力する |
TIMEOUT 10 |
初期タイムアウトを 10 秒に設定する。モデムは即時に応答する必要がある |
"" AT&F1M0&M5S2=255 |
M0 – 接続中、スピーカーをオフに設定する &M5 – モデムにエラー制御を要求させる S2=255 – TIES "+++" ブレークシーケンスを無効にする |
SAY "Calling myserver\n" |
ローカルマシン上に「Calling myserver (myserver を呼び出し中)」のメッセージを表示する |
TIMEOUT 60 |
タイムアウトを 60 秒にリセットし、接続ネゴシエーションにより多くの時間を割り当てる |
OK "ATDT1-123-555-1212" |
電話番号 1-123-555-1212 を使ってリモートピアに発信する |
ogin: pppuser |
UNIX 方式のログインを使ってピアにログインする。ユーザー名 pppuser を指定 |
ssword: \q\U |
\q – –v オプションを使ってデバッグする場合、ログをとらない \U – –U の後に続く文字列の内容を挿入する。文字列はコマンド行に指定されるもので、通常はパスワードが含まれる |
% pppd |
% シェルプロンプトを待ち、pppd コマンドを実行する |
Solaris PPP 4.0 には、ユーザーが自分のサイトで使用するために変更できる /etc/ppp/myisp-chat.tmpl という chat スクリプトテンプレートが用意されています。/etc/ppp/myisp-chat.tmpl は、基本のモデム chat スクリプトと似ていますが、ログインシーケンスが含まれていません。
ABORT BUSY ABORT 'NO CARRIER' REPORT CONNECT TIMEOUT 10 "" "AT&F1" OK "AT&C1&D2" SAY "Calling myisp\n" TIMEOUT 60 OK "ATDT1-123-555-1212" CONNECT \c |
スクリプトの内容 |
意味 |
---|---|
ABORT BUSY |
モデムが反対側のピアからこのメッセージを受け取った場合、伝送を中止する |
ABORT 'NO CARRIER |
ダイアル時にモデムが 'NO CARRIER' を報告した場合、伝送を中止する。このメッセージは、通常、ダイアルまたはモデムのネゴシエーションが失敗したときに発生する |
REPORT CONNECT |
CONNECT 文字列をモデムから収集し、その文字列を出力する |
TIMEOUT 10 |
初期タイムアウトを 10 秒に設定する。 モデムは即時に応答する必要がある |
"" "AT&F1" |
モデムを出荷時のデフォルトにリセット |
OK "AT&C1&D2" |
モデムをリセットする。その結果、&C1 では、モデムからの DCD がキャリアを追跡する。リモート側がなんらかの理由で電話を切った場合、DCD はドロップする &D2 では、DTR の High-Low 遷移により、モデムが「オンフック」状態になる、またはハングアップする |
SAY "Calling myisp\n" |
ローカルマシン上に「Calling myisp (myisp を呼び出し中)」のメッセージを表示する |
TIMEOUT 60 |
タイムアウトを 60 秒にリセットし、接続ネゴシエーションにより多くの時間を割り当てる |
OK "ATDT1-123-555-1212" |
電話番号 1-123-555-1212 を使ってリモートピアに発信する |
CONNECT \c |
反対側のピアのモデムからの CONNECT メッセージを待つ |
ダイアルアウトマシンから U.S. Robotics Courier モデムを使用して ISP を呼び出すには、テンプレートとして次の chat スクリプトを使用します。
ABORT BUSY ABORT 'NO CARRIER' REPORT CONNECT TIMEOUT 10 "" AT&F1M0&M5S2=255 SAY "Calling myisp\n" TIMEOUT 60 OK "ATDT1-123-555-1212" CONNECT \c \r \d\c SAY "Connected; running PPP\n" |
次の表では、chat スクリプトの内容を説明します。
スクリプトの内容 |
説明 |
---|---|
ABORT BUSY |
モデムが反対側のピアからこのメッセージを受け取った場合、伝送を中止する |
ABORT 'NO CARRIER' |
モデムが反対側のピアからこのメッセージを受け取った場合、伝送を中止する |
REPORT CONNECT |
CONNECT 文字列をモデムから収集し、その文字列を出力する |
TIMEOUT 10 |
初期タイムアウトを 10 秒に設定する。モデムは即時に応答する必要がある |
"" AT&F1M0M0M0M0&M5S2=255 |
M0 – 接続中、スピーカーをオフに設定する &M5 – モデムにエラー制御を要求させる S2=255 – TIES "+++" ブレークシーケンスを無効にする |
SAY "Calling myisp\n" |
ローカルマシン上に「Calling myisp (myisp を呼び出し中)」のメッセージを表示する |
TIMEOUT 60 |
タイムアウトを 60 秒にリセットし、接続ネゴシエーションにより多くの時間を割り当てる |
OK "ATDT1-123-555-1212" |
電話番号 1-123-555-1212 を使ってリモートピアに発信する |
CONNECT \c |
反対側のピアのモデムからの CONNECT メッセージを待つ |
\r \d\c |
CONNECT メッセージの最後まで待つ |
SAY “Connected; running PPP\n” |
「Connected; running PPP (接続完了。PPP を実行中)」という通知メッセージをローカルマシン上に表示する |
次の chat スクリプトは、Solaris のリモートピアまたは他の UNIX タイプのピアを呼び出すために基本のスクリプトを拡張したものです。この chat スクリプトは、ピアを呼び出すための命令群を作成する方法で使用されています。
SAY "Calling the peer\n" TIMEOUT 10 ABORT BUSY ABORT 'NO CARRIER' ABORT ERROR REPORT CONNECT "" AT&F1&M5S2=255 TIMEOUT 60 OK ATDT1-123-555-1234 CONNECT \c SAY "Connected; logging in.\n" TIMEOUT 5 ogin:--ogin: pppuser TIMEOUT 20 ABORT 'ogin incorrect' ssword: \qmypassword "% " \c SAY "Logged in. Starting PPP on peer system.\n" ABORT 'not found' "" "exec pppd" ~ \c |
スクリプトの内容 |
説明 |
---|---|
TIMEOUT 10 |
初期タイムアウトを 10 秒に設定する。モデムは即時に応答する必要がある |
ABORT BUSY |
モデムが反対側のピアからこのメッセージを受け取った場合、伝送を中止する |
ABORT 'NO CARRIER' |
モデムが反対側のピアからこのメッセージを受け取った場合、伝送を中止する |
ABORT ERROR |
モデムが反対側のピアからこのメッセージを受け取った場合、伝送を中止する |
REPORT CONNECT |
CONNECT 文字列をモデムから収集し、その文字列を出力する |
"" AT&F1&M5S2=255 |
&M5 – モデムにエラー制御を要求させる S2=255 – TIES "+++" ブレークシーケンスを無効にする |
TIMEOUT 60 |
タイムアウトを 60 秒にリセットし、接続ネゴシエーションにより多くの時間を割り当てる |
OK ATDT1-123-555-1234 |
電話番号 1-123-555-1212 を使ってリモートピアに発信する |
CONNECT \c |
反対側のピアのモデムからの CONNECT メッセージを待つ |
SAY "Connected; logging in.\n" |
「Connected; logging in (接続完了。ログイン中)」という通知メッセージを表示して、ユーザーの状態を知らせる |
TIMEOUT 5 |
タイムアウトを変更し、ログインプロンプトを迅速に表示できるようにする |
ogin:--ogin: pppuser |
ログインプロンプトを待つ。ログインプロンプトを受け取らなかった場合は、RETURN を送信して待機する。次にユーザー名 pppuser をピアに送信する。この後に続くシーケンスは、ほとんどの ISP から PAP ログインと呼ばれている。ただし、PAP 認証とはまったく無関係である |
TIMEOUT 20 |
タイムアウトを 20 秒に変更し、パスワードの検証により多くの時間をかけられるようにする |
ssword: \qmysecrethere |
ピアからのパスワードプロンプトを待つ。プロンプトを受け取ると、パスワード \qmysecrethere を送信する。\q は、パスワードがシステムログファイルに書き込まれるのを防ぐ |
"% " \c |
ピアからのシェルプロンプトを待つ。 chat スクリプトは C シェルを使用する。ユーザーが異なるシェルを使ってログインすることを希望する場合は、この値を変更する |
SAY "Logged in. Starting PPP on peer system.\n" |
「Logged in. Starting PPP on peer system (ログイン完了。ピアシステム上で PPP を開始中)」という通知メッセージを表示して、ユーザーの状態を知らせる |
ABORT 'not found' |
シェルがエラーに遭遇した場合、伝送を中止する |
"" "exec pppd" |
ピア上で pppd を起動する |
~ \c |
PPP がピア上で開始するのを待つ |
ISP は、CONNECT \c の直後に PPP を開始することをしばしば「PAP ログイン」といいます。しかし、実際には、PAP ログインは PAP 認証とは無関係です。
ogin:--ogin: pppuser 句は、ダイアルインサーバーからのログインプロンプトに対してユーザー名 pppuser を送信するようにモデムに指示します。pppuser は、ダイアルインサーバー上のリモートユーザー user1 用に作成された専用の PPP ユーザーアカウント名です。ダイアルインサーバー上に PPP ユーザーアカウントを作成する方法については、ダイアルインサーバーのユーザーを構成する方法を参照してください。
次は、ダイアルアウトマシンから ZyXEL omni.net ISDN TA を使って呼び出すための chat スクリプトです。
SAY "Calling the peer\n" TIMEOUT 10 ABORT BUSY ABORT 'NO CARRIER' ABORT ERROR REPORT CONNECT "" AT&FB40S83.7=1&K44&J3X7S61.3=1S0=0S2=255 OK ATDI18882638234 CONNECT \c \r \d\c SAY "Connected; running PPP\n" |
次の表では、chat スクリプトのパラメータを説明します。
スクリプトの内容 |
説明 |
---|---|
SAY "Calling the peer" |
ダイアルアウトマシンの画面上にこのメッセージを表示する |
TIMEOUT 10 |
初期タイムアウトを 10 秒に設定する |
ABORT BUSY |
モデムが反対側のピアからこのメッセージを受け取った場合、伝送を中止する |
ABORT 'NO CARRIER' |
モデムが反対側のピアからこのメッセージを受け取った場合、伝送を中止する |
ABORT ERROR |
モデムが反対側のピアからこのメッセージを受け取った場合、伝送を中止する |
REPORT CONNECT |
CONNECT 文字列をモデムから収集し、その文字列を出力する |
"" AT&FB40S83.7= 1&K44&J3X7S61.3=1 S0=0S2=255 |
|
OK ATDI18882638234 |
ISDN 呼び出しを行う。マルチリンクでは、2 番目の呼び出しは、同じ電話番号に対して行われる。これは、通常、ほとんどの ISP の条件である。リモートピアが 2 番目の電話番号に異なる番号を要求す る場合は、「+ nnnn」を付け加える。nnnn は 2 番目の電話番号を表す |
CONNECT \c | |
\r \d\c |
CONNECT メッセージの最後まで待つ |
SAY "Connected; running PPP\n" |
ダイアルアウトマシンの画面上にこのメッセージを表示する |
chat スクリプトのオプションの説明およびその他の詳細な情報については、chat(1M) のマニュアルページを参照してください。送信予期文字列の説明については、UUCP Chat-Script フィールドを参照してください。
数多くの Web サイトで、chat スクリプトのサンプルとスクリプト作成のヒントが提供されています。
オーストラリア国立大学の Web サイトから利用できる PPP FAQ (Frequently Asked Questions) のページ (URL) も参考になります。
chat スクリプトを呼び出すには、connect オプションを使用します。PPP 構成ファイルまたはコマンド行で connect "chat ..." を使用できます。
chat スクリプトは実行可能ではありませんが、connect によって呼び出されるプログラムは実行可能でなければなりません。connect によって呼び出されるプログラムに chat ユーティリティを使用することがあります。この場合、–f オプションを使用して chat スクリプトを外部ファイルに保存すると、chat スクリプトファイルは実行可能にはなりません。
chat(1m) で説明されている chat プログラムは、実際の chat スクリプトを実行します。pppd デーモンは、pppd が connect "chat ..." オプションに遭遇すると必ず、chat プログラムを起動します。
Perl や Tcl などの外部プログラムを使って機能を拡張した chat スクリプトを作成することもできます。Solaris PPP 4.0 で chat ユーティリティが提供されているのは、ユーザーの便宜を図るためです。
ASCII ファイル形式で chat スクリプトを作成します。
次の構文を使用して、任意の PPP 構成ファイル内で chat スクリプトを呼び出します。
connect 'chat -f /etc/ppp/chatfile' |
-f フラグは、ファイル名が後に続くことを示します。/etc/ppp/chatfile は、chat ファイルの名前を表します。
外部 chat ファイルの読み取り権を pppd コマンドを実行するユーザーに与えます。
connect 'chat ...' オプションが特権ソースから呼び出された場合でも、chat プログラムは、常にユーザーの権限と連携して実行します。従って、-f オプションを使って読み取る個別の chat ファイルは、それを呼び出すユーザーが読み取り権を持っている必要があります。chat スクリプトにパスワードやその他の機密情報が含まれる場合、この特権はセキュリティの問題にかかわる可能性があります。
特定のピアで必要な chat スクリプトが長くて複雑な場合は、スクリプトを別ファイルとして作成することを考えます。外部 chat ファイルは、簡単に維持、作成できます。ハッシュ記号 (#) の後に続けて chat ファイルについてのコメントを追加できます。
外部ファイルに含まれる chat スクリプトの使用については、ピアを呼び出すための命令群を作成する方法 の手順を参照してください。
次に示すように、chat スクリプトの全会話を 1 つの行に入れることができます。
connect 'chat "" "AT&F1" OK ATDT5551212 CONNECT "\c"' |
実行可能なスクリプトの chat ファイルを作成して、ダイアルアップリンクが開始されたときに自動的に実行されるようにできます。これにより、接続開始時に、従来の chat スクリプトに含まれるコマンドのほかに、パリティー設定のための stty のような追加コマンドを実行できます。
この実行可能な chat スクリプトは、7 ビット長/ 偶数パリティーを要求する旧スタイルの UNIX システムにログインし、PPP 実行時に 8 ビット長/ パリティーなしに移行します。
#!/bin/sh chat "" "AT&F1" OK "ATDT555-1212" CONNECT "\c" stty evenp chat ogin: pppuser ssword: "\q\U" % "exec pppd" stty -evenp |
テキストエディタを使用して、前述の例のような実行可能な chat プログラムを作成します。
chat プログラムを実行可能にします。
# chmod +x /etc/ppp/chatprogram |
chat プログラムを呼び出します。
connect /etc/ppp/chatprogram |
chat プログラムの場所は、/etc/ppp ファイルシステム内である必要はありません。chat プログラムは任意の場所に保存できます。
この節では、PPP 認証プロトコルの動作と認証プロトコルに関連するデータベースについて説明します。
PAP 認証は、UNIX の login プログラムと動作が多少似ていますが、PAP はユーザーにシェルアクセスを許可しない点が異なります。PAP は、PPP 構成ファイルと /etc/ppp/pap-secrets ファイルの形式の PAP データベースを使って認証を設定します。また、PAP セキュリティ資格の定義にも /etc/ppp/pap-secrets を使用します。この資格には、ピア名 (PAP の用語では 「ユーザー名」)とパスワードが含まれます。また、ローカルマシンへの接続を許可されている呼び出し元に関する情報も含まれます。PAP のユーザー名とパスワードは、パスワードデータベース内の UNIX ユーザー名およびパスワードと同じものにすることも、違うものにすることもできます。
PAP データベースは、/etc/ppp/pap-secrets ファイルに実装されています。 認証が成功するためには、PPP リンクの両側にある各マシンで、/etc/ppp/pap-secrets ファイル内に適切に設定された PAP 資格が必要です。 呼び出し元 (認証される側) は、/etc/ppp/pap-secrets ファイルまたは旧バージョンの +ua ファイルの user 列および password 列で資格を提供します。サーバー (認証する側) は、UNIX の passwd データベースまたは PAM 機能により /etc/ppp/pap-secrets 内の情報と対照してこの資格の妥当性を検証します。
/etc/ppp/pap-secrets ファイルの構文は、次のとおりです。
表 32–5 /etc/ppp/pap-secrets の構文
呼び出し元 |
サーバー |
パスワード |
IP アドレス |
---|---|---|---|
myclient |
ISP-server |
mypassword |
* |
パラメータの意味は次のとおりです。
呼び出し元の PAP ユーザー名。 この名前は、呼び出し元の UNIX ユーザー名と同じ場合がある。特に、ダイアルインサーバーが PAP の login オプションを使用する場合は、同じ場合が多い
リモートマシンの名前。ダイアルインサーバーである場合がしばしばある
呼び出し元の PAP パスワード
呼び出し元に関連付けられている IP アドレス。 任意の IP アドレスを表すには、アスタリスク (*) を使用する
PAP パスワードは、接続上をクリアテキストで (読み取り可能な ASCII 形式で) 送信されます。呼び出し元 (認証される側) では、PAP パスワードを次のどこかにクリアテキストで格納する必要があります。
/etc/ppp/pap-secrets ファイル内
別の外部ファイル内
pap-secrets @ 機能による名前付きパイプ内
pppd のオプションとして、コマンド行上または PPP 構成ファイル内のどちらか
+ua ファイルを介して
サーバー (認証する側) では、PAP パスワードは、次のどれかの方法で隠すことができます。
pap-secrets ファイル内で papcrypt を指定し、crypt(3C) によってハッシュ化されたパスワードを使用する
pppd に login オプションを指定し、パスワード列に二重引用符 ("") を入れることにより pap-secrets ファイルからパスワードを除外する。この場合、認証は UNIX の passwd データベースまたは pam(3PAM) メカニズムを利用して行われる。
呼び出し元 (認証される側) がリモートピア (認証する側) を呼び出し、接続ネゴシエーションの一環として PAP ユーザー名とパスワードを伝えます。
ピアは、/etc/ppp/pap-secrets ファイルで呼び出し元の識別情報を検証します。PAP の login オプションを使用する場合は、呼び出し元のユーザー名とパスワードの検証にパスワードデータベースが使用されます。
認証が成功すると、ピアは呼び出し元との接続ネゴシエーションを継続します。認証に失敗すると、接続は切られます。
(オプション) 呼び出し元がリモートピアからの応答を認証する場合は、リモートピアが自身の PAP 資格を呼び出し元に送信する必要があります。したがって、リモートピアは認証される側になり、呼び出し側は認証する側になります。
(オプション) 最初の呼び出し元が自身の /etc/ppp/pap-secrets を読み取り、リモートピアの識別情報を検証します。
最初の呼び出し元がリモートピアに認証資格を要求する場合は、手順 1 と手順 4 が並行して行われます。
ピアが認証されると、ネゴシエーションが継続されます。認証されない場合は、接続が切られます。
呼び出し元とピアのネゴシエーションは、接続の確立に成功するまで継続されます。
PAP 資格を認証するための login オプションを PPP 構成ファイルに追加できます。たとえば /etc/ppp/options で login を指定した場合、pppd は呼び出し元の PAP 資格が Solaris のパスワードデータベース内に存在するかどうかを検証します。次の表に、login オプションを追加した /etc/ppp/pap-secrets ファイルの形式を示します。
表 32–6 login オプションを追加した /etc/ppp/pap-secrets
呼び出し元 |
サーバー |
パスワード |
IP アドレス |
---|---|---|---|
joe |
* |
“ “ |
* |
sally |
* |
“ “ |
* |
sue |
* |
“ “ |
* |
パラメータの意味は次のとおりです。
すべての承認された呼び出し元の名前
アスタリスクは、任意のサーバー名が有効であることを示す。 name オプションは PPP 構成ファイルでは必須ではない
二重引用符は、任意のパスワードが有効であることを示す。
この列にパスワードがある場合、ピアからのパスワードは、PAP パスワードと UNIX passwd データベースの両方に一致しなければならない
アスタリスクは、任意の IP アドレスが許可されることを示す。
CHAP 認証は、チャレンジと応答という概念を使用します。つまり、ピア (認証する側) は識別情報を証明するために呼び出し元 (認証される側) にチャレンジします。チャレンジには、乱数、および認証する側によって生成された一意の ID が含まれます。呼び出し元は、ID、乱数、および呼び出し元の CHAP セキュリティ資格を使って適切な応答 (ハンドシェーク) を生成しピアに送信します。
CHAP セキュリティ資格には、CHAP ユーザー名と CHAP「シークレット」が含まれます。チャップシークレットは、PPP リンクネゴシエーションを行う前に、あらかじめ呼び出し元とピアの両方が知っている任意の文字列です。CHAP セキュリティ資格は、CHAP データベース /etc/ppp/chap-secrets 内で設定します。
CHAP データベースは、/etc/ppp/chap-secrets ファイルに実装されています。 認証が成功するためには、PPP リンクの両側にある各マシンで、/etc/ppp/chap-secrets ファイル内に互いのマシンの CHAP 資格が必要です。
PAP と異なり、共有シークレットは、両方のピアでクリアテキストでなければなりません。CHAP では、crypt、PAM、または PPP ログインオプションは使用できません。
/etc/ppp/chap-secrets ファイルの構文は、次のとおりです。
表 32–7 /etc/ppp/chap-secrets の構文
呼び出し元 |
サーバー |
CHAP シークレット |
IP アドレス |
---|---|---|---|
myclient |
myserver |
secret5748 |
* |
パラメータの意味は次のとおりです。
呼び出し元の CHAP ユーザー名。 呼び出し元の UNIX ユーザー名と同じ名前にすることも、違う名前にすることもできる
リモートマシンの名前。ダイアルインサーバーである場合がしばしばある
呼び出し元の CHAP シークレット
PAP パスワードと異なり、CHAP シークレットは送信されない。CHAP シークレットは、ローカルマシンが応答を処理するときに使用される
呼び出し元に関連付けられている IP アドレス。 任意の IP アドレスを表すには、アスタリスク (*) を使用する
通信を開始しようとする 2 つのピアが、PPP リンクのネゴシエーション時に認証に使用するシークレットについて合意します。
両方のマシンの管理者が、シークレット、CHAP ユーザー名、その他の CHAP 資格をそれぞれのマシンの /etc/ppp/chap-secrets データベースに追加します。
呼び出し元 (認証される側) がリモートピア (認証する側) を呼び出します。
認証する側が乱数と ID を生成し、それらを認証される側にチャレンジとして送信します。
認証される側は、/etc/ppp/chap-secrets データベース内でピアの名前とシークレットを調べます。
認証される側は、シークレットとピアの乱数チャレンジに MD5 計算アルゴリズムを適用することにより、応答を計算します。次に、認証される側は、認証する側に結果を応答として送信します。
認証する側は、/etc/ppp/chap-secrets データベース内で認証される側の名前とシークレットを調べます。
認証する側は、チャレンジとして生成された数値と /etc/ppp/chap-secrets 内の認証される側のシークレットに MD5 を適用することにより、自身の数値を計算します。
認証する側は、呼び出し元からの応答と結果を比較します。2 つの数字が同じ場合、ピアは、呼び出し元の認証に成功し、接続ネゴシエーションが続けられます。認証されない場合は、接続が切られます。
リモートユーザーごとに一意の IP アドレスを割り当てる代わりに、すべての着呼のために 1 つ以上の IP アドレスを作成することを考えます。専用 IP アドレスは、予想される呼び出し元の数が、ダイアルインサーバー上のシリアルポートとモデムの数を上回る場合、特に重要です。サイトの必要性に応じて、さまざまなシナリオを実現できます。さらに、シナリオは、相互に排他的ではありません。
動的アドレス指定は、/etc/ppp/options.ttyname で定義されている IP アドレスを各呼び出し元に割り当てます。動的アドレス指定は、シリアルポート単位で発生します。シリアル回線に呼が着信すると、呼び出しを処理するシリアルインタフェース用に /etc/ppp/options. ttyname ファイルで定義されている IP アドレスが呼び出し元に与えられます。
たとえば、ダイアルインサーバーに、着呼に対してダイアルアップサービスを提供するシリアルインタフェースが 4 つあると仮定します。
シリアルポート term/a 用に、次のエントリがある /etc/ppp/options.term.a ファイルを作成します。
:10.1.1.1 |
シリアルポート term/b 用に、次のエントリがある /etc/ppp/options.term.b ファイルを作成します。
:10.1.1.2 |
シリアルポート term/c 用に、次のエントリがある /etc/ppp/options.term.c ファイルを作成します。
:10.1.1.3 |
シリアルポート term/d 用に、次のエントリがある /etc/ppp/options.term.d ファイルを作成します。
:10.1.1.4 |
PPP ネットワークの使用状況をシリアルポートまで追跡できる
PPP 使用で割り当てる IP アドレスの数を最小限にできる
IP フィルタリングをより簡単に管理できる
サイトが PPP 認証を実装する場合は、個々の呼び出し元に特定の静的 IP アドレスを割り当てることができます。この場合、ダイアルアウトマシンがダイアルインサーバーを呼び出すたびに、呼び出し元は同じ IP アドレスを受け取ります。
静的アドレスは、pap-secrets または chap-secrets のどちらかのデータベースで実装します。以下は、静的 IP アドレスを定義した /etc/ppp/pap-secrets ファイルの例です。
呼び出し元 |
サーバー |
パスワード |
IP アドレス |
---|---|---|---|
joe |
myserver |
joepasswd |
10.10.111.240 |
sally |
myserver |
sallypasswd |
10.10.111.241 |
sue |
myserver |
suepasswd |
10.10.111.242 |
以下は、静的 IP アドレスを定義した /etc/ppp/chap-secrets ファイルの例です。
呼び出し元 |
サーバー |
CHAP シークレット |
IP アドレス |
---|---|---|---|
account1 |
myserver |
secret5748 |
10.10.111.244 |
account2 |
myserver |
secret91011 |
10.10.111.245 |
PAP 認証または CHAP 認証を使用している場合は、sppp ユニット番号を使って IP アドレスを呼び出し元に割り当てることができます。次の表に、この方法の例を示します。
呼び出し元 |
サーバー |
パスワード |
IP アドレス |
---|---|---|---|
myclient |
ISP-server |
mypassword |
10.10.111.240/28+ |
正符号 (+) は、ユニット番号が IP アドレスに追加されていることを示します。アドレス 10.10.111.240 から 10.10.111.255 までがリモートユーザーに割り当てられます。sppp0 は IP アドレス 10.10.111.240 を取得します。sppp1 は IP アドレス 10.10.111.241 を取得し、以下同様に続きます。
PPPoE を使用することにより、1 台以上の DSL モデムを使用している複数のクライアントに PPP 超高速デジタルサービスを提供できます。PPPoE は、3 つの関係者、つまり企業、電話会社、サービスプロバイダを通して Ethernet トンネルを作成することにより、このサービスを実現します。
PPPoE の動作の概要と説明については、PPPoE の概要 を参照してください。
PPPoE トンネルの設定作業については、第 30 章「PPPoE トンネルの設定 (手順)」を参照してください。
この節では、PPPoE コマンドおよびファイルについて詳しく説明します。概要を次の表に示します。
表 32–8 PPPoE のコマンドと構成ファイル
ファイルまたはコマンド |
説明 |
参照先 |
---|---|---|
/etc/ppp/pppoe |
PPPoE がシステムに設定したすべてのトンネルに対してデフォルトで適用される特性を含むファイル | |
/etc/ppp/pppoe. device |
PPPoE がトンネルに使用する特定のインタフェースの特性を含むファイル | |
/etc/ppp/pppoe.if |
PPPoE が設定したトンネルが動作する Ethernet インタフェースをリストしたファイル | |
/usr/sbin/sppptun |
PPPoE トンネルに関係する Ethernet インタフェースを設定するためのコマンド | |
/usr/lib/inet/pppoed |
PPPoE を使ってトンネルを設定するためのコマンドとオプション |
PPPoE トンネルの両端で使用されるインタフェースは、トンネルが PPP 通信をサポートする前に、あらかじめ設定しておく必要があります。設定には、/usr/sbin/sppptun および /etc/ppp/pppoe.if ファイルを使用します。これらのツールを使用して、すべての Solaris PPPoE クライアントおよび PPPoE アクセスサーバー上の Ethernet インタフェースを設定する必要があります。
/etc/ppp/pppoe.if ファイルは、ホスト上の PPPoE トンネルで使用されるすべての Ethernet インタフェースの名前をリストします。このファイルはシステムの起動時に処理され、ファイルにリストされているインタフェースは PPPoE トンネルで使用するために plumb されます。
/etc/ppp/pppoe.if は明示的に作成する必要があります。各行ごとにインタフェース名を 1 つずつ入力して PPPoE 用に設定します。
次に、PPPoE トンネルに 3 つのインタフェースを提供するサーバーの /etc/ppp/pppoe.if ファイルの例を示します。
# cat /etc/ppp/pppoe.if hme1 hme2 hme3 |
PPPoE クライアントは通常、/etc/ppp/pppoe.if にリストされているインタフェースを 1 つだけ使用します。
/usr/sbin/sppptun コマンドを使用すると、PPPoE トンネルで使用する Ethernet インタフェースを手動で plumb したり unplumb したりできます。これに対して、/etc/ppp/pppoe.if はシステムの起動時だけ読み取られます。これらのインタフェースは、/etc/ppp/pppoe.if にリストされているインタフェースと一致する必要があります。
sppptun は、PPPoE トンネルで使用する Ethernet インタフェースを ifconfig コマンドと同様の方法で plumb します。ifconfig とは異なり、2 つの Ethernet プロトコル番号が必要なため、PPPoE をサポートするにはインタフェースを 2 回 plumb する必要があります。
sppptun の基本的な構文を次に示します。
# /usr/sbin/sppptun plumb pppoed device-name device-name:pppoed # /usr/sbin/sppptun plumb pppoe device-name device-name:pppoe |
上の 1 つめの sppptun コマンドを実行したときは、発見プロトコル pppoed がインタフェースに plumb されます。2 つめの sppptun を実行したときは、セッションプロトコル pppoe が plumb されます。sppptun は、plumb されたインタフェースの名前を表示します。必要な場合は、この名前を使ってインタフェースを unplumb します。
詳細は、sppptun(1M) のマニュアルページを参照してください。
次の例は、/usr/sbin/sppptun を使用して PPPoE のインタフェースを手動で plumb します。
# /usr/sbin/sppptun plumb pppoed hme0 hme0:pppoed # /dev/sppptun plumb pppoe hme0 hme0:pppoe |
次の例は、PPPoE に plumb されたアクセスサーバー上のインタフェースを表示します。
/usr/sbin/sppptun query hme0:pppoe hme0:pppoed hme1:pppoe hme1:pppoed hme2:pppoe hme2:pppoed |
# sppptun unplumb hme0:pppoed # sppptun unplumb hme0:pppoe |
DSL のサービスまたはサポートを顧客に提供するサービスプロバイダは、Solaris PPPoE を実行するアクセスサーバーを使用できます。PPPoE アクセスサーバーとクライアントは、従来のクライアントとサーバーの関係で機能します。この関係は、ダイアルアップリンクでのダイアルアウトマシンとダイアルインサーバーの関係に似ています。つまり、ある PPPoE システムが通信を開始し、別の PPPoE システムが応答します。これに対して、PPP プロトコルにはクライアントとサーバーの関係という概念はなく、両方のマシンが同等のピアとみなされます。
PPPoE アクセスサーバーを設定するコマンドおよびファイルには、以下が含まれます。
pppoed デーモンは、将来の PPPoE クライアントからブロードキャストを受け取ります。さらに、pppoed は PPPoE トンネルのサーバー側とネゴシエーションし、PPP デーモン pppd をそのトンネル上で実行します。
pppoed サービスは、/etc/ppp/pppoe および /etc/ppp/pppoe.device ファイルで設定します。システム起動時に /etc/ppp/pppoe が存在する場合は、pppoed が自動的に実行します。コマンド行で /usr/lib/inet/pppoed と入力することにより、pppoed デーモンを明示的に実行することもできます。
/etc/ppp/pppoe ファイルは、アクセスサーバーが提供するサービスと、PPP が PPPoE トンネル上でどのように実行するかを定義するオプションを説明します。 インタフェースごとに個別にサービスを定義することも、広域的にアクセスサーバー上のすべてのインタフェースに対してサービスを定義することもできます。アクセスサーバーは、将来の PPPoE クライアントからのブロードキャストに応答して、/etc/ppp/pppoe ファイル内の情報を送信します。
以下に、/etc/ppp/pppoe の基本的な構文を示します。
global-options service service-name service-specific-options device interface-name |
/etc/ppp/pppoe ファイルのデフォルトのオプションを設定する。このオプションには、pppoed または pppd で使用可能なオプションはすべて使用できる。オプションの完全なリストについては、pppoed(1M) および pppd(1M) のマニュアルページを参照
たとえば、グローバルオプションには、PPPoE トンネルで使用できる Ethernet インタフェースをリストする必要がある。/etc/ppp/pppoe でデバイスを定義しないと、インタフェースでサービスを提供できない
devices をグローバルオプションとして定義するには、次の形式を使用する
device interface <,interface> |
service-name というサービスの定義を開始する。service-name には、提供されるサービスに適した任意の文字列を指定できる
このサービスに固有の PPPoE および PPP のオプションを表示する
上記でリストしたサービスを利用できるインタフェースを指定する
/etc/ppp/pppoe のこの他のオプションについては、pppoed(1M) および pppd(1M) のマニュアルページを参照してください。
次に、典型的な /etc/ppp/pppoe ファイルの例を示します。
device hme1,hme2,hme3 service internet pppd "name internet-server" service intranet pppd "192.168.1.1:" service debug device hme1 pppd "debug name internet-server" |
このファイルでは、以下の値が適用されています。
PPPoE トンネルに使用されるアクセスサーバー上の 3 つのインタフェース
将来のクライアントに対して internet というサービスを通知する。また、サービスを提供するプロバイダは internet の定義についても決定する。たとえば、プロバイダは、インターネットへのアクセスだけでなく、さまざまな IP サービスを意味する internet サービスを提供できる
呼び出し元が pppd を呼び出したときに使用されるコマンド行オプションを設定する。 "name internet-server" オプションは、ローカルマシン (アクセスサーバー) の名前を internet-server と付ける
intranet という別のサービスを想定クライアントに通知する
呼び出し元が pppd を呼び出したときに使用されるコマンド行オプションを設定する。 呼び出し元が pppd を呼び出すと、ローカルマシン (アクセスサーバー) の IP アドレスとして 192.168.1.1 が設定される
PPPoE 用に定義されているインタフェースに 3 番目のサービス、デバッグを通知する
PPPoE トンネルに対するデバッグを hme1 に限定する
呼び出し元が pppd を起動したときに使用されるコマンド行オプション、この場合は PPP デバッグをローカルマシン internet-server に設定する
/etc/ppp/pppoe.device ファイルは、PPPoE アクセスサーバーの インタフェース上で提供されるサービスと、PPP が PPPoE トンネル上でどのように実行するかを定義するオプションを説明します。/etc/ppp/pppoe.device はオプションのファイルで、グローバルの /etc/ppp/pppoe とまったく同様に動作します。ただし、/etc/ppp/pppoe.device がインタフェース用に定義されている場合、そのインタフェースでは、このファイルのパラメータが、/etc/ppp/pppoe で定義されているグローバルパラメータより優先されます。
以下に、/etc/ppp/pppoe.device の基本的な構文を示します。
service service-name service-specific-options service another-service-name service-specific-options |
上記の構文と /etc/ppp/pppoe の構文の違いは、/etc/ppp/pppoe ファイル で示した device オプションを使用できない点だけです。
pppoe.so は PPPoE 共有オブジェクトファイルで、PPPoE のアクセスサーバーおよびクライアントによって呼び出されます。 このファイルは、MTU および MRU を 1492 に制限し、ドライバからのパケットにフィルタをかけ、pppoed とともに PPPoE トンネルをネゴシエートします。 アクセスサーバー側では、pppoe.so は pppd デーモンによって自動的に呼び出されます。
ここでは、あるアクセスサーバーを構成するために使用するすべてのファイルのサンプルを紹介します。このアクセスサーバーはマルチホームで、3 つのサブネット、green、orange、および purple が接続されています。pppoed は、サーバー上で root として実行します。これはデフォルトの動作です。
PPPoE クライアントは、hme0 および hme1 インタフェースを通じて orange および purple ネットワークにアクセスできます。クライアントは、標準の UNIX ログインを使ってサーバーにログインします。サーバーは、クライアントを PAP を使って認証します。
green ネットワークは、クライアントに通知されません。クライアントが green にアクセスできるためには、直接「green-net」を指定し、CHAP 認証資格を提供しなければなりません。さらに、クライアント joe および mary だけが、静的 IP アドレスを使用して green ネットワークにアクセスできます。
service orange-net device hme0,hme1 pppd "require-pap login name orange-server orange-server:" service purple-net device hme0,hme1 pppd "require-pap login name purple-server purple-server:" service green-net device hme1 pppd "require-chap name green-server green-server:" nowildcard |
このサンプルは、アクセスサーバーから使用できるサービスを説明します。1 番目の service 節は、orange ネットワークのサービスを説明します。
service orange-net device hme0,hme1 pppd "require-pap login name orange-server orange-server:" |
purple ネットワーク用の service 節は、ネットワーク名とサーバー名が異なる以外は、orange ネットワーク用の service 節と同じです。
次の service 節は、green ネットワークのサービスを説明します。
service green-net device hme1 pppd "require-chap name green-server green-server:" nowildcard |
このアクセスサーバーのシナリオでは、次のような /etc/ppp/options ファイルを設定する場合があります。
auth proxyarp nodefaultroute name no-service # don't authenticate otherwise |
name no-service オプションは、通常、PAP または CHAP 認証時に検索されるサーバー名を無効にします。サーバーのデフォルト名は、/usr/bin/hostname に記述されています。前述の例の name オプションは、サーバー名を no-service に変更します。no-service は、pap または chap-secrets ファイルでは見つかりそうにない名前です。この処理により、任意のユーザーが pppd を実行したり、/etc/ppp/options で設定されている auth および name オプションを上書きするのを防ぐことができます。pppd は、no-service のサーバー名ではクライアントのシークレットを見つけることができないため、失敗します。
このアクセスサーバーのシナリオでは、次の /etc/hosts ファイルを使用します。
172.16.0.1 orange-server 172.17.0.1 purple-server 172.18.0.1 green-server 172.18.0.2 joes-pc 172.18.0.3 marys-pc |
次に、orange および purple ネットワークにアクセスしようとするクライアントの PAP 認証に使用する /etc/ppp/pap-secrets ファイルを示します。
* orange-server "" 172.16.0.2/16+ * purple-server "" 172.17.0.2/16+ |
次に、CHAP 認証に使用される /etc/ppp/chap-secrets ファイルを示します。joe および mary というクライアントだけがファイルにリストされていることに注意してください。
joe green-server "joe's secret" joes-pc mary green-server "mary's secret" marys-pc |
DSL モデム上で PPP を実行するには、マシンが PPPoE クライアントになる必要があります。PPPoE を実行するためにインタフェースを plumb し、次に pppoec ユーティリティを使ってアクセスサーバーの存在を「発見」する必要があります。その後、クライアントは DSL モデム上に PPPoE トンネルを作成し PPP を実行できます。
PPPoE クライアントは、従来のクライアント - サーバーモデルでアクセスサーバーに接続します。PPPoE トンネルはダイアルアップリンクではありませんが、ほぼ同じような方法で構成され、操作されます。
PPPoE クライアントを設定するコマンドおよびファイルには、以下が含まれます。
/usr/lib/inet/pppoec ユーティリティは、PPPoE トンネルのクライアント側をネゴシエーションします。 pppoec は、Solaris PPP 4.0 の chat ユーティリティに似て います。pppoec は直接起動しません。直接起動するのではなく、pppd の connect オプションの引数として /usr/lib/inet/pppoec を起動します。
pppoe.so は PPPoE 共有オブジェクトで、PPPoE によって読み込まれ、PPPoE 機能をアクセスサーバーとクライアントに提供します。 共有オブジェクト pppoe.so は、MTU および MRU を 1492 に制限し、ドライバからのパケットにフィルタをかけ、実行時 PPPoE メッセージを処理します。
クライアント側では、ユーザーが plugin pppoe.so オプションを指定すると、pppd が pppoe.so を読み込みます。
アクセスサーバーが pppoec によって発見されるように定義する場合は、 pppoec および pppd デーモンの両方に適用されるオプションを使用します。アクセスサーバーの /etc/ppp/peers/peer-name ファイルは次のパラメータを必要とします。
sppptun – PPPoE トンネルが使用するシリアルデバイスの名前
plugin pppoe.so – pppd に pppoe.so 共有オブジェクトを読み込むように指示する
connect "/usr/lib/inet/pppoec device" – 接続を開始する。次に、PPPoE にplumb されているインタフェース device 上で pppoec ユーティリティを起動する
/etc/ppp/peers/peer-name ファイル内の残りのパラメータは、サーバー上の PPP リンクに適用されます。ダイアルアウトマシン上の /etc/ppp/peers/peer-name と同じオプションを使用します。オプションの数を PPP リンクで必要な最小数に制限するようにしてください。
次の例は、PPPoE アクセスサーバーピアを定義する方法で紹介されています。
# vi /etc/ppp/peers/dslserve sppptun plugin pppoe.so connect "/usr/lib/inet/pppoec hme0" noccp noauth user Red password redsecret noipdefault defaultroute |
このファイルは、アクセスサーバー dslserve に PPPoE トンネルと PPP リンクを設定するときに使用するパラメータを定義します。オプションには、以下が含まれます。
オプション |
説明 |
---|---|
sppptun | |
plugin pppoe.so | |
connect "/usr/lib/inet/pppoec hme0" | |
noccp |
注 – 多くの ISP は独自の圧縮アルゴリズムだけを使用します。公開された CCP アルゴリズムをオフにすると、ネゴシエーションの時間を節約し、偶発的な相互運用性の問題を避けることができます。 |
noauth | |
user Red |
アクセスサーバーによる PAP 認証に必要なクライアントのユーザー名として Red の名前を設定する |
password redsecret |
PAP 認証のためにアクセスサーバーに提供されるパスワードとして redsecret を定義する |
noipdefault |
初期 IP アドレスとして 0.0.0.0 を割り当てる |
defaultroute |
IPCP ネゴシエーション後にデフォルトの IPv4 経路指定をインストールするよう pppd に指示する。接続がシステムのインターネットへの接続である場合、/etc/ppp/peers/peer-name 内に defaultroute を含める必要がある。PPPoE クライアントの場合これにあてはまる |
Solaris オペレーティングシステムの以前のバージョンでは、別の PPP 実装である非同期 Solaris PPP (asppp) が提供されていました。asppp を実行するピアを最新の PPP 4.0 に更新したい場合は、変換スクリプトを実行する必要があります。この章では、PPP 変換に関する次のトピックについて説明します。
この章では、サンプルの asppp 構成を使用して、PPP 変換を実施する方法について説明します。Solaris PPP 4.0 と asppp の相違点については、使用する Solaris PPP のバージョンを参照してください。
変換スクリプト /usr/sbin/asppp2pppd を使用して、標準 asppp 構成を構成する次のファイルを変換できます。
/etc/asppp.cf – 非同期 PPP 構成ファイル
/etc/uucp/Systems – リモートピアの特性を記述する UUCP ファイル
/etc/uucp/Devices – ローカルマシン上のモデムを記述する UUCP ファイル
/etc/uucp/Dialers – /etc/uucp/Devices ファイルに記述されているモデムが使用するログインシーケンスが含まれる UUCP ファイル
asppp については、http://docs.sun.com に掲載されている「Solaris 8 System Administrator Collection - Japanese」の『Solaris のシステム管理 (第 3 巻)』を参照してください。
asppp から Solaris PPP 4.0 に変換する方法に示す手順は、次の /etc/asppp.cf ファイルを使用します。
# ifconfig ipdptp0 plumb mojave gobi up path inactivity_timeout 120 # Approx. 2 minutes interface ipdptp0 peer_system_name Pgobi # The name we log in with (also in # /etc/uucp/Systems |
このファイルには次のパラメータが含まれています。
ifconfig コマンドを実行し、ローカルマシン mojave の PPP インタフェース ipdptp0 からリモートピア gobi へのリンクを確立する
2 分間アクティブでない回線を終了する
ダイアルアウトマシン上のインタフェース ipdptp0 を非同期 PPP に構成する
リモートピアの名前 Pgobi を指定する
asppp から Solaris PPP 4.0 に変換する方法に示す手順は、次の /etc/uucp/Systems ファイルを使用します。
#ident "@(#)Systems 1.5 92/07/14 SMI" /* from SVR4 bnu:Systems 2.4 */ # # . # . Pgobi Any ACU 38400 15551212 in:--in: mojave word: sand |
このファイルには次のパラメータが含まれています。
Pgobi をリモートピアのホスト名として使用する
ダイアルアウトマシン mojave 上のモデムが、任意の時点で Pgobi 上のモデムとリンクを確立するようにする。Any ACU は「/etc/uucp/Devices ファイル内で ACU を探す」ことを意味する
リンクの最大速度として 38400 を設定する
Pgobi の電話番号を指定する
Pgobi が必要とするログインスクリプトを定義して、ダイアルアウトマシン mojave を認証する
asppp から Solaris PPP 4.0 に変換する方法に示す手順は、次の /etc/uucp/Devices ファイルを使用します。
#ident "@(#)Devices 1.6 92/07/14 SMI" /* from SVR4 bnu:Devices 2.7 */ . . # TCP,et - - Any TCP - . . # ACU cua/b - Any hayes # 0-7 are on a Magma 8 port card Direct cua/0 - Any direct Direct cua/1 - Any direct Direct cua/2 - Any direct Direct cua/3 - Any direct Direct cua/4 - Any direct Direct cua/5 - Any direct Direct cua/6 - Any direct Direct cua/7 - Any direct # a is the console port (aka "tip" line) Direct cua/a - Any direct # b is the aux port on the motherboard Direct cua/b - Any direct # c and d are high speed sync/async ports Direct cua/c - Any direct Direct cua/d - Any direct |
このファイルは、シリアルポート cua/b に接続されている Hayes モデムをサポートします。
asppp から Solaris PPP 4.0 に変換する方法に示す手順は、次の /etc/uucp/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\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 direct # # # # Hayes Smartmodem -- modem should be set with the configuration # switches as follows: # # S1 - UP S2 - UP S3 - DOWN S4 - UP # S5 - UP S6 - DOWN S7 - ? S8 - DOWN # hayes =,-, "" \dA\pTE1V1X1Q0S2=255S12=255\r\c OK\r \EATDT\T\r\c CONNECT <この他にも Solaris UUCP でサポートされているモデムについての多くの情報があります。> |
このファイルには、あらゆるタイプのモデムの chat スクリプトが含まれます。/etc/uucp/Dialers ファイルでサポートされている Hayes モデムの chat スクリプトも含まれます。
/usr/sbin/asppp2pppd スクリプトは、/etc/asppp.cf に含まれる PPP 情報と PPP 関連の UUCP ファイルを、Solaris PPP 4.0 ファイル内の適切な場所にコピーします。
次の作業に進む前に、以下のことを完了しておく必要があります。
asppp と UUCP 構成ファイルがあるマシン上に Solaris 9 オペレーティング環境をインストールする
PPP ファイルがあるマシン、たとえば mojave 上でスーパーユーザーになる
変換スクリプトを実行します。
# /usr/sbin/asppp2pppd |
変換処理が開始し、画面に次のようなメッセージが表示されます。
This script provides only a suggested translation for your existing aspppd configuration. You will need to evaluate for yourself whether the translation is appropriate for your operating environment. Continue [Yn]? |
Y と入力してスクリプトの実行を継続します。画面に次のようなメッセージが表示されます。
Chat cannot do echo checking; requests for this removed. Adding 'noauth' to /etc/ppp/options Preparing to write out translated configuration: 1 chat file: 1. /etc/ppp/chat.Pgobi.hayes 2 option files: 2. /etc/ppp/peers/Pgobi 3. /etc/ppp/options 1 script file: 4. /etc/ppp/demand |
新しい Solaris PPP 4.0 ファイルが生成されました。
変換処理の最後に、/usr/sbin/asppp2pppd 変換スクリプトによって作成された Solaris PPP 4.0 ファイルを表示できます。以下に示すオプションリストが表示されます。
Enter option number: 1 - view contents of file on standard output 2 - view contents of file using /usr/bin/less 3 - edit contents of file using /usr/bin/vi 4 - delete/undelete file from list 5 - rename file in list 6 - show file list again 7 - escape to shell (or "!") 8 - abort without saving anything 9 - save all files and exit (default) Option: |
1 を入力して、画面上にファイルの内容を表示します。
表示するファイルの番号の入力を求めるプロンプトが表示されます。
File number (1 .. 4): |
この番号は、前述の手順 2 で示したように、変換処理中に表示された変換ファイルを示します。
1 を入力して、chat ファイル /etc/ppp/chat.Pgobi.hayes を表示します。
File number (1 .. 4): 1 "" \d\dA\p\pTE1V1X1Q0S2=255S12=255\r\c OK\r ATDT\T\r\c CONNECT \c in:--in: mojave word: sand |
chat スクリプトには、サンプルの /etc/uucp/Dialers ファイルの hayes 行に記述されているモデムの “chat” 情報が含まれています。また、/etc/ppp/chat.Pgobi.hayes にはサンプルの /etc/uucp/Systems ファイルに記述されている Pgobi のログインシーケンスが含まれています。したがって、現時点では、chat スクリプトは /etc/ppp/chat.Pgobi.hayes ファイルにあります。
2 を入力して、ピアファイル /etc/ppp/peers/Pgobi を表示します。
File number (1 .. 4): 2 /dev/cua/b 38400 demand idle 120 connect "/usr/bin/chat -f /etc/ppp/chat.Pgobi.hayes -T '15551212'" user NeverAuthenticate mojave:gobi |
/etc/uucp/Devices ファイル内のシリアルポート情報 (/dev/cua/b) と、/etc/asppp.cf ファイル内のリンク速度、アイドル時間、認証情報、ピア名が表示されています。demand は demand スクリプトを意味します。このスクリプトは、ダイアルアウトマシンがピア Pgobi に接続を試みるときに呼び出されます。
3 を入力して、ダイアルアウトマシン mojave 用に作成された /etc/ppp/options ファイルを表示します。
File number (1 .. 4): 3 #lock noauth |
/etc/ppp/options ファイル内の情報は /etc/asppp.cf ファイルから得られたものです。
4 を入力して、demand スクリプトの内容を表示します。
File number (1 .. 4): 4 /usr/bin/pppd file /etc/ppp/peers/Pgobi |
このスクリプトが実行されると、pppd コマンドが実行されます。このコマンドは、/etc/ppp/peers/Pgobi を読み込んで、mojave と Pgobi の間のリンクを確立します。
9 を入力して、作成したファイルを保存し、変換スクリプトを終了します。
この章では、UNIX 間コピープログラム (UUCP) とデーモンについて説明します。次の項目について説明します。
UUCP を使用すると、コンピュータシステム間で相互にファイルの転送とメールの交換を行えます。また、UUCP を使用して Usenet のような大規模なネットワークにコンピュータを接続することもできます。
Solaris 環境では、HoneyDanBer UUCP とも呼ばれる基本ネットワークユーティリティ (BNU) バージョンの UUCP が提供されています。UUCP という用語はシステムを形成するすべてのファイルとユーティリティを意味するものであり、uucp プログラムはそのシステムの一部にすぎません。UUCP のユーティリティには、コンピュータ間でファイルをコピーするためのユーティリティ (uucp と uuto) から、リモートログインやリモートコマンド実行のためのユーティリティ (cu と uux) まで、さまざまなものがあります。
2 つのマシンのシリアルポート間を RS-232 ケーブルで結ぶことにより、他のコンピュータとの間の直接リンクを作成できる。2 つのコンピュータが常時互いに通信を行い、両者の間の距離が 15m 以内の場合は、直接リンクを使用すると便利。この制限距離は、短距離モデムを使用することによりある程度延長できる
高速モデムなどの自動呼び出し装置 (ACU) を使用すれば、通常の電話回線を介して他のコンピュータと通信できる。モデムは、UUCP が要求する電話番号をダイアルする。受信側のモデムは、着信に応答できなければならない
UUCP は、TCP/IP またはその他のプロトコルファミリが機能するネットワークを介しても通信できる。コンピュータがネットワーク上でホストとして確立されていれば、そのネットワークに接続されている他のどのホストとも通信できる
この章では、UUCP ハードウェアをすでに設置、構成してあるものとして説明を進めます。モデムを設定する必要がある場合は、『Solaris のシステム管理 (基本編)』と、モデムに付属のマニュアルを参照してください。
Solaris インストールプログラムを実行するときに全体ディストリビューションを選択していれば、UUCP ソフトウェアは自動的に組み込まれています。あるいは、pkgadd を使用して UUCP を単独で追加することもできます。UUCP のプログラムは、デーモン、管理プログラム、およびユーザープログラムの 3 種類に分類されます。
UUCP システムには、uucico、uuxqt、uusched、および in.uucpd の 4 つのデーモンがあります。 これらのデーモンは、UUCP のファイル転送とコマンド実行を処理します。これらのデーモンは、必要に応じて、シェルから手動で実行することもできます。
リンクに使用するデバイスを選択し、リモートコンピュータへのリンクを確立し、必要なログインシーケンスとアクセス権の検査を行う。また、データを転送し、ファイルを実行し、結果をログに記録し、転送の完了をメールによりユーザーに通知する。uucico は、UUCP ログインアカウント用の「ログインシェル」として働く。ローカル uucico デーモンはリモートマシンを呼び出して、セッションの間、リモート uucico デーモンと直接通信する
必要なファイルがすべて作成されたら、uucp、uuto、および uux プログラムが uucico デーモンを実行してリモートコンピュータに接続する。uusched と Uutry は、どちらも uucico を実行する。詳細は、uucico(1M) のマニュアルページを参照
リモート実行要求を処理する。このデーモンは、スプールディレクトリを検索して、リモートコンピュータから送られた実行ファイル (名前は常に X.file) を見つける。X.file が見つかると、uuxqt はそのファイルをオープンして、実行に必要なデータファイルのリストを取得する。次に、必要なデータファイルが使用可能でアクセスできるかどうかを確認する。ファイルが使用可能であれば、uuxqt は Permissions ファイルを調べて、要求されたコマンドを実行する権限があるかどうかを確認する。uuxqt デーモンは、cron により起動される uudemon.hour シェルスクリプトから実行される。詳細は、uuxqt(1M) のマニュアルページを参照
スプールディレクトリ内でキューに入っている作業をスケジュールする。uusched デーモンは、cron によって、ブート時に最初に実行される。詳細は、uusched(1M) のマニュアルページを参照。 uusched は uucico デーモンを起動する前に、リモートコンピュータを呼び出す順序をランダム化する
ネットワークを介した 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 は、プログラムとスプールデータファイルを所有しています。
指定したコンピュータのログファイルの内容を表示する。ログファイルは、このマシンが通信する各リモートコンピュータごとに作成される。ログファイルには、 uucp、uuto、uux の使用が記録される。詳細は、 uucp(1C) のマニュアルページを参照
スプールディレクトリをクリーンアップする。これは通常、cron によって起動される uudemon.cleanup シェルスクリプトから実行される。詳細は、uucleanup(1M) のマニュアルページを参照
呼び出し処理機能をテストし、簡単なデバッグを行うことができる。 uucico デーモンを呼び出して、このマシンと指定されたリモートコンピュータとの間の通信リンクを確立する。詳細は、Uutry(1M) のマニュアルページを参照
UUCP のディレクトリ、プログラム、およびサポートファイルの有無を検査する。また、/etc/uucp/Permissions ファイルの所定の部分に、明らかな構文エラーがないかどうかも検査する。詳細は、uucheck(1M) のマニュアルページを参照
UUCP のユーザープログラムは /usr/bin にあります。これらのプログラムを使用するのに、特別な権限は必要ありません。
このマシンをリモートコンピュータに接続して、ユーザーが両方のマシンに同時にログインできるようにする。cu を使用すれば、接続したリンクを切断することなく、どちらのマシンでもファイルを転送したり、コマンドを実行したりできる。詳細は、cu(1C) のマニュアルページを参照
あるマシンから別のマシンへファイルをコピーする。uucp は作業ファイルとデータファイルを作成し、転送するジョブをキューに入れ、uucico デーモンを呼び出す。このデーモンは、リモートコンピュータへの接続を試みる。詳細は、uucp(1C) のマニュアルページを参照
ローカルマシンから、リモートマシン上の公共スプールディレクトリ /var/spool/uucppublic/receive にファイルをコピーする。uucp はリモートマシン上のアクセス可能な任意のディレクトリにファイルをコピーするのに対して、uuto は所定のスプールディレクトリにファイルを格納し、リモートユーザーに uupick を使用してそのファイルを取り出すよう指示する。詳細は、uuto(1C) のマニュアルページを参照
uuto を使用してコンピュータにファイルが転送されてきたときに、/var/spool/uucppublic/receive からファイルを取得する。詳細は、uuto(1C) のマニュアルページを参照
リモートマシン上でコマンドを実行するために必要な作業ファイル、データファイル、および実行ファイルを作成する。詳細は、uux(1C) のマニュアルページを参照
要求された転送 (uucp、uuto、uux) の状態を表示する。また、キューに入っている転送を制御する手段も提供する。詳細は、uustat(1C) のマニュアルページを参照
UUCP の構成の主要部分の 1 つに、UUCP データベースを形成するファイルの構成があります。これらのファイルは /etc/uucp ディレクトリにあります。マシン上で UUCP または asppp を設定するには、これらのファイルを編集する必要があります。使用できるファイルを次に示します。
Systems ファイルのエントリの電話番号フィールド内で使用できるダイアルコード省略名が入っている。これは必須ではないが、UUCP の他に asppp でも使用できる
リモートコンピュータとの接続を確立するときに、モデムとのネゴシエーションを行うために必要な文字列が入っている。これは、UUCP の他に asppp でも使用される
ジョブの処理順序と、ジョブの各処理順序に関連付けられたアクセス権を定義する。これらは、リモートコンピュータのキューにジョブを入れる際に、ユーザーが指定できる
uucico と cu が、Systems、Devices、および Dialers ファイルとして、別のファイルや複数のファイルを使用する時に、その割り当てを行う
uucico デーモン、cu、および asppp が、リモートコンピュータへのリンクを確立するために必要とする情報が入っている。この情報には、リモートホスト名、リモートホストに対応する接続デバイス名、そのホストに接続できる日時、電話番号、ログイン ID、パスワードが含まれる
サポートデータベースの一部とみなすことのできるファイルが他にもいくつかありますが、それらは、リンクの確立とファイルの転送には直接関係しません。
UUCP データベースは、UUCP データベースファイルに示したファイルから構成されます。ただし、基本的な UUCP 構成に関係する重要なファイルは次に示すものだけです。
/etc/uucp/Systems
/etc/uucp/Devices
/etc/uucp/Dialers
asppp は UUCP データベースの一部を使用するので、asppp を構成する予定がある場合は、少なくともこれらのデータベースファイルだけは理解しておく必要があります。これらのデータベースを構成してしまえば、その後の UUCP の管理はきわめて簡単です。通常、Systems ファイルを最初に編集し、次に Devices ファイルを編集します。/etc/uucp/Dialers ファイルは、普通はデフォルトのままで使用できますが、デフォルトファイルに含まれていないダイアラを追加する予定がある場合は編集が必要になります。基本的な UUCP 構成と asppp 構成には、さらに次のファイルを加えることもできます。
/etc/uucp/Sysfiles
/etc/uucp/Dialcodes
/etc/uucp/Sysname
これらのファイルは互いに関係しながら機能するので、1 つでも変更する場合は、全部のファイルの内容を理解しておくことが必要です。あるファイルのエントリに変更を加えた場合に、別のファイル内の関連エントリに対しても変更が必要になることがあります。UUCP データベースファイルに挙げたその他のファイルは、上記のファイルほど緊密な相互関係を持っていません。
asppp が使用するファイルはこの節で説明するものだけです。他の UUCP データベースファイルは使用しません。
この章では、ご使用のマシンに合わせてデータベースファイルを変更したあと、UUCP 処理を起動する方法について説明します。この章には、Solaris 環境が動作するマシンで UUCP を構成し保守するための、手順と障害の解明についての情報が記載されています。
表 35–1に、この章で説明する手順の参照先と、各手順についての簡単な説明を示します。
表 35–1 UUCP 管理 (作業マップ)
作業 |
説明 |
参照先 |
---|---|---|
リモートマシンにユーザーシステムへのアクセスを許可する |
/etc/passwd ファイルを編集し、ユーザーのシステムへのアクセスを許可するマシンを識別するようエントリを追加する | |
UUCP を起動する |
UUCP の起動用に提供されているシェルスクリプトを使用する | |
UUCP を TCP/IP ネットワーク上で有効にする |
/etc/inetd.conf ファイルと /etc/uucp/Systems ファイルを編集し、TCP/IP 用の UUCP を起動する | |
UUCP に起こりがちな問題を解決する |
モデムまたは ACU の異常を確認するための診断手順。 送信に関するデバッグを行うための診断手順 |
リモートマシンからの UUCP (uucico) 着信要求が正しく取り扱われるように、各リモートマシンはローカルシステム上にログインを持っていなければなりません。
ユーザーのシステムへのアクセスをリモートマシンに許可するには、次の手順を行なって /etc/passwd ファイルにエントリを追加する必要があります。
/etc/passwd ファイルを編集し、システムにアクセスを許可するマシンを識別するためのエントリを追加します。
通常、UUCP 接続でのシステムへのアクセスを許可するリモートマシンについて、次のようなエントリを /etc/passwd ファイルに入力します。
Ugobi:*:5:5:gobi:/var/spool/uucppublic:/usr/lib/uucp/uucico |
リモートマシンのログイン名は慣例的に、そのマシン名の前に大文字の U を付けたものです。8 文字を超える名前は使用できないので、一部を短縮した名前や省略名を使用しなければならない場合もあります。
例に示したエントリは、Ugobi からのログイン要求に /usr/lib/uucp/uucico が応答することを示しています。ホームディレクトリは /var/spool/uucppublic です。パスワードは /etc/shadow ファイルから取得されます。パスワードとログイン名は、リモートマシンの UUCP 管理者と協議して決める必要があります。リモート側の管理者は、ログイン名と暗号化されていないパスワードを含む正しいエントリを、リモートマシンの Systems ファイルに追加する必要があります。
他のシステムの UUCP 管理者と、ローカルマシン名を調整します。
同様に、ローカルマシン名とパスワードについて、UUCP を介して通信する相手方のすべてのマシンの UUCP 管理者と協議する必要があります。
UUCP には、次に示す 4 つのシェルスクリプトが付属しています。これらのスクリプトは、リモートマシンをポーリングし、転送を再スケジュールし、古いログファイルと成功しなかった転送を整理します。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 ファイルは、次の手順に従って起動します。
スーパーユーザーになります。
/usr/lib/uucp/uudemon.crontab ファイルを編集し、必要に応じてエントリを変更します。
次のコマンドを入力して、uudemon.crontab ファイルを起動します。
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 の保守に必要な作業の量はさほど多くはありません。UUCP の起動方法で述べたように、crontab ファイルを正しい場所に配置してあることを確認する以外には、メールファイルと公共ディレクトリが大きくなるという点に注意する必要があります。
UUCP のプログラムとスクリプトが生成する電子メールメッセージは、すべてユーザー ID uucp に送信されます。管理者がユーザー uucp として頻繁にログインしていないと、メールが蓄積されている (このためディスク空間を浪費している) ことに気付かない場合があります。この問題を解決するには、/etc/mail/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 で、適正に動作していないものがないかどうかを、いくつかの方法で検査できます。
# uustat -q |
特定の回線を介した呼び出しを行い、その試行に関するデバッグ情報を表示します。
この回線は、/etc/uucp/Devices ファイル内で direct として定義されていなければなりません (回線が自動ダイヤラに接続している場合は、コマンド行の終わりに電話番号を追加するか、デバイスを direct として設定する必要があります)。次のように入力します。
# cu -d -lline |
line は /dev/cua/a です。
特定のマシンに接続できない場合は、Uutry と uucp を使用して、そのマシンに対する通信を検査できます。
# /usr/lib/uucp/Uutry -r machine |
machine には、接続に問題のあるマシンのホスト名を指定します。このコマンドは次のことを行います。
デバッグ機能を指定して転送デーモン (uucico) を起動する。root としてログインしていれば、さらに多くのデバッグ情報が得られる
デバッグ出力を /tmp/machine に送る
次のように入力すると、デバッグ出力を端末に表示する
# tail -f |
出力を終了するには Control-c キーを押します。この出力を保存したい場合は、/tmp/machine から出力内容をコピーします。
Uutry を使用しても問題の原因が分からない場合は、ジョブをキューに入れてみます。
# uucp -r file machine\!/dir/file |
file には転送したいファイル、machine には転送先のマシンを指定します。/dir/file には、相手のマシンのどこにファイルを転送するかを指定します。r オプションを指定すると、ジョブはキューに入りますが、転送は開始されません。
次のコマンドを入力します。
# Uutry |
それでも問題が解決できないときは、ご購入先へお問い合わせください。デバッグ出力を保存しておいてください。これは問題の診断に役立ちます。
Uutry で -x n オプションを使用して、デバッグのレベルを増減することもできます。n はデバッグレベルを指定します。Uutry のデフォルトのデバッグレベルは 5 です。
デバッグレベル 3 では、接続がいつどのように確立されたかについての基本的な情報は提供されますが、転送自体について提供される情報は多くはありません。一方、デバッグレベル 9 では、転送処理に関するすべての情報が網羅されます。デバッグは転送の両端で行われるという点に注意してください。比較的大きいテキストについて 5 より高いレベルのデバッグを行いたい場合は、相手サイトの管理者に連絡して、デバッグを行う時期について同意を得てください。
特定のマシンと接続しようとすると障害が発生する場合は、Systems ファイルの中の情報が最新のものであることを確認してください。マシンに関する次の情報が、最新でない可能性があります。
UUCP のエラーメッセージには、ASSERT と STATUS の 2 つの種類があります。
プロセスが異常終了した場合は、ASSERT エラーメッセージが /var/uucp/.Admin/errors に記録されます。この種類のメッセージには、ファイル名、sccsid、回線番号、およびテキストが含まれています。この種類のメッセージが送られるのは、通常、システムに問題がある場合です。
STATUS エラーメッセージは /var/uucp/.Status ディレクトリに格納されます。このディレクトリ内には、ローカルコンピュータが通信しようとした各リモートマシンについて、それぞれファイルが作られます。これらのファイルには、試行した通信と、その通信が成功したかどうかについての状態情報が入っています。
次のコマンドを使用して、基本的なネットワーク情報を検査できます。
uucheck -v コマンドは、uucp が必要とするファイルとディレクトリが存在しているかどうかを検査するために使用します。また、Permissions ファイルも検査して、設定してあるアクセス権に関する情報を出力します。
この章では、UUCP を使用する場合のリファレンス情報について説明します。この節の内容は次のとおりです。
/etc/uucp/Systems ファイルには、uucico がリモートコンピュータとの通信リンクを確立するために必要な情報が入っています。/etc/uucp/Systems は、UUCP を構成するときに編集しなければならない最初のファイルです。
Systems ファイルの中の各エントリは、このホストが通信するリモートコンピュータを表します。1 つのホストについて複数のエントリがある場合もあります。付加的なエントリは、順番に試される代替通信パスを表します。さらに、UUCP のデフォルト状態では、/etc/uucp/Systems ファイルに含まれていないコンピュータがこのホストにログインできないようになっています。
Sysfiles ファイルを使用して、Systems ファイルとして使用されるファイルをいくつか定義できます。詳細は、UUCP /etc/uucp/Sysfiles ファイルで Sysfiles ファイルの説明を参照してください。
System-Name |
Time |
Type |
Speed |
Phone |
Chat Script |
例 36–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 通信用として特別に作成した名前でもかまいません。UUCP /etc/uucp/Systems ファイルを参照してください。例 36–1 では、System-Name フィールドにはリモートホスト arabian に関するエントリが含まれています。
このフィールドには、リモートコンピュータを呼び出すことのできる曜日と時刻を指定します。Time フィールドの形式は次のとおりです。
daytime[;retry]
day の部分には、次のエントリのいくつかを含むリストを指定できます。
表 36–1 Day フィールド
個々の曜日 |
|
任意の平日 |
|
任意の日 |
|
このホストはこのリモートコンピュータの呼び出しをいっさい行わない。呼び出しはリモートコンピュータ側から行う必要がある。それを受けて、このホストは受動モードで稼動する |
例 36–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 を指定した場合は、常にその値が再試行待ち時間となります。指定がなければ待ち時間倍加アルゴリズムが使用されます。
このフィールドには、リモートコンピュータとの通信リンクを確立するために使用するデバイスタイプを指定します。このフィールドで使用するキーワードは、Devices ファイル中のエントリの最初のフィールドと突き合わされます。
File Name System-Name Time Type Speed Phone Chat Script Systems arabian Any ACUEC, g 38400 1112222 ogin: Puucp ssword:beledi |
Type フィールドでは、さらに、システムとの接続に使用するプロトコルを定義できます。上記の例では、デバイスタイプ ACUEC に g プロトコルを組み合わせる方法を示しています。プロトコルの詳細は、UUCP Devices ファイル内のプロトコル定義を参照してください。
このフィールド (Class フィールドとも呼ばれます) は、通信リンクの確立に使用するデバイスの転送速度を指定します。このフィールドには、ダイヤラのクラスを区別するために、1 個の英字と速度を含めることができます (たとえば、C1200、D1200) (詳細は、UUCP Class フィールドを参照してください)。
デバイスにはどのような速度でも使用できるものがあり、その場合はキーワード Any を使用できます。このフィールドは、Devices ファイルの対応するエントリの Class フィールドに一致していなければなりません。
File Name System-Name Time Type Speed Phone Chat Script Systems eagle Any ACU, g D1200 NY3251 ogin: nuucp ssword: Oakgrass |
このフィールドに情報を入れる必要がない場合は、フィールドの数を合わせるためにダッシュ (-) を指定してください。
このフィールドには、自動ダイヤラ (ポートセレクタ) に与えるリモートコンピュータの電話番号 (トークン) を指定できます。電話番号は、オプションの英字による省略名と数字部分で構成されます。省略名を使用する場合は、Dialcodes ファイル内に列挙されているものの 1 つでなければなりません。
File Name System-Name Time Type Speed Phone Chat Script Systems nubian Any ACU 2400 NY5551212 ogin: Puucp ssword:Passuan |
文字列 System-Name では、等号 (=) は、二次発信音を待ってから残りの数字をダイアルするという ACU への指示となります。文字列の中にダッシュ (-) があれば、4 秒間待ってから次の数字をダイアルするという指示になります。
コンピュータがポートセレクタに接続されている場合は、そのセレクタに接続している他のコンピュータにアクセスできます。この種のリモートマシン用の Systems ファイルエントリの Phone フィールドには、電話番号を入れません。代わりに、このフィールドにはスイッチに渡すトークンを指定します。このようにすれば、このホストがどのリモートマシンとの通信を望んでいるかを、ポートセレクタが判断できます。この場合は、システム名だけを指定するのが普通です。対応する Devices ファイルエントリでは、エントリの末尾に \D を指定して、このフィールドが Dialcode ファイルを使用して解釈されないようにしなければなりません。
このフィールド (Login フィールドとも呼ばれます) には、chat スクリプトと呼ばれる文字列が入ります。chat スクリプトには、ローカルマシンとリモートマシンが対話の最初の時点で互いに受け渡ししなければならない文字が含まれています。chat スクリプトの形式は次のとおりです。
expect send [expect send] ....
expect は、対話を開始するために、ローカルホストがリモートホストから受信することを想定している文字列です。send は、ローカルホストが、リモートホストからの expect 文字列を受信した後で送信する文字列です。chat スクリプトには、複数の 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 Chat 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 を送ります。
表 36–2 に、便利なエスケープ文字をいくつか紹介します。
表 36–2 Systems ファイルの chat スクリプトで使用されるエスケープ文字エスケープ文字 | 意味 |
---|---|
バックスペース文字を送信または想定する |
|
文字列の末尾で使用すると、普通なら送信されるキャリッジリターンが抑止される。その他の場合は無視される |
|
後続の文字を送る前に 1 〜 3 秒の遅延が生じる |
|
エコーチェックを開始する。これ以降は、1 文字送信するたびに、UUCP はその文字が受信されるまで待ち、その後、チェックを続行する |
|
エコーチェックをオフにする |
|
ハングアップを 1 回無視する。このオプションはコールバックモデム用に使用する |
|
BREAK 文字を送信する |
|
CLOCAL フラグをオンにする |
|
CLOCAL フラグをオフにする |
|
改行文字を送信または想定する |
|
NULL 文字 (ASCII NUL) を送信する |
|
約 1/4 秒間または 1/2 秒間、一時停止する |
|
キャリッジリターンを送信または想定する |
|
スペース文字を送信または想定する |
|
タブ文字を送信または想定する |
|
EOT とそれに続く 2 個の改行文字を送信する |
|
ブレーク文字を送信する |
|
8 進数 (ddd) で表される文字を送信または想定する |
組織によっては、リモートコンピュータからの呼び出しを処理するダイアルインサーバーを設定する場合があります。たとえば、コールバックモデムを持つダイアルインサーバーを配備し、社員が自宅のコンピュータから呼び出せるようにすることができます。ダイアルインサーバーは、リモートマシンを識別すると、そのリモートマシンとのリンクを切断し、逆にそのリモートマシンを呼び出して、通信リンクが再確立されます。
Systems ファイルの chat スクリプトで、コールバックが必要な箇所で \H オプションを使用することにより、コールバックの操作を簡素化することができます。ダイアルインサーバーのハングアップが予想される箇所で、expect 文字列の一部として \H を使用します。
たとえば、ダイアルインサーバーを呼び出す chat スクリプトに、次のような文字列が含まれているとします。
INITIATED\Hogin: |
ローカルホストの UUCP ダイアル機能は、ダイアルインサーバーから INITIATED という文字列を受け取ることを想定しています。INITIATED 文字列を受け取ると、ダイアル機能は、ダイアルインサーバーがハングアップするまで、その後受信するすべての文字をフラッシュします。またダイアル機能は、expect 文字列のその次の部分、つまり ogin: という文字列がダイアルインサーバーから送られてくるのを待ちます。ogin: を受け取ると、ダイアル機能は chat スクリプトを先へ進めます。
上記のサンプルでは \H の前後に文字列が指定されていますが、これらはなくてもかまいません。
擬似送信文字列 STTY=value を用いることによっても、モデムの特性を設定できます。たとえば、STTY=crtscts を使用すると、ハードウェアフロー制御が可能になります。 STTY はすべての stty モードを受け入れます。詳細は、stty(1) と termio(7I) のマニュアルページを参照してください。
次の例は、Systems ファイルのエントリ内でハードウェアフロー制御を指定しています。
System-Name Time Type Speed Phone Chat Script unix Any ACU 2400 12015551212 "" \r login:-\r-login:-\r-login: nuucp password: xxx "" \ STTY=crtscts |
擬似送信文字列は、Dialers ファイルのエントリの中でも使用できます。
場合によっては、呼び出そうとしているシステムがポートのパリティを検査し、パリティに誤りがあると回線を切断することがあります。そのため、パリティのリセットが必要になります。expect-send (予期-送信) の文字列ペアとして "" P_ZERO を使用すると、上位ビット (パリティビット) が 0 に設定されます。次に例を示します。
System-Name Time Type Speed Phone Chat Script unix Any ACU 2400 12015551212 "" P_ZERO "" \r login:-\r-login:-\r-login: nuucp password: xxx |
同様に、P_EVEN はパリティを偶数 (デフォルト) に設定し、P_ODD は奇数パリティを設定し、P_ONE はパリティビットを 1 に設定します。
パリティ設定は、chat スクリプトのどこにでも挿入できます。この設定は、chat スクリプト内の "" P_ZERO より後にあるすべての情報に適用されます。この設定は、Dialers ファイルのエントリの中でも使用できます。
/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 |
このフィールドでデバイスが設定するリンクの Type を説明します。このフィールドには以下のセクションに示すキーワードのいずれかを入れることができます。
キーワード Direct は、主として cu 接続用のエントリ内で使用されます。このキーワードは、このリンクが他のコンピュータまたはポートセレクタへの直接リンクであることを示します。cu の -l オプションで参照したい各回線について、それぞれ独立したエントリを作成する必要があります。
キーワード ACU は、(cu、UUCP、asppp、または Solaris PPP 4.0 を介した) リモートコンピュータへのリンクを、モデムを介して確立することを示します。このモデムは、直接ローカルコンピュータに接続しているものでも、ポートセレクタを介して間接的に接続しているものでもかまいません。
これは、ポートセレクタの名前で置き換えるものとして、Type フィールド内で使用される変数です。ポートセレクタは、ネットワークに接続されたデバイスで、呼び出し側モデムの名前を要求し、アクセスを許可します。/etc/uucp/Dialers ファイルに入っている呼び出しスクリプトは、micom ポートセレクタと develcon ポートセレクタについてのものだけです。ユーザーは、Dialers ファイルに独自のポートセレクタエントリを追加できます。詳細は、UCCP /etc/uucp/Dialers ファイルを参照してください。
Type フィールド内のこの変数は、特定のマシンの名前で置き換えられます。これは、リンクがこのマシンへの直接リンクであることを示します。この命名スキーマは、この Devices エントリ内の行と、コンピュータ Sys-Name についての /etc/uucp/Systems ファイルエントリを対応付けるために使用されます。
例 36–5 は、/etc/uucp/Devices のフィールドと、/etc/uucp/Systems のフィールドの対応を示しています。各列の見出しは Devices ファイルに対応するものです。
フィールドの書体を変えて示したように、Devices ファイルの Type フィールドで使用されているキーワードは、Systems ファイルエントリの 3 番目のフィールドと突き合わされます。Devices ファイルの Type フィールドには ACUEC というエントリが入っており、これは自動呼び出し装置、つまりこの例では V.32bis モデムを示しています。この値は、Systems ファイルの 3 番目のフィールドと突き合わされます。このフィールドにも ACUEC というエントリが入っています。詳細は、UUCP /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 つのネットワークは外線通信に使用するといった方式が考えられます。このような場合は、内線回線と外線回線とを区別する必要があります。
Devices ファイルの Class フィールドで使用するキーワードは、Systems ファイルの Speed フィールドと突き合わされます。
File Name Type Line Line2 Class Dialer-Token-Pairs Devices ACU cua/a - D2400 hayes |
どのような速度でも使用できるデバイスでは、Class フィールドにキーワード Any を使用します。Any を使用した場合は、回線は、Systems ファイルの Speed フィールドで要求された任意の速度に適合します。このフィールドが Any で、Systems ファイルの Speed フィールドも Any である場合は、速度はデフォルトの 2400 bps となります。
Dialer-Token-Pairs (DTP) フィールドには、ダイヤラの名前とそれに渡すトークンが入ります。DTP フィールドの構文は次のとおりです。
dialer token [dialer token]
dialer の部分は、モデムかポートモニターの名前あるいは直接リンクデバイスの場合は direct または uudirect です。ダイヤラとトークンのペアはいくつでも指定できます。dialer の部分がない場合は、Systems ファイル内の関連エントリから取得されます。token 部は、dialer 部の直後に指定できます。
対応するダイアラによっては、最後のダイアラとトークンのペアはない場合もあります。ほとんどの場合は、最後のペアには dialer 部だけが含まれます。token 部は、対応する Systems ファイルエントリの Phone フィールドから取得されます。
dialer 部の有効エントリは、Dialers ファイル内で定義されているものか、いくつかの特殊ダイアラタイプのうちの 1 つとなります。これらの特殊ダイアラタイプはコンパイル時にソフトウェア中に組み込まれているので、Dialers ファイル内に該当エントリがなくても使用できます。表 36–3 に、特殊ダイアラタイプを示します。
表 36–3 ダイヤラとトークンのペア
TCP/IP ネットワーク |
|
トランスポートレベルインタフェースネットワーク (STREAMS を使用しないもの) |
|
トランスポートレベルインタフェースネットワーク (STREAMS を使用するもの) |
詳細は、UUCP Devices ファイル内のプロトコル定義を参照してください。
DTP フィールドの構造は、エントリに対応するデバイスに応じて 4 通りに設定できます。
直接接続モデム
コンピュータのポートにモデムが直接接続されている場合は、対応する Devices ファイルエントリの DTP フィールドに入るペアは 1 つだけです。このペアは、通常はモデムの名前です。この名前は、Devices ファイルの特定のエントリと、Dialers ファイル内のエントリとを対応付けるために使用されます。したがって、Dialer フィールドは、Dialers ファイルエントリの最初のフィールドに一致している必要があります。
Dialers hayes =,-, "" \\dA\pTE1V1X1Q0S2=255S12=255\r\c \EATDT\T\r\c CONNECT |
Devices ファイルエントリの DTP フィールドには、dialer 部 (hayes) だけが示されている点に注意してください。これは、ダイアラに渡す token (この例では電話番号) が、Systems ファイルエントリの Phone フィールドから取得されることを意味します (例 36–9で説明するように、\T が暗黙で指定されます)。
直接リンク – 特定のコンピュータへの直接リンクの場合は、対応するエントリの DTP フィールドには、キーワード direct が入ります。これは、Direct、Sys-Name の両方の直接リンクエントリにもあてはまります (UUCP Type フィールドを参照)。
同じポートセレクタ上のコンピュータ – 通信したいコンピュータが、ローカルコンピュータと同じポートセレクタスイッチ上にある場合は、ローカルコンピュータはまずそのスイッチにアクセスする必要があります。そのスイッチが、相手のコンピュータとの接続を確立します。この種のエントリでは、ペアは 1 つだけです。dialer 部が Dialers ファイルのエントリと突き合わされます。
Dialers develcon ,"" "" \pr\ps\c est:\007 \E\D\e \007 |
token 部が空である点に注意してください。このように指定されている場合は、この部分が Systems ファイルから取得されることを示しています。このコンピュータ用の Systems ファイルエントリには、Phone フィールドにトークンが含まれています。このフィールドは、通常、コンピュータの電話番号用として確保されています。UUCP /etc/uucp/Systems ファイル を参照してください。この種類の DTP にはエスケープ文字 (\D) が含まれています。これは、Phone フィールドの内容が、Dialcodes ファイル内の有効エントリとして解釈されないことを保証します。
ポートセレクタに接続しているモデム – ポートセレクタに高速モデムが接続されている場合は、ローカルコンピュータはまずポートセレクタスイッチにアクセスする必要があります。そして、そのスイッチがモデムとの接続を確立します。この種類のエントリには、ダイヤラとトークンのペアが 2 つ必要です。各ペアの dialer 部 (エントリの 5 番目と 7 番目のフィールド) が、Dialers ファイル内のエントリと突き合わされます。
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) に関連したエントリで使用されます。
/etc/uucp/Devices では、各デバイスに使用するプロトコルを定義できます。通常は、デフォルトを使用するか、または呼び出そうとしている特定のシステムに対してプロトコルを定義できるので、この指定は不要です。UUCP /etc/uucp/Systems ファイル を参照してくださいプロトコルを指定する場合は、次の形式を使用する必要があります。
Type,Protocol [parameters]
たとえば、TCP/IP プロトコルを指定するには、TCP,te を入力します。
表 36–4 に、Devices ファイルで使用できるプロトコルを示します。
表 36–4 /etc/uucp/Devices で使用されるプロトコル
プロトコル |
説明 |
---|---|
このプロトコルは、TCP/IP や、その他の信頼性のある接続を介した伝送に、最もよく使用される。t はエラーのない伝送を前提としている |
|
UUCP のネイティブプロトコル。低速で信頼性があり、ノイズの多い電話回線を介した伝送に適している |
|
このプロトコルは、(TCP/IP のようなバイトストリーム指向ではなく) メッセージ指向でエラーのないチャネルを介した伝送を前提としている |
|
このプロトコルは X.25 接続を介した伝送に使用される。f は、データストリームのフロー制御に関係している。特に X.25/PAD リンクなどのように、完全に (またはほとんど) エラーがないことが保証されるリンクでの使用を意図している。検査合計はファイル全体についてのみ実施される。伝送が失敗した場合は、受信側は再伝送を要求する |
次に、デバイスエントリ用のプロトコル指定の例を示します。
TCP,te - - Any TCP - |
この例は、デバイス TCP について t プロトコルの使用を試みるように指示しています。相手側がそれを拒否した場合は、e プロトコルが使用されます。
e と t のどちらも、モデムを介した通信には適していません。モデムがエラーのない伝送を保証するものであったとしても、モデムと CPU との間でデータが失われる可能性があります。
/etc/uucp/Dialers ファイルには、よく使用される多くのモデムに関するダイアリング指示が入っています。標準外のモデムの使用や、UUCP 環境のカスタマイズを予定している場合以外は、通常このファイルのエントリの変更や追加は必要ありません。しかし、このファイルの内容と、Systems ファイルや Devices ファイルとの関係は理解しておく必要があります。
このファイルの中のテキストは、回線をデータ転送に使用できるようにするために、最初に行わなければならない対話を指定します。chat スクリプトと呼ばれるこの対話は、通常は送受信される一連の ASCII 文字列で、電話番号をダイアルするためによく使用されます。
UUCP /etc/uucp/Devices ファイルの例に示したように、Devices ファイルの 5 番目のフィールドは、Dialers ファイルへのインデックスか、または特殊ダイアラタイプ (TCP、TLI、または TLIS) です。 uucico デーモンは、Devices ファイルの 5 番目のフィールドを、Dialers ファイルの各エントリの最初のフィールドと突き合わせます。さらに、Devices の 7 番目の位置から始まる奇数番号の各フィールドは、Dialers ファイルへのインデックスとして使用されます。これらが一致すると、その Dialers のエントリがダイアラ対話を行うために解釈されます。
Dialers ファイルの各エントリの形式は次のとおりです。
dialer |
substitutions |
expect-send |
例 36–10 に、US Robotics V.32bis モデム用のエントリの例を示します。
Dialer Substitution Expect-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 の各フィールドは文字列です。
例 36–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 |
表 36–5 に、Dialers ファイルの send 文字列でよく使用されるエスケープ文字を示します。
表 36–5 /etc/uucp/Dialers で使用するエスケープ文字
文字 |
説明 |
---|---|
バックスペース文字を送信または想定する |
|
改行、キャリッジリターンを抑止する |
|
遅延 (約 2 秒) |
|
\D |
Dialcodes 変換なしの電話番号またはトークン |
エコーチェックを使用しない |
|
エコーチェックを使用する (低速デバイス用) |
|
ブレーク文字を挿入する |
|
改行文字を送信する |
|
8 進数値を送信する。使用できるその他のエスケープ文字については、UUCP /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 は、引数として渡された電話番号をとることを意味する。\T は Dialcodes 変換と、このエントリのフィールド 2 で指定されたモデム機能変換を適用する。次に、P とキャリッジリターンを送信する
> – > を待つ
9\c – 改行を付けずに 9 を送信する
OK – 文字列 OK を待つ
擬似送信文字列 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 ファイルのエントリの中でも使用できます。
場合によっては、呼び出そうとしているシステムがポートのパリティを検査し、パリティに誤りがあると回線を切断することがあります。そのため、パリティのリセットが必要になります。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 ファイルのエントリがアクセスされたときにダイヤラに渡されるダイアルシーケンスです。表 36–6 に、この 2 つのファイル間の対応関係を示します。
表 36–6 Dialcodes ファイルと Systems ファイルの間の対応関係
|
フィールド名 |
|
|
|
|
|
---|---|---|---|---|---|---|
Dialcodes |
Abbreviation |
Dial-Sequence |
|
|
|
|
Systems |
System-Name |
Time |
Type |
Speed |
Phone |
Chat Script |
表 36–7 に示すのは、Dialcodes ファイルのエントリの例です。
表 36–7 Dialcodes ファイルのエントリ
省略名 |
ダイアルシーケンス |
---|---|
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 ファイルに、chat スクリプトやその他の識別情報とともに格納されます。通常は、UUCP は、uname -n コマンドから返されるものと同じノード名を使用し、TCP/IP でもこの名前を使用します。
/etc/uucp/Sysname ファイルを作成することによって、TCP/IP ホスト名とは別の UUCP ノード名を指定できます。このファイルには、ローカルシステムの UUCP ノード名が入った 1 行のエントリが含まれています。
/etc/uucp/Permissions ファイルは、ログイン、ファイルアクセス、およびコマンド実行に関するリモートコンピュータのアクセス権を指定します。リモートコンピュータがファイルを要求する権限と、ローカルマシンでキューに入れられたファイルを受け取る権限を制限するオプションがあります。また、リモートマシンがローカルコンピュータ上で実行できるコマンドを指定するオプションもあります。
各エントリは 1 行の論理行で、行末にバックスラッシュ (\) がある場合は次の行と継続していることを示します。エントリは、スペースで区切られたオプションから 構成されます。各オプションは、次の形式の名前と値のペアです。
name=value
values はコロンで区切ってリストとすることもできます。オプション指定の中では、スペースは使用できないので注意してください。
コメント行はポンド記号 (#) で始まり、その行の改行文字までの全部分を占めます。空行は無視されます (複数行エントリの中の空行も同じです)。
Permissions ファイルのエントリの種類を次に示します。
リモートマシンがローカルマシンを呼び出すとき、固有のログインと検証可能なパスワードを使用しない限り、そのリモートマシンの識別情報は正確なものとはなりません。
LOGNAME エントリには LOGNAME オプションが含まれ、MACHINE エントリには MACHINE オプションが含まれます。1 つのエントリに両方のオプションを含めることもできます。
Permissions ファイルを使用して、リモートコンピュータに付与されているアクセスのレベルを制限するときは、以下のことを考慮に入れる必要があります。
リモートコンピュータが、UUCP 通信を目的としてログインするために使用するすべてのログイン ID は、1 つの LOGNAME エントリだけに指定されていなければならない。
呼び出されたサイトの名前が MACHINE エントリにない場合、そのサイトには次に示すデフォルトのアクセス権または制約が適用される。
リモートコンピュータがローカルコンピュータを呼び出し、ファイルの受信を要求したときに、その要求を承認することも拒否することもできます。REQUEST オプションは、リモートコンピュータがローカルコンピュータからのファイル転送を要求できるかどうかを指定します。REQUEST=yes は、リモートコンピュータがローカルコンピュータからのファイル転送を要求できることを指定します。REQUEST=no は、リモートコンピュータがローカルコンピュータからのファイルの受信を要求できないことを指定します。REQUEST=no は、REQUEST オプションを指定しなかった場合に使用されるデフォルト値です。REQUEST オプションは、LOGNAME エントリ (リモートコンピュータがローカルコンピュータを呼び出す場合) と、MACHINE エントリ (ローカルコンピュータがリモートコンピュータを呼び出す場合) のどちらにも使用できます。
リモートコンピュータがローカルコンピュータを呼び出す作業を完了した後で、ローカルコンピュータのキュー中のリモートコンピュータ用の作業を受け取ろうとすることがあります。SENDFILES オプションは、ローカルコンピュータが、リモートコンピュータ用にキューに入れた作業を送信できるかどうかを指定します。
文字列 SENDFILES=yes は、リモートコンピュータが LOGNAME オプションに指定されている名前の 1 つを使用してログインしていれば、ローカルコンピュータがキューに入れた作業を送信できることを指定します。/etc/uucp/Systems の Time フィールドに Never を入力してある場合は、この文字列の使用は必須です。その場合、ローカルマシンは受動モードに設定され、相手のリモートコンピュータへの呼び出しを開始することはできなくなります。詳細は、UUCP /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 オプションにより、ローカルマシンが自分自身を呼ぶこともできるので、テストの目的にも利用できます。しかし、このオプションはマシンの実際の識別情報を隠す目的にも使用できてしまうので、UUCP 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 オプションおよびデフォルトに対する例外を指定します。次のエントリは、/etc ディレクトリ (およびこの下の各サブディレクトリ。このパス名は接頭辞であることを忘れないでください) の中のファイルを除くすべてのファイルの読み取りを許可しています。
READ=/ NOREAD=/etc WRITE=/var/spool/uucppublic |
このエントリは、デフォルトの /var/spool/uucppublic ディレクトリへの書き込みだけを許可しています。NOWRITE も NOREAD オプションと同じ形で働きます。NOREAD オプションと NOWRITE オプションは、LOGNAME エントリと MACHINE エントリのどちらにも使用できます。
LOGNAME エントリの中で CALLBACK オプションを使用すると、呼び出し側システムがコールバックするまで、トランザクションを一切行わないことを指定できます。CALLBACK を設定する理由を次に示します。
文字列 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 文字列を使用した場合は、デフォルトのコマンドは無効化されます。たとえば、次のエントリは、COMMANDS のデフォルトを無効にして、owl、raven、hawk、dove という名前の各コンピュータが、rmail、rnews、lp の各コマンドをローカルコンピュータで実行できるようにします。
MACHINE=owl:raven:hawk:dove COMMANDS=rmail:rnews:lp |
上記で指定した名前に加えて、コマンドの完全パス名も指定できます。たとえば、次のエントリは、 rmail コマンドがデフォルトの検索パスを使用することを指定しています。
COMMANDS=rmail:/usr/local/rnews:/usr/local/lp |
UUCP のデフォルトの検索パスは、/bin と /usr/bin です。リモートコンピュータが、実行するコマンドとして rnews または /usr/local/rnews を指定した場合は、デフォルトのパスに関係なく /usr/local/rnews が実行されます。同様に、実行される lp コマンドは /usr/local/lp です。
リストに ALL という値を含めると、エントリに指定されたリモートコンピュータから、すべてのコマンドが実行できます。この値を使用した場合は、リモートコンピュータにローカルマシンへのフルアクセスを与えることになります。
これは、通常のユーザーが持っているよりもはるかに多くのアクセス権を与えることになります。この値を使用するのは、両方のマシンが同じサイトにあり、緊密に接続されていて、ユーザーが信頼できる場合に限定するようにしてください。
ALL が追加された文字列を次に示します。
COMMANDS=/usr/local/rnews:ALL:/usr/local/lp |
この文字列は、次の 2 点を示しています。
COMMANDS オプションで cat や uucp などのように、潜在的な危険性のあるコマンドを指定するときは、VALIDATE オプションを使用するようにしてください。UUCP リモート実行デーモン (uuxqt) により実行する場合、ファイルを読み書きをするコマンドは、どれもローカルセキュリティにとって危険性のあるものとなります。
VALIDATE オプションは、マシンのセキュリティにとって危険性があると考えられるコマンドを指定するときに、COMMANDS オプションといっしょに使用します。VALIDATE は、コマンドアクセスを開放する方法としては ALL より安全ですが、COMMANDS オプションのセキュリティのレベルを補強するだけのものです。
VALIDATE は、呼び出し側マシンのホスト名と、そのマシンが使用しているログイン名とを相互にチェックするものであり、呼び出し側の識別情報について、ある程度の検証機能を備えています。この例では、widget または gadget 以外のマシンが Uwidget としてログインしようとすると、接続は拒否されます。
LOGNAME=Uwidget VALIDATE=widget:gadget |
VALIDATE オプションを使用する場合、権限が与えられたコンピュータは UUCP トランザクション用に固有のログインとパスワードを持っていなければなりません。この認証処理では、このエントリに対応するログインとパスワードを保護することが重要な条件の 1 つです。部外者がこの情報を入手してしまうと、VALIDATE オプションはセキュリティに関する役割をまったく果たさなくなります。
UUCP トランザクションについて、特権を持つログインとパスワードをどのリモートコンピュータに付与するかについては、十分に検討する必要があります。ファイルアクセスとリモート実行の権限をリモートコンピュータに与えるということは、そのリモートコンピュータのすべてのユーザーに対して、ローカルコンピュータに対する通常のログインとパスワードを与えるのと同じことです。したがって、リモートコンピュータに信頼の置けないユーザーがいると判断した場合は、そのコンピュータには特権的なログインとパスワードは付与しないようにしてください。
次のような LOGNAME エントリは、あるリモートコンピュータが eagle、owl、hawk のどれかとしてローカルコンピュータにログインする場合は、そのコンピュータはログイン uucpfriend を使用する必要があることを指定します。
LOGNAME=uucpfriend VALIDATE=eagle:owl:hawk |
部外者が 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 セットのエントリは、同じ REQUEST、READ、WRITE オプションを共有しています。
MACHINE=eagle:owl:hawk REQUEST=yes \ READ=/ WRITE=/ |
および
LOGNAME=uupz REQUEST=yes SENDFILES=yes \ READ=/ WRITE=/ |
この 2 つのエントリを結合したものを次に示します。
MACHINE=eagle:owl:hawk REQUEST=yes \ logname=uucpz SENDFILES-yes \ READ=/ WRITE=/ |
MACHINE エントリと LOGNAME エントリを結合することによって、Permissions ファイルは、効率的で管理しやすくなります。
一連のマシンを介してファイルを送信するときは、リレー (中継) マシンの COMMANDS オプションの中に uucp コマンドが含まれていなければなりません。次のコマンドを入力した場合、マシン willow がマシン oak に対して uucp プログラムの実行を許可する場合に限り、この転送操作は正常に機能します。
% uucp sample.txt oak\!willow\!pine\!/usr/spool/uucppublic |
oak もローカルマシンに uucp のプログラムの実行を許可している必要があります。最終宛先マシンである 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 を使用し、そのデフォルトに割り当てるシステムジョブグレードを指定します。Restriction フィールドと ID フィールドは Any と定義して、どのようなユーザー、どのようなサイズのジョブでも、このグレードでキューに入れることができるようにします。次に例を示します。
default a Any User Any |
デフォルトのユーザージョブグレードを定義しなかった場合は、組み込まれているデフォルトグレードである Z が使用されます。Restriction フィールドのデフォルトは Any なので、デフォルトグレードのエントリが複数存在していても検査されません。
このフィールドは、キューに入れることのできる最大ジョブサイズを指定します。Job-size はバイト数で表され、表 36–8 に示すオプションを使用できます。
表 36–8 Job-size フィールド
nnnn |
このジョブグレードの最大ジョブサイズを指定する整数 |
n K |
K バイト数を表す 10 進数 (K はキロバイトの略号) |
n M |
M バイト数を表す 10 進数 (M はメガバイトの略号) |
最大ジョブサイズが指定されないことを指定するキーワード |
次に例をいくつか示します。
5000 は 5000 バイトを表す
10K は 10K バイトを表す
2M は 2M バイトを表す
このフィールドには、ID リストをどのように解釈するかを指示するキーワードを指定します。表 36–9 に、キーワードとそれぞれの意味を示します。
表 36–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 ディレクトリ内に作成されます。ロックファイルは、対話の重複、複数の試行による同じ呼び出しデバイスの使用が発生するのを防ぎます。表 36–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 に関連したエラーメッセージを示します。
表 36–11 に ASSERT エラーメッセージを示します。
表 36–11 ASSERT エラーメッセージ
エラーメッセージ |
説明または処置 |
---|---|
open() または fopen() が失敗した |
|
write()、fwrite()、fprint()、または類似のコマンドが失敗した |
|
read()、fgets()、または類似のコマンドが失敗した |
|
creat() 呼び出しが失敗した |
|
動的割り当てが失敗した |
|
LCK (ロック) ファイルを作成しようとしたが失敗した。場合によっては、これは重大なエラーとなる |
|
stat() 呼び出しが失敗した |
|
chmod() 呼び出しが失敗した |
|
link() 呼び出しが失敗した |
|
chdir() 呼び出しが失敗した |
|
unlink() 呼び出しが失敗した |
|
内部ロジックの問題 |
|
不良な C. ファイルまたは X. ファイルを、/var/spool/uucp/.Corrupt ディレクトリに移動しようとしたが失敗した。このディレクトリが存在しないか、モードまたは所有者が正しくない |
|
close() または fclose() 呼び出しが失敗した |
|
C. ファイルまたは D. ファイルを作成しようとしたが、そのファイルがすでに存在している。このエラーは、シーケンスファイルのアクセスに問題がある場合に生じる。これは通常、ソフトエラーを示す |
|
TCP/IP 呼び出しを試みたが、/etc/services 内に UUCP に関するエントリがない |
|
ユーザー ID がパスワードデータベース内にない。ネームサービス構成の検査が必要 |
|
前記と同じ |
|
Devices ファイル内に不良な行がある。引数が足りない行が 1 つ以上ある |
|
gename.c の内部テーブルがオーバーフローした。1 つのジョブが 30 を超えるシステムに接続しようとした |
|
前記と同じ |
|
失敗するはずのない ioctl(2) が失敗した。システムドライバに問題がある |
|
Devices ファイルまたは Systems ファイルの中に不適正な回線速度がある (Class フィールドまたは Speed フィールド) |
|
Permissions ファイルの中に不適正な行またはオプションがある。ただちに修正が必要 |
|
リモートマシンがハングアップした可能性がある。処置は不要 |
|
リモートマシンが回復不可能な状態で異常終了した。通常このエラーは無視できる |
|
内部的な問題がある。システムの購入先への問い合わせが必要 |
|
ファイル、またはディレクトリのどこかに問題が発生している。このプロセスが実行される前に、宛先のモードがチェックされるべきであるが実行されていないなど、スプールディレクトリに問題がある可能性がある |
|
fork と exec を実行しようとしたが失敗した。現行ジョブは失われず、後で再試行される (uuxqt)。処置は不要 |
表 36–12 に一般的な STATUS エラーメッセージを示します。
表 36–12 UUCP の STATUS エラーメッセージ
エラーメッセージ |
説明または処置 |
---|---|
状態は良好 |
|
現在、この呼び出し用に使用可能なデバイスがない。該当のシステムについて Devices ファイル内に有効なデバイスがあるかどうかを確認してください。そのシステムの呼び出しに使用するデバイスが Systems ファイル内にあるかどうかを検査してください |
|
Systems ファイルに指定されている日時以外の時点で、システムに対する呼び出しが行われた |
|
会話中 |
|
特定のマシンのログインが失敗した。ログインまたはパスワードが正しくないか、番号が正しくないか、低速のマシンであるか、Dialer-Token-Pairs スクリプトによる処理が失敗した |
|
起動に成功した後で対話が失敗した。一方の側がダウンしたか、プログラムが異常終了したか、回線 (リンク) が切断されたことが考えられる |
|
リモートマシンがまったく応答しない。ダイヤラが不良であるか、電話番号が正しくない可能性がある |
|
あるマシンが、Permissions ファイルの条件を満たしていないログインとマシン名を使用して、ローカルマシンを呼び出そうとした。偽装の疑いがある |
|
使用しようとしている呼び出しデバイスは、現在ロックされ、他のプロセスに使用されている |
|
ASSERT エラーが発生した。/var/uucp/.Admin/errors ファイルにエラーメッセージが入っているかどうかを検査し、UUCP の ASSERT エラーメッセージを参照 |
|
システムが Systems ファイルの中に記述されていない |
|
アクセスしようとしたデバイスが存在しないか、またはモードが正しくない。Systems ファイルと Devices ファイルの中の該当のエントリを検査する |
|
デバイスがオープンできない |
|
呼び出されたマシンは、予期したのとは異なる名前である |
|
呼び出されたマシンは、そのマシンがローカルマシンをコールバックする必要があることを示している |
|
リモートマシンは、ローカルマシンに関連する LCK ファイルを持っている。そのリモートマシンがローカルマシンを呼び出そうとしている可能性がある。そのマシンの UUCP のバージョンが古い場合は、プロセスがローカルマシンに接続しようとして失敗し、LCK ファイルがそのまま残されたことが考えられる。リモートマシンの UUCP のバージョンが新しく、ローカルマシンと通信していない場合は、LCK を持っているプロセスはハングする |
|
リモートマシンの Systems ファイルの中に、ローカルマシンのノード名がない |
|
ローカルマシンがログインのために使用したログインが、リモートマシンが予期している内容に一致していない |
|
理由は不明だが、リモートマシンがローカルマシンとの通信を拒否した。リモートマシンが標準バージョンの UUCP を使用していない可能性がある |
|
ログインは成功したが、初期ハンドシェークに失敗した |
|
通常、これは DIAL FAILED と同じ。しかしこのエラーが頻発する場合は、Dialers ファイル内の呼び出し側スクリプトに原因があることが考えられる。Uutry を使用して検査する |
表 36–13 に、/usr/include/sysexits.h ファイルにより生成されるエラー状態メッセージの終了コード番号を示します。これらのすべてが現在 uucp で使用されているわけではありません。
表 36–13 番号による 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 や /var/admin/utmpx などのシステムファイルのどれかが存在しないか、開くことができない。あるいは、構文エラーなどがある |
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 |
エラーメッセージの最大番号 |