Sun Java ロゴ     前へ      目次      索引      次へ     

Sun ロゴ
Sun Java System Calendar Server 管理ガイド 

第 4 章
移行ユーティリティ

Calendar Server をインストールして設定した後で、コンポーネントデータベースおよび LDAP データベースの移行が必要な場合があります。下位レベルのデータベースを現行バージョンにアップグレードする移行ユーティリティがいくつか提供されています。この章の「移行ユーティリティのロードマップ」を参照すると、適切なユーティリティの選択に役立ちます。

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

Calendar Server 移行ユーティリティの概要

Calendar Server 6 2004Q2 には、次の 2 種類のデータベース移行ユーティリティがあります。

コンポーネントデータベースの移行ユーティリティ

コンポーネントデータベースには、すべてのカレンダーユーザーおよびリソースについての、予定および仕事が含まれます。以下のユーティリティで、コンポーネントデータベースを移行します。

LDAP データベースの移行ユーティリティおよびアップグレードユーティリティ

LDAP データベースには認証 (ユーザーおよびリソースのエントリ) およびカレンダーの設定情報が含まれます。次のユーティリティでは、LDAP データのアップグレードや移行を行います。

移行ユーティリティのロードマップ

ユーティリティには多数の選択肢があるため、図 4-1 にユーティリティを使用する順序を決めるのに役立つロードマップを示します。

注

ics2migrate は Sun ONE Calendar Server 5.1.1 のダウンロード用プログラムにバンドルされています。また、csmig および csvdmig は Sun Java System Calendar Server 6 2004Q2 にバンドルされています。

Netscape Calendar Server 3.5 を使用している場合は、ncs4migrate を実行する前に Netscape Calendar Server 4.x に移行する必要があります。この移行ユーティリティはご購入先のテクニカルサポートサイトから入手できます。

図 4-1  Calendar Server の移行ユーティリティを実行するためのロードマップ

この図は、Calendar Server の移行ユーティリティを実行するためのロードマップを示しています。

Calendar Server 6.x をインストールして cs5migrate を実行した後で、ほかに実行する必要のある移行ユーティリティがあるかどうかを判断します。図 4-2 に、いくつかの設定シナリオと、各シナリオで実行する移行ユーティリティを示します。

図 4-2 設定のシナリオ

この図は、実行する LDAP 移行ユーティリティに影響を与えるいくつかの設定シナリオを示しています。

移行の Web サイト

特定のサイトにもっとも適した選択を行うために、テクニカルサポートの担当者に問い合わせて、詳細情報およびユーティリティのダウンロードプログラムを入手できる Web サイトを確認してください。

その Web サイトで、表示される簡単な質問に答えると、使用するユーティリティを決定し、移行プロセスでどのようなダウンタイムが発生するかを推測するのに役立ちます。

警告

現在のサイトに限定的な仮想ドメインモードが設定されていたり、複数の Calendar Server インスタンスが設定されていたりする場合は、移行要件の評価についてご購入先の顧客サービスの担当者に問い合わせ、その要件をサポートする特定の移行ユーティリティが手元にあるかどうか確認してください。

場合によっては、Sun Microsystems のテクニカルサポートまたは Professional Services に問い合わせるように指示されることがあります。

注

cs5migrate は Calendar Server 製品にバンドルされますが、このユーティリティを実行しようとすると、次のメッセージが表示されます。

!!!!!!!!!!PLEASE NOTE!!!!!!!!!!

Calendar Server 6.0 に移行するには、ご購入先のテクニカルサポートまたは販売代理店に問い合わせ、最新バージョンのユーティリティを入手してください。

ics2migrate

ics2migrate ユーティリティは iPlanet Calendar Server 2.x のカレンダーデータおよび LDAP のユーザー設定を Sun ONE Calendar Server 5.x に移行します。

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

移行の要件

Calendar Server 2.x から 6.x への移行には、以下のハードウェアおよびソフトウェアが必要となります。

ソースマシンおよび出力先マシンは、別のサーバーにすることも、同じサーバーにすることもできます。サポートされるプラットフォームについては、『Sun Java System Calendar Server リリースノート』を参照してください。

移行対象

次の表に、Calendar Server 2.x データの一覧と、ics2migrate によるデータの Calendar Server 6.x への移行方法を示します。

表 4-1 Calendar Server 2.x データの移行

Calendar Server 2.x データ

Calendar Server 6.0 への移行結果

カレンダープロパティ (calprops) 

Calendar Server の calprops データベースを更新する

予定

Calendar Server の events データベースを更新する

仕事

Calendar Server の todos データベースを更新する

アラーム

予定や仕事の書き込み中に、alarms データベースを更新する

次の表に、Calendar Server 2.x の LDAP 属性の一覧と、ics2migrate による属性の Calendar Server 6.x への移行方法を示します。

表 4-2 LDAP 属性の移行 

Calendar Server 2.x の LDAP 属性

Calendar Server 6.0.x の LDAP 属性

nswcalUser *

icsCalendarUser *

nswcalCalID

icsCalendar

nswcalExtendedUserPrefs

icsExtendedUserPrefs

ceCalList **

icsSubscribed

ceAgendaList **

icsSet

ceDefaultAgenda **

icsDefaultSet

ceDefaultTZID **

icsTimeZone

ceFirstDayWeek **

icsFirstDay

* オブジェクトクラス

** 以前は nswcalExtendedUserPrefs の一部だった

移行プロセス

2.x から 5.x に移行するには、以下を実行します。

 

警告

ics2migrate を実行する前に、csbackup ユーティリティや Sun StorEdge Enterprise BackupTM ソフトウェア、Legato Networker® などを使用して、カレンダーデータベースのバックアップを作成します。

db_upgrade によってデータベースが同じ場所でアップグレードされるため、カレンダーデータベースのバックアップを作成することが非常に重要です。アップグレード中に問題が発生した場合は、データベースが回復不能な状態になる可能性があります。

2.x Berkeley データベースに対する db_recover の実行

移行前に Berkeley DB db_recover ユーティリティを実行して、ログファイルのトランザクションをデータベースにマージします。このユーティリティを使用しない場合は、マージされていないトランザクションが失われます。

Calendar Server 5.1.1 のダウンロードおよびインストール

次のサイトで入手できる『iPlanet Calendar Server 5.1 インストールガイド』を参照してください。

http://docs.sun.com/db/doc/816-1459-01?l=ja

2.x カレンダーデータベースのアップグレード

Calendar Server 5.1.1 には Sleepycat Software Inc. 製の Berkeley DB バージョン 3.2.9 が必要です。ics2migrate を実行する前に、Berkeley DB の db_upgrade ユーティリティを使用してカレンダーデータベースをバージョン 3.2.9 にアップグレードする必要があります。Calendar Server 5.x では、次のディレクトリに Berkeley DB のユーティリティがあります。

cal_svr_base/opt/SUNWics5/cal/tools/unsupported/bin

Berkeley DB ユーティリティの詳細については、次の Web サイトを参照してください。

http://www.sleepycat.com/docs/utility/index.html

データベースをバージョン 3.2.9 にアップグレードする方法

  1. Solaris や他の UNIX システムで、Calendar Server を実行しているユーザーおよびグループ、たとえば icsgroup および icsuser としてログインします。
  2. 必要な場合は、2.x Calendar Server を停止します。
  3. まだ作成していなければ、カレンダー 2.x データベースのバックアップを作成します。
  4. 次のディレクトリに、古い共有ファイル (__db_name.share) やログファイル (log.*) があれば削除します。

    5. cal_svr_base/opt/SUNWics5/cal/lib/http

    cal_svr_base/var/opt/SUNWics5/csdb

  5. db_upgrade ユーティリティを実行して、2.x のカレンダーデータベースをバージョン 3.2.9 にアップグレードします。2.x のカレンダーデータベースがあるディレクトリがカレントディレクトリになっていない場合、-h オプションを使用してデータベースファイルを指定します。

    6. 注 : すべての 2.x データベースファイル (alarms.db、calprops.db、events.db、および todos.db) に対して db_upgrade を実行する必要があります。サーバーが直接カレンダーデータベースに接続されていない場合でも、Calendar Server 構成のすべてのフロントエンドサーバーとバックエンドサーバーに対して db_upgrade を実行する必要があります。

  6. Calendar Server 2.x caldb.conf ファイルをデータベースファイルとともに csdb ディレクトリに格納し、ファイルの 1 行目を次のように変更します。

    7. 古い値: caldb.version "1.0.0 [BerkeleyDB]"

    新しい値: caldb.version= "1.0.0 [BerkeleyDB]"

    注 : このファイルが csdb ディレクトリにない場合は、テキストエディタを使用して作成し、1 行目に新しい値を設定します。

データの移行 (ics2migrate の実行)

次の手順に従って、ics2migrate を実行します。

  1. ics2migrate が格納されているディレクトリに変更します。
  2. ics2migrate の構文内の構文を使用して、ics2migrate を実行します。
  3. 移行後、ics.conf ファイル内の caldb.berkeleydb.homedir.path パラメータが、移行されたデータベースを指していることを確認します。
  4. csdb check コマンドを実行し、必要に応じて csdb rebuild コマンドを実行してカレンダーデータベースを再構築します。
ics2migrate の構文
Calendar Server 2.x データベースと LDAP ユーザー設定の両方を移行する場合

ics2migrate [-q] [-s def|none] [-f def|none] [-l min|max] source target

Calendar Server 2.x データベースだけを移行する場合

ics2migrate [-q] [-m db] [-s def|none] [-f def|none] [-l min|max] source target

LDAP ユーザー設定だけを移行する場合

ics2migrate [-q] [-m ldap]

注

構文を表示するには、オプションなしで ics2migrate を実行します。

表 4-3 に、ics2migrate のオプションと各オプションの説明を示します。

表 4-3 ics2migrate のオプション 

ics2migrate のオプション

説明

[-q]

非出力モードで実行する。正常に移行された場合は、ics2migrate によりコンソールに情報が表示されることはない。移行に失敗した場合は、ics2migrate によりエラーだけが表示される

デフォルトは冗長モード

[-m db|ldap]

db : カレンダーデータベースだけを移行する

ldap : LDAP ユーザー設定だけを移行する

デフォルトでは、カレンダーデータベースとLDAP ユーザー設定の両方を移行する

[-s def|none]

def : ユーザーのデフォルトカレンダーへのスケジュール設定のアクセス権だけを付与する

none : すべてのユーザーのカレンダーへのスケジュール設定のアクセス権を拒否する

デフォルトでは、すべてのカレンダーへのスケジュール設定のアクセス権を付与する

[-f def|none]

def : ユーザーのデフォルトカレンダーへの空き時間 / 予定ありの設定アクセス権だけを付与する

none : すべてのユーザーのカレンダーへの空き時間 / 予定ありの設定アクセス権を拒否する

デフォルトでは、すべてのカレンダーへの空き時間 / 予定ありの設定のアクセス権を付与する

[-l min|max]

min : データ移行の最小限の統計情報、つまり各カレンダーのカレンダー ID、一次所有者、および予定と仕事の数を記録する

max : データ移行の最大限の統計情報、つまり最小限の統計情報に加えて、各予定および仕事の参加者の数とアラームを記録する

ics2migrate により、cal_svr_base/opt/SUNWics5/cal/sbin ディレクトリ内の ics2migrate.log に統計情報が記録される

デフォルトでは、ics2migrate によりコンソールに移行の統計情報が表示され、ログファイルは生成されない

source

Calendar Server 2.x データベースファイルが格納されるディレクトリ

-m db オプションが指定された場合、または-m オプションが省略された場合に、データベース移行に source が必要となる

target

Calendar Server 6.0.x データベースファイルが格納されるディレクトリ

-m db オプションが指定された場合、または-m オプションが省略された場合に、データベース移行に target が必要となる

移行結果の確認

移行が完了したら、次のように結果を確認します。

移行の例

ここでは、次の場合の例を示します。

非出力モードでの移行

非出力モードで操作することを除いては、前述の例と同じように移行を実行します。ics2migrate によりコンソールに移行の統計情報が表示されることはなく、ログファイルも生成されません。

ics2migrate -q /var/opt/SUNWicsrv/2x_db /var/opt/SUNWics5/50_db

カレンダーデータベースのみの移行

2x_db ディレクトリ (現在のディレクトリに対する相対パス) に格納されている 2.x カレンダーデータベースだけを移行し、/var/opt/SUNWics5/50_db ディレクトリに 6.0 データベースを作成します。

ics2migrate -m db 2x_db /var/opt/SUNWics5/50_db

LDAP ユーザー情報のみの移行

Calendar Server 2.x の LDAP ユーザー情報だけをバージョン 6.0 のフォーマットに移行します。

ics2migrate -m ldap

カレンダーデータベースと LDAP ユーザー情報の両方を移行

LDAP ユーザー情報と Calendar Server 2.x のデータベースの両方を移行します。Calendar Server 2.x のデータベースは /var/opt/SUNWicsrv/2x_db ディレクトリに格納され、6.0 のデータベースは /var/opt/SUNWics5/50_db ディレクトリに格納されます。

すべてのカレンダーへのスケジュール、空き時間 / 予定ありの設定アクセス権を付与し、ics2migrate.log という名前のログファイルに移行の最小限の統計情報を記録します。

ics2migrate /var/opt/SUNWicsrv/2x_db /var/opt/SUNWics5/50_db -l min

csmig

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

csmig ユーティリティでは、ホストされた (仮想) ドメインおよび LDAP Calendar Lookup Database (CLD) プラグインがサポートされます。移行されたデータベース内のカレンダーには、このプラグインを使用してアクセスできます。LDAP CLD プラグインは、カレンダーを多数のバックエンドサーバーに分散することによって、カレンダーデータベースの水平方向のスケーラビリティを提供します。LDAP CLD プラグインの詳細については、『Sun Java System Calendar Server 6 2004Q2 管理ガイド』を参照してください。

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

csmig の機能

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

csmig の要件

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

csmig 構文

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

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

-t DestinationDB は、csmig で生成する出力先ターゲットデータベースを指定します。デフォルトは MigratedDB です。

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

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

-e ErrorFile は、csmig によってあらゆるエラーや解決できないデータベースエントリが書き込まれるファイルです。解決できないデータベースエントリは、出力先データベースに書き込まれません。デフォルトは MigrateError です。

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

例 :

Old calid = jsmith New calid = jsmith:basketball

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

migrate モードでは、MappingFile は使用されません。

-c calendarOwner では、所有者がいないユーザーカレンダーの所有者を指定します。

-r resourceOwner では、所有者がいないリソースカレンダーの所有者を指定します。

csmig 移行の手順

構成内のすべてのサーバーに Calendar Server 6.0 をインストールした後、csmig を実行して既存の Calendar Server および LDAP データを新しい Calendar Server 6.0 および LDAP データに移行する必要があります。これは、LDAP CLD プラグインを正常に動作させるために必要です。次の手順を使用して、csmig を使用するカレンダーデータを移行します。

  1. LDAP ディレクトリサーバーの設定: インデックスを追加すると、移行および LDAP データでのカレンダー検索のパフォーマンスが大幅に向上します。
  2. テストドライランの実行: ドライランでは移行中に csmig によって何が行われるかがレポートされますが、実際のデータは移行されません。ドライラン後、エラーを修正し、未解決のカレンダーを処理する計画を決定できます。
  3. 運用データの移行: 本番稼働では、csmig によりカレンダーデータベース (.db ファイル) および LDAP データ (ユーザーおよびグループの設定データ)、icsSubscribed、icsCalendar、icsCalendarOwned、icsFreeBusy、icsSet、および uid (リソースカレンダー用) が移行されます。移行後、すべてのカレンダーリソースに LDAP エントリが作成されます。

LDAP ディレクトリサーバーの設定

パフォーマンスを向上させるには、slapd.ldbm.conf ファイルに次の 2 つの新しいインデックスを追加することを考慮します。

slapd.ldbm.conf ファイルのインデックス作成の詳細については、ディレクトリ サーバーのマニュアルを参照してください。

テストドライランの実行

中継サーバーで実行されるテストドライランでは、移行対象はレポートされますが、運用データベースは実際には移行されません。ドライランによって、運用データベースの移行計画を決定できます。たとえば、"親のない" カレンダー、すなわち所有者のいないカレンダーの処理方法を決定できます。

csmig を使用したドライランは、次の手順で実行します。

  1. icsuser (または設定中に指定された Calendar Server 実行時ユーザー ID) としてログインします。スーパーユーザー (root) として csmig を実行すると、場合によっては移行されたファイルに対するアクセス権をリセットする必要があります。
  2. 必要に応じて、中継サーバーに Calendar Server 6.0 をインストールします。
  3. カレンダーデータベースのスナップショットを中継サーバーにコピーします。
  4. LDAP サーバーをインストールし、疑似的な運用 LDAP 環境を構築します。このサーバーに、slapd.ldbm.conf ファイルの新しいインデックスとともに LDAP データベースのスナップショットをインストールします。
  5. cal_svr_base/opt/SUNWics5/cal/sbin ディレクトリに移動します。
  6. 所有者がいないユーザーカレンダーにキャッチオール calid を作成することを考慮します。たとえば、Solaris システムで次のコマンドを実行すると、orphan の calid を持ったユーザーが作成されます。

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

  7. 必要に応じて、stop-cal コマンドを使用して Calendar Server を停止します。
  8. csdb check コマンドを実行して、データベースに破損が生じていないかどうかを確認します。破損が見つかった場合は、csdb rebuild を実行してデータベースを再構築します。
  9. dryrun オプション付きで csmig を実行します。たとえば、Solaris システムでは次のように入力します。

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

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

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

  10. 出力ファイル、マッピングファイル、およびエラーファイルを確認します。検出された LDAP の問題やエラーを解決します。実際の移行の前に、未解決のカレンダーを処理する方法を決定します。選択肢は以下のとおりです。
    • 移行する前に、不要なカレンダーを削除します。
    • 未解決のカレンダーに所有者を割り当てます。
    • -c オプションと -r オプションを使用して csmig を実行し、移行中にカレンダーに所有者を割り当てます。
  11. 実際の運用データベースを移行する前に、中継サーバー上のカレンダーデータベースを移行します。この手順を実行すると、実際にデータがどのように移行されるかがわかり、運用データベースを移行する前に問題を解決できます。

    12. たとえば、Solaris システムで次のコマンドを実行すると、カレンダーデータベースが /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

  12. テスト移行が完了したら、移行されたデータベースを caldb.berkeleydb.homedir.path パラメータによって指定された /csdb ディレクトリにコピーします。あるいは、このパラメータを編集して、移行されたデータベースの新しい格納場所を指定します。それから以下の確認を行います。
    • 新しいカレンダーデータベースで csdb check を実行します。移行されたデータベースの予定や仕事の数は、移行前の合計数と一致している必要があります。
    • icsCalendarOwned エントリを検索し、エントリが移行前の数と一致していることを確認します。
    • Calendar Express にログインし、移行されたデータベースのいくつかのカレンダーを検証します。

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

運用データの移行

csmig を使用して運用データベースを移行するには、次の手順を実行します。

  1. icsuser (または設定中に指定された Calendar Server 実行時ユーザー ID) としてログインします。スーパーユーザー (root) として csmig を実行すると、場合によっては移行されたファイルに対するアクセス権をリセットする必要があります。
  2. cal_svr_base/opt/SUNWics5/cal/sbin ディレクトリに移動します。
  3. 必要に応じて、stop-cal コマンドを使用して Calendar Server を停止します。
  4. 以下のデータのバックアップを作成します。
    • カレンダーデータベース (.db ファイル)
    • LDAP データ: slapd データベース ディレクトリおよび LDAP データベース
    • ics.conf ファイル。この手順は実際には必要ありませんが、元の設定に戻す必要がある場合に役立ちます。
  5. migrate オプション付きで csmig を実行します。たとえば、Solaris システムで次のコマンドを実行すると、カレンダーデータベースが /var/opt/SUNWics5/newcsdb/ ディレクトリに移行されます。

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

  6. エラーファイルで未解決のカレンダーを確認し、「テストドライランの実行」の手順 10 の計画に従って問題を解決します。
  7. 新しく移行されたデータベースを caldb.berkeleydb.homedir.path パラメータで指定された /csdb ディレクトリにコピーします。あるいは、このパラメータを編集して、移行されたデータベースの新しい格納場所を指定します。
  8. csdb check コマンドを実行して、移行されたデータベースを確認します。破損が見つかった場合は、csdb rebuild を実行してデータベースを再構築します。
  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 キャッシュディレクトリの場所を指定します。デフォルトは cal_svr_base/var/opt/SUNWics5/csdb/cld_cache です。

      このディレクトリが正しいかどうか確認します。CLD キャッシュに別の場所を指定する場合は、このパラメータを変更します。

      LDAP CLD プラグインの設定パラメータの詳細については、『Sun Java System Calendar Server 6 2004Q2 管理ガイド』を参照してください。

  10. start-cal コマンドを使用して Calendar Server を再起動します。
  11. Calendar Server にログインし、移行されたカレンダーのいくつかを確認して設定に成功したかどうか検証します。確認を行う間アラームを無効にするには、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 ドライランカレンダーの所有者が、意図した所有者とは異なる

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

解決策

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

LDAP カレンダー検索を正常に実行できない

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

解決策

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

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

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

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

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

ドライランで、移行中に 2 つのカレンダーがマージされ、その結果としてカレンダーが次のようになります。

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

Error modifying calendar properties, error=2

解決策

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

親のないカレンダーに複数の所有者を割り当てる方法

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

解決策

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

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

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

解決策

カレンダーユーザーを移動するには、元のサーバーにある各ユーザーのカレンダーをエクスポートし、2 台目のサーバーにカレンダーをインポートします。カレンダーの移動後、元のサーバー上のカレンダーを削除できます。ユーザー移動の詳細については、『Sun Java System Calendar Server 6 2004Q2管理ガイド』を参照してください。

csvdmig

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

csvdmig 構文

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

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

-m MappingFile はマッピングファイルを指定する入力パラメータです。デフォルトは MigrateMapping です。

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

例 :

user1 user1@sesta.com
user2 user2@siroe.com
user3 user3@sesta.com
...
user-n user-n@siroe.com

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

-t DestinationDB は、移行されたデータベースの場所を指定する出力パラメータです。デフォルトは MigratedDB です。

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

DB | LDAP では、Calendar Server データベース (DB) または LDAP ディレクトリサーバー (LDAP) のどちらを変更するかを指定します。デフォルトはカレンダーデータベース (DB) です。

csvdmig の例



前へ      目次      索引      次へ     

Copyright 2004 Sun Microsystems, Inc. All rights reserved.