Chapter 6, Configuring Calendar Database Distribution Across Multiple Machines
Chapter 7, Configuring for High Availability (Failover Service)
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
Do not attempt to edit the configuration file until you have completed the following tasks:
Install or upgrade to Calendar Server 6 2005Q4.
Run the postinstallation configuration programs comm_dssetup.pl and csconfigurator.sh.
Run csmig, csvdmig and commdirmig as needed against your existing calendar databases. See Chapter 4, Database Migration Utilities.
This chapter describes the following topics:
Additional configuration topics are covered in other, separate chapters. They include the following topics:
Chapter 6, Configuring Calendar Database Distribution Across Multiple Machines
Chapter 7, Configuring for High Availability (Failover Service)
Communications Express requires the following things to be configured in the Calendar Server:
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit the ics.conf parameters as shown in the following table:
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. |
The uwcconfig.properties file is located in the comms_express_svr_base/WEB-INF/config directory, where comm_express_svr_base is the directory where Communications Express was installed.
Save the file as ics.conf.
Restart Calendar Server.
cal_svr_base/SUNWics5/cal/sbin/start-cal
For instructions on configuring Communications Express, see the.
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit the following 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. |
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.
Save the file as ics.conf.
Restart Calendar Server.
cal_svr_base/SUNWics5/cal/sbin/start-cal
For instructions on configuring Communications Express, see theSun Java System Communications Express 6 2005Q4 Administration Guide.
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit one or more of the parameters as shown in the following table:
Parameter |
Description and Default Value |
---|---|
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”. |
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:
|
Save the file as ics.conf.
Restart Calendar Server.
cal_svr_base/SUNWics5/cal/sbin/start-cal
Log in as an administrator with permission to change the configuration.
Edit one or more of the parameters as shown in the following table:
Save the file as ics.conf.
Restart Calendar Server.
cal_svr_base/SUNWics5/cal/sbin/start-cal
Autoprovisioning of user calendars is enabled by default.
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
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”. |
Save the file as ics.conf.
Restart Calendar Server.
cal_svr_base/SUNWics5/cal/sbin/start-cal
The free-busy view is used for several purposes. There are a number of ics.conf parameters that can be set to customize how the free-busy view is generated.
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Disable autoprovisioning of user calendars upon first login editing the parameter shown in the following table:
Parameter |
Description and Default Value |
---|---|
Specifies the offset from the current time in days for get_freebusy for beginning of the range. The default is "30". |
|
Specifies the offset from the current time in days for get_freebusy for end of the range. The default is "30". |
|
Specifies whether a user's default calendar is included in user's free/busy calendar list. The default is "yes". |
|
Specifies whether a user's default calendar can be removed from user's free/busy calendar list. The default is "no". |
Save the file as ics.conf.
Restart Calendar Server.
cal_svr_base/SUNWics5/cal/sbin/start-cal
This section contains instructions on configuring calendar users and includes the following topics:
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit one or more of the following ics.conf parameters shown in the following table:
Parameters |
Description and Default Value |
---|---|
If "yes", allow users to change their passwords. The default is "no". |
|
If "yes", allow users to have publicly writable calendars. The default is "yes". |
|
Specifies whether a user's default calendar can be removed from the user's subscribed calendar list. The default is "no". |
|
If "yes", allow calendars to be created by users who do not have administrative privileges. The default is "yes". |
|
If "yes", allow calendars to be deleted by users who do not have administrative privileges, but do have delete permission for that calendar. The default is "yes". |
Save the file as ics.conf.
Restart Calendar Server.
cal_svr_base/SUNWics5/cal/sbin/start-cal
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit one or more of the following ics.conf parameters shown in the following table:
Parameters |
Description and Default Value |
---|---|
If "yes", allow set_userprefs to modify the user preference "cn" (LDAP user's common name). The default is “no”. |
|
If "yes", allow set_userprefs to modify the user preference "givenname" (LDAP user's given name). The default is “no”. |
|
If "yes", allow set_userprefs to modify the user preference “icsCalendar" (a user's default calendar identifier). The default is “no”. |
|
If "yes", allow set_userprefs to modify the user preference "mail" (user's email address). The default is “no”. |
|
preferredlanguage |
If "yes", allow set_userprefs to modify the user preference "preferredlanguage" (LDAP user's preferred language). The default is “no”. |
If "yes", allow set_userprefs to modify the user preference "sn" (LDAP user's surname). The default is “no”. |
|
If "yes", enables LDAP proxy authorization for get_userprefs. If "no", anonymous LDAP search is performed. The default is “no”. |
Save the file as ics.conf.
Restart Calendar Server.
cal_svr_base/SUNWics5/cal/sbin/start-cal
This section contains procedures for customizing server-side configuration by editing the ics.conf file, and contains the following topics:
The calendar store is configured by default as shown in The following table. If you wish to reconfigure the store, perform the following steps:
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit one or more of the parameters in the following table:
Parameter |
Description and Default Value |
---|---|
calstore.calendar.create.lowercase |
Specifies whether Calendar Server should convert a calendar ID (calid) to lowercase when creating a new calendar or when looking up a calendar using the LDAP CLD plug-in. The default is “no”. |
calstore.default.timezoneID |
Time zone ID to be used when importing files, and no other time zone ID's can be found for any of the following: an event, a calendar, a user. The default is "America/New_York” An invalid value causes the server to use the GMT (Greenwich Mean Time) time zone. |
calstore.filterprivateevents |
Specifies whether Calendar Server filters (recognizes) Private and Confidential (Time-and-Date-Only) events and tasks.If "no", Calendar Server treats them the same as Public events and tasks. The default is “yes”. |
calstore.group.attendee.maxsize |
Maximum number of 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”. |
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”. |
Save the file as ics.conf.
Restart Calendar Server.
cal_svr_base/SUNWics5/cal/sbin/start-cal
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit one or more of the parameters shown in the following table:
Parameter |
Description and Default Value |
---|---|
logfile.admin.logname |
This log file contains history of the administrative tool commands issued. The default is "admin.log". |
logfile.buffersize |
Size in bytes for log buffers. The default is "0". Specify the size of each entry in the log files. If your buffers fill up too fast, consider making them larger. |
logfile.dwp.logname |
Name of the log file for logging Database Wire Protocol related administrative tools. The default is "dwp.log". Specify one per front-end server. |
logfile.expirytime |
Number of seconds before the log files expire. The default is "604800". After this time, a cleanup routine will purge the log. If you want to archive the log, you must write your own routine. |
logfile.flushinterval |
Number of seconds between the flushing of buffers to log files. the default is "60". If your system experiences a high volume of log information and your buffers fill up before 60 seconds, you will lose information. In that case consider decreasing this time interval. Note that decreasing the time interval increases system overhead. |
logfile.http.logname |
Name of the current log file for the cshttpd service. The default is "http.log". |
logfile.http.access.logname |
Name of the current HTTP access log file. |
logfile.logdir |
Directory location of the log files. The default is "/var/opt/SUNWics5/logs". |
logfile.loglevel |
Determines the level of detail the server will log. Each log entry is assigned one of these levels (starting with the most severe): CRITICAL, ALERT, ERROR, WARNING, NOTICE, INFORMATION, and DEBUG. The default is “NOTICE”. If you set to CRITICAL, Calendar Server logs the least amount of detail. If you want the server to log the most amount of detail, specify DEBUG. Each succeeding log level also gives you all the more severe log levels before it. For example, if set to WARNING, only CRITICAL, ERROR, and WARNING level log entries are logged. If set to DEBUG, all levels are logged. |
logfile.maxlogfiles |
Maximum number of log files in the log directory. The default is "10". Before the system tries to create the 11th log, it runs the clean up routine to purge old log files. |
logfile.maxlogfilesize |
Maximum disk space in bytes for all log files. The default is "2097152". When creating the next log file will violate this limit, the system tries to free disk space by deleting the oldest logs. |
logfile.minfreediskspace |
Minimum free disk space (in bytes) that must be available for logging. When this value is reached, Calendar Server attempts to free disk space by expiring old log files. Logging is paused if space cannot be freed up. The default is "5242880". |
logfile.notify.logname |
Name of the log file for the csnotifyd service. The default is "notify.log". |
logfile.rollovertime |
Number of seconds before the log files are rotated. That is, the time interval between creation opening of new log files. The default is "86400". |
logfile.store.logname |
Name of the log file for the calendar store. The default is "store.log". |
Save the file as ics.conf.
Restart Calendar Server.
cal_svr_base/SUNWics5/cal/sbin/start-cal
To configure transaction logging for the calendar database, see Chapter 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.
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit one or more of the following ics.conf parameters as shown in following table:
Parameter |
Description and Default Value |
---|---|
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. |
Save the file as ics.conf.
Restart Calendar Server.
cal_svr_base/SUNWics5/cal/sbin/start-cal
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:
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit the parameter that follows:
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”. |
Restart Calendar Server for the new value to take effect.
Verify that administrator proxy logins are working by using the following WCAP command:
http://server[:port]/login.wcap? user=admin-user&password=admin-password &proxyauth=calendar-user |
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.
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit one or more of the parameters shown in the following table:
Parameter |
Description/Default |
---|---|
Base DN for LDAP authentication. If not specified, local.ugldapbasedn is used. If not specified, the server uses the value of local.ugldaphost. |
|
Host for LDAP authentication. If not specified, uses the value of local.ugldaphost. The default is "localhost". |
|
Bind credentials (password) for user specified in local.authldapbinddn. |
|
DN used to bind to LDAP authentication host to search for user's dn. If not specified or blank (" "), its assumed to be an anonymous bind. |
|
Port for LDAP authentication. If not specified, uses the value of local.ugldapport. The default is "389". |
|
Minimum number of LDAP client connections that are maintained for LDAP authentication. If not specified, uses the value of local.ugldappoolsize. The default is "1". |
|
Maximum number of LDAP client connections that are maintained for LDAP authentication. If not specified, uses the value of local.ugldapmaxpool. The default is "1024". |
|
Specifies the authentication filter used for user lookup. The default is "(uid=%U)" This value is stored in the inetDomainSearchFilter attribute in the domain entry. It is possible to filter on a different attribute. For example, you could set this parameter to "(mail=%U)" The uid of the authenticated user is passed on to all other functions as the identity for that user, regardless of the attribute used for authentication. |
|
Number of seconds to delay after successfully authenticating a user with plain text passwords. The default is "0". |
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit one or more of the parameters as shown in The following table:
Parameter |
Description and Default Value |
---|---|
Maximum number of authenticated user ID's (uids) and passwords that Calendar Server will maintain in the cache. The default is “10000”. |
|
Number of seconds since the last access before a uid and password are removed from the cache. The default is “900”. |
Save the file as ics.conf.
Restart Calendar Server.
cal_svr_base/SUNWics5/cal/sbin/start-cal
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit the following parameter as shown in the following table:
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”. |
Save the file as ics.conf.
Restart Calendar Server.
cal_svr_base/SUNWics5/cal/sbin/start-cal
See also, Chapter 10, Configuring Automatic Backups (csstored).
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit one or more of the parameters as shown in the following table:
Parameter |
Description and Default Value |
---|---|
If "yes", start the csadmind database checkpoint thread. If “no”, no checkpoint log files created. The default is “yes”. |
|
Maximum cache size (in bytes) for Berkeley Database for administration sessions. The default is “8388608”. |
|
If "yes", start the csadmind database deadlock detection thread. The default is “yes”. |
|
If "yes", start the csadmind low disk space monitor thread. The default is “no”. Disk usage is not monitored by default. |
|
If "yes", start the csadmind service when starting all services and stop csadmind when stopping all services. The default is “yes”. |
|
Number of seconds before timing out an HTTP connection in csadmind. The default is “120”. |
|
Maximum number of administration sessions allowed. The default is “100”. |
|
Maximum number of running threads per administration session. The default is “10”. |
|
Maximum number of a concurrent administration processes allowed. |
|
No default. This parameter is set by the system. 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. |
|
Number of seconds before timing out an administration connection. The default is “900”. |
|
If "yes", start the csadmind service response thread. The default is “no”. |
|
Temporary directory for administration session requests. No default. |
|
Number of seconds before timing out an HTTP session in csadmind. The default is “1800”. |
|
Number of seconds to wait between checking for started, stopped, or ready calendar service. The default is “2”. |
|
Number of seconds to wait for any calendar service to start. The default is “300”. |
|
Number of seconds to wait for any calendar service to stop. The default is “300”. |
|
Number of seconds to wait between sending stop commands to any calendar service. The default is “60”. |
Save the file as ics.conf.
Restart Calendar Server.
cal_svr_base/SUNWics5/cal/sbin/start-cal
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit one or more of the parameters as shown in the following table:
Parameter |
Description and Default Value |
---|---|
Space separated list of user ID's with administration rights to this Calendar Server. The default is “calmaster”. |
|
If "yes", allow login via proxy. The default is “no”. |
|
If "yes", allow anonymous (no authentication) access. This is a special type of login that is allowed only specified, restricted access (usually read only access to public calendars). The default is “yes”. |
|
HTTP host for retrieving HTML documents. To enable users to use a fully qualified host name to access calendar data, this value must be the fully qualified host name (including the machine name, DNS domain and suffix) of the machine on which Calendar Server is running, such as mycal@sesta.com. If not specified, the local HTTP host is used. |
|
Tells the server to whether or to support cookies (yes/no). It must be set to "yes" to enable single sign-on. The default is “yes”. |
|
Maximum cache size of Berkeley DB for HTTP sessions. The default is “8388308”. |
|
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 "". |
|
If specified and not blank (" "), filter to not allow access based on TCP domains. For example, "ALL: LOCAL.sesta.com" would deny HTTP access to anyone in the sesta.com domain. Multiple filters must be separated by CR-LF (line-feed). The default is " "(blank). |
|
Directory location relative to local.queuedir (or an absolute path if specified) where imported files are temporarily stored. The default is the current directory ("."). |
|
If "yes", all requests that reference an existing session are verified as originating from the same IP address. The default is “yes”. |
|
If "yes", start the cshttpd service when starting all services and stop cshttpd when stopping all services. The default is “yes”. Caution – Disabling the HTTP service with this parameter will also disable HTTPS. |
|
Number of seconds before timing out an HTTP connection. The default is “120”. |
|
Specifies the TCP address that HTTP services will listen on for client requests. The default is "INADDR_ANY", which indicates any address. |
|
If "yes", HTTP connections to server are fully logged. The default is “no”. |
|
Maximum number of HTTP sessions in cshttpd service. The default is “5000”. |
|
Maximum number of threads to service HTTP requests in cshttpd service. The default is “20”. |
|
Maximum number of concurrently running HTTP service (cshttpd) processes that should run on a server. The default is “1”. For a server that has multiple CPU's, see Using Load Balancing Across Multiple CPU's. |
|
Port for HTTP requests from Calendar Server users. The default is “80”. |
|
If specified and not "", filter for allowing proxy login based on TCP domains. Same syntax as service.http.domainallowed. The default is "". |
|
Number of seconds before timing out an HTTP session. The default is “900”. |
|
Directory for the HTTP session database. The default is “http”. |
|
Number of seconds before timing out an HTTP session in cshttpd service. The default is “1800”. |
|
Directory relative to executable where all URL references to files are stored. The default is "" (null). |
|
service.http.tmpdir |
Temporary directory for HTTP sessions. The default is “/var/opt/SUNWics5/tmp”. |
Directory that contains the default calendar client. If allowing only WCAP access, set to "html". |
Save the file as ics.conf.
Restart Calendar Server.
cal_svr_base/SUNWics5/cal/sbin/start-cal
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit one or more of the following ics.conf parameters as shown in the following table:
Save the file as ics.conf.
Restart Calendar Server.
cal_svr_base/SUNWics5/cal/sbin/start-cal
You can configure the Calendar Server to periodically check for deadlocks in the Berkeley databases.
It is possible for the Berkeley databases to get into a deadlocked state, thus preventing access to them. To detect this state as early as possible, enable periodic checking for deadlocks.
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit the parameter shown in the following table:
Parameter |
Description/Default |
---|---|
Periodically checks if the Berkeley database is in a deadlock state and, if so, instructs the database to reset. The default value is “no” (not enabled). |
Save the file as ics.conf.
Restart Calendar Server.
cal_svr_base/SUNWics5/cal/sbin/start-cal
For information about how to reset Berkeley databases once deadlocked, see Detecting Database CorruptionList of Available Tools in the Troubleshooting chapter.
In general, anonymous access is allowed by default. If you want to restrict anonymous access, change the appropriate parameters.
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit one or more of the parameters in the following:
Parameter |
Description/Default |
---|---|
calstore.anonymous.calid |
Specifies the anonymous login calendar identifier (calid). The default is “anonymous”. |
service.http.allowanonymouslogin |
Specifies whether or not anonymous access is allowed without a login. The default is “yes”. (Allows recipient of emailed calendar URL to access a free-busy version of the calendar without login in.) |
service.wcap.anonymous. allowpubliccalendarwrite |
Specifies whether or not to allow anonymous users to write to a publicly writable calendar. The default is “yes”. |
service.wcap.userprefs.ldapproxyauth |
Enables anonymous search of the LDAP used for user preferences. The default is “no”, which allows anonymous access. Specifying “yes” means using proxy authentication to do the search. |
Save the file as ics.conf.
Restart Calendar Server.
cal_svr_base/SUNWics5/cal/sbin/start-cal
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit one or more of the parameters in the following table:
Parameter |
Description/Default |
---|---|
minwildcardsize |
Specifies the minimum string size for wildcard searches in an attendee lookup search. Zero (0) means always do a wildcard search. |
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. |
Name of the default domain used to lookup an attendee’s calendar ID that corresponds to an email address. For example, jsmith resolves to jsmith@sesta.com if the value for this setting is "sesta.com". |
Save the file as ics.conf.
Restart Calendar Server.
cal_svr_base/SUNWics5/cal/sbin/start-cal
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit one or more of the parameters in the following table:
In all the parameter descriptions that follow, %s allows only a single attendee.
Save the file as ics.conf.
Restart Calendar Server.
cal_svr_base/SUNWics5/cal/sbin/start-cal
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit the parameter shown in the following table:
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”. |
Save the file as ics.conf.
Restart Calendar Server.
cal_svr_base/SUNWics5/cal/sbin/start-cal
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.
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit one or more of the parameters in the following table:
Parameter |
Description/Default |
---|---|
local.lookupldap.mailtocalid.search |
Specifies the mail attributes to use for mail-to-calid lookup. The default is "(|(mail=%s)(mailalternateaddress=%s))” You can substitute the attribute mailequivalentaddress in place of mailalternateaddress. |
local.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. |
Save the file as ics.conf.
Restart Calendar Server.
cal_svr_base/SUNWics5/cal/sbin/start-cal
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit one or more of the parameters in the following table:
Parameter |
Description/Default |
---|---|
Bind credentials (password) for LDAP user preferences authentication. No default. |
|
DN used to bind to LDAP user preferences host. Must be specified. If blank (" ") or not specified, assumes an anonymous bind. |
|
Minimum number of LDAP client connections that are maintained for LDAP user preferences. The default is “1”. |
|
Maximum number of LDAP client connections that are maintained for LDAP user preferences. The default is “1024”. |
|
service.wcap.userprefs.ldapproxyauth |
Enables anonymous search of the LDAP used for user preferences. The default is “no”, which allows anonymous access. Specifying “yes” means using proxy authentication to do the search. |
Save the file as ics.conf.
Restart Calendar Server.
cal_svr_base/SUNWics5/cal/sbin/start-cal
You can restrict the preferences users are allowed to set by removing them from the default list.
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit the list of user preferences in the parameter shown in the following table:
Parameter |
Default List of User Preferences |
Description |
---|---|---|
ugldapicsextendeduserprefs |
"ceColorSet, ceFontFace, ceFontSizeDelta, ceDateOrder, ceDateSeparator, ceClock, ceDayHead, ceDayTail, ceInterval, ceToolText, ceToolImage, ceDefaultAlarmStart, ceSingleCalendarTZID, ceAllCalendarTZIDs, ceDefaultAlarmEmail, ceNotifyEmail, ceNotifyEnable, ceDefaultView, ceExcludeSatSun, ceGroupInviteAll" |
User preference values are kept in LDAP. This parameter defines which user preferences are kept in LDAP in the icsExtendedUserPrefs attribute. |
Save the file as ics.conf.
Restart Calendar Server.
cal_svr_base/SUNWics5/cal/sbin/start-cal
For overview information about the LDAP Data Cache, see LDAP Data Cache Option.
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Enable the LDAP data cache by editing the parameter as shown in the following table:
Save the file as ics.conf.
Restart Calendar Server.
cal_svr_base/SUNWics5/cal/sbin/start-cal
For information about tuning the LDAP data cache, see Improving Performance of the LDAP Data Cache.
If Calendar Server or the server where Calendar Server is running is not properly shut down, manually delete all files in the ldap_cache directory to avoid any database corruption that might cause problems during a subsequent restart.
The LDAP SDK cache is disabled by default.
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Editing one or more of the parameters as shown in the following table:
Parameter |
Description and Default Value |
---|---|
If "yes", enables LDAP SDK cache. The default is “no”. |
|
If service.ldapmemcache is "yes", this parameter is used to set the maximum number of seconds that an item can be cached. If “0”, there is no limit to the amount of time that an item can be cached. The default is “30”. |
|
If service.ldapmemcache is "yes", this parameter is used to set the maximum amount of memory in bytes that the cache will consume. If “0”, the cache has no size limit. The default is “131072”. |
Save the file as ics.conf.
Restart Calendar Server.
cal_svr_base/SUNWics5/cal/sbin/start-cal
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit one or more of the following parameters as shown in the following table:
Parameter |
Description and Default Value |
---|---|
Specifies the offset from the current time in days for get_freebusy for beginning of the range. The default is “30”. |
|
Specifies the offset from the current time in days for get_freebusy for end of the range. The default is “30”. |
Save the file as ics.conf.
Restart Calendar Server.
cal_svr_base/SUNWics5/cal/sbin/start-cal
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit the parameter as shown in the following table:
Save the file as ics.conf.
Restart Calendar Server.
cal_svr_base/SUNWics5/cal/sbin/start-cal
While it is possible to reset the root suffix for your LDAP organization tree (Schema 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.
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit one of the parameters as shown in the following table:
Parameter |
Description and Default Value |
---|---|
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. |
Save the file as ics.conf.
Restart Calendar Server:
cal_svr_base/SUNWics5/cal/sbin/start-cal
This chapter describes how to use the Calendar Lookup Database (CLD) plug-in to enable the calendar database to be distributed over multiple back-end servers. You must both enable and configure the CLD plug-in.
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:
For information on how to improve the performance of the CLD plug-in, see Chapter 21, Tuning Calendar Server Performance.
This section covers valuable overview and background information that you might want to understand before actually enabling and configuring the CLD plug-in. It contains the following topics:
The Calendar Lookup Database (CLD) plug-in provides horizontal scalability of the calendar database by allowing user and resource calendars to be distributed over a number of back-end servers for a single calendar instance. When the calendar database is distributed over several back-end servers, Calendar Server uses the CLD plug-in to determine the actual server where a calendar is stored.
Calendar Server accesses the calendar data on the back-end server using the Database Wire Protocol (DWP). DWP is an internal protocol that runs as the csdwpd service and provides the networking capability for the calendar database.
Calendar Server accesses calendar data on a back-end server as follows:
When an end user accesses a calendar through Communications Express, the CLD plug-in extracts the userid from the calendar’s calid and then looks up the calendar owner in the LDAP directory database, or the CLD data cache (if enabled). For information and instructions on configuring a front-end machine, see To Configure a Front-End Server for CLD.
After finding the calendar owner, the plug-in uses the value in the icsDWPHost LDAP attribute to determine the host name of the back-end server where the calendar resides. This host name must be resolvable by your Domain Name Service (DNS) into a valid IP address.
Using the host name, Calendar Server accesses the calendar data on the back-end server using the Database Wire Protocol (DWP).
Using DWP, Calendar Server sends the calendar data to the server where the user is logged in, so it can be rendered in one of the user interfaces.
If your site is using the CLD plug-in, all calendars created for the same user must reside on the same back-end server, as indicated by the LDAP user entry’s icsDWPHost LDAP attribute. If you try to create a calendar on a different back-end server, Calendar Server returns an error.
The CLD plug-in supports the following Calendar Server configurations:
In all configurations, each front-end and back-end server must:
Be on the same hardware platform.
Be running the same operating system.
Be running the same Calendar Server release, including patches.
Use the same port number for the DWP port (service.dwp.port parameter). The default port number is “59779”.
Figure 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–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.
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:
For our rough estimates, we are assuming the following:
All clients are Web clients.
Therefore, the only inputs to be used are: total number of users, and percent concurrency.
The average size calendar event size is 2K.
Each person creates five events or todos per week.
80% CPU utilization.
900 MHz CPU's
1 GB RAM per CPU
Two years' worth of calendar data stored on system.
The formula is:
Number of CPU's = Number of Concurrent Users divided by 4800
The formula is:
Number of CPU's = 4 CPU's per 500,000 configured users
The formula is:
Amount of Storage = 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.
This sections contains instructions for configuring servers and contains the following topics:
On every front-end server, log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit the ics.conf parameters as shown in the following table:
Save the file as ics.conf.
Restart Calendar Server.
cal_svr_base/SUNWics5/cal/sbin/start-cal
On every back-end server, log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit the ics.conf parameters as shown in the following table:
Save the file as ics.conf.
Restart Calendar Server.
cal_svr_base/SUNWics5/cal/sbin/start-cal
On every server, log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit the ics.conf parameters as shown in the following table:
Save the file as ics.conf.
Restart Calendar Server.
cal_svr_base/SUNWics5/cal/sbin/start-cal
You can configure password authentication between front-end and back-end servers. This section explains how secure communication between the two can be set up and how it works. The following topics are covered:
To Set Up Authentication for DWP Connections for a Front-end Server
To Set up Authentication for DWP Connections for a Back-end Server
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.
These parameters are not included in the installed version of the ics.conf file. To use authentication for DWP connections, you must add the required parameters to the ics.conf file on each front-end server.
On every front-end server, log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Add the ics.conf parameters as shown in the following table:
Parameter |
Description |
On a front-end server, specifies the administrator's user ID that is used for authentication for a DWP connection to a back-end server, where back-end-server is the name of the server. |
|
On a front-end server, specifies the password that is used for authentication for a DWP connection to a back-end server, where back-end-server is the name of the server. |
Save the file as ics.conf.
Restart Calendar Server.
cal_svr_base/SUNWics5/cal/sbin/start-cal
These parameters are not included in the installed version of the ics.conf file. To use authentication for DWP connections, you must add the required parameters to the ics.conf file on each back-end server.
On every back-end server, log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Add the ics.conf parameters as shown in the following table:
Parameter |
Description |
On a back-end server, specifies the user ID that is used to authenticate a DWP connection. If a back-end server does not specify a user ID, no authentication is performed. |
|
On a back-end server, specifies the password that is used to authenticate a DWP connection. If a back-end server does not specify a password, no authentication is performed. |
Save the file as ics.conf.
Restart Calendar Server.
cal_svr_base/SUNWics5/cal/sbin/start-cal
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.
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. |
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 |
This is a high level list of the steps necessary to install and configure a Calendar Server HA configuration.
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.
On each node in the cluster, perform these steps:
Create the Calendar Server runtime user and group under which Calendar Server will run as follows:
Add icsgroup (or the value you selected) to the /etc/group file.
Add icsuser (or the value you selected) to the /etc/passwd file.
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.
Add or set the following fields in the /etc/vfstab file:
mountpoint to /global/cal/ (Or, the file system mount point you selected in Selecting the Calendar Server Installation Directory.)
mount at boot option to no
mount options to logging for FFS or global,logging for GFS
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 |
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.
On node 2, follow these steps:
Install Sun Cluster and the Sun Cluster Agent for Calendar Server (SUNWscics package) using the Java Enterprise System installer.
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.
Install shared components (SUNWicu, SUNWldk, SUNWpr, SUNWsasl, and SUNWtls packages) using the pkgadd command. See Installing Shared Components.
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/
To make the required shared components available on node 2, you must install the following packages:
SUNWicu – International Components for Unicode User Files
SUNWldk – LDAP C SDK
SUNWpr – Netscape Portable Runtime Interface
SUNWsasl – Simple Authentication and Security Layer (SASL)
SUNWtls – Network Security Services
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
To configure the logical host:
Create a Calendar Server failover resource group named cal-resource-group:
# scrgadm -a -g cal-resource-group -h cal-node-2,cal-node-1 |
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 |
Bring the resource group online:
# scswitch -Z -g cal-resource-group |
To activate the storage resource:
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 |
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.
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
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.
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:
/opt/SUNWics5/cal
/opt/SUNWics5/cal/lib
/opt/SUNWics5/cal/sbin
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/
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.
Check that config is a symbolic link to the new config directory. For example:
# ls -l config ... config -\> /etc/opt/SUNWics5/config/ |
In the /opt/SUNWics5/cal/ directory, remove the config symbolic link:
# cd /opt/SUNWics5/cal # rm config |
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 . |
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/ |
Remove the config symbolic link:
# rm config |
Create a new symbolic link to the new config location:
# ln -s ../config config |
Verify the new link:
# ls -l config ... config -\> ../config/ |
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/ |
Remove the config symbolic link:
# rm config |
Create a new symbolic link to the new config location:
# ln -s ../config config |
Verify the new link:
# ls -l config ... config -\> ../config/ |
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.
In the /opt/SUNWics5/cal/config directory, edit the ics.conf configuration file as follows:
Add the following parameters:
local.server.ha.enabled="yes" local.server.ha.agent="SUNWscics" |
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.
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" |
Before you start the HA Calendar Server, register the calendar resource type SUNWscics and create a calendar resource as follows:
Register the calendar resource type:
# scrgadm -a -t SUNW.scics |
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 |
Enable the resource and start Calendar Server:
# scswitch -e -j cal-resource |
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.
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.
Sun Cluster Concepts Guide for Solaris OS provides a general background about Sun Cluster software, data services, and terminology resource types, resources, and resource groups.
Sun Cluster Data Services Planning and Administration Guide for Solaris OS provides general information on planning and administration of data services.
Sun Cluster System Administration Guide for Solaris OS provides the software procedures for administering a Sun Cluster configuration.
Sun Cluster Reference Manual for Solaris OS describes the commands and utilities available with the Sun Cluster software, including commands found only in the SUNWscman and SUNWccon packages.
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:
Calendar Server does not support client-based SSL authentication.
An SSL implementation for Calendar Server requires a certificate database. The certificate database must define a Certificate Authority (CA) and certificates for Calendar Server. This section contains conceptual and task information:
Before you create the certificate database, familiarize yourself with the following:
Mozilla Tools — This release includes the following Mozilla tools:
Certificate Database Tool (certutil) to create and manage the certificate database. For information, refer to the following Web site:
http://mozilla.org/projects/security/pki/ nss/tools/certutil.html
Familiarize yourself with the tool syntax before attempting to generate your certificate database.
Security Module Database Tool (modutil) to display information about available security modules. For information, refer to the following Web site:
http://mozilla.org/projects/security/pki/ nss/tools/modutil.html
These utilities are available in the following directory:
/opt/SUNWics5/cal/lib
or download the most recent version from the Web site.
Library Path Variable — Before you use the Mozilla tools, set your LD_LIBRARY_PATH variable appropriately. For example:
setenv LD_LIBRARY_PATH /opt/SUNWics5/cal/lib
Example Files and Directories — The examples in this chapter use these files and directories:
alias is a directory that contains the certificate database. Create the alias directory in the following directory:
/var/opt/SUNWics5
Also, make sure you backup the alias directory regularly.
sslPasswordFile is a text file that contains the certificate database password. This file is used by the certutil utility but not by Calendar Server. Create sslPasswordFile in the following directory:
/etc/opt/SUNWics5/config
/etc/passwd introduces entropy for random number generation, that is, this directory is used to generate varied and unique seeds that help ensure truly random results from the random number generator.
Log in as or become superuser (root).
Specify the certificate database password for certutil in /etc/opt/SUNWics5/config/sslPasswordFile. For example:
# echo "password" /etc/opt/SUNWics5/config/sslPasswordFile |
where password is your specific password.
Create the certificate database alias directory. For example:
# cd /var/opt/SUNWics5 # mkdir alias |
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 |
For this and other times when you must run the certutil utility, follow the examples exactly, or consult the certutil help page to understand the syntax.
For example, in this case, do not run the utility with the -N option without also specifying the -d /file information.
Generate a default self-signed root Certificate Authority certificate. For example:
# ./certutil -S -n SampleRootCA -x -t "CTu,CTu,CTu" -s "CN=My Sample Root CA, O=sesta.com" -m 25000 -o /var/opt/SUNWics5/alias/SampleRootCA.crt -d /var/opt/SUNWics5/alias -f /etc/opt/SUNWics5/config/sslPasswordFile -z /etc/passwd |
Generate a certificate for the host. For example:
# ./certutil -S -n SampleSSLServerCert -c SampleRootCA -t "u,u,u" -s "CN=hostname.sesta.com, O=sesta.com" -m 25001 -o /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.
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 |
List the certificates. For example:
# ./certutil -L -d /var/opt/SUNWics5/alias # ./certutil -L -n SampleSSLServerCert -d /var/opt/SUNWics5/alias |
Use modutil to list the available security modules (secmod.db). For example:
# ./modutil -list -dbdir /var/opt/SUNWics5/alias |
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 {}; |
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.
Log in as or become superuser (root).
Move to the bin directory:
# cd /opt/SUNWics5/cal/bin |
Use certutil to generate a Certificate Request based on the Certificate Authority or Public Key Infrastructure (PKI) Web site. For example:
# ./certutil -R -s "CN=hostname.sesta.com, OU=hostname/ SSL Web Server, O=Sesta, C=US" -p "408-555-1234" -o hostnameCert.req -g 1024 -d /var/opt/SUNWics5/alias -f /etc/opt/SUNWics5/config/sslPasswordFile -z /etc/passwd -a |
where “hostname.sesta.com” is the host name.
Request an test certificate for an SSL web server from the Certificate Authority or Public Key Infrastructure (PKI) Web site. Copy and paste the contents from the hostnameCert.req file into the Certificate Request.
You will be notified by when your certificate is signed and can be picked up.
Copy the Certificate Authority Certificate Chain and SSL server certificate into text files.
Import the Certificate Authority Certificate Chain into the certificate database to establish a Chain of Authority. For example:
# ./certutil -A -n "GTE CyberTrust Root" -t "TCu,TCu,TCuw" -d /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 |
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 |
List the certificates in the certificate database:
# ./certutil -L -d /var/opt/SUNWics5/alias |
Configure the SSL Server Nickname in the ics.conf file to be the signed SSL server certificate, For example: “hostname SSL Server Test Cert”.
Note The host name for the service.http.calendarhostname and service.http.ssl.sourceurl parameters in the ics.conf file should match the host name on the SSL certificate (in case your system has several aliases). For example: calendar.sesta.com
To implement SSL with Calendar Server, you must set specific parameters in the ics.conf file. If any of the parameters listed in the following table are not in the ics.conf file, add them to the file with the value specified. Since the ics.conf is read only at system startup (when start-cal is issued), the new values will not take effect until the Calendar Server is restarted. For a description of these SSL parameters, see SSL Configuration.
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit one or more of the parameters as shown in the following table:
Parameter |
Value |
---|---|
encryption.rsa.nssslactivation |
“on” |
encryption.rsa.nssslpersonalityssl |
“SampleSSLServerCert” |
encryption.rsa.nsssltoken |
“internal” |
service.http.tmpdir |
“/var/opt/SUNWics5/tmp” |
service.http.uidir.path |
“html” |
service.http.ssl.cachedir |
“.” |
service.http.ssl.cachesize |
“10000” |
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” |
Save the file as ics.conf.
Restart Calendar Server for the changes to take effect.
cal_svr_base/SUNWics5/cal/sbin/start-cal
First, always backup your certificate database on a regular basis in case unrecoverable problems occur. If you have problems with SSL, here are some things to consider:
SSL requires the Calendar Server cshttpd process to be running. To determine if cshttpd is running, use this command:
# ps -ef | grep cshttpd
To list the certificates in the certificate database and checking their validity dates, use this command:
# ./certutil -L -d /var/opt/SUNWics5/alias
Check the Calendar Server log files for any SSL errors. For more information see Using Calendar Server Log Files.
Connect to the SSL port using a browser and the following URL:
https://server-name:ssl-port-number
where:
server-name is the name of the server where Calendar Server is running.
ssl-port-number is the SSL port number as specified by the service.http.ssl.port parameter in the ics.conf file. The default is 443.
HTTP and HTTPS listen on different ports (443 for SSL, and 80 for HTTP), so you will never have both listening to the same port. Currently, there is no way to tell cshttpd to stop listening to the regular HTTP port. However, an administrator can change the service.http.port to an undisclosed number.
Do not set service.http.enable ="no" in an attempt to prevent cshttpd from listening to HTTP. Doing so would cause HTTPS to fail also. Both service.http.enable and service.http.ssl.port.enable must be set to "yes" for SSL to be configured properly.
This chapter describes how to configure single sign-on (SSO).
Single sign-on (SSO) allows a user to authenticate once and then use multiple trusted applications without having to authenticate again. Sun Java System communications servers, including Calendar Server and Messaging Server, can implement SSO as follows:
Sun Java Enterprise System servers, including Calendar Server and Messaging Server, can implement SSO using Sun Java System Access Manager (release 6 2003Q4 or later)
Access Manager serves as the SSO gateway for Sun Java Enterprise System servers. That is, users log in to Access Manager and then can access other Sun Java Enterprise System servers, as long as the servers are configured properly for SSO.
Make sure that Access Manager and Directory Server are installed and configured. For information about installing and configuring these products, refer to the Sun Java Enterprise System 2005Q4 Installation Guide for UNIX.
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.
When you set the local.calendar.sso.amnamingurl parameter, you must use a fully qualified name for Access Manager.
To configure SSO for Messaging Server, refer to the Sun Java System Messaging Server 6 2005Q4 Administration Guide.
Users log into Access Manager using their Directory Server LDAP user name and password. (A user who logs in through another server such as Calendar Server or Messaging Server will not be able to use SSO to access the other Sun Java Enterprise System servers.)
After logging in, users can access Calendar Server through Communications Express using the appropriate URL. Users can also access other Sun Java Enterprise System servers such as Messaging Server, if the servers are configured properly for SSO.
A calendar session is valid only as long as the Access Manager session is valid. If a user logs out of Access Manager, the calendar session is automatically closed (single sign-off).
SSO applications must be in the same domain.
SSO applications must have access to the Access Manager verification URL (naming service).
Browsers must support cookies.
If you are using the Sun Java System Portal Server gateway, set the following Calendar Server parameters:
service.http.ipsecurity="no"
render.xslonclient.enable="no"
When configuring SSO through Communications Servers trusted circle technology (that is, not through Access Manager), consider these points:
Each trusted application must be configured for SSO.
SSO does not work correctly if the default.html page is in your browser’s cache. Before using SSO, be sure to reload the default.html page in your browser. For example, in Netscape Navigator, hold down the Shift key and then click Reload.
SSO works only for bare URL's. For example, SSO works for:http://servername.
The following table describes the Calendar Server configuration parameters for SSO through Communications Servers trusted circle technology.
Table 9–1 Calendar Server SSO Parameters Through Communications Servers Trusted Circle Technology
The following table describes the Messaging Server configuration parameters for SSO through Communications Servers trusted circle technology.
Table 9–2 Messaging Server SSO Parameters Through Communications Servers Trusted Circle Technology
For more information about configuring Messaging Server for SSO, see the Sun Java System Messaging Server 6 2005Q4 Administration Guide.
At configuration time you are given the opportunity to enable automatic backups. However, you can also enable or disable automatic backups at any time thereafter. A good backup system is essential to safeguard your data and minimize operational downtime.
Information in this chapter explains how to configure the Calendar Server service csstored to perform automatic backups. It contains the following sections:
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.
This section covers the following topics:
The Calendar Server system records each transaction for the calendar database (additions, modifications or deletions to calendars and their properties) in a transaction log file. At some predetermined interval, the log file is closed for writing and another is created. The system then applies the transactions from the oldest closed transaction log to the live calendar databases as time permits. When all the transactions in the log have been applied to the database, the log is marked as “already applied”.
When hot backups are configured, a snapshot of the live databases is taken every 24 hours. The already applied logs are then applied to the hot backup copy of the databases. The hot backup databases are as current as the number of transactions still waiting to be applied.
One of the Calendar Server services launched at startup is csstored. When configured, this service performs automatic backups (either hot backups or archival backups, or both) of your calendar databases.
You can configure csstored for automatic backups when you run the configuration program, csconfigurator.sh. If you choose one or both of the automatic backups at that time, no further configuration steps are necessary.
If 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).
When automatic backups are disabled, the circular logging ics.conf parameter, caldb.berkeley.circularlogging, should be set to “yes”. This enables purging of old database transaction logs, which conserves disk space.
With automatic backups enabled, csstored automatically manages the number of backup copies retained in your backup database files using a circular backup system.
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.
The following is a high-level list of the tasks to perform to enable automatic backups:
This section covers the following topics:
Transaction log files are used by Calendar Server to capture all of the additions, modifications and deletions made to the calendar database since the latest snapshot. The transactions are not actually applied to the live database until the log file is closed for writing. The interval parameter specifies how often the old log files are closed and new log files are created.
The log file names consist of a configurable name with a unique number appended to the end.
As the log files are closed, they are ready to be applied to the live database. This happens asynchronously, meaning the creation of log files and the writing of transactions into them is done in “real time”, whereas the program applying the transactions to the database is running independently, without regard to the writing of the transactions into the log files. If the system is very busy, the number of log files awaiting application to the database can rise. When the system has slow periods, the program applying the transactions has time to “catch up” and may actually sit idle, waiting for the next transaction log.
After the transactions have been applied to the live database, they are applied to the hot backup snapshot (if enabled). The log files are also written to the same archive directory where the snapshot resides.
At a command line, change to the directory where the ics.conf is located:
cd/etc/opt/SUNWics5/config
Specify the transaction log name:
logfile.store.logname=storename.log
Specify the directory path for the transaction log directory:
The default value is: logfile.logdir="logs"
When you have completed editing the ics.conf file, restart Calendar Server:
cal_svr_base/SUNWics5/cal/sbin/start-cal
Calendar services do not need to be stopped to edit the ics.conf file, but you must restart the services in order for the changes to take effect.
This section covers the following topics:
When certain events or errors occur, the administrator is notified by email. The events causing an email message to be generated are:
Automatic backups not enabled or not configured properly.
Every 24 hours, when its time to take a snapshot, if automatic backups are not enabled, the csstored process reports that automatic backups are not properly configured.
The disk space threshold has been exceeded.
This message is sent out periodically until the condition has cleared.
A service has stopped and can’t be restarted.
The notification email will explain what required action is needed before the service can be started.
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit the ics.conf parameter that follows to specify the administrator’s email address:
alarm.msgalarmnoticercpt=”admin@email_address”
Save the file as ics.conf.
Restart Calendar Server.
cal_svr_base/SUNWics5/cal/sbin/start-cal
The calendar services do not need to be stopped to edit the ics.conf file, but you must restart the services in order for the changes to take effect.
This section covers the following topics:
Ideally, hot backups consist of the latest snapshot with all of the transaction logs applied to the it, except the transaction log currently being written. The system can get behind in applying the transaction logs, depending on how busy the system is. It is possible that there might be several log files that have not yet been applied to either the database or the hot backup.
This “almost duplicate” of the live database is designed to minimize down time and data loss if something catastrophic happens, or if a corruption of the database is detected.
A new hot backup is started every 24 hours when a new snapshot is taken. The old hot backup is verified and kept until purged. For more information, see How Circular Backups Work.
At a command line, change to the directory where the ics.conf is located:
cd /etc/opt/SUNWics5/config
Enable hot backups by setting the following ics.conf parameter to “yes”:
caldb.berkeleydb.hotbackup.enable=”yes”
Specify the directory path for the hot backup directory:
caldb.berkeleydb.hotbackup.path= /var/opt/SUNWics5/hotbackup_directory
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).
When you have completed editing the ics.conf file, restart Calendar Server:
cal_svr_base/SUNWics5/cal/sbin/start-cal
The calendar services do not need to be stopped to edit the ics.conf file, but you must restart the services in order for the changes to take effect.
This section covers the following topics:
Archive backups consist of a snapshot and the log files that were created for it. The log files are not applied to the snapshot. The archive databases remain on disk until purged. See How Circular Backups Work.
At a command line, change to the directory where the ics.conf is located:
cd /etc/opt/SUNWics5/config
Enable archive backups by setting the following ics.conf parameter to “yes”:
caldb.berkeleydb.archive.enable=”yes”
Specify the directory path for the archive directory:
caldb.berkeleydb.archive.path= /var/opt/SUNWics5/archive_backup_directory
You might choose to place the archive backups on an alternate disk or disk subsystem in case of a hardware failure on the primary disk drive. Doing this might also reduce I/O contention on the primary drive or subsystem.
If you have a high availability (HA) configuration, specify the path as a subdirectory in shared storage (/global/cal/ ). See also, Chapter 7, Configuring for High Availability (Failover Service).
When you have completed editing the ics.conf file, restart Calendar Server:
cal_svr_base/SUNWics5/cal/sbin/start-cal
The calendar services do not need to be stopped to edit the ics.conf file, but you must restart the services in order for the changes to take effect.
This section describes the daily warning message from an unconfigured csstored process and how to stop it. This section contains the following topics:
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.
Log in as an administrator with permission to change the configuration.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Add the parameter that follows to the ics.conf file to disable csstored from running:
service.store.enable="no"
Save the file as ics.conf.
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.
Be sure not to disable csstored on machines where you have csstored configured for automatic backups.
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:
The Sun Java System Communications Services 6 2005Q4 Deployment Planning Guide discusses all the steps necessary to prepare your installation to use hosted domains.
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.
This section provides an overview of hosted domains, including:
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:
Sun LDAP Schema 2 (compatibility or native mode)
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:
New Installation — If your site is installing Calendar Server 6 2005Q4 as a new installation, use LDAP Schema 2.
Upgrade — If your site is upgrading from Calendar Server version 5, use the schema version as follows:
If you want to use Access Manager features such as single sign-on (SSO), or if you want to use Delegated Administrator, choose LDAP Schema 2.
If you do not have hosted domains, don’t want to use Access Manager features, or don't want to provision users with Delegated Administrator, you can use either schema version. However, use LDAP Schema 2, if possible.
The following graphic shows an LDAP directory organization for a hosted domain installation that uses Sun LDAP Schema 2.
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).
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)
DC tree
Organization (OSI) tree
The DC tree (node) is similar to the DNS, which determines a domain entry given the domain name. The inetdomainbasedn LDAP attribute points to the base DN, which is the root of the domain’s users, resources and groups in the organization tree (node). Within each domain, the identifiers for Calendar Server users, resources, and groups must be unique.
If your earlier LDAP configuration did not contain a DC tree, in order to use Schema 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:
In the DC tree, the search operation locates the domain entry that contains the value of the DN pointing to the base DN (inetDomainBaseDN attribute) of domain in the organization tree.
In the organization tree, the search operation locates the domain entry and then searches from that entry’s base DN to find the user, resource, or group within the domain.
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.
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:
Each domain can specify an access control list (ACL) in the domainAccess property of the icsExtendedDomainPrefs attribute that grants or denies cross domain searches from other domains. Thus, a domain can allow or disallow either specific domains, or all domains, from searching it.
For a description of domainAccess, see LDAP Attributes and Property Names. For general information about ACLs, see Access Control Lists (ACLs).
Each domain can specify the external domains its users can search. The icsDomainNames LDAP attribute specifies the external domains that a domain’s users can search when looking for users and groups (as long as the ACL for the external domain allows the search).
For example, if icsDomainNames for the various.org domain lists sesta.com and siroe.com, users in various.org can perform cross domain searches in sesta.com and siroe.com. For a description of icsDomainNames, see LDAP Attributes and Property Names.
For instructions on how to enable cross domain searches, see Enabling Cross Domain Searches.
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.
This section covers the basic tasks that you might need to perform before creating new hosted domain entries in your LDAP:
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.
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.
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 |
---|---|
Enables ("yes") or disables ("no") support for hosted (virtual) domain mode. Default is "no". |
|
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. |
Specifies the root suffix underneath which all domains are found, if local.schemaversion="2". For example: "o=sesta.com". |
|
Specifies the default domain for this instance of Calendar Server. Used when a domain name is not supplied during a login. For example: "red.sesta.com". |
|
Specifies a string of separators used for the login-separator when Calendar Server parses "userid[login-separator]domain". Calendar Server tries each separator in turn. Default is "@+". |
|
Specifies the user ID of the domain administrator. For example: DomainAdmin@sesta.com. |
|
Controls cross domain searching:
|
|
Specifies the language for the domain. Default is "en" (English). |
Create a default domain entry.
For Schema 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
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
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
Enable calendaring services for the new hosted domains, as explained in Setting up a Hosted Domain Environment.
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
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
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:
Perform an LDAP dump of the existing calmaster LDAP entry and save it in a temporary file, such as /tmp/calmaster.ldif.
Delete the existing calmaster LDAP entry on the organization tree root suffix using ldapdelete, as follows:
#ldapdelete -D "cn=Directory Manager" -w password uid=calmaster,ou=People,o=rootsuffix
Modify the calendar administrator’s group entry (update the uniqueMember attribute) to reflect the changes as shown in the LDIF example that follows:
dn:cn=Calendar Administrators,ou=Groups,o=rootsuffix changetype:modifyreplace:uniqueMember uniqueMember:uid=calmaster,ou=People,o=sesta.com,o=rootsuffix |
It is not necessary to move the group entry to the hosted domain.
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.
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:
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:
Object class: icsCalendarDomain.
Attribute:icsStatus. Set the value to “active”.
Attribute: icsExtendedDomainPrefs. Set the value of attribute option domainAccessto the ACL you want to use for access control.
You can do this in one of two ways: use csattribute add command or use ldapmodify as shown in the example that follows:
dn:dc=sesta,dc=com,o=internet changetype:modify add:objectclass objectClass:icsCalendarDomain add:icsStatus icsStatus:active add:icsExtendedDomainPrefs icsExtendedDomainPrefs:domainAccess=@@d^a^slfrwd^g;anonymous^a^r^g;@^a^s^g |
If 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:
Use the Delegated Administrator Utility command commadmin domain modify with the -S option to add calendar service to each domain.
Alternately, you can use the Delegated Administrator Console to allocate service packages containing calendar service to the affected domains. To do this, use the Allocate Service Packages button on the Organization List page.
Use the Delegated Administrator Utility command commadmin user modify with the -S option to add calendar service to each user in each domain you enabled for calendar.
Alternately, you can use the Delegated Administrator Console to assign a service package containing calendar service to each user in the affected domains. To do this, use the Assign Service Package button on the User List page in each affected organization.
For the commadmin commands, see the Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide.
For more information about Delegated Administrator Console, see its online help.
For commdirmig information, see the Sun Java System Communications Services 6 2005Q4 Schema Migration Guide)