ここでは、Calendar Server 6.3 ソフトウェアをインストールし、設定したあとにカレンダデータベースと LDAP データベースを移行するためのさまざまなデータベース移行ユーティリティーについて説明します。
この章の内容は次のとおりです。
Calendar Server 6.0、6.1、または 6.2 バージョンから移行する場合は、「3.3 csmigrate ユーティリティー」 と呼ばれるユーティリティーを実行します。以前の配備で、定期的な予定および作業に対して cs5migrate が実行済みでない場合は、csmigrate を実行する前に既存のカレンダデータベースで cs5migrate を実行する必要があります。
Calendar Server 5.1.1 から移行する場合は、「3.2 適切な Calendar Server ユーティリティーの選択」で説明するように、移行ユーティリティーを使用してカレンダデータベースと LDAP データベースを移行します。
5.1.1 より古いバージョンの Calendar Server がインストールされている場合は、データの移行についてはテクニカルサポートにお問い合わせください。
ここでは、それぞれの移行ユーティリティーについて説明します。過去にインストールされた Calendar Server のバージョンに応じ、必要となる移行ユーティリティーのみを使用します。これらのユーティリティーは sbin ディレクトリにあります。
データベースに対して過去に cs5migrate ユーティリティーを実行したことがあるが、そのときに -r オプションを指定しなかった場合は、ほかのユーティリティーを実行する前に -r オプションを指定してこのユーティリティーを再実行する必要があります。
移行ユーティリティーとは、次のものを指します。
Calendar Server 6 データベース内の各カレンダに所有者を割り当て、必要に応じて各カレンダ ID (calid) を所有者にマッピングします。これによって、複数ドメインおよび LDAP カレンダ検索データベース (CLD) プラグインがサポートされます。
cs5migrate のあと、csvdmig の前にこのユーティリティーを実行します。
カレンダのドメイン (@domainname) を各 calid に追加することにより、Calendar Server 6 サイトをアップグレードして、複数ドメインを使用するようにします。たとえば、sesta.com というドメインでは、jdoe の calid は jdoe@sesta.com となります。このユーティリティーは Calendar Server に同梱されています。
csmig のあと、cs5migrate の前にこのユーティリティーを実行します。
カレンダデータベースを Calendar Server バージョン 5 の形式からバージョン 6.2 の形式に移行します。-r オプションを指定し、データベースに対してこのユーティリティーを実行する必要があります。以前に Calendar Server バージョン 5.1.1 から 6.2 に移行したが、-r オプションを指定して cs5migrate ユーティリティーを実行しなかった場合は、csmigrate ユーティリティーの前に、このユーティリティーを実行する必要があります。
このユーティリティーは、csmig および csvdmig のあと、csmigrate の前に実行します。
Calendar Server バージョン 6.0、6.1、または 6.2 から Calendar Server 6.3 バージョンにアップグレードするために、カレンダデータベースを移行します。cs5migrate を -r オプションを指定して実行する必要がある場合は、このユーティリティーの前に実行します。
Access Manager (Legacy モード) での使用に備え、LDAP データを Schema バージョン 1 から Schema バージョン 2 に移行します。
ここでは、すべてのカレンダデータベースおよび LDAP データベースを、Calendar Server 6.3 ソフトウェアレベルに移行するために実行する必要のあるユーティリティーを判断する方法について説明します。
次の表を使用し、適切なユーティリティーのコレクションを見つけます。
ユーティリティーは、指定の順序で実行します。
移行前の Calendar Server のバージョン |
データベースファイルの状態 |
使用するユーティリティー |
---|---|---|
Calendar Server 6.0、6.1、6.2 |
定期的な予定と仕事があり、過去に cs5migrate を実行したことがある。 Schema バージョン 2 をすでに使用している。 |
csmigrate を実行します。 |
Calendar Server 6.0、6.1、6.2 |
定期的な予定と仕事があり、過去に cs5migrate を実行したことがある。 過去に Schema バージョン 2 を使用したことはないが、使用する必要性が生じた。 |
csmigrate および commdirmig を実行します。 |
Calendar Server 6.0、6.1、6.2 |
ファイルに対して cs5migrate を実行したことがない。 Schema バージョン 2 をすでに使用している。または、Schema バージョン 1 を使用しており、今後も使用を続ける予定である。 |
cs5migrate および csmigrate を実行します。 |
Calendar Server 6.0、6.1、6.2 |
ファイルに対して cs5migrate を実行したことがない。 過去に Schema バージョン 2 を使用したことはないが、使用する必要性が生じた。 |
cs5migrate、csmigrate、および commdirmig を実行します。 |
Calendar Server 5.1.1 |
過去に複数ドメインを使用したことがない。 |
csmig、csvdmig、cs5migrate、csmigrate、および commdirmig を実行します。 |
Calendar Server 5.1.1 以前 |
ファイルは複数ドメインまたは LDAP CLD をサポートしていない。LDAP データベースは Schema バージョン 1 を使用している。 |
データベースと LDAP ファイルを Calendar Server 5.1.1 レベルに移行する方法については、テクニカルサポートにお問い合わせください。 |
Calendar Server 5.1.1 以前 |
システムは制限付きの仮想ドメインに対応するよう設定されているか、Calendar Server ソフトウェアの複数のインスタンスが Solaris 10 以前のオペレーティングシステムにインストールされている。 |
移行要件の評価については、セールス担当者にお問い合わせください。 |
csmigrate ユーティリティーは、Calendar Server 6.0、6.1、または 6.2 データベースを Calendar Server 6.3 データベースに移行するために使用されます。csmigrate ユーティリティーは、その他の管理ツールとともに Calendar Server 製品の sbin ディレクトリ内にあります。
ここでは、次の内容について説明します。
csmigrate コマンドの構文は次のとおりです。
csmigrate [-q] [-d] [-l min|max] [-b backup_dir] source_dbdir target_dbdir
オプションとその用途は次のとおりです。
非出力モードを指定し、印刷指示は出しません。
ドライランモードを指定し、新規データベースは書き込まれません。
ログレベルを指定します。移行ログは csmigrate.log に書き込まれ、エラーはデフォルトログディレクトリの csmigrateError.log に書き込まれます。
ソースデータベースのバックアップを作成するディレクトリを指定します。プログラムはこのディレクトリにソースデータベースのバックアップを作成し、ソースデータベースを破損しないために、そのコピーに対して作業を行います。デフォルトの場所は、ソースデータベースディレクトリの backup です。
移行前のデータベースファイルが保存されているディレクトリ。
移行後のファイルが保存されるディレクトリ。
ツールのバージョン情報の印刷。
ツールの使用情報の印刷。
プログラムの終了コードは、失敗の場合は 255、成功の場合は 0 です。
csmigrate コマンドのオプションの使用例は次のとおりです。
csmigrate -b /var/opt/SUNWics5/tmpdb /var/opt/SUNWics5/old_db /var/opt/SUNWics5/new_db csmigrate -q /var/opt/SUNWics5/old_db /var/opt/SUNWics5/new_db csmigrate -l min old_db /var/opt/SUNWics5/new_db csmigrate -l max old_db /var/opt/SUNWics5/new_db
root 権限でログインします。
すべてのサービスを停止します。
たとえば、次のコマンドを実行します。
stop-cal
現在のデータベースを一時ディレクトリに移動します。
たとえば、csdb ディレクトリ全体を oldcsdb に移動します。
mv cal-svr-base/SUNWics5/csdb/* cal-svr-base/SUNWics5/oldcsdb
新規ディレクトリと、そのディレクトリ内の古いファイルの両方が、デフォルト管理者 (icsuser、icsgroup) によって所有されていることを確認します。
所有権が誤っている場合は、次のコマンドを使用して所有権を変更します。
chown -R icsuser:icsgroup /cal-svr-base/SUNWics5/oldcsdb/
移行ツールを実行します。
次の例に示すように、新規バックアップコピー (oldcsdb) から csdb ディレクトリに移行します。
cd cal-svr-base/SUNWics5/cal/sbin/ ./csmigrate -l max /cal-svr-base/SUNWics5/oldcsdb cal-svr-base/SUNWics5/csdb
カレンダサービスを再起動します。
たとえば、次のコマンドを使用します。
stop-cal
csmigrate ユーティリティーは、Calendar Server 5.1.1 データベースを Calendar Server 6.3 レベルに移行するために使用されます。加えて、初期の Calendar Server 6 バージョンから移行するときに、定期的なオプションを使用しなかった場合にもこのユーティリティーを使用します。
cs5migrate ユーティリティーでは、次の作業を実行できます。
これまでに、Connection for Microsoft Outlook を使用する計画がなかった場合は、定期的なデータ変換を行わずにこのユーティリティーを実行することもできます。ただし、Calendar Server 6.3 以降では、定期的なデータを新しい形式に変換する必要があります。
このユーティリティーは、Calendar Server 6.3 ソフトウェアへのアップグレード後に、ほかの管理ツールとともに sbin ディレクトリに格納されます。
csmig ユーティリティでは、必要に応じて、カレンダデータベース内の各カレンダに所有者を割り当て、各カレンダ ID (calid) を所有者にマッピングします。
csmig ユーティリティーは複数ドメインと LDAP Calendar Lookup Database (CLD) プラグインをサポートします。移行されたデータベース内のカレンダには、LDAP CLD プラグインを使用してアクセスできます。LDAP CLD プラグインについては、第 5 章「Calendar Server バージョン 6.3 での複数のマシンへのカレンダデータベースの分散の設定」を参照してください。
ここで説明する内容は次のとおりです。
csmig 移行ユーティリティーでは、次の機能を実行します。
csmig は、caldb.berkeleydb.homedir.path パラメータによって指定された現在のカレンダデータベース (*.db ファイル) 内のユーザーとリソースの両方のカレンダを移行します。新しい移行先ターゲットデータベースでは、csmig により、カレンダプロパティー (calprops)、予定、仕事 (作業)、およびグループスケジューリングエンジン (GSE) データベースファイルに含まれる、LDAP CLD プラグインで必要とされるエントリが更新されます。
csmig は移行先ターゲットデータベースだけに書き込みを行います。既存のカレンダデータベースに書き込むことはありません。
csmig は、必要に応じて、カレンダデータベース内の各カレンダに所有者を割り当て、各カレンダ ID (calid) を所有者にマッピングします。すべてのデフォルトの calids はそのまま維持され、変更は行われません。
その他のカレンダは次のようにマッピングされます。
有効な所有者がいないユーザーカレンダは、-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 は、カレンダが存在するバックエンドサーバーのホスト名を指定します。
csmig を使用するための要件は次のとおりです。
カレンダデータベースが破損していないこと。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 モードを使用します。 |
バージョン 5.1.1 以前の Calendar Server を使用している場合は、Calendar Server 6.3 のインストールと設定が完了したあとに csmig を実行し、既存の Calendar Server および LDAP データベースを移行します。LDAP データの移行は、LDAP CLD プラグインを正常に動作させるために必要です。csmig を使用してカレンダデータを移行する場合は、次の手順を実行します。
comm_dssetup.pl を使用し、Directory Server を設定します。
まだ comm_dssetup.pl を使用して LDAP 属性にインデックスを作成していない場合は、ここで行います。これによって、LDAP データの移行処理のパフォーマンスが大幅に向上します。
テストサーバー (本稼働サーバーではない) を使用して、テストドライランを実行します。
ドライランでは、実際の移行中に csmig によって何が行われるかがレポートされますが、データは移行されません。ドライラン後、実際に移行を行う前に、エラーを修正し、未解決のカレンダを処理する計画を決定します。
テストドライランの実行方法については、「3.5.4 csmig ユーティリティーの移行の手順」を参照してください。
運用データを移行します。
本稼働では、csmig によって、カレンダデータベース (.db ファイル) と LDAP データ (ユーザーおよびグループの設定データ)、icsSubscribed、icsCalendar、icsCalendarOwned、icsFreeBusy、icsSet、および uid (リソースカレンダ用) が移行されます。移行後、すべてのカレンダリソースに LDAP エントリが作成されます。
運用データの移行方法については、「3.5.4 csmig ユーティリティーの移行の手順」を参照してください。
必要に応じて、Calendar Server 6.3 を中継サーバーにインストールします。
カレンダデータベースのスナップショットを中継サーバーにコピーします。
次の作業を実行して、中継サーバー上に本稼働 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/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) で未解決のカレンダを確認し、「3.5.4 csmig ユーティリティーの移行の手順」 の 「3.5.4 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 プラグインの構成パラメータの指定方法については、第 5 章「Calendar Server バージョン 6.3 での複数のマシンへのカレンダデータベースの分散の設定」を参照してください。
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) します。カレンダの移動後、元のサーバー上のカレンダを削除できます。カレンダの移動方法については、「15.6 ユーザーカレンダの管理」を参照してください。
csvdmig ユーティリティーは、複数ドメイン環境で使用するカレンダデータベースおよび LDAP ユーザーおよびグループエントリを準備します。デフォルトドメインしか使用しない場合でも、このユーティリティーを実行する必要があります。
非ドメイン環境を、Calendar Server 6.3 の複数ドメイン環境に移行する場合は、このユーティリティーを使用する前に必ず csmig を実行してください。
ここで説明する内容は次のとおりです。
csvdmig ユーティリティーは、データベースと LDAP エントリに対して次の変更を加えます。
カレンダ ID (calids) の形式が変更されます。
変更前: 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 |
マッピングファイルを指定する入力パラメータ。マッピングファイルについては、「3.6.2.1 マッピングファイル」を参照してください。デフォルトは MigrateMapping です。 |
-c ConfigFile |
Calendar Server 設定ファイルを指定する入力パラメータ。デフォルトは ics.conf ファイルです。 |
-t DestinationDB |
移行するデータベースの位置を指定する出力パラメータ。デフォルトは MigratedDB です。 ヒント – 常に -t オプションを使用します。 このオプションについて詳しくは、「3.6.2.2 出力先 DB」を参照してください。 |
-e ErrorFile |
解決できないエラー用のエラーファイルの名前を指定する出力パラメータ。デフォルトは MigrateError です。 |
DB | LDAP |
どのデータベースを変更するかを指定します。 DB: カレンダデータベース LDAP: LDAP ディレクトリ デフォルトはカレンダデータベース (DB) です。 |
マッピングファイルは、既存のユーザーをそれぞれのドメインにマッピングする入力テキストファイルです。csvdmig を実行する前に、マッピングファイルを作成する必要があります。古い値と新しい値の間にスペースを入力し、1 行に 1 つのエントリを指定します。次に例を示します。
user1 user1@sesta.com user2 user2@siroe.com user3 user3@sesta.com ... usern usern@siroe.com
移行されるデータベースの場所。ユーティリティーは、ここにあるファイルをアップデートします。csvdmig ユーティリティーを使用する前に、このディレクトリをバックアップしてください。
-t オプションを指定しなければ、ユーティリティーは現在のディレクトリ (コマンド行で pwd を実行することで指定されたディレクトリ) の内容の移行を試行しますが、その結果は予期できません。
次に csvdmig の例を示します。
デフォルト値を使用して、LDAP ディレクトリサーバーのデータを移行します。
csvdmig migrate LDAP
Calendar Server データベースを移行します。
csvdmig -t targetDB -e errorFile -m mappingFile migrate
commdirmig ユーティリティーでは、認証サービスに Access Manager を使用できるように、LDAP データを Sun LDAP Schema バージョン 1 から Schema バージョン 2 に移行します。過去のインストールが Schema バージョン 2 をすでに使用している場合は、このユーティリティーを再度実行する必要はありません。
この移行ユーティリティーは、Schema バージョン 1 の LDAP データベースを Schema バージョン 2 に移行します。Access Manager ソフトウェアを認証に使用する場合は、このユーティリティーを実行して LDAP エントリを Schema バージョン 2 に変換する必要があります。
Access Manager を使用していない場合、Schema バージョン 2 は LDAP を使用するすべての Communications Suite 製品に最適な LDAP モードであるため、LDAP データの移行を検討することをお勧めします。
設定用の LDAP ディレクトリが個別に用意されている場合は、認証用の LDAP だけでなく、その LDAP に対しても commdirmig を実行する必要があります。
カレンダおよび LDAP データベースを、旧バージョンの Calendar Server ソフトウェアから Calendar Server ソフトウェアのバージョン 6.3 に移行するために必要なほかのすべての移行ユーティリティーを実行したあとに、commdirmig を実行します。
commdirmig 移行ユーティリティーには、特別な準備と計画が必要です。このユーティリティーについては別のマニュアルで説明しています。『Sun Java Communications Suite 5 Schema Migration Guide 』を参照してください。
commdirmig ユーティリティーは、Communications Suite インストーラからインストールする Delegated Administrator にバンドルされています。
ユーティリティーのパッチもテクニカルサポートから入手できます。