Sun Java System Calendar Server 6 2005Q4 Administration Guide

Part III Customizing Your Calendar Server Configuration

Chapter 5 Customizing Calendar Server

After installation and postinstallation configuration, Calendar Server can be run as is. However, you can customize, or reconfigure, your system by editing the configuration file, ics.conf.

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 ics.conf in the following directory:

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

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


Note –

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


This chapter describes the following topics:


Note –

Additional configuration topics are covered in other, separate chapters. They include the following topics:


Configuring for Communications Express

Communications Express requires the following things to be configured in the Calendar Server:

ProcedureTo Configure Proxy Authentication

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

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

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

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

    Parameters  

    Description and Default Value  

    service.http.allowadminproxy

    Enables administrator proxy authentication when set to “yes”. The default is “no”.

    service.http.admins

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

    service.admin.calmaster.userid

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

    service.admin.calmaster.cred

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


    Note –

    The uwcconfig.properties file is located in the comms_express_svr_base/WEB-INF/config directory, where comm_express_svr_base is the directory where Communications Express was installed.


  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal_svr_base/SUNWics5/cal/sbin/start-cal

See Also

For instructions on configuring Communications Express, see the.

ProcedureTo Enable Anonymous Access

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

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

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

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

    Parameters 

    Description and Default Value  

    service.wcap.anonymous.

    allowpubliccalendarwrite

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

    service.wcap.allowpublicwritablecalendars

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

    service.http.allowanonymouslogin

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

    service.calendarsearch.ldap

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


    Note –

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


  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal_svr_base/SUNWics5/cal/sbin/start-cal

    For instructions on configuring Communications Express, see theSun Java System Communications Express 6 2005Q4 Administration Guide.

Configuring Calendars

ProcedureTo Configure User Calendars

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

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

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

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

    Parameter 

    Description and Default Value  

    calstore.calendar.default.acl

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

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

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

    calstore.calendar.owner.acl

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

    calstore.freebusy.include.defaultcalendar

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

    calstore.freebusy.remove.defaultcalendar

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

    service.wcap.freebusy.redirecturl

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

    calstore.subscribed.include.

    defaultcalendar

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

    service.wcap.login.calendar.publicread

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

    user.allow.doublebook

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

    • "no" prevents double booking.

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

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

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

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal_svr_base/SUNWics5/cal/sbin/start-cal

ProcedureTo Configure Resource Calendars

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

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

    Parameter  

    Description and Default Value  

    resource.allow.doublebook

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

    • "no" prevents double booking.

    • "yes" allows double booking.

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

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

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

    resource.default.acl

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

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

  3. Save the file as ics.conf.

  4. Restart Calendar Server.

    cal_svr_base/SUNWics5/cal/sbin/start-cal

ProcedureTo Disable Autoprovisioning of User Calendars at Login

Autoprovisioning of user calendars is enabled by default.

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

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

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

  4. Disable autoprovisioning of user calendars upon first login editing the following parameter:

    Parameter  

    Description and Default Value  

    local.autoprovision

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

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal_svr_base/SUNWics5/cal/sbin/start-cal

ProcedureTo Configure Free-Busy Lookup

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

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

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

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

  4. Disable autoprovisioning of user calendars upon first login editing the parameter shown in the following table:

    Parameter  

    Description and Default Value  

    service.wcap.freebusybegin

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

    service.wcap.freebusyend

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

    calstore.freebusy.include.defaultcalendar

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

    calstore.freebusy.remove.defaultcalendar

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

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal_svr_base/SUNWics5/cal/sbin/start-cal

Configuring Calendar Users

This section contains instructions on configuring calendar users and includes the following topics:

ProcedureTo Configure Users

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

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

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

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

    Parameters  

    Description and Default Value  

    service.wcap.allowchangepassword

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

    service.wcap.allowpublicwritablecalendars

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

    calstore.subscribed.remove.defaultcalendar

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

    service.wcap.allowcreatecalendars

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

    service.wcap.allowdeletecalendars

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

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal_svr_base/SUNWics5/cal/sbin/start-cal

ProcedureTo Set User Preferences

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

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

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

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

    Parameters  

    Description and Default Value  

    service.wcap.allowsetprefs.cn

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

    service.wcap.allowsetprefs.givenname

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

    service.wcap.allowsetprefs.icsCalendar

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

    service.wcap.allowsetprefs.mail

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

    service.wcap.allowsetprefs.

    preferredlanguage

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

    service.wcap.allowsetprefs.sn

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

    service.wcap.userprefs.ldapproxyauth

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

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal_svr_base/SUNWics5/cal/sbin/start-cal

Configuring Calendar Server

This section contains procedures for customizing server-side configuration by editing the ics.conf file, and contains the following topics:

ProcedureTo Configure Server Behavior

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

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

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

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

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

    Parameter  

    Description 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 attendees allowed in an LDAP group when expanding an event. Value of "0" (the default value) means to expand the group entirely.

    calstore.recurrence.bound

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

    calstore.userlookup.maxsize

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

    calstore.unqualifiedattendee.fmt1.type

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

    calstore.unqualifiedattendee.fmt2.type

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

    calstore.unqualifiedattendee.fmt3.type

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

    service.wcap.validateowners

    If "yes", the server must validate that each owner of a calendar exists in the directory (through LDAP or a CSAPI compatible user directory mechanism). 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 2005Q4 Developer’s Guide.

    store.partition.primary.path

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

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal_svr_base/SUNWics5/cal/sbin/start-cal

ProcedureTo Configure Calendar Logging

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

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

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

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

    Parameter 

    Description and Default Value  

    logfile.admin.logname

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

    logfile.buffersize

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

    logfile.dwp.logname

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

    logfile.expirytime

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

    logfile.flushinterval

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

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

    logfile.http.logname

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

    logfile.http.access.logname

    Name of the current HTTP access log file. 

    logfile.logdir

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

    logfile.loglevel

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

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

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

    logfile.maxlogfiles

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

    logfile.maxlogfilesize

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

    logfile.minfreediskspace

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

    logfile.notify.logname

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

    logfile.rollovertime

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

    logfile.store.logname

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

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal_svr_base/SUNWics5/cal/sbin/start-cal

See Also

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

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

ProcedureTo Configure WCAP Commands

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

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

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

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

    Parameter 

    Description and Default Value 

    service.wcap.format

    Specifies the default output format for commands. The default is “text/calendar”. (text/js is supported for backward compatibility.)

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

    service.wcap.version

    WCAP version. 

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal_svr_base/SUNWics5/cal/sbin/start-cal

Configuring Logins and Authentication

ProcedureTo Configure Proxy Administrator Logins

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

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

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

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

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

  4. Edit the parameter that follows:

    Parameter  

    Description/Default  

    service.http.allowadminproxy

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

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

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


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

    where:

    • server is the name of the server where Calendar Server is running.

    • port is the Calendar Server port number. The default port is 80.

    • admin-user is the Calendar Server administrator. For example, calmaster.

    • admin-password is the password for admin-user.

    • calendar-user is the calid of the Calendar Server user.

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

    • The admin-user does not have Calendar Server administrator privileges.

    • The admin-password is incorrect.

    • The calendar-user is not a valid Calendar Server user.

ProcedureTo Configure Authentication

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

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

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

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

    Parameter  

    Description/Default 

    local.authldapbasedn

    Base DN for LDAP authentication. If not specified, local.ugldapbasedn is used. If not specified, the server uses the value of local.ugldaphost.

    local.authldaphost

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

    local.authldapbindcred

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

    local.authldapbinddn

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

    local.authldapport

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

    local.authldappoolsize

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

    local.authldapmaxpool

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

    local.user.authfilter

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

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

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

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

    service.plaintextloginpause

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

ProcedureTo Configure the Authentication Cache

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

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

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

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

    Parameter  

    Description and Default Value  

    service.authcachesize

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

    service.authcachettl

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

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal_svr_base/SUNWics5/cal/sbin/start-cal

ProcedureTo Enable Checking the Client IP Address at Login

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

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

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

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

    Parameter  

    Description and Default Value  

    service.dnsresolveclient

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

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal_svr_base/SUNWics5/cal/sbin/start-cal

Configuring Calendar Services


Tip –

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


ProcedureTo Configure Administrative Services (csadmind)

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

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

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

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

    Parameter  

    Description and Default Value  

    service.admin.checkpoint

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

    service.admin.dbcachesize

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

    service.admin.deadlock

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

    service.admin.diskusage

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

    service.admin.enable

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

    service.admin.idletimeout

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

    service.admin.maxsessions

    Maximum number of administration sessions allowed. The default is “100”.

    service.admin.maxthreads

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

    service.admin.numprocesses

    Maximum number of a concurrent administration processes allowed. 

    service.admin.port

    No default. This parameter is set by the system. 


    Caution – Caution –

    Do NOT set this parameter yourself. It is set by the system. You can not do remote administration in Calendar Server. If you change this port number, csadmind may not start.


    service.admin.resourcetimeout

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

    service.admin.serverresponse

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

    service.admin.sessiondir.path

    Temporary directory for administration session requests. No default. 

    service.admin.sessiontimeout

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

    service.admin.sleeptime

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

    service.admin.starttime

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

    service.admin.stoptime

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

    service.admin.stoptime.next

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

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal_svr_base/SUNWics5/cal/sbin/start-cal

ProcedureTo Configure HTTP Services (cshttpd)

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

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

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

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

    Parameter  

    Description and Default Value  

    service.http.admins

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

    service.http.allowadminproxy

    If "yes", allow login via proxy. The default is “no”.

    service.http.allowanonymouslogin

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

    service.http.calendarhostname

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

    If not specified, the local HTTP host is used. 

    service.http.cookies

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

    service.http.dbcachesize

    Maximum cache size of Berkeley DB for HTTP sessions. The default is “8388308”.

    service.http.domainallowed

    If specified and not " ", 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 "".

    service.http.domainnotallowed

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

    service.http.attachdir.path

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

    service.http.ipsecurity

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

    service.http.enable

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


    Caution – Caution –

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


    service.http.idletimeout

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

    service.http.listenaddr

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

    service.http.logaccess

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

    service.http.maxsessions

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

    service.http.maxthreads

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

    service.http.numprocesses

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

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

    service.http.port

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

    service.http.proxydomainallowed

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

    service.http.resourcetimeout

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

    service.http.sessiondir.path

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

    service.http.sessiontimeout

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

    service.http.sourceurl

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

    service.http.tmpdir

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

    service.http.uidir.path

    Directory that contains the default calendar client. If allowing only WCAP access, set to "html".

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal_svr_base/SUNWics5/cal/sbin/start-cal

ProcedureTo Configure Alarm Notification

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

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

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

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

    Parameter  

    Description and Default Value  

    alarm.diskstat.msgalarmdescription

    Description sent with insufficient disk space messages. 

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

    alarm.diskstat.msgalarmstatinterval

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

    alarm.diskstat.msgalarmthreshold

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

    alarm.diskstat.msgalarmthresholddirection

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

    alarm.diskstat.msgalarmwarninginterval

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

    alarm.msgalarmnoticehost

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

    alarm.msgalarmnoticeport

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

    alarm.msgalarmnoticercpt

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

    alarm.msgalarmnoticesender

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

    alarm.msgalarmnoticetemplate

    The default format used to send email alarms: 

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

    alarm.responsestat.msgalarmdescription

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

    alarm.responsestat.msgalarmstatinterval

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

    alarm.responsestat.msgalarmthreshold

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

    alarm.responsestat.

    msgalarmthresholddirection

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

    alarm.responsestat.

    msgalarmwarninginterval

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

    local.rfc822header.allow8bit

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

    service.admin.alarm

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

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal_svr_base/SUNWics5/cal/sbin/start-cal

Configuring Periodic Deadlock Checking for the Berkeley Databases

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

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

ProcedureTo Enable Periodic Checking of Berkeley Databases for Deadlocks

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

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

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

  4. Edit the parameter shown in the following table:

    Parameter  

    Description/Default  

    local.caldb.deadlock.autodetect

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

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal_svr_base/SUNWics5/cal/sbin/start-cal

Troubleshooting

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

Configuring Calendar Server for LDAP

ProcedureTo Configure Anonymous Access to LDAP

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

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

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

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

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

    Parameter  

    Description/Default  

    calstore.anonymous.calid

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

    service.http.allowanonymouslogin

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

    service.wcap.anonymous.

    allowpubliccalendarwrite

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

    service.wcap.userprefs.ldapproxyauth

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

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal_svr_base/SUNWics5/cal/sbin/start-cal

ProcedureTo Configure LDAP Attendee Lookup

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

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

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

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

    Parameter  

    Description/Default  

    local.lookupldap.search.

    minwildcardsize

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

    local.lookupldap.user.authfilter

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

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

    local.lookupldapsearchattr.

    objectclass.person

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

    local.lookupldapsearchattr.

    memberurl

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

    local.lookupldapsearchattr.

    uniquemember

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

    local.lookupldapsearchattr.

    givenname

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

    local.lookupldapsearchattr.sn

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

    local.smtp.defaultdomain

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

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal_svr_base/SUNWics5/cal/sbin/start-cal

ProcedureTo Configure Search Filters for LDAP Attendee Lookup

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

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

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

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


    Tip –

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


    Parameter  

    Description/Default  

    local.lookupldap.calid.direct

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

    %s–The attendee string. 

    local.lookupldap.cn.direct

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

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

    %s – The attendee string.

    local.lookupldap.cn.search

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

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

    For a wild card search (multiple search strings): 

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

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

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

    local.lookupldap.gid

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

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

    %s — A single attendee string.

    local.lookupldap.mailto.indomain

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

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

    %s – The attendee string.

    %o – The attendeeuid.

    %h – The query string without the domain part.

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

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

    local.lookupldap.mailto.outdomain

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

    %s – The attendee string.

    local.lookupldap.res

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

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

    $s – The attendee string.

    local.lookupldap.res.ugldap

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

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

    %s – The attendee string.

    local.lookupldap.uid.direct

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

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

    %s – The attendee string.

    local.lookupldap.uid.search

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

     

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

    %s – The attendee string.

    %w – The attendee string with wildcards.

    %o – The attendee string without wildcards.

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal_svr_base/SUNWics5/cal/sbin/start-cal

ProcedureTo Configure LDAP Resource Lookup

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

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

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

  4. Edit the parameter shown in the following table:

    Parameter  

    Description/Default  

    local.lookupldap.resource.use.ugldap

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

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

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

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal_svr_base/SUNWics5/cal/sbin/start-cal

ProcedureTo Configure LDAP Mail-to-Calid Lookup

These parameters are used only for a non-hosted domain environment. If you have deployed a hosted domain environment, the maillookup parameters are ignored and the user and group LDAP values (ugldap) are used.

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

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

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

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

    Parameter  

    Description/Default  

    local.lookupldap.mailtocalid.search

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

    You can substitute the attribute mailequivalentaddress in place of mailalternateaddress.

    local.maillookupldapbasedn

    Specifies the base DN for mail-to-calid lookup. If not specified, uses local.ugldapbasedn.

    local.maillookupldapbinddn

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

    local.maillookupldapbindcred

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

    local.maillookupldaphost

    Specifies the LDAP host used for mail -to-calid lookup. If not specified, uses local.ugldaphost.

    local.maillookupldapmaxpool

    Specifies the maximum number of client connections maintained for mail-to-calid lookup. If not specified, uses local.ugldapmaxpool. The default is “1024”.

    local.maillookupldappoolsize

    Specifies the minimum number of client connections to maintain for mail-to-calid lookup. If not specified, uses local.ugldappoolsize. The default is “1”.

    local.maillookupldapport

    Specifies the port for the LDAP mail-to-calid lookup. If not specified, uses local.ugldapport. No default.

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal_svr_base/SUNWics5/cal/sbin/start-cal

ProcedureTo Configure Calendar Server to Use the User Preferences LDAP Directory

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

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

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

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

    Parameter  

    Description/Default  

    local.enduseradmincred

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

    local.enduseradmindn

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

    local.ugldappoolsize

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

    local.ugldapmaxpool

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

    service.wcap.userprefs.ldapproxyauth

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

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal_svr_base/SUNWics5/cal/sbin/start-cal

ProcedureTo Configure User Preferences

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

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

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

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

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

    Parameter  

    Default List of User Preferences  

    Description  

    local.

    ugldapicsextendeduserprefs

    "ceColorSet,

    ceFontFace,

    ceFontSizeDelta,

    ceDateOrder,

    ceDateSeparator,

    ceClock,

    ceDayHead,

    ceDayTail,

    ceInterval,

    ceToolText,

    ceToolImage,

    ceDefaultAlarmStart,

    ceSingleCalendarTZID,

    ceAllCalendarTZIDs,

    ceDefaultAlarmEmail,

    ceNotifyEmail,

    ceNotifyEnable,

    ceDefaultView,

    ceExcludeSatSun,

    ceGroupInviteAll"

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

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal_svr_base/SUNWics5/cal/sbin/start-cal

ProcedureTo Enable and Configure the LDAP Data Cache

Before You Begin

For overview information about the LDAP Data Cache, see LDAP Data Cache Option.

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

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

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

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

    Parameter  

    Description and Default Value  

    local.ldap.cache.enable

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

    local.ldap.cache.checkpointinterval

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

    local.ldap.cache.circularlogging

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

    local.ldap.cache.homedir.path

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

    cal_svr_base/var/opt/SUNWics5
    /csdb/ldap_cache

    local.ldap.cache.logfilesizemb

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

    local.ldap.cache.maxthreads

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

    local.ldap.cache.mempoolsizemb

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

    local.ldap.cache.entryttl

    Not currently implemented. 

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

    local.ldap.cache.stat.enable

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


    Note –

    This parameter applies only to debug mode.


    local.ldap.cache.stat.interval

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

    local.ldap.cache.cleanup.interval

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

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal_svr_base/SUNWics5/cal/sbin/start-cal

See Also

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


Caution – Caution –

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


ProcedureTo Enable and Configure the LDAP SDK Cache

The LDAP SDK cache is disabled by default.

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

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

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

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

    Parameter  

    Description and Default Value  

    service.ldapmemcache

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

    service.ldapmemcachettl

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

    service.ldapmemcachesize

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

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal_svr_base/SUNWics5/cal/sbin/start-cal

ProcedureTo Set the Date Range for Free Busy Searches

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

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

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

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

    Parameter  

    Description and Default Value  

    service.wcap.freebusybegin

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

    service.wcap.freebusyend

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

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal_svr_base/SUNWics5/cal/sbin/start-cal

ProcedureTo Enable Wildcard LDAP Searches of Calendar Properties

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

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

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

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

    Parameter  

    Description and Default Value  

    service.calendarsearch.ldap.

    primaryownersearchfilter

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

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

    Enabling this search filter can negatively impact performance. 

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal_svr_base/SUNWics5/cal/sbin/start-cal

ProcedureTo Set the LDAP Root Suffix

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

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

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

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

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

    Parameter 

    Description and Default Value 

    service.dcroot

    Root suffix of the DC tree in the directory. Required for hosted (virtual) domain mode support using Schema 1. The default is "o=internet".

    See also Setting up a Hosted Domain Environment.

    service.schema2root

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

  5. Save the file as ics.conf.

  6. Restart Calendar Server:

    cal_svr_base/SUNWics5/cal/sbin/start-cal

Chapter 6 Configuring Calendar Database Distribution Across Multiple Machines

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


Caution – Caution –

For Calendar Server installations that separate functionality across front-end and back-end machines, the hardware platforms must be the same on each end.

More specifically, due to big-endian versus small-endian incompatibility, you can’t use both an x86 platform machine and a SPARC platform machine in the same Calendar Server deployment containing front-end and back-end machines.


This chapter contains the following topics:


Tip –

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


Background Information

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

CLD Plug-in Overview

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.

How the CLD Plug-in Works

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

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

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

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

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


Tip –

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


Configurations Supported by the CLD Plug-in

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


Tip –

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


Multiple Front-end Servers with Multiple Back-end Servers

Figure 6–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 Configuring Calendar Servers for CLD and DWP.

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

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

Multiple Machines Functioning as Both Front-end and Back-end Servers

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

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

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

Simple Sizing Exercise

The following are a few rough formulas based on a medium usage profile for figuring how many back-end and front-end servers you need, and how much storage:

Definition of Medium Usage Profile

For our rough estimates, we are assuming the following:

Number of Front-End CPU's

The formula is:

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

Number of Back-End CPU's

The formula is:

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

Amount of Storage Needed

The formula is:

Amount of Storage = 5 emails per week times 52 weeks a year times 2K per email (5*52*2K)

= 520KB per user per year

For the assumed two years of calendar data, 1 MB per user.

Configuring Calendar Servers for CLD and DWP

This sections contains instructions for configuring servers and contains the following topics:

ProcedureTo Configure a Front-End Server for CLD

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

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

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

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

    Parameters 

    Description 

    csapi.plugin.loadall

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

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

    csapi.plugin.calendarlookup

    Set this parameter to "yes".

    csapi.plugin.calendarlookup.name

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

    caldb.cld.type

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

    service.dwp.enable

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

    service.dwp.port

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

    service.store.enable

    Since csstored is meant to back up calendar databases, you do not need it on a front-end machine. However, disabling the process is not required.

    You can choose to disable the csstored process on a front-end machine by setting this parameter to "no". This will stop the process from reporting on a daily basis that it is not configured.

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

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

    For example:  

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

    caldb.dwp.server.default

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

    For example: 

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

    local.authldaphost

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

    local.ugldaphost

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

    service.ens.enable

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

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

    caldb.serveralarms

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

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

    caldb.serveralarms.dispatch

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

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

    service.notify.enable

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

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

    caldb.berkeleydb.archive.enable

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

    caldb.berkeleydb.hotbackup.enable

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

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal_svr_base/SUNWics5/cal/sbin/start-cal

ProcedureTo Configure a Back-end Server for CLD and DWP

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

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

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

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

    Parameters 

    Description 

    service.http.enable

    Set this parameter to "no".

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

    service.admin.enable

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

    caldb.cld.type

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

    For CLD and DWP this must be set to "directory" on every front-end and back-end server.

    csapi.plugin.calendarlookup

    Set this parameter to "no".

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

    service.dwp.enable

    Enable DWP by setting this parameter to "yes"

    service.dwp.port

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

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

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

    For example:  

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

    caldb.dwp.server.default

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

    For example: 

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

    local.authldaphost

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

    local.ugldaphost

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

    service.ens.enable

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

    caldb.serveralarms

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

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal_svr_base/SUNWics5/cal/sbin/start-cal

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

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

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

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

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

    Parameters 

    Description 

    csapi.plugin.loadall

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

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

    csapi.plugin.calendarlookup

    Set this parameter to "yes".

    csapi.plugin.calendarlookup.name

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

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

    caldb.cld.type

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

    service.dwp.enable

    Enable DWP by setting this parameter to "yes"

    service.dwp.port

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

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

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

    For example:  

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

    caldb.dwp.server.default

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

    For example: 

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

    local.authldaphost

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

    local.ugldaphost

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

    service.ens.enable

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

    caldb.serveralarms

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

    caldb.serveralarms.dispatch

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

    service.notify.enable

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

    caldb.berkeleydb.archive.enable

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

    caldb.berkeleydb.hotbackup.enable

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

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal_svr_base/SUNWics5/cal/sbin/start-cal

Maintaining Security Between Front-End and Back-End Servers

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. The following topics are covered:

How Authentication is Accomplished

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.conffile. The back-end server checks the parameters in its ics.conffile, and if both parameters match, the authentication is successful. The back-end server then sends a session ID back to the front-end server. The front-end server uses the session ID in subsequent DWP commands to the back-end server.

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

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

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

ProcedureTo Set Up Authentication for DWP Connections for a Front-end Server

Before You Begin

Caution – Caution –

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


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

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

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

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

    Parameter 

    Description 

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

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

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

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

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal_svr_base/SUNWics5/cal/sbin/start-cal

ProcedureTo Set up Authentication for DWP Connections for a Back-end Server

Before You Begin

Caution – Caution –

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


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

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

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

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

    Parameter 

    Description 

    service.dwp.admin.userid

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

    service.dwp.admin.cred

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

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal_svr_base/SUNWics5/cal/sbin/start-cal

Chapter 7 Configuring for High Availability (Failover Service)

Configuring Calendar Server for high availability (HA) provides for monitoring of and recovery from software and hardware failures. The Calendar Server high availability feature is implemented as a failover service. This chapter describes a Calendar Server HA configuration using Sun Cluster software.

This chapter describes how to install and configure a Calendar Server HA service, including:

Find a set of worksheets to help you plan a Calendar Server High Availability configuration in an appendix, Appendix C, High Availability (HA) Configuration Worksheets.

Requirements for an HA Configuration

A Calendar Server HA configuration requires the software shown in the following table:

Software and Version 

Notes and Patches 

Solaris 9 OS 

SPARC Platform only 

All versions of Solaris 9 OS are supported. 

Solaris 9 OS requires Sun Cluster 3.0 U3 or later. 

Solaris 9 OS includes Solaris Logical Volume Manager (LVM). 

Solaris 8 OS 

SPARC Platform only 

Solaris 8 Maintenance Update 7 (MU7) OS or later plus required patches. 

Sun Cluster 3.0 U3 or 3.1 

Sun Cluster software must be installed and configured on all nodes in the cluster. 

To install Sun Cluster 3.1, use the Java Enterprise System installer by following the installation process in the Sun Java Enterprise System 2005Q4 Installation Guide for UNIX.

After you install the Sun Cluster software, you must configure the cluster. For information, refer to the Sun Cluster System Administration Guide for Solaris OS. For related documentation, see Related Documentation.

Sun Cluster Patches

For the Solaris 9 OS, see the Sun Cluster InfoDoc 49704. 

For the Solaris 8 OS, see the Sun Cluster InfoDoc 49705. 

Solstice DiskSuite 4 

Solstice DiskSuite is available for Solaris 8 OS only. 

Solstice DiskSuite is not required for Solaris 9 OS, which includes the Logical Volume Manager (LVM). 

Veritas Volume Manager (VxVM) 3.x 

Solaris 8 OS requires version 3.2 or later plus required patches. 

Solaris 9 OS requires version 3.5 or later plus required patches. 

Veritas File System (VxFS) 3.x 

Solaris 8 OS requires version 3.4 or later plus required patches. 

Solaris 9 OS requires version 3.5 or later plus required patches. 

HAStoragePlus requires patch 110435-08 or later. 

Installation and Configuration

The Calendar Server HA configuration examples in this section use the following names:

Name in Example  

Description  

/global/cal/

Global file system mount point 

cal-logical-host

Logical host name 

cal-logical-host-ip

Logical host IP numeric address 

cs-admin@cal-logical-host

Email address for the Calendar Server administrator 

cal-node-1

Node 1 

cal-node-2

Node 2 

cal-resource-group

Calendar resource group 

cal-resource-group-store

Calendar Server storage resource 

cal-resource

Calendar Server resource 

ProcedureTo Install and Configure a Calendar Server HA Configuration

This is a high level list of the steps necessary to install and configure a Calendar Server HA configuration.

  1. Log in as Superuser

  2. Prepare Each Node in the Cluster

  3. Install Sun Java Enterprise System Products and Packages

  4. Configure the Logical Host

  5. Activate the Storage Resource

  6. Run Postinstallation Configuration Programs

  7. Locate Automatic Backup Directories on Shared Storage

  8. Relocate the Calendar Server config Directory

  9. Edit the Calendar Server ics.conf File

  10. Start the HA Calendar Server

  11. Verify the HA Configuration

Log in as Superuser

To install and configure a Calendar Server HA configuration, log in as or become superuser (root) and specify a console or window for viewing messages sent to /dev/console.

Prepare Each Node in the Cluster

On each node in the cluster, perform these steps:

  1. Create the Calendar Server runtime user and group under which Calendar Server will run as follows:

    1. Add icsgroup (or the value you selected) to the /etc/group file.

    2. Add icsuser (or the value you selected) to the /etc/passwd file.


    Tip –

    The default names are icsuser and icsgroup. You can use other names if you prefer, but the uid and gid numbers must be the same on all nodes in the cluster. The user name should not be root.

    You must provide the user and group names when you Run Postinstallation Configuration Programs.


  2. Add or set the following fields in the /etc/vfstab file:

Install Sun Java Enterprise System Products and Packages

The installation of Sun Java Enterprise System products, including Calendar Server, has significantly changed from earlier Sun branded products (for example, Sun ONE, and iPlanet). To install Sun Java Enterprise System products, you must use the Sun Java Enterprise System installer.

For information about the installer, refer to the Sun Java Enterprise System 2005Q4 Installation Guide for UNIX.

The following table describes the Sun products and packages required for a Calendar Server HA configuration.

Product or Package 

Node 1 

Node 2 

Sun Cluster Software 

yes 

yes 

Calendar Server (6.0 and later) 

yes 

no 

Sun Cluster Agent for Calendar Server (SUNWscics package)

yes 

yes 

Shared components (SUNWicu, SUNWldk, SUNWpr, SUNWsasl, and SUNWtls packages)

yes 

yes 

Node 1

On node 1, install all selected products and packages using the Java Enterprise System installer. When you install Calendar Server, you must specify a directory other the default directory. See Selecting the Calendar Server Installation Directory.

Node 2

On node 2, follow these steps:

  1. Install Sun Cluster and the Sun Cluster Agent for Calendar Server (SUNWscics package) using the Java Enterprise System installer.

  2. Note You cannot install only the Sun Cluster Agent for Calendar Server. When you chose the Sun Java System Agents for Sun Cluster, the Java Enterprise System installer installs all agents.

  3. Install shared components (SUNWicu, SUNWldk, SUNWpr, SUNWsasl, and SUNWtls packages) using the pkgadd command. See Installing Shared Components.

Selecting the Calendar Server Installation Directory

For Calendar Server, the Java Enterprise System installer uses the following default installation directory: /opt

However, for an HA configuration, you must specify a global installation directory. For example: /global/cal/opt/

Installing Shared Components

To make the required shared components available on node 2, you must install the following packages:

These packages are available in the following directories:

.../Solaris_sparc/Product/shared_components/Packages/SUNWldk
 .../Solaris_sparc/Product/shared_components/Solaris_8/Packages
 .../Solaris_sparc/Product/shared_components/Solaris_9/Packages

To install these packages, change to one of the directories shown above and use the pkgadd command. For example:

# pkgadd -d . SUNWicu SUNWpr SUNWsasl SUNWtls

Configure the Logical Host

To configure the logical host:

  1. Create a Calendar Server failover resource group named cal-resource-group:


    # scrgadm -a -g cal-resource-group -h cal-node-2,cal-node-1
    
  2. Add the logical host name named cal-logical-host to the resource group. Calendar Server will listen on this host name.


    # scrgadm -a -L -g cal-resource-group -l cal-logical-host
    
  3. Bring the resource group online:


    # scswitch -Z -g cal-resource-group
    

Activate the Storage Resource

To activate the storage resource:

  1. Register the storage resource specifying the mount point as the ServicePaths property:


    # scrgadm -a 
        -j cal-resource-group-store
        -g cal-resource-group
        -t SUNW.HAStorage
        -x ServicePaths=/global/cal
        -x AffinityOn=True
  2. Enable the storage resource:


    # scswitch -e -j cal-resource-group-store
    

    If SUNW.HAStoragePlus has also chosen to setup a global file system (GFS), the FileSystemMountPoints property must be set instead of ServicePaths.

Run Postinstallation Configuration Programs

After you install Calendar Server, run the Directory Server Setup script (comm_dssetup.pl) and the Calendar Server configuration program (csconfigurator.sh) as described in Chapter 2, Directory Preparation Script (comm_dssetup.pl).

The following table describes the specific configuration information that you must provide for an HA configuration.

Table 7–1 Calendar Server Configuration Options for an HA Configuration

Configuration Panel 

Description  

Runtime Configuration 

Runtime User ID and Group ID

  • Runtime user ID is the user name under which Calendar Server will run. This name should not be root. The default is icsuser.

  • Runtime Group ID is the group under which Calendar Server will run. The default is icsgroup.

    Although the configuration program can create these names for you, you should create them before you run the configuration program, as part of the preparation of each node as described earlier in this chapter.

    These names must be in the following files:

  • icsuser (or the name you select) in /etc/passwd on all nodes in the cluster

  • icsgroup (or the name you select) in /etc/group on all nodes in the cluster

    Calendar Server Startup

    Do not check either of these options.

  • Start after successful installation

  • Start on system startup

Select Directories 

For the location of the database, temporary, and log files, select global partitions. For example: 

  • Database:/global/cal/var/csdb

  • Temporary Files: /global/cal/var/tmp

  • Logs: /global/cal/var/logs

  • Backups:/global/cal/var/hotbackupdb, and /global/cal/var/archivedb

Locate Automatic Backup Directories on Shared Storage

When configuring automatic backups for HA, backup directories must reside on shared storage partitions to prevent incomplete copies on individual nodes of the cluster. Pay particular attention to the size of the partition, since backup directories are large.

Disk space calculations fail for symbolic links. Therefore, do not use symbolic links for automatic backup directories.

Relocate the Calendar Server config Directory

The Calendar Server stores configuration files in the config directory. In an earlier release, the config directory was relocated. Its location is:

/etc/opt/SUNWics5/config/

Symbolic links to the old config directory are kept in the following directories:

After running the Calendar Server configuration program, csconfigurator.sh, remove the symbolic link in each of the old directories and replace it with a link to the new directory as described in the procedures that follows. Note that these procedures preserve the settings from the original configuration files found in /etc/opt/SUNWics5/config.

Before you start, make sure the contents of the config directory are owned by icsuser and icsgroup (or your choices you specified for the runtime User ID and Group ID):

# ls -ld config
 ... icsuser icsgroup ... config/

To Change the Symbolic Link Found in /opt/SUNWics5/cal:

  1. Change to the /global/cal/opt/SUNWics5/cal directory, For example:


    # cd /global/cal/opt/SUNWics5/cal/

    where /global/cal/ is the file system mount point.

  2. Check that config is a symbolic link to the new config directory. For example:


    # ls -l config
     ... config -\> /etc/opt/SUNWics5/config/
  3. In the /opt/SUNWics5/cal/ directory, remove the config symbolic link:


    # cd /opt/SUNWics5/cal
    # rm config
  4. Copy the contents of the /etc/opt/SUNWics5/config directory into the new HA directory, preserving the ownership and permissions:


    # cd /global/cal/opt/SUNWics5/cal
    # cp -pr /etc/opt/SUNWics5/config .

To Change the Symbolic Link Found in /opt/SUNWics5/lib:

  1. In the /global/cal/opt/SUNWics5/cal/lib directory, check that config is a symbolic link to /etc/opt/SUNWics5/config.


    # cd /global/cal/opt/SUNWics5/cal/lib
     # ls -l config
     ... config -\> /etc/opt/SUNWics5/config/
  2. Remove the config symbolic link:


    # rm config
  3. Create a new symbolic link to the new config location:


    # ln -s ../config config
  4. Verify the new link:


    # ls -l config
     ... config -\> ../config/

To Change the Symbolic Link Found in /opt/SUNWics5/sbin:

  1. In the /global/cal/opt/SUNWics5/cal/sbin directory, check that config is a symbolic link to /etc/opt/SUNWics5/config.


    # cd /global/cal/opt/SUNWics5/cal/sbin
     # ls -l config
     ... config -\> /etc/opt/SUNWics5/config/
  2. Remove the config symbolic link:


    # rm config
  3. Create a new symbolic link to the new config location:


    # ln -s ../config config
  4. Verify the new link:


    # ls -l config
     ... config -\> ../config/

    Note –

    If you need to uninstall Calendar Server, use the Java Enterprise System uninstaller, which removes the SUNWics5 and SUNWica5 packages.

    For a Calendar Server HA configuration, however, you must first remove the relocated config directory and all of its contents before you run the uninstaller. For example:


    # cd /global/cal/opt/SUNWics5/cal/
     # rm -rf config

    If you do not remove the config directory, the uninstall operation fails for the SUNWics5 package.


Edit the Calendar Server ics.conf File

In the /opt/SUNWics5/cal/config directory, edit the ics.conf configuration file as follows:

  1. Add the following parameters:


    local.server.ha.enabled="yes"
     local.server.ha.agent="SUNWscics"
  2. Rename the service.listenaddr parameter to service.http.listenaddr and then set the parameter to the IP address of the logical host. For example:


    service.http.listenaddr = "cal-logical-host-ip"

    where “cal-logical-host-ip” is the numeric IP address of the logical host. For example: 123.321.12.2.

  3. Change all parameters that refer to a local host name to the logical host name. For example:


    local.hostname="cal-logical-host"
     local.servername="cal-logical-host"
     service.ens.host="cal-logical-host"
     service.http.calendarhostname="cal-logical-host.sesta.com"

Start the HA Calendar Server

Before you start the HA Calendar Server, register the calendar resource type SUNWscics and create a calendar resource as follows:

  1. Register the calendar resource type:


    # scrgadm -a -t SUNW.scics
  2. Create the calendar resource:


    # scrgadm -a 
            -j cal-resource 
            -g cal-resource-group
            -t SUNW.scics 
            -x Confdir_list=/global/cal/cal-resource-group 
            -y Resource_dependencies=cal-resource-group-store 
            -y Port_list=80/tcp
  3. Enable the resource and start Calendar Server:


    # scswitch -e -j cal-resource
    

Verify the HA Configuration

After you start Calendar Server check that all required processes or daemons (csadmind, enpd, csnotifyd, and cshttpd) are running.

Additionally, conduct a switchover of the service to the backup node to ensure the high availability. For example, if the service is running on cal-node-1, issue the following command to switch the service to cal-node-2.

# scswitch -z -g cal-resource-group
                            -h cal-node-2

Then check that all processes are started on cal-node-2.

For troubleshooting, error messages are written to the console and /var/adm/messages.

The /var/cluster/rgm/rt/SUNW.scics/loglevel file contains the logging level. Use “9” for maximum verbosity.

For information about using the logging facility, refer to the Related Documentation.

Starting and Stopping Calendar Server HA Service

To start and stop the Calendar Server HA service, use the Sun Cluster scswitch command. Do not use the Calendar Server start-cal, csstart, stop-cal, or csstop utilities. For example:

To start the Calendar Server HA service:

# scswitch -e -j cal-resource

To stop the Calendar Server HA service:

# scswitch -n -j cal-resource

To restart the Calendar Server HA service:

# scswitch -R -j cal-resource

For information about the Sun Cluster scswitch command, refer to the Sun Cluster Reference Manual for Solaris OS.

Related Documentation

Chapter 8 Configuring SSL

Calendar Server supports the Secure Sockets Layer (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), which are also used by Sun Java System Messaging Server.

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 is covers the three tasks necessary to configure SSL and troubleshooting:


Note –

Calendar Server does not support client-based SSL authentication.


Configuring SSL for Calendar Server

ProcedureTo Create a Certificate Database

An SSL implementation for Calendar Server requires a certificate database. The certificate database must define a Certificate Authority (CA) and certificates for Calendar Server. This section contains conceptual and task information:

Before You Begin

Before you create the certificate database, familiarize yourself with the following:

  1. Log in as or become superuser (root).

  2. Specify the certificate database password for certutil in /etc/opt/SUNWics5/config/sslPasswordFile. For example:


    # echo "password" 
          /etc/opt/SUNWics5/config/sslPasswordFile

    where password is your specific password.

  3. Create the certificate database alias directory. For example:


    # cd /var/opt/SUNWics5
     # mkdir alias
  4. Move 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 /var/opt/SUNWics5/alias
                     -f /etc/opt/SUNWics5/config/sslPasswordFile

    Note –

    For this and other times when you must run the certutil utility, follow the examples exactly, or consult the certutil help page to understand the syntax.

    For example, in this case, do not run the utility with the -N option without also specifying the -d /file information.


  5. Generate a default self-signed root Certificate Authority certificate. For example:


    # ./certutil -S -n SampleRootCA -x -t "CTu,CTu,CTu"
     -s "CN=My Sample Root CA, O=sesta.com" -m 25000
     -o /var/opt/SUNWics5/alias/SampleRootCA.crt
     -d /var/opt/SUNWics5/alias
     -f /etc/opt/SUNWics5/config/sslPasswordFile -z
     /etc/passwd
  6. Generate a certificate for the host. For example:


    # ./certutil -S -n SampleSSLServerCert -c SampleRootCA 
     -t "u,u,u"
     -s "CN=hostname.sesta.com, O=sesta.com" -m 25001
     -o /var/opt/SUNWics5/alias/SampleSSLServer.crt
     -d /var/opt/SUNWics5/alias 
     -f /etc/opt/SUNWics5/config/sslPasswordFile
     -z /etc/passwd

    where hostname.sesta.com is the server host name.

  7. Validate the certificates. For example:


    # ./certutil -V -u V -n SampleRootCA  
        -d /var/opt/SUNWics5/alias
     # ./certutil -V -u V -n SampleSSLServerCert 
       -d /var/opt/SUNWics5/alias
  8. List the certificates. For example:


    # ./certutil -L -d /var/opt/SUNWics5/alias
     # ./certutil -L -n SampleSSLServerCert 
       -d /var/opt/SUNWics5/alias
  9. Use modutil to list the available security modules (secmod.db). For example:


    # ./modutil -list -dbdir /var/opt/SUNWics5/alias
  10. Change the owner of the alias file to icsuser and icsgroup (or the user and group identity under which Calendar Server will run). For example:


    # find /var/opt/SUNWics5/alias -exec chown icsuser {};
     # find /var/opt/SUNWics5/alias -exec chgrp icsgroup {};

ProcedureTo Request and Import a Certificate from a Root Certificate Authority

The following steps tell you how to generate a certificate request, submit it to the Public Key Infrastructure (PKI) Web site, and then import the certificate.

  1. Log in as or become superuser (root).

  2. Move to the bin directory:


    # cd /opt/SUNWics5/cal/bin
  3. Use certutil to generate a Certificate Request based on the Certificate Authority or Public Key Infrastructure (PKI) Web site. For example:


    # ./certutil -R -s "CN=hostname.sesta.com, 
    OU=hostname/ SSL Web Server, O=Sesta, 
    C=US" -p "408-555-1234" -o hostnameCert.req 
    -g 1024  -d /var/opt/SUNWics5/alias 
    -f /etc/opt/SUNWics5/config/sslPasswordFile  -z /etc/passwd -a

    where “hostname.sesta.com” is the host name.

  4. Request an test certificate for an SSL web server from the Certificate Authority or Public Key Infrastructure (PKI) Web site. Copy and paste the contents from the hostnameCert.req file into the Certificate Request.

    You will be notified by when your certificate is signed and can be picked up.

  5. Copy the Certificate Authority Certificate Chain and SSL server certificate into text files.

  6. Import the Certificate Authority Certificate Chain into the certificate database to establish a Chain of Authority. For example:


    # ./certutil -A -n "GTE CyberTrust Root"
        -t "TCu,TCu,TCuw" 
        -d /var/opt/SUNWics5/alias 
        -a 
        -i /export/wspace/Certificates/CA_Certificate_1.txt
        -f /etc/opt/SUNWics5/config/sslPasswordFile
    # ./certutil -A -n "Sesta TEST Root CA" 
        -t "TCu,TCu,TCuw" 
        -d /var/opt/SUNWics5/alias 
        -a 
        -i /export/wspace/Certificates/CA_Certificate_2.txt
        -f /etc/opt/SUNWics5/config/sslPasswordFile
  7. Import the signed SSL server certificate:


    # ./certutil -A -n "hostname SSL Server Test Cert"
        -t "u,u,u" -d /var/opt/SUNWics5/alias 
        -a 
        -i /export/wspace/Certificates/SSL_Server_Certificate.txt
        -f /etc/opt/SUNWics5/config/sslPasswordFile
  8. List the certificates in the certificate database:


    # ./certutil -L -d /var/opt/SUNWics5/alias
  9. Configure the SSL Server Nickname in the ics.conf file to be the signed SSL server certificate, For example: “hostname SSL Server Test Cert”.

    Note The host name for the service.http.calendarhostname and service.http.ssl.sourceurl parameters in the ics.conf file should match the host name on the SSL certificate (in case your system has several aliases). For example: calendar.sesta.com

ProcedureTo Configure SSL Parameters in the ics.conf File

To implement SSL with Calendar Server, you must set specific parameters in the ics.conf file. If any of the parameters listed in the following table are not in the ics.conf file, add them to the file with the value specified. Since the ics.conf is read only at system startup (when start-cal is issued), the new values will not take effect until the Calendar Server is restarted. For a description of these SSL parameters, see SSL Configuration.

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

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

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

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

    Parameter 

    Value 

    encryption.rsa.nssslactivation

    “on”

    encryption.rsa.nssslpersonalityssl

    “SampleSSLServerCert”

    encryption.rsa.nsssltoken

    “internal”

    service.http.tmpdir

    “/var/opt/SUNWics5/tmp”

    service.http.uidir.path

    “html”

    service.http.ssl.cachedir

    “.”

    service.http.ssl.cachesize

    “10000”

    service.http.ssl.certdb.password

    " "(Supply an appropriate password)

    service.http.ssl.certdb.path

    “/var/opt/SUNWics5/alias”

    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 local host, and the service.http.ssl.port value.)

    service.http.ssl.ssl2.ciphers

    ““

    service.http.ssl.ssl2.sessiontimeout

    “0”

    service.http.ssl.ssl3.ciphers

    "rsa_red_40_md5,

    rsa_rc2_40_md5,

    rsa_des_sha,

    rsa_rc4_128_md5,

    rsa_3des_sha"

    service.http.ssl.ssl3.sessiontimeout

    “0”

    service.http.sslusessl

    “yes”

  5. Save the file as ics.conf.

  6. Restart Calendar Server for the changes to take effect.

    cal_svr_base/SUNWics5/cal/sbin/start-cal

Troubleshooting SSL

First, always backup your certificate database on a regular basis in case unrecoverable problems occur. If you have problems with SSL, here are some things to consider:

Checking for the cshttpd Process

SSL requires the Calendar Server cshttpd process to be running. To determine if cshttpd is running, use this command:

# ps -ef | grep cshttpd

Verifying Certificates

To list the certificates in the certificate database and checking their validity dates, use this command:

# ./certutil -L -d /var/opt/SUNWics5/alias

Reviewing Calendar Server Log Files

Check the Calendar Server log files for any SSL errors. For more information see Using Calendar Server Log Files.

Connecting to the SSL Port

Connect to the SSL port using a browser and the following URL:

https://server-name:ssl-port-number

where:

server-name is the name of the server where Calendar Server is running.

ssl-port-number is the SSL port number as specified by the service.http.ssl.port parameter in the ics.conf file. The default is 443.

Making cshttpd Stop Listening on the Regular HTTP Port

HTTP and HTTPS listen on different ports (443 for SSL, and 80 for HTTP), so you will never have both listening to the same port. Currently, there is no way to tell cshttpd to stop listening to the regular HTTP port. However, an administrator can change the service.http.port to an undisclosed number.


Caution – Caution –

Do not set service.http.enable ="no" in an attempt to prevent cshttpd from listening to HTTP. Doing so would cause HTTPS to fail also. Both service.http.enable and service.http.ssl.port.enable must be set to "yes" for SSL to be configured properly.


Chapter 9 Configuring Single Sign-on

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:

Configuring SSO Through Access Manager

Sun Java Enterprise System servers, including Calendar Server and Messaging Server, can implement SSO using Sun Java System Access Manager (release 6 2003Q4 or later)

Access Manager serves as the SSO gateway for Sun Java Enterprise System servers. That is, users log in to Access Manager and then can access other Sun Java Enterprise System servers, as long as the servers are configured properly for SSO.

ProcedureTo use SSO with Calendar Server

  1. Make sure that Access Manager and Directory Server are installed and configured. For information about installing and configuring these products, refer to the Sun Java Enterprise System 2005Q4 Installation Guide for UNIX.

  2. Configure SSO for Calendar Server by setting the parameters shown in Configuring SSO Through Access Manager and then restarting Calendar Server for the values to take effect. If necessary, remove the comment character (!) when you set each parameter.


    Note –

    When you set the local.calendar.sso.amnamingurl parameter, you must use a fully qualified name for Access Manager.


  3. To configure SSO for Messaging Server, refer to the Sun Java System Messaging Server 6 2005Q4 Administration Guide.

  4. Users log into Access Manager using their Directory Server LDAP user name and password. (A user who logs in through another server such as Calendar Server or Messaging Server will not be able to use SSO to access the other Sun Java Enterprise System servers.)

  5. After logging in, users can access Calendar Server through Communications Express using the appropriate URL. Users can also access other Sun Java Enterprise System 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“. 

Considerations for Using SSO With Access Manager

Configuring SSO Through Communications Servers Trusted Circle Technology

When configuring SSO through Communications Servers trusted circle technology (that is, not through Access Manager), consider these points:

The following table describes the Calendar Server configuration parameters for SSO through Communications Servers trusted circle technology.

Table 9–1 Calendar Server SSO Parameters Through Communications Servers Trusted Circle Technology

Parameter  

Description  

sso.enable

This parameter must be set to "1" (the default) to enable SSO. "0" disables SSO. 

sso.appid

This parameter specifies the unique application ID for the specific Calendar Server installation. Each trusted application must also have a unique application ID. The default is: "ics50"

sso.appprefix

This parameter specifies the prefix value to be used for formatting SSO cookies. The same value must be used by all trusted applications, because only SSO cookies with this prefix will be recognized by Calendar Server. The default is: "ssogrp1"

sso.cookiedomain

This parameter causes the browser to send a cookie only to servers in the specified domain. The value must begin with a period (.) 

sso.singlesignoff

A value of “true” (the default) clears all SSO cookies on the client with prefix values matching the value configured in sso.appprefix when the client logs out.

sso.userdomain

This parameter sets the domain used as part of the user's SSO authentication. 

sso.appid.url = "verifyurl"

This parameter sets the verify URL values for peer SSO hosts for the Calendar Server configuration. One parameter is required for each trusted peer SSO host. The parameter includes the: 

  • Application ID (appid) identifies each peer SSO host whose SSO cookies are to be honored

  • Verify URL (verifyurl) includes the host URL, host port number, and VerifySSO? (including the ending question mark (?).

    In this example, the Calendar Server application ID is ics50, the host URL is sesta.com, and the port is 8883.

    The Messenger Express application ID is msg50, the host URL is sesta.com, and the port is 8882.

For example: 

sso.ics50.url=
  "http://sesta.com:8883
  /VerifySSO?"
sso.msg50.url=
  "http://sesta.com:8882
  /VerifySSO?" 

The following table describes the Messaging Server configuration parameters for SSO through Communications Servers trusted circle technology.

Table 9–2 Messaging Server SSO Parameters Through Communications Servers Trusted Circle Technology

Parameter  

Description  

local.webmail.sso.enable

This parameter must be set to a non-zero value to enable SSO. 

local.webmail.sso.prefix

This parameter specifies a prefix used when formatting SSO cookies set by the HTTP server. For example: ssogrp1

local.webmail.sso.id

This parameter specifies the unique application ID ( for example: msg50) for the Messaging Server.

Each trusted application must also have a unique application ID. 

local.webmail.sso.cookiedomain

This parameter specifies the cookie domain value of all SSO cookies set by the HTTP server. 

local.webmail.sso.singlesignoff

A non-zero value clears all SSO cookies on the client with prefix values matching the value configured in local.webmail.sso.prefix when the client logs out.

local.sso.appid.url=verifyurl

This parameter sets the verify URL values for peer SSO hosts for the Messaging Server configuration. One parameter is required for each trusted peer SSO host. The parameter includes these items: 

  • Application ID (appid) identifies each peer SSO host whose SSO cookies are to be honored

  • Verify URL (verifyurl) includes the host URL, host port number, and VerifySSO? (including the ending ?).

    For example:

    local.sso.ics50.verifyurl=

    http://sesta.com:8883/VerifySSO?

    In this example, the Calendar Server application ID is ics50, the host URL is sesta.com, and the port is 8883.

    local.sso.msg50.verifyurl=

    http://sesta.com:8882/VerifySSO?

    In this example, the Messaging Server application ID is msg50, the host URL is sesta.com, and the port is 8882.

For more information about configuring Messaging Server for SSO, see the Sun Java System Messaging Server 6 2005Q4 Administration Guide.

Chapter 10 Configuring Automatic Backups (csstored)

At configuration time you are given the opportunity to enable automatic backups. However, you can also enable or disable automatic backups at any time thereafter. A good backup system is essential to safeguard your data and minimize operational downtime.

Information in this chapter explains how to configure the Calendar Server service csstored to perform automatic backups. It contains the following sections:


Note –

If you choose not to use the automatic backup process discussed here, you must implement your own backup strategy to safeguard your data. For information on how to use other Calendar Server tools for protecting your data, see Chapter 17, Backing Up and Restoring Calendar Server Data.


For an overview of csstored, see the Sun Java System Communications Services 6 2005Q4 Deployment Planning Guide.

Automatic Backups Overview

This section covers the following topics:

How Automatic Backups Work

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.

How csstored Works

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 you did not choose automatic backups in the configuration program, they are disabled, but the csstored process still runs. However, until automatic backups are enabled, the only function csstored performs is to generate an informational administrator message every 24 hours saying csstored is not configured (meaning automatic backups have not been enabled).


Note –

When automatic backups are disabled, the circular logging ics.conf parameter, caldb.berkeley.circularlogging, should be set to “yes”. This enables purging of old database transaction logs, which conserves disk space.


How Circular Backups Work

With automatic backups enabled, csstored automatically manages the number of backup copies retained in your backup database files using a circular backup system.

csstored 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 Tuning Automatic Backups.

High Level Steps for Enabling Automatic Backups

The following is a high-level list of the tasks to perform to enable automatic backups:

Setting up Transaction Log Files

This section covers the following topics:

Understanding Transaction Log Files

Transaction log files are used by Calendar Server to capture all of the additions, modifications and deletions made to the calendar database since the latest snapshot. The transactions are not actually applied to the live database until the log file is closed for writing. The interval parameter specifies how often the old log files are closed and new log files are created.

The log file names consist of a configurable name with a unique number appended to the end.

As the log files are closed, they are ready to be applied to the live database. This happens asynchronously, meaning the creation of log files and the writing of transactions into them is done in “real time”, whereas the program applying the transactions to the database is running independently, without regard to the writing of the transactions into the log files. If the system is very busy, the number of log files awaiting application to the database can rise. When the system has slow periods, the program applying the transactions has time to “catch up” and may actually sit idle, waiting for the next transaction log.

After the transactions have been applied to the live database, they are applied to the hot backup snapshot (if enabled). The log files are also written to the same archive directory where the snapshot resides.

ProcedureTo Set up Transaction Log Files

  1. At a command line, change to the directory where the ics.conf is located:

    cd/etc/opt/SUNWics5/config

  2. Specify the transaction log name:

    logfile.store.logname=storename.log

  3. Specify the directory path for the transaction log directory:

    The default value is: logfile.logdir="logs"

  4. When you have completed editing the ics.conf file, restart Calendar Server:

    cal_svr_base/SUNWics5/cal/sbin/start-cal

    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.

Specifying the Administrator’s Email Address

This section covers the following topics:

Email Messages Sent to the Administrator

When certain events or errors occur, the administrator is notified by email. The events causing an email message to be generated are:

ProcedureTo Set the Administrator’s Email Address

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

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

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

  4. Edit the ics.conf parameter that follows to specify the administrator’s email address:

    alarm.msgalarmnoticercpt=”admin@email_address

  5. Save the file as ics.conf.

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

Enabling Hot Backups

This section covers the following topics:

What are Hot Backups?

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 How Circular Backups Work.

ProcedureTo Enable Hot Backups

  1. At a command line, change to the directory where the ics.conf is located:

    cd /etc/opt/SUNWics5/config

  2. Enable hot backups by setting the following ics.conf parameter to “yes”:

    caldb.berkeleydb.hotbackup.enable=”yes”

  3. Specify the directory path for the hot backup directory:

    caldb.berkeleydb.hotbackup.path=
       /var/opt/SUNWics5/hotbackup_directory
    

    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 7, Configuring for High Availability (Failover Service).

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

Enabling Archive Backups

This section covers the following topics:

What are Archive Backups?

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 How Circular Backups Work.

ProcedureTo Enable Archive Backups

  1. At a command line, change to the directory where the ics.conf is located:

    cd /etc/opt/SUNWics5/config

  2. Enable archive backups by setting the following ics.conf parameter to “yes”:

    caldb.berkeleydb.archive.enable=”yes”

  3. 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 7, Configuring for High Availability (Failover Service).

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

Disabling the Warning Message

This section describes the daily warning message from an unconfigured csstored process and how to stop it. This section contains the following topics:

Why is the Message Emitted?

The start-cal program starts the csstored process by default. If you have chosen not to configure csstored for your backups on a back-end machine, or you have a front-end machine that does not contain any databases that need to be backed up, you will still receive informational messages every 24 hours, from every machine not configured. If you do not want these messages to be emitted by csstored, you must disable csstored from running.

ProcedureHow to Disable csstored from Running

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

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

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

  4. Add the parameter that follows to the ics.conf file to disable csstored from running:

    service.store.enable="no"

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal_svr_base/SUNWics5/cal/sbin/start-cal

    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.


    Note –

    Be sure not to disable csstored on machines where you have csstored configured for automatic backups.


Chapter 11 Setting Up Hosted Domains

Calendar Server supports hosted (or virtual) domains. In a hosted domain installation, each domain shares the same instance of Calendar Server, 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.

This chapter describes these topics:


Note –

The Sun Java System Communications Services 6 2005Q4 Deployment Planning Guide discusses all the steps necessary to prepare your installation to use hosted domains.



Caution – Caution –

If your site is currently configured for multiple instances of Calendar Server or for limited virtual domain mode, contact your Sun Microsystems sales account representative for an evaluation of your migration requirements.


Overview of Hosted Domains

This section provides an overview of hosted domains, including:

Organization of the LDAP Directory

With a hosted 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 uids 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) describes the root of each domain.

Calendar Server supports both of these LDAP directory schema versions for hosted domains:

When you run the Directory Server Setup script (comm_dssetup.pl), you can choose either LDAP Schema 1 or LDAP Schema 2. Several considerations are:

Sun LDAP Schema 2

The following graphic shows an LDAP directory organization for a hosted domain installation that uses Sun LDAP Schema 2.

Figure 11–1 LDAP Directory Organization Using LDAP Schema 2

This diagram shows an example of a pure Schema 2 environment
using only a single tree, an Organization tree, and no DC tree.

LDAP Schema 2 uses a flat LDAP directory organization, that is, the domains are all at the same level; they are not nested. For a hosted 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 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 1, but it uses the Schema 2 object classes and attributes. This is Schema 2 compatibility mode, which is called Schema 1.5 in the configuration program (csconfigurator.sh).

Sun LDAP Schema 1

The graphic that follows shows an example of an LDAP directory organization for a hosted domain installation that uses Sun LDAP Schema 1.

This organization includes two trees for domain management: a DC tree and an Organization tree (OSI)

Figure 11–2 LDAP Directory Organization Using LDAP Schema 1

This diagram shows an example of a two tree, Schema 1, LDAP organization.

The DC tree (node) is similar to the DNS, which determines a domain entry given the domain name. The inetdomainbasedn LDAP attribute points to the base DN, which is the root of the domain’s users, resources and groups in the organization tree (node). Within each domain, the identifiers for Calendar Server users, resources, and groups must be unique.


Note –

If your earlier LDAP configuration did not contain a DC tree, in order to use Schema 1 mode or Schema 2 compatibility mode, you must create the DC tree nodes yourself as explained in Setting up a Hosted Domain Environment.


In a hosted domain installation using LDAP Schema 1, a directory search requires these two steps to find an entry:

  1. In the DC tree, the search operation locates the domain entry that contains the value of the DN pointing to the base DN (inetDomainBaseDN attribute) of domain in the organization tree.

  2. In the organization tree, the search operation locates the domain entry and then searches from that entry’s base DN to find the user, resource, or group within the domain.

Calendar Server Logins

For a hosted 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.

For an installation with a non-hosted domain environment, domain-name is not required. If a domain name is specified, it will be ignored.

If auto-provisioning 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 LDAP Attributes and Property Names.

Cross Domain Searches

By default, users can search only within their domain for users and groups to invite to events. Cross domain searches, however, allow users in one domain to search for users and groups in other domains, as long as these requirements are met:

For instructions on how to enable cross domain searches, see Enabling Cross Domain Searches.

Support for a Non-Hosted Domains Environment

Calendar Server still supports operating in a non-hosted domains (that is, having a single domain) environment. For example, if you had an existing Calendar Server version 5 or earlier legacy installation, you can still operate in the single domain environment by setting the ics.conf parameter service.virtualdomain.support to "no". See also, Enabling Hosted Domains.

You will, however, still need to migrate the legacy version components database to the current version. For migration information, see the Chapter 4, Database Migration Utilities.

Setting up a Hosted Domain Environment

This section covers the basic tasks that you might need to perform before creating new hosted domain entries in your LDAP:

  1. Run the database migration utilities.

    If you are migrating from Calendar Server version 5, be sure that you have already run cs5migrate, csmig, and csvdmig before attempting to set up hosted domains. You can get the latest version of cs5migrate from Sun’s technical support. For more information on these migrations utilities, see Chapter 4, Database Migration Utilities.

  2. Run comm_dsseetup.pl if you have not already done so.

    It updates the ics.conf file with the parameters needed to support hosted domains.

  3. Edit the ics.conf file to enable hosted domains.

    The following table lists and describes the configuration parameters in the ics.conf file used for hosted domain support. If any of the parameters listed in this table are not in the ics.conf file, add the parameter and its associated value to the file and then restart Calendar Server for the values to take effect.

    Parameter  

    Description  

    service.virtualdomain.support

    Enables ("yes") or disables ("no") support for hosted (virtual) domain mode. Default is "no".

    local.schemaversion

    Specifies the version of the LDAP schema: 

    service.dcroot

    Specifies the root suffix of the DC tree in the LDAP directory, if local.schemaversion="1".

    For example: "o=internet".

    In hosted (virtual) domain mode, Calendar Server uses the service.dcroot parameter and not the local.ugldapbasedn and local.authldapbasedn parameters.

    Conversely, in non-hosted (virtual) domain mode, Calendar Server uses the local.ugldapbasedn and local.authldapbasedn parameters and not the service.dcroot parameter.

    service.schema2root

    Specifies the root suffix underneath which all domains are found, if local.schemaversion="2".

    For example: "o=sesta.com".

    service.defaultdomain

    Specifies the default domain for this instance of Calendar Server. Used when a domain name is not supplied during a login. 

    For example: "red.sesta.com".

    service.loginseparator

    Specifies a string of separators used for the login-separator when Calendar Server parses "userid[login-separator]domain". Calendar Server tries each separator in turn.

    Default is "@+".

    service.siteadmin.userid

    Specifies the user ID of the domain administrator. 

    For example: DomainAdmin@sesta.com.

    service.virtualdomain.scope

    Controls cross domain searching: 

    • "primary" Search only within the domain where the user is logged in.

    • "select" Search in any domain that allows the search.

      Default is "select".

    local.domain.language

    Specifies the language for the domain. Default is "en" (English).

  4. Create a default domain entry.

    For Schema 2, the default domain is created by the Delegated Administrator configuration program (config-commda).

    For Schema 1, create a default domain (one of your hosted domains) 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 Sun LDAP Schema 1. 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
  5. Enable calendaring services for the default domain entry.

    For Schema 1: Add the icsCalendarDomain object class to the o=sesta.com domain entry in LDAP using csattribute.

    For Schema 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 hosted domain:

    commadmin domain modify -D admin -w passwd -d defaultdomain -S cal,mail

  6. Create the hosted domains you want on your system.

    For instructions on how to add a hosted domain in Schema 2 mode, see Creating New Hosted Domains.

    To create a Schema 1 hosted 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
  7. Enable calendaring services for the new hosted domains, as explained in Setting up a Hosted Domain Environment.

  8. Create the calmaster site administrator user if it does not already exist.

    For Schema 2, create the calmaster user using the commadmin user create command as illustrated in the following example:

    commadmin user create -D admin -w passwd -F Calendar
        -L Administrator -l calmaster -W calmasterpasswd -d sesta.com -S cal

    Note –

    To create the calmaster using the Delegated Administrator Console's Create New User wizard, see the Delegated Administrator online help.


    For Schema 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
  9. If the calmaster site administrator user already exists from an earlier non-hosted domain environment (Schema 1), move it to the default domain by performing the following steps:

    1. Perform an LDAP dump of the existing calmaster LDAP entry and save it in a temporary file, such as /tmp/calmaster.ldif.

    2. Delete the existing calmaster LDAP entry on the organization tree root suffix using ldapdelete, as follows:

      #ldapdelete -D "cn=Directory Manager" -w password 
         uid=calmaster,ou=People,o=rootsuffix
      
    3. Modify the calendar administrator’s group entry (update the uniqueMember attribute) to reflect the changes as shown in the LDIF example that follows:


      dn:cn=Calendar Administrators,ou=Groups,o=rootsuffix
      changetype:modifyreplace:uniqueMember 
      uniqueMember:uid=calmaster,ou=People,o=sesta.com,o=rootsuffix
      

      It is not necessary to move the group entry to the hosted domain.

  10. Update any administration scripts you have so that calids in the WCAP commands are fully qualified. That is, each calid must now include the domain name. For example: jsmith@sesta.com.

Using Domains Created by Messaging Server

If Messaging Server has already created hosted domains, they can be calendar enabled for either Schema 1 or Schema 2. This section covers the following topics:

Enabling Calendaring in Schema 1 Messaging Domains

To enable domains for calendaring, add the following object class and two attributes to the LDAP domain entry for each domain you want enabled for calendar:

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
               

Enabling Calendaring in Schema 2 Messaging Domains

If you have already migrated your existing Messaging Server LDAP entries to Schema 2 (using commdirmig), or you originally created the Messaging Server LDAP entries in Schema 2 mode, perform the following two steps to enable calendaring:

  1. Use the Delegated Administrator Utility command commadmin domain modify with the -S option to add calendar service to each domain.

    Alternately, you can use the Delegated Administrator Console to allocate service packages containing calendar service to the affected domains. To do this, use the Allocate Service Packages button on the Organization List page.

  2. Use the Delegated Administrator Utility command commadmin user modify with the -S option to add calendar service to each user in each domain you enabled for calendar.

    Alternately, you can use the Delegated Administrator Console to assign a service package containing calendar service to each user in the affected domains. To do this, use the Assign Service Package button on the User List page in each affected organization.

For the commadmin commands, see the Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide.

For more information about Delegated Administrator Console, see its online help.

For commdirmig information, see the Sun Java System Communications Services 6 2005Q4 Schema Migration Guide)