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数据库失败

1.7.1  问题描述

配置Portal 6.1.0.0使用Oracle数据库并将Portal数据从默认数据库迁移到Oracle时失败。多种原因都会导致出现这个问题，但以下提到的三个问题是经常发生的，出现迁移失败时，请首先确定这个问题。

1.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中指定该权限后再次传输，可以避免该问题的出现。

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

图1-28  登录管理控制台

 依次单击“系统管理”→“节点”出现现有的节点列表。选中要同步的两台机器，然后单击“同步”按钮，如图1-29所示。

图1-29  选中要同步的两台机器

 系统开始同步，如图1-30所示。

图1-30  开始同步

 经过1～2个小时，系统同步完成。

1.9.2.2  自动同步

在图1-29所示的页面上，检查Portal集群的每个节点与dmgr（Deployment 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重新启动时，对排除列表所做的更改生效。

数据类型	字符串
单位	文件名或模式

网站题目：portal开发与配置技巧集锦（三）
浏览路径：http://azwzsj.com/article/jsddge.html