Chapter 1 Overview of Calendar Server 6.3 Software

Sun Java^TM System Calendar Server 6.3 (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 Communications Suite 5 Deployment Planning Guide.

This chapter covers the following topics:

• 1.1 Calendar Server 6.3 Software Installation

• 1.2 Post Installation Configuration for Calendar Server Version 6.3

• 1.3 Special Accounts for Calendar Server Version 6.3

• 1.4 Proxy Administrator Logins for Calendar Server Version 6.3

• 1.5 End User Administration in Calendar Server Version 6.3

• 1.6 Data Formats and Standards Overview for Calendar Server Version 6.3

• 1.7 LDAP Data Cache Option for Calendar Server Version 6.3

• 1.8 Access Control for Calendar Server Version 6.3

• 1.9 Internal Subsystems for Calendar Server Version 6.3

• 1.10 Services Running As Daemons in Calendar Server Version 6.3

• 1.11 Public APIs for Calendar Server Version 6.3

In this and subsequent chapters, when fully qualified directory paths are specified, they are for the Solaris platform. The default paths for Solaris are:

/opt/SUNWics5/cal

/var/opt/SUNWics5

/etc/opt/SUNWics5

The default paths for Linux® are:

/opt/sun/calendar

/var/opt/sun/

/etc/opt/sun

Linux users should substitute their default path in any command showing the Solaris default.

1.1 Calendar Server 6.3 Software Installation

The installation of Calendar Server 6.3 has significantly changed from earlier Calendar Server releases. You must use the Communications Suite installer to install Calendar Server 6.3 software. Do not use the Java Enterprise System installer. However, you may need to use the Java Enterprise System Installer to install other server products.

For more information about installing Calendar Server 6.3, see .Sun Java Communications Suite 5 Installation Guide

If you want to upgrade from an earlier version of Calendar Server, the upgrade process is described in the Sun Java Communications Suite 5 Upgrade Guide.

For information about migrating your calendar databases and LDAP database from older versions of Calendar Server to version 6.3, refer to the information found in Chapter 3, Database Migration Utilities for Calendar Server 6.3.

1.2 Post Installation Configuration for Calendar Server Version 6.3

After you install Calendar Server, you must configure it. The installer does not perform configuration as part of the installation process.

High Level Task List for Post Installation Configuration for Calendar Server Version 6.3

1. Run the Directory Server Setup script, comm_dssetup.pl, to configure Sun Java System Directory Server 5 (if the script has not already been run).

   This script is located in the following directory: /opt/SUNWcomds/sbin.

   For information about running it, see the Sun Java Communications Suite 5 Installation Guide.

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.

   The configuration program is located in the following directory: /opt/SUNWics5/sbin

   For information about running csconfigurator.sh, see Chapter 2, Initial Runtime Configuration Program for Calendar Server 6.3 software (csconfigurator.sh).

3. Customize your system by editing parameters in the ics.conf file.

   The chapters in Part III, Customizing Your Calendar Server Configuration describe how to customize your system by editing the ics.conf file.

   ---

   Note –

   Its possible for the ics.conf to contain duplicate parameters with different values. The system reads the file sequentially, updating system settings as it goes along. With this method, the last value it finds for this parameter is the one that gets used.

   As a best practice, add all of your ics.conf settings to the end of the file so you will know which ones you have set. But to improve efficiency, comment out the older instances of the parameter. This helps because the fewer parameters the system has to read, the faster it can process the file.

   ---

1.3 Special Accounts for Calendar Server Version 6.3

Calendar Server special accounts include the following:

• 1.3.1 Calendar Server Administrator (calmaster) Account in Calendar Server Version 6.3

• 1.3.2 Calendar Server User and Group Accounts for Calendar Server Version 6.3

• 1.3.3 Superuser (root)

• 1.3.4 Non-root User (icsuser, icsgroup) for Calendar Server Version 6.3

1.3.1 Calendar Server Administrator (calmaster) Account in Calendar Server Version 6.3

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.siteadmin.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.

The following table describes the Calendar Server administrator configuration parameters in the ics.conf file.

1.3.2 Calendar Server User and Group Accounts for Calendar Server Version 6.3

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.

1.3.3 Superuser (root)

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.

1.3.4 Non-root User (icsuser, icsgroup) for Calendar Server Version 6.3

Although you need root privileges to install Calendar Server, it is possible to run the services as a non-root user.

However, if you start the services as root, each process changes the effective UID to the runtime (non-root) user and group once the tasks that need the root privileges have been executed. Doing it this way allows the use of ports below 1024. Instead, when you start services as the non-root runtime user and group, the web server port must be set to a value greater than 1024 in order for the services to start successfully.

The non-root user or group are created automatically at the time of configuration. The defaults are icsuser, and icsgroup.

1.4 Proxy Administrator Logins for Calendar Server Version 6.3

To allow administrators to administer user calendars, the following parameter in the ics.conf file is set by default as shown: service.http.allowadminproxy="yes".

If you are using Communications Express, this parameter must be set to "yes".

For more information on this parameter and on verifying that proxy logins are working, see 4.5 Configuring Logins and Authentication.

1.5 End User Administration in Calendar Server Version 6.3

End users can connect to Calendar Server from client machines using a Web graphical user interface (GUI), Sun Java System Communications Express, or through the Connector for Microsoft Outlook, which allows end users to continue using Outlook on their desktop while still taking advantage of the Calendar Server back end. 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 user LDAP entries, or resource LDAP entries, using the Delegated Administrator Utility (command-line) or Console (GUI).

For documentation on the Delegated Administrator Utility (commadmin), see Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide.

For documentation on the Delegated Administrator Console, see the Console's online help.

In addition, when necessary, you can use ldapmodify to modify LDAP entries directly. For information about ldapmodify, refer to the Sun ONE Directory Server Resource Kit 5.2 Tools Reference.

Utility programs used in pre-Java Enterprise System deployments, such as csuser, are still bundled with Calendar Server. If you are using Access Manager in your deployment, do not use these utilities for managing or creating user, domain or resource LDAP entries. There are some exceptions. Where these apply, this guide will direct you to the proper utility.

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

• 1.5.1 Choosing the Proper User Management Tool for Calendar Server Version 6.3

• 1.5.2 Creating User LDAP Entries in Calendar Server Version 6.3

• 1.5.3 Authenticating Users in Calendar Server Version 6.3

• 1.5.4 Understanding User Preferences for Calendar Server Version 6.3

• 1.5.7 Group Calendars Overview for Calendar Server Version 6.3

• 1.5.6 Autoprovisioning: Automatic Creation of Calendars in Calendar Server Version 6.3

• 1.5.8 Resources Overview for Calendar Server Version 6.3

1.5.1 Choosing the Proper User Management Tool for Calendar Server Version 6.3

Calendar users, groups, and resources can be administered using one of the following user management tools:

• Delegated Administrator Console.

  Use this GUI to provision users, groups and resources in LDAP for Calendar Server. For information on using the GUI, see the Delegated Administrator Console online help.

• Delegated Administrator Utility (commadmin).

  Use these tools to provision users, groups and resources in LDAP for Calendar Server . For detailed instructions, see the Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide.

• Calendar Server utilities.

  Use these utilities to manage calendars. In addition, use them for user, group, and resource management if your configuration meets all of the following criteria:

  • You are not using Access Manager.

  • You have an earlier version of Calendar Server or Messaging Server installed using Sun LDAP Schema version 1.

  • You plan to continue using Schema version 1.

  See also the command-line utility reference in this guide, Appendix D, Calendar Server Command-Line Utilities Reference.

Delegated Administrator does not manage calendars. To create calendars for users, groups and resources, use the Calendar Server utilities cscal and csresource, or turn on autoprovisioning. With autoprovisioning turned on, the system creates a default calendar under two circumstances: if a user logs in without a default calendar, or a user, group or resource is issued an invitation before the default calendar exists.

1.5.2 Creating User LDAP Entries in Calendar Server Version 6.3

You can create users in LDAP using the following tools:

• For Schema version 1, create both the user and the calendar at the same time using the Calendar Server csuser utility.

• For Schema version 2, use Delegated Administrator Console to create the user with the Create New User wizard. Then create the users default calendar using the Calendar Server Utility cscal. See Appendix D, Calendar Server Command-Line Utilities Reference.

• For Schema version 2, use Delegated Administrator Utility, commadmin user create. Then use the Calendar Server Utility cscal.

  For further instruction on adding users in this guide, see 14.1 Creating Calendar User LDAP Entries.

  For information on using the Delegated Administrator Utility, see Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide.

1.5.3 Authenticating Users in Calendar Server Version 6.3

Calendar Server requires a LDAP directory server such Sun Java System Directory Server to authenticate users (and to store user preferences).

1.5.4 Understanding User Preferences for Calendar Server Version 6.3

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.3 WCAP Developer’s Guide.

1.5.5 LDAP Groups Overview in Calendar Server Version 6.3

Groups are named collections of users. Each group has an LDAP entry, similar to a user or resource entry. You can use the same group entry for all services, such as calendar and messaging.

The following are a few facts about Calendar Server LDAP groups:

• Calendar Server groups can be either static or dynamic.

• Groups with calendar service can have their own default calendar.

• Calendar Server groups can consist of individuals, resources, and other groups (nested).

For more information about group calendars, see the following section: 1.5.7 Group Calendars Overview for Calendar Server Version 6.3.

1.5.6 Autoprovisioning: Automatic Creation of Calendars in Calendar Server Version 6.3

Calendar databases can be automatically populated by setting local.autoprovision="yes" in the ics.conf file. In addition, domains must be calendar enabled (have calendar service), meaning the domain LDAP entry must contain the icsCalendar object class.

There are two ways for default calendars to be created automatically:

• When a user logs in for the first time, if the user's LDAP entry is found, the system enables it for calendar services and creates a default calendar.

• When an LDAP user, group or resource is invited to an event before the default calendar has been created, the system creates a default calendar for that entity.

For example, suppose tchang exists in the directory server but is not yet enabled for calendaring (that is, does not have a default calendar). With autoprovisioning turned on, and with the domain calendar enabled:

• When tchang logs into Calendar Server for the first time, the system automatically enables tchang for calendaring and creates a default calendar with the calid tchang@hisdomain.com.

• Alternately, if someone invites tchang to an event before the default calendar has been created, the system will automatically create a default calendar for him, if user.invite.autprovision="yes" in the ics.conf file.

  For groups invited, the default group calendar is created if the following ics.conf parameter is set: groupAutoprovisioning="yes".

  For resources, likewise, the default resource calendar is created if the following ics.conf parameter is set: resource.invite.autoprovision="yes".

For more information about the configuration file parameters necessary for users, resources and groups, see 4.3 Configuring Calendar for LDAP Users, Groups and Resources.

1.5.7 Group Calendars Overview for Calendar Server Version 6.3

A group calendar can be created for any calendar-enabled LDAP group. This calendar can be scheduled much like an individual's calendar. Invitations sent to the group are scheduled to the group calendar and all individual member calendars. If a group calendar does not yet exist at the time it is invited to an event, and autoprovisioning is turned on, the system creates a calendar with a default set of properties and ACLs.

The following are some facts about group calendars:

• Group calendars do not have user interface preference like calendars for individuals because no one logs into a group calendar.

• Individuals need to subscribe to the group calendar to view it.

• The group's owner is responsible for setting the appropriate ACLs.

• Fetching free-busy information for a group calendar produces only the information for the group calendar, not the individual members' calendars.

• If a group calendar ACL does not allow invitation by an event organizer, the system returns an error. No group members are invited in this case.

• An organizer can invite a group using either its group calendar ID, or its mailing address.

For more information about Calendar Server users, see Chapter 14, Administering Users, Groups, and Resources.

1.5.8 Resources Overview for Calendar Server Version 6.3

A resource is anything that can be scheduled using a calendar, such as a conference room, or a projector. There is a separate resource LDAP entry for each such item. Create the LDAP entry and its associated calendar using the appropriate tools:

• For Schema version 2 - Use Delegated Administrator to create the resource LDAP entry, and the Calendar Server utility resource to create the calendar.

• For Schema version 1 - Use the csresource create command which creates both the resource LDAP entry and the calendar.

It is not necessary to explicitly create resource calendars. With autoprovisioning enabled, the first time a resource is invited, the system will automatically create a resource calendar for it. This is the same behavior as for users and groups.

1.6 Data Formats and Standards Overview for Calendar Server Version 6.3

This section describes the following information about Calendar Server data:

• 1.6.1 Data Format for Calendar Server Version 6.3

• 1.6.2 Import and Export of Calendar Data for Calendar Server Version 6.3

• 1.6.3 Calendar Links for Data Exchange in Calendar Server Version 6.3

• 1.6.4 Server Alarms in Calendar Server Version 6.3

• 1.6.5 Support of ITIP/IMIP Standards in Calendar Server Version 6.3

1.6.1 Data Format for Calendar Server Version 6.3

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

Calendar Server supports the following formats:

• XML (.xml) — The interface to Communications Express.

• iCalendar (.ical) — The default format.

1.6.2 Import and Export of Calendar Data for Calendar Server Version 6.3

Calendar data can be imported and exported in either iCalendar (.ical) or XML (.xml) format. Calendar Server administrators can import and export calendar data using the Calendar Server csimport and csexport utilities. End users can import and export calendar data using the Communications Express user interface.

1.6.3 Calendar Links for Data Exchange in Calendar Server Version 6.3

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

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

For information on how to link to a calendar, see 15.8 Linking to a Calendar.

1.6.4 Server Alarms in Calendar Server Version 6.3

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.

1.6.5 Support of ITIP/IMIP Standards in Calendar Server Version 6.3

Calendar Server supports the ITIP/IMIP standards (RFC 2446 and RFC 2447), including ITIP methods PUBLISH, REQUEST, REPLY, and CANCEL for events.

1.7 LDAP Data Cache Option for Calendar Server Version 6.3

The LDAP data cache option ensures that LDAP data is available immediately after it has been committed, even if the LDAP directory server is configured to include a delay in the availability of committed data.

For example, if your site has deployed a master/slave LDAP configuration where Calendar Server accesses the master LDAP directory through a slave LDAP directory server, which in turn introduces a delay in the availability of committed LDAP data, the LDAP data cache can ensure that your Calendar Server clients have accurate LDAP data.

This section covers the following topics:

• 1.7.1 Considerations for Using the LDAP Data Cache for Calendar Server Version 6.3

• 1.7.2 Master/Slave LDAP Configuration for Calendar Server Version 6.3

• 1.7.3 LDAP Data Cache for Calendar Server Version 6.3

• 1.7.4 LDAP Data Cache Limitations for Calendar Server Version 6.3

1.7.1 Considerations for Using the LDAP Data Cache for Calendar Server Version 6.3

Use these guidelines to determine if your site should configure the LDAP data cache:

• If Calendar Server at your site accesses your master (or root) LDAP directory server directly with no delays in the availability of committed LDAP data, you don't need to configure the LDAP data cache. Make sure that the local.ldap.cache.enable parameter is set to "no" (which is the default).

• If you have deployed a 1.7.2 Master/Slave LDAP Configuration for Calendar Server Version 6.3, where Calendar Server accesses the master LDAP directory through a slave LDAP directory server, there will be a delay in the availability of committed LDAP data. Configure the LDAP data cache to ensure that your end users have the most recent data.

1.7.2 Master/Slave LDAP Configuration for Calendar Server Version 6.3

A master/slave LDAP configuration includes a master (root) directory server and one or more slave (consumer or replica) directory servers. Calendar Server can access the master LDAP directory server either directly or through a slave directory server:

• If Calendar Server accesses the master LDAP directory server directly, the LDAP should be accurate, and you don't need to configure the LDAP data cache.

• If Calendar Server accesses the master LDAP directory server through a slave directory server, LDAP data changes are usually written transparently using an LDAP referral to the master directory server. The LDAP referral then replicates the data back to each slave directory server.

  In this second type of configuration, problems with inaccurate LDAP data can occur because of the delay in the availability of committed LDAP data to the slave directory servers.

  For example, Calendar Server commits an LDAP data change, but the new data is not available for a specific amount of time because of the delay in the master directory server updating each slave directory server. A subsequent Calendar Server client operation uses the old LDAP data and presents an out-of-date view.

  If the delay in updating the slave directory servers is short (only a few seconds), clients might not experience a problem. However, if the delay is longer (minutes or hours), clients will display inaccurate LDAP data for the length of the delay.

  The following table lists operations and the LDAP attributes affected by such a delay:

  Operation	LDAP Attributes
  Autoprovisioning of calendars	icsCalendar, icsSubscribed, icsCalendarOwned, icsDWPHost
  Calendar groups	icsStatus, icsCalendar
  Calendar creation	icsCalendarOwned, icsSubscribed
  Calendar subscription	icsSubscribed
  User options	icsExtendedUserPrefs, icsFirstDay, icsTimeZone, icsFreeBusy
  Calendar searches	icsCalendarOwned

1.7.3 LDAP Data Cache for Calendar Server Version 6.3

The LDAP data cache resolves the master/slave LDAP configuration problem by providing Calendar Server clients with the most recent LDAP data, even when the master directory server has not updated each slave directory server.

If the LDAP data cache is enabled, Calendar Server writes committed LDAP data to the cache database (ldapcache.db file). By default, the LDAP cache database is located in the ldap_cache database directory, but you can configure a different location if you prefer.

When a client makes a change to the LDAP data for a single user, Calendar Server writes the revised data to the LDAP cache database (as well as to the slave directory server). A subsequent client operation retrieves the LDAP data from the cache database.

This data retrieval applies to the following operations for a single user:

• User's attributes at login

• User's options (such as color scheme or time zone)

• User's calendar groups

• User's subscribed list of calendars

Thus, the LDAP data cache database provides for:

• Data consistency across processes on a single system The database is available to all Calendar Server processes on a multiprocessor system.

• Data persistence across user sessions The database is permanent and does not require refreshing.

1.7.4 LDAP Data Cache Limitations for Calendar Server Version 6.3

The LDAP data cache does not provide for:

• Reading the cache for searches where a list of entries is expected. For example, searching for attendees for a meeting. This type of search is subject to any LDAP delay. For instance, a newly created calendar will not appear in a calendar search if the LDAP search option is active and the search is performed within the delay period following the creation of a new calendar.

• Reading and writing of the cache across multiple front-end servers. Each front-end server has its own cache, which is not aware of data in other caches.

• The capability to handle a user who doesn't always log into the same server. Such a user will generate different LDAP data in the cache on each server.

1.8 Access Control for Calendar Server Version 6.3

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 the following topics:

• 1.8.1 Secure Logins for Calendar Server Version 6.3

• 1.8.2 Access Control by Users in Calendar Server Version 6.3

• 1.8.3 Access Control Lists (ACLs) in Calendar Server Version 6.3

1.8.1 Secure Logins for Calendar Server Version 6.3

When users log in to Calendar Server through Communications Express, by default the authentication process does not encrypt the login information, including user names and passwords. If you want secure logins at 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, Configuring SSL.

1.8.2 Access Control by Users in Calendar Server Version 6.3

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

• Primary calendar owners

  Primary calendar owners have full access to their own calendars. Calendar Server does not perform any access control checks for primary owners accessing their own calendars.

• Administrators and superusers

  An administrator such as calmaster, or a superuser such as root, is not subject to access control restrictions and can perform any operation on a calendar or calendar component. For more information, see 1.3 Special Accounts for Calendar Server Version 6.3.

• Other calendar owners

  Primary calendar owners can designate other owners for their calendars. The other owner can then act on behalf of the primary owner to schedule, delete, modify, accept, or decline events or todos (tasks) for a calendar.

• anonymous user

  The special calendar ID (calid) anonymous can access Calendar Server using any password, if service.http.allowanonymouslogin in the ics.conf file is set to yes (which is the default). The anonymous user is not associated with any particular domain. You can change the calid for the anonymous user by editing the calstore.anonymous.calid parameter.

  You can also view a calendar anonymously if the calendar’s permissions allow read access for everybody. For example, the following link allows users to anonymously view the calendar with the calid tchang:meetings, if the calendar’s permissions allow read access for everybody.

  http://calendar.sesta.com:8080/?calid=tchang:meetings

  An anonymous user can view, print and search for public events and tasks on the calendar but cannot perform any other operations.

  For information about viewing a resource calendar anonymously, see 15.8 Linking to a Calendar.

1.8.3 Access Control Lists (ACLs) in Calendar Server Version 6.3

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.

ACE strings are case insensitive.

The following is a list of examples:

• jsmith^c^wd^g consists of a single ACE.

• @@o^a^r^g;@@o^c^wdeic^g;@^a^sf^g consists of three ACEs.

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

• 1.8.3.1 Who Element of Ace Strings in Calendar Server Version 6.3 - The individual, user, domain, or type of user who the ACE applies to.

• 1.8.3.2 What Element of Ace Strings in Calendar Server Version 6.3 - The target being accessed, such as a calendar or a calendar component such as an event, todo (task), or calendar property.

• 1.8.3.3 How Elements of Ace Strings in Calendar Server Version 6.3 - The type of access control rights permitted, such as read, write, or delete.

• 1.8.3.4 Grant Element of Ace Strings in Calendar Server Version 6.3 - A specific access control right that is either granted or denied.

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

• jsmith is the Who element, indicating who the ACE applies to.

• c is the What element, indicating what is being accessed (only the calendar components).

• wd is the How element, indicating which access rights are to be granted or denied (write and delete).

• g is the Grant element, indicating that the specified access rights, write and delete, for the calendar components are granted to jsmith.

1.8.3.1 Who Element of Ace Strings in Calendar Server Version 6.3

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.

1.8.3.2 What Element of Ace Strings in Calendar Server Version 6.3

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

c                           

p                           

a                           

1.8.3.3 How Elements of Ace Strings in Calendar Server Version 6.3

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

1.8.3.4 Grant Element of Ace Strings in Calendar Server Version 6.3

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

1.8.3.5 Examples of ACEs for Calendar Server Version 6.3

The following examples show the use of ACEs:

• Grant the user ID jsmith read access to the entire calendar, including both components and properties:

  jsmith^a^r^g

• Grant jsmith write and delete access to components only:

  jsmith^c^wd^g

• Grant all users in the sesta.com domain privileges to schedule, availability, and read access to components only:

  @sesta.com^c^sfr^g

• Grant all owners write and delete access to components only:

  @@o^c^wd^g

• Deny jsmith all access to calendar data:

  jsmith^a^sfdwr^d

• Grant all owners read, schedule, and availability access to the entire calendar, including both components and properties:

  @@o^a^rsf^g

• Grant read access to all users:

  @^a^r^g

1.8.3.6 Placing ACE's in an ACL for Calendar Server Version 6.3

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.

1.9 Internal Subsystems for Calendar Server Version 6.3

Sun Java System Calendar Server includes the following internal subsystems:

• 1.9.1 Protocol Subsystem

• 1.9.2 Core Subsystem

• 1.9.3 Database Subsystem

The following graphic shows the logical flow through these subsystems.

Figure 1–1 Calendar Server 6.3 Internal Subsystems Logical Flow

1.9.1 Protocol Subsystem

Clients retrieve calendar data by submitting requests using the HTTP protocol layer. This is a minimal HTTP server implementation, streamlined to support calendar requests. This is done by appending Web Calendar Access Protocol (WCAP) commands to the URL.

WCAP is an open protocol that allows you to write your own interface to Calendar Server. Using WCAP commands (.wcap extension), you can perform most server commands, except for certain administrative commands. You can use WCAP commands to request output as XML or iCalendar wrapped in HTML.

For information about WCAP commands, see the Sun Java System Calendar Server 6.3 WCAP Developer’s Guide.

1.9.2 Core Subsystem

The Core subsystem includes an access control component, a WCAP command interpretation component, and data translators to format data coming from the calendar database component. The Core subsystem processes calendar requests and generates XML and iCalendar output. The Core subsystem can also handle user authentication.

1.9.3 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 super set of the iCalendar standard.

The Database subsystem returns data in a low-level format, and the Core UI generator then translates the low-level data and sends it through WCAP.

For a distributed calendar database, Calendar Server uses the Distributed Wire Protocol (DWP) to provide a networking capability. For more information, see 1.10.5 Distributed Database Service: csdwpd in Calendar Server Version 6.3.

For information about the calendar database, refer to Chapter 16, Administering Calendar Server Databases with the csdb Utility.

1.10 Services Running As Daemons in Calendar Server Version 6.3

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

• 1.10.1 Administration Service: csadmind in Calendar Server Version 6.3

• 1.10.2 HTTP Service: cshttpd in Calendar Server Version 6.3

• 1.10.3 Automatic Backup Service: csstored in Calendar Server Version 6.3

• 1.10.4 Event Notification Service (ENS): csnotifyd and enpd in Calendar Server Version 6.3

• 1.10.5 Distributed Database Service: csdwpd in Calendar Server Version 6.3

1.10.1 Administration Service: csadmind in Calendar Server Version 6.3

The csadmind service manages alarm notifications, and group scheduling requests.

1.10.2 HTTP Service: cshttpd in Calendar Server Version 6.3

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 specified in the incoming WCAP command. Data can be formatted in standard RFC 2445 iCalendar format (text/calendar) or XML format (text/xml

1.10.3 Automatic Backup Service: csstored in Calendar Server Version 6.3

When properly configured, the csstored service creates automatic backups of the calendar database. You can configure Calendar Server for automatic backups when the csconfigurator.sh configuration program runs, or you can do it at a later time, as described in this guide.

If the service is started in the disabled state, it will send a message to the administrator every 24 hours stating that automatic backups are not enabled.

For instructions on how to configure this service to perform backups, see Chapter 9, Configuring Automatic Backups (csstored).

When configured properly, the service has the following functionality:

• Upon system start up and at 24 hour (default interval) intervals thereafter, takes a snapshot of the live Calendar Server calendar database. The interval is configurable. (If the service has been stopped and restarted, it does not take another snapshot unless the configured interval has elapsed since the last snapshot.)

• Verifies the database by running csdb verify against the backup copy.

  If the verify step fails (the database is corrupted), the service notifies the administrator. The administrator can put the live database in read-only mode, allowing you to troubleshoot the problem without having to shut down the databases. While in read-only mode, no modify or delete transactions are accepted (no logging). For more information about read-only mode, see 22.5.4 Preventing Service Interruptions When Your Database is Corrupted (Read-only Mode).

  Administrator intervention is required when a corruption is sensed. A notification is sent to the administrator.

  If the verify succeeds, csstored performs the following additional tasks:

  • Creates an archival backup consisting of the database snapshot and all the transaction log files that were applied to it since the previous snapshot.

  • Creates a hot backup consisting of the database snapshot with the transaction log files applied to it.

    Should the live database become corrupted, a hot backup provides an immediate up to date backup of the database with a minimum of data loss and downtime.

    For information on how to restore an automatic backup copy, see 22.5.8 Restoring an Automatic Backup Copy.

1.10.4 Event Notification Service (ENS): csnotifyd and enpd in Calendar Server Version 6.3

The ENS service consists of these individual services:

• csnotifyd — The csnotifyd service sends notifications of events and todos (tasks). The csnotifyd service also subscribes to alarm events. When an alarm event occurs, csnotifyd sends an SMTP message reminder to each recipient.

• enpd — The enpd service acts as the broker for event alarms. The enpd service 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 the subscriber. The default subscriber for the Calendar Server system is csnotifyd.

The enpd and csnotifyd services are not required to run on the same server as the cshttpd, csdwpd, or csadmind processes.

1.10.5 Distributed Database Service: csdwpd in Calendar Server Version 6.3

Using csdwpd, you can create a distributed calendar store. That is, use csdwpd to manage calendar databases spread across multiple back-end servers within the same Calendar Server configuration.

The csdwpd service runs in the background on back-end servers 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.

1.11 Public APIs for Calendar Server Version 6.3

Calendar Server includes the following APIs:

• 1.11.1 Web Calendar Access Protocol (WCAP) in Calendar Server Version 6.3

• 1.11.2 Event Notification Service (ENS) API for Calendar Server Version 6.3

1.11.1 Web Calendar Access Protocol (WCAP) in Calendar Server Version 6.3

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:

• Standard RFC 2445 iCalendar format (text/calendar)

• XML format (text/xml)

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

• To override the access control of WCAP commands

  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":

  service.admin.calmaster.overrides.accesscontrol="yes"

• To retrieve and modify user preferences for any user

  The administrator can use get_userprefs.wcap and set_userprefs.wcap to retrieve and modify any user’s preferences. For an administrator to have this privilege, the following parameter in the ics.conf file must be set to "yes":

  service.admin.calmaster.wcap.allowmodifyuserprefs="yes"

For more information, see the Sun Java System Calendar Server 6.3 WCAP Developer’s Guide.

1.11.2 Event Notification Service (ENS) API for Calendar Server Version 6.3

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

For information about the ENS API, see the Sun Java Communications Suite 5 Event Notification Service Guide.

The Calendar Server software also contains support for Java Message Queue for notification, but csnotifyd does not subscribe to it. Thus, it is not part of the default alarms and notification system. For more information, refer to the Sun Java System Java Message Queue documentation.