test

Sun Java System Calendar Server 6.3 管理ガイド

3.5 csmig ユーティリティー

csmig ユーティリティでは、必要に応じて、カレンダデータベース内の各カレンダに所有者を割り当て、各カレンダ ID (calid) を所有者にマッピングします。

csmig ユーティリティーは複数ドメインと LDAP Calendar Lookup Database (CLD) プラグインをサポートします。移行されたデータベース内のカレンダには、LDAP CLD プラグインを使用してアクセスできます。LDAP CLD プラグインについては、第 5 章「Calendar Server バージョン 6.3 での複数のマシンへのカレンダデータベースの分散の設定」を参照してください。

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

3.5.1 csmig ユーティリティーの機能

csmig 移行ユーティリティーでは、次の機能を実行します。

3.5.1.1 カレンダを移行する

csmig は、caldb.berkeleydb.homedir.path パラメータによって指定された現在のカレンダデータベース (*.db ファイル) 内のユーザーとリソースの両方のカレンダを移行します。新しい移行先ターゲットデータベースでは、csmig により、カレンダプロパティー (calprops)、予定、仕事 (作業)、およびグループスケジューリングエンジン (GSE) データベースファイルに含まれる、LDAP CLD プラグインで必要とされるエントリが更新されます。

csmig は移行先ターゲットデータベースだけに書き込みを行います。既存のカレンダデータベースに書き込むことはありません。

3.5.1.2 カレンダに所有者を割り当てる

csmig は、必要に応じて、カレンダデータベース内の各カレンダに所有者を割り当て、各カレンダ ID (calid) を所有者にマッピングします。すべてのデフォルトの calids はそのまま維持され、変更は行われません。

その他のカレンダは次のようにマッピングされます。

3.5.1.3 LDAP 属性を更新する

csmig は、icsSubscribed、icsCalendar、icsCalendarOwned、icsFreeBusy、icsSet、およびリソースカレンダに対する uid を含む、関連するすべての LDAP エントリの LDAP 属性を更新します。csmig は、LDAP ディレクトリサーバーデータベース内の各カレンダの icsDWPHost 属性を作成します。icsDWPHost は、カレンダが存在するバックエンドサーバーのホスト名を指定します。

3.5.2 csmig ユーティリティーの要件

csmig を使用するための要件は次のとおりです。

3.5.3 csmig の構文

csmig ユーティリティーの構文は次のとおりです。


csmig [-t DestinationDB]
      [-b Backend-DWPHost]
      [-o OutputFile]
      [-e ErrorFile]
      [-m MappingFile]
      [-c calendarOwner]
      [-r resourceOwner]
      { migrate|dryrun }

次の表に、ユーティリティーのオプションを一覧表示し、各オプションの説明とデフォルト値も示します。

csmig のオプション 

説明とデフォルト値 

-t DestinationDB

csmig で生成する移行先ターゲットデータベースを指定します。デフォルトは MigratedDB です。

-b Backend-DWPHost

DWP バックエンドホストサーバーの名前を指定します。この名前は ics.conf ファイルで指定された DWP バックエンドホストサーバー名と一致している必要があります。

-o OutputFile

csmig の画面への出力と発生するあらゆるエラーを書き込む出力ファイルを指定します。デフォルトは MigrateOut です。

-e ErrorFile

csmig でエラーや解決できないデータベースエントリが書き込まれるファイル。解決できないデータベースエントリは、移行先データベースに書き込まれません。デフォルトは MigrateError です。

-m MappingFile

dryrun モードで生成された出力マッピングファイルを指定します。出力マッピングファイルには、LDAP スキーマで変更する必要のあるエントリが一覧表示されます。次に例を示します。

古いエントリ: calid=jsmith

新しいエントリ: calid=jsmith:basketball

マッピングファイルでは、LDAP スキーマに対して行われる変更のリストだけが生成されます。csmig では、実際にはスキーマへの変更は行われません。 

マッピングファイルは、migrate モードでは使用されません。

-c calendarOwner

所有者がいないユーザーカレンダの所有者を指定します。 

-r resourceOwner

所有者がいないリソースカレンダの所有者を指定します。 

migrate|dryrun

ユーティリティーがどのモードで実行されているかを指定します。移行を行う場合は、migrate モードを使用します。実際に移行を行う前に出力マッピングファイルを生成する場合は、dryrun モードを使用します。

3.5.4 csmig ユーティリティーの移行の手順

バージョン 5.1.1 以前の Calendar Server を使用している場合は、Calendar Server 6.3 のインストールと設定が完了したあとに csmig を実行し、既存の Calendar Server および LDAP データベースを移行します。LDAP データの移行は、LDAP CLD プラグインを正常に動作させるために必要です。csmig を使用してカレンダデータを移行する場合は、次の手順を実行します。

Procedurecsmig を使用するための高レベルの手順

  1. comm_dssetup.pl を使用し、Directory Server を設定します。

    まだ comm_dssetup.pl を使用して LDAP 属性にインデックスを作成していない場合は、ここで行います。これによって、LDAP データの移行処理のパフォーマンスが大幅に向上します。

  2. テストサーバー (本稼働サーバーではない) を使用して、テストドライランを実行します。

    ドライランでは、実際の移行中に csmig によって何が行われるかがレポートされますが、データは移行されません。ドライラン後、実際に移行を行う前に、エラーを修正し、未解決のカレンダを処理する計画を決定します。

    テストドライランの実行方法については、「3.5.4 csmig ユーティリティーの移行の手順」を参照してください。

  3. 運用データを移行します。

    本稼働では、csmig によって、カレンダデータベース (.db ファイル) と LDAP データ (ユーザーおよびグループの設定データ)、icsSubscribed、icsCalendar、icsCalendarOwned、icsFreeBusy、icsSet、および uid (リソースカレンダ用) が移行されます。移行後、すべてのカレンダリソースに LDAP エントリが作成されます。

    運用データの移行方法については、「3.5.4 csmig ユーティリティーの移行の手順」を参照してください。

Procedureテストドライランを実行するには

  1. 必要に応じて、Calendar Server 6.3 を中継サーバーにインストールします。

  2. カレンダデータベースのスナップショットを中継サーバーにコピーします。

  3. 次の作業を実行して、中継サーバー上に本稼働 LDAP 環境を再現します。

    • Directory Server をインストールします。

    • このサーバーに LDAP データベースのスナップショットをインストールします。

  4. comm_dssetup.pl を実行して、中継 Directory Server を設定します。

  5. csconfigurator.sh を実行して、中継 Calendar Server を設定します。

  6. icsuser としてログインします。これが異なる場合は、設定中に指定した Calendar Server のランタイムユーザー ID としてログインします。スーパーユーザー (root) として csmig を実行する場合は、移行されたファイルに対するアクセス権のリセットが必要になることもあります。

  7. cal-svr-base/SUNWics5/cal/sbin ディレクトリに移動します。

  8. csdb check コマンドを実行して、データベースに破損が生じていないかどうかを確認します。破損が見つかった場合は、csdb rebuild を実行してデータベースを再構築します。

  9. 所有者がいないユーザーカレンダにすべてを割り当てるための calid を作成することを考慮します。たとえば、次のコマンドを実行すると、orphan という calid を持ったユーザーが作成されます。


    ./csuser -g orphan -s adminuser -y password -l en -c orphan create orphan

  10. 必要に応じて、stop-cal コマンドを使用して Calendar Server を停止します。

    cal-svr-base/SUNWics5/cal/sbin/stop-cal

  11. -dryrun オプションを指定して csmig を実行します。たとえば、次のように入力します。

    ./csmig -b sesta.com -o csmig.out -e csmig.errors
 -m csmig.map -c orphan -r calmaster dryrun

    このコマンドを実行すると、所有者のいないユーザーカレンダ (orphan カレンダ) が所有者 orphan に割り当てられ、所有者のいないリソースカレンダが所有者 calmaster に割り当てられます。

  12. 出力マッピングファイル (csmig.map) を確認します。マッピングファイルに、LDAP スキーマ内で更新する必要のあるエントリが一覧表示されます。

  13. 出力ファイル、マッピングファイル、およびエラーファイルを確認します。検出された LDAP の問題やエラーを解決します。実際の移行の前に、未解決のカレンダを処理する方法を決定します。

    選択肢は以下のとおりです。

    • 移行する前に、不要なカレンダを削除します。

    • 未解決のカレンダに所有者を割り当てます。

    • -c オプションと -r オプションを使用して csmig を実行し、移行中にカレンダに所有者を割り当てます。

  14. csmig を実行して、中継カレンダデータベースを移行します。

    たとえば、次のコマンドを実行すると、カレンダデータベースが /var/opt/SUNWics5/testcsdb/ ディレクトリに移行されます。

    ./csmig -t /var/opt/SUNWics5/testcsdb/ -b sesta.com 
-o csmig.out -e csmig.errors -m csmig.map -c orphan 
-r calmaster migrate

  15. テスト移行が完了したら、次の手順を実行して、新しく移行されたカレンダデータベースを確認します。

    1. 移行されたデータベースを、caldb.berkeleydb.homedir.path パラメータで指定された /csdb ディレクトリにコピーします。あるいは、このパラメータを編集して、移行されたデータベースの新しい格納場所を指定します。

    2. 新しいカレンダデータベースで csdb check を実行します。移行されたデータベースの予定や仕事の数は、移行前の合計数と一致している必要があります。

    3. icsCalendarOwned エントリを検索し、エントリが移行前のカレンダ数と一致していることを確認します。

    4. Communications Express にログインし、移行されたデータベース内のいくつかのカレンダを検証します。

      テスト移行が正常に行われたら、運用データベースの移行準備は完了です。

Procedure運用データを移行するには

  1. icsuser (または設定中に指定した Calendar Server のランタイムユーザー ID) としてログインします。スーパーユーザー (root) として csmig を実行する場合は、移行されたファイルに対するアクセス権のリセットが必要になることもあります。

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

  3. stop-cal コマンドを使用して Calendar Server を停止します。

    cal-svr-base/SUNWics5/cal/sbin/stop-cal

  4. 以下のデータのバックアップを作成します。

    • カレンダデータベース (.db ファイル)

    • LDAP データ: slapd データベースディレクトリおよび LDAP データベース。

    • ics.conf ファイル。この手順は実際には必要ありませんが、元の設定に戻す必要がある場合に役立ちます。

  5. -migrate オプションを指定して csmig を実行します。

    たとえば、次のコマンドを実行すると、カレンダデータベースが /var/opt/SUNWics5/newcsdb/ ディレクトリに移行されます。

    ./csmig -t /var/opt/SUNWics5/newcsdb/ -b sesta.com 
-o csmig.out -e csmig.errors -m csmig.log -c orphan 
-r calmaster migrate

  6. エラーファイル (csmig.errors) で未解決のカレンダを確認し、「3.5.4 csmig ユーティリティーの移行の手順」 の 「3.5.4 csmig ユーティリティーの移行の手順」の計画に従って問題を解決します。

  7. csdb check コマンドを実行して、移行されたデータベースを確認します。破損が見つかった場合は、csdb rebuild を実行してデータベースを再構築します。

  8. 移行されたデータベースを、caldb.berkeleydb.homedir.path パラメータで指定された /csdb ディレクトリにコピーします。あるいは、このパラメータを編集して、移行されたデータベースの新しい格納場所を指定します。

  9. ics.conf ファイルで、必要に応じて次の構成パラメータを変更し、LDAP CLD プラグインを有効にします。

    • service.dwp.enable = "yes"

    • service.dwp.port = "59779"

    • csapi.plugin.calendarlookup = "yes"

    • csapi.plugin.calendarlookup.name = "*"

    • caldb.cld.type = "directory"

    • caldb.dwp.server.default = "default-server-name"

    • caldb.dwp.server. server-hostname.ip = "server-hostname" (ローカルサーバーを含む各バックエンドサーバー用)

    • caldb.cld.cache.enable = "yes" (CLD キャッシュオプションを使用する場合)

    • caldb.cld.cache.homedir.path では、CLD キャッシュディレクトリの場所を指定します。デフォルトは、/var/opt/SUNWics5/csdb/cld_cache です。

      LDAP CLD プラグインの構成パラメータの指定方法については、第 5 章「Calendar Server バージョン 6.3 での複数のマシンへのカレンダデータベースの分散の設定」を参照してください。

  10. start-cal コマンドを使用して Calendar Server を再起動します。

  11. Communications Express にログインし、移行されたカレンダのいくつかを確認して、正常に設定されたかどうかを検証します。

    確認を行う間アラームを無効にするには、ics.conf ファイルで次の各パラメータを "no" に設定します。

    • caldb.serveralarms = "no"

    • caldb.serveralarms.dispatch = "no"

    • service.ens.enable = "no"

    • service.notify.enable = "no"

    • ine.cancellation.enable = "no"

    • ine.invitation.enable = "no"

    • service.admin.alarm = "no"

3.5.5 csmig のヒントとトラブルシューティング

ここでは、次のヒントとトラブルシューティングの例について説明します。

3.5.5.1 csmig のドライランカレンダに表示されるカレンダの所有者が間違っています。

問題の例

tchang:myCalendar という名前のカレンダの所有者がカレンダデータベース内の jsmith であるため、csmig のドライランのマッピングでは jsmith:tchang_myCalendar と表示されます。しかし、このカレンダの名前を tchang:myCalendar とし、tchang という所有者を割り当てるとします。

解決策の例

移行前に、cscal ユーティリティーを使用して、カレンダ tchang:myCalendar の所有者を tchang に変更します。これを実行すると、移行によってこのカレンダが tchang:myCalendar にマッピングされ、icsCalendarowned がユーザー ID tchang の LDAP エントリに追加されます。

3.5.5.2 LDAP カレンダ検索を正常に実行できません。

問題の例

移行後、LDAP カレンダ検索が有効になりますが、カレンダ検索ダイアログに何も結果が表示されないか、一部の結果だけが表示されます。

解決策の例

LDAP カレンダ検索を有効にすると、Calendar Server で検索に (&(objectclass=icscalendaruser)(icscalendarowned=*substr*)) を使用できるようになります。

次のフィルタを使用して LDAP データに対して 2 つの異なる検索を手動で実行し、出力を比較します。

サーバーで icsCalendarUser オブジェクトクラスを含むフィルタを使用するため、スキーマの確認が無効な状態で LDAP サーバーが配備され、一部のカレンダエントリが icsCalendarUser オブジェクトクラスなしでプロビジョニングされた可能性があります。

3.5.5.3 csmig のドライランでカレンダ名の重複が検出されました。

問題の例

csmig のドライランマッピングファイルおよび出力ファイルに、カレンダ名の重複が記録されます。

たとえば、元のデータベースで、jsmith が次のカレンダを所有しているとします。

ドライランでは、移行中に 2 つのカレンダがマージされ、生成されるカレンダは、所有者が jsmith で、合計 15 個の予定が含まれた jsmith:basketball となります。

出力ファイルには次の警告メッセージが記録されます。

Error modifying calendar properties, error=2

解決策の例

2 つのカレンダをマージしない場合は、移行前に basketball の所有者を jsmith 以外のユーザーに変更します。これによって、2 つの独立したカレンダのデータの完全性が維持されます。

3.5.5.4 親のないカレンダに、異なる複数の所有者を割り当てるにはどうしたらよいですか。

問題の例

デフォルトでは、csmig によって親のないすべてのカレンダに 1 人の所有者が割り当てられますが、一部の親のないカレンダに、異なる複数の所有者を割り当てるとします。

解決策の例

csmig では、コマンド行からはマッピングファイルを操作できません。ただし、移行前に、元のデータベース内の親のないカレンダに所有者を割り当てることはできます。親のないすべてのカレンダに対するドライランのマッピングファイルを確認します。移行前に、cscal ユーティリティーを使用して、親のないカレンダに所有者を割り当てます。再び -dryrun モードで csmig を実行し、新しい所有者を確認します。

3.5.5.5 カレンダユーザーを別のバックエンドサーバーに移動するにはどうしたらよいですか。

問題の例

カレンダユーザーを 1 台のバックエンドサーバーから別のバックエンドサーバーに移動するにはどうしたらよいですか。

解決策の例

カレンダユーザーを移動するには、元のサーバーにある各ユーザーのカレンダをエクスポート (export) し、次にそのカレンダを 2 台目のサーバーにインポート (import) します。カレンダの移動後、元のサーバー上のカレンダを削除できます。カレンダの移動方法については、「15.6 ユーザーカレンダの管理」を参照してください。