Portal開發與配置技巧集錦（三）

1. 6  Portal 6.1.0.3無法查詢任何使用者或使用者組

1. 6.1   問題描述

Portal 系統升級到 6.1.0.3 之後，無法搜尋任何使用者或使用者組，所體現的功能模組有： WCM 授權、 WCM 管理、 PDM 管理，凡使用到 People Picker Page 的地方，都不行。

1. 6.2   解決方案

這 是由於 Portal 6.1.0.3 的升級程式可能不慎修改了 People Picker Portlet 的屬性值，導致該 Portlet 無法查詢到合適的使用者或使用者組，我們必須手工去修正這個問題。修正該問題的步驟如下。

  以 WAS 超級管理員（一般是 wpsbind ）身份登入 WAS 管理控制檯。

  單擊 “ Resource （資源）”→“ Resource Environment （資源環境）”→“ Resource Environment Providers （環境資源提供程式）”，找到“ WP PeopleService ”條目，如圖 1- 26 所示。

圖 1- 26  PeopleFinder 的屬性缺少導致許多 Portal 版本出現人員和組織無法查詢的問題

  單擊 “ Custom properties （自定義屬性）”，編輯如圖 1- 27 所示的三個屬性值。

圖 1- 27   修改資源提供程式裡的 PeoplePicker 屬性

  要確保這三個值與 LDAP 中的屬性值相對應。例如：

Name       Value

pickerPeopleSearchAttribute   cn,displayName,sn,uid

pickerGroupSearchAttribute   cn,displayName,sn,givenName

configurePeoplePickerSearch   true

  重啟 Portal 伺服器，驗證是否可以正常工作。

1. 7  配置Portal 6.1使用Oracle資料庫 失敗

7.1   問題描述

配置 Portal 6.1.0.0 使用 Oracle 資料庫並將 Portal 資料從預設資料庫遷移到 Oracle 時失敗。多種原因都會導致出現這個問題，但以下提到的三個問題是經常發生的，出現遷移失敗時，請首先確定這個問題。

7.2   解決方案

工程師在配置過程中，以下三個問題是經常發生的，它們會導致 Oracle 資料庫遷移失敗。

（ 1 ） Oracle 版本號不是受 Portal 6.1 支援的正確版本號，尤其是小版本號。

例如，使用者安裝的 Oracle 版本號是 10.2.0.0 ，但是 Portal 6.1 支援的版本號是 10.2.0.1 ，這個小補丁的差距就會導致遷移失敗。

（ 2 ） WAS 對交易超時的設定不恰當。

WAS 預設設定的交易超時時間為 130 秒，而 Portal 對 Oracle 資料傳輸的過程有很多事務是超過 180 秒的，這導致傳輸過程中由於交易超時而使得某些執行緒掛起，將這個超時時間改為 300 秒以上再執行傳輸過程，就可以避免出現這個問題。

（ 3 ） Portal 資料庫管理員在 Oracle 中不具備建立檢視的許可權。

用 戶在建立 Oracle 資料庫表空間的過程中，沒有對指定的 Portal 資料庫管理員賦予管理員許可權，導致資料傳輸由於許可權不足而失敗。在 Oracle 中指定該許可權後再次傳輸，可以避免該問題的出現。

8  配置Portal 6.1使用Novell LDAP作為Portal的安全機制

8.1  問題描述

配置 Portal 6.1 使用 Novell LDAP 並作為 Portal 的使用者登錄檔和安全認證機制，配置過程是成功的，但是在 Portal 管理控制檯建立出的使用者、使用者組無法搜尋出來。

.2   解決方案

經過檢查，發現使用者在配置過程中存在以下問題。

LDAP 使用者在被 Portal 搜尋時設定的過濾條件太多了，使用者按照自己的設定文件定義了“ LDAP entity types ”的 8 個屬性，這 8 個屬性在 Portal 管理員搜尋使用者時作為搜尋的過濾條件。事實上，產品要求只需要兩個過濾條件，這兩個過濾條件是：

standalone.ldap.et.group.objectClasses=groupOfNames

standalone.ldap.et.personaccount.objectClasses=inetOrgPerson

改正的辦法是刪除已有的 8 個屬性，並新增或更新為以上兩個屬性。修改完這兩個引數後，再次搜尋使用者、使用者組，上述問題就解決了。

9  對portal叢集執行同步

1. 9.1   問題描述

對叢集執行了 Portlet 安裝、主題與皮膚安裝、引數配置等之後，發現再次訪問時沒有起作用。這通常是由於沒有執行叢集同步導致的。做完以上工作後必須執行叢集同步。執行同步有兩種方法：一是強制（手工）同步；二是自動同步。

1.9 .2   解決方案

9.2.1   強制同步

  以 wpsadmin 身份登入 WAS 管理控制檯，如圖 1- 28 所示。

圖 1- 28   登入管理控制檯

  依次單擊 “系統管理”→“節點”出現現有的節點列表。選中要同步的兩臺機器，然後單擊“同步”按鈕，如圖 1- 29 所示。

圖 1- 29   選中要同步的兩臺機器

  系統開始同步，如圖 1- 30 所示。

圖 1- 30   開始同步

  經過 1 ～ 2 個小時，系統同步完成。

.2.2   自動同步

在圖 1- 29 所示的頁面上，檢查 Portal 叢集的每個 節點 與 dmgr （ Deployment Manager ）節點的 設定檔案 是否 匹配，並確保跨單元配置資料的一致性。 具體操作步驟如下。

  登入 管理控制檯，單擊 “ 系統管理 ”→“ Node Agent ”→“ node_agent_name ”→“ 檔案同步服務 ” 。

  選擇 “ 配置 ” 選項卡 。

  伺服器啟動時啟用服務 。

  指定伺服器是否嘗試啟動檔案同步服務。此設定不會導致啟動檔案同步操作。 在預設 情況下，此設定已啟用。

資料型別	布林
預設 值	true

  指定同步間 隔 時間（以分鐘計）。 預設 值為 1 分鐘。

資料型別	整型
單位	分鐘
預設 值	1 應用程式伺服器使用的最小值為 1 。如果指定的值為 ，則應用程式伺服器忽略該值並使用 預設 值 1 。

  設定 自動同步 。 指定是否在指定的時間間隔後自動同步檔案。當此設定啟用時， Node Agent 在每次同步時間間隔中自動聯絡 Deployment Manager ，嘗試同步節點的配置庫和 Deployment Manager 擁有的主庫。

如果啟用自動同步設定，則 Node Agent 在與 Deployment Manager 建立聯絡時嘗試檔案同步。 Node Agent 在嘗試下一次同步之前等待同步時間間隔。

如果要控制檔案傳送到節點的時間， 則取消選中 “自動同步時間” 核取方塊。

資料型別	布林
預設 值	true

  啟動同步指定 Node Agent 是否在啟動應用程式伺服器之前嘗試同步節點配置和主庫中的最新配置。

預設 為在啟動應用程式伺服器之前不同步檔案。啟用設定確保 Node Agent 具有最新配置，但增加了啟動應用程式伺服器所花費的時間量。

 

注意：此設定不影響 startServer 命令。 startServer 命令直接啟動伺服器 , 並且不使用 Node Agent 。

 

資料型別	布林
預設 值	false

  排除 。 指定不應是配置資料同步的一部分檔案或模式。此列表中的檔案不從主配置庫中複製到節點，並且不從節點上的庫中刪除。

  預設 為未指定檔案。 iSeries 使用者 的預設 值是 */plugin-cfg.xml ，它從 Web 伺服器外掛配置檔案 中自動同步 。

要指定檔案， 應 使用完整的名稱或 者 以萬用字元 * （ 星號）開頭或結尾的名稱。例如：

cells/cell name/nodes/node name/file name	排除此特定檔案
*/file name	排除任何上下文中名為 file name 的檔案
dirname/*	排除 dirname 以及 dirname 下面的子屬性

在每個條目結尾處按下 “ Enter ”鍵， 每行出現一個檔名。

因 為這些字串表示邏輯文 件 位置而不是實際的檔案路徑，所以無論是什麼平臺，只需要正斜槓。

當 Node Agent 重新啟動時，對排除列表所 做 的更改生效。

資料型別	字串
單位	檔名或模式