|Previous Contents Index Next|
|iPlanet Calendar Server Administrator's Guide|
Chapter 1 Introduction to iPlanet Calendar Server
iPlanet Calendar Server is a scalable, Web-based solution for centralized calendaring and scheduling for enterprises and service providers. The Calendar Server supports personal and group calendars as well calendars for resources such as conference rooms and equipment.
This chapter contains these sections:
Calendar Server Administrators
Calendar Server Administrators
Calendar Server Administrator (calmaster)
Calendar Server Administrator (calmaster)
The Calendar Server Administrator is the user name and associated password that can manage the Calendar Server. This user has administration privileges for the Calendar Server but not for the directory server. The default user ID is calmaster, but you can specify a different user during installation, if you wish. After installation you can specify a different user in service.admin.calmaster.userid in the ics.conf file.
The user ID you specify for the Calendar Server Administrator must be a valid user account in your directory server. If the Calendar Server Administrator user account does not exist in the directory server during installation, you must add it after installation. For example, if you accept the default calmaster, a user named calmaster must exist in your directory server.
Table 1-1 describes the Calendar Server Administrator configuration parameters in the ics.conf file.
Calendar Server User and Group (UNIX only)
On Solaris and other UNIX systems, these accounts are the UNIX user and group identity under which Calendar Server runs. iPlanet recommends that you use the default values, icsuser and icsgroup, which are automatically created by the installation program if they do not exist. The icsuser and icsgroup values are stored in the local.serveruid and local.servergid parameters, respectively, in the ics.conf file.
root (UNIX only)
On Solaris and other UNIX systems, you must log in as (or become) root (user ID = 0) to install, re-install, or upgrade the Calendar Server. To manage the Calendar Server using the command-line utilities, you must log in as (or become) root or an administrator such as icsuser.
Windows NT Administrator
To install and manage the Calendar Server on Windows NT systems, you must log in as an administrator with full administrator rights to the system.
Calendar Server Users
Creation of Calendar Server Users
Calendar Server users are created either manually or automatically:
Manually A administrator can add users to the directory server using the directory server tools and then create the users' default calendars using the Calendar Server cscal utility. If a user doesn't already exist in the directory server, an administrator can create both the user and the calendar at the same time using the Calendar Server csuser utility.
Automatically If a user already exists in the directory server, the Calendar Server automatically creates a default calendar the first time the user logs in. The Calendar Server uses the user's user ID for the calendar ID (calid) of default calendar (unless a calendar by that name already exists).
- For example, suppose TChang exists in the directory server but is not yet enabled for calendaring (that is, does not have a default calendar). When TChang logs into the Calendar Server for the first time, it automatically enables TChang for calendaring and creates a default calendar with the calid TChang.
Authentication of Calendar Server Users
The Calendar Server stores and manages calendars, calendar properties, access control information, events, todos (tasks), and alarms. The Calendar Server, however, requires a directory service such as an LDAP server for user authentication and for the storage and retrieval of user preferences.
The Calendar Server default installation supports users defined and maintained in an LDAP directory, such as Netscape Directory Server. To allow access for users defined in a non-LDAP directory server, the Calendar Server also supports Calendar Server API (CSAPI) plug-ins.
For more information, see "Provisioning New Calendar Server Users".
Calendar Server Data
Calendar Server Data FormatFor information about access control for data, see "Calendar Server Access Control".
Calendar Server Data Format
The Calendar Server data format is modeled after RFC 2445, Internet Calendaring and Scheduling Core Object Specification (iCalendar). The Calendar Server stores and manages calendars, calendar properties, access control information, events, todos (tasks), and alarms. The Calendar Server, however, does not manage user information. It requires a directory service to perform operations such as user authentication and the storage and retrieval of user preferences.
Calendar Server Format Encoding
The Calendar Server supports the following format encodings:
For details about CSAPI, see the iPlanet Calendar Server Programmer's Manual.
A calendar group is a named list of individual calendars. Group calendars allow multiple calendars to be combined into a single calendar for display purposes. A user can, for example, have a calendar group made up of a private calendar, department calendar, and a company holidays calendar.
Users can create or subscribe to calendar groups and then view and modify the calendar group (subject to access control). They can then view the calendar group, rather than having to select a list of calendars each time they want to view them side-by-side or invite the calendar owners to an event.
Calendar Server Event Feeds
The Calendar Server supports event feeds, which allows users to import and export calendar data in either iCalendar (.ics) or XML (.xml) formats. End users can import and export data using Calendar Express. For information, see the Calendar Express online help.
Users can also subscribe to event or group calendars such as holiday schedules, convention center schedules, concert schedules, or any other schedule of events that might be of interest.
Calendar Server administrators can also import and export calendar data using the csimport and csexport command-line utilities.
Calendar Server Data Exchange and Alarms
Calendars can be referenced as links that can be embedded in email messages and Web pages. Users can then click a link to view a calendar, and as long as the calendar allows read access, are not required to log into the Calendar Server. For example, the following link specifies a resource room named Auditorium:
The Calendar Server supports server-side email alarms, which can be sent to a list of recipients. The format of the email message is configurable and is maintained as a server attribute, rather than as a user or calendar attribute. The Calendar Server has limited support for the ITIP/IMIP standards (RFC-2446 and RFC-2447), including ITIP methods PUBLISH, REQUEST, REPLY, and CANCEL for events.
Calendar Server User Preferences
The Calendar Server customizes the display of calendar information for each user according to attributes called user preferences. User preferences (as opposed to calendar preferences) refer to the user interface representation of calendar information. User preferences include such things as email address, user name, and preferred colors to use when rendering calendar information. For a list of preferences, see the get_userprefs and set_userprefs commands in the iPlanet Calendar Server Programmer's Manual.
Calendar Server Architecture
Calendar Server Internal Subsystems
The Calendar Server includes a collection of shared libraries that make up the following internal subsystems:
Figure 1-1    Calendar Server Internal Subsystems Logical Flow
Commands and requests enter through the HTTP protocol layer. This is a minimal HTTP server implementation, streamlined to support calendar requests.
Clients use either SHTML or Web Calendar Access Protocol (WCAP) to submit requests:
SHTML is based on XML and XSLT specifications, which generate a user interface in response to commands. In response to an incoming request, the UI generator uses an XML specification to build a document tree with calendar and user data, subject to access control. The XSLT specification then traverses the document data tree and emits HTML. This design results in fewer interactions between the client and server, which reduces the network traffic.
The Core subsystem includes the Access Control subsystem, the UI Generator subsystem (either SHTML using XML and XSLT or WCAP using data translators), Caldb subsystem, and any CSAPI plug-ins. The Core subsystem processes calendar requests and generates the desired UI output. The Core subsystem also handles user authentication including:
Calendar Server API (CSAPI) authentication
Single Sign-on (SSO) authentication
The Database subsystem uses the Berkeley DB from Sleepycat Software (the database API is not public). The Database subsystem stores and retrieves calendar data to and from the database, including events, todos (tasks), and alarms. Calendar data is based on iCalendar format, and the schema used for Calendar Server data is a superset of the iCalendar standard. The Database subsystem returns data in a low-level format, and the Core UI generator (either SHTML or WCAP) then translates the low-level data into the desired output.
For a distributed calendar store, the Calendar Server use the Database Wire Protocol (DWP) to provide a networking capability. For more information, see "Distributed Database Service - csdwpd".
For information about managing the database, see Chapter 5 "Managing Calendar Server Databases," which describes how to manage databases and calendar data using the csdb utility.
Calendar Server Services
Administration Service - csadmindThese services run as processes (or daemons on UNIX systems) on a single machine or on multiple machines, depending on your configuration.
Administration Service - csadmind
The csadmind service is required for each instance of the Calendar Server. It provides a single point of authentication for administering the Calendar Server and provides most of the administration tools such as commands to start or stop a service, list or log out users, create or delete users or resources, fetch or store calendars, and fetch or reset counters. The csadmind service also manages alarm notifications, group scheduling requests, database checkpointing, and deadlock detection, as well as disk usage and server response monitoring.
HTTP Service - cshttpd
Since the Calendar Server uses HTTP as its primary transport, the cshttpd service listens for HTTP commands. The cshttpd service receives user commands and returns data to the caller, depending on the format of the incoming command:
For a command received with the default .shtml extension, cshttpd returns data formatted in HTML.
Notification Service - csnotifyd
The csnotifyd service sends notifications of events and todos (tasks) using the Event Notification Service (ENS) as the broker for events. csnotifyd also subscribes to alarm events. When an alarm event occurs, csnotifyd sends an SMTP message reminder to the recipients.
Event Notification Service (ENS) - enpd
The enpd service is the other half of the Event Notification Service (ENS) and acts as the broker for event alarms. enpd receives notifications of alarms from the csadmind service, checks for subscriptions to this event, and then notifies the event's subscribers by passing the subscribed-to alarm notifications to csnotifyd. enpd also receives and stores subscriptions and cancellations of subscriptions (unsubscribe) from csnotifyd.
Distributed Database Service - csdwpd
The csdwpd service allows you to link multiple servers together within the same Calendar Server system to form a distributed calendar store. csdwpd can run in the background on any server where the Calendar Server is installed. It then accepts requests that follow the Database Wire Protocol (DWP) for calendar information. DWP is an internal protocol used to provide networking capability for the Calendar Server database.
The csdwpd service should be run only on a server that has a local calendar database and must provide network access to its calendar data from other Calendar Server installations.
You should use DWP only on a relatively fast network. If the network connection between the various databases is slow, DWP can degrade overall system performance.
Basic Calendar Server Configurations
The Calendar Server can be configured to fit the different needs of an organization. For example, it can run as a stand-alone server, or it can be configured with multiple instances, with the various Calendar Server services duplicated or split between the instances.
This section describes these basic Calendar Server configurations:
Minimal Calendar Server Configuration
Figure 1-2 shows a minimal Calendar Server configuration, including a:
Single Calendar Server instance with support for event notifications. This configuration consists of the required Administration Service (csadmind), the HTTP service (cshttpd) to handle incoming SHTML and WCAP requests, and the Event Notification Services (ENS), enpd and csnotifyd.In Figure 1-2, CLD is the Calendar Lookup Database. CUA is a Calendar User Agent, which is an application that a calendar client uses to access the Calendar Server. iCal refers to RFC 2445, Internet Calendaring and Scheduling Core Object Specification (iCalendar). The calendar database is local, so the Database Wire Protocol (DWP) service is not required.
Figure 1-2    Minimal Calendar Server Configuration
Scalable Calendar Server Configuration
The Calendar Server is scalable both vertically and horizontally. The Calendar Server can run in multiple processors on a single machine or on multiple machines. The Calendar Server consists of the cshttpd, csadmind, csdwpd, csnotifyd, and enpd. services, which can be run in different configurations to allow you great flexibility and scalability.
The Calendar Server supports horizontal scalability, which is spreading an installation over several machines. To achieve horizontal scalability, you can install various instances of the Calendar Server across your machines. The basic requirements for each system are:
Each Calendar Server instance must have an Administration (csadmind) service. You can, however, install the Event Notification Services (ENS) enpd and csnotifyd on a separate instance without the csadmind service.Figure 1-3 shows three Calendar Server HTTP front-end services using three Calendar Server database services. All six of these instances can run on separate machines.
All other Calendar Server services must be installed at least once, unless you have a single-instance installation using a local database. In this installation, the DWP (csdwpd) service is not required because the calendar database is local.
This configuration uses the Database Wire Protocol (DWP), which is an internal protocol that provides networking capability for the Calendar Server database. DWP uses HTTP as its base, with an HTTP POST or GET command with a single binary MIME part that contains serialized binary database information. For more information, see Distributed Database Service - csdwpd.
Figure 1-3    Scalable Calendar Server Configuration
Calendar Server Access Control
The Calendar Server uses access control lists (ACLs) to determine the access control for calendars, calendar properties, and calendar components such as events and todos (tasks). An ACL consists of one or more access control entries (ACEs), which are strings that collectively apply to the same calendar or component. Each ACE in an ACL must be separated by a semicolon. For example:
Calendar properties - Only the primary owner of a calendar or an administrator can delete a calendar or change the calendar's properties, including its ACLs.End users set the access control for their calendars using Calendar Express. Calendar Server administrators can set access control configuration parameters in the ics.conf file and use the cscal, csresource, and csuser command-line utilities.
Group scheduling - When an organizer schedules a group event, the Calendar Server uses ACLs to determine the access to the invitees' calendars. For example, the organizer of an event might be able to view only the free/busy time for an attendee and not the attendee's entire calendar.
Other owners - The primary owner of a calendar can specify other owners of the calendar to act in their behalf. For example, a primary owner such as a vice president can designate an administrative assistant to schedule meetings and invite attendees, or to cancel or accept invitations to meetings scheduled by others.
For more information, see Chapter 4 "Managing Calendar Server Access Control."
Calendar Server APIs and SDKs
Calendar Server API (CSAPI)For detailed information about these APIs, see the iPlanet Calendar Server Programmer's Manual.
Calendar Server API (CSAPI)
The Calendar Server API (CSAPI) allows a programmer to customize functional areas of the Calendar Server such as user login authentication, access control, and calendar lookup.
For example, by default the Calendar Server uses entries in an LDAP server to authenticate users and to store user preferences. If you have another mechanism that is not based on LDAP, you can use CSAPI to implement your existing authentication and directory services and override the default Calendar Server mechanisms.
Event Notification Service (ENS) API
The Event Notification Service (ENS) is an alarm dispatcher that detects events on an alarm queue and sends notifications of these events to its subscribers. The ENS API allows programmers to modify publish-and-subscribe functions used by the Calendar Server to perform functions such as subscribe to events, unsubscribe to events, and notify a subscriber of events. The ENS APIs consists of these specific APIs:
Proxy Authentication SDK (authSDK)
The Calendar Server provides the authSDK for user authentication. With authSDK, you can integrate an existing portal service with the Calendar Server, thus allowing users to access various applications without requiring re-authentication.
A connection established between the Calendar Server and the authSDK forms a trusted relationship. If a user logs in and successfully authenticates to the authSDK, the Calendar Server accepts the certificate generated by the proxy for its functions.
The authSDK consists of the following functions packaged in a DLL/shared-object library (libicsexp10) and a header (file, expapi.h):
CEXP_GenerateLoginURL generates a URL with the valid session ID.
Web Calendar Access Protocol (WCAP)
iPlanet Calendar Server 5.x supports WCAP 2.0, a high-level, command-based protocol that allows communication with clients. WCAP commands, which use the .wcap extension, allow clients to get, modify, and delete calendar components, user preferences, calendar properties, and other calendar information such as time zones. WCAP elements such as times, strings, and parameters follow RFC2445, RFC2446, and RFC2447 specifications (unless otherwise noted).
WCAP returns output calendar data in an HTTP message in the following formats:
Standard RFC2445 iCalendar format (text/calendar)Using WCAP commands, a Calendar Server administrator who logs in using login.wcap has the following capabilities:
To override the access control of WCAP commandsFor more information, see the iPlanet Calendar Server Programmer's Manual.
To retrieve and modify user preferences for any user
- The administrator can use WCAP commands to read (fetch), alter (store), or delete other user's calendars. For an administrator to have this privilege, the following parameter in the ics.conf file must be set to "yes":
Single Sign-on (SSO)
Single Sign-on (SSO) allows a user to authenticate once and then use multiple applications. For example, a user can log into Calendar Express and then use Messenger Express without authenticating again.
SSO is independent from other authentication mechanisms, session management, and resource access control. With SSO, applications form circles of trust that share cookies and accept each others' user authentication. Each verification authority stores a cookie that is understood by the other applications' verification routines. Each application can also have its own verification interface, if necessary.
SSO has the following requirements:
The client browser must accept cookies.To enable SSO between applications, you must configure each application. For information about configuring Calendar Server, see "Configuring Single Sign-on (SSO)".
Calendar Server Deployment Configurations
In addition to the Minimal Calendar Server Configuration (Figure 1-2) and the Scalable Calendar Server Configuration (Figure 1-3), two other Calendar Server configurations are:
Network Front End, Single Database Back End
serviceFigure 1-4 shows a configuration where client browsers and applications connect to the Calendar Server through the HTTP (cshttp) service at the front end (cal.example.com). All requests for calendar data are then routed to the back end (caldb.example.com) using the DWP (csdwpd) service.
The front end requires only the HTTP (cshttp) and Administration (csadmind) services, because it does not perform any database processing. The back end does not require cshttpd, but it does require the Administration (csadmind) and DWP (csdwpd) services and the Event Notification Services (ENS), enpd and csnotifyd.
Figure 1-4    Network Front End, Database Back End
Multiple Front Ends, Multiple Database Back Ends
Figure 1-5 shows a configuration where clients are routed to one of the front-end HTTP (cshttp) services by a user-supplied mechanism. The session ID returned at login is valid only on the host system where the login occurred. All requests for this session ID must be routed to the same host, or the user is forced to log in again.
In this example, the database has been distributed, with calendars A-M on the caldb1.example.com server and calendars N-Z on the caldb2.example.com server. A CSAPI plug-in handles the mapping between calendar IDs and the server where the calendar is located. (The default CSAPI implementation provided by the Calendar Server uses an algorithm to associate a calendar ID with a server name. See "Calendar Lookup Database Plug-in" for more information.)
Each front end requires the HTTP (cshttp) and Administration (csadmind) services. All requests for calendar data are routed to the appropriate back end using the DWP (csdwpd) service. Each back end requires the Administration (csadmind) and DWP (csdwpd) services and the Event Notification Services (ENS), enpd and csnotifyd.
Figure 1-5    Multiple Front Ends, Multiple Database Back Ends
Previous Contents Index Next
Copyright © 2002 Sun Microsystems, Inc. All rights reserved.
Last Updated January 22, 2002