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 6, Configuring Calendar Server 6.3 Software for High Availability (Failover Service)
Chapter 8, Configuring Single Sign-on for a Calendar Server 6.3 System
Chapter 10, Setting Up a Multiple Domain Calendar Server 6.3 Environment
Chapter 11, Customizing Existing Domains for a Calendar Server 6.3 System
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.
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
Do not attempt to edit the configuration file until you have completed the following tasks:
Install or upgrade to Calendar Server 6 2006Q3.
Run the post installation configuration programs comm_dssetup.pl and csconfigurator.sh.
Run csmig, csvdmig, cs5migrate, csmigrate, and commdirmig as needed against your existing calendar databases. See Chapter 3, Database Migration Utilities for Calendar Server 6.3.
This chapter covers the following configuration topics:
4.3 Configuring Calendar for LDAP Users, Groups and Resources
4.7 Configuring Periodic Deadlock Checking for the Berkeley in Calendar Server Version 6.3
This section covers the two configuration file parameters to configure for Communications Express.
Communications Express requires the following:
Log in as an administrator with permission to change the configuration.
Stop Calendar Server services by issuing the stop-cal.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit the ics.conf parameters as shown in the following table:
Enables administrator proxy authentication when set to "yes". The default is "yes".
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.
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.
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.
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.
Save the file as ics.conf.
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 Customization Guide .
Log in as an administrator with permission to change the configuration.
Stop Calendar Server services by issuing the stop-cal.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit the following parameters in the ics.conf to enable anonymous access:
Enables or disables allowing anonymous access users to write to public calendars. Enable access by setting the value to "yes", which is the default.
Enables users to have publicly writable calendars. This is enabled by default (set to "yes").
Enable anonymous access (login) by setting this parameter to "yes", if necessary. The default value is "yes".
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.
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.
Save the file as ics.conf.
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.
This section contains the following topics:
Log in as an administrator with permission to change the configuration.
Stop Calendar Server services by issuing the stop-cal.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit one or more of the parameters as shown in the following table:
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.
Specifies the default access control settings for owners of a calendar. The default is: "@@o^a^rsf^g;@@o^c^wdeic^g"
Specifies whether a user's default calendar is included in user's free/busy calendar list. The default is “yes”.
Specifies whether a user's default calendar can be removed from user's free/busy calendar list. The default is “no”.
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.
Specifies whether a user's default calendar is included in the user's subscribed calendar list. The default is “yes”.
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”.
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.
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").
Save the file as ics.conf.
Restart Calendar Server.
cal-svr-base/SUNWics5/cal/sbin/start-cal
Log in as an administrator with permission to change the configuration.
Stop Calendar Server services by issuing the stop-cal.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit one or more of the parameters as shown in the following table:
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.
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"
When invitations are sent to resources should they be automatically marked as accepted? The default is "yes".
When a resource is invited to an event, if it has no existing calendar, should it be autoprovisioned?
The default is "yes".
Save the file as ics.conf.
Restart Calendar Server.
cal-svr-base/SUNWics5/cal/sbin/start-cal
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.
Log in as an administrator with permission to change the configuration.
Stop Calendar Server services by issuing the stop-cal.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit one or more of the parameters as shown in the following table:
Specifies whether the group calendar can be double booked. The default is yes.
Specifies the default ACL for group calendars:
"@@o^a^r^g;@@o^c^wdeic^g;@^a^rsf^g"
Specifies whether autoprovisioning is enabled or disabled. The default is "yes" (enabled).
Specifies whether a group invitation will automatically have PARTSTAT=ACCEPTED.
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.
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.
Save the file as ics.conf.
Restart Calendar Server.
cal-svr-base/SUNWics5/cal/sbin/start-cal
For instructions on configuring groups, see To Configure Calendar Server for Groups.
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.
Log in as an administrator with permission to change the configuration.
Stop Calendar Server services by issuing the stop-cal.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Disable autoprovisioning of user, resource and group calendars by editing the following parameters:
Specifies whether autoprovisioning of user calendars is enabled (“yes”), or disabled (“no”). The default is “yes”.
Specifies whether autoprovisioning of resource calendars is enabled (“yes”), or disabled (“no”). The default is “yes”.
Specifies whether autoprovisioning of group calendars is enabled (“yes”), or disabled (“no”). The default is “yes”.
Specifies whether auto-inviting of user calendars is enabled (“yes”), or disabled (“no”). The default is “yes”.
Save the file as ics.conf.
Restart Calendar Server.
cal-svr-base/SUNWics5/cal/sbin/start-cal
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.
Log in as an administrator with permission to change the configuration.
Stop Calendar Server services by issuing the stop-cal.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit one or more of the following ics.conf parameters shown in the following table:
Specifies the offset from the current time in days for get_freebusy for beginning of the range. The default is "30".
Specifies the offset from the current time in days for get_freebusy for end of the range. The default is "30".
Specifies whether a user's default calendar is included in user's free/busy calendar list. The default is "yes".
Specifies whether a user's default calendar can be removed from user's free/busy calendar list. The default is "no".
Save the file as ics.conf.
Restart Calendar Server.
cal-svr-base/SUNWics5/cal/sbin/start-cal
This section contains instructions on configuring LDAP users, groups and resources.
This section includes the following topics:
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit one or more of the following ics.conf parameters shown in the following table:
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.)
If "yes", allow users to change their passwords. The default is "no".
If "yes", allow users to have publicly writable calendars. The default is "yes".
Specifies whether a user's default calendar can be removed from the user's subscribed calendar list. The default is "no".
If "yes", allow calendars to be created by users who do not have administrative privileges. The default is "yes".
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".
Save the file as ics.conf.
Restart Calendar Server.
cal-svr-base/SUNWics5/cal/sbin/start-cal
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit one or more of the following ics.conf parameters shown in the following table:
If "yes", allow set_userprefs to modify the user preference "cn" (LDAP user's common name). The default is “no”.
If "yes", allow set_userprefs to modify the user preference "givenname" (LDAP user's given name). The default is “no”.
If "yes", allow set_userprefs to modify the user preference “icsCalendar" (a user's default calendar identifier). The default is “no”.
If "yes", allow set_userprefs to modify the user preference "mail" (user's email address). The default is “no”.
If "yes", allow set_userprefs to modify the user preference "preferredlanguage" (LDAP user's preferred language). The default is “no”.
If "yes", allow set_userprefs to modify the user preference "sn" (LDAP user's surname). The default is “no”.
If "yes", enables LDAP proxy authorization for get_userprefs. If "no", anonymous LDAP search is performed. The default is “no”.
Save the file as ics.conf.
Restart Calendar Server.
cal-svr-base/SUNWics5/cal/sbin/start-cal
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.
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit one or more of the following ics.conf parameters shown in the following table:
Owner attribute to use for groups and resources. The default is "owner".
Secondary owners attribute for groups and resources. The default is "icsSecondaryowners".
The attribute used to store the unique group identifier. The default is "groupid".
The attribute used to store the default ACL given to each group calendar at autoprovisioning. The default is "icsDefaultacl".
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".
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".
The attribute used to specify the time zone for an auto-created group calendar. The default is "icsTimezone".
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.)
Save the file as ics.conf.
Restart Calendar Server.
cal-svr-base/SUNWics5/cal/sbin/start-cal
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:
icsAllowRights — Set bit 15 to indicate your domain-level preference for group calendar doublebooking.
icsExtendedDomainPrefs — Set the groupdefaultacl property to determine the default ACL for group calendars in the domain.
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.
This section contains procedures for customizing server-side configuration by editing the ics.conf file.
This section contains the following topics:
The calendar store is configured by default as shown in The following table. If you wish to reconfigure the store, perform the following steps:
Log in as an administrator with permission to change the configuration.
Stop Calendar Server services using stop-cal.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
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". |
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". |
Save the file as ics.conf.
Restart Calendar Server.
cal-svr-base/SUNWics5/cal/sbin/start-cal
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
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". |
Save the file as ics.conf.
Restart Calendar Server.
cal-svr-base/SUNWics5/cal/sbin/start-cal
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.
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit one or more of the following ics.conf parameters as shown in following table:
Save the file as ics.conf.
Restart Calendar Server.
cal-svr-base/SUNWics5/cal/sbin/start-cal
Three types of email notifications can be enabled:
Send email notifications to attendees who are invited to an event.
Send email notifications to attendees when an event is cancelled.
Send email notifications to organizers when attendees reply.
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
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. |
Save the file as ics.conf.
Restart Calendar Server.
cal-svr-base/SUNWics5/cal/sbin/start-cal
For more information about configuring notifications, see E.4.1 Calendar Server Email Notifications Configuration Parameters and Format Files.
This section contains instructions for configuring logins and authentication.
This section contains the following topics:
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:
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit the parameter that follows:
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".
Restart Calendar Server for the new value to take effect.
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.
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit one or more of the parameters shown in the following table:
Parameter |
Description/Default |
---|---|
Base DN for LDAP authentication. If not specified, local.ugldapbasedn is used. |
|
Host for LDAP authentication. If not specified, uses the value of local.ugldaphost. The default is "localhost". |
|
Bind credentials (password) for user specified in 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. |
|
Port for LDAP authentication. If not specified, uses the value of local.ugldapport. The default is "389". |
|
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". |
|
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". |
|
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. |
|
Number of seconds to delay after successfully authenticating a user with plain text passwords. The default is "0". |
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit one or more of the parameters as shown in The following table:
Maximum number of authenticated user ID's (uids) and passwords that Calendar Server will maintain in the cache. The default is “10000”.
Number of seconds since the last access before a uid and password are removed from the cache. The default is “900”.
Save the file as ics.conf.
Restart Calendar Server.
cal-svr-base/SUNWics5/cal/sbin/start-cal
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit the following parameter as shown in the following table:
If "yes", when HTTP access is allowed, checks the client IP address against DNS. The default is “no”.
Save the file as ics.conf.
Restart Calendar Server.
cal-svr-base/SUNWics5/cal/sbin/start-cal
This section contains instructions on how to configure calendar services (daemons).
This section contains the following topics:
To Configure the Watcher Process for Calendar Server Version 6.3
To Configure HTTP Services (cshttpd) for Calendar Server Version 6.3
To Configure Alarm Notification for Calendar Server Version 6.3
See also, Chapter 9, Configuring Automatic Backups (csstored).
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.
Log in as an administrator with permission to change the configuration.
Stop Calendar Server services by issuing the stop-cal command.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit one or more of the parameters as shown in the following table:
Parameter |
Description and Default Value |
---|---|
Runtime user identifier (uid). The default is "icsuser". This is the user identifier to use when super-user privileges are not needed. |
|
Runtime group identifier (gid). The default is "icsgroup". This is the group identifier to use when super-user privileges are not needed. |
|
If this parameter is set to "yes", if a service that is connected to the watcher dies without properly disconnecting, it is automatically restarted. |
|
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. |
Save the file as ics.conf.
Restart Calendar Server.
cal-svr-base/SUNWics5/cal/sbin/start-cal
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:
Log in as an administrator with permission to change the configuration.
Stop Calendar Server services by issuing the stop-cal command.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit one or more of the parameters as shown in the following table:
Parameter |
Description and Default Value |
---|---|
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". |
|
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. |
|
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. |
Save the file as ics.conf.
Restart Calendar Server.
cal-svr-base/SUNWics5/cal/sbin/start-cal
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.
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".
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit one or more of the parameters as shown in the following table:
Parameter |
Description and Default Value |
---|---|
If "yes", start the csadmind database checkpoint thread. If "no", no checkpoint log files created. The default is "yes". |
|
Maximum cache size (in bytes) for Berkeley Database for administration sessions. The default is "8388608". |
|
If "yes", start the csadmind database deadlock detection thread. The default is "yes". |
|
If "yes", start the csadmind low disk space monitor thread. The default is "no". Disk usage is not monitored by default. |
|
If "yes", start the csadmind service when starting all services and stop csadmind when stopping all services. The default is “yes”. |
|
Maximum number of running threads per administration session. The default is “10”. |
|
Number of seconds before timing out an administration connection. The default is “900”. |
|
If "yes", start the csadmind service response thread. The default is “no”. |
|
Temporary directory for administration session requests. No default. |
|
Number of seconds before timing out an HTTP session in csadmind. The default is “1800”. |
|
Number of seconds to wait between checking for started, stopped, or ready calendar service. The default is “2”. |
|
Number of seconds to wait for any calendar service to start. The default is “300”. |
|
Number of seconds to wait for any calendar service to stop. The default is “300”. |
|
Number of seconds to wait between sending stop commands to any calendar service. The default is “60”. |
Save the file as ics.conf.
Restart Calendar Server.
cal-svr-base/SUNWics5/cal/sbin/start-cal
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit one or more of the parameters as shown in the following table:
Parameter |
Description and Default Value |
---|---|
Space separated list of user ID's with administration rights to this Calendar Server. The default is "calmaster". |
|
If "yes", allow login via proxy, which is the default. |
|
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". |
|
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. |
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". |
|
Maximum cache size of Berkeley database for HTTP sessions. The default is "8388308". |
|
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 (""). |
|
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 (" "). |
|
Directory location relative to local.queuedir (or an absolute path if specified) where imported files are temporarily stored. The default is the current directory ("."). |
|
If "yes", all requests that reference an existing session are verified as originating from the same IP address. The default is “yes”. |
|
If "yes", start the cshttpd service when starting all services and stop cshttpd when stopping all services. The default is “yes”. Caution – Disabling the HTTP service with this parameter will also disable HTTPS. |
|
Number of seconds before timing out an HTTP connection. The default is “120”. |
|
Specifies the TCP address that HTTP services will listen on for client requests. The default is "INADDR_ANY", which indicates any address. |
|
If "yes", HTTP connections to server are fully logged. The default is “no”. |
|
Maximum number of HTTP sessions in cshttpd service. The default is “5000”. |
|
Maximum number of threads to service HTTP requests in cshttpd service. The default is “20”. |
|
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. |
|
Port for HTTP requests from Calendar Server users. The default is “80”. |
|
If specified and not "", filter for allowing proxy login based on TCP domains. Same syntax as service.http.domainallowed. The default is "". |
|
Number of seconds before timing out an HTTP session. The default is “900”. |
|
Directory for the HTTP session database. The default is “http”. |
|
Number of seconds before timing out an HTTP session in cshttpd service. The default is “1800”. |
|
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”. |
Save the file as ics.conf.
Restart Calendar Server.
cal-svr-base/SUNWics5/cal/sbin/start-cal
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit one or more of the following ics.conf parameters as shown in the following table:
Save the file as ics.conf.
Restart Calendar Server.
cal-svr-base/SUNWics5/cal/sbin/start-cal
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.
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit the parameter shown in the following table:
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).
Save the file as ics.conf.
Restart Calendar Server.
cal-svr-base/SUNWics5/cal/sbin/start-cal
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.
This section contains instructions for configuring Calendar Server for LDAP.
This section contains the following topics:
To Configure Anonymous Access to LDAP for Calendar Server Version 6.3
To Configure LDAP Attendee Lookup for Calendar Server Version 6.3
To Configure Search Filters for LDAP Attendee Lookup for Calendar Server Version 6.3
To Configure LDAP Resource Lookup for Calendar Server Version 6.3
To Configure LDAP Mail-to-Calid Lookup for Calendar Server Version 6.3
To Configure the User Preferences LDAP Directory for Calendar Server Version 6.3
To Configure User Preferences for Calendar Server Version 6.3
To Enable and Configure the LDAP Data Cache for Calendar Server Version 6.3
To Enable and Configure the LDAP SDK Cache for Calendar Server Version 6.3
To Set the Date Range for Free Busy Searches for Calendar Server Version 6.3
To Enable Wildcard LDAP Searches of Calendar Properties 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.
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
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. |
Save the file as ics.conf.
Restart Calendar Server.
cal-svr-base/SUNWics5/cal/sbin/start-cal
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit one or more of the parameters in the following table:
Parameter |
Description/Default |
---|---|
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. |
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". |
Save the file as ics.conf.
Restart Calendar Server.
cal-svr-base/SUNWics5/cal/sbin/start-cal
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit one or more of the parameters in the following table:
In all the parameter descriptions that follow, %s allows only a single attendee.
Save the file as ics.conf.
Restart Calendar Server.
cal-svr-base/SUNWics5/cal/sbin/start-cal
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit the parameter shown in the following table:
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”.
Save the file as ics.conf.
Restart Calendar Server.
cal-svr-base/SUNWics5/cal/sbin/start-cal
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
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. |
Save the file as ics.conf.
Restart Calendar Server.
cal-svr-base/SUNWics5/cal/sbin/start-cal
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit one or more of the parameters in the following table:
Parameter |
Description/Default |
---|---|
Bind credentials (password) for LDAP user preferences authentication. No default. |
|
DN used to bind to LDAP user preferences host. Must be specified. If blank (" ") or not specified, assumes an anonymous bind. |
|
Minimum number of LDAP client connections that are maintained for LDAP user preferences. The default is “1”. |
|
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. |
Save the file as ics.conf.
Restart Calendar Server.
cal-svr-base/SUNWics5/cal/sbin/start-cal
You can restrict the preferences users are allowed to set by removing them from the default list.
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit the list of user preferences in the parameter shown in the following table:
Parameter |
Default List of User Preferences |
Description |
---|---|---|
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. |
Save the file as ics.conf.
Restart Calendar Server.
cal-svr-base/SUNWics5/cal/sbin/start-cal
For overview information about the LDAP Data Cache, see 1.7 LDAP Data Cache Option for Calendar Server Version 6.3.
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Enable the LDAP data cache by editing the parameter as shown in the following table:
Save the file as ics.conf.
Restart Calendar Server.
cal-svr-base/SUNWics5/cal/sbin/start-cal
For information about tuning the LDAP data cache, see 21.5 Improving Performance of the LDAP Data Cache.
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.
The LDAP SDK cache is disabled by default.
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Editing one or more of the parameters as shown in the following table:
If "yes", enables LDAP SDK cache. The default is “no”.
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”.
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”.
Save the file as ics.conf.
Restart Calendar Server.
cal-svr-base/SUNWics5/cal/sbin/start-cal
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit one or more of the following parameters as shown in the following table:
Specifies the offset from the current time in days for get_freebusy for beginning of the range. The default is “30”.
Specifies the offset from the current time in days for get_freebusy for end of the range. The default is “30”.
Save the file as ics.conf.
Restart Calendar Server.
cal-svr-base/SUNWics5/cal/sbin/start-cal
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit the parameter as shown in the following table:
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.
Save the file as ics.conf.
Restart Calendar Server.
cal-svr-base/SUNWics5/cal/sbin/start-cal
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.
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit one of the parameters as shown in the following table:
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.
Root suffix of the DIT (Organization Tree) for Schema version 2. No default value.
Save the file as ics.conf.
Restart Calendar Server:
cal-svr-base/SUNWics5/cal/sbin/start-cal
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.
You must run the same version of Calendar Server on both the front-end and back-end servers.
This chapter contains the following topics:
5.1 CLD Plug-in Background Information for Calendar Server Version 6.3
5.3 Maintaining Security Between Front-End and Back-End Servers for Calendar Server Version 6.3
For information on how to improve the performance of the CLD plug-in, see Chapter 21, Tuning Calendar Server Performance.
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.2 How the CLD Plug-in Works for Calendar Server Version 6.3
5.1.3 Configurations Supported by the CLD Plug-in for Calendar Server Version 6.3
5.1.4 Simple Sizing Exercise for Calendar Server 6.3 Storage Requirements
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.
Calendar Server accesses calendar data on a back-end server as follows:
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.
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.
Using the host name, Calendar Server accesses the calendar data on the back-end server using the Database Wire Protocol (DWP).
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.
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.
This section contains overview material about the CLD Plug-in.
The CLD plug-in supports the following Calendar Server configurations:
In all configurations, each front-end and back-end server must:
Be on the same hardware platform.
Be running the same operating system.
Be running the same Calendar Server release, including patches.
Use the same port number for the DWP port (service.dwp.port parameter). The default port number is “59779”.
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–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.
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:
For our rough estimates, we are assuming the following:
All clients are Web clients.
Therefore, the only inputs to be used are: total number of users, and percent concurrency.
The average size calendar event size is 5K.
Each person creates ten events or todos per week.
80% CPU utilization.
900 MHz CPU's.
1 GB RAM per CPU.
Two years' worth of calendar data stored on system.
Six hot backup copies held in storage.
The formula is:
Number of CPU's = Number of Concurrent Users divided by 4800
The formula is:
Number of CPU's = 4 CPU's per 500,000 configured users
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.
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.
This sections contains instructions for configuring servers for CLD and DWP.
This section contains the following topics:
On every front-end server, log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit the ics.conf parameters as shown in the following list:
Description
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.
Set this parameter to "yes".
Set this parameter to the name of the plug-in,"calendarlookup". Or, to load all plug-ins, set the parameter to "*".
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).
Disable DWP service for the front-end, unless it is also serving as a back-end machine. For example: service.dwp.enable="no"
The default port is “59979”. This port number must be the same for all front-end and back-end servers.
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").
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"
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"
The hostname where the Directory Server is installed. The default is "localhost".
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.
Disable ENS (enpd) for this front-end server, set this parameter to "no".
ENS must be enabled only on the back-end servers.
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.
To disable the alarm dispatcher, set this parameter to "no".
The alarm dispatcher should be enabled ("yes") only on the back-end servers.
To disable the notify service, set this parameter to "no".
The notify service should be enabled ("yes") only on back-end servers.
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.
The automatic hot backup service should be disabled (value set to "no"). There is no need for hot backups on a front-end machine.
Save the file as ics.conf.
Restart Calendar Server.
cal-svr-base/SUNWics5/cal/sbin/start-cal
On every back-end server, log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit the ics.conf parameters as shown in the following table:
Description
Set this parameter to "no".
There is no need for HTTP on a back-end server.
Enable the administration service (csadmind) by setting the parameter to "yes", which is the default.
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".
Set this parameter to "no".
There is no need for a plug-in on a back-end server.
Enable DWP by setting this parameter to "yes"
The default port is “59979”. This port number must be the same for all front-end and back-end servers.
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"
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"
The hostname where the Directory Server is installed. The default is "localhost".
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.
To enable ENS (enpd) for this back-end server, set this parameter to "yes".
Server alarms must be enabled ("1") on the back-end servers.
Save the file as ics.conf.
Restart Calendar Server.
cal-svr-base/SUNWics5/cal/sbin/start-cal
On every server, log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit the ics.conf parameters as shown in the following table:
Description
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.
Set this parameter to "yes".
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".
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).
Enable DWP by setting this parameter to "yes"
The default port is “59979”. This port number must be the same for all front-end and back-end servers.
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"
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"
The hostname where the Directory Server is installed. The default is “localhost”(on the same server as the front-end).
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.
Enable ENS by setting this parameter value to "yes".
Server alarms must be enabled ("1") on the back-end servers.
The alarm dispatcher should be enabled ("yes") on the back-end servers.
The notify service should be enabled ("yes") on back-end servers.
The automatic archive backup service should be enabled (value set to "yes"on the back-end systems.
The automatic hot backup service should be enabled (value set to "yes"on the back-end systems.
Save the file as ics.conf.
Restart Calendar Server.
cal-svr-base/SUNWics5/cal/sbin/start-cal
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
To Set Up Authentication for DWP Connections for a Front-end Server in Calendar Server Version 6.3
To Set up Authentication for DWP Connections for a Back-end Server 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.
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.
On every front-end server, log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Add the ics.conf parameters as shown in the following list:
Description
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.
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.
Save the file as ics.conf.
Restart Calendar Server.
cal-svr-base/SUNWics5/cal/sbin/start-cal
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.
On every back-end server, log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Add the ics.conf parameters as shown in the following table:
Description
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.
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.
Save the file as ics.conf.
Restart Calendar Server.
cal-svr-base/SUNWics5/cal/sbin/start-cal
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:
6.1 Overview of High Availability Choices for Calendar Server Version 6.3
6.2 Prerequisites for an HA Environment for Your Calendar Server Version 6.3 Deployment
6.7 Configuring a Symmetric High Availability Calendar Server System
6.11 Example Output from the Calendar Configuration Program (Condensed)
You can find a set of worksheets to help you plan a Calendar Server HA configuration in the Appendix C, Calendar Server Configuration Worksheet.
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
6.1.2 Understanding Symmetric High Availability for Calendar Server Version 6.3
6.1.4 Choosing a High Availability Model for Your Calendar Server Version 6.3 Deployment
6.1.5 System Down Time Calculations for High Availability in Your Calendar Server 6.3 Deployment
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.
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
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.
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.
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.
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
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 |
This sections lists the prerequisites for installing Calendar Server in an HA environment.
The following prerequisites apply:
Either the Solaris 9 or the Solaris 10 operating system must be installed on all nodes of the cluster, with required patches
Sun Cluster 3.0 or 3.1 must be installed on all nodes of the cluster
Calendar Server HA Agents package (SUNWscics) must be installed on all nodes of the cluster using the Java Enterprise System installer
Specify local file systems as HAStoragePlus Failover File System (FFS) systems, or HAStorage Cluster File System (CFS)
If you have a version of Sun Cluster 3.0 dated December 2001 or earlier, you must use the global file system, specified as a HAStorage Cluster File System (CFS).
If logical volumes are being created, which is true for the symmetric high availability system, use either Solstice DiskSuite or Veritas Volume Manager.
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:
HAStoragePlus bypasses the global file service layer completely. For data services requiring an intensive number of disk accesses, this leads to a significant performance increase.
HAStoragePlus can work with any file system (like UFS, VxFS, and so forth), even those that might not work with the global file service layer. If a file system is supported by the Solaris operating system, it will work with HAStoragePlus.
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.
The following is a list of the tasks necessary to install and configure Calendar Server for Asymmetric High Availability:
Prepare the nodes.
Install the Solaris Operating System software on all nodes of the cluster.
Install Sun Cluster software on all nodes of the cluster.
Install the Calendar Server HA Agents package, SUNWscics, on all nodes of the cluster using the Java Enterprise System installer
Create a file system on the shared disk.
Install Calendar Server on the Primary and Secondary nodes of the cluster, using the Communications Suite 5 installer.
Run the Directory Preparation Script, comm_dssetup.pl on the machine where the Directory Server LDAP directory resides.
Installing and configuring the first (primary) node.
Using the Sun Cluster command-line interface, set up HA on the primary node.
Run the Calendar Server configuration program, csconfigurator.sh, on the primary node.
Using the Sun Cluster command-line interface, switch to the secondary node.
Create a symbolic link from the Calendar Server config directory on the primary node to the shared disk config directory.
Install and configure the second (secondary) node.
Run the Calendar Server configuration program on the secondary node by reusing the state file created when you configured the primary node.
Edit the Configuration File, ics.conf.
Using the Sun Cluster command-line interface, configure and enable a resource group for Calendar Server.
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.
The following is a list of the tasks necessary to install and configure Calendar Server for Symmetric High Availability:
Prepare the nodes.
Install the Solaris Operating System software on all nodes of the cluster.
Install Sun Cluster software on all nodes of the cluster.
Create six file systems, either Cluster File Systems (Global File systems) or Fail Over File Systems (Local File systems).
Create the necessary directories.
Install the Calendar Server HA Agents package, SUNWscics, on all nodes of the cluster using the Java Enterprise System installer
Install and Configure the first node.
Using the Communications Suite 5 installer, install Calendar Server on the first node of the cluster.
Run the Directory Preparation Script, comm_dssetup.pl, on the machine where the Directory Server LDAP database resides.
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.
Using the Sun Cluster command-line interface, configure HA on the first node.
Run the Calendar Server configuration program, csconfigurator.sh, on the first node.
Using the Sun Cluster command-line interface, fail over to the second node.
Edit the Configuration File, ics.conf, on the first node.
Using the Sun Cluster command-line interface, configure and enable a resource group for Calendar Server on the first node.
Using the Sun Cluster command-line interface, create and enable a resource group for the first node.
Using the Sun Cluster command-line interface to test the successful creation of the resource group, perform a fail over to the first node.
Install and configure the second node.
Using the Communications Suite 5 installer, install Calendar Server on the second node of the cluster.
Using the Sun Cluster command-line interface, configure HA on the second node.
Run the Calendar Server configuration program, csconfigurator.sh, on the second node by reusing the state file created when you configured the first node.
Using the Sun Cluster command-line interface, fail over to the first node.
Edit the Configuration File, ics.conf, on the second node.
Using the Sun Cluster command-line interface, create and enable a resource group for Calendar Server on the second node.
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.
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
Table 6–4 Directory Name Variables Used in Symmetric Examples
Table 6–5 Resource Name Variables for Asymmetric Examples
Table 6–6 Resource Name Variables for Symmetric Examples
Table 6–7 Variable Name for IP Address in Asymmetric Examples
Table 6–8 Variable Name for IP Address in Symmetric 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" |
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
6.6.3 Installing and Configuring High Availability for Calendar Server 6.3 Software
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
The fields in these commands are separated by tabs, not just spaces.
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
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:
Install Calendar Server on the Primary and Secondary nodes of the cluster, using the Communications Suite 5 installer.
Be sure to specify the same installation root on all nodes.
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).
Choose the Configure Later option.
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
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.
Use the Sun Cluster command line interface as indicated to set up HA on the first node.
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.
Register the Calendar Server and HAStoragePlus resource
./scrgadm -a -t SUNW.HAStoragePlus ./scrgadm -a -t SUNW.scics
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
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
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
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.
At the Run Time Configuration panel, deselect both Calendar Server startup options.
At the Directories panel, configure all directories on a shared disk. Use the following locations:
/share-disk-dir/config
/share-disk-dir/csdb
/share-disk-dir/store
/share-disk-dir/logs
/share-disk-dir/tmp
Once you have finished specifying the directories, choose Create Directory.
At the Archive and Hot Backup panel, specify the following choices:
/share-disk-dir/csdb/archive
/share-disk-dir/csdb/hotbackup
When you have finished specifying the directories, choose the Create Directory option.
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)
Click Next to finish configuration.
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
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 .
Do not forget the dot (.) at the end of the ln command.
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.
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.
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"
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
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.
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.2 Installing and Configuring the First Instance of Calendar Server
6.7.3 Installing and Configuring the Second Instance of Calendar Server
There are two preparatory tasks that must be completed before installing Calendar Server on the nodes.
The preparatory tasks are as follows:
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:
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
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
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.
Follow the instructions in this section to install and configure the first instance of Calendar Server. This section covers the following topics:
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
Using the Sun Java Systems Communications Suite installer, install Calendar Server on the Primary Node.
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.
Choose Configure Later.
Run the Directory Preparation Tool script on the machine with the Directory Server.
Using the Sun Cluster command-line interface, configure Sun Cluster on the first node by performing the following steps:
Register the following resource types:
./scrgadm -a -t SUNW.HAStoragePlus ./scrgadm -a -t SUNW.scics
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
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"
Bring the resource group online.
scswitch -Z -g CAL-CS1-RG
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"
Enable the HAStoragePlus resource.
./scswitch -e -j CAL-HASP-CS1-RS
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.
On the Runtime Configuration panel, deselect both of the Calendar Server start up options.
On the Directories to Store Configuration and Data Files panel, provide the shared disk directories as shown in the following list:
/share-disk-dirCS1/config
/share-disk-dirCS1/csdb
/share-disk-dirCS1/store
/share-disk-dirCS1/logs
/share-disk-dirCS1/tmp
When you have finished specifying the directories, choose Create Directory.
On the Archive and Hot Backup panel, provide the shared disk directory names as shown in the following list:
/share-disk-dirCS1/csdb/archive
/share-disk-dirCS1/csdb/hotbackup
After specifying these directories, choose Create Directory.
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).
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
Edit the configuration file, ics.conf, by adding the parameters shown in the example that follows.
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"
The expected value for service.http.calendarhostname is a fully qualified hostname.
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
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
The primary node for the second Calendar Server instance is the second node (Node2).
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
Using the Sun Java Systems Communications Suite installer, install Calendar Server on the new Primary Node (second node).
Using the Sun Cluster command-line interface, configure the second instance of Calendar Server as described in the following steps:
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
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"
Bring the resource group online.
scswitch -Z -g CAL-CS2-RG
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"
Enable the HAStoragePlus resource.
./scswitch -e -j CAL-HASP-CS2-RS
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.
On the Runtime Configuration panel, deselect both of the Calendar Server start up options.
On the Directories to Store Configuration and Data Files panel, provide the proper directories as shown in the following list:
share-disk-dirCS2/config
/share-disk-dirCS2/csdb
/share-disk-dirCS2/store
/share-disk-dirCS2/logs
/share-disk-dirCS2/tmp
When you have finished specifying the directories, choose Create Directory.
On the Archive and Hot Backup panel, provide the appropriate directory names as shown in the following list:
/share-disk-dirCS2/csdb/archive
/share-disk-dirCS2/csdb/hotbackup
After specifying these directories, choose Create Directory.
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).
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
Edit the configuration file, ics.confby adding the parameters shown in the example that follows.
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"
The value for service.http.calendarhostname must be a fully qualified hostname.
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
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.
Use the following commands to start, fail over, disable, remove, and restart the Calendar Server HA service:
# scswitch -e -j CAL-SVR-RS
# scswitch -z -g CAL-RG -h Node2
# scswitch -n -j CAL-SVR-RS
# scrgadm -r -j CAL-SVR-RS
# scrgadm -R -j CAL-SVR-RS
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.
Become a superuser.
All of the following Sun Cluster commands require that you be running as a superuser.
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 |
Disable the individual resources.
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 |
Remove the resource group itself using the command:
# scrgadm -r -g CAL-RG |
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 |
The Calendar Server Sun Cluster agents use two different API's to log messages:
scds_syslog_debug() — Used by Calendar Server agents. Messages are logged at daemon.debug level.
scds_syslog() — Used by Calendar Server agents and Sun Cluster data services. Messages are logged at daemon.notice, daemon.info, and daemon.errorlevels.
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.
Create a logging directory for Calendar Server agents.
mkdir -p /var/cluster/rgm/rt/SUNW.scics
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
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.
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.
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.
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:
Sun Cluster Concepts Guide for Solaris OS provides a general background about Sun Cluster software, data services, and terminology resource types, resources, and resource groups.
Sun Cluster Data Services Planning and Administration Guide for Solaris OS provides general information on planning and administration of data services.
Sun Cluster System Administration Guide for Solaris OS provides the software procedures for administering a Sun Cluster configuration.
Sun Cluster Reference Manual for Solaris OS describes the commands and utilities available with the Sun Cluster software, including commands found only in the SUNWscman and SUNWccon packages.
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:
Calendar Server does not support client-based SSL authentication.
This section contains instructions for configuring SSL for Calendar Server.
This section contains the following topics:
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:
Issues (creates and signs) certificates.
Maintains certificate status information and issues CRL.
Publishes its current (unexpired) certificates and CRLs
Maintains archives of status information about the expired certificates.
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 create the certificate database, familiarize yourself with the following:
Mozilla Tools
This release includes the following Mozilla tools:
Certificate Database Tool (certutil) to create and manage the certificate database. For information, refer to the following Web site:
http://mozilla.org/projects/security/pki/nss/tools/certutil.html
Familiarize yourself with the tool syntax before attempting to generate your certificate database.
Security Module Database Tool (modutil) to display information about available security modules. For information, refer to the following Web site:
http://mozilla.org/projects/security/pki/nss/tools/modutil.html
These utilities are available in the following directory:
/opt/SUNWics5/cal/lib
You can also download the most recent version from the Web site.
Library Path Variable
Before you use the Mozilla tools, set your LD_LIBRARY_PATH variable appropriately. For example:
setenv LD_LIBRARY_PATH /opt/SUNWics5/cal/lib
Example Files and Directories
The examples in this chapter use these files and directories:
/etc/opt/SUNWics5/config is the directory that contains the certificate database.
Backup the certificate database regularly. You can choose to create the certificate database in another directory. If you do, you must also place the certificate password file in the same directory.
sslpassword.conf is a text file that contains the certificate database password.
After Calendar Server is set up for SSL, Calendar Server requires the sslpassword.conf file to start up in SSL mode. The certutil utility uses a different password file. Create sslpassword.conf in the following directory:
/etc/opt/SUNWics5/config
The file at /etc/passwd introduces entropy for random number generation, that is, this directory is used to generate varied and unique seeds that help ensure truly random results from the random number generator.
Log in as or become superuser (root).
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.
Create the certificate database directory. For example:
# cd /var/opt/SUNWics5 # mkdir alias |
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 |
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.
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 |
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.
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 |
List the certificates. For example:
# ./certutil -L -d /etc/opt/SUNWics5/config # ./certutil -L -n SampleSSLServerCert -d /etc/opt/SUNWics5/config |
Use modutil to list the available security modules (secmod.db). For example:
# ./modutil -list -dbdir /etc/opt/SUNWics5/config |
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 {}; |
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
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.
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.
Log in as or become superuser (root).
Move to the bin directory:
# cd /opt/SUNWics5/cal/bin
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.
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.
Copy the Certificate Authority Certificate Chain and SSL server certificate into text files.
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 |
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 |
List the certificates in the certificate database:
# ./certutil -L -d /etc/opt/SUNWics5/config
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
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.
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
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" |
Save the file as ics.conf.
Restart Calendar Server for the changes to take effect.
cal-svr-base/SUNWics5/cal/sbin/start-cal
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.
If you have problems with SSL, here are some things to consider:7.2.1 Checking for the cshttpd Process
7.2.5 Making cshttpd Stop Listening on the Regular HTTP Port
SSL requires the Calendar Server cshttpd process to be running. To determine if cshttpd is running, use this command:
# ps -ef | grep cshttpd
To list the certificates in the certificate database and checking their validity dates, use this command:
# ./certutil -L -d /etc/opt/SUNWics5/config
Check the Calendar Server log files for any SSL errors.
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.
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.
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.
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:
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.
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.
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.
When you set the local.calendar.sso.amnamingurl parameter, you must use a fully qualified host name for where Access Manager software is installed.
To configure SSO for Messaging Server, refer to the Sun Java System Messaging Server 6.3 Administration Guide.
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.)
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“. |
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.
This section lists some considerations for using Single Sign-on (SSO) with Access Manager.
The following are some of the considerations:
A calendar session is valid only as long as the Access Manager session is valid. If a user logs out of Access Manager, the calendar session is automatically closed (single sign-off).
SSO applications must be in the same domain.
SSO applications must have access to the Access Manager verification URL (naming service).
Browsers must support cookies.
If you are using the Sun Java System Portal Server gateway, set the following Calendar Server parameters:
service.http.ipsecurity="no"
render.xslonclient.enable="no"
When configuring SSO through Communications Servers trusted circle technology (that is, not through Access Manager), consider these points:
Each trusted application must be configured for SSO.
SSO does not work correctly if the default.html page is in your browser’s cache. Before using SSO, be sure to reload the default.html page in your browser. For example, in Netscape Navigator, hold down the Shift key and then click Reload.
SSO works only for bare URL's. For example, SSO works for:http://servername.
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
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
For more information about configuring Messaging Server for SSO, see the Sun Java System Messaging Server 6.3 Administration Guide.
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.
9.2 Overview of Automatic Backups in a Calendar Server 6.3 System
9.3 Setting up Transaction Log Files for Calendar Server 6.3 Backups
9.4 Specifying the Calendar Server Administrator’s Email Address
9.6 Enabling Archive Backups for Calendar Server 6.3 Databases
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.
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. |
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
9.2.2 How csstored Works for Backups in a Calendar Server 6.3 System
9.2.3 How Circular 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.
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.
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.
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.
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
9.4 Specifying the Calendar Server Administrator’s Email Address
9.6 Enabling Archive Backups for Calendar Server 6.3 Databases
This section contains both overview and instructions for setting up transaction log files.
This section covers the following topics:
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.
At a command line, change to the directory where the ics.conf is located:
cd /etc/opt/SUNWics5/config
Specify the transaction log name:
logfile.store.logname=storename.log
Specify the directory path for the transaction log directory:
The default value is: logfile.logdir="logs"
When you have completed editing the ics.conf file, restart Calendar Server:
cal-svr-base/SUNWics5/cal/sbin/start-cal
This section contains overview and instructions for setting the Calendar Server administrator's email address.
This section covers the following topics:
When certain events or errors occur, the administrator is notified by email.
The events causing an email message to be generated are:
Automatic backups not enabled or not configured properly.
Every 24 hours, when its time to take a snapshot, if automatic backups are not enabled, the csstored process reports that automatic backups are not properly configured.
The disk space threshold has been exceeded.
This message is sent out periodically until the condition has cleared.
A service has stopped and can’t be restarted.
The notification email will explain what required action is needed before the service can be started.
Log in as an administrator with permission to change the configuration.
Stop Calendar Server services by issuing the stop-cal command.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit the ics.conf parameter that follows to specify the administrator’s email address:
alarm.msgalarmnoticercpt="admin@email_address"
Save the file as ics.conf.
Restart Calendar Server.
cal-svr-base/SUNWics5/cal/sbin/start-cal
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:
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.
Log in as an administrator with permission to change the configuration.
Stop Calendar Server services by issuing the stop-cal command.
At a command line, change to the directory where the ics.conf is located:
cd /etc/opt/SUNWics5/config
Enable hot backups by setting the following ics.conf parameter to "yes":
caldb.berkeleydb.hotbackup.enable="yes"
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.
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).
When you have completed editing the ics.conf file, restart Calendar Server:
cal-svr-base/SUNWics5/cal/sbin/start-cal
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:
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.
Log in as an administrator with permission to change the configuration.
Stop Calendar Server services by issuing the stop-cal command.
At a command line, change to the directory where the ics.conf is located:
cd /etc/opt/SUNWics5/config
Enable archive backups by setting the following ics.conf parameter to “yes”:
caldb.berkeleydb.archive.enable=”yes”
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).
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.
This chapter contains overview material and instructions on how to set up a multiple domain environment for the first time.
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
10.2 Setting up a Multiple Domain Environment for Calendar Server Version 6.3 for the First Time
10.3 How the Multiple Domains Feature in Calendar Server Version 6.3 Influences Your Schema Choices
10.4 Additional Parameters Required for Multiple Domain Mode in Calendar Server Version 6.3
10.6 Migrating from a Non-Domain Environment 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:
You can choose to move to a single default domain mode.
In which case, you must move your user and group records under the domain node in LDAP.
You can choose to move to a multiple domain mode and distribute the users and groups amongst multiple domains.
Use Delegated Administrator to create more domains.
If you wish to distribute your existing users into multiple domains, you need to run the migration utilities to add fully qualified domain names to your database user IDs and calendar IDs. This way you can distribute your users among the domains you created with Delegated Administrator. Create the domains before you run the configuration program.
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.
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.
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:
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.
Run the comm_dsseetup.pl if you have not already done so.
Log in as an administrator with permission to change the configuration.
Stop Calendar Server services by issuing the stop-cal command.
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 |
---|---|
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”. |
|
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". |
if local.schemaversion="2", specifies the root suffix of the Organization Tree, underneath which all domains are found. For example: "o=sesta.com". |
|
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". |
|
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 "@+". |
|
Specifies the user ID of the domain administrator. For example: DomainAdmin@sesta.com. |
|
Controls cross domain searching:
|
|
Specifies the language for the domain. Default is "en" (English). |
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
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
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
Add calendar (and mail, if wanted) services for the new domains.
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
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
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:
Perform an LDAP dump of the existing calmaster LDAP entry and save it in a temporary file, such as /tmp/calmaster.ldif.
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
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.
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.
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.2 Sun LDAP Schema Version 2 for Calendar Server Version 6.3
10.3.3 Sun LDAP Schema Version 1 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:
You already have Schema version 1 and you are not planning on using Delegated Administrator for populating LDAP.
You already have Schema version 1 and you are not planning to use Access Manager features.
The following graphic shows an LDAP directory organization for a multiple domain installation that uses Sun LDAP Schema version 2.
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).
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:
DC tree
Organization (OSI) tree
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.
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:
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.
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.
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
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 "1" |
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 |
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.
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.
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
11.3 Using Domains Created by Messaging Server 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.
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.
You can change the default access control permissions for groups at various levels.
This section covers the following group ACL topics:
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.
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.
To change the default ACL for a specific group, edit the group LDAP entry. Change the value of the icsDefaultacl attribute.
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:
Each domain can specify an access control list (ACL) in the domainAccess property of the icsExtendedDomainPrefs attribute that grants or denies cross domain searches from other domains. Thus, a domain can allow or disallow either specific domains, or all domains, from searching it.
To specify more than one domain, supply a semicolon separated list of domain names for the value of the domainAccess property.
There can be only one instance of the domainAccess property in an LDAP domain entry. If you use LDAP tools to add ACLs to a domain entry, you must ensure that you are not inadvertently creating a duplicate of the domainAccess property.
For a description of domainAccess, see D.9.3 LDAP Attributes and Property Names. For general information about ACLs, see 1.8.3 Access Control Lists (ACLs) in Calendar Server Version 6.3.
Each domain can specify the external domains its users can search. The icsDomainNames LDAP attribute specifies the external domains that a domain’s users can search when looking for users and groups (as long as the ACL for the external domain allows the search).
For example, if icsDomainNames for the various.org domain lists sesta.com and siroe.com, users in various.org can perform cross domain searches in sesta.com and siroe.com. For a description of icsDomainNames, see D.9.3 LDAP Attributes and Property Names.
For instructions on how to enable cross domain searches, see 13.3 Enabling Cross Domain Searches.
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.2 Adding Calendar Services to Messaging Domains in Schema 2 Mode in 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:
Object class: icsCalendarDomain.
Attribute:icsStatus. Set the value to “active”.
Attribute: icsExtendedDomainPrefs. Set the value of the domainAccess attribute option to the ACL you want to use for access control.
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 |
If Messaging Server is in Schema version 2 mode, perform the following two steps to add calendar services to the existing domains:
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.
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.