Previous Contents Index Next |
iPlanet Calendar Server Administrator's Guide |
Chapter 3 Managing the Calendar Server
This chapter describes how to manage and configure iPlanet Calendar Server.This chapter contains these sections:
Starting and Stopping the Calendar Server
You manage the Calendar Server by running command-line utilities and by editing the ics.conf configuration file.Configuring Calendar Server Timeout Values
Configuring Single Sign-on (SSO)
Configuring Database Wire Protocol (DWP)
Managing the Group Scheduling Engine (GSE) Queue
To run the command-line utilities, you must log in as a user who has administrative rights to the system where the Calendar Server is running.
For more information, see Chapter 7 "Calendar Server Command-Line Utilities" and Chapter 8 "Calendar Server Configuration."
Starting and Stopping the Calendar Server
You can start and stop the Calendar Server as follows:
On Solaris, other UNIX, and Windows NT systems, use the start-cal and stop-cal commands. See "Using the start-cal and stop-cal Commands".
On Windows NT systems, you can also use the Control Panel Services. See "Using the Windows NT Control Panel".
Using the start-cal and stop-cal Commands
The start-cal and stop-cal utilities are located in the server-root/cal/bin directory. You must run these utilities on the local machine where the Calendar Server is installed. For problems that might occur, see "Troubleshooting the start-cal and stop-cal Commands".The start-cal command starts the Calendar Server services in the following order:
enpd Event Notification Service (ENS)
For a description of these services, see "Calendar Server Services".csnotifyd Notification Service
csadmind Administration Service
csdwpd Distributed Database Service (started only with a remote Calendar Server database configuration)
To start the Calendar Server using the start-cal command:
Log in as a user who has administrative rights to the system.
Change to the server-root/cal/bin directory. For example on Solaris systems:
Start the Calendar Server:
- cd /opt/SUNWics5/cal/bin
- ./start-cal
To stop the Calendar Server using the stop-cal command:
Log in as a user who has administrative rights to the system where the Calendar Server is running.
Change to the server-root/cal/bin directory. For example on Solaris systems:
Stop the Calendar Server:
- cd /opt/SUNWics5/cal/bin
- ./stop-cal
Using the Windows NT Control Panel
On Windows NT systems, use the Services dialog box from the Control Panel.
To start and stop the Calendar Server using the Windows NT Control Panel:
Log in as a user who has administrative rights to the Windows NT system.
For more information, refer to the Windows NT online Help.Display the Services dialog box from the Control Panel:
Under Service, click the specific Calendar Server service (Admin, DWP, HTTP, ENS, or Notification) and then click Start or Stop.
- Start>Settings>Control Panel>Services
Troubleshooting the start-cal and stop-cal Commands
When you are starting and stopping the Calendar Server, the following problems might occur:
The start-cal command does not start all of the 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 of the Calendar Server processes before you try to restart the Calendar Server.
The stop-cal command does not stop all of the 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 a Windows NT system:
Log in as a user who has administrative rights to the system where the Calendar Server is running.
Use the Task Manager to identify and then stop any remaining Calendar Server processes.
To stop Calendar Server processes on Solaris and other UNIX systems:
Log in as a user who has administrative rights to the system where the Calendar Server is running.
Determine the process ID (PID) of the remaining Calendar Server processes by entering a ps command for each service:
Using the PID of each process that is still running, enter a pkill -15 command to kill the process. For example:
- ps -elf | grep cs-process
- where cs-process is enpd, csnotifyd, csdwpd, csadmind, or cshttpd. For example:
- ps -elf | grep cshttpd
Enter each ps command again to make sure that all Calendar Server processes are stopped.
- pkill -15 9875
- If a Calendar Server process is still running, enter a pkill -9 command to kill it. For example:
- pkill -9 9875
After you have stopped all of the Calendar Server processes and before you restart the 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
For information about editing ics.conf parameters, see "Editing the ics.conf Configuration File".
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.
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.
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. For example, a user can log in to Messenger Express and then use Calendar Express without authenticating again, if SSO is enabled for both applications.When configuring SSO, consider these points:
Each trusted application must be configured for SSO.
The following example shows an SSO configuration for the Calendar Server (Calendar Express) and Messaging Server (Messenger Express) for the sesta.com domain.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.
To configure Single Sign-on (SSO):
Log in as a user with administrator privileges.
Stop the Calendar Server and Messaging Server.
Edit the Calendar Server ics.conf file as described in Table 3-3. (For a description of the Calendar Server SSO configuration parameters, see "Single Sign-on (SSO) Configuration".)
Use configutil to set the Messaging Server configuration parameters as shown in Table 3-4. You do not have to enclose these parameters in double quotation marks (").
Restart the Calendar Server and Messaging Server to update the configurations.
- For more information, see "Starting and Stopping the Calendar Server". For information about the Messaging Server, see the iPlanet Messaging Server Administrator's Guide.
Configuring Database Wire Protocol (DWP)
DWP is a proprietary protocol used by the Calendar Server to perform calendar database operations over a network. DWP uses HTTP as its transport mechanism and includes a subset of the calendar database API.If the calendar database resides on the local server, the Calendar Server Database subsystem uses the calid to access a calendar in the database. However, if the calendar database is located over a network (such as, on a back-end server), the Calendar Server must use the Calendar Lookup Database plug-in to determine the network address of the server where a calendar actually resides. The request is then forwarded to the DWP (csdwpd) service on the other server for processing.
Front-End Machine and a Back-End Server
Figure 3-1 shows a Calendar Server configuration with a single front-end machine and a back-end server. To use DWP, the front-end machine and back-end server must be running the same operating system and the same version of the Calendar Server (such as 5.1).
Figure 3-1    Calendar Server Configuration for a Front-End Machine and a Back-End Server
In the configuration shown in Figure 3-1, the front-end machine performs these functions:
Handles client requests for calendar data residing over a network
The back-end server performs these functions:Makes requests to the back-end server for calendar data
Transforms the calendar data first into an XML document tree
Applies an XSL file to the XML document tree to produce HTML
To configure DWP, you must set ics.conf parameters on both the front-end machine and back-end servers.
To Configure DWP Parameters on a Front-End Machine:
On the front-end machine, log in as a user with administrator privileges.
Change to the server-root/cal/bin directory where the Calendar Server command-line utilities are located and stop the Calendar Server using the stop-cal command.
Change to the server-root/cal/bin/config/ directory and edit the ics.conf parameters shown in Table 3-5. (To configure multiple front-end machines that point to a single back-end server, see Multiple Front-End Machines.)
Change to the server-root/cal/bin directory where the Calendar Server command-line utilities are located and restart the Calendar Server using the start-cal command.
To Configure DWP Parameters on a Back-End Server:
On the back-end server, log in as a user with administrator privileges.
Change to the server-root/cal/bin directory where the Calendar Server command-line utilities are located and stop the Calendar Server using the stop-cal command.
Change to the server-root/cal/bin/config/ directory and edit the ics.conf parameters shown in Table 3-6.
Change to the server-root/cal/bin directory where the Calendar Server command-line utilities are located and restart the Calendar Server using the start-cal command.
You can now access the Calendar Server database on the back-end server from the front-end machine using Calendar Express. Here's how it works:
When the cshttpd service starts on the front-end machine, it initializes the Database subsystem. It loads the caldb.dwp.server.host.ip and caldb.dwp.server.host.port parameters from the ics.conf file and attempts to contact the back-end server using the host IP address and port values. If the contact is successful, the cshttpd service creates a pool of connections with the csdwpd service on the back-end server that are to used exclusively for DWP transactions.
Initially, the size of this connection pool is set to the value of the caldb.dwp.initconns. parameter, but the pool can grow to the maximum value specified by the caldb.dwp.maxcons parameter. Each connection in the pool is an HTTP/1.1 persistent connection, and if any connection fails, an error message is written to the log file.
If a DWP connection between the front-end machine and back-end server is broken (for example, the back-end server is restarted), the front-end machine tries to reconnect with the back-end server. Requests for calendar data fail while the DWP connection is broken, and data is not available until the connection is restored.
Multiple Front-End Machines
Figure 3-2 shows a Calendar Server configuration with multiple front-end machines and a single back-end server. The configuration parameters for both front-end machines (cal1.example.com and cal2.example.com) are identical and are described in To Configure DWP Parameters on a Front-End Machine:. You can add other front-end machines as well to distribute the front-end load.
Figure 3-2    Calendar Server Configuration for Multiple Front-End Machines and a Back-End Server
Managing LDAP Attributes
To manage the LDAP attributes used by Calendar Server, use the csattribute utility.
Listing LDAP Attributes
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:csattribute -a icsCalendar=Conference_Schedule add 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:csattribute -a icsCalendar delete 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 the 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 the first ten entries stored in the GSE queue:
To list all entries in the GSE queue for a calendar with the calid Holiday_Schedule:
csschedule -v list 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:
csschedule -v -t 20011130T133045Z -o 1 -u 1111 -r 0 -n 0 delete calA
Monitoring the Calendar Server
To monitor Calendar Server activity, use the csstats and cstool utilities. This section describes the following tasks:
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 the Calendar Server including:
Maximum number of concurrent connections and total number of connections
For more information about Calendar Server counter statistics, see Counters Configuration (counter.conf) File.Total number of successful and failed logins and connections
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 specifically about the httpstat counter object:
To list statistics about the wcapstat counter object every 10 seconds for one hour:
csstats -i 360 -s 10 list wcap
Monitoring the 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-7:
Table 3-7    Calendar Server Log Files
Service Name
Log File Name
Calendar Server log files are stored in the default log directory:
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:
admin.20000801115354.1
http.20000801115354.2
Log Event Severity Levels
The Calendar Server provides eight levels of severity for events reported to the log files as described in Table 3-8.
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 the 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 the Calendar Server. The NOTICE and INFORMATION level log events are generated during normal operation of the 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 the 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.The Calendar Server service options are:
http HTTP Service (cshttpd)
To run cstool, the Calendar Server must be running.admin Administration Service (csadmind)
Note In the current release, you cannot ping the Distributed Database 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:
cstool -p 80 -h calserver ping http
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
To force a Calendar Server service to refresh its configuration, use the cstool utility refresh command. If no service is specified, the command refreshes the configuration of all Calendar Server services.To run cstool, the Calendar Server must be running.
For example, to force a local Calendar Server to refresh configurations for all services:
Previous Contents Index Next
Copyright © 2002 Sun Microsystems, Inc. All rights reserved.
Last Updated January 22, 2002