第 3 章管理 Calendar Server

可以通过运行命令行实用程序和编辑 ics.conf 配置文件来管理 Calendar Server。

要运行命令行实用程序，必须以管理员用户身份登录正在运行 Calendar Server 的系统。

启动和停止 Calendar Server

使用 start-cal 和 stop-cal 实用程序


注	Calendar Server 提供了 csstart 和 csstop 实用程序只是为了与其早期版本兼容。建议使用 start-cal 和 stop-cal 实用程序启动和停止 Calendar Server。

start-cal 和 stop-cal 实用程序都位于 cal_svr_base/opt/SUNWics5/cal/sbin 目录中。必须在已安装 Calendar Server 的本地计算机上运行这些实用程序。有关可能出现的问题，请参阅 start-cal 和 stop-cal 实用程序错误诊断。

enpd — 事件通知服务 (ENS)

csnotifyd — 通知服务

csadmind — 管理服务

csdwpd — 数据库有线协议 (DWP) 服务，只能通过远程 Calendar Server 数据库配置启动的分布式数据库服务

cshttpd — HTTP 服务

使用 start-cal 命令启动 Calendar Server：

以系统管理员用户身份登录。

转到 cal_svr_base/opt/SUNWics5/cal/sbin 目录。

启动 Calendar Server：

./start-cal

使用 stop-cal 命令停止 Calendar Server：

以系统管理员用户身份登录正在运行 Calendar Server 的系统。

转到 cal_svr_base/opt/SUNWics5/cal/sbin 目录。

停止 Calendar Server：

./stop-cal

start-cal 和 stop-cal 实用程序错误诊断

start-cal 实用程序无法启动所有 Calendar Server 进程。例如，start-cal 可以启动 enpd、csnotifyd 和 csadmind 进程，但无法启动 cshttpd。在这种情况下，必须先停止所有 Calendar Server 进程，然后再尝试重新启动 Calendar Server。

stop-cal 实用程序无法停止所有 Calendar Server 进程。例如，stop-cal 可以停止 cshttpd 父进程，但无法停止任何 cshttpd 子进程。在这种情况下，必须停止其余的 Calendar Server 进程。

停止 Solaris 系统上的 Calendar Server 进程：

以系统管理员用户身份登录正在运行 Calendar Server 的系统。

通过对每项服务输入 ps 命令来确定其余 Calendar Server 进程的进程 ID (PID)：

ps -elf | grep cs-process

其中，cs-process 可以是 enpd、csnotifyd、csdwpd、csadmind 或 cshttpd。例如：

ps -elf | grep cshttpd

使用正在运行的每个进程的 PID，并输入 pkill -15 命令来终止这些进程。例如：

pkill -15 9875

再次对每项服务输入 ps 命令，确保所有 Calendar Server 进程均已停止。

如果仍有 Calendar Server 进程正在运行，请输入 pkill -9 命令将其终止。例如：

pkill -9 9875


警告	在停止所有 Calendar Server 进程之后，重新启动 Calendar Server 之前，请考虑通过运行 csdb 实用程序的 check 命令来检查是否可能有日历数据库损坏情况发生。有关 check 命令的信息，请参阅检测和重建日历数据库。

配置 Calendar Server 超时值

配置 csadmind 的超时值

配置最终用户的 HTTP 超时值

配置 csadmind 的超时值

表 3-1 介绍了 ics.conf 文件中由管理服务 (csadmin) 使用的 Calendar Server 超时参数。

表 3-1 管理服务 (csadmin) 的 HTTP 超时值
参数	说明
service.admin.idletimeout	指定在 HTTP 连接空闲超时前 csadmind 服务等待的秒数。默认值为 120 秒（2 分钟）。
service.admin.resourcetimeout	指定资源日历的 HTTP 会话超时前 csadmind 服务等待的秒数。默认值为 900 秒（15 分钟）。
service.admin.sessiontimeout	指定在 HTTP 会话超时前 csadmind 服务等待的秒数。默认值为 1800 秒（30 分钟）。

配置最终用户的 HTTP 超时值

表 3-2 介绍了 ics.conf 文件中适用于最终用户的 Calendar Server HTTP 超时参数。

表 3-2 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 分钟）。

配置单一登录 (SSO)

单一登录 (SSO) 使用户只需验证一次就可以使用多个信任的应用程序，而不必多次验证。Sun ONE 通信服务器（包括 Calendar Server 和 Messaging Server）可以按以下说明实现 SSO 功能：

通过 Identity Server 配置 SSO

通过通信服务器信任环技术配置 SSO

通过 Identity Server 配置 SSO

Sun ONE 服务器（包括 Calendar Server 和 Messaging Server）可以通过使用 Sun ONE Identity Server 6.1 或更高版本来实现 SSO 功能。

Identity Server 起到 Sun ONE 服务器的 SSO 网关的作用。也就是说，用户先登录 Identity Server，然后即可访问其他 Sun ONE 服务器，只要这些服务器已经过适当配置，支持 SSO。

确保已安装和配置 Sun ONE Identity Server 和 Sun ONE Directory Server。有关安装和配置这些产品的信息，请参阅《Sun Java Enterprise System 安装指南》。

通过设置表 3-3 中的参数为 Calendar Server 配置 SSO，然后重新启动 Calendar Server 以使这些值生效。如果有必要，可以在设置每个参数时删除注释字符 (!)。

注意：设置 local.calendar.sso.amnamingurl 参数时，必须为 Identity Server 使用全限定名。

要为 Messaging Server 配置 SSO，请参阅《Sun ONE Messaging Server 6.0 管理员指南》。

用户使用他们的 Directory Server LDAP 用户名和密码登录 Identity Server。通过其他服务器（例如 Calendar Server 或 Messaging Server）登录的用户将不能使用 SSO 访问其他 Sun ONE 服务器。

登录 Identity Server 后，用户就可以使用适当的 URL，通过 Calendar Express 访问 Calendar Server。用户也可以访问其他 Sun ONE 服务器（例如 Messaging Server），只要这些服务器已经过适当配置，支持 SSO。

表 3-3 在 Identity Server 中使用 SSO 需要的 Calendar Server 配置参数
参数	说明
local.calendar.sso.amnamingurl	指定 Identity Server SSO 命名服务的 URL。默认值为 http://IdentityServer:port/amserver/namingservice 其中，IdentityServer 是 Identity Server 的全限定名，port 是 Identity Server 端口号。
local.calendar.sso.amcookiename	指定 Identity Server SSO Cookie 的名称。默认值为 iPlanetDirectoryPro。
local.calendar.sso.amloglevel	指定 Identity Server SSO 的日志级别。取值范围从 1（静音）到 5（冗余），默认值为 3。
local.calendar.sso.logname	指定 Identity Server SSO API 日志文件名。默认值为 am_sso.log。
local.calendar.sso.singlesignoff	启用 (yes) 或禁用 (no) 从 Calendar Server 到 Identity Server 的单一注销。如果启用，用户从 Calendar Server 注销的同时也将从 Identity Server 注销，而且用户通过 Identity Server 启动的任何其他会话（例如 Messaging Server Web 邮件会话）也将终止。由于 Identity Server 是验证网关，因此总是启用从 Identity Server 到 Calendar Server 单一注销。默认值为 yes。

在 Identity Server 中使用 SSO 的注意事项

只要 Identity Server 会话有效，日历会话就会有效。如果用户从 Identity Server 注销，日历会话将自动关闭（单一注销）。

SSO 应用程序必须在同一个域中。

SSO 应用程序必须可以访问 Identity Server 验证 URL（命名服务）。

浏览器必须支持 Cookie。

如果使用的是 Sun ONE Portal Server 网关，请设置以下 Calendar Server 参数：

service.http.ipsecurity="no"

render.xslonclient.enable="no"

通过通信服务器信任环技术配置 SSO

在通过通信服务器信任环技术（也就是不通过 Identity Server）配置 SSO 时，请注意以下几点：

必须配置每个信任的应用程序以支持 SSO。

如果 default.html 页面位于浏览器的缓存中，SSO 将无法正常工作。在使用 SSO 之前，确保将 default.html 页面重新装入浏览器。例如，在 Netscape Navigator 中，按住 Shift 键，然后单击“重新装入”。

SSO 只支持纯 URL，例如支持 http://servername，但不支持诸如 http://servername/command.shtml?view 之类的 URL。

表 3-4 介绍了通过通信服务器信任环技术启用 SSO 所需的 Calendar Server 配置参数。

表 3-4 通过通信服务器信任环技术启用 SSO 所需的 Calendar Server 参数
参数	说明
sso.enable = "1"	必须将此参数设置为 1（默认值）才能启用 SSO。设置为 0 将禁用 SSO。
sso.appid = "ics50"	此参数指定特定 Calendar Server 安装的唯一应用程序 ID。每个信任的应用程序也必须有一个唯一的应用程序 ID。默认值为 ics50。
sso.appprefix = "ssogrp1"	此参数指定用于格式化 SSO Cookie 的前缀值。所有信任的应用程序必须使用相同的前缀值，因为 Calendar Server 只能识别带有此前缀的 SSO Cookie。默认值为 ssogrp1。
sso.cookiedomain = ".sesta.com"	此参数使浏览器只向指定域中的服务器发送 Cookie。其值必须以句点 (.) 开头。
sso.singlesignoff = "true"	如果将此参数设置为 true（默认值），那么当客户机注销时，将清除客户机上前缀与 sso.appprefix 中配置的值相匹配的所有 SSO Cookie。
sso.userdomain = "sesta.com"	此参数设置用作用户的 SSO 验证一部分的域。
sso.appid.url = "verifyurl" 例如： sso.ics50.url = "http://sesta.com:8883/VerifySSO?" sso.msg50.url = "http://sesta.com:8882/VerifySSO?"	此参数设置 Calendar Server 配置的对等 SSO 主机的验证 URL 值。必须为每个信任的对等 SSO 主机设置一个参数，包括：应用程序 ID (appid)，标识需要遵守其 SSO Cookie 的每个对等 SSO 主机。验证 URL (verifyurl)，包括主机 URL，主机端口号以及 VerifySSO?（包括末尾处的问号 ?）。在本例中，Calendar Server 应用程序 ID 是 ics50，主机 URL 是 sesta.com，端口号是 8883。 Messenger Express 应用程序 ID 是 msg50，主机 URL 是 sesta.com，端口号是 8882。

表 3-5 介绍了通过通信服务器信任环技术启用 SSO 所需的 Messaging Server 配置参数。

表 3-5 通过通信服务器信任环技术启用 SSO 所需的 Messaging Server 参数
参数	说明
local.webmail.sso.enable = 1	必须将此参数设置为非零值才能启用 SSO。
local.webmail.sso.prefix = ssogrp1	此参数指定在格式化 HTTP 服务器设置的 SSO Cookie 时所使用的前缀。
local.webmail.sso.id = msg50	此参数指定 Messaging Server 的唯一应用程序 ID (msg50)。每个信任的应用程序也必须有一个唯一的应用程序 ID。
local.webmail.sso.cookiedomain = sesta.com	此参数指定 HTTP 服务器设置的所有 SSO Cookie 的 Cookie 域值。
local.webmail.sso.singlesignoff = 1	如果将此值设置为非零值，那么当客户机注销时，将清除客户机上前缀与 local.webmail.sso.prefix 中配置的值相匹配的所有 SSO Cookie。
local.sso.appid.url = "verifyurl" 例如： local.sso.ics50.verifyurl = http://sesta.com:8883/VerifySSO? local.sso.msg50.verifyurl = http://sesta.com:8882/VerifySSO?	此参数设置 Messaging Server 配置的对等 SSO 主机的验证 URL 值。必须为每个信任的对等 SSO 主机设置一个参数，包括以下几项：应用程序 ID (appid)，标识需要遵守其 SSO Cookie 的每个对等 SSO 主机。验证 URL (verifyurl)，包括主机 URL，主机端口号以及 VerifySSO?（包括末尾处的问号 ?）。在本例中，Messaging Server 应用程序 ID 是 msg50，主机 URL 是 sesta.com，端口号是 8882。 Calendar Server 应用程序 ID 是 ics50，主机 URL 是 sesta.com，端口号是 8883。

有关配置 Messaging Server 以启用 SSO 的详细信息，请参阅《Sun ONE Messaging Server 6.0 管理员指南》。

配置 LDAP 日历查找数据库 (CLD) 插件

LDAP CLD 插件允许通过多个后端服务器为一个日历实例分发用户和资源日历，从而为日历数据库提供了水平可伸缩性。LDAP CLD 插件使用 icsDWPHost 属性来确定日历所在的后端服务器。


注	在 Calendar Server 5.1.1 及其更高版本中，CLD 插件的主版本号由 1 更改为 2，次版本号仍然是 0。如果您已经编写好自己的 CLD 插件，则必须修改插件才能支持这个新的主版本号。

LDAP CLD 插件的工作原理

LDAP CLD 插件所需的 Calendar Server 配置

LDAP CLD 插件的工作原理

LDAP CLD 插件允许通过多个后端服务器分发日历数据库。数据库中的每个日历都由一个唯一的日历 ID (calid) 标识，其格式如下：

userid 是 Calendar Server 实例的唯一用户 ID。

domain 是用户的可选域名。

calendar-name 是特定用户的唯一可选日历名。

当 Calendar Express 最终用户访问日历时，LDAP CLD 插件先从日历的 calid 中提取 userid，然后在 LDAP 服务器数据库中查找日历的属主。

找到日历的属主后，插件将使用属主的 icsDWPHost LDAP 属性确定日历所在的后端服务器的主机名。此主机名必须能够被域名服务 (DNS) 解析成有效的 IP 地址。

Calendar Server 使用此主机名和数据库有线协议 (DWP) 访问后端服务器上的日历数据。DWP 是一个内部协议，作为 csdwpd 服务运行，为日历数据库提供网络连接功能。

Calendar Server 使用 DWP 将日历数据发送到用户登录的服务器，然后由 Calendar Express 将这些数据呈现在最终用户的浏览器中。



注	如果您的站点正在使用 LDAP CLD 插件，那么当您使用 cscal 实用程序创建新日历时，必须在用户的日历所驻留（或将要驻留）的同一后端服务器上创建新日历，正如用户的 icsDWPHost LDAP 属性所说明的那样。如果试图在不同的后端服务器上创建日历，Calendar Server 将返回一条错误信息。有关详细信息，请参阅 cscal。

LDAP CLD 插件所需的 Calendar Server 配置

多个前端服务器与多个后端服务器

多个前端/后端服务器

正在运行相同版本的 Solaris 操作系统。

正在运行相同版本的 Calendar Server，包括修补程序。

为 DWP 端口使用相同的端口号（由 service.dwp.port 参数设置）。默认端口号为 59779。

多个前端服务器与多个后端服务器

下图显示了正在运行一个 Calendar Server 实例的两个前端服务器和两个后端服务器。如果需要，还可以配置更多的前端服务器或后端服务器。

此配置通过防火墙限制对 LDAP 和日历数据库的访问，从而保护服务器。日历数据库分布到两个后端服务器上。

前端服务器属于 CPU 密集型，大部分 CPU 时间都用于为最终用户呈现日历数据。后端服务器属于磁盘密集型，大部分 CPU 时间用于访问日历数据库。

配置前端服务器

要配置前端服务器，请在每个前端服务器上设置 ics.conf 文件中的以下参数。

启用日历数据库查找插件：

csapi.plugin.calendarlookup = "y"

指定 Calendar Server 装入所有插件：

csapi.plugin.calendarlookup.name = "*"

设置 LDAP CLD 插件的日历查找插件的类型：

caldb.cld.type = "directory"

设置 DWP 服务的端口号 (csdwpd)：

service.dwp.port = "59779"

默认值为 59779。配置的所有前端服务器和后端服务器都必需具有相同的端口号。

为配置中的每个后端服务器设置服务器名：

caldb.dwp.server.backend-server-1.ip = "backend-server-1"
caldb.dwp.server.backend-server-2.ip = "backend-server-2"
...
caldb.dwp.server.backend-server-n.ip = "backend-server-n"

服务器名必须是全限定名称，且必须能够被域名服务 (DNS) 解析成有效的 IP 地址。服务器名在参数的每个部分中都必须保持一致，并且是全限定名称。例如：

caldb.dwp.server.calendar.sesta.com.ip = "calendar.sesta.com"

同时，服务器名必须与适用的日历属主的 icsDWPHost LDAP 属性使用的名称相匹配。

设置默认的 DWP 服务器名：

caldb.dwp.server.default = "server-name"

如果 LDAP 服务器数据库中的用户或资源条目没有 icsDWPHost 属性，则其中的 server-name 是 Calendar Server 使用的全限定默认服务器名。此名称必须能够被域名服务 (DNS) 解析成有效的 IP 地址例如：

caldb.dwp.server.default = "calendar.sesta.com"

重新启动 Calendar Server 使上述更改生效。

前端服务器的配置参数示例

以下示例显示一个前端服务器与两个后端服务器（名为 calendar.sesta.com 和 calendar.siroe.com）的配置参数。默认 DWP 服务器是 calendar.sesta.com。

配置后端服务器

要配置后端服务器，请在每个前端服务器上设置 ics.conf 文件中的以下参数。

启用 DWP 服务 (csdwpd)，并设置 DWP 端口号：

service.dwp.enable = "y"
service.dwp.port = "59779"

默认端口号为 59779。配置的所有前端服务器和后端服务器都必需具有相同的端口号。

由于后端服务器不需要 HTTP 服务，因此请禁用该服务（应将管理服务设置为默认值 yes）：

service.http.enable = "no"
service.admin.enable = "yes"

设置 LDAP CLD 插件的日历查找插件的类型：

caldb.cld.type = "local"

由于后端服务器不需要查找任何日历数据，因此请将 csapi.plugin.calendarlookup 设置为 n：

csapi.plugin.calendarlookup = "n"

重新启动 Calendar Server 使上述更改生效。

后端服务器的配置参数示例

多个前端/后端服务器

下图显示了三个前端服务器和三个后端服务器，其中的每个服务器都连接一个日历数据库。此配置允许将日历分发到不同的地理位置，每个日历都驻留在其属主登录 Calendar Server 的服务器上。

配置前端/后端服务器

要配置前端/后端服务器，请在每个服务器上设置 ics.conf 文件中的以下参数。

启用 DWP 服务 (csdwpd)：

service.dwp.enable = "y"

设置 DWP 服务的端口号 (csdwpd)：

service.dwp.port = "59779"

默认值为 59779。配置的所有前端服务器和后端服务器都必需具有相同的端口号。

启用日历查找插件：

csapi.plugin.calendarlookup = "y"

指定 Calendar Server 装入所有插件：

csapi.plugin.calendarlookup.name = "*"

指定 Calendar Server 使用的日历查找插件的类型：

caldb.cld.type = "directory"

设置默认的 DWP 服务器名：

caldb.dwp.server.default = "server-name"

如果 LDAP 服务器数据库中的用户或资源条目没有 icsDWPHost 属性，则其中 server-name 是 Calendar Server 使用的全限定默认服务器名。此名称必须能够被域名服务 (DNS) 解析成有效的 IP 地址。例如：

caldb.dwp.server.default = "calendar.sesta.com"

为配置中的所有前端/后端服务器（包括本地服务器）设置服务器名：

caldb.dwp.server.server-1.ip = "server-1"
caldb.dwp.server.server-2.ip = "server-2"
...
caldb.dwp.server.server-n.ip = "server-n"

caldb.dwp.server.calendar.sesta.com.ip = "calendar.sesta.com"

同时，服务器名必须与适用的日历属主的 icsDWPHost LDAP 属性使用的名称相匹配。

重新启动 Calendar Server 使上述更改生效。

每个前端/后端服务器的配置参数示例

以下示例显示每个前端/后端服务器的配置参数。这些服务器包括 sesta.com、siroe.com 和 varrius.com。默认 DWP 服务器是 sesta.com。

维护前端服务器与后端服务器之间的安全

前端服务器使用数据库有线协议 (DWF) 与后端服务器通信。由于 DWP 使用 HTTP 作为传输机制，因此，Calendar Server 6.0 使用表 3-6 和表 3-7 中的配置参数对前端服务器和后端服务器之间的 DWP 连接进行验证。

这些参数都是可选的，并且默认情况下不包括在 ics.conf 文件中。要使用 DWP 连接验证，必须在每个前端服务器和后端服务器上将所需的参数添加到 ics.conf 文件中。

表 3-6 用于 DWP 连接验证的后端配置参数
参数	说明
service.dwp.admin.userid	在后端服务器上，指定用来对 DWP 连接进行验证的用户 ID。如果后端服务器不指定用户 ID，则不执行验证。
service.dwp.admin.cred	在后端服务上，指定用来对 DWP 连接进行验证的密码。如果后端服务器不指定密码，则不执行验证。

表 3-7 用于 DWP 连接验证的前端配置参数
参数	说明
caldb.dwp.server.back-end-server.admin	在前端服务器上，指定用来对到后端服务器的 DWP 连接进行验证的用户 ID。其中的 back-end-server 是服务器的名称。
caldb.dwp.server.back-end-server.cred	在前端服务器上，指定用来对到后端服务器的 DWP 连接进行验证的用户密码。其中的 back-end-server 是服务器的名称。

要设置前端服务器与后端服务器之间的 DWP 连接验证，请执行以下操作：

在每个前端服务器上的 ics.conf 文件中添加以下参数：

caldb.dwp.server.back-end-server.admin = "userid"
caldb.dwp.server.back-end-server.cred = "password"

其中，back-end-server 是后端服务器的名称，userid 和 password 分别是您希望 Calendar Server 用来验证连接的用户 ID 和密码。

在 back-end-server 代表的每个后端服务器上的 ics.conf 文件中添加以下参数：

service.dwp.admin.userid = "userid"
service.dwp.admin.cred = "password"

其中，userid 和 password 与在前端服务器上指定的用户 ID 和密码相同。

当前端服务器首次连接到后端服务器时，它将发送在以上参数中指定的用户 ID 和密码。后端服务器将查这些参数，如果两个参数都匹配，则验证成功。后端服务器然后向前端服务器发送会话 ID。前端服务器在对后端服务器执行的后续 DWP 命令中使用该会话 ID。

重新启动了后端服务器。

由于两个服务器之间没有活动而导致该会话过期。

如果有多个前端服务器和多个后端服务器，则可以对每个服务器使用相同的用户 ID 和密码。

如果后端服务器没有在此参数中指定用户 ID 和密码，则不执行验证。

改进 LDAP CLD 插件的性能

要改进带有 LDAP CLD 插件的 Calendar Server 的性能，请确保将以下配置参数设置为 yes（每个参数的默认值）：

caldb.cld.cache.enable 启用 CLD 缓存选项。此选项用于存储日历用户的 DWP 主机服务器信息（icsDWPHost LDAP 属性），从而减少对 LDAP 目录服务器的调用。

service.calendarsearch.ldap 指定使用 LDAP 或用户的首选插件完成日历搜索。

清除 CLD 缓存

如果正在使用 CLD 缓存选项，更新 ics.conf 参数的服务器名或将日历移至不同的后端服务器后，应清除 CLD 缓存以删除该服务器名。CLD 缓存中的旧条目会导致前端服务器无法正确连接到后端服务器，或导致 Calendar Server 无法找到移动后的日历。

停止 Calendar Server。

删除 cal_svr_base/var/opt/SUNWics5/csdb/cld_cache 目录中的所有文件，但不要删除 cld_cache 目录本身。

重新启动 Calendar Server。

将日历移至不同的后端服务器

要将用户或资源日历从一个后端服务器移至其他后端服务器，请执行以下操作：

在原始服务器上，使用 csuser 实用程序禁用用户日历的日历用户，或使用 csresource 实用程序禁用资源日历的日历用户。例如，禁用用户 ID 和 calid 为 bkamdar 的用户：

csuser disable bkamdar

在原始服务器上，使用 csexport 实用程序将日历从日历数据库导出到某个文件中。例如：

csexport -c bkamdar calendar bkamdar.ics

如果用户有多个日历，则必须对每个日历执行此操作。

将导出的日历文件 (*.ics) 从原始服务器复制到新服务器上。

在新服务器上，使用 csimport 实用程序将此文件中的日历导入到日历数据库中。例如：

csimport -c bkamdar calendar bkamdar.ics

同样，必须对导出的每个日历重复执行此操作。

在 LDAP 目录服务器上，使用 csattribute 实用程序更新日历属主的 icsDWPHost LDAP 属性，以指向新的后端服务器。要更新属性，必须先删除该属性，然后再添加它并为其指定新值。例如，要将新服务器名设置为 sesta.com：

csattribute -a icsDWPHost delete bkamdar
csattribute -a icsDWPHost=sesta.com add bkamdar

在新服务器上，使用 csuser 实用程序禁用用户日历的日历用户，或使用 csresource 实用程序禁用资源日历的日历用户。例如：

csuser enable bkamdar

在新服务器上，使用以下命令验证这些属性是否正确以及是否正确移动了每个日历。例如：

cscal -v -o bkamdar list bkamdar
...
csattribute -v list bkamdar

在原始服务器上，删除刚刚移动的每个日历。例如：

cscal -o bkamdar delete bkamdar

-o 选项将删除主要属主为 bkamdar 的所有日历。

管理 LDAP 属性

要管理 Calendar Server 使用的 LDAP 属性，请使用 csattribute 实用程序。

列出 LDAP 属性


注	如果您的站点正在使用 LDAP CLD 插件，请不要通过使用 csattribute 来修改 icsDWPHost 属性以指定新的后端主机服务器。修改 icsDWPHost 并不会在新的后端主机上创建新日历。有关详细信息，请参阅配置 LDAP 日历查找数据库 (CLD) 插件。

要列出用户或资源的 LDAP 属性，请使用 csattribute 实用程序的 add 命令。例如，要列出用户 TChang 的 LDAP 属性：

添加 LDAP 属性

要添加 LDAP 服务器属性，请使用 csattribute 实用程序的 add 命令。例如，要为用户 TChang 添加值为 Conference_Schedule 的 LDAP 属性 icsCalendar：

删除 LDAP 属性

要删除 LDAP 服务器属性，请使用 csattribute 实用程序的 delete 命令。例如，要从 TChang 删除 LDAP 属性 icsCalendar：

管理组计划引擎 (GSE) 队列

组计划使 Calendar Server 用户可以创建诸如会议之类的事件，并邀请其他参与者。通过使用空闲/繁忙查找功能，用户可以确定被邀请者能够参与事件的确切时间。

如果参与者也在同一个 Calendar Server 上，则会在其日历上安排此事件。如果参与者不在同一个 Calendar Server 上，则会通过电子邮件向其发送邀请。参与者既可接受邀请，也可拒绝邀请。

Calendar Server 用户也可以通过并行查看参与者的日历来比较组计划。

要管理 GSE 队列中的条目，请使用 csschedule 实用程序。必须在已安装 Calendar Server 的本地计算机上运行 csschedule。

列出 GSE 队列中的条目

要列出 GSE 队列中的条目，请使用 csschedule 实用程序的 list 命令。例如，要列出 GSE 队列中的所有条目：

要列出 GSE 队列中带有 calid Holiday_Schedule 的日历中的所有条目：

删除 GSE 队列中的条目

要删除 GSE 队列中的条目，请使用 csschedule 实用程序的 delete 命令。例如，要删除 GSE 队列中的所有条目：

要从 GSE 队列的 calA 日历中删除首次计划时间为 2001 年 11 月 30 日 13:30:45，偏移数为 1，唯一标识符为 1111，周期 ID 为 0，序列号为 0 的条目：

监视 Calendar Server

要监视 Calendar Server 活动，请使用 csmonitor、csstats 和 cstool 实用程序。本节介绍以下任务：

列出计数器统计信息

监视 Calendar Server 日志文件

列出计数器统计信息

csstats 实用程序显示日历配置文件 (counter.conf) 中定义的计数器对象的统计信息。计数器对象（例如 httpstat、authstat、wcapstat 或 dbstat）显示 Calendar Server 的以下信息：

最大并行连接数目和连接总数目

成功和失败的登录与连接的总数目

数据库读取、写入和删除的数目

要列出统计信息，请使用 csstats 实用程序的 list 命令。例如，要显示计数器对象的基本信息和可用类型：

要列出 wcapstat 计数器对象在 1 小时内每 10 秒钟的统计信息：

监视 Calendar Server 日志文件

每个 Calendar Server 服务都将状态信息写入它的日志文件。每个日志文件都根据其相关的服务名命名，如表 3-8 所示：

表 3-8 Calendar Server 日志文件
服务名	日志文件名
管理服务 (csadmind)	admin.log
分布式数据库服务 (csdwpd)	dwp.log
HTTP 服务 (cshttpd)	http.log
通知服务 (csnotifyd)	notify.log

Calendar Server 日志文件存储在 Solaris 系统上的以下默认目录中：

根据配置的时间和大小限制，每个日志文件将回滚为具有新名称的新文件，如下所示：

日志事件严重级别

Calendar Server 为日志文件中报告的事件提供了 8 种严重级别，如表 3-9 所示。

表 3-9 Calendar Server 日志错误严重级别
严重级别	含义
EMERGENCY	系统不可用。此级别表示最严重（最危险）的事件。
ALERT	必须立即采取措施。
CRITICAL	表示处于危险状态。
ERROR	表示处于错误状态。
WARNING	表示处于警告状态。
NOTICE	正常，但处于重要状态。这是每个日历服务的默认报告级别。
INFORMATION	表示提示性信息。
DEBUG	表示调试级别的信息。

一个日志事件通过一行内容表示，其中显示相关的时间标记、服务器主机名、严重级别、进程名（进程 ID）、事件类型、优先级和说明。可以通过修改 ics.conf 文件中的某些配置设置，指定 Calendar Server 在日志文件中报告的事件的严重级别。有关信息，请参阅日历日志信息配置。

应该定期查看日志文件，了解系统是否发生了 EMERGENCY、ALERT、CRITICAL、ERROR 和 WARNING 级别的错误，如果发现这些错误，请检查这些事件以找出 Calendar Server 操作可能出现的问题。在 Calendar Server 的正常操作过程中，系统会生成 NOTICE 和 INFORMATION 级别的日志事件，以帮助您监视服务器活动。


注	在请求 Calendar Server 技术支持时，可能需要您提供日志文件以协助解决问题。

强制回应 Calendar Server

要验证 Calendar Server 服务是否正在侦听指定的端口号，请使用 cstool 实用程序的 ping 命令。强制回应服务无法验证该服务是否正在运行，但可以表明该服务是否可以接受套接连接。

http — HTTP 服务 (cshttpd)

admin — 管理服务 (csadmind)



注	在当前发行版中，不能强制回应 DWP 服务 (csdwpd)、事件通知服务 (enpd) 或通知服务 (csnotifyd)。

例如，要强制回应主机名为 calserver 的计算机以查看 cshttpd 服务是否正在侦听端口 80：

默认情况下，cstool 等待响应的时间为 120 秒，但您可以使用 -t timeout 选项更改此值。

刷新 Calendar Server 配置

在当前发行版中，请不要使用 cstool refresh 命令刷新配置。应使用 stop-cal 和 start-cal 命令。有关详细信息，请参阅启动和停止 Calendar Server。