Sun Java System Calendar Server 6.3 Administration Guide

Part III Customizing Your Calendar Server Configuration

This part contains chapters on various features that can be configured by editing the configuration file, ics.conf.

This part contains the following chapters:

Chapter 4 Customizing Calendar Server

After installation and post installation configuration, Calendar Server can be run as is. However, you can customize features in your system (reconfigure your system) by editing the ics.conf file.


Note –

Duplicate parameters are allowed in the ics.conf file. The system takes the value of the last instance of the parameter in the file.

Best Practices: To avoid confusion, add your customizations to the end of the file in a section you create for that purpose. For example, you can create a comment line with the following text: ! My ics.conf Changes. Then add any new parameters or any parameters that you are modifying, and their values. Add comments to each parameter describing why the change was made and add the current date. This will give you a history of the changes made to the system for later reference.

If you make extensive customizations, to improve processing efficiency, you might consider commenting out the original parameter that you are replacing. Also, periodically review the file, commenting out obsolete duplicate parameters.


This chapter, and the chapters that follow in Part III, Customizing Your Calendar Server Configuration, contain instructions and information you can use to reconfigure Calendar Server.

You can find the ics.conf file in the following directory:

For Solaris: /etc/opt/SUNWics5/cal/config

For Linux: /etc/opt/sun/calendar/config


Note –

Do not attempt to edit the configuration file until you have completed the following tasks:


This chapter covers the following configuration topics:

4.1 Configuring for Communications Express

This section covers the two configuration file parameters to configure for Communications Express.

Communications Express requires the following:

ProcedureTo Configure Proxy Authentication

  1. Log in as an administrator with permission to change the configuration.

  2. Stop Calendar Server services by issuing the stop-cal.

  3. Change to the /etc/opt/SUNWics5/cal/config directory.

  4. Save your old ics.conf file by copying and renaming it.

  5. Edit the ics.conf parameters as shown in the following table:

    service.http.allowadminproxy

    Enables administrator proxy authentication when set to "yes". The default is "yes".

    service.http.admins

    Lists the user ID's with administration rights to Calendar Server. The default is “calmaster”. This can be a space-separated list with multiple values. One of the values must be the value as specified in the uwconfig.properties file for calendar.wcap.adminid.

    service.siteadmin.userid

    User ID of the calmaster. This should be the same as the user ID found in the calendar.wcap.adminid parameter of the uwcconfig.properties file.

    service.siteadmin.cred

    Password for the calmaster. This should be the same as the user ID found in the calendar.wcap.passwd parameter of the uwcconfig.properties file.


    Note –

    The uwcconfig.properties file is located in the comms-express-svr-base/WEB-INF/config directory, where comm-express-svr-base is the directory where Communications Express was installed.


  6. Save the file as ics.conf.

  7. Restart Calendar Server.

    cal-svr-base/SUNWics5/cal/sbin/start-cal

See Also

For instructions on configuring Communications Express, see theSun Java System Communications Express 6.3 Customization Guide .

ProcedureTo Enable Anonymous Access

  1. Log in as an administrator with permission to change the configuration.

  2. Stop Calendar Server services by issuing the stop-cal.

  3. Change to the /etc/opt/SUNWics5/cal/config directory.

  4. Save your old ics.conf file by copying and renaming it.

  5. Edit the following parameters in the ics.conf to enable anonymous access:

    service.wcap.anonymous.allowpubliccalendarwrite

    Enables or disables allowing anonymous access users to write to public calendars. Enable access by setting the value to "yes", which is the default.

    service.wcap.allowpublicwritablecalendars

    Enables users to have publicly writable calendars. This is enabled by default (set to "yes").

    service.http.allowanonymouslogin

    Enable anonymous access (login) by setting this parameter to "yes", if necessary. The default value is "yes".

    service.calendarsearch.ldap

    For security purposes with anonymous logins enabled, you might want to disable searching through the LDAP first when doing calendar searches, by setting this parameter to "no", which is the default.


    Note –

    Communications Express expects the value of the service.calendarsearch.ldap parameter to be "no". This conflicts with instructions given for tuning your system for best performance in a DWP environment, (in which your database is distributed across multiple back-ends.) See 21.2 Improving Calendar Search Performance in a DWP Environment.


  6. Save the file as ics.conf.

  7. Restart Calendar Server.

    cal-svr-base/SUNWics5/cal/sbin/start-cal

    For instructions on configuring Communications Express, see theSun Java System Communications Express 6.3 Administration Guide.

4.2 Configuring Calendars

This section contains the following topics:

ProcedureTo Configure User Calendars

  1. Log in as an administrator with permission to change the configuration.

  2. Stop Calendar Server services by issuing the stop-cal.

  3. Change to the /etc/opt/SUNWics5/cal/config directory.

  4. Save your old ics.conf file by copying and renaming it.

  5. Edit one or more of the parameters as shown in the following table:

    calstore.calendar.default.acl

    Specifies the default access control permissions used when a user creates a calendar. The format is specified by a semicolon-separated list of access control entry (ACE) argument strings. The default is:

    "@@o^a^r^g;@@o^c^wdeic^g;
    @^a^fs^g;@^c^^g;@^p^r^g"

    For more information on the ACE format, see 15.4 Calendar Access Control Calendar Server utilities, see D.5 cscal.

    calstore.calendar.owner.acl

    Specifies the default access control settings for owners of a calendar. The default is: "@@o^a^rsf^g;@@o^c^wdeic^g"

    calstore.freebusy.include.defaultcalendar

    Specifies whether a user's default calendar is included in user's free/busy calendar list. The default is “yes”.

    calstore.freebusy.remove.defaultcalendar

    Specifies whether a user's default calendar can be removed from user's free/busy calendar list. The default is “no”.

    service.wcap.freebusy.redirecturl

    Specifies a URL to use to search for a calendar in a different database. This is only used while migrating calendar databases. During the time that calendars are split between two different databases, you can specify a URL other than the current Calendar Server database. The system searches the Calendar Server calendar database first and if it can’t find the user, checks to see if the redirect URL is available. This feature can be turned off by passing in the noredirect parameter set to 1 with the get_freebusy command.

    calstore.subscribed.include.defaultcalendar

    Specifies whether a user's default calendar is included in the user's subscribed calendar list. The default is “yes”.

    service.wcap.login.calendar.publicread

    If "yes", default user calendars are initially set to public read/private write. If no, default user calendars are initially set to private read/private write. The default is “no”.

    user.allow.doublebook

    Determines if a user calendar can have more than one event scheduled for the same time period:

    • "no" prevents double booking.

    • "yes" allows double booking, and is the default.

      This parameter is used only when a user calendar is created. Thereafter, Calendar Server checks the calendar properties file (ics50calprops.db) to determine if double booking is allowed.

      To change the value of the double booking calendar property, use cscal with the -k option.

    user.invite.autoprovision

    Determines if user calendar should be auto-created if the user receives an invitation but has no default calendar. The default is the enable this option ("yes").

  6. Save the file as ics.conf.

  7. Restart Calendar Server.

    cal-svr-base/SUNWics5/cal/sbin/start-cal

ProcedureTo Configure Resource Calendars

  1. Log in as an administrator with permission to change the configuration.

  2. Stop Calendar Server services by issuing the stop-cal.

  3. Change to the /etc/opt/SUNWics5/cal/config directory.

  4. Save your old ics.conf file by copying and renaming it.

  5. Edit one or more of the parameters as shown in the following table:

    resource.allow.doublebook

    Determines if a calendar that belongs to a resource (such as a conference room or audio visual equipment) can have more than one event scheduled for the same time slot when the calendar is created:

    • "no" prevents double booking, and is the default.

    • "yes" allows double booking.

    • This parameter is used only when a resource calendar is created.

      After a resource calendar is created, Calendar Server checks the calendar properties (ics50calprops.db) to determine if double booking is allowed.

      If you need to change the calendar properties for a resource calendar to allow or disallow double booking, use csresource with the -k option.

    resource.default.acl

    Specifies the default access control permissions used when a resource calendar is created. The default is:

    "@@o^a^r^g;@@o^c^wdeic^g;
    @^a^rsf^g"
    resource.invite.autoaccept

    When invitations are sent to resources should they be automatically marked as accepted? The default is "yes".

    resource.invite.autoprovision

    When a resource is invited to an event, if it has no existing calendar, should it be autoprovisioned?

    The default is "yes".

  6. Save the file as ics.conf.

  7. Restart Calendar Server.

    cal-svr-base/SUNWics5/cal/sbin/start-cal

ProcedureTo Configure Group Calendars

A group calendar can be scheduled with events similar to a user calendar. However, a user should not log into a group calendar. To view a group calendar, the user should subscribe to it. To configure a group calendar, edit the ics.conf file as shown in the steps that follow.

  1. Log in as an administrator with permission to change the configuration.

  2. Stop Calendar Server services by issuing the stop-cal.

  3. Change to the /etc/opt/SUNWics5/cal/config directory.

  4. Save your old ics.conf file by copying and renaming it.

  5. Edit one or more of the parameters as shown in the following table:

    group.allow.doublebook

    Specifies whether the group calendar can be double booked. The default is yes.

    group.default.acl

    Specifies the default ACL for group calendars:

    "@@o^a^r^g;@@o^c^wdeic^g;@^a^rsf^g"

    group.invite.autoprovision

    Specifies whether autoprovisioning is enabled or disabled. The default is "yes" (enabled).

    group.invite.autoaccept

    Specifies whether a group invitation will automatically have PARTSTAT=ACCEPTED.

    group.invite.expand

    Determines if a group should be expanded for invitations.

    If “yes”, the list will be expanded if it meets the constraints of the calstore.group.attendee.maxsize parameter. If the expansion fails, or this parameter is set to "no", only the group name shows up on the attendee list and no RSVP is required.

    calstore.group.attendee.maxsize

    Specifies whether groups can be expanded. A value of "0" means no expansion limits. A group of any size can be expanded.

    If expansion is allowed, but not unlimited. The value of the parameter indicates the maximum number of attendees allowed in an expanded group. If the number in the group exceeds the maximum size, then the group is not expanded.

    A value of "-1" means no expansion allowed.

    If expansion is not allowed because it exceeds the maximum size, only the group name appears in the attendee list and an error is returned to the organizer.

  6. Save the file as ics.conf.

  7. Restart Calendar Server.

    cal-svr-base/SUNWics5/cal/sbin/start-cal
See Also

For instructions on configuring groups, see To Configure Calendar Server for Groups.

ProcedureTo Disable Autoprovisioning of Calendars

Autoprovisioning of user , resource and group calendars is enabled by default. That is, if a user attempting to log in does not yet have a default calendar, the system creates a user calendar with default settings.

If a user, resource or a group is invited to an event, but it does not yet have a default calendar, the system creates a resource or group calendar with default settings.

If you want to disable any of these calendars from being autoprovisioned, change the appropriate parameter in the ics.conf file as shown in the steps that follow.

  1. Log in as an administrator with permission to change the configuration.

  2. Stop Calendar Server services by issuing the stop-cal.

  3. Change to the /etc/opt/SUNWics5/cal/config directory.

  4. Save your old ics.conf file by copying and renaming it.

  5. Disable autoprovisioning of user, resource and group calendars by editing the following parameters:

    local.autoprovision

    Specifies whether autoprovisioning of user calendars is enabled (“yes”), or disabled (“no”). The default is “yes”.

    resource.invite.autoprovision

    Specifies whether autoprovisioning of resource calendars is enabled (“yes”), or disabled (“no”). The default is “yes”.

    group.invite.autoprovision

    Specifies whether autoprovisioning of group calendars is enabled (“yes”), or disabled (“no”). The default is “yes”.

    autoprovisioning

    Specifies whether auto-inviting of user calendars is enabled (“yes”), or disabled (“no”). The default is “yes”.

  6. Save the file as ics.conf.

  7. Restart Calendar Server.

    cal-svr-base/SUNWics5/cal/sbin/start-cal

ProcedureTo Configure Free-Busy Lookup

The free-busy view is used for several purposes. There are a number of ics.conf parameters that can be set to customize how the free-busy view is generated.

  1. Log in as an administrator with permission to change the configuration.

  2. Stop Calendar Server services by issuing the stop-cal.

  3. Change to the /etc/opt/SUNWics5/cal/config directory.

  4. Save your old ics.conf file by copying and renaming it.

  5. Edit one or more of the following ics.conf parameters shown in the following table:

    service.wcap.freebusybegin

    Specifies the offset from the current time in days for get_freebusy for beginning of the range. The default is "30".

    service.wcap.freebusyend

    Specifies the offset from the current time in days for get_freebusy for end of the range. The default is "30".

    calstore.freebusy.include.defaultcalendar

    Specifies whether a user's default calendar is included in user's free/busy calendar list. The default is "yes".

    calstore.freebusy.remove.defaultcalendar

    Specifies whether a user's default calendar can be removed from user's free/busy calendar list. The default is "no".

  6. Save the file as ics.conf.

  7. Restart Calendar Server.

    cal-svr-base/SUNWics5/cal/sbin/start-cal

4.3 Configuring Calendar for LDAP Users, Groups and Resources

This section contains instructions on configuring LDAP users, groups and resources.

This section includes the following topics:

ProcedureTo Configure Calendar Users

  1. Log in as an administrator with permission to change the configuration.

  2. Change to the /etc/opt/SUNWics5/cal/config directory.

  3. Save your old ics.conf file by copying and renaming it.

  4. Edit one or more of the following ics.conf parameters shown in the following table:

    local.lookupldapsearchattr.aclgroup

    The attribute used to specify which groups a user, group, or resource is a member of, for ACL evaluation. The default is "aclgroupaddr". (This is used to calculate dynamic groups.)

    service.wcap.allowchangepassword

    If "yes", allow users to change their passwords. The default is "no".

    service.wcap.allowpublicwritablecalendars

    If "yes", allow users to have publicly writable calendars. The default is "yes".

    calstore.subscribed.remove.defaultcalendar

    Specifies whether a user's default calendar can be removed from the user's subscribed calendar list. The default is "no".

    service.wcap.allowcreatecalendars

    If "yes", allow calendars to be created by users who do not have administrative privileges. The default is "yes".

    service.wcap.allowdeletecalendars

    If "yes", allow calendars to be deleted by users who do not have administrative privileges, but do have delete permission for that calendar. The default is "yes".

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal-svr-base/SUNWics5/cal/sbin/start-cal

ProcedureTo Set Calendar User Preferences

  1. Log in as an administrator with permission to change the configuration.

  2. Change to the /etc/opt/SUNWics5/cal/config directory.

  3. Save your old ics.conf file by copying and renaming it.

  4. Edit one or more of the following ics.conf parameters shown in the following table:

    service.wcap.allowsetprefs.cn

    If "yes", allow set_userprefs to modify the user preference "cn" (LDAP user's common name). The default is “no”.

    service.wcap.allowsetprefs.givenname

    If "yes", allow set_userprefs to modify the user preference "givenname" (LDAP user's given name). The default is “no”.

    service.wcap.allowsetprefs.icsCalendar

    If "yes", allow set_userprefs to modify the user preference “icsCalendar" (a user's default calendar identifier). The default is “no”.

    service.wcap.allowsetprefs.mail

    If "yes", allow set_userprefs to modify the user preference "mail" (user's email address). The default is “no”.

    service.wcap.allowsetprefs.preferredlanguage

    If "yes", allow set_userprefs to modify the user preference "preferredlanguage" (LDAP user's preferred language). The default is “no”.

    service.wcap.allowsetprefs.sn

    If "yes", allow set_userprefs to modify the user preference "sn" (LDAP user's surname). The default is “no”.

    service.wcap.userprefs.ldapproxyauth

    If "yes", enables LDAP proxy authorization for get_userprefs. If "no", anonymous LDAP search is performed. The default is “no”.

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal-svr-base/SUNWics5/cal/sbin/start-cal

ProcedureTo Configure Calendar Server for Groups

Calendar Server supports LDAP groups, which are a named collection of users. The group membership can be static, or dynamically created. Groups can be nested. Groups have a groupid that is analogous to a uid for a user. Groups also have a mail address.

In addition, groups can have a default calendar with a group calid that should correspond to the groupid, with the addition of the domain, for instance groupid@sesta.com. Group calendars do not have user interface preferences stored in the preferences database. Instead, the LDAP entry contains an icsDefaultacl attribute that is used in group creation.

A group is defined in the LDAP entry as an instance of icsCalendarGroup. For information on the other attributes available for group calendars, see the Sun Java System Communications Services 6 2005Q4 Schema Reference.

  1. Log in as an administrator with permission to change the configuration.

  2. Change to the /etc/opt/SUNWics5/cal/config directory.

  3. Save your old ics.conf file by copying and renaming it.

  4. Edit one or more of the following ics.conf parameters shown in the following table:

    local.lookupldapsearchattr.owner

    Owner attribute to use for groups and resources. The default is "owner".

    local.lookupldapsearchattr.coowner

    Secondary owners attribute for groups and resources. The default is "icsSecondaryowners".

    local.lookupldapsearchattr.groupid

    The attribute used to store the unique group identifier. The default is "groupid".

    local.lookupldapsearchattr.defaultacl

    The attribute used to store the default ACL given to each group calendar at autoprovisioning. The default is "icsDefaultacl".

    local.lookupldapsearchattr.doublebook

    The attribute used to specify whether doublebooking of group calendars is permitted. This is the attribute used when a default group calendar is auto-created. The default is "icsDoublebooking".

    local.lookupldapsearchattr.autoaccept

    The attribute used to specify whether invitations to group calendars are automatically accepted. This is the attribute used when a default group calendar is auto-created. The default is "icsAutoaccept".

    local.lookupldapsearchattr.timezone

    The attribute used to specify the time zone for an auto-created group calendar. The default is "icsTimezone".

    local.lookupldapsearchattr.aclgroup

    The attribute used to specify which groups a user, group, or resource is a member of, for ACL evaluation. The default is "aclgroupaddr". (For groups, this would be for nested groups.)

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal-svr-base/SUNWics5/cal/sbin/start-cal

See Also

If you plan to have calendars for groups, you need to configure group calendars. See To Configure Group Calendars.

If you are using groups, you should set the following domain level preferences in the group LDAP entry:

For information on how to configure Calendar Server domains for groups, see 11.1 Configuring Domain Preferences for Groups in Calendar Server Version 6.3.

4.4 Configuring Calendar Server

This section contains procedures for customizing server-side configuration by editing the ics.conf file.

This section contains the following topics:

ProcedureTo Configure Server Behavior

The calendar store is configured by default as shown in The following table. If you wish to reconfigure the store, perform the following steps:

  1. Log in as an administrator with permission to change the configuration.

  2. Stop Calendar Server services using stop-cal.

  3. Change to the /etc/opt/SUNWics5/cal/config directory.

  4. Save your old ics.conf file by copying and renaming it.

  5. Edit one or more of the parameters in the following table:

    Parameter  

    Description and Default Value 

    calstore.calendar.create.lowercase

    Specifies whether Calendar Server should convert a calendar ID (calid) to lowercase when creating a new calendar or when looking up a calendar using the LDAP CLD plug-in. The default is "no".

    calstore.default.timezoneID

    Time zone ID to be used when importing files, and no other time zone ID's can be found for any of the following: an event, a calendar, a user. 

    The default is "America/New_York"

    An invalid value causes the server to use the GMT (Greenwich Mean Time) time zone. 

    calstore.filterprivateevents

    Specifies whether Calendar Server filters (recognizes) Private and Confidential (Time-and-Date-Only) events and tasks.If "no", Calendar Server treats them the same as Public events and tasks. The default is "yes".

    calstore.group.attendee.maxsize

    Maximum number of members allowed when expanding a group. The default value, "0" means to expand the group without regard to size.

    A value of -1 means no expansion of groups.

    calstore.recurrence.bound

    Maximum number of events that can be created by a recurrence expansion. The default is "60".

    calstore.userlookup.maxsize

    Maximum number of results returned from LDAP lookup from user search. Value of "0" means no limit. The default is "200".

    calstore.unqualifiedattendee.fmt1.type

    Specifies how Calendar Server treats strings, such as jdoe or jdoe:tv, when performing a directory lookup for attendees of an event. Allowable values are: uid, cn, gid, res, mailto, cap. The default is "uid".

    calstore.unqualifiedattendee.fmt2.type

    Specifies how Calendar Server treats strings with an at sign (@), such as jdoe@sesta.com, when performing a directory lookup for attendees of an event. Allowable values are: uid, cn, gid, res, mailto, cap. The default is "mailto".

    calstore.unqualifiedattendee.fmt3.type

    Specifies how Calendar Server treats strings with a space, such as john doe, when performing a directory lookup for attendees of an event. Allowable values are: uid, cn, gid, res, cap. The default is "cn".

    service.wcap.validateowners

    If "yes", the server must validate that each owner of a calendar exists in the LDAP directory. The default is "no".

    service.wcap.freebusy.redirecturl

    If the requested calendar can’t be found in the local calendar database, alternately, a URL found in this parameter can be used to redirect the search to another database. This is specifically used for scripts created when migrating between two databases and both are still being used. Then the get_freebusy.wcap command can be used to specify whether to look in the other database. See the get_freebusy command description in the Sun Java System Calendar Server 6.3 WCAP Developer’s Guide.

    store.partition.primary.path

    Location of primary disk partition where calendar information is stored. The default is "/var/opt/SUNWics5/csdb".

  6. Save the file as ics.conf.

  7. Restart Calendar Server.

    cal-svr-base/SUNWics5/cal/sbin/start-cal

ProcedureTo Configure Calendar Logging

  1. Log in as an administrator with permission to change the configuration.

  2. Change to the /etc/opt/SUNWics5/cal/config directory.

  3. Save your old ics.conf file by copying and renaming it.

  4. Edit one or more of the parameters shown in the following table:

    Parameter 

    Description and Default Value  

    logfile.admin.logname

    This log file contains history of the administrative tool commands issued. The default is "admin.log".

    logfile.buffersize

    Size in bytes for log buffers. The default is "0". Specify the size of each entry in the log files. If your buffers fill up too fast, consider making them larger.

    logfile.dwp.logname

    Name of the log file for logging Database Wire Protocol related administrative tools. The default is "dwp.log". Specify one per front-end server.

    logfile.expirytime

    Number of seconds before the log files expire. The default is "604800". After this time, a cleanup routine will purge the log. If you want to archive the log, you must write your own routine.

    logfile.flushinterval

    Number of seconds between the flushing of buffers to log files. the default is "60".

    If your system experiences a high volume of log information and your buffers fill up before 60 seconds, you will lose information. In that case consider decreasing this time interval. Note that decreasing the time interval increases system overhead. 

    logfile.http.logname

    Name of the current log file for the cshttpd service. The default is "http.log".

    logfile.http.access.logname

    Name of the current HTTP access log file. 

    logfile.logdir

    Directory location of the log files. The default is "/var/opt/SUNWics5/logs".

    logfile.loglevel

    Determines the level of detail the server will log. Each log entry is assigned one of these levels (starting with the most severe): CRITICAL, ALERT, ERROR, WARNING, NOTICE, INFORMATION, and DEBUG. The default is “NOTICE”.

    If you set to CRITICAL, Calendar Server logs the least amount of detail. If you want the server to log the most amount of detail, specify DEBUG.

    Each succeeding log level also gives you all the more severe log levels before it. For example, if set to WARNING, only CRITICAL, ERROR, and WARNING level log entries are logged. If set to DEBUG, all levels are logged.

    logfile.maxlogfiles

    Maximum number of log files in the log directory. The default is "10". Before the system tries to create the 11th log, it runs the clean up routine to purge old log files.

    logfile.maxlogfilesize

    Maximum disk space in bytes for all log files. The default is "2097152". When creating the next log file will violate this limit, the system tries to free disk space by deleting the oldest logs.

    logfile.minfreediskspace

    Minimum free disk space (in bytes) that must be available for logging. When this value is reached, Calendar Server attempts to free disk space by expiring old log files. Logging is paused if space cannot be freed up. The default is "5242880".

    logfile.notify.logname

    Name of the log file for the csnotifyd service. The default is "notify.log".

    logfile.rollovertime

    Number of seconds before the log files are rotated. That is, the time interval between creation opening of new log files. The default is "86400".

    logfile.store.logname

    Name of the log file for the calendar store. The default is "store.log".

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal-svr-base/SUNWics5/cal/sbin/start-cal

See Also

To configure transaction logging for the calendar database, see Chapter 9, Configuring Automatic Backups (csstored).

You do not have to configure the delete log (for deleted events and tasks). See Chapter 18, Administering the Delete Log Database.

ProcedureTo Configure WCAP Commands

  1. Log in as an administrator with permission to change the configuration.

  2. Change to the /etc/opt/SUNWics5/cal/config directory.

  3. Save your old ics.conf file by copying and renaming it.

  4. Edit one or more of the following ics.conf parameters as shown in following table:

    Parameter 

    Description and Default Value 

    service.wcap.format

    Specifies the default output format for commands. Two formats are supported: 

    • "text/calendar" (default)

    • "text/xml"

    If you are using the Connector for Microsoft Outlook, you must use text/calendar.

    service.wcap.version

    WCAP version. 

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal-svr-base/SUNWics5/cal/sbin/start-cal

ProcedureTo Enable Email Notifications

Three types of email notifications can be enabled:

  1. Log in as an administrator with permission to change the configuration.

  2. Change to the /etc/opt/SUNWics5/cal/config directory.

  3. Save your old ics.conf file by copying and renaming it.

  4. Edit one or more of the following ics.conf parameters as shown in following table:

    Parameter 

    Description and Default Value 

    ine.invitation.enable

    "yes"- (Default) To send notifications of invitations to attendees.

    "no"- Do not send email notifications of invitations to attendees.

    ine.cancellation.enable

    "yes"- (Default) To send notifications of event cancellations to attendees.

    "no"- Do not send notifications of cancellation to attendees.

    ine.reply.enable

    "yes"- (Default) To send organizers notifications of attendees' replies to invitations.

    "no"- Do not send organizers notifications of replies.

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal-svr-base/SUNWics5/cal/sbin/start-cal

See Also

For more information about configuring notifications, see E.4.1 Calendar Server Email Notifications Configuration Parameters and Format Files.

4.5 Configuring Logins and Authentication

This section contains instructions for configuring logins and authentication.

This section contains the following topics:

ProcedureTo Configure Proxy Administrator Logins

Proxy logins must be configured for Communications Express. For instructions on how to configure proxy logins for Communications Express, see4.1 Configuring for Communications Express.

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

  1. Log in as an administrator with permission to change the configuration.

  2. Change to the /etc/opt/SUNWics5/cal/config directory.

  3. Save your old ics.conf file by copying and renaming it.

  4. Edit the parameter that follows:

    service.http.allowadminproxy

    Specifies whether administrators are allowed to perform proxy logins to administer user calendars. If "yes", proxy logins are allowed. If "no" proxy logins are not allowed. The default value is "yes".

  5. Restart Calendar Server for the new value to take effect.

  6. Verify that administrator proxy logins are working by using the following WCAP command:


    http://server[:port]/login.wcap?
       user=admin-user&password=admin-password
       &proxyauth=calendar-user&fmt-out=text/html

    The following list contains an explanation of each variable in the previous example:

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

    • fmt-out is the specification for output format of the content. For example, text or HTML.

    If the command is successful, Calendar Server displays the calendar for calendar-user. If problems occur, Calendar Server displays “Unauthorized”.

    Causes for error 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.

ProcedureTo Configure Authentication

  1. Log in as an administrator with permission to change the configuration.

  2. Change to the /etc/opt/SUNWics5/cal/config directory.

  3. Save your old ics.conf file by copying and renaming it.

  4. Edit one or more of the parameters shown in the following table:

    Parameter  

    Description/Default 

    local.authldapbasedn

    Base DN for LDAP authentication. If not specified, local.ugldapbasedn is used.

    local.authldaphost

    Host for LDAP authentication. If not specified, uses the value of local.ugldaphost. The default is "localhost".

    local.authldapbindcred

    Bind credentials (password) for user specified in local.authldapbinddn.

    local.authldapbinddn

    DN used to bind to LDAP authentication host to search for user's dn. If not specified or blank (" "), its assumed to be an anonymous bind.

    local.authldapport

    Port for LDAP authentication. If not specified, uses the value of local.ugldapport. The default is "389".

    local.authldappoolsize

    Minimum number of LDAP client connections that are maintained for LDAP authentication. If not specified, uses the value of local.ugldappoolsize. The default is "1".

    local.authldapmaxpool

    Maximum number of LDAP client connections that are maintained for LDAP authentication. If not specified, uses the value of local.ugldapmaxpool. The default is "1024".

    local.user.authfilter

    Specifies the authentication filter used for user lookup. The default is "(uid=%U)"

    This value is stored in the inetDomainSearchFilter attribute in the domain entry.

    It is possible to filter on a different attribute. For example, you could set this parameter to "(mail=%U)"

    The uid of the authenticated user is passed on to all other functions as the identity for that user, regardless of the attribute used for authentication.

    service.plaintextloginpause

    Number of seconds to delay after successfully authenticating a user with plain text passwords. The default is "0".

ProcedureTo Configure the Authentication Cache

  1. Log in as an administrator with permission to change the configuration.

  2. Change to the /etc/opt/SUNWics5/cal/config directory.

  3. Save your old ics.conf file by copying and renaming it.

  4. Edit one or more of the parameters as shown in The following table:

    service.authcachesize

    Maximum number of authenticated user ID's (uids) and passwords that Calendar Server will maintain in the cache. The default is “10000”.

    service.authcachettl

    Number of seconds since the last access before a uid and password are removed from the cache. The default is “900”.

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal-svr-base/SUNWics5/cal/sbin/start-cal

ProcedureTo Enable Checking the Client IP Address at Login

  1. Log in as an administrator with permission to change the configuration.

  2. Change to the /etc/opt/SUNWics5/cal/config directory.

  3. Save your old ics.conf file by copying and renaming it.

  4. Edit the following parameter as shown in the following table:

    service.dnsresolveclient

    If "yes", when HTTP access is allowed, checks the client IP address against DNS. The default is “no”.

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal-svr-base/SUNWics5/cal/sbin/start-cal

4.6 Configuring Calendar Services (Daemons)

This section contains instructions on how to configure calendar services (daemons).

This section contains the following topics:


Tip –

See also, Chapter 9, Configuring Automatic Backups (csstored).


ProcedureTo Configure Start and Stop Services

The start-cal and stop-cal commands are wrapper scripts that allow ease of starting and stopping Calendar Server. The utility is defined in Appendix D, Calendar Server Command-Line Utilities Reference.

  1. Log in as an administrator with permission to change the configuration.

  2. Stop Calendar Server services by issuing the stop-cal command.

  3. Change to the /etc/opt/SUNWics5/cal/config directory.

  4. Save your old ics.conf file by copying and renaming it.

  5. Edit one or more of the parameters as shown in the following table:

    Parameter  

    Description and Default Value  

    local.serveruid

    Runtime user identifier (uid). The default is "icsuser". This is the user identifier to use when super-user privileges are not needed.

    local.servergid

    Runtime group identifier (gid). The default is "icsgroup". This is the group identifier to use when super-user privileges are not needed.

    local.autorestart

    If this parameter is set to "yes", if a service that is connected to the watcher dies without properly disconnecting, it is automatically restarted.

    local.autorestart.timeout

    Defines the auto-restart timeout interval. To avoid infinite restart attempts on auto-start, if a service dies twice in a specific interval, it will not be restarted. The default setting is 10 minutes. 

  6. Save the file as ics.conf.

  7. Restart Calendar Server.

    cal-svr-base/SUNWics5/cal/sbin/start-cal

ProcedureTo Configure the Watcher Process for Calendar Server Version 6.3

The watcher process, watcher, monitors failed socket connections. It is used with both Calendar Server and Messaging Server. To set the Calendar Server parameters to configure Watcher, perform the following steps:

  1. Log in as an administrator with permission to change the configuration.

  2. Stop Calendar Server services by issuing the stop-cal command.

  3. Change to the /etc/opt/SUNWics5/cal/config directory.

  4. Save your old ics.conf file by copying and renaming it.

  5. Edit one or more of the parameters as shown in the following table:

    Parameter  

    Description and Default Value  

    local.watcher.enable

    If this parameter is set to "yes", the start program attempts to start the watcher before any other services. And daemons will connect to it through a socket connection. The default is "no", but the configuration program changes it to "yes".

    local.watcher.port

    This is the port on which the watcher listens. Messaging Server uses port 49994. A different port should be used for Calendar Server, for example 49995.

    local.watcher.config.file

    The configuration file for watcher. If the path is relative, it is relative to the config directory. The default is watcher.cnf.

    service.autorestart

    If set to "yes", the watcher automatically restarts any registered service that dies without properly disconnecting. If the service dies twice in 10 minutes, watcher will not restart it.

  6. Save the file as ics.conf.

  7. Restart Calendar Server.

    cal-svr-base/SUNWics5/cal/sbin/start-cal

See Also

For more information about the Watcher process, see Sun Java System Messaging Server 6.3 Administration Guide. Both Chapter 4 and Chapter 23 have information.


Note –

If Watcher is enabled, each service the Watcher is monitoring must be registered with the Watcher process. This is done automatically and internally by Calendar Server daemons. Alternatively, the daemons create a pid files in the cal-svr-base/data/proc directory that contain the process ID of each service and its status, either "init", or "ready".


ProcedureTo Configure Administrative Services (csadmind)

  1. Log in as an administrator with permission to change the configuration.

  2. Change to the /etc/opt/SUNWics5/cal/config directory.

  3. Save your old ics.conf file by copying and renaming it.

  4. Edit one or more of the parameters as shown in the following table:

    Parameter  

    Description and Default Value  

    local.store.checkpoint.enable

    If "yes", start the csadmind database checkpoint thread. If "no", no checkpoint log files created. The default is "yes".

    service.admin.dbcachesize

    Maximum cache size (in bytes) for Berkeley Database for administration sessions. The default is "8388608".

    local.store.deadlock.enable

    If "yes", start the csadmind database deadlock detection thread. The default is "yes".

    service.admin.diskusage

    If "yes", start the csadmind low disk space monitor thread. The default is "no". Disk usage is not monitored by default.

    service.admin.enable

    If "yes", start the csadmind service when starting all services and stop csadmind when stopping all services. The default is “yes”.

    service.admin.maxthreads

    Maximum number of running threads per administration session. The default is “10”.

    service.admin.resourcetimeout

    Number of seconds before timing out an administration connection. The default is “900”.

    service.admin.serverresponse

    If "yes", start the csadmind service response thread. The default is “no”.

    service.admin.sessiondir.path

    Temporary directory for administration session requests. No default. 

    service.admin.sessiontimeout

    Number of seconds before timing out an HTTP session in csadmind. The default is “1800”.

    service.admin.sleeptime

    Number of seconds to wait between checking for started, stopped, or ready calendar service. The default is “2”.

    service.admin.starttime

    Number of seconds to wait for any calendar service to start. The default is “300”.

    service.admin.stoptime

    Number of seconds to wait for any calendar service to stop. The default is “300”.

    service.admin.stoptime.next

    Number of seconds to wait between sending stop commands to any calendar service. The default is “60”.

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal-svr-base/SUNWics5/cal/sbin/start-cal

ProcedureTo Configure HTTP Services (cshttpd) for Calendar Server Version 6.3

  1. Log in as an administrator with permission to change the configuration.

  2. Change to the /etc/opt/SUNWics5/cal/config directory.

  3. Save your old ics.conf file by copying and renaming it.

  4. Edit one or more of the parameters as shown in the following table:

    Parameter  

    Description and Default Value  

    service.http.admins

    Space separated list of user ID's with administration rights to this Calendar Server. The default is "calmaster".

    service.http.allowadminproxy

    If "yes", allow login via proxy, which is the default.

    service.http.allowanonymouslogin

    If "yes", allow anonymous (no authentication) access. This is a special type of login that is allowed only specified, restricted access (usually read only access to public calendars). The default is "yes".

    service.http.calendarhostname

    HTTP host for retrieving HTML documents. To enable users to use a fully qualified host name to access calendar data, this value must be the fully qualified host name (including the machine name, DNS domain and suffix) of the machine on which Calendar Server is running, such as mycal@sesta.com.

    If not specified, the local HTTP host is used. 

    service.http.commandlog

    This parameter is for debugging only. If set to "yes", the system logs all incoming commands into the http.commands log file.

    Do not use this during production runtime. It will fill up the log file very quickly and could cause performance degradation. 

    service.http.commandlog.all

    This parameter is for debugging only. If set to "yes", the system logs all HTTP requests into the http.access log file.

    Do not use this during production runtime. It will fill up the log file very quickly and could cause performance degradation. 

    service.http.cookies

    Tells the server to whether or to support cookies (yes/no). It must be set to "yes" to enable single sign-on. The default is "yes".

    service.http.dbcachesize

    Maximum cache size of Berkeley database for HTTP sessions. The default is "8388308".

    service.http.domainallowed

    If specified and not blank (" "), filter to allow access based on TCP domains. For example, "ALL: LOCAL.sesta.com" would allow local HTTP access to anyone in the sesta.com domain. Multiple filters are separated by CR-LF (line feed). The default is blank ("").

    service.http.domainnotallowed

    If specified and not blank (" "), filter to not allow access based on TCP domains. For example, "ALL: LOCAL.sesta.com" would deny HTTP access to anyone in the sesta.com domain. Multiple filters must be separated by CR-LF (line-feed). The default is blank (" ").

    service.http.attachdir.path

    Directory location relative to local.queuedir (or an absolute path if specified) where imported files are temporarily stored. The default is the current directory (".").

    service.http.ipsecurity

    If "yes", all requests that reference an existing session are verified as originating from the same IP address. The default is “yes”.

    service.http.enable

    If "yes", start the cshttpd service when starting all services and stop cshttpd when stopping all services. The default is “yes”.


    Caution – Caution –

    Disabling the HTTP service with this parameter will also disable HTTPS.


    service.http.idletimeout

    Number of seconds before timing out an HTTP connection. The default is “120”.

    service.http.listenaddr

    Specifies the TCP address that HTTP services will listen on for client requests. The default is "INADDR_ANY", which indicates any address.

    service.http.logaccess

    If "yes", HTTP connections to server are fully logged. The default is “no”.

    service.http.maxsessions

    Maximum number of HTTP sessions in cshttpd service. The default is “5000”.

    service.http.maxthreads

    Maximum number of threads to service HTTP requests in cshttpd service. The default is “20”.

    service.http.numprocesses

    Maximum number of concurrently running HTTP service (cshttpd) processes that should run on a server. The default is “1”.

    For a server that has multiple CPU's, see 21.8 Using Load Balancing Across Multiple CPU's.

    service.http.port

    Port for HTTP requests from Calendar Server users. The default is “80”.

    service.http.proxydomainallowed

    If specified and not "", filter for allowing proxy login based on TCP domains. Same syntax as service.http.domainallowed. The default is "".

    service.http.resourcetimeout

    Number of seconds before timing out an HTTP session. The default is “900”.

    service.http.sessiondir.path

    Directory for the HTTP session database. The default is “http”.

    service.http.sessiontimeout

    Number of seconds before timing out an HTTP session in cshttpd service. The default is “1800”.

    service.http.sourceurl

    Directory relative to executable where all URL references to files are stored. The default is "" (null).

    service.http.tmpdir

    Temporary directory for HTTP sessions. The default is “/var/opt/SUNWics5/tmp”.

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal-svr-base/SUNWics5/cal/sbin/start-cal

ProcedureTo Configure Alarm Notification for Calendar Server Version 6.3

  1. Log in as an administrator with permission to change the configuration.

  2. Change to the /etc/opt/SUNWics5/cal/config directory.

  3. Save your old ics.conf file by copying and renaming it.

  4. Edit one or more of the following ics.conf parameters as shown in the following table:

    Parameter  

    Description and Default Value  

    alarm.diskstat.msgalarmdescription

    Description sent with insufficient disk space messages. 

    The default description is: “percentage calendar partition diskspace available”.

    alarm.diskstat.msgalarmstatinterval

    Number of seconds between monitoring disk space. The default is “3600”.

    alarm.diskstat.msgalarmthreshold

    Percentage of available disk space that triggers sending a warning message. The default is “10”.

    alarm.diskstat.msgalarmthresholddirection

    Whether alarm.diskstat.msgalarmthreshold is above or below percentage. -1 is below and 1 is above. The default is “-1”.

    alarm.diskstat.msgalarmwarninginterval

    Number of hours between sending warning messages about insufficient disk space. The default is “24”.

    alarm.msgalarmnoticehost

    The host name of the SMTP server used to send server alarms. The default is “localhost”.

    alarm.msgalarmnoticeport

    The SMTP port used to send server alarms. The default is “25”.

    alarm.msgalarmnoticercpt

    The email address to whom server alarms sent. “Postmaster@localhost”

    alarm.msgalarmnoticesender

    The email address used as the sender when the server sends alarms. The default is “Postmaster@localhost”

    alarm.msgalarmnoticetemplate

    The default format used to send email alarms: 

    "From: %s\nTo: %s\nSubject: ALARM: %s of \"%s\" is n\n%s\n"

    alarm.responsestat.msgalarmdescription

    Description sent with no service response messages. The default is “calendar service not responding”.

    alarm.responsestat.msgalarmstatinterval

    Number of seconds between monitoring services. The default is “3600”.

    alarm.responsestat.msgalarmthreshold

    The default is “100” (only trigger sending a warning message if no service response.)

    alarm.responsestat.

    msgalarmthresholddirection

    Specifies whether alarm.responsestat.msgalarmthreshold is above or below percentage. -1 is below and 1 is above. The default is “-1”

    alarm.responsestat.

    msgalarmwarninginterval

    Number of hours between sending warning messages about no service response sent out. The default is “24”.

    local.rfc822header.allow8bit

    Allow (“y”) or not allow (“n”) 8 bit headers in email messages sent by this server.

    service.admin.alarm

    Enable ("yes") or disable ("no") alarm notifications for administration tools. The default is “yes”.

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal-svr-base/SUNWics5/cal/sbin/start-cal

4.7 Configuring Periodic Deadlock Checking for the Berkeley in Calendar Server Version 6.3

You can configure the Calendar Server to periodically check for deadlocks in the Berkeley databases.

It is possible for the Berkeley databases to get into a deadlocked state, thus preventing access to them. To detect this state as early as possible, enable periodic checking for deadlocks.

ProcedureTo Enable Periodic Checking of Berkeley Databases for Deadlocks

  1. Log in as an administrator with permission to change the configuration.

  2. Change to the /etc/opt/SUNWics5/cal/config directory.

  3. Save your old ics.conf file by copying and renaming it.

  4. Edit the parameter shown in the following table:

    local.caldb.deadlock.autodetect

    Periodically checks if the Berkeley database is in a deadlock state and, if so, instructs the database to reset. The default value is “no” (not enabled).

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal-svr-base/SUNWics5/cal/sbin/start-cal

Troubleshooting

For information about how to reset Berkeley databases once deadlocked, see 22.5.2 Detecting Database Corruption22.5.1.2 List of Available Tools in the Troubleshooting chapter.

4.8 Configuring LDAP for Calendar Server Version 6.3

This section contains instructions for configuring Calendar Server for LDAP.

This section contains the following topics:

ProcedureTo Configure Anonymous Access to LDAP for Calendar Server Version 6.3

In general, anonymous access is allowed by default. If you want to restrict anonymous access, change the appropriate parameters.

  1. Log in as an administrator with permission to change the configuration.

  2. Change to the /etc/opt/SUNWics5/cal/config directory.

  3. Save your old ics.conf file by copying and renaming it.

  4. Edit one or more of the parameters in the following:

    Parameter  

    Description/Default  

    calstore.anonymous.calid

    Specifies the anonymous login calendar identifier (calid). The default is "anonymous".

    service.http.allowanonymouslogin

    Specifies whether or not anonymous access is allowed without a login. The default is “yes”. (Allows recipient of emailed calendar URL to access a free-busy version of the calendar without login in.)

    service.wcap.anonymous.

    allowpubliccalendarwrite

    Specifies whether or not to allow anonymous users to write to a publicly writable calendar. The default is “yes”.

    service.wcap.userprefs.ldapproxyauth

    Enables anonymous search of the LDAP used for user preferences. The default is “no”, which allows anonymous access. Specifying “yes” means using proxy authentication to do the search.

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal-svr-base/SUNWics5/cal/sbin/start-cal

ProcedureTo Configure LDAP Attendee Lookup for Calendar Server Version 6.3

  1. Log in as an administrator with permission to change the configuration.

  2. Change to the /etc/opt/SUNWics5/cal/config directory.

  3. Save your old ics.conf file by copying and renaming it.

  4. Edit one or more of the parameters in the following table:

    Parameter  

    Description/Default  

    local.lookupldap.search.

    minwildcardsize

    Specifies the minimum string size for wildcard searches in an attendee lookup search. Zero (0) means always do a wildcard search.

    sasl.default.ldap.searchfilter

    Specifies the authentication filter for user lookup. The default is: "(uid=%s)"

    local.lookupldapbasedn

    Specifies the DN for LDAP attendee lookup. If not specified, uses local.ugldapbsedn. No default value.

    local.lookupldapbinddn

    Specifies the DN to bind to the host used for LDAP attendee lookup. If not specified (default is ““), anonymous bind assumed.

    local.lookupldapbindcred

    Credentials (password) for user identified in local.lookupldapbinddn. No default value.

    local.lookupldaphost

    The host name for LDAP attendee lookup. If not specified, uses local.ugldaphost.

    local.lookupldapmaxpool

    Specifies the number of LDAP client connections maintained for LDAP attendee lookup. If not specified, uses local.ugldapmaxpool. The default is “1024”.

    local.lookupldappoolsize

    Specifies the minimum number of LDAP client connections maintained for LDAP attendee lookup. If not specified, uses local.ugldappoolsize. The default is “1”.

    local.lookupldapport

    Specifies the port to use for LDAP attendee lookup. If not specified, uses local.ugldapport.

    local.lookupldapsearchattr.calid

    Specifies the calid attribute for attendee lookup. The default is icsCalendar.

    local.lookupldapsearchattr.mail

    Specifies the mail attribute for attendee lookup. The default is mail.

    local.lookupldapsearchattr.

    mailalternateaddress

    Specifies the alternate mail address attribute for attendee lookup. The default is mailalternateaddress.

    local.lookupldapsearchattr.

    mailequivalentaddres

    Specifies the equivalent address mail attribute for attendee lookup. The default is mailequivalentaddress.

    local.lookupldapsearchattr.

    calendar

    Specifies the calendar attribute for attendee lookup. The default is icsCalendar.

    local.lookupldapsearchattr.cn

    Specifies the common name attribute for attendee lookup. The default is cn.

    local.lookupldapsearchattr.

    objectclass

    Specifies the object class attribute for attendee lookup. The default is objectclass.

    local.lookupldapsearchattr.

    objectclass.caluser

    Specifies the object class for calendar users. The default is icsCalendarUser.

    local.lookupldapsearchattr.

    objectclass.calresource

    Specifies the object class for calendar resources. The default is icsCalendarResource.

    local.lookupldapsearchattr.

    objectclass.group

    Specifies the object class for groups. The default is icsCalendarGroup.

    local.lookupldapsearchattr.

    objectclass.person

    Specifies the object class for persons. The default is person.

    local.lookupldapsearchattr.

    memberurl

    Specifies the member URL attribute for attendee lookup. The default is memberurl.

    local.lookupldapsearchattr.

    uniquemember

    Specifies the unique member attribute for attendee lookup. The default is uniquemember.

    local.lookupldapsearchattr.

    givenname

    Specifies the given name attribute for attendee lookup. The default is givenname.

    local.lookupldapsearchattr.sn

    Specifies the screen name attribute for attendee lookup. The default is sn.

    local.smtp.defaultdomain

    Name of the default domain used to lookup an attendee’s calendar ID that corresponds to an email address. For example, jsmith resolves to jsmith@sesta.com if the value for this setting is "sesta.com".

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal-svr-base/SUNWics5/cal/sbin/start-cal

ProcedureTo Configure Search Filters for LDAP Attendee Lookup for Calendar Server Version 6.3

  1. Log in as an administrator with permission to change the configuration.

  2. Change to the /etc/opt/SUNWics5/cal/config directory.

  3. Save your old ics.conf file by copying and renaming it.

  4. Edit one or more of the parameters in the following table:


    Tip –

    In all the parameter descriptions that follow, %s allows only a single attendee.


    Parameter  

    Description/Default  

    local.lookupldap.calid.direct

    The search filter for calid-search-type using direct lookup. The default is: "(icsCalendar=%s)

    %s – The attendee string. 

    local.lookupldap.cn.direct

    The search filter for cn-search-type in direct lookup. The default is:  

    "(&(cn=%s)
    (|(objectclass=groupofuniquenames)
    (objectclass=icsCalendarResource)
    (objectclass=person)))"

    %s – The attendee string.

    local.lookupldap.cn.search

    The search filter for cn-search-type in search dialog lookup. The default is for a single attendee string (%s):

    "(&(cn=%s)
      (|(objectclass=groupofuniquenames)
      (objectclass=icsCalendarResource)
      (objectclass=person)))"

    For a wild card search (multiple search strings): 

    "(&(cn=%w)
      (|(objectclass=groupofuniquenames)
      (objectclass=icsCalendarResource)
      (objectclass=person)))"

    %w – Causes expansion to a list of attendee strings. For example: %w=”Mary Ann Smith” expands to:

    (& (cn=*Mary*) (cn=”*Ann”)
     (cn=*Smith*)

    local.lookupldap.gid

    The search filter for gid search type. The default is:

    "(&(cn=%s)
       (objectclass=groupofuniquenames))"

    %s — A single attendee string.

    local.lookupldap.mailto.indomain

    The search filter for mailto-search-type in the domain specified by local.smtp.defaultdomain. The default is:

    "(|(mail=%s)(mail=%h)(mail=*<%s\>*)
       (uid=%o))"

    %s – The attendee string.

    %o – The attendeeuid.

    %h – The query string without the domain part.

    For example: if %s=jdoe@sesta.com, %o=jdoe@sesta.com and %h=jdoe, then the value is:

    (|(mail=jdoe@varrius.com)
       (mail=jdoe)
       (mail=*<jdoe@varrius.com\>*)
       (uid=jdoe@varrius.com))

    local.lookupldap.mailto.outdomain

    The search filter for mailto-search-type where the domain is not the one specified by local.smtp.defaultdomain. The default is: "(|(mail=%s)(uid=%s))"

    %s – The attendee string.

    local.lookupldap.res

    The search filter for res search type (resource search). The default is:

    "(&(cn=%s)
       (objectclass=icsCalendarResource))"

    $s – The attendee string.

    local.lookupldap.res.ugldap

    The search filter for res search type (resource search) only on the User/Group LDAP server. This is only set when local.lookupldap.resource.use.ugldap is set to “yes”. The default is:

    "(&(cn=%s)
       (objectclass=icsCalendarResource))"

    %s – The attendee string.

    local.lookupldap.uid.direct

    The search filter for uid search type using direct lookup. The default is:

    "(|(uid=%s)(&(cn=%s)
       (|(objectclass=groupofuniquenames)
       (objectclass=icsCalendarResource)
       (objectclass=person))))"

    %s – The attendee string.

    local.lookupldap.uid.search

    The search filter for uid search type lookup using a search dialog. The default is:

     

    "(|(uid=%o)(&(cn=%w)
       (|(objectclass=groupofuniquenames)
       (objectclass=icsCalendarResource)
       (objectclass=person))))"

    %s – The attendee string.

    %w – The attendee string with wildcards.

    %o – The attendee string without wildcards.

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal-svr-base/SUNWics5/cal/sbin/start-cal

ProcedureTo Configure LDAP Resource Lookup for Calendar Server Version 6.3

  1. Log in as an administrator with permission to change the configuration.

  2. Change to the /etc/opt/SUNWics5/cal/config directory.

  3. Save your old ics.conf file by copying and renaming it.

  4. Edit the parameter shown in the following table:

    local.lookupldap.resource.use.ugldap

    Whether to use the User/Group LDAP server for resource lookup, or the Lookup server.

    “yes” – Use the User/Group LDAP server.

    “no” – Use the Lookup server. The default is “no”.

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal-svr-base/SUNWics5/cal/sbin/start-cal

ProcedureTo Configure LDAP Mail-to-Calid Lookup for Calendar Server Version 6.3

  1. Log in as an administrator with permission to change the configuration.

  2. Change to the /etc/opt/SUNWics5/cal/config directory.

  3. Save your old ics.conf file by copying and renaming it.

  4. Edit one or more of the parameters in the following table:

    Parameter  

    Description/Default  

    local.lookupldap.mailtocalid.search

    Specifies the mail attributes to use for mail-to-calid lookup. The default is "(|(mail=%s)(mailalternateaddress=%s))”

    You can substitute the attribute mailequivalentaddress in place of mailalternateaddress.

    local.ugldapbasedn

    Specifies the base DN for mail-to-calid lookup.  

    local.authldapbinddn

    Specifies the DN to bind to the host used for mail-to-calid lookup. If not specified (default is ""), anonymous bind assumed.

    local.authldapbindcred

    Specifies the password for the DN specified in local.authldapbinddn. No default.

    local.ugldaphost

    Specifies the LDAP host used for mail -to-calid lookup. 

    local.ugldapmaxpool

    Specifies the maximum number of client connections maintained for mail-to-calid lookup. The default is “1024”.

    local.ugldappoolsize

    Specifies the minimum number of client connections to maintain for mail-to-calid lookup. The default is “1”.

    local.ugldapport

    Specifies the port for the LDAP mail-to-calid lookup. No default. 

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal-svr-base/SUNWics5/cal/sbin/start-cal

ProcedureTo Configure the User Preferences LDAP Directory for Calendar Server Version 6.3

  1. Log in as an administrator with permission to change the configuration.

  2. Change to the /etc/opt/SUNWics5/cal/config directory.

  3. Save your old ics.conf file by copying and renaming it.

  4. Edit one or more of the parameters in the following table:

    Parameter  

    Description/Default  

    local.enduseradmincred

    Bind credentials (password) for LDAP user preferences authentication. No default. 

    local.enduseradmindn

    DN used to bind to LDAP user preferences host. Must be specified. If blank (" ") or not specified, assumes an anonymous bind.

    local.ugldappoolsize

    Minimum number of LDAP client connections that are maintained for LDAP user preferences. The default is “1”.

    local.ugldapmaxpool

    Maximum number of LDAP client connections that are maintained for LDAP user preferences. The default is “1024”.

    service.wcap.userprefs.ldapproxyauth

    Enables anonymous search of the LDAP used for user preferences. The default is “no”, which allows anonymous access. Specifying “yes” means using proxy authentication to do the search.

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal-svr-base/SUNWics5/cal/sbin/start-cal

ProcedureTo Configure User Preferences for Calendar Server Version 6.3

You can restrict the preferences users are allowed to set by removing them from the default list.

  1. Log in as an administrator with permission to change the configuration.

  2. Change to the /etc/opt/SUNWics5/cal/config directory.

  3. Save your old ics.conf file by copying and renaming it.

  4. Edit the list of user preferences in the parameter shown in the following table:

    Parameter  

    Default List of User Preferences  

    Description  

    local.

    ugldapicsextendeduserprefs

    "ceColorSet,

    ceFontFace,

    ceFontSizeDelta,

    ceDateOrder,

    ceDateSeparator,

    ceClock,

    ceDayHead,

    ceDayTail,

    ceInterval,

    ceToolText,

    ceToolImage,

    ceDefaultAlarmStart,

    ceSingleCalendarTZID,

    ceAllCalendarTZIDs,

    ceDefaultAlarmEmail,

    ceNotifyEmail,

    ceNotifyEnable,

    ceDefaultView,

    ceExcludeSatSun,

    ceGroupInviteAll"

    User preference values are kept in LDAP. This parameter defines which user preferences are kept in LDAP in the icsExtendedUserPrefs attribute.

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal-svr-base/SUNWics5/cal/sbin/start-cal

ProcedureTo Enable and Configure the LDAP Data Cache for Calendar Server Version 6.3

Before You Begin

For overview information about the LDAP Data Cache, see 1.7 LDAP Data Cache Option for Calendar Server Version 6.3.

  1. Log in as an administrator with permission to change the configuration.

  2. Change to the /etc/opt/SUNWics5/cal/config directory.

  3. Save your old ics.conf file by copying and renaming it.

  4. Enable the LDAP data cache by editing the parameter as shown in the following table:

    Parameter  

    Description and Default Value  

    local.ldap.cache.enable

    Enable or disable the LDAP cache. If “yes”, the cache is enabled. If “no” the cache is disabled. The default is “no”.

    local.ldap.cache.checkpointinterval

    Specifies the number of seconds for the checkpoint thread to sleep. The default time is 60 seconds. 

    local.ldap.cache.circularlogging

    Specifies whether or not to remove the database log files after they have been processed. The default is "yes" .

    local.ldap.cache.homedir.path

    Specifies the physical location of LDAP data cache database. The default is:  

    cal-svr-base/var/opt/SUNWics5
    /csdb/ldap_cache

    local.ldap.cache.logfilesizemb

    Specifies the maximum size in megabytes of the checkpoint file. The default is 10 megabytes. 

    local.ldap.cache.maxthreads

    Specifies the maximum number of threads for the LDAP data cache database. The default is "1000" .

    local.ldap.cache.mempoolsizemb

    Specifies the number of megabytes of shared memory. The default is "4" megabytes.

    local.ldap.cache.entryttl

    Not currently implemented. 

    Specifies the time to live (TTL) in seconds for an LDAP data cache entry. The default is "3600" seconds (1 hour).

    local.ldap.cache.stat.enable

    Specifies whether or not to log the access to the LDAP data cache and to print statistics in the log file. The default is no .  


    Note –

    This parameter applies only to debug mode.


    local.ldap.cache.stat.interval

    Specifies the interval in seconds when each statistics report is written to the log file. The default is "1800" seconds (30 minutes).

    local.ldap.cache.cleanup.interval

    Specifies the interval in seconds between each database cleanup. The default is "1800" seconds (30 minutes).

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal-svr-base/SUNWics5/cal/sbin/start-cal

See Also

For information about tuning the LDAP data cache, see 21.5 Improving Performance of the LDAP Data Cache.


Caution – Caution –

If Calendar Server or the server where Calendar Server is running is not properly shut down, manually delete all files in the ldap_cache directory to avoid any database corruption that might cause problems during a subsequent restart.


ProcedureTo Enable and Configure the LDAP SDK Cache for Calendar Server Version 6.3

The LDAP SDK cache is disabled by default.

  1. Log in as an administrator with permission to change the configuration.

  2. Change to the /etc/opt/SUNWics5/cal/config directory.

  3. Save your old ics.conf file by copying and renaming it.

  4. Editing one or more of the parameters as shown in the following table:

    service.ldapmemcache

    If "yes", enables LDAP SDK cache. The default is “no”.

    service.ldapmemcachettl

    If service.ldapmemcache is "yes", this parameter is used to set the maximum number of seconds that an item can be cached. If “0”, there is no limit to the amount of time that an item can be cached. The default is “30”.

    service.ldapmemcachesize

    If service.ldapmemcache is "yes", this parameter is used to set the maximum amount of memory in bytes that the cache will consume. If “0”, the cache has no size limit. The default is “131072”.

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal-svr-base/SUNWics5/cal/sbin/start-cal

ProcedureTo Set the Date Range for Free Busy Searches for Calendar Server Version 6.3

  1. Log in as an administrator with permission to change the configuration.

  2. Change to the /etc/opt/SUNWics5/cal/config directory.

  3. Save your old ics.conf file by copying and renaming it.

  4. Edit one or more of the following parameters as shown in the following table:

    service.wcap.freebusybegin

    Specifies the offset from the current time in days for get_freebusy for beginning of the range. The default is “30”.

    service.wcap.freebusyend

    Specifies the offset from the current time in days for get_freebusy for end of the range. The default is “30”.

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal-svr-base/SUNWics5/cal/sbin/start-cal

ProcedureTo Enable Wildcard LDAP Searches of Calendar Properties for Calendar Server Version 6.3

  1. Log in as an administrator with permission to change the configuration.

  2. Change to the /etc/opt/SUNWics5/cal/config directory.

  3. Save your old ics.conf file by copying and renaming it.

  4. Edit the parameter as shown in the following table:

    service.calendarsearch.ldap.primaryownersearchfilter

    The default search filter used for search_calprops searches for exact matches to the search string. To allow wildcard searches such that matches are found when the search string is merely contained within the property value, uncomment this parameter. This enables the system to use the following search filter:

    "(&(|(uid=*%s*)(cn=*%s*))
    (objectclass=icsCalendarUser))"

    Enabling this search filter can negatively impact performance.

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal-svr-base/SUNWics5/cal/sbin/start-cal

ProcedureTo Set the LDAP Root Suffix in Calendar Server Version 6.3

While it is possible to reset the root suffix for your LDAP organization tree (Schema version 2), or domain component tree (Schema version 1), this should be done with great care. It would be better to rerun the configuration program to do this.

  1. Log in as an administrator with permission to change the configuration.

  2. Change to the /etc/opt/SUNWics5/cal/config directory.

  3. Save your old ics.conf file by copying and renaming it.

  4. Edit one of the parameters as shown in the following table:

    service.dcroot

    Root suffix of the DC tree in the directory. Required for multiple domain support using Schema version 1, and Schema version 2 compatibility mode (1.5). The default is "o=internet".

    See also 10.2 Setting up a Multiple Domain Environment for Calendar Server Version 6.3 for the First Time.

    service.schema2root

    Root suffix of the DIT (Organization Tree) for Schema version 2. No default value.

  5. Save the file as ics.conf.

  6. Restart Calendar Server:

    cal-svr-base/SUNWics5/cal/sbin/start-cal

Chapter 5 Configuring Calendar Database Distribution Across Multiple Machines in Calendar Server Version 6.3

This chapter describes how to use the Calendar Lookup Database (CLD) plug-in to enable the calendar database to be distributed over multiple back-end servers. You must both enable and configure the CLD plug-in.


Caution – Caution –

You must run the same version of Calendar Server on both the front-end and back-end servers.


This chapter contains the following topics:


Tip –

For information on how to improve the performance of the CLD plug-in, see Chapter 21, Tuning Calendar Server Performance.


5.1 CLD Plug-in Background Information for Calendar Server Version 6.3

This section covers valuable overview and background information that you might want to understand before actually enabling and configuring the CLD plug-in.

This section contains the following topics:

5.1.1 CLD Plug-in Overview for Calendar Server Version 6.3

The Calendar Lookup Database (CLD) plug-in provides horizontal scalability of the calendar database by allowing user and resource calendars to be distributed over a number of back-end servers for a single calendar instance. When the calendar database is distributed over several back-end servers, Calendar Server uses the CLD plug-in to determine the actual server where a calendar is stored.

Calendar Server accesses the calendar data on the back-end server using the Database Wire Protocol (DWP). DWP is an internal protocol that runs as the csdwpd service and provides the networking capability for the calendar database.

5.1.2 How the CLD Plug-in Works for Calendar Server Version 6.3

Calendar Server accesses calendar data on a back-end server as follows:

  1. When an end user accesses a calendar through Communications Express, the CLD plug-in extracts the userid from the calendar’s calid and then looks up the calendar owner in the LDAP directory database, or the CLD data cache (if enabled). For information and instructions on configuring a front-end machine, see To Configure a Front-End Server for CLD.

  2. After finding the calendar owner, the plug-in uses the value in the icsDWPHost LDAP attribute to determine the host name of the back-end server where the calendar resides. This host name must be resolvable by your Domain Name Service (DNS) into a valid IP address.

  3. Using the host name, Calendar Server accesses the calendar data on the back-end server using the Database Wire Protocol (DWP).

  4. Using DWP, Calendar Server sends the calendar data to the server where the user is logged in, so it can be rendered in one of the user interfaces.


Tip –

If your site is using the CLD plug-in, all calendars created for the same user must reside on the same back-end server, as indicated by the LDAP user entry’s icsDWPHost LDAP attribute. If you try to create a calendar on a different back-end server, Calendar Server returns an error.


5.1.3 Configurations Supported by the CLD Plug-in for Calendar Server Version 6.3

This section contains overview material about the CLD Plug-in.

The CLD plug-in supports the following Calendar Server configurations:


Tip –

In all configurations, each front-end and back-end server must:


5.1.3.1 Multiple Front-end Servers with Multiple Back-end Servers in Calendar Server Version 6.3

Figure 5–1 shows two front-end servers and two back-end servers running a single Calendar Server instance. You can also configure more than two front-end or back-end servers, if you wish.

This configuration allows the servers to be protected by a firewall to restrict access to the LDAP and calendar databases. The calendar database is distributed across the two back-end servers.

The front-end servers are CPU intensive, with most CPU time spent rendering calendar data for end-users. The back-end servers are disk intensive, with most CPU time spent accessing the calendar database.

For configuration instructions, see 5.2 Configuring Calendar Servers for CLD and DWP.

Figure 5–1 Multiple Front-End Servers with Multiple Back-End Servers

This shows an example of a system with both multiple
back-ends and front-ends.

5.1.3.2 Multiple Machines Functioning as Both Front-end and Back-end Servers in Calendar Server Version 6.3

Figure 5–2 shows three machines functioning as both front-end and back-end servers. Each machine is connected to a calendar database. This configuration allows calendars to be geographically distributed. Calendar owners (end users) log into the machine where their calendars reside. For configuration instructions, see To Configure a Server as Both a Front-end and a Back-end.

Figure 5–2 Multiple Servers as Functioning as Both Front-end and Back-end

This graphic shows an example of machines functioning
as both front-end and back-end machines.

5.1.4 Simple Sizing Exercise for Calendar Server 6.3 Storage Requirements

This section describes a simple sizing method using a few rough formulas based on a medium usage profile. They allow you to figure out how many front-end and back-end servers you need and how much storage.

This sections covers the following topics:

5.1.4.1 Definition of Medium Usage Profile for a Calendar Server 6.3 Deployment

For our rough estimates, we are assuming the following:

5.1.4.2 Number of Front-End CPU's

The formula is:

Number of CPU's = Number of Concurrent Users divided by 4800

5.1.4.3 Number of Back-End CPU's

The formula is:

Number of CPU's = 4 CPU's per 500,000 configured users

5.1.4.4 Amount of Storage Needed

The formula is:

Amount of Storage Per User = 100 emails per week, multiplied by 52 weeks a year, multiplied by 5K per email, multiplied by the number of years worth of data to keep online, multiplied by the number of copies (5 backups + 1 working copy) kept online = 100*52*5K*2*(5+1) = 65 MB storage per user.

That is 2.6 MB per user per year per copy held online.


Note –

The final number depends on how many hot backups or archival backups you keep online. For this example, 5 backup copies was the number used.


5.2 Configuring Calendar Servers for CLD and DWP

This sections contains instructions for configuring servers for CLD and DWP.

This section contains the following topics:

ProcedureTo Configure a Front-End Server for CLD

  1. On every front-end server, log in as an administrator with permission to change the configuration.

  2. Change to the /etc/opt/SUNWics5/cal/config directory.

  3. Save your old ics.conf file by copying and renaming it.

  4. Edit the ics.conf parameters as shown in the following list:

    Parameters

    Description

    csapi.plugin.loadall

    For every front-end server, set the value to “y” if you want all plug-ins starting with cs_ to be loaded into the cal-svr-base/SUNWics5/cal/bin/plugins directory.

    Set to “n”, to load only a specific plug-in, the name of which is found in csapi.plugin.calendarlookup.name.

    csapi.plugin.calendarlookup

    Set this parameter to "yes".

    csapi.plugin.calendarlookup.name

    Set this parameter to the name of the plug-in,"calendarlookup". Or, to load all plug-ins, set the parameter to "*".

    caldb.cld.type

    This parameter specifies whether calendars are to be distributed across multiple back-ends (set value to “directory”), or calendars are to be stored on the same server on which Calendar Server is installed (set value to,“local”, which is the default value).

    service.dwp.enable

    Disable DWP service for the front-end, unless it is also serving as a back-end machine. For example: service.dwp.enable="no"

    service.dwp.port

    The default port is “59979”. This port number must be the same for all front-end and back-end servers.

    service.store.enable

    This parameter is enabled by default (value = "yes"). It does not appear in the configuration file (ics.conf).

    It must be added to the configuration file if you wish to disable it (value = "no").

    caldb.dwp.server.backend-server-n.ip

    This is a multi-valued parameter. Create one ics.confparameter for each back-end server in your Calendar Server deployment. The value of this parameter is the back-end server hostname. The server name must be fully qualified and be resolvable by your Domain Name Service (DNS) into a valid IP address. The server name must be identical and fully qualified in both the parameter name and the value.

    For example:

    caldb.dwp.server.calendar1.sesta.com="calendar1.sesta.com"
    caldb.dwp.server.calendar2.sesta.com="calendar2.sesta.com"
    caldb.dwp.server.default

    Set the default DWP server name used by the system if the user or resource LDAP entry does not have an icsDWPHost attribute. The server name must be fully qualified and be resolvable by your DNS.

    For example:

    caldb.dwp.sever.default="calendar1.sesta.com"
    local.authldaphost

    The hostname where the Directory Server is installed. The default is "localhost".

    local.ugldaphost

    The hostname where the LDAP user preferences are stored. If you do not keep the user preferences in a separate LDAP host, then it should be set to the same value as local.authldaphost.

    service.ens.enable

    Disable ENS (enpd) for this front-end server, set this parameter to "no".

    ENS must be enabled only on the back-end servers.

    caldb.serveralarms

    To disable server alarms for the front-end by setting this to "0".

    Server alarms must be enabled ("1") only on the back-end servers.

    caldb.serveralarms.dispatch

    To disable the alarm dispatcher, set this parameter to "no".

    The alarm dispatcher should be enabled ("yes") only on the back-end servers.

    service.notify.enable

    To disable the notify service, set this parameter to "no".

    The notify service should be enabled ("yes") only on back-end servers.

    caldb.berkeleydb.archive.enable

    To disable the automatic archive backup service, set this parameter to "no". There is no need to have archiving configured on a front-end machine.

    caldb.berkeleydb.hotbackup.enable

    The automatic hot backup service should be disabled (value set to "no"). There is no need for hot backups on a front-end machine.

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal-svr-base/SUNWics5/cal/sbin/start-cal

ProcedureTo Configure a Back-end Server for CLD and DWP

  1. On every back-end server, log in as an administrator with permission to change the configuration.

  2. Change to the /etc/opt/SUNWics5/cal/config directory.

  3. Save your old ics.conf file by copying and renaming it.

  4. Edit the ics.conf parameters as shown in the following table:

    Parameters

    Description

    service.http.enable

    Set this parameter to "no".

    There is no need for HTTP on a back-end server.

    service.admin.enable

    Enable the administration service (csadmind) by setting the parameter to "yes", which is the default.

    caldb.cld.type

    If this machine is a back-end only machine, set to "local". If this machine is both a front-end and a back-end, set to "directory".

    csapi.plugin.calendarlookup

    Set this parameter to "no".

    There is no need for a plug-in on a back-end server.

    service.dwp.enable

    Enable DWP by setting this parameter to "yes"

    service.dwp.port

    The default port is “59979”. This port number must be the same for all front-end and back-end servers.

    caldb.dwp.server.backend-server-n.ip

    This is a multi-valued parameter. Create one ics.confparameter for each back-end server in your Calendar Server deployment. The value of this parameter is the back-end server hostname. The server name must be fully qualified and be resolvable by your Domain Name Service (DNS) into a valid IP address. The server name must be identical and fully qualified in both the parameter name and the value.

    For example:

    caldb.dwp.server.calendar1.sesta.com="calendar1.sesta.com"
    caldb.dwp.server.calendar2.sesta.com="calendar2.sesta.com"
    caldb.dwp.server.default

    Set the default DWP server name used by the system if the user or resource LDAP entry does not have an icsDWPHost attribute. The server name must be fully qualified and be resolvable by your DNS.

    For example:

    caldb.dwp.sever.default="calendar1.sesta.com"
    local.authldaphost

    The hostname where the Directory Server is installed. The default is "localhost".

    local.ugldaphost

    The hostname where the LDAP user preferences are stored. If you do not keep the user preferences in a separate LDAP host, then it should be set to the same value as local.authldaphost.

    service.ens.enable

    To enable ENS (enpd) for this back-end server, set this parameter to "yes".

    caldb.serveralarms

    Server alarms must be enabled ("1") on the back-end servers.

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal-svr-base/SUNWics5/cal/sbin/start-cal

ProcedureTo Configure a Server as Both a Front-end and a Back-end

  1. On every server, log in as an administrator with permission to change the configuration.

  2. Change to the /etc/opt/SUNWics5/cal/config directory.

  3. Save your old ics.conf file by copying and renaming it.

  4. Edit the ics.conf parameters as shown in the following table:

    Parameters

    Description

    csapi.plugin.loadall

    For every front-end server, set the value to “y” if you want all plug-ins starting with cs_ to be loaded into the cal-svr-base/SUNWics5/cal/bin/plugins directory.

    Set to “n”, to load only the CLD plug-in, the name of which is found in csapi.plugin.calendarlookup.name.

    csapi.plugin.calendarlookup

    Set this parameter to "yes".

    csapi.plugin.calendarlookup.name

    To load all plug-ins, set the parameter to "*".

    If you want to load only the CLD plug-in, set this parameter to the name of the plug-in,"calendarlookup".

    caldb.cld.type

    This parameter specifies whether calendars are to be distributed across multiple back-ends (set value to “directory”), or calendars are to be stored on the same server on which Calendar Server is installed (set value to,“local”, which is the default value).

    service.dwp.enable

    Enable DWP by setting this parameter to "yes"

    service.dwp.port

    The default port is “59979”. This port number must be the same for all front-end and back-end servers.

    caldb.dwp.server.backend-server-n.ip

    This is a multi-valued parameter. Create one ics.confparameter for each back-end server in your Calendar Server deployment. The value of this parameter is the back-end server hostname. The server name must be fully qualified and be resolvable by your Domain Name Service (DNS) into a valid IP address. The server name must be identical and fully qualified in both the parameter name and the value.

    For example:

    caldb.dwp.server.calendar1.sesta.com="calendar1.sesta.com"
    caldb.dwp.server.calendar2.sesta.com="calendar2.sesta.com"
    caldb.dwp.server.default

    Set the default DWP server name used by the system if the user or resource LDAP entry does not have an icsDWPHost attribute. The server name must be fully qualified and be resolvable by your DNS.

    For example:

    aldb.dwp.sever.default="calendar1.sesta.com"
    local.authldaphost

    The hostname where the Directory Server is installed. The default is “localhost”(on the same server as the front-end).

    local.ugldaphost

    The hostname where the LDAP user preferences are stored. If you do not keep the user preferences in a separate LDAP host, then it should be set to the same value as local.authldaphost.

    service.ens.enable

    Enable ENS by setting this parameter value to "yes".

    caldb.serveralarms

    Server alarms must be enabled ("1") on the back-end servers.

    caldb.serveralarms.dispatch

    The alarm dispatcher should be enabled ("yes") on the back-end servers.

    service.notify.enable

    The notify service should be enabled ("yes") on back-end servers.

    caldb.berkeleydb.archive.enable

    The automatic archive backup service should be enabled (value set to "yes"on the back-end systems.

    caldb.berkeleydb.hotbackup.enable

    The automatic hot backup service should be enabled (value set to "yes"on the back-end systems.

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal-svr-base/SUNWics5/cal/sbin/start-cal

5.3 Maintaining Security Between Front-End and Back-End Servers for Calendar Server Version 6.3

You can configure password authentication between front-end and back-end servers. This section explains how secure communication between the two can be set up and how it works.

This section covers the following topics:

5.3.1 How Authentication is Accomplished in Calendar Server Version 6.3

A front-end server uses the Database Wire Protocol (DWP) to communicate with a back-end server. Because DWP uses HTTP as the transport mechanism, Calendar Server provides authentication for DWP connections between front-end and back-end servers using configuration parameters.

When the front-end server first connects to the back-end server, it sends the user ID and password specified in the ics.conf file. The back-end server checks the parameters in its ics.conf file, and if both parameters match, the authentication is successful. The back-end server then sends a session ID back to the front-end server. The front-end server uses the session ID in subsequent DWP commands to the back-end server.

Subsequent connections from the same front-end server do not need to be authenticated again, unless the back-end server is restarted or the session expires because of no activity between the two servers.

If you have multiple front-end and back-end servers, you can use the same user ID and password for each one.

If a back-end server does not specify a user ID and password, no authentication is performed.

ProcedureTo Set Up Authentication for DWP Connections for a Front-end Server in Calendar Server Version 6.3

Before You Begin

Caution – Caution –

These parameters are not included in the installed version of the ics.conf file. To use authentication for DWP connections, you must add the required parameters to the ics.conf file on each front-end server.


  1. On every front-end server, log in as an administrator with permission to change the configuration.

  2. Change to the /etc/opt/SUNWics5/cal/config directory.

  3. Save your old ics.conf file by copying and renaming it.

  4. Add the ics.conf parameters as shown in the following list:

    Parameter

    Description

    caldb.dwp.server.back-end-server.admin

    On a front-end server, specifies the administrator's user ID that is used for authentication for a DWP connection to a back-end server, where back-end-server is the name of the server.

    caldb.dwp.server.back-end-server.cred

    On a front-end server, specifies the password that is used for authentication for a DWP connection to a back-end server, where back-end-server is the name of the server.

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal-svr-base/SUNWics5/cal/sbin/start-cal

ProcedureTo Set up Authentication for DWP Connections for a Back-end Server in Calendar Server Version 6.3

Before You Begin

Caution – Caution –

These parameters are not included in the installed version of the ics.conf file. To use authentication for DWP connections, you must add the required parameters to the ics.conf file on each back-end server.


  1. On every back-end server, log in as an administrator with permission to change the configuration.

  2. Change to the /etc/opt/SUNWics5/cal/config directory.

  3. Save your old ics.conf file by copying and renaming it.

  4. Add the ics.conf parameters as shown in the following table:

    Parameter

    Description

    service.dwp.admin.userid

    On a back-end server, specifies the user ID that is used to authenticate a DWP connection. If a back-end server does not specify a user ID, no authentication is performed.

    service.dwp.admin.cred

    On a back-end server, specifies the password that is used to authenticate a DWP connection. If a back-end server does not specify a password, no authentication is performed.

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal-svr-base/SUNWics5/cal/sbin/start-cal

Chapter 6 Configuring Calendar Server 6.3 Software for High Availability (Failover Service)

This chapter explains how to install and configure high availability for Calendar Server 6.3 software using Sun Cluster 3.0 or 3.1.

Configuring Calendar Server for High availability (HA) provides for monitoring of and recovery from software and hardware failures. The Calendar Server HA feature is implemented as a failover service. This chapter describes two Calendar Server HA configurations using Sun Cluster software, one asymmetric and one symmetric.

This chapter includes the following topics to describe how to install and configure HA for Calendar Server:

You can find a set of worksheets to help you plan a Calendar Server HA configuration in the Appendix C, Calendar Server Configuration Worksheet.

6.1 Overview of High Availability Choices for Calendar Server Version 6.3

High availability can be configured many ways. This section contains an overview of three high availability choices, and information to help you choose which is right for your needs.

This sections covers the following topics:

6.1.1 Understanding Asymmetric High Availability for Calendar Server Version 6.3

This figure shows a simple asymmetric HA Calendar Server
installation.

A simple asymmetric high availability system has two physical nodes. The primary node is usually active, with the other node acting as a backup node, ready to take over if the primary node fails. To accomplish a fail over, the shared disk array is switched so that it is mastered by the backup node. The Calendar Server processes are stopped on the failing primary node and started on the backup node.

There are several advantages of this type of high availability system. One advantage is that the backup node is dedicated and completely reserved for the primary node. This means there is no resource contention on the backup node when a failover occurs. Another advantage is the ability to perform a rolling upgrade; that is, you can upgrade one node while continuing to run Calendar Server software on the other node. Changes you make to the ics.conf file while upgrading the first node will not interfere with the other instance of Calendar Server software running on the secondary node because the configuration file is read only once, at startup. You must stop and restart the calendar processes before the new configuration takes effect. When you want to upgrade the other node, you perform a failover to the upgraded primary node and proceed with the upgrade on the secondary node.


Note –

You can, of course, choose to upgrade the secondary node first, and then the primary node.


The asymmetric high availability model also has some disadvantages. One disadvantage is that the backup node stays idle most of the time, making this resource underutilized. Another possible disadvantage is the single storage array. In the event of a disk array failure with a simple asymmetric high availability system, no backup is available

6.1.2 Understanding Symmetric High Availability for Calendar Server Version 6.3

This figure shows a simple symmetric HA system for Calendar
Server. Both nodes contain active instances of Calendar Server.

A simple symmetric high availability system has two active physical nodes, each with its own disk array with two storage volumes, one volume for the local calendar store, and the other a mirror image of the other node's calendar store. Each node acts as the backup node for the other. When one node fails over to its backup, two instances of Calendar Server run concurrently on the backup node, each running from its own installation directory and accessing its own calendar store. The only thing shared is the computing power of the back up node.

The advantage of this type of high availability system is that both nodes are active simultaneously, thus fully utilizing machine resources. However, during a failure, the backup node will have more resource contention as it runs services for Calendar Server from both nodes.

Symmetric high availability also provides a backup storage array. In the event of a disk array failure, its redundant image can be picked up by the service on its backup node.


Note –

To configure a symmetric high availability system, you install the Calendar Server binaries on your shared disk. Doing so might prevent you from performing rolling upgrades, a feature planned for future releases of Calendar Server that enables you to update your system with a Calendar Server patch release with minimal or no down time.


6.1.3 Understanding N+1 (N Over 1): Multiple Asymmetric High Availability for Calendar Server Version 6.3

This configuration is a series of asymmetric HA Calendar
Servers, each failing over to the same standby node.

In addition to the two types of highly available systems described in this chapter, a third type which is a hybrid of the two is also possible. This is a multi-node asymmetric high availability system. In this type, “N” disk arrays and “N” nodes all use the same backup node which is held in reserve and is not active normally. This backup node is capable of running Calendar Server for any of the “N” nodes. It shares each of the “N” node's disk array, as shown in the preceding graphic. If multiple nodes fail at the same time, the backup node must be capable of running up to “N” instances of Calendar Server concurrently. Each of the “N” nodes has its own disk array.

The advantages of the N+1 model are that Calendar Server load can be distributed to multiple nodes, and that only one backup node is necessary to sustain all the possible node failures.

The disadvantage of this type of high availability is the same as any asymmetric system; the backup node is idle most of the time. In addition, the N+1 high availability system backup node must have excess capacity in the event it must host multiple instances of Calendar Server. This means a higher cost machine is sitting idle. However, the machine idle ratio is 1:N as opposed to 1:1, as is the case in a single asymmetric system.

To configure this type of system, use the instructions for the asymmetric high availability system for each of the “N” nodes and the backup. Use the same backup node each time, but with a different primary node.

6.1.4 Choosing a High Availability Model for Your Calendar Server Version 6.3 Deployment

The following table summarizes the advantages and disadvantages of each high availability model. Use this information to help you determine which model is right for your deployment.

Table 6–1 Advantages and Disadvantages of Both High Availability Model

Model 

Advantages 

Disadvantages 

Recommended Users 

Asymmetric 

  • Simple Configuration

  • Backup node is 100 percent reserved

  • Rolling Upgrade, with zero downtime

Machine resources are not fully utilized. 

A small service provider with plans to expand in the future 

Symmetric 

  • Better use of system resources

  • Higher availability

Resource contention on the backup node.  

HA requires fully redundant disks. 

A small corporate deployment that can accept performance penalties in the event of a single server failure 

N+1 

  • Load distribution

  • Easy expansion

Management and configuration complexity. 

A large service provider who requires distribution with no resource constraints 

6.1.5 System Down Time Calculations for High Availability in Your Calendar Server 6.3 Deployment

The following table illustrates the probability that on any given day the calendar service will be unavailable due to system failure. These calculations assume that on average, each server goes down for one day every three months due to either a system crash or server hang, and that each storage device goes down one day every 12 months. These calculations also ignore the small probability of both nodes being down simultaneously.

Table 6–2 System Down Time Calculations

Model 

Server Down Time Probability 

Single server (no high availability) 

Pr(down) = (4 days of system down + 1 day of storage down)/365 = 1.37% 

Asymmetric 

Pr(down) = (0 days of system down + 1 day of storage down)/365 = 0.27% 

Symmetric 

Pr(down) = (0 days of system down + 0 days of storage down)/365 = (near 0) 

N + 1 Asymmetric 

Pr(down) = (5 hours of system down + 1 day of storage down)/(365xN) = 0.27%/N 

6.2 Prerequisites for an HA Environment for Your Calendar Server Version 6.3 Deployment

This sections lists the prerequisites for installing Calendar Server in an HA environment.

The following prerequisites apply:

6.2.1 About HAStoragePlus for a Calendar Server 6.3 HA Deployment

Use the HAStoragePlus resource type to make locally mounted file systems highly available within a Sun Cluster environment. Any file system resident on a Sun Cluster global device group can be used with HAStoragePlus. An HAStoragePlus file system is available on only one cluster node at any given point of time. These locally mounted file systems can only be used in failover mode and in failover resource groups. HAStoragePlus offers Failover File System (FFS), in addition to supporting the older Global File System (GFS), or Cluster File System (CFS).

HAStoragePlus has a number of benefits over its predecessor, HAStorage:


Note –

Use HAStoragePlus resources in a data service resource group with Sun Cluster 3.0 Release May 2002 and later.

For more information on HAStoragePlus, see Sun Cluster Data Services Planning and Administration Guide for Solaris OS.


6.3 High-Level Task List for an Asymmetric High Availability Deployment with Calendar Server 6.3 Software

The following is a list of the tasks necessary to install and configure Calendar Server for Asymmetric High Availability:

  1. Prepare the nodes.

    1. Install the Solaris Operating System software on all nodes of the cluster.

    2. Install Sun Cluster software on all nodes of the cluster.

    3. Install the Calendar Server HA Agents package, SUNWscics, on all nodes of the cluster using the Java Enterprise System installer

    4. Create a file system on the shared disk.

    5. Install Calendar Server on the Primary and Secondary nodes of the cluster, using the Communications Suite 5 installer.

  2. Run the Directory Preparation Script, comm_dssetup.pl on the machine where the Directory Server LDAP directory resides.

  3. Installing and configuring the first (primary) node.

    1. Using the Sun Cluster command-line interface, set up HA on the primary node.

    2. Run the Calendar Server configuration program, csconfigurator.sh, on the primary node.

    3. Using the Sun Cluster command-line interface, switch to the secondary node.

  4. Create a symbolic link from the Calendar Server config directory on the primary node to the shared disk config directory.

  5. Install and configure the second (secondary) node.

    1. Run the Calendar Server configuration program on the secondary node by reusing the state file created when you configured the primary node.

    2. Edit the Configuration File, ics.conf.

    3. Using the Sun Cluster command-line interface, configure and enable a resource group for Calendar Server.

    4. Using the Sun Cluster command-line interface to test the successful creation of the resource group, perform a fail over to the primary node.

For step-by-step instructions, see 6.6 Installing and Configuring Calendar Server 6.3 Software in an Asymmetric High Availability Environment.

6.4 High-Level Task List for a Symmetric High Availability Deployment with Calendar Server 6.3 Software

The following is a list of the tasks necessary to install and configure Calendar Server for Symmetric High Availability:

  1. Prepare the nodes.

    1. Install the Solaris Operating System software on all nodes of the cluster.

    2. Install Sun Cluster software on all nodes of the cluster.

    3. Create six file systems, either Cluster File Systems (Global File systems) or Fail Over File Systems (Local File systems).

    4. Create the necessary directories.

    5. Install the Calendar Server HA Agents package, SUNWscics, on all nodes of the cluster using the Java Enterprise System installer

  2. Install and Configure the first node.

    1. Using the Communications Suite 5 installer, install Calendar Server on the first node of the cluster.

    2. Run the Directory Preparation Script, comm_dssetup.pl, on the machine where the Directory Server LDAP database resides.


      Note –

      If the instances of Calendar Server on the two nodes share the same LDAP server, it is not necessary to repeat this step after installing Calendar Server software on the second node.


    3. Using the Sun Cluster command-line interface, configure HA on the first node.

    4. Run the Calendar Server configuration program, csconfigurator.sh, on the first node.

    5. Using the Sun Cluster command-line interface, fail over to the second node.

    6. Edit the Configuration File, ics.conf, on the first node.

    7. Using the Sun Cluster command-line interface, configure and enable a resource group for Calendar Server on the first node.

    8. Using the Sun Cluster command-line interface, create and enable a resource group for the first node.

    9. Using the Sun Cluster command-line interface to test the successful creation of the resource group, perform a fail over to the first node.

  3. Install and configure the second node.

    1. Using the Communications Suite 5 installer, install Calendar Server on the second node of the cluster.

    2. Using the Sun Cluster command-line interface, configure HA on the second node.

    3. Run the Calendar Server configuration program, csconfigurator.sh, on the second node by reusing the state file created when you configured the first node.

    4. Using the Sun Cluster command-line interface, fail over to the first node.

    5. Edit the Configuration File, ics.conf, on the second node.

    6. Using the Sun Cluster command-line interface, create and enable a resource group for Calendar Server on the second node.

    7. Using the Sun Cluster command-line interface to test the successful creation of the resource group, perform a fail over to the second node.

For step-by-step instructions, see 6.7 Configuring a Symmetric High Availability Calendar Server System.

6.5 Naming Conventions for All Examples in this Deployment Example for Configuring High Availability in Calendar Server Version 6.3


Tip –

Print out this section and record the values you use as you go through the HA installation and configuration process.


This section contains four tables showing the variable names used in all examples:

Table 6–3 Directory Name Variables Used in Asymmetric Examples

Example Name 

Directory 

Description 

install-root

/opt

The directory in which Calendar Server is installed.  

cal-svr-base

/opt/SUNWics5/cal

The directory in which all Calendar Server files are located.  

var-cal-dir

/var/opt/SUNWics5

The /var directory.

share-disk-dir

/cal

A global directory; that is, a directory shared between nodes in an asymmetric high availability system. 

Table 6–4 Directory Name Variables Used in Symmetric Examples

Example Name 

Directory 

Description 

install-rootCS1

install-rootCS2

/opt/Node1

/opt/Node2

The directory in which an instance of Calendar Server is installed. 

cal-svr-baseCS1

cal-svr-baseCS2

/opt/Node1/SUNWics5/cal

/opt/Node2/SUNWics5/cal

The directory in which all Calendar Server files are located for the node.  

var-cal-dirCS1

var-cal-dirCS2

/var/opt/Node1/SUNWics5

/var/opt/Node2/SUNWics5

The /var directories for each node.

share-disk-dirCS1

share-disk-dirCS2

/cal/Node1

/cal/Node2

The global (shared) directories each instance of Calendar Server shares with its fail over node. This is used in a symmetric high availability system. 

Table 6–5 Resource Name Variables for Asymmetric Examples

Variable Name 

Description 

CAL-RG

A calendar resource group. 

LOG-HOST-RS

A logical hostname resource. 

LOG-HOST-RS-Domain.com

The fully qualified logical hostname resource. 

CAL-HASP-RS

An HAStoragePlus resource. 

CAL-SVR-RS

A Calendar Server resource group. 

Table 6–6 Resource Name Variables for Symmetric Examples

Variable Name 

Description 

CAL-CS1-RG

A calendar resource group for the first instance of Calendar Server. 

CAL-CS2-RG

A calendar resource group for the second instance of Calendar Server. 

LOG-HOST-CS1-RS

A logical hostname resource for the first instance of Calendar Server. 

LOG-HOST-CS1-RS-Domain.com

The fully qualified logical hostname resource for the first instance of Calendar Server. 

LOG-HOST-CS2-RS

A logical hostname resource for the second instance of Calendar Server. 

LOG-HOST-CS2-RS-Domain.com

The fully qualified logical hostname resource for the second instance of Calendar Server. 

CAL-HASP-CS1-RS

An HAStoragePlus resource for the first instance of Calendar Server. 

CAL-HASP-CS2-RS

An HAStoragePlus resource for the second instance of Calendar Server. 

CAL-SVR-CS1-RS

A Calendar Server resource group for the first instance of Calendar Server. 

CAL-SVR-CS2-RS

A Calendar Server resource group for the second instance of Calendar Server. 

Table 6–7 Variable Name for IP Address in Asymmetric Examples

Logical IP Address 

Description 

IPAddress

The IP Address of the port on which the chsttpd daemon will listen. It should be in the standard IP format, for example: "123.45.67.890"

Table 6–8 Variable Name for IP Address in Symmetric Examples

Logical IP Address 

Description 

IPAddressCS1

The IP Address of the port on which the chsttpd daemon for the first instance of Calendar Server will listen. It should be in the standard IP format, for example: "123.45.67.890"

IPAddressCS2

The IP Address of the port on which the chsttpd daemon for the second instance of Calendar Server will listen. It should be in the standard IP format, for example: "123.45.67.890"

6.6 Installing and Configuring Calendar Server 6.3 Software in an Asymmetric High Availability Environment

This section contains instructions for configuring an asymmetric high availability Calendar Server cluster.

This sections contains the following topics:

6.6.1 Creating the File Systems for Your Calendar Server 6.3 HA Deployment

Create a file system on the shared disk. The /etc/vfstab should be identical on all the nodes of the cluster.

For CFS, it should look similar to the following example.

## Cluster File System/Global File System ##
/dev/md/penguin/dsk/d400 /dev/md/penguin/rdsk/d400 /cal ufs 2 yes global,logging

For example, for FFS:

## Fail Over File System/Local File System ##
/dev/md/penguin/dsk/d400 /dev/md/penguin/rdsk/d400 /cal ufs 2 no logging

Note –

The fields in these commands are separated by tabs, not just spaces.


6.6.2 Creating the Calendar Directory on All Shared Disks of the Cluster in Your Calendar Server 6.3 HA Deployment

For all nodes of the cluster, create a directory, /Cal, on the shared disk where configuration and data is held. For example, do the following command for every shared disk:

mkdir -P /Cal

6.6.3 Installing and Configuring High Availability for Calendar Server 6.3 Software

This section contains instructions for the tasks involved in installing and configuring high availability for Calendar Server.

Perform each of the following tasks in turn to complete the configuration:

ProcedureTo Prepare Each Node of the Cluster

  1. Install Calendar Server on the Primary and Secondary nodes of the cluster, using the Communications Suite 5 installer.


    Note –

    Be sure to specify the same installation root on all nodes.


    1. At the Specify Installation Directories panel, answer with the installation root for both nodes.

      This will install the Calendar Server binaries in the following directory:/install-root/SUNWics5/cal. This directory is called the Calendar Server base (cal-svr-base).

    2. Choose the Configure Later option.

    3. After the installation is complete, verify that the files are installed.

      # pwd
      /cal-svr-base
      
      # ls -rlt
      
      total 16
      drwxr-xr-x   4 root     bin          512 Dec 14 12:52 share
      drwxr-xr-x   3 root     bin          512 Dec 14 12:52 tools
      drwxr-xr-x   4 root     bin         2048 Dec 14 12:52 lib
      drwxr-xr-x   2 root     bin         1024 Dec 14 12:52 sbin
      drwxr-xr-x   8 root     bin          512 Dec 14 12:52 csapi
      drwxr-xr-x  11 root     bin         2048 Dec 14 12:52 html
  2. Run the Directory Preparation Script (comm_dssetup.pl) against your existing Directory Server LDAP.

    This prepares your Directory Server by setting up new LDAP schema, index, and configuration data.

    For instructions and further information about running comm_dssetup.pl, see Chapter 8, Directory Preparation Tool (comm_dssetup.pl), in Sun Java Communications Suite 5 Installation Guide.

ProcedureTo Set Up the Primary Node

Use the Sun Cluster command line interface as indicated to set up HA on the first node.


Note –

Refer to 6.5 Naming Conventions for All Examples in this Deployment Example for Configuring High Availability in Calendar Server Version 6.3 as a key for directory names and Sun Cluster resource names in the examples.


  1. Register the Calendar Server and HAStoragePlus resource

    ./scrgadm -a -t SUNW.HAStoragePlus
    ./scrgadm -a -t SUNW.scics
  2. Create a failover Calendar Server resource group.

    For example, the following instruction creates the calendar resource group CAL-RG with the primary node as Node1 and the secondary, or failover, node as Node2.

    ./scrgadm -a -g CAL-RG -h node1,node2
  3. Create a logical hostname resource in the Calendar Server resource group and bring the resource group online.

    For example, the following instructions create the logical hostname resource LOG-HOST-RS, and then brings the resource group CAL-RG online.

    ./scrgadm -a -L -g CAL-RG -l LOG-HOST-RS
    ./scrgadm -c -j LOG-HOST-RS -y    \
          R_description="LogicalHostname resource for LOG-HOST-RS"
    ./scswitch -Z -g CAL-RG
  4. Create and enable the HAStoragePlus resource.

    For example, the following instructions create and enable the HAStoragePlus resource CAL-HASP-RS.

    scrgadm -a -j CAL-HASP-RS -g CAL-RG -t 
         SUNW.HAStoragePlus:4 -x FilesystemMountPoints=/cal
    scrgadm -c -j CAL-HASP-RS -y 
         R_description="Failover data service resource for SUNW.HAStoragePlus:4"
    scswitch -e -j CAL-HASP-RS

ProcedureTo Run the Configuration Utility (csconfigurator.sh) on the Primary Node

  1. Run the configuration program.

    For example, from the /cal-svr-base/sbin directory:

    # pwd
         /cal-svr-base/sbin
    
    # ./csconfigurator.sh

    For further information about running the configuration script, see Chapter 2, Initial Runtime Configuration Program for Calendar Server 6.3 software (csconfigurator.sh)also in this guide.

  2. At the Run Time Configuration panel, deselect both Calendar Server startup options.

  3. At the Directories panel, configure all directories on a shared disk. Use the following locations:

    Config Directory

    /share-disk-dir/config

    Database Directory

    /share-disk-dir/csdb

    Attachment Store Directory

    /share-disk-dir/store

    Logs Directory

    /share-disk-dir/logs

    Temporary Files Directory

    /share-disk-dir/tmp

    Once you have finished specifying the directories, choose Create Directory.

  4. At the Archive and Hot Backup panel, specify the following choices:

    Archive Directory

    /share-disk-dir/csdb/archive

    Hot Backup Directory

    /share-disk-dir/csdb/hotbackup

    When you have finished specifying the directories, choose the Create Directory option.

  5. Verify that the configuration is successful.

    Look at the end of the configuration output to make sure it says: “All Tasks Passed.” The following example shows the last part of the configuration output.

    ...
    All Tasks Passed. Please check install log 
    /var/sadm/install/logs/Sun_Java_System_Calendar_Server_install.B12141351
     for further details.

    For a larger sample of the output, see 6.11 Example Output from the Calendar Configuration Program (Condensed)

  6. Click Next to finish configuration.

ProcedureTo Configure the Secondary Node

  1. Switch to the secondary node.

    Using the Sun Cluster command line interface, switch to the secondary node. For example, the following command switches the resource group to the secondary (failover) node, Node2:

    scswitch -z -g CAL-RG -h Node2
  2. Create a symbolic link from the Calendar Server config directory to the config directory of the Shared File System.

    For example, perform the following commands:

    # pwd
    /cal-svr-base
    
    # ln -s /share-disk-dir/config .  

    Note –

    Do not forget the dot (.) at the end of the ln command.


  3. Configure Calendar Server on the secondary node using the state file from the primary node configuration.

    Share the configuration of the primary node by running the state file created when you ran the configuration program.

    For example, run the following command:

    # /cal-svr-base/sbin/csconfigurator.sh -nodisplay -noconsole -novalidate

    Check that all the tasks passed as with the first time you ran the configuration program.

  4. Edit the Configuration File (ics.conf)

    Edit the ics.conf file by adding the following parameters to the end of the file. The logical hostname of the calendar resource is LOG-HOST-RS.


    Note –

    Back up your ics.conf file before performing this step.


    ! The following are the changes for making Calendar Server
    ! Highly Available
    !
    local.server.ha.enabled="yes"
    local.server.ha.agent="SUNWscics"
    service.http.listenaddr="IPAddress"
    local.hostname="LOG-HOST-RS"
    local.servername="LOG-HOST-RS"
    service.ens.host="LOG-HOST-RS"
    service.http.calendarhostname="LOG-HOST-RS-Domain.com"
    local.autorestart="yes"
    service.listenaddr="IPAddress"
  5. Create the Calendar Server resource group and enable it.

    For this example, the resource group name is CAL-SVR-RS. You will also be required to supply the logical host resource name and the HAStoragePlus resource name.

    ./scrgadm -a -j CAL-SVR-RS -g CAL-RG 
         -t SUNW.scics -x ICS_serverroot=/cal-svr-base 
         -y Resource_dependencies=CAL-HASP-RS,LOG-HOST-RS
    
    ./scrgadm -e -j CAL-SVR-RS
  6. Test the successful creation of the calendar resource group by performing a fail over.

    ./ scswitch -z -g CAL-RG -h Node1

    When you have finished this step, you have completed the creation and configuration of the asymmetric high availability system for Calendar Server. The section that follows explains how to set up logging on Sun Cluster for debug purposes.

    You have now finished the installation and configuration of an asymmetric Calendar Server HA system.

6.7 Configuring a Symmetric High Availability Calendar Server System

This section contains instructions for configuring a symmetric high availability Calendar Server system

To configure a symmetric high availability Calendar Server system, follow the instructions in the following sections:

6.7.1 Initial Tasks

There are two preparatory tasks that must be completed before installing Calendar Server on the nodes.

The preparatory tasks are as follows:


Note –

In various places in the examples, you need to provide the installation directory (cal-svr-base) for each node. For a symmetric HA system, the cal-svr-base is different than the asymmetric HA system. For symmetric HA systems, cal-svr-base has the following format: /opt/node/SUNWics5/cal, where /opt/node is the name of the root directory in which Calendar Server is installed (install-root).

For the purposes of the examples, and to differentiate the installation directories of the two Calendar Server instances, they are designated as cal-svr-baseCS1 and cal-svr-baseCS1.

To differentiate the installation roots for the two Calendar Server instances in this example, they are designated as install-rootCS1 and install-rootCS2:


ProcedureCreating the File Systems

  1. Create six file systems, using either Cluster File Systems (Global File systems) or Fail Over File Systems (Local File systems).

    This example is for Global File Systems. The contents of the /etc/vfstab file should look like the following: (Note that the fields are all tab separated.)

    # Cluster File System/Global File System ##
    /dev/md/penguin/dsk/d500  /dev/md/penguin/rdsk/d500  
        /cal-svr-baseCS1  ufs  2  yes  logging,global
    /dev/md/penguin/dsk/d400  /dev/md/penguin/rdsk/d400  
        /share-disk-dirCS1  ufs  2  yes  logging,global
    /dev/md/polarbear/dsk/d200  /dev/md/polarbear/rdsk/d200  
        /cal-svr-baseCS2  ufs  2  yes  logging,global
    /dev/md/polarbear/dsk/d300  /dev/md/polarbear/rdsk/d300
        /share-disk-dirCS2  ufs  2  yes logging,global
    /dev/md/polarbear/dsk/d600  /dev/md/polarbear/rdsk/d300 
        /var-cal-dirCS1  ufs  2   yes  logging,global
    /dev/md/polarbear/dsk/d700  /dev/md/polarbear/rdsk/d300  
        /var-cal-dirCS2  ufs   2   yes  logging,global

    This example is for the Failover File Systems. The contents of the /etc/vfstab file should look like the following: (Note that the fields are all tab separated.)

    # Failover File System/Local File System ##
    /dev/md/penguin/dsk/d500  /dev/md/penguin/rdsk/d500  
        /cal-svr-baseCS1  ufs  2  yes  logging
    /dev/md/penguin/dsk/d400  /dev/md/penguin/rdsk/d400  
        /share-disk-dirCS1  ufs  2  yes  logging
    /dev/md/polarbear/dsk/d200  /dev/md/polarbear/rdsk/d200 
       /cal-svr-baseCS2  ufs  2  yes  logging
    /dev/md/polarbear/dsk/d300  /dev/md/polarbear/rdsk/d300 
        /share-disk-dirCS2  ufs  2  yes  logging
    /dev/md/polarbear/dsk/d600  /dev/md/polarbear/rdsk/d300 
        /var-cal-dirCS1  ufs  2   yes  logging
    /dev/md/polarbear/dsk/d700  /dev/md/polarbear/rdsk/d300
       /var-cal-dirCS2  ufs  2   yes  logging
  2. Create the following required directories on all nodes of the cluster.

    # mkdir -p /install-rootCS1 share-disk-dirCS1 
         install-rootCS2 share-disk-dirCS2 var-cal-dirCS1 
         var-cal-dirCS2

6.7.1.1 Installing the Calendar Server HA Package

Install the Calendar Server HA package, SUNWscics, on all nodes of the cluster.

This must be done from the Java Enterprise System installer.

For more information about the Java Enterprise System installer, refer to the Sun Java Enterprise System 5 Installation and Configuration Guide.

6.7.2 Installing and Configuring the First Instance of Calendar Server

Follow the instructions in this section to install and configure the first instance of Calendar Server. This section covers the following topics:

ProcedureTo Install Calendar Server

  1. Verify the files are mounted.

    On the primary node (Node1), enter the following command:

    df -k

    The following is an example of the output you should see:

    /dev/md/penguin/dsk/d500     35020572   
         34738 34635629   1%   /install-rootCS1
    /dev/md/penguin/dsk/d400     35020572   
         34738 34635629   1%   /share-disk-dirCS1
    /dev/md/polarbear/dsk/d300   35020572   
         34738 34635629   1%   /share-disk-dirCS2
    /dev/md/polarbear/dsk/d200   35020572   
         34738 34635629   1%   /install-rootCS2
    /dev/md/polarbear/dsk/d600   35020572   
         34738 34635629   1%   /var-cal-dirCS1
    /dev/md/polarbear/dsk/d700   35020572   
         34738 34635629   1%   /var-cal-dirCS2
  2. Using the Sun Java Systems Communications Suite installer, install Calendar Server on the Primary Node.

    1. At the Specify Installation Directories panel, specify the installation root (install-rootCS1):

      For example, if your Primary node is named red and the root directory is dawn, the installation root would be /dawn/red. This is the directory where you are installing Calendar Server on the first node.

    2. Choose Configure Later.

  3. Run the Directory Preparation Tool script on the machine with the Directory Server.

ProcedureTo Configure Sun Cluster on the First Node

Using the Sun Cluster command-line interface, configure Sun Cluster on the first node by performing the following steps:

  1. Register the following resource types:

    ./scrgadm -a -t SUNW.HAStoragePlus
    ./scrgadm -a -t SUNW.scics
  2. Create a fail over resource group.

    In the following example, the resource group is CAL-CS1-RG, and the two nodes are named Node1 as the primary node and Node2 as the fail over node.

    ./scrgadm -a -g CAL-CS1-RG -h Node1,Node2
  3. Create a logical hostname resource for this node.

    The calendar client listens on this logical hostname. The example that follows uses LOG-HOST-CS1-RS in the place where you will substitute in the actual hostname.

    ./scrgadm -a -L -g CAL-RG -l LOG-HOST-CS1-RS
    ./scrgadm -c -j LOG-HOST-CS1-RS -y R_description=
         "LogicalHostname resource for LOG-HOST-CS1-RS"
  4. Bring the resource group online.

    scswitch -Z -g CAL-CS1-RG
  5. Create an HAStoragePlus resource and add it to the fail over resource group.

    In this example, the resource is called CAL-HASP-CS1-RS. You will substitute you own resource name. Note that the lines are cut and show as two lines in the example for display purposes in this document.

    ./scrgadm -a -j CAL-HASP-CS1-RS -g CAL-CS1-RG -t 
         SUNW.HAStoragePlus:4 -x FilesystemMountPoints=/install-rootCS1,
         /share-disk-dirCS1,/cal-svr-baseCS1
    ./scrgadm -c -j CAL-HASP-CS1-RS -y R_description="Failover data 
         service resource for SUNW.HAStoragePlus:4"
  6. Enable the HAStoragePlus resource.

    ./scswitch -e -j CAL-HASP-CS1-RS

ProcedureTo Configure the First Instance of Calendar Server

  1. Run the configuration program on the primary node.

    # cd /cal-svr-baseCS1/sbin/
    
    # ./csconfigurator.sh

    For further information about running the configuration script, see the Sun Java System Calendar Server 6.3 Administration Guide.

  2. On the Runtime Configuration panel, deselect both of the Calendar Server start up options.

  3. On the Directories to Store Configuration and Data Files panel, provide the shared disk directories as shown in the following list:

    Config Directory

    /share-disk-dirCS1/config

    Database Directory

    /share-disk-dirCS1/csdb

    Attachment Store Directory

    /share-disk-dirCS1/store

    Logs Directory

    /share-disk-dirCS1/logs

    Temporary Files Directory

    /share-disk-dirCS1/tmp

    When you have finished specifying the directories, choose Create Directory.

  4. On the Archive and Hot Backup panel, provide the shared disk directory names as shown in the following list:

    Archive Directory

    /share-disk-dirCS1/csdb/archive

    Hot Backup Directory

    /share-disk-dirCS1/csdb/hotbackup

    After specifying these directories, choose Create Directory.

  5. Verify that the configuration was successful.

    The configuration program will display a series of messages. If they all start with PASSED, which means it was successful. For an example of the output you might see, check the example at: 6.11 Example Output from the Calendar Configuration Program (Condensed).

ProcedureTo Perform the Final Configuration Steps for the First Instance

  1. Using the Sun Cluster command-line interface, perform a fail over to the second node.

    For example:

    # /usr/cluster/bin/scswitch -z -g CAL-CS1-RG -h Node2
  2. Edit the configuration file, ics.conf, by adding the parameters shown in the example that follows.


    Note –

    Back up the ics.conf file before starting this step.


    ! The following changes were made to configure Calendar Server
    ! Highly Available
    !
    local.server.ha.enabled="yes"
    local.server.ha.agent="SUNWscics"
    service.http.listenaddr="IPAddressCS1"
    local.hostname="LOG-HOST-CS1-RS"
    local.servername="LOG-HOST-CS1-RS"
    service.ens.host="LOG-HOST-CS1-RS"
    service.http.calendarhostname="LOG-HOST-CS1-RS-Domain.com"
    local.autorestart="yes"
    service.listenaddr = "IPAddressCS1"

    Note –

    The expected value for service.http.calendarhostname is a fully qualified hostname.


  3. Using the Sun Cluster command-line interface, create the Calendar Server resource group.

    Create a calendar resource group and enable it.

    For example:

    ./scrgadm -a -j CAL-SVR-CS1-RS -g CAL-CS1-RG
          -t SUNW.scics  -x ICS_serverroot=/cal-svr-baseCS1
          -y Resource_dependencies=CAL-HASP-CS1-RS,LOG-HOST-CS1-RS
    
    ./scrgadm -e -j CAL-SVR-CS1-RS
  4. Using the Sun Cluster command-line interface to test the successful creation of the Calendar Server resource group, perform a fail over to the first node, which is the Primary node.

    For example:

    ./scswitch -z -g CAL-CS1-RG -h Node1

6.7.3 Installing and Configuring the Second Instance of Calendar Server

The primary node for the second Calendar Server instance is the second node (Node2).

ProcedureTo Install Calendar Server on the Second Node

  1. Verify the files are mounted.

    On the primary node (Node2), enter the following command:

    df -k

    The following is an example of the output you should see:

    /dev/md/penguin/dsk/d500     35020572   
         34738 34635629   1%   /install-rootCS1
    /dev/md/penguin/dsk/d400     35020572   
         34738 34635629   1%   /share-disk-dirCS1
    /dev/md/polarbear/dsk/d300   35020572   
         34738 34635629   1%   /share-disk-dirCS2
    /dev/md/polarbear/dsk/d200   35020572   
         34738 34635629   1%   /install-rootCS2
    /dev/md/polarbear/dsk/d600   35020572   
         34738 34635629   1%   /var-cal-dirCS1
    /dev/md/polarbear/dsk/d700   35020572   
         34738 34635629   1%   /var-cal-dirCS2
  2. Using the Sun Java Systems Communications Suite installer, install Calendar Server on the new Primary Node (second node).

    1. At the Specify Installation Directories panel, specify the installation root for the second node (/install-rootNode2):

      For example, if your Node 2 machine is named blue and your root directory is ocean, your installation directory would be /ocean/blue.

    2. Select the Configure Later option.

ProcedureTo Configure Sun Cluster for the Second Instance

Using the Sun Cluster command-line interface, configure the second instance of Calendar Server as described in the following steps:

  1. Create a fail over resource group.

    In the following example, the resource group is CAL-CS2-RG, and the two nodes are named Node2 as the primary node and Node1 as the fail over node.

    ./scrgadm -a -g CAL-CS2-RG -h Node2,Node1
  2. Create a logical hostname resource.

    The calendar client listens on this logical hostname. The example that follows uses LOG-HOST-CS2-RS in the place where you will substitute in the actual hostname.

    ./scrgadm -a -L -g CAL-CS2-RG -l LOG-HOST-CS2-RS
    ./scrgadm -c -j LOG-HOST-CS2-RS -y R_description="LogicalHostname 
         resource for LOG-HOST-CS2-RS"
  3. Bring the resource group online.

    scswitch -Z -g CAL-CS2-RG
  4. Create an HAStoragePlus resource and add it to the fail over resource group.

    In this example, the resource is called CAL-SVR-CS2-RS. You will substitute you own resource name.

    ./scrgadm -a -j CAL-SVR-CS2-RS -g CAL-CS2-RG -t 
         SUNW.HAStoragePlus:4 -x FilesystemMountPoints=/install-rootCS2,
         /share-disk-dirCS2,/var-cal-dirCS2
    ./scrgadm -c -j CAL-HASP-CS2-RS -y R_description="Failover data 
         service resource for SUNW.HAStoragePlus:4"
  5. Enable the HAStoragePlus resource.

    ./scswitch -e -j CAL-HASP-CS2-RS

ProcedureTo Configure the Second Instance of Calendar Server

  1. Run the configuration program again on the secondary node.

    # cd /cal-svr-baseCS2/sbin/
    
    # ./csconfigurator.sh

    For further information about running the configuration script, see the Sun Java System Calendar Server 6.3 Administration Guide.

  2. On the Runtime Configuration panel, deselect both of the Calendar Server start up options.

  3. On the Directories to Store Configuration and Data Files panel, provide the proper directories as shown in the following list:

    Config Directory

    share-disk-dirCS2/config

    Database Directory

    /share-disk-dirCS2/csdb

    Attachment Store Directory

    /share-disk-dirCS2/store

    Logs Directory

    /share-disk-dirCS2/logs

    Temporary Files Directory

    /share-disk-dirCS2/tmp

    When you have finished specifying the directories, choose Create Directory.

  4. On the Archive and Hot Backup panel, provide the appropriate directory names as shown in the following list:

    Archive Directory

    /share-disk-dirCS2/csdb/archive

    Hot Backup Directory

    /share-disk-dirCS2/csdb/hotbackup

    After specifying these directories, choose Create Directory.

  5. Verify that the configuration was successful.

    The configuration program will display a series of messages. If they all start with PASSED, which means it was successful. For an example of the output you might see, check the example at: 6.11 Example Output from the Calendar Configuration Program (Condensed).

ProcedureTo Perform the Final Configuration Steps for the Second Instance

  1. Using the Sun Cluster command-line interface, perform a fail over to the first node.

    For example:

    # /usr/cluster/bin/scswitch -z -g CAL-CS2-RG -h Node1
  2. Edit the configuration file, ics.confby adding the parameters shown in the example that follows.


    Note –

    The values shown are examples only. You must substitute your own information for the values in the example.

    Back up the ics.conf file before starting this step.


    ! The following changes were made to configure Calendar Server
    ! Highly Available
    !
    local.server.ha.enabled="yes"
    local.server.ha.agent="SUNWscics"
    service.http.listenaddr="IPAddressCS2"
    local.hostname="LOG-HOST-CS2-RS"
    local.servername="LOG-HOST-CS2-RS"
    service.ens.host="LOG-HOST-CS2-RS"
    service.http.calendarhostname="LOG-HOST-CS2-RS-Domain.com"
    local.autorestart="yes"
    service.listenaddr = "IPAddressCS2"

    Note –

    The value for service.http.calendarhostname must be a fully qualified hostname.


  3. Using the Sun Cluster command-line interface, create a Calendar Server resource group.

    Create a Calendar Server resource group and enable it.

    For example:

    ./scrgadm -a -j CAL-SVR-CS2-RS -g CAL-CS2-RG
          -t SUNW.scics -x ICS_serverroot=/cal-svr-baseCS2
          -y Resource_dependencies=CAL-HASP-CS2-RS,LOG-HOST-CS2-RS
    
    ./scrgadm -e -j CAL-SVR-CS2-RS
  4. Using the Sun Cluster command-line interface to test the successful creation of the calendar resource group, perform a fail over to the second node, which is primary node for this Calendar Server instance.

    For example:

    ./scswitch -z -g CAL-CS2-RG -h Node2

    Your have now finished installing and configuring a symmetric HA Calendar Server.

6.8 Starting and Stopping Calendar Server HA Service

Use the following commands to start, fail over, disable, remove, and restart the Calendar Server HA service:

To enable and start the Calendar Server HA service:
# scswitch -e -j CAL-SVR-RS
To Fail Over the Calendar Server HA service:
# scswitch -z -g CAL-RG -h Node2
To disable the Calendar Server HA Service:
# scswitch -n -j CAL-SVR-RS
To remove the Calendar Server resource:
# scrgadm -r -j CAL-SVR-RS
To restart the Calendar Server HA service:
# scrgadm -R -j CAL-SVR-RS

6.9 Removing HA from Your Calendar Server Configuration

This section describes how to undo the HA configuration for Sun Cluster. This section assumes the simple asymmetric example configuration described in this chapter. You must adapt this scenario to fit your own installation.

ProcedureTo Remove HA Components

  1. Become a superuser.


    Note –

    All of the following Sun Cluster commands require that you be running as a superuser.


  2. Bring the resource group offline. Use the following command to shut down all of the resources in the resource group (For example, the Calendar Server and the HA logical host name).


    # scswitch -F -g CAL-RG
  3. Disable the individual resources.

  4. Remove the resources one-by-one from the resource group using the commands:


    # scswitch -n -j CAL-SVR-RS
    # scswitch -n -j CAL-HASP-RS
    # scswitch -n -j LOG-HOST-RS
  5. Remove the resource group itself using the command:


    # scrgadm -r -g CAL-RG
  6. Remove the resource types (optional). If you want to remove the resource types from the cluster, use the command:


    # scrgadm -r -t SUNW.scics
    # scrgadm -r -t SUNW.HAStorage

6.10 Debugging on Sun Cluster

The Calendar Server Sun Cluster agents use two different API's to log messages:

ProcedureTo Enable Logging

The following task must be done on each HA node since the /var/adm file can't be shared. This file is on the root partition of the individual nodes.

  1. Create a logging directory for Calendar Server agents.

    mkdir -p /var/cluster/rgm/rt/SUNW.scics
  2. Set the debug level to 9.

    echo 9 >/var/cluster/rgm/rt/SUNW.scics/loglevel

    The following example shows log messages you might see in the directory. Note that, in the last line, ICS-serverroot is asking for the cal-svr-base, or installation directory.

    Dec 11 18:24:46 mars SC[SUNW.scics,CAL-RG,cal-rs,ics_svc_start]: 
         [ID 831728 daemon.debug] Groupname icsgroup exists.
    Dec 11 18:24:46 mars SC[SUNW.scics,CAL-RG,LOG-HOST-RS,ics_svc_start]: 
         [ID 383726 daemon.debug] Username icsuser icsgroup
    Dec 11 18:24:46 mars SC[SUNW.scics,CAL-RG,LOG-HOST-RS,ics_svc_start]: 
         [ID 244341 daemon.debug] ICS_serverroot = /cal-svr-base
  3. Enable Sun Cluster Data Services Logging.

    Edit the syslog.conf file by adding the following line .

    daemon.debug /var/adm/clusterlog

    This will cause all the debug messages to be logged into the daemon.debug /var/adm/clusterlog file.

  4. Restart the syslogd daemon.

    pkill -HUP syslogd

    All syslog debug messages are prefixed with the following:

    SC[resourceTypeName, resourceGroupName, resourceName, methodName]

    The following example messages have been split and carried over to multiple lines for display purposes.

    Dec 11 15:55:52 Node1 SC
          [SUNW.scics,CAL-RG,CalendarResource,ics_svc_validate]:
          [ID 855581 daemon.error] Failed to get the configuration info
    Dec 11 18:24:46 Node1 SC
          [SUNW.scics,CAL-RG,LOG-HOST-RS,ics_svc_start]:
          [ID 833212 daemon.info] Attempting to start the data service under 
          process monitor facility.

6.11 Example Output from the Calendar Configuration Program (Condensed)

This section contains a partial listing of the output from the configuration program. Your output will be much longer. At the end, it should say: “All Tasks Passed.” Inspect the log files. The location of the files is given at the end of the printout.

/usr/jdk/entsys-j2se/bin/java -cp /opt/Node2/SUNWics5/cal/share/lib:
     /opt/Node2/SUNWics5/cal/share -Djava.library.path=
     /opt/Node2/SUNWics5/cal/lib configure -nodisplay -noconsole -novalidate
# ./csconfigurator.sh -nodisplay -noconsole -novalidate
/usr/jdk/entsys-j2se/bin/java -cp /opt/Node2/SUNWics5/cal/share/lib:
     /opt/Node2/SUNWics5/cal/share -Djava.library.path=
     /opt/Node2/SUNWics5/cal/lib configure -nodisplay -noconsole -novalidate
Java Accessibility Bridge for GNOME loaded.

Loading Default Properties...

Checking disk space...

Starting Task Sequence
===== Mon Dec 18 15:33:29 PST 2006 =====
Running /bin/rm -f /opt/Node2/SUNWics5/cal/config
/opt/Node2/SUNWics5/cal/data

===== Mon Dec 18 15:33:29 PST 2006 =====
Running /usr/sbin/groupadd icsgroup

===== Mon Dec 18 15:33:29 PST 2006 =====
Running /usr/sbin/useradd -g icsgroup -d / icsuser

===== Mon Dec 18 15:33:30 PST 2006 =====
Running /usr/sbin/usermod -G icsgroup icsuser

===== Mon Dec 18 15:33:30 PST 2006 =====
Running /bin/sh -c /usr/bin/crle


===== Mon Dec 18 15:33:32 PST 2006 =====
Running /bin/chown icsuser:icsgroup /etc/opt/Node2/SUNWics5/config/watcher.
cnf


...

Sequence Completed

PASSED: /bin/rm -f /opt/Node2/SUNWics5/cal/config
/opt/Node2/SUNWics5/cal/data : status = 0

PASSED: /usr/sbin/groupadd icsgroup : status = 9

PASSED: /usr/sbin/useradd -g icsgroup -d / icsuser : status = 9


...

All Tasks Passed. Please check install log
/var/sadm/install/logs/Sun_Java_System_Calendar_Server_install.B12181533 for
further details.

6.12 Related Documentation

For more instruction about Sun Cluster, there are many documents that can be found at docs. sun.com.

The following is a partial list of documentation titles:

Chapter 7 Configuring SSL

Secure Socket Layer (SSL) is a protocol for encrypting and decrypting data across a secure connection from a client to a server with SSL capabilities. The server is responsible for sending the client, a digital certificate and a public key for encryption. If the client trusts the server's certificate, an SSL connection can be established. All data passing from one side to the other will be encrypted. Only the client and the server will be able to decrypt the data.

Sun Java System servers support the authentication of users through examination of their digital certificates. Instead of presenting a password, the client presents the user's certificate when it establishes an SSL session with the server. If the certificate is validated, the user is authenticated. Calendar Server supports the SSL protocol to encrypt data between calendar client end users and Calendar Server. To support SSL, Calendar Server uses SSL libraries from Netscape Security Services (NSS) certutil tool, which are also used by Sun Java System Messaging Server. The NSS certutil tool is bundled in the sbin directory of the Calendar Server product.

You can configure Calendar Server in the ics.conf file to encrypt only the Calendar Server login and password or an entire calendar session.

This chapter covers the three tasks necessary to configure SSL and troubleshooting:


Note –

Calendar Server does not support client-based SSL authentication.


7.1 Configuring SSL for Calendar Server

This section contains instructions for configuring SSL for Calendar Server.

This section contains the following topics:

ProcedureTo Create a Certificate Database

A certificate is required by the gateway to send its public keys to the clients. The certificate contains the gateway's public key, the Distinguished Name associated with the gateway's certificate, the serial number or issue date of the certificate, and the expiration date of the certificate. A certificate is issued by a certification authority (CA), which verifies the identity of the gateway. CA is an authority trusted by one or more users to issue and manage X.509 Public Key Certificates and CARLs or Certification Revocation List (CRL)s. CA is the basic building block of the Public Key Infrastructure (PKI). On the other hand, PKI is a set of policies, processes, server platforms, software and workstations used for the purpose of administering certificates and public-private key pairs, including the ability to issue, maintain, and revoke public key certificates.

The CA inserts its name in every certificate and CRL it generates and digitally signs the certificate with its private key. Once you establish that they trust a CA (directly, or through a certification path), you can trust certificates issued by that CA. You can easily identify certificates issued by that CA by comparing its name. However, its public key can be used to ensure that the certificate is valid.

The CA performs four basic PKI functions:

Your server's certificate and key pair represent your server's identity. They are stored in a certificate database that can be either internal to the server or on an external, removable hardware card (smartcard). An SSL implementation for Calendar Server requires a certificate database. The certificate database must define a Certificate Authority (CA) and certificates for Calendar Server. This section contains conceptual and task information:

Before You Begin

Before you create the certificate database, familiarize yourself with the following:

  1. Log in as or become superuser (root).

  2. Specify the certificate database password in /etc/opt/SUNWics5/config/sslpassword.conf.

    For example:


    # echo "password file entry" 
          /etc/opt/SUNWics5/config/sslpassword.conf

    The format of password file entry in the sslpassword.conf file is as follows:

    Internal (Software) Token:password

    where password is your password.

    Note that the password entry in the sslpassword.conf file must use the format shown above, including the string, Internal (Software) Token:. However, the password entry used with the password file associated with the certutil -fpasswordfile command must use the following simple format:

    password.

  3. Create the certificate database directory. For example:


    # cd /var/opt/SUNWics5
     # mkdir alias
  4. Change to the bin directory and generate the certificate database (cert8.db) and key database (key3.db). For example:


    # cd /opt/SUNWics5/cal/bin
     # ./certutil -N -d /etc/opt/SUNWics5/config
                     -f /mypath/mypassworfile
    

    Note –

    For this and other times when you must run the certutil utility, follow the examples exactly, or consult the certutil help page to understand the syntax.

    For example, in this case, do not run the utility with the -N option without also specifying the -d /file information.


  5. Generate a default self-signed root Certificate Authority certificate. For example:


    # ./certutil -S -n SampleRootCA -x -t "CTu,CTu,CTu"
     -s "CN=My Sample Root CA, O=sesta.com" -m 25000
     -o /etc/opt/SUNWics5/config/SampleRootCA.crt
     -d /etc/opt/SUNWics5/config
     -f /mypath/mypassworfile -z
     /etc/passwd
  6. Generate a certificate for the host. For example:


    # ./certutil -S -n SampleSSLServerCert -c SampleRootCA 
     -t "u,u,u"
     -s "CN=hostname.sesta.com, O=sesta.com" -m 25001
     -o /etc/opt/SUNWics5/config/SampleSSLServer.crt
     -d /etc/opt/SUNWics5/config 
     -f /mypath/mypassworfile
     -z /etc/passwd

    where hostname.sesta.com is the server host name.

  7. Validate the certificates. For example:


    # ./certutil -V -u V -n SampleRootCA  
        -d /etc/opt/SUNWics5/config
     # ./certutil -V -u V -n SampleSSLServerCert 
       -d /etc/opt/SUNWics5/config
  8. List the certificates. For example:


    # ./certutil -L -d /etc/opt/SUNWics5/config
     # ./certutil -L -n SampleSSLServerCert 
       -d /etc/opt/SUNWics5/config
  9. Use modutil to list the available security modules (secmod.db). For example:


    # ./modutil -list -dbdir /etc/opt/SUNWics5/config
  10. Change the owner of the alias file to icsuser and icsgroup (or the user and group identity under which Calendar Server will run). For example:


    # find /etc/opt/SUNWics5/config -exec chown icsuser {};
     # find /etc/opt/SUNWics5/config -exec chgrp icsgroup {};

7.1.1 Self-signed Certificate

A self-signed certificate is signed with the gateway's own private key. Self-signed certificates are not secure, but they can be used to test applications that require certificates before a signed certificate is available for use. A self-signed certificate uses its own certificate request as a signature rather than the signature of a CA.

There are ten common fields in which six are mandatory and four are optional in creating a self-signed certificate through PKI. The serial number, certificate signature algorithm identifier, certificate issuer name, certificate validity period, public key, and the subject name are the mandatory fields. The optional fields are the version number, two unique identifiers, and the extension. These optional fields appear only in version 2 and 3 certificates.

The mandatory Validity field indicates the dates on which the certificate becomes valid and the date on which the certificate expires. The default value for expiration date provided in the NSS certutils is three months. However, the validity data in a certificate become unreliable before the expiration date arrives. The X.509 CRL mechanism provides a status update for the certificates they have issued and to take care about the certificate expiration dates. Also, CA enforces certificate expiration to one or two years.

When a certificate is expired or its validity date is over, it needs to be renewed. Renewal is an act or process of extending the validity of the data binding asserted by a public key certificate by issuing a new certificate. You can validate a certificate using the command:

-V -n certname -b validity-time -u certusage [-e] [-l] [-d certdir]

The following example shows how to use the command to validate a certificate:

certutil -V -n jsmith@netscape.com -b 9803201212Z -u SR -e -l -d certdir.

The Certificate Database Tool shows results similar to the following:

Certificate:'jsmith@netscape.com' is valid.

or

UID=jsmith, E=jsmith@netscape.com, CN=John Smith, O=Netscape Communications Corp., C=US : Expired certificate

or

UID=jsmith, E=jsmith@netscape.com, CN=John Smith, O=Netscape Communications Corp., C=US : Certificate not approved for this operation

ProcedureTo Request and Import a Certificate from a Root Certificate Authority

The following steps tell you how to generate a certificate request, submit it to the Public Key Infrastructure (PKI) Web site, and then import the certificate. These instruction assume you are placing the certificate database under the config directory.

Before You Begin

Both the certificate database and the password file must reside in the same directory. The default shown here is the config directory, but you can choose another directory, in which case, you must configure a different path parameter, as shown in the procedure that follows.

  1. Log in as or become superuser (root).

  2. Move to the bin directory:

    # cd /opt/SUNWics5/cal/bin

  3. Use certutil to generate a Certificate Request based on the Certificate Authority or Public Key Infrastructure (PKI) Web site. For example:


    # ./certutil -R -s "CN=hostname.sesta.com, 
    OU=hostname/ SSL Web Server, O=Sesta, 
    C=US" -p "408-555-1234" -o hostnameCert.req 
    -g 1024  -d /etc/opt/SUNWics5/config 
    -f /mypath/mypassworfile  -z /etc/passwd -a

    where “hostname.sesta.com” is the host name.

  4. Request an test certificate for an SSL web server from the Certificate Authority or Public Key Infrastructure (PKI) Web site. Copy and paste the contents from the hostnameCert.req file into the Certificate Request.

    You will be notified by when your certificate is signed and can be picked up.

  5. Copy the Certificate Authority Certificate Chain and SSL server certificate into text files.

  6. Import the Certificate Authority Certificate Chain into the certificate database to establish a Chain of Authority. For example:


    # ./certutil -A -n "GTE CyberTrust Root"
        -t "TCu,TCu,TCuw" 
        -d /etc/opt/SUNWics5/config 
        -a 
        -i /export/wspace/Certificates/CA_Certificate_1.txt
        -f /mypath/mypassworfile
    # ./certutil -A -n "Sesta TEST Root CA" 
        -t "TCu,TCu,TCuw" 
        -d /etc/opt/SUNWics5/config 
        -a 
        -i /export/wspace/Certificates/CA_Certificate_2.txt
        -f /mypath/mypassworfile
    
  7. Import the signed SSL server certificate:


    # ./certutil -A -n "hostname SSL Server Test Cert"
        -t "u,u,u" -d /etc/opt/SUNWics5/config 
        -a 
        -i /export/wspace/Certificates/SSL_Server_Certificate.txt
        -f /mypath/mypassworfile
    
  8. List the certificates in the certificate database:

    # ./certutil -L -d /etc/opt/SUNWics5/config

  9. Configure the SSL Server Nickname in the ics.conf file to be the signed SSL server certificate, For example: “hostname SSL Server Test Cert”.

    Note The host name for the service.http.calendarhostname and service.http.ssl.sourceurl parameters in the ics.conf file should match the host name on the SSL certificate (in case your system has several aliases). For example: calendar.sesta.com

ProcedureTo Configure SSL Parameters in the ics.conf File

To implement SSL with Calendar Server, you must set specific parameters in the ics.conf file. If any of the parameters listed in the following table are not in the ics.conf file, add them to the file with the value specified. Since the ics.conf is read only at system startup (when start-cal is issued), the new values will not take effect until the Calendar Server is restarted. For a description of these SSL parameters, see E.2.10 Calendar Server SSL Configuration Parameters.

  1. Log in as an administrator with permission to change the configuration.

  2. Change to the /etc/opt/SUNWics5/cal/config directory.

  3. Save your old ics.conf file by copying and renaming it.

  4. Edit one or more of the parameters as shown in the following table:

    Parameter 

    Value 

    encryption.rsa.nssslactivation

    "on"

    encryption.rsa.nssslpersonalityssl

    "SampleSSLServerCert"

    encryption.rsa.nsssltoken

    "internal"

    service.http.tmpdir

    "/var/opt/SUNWics5/tmp"

    service.http.uidir.path

    "html"

    service.http.ssl.cachedir

    "."

    service.http.ssl.cachesize

    "10000"

    local.ssldbpath

    "/etc/opt/SUNWics5/config"

    service.http.ssl.port.enable

    "yes"

    service.http.ssl.port

    "443" (Default SSL port)


    Note –

    Not on port "80", which is the HTTP default port.


    service.http.securesession

    "yes" (Entire session encrypted)

    service.http.ssl.sourceurl

    "https://localhost:port" (Supply the name of your localhost, and the service.http.ssl.port value.)

    service.http.ssl.ssl3.ciphers

    "rsa_red_40_md5,

    rsa_rc2_40_md5,

    rsa_des_sha,

    rsa_rc4_128_md5,

    rsa_3des_sha"

    service.http.ssl.ssl3.sessiontimeout

    "0"

    service.http.sslusessl

    "yes"

  5. Save the file as ics.conf.

  6. Restart Calendar Server for the changes to take effect.

    cal-svr-base/SUNWics5/cal/sbin/start-cal

7.2 Troubleshooting SSL for Calendar Server 6.3 Software

First, always backup your certificate database on a regular basis in case unrecoverable problems occur. This section contains things to consider after you back up your database.

7.2.1 Checking for the cshttpd Process

SSL requires the Calendar Server cshttpd process to be running. To determine if cshttpd is running, use this command:

# ps -ef | grep cshttpd

7.2.2 Verifying Certificates

To list the certificates in the certificate database and checking their validity dates, use this command:

# ./certutil -L -d /etc/opt/SUNWics5/config

7.2.3 Reviewing Calendar Server Log Files

Check the Calendar Server log files for any SSL errors.

7.2.4 Connecting to the SSL Port

Connect to the SSL port using a browser and the following URL:

https://server-name:ssl-port-number

where:

server-name is the name of the server where Calendar Server is running.

ssl-port-number is the SSL port number as specified by the service.http.ssl.port parameter in the ics.conf file. The default is 443.

7.2.5 Making cshttpd Stop Listening on the Regular HTTP Port

HTTP and HTTPS listen on different ports (443 for SSL, and 80 for HTTP), so you will never have both listening to the same port. Currently, there is no way to tell cshttpd to stop listening to the regular HTTP port. However, an administrator can change the service.http.port to an undisclosed number.


Caution – Caution –

Do not set service.http.enable ="no" in an attempt to prevent cshttpd from listening to HTTP. Doing so would cause HTTPS to fail also. Both service.http.enable and service.http.ssl.port.enable must be set to "yes" for SSL to be configured properly.


Chapter 8 Configuring Single Sign-on for a Calendar Server 6.3 System

This chapter describes how to configure single sign-on (SSO).

Single sign-on (SSO) allows a user to authenticate once and then use multiple trusted applications without having to authenticate again.

Sun Java System communications servers, including Calendar Server and Messaging Server, can implement SSO as follows:

8.1 Configuring SSO Through Access Manager

Sun Java Enterprise System servers, including Calendar Server and Messaging Server, can implement SSO using Sun Java System Access Manager (release 6 2003Q4 or later)

Access Manager serves as the SSO gateway for Sun Java Enterprise System servers. That is, users log in to Access Manager and then can access other Sun Java Enterprise System servers, as long as the servers are configured properly for SSO.

ProcedureTo use SSO with Calendar Server

  1. Make sure that Access Manager and Directory Server are installed and configured. For information about installing and configuring these products, refer to the Sun Java Enterprise System 5 Installation Guide for UNIX.

  2. After stopping Calendar Server services, configure SSO for Calendar Server by setting the parameters shown in 8.1 Configuring SSO Through Access Manager. For the values to take effect, you must restart Calendar Server services.


    Note –

    When you set the local.calendar.sso.amnamingurl parameter, you must use a fully qualified host name for where Access Manager software is installed.


  3. To configure SSO for Messaging Server, refer to the Sun Java System Messaging Server 6.3 Administration Guide.

  4. Users log into Access Manager using their Directory Server LDAP user name and password. (A user who logs in through another server such as Calendar Server or Messaging Server will not be able to use SSO to access the other Sun Java Enterprise System servers.)

  5. After logging in, users can access Calendar Server through Communications Express using the appropriate URL. Users can also access other Communications Suite servers such as Messaging Server, if the servers are configured properly for SSO.

    Parameter  

    Description  

    local.calendar.sso.amnamingurl

    Specifies the URL of the Access Manager SSO naming service. 

    Default is  

    http://AccessManager:port/amserver/namingservice

    where AccessManager is the fully qualified name of Access Manager, and port is the Access Manager port number.

    local.calendar.sso.amcookiename

    Specifies the name of the Access Manager SSO cookie. 

    Default is "iPlanetDirectoryPro".

    local.calendar.sso.amloglevel

    Specifies the log level for Access Manager SSO. Range is from 1 (quiet) to 5 (verbose). Default is “3“. 

    local.calendar.sso.logname

    Specifies the name of the Access Manager SSO API log file. 

    Default is: am_sso.log

    local.calendar.sso.singlesignoff

    Enables (“yes“) or disables (“no“) single sign-off from Calendar Server to Access Manager. 

    If enabled, a user who logs out of Calendar Server is also logged out of Access Manager, and any other sessions the user had initiated through Access Manager (such as a Messaging Server Webmail session) are terminated. 

    Because Access Manager is the authentication gateway, single sign-off is always enabled from Access Manager to Calendar Server. 

    Default is “yes“. 


    Tip –

    A best practice for changing the ics.conf file is to add the parameter and its new value to the end of the file. The system reads the entire file and uses the last value found for the parameter.


8.1.1 Considerations for Using Single Sign-on With Access Manager

This section lists some considerations for using Single Sign-on (SSO) with Access Manager.

The following are some of the considerations:

8.1.2 Configuring SSO Through Communications Servers Trusted Circle Technology

When configuring SSO through Communications Servers trusted circle technology (that is, not through Access Manager), consider these points:

The following table describes the Calendar Server configuration parameters for SSO through Communications Servers trusted circle technology.

Table 8–1 Calendar Server SSO Parameters Through Communications Servers Trusted Circle Technology

Parameter  

Description  

sso.enable

This parameter must be set to "1" (the default) to enable SSO. "0" disables SSO. 

sso.appid

This parameter specifies the unique application ID for the specific Calendar Server installation. Each trusted application must also have a unique application ID. The default is: "ics50"

sso.appprefix

This parameter specifies the prefix value to be used for formatting SSO cookies. The same value must be used by all trusted applications, because only SSO cookies with this prefix will be recognized by Calendar Server. The default is: "ssogrp1"

sso.cookiedomain

This parameter causes the browser to send a cookie only to servers in the specified domain. The value must begin with a period (.) 

sso.singlesignoff

A value of “true” (the default) clears all SSO cookies on the client with prefix values matching the value configured in sso.appprefix when the client logs out.

sso.userdomain

This parameter sets the domain used as part of the user's SSO authentication. 

sso.appid.url = "verifyurl"

This parameter sets the verify URL values for peer SSO hosts for the Calendar Server configuration. One parameter is required for each trusted peer SSO host.  

This parameter contains the following parts:

  • Application ID (appid) identifies each peer SSO host whose SSO cookies are to be honored

  • Verify URL (verifyurl) includes the host URL, host port number, and VerifySSO? (including the ending question mark (?).

    In this example, the Calendar Server application ID is ics50, the host URL is sesta.com, and the port is 8883.

    The Messenger Express application ID is msg50, the host URL is sesta.com, and the port is 8882.

For example: 

sso.ics50.url=
  "http://sesta.com:8883
  /VerifySSO?"
sso.msg50.url=
  "http://sesta.com:8882
  /VerifySSO?" 

The following table describes the Messaging Server configuration parameters for SSO through Communications Servers trusted circle technology.

Table 8–2 Messaging Server SSO Parameters Through Communications Servers Trusted Circle Technology

Parameter  

Description  

local.webmail.sso.enable

This parameter must be set to a non-zero value to enable SSO. 

local.webmail.sso.prefix

This parameter specifies a prefix used when formatting SSO cookies set by the HTTP server. For example: ssogrp1

local.webmail.sso.id

This parameter specifies the unique application ID ( for example: msg50) for the Messaging Server.

Each trusted application must also have a unique application ID. 

local.webmail.sso.cookiedomain

This parameter specifies the cookie domain value of all SSO cookies set by the HTTP server. 

local.webmail.sso.singlesignoff

A non-zero value clears all SSO cookies on the client with prefix values matching the value configured in local.webmail.sso.prefix when the client logs out.

local.sso.appid.url=verifyurl

This parameter sets the verify URL values for peer SSO hosts for the Messaging Server configuration. One parameter is required for each trusted peer SSO host.  

The parameter includes these parts:

  • Application ID (appid) identifies each peer SSO host whose SSO cookies are to be honored

  • Verify URL (verifyurl) includes the host URL, host port number, and VerifySSO? (including the ending ?).

    For example:

    local.sso.ics50.verifyurl=

    http://sesta.com:8883/VerifySSO?

    In this example, the Calendar Server application ID is ics50, the host URL is sesta.com, and the port is 8883.

    local.sso.msg50.verifyurl=

    http://sesta.com:8882/VerifySSO?

    In this example, the Messaging Server application ID is msg50, the host URL is sesta.com, and the port is 8882.

For more information about configuring Messaging Server for SSO, see the Sun Java System Messaging Server 6.3 Administration Guide.

Chapter 9 Configuring Automatic Backups (csstored)

At configuration time you are given the opportunity to enable automatic backups. However, you can also enable or disable automatic backups at any time thereafter. A good backup system is essential to safeguard your data and minimize operational downtime.

Information in this chapter explains how to configure the Calendar Server service csstored to perform automatic backups.


Note –

If you choose not to use the automatic backup process discussed here, you must implement your own backup strategy to safeguard your data. For information on how to use other Calendar Server tools for protecting your data, see Chapter 17, Backing Up and Restoring Calendar Server Data.


For an overview of csstored, see the Sun Java Communications Suite 5 Deployment Planning Guide.

9.1 Enabling the Calendar Server Store Service (csstored)

The store service must be enabled in the ics.conf file. Verify that the store service is enabled by setting the following ics. conf file parameter is set to "yes":

local.store.enable

If this parameter is set to "yes", each service that accesses the store depends on the successful start up of the store service.

9.2 Overview of Automatic Backups in a Calendar Server 6.3 System

This section is an overview of how automatic backups are implemented in a Calendar Server system.

This section covers the following topics:

9.2.1 How Automatic Backups Work in a Calendar Server 6.3 System

The Calendar Server system records each transaction for the calendar database (additions, modifications or deletions to calendars and their properties) in a transaction log file. At some predetermined interval, the log file is closed for writing and another is created. The system then applies the transactions from the oldest closed transaction log to the live calendar databases as time permits. When all the transactions in the log have been applied to the database, the log is marked as “already applied”.

When hot backups are configured, a snapshot of the live databases is taken every 24 hours. The already applied logs are then applied to the hot backup copy of the databases. The hot backup databases are as current as the number of transactions still waiting to be applied.

9.2.2 How csstored Works for Backups in a Calendar Server 6.3 System

One of the Calendar Server services launched at startup is csstored. When configured, this service performs automatic backups (either hot backups or archival backups, or both) of your calendar databases.

You can configure csstored for automatic backups when you run the configuration program, csconfigurator.sh. If you choose one or both of the automatic backups at that time, no further configuration steps are necessary.

If csstored is disabled, none of the other daemons that access the database will work. The csstored daemon performs other necessary tasks for the databases. Therefore, the daemon should not be disabled.


Note –

When automatic backups are disabled, the circular logging ics.conf parameter, caldb.berkeley.circularlogging, should be set to "yes". This enables purging of old database transaction logs, which conserves disk space.


9.2.3 How Circular Backups Work in a Calendar Server 6.3 System

With automatic backups enabled, csstored automatically manages the number of backup copies retained in your backup database files using a circular backup system.

The csstored process stores backups in your backup database directory until either the maximum number of backup copies have accumulated, or the maximum disk space allowed has been reached. At that point, it purges backup copies (oldest first) until it reaches the minimum number of copies to retain and it is under the disk space threshold.

There are a cluster of ics.conf parameters that control circular backups. These parameters have default values, and do not require further customization. If you wish to tune how backups work in your system, see 21.7 Tuning Automatic Backups.

9.2.4 High Level Steps for Enabling Automatic Backups

If you did not configure automatic backups when you ran the configuration file, you can set them up later. This section contains a list of high-level steps necessary for enabling automatic backups for the Calendar Server 6.3 system after the configuration program has already run.

The following is the list of high-level tasks:

9.3 Setting up Transaction Log Files for Calendar Server 6.3 Backups

This section contains both overview and instructions for setting up transaction log files.

This section covers the following topics:

9.3.1 Understanding Transaction Log Files for Calendar Server 6.3 Backups

Transaction log files are used by Calendar Server to capture all of the additions, modifications and deletions made to the calendar database since the latest snapshot. The transactions are not actually applied to the live database until the log file is closed for writing. The interval parameter specifies how often the old log files are closed and new log files are created.

The log file names consist of a configurable name with a unique number appended to the end.

As the log files are closed, they are ready to be applied to the live database. This happens asynchronously, meaning the creation of log files and the writing of transactions into them is done in “real time”, whereas the program applying the transactions to the database is running independently, without regard to the writing of the transactions into the log files. If the system is very busy, the number of log files awaiting application to the database can rise. When the system has slow periods, the program applying the transactions has time to “catch up” and may actually sit idle, waiting for the next transaction log.

After the transactions have been applied to the live database, they are applied to the hot backup snapshot (if enabled). The log files are also written to the same archive directory where the snapshot resides.

ProcedureTo Set up Transaction Log Files

  1. At a command line, change to the directory where the ics.conf is located:

    cd /etc/opt/SUNWics5/config

  2. Specify the transaction log name:

    logfile.store.logname=storename.log

  3. Specify the directory path for the transaction log directory:

    The default value is: logfile.logdir="logs"

  4. When you have completed editing the ics.conf file, restart Calendar Server:

    cal-svr-base/SUNWics5/cal/sbin/start-cal

9.4 Specifying the Calendar Server Administrator’s Email Address

This section contains overview and instructions for setting the Calendar Server administrator's email address.

This section covers the following topics:

9.4.1 Email Messages Sent to the Administrator

When certain events or errors occur, the administrator is notified by email.

The events causing an email message to be generated are:

ProcedureTo Set the Calendar Server 6.3 System Administrator’s Email Address

  1. Log in as an administrator with permission to change the configuration.

  2. Stop Calendar Server services by issuing the stop-cal command.

  3. Change to the /etc/opt/SUNWics5/cal/config directory.

  4. Save your old ics.conf file by copying and renaming it.

  5. Edit the ics.conf parameter that follows to specify the administrator’s email address:

    alarm.msgalarmnoticercpt="admin@email_address"

  6. Save the file as ics.conf.

  7. Restart Calendar Server.

    cal-svr-base/SUNWics5/cal/sbin/start-cal

9.5 Enabling Hot Backups for Calendar Server 6.3 Databases

This section contains an overview and instructions for enabling hot backups for Calendar Server 6.3 databases, if you did not configure them when you ran the configuration program.

This section covers the following topics:

9.5.1 What are Hot Backups in Calendar Server Version 6.3?

Ideally, hot backups consist of the latest snapshot with all of the transaction logs applied to the it, except the transaction log currently being written. The system can get behind in applying the transaction logs, depending on how busy the system is. It is possible that there might be several log files that have not yet been applied to either the database or the hot backup.

This “almost duplicate” of the live database is designed to minimize down time and data loss if something catastrophic happens, or if a corruption of the database is detected.

A new hot backup is started every 24 hours when a new snapshot is taken. The old hot backup is verified and kept until purged. For more information, see 9.2.3 How Circular Backups Work in a Calendar Server 6.3 System.

ProcedureTo Enable Hot Backups for a Calendar Server 6.3 System

  1. Log in as an administrator with permission to change the configuration.

  2. Stop Calendar Server services by issuing the stop-cal command.

  3. At a command line, change to the directory where the ics.conf is located:

    cd /etc/opt/SUNWics5/config

  4. Enable hot backups by setting the following ics.conf parameter to "yes":

    caldb.berkeleydb.hotbackup.enable="yes"

  5. Specify the directory path for the hot backup directory:

    caldb.berkeleydb.hotbackup.path=
       /var/opt/SUNWics5/hotbackup_directory
    

    The default hot backup directory for Calendar Server is /var/opt/SUNWics5/csdb for Solaris and /var/opt/sun/calendar/csdb for Linux. The Communications Suite installer puts the archive and hot backup directories in the csdb directory by default because it is the convenient subdirectory that is known to the installer.


    Note –

    It is highly recommended that the Calendar Server administrator needs to put the archive and hot backup in a different disk or volume or partition than the csdb directory because of the size issues.


    The number of archive and hot backup directories is configurable. So, if you choose to have six of each archive and hot backup directories, it means that they might have 6 + 6 + 1 copies of your live database in the csdb directory. The csstored utility calculates the size of the required archive and hot backup based off of the size of the contents of the csdb directory and the physical disk that csdb is located on.

    The archive and hot backup directories are installed inside the csdb directory by default for convenience. But, it should be located in a directory outside of csdb for a real life deployment.

    You might choose to place hot backups on an alternate disk or disk subsystem in case of a hardware failure on the primary disk drive. Doing this might also reduce input-output contention on the primary drive or subsystem.

    If you have a high availability (HA) configuration, specify the path as a subdirectory in shared storage (/global/cal/). See also, Chapter 6, Configuring Calendar Server 6.3 Software for High Availability (Failover Service).

  6. When you have completed editing the ics.conf file, restart Calendar Server:

    cal-svr-base/SUNWics5/cal/sbin/start-cal

9.6 Enabling Archive Backups for Calendar Server 6.3 Databases

This section contains overview material and instructions for enabling archival backups for Calendar Server databases if you did not configure them when the configuration program ran.

This section covers the following topics:

9.6.1 What are Archive Backups in Calendar Server Version 6.3?

Archive backups consist of a snapshot and the log files that were created for it. The log files are not applied to the snapshot. The archive databases remain on disk until purged. See 9.2.3 How Circular Backups Work in a Calendar Server 6.3 System.

ProcedureTo Enable Archive Backups for a Calendar Server 6.3 System

  1. Log in as an administrator with permission to change the configuration.

  2. Stop Calendar Server services by issuing the stop-cal command.

  3. At a command line, change to the directory where the ics.conf is located:

    cd /etc/opt/SUNWics5/config

  4. Enable archive backups by setting the following ics.conf parameter to “yes”:

    caldb.berkeleydb.archive.enable=”yes”

  5. Specify the directory path for the archive directory:

    caldb.berkeleydb.archive.path=
       /var/opt/SUNWics5/archive_backup_directory
    

    You might choose to place the archive backups on an alternate disk or disk subsystem in case of a hardware failure on the primary disk drive. Doing this might also reduce I/O contention on the primary drive or subsystem.

    If you have a high availability (HA) configuration, specify the path as a subdirectory in shared storage (/global/cal/). See also, Chapter 6, Configuring Calendar Server 6.3 Software for High Availability (Failover Service).

  6. When you have completed editing the ics.conf file, restart Calendar Server:

    cal-svr-base/SUNWics5/cal/sbin/start-cal

    The calendar services do not need to be stopped to edit the ics.conf file, but you must restart the services in order for the changes to take effect.

Chapter 10 Setting Up a Multiple Domain Calendar Server 6.3 Environment

This chapter contains overview material and instructions on how to set up a multiple domain environment for the first time.


Tip –

In the past, domains in a multiple domain environment have been referred to as both hosted domains, and virtual domains. These terms are interchangeable in this document.


This chapter covers the following topics:

10.1 Overview of Multiple Domains in Calendar Server Version 6.3

Calendar Server 6.3 features multiple domains as the default, and only, way to organize your user and group LDAP entries. That is, you must have at least one domain under the root node and all of your user and group entries must reside under a domain node. In earlier versions of Calendar Server, the use of domains to contain user and group entries was optional. You could run Calendar Server without using domains at all. That is no longer true for Calendar Server 6.3; you must have at least one (default) domain.

In a multiple domain environment, each domain shares the same instance of the Calendar Server system, which allows multiple domains to exist on a single server. Each domain defines a name space within which all users, groups, and resources are unique. Each domain also has a set of attributes and preferences that you specifically set. All user and calendar IDs for domains must be fully qualified.

The configuration program asks you for the necessary information to set up the default domain. When the configuration program is done and you have created all of the domains you need, before copying your user and group LDAP entries to the desired domains, you must prepare the user and group entries by running the migration utilities to convert your non-domain user and group LDAP entries to domain ready user and group entries. The utilities to run are csmig and csvdmig.

If you are upgrading to Calendar Server 6.3 from a non-domain version of Calendar Server, you have several choices to make:

If you had hosted (multiple) domains set up prior to upgrading to the current version, your user IDs and calendar IDs need not be altered. However, there are some new ics.conf parameters that need to be configured, as shown in the following section:10.4 Additional Parameters Required for Multiple Domain Mode in Calendar Server Version 6.3.


Caution – Caution –

If your site is currently configured for multiple instances of Calendar Server on a single machine, or if you have implemented a limited virtual domain mode, contact your Sun Microsystems sales account representative for an evaluation of your migration requirements.


10.2 Setting up a Multiple Domain Environment for Calendar Server Version 6.3 for the First Time

To move from a non- or single domain environment to a multiple domain environment, you might need to perform the following tasks before creating any LDAP entries:

  1. Run the database migration utilities.

    If you are migrating from Calendar Server version 5, be sure that you have already run csmig, csvdmig, cs5migrate, and cs5migrate before attempting to set up multiple domains. For more information on these migrations utilities, see Chapter 3, Database Migration Utilities for Calendar Server 6.3.

  2. Run the comm_dsseetup.pl if you have not already done so.

  3. Log in as an administrator with permission to change the configuration.

  4. Stop Calendar Server services by issuing the stop-cal command.

  5. Edit the ics.conf file to enable multiple domains.

    The following table lists and describes the configuration parameters in the ics.conf file used for multiple domain support. If any of the parameters listed in this table are not in the ics.conf file, add the parameter and its associated value to the file and then restart Calendar Server for the values to take effect.

    Parameter  

    Description  

    service.virtualdomain.support

    Enables ("yes") support for multiple domains. Default is "yes".


    Note –

    Do not change this parameter to “no” even if you are going to operate in a single domain. The current version of Calendar Server requires this to be “yes”.


    local.schemaversion

    Specifies the version of the LDAP schema:

    service.dcroot

    For multiple domain support, this replaces local.ugldapbasedn and local.authldapbasedn.

    If local.schemaversion="1" or local.schemaversion="1.5", specifies the root suffix of the DC tree, underneath which all domains are found.

    For example: "o=internet".

    service.schema2root

    if local.schemaversion="2", specifies the root suffix of the Organization Tree, underneath which all domains are found.

    For example: "o=sesta.com".

    service.defaultdomain

    Specifies the default domain for this instance of Calendar Server. Used when a domain name is not supplied during a login. 

    For example: "red.sesta.com".

    service.loginseparator

    Specifies a string of separators used for the login-separator when Calendar Server parses "userid[login-separator]domain". Calendar Server tries each separator in turn.

    Default is "@+".

    service.siteadmin.userid

    Specifies the user ID of the domain administrator. 

    For example: DomainAdmin@sesta.com.

    service.virtualdomain.scope

    Controls cross domain searching:

    • "primary" Search only within the domain where the user is logged in.

    • "select" Search in any domain that allows the search.

      Default is "select".

    local.domain.language

    Specifies the language for the domain. Default is "en" (English).

  6. Create a default domain entry.

    For Schema version 2, the default domain is created by the Delegated Administrator configuration program (config-commda).

    For Schema version 1, create a default domain (one of your multiple domains), placing it one or more levels under your DC tree root suffix, depending on your DC tree structure. For example, if your root suffix is o=internet, then the next level down node could be com, as shown in 10.3.3 Sun LDAP Schema Version 1 for Calendar Server Version 6.3. However, your default domain would be one node lower, such as sesta.com. Use csdomain to create DC tree nodes, as illustrated in the example that follows:

    csdomain -n o=com,dc=com,o=internet create comcsdomain
        -n o=sesta.com,dc=sesta,dc=com,o=internet create sesta.com
  7. Enable calendaring services for the default domain entry.

    For Schema version 1: Add the icsCalendarDomain object class to the o=sesta.com domain entry in LDAP using csattribute.

    For Schema version 2: After configuring Delegated Administrator, modify the default domain (created by the Delegated Administrator configuration program) to add Calendar (and Mail) services. In the following example, calendar and mail services are added to a domain:

    commadmin domain modify -D admin -w passwd -d defaultdomain -S cal,mail

  8. Create as many domains as you want on your system.

    For instructions on how to add a domain in Schema version 2 mode, see 13.2 Creating New Calendar Server Domains.

    To create a Schema version 1 domain, use csdomain create, as illustrated in the example that follows:

    csdomain -n o=red.sesta.com,dc=red,dc=sesta,dc=com 
       create red.sesta.com
  9. Add calendar (and mail, if wanted) services for the new domains.

  10. Create the calmaster site administrator user if it does not already exist.

    For Schema version 2, create the calmaster user using the commadmin user create command as illustrated in the following example:

    commadmin user create -D admin -w passwd -F Calendar
        -L Administrator -l calmaster -W calmasterpasswd -d sesta.com -S cal

    Note –

    To create the calmaster using the Delegated Administrator Console's Create New User wizard, see the Delegated Administrator online help.


    For Schema version 1, create the calmaster user on the organization tree with csuser as illustrated in the following example:

    csuser o=sesta.com,o=rootsuffix -d sesta.com
        -g Calendar -s Administrator -ycalmasterpasswordcreate calmaster
  11. If the calmaster site administrator user already exists from an earlier non-domain environment (Schema version 1), move it to the default domain by performing the following steps:

    1. Perform an LDAP dump of the existing calmaster LDAP entry and save it in a temporary file, such as /tmp/calmaster.ldif.

    2. Delete the existing calmaster LDAP entry on the organization tree root suffix using ldapdelete, as follows:

      #ldapdelete -D "cn=Directory Manager" -w password 
         uid=calmaster,ou=People,o=rootsuffix
      
    3. Modify the calendar administrator’s group entry (update the uniqueMember attribute) to reflect the changes as shown in the LDIF example that follows:


      dn:cn=Calendar Administrators,ou=Groups,o=rootsuffix
      changetype:modifyreplace:uniqueMember 
      uniqueMember:uid=calmaster,ou=People,o=sesta.com,o=rootsuffix
      

      It is not necessary to move the administrator's group entry to the domain.

  12. Update any administration scripts you have so that all calendar IDs (calid) in the WCAP commands are fully qualified. That is, each calid must now include the domain name. For example: jsmith@sesta.com.

10.3 How the Multiple Domains Feature in Calendar Server Version 6.3 Influences Your Schema Choices

This section contains conceptual information you can use to better understand the process for implementing multiple domains and what it has to do with choosing a schema version.

This section contains the following topics:

10.3.1 Overview of Multiple Domains and the Implications for Schema Choice for Calendar Server Version 6.3

With a multiple domain installation, the LDAP directory is organized into distinct, non-intersecting sections, each of which represents a domain found in the Domain Name System (DNS). User, group and resource unique IDs are unique within each domain. For example, there can be only one user in each domain with the uid of jdoe. A distinguished name (DN) is a fully qualified domain name.

Calendar Server supports both of these LDAP directory schema versions: Schema version 1 and Schema version 2. When you run the Directory Server Setup script (comm_dssetup.pl), you can choose either LDAP Schema version 1 or LDAP Schema version 2. Use Schema version 2, unless you have specific reasons for using Schema version 1

The following are two reasons to use Schema version 1:

10.3.2 Sun LDAP Schema Version 2 for Calendar Server Version 6.3

The following graphic shows an LDAP directory organization for a multiple domain installation that uses Sun LDAP Schema version 2.

Figure 10–1 LDAP Directory Organization Using LDAP Schema Version 2

This diagram shows an example of a pure Schema version
2 environment using only a single tree, an Organization tree, and no DC tree.

LDAP Schema version 2 uses a flat LDAP directory organization, that is, the domains are all at the same level; they are not nested. For a multiple domain installation, the first level entries (as shown by varriusDomain, sestaDomain, and siroeDomain in the graphic) must be parallel in the directory organization. These entries cannot be nested.

If you want to use Access Manager features such as single sign-on (SSO), or use Delegated Administrator to provision users, Schema version 2 is required. However, there is a hybrid variation, a two tree scheme that uses both the DC tree and the Organization tree, much like Schema version 1, but it uses the Schema version 2 object classes and attributes. This is Schema version 2 compatibility mode, which is called Schema version 1.5 in the configuration program (csconfigurator.sh).

10.3.3 Sun LDAP Schema Version 1 for Calendar Server Version 6.3

The graphic that follows shows an example of an LDAP directory organization for a multiple domain installation that uses Sun LDAP Schema version 1.

This organization includes two trees for domain management:

Figure 10–2 LDAP Directory Organization Using LDAP Schema Version 1

This diagram shows an example of a two tree, Schema version
1, LDAP organization.

The DC tree (node) is similar to the DNS, which determines a domain entry given the domain name. The inetdomainbasedn LDAP attribute points to the base DN, which is the root of the domain’s users, resources and groups in the organization tree (node). Within each domain, the identifiers for Calendar Server users, resources, and groups must be unique.


Note –

If your earlier LDAP configuration did not contain a DC tree, in order to use Schema version 1 mode or Schema version 2 compatibility mode, you must create the DC tree nodes yourself as explained in 10.2 Setting up a Multiple Domain Environment for Calendar Server Version 6.3 for the First Time. However, Schema version 2 is the preferred mode.


In a multiple domain installation using LDAP Schema version 1, a directory search requires these two steps to find an entry:

  1. In the DC tree, the search operation locates the domain entry that contains the value of the DN pointing to the base DN (inetDomainBaseDN attribute) of domain in the organization tree.

  2. In the organization tree, the search operation locates the domain entry and then searches from that entry’s base DN to find the user, resource, or group within the domain.

10.4 Additional Parameters Required for Multiple Domain Mode in Calendar Server Version 6.3

Starting with Calendar Server 6 , every deployment is configured for multiple domains. If you are upgrading from an older version of Calendar Server, and did not have hosted (multiple) domains configured, you must add the parameters, as shown, for your schema mode:

10.4.1 Schema Version 1 Parameter Additions for Calendar Server Version 6.3

The following list of parameters should be added to the configuration file (ics.conf), if they do not already exist.

service.dcroot

service.defaultdomain

service.loginseparator

service.virtualdomain.support set to "yes"

service.virtualdomain.scope

service.siteadmin.userid

service.siteadmin.cred

local.schemaversion set to "1"

10.4.2 Schema Version 2 Parameter Additions for Calendar Server Version 6.3

The following list of parameters should be added to the configuration file (ics.conf), if they do not already exist:

service.dcroot

service.defaultdomain

service.loginseparator

service.virtualdomain.support set to "yes"

service.virtualdomain.scope

service.siteadmin.userid

service.siteadmin.cred

local.schemaversion set to "2"

service.schema2root

10.5 Calendar Server 6.3 Logins

For a multiple domain installation, each user must have a user ID (uid) that is unique within the domain. A login to Calendar Server uses the following format:

userid[@domain-name]

If domain-name is omitted, Calendar Server uses the default domain name specified by the service.defaultdomain parameter in the ics.conf file. Thus, if a user is logging into the default domain, only the userid is required.

If autoprovisioning is enabled, the first time a user logs in, Calendar Server creates a default calendar for the user. For information about calendar creation, see Chapter 15, Administering Calendars.

Login permission is based on the icsStatus or icsAllowedServiceAccess attribute. For more information, see D.9.3 LDAP Attributes and Property Names.

10.6 Migrating from a Non-Domain Environment in Calendar Server Version 6.3

In Calendar Server version 5.0 and earlier, there were no domains. Therefore, the user and calendar ID's were not required to be fully qualified. That is, they did not need a domain name to be part of the ID such as jdoe@domain.com. If your uid's and calid's were not fully qualified before installing the current version of Calendar Server, your data does not have to be altered. The system assumes any unqualified uid's and calid's it encounters to belong to the default domain. If you want to implement multiple domains, however, you must migrate your LDAP and components databases to indicate which domain each user belongs to.

In addition, your data might need to be migrated in other ways. There are several migration programs. Check the migration information found in Chapter 3, Database Migration Utilities for Calendar Server 6.3.

Chapter 11 Customizing Existing Domains for a Calendar Server 6.3 System

This chapter contains conceptual information and instructions on how to customize your existing domains.

This chapter describes these topics:

11.1 Configuring Domain Preferences for Groups in Calendar Server Version 6.3

If you have user groups set up in LDAP, you can specify domain level preferences for doublebooking and set default ACL's.

11.1.1 Setting the Doublebooking Domain Preference in Calendar Server Version 6.3

Set bit 15 of the icsAllowRights attribute in the domain LDAP entry. Use "0" if doublebooking is not allowed. Use "1" if doublebooking is allowed.

11.1.2 Specifying the Default ACL for Groups in Calendar Server Version 6.3

You can change the default access control permissions for groups at various levels.

This section covers the following group ACL topics:

11.1.2.1 For All Groups

The default ACL for groups in any domain is specified in the ics.conf file parameter group.default.acl. The default ACL is:

"@@o^a^r^g;@@o^c^wdeic^g;@^a^rsf^g"

You can change the ACL by editing it.

11.1.2.2 For All Groups in a Specific Domain

To change the default ACL for groups in a specific domain, you must edit the domain LDAP entry. Change the value of the groupdefaultacl property in the icsExtendedDomainPrefs attribute.

11.1.2.3 For a Specific Group in a Domain

To change the default ACL for a specific group, edit the group LDAP entry. Change the value of the icsDefaultacl attribute.

11.2 Cross Domain Searching in Calendar Server 6.3 Systems

This section contains conceptual information and high-level tasks for setting up cross domain searches.

By default, users can search only within their home domain for users, groups and resources to invite to events. Cross domain searches, however, allow users in one domain to search for users, groups and resources in other domains, as long as certain requirements are met.

The following is a list of requirements you must meet to successfully implement cross domain searches:

For instructions on how to enable cross domain searches, see 13.3 Enabling Cross Domain Searches.

11.3 Using Domains Created by Messaging Server in Calendar Server Version 6.3

If Messaging Server has already created domains, you can add calendar services in either Schema version 1 or Schema version 2 mode.

This section covers the following topics:

11.3.1 Adding Calendar Services to Messaging Domains in Schema Version 1 Mode for Calendar Server Version 6.3

To add calendar services to a domain, add the following object class and two attributes to the domain's LDAP entry:

You can do this in one of two ways: use csattribute add command or use ldapmodify as shown in the example that follows:


dn:dc=sesta,dc=com,o=internet
 changetype:modify
 add:objectclass
 objectClass:icsCalendarDomain
 add:icsStatus
 icsStatus:active
 add:icsExtendedDomainPrefs
 icsExtendedDomainPrefs:domainAccess=@@d^a^slfrwd^g;anonymous^a^r^g;@^a^s^g
               

11.3.2 Adding Calendar Services to Messaging Domains in Schema 2 Mode in Calendar Server Version 6.3

If Messaging Server is in Schema version 2 mode, perform the following two steps to add calendar services to the existing domains:

  1. Use the Delegated Administrator Utility command commadmin domain modify with the -S option to add calendar service to each domain.

    Alternately, you can use the Delegated Administrator Console to allocate service packages containing calendar service to the affected domains. To do this, use the Allocate Service Packages button on the Organization List page.

  2. Use the Delegated Administrator Utility command commadmin user modify with the -S option to add calendar service to each user in each domain you enabled for calendar.

    Alternately, you can use the Delegated Administrator Console to assign a service package containing calendar service to each user in the affected domains. To do this, use the Assign Service Package button on the User List page in each affected organization.

For the commadmin commands, see the Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide.

For more information about Delegated Administrator Console, see its online help.

For commdirmig information, see the Sun Java Communications Suite 5 Schema Migration Guide.