This chapter describes server administration for a Calendar Server deployment.
This chapter contains the following sections:
12.2 Enabling or Disabling Automatic Backups in Calendar Server Version 6.3
12.3 Managing the Group Scheduling Engine Queue for Calendar Server Version 6.3
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 separate chapters.
The chapters cover the following topics:
This section contains conceptual information and instructions on how to use the start-cal and stop-cal commands.
This section 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.
Check your scripts to make sure you do not use the old csstart and csstop utilities. 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:
watcher — Watcher, the process that monitors the system
enpd— Event Notification Service (ENS)
csstored— Automatic Backup Service
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
For a description of these services, see1.10 Services Running As Daemons in Calendar Server Version 6.3
Log in as a user who has administrative rights to the system.
Verify that all Calendar Server services are stopped by issuing the stop-cal command.
Change to the directory.
cal-svr-base/SUNWics5/cal/sbin
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 directory.
cal-svr-base/SUNWics5/cal/sbin
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.
For information on automatic backups and instructions on configuring csstored, see Chapter 9, Configuring Automatic Backups (csstored).
The following is a list of tasks for enabling and disabling automatic backups:
Log in as an administrator with configuration privileges.
Stop Calendar Server services by issuing the stop-cal command.
Change to the directory where the ics.conf file 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.
Log in as an administrator with configuration privileges.
Stop Calendar Server services by issuing the stop-cal command.
Change to the directory where the ics.conf file 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:
Log in as an administrator with configuration privileges.
Stop Calendar Server services by issuing the stop-cal command.
Change to the directory where the ics.conf file 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:
Log in as an administrator with configuration privileges.
Stop Calendar Server services by issuing the stop-cal command.
Change to the directory where the ics.conf file 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.
This section contains conceptual information and instructions for managing the Group Scheduling Engine (GSE)
The 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 csadmind process 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
Calendar Server and Messaging Server now use the same stop and start mechanism, as part of the Sun JavaTM Enterprise System Monitoring Framework (JESMF). The start-cal command starts the watcher process first, and then starts all other processes. The watcherprocess is aware of any dependencies the other services have, and in which sequence the services should be started.
Each registered service (process) opens a connection to the Watcher. If a process dies without properly disconnecting, the Watcher automatically restarts it. If the process dies twice in a defined interval, Watcher does not restart it. This timeout interval is configurable.
Watcher writes to a single log, cal-svr-base/data/log/watcher.log , which contains the following information:
Failure notices and non-response error messages that were sent to the administrative console.
Records of all server stops and starts.
For information on how to configure Watcher, seeTo Configure the Watcher Process for Calendar Server Version 6.3
This section covers conceptual information and instructions on how to clear the CLD cache.
This section covers the following topics:
If you have enabled the CLD Cache, you might need to clear the cache from time to time. The CLD cache can get out of sync (stale) with your system configuration for various reasons.
The following are a few reasons the CLD cache might become stale.
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.
The following steps are useful to keep your CLD uptodate:
Clear the CLD Cache
If an old server is taken out, delete it from the ics.conf parameters where it appears.
This sections contains instructions on how to enable and disable anonymous access (login).
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 4.1 Configuring for Communications Express.
Log in as an administrator with configuration privileges.
Stop Calendar Server services by issuing the stop-cal command.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit the 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 21.2 Improving Calendar Search Performance in a DWP Environment.
Save the file as ics.conf.
Restart Calendar Server.
cal-svr-base/SUNWics5/cal/sbin/start-cal
Log in as an administrator with configuration privileges.
Stop Calendar Server services by issuing the stop-cal command.
Change to the /etc/opt/SUNWics5/cal/config directory.
Save your old ics.conf file by copying and renaming it.
Edit the 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 4.1 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, confirming that the following parameter is set as shown:
service.http.allowadminproxy = "yes"
If not, change it to "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&fmt-out=text/html
This list defines the variables in the previous example:
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, the system displays the calendar for calendar-user. If problems occur, the system displays Unauthorized.
The following is a list of some reasons the command might fail:
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 Calendar Server 6.3 release, use the stop-cal and start-cal commands to refresh a configuration. For more information, see 12.1 Starting and Stopping Calendar Server 6.3 Processes.