Sun Java logo     Previous      Contents      Index      Next     

Sun logo
Sun Java System Calendar Server Administration Guide 

Chapter 1
Overview

Sun Java™ System Calendar Server 6 2004Q2 (Calendar Server), formerly 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.

For information about basic configuration scenarios, see the Sun Java System Calendar Server 6 2004Q2 Deployment Planning Guide at:

http://docs.sun.com/coll/CalendarServer_04q2

This chapter includes the following information:

Calendar Server Configurations

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

 

This chapter provides an overview of these configurations. For more information, see Configurations for the 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 Java System Identify Server processes can run on the same server or on different servers. A single-server minimal configuration includes the following components.

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 not on the same server as the cshttpd process, is not required for a minimal configuration because the database is on the same server.

Directory Server

Calendar Server requires that a calendar user entry be stored in a directory server. Calendar Server then uses the directory server for user authentication and for the storage and retrieval of user preferences. Calendar Server default installation supports users defined in an LDAP directory, such as the Sun Java System Directory Server, which can reside on the same machine as Calendar Server, or on a remote server.

If your users are already stored in an LDAP directory, you can simply upgrade your directory server to Directory Server, which supports the schema extensions that allow users to access Calendar Server. For information about Directory Server, see the following documentation Web site:

http://docs.sun.com/coll/DirectoryServer_04q2

However, if you prefer, you can use the Calendar Server API (CSAPI) to write a plug-in to use a non-LDAP directory server. This API is described in the Sun Java System Calendar Server 6 2004Q2 Developer’s Guide.

Sun Java System Identify Server

Sun Java System Identify Server (release 2003Q4 (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 one of the two Web user interfaces (UIs), that is, either Sun Java System Calendar Express, or Sun Java System Communications Express. For information on either user interface, refer to the respective interface’s online Help. Communications Express also has an Administration Guide that can be found at: http://docs.sun.com/coll/CalendarServer_04q2

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.

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 Java System Identify Server

You can use Identify Server (release 6.1 (release 6 2003Q4) or later) to implement single sign-on (SSO), and to use Sun LDAP Schema 2. To provision and manage hosted (virtual) domains, users, groups, organizations, resources, and roles use the User Management Utility, commadmin, which is built upon the Identity Server SDK.

End Users

End users connect from client machines to a front-end server by using one of the two Web user interfaces (UIs), that is, either Sun Java System Calendar Express (the old UI), or Sun Java System Communications Express (the new unified Web client).

For information on either user interface, refer to the respective interface’s online Help. Additional documentation for Communications Express is available at:

http://docs.sun.com/coll/CalendarServer_04q2

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.

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.

Identify Server

You can use Identify Server (release 6.1 (release 6 2003Q4) or later) to implement single sign-on (SSO), and to use Sun LDAP Schema 2. To provision and manage hosted (virtual) domains, users, groups, organizations, resources, and roles use the User Management Utility, commadmin, which is built upon the Identity Server SDK.

End Users

An end user connects from the client machine to a front-end server by using one of the two Web user interfaces (UIs), that is, either Sun Java System Calendar Express (the old UI), or Sun Java System Communications Express (the new unified Web client). For information on either user interface, refer to the respective interface’s online Help. Additional documentation for Communications Express can be found at:

http://docs.sun.com/coll/CalendarServer_04q2

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

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

 

Calendar Server Installation

The installation and configuration of Calendar Server has significantly changed from earlier Calendar Server releases (pre-2003Q4 versions). There is no longer a standalone installer for Calendar Server.

If you do not already have Calendar Server 2003Q4 (6.0) installed, you must use the Sun Java Enterprise System installer to get the 2004Q2 version. With this installer, you can also install other Sun component products and packages. For information about the Java Enterprise System installer, refer to the Sun Java Enterprise System 2004Q2 Installation Guide.

If you want to upgrade from Calendar Server 6 2003Q4 to Calendar Server 6 2004Q2, the upgrade process is described in “Upgrading from Java Enterprise System 2003Q4” in the Sun Java Enterprise System 2004Q2 Installation Guide.

For information about migrating from older versions of Calendar Server, refer to the information in Chapter 4, "Migration Utilities."

Post Installation Configuration

After you install Calendar Server 6 2004Q2, you must configure it. This step was previously performed as part of the installation process, but has now been separated out of the installer.

After you install Calendar Server, you must configure Calendar Server as follows:

  1. Run the Directory Server Setup script (comm_dssetup.pl) to configure Sun Java System 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 Appendix E, "Calendar Server Configuration Parameters"

Both comm_dssetup.pl and csconfigurator.sh are located in the following directory: /opt/SUNWics5/cal/sbin

For information about running comm_dssetup.pl and csconfigurator.sh, see Chapter 10, "Administering Calendar Server."

Calendar Server Administrators

Administrators for Calendar Server include:

Calendar Server Administrator (calmaster)

The Calendar Server administrator is a specific user name with its 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 Operating Systems, these special accounts are the user ID and group ID under which Calendar Server runs. Unless there are overriding reasons not to, 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 Operating 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.

Proxy Administrator Logins

To allow administrator proxy logins for Calendar Server, perform these steps:

  1. In the ics.conf file set, the following parameter:

    2. service.http.allowadminproxy = "yes"

  2. Restart Calendar Server for the new value to take effect.
  3. Verify that administrator proxy logins are working by using the following WCAP command:

    4. http://server[:port]/login.wcap?user=admin-user
    &password=admin-password&proxyauth=calendar-user

    where:

    • server is the name of the server where Calendar Server is running.
    • port is the Calendar Server port number. The default port is 80.
    • admin-user is the Calendar Server administrator. For example, calmaster.
    • admin-password is the password for admin-user.
    • calendar-user is the calid of the Calendar Server user.

      • If the command is successful, Calendar Server displays the calendar for calendar-user. If problems occur, Calendar Server displays “Unauthorized”. Causes might be:

    • The admin-user does not have Calendar Server administrator privileges.
    • The admin-password is incorrect.
    • The calendar-user is not a valid Calendar Server user.

 

Calendar Server End User Administration

End users connect to Calendar Server from client machines by using one of the two Web user interfaces (UIs), that is, either Sun Java System Calendar Express, or Sun Java System Communications Express. Users must have a unique entry in the LDAP directory. Each user can have one or more calendars and can belong to one or more groups.

Administrators, with the proper permissions, can add, delete or modify users and their calendars, using the User Management Utility.

This section describes the following aspects of user and user calendar administration:

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 Java System 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 Java System Calendar Server 6 2004Q2 Developer’s Guide.

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 Java System Calendar Server 6 2004Q2 Developer’s Guide.

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 12, "Administering Users and Resources."

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 Java System Calendar Server 6 2004Q2 Developer’s Guide.

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 one of the graphical user interfaces, for example, Sun Java System Calendar Express. For information, see the appropriate user interface’s 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 Access Control

Sun™ ONE 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).

This section covers these topics:

Secure Calendar Server Logins

When users log in to Calendar Server through Calendar Express, by default the authentication process does not encrypt the login information, including user names and passwords. If you want secure logins as your site, configure Calendar Server to use the Secure Sockets Layer (SSL) protocol to encrypt the login data. For more information, see Chapter 7, "Configuring SSL."

Access Control by Users

Calendar Server considers the following users when determining access to calendars, calendar properties, and calendar components:

Access Control Lists (ACLs)

Calendar Server uses access control lists (ACLs) to determine 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:

An ACE consists of the following elements, with each element separated by a caret (^):

For example, in the ACE jsmith^c^wd^g:

Who

The Who element is the principal value for an ACE and indicates who the ACE applies to, such an individual user, domain, or specific type of user.

Who is also called the Universal Principal Name (UPN). The UPN for a user is the user’s login name combined with the user’s domain. For example, user bill in domain sesta.com has the UPN bill@sesta.com.

Table 1-2 shows the Who formats used in Calendar Server ACEs.

Table 1-2  Who Formats for Access Control Entry (ACE) Strings 

Format

Description

user

Refers to a specific user. For example: jsmith.

user@domain

Refers to a specific user at a specific domain. For example: jsmith@sesta.com.

@domain

Refers to any user at the specified domain.

For example: @sesta.com specifies jsmith@sesta.com, sally@sesta.com, and anyone else at sesta.com.

Use this format to grant or deny access to an entire domain of users.

@

Refers to all users.

@@{p|o|n}

Refers to owners for the calendar:

  • @@p – primary owner only
  • @@o – all owners, including the primary owner
  • @@n – not an owner

What

The What element specifies the target being accessed, such as a calendar, calendar component (event or task), or calendar property.

Table 1-3 shows the What target values used in Calendar Server ACEs.

Table 1-3  What Values for Access Control Entry (ACE) Strings 

Value

Description

c

Specifies calendar components such as events and tasks

p

Specifies calendar properties such as name, description, owners, and so forth

a

Specifies an entire calendar (all), including both components and properties

How

The How element specifies the type of access control rights permitted, such as read, write, or delete.

Table 1-4 shows the How types of access control rights used in Calendar Server ACEs.

Table 1-4  How Types for Access Control Entry (ACE) Strings 

Type

Description

r

Read access.

w

Write access, including adding new items and modifying existing items.

d

Delete access.

s

Schedule (invite) access. Requests can be made, replies will be accepted, and other iTIP scheduling interactions will be honored.

f

Free/busy (availability) access only. Free/busy access means that a user can see scheduled time on a calendar, but is not allowed to see the event details. Instead, only the words “Not Available” appear by a scheduled time block. Blocks of time without any scheduled events are listed with the word “Available” next to them.

l

Lookup access for a domain.

e

Act on behalf of for reply access. This type grants a user the right to accept or decline invitations on behalf of the calendar’s primary owner. This type of access does not need to be granted explicitly because it is implied when a user is designated as an owner (an owner other than the primary owner) of a calendar.

i

Act on behalf of for invite access. This type grants a user the right to create and modify components in which other attendees have been invited on behalf of the calendar's primary owner. This type of access does not need to be granted explicitly because it is implied when a user is designated as an owner (an owner other than the primary owner) of a calendar.

c

Act on behalf of for cancel access. This type grants a user the right to cancel components to which attendees have been invited on behalf of the calendar's primary owner. This type of access does not need to be granted explicitly because it is implied when a user is designated as an owner (an owner other than the primary owner) of a calendar.

Grant

The Grant element specifies whether to grant or deny access for a specified access type, such as d (delete) or r (read).

Table 1-5 shows the Grant attribute values used in Calendar Server ACEs.

Table 1-5  Grant Values for Access Control Entry (ACE) Strings 

Value

Description

g   

Grant the specific access control right.

d   

Deny the specific access control right.

Examples of ACEs

The following examples show the use of ACEs:

Placing ACEs in an ACL

When the Calendar Server reads an ACL, it uses the first ACE it encounters that either grants or denies access to the target. Thus, the ordering of an ACL is significant, and ACE strings should be ordered such that the more specific ones appear before the more general ones.

For example, suppose the first ACE in an ACL for the calendar jsmith:sports grants read access to all users. Then, Calendar Server encounters a second ACE that denies bjones read access to this calendar. In this case, Calendar Server grants bjones read access to this calendar and ignores the second ACE because it is a conflict. Therefore, to ensure that an access right for a specific user such as bjones is honored, the ACE for bjones should be positioned in the ACL before more global entries such as an ACE that applies to all users of a calendar.

Calendar Server Internal Subsystems

Sun Java System 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 uses the Distributed Database Service (DWP) to provide a networking capability. For more information, see Distributed Database Service: csdwpd.

For information about the calendar database, refer to Chapter 14, "Administering Calendar Server Databases."

Calendar Server Services

Calendar Server services run as daemons (or processes) on Solaris Operating 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 back-end servers, that is, a server that has a calendar database, but does not provide user access services (cshttpd). It is not required on front-end servers that do not have a 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 Java System Calendar Server 6 2004Q2 Developer’s Guide.

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 Java System Calendar Server 6 2004Q2 Developer’s Guide.

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 Java System Communications Services 6 2004Q2 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 Java System Calendar Server 6 2004Q2 Developer’s Guide.



Previous      Contents      Index      Next     

Copyright 2004 Sun Microsystems, Inc. All rights reserved.