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

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

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

質問と回答

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

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

クライアントが再利用できるように、任意のダウンロードされたポリシーをローカルで使用可能なキャッシュに書き込む
ポリシーがホストされている LDAP サーバーへの接続などの、共有可能でかつ共有すべき、任意の高価なリソースを共有する

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

ユーザーが、gconfd、Mozilla、StarSuite など、関連するデスクトップクライアントアプリケーションの 1 つを起動します。
クライアントアプリケーションが Configuration Agent に接続します。
クライアントアプリケーションは、Configuration Agent から必要とするポリシーデータを要求します。
Configuration Agent は、要求されたポリシーデータを探してキャッシュを検索します。
ポリシーデータがキャッシュ内に見つからなかった場合、Configuration Agent は、事前に構成されたポリシーリポジトリから要求されたデータをダウンロードして、キャッシュに格納します。
ポリシーデータは、要求を行なったクライアントアプリケーションに送信されます。
Configuration Agent は、ポリシーデータに対する変更についてポリシーリポジトリを監視します。
変更が検出されると、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 つのメカニズムのいずれかを使用して、エージェントを有効にすることができます。

Configuration Agent ウィザード (/usr/bin/apoc-config) を使用して、「状態」を「アクティブ」に設定します。
Configuration Agent コントローラプログラム ( /usr/lib/apoc/apocd) を使用して、スーパーユーザーとして次のコマンドを実行します。
/usr/lib/apoc/apocd enable
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 のコントローラプログラムを使用します。スーパーユーザーになって、次のコマンドを入力します。
/usr/lib/apoc/apocd is-enabled
エージェントが有効の場合、コントローラプログラムは次のメッセージを返します。
Checking Configuration Agent enabled status ... Enabled
エージェントが無効の場合、コントローラプログラムは次のメッセージを返します。
Checking Configuration Agent enabled status ... Not enabled
smf(5) を使用して、次のコマンドを実行します。
/usr/bin/svcs svc:/network/apocd/udp:default
エージェントが有効の場合、svcs は次のメッセージを返します。
STATE STIME FMRI online 8:36:04 svc:/network/apocd/udp:default
エージェントが無効の場合、svcs は次のメッセージを返します。
STATE STIME FMRI disabled 15:58:34 svc:/network/apocd/udp:default
エージェントが保守モードの場合、svcs は次のメッセージを返します。
STATE STIME FMRI maintenance 8:38:42 svc:/network/apocd/udp:default

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

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

スーパーユーザーになって、Configuration Agent コントローラプログラムを実行します。
/usr/lib/apoc/apocd status
エージェントが有効の場合、コントローラプログラムは次のメッセージを返します。
Checking Configuration Agent status ... Running
エージェントが無効の場合、コントローラプログラムは次のメッセージを返します。
Checking Configuration Agent status ... Not running
次のコマンドを実行します。
/usr/bin/svcs svc:/network/apocd/udp:default
エージェントが稼動している場合、svcs は次のメッセージを返します。
STATE STIME FMRI online 8:36:04 svc:/network/apocd/udp:default
エージェントが稼動していない場合、svcs は次のメッセージを返します。
STATE STIME FMRI disabled 15:58:34 svc:/network/apocd/udp:default
エージェントが保守モードの場合、svcs は次のメッセージを返します。
STATE STIME FMRI maintenance 8:38:42 svc:/network/apocd/udp:default

次のコマンドを実行します。

ps -ef | grep apoc

Configuration Agent が稼動している場合、ps 出力に、次の関連付けされた Java 処理が表示されます。

 daemon 29295 29294  0 13:05:22?  0:03 java -Djava.library.path=/usr/lib/apoc
 -cp /usr/share/lib/apoc/apocd.jar:/usr/s
 daemon 29294   1   0 13:05:22?  0:00 sh -c java 
-Djava.library.path=/usr/lib/apoc -cp /usr/share/lib/apoc/apocd.jar:
 root 29345 28134  0 13:08:59 pts/1   0:00 grep apoc

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

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

smf(5) ログファイル:
- /var/svc/log/network-apocd-udp:default.log ファイルには、Configuration Agent の特定のインスタンスを開始または停止しようとする試みに関連するイベントが記録されます。また、ファイルには、Configuration Agent コントローラプログラム、/usr/lib/apoc/apocd が標準出力に書き込みを行なったというメッセージと、JVM または Configuration Agent の出力メッセージも含まれます。
- /var/svc/log/svc.startd.log ログファイルは、高レベルの smf(5) イベントの記録を保持します。たとえば、Configuration Agent を起動しようとする試みが短時間で連続して複数回発生した場合、 smf(5) は、Configuration Agent が起動できないと判断することがあります。これが発生した場合、smf(5) は Configuration Agent を保守モードにして、その結果にログエントリを書き込みます。
一般に、Configuration Agent 起動の問題が発生したとき、これらのログファイルの両方が役立ちます。
Configuration Agent ログ:

Configuration Agent は、デフォルトのログディレクトリ /var/opt/apoc/Logs にあるログファイルにログメッセージを書き込みます。Configuration Agent の「データディレクトリ」は /var/opt/apoc です。Configuration Agent ウィザード (/usr/bin/apoc-config) アプリケーションを使用して、このディレクトリの場所を変更することができます。Configuration Agent ウィザードで「ログのレベル」を変更して、ログメッセージの詳細度を変更することができます。Configuration Agent が正しく構成されていない場合、または何らかのエージェントの傷害が発生した場合は、Configuration Agent ウィザードを使用して、ログのレベルを「Finest」に設定してから、エージェントのログファイルを調べてください。この手順により、利用可能な最大量のログ情報を確実に取得できます。
システムログ:

/var/adm/messages ログファイル、または SunRay マシンにある /var/opt/SUNWut/log/messages ログファイルをチェックして、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 が起動できず、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 が接続されたすべてのアプリケーションのポリシーデータを強制的にリフレッシュするようにできます。