Sun ONE logo     上一章     目录     索引     下一章     
Sun ONE Calendar Server 安装指南



第 4 章   迁移 Calendar Server 数据


本章介绍下列 Sun™ ONE Calendar Server 5.1.1 迁移公用程序:


ics2migrate 迁移公用程序

ics2migrate 迁移公用程序可将 Calendar Server 2.x 日历数据和 LDAP 用户首选项迁移到 Calendar Server 5.1.1。

本节介绍:

从 Calendar Server 2.x 到 5.x 的迁移是单向迁移。您只能将 2.x 版的数据迁移到 5.1 版,但不能将 5.x 版的数据迁移到 2.x 版。

迁移要求

将 Calendar Server 2.x 迁移到 5.x 需要下列硬件和软件:

  • 源机器上有您打算迁移的 Calendar Server 2.x 数据。

  • 目标机器是创建迁移数据的地方。该机器上必须已安装 Calendar Server 5.0 修补程序 4(或更高版本)。

    ics2migrate.exe 位于 server-root\cal\bin 目录中。

源机器和目标机器可以是不同的服务器,也可以是相同的服务器。下列平台受到支持:

  • Solaris 2.6 (5.6) 操作环境(或更高版本)

  • 已安装 Service Pack 6a 的 Windows NT 4.0

迁移内容

下表列出 Calendar Server 2.x 数据并描述 ics2migrate 如何将这些数据迁移到 Calendar Server 5.x。


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

Calendar Server 2.x 数据

Calendar Server 5.x 的迁移结果

日历属性 (calprops)  

更新 Calendar Server calprops 数据库。  

事件  

更新 Calendar Server events 数据库。  

待办事项  

更新 Calendar Server todos 数据库  

警报  

在写入事件和待办事项时更新 alarms 数据库。  

下表列出 Calendar Server 2.x LDAP 属性并描述 ics2migrate 如何将这些属性迁移到 Calendar Server 5.x。


表 4-2    迁移 LDAP 属性 

Calendar Server 2.x LDAP 属性

Calendar Server 5.x LDAP 属性

nswcalUser *  

icsCalendarUser *  

nswcalCalID  

icsCalendar  

nswcalExtendedUserPrefs  

icsExtendedUserPrefs  

ceCalList **  

icsSubscribed  

ceAgendaList **  

icsSet  

ceDefaultAgenda **  

icsDefaultSet  

ceDefaultTZID **  

icsTimeZone  

ceFirstDayWeek **  

icsFirstDay  

* Objectclass

** 原始 nswcalExtendedUserPrefs 的部分

迁移过程



警告

在迁移之前,请备份 Calendar Server 2.x 和 5.x 日历数据库。



准备迁移

遵循以下步骤准备迁移数据:

  1. 在安装 Calendar Server 的目标机器上,以具有系统管理权限的用户身份登录:

    • 在 Solaris 机器上,以 root 身份登录(或切换为),或者以安装时指定用来运行 Calendar Server 的用户和组(例如 icsusericsgroup)登录。

    • 在 Windows NT 机器上,以具有完全管理员权限的管理员身份登录。

  2. 找到 Calendar Server 2.x caldb.conf 文件。该文件的默认目录取决于您的平台:

    • Solaris 机器:/var/opt/SUNWicsrv/csdb

    • Windows NT 机器:server-root\var\csdb

  3. 按以下方式更改 caldb.conf 文件中的第一行:

    旧值:caldb.version "1.0.0 [BerkeleyDB]"

    新值:caldb.version= "2.0.0 [BerkeleyDB]"

  4. 为确保数据完整性,请停止 Calendar Server 2.x 和 5.x 的所有服务。有关更多信息,请参见文档 Web 站点上的《Sun ONE Calendar Server 管理员指南》。

迁移数据

遵循以下步骤迁移数据:

  1. 定位到 ics2migrate.exe 所在的 server-root\cal\bin 目录。

  2. 使用以下语法运行 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 时不带任何选项。



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


表 4-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 将统计信息记录到 server-root\cal\bin 目录的 ics2migrate.log 中。

默认情况下,ics2migrate 会在控制台上显示迁移统计信息,而且不生成日志文件。  

source  

Calendar Server 2.x 数据库文件所在的目录。

如果指定 -m db 选项,或者省略 -m 选项,则必须有 source 才能进行数据库迁移。  

target  

Calendar Server 5.1 数据库文件所在的目录。

如果指定 -m db 选项或省略 -m 选项,则必须有 target 才能进行数据库迁移。  

检查迁移结果

迁移完成后,请检查结果:

  • 查看 server-root\cal\bin 目录中的 ics2migrate.log 文件,查找下列消息(取决于您选择的迁移方式):

    Database migration successfully completed
    LDAP user preference migration successfully completed

  • 如果怀疑数据库可能已损坏,请运行 csdb 公用程序的 check 命令。

    check 命令会扫描日历数据库是否损坏。如果 check 命令找到不一致的情况,而且又无法解决,则会在输出时报告该情况。如有必要,可以运行 csdb 公用程序的 rebuild 命令来重建日历数据库 (caldb)。

    有关 csdb 公用程序的 checkrebuild 命令的文档,请参见文档 Web 站点上的《Sun ONE Calendar Server 管理员指南》。

迁移示例

同时迁移日历数据库和 LDAP 用户信息

同时迁移 LDAP 用户信息和 Calendar Server 2.x 数据库。Calendar Server 2.x 数据库存储在 /var/opt/SUNWicsrv/2x_db 目录中,而 5.1 数据库位于 /var/opt/SUNWics5/50_db 目录中。

允许对所有日历进行日程安排,且可查看所有日历的“空闲/已占用”状态,并将最少的迁移统计信息记录在 server-root\cal\bin 目录的 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 目录中创建 5.1 数据库。

ics2migrate -m db 2x_db /var/opt/SUNWics5/50_db

只迁移 LDAP 用户信息

只将 Calendar Server 2.x LDAP 用户信息迁移到 5.1 版格式。

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 后,将它复制到 server-root\cal\bin 目录中。

本节包括以下信息:

迁移要求

迁移时需以下列硬件和软件:

  • 源机器-该机器上有您打算迁移的 Netscape Calendar Server 4.0(或更高版本)数据。

  • 目标机器-该机器上有您打算迁移到的 Calendar Server 5.0 数据库。请于其上运行 Calendar Server 5.0 修补程序 4(或更高版本)。

源机器和目标机器可以是不同的服务器,也可以是相同的服务器。下列平台受到支持:

  • Solaris 2.6 (5.6) 或更高版本的操作环境

  • 已安装 Service Pack 6a 的 Windows NT 4.0

迁移内容

下表显示 ncs4migrate 如何将 Netscape Calendar Server 数据迁移到 Calendar Server 5.0。

表 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 数据库

在迁移之前,建议执行以下这些步骤以确保日历数据库的完整性:

  1. 使用 csbackup 公用程序(或其他备份公用程序)备份日历数据库。

    有关 csbackup 的信息,请参见《Sun ONE Calendar Server 管理员指南》。

  2. 对日历数据库运行 csdb 公用程序的 check 命令,以检查数据库是否损坏。如果 check 命令检测到任何损坏,请运行 csdb 公用程序的 rebuild 命令重建数据库。

    有关 csdbcsbackup 公用程序的文档,请参见《Sun ONE Calendar Server 管理员指南》。

准备迁移

在运行 ncs4migrate 公用程序之前,请在目标机器上执行以下步骤:

  1. root 身份或具有系统管理员权限的用户登录(或者成为该用户)。

  2. 转到 server-root\cal\bin 目录。

  3. 创建一个名为 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 文件的信息,请参见“从多个节点迁移数据”

  4. 如果打算迁移所选用户,请在 server-root\cal\bin 目录中创建用户过滤文件 ncs4userfilter.datncs4userfilter.dat 是一个文本文件,指定您要迁移的用户。每一行表示一个用户,其格式为以下其中一种:

    • Netscape Calendar Server 日历系统中的 node-number:user idnscalxitemid 属性)

    • 用户 UID 属性

    例如,ncs4userfilter.dat 文件中的几项可能是:

    caluser1
    caluser2
    10000:00256
    10000:00257

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

  5. 确保 LDAP 服务器正在运行。

  6. 若要避免在迁移期间更新日历数据库,请停止 Calendar Server。但您可运行或停止 Netscape Calendar Server 。

现在就可以迁移 Netscape Calendar Server 4.0 数据了。

迁移数据

在目标机器上执行以下步骤:

  1. root 身份或具有系统管理员权限的用户登录后,定位到 server-root\cal\bin 目录(如有必要)。

  2. 在命令行中键入 ncs4migrate

    ncs4migrate 公用程序随即显示欢迎菜单,其中包含表 5中显示的选项。

    备注:尽管 ncs4migrate 会显示(E)xport 和(I)mport 选项,但这些选项是不受支持的,您不应使用它们。


    表 5    ncs4migrate 公用程序选项 

    ncs4migrate 选项

    说明

    (E)xport  

    将 Netscape Calendar Server 4.0 日历数据库导出到中间文件。  

    (I)mport  

    将中间文件中的数据导入到日历数据库。  

    (S)kip  

    跳过中间文件。一次只将一条记录从 Netscape Calendar Server 4.0 迁移到 Calendar Server 5.0。  

    (L)igging = ON|OFF  

    设置日志记录。日志记录的文件名是 ncs4migrate_yyyymmdd-hhmmss.log。默认为“ON”。  

    (V)erbose = ON|OFF  

    设置详细日志。默认为“OFF”。

    为节省磁盘空间,建议保留为“OFF”。  

    (D)ebug = ON|OFF  

    设置调试日志。默认为“OFF”。  

    (Q)uiet = ON|OFF  

    设置屏幕输出。默认为“OFF”。  

    (T)erminate = TRUE|FALSE  

    如果 Netscape Calendar Server 4.0 数据库中的用户不在 LDAP 中,将终止。默认为“FALSE”。  

    (O)nly = TRUE|FALSE  

    只迁移用户过滤文件 ncs4userfilter.dat 中的用户。 默认为“FALSE”。

    如果 O 和 M 为 TRUE,则 ncs4migrate 会迁移所有在过滤文件中具有参与人员(无论是所有者或参与者)的事件。所有参与者的事件都会迁移到他们的日历中。  

    (M)igrate = TRUE|FALSE  

    迁移用户过滤文件中的用户。默认为“FALSE”。  

    (B)ypass = TRUE|FALSE  

    不迁移用户过滤文件中的用户。默认为“FALSE”。  

    (A)ny = TRUE|FALSE  

    Netscape Calendar Server 安全访问级别的任何组合会在 Calendar Server 中产生一个授权。默认为“TRUE”。“FALSE”表示所有 3 个访问级别都必须存在;请参阅“帮助(H)”。  

    (U)ser  

    显示用户过滤文件 ncs4userfilter.dat
    使用 O 选项打开或关闭过滤功能。默认为“OFF”。
     

    (P)ath  

    Netscape Calendar Server 4.0 数据库的路径文件。文件名是 ncs4dirpaths.dat  

    (H)elp  

    显示帮助屏幕  

    (E)xit  

    退出程序。  

  3. ncs4migrate 菜单中,指定 S 选项可迁移所有用户。或者,如果要迁移用户过滤文件 (ncs4userfilter.dat) 中的特定用户,请指定 O 选项。

  4. 监视迁移日志文件以检查迁移状态。有关更多信息,请参见检查迁移日志文件

  5. 迁移完成后,请按照检查已迁移的数据中的说明检查已迁移的日历数据库。


从多个节点迁移数据
若要从多个节点迁移 Netscape Calendar Server 4.0 数据,请在目标机器上执行以下步骤:

  1. 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 数据。

  2. 转到 server-root\cal\bin 目录。

  3. 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

  4. 若要运行迁移公用程序,请在命令行中键入 ncs4migrate

  5. ncs4migrate 菜单中,指定 S 选项可迁移所有用户。或者,如果要迁移用户过滤文件(ncs4userfilter.dat)中的特定用户,请指定 O 选项。

  6. 监视迁移日志文件以检查迁移状态。有关更多信息,请参见检查迁移日志文件

  7. 迁移完成后,请按照检查已迁移的数据中的说明检查已迁移的日历数据库。


检查迁移日志文件
ncs4migrate 公用程序在 server-root\cal\bin 目录中生成具有以下名称的日志文件:

ncs4migrate_yyyymmdd-hhmmss.log

其中,yyyymmdd-hhmmss 是指示迁移开始时间的时间戳。

如果 ncs4migrate 公用程序已运行了很长时间,请检查日志文件的大小是否正在增加,若是则表示公用程序仍在运行。



备注 若要防止日志文件变得太大,请省略 ncs4migrate 的 (V)erbose
选项。



检查已迁移的数据

迁移完成后,请在目标机器上执行以下步骤:

  1. 运行 csdb 公用程序的 check 命令扫描日历数据库是否损坏。如果 check 命令检测到任何损坏,请运行 csdb 公用程序的 rebuild 命令重建数据库。

    有关 csdb 公用程序的 checkrebuild 命令的文档,请参见文档 Web 站点上的《Sun ONE Calendar Server 管理员指南》。

  2. 如有必要,请重新启动 Calendar Server。

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


csmig 迁移公用程序

csmig 公用程序会把 Calendar Server 5.1.1 版之前创建的日历数据库迁移到一个支持 LDAP 日历查找数据库 (CLD) 插件的目标数据库。这样,使用该插件就可以访问迁移的数据库中的日历(Calendar Server 5.1.1 的新部署不需要该迁移)。

LDAP CLD 插件提供的日历数据库的横向伸缩性允许日历分布在多个后端服务器之间。有关 LDAP CLD 插件的信息,请参见《Sun ONE Calendar Server 管理员指南》。

该文档说明以下主题:

csmig 功能

csmig 迁移公用程序执行以下功能:

  • csmig 可迁移 caldb.berkeleydb.homedir.path 参数所指定的当前日历数据库(*.db 文件)中的用户和资源日历。在新的目标数据库中,csmig 会更新 LDAP CLD 插件日历属性 (calprops)、事件、待办事项(任务)、组日程安排引擎 (gse) 数据库文件所需的项。

    csmig 只写入目标数据库,而不写入现有的日历数据库。

  • csmig 会更新所有相关 LDAP 项的 LDAP 属性,包括 icsSubscribedicsCalendaricsCalendarOwnedicsFreeBusyicsSet 以及 uid(用于资源日历)。csmig 会为 LDAP 目录服务器数据库中的每个日历创建 icsDWPHost 属性。icsDWPHost 指定日历所在的后端服务器主机名。

  • csmig 为日历数据库中的每个日历分配一个所有者并将每个日历 ID (calid) 映射到所有者(如果需要)。按原样保留所有默认的 calid,不进行任何更改。其他日历将按以下方法进行映射:

    • 没有有效所有者的用户日历将由通过 -c 选项传递给 csmig 的用户所拥有。例如,如果 jsmith 没有所有者而且 orphan 被指定为 -c 选项,则它将转换为 orphan:jsmith

    • 没有所有者的资源日历将由通过 -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,您必须以 root 身份登录,或者在安装 Calendar Server 的系统上以具有管理权限的用户(如 icsuser)登录。

    您在存储用户首选项 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 ErrorFilecsmig 将所有错误或无法解析的数据库项写入其中的文件。如果数据库项无法解析,则它们将不会写入目标数据库。默认值为 MigrateError

-m MappingFile 指定用于更新 LDAP 架构项的映射文件。该映射文件列出了 LDAP 架构的建议修改,但不执行对架构的实际修改。

-c calendarOwner 为没有所有者的用户日历指定所有者。

-r resourceOwner 为没有所有者的资源日历指定所有者。

csmig 迁移步骤

在您配置中的所有服务器上都安装了 Calendar Server 5.1.1 后,必须运行 csmig 才能将现有的 Calendar Server 和 LDAP 数据迁移到新的 Calendar Server 和 LDAP 数据,这需要 LDAP CLD 插件能够正常工作。使用 csmig 迁移日历数据,建议您遵循以下步骤:

  1. 配置 LDAP 目录服务器-添加索引可大大提高迁移和日历搜索 LDAP 数据的性能。

  2. 执行测试空运行-空运行 (dry run) 报告迁移期间 csmig 将执行的操作,但并不迁移任何实际数据。进行空运行后,可以更正任何错误并确定如何处理所有未解决 (unresolved) 日历的计划。

  3. 迁移组织数据-在产品运行 (production run) 期间,csmig 将迁移日历数据库(.db 文件)和 LDAP 数据(用户和组首选项数据)、icsSubscribedicsCalendaricsCalendarOwnedicsFreeBusyicsSetuid(用于资源日历)。迁移后,所有日历资源都将创建一个 LDAP 项。

配置 LDAP 目录服务器

要提高性能,可考虑将以下两个新索引添加到 slapd.ldbm.conf 文件中:

  • 索引 icscalendar preseqsub-由迁移过程使用,来搜索 icsCalendar 属性。

  • 索引 icscalendarowned preseqsub-迁移过程不需要,但在启用 LDAP CLD 插件后,执行 LDAP 数据的日历搜索(对于预订操作)时使用。

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

执行测试空运行

在测试服务器上执行的测试空运行(test dry run)报告迁移的内容,但不执行实际组织数据库的迁移。空运行使您得以确定迁移组织数据库的计划。例如,您可以决定如何处理没有所有者的“孤儿”日历。

要使用 csmig 执行测试空运行,请遵循以下步骤:

  1. root 身份(或成为 root )或以具有管理权限的用户(如 icsuser)登录到安装 Calendar Server 的系统。

  2. 在测试服务器上安装 Calendar Server 5.1.1(如果必要)。

  3. 将日历数据库的快照复制到测试服务器中。

  4. 安装 LDAP 服务器以模拟组织 LDAP 环境。以 slapd.ldbm.conf 文件中的新索引在该服务器上安装 LDAP 数据库快照。

  5. 转到 server-root/cal/bin/目录

  6. 考虑为没有所有者的用户日历创建一个通用 calid。例如在 Solaris 系统上,以下命令将创建一个 calidorphan 的用户:

    ./csuser -g orphan -s adminuser -y password -l en -c orphan create orphan

  7. 使用 stop-cal 命令停止 Calendar Server(如有必要)。

  8. 运行 csdb check 命令检查数据库是否损坏。如果指示数据库已损坏,则运行 csdb rebuild 命令重建该数据库。

  9. 带有 dryrun 选项运行 csmig。例如,在 Solaris 系统上,输入:

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

    该命令将没有所有者的用户日历分配给 orphan,将没有所有者的资源日历分配给 calmaster

  10. 检查输出、映射和错误文件。解决所发现的任何 LDAP 问题或错误。在进行实际迁移之前,应确定如何处理所有未解决的日历。可选择以下方法:

    • 在迁移之前删除所有不需要的日历。

    • 为所有未解决的日历分配所有者。

    • 在迁移期间,使用 -c-r 选项让 csmig 将所有者分配给日历。

  11. 强烈建议您在真正迁移组织日历数据库之前,先在测试服务器上迁移日历数据库。该步骤将使您能够准确看到将如何迁移数据,并在迁移组织数据库之前更正所有问题。

    例如,在 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

  12. 测试迁移完成后,将迁移的数据库复制到 caldb.berkeleydb.homedir.path 参数指定的 /csdb 目录中。或者编辑该参数以指向迁移数据库的新位置。然后,执行以下检查:

    • 在新的日历数据库上运行 csdb check。迁移数据库中的事件和待办事项的数目应与迁移前数据库中的数目相匹配。

    • 搜索 icsCalendarOwned 项并确保这些项的数目与迁移前日历的数目相匹配。

    • 登录到 Calendar Express 并检验迁移的数据库中是否存在某些日历。

如果测试迁移成功,即可以迁移组织数据库。

迁移组织数据

要使用 csmig 迁移组织数据库,请遵循以下步骤:

  1. root 身份(或成为 root )或以具有管理权限的用户(如 icsuser)登录到安装 Calendar Server 的系统。

  2. 转到 server-root/cal/bin/目录。

  3. 使用 stop-cal 命令停止 Calendar Server(如有必要)。

  4. 备份以下数据:

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

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

    • ics.conf 文件。实际上不需要该步骤,但如果需要恢复到原始配置,则该步骤会很有用。

  5. 带有 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

  6. 检查错误文件中所有未解决的日历,并根据“执行测试空运行”中步骤 10中的计划解决它们。

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

  8. 运行 csdb check 命令检查迁移的数据库。如果指示数据库已损坏,则运行 csdb rebuild 命令重建该数据库。

  9. 启用 LDAP CLD 插件,方法是对 ics.conf 文件中的下列配置参数进行任何必要的更改:

    • 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 缓存目录的位置。默认值为 server-root/var/csdb/cld_cache

      检查该目录是否正确,或者如果希望将 CLD 缓存放入其他位置,请修改该参数。

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

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

  11. 登录到 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 空运行日历所有者不是需要的日历所有者
例如,日历 tchang:myCalendar 在日历数据库中的所有者为 jsmith,而 csmig 空运行却将该映射显示为 jsmith:tchang_myCalendar。我希望将该日历名称保留为 tchang:myCalendar 并将所有者指定为 tchang


解决方案
在迁移之前,使用 cscal 公用程序将日历所有者 tchang:myCalendar 更改为 tchang。完成更改后,迁移会将该日历映射为 tchang:myCalendar 并将 icsCalendarowned 添加到 tchang 的 LDAP 项。


LDAP 日历搜索不能正常工作
迁移后,将启用 LDAP 日历搜索,但日历搜索对话框不返回任何结果或只返回部分结果。


解决方案
启用 LDAP 日历搜索将使 Calendar Server 搜索(&(objectclass=icscalendaruser)(icscalendarowned=*substr*))

手动运行具有以下过滤器的两个不同的 LDAP 数据搜索,并比较输出:

  • 具有过滤器为 (&(objectclass=icscalendaruser)(icscalendarowned=*substr*))的 ldapsearch

  • 具有过滤器为 (icscalendarowned=*substr*) 的 ldapsearch

由于服务器使用包含 icsCalendaruser objectclass 的过滤器,因此 LDAP 服务器可能是在没有启用架构检查的情况下部署的,有些日历项可能没有提供 icsCalendaruser objectclass。


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

  • 具有 5 个事件的 basketball

  • 具有 10 个事件的 jsmith:basketball

空运行指示在迁移期间,这两个日历将会合并,最终生成的日历为:

  • 具有 15 个事件的 jsmith:basketball,所有者为 jsmith

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

Error modifying calendar properties, error=2


解决方案
如果不想合并这两个日历,则在迁移前,将 basketball 的所有者更改为 jsmith 以外的用户。这样将会保持这两个单独日历的数据完整性。


如何将孤儿日历分配给其他所有者?
默认情况下,csmig 将所有孤儿日历分配给单个所有者,但我希望将某些孤儿日历分配给其他所有者。


解决方案
csmig 不接受命令行中的映射文件。不过,您可以在迁移之前将所有者分配给原始数据库中的孤儿日历。检查所有孤儿日历的空运行映射文件。然后在迁移前使用 cscal 公用程序将所有者分配给孤儿日历。以空运行模式再次运行 csmig 以验证新的所有者。


如何将日历用户移到其他后端服务器?
如何将用户从一个后端服务器移到另一个后端服务器?


解决方案
若要移动日历用户,您需要导出原始服务器中的每个用户日历,然后将这些日历导入到另一个服务器。移动日历后,可以删除原始服务器上的日历。有关移动用户的详细步骤,请参见《Sun ONE Calendar Server 管理员指南》。


上一章     目录     索引     下一章     
版权所有 2002 Sun Microsystems, Inc. 全权所有。

更新日期 2002 年 8 月 30 日