test

Sun Desktop Manager 1.0 インストールガイド

第 3 章 クライアントコンポーネント

Desktop Manager から構成データにアクセスするには、デスクトップクライアントに Java Desktop System Configuration Agent が必要になります。Configuration Agent は、リモートの構成データリポジトリおよびアダプタと通信すると同時に、データを特定の構成システムに統合します。現在サポートされている構成システムは、GConf、Java Preferences、Mozilla Preferences、および StarSuite Registry です。

あるバージョンの Configuration Agent が Solaris 10 オペレーティングシステムに付属しています。しかし、Desktop Manager では、そのツールのより新しいバージョンが必要になります。その新しいバージョンは、Desktop Manager クライアントコンポーネントおよび関連するパッチの設定の一部としてインストールされます。

Desktop Manager クライアントコンポーネントをインストールするには

  1. Desktop Manager zip アーカイブをダウンロードし、その内容を一時ディレクトリに取り出します。


    # unzip SunDesktopMgr-1.0.zip

  2. 推奨パッチをインストールします。

    これらのパッチは、SunDesktopMgr-1.0/<platform>/client/Patches ディレクトリにあります。パッチごとに指定されるインストール手順に従います。

  3. スーパーユーザー (root) になって、次のように設定スクリプトを実行します。


    # cd SunDesktopMgr-1.0/<platform>/client
# ./setup

Configuration Agent

Configuration Agent は、次の表に示す各種のパッケージに含まれています。

Solaris のパッケージ名 

説明 

SUNWapbas 

構成共有ライブラリ 

SUNWapmsc 

Configuration Agent に関するその他のファイル 

SUNWapoc 

Configuration Agent 

SUNWapdc 

Configuration Agent ウィザード 

上記のパッケージをインストールすると、この API に必要なファイルもインストールされます。このパッケージは手作業でも Java Desktop System インストール経由でもインストールできます。インストール後は、自分のシステム上で Configuration Agent を構成および有効にする必要があります。

注 –

Configuration Agent パッケージは、Java Desktop System インストールで Solaris の一部としてインストールされますが、Desktop Manager は、適切なレベルの機能を提供するために、インストール中にこれらのファイルにパッチをあてます。

リモートの構成データにアクセスするには、Configuration Agent に最小限のブートストラップ情報 (LDAP サーバーのホスト名やポートなど) が必要です。この情報は、policymgr.properties、apocd.properties、os.properties などのプロパティーファイルの集合として保守されます。これらの属性ファイルはローカルの /etc/apoc ディレクトリに格納されます。これらのプロパティーファイル (付録 A 「構成パラメータ」 参照) は手動でも、Configuration Agent の構成ウィザードでも編集できます。

この構成ウィザードは、グラフィカルユーザーインタフェースを提供し、これに従って Configuration Agent に必要な設定ができます。このウィザードのすべてのページで、対応するヘルプ画面が利用できます。このウィザードを起動するには、スーパーユーザー (root) として /usr/bin/apoc-config スクリプトを実行します。

注 –

ウィザードはグラフィカルインタフェースを起動しなくても起動できます。たとえば、/usr/bin/apoc-config -nodisplay を実行すると、ウィザードはコンソールモードで起動します。

ブートストラップ情報

図 3–1 Configuration Agent、構成リポジトリ

構成リポジトリと状態

注 –

対応するプロパティーファイルキーを括弧内に示しています (適切な場合)。

図 3–2 Configuration Agent、LDAP 階層とファイルベースの記憶領域

LDAP 階層とファイルベースの記憶領域

注 –

図 3–2 の画面は、前の画面で選択した「リポジトリタイプ」により異なります。「LDAP」または「ハイブリッド」リポジトリタイプを選択した場合、「サーバー識別子」、「サーバーポート」、および「サフィックス」が必須です。「ファイルベース」または「ハイブリッド」リポジトリタイプを選択した場合、「構成設定 URL」が必須です。

図 3–3 Configuration Agent、認証機構

認証

ポートの設定

Configuration Agent は、次の 2 つのポートを使用します。

図 3–4 Configuration Agent、ポートの設定

Configuration Agent、ポートの設定

変更検出間隔

Configuration Agent は、次の 2 つの間隔を使用して、構成データに変更があるかどうかを定期的にチェックします。

汎用の検出間隔を使用すると、リモートの構成データの変更をクライアント側のアプリケーションに伝播する間隔を調整できます。この設定で指定する値は、リモートに加えられた変更の内容がクライアントアプリケーションに反映されるまでの最大期間（分）です。

この値が小さくなるほど、Configuration Agent と LDAP サーバーの活動が増えます。したがって、この設定値を調整する場合は注意が必要です。たとえば、最初の配備段階でこの値を 1 分に設定すれば、クライアントアプリケーションに対するリモート構成の影響を簡単にテストできます。テストが完了したら、この設定を初期値に戻します。

操作設定

図 3–5 Configuration Agent、データディレクトリ

Configuration Agent、データディレクトリ

次の設定が構成できます。

図 3–6 Configuration Agent、要求の処理とロギング

Configuration Agent、要求の処理とロギング

注 –

ほとんどの操作設定 (「データディレクトリ」と「接続タイムアウト」の設定を除く) は、LDAP サーバーに格納された対応するポリシー経由で集中的に保守できます。この機能を使用する場合は、対応する設定をウィザードで変更しないでください。代わりに、Desktop Manager 内の Configuration Agent ポリシーを使用して、操作設定を集中的に指定します。

エージェント設定の適用

Desktop Manager を使用して LDAP サーバーに格納した操作設定 (「データディレクトリ」と「接続タイムアウト」の設定を除く) は、エージェント構成の次回の変更検出サイクルで自動的に適用されます (DaemonChangeDetectionInterval を参照)。

図 3–7 Configuration Agent、設定の要約ページ

設定の要約ページ

ローカルで変更したその他の設定については、Configuration Agent を再読み込みまたは再起動する必要があります。構成ウィザードを使用する場合、再読み込みまたは再起動は自動的に実行されます。

注 –

Configuration Agent を手作業で再起動するには、関連するクライアントアプリケーションが動作していないことを確認し、root としてログインして、コマンド /usr/lib/apoc/apocd restart を入力します。

エージェントの追加設定

注 –

次の設定は、構成ウィザードでは設定できません。

ローカルポリシーの使用

Configuration Agent を構成して、全体的なポリシーに加えてまたは代替として、ローカルで配備されたポリシーから構成設定を適用することができます。次の手順に従って、このようなローカルポリシーを配置します。

Procedureローカルポリシーを配置する

手順

  1. Desktop Manager を使用して、必要なポリシー設定でプロファイルを作成します。

  2. Desktop Manager を使用して、zip ファイルにプロファイルをエクスポートします。

  3. クライアントホスト上で、${DataDir}/Policies/profiles/PROFILE_REPOSITORY_default ディレクトリをまだ存在していない場合は、作成します。

    ${DataDir} は、デフォルトで /var/opt/apoc になる Configuration Agent のデータディレクトリの値を表します。

  4. 前にエクスポートした zip ファイルを ${DataDir}/Policies/profiles/PROFILE_REPOSITORY_default にコピーします。

  5. 使用可能なローカルポリシーを適用するように Configuration Agent が構成されていることを確認します。詳細は、「エージェントの追加設定」 を参照してください。

    注 –

    Configuration Agent の「ApplyLocalPolicy」設定を変更した場合、root としてログインし、/usr/lib/apoc/apocd reload コマンドを入力して、Configuration Agent を再起動する必要があります。

    この方法で配置されたローカルポリシーは、Configuration Agent による次の変更検出サイクル中にクライアントが使用できるようになります。

Configuration Agent の自動起動

障害の発生時に、Configuration Agent は自動的に再起動されます。サービス管理機能 (smf(5)) により、この決定がなされます。すでに数多くの障害が発生している場合など、再起動が不適切であるとサービス管理機能が判断すると、Configuration Agent は保守モードになります。

Configuration Agent が再起動しない場合は、root としてログインし /usr/lib/apoc/apocd disable コマンドを実行してエージェントを一時的に無効にして、エージェントに障害を発生させた問題を修正し、/usr/lib/apoc/apocd enable コマンドを実行してエージェントを再度有効にしてください。

データアクセス/ユーザー認証

Configuration Agent は、デスクトップユーザーのログイン ID に基づいて LDAP サーバーから情報を取得します。組織のマッピングファイルの User/UniqueIdAttribute 設定により、ログイン ID と、LDAP サーバー内のユーザー要素がマッピングされます。Configuration Agent はまた、ホストについての情報 (ホストの名前と IP アドレスなど) を取得します。この情報は、組織のマッピングファイルの Host/UniqueIdAttribute 設定により、LDAP サーバー内のホスト要素にマッピングされます。組織のマッピングの詳細は、付録 C 「組織のマッピング」 を参照してください。

LDAP サーバーにアクセスする場合、匿名または GSSAPI の 2 つの方法があります。匿名アクセスでは、デスクトップ上での処理は必要ありません。GSSAPI 方式では、デスクトップ上で Kerberos 資格情報を取得する必要があります。Kerberos 資格情報とユーザーログインの取得を統合するには、pam_krb5 モジュールを Java Desktop System ホストにインストールおよび構成する必要があります。

gdm を使用して Kerberos とユーザーログインを統合できます。たとえば、次のように /etc/pam.d/gdm ファイルを使用します。


#%PAM-1.0
auth   required    pam_unix2.so  nullok #set_secrpc
auth   optional  pam_krb5.so use_first_pass missing_keytab_ok ccache=SAFE putenv_direct
account required    pam_unix2.so 
password required    pam_unix2.so  #strict=false
session required    pam_unix2.so  # trace or none
session required    pam_devperm.so 
session optional    pam_console.so

このように Kerberos をユーザーログインに統合する場合は、スクリーンセーバーの Kerberos サポートを有効にするとよいでしょう。たとえば、次のように /etc/pam.d/xscreensaver ファイルを使用します。


auth required pamkrb5.so use_first_pass missing_keytab_ok 
ccache=SAFE putenv_direct

アダプタ

アプリケーションアダプタは、Desktop Manager がサポートする構成システムの拡張機能です。アダプタにより、各種アプリケーションは、構成システムに応じて、中央の構成データを取り入れることができます。次の構成システムがサポートされます。

ユーザーのデスクトップにデスクトップランチャー、メニュー項目、および起動プログラムを追加する、デスクトップ定義アダプタも提供されます。

GConf アダプタ

GConf アダプタは、Solaris 用 SUNWapoc-adapter-gconf パッケージに含まれます。該当する packageAdapter からアダプタをインストールすると、/etc/gconf/2/path にある GConf データソースパスは Desktop Manager ソースを含むように更新されます。アダプタから提供される 2 つのデータソースは、次のとおりです。

GConf アダプタの構成

GConf アダプタはインストールの一部として構成されますが、その操作は、必須の中央設定とデフォルト設定を表す 2 つのデータソースが GConf パスファイル (/etc/gconf/2/path) に存在するかどうかによって異なります。このパスファイルには、システムのインストール後に GConf が予期したとおりに中央設定を取り入れるための適切な情報が含まれていますが、管理者は、そのパスを変更して追加のカスタムソースを含める必要がある場合は、「apoc」の接頭辞が付けられたデータソースがファイル内にまだ存在していることを確認します。また、データソースが、必須の中央設定を表すデータソースに対してローカルの必須設定とユーザー設定の間に配置され、デフォルトの中央設定を表すデータソースに対してユーザー設定とローカルのデフォルト設定の間に配置されていることも確認する必要があります。

Java Preferences アダプタ

Java Preferences アダプタは、Solaris 用 SUNWapcj パッケージに含まれます。

Java Preferences アダプタの構成

Java Preferences アダプタは、JRE が提供するデフォルトのファイルベースシステムなどほかの既存の実装に対してラッパーとして使用される必要がある Preferences API の実装として提供されます。Preferences API を利用する Java アプリケーションで中央構成を使用できるようにするには、ヘルパーとして /usr/lib/apoc/apocjlaunch スクリプトを使用して、そのアプリケーションの起動スクリプトを作成する必要があります。このスクリプトには、2、3 の環境変数を指定して、必要な環境で Java アプリケーションを起動する apocjlaunch スクリプトを最後に含める必要があります。次の環境変数を設定する必要があります。

次の省略可能な追加の環境変数を設定できます。

Mozilla アダプタ

Mozilla アダプタは、Solaris 用 SUNWmozapoc-adapter パッケージに含まれます。

Mozilla アダプタの構成

Mozilla アダプタは、この製品のインストールの一部として設定され、追加で構成する必要はありません。

StarSuite アダプタ

StarSuite アダプタは標準の StarSuite インストールに含まれています。これにより、特殊な変更を加えることなく、プロファイル構成データにアクセスできます。

StarSuite アダプタの構成

StarSuite アダプタは、この製品のインストールの一部として設定され、追加で構成する必要はありません。

Desktop Definition アダプタ

Desktop Definition アダプタは、次のパッケージで構成されます。

パッケージ名 

説明 

SUNWapleg 

構成アクセスバイナリ 

SUNWardsa 

デスクトップ定義アダプタ 

SUNWardsa-misc 

アダプタ用システム統合 

これらのパッケージは、Desktop Manager クライアントコンポーネントのインストール時にインストールされ、追加で設定する必要はありません。

Desktop Definition アダプタの構成

Desktop Definition アダプタは、ユーザーがログインするたびに使用される設定処理によって構成され、追加で設定する必要はありません。

アダプタの削除

Mozilla アダプタと StarSuite アダプタは、これらの製品が削除されると削除されます。GConf、Java Preferences、および Desktop Definition アダプタは、適切なパッケージ管理システムツールを使用して、インストールのセクションで説明したパッケージを削除することで削除できます。

Java Preferences アダプタを削除した場合、Preferences API を使用する Java アプリケーションを起動するために作成された起動スクリプトは使用しないでください。いくつかの必要なクラスが使用できなくなるため、起動スクリプト内の Java の起動が失敗します。

アダプタのトラブルシューティング

対応するアプリケーションで中央の構成データが表示されない原因となる問題の大部分は、Configuration Agent に起因する可能性があります。これは、データを取得するためにすべてのアダプタが使用する共通のメカニズムであるためです。

中央構成の変更が特定の設定 (またはそのグループ) に対して効果がない場合、ユーザーが、通常は製品の「オプション」ダイアログや「設定」ダイアログを使用して、アプリケーション内のその設定に対して明示的に値を設定していることが考えられます。この場合、中央設定をプロテクトとして、つまり管理者が設定してユーザーは変更できないように定義されないかぎり、ユーザー設定は、Desktop Manager を使用して設定された値よりも優先度が高くなります。

Configuration Agent のトラブルシューティング

このセクションでは、Configuration Agent の性質と動作に関してユーザーが抱く可能性がある疑問と、エージェントの問題のトラブルシューティングを行うためのいくつかの注意事項について説明します。

質問と回答

Configuration Agent とは何ですか、またその動作はどのようなものですか

Configuration Agent は、ポリシーをキャッシュし配信するアプリケーションです。アプリケーションとそれが実行されるホストの性能に重大な影響を与えずに、デスクトップクライアントアプリケーションを確実に一元的に構成できるように設計され構築されています。この機能は、次のことにより達成されます。

クライアントアプリケーションと Configuration Agent との間で対話が発生する典型的なシナリオは、非常に単純で、次のように説明できます。

  1. ユーザーが、gconfd、Mozilla、StarSuite など、関連するデスクトップクライアントアプリケーションの 1 つを起動します。

  2. クライアントアプリケーションが Configuration Agent に接続します。

  3. クライアントアプリケーションは、Configuration Agent から必要とするポリシーデータを要求します。

  4. Configuration Agent は、要求されたポリシーデータを探してキャッシュを検索します。

  5. ポリシーデータがキャッシュ内に見つからなかった場合、Configuration Agent は、事前に構成されたポリシーリポジトリから要求されたデータをダウンロードして、キャッシュに格納します。

  6. ポリシーデータは、要求を行なったクライアントアプリケーションに送信されます。

  7. Configuration Agent は、ポリシーデータに対する変更についてポリシーリポジトリを監視します。

  8. 変更が検出されると、Configuration Agent はキャッシュをリフレッシュして、最新の状態にし、クライアントアプリケーションに変更があることを知らせます。

Configuration Agent を入手してインストールするにはどのようにするのですか

Configuration Agent は、Solaris 10 にデフォルトで付属し、インストールされています。

Solaris 10 をインストールしたあとで、何をすべきですか

Configuration Agent は、デフォルトでは無効になっており、構成されていません。Configuration Agent を使用するためには、少なくとも最小限に構成を行い、有効にする必要があります。これらの手順を完了すると、次回の起動時に、デスクトップクライアントアプリケーションが提供されたポリシーを自動的に使用し始めます。

Configuration Agent を構成する方法について知りたいのですが

Configuration Agent を正しく構成するには、Configuration Agent ウィザードを使用します。スーパーユーザーとして /usr/bin/apoc-config コマンドを実行すると、ウィザードを起動できます。ウィザードに従って、エージェントを正しく構成するために必要な手順を実行します。ほとんどの場合では、ウィザードを完了するために絶対必要な情報は、ポリシーリポジトリの場所だけです。

また、構成ファイルを手動で編集して、Configuration Agent を構成することも可能です。この場合、エージェントは間違って構成されやすいため、この方法はお勧めしません。さらに、Configuration Agent ウィザードには、特定の構成変更がエージェントの再起動または再ロードを必要とするかどうかを判断するロジックも追加されています。

Configuration Agent を有効にするにはどうすればよいのでしょうか

次の 3 つのメカニズムのいずれかを使用して、エージェントを有効にすることができます。

  1. Configuration Agent ウィザード (/usr/bin/apoc-config) を使用して、「状態」を「アクティブ」に設定します。

  2. Configuration Agent コントローラプログラム ( /usr/lib/apoc/apocd) を使用して、スーパーユーザーとして次のコマンドを実行します。


    /usr/lib/apoc/apocd enable

  3. smf(5) を使用して、スーパーユーザーとして次のコマンドを実行します。


    /usr/sbin/svcadm enable svc:/network/apocd/udp

Configuration Agent を構成し有効にしたあとで、正常に動作していることを確認するにはどうすればよいのでしょうか

Configuration Agent が正しく構成され動作していることを確認するもっとも簡単な方法は、Desktop Manager でポリシーを作成し、そのポリシーをユーザーに割り当てることです。そのユーザーとしてデスクトップマシンにログインして、作成したポリシー設定が使用されていることを確認します。背景やテーマなど、デスクトップセッションで容易に検出できる多くのポリシー設定があります。

Configuration Agent を有効にすることにはどのような意味があるのでしょうか

Configuration Agent は、smf(5) 準拠のサービスであり、したがって、エージェントを有効にするという意図は smf(5) に起因します。エージェントを有効にすると、エージェントはサービスを提供する準備が整います。エージェントを有効にしたとき、次の処理が発生します。

Configuration Agent が有効かどうかを確認する方法を教えてください

次の方法のいずれか 1 つを使用して、Configuration Agent が有効かどうかを判断できます。

Configuration Agent が稼動しているかどうかを確認するにはどのようにすればよいのでしょうか

次の方法のいずれか 1 つを使用して、Configuration Agent が稼動しているかどうかを判断します。

ログファイルの場所はどこですか

Configuration Agent の問題のトラブルシューティングを行う必要があるときは、次のログファイルを調べることができます。

エージェントのログ記録メカニズムの詳細度を高めるにはどのようにするのですか

「ログファイルの場所はどこですか」を参照してください。

保守モードとはどのようなものですか

smf(5) は、エージェントの起動または再起動で問題を検出すると、Configuration Agent を保守モードにします。smf(5) はエージェントの起動に失敗すると、エージェントの起動が成功するまで繰り返し再起動を試みるか、または smf(5) はエージェントが起動できないと判断します。後者の場合、smf(5) はエージェントを保守モードにして、発生した問題に対処する必要があることを知らせます。問題に対処したあとで、エージェントの smf(5) 状態をクリアして、通常の操作に戻ることができます。

保守モードから抜け出す、つまり smf(5) 状態をクリアするにはどうするのですか

スーパーユーザーになって、/usr/sbin/svcadm clear svc:/network/apocd/udp コマンドを実行します。

Configuration Agent が不意に実行を停止した場合、何が起こりますか

smf(5) は、エージェントが停止したことを検出し、エージェントの再起動を試みます。何らかの理由により再起動の試みが連続して失敗した場合、smf(5) はエージェントを保守モードにします。エージェントが正常に再起動された場合、デスクトップクライアントアプリケーションの実行は影響を受けません。このようなデスクトップクライアントアプリケーションは、再起動時にエージェントに自動で再接続します。

エージェントを有効または起動した場合、デスクトップクライアントアプリケーションを再起動する必要がありますか

実際に行う処置は、特定のデスクトップクライアントアプリケーションの起動時にエージェントが有効にされ稼動していたかどうかによって異なります。エージェントが有効にされ稼動していた場合、 クライアントアプリケーションはエージェントへの接続を確立しており、接続が切断されると再接続を試みます。つまり、エージェントを起動、有効、または無効にするたびに、クライアントアプリケーションは常に、エージェントが実行していれば再接続を試みます。クライアントアプリケーションの起動時にエージェントが有効にされておらず、稼動していなかった場合、クライアントアプリケーションは Configuration Agent を使用せず、エージェントの起動時にも接続を試みません。実際に、これは次のことを意味します。

デスクトップクライアントアプリケーションが構成済みポリシーを使用していない場合はどのようにすればよいでしょうか

Configuration Agent に関連するもっとも一般的な問題は、構成済みポリシーの効果がデスクトップクライアントアプリケーションに表れないことです。この問題のもっとも一般的な原因は、エージェントが間違って構成されている、ポリシーリポジトリが間違って構成されている、またはポリシーリポジトリが使用できないということです。次のガイドラインに従って、このような問題を検出し取り除くことができます。

Configuration Agent を起動するときの問題

Configuration Agent が起動できず、Configuration Agent を構成し有効にしている場合は、ログファイルを調べる必要があります。次のセクションでは、この問題のもっとも一般的なエラーについて説明します。

エージェントデータディレクトリが無効またはアクセス不可

ログファイル、ポリシーキャッシュなどを格納するために、エージェントは Configuration Agent データディレクトリを作成および使用します。このディレクトリは、デフォルトで /var/opt/apoc に置かれます。

データディレクトリがアクセスできない場所、つまり/dev/null/cant/write/here に設定されると、Configuration Agent は smf(5) ログに次のエラーメッセージを生成します。この問題を解決するには、Configuration Agent ウィザード (/usr/bin/apoc-config) を使用して、データディレクトリをアクセス可能な場所に指定します。


[ Nov 17 14:35:38 Executing start method ("/usr/lib/apoc/apocd svcStart") ]
Starting Configuration Agent ... Warning: Cannot create Log directory
   '/dev/null/cant/write/here/Logs'
Warning:Failed to create log file handler
Nov 17, 2005 2:35:39 PM com.sun.apoc.daemon.misc.APOCLogger config
CONFIG: Daemon configuration:
 MaxRequestSize = 4096
 DaemonAdminPort = 38901
 ThreadTimeToLive = 5
 DaemonChangeDetectionInterval = 10
 IdleThreadDetectionInterval = 15
 PROVIDER_URL =
 DataDir = /dev/null/cant/write/here
 ApplyLocalPolicy = true
 ChangeDetectionInterval = 60
 MaxClientConnections = 50
 GarbageCollectionInterval = 10080
 InitialChangeDetectionDelay = 10
 TimeToLive = 10080
 ConnectionReadTimeout = 5000
 DaemonPort = 38900
 LogLevel = FINEST
 MaxClientThreads = 5


Nov 17, 2005 2:35:39 PM Daemon main
FINER: THROW
com.sun.apoc.daemon.misc.APOCException
    at com.sun.apoc.daemon.apocd.Daemon.initAuthDir(Unknown Source)
    at com.sun.apoc.daemon.apocd.Daemon.init(Unknown Source)
    at com.sun.apoc.daemon.apocd.Daemon.<init>(Unknown Source)
    at com.sun.apoc.daemon.apocd.Daemon.main(Unknown Source)
[ Nov 17 14:36:08 Method or service exit timed out.  Killing contract 980 ]
[ Nov 17 14:36:08 Method "start" failed due to signal KILL ]

ビジー状態にあるクライアント要求ポートの使用

Configuration Agent は TCP/IP ソケット接続を使用して、デスクトップクライアントアプリケーションと通信します。デフォルトで、これらの接続はポート 38900 経由で行われます。

すでにほかのサービスが使用しているポート 1234 を使用するように Configuration Agent が構成されている場合、次のエラーメッセージが生成されます。エラーメッセージは、Configuration Agent ログに記録されます。この問題を解決するには、Configuration Agent ウィザード (/usr/bin/apoc-config) を使用して、「エージェントポート」の設定を未使用のポート番号に変更します。


Nov 17, 2005 2:50:59 PM com.sun.apoc.daemon.misc.APOCLogger config
CONFIG: Daemon configuration:
 MaxRequestSize = 4096
 DaemonAdminPort = 38901
 ThreadTimeToLive = 5
 DaemonChangeDetectionInterval = 10
 IdleThreadDetectionInterval = 15
 PROVIDER_URL =
 DataDir = /var/opt/apoc
 ApplyLocalPolicy = true
 ChangeDetectionInterval = 60
 MaxClientConnections = 50
 GarbageCollectionInterval = 10080
 InitialChangeDetectionDelay = 10
 TimeToLive = 10080
 ConnectionReadTimeout = 5000
 DaemonPort = 1234
 LogLevel = FINEST
 MaxClientThreads = 5


Nov 17, 2005 2:50:59 PM com.sun.apoc.daemon.misc.APOCLogger info
INFO: Daemon starting
Nov 17, 2005 2:50:59 PM com.sun.apoc.daemon.misc.APOCLogger fine
FINE: Garbage collection scheduled ( interval = 10080 minutes )
Nov 17, 2005 2:50:59 PM Daemon main
FINER: THROW
com.sun.apoc.daemon.misc.APOCException: java.net.BindException: Address already in use
    at com.sun.apoc.daemon.transport.ChannelManager.<init>(Unknown Source)
    at com.sun.apoc.daemon.apocd.Daemon.run(Unknown Source)
    at com.sun.apoc.daemon.apocd.Daemon.main(Unknown Source)
Caused by: java.net.BindException: Address already in use
    at sun.nio.ch.Net.bind(Native Method)
    at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:119)
    at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59)
    at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:52)

ビジー状態にある管理ポートの使用

Configuration Agent は TCP/IP ソケット接続を使用して、Configuration Agent コントローラプログラム (/usr/lib/apoc/apocd) と通信します。デフォルトで、これらの接続はポート 38901 経由で行われます。

すでにほかのサービスが使用しているポート 1234 を使用するように Configuration Agent が構成されている場合、次のエラーメッセージが Configuration Agent ログに生成されます。この問題を解決するには、Configuration Agent ウィザード (/usr/bin/apoc-config) を使用して、「管理ポート」の設定を未使用のポート番号に変更します。


ONFIG: Daemon configuration:
 MaxRequestSize = 4096
 DaemonAdminPort = 1234
 ThreadTimeToLive = 5
 DaemonChangeDetectionInterval = 10
 IdleThreadDetectionInterval = 15
 PROVIDER_URL =
 DataDir = /var/opt/apoc
 ApplyLocalPolicy = true
 ChangeDetectionInterval = 60
 MaxClientConnections = 50
 GarbageCollectionInterval = 10080
 InitialChangeDetectionDelay = 10
 TimeToLive = 10080
 ConnectionReadTimeout = 5000
 DaemonPort = 38900
 LogLevel = FINEST
 MaxClientThreads = 5


Nov 17, 2005 2:55:11 PM com.sun.apoc.daemon.misc.APOCLogger info
INFO: Daemon starting
Nov 17, 2005 2:55:11 PM com.sun.apoc.daemon.misc.APOCLogger fine
FINE: Garbage collection scheduled ( interval = 10080 minutes )
Nov 17, 2005 2:55:11 PM com.sun.apoc.daemon.misc.APOCLogger fine
FINE: Client manager started
Nov 17, 2005 2:55:11 PM com.sun.apoc.daemon.misc.APOCLogger fine
FINE: Channel manager started
Nov 17, 2005 2:55:11 PM Daemon main
FINER: THROW
com.sun.apoc.daemon.misc.APOCException: java.net.BindException: Address already in use
    at com.sun.apoc.daemon.admin.AdminManager.initChannel(Unknown Source)
    at com.sun.apoc.daemon.admin.AdminManager.<init>(Unknown Source)
    at com.sun.apoc.daemon.apocd.Daemon.run(Unknown Source)
    at com.sun.apoc.daemon.apocd.Daemon.main(Unknown Source)
Caused by: java.net.BindException: Address already in use
    at sun.nio.ch.Net.bind(Native Method)
    at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:119)
    at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:59)
    at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:52)
    ... 4 more

実行中の Configuration Agent からポリシーを取得するときの問題

構成リポジトリの指定が欠落しているか無効である

Configuration Agent は、ポリシー情報をダウンロードまたはキャッシュに書き込むために有効な構成リポジトリに接続する必要があります。エージェントの構成で構成リポジトリを正しく特定していない場合、無効な形式の使用、リポジトリの未指定などにより、デスクトップクライアントアプリケーションの起動時に、次のようなエラーが Configuration Agent ログに書き込まれます。この問題を解決するには、Configuration Agent ウィザード (/usr/bin/apoc-config) を使用して、使用する構成リポジトリを特定します。


FINER: New client added
Nov 18, 2005 1:59:22 PM com.sun.apoc.daemon.misc.APOCLogger finer
FINER: CreateSession transaction started
Nov 18, 2005 1:59:22 PM com.sun.apoc.daemon.misc.APOCLogger finer
FINER: Creating new client session
Nov 18, 2005 1:59:22 PM com.sun.apoc.daemon.misc.APOCLogger finest
FINEST: Authenticating user geoffh
Nov 18, 2005 1:59:22 PM com.sun.apoc.daemon.misc.APOCLogger finest
FINEST: Authentication successful
Nov 18, 2005 1:59:23 PM PolicyBackend openPolicyBackend
FINER: THROW
com.sun.apoc.daemon.misc.APOCException: com.sun.apoc.daemon.misc.APOCException: 
com.sun.apoc.spi.environment.InvalidParameterException: The parameter organisation 
PROVIDER_URL#protocol (null) is not valid, the value must be comprised in 
{ldaps,ldap,https,http,file}.
    at com.sun.apoc.daemon.apocd.PolicyBackend.<init>(Unknown Source)
    at com.sun.apoc.daemon.apocd.HostPolicyBackend.<init>(Unknown Source)
    at com.sun.apoc.daemon.apocd.PolicyBackendFactory.openPolicyBackend(Unknown Source)
    at com.sun.apoc.daemon.apocd.Cache$DataSource.openPolicyBackend(Unknown Source)
    at com.sun.apoc.daemon.apocd.Cache$DataSource.open(Unknown Source)
    at com.sun.apoc.daemon.apocd.Cache.createDataSources(Unknown Source)
    at com.sun.apoc.daemon.apocd.Cache.<init>(Unknown Source)
    at com.sun.apoc.daemon.apocd.CacheFactory.createNewCache(Unknown Source)
    at com.sun.apoc.daemon.apocd.CacheFactory.openCache(Unknown Source)
    at com.sun.apoc.daemon.apocd.Session.<init>(Unknown Source)
    at com.sun.apoc.daemon.transaction.CreateSessionTransaction.executeTransaction
(Unknown Source)
    at com.sun.apoc.daemon.transaction.Transaction.execute(Unknown Source)
    at com.sun.apoc.daemon.apocd.ClientEventHandler.handleEvent(Unknown Source)
    at com.sun.apoc.daemon.apocd.EventWorkerThread.run(Unknown Source)
Caused by: com.sun.apoc.daemon.misc.APOCException: 
 com.sun.apoc.spi.environment.InvalidParameterException:
 The parameter organisation PROVIDER_URL#protocol (null) is not valid, 
 the value must be comprised in {ldaps,ldap,https,http,file}.
    at com.sun.apoc.daemon.apocd.PolicyBackendFactory.openPolicyMgr(Unknown Source)
    ... 14 more
Caused by: com.sun.apoc.spi.environment.InvalidParameterException: The parameter 
organisation PROVIDER_URL#protocol (null) is not valid, the value must be comprised in 
{ldaps,ldap,https,http,file}.
    at com.sun.apoc.spi.PolicyMgrFactoryImpl.createPolicyMgr(Unknown Source)
    ... 15 more
Nov 18, 2005 1:59:23 PM PolicyBackend openPolicyBackend

ポリシーリポジトリに接続できない

Configuration Agent は、ポリシー情報をダウンロードまたはキャッシュに書き込むために有効な構成リポジトリに接続する必要があります。接続を確立できない場合、デスクトップクライアントアプリケーションの起動時に、次のようなエラーが Configuration Agent ログに記録されます。次のケースでは、ホスト sobuild が存在していない、接続できない、またはポート 389 経由で LDAP サーバーにアクセスできません。この問題を解決するには、Agent Configuration ウィザード (/usr/bin/apoc-config) を使用して、ポリシーリポジトリが正しく特定されていることを確認します。正しく特定されている場合は、ポリシーリポジトリへのアクセスが使用可能であることを確認します。たとえば、LDAP リポジトリの場合、LDAP サーバーが稼動していること、LDAP サーバーをホストしているマシンがネットワーク上で使用可能であること、および指定したポートが LDAP サーバーが使用しているポートであることを確認する必要があります。

SSL 接続を使用する LDAP サーバーに接続する場合は、Configuration Agent を実行するために必要な Java 実行環境に関連付けされたキーストア内で、適切な証明書が使用可能であることを確認します。apoc-config についての詳細については、「Configuration Agent」 のセクションを参照してください。


FINER: New client added
Nov 18, 2005 2:17:43 PM com.sun.apoc.daemon.misc.APOCLogger finer
FINER: CreateSession transaction started
Nov 18, 2005 2:17:43 PM com.sun.apoc.daemon.misc.APOCLogger finer
FINER: Creating new client session
Nov 18, 2005 2:17:43 PM com.sun.apoc.daemon.misc.APOCLogger finest
FINEST: Authenticating user geoffh
Nov 18, 2005 2:17:43 PM com.sun.apoc.daemon.misc.APOCLogger finest
FINEST: Authentication successful
Nov 18, 2005 2:17:43 PM PolicyBackend openPolicyBackend
FINER: THROW
com.sun.apoc.daemon.misc.APOCException: com.sun.apoc.daemon.misc.APOCException: 
com.sun.apoc.spi.OpenConnectionException: An error occured while connecting to 
ldap://sobuild:389.
    at com.sun.apoc.daemon.apocd.PolicyBackend.<init>(Unknown Source)
    at com.sun.apoc.daemon.apocd.HostPolicyBackend.<init>(Unknown Source)
    at com.sun.apoc.daemon.apocd.PolicyBackendFactory.openPolicyBackend(Unknown Source)
    at com.sun.apoc.daemon.apocd.Cache$DataSource.openPolicyBackend(Unknown Source)
    at com.sun.apoc.daemon.apocd.Cache$DataSource.open(Unknown Source)
    at com.sun.apoc.daemon.apocd.Cache.createDataSources(Unknown Source)
    at com.sun.apoc.daemon.apocd.Cache.<init>(Unknown Source)
    at com.sun.apoc.daemon.apocd.CacheFactory.createNewCache(Unknown Source)
    at com.sun.apoc.daemon.apocd.CacheFactory.openCache(Unknown Source)
    at com.sun.apoc.daemon.apocd.Session.<init>(Unknown Source)
    at com.sun.apoc.daemon.transaction.CreateSessionTransaction.executeTransaction
(Unknown Source)
    at com.sun.apoc.daemon.transaction.Transaction.execute(Unknown Source)
    at com.sun.apoc.daemon.apocd.ClientEventHandler.handleEvent(Unknown Source)
    at com.sun.apoc.daemon.apocd.EventWorkerThread.run(Unknown Source)
Caused by: com.sun.apoc.daemon.misc.APOCException: 
com.sun.apoc.spi.OpenConnectionException: An error occured while 
connecting to ldap://sobuild:389. at 
com.sun.apoc.daemon.apocd.PolicyBackendFactory.openPolicyMgr(Unknown Source)
    ... 14 more
Caused by: com.sun.apoc.spi.OpenConnectionException: An error occured while 
connecting to ldap://noSuchHost:389.
    at com.sun.apoc.spi.ldap.LdapClientContext.prepareConnection(Unknown Source)
    at com.sun.apoc.spi.ldap.LdapClientContext.connect(Unknown Source)
    at com.sun.apoc.spi.ldap.LdapConnectionHandler.openAuthorizedContext(Unknown Source)
    at com.sun.apoc.spi.ldap.LdapConnectionHandler.connect(Unknown Source)
    at com.sun.apoc.spi.ldap.entities.LdapOrganizationProvider.open(Unknown Source)
    at com.sun.apoc.spi.PolicyMgrFactoryImpl.createPolicyMgr(Unknown Source)
    ... 15 more
Caused by: netscape.ldap.LDAPException: failed to connect to server sobuild:389 (91); 
Cannot connect to the LDAP server
    at netscape.ldap.LDAPConnSetupMgr.connectServer(LDAPConnSetupMgr.java:422)
    at netscape.ldap.LDAPConnSetupMgr.openSerial(LDAPConnSetupMgr.java:350)
    at netscape.ldap.LDAPConnSetupMgr.connect(LDAPConnSetupMgr.java:244)
    at netscape.ldap.LDAPConnSetupMgr.access$0(LDAPConnSetupMgr.java:241)
    at netscape.ldap.LDAPConnSetupMgr$1.run(LDAPConnSetupMgr.java:179)
    at java.lang.Thread.run(Thread.java:595)
Nov 18, 2005 2:17:44 PM PolicyBackend openPolicyBackend

構成されていないポリシーリポジトリへの接続

Configuration Agent がポリシーリポジトリ内のポリシーデータを検索できるように、ポリシーリポジトリを正しく構成する必要があります。構成されていない、または間違って構成されたポリシーリポジトリを指定すると、デスクトップクライアントアプリケーションの起動時に、次のようなエラーが Configuration Agent ログに記録されます。　


FINER: New client added
Nov 18, 2005 2:36:55 PM com.sun.apoc.daemon.misc.APOCLogger finer
FINER: CreateSession transaction started
Nov 18, 2005 2:36:55 PM com.sun.apoc.daemon.misc.APOCLogger finer
FINER: Creating new client session
Nov 18, 2005 2:36:55 PM com.sun.apoc.daemon.misc.APOCLogger finest
FINEST: Authenticating user geoffh
Nov 18, 2005 2:36:55 PM com.sun.apoc.daemon.misc.APOCLogger finest
FINEST: Authentication successful
Nov 18, 2005 2:36:55 PM PolicyBackend openPolicyBackend
FINER: THROW
com.sun.apoc.daemon.misc.APOCException: com.sun.apoc.daemon.misc.APOCException: 
com.sun.apoc.spi.environment.RemoteEnvironmentException: Error on reading the 
configuration data on LDAP server ldap://sobuild:389.
    at com.sun.apoc.daemon.apocd.PolicyBackend.<init>(Unknown Source)
    at com.sun.apoc.daemon.apocd.HostPolicyBackend.<init>(Unknown Source)
    at com.sun.apoc.daemon.apocd.PolicyBackendFactory.openPolicyBackend(Unknown Source)
    at com.sun.apoc.daemon.apocd.Cache$DataSource.openPolicyBackend(Unknown Source)
    at com.sun.apoc.daemon.apocd.Cache$DataSource.open(Unknown Source)
    at com.sun.apoc.daemon.apocd.Cache.createDataSources(Unknown Source)
    at com.sun.apoc.daemon.apocd.Cache.<init>(Unknown Source)
    at com.sun.apoc.daemon.apocd.CacheFactory.createNewCache(Unknown Source)
    at com.sun.apoc.daemon.apocd.CacheFactory.openCache(Unknown Source)
    at com.sun.apoc.daemon.apocd.Session.<init>(Unknown Source)
    at com.sun.apoc.daemon.transaction.CreateSessionTransaction.executeTransaction
(Unknown Source)
    at com.sun.apoc.daemon.transaction.Transaction.execute(Unknown Source)
    at com.sun.apoc.daemon.apocd.ClientEventHandler.handleEvent(Unknown Source)
    at com.sun.apoc.daemon.apocd.EventWorkerThread.run(Unknown Source)

「クライアントの最大接続数」に関する Configuration Agent ログに見られるメッセージは何を意味しているのですか

Configuration Agent によって有効にされる各デスクトップクライアントアプリケーション (gconfd、Mozilla、StarSuite) は、起動時に Configuration Agent へ接続します。この接続制限は、エージェントの構成で指定されます。デフォルトの接続制限は、50 です。複数ユーザーのマシンでは、Configuration Agent ウィザード (/usr/bin/apoc-config) で「クライアントの最大接続数」設定を変更して、この制限を増やす必要がある場合があります。Configuration Agent が最大接続数に達すると、次のようなエラーメッセージが Configuration Agent ログに記録されます。


Nov 18, 2005 3:20:55 PM com.sun.apoc.daemon.misc.APOCLogger warning
WARNING: The maximum number of client connections ( 50 ) has been reached. 
No new client connections can be established at this time.

Desktop Manager を使用していくつかのポリシーを変更したが、変更内容が使用しているクライアントマシンに表れない

Configuration Agent は、Desktop Manager が作成したポリシーデータは比較的静的であり、頻繁に変更されることはないという仮定の基に設計されました。この仮定により、変更が発生したかどうかを確認するために、エージェントが断続的にポリシーリポジトリを調べるという手法が採られました。デフォルトで、エージェントは、実行中のすべてのデスクトップアプリケーションのリポジトリを、1 時間に 1 度調べます。結果として、Desktop Manager で変更を行なったときは、実行中のデスクトップアプリケーションに変更が通知されるまで、最大で 1 時間待つ必要があります。必要であれば、リポジトリチェックの頻度を上げるために、Agent Configuration ウィザード (/usr/bin/apoc-config) を使用して、「一般的な検出間隔」の値を変更できます。あるいは、スーパーユーザーになって、/usr/lib/apoc/apocd change-detect コマンドを実行することにより、Configuration Agent が接続されたすべてのアプリケーションのポリシーデータを強制的にリフレッシュするようにできます。