| Sun ONE Calendar Server 6.0 インストールガイド (Solaris 版) |
第 3 章
Calendar Server データの移行SunTM ONE Calendar Server 6.0 には、次の移行ユーティリティがあります。
- cs5migrate ユーティリティ Calendar Server 5.x データベースを Calendar Server 6.0 へ移行し、カレンダデータベースを Berkeley DB バージョン 2.6 からバージョン 3.2.9 へアップグレードします。
- csmig ユーティリティ カレンダデータベースの各カレンダに所有者を割り当て、必要に応じて各カレンダ ID (calid) を所有者にマッピングします。これにより、ホスト (仮想) ドメインおよび LDAP Calendar Lookup Database (CLD) プラグインを使用できます。
- csvdmig ユーティリティ 仮想ドメイン (ホストドメイン) を使用できるように、Calendar Server 6.0 サイトをアップグレードします。
- ics2migrate ユーティリティ iPlanet Calendar Server 2.x からデータを移行します。
- ncs4migrate ユーティリティ Netscape Calendar Server 4.x からデータを移行します。
- csrename ユーティリティ カレンダデータベースと LDAP ディレクトリサーバー内のカレンダユーザーの名前を変更します (プレフィックス「ics」が付いた Calendar Server 属性)。
図 3-1 に、Calendar Server 移行ユーティリティの実行フローを示します。
図 3-1 Calendar Server 移行ユーティリティの実行フロー
cs5migrate ユーティリティCalendar Server 5.x から Calendar Server 6.0 にアップグレードしている場合は、Calendar Server 6.0 の実行前に cs5migrate ユーティリティを実行する必要があります。cs5migrate ユーティリティの機能は次のとおりです。
移行の所要時間
cs5migrate による移行にかかる時間は、さまざまな要因で変化します。第 1 に cs5migrate では、スキーマ属性を更新するため、LDAP ディレクトリサーバーにアクセスする必要があります。そのため LDAP サーバーへのネットワーク接続が移行時間に大きく影響します。可能な限り、LDAP サーバーへの高速ネットワーク接続を使用し、その他のネットワークトラフィックが最小のときに cs5migrate を実行してください。
移行シナリオ Sun FireTM (UltraSPARCTM III Cu、12 CPU、750MHz、メモリ 12G バイト、浮動小数点プロセッサ付、20G バイトのスワップファイルスペースで Solaris 8 OS を使用) では、次の Calendar Server 5.x カレンダデータベースを約 1 時間 15 分で移行しました。
cs5migrate の構文
csmig ユーティリティは、次の構文を使用します。
-q を指定すると非出力モードになります。非出力モードでは、エラーが検出された場合にのみ情報が表示されます。移行処理が正常に完了した場合、情報は表示されません。
-d を指定するとドライランモードになります。ドライランモードでは、データの移行やデータベースのアップグレードは行われません。実際に移行を実施したときの cs5migrate の処理内容が報告されるだけです。
-r を指定すると、繰り返し発生するイベントのマスターコンポーネントを作成します。
-l min|max では、ログモードと移行ログ (cs5migrate.log) の詳細レベルを指定します。
注 -t オプションは、現在のリリースでは実装されていません。
source-directory は、Calendar Server 5.x データベースファイルが格納されたディレクトリを指定する必須パラメータです。
target-directory は、新しい Calendar Server 6.0 データベースファイルが作成される既存のディレクトリを指定する必須パラメータです。
重要 cs5migrate の実行前に、target-directory を作成する必要があります。
移行プロセス
cs5migrate の実行前に、次の手順に従ってください。
- csbackup、Sun StorEdge Enterprise BackupTM、Legato Networker などのユーティリティを使って、Calendar Server 5.x データベースのバックアップを作成します。
- 移行前に csbd rebuild コマンドを使用してカレンダデータベースを再構築します。詳細については、『Sun ONE Calendar Server 管理者ガイド』の第 5 章「Calendar Server データベースの管理」を参照してください。
- 必要に応じてアラームを有効にします。アラームを有効にするには、ics.conf ファイル内の caldb.serveralarms パラメータの値を yes に設定します。
- Calendar Server 5.x データベースを別のサーバーに移動する必要がある場合、データベースファイル (*.db) がそれほど大きくない場合は、単に新しいサーバーにコピーできます。そうでない場合は、データベースファイルの tar ファイルを作成し、その tar ファイルを新しいサーバーにコピーして、untar を実行します。
次の手順に従って、cs5migrate を実行します。
- Solaris またはその他の UNIX システムの場合は、Calendar Server を実行するユーザー名 (例: icsuser) とグループ名 (例: icsgroup) を指定してログインします。
- 必要に応じて stop-cal コマンドを使って Calendar Server サービスを停止します。
- 必要に応じて target-directory を作成します。target-directory は cs5migrate の実行前に存在している必要があります。
- cs5migrate を実行します。構文については、「cs5migrate の構文」を参照してください。
たとえば、Solaris システムでは、次を入力します。
./cs5migrate -q -l max /var/opt/SUNWics5/csdb511
/var/opt/SUNWics5/csdb60
この例では、移行前に /var/opt/SUNWics5/csdb60 ディレクトリが存在している必要があります。
移行ステータスについては、cs5migrate.log ファイルで確認してください。移行中にエラーが発生した場合や、カレンダデータベースエントリを移行できない場合は、cs5migrate によってその旨が cs5migrateerror.log に書き込まれます。
- cs5migrate では ics.conf ファイルを変更しないため、cs5migrate の実行が終了したら、ics.conf ファイルの caldb.berkeleydb.homedir.path パラメータが移行したデータベースを示している必要があります。
移行したデータベースディレクトリを指すようにパラメータを設定し直すか、移行したデータベースファイルをパラメータが示すディレクトリに移動します。
- LDAP データキャッシュオプション (local.ldap.cache.enable = "yes") または CLD キャッシュオプション (caldb.cld.cache.enable = "yes") を使用している場合は、cs5migrate の実行後、ターゲットディレクトリに ldap_cache および cld_cache ディレクトリを作成します。
- 移行したデータベースファイルのアクセス権を確認します。cs5migrate を icsuser として実行した場合は、アクセスに問題はありません。スーパーユーザー (root) として実行することは推奨されませんが、その場合は、アクセス権を設定し直さなければならないことがあります。
- start-cal コマンドを使用して Calendar Server を再起動します。
csmig ユーティリティcsmig ユーティリティは、カレンダデータベースの各カレンダに所有者を割り当て、必要に応じて各カレンダ ID (calid) を所有者にマッピングします。
csmig ユーティリティでは、ホスト (仮想) ドメインおよび LDAP Calendar Lookup Database (CLD) プラグインを使用できます。移行したデータベースのカレンダは、このプラグインを使用してアクセスできます。LDAP CLD プラグインはカレンダを多数のバックエンドサーバーに配布することによってカレンダデータベースの水平方向のスケーラビリティを提供します。LDAP CLD プラグインの詳細については、『Sun ONE Calendar Server 管理者ガイド』を参照してください。
このマニュアルでは、次のトピックを取り上げます。
csmig の機能
csmig 移行ユーティリティには次の機能があります。
- csmig は、icsSubscribed、icsCalendar、icsCalendarOwned、icsFreeBusy、icsSet、および uid (リソースカレンダ用) など、すべての関連のある LDAP エントリに対して LDAP 属性を更新します。csmig は、LDAP ディレクトリサーバーデータベースの各カレンダに対して icsDWPHost 属性を作成します。icsDWPHost は、カレンダが常駐するバックエンドサーバーのホスト名を指定します。
- csmig は、カレンダデータベースの各カレンダに所有者を割り当て、必要に応じて各カレンダ ID (calid) を所有者にマッピングします。すべてのデフォルトの calids は現状のまま維持され、変更は行われません。ほかのカレンダは次のように割り当てられます。
csmig 要件
csmig を使用する際の要件は次のとおりです。
- カレンダデータベースは破損がないようにしてください。csdb check コマンドを使用してカレンダデータベースを検査し、必要に応じて csdb rebuild コマンドを実行してデータベースを再構築します。これらのコマンドの詳細については、『Sun ONE Calendar Server 管理者ガイド』を参照してください。
- 新しい宛先ターゲットデータベース用に十分なディスク容量が必要です。該当する場合には、バックアップデータベースの容量も必要です。
- csmig を実行するには、icsuser (または設定中に指定した Calendar Server 実行時ユーザー ID) としてログインします。csmig をスーパーユーザー (root) として実行すると、移行したファイルのアクセス権を設定し直さなければならないことがあります。
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 は、LDAP スキーマのエントリを更新するために要求される変更をリストするドライランモードで生成される出力マッピングファイルです。内容は、次のようになります。
Old calid = jsmith New calid = jsmith:basketball
マッピングファイルでは LDAP スキーマに望ましい変更がリストされるだけです。csmig ではスキーマに実際の変更を加えません。
移行モードでは、MappingFile は使用されません。
-c calendarOwner には、所有者のないユーザーカレンダに付与する所有者名を指定します。
-r resourceOwner には、所有者のないリソースカレンダに付与する所有者名を指定します。
csmig 移行手順
構成内のすべてのサーバーに Calendar Server 6.0 をインストールしてから、csmig を実行して、既存の Calendar Server および LDAP データを新しい Calendar Server 6.0 および LDAP データに移行します。適切に動作するためには、LDAP CLD プラグインが必要です。csmig を使用してカレンダデータを移行する推奨手順は次のとおりです。
- LDAP ディレクトリサーバーの設定 インデックスを追加すると、LDAP データ上の移行およびカレンダ検索のパフォーマンスが向上します。
- テストドライランの実行 ドライランは、移行時の csmig の実行内容を報告しますが、実データは移行しません。ドライランを行ったあとで、エラーを訂正したり、未解決カレンダを処理する計画を決定できます。
- 実働データの移行 本番稼動の間、csmig はカレンダデータベース (.db ファイル) および LDAP データ (ユーザーおよびグループ設定の変更データ) の icsSubscribed、icsCalendar、icsCalendarOwned、icsFreeBusy、icsSet、および uid (リソースカレンダ用) を移行します。移行のあとで、すべてのカレンダリソースに LDAP エントリが作成されます。
LDAP ディレクトリサーバーの設定
パフォーマンスを向上させるには、次の 2 つの新しいインデックスを slapd.ldbm.conf ファイルに追加します。
slapd.ldbm.conf ファイルでインデックスを作成することについての詳細は、ディレクトリサーバーに付属のマニュアルを参照してください。
テストドライランの実行
ステージングサーバー上で実行したテストドライランは、何が移行されるのかを報告しますが、実働データベースを実際に移行することはありません。ドライランによって実働データベースを移行する計画を決定することができます。たとえば、所有者を持たない「orphan」カレンダを処理する方法を決定できます。
csmig を使用してテストドライランを実行するには、次の手順に従います。
- icsuser (または設定中に指定した Calendar Server 実行時ユーザー ID) としてログインします。csmig をスーパーユーザー (root) として実行すると、移行したファイルのアクセス権を設定し直さなければならないことがあります。
- ステージングサーバー上で、必要に応じて Calendar Server 6.0 をインストールします。
- カレンダデータベースのスナップショットをステージングサーバーにコピーします。
- LDAP サーバーをインストールして実働 LDAP 環境を模倣します。slapd.ldbm.conf ファイルの新しいインデックスとともに、このサーバー上に LDAP データベースのスナップショットをインストールします。
- cal_svr_base/opt/SUNWics5/cal/sbin ディレクトリに移動します。
- 所有者を持たないユーザーカレンダに多目的の calid を作成します。たとえば、Solaris システムでは、次のコマンドは orphan の calid を使用してユーザーを作成します。
./csuser -g orphan -s adminuser -y password -l en -c orphan create orphan
- 必要に応じて、stop-cal コマンドを使って Calendar Server を停止します。
- csdb check コマンドを実行してデータベースに破損がないかを検査します。破損が検出された場合、csdb rebuild を実行してデータベースを再構築します。
- dryrun オプションを使用して csmig コマンドを実行します。たとえば、Solaris システムでは、次を入力します。
./csmig -b sesta.com -o csmig.out -e csmig.errors -m csmig.map -c orphan -r calmaster dryrun
このコマンドを使用すると、orphan に所有者のないユーザーカレンダを割り当てて、calmaster に所有者のないリソースカレンダを割り当てます。
出力マッピングファイル (csmig.map) を確認します。マッピングファイルには LDAP スキーマのエントリ更新に望ましい変更がリストされています。
- 出力、マッピング、およびエラーファイルを検査します。検出したすべての LDAP 問題またはエラーを解決します。実際の移行の前に、未解決カレンダを処理する方法を決定します。次のようないくつかのオプションがあります。
- 実働カレンダデータベースを実際に移行する前に、ステージングサーバーにカレンダデータベースを移行することを推奨します。この手順によって、実働データベースを移行する前にデータがどのように移行されるのかを正確に確認し、問題があれば訂正することができます。
たとえば、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
- テスト移行が終了した後、移行したデータベースをcaldb.berkeleydb.homedir.path パラメータによって指定された /csdb ディレクトリにコピーします。あるいは、このパラメータを編集して移行したデータベースの新しい位置を示すように編集します。そのあと、下記のチェックを実行します。
テスト移行が成功した場合は、実働データベースを移行する準備ができています。
実働データの移行
csmig を使用して実働データベースを移行するには、次の手順に従います。
- icsuser (または設定中に指定した Calendar Server 実行時ユーザー ID) としてログインします。csmig をスーパーユーザー (root) として実行すると、移行したファイルのアクセス権を設定し直さなければならないことがあります。
- cal_svr_base/opt/SUNWics5/cal/sbin ディレクトリに移動します。
- 必要に応じて、stop-cal コマンドを使って Calendar Server を停止します。
- 次のデータのバックアップを作成します。
- migrate オプションを使用して csmig を実行します。たとえば、Solaris システムでは、次のコマンドで、カレンダデータベースを /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
- エラーファイルに含まれている、すべての未解決カレンダを確認のうえ、「テストドライランの実行」の手順 10 の記述を基にした計画に従って、それらを解決しておきます。
- 新しい移行したデータベースを caldb.berkeleydb.homedir.path パラメータによって指定された /csdb ディレクトリにコピーします。あるいは、このパラメータを編集して移行したデータベースの新しい位置を示すように編集します。
- csdb check コマンドを実行して移行したデータベースを検査します。何らかの破損が示された場合は、csdb rebuild を実行してデータベースを再構築します。
- 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 です。
- start-cal コマンドを使用して Calendar Server を再起動します。
- Calendar Server にログインし、いくつかの移行したカレンダを検査することにより、設定が正常に動作していることを検証します。検査中アラームを無効にするには、ics.conf ファイルにある次の各パラメータを「no」に設定します。
csmig の使用上のヒントおよびトラブルシューティング
この節では、csmig の使用上のヒントおよびトラブルシューティングの方法について説明します。
csmig ドライランカレンダの所有者をカレンダの所有者にしない場合
たとえば、tchang:myCalendar という名前のカレンダに、カレンダデータベースで所有者として jsmith があり、csmig ドライランがマッピングを jsmith:tchang_myCalendar として表示しているとします。このカレンダ名を tchang:myCalendar のまま保持し、所有者の割り当てを tchang にします。
解決策
移行の前に、cscal ユーティリティを使用してカレンダ tchang:myCalendar の所有者を tchang に変更します。このようにすると、移行の際、このカレンダは tchang:myCalendar にマッピングされ、tchang の LDAP エントリに icsCalendarowned が追加されます。
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 つの別々のカレンダのデータ整合性が保たれます。
複数の orphan カレンダを個別に所有者に割り当てる方法
csmig は、デフォルトで、すべての orphan カレンダを単一の所有者に割り当てます。しかし、orphan カレンダを複数の所有者に割り当てたい場合もあります。
解決策
csmig は、コマンド行からはマッピングファイルを受け付けません。ただし、移行の前に、元のデータベースで orphan カレンダに所有者を割り当てることができます。すべての orphan カレンダのドライランマッピングファイルを検査します。その後、移行の前に cscal ユーティリティを使用して orphan カレンダに所有者を割り当てます。dryrun モードで再び csmig を実行して新しい所有者を検証します。
カレンダユーザーをほかのバックエンドサーバーに移動する方法
ユーザーをバックエンドサーバー間で移動する方法は？
解決策
カレンダユーザーを移動するためには、元のサーバーから各ユーザーカレンダをエクスポートし、そのカレンダを新しいサーバーにインポートします。カレンダを移動させたら、元のサーバーにあるカレンダを削除できます。ユーザーの移動手順の詳細については、『Sun ONE Calendar Server 管理者ガイド』を参照してください。
csvdmig ユーティリティcsvdmig ユーティリティは、ホスト (仮想) ドメインを使用するサイトの Calendar Server データベースおよび LDAP ディレクトリサーバーデータベースを変更します。csvdmig ユーティリティでは、次のようにドメイン名をユーザー ID に追加します。
警告
csvdmig ユーティリティは、元の場所から別の場所への、実際のデータの移行はしません。このユーティリティは、それぞれ現在の場所にある、カレンダデータベースと LDAP ディレクトリサーバーを修正します。
したがって、csvdmig の実行に先立ち、Calendar Server データベースと LDAP ディレクトリサーバーデータベースの両者について、バックアップが必要になります。
csvdmig の構文
csvdmig ユーティリティは、次の構文を使用します。
-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 の実行例
ics2migrate ユーティリティics2migrate 移行ユーティリティでは、iPlanet Calendar Server 2.x のカレンダデータと LDAP ユーザー基本設定を Calendar Server 6.0 に移行できます。
この節では、次の項目について説明します。
移行要件
Calendar Server 2.x から 6.0 に移行する際のハードウェアおよびソフトウェア要件は次のとおりです。
ソースマシンと移行先マシンは、別々のサーバーであっても同一のサーバーであってもかまいません。サポート対象のプラットフォームについては、『Sun ONE Calendar Server リリースノート』を参照してください。
移行対象
次の表に、Calendar Server 2.x のデータと、ics2migrate を使ってこれらのデータを Calendar Server 6.0 へ移行する方法を説明します。
次の表に、Calendar Server 2.x LDAP 属性と、ics2migrate を使ってこれらの属性を Calendar Server 6.0 へ移行する方法を説明します。
移行プロセス
ics2migrate の手順は次のとおりです。
2.x カレンダデータベースのアップグレード
Calendar Server 6.0 では Sleepycat Software の Berkeley DB バージョン 3.2.9 が必要です。カレンダデータベースをバージョン 3.2.9 にアップグレードするために、ics2migrate の実行前に Berkeley DB db_recover および db_upgrade ユーティリティを使用する必要があります。Calendar Server 6.0 では、次のディレクトリに 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 にアップグレードするには :
- Solaris またはその他の UNIX システムの場合は、Calendar Server を実行するユーザー名 (例: icsuser) とグループ名 (例: icsgroup) を指定してログインします。
- 必要に応じて 2.x Calendar Server を停止します。
- カレンダ 2.x データベースをバックアップしていない場合は、バックアップします。
- 次の場所に古い共有ファイル (__db_name.share) またはログファイル (log.*) があれば、削除します。
cal_svr_base/opt/SUNWics5/cal/lib/http
cal_svr_base/var/opt/SUNWics5/csdb
- db_upgrade ユーティリティを実行して、2.x カレンダデータベースをバージョン 3.2.9 にアップグレードします。カレントディレクトリが 2.x カレンダデータベースと同じディレクトリでない場合は、-h オプションを使用して、データベースファイルの場所を示します。
注 db_upgrade はすべての 2.x データベースファイル (alarms.db、calprops.db、events.db、および todos.db) で実行する必要があります。また、db_upgrade は、Calendar Server を構成するフロントエンド、バックエンドのすべてのサーバー上で実行してください。サーバーがカレンダデータベースに直接接続されていない場合も、この処理を省略することはできません。
- データベースファイルのある csdb ディレクトリで Calendar Server 2.x の caldb.conf ファイルを探し、ファイルの先頭の行を次のように書き換えます。
元の値: caldb.version "1.0.0 [BerkeleyDB]"
新しい値: caldb.version= "1.0.0 [BerkeleyDB]"
注 : このファイルが csdb ディレクトリにない場合は、テキストエディタでファイルを作成し、先頭の行に新しい値を設定してください。
データの移行
次の手順で ics2migrate を実行します。
- ics2migrate の存在するディレクトリに移動します。
- ics2migrate の構文の構文を使用して ics2migrate を実行します。
- 移行後、ics.conf ファイルの caldb.berkeleydb.homedir.path パラメータが移行したデータベースを示していることを確認します。
- csdb check コマンドを実行します。また必要に応じて csdb rebuild コマンドを実行して、カレンダデータベースを再構築します。
ics2migrate の構文
Calendar Server 2.x のデータベースと LDAP ユーザー基本設定の両方を移行する場合
Calendar Server 2.x データベースだけを移行する場合
LDAP ユーザー基本設定だけを移行する場合
表 3-3 は、ics2migrate オプションとその説明の一覧です。
移行結果のチェック
移行処理が終了したら、その結果をチェックします。
移行例
カレンダデータベースと 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
非出力モードでの移行
上記の例と同じ移行を非出力モードで行います。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 情報とカレンダデータベース情報の両方を指定ディレクトリに移行します。各ユーザーのデフォルトカレンダに対してだけスケジュール設定アクセス権を付与し、サーバー上の全カレンダに対する空き時間/予定あり設定アクセス権を付与せず、統計情報をログファイルに生成することもありません。
ics2migrate -s def -f none 2x_db 50_db
ncs4migrate ユーティリティこの節では、ncs4migrate 移行ユーティリティを使用して Netscape Calendar Server 4.x カレンダデータを Sun ONE Calendar Server へ移行する方法について説明します。
Netscape Calendar Server 4.x カレンダは、開発元が Corporate Software & Technologies Int. Inc. であることから、CS&T カレンダとも呼ばれています。
ncs4migrate ユーティリティのコピーが必要な場合は、Sun テクニカルサポート担当者またはお客様窓口まで連絡してください。ncs4migrate を取得したら、それを cal_svr_base/opt/SUNWics5/cal/sbin ディレクトリにコピーします。
この節では、次の項目について説明します。
移行要件
移行するには、次のハードウェアとソフトウェアが必要です。
ソースマシンとターゲットマシンは、別々のサーバーであっても同一のサーバーであってもかまいません。サポート対象のプラットフォームについては、『Sun ONE Calendar Server リリースノート』を参照してください。
移行対象
次の表で、ncs4migrate が Netscape Calendar Server データを Calendar Server 6.0 に移行する方法を示します。
移行手順
Calendar Server 5.0 データベースのバックアップ
移行処理をはじめる前に、以下の手順を行ってカレンダデータベースの整合性を確保することをお勧めします。
- csbackup、Sun StorEdge Enterprise BackupTM、Legato Networker などのユーティリティを使って、カレンダデータベースのバックアップを作成します。
詳細については、『Sun ONE Calendar Server 管理者ガイド』を参照してください。
- カレンダデータベースに対して csdb ユーティリティの check コマンドを実行し、データベースが壊れていないかどうかをチェックします。check コマンドによって破損箇所が検出された場合は、csdb ユーティリティの rebuild コマンドを実行してデータベースを再構築します。
csdb および csbackup ユーティリティについては、『Sun ONE Calendar Server 管理者ガイド』を参照してください。
移行準備
ncs4migrate ユーティリティを実行する前に、ターゲットマシン上で以下の手順を実行します。
- スーパーユーザー (root) としてログインするか、システムに対する管理権限を持つユーザーとしてログインします。
- cal_svr_base/opt/SUNWics5/cal/sbin ディレクトリに移動します。
- ncs4dirpaths.dat というテキストファイルを作成し、Netscape Calendar Server 4.0 データベースを指す完全修飾ディレクトリパスを指定します。たとえば、次のように入力します。
/apps/ncs/calendar/unison/db/nodes/N0/perm
Netscape Calendar Server 4.0 データベースが入っているディレクトリを検出するには、unison.dbd ファイルを検索します。
必要に応じ、ncs4migrate がノードにアクセスするために必要な条件を満たしてノードにアクセスし、Netscape Calendar Server 4.0 データベースが入っているディレクトリを読み込みます。
複数のノード上のデータのための ncs4dirpaths.dat ファイルを作成する方法については、「複数のノードからのデータの移行」を参照してください。
- 選択したユーザーだけを移行する場合には、同じ cal_svr_base/opt/SUNWics5/cal/sbin ディレクトリ内に ncs4userfilter.dat というユーザーフィルタファイルを作成します。ncs4userfilter.dat は、移行対象のユーザーを指定するテキストファイルです。次のいずれかの形式で、1 行につき 1 名のユーザーを指定します。
- LDAP サーバーが稼動していることを確認してください。
- 移行処理中にカレンダデータベースが更新されないようにするため、iPlanet Calendar Server を停止してください。ただし、Netscape Calendar Server は、稼動中でも停止中でもかまいません。
以上で、Netscape Calendar Server 4.0 データの移行準備が完了しました。
データの移行
ターゲットマシン上で、次の手順を行います。
- スーパーユーザー (root) として、またはシステムに対する管理権限を持つユーザーとしてログインし、必要に応じて cal_svr_base/opt/SUNWics5/cal/sbin ディレクトリに移動します。
- コマンド行に ncs4migrate と入力します。
ncs4migrate ユーティリティにより、表 3-5 に示されたオプションとともに「ようこそ」メニューが表示されます。
注: ncs4migrate は、(E)xport および (I)mport オプションを表示しますが、これらのオプションはサポートされていないので使用しないでください。
- ncs4migrate メニューで S オプションを指定すると、全ユーザーが移行されます。ユーザーフィルタファイル (ncs4userfilter.dat) に指定されているユーザーだけを移行する場合には、O オプションを指定します。
- 移行ログファイルを監視して移行ステータスをチェックします。詳細については、「移行ログファイルのチェック」を参照してください。
- 移行処理が終了したら、移行したカレンダデータベースを「移行データのチェック」のとおりにチェックします。
複数のノードからのデータの移行
Netscape Calendar Server 4.0 のデータを複数のノードから移行するには、ターゲットマシン上で次の手順を行います。
- スーパーユーザー (root) として、またはシステムに対する管理権限を持つユーザーとしてログインし、各ノードの Netscape Calendar Server 4.0 データベースディレクトリを ncs4migrate の実行場所であるマシンにコピーします。Netscape Calendar Server 4.0 の各ディレクトリには unison.dbd ファイルが入っています。
Netscape Calendar Server 4.0 データを各ノードから直接移行することも可能ですが、そのためには、他のノード上の Netscape Calendar Server 4.0 データに ncs4migrate がアクセスするための要件を、まず最初に満たす必要があります。
- cal_svr_base/opt/SUNWics5/cal/sbin ディレクトリに移動します。
- 全ノードからのデータについて、ディレクトリパス名を ncs4dirpaths.dat ファイルに指定します。たとえば、次の ncs4dirpaths.dat ファイルには、3 つのノードのディレクトリパスが入っています。
/apps/ncs/calendar/unison/db/nodes/N0/perm
/apps/ncs/calendar/unison/db/nodes/N1/perm
/apps/ncs/calendar/unison/db/nodes/N2/perm- 移行ユーティリティを実行するには、コマンド行に ncs4migrate と入力します。
- ncs4migrate メニューで S オプションを指定すると、全ユーザーが移行されます。ユーザーフィルタファイル (ncs4userfilter.dat) に指定されているユーザーだけを移行する場合には、O オプションを指定します。
- 移行ログファイルを監視して移行ステータスをチェックします。詳細については、「移行ログファイルのチェック」を参照してください。
- 移行処理が終了したら、移行したカレンダデータベースを「移行データのチェック」のとおりにチェックします。
移行ログファイルのチェック
ncs4migrate ユーティリティは、cal_svr_base/opt/SUNWics5/cal/sbin ディレクトリにある次の名前を使用してログファイルを生成します。
ncs4migrate_yyyymmdd-hhmmss.log
yyyymmdd-hhmmss は、移行開始時刻を示すタイムスタンプです。
ncs4migrate ユーティリティの実行に時間がかかる場合は、ログファイルのサイズを確認してください。ファイルのサイズが増え続けていれば、ユーティリティはまだ実行中です。
移行データのチェック
移行処理が終了したら、ターゲットマシン上で次の手順を行います。
- csdb ユーティリティの check コマンドをカレンダデータベースに対して実行し、データベースが壊れていないかをチェックします。check コマンドによって破損箇所が検出された場合は、csdb ユーティリティの rebuild コマンドを実行してデータベースを再構築します。
csdb ユーティリティの check コマンドと rebuild コマンドの詳細については、マニュアル Ｗeb サイトの『Sun ONE Calendar Server 管理者ガイド』を参照してください。
- 必要であれば、Calendar Server を再起動します。
Calendar Express を使用すれば、移行したカレンダデータベースにアクセスできます。
csrename ユーティリティcsrename ユーティリティは、カレンダユーザーの名前を次のように変更します。
csrename ユーティリティは、次のディレクトリに格納されています。
cal_svr_base/opt/SUNWics5/cal/sbin
csrename を実行する前に、次の操作を行います。
csrename を実行するには、icsuser (または設定中に指定した Calendar Server 実行時ユーザー ID) としてログインする必要があります。csrename をスーパーユーザー (root) として実行する場合は、新しいデータベースファイルのアクセス権を設定し直さなければならないことがあります。LDAP ディレクトリサーバー属性を変更するには、そのディレクトリに対して管理権限が必要です。
フロントエンド / バックエンドサーバー設定がある場合は、各バックエンドサーバーで csrename を実行する必要があります。
csrename の構文
csrename を実行するには次の構文を使用します。
-t DestinationDB は、変換されたユーザー名で新しいデータベースが生成される生成先ディレクトリを指定します。デフォルトは、MigratedDB です。
csrename の実行後、ics.conf ファイルの caldb.berkeleydb.homedir.path パラメータが生成先データベースを示している必要があります。caldb.berkeleydb.homedir.path が生成先データベースディレクトリを指すように設定し直すか、パラメータが示すディレクトリに生成先データベースファイルを移動してください。
-c ConfigFile は Calendar Server の設定ファイルを指定する入力パラメータです。デフォルトは、ics.conf ファイルです。
csrename では設定ファイルの caldb.berkeleydb.homedir.path パラメータを使用して、入力カレンダデータベースの場所を特定します。カレンダデータベースのデフォルトの場所は cal_svr_base/var/opt/SUNWics5/csdb です。
-e ErrorFile は、csrename が解決できないすべてのエラーまたはデータベースエントリを書き込むファイルです。デフォルトは、MigrateError です。
-m MappingFile は入力マッピングファイルを指定します。デフォルトは、MigrateMapping です。
入力マッピングファイルは、既存のユーザー ID を新しいユーザー ID にマップするテキストファイルです。
csrename の実行前にマッピングファイルを作成する必要があります。新旧の値の間に空白文字を入れ、1 行に 1 エントリずつ指定してください。たとえば、次のように入力します。
tchang tc897675
jsmith js963123
...
bkamdar bk548769DB|LDAP は更新されるデータベースを指定します。
csrename の例
