test

Sun Java System Calendar Server 6.3 管理ガイド

第 3 章 Calendar Server 6.3 のデータベース移行ユーティリティー

ここでは、Calendar Server 6.3 ソフトウェアをインストールし、設定したあとにカレンダデータベースと LDAP データベースを移行するためのさまざまなデータベース移行ユーティリティーについて説明します。

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

ヒント –

Calendar Server 6.0、6.1、または 6.2 バージョンから移行する場合は、「3.3 csmigrate ユーティリティー」 と呼ばれるユーティリティーを実行します。以前の配備で、定期的な予定および作業に対して cs5migrate が実行済みでない場合は、csmigrate を実行する前に既存のカレンダデータベースで cs5migrate を実行する必要があります。

Calendar Server 5.1.1 から移行する場合は、「3.2 適切な Calendar Server ユーティリティーの選択」で説明するように、移行ユーティリティーを使用してカレンダデータベースと LDAP データベースを移行します。

5.1.1 より古いバージョンの Calendar Server がインストールされている場合は、データの移行についてはテクニカルサポートにお問い合わせください。

3.1 Calendar Server データベース移行ユーティリティーの概要

ここでは、それぞれの移行ユーティリティーについて説明します。過去にインストールされた Calendar Server のバージョンに応じ、必要となる移行ユーティリティーのみを使用します。これらのユーティリティーは sbin ディレクトリにあります。

ヒント –

データベースに対して過去に cs5migrate ユーティリティーを実行したことがあるが、そのときに -r オプションを指定しなかった場合は、ほかのユーティリティーを実行する前に -r オプションを指定してこのユーティリティーを再実行する必要があります。

移行ユーティリティーとは、次のものを指します。

「3.5 csmig ユーティリティー」

Calendar Server 6 データベース内の各カレンダに所有者を割り当て、必要に応じて各カレンダ ID (calid) を所有者にマッピングします。これによって、複数ドメインおよび LDAP カレンダ検索データベース (CLD) プラグインがサポートされます。

cs5migrate のあと、csvdmig の前にこのユーティリティーを実行します。

「3.6 csvdmig」

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

csmig のあと、cs5migrate の前にこのユーティリティーを実行します。

「3.4 cs5migrate ユーティリティー」

カレンダデータベースを Calendar Server バージョン 5 の形式からバージョン 6.2 の形式に移行します。-r オプションを指定し、データベースに対してこのユーティリティーを実行する必要があります。以前に Calendar Server バージョン 5.1.1 から 6.2 に移行したが、-r オプションを指定して cs5migrate ユーティリティーを実行しなかった場合は、csmigrate ユーティリティーの前に、このユーティリティーを実行する必要があります。

このユーティリティーは、csmig および csvdmig のあと、csmigrate の前に実行します。

「3.3 csmigrate ユーティリティー」

Calendar Server バージョン 6.0、6.1、または 6.2 から Calendar Server 6.3 バージョンにアップグレードするために、カレンダデータベースを移行します。cs5migrate を -r オプションを指定して実行する必要がある場合は、このユーティリティーの前に実行します。

「3.7 commdirmig」

Access Manager (Legacy モード) での使用に備え、LDAP データを Schema バージョン 1 から Schema バージョン 2 に移行します。

3.2 適切な Calendar Server ユーティリティーの選択

ここでは、すべてのカレンダデータベースおよび LDAP データベースを、Calendar Server 6.3 ソフトウェアレベルに移行するために実行する必要のあるユーティリティーを判断する方法について説明します。

次の表を使用し、適切なユーティリティーのコレクションを見つけます。

注 –

ユーティリティーは、指定の順序で実行します。

表 3–1 権限ユーティリティーの選択

移行前の Calendar Server のバージョン 

データベースファイルの状態 

使用するユーティリティー 

Calendar Server 6.0、6.1、6.2 

定期的な予定と仕事があり、過去に cs5migrate を実行したことがある。

Schema バージョン 2 をすでに使用している。 

csmigrate を実行します。

Calendar Server 6.0、6.1、6.2 

定期的な予定と仕事があり、過去に cs5migrate を実行したことがある。

過去に Schema バージョン 2 を使用したことはないが、使用する必要性が生じた。 

csmigrate および commdirmig を実行します。

Calendar Server 6.0、6.1、6.2 

ファイルに対して cs5migrate を実行したことがない。

Schema バージョン 2 をすでに使用している。または、Schema バージョン 1 を使用しており、今後も使用を続ける予定である。 

cs5migrate および csmigrate を実行します。

Calendar Server 6.0、6.1、6.2 

ファイルに対して cs5migrate を実行したことがない。

過去に Schema バージョン 2 を使用したことはないが、使用する必要性が生じた。 

cs5migrate、csmigrate、および commdirmig を実行します。

Calendar Server 5.1.1 

過去に複数ドメインを使用したことがない。 

csmig、csvdmig、cs5migrate、csmigrate、および commdirmig を実行します。

Calendar Server 5.1.1 以前 

ファイルは複数ドメインまたは LDAP CLD をサポートしていない。LDAP データベースは Schema バージョン 1 を使用している。 

データベースと LDAP ファイルを Calendar Server 5.1.1 レベルに移行する方法については、テクニカルサポートにお問い合わせください。 

Calendar Server 5.1.1 以前 

システムは制限付きの仮想ドメインに対応するよう設定されているか、Calendar Server ソフトウェアの複数のインスタンスが Solaris 10 以前のオペレーティングシステムにインストールされている。 

移行要件の評価については、セールス担当者にお問い合わせください。 

3.3 csmigrate ユーティリティー

csmigrate ユーティリティーは、Calendar Server 6.0、6.1、または 6.2 データベースを Calendar Server 6.3 データベースに移行するために使用されます。csmigrate ユーティリティーは、その他の管理ツールとともに Calendar Server 製品の sbin ディレクトリ内にあります。

ここでは、次の内容について説明します。

3.3.1 csmigrate ユーティリティーの構文

csmigrate コマンドの構文は次のとおりです。

csmigrate [-q] [-d] [-l min|max] [-b backup_dir] source_dbdir target_dbdir

オプションとその用途は次のとおりです。

-q (任意)

非出力モードを指定し、印刷指示は出しません。

-d (任意)

ドライランモードを指定し、新規データベースは書き込まれません。

-l min|max (任意)

ログレベルを指定します。移行ログは csmigrate.log に書き込まれ、エラーはデフォルトログディレクトリの csmigrateError.log に書き込まれます。

-b backup_dir (オプション)

ソースデータベースのバックアップを作成するディレクトリを指定します。プログラムはこのディレクトリにソースデータベースのバックアップを作成し、ソースデータベースを破損しないために、そのコピーに対して作業を行います。デフォルトの場所は、ソースデータベースディレクトリの backup です。

-source_dbdir (必須)

移行前のデータベースファイルが保存されているディレクトリ。

-target_dbdir (必須)

移行後のファイルが保存されるディレクトリ。

-V (サポートされるその他のオプション)

ツールのバージョン情報の印刷。

-? (サポートされるその他のオプション)

ツールの使用情報の印刷。

注 –

プログラムの終了コードは、失敗の場合は 255、成功の場合は 0 です。

3.3.2 csmigrate の例

csmigrate コマンドのオプションの使用例は次のとおりです。

csmigrate -b /var/opt/SUNWics5/tmpdb /var/opt/SUNWics5/old_db /var/opt/SUNWics5/new_db
csmigrate -q /var/opt/SUNWics5/old_db /var/opt/SUNWics5/new_db
csmigrate -l min old_db /var/opt/SUNWics5/new_db
csmigrate -l max old_db /var/opt/SUNWics5/new_db

ProcedureCalendar Server の csmigrate ユーティリティーの実行方法

  1. root 権限でログインします。

  2. すべてのサービスを停止します。

    たとえば、次のコマンドを実行します。

    stop-cal

  3. 現在のデータベースを一時ディレクトリに移動します。

    たとえば、csdb ディレクトリ全体を oldcsdb に移動します。

    mv cal-svr-base/SUNWics5/csdb/* cal-svr-base/SUNWics5/oldcsdb

  4. 新規ディレクトリと、そのディレクトリ内の古いファイルの両方が、デフォルト管理者 (icsuser、icsgroup) によって所有されていることを確認します。

    所有権が誤っている場合は、次のコマンドを使用して所有権を変更します。

    chown -R icsuser:icsgroup /cal-svr-base/SUNWics5/oldcsdb/

  5. 移行ツールを実行します。

    次の例に示すように、新規バックアップコピー (oldcsdb) から csdb ディレクトリに移行します。

    cd cal-svr-base/SUNWics5/cal/sbin/ 
./csmigrate -l max /cal-svr-base/SUNWics5/oldcsdb cal-svr-base/SUNWics5/csdb

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

    たとえば、次のコマンドを使用します。

    stop-cal

3.4 cs5migrate ユーティリティー

csmigrate ユーティリティーは、Calendar Server 5.1.1 データベースを Calendar Server 6.3 レベルに移行するために使用されます。加えて、初期の Calendar Server 6 バージョンから移行するときに、定期的なオプションを使用しなかった場合にもこのユーティリティーを使用します。

cs5migrate ユーティリティーでは、次の作業を実行できます。

注 –

これまでに、Connection for Microsoft Outlook を使用する計画がなかった場合は、定期的なデータ変換を行わずにこのユーティリティーを実行することもできます。ただし、Calendar Server 6.3 以降では、定期的なデータを新しい形式に変換する必要があります。

このユーティリティーは、Calendar Server 6.3 ソフトウェアへのアップグレード後に、ほかの管理ツールとともに sbin ディレクトリに格納されます。

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 ユーザーカレンダの管理」を参照してください。

3.6 csvdmig

csvdmig ユーティリティーは、複数ドメイン環境で使用するカレンダデータベースおよび LDAP ユーザーおよびグループエントリを準備します。デフォルトドメインしか使用しない場合でも、このユーティリティーを実行する必要があります。

注 –

非ドメイン環境を、Calendar Server 6.3 の複数ドメイン環境に移行する場合は、このユーティリティーを使用する前に必ず csmig を実行してください。

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

3.6.1 csvdmig の機能

csvdmig ユーティリティーは、データベースと LDAP エントリに対して次の変更を加えます。

注意 – 注意 –

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

3.6.2 csvdmig の構文

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


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

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

オプション 

説明とデフォルト値 

-m MappingFile

マッピングファイルを指定する入力パラメータ。マッピングファイルについては、「3.6.2.1 マッピングファイル」を参照してください。デフォルトは MigrateMapping です。

-c ConfigFile

Calendar Server 設定ファイルを指定する入力パラメータ。デフォルトは ics.conf ファイルです。

-t DestinationDB

移行するデータベースの位置を指定する出力パラメータ。デフォルトは MigratedDB です。

ヒント –

常に -t オプションを使用します。

このオプションについて詳しくは、「3.6.2.2 出力先 DB」を参照してください。

-e ErrorFile

解決できないエラー用のエラーファイルの名前を指定する出力パラメータ。デフォルトは MigrateError です。

DB | LDAP

どのデータベースを変更するかを指定します。 

DB: カレンダデータベース

LDAP: LDAP ディレクトリ

デフォルトはカレンダデータベース (DB) です。

3.6.2.1 マッピングファイル

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

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

3.6.2.2 出力先 DB

移行されるデータベースの場所。ユーティリティーは、ここにあるファイルをアップデートします。csvdmig ユーティリティーを使用する前に、このディレクトリをバックアップしてください。

-t オプションを指定しなければ、ユーティリティーは現在のディレクトリ (コマンド行で pwd を実行することで指定されたディレクトリ) の内容の移行を試行しますが、その結果は予期できません。

3.6.3 csvdmig の例

次に csvdmig の例を示します。

3.7 commdirmig

commdirmig ユーティリティーでは、認証サービスに Access Manager を使用できるように、LDAP データを Sun LDAP Schema バージョン 1 から Schema バージョン 2 に移行します。過去のインストールが Schema バージョン 2 をすでに使用している場合は、このユーティリティーを再度実行する必要はありません。

3.7.1 commdirmig ユーティリティーの実行者

この移行ユーティリティーは、Schema バージョン 1 の LDAP データベースを Schema バージョン 2 に移行します。Access Manager ソフトウェアを認証に使用する場合は、このユーティリティーを実行して LDAP エントリを Schema バージョン 2 に変換する必要があります。

Access Manager を使用していない場合、Schema バージョン 2 は LDAP を使用するすべての Communications Suite 製品に最適な LDAP モードであるため、LDAP データの移行を検討することをお勧めします。

注 –

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

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

カレンダおよび LDAP データベースを、旧バージョンの Calendar Server ソフトウェアから Calendar Server ソフトウェアのバージョン 6.3 に移行するために必要なほかのすべての移行ユーティリティーを実行したあとに、commdirmig を実行します。

3.7.3 commdirmig ユーティリティーのマニュアルの参照先

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

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

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

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