Sun logo      Previous      Contents      Index      Next     

Sun ONE Calendar Server 6.0 Administrator's Guide

Chapter 1
Introduction to Sun ONE Calendar Server

Sun™ ONE Calendar Server is a scalable, Web-based solution for centralized calendaring and scheduling for enterprises and service providers. Calendar Server supports personal and group calendars for both events and tasks as well as calendars for resources such as conference rooms and equipment.

This chapter includes the following information:

 


Calendar Server Configurations

Calendar Server configurations can vary depending on a site’s specific requirements. This chapter describes the following three basic configurations:

 

This chapter provides an overview of these configurations. For more information, see "Calendar Server Configurations for the LDAP CLD Plug-in".

Single-Server Minimal Configuration

In a single-server minimal configuration (shown in Figure 1-1), all Calendar Server services (processes) run on the same server, either in the same CPU (processor) or across multiple CPUs. The directory server and Sun ONE Identify Server processes can run on the same server or on different servers. A single-server minimal configuration includes the following components.

Sun ONE Calendar Server

A Calendar Server instance on a single server includes the following services:

For a description of Calendar Server services, see "Calendar Server Services".

The Database Wire Protocol (DWP) service (csdwpd process), which provides networking capability when the calendar database is on another server, is not required for a minimal configuration because the database is on the same server.

Directory Server

Calendar Server requires a directory server to authenticate users and to store user preferences. Usually, the directory server is an LDAP directory server such as Sun ONE Directory Server. However, if you prefer, you can use the Calendar Server API (CSAPI) to write a plug-in to use a non-LDAP directory server.

The directory server can run on the same server where Calendar Server is running or on a remote server.

Sun ONE Identify Server

Sun ONE Identify Server 6.1 (or later) provides the following functions:

Identify Server can run on the same server where Calendar Server is running or on a remote server.

End Users

End users connect to Calendar Server from client machines by using the Sun ONE Calendar Express Web user interface (UI). For information, refer to the Calendar Express online Help.

Figure 1-1  Single-Server Minimal Calendar Server Configuration

Minimal Calendar Server configuration

 

Network Front-End/Database Back-End Server Configuration

Calendar Server supports scalability by distributing a configuration over multiple front-end and back-end servers. On each server, Calendar Server services (processes or daemons) can also be distributed across multiple CPUs (or processors).

In network front-end/database back-end configuration (shown in Figure 1-2), users log in to a front-end server and connect to a back-end server using the Database Wire Protocol (DWP) service (csdwpd process). The calendar database is connected only to the back-end servers.

Sun ONE Calendar Server

Calendar Server processes run on both the front-end and back-end servers as follows:

For a description of Calendar Server services, see "Calendar Server Services".

Directory Server

A scalable Calendar Server configuration requires a Directory Server to authenticate users and to store user preferences.

Sun ONE Identify Server

You can use Sun ONE Identify Server (release 6.1 or later) to implement Single Sign-on (SSO), to use Sun ONE LDAP Schema, v.2, or to provision and manage hosted (virtual) domains, users, groups, organizations, resources, and roles.

End Users

End users connect from client machines to a front-end server by using the Sun ONE Calendar Express Web user interface (UI). For information, refer to the Calendar Express online Help.

Figure 1-2  Network Front-End/Database Back-End Server Configuration

Scalable Calendar Server configuration

 

Multiple Front-End/Back-End Server Configuration

In a multiple front-end/back-end server configuration (shown in Figure 1-3), users log in to a specific server, and each server is connected to a calendar database. This configuration allows calendars to be geographically distributed, with each calendar residing on the server where its owner logs in to Calendar Server.

Sun ONE Calendar Server

Each front-end/back-end server requires all Calendar Server services: Administration service (csadmind process), HTTP service (cshttpd process), Event Notification Service (enpd and csnotifyd processes), and Database Wire Protocol (DWP) service (csdwpd process).

For a description of Calendar Server services, see "Calendar Server Services".

Directory Server

A multiple front-end/back-end server configuration requires a Directory Server to authenticate users and to store user preferences.

Sun ONE Identify Server

You can use Sun ONE Identify Server (release 6.1 or later) to implement Single Sign-on (SSO), to use Sun ONE LDAP Schema, v.2, or to provision and manage hosted (virtual) domains, users, groups, organizations, resources, and roles.

End Users

An end user connects from the client machine to a front-end server by using the Sun ONE Calendar Express Web user interface (UI). For information, refer to the Calendar Express online Help.

Figure 1-3  Multiple Front-End/Back-End Server Configuration

Calendar Server Configuration for Multiple Front-End/Back-End Servers

 


Calendar Server Installation and Configuration

The installation and configuration of Sun ONE Calendar Server 6.0 (and later) on Solaris Systems has significant changes from previous Calendar Server releases. To install Calendar Server on Solaris Systems, you must use the Sun Java Enterprise System installer, which also installs other Sun component products and packages.

For information about the Java Enterprise System installer, refer to the Sun Java Enterprise System Installation Guide.

After you install Calendar Server using the Java Enterprise System installer, you must configure Calendar Server as follows:

  1. Run the Directory Server Setup script (comm_dssetup.pl) to configure Sun ONE Directory Server 5.x (if the script has not already been run).
  2. Run the Calendar Server configuration program (csconfigurator.sh) to configure your site’s specific requirements and to create a new ics.conf configuration file. For a description of the parameters in the ics.conf file, see Chapter 12, "Calendar Server Configuration Parameters."

Both comm_dssetup.pl and csconfigurator.sh are located in the following directory:

/opt/SUNWics5/cal/sbin directory.

For information about running comm_dssetup.pl and csconfigurator.sh, refer to the Sun ONE Calendar Server 6.0 Installation Guide for Solaris Operating Systems.


Calendar Server Administrators

Administrators for Calendar Server include:

Calendar Server Administrator (calmaster)

The Calendar Server administrator is the user name and associated password that can manage Calendar Server. For example, a Calendar Server administrator can start and stop Calendar Server services, add and delete users, create and delete calendars, and so on. This user has administrator privileges for Calendar Server but not necessarily for the directory server.

The default user ID for the Calendar Server administrator is calmaster, but you can specify a different user during Calendar Server configuration, if you prefer. After installation you can also specify a different user in the service.admin.calmaster.userid parameter 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 configuration, the configuration program can create it for you.

Table 1-1 describes the Calendar Server administrator configuration parameters in the ics.conf file.

Table 1-1  Calendar Server Administrator Configuration Parameters 

Parameter

Description

service.admin.calmaster.userid

User ID of the person designated as the Calendar Server administrator. You must provide this required value during Calendar Server installation. The default is "calmaster".

service.admin.calmaster.cred

Password of the user ID specified as the Calendar Server administrator. You must provide this required value during installation.

caldb.calmaster

Email address of the Calendar Server administrator. The default is "root@localhost".

service.admin.calmaster.overrides.accesscontrol

Indicates whether the Calendar Server administrator can override access control.The default is "no".

service.admin.calmaster.wcap.allowgetmodifyuserprefs

Indicates whether the Calendar Server administrator can get and set user preferences using WCAP commands.The default is "no".

service.admin.ldap.enable

Enables the LDAP server for user authentication of the user specified in service.admin.calmaster.userid. The default is “yes”.

Calendar Server User and Group

On Solaris Systems, these special accounts are the user ID and group ID under which Calendar Server runs. Sun recommends that you use the default values, icsuser and icsgroup, which are automatically created by the configuration program, if they do not exist. If you prefer, however, you can specify values other than icsuser and icsgroup when you run the Calendar Server configuration program. These values are stored in the local.serveruid and local.servergid parameters, respectively, in the ics.conf file.

Superuser (root)

On Solaris Systems, you must log in as or become superuser (root) to install Calendar Server. You can also run as superuser to manage Calendar Server using the command-line utilities. For some tasks, however, you should run as icsuser and icsgroup (or the values you have selected) rather than superuser to avoid access problems for Calendar Server files.


Calendar Server End Users

End users connect to Calendar Server from client machines by using the Sun ONE Calendar Express Web user interface (UI). This section describes:

Creation of Calendar Server Users

Calendar Server users are created either manually or automatically:

Authentication of Calendar Server Users

Calendar Server requires a directory server such Sun ONE Directory Server to authenticate users (and to store user preferences). However, To allow access for users defined in a non-LDAP directory server, Calendar Server includes the Calendar Server API (CSAPI), which you can use to write a plug-in to access a non-LDAP directory. For information about CSAPI, refer to the Sun ONE Calendar Server 6.0 Programmer’s Manual.

Calendar Server User Preferences

Calendar Server allows users to customize their views of calendar data by setting user preferences attributes, which are stored in the directory server. User preferences (as opposed to Calendar Server configuration parameters) refer to the user interface representation of calendar data and include items such as user name, email address, and preferred colors to use when rendering calendar views.

For a list of preferences, refer to the get_userprefs and set_userprefs WCAP commands in the Sun ONE Calendar Server 6.0 Programmer’s Manual.

Calendar Groups

A calendar group is a named list of individual calendars. Group calendars allow multiple calendars to be combined into a single calendar for viewing. For example, a user can have a calendar group consisting of a private calendar, department calendar, and company holidays calendar. Users can also use a calendar group to select a list of calendars and view them side-by-side or invite the calendar owners to an event.

For more information about Calendar Server users, see Chapter 2, "Managing Calendar Server Users and Calendars."


Calendar Server Data

This section describes the following information about Calendar Server data:

Calendar Server Data Format

Calendar Server data format is modeled after RFC 2445, Internet Calendaring and Scheduling Core Object Specification (iCalendar). Calendar Server supports the following formats:

You can add other formats by developing your own XSL translations for the Calendar Express views and dialogs. You can also use CSAPI to develop a translator DLL or shared library for the WCAP protocol. For information about WCAP and CSAPI, see the Sun ONE Calendar Server 6.0 Programmer’s Manual.

Import and Export of Calendar Data

Calendar data can be imported and exported in either iCalendar (.ical) or XML (.xml) format. End users import and export data using Sun ONE Calendar Express. For information, see the Calendar Express online help. Calendar Server administrators can import and export calendar data using the Calendar Server csimport and csexport utilities.

Calendar Links for Data Exchange

Calendars can be referenced as links embedded in email messages and on Web pages. Users can then click a link to view a calendar as long as the calendar allows read access, without having to log into Calendar Server. For example, the following link specifies a resource room named Auditorium:

http://calendar.sesta.com:8080/?calid=Auditorium

Calendar Server Alarms

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. 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 Internal Subsystems

Sun ONE Calendar Server includes the following internal subsystems:

Figure 1-4 shows the logical flow through these subsystems.

Figure 1-4  Calendar Server Internal Subsystems Logical Flow

Calendar Server Internal Subsystems Logical Flow

 

Protocol Subsystem

Commands and requests enter through the HTTP protocol layer. This is a minimal HTTP server implementation, streamlined to support calendar requests.

Clients use SHTML or Web Calendar Access Protocol (WCAP) commands to submit requests:

Core Subsystem

The Core subsystem includes the access control subsystem, user interface (UI) generator subsystem (either SHTML using XML and XSLT or WCAP using data translators), calendar database 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) and Proxy Authentication SDK (authSDK).

Database Subsystem

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 database, Calendar Server to provide a networking capability. For more information, see "Distributed Database Service: csdwpd".

For information about the calendar database, refer to Chapter 5, "Managing Calendar Server Databases."


Calendar Server Services

Calendar Server services run as daemons (or processes) on Solaris Systems. These services include:

Administration Service: csadmind

The csadmind service provides a single point of authentication for administering Calendar Server, including most administration utilities (for example, start and stop commands, create and delete users, create and delete calendars, and so on). 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 Calendar Server uses HTTP as its primary transport, the cshttpd service listens for HTTP commands from Calendar Server end users, receives the user commands, and returns calendar data, depending on the format of the incoming command:

Event Notification Service (ENS): csnotifyd and enpd

The ENS service consists of these individual services:

Distributed Database Service: csdwpd

The csdwpd service is required only on a server that has a local calendar database. The csdwpd service allows you to link front-end/back-end servers within the same Calendar Server configuration to form a distributed calendar store.

The csdwpd service runs in the background on a back-end server and accepts requests that follow the Database Wire Protocol (DWP) for accessing the calendar database. DWP is an internal protocol used to provide networking capability for the Calendar Server database.


Calendar Server APIs and SDKs

Calendar Server includes the following APIs and SDKs:

Web Calendar Access Protocol (WCAP)

Calendar Server supports WCAP 3.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 generally follow RFC 2445, RFC 2446, and RFC 2447 specifications.

WCAP returns output calendar data in an HTTP message in the following formats:

Using WCAP commands, a Calendar Server administrator who logs in using the login.wcap has the following capabilities:

For more information, see the Sun ONE Calendar Server 6.0 Programmer’s Manual.

Calendar Server API (CSAPI)

The Calendar Server API (CSAPI) allows you to customize functional areas of Calendar Server such as user login authentication, access control, and calendar lookup. For example, by default Calendar Server uses entries in an LDAP directory server to authenticate users and to store user preferences. The CSAPI allows you to override the default Calendar Server authentication by implementing another authentication mechanism that is not based on an LDAP directory server.

For information about CSAPI, see the Sun ONE Calendar Server 6.0 Programmer’s Manual.

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 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: Published API, Subscriber API, and Publish and Subscribe Dispatcher API.

For information about the ENS API, see the Sun ONE Messaging and Collaboration 6.0 Event Notification Service Manual.

Proxy Authentication SDK (authSDK)

Calendar Server provides the authSDK for user authentication. With authSDK, you can integrate an existing portal service with Calendar Server, thus allowing users to access various applications without requiring re-authentication. The authSDK consists of the functions packaged in a DLL/shared-object library and a header file.

A connection established between Calendar Server and the authSDK forms a trusted relationship. If a user logs in and successfully authenticates to the authSDK, Calendar Server accepts the certificate generated by the proxy for its functions.

For information about authSDK, see the Sun ONE Calendar Server 6.0 Programmer’s Manual.



Previous      Contents      Index      Next     


Copyright 2003 Sun Microsystems, Inc. All rights reserved.