サービスロケーションプロトコルの管理

第 7 章レガシーサービスの組み込み

通知に SLP を使用できるサーバーには、サービスおよび属性を直接 UA に、あるいは DA があれば DA に通知する内部 SA があります。レガシーサービスは、SLP の開発および実装が旧式になっているネットワークサービスです。たとえば、ラインプリンタデーモン (lpsched)、NFS ファイルサービス、NIS または NIS+ ネームサービスなどの Solaris サービスは、SLP で使用する内部 SA を持っていません。この章では、レガシーサービスを通知する場合およびその方法について説明します。

レガシーサービスを通知する場合

SLP UA を持つアプリケーションがネットワークに配置されていて、次のいずれかに当てはまる場合に、レガシーサービスの通知が求められることがあります。

ネットワーク上で、プリンタなど SLP が組み込まれていないハードウェアデバイスが使用可能であり、SLP UA を持つアプリケーションがそれらのデバイスを検出する必要がある時
ネットワーク上で、データベースなど SLP が組み込まれていないソフトウェアが使用可能であり、SLP UA を持つアプリケーションがそれらのソフトウェアを検出する必要がある時

レガシーサービスを通知する方法

レガシーサービスは、次の方法で通知できます。

SLP SA を組み込むようにサービスを変更する
サービスを通知するために、SLP SA として機能する小さなプログラムを書く
プロキシ通知を使用して、slpd にサービスを通知させる

サービスの変更

サービスがソフトウェアサーバーで、サービスのソースコードを使用できる場合は、サーバーに SLP SA を組み込むようソースコードを変更することができます。SLP 用の C API および Java API は比較的簡単に使用できます (C API のマニュアルページおよび Java API の Javadoc ページを参照してください)。サービスがハードウェアデバイスの場合は、製造元が SLP を組み込む PROM を更新していることがあります。詳細は、デバイスの製造元に問い合わせてください。

サービスを通知する SLP SA を書く

ソースコードや更新された SLP 用 PROM が使用できない場合は、サービスを通知する小さな SLP SA を書くことができます。この SA はサービスそのものと同じシェルスクリプトから起動する、小さなデーモンとして機能します。同様に、サービス制御シェルスクリプトは、この SA を停止することもできます。ここでも、C および Java 用の SLP API が、SLP へのプログラム的なアクセスを提供します。

SLP プロキシ登録を使用する

Solaris slpd は、プロキシ登録ファイルを使用したレガシーサービスの通知をサポートしています。プロキシ通知ファイルは、移植性のあるフォーマットで書かれたサービス通知のリストです。

サービス通知は、サービス URL 行、オプションのスコープ行、一連の属性の定義から構成されます。slpd はファイルからプロキシ通知を読み、その通知を登録し、SA クライアントと同じようにそれらを保持します。次のリストは、プロキシ登録ファイルの例を示します。行番号は説明のために付け加えたもので、ファイルの一部ではありません。

1  #Advertise legacy printer. 
2
3  service:lpr://bizserver/mainspool,en,65535
4  scope=eng,corp
5  make-model=Laserwriter II
6  location-description=B16-2345
7  color-supported=monochromatic
8  fonts-supported=Courier,Times,Helvetica 9 10
9 
10 #Advertise FTP server
11
12 ftp://archive/usr/src/public,en,65535,src-server
13 content=Source code for projects
14

この例では、LPR プロトコルをサポートするレガシーのプリンタおよび FTP サーバーが通知されています。

1 および 10 行	シャープ記号 (#) で始まるコメント行で、ファイルの動作には影響しない。コメント行の最後まですべてが無視される
2、9、14 の空行	通知の区切り
3 および 12 行	サービス URL
4 行	スコープの指定
5〜8 および 13 行	属性の定義

サービス URL

サービス URL 行には、3 つの必須フィールドと 1 つのオプションフィールドがあり、コンマで区切られています。

最初のフィールド - 通知されるサービスの URL が書かれる。サービス URL には、一般的な URL または service: URL のいずれかを使用できる。service: URL の指定方法の仕様については、RFC 2609 を参照
2 番目のフィールド - 通知の言語を指定する。前述の例では、フィールドは英語 en を指定している。この言語は RFC 1766 の言語タグである
3 番目のフィールド - 登録の有効期限を秒単位で規定する。有効期限は符号なしの 16 ビット整数に限定される。有効期限が最大値 65535 より小さい場合は、slpd は他の通知のように通知をタイムアウトする。有効期限が 65535 の場合、slpd は定期的に通知を更新し、slpd が存在する限り有効期限は永続するとされる

注 -
実際には、永続しないプロキシ登録は実用性が限られています。これは、いったん slpd が通知を削除すると、UA にアクセスできなくなるためです。例に挙げた通知は両方とも永続します。
サービスタイプフィールド (省略可) - サービスタイプの定義に使用する。サービス URL が一般的な URL の場合は、URL が通知されるサービスタイプを変更できる。前述のプロキシ登録ファイルの例では、12 行目に一般的な FTP URL が含まれていて、オプションの型フィールドを使用して、この URL はサービスタイプ名 src-server で通知される。デフォルトでは service: 接頭辞はタイプ名には付かない

スコープの指定

URL 行の後に、オプションのスコープ行があります。スコープ行はトークン scope と等号、およびコンマで区切られたスコープ名のリストで構成されます。このスコープ名は、net.slp.useScopes 構成プロパティで定義されたものです。ホストに構成されたスコープのリストに含まれるスコープのみ、このスコープリストに表示されます。スコープ行がない場合は、slpd が構成されているすべてのスコープに登録が行われています。スコープ行は URL 行のすぐ後になければなりません。その他の場所にある場合、スコープ行は属性として認識されます。

属性の定義

オプションのスコープ行の後は、サービス通知の大部分は属性と値リストのペアの行で構成されます。各ペアは属性タグ、等号、コンマで区切られた属性値のリスト (属性が単一値の場合は単一値) で構成されます。前述のプロキシ登録ファイルの例では、8 行目が複数の値を持つ値リストの例で、これ以外の値リストはすべて単一値を持っています。属性名および値のフォーマットは、ネットワークを通過する SLP メッセージと同じです。

フォーマットの説明については、RFC 2608 を参照してください。プロキシ登録ファイルは、ASCII でない文字のエスケープに、構成ファイルと同じ取り決めをサポートします。プロキシ登録ファイルのフォーマットについては、RFC 2614 を参照してください。

プロキシ登録を有効にする

プロキシ登録を有効にするために行う最初の手順は、プロキシ登録ファイルを作成することです。ファイルは、ホストのファイルシステムまたは HTTP でアクセス可能なネットワーク上のどこにでも置くことができます。このファイルを配置するには、/etc/inet ディレクトリの slp.conf ファイルにある net.slp.serializedRegURL プロパティを使用します (slp.conf(4)のマニュアルページを参照してください)。

プロキシ登録を作成する場合は、サービスについてサービスタイプのテンプレートが存在するかどうかを確認してください。サービスタイプのテンプレートは、サービスタイプに対するサービス URL および属性を記述したものです。テンプレートは、特定のサービスタイプについて何がサービス通知を構成するかを定義するので、テンプレートを使用することにより、UA および SA は相互運用が可能になります。サービスタイプテンプレートが存在する場合は、そのテンプレートを使用してプロキシ登録を構成してください。サービスタイプテンプレートについては、RFC 2609 を参照してください。

サービスについてサービスタイプテンプレートを使用できない場合は、サービスを正確に記述する属性の集合体を選択してください。さらに、デフォルトの命名権限は標準化されたサービスタイプについてのみ許可されているので、通知に対して、デフォルト以外の命名権限を使用してください。命名権限については、RFC 2609 を参照してください。

たとえば、BizApp という会社にローカルのソフトウェア欠陥領域データベースがあり、これを通知したいとします。この会社は、サービスタイプ service:bugdb.bizapp を持つ URL を作成して通知します。この場合、命名権限は bizapp です。

プロキシ登録ファイルが完成したら、そのファイルを読むように slpd を構成する必要があります。slp.conf ファイルを編集して次の行を追加します。

net.slp.serializedRegURL=<proxy registration file URL>

ここにはファイル名を追加するのではなく、ファイルの場所を示す URL を追加します。たとえば、一連の登録ファイルの名前が slp.reg で、これがローカルの /net/inet ディレクトリにある場合、次のように URL プロパティを構成します。

net.slp.serializedRegURL=file:/etc/inet/slp.reg

レガシーサービスを通知する場合の検討事項

通常、SLP を追加する場合、スタンドアロンの SA を作成したりプロキシ登録を使用したりするよりも、ソースコードを変更する方が望ましい方法です。ソースコードを変更することにより、サービス固有の機能を追加したり、サービスの使用可否を綿密に追跡したりできます。ソースコードが使用できない場合は、プロキシ登録を使用するよりもスタンドアロンの SA を書く方が望ましい方法です。スタンドアロンの SA をサービスの開始または停止手順に組み込むことにより、SA はサービスの使用可否を追跡することができます。プロキシ通知は通常、ソースコードが使用できず、スタンドアロンの SA を書くことが実際的ではない場合の 3 番目の選択肢です。

プロキシ通知は、プロキシ登録ファイルを読み取る slpd が動作している間のみ保持されます。通知がタイムアウトしたり slpd が停止したりすると、プロキシ通知は使用できなくなります。ただし、プロキシ通知とサービスの間には直接的な関係はありません。

サービスが停止した場合は、slpd を停止し、直列化登録ファイルを編集してプロキシ通知をコメントアウトするか削除し、slpd を再起動してください。サービスを再起動または再インストールしたときは同じ手順に従ってください。レガシー通知の他の 2 つの技術と比べた場合、プロキシ通知とサービスの間に関係のないことがプロキシ通知の主な欠点です。

第 7 章 レガシーサービスの組み込み