Sun ONE Calendar Server インストールガイド: 第 4 章 Calendar Server データの移行

前へ目次索引次へ

Sun ONE Calendar Server インストールガイド

第 4 章 Calendar Server データの移行

この章では、次の Sun™ ONE Calendar Server 5.1.1 移行ユーティリティについて説明します。

ics2migrate 移行ユーティリティ - Calendar Server 2.x からデータを移行する。

ncs4migrate 移行ユーティリティ - Netscape Calendar Server 4.x からデータを移行する。

csmig 移行ユーティリティ -カレンダーデータベースを移行して LDAP Calendar Lookup Database (CLD) プラグインをサポートする。

ics2migrate 移行ユーティリティ

ics2migrate 移行ユーティリティは、Calendar Server 2.x のカレンダーデータと LDAP ユーザ基本設定の両方を Calendar Server 5.1 に移行できます。
この節では、次の項目について説明します。

移行要件

移行対象

移行プロセス

1. 移行準備

2. データの移行

3. 移行結果のチェック

移行例
Calendar Server 2.x から 5.x への移行は、一方向の移行です。つまり、データをバージョン 2.x からバージョン 5.1 に移行することはできますが、バージョン 5.x からバージョン 2.x に移行することはできません。

移行要件
Calendar Server 2.x から 5.x に移行するには、次のハードウェアとソフトウェアが必要です。

ソースマシンには、移行対象の Calendar Server 2.x データが入っています。

ターゲットマシンは、移行データを作成する場所です。このマシンには、Calendar Server 5.0 パッチ 4 (またはそれ以降) がインストールされている必要があります。

ics2migrate.exe は、server-root\cal\bin ディレクトリに入っています。

ソースマシンと移行先マシンは、別々のサーバであっても同一のサーバであってもかまいません。次のプラットフォームがサポートされています。

Solaris 2.6 (5.6) またはこれ以降のオペレーティング環境

Windows NT 4.0 サービスパック 6a

移行対象
次の表に、Calendar Server 2.x のデータを一覧表示して ics2migrate がデータを Calendar Server 5.x に移行する方法を説明します。

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

Calendar Server 2.x のデータ

Calendar Server 5.x の移行結果

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

Calendar Server calprops データベースを更新します。

イベント

Calendar Server events データベースを更新します。

予定

Calendar Server todos データベースを更新します。

アラーム

イベントと予定を書き込んで alarms データベースを更新します。

次の表に、Calendar Server 2.x LDAP 属性を一覧表示して ics2migrate が属性を Calendar Server 5.x に移行する方法を説明します。

表 4-2    LDAP 属性の移行

Calendar Server 2.x LDAP の属性

Calendar Server 5.x LDAP の属性

nswcalUser *

icsCalendarUser *

nswcalCalID

icsCalendar

nswcalExtendedUserPrefs

icsExtendedUserPrefs

ceCalList **

icsSubscribed

ceAgendaList **

icsSet

ceDefaultAgenda **

icsDefaultSet

ceDefaultTZID **

icsTimeZone

ceFirstDayWeek **

icsFirstDay

* オブジェクトクラス
** もとは nswcalExtendedUserPrefs の一部



移行プロセス

注意
移行処理を始める前に、Calendar Server 2.x と 5.x の両方のカレンダーデータベースのバックアップをとります。

移行準備
次の手順に従ってデータを移行する準備をします。

Calendar Server のインストール先であるターゲットマシンに、システムに対する管理権限を持つユーザとしてログインします。

Solaris マシンの場合は、root としてログインする (または root ユーザになる) か、またはインストール時に指定した Calendar Server を実行しているユーザおよびグループとして (icsuser および icsgroup など) ログインします。

Windows NT マシンの場合は、完全な管理権限を持つ管理者としてログインします。

Calendar Server 2.x の caldb.conf ファイルを検出します。このファイルのデフォルトディレクトリは、プラットフォームによって異なります。

Solaris マシン： /var/opt/SUNWicsrv/csdb

Windows NT マシン： server-root\var\csdb

caldb.conf ファイルの 1 行目を次のように変更します

元の値：caldb.version "1.0.0 [BerkeleyDB]"

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

データの整合性を保つため、Calendar Server 2.x と 5.x の両方のサービスをすべて停止します。詳細については、マニュアル Web サイトにある『Sun ONE Calendar Server 管理者ガイド』を参照してください。

データの移行
次の手順に従ってデータを移行します。

ics2migrate.exe が格納されている server-root\cal\bin ディレクトリに移動します。

次の構文を使用して 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]

Quiet モードで実行します。移行が成功した場合、ics2migrate はコンソールに情報を表示しません。移行が失敗した場合、ics2migrate はエラーだけを表示します。
デフォルトは、Verbose モードです。

[-m db|ldap]

db - カレンダーデータベースだけを移行します。
ldap - LDAP ユーザ基本設定だけを移行します。
デフォルトでは、カレンダーデータベースと LDAP ユーザ基本設定の両方が移行されます。

[-s def|none]

def - ユーザのデフォルトカレンダーに対してだけスケジュール設定アクセス権を付与します。
none - すべてのユーザカレンダーに対し、スケジュール設定アクセス権を付与しません。
デフォルトでは、全カレンダーに対するスケジュール設定アクセス権が付与されます。

[-f def|none]

def - ユーザのデフォルトカレンダーに対してだけ空き時間/予定あり設定アクセス権を付与します。
none - すべてのユーザカレンダーの空き時間/予定あり設定アクセス権を拒否します。
デフォルトでは、全カレンダーに対する空き時間/予定あり設定アクセス権が付与されます。

[-l min|max]

min - データ移行に関する最小限の統計情報を記録します。最小限の統計情報とは、各カレンダーのカレンダー ID、一次所有者、イベントおよび予定の数です
max - データ移行に関する最大限の統計情報を記録します。最大限の統計情報とは、最小限の統計情報に、各イベントと予定の出席者数、各イベントと予定のアラーム数が加わったものです
ics2migrate は、server-root\cal\bin ディレクトリにある ics2migrate.log に統計情報を記録します。
デフォルトの場合、ics2migrate は移行統計情報をコンソール上に表示し、ログファイルは生成しません。

source

Calendar Server 2.x データベースファイルが格納されているディレクトリ。
-m db オプションが指定されている場合、または -m オプションが省略されている場合には、source が必要です。

target

Calendar Server 5.1 データベースファイルが格納されているディレクトリ。
-m db オプションが指定されている場合、または -m オプションが省略されている場合には、target が必要です。

移行結果のチェック
移行処理が終了したら、その結果をチェックします。

server-root\cal\bin ディレクトリにある ics2migrate.log ファイルに次のメッセージがあるかどうかをチェックします(メッセージは、どのような移行処理を選択したかによって異なります)。

Database migration successfully completed
LDAP user preference migration successfully completed

データベースが壊れている場合には、csdb ユーティリティの check コマンドを実行してください。

check コマンドは、カレンダーデータベースが壊れていないかをスキャンして調べます。回復不能な不整合を check コマンドが見つけた場合には、その状況がスキャン結果にレポートされます。ここで、必要に応じて csdb ユーティリティの rebuild コマンドを実行することにより、カレンダーデータベース (caldb)を再構築できます。

csdb ユーティリティの check コマンドと rebuild コマンドの詳細については、マニュアル Web サイトにある『Sun ONE Calendar Server 管理者ガイド』を参照してください。

移行例



カレンダーデータベースと LDAP ユーザ情報の両方の移行
LDAP ユーザ情報と Calendar Server 2.x データベースの両方を移行します。Calendar Server 2.x のデータベースは /var/opt/SUNWicsrv/2x_db ディレクトリに、5.1 のデータベースは /var/opt/SUNWics5/50_db ディレクトリに格納されます。
すべてのカレンダーに対する空き時間および予定あり設定アクセス権のスケジュール設定を付与し、server-root\cal\bin ディレクトリにある ics2migrate.log というログファイルに最小限の統計情報を記録します。
ics2migrate /var/opt/SUNWicsrv/2x_db /var/opt/SUNWics5/50_db -l min

Quiet モードでの移行
上記の例と同じ移行を Quiet モードで行います。 ics2migrate は、移行統計情報をコンソール上に表示することもログファイルの生成もしません。
ics2migrate -q /var/opt/SUNWicsrv/2x_db /var/opt/SUNWics5/50_db

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

LDAP ユーザ情報だけの移行
Calendar Server 2.x LDAP ユーザ情報だけをバージョン 5.1 フォーマットに移行します。
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 ユーティリティのコピーが必要な場合は、サンのテクニカルサポート担当またはお客様窓口まで連絡してください。 ncs4migrate を取得したら、それを server-root\cal\bin ディレクトリにコピーします。
この節では、次の項目について説明します。

移行要件

移行対象

移行手順

1. Calendar Server 5.0 データベースのバックアップ

2. 移行準備

3. データの移行

複数のノードからのデータの移行

移行ログファイルのチェック

4. 移行データのチェック



移行要件
移行するには、次のハードウェアとソフトウェアが必要です。

ソースマシン - このマシン (1 台または複数台) には、Netscape Calendar Server 4.0 (またはそれ以上) の移行対象データが入っています。

ターゲットマシン－このマシンには、移行先である Calendar Server 5.0 データベースが入っています。Calendar Server 5.0 パッチ 4 (またはそれ以降) を稼動している必要があります。
ソースマシンとターゲットマシンは、別々のサーバであっても同一のサーバであってもかまいません。次のプラットフォームがサポートされています。

Solaris 2.6 (5.6) またはこれ以降のオペレーティング環境

Windows NT 4.0 サービスパック 6a

移行対象
次の表で、ncs4migrate が Netscape Calendar Server データを Calendar Server 5.0 に移行する方法を示します。

表 4 Netscape Calendar Server 4.0 データの移行

Netscape Calendar Server 4.0 のデータ項目

Calendar Server 5.0 の移行結果

会議、イベント、およびリソースとユーザに関するメモ

イベントとして移行

仕事

todo (仕事) として移行

アクセス (セキュリティ) 権限

移行期間中は無視。指名および指名権は移行されません。
ユーザカレンダーとリソースカレンダーの場合、ncs4migrate は、次のように ics.conf ファイル内のアクセスコントロール文字列を使用します。
ユーザカレンダーの場合、ncs4migrate は calstore.calendar.default.acl を使用して Calendar Server 5.0 におけるプライバシー設定を次のとおりに設定します。

カレンダー所有者：空き時間の確認、スケジュール、読み込み、削除、変更

その他のユーザの場合：空き時間の確認とスケジュール

リソースカレンダーの場合、ncs4migrate は resource.default.acl を使用して Calendar Server 5.0 におけるプライバシー設定を次のとおりに設定します。

リソース所有者：空き時間の確認、スケジュール、読み込み、削除、変更

その他のユーザの場合：空き時間の確認、スケジュール、読み込み

プライバシー設定とその変更方法については、Calendar Express のオンラインヘルプを参照してください。
注：移行を開始する前に、ics.conf ファイルに定義されている文字列が次のとおりであることを確認してください。
calstore.calendar.default.acl の正しい文字列は、次のとおりです。
@@o^a^r^g;@@o^c^wdeic^g;@^a^sf^g;@^c^^g
resource.default.acl の正しい文字列は、次のとおりです。
@@o^a^r^g;@@o^c^wdeic^g;@^a^rsf^g;@^c^^g

ファイルアタッチメント

移行処理中は無視されます。警告メッセージがログファイルに出力されます。

グループ

移行されない



移行手順



Calendar Server 5.0 データベースのバックアップ
移行処理をはじめる前に、以下の手順を行ってカレンダーデータベースの整合性を保つことをお勧めします。

csbackup ユーティリティ (または他のバックアップユーティリティ) を使用してカレンダーデータベースのバックアップを作成します。

csbackup の詳細な情報については、『Sun ONE Calendar Server 管理者ガイド』を参照してください。

csdb ユーティリティの check コマンドをカレンダーデータベースに対して実行し、データベースが壊れていないかどうかをチェックします。check コマンドによって破損箇所が検出された場合は、csdb ユーティリティの rebuild コマンドを実行してデータベースを再構築します。

csdb および csbackup ユーティリティのマニュアルについては、『Sun ONE Calendar Server 管理者ガイド』を参照してください。

移行準備
ncs4migrate ユーティリティを実行する前に、以下の手順をターゲットマシン上で行います。

root としてログインする (または root ユーザになる) か、システムに対する管理権限を持つユーザとしてログインします。

server-root\cal\bin ディレクトリに移動します。

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 データベースが入っているディレクトリを読み込みます。

注 $CAL_HOME などの変数はパス名の中で使用しないでください。変数は、移行処理時に解決されません。

複数のノード上のデータのための ncs4dirpaths.dat ファイルを作成する方法については、複数のノードからのデータの移行を参照してください。

選択したユーザだけを移行する場合には、同じ server-root\cal\bin ディレクトリ内に ncs4userfilter.dat というユーザフィルタファイルを作成します。ncs4userfilter.dat は、移行対象のユーザを指定するテキストファイルです。次のいずれかのフォーマットで、1 行につき 1 名のユーザを指定します。

Netscape Calendar Server カレンダーシステムのnode-number:user id (nscalxitemid 属性)

ユーザの UID 属性

次は、ncs4userfilter.dat ファイルのエントリ例です

caluser1
caluser2
10000:00256
10000:00257

1 つの ncs4userfilter.dat ファイルの中で両方のフォーマットを使用できます。

LDAP サーバが稼動していることを確認してください。

移行処理中にカレンダーデータベースが更新されないようにするため、iPlanet Calendar Server を停止してください。ただし、Netscape Calendar Server は、稼動中でも停止中でもかまいません。
以上で、Netscape Calendar Server 4.0 データの移行準備が完了しました。

データの移行
ターゲットマシン上で、次の手順を行います。

root として、またはシステムに対する管理権限を持つユーザとしてログインし、必要があれば server-root\cal\bin ディレクトリに移動します。

コマンドラインに ncs4migrate と入力します。

ncs4migrate ユーティリティが、表 5 に示されたオプションとともに「ようこそ」メニューを表示します。

注： ncs4migrate は、(E)xport および (I)mport オプションを表示しますが、これらのオプションはサポートされていないので使用しないでください。

表 5    ncs4migrate ユーティリティオプション

ncs4migrate オプション

説明

(E)xport

Netscape Calendar Server 4.0 を中間ファイルにエクスポートします。

(I)mport

中間ファイルからカレンダーデータベースにデータをインポートします。

(S)kip

中間ファイルをスキップします。Netscape Calendar Server 4.0 から Calendar Server 5.0 に一度に 1 レコードずつ移行します。

(L)ogging = ON|OFF

ロギングを設定します。ロギングファイル名は、
ncs4migrate_yyyymmdd-hhmmss.log です。デフォルトは、ONです。
デフォルトは、ON です。

(V)erbose = ON|OFF

Verbose ログを設定します。デフォルトは、OFF です。
ディスク容量を節約するため、OFF のままにしておくことをお勧めします。

(D)ebug = ON|OFF

デバッグログを設定します。デフォルトは、OFF です。

(Q)uiet = ON|OFF

画面出力の設定を行います。デフォルトは、OFF です。

(T)erminate = TRUE|FALSE

LDAP に含まれていないユーザが Netscape Calendar Server 4.0 データベース内に存在する場合には終了します。デフォルトは、FALSE です。

(O)nly = TRUE|FALSE

ユーザフィルタファイル ncs4userfilter.dat で指定されているユーザだけを移行します。デフォルトは、FALSE です。
O と M が TRUE である場合、ncs4migrate は所有者と出席者のどちらかとしてフィルタファイル中に参加者があるイベントを移行します。イベントは、そのすべての出席者のカレンダーに移行されます。

(M)igrate = TRUE|FALSE

ユーザフィルタファイルに指定されているユーザを移行します。デフォルトは、FALSE です。

(B)ypass = TRUE|FALSE

ユーザフィルタファイルに指定されているユーザの移行をバイパスします。デフォルトは、FALSE です。

(A)ny = TRUE|FALSE

どんな組み合わせの Netscape Calendar Server セキュリティアクセスレベルによっても、Calendar Server におけるアクセス権が許可されます。デフォルトは、TRUE です。FALSE の場合、3 つのアクセスレベルがすべて存在している必要があります。 (H)elp を参照してください。

(U)ser

ユーザフィルタファイル ncs4userfilter.dat を表示します。 O オプションは、フィルタリングを ON|OFF します。デフォルトは、OFF です。

(P)ath

Netscape Calendar Server 4.0 データベースのパスファイル。ファイル名は、ncs4dirpaths.dat です。

(H)elp

ヘルプ画面を表示します。

(E)xit

プログラムを終了します。

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 がアクセスするための要件を、まず最初に満たす必要があります。

server-root\cal\bin ディレクトリに移動します。

全ノードからのデータについて、ディレクトリパス名を 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 ユーティリティは、server-root\cal\bin ディレクトリにある次の名前を使用してログファイルを生成します。
ncs4migrate_yyyymmdd-hhmmss.log
yyyymmdd-hhmmss は、移行開始時刻を示すタイムスタンプです。
ncs4migrate ユーティリティの実行に時間がかかる場合は、ログファイルのサイズを確認してください。ファイルのサイズが増え続けていれば、ユーティリティはまだ実行中です。

注ログファイルが大きくなりすぎないようにするには、ncs4migrate の verbose (V) オプションを使用してください。

移行データのチェック
移行処理が終了したら、ターゲットマシン上で次の手順を行います。

csdb ユーティリティの check コマンドをカレンダーデータベースに対して実行し、データベースが壊れていないかをチェックします。check コマンドによって破損箇所が検出された場合は、csdb ユーティリティの rebuild コマンドを実行してデータベースを再構築します。

csdb ユーティリティの check コマンドと rebuild コマンドの詳細については、マニュアル Web サイトにある『Sun ONE Calendar Server 管理者ガイド』を参照してください。

必要であれば、Calendar Server を再起動します。

Calendar Express を使用すれば、移行したカレンダーデータベースにアクセスできます。

csmig 移行ユーティリティ

csmig ユーティリティは、Calendar Server 5.1.1 が LDAP Calendar Lookup Database (CLD) プラグインをサポートする宛先ターゲットデータベースに開放する前に作成されたカレンダーデータベースを移行します。移行したデータベースのカレンダーは、このプラグインを使用してアクセスできます。(新しい Calendar Server 5.1.1 配備では、この移行は必要ありません。)
LDAP CLD プラグインはカレンダーを多数のバックエンドサーバに配布することによってカレンダーデータベースの水平方向のスケーラビリティを提供します。LDAP CLD プラグインについての詳細は、『Sun ONE Calendar Server 管理者ガイド』を参照してください。
このドキュメントでは、次のトピックについて説明します。

csmig 機能

csmig 要件

csmig 構文

csmig 移行手順

csmig ヒントおよびトラブルシューティング



csmig 機能
csmig 移行ユーティリティには次の機能があります。

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

csmig は、宛先ターゲットデータベースにだけ書き込み、既存のカレンダーデータベースには書き込みません。

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

csmig は、カレンダーデータベースの各カレンダーに所有者を割り当て、必要に応じて各カレンダー ID (calid) を所有者にマッピングします。すべてのデフォルトの calids は現状のまま維持され、変更は行われません。ほかのカレンダーは次のように割り当てられます。

有効な所有者を持たないユーザカレンダーは、-c オプションによって csmig に移行されたユーザに所有されます。たとえば、jsmith が所有者を持たない場合、orphan が -c オプションとして指定されると、orphan:jsmith に変換されます。

所有者を持たないリソースカレンダーは、-r オプションによって csmig に移行されたリソースユーザに所有されます。

リソースカレンダーの名前にコロンが含まれている場合は、コロンは下線に変換されます。

たとえば、football という名前のカレンダーで、所有者が bkamdar の場合は、bkamdar:football に変換されます。カレンダーが tchang:soccer で、所有者が bkamdar の場合は、bkamdar:tchang_soccer に変換されます。 (calid にはコロンは 1 つだけです。) auditorium:room1 という名前のリソースカレンダーは、auditorium_room1 に変換されます。

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

カレンダーデータベースは破損がないようにしてください。 csdb check コマンドを使用してカレンダーデータベースを検査し、必要に応じて csdb rebuild コマンドを実行してデータベースを再構築します。これらのコマンドの詳細については、『Sun ONE Calendar Server 管理者ガイド』を参照してください。

新しい宛先ターゲットデータベース用に十分なディスク容量が必要です。該当する場合には、バックアップデータベースの容量も必要です。

csmig を実行するには、root としてログインする (または root ユーザになる) か、Calendar Server がインストールされたシステムに対する管理権限をもつユーザ (icsuser のような) としてログインします。

ユーザ設定の変更を格納する LDAP ディレクトリサーバのカレンダーユーザの属性を管理する優先権も保有する必要があります。

Calendar Server を停止する必要があります。

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 スキーマのエントリを更新するためにマッピングファイルを指定します。マッピングファイルは、LDAP スキーマに推奨修正リストを提供しますが、スキーマを実際の修正は実行しません。
-c calendarOwner によって、所有者を持たないユーザに所有者を指定します。
-r resourceOwner によって、所有者を持たないリソースカレンダーに所有者を指定します。

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

LDAP ディレクトリサーバの設定－索引を追加すると、LDAP データ上の移行およびカレンダー検索のパフォーマンスが向上します。

テストドライランの実行－ドライランは、移行期間中に csmig が何を行うかを報告しますが、実データは移行しません。ドライランを行ったあとで、エラーを訂正したり、未解決カレンダーを処理する計画を決定できます。

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

LDAP ディレクトリサーバの設定
パフォーマンスを向上させるには、次の 2 つの新しい索引を slapd.ldbm.conf ファイルに追加します。

index icscalendar pres,eq,sub － icsCalendar 属性を検索するために移行プロセスで使用されます。

index icscalendarowned pres,eq,sub －移行プロセスには必要ではないが、LDAP CLD プラグインが使用可能な場合に LDAP データ (サブスクライブ操作用) 上でカレンダー検索を実行するときに使用されます。
slapd.ldbm.conf ファイルで索引を作成することについての詳細は、ディレクトリサーバに付属のマニュアルを参照してください。

テストドライランの実行
ステージングサーバ上で実行したテストドライランは、何が移行されるのかを報告しますが、実働データベースを実際に移行することはありません。ドライランによって実働データベースを移行する計画を決定することができます。たとえば、所有者を持たない「 orphan 」カレンダーを処理する方法を決定できます。
csmig を使用してテストドライランを実行するには、次の手順に従います。

root としてログインする (または root ユーザになる) か、Calendar Server がインストールされたシステムに対する管理者権限をもつユーザ (icsuser のような) としてログインします。

ステージングサーバ上で、(必要に応じて) Calendar Server 5.1.1 をインストールします。

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

LDAP サーバをインストールして実働 LDAP 環境を模倣します。 slapd.ldbm.conf ファイルの新しい索引とともに、このサーバ上に LDAP データベースのスナップショットをインストールします。

server-root/cal/bin/ ディレクトリに変更します。

所有者を持たないユーザカレンダーに多目的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 に所有者のないリソースカレンダーを割り当てます。

出力、マッピング、およびエラーファイルを検査します。検出したすべての LDAP 問題またはエラーを解決します。実際の移行の前に、未解決カレンダーを処理する方法を決定します。次のような次にいくつかのオプションがあります。

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

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

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

実働カレンダーデータベースを実際に実移行する前に、ステージングサーバにカレンダーデータベースを移行することを推奨します。この手順によって、実働データベースを移行する前にデータがどのように移行されるのかを正確に確認し、問題があれば訂正することができます。

たとえば、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 ディレクトリにコピーします。あるいは、このパラメータを編集して移行したデータベースの新しい位置を示すようにします。そのあと、下記のチェックを実行します。

新しいカレンダーデータベースで csdb check を実行する。移行したデータベースのイベントおよびtodoの数は、移行前の合計と一致する必要があります。

icsCalendarOwned エントリの検索およびエントリの数がカレンダーの移行前の数と一致することを確認する。

Calendar Express にログインして移行したデータベースのカレンダーのいくつかを検証する。

テスト移行が成功した場合は、実働データベースを移行する準備ができています。

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

root としてログインする (または root ユーザになる) か、Calendar Server がインストールされたシステムに対する管理権限をもつユーザ (icsuser のような) としてログインする。

server-root/cal/bin/ ディレクトリに変更する。

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

次のデータをバックアップする。

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

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

ics.conf ファイル。この手順は実際は必要ありませんが、元の構成に戻す必要がある場合には利用できます。

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 キャッシュディレクトリの位置を指定します。デフォルトは、server-root/var/csdb/cld_cache です。

このディレクトリが正確であることを確認するか、あるいは CLD キャッシュを別の位置にする場合は、このパラメータを修正します。

LDAP CLD プラグインに対する構成パラメータの設定についての詳細は、『Sun ONE Calendar Server 管理者ガイド』を参照してください。

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

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 ドライランカレンダーの所有者をカレンダーの所有者にしない場合

LDAP後のカレンダー検索が正常に動作しない場合

csmig ドライランが重複するカレンダー名を表示する場合

複数の orphan カレンダーを個別に所有者に割り当てる方法

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

 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 つの異なる検索を手動で実行して出力を比較します。

(&(objectclass=icscalendaruser)(icscalendarowned=*substr* )) を使用して ldapsearch

フィルタでの LDAP 検索(icscalendarowned=*substr*)
サーバは、icsCalendaruser オブジェクトクラスを含むフィルタを使用するため、LDAP サーバはスキーマ検査が使用不可の状態で配置されいくつかのカレンダーエントリが icsCalendaruser オブジェクトクラスを持たないでプロビジョンされた可能性があります。

csmig ドライランが重複するカレンダー名を表示する場合
csmig ドライランマッピングファイルおよび出力ファイルが、重複するカレンダー名があることを示します。たとえば、もとのデータベースでは、jsmith は次のカレンダーを所有します。

basketball と 5 つのイベント

jsmith:basketball と 10 のイベント
ドライランによって、移行期間中は 2 つのカレンダーが統合されて結果カレンダーは次のように示されます。

jsmith:basketball および所有者 jsmith と 15 の合計イベント
出力ファイルには次の警告メッセージが含まれます。
Error modifying calendar properties, error=2

解決策
2 つのカレンダーを統合しない場合は、移行の前に、basketball の所有者を jsmith 以外のほかのユーザに変更します。これにより、2 つの別々のカレンダーのデータの整合性が保たれます。

複数の orphan カレンダーを個別に所有者に割り当てる方法
デフォルトで csmig は、すべての orphan カレンダーを単一所有者に割り当てますが、いくつかの orphan カレンダーについては個別の所有者に割り当てる予定です。

解決策
csmig はコマンドラインでマッピングファイルを受け入れません。ただし、移行の前に、もとのデータベースで親のないカレンダーに所有者を割り当てることができます。すべての親のないカレンダーのドライランマッピングファイルを検査します。その後、移行の前に cscal ユーティリティを使用して親のないカレンダーに所有者を割り当てます。 dryrun モードで再び csmig を実行して新しい所有者を検証します。

カレンダーユーザをほかのバックエンドサーバに移動する方法
ユーザをバックエンドサーバ間で移動する方法は？

解決策
カレンダーユーザを移動するには、もとのサーバの各ユーザカレンダーをエクスポートしてから 2 番目のサーバのカレンダーをインポートします。カレンダーを移動させたら、もとのサーバにあるカレンダーを削除できます。ユーザの移動の手順の詳細については、『Sun ONE Calendar Server 管理者ガイド』を参照してください。

Calendar Server 2.x のデータ	Calendar Server 5.x の移行結果
カレンダープロパティ(calprops)	Calendar Server calprops データベースを更新します。
イベント	Calendar Server events データベースを更新します。
予定	Calendar Server todos データベースを更新します。
アラーム	イベントと予定を書き込んで alarms データベースを更新します。

Calendar Server 2.x LDAP の属性	Calendar Server 5.x LDAP の属性
nswcalUser *	icsCalendarUser *
nswcalCalID	icsCalendar
nswcalExtendedUserPrefs	icsExtendedUserPrefs
ceCalList **	icsSubscribed
ceAgendaList **	icsSet
ceDefaultAgenda **	icsDefaultSet
ceDefaultTZID **	icsTimeZone
ceFirstDayWeek **	icsFirstDay
* オブジェクトクラス ** もとは nswcalExtendedUserPrefs の一部

ics2migrate オプション	説明
[-q]	Quiet モードで実行します。移行が成功した場合、ics2migrate はコンソールに情報を表示しません。移行が失敗した場合、ics2migrate はエラーだけを表示します。デフォルトは、Verbose モードです。
[-m db\|ldap]	db - カレンダーデータベースだけを移行します。 ldap - LDAP ユーザ基本設定だけを移行します。デフォルトでは、カレンダーデータベースと LDAP ユーザ基本設定の両方が移行されます。
[-s def\|none]	def - ユーザのデフォルトカレンダーに対してだけスケジュール設定アクセス権を付与します。 none - すべてのユーザカレンダーに対し、スケジュール設定アクセス権を付与しません。デフォルトでは、全カレンダーに対するスケジュール設定アクセス権が付与されます。
[-f def\|none]	def - ユーザのデフォルトカレンダーに対してだけ空き時間/予定あり設定アクセス権を付与します。 none - すべてのユーザカレンダーの空き時間/予定あり設定アクセス権を拒否します。デフォルトでは、全カレンダーに対する空き時間/予定あり設定アクセス権が付与されます。
[-l min\|max]	min - データ移行に関する最小限の統計情報を記録します。最小限の統計情報とは、各カレンダーのカレンダー ID、一次所有者、イベントおよび予定の数です max - データ移行に関する最大限の統計情報を記録します。最大限の統計情報とは、最小限の統計情報に、各イベントと予定の出席者数、各イベントと予定のアラーム数が加わったものです ics2migrate は、server-root\cal\bin ディレクトリにある ics2migrate.log に統計情報を記録します。デフォルトの場合、ics2migrate は移行統計情報をコンソール上に表示し、ログファイルは生成しません。
source	Calendar Server 2.x データベースファイルが格納されているディレクトリ。 -m db オプションが指定されている場合、または -m オプションが省略されている場合には、source が必要です。
target	Calendar Server 5.1 データベースファイルが格納されているディレクトリ。 -m db オプションが指定されている場合、または -m オプションが省略されている場合には、target が必要です。

Netscape Calendar Server 4.0 のデータ項目	Calendar Server 5.0 の移行結果
会議、イベント、およびリソースとユーザに関するメモ	イベントとして移行
仕事	todo (仕事) として移行
アクセス (セキュリティ) 権限	移行期間中は無視。指名および指名権は移行されません。ユーザカレンダーとリソースカレンダーの場合、ncs4migrate は、次のように ics.conf ファイル内のアクセスコントロール文字列を使用します。ユーザカレンダーの場合、ncs4migrate は calstore.calendar.default.acl を使用して Calendar Server 5.0 におけるプライバシー設定を次のとおりに設定します。カレンダー所有者：空き時間の確認、スケジュール、読み込み、削除、変更その他のユーザの場合：空き時間の確認とスケジュールリソースカレンダーの場合、ncs4migrate は resource.default.acl を使用して Calendar Server 5.0 におけるプライバシー設定を次のとおりに設定します。リソース所有者：空き時間の確認、スケジュール、読み込み、削除、変更その他のユーザの場合：空き時間の確認、スケジュール、読み込みプライバシー設定とその変更方法については、Calendar Express のオンラインヘルプを参照してください。注：移行を開始する前に、ics.conf ファイルに定義されている文字列が次のとおりであることを確認してください。 calstore.calendar.default.acl の正しい文字列は、次のとおりです。 @@o^a^r^g;@@o^c^wdeic^g;@^a^sf^g;@^c^^g resource.default.acl の正しい文字列は、次のとおりです。 @@o^a^r^g;@@o^c^wdeic^g;@^a^rsf^g;@^c^^g
ファイルアタッチメント	移行処理中は無視されます。警告メッセージがログファイルに出力されます。
グループ	移行されない

ncs4migrate オプション	説明
(E)xport	Netscape Calendar Server 4.0 を中間ファイルにエクスポートします。
(I)mport	中間ファイルからカレンダーデータベースにデータをインポートします。
(S)kip	中間ファイルをスキップします。Netscape Calendar Server 4.0 から Calendar Server 5.0 に一度に 1 レコードずつ移行します。
(L)ogging = ON\|OFF	ロギングを設定します。ロギングファイル名は、 ncs4migrate_yyyymmdd-hhmmss.log です。デフォルトは、ONです。デフォルトは、ON です。
(V)erbose = ON\|OFF	Verbose ログを設定します。デフォルトは、OFF です。ディスク容量を節約するため、OFF のままにしておくことをお勧めします。
(D)ebug = ON\|OFF	デバッグログを設定します。デフォルトは、OFF です。
(Q)uiet = ON\|OFF	画面出力の設定を行います。デフォルトは、OFF です。
(T)erminate = TRUE\|FALSE	LDAP に含まれていないユーザが Netscape Calendar Server 4.0 データベース内に存在する場合には終了します。デフォルトは、FALSE です。
(O)nly = TRUE\|FALSE	ユーザフィルタファイル ncs4userfilter.dat で指定されているユーザだけを移行します。デフォルトは、FALSE です。 O と M が TRUE である場合、ncs4migrate は所有者と出席者のどちらかとしてフィルタファイル中に参加者があるイベントを移行します。イベントは、そのすべての出席者のカレンダーに移行されます。
(M)igrate = TRUE\|FALSE	ユーザフィルタファイルに指定されているユーザを移行します。デフォルトは、FALSE です。
(B)ypass = TRUE\|FALSE	ユーザフィルタファイルに指定されているユーザの移行をバイパスします。デフォルトは、FALSE です。
(A)ny = TRUE\|FALSE	どんな組み合わせの Netscape Calendar Server セキュリティアクセスレベルによっても、Calendar Server におけるアクセス権が許可されます。デフォルトは、TRUE です。FALSE の場合、3 つのアクセスレベルがすべて存在している必要があります。 (H)elp を参照してください。
(U)ser	ユーザフィルタファイル ncs4userfilter.dat を表示します。 O オプションは、フィルタリングを ON\|OFF します。デフォルトは、OFF です。
(P)ath	Netscape Calendar Server 4.0 データベースのパスファイル。ファイル名は、ncs4dirpaths.dat です。
(H)elp	ヘルプ画面を表示します。
(E)xit	プログラムを終了します。

前へ目次索引次へ
Copyright 2002 Sun Microsystems, Inc. All rights reserved.

最終更新日 2002 年 8 月 30 日