Sun Java System Calendar Server 6 2005Q4 管理ガイド

パート IV Calendar Server の管理

第 12 章 Calendar Server の管理

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

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

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

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


注 –

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


Calendar Server の起動と停止

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

start-cal と stop-cal について

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


注 –

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


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

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

  2. csnotifyd: 通知サービス

  3. csadmind: 管理サービス

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

  5. cshttpd: HTTP サービス

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

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

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

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

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

  3. Calendar Server を起動します。


    ./start-cal

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

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

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

  3. Calendar Server を停止します。


    ./stop-cal

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

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

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

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

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

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

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

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

    cd /etc/opt/SUNWics5/config

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

    caldb.berkeleydb.hotbackup.enable="yes"

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

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

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

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

    cal_svr_base/SUNWics5/cal/sbin/start-cal

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

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

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

    cd /etc/opt/SUNWics5/config

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

    caldb.berkeleydb.archive.enable=”yes”

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

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

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

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

    cal_svr_base/SUNWics5/cal/sbin/start-cal

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

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

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

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

    cd /etc/opt/SUNWics5/config

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

    caldb.berkeleydb.hotbackup.enable="no"

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

    cal_svr_base/SUNWics5/cal/sbin/start-cal

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

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

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

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

    cd /etc/opt/SUNWics5/config

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

    caldb.berkeleydb.archive.enable="no"

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

    cal_svr_base/SUNWics5/cal/sbin/start-cal

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

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

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

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

GSE について

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

GSE キューについて

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

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

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

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

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

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


csschedule list

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


csschedule -c 10 list

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


csschedule -v list Holiday_Schedule

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

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

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

csschedule -v delete

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

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

Calendar Server の監視

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

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

csmonitor について

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

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

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

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

Procedurecsmonitor を設定するには

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

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

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

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

    パラメータ 

    説明とデフォルト値 

    service.monitor.continuous

    csmonitor を連続してループするかどうかを指定します。"0": 連続的にループしません (デフォルト)。"1": 連続的にループします。

    このパラメータを “1” に設定すると、csmonitor を自動的に実行できます。

    service.monitor.loopsdelay

    2 つの監視ループの間の遅延時間を秒単位で指定します。デフォルトは “60” 秒です。 

    デバッグの目的ではこの間隔を短くし、本稼働ではこの間隔を長くします。 

    service.monitor.emailaddress.from

    csmonitor が送信するメッセージの送信元となる電子メールアドレスを指定します。デフォルトはなしです。

    service.monitor.emailaddress.to

    csmonitor が送信するメッセージの送信先となる電子メールアドレスを指定します。デフォルトはなしです。

    service.monitor.csdb.logthreshold 

    カレンダデータベース (csdb) を監視します。最大ディスク消費量のしきい値を、ディスク容量全体のパーセント値で指定します。csdb ディレクトリのディスク消費量がこの値を超えると、電子メールで警告メッセージが送信されます。デフォルトは “90” です。

    logfile.monitor.logname

    csmonitor のログファイル名を指定します。デフォルトは “csmonitor.log” です。

    logfile.monitor.maxlogfilesize

    ログファイルの最大サイズを指定します。ログファイルがこのサイズを超えると、csmonitor はログを csmonitor.log.timestamp という名前で保存し、現在のログをリセットします。デフォルトは “2097152” です。

    service.monitor.dbglevel

    デバッグレベルを指定します。設定できる値は 05 です。 この値が大きいほど、csmonitor は詳細なメッセージを送信します。デフォルトは “0” で、ログは指定されません。このパラメータを “5” に設定すると、デバッグのログが指定されます。

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

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

    cal_svr_base /SUNWics5/cal/sbin/start-cal

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

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

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

cstool による監視

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

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

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

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

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

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

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

手順
  1. Calendar Server を停止します。

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

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

サーバー名の変更

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

匿名アクセスの設定

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


注 –

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


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

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

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

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

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

    パラメータ 

    説明とデフォルト値 

    service.http.allowanonymouslogin

    必要に応じて、このパラメータを “yes” に設定し、匿名アクセス (ログイン) を有効にします。デフォルト値は “yes” です。

    service.calendarsearch.ldap

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


    注 –

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


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

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

    cal_svr_base /SUNWics5/cal/sbin/start-cal

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

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

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

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

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

    パラメータ 

    説明とデフォルト値 

    service.wcap.anonymous.

    allowpubliccalendarwrite

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

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

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

    cal_svr_base /SUNWics5/cal/sbin/start-cal

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

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

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

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

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

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

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

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

    service.http.allowadminproxy = "yes"

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

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

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

手順

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

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

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

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

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

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

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

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

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

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

      • admin-password が正しくない。

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

Calendar Server 設定の再読み込み

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

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

ここでは、ホストされたドメインの管理について、次の項目を説明します。

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

インストールしたカレンダをホストされたドメイン用に設定し、第 11 章「ホストされたドメインの設定」で説明している準備作業を行うと、新しいホストされたドメインを追加できるようになります。

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

Calendar Server のホストされた (または仮想) ドメインを管理するには、次の 2 つのツールのセットのいずれかを使用します。

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

ホストされたドメインの概要や、その他の入門的な内容については、第 11 章「ホストされたドメインの設定」を参照してください。


注意 – 注意 –

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


新規のホストされたドメインの作成

次を参照して、Schema 2 または Schema 1 用のホストされたドメインを作成します。

ホストされたドメインを追加するには (Schema 2)

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

ホストされたドメインを追加するには (Schema 1)

csdomain を実行するには、ホストされたドメインモードである必要があります。ホストされたドメインを有効にする方法については、第 11 章「ホストされたドメインの設定」を参照してください。

Schema 1 でホストされたドメインを作成するには、csdomain create を使用します。たとえば、west.sesta.com を作成するには、次のコマンドを使用します。

csdomain create west.sesta.com

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

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

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

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

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

ACI の構成については、「カレンダのアクセス制御」で詳細に説明しています。

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

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


注 –

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


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

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


注 –

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


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

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

ホストされたドメインの有効化

デフォルトでは、Calendar Server はホストされていないドメインになっています。Java Enterprise System で Calendar Server および Messaging Server を使用する場合は、ホストされたドメインを使用することをお勧めします。

インストールされている Calendar Server のホストされたドメインを有効または無効にするには、ics.conf ファイルを編集します。

Procedureホストされたドメインを有効にするには

手順
  1. ics.conf ファイルを次のように編集します。

    service.virtualdomain.support="yes" (デフォルトは "no")

  2. カレンダサービスを再起動します。

    ホストされたドメインを実装するために必要なすべての ics.conf パラメータの一覧については、「ホストされたドメイン環境の設定」を参照してください。

Procedureホストされたドメインを無効にするには

手順
  1. ics.conf ファイルを次のように編集します。

    service.virtualdomain.support="no"

  2. カレンダサービスを再起動します。

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

この章では、ユーザーとリソースの管理のための Calendar Server ユーティリティーの使用方法について説明します。この章で説明する内容は次のとおりです。

ユーザー管理ツール

次のいずれかのユーザー管理ツールを使用して、カレンダのユーザーとリソースを管理できます。


注 –

Delegated Administrator はカレンダを管理しません。ユーザーとリソースのカレンダを作成するには、Calendar Server ユーティリティーを使用します。



注 –

Schema 2 および Delegated Administrator を使用している場合でも、Calendar Server コマンド行ユーティリティーを使用して特別な機能を実行する必要がある場合もあります。このような場合には、どのユーティリティーを使用すればよいか、作業指向のこのマニュアルの記述を参照してください。


ユーザーとリソースの作成

ここでは、Calendar Server の新規ユーザーとリソースの管理に関する次の情報について説明します。

Schema 2 の新規ユーザーを作成するには

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

Schema 1 の新規ユーザーを作成するには

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

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

Schema 2 の新規リソースを作成するには

Delegated Administrator コンソールまたはユーティリティーのどちらも使用できます。

Schema 1 の新規リソースを作成するには

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

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

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

必須の mail 属性を追加するには

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 属性の追加が必要になる場合があります。

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

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 属性を既存のユーザーおよびリソースに追加するには

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

ユーザーの管理

ユーザーの作成が完了すると、csuser ユーティリティーを使用して次の管理作業を実行できます。

ユーザー情報を表示するには

すべてのカレンダユーザーを一覧表示したり、特定ユーザーのカレンダ属性を表示したりするときは、csuser ユーティリティーの list コマンドを使用します。

たとえば、カレンダ機能が有効なすべてのユーザーを表示するには、次のように実行します。

csuser list

jsmith という単一ユーザーのすべてのカレンダ属性を表示するには、次のように実行します。

csuser -v list jsmith

ユーザーを無効にするには

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

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

Delegated Administrator コンソール

Delegated Administrator コンソールで、「ユーザー」一覧ページからユーザーを選択します。このユーザーのプロパティーで、カレンダサービスを含むサービスパッケージを削除します。これにより、このユーザーがカレンダに対して無効になり、ユーザーの icsStatusinactive に設定されます。


注 –

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


Delegated Administrator ユーティリティー (commadmin user delete)

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

commadmin user delete jsmith -S cal

これにより、LDAP エントリを完全に削除することなく、このユーザーがカレンダに対して無効になります。さらに、このコマンドによって、ユーザーの icsStatusinactive に変更されます。

Calendar Server ユーティリティー (csuser disable)

disable コマンドにより、ユーザーはカレンダデータにアクセスできなくなりますが、そのユーザーの情報は LDAP エントリや Calendar Server データベースから削除されません。このコマンドによって、icsStatus 属性が active から inactive に変更されます。ホストされていないドメインモードには、カレンダサービスのようなものは存在しません。

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

csuser disable jsmith

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

ユーザーを有効にするには

ユーザーを有効にするには、次のいずれかのユーティリティーを使用します。

Delegated Administrator コンソール

新規ユーザーと既存のユーザーの両方を有効にすることができます。

Delegated Administrator (commadmin user create)

ユーザーを作成する場合は、次の例に示すように、カレンダサービスに対してそのユーザーを有効にします。

commadmin user create jsmith -S cal

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

commadmin user modify jsmith -S cal

Calendar Server ユーティリティー (csuser enable)

ユーザーエントリの作成時に 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



例 14–1 csattribute を使用した電子メールのエイリアスの追加

たとえば、JohnSmith という名前のユーザーに対して、以下の値を持つ mailalternateaddress 属性を追加するには次のようにします。

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 ディレクトリサーバーに存在しないことが検出された場合は、そのユーザーのディレクトリサーバーエントリを作成する必要があります。

LDAP からユーザーを削除するには

ユーザーをホストドメインまたはホストされていないドメインのどちらから削除するかに応じて異なるツールを使用します。


注意 – 注意 –

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

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

ホストされていないドメインについては、「ホストされていないドメインの場合のみ: 削除のマークは付いているが破棄されていないユーザーの削除取消し」を参照してください。


ProcedureDelegated Administrator を使用した Schema 2 でのユーザーの削除

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

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

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

    Delegated Administrator ユーティリティーの場合: commadmin user delete コマンドを使用します。次に例を示します。

    commadmin user delete -D chris -n siroe.com 
    -w bolton -l jsmith

    どちらの場合も、ユーザー LDAP エントリ内の icsStatus 属性が active から deleted に変更されます。

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

    csclean clean “*”

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


    ヒント –

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


  3. 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』を参照してください。


Schema 1 環境でのユーザーの削除

指定されたユーザーの 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 (オブジェクトクラス)、icsSubscribedicsCalendarOwnedicsCalendaricsDWPHost (LDAP CLD が設定されている場合) を含むすべてのカレンダ属性がユーザーの LDAP エントリから消去されます。Calendar Server 管理者がユーザーに代わってカレンダを作成することはできません。

次の場合に、ユーザーの LDAP エントリにこれらの属性が復元されます。


ユーザー名を変更するには

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


注 –

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

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


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

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

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

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

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

    パラメータ 

    説明とデフォルト値 

    service.wcap.

    allowpublicwritablecalendars

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

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

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

    cal_svr_base /SUNWics5/cal/sbin/start-cal

リソースの管理

リソースを追加したら、csresource を使用して次のように管理できます。

Procedureリソースをリスト表示するには

手順
  1. sbin ディレクトリに移動します。

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

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

    ./csresource -v list

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

手順
  1. sbin ディレクトリに移動します。

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

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

    ./csresource -v enable ConfRm12

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

手順
  1. sbin ディレクトリに移動します。

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

    ./csresource -v disable ConfRm12

Procedureリソースを削除するには

手順
  1. sbin ディレクトリに移動します。

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

    ./csresource -v delete ConfRm12

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

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

ここで説明する手順は次のとおりです。

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

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

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


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

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

手順
  1. 適切なホストの /etc/aliases ファイルに次のようなエントリを追加します。


    Resource/Conference room aliases
     Room100: /dev/null
  2. csattribute ユーティリティーを使用して、リソースの電子メールアドレスを LDAP ディレクトリに追加します。


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

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

Calendar Server が使用する LDAP 属性の管理には、「csattribute」ユーティリティー、または ldapmodify を使用します。csattribute を使用すると、属性をリスト表示、追加、または削除できます。属性を変更するには、ldapmodify を使用します。ここで説明する内容は次のとおりです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

注 –

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


第 15 章 カレンダの管理

この章で説明する内容は次のとおりです。 カレンダの作成や管理を行うための Calendar Server コマンド行ユーティリティーの使用方法について説明します。

カレンダ管理の概要

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

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

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

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

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

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

Calid 構文

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

userid[@domain][:calendar-name]

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

userid

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

domain

ユーザーのドメイン名。

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

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

ホストされたドメイン (仮想ドメインとも言う) については、第 11 章「ホストされたドメインの設定」および 第 13 章「ホストされたドメインの管理」を参照してください。

calendar-name

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

カレンダ ID の作成規則

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

ホストしていない Calid からホストされたドメイン形式の Calid への変換

ホストされたドメインを持つ前に作成された 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 という名前の新しいカレンダを作成する場合、ホストしていない環境内の新しいカレンダの calidjsmith:meetings です。


注 –

デフォルトカレンダを持たないユーザーが参加予定者として指定される場合、Calendar Server はカレンダが見つからないことを示すエラーを返します。


Procedure自動プロビジョニングを有効にするには

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

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

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

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

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

    パラメータ 

    説明とデフォルト値 

    local.autoprovision

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

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

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

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

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

  7. ファイルを保存します。

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

    cal_svr_base /SUNWics5/cal/sbin/start-cal

Procedure自動プロビジョニングを無効にするには

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

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

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

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

    パラメータ 

    説明とデフォルト値 

    local.autoprovision

    パラメータを no に設定すると、ユーザーカレンダの自動プロビジョニングが無効になります。

  5. ファイルを保存します。

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

    cal_svr_base /SUNWics5/cal/sbin/start-cal


    注 –

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


カレンダのアクセス制御

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

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

アクセス制御の設定パラメータ

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

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

パラメータ 

説明 

calstore.calendar.default.acl

ユーザーがカレンダを作成したときに使用されるデフォルトのアクセス制御設定を指定します。デフォルトは次のとおりです。 

"@@o^a^r^g;@@o^c^wdeic^g;

@^a^fs^g;@^c^^g;@^p^r^g"

calstore.calendar.owner.acl

カレンダ所有者のデフォルトのアクセス制御設定を指定します。デフォルトは次のとおりです。 

"@@o^a^rsf^g;@@o^c^wdeic^g"

resource.default.acl

リソースカレンダを作成したときに使用されるデフォルトのアクセス制御設定を指定します。デフォルトは次のとおりです。 

"@@o^a^r^g;@@o^c^wdeic^g;

@^a^rsf^g"

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

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

公開

ユーザーのカレンダに対する読み取りアクセス権を持つ誰もが予定また は仕事を表示できます。

非公開

カレンダの所有者だけが予定または仕事を表示できます。

時刻と日付のみの公開

これらは極秘の予定および仕事です。カレンダの所有者は予定または仕事を表示できます。カレンダに対する読み取りアクセス権を持つユーザーがカレンダにア クセスすると、「タイトルなしの予定」とカレンダに表示されます。

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

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

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

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

ユーティリティー 

説明 

cscal

特定のユーザーまたはリソースのカレンダの ACL を設定するときは、-a オプションを指定して create コマンドまたは modify コマンドを実行します。

csresource

Schema 1 モードで csresource を使用してリソースカレンダを作成している場合、リソースカレンダに ACL を設定するには、csresource ユーティリティーに -a オプションを指定して実行します。

commadmin ユーザー

csuser

Schema 2 の commadmin ユーティリティーを使用して、ユーザーがカレンダを作成するときに使用するデフォルト ACL を変更します。

ユーザーがカレンダを作成するときに使用するデフォルトACL を変更するには、Schema 1 の csuser ユーティリティーに -a オプションを指定して実行します。


注 –

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


カレンダの作成

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

cscal を使用したユーザーカレンダの作成

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

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

たとえば、jsmith というカレンダ ID (calid) を持つカレンダを新規作成するには、次のように実行します。

cscal -o jsmith -n JohnSmithCalendar create jsmith

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

John Smith が所有する Hobbies という表示名のカレンダを作成し、グループスケジュール機能のアクセス制御設定を適用するには、次のように実行します。

cscal -n Hobbies -o jsmith create Personal

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

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

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

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

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

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

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

リソースカレンダの作成準備

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

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

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

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

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


注 –

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


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

パラメータ 

説明とデフォルト値 

resource.default.acl

このパラメータには、リソースカレンダの作成時にデフォルトで適用されるアクセス制御設定を特定します。デフォルトのアクセス許可は、次の ACL (アクセス制御リスト) によって指定されます。 

"@@o^a^r^g;@@o^c^wdeic^g;@^a^rsf^g"

この ACL は、コンポーネントとプロパティーの両方に対する読み取り、スケジュール、空き/予定ありの設定アクセス権をすべてのカレンダユーザーに付与します。 

リソースに対するアクセス権を変更するには、csresource ユーティリティーの create コマンドを使用してカレンダを作成するときに -a オプションを指定します。

resource.allow.doublebook

このパラメータには、リソースカレンダが複数のユーザーからの予約を許可するかどうかを指定します。複数のユーザーからの予約が許可される場合、リソースカレンダでは同時に複数の予定をスケジュールできます。 

デフォルトは "no"— で、複数のユーザーからの予約は許可されません。

リソースカレンダの複数のユーザーからの予約を許可するには、csresource ユーティリティーの create コマンドを使用してカレンダを作成するときに -k オプションを指定します。

新しいリソースカレンダの作成

Calendar Server では、リソースカレンダの自動プロビジョニングはサポートしていません。サイトに必要なリソースごとに、次の方法を使用する必要があります。


注 –

リソースの 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

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

Delegated Administrator

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

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

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

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

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

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

    cscal -o owner list

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

    cscal -o owner delete

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


    注 –

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


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

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

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

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

    csclean -g 10 clean sesta.com
  2. ユーザーが 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

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

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

カレンダからプロパティー値を消去するには、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 エントリの次の属性を更新することで、カレンダを復元できます。

ここで、default_calid はユーザーのデフォルトカレンダの ID (calid) です。

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

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

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

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

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


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


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

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


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


    csattribute -a icsDWPHost delete bkamdar
     csattribute -a icsDWPHost=sesta.com add bkamdar
  6. 新しいサーバーで、「csuser」 ユーティリティーを使用してユーザーカレンダのカレンダユーザーを有効にします。次に例を示します。


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


    cscal -v -o bkamdar list bkamdar
     ...
     csattribute -v list bkamdar
  8. 元のサーバーで、移動した各カレンダを削除します。次に例を示します。


    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 はカレンダを削除し、削除が完了したことを示すメッセージを表示します。

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

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

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


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


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

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


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


    csattribute -a icsDWPHost delete bkamdar
     csattribute -a icsDWPHost=sesta.com add bkamdar
  6. 新しいサーバーで、「csresource」 ユーティリティーを実行してカレンダリソースを有効にします。次に例を示します。


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


    cscal -v -o bkamdar list bkamdar
     csattribute -v list bkamdar
  8. 元のサーバーで、移動した各カレンダを削除します。次に例を示します。


    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

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

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

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

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

csexportcsimport は、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

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

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

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

csdb を使用したカレンダデータベースの管理

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

csdb がデータベースファイルをグループ化する方法

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

カレンダデータベース (caldb)

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 章「削除ログデータベースの管理」も参照してください。

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

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

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

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

/opt/SUNWics5/cal/lib/counter/

特定のデータベースにターゲットを指定できる csdb

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

-t オプションを指定しない場合、csdb は 3 種類すべてのデータベースを対象に動作します。 ただし、checkrebuild の対象はカレンダデータベースだけです。

csdb の管理作業

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


注 –

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


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

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

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

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

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

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


    cd /opt/SUNWics5/cal/sbin
  4. データベースグループの 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 つのターゲットデータベースのグループ (caldbsessdb、または statdb) の指定には、-t オプションを使用します。たとえば、カレンダデータベースのみのデータベースの状態と統計情報を表示するときは、次のように実行します。

    csdb -t caldb list

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

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

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

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

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

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

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

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


    cd /opt/SUNWics5/cal/sbin
  5. カレンダデータベースのコピーに対して check コマンドを実行します。


    ./csdb check dbdir \> /tmp/check.out 2\>&1

    dbdir を指定しない場合、現在のディレクトリに格納されているデータベースに対して check が実行されます。

    check コマンドは大量の情報を生成する可能性があるので、この例で示すように stdoutstderr を含むすべての出力をファイルとして書き出すことをお勧めします。

  6. check の実行が完了したら、出力ファイルを確認します。

    データベースが破損している場合、ホットバックアップのコピーに置き換えることができます。または、rebuild コマンドを実行して、破損したデータベースを再構築することもできます。

Procedureカレンダデータベース (caldb) を再構築するには ? GSE がない場合

破損してしまったカレンダデータベース (caldb) を復元するときは、csdb ユーティリティーの rebuild コマンドを使用します。rebuild コマンドで、すべてのカレンダデータベースを走査して破損の発生を調べます。不整合が検出されると、rebuild コマンドは再構築したカレンダデータベース (.db ファイル) を cal_svr_base/SUNWics5/cal/sbin/rebuild_db ディレクトリに生成します。

rebuild は大量の情報を生成する可能性があるので、stdoutstderr を含むすべての出力をファイルとして書き出すことをお勧めします。

次に示す手順では、rebuild コマンドは GSE (グループスケジューリングエンジン) データベースを再構築しません。

GSE データベースなしにカレンダデータベースを再構築するには、次のように実行します。

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

  2. Calendar Server を停止します。

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

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


    cd /opt/SUNWics5/cal/sbin

    sbin ディレクトリのディスク容量が問題となる場合は、別のディレクトリで rebuild コマンドを実行します。

  5. カレンダデータベースのコピーに対して rebuild コマンドを実行します。


    ./csdb rebuild /tmp/db /tmp/

    データベースディレクトリを指定しない場合、現在のディレクトリに格納されているデータベースに対して rebuild が実行されます。上記の例では、/tmp/ パラメータは、再構築したデータベースの出力先ディレクトリを指定しています。


    注 –

    カレンダデータベースを再構築するときは、常に最新のバックアップコピーを使用してください。

    ただし、膨大なデータが失われ、データベースの定期バックアップで複数のコピーを利用できるときは、最新のコピーから最も古いコピーの順に再構築を行います。この方法の唯一の欠点は、すでに削除されているカレンダコンポーネントが再構築されたデータベースに再表示されることです。

    たとえば、3 つのバックアップカレンダデータベースファイルが db_0601db_0615、および db_0629 というディレクトリに格納されている場合は、次の順序で rebuild コマンドを実行します。

    1. ./csdb rebuild db_0629

      Then check for corruption. If this backup copy is also corrupt, then run rebuild on the next backup copy.

    2. ./csdb rebuild db_0615

      Then check for corruption. If this backup copy is also corrupt, then run rebuild on the next backup copy.

    3. ./csdb rebuild db_0601

      ... etc.

    rebuild コマンドは再構築したデータベースを cal_svr_base/SUNWics5/cal/sbin/rebuild_db ディレクトリに書き込みます。


  6. rebuild の実行が完了したら、rebuild.out ファイルを確認します。再構築が正常に完了した場合、rebuild.out ファイルの最後の行は次のようになります。


    Calendar database has been rebuilt
  7. rebuild の成功を確認したら、再構築したデータベース (.db) ファイルを rebuild_db ディレクトリから運用データベースにコピーします。

  8. 破損したデータベースのディレクトリに共有ファイル (__db.*) が含まれていた場合は、それも運用ディレクトリに移動します。

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

Procedureカレンダデータベースを再構築するには ? GSE データベースを含める場合

サイトにグループスケジューリングを実装している場合は、再構築に GSE を含めることをお勧めします。

カレンダデータベースと GSE データベースの両方を再構築するには、次のように実行します。

手順
  1. GSE データベースにエントリが含まれているかどうかを調べるには、csschedule -v list コマンドを実行して GSE がすべてのエントリの処理を完了するようにします。

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

  3. Calendar Server を停止します。

  4. カレンダデータベースのコピーをまだ作成していない場合は、コピーを作成します。

    データベース (.db) ファイルとログ (log.*) ファイルをコピーします。共有ファイル (__db.*) をコピーする必要はありません。

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

    たとえば、Solaris オペレーティングシステムでは次のように入力します。

    cd /opt/SUNWics5/cal/sbin

    sbin ディレクトリのディスク容量が問題となる場合は、別のディレクトリで rebuild コマンドを実行します。

  6. カレンダデータベースのコピーに対して rebuild コマンドを実行します。

    ./csdb -g rebuild /tmp/db /tmp/

    データベースディレクトリを指定しない場合、現在のディレクトリに格納されているデータベースに対して rebuild が実行されます。上記の例では、/tmp/ パラメータは、再構築したデータベースの出力先ディレクトリを指定しています。


    注 –

    カレンダデータベースを再構築するときは、常に最新のバックアップコピーを使用してください。

    ただし、膨大なデータが失われ、データベースの定期バックアップで複数のコピーを利用できるときは、最新のコピーから最も古いコピーの順に再構築を行います。この方法の唯一の欠点は、すでに削除されているカレンダコンポーネントが再構築されたデータベースに再表示されることです。

    たとえば、3 つのバックアップカレンダデータベースファイルが db_0601db_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 ディレクトリに書き込みます。


  7. rebuild の実行が完了したら、rebuild.out ファイルを確認します。

    再構築が正常に完了した場合、rebuild.out ファイルの最後の行は次のようになります。


    Calendar database has been rebuilt
  8. rebuild の成功を確認したら、再構築したデータベース (.db) ファイルを rebuild_db ディレクトリから運用データベースにコピーします。

  9. 破損したデータベースのディレクトリに共有ファイル (__db.*) が含まれていた場合は、それも運用ディレクトリに移動します。

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


例 16–1 再構築出力のサンプル

出力サンプルでは、予定と仕事のデータベースがそれぞれ 2 回走査されたことを示しています。これはエラーではありません。最初の走査では calprops データベースの情報を確認し、次に再走査して calprops が確実にカレンダデータベースからアクセスできることを確認します。

次の例は、コマンドと、そのコマンドにより生成された出力を示しています。


# ./csdb -g rebuild
Building calprops based on component information.
Please be patient, this may take a while...
Scanning events database...
512 events scanned
Scanning todos database...
34 todos scanned
Scanning events database...
512 events scanned
Scanning todos database...
34 todos scanned
Scanning deletelog database...
15 deletelog entries scanned
Scanning gse database...
21 gse entries scanned
Scanning recurring database...
12 recurring entries scanned
Successful components db scan
Calendar database has been rebuilt
Building components based on calprops information.
Please be patient, this may take a while...
Scanning calprops database to uncover events...
25 calendars scanned
Scanning calprops database to uncover todos...
25 calendars scanned
Successful calprops db scan
Calendar database has been rebuilt

データベースグループを削除するには

カレンダデータベースを削除するには、csdb ユーティリティーの delete コマンドを使用します。Calendar Server は停止している必要があります。

ターゲットデータベース (caldbsessdbstatdb) を指定するときは、-t オプションを指定します。 指定しない場合、csdb は 3 種類すべてのデータベースを削除します。

たとえば、カレンダデータベースを削除するときは、次のように実行します。

csdb -t caldb delete

データベースを削除する前に、csdb ユーティリティーは警告を出力します。

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

Calendar Server により提供される自動バックアップ機能の使用を選択していない場合は、csstored を使用して、バックアップ手順を実装し、データを保護する必要があります。この章では、手動バックアップを実行して、カレンダデータベースファイルを復元するための Calendar Server およびほかの Sun ツールの使用方法を説明します。

/var/opt/SUNWics5/csdb ディレクトリに格納されている Calendar Server データのバックアップと復元には、次のコマンド行ユーティリティーを使用します。


注 –

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 のカレンダデータがある場合は、テクニカルサポートに問い合わせて適切な移行ユーティリティーを入手してください。


Calendar Server データのバックアップ

csbackup ユーティリティーを使用して、カレンダデータベース、指定したカレンダ、ユーザーのデフォルトカレンダをバックアップできます。ここで説明する内容は次のとおりです。

Procedureカレンダデータベースのディレクトリへのバックアップ

手順
  1. データベースファイルの所有者 (icsuser など) としてログインします。

  2. csbackup ユーティリティーの database コマンドを使用します。

    たとえば、カレンダデータベースを backupdir というディレクトリにバックアップするときは、次のように実行します。


    csbackup -f database backupdir
  3. バックアップディレクトリ内のバージョンファイル ics50caldb.conf を調べて、正しいバージョンのデータベースがバックアップされたかどうか確認します。


    注 –

    ターゲットバックアップディレクトリがすでに存在し、-f オプションを指定しない場合は、csbackup ユーティリティーの実行は失敗します。たとえば、backupdir ディレクトリがすでに存在する場合は、そのディレクトリが空であっても次のコマンドの実行は失敗します。


    csbackup database backupdir

    このため、既存のターゲットバックアップディレクトリを指定するとき は、-f オプションを指定して csbackup を実行する必要があります。

    存在しないターゲットバックアップディレクトリを指定し、csbackup にディレクトリを新規作成させることもできます。


Procedure指定したカレンダのファイルへのバックアップ

手順
  1. データベースの所有者 (icsuser) としてログインします。

  2. カレンダを 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

Procedureユーザーデフォルトカレンダのファイルへのバックアップ

手順
  1. データベースの所有者 (icsuser) としてログインします。

  2. ユーザーのデフォルトカレンダを 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

Calendar Server データの復元

csrestore は、csbackup で生成したカレンダデータベース、個々のカレンダ、ユーザーのデフォルトカレンダを復元します。csrestore ユーティリティーを Calendar Server がインストールされているローカルマシンで実行し、最初に Calendar Server を停止する必要があります。データベースのバックアップ時は Calendar Server は稼動していてもかまいません。

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

Procedureカレンダデータベースの復元

手順
  1. データベースの所有者 (icsuser) としてログインします。

  2. csbackup ユーティリティーで作成したバックアップディレクトリからカレンダデータベースを復元するときは、csrestore ユーティリティーの database コマンドを使用します。

    たとえば、backupdir というバックアップディレクトリに保存されているカレンダデータベースを復元するには、次のように実行します。


    csrestore database backupdir

Procedureバックアップディレクトリからのカレンダの復元

手順
  1. データベースの所有者 (icsuser) としてログインします。

  2. csbackup ユーティリティーで作成したバックアップディレクトリに保存されているデータベースから特定のカレンダを復元するときは、-c オプションを指定して csrestore ユーティリティーの database コマンドを実行します。

    たとえば、backupdir というバックアップデータベースディレクトリから jsmithcal というカレンダを復元するときは、次のように実行します。


    csrestore -c jsmithcal calendar backupdir

Procedureバックアップファイルからのカレンダの復元

手順
  1. データベースの所有者 (icsuser) としてログインします。

  2. 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

Procedureユーザーのデフォルトカレンダの復元

手順
  1. データベースの所有者 (icsuser) としてログインします。

  2. 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 BackupTM または Legato Networker® の使用

Sun StorEdge Enterprise Backup ソフトウェア (従来の Solstice Backup) または Legato Networker を使用して Calendar Server データのバックアップと復元を行うこともできます。Sun StorEdge Enterprise Backup ソフトウェアと Legato Networker は似ているので、ここで紹介する手順はどちらの製品にも適用できます。

ただし、Calendar Server のバックアップを行う前に、Sun StorEdge Enterprise Backup または Legato Networker のマニュアルを参照してください。

Sun StorEdge Enterprise Backup ソフトウェアのマニュアルは、http://docs.sun.com で入手できます。

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

StorEdge ツールまたは Legato ツール

/opt/SUNWics5/cal/sbin ディレクトリには、Sun StorEdge または Legato バックアップソフトウェアを使用する上で必要となる次のファイルが格納されています。

icsasm

Calendar Server ASM (Application Specific Module)。ASM は、Sun StorEdge または Legato バックアップソフトウェアがデータをバックアップまたは復元するときに呼び出されるプログラムです。

legbackup.sh

csbackup ユーティリティーを呼び出すスクリプト。

legrestore.sh

csrestore ユーティリティーを呼び出すスクリプト。

ProcedureSun StorEdge Enterprise Backup ソフトウェアまたは Legato Networker を使用して Calendar Server データをバックアップするには

Sun StorEdge または Legato バックアップソフトウェアを使用してカレンダデータベースをバックアップするには、次の手順を実行します。

手順
  1. Sun StorEdge または Legato の nsrfile バイナリファイルを /usr/lib/nsr ディレクトリにコピーします。

  2. /usr/lib/nsr ディレクトリに次のシンボリックリンクを作成します。


    icsasm -\> /opt/SUNWics5/cal/sbin/icsasm nsrfile -\> /usr/lib/nsr/nsrfile
  3. /opt/SUNWics5/cal/sbin ディレクトリに移動し、-l オプションを指定して csbackup ユーティリティーを実行します。次に例を示します。


    cd /opt/SUNWics5/cal/sbin ./csbackup -l

    -l オプションによって、現在のディレクトリの下にバックアップディレクトリイメージが作成されます。このディレクトリ内のファイルは空で、カレンダがバックアップ媒体にどのように格納されるかをバックアッププログラムに伝えるためだけに使用されます。バックアップディレクトリがすでに存在する場合、現在のディレクトリ構造がそのディレクトリに反映されます。

  4. save コマンドを実行してカレンダデータをバックアップします。次に例を示します。次に例を示します。


    /usr/bin/nsr/save -s /opt/SUNWics5/cal/sbin/budir

    Sun StorEdge または Legato のバックアップ GUI でクライアント保存セットを設定してバックアップをスケジューリングし、データベースを定期的にバックアップすることもできます。

    注: .nsr ファイルを変更しないでください。これらのファイルには、バックアップ時に save コマンドと icsasm コマンドが解釈する指令が記録されています。

    Calendar Server は増分バックアップ機能をサポートしていません。バックアップディレクトリはフォルダ構造のイメージに過ぎず、実際のデータを含まないので、この機能を使用しないでください。

    ASCII 以外の文字またはスラッシュ記号 (/) を含む名前を付けてカレンダをバックアップすることはできません。

  5. バックアップ手順を自動化します。

    これまでは手動で行うバックアップ手順について説明してきました。バックアッププログラムの backup コマンドを設定し、バックアッププログラムの save コマンドによって自動的なバックアッププロセスが開始される前に、Calendar Server の csbackup コマンド行ユーティリティーが実行されるようにします。

ProcedureSun StorEdge Enterprise Backup ソフトウェアまたは Legato Networker を使用して Calendar Server データを復元するには

Calendar Server データを復元するには、次の手順を実行します。

手順
  1. Sun StorEdge Enterprise Backup ソフトウェアの nwrestore 機能または recover コマンドを使用して、バックアップされているカレンダ情報を復元します。

    nwrestore を使用した場合は次のメッセージが出力されます。


    "File already exists. Do you want to overwrite, skip, backup, or rename?"
  2. overwrite を選択します。

    このメッセージは、バックアップツリーが単なるディレクトリ階層であるために表示されます。つまり、このツリーは空のファイルだけを含み、この状態は変化しません。

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

Calendar Server には、削除された予定や仕事 (作業) を格納するための削除ログデータベース (ics50deletelog.db) が用意されています。

初期のリリースでは、Calendar Server は削除された予定や作業をデータベースに維持していませんでした。どのコンポーネントが削除されたのかを特定するには、ユーザーは予定または仕事 (作業) の一意の識別子 (uid) または定期予定 ID (rid) を必ず保存しなければなりません。この制限は、WCAP コマンドを使用してクライアントユーザーインタフェース (UI) を作成するインストールに直接影響しました。この制限を解決するため、削除ログデータベースが作成されました。

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

削除ログデータベースの作成

Calendar Server は、その他の Calendar Server データベースファイルと同様に削除ログデータベース (ics50deletelog.db) を csdb ディレクトリ内に自動的に作成します。Calendar Server は、予定と仕事を次のように削除ログデータベースに書き込みます。

削除ログデータベースの照会

削除ログデータベースからエントリを返すには、展開モードまたは圧縮モードの fetch_deletedcomponents WCAP コマンドを使用します。

WCAP コマンドについては、『Sun Java System Calendar Server 6 2005Q4 Developer’s Guide』を参照してください。

削除ログデータベースの破棄

Calendar Server は、「削除ログデータベースの自動破棄」「削除ログデータベースの手動破棄」の両方をサポートしています。

削除ログデータベースの自動破棄

削除ログデータベースのエントリを Calendar Server に自動破棄させることができます。

次の表は、自動破棄を制御する ics.conf ファイルのパラメータを示しています。

表 18–1 削除ログデータベースの自動破棄に適用される設定パラメータ

パラメータ 

説明 

service.admin.purge.deletelog

削除ログデータベース (ics50deletelog.db) エントリの自動破棄を有効化 (yes) または無効化 (no) します。

デフォルトは "no" です。

caldb.berkeleydb.purge.deletelog.interval

削除ログデータベース (ics50deletelog.db) のエントリを自動的に破棄する間隔を秒単位で指定します。

デフォルトは 60 秒です。

caldb.berkeleydb.purge.deletelog.beforetime

削除ログデータベース (ics50deletelog.db) から自動的に破棄するエントリの存続時間を秒単位で指定します。

デフォルトは 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

endtimestarttime は、対象範囲の開始と終了を世界標準時形式 (GMT または UTC とも呼ばれる) で指定します。

cspurge を実行するには、Calendar Server を稼動しているユーザーとグループ (デフォルトでは icsusericsgroup)、またはスーパーユーザー (root) としてログインする必要があります。

たとえば、2003 年 7 月 1 日から 2003 年 7 月 31 日までのエントリを破棄するには、次のように実行します。

cspurge -e 20030731T235959Z -s 20030701T120000Z

詳細は、「cspurge」を参照してください。

削除ログデータベース用の Calendar Server ユーティリティーの使用

次の表は、削除ログデータベース (ics50deletelog.db) をサポートする Calendar Server ユーティリティーを示しています。

表 18–2 削除ログデータベースをサポートするユーティリティー

ユーティリティー 

説明 

cspurge 

削除ログデータベースのエントリを手動で破棄します。 

csbackup と csrestore 

削除ログデータベースのバックアップと復元をサポートします。 

csstats 

削除ログデータベースの統計情報をレポートします。 

csdb 

削除ログデータベースのチェック、復元、再構築をサポートします。 

cscomponents 

削除ログデータベースのエントリの数をリスト表示します (読み取り専用情報)。 

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

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

この付録では、Calendar Server がタイムゾーンを定義、処理する方法について、次の項目を説明します。

タイムゾーンのプロパティーとパラメータについては、次の Web サイトで『RFC 2445, Internet Calendaring and Scheduling Core Object Specification (iCalendar)』を参照してください。

http://www.ietf.org/rfc/rfc2445.txt

Calendar Server タイムゾーンの概要

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 と夏時間用の DAYLIGHTX-NSCP-TZCROSS リストには、そのタイムゾーンで夏時間 (DAYLIGHT) と標準時間 (STANDARD) が切り替わる日付が含まれます。

RRULE プロパティーは、STANDARDDAYLIGHT の規則のパターンを定義します。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』を参照してください。


例 19–1 timezones.ics ファイル内の America/Los_Angeles タイムゾーンの表記

次の例は、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

Calendar Server タイムゾーンの管理

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

新しいタイムゾーンの追加

ここでは、Communications Express ユーザーインタフェースで使用できるように Calendar Server に新しいタイムゾーンを追加する方法について説明します。たとえば、America/Miami 用のタイムゾーンの追加が必要になる場合があります。


ヒント –

新しいタイムゾーンを追加するもっとも簡単な方法は、次の手順で説明する各ファイルで、追加するタイムゾーンに似たタイムゾーンエントリをコピーし、それを編集する方法です。たとえば、America/Miami 用のタイムゾーンを追加するのであれば、各ファイルで America/New_York のタイムゾーンエントリをコピーして編集します。


Procedure新しいタイムゾーンを追加するには

手順
  1. 次のファイルに新しいタイムゾーン用のタイムゾーンブロックを追加します。


    cal_svr_base/SUNWics5/cal/data/timezones.ics

    この場合も、新しいタイムゾーンブロックを追加するもっとも簡単な方法は、追加するタイムゾーンと夏時間 (DST) の時間差などが似ている既存のブロックをコピーする方法です。次に、追加するタイムゾーンに合わせて新しいタイムゾーンブロックに変更を加えます。追加するタイムゾーンに夏時間 (DST) が適用される場合は、それに似たブロックを探します。

  2. 次のファイルで 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\>
  3. 次の 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" を指定します。

    TimeZoneAreaTimeZoneName は、「新しいタイムゾーンの追加」で定義しています。

    offset には、新しいタイムゾーンが GMT と比較して何時間進んでいるか (+)、または遅れているか (-) を指定します。たとえば、新しいタイムゾーンが GMT から4 時間遅れている場合は、時間差として "-04:00" を指定します。

    次に例を示します。


    <timezone type="americas" tzid="America/Miami" 
       offset="-05:00" daylightOffset="-04:00">
  4. 新しいタイムゾーンをユーザー設定のデフォルトタイムゾーンにするときは、次のファイルの timezone エントリを変更します。


    cal_svr_base/SUNWics5/cal/html/default_user_prefs.xml
  5. 新しいタイムゾーンが適用されるように、Calendar Server を停止し (稼動していた場合)、再起動します。

既存のタイムゾーンの変更

ここでは、既存のタイムゾーンを変更する方法について説明します。たとえば、「America/Phoenix」というタイムゾーン名から「US/Arizona」への変更が必要になる場合があります。

Procedure既存のタイムゾーンを変更するには

手順
  1. 次のファイルで、変更するタイムゾーンのタイムゾーンブロックを変更します。


    cal_svr_base/SUNWics5/cal/data/timezones.ics

    タイムゾーン名を変更するときは、TZID エントリの名前を変更します。

  2. 次のファイルで getDisplayNameofTZID テンプレートを修正します。


    cal_svr_base/SUNWics5/cal/html/language/i18n.xsl file

    それぞれの意味は次のとおりです。language には、サイトで使用する言語のディレクトリを指定します。たとえば、英語であれば en、フランス語であれば fr を指定します。

    タイムゾーン名を変更するときは、既存の名前を変更します。

  3. タイムゾーンの変更に合わせて次の 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

    これらのファイルのエントリについては、「新しいタイムゾーンの追加」を参照してください。

  4. 変更がユーザー設定のデフォルトタイムゾーンに影響するときは、次のファイルの “icsTimeZone” エントリを修正します。


    cal_svr_base/SUNWics5/cal/html/default_user_prefs.xml
  5. タイムゾーンの変更が適用されるように、Calendar Server を停止し (稼動していた場合)、再起動します。

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

Calendar Server は、Sun Java System Instant Messaging 6.0 (以降) と統合され、カレンダの予定と作業に関するポップアップアラームを自動的に表示します。

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

ポップアップアラームの概要

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

ポップアップアラームの動作

ユーザーは、カレンダの今後公開される予定や作業の Instant Messenger ポップアップアラームを受信します。これらのポップアップアラームを有効にするには、次の 2 つを行う必要があります。

ポップアップを有効にすると、差し迫った予定や作業が近づくと、予定通知システムで設定されたアラームにより Calendar Server は電子メール通知を送信し、Instant Messaging はポップアップアラームを表示します。

Calendar Server 管理者は、エンドユーザーの電子メール通知またはポップアラームのいずれか一方、または両方を設定できます。たとえば、電子メールアラームを無効にするときは、ics.conf ファイルのパラメータを次のように設定します。

caldb.serveralarms.binary.enable= "no"

ポップアップアラームのアーキテクチャーフロー

Instant Messaging ポップアップアラームを有効に設定すると、次のアーキテクチャーフローで処理されます。

  1. Instant Messaging JMS サブスクライバが Calendar Server の予定と通知を ENS (予定通知サービス) に登録します。

  2. Calendar Server が text/xml 形式または text/calendar 形式で予定または通知を ENS に送信します。

  3. Instant Messaging JMS サブスクライバがカレンダの予定または通知を受け取り、text/calendar 形式のメッセージを生成します。

  4. エンドユーザーがオンライン状態であれば、Instant Messaging サーバーはカレンダの所有者にメッセージを送信します。

  5. 受信者がいれば、Instant Messenger は HTML ポップアップアラームを生成し、メッセージに基づいてエンドユーザーのデスクトップに表示します。

ポップアップアラームの設定

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

ProcedureInstant Messaging サーバーを設定するには

次の Instant Messaging のポップアップを設定するために必要な作業の概要は、便宜上紹介しています。Instant Messaging を設定するには、次の Web サイトで入手可能な Instant Messaging のマニュアルを参照してください。

http://docs.sun.com/coll/1309.2

手順
  1. 新しいパッケージ SUNWiimag をインストールします。

    Instant Messaging のポップアップを使用するには、Java Enterprise System インストーラを使用して Instant Messaging パッケージをインストールする必要があります。

  2. Instant Messaging をインストールしたマシンで、次のディレクトリに移動します。

    cd /etc/opt/SUNWiim/default/config

  3. iim.conf ファイルの次の表に示すパラメータを 1 つ以上編集します。

    次に示すパラメータ値により、予定と作業の両方のポップアップアラームの設定がわかります。iim.conf ファイルにこれらのパラメータが存在しない場合は、追加します。

    パラメータ 

    説明および使用する適切な値 

    JMS Consumers セクション 

     

    jms.consumers

    アラーム名。値を cal_reminder に設定します。

    jms.consumer.cal_reminder.destination

    アラームの出力先。値を enp:///ics/customalarm に設定します。 

    jms.consumer.cal_reminder.provider

    プロバイダ名。ens に設定します。この値は、必ず JMS Providers セクションの jms.providers の名前と同じにしてください。

    jms.consumer.cal_reminder.type

    設定するアラームの種類。値を topic に設定します。

    jms.consumer.cal_reminder.param

    アラームパラメータ。値を "eventtype=calendar.alarm" (引用符を含む) に設定します。

    jms.consumer.cal_reminder.factory

    C++ ファクトリ名。値を次のように設定します。 

    com.iplanet.im.server.
    JMSCalendarMessageListener

    JMS Providers セクション 

     

    jms.providers

    プロバイダ名。値を ens に設定します。この値は、必ず JMS Consumers セクションの jms.consumer.cal_reminder.provider でリスト表示された名前と同じにしてください。

    jms.provider.ens.broker=cal.example.com

    ENS が待機するポート番号。ics.conf ファイルのパラメータ service.ens.port で指定したポートに設定します。デフォルトは 57997 です。

    jms.provider.ens.factory

    使用する C++ ファクトリ。com.iplanet.ens.jms.EnsTopicConnFactory に設定します。

    Calendar Server の一般的なパラメータ 

     

    iim_agent.enable

    Calendar エージェントを有効にします。引用符も含めて、値を次のように設定します。 

    iim_agent.enable="true"

    iim_agent.agent-calendar.enable

    Calendar エージェントを有効にするコンポーネントを読み込みます。引用符も含めて、値を次のように設定します。 

    iim_agent.agent-calendar.enable="true"

    agent-calendar.jid

    Calendar エージェントの JID。この値を次のように設定します。 

    agent-calendar.jid=calimbot.server .domain

    agent-calendar.password

    Calendar エージェントのパスワード。この値を次のように設定します。 

    agent-calendar.password=password

    iim_server.components

    この値を次のように設定します。 

    iim_server.components=agent-calendar

  4. imadmin コマンド行ユーティリティーが格納されているディレクトリに移動します。

    cd /opt/SUNWiim/sbin

  5. imadmin を使用して Calendar エージェントを起動します。

    imadmin start agent-calendar

    Calendar エージェントは、Calendar Server ユーザーにポップアップ機能を提供する Instant Messaging コンポーネントです。Instant Messaging に用意されているツールを使用すると、Calendar エージェントの起動、停止、再起動、または状態の確認、さらにはログファイルによるアクティビティーの監視を行うことができます。


    注 –

    stopstart、および refresh コマンドが含まれたスクリプトがある場合は、そこに Calendar エージェントを追加してください。


    imadminト および Calendar エージェントについては、『Sun Java System Instant Messaging 7 2005Q1 管理ガイド』を参照してください。

ProcedureCalendar Server を設定するには

始める前に

次の表に示す ics.conf パラメータに、示された値が設定されているかどうかを確認します。設定されていない場合や、パラメータをカスタマイズする場合は、次の手順を実行します。

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

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

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

  4. 次の表に示すように 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" です。

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

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

    cal_svr_base /SUNWics5/cal/sbin/start-cal

ProcedureInstant Messenger を設定するには

Calendar Server の予定と作業のポップアップアラームを受信するには、エンドユーザーは各自の Instant Messenger を次のように設定する必要があります。

手順
  1. メイン ウインドウで「ツール」メニューから「設定」を選択します。

  2. 「設定」ウィンドウで、「アラート」タブをクリックします。

  3. カレンダリマインダを表示」オプションにチェックマークを付けます。

  4. 「了解」をクリックします。

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

Calendar Server のパフォーマンスを向上させるには、次のオプション設定を検討します。

LDAP ディレクトリサーバーのインデックス設定

Calendar Server が LDAP ディレクトリサーバーにアクセスするときのパフォーマンスを向上させるには、LDAP 設定ファイルの次の属性にインデックスを追加します。

icsCalendar

この属性は、カレンダユーザーまたはリソースのデフォルトカレンダの検索に使用されます。実在 (pres)、等価 (eq)、部分文字列 (sub) のいずれかのインデックスタイプを指定します。

icsCalendarOwned

この属性は、ユーザーが所有しているほかのカレンダの検索に使用されます。実在 (pres)、等価 (eq)、部分文字列 (sub) のいずれかのインデックスタイプを指定します。「DWP 環境でのカレンダ検索のパフォーマンス向上」も参照してください。

mailmailAlternateAddress

これらの属性は、ユーザーの一次電子メールアドレスと代替電子メールアドレスを指定します。「ユーザーとリソースの作成」および 「Calendar Server ユーティリティー (csuser enable)」も参照してください。

ディレクトリサーバーインデックスの追加方法については、次の Web サイトにある Directory Server のマニュアルを参照してください。

http://docs.sun.com/coll/1316.1

DWP 環境でのカレンダ検索のパフォーマンス向上

DWP 環境にある場合、つまり、複数のバックエンドサーバーにカレンダベースが分散している場合、カレンダデータベース内のカレンダの検索に非常に時間がかかる場合があります。最初に LDAP エントリを探し、カレンダが存在している DWP ホストで直接検索すると、時間を短縮できます。

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

ProcedureLDAP を対象とするカレンダ検索を有効にするには

最初に LDAP ディレクトリ、次にカレンダデータベースを対象とするカレンダ検索を有効にするには、次の手順を実行します。

手順
  1. ics.conf ファイルの service.calendarsearch.ldap パラメータを編集し、そのパラメータを次のようにデフォルトの “yes” に設定します。

    service.calendarsearch.ldap="yes"

  2. 次のようにカレンダサービスを再起動します。

    start-cal


    注 –

    公開カレンダへの匿名アクセスを許可している場合は、LDAP を対象とするカレンダ検索を無効にすることもできます。実際に、Communications Express では、パラメータ値を “no” に設定することをお勧めします。


Procedureインデックスを作成して検索のパフォーマンスを向上させるには

手順
  1. インデックスを作成することにより、カレンダ検索のパフォーマンスを向上させることができるかどうかを調べるには、次の LDAP コマンドを実行します。


    ldapsearch -b "base" "(&(icscalendarowned=*user*)
       (objectclass=icsCalendarUser))"

    ここで、base は、Calendar Server のユーザーとリソースのデータが格納されているディレクトリサーバーの LDAP ベース DN であり、user は、エンドユーザーが検索ダイアログで入力できる値です。

    60,000 のエントリを使ったテストでは、icsCalendarOwned のインデックスを設定しない場合、前述した検索に要した時間は 50 〜 55 秒でした。インデックスの設定後に検索に要した時間は、約 1 〜 2 秒でした。

  2. comm_dssetup.pl を実行して、適切な LDAP 属性に、または少なくとも icsCalendarOwned にインデックスを設定します。

    comm_dssetup.pl は、この属性やその他の多くの属性にインデックスを設定して、さまざまな方法でパフォーマンスを向上させます。comm_dssetup.pl を実行していない場合、または実行したがインデックス設定を行わなかった場合、ユーティリティーを再実行してインデックス設定を行うか、または Directory Server ツールを使用してインデックスを設定できます。

    comm_dssetup.pl によるインデックス設定については、「属性のインデックス」を参照してください。

    ディレクトリサーバーインデックスの追加方法については、次の Web サイトにある Directory Server のマニュアルを参照してください。

    http://docs.sun.com/coll/1316.1

ワイルドカード検索の無効化によるカレンダ検索のパフォーマンスの向上

デフォルトでは、Calendar Server でのワイルドカード検索は無効になっています。つまり、グラフィカルユーザーインタフェース (GUI) を使用してカレンダを検索するとき、または、カスタムインタフェースで search_calprops.wcap を実行するときは、WCAP コマンドを使用して渡される検索文字列との完全一致を検索します。

ics.conf ファイルで次の行のコメントを外して (行頭の感嘆符 (“!”) を削除して) ワイルドカード検索を有効にしている場合は、パフォーマンスにマイナスの影響を与える可能性があります。

!service.calendarsearch.ldap.primaryownersearchfilter = "(&(|(uid=*%s*)(cn=*%s*))(objectclass=icsCalendarUser))"

パフォーマンスに与えるワイルドカードの影響を調べるには、行の先頭に感嘆符 (“!”) を挿入して行をもう一度コメントアウトします。

CLD プラグインのパフォーマンスの向上

カレンダデータベースからカレンダにアクセスする前に、ユーザーのカレンダをどのバックエンドマシンに格納するかを決める必要があります。適切なバックエンドマシンを見つけるために、システムではユーザーエントリの LDAP ディレクトリを検索し、icsDWPHost 属性を取り出します。この検索は非常に時間がかかり、カレンダデータにアクセスするたびに実行する必要があります。すべてのユーザーセッションでは、データベースのアクセスが多数発生し、LDAP の検索も多くなります。時間を節約してパフォーマンスを向上させるには、次のように ics.conf ファイルを編集して CLD キャッシュを有効にします。

caldb.cld.cache.enable="yes"

LDAP データキャッシュは、ユーザー ID およびそれに関連する icsDWPHost 属性を格納します。LDAP でユーザーのエントリを検索する前に、システムは、キャッシュにそのユーザーの ID がないかどうかチェックします。キャッシュにユーザー ID があれば、そこに格納されている icsDWPHost 属性からバックエンドのホスト名を取り出します。キャッシュにユーザー ID がない場合、システムは LDAP 検索を実行して、ユーザー ID と属性を CLD キャッシュにコピーします。このあとは、キャッシュでユーザー ID が見つかるため、ユーザーのカレンダデータへのアクセスが速くなります。

LDAP データキャッシュのパフォーマンスの向上

LDAP データキャッシュが有効になっている場合は、ics.conf パラメータを使用してキャッシュを調整できます。それには、次の表に示すパラメータを 1 つ以上調整します。


注 –

デフォルトでは、LDAP データキャッシュが有効になっています。LDAP データキャッシュを無効にするには、次のように設定します。local.ldap.cache.enable="no"


表 21–1 LDAP データキャッシュのカスタマイズに使用される ics.conf パラメータ

パラメータ 

説明と値 

local.ldap.cache

.checkpointinterval

チェックポイント間でチェックポイントスレッドがスリープするまでの秒数。デフォルトは “60” です。

高アクティビティーの LDAP では、キャッシュをできるだけ最新のものにしておくため、間隔を短くすることをお勧めします。同時に、キャッシュの更新が頻繁になるほど、システムのオーバーヘッドが高くなることにも留意してください。 

local.ldap.cache.

circularlogging

処理が完了したあとに LDAP データキャッシュのデータベースログファイルを削除するかどうかを指定します。デフォルトは “yes” です。

古いログファイルを削除するカスタムのクリーンアップルーチンがある場合を除いて、このパラメータは変更しないでください。 

local.ldap.cache.

logfilesizemb

チェックポイントファイルの最大サイズを M バイト単位で指定します。デフォルトは "10”M バイトです。

高アクティビティーの LDAP の場合、チェックポイント間隔が終わる前にこのファイルがいっぱいになる可能性があります。経験に基づいて、できるだけログの実サイズに近い値を設定します。 

local.ldap.cache.

maxthreads

LDAP データキャッシュデータベースの最大スレッド数を指定します。デフォルトは “1000” です。

高アクティビテーの LDAP では、スレッド数を増やすことをお勧めします。そうすることにより CPU の使用率が高くなります。LDAP アクティビティーが最小の場合にのみ、スレッド数を減らします。 

local.ldap.cache.

mempoolsizemb

共有メモリーのサイズを M バイト単位で指定します。デフォルトは “4”M バイトです。

local.ldap.cache.

entryttl

LDAP データキャッシュエントリの存続時間 (TTL) を秒単位で指定します。デフォルトは “3600” 秒 (1 時間) です。

キャッシュがあまりにも早くいっぱいになる場合は (高アクティビティー)、TTL 時間を減らします。ただし、これにより全体の LDAP データベースのアクセス数が増加し、全体的にシステムを低下させる可能性があります。 

local.ldap.cache.

cleanup.interval

キャッシュデータベースのクリーンアップの間隔を秒単位で指定します。デフォルトは “1800” 秒 (30 分) です。

システムにより有効期限が切れたエントリが削除されます。時間間隔は、エントリの TTL 時間と同一である必要はありません。ただし、同期させるとより効率的になります。 

local.ldap.cache.

stat.enable

LDAP データキャッシュへのアクセスをログに記録し、ログファイルに統計情報を出力するかどうかを指定します。デフォルトは “no” です。

パフォーマンス向上のために、このパラメータはデバッグモードでのみ使用してください。 

local.ldap.cache.

stat.interval

統計情報レポートをログファイルに書き込む間隔を秒単位で指定します。デフォルトは “1800” 秒 (30 分) です。

これは、local.ldap.cache.stat.enable が有効になっている場合にのみアクティブになります。間隔を短くすると、問題を特定するのに役立ちます。間隔を長くすると、システムロードが減少します。 


注 –

Communications Express では、データキャッシュを無効にすることをお勧めします。


LDAP SDK キャッシュの調整

項目をキャッシュしておく時間、およびキャッシュのサイズを制御するいくつかのパラメータがあります。

キャッシュを調整するには、次の表に示すパラメータを 1 つ以上編集します。

表 21–2 LDAP SDK キャッシュを設定するための ics.conf パラメータ

パラメータ 

説明とデフォルト値 

service.ldapmemcachettl

このパラメータは現在実装されていません。ldap_cache ディレクトリの内容を手動で削除してから、Calendar Server を再起動する必要があります。

service.ldapmemcache"yes" を指定した場合、このパラメータは項目をキャッシュしておける最大秒数の設定に使用されます。“0” を指定した場合、項目をキャッシュしておける時間に制限が適用されなくなります。デフォルトは “30” です。

service.ldapmemcachesize

service.ldapmemcache"yes" を指定した場合、このパラメータを使用して、キャッシュに使用できるメモリーの最大容量をバイト単位で設定します。“0” を指定した場合、キャッシュ容量の制限は適用されなくなります。デフォルトは “131072” です。

自動バックアップの調整

ディスクに保存するバックアップ数と必要性とのバランスを取って、使用可能なディスク容量を越えないようにする必要があります。アーカイブとホットバックアップに必要なディスク容量を管理するために、さまざまな ics.conf パラメータの設定を変更できます。これらのパラメータにより、一度に保存するバックアップのコピー数、および古いコピーのクリーンアップを行うディスク容量のしきい値が決定されます。

アーカイブ、およびホットバックアップのそれぞれバックアップタイプ用に調整できる次の 3 種類のパラメータがあります。

Calendar Server では、ディスク容量のしきい値を超えずに可能な最大日数の間、バックアップを保持します。そのため、現在のバックアップでディスク使用率がしきい値を超える場合、システムは古いバックアップコピーを破棄し、ディスク容量の使用率がしきい値より低くなるかどうかを確認します。システムは、別のバックアップコピーを削除することにより、ディスク上のバックアップ数が最小バックアップコピー数を下回るか、ディスク容量の使用率がしきい値を下回るまで、古いバックアップコピーを破棄し続けます。

その結果、しきい値のパラメータによりディスク容量のバックアップ使用を管理できます。また反対に、許容されるディスク容量やコピーを調整することにより、ディスクで保持するバックアップ量を管理できます。

次の表は、ディスク容量とディスクに保持されるバックアップ数を制御する ics.conf パラメータを一覧表示しています。

表 21–3 ディスク上に保持するバックアップ数の設定に使用される ics.conf パラメータ

ics.conf パラメータ 

デフォルトの設定 

説明 

caldb.berkeleydb.hotbackup.mindays

ディスク上に保持するホットバックアップの最小日数です。 

caldb.berkeleydb.hotbackup.maxdays

ディスク上に保持するホットバックアップの最大日数です。 

caldb.berkeleydb.hotbackup.threshold

70 

ホットバックアップに使用されるディスク容量の割合 (パーセント) です。しきい値を超えた古いコピーの廃棄をトリガーします。 

caldb.berkeleydb.archive.mindays

ディスク上に保持するアーカイブバックアップの最小日数です。 

caldb.berkeleydb.archive.maxdays

ディスク上に保持するアーカイブバックアップの最大日数です。 

caldb.berkeleydb.archive.threshold

70 

アーカイブバックアップに使用されるディスク容量の割合 (パーセント) です。しきい値を超えた古いコピーの廃棄をトリガーします。 

複数 CPU 間でのロードバランスの使用

サーバーに複数の 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 のタイムアウト値

次の表は、管理サービス (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 分) です。 

エンドユーザーの HTTP タイムアウト値

次の表は、エンドユーザーに適用される、ics.conf ファイル内の Calendar Server HTTP タイムアウトパラメータを示しています。

表 21–5 ics.conf に設定され、エンドユーザーに適用される HTTP タイムアウト値 (cshttpd サービス)

パラメータ 

説明 

service.http.idletimeout 

cshttpd サービスがアイドル状態の HTTP 接続をタイムアウトにするまでの秒数を指定します。

デフォルトは "120" 秒 (2 分) です。

service.http.resourcetimeout 

cshttpd サービスがリソースカレンダの HTTP セッションをタイムアウトにするまでの秒数を指定します。

デフォルトは "900" 秒 (15 分) です。

service.http.sessiontimeout 

cshttpd サービスが HTTP セッションをタイムアウトにするまでの秒数を指定します。

デフォルトは "1800" 秒 (30 分) です。

GSE キューのタイムアウト値

ics.conf ファイルの次のパラメータは、要求されたジョブを Calendar Server が GSE (グループスケジューリングエンジン) キューで走査するまでの時間を秒単位で指定します。

gse.belowthresholdtimeout="3"

キューに含まれるジョブが許容最大しきい値より多い場合、最後のスレッドが常にキューをもう一度走査します。このため、この設定はジョブの数が最大しきい値より少ない場合にだけ適用されます。

デフォルトは "3" です。この値を大きくすると、サーバーがキューを走査する回数が減り、全体的なパフォーマンスを向上できます。ただし、予定のボリュームが増大したためにキューが大きくなりすぎた場合、キューの処理速度を上げるための時間が短くなる可能性があります。これによって全体のパフォーマンスは低下しますが、予定はすぐに更新されます。

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

この章では、システムに問題があるかどうか、またその原因を調べるためのトラブルシューティングの方法について説明します。この章で説明する内容は次のとおりです。

デバッグ情報の有効化

システム全体を「デバッグモード」にする ics.conf パラメータはありませんが、ここでは有用なデバッグ情報を取得する方法について説明します。


注 –

パフォーマンスにマイナスの影響を与えるため、必要でない場合は、必ず、過度なログ記録および監視は無効にしてください。


ログレベルを上げる

次の表に示すパラメータを使用して、ログの詳細度を上げます。

パラメータ 

説明とデフォルト値 

logfile.loglevel

DEBUG に設定して、CRITICALALERTERRORWARNINGNOTICE、および INFORMATION を含む、すべてのレベルがログ記録されるようにします。この設定はすべてのログに適用されます。

使用可能な別のログについては、「Calendar Server ログファイルの使用」を参照してください。

LDAP キャッシュへのアクセスログの有効化

LDAP データキャッシュのすべてのアクセスをログに記録し、そのログ (レポート) を出力するには、次の表に示す ics.conf パラメータを設定します。

パラメータ 

説明とデフォルト値 

local.ldap.cache.stat.enable

LDAP データキャッシュへのアクセスをログに記録し、ログファイルに統計情報を出力するかどうかを指定します。デフォルトは “no” です (統計情報はログ記録されない)。統計情報のログを有効にするには、“yes” に設定します。

パフォーマンス向上のために、このパラメータはデバッグモードでのみ使用してください。 

local.ldap.cache.stat.interval

統計情報レポートをログファイルに書き込む間隔を秒単位で指定します。デフォルトは “1800” 秒 (30 分) です。

これは、ログが有効になっている場合にのみアクティブになります。間隔を短くすると、問題を特定するのに役立ちます。間隔を長くすると、システムロードが減少します。 

LDAP キャッシュのクリア

現在、Calendar Server には LDAP キャッシュデータを失効させるためのロジックは存在しません。ldap_cache ディレクトリの内容を手動で削除し、Calendar Server を再起動する必要があります。

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

手順
  1. Calendar Server を停止します。

  2. /var/opt/SUNWics5/csdb/ldap_cache ディレクトリ内のファイルをすべて削除します。ただし、ldap_cache ディレクトリ自体は削除しないでください。

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

Calendar Server ユーティリティーによるシステムの監視

システムを監視するには、次の Calendar Server ユーティリティーを使用します。

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

LDAP の問題のトラブルシューティング

ホストされた環境を最初に作成するときに、ドメイン、コンテナ、ユーザー、リソースの適切なエントリを追加して、LDAP に DC ツリーを作成する必要があります。cscal などの Calendar Server のユーティリティーを使用するときに DC ツリーが存在しないと、次のようなエラーメッセージが表示される可能性があります。"Initialization failed .... exiting"

DC ツリーには、DC ツリーのルートに少なくとも 1 つの (デフォルト) ドメインが含まれていることを確認します。「新規のホストされたドメインの作成」に記載されている方法を使用して DC ツリー構造を作成します。

移行ユーティリティーのトラブルシューティング

Calendar Server には、カレンダデータベースおよび LDAP ディレクトリを移行するためのいくつかのユーティリティーが用意されています。ここで説明する内容は次のとおりです。

テクニカルサポートに問い合わせる前に必要なこと

一般に、移行ユーティリティーを使用して問題が生じた場合、次の情報を収集してから、テクニカルサポートにお問い合わせください。

移行ユーティリティーの入手先

さまざまな移行ユーティリティーおよびそのマニュアルは、次の一覧に示す場所にあります。

スキーマ移行ユーティリティー (commdirmig)

このユーティリティーは、個別にインストール可能なコンポーネントである Delegated Administrator にバンドルされています。このユーティリティーは LDAP ディレクトリを Schema 1 から Schema 2 に移行します。このユーティリティーについては、『Sun Java System Communications Services 6 2005Q4 Schema Migration Guide』を参照してください。

Calendar Server 5 から Calendar Server 6 への移行ユーティリティー ( cs5migrate)

テクニカルサポートサイトにはユーティリティーとそのマニュアルを含む移行バンドルが用意されています。

Calendar Server 移行ユーティリティー (csmig)

このユーティリティーは Calendar Server にインストールされています。マニュアルは 第 4 章「データベース移行ユーティリティー」に記載されており、トラブルシューティングの節が含まれています。ホストされたドメインおよび LDAP カレンダ検索データベース (CLD) プラグインを使用している場合は、このユーティリティーを実行する必要があります。

Calendar Server 仮想ドメイン移行ユーティリティー (csvdmig)

このユーティリティーは Calendar Server にインストールされています。マニュアルは、第 4 章「データベース移行ユーティリティー」に記載されています。ホストされたドメイン用のカレンダデータベースおよび LDAP ディレクトリのエントリを準備するには、このユーティリティーを使用します。

Calendar Server 2 から Calendar Server 6 への移行ユーティリティー ( ics2migrate)

このユーティリティーは Calendar Server にインストールされています。マニュアルは、第 4 章「データベース移行ユーティリティー」に記載されています。Calendar Server 2 データベースを移行して Calendar Server 5 との互換性を持たせるには、このユーティリティーを使用します。

Netscape Calendar Server 4 から Calendar Server 5 への移行ユーティリティー (ncs4migrate)

このユーティリティーは、テクニカルサポートサイトからのみ入手できます。ユーティリティーパッケージにはマニュアルが含まれています。このユーティリティーは、Netscape Calendar Server 4 を Calendar Server 5 に移行します。移行元のデータベースが整合していないため、これらの移行には特に注意を要します。手動による多くの作業が必要になることも珍しくありません。このユーティリティーは、テクニカルサポートサイトからのみ入手できます。ユーティリティーパッケージにはマニュアルが含まれています。このユーティリティーは、Netscape Calendar Server 4 を Calendar Server 5 に移行します。これらの移行には特に注意を要します。ユーティリティーを実行できるようになるまでに、移行元のファイルに対して多くの作業が必要になることも珍しくありません。移行の計画をサポートする Professional Services を利用されることをお勧めします。

Calendar Server のトラブルシューティング

ここでは、データベース以外の問題のさまざまなトラブルシューティングについて説明します。ここで説明する内容は次のとおりです。


ヒント –

さらに、次の SSL の章にも、SSL に関するトラブルシューティングの節があります。

「SSL のトラブルシューティング」


カレンダサービスに対する ping の実行

サービスが特定のポート番号で待機していることを確認するには、「cstool」 ユーティリティーの ping コマンドを実行します。サービスに対して ping を実行しても、サービスが実際に稼動しているかどうかは検証されません。ソケット接続が受け付けられるかどうかが検証されます。

cstool のサービスオプション

Calendar Server サービスには次のオプションがあります。

http

HTTP サービス (cshttpd)

admin

管理サービス (csadmind)

ens

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


注 –

DWP サービス (csdwpd) や通知サービス (csnotifyd) に対して ping を実行することはできません。


cstool の例

たとえば、calserver というホスト名のマシンに対して ping を実行し、cshttpd サービスがポート 80 で待機しているかどうかを確認するには、次のように実行します。

cstool -p 80 -h calserver ping http

デフォルトでは、cstool は 120 秒間応答を待ちますが、-t timeout オプションを使用してこの値を変更することができます。

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


注 –

cstool を実行するには、Calendar Server が稼動している必要があります。


Procedurestart-cal の問題の解決

start-cal を実行したときに起動しないカレンダサービスがある場合は、再起動する前に起動したサービスを終了する必要があります。たとえば、enpdcsnotifyd、および csadmind が起動しても cshttpd が起動しなかった場合は、enpdcsnotifyd、および csadmind を終了する必要があります。

カレンダサービスを起動するには、次のように実行します。

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

  2. サービスを終了して、再起動するには、start-cal を使用します。次に例を示します。

    cal_svr_base/SUNWics5/cal/sbin/start-cal

    start-cal は、さまざまなカレンダサービスを起動する前に、まず stop-cal コマンドを実行します。

  3. stop-cal が終了に失敗した場合は、いくつかの子プロセスが終了に失敗した可能性があります。この場合の処理については、「stop-cal の問題の解決」を参照してください。

stop-cal の問題の解決

Calendar Server のシャットダウン時には、考慮する必要がある 2 つの別個の問題があります。

Procedure子プロセスを停止するには

stop-cal を実行したあと、いくつかの子プロセスが停止していない場合があります。たとえば、stop-cal によって cshttpd 親プロセスは停止しているのに、一部の cshttpd 子プロセスが停止していないことがあります。このような場合は、次の手順で、残りの Calendar Server プロセスを個別に停止させる必要があります。

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

  2. サービスごとに ps コマンドを実行し、残っている Calendar Server プロセスのプロセス ID (PID) を特定します。


    ps -elf | grep cs-process
    

    ここで、cs-processenpdcsnotifydcsdwpdcsadmind、または cshttpd です。次に例を示します。


    ps -elf | grep cshttpd
  3. kill -15 コマンドに終了していない各プロセスの PID を指定して、プロセスを終了します。例: kill -15 9875

  4. それぞれの ps コマンドをもう一度実行し、すべての Calendar Server プロセスが終了していることを確認します。


    Calendar Server プロセスがまだ稼動しているときは、kill -9 コマンドを実行して終了します。例: kill -9 9875

    注 –

    Linux システムで Calendar Server を実行していて、ps コマンドを使用してカレンダプロセスを検索すると、結果がわかりにくく見えることがあります。Linux では、ps コマンドは、プロセスのリストではなく実行しているスレッドのリストを返します。プロセスだけが表示されるようにするための既知の解決策はありません。


Procedure不正シャットダウンしたあとで回復するには

Calendar Server が正しくシャットダウンしなかった場合は、次の手順を実行します。

手順
  1. 前の手順 (「stop-cal の問題の解決」) を実行します。

  2. LDAP データキャッシュデータベースのディレクトリ内のすべてのファイルを手動で削除します。

    ファイルが残っていると、データベースが破損する可能性があります。ファイルを削除するには、次のように実行します。

    1. LDAP データキャッシュのディレクトリに移動します。

      デフォルトでは /opt/SUNWics5/csdb/ldap_cache ですが、ics.conf ファイルの local.ldap.cache.homedir.path パラメータで指定されるディレクトリを使用してください。

    2. ディレクトリ内のすべてのファイルを削除します。

      例: rm *.*

    3. すべてのファイルが削除されたことを確認します。

      例: ls

  3. 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』を参照してください。

バックエンドサーバーに接続できない

  1. 応答しているかどうか調べるには、バックエンドサーバーに対して ping を実行します。

    応答している場合は、手順 3 に進みます。応答していない場合は、その原因を調べ、ふたたび動作するようになったら手順 3 に進みます。

  2. CLD キャッシュをクリアします。「CLD キャッシュのクリア」を参照してください。

    CLD キャッシュオプションを使用していて、ics.conf パラメータのサーバー名を更新した場合は、CLD キャッシュをクリアしてサーバー名を消去するとよいでしょう。CLD キャッシュに古いエントリが残されていると、フロントエンドサーバーが正しいバックエンドサーバーに接続できなくなったり、Calendar Server が移動後のカレンダを見つけられなくなります。

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

カレンダが見つからない

CLD キャッシュオプションを使用していて、1 つ以上のカレンダを別のバックエンドサーバーに移動した (または、バックエンドサーバーの名前を変更した) 場合は、次の手順を実行します。

  1. 次に記載されている手順に従ってカレンダを移動していることを確認します。

    「ユーザーカレンダの管理」を参照してください。

  2. CLD キャッシュをクリアします。「CLD キャッシュのクリア」を参照してください。

    1 つ以上のカレンダを別のバックエンドサーバーに移動すると、CLD キャッシュは無効になります。再読み込みするには、キャッシュをクリアする必要があります。そうすると、キャッシュが再構築されます。

プロキシ認証を使用してログインしようとすると「承認されていない」が表示される

  1. service.http.allowadminproxy“yes” に設定されていることを確認します。

  2. admin-user に Calendar Server 管理者の権限があることを確認します。

  3. admin-password が正しいことを確認します。

  4. calendar-user が有効な Calendar Server ユーザーであることを確認します。

正しく完了しない検索のトラブルシューティング

LDAP ディレクトリサーバー設定の nsslapd-sizelimit 属性と nsLookthroughLimit 属性は、検索が正しく終了するように十分なサイズに設定する必要があります。nsSizeLimit が十分なサイズでない場合は、一部の結果が欠落したり、検索結果が表示されなくなることがあります。nsLookthroughLimit が十分なサイズでない場合は、検索が完了しないことがあります。

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

Procedure制限属性の値が適切かどうかを調べるには

手順
  1. これらの属性に適切な値が設定されているかどうかを調べるには、次のコマンドを実行します。

    ldapsearch -b "base " "(&(icscalendarowned=*user*)(objectclass=icsCalendarUser))"

    ここで、base は、Calendar Server のユーザーとリソースのデータが格納されているディレクトリサーバーの LDAP ベース DN であり、user は、エンドユーザーがユーザーインタフェースの検索ダイアログで入力できる値です。

  2. LDAP サーバーがエラーを返す場合、nsSizeLimit または nsLookthroughLimit パラメータの値が十分でない可能性があります。

Procedure制限属性を適切な値に設定するには

これらの属性の DN は次のとおりです。

dn: cn=config,cn=ldbm databases,cn=plug ins,cn=config

手順
  1. nsLookthroughLimit の値を動的に設定するには、ldapmodify を使用します。

    この属性を変更するために Directory Server を終了して再起動する必要はありません。

    デフォルト値は 5000 です。検索結果が表示されない場合、この値を大きくすることができます。ただし、そうすると LDAP サーバーのパフォーマンスが低下します。

    制限を -1 に設定して、制限の適用を解除することもできます。ただし、システムがハングすることが想定されるため、慎重に行ってください。

  2. nsslapd-sizelimit をより大きい値に設定する場合は、次の手順を実行する必要があります。

    1. Directory Server を停止します。

    2. dse.ldif ファイルを編集します。

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


      注 –

      ldapmodify の使用方法および dse.ldif ファイルの編集方法については、次の Web サイトで入手できる Directory Server のマニュアルを参照してください。

      http://docs.sun.com/coll/1316.1


csstored のわずらわしい日常的なメッセージを無効にする

start-cal コマンドは、csstored プロセスが設定されていない場合でも、デフォルトで csstored プロセスを起動します。設定されていない csstored プロセスは、csstored を実行しているすべてのマシンで 24 時間ごとに設定されていないことを伝えるメッセージを出力します。

csstored を未設定の状態で実行しないようにすることによって、メッセージを無効にできます。csstored プロセスの実行を無効にするには、メッセージが生成されるすべてのマシンで、次の ics.conf パラメータを設定します。

service.store.enable=”no”

自動バックアップ作成のために csstored を設定しているマシンでは、プロセスを無効にしないでください。

データベース問題の処理

ここでは、Calendar Server データベースに関するさまざまな問題について説明します。

Berkeley データベースのツールの検索

多くのトラブルシューティングの手順では、Berkeley データベースのユーティリティープログラムへのアクセス権が必要です。これらのユーティリティープログラムは、Calendar Server バンドルで入手できますが、これらのプログラムはサポートされていません。詳細は、直接 Sleepycat Software (http://www.sleepycat.com) から入手できます。

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

Berkeley データベースユーティリティーにアクセスするには

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 つ以上のファイルおよびファイル内に含まれるデータベースの構造を検証します。 

Procedureデータベースのデッドロックを検出して解決するには

Berkeley データベースがデッドロック状態にある場合は、データベースをリセットする必要があります。できるだけ早期にこの状態を検出することが重要です。

システムが定期的にデータベースをチェックして、デッドロック状態を検出し、管理者に通知するようにするには、次のように実行します。

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

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

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

  4. 必要に応じて、ics.conf ファイルを編集して次の値を設定します。

    local.caldb.deadlock.autodetect=”yes”


    注 –

    このパラメータが “yes” に設定されている場合は、ロック領域を監視する db_deadlock デーモンが起動されます。


データベースの破損の検出

カレンダデータベースは、システムリソースの競合、ハードウェアの障害、アプリケーションエラー、データベース障害、人為的な原因など、さまざまな原因で破損することがあります。ここでは、カレンダデータベースの破損を検出する方法について説明します。

データベース破損の基本的考え方

データベースが破損しないとだれにも保証はできません。ですが、データの損失と運用停止時間を最小限にとどめることができます。破損を早期に検出するには、厳密にデータベースおよびカレンダサービスを監視することが重要です。頻繁に完全なバックアップを行っておくことが、破損が検出された場合に復元する秘訣です。

カレンダデータベースで起こりうる破損には、2 つのレベルがあります。

ログファイルの監視

データベース破損の兆候を示すエラーメッセージについて、アラームログを含む Calendar Server ログファイルを監視します。ログファイルについては、「Calendar Server ログファイルの使用」を参照してください。

ALERTCRITICALERROR、および WARNING レベルのエラーについて、ログファイルを定期的に調べてください。これらのエラーが見つかったときは、Calendar Server の動作で考えられる問題について調査します。NOTICE および INFORMATION レベルのログ予定は、Calendar Server の通常動作中に生成されることがあります。これは、サーバーアクティビティの監視に役立つように提供されています。

データベースディレクトリ内のトランザクションログファイルを削除しないでください。トランザクションログファイルにはトランザクションの更新 (追加、変更、削除) が記録されており、これを削除すると復元できない状態にまでカレンダデータベースが破損してしまうことがあります。


注 –

Calendar Server に関するテクニカルサポートを依頼する場合、問題解決のためにログファイルの提出が必要となることがあります。


csmonitor の使用

Calendar Server を監視するには、csmonitor ユーティリティーを使用します。このユーティリティーは、複数のトランザクションログファイルの発生や、カレンダデータベースのディスク容量の不足などの問題が生じた時点で、管理者に電子メールを送信するようにします。詳細は、「csmonitor」を参照してください。

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

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

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

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

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

  3. カレンダデータベースのコピーをまだ作成していない場合は、コピーを作成します。

    データベース (.db) ファイルだけをコピーします。共有ファイル (__db.*) やログファイル (log.*) をコピーする必要はありません。

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

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


    cd /opt/SUNWics5/cal/sbin
  5. カレンダデータベースのコピーに対して check コマンドを実行します。


    ./csdb check dbdir /tmp/check.out 

    dbdir を指定しない場合、現在のディレクトリに格納されているデータベースに対して check が実行されます。

    check コマンドは大量の情報を生成する可能性があるため、この例で示すように stdoutstderr を含むすべての出力をファイルとして書き出すことをお勧めします。

  6. check の実行が完了したら、出力ファイルを確認します。データベースが破損していた場合は、rebuild コマンドを実行します。

    「破損したカレンダデータベースの再構築」を参照してください。

データベース破損時のサービス停止の防止 (読み取り専用モード)

ここでは、リカバリモードの間も破損したデータベースにアクセスできる方法について説明します。ここで説明する内容は次のとおりです。

読み取り専用モードの使用

データベースの破損が見つかった場合、サービスの停止を防ぐ 1 つの方法は、データベースを読み取り専用モードにすることです。このモードでは、エンドユーザーはデータベースのエントリを読むことはできますが、追加、変更、または削除はできません。エンドユーザーがカレンダデータを追加、変更、または削除しようとすると、システムによりエラーメッセージが表示されます。また、カレンダの予定および仕事を追加、変更、または削除する管理者ツールも、データベースが読み取り専用モードの間は機能しません。


注 –

データベースを読み取ることができないほど破損している場合は、バックアップを復元するまでの間、サービスを停止する必要があります。バックアップを復元する最短の方法は、有効なホットバックアップを取ることです。「復元する前に」を参照してください。


Procedureデータベースを読み取り専用モードにするには

手順
  1. 必要がなくても、カレンダサービスを一時的に停止して、データベースがさらに破損するのを防ぐ場合もあります。

    カレンダダービスを停止するには、次のようにように実行します。

    cal_svr_base/SUNWics5/cal/sbin/stop-cal

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

    cd /etc/opt/SUNWics5/config

  3. カレンダデータベースに対して読み取り専用モードを指定します。

    caldb.berkeleydb.readonly=”yes”

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

    cal_svr_base /SUNWics5/cal/sbin/start-cal

    ics.conf の変更を有効にするには、サービスを再起動する必要があります。

一般的なデータベース障害の処理

ここでは、いくつかの一般的なデータベース障害と、推奨する対応策について説明します。ここで説明する内容は次のとおりです。

Procedurecsadmind が起動しない、または起動時にクラッシュする

csadmind では GSE (グループスケジューリングエンジン) とアラームディスパッチエンジンの両方のサービスを処理するため、GSE キュー内、またはアラームキュー内のエントリに問題があると、これらの問題が発生する可能性があります。

対応策

手順
  1. csadmind が稼動していない場合は、すぐに stop-cal を実行します。

    カレンダサービスを稼動したままにしておくと、トランザクションログが累積し、それが原因でデータベースがさらに破損して、トランザクションログファイルとデータベースを照合するのに時間がかかる場合があります。

  2. csadmind の再起動を試みます (start-cal の再実行)。

    正常に起動したら、次のようにして 2 つのキューが機能していることを確認します。

    1. csschedule を使用して、GSE キューをチェックします。

    2. dbrig を使用して、アラームキューをチェックします。

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

  3. csadmind がダンプでクラッシュした場合は、pstack を分析します。

    トレースに GSE に関連した機能がある場合は (中に GSE の文字がある)、GSE キューの最初のエントリおよび予定データベースの参照エントリを調べます。ほとんどの場合、GSE エントリで参照されている予定が、問題を起こしているエントリです。この問題を解決するには次を実行します。

    1. csschedule を使用して、GSE エントリを削除します。

    2. cscomponents を使用して、問題を起こしている予定をデータベースから削除します。

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

  4. エントリが破損していない場合は、カレンダサーバーでは処理できない特殊な例の可能性があります。

    次の手順を実行します。

    1. 破損したデータベースのカレンダ環境のスナップショットを取り、カスタマサポートに問い合わせます。

      環境のバックアップを作成するには、次のように実行します。

      1. 次の場所にある db_checkpoint ユーティリティーを使用します。

        cal_svr_base/SUNWics5/cal/tools/unsupported/bin/db_checkpoint

      2. db_archive -s を実行します。

        -s オプションを使用して、すべてのデータベースファイルを識別し、それらを CD、DVD、テープなどのリムーバブルメディアにコピーします。

      3. db_archive -l を実行します。

        -l オプションを使用して、すべてのログファイルを識別し、使用されていないファイルをリムーバブルメディアデバイスにコピーします。

    2. サービスの停止を避けるには、カレンダデータベースを一時的に読み取り専用の状態にして、ホットバックアップのコピーに戻ります。

      • カレンダデータベースを一時的に読み取り専用の状態にすると、トランザクションの追加、変更、または削除はできなくなります。エンドユーザーがカレンダデータを追加、変更、または削除しようとすると、エラーメッセージが表示されます。カレンダの予定および仕事を追加、変更、または削除する管理者ツールも、データベースが読み取り専用モードの間は機能しません。

        カレンダデータベースを読み取り専用モードにするには、ics.conf ファイルを編集して、次のパラメータを “yes” に設定します。

        caldb.berkeleydb.readonly=”yes”

      • 「自動バックアップコピーの復元」にある手順を使用して、ホットバックアップコピーに戻ります。

        csstored を設定して有効にすると、ホットバックアップが使用可能になり、数分以内に最新の状態になります。また、常にホットバックアップコピーを検証して、破損していないことを確認するとよいでしょう。その場合は、db_verify を実行します。

  5. ほかの方法がすべて失敗した場合、ダンプと再ロードの手順を実行して、データベースを修復できるかどうか確認します。

    この手順は、「ダンプとロードによるカレンダデータベースの復元」で説明しています。

Procedureサービスがハングし、エンドユーザーが接続できない: 親のないロック

この状態は、制御スレッドが原因で発生する場合があります。これは Berkeley DB データベースのページをロックし、ロックを解除しないで終了します。この問題を確認するには、cshttpd プロセスおよび csadmind 上で pstack を実行します。pstack は標準 UNIX ユーティリティーで、次の場所に格納されています。/usr/bin/pstack。このユーティリティーにより、ロックを獲得するために待機しているスレッドが表示されます。

問題を解決するには、次のようにして Calendar Server を再起動します。

手順
  1. start-cal が存在するディレクトリに移動します。

    cd cal_svr_base/SUNWics5/cal/sbin

  2. start-cal コマンドを実行します。

    ./start-cal

Procedurecsdb rebuild が終了しない: データベースのループ

データベースのループは、通常、データベースファイルの破損により起こります。データベースが破損しているため、回復不能になる可能性があります。次のいくつかの選択肢があります。

手順
  1. ホットバックアップに戻ります。

    破損が最近起こったのであれば、いずれかのホットバックアップコピーを使用できます。

  2. 壊滅的アーカイブのリカバリプロセスを使用します。

    推奨されるプロセスについては、「自動バックアップコピーの復元」を参照してください。

  3. ダンプと再ロードの手順を使用します。「ダンプとロードによるカレンダデータベースの復元」を参照してください。

破損したカレンダデータベースの再構築

ここでは、csdb rebuild コマンドの使用方法について説明します。ここで説明する内容は次のとおりです。

rebuild の概要

rebuild コマンドはカレンダデータベースを走査し、カレンダプロパティー (calprops) の予定と仕事 (作業) をチェックして破損がないかどうかを調べます。不整合を検出すると、rebuild コマンドは再構築したカレンダデータベース (.db ファイル) を cal_svr_base /SUNWics5/cal/sbin/rebuild_db ディレクトリに生成します。

-g オプションを指定せずに rebuild コマンドを実行すると、GSE (グループスケジューリングエンジン) データベース以外のすべてのデータベースが再構築されます。GSE データベースも再構築するときは、-g オプションを指定します。

GSE データベースにエントリが含まれているかどうかを調べるには、csschedule -v list コマンドを実行します。GSE がすべてのエントリの処理を完了してから rebuild コマンドを実行してください。

Procedureカレンダデータベースを再構築するには

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

  2. Calendar Server を停止します。

  3. カレンダデータベースのコピーを作成し、/tmp/db ディレクトリに置きます。

    データベース (.db) ファイルとログ (log.*) ファイルをコピーします。共有ファイル (__db.*) をコピーする必要はありません。

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

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


    cd /opt/SUNWics5/cal/sbin

    注 –

    sbin ディレクトリのディスク容量が問題となる場合は、別のディレクトリで rebuild コマンドを実行します。


  5. カレンダデータベースのコピーに対して rebuild コマンドを実行します。


    ./csdb rebuild /tmp/db /tmp/

    データベースパスを指定しない場合は、現在のディレクトリに対して rebuild が実行されます。/tmp/ パラメータは、再構築したデータベースの出力先ディレクトリを指定します。

    GSE データベースも再構築するときは、-g オプションを指定します。

    rebuild は大量の情報を生成する可能性があるため、stdoutstderr を含むすべての出力をファイルとして書き出すことをお勧めします。


    注 –

    カレンダデータベースを再構築するときは、常に最新のバックアップコピーを使用してください。

    ただし、膨大なデータが失われ、データベースの定期バックアップで複数のコピーを利用できるときは、最新のコピーからもっとも古いコピーの順に再構築を行います。この方法の唯一の欠点は、すでに削除されているカレンダコンポーネントが再構築されたデータベースに再表示されることです。

    たとえば、3 つのバックアップカレンダデータベースファイルが db_0601db_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 ディレクトリに書き込みます。


  6. rebuild の実行が完了したら、rebuild.out ファイルを確認します。

    再構築が正常に完了した場合、rebuild.out ファイルの最後の行は次のようになります。


    Calendar database has been rebuilt
  7. 前の手順で再構築が正常に完了したことを確認したら、再構築したデータベースファイル (.db) を rebuild_db ディレクトリから運用データベースにコピーします。

  8. 破損したデータベースのディレクトリに共有ファイル (__db.*) やログファイル (log.*) が含まれていた場合は、それも運用ディレクトリに移動します。

  9. 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_dumpdb_load によるデータベースの復元が成功するかどうかは、データベースの破損具合によって決まります。データベースを復元するまでに、db_dump オプションを何度か実行しなければならないこともあります。ただし、破損が著しいデータベースは復元できません。この場合は、データベースの最終ホットバックアップまたはアーカイブを使用する必要があります。


注 –

ダンプとロードの手順を実行するときは、カレンダデータベースが Berkeley DB バージョン 3.2.9 以上である必要があります。それ以前のバージョンを使用している場合は、最初に cs5migrate ユーティリティーを使用してカレンダデータベースをアップグレードしてください。

最新バージョンの cs5migrate については、ご購入先のテクニカルサポートに問い合わせてください。


Procedureダンプとロードの手順を実行するには

手順
  1. Calendar Server を実行するユーザーやグループ (icsusericsgroup など)、またはスーパーユーザー (root) としてログインします。

  2. Calendar Server が停止していなければ、停止します。

  3. csbackup ユーティリティーや Sun StorEdge Enterprise BackupTM ソフトウェア、Legato Networker® などを使用して、破損しているデータベースのバックアップを作成します。

    詳細は、第 17 章「Calendar Server データのバックアップと復元」を参照してください。

  4. db_dump ユーティリティーを使用して、破損しているデータベースの各ファイルをダンプします。

    データベースファイルは、ics50calprops.dbics50journals.dbics50alarms.dbics50events.dbics50todos.db、および ics50gse.db です。

    データベースが復元されるまで (または復元不可能であると判断されるまで)、次のオプションを順に指定して db_dump を実行します。

    • オプションなし: 軽度のデータベース破損。

    • -r オプション: 中度のデータベース破損。

    • -R オプション: 重度のデータベース破損。-R オプションを指定した場合、破損しているデータベースから、部分的なレコードや削除されたレコードなども含め、-r オプションを指定した場合より多くのデータがダンプされます。

      たとえば、-r オプションを指定して db_dump を実行するときは、次のように入力します。


      db_dump -r ics50events.db \> ics50events.db.txt
  5. db_load ユーティリティーを使用して、出力ファイルを新しいデータベースファイルにロードします。

    次に例を示します。


    db_load new.ics50events.db < ics50events.db.txt

    db_load が奇数のキーまたはデータエントリをレポートする場合は、db_dump 出力ファイルを編集して、異常のあるキーまたはデータエントリを削除します。次に、db_load を再実行します。

  6. 破損しているその他のデータベースファイルに対して、前の 2 つの手順を繰り返します。

    つまり、破損しているその他のデータベースファイルに対して db_dump を実行します。

  7. 「破損したカレンダデータベースの再構築」で説明している csdb rebuild コマンドを使用して、復元したデータベースファイルを再構築します。

    rebuild の実行が完了したら、出力ファイルを確認します。再構築が正常に完了した場合、rebuild.out ファイルの最後の行は次のようになります。


    Calendar database has been rebuilt

    csdb rebuild コマンドが正常に終了しなかった場合は、次レベルの db_dump オプション (-r または -R) を使用してデータベースのダンプを行います。

    db_dump -R オプションを実行しても破損しているデータベースを復元できない場合は、ご購入先のテクニカルサポートまたは販売代理店までご連絡ください。それまでの間は、データベースの最終バックアップを使用する必要があります。

自動バックアップコピーの復元

第 10 章「自動バックアップ (csstored) の設定」で説明されている自動バックアップ機能を使用している場合、ライブデータベースが破損したときにバックアップコピーを復元できます。

ここでは、2 つの異なる自動バックアップの復元方法について説明します。

復元する前に

バックアップを復元する前に、必ず次の操作を行っていることを確認してください。

Procedureホットバックアップを復元するには

ライブデータベースが破損した場合は、ホットバックアップがバックアップの最初の選択肢となります。バックアップを復元するには、次の手順を実行します。

手順
  1. 破損したライブデータベースのディレクトリで、適用されていない、または書き込み可能な状態のログファイルを識別します。

  2. 書き込み可能なログを閉じます。このログには、最新のトランザクションが含まれています。

  3. 新規の (復元) ディレクトリを作成します。

  4. 現在のホットバックアップのコピーを、新規の復元データベースのディレクトリにコピーします。

  5. log.* ファイルを、破損したライブデータベースのディレィトリから、新規の復元データベースのディレクトリにコピーします。

  6. データベースのアーカイブコピーを保持している場合は、ライブデータベースに適用されなかったログをアーカイブディレクトリにコピーします。

  7. 新規の復元データベースに対して指定された -c -h オプションを指定して、db_recover を実行します。

    たとえば、新規の復元ディレクトリの名前が recoverydb の場合、コマンドは次のようになります。

    db_recover -c -h recoverydb

  8. log.* ファイルは、新規のディレクトリに残しておきます。

    db_recover プログラムではログファイルを新規の復元データベースに適用しましたが、バージョン 4.2 以降、Berkeley DB ではログファイルをそのまま残しておくことを勧めします。

  9. 新規の復元ディレクトリ内のデータベースファイルに対して、db_verify を実行します。

    手順については、「カレンダデータベースの破損をチェックするには」を参照してください。

  10. 新規の復元ディレクトリに対して、csdb -v list を実行します。

  11. 新規の復元ディレクトリで 上記の 3 つの手順を実行したら、古い破損したライブデータベースを新規の復元ディレクトリと置き換えます。

  12. 新しいスナップショットとして機能させるために、新規のライブデータベースをホットバックアップのディレクトリにコピーします。

    次の定期的なスナップショットが取得されるまで、すべての新しいログがこのコピーに適用されます。

  13. Calendar Server を起動します。

  14. 新規の復元ディレクトリでいずれかの手順に失敗した場合は、次のようにして破損していない古いホットバックアップを特定します。

    1. ホットバックアップを新しい順から逆にたどり、各ファイルに対して順番に db_verify および csdb -v list を実行して、破損していない最新のコピーを見つけます。

    2. パスする最初のホットバックアップコピーが、ライブデータベースのディレクトリに復元されます。

      「ホットバックアップを復元するには」で説明している手順に従い、破損したライブデータベースを新規のホットバックアップと置き換えます。最初に、必ず 「復元する前に」をお読みください。

    3. ホットバックアップがどれも動作せず、アーカイブバックアップがない場合は、テクニカルサポートに問い合わせてください。アーカイブバックアップがある場合は、「アーカイブバックアップを復元するには」にある手順を実行します。「復元する前に」も参照してください。

Procedureアーカイブバックアップを復元するには

破損したホットバックアップはないが、アーカイブバックアップとトランザクションログがある場合は、次の手順を実行して、アーカイブしたデータベースの最新の破損していないデータベースを復元できます。

手順
  1. 破損したライブデータベースのディレクトリで、適用されていない、または書き込み可能な状態のログファイルを識別します。

  2. 書き込み可能なログを閉じます。このログには、最新のトランザクションが含まれています。

  3. 新規の (復元) ディレクトリを作成します。

  4. 最新のアーカイブコピーとそのログファイルを、新規の復元データベースのディレクトリにコピーします。

  5. 適用されていない log.* ファイルを、破損したライブデータベースのディレクトリから、新規の復元データベースのディレクトリにコピーします。

  6. 新規の復元データベースに対して指定された -c -h オプションを指定して、db_recover を実行します。

    たとえば、新規の復元ディレクトリの名前が recoverydb の場合、コマンドは次のようになります。

    db_recover -c -h recoverydb

  7. log.* ファイルは、新規の復元ディレクトリに残しておきます。

    db_recover プログラムではログファイルを新規の復元データベースに適用しましたが、バージョン 4.2 以降、Berkeley DB ではログファイルをそのまま残しておくことを勧めします。

  8. 新規の復元ディレクトリ内のデータベースファイルに対して、db_verify を実行します。

    手順については、「カレンダデータベースの破損をチェックするには」を参照してください。

  9. 新規の復元ディレクトリに対して、csdb -v list を実行します。

  10. 新規の復元ディレクトリで 上記の 3 つの手順を実行したら、古い破損したライブデータベースを新規の復元ディレクトリと置き換えます。

  11. 新しいスナップショットとして機能させるために、新規のライブデータベースをホットバックアップのディレクトリにコピーします。

  12. Calendar Server を起動します。

  13. 新規の復元ディレクトリがいずれかの手順に失敗した場合は、次のようにして破損していない古いアーカイブバックアップを特定します。

    1. アーカイブバックアップのコピーを新しい順から逆に調べて、順に各ファイルに対して次の 3 つのリカバリプログラムを実行して、破損していない最新のコピーを見つけます。db_recover -c-hdb_verify、および csdb -v list

    2. パスする最初のアーカイブアップコピーが、ライブデータベースのディレクトリに復元されます。

      「アーカイブバックアップを復元するには」で説明している手順に従い、破損したライブデータベースを新規のアーカイブバックアップと置き換えます。

    3. アーカイブバックアップがどれも動作しない場合は、テクニカルサポートに問い合わせてください。

カスタムのバックアップスクリプトの修復

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

現在、動的ライブラリでコンパイルされている Berkeley ツール

カスタムバックアップスクリプトが Berkeley データベースのツール (db_recover など) を使用して作成されている場合は、Calendar Server にアップグレードすると、機能しなくなる可能性があります。これは、Calendar Server の以前のバージョンでは、ツールを静的ライブラリでコンパイルしていたためです。現在では、ツールは動的ライブラリの libdb-4.2.so でコンパイルされています。

カスタムのバックアップスクリプトを修復するには

既存のカスタムスクリプトで新しい動的ライブラリを使用するには、次に示す大域変数を設定します。

LD_LIBRARY_PATH=libdb-4.2.so