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 都保持不变,并且不进行任何更改。

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

3.5.1.3 更新 LDAP 属性

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

3.5.2 csmig 实用程序要求

使用 csmig 的要求为:

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 迁移日历数据,请按照以下步骤执行操作:

Procedure使用 csmig 的高级步骤

  1. 使用 comm_dssetup.pl 配置 Directory Server。

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

  2. 请使用分步服务器(非产品服务器)执行模拟运行测试。

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

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

  3. 迁移产品数据

    在产品运行过程中,csmig 迁移日历数据库(.db 文件)与 LDAP 数据(用户和组首选项数据)、icsSubscribedicsCalendaricsCalendarOwnedicsFreeBusyicsSet 和用于资源日历的 uid。迁移之后,将为所有日历资源创建 LDAP 项。

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

Procedure要执行模拟运行测试

  1. 在分步服务器上安装 Calendar Server 6.3(如果需要)。

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

  3. 通过执行以下任务在分步服务器上模仿生产 LDAP 环境:

    • 安装 Directory Server。

    • 在此服务器上安装 LDAP 数据库的快照。

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

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

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

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

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

  9. 考虑为不具有所有者的用户日历创建通用的 calid。例如,以下命令将创建 calidorphan 的用户:


    ./csuser -g orphan -s adminuser -y password -l en -c orphan create orphan
  10. 使用 stop-cal 命令停止 Calendar Server(如果需要)。

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

  11. 运行带有 -dryrun 选项的 csmig。例如,可以输入:

    ./csmig -b sesta.com -o csmig.out -e csmig.errors
     -m csmig.map -c orphan -r calmaster dryrun

    该命令将不具有所有者的用户日历(不带有所有者的日历)指定给所有者 orphan,将不具有所有者的资源日历指定给所有者 calmaster

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

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

    有以下若干选择:

    • 在迁移前,删除任何不需要的日历。

    • 为任何未解析的日历指定所有者。

    • 在迁移期间,使用 -c-r 选项允许 csmig 为日历指定所有者。

  14. 运行 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
  15. 测试迁移完成之后,请执行以下步骤检查新迁移的日历数据库。

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

    2. 对新的日历数据库运行 csdb check。迁移的数据库中事件和待办事项的数目应与迁移之前的总数相匹配。

    3. 搜索 icsCalendarOwned 条目,并确保这些条目与迁移前日历的数目相匹配。

    4. 登录到 Communications Express 并验证已迁移的数据库中的某些日历。

      如果成功完成了迁移测试,则可以开始迁移产品数据库。

Procedure要迁移产品数据

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

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

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

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

  4. 备份以下数据:

    • 日历数据库(.db 文件)。

    • LDAP 数据:slapd 数据库目录和 LDAP 数据库。

    • ics.conf 文件。此步骤实际上并不需要,但如果要恢复为初始配置,该步骤则会很有帮助。

  5. 运行带有 -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
  6. 检查错误文件 (csmig.errors) 中是否有未解析的日历,并根据3.5.4 csmig 实用程序迁移步骤中的计划解析这些日历。

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

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

  9. 通过对 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 中配置跨多个计算机的日历数据库分发

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

  11. 登录到 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 的日历的所有者在日历数据库中为 jsmithcsmig 模拟运行将映射显示为 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 数据手动运行两个不同的搜索,并比较输出结果:

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

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

问题示例

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

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

模拟运行的结果表示迁移时将合并这两个日历,生成的日历将为 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 管理用户日历