Sun ONE Calendar Server 6.0 安装指南(适用于 Solaris 操作系统) |
第 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 实用程序执行以下功能:
迁移时间
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 分钟:
cs5migrate 语法
cs5migrate 实用程序的语法如下:
-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 [ -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 文件添加以下两个新索引:
有关在 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 问题或错误。在进行实际的迁移之前,确定如何处理未解决的日历。有以下若干选择:
- 强烈建议您在迁移实际的产品日历数据库之前在分步服务器上迁移日历数据库。执行此步骤,您可以切实了解迁移数据的方式,并可以在迁移产品数据库之前更正任何问题。
例如,在 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
- 将新迁移的数据库复制到 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 空运行日历的所有者不是我所希望的日历所有者
例如,名为 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 数据手动运行两个不同的搜索,并比较输出结果:
因为服务器使用包含 icsCalendaruser 对象类的过滤器,所以可能已在禁用模式检查的情况下部署了 LDAP 服务器,并且可能在没有 icsCalendaruser 对象类的情况下已经置备了某些日历项。
csmig 空运行指示重复的日历名称
csmig 空运行映射文件和输出文件指示存在重复的日历名称。例如,在初始数据库中,jsmith 拥有以下日历:
空运行指示在迁移时将合并这两个日历,生成的日历将为
输出文件将包含以下警告消息:
修改日历属性时出错,错误数 = 2
解决方法
如果不希望合并两个日历,则在迁移之前将 basketball 的所有者更改为 jsmith 以外的用户。这可以保持这两个独立日历数据的完整性。
如何将不带有所有者的日历指定给不同的所有者?
默认情况下,csmig 将所有不带有所有者的日历指定给一个所有者,但是我希望为其中的某些日历指定不同的所有者。
解决方法
csmig 不接受命令行中的映射文件。但是,可以在迁移之前为初始数据库中不带有所有者的日历指定所有者。检查所有不带有所有者的日历的空运行映射文件。然后在迁移之前使用 cscal 实用程序为不带有所有者的日历指定所有者。在空运行模式下再次运行 csmig 以验证新的所有者。
如何将日历用户移动到其它后端服务器?
如何将用户从一个后端服务器移动到另一个后端服务器?
解决方法
要移动日历用户,应导出初始服务器上该用户的每个日历,然后将日历导入到第二个服务器。移动日历后,可以删除初始服务器上的日历。有关移动用户的详细步骤,请参阅《Sun ONE Calendar Server 管理员指南》。
csvdmig 实用程序csvdmig 实用程序为要使用托管(虚拟)域的工作地点修改 Calendar Server 数据库和 LDAP 目录服务器数据库。csvdmig 实用程序按以下方式将域名添加到用户 ID:
注意 csvdmig 实用程序实际上并没有将数据从一个位置迁移到另一个位置,而是在数据的当前位置上修改日历数据库和 LDAP 目录服务器。
因此,在运行 csvdmig 之前,请备份您的 Calendar Server 数据库和 LDAP 目录服务器数据库。
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 示例
ics2migrate 实用程序ics2migrate 迁移实用程序可以将 iPlanet Calendar Server 2.x 日历数据和 LDAP 用户首选项迁移至 Calendar Server 6.0。
本节包括以下内容:
迁移要求
从 Calendar Server 2.x 到 6.0 的迁移要求具有以下硬件和软件:
源计算机和目标计算机可以是不同的服务器,也可以是同一服务器。有关支持的平台列表,请参阅《Sun ONE Calendar Server 发行说明》。
迁移内容
下表列出了 Calendar Server 2.x 数据,并说明了 ics2migrate 如何将这些数据迁移至 Calendar Server 6.0。
下表列出了 Calendar Server 2.x LDAP 属性,并说明了 ics2migrate 如何将这些属性迁移至 Calendar Server 6.0。
迁移过程
ics2migrate 的步骤包括:
注意 运行 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 用户首选项
要仅迁移 Calendar Server 2.x 数据库
要仅迁移 LDAP 用户首选项
表 3-3 列出了 ics2migrate 选项以及每个选项的说明。
检查迁移结果
迁移完成后,请检查结果:
迁移示例
迁移日历数据库和 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 目录中。
本节包含以下信息:
迁移要求
迁移要求以下硬件和软件:
源计算机和目标计算机可以是不同的服务器,也可以是同一服务器。有关支持的平台列表,请参阅《Sun ONE Calendar Server 发行说明》。
迁移内容
下表说明了 ncs4migrate 如何将 Netscape Calendar Server 4.0 数据迁移到 Calendar Server 6.0。
迁移步骤
备份 Calendar Server 5.0 数据库
迁移之前,建议执行以下步骤,以确保日历数据库的完整:
准备迁移
在运行 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 数据库所在目录的任何要求。
有关为多个节点上的数据创建 ncs4dirpaths.dat 文件的信息,请参阅迁移多个节点中的数据。
- 如果要迁移选定用户,请在 cal_svr_base/opt/SUNWics5/cal/sbin 目录中创建名为 ncs4userfilter.dat 的用户过滤器文件。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)”选项,但这些选项并不受支持,也不应使用。
- 从 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 实用程序运行时间很长,请检查日志文件的大小是否在不断增加,因为如果文件大小增加则说明实用程序仍在运行。
检查迁移的数据
完成迁移后,请在目标计算机上执行以下步骤:
csrename 实用程序csrename 实用程序按以下方式重命名日历用户:
csrename 实用程序位于以下目录中:
cal_svr_base/opt/SUNWics5/cal/sbin
运行 csrename 之前,您必须先:
要运行 csrename,您必须以 icsuser(或在配置过程中指定的 Calendar Server 运行时用户 ID)身份登录。如果您以超级用户(root 用户)身份运行 csrename,则可能需要重置新数据库文件的权限。要修改 LDAP 目录服务器属性,您还必须具有该目录的管理权限。
如果具有前端/后端服务器配置,则必须对每个后端服务器运行 csrename。
csrename 语法
请使用以下语法运行 csrename:
-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 bk548769DB|LDAP 指定获得更新的数据库:
csrename 示例