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) します。カレンダの移動後、元のサーバー上のカレンダを削除できます。カレンダの移動方法については、「ユーザーカレンダの管理」を参照してください。