|
| |
| Sun Java System Calendar Server 管理指南 | |
第 4 章
移植实用程序安装 Calendar Server 并对其进行配置之后，您可能需要移植组件数据库和 LDAP 数据库。Calendar Server 提供了若干移植实用程序，用于将早期版本中的数据库移植到当前版本中。本章提供了移植实用程序流程图，帮助您选择运行的合适的实用程序。
本章包含以下小节：
Calendar Server 移植实用程序概述Calendar Server 6 2004Q2 提供了两种类型的数据库移植实用程序：
组件数据库移植实用程序
组件数据库包含所有日历用户和日历资源的事件和待办事件。以下实用程序用于移植组件数据库：
如果已安装 Calendar Server 6.0 (2003Q4) 并要将其升级到 Calendar Server 6 2004Q2，则无需运行此实用程序。首次访问 Berkeley 数据库时，该数据库将自动从 Berkeley 3.2.9 版更新到 4.2 版。
在 csmig、csvdmig 和 commdirmig 之前运行此程序。
可在移植 Web 站点获得此实用程序。请参阅移植 Web 站点。
由于此周期性版还将执行与基本版一样的功能，您无需首先运行此实用程序的基本版。即，周期性版将 Calendar Server 5.x 数据库移植至 Calendar Server 6，并将日历数据库从 Berkeley DB 2.6 版升级至 4.2 版。此外，为了能够在 Outlook 中查看这些事件，此周期性版将现有周期性事件转换为带有异常的主记录。
可在移植 Web 站点获得此实用程序。请参阅移植 Web 站点。
- ics2migrate — 将数据从 iPlanet Calendar Server 2.x 移植到 iPlanet Calendar Server 5.x。此实用程序与 Calendar Server 5.1.1 捆绑在一起。
- ncs4migrate — 将数据从 Netscape Calendar Server 4.x 移植到 Netscape Calendar Server 5.x。可在移植 Web 站点获得此实用程序。请参阅移植 Web 站点。
LDAP 数据库移植和升级实用程序
LDAP 数据库包含验证（用户和资源条目）以及日历首选项信息。以下实用程序用于升级或移植 LDAP 数据：
- csmig — 为 Calendar Server 6.x 数据库中的每个日历指定一个属主，并将每个日历 ID (calid) 映射到一个属主（如果需要），这可以支持托管（虚拟）域和 LDAP 日历查找数据库 (CLD) 插件。此实用程序打包在 Calendar Server 中。在 cs5migrate 之后，在 csvdmig 之前运行此实用程序。
- csvdmig — 升级 Calendar Server 6.x 站点以使用托管（虚拟）域，方法是将日历的域 (@domainname) 添加到每个 calid。例如，在域 sesta.com 中，jdoe 的calid 应该为 jdoe@sesta.com。此实用程序打包在 Calendar Server 中。在 cs5migrate 和 csmig 之后运行此实用程序。
- commdirmig 实用程序 — 将 LDAP 数据从模式 1 移植到模式 2，为与 Identity Server 6.1（或更高版本）配套使用做好准备。此移植实用程序在单独的文档指南中有说明，请参阅以下站点中的 Sun Java System Communications Services Schema Migration Guide：
http://docs.sun.com/coll/CalendarServer_04q2 和
http://docs.sun.com/coll/CalendarServer_04q2_zh如果之前使用的是 Messaging Server 5.x 或 Calendar Server 5.x，则您的 LDAP 条目的格式为 Sun LDAP 模式 1。在新的 Calendar Server 6 2004Q2 环境中，如果要使用 Identity Server 来进行验证，则必须运行此实用程序将 LDAP 条目转换为模式 2 格式。
如果要从 Java Enterprise System 之前的 Calendar Server 版本移植，请在运行 cs5migrate、csmig 和 csvdmig 之后运行此实用程序。
在 Sun Java Enterprise System 2004Q2 中，此实用程序与 Identity Server 6.2 (2004Q2) 以及置备实用程序 commadmin 捆绑在一起。
如果不打算更新 Identity Server 并且只需要用于 Calendar Server 6.0 (2003Q4) 的移植实用程序，可从技术支持处获得此实用程序的修补程序。
移植实用程序流程图由于有许多实用程序可供选择，图 4-1 显示了一个流程图，用于帮助您决定使用这些实用程序的顺序。
图 4-1 运行 Calendar Server 移植实用程序的流程图
安装了 Calendar Server 6.x 并运行 cs5migrate 后，请从其他移植实用程序中选择要运行哪些实用程序（如果需要）。图 4-2 显示了不同的配置方案以及每种配置方案要运行的移植实用程序。
图 4-2 配置方案
移植 Web 站点为了进一步帮助您根据特定站点作出正确选择，您可以从技术支持处（引导您进入 Web 站点）下载附加信息和实用程序。
在 Web 站点，将要求您回答一个简单的调查表，该调查表将帮助您决定使用何种实用程序，并帮助您计算移植进程可能导致的停机时间。
警告 如果您的站点已针对受限的虚拟域模式或多个 Calendar Server 实例进行配置，请与 Sun Microsystems Inc. 销售代表联系，以获得移植要求的评估，并确保您安装了满足这些要求的特定移植实用程序。
在某些情况下，您可咨询 Sun Microsystems 技术支持或专业服务以获得帮助。
注意 即使 cs5migrate 与 Calendar Server 产品捆绑在一起，如果您尝试运行此实用程序，屏幕将显示以下消息：
!!!!!!!!!!请注意!!!!!!!!!!
要移植到 Calendar Server 6.0，请联系 Sun Microsystems 技术支持或销售代表以获得此实用程序的最新版本。
ics2migrateics2migrate 实用程序可以将 iPlanet Calendar Server 2.x 日历数据和 LDAP 用户首选项移植到 Sun ONE Calendar Server 5.x。
本节包括以下内容：
移植要求
从 Calendar Server 2.x 移植到 6.x 需要满足以下硬件和软件要求：
源计算机和目标计算机可以是不同的服务器，也可以是同一服务器。有关支持的平台列表，请参阅《Sun Java System Calendar Server 发行说明》。
移植内容
下表列出了 Calendar Server 2.x 数据，并说明了 ics2migrate 如何将这些数据移植至 Calendar Server 6.x。
下表列出了 Calendar Server 2.x LDAP 属性，并说明了 ics2migrate 如何将这些属性移植至 Calendar Server 6.x。
移植过程
从 2.x 移植到 5.x：
警告 运行 ics2migrate 之前，请先使用 csbackup、Sun StorEdge Enterprise Backup™ 软件或 Legato Networker® 等实用程序备份日历数据库。
备份日历数据库非常重要，因为 db_upgrade 将升级其当前目录中的数据库。如果在升级过程中出现问题，您的数据库可能会处于不可恢复的状态。
在 2.x Berkeley 数据库中运行 db_recover
运行 Berkeley DB db_recover 实用程序，可以在转换数据库之前将日志文件事务合并到数据库中。如果不使用此实用程序，将丢失未合并的事务。
下载和安装 Calendar Server 5.1.1
请参阅以下地址的 iPlanet Calendar Server 5.1 Installation Guide：
http://docs.sun.com/db/doc/816-5516-10
升级 2.x 日历数据库
Calendar Server 5.1.1 需要 Sleepycat Software 公司的 Berkeley DB 3.2.9 版。运行 ics2migrate 之前，您必须使用 Berkeley DB db_upgrade 实用程序，以将您的日历数据库升级到 3.2.9 版。Calendar Server 5.x 在以下目录中包括 Berkeley DB 实用程序：
cal_svr_base/opt/SUNWics5/cal/tools/unsupported/bin
有关 Berkeley DB 实用程序的更多信息，请访问以下 Web 站点：
http://www.sleepycat.com/docs/utility/index.html
将数据库升级到 3.2.9 版的步骤：
- 在 Solaris 和其他 UNIX 系统中，以 Calendar Server 运行时所用的用户和组的身份登录（例如，icsgroup 和 icsuser）。
- 如果需要，请停止 2.x Calendar Server。
- 如果还没有备份您的 2.x 日历数据库，请执行此操作。
- 删除以下目录中所有旧的共享 (__db_name.share) 文件或日志 (log.*) 文件：
cal_svr_base/opt/SUNWics5/cal/lib/http
cal_svr_base/var/opt/SUNWics5/csdb
- 运行 db_upgrade 实用程序，以将您的 2.x 日历数据库升级到 3.2.9 版。如果不在与 2.x 日历数据库相同的目录中，请使用 -h 选项指向数据库文件。
注意 您必须对所有 2.x 数据库文件（alarms.db、calprops.db、events.db 和 todos.db）运行 db_upgrade。还必须对 Calendar Server 配置中的所有前端和后端服务器运行 db_upgrade，即使某个服务器未直接连接到日历数据库。
- 在带有数据库文件的 csdb 目录中查找 Calendar Server 2.x caldb.conf 文件，并按以下方式更改文件中的第一行：
原有值： caldb.version "1.0.0 [BerkeleyDB]"
新值： caldb.version= "1.0.0 [BerkeleyDB]"
注意 如果此文件不在 csdb 目录中，请使用文本编辑器创建此文件，然后将第一行设置为新值。
移植数据（运行 ics2migrate）
请按以下步骤运行 ics2migrate：
- 转到 ics2migrate 所在的目录。
- 使用 ics2migrate 语法中的语法运行 ics2migrate：
- 移植后，确保 ics.conf 文件中的 caldb.berkeleydb.homedir.path 参数指向已移植的数据库。
- 运行 csdb check 命令。如果需要，运行 csdb rebuild 命令重新建立日历数据库。
ics2migrate 语法
要移植 Calendar Server 2.x 数据库和 LDAP 用户首选项
要仅移植 Calendar Server 2.x 数据库
要仅移植 LDAP 用户首选项
表 4-3 列出了 ics2migrate 选项以及每个选项的说明。
检查移植结果
移植完成后，请检查结果：
移植示例
本节包含关于以下主题的示例：
在静默模式下移植
除运行在静默模式下以外，其他移植操作与前面的示例相同。ics2migrate 不在控制台显示移植统计数据，也不生成日志文件。
ics2migrate -q /var/opt/SUNWicsrv/2x_db /var/opt/SUNWics5/50_db
仅移植日历数据库
仅移植存储在 2x_db 目录（相对于当前目录）中的 2.x 日历数据库，并在 /var/opt/SUNWics5/50_db 目录中创建 6.0 数据库。
ics2migrate -m db 2x_db /var/opt/SUNWics5/50_db
仅移植 LDAP 用户信息
仅将 Calendar Server 2.x LDAP 用户信息移植至 6.0 版格式。
ics2migrate -m ldap
移植日历数据库和 LDAP 用户信息
移植 LDAP 用户信息和 Calendar Server 2.x 数据库。Calendar Server 2.x 数据库存储在 /var/opt/SUNWicsrv/2x_db 目录中，6.0 数据库存储在 /var/opt/SUNWics5/50_db 目录中。
可访问所有日历的时间安排和空闲/繁忙情况，并将最小移植统计数据记录到名为 ics2migrate.log 的日志文件中。
ics2migrate /var/opt/SUNWicsrv/2x_db /var/opt/SUNWics5/50_db -l min
csmigcsmig 实用程序为日历数据库中的每个日历指定属主，并将每个日历 ID (calid) 映射到一个属主（如果需要）。
csmig 实用程序支持托管（虚拟）域和 LDAP Calendar 查找数据库 (CLD) 插件。使用此插件可以访问已移植数据库中的日历。LDAP CLD 插件通过允许日历在许多后端服务器上分布来提供日历数据库的水平可伸缩性。有关 LDAP CLD 插件的信息，请参阅《Sun Java System Calendar Server 6 2004Q2 管理指南》。
本节介绍以下主题：
csmig 的功能
csmig 移植实用程序执行以下功能：
csmig 的要求
使用 csmig 的要求为：
csmig 语法
csmig 实用程序的语法如下：
csmig [ -t DestinationDB ] [ -b Backend-DWPHost ]
[ -o OutputFile ] [ -e ErrorFile ] [ -m MappingFile ]
-c calendarOwner -r resourceOwner { migrate|dryrun }
-t DestinationDB 指定 csmig 生成的目标数据库。默认值为 MigratedDB。
-b Backend-DWPHost 指定 DWP 后端主机服务器的名称。此名称必须与 ics.conf 文件中指定的 DWP 后端主机服务器名称相匹配。
-o OutputFile 指定输出文件，此文件捕获 csmig 输出到屏幕的信息以及出现的任何错误。默认值为 MigrateOut。
-e ErrorFile 是 csmig 向其中写入无法解决的错误或数据库项的文件。如果数据库项无法解决，则不将它们写入目标数据库。默认值为 MigrateError。
-m MappingFile 是在 dryrun 模式下生成的输出映射文件，它列出了 LDAP 模式中需要更改的条目。例如：
Old calid = jsmith New calid = jsmith:basketball
映射文件中仅仅提供要对 LDAP 模式进行的更改列表，但实际上 csmig 并没有更改模式。
在 migrate 模式中，不使用 MappingFile。
-c calendarOwner 为不具有属主的用户日历指定属主。
-r resourceOwner 为不具有属主的资源日历指定属主。
csmig 移植步骤
在配置中的所有服务器上都安装 Calendar Server 6.0 之后，必须运行 csmig，将现有 Calendar Server 和 LDAP 数据移植至新的 Calendar Server 6.0 和 LDAP 数据，这是 LDAP CLD 插件正常工作所必需的。要使用 csmig 移植日历数据，请按照以下步骤执行操作：
- 配置 LDAP 目录服务器 — 添加索引可以显著提高对 LDAP 数据进行移植和日历搜索的性能。
- 执行模拟运行测试 (Test Dry Run) — 模拟运行 (Dry Run) 报告 csmig 在移植过程中将会执行的操作，但实际上 csmig 并没有移植任何数据。模拟运行 (Dry Run) 之后，您可以更正任何错误，并确定处理任何未解决的日历的计划。
- 移植产品数据 — 在实际运行过程中，csmig 将移植日历数据库（.db 文件）和 LDAP 数据（用户和组首选项数据）、icsSubscribed、icsCalendar、icsCalendarOwned、icsFreeBusy、icsSet 和 uid（用于资源日历）。移植之后，将为所有日历资源创建 LDAP 项。
配置 LDAP 目录服务器
为了提高性能，请考虑向 slapd.ldbm.conf 文件添加以下两个新索引：
有关在 slapd.ldbm.conf 文件中创建索引的信息，请参阅目录服务器文档。
执行模拟运行测试 (Test Dry Run)
在分步服务器上执行模拟运行测试 (Test Dry Run) 后报告将会移植的内容，但它实际上并不对产品数据库进行移植。模拟运行 (Dry Run) 允许您确定移植产品数据库的计划。例如，您可以确定处理“orphan”日历（该日历不具有属主）的方式。
要使用 csmig 执行模拟运行测试 (Test Dry Run)，请执行以下步骤：
- 以 icsuser（或在配置过程中指定的 Calendar Server 运行时用户 ID）身份登录。如果您以超级用户（root 用户）身份运行 csmig，则可能需要重置已移植文件的权限。
- 在分步服务器上安装 Calendar Server 6.0（如果需要）。
- 将日历数据库的快照复制到分步服务器。
- 安装 LDAP 服务器以模仿产品 LDAP 环境。使用 slapd.ldbm.conf 文件中的新索引在此服务器上安装 LDAP 数据库的快照。
- 转到 cal_svr_base/opt/SUNWics5/cal/sbin 目录。
- 考虑为不具有属主的用户日历创建通用的 calid。例如，在 Solaris 系统中，以下命令将创建 calid 为 orphan 的用户：
./csuser -g orphan -s adminuser -y password -l en -c orphan create orphan
- 使用 stop-cal 命令停止 Calendar Server（如果需要）。
- 运行 csdb check 命令检查数据库是否损坏。如果该命令检测出数据库已损坏，则运行 csdb rebuild 以重新建立数据库。
- 带 dryrun 选项运行 csmig。例如，在 Solaris 系统中输入以下内容：
./csmig -b sesta.com -o csmig.out -e csmig.errors -m csmig.map -c orphan -r calmaster dryrun
此命令将不具有属主的用户日历指定给 orphan，将不具有属主的资源日历指定给 calmaster。
查看输出映射文件 (csmig.map)。映射文件列出了 LDAP 模式中需要更新的条目。
- 检查输出、映射和出错文件。解决发现的任何 LDAP 问题或错误。在进行实际的移植之前，确定如何处理未解决的日历。有以下若干选择：
- 在移植实际的产品日历数据库之前，请在分步服务器上移植日历数据库。执行此步骤，您可以切实了解移植数据的方式，并可以在移植产品数据库之前更正任何问题。
例如，在 Solaris 系统中，以下命令将日历数据库移植至 /var/opt/SUNWics5/testcsdb/ 目录：
./csmig -t /var/opt/SUNWics5/testcsdb/ -b sesta.com -o csmig.out -e csmig.errors -m csmig.map -c orphan -r calmaster migrate
- 移植测试完成之后，将移植的数据库复制到 caldb.berkeleydb.homedir.path 参数指定的 /csdb 目录。或者编辑此参数，使其指向移植的数据库的新位置。然后进行以下检查：
如果成功完成了移植测试，则可以开始移植产品数据库。
移植产品数据
要使用 csmig 移植产品数据库，请执行以下步骤：
- 以 icsuser（或在配置过程中指定的 Calendar Server 运行时用户 ID）身份登录。如果您以超级用户（root 用户）身份运行 csmig，则可能需要重置已移植文件的权限。
- 转到 cal_svr_base/opt/SUNWics5/cal/sbin 目录。
- 使用 stop-cal 命令停止 Calendar Server（如果需要）。
- 备份以下数据：
- 带 migrate 选项运行 csmig。例如，在 Solaris 系统中，以下命令将日历数据库移植至 /var/opt/SUNWics5/newcsdb/ 目录：
./csmig -t /var/opt/SUNWics5/newcsdb/ -b sesta.com -o csmig.out -e csmig.errors -m csmig.log -c orphan -r calmaster migrate
- 检查错误文件中是否存在未解决的日历，并根据执行模拟运行测试 (Test Dry Run) 下步骤 10 中的计划进行解决。
- 将新移植的数据库复制到 caldb.berkeleydb.homedir.path 参数指定的 /csdb 目录中。或者编辑此参数，使其指向移植的数据库的新位置。
- 运行 csdb check 命令以检查移植的数据库。如果该命令检测出数据库已损坏，则运行 csdb rebuild 以重新建立数据库。
- 通过对 ics.conf 文件中的以下配置参数进行必要的更改，以启用 LDAP CLD 插件：
- service.dwp.enable = "yes"
- service.dwp.port = "9779"
- csapi.plugin.calendarlookup = "y"
- csapi.plugin.calendarlookup.name = "*"
- caldb.cld.type = "directory"
- caldb.dwp.server.default = "default-server-name"
- caldb.dwp.server.server-hostname.ip = "server-hostname"（用于包含本地服务器的每个后端服务器）
- caldb.cld.cache.enable = "yes"（如果要使用 CLD 缓存选项）
- caldb.cld.cache.homedir.path 指定 CLD 缓存目录的位置。默认值为 cal_svr_base/var/opt/SUNWics5/csdb/cld_cache。
- 使用 start-cal 命令重新启动 Calendar Server。
- 登录到 Calendar Server，并通过检查若干移植的日历来验证配置是否生效。要在检查时禁用报警，请将 ics.conf 文件中的以下参数都设置为“no”：
csmig 提示和疑难解答
本节包括以下提示和疑难解答解决方法：
csmig 模拟运行 (Dry Run) 日历的属主不是我所希望的日历属主
例如，名为 tchang:myCalendar 的日历的属主在日历数据库中为 jsmith，csmig 模拟运行 (Dry Run) 将映射显示为 jsmith:tchang_myCalendar。我希望将此日历的名称保持为 tchang:myCalendar，并将 tchang 指定为属主。
解决方法
在移植之前，使用 cscal 实用程序将 tchang:myCalendar 日历的属主更改为 tchang。执行此操作后，移植操作会将此日历映射为 tchang:myCalendar，并向 tchang 的 LDAP 项添加 icsCalendarowned。
LDAP 日历搜索无法正常工作
移植之后，将启用 LDAP 日历搜索，但日历搜索对话框不返回任何结果，或仅返回部分结果。
解决方法
启用 LDAP 日历搜索后，Calendar Server 可以搜索 (&(objectclass=icscalendaruser)(icscalendarowned=*substr*))。
使用以下过滤器对 LDAP 数据手动运行两个不同的搜索，并比较输出结果：
因为服务器使用包含 icsCalendaruser 对象类的过滤器，所以可能已在禁用模式检查的情况下部署了 LDAP 服务器，并且可能在没有 icsCalendaruser 对象类的情况下已经置备了某些日历项。
csmig 模拟运行 (Dry Run) 指示重复的日历名称
csmig 模拟运行 (Dry Run) 映射文件和输出文件指示存在重复的日历名称。例如，在初始数据库中，jsmith 拥有以下日历：
模拟运行 (Dry Run) 指示在移植时将合并这两个日历，生成的日历将为
输出文件将包含以下警告消息：
修改日历属性时出错，错误数 = 2
解决方法
如果不希望合并两个日历，则在移植之前将 basketball 的属主更改为 jsmith 以外的用户。这可以保持这两个独立日历数据的完整性。
如何将不带有属主的日历指定给不同的属主？
默认情况下，csmig 将所有不带有属主的日历指定给一个属主，但是我希望为其中的某些日历指定不同的属主。
解决方法
csmig 不接受命令行中的映射文件。但是，可以在移植之前为初始数据库中不带有属主的日历指定属主。检查所有不带有属主的日历的模拟运行 (Dry Run) 映射文件。然后在移植之前使用 cscal 实用程序为不带有属主的日历指定属主。在 dryrun 模式下再次运行 csmig 以验证新的属主。
如何将日历用户移动到其他后端服务器？
如何将用户从一个后端服务器移动到另一个后端服务器？
解决方法
要移动日历用户，应导出初始服务器上该用户的每个日历，然后将日历导入到第二个服务器。移动日历后，可以删除初始服务器上的日历。有关移动用户的详细步骤，请参阅《Sun Java System Calendar Server 6 2004Q2 管理指南》。
csvdmigcsvdmig 实用程序为要使用托管（虚拟）域的工作地点修改 Calendar Server 数据库和 LDAP 目录服务器数据库。csvdmig 实用程序按以下方式将域名添加到用户 ID：
csvdmig 语法
csvdmig 实用程序的语法如下：
-m MappingFile 是输入参数，用于指定映射文件。默认值为 MigrateMapping。
映射文件是输入文本文件，可将现有用户映射到其各自的域。运行 csvdmig 之前，您必须创建映射文件。每行指定一个条目，在旧值和新值之间留有一个空格。例如：
user1 user1@sesta.com
user2 user2@siroe.com
user3 user3@sesta.com
...
user-n user-n@siroe.com-c ConfigFile 是输入参数，用于指定 Calendar Server 配置文件。默认值为 ics.conf 文件。
-t DestinationDB 是输出参数，用于指定被移植的数据库的位置。默认值为 MigratedDB。
-e ErrorFile 是输出参数，用于为无法解决的错误指定错误文件的名称。默认值为 MigrateError。
DB | LDAP 指定是修改 Calendar Server 数据库 (DB) 还是修改 LDAP 目录服务器 (LDAP)。默认值为日历数据库 (DB)。
csvdmig 示例
