Sun ONE logo     上一章     目录     索引     下一章     
Sun ONE Calendar Server 管理员指南



第 3 章   管理 Calendar Server


本章介绍如何配置和管理 Sun™ ONE Calendar Server。

本章包含以下几节:

您可以通过运行命令行公用程序,或者编辑 ics.conf 配置文件来管理 Calendar Server。

要运行命令行公用程序,请在运行 Calendar Server 的系统上使用具有管理权限的用户身份登录。

有关更多信息,请参见第 7 章 “Calendar Server 命令行公用程序”第 8 章 “Calendar Server 配置”


启动和停止 Calendar Server

可以通过以下方式启动和停止 Calendar Server:



备注 Calendar Server 所提供的 csstartcsstop 公用程序只是为了与早期版本兼容。建议使用 start-calstop-cal 命令来启动和停止 Calendar Server。



使用 start-cal 和 stop-cal 命令

start-calstop-cal 公用程序位于 server-root/cal/bin 目录中。必须在安装 Calendar Server 的本地机器上运行这些公用程序。有关可能出现的问题,请参见“start-cal 和 stop-cal 命令疑难解答”

start-cal 命令会以下列顺序启动 Calendar Server 的服务:

  1. enpd-事件通知服务 (ENS)

  2. csnotifyd-通知服务

  3. csadmind-管理服务

  4. csdwpd-数据库连线协议 (DWP) 服务,此分布式数据库服务只有在远程 Calendar Server 数据库配置下才会启动

  5. cshttpd-HTTP 服务

有关这些服务的说明,请参见“Calendar Server 服务”


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

  1. 使用拥有系统管理权限的用户身份登录。

  2. 定位到 server-root/cal/bin 目录。例如,在 Solaris 系统上:

    cd /opt/SUNWics5/cal/bin

  3. 启动 Calendar Server:

    ./start-cal


使用 stop-cal 命令停止 Calendar Server:
  1. 请使用具有管理权限的用户登录到运行 Calendar Server 的系统。

  2. 定位到 server-root/cal/bin 目录。例如,在 Solaris 系统上:

    cd /opt/SUNWics5/cal/bin

  3. 停止 Calendar Server:

    ./stop-cal

使用 Windows NT 控制面板

在 Windows NT 系统上,使用“控制面板”中的“服务”对话框。


使用 Windows NT“控制面板”启动或停止 Calendar Server:

  1. 使用拥有 Windows NT 系统管理权限的用户身份登录。

  2. 显示“控制面板”中的“服务”对话框:

    开始>设置>控制面板>服务

  3. 在“服务”对话框中,单击特定的 Calendar Server 服务(Admin、DWP、HTTP、ENS 或 Notification),然后单击“启动”或“停止”。

有关更多信息,请参考 Windows NT 联机帮助。

start-cal 和 stop-cal 命令疑难解答

在启动和停止 Calendar Server 时,可能会出现以下问题:

  • start-cal 命令没有启动所有的 Calendar Server 进程。例如,start-cal 可能启动了 enpdcsnotifydcsadmind 进程,但没有启动 cshttpd。在这种情况下,您必须停止所有 Calendar Server 进程,然后尝试重新启动 Calendar Server。

  • stop-cal 命令没有停止所有的 Calendar Server 进程。例如,stop-cal 可能只停止了 cshttpd 父进程,但没有停止任何 cshttpd 子进程。在这种情况下,您必须停止其余的 Calendar Server 进程。


在 Windows NT 系统上停止 Calendar Server 进程:
  1. 请使用具有管理权限的用户登录到运行 Calendar Server 的系统。

  2. 使用任务管理器找出任何其余的 Calendar Server 进程,并加以停止。


在 Solaris 和其他 UNIX 系统上停止 Calendar Server 进程:
  1. 请使用具有管理权限的用户登录到运行 Calendar Server 的系统。

  2. 对每个服务输入 ps 命令,确定其余 Calendar Server 进程的进程 ID (PID):

    ps -elf | grep cs-process

    其中,cs-process 表示 enpdcsnotifydcsdwpdcsadmindcshttpd
    例如:

    ps -elf | grep cshttpd

  3. pkill -15 命令后输入每个仍在运行的进程 PID,以终止该进程。
    例如:

    pkill -15 9875

  4. 每次终止进程后可重新输入 ps 命令,确保所有 Calendar Server 进程都已停止。

    如果某个 Calendar Server 进程仍在运行,请输入 pkill -9 命令来终止该进程。
    例如:

    pkill -9 9875



    警告

    在停止所有 Calendar Server 进程后、重新启动 Calendar Server 之前,请尝试运行 csdb 公用程序的 check 命令,检查任何可能发生的日历数据库损坏。

    有关 check 命令的信息,请参见“检查和重建日历数据库”




配置 Calendar Server 超时值

有关编辑 ics.conf 参数的信息,请参见“编辑 ics.conf 配置文件”

配置 csadmind 的超时值

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


表 3-1    管理服务 (csadmin) 的 HTTP 超时值

参数

说明

service.admin.idletimeout  

指定 csadmind 服务在使空闲的 HTTP 连接超时前等待的秒数。

默认值是 120 秒(即 2 分钟)。  

service.admin.resourcetimeout  

指定 csadmind 服务在使资源日历的 HTTP 会话超时前等待的秒数。

默认值是 900 秒(即 15 分钟)。  

service.admin.sessiontimeout  

指定 csadmind 服务在使 HTTP 会话超时前等待的秒数。

默认值是 1800 秒(即 30 分钟)。  

配置最终用户的 HTTP 超时值

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


表 3-2    ics.conf 中最终用户(cshttpd 服务)的 HTTP 超时值

参数

说明

service.http.idletimeout  

指定 cshttpd 服务在使空闲 HTTP 连接超时前等待的秒数。

默认值是 120 秒(即 2 分钟)。  

service.http.resourcetimeout  

指定 cshttpd 服务在使资源日历的 HTTP 会话超时前等待的秒数。

默认值是 900 秒(即 15 分钟)。  

service.http.sessiontimeout  

指定 cshttpd 服务在使 HTTP 会话超时前等待的秒数。

默认值是 1800 秒(即 30 分钟)。  


配置单次登录 (SSO)

单次登录 (SSO) 使用户只需进行一次身份验证,即可使用多个可信应用程序,无需再次进行身份验证。例如,如果 Messenger Express 和 Calendar Express 都支持 SSO,则用户在登录到 Messenger Express 后,无需再次进行身份验证就可以使用 Calendar Express。

配置 SSO 时需注意以下几点:

  • 每个可信应用程序都必须配置了 SSO。

  • 如果 default.html 页在浏览器的缓存中,则 SSO 将无法正常工作。在使用 SSO 之前,请确保在浏览器中刷新 default.html 页。例如,在 Netscape Navigator 中,按住 Shift 键,然后单击“刷新”。

  • SSO 只适用于不带参数的 URL。例如,SSO 适用于 http://servername,而不适用于 http://servername/command.shtml?view 这类的 URL。

以下示例显示了 sesta.com 域的 Calendar Server (Calendar Express) 和 Messaging Server (Messenger Express) SSO 配置。


配置单次登录 (SSO):

  1. 使用拥有管理员权限的用户身份登录。

  2. 停止 Calendar Server 和 Messaging Server。

  3. 表 3-3 中的说明编辑 Calendar Server 的 ics.conf 文件。(有关 Calendar Server SSO 配置参数的说明,请参见“单次登录 (SSO) 配置”。)

表 3-3 说明 Calendar Server 的 SSO 配置参数。


表 3-3    Calendar Server 的单次登录 (SSO) 配置参数 

参数

说明

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。  

  1. 使用 configutil 设置表 3-4 中显示的 Messaging Server 配置参数。这些参数不必用双引号 (") 括起来。


表 3-4    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。  

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。  

  1. 重新启动 Calendar Server 和 Messaging Server 以更新配置。

    有关更多信息,请参见启动和停止 Calendar Server。有关 Messaging Server 的信息,请参见《Sun ONE Messaging Server 管理员指南》。


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

Calendar Server 提供以下日历查找数据库 (CLD) 插件:



备注 Calendar Server 提供了 CLD 算法插件,以便与旧版本兼容。但是,新的 LDAP CLD 插件和接口与 CLD 算法插件不兼容。Sun 建议您于分布式日历数据库使用新的 LDAP CLD 插件,而不是使用较早的 CLD 算法插件。



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

LDAP CLD 插件允许将单个日历实例的用户和资源日历分布在多个后端服务器上,从而为日历数据库提供了横向可伸缩性。LDAP CLD 插件使用 icsDWPHost 属性来确定日历所在的后端服务器。



备注 在 Calendar Server 5.1.1 版中,CLD 插件的主要版本号已从 1 变为2。次要版本号仍然为 0。如果您自己编写了 CLD 插件,则必须对该插件进行修改,使其支持这个新的主要版本号。



本节介绍以下主题:

LDAP CLD 插件的工作机制

LDAP CLD 插件允许将日历数据库分布在许多后端服务器上。数据库中的每个日历由一个唯一的日历 ID (calid) 标识,其格式如下:

userid[:calendar_name]

其中:

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

  • calendar_name 是可选的日历名称,该名称是特定用户所特有的。

Calendar Server 会按以下方式访问后端服务器上的日历数据:

  1. 当 Calendar Express 最终用户访问日历时,LDAP CLD 插件会从日历的 calid 中提取 userid,然后在 LDAP 服务器数据库中查找日历所有者。

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

  3. Calendar Server 可利用该主机名通过分布式连线协议 (DWP) 访问后端服务器上的日历数据。DWP 是一个内部协议,它会以 csdwpd 服务的形来运行,并为日历数据库提供联网功能。

  4. Calendar Server 可使用 DWP 将日历数据发送到用户登录到的服务器,然后 Calendar Express 会将数据呈现在最终用户的浏览器中。



备注 如果您的站点使用的是 LDAP CLD 插件并使用 cscal 公用程序创建新日历,则必须在用户日历所驻留(或将驻留)并由用户的 icsDWPHost LDAP 属性所指示的同一后端服务器上创建新日历。如果试图在其他后端服务器上创建日历,则 Calendar Server 将返回一个错误。

有关更多信息,请参阅“cscal”



Calendar Server 的 LDAP CLD 插件配置

LDAP CLD 插件支持以下的 Calendar Server 配置:

在这些配置中,每个前端服务器和后端服务器都必须满足下列要求:

  • 运行的操作系统必须相同:Solaris™ 操作环境、Windows NT 或 HP-UX。

  • 所使用的 DWP 端口号(service.dwp.port 参数)必须相同。默认端口号为 9779。

多个前端服务器与多个后端服务器
下图显示运行单个 Calendar Server 实例的两个前端服务器和两个后端服务器。如果愿意,您也可以配置两个以上的前端或后端服务器。

此配置可以使服务器受到防火墙的保护,以限制对 LDAP 和日历数据库的访问。日历数据库分布在两个后端服务器上。

前端服务器的 CPU 使用率较高,因为其中大部分 CPU 时间都用于呈现最终用户的日历数据上。后端服务器的磁盘使用率较高,因为其中大部分 CPU 时间都用于访问日历数据库上。

图 3-1    多个前端服务器与多个后端服务器


Calendar Server 配置多个前端服务器与多个后端服务器


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

  1. 启用日历数据库查找插件:

    csapi.plugin.calendarlookup = "y"

  2. 指定 Calendar Server 载入所有插件:

    csapi.plugin.calendarlookup.name = "*"

  3. 设置 LDAP CLD 插件的日历查找插件类型:

    caldb.cld.type = "directory"

  4. 设置 DWP 服务 (csdwpd) 的端口号:

    service.dwp.port = "9779"

    默认值为“9779”。所有已配置的前端和后端服务器的端口号必须相同。

  5. 设置该配置中每个后端服务器的服务器名称:

    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 属性使用的名称相匹配。

  6. 设置默认的 DWP 服务器名称:

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

    其中 server-name 是在 LDAP 服务器数据库中的用户或资源项没有 icsDWPHost 属性时,Calendar Server 所使用的完全限定默认服务器名称。您的域名服务 (DNS) 必须能将此名称解析成有效的 IP 地址。例如:

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

  7. 重新启动 Calendar Server 以使更改生效。


前端服务器配置参数示例
以下示例显示一个前端服务器和两个后端服务器(名称分别为 calendar.sesta.comcalendar.siroe.com)的配置参数。默认的 DWP 服务器为 calendar.sesta.com

代码示例 3-1    前端服务器的 LDAP CLD 配置参数


service.dwp.port = "9779"
csapi.plugin.calendarlookup = "y"
csapi.plugin.calendarlookup.name = "*"
caldb.cld.type = "directory"
! Default DWP server
caldb.dwp.server.default = "calendar.sesta.com"
! Back-end servers
caldb.dwp.server.sesta.com.ip = "calendar.sesta.com"
caldb.dwp.server.siroe.com.ip = "calendar.siroe.com"


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

  1. 启用 DWP 服务 (csdwpd) 并设置 DWP 端口号:

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

    默认端口号为“9779”。所有已配置的前端和后端服务器的端口号必须相同。

  2. 禁用 HTTP 服务,因为后端服务器上不需要它(应将管理服务设置为默认值 "yes"):

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

  3. 设置 LDAP CLD 插件的日历查找插件类型:

    caldb.cld.type = "directory"

  4. csapi.plugin.calendarlookup 设置为 "n",因为后端服务器不需要查找任何日历数据:

    csapi.plugin.calendarlookup = "n"

  5. 重新启动 Calendar Server 以使更改生效。


后端服务器配置参数示例
以下示例显示后端服务器的配置参数。

代码示例 3-2    后端服务器的 LDAP CLD 配置参数


service.dwp.enable = "y"
service.dwp.port = "9779"
service.http.enable = "no"
service.admin.enable = "yes"
caldb.cld.type = "directory"
csapi.plugin.calendarlookup = "n"

多个前端/后端服务器
下图显示三个前端/后端服务器,其中每个服务器皆与一个日历数据库相连。此配置允许日历分布于不同的地理区域,每个日历都在其所有者登录到 Calendar Server 时所在的服务器上。

图 3-2    多个前端/后端服务器


Calendar Server 配置多个前端/后端服务器


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

  1. 启用 DWP 服务 (csdwpd):

    service.dwp.enable = "y"

  2. 设置 DWP 服务 (csdwpd) 的端口号:

    service.dwp.port = "9779"

    默认值为“9779”。所有已配置的前端和后端服务器的端口号必须相同。

  3. 启用日历查找插件:

    csapi.plugin.calendarlookup = "y"

  4. 让 Calendar Server 载入所有插件:

    csapi.plugin.calendarlookup.name = "*"

  5. 指定 Calendar Server 应使用的日历查找插件类型:

    caldb.cld.type = "directory"

  6. 设置默认的 DWP 服务器名称:

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

    其中 server-name 是在 LDAP 服务器数据库中的用户或资源项没有 icsDWPHost 属性时,Calendar Server 所使用的完全限定默认服务器名称。您的域名服务 (DNS) 必须能将该名称解析成有效的 IP 地址。例如:

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

  7. 设置该配置中所有前端/后端服务器的服务器名称(包括本地服务器):

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

    服务器名称必须是完全限定的,并且可以由您的域名服务 (DNS) 解析成有效的 IP 地址。在每个参数部分中,服务器名称必须完全一致并且是完全限定的。
    例如:

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

    服务器名称还必须与可用的日历所有者的 icsDWPHost LDAP 属性使用的名称相匹配。

  8. 重新启动 Calendar Server 以使更改生效。


每个前端/后端服务器的配置参数示例
以下示例显示每个前端/后端服务器的配置参数。这些服务器包括 sesta.comsiroe.comvarrius.com。默认的 DWP 服务器为 sesta.com

代码示例 3-3    每个前端/后端服务器的 LDAP CLD 配置参数


service.dwp.enable = "y"
service.dwp.port = "9779"
csapi.plugin.calendarlookup = "y"
csapi.plugin.calendarlookup.name = "*"
caldb.cld.type = "directory"
! Default DWP server
caldb.dwp.server.default = "calendar.sesta.com"
! Back-end servers
caldb.dwp.server.calendar.sesta.com.ip = "calendar.sesta.com"
caldb.dwp.server.calendar.siroe.com.ip = "calendar.siroe.com"
caldb.dwp.server.calendar.varrius.com.ip = "calendar.varrius.com"

提高 LDAP CLD 插件的性能

为提高 Calendar Server LDAP CLD 插件的性能,请确保将以下配置参数设置为“yes”(即每个参数的默认值):

  • caldb.cld.cache.enable 可以启用 CLD 缓存选项。此选项存储日历用户的 DWP 主机服务器信息(即 icsDWPHost LDAP 属性),从而减少了对 LDAP 目录服务器的调用次数。

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

清除 CLD 缓存

如果您正在使用 CLD 缓存选项并且已更新 ics.conf 参数的服务器名称或已将日历移到其他后端服务器,则应清除 CLD 缓存以移除服务器名称。CLD 缓存中的过期项会阻止前端服务器与正确的后端服务器建立连接或者在移动日历后导致 Calendar Server 无法找到该日历。

要清除 CLD 缓存,请遵循以下步骤:

  1. 停止 Calendar Server。

  2. 移除 server-root/var/csdb/cld_cache 目录中的所有文件,但不要移除 cld 缓存目录本身。

  3. 重新启动 Calendar Server。

将日历移到其他后端服务器

若要将用户日历或资源日历从一个后端服务器移到另一个后端服务器,请遵循以下步骤:

  1. 在原始服务器上,使用用户日历的 csuser 公用程序或资源日历的 csresource 禁用日历用户。例如,若要禁止用户 ID 和 calid bkamdar 的用户,请执行以下命令:

    csuser disable bkamdar

  2. 在原始服务器上,使用 csexport 公用程序将日历从日历数据库导出到文件。
    例如:

    csexport -c bkamdar calendar bkamdar.ics

    如果用户具有多个日历,则必须对每个日历执行该步骤。

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

  4. 在新服务器上,使用 csimport 公用程序将该文件中的日历导入日历数据库。
    例如:

    csimport -c bkamdar calendar bkamdar.ics

    同样,对于所导出的每个日历都必须执行该步骤。

  5. 在 LDAP 目录服务器上,使用 csattribute 公用程序更新日历所有者的 icsDWPHost LDAP 属性以便指向新的后端服务器。要更新属性,您必须首先删除该属性,然后使用新值将其添加。例如,要将新服务器名称设置为 sesta.com,请执行以下命令:

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

  6. 在新服务器上,使用用户日历的 csuser 公用程序或资源日历的 csresource 启用日历用户。例如:

    csuser enable bkamdar

  7. 在新服务器上,使用下列命令检验属性是否正确以及每个日历的移动是否正确:

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

  8. 在原始服务器上,删除所有移动的日历。例如:

    cscal -o bkamdar delete bkamdar

    -o 选项删除主所有者为 bkamdar 的所有日历。

CLD 算法插件

DWP 是由 Calendar Server 专用的协议,用来在网络上执行日历数据库操作。DWP 使用 HTTP 作为传输机制,并包括日历数据库 API 的一个子集。

如果日历数据库在本地服务器上,则 Calendar Server 数据库子系统会使用 calid 来访问数据库中的日历。但是,如果日历数据库位于网络上(例如,位于后端服务器上),则 Calendar Server 必须使用日历查找数据库插件来确定日历实际所在的服务器网络地址。之后,该请求就会被转发到其他服务器上的 DWP 服务 (csdwpd) 进行处理。

一个前端机器和一个后端服务器

图 3-3 显示一个前端机器和一个后端服务器下的 Calendar Server 配置。要使用 DWP,前端机器和后端服务器所运行的操作系统以及 Calendar Server 的版本必须相同。

图 3-3    一个前端机器和一个后端服务器的 Calendar Server 配置


一个前端机器和一个后端服务器的 Calendar Server 配置

图 3-3 所显示的配置中,前端机器执行以下这些功能:

  • 处理客户端对网络上的日历数据的请求

  • 向后端服务器发出日历数据请求

  • 首先将日历数据转换为 XML 文档树

  • 将 XSL 文件应用于 XML 文档树以产生 HTML

  • 将 HTML 发送回客户端

后端服务器执行以下这些功能:

  • 处理所有日历数据库请求

  • 处理组日程安排引擎 (GSE) 请求队列

  • 监视提醒通知队列

  • 使用 enscsnotifyd 服务发送提醒通知

要配置 DWP,您在前端机器和后端服务器上都必须设置 ics.conf 参数


在前端机器上配置 CLD 算法插件参数:

  1. 使用拥有管理员权限的用户身份登录到前端机器。

  2. 定位到 Calendar Server 命令行公用程序所在的 server-root/cal/bin 目录,然后使用 stop-cal 命令停止 Calendar Server。

  3. 定位到 server-root/cal/bin/config/ 目录,然后编辑表 3-5 中显示的 ics.conf 参数。(要配置指向单个后端服务器的多个前端机器,请参见多个前端机器)。


表 3-5    前端机器的 CLD 算法插件配置参数 

参数

说明

service.http.enable = "yes"  

设置为 "yes"(默认值)表示本地配置需要 cshttpd 服务。  

csapi.plugin.calendarlookup = "y"  

设置为 "yes" (是) 可让 CSAPI 子系统载入日历查找数据库插件。  

csapi.plugin.calendarlookup.name = "*"  

此参数指定插件名称。在当前版本中,设置为 "*"(默认值)可让 CSAPI 子系统载入日历查找数据库插件。  

caldb.cld.type = "algorithmic"  

此参数指定要使用的日历查找数据库插件。默认值为 "local",但若要成功连接到 hostname 服务器,请设置为 "algorithmic"  

caldb.dwp.server.hostname.ip = "hostname"  

指定运行 DWP 服务的后端服务器完全限定名(即网络地址)。所有使用 DWP 的服务皆可读取,并且在启动时每个服务都尝试与 DWP 服务建立联系。

例如,如果服务器名称是 sesta,则此参数为:

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

caldb.dwp.server.hostname.port = "9779"  

指定 DWP 服务 (csdwpd) 所侦听的端口。默认值为 "9779"。它用作 caldb.dwp.server.hostname.ip 的值。hostname 部分必须与 caldb.dwp.server.hostname.ip 中的 hostname 相同。例如:

caldb.dwp.server.sesta.port = "9779"  

caldb.cld.server.hostname.regexpr = "expression"  

如果 caldb.cld.type"algorithmic",则此参数会指定由 CLD 算法插件所使用的表达式来确定实际存储指定日历 ID 的服务器。例如:

caldb.cld.server.sesta.regexpr = "^[^\n]"

sesta 服务器上的所有日历 ID 相匹配。  

  1. 定位到 Calendar Server 命令行公用程序所在的 server-root/cal/bin 目录,然后使用 start-cal 命令重新启动 Calendar Server。

    前端机器上需要 cshttpdcsadmind 服务。


在后端服务器上配置 CLD 算法插件参数:
  1. 使用拥有管理员权限的用户身份登录到后端服务器。

  2. 定位到 Calendar Server 命令行公用程序所在的 server-root/cal/bin 目录,然后使用 stop-cal 命令停止 Calendar Server。

  3. 定位到 server-root/cal/bin/config/ 目录,然后编辑表 3-6 中显示的 ics.conf 参数。


表 3-6    单个后端服务器的 CLD 算法插件配置参数 

参数

说明

service.dwp.enable = "yes"  

启用 DWP 服务 (csdwpd)。会使 Calendar Server 在启动其他服务时启动 csdwpd 服务。也会让 csdwpd 服务侦听 service.dwp.port 指定的端口。

默认值为 "no",但必须重置为 "yes"。  

service.dwp.port = "9779"  

指定 csdwpd 服务侦听的端口。

默认值是“9779”。  

service.notify.enable = "yes"

service.admin.enable = "yes"

service.ens.enable = "yes"  

启用后端服务器上的每个服务。必须设置为 "yes"(默认值)才能启用各个服务。  

  1. 定位到 Calendar Server 命令行公用程序所在的 server-root/cal/bin 目录,然后使用 start-cal 命令重新启动 Calendar Server。

    后端服务器上需要 csdwpdcsadmindenpdcsnotifyd 服务。

现在,您就可以使用 Calendar Express 从前端机器访问后端服务器上的 Calendar Server 数据库了。下面是它的工作机制:

cshttpd 服务在前端机器上启动时,它会初始化数据库子系统。它会从 ics.conf 文件中载入 caldb.dwp.server.host.ipcaldb.dwp.server.host.port 两个参数,然后尝试使用主机 IP 地址和端口值与后端服务器建立联系。如果联系成功,则 cshttpd 服务会与后端服务器上的 csdwpd 服务创建一个连接池,专门用于 DWP 事务。

最初,该连接池的大小设置为 caldb.dwp.initconns 参数的值,但该池可增大到 caldb.dwp.maxcons 参数所指定的最大值。池中的每个连接都是一个 HTTP/1.1 持续连接;若有任何连接失败,都会向日志文件中写入错误消息。

如果前端机器和后端服务器之间的 DWP 连接中断(例如,后端服务器重新启动),则前端机器会尝试与后端服务器重新建立连接。如果 DWP 连接中断,则日历数据请求会失败;要等到连接恢复后数据才可用。

多个前端机器

图 3-4 显示多个前端机器和单个后端服务器下的 Calendar Server 配置。两个前端机器(cal1.example.com 和 cal2.example.com)的配置参数相同,这些参数说明于 在前端机器上配置 CLD 算法插件参数:您也可以添加其他前端机器以分担前端负载。

图 3-4    多个前端机器和一个后端服务器的 Calendar Server 配置


多个前端机器和一个后端服务器的 Calendar Server 配置


管理 LDAP 属性

要管理 Calendar Server 所使用的 LDAP 属性,请使用 csattribute 公用程序。



备注 如果您的站点使用的是 LDAP CLD 插件,请不要使用 csattribute 更改 icsDWPHost 属性来指定新的后端主机服务器。修改 icsDWPHost 的操作不会在新的后端主机上创建新日历。有关更多信息,请参阅“LDAP 日历查找数据库 (CLD) 插件”



列出 LDAP 属性

要列出用户或资源的 LDAP 属性,请使用 csattribute 公用程序的 add命令。
例如,要列出用户 TChang 的 LDAP 属性,请执行以下命令:

csattribute list TChang

添加 LDAP 属性

要向 LDAP 服务器添加属性,请使用 csattribute 公用程序的 add 命令。例如,要将 LDAP 属性 icsCalendar 的值 Conference_Schedule 添加给用户 TChang,请执行以下命令:

csattribute -a icsCalendar=Conference_Schedule add TChang

删除 LDAP 属性

要从 LDAP 服务器中删除属性,请使用 csattribute 公用程序的 delete 命令。
例如,要从 TChang 中删除 LDAP 属性 icsCalendar,请执行以下命令:

csattribute -a icsCalendar delete TChang


管理组日程安排引擎 (GSE) 队列

组日程安排允许 Calendar Server 用户创建一个事件(如会议),然后邀请其他参与者。通过使用“空闲/已占用”查找功能,用户可以确定被邀请者什么时候有空参与事件。

如果参与者位于同一个 Calendar Server 上,则会于参与者的日历中安排事件。如果参与者不在同一个 Calendar Server 上,则会通过电子邮件发送邀请。然后参与者可以接受或谢绝此邀请。

Calendar Server 用户也可以并排查看各参与者的日历来比较组日程。

要管理 GSE 队列中的项,请使用 csschedule 公用程序。必须在安装 Calendar Server 的本地机器上运行 csschedule

列出 GSE 队列中的项

要列出 GSE 队列中的项,请使用 csschedule 公用程序的 list 命令。例如,要列出 GSE 队列中的所有项,请执行以下命令:

csschedule list

要列出存储在 GSE 队列中的前十项,请执行以下命令:

csschedule -c 10 list

要列出GSE 队列内,calidHoliday_Schedule 的日历中之所有项:

csschedule -v list Holiday_Schedule

删除 GSE 队列中的项

要删除 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

要监视 Calendar Server 的活动,请使用 csstatscstool 公用程序。本节介绍以下任务:

列出计数器统计信息

csstats 公用程序可显示日历配置 (counter.conf) 文件所定义之计数器对象的统计信息。计数器对象(如httpstatauthstatwcapstatdbstat)所显示的有关 Calendar Server 的信息包括:

  • 最高并行连接数和连接总数

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

  • 数据库读取、写入和删除数

有关 Calendar Server 计数器统计信息的更多信息,请参见“计数器配置 (counter.conf) 文件”

要列出统计信息,请使用 csstats 公用程序的 list 命令。例如,要显示有关可用计数器对象和类型的基本信息,请执行以下命令:

csstats list

要专门列出有关 httpstat 计数器对象的统计信息,请执行以下命令:

csstats list http

要在一个小时内每隔十秒钟列出一次有关 wcapstat 计数器对象的统计信息,请执行以下命令:

csstats -i 360 -s 10 list wcap

监视 Calendar Server 日志文件

每个 Calendar Server 服务都会将状态信息写入其本身的日志文件。每个日志文件会以其关联的服务名称来命名,如表 3-7 所示:


表 3-7    Calendar Server 日志文件

服务名称

日志文件名

csadmind  

admin.log  

csdwpd  

dwp.log  

cshttpd  

http.log  

csnotifyd  

notify.log  

Calendar Server 日志文件会存储在默认日志目录中:

  • 在 Solaris 系统上:

    /var/opt/SUNWics5/logs

  • 在 Solaris 以外的 UNIX 系统上:

    /var/opt/iPlanet/CalendarServer5/logs

  • 在 Windows NT 系统上:

    c:\Program Files\iPlanet\CalendarServer5\var\logs

每个日志文件会根据配置的时间和大小限制,转换为具有新名称的新日志文件,如下所示:

ServiceName.TimeStamp.#

例如:

admin.20000801115354.1
http.20000801115354.2

日志事件严重性级别

针对报告给日志文件的事件,Calendar Server 提供了八个严重性级别,详见表 3-8


表 3-8    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 执行 Ping 操作

要确认 Calendar Server 服务是否在侦听指定的端口号,请使用 cstool 公用程序的 ping 命令。对一个服务执行 ping 操作并不能确认该服务是否确实在运行,但可以指出该服务是否能够接受套接字连接。

Calendar Server 服务选项包括:

  • http HTTP 服务 (cshttpd)

  • admin 管理服务 (csadmind)



    备注 在当前版本中,您无法对 DWP 服务 (csdwpd)、事件通知服务 (enpd) 或通知服务 (csnotifyd) 执行 ping 操作。



必须运行 Calendar Server,才能运行 cstool

例如,要对主机名为 calserver 的机器执行 ping 操作,以查看 cshttpd 服务是否在侦听端口 80,请执行以下命令:

cstool -p 80 -h calserver ping http

默认情况下,cstool 会等待 120 秒,查看有无响应;但您可以使用 -t timeout 选项更改该值。


刷新 Calendar Server 配置

要强制 Calendar Server 服务刷新其配置,请使用 cstool 公用程序的 refresh 命令。如果未指定服务,则该命令将刷新所有 Calendar Server 服务的配置。必须运行 Calendar Server,才能运行 cstool。

例如,要强制本地 Calendar Server 刷新所有服务的配置,请执行以下命令:

cstool refresh



备注 在当前版本中,不要使用 cstool 刷新来刷新配置。而应使用 stop-calstart-cal 命令。有关更多信息,请参见“启动和停止 Calendar Server”




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

更新日期 2002 年 8 月 30 日