第 12 章 Calendar Server の管理

この章と「Messaging Server を利用して作成したドメインの使用」以降の章では、Calendar Server の管理方法について説明します。ここで説明する内容は次のとおりです。

• 「Calendar Server の起動と停止」

• 「自動バックアップの有効化または無効化」

• 「グループスケジューリングエンジンキューの管理」

• 「Calendar Server の監視」

• 「CLD キャッシュのクリア」

• 「サーバー名の変更」

• 「匿名アクセスの設定」

• 「プロキシ管理者のログインの有効化」

• 「Calendar Server 設定の再読み込み」

Calendar Server を管理するには、Delegated Administrator ユーティリティー (従来のユーザー管理ユーティリティー) または Calendar Server のコマンド行ユーティリティーを実行するか、ics.conf 設定ファイルを編集します。

コマンド行ユーティリティーを実行するには、Calendar Server が稼動しているシステムの管理権限を持つユーザーとしてログインする必要があります。

詳細は、付録 D 「Calendar Server のコマンド行ユーティリティーのリファレンス」を参照してください。

管理に関するその他の内容については、別の章で説明します。説明する内容は次のとおりです。

• 第 13 章「ホストされたドメインの管理」

• 第 14 章「ユーザーとリソースの管理」

• 第 15 章「カレンダの管理」

• 第 16 章「csdb を使用した Calendar Server データベースの管理」

• 第 17 章「Calendar Server データのバックアップと復元」

• 第 18 章「削除ログデータベースの管理」

• 第 19 章「Calendar Server のタイムゾーンの管理」

• 第 20 章「Instant Messaging のポップアップアラームの使用」

• 第 21 章「Calendar Server のパフォーマンスの調整」

• 第 22 章「トラブルシューティング」

Calendar Server の起動と停止

ここでは、start-cal と stop-cal の使用方法について説明します。 ここで説明する内容は次のとおりです。

• 「start-cal と stop-cal について」

• 「start-cal を使用して Calendar Server を起動するには」

• 「stop-cal を使用して Calendar Server を停止するには」

start-cal と stop-cal について

Calendar Server の起動と停止には、start-cal コマンドと stop-cal コマンドを使用します。start-cal と stop-cal の各ユーティリティーは、cal_svr_base/SUNWics5/cal/sbin ディレクトリに格納されています。これらのユーティリティーを、Calendar Server がインストールされているローカルマシンで実行する必要があります。

Calendar Server に用意されている csstart と csstop の各ユーティリティーは、従来リリースとの互換性維持だけを目的としています。可能であれば、Calendar Server の起動と停止には、start-cal と stop-cal ユーティリティーを使用します。

start-cal ユーティリティーは次の順序で Calendar Server サービスを開始します。

1. enpd: 予定通知サービス (ENS)

2. csnotifyd: 通知サービス

3. csadmind: 管理サービス

4. csdwpd: DWP (データベースワイヤプロトコル) サービス。リモート Calendar Server データベース設定がある場合にのみ起動される分散データベースサービス

5. cshttpd: HTTP サービス

6. csstored: 自動バックアップサービス

これらのサービスについては、「Calendar Server サービス」を参照してください。

start-cal を使用して Calendar Server を起動するには

手順

1. システムの管理権限を持つユーザーとしてログインします。

2. cal_svr_base/SUNWics5/cal/sbin ディレクトリに移動します。

3. Calendar Server を起動します。

   ./start-cal

stop-cal を使用して Calendar Server を停止するには

手順

1. Calendar Server が稼動しているシステムの管理権限を持つユーザーとしてログインします。

2. cal_svr_base/SUNWics5/cal/sbin ディレクトリに移動します。

3. Calendar Server を停止します。

   ./stop-cal

自動バックアップの有効化または無効化

自動バックアップは、start-cal の実行時に自動的に起動される csstored プロセスによって管理されます。ただし、自動バックアップは任意に有効または無効にすることができます。デフォルトでは、自動バックアップは無効になっています。csstored プロセスは、自動バックアップが有効になっていない場合でも実行されます。

自動バックアップには 2 種類あります。ホットバックアップとアーカイブバックアップです。各バックアップは個別に有効または無効にすることができます。

csstored プロセスは、start-cal を実行する前に設定しておく必要があります。 そうしないと、csstored が設定されていないことを知らせるエラーメッセージが送信されます。そのあとも、設定が行われるまで 24 時間ごとに同じメッセージが送信されます。

自動バックアップと csstored の設定方法については、第 10 章「自動バックアップ (csstored) の設定」を参照してください。

次に示すのは、自動バックアップを有効化および無効化するための作業の一覧です。

• 「ホットバックアップを有効にするには」

• 「アーカイブバックアップを有効にするには」

• 「ホットバックアップを無効にするには」

• 「アーカイブバックアップを無効にするには」

ホットバックアップを有効にするには

手順

1. コマンド行で、ics.conf が格納されているディレクトリに移動します。

   cd /etc/opt/SUNWics5/config

2. 次の ics.conf パラメータを “yes” に設定して、ホットバックアップを有効にします。

   caldb.berkeleydb.hotbackup.enable="yes"

3. ホットバックアップディレクトリのディレクトリパスを指定します。

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

   デフォルトは現在のディレクトリです。

4. ics.conf ファイルの編集が終わったら、Calendar Server を再起動します。

   cal_svr_base/SUNWics5/cal/sbin/start-cal

   ics.conf ファイルを編集するときにカレンダサービスを停止する必要はありませんが、変更を適用するためにサービスを再起動する必要があります。

アーカイブバックアップを有効にするには

手順

1. コマンド行で、ics.conf が格納されているディレクトリに移動します。

   cd /etc/opt/SUNWics5/config

2. 次の ics.conf パラメータを “yes” に設定して、アーカイブバックアップを有効にします。

   caldb.berkeleydb.archive.enable=”yes”

3. アーカイブディレクトリのディレクトリパスを指定します。

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

   デフォルトは現在のディレクトリです。

4. ics.conf ファイルの編集が終わったら、Calendar Server を再起動します。

   cal_svr_base/SUNWics5/cal/sbin/start-cal

   ics.conf ファイルを編集するときにカレンダサービスを停止する必要はありませんが、変更を適用するためにサービスを再起動する必要があります。

ホットバックアップを無効にするには

バックアップはデフォルトで無効になっています。以前に有効にしたバックアップを無効にする場合は、次の手順を実行します。

手順

1. コマンド行で、ics.conf が格納されているディレクトリに移動します。

   cd /etc/opt/SUNWics5/config

2. 次の ics.conf パラメータを "no" に設定して、ホットバックアップを無効にします。

   caldb.berkeleydb.hotbackup.enable="no"

3. ics.conf ファイルの編集が終わったら、Calendar Server を再起動します。

   cal_svr_base/SUNWics5/cal/sbin/start-cal

   ics.conf ファイルを編集するときにカレンダサービスを停止する必要はありませんが、変更を適用するためにサービスを再起動する必要があります。

アーカイブバックアップを無効にするには

バックアップはデフォルトで無効になっています。以前に有効にしたバックアップを無効にする場合は、次の手順を実行します。

手順

1. コマンド行で、ics.conf が格納されているディレクトリに移動します。

   cd /etc/opt/SUNWics5/config

2. 次の ics.conf パラメータを "no" に設定して、アーカイブバックアップを無効にします。

   caldb.berkeleydb.archive.enable="no"

3. ics.conf ファイルの編集が終わったら、Calendar Server を再起動します。

   cal_svr_base/SUNWics5/cal/sbin/start-cal

   ics.conf ファイルを編集するときにカレンダサービスを停止する必要はありませんが、変更を適用するためにサービスを再起動する必要があります。

グループスケジューリングエンジンキューの管理

GSE (グループスケジューリングエンジン) は、コンポーネントデータベースを更新するために使用される予定のキューを保存します。管理者は Calendar Server がキューを走査する間隔を調整するためのタイムアウト値を変更できます。また、必要に応じて、キュー内の予定を一覧表示したり、特定の予定を削除したりできます。

ここで説明する内容は次のとおりです。

• 「GSE について」

• 「GSE キューについて」

• 「GSE キュー内のエントリのリスト表示」

• 「GSE キュー内のエントリの削除」

GSE について

GSE により、Calendar Server ユーザーは予定を作成したり、ほかのユーザーに出席を依頼したりできます。出席者が同じ Calendar Server に存在する場合は、予定は出席者のカレンダにスケジューリングされます。出席者が異なる Calendar Server に存在する場合は、電子メールで出席依頼が送信されます。出席者は出席依頼に応じるか拒否するかを決めることができ、GSE ではその返信内容によって予定が更新されます。

GSE キューについて

GSE キューは実質的には GSE によって管理される独立したデータベースです。Calendar Server は、コンポーネントデータベースに対して実行する必要がある更新のキューを走査します。

この走査の頻度を調節することで、Calendar Server を調整できます。これは、ics.conf ファイルの gse.belowthresholdtimeout タイムアウト値を変更することによって行われます。第 21 章「Calendar Server のパフォーマンスの調整」を参照してください。

GSE キューエントリは、csschedule を使用して管理 (一覧表示や削除) できます。csschedule は、Calendar Server がインストールされているローカルマシンで実行する必要があります。

GSE キュー内のエントリのリスト表示

GSE キュー内のエントリをリスト表示するには、csschedule ユーティリティーの list コマンドを使用します。

たとえば、GSE キュー内のすべてのエントリを表示するには、次のように実行します。

csschedule list

GSE キューに格納されている最初の 10 エントリをリスト表示するには、次のように実行します。

csschedule -c 10 list

calid が Holiday_Schedule のカレンダの GSE キューに含まれるすべてのエントリをリスト表示するには、次のように実行します。

csschedule -v list Holiday_Schedule

GSE キュー内のエントリの削除

GSE キュー内のエントリを削除するには、csschedule ユーティリティーの delete コマンドを使用します。

たとえば、GSE キュー内のすべてのエントリを削除するには、次のように実行します。

csschedule -v delete

calA というカレンダで、最初のスケジュール時刻が 2001 年 11 月 30 日の 13 時 30 分 45 秒、オフセット数が 1、一意の ID が 1111、定期予定 ID が 0、シーケンス番号が 0 のエントリを GSE キューから削除するには、次のように実行します。

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

Calendar Server の監視

システムの状態監視は、毎日の作業の一部として行うことをお勧めします。Calendar Server の状態監視には複数のユーティリティーツールを使用できます。csmonitor、csstats、cstool の各ユーティリティーを使用できます。また、システムの使用状況の監視に役立つ多数のログファイルを設定することもできます。

ここで説明する内容は次のとおりです。

• 「csmonitor について」

• 「csmonitor を設定するには」

• 「カウンタ統計情報のリスト表示」

• 「cstool による監視」

• 「Calendar Server ログファイルの使用」

csmonitor について

この Calendar Server ユーティリティーは、bash を必要とするシェルスクリプトです。このユーティリティーを呼び出すと、次の機能が実行されます。

• ics.conf ファイルで指定したログレベルに従って、次の各プロセスを監視および記録する。csadmind、csnotifyd、cshttpd、enpd。

• cshttpd がコマンドを受け入れているかどうかを確認する。

• システムに LDAP 接続が含まれているかどうかを確認する。

• 循環ログが有効になっている場合は、複数のトランザクションファイルが存在するかどうかを確認し、存在する場合は電子メールで警告を送信する。

• カレンダデータベースの空きディスク容量をチェックして、適切な操作を行うのに必要な容量があるかどうかを確認する。

• エラーが発生すると、このユーティリティーはエラーを記録し、ics.conf パラメータ service.monitor.emailaddress.to で指定された管理者に電子メールを送信する。

デバッグの目的で、モニターを非常に短い間隔の連続したループになるように設定できますが、システムリソースが余分に必要となるため、通常の運用ではそのモードにしておかないことをお勧めします。

通常の環境で csmonitor を使用するには、選択した間隔で実行されるように設定します。

csmonitor ユーティリティーについては、付録 D 「Calendar Server のコマンド行ユーティリティーのリファレンス」を参照してください。

csmonitor を設定するには

手順

1. 設定を変更する権限を持つ管理者としてログインします。

2. /etc/opt/SUNWics5/cal/config ディレクトリに移動します。

3. 古い ics.conf ファイルをコピーして名前を変更し、保存します。

4. 次の表に示す 1 つ以上の ics.conf パラメータを編集します。

   パラメータ	説明とデフォルト値
   service.monitor.continuous	csmonitor を連続してループするかどうかを指定します。"0": 連続的にループしません (デフォルト)。"1": 連続的にループします。 このパラメータを “1” に設定すると、csmonitor を自動的に実行できます。
   service.monitor.loopsdelay	2 つの監視ループの間の遅延時間を秒単位で指定します。デフォルトは “60” 秒です。  デバッグの目的ではこの間隔を短くし、本稼働ではこの間隔を長くします。
   service.monitor.emailaddress.from	csmonitor が送信するメッセージの送信元となる電子メールアドレスを指定します。デフォルトはなしです。
   service.monitor.emailaddress.to	csmonitor が送信するメッセージの送信先となる電子メールアドレスを指定します。デフォルトはなしです。
   service.monitor.csdb.logthreshold	カレンダデータベース (csdb) を監視します。最大ディスク消費量のしきい値を、ディスク容量全体のパーセント値で指定します。csdb ディレクトリのディスク消費量がこの値を超えると、電子メールで警告メッセージが送信されます。デフォルトは “90” です。
   logfile.monitor.logname	csmonitor のログファイル名を指定します。デフォルトは “csmonitor.log” です。
   logfile.monitor.maxlogfilesize	ログファイルの最大サイズを指定します。ログファイルがこのサイズを超えると、csmonitor はログを csmonitor.log.timestamp という名前で保存し、現在のログをリセットします。デフォルトは “2097152” です。
   service.monitor.dbglevel	デバッグレベルを指定します。設定できる値は 0 〜 5 です。 この値が大きいほど、csmonitor は詳細なメッセージを送信します。デフォルトは “0” で、ログは指定されません。このパラメータを “5” に設定すると、デバッグのログが指定されます。

5. ファイルを ics.conf として保存します。

6. Calendar Server を再起動します。

   cal_svr_base /SUNWics5/cal/sbin/start-cal

カウンタ統計情報のリスト表示

「csstats」 ユーティリティーは、カレンダ設定 (counter.conf) ファイルに定義されているカウンタオブジェクトからの統計情報を表示します。httpstat、authstat、wcapstat、dbstat などのカウンタオブジェクトは、Calendar Server に関する次のような情報を表示します。

• 並行接続の最大数と合計接続数

• ログインと接続の成功数と失敗数

• データベースの読み取り、書き込み、削除の回数

Calendar Server のカウンタ統計情報については、付録 E 「Calendar Server の設定パラメータ」を参照してください。

cstool による監視

Calendar Server がインストールされているマシンだけでなく、次のサービスに対しても ping を実行できます。

• cshttpd

• csadmind

• enpd

cstool の使用方法については、付録 D 「Calendar Server のコマンド行ユーティリティーのリファレンス」を参照してください。

Calendar Server ログファイルの使用

Calendar Server の各サービスは、状態に関する情報をそれぞれのログファイルに書き込みます。次の表に示すように、各ログファイルにはサービス名に関連する名前が付けられます。

Calendar Server ログファイルは、次のデフォルトディレクトリに格納されます。

/var/opt/SUNWics5/logs

各ログファイルは、一意の番号によって識別される新しいログファイルにロールオーバーされます。次に例を示します。

admin.log.8.1083013284 http.log.8.1083013284

次の表に示すように、Calendar Server のログファイルに記録する予定の重要度は、6 段階に分かれています。Calendar Server がログファイルに記録する予定の重要度は、ics.conf パラメータ logfile.loglevel の設定を変更して指定できます。

ログ予定はタイムスタンプ、サーバーホスト名、重要度、プロセス名 (プロセス ID)、予定の種類、優先度、説明から構成される 1 行で表されます。

ics.conf のログの設定については、付録 E 「Calendar Server の設定パラメータ」を参照してください。

CLD キャッシュのクリア

CLD キャッシュを有効にしている場合は、ときどきキャッシュをクリアする必要があります。ここで説明する内容は次のとおりです。

• 「CLD キャッシュをクリアする理由」

• 「CLD キャッシュをクリアするには」

CLD キャッシュをクリアする理由

CLD キャッシュは、さまざまな理由でシステム設定との同期が取れなくなることがあります。 たとえば、次のような場合がこれに該当します。

• サーバーの追加、削除、または名前の変更を行った場合

• サーバーを設定内のある機能から別の機能に移動した場合

• 1 つ以上のカレンダを別のバックエンドサーバーに移動した場合

上記のいずれかを行った場合は、CLD キャッシュを更新するために、それをクリアする必要があります。

CLD キャッシュをクリアするには

手順

1. Calendar Server を停止します。

2. /var/opt/SUNWics5/csdb/cld_cache ディレクトリ内のすべてのファイルを消去します。ただし、cld_cache ディレクトリ自体は消去しません。

3. Calendar Server を再起動します。

サーバー名の変更

設定内のサーバー名を追加、削除、または変更した場合は、エラーの発生を防ぐために「後処理」の手順をいくつか実行する必要があります。

• CLD キャッシュのクリア

• 古いサーバーを取り除く場合は、そのサーバーが指定されている ics.conf パラメータからそれを削除します。

匿名アクセスの設定

匿名アクセスとは、認証を必要としない特殊なログインのことです。匿名ログインが有効になっていると、公開カレンダへの読み書きアクセスがデフォルトで有効になります。公開カレンダへの書き込みアクセスを拒否することも可能です。ここで説明する内容は次のとおりです。

• 「匿名アクセスを有効にするには」

• 「匿名ユーザーによる公開カレンダへの書き込みを無効にするには」

Communication Express では、読み取りだけでなく、書き込みについても匿名ログインが許可されている必要があります。「Communications Express の設定」を参照してください。

匿名アクセスを有効にするには

手順

1. 設定を変更する権限を持つ管理者としてログインします。

2. /etc/opt/SUNWics5/cal/config ディレクトリに移動します。

3. 古い ics.conf ファイルをコピーして名前を変更し、保存します。

4. ics.conf に含まれる次のパラメータを編集して、匿名アクセスを有効にします。

   パラメータ	説明とデフォルト値
   service.http.allowanonymouslogin	必要に応じて、このパラメータを “yes” に設定し、匿名アクセス (ログイン) を有効にします。デフォルト値は “yes” です。
   service.calendarsearch.ldap	匿名ログインが有効になっているときには、セキュリティー上の理由から、カレンダ検索を行う際に最初に LDAP を検索できないようにしたい場合があります。 その場合には、このパラメータを “no” に設定します (デフォルト)。

   ---

   注 –

   Communications Express では、service.calendarsearch.ldap パラメータの値を “no” に設定する必要があります。この設定は、DWP 環境で最良のパフォーマンスを得るためのシステム調整の指示とは矛盾しています。DWP 環境とは、データベースが複数のバックエンドに分散されている環境のことです。「DWP 環境でのカレンダ検索のパフォーマンス向上」を参照してください。

   ---

5. ファイルを ics.conf として保存します。

6. Calendar Server を再起動します。

   cal_svr_base /SUNWics5/cal/sbin/start-cal

匿名ユーザーによる公開カレンダへの書き込みを無効にするには

手順

1. 設定を変更する権限を持つ管理者としてログインします。

2. /etc/opt/SUNWics5/cal/config ディレクトリに移動します。

3. 古い ics.conf ファイルをコピーして名前を変更し、保存します。

4. 次の表に示すように ics.conf のパラメータを編集します。

   パラメータ	説明とデフォルト値
   service.wcap.anonymous. allowpubliccalendarwrite	匿名アクセスのユーザーによる公開カレンダへの書き込みを有効または無効にします。アクセスを有効にするには、この値を “yes” に設定します (デフォルト)。

5. ファイルを ics.conf として保存します。

6. Calendar Server を再起動します。

   cal_svr_base /SUNWics5/cal/sbin/start-cal

プロキシ管理者のログインの有効化

Communications Express 用にプロキシ管理者のログイン (プロキシ認証) を有効にする必要があります。Communications Express 用にプロキシ認証を設定する方法については、「Communications Express の設定」を参照してください。

ただし、Communications Express を使用しない場合でもプロキシ認証を有効にすることができます。この節では、Communications Express を使用しない場合にプロキシ認証を有効にする手順について説明します。

• 「Communications Express を使用しない場合にプロキシ認証を有効にするには」

• 「プロキシ認証が機能していることを検証するには」

Communications Express を使用しない場合にプロキシ認証を有効にするには

手順

1. 設定を変更する権限を持つ管理者としてログインします。

2. /etc/opt/SUNWics5/cal/config ディレクトリに移動します。

3. 古い ics.conf ファイルをコピーして名前を変更し、保存します。

4. ics.conf ファイルを編集して次のパラメータを設定します。

   service.http.allowadminproxy = "yes"

5. ファイルを ics.conf として保存します。

6. 新しい値を適用するために Calendar Server を再起動します。

プロキシ認証が機能していることを検証するには

手順

次の WCAP コマンドを使用して、管理者プロキシログインが正しく機能することを確認します。

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

それぞれの意味は次のとおりです。

• server: Calendar Server が稼動しているサーバーの名前。

  • port: Calendar Server のポート番号。デフォルトのポートは 80。

  • admin-user: Calendar Server の管理者。例: calmaster

  • admin-password: admin-user のパスワード。

  • calendar-user: Calendar Server ユーザーの calid。

    コマンドの実行が成功すると、Calendar Server は calendar-user のカレンダを表示します。問題が発生した場合は、「Unauthorized」というメッセージが出力されます。次のような原因が考えられます。

  • admin-user が Calendar Server の管理者権限を持っていない。

  • admin-password が正しくない。

  • calendar-user が有効な Calendar Server ユーザーではない。

Calendar Server 設定の再読み込み

現在のリリースでは、設定の再読み込みに cstool refresh コマンドを使用しないでください。その代わりに、stop-cal コマンドと start-cal コマンドを使用します。詳細は、「Calendar Server の起動と停止」を参照してください。