Sun Java System Calendar Server 6.3 管理指南

3.5 csmig 实用程序

csmig 实用程序为日历数据库中的每个日历指定所有者，并将每个日历的 ID (calid) 映射到一个所有者（如果需要）。

csmig 实用程序支持多域和 LDAP 日历查找数据库 (Calendar Lookup Database, CLD) 插件。可以使用 LDAP CLD 插件访问已迁移的数据库中的日历。有关 LDAP CLD 插件的信息，参见第 5 章，在 Calendar Server 版本 6.3 中配置跨多个计算机的日历数据库分发。

本节介绍以下主题：

3.5.1 csmig 实用程序功能

csmig 迁移实用程序执行以下功能：

3.5.1.1 迁移日历

csmig 迁移由 caldb.berkeleydb.homedir.path 参数指定的当前日历数据库（*.db 文件）中的用户和资源日历。在新的目标数据库中，csmig 更新日历属性 (calprops)、事件、待办事项（任务）和组调度引擎 (Group Scheduling Engine, GSE) 数据库文件中的 LDAP CLD 插件所需的条目。

csmig 仅对目标数据库执行写入操作，而不更新现有日历数据库。

3.5.1.2 为日历指定所有者

csmig 为日历数据库中的每个日历指定所有者，并将每个日历的 ID (calid) 映射到一个所有者（如果需要）。所有默认的 calid 都保持不变，并且不进行任何更改。

其他日历按如下方式进行映射：

不具有有效所有者的用户日历将属于通过 -c 选项传递给 csmig 的用户。例如，如果日历 ID jsmith 没有所有者，它将被转换为 orphan:jsmith（其中 orphan 由 -c 选项指定）。
不具有所有者的资源日历将属于通过 -r 选项传递给 csmig 的资源用户。
如果资源日历的名称包含多个冒号 (:)，则冒号将被转换为下划线，并使迁移后的名称只包含一个冒号。

例如，所有者为 bkamdar 且名为 football 的日历将被转换为 bkamdar:football。所有者为 bkamdar 且名为 tchang:soccer 的日历将被转换为 bkamdar:tchang_soccer。所有者为 admin1 且名为 auditorium:room1 的资源日历将被转换为 admin1：auditorium_room1。

3.5.1.3 更新 LDAP 属性

csmig 更新所有相关的 LDAP 条目的 LDAP 属性，包括 icsSubscribed、icsCalendar、icsCalendarOwned、icsFreeBusy、icsSet 和资源日历的 uid。csmig 为 LDAP 目录服务器数据库中的每个日历创建 icsDWPHost 属性。icsDWPHost 指定日历驻留的后端服务器的主机名称。

3.5.2 csmig 实用程序要求

使用 csmig 的要求为：

日历数据库必须未被损坏。使用 csdb check 命令检查日历数据库；如果需要，运行 csdb rebuild 命令来重新建立数据库。有关这些命令的信息，请参见附录 D，Calendar Server 命令行实用程序参考。
您必须为新的目标数据库准备足够的磁盘空间。如果适用，也应为备份数据库准备足够的磁盘空间。
要运行 csmig，请以 icsuser（或以配置过程中指定的 Calendar Server 运行时用户 ID）身份登录。如果您以超级用户 (root) 身份运行 csmig，则可能需要重置已迁移文件的权限。

您还必须具有管理存储用户首选项的 LDAP Directory Server 中的日历用户属性的权限。
必须停止 Calendar Server。

3.5.3 csmig 语法

csmig 实用程序有以下语法：

csmig [-t DestinationDB]
      [-b Backend-DWPHost]
      [-o OutputFile]
      [-e ErrorFile]
      [-m MappingFile]
      [-c calendarOwner]
      [-r resourceOwner]
      { migrate|dryrun }

下表列出了实用程序选项，并给出了每个选项的说明和默认值。

csmig 选项	说明和默认值
`-t` `DestinationDB`	指定 `csmig` 生成的目标数据库。默认值为 `MigratedDB`。
`-b` `Backend-DWPHost`	指定 DWP 后端主机服务器的名称。该名称必须与 `ics.conf` 文件中指定的 DWP 后端主机服务器名称相匹配。
`-o` `OutputFile`	指定输出文件，此文件将捕获 `csmig` 输出到屏幕的消息以及出现的任何错误。默认值为 `MigrateOut`。
`-e` `ErrorFile`	`csmig` 向其中写入错误或无法解析的数据库条目的文件。如果数据库项无法解析，则不将它们写入目标数据库。默认值为 `MigrateError`。
`-m` `MappingFile`	指定 `dryrun` 模式下生成的输出映射文件，它列出了 LDAP 模式中需要更改的条目。例如：旧的：`calid=jsmith` 新的：`calid=jsmith:basketball` 映射文件仅提供了对 LDAP 模式所作的更改的列表。csmig 实际上并不对该模式进行这些更改。 `migrate` 模式中不使用该映射文件。
`-c` `calendarOwner`	为不具有所有者的用户日历指定所有者。
`-r` `resourceOwner`	为不具有所有者的资源日历指定所有者。
`migrate\|dryrun`	指定运行实用程序时所使用的模式。使用 `migrate` 模式执行迁移。在实际迁移之前，使用 `dryrun` 模式生成输出映射文件。

3.5.4 csmig 实用程序迁移步骤

如果拥有 Calendar Server 版本 5.1.1 之前的版本，则在安装和配置 Calendar Server 6.3 之后，运行 csmig 来迁移现有的 Calendar Server 和 LDAP 数据库。LDAP CLD 插件的正常工作需要进行 LDAP 数据的迁移。要使用 csmig 迁移日历数据，请按照以下步骤执行操作：

使用 csmig 的高级步骤

使用 comm_dssetup.pl 配置 Directory Server。

如果尚未使用 comm_dssetup.pl 为 LDAP 属性创建索引，则现在创建索引。这将大大提高 LDAP 数据迁移的性能。

请使用分步服务器（非产品服务器）执行模拟运行测试。

模拟运行会报告 csmig 在实际迁移过程中将要执行的操作，但模拟运行并不真地迁移任何数据。在模拟运行之后以及实际迁移之前，您可以更正任何错误，并确定处理任何未解析的日历的计划。

有关如何执行模拟运行测试的说明，参见3.5.4 csmig 实用程序迁移步骤。

迁移产品数据

在产品运行过程中，csmig 迁移日历数据库（.db 文件）与 LDAP 数据（用户和组首选项数据）、icsSubscribed、icsCalendar、icsCalendarOwned、icsFreeBusy、icsSet 和用于资源日历的 uid。迁移之后，将为所有日历资源创建 LDAP 项。

有关如何迁移产品数据的说明，请参见3.5.4 csmig 实用程序迁移步骤。

要执行模拟运行测试

在分步服务器上安装 Calendar Server 6.3（如果需要）。

将日历数据库的快照复制到分步服务器。

通过执行以下任务在分步服务器上模仿生产 LDAP 环境：
- 安装 Directory Server。
- 在此服务器上安装 LDAP 数据库的快照。

运行 comm_dssetup.pl 以配置分步 Directory Server。

运行 csconfigurator.sh 以配置分步 Calendar Server。

以 icsuser 身份登录（或者，如果不相同，以配置过程中指定的 Calendar Server 运行时用户 ID 登录）。如果您以超级用户 (root) 身份运行 csmig，则可能需要重置已迁移文件的权限。

转到 cal-svr-base/SUNWics5/cal/sbin 目录。

运行 csdb check 命令检查数据库中是否存在损坏。如果该命令检测出数据库中存在损坏，则运行 csdb rebuild 命令来重新建立数据库。

考虑为不具有所有者的用户日历创建通用的 calid。例如，以下命令将创建 calid 为 orphan 的用户：
./csuser -g orphan -s adminuser -y password -l en -c orphan create orphan

使用 stop-cal 命令停止 Calendar Server（如果需要）。

cal-svr-base/SUNWics5/cal/sbin/stop-cal

运行带有 -dryrun 选项的 csmig。例如，可以输入：
```
./csmig -b sesta.com -o csmig.out -e csmig.errors
 -m csmig.map -c orphan -r calmaster dryrun
```
该命令将不具有所有者的用户日历（不带有所有者的日历）指定给所有者 orphan，将不具有所有者的资源日历指定给所有者 calmaster。

检查输出的映射文件 (csmig.map)。映射文件列出了 LDAP 模式中需要更新的条目。

检查输出、映射和出错文件。解析发现的任何 LDAP 问题或错误。在进行实际的迁移之前，确定如何处理未解析的日历。

有以下若干选择：
- 在迁移前，删除任何不需要的日历。
- 为任何未解析的日历指定所有者。
- 在迁移期间，使用 -c 和 -r 选项允许 csmig 为日历指定所有者。

运行 csmig 以迁移分步日历数据库。

例如，以下命令将把日历数据库迁移至 /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
```

测试迁移完成之后，请执行以下步骤检查新迁移的日历数据库。
1. 将已迁移的数据库复制到 caldb.berkeleydb.homedir.path 参数指定的 /csdb 目录中。或者编辑此参数，使其指向迁移的数据库的新位置。
2. 对新的日历数据库运行 csdb check。迁移的数据库中事件和待办事项的数目应与迁移之前的总数相匹配。
3. 搜索 icsCalendarOwned 条目，并确保这些条目与迁移前日历的数目相匹配。
4. 登录到 Communications Express 并验证已迁移的数据库中的某些日历。
  
  如果成功完成了迁移测试，则可以开始迁移产品数据库。

要迁移产品数据

以 icsuser（或在配置过程中指定的 Calendar Server 运行时用户 ID）身份登录。如果您以超级用户 (root) 身份运行 csmig，则可能需要重置已迁移文件的权限。

转到 cal-svr-base/SUNWics5/cal/sbin 目录。

使用 stop-cal 命令停止 Calendar Server。

cal-svr-base/SUNWics5/cal/sbin/stop-cal

备份以下数据：
- 日历数据库（.db 文件）。
- LDAP 数据：slapd 数据库目录和 LDAP 数据库。
- ics.conf 文件。此步骤实际上并不需要，但如果要恢复为初始配置，该步骤则会很有帮助。

运行带有 -migrate 选项的 csmig。

例如，以下命令将把日历数据库迁移至 /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

检查错误文件 (csmig.errors) 中是否有未解析的日历，并根据3.5.4 csmig 实用程序迁移步骤中的计划解析这些日历。

运行 csdb check 命令以检查已迁移的数据库。如果该命令检测出数据库中存在损坏，则运行 csdb rebuild 命令来重新建立数据库。

将新迁移的数据库复制到 caldb.berkeleydb.homedir.path 参数指定的 /csdb 目录中。或者编辑此参数，使其指向迁移的数据库的新位置。

通过对 ics.conf 文件中的以下配置参数进行必要的更改来启用 LDAP CLD 插件：
- service.dwp.enable= "yes"
- service.dwp.port = "59779"
- csapi.plugin.calendarlookup = "yes"
- 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 高速缓存目录的位置。默认值为 /var/opt/SUNWics5/csdb/cld_cache。
  
  有关设置 LDAP CLD 插件的配置参数的信息，参见第 5 章，在 Calendar Server 版本 6.3 中配置跨多个计算机的日历数据库分发。

使用 start-cal 命令重新启动 Calendar Server。

登录到 Communications Express 并通过检查几个已迁移的日历来验证配置是否起到作用。

要在检查时禁用警报，将 ics.conf 文件中的以下参数都设置为 "no"：
- caldb.serveralarms = "no"
- caldb.serveralarms.dispatch = "no"
- service.ens.enable = "no"
- service.notify.enable = "no"
- ine.cancellation.enable = "no"
- ine.invitation.enable = "no"
- service.admin.alarm = "no"

3.5.5 csmig 提示和故障排除

本节介绍了以下提示和故障排除示例：

3.5.5.1 csmig 模拟运行日历显示了错误的日历所有者。

问题示例

名为 tchang:myCalendar 的日历的所有者在日历数据库中为 jsmith，csmig 模拟运行将映射显示为 jsmith:tchang_myCalendar。但是，您希望将此日历命名为 tchang:myCalendar，并将所有者指定为 tchang。

解决方案示例

在迁移之前，使用 cscal 实用程序将 tchang:myCalendar 日历的所有者更改为 tchang。执行此操作后，迁移操作会将此日历映射为 tchang:myCalendar，并针对用户 ID tchang 向 LDAP 条目中添加 icsCalendarowned。

3.5.5.2 LDAP 日历搜索无法正常工作。

问题示例

迁移之后，将启用 LDAP 日历搜索，但日历搜索对话框不返回任何结果，或仅返回部分结果。

解决方案示例

启用 LDAP 日历以使 Calendar Server 可以搜索 (&(objectclass=icscalendaruser)(icscalendarowned=*substr*))。

使用以下过滤器对 LDAP 数据手动运行两个不同的搜索，并比较输出结果：

使用过滤器 (&(objectclass=icscalendaruser)(icscalendarowned=*substr*)) 进行 LDAP 搜索
使用过滤器 (icscalendarowned=*substr* ) 进行 LDAP 搜索

因为服务器使用包含 icsCalendarUser 对象类的过滤器，所以可能已在禁用模式检查的情况下部署了 LDAP 服务器，并且可能在没有 icsCalendarUser 对象类的情况下置备了某些日历条目。

3.5.5.3 csmig 模拟运行指示重复的日历名称。

问题示例

csmig 模拟运行映射文件和输出结果文件指示存在重复的日历名称。

例如，在初始数据库中，jsmith 拥有以下日历：

具有 5 个事件的 basketball
具有 10 个事件的 jsmith:basketball

模拟运行的结果表示迁移时将合并这两个日历，生成的日历将为 jsmith:basketball，该日历的所有者为 jsmith 并总共具有 15 个事件

输出文件将包含以下警告消息：

Error modifying calendar properties, error=2

解决方案示例

如果不希望合并这两个日历，则在迁移之前将 basketball 的所有者更改为 jsmith 以外的用户。这可以保持这两个独立日历数据的完整性。

3.5.5.4 如何将不带有所有者的日历指定给不同的所有者？

问题示例

默认情况下，csmig 将所有不带有所有者的日历指定给一个所有者，但是我希望为其中的某些日历指定不同的所有者。

解决方案示例

csmig 不接受命令行中的映射文件。但是，可以在迁移之前为初始数据库中不带有所有者的日历指定所有者。检查所有不带有所有者的日历的空运行映射文件。然后，在迁移之前使用 cscal 实用程序为不带有所有者的日历指定所有者。在 -dryrun 模式下再次运行 csmig 以验证新的所有者。

3.5.5.5 如何将日历用户移动至其他后端服务器？

问题示例

如何将用户从一个后端服务器移动到另一个后端服务器？

解决方案示例

要移动日历用户，应通过 export 命令导出初始服务器上该用户的每个日历，然后通过 import 命令将日历导入到第二个服务器。移动日历后，可以删除初始服务器上的日历。有关如何移动日历的说明，参见15.6 管理用户日历。