Chapter 3 Managing Calendar Server

You manage Calendar Server by running command-line utilities and by editing the ics.conf configuration file.

To run the command-line utilities, you must log in as a user who has administrative rights to the system where Calendar Server is running.

Starting and Stopping Calendar Server

Using the start-cal and stop-cal Utilities


Note	Calendar Server provides the csstart and csstop utilities only for compatibility with earlier releases. It is recommended that you use the start-cal and stop-cal utilities to start and stop Calendar Server.

The start-cal and stop-cal utilities are located in the cal_svr_base/opt/SUNWics5/cal/sbin directory. You must run these utilities on the local machine where Calendar Server is installed. For problems that might occur, see "Troubleshooting the start-cal and stop-cal Utilities".

enpd — Event Notification Service (ENS)

csnotifyd — Notification Service

csadmind — Administration Service

csdwpd — Database Wire Protocol (DWP) service, the distributed database service that is started only with a remote Calendar Server database configuration

cshttpd — HTTP Service

To start Calendar Server using the start-cal command:

Change to the cal_svr_base/opt/SUNWics5/cal/sbin directory.

Start Calendar Server:

./start-cal

To stop Calendar Server using the stop-cal command:

Change to the cal_svr_base/opt/SUNWics5/cal/sbin directory.

Stop Calendar Server:

./stop-cal

Troubleshooting the start-cal and stop-cal Utilities

When you are starting and stopping Calendar Server, the following problems might occur:

The start-cal utility does not start all Calendar Server processes. For example, start-cal might start the enpd, csnotifyd, and csadmind processes but not cshttpd. In this situation, you must stop all Calendar Server processes before you try to restart Calendar Server.

The stop-cal utility does not stop all Calendar Server processes. For example, stop-cal might stop the cshttpd parent process but not any cshttpd child processes. In this situation, you must stop the remaining Calendar Server processes.

To stop Calendar Server processes on Solaris Systems:

Determine the process ID (PID) of the remaining Calendar Server processes by entering a ps command for each service:

ps -elf | grep cs-process

where cs-process is enpd, csnotifyd, csdwpd, csadmind, or cshttpd. For example:

ps -elf | grep cshttpd

Using the PID of each process that is still running, enter a pkill -15 command to kill the process. For example:

pkill -15 9875

Enter each ps command again to make sure that all Calendar Server processes are stopped.

If a Calendar Server process is still running, enter a pkill -9 command to kill it. For example:

pkill -9 9875


Caution	After you have stopped all Calendar Server processes and before you restart Calendar Server, consider running the csdb utility check command to check for any calendar database corruption that might have occurred. For information about the check command, see "Checking and Rebuilding a Calendar Database".

Configuring Calendar Server Timeout Values

Configuring Timeout Values for csadmind

Configuring HTTP Timeout Values for End Users

Configuring Timeout Values for csadmind

Table 3-1 describes the Calendar Server timeout parameters in the ics.conf file used by the Administration (csadmin) service.

Table 3-1 HTTP Timeout Values for the Administration Service (csadmin)
Parameter	Description
service.admin.idletimeout	Specifies the number of seconds the csadmind service waits before timing out an idle HTTP connection. The default is 120 seconds (2 minutes).
service.admin.resourcetimeout	Specifies the number of seconds the csadmind service waits before timing out an HTTP session for a resource calendar. The default is 900 seconds (15 minutes).
service.admin.sessiontimeout	Specifies the number of seconds the csadmind service waits before timing out an HTTP session. The default is 1800 seconds (30 minutes).

Configuring HTTP Timeout Values for End Users

Table 3-2 describes the Calendar Server HTTP timeout parameters in the ics.conf file that apply to end users.

Table 3-2 HTTP Timeout Values in ics.conf for End Users (cshttpd Service)
Parameter	Description
service.http.idletimeout	Specifies the number of seconds the cshttpd service waits before timing out an idle HTTP connection. The default is 120 seconds (2 minutes).
service.http.resourcetimeout	Specifies the number of seconds the cshttpd service waits before timing out an HTTP session for a resource calendar. The default is 900 seconds (15 minutes).
service.http.sessiontimeout	Specifies the number of seconds the cshttpd service waits before timing out an HTTP session. The default is 1800 seconds (30 minutes).

Configuring Single Sign-on (SSO)

Single Sign-on (SSO) allows a user to authenticate once and then use multiple trusted applications without having to authenticate again. Sun ONE Communications servers, including Calendar Server and Messaging Server, can implement SSO as follows:

Configuring SSO Through Identity Server

Configuring SSO Through Communications Servers Trusted Circle Technology

Configuring SSO Through Identity Server

Sun ONE servers, including Calendar Server and Messaging Server, can implement SSO using Sun ONE Identity Server 6.1 or later.

Identity Server serves as the SSO gateway for Sun ONE servers. That is, users log in to Identity Server and then can access other Sun ONE servers, as long as the servers are configured properly for SSO.

Make sure that Sun ONE Identity Server and Sun ONE Directory Server are installed and configured. For information about installing and configuring these products, refer to the Sun Java Enterprise System Installation Guide.

Configure SSO for Calendar Server by setting the parameters shown in Table 3-3 and then restarting Calendar Server for the values to take effect. If necessary, remove the comment character (!) when you set each parameter.

Note When you set the local.calendar.sso.amnamingurl parameter, you must use a fully qualified name for Identity Server.

To configure SSO for Messaging Server, refer to the Sun ONE Messaging Server 6.0 Administrator's Guide.

Users log into Identity Server using their Directory Server LDAP user name and password. (A user who logs in through another server such as Calendar Server or Messaging Server will not be able to use SSO to access the other Sun ONE servers.)

After logging in, users can access Calendar Server through Calendar Express using the appropriate URL. Users can also access other Sun ONE servers such as Messaging Server, if the servers are configured properly for SSO.

Table 3-3 Calendar Server Configuration Parameters for Using SSO With Identity Server
Parameter	Description
local.calendar.sso.amnamingurl	Specifies the URL of the Identity Server SSO naming service. Default is “http://IdentityServer:port/amserver/namingservice“ where IdentityServer is the fully qualified name of Identity Server, and port is the Identity Server port number.
local.calendar.sso.amcookiename	Specifies the name of the Identity Server SSO cookie. Default is “iPlanetDirectoryPro”.
local.calendar.sso.amloglevel	Specifies the log level for Identity Server SSO. Range is from 1 (quiet) to 5 (verbose). Default is “3“.
local.calendar.sso.logname	Specifies the name of the Identity Server SSO API log file. Default is “am_sso.log”.
local.calendar.sso.singlesignoff	Enables (“yes“) or disables (“no“) single sign-off from Calendar Server to Identity Server. If enabled, a user who logs out of Calendar Server is also logged out of Identity Server, and any other sessions the user had initiated through Identity Server (such as a Messaging Server webmail session) are terminated. Because Identity Server is the authentication gateway, single sign-off is always enabled from Identity Server to Calendar Server. Default is “yes“.

Considerations for Using SSO With Identity Server

A calendar session is valid only as long as the Identity Server session is valid. If a user logs out of Identity Server, the calendar session is automatically closed (single sign-off).

SSO applications must be in the same domain.

SSO applications must have access to the Identity Server verification URL (naming service).

Browsers must support cookies.

If you are using the Sun ONE Portal Server gateway, set the following Calendar Server parameters:

service.http.ipsecurity="no"

render.xslonclient.enable="no"

Configuring SSO Through Communications Servers Trusted Circle Technology

When configuring SSO through Communications Servers trusted circle technology (that is, not through Identity Server), consider these points:

Each trusted application must be configured for SSO.

SSO does not work correctly if the default.html page is in your browser’s cache. Before using SSO, be sure to reload the default.html page in your browser. For example, in Netscape Navigator, hold down the Shift key and then click Reload.

SSO works only for bare URLs. For example, SSO works for http://servername but not for URLs such as http://servername/command.shtml?view.

Table 3-4 describes the Calendar Server configuration parameters for SSO through Communications Servers trusted circle technology.

Table 3-4 Calendar Server SSO Parameters Through Communications Servers Trusted Circle Technology
Parameter	Description
sso.enable = "1"	This parameter must be set to"1" (the default) to enable SSO. "0" disables SSO.
sso.appid = "ics50"	This parameter specifies the unique application ID for the specific Calendar Server installation. Each trusted application must also have a unique application ID. The default is "ics50".
sso.appprefix = "ssogrp1"	This parameter specifies the prefix value to be used for formatting SSO cookies. The same value must be used by all trusted applications, because only SSO cookies with this prefix will be recognized by Calendar Server. The default is "ssogrp1".
sso.cookiedomain = ".sesta.com"	This parameter causes the browser to send a cookie only to servers in the specified domain. The value must begin with a period (.)
sso.singlesignoff = "true"	A value of "true" (the default) clears all SSO cookies on the client with prefix values matching the value configured in sso.appprefix when the client logs out.
sso.userdomain = "sesta.com"	This parameter sets the domain used as part of the user's SSO authentication.
sso.appid.url = "verifyurl" For example: sso.ics50.url = "http://sesta.com:8883/VerifySSO?" sso.msg50.url = "http://sesta.com:8882/VerifySSO?"	This parameter sets the verify URL values for peer SSO hosts for the Calendar Server configuration. One parameter is required for each trusted peer SSO host. The parameter includes the: Application ID (appid) identifies each peer SSO host whose SSO cookies are to be honored Verify URL ("verifyurl") includes the host URL, host port number, and VerifySSO? (including the ending ?). In this example, the Calendar Server application ID is ics50, the host URL is sesta.com, and the port is 8883. The Messenger Express application ID is msg50, the host URL is sesta.com, and the port is 8882.

Table 3-5 describes the Messaging Server configuration parameters for SSO through Communications Servers trusted circle technology.

Table 3-5 Messaging Server SSO Parameters Through Communications Servers Trusted Circle Technology
Parameter	Description
local.webmail.sso.enable = 1	This parameter must be set to a non-zero value to enable SSO.
local.webmail.sso.prefix = ssogrp1	This parameter specifies a prefix used when formatting SSO cookies set by the HTTP server.
local.webmail.sso.id = msg50	This parameter specifies the unique application ID (msg50) for the Messaging Server. Each trusted application must also have a unique application ID.
local.webmail.sso.cookiedomain = sesta.com	This parameter specifies the cookie domain value of all SSO cookies set by the HTTP server.
local.webmail.sso.singlesignoff = 1	A non-zero value clears all SSO cookies on the client with prefix values matching the value configured in local.webmail.sso.prefix when the client logs out.
local.sso.appid.url = "verifyurl" For example: local.sso.ics50.verifyurl = http://sesta.com:8883/VerifySSO? local.sso.msg50.verifyurl = http://sesta.com:8882/VerifySSO?	This parameter sets the verify URL values for peer SSO hosts for the Messaging Server configuration. One parameter is required for each trusted peer SSO host. The parameter includes these items: Application ID (appid) identifies each peer SSO host whose SSO cookies are to be honored Verify URL ("verifyurl") includes the host URL, host port number, and VerifySSO? (including the ending ?). In this example, the Messaging Server application ID is msg50, the host URL is sesta.com, and the port is 8882. The Calendar Server application ID is ics50, the host URL is sesta.com, and the port is 8883.

For more information about configuring Messaging Server for SSO, see the Sun ONE Messaging Server 6.0 Administrator's Guide.

Configuring the LDAP Calendar Lookup Database (CLD) Plug-in

The LDAP CLD plug-in provides horizontal scalability of the calendar database by allowing user and resource calendars to be distributed over a number of back-end servers for a single calendar instance. The LDAP CLD plug-in uses the icsDWPHost attribute to determine the back-end server where a calendar is located.


Note	In Calendar Server 5.1.1 and later releases, the major version number of the CLD plug-in changed from 1 to 2. The minor version number is still 0. If you have written your own CLD plug-in, you must modify your plug-in to support this new major version number.

How the LDAP CLD Plug-in Works

Calendar Server Configurations for the LDAP CLD Plug-in

Maintaining Security Between Front-End and Back-End Servers

Improving Performance of the LDAP CLD Plug-in

Clearing the CLD Cache

Moving a Calendar to a Different Back-End Server

How the LDAP CLD Plug-in Works

The LDAP CLD plug-in allows the calendar database to be distributed over a number of back-end servers. Each calendar in the database is identified by a unique calendar ID (calid) in the following format:

userid is a unique user ID for the Calendar Server instance.

domain is an optional domain name for the user.

calendar-name is an optional calendar name that is unique to the specific user.

When a Calendar Express end user accesses a calendar, the LDAP CLD plug-in extracts the userid from the calendar’s calid and then looks up the calendar owner in the LDAP server database.

After finding the calendar owner, the plug-in uses the owner’s icsDWPHost LDAP attribute to determine the host name of the back-end server where the calendar resides. This host name must be resolvable by your Domain Name Service (DNS) into a valid IP address.

Using the host name, Calendar Server accesses the calendar data on the back-end server using the Database Wire Protocol (DWP). DWP is an internal protocol that runs as the csdwpd service and provides the networking capability for the calendar database.

Using DWP, Calendar Server sends the calendar data to the server where the user is logged in, and then Calendar Express renders the data in the end user’s browser.



Note	If your site is using the LDAP CLD plug-in and you are using the cscal utility to create a new calendar, you must create the new calendar on the same back-end server where the user’s calendars reside (or will reside), as indicated by the user’s icsDWPHost LDAP attribute. If you try to create a calendar on a different back-end server, Calendar Server returns an error. For more information, see "cscal".

Calendar Server Configurations for the LDAP CLD Plug-in

Multiple Front-End Servers with Multiple Back-End Servers

Multiple Front-End/Back-End Servers

Be running the same Solaris Operating System.

Be running the same Calendar Server release, including patches.

Use the same port number for the DWP port (service.dwp.port parameter). The default port number is “59779”.

Multiple Front-End Servers with Multiple Back-End Servers

The following figure shows two front-end servers and two back-end servers running a single Calendar Server instance. You can also configure more than two front-end or back-end servers, if you wish.

This configuration allows the servers to be protected by a firewall to restrict access to the LDAP and calendar databases. The calendar database is distributed across the two back-end servers.

The front-end servers are CPU intensive, with most CPU time spent rendering calendar data for end-users. The back-end servers are disk intensive, with most CPU time spent accessing the calendar database.

Configuring a Front-End Server

To configure a front-end server, set the following parameters in the ics.conf file on each front-end server.

Enable calendar database lookup plug-ins:

csapi.plugin.calendarlookup = "y"

Specify that Calendar Server load all plug-ins:

csapi.plugin.calendarlookup.name = "*"

Set the type of calendar lookup plug-in for the LDAP CLD plug-in:

caldb.cld.type = "directory"

Set the port number for the DWP service (csdwpd):

service.dwp.port = "59779"

The default is “59779”. The port number must be the same for all configured front-end and back-end servers.

Set the server name for each back-end server in the configuration:

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"

The server name must be fully qualified and be resolvable by your Domain Name Service (DNS) into a valid IP address. In each part of the parameter, the server name must be identical and fully qualified. For example:

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

The server name must also match the name used for the icsDWPHost LDAP attribute for the applicable calendar owners.

Set the default DWP server name:

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

where server-name is the fully qualified default server name used by Calendar Server if the user or resource entry in the LDAP server database does not have an icsDWPHost attribute. This name must be resolvable by your Domain Name Service (DNS) into a valid IP address. For example:

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

Restart Calendar Server for the changes to take effect.

Example Configuration Parameters for a Front-End Server

The following example shows the configuration parameters for a front-end server with two back-end servers named calendar.sesta.com and calendar.siroe.com. The default DWP server is calendar.sesta.com.

Configuring a Back-End Server

To configure a back-end server, set the following parameters in the ics.conf file on each back-end server.

Enable the DWP service (csdwpd) and set the DWP port number:

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

The default port number is “59779”. The port number must be the same for all configured front-end and back-end servers.

Disable the HTTP service because it is not required on a back-end server (the Admin service should be set to the default value of "yes"):

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

Set the type of calendar lookup plug-in for the LDAP CLD plug-in:

caldb.cld.type = "local"

Set csapi.plugin.calendarlookup to "n" because a back-end server does not need to lookup any calendar data:

csapi.plugin.calendarlookup = "n"

Restart Calendar Server for the changes to take effect.

Example Configuration Parameters for a Back-End Server

Multiple Front-End/Back-End Servers

The following figure shows three front-end/back-end servers, with each server connected to a calendar database. This configuration allows calendars to be geographically distributed, with each calendar residing on the server where its owner logs into Calendar Server.

Configuring a Front End/Back-End Server

To configure a front-end/back-end server, set the following parameters in the ics.conf file on each server.

Enable the DWP service (csdwpd):

service.dwp.enable = "y"

Set the port number for the DWP service (csdwpd):

service.dwp.port = "59779"

The default is “59779”. The port number must be the same for all configured front-end and back-end servers.

Enable calendar lookup plug-ins:

csapi.plugin.calendarlookup = "y"

Have Calendar Server load all plug-ins:

csapi.plugin.calendarlookup.name = "*"

Specify the type of calendar lookup plug-in that Calendar Server should use:

caldb.cld.type = "directory"

Set the default DWP server name:

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

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

Set the server name for all front-end/back-end servers in the configuration, including the local server:

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"

The server name must also match the name used for the icsDWPHost LDAP attribute for the applicable calendar owners.

Restart Calendar Server for the changes to take effect.

Example Configuration Parameters for Each Front-End/Back-End Server

The following example shows the configuration parameters for each front-end/back-end server. The servers are sesta.com, siroe.com, and varrius.com. The default DWP server is sesta.com.

Code Example 3-3 LDAP CLD Configuration Parameters for Each Front-End/Back-End Server

Maintaining Security Between Front-End and Back-End Servers

A front-end server uses the Database Wire Protocol (DWP) to communicate with a back-end server. Because DWP uses HTTP as the transport mechanism, Calendar Server 6.0 provides authentication for DWP connections between front-end and back-end servers using the configuration parameters in Table 3-6 and Table 3-7.

These parameters are optional and by default are not included in the ics.conf file. To use authentication for DWP connections, you must add the required parameters to the ics.conf file on each front-end and back-end server.

Table 3-6 Back-end Configuration Parameters for Authentication of a DWP Connection
Parameter	Description
service.dwp.admin.userid	On a back-end server, specifies the user ID that is used to authenticate a DWP connection. If a back-end server does not specify a user ID, no authentication is performed.
service.dwp.admin.cred	On a back-end server, specifies the password that is used to authenticate a DWP connection. If a back-end server does not specify a password, no authentication is performed.

Table 3-7 Front-end Configuration Parameters for Authentication of a DWP Connection
Parameter	Description
caldb.dwp.server.back-end-server.admin	On a front-end server, specifies the user ID that is used for authentication for a DWP connection to a back-end server, where back-end-server is the name of the server.
caldb.dwp.server.back-end-server.cred	On a front-end server, specifies the password that is used for authentication for a DWP connection to a back-end server, where back-end-server is the name of the server.

To set up the authentication for DWP connections between front-end and back-end servers, follow these steps:

In the ics.conf file on each front-end server, add these parameters:

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

where back-end-server is the name of the back-end server and userid and password are the user ID and password you want Calendar Server to use to authenticate the connection.

In the ics.conf file on each back-end server indicted by back-end-server, add these parameters:

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

where userid and password are the same user ID and password you specified on the front-end server.

When the front-end server first connects to the back-end server, it sends the user ID and password specified by the parameters. The back-end server checks the parameters, and if both parameters match, the authentication is successful. The back-end server then sends a session ID back to the front-end server. The front-end server uses the session ID in subsequent DWP commands to the back-end server.

Subsequent connections from the same front-end server do not need to be authenticated again, unless:

The back-end server is restarted.

The session expires because of no activity between the two servers.

If you have multiple front-end and back-end server, you can use the same user ID and password for each one.

If a back-end server does not specify a user ID and password in this parameter, no authentication is performed.

Improving Performance of the LDAP CLD Plug-in

To improve the performance of Calendar Server with the LDAP CLD plug-in, make sure the following configuration parameters are set to “yes” (the default value for each parameter):

caldb.cld.cache.enable enables the CLD cache option. This option stores the DWP host server information (icsDWPHost LDAP attribute) for calendar users and thus reduces calls to the LDAP directory server.

service.calendarsearch.ldap specifies that calendar searches are done using the LDAP or a user preference plug-in.

Clearing the CLD Cache

If you are using the CLD cache option and you have updated a server name for an ics.conf parameter or moved a calendar to a different back-end server, you should clear the CLD cache to remove the server names. An out-of-date entry in the CLD cache can prevent a front-end server from establishing a connection to the correct back-end server or cause Calendar Server not to find a calendar after it have been moved.

Stop Calendar Server.

Remove all files in the cal_svr_base/var/opt/SUNWics5/csdb/cld_cache directory, but do not remove the cld_cache directory itself.

Restart Calendar Server.

Moving a Calendar to a Different Back-End Server

To move a user or resource calendar from one back-end server to another back-end server, follow these steps:

On the original server, disable the calendar user using the csuser utility for a user calendar or csresource for a resource calendar. For example to disable the user with the user ID and calid bkamdar:

csuser disable bkamdar

On the original server, export the calendar from the calendar database to a file using the csexport utility. For example:

csexport -c bkamdar calendar bkamdar.ics

If a user has more than one calendar, you must perform this step for each calendar.

Copy the exported calendar (*.ics) files from the original server to the new server.

On the new server, import the calendar from the file to the calendar database using the csimport utility. For example:

csimport -c bkamdar calendar bkamdar.ics

Again, you must perform this step for each of the calendars you exported.

On the LDAP directory server, update the calendar owner’s icsDWPHost LDAP attribute to point to the new back-end server using the csattribute utility. To update an attribute, you must first delete the attribute and then add it with the new value. For example, to set the new server name to sesta.com:

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

On the new server, enable the calendar user using the csuser utility for a user calendar or csresource for a resource calendar. For example:

csuser enable bkamdar

On the new server, use the following commands to verify that the attributes are correct and that each calendar has been moved correctly. For example:

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

On the original server, delete each calendar you just moved. For example:

cscal -o bkamdar delete bkamdar

The -o option deletes all calendars whose primary owner is bkamdar.

Managing LDAP Attributes

To manage the LDAP attributes used by Calendar Server, use the csattribute utility.

Listing LDAP Attributes


Note	If your site is using the LDAP CLD plug-in, do not use csattribute to change the icsDWPHost attribute to specify a new back-end host server. Modifying icsDWPHost does not cause a new calendar to be created on the new back-end host. For more information, see "Configuring the LDAP Calendar Lookup Database (CLD) Plug-in".

To list LDAP attributes for a user or resource, use the csattribute utility add command. For example, to list the LDAP attributes for the user TChang:

Adding an LDAP Attribute

To add an attribute to the LDAP server, use the csattribute utility add command. For example, to add the LDAP attribute icsCalendar with the value Conference_Schedule to the user TChang:

Deleting an LDAP Attribute

To delete an attribute to the LDAP server, use the csattribute utility delete command. For example, to delete the LDAP attribute icsCalendar from TChang:

Managing the Group Scheduling Engine (GSE) Queue

Group scheduling allows a Calendar Server user to create an event such as a meeting and then invite other attendees. By using the free/busy lookup feature, the user can determine when an invitee is actually available for an event.

If an attendee is on the same Calendar Server, the event is scheduled in the attendee’s calendar. If an attendee is not on the same Calendar Server, the invitation is sent via email. The attendee can then accept or decline the invitation.

Calendar Server users can also compare a group schedule by viewing attendees' calendars side-by-side.

To manage entries in the GSE queue, use the csschedule utility. You must run csschedule on the local machine where Calendar Server is installed.

Listing Entries in the GSE Queue

To list entries in the GSE queue, use the csschedule utility list command. For example, to list all entries in the GSE queue:

To list all entries in the GSE queue for a calendar with the calid Holiday_Schedule:

Deleting Entries in the GSE Queue

To delete entries in the GSE queue, use the csschedule utility delete command. For example, to delete all entries in the GSE queue:

To delete the entry in the GSE queue for calendar calA with the first schedule time of 13:30:45 on 11/30/2001, an offset number of 1, the unique identifier 1111, the recurrence ID 0, and the sequence number 0:

Monitoring Calendar Server

To monitor Calendar Server activity, use the csmonitor, csstats, and cstool utilities. This section describes the following tasks:

Listing Counter Statistics

Monitoring Calendar Server Log Files

Listing Counter Statistics

The csstats utility displays statistical information from counter objects defined in the calendar configuration (counter.conf) files. Counter objects such as httpstat, authstat, wcapstat, or dbstat show information about Calendar Server including:

Maximum number of concurrent connections and total number of connections

Total number of successful and failed logins and connections

Number of database reads, writes, and deletes

To list statistical information, use the csstats utility list command. For example, to display basic information about the counter objects and the types available:

To list statistics about the wcapstat counter object every 10 seconds for one hour:

Monitoring Calendar Server Log Files

Each Calendar Server service writes status information to its own log file. Each log file is named after its associated service name, as shown in Table 3-8:

Table 3-8 Calendar Server Log Files
Service Name	Log File Name
Administration Service (csadmind)	admin.log
Distributed Database Service (csdwpd)	dwp.log
HTTP Service (cshttpd)	http.log
Notification Service (csnotifyd)	notify.log

Calendar Server log files are stored in the following default directory on Solaris Systems:

Each log file is rolled-over to a new log file with a new name based on the configured time and size limits as follows:

Log Event Severity Levels

Calendar Server provides eight levels of severity for events reported to the log files as described in Table 3-9.

Table 3-9 Calendar Server Log Error Severity Levels
Severity Level	Meaning
EMERGENCY	System is unusable. This level indicates events with the highest (most critical) severity.
ALERT	Action must be taken immediately.
CRITICAL	Critical condition.
ERROR	Error condition.
WARNING	Warning condition.
NOTICE	Normal, but signification condition. This is the default reporting level for each calendar service.
INFORMATION	Informational.
DEBUG	Debug-level message.

A log event is represented by a single line that shows the associated timestamp, server host name, severity level, process name (process ID), type of event, priority, and description. You can specify the level of severity of the events that Calendar Server reports to the log files by modifying certain configuration settings in the ics.conf file. For information, see "Calendar Log Information Configuration".

You should inspect the log files on a regular basis for EMERGENCY, ALERT, CRITICAL, ERROR, and WARNING level errors and, if found, examine the events for possible problems with the operation of Calendar Server. The NOTICE and INFORMATION level log events are generated during normal operation of Calendar Server and are provided to help you monitor server activity.


Note	When requesting technical support for Calendar Server, you might be asked to provide the log files for help in resolving problems.

Pinging Calendar Server

To verify that a Calendar Server service is listening on a specified port number, use the cstool utility ping command. Pinging a service does not verify that a service is actually running but indicates if it can accept a socket connection.

http — HTTP Service (cshttpd)

admin — Administration Service (csadmind)



Note	In the current release, you cannot ping the DWP service (csdwpd), Event Notification Service (enpd), or Notification Service (csnotifyd).

For example, to ping the machine with the host name calserver to see if the cshttpd service is listening on port 80:

By default, cstool waits 120 seconds for a response; however, you can change by value by using the -t timeout option.

Refreshing the Calendar Server Configuration

In the current release, do not use the cstool refresh command to refresh a configuration. Instead, use the stop-cal and start-cal commands. For more information, see "Starting and Stopping Calendar Server".