第 3 章
迁移 Calendar Server 数据

Sun™ ONE Calendar Server 6.0 提供以下迁移实用程序：

cs5migrate 实用程序 - 将 Calendar Server 5.x 数据库迁移至 Calendar Server 6.0，并将日历数据库从 Berkeley DB 2.6 版升级到 3.2.9 版。
csmig 实用程序 - 为日历数据库中的每个日历指定一个所有者，并将每个日历 ID (calid) 映射到一个所有者（如果需要），这可以支持托管（虚拟）域和 LDAP Calendar 查找数据库 (CLD) 插件。
csvdmig 实用程序 - 升级 Calendar Server 6.0 工作地点以使用托管（虚拟）域。
ics2migrate 实用程序 - 迁移 iPlanet Calendar Server 2.x 中的数据。
ncs4migrate 实用程序 - 迁移 Netscape Calendar Server 4.x 中的数据。
csrename 实用程序 - 重命名日历数据库和 LDAP 目录服务器（带有“ics”前缀的 Calendar Server 属性）中的日历用户。

图 3-1 展示了运行 Calendar Server 迁移实用程序的流程图。

注意	在运行迁移实用程序之前，请务必先向 Sun Microsystems 技术支持人员或销售帐户代表进行咨询，以确保您使用的是最新版本的实用程序。 如果您的工作地点已针对受限的虚拟域模式或多个 Calendar Server 实例进行配置，请与 Sun Microsystems 销售帐户代表联系，以获得迁移要求的评估，并确保您安装了支持这些要求的特定迁移实用程序。

图 3-1 运行 Calendar Server 迁移实用程序的流程图

---

cs5migrate 实用程序

如果您要从 Calendar Server 5.x 升级到 Calendar Server 6.0，则必须先运行 cs5migrate 实用程序，然后才能运行 Calendar Server 6.0。cs5migrate 实用程序执行以下功能：

将以下 Calendar Server 5.x 文件迁移至 Calendar Server 6.0：
Calendar 数据库文件（ics50calprops.db、ics50journals.db、ics50alarms.db、ics50events.db、ics50todos.db 和 ics50gse.db）
会话数据库 (session.db)
将日历数据库从 Berkeley DB 2.6 版升级到 3.2.9 版。
将迁移状态写入到 cs5migrate.log，将所有错误写入到 cs5migrateError.log 和 cs5migrateException.log。

迁移时间

cs5migrate 迁移时间会因若干因素的不同而有所差异。首先，cs5migrate 必须访问 LDAP 目录服务器以更新模式属性，以便与 LDAP 服务器的网络连接可以极大地影响迁移时间。如果可能，请在其它网络通信量最小时使用与 LDAP 服务器的快速网络连接运行 cs5migrate。

迁移方案 - 在一台运行了具有 20 GB 交换文件空间的 Solaris 8 操作系统，且具有 UltraSPARC™ III Cu、12 个 CPU、750 MHz、12 GB 内存以及浮点处理器的 Sun Fire™ 上，cs5migrate 迁移以下 Calendar Server 5.x 日历数据库大约需要 1 小时 15 分钟：

日历数据库大小：大约 600 MB
日历数目： 8726
事件数目： 272412
任务数目： 4490
警报数目： 13583
组计划引擎 (GSE) 项的数目： 0

cs5migrate 语法

cs5migrate 实用程序的语法如下：

cs5migrate [-q] [-d] [-r] [-l min|max] source-directory target-directory

-q 指定静默模式。如果迁移成功，cs5migrate 将不显示信息。但如果出现任何错误，则会显示错误信息。

-d 指定空运行模式。空运行报告 cs5migrate 在实际迁移过程中将会执行的操作，但 cs5migrate 不会迁移任何数据或升级数据库。

-r 指定为周期性事件创建主组件。

-l min|max 指定日志模式和迁移日志 (cs5migrate.log) 的详细资料等级。

注意 在当前版本中未采用 -t 选项。

source-directory 是必须提供的参数，它指定包含 Calendar Server 5.x 数据库文件的目录。

target-directory 是必须提供的参数，它指定 cs5migrate 将在其中创建新的 Calendar Server 6.0 数据库文件的现有目录。

重要事项 您必须先创建 target-directory，然后再运行 cs5migrate。

迁移过程

在运行 cs5migrate 之前，请执行以下步骤：

使用 csbackup、Sun StorEdge Enterprise Backup™ 软件或 Legato Networker® 等实用程序备份 Calendar Server 5.x 数据库。
也建议您在迁移之前使用 csbd rebuild 命令重新建立您的日历数据库。有关信息，请参阅《Sun ONE Calendar Server 管理员指南》中的第 5 章“管理 Calendar Server 数据库”。
如果需要，可以通过将 ics.conf 文件中的 caldb.serveralarms 参数设置为“yes”来启用警报。
如果需要将 Calendar Server 5.x 数据库移到另一个服务器，您只需将数据库 (*.db) 文件复制到新服务器（如果文件不是太大）。否则，请创建数据库文件的归档文件，并将归档文件复制到新服务器，然后将其脱档。

要运行 cs5migrate，请执行以下步骤：

在 Solaris 和其它 UNIX 系统中，以 Calendar Server 运行时所用的用户和组的身份登录（例如，icsgroup 和 icsuser）。
如果需要，请使用 stop-cal 命令停止 Calendar Server。
如果需要，请创建 target-directory。在运行 cs5migrate 之前，必须存在 target-directory。
运行 cs5migrate。有关语法，请参阅 cs5migrate 语法。

例如，对于 Solaris 系统：

./cs5migrate -q -l max /var/opt/SUNWics5/csdb511
  /var/opt/SUNWics5/csdb60


在此例中，在迁移之前必须存在 /var/opt/SUNWics5/csdb60 目录。

有关迁移状态的信息，请查看 cs5migrate.log 文件。如果在迁移过程中出现错误或者无法迁移日历数据库条目，cs5migrate 会将错误写入到 cs5migrateerror.log。

运行完 cs5migrate 后，ics.conf 文件中的 caldb.berkeleydb.homedir.path 参数必须指向已迁移的数据库，因为 cs5migrate 不会修改 ics.conf 文件。

重置此参数以指向已迁移的数据库目录，或者将已迁移的数据库文件移到参数所指示的目录。

如果要使用 LDAP 数据缓存选项（local.ldap.cache.enable = "yes"）或 CLD 缓存选项（caldb.cld.cache.enable = "yes"），请在运行 cs5migrate 后在目标目录中创建 ldap_cache 和 cld_cache 目录。
检验已迁移数据库文件的权限。如果您以 icsuser 身份运行 cs5migrate，则不会有任何访问权限问题。如果您以超级用户（root 用户）身份运行（建议不使用），则可能需要重置权限。
使用 start-cal 命令重新启动 Calendar Server。

---

csmig 实用程序

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

csmig 实用程序支持托管（虚拟）域和 LDAP Calendar 查找数据库 (CLD) 插件。使用此插件可以访问已迁移数据库中的日历。LDAP CLD 插件通过允许日历在许多后端服务器上分布来提供日历数据库的水平可伸缩性。有关 LDAP CLD 插件的信息，请参阅《Sun ONE Calendar Server 管理员指南》。

此文档包括以下主题：

csmig 的功能
csmig 的要求
csmig 语法
csmig 迁移步骤
csmig 提示和疑难解答

csmig 的功能

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

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

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

csmig 更新所有相关 LDAP 项的 LDAP 属性，包括 icsSubscribed、icsCalendar、icsCalendarOwned、icsFreeBusy、icsSet 和 uid（用于资源日历）。csmig 为 LDAP 目录服务器数据库中的每个日历都创建 icsDWPHost 属性。icsDWPHost 指定日历所在后端服务器的主机名称。
csmig 为日历数据库中的每个日历指定所有者，并将每个日历的 ID (calid) 映射到一个所有者（如果需要）。所有默认的 calids 都保持不变，并且不进行任何更改。其它日历按如下方式进行映射：
通过 -c 选项传递给 csmig 的用户将拥有不具有有效所有者的用户日历。例如，如果 jsmith 没有所有者，它将被转换为 orphan:jsmith（如果 orphan 指定为 -c 选项）。
通过 -r 选项传递给 csmig 的资源用户将拥有不具有所有者的资源日历。
如果资源日历的名称中包含冒号，则此冒号将转换为下划线。

例如，所有者为 bkamdar 且名为 football 的日历将被转换为 bkamdar:football。所有者为 bkamdar 的日历 tchang:soccer 将被转换为 bkamdar:tchang_soccer。（calid 中只能有一个冒号。）名为 auditorium:room1 的资源日历将被转换为 auditorium_room1。

csmig 的要求

使用 csmig 的要求为：

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

您还必须具有管理存储用户首选项的 LDAP 目录服务器中的日历用户属性的权限。

必须停止 Calendar Server。

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 是在空运行模式下生成的输出映射文件，它列出了用于更新 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 数据的日历搜索的性能。
进行空运行测试 - 空运行报告 csmig 在迁移过程中将会执行的操作，但实际上 csmig 并没有迁移任何数据。空运行之后，您可以更正任何错误，并确定处理任何未解决的日历的计划。
迁移产品数据 - 实际运行时，csmig 将迁移日历数据库（.db 文件）和 LDAP 数据（用户和组首选项数据）、icsSubscribed、icsCalendar、icsCalendarOwned、icsFreeBusy、icsSet 和 uid（用于资源日历）。迁移之后，将为所有日历资源创建 LDAP 项。

配置 LDAP 目录服务器

为了提高性能，请考虑向 slapd.ldbm.conf 文件添加以下两个新索引：

index icscalendar pres,eq,sub - 由迁移进程使用，用于搜索 icsCalendar 属性。
index icscalendarowned pres,eq,sub - 不是迁移进程所必需的，但用于在启用了 LDAP CLD 插件时对 LDAP 数据执行日历搜索（用于预定操作）。

有关在 slapd.ldbm.conf 文件中创建索引的信息，请参阅目录服务器文档。

进行空运行测试

在分步服务器上进行空运行测试后报告将会迁移的内容，但它实际上并不对产品数据库进行迁移。空运行允许您确定迁移产品数据库的计划。例如，您可以确定处理“orphan”日历（该日历不具有所有者）的方式。

要使用 csmig 进行空运行测试，请执行以下步骤：

以 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 问题或错误。在进行实际的迁移之前，确定如何处理未解决的日历。有以下若干选择：
在迁移前，删除任何不需要的日历。
为任何未解决的日历指定所有者。
使用 -c 和 -r 选项，允许 csmig 在迁移期间为日历指定所有者。
强烈建议您在迁移实际的产品日历数据库之前在分步服务器上迁移日历数据库。执行此步骤，您可以切实了解迁移数据的方式，并可以在迁移产品数据库之前更正任何问题。

例如，在 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 目录。或者编辑此参数，使其指向迁移的数据库的新位置。然后进行以下检查：
对新的日库据库运行 csdb check。迁移的数据库中事件和待办事件的数目应与迁移之前的总数相匹配。
搜索 icsCalendarOwned 项，并确保这些项与迁移前日历的数目相匹配。
登录到 Calendar Express，并验证迁移的数据库中的某些日历。

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

迁移产品数据

要使用 csmig 迁移产品数据库，请执行以下步骤：

以 icsuser（或在配置过程中指定的 Calendar Server 运行时用户 ID）身份登录。如果您以超级用户（root 用户）身份运行 csmig，则可能需要重置已迁移文件的权限。
转到 cal_svr_base/opt/SUNWics5/cal/sbin 目录。
使用 stop-cal 命令停止 Calendar Server（如果需要）。
备份以下数据：
日历数据库（.db 文件）。
LDAP 数据：slapd 数据库目录和 LDAP 数据库。
ics.conf 文件。此步骤实际上并不需要，但如果要恢复为初始配置，该步骤则会很有帮助。
带 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

检查错误文件中是否存在未解决的日历，并根据进行空运行测试下步骤 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。

检查此目录是否正确。如果希望为 CLD 缓存指定不同的位置，则修改此参数。

有关设置 LDAP CLD 插件的配置参数的信息，请参阅《Sun ONE Calendar Server 管理员指南》。

使用 start-cal 命令重新启动 Calendar Server。
登录到 Calendar Server，并通过检查若干迁移的日历来验证配置是否生效。要在检查时禁用警报，请将 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"

csmig 提示和疑难解答

本节包括以下提示和疑难解答解决方法：

csmig 空运行日历的所有者不是我所希望的日历所有者
LDAP 日历搜索无法正常工作
csmig 空运行指示重复的日历名称
如何将不带有所有者的日历指定给不同的所有者？
如何将日历用户移动到其它后端服务器？

 

csmig 空运行日历的所有者不是我所希望的日历所有者

例如，名为 tchang:myCalendar 的日历的所有者在日历数据库中为 jsmith，csmig 空运行将映射显示为 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 数据手动运行两个不同的搜索，并比较输出结果：

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

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

csmig 空运行指示重复的日历名称

csmig 空运行映射文件和输出文件指示存在重复的日历名称。例如，在初始数据库中，jsmith 拥有以下日历：

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

空运行指示在迁移时将合并这两个日历，生成的日历将为

jsmith:basketball，所有者为 jsmith，总共 15 个事件

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

修改日历属性时出错，错误数 = 2

解决方法

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

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

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

解决方法

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

如何将日历用户移动到其它后端服务器？

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

解决方法

要移动日历用户，应导出初始服务器上该用户的每个日历，然后将日历导入到第二个服务器。移动日历后，可以删除初始服务器上的日历。有关移动用户的详细步骤，请参阅《Sun ONE Calendar Server 管理员指南》。

---

csvdmig 实用程序

csvdmig 实用程序为要使用托管（虚拟）域的工作地点修改 Calendar Server 数据库和 LDAP 目录服务器数据库。csvdmig 实用程序按以下方式将域名添加到用户 ID：

更改日历 ID (calid) 的格式：

userid[:calendar-name] 更改为 userid@domain[:calendar-name]

更改访问控制列表 (ACL) 访问规则：

userid 更改为 userid@domain

修改用于 Calendar Server 属性的 LDAP 目录服务器用户条目：

userid[:calendar-name] 修改为 userid@domain[:calendar-name]。

 

注意	csvdmig 实用程序实际上并没有将数据从一个位置迁移到另一个位置，而是在数据的当前位置上修改日历数据库和 LDAP 目录服务器。 因此，在运行 csvdmig 之前，请备份您的 Calendar Server 数据库和 LDAP 目录服务器数据库。

 

csvdmig 语法

csvdmig 实用程序的语法如下：

csvdmig [-t DestinationDB] [-c ConfigFile] [-e ErrorFile] [-m MappingFile]   migrate [DB | LDAP]

-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 示例

使用默认值迁移 LDAP 目录服务器数据：

csvdmig migrate LDAP

迁移 Calendar Server 数据库：

csvdmig -t targetDB -e errorFile -m mappingFile migrate

---

ics2migrate 实用程序

ics2migrate 迁移实用程序可以将 iPlanet Calendar Server 2.x 日历数据和 LDAP 用户首选项迁移至 Calendar Server 6.0。

本节包括以下内容：

迁移要求
迁移内容
迁移过程

1. 升级 2.x 日历数据库

2. 迁移数据

3. 检查迁移结果

迁移示例

 

迁移要求

从 Calendar Server 2.x 到 6.0 的迁移要求具有以下硬件和软件：

源计算机具有要迁移的 Calendar Server 2.x 数据。
目标计算机是将在其上创建迁移数据的计算机。此计算机必须已经安装了 Calendar Server 6.0（或更高版本）。
ics2migrate 实用程序 - 在迁移之前，请先向 Sun 技术支持代表或帐户管理员进行咨询，以确保您使用的是最新版本的实用程序。

源计算机和目标计算机可以是不同的服务器，也可以是同一服务器。有关支持的平台列表，请参阅《Sun ONE Calendar Server 发行说明》。

迁移内容

下表列出了 Calendar Server 2.x 数据，并说明了 ics2migrate 如何将这些数据迁移至 Calendar Server 6.0。

表 3-1 Calendar Server 2.x 数据的迁移

Calendar Server 2.x 数据	Calendar Server 6.0 迁移结果
日历属性 (calprops)	更新 Calendar Server calprops 数据库。
事件	更新 Calendar Server events 数据库。
待办事件	更新 Calendar Server todos 数据库
警报	在写入事件和待办事件的同时，更新 alarms 数据库。

下表列出了 Calendar Server 2.x LDAP 属性，并说明了 ics2migrate 如何将这些属性迁移至 Calendar Server 6.0。

表 3-2 LDAP 属性的迁移 

Calendar Server 2.x LDAP 属性	Calendar Server 6.0 LDAP 属性
nswcalUser *	icsCalendarUser *
nswcalCalID	icsCalendar
nswcalExtendedUserPrefs	icsExtendedUserPrefs
ceCalList **	icsSubscribed
ceAgendaList **	icsSet
ceDefaultAgenda **	icsDefaultSet
ceDefaultTZID **	icsTimeZone
ceFirstDayWeek **	icsFirstDay
* 对象类 ** nswcalExtendedUserPrefs 的初始部分

迁移过程

ics2migrate 的步骤包括：

升级 2.x 日历数据库
迁移数据
检查迁移结果

 

注意	运行 ics2migrate 之前，请先使用 csbackup、Sun StorEdge Enterprise Backup™ 软件或 Legato Networker® 等实用程序备份日历数据库。 备份日历数据库非常重要，因为 db_upgrade 将升级其当前目录中的数据库。如果在升级过程中出现问题，您的数据库可能会处于不可恢复的状态。

 

升级 2.x 日历数据库

Calendar Server 6.0 需要 Sleepycat 软件的 Berkeley DB 3.2.9 版。运行 ics2migrate 之前，您必须使用 Berkeley DB db_recover 和 db_upgrade 实用程序，以将您的日历数据库升级到 3.2.9 版。Calendar Server 6.0 在以下目录中包括 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：
迁移后，确保 ics.conf 文件中的 caldb.berkeleydb.homedir.path 参数指向已迁移的数据库。
运行 csdb check 命令。如果需要，运行 csdb rebuild 命令重新建立日历数据库。

ics2migrate 语法

要迁移 Calendar Server 2.x 数据库和 LDAP 用户首选项

ics2migrate [-q] [-s def|none] [-f def|none] [-l min|max] source target

要仅迁移 Calendar Server 2.x 数据库

ics2migrate [-q] [-m db] [-s def|none] [-f def|none] [-l min|max] source target

要仅迁移 LDAP 用户首选项

ics2migrate [-q] [-m ldap]

注	要显示语法，请键入 ics2migrate（不带任何选项）。

 

表 3-3 列出了 ics2migrate 选项以及每个选项的说明。

表 3-3 ics2migrate 选项 

ics2migrate 选项	说明
[-q]	在静默模式下运行。如果迁移成功，则 ics2migrate 将不在控制台上显示信息。如果迁移不成功，ics2migrate 将仅显示错误。 默认值为冗余模式。
[-m db|ldap]	db - 仅迁移日历数据库。 ldap - 仅迁移 LDAP 用户首选项。 默认值为迁移日历数据库和 LDAP 用户首选项。
[-s def|none]	def - 仅可访问用户默认日历的时间安排。 none - 不能访问任何用户日历的时间安排。 默认值为可访问所有用户的时间安排。
[-f def|none]	def - 仅可访问用户默认日历的空闲/繁忙情况。 none - 不能访问任何用户日历的空闲/繁忙情况。 默认值为可访问所有日历的空闲/繁忙情况。
[-l min|max]	min - 记录最少的数据迁移统计数据：每个日历的日历 ID、主要所有者以及事件和待办事件的数目。 max - 记录最多的数据迁移统计数据：最小统计数据加上每个事件和待办事件的参与者和警报的数目。 ics2migrate 将统计数据记录到 cal_svr_base/opt/SUNWics5/cal/sbin 目录的 ics2migrate.log 中。 默认情况下，ics2migrate 在控制台显示迁移统计数据，并且不生成日志文件。
source	Calendar Server 2.x 数据库文件所在的目录。 如果指定了 -m db 选项，或省去 -m 选项，则必须为数据库迁移指定 source 选项。
target	Calendar Server 6.0 数据库文件所在的目录。 如果指定了 -m db 选项，或省去 -m 选项，则必须为数据库迁移指定 target。

检查迁移结果

迁移完成后，请检查结果：

检查 ics2migrate.log 文件以获得以下消息（取决于您的迁移选择）：

成功完成数据库迁移
成功完成 LDAP 用户首选项迁移

如果您认为数据库可能被损坏，则运行 csdb 实用程序 check 命令。

check 命令对日历数据库进行扫描，检查它是否损坏。如果 check 命令发现数据库中存在无法解决的冲突，它会在输出中进行报告。如果需要，可以运行 csdb 实用程序 rebuild 命令，重新建立日历数据库 (caldb)。

有关 csdb 实用程序 check 和 rebuild 命令的文档，请参阅文档 Web 站点上的《Sun ONE Calendar Server 管理员指南》。

迁移示例

迁移日历数据库和 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

在静默模式下迁移

除运行在静默模式下以外，其它迁移操作与前面的示例相同。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 和日历数据库信息。仅能访问每个用户默认日历的时间安排，不能访问服务器上任何日历的空闲/繁忙情况，并且不在日志文件中生成统计数据信息。

ics2migrate -s def -f none 2x_db 50_db

---

ncs4migrate 实用程序

本节介绍如何使用 ncs4migrate 迁移实用程序将 Netscape Calendar Server 4.x 日历数据迁移至 Sun ONE Calendar Server。

对于 Corporate Software & Technologies Int. Inc. 的开发者而言，Netscape Calendar Server 4.x 日历也称为 CS&T 日历。

如果您需要 ncs4migrate 实用程序的副本，请与 Sun 技术支持代表人员或帐户管理员联系。获得 ncs4migrate 之后，将其复制到 cal_svr_base/opt/SUNWics5/cal/sbin 目录中。

本节包含以下信息：

迁移要求
迁移内容
迁移步骤

1. 备份 Calendar Server 5.0 数据库

2. 准备迁移

3. 迁移数据

迁移多个节点中的数据

检查迁移日志文件

4. 检查迁移的数据

迁移要求

迁移要求以下硬件和软件：

源计算机 — 此计算机具有要迁移的 Netscape Calendar Server 4.0（或更高版本）数据。
目标计算机 — 此计算机具有要向其中迁移数据的 Calendar Server 5.0 数据库。它应该运行的 Calendar Server 5.0 修补程序 4（或更新版本）。

源计算机和目标计算机可以是不同的服务器，也可以是同一服务器。有关支持的平台列表，请参阅《Sun ONE Calendar Server 发行说明》。

迁移内容

下表说明了 ncs4migrate 如何将 Netscape Calendar Server 4.0 数据迁移到 Calendar Server 6.0。

表 3-4 迁移 Netscape Calendar Server 4.0 数据 

Netscape Calendar Server 4.0 数据项	Calendar Server 5.0 迁移结果
会议、事件以及资源和用户记录	作为事件迁移。
任务	作为待办事件（任务）迁移。
访问（安全）权限	迁移时忽略。不迁移指定和指定权限。 对于用户日历和资源日历，ncs4migrate 按以下方式使用 ics.conf 文件中的访问控制字符串： 对于用户日历，ncs4migrate 使用 calstore.calendar.default.acl 并将 Calendar Server 5.0 日历中的保密设置设定为： 日历所有者：“空闲时间”、“安排”、“读取”、“删除”和“修改” 所有其他用户：“空闲时间”和“安排” 对于资源日历，ncs4migrate 使用 resource.default.acl 并将 Calendar Server 5.0 日历中的保密设置设定为： 资源所有者：“空闲时间”、“安排”、“读取”、“删除”和“修改” 所有其他用户：“空闲时间”、“安排”和“读取” 有关保密设置及其更改方法的说明，请参阅 Calendar Express 联机帮助。 注意：在迁移之前，请检查 ics.conf 文件中的字符串，以确保它们为以下正确内容： calstore.calendar.default.acl 的正确字符串为： @@o^a^r^g;@@o^c^wdeic^g;@^a^sf^g;@^c^^g resource.default.acl 的正确字符串为： @@o^a^r^g;@@o^c^wdeic^g;@^a^rsf^g;@^c^^g
文件附件	迁移时忽略；日志文件中生成警告。
分组	不迁移。

迁移步骤

备份 Calendar Server 5.0 数据库

迁移之前，建议执行以下步骤，以确保日历数据库的完整：

使用 csbackup、Sun StorEdge Enterprise Backup™ 软件或 Legato Networker® 等实用程序备份日历数据库。

有关信息，请参阅《Sun ONE Calendar Server 管理员指南》。

对日历数据库运行 csdb 实用程序 check 命令，以检查数据库是否损坏。如果 check 命令检测出数据库损坏，则运行 csdb 实用程序 rebuild 命令以重新建立数据库。

有关 csdb 和 csbackup 实用程序的文档，请参阅《Sun ONE Calendar Server 管理员指南》。

准备迁移

在运行 ncs4migrate 实用程序之前，请在目标计算机上执行以下步骤：

以超级用户（root 用户）身份或对系统具有管理权限的用户身份登录，或成为超级用户。
转到 cal_svr_base/opt/SUNWics5/cal/sbin 目录。
创建名为 ncs4dirpaths.dat 的文本文件，并指定 Netscape Calendar Server 4.0 数据库的全限定目录路径。例如：

/apps/ncs/calendar/unison/db/nodes/N0/perm

要定位包含 Netscape Calendar Server 4.0 数据库的目录，请查找 unison.dbd 文件。

如果需要，请满足允许 ncs4migrate 访问节点并读取 Netscape Calendar Server 4.0 数据库所在目录的任何要求。

注	请勿在路径名中使用诸如 $CAL_HOME 的变量。在迁移过程中，将不解析变量。

有关为多个节点上的数据创建 ncs4dirpaths.dat 文件的信息，请参阅迁移多个节点中的数据。

如果要迁移选定用户，请在 cal_svr_base/opt/SUNWics5/cal/sbin 目录中创建名为 ncs4userfilter.dat 的用户过滤器文件。ncs4userfilter.dat 是文本文件，它指定要迁移的用户。其中每一行都以下列格式之一标识一个用户：
在 Netscape Calendar Server 日历系统中为 node-number:user id（nscalxitemid 属性）
用户的 UID 属性

例如，ncs4userfilter.dat 文件中的几项可以是：

caluser1
caluser2
10000:00256
10000:00257

可以在同一个 ncs4userfilter.dat 文件中同时使用这两种格式。

请确保 LDAP 服务器正在运行。
要防止在迁移过程中更新日历数据库，则停止 Calendar Server。但是 Netscape Calendar Server 可以处于运行或停止状态。

现在，即可迁移 Netscape Calendar Server 4.0 数据了。

迁移数据

在目标计算机上，请执行以下步骤：

以超级用户（root 用户）身份或对系统具有管理权限的用户身份登录后，转到 cal_svr_base/opt/SUNWics5/cal/sbin 目录（如果需要）。
在命令行中键入 ncs4migrate。

ncs4migrate 实用程序将显示其欢迎菜单和表 3-5 中所示的选项。

注意：虽然 ncs4migrate 显示“导出(E)”和“导入(I)”选项，但这些选项并不受支持，也不应使用。

表 3-5 ncs4migrate 实用程序选项 

ncs4migrate 选项	说明
导出(E)	将 Netscape Calendar Server 4.0 日历数据库导出为中间文件。
导入(I)	将中间文件的数据导入到日历数据库中。
跳过(S)	跳过中间文件。一次仅从 Netscape Calendar Server 4.0 向 Calendar Server 5.0 迁移一条记录。
日志(L) = ON|OFF	设置“日志”。日志文件名为 ncs4migrate_yyyymmdd-hhmmss.log。 默认值为 ON。
冗余(V) = ON|OFF	设置“冗余”日志。默认值为 OFF。 为了节省磁盘空间，建议保持为 OFF。
调试(D) = ON|OFF	设置“调试”日志。默认值为 OFF。
静默(Q) = ON|OFF	设置屏幕输出。默认值为 OFF。
终止(T) = TRUE|FALSE	如果 Netscape Calendar Server 4.0 数据库中的用户不在 LDAP 中，则终止。默认值为 FALSE。
仅(O) = TRUE|FALSE	仅迁移用户过滤器文件 ncs4userfilter.dat 中的用户。 默认值为 FALSE。 如果 O 和 M 选项的值为 TRUE，则 ncs4migrate 将迁移在过滤器文件中具有任何参与者的任何事件，这些参与者在过滤器文件中可以是所有者或参与者。事件将迁移到所有参与者的日历中。
迁移(M) = TRUE|FALSE	迁移用户过滤器文件中的用户。默认值为 FALSE。
绕过(B) = TRUE|FALSE	不迁移用户过滤器文件中的用户。默认值为 FALSE。
任何(A) = TRUE|FALSE	Netscape Calendar Server 安全性访问级别的任何组合都将在 Calendar Server 中生成授权。默认值为 TRUE。FALSE 表示需要提供所有 3 个访问级别；请参阅“帮助(H)”。
用户(U)	显示用户过滤文件 ncs4userfilter.dat。 使用 O 选项打开/关闭过滤。默认值为 OFF。
路径(P)	Netscape Calendar Server 4.0 数据库的路径文件。文件名为 ncs4dirpaths.dat。
帮助(H)	显示“帮助”屏幕。
退出(E)	退出程序。

从 ncs4migrate 菜单中，指定 S 选项迁移所有用户。或者，如果要迁移用户过滤器文件 (ncs4userfilter.dat) 中的特定用户，则指定 O 选项。
监视迁移日志文件以检查迁移状态。有关更多信息，请参阅检查迁移日志文件。
迁移完成后，按照检查迁移的数据中的说明检查迁移的日历数据库。

迁移多个节点中的数据

要迁移多个节点中的 Netscape Calendar Server 4.0 数据，请在目标计算机上执行以下步骤：

以超级用户（root 用户）身份或对系统具有管理员权限的用户身份登录后，将 Netscape Calendar Server 4.0 数据库目录从每个节点复制到要在其上运行 ncs4migrate 的计算机中。（每个 Netscape Calendar Server 4.0 目录都应包含一个 unison.dbd 文件。）

您也可以直接从每个节点迁移 Netscape Calendar Server 4.0 数据，但必须首先满足允许 ncs4migrate 访问其它节点上的 Netscape Calendar Server 4.0 数据的任何要求。

转到 cal_svr_base/opt/SUNWics5/cal/sbin 目录。
在 ncs4dirpaths.dat 文件中，指定所有节点中的数据的目录路径名。例如，以下 ncs4dirpaths.dat 文件包含三个节点的目录路径：

/apps/ncs/calendar/unison/db/nodes/N0/perm
/apps/ncs/calendar/unison/db/nodes/N1/perm
/apps/ncs/calendar/unison/db/nodes/N2/perm

要运行迁移实用程序，在命令行中键入 ncs4migrate。
从 ncs4migrate 菜单中，指定 S 选项迁移所有用户。或者，如果要迁移用户过滤器文件 (ncs4userfilter.dat) 中的特定用户，则指定 O 选项。
监视迁移日志文件以检查迁移状态。有关更多信息，请参阅检查迁移日志文件。
迁移完成后，按照检查迁移的数据中的说明检查迁移的日历数据库。

检查迁移日志文件

ncs4migrate 实用程序在 cal_svr_base/opt/SUNWics5/cal/sbin 目录中生成具有以下名称的日志文件：

ncs4migrate_yyyymmdd-hhmmss.log

其中 yyyymmdd-hhmmss 是时间戳记，用于指示迁移的开始时间。

如果 ncs4migrate 实用程序运行时间很长，请检查日志文件的大小是否在不断增加，因为如果文件大小增加则说明实用程序仍在运行。

注	要防止日志文件变得过大，可以考虑略去 ncs4migrate“冗余(V)”选项。

检查迁移的数据

完成迁移后，请在目标计算机上执行以下步骤：

运行 csdb 实用程序 check 命令来扫描日历数据库，以确定是否发生了损坏数据的现象。如果 check 命令检测出数据库损坏，则运行 csdb 实用程序 rebuild 命令以重新建立数据库。

有关 csdb 实用程序 check 和 rebuild 命令的文档，请参阅文档 Web 站点上的《Sun ONE Calendar Server 管理员指南》。

如果需要，重新启动 Calendar Server。

用户可以使用 Calendar Express 访问迁移的日历数据库。

---

csrename 实用程序

csrename 实用程序按以下方式重命名日历用户：

日历数据库文件 - 在日历数据库文件中重命名用户（用户 ID），然后将新数据库文件写入到目标目录中。不修改现有的日历数据库文件。
LDAP 目录服务器 - 转换 Calendar Server LDAP 属性（即带有“ics”前缀的属性）中的用户 ID。适当修改 LDAP 目录服务器。

csrename 实用程序位于以下目录中：

cal_svr_base/opt/SUNWics5/cal/sbin

运行 csrename 之前，您必须先：

为要转换的用户创建输入映射文件（-m 选项）。
置备 LDAP 目录服务器中的所有新用户（如果需要）。
停止 Calendar Server。

要运行 csrename，您必须以 icsuser（或在配置过程中指定的 Calendar Server 运行时用户 ID）身份登录。如果您以超级用户（root 用户）身份运行 csrename，则可能需要重置新数据库文件的权限。要修改 LDAP 目录服务器属性，您还必须具有该目录的管理权限。

如果具有前端/后端服务器配置，则必须对每个后端服务器运行 csrename。

csrename 语法

请使用以下语法运行 csrename：

csrename [-t DestinationDB ] [-c ConfigFile ] [-e ErrorFile ] -m MappingFile rename [DB|LDAP]

-t DestinationDB 指定目标目录，csrename 在该目录中生成具有已转换用户名的新数据库。默认值为 MigratedDB。

运行完 csrename 后，ics.conf 文件中的 caldb.berkeleydb.homedir.path 参数必须指向目标数据库。重置 caldb.berkeleydb.homedir.path 以指向目标数据库目录，或将目标数据库文件移到参数所指示的目录。

-c ConfigFile 是输入参数，用于指定 Calendar Server 配置文件。默认值为 ics.conf 文件。

csrename 使用配置文件中的 caldb.berkeleydb.homedir.path 参数来确定输入日历数据库的位置。日历数据库的默认位置为 cal_svr_base/var/opt/SUNWics5/csdb。

-e ErrorFile 是 csrename 向其中写入无法解决的错误或数据库项的文件。默认值为 MigrateError。

-m MappingFile 指定输入映射文件。默认值为 MigrateMapping。

输入映射文件是文本文件，可将现有的用户 ID 映射到新用户 ID。

运行 csrename 之前，您必须创建映射文件。每行指定一个条目，在旧值和新值之间留有一个空格。例如：

tchang tc897675
jsmith js963123
...
bkamdar bk548769

DB|LDAP 指定获得更新的数据库：

DB 仅转换新日历数据库中的用户 ID（默认）。
LDAP 转换新日历数据库和 LDAP 目录服务器属性中的用户 ID。

csrename 示例

根据名为 DBMapFile 的映射文件重命名用户，并在名为 newcalDB 的目标目录中创建新的日历数据库：

csrename -t newcalDB -m DBMapFile rename DB

根据名为 NewNames 的映射文件中的值重命名用户，在名为 NewDB 的目标目录中创建新的日历数据库，并修改 LDAP 目录服务器中的 Calendar Server 属性：

csrename -t NewDB -m NewNames rename LDAP

上一个      目录      索引      下一个

---

版权所有 2003 Sun Microsystems, Inc.。保留所有权利。