以前のバージョンの Calendar Server (5.11 以前) を使用していた場合は、Calendar Server をインストールし、インストール後の設定を行ったあとで、コンポーネントデータベースと LDAP データベースの移行が必要になることもあります。
この章の 「権限ユーティリティーの選択」を参照すると、適切なユーティリティーを選択する場合に役立ちます。
この章で説明する内容は次のとおりです。
以前にインストールした Calendar Server 5.1.1 のカレンダデータベースと LDAP データベースのエントリがある場合は、Sun Java System Calendar Server をインストールしたあとで、次のユーティリティーを指定された順序で実行します。
cs5migrate
カレンダデータベースを Calendar Server バージョン 5 の形式からバージョン 6 の形式に移行します。これらのユーティリティーはテクニカルサポートからダウンロードして入手できます。
Connector for Microsoft Outlook の使用を計画しており、複数のコンポーネントが定期的に発生する予定の場合は、cs5migrate_recurring を使用します。このユーティリティーにより、定期的コンポーネントごとにマスターレコードと例外が作成されます。
定期的コンポーネントが既存のデータベースに格納されていない場合、または格納されていても Connector for Microsoft Outlook を使用する予定がない場合は、cs5migrate を使用します。
cs5migrate と cs5migrate_recurring のどちらも、テクニカルサポートサイトからのみ入手できます。これらは製品に同梱されていません。
Calendar Server 6 データベース内の各カレンダに所有者を割り当て、必要に応じて各カレンダ ID (calid) を所有者にマッピングします。これによって、ホストされた (仮想) ドメインおよび LDAP カレンダ検索データベース (CLD) プラグインがサポートされます。このユーティリティーは Calendar Server に同梱されています。cs5migrate のあと、csvdmig の前にこのユーティリティーを実行します。
カレンダのドメイン (@domainname) を各 calid に追加することにより、Calendar Server 6 サイトをアップグレードして、ホストされた (仮想) ドメインを使用するようにします。たとえば、sesta.com というドメインでは、jdoe の calid は jdoe@sesta.com となります。このユーティリティーは Calendar Server に同梱されています。cs5migrate および csmig のあとにこのユーティリティーを実行します。
Access Manager 6.1 以上で使用するために、LDAP データを Schema 1 から Schema 2 に移行します。このユーティリティーは Access Manager に同梱されています。
ユーティリティーには多数の選択肢があるため、次の図を参照して、どのユーティリティーを実行するかを選択してください。
csmig ユーティリティーでは、必要に応じて、カレンダデータベース内の各カレンダに所有者を割り当て、各カレンダ ID (calid) を所有者にマッピングします。
csmig ユーティリティーは、ホストされた (仮想) ドメインと LDAP カレンダ検索データベース (CLD) プラグインをサポートしています。移行されたデータベース内のカレンダには、LDAP CLD プラグインを使用してアクセスできます。LDAP CLD プラグインについては、第 6 章「複数のマシンへのカレンダデータベースの分散の設定」を参照してください。
ここで説明する内容は次のとおりです。
csmig 移行ユーティリティーでは、次の機能を実行します。
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 に変換されます。
csmig は、icsSubscribed、icsCalendar、icsCalendarOwned、icsFreeBusy、icsSet、およびリソースカレンダに対する uid を含む、関連するすべての LDAP エントリの LDAP 属性を更新します。csmig は、LDAP ディレクトリサーバーデータベース内の各カレンダの icsDWPHost 属性を作成します。icsDWPHost は、カレンダが存在するバックエンドサーバーのホスト名を指定します。
カレンダデータベースが破損していないこと。csdb check コマンドを使用してカレンダデータベースを確認し、必要に応じて csdb rebuild コマンドを実行してデータベースを再構築します。これらのコマンドについては、付録 D 「Calendar Server のコマンド行ユーティリティーのリファレンス」 を参照してください。
新しい移行先ターゲットデータベース、および、バックアップデータベースがある場合にはその分も含めて、十分なディスクの空き容量があること。
csmig を実行するには、icsuser、または設定中に指定した Calendar Server のランタイムユーザー ID としてログインします。スーパーユーザー (root) として csmig を実行する場合は、移行されたファイルに対するアクセス権のリセットが必要になることもあります。
ユーザー設定を格納する LDAP ディレクトリサーバーでカレンダユーザーの属性を管理するための権限も必要です。
Calendar Server は停止している必要があります。
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 モードを使用します。 |
Calendar Server 6 のインストールと設定が終わったら、csmig を実行して既存の Calendar Server と LDAP データを移行する必要があります。LDAP データの移行は、LDAP CLD プラグインを正常に動作させるために必要です。csmig を使用してカレンダデータを移行する場合は、次の手順を実行します。
comm_dssetup.pl を使用して Directory Server を設定します。
まだ comm_dssetup.pl を使用して LDAP 属性にインデックスを作成していない場合は、ここで行います。これによって、LDAP データの移行処理のパフォーマンスが大幅に向上します。
テストサーバー (本稼働サーバーではない) を使用して、テストドライランを実行します。
ドライランでは、実際の移行中に csmig によって何が行われるかがレポートされますが、データは移行されません。ドライラン後、実際に移行を行う前に、エラーを修正し、未解決のカレンダを処理する計画を決定します。
テストドライランの実行方法については、「csmig 移行の手順」を参照してください。
運用データを移行します。
本稼働では、csmig によって、カレンダデータベース (.db ファイル) と LDAP データ (ユーザーおよびグループの設定データ)、icsSubscribed、icsCalendar、icsCalendarOwned、icsFreeBusy、icsSet、および uid (リソースカレンダ用) が移行されます。移行後、すべてのカレンダリソースに LDAP エントリが作成されます。
運用データの移行方法については、「csmig 移行の手順」を参照してください。
必要に応じて、Calendar Server 6 を中継サーバーにインストールします。
カレンダデータベースのスナップショットを中継サーバーにコピーします。
次の作業を実行して、中継サーバー上に本稼働 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 エントリを検索し、エントリが移行前のカレンダ数と一致していることを確認します。
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/testcsdb/ ディレクトリに移行されます。
./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) で未解決のカレンダを確認し、「csmig 移行の手順」の 「csmig 移行の手順」の計画に従って問題を解決します。
csdb check コマンドを実行して、移行されたデータベースを確認します。破損が見つかった場合は、csdb rebuild を実行してデータベースを再構築します。
新しく移行されたデータベースを、caldb.berkeleydb.homedir.path パラメータで指定された /csdb ディレクトリにコピーします。あるいは、このパラメータを編集して、移行されたデータベースの新しい格納場所を指定します。
ics.conf ファイルで、必要に応じて次の設定パラメータを変更し、LDAP CLD プラグインを有効にします。
caldb.dwp.server.server-hostname .ip = "server-hostname " (ローカルサーバーを含む各バックエンドサーバー用)
caldb.cld.cache.homedir.path では、CLD キャッシュディレクトリの場所を指定します。デフォルトは、/var/opt/SUNWics5/csdb/cld_cache です。
LDAP CLD プラグインの設定パラメータの指定方法については、第 6 章「複数のマシンへのカレンダデータベースの分散の設定」を参照してください。
start-cal コマンドを使用して Calendar Server を再起動します。
Communications Express にログインし、移行されたカレンダのいくつかを確認して、正常に設定されたかどうかを検証します。
確認を行う間アラームを無効にするには、ics.conf ファイルで次の各パラメータを “no” に設定します。
ここでは、次のヒントとトラブルシューティングの例について説明します。
tchang:myCalendar という名前のカレンダの所有者がカレンダデータベース内の jsmith であるため、csmig のドライランのマッピングでは jsmith:tchang_myCalendar と表示されます。しかし、このカレンダの名前を tchang:myCalendar とし、tchang という所有者を割り当てるとします。
移行前に、cscal ユーティリティーを使用して、カレンダ tchang:myCalendar の所有者を tchang に変更します。これを実行すると、移行によってこのカレンダが tchang:myCalendar にマッピングされ、icsCalendarowned がユーザー ID tchang の LDAP エントリに追加されます。
移行後、LDAP カレンダ検索が有効になりますが、カレンダ検索ダイアログに何も結果が表示されないか、一部の結果だけが表示されます。
LDAP カレンダ検索を有効にすると、Calendar Server で検索に (&(objectclass=icscalendaruser)(icscalendarowned=*substr*)) を使用できるようになります。
次のフィルタを使用して LDAP データに対して 2 つの異なる検索を手動で実行し、出力を比較します。
フィルタ (&(objectclass=icscalendaruser)(icscalendarowned=*substr*)) を使用した LDAP 検索
フィルタ (icscalendarowned=*substr* ) を使用した LDAP 検索
サーバーで icsCalendarUser オブジェクトクラスを含むフィルタを使用するため、スキーマの確認が無効な状態で LDAP サーバーが配備され、一部のカレンダエントリが icsCalendarUser オブジェクトクラスなしでプロビジョニングされた可能性があります。
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 ユーティリティーでは、ホストされた (または仮想) ドメインを使用するサイトの Calendar Server データベースおよび LDAP ディレクトリサーバーデータベースが変更されます。
ホストされていない環境から移動している場合は、このユーティリティーを使用する前に必ず csmig を実行してください。
ここで説明する内容は次のとおりです。
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 [-t DestinationDB] [-c ConfigFile] [-e ErrorFile] [-m MappingFile] migrate [DB|LDAP] |
次の表に、csvdmig によって使用されるオプションと、各オプションの説明を示します。
オプション |
説明とデフォルト値 |
---|---|
-m MappingFile |
マッピングファイルを指定する入力パラメータ。マッピングファイルについては、「マッピングファイル」を参照してください。デフォルトは MigrateMapping です。 |
-c ConfigFile |
Calendar Server 設定ファイルを指定する入力パラメータ。デフォルトは ics.conf ファイルです。 |
-t DestinationDB |
データベースの位置を指定する出力パラメータ。デフォルトは MigratedDB です。 ヒント – 常に -t オプションを使用します。作業用ディレクトリ内のデータベースを移行しようとすると、予期しない結果が発生します。「出力先 DB」を参照してください。 |
-e ErrorFile |
解決できないエラー用のエラーファイルの名前を指定する出力パラメータ。デフォルトは MigrateError です。 |
DB | LDAP |
どのデータベースを変更するかを指定します。 DB: カレンダデータベース LDAP: LDAP ディレクトリ デフォルトはカレンダデータベース (DB) です。 |
表 4–1 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 ... usern usern@siroe.com
このユーティリティーでは、移行されたファイルは新しい DestinationDB には移動されません。-t オプションを指定する場合は、csvdmig を実行する前に、移行するデータベースファイルをそのディレクトリにコピーしておく必要があります。
-t オプションを使用しないと、ユーティリティーによって作業用ディレクトリ内のファイルが移行されるため、予期しない結果が発生します。
デフォルト値を使用して、LDAP ディレクトリサーバーのデータを移行します。
csvdmig migrate LDAP
Calendar Server データベースを移行します。
csvdmig -t targetDB -e errorFile -m mappingFile migrate
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 にバンドルされています。
ユーティリティーのパッチもテクニカルサポートから入手できます。