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 ”→“ 文件同步服务 ” 。

  选择 “ 配置 ” 选项卡 。

  服务器启动时启用服务 。

  指定服务器是否尝试启动文件同步服务。此设置不会导致启动文件同步操作。 在默认 情况下，此设置已启用。

  指定同步间 隔 时间（以分钟计）。 默认 值为 1 分钟。

  设置 自动同步 。 指定是否在指定的时间间隔后自动同步文件。当此设置启用时， Node Agent 在每次同步时间间隔中自动联系 Deployment Manager ，尝试同步节点的配置库和 Deployment Manager 拥有的主库。

如果启用自动同步设置，则 Node Agent 在与 Deployment Manager 建立联系时尝试文件同步。 Node Agent 在尝试下一次同步之前等待同步时间间隔。

如果要控制文件发送到节点的时间， 则取消选中 “自动同步时间” 复选框。

  启动同步指定 Node Agent 是否在启动应用程序服务器之前尝试同步节点配置和主库中的最新配置。

默认 为在启动应用程序服务器之前不同步文件。启用设置确保 Node Agent 具有最新配置，但增加了启动应用程序服务器所花费的时间量。

注意：此设置不影响 startServer 命令。 startServer 命令直接启动服务器 , 并且不使用 Node Agent 。

  排除 。 指定不应是配置数据同步的一部分文件或模式。此列表中的文件不从主配置库中复制到节点，并且不从节点上的库中删除。

  默认 为未指定文件。 iSeries 用户 的默认 值是 */plugin-cfg.xml ，它从 Web 服务器插件配置文件 中自动同步 。

要指定文件， 应 使用完整的名称或 者 以通配符 * （ 星号）开头或结尾的名称。例如：

在每个条目结尾处按下 “ Enter ”键， 每行出现一个文件名。

因 为这些字符串表示逻辑文 件 位置而不是实际的文件路径，所以无论是什么平台，只需要正斜杠。

当 Node Agent 重新启动时，对排除列表所 做 的更改生效。