第 4 章 データベース移行ユーティリティー

以前のバージョンの Calendar Server (5.11 以前) を使用していた場合は、Calendar Server をインストールし、インストール後の設定を行ったあとで、コンポーネントデータベースと LDAP データベースの移行が必要になることもあります。

この章の 「権限ユーティリティーの選択」を参照すると、適切なユーティリティーを選択する場合に役立ちます。

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

• 「インストール後のデータベース移行ユーティリティー」

• 「権限ユーティリティーの選択」

• 「csmig」

• 「csvdmig」

• 「commdirmig」

インストール後のデータベース移行ユーティリティー

以前にインストールした Calendar Server 5.1.1 のカレンダデータベースと LDAP データベースのエントリがある場合は、Sun Java System Calendar Server をインストールしたあとで、次のユーティリティーを指定された順序で実行します。

1. cs5migrate

   カレンダデータベースを Calendar Server バージョン 5 の形式からバージョン 6 の形式に移行します。これらのユーティリティーはテクニカルサポートからダウンロードして入手できます。

   Connector for Microsoft Outlook の使用を計画しており、複数のコンポーネントが定期的に発生する予定の場合は、cs5migrate_recurring を使用します。このユーティリティーにより、定期的コンポーネントごとにマスターレコードと例外が作成されます。

   定期的コンポーネントが既存のデータベースに格納されていない場合、または格納されていても Connector for Microsoft Outlook を使用する予定がない場合は、cs5migrate を使用します。

   cs5migrate と cs5migrate_recurring のどちらも、テクニカルサポートサイトからのみ入手できます。これらは製品に同梱されていません。

2. 「csmig」

   Calendar Server 6 データベース内の各カレンダに所有者を割り当て、必要に応じて各カレンダ ID (calid) を所有者にマッピングします。これによって、ホストされた (仮想) ドメインおよび LDAP カレンダ検索データベース (CLD) プラグインがサポートされます。このユーティリティーは Calendar Server に同梱されています。cs5migrate のあと、csvdmig の前にこのユーティリティーを実行します。

3. 「csvdmig」

   カレンダのドメイン (@domainname) を各 calid に追加することにより、Calendar Server 6 サイトをアップグレードして、ホストされた (仮想) ドメインを使用するようにします。たとえば、sesta.com というドメインでは、jdoe の calid は jdoe@sesta.com となります。このユーティリティーは Calendar Server に同梱されています。cs5migrate および csmig のあとにこのユーティリティーを実行します。

4. 「commdirmig」

   Access Manager 6.1 以上で使用するために、LDAP データを Schema 1 から Schema 2 に移行します。このユーティリティーは Access Manager に同梱されています。

権限ユーティリティーの選択

ユーティリティーには多数の選択肢があるため、次の図を参照して、どのユーティリティーを実行するかを選択してください。

図 4–1 実行する移行ユーティリティーの選択

csmig

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

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

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

• 「csmig の機能」

• 「csmig の要件」

• 「csmig の構文」

• 「csmig 移行の手順」

• 「csmig のヒントとトラブルシューティング」

csmig の機能

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

• 「カレンダを移行する」

• 「カレンダに所有者を割り当てる」

• 「LDAP 属性を更新する」

カレンダを移行する

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

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

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

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

• 有効な所有者がいないユーザーカレンダは、-c オプションによって csmig に渡されるユーザーが所有します。たとえば、jsmith というカレンダ ID の所有者がいない場合、-c オプションとして orphan を指定すると、このカレンダ ID は orphan:jsmith に変換されます。

• 所有者がいないリソースカレンダは、-r オプションによって csmig に渡されるリソースユーザーが所有します。

• リソースカレンダの名前にコロン (:) が含まれる場合、移行された名前に含まれるコロンが 1 つのみになるように、それらのコロンは下線に変換されます。

  たとえば、所有者が bkamdar の football というカレンダ名は、bkamdar:football に変換されます。所有者が bkamdar の tchang:soccer というカレンダ名は、bkamdar:tchang_soccer に変換されます。所有者が admin1 の auditorium:room1 というカレンダ名は、admin1:auditorium_room1 に変換されます。

LDAP 属性を更新する

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

csmig の要件

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

• カレンダデータベースが破損していないこと。csdb check コマンドを使用してカレンダデータベースを確認し、必要に応じて csdb rebuild コマンドを実行してデータベースを再構築します。これらのコマンドについては、付録 D 「Calendar Server のコマンド行ユーティリティーのリファレンス」 を参照してください。

• 新しい移行先ターゲットデータベース、および、バックアップデータベースがある場合にはその分も含めて、十分なディスクの空き容量があること。

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

  ユーザー設定を格納する LDAP ディレクトリサーバーでカレンダユーザーの属性を管理するための権限も必要です。

• Calendar Server は停止している必要があります。

csmig の構文

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

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

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

csmig 移行の手順

Calendar Server 6 のインストールと設定が終わったら、csmig を実行して既存の Calendar Server と LDAP データを移行する必要があります。LDAP データの移行は、LDAP CLD プラグインを正常に動作させるために必要です。csmig を使用してカレンダデータを移行する場合は、次の手順を実行します。

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

手順

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

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

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

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

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

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

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

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

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

手順

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

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 にログインし、移行されたデータベース内のいくつかのカレンダを検証します。

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

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

手順

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/testcsdb/ ディレクトリに移行されます。

   ./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) で未解決のカレンダを確認し、「csmig 移行の手順」の 「csmig 移行の手順」の計画に従って問題を解決します。

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

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

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

   • service.dwp.enable = "yes"

   • service.dwp.port = "9779"

   • csapi.plugin.calendarlookup = "y"

   • 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 プラグインの設定パラメータの指定方法については、第 6 章「複数のマシンへのカレンダデータベースの分散の設定」を参照してください。

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"

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

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

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

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

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

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

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

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

問題の例

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

解決策の例

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

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

問題の例

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

解決策の例

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

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

• フィルタ (&(objectclass=icscalendaruser)(icscalendarowned=*substr*)) を使用した LDAP 検索

• フィルタ (icscalendarowned=*substr* ) を使用した LDAP 検索

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

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

問題の例

csmig のドライランマッピングファイルおよび出力ファイルに、カレンダ名の重複が記録されます。たとえば、元のデータベースで、jsmith が次のカレンダを所有しているとします。

• basketball (5 個の予定あり)

• jsmith:basketball (10 個の予定あり)

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

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

Error modifying calendar properties, error=2

解決策の例

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

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

問題の例

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

解決策の例

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

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

問題の例

カレンダユーザーを 1 台のバックエンドサーバーから別のバックエンドサーバーに移動します。

解決策の例

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

csvdmig

csvdmig ユーティリティーでは、ホストされた (または仮想) ドメインを使用するサイトの Calendar Server データベースおよび LDAP ディレクトリサーバーデータベースが変更されます。

ホストされていない環境から移動している場合は、このユーティリティーを使用する前に必ず csmig を実行してください。

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

• 「csvdmig の機能」

• 「csvdmig の構文」

• 「csvdmig の例」

csvdmig の機能

csvdmig ユーティリティーでは、次のようにドメイン名をユーザー ID に追加します。

• カレンダ ID (calid) の形式が変更されます。

  変更前: userid[:calendar-name]

  変更後: userid@domain[:calendar-name]

• ACL (アクセス制御リスト) のアクセス規則が変更されます。

  変更前: userid

  変更後: userid@domain

• Calendar Server 属性の LDAP ディレクトリサーバーのユーザーエントリが次のように変更されます。

  userid[:calendar-name] から userid@domain[:calendar-name]。

• カレンダデータベースに含まれる予定と作業の所有者フィールドと出席者フィールドを更新します。

  例: ドメイン sesta.com の jsmith が予定の所有者である場合、新しい所有者フィールドには jsmith@sesta.com が入ります。

csvdmig ユーティリティーでは、データベースと LDAP ディレクトリに適切な更新を行います。つまり、移行データベースを個別に作成するのではなく、変換中のデータベースを変更します。したがって、念のため、データベースと LDAP ディレクトリのスナップショットに対して csvdmig を実行してください。

csvdmig の構文

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

csvdmig [-t DestinationDB]
         [-c ConfigFile]
         [-e ErrorFile]
         [-m MappingFile]
         migrate [DB|LDAP]

次の表に、csvdmig によって使用されるオプションと、各オプションの説明を示します。

マッピングファイル

マッピングファイルは、既存のユーザーをそれぞれのドメインにマッピングする入力テキストファイルです。csvdmig を実行する前に、マッピングファイルを作成する必要があります。古い値と新しい値の間にスペースを入力し、1 行に 1 つのエントリを指定します。次に例を示します。

user1 user1@sesta.com
user2 user2@siroe.com
user3 user3@sesta.com
 ...
usern usern@siroe.com

出力先 DB

このユーティリティーでは、移行されたファイルは新しい DestinationDB には移動されません。-t オプションを指定する場合は、csvdmig を実行する前に、移行するデータベースファイルをそのディレクトリにコピーしておく必要があります。

-t オプションを使用しないと、ユーティリティーによって作業用ディレクトリ内のファイルが移行されるため、予期しない結果が発生します。

csvdmig の例

• デフォルト値を使用して、LDAP ディレクトリサーバーのデータを移行します。

  csvdmig migrate LDAP

• Calendar Server データベースを移行します。

  csvdmig -t targetDB -e errorFile -m mappingFile migrate

commdirmig

commdirmig ユーティリティーでは、認証サービスに Access Manager を使用できるように、LDAP データを Sun LDAP Schema 1 から Schema 2 に移行します。

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

• 「ユーティリティーを実行する必要がある場合」

• 「ユーティリティーを実行するタイミング」

• 「マニュアルの参照先」

• 「ユーティリティーの入手先」

ユーティリティーを実行する必要がある場合

以前に Messaging Server 5 または Calendar Server 5 のバージョンを使用していた場合は、LDAP エントリが Schema 1 にフォーマットされています。新しい Calendar Server 6 2005Q4 環境で、認証に Access Manager を使用する場合は、このユーティリティーを実行して LDAP エントリを Schema 2 形式に変換する必要があります。

Access Manager を使用していない場合、Schema 2 は LDAP を使用するすべての Java Enterprise System 製品に最適な LDAP モードであるため、LDAP データの移行を検討することをお勧めします。今後は、新しいバージョンの通信製品 (Calendar、Messaging、および Instant Messaging) で Schema 1 がサポートされなくなる可能性があります。ただし、この時点で Access Manager を使用しない場合は、都合のよい時期まで移行作業を見合わせることができます。

設定用の LDAP ディレクトリが個別に用意されている場合は、認証用の LDAP だけでなく、その LDAP に対しても commdirmig を実行する必要があります。

ユーティリティーを実行するタイミング

Java Enterprise System 以前のバージョンの Calendar Server から移行する場合は、cs5migrate、csmig、および csvdmig を実行したあとでこのユーティリティーを実行します。

マニュアルの参照先

commdirmig 移行ユーティリティーには、特別な準備と計画が必要です。このユーティリティーについては別のマニュアルで説明しています。『Sun Java System Communications Services 6 2005Q4 Schema Migration Guide』を参照してください。

ユーティリティーの入手先

commdirmig ユーティリティーは、Java Enterprise System インストーラからインストールする Delegated Administrator にバンドルされています。

ユーティリティーのパッチもテクニカルサポートから入手できます。