本章及使用由 Messaging Server 创建的域中的其他各章介绍了如何管理 Calendar Server,本章包含以下小节:
您可以通过运行 Delegated Administrator 实用程序(以前称为用户管理实用程序)或 Calendar Server 命令行实用程序,并编辑 ics.conf 配置文件来管理 Calendar Server。
要运行命令行实用程序,必须以具备管理权限的用户身份登录正在运行 Calendar Server 的系统。
有关更多信息,请参见附录 D,Calendar Server 命令行实用程序参考。
其他管理主题分别包含在其他单独的章节中。其中包括以下主题:
本节介绍了如何使用 start-cal 和 stop-cal,它包含以下主题:
可以使用 start-cal 和 stop-cal 命令启动和停止 Calendar Server。start-cal 和 stop-cal 实用程序位于 cal_svr_base/SUNWics5/cal/sbin 目录中。必须在已安装 Calendar Server 的本地计算机上运行这些实用程序。
Calendar Server 提供了 csstart 和 csstop 实用程序只是为了与其早期版本兼容。建议使用 start-cal 和 stop-cal 实用程序来启动和停止 Calendar Server。
start-cal 实用程序按以下顺序启动 Calendar Server 服务:
enpd—事件通知服务 (ENS)
csnotifyd—通知服务
csadmind—管理服务
csdwpd—数据库有线协议 (Database Wire Protocol, DWP) 服务,只能通过远程 Calendar Server 数据库配置启动的分布式数据库服务
cshttpd—HTTP 服务
csstored—自动备份服务
有关这些服务的介绍,请参见Calendar Server 服务
以具备管理权限的用户身份登录正在运行 Calendar Server 的系统。
转到 cal_svr_base/SUNWics5/cal/sbin 目录。
停止 Calendar Server:
./stop-cal |
自动备份由 csstored 进程来管理,在发出 start-cal 命令时,将自动启动该进程。但是,您可以根据需要来启用或禁用自动备份。默认值为禁用自动备份。即使未启用自动备份,csstored 进程也会运行。
有两种自动备份:热备份和归档备份。您可以分别启用或禁用它们。
发出 start-cal 命令之前必须先配置 csstored 进程,否则会收到错误消息,通知您尚未配置 csstored。此后每隔 24 小时您都会收到该消息,直到配置了此进程。
有关自动备份的信息和配置 csstored 的说明,请参见第 10 章,配置自动备份 (csstored)。
以下是启用和禁用自动备份的任务列表:
在命令行处,转至 ics.conf 所在的目录:
cd /etc/opt/SUNWics5/config
通过将以下 ics.conf 参数设置为 "yes" 来启用热备份:
caldb.berkeleydb.hotbackup.enable="yes"
指定热备份目录的目录路径:
caldb.berkeleydb.hotbackup.path= /var/opt/SUNWics5/hotbackup_directory
默认值为当前目录。
编辑完 ics.conf 文件后,请重新启动 Calendar Server:
cal_svr_base/SUNWics5/cal/sbin/start-cal
您无需为编辑 ics.conf 文件停止日历服务,但必须重新启动服务以使更改生效。
在命令行处,转至 ics.conf 所在的目录:
cd /etc/opt/SUNWics5/config
通过将以下 ics.conf 参数设置为 "yes" 来启用归档备份:
caldb.berkeleydb.archive.enable="yes"
指定归档目录的目录路径:
caldb.berkeleydb.archive.path= /var/opt/SUNWics5/hotbackup_directory
默认值为当前目录。
编辑完 ics.conf 文件后,请重新启动 Calendar Server:
cal_svr_base/SUNWics5/cal/sbin/start-cal
您无需为编辑 ics.conf 文件停止日历服务,但必须重新启动服务以使更改生效。
默认情况下,禁用备份。如果您先前已启用了它们而现在要禁用它们,请执行以下步骤:
在命令行处,转至 ics.conf 所在的目录:
cd /etc/opt/SUNWics5/config
通过将以下 ics.conf 参数设置为 "no" 来禁用热备份:
caldb.berkeleydb.hotbackup.enable="no"
编辑完 ics.conf 文件后,请重新启动 Calendar Server:
cal_svr_base/SUNWics5/cal/sbin/start-cal
您无需为编辑 ics.conf 文件停止日历服务,但必须重新启动服务以使更改生效。
默认情况下,禁用备份。如果您先前已启用了它们而现在要禁用它们,请执行以下步骤:
在命令行处,转至 ics.conf 所在的目录:
cd /etc/opt/SUNWics5/config
通过将以下 ics.conf 参数设置为 "no" 来禁用归档备份:
caldb.berkeleydb.archive.enable="no"
编辑完 ics.conf 文件后,请重新启动 Calendar Server:
cal_svr_base/SUNWics5/cal/sbin/start-cal
您无需为编辑 ics.conf 文件停止日历服务,但必须重新启动服务以使更改生效。
组计划引擎 (GSE) 保持一个将用于更新组件数据库的事件队列。管理员可以更改超时值以调整 Calendar Server 扫描队列的时间间隔。还可以列出队列中的事件,如果需要也可以将特定事件删除。
本节包含以下主题:
GSE 允许 Calendar Server 用户创建事件和邀请其他参与者。如果参与者也在同一个 Calendar Server 上,则会在其日历上预定此事件。如果参与者不在同一个 Calendar Server 上,则会通过电子邮件向其发送邀请。参与者可以接受或拒绝邀请,GSE 将根据回复来更新事件。
GSE 队列实际上是由 GSE 管理的独立数据库。Calendar Server 将扫描队列来查找需要对组件数据库进行哪些更新。
可以调整扫描的频率来调整 Calendar Server。这可通过更改 ics.conf 文件中 gse.belowthresholdtimeout 的超时值来完成。请参见第 21 章,优化 Calender Server 的性能。
可以使用 csschedule 来管理(列出和删除)GSE 队列条目。必须在已安装 Calendar Server 的本地计算机上运行 csschedule。
要列出 GSE 队列中的条目,请使用 csschedule 实用程序的 list 命令。
例如,要列出 GSE 队列中的所有条目:
csschedule list |
要列出 GSE 队列中存储的前十个条目:
csschedule -c 10 list |
要列出 GSE 队列中带有 calid Holiday_Schedule 的所有条目:
csschedule -v list Holiday_Schedule |
要删除 GSE 队列中的条目,请使用 csschedule 实用程序的 delete 命令。
例如,要删除 GSE 队列中的所有条目:
csschedule -v delete
要删除 GSE 队列中 calA 日历的首次计划时间为 2001 年 11 月 30 日 13:30:45,偏移数为 1,唯一标识符为 1111,周期 ID 为 0,序列号为 0 的条目:
csschedule -v -t 20011130T133045Z -o 1 -u 1111 -r 0 -n 0 delete calA
您也许要将监视系统活动作为日常任务的一部分。以下列出了几个可以用于监视 Calendar Server 活动的实用程序工具:csmonitor、csstats、 cstool。此外,您还可以设置多个日志文件来帮助监视系统的使用情况。
本节包含以下主题:
此 Calendar Server 实用程序是一种要求使用 bash 的 shell 脚本。调用该实用程序时,它将执行以下功能:
根据 ics.conf 文件中指定的日志级别来监视和记录以下进程:csadmind、csnotifyd、cshttpd 和 enpd。
查看 cshttpd 是否正在接受命令。
查看系统是否具有 LDAP 连接。
如果启用了循环日志记录,则查看是否存在多个事务文件,如果存在,则发送电子邮件警告。
检查日历数据库的可用磁盘空间,以确保有足够的空间进行正常操作。
发生错误时,该实用程序将记录这些错误,并向由 ics.conf 参数 service.monitor.emailaddress.to 所指定的管理员发送电子邮件。
为了进行调试,您可以将监视程序配置为以时间间隔很短的持续循环模式运行,但是该模式需要更多的系统资源,因此,在正常生产过程中您不希望将监视程序保持在该模式下。
要在正常情况下使用 csmonitor,请将其设置为以您所选择的时间间隔运行。
有关 csmonitor 实用程序的更多信息,请参见附录 D,Calendar Server 命令行实用程序参考。
以有权更改此配置的管理员身份登录。
转至 /etc/opt/SUNWics5/cal/config 目录。
通过复制和重命名旧的 ics.conf 文件来保存该文件。
编辑下表中所示的一个或多个 ics.conf 参数:
参数 |
说明和默认值 |
---|---|
指定 csmonitor 是否应持续循环:"0"—不持续循环(默认值)。"1"—持续循环。 将此参数设置为 "1" 可以使 csmonitor 自动运行。 |
|
指定两次监视循环之间的延迟秒数。默认值为 "60" 秒。 为了进行调试,请设置较短的时间间隔;为了进行生产,请设置较长的时间间隔。 |
|
指定 csmonitor 从中发送信息的电子邮件地址。未提供默认值。 |
|
指定 csmonitor 向其发送消息的电子邮件地址。未提供默认值。 |
|
service.monitor.csdb.logthreshold |
监视日历数据库 (csdb)。以总磁盘空间百分比的形式指定一个阈值,以代表最大磁盘空间占用率。如果 csdb 目录的磁盘空间占用率超过该值,它将发送警告电子邮件消息。默认值为 "90"。 |
指定 csmonitor 日志文件名。默认值为 "csmonitor.log"。 |
|
指定日志文件的最大大小。如果日志文件大小超过此值,csmonitor 将日志另存为 csmonitor.log.timestamp,然后重置当前日志。默认值为 "2097152" |
|
指定调试级别。范围是 0 到 5,值越高,csmonitor 发送的消息就越精确,越详细。默认值为 "0",指定无日志记录。值为 "5" 时表示调试日志记录。 |
将此文件另存为 ics.conf。
重新启动 Calendar Server。
cal_svr_base/SUNWics5/cal/sbin/start-cal
csstats 实用程序显示日历配置 (counter.conf) 文件中定义的计数器对象的统计信息。计数器对象(例如 httpstat、authstat、wcapstat 或 dbstat)显示 Calendar Server 的以下信息:
最大并行连接数目和连接总数目
成功和失败的登录与连接的总数目
数据库读取、写入和删除的数目
有关 Calendar Server 计数器统计信息的信息,请参见附录 E,Calendar Server 配置参数。
您可以对以下服务及安装了 Calendar Server 的计算机执行 ping:
cshttpd
csadmind
enpd
有关使用 cstool 的信息,请参见附录 D,Calendar Server 命令行实用程序参考。
每个 Calendar Server 服务都将状态信息写入它的日志文件。每个日志文件都根据其相关的服务名命名,如下表所示:
服务名 |
日志文件名 |
---|---|
管理服务 (csadmind) |
admin.log |
分布式数据库服务 (csdwpd) |
dwp.log |
HTTP 服务 (cshttpd) |
http.log |
通知服务 (csnotifyd) |
notify.log |
单点登录 |
am_sso.log |
启动命令的日志 |
start.log |
停止命令的日志 |
stop.log |
存储命令的日志 |
store.log |
Calendar Server 日志文件存储在以下默认目录中:
/var/opt/SUNWics5/logs
每个日志文件将回滚为由唯一编号标识的新日志文件。例如:
admin.log.8.1083013284 http.log.8.1083013284
Calendar Server 为日志文件中报告的事件提供了六种严重级别,如下表所示。可以通过修改 ics.conf 参数 logfile.loglevel 来指定 Calendar Server 在日志文件中报告的事件的严重级别。
严重级别 |
含义 |
---|---|
CRITICAL |
表示处于危险状态。 |
ERROR |
表示处于错误状态。 |
WARNING |
表示处于警告状态。 |
NOTICE |
表示处于运行正常、但需要特别注意的状态。这是每个日历服务的默认报告级别。 |
INFORMATION |
表示提示性信息。 |
DEBUG |
表示调试级别的信息。 |
一个日志事件通过一行内容表示,其中显示相关的时间标记、服务器主机名、严重级别、进程名(进程 ID)、事件类型、优先级和说明。
有关 ics.conf 日志设置的信息,请参见附录 E,Calendar Server 配置参数。
如果已启用 CLD 高速缓存,则可能需要经常清除此高速缓存。本节包含以下主题:
CLD 高速缓存会因各种原因而变得与系统配置不同步,例如:
添加、删除或重命名服务器。
在配置中改变服务器的功能。
将一个或多个日历移至不同的后端服务器。
如果执行了以上任一操作,则为了刷新 CLD 高速缓存,您必须清除它。
停止 Calendar Server。
删除 /var/opt/SUNWics5/csdb/cld_cache 目录中的所有文件,但不要删除 cld_cache 目录本身。
重新启动 Calendar Server。
如果在配置中添加、删除或更改了服务器名,则为了避免错误,应执行以下几个“内务处理”步骤:
清除 CLD 高速缓存
如果已卸下旧服务器,请从出现该服务器的 ics.conf 参数中删除它。
匿名访问是一种不需要验证的特殊登录方式。默认情况下,启用匿名登录时,将启用对公共日历的读写访问权限。有可能拒绝对公共日历的写访问权限。本节包含以下主题:
Communications Express 需要允许进行读写操作的匿名登录。请参见配置 Communications Express。
以有权更改此配置的管理员身份登录。
转至 /etc/opt/SUNWics5/cal/config 目录。
通过复制和重命名旧的 ics.conf 文件来保存该文件。
编辑 ics.conf 中的以下参数以启用匿名访问:
参数 |
说明和默认值 |
---|---|
service.http.allowanonymouslogin |
如果需要,通过将该参数设置为 "yes" 可以启用匿名访问(登录)。默认值为 "yes"。 |
service.calendarsearch.ldap |
出于安全性目的,启用匿名登录之后,您可能希望在进行日历搜索时,首先禁用对 LDAP 的搜索,为此可以将该参数设置为 "no"(默认值)。 |
Communications Express 需要 service.calendarsearch.ldap 参数值为 "no"。这与有关在 DWP 环境中调优系统以获得最佳性能的说明冲突。(数据库分布在多个后端中。)请参见提高日历搜索在 DWP 环境中的性能。
将此文件另存为 ics.conf。
重新启动 Calendar Server。
cal_svr_base/SUNWics5/cal/sbin/start-cal
以有权更改此配置的管理员身份登录。
转至 /etc/opt/SUNWics5/cal/config 目录。
通过复制和重命名旧的 ics.conf 文件来保存该文件。
编辑下表所示的以下 ics.conf 参数:
参数 |
说明和默认值 |
---|---|
service.wcap.anonymous. allowpubliccalendarwrite |
启用或禁用允许进行匿名访问的用户对公共日历的写操作。将此值设置为 "yes"(默认值)可以启用写访问权限。 |
将此文件另存为 ics.conf。
重新启动 Calendar Server。
cal_svr_base/SUNWics5/cal/sbin/start-cal
为实现 Communications Express,必须启用代理管理员登录(代理验证)。有关为 Communications Express 配置代理验证的说明,请参见配置 Communications Express。
但是,即使不使用 Communications Express,也可以启用代理验证。本节包含启用代理验证而不使用 Communications Express 的过程:
以有权更改此配置的管理员身份登录。
转至 /etc/opt/SUNWics5/cal/config 目录。
通过复制和重命名旧的 ics.conf 文件来保存该文件。
编辑 ics.conf 文件,请设置以下参数:
service.http.allowadminproxy = "yes"
将此文件另存为 ics.conf。
重新启动 Calendar Server 以便新值生效。
使用以下 WCAP 命令验证管理员代理登录正在工作:
http://server[:port] /login.wcap?user=admin-user&password=admin-password &proxyauth=calendar-user
其中:
server—运行 Calendar Server 的服务器的名称。
port—Calendar Server 端口号。默认端口为 80。
admin-user—Calendar Server 管理员。例如,calmaster。
admin-password—admin-user 的密码。
calendar-user—Calendar Server 用户的 calid。
如果命令运行成功,Calendar Server 将显示 calendar-user 的日历。如果发生问题,Calendar Server 将显示“未授权”。原因可能是:
admin-user 没有 Calendar Server 管理员权限。
admin-password 不正确。
calendar-user 不是有效的 Calendar Server 用户。
在当前发行版本中,请不要使用 cstool refresh 命令来刷新配置。应使用 stop-cal 和 start-cal 命令。有关更多信息,请参见启动和停止 Calendar Server。
本章包括以下各节,介绍了如何管理托管域:
为托管域配置了日历安装并执行了第 11 章,设置托管域中介绍的准备工作后,您可以添加新的托管域。
每个域都有一组可设置的属性和首选项。这些属性是 icsCalendarDomain 对象类的一部分。这些属性包含首选项,例如访问权限、访问控制列表 [ACL]、域搜索、域搜索访问权限、用户状态和代理登录。
要管理 Calendar Server 托管(虚拟域),请使用以下两组工具中的一种:
Delegated Administrator 控制台或实用程序—适用于 Schema 2 环境。
Delegated Administrator 是 Java Enterprise System 安装程序中的一个可单独安装的组件。有关该实用程序的更多信息,请参见《Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide》。有关该控制台的更多信息,请使用 Delegated Administrator 控制台联机帮助。
Calendar Server 实用程序—(csdomain 和 csattribute)适用于 Schema 1 环境。
该实用程序是在安装 Calendar Server 时安装的。您可以使用 csdomain 添加或删除属性,但没有 modify 命令。使用 csattribute 可以修改现有属性的值。此外,如果需要,请使用 ldapmodify 添加或删除由 csdomain 在域中创建的对象类。
有关 csdomain 和 csattribute 的信息,请参见附录 D,Calendar Server 命令行实用程序参考。
有关特定对象类和属性的信息,请参见《Sun Java System Communications Services 6 2005Q4 Schema Reference》。
有关托管域的概述和其他介绍材料,请参见第 11 章,设置托管域。
Calendar Server 并不支持使用 Access Manager 控制台来管理域。
创建 Schema 2 或 Schema 1 的托管域:
您可以使用 Delegated Administrator 控制台或实用程序:
控制台—使用“组织列表”页面上的创建新组织向导。
有关更多信息,请参见 Delegated Administrator 控制台联机帮助。
实用程序—使用 commadmin domain create 命令。
例如,要创建域 sesta.com,请发出以下命令:
commadmin domain create -D calmaster -d sesta.com -w calmasterpassword -S cal -B backend.sesta.com
有关 Delegated Administrator 实用程序的信息,请参见《Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide》。
您必须在托管域模式下运行 csdomain。有关如何启动托管域的说明,请参见第 11 章,设置托管域。
要在 Schema 1 下创建托管域,请使用 csdomain create。例如,要创建 west.sesta.com,请使用以下命令:
csdomain create west.sesta.com
本节包括要启用交叉域搜索所必须执行的两项任务:
在允许搜索该域的每个域的 LDAP 条目中添加允许搜索该域的域的名称。
当该域中的用户向事件发出邀请时,添加允许该域进行搜索的域的名称。
使用以下工具之一可以完成此操作:ldapmodify(用于任一 Schema 模式),或者 Delegated Administrator 控制台或实用程序(适用于 Schema 2)。
每个域 LDAP 条目在 ACE 中指定访问权限,该 ACE 是在 icsExtendedDomainPrefs 属性的 domainAccess 参数中定义的。允许外部域搜索该域的两种方法是:
日历访问控制 中有对 ACE 结构的进一步解释。
这有三种实现方法:
使用 ldapmodify,在 icsExtendedDomainPrefs 的 domainAccess 首选项中创建以下 ACE 字符串:
@domain_being_allowed ^a^lsfr^g
通过指定允许搜索该域的域生成 ACE,然后指定允许搜索的充足权限。
使用 Delegated Administrator 实用程序命令 commadmin domain modify,通过指定 icsExtendedDomainPrefs 属性中的 domainAccess 首选项来添加 ACE 字符串。
例如,在 Schema 2 环境中,sesta.com 允许从 siroe.com 进行搜索:
commadmin domain modify -D admin -w adminpassword -X hostmachine_1 -d sesta.com -A +icsextendeddomainprefs:"domainAccess=@@d^a^slfrwd^g; @siroe.com^a^lsfrwd^g;anonymous^a^r^g;@^a^s^g"
使用 Delegated Administrator 控制台,可以在创建或编辑组织属性时将域添加到允许来自这些组织中的用户的邀请列表。
这将更新 icsExtendedDomainPrefs 属性中的 domainAccess 首选项。
虽然您可以使用列出的前两种方法指定给予域的确切权限,但是后一种方法(使用 Delegated Administrator 控制台)却不能给予管理员同样多的控制权限。权限列表是预设的。给予的权限有:free-busy 访问和 event scheduling 访问。用户无法看到事件的详细信息,除非日历的属主已将权限设置为允许所有用户阅读该信息。
有三种方法允许外部域搜索该域:
使用 ldapmodify,在 icsExtendedDomainPrefs 的 domainAccess 首选项中创建以下 ACE 字符串:
@^a^slfr^g
通过指定所有域都有执行搜索的充足访问权限来生成 ACE。
使用 Delegated Administrator 实用程序命令 commadmin domain modify,通过指定 icsExtendedDomainPrefs 属性中的 domainAccess 首选项来添加 ACE 字符串。
例如,在 Schema 2 环境中,sesta.com 允许所有域执行搜索:
commadmin domain modify -D admin -w adminpassword -X hostmachine_1 -d sesta.com -A +icsextendeddomainprefs:"domainAccess=@@d^a^slfrwd^g; anonymous^a^r^g;@^a^slfr^g"
字符 @@d 是指主要属主的域。
使用 Delegated Administrator 控制台,可以在创建或编辑组织属性时将域添加到允许来自这些组织中的用户的邀请列表。
这将更新 icsExtendedDomainPrefs 属性中的 domainAccess 首选项。
虽然您可以使用列出的前两种方法指定给予域的确切权限,但是后一种方法(使用 Delegated Administrator 控制台)却不能给予管理员同样多的控制权限。权限列表是预设的。给予的权限有:free-busy 访问和 event scheduling 访问。用户无法看到事件的详细信息,除非日历的属主已将权限设置为允许所有用户阅读该信息。
有三种方式可以添加允许该域进行搜索的外部域:
使用 ldapmodify,为允许该域中的用户搜索的每一个外部域添加一个 icsDomainNames 实例。
例如,执行交叉域搜索时,sesta.com 将在 siroe.com 和 example.com 中执行搜索。使用 ldapmodify(适用于 Schema 1 或 Schema 2)创建以下的 LDIF:
dn: dc=sesta, dc=com, o=internet changetype: modify add: icsDomainNames icsDomainNames:siroe.com icsDomainNames:example.com
使用 Delegated Administrator 实用程序命令 commadmin domain modify,指定选项 -A 以添加要搜索的域的名称。
例如:
commadmin domain modify -D admin -w adminpassword -X hostmachine_1 -d sesta.com -A +icsDomainNames:siroe.com -A +icsDomainNames:example.com
使用 Delegated Administrator 控制台,可以在创建或编辑组织属性时将域添加到这些组织中的邀请日历列表。
这将向域 LDAP 条目中添加 icsDomainNames 属性。当该域中的用户向事件发送邀请时,为要搜索的每个外部域添加一个属性。
有关更多信息,请参见 Delegated Administrator 控制台联机帮助。
Calendar Server 默认启用的是非托管域。如果在 Java Enterprise System 部署中使用了 Calendar Server 和 Messaging Server,则应使用托管域。
可以通过编辑 ics.conf 文件来启用或禁用安装的托管域。
按照以下说明编辑 ics.conf 文件:
service.virtualdomain.support="yes"(默认值为 "no"。)
重新启动日历服务。
有关实现托管域需要的所有 ics.conf 参数的列表,请参见设置托管域环境。
本章介绍如何使用 Calendar Server 实用程序来管理用户和资源。本章包括以下各节:
可以使用以下任意一种用户管理工具来管理日历用户和资源:
Delegated Administrator 控制台
使用此 GUI 在 LDAP 中为 Calendar Server 置备用户和资源。有关使用此 GUI 的信息,请参见 Delegated Administrator 控制台联机帮助。
Delegated Administrator 实用程序 (commadmin)
使用这些工具在 LDAP 中为 Calendar Server 置备用户和资源。有关详细说明,请参见《Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide》。
Delegated Administrator 不管理日历。要创建用户和资源的日历,请使用 Calendar Server 实用程序。
Calendar Server 实用程序(csuser 和 csresource)
使用这些实用程序管理日历。此外,如果您的配置满足以下所有条件,则可以使用它们来管理用户和资源:
未使用 Access Manager。
使用 Sun LDAP Schema 1 安装了早期版本的 Calendar Server 或 Messaging Server
打算继续使用 Schema 1。
另请参见本指南附录 D,Calendar Server 命令行实用程序参考中的命令行实用程序参考。
在某些情况下,即使您正在使用 Schema 2 和 Delegated Administrator,您仍需要使用某些 Calendar Server 命令行实用程序来执行一些特殊功能。如果确有此必要,本指南中面向任务的文档会告诉您应使用哪些实用程序。
本节提供有关管理新 Calendar Server 用户和资源的以下信息:
您可以使用 Delegated Administrator 控制台或实用程序:
Delegated Administrator 控制台
在 Delegated Administrator 控制台中,使用“创建新用户”向导。(在用户所在组织的“用户列表”页面中,单击“新建”。)有关更多信息,请参见 Delegated Administrator 控制台联机帮助。
Delegated Administrator 实用程序
使用 commadmin 实用程序的 user create 命令。例如,要在 sesta.com 域中添加用户 jdoe,请使用以下命令:
commadmin user create -D calmaster -F John -n sesta.com -k hosted -l jdoe -w calmasterpassword -W jdoepassword -L Doe -S cal -B red.sesta.com -E jdoe@sesta.com
有关 commadmin 实用程序的所有可用选项的详细信息,请参阅《Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide》
使用 csuser 实用程序。例如,要在 sesta.com 域中添加用户 jdoe,请使用以下命令:
csuser -m jdoe@sesta.com -d sesta.com create jdoe
您可以使用 Delegated Administrator 控制台或实用程序:
Delegated Administrator 控制台
在 Delegated Administrator 控制台中,使用“创建新资源”向导。(在资源所在组织的“日历资源”选项卡中,单击“新建”。)有关更多信息,请参见 Delegated Administrator 控制台联机帮助。
Delegated Administrator 实用程序
使用 commadmin 实用程序的 rescource create 命令创建 LDAP 条目。例如,要添加会议室 Conference_Room_100,请使用以下命令:
commadmin resource create -D calmaster -w calmasterpassword -n sesta.com -c room100 -N Conference_Room_100
然后必须使用 csresource 创建实际资源日历。有关如何创建资源日历的信息,请参见创建日历
有关 commadmin 实用程序的所有可用选项的详细信息,请参阅《Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide》
使用 csresource 实用程序创建 LDAP 目录和资源日历。例如,要添加投影仪 p101,请使用以下命令:
csresource -m p101@siroe.com -c p101 create Projector_101
有关 csresource 的更多信息,请参见csresource。
Calendar Server 要求用户和资源拥有 mail 属性,该属性包含用户和资源的电子邮件地址。这使用户可以使用电子邮件地址或 calid 来搜索日历和资源。使用 Delegated Administrator 创建新用户时,它将自动添加 mail 属性。即使未为用户指定 mail 服务,也会自动添加该属性。
Calendar Server 不支持针对资源日历的电子邮件通知。
添加 mail 属性并不启用针对用户日历的电子邮件通知。
要针对用户日历启用电子邮件通知,请将以下两个属性添加到用户的 LDAP 条目中:
icsExtendedUserPrefs:ceNotifyEnable=1 icsExtendedUserPrefs:ceNotifyEmail=jdoe@sesta.com
如果用户和资源是在早期版本的 Calendar Server (无需 mail 属性)中添加的,则可能需要将 mail 属性添加到现有的用户和资源 LDAP 条目中。
本节包含以下主题:
要检查是否设置了该属性,请使用带有 -v(详细)选项的 csattribute list 命令:
csattribute -v list Room100
输出说明了 mail 属性是否存在:
cn=Room 100,ou=conferenceRooms,dc=sesta,dc=com has mail: Room100@sesta.com
要将 mail 属性添加到现有用户和资源,请使用以下方法之一:
使用 Calendar Server csattribute 实用程序。
以下示例为位于 sesta.com 服务器上名为 Room100 的现有会议室添加 LDAP mail 属性:
csattribute -a mail=Room100@sesta.com add Room100
使用 ldapmodify 将该属性直接添加到 LDAP 条目中。
创建用户后,请使用 csuser 实用程序执行以下管理任务:
要列出所有日历用户或显示指定用户的日历属性,请使用 csuser 实用程序的 list 命令。
例如,可使用以下命令显示已启用日历操作功能的所有用户:
csuser list
要显示单个用户(例如 jsmith)的所有日历属性,请使用以下命令:
csuser -v list jsmith
禁用用户的目的是为了阻止用户登录到 Calendar Server。根据创建用户所使用的用户管理工具,禁用用户的处理方法不尽相同。在 Delegated Administrator 控制台中创建的用户,也应使用该控制台进行管理。同样地,如果是使用 Delegated Administrator 实用程序为用户指定了日历服务,也应使用该实用程序删除日历服务。最后,只应使用 Calendar Server 实用程序管理非托管域环境中的用户。每一种情况的处理方法都有所相同。
本节包含以下主题:
Calendar Server 实用程序 (csuser disable) (Calendar Server utilities)
在 Delegated Administrator 控制台中,从“用户列表”页面选择用户。在该用户的“属性”中,删除带有日历服务的服务软件包。该操作将禁止用户访问日历,还会将用户的 icsStatus 设置为 inactive。
如果该软件包还包含其他服务,则必须用不包含日历的另一个软件包重新指定这些服务。
要禁止用户访问日历服务,请从用户的 LDAP 条目删除该服务,如下例所示:
commadmin user delete jsmith -S cal
该命令禁止用户访问日历,但并不完全删除 LDAP 条目。此外,该命令将把用户的 icsStatus 更改为 inactive。
disable 命令将禁止用户访问日历数据,但它并不从 LDAP 条目或 Calendar Server 数据库删除用户信息。该命令将把 icsStatus 属性从 active 更改为 inactive。在非托管域模式中,没有提供日历服务。
例如,可使用以下命令禁止 jsmith 访问 Calendar Server:
csuser disable jsmith
如果 jsmith 当前已经登录 Calendar Server,则在注销之前 jsmith 将一直拥有对日历数据的访问权。
Delegated Administrator (commadmin user create)(适用于 Schema 2)
Calendar Server 实用程序 (csuser enable)(适用于 Schema 1)。
您可以添加新用户和现有用户:
新用户—创建用户时,使用“新建用户”向导为用户指定包含日历服务的服务软件包。将自动启用该用户。
现有用户—从“用户列表”页面选择用户,并使用“指定服务软件包”向导选择具有日历服务的服务软件包。将自动启用该用户。
创建用户时为用户启用日历服务,如以下示例所示:
commadmin user create jsmith -S cal
如果创建用户时没有为其启用日历服务,则可以在以后使用 modify 命令为用户添加日历服务,如以下示例所示:
commadmin user modify jsmith -S cal
如果使用 csuser create 创建了用户条目,则将自动启用该用户。
如果一个用户向另一个未启用日历操作功能的用户(即,该用户没有默认日历)发送请求,Calendar Server 将向发送请求的用户返回错误消息“未找到日历”。
如果需要为日历用户设置电子邮件别名,请将 mailalternateaddress 属性添加到用户的 LDAP 条目中。mail 属性提供了主电子邮件地址,而 mailalternateaddress 属性提供了电子邮件别名。这两个属性都将邮件地址映射到用户的日历 ID (calid)。
您可以使用 Calendar Server 实用程序 csattribute 添加该属性,也可以使用 ldapmodify 直接更新 LDAP。以下示例使用 csattribute。
要启用这些更改,可能还需要重新生成别名表或别名配置。请参阅 Messaging Server(或您的电子邮件产品)的文档,以及您站点上关于更改邮件服务的文档和过程。可在以下位置获得 Messaging Server 文档:http://docs.sun.com/coll/1312.1 和 http://docs.sun.com/coll/1392.1。
例如,要为具有以下值的用户 John Smith 添加 mailalternateaddress 属性:
用户 ID (uid) 和 calid:johnsmith
password:John Smith 的密码
电子邮件地址:john.smith@sesta.com
电子邮件别名:johns@sesta.com 和 jsmith@sesta.com
csattribute -a mailalternateaddress=johns@sesta.com add johnsmith csattribute -a mailalternateaddress=jsmith@sesta.com add johnsmith
要确定某个指定的用户是否在您的目录服务器中以及是否允许该用户访问 Calendar Server 数据,请使用 csuser 实用程序的 check 命令。
例如,可使用以下命令检查是否为 jsmith 启用了日历操作功能:
csuser check jsmith
如果 check 命令显示 LDAP 目录服务器中不存在该用户,则必须为该用户创建目录服务器条目。
根据是从托管域还是非托管域删除用户,使用不同的工具:
没有 undelete 命令。
一旦使用 Delegated Administrator 删除了托管域中的用户,就必须清除这些用户并从头重新添加。清除之前,无法重新使用用户名。
对于非托管域,请参见仅适用于非托管域:取消删除标记为删除但尚未被清除的用户。。
您可以通过任何一个 Delegated Administrator 界面标记要删除的用户,但您不能使用 Delegated Administrator 控制台从 LDAP 清除用户。必须使用 Delegated Administrator 实用程序清除用户。以下任务列出了从 LDAP 删除用户的步骤。完成最后一个步骤之前,不会真正从 LDAP 删除用户。
标记要删除的用户条目。
对于 Delegated Administrator 控制台:从“用户列表”页面中选择要删除的用户,并单击“删除”。
对于 Delegated Administrator 实用程序:使用 commadmin user delete 命令。例如:
commadmin user delete -D chris -n siroe.com -w bolton -l jsmith
两种情况中,用户 LDAP 条目中的 icsStatus 属性都从 active 更改为 deleted。
使用 Calendar Server 实用程序的 csclean 在一个或所有域中删除属于所有已删除用户的所有日历,如下例所示:
csclean clean "*"
或指定实际的域以删除属于该域中所有已删除用户的日历,如下例所示:csclean clean sesta.com
如果在删除用户日历之前,不小心从 LDAP 清除了用户,您可以稍后使用 cscal 实用程序删除日历,如管理用户日历所述。
使用 Delegated Administrator 实用程序命令 commadmin domain purge 清除域中所有标记为删除的用户。
例如:
commadmin domain purge -D chris -d sesta.com -n siroe.com -w bolton
在本示例中,将清除 sesta.com 中标记为已删除的所有用户,也就是永久删除。
请经常手动运行此实用程序以清除 LDAP 目录。有关此命令的更多信息,请参见《Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide》。
使用 Calendar Server 实用程序 csuser 的 delete 命令删除指定用户的 LDAP 条目及其默认日历。
例如,要删除用户 jsmith 的 LDAP 条目和默认日历,请使用以下命令:
csuser delete jsmith
如果您希望删除属于该用户的其他日历,则必须使用 cscal,如管理用户日历所述。
对于非托管域,要取消删除标记为删除但尚未被清除的用户,必须将用户的 icsStatus 属性重置为 active。您可以通过直接更改 LDAP 条目 (使用 ldapmodify)或使用 Calendar Server 实用程序 csattribute 来重置属性。
但是,在非托管域中,一旦用户被清除,您就只能从备份中恢复 LDAP 服务器信息。
要重置指定用户的所有日历 LDAP 属性的默认设置,请使用 csuser 实用程序的 reset 命令。
例如,可以使用以下命令将 jsmith 的所有日历属性重置为默认配置设置:
csuser reset jsmith
在重置日历用户后,将从用户的 LDAP 条目(包括 icsCalendarUser [对象类]、icsSubscribed、icsCalendarOwned、icsCalendar 和 icsDWPHost [如果在 LDAP CLD 设置中])中删除所有日历属性。Calendar Server 管理员将不能再以该用户的名义创建日历。
以下情况将恢复用户的 LDAP 条目中的这些属性:
用户再次登录 Calendar Server,或
Calendar Server 管理员对用户执行了 csuser enable 命令(但这种情况下不会恢复 icsDWPHost 属性)。
如果需要更改一个或多个用户 ID,请运行 csrename 实用程序。此实用程序将执行以下步骤:
转换 Calendar Server LDAP 属性(带有 ics 前缀)中的用户 ID。将对 LDAP 目录进行相应更新。
重命名 Calendar Server 数据库文件中的事件和任务中的用户。新的数据库将被写入到目标目录中。现有数据库文件不受影响。
请注意,即使只更改一个用户 ID,也会导致整个数据库被重写。因此,运行该实用程序要付出很大代价。
有关如何运行 csrename 实用程序的说明,请参见附录 D,Calendar Server 命令行实用程序参考。
以有权更改此配置的管理员身份登录。
转至 /etc/opt/SUNWics5/cal/config 目录。
通过复制和重命名旧的 ics.conf 文件来保存该文件。
编辑下表中所示的 ics.conf 参数:
参数 |
说明和默认值 |
---|---|
service.wcap. allowpublicwritablecalendars |
允许用户拥有可写入的公共日历。默认情况下,已启用(设置为 "yes")此功能。 |
将此文件另存为 ics.conf。
重新启动 Calendar Server。
cal_svr_base/SUNWics5/cal/sbin/start-cal
添加资源后,您可以使用 csresource 来管理这些资源:
转至 sbin 目录。
使用 csresource enable 命令启用一个或多个资源。
例如,可使用以下命令启用 ConfRm12 资源:
./csresource -v enable ConfRm12
转至 sbin 目录。
使用 csresource disable 命令禁用一个或多个资源。例如,可使用以下命令禁用 ConfRm12 资源:
./csresource -v disable ConfRm12
转至 sbin 目录。
使用 csresource delete 命令删除一个或多个资源。例如,可使用以下命令删除 ConfRm12 资源:
./csresource -v delete ConfRm12
本节说明如何为 Messaging Server 和 Sendmail 设置 bitbucket 通道。使用 bitbucket 通道可以删除为资源日历生成的电子邮件。这些示例使用了 sesta.com 服务器上名为 Room100 的资源。如果不设置 bitbucket 通道(或等价机制),则需要定期删除发送至资源日历的电子邮件。
本节包含以下过程:
确保在 imta.cnf 文件中定义了 bitbucket 通道。
要将消息定向至 bitbucket 通道,请使用 csattribute 实用程序为资源创建电子邮件地址:
csattribute -a mail=Room100@bitbucket.sesta.com add Room100 |
在相应主机上的 /etc/aliases 文件中添加如下条目:
Resource/Conference room aliases Room100: /dev/null |
使用 csattribute 实用程序将资源的电子邮件地址添加到 LDAP 目录中:
csattribute -a mail=Room100@sesta.com add Room100 |
使用 csattribute 实用程序或 ldapmodify 管理由 Calendar Server 使用的 LDAP 属性。可以使用 csattribute 列出、添加或删除属性。要修改属性,请使用 ldapmodify。本节包含以下主题:
以安装过程中指定的运行 Calendar Server 的用户或组(例如 icsuser 和 icsgroup)身份登录,或以 root 登录。
转至 sbin 目录。
使用 csattribute list 命令列出用户或资源的属性。例如,要列出 tchang@sesta.com 的属性,可以运行以下命令:
./csattribute -t user -d sesta.com list tchang
以安装过程中指定的运行 Calendar Server 的用户或组(例如 icsuser 和 icsgroup)身份登录,或以 root 登录。
如果要立即识别此属性更改,请停止 Calendar Server。否则,您无需停止 Calendar Server。
转至 sbin 目录。
使用 csattribute add 命令为用户或资源添加属性。例如,要为用户 tchang 添加值为 Conference_Schedule 的 LDAP 属性 icsCalendar,请使用以下命令:
./csattribute -a icsCalendar=Conference_Schedule add tchang@sesta.com
以安装过程中指定的运行 Calendar Server 的用户或组(例如 icsuser 和 icsgroup)身份登录,或以 root 登录。
如果要立即识别此属性更改,请停止 Calendar Server。否则,您无需停止 Calendar Server。
转至 sbin 目录。
使用 csattribute delete 命令删除用户或资源的属性。例如,要删除用户 tchang 的值为 Conference_Schedule 的 LDAP 属性 icsCalendar,请使用以下命令:
./csattribute -a icsCalendar=Conference_Schedule -t user -d sesta.com delete tchang
要修改 LDAP 条目属性,请使用 ldapmodify。例如,要更改 uid=tchang 所对应的用户的状态,请按以下所示使用 ldapmodify 命令:
dn:uid=tchang,ou=people,o=sesta.com changetype: modify add: objectclass objectClass: icsCalendarUser add: icsStatus icsStatus: active |
如果您的站点正在使用 LDAP CLD 插件,请勿尝试使用 csattribute 通过更改 icsDWPHost 的值将用户的日历从一个后端主机移动到另一个后端主机。修改 icsDWPHost 不会将日历移动到新的后端主机。有关如何将日历从一个后端服务器移动到另一个后端服务器的说明,请参见管理用户日历。
本章介绍了如何使用 Calendar Server 命令行实用程序来创建和管理日历,它包含以下主题:
Delegated Administrator 不会创建或管理日历。您必须使用附录 D,Calendar Server 命令行实用程序参考 中介绍的 Calendar Server 实用程序。
在创建日历之前,您必须了解以下信息:
两种日历类型是用户日历和资源日历。
用户日历用于安排用户的活动。资源日历用于安排物品(例如会议室或视频设备)的使用。
两种日历类型均由唯一的日历标识符 (calid) 标识。
使用 cscal 创建用户日历。(或者,您可以允许在登录时进行自动置备。请参见自动创建用户日历。)
使用 csresource 创建资源日历。(没有资源日历的自动置备。)
要运行 cscal 或 csresource,必须以对运行 Calendar Server 的系统具备管理权限的用户身份登录。您必须从 /opt/SUNWics5/cal/sbin 目录运行这些命令。也就是说,必须更改为 sbin 目录;不能通过指定该路径而从其他目录运行这些命令。
Calendar Server 数据库中的每个日历都由一个唯一的日历标识符 (ID) 或 calid 标识。创建日历时,要求指定 calid。
本节包含以下主题:
数据库中的每个日历都由一个唯一的日历 ID (calid) 标识。下面的 calid 语法分成三部分:
userid[@domain][:calendar-name]
这三个部分分别为:
此 Calendar Server 实例中的域的唯一用户 ID。
用户的域的名称。
如果没有托管域,则域这一部分可选,因为用户位于哪个域中是明确的。
如果存在托管域,而又没有指定域这一部分,则 Calendar Server 将使用 ics.conf 参数 service.defaultdomain 中指定的值来指定域。如果用户不在默认的域中,则必须指定域部分。
有关托管域(也称作虚拟域)的更多信息,请参见第 11 章,设置托管域和第 13 章,管理托管域。
特定用户的唯一可选日历名。虽然一个属主只有一个默认日历,但是,出于其他用途,有可能拥有多个日历。每个非默认日历由其日历名称识别。例如,如果用户 John Doe 拥有 uid jdoe,则他的默认日历可能是 jdoe@sesta.com。而他用于记录他所执教的 Little League 队的棒球比赛的附加日历则可能由下面的 calid 标识:jdoe@sesta.com:baseball。
创建 calid 时,请注意以下规则:
日历 ID 区分大小写。例如,JSMITH 与 jsmith 并不相同。(这与电子邮件地址不同,电子邮件地址是不区分大小写的。例如,jsmith@sesta.com 等同于 JSMITH@SESTA.COM。)
日历 ID 不能包含空格并且只能使用以下字符:
如果在拥有托管域之前已创建 calid,并且现在希望将非托管域 calid 转换为托管域 calid,可以使用 csvdmig 实用程序将域部分添加到现有 calid 中。有关如何使用此实用程序的说明,请参见csvdmig。
本节包含以下主题:
用户首次登录时,Calendar Server 将为用户自动创建默认日历。此功能称为自动置备。默认情况下,将启用自动置备功能。但是,自动置备仅可用于用户日历;资源日历必须显式创建。
Calendar Server 将根据用户 ID 为这个新的默认日历创建日历 ID (calid),除非已存在同名的日历。
例如,如果 John Smith 使用用户 ID jsmith 首次登录 Calendar Server,则 Calendar Server 将自动创建以 jsmith 作为 calid 的默认日历。John Smith 随后创建的每个日历的 calid 都将使用 jsmith: 作为日历名称的前缀。例如,如果 John Smith 随后创建了名为 meetings 的新日历,则新日历(在非托管环境中)的 calid 为 jsmith:meetings。
如果将不具有默认日历的用户指定为参与者,则 Calendar Server 将显示错误消息未找到日历。
默认情况下,将启用自动置备。但是,如果要在禁用它以后再次启用它,请执行以下步骤:
以有权更改此配置的管理员身份登录。
转至 /etc/opt/SUNWics5/cal/config 目录。
通过复制和重命名旧的 ics.conf 文件来保存该文件。
在 Calendar Server 配置文件 ics.conf 中编辑下表中所示的一个或多个参数:
参数 |
说明和默认值 |
---|---|
local.autoprovision |
设置为 "yes",则允许在用户首次登录后自动创建默认日历。默认情况下,将启用自动置备。 要禁用此功能,请将该值设置为 "no"。 |
验证是否已为日历启用了用户的 LDAP 条目。
此条目必须包含 icsCalendarUser 对象类。如果尚不存在该对象类,请向用户的 LDAP 条目添加该对象类。
如果站点使用托管域,则用户的域也必须启用日历,自动置备才能正常运行。此域条目必须包含 icsCalendarDomain 对象类。
保存此文件。
重新启动 Calendar Server。
cal_svr_base/SUNWics5/cal/sbin/start-cal
以有权更改此配置的管理员身份登录。
转至 /etc/opt/SUNWics5/cal/config 目录。
通过复制和重命名旧的 ics.conf 文件来保存该文件。
在 Calendar Server 配置文件 ics.conf 中编辑下表中所示的一个或多个参数:
参数 |
说明和默认值 |
---|---|
local.autoprovision |
将该参数设置为 no 将禁用用户日历的自动置备。 |
保存此文件。
重新启动 Calendar Server。
cal_svr_base/SUNWics5/cal/sbin/start-cal
如果禁用了自动置备,则必须为用户明确创建日历,用户才能成功登录。
Calendar Server 使用存取控制表 (Access Control List, ACL) 来确定日历、日历属性和日历组件(例如事件和待办事件 [任务])的访问控制。
本节包含以下主题:
下表介绍了 ics.conf 文件中 Calendar Server 用于访问控制的配置参数。
表 15–1 访问控制的配置参数
参数 |
说明 |
---|---|
指定用户创建日历时使用的默认访问控制设置。默认值为: "@@o^a^r^g;@@o^c^wdeic^g; @^a^fs^g;@^c^^g;@^p^r^g" |
|
指定日历属主的默认访问控制设置。默认值为: "@@o^a^rsf^g;@@o^c^wdeic^g" |
|
指定创建资源日历时使用的默认访问控制设置。默认值为: "@@o^a^r^g;@@o^c^wdeic^g; @^a^rsf^g" |
创建新事件或任务时,用户可以指定该事件或任务是“公用”、“私人”还是“仅时间与日期(保密)”:
对用户的日历拥有读取权限的任一用户均可以查看事件或任务。
仅日历属主可以查看事件或任务。
这些是保密事件和任务。日历属主可以查看事件或任务。拥有日历读取权限的其他用户只能查看日历中“未命名的事件”,而且此标题不是一个活动链接。
calstore.filterprivateevents 确定 Calendar Server 是否过滤(识别)“私人”和“仅时间与日期(保密)”事件和任务。默认情况下,此参数设置为 "yes"。如果将 calstore.filterprivateevents 设置为 "no",那么 Calendar Server 将按处理“公用”事件和任务的方式处理“私人”及“仅时间与日期”事件和任务。
下表介绍了 Calendar Server 命令行实用程序,它们允许您设置或修改访问控制的 ACL:
表 15–2 访问控制的命令行实用程序
实用程序 |
说明 |
---|---|
使用带有 -a 选项的 create 和 modify 命令为特定的用户日历或资源日历设置 ACL。 |
|
如果正在使用 csresource 创建资源日历(在 Schema 1 模式下运行),请使用带有 -a 选项的 csresource 实用程序来设置资源日历的 ACL。 |
|
csuser |
使用 Schema 2 commadmin 实用程序更改用户创建日历时使用的默认 ACL。 使用带 -a 选项的 Schema 1 csuser 实用程序更改用户创建日历时使用的默认 ACL。 |
要在 Delegated Administrator 控制台中从“组织属性”页(或从“新建组织”向导)设置访问权限,请单击“高级权限”按钮查看可通过控制台管理的访问权限列表。
本节包含以下主题:
要创建新日历,请使用 cscal 实用程序的 create 命令。LDAP 目录中必须已经存在用户条目或资源条目。有关向 LDAP 目录添加用户和资源的信息,请参阅第 14 章,管理用户和资源。
如果您的站点使用的是 LDAP 日历查找数据库 (Calendar Lookup Database, CLD) 插件,则必须按照用户条目或资源条目中的 icsDWPHost LDAP 属性中的指定,在同一后端服务器上为特定用户或资源创建所有日历。如果试图在不同的后端服务器上创建日历,cscal 实用程序将返回一条错误消息。有关 LDAP CLD 插件的信息,请参见第 6 章,在多个计算机上配置日历数据库分发。
例如,可使用以下命令创建日历 ID (calid) 为 jsmith 的新日历:
cscal -o jsmith -n JohnSmithCalendar create jsmith
其中:
-o jsmith 指定新日历的主要属主。
-n JohnSmithCalendar 指定新日历的可见名称。
默认访问控制设置由 ics.conf 文件中的 calstore.calendar.default.acl 定义。
要创建属主为 John Smith,可见名称为 Hobbies,并且使用默认访问控制设置进行组计划的日历,请使用以下命令:
cscal -n Hobbies -o jsmith create Personal
其中:
-n Hobbies 指定日历的可见名称。
-o jsmith 指定主要属主的用户 ID。
Personal 用作日历 ID (calid) 的第二部分。例如:jsmith:Personal
以下示例将创建与上一个示例类似的新日历,但它还将日历与名为 sports 的类别关联,同时还启用了双重预订,并指定 Ron Jones 作为另一个属主:
cscal -n Hobbies -o jsmith -g sports -k yes -y rjones create Personal
其中:
-g sports 将日历与名为 sports 的类别相关联。
-y rjones 指定日历的另一个属主。
-k yes 启用双重预订。(-k no 将禁用双重预订。)
以下示例创建了与上一个示例类似的日历,但它还为组计划设置了特定的访问控制设置值:
cscal -n Hobbies -o jsmith -a "@@o^a^sfr^g" create Personal
其中,-a "@@o^a^sfr^g" 为其他属主授予对该日历的组件和日历属性的预定、空闲/繁忙和读取访问权限,以便进行组计划。
资源日历与可以预定的事物关联,例如,会议室、笔记本计算机、顶置光源投影机以及其他设备。资源日历需要访问控制列表。
如表 15–3 所示,ics.conf 文件中的两个配置参数适用于资源日历:
resource.default.acl—默认存取控制表。
resource.allow.doublebook—允许或不允许双重预订的参数。
有时可能需要双重预订用户日历,而可能不希望双重预订资源,因此默认值为 "no"。但是,如有需要,可以将其更改为 "yes"。
要更改这些参数(如表 15–3 中所示)的默认值,请编辑 ics.conf 文件。对默认值所做的更改只能应用到新的资源日历,而不能更改现有资源日历的值。
对于 Schema 1,使用 Calendar Server 实用程序 cscal 更改现有资源日历的值。csresource 实用程序没有 modify 命令。
对于 Schema 2,使用 Delegated Administrator 实用程序的 commadmin resource modify 命令。Delegated Administrator 控制台不允许您更改日历资源的这些值。
Calendar Server 通知软件不会向资源发送通知,而是仅向用户发送通知。
参数 |
说明和默认值 |
---|---|
resource.default.acl |
此参数决定创建资源日历时使用的默认访问控制权限。默认权限由以下访问控制列表 (ACL) 指定: "@@o^a^r^g;@@o^c^wdeic^g;@^a^rsf^g" 此 ACL 将授予所有日历用户读取、调度和空闲/繁忙访问该日历(包括组件和属性)的权限。 要更改资源的权限,请在使用 csresource 实用程序的 create 命令创建日历时使用 -a 选项。 |
resource.allow.doublebook |
此参数决定资源日历是否允许双重预订。双重预订允许资源日历同时具有多个预定的事件。 默认值为 "no"—不允许双重预订。 要启用资源日历的双重预订功能,请在使用 csresource 实用程序的 create 命令创建日历时使用 -k 选项。 |
Calendar Server 没有资源日历的自动置备功能。对于您的站点需要的每个资源,必须使用以下方法:
对于 Schema 1,使用 Calendar Server 实用程序的 csresource create 命令。
此实用程序创建了资源的 LDAP 条目和默认日历。
例如,可以使用以下命令创建日历 ID 为 aud100、可见名称为 Auditorium(LDAP cn 属性)且具有默认设置的资源 LDAP 条目和日历:
csresource -m aud100@siroe.com -c aud100 create Auditorium
对于 Schema 2,使用 Delegated Administrator 实用程序的 commadmin resource create 命令创建 LDAP 条目。然后,使用 Calendar Server 实用程序的 csresource create 命令创建默认日历。
对于 Schema 2,使用 Delegated Administration 控制台创建资源 LDAP 条目。然后,使用 Calendar Server 实用程序的 csresource create 命令创建默认日历。
要使用控制台创建 LDAP 资源,请从“组织列表”选择此资源将驻留的组织。从此组织的“日历资源”页,单击“新建”以显示“新建日历资源向导”。
如果已存在该资源的 LDAP 条目,csresource 将仅创建日历。而不会创建重复的 LDAP 条目。
有关 Delegated Administrator 实用程序的更多信息,请参见《Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide》。
有关 Delegated Administrator 控制台的更多信息,请参见联机帮助。
有关 csresource 的更多信息,请参见附录 D,Calendar Server 命令行实用程序参考。
默认情况下,Calendar Server 不允许对资源日历进行双重预订(resource.allow.doublebook 参数)。此默认值用于防止资源(例如房间和设备)的预定冲突。但是,如果您要允许对资源日历进行双重预订,可以在创建日历时将 csresource -k 选项设置为 "yes"。
以下命令创建了资源 LDAP 条目和日历,但 -k 选项允许对日历进行双重预订,-o 选项指定 bkamdar 作为日历的属主,而 -y 选项指定 jsmith 作为另一个属主:
csresource -m aud100@siroe.com -c aud100 -k yes -o bkamdar -y jsmith create Auditorium
要控制可以预定特定资源的人员,请考虑限制对资源日历具有写入权限的用户。例如,您可能只希望几个特定用户预定会议室或设备。
如果不为资源日历指定属主,其值将由 ics.conf 文件中的 service.admin.calmaster.userid 参数指定。
创建用户日历后,请使用cscal实用程序执行以下管理任务:
要显示所有日历、某个用户拥有的所有日历或特定日历的属性,请使用 cscal 实用程序的 list 命令。
例如,可使用以下命令列出日历数据库中的所有日历:
cscal list
可使用以下命令列出 jsmith 拥有的所有日历:
cscal -o jsmith list
可使用以下命令列出日历 ID 为 jsmith:meetings 的日历的所有属性:
cscal -v list jsmith:meetings
要从 Calendar Server 中删除一个或多个日历,请使用 cscal 实用程序的 delete 命令。此实用程序将删除日历,但并不会从 Directory Server 中删除用户。
delete 命令将从日历数据库中删除所有日历信息,并且不能撤消。删除日历后,只有在已经对日历数据进行了备份的情况下才能恢复它。有关更多信息,请参见第 17 章,备份和恢复 Calendar Server 数据。
可以使用 cscal 实用程序删除一个或多个日历。
例如,可使用以下命令删除日历 ID 为 jsmith:meetings 的特定日历:
cscal delete jsmith:meetings
可使用以下命令删除主要属主为 jsmith 的所有日历:
cscal -o jsmith delete
如果您已使用 Calendar Server 实用程序的 csuser delete 命令,或者 Delegated Administrator 控制台或实用程序删除了一个或多个用户,那些用户所拥有的日历将可能仍存在于数据库中。
可以用两种方法来删除用户的日历。要使用的方法取决于删除用户所使用的工具:
csuser 实用程序用于删除 LDAP 目录下的用户及该用户的默认日历,但不会删除该用户可能拥有的其他任何日历。有关如何使用 cscal 来删除这些日历的说明,请参见删除使用 csuser 删除的用户的所有日历。
Delegated Administrator 不会删除任何日历。使用 Delegated Administrator 将用户标记为已删除,然后使用 Calendar Server 实用程序 csclean 删除标记为已删除的用户的所有日历。
有关如何使用 csclean 来删除已删除的用户的日历的说明,请参见删除使用 Delegated Administrator 删除的用户的所有日历。
有关使用 Delegated Administrator 实用程序的说明,请参见《Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide》。
有关使用 Delegated Administrator 控制台的说明,请参见联机帮助。
运行 cscal list 来查找已删除的属主 uid 的所有日历。
cscal -o owner list
使用 cscal 来删除此属主的所有日历。
cscal -o owner delete
通过再次运行 csuser list 来验证是否已删除所有日历。
如果您已使用 commadmin 将用户标记为已删除,并且该用户的 LDAP 条目已被清除,则使用此过程。
Delegated Administrator 不会删除日历。此 csclean 实用程序用于删除已使用 Delegated Administrator 标记为已删除的任何用户的所有日历。
csclean 用于删除标记为已删除但尚未被清除的用户的所有日历。
例如,要删除最近 10 天 sesta.com 域中标记为已删除的用户的所有日历,则应执行如下命令:
csclean -g 10 clean sesta.com
如果用户已从 LDAP 中清除,那么您必须使用 cscal。
有关说明,请参见删除使用 csuser 删除的用户的所有日历。
要启用日历以允许用户访问该日历,请使用 cscal 实用程序的 enable 命令。
例如,可使用以下命令来使用默认配置设置启用日历 jsmith:meetings:
cscal enable jsmith:meetings
可使用以下命令启用日历 jsmith:meetings,但不允许双重预订:
cscal -k no enable jsmith:meetings
要禁止用户访问日历,请使用 cscal 实用程序的 disable 命令。disable 命令将禁止用户访问日历,但并不会从日历数据库中删除信息。
例如,可使用以下命令禁止用户访问 jsmith:meetings:
cscal disable jsmith:meetings
要修改日历属性,请使用 cscal 实用程序的 modify 命令。
例如,可使用以下命令更改 AllAdmins 的组计划访问控制设置,并指定 RJones 作为另一个属主:
cscal -a "@@o^c^wd^g" -y RJones modify AllAdmins
其中:
-a "@@o^c^wd^g" 将授予属主对 AllAdmins 组件(事件和任务)的写入和删除权限。
-y RJones 指定此用户 ID 作为另一个属主。
要从日历中删除属性值,请使用 cscal 实用程序的 modify 命令,并用两个双引号 ("") 指定选项的值。
例如,可使用以下命令从 jsmith:meetings 中删除说明:
cscal -d "" modify jsmith:meetings
可使用以下命令从 jsmith:meetings 中删除所有类别:
cscal -g "" modify jsmith:meetings
可使用以下命令从 jsmith:meetings 中删除“其他属主”:
cscal -y "" modify jsmith:meetings
如果用户的默认日历未出现在 Communications Express“当前日历”下拉式列表中,但仍存在于数据库中,则可以通过更新用户 LDAP 条目中的以下属性来恢复该日历:
icsCalendar:default_calid
icsSubscribed:default_calid
其中,default_calid 为用户的默认日历 ID (calid)。
对于 Schema 2,使用以下方法之一更新属性:
使用 ldapmodify Directory Server 实用程序。
使用 Calendar Server 实用程序的 csuser reset 命令。
使用 Delegated Administrator 实用程序的 commadmin user modify 命令。
使用 Delegated Administrator 控制台通过编辑“用户属性”页添加默认日历名。
对于 Schema 1,使用 csattribute add 命令更新属性。
要将用户日历从一个后端服务器移至其他后端服务器,请执行以下操作:
在原始服务器上,使用csuser实用程序禁用日历用户。例如,禁用用户 ID 和 calid 为 bkamdar 的用户:
csuser disable bkamdar |
在原始服务器上,使用csexport实用程序将用户的每个日历从日历数据库导出到某个文件中。例如:
csexport -c bkamdar calendar bkamdar.ics |
将导出的日历文件 (*.ics) 从原始服务器复制到新服务器上。
在新服务器上,针对已导出的每个日历,使用csimport实用程序将日历从此文件导入到日历数据库中。例如:
csimport -c bkamdar calendar bkamdar.ics |
在 LDAP Directory Server 上,使用csattribute实用程序更新日历属主的 icsDWPHost LDAP 属性,以指向新的后端服务器。要更新属性,必须先删除该属性,然后再添加它并为其指定新值。例如,要将新服务器名设置为 sesta.com:
csattribute -a icsDWPHost delete bkamdar csattribute -a icsDWPHost=sesta.com add bkamdar |
在新服务器上,使用csuser实用程序启用用户日历的日历用户。例如:
csuser enable bkamdar |
在新服务器上,使用以下命令验证这些属性是否正确以及是否已正确移动了每个日历。例如:
cscal -v -o bkamdar list bkamdar ... csattribute -v list bkamdar |
在原始服务器上,删除刚刚移动的每个日历。例如:
cscal -o bkamdar delete bkamdar |
-o 选项将删除主要属主为 bkamdar 的所有日历。
如果您要在将日历移至不同的后端服务器之后使用 CLD 高速缓存选项,则应清除 CLD 高速缓存以删除该服务器名称。CLD 高速缓存中的过期条目可以阻止前端服务器在日历被移动后查找此日历。要清除 CLD 高速缓存,请执行以下操作:
停止 Calendar Server。
删除 /var/opt/SUNWics5/csdb/cld_cache 目录中的所有文件,但不要删除 cld_cache 目录本身。
重新启动 Calendar Server。
创建了资源日历后,使用 csresource 实用程序来对其进行管理。以下是管理资源日历所需的过程:
要显示资源日历,请使用 csresource 实用程序的 list 命令。
例如,可使用以下命令显示所有 Calendar Server 资源日历及其对应的 LDAP 属性的列表:
csresource list
可使用以下命令显示名为 Auditorium 的特定资源日历的所有 LDAP 属性的列表:
csresource -v list Auditorium
要修改资源日历,请使用cscal实用程序的 modify 命令(csresource 没有 modify 命令)。
例如,可使用以下命令为名为 Auditorium 的资源日历设置一个名为 tchang 的属主并为其添加另一个名为 mwong 的属主:
cscal -o tchang -y mwong modify aud100
在本例中,cscal 实用程序需要 calid (aud100),而不是日历名称 (Auditorium)。
您可能希望禁用资源日历,以防止用户预定事件。例如,会议室可能因为装修而无法使用,或顶置光源投影仪已送修。
要禁用或启用资源日历,请使用 csresource 实用程序的 enable 或 disable 命令。
例如,可使用以下命令禁用名为 Auditorium 的资源日历:
csresource disable Auditorium
然后,可使用以下命令启用资源日历:
csresource enable Auditorium
要删除资源日历,请使用 csresource 实用程序的 delete 命令。
例如,可使用以下命令删除名为 Auditorium 的资源日历:
csresource delete Auditorium
Calendar Server 将显示以下消息:
Do you really want to delete this resource (y/n)?
输入 "y" 删除日历或输入 "n" 取消操作。
如果输入 "y",Calendar Server 将删除日历并显示一条表明日历已被删除的消息。
要将用户或资源日历从一个后端服务器移至其他后端服务器,请执行以下操作:
在原始服务器上,使用csresource实用程序禁用日历资源。例如,禁用具有公用名称 Auditorium 的资源:
csresource disable Auditorium |
在原始服务器上,使用csexport实用程序将资源的每个日历从日历数据库导出到某个文件中。例如:
csexport -c aud100 calendar aud100.ics |
将导出的日历文件 (*.ics) 从原始服务器复制到新服务器上。
在新服务器上,针对已导出的每个日历,使用csimport实用程序将此文件中的这些日历导入到日历数据库中。例如:
csimport -c bkamdar calendar bkamdar.ics |
在 LDAP Directory Server 上,使用csattribute实用程序更新日历属主的 icsDWPHost LDAP 属性,以指向新的后端服务器。要更新属性,必须先删除该属性,然后再添加它并为其指定新值。例如,要将新服务器名设置为 sesta.com:
csattribute -a icsDWPHost delete bkamdar csattribute -a icsDWPHost=sesta.com add bkamdar |
在新服务器上,使用csresource实用程序启用日历资源。例如:
csresource enable bkamdar |
在新服务器上,使用以下命令验证这些属性是否正确以及是否已正确移动了每个日历。例如:
cscal -v -o bkamdar list bkamdar csattribute -v list bkamdar |
在原始服务器上,删除刚刚移动的每个日历。例如:
cscal -o bkamdar delete bkamdar |
-o 选项将删除主要属主为 bkamdar 的所有日历。
如果您要使用 CLD 高速缓存选项并且已将日历移至不同的后端服务器,则应清除 CLD 高速缓存以删除该服务器名称。CLD 高速缓存中的过期条目可以阻止前端服务器在日历被移动后查找此日历。要清除 CLD 高速缓存,请执行以下操作:
停止 Calendar Server。
删除 /var/opt/SUNWics5/csdb/cld_cache 目录中的所有文件,但不要删除 cld_cache 目录本身。
重新启动 Calendar Server。
可以创建一个或多个用户日历或资源日历的链接,只要每个日历设置了允许读取访问的权限。例如,可以在 Web 页或电子邮件消息中嵌入日历链接。然后,其他用户就可以匿名查看该日历而无需登录 Calendar Server。
http://CommunicationsExpresshostname: CommunicationsExpressport/uwc/ ?calid=calid-1[; ... ;calid-n]
对于多个日历,请使用半角分号 (;) 分隔每个日历 ID (calid)。
例如,要链接到 jsmith@sesta.com 和 jdoe@siroe.com 的默认日历,请输入:
http://calendar.sesta.com:8080/?calid=jsmith@sesta;jdoe@siroe.com
要链接 calid 为 overhead_projector10 的顶置光源投影仪的资源日历,请输入:
http://calendar.sesta.com:8080/uwc/?calid=overhead_projector10
要将日历数据导出到文件中,或从文件中导入日历数据,请使用 csexport 和 csimport 实用程序。日历数据可以是 iCalendar (.ics) 或 XML (.xml) 格式。
必须在已安装 Calendar Server 的本地计算机上运行 csexport 和 csimport。Calendar Server 可以正在运行或已经停止。
要从以前使用 csexport 实用程序保存的文件中导入日历数据,请使用 csimport。导入文件的文件扩展名(.ics 或 .xml)表明了文件的保存格式。
例如,可使用以下命令从以 iCalendar (text/calendar MIME) 格式保存的文件 jsmith.ics 中将日历数据导入到日历 ID (calid) 为 jsmithcal 的日历中:
csimport -c jsmithcal calendar jsmith.ics
可使用以下命令从以 XML (text/xml MIME) 格式保存的文件 jsmith.xml 中将数据导入到日历 jsmithcal 中:
csimport -c jsmithcal calendar jsmith.xml
要将日历数据导出到文件中,请使用 csexport。为输出文件指定的文件扩展名(.ics 或 .xml)决定了使用的格式。
例如,可使用以下命令以 iCalendar (text/calendar MIME) 格式将日历 ID (calid) 为 jsmithcal 的日历导出到名为 jsmith.ics 的文件中:
csexport -c jsmithcal calendar jsmith.ics
可使用以下命令以 XML (text/xml MIME) 格式将日历 jsmithcal 导出到名为 jsmith.xml 的文件中:
csexport -c jsmithcal calendar jsmith.xml
Calendar Server 在多个目录中保留多个数据库文件。您必须实施第 10 章,配置自动备份 (csstored)中所述的自动备份过程或者亲自实施系统备份来保护数据库文件。可以使用 csdb 实用程序来管理数据库文件。
本章介绍了如何使用 csdb 管理 Calendar Server 数据库,并包含以下各节:
要管理数据库文件,请使用 Calendar Server 实用程序 csdb。本节包含以下主题:
日历数据库实用程序 csdb 将数据库文件视为以下三种逻辑数据库:
caldb 由数据库目录中的所有 .db 文件和 _db.* 文件组成。日历数据库文件(以及 cld_cache 和 ldap_cache 子目录)的默认位置如下:
/var/opt/SUNWics5/csdb
如果需要,您可以在运行 Calendar Server 配置程序 (csconfigurator.sh) 时指定其他目录。有关配置程序的信息,请参阅第 3 章,Calendar Server 配置程序 (csconfigurator.sh)
下表介绍了日历数据库 (caldb) 文件:
表 16–1 Calendar Server 数据库文件
文件 |
说明 |
---|---|
ics50calprops.db |
所有日历的日历属性。包括日历 ID (calid)、日历名称、访问控制列表 (Access Control List, ACL) 和属主。 |
ics50events.db |
所有日历的事件。 |
ics50todos.db |
所有日历的待办事件(任务)。 |
ics50alarms.db |
所有事件和待办事件(任务)的警报。 |
ics50gse.db |
组计划引擎 (GSE) 的计划请求队列。 |
ics50journals.db |
日历的日志。当前发行版中尚未实现日志功能。 |
ics50caldb.conf |
数据库版本标识符。 |
ics50recurring.db |
重复性事件。 |
ics50deletelog.db |
已删除的事件和待办事件(任务)。另请参见第 18 章,管理“删除日志”数据库 |
会话数据库由以下目录中的所有文件组成:/opt/SUNWics5/cal/lib/admin/session/ 和 /opt/SUNWics5/cal/lib/http/session/
统计信息数据库由 counter 目录中的所有文件组成:
/opt/SUNWics5/cal/lib/counter/
-t caldb—日历数据库
-t sessdb—会话数据库
-t statdb—统计数据库
如果没有使用 -t 选项,则在 csdb 实用程序中除了使用 check 和 rebuild 两个命令仅对日历数据库执行操作外,使用其他命令均将对所有三个数据库执行操作。
本节介绍了如何使用 csdb 实用程序执行以下管理任务:
要运行 csdb 实用程序,必须以具备管理权限的用户身份登录正在运行 Calendar Server 的系统。有关更多信息,请参见附录 D,Calendar Server 命令行实用程序参考。
要查看数据库组(caldb、sessdb 和 statdb)的状态,请使用 csdb 实用程序的 list 命令。
要列出数据库的状态,请执行以下步骤:
以具备管理权限的用户身份登录安装了 Calendar Server 的系统。
Calendar Server 可以正在运行或已经停止,但最好停止 Calendar Server。
转至 /sbin 目录。例如,在 Solaris 操作系统上输入以下内容:
cd /opt/SUNWics5/cal/sbin |
针对一个或所有数据库组运行 list 命令。例如,列出所有三种数据库组的状态和统计信息:
./csdb list
以下代码显示了样例输出:
Sleepycat Software: Berkeley DB 4.1.25: (December 19, 2002) Calendar database version: 3.0.0 [BerkeleyDB] Total database size in bytes: 57344 Session database version: 1.0.0 [BerkeleyDB] Total database size in bytes: 0 Counter database version: 1.0.0 [Memory Mapped Files] Total database size in bytes: 118792 |
您也可以选择使用详细模式。例如:
./csdb -v list
以下样例代码显示了详细输出:
Sleepycat Software: Berkeley DB 4.1.25: (December 19, 2002) Calendar database version: 3.0.0 [BerkeleyDB] Total database size in bytes: 57344 Total number of calendars: 2 Total number of events: 0 Total number of tasks: 0 Total number of alarms: 0 Total number of gse entries: 0 Total number of master component entries: 0 Total number of deletelog entries: 0 Total logfile size in bytes: 5779919 Session database version: 1.0.0 [BerkeleyDB] Total database size in bytes: 0 Total logfile size in bytes: 0 Counter database version: 1.0.0 [Memory Mapped Files] Total database size in bytes: 118792 |
或者,使用 -t 选项来指定一个目标数据库组(caldb、sessdb 或 statdb)。例如,只查看日历数据库的数据库状态和统计信息:
csdb -t caldb list
使用 check 命令可以扫描日历数据库(包括日历属性 [calprops] 和事件及待办事件 [任务])中的损坏。如果使用 check 命令发现无法解决的冲突,则将在输出结果中报告该情况。
check 命令不检查警报或组调度引擎 (Group Scheduling Engine, GSE) 数据库中的损坏。
要检查数据库的损坏,请执行以下步骤:
以具备管理权限的用户身份登录安装了 Calendar Server 的系统。
Calendar Server 可以正在运行或已经停止,但最好停止 Calendar Server。
如果尚未备份,请备份日历数据库。只需复制数据库 (.db) 文件。无需复制任何共享 (__db.*) 文件或日志 (log.*) 文件。
转至 cal_svr_base/SUNWics5/cal/sbin 目录。例如,在 Solaris 操作系统上输入以下内容:
cd /opt/SUNWics5/cal/sbin |
针对日历数据库副本运行 check 命令:
./csdb check dbdir \> /tmp/check.out 2\>&1 |
如果未指定 dbdir,则 check 命令将针对当前目录中的数据库。
check 命令会生成许多信息,因此请考虑将所有输出结果(包括 stdout 和 stderr)重定向到一个文件中(如示例中所示)。
运行完 check 命令后,查看输出文件。
如果数据库遭受损坏,则可以选择用热备份副本进行替换。另外,您可以选择通过运行 rebuild 命令来尝试重新建立已损坏的数据库。
要恢复已损坏的日历数据库 (caldb),请使用 csdb 实用程序的 rebuild 命令。rebuild 命令将扫描所有日历数据库以查看其中是否存在损坏。如果 rebuild 命令发现冲突,它将在 cal_svr_base/SUNWics5/cal/sbin/rebuild_db 目录中重新建立一个日历数据库(.db 文件)。
rebuild 命令会生成许多信息,因此请考虑将所有输出结果(包括 stdout 和 stderr)重定向到一个文件中。
在以下说明中,rebuild 命令不会重新建立组调度引擎 (Group Scheduling Engine, GSE) 数据库。
要重新建立不包括 GSE 数据库的日历数据库,请执行以下步骤:
以具备管理权限的用户身份登录安装了 Calendar Server 的系统。
停止 Calendar Server。
如果尚未备份,请备份日历数据库。只需复制数据库 (.db) 文件和日志 (log.*) 文件。无需复制任何共享 (__db.*) 文件。
转至 cal_svr_base/SUNWics5/cal/sbin 目录。例如,在 Solaris 操作系统上输入以下内容:
cd /opt/SUNWics5/cal/sbin |
如果 sbin 目录的磁盘空间不足,请在其他目录中运行 rebuild 命令。
针对日历数据库副本运行 rebuild 命令:
./csdb rebuild /tmp/db /tmp/ |
如果未指定数据库目录,则 rebuild 命令将针对当前目录中的数据库。在上述示例中,/tmp/ 参数用于指定重新建立的数据库所在的目标目录。
请始终使用最新的备份副本重建日历数据库。
但是,如果曾丢失大量数据,同时由于定期备份数据库而创建了多个副本,请从最新副本向最旧副本进行重建。(这样做的唯一缺点是已删除的日历组件将重新出现在重建数据库中。)
例如,如果目录 db_0601、db_0615 和 db_0629 中分别有三组备份日历数据库文件,请按以下顺序运行 rebuild 命令:
./csdb rebuild db_0629
然后检查是否存在损坏。如果该备份副本已被损坏,则针对下一个备份副本运行 rebuild。
./csdb rebuild db_0615
然后检查是否存在损坏。如果该备份副本已被损坏,则针对下一个备份副本运行 rebuild。
./csdb rebuild db_0601
... 等等。
rebuild 命令将重新建立的数据库写入 cal_svr_base/SUNWics5/cal/sbin/rebuild_db 目录。
运行完 rebuild 命令后,查看rebuild.out 文件中的输出结果。如果重新建立成功,rebuild.out 文件中的最后一行应如下所示:
Calendar database has been rebuilt |
验证 rebuild 成功后,将重新建立的数据库 (.db) 文件从 rebuild_db 目录复制到您的生产数据库中。
如果从损坏的数据库中恢复了任何共享 (__db.*) 文件,请将它们移到其他目录中。
重新启动 Calendar Server。
如果您已在您的站点中实现了组计划,则应在重新建立日历数据库时包括 GSE 数据库。
要重新建立日历数据库和 GSE 数据库,请执行以下步骤:
通过运行 csschedule -v list 命令确定 GSE 数据库是否具有任何条目,如果有,则让 GSE 处理完这些条目。
以具备管理权限的用户身份登录安装了 Calendar Server 的系统。
停止 Calendar Server。
如果尚未备份,请备份日历数据库。
只需复制数据库 (.db) 文件和日志 (log.*) 文件。无需复制任何共享 (__db.*) 文件。
转至 cal_svr_base/SUNWics5/cal/sbin 目录。
例如,在 Solaris 操作系统上输入以下内容:
cd /opt/SUNWics5/cal/sbin
如果 sbin 目录的磁盘空间不足,请在其他目录中运行 rebuild 命令。
针对日历数据库副本运行 rebuild 命令:
./csdb -g rebuild /tmp/db /tmp/
如果未指定数据库目录,则 rebuild 命令将针对当前目录中的数据库。在上述示例中,/tmp/ 参数用于指定重新建立的数据库所在的目标目录。
请始终使用最新的备份副本重建日历数据库。
但是,如果曾丢失大量数据,同时由于定期备份数据库而创建了多个副本,请从最新副本向最旧副本进行重建。(这样做的唯一缺点是已删除的日历组件将重新出现在重建数据库中。)
例如,如果目录 db_0601、db_0615 和 db_0629 中分别有三组备份日历数据库文件,请按以下顺序运行 rebuild 命令:
./csdb rebuild db_0629 ./csdb rebuild db_0615 ./csdb rebuild db_0601 |
rebuild 命令然后会将重新建立的数据库写入 cal_svr_base/SUNWics5/cal/sbin/rebuild_db 目录。
运行完 rebuild 命令后,查看rebuild.out 文件中的输出结果。
如果重新建立成功,rebuild.out 文件中的最后一行应如下所示:
Calendar database has been rebuilt |
验证 rebuild 成功后,将重新建立的数据库 (.db) 文件从 rebuild_db 目录复制到您的生产数据库中。
如果从损坏的数据库中恢复了任何共享 (__db.*) 文件,请将它们移到其他目录中。
重新启动 Calendar Server。
通过以下输出结果样例可以看到事件和待办事件数据库均被扫描了两次。这不是错误。首次扫描是为了验证 calprops 数据库中的信息,再次扫描是为了确保可以从日历数据库访问 calprops。
以下示例显示了此命令及其生成的输出:
# ./csdb -g rebuild Building calprops based on component information. Please be patient, this may take a while... Scanning events database... 512 events scanned Scanning todos database... 34 todos scanned Scanning events database... 512 events scanned Scanning todos database... 34 todos scanned Scanning deletelog database... 15 deletelog entries scanned Scanning gse database... 21 gse entries scanned Scanning recurring database... 12 recurring entries scanned Successful components db scan Calendar database has been rebuilt Building components based on calprops information. Please be patient, this may take a while... Scanning calprops database to uncover events... 25 calendars scanned Scanning calprops database to uncover todos... 25 calendars scanned Successful calprops db scan Calendar database has been rebuilt |
要删除日历数据库,请使用 csdb 实用程序的 delete 命令。必须停止 Calendar Server。
请使用 -t 选项指定目标数据库(caldb、sessdb 或 statdb);否则,csdb 将删除所有三个数据库。
例如,可使用以下命令删除日历数据库:
csdb -t caldb delete
删除数据库之前,csdb 实用程序将发出警告。
如果您已选择不使用由 Calendar Server 所提供的自动备份工具(使用 csstored),那么您需要执行备份过程以保护数据。本章介绍了如何使用 Calendar Server 和其他 Sun 工具来执行对日历数据库文件的手动备份和恢复。
要备份和恢复 /var/opt/SUNWics5/csdb 目录中的 Calendar Server 数据,请使用以下命令行实用程序:
csbackup,用于备份日历数据库、特定日历或用户的默认日历。要备份的目录必须由运行时用户 (icsuser) 所拥有,否则当您尝试恢复数据时,将会收到一条错误消息。
csrestore,用于恢复使用 csbackup 保存的日历数据库、单个日历或用户的默认日历。
如果您具有使用 Berkeley 数据库工具(例如 db_recover)的现有自定义脚本,则您会发现在升级到 Calendar Server 6 后,这些工具将无法工作。在 Calendar Server 2004Q4 之前,使用静态库对这些工具进行编译。从该版本起,使用动态库对这些工具进行编译。
要适应此更改,请按以下方式更改自定义脚本以便使用动态链接库:将全局变量 LD_LIBRARY_PATH 设置为动态库的名称 (libdb-4.2.so)。
本章包括以下各节:
Calendar Server 2 数据与当前产品不兼容。请不要尝试恢复使用 Calendar Server 2 backup 实用程序备份的日历数据,否则可能会导致数据丢失。
如果您有要移动到当前版本的 Calendar Server 2 日历数据,则您必须与技术支持部门联系以获取相应的迁移实用程序。
csbackup 实用程序可以备份日历数据库、指定日历或用户的默认日历。本节包括以下内容:
以数据库文件属主的身份登录(例如 icsuser)。
使用 csbackup 实用程序的 database 命令。
例如,可使用以下命令将日历数据库备份到名为 backupdir 的目录中:
csbackup -f database backupdir |
通过检查备份目录中的 ics50caldb.conf 版本文件验证是否已备份数据库的正确版本。
如果目标备份目录已经存在而您没有指定 -f 选项,csbackup 实用程序将失败。例如,如果 backupdir 已经存在,即使该目录为空,以下命令也将失败:
csbackup database backupdir |
因此,如果指定的目标备份目录已经存在,必须在运行 csbackup 时包含 -f 选项。
也可以指定一个不存在的目标备份目录,让 csbackup 为您创建该目录。
以数据库属主的身份登录 (icsuser)。
要将日历备份到 iCalendar 或 XML 格式的文件中,请使用 csbackup 实用程序的 calendar 命令。
备份文件的文件扩展名(.ics 或 .xml)表明了其格式。
例如,可使用以下命令以 iCalendar (text/calendar MIME) 格式将日历 jsmithcal 备份到 backupdir 目录中的 jsmith.ics 文件中:
csbackup -c jsmithcal calendar backupdir/jsmith.ics |
或使用以下命令以 XML (text/XML) 格式将日历 jsmithcal 备份到 bcakupdir 目录中的 jsmith.xml 文件中:
csbackup -c jsmithcal calendar backupdir/jsmith.xml |
以数据库属主的身份登录 (icsuser)。
要将用户的默认日历备份到 iCalendar 或 XML 格式的文本文件中,请使用 csbackup 实用程序的 defcal 命令。为输出文件指定的文件扩展名(.ics 或 .xml)决定了使用的格式。
例如,可以使用以下命令以 iCalendar (text/calendar MIME) 格式将日历用户 jsmith 的默认日历备份到备份目录中名为 jsmith.ics 的文件中:
csbackup -a jsmith defcal backupdir/jsmith.ics |
或使用以下命令以 XML (text/xml MIME) 格式将日历用户 jsmith 的默认日历备份到备份目录中名为 jsmith.xml 的文件中:
csbackup -a jsmith defcal backupdir/jsmith.xml |
csrestore 实用程序,用于恢复使用 csbackup 保存的日历数据库、单个日历或用户的默认日历。必须在安装 Calendar Server 的本地计算机上运行 csrestore 实用程序,且必须首先停止 Calendar Server。(但备份数据库时可以运行 Calendar Server。)
本节包括以下内容:
以数据库属主的身份登录 (icsuser)。
要恢复使用 csbackup 实用程序保存到备份目录中的日历数据库,请使用 csrestore 实用程序的 database 命令。
例如,可使用以下命令恢复保存到名为 backupdir 的备份目录中的日历数据库:
csrestore database backupdir |
以数据库属主的身份登录 (icsuser)。
要从数据库中恢复使用 csbackup 实用程序保存到备份目录中的特定日历,请使用 csrestore 实用程序的 database 命令与 -c 选项。
例如,可使用以下命令从备份数据库目录 backupdir 中恢复日历 jsmithcal:
csrestore -c jsmithcal calendar backupdir |
以数据库属主的身份登录 (icsuser)。
要恢复使用 csbackup 实用程序保存到备份文件中的特定日历,请使用 csrestore 实用程序的 calendar 命令与 -c 选项。
备份文件的文件扩展名(.ics 或 .xml)表明了日历的保存格式。
例如,可使用以下命令恢复以 iCalendar (text/calendar MIME) 格式保存到 backupdir 目录中文件 jsmith.ics 中的日历 jsmithcal:
csrestore -c jsmithcal calendar backupdir/jsmith.ics |
或者使用以下命令恢复以 XML (text/calendar MIME) 格式保存到 bcakupdir 目录中文件 jsmith.xml 中的日历 jsmithcal:
csrestore -c jsmithcal calendar backupdir/jsmith.xml |
以数据库属主的身份登录 (icsuser)。
要恢复使用 csbackup 实用程序保存到备份文件中的用户的默认日历,请使用 csrestore 实用程序的 defcal 命令。
备份文件的文件扩展名(.ics 或 .xml)表明了日历的保存格式。
例如,可使用以下命令恢复以 iCalendar (text/calendar MIME) 格式保存到备份目录 backupdir 中文件 jsmith.ics 中的日历用户 jsmith 的默认日历:
csrestore -a jsmith defcal backupdir/jsmith.ics |
使用以下命令恢复以 XML (text/xml MIME) 格式保存到备份目录 backupdir 中文件 jsmith.xml 中的日历用户 jsmith 的默认日历:
csrestore -a jsmith defcal backupdir/jsmith.xml |
也可以使用 Sun StorEdge Enterprise Backup 软件(以前称为 Solstice Backup)或 Legato Networker 来备份和恢复 Calendar Server 数据。Sun StorEdge Enterprise Backup 软件和 Legato Networker 相似,本节中的说明同时适用于这两种产品。
然而,在尝试备份 Calendar Server 之前,请参见 Sun StorEdge Enterprise Backup 或 Legato Networker 文档。
有关 Sun StorEdge Enterprise Backup 软件的文档,请访问 http://docs.sun.com。
本节包括以下内容:
Calendar Server 在 /opt/SUNWics5/cal/sbin 目录中提供了以下文件,可与 Sun StorEdge 或 Legato 备份软件一起使用:
Calendar Server 应用程序特定模块 (Application Specific Module, ASM)。ASM 是一个程序,可由 Sun StorEdge 或 Legato 备份软件调用以备份和恢复数据。
用于调用 csbackup 实用程序的脚本。
—用于调用 csrestore 实用程序的脚本。
要使用 Sun StorEdge 或 Legato 备份软件来备份日历数据库,请执行以下操作:
将 Sun StorEdge 或 Legato 的 nsrfile 二进制文件复制到 /usr/lib/nsr 目录中。
在 /usr/lib/nsr 目录中创建以下符号链接:
icsasm -\> /opt/SUNWics5/cal/sbin/icsasm nsrfile -\> /usr/lib/nsr/nsrfile |
转到 /opt/SUNWics5/cal/sbin 目录,并在运行 csbackup 实用程序时带上 -l 选项。例如:
cd /opt/SUNWics5/cal/sbin ./csbackup -l |
-l 选项将在当前目录下创建备份目录映像。该目录中是一些空文件,仅用于向备份程序提供关于如何在备份介质中存储日历的信息。如果备份目录已经存在,系统将按照当前目录的结构对其进行同步。
使用 save 命令备份日历数据。例如:
/usr/bin/nsr/save -s /opt/SUNWics5/cal/sbin/budir |
也可以使用 Sun StorEdge 或 Legato 备份 GUI 来预定备份,方法是设置客户端存储集以定期备份数据库。
注意:请不要修改 .nsr 文件。这些生成的文件包含备份过程中由 save 命令和 icsasm 命令负责解释的指令。
Calendar Server 不支持增量备份功能。请不要使用该功能,因为备份目录只是文件夹结构的映像,并不包含实际的数据。
不能备份名称中包含非 ASCII 字符或反斜杠 (/) 的日历。
让备份过程自动完成。
前面的步骤介绍了如何手动运行备份操作。在运行备份程序的 save 命令之前,设置备份程序的 backup 命令以运行 Calendar Server csbackup 命令行实用程序,从而实现自动化的备份进程。
要恢复日历数据:
使用 Sun StorEdge Enterprise Backup 软件的 nwrestore 功能或 recover 命令恢复备份的日历信息。
如果使用 nwrestore,将看到以下消息:
"File already exists. Do you want to overwrite, skip, backup, or rename?" |
选择 overwrite。
出现该消息是因为备份树只是目录的分层结构。也就是说,备份树由空文件组成,且永远保持这种状态。
Calendar Server 包括“删除日志”数据库 (ics50deletelog.db),该数据库用来存储已删除的事件和待办事件(任务)。
在早期版本中,Calendar Server 没有提供维护已删除事件和任务的数据库。用户不得不通过保存事件或待办事件(任务)的唯一标识符 (uid) 或周期标识符 (rid) 来确定已删除的组件。这种局限性直接影响了使用 WCAP 命令生成客户端用户界面 (UI) 的安装。为解决此局限性,创建了“删除日志”数据库。
本章介绍了以下内容:
在 csdb 目录下除了创建其他 Calendar Server 数据库文件,Calendar Server 还将自动创建“删除日志”数据库 (ics50deletelog.db)。Calendar Server 按如下方式在“删除日志”数据库中写入事件和待办事件:
非重复性事件和待办事件
删除非重复性事件或待办事件后,Calendar Server 将从“事件”数据库 (ics50events.db) 或“待办事件”数据库 (ics50todos.db) 中将其删除,然后将其写入“删除日志”数据库 (ics50deletelog.db)。
重复性事件和待办事件
删除重复性事件或任务的单个实例后,Calendar Server 将把每个这样的实例写入“删除日志”数据库 (ics50deletelog.db)。
重复性事件或待办事件的所有实例被删除后,Calendar Server 将从事件或待办事件数据库中删除主组件,然后将其写入“删除日志”数据库。“删除日志”数据库中的主组件将包含以下重复性参数:rrules、rdates、exrules 和 exdates。
要从“删除日志”数据库返回条目,请使用 WCAP 命令 fetch_deletedcomponents(不管是在扩展模式还是在压缩模式下):
扩展模式 (recurring = 0)
如果 recurring 参数为 0,则 fetch_deletedcomponents 命令将返回符合条件的重复性事件的所有实例,但不会返回重复性事件的主组件。
压缩模式 (recurring = 1)
如果 recurring 参数为 1,则 fetch_deletedcomponents 命令将返回非重复性事件和所有重复性事件的主组件,但不会返回单个重复性事件。
如果删除了重复性链中的所有实例,则主组件将返回 dtstart、dtend、rrules、rdates、exrules、exdates 和 uid 参数。
另外,fetch_deletedcomponents 命令不返回与已删除重复实例关联但仍处于活动状态的主组件。要返回活动的主组件,请使用 WCAP 命令 fetchcomponents_by_lasmod。fetch_deletedcomponents 命令应该与 fetchcomponents_by_lasmod 命令一起使用。
有关 WCAP 命令的更多信息,请参见《Sun Java System Calendar Server 6 2005Q4 Developer’s Guide》。
Calendar Server 提供了自动清理“删除日志”数据库和手动清理“删除日志”数据库。
如果需要,可以让 Calendar Server 自动清理“删除日志”数据库中的条目。
下表介绍了 ics.conf 文件中控制自动清理的参数。
表 18–1 自动清理“删除日志”数据库的配置参数
参数 |
说明 |
---|---|
启用 ("yes") 或禁用 ("no") 自动清理“删除日志”数据库条目 (ics50deletelog.db) 功能。 默认值为 "no"。 |
|
指定自动清理“删除日志”数据库 (ics50deletelog.db) 中条目的时间间隔(以秒为单位)。 默认值为 60 秒。 |
|
指定清理“删除日志”数据库 (ics50deletelog.db) 中条目前的时间(以秒为单位)。 默认值为 86400 秒(1 天)。 |
例如,要使 Calendar Server 每五分钟(300 秒)自动清理一次 2 天(172800 秒)前生成的“删除日志”数据库条目,请按如下所示设置自动清理“删除日志”数据库中所述参数:
service.admin.purge.deletelog="yes" caldb.berkeleydb.purge.deletelog.interval=600 caldb.berkeleydb.purge.deletelog.beforetime=172800
设置这些参数后,重新启动 Calendar Server 以使新值生效。
要手动清理“删除日志”数据库 (ics50deletelog.db) 中的条目,请使用如下 cspurge 实用程序:
cspurge -e endtime -s starttime
其中,endtime 和 starttime 指定以祖鲁时间(也称为 GMT 或 UTC 时间)表示的开始时间和结束时间。
要运行 cspurge,必须以运行 Calendar Server 的用户和组身份登录(默认值为 icsuser 和 icsgroup)或以 root 用户身份登录。
例如,可使用以下命令清理自 2003 年 7 月 1 日到 2003 年 7 月 31 日之间的条目:
cspurge -e 20030731T235959Z -s 20030701T120000Z
有关更多信息,请参见cspurge。
下表列出了可以针对“删除日志”数据库使用的 (ics50deletelog.db) Calendar Server 实用程序:
表 18–2 支持“删除日志”数据库的实用程序
实用程序 |
说明 |
---|---|
cspurge |
允许手动清理“删除日志”数据库中的条目。 |
csbackup and csrestore |
支持“删除日志”数据库的备份和恢复。 |
csstats |
报告“删除日志”数据库的统计信息。 |
csdb |
支持对“删除日志”数据库执行重建、恢复和检查操作。 |
cscomponents |
列出(只读)“删除日志”数据库中的条目数。 |
有关更多信息(包括这些实用程序的语法),请参见附录 D,Calendar Server 命令行实用程序参考。
本附录介绍 Calendar Server 如何定义和处理时区,包含以下内容:
有关时区属性和参数的更多信息,请参阅 RFC 2445 "Internet Calendaring and Scheduling Core Object Specification (iCalendar)":
http://www.ietf.org/rfc/rfc2445.txt
timezones.ics 文件中包含 Calendar Server 支持的时区表示。该文件位于以下目录中:
cal_svr_base/SUNWics5/cal/data
启动时,Calendar Server 读取 timezones.ics 文件,生成时区数据,然后将数据存储在内存中。这样,在 Calendar Server 运行时,时区数据将一直保存在内存中。之后,如果添加新时区或修改现有的时区,必须停止并重新启动 Calendar Server 才能使所做的更改生效。
timezones.ics 文件中的时区由 TZID 参数标识。例如,Calendar Server 使用 America/Los_Angeles TZID 标识太平洋标准时间 (PST/PDT) 时区,如示例 19–1 所示。TZNAME 属性是时区的缩写表示,例如 PST(Pacific Standard Time,太平洋标准时间)代表 America/Los_Angeles 时区。
可识别夏令时 (daylight savings time, DST) 的时区(例如 America/Los_Angeles)包含两个组成部分:表示标准时间的 STANDARD 和表示 DST 的 DAYLIGHT。X-NSCP-TZCROSS 列表包含一系列日期,用于表明时区何时被更改为(或更改自)DST (DAYLIGHT) 和标准时间 (STANDARD)。
RRULE 属性定义 STANDARD 和 DAYLIGHT 规则的模式。TZOFFSETFROM 和 TZOFFSETTO 属性定义从 DST 更改为标准时间或从标准时间更改为 DST 之前和之后的 GMT 偏移。Communications Express 用户界面通过 X-NSCP-TZCROSS 中的日期来确定何时显示时区中的更改。
包含时区 ID (tzid) 参数的 WCAP 命令应引用 timezones.ics 文件中定义的有效时区。Calendar Server 然后将返回以该时区表示的数据。如果 WCAP 命令指定了无法识别的时区,默认情况下,Calendar Server 将返回以 GMT 时区表示的数据。有关 WCAP 的更多信息,请参阅《Sun Java System Calendar Server 6 2005Q4 Developer’s Guide》。
下面的示例显示了 timezones.ics 文件中 America/Los_Angeles 时区的表示。
BEGIN:VTIMEZONE TZID:America/Los_Angeles BEGIN:STANDARD DTSTART:19671025T020000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 TZOFFSETFROM:-0700 TZOFFSETTO:-0800 TZNAME:PST END:STANDARD BEGIN:DAYLIGHT DTSTART:19870405T020000 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 TZOFFSETFROM:-0800 TZOFFSETTO:-0700 TZNAME:PDT END:DAYLIGHT X-NSCP-TZCROSS: 19880403T100000Z;19881030T090000Z;19890402T100000Z;19891029T090000Z; 19900401T100000Z;19901028T090000Z;19910407T100000Z;19911027T090000Z; 19920405T100000Z;19921025T090000Z;19930404T100000Z;19931031T090000Z; 19940403T100000Z;19941030T090000Z;19950402T100000Z;19951029T090000Z; 19960407T100000Z;19961027T090000Z;19970406T100000Z;19971026T090000Z; 19980405T100000Z;19981025T090000Z;19990404T100000Z;19991031T090000Z; 20000402T100000Z;20001029T090000Z;20010401T100000Z;20011028T090000Z; 20020407T100000Z;20021027T090000Z;20030406T100000Z;20031026T090000Z; 20040404T100000Z;20041031T090000Z;20050403T100000Z;20051030T090000Z; 20060402T100000Z;20061029T090000Z;20070401T100000Z;20071028T090000Z; 20080406T100000Z;20081026T090000Z;20090405T100000Z;20091025T090000Z; 20100404T100000Z;20101031T090000Z;20110403T100000Z;20111030T090000Z; 20120401T100000Z;20121028T090000Z;20130407T100000Z;20131027T090000Z; 20140406T100000Z;20141026T090000Z;20150405T100000Z;20151025T090000Z; 20160403T100000Z;20161030T090000Z;20170402T100000Z;20171029T090000Z; 20180401T100000Z;20181028T090000Z;20190407T100000Z;20191027T090000Z; 20200405T100000Z;20201025T090000Z;20210404T100000Z;20211031T090000Z; 20220403T100000Z;20221030T090000Z;20230402T100000Z;20231029T090000Z; 20240407T100000Z;20241027T090000Z;20250406T100000Z;20251026T090000Z; 20260405T100000Z;20261025T090000Z;20270404T100000Z;20271031T090000Z; 20280402T100000Z;20281029T090000Z;20290401T100000Z;20291028T090000Z; 20300407T100000Z;20301027T090000Z;20310406T100000Z;20311026T090000Z; 20320404T100000Z;20321031T090000Z;20330403T100000Z;20331030T090000Z; 20340402T100000Z;20341029T090000Z;20350401T100000Z;20351028T090000Z; 20360406T100000Z;20361026T090000Z;20370405T100000Z;20371025T090000Z; 20360406T120000Z;20361026T110000Z;20370405T120000Z;20371025T110000Z END:VTIMEZONE |
本节介绍以下主题:
本节介绍如何为 Calendar Server 添加新时区,以便可以在 Communications Express 用户界面中使用它。例如,您可能需要添加 America/Miami 新时区。
要添加新时区,最简单的方法就是在以下步骤介绍的文件中复制并编辑与要添加的时区类似的时区条目。例如,如果要添加 America/Miami 时区,请复制并编辑每个文件中的 America/New_York 时区条目。
在以下文件中添加新时区的时区块:
cal_svr_base/SUNWics5/cal/data/timezones.ics |
同样,要添加新时区块,最简单的方法就是复制与要添加的时区类似的现有块(包括所有夏令时 [DST] 偏移)。然后编辑新时区块,对新时区进行任何所需的更改。如果新时区具有夏令时 (DST),可尝试找到类似的时区。
修改以下文件中的 getDisplayNameofTZID 模板:
cal_svr_base/SUNWics5/cal/html/language/i18n.xsl file |
其中,language 指定您的站点使用的语言的目录。例如:en 代表英语,fr 代表法语。
在 i18n.xsl 文件中添加如下所示的新条目:
<xsl:when test="$tzid=’TimeZoneArea/ TimeZoneName’"TimeZoneArea/ TimeZoneName</xsl:when\> |
其中:
TimeZoneArea 是以下地理区域之一:非洲、美洲、亚洲、大西洋、澳大利亚、欧洲或太平洋。
TimeZoneName 为新时区的名称。
例如:
<xsl:when test="$tzid='America/Miami'"\>America/Miami</xsl:when\> |
修改以下 XML 文件:
cal_svr_base/SUNWics5/cal/html/change_timezone.xml cal_svr_base/SUNWics5/cal/html/new_cal.xml cal_svr_base/SUNWics5/cal/html/new_group.xml |
在每个文件中添加以下代码行:
<timezone type="TimeZoneType" tzid="TimeZoneArea/TimeZoneName" offset="offset"> |
其中:
TimeZoneType 可以是 "americas"、"europeAfrica" 或 "asiaPacific"。
TimeZoneArea 和 TimeZoneName 在添加新时区中定义。
offset 是新时区比 GTM 时间早 (+) 或晚 (-) 的小时数。例如,如果新时区比 GMT 时间晚四个小时,则偏移值为 "-04:00"。
例如:
<timezone type="americas" tzid="America/Miami" offset="-05:00" daylightOffset="-04:00"> |
如果要将新时区作为用户首选项的默认时区,请修改以下文件中的 timezone 条目:
cal_svr_base/SUNWics5/cal/html/default_user_prefs.xml |
停止(如果必要)并重新启动 Calendar Server 以使新时区生效。
本节介绍如何修改现有时区。例如,您可能需要更改时区的名称,比如将 "America/Phoenix" 更改为 "US/Arizona"。
在以下文件中修改要更改的时区的时区块:
cal_svr_base/SUNWics5/cal/data/timezones.ics |
如果要更改时区名称,请将 TZID 条目更改为新名称。
修改以下文件中的 getDisplayNameofTZID 模板:
cal_svr_base/SUNWics5/cal/html/language/i18n.xsl file |
其中:language 指定您的站点使用的语言的目录。例如:en 代表英语,fr 代表法语。
如果要更改名称,请将现有的时区名称更改为新名称。
修改以下 XML 文件,对时区进行所需的更改:
cal_svr_base/SUNWics5/cal/html/change_timezone.xml cal_svr_base/SUNWics5/cal/html/new_cal.xml cal_svr_base/SUNWics5/cal/html/new_group.xml |
有关这些文件中的条目的信息,请参见添加新时区。
如果所做的更改影响用户首选项的默认时区,请修改以下文件中的 "icsTimeZone" 条目:
cal_svr_base/SUNWics5/cal/html/default_user_prefs.xml |
停止(如果必要)并重新启动 Calendar Server 以使时区更改生效。
与 Sun Java System Instant Messaging 6.0(或更高版本)集成的 Calendar Server 可以为日历事件和任务提供自动弹出式提醒通知。
本章介绍了以下内容:
本节包含以下主题:
用户可以在其日历上接受到即将举行的事件和任务的 Instant Messenger 弹出式提醒通知。要启用弹出式提醒通知,必须完成以下两件任务:
管理员必须配置 Calendar Server 和 Instant Messaging Server 以允许弹出式提醒通知。
最终用户必须在 Communications Express 的“选项”选项卡中指定电子邮件提醒通知,该通知将在“事件通知系统”中设置一个警报。
最终用户必须在 Instant Messenger 中启用日历提醒通知。
启用了弹出式提醒通知后,即将发生的事件或任务临近时,Event Notification System 中设置的警报将使 Calendar Server 发送电子邮件通知并使 Instant Messaging 显示弹出式提醒通知。
Calendar Server 管理员可以选择为最终用户配置电子邮件提醒通知或弹出式提醒通知,也可以选择同时配置这两项。例如,要关闭电子邮件提醒通知,可在 ics.conf 文件中设置以下参数:
caldb.serveralarms.binary.enable= "no"
如果配置了 Instant Messaging 弹出式提醒通知,它将遵循下面的构建流程:
Instant Messaging JMS 订户在事件通知服务 (ENS) 中订阅 Calendar Server 事件和通知。
Calendar Server 将事件或任务通知以 text/xml 或 text/calendar 格式发送给 ENS。
Instant Messaging JMS 订户接收日历事件或任务通知,然后生成 text/calendar 格式的消息。
Instant Messaging Server 将消息发送给日历属主(如果最终用户在线)。
如果收件人在线,Instant Messenger 将根据该消息在最终用户的桌面上生成 HTML 弹出式提醒通知。
本节包括以下配置说明:
配置 Instant Messaging 弹出式提醒通知所需的以下较高级别任务列表可以为您提供方便。要配置 Instant Messaging,请参阅以下站点上可用的 Instant Messaging 文档:
http://docs.sun.com/coll/1309.2 和 http://docs.sun.com/coll/1390.2
安装新软件包 SUNWiimag。
使用 Instant Messaging 弹出式提醒通知之前,必须首先使用 Java Enterprise System 安装程序安装 Instant Messaging 软件包。
在已安装 Instant Messaging 的计算机中,转到以下目录:
cd /etc/opt/SUNWiim/default/config
编辑下表中所示的 iim.conf 文件中的一个或多个参数。
显示的参数值假定您要为事件和任务都启用弹出式提醒通知。如果 iim.conf 文件中尚不存在这些参数,则先添加它们。
转到 imadmin 命令行实用程序所在的目录:
cd /opt/SUNWiim/sbin
使用 imadmin 启动 Calendar 代理:
imadmin start agent-calendar
Calendar 代理是 Instant Messaging 的一个组件,可以为 Calendar Server 用户提供弹出式功能。使用 Instant Messaging 提供的工具,可以启动、停止、重新启动 Calendar 代理或检查它的状态,也可以通过日志文件监视它的活动。
如果有包含 stop、start 和 refresh 命令的脚本,则可将 Calendar 代理加入其中。
有关 imadmin 和 Calendar 代理的更多信息,请参见《Sun Java System Instant Messaging 7 2005Q1 管理指南》。
确认下表中所示的 ics.conf 参数具有所示的值。如果它们不具有这些值,或者您要对它们进行自定义设置,则按以下步骤操作:
以有权更改此配置的管理员身份登录。
转至 /etc/opt/SUNWics5/cal/config 目录。
通过复制和重命名旧的 ics.conf 文件来保存该文件。
编辑 ics.conf 参数的值,如下表所示:
参数 |
说明和默认值 |
---|---|
caldb.serveralarms |
启用要排队的日历警报。默认值为 "yes"(启用)。 |
caldb.serveralarms.contenttype |
警报内容的输出格式。默认值为 "text/xml"。 |
caldb.serveralarms.dispatch |
启用要分发的日历警报。默认值为 "yes"。 |
caldb.serveralarms.dispatchtype |
要分发的服务器警报的类型。默认值为 "ens"。 |
caldb.serveralarms.url |
这是检索警报内容的警报的 URL。默认值为 "enp:///ics/customalarm"。 |
将此文件另存为 ics.conf。
重新启动 Calendar Server。
cal_svr_base/SUNWics5/cal/sbin/start-cal
要接收 Calendar Server 事件和任务的弹出式提醒通知,最终用户必须按以下方式配置 Instant Messenger:
要改进 Calendar Server 的性能,请考虑使用以下方法:
要改进 Calendar Server 访问 LDAP Directory Server 时的性能,请在 LDAP 配置文件中添加以下属性的索引:
此属性用于搜索日历用户或资源的默认日历。指定存在 (pres)、等式 (eq) 和子串 (sub) 索引类型。
此属性用于搜索用户所拥有的其他日历。指定存在 (pres)、等式 (eq) 和子串 (sub) 索引类型。另请参见提高日历搜索在 DWP 环境中的性能。
这两个属性用于指定用户的主电子邮件地址和备用电子邮件地址。另请参见创建用户和资源和Calendar Server 实用程序 (csuser enable)。
有关添加目录服务器索引的信息,请参阅以下位置处的 Directory Server 文档:
http://docs.sun.com/coll/1316.1 和 http://docs.sun.com/coll/1389.1
处于 DWP 环境(即,日历数据库分布在多个后端服务器中)中时,在日历数据库中搜索某个日历将会消耗大量时间。如果先在 LDAP 条目中查找,然后直接找出该日历所在的那个 DWP 主机,日历搜索的速度将会更快。
本节包含以下主题:
要启用日历搜索先查看 LDAP 目录,然后查看日历数据库,请执行以下步骤:
编辑 ics.conf 文件中的 service.calendarsearch.ldap 参数,将该参数设置为 "yes"(默认值),如下所示:
service.calendarsearch.ldap="yes"
重新启动日历服务,如下所示:
start-cal
如果允许匿名访问公共日历,您可能希望禁用日历搜索对 LDAP 进行查看。事实上,Communications Express 要求此参数值为 "no"。
要确定是否可以通过创建索引提高日历搜索性能,请尝试使用以下 LDAP 命令:
ldapsearch -b "base" "(&(icscalendarowned=*user*) (objectclass=icsCalendarUser))" |
其中,base 是用户和 Calendar Server 资源数据所在的 Directory Server 的 LDAP 基本 DN,user 是最终用户可以在搜索对话框中输入的值。
测试表明,如果没有为 icsCalendarOwned 创建索引,使用上述搜索功能搜索 60,000 个条目大约需要 50 到 55 秒。而创建索引后,上述搜索只需要大约 1-2 秒时间。
通过运行 comm_dssetup.pl 为相应的 LDAP 属性或仅仅为 icsCalendarOwned 创建索引。
comm_dssetup.pl 将为该属性和许多其他属性创建索引,以提高各方面的性能。如果尚未运行 comm_dssetup.pl,或者已运行但尚未执行创建索引操作,则可以再次运行此实用程序来创建索引,也可以使用 Directory Server 工具来执行创建索引操作。
有关如何使用 comm_dssetup.pl 创建索引的信息,请参见属性索引。
有关添加目录服务器索引的信息,请参阅以下位置处的 Directory Server 文档:
http://docs.sun.com/coll/1316.1 和 http://docs.sun.com/coll/1389.1
默认情况下,Calendar Server 中禁用通配符搜索。即,当您使用图形用户界面搜索日历时,或在自定义界面中发出 search_calprops.wcap 时,它将搜索与使用 WCAP 命令传递的搜索字符串完全匹配的字符串。
如果您通过取消注释 ics.conf 文件中的以下行(删除开头的惊叹号 "!")启用了通配符搜索,则可能对性能产生负面影响。
!service.calendarsearch.ldap.primaryownersearchfilter = "(&(|(uid=*%s*)(cn=*%s*))(objectclass=icsCalendarUser))"
要测试通配符搜索对性能的影响,请通过在行前插入惊叹号 ("!") 再次注释行。
在系统访问日历数据库中的日历之前,系统必须确定哪台后端计算机存储了该用户的日历。为了找到相应的后端计算机,系统将搜索 LDAP 目录以查找该用户的条目并选取 icsDWPHost 属性。此搜索会消耗大量时间,而且每次对日历数据进行访问时都必须执行它。每个用户会话都需要多次访问数据库,从而导致多次搜索 LDAP。为了节省时间并提高性能,请通过编辑 ics.conf 文件来启用 CLD 高速缓存,如下所示:
caldb.cld.cache.enable="yes"
LDAP 数据高速缓存存储了用户 ID 及其关联的 icsDWPHost 属性。在搜索 LDAP 查找用户条目之前,系统将检查该高速缓存中是否存在该用户 ID。如果高速缓存中有该用户 ID,系统将从存储在高速缓存中的 icsDWPHost 属性中选取后端主机名。如果高速缓存中没有该用户 ID,系统将执行 LDAP 搜索并将该用户 ID 和属性复制到 CLD 高速缓存中。以后,对该用户日历数据的访问速度就会变快,因为现在可以在高速缓存中找到该用户 ID。
启用 LDAP 数据高速缓存后,可以使用 ics.conf 参数对其进行优化,请对下表中列出的一个或多个参数进行调整:
默认情况下,已启用 LDAP 数据高速缓存。您可以通过以下设置来禁用它:local.ldap.cache.enable="no"
参数 |
说明/值 |
---|---|
local.ldap.cache .checkpointinterval |
检查点之间检查点线程休眠的秒数。默认值为 "60"。 在活动频繁的 LDAP 中,您可能需要降低该时间间隔以使高速缓存尽可能地保持当前状态。同时,请记住刷新高速缓存的频率越高,引入的系统开销就越多。 |
local.ldap.cache. circularlogging |
指定在处理完 LDAP 数据高速缓存数据库日志文件之后是否将其删除。默认值为 "yes"。 请勿更改该参数,除非您有用于删除旧日志文件的自定义清理例程。 |
local.ldap.cache. logfilesizemb |
以兆字节为单位指定检查点文件大小的最大值。默认值为 "10" 兆字节。 如果您拥有一个活动频繁的 LDAP,此文件可能在检查点时间间隔结束之前填满。请根据您的经验尝试将该值设置为接近日志实际大小的值。 |
local.ldap.cache. maxthreads |
指定 LDAP 数据高速缓存数据库的最大线程数。默认值为 "1000"。 在活动频繁的 LDAP 中,您可能希望增加线程数。这可能会导致对 CPU 占用的增加。仅当 LDAP 活动程度最小时,才能减少线程数。 |
local.ldap.cache. mempoolsizemb |
以兆字节为单位指定共享内存的大小。默认值为 "4" 兆字节。 |
local.ldap.cache. entryttl |
以秒为单位指定 LDAP 数据高速缓存条目的“生存时间”(Time to Live, TTL)。默认值为 "3600" 秒(1 小时)。 如果高速缓存过快地填满(活动频繁),您可以减少 TTL。但是,这会增加 LDAP 数据库的总访问次数,从而降低系统的总体性能。 |
local.ldap.cache. cleanup.interval |
以秒为单位指定清理各个高速缓存数据库的时间间隔。默认值为 "1800" 秒(30 分钟)。 系统将删除过期条目。此时间间隔不必与条目的 TTL 相同。但将这两个时间同步会使系统更高效。 |
local.ldap.cache. stat.enable |
指定是否将访问记录到 LDAP 数据高速缓存,以及是否在日志文件中记录统计信息。默认值为 "no"。 为了增强性能,请仅在调试模式下使用此参数。 |
local.ldap.cache. stat.interval |
以秒为单位指定每个统计报告写入日志文件的时间间隔。默认值为 "1800" 秒(30 分钟)。 仅当启用 local.ldap.cache.stat.enable 时,此参数才处于活动状态。减少时间间隔有助于您查明问题所在。增加时间间隔有助于降低系统负载。 |
Communications Express 要求禁用数据高速缓存。
有一对参数用于控制项目保存在高速缓存中的时间以及高速缓存可以具有的大小。
要对高速缓存进行优化,请编辑下表中列出的一个或多个参数:
表 21–2 用于配置 LDAP SDK 高速缓存的 ics.conf 参数
参数 |
说明和默认值 |
---|---|
目前尚未实现。必须手动删除 ldap_cache 目录中的内容,然后重新启动 Calendar Server。 如果将 service.ldapmemcache 设置为 "yes",则可以使用此参数来设置所允许的项目的最大高速缓存秒数。如果设置为 "0",则项目的高速缓存时间没有限制。默认值为 "30"。 |
|
如果将 service.ldapmemcache 设置为 "yes",则可以使用此参数来设置高速缓存将消耗的最大内存量(以字节为单位)。如果设置为 "0",则高速缓存没有大小限制。默认值为 "131072"。 |
必须根据需要调整保留在磁盘上的备份数目,以使其不会超出可用磁盘空间。您可以通过更改各种 ics.conf 参数来管理归档和热备份所占用的磁盘空间量,这些参数用于确定可以同时保留的备份副本数以及将触发清理旧副本操作的磁盘空间阈值。
可以针对每种备份类型(归档和热备份)调整以下三种参数:
mindays—备份可以保存在磁盘上的最少天数。
maxdays—备份可以保存在磁盘上的最多天数。
threshold—已用磁盘空间占总磁盘空间的百分比。此参数用作触发点。
Calendar Server 保留备份的最多可能天数是以不超过磁盘空间阈值为准。因此,如果当前备份将要使磁盘使用率超过阈值,系统将清除最早的备份副本,并查看磁盘使用率是否降低到阈值以下。系统将继续清除早期的备份副本,直到满足以下条件之一:再删除一个备份副本将使磁盘上的备份数目小于备份副本的最小数目,或者磁盘空间使用率已低于阈值。
因此,您可以使用阈值参数来管理备份使用的磁盘空间量。反之,您也可以通过调整允许的磁盘空间量和副本数目来管理保留在磁盘上的备份数目。
下表列出了用于控制磁盘空间和在磁盘上保留的备份数目的 ics.conf 参数:
表 21–3 用于设置保存在磁盘上的备份数目的 ics.conf 参数
ics.conf 参数 |
默认设置 |
说明 |
---|---|---|
caldb.berkeleydb.hotbackup .mindays |
3 |
将热备份保留在磁盘上的最少天数。 |
caldb.berkeleydb.hotbackup .maxdays |
6 |
将热备份保留在磁盘上的最多天数。 |
caldb.berkeleydb.hotbackup .threshold |
70 |
用于热备份的磁盘空间占总磁盘空间的百分比。超过此值时将触发清除最早的副本。 |
caldb.berkeleydb.archive.mindays |
3 |
将归档备份保留在磁盘上的最少天数。 |
caldb.berkeleydb.archive.maxdays |
6 |
将归档备份保留在磁盘上的最多天数。 |
caldb.berkeleydb.archive .threshold |
70 |
用于归档备份的磁盘空间占总磁盘空间的百分比。超过此值时将触发清除最早的副本。 |
如果服务器上有多个 CPU,则默认情况下 Calendar Server 会将 HTTP 服务(cshttpd 进程)和分布式数据库服务(csdwpd 进程)分布到这些 CPU 中。
service.http.numprocesses 和 service.dwp.numprocesses 参数确定了为每个服务实际运行的进程数目。默认情况下,在安装时将这些参数设置为服务器的 CPU 数目,但您可以重新设置这些值。例如,如果服务器具有 8 个 CPU,但您希望 cshttpd 和 csdwpd 只在 4 个 CPU 中运行,可以将这些参数设置为:
service.http.numprocesses="4" service.dwp.numprocesses="4"
要禁用负载平衡,请将 service.loadbalancing 参数添加到 ics.conf 文件中,并将其设置为 "no"。然后重新启动 Calendar Server 以使更改生效。
可以使用各个 ics.conf 参数的超时值来调整 Calendar Server 的性能。
共有以下几类超时:
有关编辑 ics.conf 参数的信息,请参见编辑 ics.conf 配置文件。
下表介绍了 ics.conf 文件中由管理 (csadmin) 服务使用的 Calendar Server 超时参数。
表 21–4 管理服务 (csadmin) 的 HTTP 超时值
参数 |
说明 |
---|---|
service.admin.idletimeout |
指定在 HTTP 连接空闲超时前 csadmind 服务等待的秒数。 默认值为 120 秒(2 分钟)。 |
service.admin.resourcetimeout |
指定资源日历的 HTTP 会话超时前 csadmind 服务等待的秒数。 默认值为 900 秒(15 分钟)。 |
service.admin.sessiontimeout |
指定在 HTTP 会话超时前 csadmind 服务等待的秒数。 默认值为 1800 秒(30 分钟)。 |
下表介绍了 ics.conf 文件中适用于最终用户的 Calendar Server HTTP 超时参数。
表 21–5 ics.conf 文件中适用于最终用户的 HTTP 超时值(cshttpd 服务)
参数 |
说明 |
---|---|
service.http.idletimeout |
指定空闲 HTTP 连接超时前 cshttpd 服务等待的秒数。 默认值为 "120" 秒(2 分钟)。 |
service.http.resourcetimeout |
指定资源日历 HTTP 会话超时前 cshttpd 服务等待的秒数。 默认值为 "900" 秒(15 分钟)。 |
service.http.sessiontimeout |
指定 HTTP 会话超时前 cshttpd 服务等待的秒数。 默认值为 "1800" 秒(30 分钟)。 |
以下 ics.conf 文件参数以秒为单位指定要在 Calendar Server 扫描组调度引擎 (Group Scheduling Engine, GSE) 队列中的传入作业之前等待的时间:
gse.belowthresholdtimeout="3"
如果队列中的作业数目大于分配的最大线程数,最后一个线程始终会重新扫描队列。因此,此设置仅在作业数目少于分配的最大线程数时才有效。
默认值为 "3"。增加该值可以减少服务器扫描队列的频率,改进总体性能。但是,如果队列因事件数量的增加而变得太大,则可以减少该时间以加快处理队列。这有可能导致总体性能降低,但用于更新事件的时间会更短。
本章介绍了一些错误诊断技术,您可以使用这些技术来确定您的系统是否有问题以及产生问题的原因。本章包含以下主题:
由于没有哪个 ics.conf 参数可用于将整个系统置入“调试模式”,因此,本节介绍了一些获取有用调试信息的方法:
确保在不需要的时候关闭超额的日志记录和监视,因为它将对性能产生负面影响。
使用下表显示的参数来提高日志记录的详细级别:
参数 |
说明和默认值 |
---|---|
logfile.loglevel |
设置为 DEBUG 可以获得所有详细级别的日志,其中包括 CRITICAL、ALERT、ERROR、WARNING、 NOTICE 和 INFORMATION。此参数适用于所有日志。 |
有关各种可用日志的更多信息,请参见使用 Calendar Server 日志文件。
要将所有访问信息记录到 LDAP 数据高速缓存并打印日志(报告),请设置下表中所示的 ics.conf 参数:
参数 |
说明和默认值 |
---|---|
local.ldap.cache.stat.enable |
指定是否将访问记录到 LDAP 数据高速缓存,以及是否在日志文件中记录统计信息。默认值为 "no"(不记录统计信息)。设置为 "yes" 可以记录统计信息。 为了增强性能,请仅在调试模式下使用此参数。 |
local.ldap.cache.stat.interval |
以秒为单位指定每个统计报告写入日志文件的时间间隔。默认值为 "1800" 秒(30 分钟)。 仅当启用了日志记录时,此参数才处于活动状态。减少时间间隔有助于您查明问题所在。增加时间间隔有助于降低系统负载。 |
目前 Calendar Server 中没有使 LDAP 高速缓存数据过期的设置。必须手动删除 ldap_cache 目录中的内容,并重新启动 Calendar Server。
停止 Calendar Server。
删除 /var/opt/SUNWics5/csdb/ldap_cache 目录中的所有文件,但不删除 ldap_cache 目录本身。
重新启动 Calendar Server。
请使用以下 Calendar Server 实用程序监视您的系统:
csmonitor—指定所需的调试级别。值越高,消息就越详细。
csstats—使用 list 命令显示 counter.conf 文件中定义的计数器对象中的统计信息。
cstool—使用该实用程序强制回应以下服务:cshttpd、csadmind 和 enpd。
有关 Calendar Server 实用程序的更多信息,请参见附录 D,Calendar Server 命令行实用程序参考。
如果是首次创建托管环境,则必须通过添加域、容器、用户和资源的适当条目来创建 LDAP 中的 DC 树。使用诸如 cscal 之类的 Calendar Server 实用程序时,如果 DC 树尚未存在,则可能会看到以下错误消息:“初始化失败.... 退出”。
请确保 DC 树在其根目录下至少包含一个(默认)域。按照创建新托管域中提供的说明,创建 DC 树结构。
Calendar Server 提供了几个用于迁移日历数据库和 LDAP 目录的实用程序。本节包含以下主题:
通常,如果您在使用迁移实用程序时遇到问题,应与技术支持联系,在联系之前,应先收集以下信息:
出现问题的数据库的备份副本。
所有相关日志的副本。
所有错误输出消息(包括核心转储文件)。
您可以从下述内容所指明的位置处找到各个迁移实用程序及其文档:
该实用程序与 Delegated Administrator (一个可单独安装的组件)捆绑在一起。此实用程序将 LDAP 目录从 Schema 1 迁移到 Schema 2。有关此实用程序的信息,请参见《Sun Java System Communications Services 6 2005Q4 Schema Migration Guide》。
技术支持处提供了包含该实用程序及其文档的迁移软件包。
此实用程序是随 Calendar Server 一起安装的。可在第 4 章,数据库迁移实用程序中找到它的说明,该文档包含有错误诊断一节。如果使用的是托管域和 LDAP 日历查找数据库 (CLD) 插件,则有必要运行此实用程序。
此实用程序是随 Calendar Server 一起安装的。可在第 4 章,数据库迁移实用程序中找到它的说明。使用该实用程序可以针对托管域准备日历数据库和 LDAP 目录条目。
此实用程序是随 Calendar Server 一起安装的。可在第 4 章,数据库迁移实用程序中找到它的说明。使用此实用程序可以迁移 Calendar Server 2 数据库从而使其与 Calendar Server 5 兼容。
您只能从技术支持处获得此实用程序。实用程序软件包包含文档。此实用程序将 Netscape Calendar Server 4 迁移至 Calendar Server 5。由于在源数据库中缺乏一致性,进行这些迁移时往往需要特别注意。可在很多手册中找到该实用程序的说明。您只能从技术支持处获得此实用程序。实用程序软件包包含文档。此实用程序将 Netscape Calendar Server 4 迁移至 Calendar Server 5。进行这些迁移时往往需要特别注意。通常需要对源文件做大量工作后,才可以运行该实用程序。您可以考虑使用专业服务来帮助您规划迁移。
本节介绍了对非数据库问题的各种错误诊断方法。本节包含以下主题:
此外,在讲述 SSL 的一章中有一节是说明 SSL 错误诊断:
要验证某项服务是否在侦听指定的端口号,请使用 cstool 实用程序的 ping 命令。强制回应服务无法验证该服务是否正在运行,但可以表明该服务是否可以接受套接连接。
Calendar Server 服务选项如下:
HTTP 服务 (cshttpd)
管理服务 (csadmind)
事件通知服务 (enpd)
不能强制回应 DWP 服务 (csdwpd) 或通知服务 (csnotifyd)。
例如,要强制回应主机名为 calserver 的计算机以查看 cshttpd 服务是否在侦听端口 80:
cstool -p 80 -h calserver ping http
默认情况下,cstool 等待响应的时间为 120 秒,但您可以使用 -t timeout 选项更改此值。
有关完整的实用程序参考资料,请参阅附录 D,Calendar Server 命令行实用程序参考。
要运行 cstool,Calendar Server 必须正在运行。
如果在您发出 start-cal 后并没有启动所有日历服务,则在重新启动之前必须停止已启动的日历服务。例如,如果 enpd、csnotifyd 和 csadmind 已启动,但 cshttpd 没有启动,则必须停止 enpd、csnotifyd 和 csadmind。
要启动日历服务,请执行以下步骤:
以具备管理权限的用户身份登录正在运行 Calendar Server 的系统。
使用 start-cal 停止并重新启动服务。例如:
cal_svr_base/SUNWics5/cal/sbin/start-cal
start-cal 首先发出 stop-cal 命令,然后再启动各种日历服务。
如果 stop-cal 无法停止服务,则可能是无法停止某些子进程。要解决此问题,请参见解决 stop-cal 问题。
当 Calendar Server 关闭时,需要单独考虑两个问题:
发出 stop-cal 之后,某些子进程可能仍未停止。例如,stop-cal 可以停止 cshttpd 父进程,但无法停止任何 cshttpd 子进程。在这种情况下,必须使用以下过程单独停止其余的 Calendar Server 进程。
以具备管理权限的用户身份登录正在运行 Calendar Server 的系统。
通过针对每一项服务输入 ps 命令来确定其余 Calendar Server 进程的进程 ID (Process ID, PID):
ps -elf | grep cs-process |
其中,cs-process 为 enpd、csnotifyd、csdwpd、csadmind 或 cshttpd。例如:
ps -elf | grep cshttpd |
使用仍在运行的每个进程的 PID,并输入 kill -15 命令来中止这些进程。例如:kill -15 9875
再次针对每项服务输入 ps 命令,以确保已停止所有 Calendar Server 进程。
如果仍有 Calendar Server 进程在运行,请输入 kill -9 命令将其中止。例如:kill -9 9875 |
在运行 Calendar Server 的 Linux 系统中,如果使用 ps 命令搜索日历进程,搜索结果的显示可能会十分混乱。在 Linux 系统中,ps 命令返回正在运行的线程的列表,而不是进程列表。尚未找到解决方法来仅显示进程。
如果未正确关闭 Calendar Server,请执行以下步骤:
执行上一个过程解决 stop-cal 问题中的步骤。
手动删除 LDAP 数据高速缓存数据库目录中的所有文件。
这些遗留文件可能会导致数据库损坏。要删除这些文件,请执行以下步骤:
重新启动 Calendar Server。
cal_svr_base/SUNWics5/cal/sbin/start-cal
有关如何配置 LDAP 数据高速缓存的说明,请参见为 LDAP 配置 Calendar Server。有关 LDAP 数据高速缓存的更多信息,请参见《Sun Java System Communications Services 6 2005Q4 Deployment Planning Guide》。
Ping 后端服务器以查看它是否响应。
如果响应,请转到步骤 3。如果不响应,请确定失败原因,当其再次起作用时,接着
清除 CLD 高速缓存。请参见清除 CLD 缓存。
如果使用的是 CLD 高速缓存选项,并已通过 ics.conf 参数更新了服务器名,则应清除 CLD 高速缓存以删除服务器名。CLD 缓存中的旧条目会导致前端服务器无法正确连接到后端服务器,或导致 Calendar Server 无法找到移动后的日历。
重新启动 Calendar Server。
如果使用的是 CLD 高速缓存选项,并已将一个或多个日历移至其他后端服务器(或更改了后端服务器的名称),请执行以下步骤:
确保已按以下说明移动日历:
清除 CLD 高速缓存。请参见清除 CLD 缓存。
如果已将一个或多个日历移至其他后端服务器,则 CLD 高速缓存将失效。要刷新 CLD 高速缓存,您需要先清除它,这样才可重建它。
验证 service.http.allowadminproxy 是否设置为 "yes"。
验证 admin-user 是否具有 Calendar Server 管理员权限。
验证 admin-password 是否正确。
验证 calendar-user 是否为 Calendar Server 的有效用户。
LDAP 目录服务器配置中的 nsslapd-sizelimit 和 nsLookthroughLimit 属性必须足够大,以使搜索能够顺利完成。如果 nsSizeLimit 不够大,则进程可能被中断,而不显示任何结果。如果 nsLookthroughLimit 不够大,则可能无法完成搜索。
本节包含以下主题:
要确定是否为这些属性设置了适当的值,请尝试以下命令:
ldapsearch -b "base " "(&(icscalendarowned=*user*)(objectclass=icsCalendarUser))"
其中,base 是 Calendar Server 用户和资源数据所在目录服务器的 LDAP 基本 DN,user 是最终用户可以在用户界面的搜索对话框中输入的值。
如果 LDAP 服务器返回错误消息,则可能是由于参数 nsSizeLimit 或 nsLookthroughLimit 的值不够大。
这些属性的 DN 为:
dn: cn=config,cn=ldbm databases,cn=plug ins,cn=config
使用 ldapmodify 动态设置 nsLookthroughLimit 的值。
即,无需停止和重新启动 Directory Server 来更改此属性。
默认值为 5000。如果搜索未报告结果,您可能希望增大该值。但是,这将使 LDAP 服务器的性能降低。
可以将限制设置为 -1,这样将取消任何限制。但是,这样做时应小心,因为它很可能会导致系统挂起。
如果要将 nsslapd-sizelimit 设置为更高的值,则必须执行以下步骤:
停止 Directory Server。
编辑 dse.ldif 文件。
重新启动 Directory Server。
有关如何使用 ldapmodify 和编辑 dse.ldif 文件的信息,请参见以下位置处的 Directory Server 文档:
http://docs.sun.com/coll/1316.1 和 http://docs.sun.com/coll/1389.1
即使未配置 csstored 进程,默认情况下 start-cal 命令也将启动该进程。未配置的 csstored 进程将每隔 24 小时在运行 csstored 的每台计算机上发出消息说明其尚未配置。
通过禁止未配置的 csstored 进程运行可以禁用此消息。要禁止 csstored 进程运行,请按如下所示在生成此消息的每台计算机上设置 ics.conf 参数:
service.store.enable=”no”
在将 csstored 配置为进行自动备份的计算机上,请确保没有禁用该进程。
本节介绍了与日历服务器数据库有关的各种问题:
所要采取的多数错误诊断步骤都需要您具有对 Berkeley 数据库实用程序的访问权限。虽然在 Calendar Server 包中提供了这些实用程序的某个版本,但它们不受支持。您可能希望直接从 Sleepycat Software (http://www.sleepycat.com) 上获得更多信息。
本节包含以下主题:
设置并导出 LD_LIBRARY_PATH 环境变量以反映以下目录:
cal_svr_base/SUNWics5/cal/tools/unsupported/bin/
下表列出了一些常用 Berkeley 数据库工具(实用程序)。
Berkeley 数据库工具 |
说明 |
---|---|
db_archive |
将不再使用的日志文件的路径名写入标准输出结果中,每行一个路径名。 |
db_checkpoint |
一个守护进程,用于监视数据库日志并定期调用检查点例程以对其进行检查点检查。 |
db_deadlock |
遍历数据库环境锁定区域,并在每次检测到死锁或已超时的锁定请求时异常中止锁定请求。 |
db_dump |
将指定文件以 db_load 实用程序能够识别的平面文本格式写入标准输出结果中。 |
db_load |
从标准输入中读取文件并将其载入指定的数据库文件。如果文件尚未存在,此工具将创建它。 |
db_printlog |
调试用于将日志文件转储为用户可读格式的实用程序。 |
db_recover |
在发生意外的应用程序、数据库或系统故障后,将数据库恢复到一致性状态。 |
db_stat |
显示数据库环境的统计信息。 |
db_verify |
验证一个或多个文件及其所包含的数据库的结构。 |
如果 Berkeley 数据库处于死锁状态,则必须重置数据库。尽早检测到此状态是很重要的。
要使系统可以定期检查数据库以检测到死锁状态并通知管理员,请执行以下步骤:
以有权更改此配置的管理员身份登录。
转至 /etc/opt/SUNWics5/cal/config 目录。
通过复制和重命名旧的 ics.conf 文件来保存该文件。
如果必要,编辑 ics.conf 使其具有以下值:
local.caldb.deadlock.autodetect=”yes”
将此参数设置为 "yes" 时,将启动用于监视锁定区域的 db_deadlock 守护进程。
导致日历数据库损坏的原因有多种:系统资源争用、硬件错误、应用程序错误和数据库错误,当然还有人为错误。本节介绍了如何检测日历数据库损坏:
没有人可以保证数据库不被损坏。但您可以最小化数据丢失和运行的停机时间。严密监视数据库和日历服务器是尽早检测到损坏的关键。频繁和完整的备份是在发现损坏后从损坏中恢复的关键。
日历数据库中有两种可能的损坏级别:
应用程序级别—一个或多个数据库文件中的违例条目会在服务器运行这些条目时阻止服务器继续运行。
数据库级别—Berkeley 数据库页面中的损坏会导致各种问题。一个常见的症状是运行 csdb check 时不断循环。另一个常见症状是显示错误消息,例如:
“非法的页面类型或格式”或 “第 97895 页不存在,未设置创建标志”
查看 Calendar Server 日志文件(包括警报日志)中的错误消息,这些消息可能会表明数据库受到损坏。有关日志文件的信息,请参阅使用 Calendar Server 日志文件。
应该定期查看日志文件,看是否发生了 ALERT、CRITICAL、ERROR 和 WARNING 级别的错误,如果发现这些错误,请检查事件以找出 Calendar Server 操作可能出现的问题。在 Calendar Server 的正常操作过程中,系统会生成 NOTICE 和 INFORMATION 级别的日志事件,以帮助您监视服务器的活动。
任何情况下都不要移除数据库目录中的任何事务日志文件。事务日志文件包含事务更新(添加、修改或删除),移除这些文件将损坏日历数据库,且无法恢复。
在请求 Calendar Server 技术支持时,可能需要您提供日志文件以协助解决问题。
使用 csmonitor 实用程序可以监视 Calendar Server。如果该实用程序检测到问题(例如,检测到多个事务日志文件或日历数据库缺少磁盘空间),该实用程序将向管理员发送警报电子邮件。有关更多信息,请参见csmonitor。
使用 check 命令可以扫描日历数据库,包括日历属性 (calprops) 和事件以及待办事件(任务),以查看其中是否存在损坏。如果使用 check 命令发现无法解决的冲突,则将在输出结果中报告该情况。
check 命令不检查警报或组调度引擎 (Group Scheduling Engine, GSE) 数据库中的损坏。
以具备管理权限的用户身份登录安装了 Calendar Server 的系统。
Calendar Server 可以正在运行或已经停止,但最好停止 Calendar Server。
如果尚未备份,请备份日历数据库。
只需复制数据库 (.db) 文件。无需复制任何共享 (__db.*) 文件或日志 (log.*) 文件。
转至 cal_svr_base/SUNWics5/cal/sbin 目录。
例如,在 Solaris 操作系统上为转到默认目录,请输入:
cd /opt/SUNWics5/cal/sbin |
针对日历数据库副本运行 check 命令:
./csdb check dbdir /tmp/check.out |
如果未指定 dbdir,则 check 命令将针对当前目录中的数据库。
check 命令会生成许多信息,因此请考虑将所有输出结果(包括 stdout 和 stderr)重定向到一个文件中(如示例中所示)。
运行完 check 命令后,查看输出文件。如果数据库已损坏,请运行 rebuild 命令。
(请参见重建损坏的日历数据库。)
本节介绍了如何在处于恢复模式时使损坏的数据库仍然可访问,包含以下主题:
如果遇到数据库损坏,一种防止服务中断的方法是将数据库置入只读模式。此模式允许最终用户读取数据库条目,但不允许添加、修改或删除。如果最终用户试图添加、修改或删除任何日历数据,系统将给出错误消息。另外,数据库处于只读模式时,用于添加、修改或删除日历事件和待办事件的管理员工具将不起作用。
如果数据库被损坏到无法读取的程度,则必须中断服务直到用备份进行了恢复。使用备份进行恢复的最快方法是拥有完好的热备份。请参见恢复之前。
当然这并不是必需的,您可能选择即刻停止日历服务以防止数据库受到进一步损坏。
要停止日历服务,请使用以下命令:
cal_svr_base/SUNWics5/cal/sbin/stop-cal
在命令行,转到 ics.conf 所在的目录:
cd /etc/opt/SUNWics5/config
将日历数据库指定为只读模式:
caldb.berkeleydb.readonly=”yes”
编辑完 ics.conf 文件后,重新启动 Calendar Server:
cal_svr_base/SUNWics5/cal/sbin/start-cal
必须重新启动这些服务才能使 ics.conf 更改生效。
本节介绍了一些常见数据库故障,并提供了一些建议的修正方法。本节包含以下主题:
由于 csadmind 是处理组调度引擎 (Group Scheduling Engine, GSE) 和警报分发引擎的服务,因此,此故障可能是由 GSE 队列或警报队列中的违例条目引起的。
修正方法:
如果 csadmind 未运行,则立即发出 stop-cal。
保持日历服务器运行可能导致事务日志累积,从而进一步损坏数据库,并可能需要更长时间才能使事务日志文件与数据库一致。
尝试再次重新启动 csadmind(再次重新发出 start-cal)。
如果启动成功,请通过以下操作确保这两个队列正常运行:
使用 csschedule 检查 GSE 队列。
使用 dbrig 检查警报队列。
有关运行 csschedule 和 dbrig 的说明,请参见附录 D,Calendar Server 命令行实用程序参考。
如果 csadmind 发生转储故障,请分析 pstack。
如果您在跟踪中发现任何与 GSE 相关的函数(这些函数将带有 GSE 字母),请查看 GSE 队列中的第一个条目和引用的事件数据库中的条目。通常情况下,GSE 条目中引用的事件就是违例条目。要解决此问题,请执行以下步骤:
使用 csschedule 删除 GSE 条目。
使用 cscomponents 从数据库中删除违例事件。
有关运行 csschedule 和 cscomponents 的说明,请参见附录 D,Calendar Server 命令行实用程序参考。
如果条目未损坏,则可能是日历服务器无法处理的特殊故障。
请执行以下步骤:
拍下损坏的数据库的日历环境快照,并与客户支持联系。
要创建环境备份,请执行以下步骤:
为避免服务中断,请将日历数据库临时置入只读状态,并恢复为热备份副本。
将日历数据库临时置入只读状态,以防出现添加、修改或删除事务。最终用户尝试添加、修改或删除任何日历数据时,将收到错误消息。数据库处于只读模式时,用于添加、修改或删除日历事件和待办事件的管理员工具也将不起作用。
要将日历数据库置入只读模式,请编辑 ics.conf 文件,按如下所示将指定参数设置为 "yes":
caldb.berkeleydb.readonly=”yes”
按照恢复自动备份副本中的说明,恢复为热备份副本。
配置并启用 csstored 之后,在几分钟的更新后即可使用热备份。还应当始终验证热备份副本以确保其未损坏。(运行 db_verify。)
如果所有修复操作均失败,请执行转储和重新装入过程以查看是否可以抢修数据库。
使用转储和装入过程来恢复日历数据库中介绍了此过程。
这种情况可能是由包含 Berkeley DB 数据库页面锁定的控制线程在退出时没有释放该锁定而引起的。要确认是否存在此问题,请针对 cshttpd 进程和 csadmind 运行 pstack。(pstack 是位于 /usr/bin/pstack 中的标准 UNIX 实用程序)它应当显示为获取锁定而正在等待的线程。
要解决此问题,请重新启动 Calendar Server,如下所示:
数据库循环通常是由数据库文件损坏引起的。由于是数据库损坏,因此,它是不可修复的。有以下几种选择:
恢复为热备份。
如果是最近发生的损坏,则可以使用其中一个热备份。
使用灾难归档恢复过程。
有关建议的过程,请参见恢复自动备份副本。
使用转储和重新装入过程(使用转储和装入过程来恢复日历数据库)。
本节介绍了如何使用 csdb rebuild 命令,并包含以下主题:
rebuild 命令可以扫描日历数据库并检查日历属性 (calprops)、事件和待办事件(任务),以确定是否发生了损坏。如果 rebuild 命令发现了冲突,它将在 cal_svr_base/SUNWics5/cal/sbin/rebuild_db 目录中重新建立一个日历数据库(.db 文件)。
如果未指定 -g 选项,rebuild 命令将重新建立除组调度引擎 (Group Scheduling Engine, GSE) 数据库之外的所有数据库。如果还要重新建立 GSE 数据库,请包含 -g 选项。
要确定 GSE 数据库中是否存在任何条目,请运行 csschedule -v list 命令,然后在 GSE 处理完这些条目后再运行 rebuild 命令。
以具备管理权限的用户身份登录安装了 Calendar Server 的系统。
停止 Calendar Server。
制作日历数据库的副本并将其放到 /tmp/db 目录中。
只需复制数据库 (.db) 文件和日志 (log.*) 文件。无需复制任何共享 (__db.*) 文件。
转至 cal_svr_base/SUNWics5/cal/sbin 目录。
例如,在 Solaris 操作系统上,为转到默认目录,请输入:
cd /opt/SUNWics5/cal/sbin |
如果 sbin 目录的磁盘空间不足,请在其他目录中运行 rebuild 命令。
针对日历数据库副本运行 rebuild 命令:
./csdb rebuild /tmp/db /tmp/ |
如果未指定数据库路径,rebuild 将使用当前目录。/tmp/ 参数指定了重新建立的数据库所在的目录。
如果还要重新建立 GSE 数据库,请包含 -g 选项。
rebuild 命令会生成许多信息,所以请考虑将所有输出结果(包括 stdout 和 stderr)重定向到一个文件中。
请始终使用最新的备份副本重建日历数据库。
但是,如果曾丢失大量数据,同时由于定期备份数据库而创建了多个副本,请从最新副本向最旧副本进行重建。(这样做的唯一缺点是已删除的日历组件将重新出现在重建数据库中。)
例如,如果目录 db_0601、db_0615 和 db_0629 中分别有三组备份日历数据库文件,请按以下顺序运行 rebuild 命令:
./csdb rebuild db_0629 ./csdb rebuild db_0615 ./csdb rebuild db_0601 |
rebuild 命令然后会将重新建立的数据库写入 cal_svr_base/SUNWics5/cal/sbin/rebuild_db 目录中。
运行完 rebuild 命令后,查看rebuild.out 文件中的输出结果。
如果重新建立成功,rebuild.out 文件中的最后一行应如下所示:
Calendar database has been rebuilt |
在上一步中验证重新建立成功后,将重新建立的数据库 (.db) 文件从 rebuild_db 目录复制到您的生产数据库中。
如果从已损坏的数据库中恢复了任何共享 (__db.*) 或日志 (log.*) 文件,请将它们移到其他目录中。
重新启动 Calendar Server。
以下示例显示了此命令及其生成的输出:
# ./csdb -g rebuild Building calprops based on component information. Please be patient, this may take a while... Scanning events database... 512 events scanned Scanning todos database... 34 todos scanned Scanning events database... 512 events scanned Scanning todos database... 34 todos scanned Scanning deletelog database... 15 deletelog entries scanned Scanning gse database... 21 gse entries scanned Scanning recurring database... 12 recurring entries scanned Successful components db scan Calendar database has been rebuilt Building components based on calprops information. Please be patient, this may take a while... Scanning calprops database to uncover events... 25 calendars scanned Scanning calprops database to uncover todos... 25 calendars scanned Successful calprops db scan Calendar database has been rebuilt |
以上样例输出显示了对事件和待办事件数据库扫描了两次。这不是错误。首次扫描是为了验证日历属性数据库中的信息,再次扫描是为了确保可以访问日历属性数据库。
本节包含以下主题:
使用转储和装入过程尝试恢复损坏的数据库。转储和装入过程使用 Berkeley 数据库 db_dump 和 db_load 实用程序,它们包含在 Calendar Server 的以下目录中:
cal_svr_base/SUNWics5/cal/tools/unsupported/bin |
db_dump 实用程序读取数据库文件并将数据库条目写入输出文件,使用的格式与 db_load 实用程序兼容。
要获得有关 db_dump 和 db_load 实用程序的文档,请访问 Sleepycat Software 公司的 Web 站点:
http://www.sleepycat.com/docs/utility/index.html
使用 db_dump 和 db_load 实用程序恢复数据库能否成功取决于数据库的损坏程度。可能需要使用多个 db_dump 选项才能成功恢复数据库。但如果数据库严重损坏,不可能再恢复,您可能需要恢复为最近一次完好的数据库热备份或归档备份。
在执行转储和装入过程之前,您的日历数据库必须为 Berkeley DB version 3.2.9 版本或更高版本。如果使用的是早期版本,请首先运行 cs5migrate 实用程序升级日历数据库。
要获得 cs5migrate 的最新版本,请与 Sun 技术支持联系。
以运行 Calendar Server 的用户和组(例如 icsuser 和 icsgroup)身份登录,或以超级用户 (root) 身份登录。
如果必要,请停止 Calendar Server。
使用 csbackup、Sun StorEdge Enterprise BackupTM 软件或 Legato Networker® 等实用程序备份损坏的数据库。
有关更多信息,请参阅第 17 章,备份和恢复 Calendar Server 数据。
使用 db_dump 实用程序转储每个损坏的数据库文件。
数据库文件包括 ics50calprops.db、ics50journals.db、ics50alarms.db、ics50events.db、ics50todos.db 和 ics50gse.db。
依次使用以下选项运行 db_dump,直到数据库恢复(或确定数据库无法恢复):
没有用于数据库稍微损坏的选项。
对于中等程度的数据库损坏,请使用 -r 选项。
对于严重程度的数据库损坏,请使用 -R 选项。-R 选项从损坏的数据库中转储的数据(包括不完整的记录和已删除的记录)比 -r 选项要多。
例如,运行 db_dump 时带上 -r 选项:
db_dump -r ics50events.db \> ics50events.db.txt |
使用 db_load 实用程序将输出文件装入新数据库文件。
例如:
db_load new.ics50events.db < ics50events.db.txt |
如果 db_load 报告奇数个关键字或数据条目,请编辑 db_dump 输出文件,并删除多余的关键字或数据条目。然后再次运行 db_load。
对其他损坏的数据库文件重复以上两步。
也就是,对其他损坏的数据库文件运行 db_dump。
使用 csdb rebuild 命令重新建立已恢复的数据库文件,如重建损坏的日历数据库所述。
rebuild 完成后,再次查看输出文件中的输出结果。如果重新建立成功,rebuild.out 文件中的最后一行应如下所示:
Calendar database has been rebuilt |
如果 csdb rebuild 命令失败,则使用下一个 db_dump 选项(-r 或 -R)来转储数据库。
如果即使是 db_dump 的 -R 选项也无法恢复损坏的数据库,请与 Sun Microsystems 的技术支持或销售代表联系以获得帮助。在此期间,您可能需要恢复为数据库上次完好无损的备份。
如果已使用第 10 章,配置自动备份 (csstored)中所述的自动备份功能,则可以在动态数据库损坏时使用热备份副本。
本节介绍了如何恢复两个不同的自动备份:
在恢复备份之前,请确保您已经执行了以下操作:
尝试诊断动态数据库的损坏是由哪个事务引起的。
删除或更正了引起损坏的事务,这样新的归档将不会被损坏。
通过将损坏的数据库复制到另一个目录或可移动介质中来保留它。如果要与技术支持联系,这样做是必要的。
当动态数据库损坏时,热备份应当是首选的备份。要恢复热备份,请执行以下步骤:
标识损坏的动态数据库目录中的任何未应用或为写入而打开的日志文件。
关闭为写入打开的日志。它包含最新事务。
创建新的(恢复)目录。
将当前热备份副本复制到新的恢复数据库目录中。
将 log.* 文件从损坏的动态数据库目录中复制到新的恢复数据库目录中。
如果您要保留数据库的归档副本,请将尚未应用到动态数据库的日志复制到归档目录中,这样归档备份副本就完整了。
针对新的恢复数据库运行 db_recover,同时指定 -c -h 选项。
例如,如果新的恢复目录名为 recoverydb,则命令将如下所示:
db_recover -c -h recoverydb
将 log.* 文件保留在新的恢复目录中。
db_recover 程序将日志文件应用到新的恢复数据库,但是从 4.2 版开始,Berkeley DB 要求保留这些日志文件。
针对新的恢复目录中的数据库文件运行 db_verify。
有关说明,请参见检查日历数据库的损坏。
针对新的恢复目录运行 csdb -v list。
如果新的恢复目录通过了上述全部三个恢复步骤,则损坏的旧动态数据库将替换为新的恢复数据库。
将新的动态数据库复制到热备份目录中以用作新快照。
所有新的日志都将应用到此副本中,直到拍下了下一个定期快照。
启动 Calendar Server。
如果新的恢复目录在任何一个步骤失败,则按如下所述确定未损坏的早期热备份:
如果您没有未损坏的热备份,但有归档备份及其事务日志,则可以通过执行以下步骤来恢复最近未损坏版本的已归档数据库:
标识损坏的动态数据库目录中的任何未应用或为写入而打开的日志文件。
关闭为写入打开的日志。它包含最新事务。
创建新的(恢复)目录。
将最新的归档副本及其日志文件复制到新的恢复数据库目录中。
将任何未应用的 log.* 文件从已损坏的动态数据库目录中复制到新的恢复数据库目录中。
针对新的恢复数据库运行 db_recover,同时指定 -c -h 选项。
例如,如果新的恢复目录名为 recoverydb,则命令将如下所示:
db_recover -c -h recoverydb
将 log.* 文件保留在新的恢复目录中。
db_recover 程序将日志文件应用到新的恢复数据库中,但是从 4.2 版开始,Berkeley DB 要求保留这些日志文件。
针对新的恢复目录中的数据库文件运行 db_verify。
有关说明,请参见检查日历数据库的损坏。
针对新的恢复目录运行 csdb -v list。
如果新的恢复目录通过了上述全部三个恢复步骤,则损坏的旧动态数据库将替换为新的恢复数据库。
将新的动态数据库复制到热备份目录中以用作新快照。
启动 Calendar Server。
如果新的恢复目录在任何一个步骤失败,则标识未损坏的早期归档备份,如下所述:
依次从新到旧对每个归档备份副本运行以下三个恢复程序,以找到最近一个未损坏的副本:db_recover -c-h、db_verify 和 csdb -v list。
可以将第一个找到的无损归档副本恢复到动态数据库目录中。
用未损坏的归档备份替换损坏的动态数据库,如恢复归档备份所述。
如果所有的归档备份均已损坏,请致电技术支持。
本节包括以下主题:
如果使用诸如 db_recover 之类的 Berkeley 数据库工具创建了自定义备份脚本,则在升级到 Calendar Server 后可能会发现该脚本不再工作。出现此问题的原因是早期版本的 Calendar Server 使用静态库来编译这些工具。而现在使用动态库 libdb-4.2.so 编译这些工具。
要将新的动态库与现有的自定义脚本结合使用,请设置以下全局变量,如下所示:
LD_LIBRARY_PATH=libdb-4.2.so