Sun Desktop Manager 1.0 安裝指南

Configuration Agent 疑難排解

本節將針對 Configuration Agent 之性質及運作方式的相關問題提出解答,並提供疑難排解此代理程式問題的相關提示。

問題與回答

Configuration Agent 是什麼?其如何運作?

Configuration Agent 是一種應用程式,專責策略快取與傳遞的工作。其設計建立目的在能夠集中配置桌面用戶端應用程式,但不會對這些應用程式及其執行所在主機的效能造成巨幅影響。若要達成上述目的,可執行下列作業:

用戶端應用程式與 Configuration Agent 之間的互動一般來說非常簡單,如下所述:

  1. 使用者啟動任一項桌面用戶端應用程式 ( gconfd、Mozilla 或 StarSuite)。

  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。請問該如何做?

您可以使用下列三種機制啟用此代理程式:

  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 與否?

您可以使用下列一種方法,判別 Configuration Agent 啟用與否:

我如何得知 Configuration Agent 是否已在執行中?

您可以使用下列一種方法,判別 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 加以建立。

當將 Configuration Agent 配置成使用連接埠 1234 (其他服務已在使用此連接埠) 時,會產生下列錯誤訊息。此錯誤訊息會記錄在 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 加以建立。

當將 Configuration Agent 配置成使用其他服務已在使用的連接埠 1234 時,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 記錄中寫入類似於下列的錯誤。下列情況有可能是以此方式建立的主機不存在、無法連線至該主機,或無法透過連接埠 389 存取 LDAP 伺服器。若要解決此問題,請使用 [Configuration Agent 精靈] (/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 執行時,開啟對 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 所建立的策略資料為相對靜態,不會經常變更。此項假設導致代理程式會間歇性地查看「策略儲存庫」,以確定其是否有所修改。代理程式預設會每隔一小時檢查所有執行中之桌面應用程式的儲存庫。因此當您使用 Desktop Manager 執行變更之後,必須等待一小時,執行中的桌面應用程式才會收到此項變更的通知。如有需要,可以使用 [Configuration Agent 精靈] (/usr/bin/apoc-config) 變更「一般偵測間隔」的值,以增加檢查儲存庫的頻率。您也可以使用超級使用者身份執行 /usr/lib/apoc/apocd change-detect 指令,以強制 Configuration Agent 重新整理所有連線應用程式的策略資料。