3    ネーム・スペースの管理

ネーム・スペースには,作成したオブジェクト (スプーラ,スーパバイザ,論理プリンタと物理プリンタ,キュー) の名前およびネットワーク・アドレスが含まれています。それぞれのオブジェクトに対するネーム・サービス・エントリには,オブジェクトをサポートするサーバのアドレスが入っている情報が含まれています。

クライアントとサーバは,ネーム・サービス機能を使用して,指定されたネットワーク・オブジェクトをサポートするサーバの場所を特定し,そのサーバをバインドします。クライアントまたはサーバは,プリンタ名またはサーバ名のバインドを必要とするときに,ネーム・サービスを使用してこの情報を取得します。ネーム・サービスは要求された名前を検索し,要求されたバインディングをクライアントに戻します。RPC メカニズムが,戻されたバインディングを使用してサーバに接続します。

プリント・システムは次のネーム・サービスをサポートします。

3.1    ローカル・ファイル・ネーム・サービス

ローカル・ファイル・ネーム・サービスは,単一のスタンドアロン・システム構成でも,あるいは分散環境でも作動します。

スタンドアロン構成では,クライアントとサーバ (スプーラとスーパバイザ) は同一のワークステーション上に存在します。管理者がプリント・オブジェクトを作成すると,ネーム・サービスはそのバインディング情報をただちに利用可能にします。プリント・オブジェクトを削除すると,ネーム・サービスはそのバインディング情報をただちに削除します。

ローカル・ファイル・ネーム・サービスは,/etc/printers.conf ファイルにプリンタ・バインディング情報を格納します。このファイルの別個のインスタンスがそれぞれのホスト・システム上に存在します。プリント・システムは,複数のホストによる単一の /etc/printers.conf ファイルの共用をサポートしません。次に示すのは,printers.conf ファイルの例です。

#
#	If you hand edit this file, comments and structure may change.
#
bulldog_sup:\
:saddr=bulldog.gandalf.xyz.com,105004,1,sys,sv,bulldog_sup,1:
bulldog_spl:\
:saddr=bulldog.gandalf.xyz.com,105004,1,sys,sl,bulldog_spl,1:
bulldog1:\
:paddr=bulldog.gandalf.xyz.com,105004,1,sys,pp,bulldog_sup,1:
bulldog_q:\
:qaddr=bulldog.gandalf.xyz.com,105004,1,sys,qu,bulldog_spl,1:
bulldog_log:\
:paddr=bulldog.gandalf.xyz.com,105004,1,sys,lp,bulldog_spl,1:\
:spooling-type=dpa:
cc3:\
:paddr=bulldog.gandalf.xyz.com,105004,1,sys,pp,bulldog_sup,1:

サーバのスタートアップ・プロセスは,サーバがエントリをローカル・ファイルに追加しようとしたときにファイルが存在しない場合には,printers.conf ファイルを自動的に生成します。また,サーバはオブジェクト・データベースの内容をローカル・ファイルと比較して,オブジェクトがオブジェクト・データベースにはあるのにローカル・ファイルにはないときには,そのオブジェクトを追加します。

オブジェクト作成処理は,操作を実行したホスト上のローカル・ファイルだけを更新するので,その情報は他のホスト上のクライアントやサーバでは利用できません。このため,分散環境でローカル・ファイル・ネーム・サービスを使用するときには,あらかじめ構成ファイルを作成して,クライアントやサーバを実行するすべてのホストにそれをコピーしてください。

printers.conf ファイルは,エディタで作成したり,単一のホストからすべてのプリント・オブジェクトを作成することで作成したりできます。ただし,後者の場合,作成操作でサーバを作成していないので,それぞれの異なるホストについてサーバ・エントリを手動でファイルに追加する必要があります。オブジェクトを削除する場合には,すべてのホスト上にあるファイルを更新しなければなりません。

ローカル・ファイルのネーミングには,以下が必要になります。

3.2    ネットワーク情報サービス

ネットワーク情報サービス (NIS) は,ローカル・ファイル・ネーム・サービス用のプリンタ構成エントリと同じフォーマットを使用します。ただし,NIS は同一のプリンタ構成データを 1 つの NIS ドメイン全体で管理し,配信する手段を提供します。

ローカル・ファイル・ネーム・サービスの使用と NIS の使用の最も重要な相違点は,プリント・システムが NIS エントリを変更できないということです。代わりに,管理者は,NIS ファイルにある NIS エントリを手動で更新する必要があります。NIS ファイルへの変更権限か,あるいは,変更を行う権限のあるプロキシ管理者が必要です。

NIS ネーム・サービスでは,構成変更に連係した更新が必要になります。つまり,NIS ファイルにオブジェクト名を追加してからプリント・システム・オブジェクトを作成する必要があります。ただし,複数のホストそれぞれにあるローカル・ファイルを更新する必要のあるローカル・ファイル・ネーム・サービスの場合とは異なり,NIS ではデータの更新が必要になるのは 1 箇所だけです。

プリンタ,サーバ,キューの名前と場所を,NIS クライアントとして設定されたホストに配信するには,プリント・システム・サーバ・プロセスを実行するホストから 1 つ以上の printers.conf ファイルを集めて,それらを /var/yp/src/printers.conf のマスタ・マップ・ファイルに格納する必要があります。テキスト・エディタを使用して,これらのファイルをマージしてもかまいません。結果として生成したファイルでエントリが重複している場合には,テキスト・エディタを使用して重複部分を削除してください。

マスタの printers.conf ファイルを作成した後に,次の手順を使用して,NIS サーバ上の NIS マップを更新してください。

  1. root としてログインします。

  2. まだコピーを行っていない場合には,/usr/pd/scripts/Makefile.printers /var/yp/Makefile.printers にコピーします。このファイルのコピーを編集して,DOM 変数で NIS ドメインを定義します。

  3. 現在のディレクトリを /var/yp/src に設定します。

  4. 関連するすべての printers.conf ファイルを,それぞれに一意な名前を付けて,さまざまなホストから現在のディレクトリにコピーします。

  5. テキスト・エディタを使用して,これらのファイルの内容を新しいマスタの printers.conf ファイルにマージします。

  6. 現在のディレクトリを /var/yp に変更します。

  7. printers.conf (または "すべての") ターゲットを指定して Makefile.printers ファイルを実行することにより,プリンタ・マップを再作成して配信し直します。

  8. 新しい printers.conf マップが利用可能であることを確認します。

次の例はこの手順を示しています。

# cp /usr/pd/scripts/Makefile.printers /var/yp/Makefile.printers
# cd /var/yp/src
# mv printers.conf printers.conf.<date>
# cp /etc/printers.conf ./ 
# cat printers.conf.host1 printers.conf.host2\
 printers.conf > printers.conf
# cd ..
# make -f Makefile.printers
updated printers.conf
pushed printers.conf 

次のコマンドを使用して,新しい printers.conf エントリを検索できることを確認してください。

# ypcat printers.conf.byname

このコマンドを実行すると,次に示すような出力が生成されます。各行が,マスタ・マップにリストされているそれぞれのサーバ,プリンタ,キューの情報を示しています。

WS_sharie_PP:paddr=wstent.gandalf.xyz.com,105004,1,sys,pp,wstent_sup,1:
ws_lg_queue:qaddr=wstent.gandalf.xyz.com,105004,1,sys,qu,wstent_spl,1:
WS_cross_PP:paddr=wstent.gandalf.xyz.com,105004,1,sys,pp,wstent_sup,1:
WS_cress_PP:paddr=wstent.gandalf.xyz.com,105004,1,sys,pp,wstent_sup,1:
wstent_sup:saddr=wstent.gandalf.xyz.com,105004,1,sys,sv,wstent_sup,1:
ws_lg04_pp:paddr=wstent.gandalf.xyz.com,105004,1,sys,pp,wstent_sup,1:
glypha_spl:saddr=glypha.gandalf.xyz.com,105004,1,sys,sl,glypha_spl,1:
glypha_obg:saddr=glypha.gandalf.xyz.com,105004,1,sys,sv,glypha_obg,1:
WSQ1:qaddr=wstent.gandalf.xyz.com,105004,1,sys,qu,wstent_spl,1:
BigLinePrinter:paddr=wstent.gandalf.xyz.com,105004,1,sys,lp,wstent_spl,1: :spooling-type=dpa:
wstent_spl:saddr=wstent.gandalf.xyz.com,105004,1,sys,sl,wstent_spl,1:
ws_test_lp:paddr=wstent.gandalf.xyz.com,105004,1,sys,lp,wstent_spl,1: :spooling-type=dpa:
WS_lps:paddr=wstent.gandalf.xyz.com,105004,1,sys,lp,wstent_spl,1: :spooling-type=dpa:

一般に,オブジェクト (サーバ,プリンタ,キュー) を作成したり,削除したりしたときにはいつでも,プリント・システム・クライアントが使用されるホスト上のネーム・スペースを更新する必要があります。NIS ベースのネーム・サービスでは,クライアントがサイトの NIS サーバから最新のマップを読み取るので,これは自動的に発生します。

また,他のサーバ・ホストと通信するサーバ・マシン上のネーム・スペースを更新する必要もあります。たとえば,ホスト A 上のスプーラがホスト B 上にあるプリンタに供給するキューを持つ場合,ホスト A とホスト B の両方にあるネーム・スペースは,互いのオブジェクトに対するエントリを含む必要があります。プリント・システム・サーバ・ホストがドメインの NIS サーバではない場合,その printers.conf ファイルのコピーを NIS サーバに転送し,そのプリンタ構成を変更したときにはいつでも printers.conf マップをプッシュする必要があります。

NIS マップが既にオブジェクトを含んでいるとき,(pddelete コマンドを使用して) そのオブジェクトを削除し,次に,同じオブジェクトを (pdcreate コマンドを使用して) もう一度作成した場合,そのオブジェクトはローカル・ファイル・ネーム・スペースでは削除されます。これは,その名前が既に NIS ネーム・スペース内に存在するためであり,サーバは既にエントリが存在する場合には,新しいネーム・スペース・エントリを作成しません。このため,次に収集とプッシュを行うときにネーム・スペース・エントリを失う可能性があるので,オブジェクトを削除し再作成するときには十分注意してください。このような状況を回避するには,次の 2 つの方法があります。

  1. オブジェクトを削除した直後と,オブジェクトを再作成した直後に NIS マップの収集とプッシュを行う。

  2. printers.conf ファイルと NIS ネームスペースの現在のスナップショットをマージしてから,NIS マップをプッシュする。

    # cd /var/yp/src
    #ypcat printers.conf.byname > printers.conf.NIS
    #cat /etc/printers.conf printers.conf.NIS > printers.conf
    

結果として生成された printers.conf ファイルの重複部分や古くなったエントリを削除してエントリを調整してから,前の例で説明したようにMakefile.printers ファイルを使用してマップを更新してください。

3.3    LDAP ネーム・サービス

LDAP は,プリント・オブジェクトが作成または削除される場合に,ネーム・スペースを動的に更新する機能を NIS に提供します。この節では,LDAP クライアントを設定するための必要事項について説明します。

LDAP クライアントを設定するには,次のことを行う必要があります。

3.3.1    apx.conf ファイルの作成と編集

/var/pd/config/apx.conf ファイルは,ユーザが使用するネーム・サービスに関する情報および LDAP ディレクトリ・サービスを実行するホスト・システムに関する情報を含んでいます。次に,/var/pd/config/apx.conf ファイルの 1 例を示します。

 name-services = file nis ldap
  LDAP_hosts  = system.abc.xyz.com 
  LDAP_path   = ou=organizational unit,o=organization

3.3.2    LDAP クライアントのユーザ名とパスワードの作成

Advanced Printing サーバで LDAP サーバ上のネーム・エントリを変更するにはユーザ名パスワードが必要です。ユーザ名パスワードは,apx.conf ファイルで LDAP_hosts を定義してから作成する必要があります。

pdldappw コマンドでユーザ名とパスワード作成します。

# /usr/sbin/pdldappw

このコマンドは,/var/pd/config/apx.conf ファイル中の現在の設定を表示し,ユーザ ID およびパスワードの入力を促します。

Contents of configuration file /var/pd/config/apx.conf:    
name-services = ldap   
LDAP-path=ou=advprint,o=Organization 
LDAP-hosts=toons.xyz.ayy.com  
LDAP User ID: advprintid 
LDAP password: *********

3.4    プロトサーバ

プロトサーバは,ネーム・サービスとともに動作して,サーバ・プロセスがプリント・システム・オブジェクトの名前やバインディング情報にアクセスできるようにするプリント・システム・デーモンです。

プロトサーバはプリント・システム内の 1 次 RPC サーバとして働きます。リモート・ホスト上のクライアントとサーバは,サーバ・ホスト上のプロトサーバとやりとりして,他のプリント・システム・サーバ・プロセス用の RPC バインディング情報を調べます。

プリント・システム・インストレーション・プロシージャは,ネーム・サービスが自動的にプロトサーバを実行できるように /etc/inetd.conf ファイルに次の行を追加します。

105004/1 dgram rpc/tcp wait nobody /usr/sbin/rpc.pts\ rpc.pts

3.5    TruCluster Server 環境における高可用性アプリケーションとしての Advanced Printing Software

Advanced Printing Software は,TruCluster Server 環境の高可用性シングル・インスタンス・アプリケーションとして実行するように構成できます。シングル・インスタンス・アプリケーションは,クラスタのただ 1 つのメンバ上でのみインストール,構成,および実行されますが,クラスタの全メンバで使用することができます。

高可用性シングル・インスタンス・アプリケーションは,TruCluster Server の CAA (Cluster Application Availability) サブシステムを使用するように構成されます。CAA は,クラスタ中の Advanced Printing Software に必要なリソースを監視し,これらのリソースの要求に合うクラスタ・メンバ上で実行するようにします。Advanced Printing Software の実行が失敗したり,リソースの要求が失敗した場合,CAA は Advanced Printing Software を要求されたリソースを持つ他のメンバに再割り当て, つまりフェイルオーバします。

高可用性シングル・インスタンス・アプリケーションとして Advanced Printing Software を構成し,実行するには次の準備が必要です。

これらの項目については,以降の各項で説明します。詳細については,『TruCluster Server 高可用性アプリケーション・ガイド』を参照してください。

3.5.1    リソース・プロファイル

リソース・プロファイルでは,CAA によるアプリケーションの起動,管理,および監視方法を定義します。

Advanced Printing Software サーバのサブセット (APXSERVERxxx) を構成するときには,システムに TruCluster ソフトウェアがインストールされているかどうかを判断します。TruCluster Server がインストールされている場合には,構成スクリプトは /var/cluster/caa/profile ディレクトリ中に CAA リソース・プロファイル apx-default.cap をインストールします。これは,プリント環境で動作するサーバおよびスーパバイザを示すリソース・ファイルです。

3.5.2    処理スクリプト

処理スクリプトは,アプリケーションの起動方法,アプリケーションの停止およびフェイルオーバ前のクリーンアップ方法,およびアプリケーションが実行中であるかどうかの確認方法を指定します。

Advanced Printing Software のインストール中に,TruCluster Server ソフトウェアが検出された場合,構成スクリプトは処理スクリプト /var/cluster/caa/script/apx-default.scr をインストールします。

3.5.3    リソースの登録

リソース・プロファイルと処理スクリプトのインストール後,リソースを CAA に登録する必要があります。リソースを登録するには,caa_register コマンドを使用します。

# /usr/sbin/caa_register apx-default

3.5.4    リソースの起動と停止

apx-default を CAA に登録すると,caa_start コマンドを使用してアプリケーションを実行できます。

# /usr/sbin/caa_start apx-default

アプリケーションが起動されると次のようなメッセージが表示されます。

Attempting to start `apx-default` on member `membername`
Start of `apx-default` on member `membername` succeeded.

アプリケーションを停止するには,caa_stop コマンドを使用します。

# /usr/sbin/caa_stop apx-default

3.5.5    apx-default リソースへのサーバの追加

Advanced Printing Software アプリケーションが最初にクラスタ環境で動作した後,別のスプーラおよびスーパーバイザが必要になる場合があります。追加するスプーラおよびスーパーバイザを作成および起動します。/usr/pd/scripts/pd_get_started スクリプトまたは pdmakedbpdsplr および pdspvr コマンドを使用できます。サーバが作成され,起動されると,自動的に apx-default リソースに追加されます。

3.5.6    Advanced Printing クラスタ環境のカスタマイズ

3.5.6.1    リソースの再配置

アプリケーションのリソースを再配置するには, caa_relocate コマンドを使用します。リソースを再配置したいクラスタ・メンバを指定したり,CAA が利用可能なメンバを判断できるようにします。次の例は,caa_relocate コマンドを使用してリソースを再配置する方法を示します。

# caa_relocate apx-default -c daffy

次のメッセージがこのコマンドの応答として表示されます。

Attempting to stop `apx-default` on member `goofy`
Stop of `apx-default` on member `goofy` succeeded.
Attempting to start `apx-default` on member `daffy`
Start of `apx-default` on member `daffy` succeeded.

アプリケーションのリソース・プロファイルで定義した配置ポリシに従ってリソースを再配置するには,オプションを指定しないで caa_relocate コマンドを使用します。

# caa_relocate apx-default

3.5.7    1 つのメンバ上で実行するプリンタの構成

クラスタの 1 つのメンバだけがアクセスできるようにプリンタを構成できます。このプリンタは,通常,特定のクラスタ・メンバに直接接続されています。

printer-associated-host 属性で指定されているものとは異なるホスト上で実行されているスーパーバイザからプリンタにジョブが送られてくる場合,スーパーバイザは物理プリンタを利用できないため,次の属性を設定します。

3.5.8    クラスタにおける LPD インバウンド・ゲートウェイ

LPD インバウンド・ゲートウェイは CAA アプリケーションとして構成されませんが,クラスタの各メンバ上で実行できます。LPD インバウンド・ゲートウェイを構成するには,/usr/pd/scripts/inbound_gw_config.sh スクリプトを実行します。このスクリプトは,クラスタの各メンバに LPD インバウンド・ゲートウェイを構成し,rc.config ファイルを修正します。rc.config ファイルの修正は,システムが再起動するたびに LPD インバウンド・ゲートウェイを再起動するために必要です。

LPD インバウンド・ゲートウェイを手動で起動するには,/sbin/init.d/apxstart コマンドと stop コマンドを使用します。