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

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

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

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

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

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

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

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 を実行してから、csvdmig を実行してください。

csmig の機能

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

csmig は、icsSubscribed、icsCalendar、icsCalendarOwned、icsFreeBusy、icsSet、および uid (リソースカレンダー用) など、関連するすべての LDAP エントリの LDAP 属性を更新します。csmig は、LDAP ディレクトリサーバーデータベース内の各カレンダーに、icsDWPHost 属性を作成します。icsDWPHost は、カレンダーが格納されるバックエンドサーバーのホスト名を示します。

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 に変換されます。

csmig の要件

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

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

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

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

csmig の構文

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

表 4-1 csmig のオプション
csmig のオプション	説明とデフォルト値
-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 モードでは使用されません。
-c calendarOwner	所有者がいないユーザーカレンダーの所有者を指定します。
-r resourceOwner	所有者がいないリソースカレンダーの所有者を指定します。
migrate\|dryrun	ユーティリティがどのモードで実行されているかを指定します。移行を行う場合は、migrate モードを使用します。実際に移行を行う前に出力マッピングファイルを生成する場合は、dryrun モードを使用します。

csmig 移行の手順

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

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

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

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

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

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

本番データを移行します。

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

本番データの移行方法については、「本番データを移行するには」を参照してください。

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

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

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

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

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

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

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

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

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

cal_svr_base/SUNWics5/cal/sbin ディレクトリに移動します。

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

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

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

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

cal_svr_base/SUNWics5/cal/sbin/stop-cal

dryrun オプション付きで csmig を実行します。たとえば、次のように入力します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

本番データを移行するには

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

cal_svr_base/SUNWics5/cal/sbin ディレクトリに移動します。

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

cal_svr_base/SUNWics5/cal/sbin/stop-cal

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

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

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

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

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

エラーファイル (csmig.errors) で未解決のカレンダーを確認し、「テストドライランを実行するには」の手順 13 の計画に従って問題を解決します。

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

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

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 章「複数のマシンへのカレンダーデータベースの分散の設定」を参照してください。

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

カレンダーユーザーインタフェース (Calendar Express または 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*)) と指定した ldapsearch

フィルタを (icscalendarowned=*substr*) と指定した ldapsearch

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

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

問題の例

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

basketball (5 個の予定あり)

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

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

解決策の例

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

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

問題

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

解決策

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

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

問題

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

解決策

csvdmig

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

「csvdmig の機能」

「csvdmig の構文」

「csvdmig の例」

csvdmig の機能

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

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

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

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

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

csvdmig の構文


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

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

表 4-2 csvdmig のオプション
オプション	説明とデフォルト値
-m MappingFile	マッピングファイルを指定する入力パラメータ。マッピングファイルの詳細については、「マッピングファイル」を参照してください。デフォルトは MigrateMapping です。
-c ConfigFile	Calendar Server 設定ファイルを指定する入力パラメータ。デフォルトは ics.conf ファイルです。
-t DestinationDB	データベースの位置を指定する出力パラメータ。デフォルトは MigratedDB です。「出力先 DB」を参照してください。
-e ErrorFile	解決できないエラー用のエラーファイルの名前を指定する出力パラメータ。デフォルトは MigrateError です。
DB\|LDAP	どのデータベースを変更するかを指定します。 DB: Calendar Server データベース LDAP: LDAP ディレクトリデフォルトはカレンダーデータベース (DB) です。

マッピングファイル

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

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

出力先 DB

csvdmig では、DestinationDB という変数のデフォルトが MigratedDB であっても、移行データベースを個別に作成しません。このオプションで指定した元のデータベースに適切な更新を行います。

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.x または Calendar Server 5.x を使用していた場合は、LDAP エントリが Schema 1 にフォーマットされています。新しい Calendar Server 6 2005Q1 環境で、認証に 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 を実行したあとでこのユーティリティを実行します。

マニュアルの参照先

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

ユーティリティの入手先

Sun Java Enterprise System 2005Q1 の場合、このユーティリティはユーザー管理ユーティリティ commadmin とともに Access Manager 2005Q1 にバンドルされています。

Access Manager をアップデートせず、Calendar Server 用の移行ユーティリティだけが必要な場合は、そのためだけのパッチをテクニカルサポートサイトから入手できます。

前へ目次索引次へ
Sun Java System Calendar Server 6 2005Q1 管理ガイド