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所示。

portal開發與配置技巧集錦7090.png

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

 單擊Custom properties(自定義屬性)”,編輯如圖1-27所示的三個屬性值。

portal開發與配置技巧集錦7192.png

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數據庫失敗

1.7.1  問題描述

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

1.7.2  解決方案

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

1Oracle版本號不是受Portal 6.1支持的正確版本號,尤其是小版本號。

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

2WAS對交易超時的設置不恰當。

WAS默認設置的交易超時時間爲130秒,而PortalOracle數據傳輸的過程有很多事務是超過180秒的,這導致傳輸過程中由於交易超時而使得某些線程掛起,將這個超時時間改爲300秒以上再執行傳輸過程,就可以避免出現這個問題。

3Portal數據庫管理員在Oracle中不具備創建視圖的權限。

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

1.8  配置Portal 6.1使用Novell LDAP作爲Portal的安全機制

1.8.1  問題描述

配置Portal 6.1使用Novell LDAP並作爲Portal的用戶註冊表和安全認證機制,配置過程是成功的,但是在Portal管理控制檯創建出的用戶、用戶組無法搜索出來。

1.8.2  解決方案

經過檢查,發現用戶在配置過程中存在以下問題。

LDAP用戶在被Portal搜索時設置的過濾條件太多了,用戶按照自己的設置文檔定義了“LDAP entity types”的8個屬性,這8個屬性在Portal管理員搜索用戶時作爲搜索的過濾條件。事實上,產品要求只需要兩個過濾條件,這兩個過濾條件是:

standalone.ldap.et.group.objectClasses=groupOfNames

standalone.ldap.et.personaccount.objectClasses=inetOrgPerson

改正的辦法是刪除已有的8個屬性,並添加或更新爲以上兩個屬性。修改完這兩個參數後,再次搜索用戶、用戶組,上述問題就解決了。

1.9  對portal集羣執行同步

1.9.1  問題描述

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

1.9.2  解決方案

1.9.2.1  強制同步

 wpsadmin身份登錄WAS管理控制檯,如圖1-28所示。

portal開發與配置技巧集錦8741.png

1-28  登錄管理控制檯

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

portal開發與配置技巧集錦8817.png

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

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

portal開發與配置技巧集錦8856.png

1-30  開始同步

 經過12個小時,系統同步完成。

1.9.2.2  自動同步

在圖1-29所示的頁面上,檢查Portal集羣的每個節點dmgrDeployment Manager)節點的設置文件是否匹配,並確保跨單元配置數據的一致性。具體操作步驟如下。

 登錄管理控制檯,單擊系統管理”→“Node Agent”→“node_agent_name ”→“文件同步服務

 選擇配置選項卡

 服務器啓動時啓用服務

 指定服務器是否嘗試啓動文件同步服務。此設置不會導致啓動文件同步操作。在默認情況下,此設置已啓用。

數據類型

布爾

默認

true

 指定同步間時間(以分鐘計)。默認值爲1分鐘。

數據類型

整型

單位

分鐘

默認

1

應用程序服務器使用的最小值爲 1。如果指定的值爲0,則應用程序服務器忽略該值並使用默認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重新啓動時,對排除列表所的更改生效。

數據類型

字符串

單位

文件名或模式


發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章