Complete Contents |
Chapter 1 Installation and Deployment
Chapter 2 Configuring Calendar Server
Chapter 3 Admininistering Calendar Server
Chapter 4 Monitoring the Calendar Server
Appendix A Commnand Line Utilities
Appendix B Monitoring Tools
Appendix C Time Zones
Appendix D Calendar Server LDAP Schema
|Installation Process Overview|
iPlanet Calendar Server 2.1 uses an installation program that provides a consistent installation interface and procedure across all supported platforms. In addition, Calendar Server provides tools for uninstalling the server, stopping and starting various server processes, and enabling users to access data hosted on the server. Instructions for using these tools are provided in the relevant sections of this document.
For the most up to date installation instructions, refer to the online version listed at:
Installing Calendar Server involves the following steps:
Before You Begin the Installation
Before you begin installing iPlanet Calendar Server 2.1, you should verify that the systems on which you plan to install the software meet the minimum product requirements. In addition, you should understand what the various Calendar Server components are. It is also a good idea to plan how you want to configure the software components before you begin the installation process. System Requirements
Before you install the Calendar Server, you must make sure you have met the minimum hardware and operating system requirements. Hardware Requirements
The basic minimum hardware requirements for a Calendar Server installation are as follows:
Calendar Server 2.1 supports the following operating systems at the appropriate version and patch levels:
It is recommended that you install Calendar Server logged in as root (Unix) or administrator (Windows NT). Superuser privileges (root or administrator) are required for Calendar Server 2.1 installations if you plan to use the default port numbers (which are less than 1024). Installation Packages
The product contains the following separate software components:
Provides a powerful and flexible cross-platform solution to the Calendar Server hosting needs of service providers of all sizes. Using an open, Internet-standard approach to calendar hosting, it offers rapid processing of calendar scheduling data scalable to many thousands of simultaneous users.
A high performance interface to enhancing and modifying the feature-set of the Calendar Server. This API lets you create very fast runtime shared objects which outperform both system executable programs and scripts in any language in terms of speed, memory footprint, and load time. CSAPI is a shared-object runtime interface to Calendar Server functions that supports the use of plugin CSAPI modules to manipulate server data when the server receives requests and sends responses. This package also includes Web Calendar Access Protocol (WCAP), a high level command-based protocol that clients use to communicate with iPlanet Calendar Server through CSAPI.
The Calendar Server 2.1 installation program lets you install the product in the following ways:
The accounts, groups, and administrators referred to in this guide are grouped into the following categories:
The accounts described in this section are those used with Netscape Directory Server. For more information, refer to the Netscape Directory Server documentation.
This is the username and associated password that can make configuration changes to the Calendar Server. This user has administration privileges over the Calendar Server, but not over the Directory Server itself. The default is calmaster.
Also known as "Unrestricted User". If you use LDAP (the default mechanism) for user authentication, this is the username and associated password that can make changes to the Directory Server schema. This user has overall administrator privileges on the Directory Server and all servers that make use of the Directory Server, such as the Administration Server and Calendar Server, and has full administration access to all entries in the Directory Server. You enter the Directory Administrator's distinguished name (DN) when you create a Directory Server instance. The default and recommended DN is:
On Windows NT, you can run Calendar Server logged in as any valid user. Usually, however, you will want to run the server under the system account (logged in as administrator) to ensure that you have all account privileges required to manage the server. If you log in as a user other than administrator, you may not have the privileges you need to fully manage the server. Unix System Accounts
The accounts described in this section apply only to Calendar Server installations on Unix platforms.
(Unix only) These accounts are the user and group the make up the identity that the Calendar Server runs as. The calendar data files, such as the calendar data store, are owned by this user and group. This user and group should be highly secure and should be members of the Netscape group. For security reasons, these accounts should have no special privileges on the system. In the course of operation, servers will assign some directory permissions to this user and the Netscape group for certain server-specific operations. The Calendar Server installation program suggests the default user icsuser and the default group icsgroup and will create these accounts automatically if they do not exist.
This section contains information you need and suggested guidelines you should follow as you prepare for your Calendar Server 2.1 installation:
To transfer and extract the product archive files which contain the installation program files in compressed format:
After you have extracted the installation files on the machine where you plan to install Calendar Server, you can run the installation program:
The following sections describe some of the issues you should consider before you install and deploy Calendar Server at your site.
By default, Calendar Server supports users that are defined and maintained in an LDAP directory, such as Netscape Directory Server. Calendar Server also supports the use of plug-ins that you create to enable access to users defined in non-LDAP directories such as those stored in a standard Unix Authentication format or in a Windows NT User Manager database.