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.
Additional administration topics are covered in other, separate chapters. They include the following topics:
This section covers how to use start-cal and stop-cal and contains the following topics:
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.
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:
enpd— Event Notification Service (ENS)
csnotifyd— Notification Service
csadmind— Administration Service
csdwpd— Database Wire Protocol (DWP) service, the distributed database service starts only if you have a remote Calendar Server database configuration
cshttpd— HTTP Service
csstored— Automatic Backup Service
For a description of these services, seeCalendar Server Services
Log in as a user who has administrative rights to the system.
Change to the cal_svr_base/SUNWics5/cal/sbin directory.
Start Calendar Server:
./start-cal |
Log in as a user who has administrative rights to the system where Calendar Server is running.
Change to the cal_svr_base/SUNWics5/cal/sbin directory.
Stop Calendar Server:
./stop-cal |
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:
At a command line, change to the directory where the ics.conf is located:
cd /etc/opt/SUNWics5/config
Enable hot backups by setting the following ics.conf parameter to “yes”:
caldb.berkeleydb.hotbackup.enable="yes"
Specify the directory path for the hot backup directory:
caldb.berkeleydb.hotbackup.path= /var/opt/SUNWics5/hotbackup_directory
The default is the current directory.
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.
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/hotbackup_directory
The default is the current directory.
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.
Backups are disabled by default. If you have previously enabled them and want to disable them, perform the following steps:
At a command line, change to the directory where the ics.conf is located:
cd /etc/opt/SUNWics5/config
Disable hot backups by setting the following ics.conf parameter to "no":
caldb.berkeleydb.hotbackup.enable="no"
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.
Backups are disabled by default. If you have previously enabled them and want to disable them, perform the following steps:
At a command line, change to the directory where the ics.conf is located:
cd /etc/opt/SUNWics5/config
Disable archive backups by setting the following ics.conf parameter to "no":
caldb.berkeleydb.archive.enable="no"
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.
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:
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.
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.
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 |
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
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:
This Calendar Server utility is a shell script that requires bash. When invoked, this utility performs the following functions:
Monitors and logs the following processes according to the log level specified in the ics.conf file: csadmind, csnotifyd, cshttpd, enpd.
Checks to see if cshttpd is accepting commands.
Checks to see if the system has LDAP connectivity.
If circular logging is enabled, checks to see if more than one transaction file exists and if so, sends an email warning.
Checks available disk space for the calendar database to make sure there is enough for proper operation.
When errors occur the utility logs them and sends an email to the administrator specified by the ics.conf parameter service.monitor.emailaddress.to.
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.
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 ics.conf parameters shown in the following table:
Parameter |
Description and Default Value |
---|---|
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. |
|
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. |
|
Specifies the email address csmonitor sends messages from. No default given. |
|
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”. |
Specifies the csmonitor log file name. The default is “csmonitor.log”. |
|
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” |
|
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. |
Save the file as ics.conf.
Restart Calendar Server.
cal_svr_base/SUNWics5/cal/sbin/start-cal
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:
Maximum number of concurrent connections and total number of connections
Total number of successful and failed logins and connections
Number of database reads, writes, and deletes
For information about Calendar Server counter statistics, see Appendix E, Calendar Server Configuration Parameters.
You can ping the following services as well as the machine where Calendar Server is installed:
cshttpd
csadmind
enpd
For information about using cstool, see Appendix D, Calendar Server Command-Line Utilities Reference.
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.
If you have enabled the CLD Cache, you might need to clear the cache from time to time. This section covers the following topics:
The CLD cache can become out of sync with your system configuration for various reason, for example:
You add, delete or rename a server.
You move a server from one function to another in your configuration.
You move one or more calendars to different back-end servers.
If any of these things happen, in order to refresh the CLD cache, you must clear it.
Stop Calendar Server.
Remove all files in the /var/opt/SUNWics5/csdb/cld_cache directory, but do not remove the cld_cache directory itself.
Restart Calendar Server.
If you add, delete or change a server name in your configuration, there are several “housekeeping” steps you should perform to avoid errors:
Clear the CLD Cache
If an old server is taken out, delete it from the ics.conf parameters where it appears.
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:
Communications Express expects anonymous logins to be allowed for writing as well as reading. See Configuring for Communications Express.
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.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. (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
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 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. |
Save the file as ics.conf.
Restart Calendar Server.
cal_svr_base/SUNWics5/cal/sbin/start-cal
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:
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 file, setting the following parameter:
service.http.allowadminproxy = "yes"
Save the file as ics.conf.
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– 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.
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.