Sun Desktop Manager 1.0 安裝指南

第 3 章用戶端元件

若要存取 Desktop Manager 的配置資料，桌面用戶端必須有 Java Desktop System Configuration Agent。Configuration Agent 可與遠端配置資料儲存庫及介面進行通訊，也可將資料整合至特定的配置系統中。目前支援的配置系統為 GConf、Java Preferences、Mozilla Preferences 和 StarSuite Registry。

Solaris 10 作業系統會隨附 Configuration Agent。但 Desktop Manager 必須使用此工具的較新版本。新版本工具會在安裝 Desktop Manager 用戶端元件與相關修補程式時一併安裝。

安裝 Desktop Manager 用戶端元件：

下載 Desktop Manager 壓縮歸檔，並將其內容解壓縮至暫存的目錄中。
# unzip SunDesktopMgr-1.0.zip
安裝建議的修補程式。

這些修補程式位於 SunDesktopMgr-1.0/<platform>/client/Patches 目錄中。請遵循修補程式所附的安裝說明執行作業。
以超級使用者身份 (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 目錄中。您可以手動方式或使用 Configuration Agent 配置精靈編輯這些特性檔案 (請參閱附錄 A 配置參數) 。

配置精靈提供一個圖形化使用者介面，可指導您瞭解 Configuration Agent 的必要設定。精靈的每一個頁面都會有相應的說明螢幕。您可以使用 /usr/bin/apoc-config 程序檔，以超級使用者身份 (root) 啟動精靈。

備註 –

也可以不啟動圖形介面而啟動該精靈。例如，在主控台模式下執行 /usr/bin/apoc-config -nodisplay 以啟動精靈。

啟動程式資訊

圖 3–1 Configuration Agent，配置儲存庫

備註 –

在適當的位置，關聯的特性檔案關鍵字在圓括號中進行指示。

狀態：Configuration Agent 的狀態。該核取方塊可用於啟動或關閉 Configuration Agent。若要使用配置儲存庫，Configuration Agent 必須處於使用中。啟動會自動由 Solaris 服務管理功能 ( smf(5) ) 中納入所需要的註冊。
主機識別碼 (HostIdentifierType)：可為「主機名稱」或「IP 位址」。在搜尋主機特有策略資料時，Configuration Agent 會根據主機名稱或 IP 位址識別目前的主機。請根據主機在所選「環境類型」中的識別方式選擇正確的值。
環境類型：此設定可用於指示 Configuration Agent 您是在 LDAP 或檔案型儲存中定義組織階層與配置資料，或兩者中皆有定義。

備註 –
若要手動啟用或停用 Configuration Agent，請以 root 身份登入，再分別鍵入 /usr/lib/apoc/apocd enable 或 /usr/lib/apoc/apocd disable 指令。

圖 3–2 Configuration Agent，LDAP 階層和檔案型儲存

備註 –

圖 3–2 的螢幕會隨著上一個畫面中所選之「環境類型」而不同。選擇 LDAP 或混合型環境類型時，必須具備伺服器識別碼、伺服器連接埠及字尾。選擇檔案型或混合型環境類型時，則須具備「配置設定 URL」。

伺服器識別碼︰LDAP 伺服器的主機名稱。
伺服器連接埠︰LDAP 伺服器的連接埠號。
字尾：LDAP 儲存庫的基底 DN。
配置設定 URL：指定檔案型儲存庫位置的 URL。

若連線至第一個儲存庫失敗，URL 清單可用以指定備用的儲存庫。此清單可由一或多個以空格加以分隔的 URL 組成；每一個 URL 的格式均須為 file://<filepath> 、http://<host>:<port>/<filepath> 或 https://<host>:<port>/<filepath>。如需更多資訊，請參閱附錄 A 配置參數。

備註 –
代理程式會先嘗試使用 SSL 連線存取 LDAP 伺服器。此連線若是失敗，代理程式才會接著嘗試一般的 SSL 連線。

SSL 連線要能夠成功，Java 執行階段環境的金鑰庫中必須存有適當的憑證。標準 JRE 的金鑰庫位於 <installation directory>/lib/security/cacerts，而標準 JDK 的金鑰庫則位於 <installation directory>/jre/lib/security/cacerts。無論是「憑證授權單位」或 LDAP 伺服器憑證，均須透過 keytool -import -file <certificate file> -keystore <cacerts file location> 指令增加至該金鑰庫內。該金鑰庫的預設密碼為 changeit。

圖 3–3 Configuration Agent，驗證機制

Configuration Agent 的認證類型：可為「匿名」或「簡單」。若選取「匿名」，便會自動停用 [合格的使用者名稱] 和 [密碼] 欄位。
[合格的使用者名稱] (AuthDn)：具有對儲存庫的讀取和搜尋存取權之使用者的完整 DN。
[密碼] (Password)：已註冊 LDAP 使用者的密碼

備註 –
目錄中若已啟用匿名存取，即可將 [合格的使用者名稱] 和 [密碼] 設定留為空白。
應用程式的 [認證類型] (AuthType)：依據 LDAP 伺服器驗證使用者的方法，可為「匿名」或「GSSAPI」。

備註 –
如需更多資訊，請參閱資料存取/使用者認證。

連接埠設定

Configuration Agent 使用兩個連接埠：

[代理程式連接埠] (DaemonPort)：由代理程式用來與用戶端應用程式進行通訊 (預設為 38900)。
[管理連接埠] (DaemonAdminPort)：代理程式控制器程式 apocd 與代理程式通訊時，會使用此連接埠 (預設值為 38901)。

圖 3–4 Configuration Agent，連接埠設定

變更偵測間隔

Configuration Agent 使用以下兩種間隔定期檢查配置資料中的所有變更：

[一般偵測間隔] (ChangeDetectionInterval)：桌面應用程式的 (用戶端的) 配置資料之變更偵測循環的間隔 (以分鐘為單位)。

備註 –
指定 -1 會關閉變更偵測。
[代理程式設定的間隔] (DaemonChangeDetectionInterval)：代理程式特定配置設定之變更偵測循環的間隔 (以分鐘為單位)。

備註 –
指定 -1 會關閉變更偵測。

您可以使用一般偵測間隔來調準遠端配置資料變更至用戶端應用程式的傳遞。為該設定提供的值，是遠端所做變更在用戶端應用程式中反映出來之前所需的最大時間長度 (以分鐘為單位)。

較小的值將會導致 Configuration Agent 和 LDAP 伺服器活動的增加。因此，調整設定值時應該謹慎。例如您可以在初始部署階段時，將值設定為一分鐘，以測試遠端配置對用戶端應用程式的影響。完成測試之後，請將此設定恢復為初始值。

操作設定

圖 3–5 Configuration Agent，資料目錄

可以配置以下設定：

[資料目錄] (DataDir)：用於儲存運行時間資料的目錄。預設為 /var/opt/apoc。
[快取的資料儲存生命] (TimeToLive)：非離線配置資料在本機資料庫中保留的間隔 (以分鐘為單位)。

圖 3–6 Configuration Agent，請求處理和記錄

[資源回收循環] (GarbageCollectionInterval)：本機配置資料庫中資源回收循環的間隔 (以分鐘為單位)。
[最大用戶端執行緒數] (MaxClientThreads)：可同時處理的用戶端請求的最大數目。
[最大用戶端連線數] (MaxClientConnections)：用戶端連線的最大數目。
[最大請求大小] (MaxRequestSize)：用戶端請求的最大大小。
[連線逾時] (ConnectTimeout)：表示 LDAP 伺服器回覆連線請求所允許的間隔。預設值為 1 秒。
[記錄層級] (LogLevel)：代理程式記錄檔中詳細資訊的級別。記錄層級與 Java 記錄程式層級一致。下列層級會依其嚴重性遞減排列：
- 嚴重
- 警告
- 資訊
- 配置
- 詳細
- 較詳細
- 最詳細

備註 –

大多數操作設定 ([資料目錄] 和 [連線逾時] 設定除外) 亦可透過 LDAP 伺服器中所儲存的相對應策略集中進行維護。如果您要使用此項功能，請勿透過精靈調整相應的設定，而是使用 Desktop Manager 中的 Configuration Agent 策略來集中指定操作設定。

套用代理程式設定

除「資料目錄」和「連線逾時」之外，透過 Desktop Manager 儲存於 LDAP 伺服器上的操作設定將會在代理程式配置的下一次變更偵測循環開始時自動生效 (請參閱 DaemonChangeDetectionInterval)。

圖 3–7 Configuration Agent，摘要頁面

本機變更的所有其他設定均需要重新載入或重新啟動 Configuration Agent。如果您使用配置精靈，重新載入或重新啟動則會自動執行。

備註 –

若要以手動方式重新啟動 Configuration Agent，請確定所有相關用戶端應用程式皆不在執行中，然後以 root 身份登入，並鍵入 /usr/lib/apoc/apocd restart 指令。

其他代理程式設定

備註 –

配置精靈中不會提供下列設定。

本機策略的應用程式 (ApplyLocalPolicy)：使用此設定可指定是否要將本機主機上的策略資料，提供給用戶端應用程式使用。值「true」表示應提供本機策略資料。值「false」表示不應提供本機策略資料。如需更多資訊，請參閱使用本機策略。

使用本機策略

您可以將 Configuration Agent 配置成套用本機部署策略的配置設定，以此做為所提供之全域策略的替代方案。請使用下列步驟部署這類本機策略：

部署本機策略

步驟

使用 Desktop Manager 建立具有必要策略設定的設定檔。

使用 Desktop Manager 將設定檔匯出為壓縮檔。

在您的用戶端主機上建立 ${DataDir}/Policies/profiles/PROFILE_REPOSITORY_default 目錄 (如其不存在)。

將 ${DataDir} 對應至 Configuration Agent 的「資料目錄」值 (預設為 /var/opt/apoc)。

將之前所匯出的壓縮檔複製至 ${DataDir}/Policies/profiles/PROFILE_REPOSITORY_default 。

確定已將 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 存取。對於匿名存取，不需要在桌面上執行動作。對於 GSSAPI 方法，則必須在桌面上獲取 Kerberos 憑證。若要整合獲取的 Kerberos 憑證和使用者登入，則必須在 Java Desktop System 主機上安裝和配置 pam_krb5 模組。

您可以使用 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：Gnome 配置系統，桌面和多數 Gnome 應用程式均會使用，如 Evolution。
StarSuite Registry：StarSuite 和 OpenOffice.org 所使用的配置系統。
Mozilla Preferences：Mozilla 所使用的配置系統。
Java Preferences：供 Java 應用程式使用的配置 API。

此外亦提供桌面定義介面，可以將桌面啟動程式、功能表項目和啟動程式增加到使用者的桌面上。

GConf 介面

GConf 介面屬於 Solaris 之 SUNWapoc-adapter-gconf 套裝軟體的一部分。當您從相應的 packageAdapter 安裝介面時，即會更新 /etc/gconf/2/path 中的 GConf 資料來源路徑，將 Desktop Manager 資源併入其中。介面提供的兩種資料來源包括：

「apoc:readonly:」：提供對策略中不受保護設定的存取權限。請在使用者設定與本機預設值之間插入此資料來源。
「apoc:readonly:mandatory@」：提供對策略中受保護設定的存取權限。請在本機強制設定與使用者設定之間插入此資料來源。

GConf 介面配置

GConf 介面會在安裝時進行配置，但是其運作則須取決於代表強制中央設定及預設設定之兩項資料來源的 GConf 路徑檔案 (/etc/gconf/2/path) 存在與否而定。安裝之後，當此路徑檔案中包含了正確的資訊，以便於 GConf 能夠如預期般地選用中央設定時，管理員必須確定檔案中仍保有前綴詞為「apoc」的資料來源，使之能夠在需要時修改該路徑，以納入其他自訂的資料來源。您亦須確定此資料來源位於代表強制中央設定之資料來源的本機強制設定與使用者設定之間，以及代表預設中央設定之資料來源的使用者設定與本機預設設定之間。

Java Preferences 介面

「Java Preferences」介面屬於 Solaris 之 SUNWapcj 套裝軟體的一部分。

Java Preferences 介面配置

「Preferences API」實作中會提供「Java Preferences」介面；「Preferences API」是其他現有實作 (如 JRE 所提供的預設檔案型系統) 所必須的包裝程式。若要能夠在使用「Preferences API」的 Java 應用程式中使用中央配置，必須撰寫該應用程式的啟動程序檔，並以 /usr/lib/apoc/apocjlaunch 程序檔為其輔助程式。此程序檔需要定義一些環境變數，並在其尾端併入 apocjlaunch 程序檔 (會以必要的環境啟動 Java 應用程式)。必須設定的環境變數包括：

JAVA：包含 Java 執行階段可執行檔的路徑。
APPLICATION：包含該應用程式的一般 Java 執行階段呼叫尾隨部分。例如單一類別啟動的 classname [arguments] 或 jar 歸檔啟動的 -jar jarname [arguments]。

其他可以設定的選擇性環境變數包括：

CLASSPATH：以冒號分隔的 jar 或類別檔案清單，必須是應用程式類別路徑的一部分。
DEFINES：包含定義敘述的字串，必須是應用程式啟動的一部分。
PREFFACTORY：應用程式必須使用之基礎「Preferences API」實作中的工廠類別名稱。

Mozilla 介面

Mozilla 介面是 Solaris 之 SUNWmozapoc-adapter 套裝軟體的一部分。

Mozilla 介面配置

Mozilla 介面會在安裝此產品時一併安裝，並不需要進行其他任何配置。

StarSuite 介面

StarSuite 介面隨附於標準的 StarSuite 安裝中，可讓您存取設定檔配置資料，而不需要任何特殊的修改。

StarSuite 介面配置

StarSuite 介面會在安裝此產品時一併安裝，並不需要進行其他任何配置。

桌面定義介面

「桌面定義」介面由下列套裝軟體組成：

套裝軟體名稱	說明
SUNWapleg	配置存取二進位檔
SUNWardsa	桌面定義介面
SUNWardsa-misc	介面的系統整合

這些套裝軟體會在安裝 Desktop Manager 用戶端元件時一併安裝，並不需要其他任何的設定。

桌面定義介面配置

「桌面定義」介面透過使用者登入時所使用的設定程序進行配置，並不需要其他任何的設定。

移除介面

Mozilla 及 StarSuite 介面會在移除這些產品時一併移除。只要將安裝一節所述之套裝軟體移除，並使用適當的套裝軟體管理系統工具，便可將 GConf、Java Preferences 及桌面定義介面移除。

移除「Java Preferences」介面之後，便不應再繼續使用因為啟動 Java 應用程式而利用「Preferences API」所撰寫的啟動程序檔。由於部分必要的類別將無法再繼續使用，因此會導致需要使用這些類別的 Java 呼叫失敗。

介面疑難排解

可能會造成看不到相應應用程式之中央配置資料的問題中，有絕大部分是 Configuration Agent 所造成，這是因為所有介面皆會使用 Configuration Agent 擷取資料所致。

中央配置中如有某項設定 (或其群組) 未見生效，可能是使用者已在應用程式中明確設定了該設定的值 (一般會透過產品的 [選項] 或 [喜好設定] 對話方塊)。此時除非將中央設定定義為保護 (意即管理員強制使用該值，使用者無法加以修改)，否則使用者的喜好設定將優於 Desktop Manager 所設定的值。

Configuration Agent 疑難排解

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

問題與回答

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

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

將下載的策略快取至本機所提供的快取中，以供用戶端日後之用。
分享可以共用的昂貴資源 (例如對裝載有策略之 LDAP 伺服器的連線)。

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

使用者啟動任一項桌面用戶端應用程式 ( gconfd、Mozilla 或 StarSuite)。
用戶端應用程式連線至 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。請問該如何做？

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

使用 [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 與否？

您可以使用下列一種方法，判別 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 是否已在執行中？

您可以使用下列一種方法，判別 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 精靈] 將「記錄層級」設為「最詳細」。此步驟可讓您獲取最大量的可用記錄資訊。
系統記錄：

您也可以查看 /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 Agen 取得策略時發生問題」一節。
若仍然無法解決問題，請連絡「技術支援」。

啟動 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 重新整理所有連線應用程式的策略資料。

第 3 章 用戶端元件

Configuration Agent

啟動程式資訊

圖 3–1 Configuration Agent，配置儲存庫

圖 3–2 Configuration Agent，LDAP 階層和檔案型儲存

圖 3–3 Configuration Agent，驗證機制

連接埠設定

圖 3–4 Configuration Agent，連接埠設定

變更偵測間隔

操作設定

圖 3–5 Configuration Agent，資料目錄

圖 3–6 Configuration Agent，請求處理和記錄

套用代理程式設定

圖 3–7 Configuration Agent，摘要頁面

其他代理程式設定

使用本機策略

部署本機策略

步驟

自動重新啟動 Configuration Agent

資料存取/使用者認證

介面

GConf 介面

GConf 介面配置

Java Preferences 介面

Java Preferences 介面配置

Mozilla 介面

Mozilla 介面配置

StarSuite 介面

StarSuite 介面配置

桌面定義介面

桌面定義介面配置

移除介面

介面疑難排解

Configuration Agent 疑難排解

問題與回答

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

如何才能取得 Configuration Agent 並加以安裝？

我剛安裝好 Solaris 10。接下來該如何做？

我想要配置 Configuration Agent。請問該如何做？

我想要啟用 Configuration Agent。請問該如何做？

我已配置並啟用了 Configuration Agent。要如何知道其是否運作？

為何要啟用 Configuration Agent？

我如何得知啟用 Configuration Agent 與否？

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

記錄檔位於何處？

我該如何提升代理程式記錄機制的詳細程度？

何謂維護模式？

如何離開維護模式，亦即清除 smf(5) 狀態？

Configuration Agent 未預期地停止執行；請問發生了何種狀況？

啟用/啟動代理程式之後，是否需要重新啟動桌面用戶端應用程式？

桌面用戶端應用程式似乎未使用配置的策略。我該如何做？

啟動 Configuration Agent 時發生問題

無效或無法存取的代理程式資料目錄

使用忙碌中的用戶端請求連接埠

使用忙碌中的管理連接埠

從執行中之 Configuration Agent 取得策略的問題

缺少配置儲存庫規格或其無效

無法連線至策略儲存庫

連線至未經配置的策略儲存庫

我在 Configuration Agent 記錄中看到「用戶端連線的最大數目」訊息。請問這代表什麼意思？

我使用 Desktop Manager 修改了一些策略，但在我的用戶端機器上看不到這些修改。

第 3 章用戶端元件