Sun Java System Calendar Server 6.3 管理ガイド

パート IV Calendar Server 6.3 の管理

ここでは、Calendar Server の配備の管理について説明します。

次の章で構成されています。

第 12 章 Calendar Server 6.3 配備のサーバー管理

この章では、Calendar Server 配備のサーバー管理について説明します。

この章の内容は次のとおりです。

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

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

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

注 –

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

この章の内容は次のとおりです。

12.1 Calendar Server 6.3 プロセスの起動と停止

ここでは、start-cal コマンドと stop-cal コマンドの使用に関する概念情報と手順について説明します。

ここでは、次の内容について説明します。

12.1.1 Calendar Server 6.3 コマンドについて: start-cal と stop-cal

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

注 –

スクリプトを調べて、以前の csstart と csstop ユーティリティーを使用していないことを確認してください。Calendar Server の起動と停止には、start-cal と stop-cal ユーティリティーを使用します。

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

watcher: Watcher。システムを監視するプロセス
enpd: 予定通知サービス (ENS)
csstored: 自動バックアップサービス
csnotifyd: 通知サービス
csadmind: 管理サービス
csdwpd:DWP (データベースワイヤプロトコル) サービス。リモート Calendar Server データベース設定がある場合にのみ起動される分散データベースサービス
cshttpd: HTTP サービス

これらのサービスについては、「1.10 Calendar Server バージョン 6.3 でデーモンとして実行されるサービス」を参照してください。

start-cal を使用して Calendar Server 6.3 サービスを起動するには

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

stop-cal コマンドを実行して、すべての Calendar Server サービスが停止していることを確認します。

ディレクトリに移動します。

cal-svr-base/SUNWics5/cal/sbin

Calendar Server を起動します。

./start-cal

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

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

ディレクトリに移動します。

cal-svr-base/SUNWics5/cal/sbin

Calendar Server を停止します。

./stop-cal

12.2 Calendar Server バージョン 6.3 での自動バックアップの有効化または無効化

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

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

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

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

Calendar Server バージョン 6.3 でホットバックアップを有効にするには

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

stop-cal コマンドを発行して Calendar Server サービスを停止します。

ics.conf ファイルがあるディレクトリに移動します。

cd /etc/opt/SUNWics5/config

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

caldb.berkeleydb.hotbackup.enable="yes"

ホットバックアップディレクトリのディレクトリパスを指定します。
```
caldb.berkeleydb.hotbackup.path=
   /var/opt/SUNWics5/hotbackup_directory
```
デフォルトは現在のディレクトリです。

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

cal-svr-base/SUNWics5/cal/sbin/start-cal

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

Calendar Server バージョン 6.3 でアーカイブバックアップを有効にするには

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

stop-cal コマンドを発行して Calendar Server サービスを停止します。

ics.conf ファイルがあるディレクトリに移動します。

cd /etc/opt/SUNWics5/config

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

caldb.berkeleydb.archive.enable=”yes”

アーカイブディレクトリのディレクトリパスを指定します。
```
caldb.berkeleydb.archive.path=
   /var/opt/SUNWics5/hotbackup_directory
```
デフォルトは現在のディレクトリです。

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

cal-svr-base/SUNWics5/cal/sbin/start-cal

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

Calendar Server バージョン 6.3 でホットバックアップを無効にするには

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

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

stop-cal コマンドを発行して Calendar Server サービスを停止します。

ics.conf ファイルがあるディレクトリに移動します。

cd /etc/opt/SUNWics5/config

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

caldb.berkeleydb.hotbackup.enable="no"

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

cal-svr-base/SUNWics5/cal/sbin/start-cal

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

Calendar Server バージョン 6.3 でアーカイブバックアップを無効にするには

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

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

stop-cal コマンドを発行して Calendar Server サービスを停止します。

ics.conf ファイルがあるディレクトリに移動します。

cd /etc/opt/SUNWics5/config

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

caldb.berkeleydb.archive.enable="no"

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

cal-svr-base/SUNWics5/cal/sbin/start-cal

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

12.3 Calendar Server バージョン 6.3 のグループスケジューリングエンジンキューの管理

ここでは、GSE (グループスケジューリングエンジン) の管理に関する概念情報と手順について説明します。

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

ここでは、次の内容について説明します。

12.3.1 Calendar Server バージョン 6.3 の GSE について

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

12.3.2 Calendar Server 6.3 GSE キューについて

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

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

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

12.3.3 Calendar Server 6.3 GSE キュー内のエントリのリスト表示

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

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

csschedule list

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

csschedule -c 10 list

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

csschedule -v list Holiday_Schedule

12.3.4 Calendar Server バージョン 6.3 での 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

12.4 Calendar Server 6.3 プロセスの監視

Calendar Server とMessaging Server は、Sun Java^TM Enterprise System Monitoring Framework (JESMF) の一部として、同じ停止および起動メカニズムを使用するようになりました。start-cal コマンドは最初に watcher プロセスを起動し、続いて他のすべてのプロセスを起動します。watcher プロセスは、その他のサービスの依存関係、およびサービスをどの順序で起動するかを識別します。

登録された各サービス (プロセス) は、Watcher への接続を開きます。プロセスが適切な方法で接続解除されずに終了した場合、Watcher が自動的にそのプロセスを再起動します。定義した間隔内でプロセスが 2 回終了した場合、Watcher はそのプロセスを再起動しません。このタイムアウト間隔は、設定可能です。

Watcher は、cal-svr-base/data/log/watcher.log という単一のログを書き込みます。このログには次の情報が記録されます。

管理コンソールに送信された障害通知と無回答エラーメッセージ。
すべてのサーバーの停止と起動の記録。

Watcher の設定方法については、「Calendar Server バージョン 6.3 の Watcher プロセスを設定するには」を参照してください。

12.5 Calendar Server バージョン 6.3 での CLD キャッシュのクリア

ここでは、CLD キャッシュのクリアに関する概念情報と手順について説明します。

ここでは、次の内容について説明します。

12.5.1 Calendar Server 6.3 CLD キャッシュをクリアする理由

CLD キャッシュを有効にしている場合は、ときどきキャッシュをクリアする必要があります。CLD キャッシュは、さまざまな理由からシステム設定との同期がとれなくなる (失効する) ことがあります。

次のような場合に、CLD キャッシュは失効します。

サーバーの追加、削除、または名前の変更を行なった場合
サーバーを設定内のある機能から別の機能に移動した場合
1 つ以上のカレンダを別のバックエンドサーバーに移動した場合

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

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

Calendar Server を停止します。

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

Calendar Server を再起動します。

12.6 サーバー名の変更

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

次の手順は、CLD を最新の状態に保つ場合に役立ちます。

CLD キャッシュのクリア
古いサーバーを取り除く場合は、そのサーバーが指定されている ics.conf パラメータからそれを削除します。

12.7 Calendar Server ユーザーの匿名アクセスの設定

ここでは、匿名アクセス (ログイン) を有効および無効にする手順について説明します。

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

この節の内容は、次のとおりです。

注 –

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

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

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

stop-cal コマンドを発行して Calendar Server サービスを停止します。

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

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

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

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

注 –

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

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

Calendar Server を再起動します。

cal-svr-base/SUNWics5/cal/sbin/start-cal

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

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

stop-cal コマンドを発行して Calendar Server サービスを停止します。

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

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

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

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

パラメータ

説明とデフォルト値

service.wcap.anonymous.

allowpubliccalendarwrite

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

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

Calendar Server を再起動します。

cal-svr-base/SUNWics5/cal/sbin/start-cal

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

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

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

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

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

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

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

ics.conf ファイルを編集し、パラメータが次のように設定されていることを確認します。

service.http.allowadminproxy = "yes"

設定されていない場合は、"yes" に変更します。

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

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

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

次の WCAP コマンドを使用して、管理者プロキシログインが正しく機能することを確認します。
```
http://server[:port]/login.wcap?
user=admin-user&password=admin-password
&proxyauth=calendar-user&fmt-out=text/html
```
この例で使用されている変数の意味は次のとおりです。
- server: Calendar Server が稼動しているサーバーの名前。
- port: Calendar Server のポート番号。デフォルトのポートは 80。
- admin-user: Calendar Server の管理者。例: calmaster
- admin-password: admin-user のパスワード。
- calendar-user: Calendar Server ユーザーの calid 。
コマンドの実行が成功すると、システムは calendar-user のカレンダを表示します。問題が発生した場合は、「Unauthorized」というメッセージが表示されます。

コマンドが失敗した理由としては、次のような原因が考えられます。
- admin-user が Calendar Server の管理者権限を持っていない。
- admin-password が正しくない。
- calendar-user が有効な Calendar Server ユーザーではない。

12.9 Calendar Server 設定の再読み込み

Calendar Server 6.3 リリースでは、設定の再読み込みに stop-cal と start-cal のコマンドを使用します。詳細は、「12.1 Calendar Server 6.3 プロセスの起動と停止」を参照してください。

第 13 章 Calendar Server ドメインの管理

ここでは、Calendar Server 配備でのドメインを管理するうえでの概念情報を提供し、その手順について説明します。

ここでは、複数のドメインの管理に関する次の項目について説明します。

13.1 適切なユーザー管理ツールの選択

Calendar Server ドメインを管理するには 2 通りの方法があります。

次のいずれかのツールセットを使用します。

Schema バージョン 2 環境の場合は、Delegated Administrator コンソールまたはユーティリティー。

Delegated Administrator は、Java Enterprise System インストーラで個別にインストール可能なコンポーネントです。このユーティリティーについては、『Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide』を参照してください。コンソールについては、Delegated Administrator コンソールのオンラインヘルプを参照してください。
Calendar Server ユーティリティー。Schema バージョン 1 環境の場合は、csdomain および csattribute 。

Calendar Server にインストールされています。csdomain で属性を追加または削除できますが、modify コマンドはありません。既存の属性の値を変更するには、csattribute を使用します。また、csdomain で作成したドメインのオブジェクトクラスに追加や削除を行う必要がある場合には、ldapmodify を使用します。

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

特定のオブジェクトクラスおよび属性については、『Sun Java System Communications Services 6 2005Q4 Schema Reference』を参照してください。

複数ドメインの概要や、その他の入門的な内容については、第 10 章「Calendar Server 6.3 の複数ドメイン環境の設定」を参照してください。

注意 –

Calendar Server は、Access Manager コンソールを使用してのドメイン管理はサポートしていません。

13.2 新規の Calendar Server ドメインの作成

ここでは、Calendar Server 配備でのドメインを追加するうえでの概念情報を提供し、その手順について説明します。複数ドメインでは、いずれかのスキーマを使用できます。ただし、選択できる場合は、Schema バージョン 2 の卓越したツールセットを活用してください。

ここでは、次の内容について説明します。

13.2.1 Calendar Server ドメインの作成の概要

Calendar Server ソフトウェアには、デフォルトで複数ドメインが有効になっています。次の ics.conf パラメータの値を変更しないでください。 service.virtualdomain.support="yes"

第 10 章「Calendar Server 6.3 の複数ドメイン環境の設定」で解説されている準備作業が完了すると、新規ドメインを追加できます。

各ドメインには、設定可能な属性とユーザー設定があります。これらの属性は、icsCalendarDomain オブジェクトクラスに属しています。属性には、アクセス権、アクセス制御リスト (ACL)、ドメイン検索、ドメイン検索のアクセス権、ユーザーの状態、プロキシログインなどのユーザー設定が含まれます。

13.2.2 Schema バージョン 2 モードにドメインを追加するには

ここでは、Schema バージョン 2 モードにドメインを追加する方法について説明します。

Delegated Administrator コンソールまたはユーティリティーのいずれかを使用できます。

コンソール: 「組織」一覧ページの「新しい組織を作成」ウィザードを使用します。

詳細は、Delegated Administrator コンソールのオンラインヘルプを参照してください。
ユーティリティー: commadmin domain create コマンドを使用します。

たとえば、ドメイン sesta.com を作成するには、次のコマンドを実行します。
```
commadmin domain create -D calmaster
    -d sesta.com -w calmasterpassword -S cal 
    -B backend.sesta.com
```
Delegated Administrator ユーティリティーについては、『Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide』を参照してください。

13.2.3 Schema バージョン 1 モードにドメインを追加するには

ここでは、csdomain ユーティリティーを使用するための簡易的なサンプル例を示します。

Schema バージョン 1 でドメインを作成するには、csdomain create を使用します。たとえば、west.sesta.com を作成するには、次のコマンドを使用します。

csdomain create west.sesta.com

複数ドメインを設定する方法については、第 10 章「Calendar Server 6.3 の複数ドメイン環境の設定」を参照してください。

13.3 ドメイン間の検索の有効化

ドメイン間検索を有効にする方法について説明します。

ここでは、ドメイン間の検索を有効にするために必要な 2 つの作業について説明します。

このドメインの検索を許可する各ドメインの LDAP エントリに「13.3.1 このドメインの検索を許可するドメインの名前を追加する」。
このドメイン内のユーザーが予定への出席依頼を送信する場合の「13.3.2 このドメインによって検索されるドメインの名前を追加する」。

これを実行するには、次のいずれかのツールを使用できます。ldapmodify (Schema バージョン 1 および 2)、または Delegated Administrator コンソールまたはユーティリティー (Schema バージョン 2 の場合)

13.3.1 このドメインの検索を許可するドメインの名前を追加する

各ドメインの LDAP エントリは、icsExtendedDomainPrefs 属性の domainAccess パラメータで定義されている ACE のアクセス権を指定します。外部ドメインにこのドメインの検索を許可する方法には、次の 2 種類があります。

ACI の構造について詳しくは、「1.8 Calendar Server バージョン 6.3 のアクセス制御」を参照してください。

13.3.1.1 特定のドメインにこのドメインの検索を許可するには

これを実行する方法には次の 3 つがあります。

ldapmodify を使用して、icsExtendedDomainPrefs の domainAccess 設定に次の ACE 文字列を作成します。

@domain_being_allowed ^a^lsfr^g

このドメインの検索を許可するドメインを指定し、そのあとに検索を許可するための十分な権限を指定して ACE を構成します。

注意 –
domainAccess プロパティーのインスタンスは 1 つしか許可されていません。ldapmodify を使用して値を変更する場合は、このプロパティーの複製を誤って作成してしまわないように注意する必要があります。

システムが ics.conf ファイルを連続して読み取り、LDAP エントリに対して最後に見つかった属性の値を使用するのとは異なり、システムは最初に見つけたインスタンスを使用します。LDAP 検索メカニズムは、エントリの内容が特定の順序で使用されることは保証していないため、古いバージョンのプロパティーが最初に取得され、Calendar Server ソフトウェアはそれ以降は確認しないこともあります。
Delegated Administrator ユーティリティーのコマンド commadmin domain modify を使用して、icsExtendedDomainPrefs 属性の domainAccess 設定を指定する ACE 文字列を追加します。

たとえば、Schema バージョン 2 環境では、次のようにして sesta.com により siroe.com からの検索が許可されます。
```
commadmin domain modify -D admin
   -w adminpassword -X hostmachine_1 -d sesta.com 
   -A +icsextendeddomainprefs:"domainAccess=@@d^a^slfrwd^g;
      @siroe.com^a^lsfrwd^g;anonymous^a^r^g;@^a^s^g"
```
Delegated Administrator コンソールを使用すると、組織のプロパティーを作成または編集するときに、ドメインに「次の組織内のユーザーからの招待を許可する」リストを追加できます。

これにより、icsExtendedDomainPrefs 属性の domainAccess 設定が更新されます。

注 –

上に挙げた最初の 2 つの方法ではドメインに与える正確なアクセス権を指定できますが、最後の Delegated Administrator コンソールを使用する方法の場合は、管理者に同様の権限が許可されません。アクセス権の一覧が事前に設定されています。許可されているアクセス権は、空き/予定ありアクセスと、予定スケジュールアクセスです。カレンダの所有者がすべてのユーザーに対して読み取りアクセス権を設定しないかぎり、ユーザーは予定の詳細を参照できません。

13.3.1.2 すべての外部ドメインにこのドメインの検索を許可するには

すべての外部ドメインにこのドメインの検索を許可するには、次の 3 つの方法があります。

ldapmodify を使用して、icsExtendedDomainPrefs の domainAccess 設定に次の ACE 文字列を作成します。

@^a^slfr^g

すべてのドメインが検索を実行するのに十分なアクセス権を持つように指定して、ACE を構成します。
Delegated Administrator ユーティリティーのコマンド commadmin domain modify を使用して、icsExtendedDomainPrefs 属性の domainAccess 設定を指定する ACE 文字列を追加します。

たとえば、Schema バージョン 2 環境では、次のようにして sesta.com によりすべてのドメインからの検索が許可されます。
```
commadmin domain modify -D admin 
   -w adminpassword -X hostmachine_1 -d sesta.com 
   -A +icsextendeddomainprefs:"domainAccess=@@d^a^slfrwd^g;
      anonymous^a^r^g;@^a^slfr^g"
```
注 –
文字 @@d は、一次所有者のドメインを表します。
Delegated Administrator コンソールを使用すると、組織のプロパティーを作成または編集するときに、ドメインに「次の組織内のユーザーからの招待を許可する」リストを追加できます。

これにより、icsExtendedDomainPrefs 属性の domainAccess 設定が更新されます。

注 –

13.3.2 このドメインによって検索されるドメインの名前を追加する

ここでは、検索対象のドメイン名を追加する方法について説明します。

このドメインによって検索される外部ドメインを追加するには、次の 3 つの方法があります。

ldapmodify を使用して、このドメイン内のユーザーが検索することのできる外部ドメインごとに 1 つの icsDomainNames インスタンスを追加します。

たとえば、ドメイン間の検索を行う場合、sesta.com は siroe.com と example.com の両方を検索します。ldapmodify (Schema バージョン 1 または Schema バージョン 2 用) を使用して、次の LDIF を作成します。
```
dn: dc=sesta, dc=com, o=internet
changetype: modify
add: icsDomainNames
icsDomainNames:siroe.com
icsDomainNames:example.com
```
Delegated Administrator ユーティリティーのコマンド commadmin domain modify を使用して、検索対象ドメインの名前を追加するためのオプション -A を指定します。

次に例を示します。
```
commadmin domain modify -D admin 
   -w adminpassword -X hostmachine_1 -d sesta.com 
   -A +icsDomainNames:siroe.com 
   -A +icsDomainNames:example.com
```
Delegated Administrator コンソールを使用すると、組織のプロパティーを作成または編集するときに、ドメインに「カレンダを招待する組織」リストを追加できます。

これにより、ドメインの LDAP エントリに icsDomainNames 属性が追加されます。このドメイン内のユーザーが予定への出席依頼を送信する場合は、検索対象の外部ドメインごとに 1 つの属性を追加します。

詳細は、Delegated Administrator コンソールのオンラインヘルプを参照してください。

第 14 章ユーザー、グループ、およびリソースの管理

ここでは、Delegated Administrator および Calendar Server ユーティリティーを使用してユーザー、グループ、およびリソースを管理する方法について説明します。

この章の内容は次のとおりです。

14.1 カレンダユーザー LDAP エントリの作成

この節では、新規ユーザーエントリを作成する手順について説明します。

ここでは、次の内容について説明します。

14.1.1 Schema バージョン 2 モードで新規カレンダユーザーを作成するには

この節では、Schema バージョン 2 の LDAP エントリの新規カレンダユーザーを作成する方法について説明します。

Delegated Administrator コンソールまたはユーティリティーのいずれかを使用できます。

Delegated Administrator コンソール

Delegated Administrator コンソールで、「新規ユーザー」ウィザードを使用します。ユーザーを配置する組織の「ユーザー」一覧ページで「新規」をクリックします。詳細は、Delegated Administrator コンソールのオンラインヘルプを参照してください。
Delegated Administrator ユーティリティー

commadmin ユーティリティーの user create コマンドを使用します。たとえば、ユーザー jdoe を sesta.com ドメインに追加するには、次のように実行します。
```
commadmin user create -D calmaster -F John -n sesta.com 
   -k hosted -l jdoe -w calmasterpassword -W jdoepassword -L Doe -S cal
   -B red.sesta.com -E jdoe@sesta.com
```
commadmin ユーティリティーで使用可能なすべてのオプションの詳細については、『Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide 』を参照してください。

14.1.2 Schema バージョン 1 モードで新規カレンダユーザーを作成するには

csuser ユーティリティーを使用します。たとえば、ユーザー jdoe を sesta.com ドメインに追加するには、次のように実行します。

csuser -m jdoe@sesta.com -d sesta.com create jdoe

14.2 カレンダグループ LDAP エントリの作成

ここでは、新規グループ LDAP エントリを作成する方法について説明します。

この節の内容は、次のとおりです。

14.2.1 Schema バージョン 2 モードで新規カレンダグループを作成するには

グループとは、ユーザー、リソース、またはほかのグループ (入れ子のグループ) の名前付きリストです。グループはスタティックおよびダイナミックのいずれかにすることができます。

ヒント –

グループにはスタティックメンバーとダイナミックメンバーの両方を含むことはできません。空のグループが作成されると、デフォルトはスタティックグループになります。

次のいずれかのツールを使用できます。

Delegated Administrator コンソール — 「グループ」ページで「新規」をクリックします。「新規グループを作成」ウィザードが表示されます。「メールサービスの詳細」画面のあとに「カレンダサービスの詳細」画面が表示されます。「カレンダサービスの詳細」画面では、グループにサービスパッケージを割り当てることもできます。

コンソールについては、Delegated Administrator コンソールのオンラインヘルプを参照してください。
Delegated Administrator ユーティリティー — commadmin group create を使用します。

次に例を示します。
```
commadmin group create -D chris -n sesta.com -w bolton 
-G testgroup -d sesta.com -m lorca@sesta.com -S mail -M achiko@varrius.com
```
commadmin ユーティリティーで使用可能なすべてのオプションの詳細については、『Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide 』を参照してください。

14.2.2 Schema バージョン 1 モードで新規カレンダグループを作成するには

グループ LDAP エントリを直接追加します。『Sun ONE Directory Server Resource Kit 5.2 Tools Reference 』に記載されている、Directory Server LDAP コマンドを使用します。

グループ LDAP エントリには icsCalendarGroup オブジェクトクラスが含まれている必要があります。これは、GroupofUniqueNames オブジェクトクラスの拡張です。次の属性も含められます。

属性	説明
`groupid`	グループに対して必要となる唯一の属性です。これは、ユーザーの `uid` と同じような、グループの一意の識別子です。
`icsSecondaryowners`	グループの共同所有者。
`icsDefaultacl`	新規グループカレンダの ACL 文字列。
`icsCalendar`	このグループのデフォルトカレンダの `calid`。グループには、デフォルトカレンダがなくてもかまいません。
`icsStatus`	グループカレンダの状態。指定可能な値は、`active`、 `inactive`、`deleted` です。
`icsTimezone`	グループのタイムゾーン。
`icsDWPHost`	デフォルトカレンダが格納されているバックエンドホストの名前。
`icsDoublebooking`	デフォルトカレンダが、同じ期間に複数の予定のスケジューリングを許可しているか否かを示します。この設定により、`icsAllowRights` のビット 15、ドメインレベル設定が上書きされます。グループのドメインレベルのデフォルト設定については、「グループ用に Calendar Server を設定するには」を参照してください。
`icsAutoaccept`	デフォルトカレンダに対し、出席依頼が自動的に許可されるか否かを示します。
`mail`	このグループの電子メールアドレス
`owner`	所有者の、グループの LDAP エントリの識別名。単独の値しか設定できません。

注 –

主な所有者は、GroupOfUniqueNames オブジェクトクラスの owner 属性によって指定されます。

たとえば、グループ LDAP エントリには次のものが含まれます。

dn: groupid=mygroup, ou=group, o=sesta.com
objectclass:groupofuniquenames
objectclass:icsCalendarGroup
groupid:mygroup
owner:uid=jdoe, ou=people, o=sesta.com
icsSecondaryowners:uid=pfox, ou=people, o=sesta.com
icsStatus:active
uniqueMember: uid=wsmith, ou=people, o=sesta.com

オブジェクトクラスおよび属性については、『Sun Java System Communications Services 6 2005Q4 Schema Reference 』を参照してください。

14.3 カレンダリソース LDAP エントリの作成

ここでは、新規リソースを作成する方法について説明します。

次のいずれかの方法により、カレンダリソースのエントリを作成します。

14.3.1 Schema バージョン 2 モードで新規カレンダリソースを作成するには

ここでは、Schema バージョン 2 モードに新規リソース LDAP エントリを作成する手順について説明します。

Delegated Administrator コンソールまたはユーティリティーのいずれかを使用できます。

Delegated Administrator コンソール

Delegated Administrator コンソールで、「新規カレンダリソースを作成」ウィザードを使用します。リソースを配置する組織の「カレンダリソース」タブで「新規」をクリックします。詳細は、Delegated Administrator コンソールのオンラインヘルプを参照してください。
Delegated Administrator ユーティリティー

commadmin ユーティリティーの rescource create コマンドを使用して、LDAP エントリを作成します。たとえば、会議室 Conference_Room_100 を追加するには、次のコマンドを使用します。
```
commadmin resource create -D calmaster 
   -w calmasterpassword -n sesta.com -c room100 
   -N Conference_Room_100
```
次に、csresource を使用して、実際のリソースカレンダを作成する必要があります。リソースカレンダの作成方法については、「15.5 カレンダの作成」を参照してください。

commadmin ユーティリティーで使用可能なすべてのオプションの詳細については、『Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide 』を参照してください。

14.3.2 Schema バージョン 1 モードで新規カレンダリソースを作成するには

csresource ユーティリティーを使用して、LDAP エントリとリソースカレンダの両方を作成します。たとえば、プロジェクタ P101 を追加するには、次のコマンドを使用します。

csresource -m p101@siroe.com -c p101 create Projector_101

csresource については、「D.15 csresource」を参照してください。

14.4 ユーザー、グループ、およびリソース LDAP エントリへの mail 属性の追加

ここでは、メールサービスに対して LDAP エントリを有効にするうえでの概念情報を提供し、その手順について説明します。

この節の内容は、次のとおりです。

14.4.1 Calendar Server の LDAP エントリへのメールサービス追加に関する概要

Calendar Server では、ユーザー、グループ、およびリソースは mail 属性を有する必要があります。この属性には、ユーザー、グループ、またはリソースの電子メールアドレスが含まれます。この属性を指定することにより、電子メールアドレスまたは calid を使用してカレンダやリソースの検索を実行できます。Delegated Administrator を使用して新規ユーザーを作成すると、mail 属性が自動的に追加されます。この処理は、そのユーザーにメールサービスが割り当てられていない場合でも実行されます。ただし、mail 属性が必要ではなかったバージョンの Calendar Server でユーザーおよびリソースを作成している場合、既存のユーザーおよびリソース LDAP エントリへの mail 属性の追加が必要になる場合があります。

注 –

mail 属性を追加しても、ユーザーカレンダの電子メール通知は有効になりません。

Calendar Server では、グループまたはリソースカレンダの電子メール通知をサポートしていません。

ユーザーカレンダの電子メール通知を有効にするには、ユーザーの LDAP エントリに次の 2 つの属性を追加します。

icsExtendedUserPrefs:ceNotifyEnable=1
icsExtendedUserPrefs:ceNotifyEmail=jdoe@sesta.com

14.4.2 LDAP エントリに mail 属性が設定されているか否かを確認するには

ユーザー、グループ、およびリソースに mail 属性が設定されているかどうかが分からない場合は、Schema バージョン 2 環境では、Delegated Administrator を使用してメールサービスを確認します。

Schema バージョン 1 環境の場合は、csattribute list コマンドに -v (verbose) オプションを指定して使用します。

たとえば、会議室のリソース Room100 に mail 属性があるかどうかを確認するには、次のコマンドを実行します。

csattribute -v list Room100

出力により mail 属性が設定されているかどうかがわかります。

cn=Room 100,ou=conferenceRooms,dc=sesta,dc=com
 has mail: Room100@sesta.com

mail 属性が設定されている場合は、追加する必要はありません。属性が設定されていない場合は、次の節の手順に従って追加します。

14.4.3 Calendar Server バージョン 6.3 の既存のユーザー、グループ、およびリソース LDAP エントリに対して mail 属性を追加するには

既存の LDAP エントリをカレンダ対応エントリに変換する場合は、mail 属性が設定されていないそれぞれのユーザー、グループ、およびリソース LDAP エントリに対し、この属性を追加する必要があります。

既存のユーザー、グループ、およびリソースに mail 属性を追加するには、次のいずれかの方法を使用します。

Schema バージョン 2 環境の場合は、Delegated Administrator ユーティリティーを使用する。

commadmin user|resource|group modify -A オプションを使用します。

次に例を示します。commadmin group modify -A +mail:jdoe@sesta.com
Schema バージョン 1 環境の場合は、Calendar Server の「D.3 csattribute」ユーティリティーを使用する。

次の例では、Room100 という既存の会議室の LDAP mail 属性を sesta.com サーバーに追加します。
```
csattribute -a mail=Room100@sesta.com add Room100
```
ldapmodify を使用し、両方の Schema バージョンの LDAP エントリに属性を直接追加します。

14.5 既存のユーザーの管理

ここでは、LDAP データベースのユーザーエントリの管理に関する概念情報を提供し、その手順について説明します。ユーザーエントリの作成方法については、ここでは説明しません。ユーザーエントリの作成については、「14.1 カレンダユーザー LDAP エントリの作成」を参照してください。

Delegated Administrator ユーティリティーまたは Schema version 2 LDAP コンソールユーザーエントリのいずれか、または、Schema バージョン 1 LDAP ユーザーエントリの場合は csuser ユーティリティーを使用してユーザーを管理します。

この節で説明する管理作業は次のとおりです。

14.5.1 カレンダユーザー情報の表示

ここでは、Calendar Server ユーティリティーのコマンド、csuser list を使用してすべてのカレンダユーザーのリストを取得したり、特定のユーザーのカレンダ属性を LDAP ユーザーエントリから表示したりする、2 つのコマンド例を示します。

ここでは、次の内容について説明します。

14.5.1.1 カレンダ対応のすべてのユーザーを表示するには

カレンダ対応のすべてのユーザーを表示するには、次のコマンド行ユーティリティーを実行します。

csuser list

14.5.1.2 特定のユーザーのカレンダ属性を表示するには

1 人のユーザーのすべてのカレンダ属性を表示するには、次のコマンド行ユーティリティーを実行します。

csuser -v list fully-qualified-user-name

たとえば、sesta.com ドメインに属するユーザー jsmith の場合、コマンド行は次のようになります。

csuser -v list jsmith@sesta.com

14.5.2 カレンダユーザーの無効化

ユーザーを無効にするのは、そのユーザーが Calendar Server にログインしないように防ぐためです。この処理方法は、どのユーザー管理ツールを使用してユーザーを作成したかによって異なります。Delegated Administrator コンソールで作成したユーザーは、その管理にもこのツールを使用するようにしてください。同様に、Delegated Administrator ユーティリティーを使用してユーザーにカレンダサービスを割り当てた場合は、サービスを削除する場合もこのツールを使用します。各ツールにより、少し処理が異なります。

ここでは、次の内容について説明します。

14.5.2.1 Delegated Administrator コンソールを使用してユーザーを無効化するには

Delegated Administrator コンソールでは、ユーザーを一時的に無効とすることはできません。ユーザーからカレンダサービスを削除する必要があります。これを行うには、「ユーザー」一覧ページからユーザーを選択します。このユーザーのプロパティーで、カレンダサービスを含むサービスパッケージを削除します。これにより、このユーザーがカレンダに対して無効になり、ユーザーの icsStatus が inactive に設定されます。

注 –

パッケージにその他のサービスも含まれている場合は、カレンダが含まれていない別のパッケージを使用して、これらのサービスを再度割り当てる必要があります。

14.5.2.2 Delegated Administrator ユーティリティー (`commadmin user delete`) を使用してユーザーを無効化するには

ユーザーがカレンダサービスにアクセスできないようにするには、次の例に示すように、ユーザーの LDAP エントリからサービスを削除します。

commadmin user delete jsmith -S cal

これにより、LDAP エントリを完全に削除しなくても、カレンダサービスがユーザーから削除されます。さらに、このコマンドによって、ユーザーの icsStatus も inactive に変更されます。

14.5.2.3 Calendar Server ユーティリティー (`csuser disable`) でユーザーを無効化するには

disable コマンドにより、ユーザーはカレンダデータにアクセスできなくなりますが、カレンダサービスはユーザーの LDAP エントリや Calendar Server データベースから削除されません。このユーティリティーは、ユーザー LDAP エントリに対して icsAllowedServiceAccess="http" を追加することで、無効化されているユーザーに通知します。

たとえば、jsmith による Calendar Server へのアクセスを無効にするには、次のように実行します。

csuser disable jsmith

ただし、jsmith が現在 Calendar Server にログインしている場合は、ログオフするまで jsmith はカレンダデータへのアクセスを維持できます。

14.5.2.4 Calendar Server ユーティリティーでユーザーからカレンダサービスを削除するには

ユーザーからカレンダサービスを削除するには、csuser ユーティリティーの reset コマンドを実行します。

たとえば、jsmith からカレンダサービスを削除するには、次のように実行します。

csuser reset jsmith

これにより、icsCalendarUser (オブジェクトクラス)、icsSubscribed、icsCalendarOwned 、icsCalendar、icsDWPHost (LDAP CLD を使用している場合) をはじめとするすべてのカレンダ属性がユーザーの LDAP エントリから削除されます。Calendar Server 管理者がユーザーに代わってカレンダを作成することはできません。

注 –

次のいずれかの状況になった場合は、カレンダサービスはユーザーに復元されます。

ユーザーが Calendar Server に再度ログインした場合 (自動プロビジョニングがオンになっている状態)。
Calendar Server 管理者が csuser enable コマンドを実行した場合。この場合、icsDWPHost 属性はコマンドを実行しても復元されません。この属性は、別個で追加する必要があります。
Calendar Server 管理者が、ユーザー LDAP エントリに対してオブジェクトクラスと属性を明確に追加した場合。
Schema バージョン 2 に移行したばかりで、Delegated Administrator を使用してカレンダサービスを追加する場合。

14.5.3 カレンダユーザーの有効化

ここでは、ユーザーのカレンダサービスを有効にする方法について説明します。

ユーザーが作成されると、通常はカレンダサービスが有効になっています。ただし、ユーザーを無効にすることは可能です。ユーザーのカレンダサービスを再度有効にするには、この節で示すいずれかの方法を使用する必要があります。

注意 –

ユーザーの有効化は、Delegated Administrator コンソールとユーティリティーとでは、少しだけ処理方法が異なります。そのため、ユーザーの有効化と無効化に対しては同じツールを使用する必要があります。ユーザーを無効にしたツールとは違うツールを使用して再度有効にしてはなりません。

ここでは、ユーザーを有効にする方法について説明します。

14.5.3.1 Delegated Administrator コンソールを使用してユーザーを有効にするには

コンソールからユーザーを無効化することはできません。カレンダサービスを削除し、それを再度追加することはできます。サービスを再度追加するには、「ユーザー」一覧ページからユーザーを選択し、「サービスパッケージを割り当て」ウィザードを使用し、ユーザーの LDAP エントリに対してカレンダサービスパッケージを追加します。ユーザーは自動的に有効になります。

注 –

この手順は、カレンダサービスの追加と同じです (「14.5.4 ユーザーへのカレンダサービスの追加」)。

14.5.3.2 Delegated Administrator ユーティリティーを使用してユーザーを有効にするには

Delegated Administrator ユーティリティーは、次のいずれかの方法によってユーザーを有効にできます。

icsStatus を active に変更してユーザーを有効にする。

commadmin user modify -A icsStatus:active でユーザーを有効にします。
ユーザー LDAP エントリにカレンダサービスを追加する。

commadmin user modify -S cal

注意 –

ユーザーの有効化と無効化には、必ず同じ方法を使用してください。Delegated Administrator ユーティリティーを使用してユーザーを無効にしたあとに、Delegated Administrator コンソールでユーザーを有効にしようとすると (icsStatus のみを変更)、ユーザーはすでにサービスを有しているにもかかわらず無効なってしまうため、システムはサービスを追加できなくなります。

14.5.3.3 Calendar Server ユーティリティーでユーザーを再度有効にするには

ユーザーのカレンダサービスを再度有効にするには、csuser enable を使用して icsAllowedServiceAccess="http" をユーザーの LDAP レコードから削除します。

14.5.4 ユーザーへのカレンダサービスの追加

古い (Schema バージョン 1) Calendar Server ユーティリティーで作成されたユーザーに対し、カレンダサービスを追加する必要はありません。ただし、Schema バージョン 2 の Delegated Administrator では、ユーザーの LDAP エントリにカレンダサービスを追加したり、削除したりできます。

既存のユーザーにカレンダサービスを追加するには、次のいずれかのツールを使用します。

「14.5.4.1 Delegated Administrator コンソールを使用してユーザーにカレンダサービスを追加するには」 ( Schema バージョン 2 の場合)
「14.5.4.2 Delegated Administrator (commadmin user create) を使用してユーザーにカレンダサービスを追加するには」(Schema バージョン 2 の場合)
「14.5.4.3 Calendar Server ユーティリティーを使用してカレンダサービスを追加するには」 (Schema バージョン 1 の場合)

14.5.4.1 Delegated Administrator コンソールを使用してユーザーにカレンダサービスを追加するには

新規ユーザーにも既存ユーザーにもカレンダサービスを追加できます。

新規ユーザーを作成するときに、「新規ユーザー」ウィザードを使用して、カレンダサービスを含むサービスパッケージをユーザーに割り当てます。ユーザーは自動的に有効になります。
既存のユーザーの場合は、「ユーザー」一覧ページからユーザーを選択し、「サービスパッケージを割り当て」ウィザードを使用して、カレンダサービスを含むサービスパッケージを選択します。ユーザーは自動的に有効になります。

14.5.4.2 Delegated Administrator (`commadmin user create`) を使用してユーザーにカレンダサービスを追加するには

新規ユーザーを作成する場合は、次の例に示すように、カレンダサービスを追加します。

commadmin user create jsmith -S cal

ユーザーの作成時に、カレンダサービスを追加していない場合は、次の例に示すように、modify コマンドを使用して、あとでカレンダサービスをユーザーに追加できます。

commadmin user modify jsmith -S cal

14.5.4.3 Calendar Server ユーティリティーを使用してカレンダサービスを追加するには

csuser create を使用してユーザーエントリを作成した場合は、ユーティリティーは icsCalendarUser およびその属性をユーザー LDAP エントリに追加することで、ユーザーに対してカレンダサービスを追加します。

14.5.5 ユーザー LDAP エントリからのカレンダサービスの削除

ユーザーに対してカレンダサービスを拒否するには、ユーザーエントリからサービスを削除する方法があります。また、ユーザーを一時的に無効にするという方法もあります。これらについては、前述の「14.5.2 カレンダユーザーの無効化」で説明したとおりです。

14.5.6 カレンダユーザーの電子メールのエイリアスの設定

カレンダユーザーに対して電子メールのエイリアスを設定する必要がある場合は、ユーザーの LDAP エントリに対して mailalternateaddress 属性を追加します。mail 属性は主要メールアドレスを提供し、mailalternateaddress 属性は電子メールのエイリアスに使用されます。どちらの属性もメールアドレスをユーザーのカレンダ ID (calid) にマッピングします。

属性は、次の 3 つの方法で追加できます。

commadmin user modify -A を使用するか、ldapmodify で LDAP を直接更新します。

注 –

これらの変更を有効にするには、エイリアスのテーブルまたは設定の再構築が必要となる場合があります。Messaging Server (または使用するその他の電子メール製品) のマニュアル、およびメールサービスの変更に関するサイト固有のドキュメントおよび手順を参照してください。Messaging Server のマニュアルは、次の Web サイトで入手できます。http://docs.sun.com/coll/1705.1。

Delegated Administrator コンソールを使用して電子メールのエイリアスを設定するには

ユーザーが属している組織を選択します。

ユーザーを検索します。

ユーザー名をクリックし、ユーザーのプロパティーを表示します。

「メールサービスの詳細」を編集してエイリアスを追加します。

参照

Delegated Administrator のオンラインヘルプ。

14.5.6.1 Delegated Administrator ユーティリティーを使用して電子メールのエイリアスを設定するには

ユーザーの LDAP エントリに mailalternateaddress を追加することで、メッセージングユーザーに対するのと同様に、カレンダユーザーにも電子メールのエイリアスを設定できます。Delegated Administration ユーティリティーを使用して属性を追加するには、commadmin user modify -A mailalternateaddress:value を使用します。

14.5.6.2 Calendar Server ユーティリティーの csattribute を使用して電子メールのエイリアスを設定するには

ユーザーに電子メールのエイリアスを追加するには、csattribute add -a コマンドを使用してユーザーエントリに mailalternateaddress 属性を追加します。

たとえば、次の値を持つ John Smith というユーザーに 2 つのエイリアスを追加するには、次のように実行します。

mail 属性。johnsmith@sesta.com
電子メールのエイリアス: johns@sesta.com および jsmith@sesta.com

コマンドは次の例のようになります。

csattribute -a mailalternateaddress=johns@sesta.com add johnsmith@sesta.com

csattribute -a mailalternateaddress=jsmith@sesta.com add johnsmith@sesta.com

14.5.7 ユーザーがカレンダサービスを有していることの検証

この節は、カレンダサービスを検証するための手順について説明します。

次のツールを使用し、ユーザーがカレンダサービスを有していることを検証します。

14.5.7.1 Delegated Administrator コンソールを使用し、ユーザーがカレンダサービスを有しているかどうかを確認するには

「カレンダサービスの詳細」ページがある場合は、カレンダサービスがあります。または、サービスパッケージの詳細で、リスト表示されているサービスの種類を確認します。

14.5.7.2 Delegated Administrator ユーティリティーを使用し、ユーザーがカレンダサービスを有しているかどうかを確認するには

次のコマンドを使用し、ユーザーと関連付けられているディレクトリプロパティーをすべてリスト表示します。

commadmin user search

14.5.7.3 Calendar Server ユーティリティー `csuser` を使用し、ユーザーがカレンダサービスを有するかどうかを確認するには

次のコマンドを使用し、ユーザーに対してカレンダサービスが有効になっているかどうかを確認します。

csuser check

14.5.8 LDAP データベースからのユーザーの削除

LDAP からユーザーを削除するには、Delegated Administrator または Calendar Server ユーティリティーを使用します。

次の 2 つの方法のいずれかを使用し、LDAP データベースからユーザーを削除します。

注意 –

undelete コマンドはありません。

Delegated Administrator を使用してドメイン内のユーザーを削除したら、これらのユーザーは破棄して、最初から再度追加する必要があります。破棄されるまで、ユーザー名は再利用できません。

Delegated Administrator を使用した Schema バージョン 2 でのユーザーの削除

Delegated Administrator のどちらのインタフェースでも、ユーザーに削除のマークを付けることができます。ただし、Delegated Administrator コンソールを使用し、LDAP からユーザーを実際に削除 (消去) することはできません。破棄するためには Delegated Administrator ユーティリティーを使用する必要があります。次の作業一覧は、LDAP からユーザーを削除するための手順を示しています。ユーザーは、最後の手順を完了するまで LDAP から実際には削除されません。

ユーザーエントリに削除のマークを付けます。

Delegated Administrator コンソールの場合: 「ユーザー」一覧ページで、削除するユーザーを選択し、「削除」をクリックします。

Delegated Administrator ユーティリティーの場合: commadmin ユーザー削除コマンドを使用します。次に例を示します。
```
commadmin user delete -D chris -n siroe.com 
-w bolton -l jsmith
```
どちらの場合も、ユーザー LDAP エントリ内の icsStatus 属性が active から deleted に変更されます。

次の例に示すように、Calendar Server ユーティリティーの csclean を使用して、特定のドメインまたはすべてのドメインの削除したすべてのユーザーに属するすべてのカレンダを削除します。

csclean clean “*”

または、あるドメインの削除したすべてのユーザーに属するカレンダを削除するには、次の例に示すように実際のドメインを指定します。csclean clean sesta.com

ヒント –
ユーザーのカレンダを削除する前に LDAP からユーザーを誤って破棄した場合は、「15.6 ユーザーカレンダの管理」で説明されている cscal ユーティリティーを使用して、あとでカレンダを削除することができます。

Delegated Administrator ユーティリティーのコマンドcommadmin domain purge を使用して、削除のマークが付けられているすべてのユーザーのドメインを破棄します。

次に例を示します。

commadmin domain purge -D chris -d sesta.com -n siroe.com -w bolton

この例では、sesta.com の削除のマークが付けられているすべてのユーザーが永久に削除されます。

ヒント –
ときどき、このユーティリティーを手動で実行し、LDAP ディレクトリをクリーンアップします。このコマンドについては、『Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide 』を参照してください。

14.5.8.1 Schema バージョン 1 環境でのユーザーの削除

指定されたユーザーの LDAP エントリとそのユーザーのデフォルトカレンダを削除するには、Calendar Server ユーティリティーの csuser delete コマンドを使用します。

たとえば、ユーザー jsmith の LDAP エントリおよびデフォルトカレンダを削除するには、次のコマンドを使用します。

csuser delete jsmith

このユーザーに属するその他のカレンダを削除する場合は、「15.6 ユーザーカレンダの管理」の説明に従って cscal を使用する必要があります。

14.5.9 カレンダユーザーの名前変更

1 つ以上のユーザー ID を変更する必要がある場合は、csrename ユーティリティーを実行します。

このユーティリティーは、次の手順で実行します。

Calendar Server LDAP 属性のユーザー ID (ics という接頭辞が付いている) を変換します。LDAP ディレクトリが同じ場所で更新されます。
Calendar Server データベースファイルの予定や作業のユーザー名を変更します。これによって、新しいデータベースが出力先ディレクトリに書き込まれます。既存のデータベースファイルは変更されません。

注 –

1 つのユーザー ID だけを変更する場合でも、データベース全体が書き換えられることに注意してください。そのため、これは実行するには「負荷の高い」ユーティリティーです。

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

14.5.10 書き込み可能な公開カレンダ機能の無効化

書き込み可能な公開カレンダは、Calendar Server の機能の 1 つです。この機能を有効化または無効化できます。これはデフォルトでは有効になっています。次に、設定ファイルを編集してこの設定を変更するための手順を示します。

この機能を有効にすると、出席依頼が生成されたときにカレンダをスケジューリング (書き込み) することができます。予定は、出席者のカレンダに自動的に追加されます。

この機能が有効になっていると、カレンダ所有者は出席依頼が生成されたときにのみ電子メール通知を受け取ります。予定は、出席者のカレンダに自動的に追加されません。カレンダに予定と作業を追加できるのは所有者だけです。

ユーザーが書き込み可能な公開カレンダを所有するのを禁止するには

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

stop-cal コマンドを発行して Calendar Server サービスを停止します。

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

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

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

パラメータ	説明とデフォルト値
`service.wcap.` `allowpublicwritablecalendars`	ユーザーが書き込み可能な公開カレンダを所有できるようにします。これは、デフォルトで有効になっています (`“yes”` に設定されている)。

パラメータ

説明とデフォルト値

service.wcap.

allowpublicwritablecalendars

ユーザーが書き込み可能な公開カレンダを所有できるようにします。これは、デフォルトで有効になっています (“yes” に設定されている)。

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

Calendar Server を再起動します。

cal-svr-base/SUNWics5/cal/sbin/start-cal

14.6 Calendar Server リソースの管理

この節では、カレンダリソースの管理に関する概念情報を提供し、その手順について説明します。

リソースが追加されると、Delegated Administrator または csresource を使用してそのリソースを管理できます。

ここでは、次の内容について説明します。

14.6.1 リソースの LDAP 情報の取得

ここでは、リソースの LDAP 情報を取得する手順について説明します。

次のいずれかのツールを使用すると、LDAP リソースエントリからリソースプロパティーを取得できます。

Delegated Administrator コンソールを使用してリソース情報を取得するには

Delegated Administrator コンソールで、「カレンダリソース」タブをクリックします。

「検索結果」ドロップダウンボックスを使用し、次のいずれかのオプションを選択します。
- 「リソース ID でカレンダリソースを検索」
- 「カレンダリソース名でカレンダリソースを検索」

検索対象の値を入力します。

「検索」をクリックします。

14.6.1.1 Delegated Administrator ユーティリティーを使用してリソース情報を取得するには

commadmin resource search コマンドを使用し、リソースの LDAP 情報を取得します。

たとえば、sesta.com ドメインのリソース CF101 を検索するには、次のコマンドを使用します。

commadmin resource search -D serviceadmin -w serviceadmin -n sesta.com \s
-d sesta.com -u CF101

`csresource` を使用してリソース情報を取得するには

csresource ユーティリティーを使用して、1 つまたはすべてのリソースの LDAP エントリ情報を取得できます。

sbin ディレクトリに移動します。

1 つまたはすべてのリソースをリスト表示するには、csresource list コマンドを使用します。

たとえば、すべてのリソースについてすべての情報をリスト表示するには、次のように実行します。

./csresource -v list

特定のリソース CF101 に関するすべての情報をリスト表示するには、次のように実行します。

./csresource

リソースを有効にするには

sbin ディレクトリに移動します。

1 つまたはすべてのリソースを有効にするには、csresource enable コマンドを使用します。

たとえば、ConfRm12 というリソースを有効にするには、次のように実行します。

./csresource -v enable ConfRm12

リソースを無効にするには

sbin ディレクトリに移動します。

1 つ以上のリソースを無効にするには、csresource disable コマンドを使用します。たとえば、ConfRm12 というリソースを無効にするには、次のように実行します。

./csresource -v disable ConfRm12

リソースを削除するには

sbin ディレクトリに移動します。

1 つ以上のリソースを削除するには、csresource delete コマンドを使用します。たとえば、ConfRm12 というリソースを削除するには、次のように実行します。

./csresource -v delete ConfRm12

14.6.2 リソース電子メール用の Bitbucket チャネルを設定するには

ここでは、Messaging Server および Sendmail 用の bitbucket チャネルの設定方法について説明します。bitbucket チャネルは、リソースカレンダ用に生成された電子メールを破棄する方法の 1 つです。次の例では、sesta.com サーバー上の Room100 というリソースを使用しています。bitbucket チャネルまたは同等のチャネルを設定しない場合は、リソースカレンダに送信された電子メールメッセージを定期的に削除する必要があります。

ここでは、次の手順について説明します。

Messaging Server の Bitbucket チャネルを設定するには

imta.cnf ファイルに bitbucket チャネルが定義されていることを確認します。

メッセージの送信先を bitbucket チャネルに設定するには、csattribute ユーティリティーを使用してリソースの電子メールアドレスを作成します。
csattribute -a mail=Room100@bitbucket.sesta.com add Room100

Sendmail Bitbucket チャネルを設定するには

該当するホスト上の /etc/aliases ファイルに、次のようなエントリを追加します。

Resource/Conference room aliases Room100: /dev/null

csattribute ユーティリティーを使用して、リソースの電子メールアドレスを LDAP ディレクトリに追加します。

csattribute -a mail=Room100@sesta.com add Room100

14.7 ユーザーおよびリソース LDAP 属性の管理

Calendar Server が使用する LDAP 属性の管理には、「D.3 csattribute」ユーティリティー、または ldapmodify を使用します。csattribute を使用すると、属性をリスト表示、追加、または削除できます。属性を変更するには、ldapmodify を使用します。

ここでは、次の内容について説明します。

LDAP エントリの属性をリスト表示するには

インストール時に指定した Calendar Server の実行ユーザーまたはグループ icsuser、icsgroup など)、または root としてログインします。

sbin ディレクトリに移動します。

ユーザーまたはリソースの属性をリスト表示するには、csattribute list コマンドを使用します。たとえば、ドメイン tchang@sesta.com の属性をリスト表示するには、次のコマンドを実行します。

./csattribute -t user -d sesta.com list tchang

LDAP エントリの属性を追加するには

インストール時に指定した Calendar Server の実行ユーザーまたはグループ (icsuser、icsgroup など)、または root としてログインします。

この属性の変更をすぐに認識されるようにする場合は、Calendar Server を停止します。そうでない場合は、Calendar Server を停止する必要はありません。

sbin ディレクトリに移動します。

ユーザーまたはリソースに属性を追加するには、csattribute add コマンドを使用します。たとえば、Conference_Schedule という値を持つ LDAP 属性 icsCalendar を tchang というユーザーに追加するには、次のように実行します。

./csattribute -a icsCalendar=Conference_Schedule add tchang@sesta.com

LDAP エントリの属性を削除するには

インストール時に指定した Calendar Server の実行ユーザーまたはグループ (icsuser、icsgroup など)、または root としてログインします。

この属性の変更をすぐに認識されるようにする場合は、Calendar Server を停止します。そうでない場合は、Calendar Server を停止する必要はありません。

sbin ディレクトリに移動します。

ユーザーまたはリソースから属性を削除するには、csattribute delete コマンドを使用します。たとえば、Conference_Schedule という値を持つ LDAP 属性 icsCalendar を tchang というユーザーから削除するには、次のように実行します。

./csattribute -a icsCalendar=Conference_Schedule -t user -d sesta.com delete tchang

14.7.1 LDAP エントリの属性を変更するには

LDAP エントリの属性を変更するには、ldapmodify を使用します。たとえば、uid=tchang を持つユーザーの状態を変更するには、次に示すように ldapmodify を使用します。

dn:uid=tchang,ou=people,o=sesta.com
 changetype: modify
 add: objectclass
 objectClass: icsCalendarUser
 add: icsStatus
 icsStatus: active

注 –

サイトで LDAP CLD プラグインを使用している場合、csattribute を使用して icsDWPHost の値を変更することによって 1 台のバックエンドホストから別のバックエンドホストへユーザーのカレンダを移動することは避けてください。icsDWPHost を変更しても、カレンダは新しいバックエンドホストに移動されません。バックエンドサーバー間でカレンダを移動する方法については、「15.6 ユーザーカレンダの管理」を参照してください。

第 15 章カレンダの管理

この章では、カレンダの作成や管理を行うための Calendar Server コマンド行ユーティリティーの使用方法を説明します。

この章の内容は次のとおりです。

15.1 Calendar Server バージョン 6.3 でのカレンダ管理の概要

Delegated Administrator では、カレンダの作成または管理は行えません。付録 D 「Calendar Server のコマンド行ユーティリティーのリファレンス」で説明している Calendar Server ユーティリティーを使用してください。

カレンダを作成する前に、次の情報を確認しておく必要があります。

カレンダには、ユーザーカレンダ、リソースカレンダ、グループカレンダの 3 つのタイプがあります。

ユーザーカレンダは、作業や活動のスケジュールリングを目的としています。リソースカレンダは、会議室やビデオ機器などの施設設備を使用するためのスケジューリングを目的としています。グループカレンダは、ユーザーのグループの活動のスケジューリングを目的としています。
どのタイプのカレンダも、一意のカレンダ識別子 (calid) によって識別されます。
cscal を使用してユーザーカレンダを作成します。または、ログイン時に自動プロビジョニングを有効にします。「15.3 カレンダの自動作成」を参照してください。
csresource を使用してリソースカレンダを作成します。リソースカレンダの自動プロビジョニング機能はありません。
グループカレンダを作成します。

cscal または csresource を実行するには、Calendar Server が稼動しているシステムの管理権限を持つユーザーとしてログインする必要があります。これらのコマンドは、必ず /opt/SUNWics5/cal/sbin ディレクトリから実行してください。つまり、sbin ディレクトリに移動する必要があります。パスを指定して別のディレクトリから実行することはできません。

15.2 カレンダ固有の識別子 (calid) の作成

Calendar Server データベース内の各カレンダは、一意のカレンダ識別子 (ID) または calid によって識別されます。カレンダを作成するとき、calid を指定する必要があります。

ここでは、次の内容について説明します。

15.2.1 Calid 構文

データベース内の各カレンダは、一意のカレンダ ID (calid) によって識別されます。次の calid 構文には、指定する項目が 3 つあります。

userid[@domain][:calendar-name]

指定する 3 つの項目は次のとおりです。

userid

Calendar Server インスタンスのドメインで一意のユーザー ID。

domain

ユーザーのドメイン名。

ドメインが 1 つしかない場合、ユーザーが属しているドメインには曖昧さがないため、ドメインの部分は省略可能です。

複数のドメインがあり、ドメインの部分が指定されていない場合、Calendar Server では ics.conf の service.defaultdomain で指定された値をドメインに使用します。ユーザーがデフォルトのドメインに属していない場合は、ドメイン部分を指定する必要があります。

複数のドメイン環境の詳細については、第 10 章「Calendar Server 6.3 の複数ドメイン環境の設定」と第 13 章「Calendar Server ドメインの管理」を参照してください。

calendar-name

特定のユーザーにとって一意となるカレンダの名前で、省略可能です。所有者のデフォルトカレンダは 1 つだけですが、さまざまな目的のほかのカレンダを所有することが可能です。このようなデフォルト以外の各カレンダは、カレンダ名によって識別されます。たとえば、ユーザー John Doe の uid が jdoe である場合、そのデフォルトカレンダは jdoe@sesta.com になります。たとえば、リトルリーグチームのコーチが試合の記録を取るために使用する補助カレンダは、次の calid として識別されることもあります。jdoe@sesta.com:baseball

15.2.2 カレンダ ID の作成規則

ここでは、カレンダ ID (calid ) の作成規則について説明します。

calid を作成する場合、次の規則を念頭に置いてください。

カレンダ ID の大文字と小文字は区別されます。たとえば、JSMITH と jsmith は別の ID として認識されます。(この方法は、メールアドレスの場合とは異なります。メールアドレスは大文字と小文字が区別されません。たとえば、jsmith@sesta.com と JSMITH@SESTA.COM では、同じアドレスを指します。）
カレンダ ID に空白文字を含めることはできません。使用できる文字は次の文字に限定されています。
- アルファベット (a-z、A-Z) と数字 (0-9) (つまり、ASCII 以外の文字は使用できない)
- 特殊文字: ピリオド (.)、下線 (_)、ハイフンまたはダッシュ (-)、アットマーク (@)、アポストロフィー (')、パーセント記号 (%)、スラッシュ (/)、感嘆符 (!) の特殊文字
  
  ユーザー ID は calid の一部であるため、ユーザー ID に空白文字を含める (たとえば j smith) ことはできません。空白文字が含まれるユーザー ID を持つユーザーは Calendar Server にログインすることはできますが、空白文字によってログイン後に問題が生じる可能性があります。
  
  次に適切なカレンダ ID の例を示します。
```
jsmithjsmith:private_calendar
jsmith@calendar.sesta.com:new-cal
```

15.2.3 ドメインではない Calid から複数のドメイン形式の Calid への変換

ドメインを持つ前に作成された calid があり、それらをドメイン固有の calid に変換する場合、既存の calid にドメイン部分を追加するために使用できる csvdmig というユーティリティーがあります。このユーティリティーの使用方法については、「3.6 csvdmig」を参照してください。

ドメイン名を既存の calid に追加しない場合、システムはそれらがデフォルトドメインに属していると仮定します。

15.3 カレンダの自動作成

ここでは、Calendar Server 機能を使用してユーザーの最初のログイン時にカレンダを自動的に作成する方法と概念情報について説明します。

カレンダ自動作成は、デフォルトで有効になっています。有効な場合、次の 2 つの状況下でシステムは自動的にカレンダを作成します。

ユーザーの最初のログイン時にユーザーの LDAP エントリがカレンダサービスを追加するよう更新されれば、デフォルトカレンダが作成されます。ユーザーのエントリは、LDAP ディレクトリ内にすでに存在している必要があります。存在しない場合、エラーが返されます。
適切に設定されている場合、ユーザー、グループ、またはリソースが予定への出席を最初に依頼された時に既存のデフォルトカレンダがなければ、デフォルトカレンダが作成されます。

この状況でカレンダの自動作成を実装するために必要な設定情報については、「グループ用に Calendar Server を設定するには」を参照してください。

ここでは、次の内容について説明します。

15.3.1 calids の作成

Calendar Server は、新しいデフォルトカレンダに対して、ユーザー ID とドメイン名からカレンダ ID (calid) を作成します。

たとえば、John Smith のユーザー ID は jsmith で、彼の LDAP エントリは sesta.com ドメインにあります。彼が Calendar Server に初めてログインすると、システムは calid として jsmith@sesta.com が設定されたデフォルトカレンダを自動的に作成します。それ以降に John Smith が作成する各カレンダの calid は、カレンダ名の先頭に jsmith@sesta.com: が追加されます。たとえば、John Smith があとで meetings という名前の新しいカレンダを作成する場合、新しいカレンダの calid は jsmith@sesta.com:meetings です。

デフォルトカレンダを持たないユーザー、グループ、またはリソースが予定の出席者リストに表示されている場合、システムは予定の所有者として予定の所有者のドメイン内の LDAP の uid を検索します。所有者にドメインが割り当てられていない場合、デフォルトドメインを検索します。システムは、ドメインを uid に追加して calid を構築します。

システムが予定の所有者のドメインで uid を見つけられない場合は、予定の所有者が検索できるその他のドメインを検索します。詳細は、「11.2 Calendar Server 6.3 システムでのドメイン間の検索」を参照してください。

カレンダの自動プロビジョニングを有効にするには

カレンダの自動プロビジョニングはデフォルトで有効にされています。しかし、自動プロビジョニングを無効にした後に再び有効にする必要がある場合は、次の手順を実行します。

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

stop-cal コマンドを発行して Calendar Server サービスを停止します。

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

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

次の表に示す、Calendar Server 設定ファイル ics.conf に含まれる 1 つ以上のパラメータを編集します。

パラメータ	説明とデフォルト値
`local.autoprovision`	“yes” に設定すると、ユーザーが最初にログインしたときにデフォルトのカレンダが自動的に作成されます。自動プロビジョニングはデフォルトで有効にされています。この機能を無効にするには、値を “no” に設定します。

パラメータ

説明とデフォルト値

local.autoprovision

“yes” に設定すると、ユーザーが最初にログインしたときにデフォルトのカレンダが自動的に作成されます。自動プロビジョニングはデフォルトで有効にされています。

この機能を無効にするには、値を “no” に設定します。

ユーザーの LDAP エントリがカレンダに対して有効になっていることを検証します。

このエントリには、icsCalendarUser オブジェクトクラスが含まれている必要があります。ユーザーの LDAP エントリにクラスがない場合は、追加します。

サイトで複数のドメインを使用している場合、カレンダの自動プロビジョニングを有効にする前に、ユーザーのドメインでカレンダが有効にされている必要があります。ドメインエントリに icsCalendarDomain オブジェクトクラスが含まれている必要があります。

ファイルを保存します。

Calendar Server を再起動します。

cal-svr-base/SUNWics5/cal/sbin/start-cal

カレンダの自動プロビジョニングを無効にするには

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

stop-cal コマンドを発行して Calendar Server サービスを停止します。

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

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

次の表に示す、Calendar Server 設定ファイル ics.conf に含まれる 1 つ以上のパラメータを編集します。

パラメータ	説明とデフォルト値
`local.autoprovision`	パラメータを `no` に設定すると、ユーザーカレンダの自動プロビジョニングが無効になります。

ファイルを保存します。

Calendar Server を再起動します。

cal-svr-base/SUNWics5/cal/sbin/start-cal

注 –
自動プロビジョニングが無効の場合、正常にログインするためには、そのユーザーに対して明示的にカレンダが作成されている必要があります。

15.4 カレンダのアクセス制御

Calendar Server は、アクセス制御リスト (ACL) を使用して、カレンダ、カレンダプロパティー、予定や仕事 (作業) などのカレンダコンポーネントへのアクセスを制御します。

ここでは、次の内容について説明します。

15.4.1 アクセス制御の構成パラメータ

次の表は、Calendar Server がアクセス制御に使用する、ics.conf ファイル内の構成パラメータを示しています。

表 15–1 アクセス制御の構成パラメータ


パラメータ	説明
`calstore.calendar.default.acl`	ユーザーがカレンダを作成したときに使用されるデフォルトのアクセス制御設定を指定します。デフォルトは次のとおりです。 `"@@o^a^r^g;@@o^c^wdeic^g;` `@^a^fs^g;@^c^^g;@^p^r^g"`
`calstore.calendar.owner.acl`	カレンダ所有者のデフォルトのアクセス制御設定を指定します。デフォルトは次のとおりです。 `"@@o^a^rsf^g;@@o^c^wdeic^g"`
`resource.default.acl`	リソースカレンダを作成したときに使用されるデフォルトのアクセス制御設定を指定します。デフォルトは次のとおりです。 `"@@o^a^r^g;@@o^c^wdeic^g;` `@^a^rsf^g"`

15.4.2 公開、非公開の予定と仕事、およびフィルタ

新しい予定または仕事を作成するときに、ユーザーは予定または仕事に公開、非公開、または時刻と日付のみの公開 (極秘) を指定できます。

公開: ユーザーのカレンダに対する読み取りアクセス権を持つ誰もが予定または仕事を表示できます。
非公開 (Private): カレンダの所有者だけが予定または仕事を表示できます。
時刻と日付のみの公開: これらは極秘の予定および仕事です。カレンダの所有者は予定または仕事を表示できます。カレンダに対する読み取りアクセス権を持つユーザーがカレンダにアクセスすると、「タイトルなしの予定」とカレンダに表示されます。

Calendar Server フィルタが非公開の、および時刻と日付のみが公開される極秘の予定と仕事を認識できるかどうかは、calstore.filterprivateevents によって決定されます。このパラメータはデフォルトで "yes" に設定されます。calstore.filterprivateevents を "no" に設定すると、Calendar Server は非公開の、および時刻と日付のみが公開される予定と仕事を、公開されているものと同様に扱います。

15.4.3 アクセス制御のためのコマンド行ユーティリティー

次の表は、アクセス制御用の ACL を設定または変更するための Calendar Server コマンド行ユーティリティーを示しています。

表 15–2 アクセス制御のためのコマンド行ユーティリティー


ユーティリティー	説明
`cscal`	特定のユーザーまたはリソースのカレンダの ACL を設定するときは、`-a` オプションを指定して `create` コマンドまたは `modify` コマンドを実行します。
`csresource`	リソースカレンダに ACL を設定するには、`csresource` ユーティリティーに `-a` オプションを指定して実行します。
`commadmin ユーザー` `csuser`	Schema バージョン 2 の Delegated Administrator コンソールまたは Delegated Administrator ユーティリティー、`commadmin` を使用して、ユーザーカレンダを作成するときに使用するデフォルト ACL を変更します。ユーザーがカレンダを作成するときに使用するデフォルト ACL を変更するには、Schema バージョン 1 の　`csuser` ユーティリティーに `-a` オプションを指定して実行します。

注 –

Delegated Administrator コンソールでアクセス権限を設定する場合は、「組織のプロパティー」ページ (または「新しい組織を作成」ウィザード) で「拡張権限を設定」ボタンをクリックすると、コンソールから管理できるアクセス権限のリストが表示されます。

15.5 カレンダの作成

ここでは、カレンダの作成方法についての概念情報と手順について説明します。

次の各項目について説明します。

15.5.1 `cscal` ユーティリティーを使用したユーザーカレンダの作成

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

次の例は、前の例と似たカレンダを作成しますが、グループスケジュール機能のアクセス制御設定が適用されます。

cscal -n Hobbies -o jsmith -a "@@o^a^sfr^g" create Personal

文字列 -a "@@o^a^sfr^g" は、このカレンダのコンポーネントとカレンダの両方のプロパティーに対するグループスケジュール機能のスケジュール権限、空き/ 予定ありの設定権限、読み取りアクセス権限を、ほかの所有者に与えます。

15.5.1.1 新規カレンダ作成の概要

新しいカレンダを作成するには、cscal ユーティリティーの create コマンドを使用します。ユーザーまたはリソースのエントリは、LDAP ディレクトリ内にすでに存在している必要があります。LDAP ディレクトリへのユーザーやリソースの追加については、第 14 章「ユーザー、グループ、およびリソースの管理」を参照してください。

サイトで LDAP カレンダ検索データベース (CLD) プラグインを使用している場合、ユーザーまたはリソースのエントリの icsDWPHost LDAP 属性で指定されているのと同じバックエンドサーバー上で特定のユーザーまたはリソースのすべてのカレンダを作成する必要があります。別のバックエンドサーバーにカレンダを作成しようとすると、cscal ユーティリティーはエラーを返します。LDAP CLD プラグインについては、第 5 章「Calendar Server バージョン 6.3 での複数のマシンへのカレンダデータベースの分散の設定」を参照してください。

15.5.1.2 新しいカレンダの作成

新しいカレンダを作成するために最低限必要なコマンドは次のとおりです。

cscal -o uid  create calid

たとえば、jsmith というカレンダ ID と一意の ID を持つ John Smith というユーザーに対して、コマンドは次のようになります。

cscal -o jsmith create jsmith

コマンドの構成要素は、次のようになります。

cscal: ユーティリティーの名前。
-o: このカレンダの一次所有者の一意の ID (uid)
create: 新しいカレンダを作成するためのコマンド。
calid: このカレンダに割り当てられるカレンダ ID。

cscal ユーティリティーの詳細については、本書にある「D.5 cscal」を参照してください

ヒント –

デフォルトのアクセス制御設定は、ics.conf ファイルの calstore.calendar.default.acl によって定義されます。

15.5.1.3 ユーザーの別のカレンダの作成

どのユーザーに対しても複数のカレンダを作成できます。ただし、それらは常にデフォルトカレンダのサブカレンダとして認識されます。新しいカレンダの完全修飾名では、コロンの区切り記号の左側がデフォルトカレンダ名、コロンの区切り記号の右側が新しいカレンダ名になります。

次の例は、ユーザー John Smith に対して Personal という新しいカレンダ名を持つ別のカレンダ (デフォルト以外) の作成方法を示しています。

cscal -o jsmith@sesta.com create Personal

コマンドの構成要素は次のとおりです。

cscal

ユーティリティーの名前。

-o jsmith@sesta.com

このカレンダの一次所有者の一意の ID (uid)

create

新しいカレンダを作成するためのコマンド。

Personal

このカレンダに割り当てるカレンダ ID (calid) の2 番目の部分。

完全修飾カレンダ ID は jsmith@sesta.com:Personal になります。

15.5.1.4 表示名のあるカレンダの作成

この例は、前の例で作成した Personal というデフォルト以外のカレンダに「Hobbies」という別の表示名を付ける方法を説明します。

cscal -o jsmith@sesta.com -n Hobbies create Personal

-o

jsmith@sesta.com は、一次所有者のユーザー ID を指定します。

-n

Hobbies は、カレンダの表示名を指定します。

Personal

John Smith のこの新しい追加カレンダの名前。

calid 全体は次のようになります。jsmith@sesta.com: Personal。

15.5.1.5 他のプロパティーを持つカレンダの作成

次の例は、前の例に似た Personal というカレンダを新規作成しますが、カレンダを sports というカテゴリに関連付け、複数のユーザーからの予約を有効にして Ron Jones というもう一人の所有者を指定します。

cscal -n Hobbies -o jsmith - g sports -k yes -y rjones create Personal

コマンドの構成要素は、次のようになります。

cscal

ユーティリティーの名前。

-o jamsith@sesta.com

このカレンダの一次所有者の一意の ID (uid)

-g sports

このオプションはカレンダ Personal を sports という名前のカテゴリに関連付けます。

-y

rjones@sestas.com という値はカレンダのもう一人の所有者を指定します。

-k yes|no

このオプションは、同一時間帯に複数のユーザーからの予約を有効または無効にします。

yes という値は、複数のユーザーからの予約を有効にします。 no という値は、複数のユーザーからの予約を無効にします。

create

新しいカレンダを作成するためのコマンド。

Personal

このカレンダに割り当てられるカレンダ ID。

15.5.2 リソース用の Calendar Server の設定

リソースカレンダは、スケジューリングが可能な会議室、ノートパソコン、OHP、その他の機器などに関連付けられます。リソースカレンダにはアクセス制御リストが必要です。

表 15–3 に示すように、ics.conf ファイルの 2 つの構成パラメータがリソースカレンダに適用されます。

resource.default.acl: デフォルトのアクセス制御リスト
resource.allow.doublebook: 複数のユーザーからの予約を許可または禁止するパラメータ

表 15–3 に示すように、これらのパラメータのデフォルト値を変更するには、ics.conf ファイルを編集します。デフォルト値の変更は、新しいリソースカレンダだけに適用されます。既存のリソースの値は変更されません。

Schema バージョン 1 の場合は、Calendar Server ユーティリティー cscal を使用して、既存のリソースカレンダの値を変更します。csresource ユーティリティーには modify コマンドはありません。

Schema バージョン 2 の場合は、Delegated Administrator ユーティリティーコマンド commadmin resource modify を使用します。Delegated Administrator コンソールでは、カレンダリソースについてのこれらの値を変更することはできません。

注 –

Calendar Server の通知ソフトウェアは、リソースに通知を送信するようにプログラミングされていません。通知を受け取るのはユーザーだけです。

表 15–3 ics.conf ファイルに指定できるリソースカレンダの構成パラメータ


パラメータ	説明とデフォルト値
`resource.default.acl`	このパラメータには、リソースカレンダの作成時にデフォルトで適用されるアクセス制御設定を特定します。デフォルトのアクセス許可は、次の ACL (アクセス制御リスト) によって指定されます。 `"@@o^a^r^g;@@o^c^wdeic^g;@^a^rsf^g"` この ACL は、コンポーネントとプロパティーの両方に対する読み取り、スケジュール、空き/予定ありの設定アクセス権をすべてのカレンダユーザーに付与します。リソースに対するアクセス権を変更するには、`csresource` ユーティリティーの create コマンドを使用してカレンダを作成するときに `-a` オプションを指定します。
`resource.allow.doublebook`	このパラメータには、リソースカレンダが複数のユーザーからの予約を許可するかどうかを指定します。複数のユーザーからの予約が許可される場合、リソースカレンダでは同時に複数の予定をスケジュールできます。デフォルト値は `"no"`— で、複数のユーザーからの予約は許可されません。リソースカレンダの複数のユーザーからの予約を許可するには、`csresource` ユーティリティーの create コマンドを使用してカレンダを作成するときに `-k` オプションを指定します。
`resource.invite.autoprovision`	デフォルト値は `"yes"` です。
`resource.invite.autoaccept`	デフォルト値は `"yes"` です。

15.5.3 リソースとリソースカレンダの作成

ヒント –

ics.conf パラメータ resource.invite.autoprovision の値が "yes" の場合、リソースカレンダは最初の出席依頼時に作成されます。つまり、このリソースがデフォルトカレンダを持っていない場合、初めて出席依頼がスケジュール設定された時にリソースカレンダが作成されます。

次のいずれかの方法でリソースを作成します。

Calendar Server ユーティリティー (Schema バージョン 1)

csresource create コマンドを使用します。

このユーティリティーは、リソースの LDAP エントリとデフォルトカレンダの両方を作成します。

リソースの LDAP エントリがすでに存在する場合、csresource ではカレンダのみが作成されます。LDAP エントリは重複して作成されません。

たとえば、カレンダ ID が aud100、表示名が Auditorium、およびデフォルトの設定を持つリソース LDAP エントリを作成するには、次のコマンドを実行します。

csresource -m aud100@siroe.com -c aud100 create Auditorium

Delegated Administrator ユーティリティーと Calendar Server ユーティリティー

2 つのコマンドを組み合わせて使用します。

LDAP エントリを作成するには、Delegated Administrator ユーティリティーコマンド commadmin resource create。
デフォルトカレンダを作成するには、Calendar Server ユーティリティーコマンド csresource create。

Delegated Administrator コンソール

Delegated Administration Console で LDAP リソースを作成するには、組織リストからこのリソースを配置する組織を選択します。該当する組織の「カレンダリソース」ページで、「新規」をクリックして「新規カレンダリソースを作成」ウィザードを起動します。

Delegated Administrator ユーティリティーについては、『Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide 』を参照してください。

Delegated Administrator Console については、オンラインヘルプを参照してください。

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

15.5.4 リソースカレンダでの複数のユーザーからの予約の許可

デフォルトでは、Calendar Server はリソースカレンダでの複数のユーザーからの予約 (resource.allow.doublebook パラメータ) を許可しません。このデフォルト設定は、部屋や装置などのリソースで予定の競合が生じることを防ぎます。ただし、リソースカレンダでの複数のユーザーからの予約を可能にするには、カレンダの作成時に csresource -k オプションを “yes” に設定します。

次のコマンドは、リソースの LDAP エントリとカレンダを作成しますが、-k オプションによってカレンダでの複数のユーザーからの予約が許可され、-o オプションによってカレンダの所有者が bkamdar に設定されます。また、-y オプションによってもう一人の所有者が jsmith@sesta.com に設定されます。

csresource -m aud100@siroe.com -c aud100 -k yes
    -o bkamdar -y jsmith@sesta.com create Auditorium

15.5.5 リソースカレンダに対するアクセスの制限

特定のリソースの予定を指定できるユーザーを制御するには、リソースカレンダに対して書き込みアクセス権を持つユーザーを制限してください。たとえば、会議室の予定設定や機器の使用予約を特定のユーザーに限定することができます。

リソースカレンダの所有者を指定しない場合、ics.conf ファイルの service.siteadmin.userid パラメータの値が適用されます。

15.6 ユーザーカレンダの管理

ここでは、Calendar Server ユーティリティー「D.5 cscal」を使用してユーザーカレンダを管理する手順について説明します。

ここでは、次の管理作業について説明します。

15.6.1 カレンダを表示するには

すべてのカレンダ、あるユーザーが所有するすべてのカレンダ、または特定のカレンダのプロパティーを表示するときは、cscal ユーティリティーの list コマンドを使用します。

次の例は、cscal を使用した 3 つの異なる作業を示しています。

カレンダデータベース内のすべてのカレンダを表示するには、次のように実行します。

cscal list
jsmith が所有するすべてのカレンダを表示するには、次のように実行します。

cscal - o jsmith list
カレンダ ID が jsmith:meetings のカレンダのすべてのプロパティーを表示するには、次のように実行します。

cscal -v list jsmith:meetings

15.6.2 カレンダを削除するには

Calendar Server から 1 つ以上のカレンダを削除するには、cscal ユーティリティーの delete コマンドを使用します。このユーティリティーはカレンダを削除しますが、ディレクトリサーバーからユーザーを削除することはありません。

次の 2 つの例は、cscal delete を使用して実行できる異なる作業を示しています。

jsmith@sesta.com:meetings というカレンダ ID を持つカレンダを削除するには、次のように実行します。

cscal delete jsmith@sesta.com:meetings
一次所有者が jsmith@sesta.com のすべてのカレンダを削除するには、次のように実行します。

cscal -o jsmith@sesta.com delete

注意 –

delete コマンドはすべてのカレンダ情報をカレンダデータベースから削除します。実行した処理を取り消すことはできません。カレンダを削除すると、それを復元できるのはカレンダデータがバックアップされている場合だけです。詳細は、第 17 章「Calendar Server データのバックアップと復元」を参照してください。

15.6.3 削除されたユーザーのカレンダを消去するには

Calendar Server Utility コマンド csuser delete、あるいは Delegated Administrator Console または Utility を使用して 1 つ以上のユーザーを削除した場合、そのユーザーが所有していたカレンダがまだデータベース内に存在している可能性があります。

ユーザーのカレンダを消去するには、次の 2 つの方法があります。使用する方法は、ユーザーを削除するのに使用したツールにより異なります。

Calendar Server ユーティリティー csuser

csuser ユーティリティーは、LDAP ディレクトリからユーザーを消去して、ユーザーのデフォルトのカレンダを消去しますが、ユーザーが所有していたその他のカレンダは消去しません。cscal を使用してこれらのカレンダを消去する方法については、「Calendar Server バージョン 6.3 で csuser を使用して削除されたユーザーのすべてのカレンダを消去するには」を参照してください。

Delegated Administrator コンソールとユーティリティー

Delegated Administrator はカレンダを消去しません。Delegated Administrator を使用して削除するユーザーをマークし、Calendar Server Utility の csclean を使用してマークしたユーザーのカレンダを消去します。

csclean を使用して削除されたユーザーのカレンダを消去する方法については、「Delegated Administrator を使用して削除されたユーザーのすべてのカレンダを消去するには」を参照してください。

Delegated Administrator Utility の使用方法については、『Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide 』を参照してください。

Delegated Administrator Console の使用方法については、オンラインヘルプを参照してください。

Calendar Server バージョン 6.3 で csuser を使用して削除されたユーザーのすべてのカレンダを消去するには

削除された所有者の uid のすべてのカレンダを検索するには、cscal list コマンドを実行します。

cscal -o owner list

所有者のすべてのカレンダを消去するには、cscal コマンドを使用します。

cscal -o owner delete

csuser list を再実行して、すべてのカレンダが消去されていることを確認します。

注 –
commadmin を使用してユーザーを「削除」としてマークし、ユーザーの LDAP エントリが削除されている場合は、この手順を使用します。

Delegated Administrator を使用して削除されたユーザーのすべてのカレンダを消去するには

Delegated Administrator はカレンダを消去しません。Delegated Administrator によって「削除」とマークされたユーザーのすべてのカレンダを消去するには、csclean ユーティリティーを使用します。

csclean を使用して、「削除」とマークされているがまだ削除されていないユーザーのすべてのカレンダを消去します。

たとえば、過去 10 日間で sesta.com ドメイン内の「削除」とマークされたユーザーのすべてのカレンダを消去するには、次のコマンドを実行します。

csclean -g 10 clean sesta.com

ユーザーが LDAP から削除されている場合は、cscal を使用してください。

手順については、「Calendar Server バージョン 6.3 で csuser を使用して削除されたユーザーのすべてのカレンダを消去するには」を参照してください。

15.6.4 カレンダを有効にするには

ユーザーがカレンダにアクセスできるようにするには、まず cscal enable コマンドを使用してカレンダを有効にする必要があります。

次の例は、カレンダを有効にする方法を示しています。

デフォルト設定を適用した jsmith@sesta.com:meetings カレンダを有効化するには、次のように実行します。

cscal enable jsmith@sesta.com:meetings
jsmith@sesta.com:meetings カレンダを有効化し、複数のユーザーからの予約を禁止するには、次のように実行します。

cscal -k no enable jsmith@sesta.com:meetings

15.6.5 カレンダを無効にするには

ユーザーがカレンダにアクセスできないようにするには、cscal ユーティリティーの disable コマンドを使用します。disable コマンドはユーザーによるカレンダへのアクセスを禁止しますが、カレンダデータベースから情報を削除するわけではありません。

たとえば、ユーザーが jsmith@sesta.com:meetings にアクセスできないようにするには、次のように実行します。

cscal disable jsmith@sesta.com:meetings

15.6.6 カレンダプロパティーを変更するには

カレンダプロパティーを変更するには、cscal ユーティリティーの modify コマンドを使用します。

たとえば、AllAdmins のグループスケジュール設定のアクセス制御設定を変更し、もう一人の所有者として RJones@sesta.com を指定するには、次のように実行します。

cscal -a "@@o^c^wd^g" -y RJones@sesta.com modify AllAdmins

この例で使用されている 2 つのコマンド変数の意味は次のとおりです。

-a "@@o^c^wd^g" は、AllAdmins のコンポーネント (予定および作業) に対する書き込みと削除のアクセス権を所有者に付与します。
-y RJones@sesta.com は、もう一人の所有者のユーザーID を指定します。

15.6.7 カレンダからプロパティーを消去するには

カレンダからプロパティー値を消去するには、cscal modify コマンドを使用し、オプションの値を 2 つの二重引用符("") で指定します。

次の 3 つの例は、異なるプロパティーを消去する方法を示しています。

jsmith@sesta.com:meetings から説明を消去するには、次のように実行します。

cscal -d "" modify jsmith@sesta.com:meetings
jsmith@sesta.com:meetings カレンダからすべてのカテゴリを消去するには、次のように実行します。

cscal -g "" modify jsmith@sesta.com:meetings
jsmith@sesta.com:meetings からその他の所有者を消去するには、次のように実行します。

cscal -y "" modify jsmith@sesta.com:meetings

15.6.8 「失われた」デフォルトカレンダを復元するには

ユーザーのデフォルトカレンダが Communications Express のユーザーインタフェースクライアントには表示されないが、データベースには存在する場合、ユーザーの LDAP エントリの 2 つの属性を更新することで、カレンダを復元し、再表示可能にできます。

カレンダを復元するには、ユーザーの LDAP エントリの次の属性の値がユーザーの完全修飾 calid であることを確認します。

icsCalendar
icsSubscribed

Schema バージョン 2 の場合は、次のいずれかの方法を使用して属性を更新します。

ldapmodify Directory Server ユーティリティーを使用します。
Calendar Server Utility の csuser reset コマンドを使用します。
Delegated Administrator Utility の commadmin user modify コマンドを使用します。
Delegated Administrator Console を使用して、「ユーザーのプロパティー」ページを編集してデフォルトのカレンダ名を追加します。

Schema バージョン 1 の場合は、csattribute add コマンドを使用して属性を更新できます。

ユーザーカレンダを別のバックエンドサーバーへ移動するには

あるバックエンドサーバーから別のバックエンドサーバーにユーザーカレンダを移動するには、次の手順を実行します。

元のサーバーで、「D.19 csuser」ユーティリティーを実行してカレンダユーザーを無効にします。たとえば、ユーザー ID と calid が bkamdar のユーザーを無効にするには、次のように実行します。

csuser disable bkamdar

元のサーバーで、「D.10 csexport」ユーティリティーを実行してカレンダデータベースからファイルにユーザーの各カレンダをエクスポートします。次に例を示します。

csexport -c bkamdar calendar bkamdar.ics

エクスポートしたカレンダファイル (*.ics) を元のサーバーから新しいサーバーにコピーします。

新しいサーバーで、エクスポートされた各カレンダに対して、「D.11 csimport」ユーティリティーを実行してファイルからカレンダデータベースにカレンダをインポートします。次に例を示します。

csimport -c bkamdar calendar bkamdar.ics

LDAP ディレクトリサーバーで「D.3 csattribute」ユーティリティーを実行し、カレンダ所有者の icsDWPHost LDAP 属性が新しいバックエンドサーバーをポイントするように変更します。属性を変更するには、まず属性を削除し、新しい値を持つ属性を追加します。たとえば、新しいサーバー名を sesta.com に設定するには、次のように実行します。
csattribute -a icsDWPHost delete bkamdar csattribute -a icsDWPHost=sesta.com add bkamdar

新しいサーバーで、「D.19 csuser」ユーティリティーを使用してユーザーカレンダのカレンダユーザーを有効にします。次に例を示します。

csuser enable bkamdar

新しいサーバーで、次のコマンドを実行して属性が正しく、各カレンダが正常に移動されていることを確認します。次に例を示します。
cscal -v -o bkamdar list bkamdar ... csattribute -v list bkamdar

元のサーバーで、移動した各カレンダを削除します。次に例を示します。

cscal -o bkamdar delete bkamdar

-o オプションを指定することで、一次所有者が bkamdar であるすべてのカレンダが削除されます。

注 –
CLD キャッシュオプションを使用している場合、カレンダを別のバックエンドサーバーに移動した後に、CLD キャッシュをクリアしてサーバー名を消去してください。CLD キャッシュに古いエントリが残されていると、フロントエンドサーバーが移動後のカレンダを見つけられなくなります。

CLD キャッシュをクリアするには、次の手順を実行します。
- Calendar Server を停止します。
- /var/opt/SUNWics5/csdb/cld_cache ディレクトリ内のすべてのファイルを消去します。ただし、cld_cache ディレクトリ自体は消去しません。
- Calendar Server を再起動します。

15.7 リソースカレンダの管理

ここでは、csresource ユーティリティーを使用してリソースカレンダを管理する方法について説明します。

リソースカレンダを管理する手順は次のとおりです。

15.7.1 リソースカレンダおよび属性を表示するには

リソースカレンダを表示するには、csresource ユーティリティーの list コマンドを使用します。

たとえば、次の作業を実行するためにユーティリティーを使用します。

たとえば、Calendar Server のすべてのリソースカレンダと、それに対応する LDAP 属性を表示するには、次のように実行します。

csresource list
Auditorium という特定のリソースカレンダのすべての LDAP 属性を表示するには、次のように実行します。

csresource - v list Auditorium

15.7.2 リソースカレンダを変更するには

ここでは、リソースカレンダを変更する方法について説明します。csresource ユーティリティーには modify コマンドがないため、「D.5 cscal」ユーティリティーコマンドを使用する必要があります。

たとえば、次のコマンドは、2 つの作業を同時に実行します。

所有者の uid を tchang に設定します。
uid が mwong である別の所有者を指定します。

cscal - o tchang -y mwong modify aud100

この例で、cscal ユーティリティーは、カレンダ名 (Auditorium) ではなくリソースの calid (aud100) が指定されている必要があります。

15.7.3 リソースカレンダを無効または有効にするには

ユーザーが予定をスケジュール設定できないようにするには、リソースカレンダを無効化する必要があります。たとえば、改修中で会議室を利用できない場合や、OHP が修理中の場合などがこれに該当します。

リソースカレンダの無効化と有効化には、csresource ユーティリティーの enable コマンドまたは disable コマンドを使用します。

たとえば、Auditorium というリソースカレンダを無効化するには、次のように実行します。

csresource disable Auditorium

あとからリソースカレンダを有効な状態に戻すには、次のように実行します。

csresource enable Auditorium

15.7.4 リソースカレンダを削除するには

リソースカレンダを削除するには、csresource ユーティリティーの delete コマンドを使用します。

たとえば、Auditorium というリソースカレンダを削除するには、次のように実行します。

csresource delete Auditorium

Calendar Server は次のメッセージを表示します。

Do you really want to delete this resource (y/n)?

カレンダを削除するときは y を入力し、処理をキャンセルするときは n を入力します。

y を入力すると、Calendar Server はカレンダを削除し、削除が完了したことを示すメッセージを表示します。

リソースカレンダを別のバックエンドサーバーへ移動するには

あるバックエンドサーバーから別のバックエンドサーバーにユーザーカレンダまたはリソースカレンダを移動するには、次の手順を実行します。

元のサーバーで、「D.15 csresource」ユーティリティーを実行してカレンダリソースを無効にします。たとえば、Auditorium という共通名を持つリソースを無効化するには、次のように実行します。

csresource disable Auditorium

元のサーバーで、「D.10 csexport」ユーティリティーを実行してカレンダデータベースからファイルに各リソースカレンダをエクスポートします。次に例を示します。

csexport -c aud100 calendar aud100.ics

エクスポートしたカレンダファイル (*.ics) を元のサーバーから新しいサーバーにコピーします。

新しいサーバーで、エクスポートされた各カレンダに対して、「D.11 csimport」ユーティリティーを実行してファイルからカレンダデータベースにカレンダをインポートします。次に例を示します。

csimport -c bkamdar calendar bkamdar.ics

LDAP ディレクトリサーバーで「D.3 csattribute」ユーティリティーを実行し、カレンダ所有者の icsDWPHost LDAP 属性が新しいバックエンドサーバーをポイントするように変更します。属性を変更するには、まず属性を削除し、新しい値を持つ属性を追加します。たとえば、新しいサーバー名を sesta.com に設定するには、次のように実行します。

csattribute -a icsDWPHost delete bkamdar csattribute -a icsDWPHost=sesta.com add bkamdar

新しいサーバーで、「D.15 csresource」ユーティリティーを実行してカレンダリソースを有効にします。次に例を示します。

csresource enable bkamdar

新しいサーバーで、次のコマンドを実行して属性が正しく、各カレンダが正常に移動されていることを確認します。次に例を示します。

cscal -v -o bkamdar list bkamdar csattribute - v list bkamdar

元のサーバーで、移動した各カレンダを削除します。次に例を示します。

cscal -o bkamdar delete bkamdar

-o オプションを指定することで、一次所有者が bkamdar であるすべてのカレンダが削除されます。

注 –
CLD キャッシュオプションを使用していて、カレンダを別のバックエンドサーバーに移動した場合は、CLD キャッシュをクリアしてサーバー名を消去するとよいでしょう。CLD キャッシュに古いエントリが残されていると、フロントエンドサーバーが移動後のカレンダを見つけられなくなります。CLD キャッシュをクリアするには、次の手順を実行します。
- Calendar Server を停止します。
- /var/opt/SUNWics5/csdb/cld_cache ディレクトリ内のすべてのファイルを消去します。ただし、cld_cache ディレクトリ自体は消去しません。
- Calendar Server を再起動します。

15.8 カレンダへのリンク設定

各カレンダに対する読み取りアクセスが許可されている場合は、、1 つ以上のユーザーカレンダまたはリソースカレンダへのリンクを作成することができます。たとえば、カレンダへのリンクを Web ページや電子メールメッセージに埋め込むことができます。その他のユーザーは、Calendar Server にアクセスすることなく匿名でカレンダを表示できます。

1 つ以上のユーザーカレンダへのリンクを作成するには、次の構文を使用します。

http://CommunicationsExpresshostname:
CommunicationsExpressport/uwc/
   ?calid=calid-1[; ... ;calid-n]

複数のカレンダ ID (calid) を区切るときは、セミコロン (;) を使用します。

たとえば、jsmith@sesta.com および jdoe@siroe.com のデフォルトカレンダへのリンクは、次のようになります。

http://calendar.sesta.com:8080/uwc/?calid=jsmith@sesta;jdoe@siroe.com

calid が overhead_projector10 の OHP のリソースカレンダへのリンクは、次のようになります。

http://calendar.sesta.com:8080/uwc/?calid=overhead_projector10

15.9 Calendar Server 6.3 データベースでのカレンダデータのインポートとエクスポート

カレンダデータをファイルにエクスポートしたり、ファイルからインポートしたりするには、csexport ユーティリティーと csimport ユーティリティーを使用します。サポートされているカレンダデータの形式は、iCalendar (.ics) と XML (.xml) です。

csexport と csimport は、Calendar Server がインストールされているマシンでローカルに実行する必要があります。Calendar Server は稼動中でも停止していてもかまいません。

15.9.1 カレンダデータのインポート

csexport ユーティリティーを使用して作成したファイルからカレンダデータをインポートするときは、csimport を使用します。保存されているインポートファイルの形式は、そのファイルの拡張子 (.ics または .xml ) で示されます。

たとえば、カレンダ ID (calid) が jsmithcal@sesta.com のカレンダに iCalendar 形式 (text/calendar MIME) で保存された jsmith.ics というファイルからデータをインポートするには、次のように実行します。

csimport -c jsmithcal@sesta.com calendar jsmith.ics

この jsmithcal@sesta.com カレンダに XML 形式 (text/xml MIME) で保存された jsmith.xml というファイルからデータをインポートするには、次のように実行します。

csimport -c jsmithcal@sesta.com calendar jsmith.xml

15.9.2 カレンダデータのエクスポート

カレンダデータをファイルにエクスポートするときは、csexport を使用します。ファイルの形式は、出力ファイルに指定する拡張子 (.ics または .xml ) によって決定されます。

次の例は、エクスポートユーティリティーの使用方法を示しています。

カレンダ ID (calid) が jsmithcal@sesta.com のカレンダを iCalendar 形式 (text/calendar MIME) の jsmith.ics というファイルにエクスポートするには、次のように実行します。

csexport - c jsmithcal@sesta.com calendar jsmith.ics
この jsmithcal@sesta.com カレンダを XML 形式 (text/xml MIME) の jsmith.xml というファイルにエクスポートするには、次のように実行します。

csexport -c jsmithcal@sesta.com calendar jsmith.xml

第 16 章 csdb ユーティリティーを使用した Calendar Server データベースの管理

Calendar Server では、複数のディレクトリに多くのデータベースファイルを保存します。第 9 章「自動バックアップ (csstored) の設定」で説明している自動バックアッププロセスを実装するか、または独自のバックアップシステムを実装して、データベースファイルを保護する必要があります。 csdb ユーティリティーを使用すると、データベースファイルを管理できます。

この章では、csdb ユーティリティーを使用した Calendar Server データベースの管理方法について、次の項目を説明します。

16.1 csdb ユーティリティーを使用したカレンダデータベースの管理

データベースファイルを管理するには、Calendar Server ユーティリティーの csdb を使用します。ここで説明する内容は次のとおりです。

16.1.1 3 つの論理データベースグループの識別

カレンダデータベースのユーティリティー (csdb) では、データベースファイルを 3 つの論理データベース (グループ) として扱います。

16.1.1.1 カレンダデータベースグループ (csdb)

caldb は、データベースディレクトリにあるすべての .db ファイルと _db.* ファイルで構成されます。カレンダデータベースファイルのデフォルトの場所は、次のとおりです (cld_cache および ldap_cache サブディレクトリも同様)。

/var/opt/SUNWics5/csdb

Calendar Server の設定プログラム (csconfigurator.sh) を利用して、別のディレクトリを指定することもできます。設定プログラムについては、第 2 章「Calendar Server 6.3 ソフトウェアの初期実行時設定プログラム (csconfigurator.sh)」を参照してください。

次の表は、各種カレンダデータベース (caldb) ファイルについての説明です。

表 16–1 Calendar Server データベースファイル


ファイル	説明
`ics50calprops.db`	すべてのカレンダのカレンダプロパティー。カレンダ ID (`calid`)、カレンダ名、ACL (アクセス制御リスト)、所有者が記録されています。
`ics50events.db`	すべてのカレンダの予定。
`ics50todos.db`	すべてのカレンダの仕事 (作業)。
`ics50alarms.db`	すべての予定と仕事 (作業) のアラーム。
`ics50gse.db`	GSE (グループスケジューリングエンジン) のスケジューリング要求のキュー。
`ics50journals.db`	カレンダのジャーナル。現在のリリースにはジャーナルは実装されていません。
`ics50caldb.conf`	データベースのバージョン識別子。
`ics50recurring.db`	定期的な予定。
`ics50deletelog.db`	削除された予定と仕事 (作業)。第 18 章「削除ログデータベースの管理」も参照してください。

16.1.1.2 セッションデータベース (`sessdb`)

セッションデータベースは、次のディレクトリにあるすべてのファイルで構成されます。/opt/SUNWics5/cal/lib/admin/session/ および /opt/SUNWics5/cal/lib/http/session/

16.1.1.3 統計情報データベース (`statdb`)

統計情報データベースは、counter ディレクトリにあるすべてのファイルで構成されます。

/opt/SUNWics5/cal/lib/counter/

16.1.2 csdb ユーティリティーを使用した特定のデータベースグループのターゲット設定

csdb ユーティリティーの -t オプションを使用すると、ターゲットデータベースを指定できます。

-t caldb: カレンダデータベースグループ。
-t sessdb: セッションデータベースグループ。
-t statdb: 統計情報データベースグループ。

ヒント –

-t オプションを指定しない場合、csdb は 3 種類すべてのデータベースを対象に動作します。check と rebuild の 2 つのコマンドは、カレンダデータベース、caldb だけを対象に動作します。

16.2 csdb ユーティリティーを使用したデータベースの管理

ここでは、「D.8 csdb」ユーティリティーを使用して次の管理作業を行う方法について説明します。

注 –

csdb ユーティリティーを実行するには、Calendar Server が稼動しているシステムの管理権限を持つユーザーとしてログインする必要があります。詳細は、付録 D 「Calendar Server のコマンド行ユーティリティーのリファレンス」を参照してください。

データベースグループの状態をリスト表示するには

データベースグループ (caldb、sessdb、statdb) の状態を確認するには、csdb ユーティリティーの list コマンドを使用します。

データベースの状態をリスト表示するには

Calendar Server がインストールされているシステムの管理権限を持つユーザーとしてログインします。

Calendar Server は稼動中でも停止していてもかまいませんが、可能であれば停止してください。

/sbin ディレクトリに移動します。たとえば、Solaris オペレーティングシステムでは次のように入力します。

cd /opt/SUNWics5/cal/sbin

データベースグループの 1 つまたはすべてに対して list コマンドを実行します。たとえば、3 種類すべてのデータベースグループの状態と統計情報をリスト表示するときは、次のように実行します。

./csdb list

次のコードは出力のサンプルを示しています。

Sleepycat Software: Berkeley DB 4.1.25: (December 19, 2002)

Calendar database version: 3.0.0 [BerkeleyDB]
Total database size in bytes: 57344

Session database version: 1.0.0 [BerkeleyDB]
Total database size in bytes: 0

Counter database version: 1.0.0 [Memory Mapped Files]
Total database size in bytes: 118792

または、冗長モードが使用できます。次に例を示します。

./csdb -v list

次のサンプルコードは詳細出力を示しています。

Sleepycat Software: Berkeley DB 4.1.25: (December 19, 2002)

Calendar database version: 3.0.0 [BerkeleyDB]
Total database size in bytes: 57344
Total number of calendars:    2
Total number of events:       0
Total number of tasks:        0
Total number of alarms:       0
Total number of gse entries:  0
Total number of master component entries:  0
Total number of deletelog entries:  0
Total logfile size in bytes:  5779919

Session database version: 1.0.0 [BerkeleyDB]
Total database size in bytes: 0
Total logfile size in bytes:  0

Counter database version: 1.0.0 [Memory Mapped Files]
Total database size in bytes: 118792

1 つのターゲットデータベースのグループ (caldb, sessdb、または statdb) の指定には、-t オプションを使用します。たとえば、カレンダデータベースのみのデータベースの状態と統計情報を表示するときは、次のように実行します。

csdb - t caldb list

カレンダデータベースグループでの破損をチェックするには

カレンダプロパティー (calprops)、予定、および仕事 (作業) を含め、カレンダデータベースを走査して破損がないかどうか調べるには、check コマンドを使用します。check コマンドにより回復不能な不整合が検出された場合、その状況がレポートとして出力されます。

check コマンドは、アラームまたは GSE (グループスケジューリングエンジン) データベースの破損をチェックしません。

データベースの破損をチェックするには、次のように実行します。

Calendar Server がインストールされているシステムの管理権限を持つユーザーとしてログインします。

Calendar Server は稼動中でも停止していてもかまいませんが、可能であれば停止してください。

カレンダデータベースのコピーをまだ作成していない場合は、コピーを作成します。データベース (.db) ファイルだけをコピーします。共有ファイル (__db.*) やログファイル (log.*) をコピーする必要はありません。

cal-svr-base/SUNWics5/cal/sbin ディレクトリに移動します。たとえば、Solaris オペレーティングシステムでは次のように入力します。

cd /opt/SUNWics5/cal/sbin

カレンダデータベースのコピーに対して check コマンドを実行します。

./csdb check dbdir \> /tmp/check.out 2\>&1

dbdir を指定しない場合、現在のディレクトリに格納されているデータベースに対して check が実行されます。

check コマンドは大量の情報を生成する可能性があるので、この例で示すように stdout や stderr を含むすべての出力をファイルとして書き出すことをお勧めします。

check コマンドの実行後、出力ファイルを確認します。

データベースが破損している場合、ホットバックアップのコピーに置き換えることができます。または、rebuild コマンドを実行して、破損したデータベースを再構築することもできます。

GSE データベースなしにカレンダデータベースグループ (caldb) を再構築するには

破損してしまったカレンダデータベース (caldb) を復元するときは、csdb ユーティリティーの rebuild コマンドを使用します。rebuild コマンドで、すべてのカレンダデータベースを走査して破損の発生を調べます。不整合が検出されると、rebuild コマンドは再構築したカレンダデータベース (.db ファイル) を cal-svr-base/SUNWics5/cal/sbin/rebuild_db ディレクトリに生成します。

rebuild は大量の情報を生成する可能性があるので、stdout や stderr を含むすべての出力をファイルとして書き出すことをお勧めします。

次に示す手順では、rebuild コマンドは GSE (グループスケジューリングエンジン) データベースを再構築しません。

GSE データベースなしにカレンダデータベースを再構築するには、次のように実行します。

Calendar Server がインストールされているシステムの管理権限を持つユーザーとしてログインします。

Calendar Server を停止します。

カレンダデータベースのコピーをまだ作成していない場合は、コピーを作成します。データベース (.db) ファイルとログ (log.*) ファイルをコピーします。共有ファイル (__db.*) をコピーする必要はありません。

cal-svr-base/SUNWics5/cal/sbin ディレクトリに移動します。たとえば、Solaris オペレーティングシステムでは次のように入力します。

cd /opt/SUNWics5/cal/sbin

sbin ディレクトリのディスク容量が問題となる場合は、別のディレクトリで rebuild コマンドを実行します。

カレンダデータベースの作成したコピーに対して rebuild コマンドを実行します。

./csdb rebuild /tmp/db /tmp/

データベースディレクトリを指定しない場合、rebuild コマンドは

現在のディレクトリに格納されているデータベースを使用します。上記の例では、/tmp/ パラメータは、再構築したデータベースの出力先ディレクトリを指定しています。

注 –
カレンダデータベースを再構築するときは、常に最新のバックアップコピーを使用してください。

ただし、膨大なデータが失われ、データベースの定期バックアップで複数のコピーを利用できるときは、最新のコピーから最も古いコピーの順に再構築を行います。この方法の唯一の欠点は、すでに削除されているカレンダコンポーネントが再構築されたデータベースに再表示されることです。

たとえば、3 つのバックアップカレンダデータベースファイルが db_0601、db_0615、および db_0629 というディレクトリに格納されている場合は、次の順序で rebuild コマンドを実行します。
1. ./csdb rebuild db_0629
  
  Then check for corruption. If this backup copy is also corrupt, then run rebuild on the next backup copy.
2. ./csdb rebuild db_0615
  
  Then check for corruption. If this backup copy is also corrupt, then run rebuild on the next backup copy.
3. ./csdb rebuild db_0601
  
  ... etc.
rebuild コマンドは再構築したデータベースを cal-svr-base/SUNWics5/cal/sbin/rebuild_db ディレクトリに書き込みます。

rebuild の実行が完了したら、rebuild.out ファイルを確認します。再構築が正常に完了した場合、rebuild.out ファイルの最後の行は次のようになります。
Calendar database has been rebuilt

rebuild の成功を確認したら、再構築したデータベース (.db) ファイルとトランザクションログ (log.*) ファイルを、rebuild_db ディレクトリから運用データベースにコピーします。

破損したデータベースのディレクトリに共有ファイル (__db.*) が含まれていた場合は、それも運用ディレクトリに移動します。

Calendar Server を再起動します。

カレンダデータベースグループを再構築するには ? GSE データベースを含める場合

サイトにグループスケジューリングを実装している場合は、再構築に GSE を含めることをお勧めします。

カレンダデータベースと GSE データベースの両方を再構築するには、次のように実行します。

GSE データベースにエントリが含まれているかどうかを調べるには、csschedule -v list コマンドを実行して GSE がすべてのエントリの処理を完了するようにします。

Calendar Server がインストールされているシステムの管理権限を持つユーザーとしてログインします。

Calendar Server を停止します。

カレンダデータベースのコピーをまだ作成していない場合は、コピーを作成します。

データベース (.db) ファイルとログ (log.*) ファイルをコピーします。共有ファイル (__db.*) をコピーする必要はありません。

cal-svr-base/SUNWics5/cal/sbin ディレクトリに移動します。

たとえば、Solaris オペレーティングシステムでは次のように入力します。

cd /opt/SUNWics5/cal/sbin

sbin ディレクトリのディスク容量が問題となる場合は、別のディレクトリで rebuild コマンドを実行します。

カレンダデータベースのコピーに対して rebuild コマンドを実行します。

./csdb -g rebuild /tmp/db /tmp/

データベースディレクトリを指定しない場合、現在のディレクトリに格納されているデータベースに対して rebuild が実行されます。上記の例では、/tmp/ パラメータは、再構築したデータベースの出力先ディレクトリを指定しています。

注 –
カレンダデータベースを再構築するときは、常に最新のバックアップコピーを使用してください。

ただし、膨大なデータが失われ、データベースの定期バックアップで複数のコピーを利用できるときは、最新のコピーから最も古いコピーの順に再構築を行います。この方法の唯一の欠点は、すでに削除されているカレンダコンポーネントが再構築されたデータベースに再表示されることです。

たとえば、3 つのバックアップカレンダデータベースファイルが db_0601、db_0615、および db_0629 というディレクトリに格納されている場合は、次の順序で rebuild コマンドを実行します。

./csdb rebuild db_0629 ./csdb rebuild db_0615 ./csdb rebuild db_0601

次に、rebuild コマンドは再構築したデータベースを cal-svr-base/SUNWics5/cal/sbin/rebuild_db ディレクトリに書き込みます。

rebuild の実行が完了したら、rebuild.out ファイルを確認します。

再構築が正常に完了した場合、rebuild.out ファイルの最後の行は次のようになります。
Calendar database has been rebuilt

rebuild の成功を確認したら、再構築したデータベース (.db) ファイルを rebuild_db ディレクトリから運用データベースにコピーします。

破損したデータベースのディレクトリに共有ファイル (__db.*) が含まれていた場合は、それも運用ディレクトリに移動します。

Calendar Server を再起動します。

例 16–1 再構築出力のサンプル

出力サンプルでは、予定と仕事のデータベースがそれぞれ 2 回走査されたことを示しています。これはエラーではありません。最初の走査では calprops データベースの情報を確認し、次に再走査して calprops が確実にカレンダデータベースからアクセスできることを確認します。

次の例は、コマンドと、そのコマンドにより生成された出力を示しています

# ./csdb -g rebuild
Building calprops based on component information.
Please be patient, this may take a while...
Scanning events database...
512 events scanned
Scanning todos database...
34 todos scanned
Scanning events database...
512 events scanned
Scanning todos database...
34 todos scanned
Scanning deletelog database...
15 deletelog entries scanned
Scanning gse database...
21 gse entries scanned
Scanning recurring database...
12 recurring entries scanned
Successful components db scan
Calendar database has been rebuilt
Building components based on calprops information.
Please be patient, this may take a while...
Scanning calprops database to uncover events...
25 calendars scanned
Scanning calprops database to uncover todos...
25 calendars scanned
Successful calprops db scan
Calendar database has been rebuilt

16.2.1 データベースグループを削除するには

カレンダデータベースを削除するには、csdb ユーティリティーの delete コマンドを使用します。Calendar Server は停止している必要があります。

ターゲットデータベース (caldb、sessdb、または statdb) を指定するときは、-t オプションを指定します。指定しない場合、csdb は 3 種類すべてのデータベースを削除します。

たとえば、カレンダデータベースを削除するときは、次のように実行します。

csdb -t caldb delete

データベースを削除する前に、csdb ユーティリティーは警告を出力します。

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

Calendar Server により提供される自動バックアップ機能の使用を選択していない場合は、csstored を使用して、バックアップ手順を実装し、データを保護する必要があります。この章では、手動バックアップを実行して、カレンダデータベースファイルを復元するための Calendar Server およびほかの Sun ツールの使用方法を説明します。

/var/opt/SUNWics5/csdb ディレクトリに格納されている Calendar Server データのバックアップと復元には、次のコマンド行ユーティリティーを使用します。

csbackup コマンドは、カレンダデータベース、特定したカレンダ、またはユーザーのデフォルトカレンダをバックアップします。バックアップ対象のディレクトリは、ランタイムユーザー (icsuser) が所有する必要があります。そうでない場合、データの復元を試みるとエラーメッセージが出力されます。
csrestore は、csbackup で生成したカレンダデータベース、個々のカレンダ、ユーザーのデフォルトカレンダを復元します。

注 –

Berkeley データベースのツール (db_recover など) を使用する既存のカスタムスクリプトがある場合、Calendar Server 6.3 以降にアップグレードすると、ツールが機能しない場合があります。初期のバージョンの Calendar Server ソフトウェアでは、ツールはスタティックライブラリでコンパイルされていました。現在は、ダイナミックライブラリでコンパイルされています。

この変更に対応するには、カスタムスクリプトを次のように変更してダイナミックリンクライブラリを使用可能にする必要があります。大域変数 LD_LIBRARY_PATH をダイナミックライブラリの名前 (libdb-4.2.so) に変更します。

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

注意 –

Calendar Server バージョン 2 のデータには最新製品との互換性がありません。データを喪失する可能性があるので、Calendar Server バージョン 2 の backup ユーティリティーでバックアップしたカレンダデータを復元しないでください。

最新リリースに移行するバージョン 2 のカレンダデータがある場合は、テクニカルサポートに問い合わせて適切な移行ユーティリティーを入手してください。

17.1 Calendar Server データのバックアップ

csbackup ユーティリティーを使用して、カレンダデータベース、指定したカレンダ、ユーザーのデフォルトカレンダをバックアップできます。ここで説明する内容は、次のとおりです。

カレンダデータベースのディレクトリへのバックアップ

データベースファイルの所有者 (icsuser など) としてログインします。

csbackup ユーティリティーの database コマンドを使用します。

たとえば、カレンダデータベースを backupdir というディレクトリにバックアップするときは、次のように実行します。

csbackup -f database backupdir

バックアップディレクトリ内のバージョンファイル ics50caldb.conf を調べて、正しいバージョンのデータベースがバックアップされたかどうか確認します。

注 –
ターゲットバックアップディレクトリがすでに存在し、-f オプションを指定しない場合は、csbackup ユーティリティーの実行は失敗します。たとえば、backupdir ディレクトリがすでに存在する場合は、そのディレクトリが空であっても次のコマンドの実行は失敗します。

csbackup database backupdir

このため、既存のターゲットバックアップディレクトリを指定するときは、-f オプションを指定して csbackup を実行する必要があります。

存在しないターゲットバックアップディレクトリを指定し、csbackup にディレクトリを新規作成させることもできます。

指定したカレンダのファイルへのバックアップ

データベースの所有者 (icsuser) としてログインします。

カレンダを iCalendar 形式または XML 形式のファイルにバックアップするときは、csbackup ユーティリティーの calendar コマンドを使用します。

バックアップファイルの形式は、ファイル名拡張子 (.ics または .xml ) によって示されます。

たとえば、jsmithcal@sesta.com というカレンダを iCalendar 形式 (text/calendar MIME) の jsmith.ics というファイルとして backupdir ディレクトリ内にバックアップするには、次のように実行します。

csbackup -c jsmithcal@sesta.com calendar backupdir/jsmith.ics

また、jsmithcal@sesta.com というカレンダを XML 形式 (text/XML MIME) の jsmith.xml というファイルとして backupdir ディレクトリ内にバックアップするには、次のように実行します。

csbackup -c jsmithcal@sesta.com calendar backupdir/jsmith.xml

ユーザーデフォルトカレンダのファイルへのバックアップ

データベースの所有者 (icsuser) としてログインします。

ユーザーのデフォルトカレンダを iCalendar 形式または XML 形式のテキストファイルにバックアップするには、csbackup ユーティリティーの def cal コマンドを使用します。ファイルの形式は、出力ファイルに指定する拡張子 (.ics または.xml ) によって決定されます。

たとえば、jsmith@sesta.com というユーザーのデフォルトカレンダを jsmith.ics という iCalendar 形式 (text/calendar MIME) のファイルにバックアップするには、次のように実行します。

csbackup -a jsmith@sesta.com defcal backupdir/jsmith.ics

また、jsmith@sesta.com のデフォルトカレンダをjsmith.xml というXML 形式(text/xml MIME) のファイルにバックアップするには、次のように実行します。

csbackup -a jsmith@sesta.com defcal backupdir/jsmith.xml

17.2 Calendar Server データの復元

csrestore は、csbackup で生成したカレンダデータベース、個々のカレンダ、ユーザーのデフォルトカレンダを復元します。csrestore ユーティリティーを Calendar Server がインストールされているローカルマシンで実行し、最初に Calendar Server を停止する必要があります。データベースのバックアップ時は Calendar Server は稼動していてもかまいません。

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

カレンダデータベースの復元

データベースの所有者 (icsuser) としてログインします。

csbackup ユーティリティーで作成したバックアップディレクトリからカレンダデータベースを復元するときは、csrestore ユーティリティーの database コマンドを使用します。

たとえば、backupdir というバックアップディレクトリに保存されているカレンダデータベースを復元するには、次のように実行します。

csrestore database backupdir

バックアップディレクトリからのカレンダの復元

データベースの所有者 (icsuser) としてログインします。

csbackup ユーティリティーで作成したバックアップディレクトリに保存されているデータベースから特定のカレンダを復元するときは、-c オプションを指定して csrestore ユーティリティーの database コマンドを実行します。

たとえば、backupdir というバックアップデータベースディレクトリから jsmithcal@sesta.com というカレンダを復元するときは、次のように実行します。

csrestore -c jsmithcal@sesta.com calendar backupdir

バックアップファイルからのカレンダの復元

データベースの所有者 (icsuser) としてログインします。

csbackup ユーティリティーで作成したバックアップファイルから特定のカレンダを復元するときは、-c オプションを指定して csrestore ユーティリティーの calendar コマンドを実行します。

保存されているカレンダファイルの形式は、そのファイルの拡張子 (.ics または .xml) で示されます。

たとえば、iCalendar 形式 (text/calendar MIME) の jsmith.ics というファイルとして backupdir ディレクトリに保存されている jsmithcal@sesta.com というカレンダを復元するには、次のように実行します。

csrestore -c jsmithcal@sesta.com calendar backupdir/jsmith.ics

また、XML 形式 (text/calendar MIME) の jsmith.xml というファイルとして bcakupdir ディレクトリに保存されている jsmithcal@sesta.com というカレンダを復元するには、次のように実行します。

csrestore -c jsmithcal@sesta.com calendar backupdir/jsmith.xml

ユーザーのデフォルトカレンダの復元

データベースの所有者 (icsuser) としてログインします。

csbackup ユーティリティーでバックアップファイルに保存したユーザーのデフォルトカレンダを復元するには、csrestore ユーティリティーの defcal コマンドを使用します。

保存されているカレンダファイルの形式は、そのファイルの拡張子 (.ics または .xml ) で示されます。

たとえば、iCalendar 形式 (text/calendar MIME) の jsmith.ics というファイルとして backupdir ディレクトリに保存されている、 jsmith@sesta.com というユーザーのデフォルトカレンダを復元するには、次のように実行します。

csrestore -a jsmith@sesta.com defcal backupdir/jsmith.ics

また、XML 形式 (text/xml MIME) の jsmith.xml というファイルとして backupdir ディレクトリに保存されている、jsmith というデフォルトカレンダを復元するには、次のように実行します。

csrestore -a jsmith@sesta.com defcal backupdir/jsmith.xml

17.3 Sun StorEdge Enterprise Backup^TM または Legato Networker® の使用

Sun StorEdge Enterprise Backup ソフトウェア (従来の Solstice Backup) または Legato Networker を使用して Calendar Server データのバックアップと復元を行うこともできます。Sun StorEdge Enterprise Backup ソフトウェアと Legato Networker は似ているので、ここで紹介する手順はどちらの製品にも適用できます。

ただし、Calendar Server のバックアップを行う前に、Sun StorEdge Enterprise Backup または Legato Networker のマニュアルを参照してください。

Sun StorEdge Enterprise Backup ソフトウェアのマニュアルは、http://docs.sun.com で入手できます。

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

17.3.1 StorEdge ツールまたは Legato ツール

/opt/SUNWics5/cal/sbin ディレクトリには、Sun StorEdge または Legato バックアップソフトウェアを使用する上で必要となる次のファイルが格納されています。

icsasm: Calendar Server ASM (Application Specific Module)。ASM は、Sun StorEdge または Legato バックアップソフトウェアがデータをバックアップまたは復元するときに呼び出されるプログラムです。
legbackup.sh: csbackup ユーティリティーを呼び出すスクリプト。
legrestore.sh: csrestore ユーティリティーを呼び出すスクリプト。

Sun StorEdge Enterprise Backup ソフトウェアまたは Legato Networker を使用して Calendar Server データをバックアップするには

Sun StorEdge または Legato バックアップソフトウェアを使用してカレンダデータベースをバックアップするには、次の手順を実行します。

Sun StorEdge または Legato の nsrfile バイナリファイルを /usr/lib/nsr ディレクトリにコピーします。

/usr/lib/nsr ディレクトリに次のシンボリックリンクを作成します。

icsasm -\> /opt/SUNWics5/cal/sbin/icsasm nsrfile -\> /usr/lib/nsr/nsrfile

/opt/SUNWics5/cal/sbin ディレクトリに移動し、-l オプションを指定して csbackup ユーティリティーを実行します。次に例を示します。

cd /opt/SUNWics5/cal/sbin ./csbackup -l

-l オプションによって、現在のディレクトリの下にバックアップディレクトリイメージが作成されます。このディレクトリ内のファイルは空で、カレンダがバックアップ媒体にどのように格納されるかをバックアッププログラムに伝えるためだけに使用されます。バックアップディレクトリがすでに存在する場合、現在のディレクトリ構造がそのディレクトリに反映されます。

save コマンドを実行してカレンダデータをバックアップします。次に例を示します。次に例を示します。

/usr/bin/nsr/save -s /opt/SUNWics5/cal/sbin/budir

Sun StorEdge または Legato のバックアップ GUI でクライアント保存セットを設定してバックアップをスケジューリングし、データベースを定期的にバックアップすることもできます。

注: .nsr ファイルを変更しないでください。これらのファイルには、バックアップ時に save コマンドと icsasm コマンドが解釈する指令が記録されています。

Calendar Server は増分バックアップ機能をサポートしていません。バックアップディレクトリはフォルダ構造のイメージに過ぎず、実際のデータを含まないので、この機能を使用しないでください。

ASCII 以外の文字またはスラッシュ記号 (/) を含む名前を付けてカレンダをバックアップすることはできません。

バックアップ手順を自動化します。

これまでは手動で行うバックアップ手順について説明してきました。バックアッププログラムの backup コマンドを設定し、バックアッププログラムの save コマンドによって自動的なバックアッププロセスが開始される前に、Calendar Server の csbackup コマンド行ユーティリティーが実行されるようにします。

Sun StorEdge Enterprise Backup ソフトウェアまたは Legato Networker を使用して Calendar Server データを復元するには

Calendar Server データを復元するには、次の手順を実行します。

Sun StorEdge Enterprise Backup ソフトウェアの nwrestore 機能または recover コマンドを使用して、バックアップされているカレンダ情報を復元します。

nwrestore を使用した場合は次のメッセージが出力されます。
"File already exists. Do you want to overwrite, skip, backup, or rename?"

overwrite を選択します。

このメッセージは、バックアップツリーが単なるディレクトリ階層であるために表示されます。つまり、このツリーは空のファイルだけを含み、この状態は変化しません。

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

Calendar Server には、削除された予定や仕事 (作業) を格納するための削除ログデータベース (ics50deletelog.db) が用意されています。

初期のリリースでは、Calendar Server は削除された予定や作業をデータベースに維持していませんでした。カレンダの予定と作業のローカルコピーを格納するユーザーインタフェースでは、どの予定が削除されたかを判断することが困難でした。クライアントソフトウェアは、どのコンポーネントが削除されたかを判断するために、すべての予定または仕事 (作業) の一意の識別子 (uid) または定期予定 ID (rid) を、データの Calendar Server コピーと比較するしかありませんでした。この制限は、WCAP コマンドを使用してクライアントユーザーインタフェース (UI) を作成するインストールに直接影響しました。この制限を解決するため、削除ログデータベースが作成されました。

削除ログは、データベースファイルと同様に管理する必要があります。次の節で、削除ログファイルの管理について説明します。

18.1 削除ログデータベースの作成

Calendar Server は、その他の Calendar Server データベースファイルと同様に削除ログデータベース (ics50deletelog.db) を csdb ディレクトリ内に自動的に作成します。Calendar Server は、予定と仕事を次のように削除ログデータベースに書き込みます。

繰り返されない予定と仕事

繰り返されない予定または仕事を削除すると、Calendar Server はそれを予定データベース (ics50events.db) または仕事データベース (ics50todos.db) から消去し、削除ログデータベース (ics50deletelog.db) に書き込みます。
定期的な予定と仕事

定期的な予定または仕事の個々のインスタンスが削除された場合、Calendar Server は削除された予定または仕事のインスタンスを削除ログデータベース (ics50deletelog.db) に書き込みます。

定期的な予定または仕事のすべてのインスタンスを削除すると、Calendar Server は予定データベースまたは仕事データベースからマスターコンポーネントを削除し、それを削除ログデータベースに書き込みます。削除ログデータベース内のマスターコンポーネントには、繰り返しパラメータ rrules、rdates、exrules、および exdates が含まれます。

18.2 削除ログデータベースの照会

ここでは、削除ログデータベースを照会する方法について説明します。

削除ログデータベースからエントリを返すには、展開モードまたは圧縮モードの fetch_deletedcomponents WCAP コマンドを使用します。

次に、それぞれのモードを使用する場合とその方法について説明します。

展開モード (recurring = 0)

recurring パラメータが 0 の場合、fetch_deletedcomponents は、条件と一致する定期的な予定のすべてのインスタンスを返しますが、定期的な予定のマスターコンポーネントは返しません。
圧縮モード (recurring = 1)

recurring パラメータが 1 の場合、fetch_deletedcomponents は、繰り返されない予定、および定期的な予定のマスターコンポーネントを返しますが、個々の定期的な予定は返しません。

繰り返しチェーンのすべてのインスタンスを削除すると、マスターコンポーネントは dtstart 、dtend、rrules、rdates、exrules、exdates、および uid パラメータを返します。

また fetch_deletedcomponents は、削除された繰り返しインスタンスに関連付けられているアクティブな状態のマスターコンポーネントを返しません。アクティブな状態のマスターコンポーネントを返すには、fetchcomponents_by_lastmod WCAP コマンドを使用します。fetch_deletedcomponents コマンドは、fetchcomponents_by_lastmod コマンドと組み合わせて使用する必要があります。

WCAP コマンドについては、『Sun Java System Calendar Server 6.3 WCAP Developer’s Guide 』を参照してください。

18.3 削除ログデータベースの破棄

ここでは、削除ログデータベースを破棄する方法について説明します。Calendar Server では、削除ログデータベースを破棄する方法として、自動と手動の 2 つが用意されています。

ここでは、次の内容について説明します。

18.3.1 削除ログの破棄の調整

削除ログデータベースを破棄する前に、サービスを受けるエンドユーザーに十分注意する必要があります。エンドユーザーが Communications Express を使用している場合、デフォルトのパラメータ設定で十分です。しかし、予定と作業のローカルコピーを格納した、Connector for Microsoft Outlook や Sync Tool などのクライアントユーザーインタフェースを使用している場合は、自動破棄構成パラメータの設定をそれぞれの必要に応じて調整する必要があります。一般に、30 日間またはそれ以上のエントリを削除ログに格納しておく必要があります。このため、削除ログのサイズが非常に大きくなります。この調整を行わないと、データベースに問題が生じることがあります。破棄間隔も、ユーザーの必要に合わせて調整してください。たとえば、データを破棄できるようになるまで 30 日間削除ログデータベースに格納しておく場合、1 分ごとに破棄を実行しても無駄になる可能性があります。しかしどんなものでも日々古くなっていくので、毎日の破棄は妥当なことです。

同様の問題は、手動で cspurge を実行する場合にも起きる可能性があります。削除ログから削除しすぎると、Connector for Microsoft Outlook および Sync Tool のユーザーがサーバーデータベースと同期できなくなることがあります。

削除ログデータベースを破棄するまでかなりの時間が経過した場合、ファイルが非常に大きくなる原因になります。この場合、巨大な破棄が行われたときに、日常のトランザクションログが非常に大きくなります。なぜなら、各項目を破棄するというトランザクションは、トランザクションログに記録されてからアーカイブおよびホットバックアップにアーカイブされるからです。トランザクションログがこのように大きくなった場合、システムに問題があると疑われ、何が起きたかを把握するために多くの時間が費やされてしまいます。

18.3.2 削除ログデータベースの自動破棄

削除ログデータベースのエントリを指定した間隔で Calendar Server に自動破棄させることができます。自動破棄はデフォルトで無効になっています。

ics.conf の次のパラメータにより自動破棄機能が制御されます。

表 18–1 削除ログデータベースの自動破棄に適用される構成パラメータ


パラメータ	説明
`service.admin.purge.deletelog`	削除ログデータベース (`ics50deletelog.db`) エントリの自動破棄を有効化 (`yes`) または無効化 (`no`) します。デフォルトは `"no"` です。
`caldb.berkeleydb.purge.deletelog.interval`	削除ログデータベース (`ics50deletelog.db`) のエントリを自動的に破棄する間隔を秒単位で指定します。デフォルトは `60` 秒です。
`caldb.berkeleydb.purge.deletelog.beforetime`	削除ログデータベース (`ics50deletelog.db`) から自動的に破棄するエントリの存続時間を秒単位で指定します。デフォルトは `518400` 秒 (6 日) です。

たとえば、5 分 (600 秒) おきに、2 日 (172800 秒) を経過した削除ログデータベースのエントリを Calendar Server に自動破棄させるには、「18.3.2 削除ログデータベースの自動破棄」のパラメータを次のように設定します。

service.admin.purge.deletelog="yes"
 caldb.berkeleydb.purge.deletelog.interval=600
 caldb.berkeleydb.purge.deletelog.beforetime=172800

パラメータの設定が完了したら、新しい値が適用されるように Calendar Server を再起動します。

18.3.3 削除ログデータベースの手動破棄

cspurge ユーティリティーを使用して、削除ログデータベース (ics50deletelog.db) のエントリを手動で破棄することもできます。

このユーティリティーの使用方法は次のとおりです。

cspurge -e endtime -s starttime

endtime と starttime の変数は、対象範囲の開始と終了を世界標準時形式 (GMT または UTC とも呼ばれる) で指定します。

cspurge を実行するには、Calendar Server を稼動しているユーザーとグループ (デフォルトでは icsuser と icsgroup )、またはスーパーユーザー (root) としてログインする必要があります。

たとえば、2003 年 7 月 1 日から 2003 年 7 月 31 日までのエントリを破棄するには、次のように実行します。

cspurge -e 20030731T235959Z -s 20030701T120000Z

詳細は、「D.13 cspurge」を参照してください。

18.4 削除ログデータベース用の Calendar Server ユーティリティーの使用

次の表は、削除ログデータベース (ics50deletelog.db) をサポートする Calendar Server ユーティリティーを示しています。

表 18–2 削除ログデータベースをサポートするユーティリティー


ユーティリティー	説明
`cspurge`	削除ログデータベースのエントリを手動で破棄します。
`csbackup` と `csrestore`	削除ログデータベースのバックアップと復元をサポートします。
`csstats`	削除ログデータベースの統計情報をレポートします。
`csdb`	削除ログデータベースのチェック、復元、再構築をサポートします。
`cscomponents`	削除ログデータベースのエントリの数をリスト表示します (読み取り専用情報)。

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

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

ここでは、Calendar Server ソフトウェアがどのようにタイムゾーンを定義し、処理するかについて説明します。

この章の内容は次のとおりです。

タイムゾーンのプロパティーとパラメータについては、次の Web サイトで『RFC 2445, Internet Calendaring and Scheduling Core Object Specification (iCalendar)』を参照してください。

http://www.ietf.org/rfc/rfc2445.txt

19.1 Calendar Server タイムゾーンの概要

ここでは、Calendar Server ソフトウェアによって実装されるタイムゾーンの概要を説明します。

timezones.ics ファイルには、Calendar Server がサポートするタイムゾーン表記が定義されています。このファイルは、次のディレクトリに格納されています。

/etc/opt/SUNWics5/config/

起動時に Calendar Server は timezones.ics ファイルを読み取ってタイムゾーンデータを生成し、そのデータをメモリーに格納します。このため、Calendar Server の稼動中はタイムゾーンデータはメモリー内に維持されます。したがって、新しいタイムゾーンを追加したり、既存のタイムゾーンを変更した場合は、変更が適用されるように Calendar Server を停止して再起動する必要があります。

timezones.ics ファイル内のタイムゾーンは TZID パラメータで識別されます。たとえば、Calendar Server は、例 19–1 に示すように、America/Los_Angeles TZID を使用して太平洋標準時 (PST/PDT) を識別します。TZNAME プロパティーはタイムゾーンの略式表記で、たとえば America/Los_Angeles であれば、PST (Pacific Standard Time、太平洋標準時) となります。

America/Los_Angeles のように夏時間 (DST) が適用されるタイムゾーンには、次の 2 つのサブコンポーネントが含まれます。標準時間用の STANDARD と夏時間用の DAYLIGHT。X-NSCP-TZCROSS リストには、そのタイムゾーンで夏時間 (DAYLIGHT) と標準時間 (STANDARD) が切り替わる日付が含まれます。

RRULE プロパティーは、STANDARD と DAYLIGHT の規則のパターンを定義します。TZOFFSETFROM プロパティーと TZOFFSETTO プロパティーは、夏時間と標準時間が切り替わる前後の GMT からの時間差を定義します。Communications Express のユーザーインタフェースでは、X-NSCP-TZCROSS に指定されている日付を使用して、タイムゾーンの変更をいつ表示するかが決定されます。

タイムゾーンの ID (tzid) パラメータを含む WCAP コマンドは、timezones.ics ファイルに定義されている有効なタイムゾーンを参照する必要があります。Calendar Server は、そのタイムゾーンを使用して日付を返します。WCAP コマンドに不明なタイムゾーンが指定されている場合、デフォルトでは Calendar Server は GMT タイムゾーンの日付を返します。WCAP については、『Sun Java System Calendar Server 6.3 WCAP Developer’s Guide 』を参照してください。

例 19–1 `timezones.ics` ファイル内の America/Los_Angeles タイムゾーンの表記

次の例は、timezones.ics ファイル内の America/Los_Angeles タイムゾーンの表記を示しています。

19.2 Calendar Server タイムゾーンの管理

この節では、タイムゾーンの管理に関する概念情報と手順について説明します。

ここでは、次の内容について説明します。

19.2.1 新しいタイムゾーンの追加

ここでは、Communications Express ユーザーインタフェースで使用できるように Calendar Server に新しいタイムゾーンを追加する方法について説明します。たとえば、America/Miami 用のタイムゾーンの追加が必要になるかもしれません。

新しいタイムゾーンを追加するもっとも簡単な方法は、次の手順で説明する各ファイルで、追加するタイムゾーンに似たタイムゾーンエントリをコピーし、それを編集する方法です。たとえば、America/Miami 用のタイムゾーンを追加するのであれば、各ファイルで America/New_York のタイムゾーンエントリをコピーして編集します。追加するタイムゾーンに夏時間 (DST) が適用される場合は、それに似たブロックを探します。

19.2.2 既存のタイムゾーンの変更

ここでは、既存のタイムゾーンを変更する方法について説明します。たとえば、「America/Phoenix」というタイムゾーン名から「US/Arizona」への変更が必要になる場合があります。

既存のタイムゾーンを変更するには

次のファイルで、変更するタイムゾーンのタイムゾーンブロックを変更します。

/etc/optSUNWics5/config/timezones.ics

タイムゾーン名を変更するときは、TZID エントリの名前を変更します。

次のファイルで getDisplayNameofTZID テンプレートを修正します。

cal-svr-base/SUNWics5/cal/html/ language/i18n.xsl

それぞれの意味は次のとおりです。language には、サイトで使用する言語のディレクトリを指定します。次に例を示します。英語であれば en、フランス語であれば fr を指定します。

タイムゾーン名を変更するときは、既存の名前を変更します。

タイムゾーンの変更に合わせて次の XML ファイルを変更します。

cal-svr-base /SUNWics5/cal/html/change_timezone.xml

cal-svr-base/SUNWics5/cal/html/new_cal.xml

cal-svr-base/SUNWics5/cal/html/new_group.xml

これらのファイルのエントリについては、「19.2.1 新しいタイムゾーンの追加」を参照してください。

変更がユーザー設定のデフォルトタイムゾーンに影響するときは、次のファイルの "icsTimeZone" エントリを修正します。

cal-svr-base/SUNWics5/cal/html/default_user_prefs.xml

注 –
手順 2、3、4 は、Calendar Express ユーザーインタフェースを使用している場合にのみ実行する必要があります。

タイムゾーンの変更が適用されるように、Calendar Server を停止し (稼動していた場合)、再起動します。

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

Calendar Server は、Sun Java System Instant Messaging 6.0 (以降) と統合され、カレンダの予定と作業に関するポップアップアラームを自動的に表示します。

この章では、ポップアップアラームの設定に関する概念情報と手順について説明します。

この章の内容は次のとおりです。

20.1 ポップアップアラームの概要

この節では、Calendar Server ソフトウェアのポップアップアラームの動作を理解するために必要な概念情報について説明します。

ここでは、次の内容について説明します。

20.1.1 カレンダのポップアップアラームの設定概念

ここでは、ポップアップアラームを動作させるために、何を設定するべきかを説明します。

ユーザーは、カレンダの今後公開される予定や作業の Instant Messenger ポップアップアラームを受信します。

これらのポップアップアラームを有効にするには、次の 2 つを行う必要があります。

管理者は、Calendar Server および Instant Messaging サーバーを設定して、ポップアップ通知を許可する必要があります。
エンドユーザーは、予定通知システムでアラームを設定する Communications Express の「オプション」タブで電子メールアラームを指定する必要があります。
エンドユーザーは、Instant Messenger でカレンダリマインダを有効にする必要があります。

ポップアップを有効にすると、差し迫った予定や作業が近づくと、予定通知システムで設定されたアラームにより Calendar Server は電子メール通知を送信し、Instant Messaging はポップアップアラームを表示します。

Calendar Server 管理者は、エンドユーザーの電子メール通知またはポップアラームのいずれか一方、または両方を設定できます。たとえば、電子メールアラームを無効にするときは、ics.conf ファイルのパラメータを次のように設定します。

caldb.serveralarms.binary.enable= "no"

20.1.2 ポップアップアラームの動作

ここでは、ポップアップアラームがどのように動作するかについて説明します。

Instant Messaging ポップアップアラームを有効に設定すると、次のアーキテクチャーフローで処理されます。

Instant Messaging JMS サブスクライバが Calendar Server の予定と通知を ENS (予定通知サービス) に登録します。
Calendar Server が text/xml 形式または text/calendar 形式で予定または通知を ENS に送信します。
Instant Messaging JMS サブスクライバがカレンダの予定または通知を受け取り、text/calendar 形式のメッセージを生成します。
エンドユーザーがオンライン状態であれば、Instant Messaging サーバーはカレンダの所有者にメッセージを送信します。
受信者がいれば、Instant Messenger は HTML ポップアップアラームを生成し、メッセージに基づいてエンドユーザーのデスクトップに表示します。

20.2 ポップアップアラームの設定

ここでは、Calendar Server ソフトウェアのポップアップアラームの設定方法について説明します。

この節では、次の設定方法について説明します。

Instant Messaging サーバーを設定するには

次の Instant Messaging のポップアップを設定するために必要な作業の概要は、便宜上紹介しています。Instant Messaging を設定するには、次の Web サイトで入手可能な Instant Messaging のマニュアルを参照してください。

http://docs.sun.com/coll/1309.2

新しいパッケージ SUNWiimagをインストールします。

Instant Messaging のポップアップを使用するには、Java Enterprise System インストーラを使用して Instant Messaging パッケージをインストールする必要があります。

Instant Messaging をインストールしたマシンで、次のディレクトリに移動します。

cd /etc/opt/SUNWiim/default/config

iim.conf ファイルの次の表に示すパラメータを 1 つ以上編集します。

次に示すパラメータ値により、予定と作業の両方のポップアップアラームの設定がわかります。iim.conf ファイルにこれらのパラメータが存在しない場合は、追加します。

パラメータ	説明および使用する適切な値
JMS Consumers セクション
`jms.consumers`	アラーム名。値を `cal_reminder` に設定します。
`jms.consumer.cal_reminder.destination`	アラームの出力先。値を enp:///ics/customalarm に設定します。
`jms.consumer.cal_reminder.provider`	プロバイダ名。`ens` に設定します。この値は、必ず JMS Providers セクションの `jms.providers` の名前と同じにしてください。
`jms.consumer.cal_reminder.type`	設定するアラームの種類。値を `topic` に設定します。
`jms.consumer.cal_reminder.param`	アラームパラメータ。値を `"eventtype=calendar.alarm" (引用符を含む)` に設定します。
`jms.consumer.cal_reminder.factory`	C++ ファクトリ名。値を次のように設定します。 com.iplanet.im.server. JMSCalendarMessageListener
JMS Providers セクション
`jms.providers`	プロバイダ名。値を `ens` に設定します。この値は、必ず JMS Consumers セクションの `jms.consumer.cal_reminder.provider` でリスト表示された名前と同じにしてください。
`jms.provider.ens.broker=cal.example.com`	ENS が待機するポート番号。`ics.conf` ファイルのパラメータ `service.ens.port` で指定したポートに設定します。デフォルトは 57997 です。
`jms.provider.ens.factory`	使用する C++ ファクトリ。`com.iplanet.ens.jms.EnsTopicConnFactory` に設定します。
Calendar Server の一般的なパラメータ
`iim_agent.enable`	Calendar エージェントを有効にします。引用符も含めて、値を次のように設定します。 `iim_agent.enable="true"`
`iim_agent.agent-calendar.enable`	Calendar エージェントを有効にするコンポーネントを読み込みます。引用符も含めて、値を次のように設定します。 `iim_agent.agent-calendar.enable="true"`
`agent-calendar.jid`	Calendar エージェントの JID。この値を次のように設定します。 `agent-calendar.jid=calimbot.server` `.domain`
`agent-calendar.password`	Calendar エージェントのパスワード。この値を次のように設定します。 `agent-calendar.password=password`
`iim_server.components`	この値を次のように設定します。 `iim_server.components=agent-calendar`

imadmin コマンド行ユーティリティーが格納されているディレクトリに移動します。

cd /opt/SUNWiim/sbin

imadmin を使用して Calendar エージェントを起動します。

imadmin start agent-calendar

Calendar エージェントは、Calendar Server ユーザーにポップアップ機能を提供する Instant Messaging コンポーネントです。Instant Messaging に用意されているツールを使用すると、Calendar エージェントの起動、停止、再起動、または状態の確認、さらにはログファイルによるアクティビティーの監視を行うことができます。

注 –
stop、start 、および refresh コマンドが含まれたスクリプトがある場合は、そこに Calendar エージェントを追加してください。

imadmin と Calendar エージェントについては、『 Sun Java System Instant Messaging 7 2005Q1 管理ガイド』を参照してください。

Calendar Server を設定するには

始める前に

次の表に示す ics.conf パラメータに、示された値が設定されているかどうかを確認します。設定されていない場合や、パラメータをカスタマイズする場合は、次の手順を実行します。

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

stop-cal コマンドを発行して Calendar Server サービスを停止します。

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

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

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

パラメータ	説明とデフォルト値
`caldb.serveralarms`	キューに入れるカレンダアラームを有効にします。デフォルトは `“yes”` (有効) です。
`caldb.serveralarms.contenttype`	アラーム内容の出力形式。デフォルトは `"text/xml"` です。
`caldb.serveralarms.dispatch`	送信するカレンダアラームを有効にします。デフォルトは `“yes”` です。
`caldb.serveralarms.dispatchtype`	送信するサーバーアラームの種類。デフォルトは `"ens"` です。
`caldb.serveralarms.url`	アラーム内容を取得するアラームの URL。デフォルトは `"enp:///ics/customalarm"` です。

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

Calendar Server を再起動します。

cal-svr-base/SUNWics5/cal/sbin/start-cal

Instant Messenger を設定するには

Calendar Server の予定と作業のポップアップアラームを受信するには、エンドユーザーは各自の Instant Messenger を次のように設定する必要があります。

メインウインドウで「ツール」メニューから「設定」を選択します。

「設定」ウィンドウで、「アラート」タブをクリックします。

「カレンダリマインダーを表示」オプションにチェックマークを付けます。

「了解」をクリックします。

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

ここでは、Calendar Server のパフォーマンスの調整に関する概念情報を提供し、その手順について説明します。

Calendar Server のパフォーマンスを向上させるには、次のオプション設定を検討します。

21.1 LDAP ディレクトリサーバーのインデックス設定

Calendar Server が LDAP ディレクトリサーバーにアクセスするときのパフォーマンスを向上するには、LDAP 設定ファイルの次の属性にインデックスを追加します。

icsCalendar: この属性は、カレンダユーザーまたはリソースのデフォルトカレンダの検索に使用されます。実在 (pres)、等価 (eq)、および部分文字列 (sub) のいずれかのインデックスタイプを指定します。
icsCalendarOwned: この属性は、ユーザーが所有しているほかのカレンダの検索に使用されます。実在 (pres)、等価 (eq)、および部分文字列 (sub) のいずれかのインデックスタイプを指定します。「21.2 DWP 環境でのカレンダ検索のパフォーマンス向上」も参照してください。
mail、mailAlternateAddress: これらの属性は、ユーザーの一次電子メールアドレスと代替電子メールアドレスを指定します。「14.1 カレンダユーザー LDAP エントリの作成」および「14.5.4.3 Calendar Server ユーティリティーを使用してカレンダサービスを追加するには」も参照してください。

ディレクトリサーバーインデックスの追加方法については、次の Web サイトにある Directory Server のマニュアルを参照してください。

http://docs.sun.com/coll/1316.1

21.2 DWP 環境でのカレンダ検索のパフォーマンス向上

DWP 環境にある場合、つまり、複数のバックエンドサーバーにカレンダベースが分散している場合、カレンダデータベース内のカレンダの検索に非常に時間がかかる場合があります。最初に LDAP エントリを探し、カレンダが存在している DWP ホストで直接検索すると、時間を短縮できます。

ここでは、次の内容について説明します。

LDAP を対象とするカレンダ検索を有効にするには

最初に LDAP ディレクトリ、次にカレンダデータベースを対象とするカレンダ検索を有効にするには、次の手順を実行します。

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

stop-cal コマンドを発行して Calendar Server サービスを停止します。

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

次のように、ics.conf ファイルの service.calendarsearch.ldap パラメータを、デフォルトである "yes" に設定します。

service.calendarsearch.ldap="yes"

次のようにカレンダサービスを再起動します。

start-cal

注 –
公開カレンダへの匿名アクセスを許可している場合は、LDAP を対象とするカレンダ検索を無効にすることもできます。実際に、Communications Express では、パラメータ値を “no” に設定することをお勧めします。

インデックスを作成して検索のパフォーマンスを向上させるには

インデックスを作成することにより、カレンダ検索のパフォーマンスを向上させることができるかどうかを調べるには、次の LDAP コマンドを実行します。
ldapsearch -b "base" "(&(icscalendarowned=*user*) (objectclass=icsCalendarUser))"
ここで、base は、Calendar Server のユーザーとリソースのデータが格納されているディレクトリサーバーの LDAP ベース DN であり、user は、エンドユーザーが検索ダイアログで入力できる値です。

60,000 のエントリを使ったテストでは、icsCalendarOwned のインデックスを設定しない場合、前述した検索に要した時間は 50 〜 55 秒でした。インデックスの設定後に検索に要した時間は、約 1 〜 2 秒でした。

comm_dssetup.pl を実行して、適切な LDAP 属性に、または少なくとも icsCalendarOwned にインデックスを設定します。

comm_dssetup.pl は、この属性やその他の多くの属性にインデックスを設定して、さまざまな方法でパフォーマンスを向上させます。comm_dssetup.pl を実行していない場合、または実行したがインデックス設定を行わなかった場合、ユーティリティーを再実行してインデックス設定を行うか、または Directory Server ツールを使用してインデックスを設定できます。

comm_dssetup.pl がどのようにインデックスを作成するかについては、『Sun Java System Communications Suite 5 Installation and Configuration Guide』の「Attribute Indexes」を参照してください。

ディレクトリサーバーインデックスの追加方法については、次の Web サイトにある Directory Server のマニュアルを参照してください。

http://docs.sun.com/coll/1316.1

21.3 ワイルドカード検索の無効化によるカレンダ検索のパフォーマンスの向上

デフォルトでは、Calendar Server でのワイルドカード検索は無効になっています。つまり、グラフィカルユーザーインタフェース (GUI) を使用してカレンダを検索するとき、または、カスタムインタフェースで search_calprops.wcap を実行するときは、WCAP コマンドを使用して渡される検索文字列との完全一致を検索します。

ics.conf ファイルで次の行のコメントを外して (行頭の感嘆符 ("!") を削除して) ワイルドカード検索を有効にしている場合は、パフォーマンスにマイナスの影響を与える可能性があります。

!service.calendarsearch.ldap.primaryownersearchfilter = "(&(|(uid=*%s*)(cn=*%s*))(objectclass=icsCalendarUser))"

パフォーマンスに与えるワイルドカードの影響を調べるには、行の先頭に感嘆符 ("!") を挿入して行をもう一度コメントアウトします。

21.4 CLD プラグインのパフォーマンスの向上

カレンダデータベースからカレンダにアクセスする前に、ユーザーのカレンダをどのバックエンドマシンに格納するかを決める必要があります。適切なバックエンドマシンを見つけるために、システムではユーザーエントリの LDAP ディレクトリを検索し、icsDWPHost 属性を取り出します。この検索は非常に時間がかかり、カレンダデータにアクセスするたびに実行する必要があります。すべてのユーザーセッションでは、データベースのアクセスが多数発生し、LDAP の検索も多くなります。時間を節約してパフォーマンスを向上させるには、次のように ics.conf ファイルを編集して CLD キャッシュを有効にします。

caldb.cld.cache.enable="yes"

LDAP データキャッシュは、ユーザー ID およびそれに関連する icsDWPHost 属性を格納します。LDAP でユーザーのエントリを検索する前に、システムは、キャッシュにそのユーザーの ID がないかどうかチェックします。キャッシュにユーザー ID があれば、そこに格納されている icsDWPHost 属性からバックエンドのホスト名を取り出します。キャッシュにユーザー ID がない場合、システムは LDAP 検索を実行して、ユーザー ID と属性を CLD キャッシュにコピーします。このあとは、キャッシュでユーザー ID が見つかるため、ユーザーのカレンダデータへのアクセスが速くなります。

21.5 LDAP データキャッシュのパフォーマンスの向上

LDAP データキャッシュが有効になっている場合は、ics.conf パラメータを使用してキャッシュを調整できます。それには、次の表に示すパラメータを 1 つ以上調整します。

注 –

デフォルトでは、LDAP データキャッシュが有効になっています。LDAP データキャッシュを無効にするには、次のように設定します。local.ldap.cache.enable="no"

表 21–1 LDAP データキャッシュのカスタマイズに使用される ics.conf パラメータ


パラメータ	説明と値
`local.ldap.cache` `.checkpointinterval`	チェックポイント間でチェックポイントスレッドがスリープするまでの秒数。デフォルトは `“60”` です。高アクティビティーの LDAP では、キャッシュをできるだけ最新のものにしておくため、間隔を短くすることをお勧めします。同時に、キャッシュの更新が頻繁になるほど、システムのオーバーヘッドが高くなることにも留意してください。
`local.ldap.cache.` `circularlogging`	処理が完了したあとに LDAP データキャッシュのデータベースログファイルを削除するかどうかを指定します。デフォルトは `“yes”` です。古いログファイルを削除するカスタムのクリーンアップルーチンがある場合を除いて、このパラメータは変更しないでください。
`local.ldap.cache.` `logfilesizemb`	チェックポイントファイルの最大サイズを M バイト単位で指定します。デフォルトは `"10”`M バイトです。高アクティビティーの LDAP の場合、チェックポイント間隔が終わる前にこのファイルがいっぱいになる可能性があります。経験に基づいて、できるだけログの実サイズに近い値を設定します。
`local.ldap.cache.` `maxthreads`	LDAP データキャッシュデータベースの最大スレッド数を指定します。デフォルトは `“1000”` です。高アクティビティーの LDAP では、スレッド数を増やすことをお勧めします。そうすることにより CPU の使用率が高くなります。LDAP アクティビティーが最小の場合にのみ、スレッド数を減らします。
`local.ldap.cache.` `mempoolsizemb`	共有メモリーのサイズを M バイト単位で指定します。デフォルトは `“4”`M バイトです。
`local.ldap.cache.` `entryttl`	LDAP データキャッシュエントリの存続時間 (TTL) を秒単位で指定します。デフォルトは `“3600”` 秒 (1 時間) です。キャッシュがあまりにも早くいっぱいになる場合は (高アクティビティー)、TTL 時間を減らします。ただし、これにより全体の LDAP データベースのアクセス数が増加し、全体的にシステムを低下させる可能性があります。
`local.ldap.cache.` `cleanup.interval`	キャッシュデータベースのクリーンアップの間隔を秒単位で指定します。デフォルトは `“1800”` 秒 (30 分) です。システムにより有効期限が切れたエントリが削除されます。時間間隔は、エントリの TTL 時間と同一である必要はありません。ただし、同期させるとより効率的になります。
`local.ldap.cache.` `stat.enable`	LDAP データキャッシュへのアクセスをログに記録し、ログファイルに統計情報を出力するかどうかを指定します。デフォルトは `“no”` です。パフォーマンス向上のために、このパラメータはデバッグモードでのみ使用してください。
`local.ldap.cache.` `stat.interval`	統計情報レポートをログファイルに書き込む間隔を秒単位で指定します。デフォルトは `“1800”` 秒 (30 分) です。これは、`local.ldap.cache.stat.enable` が有効になっている場合にのみアクティブになります。間隔を短くすると、問題を特定するのに役立ちます。間隔を長くすると、システムロードが減少します。

注 –

Communications Express では、データキャッシュを無効にすることをお勧めします。

21.6 LDAP SDK キャッシュの調整

項目をキャッシュしておく時間、およびキャッシュのサイズを制御するいくつかのパラメータがあります。

キャッシュを調整するには、次の表に示すパラメータを 1 つ以上編集します。

表 21–2 LDAP SDK キャッシュを設定するための ics.conf パラメータ


パラメータ	説明とデフォルト値
`service.ldapmemcachettl`	このパラメータは現在実装されていません。`ldap_cache` ディレクトリの内容を手動で削除してから、Calendar Server を再起動する必要があります。 `service.ldapmemcache` に `"yes"` を指定した場合、このパラメータは項目をキャッシュしておける最大秒数の設定に使用されます。`“0”` を指定した場合、項目をキャッシュしておける時間に制限が適用されなくなります。デフォルトは `“30”` です。
`service.ldapmemcachesize`	`service.ldapmemcache` に `"yes"` を指定した場合、このパラメータを使用して、キャッシュに使用できるメモリーの最大容量をバイト単位で設定します。`“0”` を指定した場合、キャッシュ容量の制限は適用されなくなります。デフォルトは `“131072”` です。

21.7 自動バックアップの調整

ディスクに保存するバックアップ数と必要性とのバランスを取って、使用可能なディスク容量を越えないようにする必要があります。アーカイブとホットバックアップに必要なディスク容量を管理するために、さまざまな ics.conf パラメータの設定を変更できます。これらのパラメータにより、一度に保存するバックアップのコピー数、および古いコピーのクリーンアップを行うディスク容量のしきい値が決定されます。

アーカイブ、およびホットバックアップのそれぞれバックアップタイプ用に調整できる次の 3 種類のパラメータがあります。

mindays: ディスク上に保持する最小日数分のバックアップ。
maxdays: ディスク上に保持する最大日数分のバックアップ。
threshold: 使用されるディスク容量の割合 (パーセント)。これはトリガーポイントとして使用されます。

Calendar Server では、ディスク容量のしきい値を超えずに可能な最大日数の間、バックアップを保持します。そのため、現在のバックアップでディスク使用率がしきい値を超える場合、システムは古いバックアップコピーを破棄し、ディスク容量の使用率がしきい値より低くなるかどうかを確認します。システムは、別のバックアップコピーを削除することにより、ディスク上のバックアップ数が最小バックアップコピー数を下回るか、ディスク容量の使用率がしきい値を下回るまで、古いバックアップコピーを破棄し続けます。

その結果、しきい値のパラメータによりディスク容量のバックアップ使用を管理できます。また反対に、許容されるディスク容量やコピーを調整することにより、ディスクで保持するバックアップ量を管理できます。

次の表は、ディスク容量とディスクに保持されるバックアップ数を制御する ics.conf パラメータを一覧表示しています。

表 21–3 ディスク上に保持するバックアップ数の設定に使用される ics.conf パラメータ


`ics.conf` パラメータ	デフォルト設定	説明
`caldb.berkeleydb.hotbackup.mindays`	3	ディスク上に保持するホットバックアップの最小日数です。
`caldb.berkeleydb.hotbackup.maxdays`	6	ディスク上に保持するホットバックアップの最大日数です。
`caldb.berkeleydb.hotbackup.threshold`	70	ホットバックアップに使用されるディスク容量の割合 (パーセント) です。しきい値を超えた古いコピーの廃棄をトリガーします。
`caldb.berkeleydb.archive.mindays`	3	ディスク上に保持するアーカイブバックアップの最小日数です。
`caldb.berkeleydb.archive.maxdays`	6	ディスク上に保持するアーカイブバックアップの最大日数です。
`caldb.berkeleydb.archive.threshold`	70	アーカイブバックアップに使用されるディスク容量の割合 (パーセント) です。しきい値を超えた古いコピーの廃棄をトリガーします。

21.8 複数 CPU 間でのロードバランスの使用

デフォルトでは、Calendar Server ではロードバランスが有効になっています。Calendar Server achieves は、次のアルゴリズムを使用してロードバランスをアーカイブしています。プロセスは、n 本ごとに 1 本の接続を許可しています。ここで n とは、プロセスの数です。

ロードバランスを無効にするには、ics.conf ファイルに service.http.loadbalancing パラメータを追加し、その値を "no" に指定します。次に、Calendar Server を再起動して変更を適用します。

21.9 それぞれのサービスに対して実行されるプロセス数の制御

サーバーに複数の CPU が実装されている場合、デフォルトでは、Calendar Server は HTTP サービス (cshttpd プロセス) と分散データベースサービス (csdwpd プロセス) を複数の CPU に分散します。

それぞれのサービスに対して実行されるプロセスの数を制御するには、service.http.numprocesses および service.dwp.numprocesses パラメータを編集します。デフォルトでは、これらのパラメータはインストール時にサーバーの CPU 数に設定されますが、この値を設定し直すことができます。たとえば、サーバーに 8 つの CPU がある場合に、cshttpd および csdwpd プロセスを 4 つの CPU だけで実行するときは、これらのパラメータを次のように設定します。

service.http.numprocesses="4"
 service.dwp.numprocesses="4"

21.10 タイムアウト値の使用

ここでは、さまざまな ics.conf パラメータのタイムアウト値を使用して Calendar Server のパフォーマンスを調整するうえでの概念情報を提供し、その手順について説明します。

次のタイプのタイムアウトが存在します。

ics.conf パラメータの編集については、「E.1 ics.conf 設定ファイルの編集」を参照してください。

21.10.1 `csadmind` のタイムアウト値

次の表は、管理サービス (csadmin) が使用する、ics.conf ファイル内の Calendar Server タイムアウトパラメータを示しています。

表 21–4 管理サービス (csadmin) の HTTP タイムアウト値


パラメータ	説明
`service.admin.idletimeout`	`csadmind` サービスがアイドル状態の HTTP 接続をタイムアウトにするまでの秒数を指定します。デフォルトは 120 秒 (2 分) です。
`service.admin.resourcetimeout`	`csadmind` サービスがリソースカレンダの HTTP セッションをタイムアウトにするまでの秒数を指定します。デフォルトは 900 秒 (15 分) です。
`service.admin.sessiontimeout`	`csadmind` サービスが HTTP セッションをタイムアウトにするまでの秒数を指定します。デフォルトは 1800 秒 (30 分) です。

21.10.2 エンドユーザーの HTTP タイムアウト値

次の表は、エンドユーザーに適用される、ics.conf ファイル内の Calendar Server HTTP タイムアウトパラメータを示しています。

表 21–5 ics.conf に設定され、エンドユーザーに適用される HTTP タイムアウト値 (cshttpd サービス)


パラメータ	説明
`service.http.idletimeout`	`cshttpd` サービスがアイドル状態の HTTP 接続をタイムアウトにするまでの秒数を指定します。デフォルトは `"120"` 秒 (2 分) です。
`service.http.resourcetimeout`	`cshttpd` サービスがリソースカレンダの HTTP セッションをタイムアウトにするまでの秒数を指定します。デフォルトは `"900"` 秒 (15 分) です。
`service.http.sessiontimeout`	`cshttpd` サービスが HTTP セッションをタイムアウトにするまでの秒数を指定します。デフォルトは `"1800"` 秒 (30 分) です。

21.10.3 GSE キューのタイムアウト値

ics.conf ファイルの次のパラメータは、要求されたジョブを Calendar Server が GSE (グループスケジューリングエンジン) キューで走査するまでの時間を秒単位で指定します。

gse.belowthresholdtimeout="3"

キューに含まれるジョブが許容最大しきい値より多い場合、最後のスレッドが常にキューをもう一度走査します。このため、この設定はジョブの数が最大しきい値より少ない場合にだけ適用されます。

デフォルトは "3" です。この値を大きくすると、サーバーがキューを走査する回数が減り、全体的なパフォーマンスを向上できます。ただし、予定のボリュームが増大したためにキューが大きくなりすぎた場合、キューの処理速度を上げるための時間が短くなる可能性があります。これによって全体のパフォーマンスは低下しますが、予定はすぐに更新されます。

第 22 章 Calendar Server 6.3 ソフトウェアのトラブルシューティング

ここでは、ログの設定方法と、一般的な問題への対処方法について説明します。

この章の内容は、次のとおりです。

22.1 Calendar Server 6.3 ソフトウェアのデバッグ情報の有効化

ここでは、Calendar Server 配備でログおよびデバッグを使用して問題解決するうえでの概念情報を提供し、その手順について説明します。

システム全体を「デバッグモード」にする ics.conf パラメータはありませんが、ここでは有用なデバッグ情報を取得する方法について説明します。

注 –

パフォーマンスにマイナスの影響を与えるため、必要でない場合は、必ず、過度なログ記録および監視は無効にしてください。

22.1.1 ログレベルを上げる

次の表に示すパラメータを使用して、ログの詳細度を上げます。

パラメータ	説明とデフォルト値
`logfile.loglevel`	`DEBUG` に設定して、`CRITICAL`、`ALERT`、`ERROR`、`WARNING`、`NOTICE`、および `INFORMATION` を含む、すべてのレベルがログ記録されるようにします。この設定はすべてのログに適用されます。

22.1.2 LDAP キャッシュへのアクセスログの有効化

LDAP データキャッシュのすべてのアクセスをログに記録し、そのログ (レポート) を出力するには、次の表に示すics.conf パラメータを設定します。

パラメータ	説明とデフォルト値
`local.ldap.cache.stat.enable`	LDAP データキャッシュへのアクセスをログに記録し、ログファイルに統計情報を出力するかどうかを指定します。デフォルトは `“no”` です (統計情報はログ記録されない)。統計情報のログを有効にするには、`“yes”` に設定します。パフォーマンス向上のために、このパラメータはデバッグモードでのみ使用してください。
`local.ldap.cache.stat.interval`	統計情報レポートをログファイルに書き込む間隔を秒単位で指定します。デフォルトは `“1800”` 秒 (30 分) です。これは、ログが有効になっている場合にのみアクティブになります。間隔を短くすると、問題を特定するのに役立ちます。間隔を長くすると、システムロードが減少します。

パラメータ

説明とデフォルト値

local.ldap.cache.stat.enable

LDAP データキャッシュへのアクセスをログに記録し、ログファイルに統計情報を出力するかどうかを指定します。デフォルトは “no” です (統計情報はログ記録されない)。統計情報のログを有効にするには、“yes” に設定します。

パフォーマンス向上のために、このパラメータはデバッグモードでのみ使用してください。

local.ldap.cache.stat.interval

統計情報レポートをログファイルに書き込む間隔を秒単位で指定します。デフォルトは “1800” 秒 (30 分) です。

これは、ログが有効になっている場合にのみアクティブになります。間隔を短くすると、問題を特定するのに役立ちます。間隔を長くすると、システムロードが減少します。

22.1.3 LDAP キャッシュのクリア

現在、Calendar Server には LDAP キャッシュデータを失効させるためのロジックは存在しません。ldap_cache ディレクトリの内容を手動で削除し、Calendar Server を再起動する必要があります。

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

Calendar Server を停止します。

/var/opt/SUNWics5/csdb/ldap_cache ディレクトリ内のファイルをすべて削除します。ただし、ldap_cache ディレクトリ自体は削除しないでください。

Calendar Server を再起動します。

22.1.4 WCAP コマンドと HTTP アクセスログ

デバッグを簡便化する 2 つの構成パラメータにより、受信コマンドおよび HTTP アクセスのロギングが可能になります。ics.conf ファイルに、いずれかのパラメータ、または両方のパラメータを追加し、ロギングを有効にします。

service.http.commandlog = "yes" — cshttpd プロセスは、http.commands ファイルをログディレクトリに作成します。このログには、サーバーが受信するそれぞれの .shtml または .wcap コマンドが、すべてのパラメータとともに格納されています。
service.http.commandlog.all = "yes" — cshttpd プロセスは、http.access ファイルをログディレクトリに作成します。ログには、システムによって受信される各 HTTP 要求が格納されています。

注意 –

ログファイルの容量はすぐに大きくなり、空きディスク領域が少なくなることがあります。問題を回避するため、ログファイルを注意深く監視する必要があります。これらのコマンドが有効になった状態で実行するには、システムの稼動レベルが低いときを選びます。ピーク時に実行すると、パフォーマンスが大幅に劣化します。トラブルシューティングが終了したら、これらのコマンドを必ず無効化してください。

22.1.5 Calendar Server 6.3 の csstats ユーティリティーを使用したシステム監視

counter.conf ファイルに定義されているカウンタオブジェクトからの統計情報を表示するには、csstats list コマンドを使用します。

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

22.2 LDAP の問題のトラブルシューティング

ここでは、LDAP の問題をトラブルシューティングするうえでの概念情報を提供します。

複数ドメイン環境を最初に作成する時に、ドメイン、コンテナ、ユーザー、グループ、リソースの適切なエントリを追加して、LDAP に DC ツリーを作成する必要があります。cscal などの Calendar Server のユーティリティーを使用するときに DC ツリーが存在しないと、次のようなエラーメッセージが表示される可能性があります。"Initialization failed .... exiting"

DC ツリーには、DC ツリーのルートに少なくとも 1 つの (デフォルト) ドメインが含まれていることを確認します。「13.2 新規の Calendar Server ドメインの作成」に記載されている方法を使用して DC ツリー構造を作成します。

22.3 移行ユーティリティーのトラブルシューティング

Calendar Server には、カレンダデータベースおよび LDAP ディレクトリを移行するためのいくつかのユーティリティーが用意されています。

ここでは、次の内容について説明します。

22.3.1 テクニカルサポートに問い合わせる前に必要なこと

一般的に、移行ユーティリティーの使用において問題が発生した場合は、テクニカルサポートに問い合わせてください。

問い合わせる前に、次の情報を集めます。

問題のデータベースのバックアップコピー。
すべての関連ログのコピー。
コアを含むすべてのエラー出力メッセージ。

22.3.2 移行ユーティリティーの入手先

さまざまな移行ユーティリティーおよびそのマニュアルは、次の一覧に示す場所にあります。

スキーマ移行ユーティリティー (commdirmig)

このユーティリティーは、個別にインストール可能なコンポーネントである Delegated Administrator にバンドルされています。このユーティリティーは LDAP ディレクトリを Schema バージョン 1 から Schema バージョン 2 に移行します。このユーティリティーについては、『Sun Java Communications Suite 5 Schema Migration Guide 』を参照してください。

Calendar Server 6.2 から 6.3 への移行ユーティリティー csmigrate

このユーティリティーは、ソフトウェアのインストール後に sbin ディレクトリに格納されます。

Calendar Server 5 から Calendar Server 6.2 への移行ユーティリティー (cs5migrate)

このユーティリティーは、ソフトウェアのインストール後に sbin ディレクトリに格納されます。

Calendar Server の複数ドメインデータベースの準備ユーティリティー (csmig)

このユーティリティーは、ソフトウェアのインストール後に sbin ディレクトリに格納されます。

このユーティリティーのマニュアルは第 3 章「Calendar Server 6.3 のデータベース移行ユーティリティー」にあります。これには、トラブルシューティングの節もあります。

Calendar Server の非ドメインから複数ドメインへの移行ユーティリティー (csvdmig)

このユーティリティーは、ソフトウェアのインストール後に sbin ディレクトリに格納されます。

このユーティリティーのマニュアルは、第 3 章「Calendar Server 6.3 のデータベース移行ユーティリティー」にあります。複数ドメイン用のカレンダデータベースおよび LDAP ディレクトリのエントリを準備するには、このユーティリティーを使用します。

注 –

csvdmig の前に csmig を実行してください。

Calendar Server 2 から Calendar Server 6 への移行ユーティリティー (ics2migrate)

このユーティリティーは Calendar Server にインストールされています。マニュアルは、第 3 章「Calendar Server 6.3 のデータベース移行ユーティリティー」にあります。Calendar Server 2 データベースを移行して Calendar Server 5 との互換性を持たせるには、このユーティリティーを使用します。

Netscape Calendar Server 4 から Calendar Server 5 への移行ユーティリティー (ncs4migrate)

このユーティリティーは、テクニカルサポートサイトからのみ入手できます。ユーティリティーパッケージにはマニュアルが含まれています。このユーティリティーは、Netscape Calendar Server 4 を Calendar Server 5 に移行します。移行元のデータベースが整合していないため、これらの移行には特に注意を要します。手動による多くの作業が必要になることも珍しくありません。このユーティリティーは、テクニカルサポートサイトからのみ入手できます。ユーティリティーパッケージにはマニュアルが含まれています。このユーティリティーは、Netscape Calendar Server 4 を Calendar Server 5 に移行します。これらの移行には特に注意を要します。ユーティリティーを実行できるようになるまでに、移行元のファイルに対して多くの作業が必要になることも珍しくありません。移行の計画をサポートする Professional Services を利用されることをお勧めします。

22.4 Calendar Server でのデータベース以外のトラブルシューティング

ここでは、データベース以外の問題のさまざまなトラブルシューティングについて説明します。

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

ヒント –

さらに、次の SSL の章にも、SSL に関するトラブルシューティングの節があります。

「7.2 Calendar Server 6.3 ソフトウェアの SSL のトラブルシューティング」

22.4.1 1 つの cshttpd プロセスが多数の接続を許可しており、CPU 時間を 100% 使用している

1 つの cshttpd プロセスが多数の接続を許可しており、CPU 時間を 100% 使用している場合は、負荷分散が無効になっていることがあります。負荷分散をふたたび有効にするには、ics.conf パラメータ service.http.loadbalancing の値を "yes" に変更します。

start-cal の問題の解決

start-cal を実行したときに起動しないカレンダサービスがある場合は、再起動する前に起動したサービスを終了する必要があります。たとえば、enpd、csnotifyd、および csadmind が起動したが、cshttpd は起動していない場合、enpd、csnotifyd、および csadmind を停止する必要があります。

カレンダサービスを起動するには、次のように実行します。

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

stop-cal コマンドを実行します。

stop-cal コマンドがすべての Calendar Server サービスを停止できなかった場合は、子プロセスのいくつかが実行中であることがあります。この場合の処理については、「22.4.2 stop-cal の問題の解決」を参照してください。

すべての Calendar Server プロセスが確実に終了したあと、start-cal コマンドを実行してすべてのサービスを起動します。次に例を示します。

cal-svr-base/SUNWics5/cal/sbin/start-cal

22.4.2 stop-cal の問題の解決

ここでは、stop-cal の問題を解決するうえでの概念情報を提供し、その手順について説明します。

Calendar Server のシャットダウン時には、考慮する必要がある 2 つの別個の問題があります。

子プロセスを停止するには

stop-cal を実行したあと、いくつかの子プロセスが停止していない場合があります。たとえば、stop-cal によって cshttpd 親プロセスは停止しているのに、一部の cshttpd 子プロセスが停止していないことがあります。このような場合は、次の手順で、残りの Calendar Server プロセスを個別に停止させる必要があります。

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

サービスごとに ps コマンドを実行し、残っている Calendar Server プロセスのプロセス ID (PID) を特定します。

ps -elf | grep cs-process

ここで、cs-process は enpd、csnotifyd 、csdwpd、csadmind、または cshttpd です。次に例を示します。

ps -elf | grep cshttpd

kill -15 コマンドに終了していない各プロセスの PID を指定して、プロセスを終了します。次に例を示します。kill -15 9875

それぞれの ps コマンドをもう一度実行し、すべての Calendar Server プロセスが終了していることを確認します。
Calendar Server プロセスがまだ稼動しているときは、kill -9 コマンドを実行して終了します。例: kill -9 9875
注 –
Linux システムで Calendar Server を実行していて、ps コマンドを使用してカレンダプロセスを検索すると、結果がわかりにくく見えることがあります。Linux では、ps コマンドは、プロセスのリストではなく実行しているスレッドのリストを返します。プロセスだけが表示されるようにするための既知の解決策はありません。

不正シャットダウンしたあとで回復するには

Calendar Server が正しくシャットダウンしなかった場合は、次の手順を実行します。

前の手順 (「22.4.2 stop-cal の問題の解決」) を実行します。

LDAP データキャッシュデータベースのディレクトリ内のすべてのファイルを手動で削除します。

ファイルが残っていると、データベースが破損する可能性があります。ファイルを削除するには、次のように実行します。
1. LDAP データキャッシュのディレクトリに移動します。
  
  デフォルトでは、/opt/SUNWics5/csdb/ldap_cache ですが、ics.conf ファイルの local.ldap.cache.homedir.path パラメータにより指定されるディレクトリを使用してください。
2. ディレクトリ内のすべてのファイルを削除します。
  
  次に例を示します。rm *.*
3. すべてのファイルが削除されたことを確認します。
  
  次に例を示します。ls

Calendar Server を再起動します。

cal-svr-base/SUNWics5/cal/sbin/start-cal

LDAP データキャッシュの設定方法については、「4.8 Calendar Server バージョン 6.3 の LDAP の設定」を参照してください。LDAP データキャッシュについては、『Sun Java Communications Suite 5 配備計画ガイド』を参照してください。

22.4.3 バックエンドサーバーに接続できない

応答しているかどうか調べるには、バックエンドサーバーに対して ping を実行します。

応答していない場合は、その原因を調べ、ふたたび動作するようになったら次の手順に進みます。
CLD キャッシュをクリアします。「12.5 Calendar Server バージョン 6.3 での CLD キャッシュのクリア」を参照してください。

CLD キャッシュオプションを使用していて、ics.conf パラメータのサーバー名を更新した場合は、CLD キャッシュをクリアしてサーバー名を消去するとよいでしょう。CLD キャッシュに古いエントリが残されていると、フロントエンドサーバーが正しいバックエンドサーバーに接続できなくなったり、Calendar Server が移動後のカレンダを見つけられなくなります。
stop-cal コマンドでサーバーを停止します。
start-cal を使用して Calendar Server を再起動します。

22.4.4 カレンダが見つからない

CLD キャッシュオプションを使用していて、1 つ以上のカレンダを別のバックエンドサーバーに移動した (または、バックエンドサーバーの名前を変更した) 場合は、新規サーバーのカレンダが表示されないことがあります。

その場合は、次の手順を実行します。

CLD キャッシュをクリアします。「12.5 Calendar Server バージョン 6.3 での CLD キャッシュのクリア」を参照してください。

1 つ以上のカレンダを別のバックエンドサーバーに移動すると、CLD キャッシュは無効になります。再読み込みするには、キャッシュをクリアする必要があります。そうすると、キャッシュが再構築されます。
これが失敗した場合は、正しい手順でカレンダを移動したかどうかを確認します。詳細は、

「15.6 ユーザーカレンダの管理」を参照してください。

その後、キャッシュをクリアします。

22.4.5 バックエンドマシンにカレンダを作成できない

指定したバックエンドマシンでカレンダを作成しようとすると、次のエラーメッセージが表示されます。Invalid DWP Host Server。この場合、原因は 2 つあります。サーバーが適切に設定されていないか、カレンダの所有者がすでに別のバックエンドサーバーに割り当てられています。

この節では、これら 2 つの問題の解決方法を説明します。

22.4.5.1 バックエンドマシンが適切に設定されていない

問題となっているバックエンドサーバーの ics.confファイルで、

次の設定があることを確認します。

service.dwp.enable = "yes"
caldb.cld.type = "directory"
local.hostname = "back-end hostname"

22.4.5.2 カレンダ所有者が別のバックエンドマシンに割り当てられている

ユーザーの LDAP エントリで、icsDWPHost 属性があることを確認します。icsDWPHost の値は、カレンダを作成しようとしているバックエンドサーバー名と一致する必要があります。このユーザーのカレンダを別のバックエンドサーバー上に作成することはできません。

22.4.6 プロキシ認証を使用してログインしようとすると「承認されていない」が表示される

この節では、失敗の原因として考えられるものについて説明します。示される手順を実行し、ログインを再試行します。

この問題を解決するには、次のいずれかの手順を実行します。
- service.http.allowadminproxy が “yes” に設定されていることを確認します。
- admin-user に Calendar Server 管理者の権限があることを確認します。
- admin-password が正しいことを確認します。
- calendar-user が有効な Calendar Server ユーザーであることを確認します。
ログインを再試行します。

22.4.7 正しく完了しない検索のトラブルシューティング

この節では、正しく完了しない検索のトラブルシューティングについての概念情報を提供し、その手順について説明します。

LDAP ディレクトリサーバー設定の nsslapd-sizelimit 属性と nsLookthroughLimit 属性は、検索が正しく終了するように十分なサイズに設定する必要があります。 nsSizeLimit が十分なサイズでない場合は、一部の結果が欠落したり、検索結果が表示されなくなることがあります。nsLookthroughLimit が十分なサイズでない場合、検索が完了しないことがあります。

この節の内容は、次のとおりです。

制限属性の値が適切かどうかを調べるには

これらの属性に適切な値が設定されているかどうかを調べるには、次のコマンドを実行します。

ldapsearch -b "base" "(&(icscalendarowned=*user*)(objectclass=icsCalendarUser))"

ここで、base は、Calendar Server のユーザーとリソースのデータが格納されているディレクトリサーバーの LDAP ベース DN であり、user は、エンドユーザーがユーザーインタフェースの検索ダイアログで入力できる値です。

LDAP サーバーがエラーを返す場合、nsSizeLimit または nsLookthroughLimit パラメータの値が十分でない可能性があります。

制限属性を適切な値に設定するには

これらの属性の DN は次のとおりです。

dn: cn=config,cn=ldbm databases,cn=plug ins,cn=config

nsLookthroughLimit の値を動的に設定するには、ldapmodify を使用します。

この属性を変更するために Directory Server を終了して再起動する必要はありません。

デフォルト値は 5000 です。検索結果が表示されない場合、この値を大きくすることができます。ただし、そうすると LDAP サーバーのパフォーマンスが低下します。

制限を -1 に設定して、制限の適用を解除することもできます。ただし、システムがハングすることが想定されるため、慎重に行なってください。

nsslapd-sizelimit をより高い値に設定する場合は、次の手順を実行する必要があります。
1. ディレクトリサーバーを停止します。
2. dse.ldif ファイルを編集します。
3. ディレクトリサーバーを再起動します。
  
  注 –
  ldapmodify の使用方法および dse.ldif ファイルの編集方法については、次の Web サイトで入手できる Directory Server のマニュアルを参照してください。
  
  http://docs.sun.com/coll/1316.1

22.5 Calendar Server のデータベースの問題への対処

この節では、Calendar Server (Berkeley データベース) データベースに伴うさまざまな問題について解説します。

ここでは、次の内容について説明します。

22.5.1 Berkeley データベースのツールの検索

多くのトラブルシューティングの手順では、Berkeley データベースのユーティリティープログラムへのアクセス権が必要です。これらのユーティリティープログラムは、Calendar Server バンドルで入手できますが、これらのプログラムはサポートされていません。詳細は、直接 Sleepycat Software (http://www.oracle.com/database/berkeley-db/index.html) から入手できます。

ここでは、次の内容について説明します。

22.5.1.1 Berkeley データベースユーティリティにアクセスするには

LD_LIBRARY_PATH 環境変数を設定してエクスポートし、次のディレクトリに反映させます。

cal-svr-base/SUNWics5/cal/tools/unsupported/bin/

22.5.1.2 使用可能なツールの一覧

次の表は、よく使用される Berkeley データベースのツール (ユーティリティープログラム) の一覧を示しています。

Berkeley データベースのツール	説明
`db_archive`	使用されなくなったログファイルのパス名を、標準出力に 1 行に 1 つずつ書き込みます。
`db_checkpoint`	データベースログを監視し、定期的にチェックポイントルーチンを呼び出して、チェックポイントを指定するデーモンプロセスです。
`db_deadlock`	データベース環境のロック領域をトラバースして、デッドロックまたはタイムアウトになっているロック要求を検出するたびに、ロック要求を中止します。
`db_dump`	指定したファイルを、`db_load` ユーティリティーが理解するフラットテキスト形式で標準出力に書き込みます。
`db_load`	標準出力から読み込み、指定したデータベースファイルにロードします。ファイルが存在しない場合は、ファイルを作成します。
`db_printlog`	人間が読める形式でログファイルをダンプするデバッグユーティリティーです。
`db_recover`	予期しないアプリケーション、データベース、またはシステムの障害が発生した後、データベースを整合性のある状態に復元します。
`db_stat`	データベース環境の統計情報を表示します。
`db_verify`	1 つ以上のファイルおよびファイル内に含まれるデータベースの構造を検証します。

データベースデッドロックの検出と解決

Berkeley データベースがデッドロック状態にある場合は、データベースをリセットする必要があります。できるだけ早期にこの状態を検出することが重要です。

システムが定期的にデータベースをチェックして、デッドロック状態を検出し、管理者に通知するようにするには、次のように実行します。

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

stop-cal コマンドを発行して Calendar Server サービスを停止します。

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

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

必要に応じて、ics.conf ファイルを編集して次の値を設定します。

local.caldb.deadlock.autodetect=”yes”

注 –
このパラメータが “yes” に設定されている場合は、ロック領域を監視する db_deadlock デーモンが起動されます。

22.5.2 データベースの破損の検出

カレンダデータベースは、システムリソースの競合、ハードウェアの障害、アプリケーションエラー、データベース障害、人為的な原因など、さまざまな原因で破損することがあります。ここでは、カレンダデータベースの破損を検出する方法について説明します。

22.5.2.1 データベース破損の基本的考え方

データベースが破損しないと誰にも保証はできません。ですが、データの損失と運用停止時間を最小限にとどめることができます。破損を早期に検出するには、厳密にデータベースおよびカレンダサービスを監視することが重要です。頻繁に完全なバックアップを行なっておくことが、破損が検出された場合に復元する秘訣です。

カレンダデータベースで起こりうる破損には、2 つのレベルがあります。

アプリケーションレベル: 1 つ以上のデータベースファイルのエントリに問題があると、それらを基にしている場合、サーバーが稼動しなくなります。
データベースレベル: Berkeley データベースのページが破損すると、さまざまな問題が発生します。一般的な症状は、csdb check を実行するとループすることです。もう一つの一般的な症状は、次のようなエラーメッセージが表示されることです。
```
“illegal page type or format”, 
or “page 97895 doesn’t exist, create flag not set.”
```

22.5.2.2 ログファイルの監視

データベース破損の兆候を示すエラーメッセージについて、アラームログを含む Calendar Server ログファイルを監視します。

ALERT 、CRITICAL、ERROR、および WARNING レベルのエラーについて、ログファイルを定期的に調べてください。これらのエラーが見つかったときは、Calendar Server の動作で考えられる問題について調査します。NOTICE および INFORMATION レベルのログ予定は、Calendar Server の通常動作中に生成されることがあります。これは、サーバーアクティビティーの監視に役立つように提供されています。

データベースディレクトリ内のトランザクションログファイルを削除しないでください。トランザクションログファイルにはトランザクションの更新 (追加、変更、削除) が記録されており、これを削除すると復元できない状態にまでカレンダデータベースが破損してしまうことがあります。

注 –

Calendar Server に関するテクニカルサポートを依頼する場合、問題解決のためにログファイルの提出が必要となることがあります。

カレンダデータベースの破損をチェックするには

カレンダプロパティー (calprops)、予定、および仕事 (作業) を含め、カレンダデータベースを走査して破損がないかどうか調べるには、check コマンドを使用します。check コマンドにより回復不能な不整合が検出された場合、その状況がレポートとして出力されます。

check コマンドは、アラームまたは GSE (グループスケジューリングエンジン) データベースの破損をチェックしません。

Calendar Server がインストールされているシステムの管理権限を持つユーザーとしてログインします。

Calendar Server は稼動中でも停止していてもかまいませんが、可能であれば停止してください。

カレンダデータベースのコピーをまだ作成していない場合は、コピーを作成します。

データベース (.db) ファイルだけをコピーします。共有ファイル (__db.*) やログファイル (log.*) をコピーする必要はありません。

cal-svr-base/SUNWics5/cal/sbin ディレクトリに移動します。

たとえば、Solaris オペレーティングシステムでは、デフォルトのディレクトリには次のように入力します。

cd /opt/SUNWics5/cal/sbin

カレンダデータベースのコピーに対して check コマンドを実行します。

./csdb check dbdir /tmp/check.out

dbdir を指定しない場合、現在のディレクトリに格納されているデータベースに対して check が実行されます。

check コマンドは大量の情報を生成する可能性があるので、この例で示すように stdout や stderr を含むすべての出力をファイルとして書き出すことをお勧めします。

check の実行が完了したら、出力ファイルを確認します。データベースが破損していた場合は、rebuild コマンドを実行します。

「22.5.6 破損したカレンダデータベースの再構築」を参照してください。

22.5.3 急激に巨大化し、数が増えたトランザクションログファイルへの対処

自動消去設定が、エンドユーザーが求めるクライアントユーザーインタフェースに適切に対応していない可能性があります。大容量のトランザクションログファイルが突然多数現れる原因は、Delete ログレコードの消去に非常に長い時間がかかっているだけの場合があります。この遅延が、Connector for Microsoft Outlook または Sync Tool のユーザーに対応するために意図的に設けられている場合は、多数の大容量のトランザクションログの出現は予期されているものです。これ以降の処置は必要ありません。システムは最終的には遅延を解消します。ただし、エンドユーザーが Communications Express クライアントを使用している場合、自動消去設定をデフォルトに戻すことで問題が解決します。

22.5.4 データベース破損時のサービス停止の防止 (読み取り専用モード)

ここでは、リカバリモードの間も破損したデータベースにアクセスできる方法について説明します。ここで説明する内容は次のとおりです。

22.5.4.1 読み取り専用モードの使用

データベースの破損が見つかった場合、サービスの停止を防ぐ 1 つの方法は、データベースを読み取り専用モードにすることです。このモードでは、エンドユーザーはデータベースのエントリを読むことはできますが、追加、変更、または削除はできません。エンドユーザーがカレンダデータを追加、変更、または削除しようとすると、システムによりエラーメッセージが表示されます。また、カレンダの予定および仕事を追加、変更、または削除する管理者ツールも、データベースが読み取り専用モードの間は機能しません。

注 –

データベースを読み取ることができないほど破損している場合は、バックアップを復元するまでの間、サービスを停止する必要があります。バックアップを復元する最短の方法は、有効なホットバックアップを取ることです。「22.5.8.1 復元する前に」を参照してください。

データベースを読み取り専用モードにするには

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

stop-cal コマンドを発行して Calendar Server サービスを停止します。

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

cd /etc/opt/SUNWics5/config

次のようにパラメータを設定し、カレンダに対して読み取り専用モードを指定します。

caldb.berkeleydb.readonly=”yes”

start-cal コマンドを使用して Calendar Server を再起動します。

cal-svr-base/SUNWics5/cal/sbin/start-cal

ics.conf の変更を有効にするには、サービスを再起動する必要があります。

22.5.5 一般的なデータベース障害の処理

ここでは、いくつかの一般的なデータベース障害と、推奨する対応策について説明します。ここで説明する内容は次のとおりです。

`csadmind` が起動しない、または起動時にクラッシュする

csadmind では GSE (グループスケジューリングエンジン) とアラームディスパッチエンジンの両方のサービスを処理するため、GSE キュー内、またはアラームキュー内のエントリに問題があると、これらの問題が発生する可能性があります。

対応策

csadmindが実行されていない場合は、stop-cal コマンドを即座に実行します。

カレンダサービスを稼動したままにしておくと、トランザクションログが累積し、それが原因でデータベースがさらに破損して、トランザクションログファイルとデータベースを照合するのに時間がかかる場合があります。

すべての Calendar Server プロセスが終了していることを確認します。

すべてのプロセスが終了していることを確認する方法については、「子プロセスを停止するには」を参照してください。

start-cal -csadmind コマンドを実行し、csadmind を再起動してみます。

正常に起動すると、次の手順を実行して 2 つのキューが機能していることを確認します。
1. csschedule を使用して、GSE キューをチェックします。
2. dbrig を使用して、アラームキューをチェックします。
  
  csschedule および dbrig の実行方法については、付録 D 「Calendar Server のコマンド行ユーティリティーのリファレンス」を参照してください。

csadmind がダンプでクラッシュした場合は、pstack を分析します。

トレースに GSE に関連した機能がある場合は (中に GSE の文字がある)、GSE キューの最初のエントリおよび予定データベースの参照エントリを調べます。ほとんどの場合、GSE エントリで参照されている予定が、問題を起こしているエントリです。この問題を解決するには次を実行します。
1. csschedule を使用して、GSE エントリを削除します。
2. cscomponents を使用して、問題を起こしている予定をデータベースから削除します。
  
  csschedule および cscomponents の実行方法については、付録 D 「Calendar Server のコマンド行ユーティリティーのリファレンス」を参照してください。

エントリが破損していない場合は、カレンダサーバーでは処理できない特殊な例の可能性があります。

次の手順を実行します。
1. 破損したデータベースのカレンダ環境のスナップショットを取り、カスタマサポートに問い合わせます。
  
  環境のバックアップを作成するには、次のように実行します。
  1. 次の場所にある db_checkpoint ユーティリティーを使用します。
    
    cal-svr-base/SUNWics5/cal/tools/unsupported/bin/db_checkpoint
  2. db_archive -s を実行します。
    
    -s オプションを使用して、すべてのデータベースファイルを識別し、それらを CD、DVD、テープなどのリムーバブルメディアにコピーします。
  3. db_archive -l を実行します。
    
    -l オプションを使用して、すべてのログファイルを識別し、使用されていないファイルをリムーバブルメディアデバイスにコピーします。
2. サービスの停止を避けるには、カレンダデータベースを一時的に読み取り専用の状態にして、ホットバックアップのコピーに戻ります。
  - カレンダデータベースを一時的に読み取り専用の状態にすると、トランザクションの追加、変更、または削除はできなくなります。エンドユーザーがカレンダデータを追加、変更、または削除しようとすると、エラーメッセージが表示されます。カレンダの予定および仕事を追加、変更、または削除する管理者ツールも、データベースが読み取り専用モードの間は機能しません。
    
    カレンダデータベースを読み取り専用モードにするには、ics.conf ファイルを編集して、次のパラメータを “yes” に設定します。
    
    caldb.berkeleydb.readonly=”yes”
  - 「22.5.8 自動バックアップコピーの復元」にある手順を使用して、ホットバックアップコピーに戻ります。
    
    csstored を設定して有効にすると、ホットバックアップが使用可能になり、数分以内に最新のものになります。また、常にホットバックアップコピーを検証して、破損していないことを確認するとよいでしょう。その場合は、db_verify を実行します。

他の方法がすべて失敗した場合、ダンプと再ロードの手順を実行して、データベースを修復できるかどうか確認します。

この手順は、「22.5.7 ダンプとロードによるカレンダデータベースの復元」で説明しています。

サービスがハングし、エンドユーザーが接続できない: 親のないロック

この状態は、制御スレッドが原因で発生する場合があります。これは Berkeley DB データベースのページをロックし、ロックを解除しないで終了します。問題を確認するには、cshttpd プロセスおよび csadmind 上で、pstack を実行します。pstack は標準 UNIX ユーティリティーで、次の場所に格納されています。/usr/bin/pstack。このユーティリティーにより、ロックを獲得するために待機しているスレッドが表示されます。

問題を解決するには、次のようにして Calendar Server を再起動します。

start-cal が存在するディレクトリに移動します。

cd cal-svr-base/SUNWics5/cal/sbin

start-cal コマンドを実行します。

./start-cal

`csdb` rebuild が終了しない: データベースのループ

データベースのループは、通常、データベースファイルの破損により起こります。データベースが破損しているため、回復不能になる可能性があります。次のいくつかの選択肢があります。

ホットバックアップに戻ります。

破損が最近起こったのであれば、いずれかのホットバックアップコピーを使用できます。

壊滅的アーカイブのリカバリプロセスを使用します。

推奨されるプロセスについては、「22.5.8 自動バックアップコピーの復元」を参照してください。

ダンプと再ロードの手順を使用します。「22.5.7 ダンプとロードによるカレンダデータベースの復元」を参照してください。

22.5.6 破損したカレンダデータベースの再構築

ここでは、csdb rebuild コマンドの使用方法について説明します。ここで説明する内容は次のとおりです。

22.5.6.1 `rebuild` の概要

rebuild コマンドはカレンダデータベースを走査し、カレンダプロパティー (calprops) の予定と仕事 (作業) をチェックして破損がないかどうかを調べます。不整合が検出されると、rebuild コマンドは再構築したカレンダデータベース (.db ファイル) を cal-svr-base/SUNWics5/cal/sbin/rebuild_db ディレクトリに生成します。

--g オプションを指定せずに rebuild コマンドを実行すると、GSE (グループスケジューリングエンジン) データベース以外のすべてのデータベースが再構築されます。GSE データベースも再構築するときは、-g オプションを指定します。

GSE データベースにエントリが含まれているかどうかを調べるには、csschedule -v list コマンドを実行します。GSE がすべてのエントリの処理を完了してから rebuild コマンドを実行してください。

カレンダデータベースを再構築するには

Calendar Server がインストールされているシステムの管理権限を持つユーザーとしてログインします。

Calendar Server を停止します。

カレンダデータベースのコピーを作成し、/tmp/db ディレクトリに置きます。

データベース (.db) ファイルとログ (log.*) ファイルをコピーします。共有ファイル (__db.*) をコピーする必要はありません。

cal-svr-base/SUNWics5/cal/sbin ディレクトリに移動します。

たとえば、Solaris オペレーティングシステムでは、デフォルトのディレクトリには次のように入力します。

cd /opt/SUNWics5/cal/sbin

注 –
sbin ディレクトリのディスク容量が問題となる場合は、別のディレクトリで rebuild コマンドを実行します。

カレンダデータベースのコピーに対して rebuild コマンドを実行します。

./csdb rebuild /tmp/db /tmp/

データベースパスを指定しない場合は、現在のディレクトリに対して rebuild が実行されます。/tmp/ パラメータは、再構築したデータベースの出力先ディレクトリを指定します。

GSE データベースも再構築するときは、-g オプションを指定します。

rebuild は大量の情報を生成する可能性があるので、stdout や stderr を含むすべての出力をファイルとして書き出すことをお勧めします。

注 –
カレンダデータベースを再構築するときは、常に最新のバックアップコピーを使用してください。

ただし、膨大なデータが失われ、データベースの定期バックアップで複数のコピーを利用できるときは、最新のコピーから最も古いコピーの順に再構築を行います。この方法の唯一の欠点は、すでに削除されているカレンダコンポーネントが再構築されたデータベースに再表示されることです。

たとえば、3 つのバックアップカレンダデータベースファイルが db_0601、db_0615、および db_0629 というディレクトリに格納されている場合は、次の順序で rebuild コマンドを実行します。
./csdb rebuild db_0629 ./csdb rebuild db_0615 ./csdb rebuild db_0601
次に、rebuild コマンドは再構築したデータベースを cal-svr-base/SUNWics5/cal/sbin/rebuild_db ディレクトリに書き込みます。

rebuild の実行が完了したら、rebuild.out ファイルを確認します。

再構築が正常に完了した場合、rebuild.out ファイルの最後の行は次のようになります。
Calendar database has been rebuilt

前の手順で再構築の成功を確認したときは、再構築したデータベースファイル (.db) を rebuild_db ディレクトリから運用データベースにコピーします。

破損したデータベースのディレクトリに共有ファイル (__db.*) やログファイル (log.*) が含まれていた場合は、それも運用ディレクトリに移動します。

Calendar Server を再起動します。

22.5.6.2 再構築出力のサンプル

次の例は、コマンドと、そのコマンドにより生成された出力を示しています

# ./csdb -g rebuild
Building calprops based on component information.
Please be patient, this may take a while...
Scanning events database...
512 events scanned
Scanning todos database...
34 todos scanned
Scanning events database...
512 events scanned
Scanning todos database...
34 todos scanned
Scanning deletelog database...
15 deletelog entries scanned
Scanning gse database...
21 gse entries scanned
Scanning recurring database...
12 recurring entries scanned
Successful components db scan
Calendar database has been rebuilt
Building components based on calprops information.
Please be patient, this may take a while...
Scanning calprops database to uncover events...
25 calendars scanned
Scanning calprops database to uncover todos...
25 calendars scanned
Successful calprops db scan
Calendar database has been rebuilt

注 –

上記の出力サンプルでは、予定と仕事のデータベースがそれぞれ 2 回走査されたことを示しています。これはエラーではありません。最初の走査ではカレンダプロパティーデータベース内の情報を確認し、次に再走査して、カレンダプロパティーデータベースがアクセス可能であることを確認します。

22.5.7 ダンプとロードによるカレンダデータベースの復元

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

22.5.7.1 ダンプとロードの概要

ダンプとロードの手順を使用して破損したデータベースの復元を試みます。ダンプとロードの手順では、Berkeley データベースの db_dump ユーティリティーと db_load ユーティリティーを使用します。Calendar Server では、これらのユーティリティーは次のディレクトリに格納されています。

cal-svr-base /SUNWics5/cal/tools/unsupported/bin

db_dump ユーティリティーはデータベースファイルを読み取り、エントリを db_load ユーティリティーと互換性のある形式で出力ファイルに書き込みます。

db_dump ユーティリティーと db_load ユーティリティーのマニュアルについては、次の Sleepycat Software の Web サイトを参照してください。

http://www.sleepycat.com/docs/utility/index.html

db_dump と db_load によるデータベースの復元が成功するかどうかは、データベースの破損具合によって決まります。データベースを復元するまでに、db_dump オプションを何度か実行しなければならないこともあります。ただし、破損が著しいデータベースは復元できません。この場合は、データベースの最終ホットバックアップまたはアーカイブを使用する必要があります。

注 –

ダンプとロードの手順を実行するときは、カレンダデータベースが Berkeley DB バージョン 3.2.9 以上である必要があります。それ以前のバージョンを使用している場合は、最初に cs5migrate ユーティリティーを使用してカレンダデータベースをアップグレードしてください。

最新バージョンの cs5migrate については、ご購入先のテクニカルサポートに問い合わせてください。

ダンプとロードの手順を実行するには

Calendar Server を実行するユーザーやグループ (icsuser と icsgroup など)、またはスーパーユーザー (root) としてログインします。

Calendar Server が停止していなければ、停止します。

csbackup ユーティリティーや Sun StorEdge Enterprise Backup^TM ソフトウェア、Legato Networker® などを使用して、破損しているデータベースのバックアップを作成します。

詳細は、第 17 章「Calendar Server データのバックアップと復元」を参照してください。

db_dump ユーティリティーを使用して、破損しているデータベースの各ファイルをダンプします。

データベースファイルは、ics50calprops.db 、ics50journals.db、ics50alarms.db 、ics50events.db、ics50todos.db 、および ics50gse.db です。

データベースが復元されるまで (または復元不可能であると判断されるまで)、次のオプションを順に指定して db_dump を実行します。
- オプションなし: 軽度のデータベース破損。
- -R オプション: 中度のデータベース破損。
- -R オプション: 重度のデータベース破損。-R オプションを指定した場合、破損しているデータベースから、部分的なレコードや削除されたレコードなども含め、-r オプションを指定した場合より多くのデータがダンプされます。
  
  たとえば、-r オプションを指定して db_dump を実行するときは、次のように入力します。
  
  db_dump -r ics50events.db \> ics50events.db.txt

db_load ユーティリティーを使用して、出力ファイルを新しいデータベースファイルにロードします。

次に例を示します。

db_load new.ics50events.db < ics50events.db.txt

db_load が奇数のキーまたはデータエントリをレポートする場合は db_dump 出力ファイルを編集して、異常のあるキーまたはデータエントリを削除します。次に、db_load を再実行します。

破損しているその他のデータベースファイルに対して、前の 2 つの手順を繰り返します。

つまり、破損しているその他のデータベースファイルに対して db_dump を実行します。

「22.5.6 破損したカレンダデータベースの再構築」で説明している csdb rebuild コマンドを使用して、復元したデータベースファイルを再構築します。

rebuild の実行が完了したら、出力ファイルを確認します。再構築が正常に完了した場合、rebuild.out ファイルの最後の行は次のようになります。
Calendar database has been rebuilt
csdb rebuild コマンドが正常に終了しなかった場合は、次レベルの db_dump オプション (-r または -R) を使用してデータベースのダンプを行います。

db_dump -R オプションを実行しても破損しているデータベースを復元できない場合は、ご購入先のテクニカルサポートまたは販売代理店までご連絡ください。それまでの間は、データベースの最終バックアップを使用する必要があります。

22.5.8 自動バックアップコピーの復元

第 9 章「自動バックアップ (csstored) の設定」で説明されている自動バックアップ機能を使用している場合、ライブデータベースが破損したときにバックアップコピーを復元できます。

ここでは、2 つの異なる自動バックアップの復元方法について説明します。

22.5.8.1 復元する前に

バックアップを復元する前に、必ず次の操作を行なっていることを確認してください。

どのトランザクションがライブデータベースの破損の原因になったか診断を試みていること。
新規のアーカイブが破損されないように、破損しているトランザクションを削除または修正していること。
破損したデータベースを、別のディレクトリまたはリムーバブルメディアにコピーして保存していること。このコピーは、テクニカルサポートに問い合わせを行う際に必要になります。

ホットバックアップを復元するには

ライブデータベースが破損した場合は、ホットバックアップがバックアップの最初の選択肢となります。バックアップを復元するには、次の手順を実行します。

破損したライブデータベースのディレクトリで、適用されていない、または書き込み可能な状態のログファイルを識別します。

書き込み可能なログを閉じます。このログには、最新のトランザクションが含まれています。

新規の (復元) ディレクトリを作成します。

現在のホットバックアップのコピーを、新規の復元データベースのディレクトリにコピーします。

log.* ファイルを、破損したライブデータベースのディレィトリから、新規の復元データベースのディレクトリにコピーします。

データベースのアーカイブコピーを保持している場合は、ライブデータベースに適用されなかったログをアーカイブディレクトリにコピーします。

新規の復元データベースに対して指定された -c -h オプションを指定して、db_recover を実行します。

たとえば、新規の復元ディレクトリの名前が recoverydb の場合、コマンドは次のようになります。

db_recover -c -h recoverydb

log.* ファイルは、新規の復元ディレクトリに残しておきます。

db_recover プログラムではログファイルを新規の復元データベースに適用しましたが、バージョン 4.2 以降、Berkeley DB ではログファイルをそのまま残しておくことを勧めします。

新規の復元ディレクトリ内のデータベースファイルに対して、db_verify を実行します。db_verify を実行するには、次の手順を実行します。

次のコマンドを実行し、Calendar Server を停止します。

cd /opt/SUNWics5/cal/sbin

./stop-cal

このコマンドを使用し、Calendar Server データベース (csdb) のコピーをもう 1 つ作成します。

cp -Rp /var/opt/SUNWics5/csdb /var/opt/SUNWics5/csdb.db_verify

csdb のコピーに対して db_verify を実行します。

注 –

db_verify を、元の csdb に対して実行しないでください。

LD_LIBRARY_PATH=/opt/SUNWics5/cal/lib
export LD_LIBRARY_PATH
cd /opt/SUNWics5/cal/tools/unsupported/bin
./db_verify -h /var/opt/SUNWics5/csdb.db_verify ics50alarms.db
./db_verify -h /var/opt/SUNWics5/csdb.db_verify ics50calprops.db
./db_verify -h /var/opt/SUNWics5/csdb.db_verify ics50events.db
./db_verify -h /var/opt/SUNWics5/csdb.db_verify ics50gse.db
./db_verify -h /var/opt/SUNWics5/csdb.db_verify ics50journals.db
./db_verify -h /var/opt/SUNWics5/csdb.db_verify ics50recurring.db
./db_verify -h /var/opt/SUNWics5/csdb.db_verify ics50todos.db
./db_verify -o -h /var/opt/SUNWics5/csdb.db_verify ics50deletelog.db

注 –

ics50deletelog.db に対し、-o オプションを指定して db_verify を実行します。

db_verify が正常に実行されると、エラーメッセージは表示されません。データベースファイルが破損していると、エラーメッセージがスローされます。次に例を示します。

./db_verify -h /var/opt/SUNWics5/csdb.db_verify ics50todos.db
db_verify:Page 612: last item on page sorted greater than parent entry
db_verify: Page 612: incorrect next_pgno 885 found in leaf chain (should be 501)
db_verify: Page 0: page 501 encountered a second time on free list
db_verify: DB->verify: ics50todos.db: DB_VERIFY_BAD: Database verification failed

新規の復元ディレクトリに対して、csdb -v list を実行します。

新規の復元ディレクトリで上記の 3 つの手順を実行したら、古い破損したライブデータベースを新規の復元ディレクトリと置き換えます。

新しいスナップショットとして機能させるために、新規のライブデータベースをホットバックアップのディレクトリにコピーします。

次の定期的なスナップショットが取得されるまで、すべての新しいログがこのコピーに適用されます。

Calendar Server を起動します。

新規の復元ディレクトリでいずれかの手順に失敗した場合は、次のようにして破損していない古いホットバックアップを特定します。
1. ホットバックアップを新しい順から逆にたどり、各ファイルに対して順番に db_verify および csdb -v list を実行して、破損していない最新のコピーを見つけます。
2. パスする最初のホットバックアップコピーが、ライブデータベースのディレクトリに復元されます。
  
  「ホットバックアップを復元するには」で説明している手順に従い、破損したライブデータベースを新規のホットバックアップと置き換えます。最初に、必ず「22.5.8.1 復元する前に」をお読みください。
3. ホットバックアップがどれも動作せず、アーカイブバックアップがない場合は、テクニカルサポートに問い合わせてください。アーカイブバックアップがある場合は、「アーカイブバックアップを復元するには」にある手順を実行します。「22.5.8.1 復元する前に」も参照してください。

アーカイブバックアップを復元するには

破損したホットバックアップはないが、アーカイブバックアップとトランザクションログがある場合は、次の手順を実行して、アーカイブしたデータベースの最新の破損していないデータベースを復元できます。

破損したライブデータベースのディレクトリで、適用されていない、または書き込み可能な状態のログファイルを識別します。

書き込み可能なログを閉じます。このログには、最新のトランザクションが含まれています。

新規の (復元) ディレクトリを作成します。

最新のアーカイブコピーとそのログファイルを、新規の復元データベースのディレクトリにコピーします。

適用されていない log.* ファイルを、破損したライブデータベースのディレクトリから、新規の復元データベースのディレクトリにコピーします。

新規の復元データベースに対して指定された -c -h オプションを指定してdb_recover を実行します。

たとえば、新規の復元ディレクトリの名前が recoverydb の場合、コマンドは次のようになります。

db_recover -c -h recoverydb

log.* ファイルは、新規の復元ディレクトリに残しておきます。

db_recover プログラムではログファイルを新規の復元データベースに適用しましたが、バージョン 4.2 以降、Berkeley DB ではログファイルをそのまま残しておくことを勧めします。

新規の復元ディレクトリ内のデータベースファイルに対して、db_verify を実行します。

「ホットバックアップを復元するには」では、db_verify の実行手順について説明しています。

新規の復元ディレクトリに対して、csdb -v list を実行します。

新規の復元ディレクトリで上記の 3 つの手順を実行したら、古い破損したライブデータベースを新規の復元ディレクトリと置き換えます。

新しいスナップショットとして機能させるために、新規のライブデータベースをホットバックアップのディレクトリにコピーします。

Calendar Server を起動します。

新規の復元ディレクトリがいずれかの手順に失敗した場合は、次のようにして破損していない古いアーカイブバックアップを特定します。
1. アーカイブバックアップのコピーを新しい順から逆に調べて、順に各ファイルに対して次の 3 つのリカバリプログラムを実行して、破損していない最新のコピーを見つけます。db_recover -c-h、db_verify、および csdb -v list。
2. パスする最初のアーカイブアップコピーが、ライブデータベースのディレクトリに復元されます。
  
  「アーカイブバックアップを復元するには」で説明している手順に従い、破損したライブデータベースを新規のアーカイブバックアップと置き換えます。
3. アーカイブバックアップがどれも動作しない場合は、テクニカルサポートに問い合わせてください。

22.5.9 カスタムのバックアップスクリプトの修復

ここでは、次の内容について説明します。

22.5.9.1 現在、動的ライブラリでコンパイルされている Berkeley ツール

カスタムバックアップスクリプトが Berkeley データベースのツール (db_recover など) を使用して作成されている場合は、Calendar Server にアップグレードすると、機能しなくなる可能性があります。これは、Calendar Server の以前のバージョンでは、ツールを静的ライブラリでコンパイルしていたためです。現在では、ツールは動的ライブラリの libdb-4.2.so でコンパイルされています。

22.5.9.2 カスタムのバックアップスクリプトを修復するには

既存のカスタムスクリプトで新しい動的ライブラリを使用するには、次に示す大域変数を設定します。

LD_LIBRARY_PATH=libdb-4.2.so

パート IV Calendar Server 6.3 の管理

第 12 章 Calendar Server 6.3 配備のサーバー管理

12.1 Calendar Server 6.3 プロセスの起動と停止

12.1.1 Calendar Server 6.3 コマンドについて: start-cal と stop-cal

start-cal を使用して Calendar Server 6.3 サービスを起動するには

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

12.2 Calendar Server バージョン 6.3 での自動バックアップの有効化または無効化

Calendar Server バージョン 6.3 でホットバックアップを有効にするには

Calendar Server バージョン 6.3 でアーカイブバックアップを有効にするには

Calendar Server バージョン 6.3 でホットバックアップを無効にするには

Calendar Server バージョン 6.3 でアーカイブバックアップを無効にするには

12.3 Calendar Server バージョン 6.3 のグループスケジューリングエンジンキューの管理

12.3.1 Calendar Server バージョン 6.3 の GSE について

12.3.2 Calendar Server 6.3 GSE キューについて

12.3.3 Calendar Server 6.3 GSE キュー内のエントリのリスト表示

12.3.4 Calendar Server バージョン 6.3 での GSE キュー内のエントリの削除

12.4 Calendar Server 6.3 プロセスの監視

12.5 Calendar Server バージョン 6.3 での CLD キャッシュのクリア

12.5.1 Calendar Server 6.3 CLD キャッシュをクリアする理由

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

12.6 サーバー名の変更

12.7 Calendar Server ユーザーの匿名アクセスの設定

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

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

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

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

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

12.9 Calendar Server 設定の再読み込み

第 13 章 Calendar Server ドメインの管理

13.1 適切なユーザー管理ツールの選択

13.2 新規の Calendar Server ドメインの作成

13.2.1 Calendar Server ドメインの作成の概要

13.2.2 Schema バージョン 2 モードにドメインを追加するには

13.2.3 Schema バージョン 1 モードにドメインを追加するには

13.3 ドメイン間の検索の有効化

13.3.1 このドメインの検索を許可するドメインの名前を追加する

13.3.1.1 特定のドメインにこのドメインの検索を許可するには

13.3.1.2 すべての外部ドメインにこのドメインの検索を許可するには

13.3.2 このドメインによって検索されるドメインの名前を追加する

第 14 章 ユーザー、グループ、およびリソースの管理

14.1 カレンダユーザー LDAP エントリの作成

14.1.1 Schema バージョン 2 モードで新規カレンダユーザーを作成するには

14.1.2 Schema バージョン 1 モードで新規カレンダユーザーを作成するには

14.2 カレンダグループ LDAP エントリの作成

14.2.1 Schema バージョン 2 モードで新規カレンダグループを作成するには

14.2.2 Schema バージョン 1 モードで新規カレンダグループを作成するには

14.3 カレンダリソース LDAP エントリの作成

14.3.1 Schema バージョン 2 モードで新規カレンダリソースを作成するには

14.3.2 Schema バージョン 1 モードで新規カレンダリソースを作成するには

14.4 ユーザー、グループ、およびリソース LDAP エントリへの mail 属性の追加

14.4.1 Calendar Server の LDAP エントリへのメールサービス追加に関する概要

14.4.2 LDAP エントリに mail 属性が設定されているか否かを確認するには

14.4.3 Calendar Server バージョン 6.3 の既存のユーザー、グループ、およびリソース LDAP エントリに対して mail 属性を追加するには

14.5 既存のユーザーの管理

14.5.1 カレンダユーザー情報の表示

14.5.1.1 カレンダ対応のすべてのユーザーを表示するには

14.5.1.2 特定のユーザーのカレンダ属性を表示するには

14.5.2 カレンダユーザーの無効化

14.5.2.1 Delegated Administrator コンソールを使用してユーザーを無効化するには

14.5.2.2 Delegated Administrator ユーティリティー (commadmin user delete) を使用してユーザーを無効化する には

14.5.2.3 Calendar Server ユーティリティー (csuser disable) でユーザーを無効化するには

14.5.2.4 Calendar Server ユーティリティーでユーザーからカレンダサービスを削除するには

14.5.3 カレンダユーザーの有効化

14.5.3.1 Delegated Administrator コンソールを使用してユーザーを有効にするには

14.5.3.2 Delegated Administrator ユーティリティーを使用してユーザーを有効にするには

14.5.3.3 Calendar Server ユーティリティーでユーザーを再度有効にするには

14.5.4 ユーザーへのカレンダサービスの追加

14.5.4.1 Delegated Administrator コンソールを使用してユーザーにカレンダサービスを追加するには

14.5.4.2 Delegated Administrator (commadmin user create) を使用してユーザーにカレンダサービスを追加するには

14.5.4.3 Calendar Server ユーティリティーを使用してカレンダサービスを追加するには

14.5.5 ユーザー LDAP エントリからのカレンダサービスの削除

14.5.6 カレンダユーザーの電子メールのエイリアスの設定

Delegated Administrator コンソールを使用して電子メールのエイリアスを設定するには

参照

14.5.6.1 Delegated Administrator ユーティリティーを使用して電子メールのエイリアスを設定するには

14.5.6.2 Calendar Server ユーティリティーの csattribute を使用して電子メールのエイリアスを設定するには

14.5.7 ユーザーがカレンダサービスを有していることの検証

14.5.7.1 Delegated Administrator コンソールを使用し、ユーザーが カレンダサービスを有しているかどうかを確認するには

14.5.7.2 Delegated Administrator ユーティリティーを使用し、ユーザーが カレンダサービスを有しているかどうかを確認するには

14.5.7.3 Calendar Server ユーティリティー csuser を使用し、ユーザーがカレンダサービスを有するかどうかを確認するには

第 14 章ユーザー、グループ、およびリソースの管理

14.5.2.2 Delegated Administrator ユーティリティー (`commadmin user delete`) を使用してユーザーを無効化するには

14.5.2.3 Calendar Server ユーティリティー (`csuser disable`) でユーザーを無効化するには

14.5.4.2 Delegated Administrator (`commadmin user create`) を使用してユーザーにカレンダサービスを追加するには

14.5.7.1 Delegated Administrator コンソールを使用し、ユーザーがカレンダサービスを有しているかどうかを確認するには

14.5.7.2 Delegated Administrator ユーティリティーを使用し、ユーザーがカレンダサービスを有しているかどうかを確認するには

14.5.7.3 Calendar Server ユーティリティー `csuser` を使用し、ユーザーがカレンダサービスを有するかどうかを確認するには

`csresource` を使用してリソース情報を取得するには

第 15 章カレンダの管理

15.5.1 `cscal` ユーティリティーを使用したユーザーカレンダの作成