この章と「Messaging Server を利用して作成したドメインの使用」以降の章では、Calendar Server の管理方法について説明します。ここで説明する内容は次のとおりです。
Calendar Server を管理するには、Delegated Administrator ユーティリティー (従来のユーザー管理ユーティリティー) または Calendar Server のコマンド行ユーティリティーを実行するか、ics.conf 設定ファイルを編集します。
コマンド行ユーティリティーを実行するには、Calendar Server が稼動しているシステムの管理権限を持つユーザーとしてログインする必要があります。
詳細は、付録 D 「Calendar Server のコマンド行ユーティリティーのリファレンス」を参照してください。
管理に関するその他の内容については、別の章で説明します。説明する内容は次のとおりです。
ここでは、start-cal と stop-cal の使用方法について説明します。 ここで説明する内容は次のとおりです。
Calendar Server の起動と停止には、start-cal コマンドと stop-cal コマンドを使用します。start-cal と stop-cal の各ユーティリティーは、cal_svr_base/SUNWics5/cal/sbin ディレクトリに格納されています。これらのユーティリティーを、Calendar Server がインストールされているローカルマシンで実行する必要があります。
Calendar Server に用意されている csstart と csstop の各ユーティリティーは、従来リリースとの互換性維持だけを目的としています。可能であれば、Calendar Server の起動と停止には、start-cal と stop-cal ユーティリティーを使用します。
start-cal ユーティリティーは次の順序で Calendar Server サービスを開始します。
enpd: 予定通知サービス (ENS)
csnotifyd: 通知サービス
csadmind: 管理サービス
csdwpd: DWP (データベースワイヤプロトコル) サービス。リモート Calendar Server データベース設定がある場合にのみ起動される分散データベースサービス
cshttpd: HTTP サービス
csstored: 自動バックアップサービス
これらのサービスについては、「Calendar Server サービス」を参照してください。
システムの管理権限を持つユーザーとしてログインします。
cal_svr_base/SUNWics5/cal/sbin ディレクトリに移動します。
Calendar Server を起動します。
./start-cal |
Calendar Server が稼動しているシステムの管理権限を持つユーザーとしてログインします。
cal_svr_base/SUNWics5/cal/sbin ディレクトリに移動します。
Calendar Server を停止します。
./stop-cal |
自動バックアップは、start-cal の実行時に自動的に起動される csstored プロセスによって管理されます。ただし、自動バックアップは任意に有効または無効にすることができます。デフォルトでは、自動バックアップは無効になっています。csstored プロセスは、自動バックアップが有効になっていない場合でも実行されます。
自動バックアップには 2 種類あります。ホットバックアップとアーカイブバックアップです。各バックアップは個別に有効または無効にすることができます。
csstored プロセスは、start-cal を実行する前に設定しておく必要があります。 そうしないと、csstored が設定されていないことを知らせるエラーメッセージが送信されます。そのあとも、設定が行われるまで 24 時間ごとに同じメッセージが送信されます。
自動バックアップと csstored の設定方法については、第 10 章「自動バックアップ (csstored) の設定」を参照してください。
次に示すのは、自動バックアップを有効化および無効化するための作業の一覧です。
コマンド行で、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 ファイルを編集するときにカレンダサービスを停止する必要はありませんが、変更を適用するためにサービスを再起動する必要があります。
コマンド行で、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 ファイルを編集するときにカレンダサービスを停止する必要はありませんが、変更を適用するためにサービスを再起動する必要があります。
バックアップはデフォルトで無効になっています。以前に有効にしたバックアップを無効にする場合は、次の手順を実行します。
コマンド行で、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 ファイルを編集するときにカレンダサービスを停止する必要はありませんが、変更を適用するためにサービスを再起動する必要があります。
バックアップはデフォルトで無効になっています。以前に有効にしたバックアップを無効にする場合は、次の手順を実行します。
コマンド行で、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 ファイルを編集するときにカレンダサービスを停止する必要はありませんが、変更を適用するためにサービスを再起動する必要があります。
GSE (グループスケジューリングエンジン) は、コンポーネントデータベースを更新するために使用される予定のキューを保存します。管理者は Calendar Server がキューを走査する間隔を調整するためのタイムアウト値を変更できます。また、必要に応じて、キュー内の予定を一覧表示したり、特定の予定を削除したりできます。
ここで説明する内容は次のとおりです。
GSE により、Calendar Server ユーザーは予定を作成したり、ほかのユーザーに出席を依頼したりできます。出席者が同じ Calendar Server に存在する場合は、予定は出席者のカレンダにスケジューリングされます。出席者が異なる Calendar Server に存在する場合は、電子メールで出席依頼が送信されます。出席者は出席依頼に応じるか拒否するかを決めることができ、GSE ではその返信内容によって予定が更新されます。
GSE キューは実質的には GSE によって管理される独立したデータベースです。Calendar Server は、コンポーネントデータベースに対して実行する必要がある更新のキューを走査します。
この走査の頻度を調節することで、Calendar Server を調整できます。これは、ics.conf ファイルの gse.belowthresholdtimeout タイムアウト値を変更することによって行われます。第 21 章「Calendar Server のパフォーマンスの調整」を参照してください。
GSE キューエントリは、csschedule を使用して管理 (一覧表示や削除) できます。csschedule は、Calendar Server がインストールされているローカルマシンで実行する必要があります。
GSE キュー内のエントリをリスト表示するには、csschedule ユーティリティーの list コマンドを使用します。
たとえば、GSE キュー内のすべてのエントリを表示するには、次のように実行します。
csschedule list |
GSE キューに格納されている最初の 10 エントリをリスト表示するには、次のように実行します。
csschedule -c 10 list |
calid が Holiday_Schedule のカレンダの GSE キューに含まれるすべてのエントリをリスト表示するには、次のように実行します。
csschedule -v list Holiday_Schedule |
GSE キュー内のエントリを削除するには、csschedule ユーティリティーの delete コマンドを使用します。
たとえば、GSE キュー内のすべてのエントリを削除するには、次のように実行します。
csschedule -v delete
calA というカレンダで、最初のスケジュール時刻が 2001 年 11 月 30 日の 13 時 30 分 45 秒、オフセット数が 1、一意の ID が 1111、定期予定 ID が 0、シーケンス番号が 0 のエントリを GSE キューから削除するには、次のように実行します。
csschedule -v -t 20011130T133045Z -o 1 -u 1111 -r 0 -n 0 delete calA
システムの状態監視は、毎日の作業の一部として行うことをお勧めします。Calendar Server の状態監視には複数のユーティリティーツールを使用できます。csmonitor、csstats、cstool の各ユーティリティーを使用できます。また、システムの使用状況の監視に役立つ多数のログファイルを設定することもできます。
ここで説明する内容は次のとおりです。
この Calendar Server ユーティリティーは、bash を必要とするシェルスクリプトです。このユーティリティーを呼び出すと、次の機能が実行されます。
ics.conf ファイルで指定したログレベルに従って、次の各プロセスを監視および記録する。csadmind、csnotifyd、cshttpd、enpd。
cshttpd がコマンドを受け入れているかどうかを確認する。
システムに LDAP 接続が含まれているかどうかを確認する。
循環ログが有効になっている場合は、複数のトランザクションファイルが存在するかどうかを確認し、存在する場合は電子メールで警告を送信する。
カレンダデータベースの空きディスク容量をチェックして、適切な操作を行うのに必要な容量があるかどうかを確認する。
エラーが発生すると、このユーティリティーはエラーを記録し、ics.conf パラメータ service.monitor.emailaddress.to で指定された管理者に電子メールを送信する。
デバッグの目的で、モニターを非常に短い間隔の連続したループになるように設定できますが、システムリソースが余分に必要となるため、通常の運用ではそのモードにしておかないことをお勧めします。
通常の環境で csmonitor を使用するには、選択した間隔で実行されるように設定します。
csmonitor ユーティリティーについては、付録 D 「Calendar Server のコマンド行ユーティリティーのリファレンス」を参照してください。
設定を変更する権限を持つ管理者としてログインします。
/etc/opt/SUNWics5/cal/config ディレクトリに移動します。
古い ics.conf ファイルをコピーして名前を変更し、保存します。
次の表に示す 1 つ以上の ics.conf パラメータを編集します。
パラメータ |
説明とデフォルト値 |
---|---|
csmonitor を連続してループするかどうかを指定します。"0": 連続的にループしません (デフォルト)。"1": 連続的にループします。 このパラメータを “1” に設定すると、csmonitor を自動的に実行できます。 |
|
2 つの監視ループの間の遅延時間を秒単位で指定します。デフォルトは “60” 秒です。 デバッグの目的ではこの間隔を短くし、本稼働ではこの間隔を長くします。 |
|
csmonitor が送信するメッセージの送信元となる電子メールアドレスを指定します。デフォルトはなしです。 |
|
csmonitor が送信するメッセージの送信先となる電子メールアドレスを指定します。デフォルトはなしです。 |
|
service.monitor.csdb.logthreshold |
カレンダデータベース (csdb) を監視します。最大ディスク消費量のしきい値を、ディスク容量全体のパーセント値で指定します。csdb ディレクトリのディスク消費量がこの値を超えると、電子メールで警告メッセージが送信されます。デフォルトは “90” です。 |
csmonitor のログファイル名を指定します。デフォルトは “csmonitor.log” です。 |
|
ログファイルの最大サイズを指定します。ログファイルがこのサイズを超えると、csmonitor はログを csmonitor.log.timestamp という名前で保存し、現在のログをリセットします。デフォルトは “2097152” です。 |
|
デバッグレベルを指定します。設定できる値は 0 〜 5 です。 この値が大きいほど、csmonitor は詳細なメッセージを送信します。デフォルトは “0” で、ログは指定されません。このパラメータを “5” に設定すると、デバッグのログが指定されます。 |
ファイルを ics.conf として保存します。
Calendar Server を再起動します。
cal_svr_base /SUNWics5/cal/sbin/start-cal
「csstats」 ユーティリティーは、カレンダ設定 (counter.conf) ファイルに定義されているカウンタオブジェクトからの統計情報を表示します。httpstat、authstat、wcapstat、dbstat などのカウンタオブジェクトは、Calendar Server に関する次のような情報を表示します。
並行接続の最大数と合計接続数
ログインと接続の成功数と失敗数
データベースの読み取り、書き込み、削除の回数
Calendar Server のカウンタ統計情報については、付録 E 「Calendar Server の設定パラメータ」を参照してください。
Calendar Server がインストールされているマシンだけでなく、次のサービスに対しても ping を実行できます。
cshttpd
csadmind
enpd
cstool の使用方法については、付録 D 「Calendar Server のコマンド行ユーティリティーのリファレンス」を参照してください。
Calendar Server の各サービスは、状態に関する情報をそれぞれのログファイルに書き込みます。次の表に示すように、各ログファイルにはサービス名に関連する名前が付けられます。
サービス名 |
ログファイル名 |
---|---|
管理サービス (csadmind) |
admin.log |
分散データベースサービス (csdwpd) |
dwp.log |
HTTP サービス (cshttpd) |
http.log |
通知サービス (csnotifyd) |
notify.log |
シングルサインオンのログ |
am_sso.log |
起動コマンドのログ |
start.log |
終了コマンドのログ |
stop.log |
格納コマンドのログ |
store.log |
Calendar Server ログファイルは、次のデフォルトディレクトリに格納されます。
/var/opt/SUNWics5/logs
各ログファイルは、一意の番号によって識別される新しいログファイルにロールオーバーされます。次に例を示します。
admin.log.8.1083013284 http.log.8.1083013284
次の表に示すように、Calendar Server のログファイルに記録する予定の重要度は、6 段階に分かれています。Calendar Server がログファイルに記録する予定の重要度は、ics.conf パラメータ logfile.loglevel の設定を変更して指定できます。
重要度 |
意味 |
---|---|
CRITICAL |
危険な状態にあります。 |
ERROR |
エラー状態にあります。 |
WARNING |
警告状態にあります。 |
NOTICE |
正常だが、特筆すべき状態にあります。これは、各カレンダサービスのデフォルトのレポートレベルです。 |
INFORMATION |
情報提供用。 |
DEBUG |
デバッグレベルのメッセージ。 |
ログ予定はタイムスタンプ、サーバーホスト名、重要度、プロセス名 (プロセス ID)、予定の種類、優先度、説明から構成される 1 行で表されます。
ics.conf のログの設定については、付録 E 「Calendar Server の設定パラメータ」を参照してください。
CLD キャッシュを有効にしている場合は、ときどきキャッシュをクリアする必要があります。ここで説明する内容は次のとおりです。
CLD キャッシュは、さまざまな理由でシステム設定との同期が取れなくなることがあります。 たとえば、次のような場合がこれに該当します。
サーバーの追加、削除、または名前の変更を行った場合
サーバーを設定内のある機能から別の機能に移動した場合
1 つ以上のカレンダを別のバックエンドサーバーに移動した場合
上記のいずれかを行った場合は、CLD キャッシュを更新するために、それをクリアする必要があります。
Calendar Server を停止します。
/var/opt/SUNWics5/csdb/cld_cache ディレクトリ内のすべてのファイルを消去します。ただし、cld_cache ディレクトリ自体は消去しません。
Calendar Server を再起動します。
設定内のサーバー名を追加、削除、または変更した場合は、エラーの発生を防ぐために「後処理」の手順をいくつか実行する必要があります。
CLD キャッシュのクリア
古いサーバーを取り除く場合は、そのサーバーが指定されている ics.conf パラメータからそれを削除します。
匿名アクセスとは、認証を必要としない特殊なログインのことです。匿名ログインが有効になっていると、公開カレンダへの読み書きアクセスがデフォルトで有効になります。公開カレンダへの書き込みアクセスを拒否することも可能です。ここで説明する内容は次のとおりです。
Communication Express では、読み取りだけでなく、書き込みについても匿名ログインが許可されている必要があります。「Communications Express の設定」を参照してください。
設定を変更する権限を持つ管理者としてログインします。
/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 環境とは、データベースが複数のバックエンドに分散されている環境のことです。「DWP 環境でのカレンダ検索のパフォーマンス向上」を参照してください。
ファイルを ics.conf として保存します。
Calendar Server を再起動します。
cal_svr_base /SUNWics5/cal/sbin/start-cal
設定を変更する権限を持つ管理者としてログインします。
/etc/opt/SUNWics5/cal/config ディレクトリに移動します。
古い ics.conf ファイルをコピーして名前を変更し、保存します。
次の表に示すように ics.conf のパラメータを編集します。
パラメータ |
説明とデフォルト値 |
---|---|
service.wcap.anonymous. allowpubliccalendarwrite |
匿名アクセスのユーザーによる公開カレンダへの書き込みを有効または無効にします。アクセスを有効にするには、この値を “yes” に設定します (デフォルト)。 |
ファイルを ics.conf として保存します。
Calendar Server を再起動します。
cal_svr_base /SUNWics5/cal/sbin/start-cal
Communications Express 用にプロキシ管理者のログイン (プロキシ認証) を有効にする必要があります。Communications Express 用にプロキシ認証を設定する方法については、「Communications Express の設定」を参照してください。
ただし、Communications Express を使用しない場合でもプロキシ認証を有効にすることができます。この節では、Communications Express を使用しない場合にプロキシ認証を有効にする手順について説明します。
設定を変更する権限を持つ管理者としてログインします。
/etc/opt/SUNWics5/cal/config ディレクトリに移動します。
古い ics.conf ファイルをコピーして名前を変更し、保存します。
ics.conf ファイルを編集して次のパラメータを設定します。
service.http.allowadminproxy = "yes"
ファイルを ics.conf として保存します。
新しい値を適用するために Calendar Server を再起動します。
次の WCAP コマンドを使用して、管理者プロキシログインが正しく機能することを確認します。
http://server[:port] /login.wcap?user=admin-user&password=admin-password &proxyauth=calendar-user
それぞれの意味は次のとおりです。
server: Calendar Server が稼動しているサーバーの名前。
port: Calendar Server のポート番号。デフォルトのポートは 80。
admin-user: Calendar Server の管理者。例: calmaster
admin-password: admin-user のパスワード。
calendar-user: Calendar Server ユーザーの calid。
コマンドの実行が成功すると、Calendar Server は calendar-user のカレンダを表示します。問題が発生した場合は、「Unauthorized」というメッセージが出力されます。次のような原因が考えられます。
admin-user が Calendar Server の管理者権限を持っていない。
admin-password が正しくない。
calendar-user が有効な Calendar Server ユーザーではない。
現在のリリースでは、設定の再読み込みに cstool refresh コマンドを使用しないでください。その代わりに、stop-cal コマンドと start-cal コマンドを使用します。詳細は、「Calendar Server の起動と停止」を参照してください。
ここでは、ホストされたドメインの管理について、次の項目を説明します。
インストールしたカレンダをホストされたドメイン用に設定し、第 11 章「ホストされたドメインの設定」で説明している準備作業を行うと、新しいホストされたドメインを追加できるようになります。
各ドメインには、設定可能な属性とユーザー設定があります。これらの属性は、icsCalendarDomain オブジェクトクラスに属しています。属性には、アクセス権、アクセス制御リスト (ACL)、ドメイン検索、ドメイン検索のアクセス権、ユーザーの状態、プロキシログインなどのユーザー設定が含まれます。
Calendar Server のホストされた (または仮想) ドメインを管理するには、次の 2 つのツールのセットのいずれかを使用します。
Schema 2 環境の場合は、Delegated Administrator コンソールまたはユーティリティー。
Delegated Administrator は、Java Enterprise System インストーラで個別にインストール可能なコンポーネントです。このユーティリティーについては、『Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide』を参照してください。コンソールについては、Delegated Administrator コンソールのオンラインヘルプを参照してください。
Schema 1 環境の場合は、Calendar Server ユーティリティーの csdomain および csattribute。
Calendar Server にインストールされています。csdomain で属性を追加または削除できますが、modify コマンドはありません。既存の属性の値を変更するには、csattribute を使用します。また、csdomain で作成したドメインのオブジェクトクラスに追加や削除を行う必要がある場合には、ldapmodify を使用します。
csdomain および csattribute については、付録 D 「Calendar Server のコマンド行ユーティリティーのリファレンス」 を参照してください。
特定のオブジェクトクラスおよび属性については、『Sun Java System Communications Services 6 2005Q4 Schema Reference』を参照してください。
ホストされたドメインの概要や、その他の入門的な内容については、第 11 章「ホストされたドメインの設定」を参照してください。
Calendar Server は、Access Manager コンソールを使用してのドメイン管理はサポートしていません。
次を参照して、Schema 2 または Schema 1 用のホストされたドメインを作成します。
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』を参照してください。
csdomain を実行するには、ホストされたドメインモードである必要があります。ホストされたドメインを有効にする方法については、第 11 章「ホストされたドメインの設定」を参照してください。
Schema 1 でホストされたドメインを作成するには、csdomain create を使用します。たとえば、west.sesta.com を作成するには、次のコマンドを使用します。
csdomain create west.sesta.com
ここでは、ドメイン間の検索を有効にするために必要な 2 つの作業について説明します。
このドメインの検索を許可する各ドメインの LDAP エントリに 「このドメインの検索を許可するドメインの名前を追加する」。
このドメイン内のユーザーが予定への出席依頼を送信する場合の 「このドメインによって検索されるドメインの名前を追加する」。
これを実行するには、次のいずれかのツールを使用できます。ldapmodify (Schema 1 および 2)、または Delegated Administrator コンソールまたはユーティリティー (Schema 2 の場合)
各ドメインの LDAP エントリは、icsExtendedDomainPrefs 属性の domainAccess パラメータで定義されている ACE のアクセス権を指定します。外部ドメインにこのドメインの検索を許可する方法には、次の 2 種類があります。
ACI の構成については、「カレンダのアクセス制御」で詳細に説明しています。
これを実行する方法には次の 3 つがあります。
ldapmodify を使用して、icsExtendedDomainPrefs の domainAccess 設定に次の ACE 文字列を作成します。
@domain_being_allowed ^a^lsfr^g
このドメインの検索を許可するドメインを指定し、そのあとに検索を許可するための十分な権限を指定して ACE を構成します。
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 コンソールを使用する方法の場合は、管理者に同様の権限が許可されません。アクセス権の一覧が事前に設定されています。許可されているアクセス権は、空き/予定ありアクセスと、予定スケジュールアクセスです。カレンダの所有者がすべてのユーザーに対して読み取りアクセス権を設定しないかぎり、ユーザーは予定の詳細を参照できません。
すべての外部ドメインにこのドメインの検索を許可するには、次の 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 設定が更新されます。
上に挙げた最初の 2 つの方法ではドメインに与える正確なアクセス権を指定できますが、最後の Delegated Administrator コンソールを使用する方法の場合は、管理者に同様の制御が許可されません。アクセス権の一覧は事前に設定されています。許可されているアクセス権は、空き/予定ありアクセスと、予定スケジュールアクセスです。カレンダの所有者がすべてのユーザーに対して読み取りアクセス権を設定しないかぎり、ユーザーは予定の詳細を参照できません。
このドメインによって検索される外部ドメインを追加するには、次の 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 コンソールのオンラインヘルプを参照してください。
デフォルトでは、Calendar Server はホストされていないドメインになっています。Java Enterprise System で Calendar Server および Messaging Server を使用する場合は、ホストされたドメインを使用することをお勧めします。
インストールされている Calendar Server のホストされたドメインを有効または無効にするには、ics.conf ファイルを編集します。
ics.conf ファイルを次のように編集します。
service.virtualdomain.support="yes" (デフォルトは "no")
カレンダサービスを再起動します。
ホストされたドメインを実装するために必要なすべての ics.conf パラメータの一覧については、「ホストされたドメイン環境の設定」を参照してください。
この章では、ユーザーとリソースの管理のための Calendar Server ユーティリティーの使用方法について説明します。この章で説明する内容は次のとおりです。
次のいずれかのユーザー管理ツールを使用して、カレンダのユーザーとリソースを管理できます。
Delegated Administrator コンソール
この GUI を使用して、Calendar Server 用の LDAP にユーザーとリソースをプロビジョニングします。GUI の使用方法については、Delegated Administrator コンソールのオンラインヘルプを参照してください。
Delegated Administrator ユーティリティー (commadmin)
これらのツールを使用して、Calendar Server 用の LDAP にユーザーとリソースをプロビジョニングします。詳細な手順については、『Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide』を参照してください。
Delegated Administrator はカレンダを管理しません。ユーザーとリソースのカレンダを作成するには、Calendar Server ユーティリティーを使用します。
Calendar Server ユーティリティー (csuser および csresource)
これらのユーティリティーを使用して、カレンダを管理します。さらに、設定で次の基準をすべて満たしている場合は、ユーザーとリソースの管理にも使用できます。
Access Manager を使用していない。
Sun LDAP Schema 1 を使用して、以前のバージョンの Calendar Server または Messaging Server がインストールされている。
Schema 1 を使用し続ける予定である。
このマニュアルに含まれているコマンド行ユーティリティーの参考資料、付録 D 「Calendar Server のコマンド行ユーティリティーのリファレンス」 も参照してください。
Schema 2 および Delegated Administrator を使用している場合でも、Calendar Server コマンド行ユーティリティーを使用して特別な機能を実行する必要がある場合もあります。このような場合には、どのユーティリティーを使用すればよいか、作業指向のこのマニュアルの記述を参照してください。
ここでは、Calendar Server の新規ユーザーとリソースの管理に関する次の情報について説明します。
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』を参照してください。
csuser ユーティリティーを使用します。たとえば、ユーザー jdoe を sesta.com ドメインに追加するには、次のように実行します。
csuser -m jdoe@sesta.com -d sesta.com create jdoe
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 を使用して、実際のリソースカレンダを作成する必要があります。リソースカレンダの作成方法については、「カレンダの作成」を参照してください。
commadmin ユーティリティーで使用可能なすべてのオプションの詳細については、『Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide』を参照してください。
csresource ユーティリティーを使用して、LDAP エントリとリソースカレンダの両方を作成します。たとえば、プロジェクタ P101 を追加するには、次のコマンドを使用します。
csresource -m p101@siroe.com -c p101 create Projector_101
csresource については、「csresource」を参照してください。
Calendar Server では、ユーザーおよびリソースに、ユーザーまたはリソースの電子メールアドレスを含む mail 属性が指定されていることが必要です。この属性を指定することにより、電子メールアドレスまたは calid を使用してカレンダやリソースの検索を実行できます。Delegated Administrator を使用して新規ユーザーを作成すると、mail 属性が自動的に追加されます。この処理は、そのユーザーにメールサービスが割り当てられていない場合でも実行されます。
Calendar Server では、リソースカレンダの電子メール通知をサポートしていません。
mail 属性を追加しても、ユーザーカレンダの電子メール通知は有効になりません。
ユーザーカレンダの電子メール通知を有効にするには、ユーザーの LDAP エントリに次の 2 つの属性を追加します。
icsExtendedUserPrefs:ceNotifyEnable=1 icsExtendedUserPrefs:ceNotifyEmail=jdoe@sesta.com
以前のバージョンの Calendar Server (mail 属性が必要ではなかったバージョン) でユーザーおよびリソースを追加している場合、既存のユーザーおよびリソース LDAP エントリへの mail 属性の追加が必要になる場合があります。
ここで説明する内容は次のとおりです。
属性が設定されているかどうかをチェックするには、-v (verbose、詳細出力) オプションを指定して csattribute list コマンドを実行します。
csattribute -v list Room100
出力により mail 属性が設定されているかどうかがわかります。
cn=Room 100,ou=conferenceRooms,dc=sesta,dc=com has mail: Room100@sesta.com
既存のユーザーおよびリソースに mail 属性を追加するには、次のいずれかの方法を使用します。
Calendar Server の 「csattribute」ユーティリティーを使用する。
次の例では、Room100 という既存の会議室の LDAP mail 属性を sesta.com サーバーに追加します。
csattribute -a mail=Room100@sesta.com add Room100
ldapmodify を使用して、属性を LDAP エントリに直接追加する。
ユーザーの作成が完了すると、csuser ユーティリティーを使用して次の管理作業を実行できます。
すべてのカレンダユーザーを一覧表示したり、特定ユーザーのカレンダ属性を表示したりするときは、csuser ユーティリティーの list コマンドを使用します。
たとえば、カレンダ機能が有効なすべてのユーザーを表示するには、次のように実行します。
csuser list
jsmith という単一ユーザーのすべてのカレンダ属性を表示するには、次のように実行します。
csuser -v list jsmith
ユーザーを無効にする目的は、ユーザーが Calendar Server にログインできないようにすることです。この処理方法は、どのユーザー管理ツールを使用してユーザーを作成したかによって異なります。Delegated Administrator コンソールで作成したユーザーは、その管理にもこのツールを使用するようにしてください。同様に、Delegated Administrator ユーティリティーを使用してユーザーにカレンダサービスを割り当てた場合は、サービスを削除する場合もこのツールを使用します。最後に、ホストされていないドメイン環境にあるユーザーは、Calendar Server ユーティリティーだけを使用して管理するようにしてください。各ツールにより、少し処理が異なります。
ここで説明する内容は次のとおりです。
「Calendar Server ユーティリティー (csuser disable)」(Calendar Server ユーティリティー)
Delegated Administrator コンソールで、「ユーザー」一覧ページからユーザーを選択します。このユーザーのプロパティーで、カレンダサービスを含むサービスパッケージを削除します。これにより、このユーザーがカレンダに対して無効になり、ユーザーの icsStatus が inactive に設定されます。
パッケージにその他のサービスも含まれている場合は、カレンダが含まれていない別のパッケージを使用して、これらのサービスを再度割り当てる必要があります。
ユーザーがカレンダサービスにアクセスできないようにするには、次の例に示すように、ユーザーの LDAP エントリからサービスを削除します。
commadmin user delete jsmith -S cal
これにより、LDAP エントリを完全に削除することなく、このユーザーがカレンダに対して無効になります。さらに、このコマンドによって、ユーザーの icsStatus も inactive に変更されます。
disable コマンドにより、ユーザーはカレンダデータにアクセスできなくなりますが、そのユーザーの情報は LDAP エントリや Calendar Server データベースから削除されません。このコマンドによって、icsStatus 属性が active から inactive に変更されます。ホストされていないドメインモードには、カレンダサービスのようなものは存在しません。
たとえば、jsmith による Calendar Server へのアクセスを無効にするには、次のように実行します。
csuser disable jsmith
ただし、jsmith が現在 Calendar Server にログインしている場合は、ログオフするまで jsmith はカレンダデータへのアクセスを維持できます。
ユーザーを有効にするには、次のいずれかのユーティリティーを使用します。
「Delegated Administrator (commadmin user create)」(Schema 2 の場合)
「Calendar Server ユーティリティー (csuser enable)」(Schema 1 の場合)
新規ユーザーと既存のユーザーの両方を有効にすることができます。
新規ユーザー: ユーザーを作成するときに、「新規ユーザー」ウィザードを使用して、カレンダサービスを含むサービスパッケージをユーザーに割り当てます。ユーザーは自動的に有効になります。
既存のユーザー: 「ユーザー」一覧ページからユーザーを選択し、「サービスパッケージを割り当て」ウィザードを使用して、カレンダサービスを含むサービスパッケージを選択します。ユーザーは自動的に有効になります。
ユーザーを作成する場合は、次の例に示すように、カレンダサービスに対してそのユーザーを有効にします。
commadmin user create jsmith -S cal
ユーザーの作成時に、カレンダサービスに対してユーザーを有効にしていない場合は、次の例に示すように、modify コマンドを使用して、あとでカレンダサービスをユーザーに追加できます。
commadmin user modify jsmith -S cal
ユーザーエントリの作成時に csuser create を使用した場合、ユーザーは自動的に有効になります。
ユーザーが、カレンダ機能が有効でない別のユーザー (つまり、デフォルトカレンダを持たないユーザー) に要求を送信すると、Calendar Server はカレンダが見つからないことを示すエラーを送信元ユーザーに返します。
カレンダユーザー用の電子メールのエイリアスを設定する必要がある場合は、そのユーザーの LDAP エントリに mailalternateaddress 属性を追加します。mail 属性は主要メールアドレスを提供し、mailalternateaddress 属性は電子メールのエイリアスに使用されます。どちらの属性も、メールアドレスをユーザーのカレンダ ID (calid) にマッピングします。
この属性を追加するには、Calendar Server ユーティリティーの csattribute を使用するか、または ldapmodify で直接 LDAP を更新します。次の例では、csattribute を使用しています。
これらの変更を有効にするには、エイリアスのテーブルまたは設定の再構築が必要となる場合があります。Messaging Server (または使用するその他の電子メール製品) のマニュアル、およびメールサービスの変更に関するサイト固有のドキュメントおよび手順を参照してください。Messaging Server のマニュアルは、次の Web サイトで入手できます。http://docs.sun.com/coll/1312.1
たとえば、JohnSmith という名前のユーザーに対して、以下の値を持つ mailalternateaddress 属性を追加するには次のようにします。
ユーザー ID (uid) および calid: johnsmith
password: John Smith のパスワード
電子メールアドレス: john.smith@sesta.com
電子メールのエイリアス: johns@sesta.com および jsmith@sesta.com
csattribute -a mailalternateaddress=johns@sesta.com add johnsmith csattribute -a mailalternateaddress=jsmith@sesta.com add johnsmith
ディレクトリサーバーに特定のユーザーが存在し、そのユーザーが Calendar Server のデータにアクセスできるかどうかを調べるには、csuser ユーティリティーの check コマンドを使用します。
たとえば、jsmith のカレンダ機能が有効であるかどうかを調べるには、次のように実行します。
csuser check jsmith
check コマンドによって、ユーザーが LDAP ディレクトリサーバーに存在しないことが検出された場合は、そのユーザーのディレクトリサーバーエントリを作成する必要があります。
ユーザーをホストドメインまたはホストされていないドメインのどちらから削除するかに応じて異なるツールを使用します。
undelete コマンドはありません。
Delegated Administrator を使用してホストドメイン内のユーザーを削除したら、これらのユーザーは破棄して、最初から再度追加する必要があります。破棄されるまで、ユーザー名は再利用できません。
ホストされていないドメインについては、「ホストされていないドメインの場合のみ: 削除のマークは付いているが破棄されていないユーザーの削除取消し」を参照してください。
Delegated Administrator のどちらのインタフェースでも、ユーザーに削除のマークを付けることができます。ただし、Delegated Administrator コンソールでは LDAP からユーザーを破棄できません。破棄するためには Delegated Administrator ユーティリティーを使用する必要があります。次の作業一覧は、LDAP からユーザーを削除するための手順を示しています。ユーザーは、最後の手順を完了するまで LDAP から実際には削除されません。
ユーザーエントリに削除のマークを付けます。
Delegated Administrator コンソールの場合: 「ユーザー」一覧ページで、削除するユーザーを選択し、「削除」をクリックします。
Delegated Administrator ユーティリティーの場合: commadmin user delete コマンドを使用します。次に例を示します。
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 からユーザーを誤って破棄した場合は、「ユーザーカレンダの管理」で説明されている 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』を参照してください。
指定されたユーザーの LDAP エントリとそのユーザーのデフォルトカレンダを削除するには、Calendar Server ユーティリティーの csuser delete コマンドを使用します。
たとえば、ユーザー jsmith の LDAP エントリおよびデフォルトカレンダを削除するには、次のコマンドを使用します。
csuser delete jsmith
このユーザーに属するその他のカレンダを削除する場合は、「ユーザーカレンダの管理」の説明に従って cscal を使用する必要があります。
ホストされていないドメインの場合は、削除のマークは付いているがまだ破棄されていないユーザーの削除を取り消すために、そのユーザーの icsStatus 属性を active にリセットすることが必要です。これを実行するには、ldapmodify を使用して直接 LDAP エントリを変更するか、または Calendar Server ユーティリティーの csattribute を使用します。
ただし、ホストされていないドメインでユーザーを破棄した後は、LDAP サーバー情報をバックアップから復元することしかできません。
特定のユーザーのすべてのカレンダ LDAP 属性をデフォルトの設定に戻すには、csuser ユーティリティーの reset コマンドを使用します。
たとえば、jsmith のすべてのカレンダ属性をデフォルトの設定に戻すには、次のように実行します。
csuser reset jsmith
カレンダユーザーをリセットすると、icsCalendarUser (オブジェクトクラス)、icsSubscribed、icsCalendarOwned、icsCalendar、icsDWPHost (LDAP CLD が設定されている場合) を含むすべてのカレンダ属性がユーザーの LDAP エントリから消去されます。Calendar Server 管理者がユーザーに代わってカレンダを作成することはできません。
次の場合に、ユーザーの LDAP エントリにこれらの属性が復元されます。
ユーザーが Calendar Server にログインし直した場合、または
Calendar Server 管理者がそのユーザーに対して csuser enable コマンドを実行した場合 (この場合でも、icsDWPHost 属性は復元されない)。
1 つ以上のユーザー ID を変更する必要がある場合は、csrename ユーティリティーを実行します。このユーティリティーは、次の手順で実行します。
Calendar Server LDAP 属性のユーザー ID (ics という接頭辞が付いている) を変換します。LDAP ディレクトリが同じ場所で更新されます。
Calendar Server データベースファイルの予定や作業のユーザー名を変更します。これによって、新しいデータベースが出力先ディレクトリに書き込まれます。既存のデータベースファイルは変更されません。
1 つのユーザー ID だけを変更する場合でも、データベース全体が書き換えられることに注意してください。そのため、これは実行するには「労力の多い」ユーティリティーです。
csrename ユーティリティーの実行方法については、付録 D 「Calendar Server のコマンド行ユーティリティーのリファレンス」 を参照してください。
設定を変更する権限を持つ管理者としてログインします。
/etc/opt/SUNWics5/cal/config ディレクトリに移動します。
古い ics.conf ファイルをコピーして名前を変更し、保存します。
次の表に示すように、ics.conf パラメータを編集します。
パラメータ |
説明とデフォルト値 |
---|---|
service.wcap. allowpublicwritablecalendars |
ユーザーが書き込み可能な公開カレンダを所有できるようにします。これは、デフォルトで有効になっています (“yes” に設定されている)。 |
ファイルを ics.conf として保存します。
Calendar Server を再起動します。
cal_svr_base /SUNWics5/cal/sbin/start-cal
リソースを追加したら、csresource を使用して次のように管理できます。
sbin ディレクトリに移動します。
1 つまたはすべてのリソースをリスト表示するには、csresource list コマンドを使用します。
たとえば、すべてのリソースについてすべての情報をリスト表示するには、次のように実行します。
./csresource -v list
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
ここでは、Messaging Server および Sendmail 用の bitbucket チャネルの設定方法について説明します。bitbucket チャネルは、リソースカレンダ用に生成された電子メールを破棄する方法の 1 つです。次の例では、sesta.com サーバー上の Room100 というリソースを使用しています。bitbucket チャネル (または同等機能) を設定しない場合は、リソースカレンダに送信される電子メールメッセージを定期的に削除する必要があります。
ここで説明する手順は次のとおりです。
imta.cnf ファイルに bitbucket チャネルが定義されていることを確認します。
メッセージの送信先を bitbucket チャネルに設定するには、csattribute ユーティリティーを使用してリソースの電子メールアドレスを作成します。
csattribute -a mail=Room100@bitbucket.sesta.com add Room100 |
適切なホストの /etc/aliases ファイルに次のようなエントリを追加します。
Resource/Conference room aliases Room100: /dev/null |
csattribute ユーティリティーを使用して、リソースの電子メールアドレスを LDAP ディレクトリに追加します。
csattribute -a mail=Room100@sesta.com add Room100 |
Calendar Server が使用する LDAP 属性の管理には、「csattribute」ユーティリティー、または ldapmodify を使用します。csattribute を使用すると、属性をリスト表示、追加、または削除できます。属性を変更するには、ldapmodify を使用します。ここで説明する内容は次のとおりです。
インストール時に指定した Calendar Server の実行ユーザーまたはグループ (icsuser、icsgroup など)、または root としてログインします。
sbin ディレクトリに移動します。
ユーザーまたはリソースの属性をリスト表示するには、csattribute list コマンドを使用します。たとえば、ドメイン tchang@sesta.com の属性をリスト表示するには、次のコマンドを実行します。
./csattribute -t user -d sesta.com list tchang
インストール時に指定した 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
インストール時に指定した 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
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 の値を変更することにより、あるバックエンドホストから別のバックエンドホストにユーザーのカレンダを移動しようとすることは避けてください。icsDWPHost を変更しても、カレンダは新しいバックエンドホストに移動されません。バックエンドサーバー間でカレンダを移動する方法については、「ユーザーカレンダの管理」を参照してください。
この章で説明する内容は次のとおりです。 カレンダの作成や管理を行うための Calendar Server コマンド行ユーティリティーの使用方法について説明します。
Delegated Administrator では、カレンダの作成または管理は行えません。付録 D 「Calendar Server のコマンド行ユーティリティーのリファレンス」 で説明している Calendar Server ユーティリティーを使用してください。
カレンダを作成する前に、次の情報を確認しておく必要があります。
カレンダには、ユーザーカレンダとリソースカレンダの 2 つのタイプがあります。
ユーザーカレンダは、作業や活動のスケジュールリングを目的としています。リソースカレンダは、会議室やビデオ機器などの施設設備を使用するためのスケジューリングを目的としています。
両方のタイプのカレンダが、一意のカレンダ識別子 (calid) によって識別されます。
cscal を使用してユーザーカレンダを作成します。または、ログイン時に自動プロビジョニングを有効にします。「ユーザーカレンダの自動作成」を参照してください。
csresource を使用してリソースカレンダを作成します。リソースカレンダの自動プロビジョニング機能はありません。
cscal または csresource を実行するには、Calendar Server が稼動しているシステムの管理権限を持つユーザーとしてログインする必要があります。これらのコマンドは、必ず /opt/SUNWics5/cal/sbin ディレクトリから実行してください。つまり、sbin ディレクトリに移動する必要があります。パスを指定して別のディレクトリから実行することはできません。
Calendar Server データベース内の各カレンダは、一意のカレンダ識別子 (ID) または calid によって識別されます。カレンダを作成するとき、calid を指定する必要があります。
ここで説明する内容は次のとおりです。
データベース内の各カレンダは、一意のカレンダ ID (calid) によって識別されます。次の calid 構文には、指定する項目が 3 つあります。
userid[@domain][:calendar-name]
指定する 3 つの項目は次のとおりです。
Calendar Server インスタンスのドメインで一意のユーザー ID。
ユーザーのドメイン名。
ホストされたドメインがない場合、ユーザーが属しているドメインには曖昧さがないため、ドメインの部分は省略可能です。
ホストされたドメインがあり、ドメインの部分が指定されていない場合、Calendar Server では ics.conf の service.defaultdomain で指定された値をドメインに使用します。ユーザーがデフォルトのドメインに属していない場合は、ドメイン部分を指定する必要があります。
ホストされたドメイン (仮想ドメインとも言う) については、第 11 章「ホストされたドメインの設定」および 第 13 章「ホストされたドメインの管理」を参照してください。
特定のユーザーにとって一意となるカレンダの名前で、省略可能です。所有者のデフォルトカレンダは 1 つだけですが、さまざまな目的のほかのカレンダを所有することが可能です。このようなデフォルト以外の各カレンダは、カレンダ名によって識別されます。たとえば、ユーザー John Doe の uid が jdoe である場合、そのデフォルトカレンダは jdoe@sesta.com になります。たとえば、リトルリーグチームのコーチが試合の記録を取るために使用する 補助カレンダは、次の calid として識別されることもあります。jdoe@sesta.com:baseball
calid を作成する場合、次の規則を念頭に置いてください。
カレンダ ID の大文字と小文字は区別されます。たとえば、JSMITH と jsmith は別の ID として認識されます。この方法は、メールアドレスの場合とは異なります。 メールアドレスは大文字と小文字が区別されません。たとえば、jsmith@sesta.com と JSMITH@SESTA.COM では、同じアドレスを指します。
カレンダ ID に空白文字を含めることはできません。 使用できる文字は次の文字に限定されています。
アルファベット (a-z、A-Z) と数字 (0-9) (つまり、ASCII 以外の文字は使用できない)
Special characters: ピリオド (.)、下線 (_)、ハイフンまたはダッシュ (-)、アットマーク (@)、アポストロフィー (')、パーセント記号 (%)、スラッシュ (/)、感嘆符 (!) の特殊文字
ユーザー ID は calid の一部であるため、ユーザー ID に空白文字を含める (たとえば j smith) ことはできません。空白文字が含まれるユーザー ID を持つユーザーは Calendar Server にログインすることはできますが、空白文字によってログイン後に問題が生じる可能性があります。
次に適切なカレンダ ID の例を示します。
jsmithjsmith:private_calendar jsmith@calendar.sesta.com:new-cal
ホストされたドメインを持つ前に作成された calid があり、ホストされていないドメインの calid からホストされたドメインの calid へ変換する場合、既存の calid にドメイン部分を追加するために使用できる csvdmig というユーティリティーがあります。このユーティリティーの使用方法については、「csvdmig」 を参照してください。
ここで説明する内容は次のとおりです。
Calendar Server は、ユーザーが最初にログインしたときにデフォルトのカレンダを自動的に作成します。この機能を自動プロビジョニングといいます。自動プロビジョニングはデフォルトで有効にされています。ただし、自動プロビジョニングはユーザーカレンダにのみ使用可能です。 リソースカレンダは明示的に作成する必要があります。
Calendar Server は、その名前のカレンダが存在しないかぎり、ユーザー ID からこの新しいデフォルトカレンダのカレンダ ID (calid) を作成します。
たとえば、ユーザー ID が jsmith の John Smith が初めて Calendar Server にログインするときに、Calendar Server は calid として jsmith が設定されたデフォルトカレンダを自動的に作成します。それ以降に John Smith が作成する各カレンダの calid は、カレンダ名の先頭に jsmith: が追加されます。たとえば、John Smith があとで meetings という名前の新しいカレンダを作成する場合、ホストしていない環境内の新しいカレンダの calid は jsmith:meetings です。
デフォルトカレンダを持たないユーザーが参加予定者として指定される場合、Calendar Server はカレンダが見つからないことを示すエラーを返します。
自動プロビジョニングはデフォルトで有効にされています。しかし、自動プロビジョニングを無効にしたあとに再び有効にする必要がある場合は、次の手順を実行します。
設定を変更する権限を持つ管理者としてログインします。
/etc/opt/SUNWics5/cal/config ディレクトリに移動します。
古い ics.conf ファイルをコピーして名前を変更し、保存します。
次の表に示す、Calendar Server 設定ファイル ics.conf に含まれる 1 つ以上のパラメータを編集します。
パラメータ |
説明とデフォルト値 |
---|---|
local.autoprovision |
“yes” に設定すると、ユーザーが最初にログインしたときにデフォルトのカレンダが自動的に作成されます。自動プロビジョニングはデフォルトで有効にされています。 この機能を無効にするには、値を “no” に設定します。 |
ユーザーの LDAP エントリがカレンダに対して有効になっていることを検証します。
このエントリには、icsCalendarUser オブジェクトクラスが含まれている必要があります。ユーザーの LDAP エントリにクラスがない場合は、追加します。
サイトでホストされたドメインを使用している場合、カレンダの自動プロビジョニングを有効にする前に、ユーザーのドメインでカレンダが有効にされている必要があります。ドメインエントリに icsCalendarDomain オブジェクトクラスが含まれている必要があります。
ファイルを保存します。
Calendar Server を再起動します。
cal_svr_base /SUNWics5/cal/sbin/start-cal
設定を変更する権限を持つ管理者としてログインします。
/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
自動プロビジョニングが無効の場合、正常にログインするためには、そのユーザーに対して明示的にカレンダが作成されている必要があります。
Calendar Server は、ACL (アクセス制御リスト) を使用して、カレンダ、カレンダプロパティー、予定や仕事 (作業) などのカレンダコンポーネントへのアクセスを制御します。
ここで説明する内容は次のとおりです。
次の表は、Calendar Server がアクセス制御に使用する、ics.conf ファイル内の設定パラメータを示しています。
表 15–1 アクセス制御の設定パラメータ
パラメータ |
説明 |
---|---|
ユーザーがカレンダを作成したときに使用されるデフォルトのアクセス制御設定を指定します。デフォルトは次のとおりです。 "@@o^a^r^g;@@o^c^wdeic^g; @^a^fs^g;@^c^^g;@^p^r^g" |
|
カレンダ所有者のデフォルトのアクセス制御設定を指定します。デフォルトは次のとおりです。 "@@o^a^rsf^g;@@o^c^wdeic^g" |
|
リソースカレンダを作成したときに使用されるデフォルトのアクセス制御設定を指定します。デフォルトは次のとおりです。 "@@o^a^r^g;@@o^c^wdeic^g; @^a^rsf^g" |
新しい予定または仕事を作成するときに、ユーザーは予定または仕事に公開、非公開、または時刻と日付のみの公開 (極秘) を指定できます。
ユーザーのカレンダに対する読み取りアクセス権を持つ誰もが予定また は仕事を表示できます。
カレンダの所有者だけが予定または仕事を表示できます。
これらは極秘の予定および仕事です。カレンダの所有者は予定または仕事を表示できます。カレンダに対する読み取りアクセス権を持つユーザーがカレンダにア クセスすると、「タイトルなしの予定」とカレンダに表示されます。
Calendar Server フィルタが非公開の、および時刻と日付のみが公開される極秘の予定と仕事を認識できるかどうかは、calstore.filterprivateevents によって決定されます。このパラメータはデフォルトで "yes" に設定されます。calstore.filterprivateevents を "no" に設定すると、Calendar Server は、非公開の、および時刻と日付のみが公開される予定と仕事を、公開されているものと同様に扱います。
次の表は、アクセス制御用の ACL を設定または変更するための Calendar Server コマンド行ユーティリティーを示しています。
表 15–2 アクセス制御のためのコマンド行ユーティリティー
ユーティリティー |
説明 |
---|---|
特定のユーザーまたはリソースのカレンダの ACL を設定するときは、-a オプションを指定して create コマンドまたは modify コマンドを実行します。 |
|
Schema 1 モードで csresource を使用してリソースカレンダを作成している場合、リソースカレンダに ACL を設定するには、csresource ユーティリティーに -a オプションを指定して実行します。 |
|
csuser |
Schema 2 の commadmin ユーティリティーを使用して、ユーザーがカレンダを作成するときに使用するデフォルト ACL を変更します。 ユーザーがカレンダを作成するときに使用するデフォルトACL を変更するには、Schema 1 の csuser ユーティリティーに -a オプションを指定して実行します。 |
Delegated Administrator コンソールでアクセス権限を設定する場合は、「組織のプロパティー」ページ (または「新しい組織を作成」ウィザード) で「拡張権限を設定」ボタンをクリックすると、コンソールから管理できるアクセス権限のリストが表示されます。
ここで説明する内容は次のとおりです。
新しいカレンダを作成するには、cscal ユーティリティーの create コマンドを使用します。ユーザーまたはリソースのエントリは、LDAP ディレクトリ内にすでに存在している必要があります。LDAP ディレクトリへのユーザーやリソースの追加については、第 14 章「ユーザーとリソースの管理」を参照してください。
サイトで LDAP カレンダ検索データベース (CLD) プラグインを使用している場合、ユーザーまたはリソースのエントリの icsDWPHost LDAP 属性で指定されているのと同じバックエンドサーバー上で特定のユーザーまたはリソースのすべてのカレンダを作成する必要があります。別のバックエンドサーバーにカレンダを作成しようとすると、cscal ユーティリティーはエラーを返します。LDAP CLD プラグインについては、第 6 章「複数のマシンへのカレンダデータベースの分散の設定」を参照してください。
たとえば、jsmith というカレンダ ID (calid) を持つカレンダを新規作成するには、次のように実行します。
cscal -o jsmith -n JohnSmithCalendar create jsmith
それぞれの意味は次のとおりです。
-o jsmith は、新しいカレンダの一次所有者を指定します。
-n JohnSmithCalendar は、新しいカレンダに表示される名前を指定します。
デフォルトのアクセス制御設定は、ics.conf ファイルの calstore.calendar.default.acl によって定義されます。
John Smith が所有する Hobbies という表示名のカレンダを作成し、グループスケジュール機能のアクセス制御設定を適用するには、次のように実行します。
cscal -n Hobbies -o jsmith create Personal
それぞれの意味は次のとおりです。
-n Hobbies は、カレンダに表示される名前を指定します。
-o jsmith は、一次所有者のユーザー ID を指定します。
Personal は、カレンダ ID (calid) の 2 番目の部分として使用されます。次に例を示します。jsmith:Personal
次の例は、前の例に似たカレンダを新規作成しますが、カレンダを sports というカテゴリに関連付け、複数のユーザーからの予約を有効にして Ron Jones というもう一人の所有者を指定します。
cscal -n Hobbies -o jsmith -g sports -k yes -y rjones create Personal
それぞれの意味は次のとおりです。
-g sports は、カレンダを sports というカテゴリに関連付けます。
-y rjones は、カレンダのもう一人の所有者を指定します。
-k yes は、複数のユーザーからの予約を有効にします。(-k no は、複数のユーザーからの予約を無効にする)
次の例は、前の例と似たカレンダを作成しますが、グループスケジュール機能のアクセス制御設定が適用されます。
cscal -n Hobbies -o jsmith -a "@@o^a^sfr^g" create Personal
ここで、-a "@@o^a^sfr^g" は、このカレンダのコンポーネントとカレンダの両方のプロパティーに対するグループスケジュール機能のスケジュール権限、空き/ 予定ありの設定権限、読み取りアクセス権限を、ほかの所有者に与えます。
リソースカレンダは、スケジューリングが可能な会議室、ノートパソコン、OHP、その他の機器などに関連付けられます。リソースカレンダにはアクセス制御リストが必要です。
表 15–3 に示すように、ics.conf ファイルの 2 つの設定用パラメータがリソースカレンダに適用されます。
resource.default.acl – デフォルトのアクセス制御リスト
resource.allow.doublebook– 複数のユーザーからの予約を許可または禁止するパラメータ
ユーザーのカレンダ側では複数のユーザーが予約を希望しても、リソース側では複数のユーザーの予約はおそらく好ましくないものです。したがって、デフォルト値は "no" です。ただし、必要に応じて "yes" に変更できます。
表 15–3 に示すように、これらのパラメータのデフォルト値を変更するには、ics.conf ファイルを編集します。デフォルト値の変更は、新しいリソースカレンダだけに適用されます。 既存のリソースの値は変更されません。
Schema 1 の場合は、Calendar Server ユーティリティー cscal を使用して、既存のリソースカレンダの値を変更します。csresource ユーティリティーには modify コマンドはありません。
Schema 2 の場合は、Delegated Administrator ユーティリティーコマンド commadmin resource modify を使用します。Delegated Administrator コンソールでは、カレンダリソースについてのこれらの値を変更することはできません。
Calendar Server の通知ソフトウェアは、リソースに通知を送信するようにプログラミングされていません。 通知を受け取るのはユーザーだけです。
パラメータ |
説明とデフォルト値 |
---|---|
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 オプションを指定します。 |
Calendar Server では、リソースカレンダの自動プロビジョニングはサポートしていません。サイトに必要なリソースごとに、次の方法を使用する必要があります。
Schema 1 の場合、Calendar Server Utility コマンド csresource create を使用します。
このユーティリティーは、リソースの LDAP エントリとデフォルトカレンダの両方を作成します。
たとえば、カレンダ ID が aud100、表示名が Auditorium (LDAP cn 属性)、およびデフォルトの設定を持つリソース LDAP エントリを作成するには、次のコマンドを実行します。
csresource -m aud100@siroe.com -c aud100 create Auditorium
Schema 2 の場合、Delegated Administrator Utility コマンド commadmin resource create の組み合わせを使用して、LDAP エントリを作成します。次に Calendar Server Utility コマンド csresource create を使用してデフォルトカレンダを作成します。
Schema 2 の場合、Delegated Administration Console を使用してリソース LDAP エントリを作成します。次に、Calendar Server Utility コマンド csresource create を使用してデフォルトカレンダを作成します。
Delegated Administration Console で LDAP リソースを作成するには、組織リストからこのリソースを配置する組織を選択します。該当する組織の「カレンダーリソース」ページで、「新規」をクリックして「新規カレンダーリソースを作成」ウィザードを起動します。
リソースの LDAP エントリがすでに存在する場合、csresource ではカレンダのみが作成されます。LDAP エントリは重複して作成されません。
Delegated Administrator Utility については、『Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide』を参照してください。
Delegated Administrator Console については、オンラインヘルプを参照してください。
csresource については、付録 D 「Calendar Server のコマンド行ユーティリティーのリファレンス」 を参照してください。
デフォルトでは、Calendar Server はリソースカレンダでの複数のユーザーからの予約 (resource.allow.doublebook パラメータ) を許可しません。このデフォルト設定は、部屋や装置などのリソースで予定の競合が生じることを防ぎます。ただし、リソースカレンダでの複数のユーザーからの予約を可能にするには、カレンダの作成時に csresource -k オプションを “yes” に設定します。
次のコマンドは、リソースの LDAP エントリとカレンダを作成しますが、-k オプションによってカレンダでの複数のユーザーからの予約が許可され、-o オプションによってカレンダの 所有者が bkamdar に設定されます。また、-y オプションによってもう一人の所有者が jsmith に設定されます。
csresource -m aud100@siroe.com -c aud100 -k yes -o bkamdar -y jsmith create Auditorium
特定のリソースの予定を指定できるユーザーを制御するには、リソースカレンダに対して書き込みアクセス権を持つユーザーを制限してください。たとえば、会議室の予定設定や機器の使用予約を特定のユーザーに限定することができます。
リソースカレンダの所有者を指定しない場合、ics.conf ファイルの service.admin.calmaster.userid パラメータの値が適用されます。
ユーザーカレンダの作成が完了すると、「cscal」 ユーティリティーを使用して次の管理作業を実行できます。
すべてのカレンダ、あるユーザーが所有するすべてのカレンダ、または特定のカレンダのプロパティーを表示するには、cscal ユーティリティーの list コマンドを使用します。
たとえば、カレンダデータベース内のすべてのカレンダを表示するには、次のように実行します。
cscal list
jsmith が所有するすべてのカレンダを表示するには、次のように実行します。
cscal -o jsmith list
カレンダ ID が jsmith:meetings のカレンダのすべてのプロパティーを表示するには、次のように実行します。
cscal -v list jsmith:meetings
Calendar Server から 1 つ以上のカレンダを削除するには、cscal ユーティリティーの delete コマンドを使用します。このユーティリティーはカレンダを削除しますが、ディレクトリサーバーからユーザーを削除することはありません。
delete コマンドはすべてのカレンダ情報をカレンダデータベースから削除します。実行した処理を取り消すことはできません。カレンダを削除すると、それを復元できるのはカレンダデータがバックアップされている場合だけです。詳細は、第 17 章「Calendar Server データのバックアップと復元」を参照してください。
cscal ユーティリティーを使用して、1 つのカレンダまたは複数のカレンダを削除できます。
たとえば、jsmith:meetings というカレンダ ID を持つカレンダを削除するには、次のように実行します。
cscal delete jsmith:meetings
一次所有者が jsmith のすべてのカレンダを削除するには、次のように実行します。
cscal -o jsmith delete
Calendar Server Utility コマンド csuser delete、あるいは Delegated Administrator Console または Utility を使用して 1 つ以上のユーザーを削除した場合、そのユーザーが所有していたカレンダがまだデータベース内に存在している可能性があります。
ユーザーのカレンダを消去するには、次の 2 つの方法があります。使用する方法は、ユーザーを削除するのに使用したツールにより異なります。
csuser ユーティリティーは、LDAP ディレクトリからユーザーを消去して、ユーザーのデフォルトのカレンダを消去しますが、ユーザーが所有していたその他のカレンダは消去しません。cscal を使用してこれらのカレンダを消去する方法については、「csuser を使用して削除されたユーザーのすべてのカレンダを消去するには」を参照してください。
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 の使用方法については、オンラインヘルプを参照してください。
削除された所有者の uid のすべてのカレンダを検索するには、cscal list を実行します。
cscal -o owner list
所有者のすべてのカレンダを消去するには、cscal を使用します。
cscal -o owner delete
csuser list を再実行して、すべてのカレンダが消去されていることを確認します。
commadmin を使用してユーザーを「削除」としてマークし、ユーザーの LDAP エントリが削除されている場合は、この手順を使用します。
Delegated Administrator はカレンダを消去しません。Delegated Administrator によって「削除」とマークされたユーザーのすべてのカレンダを消去するには、csclean ユーティリティーを使用します。
csclean を使用して、「削除」とマークされているがまだ削除されていないユーザーのすべてのカレンダを消去します。
たとえば、過去 10 日間で sesta.com ドメ イン内の「削除」とマークされたユーザーのすべてのカレンダを消去するには、次の コマンドを実行します。
csclean -g 10 clean sesta.com
ユーザーが LDAP から削除されている場合は、cscal を使用してください。
手順については、「csuser を使用して削除されたユーザーのすべてのカレンダを消去するには」を参照してください。
カレンダを有効化してユーザーがカレンダにアクセスできるようにするときは、cscal ユーティリティーの enable コマンドを使用します。
たとえば、デフォルト設定を適用した jsmith:meetings カレンダを有効化するには、次のように実行します。
cscal enable jsmith:meetings
jsmith:meetings カレンダを有効化し、複数のユーザーからの予約を禁止するには、次のように実行します。
cscal -k no enable jsmith:meetings
ユーザーがカレンダにアクセスできないようにするには、cscal ユーティリティーの disable コマンドを使用します。disable コマンドはユーザーによるカレンダへのアクセスを禁止しますが、カレンダデータベースから情報を削除するわけではありません。
たとえば、ユーザーが jsmith:meetings にアクセスできないようにするには、次のように実行します。
cscal disable jsmith:meetings
カレンダのプロパティーを変更するには、cscal ユーティリティーの modify コマンドを使用します。
たとえば、AllAdmins のグループスケジュール機能のアクセス制御設定を変更し、もう一人の所有者として RJones を指定するには、次のように実行します。
cscal -a "@@o^c^wd^g" -y RJones modify AllAdmins
それぞれの意味は次のとおりです。
-a "@@o^c^wd^g" は、AllAdmins のコンポーネント (予定および作業) に対する書き込みと削除のアクセス権を所有者に付与します。
-y RJones は、このユーザー ID をもう一人の所有者に指定します。
カレンダからプロパティー値を消去するには、cscal ユーティリティーの modify コマンドを使用し、オプションの値を 2 つの二重引用符 ("") で指定することで対象となるオプションを指定します。
たとえば、jsmith:meetings から説明を消去するには、次のように実行します。
cscal -d "" modify jsmith:meetings
jsmith:meetings からすべてのカテゴリを消去するには、次のように実行します。
cscal -g "" modify jsmith:meetings
jsmith:meetings からその他の所有者を消去するには、次のように実行します。
cscal -y "" modify jsmith:meetings
ユーザーのデフォルトカレンダが Communications Express の「現在のカレンダ」ドロップダウンリストには表示されないが、データベースには存在する場合、ユーザーの LDAP エントリの次の属性を更新することで、カレンダを復元できます。
icsCalendar:default_calid
icsSubscribed:default_calid
ここで、default_calid はユーザーのデフォルトカレンダの ID (calid) です。
Schema 2 の場合は、次のいずれかの方法を使用して属性を更新します。
ldapmodify Directory Server ユーティリティーを使用します。
Calendar Server Utility の csuser reset コマンドを使用します。
Delegated Administrator Utility の commadmin user modify コマンドを使用します。
Delegated Administrator Console を使用して、「ユーザーのプロパティー」ページを編集してデフォルトのカレンダ名を追加します。
Schema 1 の場合は、csattribute add コマンドを使用して属性を更新できます。
あるバックエンドサーバーから別のバックエンドサーバーにユーザーカレンダを移動するには、次の手順を実行します。
元のサーバーで、「csuser」 ユーティリティーを実行してカレンダユーザーを無効にします。たとえば、ユーザー ID と calid が bkamdar のユーザーを無効にするには、次のように実行します。
csuser disable bkamdar |
元のサーバーで、「csexport」 ユーティリティーを実行してカレンダデータベースからファイルにユーザーの各カレンダをエクスポートします。次に例を示します。
csexport -c bkamdar calendar bkamdar.ics |
エクスポートしたカレンダファイル (*.ics) を元のサーバーから新しいサーバーにコピーします。
新しいサーバーで、エクスポートされた各カレンダに対して、「csimport」 ユーティリティーを実行してファイルからカレンダデータベースにカレンダをインポートします。次に例を示します。
csimport -c bkamdar calendar bkamdar.ics |
LDAP ディレクトリサーバーで 「csattribute」 ユーティリティーを実行し、カレンダ所有者の icsDWPHost LDAP 属性が新しいバックエンドサーバーをポイントするように変更します。属性を変更するには、まず属性を削除し、新しい値を持つ属性を追加します。たとえば、新しいサーバー名を sesta.com に設定するには、次のように実行します。
csattribute -a icsDWPHost delete bkamdar csattribute -a icsDWPHost=sesta.com add bkamdar |
新しいサーバーで、「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 を再起動します。
リソースカレンダの作成後は、csresource ユーティリティーを使用して管理します。リソースカレンダを管理する手順は次のとおりです。
リソースカレンダを表示するには、csresource ユーティリティーの list コマンドを使用します。
たとえば、Calendar Server のすべてのリソースカレンダと、それに対応する LDAP 属性を表示するには、次のように実行します。
csresource list
Auditorium という特定のリソースカレンダのすべての LDAP 属性を表示するには、次のように実行します。
csresource -v list Auditorium
リソースカレンダを変更するには、「cscal」 ユーティリティーの modify コマンドを使用します。csresource には modify コマンドはありません。
たとえば、Auditorium というリソースカレンダに所有者として tchang を設定し、もう一人の所有者として mwong を設定するには、次のように実行します。
cscal -o tchang -y mwong modify aud100
この例では、cscal ユーティリティーはカレンダ名 (Auditorium) ではなく、calid (aud100) を必要とします。
ユーザーが予定をスケジュール設定できないようにするには、リソースカレンダを無効化する必要があります。たとえば、改修中で会議室を利用できない場合や、OHP が修理中の場合などがこれに該当します。
リソースカレンダの無効化と有効化には、csresource ユーティリティーの enable コマンドまたは disable コマンドを使用します。
たとえば、Auditorium というリソースカレンダを無効化するには、次のように実行します。
csresource disable Auditorium
あとからリソースカレンダを有効な状態に戻すには、次のように実行します。
csresource enable Auditorium
リソースカレンダを削除するには、csresource ユーティリティーの delete コマンドを使用します。
たとえば、Auditorium というリソースカレンダを削除するには、次のように実行します。
csresource delete Auditorium
Calendar Server は次のメッセージを表示します。
Do you really want to delete this resource (y/n)?
カレンダを削除するときは「y」を入力し、処理をキャンセルするときは「n」を入力します。
「y」を入力すると、Calendar Server はカレンダを削除し、削除が完了したことを示すメッセージを表示します。
あるバックエンドサーバーから別のバックエンドサーバーにユーザーカレンダまたはリソースカレンダを移動するには、次の手順を実行します。
元のサーバーで、「csresource」 ユーティリティーを実行してカレンダリソースを無効にします。たとえば、Auditorium という共通名を持つリソースを無効化するには、次のように実行します。
csresource disable Auditorium |
元のサーバーで、「csexport」 ユーティリティーを実行してカレンダデータベースからファイルに各リソースカレンダをエクスポートします。次に例を示します。
csexport -c aud100 calendar aud100.ics |
エクスポートしたカレンダファイル (*.ics) を元のサーバーから新しいサーバーにコピーします。
新しいサーバーで、エクスポートされた各カレンダに対して、「csimport」 ユーティリティーを実行してファイルからカレンダデータベースにカレンダをインポートします。次に例を示します。
csimport -c bkamdar calendar bkamdar.ics |
LDAP ディレクトリサーバーで 「csattribute」 ユーティリティーを実行し、カレンダ所有者の icsDWPHost LDAP 属性が新しいバックエンドサーバーをポイントするように変更します。属性を変更するには、まず属性を削除し、新しい値を持つ属性を追加します。たとえば、新しいサーバー名を sesta.com に設定するには、次のように実行します。
csattribute -a icsDWPHost delete bkamdar csattribute -a icsDWPHost=sesta.com add bkamdar |
新しいサーバーで、「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 を再起動します。
各カレンダに対する読み取りアクセスが許可されている場合は、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/?calid=jsmith@sesta;jdoe@siroe.com
calid が overhead_projector10 の OHP のリソースカレンダへのリンクは、次のようになります。
http://calendar.sesta.com:8080/uwc/?calid=overhead_projector10
カレンダデータをファイルにエクスポートしたり、ファイルからインポートしたりするには、csexport ユーティリティーと csimport ユーティリティーを使用します。サポートされているカレンダデータの形式は、iCalendar (.ics) と XML (.xml) です。
csexport と csimport は、Calendar Server がインストールされているマシンでローカルに実行する必要があります。Calendar Server は稼動中でも停止していてもかまいません。
csexport ユーティリティーを使用して作成したファイルからカレンダデータをインポートするときは、csimport を使用します。保存されているインポートファイルの形式は、そのファイルの拡張子 (.ics または .xml) で示されます。
たとえば、カレンダ ID (calid) が jsmithcal のカレンダに iCalendar 形式 (text/calendar MIME) で保存された jsmith.ics というファイルからデータをインポートするには、次のように実行します。
csimport -c jsmithcal calendar jsmith.ics
この jsmithcal カレンダに XML 形式 (text/xml MIME) で保存された jsmith.xml というファイルからデータをインポートするには、次のように実行します。
csimport -c jsmithcal calendar jsmith.xml
カレンダデータをファイルにエクスポートするときは、csexport を使用します。ファイルの形式は、出力ファイルに指定する拡張子 (.ics または .xml) によって決定されます。
たとえば、カレンダ ID (calid) が jsmithcal のカレンダを iCalendar 形式 (text/calendar MIME) の jsmith.ics というファイルにエクスポートするには、次のように実行します。
csexport -c jsmithcal calendar jsmith.ics
この jsmithcal カレンダを XML 形式 (text/xml MIME) の jsmith.xml というファイルにエクスポートするには、次のように実行します。
csexport -c jsmithcal calendar jsmith.xml
Calendar Server では、複数のディレクトリに多くのデータベースファイルを保存します。第 10 章「自動バックアップ (csstored) の設定」で説明している自動バックアッププロセスを実装するか、または独自のバックアップシステムを実装して、データベースファイルを保護する必要があります。csdb ユーティリティーを使用すると、データベースファイルを管理できます。
この章では、csdb を使用した Calendar Server データベースの管理方法について、次の項目を説明します。
データベースファイルを管理するには、Calendar Server ユーティリティーの csdb を使用します。ここで説明する内容は次のとおりです。
カレンダデータベースのユーティリティー、csdb では、データベースファイルを 3 つの論理データベースとして扱います。
caldb は、データベースディレクトリにあるすべての .db ファイルと _db.* ファイルで構成されます。カレンダデータベースファイルのデフォルトの場所は、次のとおりです (cld_cache および ldap_cache サブディレクトリも同様)。
/var/opt/SUNWics5/csdb
Calendar Server の設定プログラム (csconfigurator.sh) を実行するときに、別のディレクトリを指定することもできます。設定プログラムについては、第 3 章「Calendar Server 設定プログラム (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 章「削除ログデータベースの管理」も参照してください。 |
セッションデータベースは、次のディレクトリにあるすべてのファイルで構成されます。/opt/SUNWics5/cal/lib/admin/session/ および /opt/SUNWics5/cal/lib/http/session/
統計情報データベースは、counter ディレクトリにあるすべてのファイルで構成されます。
/opt/SUNWics5/cal/lib/counter/
csdb ユーティリティーの -t オプションを使用すると、ターゲットデータベースを指定できます。
-t caldb: カレンダデータベース
-t sessdb: セッションデータベース
-t statdb: 統計情報データベース
-t オプションを指定しない場合、csdb は 3 種類すべてのデータベースを対象に動作します。 ただし、check と rebuild の対象はカレンダデータベースだけです。
ここでは、「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 コマンドを実行して、破損したデータベースを再構築することもできます。
破損してしまったカレンダデータベース (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 コマンドを実行します。
./csdb rebuild db_0629
Then check for corruption. If this backup copy is also corrupt, then run rebuild on the next backup copy.
./csdb rebuild db_0615
Then check for corruption. If this backup copy is also corrupt, then run rebuild on the next backup copy.
./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) ファイルを rebuild_db ディレクトリから運用データベースにコピーします。
破損したデータベースのディレクトリに共有ファイル (__db.*) が含まれていた場合は、それも運用ディレクトリに移動します。
Calendar Server を再起動します。
サイトにグループスケジューリングを実装している場合は、再構築に 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 を再起動します。
出力サンプルでは、予定と仕事のデータベースがそれぞれ 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 |
カレンダデータベースを削除するには、csdb ユーティリティーの delete コマンドを使用します。Calendar Server は停止している必要があります。
ターゲットデータベース (caldb、sessdb、statdb) を指定するときは、-t オプションを指定します。 指定しない場合、csdb は 3 種類すべてのデータベースを削除します。
たとえば、カレンダデータベースを削除するときは、次のように実行します。
csdb -t caldb delete
データベースを削除する前に、csdb ユーティリティーは警告を出力します。
Calendar Server により提供される自動バックアップ機能の使用を選択していない場合は、csstored を使用して、バックアップ手順を実装し、データを保護する必要があります。この章では、手動バックアップを実行して、カレンダデータベースファイルを復元するための Calendar Server およびほかの Sun ツールの使用方法を説明します。
/var/opt/SUNWics5/csdb ディレクトリに格納されている Calendar Server データのバックアップと復元には、次のコマンド行ユーティリティーを使用します。
csbackup は、カレンダデータベース、指定したカレンダ、ユーザーのデフォルトのカレンダをバックアップします。バックアップ対象のディレクトリは、ランタイムユーザー (icsuser) が所有する必要があります。そうでない場合、データの復元を試みるとエラーメッセージが出力されます。
csrestore は、csbackup で生成したカレンダデータベース、個々のカレンダ、ユーザーのデフォルトカレンダを復元します。
Berkeley データベースのツール (db_recover など) を使用する既存のカスタムスクリプトがある場合、Calendar Server 6 以降にアップグレードすると、ツールが機能しない場合があります。Calendar Server 2004Q4 以前は、ツールはスタティックライブラリでコンパイルされていました。Calendar Server 6 以降、ツールはダイナミックライブラリでコンパイルされるようになりました。
この変更に対応するには、カスタムスクリプトを次のように変更してダイナミックリンクライブラリを使用可能にする必要があります。大域変数 LD_LIBRARY_PATH をダイナミックライブラリの名前 (libdb-4.2.so) に変更します。
この章で説明する内容は次のとおりです。
Calendar Server 2 のデータには最新製品との互換性がありません。データを喪失する可能性があるので、Calendar Server 2 の backup ユーティリティーでバックアップしたカレンダデータを復元しないでください。
最新バージョンに移行する必要のある Calendar Server 2 のカレンダデータがある場合は、テクニカルサポートに問い合わせて適切な移行ユーティリティーを入手してください。
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 というカレンダを iCalendar 形式 (text/calendar MIME) の jsmith.ics というファイルとして backupdir ディレクトリ内にバックアップするには、次のように実行します。
csbackup -c jsmithcal calendar backupdir/jsmith.ics |
また、jsmithcal というカレンダを XML 形式 (text/XML MIME) の jsmith.xml というファイルとして backupdir ディレクトリ内にバックアップするには、次のように実行します。
csbackup -c jsmithcal calendar backupdir/jsmith.xml |
データベースの所有者 (icsuser) としてログインします。
ユーザーのデフォルトカレンダを iCalendar 形式または XML 形式のテキストファイルにバックアップするには、csbackup ユーティリティーの def cal コマンドを使用します。ファイルの形式は、出力ファイルに指定する拡張子 (.ics または .xml) によって決定されます。
たとえば、jsmith というユーザーのデフォルトカレンダを jsmith.ics という iCalendar 形式 (text/calendar MIME) のファイルにバックアップするには、次のように実行します。
csbackup -a jsmith defcal backupdir/jsmith.ics |
また、jsmith のデフォルトカレンダを jsmith.xml という XML 形式 (text/xml MIME) のファイルにバックアップするには、次のように実行します。
csbackup -a jsmith defcal backupdir/jsmith.xml |
csrestore は、csbackup で生成したカレンダデータベース、個々のカレンダ、ユーザーのデフォルトカレンダを復元します。csrestore ユーティリティーを Calendar Server がインストールされているローカルマシンで実行し、最初に Calendar Server を停止する必要があります。データベースのバックアップ時は Calendar Server は稼動していてもかまいません。
ここで説明する内容は次のとおりです。
データベースの所有者 (icsuser) としてログインします。
csbackup ユーティリティーで作成したバックアップディレクトリからカレンダデータベースを復元するときは、csrestore ユーティリティーの database コマンドを使用します。
たとえば、backupdir というバックアップディレクトリに保存されているカレンダデータベースを復元するには、次のように実行します。
csrestore database backupdir |
データベースの所有者 (icsuser) としてログインします。
csbackup ユーティリティーで作成したバックアップディレクトリに保存されているデータベースから特定のカレンダを復元するときは、-c オプションを指定して csrestore ユーティリティーの database コマンドを実行します。
たとえば、backupdir というバックアップデータベースディレクトリから jsmithcal というカレンダを復元するときは、次のように実行します。
csrestore -c jsmithcal calendar backupdir |
データベースの所有者 (icsuser) としてログインします。
csbackup ユーティリティーで作成したバックアップファイルから特定のカレンダを復元するときは、-c オプションを指定して csrestore ユーティリティーの calendar コマンドを実行します。
保存されているカレンダファイルの形式は、そのファイルの拡張子 (.ics または .xml) で示されます。
たとえば、iCalendar 形式 (text/calendar MIME) の jsmith.ics というファイルとして backupdir ディレクトリに保存されている jsmithcal というカレンダを復元するには、次のように実行します。
csrestore -c jsmithcal calendar backupdir/jsmith.ics |
また、XML 形式 (text/calendar MIME) の jsmith.xml というファイルとして bcakupdir ディレクトリに保存されている jsmithcal というカレンダを復元するには、次のように実行します。
csrestore -c jsmithcal calendar backupdir/jsmith.xml |
データベースの所有者 (icsuser) としてログインします。
csbackup ユーティリティーでバックアップファイルに保存したユーザーのデフォルトカレンダを復元するには、csrestore ユーティリティーの defcal コマンドを使用します。
保存されているカレンダファイルの形式は、そのファイルの拡張子 (.ics または .xml) で示されます。
たとえば、iCalendar 形式 (text/calendar MIME) の jsmith.ics というファイルとして backupdir ディレクトリに保存されている、jsmith というユーザーのデフォルトカレンダを復元するには、次のように実行します。
csrestore -a jsmith defcal backupdir/jsmith.ics |
また、XML 形式 (text/xml MIME) の jsmith.xml というファイルとして backupdir ディレクトリに保存されている、jsmith というユーザーのデフォルトカレンダを復元するには、次のように実行します。
csrestore -a jsmith defcal backupdir/jsmith.xml |
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 で入手できます。
ここで説明する内容は次のとおりです。
「Sun StorEdge Enterprise Backup ソフトウェアまたは Legato Networker を使用して Calendar Server データをバックアップするには」
「Sun StorEdge Enterprise Backup ソフトウェアまたは Legato Networker を使用して Calendar Server データを復元するには」
/opt/SUNWics5/cal/sbin ディレクトリには、Sun StorEdge または Legato バックアップソフトウェアを使用する上で必要となる次のファイルが格納されています。
Calendar Server ASM (Application Specific Module)。ASM は、Sun StorEdge または Legato バックアップソフトウェアがデータをバックアップまたは復元するときに呼び出されるプログラムです。
csbackup ユーティリティーを呼び出すスクリプト。
csrestore ユーティリティーを呼び出すスクリプト。
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 コマンド行ユーティリティーが実行されるようにします。
Calendar Server データを復元するには、次の手順を実行します。
Sun StorEdge Enterprise Backup ソフトウェアの nwrestore 機能または recover コマンドを使用して、バックアップされているカレンダ情報を復元します。
nwrestore を使用した場合は次のメッセージが出力されます。
"File already exists. Do you want to overwrite, skip, backup, or rename?" |
overwrite を選択します。
このメッセージは、バックアップツリーが単なるディレクトリ階層であるために表示されます。つまり、このツリーは空のファイルだけを含み、この状態は変化しません。
Calendar Server には、削除された予定や仕事 (作業) を格納するための削除ログデータベース (ics50deletelog.db) が用意されています。
初期のリリースでは、Calendar Server は削除された予定や作業をデータベースに維持していませんでした。どのコンポーネントが削除されたのかを特定するには、ユーザーは予定または仕事 (作業) の一意の識別子 (uid) または定期予定 ID (rid) を必ず保存しなければなりません。この制限は、WCAP コマンドを使用してクライアントユーザーインタフェース (UI) を作成するインストールに直接影響しました。この制限を解決するため、削除ログデータベースが作成されました。
この章で説明する内容は次のとおりです。
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 が含まれます。
削除ログデータベースからエントリを返すには、展開モードまたは圧縮モードの 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_lasmod WCAP コマンドを使用します。fetch_deletedcomponents コマンドは、fetchcomponents_by_lasmod コマンドと組み合わせて使用する必要があります。
WCAP コマンドについては、『Sun Java System Calendar Server 6 2005Q4 Developer’s Guide』を参照してください。
Calendar Server は、「削除ログデータベースの自動破棄」と 「削除ログデータベースの手動破棄」の両方をサポートしています。
削除ログデータベースのエントリを Calendar Server に自動破棄させることができます。
次の表は、自動破棄を制御する ics.conf ファイルのパラメータを示しています。
表 18–1 削除ログデータベースの自動破棄に適用される設定パラメータ
パラメータ |
説明 |
---|---|
削除ログデータベース (ics50deletelog.db) エントリの自動破棄を有効化 (yes) または無効化 (no) します。 デフォルトは "no" です。 |
|
削除ログデータベース (ics50deletelog.db) のエントリを自動的に破棄する間隔を秒単位で指定します。 デフォルトは 60 秒です。 |
|
削除ログデータベース (ics50deletelog.db) から自動的に破棄するエントリの存続時間を秒単位で指定します。 デフォルトは 86400 秒 (1 日) です。 |
たとえば、5 分 (600 秒) おきに、2 日 (172800 秒) を経過した削除ログデータベースのエントリを Calendar Server に自動破棄させるには、「削除ログデータベースの自動破棄」のパラメータを次のように設定します。
service.admin.purge.deletelog="yes" caldb.berkeleydb.purge.deletelog.interval=600 caldb.berkeleydb.purge.deletelog.beforetime=172800
パラメータの設定が完了したら、新しい値が適用されるように Calendar Server を再起動します。
削除ログデータベース (ics50deletelog.db) のエントリを手動で破棄するには、cspurge ユーティリティーを使用します。
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
詳細は、「cspurge」を参照してください。
次の表は、削除ログデータベース (ics50deletelog.db) をサポートする Calendar Server ユーティリティーを示しています。
表 18–2 削除ログデータベースをサポートするユーティリティー
ユーティリティー |
説明 |
---|---|
cspurge |
削除ログデータベースのエントリを手動で破棄します。 |
csbackup と csrestore |
削除ログデータベースのバックアップと復元をサポートします。 |
csstats |
削除ログデータベースの統計情報をレポートします。 |
csdb |
削除ログデータベースのチェック、復元、再構築をサポートします。 |
cscomponents |
削除ログデータベースのエントリの数をリスト表示します (読み取り専用情報)。 |
これらのユーティリティーの構文など、詳細は 付録 D 「Calendar Server のコマンド行ユーティリティーのリファレンス」 を参照してください。
この付録では、Calendar Server がタイムゾーンを定義、処理する方法について、次の項目を説明します。
タイムゾーンのプロパティーとパラメータについては、次の Web サイトで『RFC 2445, Internet Calendaring and Scheduling Core Object Specification (iCalendar)』を参照してください。
http://www.ietf.org/rfc/rfc2445.txt
timezones.ics ファイルには、Calendar Server がサポートするタイムゾーン表記が定義されています。このファイルは、次のディレクトリに格納されています。
cal_svr_base/SUNWics5/cal/data
起動時に 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 2005Q4 Developer’s Guide』を参照してください。
次の例は、timezones.ics ファイル内の America/Los_Angeles タイムゾーンの表記を示しています。
BEGIN:VTIMEZONE TZID:America/Los_Angeles BEGIN:STANDARD DTSTART:19671025T020000 RRULE:FREQ=YEARLY;BYDAY=-1SU;BYMONTH=10 TZOFFSETFROM:-0700 TZOFFSETTO:-0800 TZNAME:PST END:STANDARD BEGIN:DAYLIGHT DTSTART:19870405T020000 RRULE:FREQ=YEARLY;BYDAY=1SU;BYMONTH=4 TZOFFSETFROM:-0800 TZOFFSETTO:-0700 TZNAME:PDT END:DAYLIGHT X-NSCP-TZCROSS: 19880403T100000Z;19881030T090000Z;19890402T100000Z;19891029T090000Z; 19900401T100000Z;19901028T090000Z;19910407T100000Z;19911027T090000Z; 19920405T100000Z;19921025T090000Z;19930404T100000Z;19931031T090000Z; 19940403T100000Z;19941030T090000Z;19950402T100000Z;19951029T090000Z; 19960407T100000Z;19961027T090000Z;19970406T100000Z;19971026T090000Z; 19980405T100000Z;19981025T090000Z;19990404T100000Z;19991031T090000Z; 20000402T100000Z;20001029T090000Z;20010401T100000Z;20011028T090000Z; 20020407T100000Z;20021027T090000Z;20030406T100000Z;20031026T090000Z; 20040404T100000Z;20041031T090000Z;20050403T100000Z;20051030T090000Z; 20060402T100000Z;20061029T090000Z;20070401T100000Z;20071028T090000Z; 20080406T100000Z;20081026T090000Z;20090405T100000Z;20091025T090000Z; 20100404T100000Z;20101031T090000Z;20110403T100000Z;20111030T090000Z; 20120401T100000Z;20121028T090000Z;20130407T100000Z;20131027T090000Z; 20140406T100000Z;20141026T090000Z;20150405T100000Z;20151025T090000Z; 20160403T100000Z;20161030T090000Z;20170402T100000Z;20171029T090000Z; 20180401T100000Z;20181028T090000Z;20190407T100000Z;20191027T090000Z; 20200405T100000Z;20201025T090000Z;20210404T100000Z;20211031T090000Z; 20220403T100000Z;20221030T090000Z;20230402T100000Z;20231029T090000Z; 20240407T100000Z;20241027T090000Z;20250406T100000Z;20251026T090000Z; 20260405T100000Z;20261025T090000Z;20270404T100000Z;20271031T090000Z; 20280402T100000Z;20281029T090000Z;20290401T100000Z;20291028T090000Z; 20300407T100000Z;20301027T090000Z;20310406T100000Z;20311026T090000Z; 20320404T100000Z;20321031T090000Z;20330403T100000Z;20331030T090000Z; 20340402T100000Z;20341029T090000Z;20350401T100000Z;20351028T090000Z; 20360406T100000Z;20361026T090000Z;20370405T100000Z;20371025T090000Z; 20360406T120000Z;20361026T110000Z;20370405T120000Z;20371025T110000Z END:VTIMEZONE |
ここで説明する内容は次のとおりです。
ここでは、Communications Express ユーザーインタフェースで使用できるように Calendar Server に新しいタイムゾーンを追加する方法について説明します。たとえば、America/Miami 用のタイムゾーンの追加が必要になる場合があります。
新しいタイムゾーンを追加するもっとも簡単な方法は、次の手順で説明する各ファイルで、追加するタイムゾーンに似たタイムゾーンエントリをコピーし、それを編集する方法です。たとえば、America/Miami 用のタイムゾーンを追加するのであれば、各ファイルで America/New_York のタイムゾーンエントリをコピーして編集します。
次のファイルに新しいタイムゾーン用のタイムゾーンブロックを追加します。
cal_svr_base/SUNWics5/cal/data/timezones.ics |
この場合も、新しいタイムゾーンブロックを追加するもっとも簡単な方法は、追加するタイムゾーンと夏時間 (DST) の時間差などが似ている既存のブロックをコピーする方法です。次に、追加するタイムゾーンに合わせて新しいタイムゾーンブロックに変更を加えます。追加するタイムゾーンに夏時間 (DST) が適用される場合は、それに似たブロックを探します。
次のファイルで getDisplayNameofTZID テンプレートを修正します。
cal_svr_base/SUNWics5/cal/html/language/i18n.xsl file |
この language には、サイトで使用する言語のディレクトリを指定します。たとえば、英語であれば en、フランス語であれば fr を指定します。
i18n.xsl ファイルに、次のような新しいエントリを追加します。
<xsl:when test="$tzid=’TimeZoneArea/ TimeZoneName’"TimeZoneArea/ TimeZoneName</xsl:when\> |
それぞれの意味は次のとおりです。
TimeZoneArea には地理的な領域を指定します (Africa、America、Asia、Atlantic、Australia、Europe、または Pacific)。
TimeZoneName には新しいタイムゾーンの名前を指定します。
次に例を示します。
<xsl:when test="$tzid='America/Miami'"\>America/Miami</xsl:when\> |
次の 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 |
それぞれのファイルに次の行を追加します。
<timezone type="TimeZoneType" tzid="TimeZoneArea/TimeZoneName" offset="offset"> |
それぞれの意味は次のとおりです。
TimeZoneType には、"americas"、"europeAfrica"、または "asiaPacific" を指定します。
TimeZoneArea と TimeZoneName は、「新しいタイムゾーンの追加」で定義しています。
offset には、新しいタイムゾーンが GMT と比較して何時間進んでいるか (+)、または遅れているか (-) を指定します。たとえば、新しいタイムゾーンが GMT から4 時間遅れている場合は、時間差として "-04:00" を指定します。
次に例を示します。
<timezone type="americas" tzid="America/Miami" offset="-05:00" daylightOffset="-04:00"> |
新しいタイムゾーンをユーザー設定のデフォルトタイムゾーンにするときは、次のファイルの timezone エントリを変更します。
cal_svr_base/SUNWics5/cal/html/default_user_prefs.xml |
新しいタイムゾーンが適用されるように、Calendar Server を停止し (稼動していた場合)、再起動します。
ここでは、既存のタイムゾーンを変更する方法について説明します。たとえば、「America/Phoenix」というタイムゾーン名から「US/Arizona」への変更が必要になる場合があります。
次のファイルで、変更するタイムゾーンのタイムゾーンブロックを変更します。
cal_svr_base/SUNWics5/cal/data/timezones.ics |
タイムゾーン名を変更するときは、TZID エントリの名前を変更します。
次のファイルで getDisplayNameofTZID テンプレートを修正します。
cal_svr_base/SUNWics5/cal/html/language/i18n.xsl file |
それぞれの意味は次のとおりです。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 |
これらのファイルのエントリについては、「新しいタイムゾーンの追加」を参照してください。
変更がユーザー設定のデフォルトタイムゾーンに影響するときは、次のファイルの “icsTimeZone” エントリを修正します。
cal_svr_base/SUNWics5/cal/html/default_user_prefs.xml |
タイムゾーンの変更が適用されるように、Calendar Server を停止し (稼動していた場合)、再起動します。
Calendar Server は、Sun Java System Instant Messaging 6.0 (以降) と統合され、カレンダの予定と作業に関するポップアップアラームを自動的に表示します。
この章で説明する内容は次のとおりです。
ここで説明する内容は次のとおりです。
ユーザーは、カレンダの今後公開される予定や作業の Instant Messenger ポップアップアラームを受信します。これらのポップアップアラームを有効にするには、次の 2 つを行う必要があります。
管理者は、Calendar Server および Instant Messaging サーバーを設定して、ポップアップ通知を許可する必要があります。
エンドユーザーは、予定通知システムでアラームを設定する Communications Express の「オプション」タブで電子メールアラームを指定する必要があります。
エンドユーザーは、Instant Messenger でカレンダリマインダを有効にする必要があります。
ポップアップを有効にすると、差し迫った予定や作業が近づくと、予定通知システムで設定されたアラームにより Calendar Server は電子メール通知を送信し、Instant Messaging はポップアップアラームを表示します。
Calendar Server 管理者は、エンドユーザーの電子メール通知またはポップアラームのいずれか一方、または両方を設定できます。たとえば、電子メールアラームを無効にするときは、ics.conf ファイルのパラメータを次のように設定します。
caldb.serveralarms.binary.enable= "no"
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 ポップアップアラームを生成し、メッセージに基づいてエンドユーザーのデスクトップに表示します。
ここでは、次の設定手順について説明します。
次の 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 ファイルにこれらのパラメータが存在しない場合は、追加します。
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 管理ガイド』を参照してください。
次の表に示す ics.conf パラメータに、示された値が設定されているかどうかを確認します。設定されていない場合や、パラメータをカスタマイズする場合は、次の手順を実行します。
設定を変更する権限を持つ管理者としてログインします。
/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
Calendar Server の予定と作業のポップアップアラームを受信するには、エンドユーザーは各自の Instant Messenger を次のように設定する必要があります。
メイン ウインドウで「ツール」メニューから「設定」を選択します。
「設定」ウィンドウで、「アラート」タブをクリックします。
「カレンダリマインダを表示」オプションにチェックマークを付けます。
「了解」をクリックします。
Calendar Server のパフォーマンスを向上させるには、次のオプション設定を検討します。
Calendar Server が LDAP ディレクトリサーバーにアクセスするときのパフォーマンスを向上させるには、LDAP 設定ファイルの次の属性にインデックスを追加します。
この属性は、カレンダユーザーまたはリソースのデフォルトカレンダの検索に使用されます。実在 (pres)、等価 (eq)、部分文字列 (sub) のいずれかのインデックスタイプを指定します。
この属性は、ユーザーが所有しているほかのカレンダの検索に使用されます。実在 (pres)、等価 (eq)、部分文字列 (sub) のいずれかのインデックスタイプを指定します。「DWP 環境でのカレンダ検索のパフォーマンス向上」も参照してください。
これらの属性は、ユーザーの一次電子メールアドレスと代替電子メールアドレスを指定します。「ユーザーとリソースの作成」および 「Calendar Server ユーティリティー (csuser enable)」も参照してください。
ディレクトリサーバーインデックスの追加方法については、次の Web サイトにある Directory Server のマニュアルを参照してください。
http://docs.sun.com/coll/1316.1
DWP 環境にある場合、つまり、複数のバックエンドサーバーにカレンダベースが分散している場合、カレンダデータベース内のカレンダの検索に非常に時間がかかる場合があります。最初に LDAP エントリを探し、カレンダが存在している DWP ホストで直接検索すると、時間を短縮できます。
ここで説明する内容は次のとおりです。
最初に LDAP ディレクトリ、次にカレンダデータベースを対象とするカレンダ検索を有効にするには、次の手順を実行します。
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 によるインデックス設定については、「属性のインデックス」を参照してください。
ディレクトリサーバーインデックスの追加方法については、次の Web サイトにある Directory Server のマニュアルを参照してください。
デフォルトでは、Calendar Server でのワイルドカード検索は無効になっています。つまり、グラフィカルユーザーインタフェース (GUI) を使用してカレンダを検索するとき、または、カスタムインタフェースで search_calprops.wcap を実行するときは、WCAP コマンドを使用して渡される検索文字列との完全一致を検索します。
ics.conf ファイルで次の行のコメントを外して (行頭の感嘆符 (“!”) を削除して) ワイルドカード検索を有効にしている場合は、パフォーマンスにマイナスの影響を与える可能性があります。
!service.calendarsearch.ldap.primaryownersearchfilter = "(&(|(uid=*%s*)(cn=*%s*))(objectclass=icsCalendarUser))"
パフォーマンスに与えるワイルドカードの影響を調べるには、行の先頭に感嘆符 (“!”) を挿入して行をもう一度コメントアウトします。
カレンダデータベースからカレンダにアクセスする前に、ユーザーのカレンダをどのバックエンドマシンに格納するかを決める必要があります。適切なバックエンドマシンを見つけるために、システムではユーザーエントリの LDAP ディレクトリを検索し、icsDWPHost 属性を取り出します。この検索は非常に時間がかかり、カレンダデータにアクセスするたびに実行する必要があります。すべてのユーザーセッションでは、データベースのアクセスが多数発生し、LDAP の検索も多くなります。時間を節約してパフォーマンスを向上させるには、次のように ics.conf ファイルを編集して CLD キャッシュを有効にします。
caldb.cld.cache.enable="yes"
LDAP データキャッシュは、ユーザー ID およびそれに関連する icsDWPHost 属性を格納します。LDAP でユーザーのエントリを検索する前に、システムは、キャッシュにそのユーザーの ID がないかどうかチェックします。キャッシュにユーザー ID があれば、そこに格納されている icsDWPHost 属性からバックエンドのホスト名を取り出します。キャッシュにユーザー ID がない場合、システムは LDAP 検索を実行して、ユーザー ID と属性を CLD キャッシュにコピーします。このあとは、キャッシュでユーザー ID が見つかるため、ユーザーのカレンダデータへのアクセスが速くなります。
LDAP データキャッシュが有効になっている場合は、ics.conf パラメータを使用してキャッシュを調整できます。それには、次の表に示すパラメータを 1 つ以上調整します。
デフォルトでは、LDAP データキャッシュが有効になっています。LDAP データキャッシュを無効にするには、次のように設定します。local.ldap.cache.enable="no"
パラメータ |
説明と値 |
---|---|
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 では、データキャッシュを無効にすることをお勧めします。
項目をキャッシュしておく時間、およびキャッシュのサイズを制御するいくつかのパラメータがあります。
キャッシュを調整するには、次の表に示すパラメータを 1 つ以上編集します。
表 21–2 LDAP SDK キャッシュを設定するための ics.conf パラメータ
パラメータ |
説明とデフォルト値 |
---|---|
このパラメータは現在実装されていません。ldap_cache ディレクトリの内容を手動で削除してから、Calendar Server を再起動する必要があります。 service.ldapmemcache に "yes" を指定した場合、このパラメータは項目をキャッシュしておける最大秒数の設定に使用されます。“0” を指定した場合、項目をキャッシュしておける時間に制限が適用されなくなります。デフォルトは “30” です。 |
|
service.ldapmemcache に "yes" を指定した場合、このパラメータを使用して、キャッシュに使用できるメモリーの最大容量をバイト単位で設定します。“0” を指定した場合、キャッシュ容量の制限は適用されなくなります。デフォルトは “131072” です。 |
ディスクに保存するバックアップ数と必要性とのバランスを取って、使用可能なディスク容量を越えないようにする必要があります。アーカイブとホットバックアップに必要なディスク容量を管理するために、さまざまな 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 |
アーカイブバックアップに使用されるディスク容量の割合 (パーセント) です。しきい値を超えた古いコピーの廃棄をトリガーします。 |
サーバーに複数の 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"
ロードバランスを無効にするには、ics.conf ファイルに service.loadbalancing パラメータを追加し、その値を “no” に指定します。次に、Calendar Server を再起動して変更を適用します。
Calendar Server のパフォーマンスは、さまざまな ics.conf パラメータのタイムアウト値を使用して調整できます。
次のタイプのタイムアウトが存在します。
ics.conf パラメータの編集については、「ics.conf 設定ファイルの編集」を参照してください。
次の表は、管理サービス (csadmind) が使用する、ics.conf ファイル内の Calendar Server タイムアウトパラメータを示しています。
表 21–4 管理サービス (csadmind) の HTTP タイムアウト値
パラメータ |
説明 |
---|---|
service.admin.idletimeout |
csadmind サービスがアイドル状態の HTTP 接続をタイムアウトにするまでの秒数を指定します。 デフォルトは 120 秒 (2 分) です。 |
service.admin.resourcetimeout |
csadmind サービスがリソースカレンダの HTTP セッションをタイムアウトにするまでの秒数を指定します。 デフォルトは 900 秒 (15 分) です。 |
service.admin.sessiontimeout |
csadmind サービスが HTTP セッションをタイムアウトにするまでの秒数を指定します。 デフォルトは 1800 秒 (30 分) です。 |
次の表は、エンドユーザーに適用される、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 分) です。 |
ics.conf ファイルの次のパラメータは、要求されたジョブを Calendar Server が GSE (グループスケジューリングエンジン) キューで走査するまでの時間を秒単位で指定します。
gse.belowthresholdtimeout="3"
キューに含まれるジョブが許容最大しきい値より多い場合、最後のスレッドが常にキューをもう一度走査します。このため、この設定はジョブの数が最大しきい値より少ない場合にだけ適用されます。
デフォルトは "3" です。この値を大きくすると、サーバーがキューを走査する回数が減り、全体的なパフォーマンスを向上できます。ただし、予定のボリュームが増大したためにキューが大きくなりすぎた場合、キューの処理速度を上げるための時間が短くなる可能性があります。これによって全体のパフォーマンスは低下しますが、予定はすぐに更新されます。
この章では、システムに問題があるかどうか、またその原因を調べるためのトラブルシューティングの方法について説明します。この章で説明する内容は次のとおりです。
システム全体を「デバッグモード」にする ics.conf パラメータはありませんが、ここでは有用なデバッグ情報を取得する方法について説明します。
パフォーマンスにマイナスの影響を与えるため、必要でない場合は、必ず、過度なログ記録および監視は無効にしてください。
次の表に示すパラメータを使用して、ログの詳細度を上げます。
パラメータ |
説明とデフォルト値 |
---|---|
logfile.loglevel |
DEBUG に設定して、CRITICAL、ALERT、ERROR、WARNING、NOTICE、および INFORMATION を含む、すべてのレベルがログ記録されるようにします。この設定はすべてのログに適用されます。 |
使用可能な別のログについては、「Calendar Server ログファイルの使用」を参照してください。
LDAP データキャッシュのすべてのアクセスをログに記録し、そのログ (レポート) を出力するには、次の表に示す ics.conf パラメータを設定します。
パラメータ |
説明とデフォルト値 |
---|---|
local.ldap.cache.stat.enable |
LDAP データキャッシュへのアクセスをログに記録し、ログファイルに統計情報を出力するかどうかを指定します。デフォルトは “no” です (統計情報はログ記録されない)。統計情報のログを有効にするには、“yes” に設定します。 パフォーマンス向上のために、このパラメータはデバッグモードでのみ使用してください。 |
local.ldap.cache.stat.interval |
統計情報レポートをログファイルに書き込む間隔を秒単位で指定します。デフォルトは “1800” 秒 (30 分) です。 これは、ログが有効になっている場合にのみアクティブになります。間隔を短くすると、問題を特定するのに役立ちます。間隔を長くすると、システムロードが減少します。 |
現在、Calendar Server には LDAP キャッシュデータを失効させるためのロジックは存在しません。ldap_cache ディレクトリの内容を手動で削除し、Calendar Server を再起動する必要があります。
Calendar Server を停止します。
/var/opt/SUNWics5/csdb/ldap_cache ディレクトリ内のファイルをすべて削除します。ただし、ldap_cache ディレクトリ自体は削除しないでください。
Calendar Server を再起動します。
システムを監視するには、次の Calendar Server ユーティリティーを使用します。
csmonitor: 必要なデバッグレベルを指定します。数字が大きいほど、メッセージがより詳細になります。
csstats: counter.conf ファイルに定義されているカウンタオブジェクトからの統計情報を表示するには、list コマンドを使用します。
cstool: cshttpd、csadmind、enpd の各サービスに対して ping を実行するには、このユーティリティーを使用します。
Calendar Server のユーティリティーについては、付録 D 「Calendar Server のコマンド行ユーティリティーのリファレンス」 を参照してください。
ホストされた環境を最初に作成するときに、ドメイン、コンテナ、ユーザー、リソースの適切なエントリを追加して、LDAP に DC ツリーを作成する必要があります。cscal などの Calendar Server のユーティリティーを使用するときに DC ツリーが存在しないと、次のようなエラーメッセージが表示される可能性があります。"Initialization failed .... exiting"
DC ツリーには、DC ツリーのルートに少なくとも 1 つの (デフォルト) ドメインが含まれていることを確認します。「新規のホストされたドメインの作成」に記載されている方法を使用して DC ツリー構造を作成します。
Calendar Server には、カレンダデータベースおよび LDAP ディレクトリを移行するためのいくつかのユーティリティーが用意されています。ここで説明する内容は次のとおりです。
一般に、移行ユーティリティーを使用して問題が生じた場合、次の情報を収集してから、テクニカルサポートにお問い合わせください。
問題のデータベースのバックアップコピー。
すべての関連ログのコピー。
コアを含むすべてのエラー出力メッセージ。
さまざまな移行ユーティリティーおよびそのマニュアルは、次の一覧に示す場所にあります。
このユーティリティーは、個別にインストール可能なコンポーネントである Delegated Administrator にバンドルされています。このユーティリティーは LDAP ディレクトリを Schema 1 から Schema 2 に移行します。このユーティリティーについては、『Sun Java System Communications Services 6 2005Q4 Schema Migration Guide』を参照してください。
テクニカルサポートサイトにはユーティリティーとそのマニュアルを含む移行バンドルが用意されています。
このユーティリティーは Calendar Server にインストールされています。マニュアルは 第 4 章「データベース移行ユーティリティー」に記載されており、トラブルシューティングの節が含まれています。ホストされたドメインおよび LDAP カレンダ検索データベース (CLD) プラグインを使用している場合は、このユーティリティーを実行する必要があります。
このユーティリティーは Calendar Server にインストールされています。マニュアルは、第 4 章「データベース移行ユーティリティー」に記載されています。ホストされたドメイン用のカレンダデータベースおよび LDAP ディレクトリのエントリを準備するには、このユーティリティーを使用します。
このユーティリティーは Calendar Server にインストールされています。マニュアルは、第 4 章「データベース移行ユーティリティー」に記載されています。Calendar Server 2 データベースを移行して Calendar Server 5 との互換性を持たせるには、このユーティリティーを使用します。
このユーティリティーは、テクニカルサポートサイトからのみ入手できます。ユーティリティーパッケージにはマニュアルが含まれています。このユーティリティーは、Netscape Calendar Server 4 を Calendar Server 5 に移行します。移行元のデータベースが整合していないため、これらの移行には特に注意を要します。手動による多くの作業が必要になることも珍しくありません。このユーティリティーは、テクニカルサポートサイトからのみ入手できます。ユーティリティーパッケージにはマニュアルが含まれています。このユーティリティーは、Netscape Calendar Server 4 を Calendar Server 5 に移行します。これらの移行には特に注意を要します。ユーティリティーを実行できるようになるまでに、移行元のファイルに対して多くの作業が必要になることも珍しくありません。移行の計画をサポートする Professional Services を利用されることをお勧めします。
ここでは、データベース以外の問題のさまざまなトラブルシューティングについて説明します。ここで説明する内容は次のとおりです。
さらに、次の SSL の章にも、SSL に関するトラブルシューティングの節があります。
サービスが特定のポート番号で待機していることを確認するには、「cstool」 ユーティリティーの ping コマンドを実行します。サービスに対して ping を実行しても、サービスが実際に稼動しているかどうかは検証されません。ソケット接続が受け付けられるかどうかが検証されます。
Calendar Server サービスには次のオプションがあります。
HTTP サービス (cshttpd)
管理サービス (csadmind)
ENS (予定通知サービス) (enpd)
DWP サービス (csdwpd) や通知サービス (csnotifyd) に対して ping を実行することはできません。
たとえば、calserver というホスト名のマシンに対して ping を実行し、cshttpd サービスがポート 80 で待機しているかどうかを確認するには、次のように実行します。
cstool -p 80 -h calserver ping http
デフォルトでは、cstool は 120 秒間応答を待ちますが、-t timeout オプションを使用してこの値を変更することができます。
ユーティリティーの詳細な参考資料については、付録 D 「Calendar Server のコマンド行ユーティリティーのリファレンス」 を参照してください。
cstool を実行するには、Calendar Server が稼動している必要があります。
start-cal を実行したときに起動しないカレンダサービスがある場合は、再起動する前に起動したサービスを終了する必要があります。たとえば、enpd、csnotifyd、および csadmind が起動しても cshttpd が起動しなかった場合は、enpd、csnotifyd、および csadmind を終了する必要があります。
カレンダサービスを起動するには、次のように実行します。
Calendar Server が稼動しているシステムの管理権限を持つユーザーとしてログインします。
サービスを終了して、再起動するには、start-cal を使用します。次に例を示します。
cal_svr_base/SUNWics5/cal/sbin/start-cal
start-cal は、さまざまなカレンダサービスを起動する前に、まず stop-cal コマンドを実行します。
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 が正しくシャットダウンしなかった場合は、次の手順を実行します。
前の手順 (「stop-cal の問題の解決」) を実行します。
LDAP データキャッシュデータベースのディレクトリ内のすべてのファイルを手動で削除します。
ファイルが残っていると、データベースが破損する可能性があります。ファイルを削除するには、次のように実行します。
Calendar Server を再起動します。
cal_svr_base /SUNWics5/cal/sbin/start-cal
LDAP データキャッシュの設定方法については、「Calendar Server の LDAP の設定」を参照してください。LDAP データキャッシュについては、『Sun Java System Communications Services 6 2005Q4 Deployment Planning Guide』を参照してください。
応答しているかどうか調べるには、バックエンドサーバーに対して ping を実行します。
応答している場合は、手順 3 に進みます。応答していない場合は、その原因を調べ、ふたたび動作するようになったら手順 3 に進みます。
CLD キャッシュをクリアします。「CLD キャッシュのクリア」を参照してください。
CLD キャッシュオプションを使用していて、ics.conf パラメータのサーバー名を更新した場合は、CLD キャッシュをクリアしてサーバー名を消去するとよいでしょう。CLD キャッシュに古いエントリが残されていると、フロントエンドサーバーが正しいバックエンドサーバーに接続できなくなったり、Calendar Server が移動後のカレンダを見つけられなくなります。
Calendar Server を再起動します。
CLD キャッシュオプションを使用していて、1 つ以上のカレンダを別のバックエンドサーバーに移動した (または、バックエンドサーバーの名前を変更した) 場合は、次の手順を実行します。
次に記載されている手順に従ってカレンダを移動していることを確認します。
「ユーザーカレンダの管理」を参照してください。
CLD キャッシュをクリアします。「CLD キャッシュのクリア」を参照してください。
1 つ以上のカレンダを別のバックエンドサーバーに移動すると、CLD キャッシュは無効になります。再読み込みするには、キャッシュをクリアする必要があります。そうすると、キャッシュが再構築されます。
service.http.allowadminproxy が “yes” に設定されていることを確認します。
admin-user に Calendar Server 管理者の権限があることを確認します。
admin-password が正しいことを確認します。
calendar-user が有効な Calendar Server ユーザーであることを確認します。
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 をより大きい値に設定する場合は、次の手順を実行する必要があります。
Directory Server を停止します。
dse.ldif ファイルを編集します。
Directory Server を再起動します。
ldapmodify の使用方法および dse.ldif ファイルの編集方法については、次の Web サイトで入手できる Directory Server のマニュアルを参照してください。
http://docs.sun.com/coll/1316.1
start-cal コマンドは、csstored プロセスが設定されていない場合でも、デフォルトで csstored プロセスを起動します。設定されていない csstored プロセスは、csstored を実行しているすべてのマシンで 24 時間ごとに設定されていないことを伝えるメッセージを出力します。
csstored を未設定の状態で実行しないようにすることによって、メッセージを無効にできます。csstored プロセスの実行を無効にするには、メッセージが生成されるすべてのマシンで、次の ics.conf パラメータを設定します。
service.store.enable=”no”
自動バックアップ作成のために csstored を設定しているマシンでは、プロセスを無効にしないでください。
ここでは、Calendar Server データベースに関するさまざまな問題について説明します。
多くのトラブルシューティングの手順では、Berkeley データベースのユーティリティープログラムへのアクセス権が必要です。これらのユーティリティープログラムは、Calendar Server バンドルで入手できますが、これらのプログラムはサポートされていません。詳細は、直接 Sleepycat Software (http://www.sleepycat.com) から入手できます。
ここで説明する内容は次のとおりです。
LD_LIBRARY_PATH 環境変数を設定してエクスポートし、次のディレクトリに反映させます。
cal_svr_base/SUNWics5/cal/tools/unsupported/bin/
次の表は、よく使用される 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 データベースがデッドロック状態にある場合は、データベースをリセットする必要があります。できるだけ早期にこの状態を検出することが重要です。
システムが定期的にデータベースをチェックして、デッドロック状態を検出し、管理者に通知するようにするには、次のように実行します。
設定を変更する権限を持つ管理者としてログインします。
/etc/opt/SUNWics5/cal/config ディレクトリに移動します。
古い ics.conf ファイルをコピーして名前を変更し、保存します。
必要に応じて、ics.conf ファイルを編集して次の値を設定します。
local.caldb.deadlock.autodetect=”yes”
このパラメータが “yes” に設定されている場合は、ロック領域を監視する db_deadlock デーモンが起動されます。
カレンダデータベースは、システムリソースの競合、ハードウェアの障害、アプリケーションエラー、データベース障害、人為的な原因など、さまざまな原因で破損することがあります。ここでは、カレンダデータベースの破損を検出する方法について説明します。
データベースが破損しないとだれにも保証はできません。ですが、データの損失と運用停止時間を最小限にとどめることができます。破損を早期に検出するには、厳密にデータベースおよびカレンダサービスを監視することが重要です。頻繁に完全なバックアップを行っておくことが、破損が検出された場合に復元する秘訣です。
カレンダデータベースで起こりうる破損には、2 つのレベルがあります。
アプリケーションレベル: 1 つ以上のデータベースファイルのエントリに問題があると、それらを基にしている場合、サーバーが稼動しなくなります。
データベースレベル: Berkeley データベースのページが破損すると、さまざまな問題が発生します。一般的な症状は、csdb check を実行するとループすることです。もう一つの一般的な症状は、次のようなエラーメッセージが表示されることです。
“illegal page type or format”, or “page 97895 doesn’t exist, create flag not set.”
データベース破損の兆候を示すエラーメッセージについて、アラームログを含む Calendar Server ログファイルを監視します。ログファイルについては、「Calendar Server ログファイルの使用」を参照してください。
ALERT、CRITICAL、ERROR、および WARNING レベルのエラーについて、ログファイルを定期的に調べてください。これらのエラーが見つかったときは、Calendar Server の動作で考えられる問題について調査します。NOTICE および INFORMATION レベルのログ予定は、Calendar Server の通常動作中に生成されることがあります。これは、サーバーアクティビティの監視に役立つように提供されています。
データベースディレクトリ内のトランザクションログファイルを削除しないでください。トランザクションログファイルにはトランザクションの更新 (追加、変更、削除) が記録されており、これを削除すると復元できない状態にまでカレンダデータベースが破損してしまうことがあります。
Calendar Server に関するテクニカルサポートを依頼する場合、問題解決のためにログファイルの提出が必要となることがあります。
Calendar Server を監視するには、csmonitor ユーティリティーを使用します。このユーティリティーは、複数のトランザクションログファイルの発生や、カレンダデータベースのディスク容量の不足などの問題が生じた時点で、管理者に電子メールを送信するようにします。詳細は、「csmonitor」を参照してください。
カレンダプロパティー (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 コマンドを実行します。
「破損したカレンダデータベースの再構築」を参照してください。
ここでは、リカバリモードの間も破損したデータベースにアクセスできる方法について説明します。ここで説明する内容は次のとおりです。
データベースの破損が見つかった場合、サービスの停止を防ぐ 1 つの方法は、データベースを読み取り専用モードにすることです。このモードでは、エンドユーザーはデータベースのエントリを読むことはできますが、追加、変更、または削除はできません。エンドユーザーがカレンダデータを追加、変更、または削除しようとすると、システムによりエラーメッセージが表示されます。また、カレンダの予定および仕事を追加、変更、または削除する管理者ツールも、データベースが読み取り専用モードの間は機能しません。
データベースを読み取ることができないほど破損している場合は、バックアップを復元するまでの間、サービスを停止する必要があります。バックアップを復元する最短の方法は、有効なホットバックアップを取ることです。「復元する前に」を参照してください。
必要がなくても、カレンダサービスを一時的に停止して、データベースがさらに破損するのを防ぐ場合もあります。
カレンダダービスを停止するには、次のようにように実行します。
cal_svr_base/SUNWics5/cal/sbin/stop-cal
コマンド行で、ics.conf が格納されているディレクトリに移動します。
cd /etc/opt/SUNWics5/config
カレンダデータベースに対して読み取り専用モードを指定します。
caldb.berkeleydb.readonly=”yes”
ics.conf ファイルの編集が終わったら、Calendar Server を再起動します。
cal_svr_base /SUNWics5/cal/sbin/start-cal
ics.conf の変更を有効にするには、サービスを再起動する必要があります。
ここでは、いくつかの一般的なデータベース障害と、推奨する対応策について説明します。ここで説明する内容は次のとおりです。
csadmind では GSE (グループスケジューリングエンジン) とアラームディスパッチエンジンの両方のサービスを処理するため、GSE キュー内、またはアラームキュー内のエントリに問題があると、これらの問題が発生する可能性があります。
対応策
csadmind が稼動していない場合は、すぐに stop-cal を実行します。
カレンダサービスを稼動したままにしておくと、トランザクションログが累積し、それが原因でデータベースがさらに破損して、トランザクションログファイルとデータベースを照合するのに時間がかかる場合があります。
csadmind の再起動を試みます (start-cal の再実行)。
正常に起動したら、次のようにして 2 つのキューが機能していることを確認します。
csschedule を使用して、GSE キューをチェックします。
dbrig を使用して、アラームキューをチェックします。
csschedule および dbrig の実行方法については、付録 D 「Calendar Server のコマンド行ユーティリティーのリファレンス」 を参照してください。
csadmind がダンプでクラッシュした場合は、pstack を分析します。
トレースに GSE に関連した機能がある場合は (中に GSE の文字がある)、GSE キューの最初のエントリおよび予定データベースの参照エントリを調べます。ほとんどの場合、GSE エントリで参照されている予定が、問題を起こしているエントリです。この問題を解決するには次を実行します。
csschedule を使用して、GSE エントリを削除します。
cscomponents を使用して、問題を起こしている予定をデータベースから削除します。
csschedule および cscomponents の実行方法については、付録 D 「Calendar Server のコマンド行ユーティリティーのリファレンス」 を参照してください。
エントリが破損していない場合は、カレンダサーバーでは処理できない特殊な例の可能性があります。
次の手順を実行します。
破損したデータベースのカレンダ環境のスナップショットを取り、カスタマサポートに問い合わせます。
環境のバックアップを作成するには、次のように実行します。
サービスの停止を避けるには、カレンダデータベースを一時的に読み取り専用の状態にして、ホットバックアップのコピーに戻ります。
カレンダデータベースを一時的に読み取り専用の状態にすると、トランザクションの追加、変更、または削除はできなくなります。エンドユーザーがカレンダデータを追加、変更、または削除しようとすると、エラーメッセージが表示されます。カレンダの予定および仕事を追加、変更、または削除する管理者ツールも、データベースが読み取り専用モードの間は機能しません。
カレンダデータベースを読み取り専用モードにするには、ics.conf ファイルを編集して、次のパラメータを “yes” に設定します。
caldb.berkeleydb.readonly=”yes”
「自動バックアップコピーの復元」にある手順を使用して、ホットバックアップコピーに戻ります。
csstored を設定して有効にすると、ホットバックアップが使用可能になり、数分以内に最新の状態になります。また、常にホットバックアップコピーを検証して、破損していないことを確認するとよいでしょう。その場合は、db_verify を実行します。
ほかの方法がすべて失敗した場合、ダンプと再ロードの手順を実行して、データベースを修復できるかどうか確認します。
この手順は、「ダンプとロードによるカレンダデータベースの復元」で説明しています。
この状態は、制御スレッドが原因で発生する場合があります。これは Berkeley DB データベースのページをロックし、ロックを解除しないで終了します。この問題を確認するには、cshttpd プロセスおよび csadmind 上で pstack を実行します。pstack は標準 UNIX ユーティリティーで、次の場所に格納されています。/usr/bin/pstack。このユーティリティーにより、ロックを獲得するために待機しているスレッドが表示されます。
問題を解決するには、次のようにして Calendar Server を再起動します。
データベースのループは、通常、データベースファイルの破損により起こります。データベースが破損しているため、回復不能になる可能性があります。次のいくつかの選択肢があります。
ホットバックアップに戻ります。
破損が最近起こったのであれば、いずれかのホットバックアップコピーを使用できます。
壊滅的アーカイブのリカバリプロセスを使用します。
推奨されるプロセスについては、「自動バックアップコピーの復元」を参照してください。
ダンプと再ロードの手順を使用します。「ダンプとロードによるカレンダデータベースの復元」を参照してください。
ここでは、csdb 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 を再起動します。
次の例は、コマンドと、そのコマンドにより生成された出力を示しています。
# ./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 回走査されたことを示しています。これはエラーではありません。最初の走査ではカレンダプロパティーデータベース内の情報を確認し、次に再走査して、カレンダプロパティーデータベースがアクセス可能であることを確認します。
ここで説明する内容は次のとおりです。
ダンプとロードの手順を使用して破損したデータベースの復元を試みます。ダンプとロードの手順では、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 BackupTM ソフトウェア、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 を実行します。
「破損したカレンダデータベースの再構築」で説明している csdb rebuild コマンドを使用して、復元したデータベースファイルを再構築します。
rebuild の実行が完了したら、出力ファイルを確認します。再構築が正常に完了した場合、rebuild.out ファイルの最後の行は次のようになります。
Calendar database has been rebuilt |
csdb rebuild コマンドが正常に終了しなかった場合は、次レベルの db_dump オプション (-r または -R) を使用してデータベースのダンプを行います。
db_dump -R オプションを実行しても破損しているデータベースを復元できない場合は、ご購入先のテクニカルサポートまたは販売代理店までご連絡ください。それまでの間は、データベースの最終バックアップを使用する必要があります。
第 10 章「自動バックアップ (csstored) の設定」で説明されている自動バックアップ機能を使用している場合、ライブデータベースが破損したときにバックアップコピーを復元できます。
ここでは、2 つの異なる自動バックアップの復元方法について説明します。
バックアップを復元する前に、必ず次の操作を行っていることを確認してください。
どのトランザクションがライブデータベースの破損の原因になったか診断を試みていること。
新規のアーカイブが破損されないように、破損しているトランザクションを削除または修正していること。
破損したデータベースを、別のディレクトリまたはリムーバブルメディアにコピーして保存していること。このコピーは、テクニカルサポートに問い合わせを行う際に必要になります。
ライブデータベースが破損した場合は、ホットバックアップがバックアップの最初の選択肢となります。バックアップを復元するには、次の手順を実行します。
破損したライブデータベースのディレクトリで、適用されていない、または書き込み可能な状態のログファイルを識別します。
書き込み可能なログを閉じます。このログには、最新のトランザクションが含まれています。
新規の (復元) ディレクトリを作成します。
現在のホットバックアップのコピーを、新規の復元データベースのディレクトリにコピーします。
log.* ファイルを、破損したライブデータベースのディレィトリから、新規の復元データベースのディレクトリにコピーします。
データベースのアーカイブコピーを保持している場合は、ライブデータベースに適用されなかったログをアーカイブディレクトリにコピーします。
新規の復元データベースに対して指定された -c -h オプションを指定して、db_recover を実行します。
たとえば、新規の復元ディレクトリの名前が recoverydb の場合、コマンドは次のようになります。
db_recover -c -h recoverydb
log.* ファイルは、新規のディレクトリに残しておきます。
db_recover プログラムではログファイルを新規の復元データベースに適用しましたが、バージョン 4.2 以降、Berkeley DB ではログファイルをそのまま残しておくことを勧めします。
新規の復元ディレクトリ内のデータベースファイルに対して、db_verify を実行します。
手順については、「カレンダデータベースの破損をチェックするには」を参照してください。
新規の復元ディレクトリに対して、csdb -v list を実行します。
新規の復元ディレクトリで 上記の 3 つの手順を実行したら、古い破損したライブデータベースを新規の復元ディレクトリと置き換えます。
新しいスナップショットとして機能させるために、新規のライブデータベースをホットバックアップのディレクトリにコピーします。
次の定期的なスナップショットが取得されるまで、すべての新しいログがこのコピーに適用されます。
Calendar Server を起動します。
新規の復元ディレクトリでいずれかの手順に失敗した場合は、次のようにして破損していない古いホットバックアップを特定します。
ホットバックアップを新しい順から逆にたどり、各ファイルに対して順番に db_verify および csdb -v list を実行して、破損していない最新のコピーを見つけます。
パスする最初のホットバックアップコピーが、ライブデータベースのディレクトリに復元されます。
「ホットバックアップを復元するには」で説明している手順に従い、破損したライブデータベースを新規のホットバックアップと置き換えます。最初に、必ず 「復元する前に」をお読みください。
ホットバックアップがどれも動作せず、アーカイブバックアップがない場合は、テクニカルサポートに問い合わせてください。アーカイブバックアップがある場合は、「アーカイブバックアップを復元するには」にある手順を実行します。「復元する前に」も参照してください。
破損したホットバックアップはないが、アーカイブバックアップとトランザクションログがある場合は、次の手順を実行して、アーカイブしたデータベースの最新の破損していないデータベースを復元できます。
破損したライブデータベースのディレクトリで、適用されていない、または書き込み可能な状態のログファイルを識別します。
書き込み可能なログを閉じます。このログには、最新のトランザクションが含まれています。
新規の (復元) ディレクトリを作成します。
最新のアーカイブコピーとそのログファイルを、新規の復元データベースのディレクトリにコピーします。
適用されていない log.* ファイルを、破損したライブデータベースのディレクトリから、新規の復元データベースのディレクトリにコピーします。
新規の復元データベースに対して指定された -c -h オプションを指定して、db_recover を実行します。
たとえば、新規の復元ディレクトリの名前が recoverydb の場合、コマンドは次のようになります。
db_recover -c -h recoverydb
log.* ファイルは、新規の復元ディレクトリに残しておきます。
db_recover プログラムではログファイルを新規の復元データベースに適用しましたが、バージョン 4.2 以降、Berkeley DB ではログファイルをそのまま残しておくことを勧めします。
新規の復元ディレクトリ内のデータベースファイルに対して、db_verify を実行します。
手順については、「カレンダデータベースの破損をチェックするには」を参照してください。
新規の復元ディレクトリに対して、csdb -v list を実行します。
新規の復元ディレクトリで 上記の 3 つの手順を実行したら、古い破損したライブデータベースを新規の復元ディレクトリと置き換えます。
新しいスナップショットとして機能させるために、新規のライブデータベースをホットバックアップのディレクトリにコピーします。
Calendar Server を起動します。
新規の復元ディレクトリがいずれかの手順に失敗した場合は、次のようにして破損していない古いアーカイブバックアップを特定します。
アーカイブバックアップのコピーを新しい順から逆に調べて、順に各ファイルに対して次の 3 つのリカバリプログラムを実行して、破損していない最新のコピーを見つけます。db_recover -c-h、db_verify、および csdb -v list。
パスする最初のアーカイブアップコピーが、ライブデータベースのディレクトリに復元されます。
「アーカイブバックアップを復元するには」で説明している手順に従い、破損したライブデータベースを新規のアーカイブバックアップと置き換えます。
アーカイブバックアップがどれも動作しない場合は、テクニカルサポートに問い合わせてください。
ここで説明する内容は次のとおりです。
カスタムバックアップスクリプトが Berkeley データベースのツール (db_recover など) を使用して作成されている場合は、Calendar Server にアップグレードすると、機能しなくなる可能性があります。これは、Calendar Server の以前のバージョンでは、ツールを静的ライブラリでコンパイルしていたためです。現在では、ツールは動的ライブラリの libdb-4.2.so でコンパイルされています。
既存のカスタムスクリプトで新しい動的ライブラリを使用するには、次に示す大域変数を設定します。
LD_LIBRARY_PATH=libdb-4.2.so