test

Sun Java System Calendar Server 6 2005Q4 Administration Guide

Chapter 12 Administering Calendar Server

This chapter and those that follow in Using Domains Created by Messaging Server describe how to administer Calendar Server, and contains the following sections:

You manage Calendar Server by running either the Delegated Administrator utility (formerly the User Management Utility) or the Calendar Server command-line utilities and by editing the ics.conf configuration file.

To run the command-line utilities, you must log in as a user who has administrative rights to the system where Calendar Server is running.

For more information, see Appendix D, Calendar Server Command-Line Utilities Reference.

Note –

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

Starting and Stopping Calendar Server

This section covers how to use start-cal and stop-cal and contains the following topics:

About start-cal and stop-cal

You can start and stop Calendar Server using the start-cal and stop-cal commands. The start-cal and stop-cal utilities are located in the cal_svr_base/SUNWics5/cal/sbin directory. You must run these utilities on the local machine where Calendar Server is installed.

Note –

Calendar Server provides the csstart and csstop utilities only for compatibility with earlier releases. If possible, use the start-cal and stop-cal utilities to start and stop Calendar Server.

The start-cal utility starts Calendar Server services in the following order:

  1. enpd— Event Notification Service (ENS)

  2. csnotifyd— Notification Service

  3. csadmind— Administration Service

  4. csdwpd— Database Wire Protocol (DWP) service, the distributed database service starts only if you have a remote Calendar Server database configuration

  5. cshttpd— HTTP Service

  6. csstored— Automatic Backup Service

For a description of these services, seeCalendar Server Services

ProcedureTo Start Calendar Server with start-cal

  1. Log in as a user who has administrative rights to the system.

  2. Change to the cal_svr_base/SUNWics5/cal/sbin directory.

  3. Start Calendar Server:


    ./start-cal

ProcedureTo Stop Calendar Server with stop-cal

  1. Log in as a user who has administrative rights to the system where Calendar Server is running.

  2. Change to the cal_svr_base/SUNWics5/cal/sbin directory.

  3. Stop Calendar Server:


    ./stop-cal

Enabling or Disabling Automatic Backups

Automatic backups are managed by the csstored process that starts up automatically when start-cal is issued. However, you can either enable or disable automatic backups at will. The default is for automatic backups to be disabled. The csstored process runs even if automatic backups are not enabled.

There are two kinds of automatic backups: hot backups and archival backups. You enable or disable them separately.

The csstored process must be configured before you issue start-cal, or you will receive an error message informing you that csstored is not configured. You will receive the same message every 24 hours thereafter until it is configured.

For information on automatic backups and instructions on configuring csstored, see Chapter 10, Configuring Automatic Backups (csstored).

The following is a list of tasks for enabling and disabling automatic backups:

ProcedureTo Enable Hot Backups

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

    cd /etc/opt/SUNWics5/config

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

    caldb.berkeleydb.hotbackup.enable="yes"

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

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

    The default is the current directory.

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

    cal_svr_base/SUNWics5/cal/sbin/start-cal

    The calendar services do not need to be stopped to edit the ics.conf file, but you must restart the services in order for the changes to take effect.

ProcedureTo Enable Archive Backups

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

    cd /etc/opt/SUNWics5/config

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

    caldb.berkeleydb.archive.enable=”yes”

  3. Specify the directory path for the archive directory:

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

    The default is the current directory.

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

    cal_svr_base/SUNWics5/cal/sbin/start-cal

    The calendar services do not need to be stopped to edit the ics.conf file, but you must restart the services in order for the changes to take effect.

ProcedureTo Disable Hot Backups

Backups are disabled by default. If you have previously enabled them and want to disable them, perform the following steps:

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

    cd /etc/opt/SUNWics5/config

  2. Disable hot backups by setting the following ics.conf parameter to "no":

    caldb.berkeleydb.hotbackup.enable="no"

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

ProcedureTo Disable Archive Backups

Backups are disabled by default. If you have previously enabled them and want to disable them, perform the following steps:

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

    cd /etc/opt/SUNWics5/config

  2. Disable archive backups by setting the following ics.conf parameter to "no":

    caldb.berkeleydb.archive.enable="no"

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

Managing the Group Scheduling Engine Queue

The Group Scheduling Engine (GSE) keeps a queue of events that will be used to update the component database. An administrator can change the timeout value to adjust the time between Calendar Server scans of the queue. Events in the queue can also be listed and specific events deleted if necessary.

This section contains the following topics:

About GSE

The GSE allows a Calendar Server user to create events and invite other attendees. If an attendee is on the same Calendar Server, the event is scheduled in the attendee’s calendar. If an attendee is not on the same Calendar Server, the invitation is sent via email. The attendee can then accept or decline the invitation and the GSE will update the event with the reply.

About the GSE Queue

The GSE queue is in reality a separate database managed by the GSE. Calendar Server scans the queue for updates that need to be made to the components database.

You can tune Calendar Server by adjusting the frequency of this scan. This is accomplished by changing the timeout value of gse.belowthresholdtimeout in the ics.conf file. See Chapter 21, Tuning Calendar Server Performance.

The GSE queue entries can be managed (listed and deleted) using csschedule. You must run csschedule on the local machine where Calendar Server is installed.

Listing Entries in the GSE Queue

To list entries in the GSE queue, use the csschedule utility list command.

For example, to list all entries in the GSE queue:


csschedule list

To list the first ten entries stored in the GSE queue:


csschedule -c 10 list

To list all entries in the GSE queue for a calendar with the calid Holiday_Schedule:


csschedule -v list Holiday_Schedule

Deleting Entries in the GSE Queue

To delete entries in the GSE queue, use the csschedule utility delete command.

For example, to delete all entries in the GSE queue:

csschedule -v delete

To delete the entry in the GSE queue for calendar calA with the first schedule time of 13:30:45 on 11/30/2001, an offset number of 1, the unique identifier 1111, the recurrence ID 0, and the sequence number 0:

csschedule -v -t 20011130T133045Z -o 1 -u 1111 -r 0 -n 0 delete calA

Monitoring Calendar Server

You will want to monitor system activity as part of your daily tasks. There are several utility tools available to you for monitoring Calendar Server activity: csmonitor, csstats, cstool. In addition, you can set up many log files to help monitor system usage.

This section covers the following topics:

About csmonitor

This Calendar Server utility is a shell script that requires bash. When invoked, this utility performs the following functions:

For debugging purposes, you can configure the monitor to run in a continuous loop with very short intervals, but this requires more system resources, so you don’t want to keep it in that mode during normal production.

To use csmonitor under normal circumstances, set it to run with an interval that you choose.

For more information about the csmonitor utility, see Appendix D, Calendar Server Command-Line Utilities Reference.

ProcedureTo Configure csmonitor

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

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

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

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

    Parameter  

    Description and Default Value  

    service.monitor.continuous

    Specifies whether csmonitor should loop continuously:"0" – Do not loop continuously (the default)."1" – Loop continuously.

    Set this parameter to “1” to enable csmonitor to run automatically.

    service.monitor.loopsdelay

    Specifies the delay in seconds between two monitoring loops. The default is “60” seconds. 

    For debugging purposes, make the interval shorter and for production, make the interval much longer. 

    service.monitor.emailaddress.from

    Specifies the email address csmonitor sends messages from. No default given.

    service.monitor.emailaddress.to

    Specifies the email address csmonitor should send messages to. No default given.

    service.monitor.csdb.logthreshold 

    Monitors the calendar database (csdb). Specifies a threshold value, as a percent of the total disk space, for maximum disk occupation. If the disk occupation for the csdb directory exceeds this value, it sends a warning email message. The default is “90”.

    logfile.monitor.logname

    Specifies the csmonitor log file name. The default is “csmonitor.log”.

    logfile.monitor.maxlogfilesize

    Specifies the maximum log file size. If the log file exceeds this size, csmonitor saves the log as csmonitor.log.timestamp and resets the current log. The default is “2097152”

    service.monitor.dbglevel

    Specifies the debug level. With a range of 0-5, the higher this value, the more precise and verbose messages sent by csmonitor. The default is “0”, which specifies no logging. A value of “5” would indicate debug logging.

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal_svr_base/SUNWics5/cal/sbin/start-cal

Listing Counter Statistics

The csstats utility displays statistical information from counter objects defined in the calendar configuration (counter.conf) files. Counter objects such as httpstat, authstat, wcapstat, or dbstat show information about Calendar Server including:

For information about Calendar Server counter statistics, see Appendix E, Calendar Server Configuration Parameters.

Using cstool for Monitoring

You can ping the following services as well as the machine where Calendar Server is installed:

For information about using cstool, see Appendix D, Calendar Server Command-Line Utilities Reference.

Using Calendar Server Log Files

Each Calendar Server service writes status information to its own log file. Each log file is named after its associated service name, as shown in the following table:

Service Name 

Log File Name 

Administration Service (csadmind) 

admin.log 

Distributed Database Service (csdwpd) 

dwp.log 

HTTP Service (cshttpd) 

http.log 

Notification Service (csnotifyd) 

notify.log 

Single Sign-on log 

am_sso.log 

Log of start commands 

start.log 

Log of stop commands 

stop.log 

Log of store commands 

store.log 

Calendar Server log files are stored in the following default directory:

/var/opt/SUNWics5/logs

Each log file is rolled-over to a new log file identified by a unique number. For example:

admin.log.8.1083013284 http.log.8.1083013284

Calendar Server provides six levels of severity for events reported to the log files as described in the following table. You can specify the level of severity of the events that Calendar Server reports to the log files by modifying the ics.conf parameter logfile.loglevel.

Severity Level 

Meaning 

CRITICAL 

Critical condition. 

ERROR 

Error condition. 

WARNING 

Warning condition. 

NOTICE 

Normal, but signification condition. This is the default reporting level for each calendar service. 

INFORMATION 

Informational. 

DEBUG 

Debug-level message. 

A log event is represented by a single line that shows the associated timestamp, server host name, severity level, process name (process ID), type of event, priority, and description.

For information regarding the ics.conf log settings, see Appendix E, Calendar Server Configuration Parameters.

Clearing the CLD Cache

If you have enabled the CLD Cache, you might need to clear the cache from time to time. This section covers the following topics:

Why Clear the CLD Cache?

The CLD cache can become out of sync with your system configuration for various reason, for example:

If any of these things happen, in order to refresh the CLD cache, you must clear it.

ProcedureTo Clear the CLD Cache

  1. Stop Calendar Server.

  2. Remove all files in the /var/opt/SUNWics5/csdb/cld_cache directory, but do not remove the cld_cache directory itself.

  3. Restart Calendar Server.

Changing a Server Name

If you add, delete or change a server name in your configuration, there are several “housekeeping” steps you should perform to avoid errors:

Configuring Anonymous Access

Anonymous access is a special login that does not require authentication. With anonymous login enabled, read and write access to public calendars is enabled by default. It is possible to deny write access to the public calendars. This section covers the following topics:

Note –

Communications Express expects anonymous logins to be allowed for writing as well as reading. See Configuring for Communications Express.

ProcedureTo Enable Anonymous Access

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

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

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

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

    Parameters  

    Description and Default Value  

    service.http.allowanonymouslogin

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

    service.calendarsearch.ldap

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

    Note –

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

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal_svr_base/SUNWics5/cal/sbin/start-cal

ProcedureTo Disable Anonymous Users to Write to Public Calendars

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

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

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

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

    Parameter  

    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.

  5. Save the file as ics.conf.

  6. Restart Calendar Server.

    cal_svr_base/SUNWics5/cal/sbin/start-cal

Enabling Proxy Administrator Logins

Proxy administrator logins (proxy authentication) must be enabled for Communications Express. For instructions on configuring proxy authentication for Communications Express, see Configuring for Communications Express.

However, proxy authentication can be enabled even if you are not using Communications Express. This section contains the procedure for enabling proxy authentication without Communications Express:

ProcedureTo Enable Proxy Authentication without Communications Express

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

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

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

  4. Edit the ics.conf file, setting the following parameter:

    service.http.allowadminproxy = "yes"

  5. Save the file as ics.conf.

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

ProcedureTo Verify Proxy Authentication is Working

  1. 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– The name of the server where Calendar Server is running.

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

      • admin-user – The Calendar Server administrator. For example, calmaster.

      • admin-password – The password for admin-user.

      • calendar-user – 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.

Refreshing the Calendar Server Configuration

In the current release, do not use the cstool refresh command to refresh a configuration. Instead, use the stop-cal and start-cal commands. For more information, see Starting and Stopping Calendar Server.