パート II Calendar Server バージョン 6.3 ソフトウェアのインストール後の設定

ここに含まれている各章では、インストール後、Calendar Server を使用する前に実行する必要のある設定と移行の手順について説明します。

次の章で構成されています。

• 第 2 章「Calendar Server 6.3 ソフトウェアの初期実行時設定プログラム (csconfigurator.sh)」

• 第 3 章「Calendar Server 6.3 のデータベース移行ユーティリティー」

第 2 章 Calendar Server 6.3 ソフトウェアの初期実行時設定プログラム (csconfigurator.sh)

Calendar Server をインストールしたあと、実行する前に設定を行う必要があります。2 つの設定プログラムを次の順序で実行することが重要です。

1. comm_dssetup.pl

   『Sun Java System Communications Suite 5 Installation and Configuration Guide』の説明に従って、LDAP ディレクトリサーバーを設定します。

2. csconfigurator.sh

   この章の説明に従って、Calendar Server を設定します。

この章の内容は次のとおりです。

• 「2.1 Calendar Server 6.3 ソフトウェアの設定情報の収集」

• 「2.2 csconfigurator.sh の実行」

以前のバージョンの Calendar Server または Messaging Server をすでにインストールしている場合、LDAP ディレクトリエントリを Schema バージョン 1 から Schema バージョン 2 に移行する必要があります。

この章で説明している設定ユーティリティーを実行する前に、必ず『Sun Java Communications Suite 5 Schema Migration Guide 』を参照してください。上記マニュアルでは、設定ユーティリティーを実行するためのタイミングとオプションについて説明しています。

2.1 Calendar Server 6.3 ソフトウェアの設定情報の収集

Calendar Server 設定プログラム csconfigurator.sh は、新しい ics.conf 設定ファイルを次のディレクトリに作成します。

Solaris の場合: /etc/opt/SUNWics5/config

Linux の場合: /etc/opt/sun/calendar/config

設定プログラムでは、インストールについての特定の情報を入力する必要がある、多くの質問が表示されます。

設定プログラムを実行する前に、次の設定情報を収集する必要があります。

• 「2.1.1 LDAP サーバーのオプション」

• 「2.1.2 Directory Manager のオプション」

• 「2.1.3 Calendar Server 管理者」

• 「2.1.4 電子メールと電子メールアラームのオプション」

• 「2.1.5 ランタイム設定のオプション」

• 「2.1.6 Calendar Server の起動」

• 「2.1.7 データベース、ログ、および一時ファイルのディレクトリ」

設定情報の追跡に役立つように、付録 B 「Calendar Server 設定ワークシート」のワークシートを使用してください。ただし、他のコンポーネント製品との競合、たとえばポート番号の競合などを避けるため、Java Enterprise System インストーラを実行する前に情報を特定する必要があります。

2.1.1 LDAP サーバーのオプション

Calendar Server では、ユーザーの認証や、ユーザー設定の格納と検索を行うためのディレクトリサーバーが必要です。次の表に、LDAP サーバーのホスト情報やポート情報の収集に使用するオプションを示します。

2.1.2 Directory Manager のオプション

次の表に、Directory Manager として指定されたユーザーの名前とパスワードの収集に使用するオプションを示します。

2.1.3 Calendar Server 管理者

Calendar Server 管理者は他の Calendar Server ACL より優先されるユーザーアカウントです。Calendar Server 管理者ユーザーアカウントは、認証ディレクトリサーバーに存在している必要があります。このアカウントはプロキシ認証にも使用されます。次の表に、Calendar Server 管理者のユーザー ID とパスワードの収集に使用するオプションを示します。

2.1.4 電子メールと電子メールアラームのオプション

サーバーに問題が生じたときに Calendar Server 管理者に電子メールのアラームメッセージを送信するように Calendar Server を設定できます。次の表に、電子メール情報の収集に使用するオプションを示します。

2.1.5 ランタイム設定のオプション

次に示す Calendar Server のランタイムオプションとシステムリソースオプションを設定できます。

2.1.6 Calendar Server の起動

Calendar Server が自動的に起動するように、次のオプションを設定できます。

2.1.7 データベース、ログ、および一時ファイルのディレクトリ

Calendar Server は特定のディレクトリにカレンダデータベースファイル、ログファイル、および一時ファイルを作成し、情報を格納します。

ログファイルと一時ファイルのディレクトリの位置や名前を変更しないでください。

2.2 csconfigurator.sh の実行

設定プログラムは、グラフィカルユーザーインタフェース (GUI) からでも、コマンド行からでも実行できます。

プログラムをリモート実行する場合は、DISPLAY 環境変数を正しく設定し、サーバーからの X-Windows 接続により、使用しているコンピュータ上に表示できるようにする必要があります。たとえば、xhost ユーティリティーを使用するには、使用しているコンピュータで次のコマンドを実行します。

# xhost +

ここでは、次の内容について説明します。

• 「コマンド行から設定プログラムを実行するには」

• 「GUI から設定プログラムを実行するには」

コマンド行から設定プログラムを実行するには

1. スーパーユーザー (root) としてログインするか、スーパーユーザーになります。

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

3. 次の表から選択したオプションを使用してスクリプトを実行します。

   オプション	説明
   -nodisplay	設定スクリプトをテキストのみモード (非 GUI) で実行します。
   -noconsole	テキスト出力を表示しません。設定スクリプトをサイレントモードで実行するには、このオプションに -nodisplay を指定して実行します。
   -novalidate	入力フィールドのテキストを検証しません。
   -saveState [statefile]	設定に関する質問に対して入力した回答を状態ファイル (テキストファイル) に保存します。状態ファイルの完全修飾パスを指定しない場合、ファイルは次のデフォルトディレクトリに保存されます。/opt/SUNWics5/cal/jconfigure 。
   -state [statefile]	入力値の設定に状態ファイルを使用します。このオプションは、-novalidate および -noconsole と一緒に使用する必要があります。

   たとえば、コマンド行モードで設定スクリプトを実行するには、次のコマンドを使用します。

   ./csconfigurator.sh -nodisplay

   コマンド行バージョンでは、GUI と同じ情報が同じ順序で尋ねられます。デフォルト値は、角カッコ [] で示されます。デフォルト値をそのまま使用するには、キーボードで Enter キーを押します。

   ---

   注 –

   スクリプトによって提示されるさまざまな質問に含まれる情報については、以降の節で示す GUI 画面内のテキストを参照してください。

   ---

GUI から設定プログラムを実行するには

1. スーパーユーザー (root) としてログインするか、スーパーユーザーになります。

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

3. 次のコマンドを実行します。

   ./csconfigurator.sh

   設定プログラムでは、次の画面が表示されます。

   • 「2.3 開始画面」

   • 「2.4 「管理、ユーザー設定、および認証」画面」

   • 「2.6 Calendar Server 6.3 の「メールと電子メールアラーム」画面」

   • 「2.7 Calendar Server 6.3 の「ランタイム設定」画面」

   • 「2.9 Calendar Server 6.3 の「設定およびデータファイルの格納先ディレクトリ」画面」

   • 「2.10 Calendar Server 6.3 の「アーカイブおよびホットバックアップの設定」画面 」

   • 「2.11 Calendar Server 6.3 の「設定準備が完了しました」画面」

   • 「2.13 Calendar Server 6.3 の「設定の概要」画面」

   ---

   注意 –

   設定プログラムはシングルドメインを設定できるだけです。複数のドメインを使用する予定の場合は、Delegated Administrator を使用してドメインを追加する必要があります。

   ---

   ---

   注 –

   どの画面でもタイトルバーが正しくありません。バージョン番号は、表示された 6.5 ではなく 6.3 です。

   ---

2.3 開始画面

図 2–1 Calendar Server 設定プログラムの開始画面

続行する場合は「次へ」をクリックし、終了する場合は「取消し」をクリックします。

2.4 「管理、ユーザー設定、および認証」画面

図 2–2 「管理、ユーザー設定、および認証」設定画面

2.4.1 ユーザー設定ディレクトリのオプション

LDAP サーバーのホスト名

ユーザー認証に使用する LDAP ディレクトリサーバーのホスト名。デフォルト: 現在のホスト

LDAP サーバーのポート

LDAP サーバーが待機するポート番号。デフォルト: 389

Directory Manager DN

ディレクトリサーバースキーマに変更を加えることができるユーザーの名前。デフォルト: cn=Directory Manager

Directory Manager のパスワード

Directory Manager のパスワード。これはプレーンテキストでは保存されません。デフォルト: なし

2.5 仮想ドメインとカレンダ管理者の画面

図 2–3 仮想ドメインとカレンダ管理者の画面

仮想ドメイン、ホストされたドメイン、複数ドメインはどれも同一の機能を表す名前であり、対応するユーザーおよびグループレコードとともに複数の LDAP ドメインを保持できることを意味します。

非仮想ドメイン環境からアップグレードする場合は、「仮想ドメインのサポートを有効」チェックボックスにチェックマークを付ける必要があります。すでに複数ドメイン環境が存在する場合は、チェックボックスはグレー表示になっています。仮想ドメインのサポートは現在、Calendar Server のデフォルトの機能になっており、オプションではありません。

2.5.1 Calendar Server 6.3 の仮想ドメイン設定

図 2–4 仮想ドメインの構造

現在、Calendar Server を新規インストールした場合、仮想ドメインはデフォルトでサポートされます。設定プログラムのグラフィカルユーザーインタフェースを使用して、「新しいデフォルトドメイン」入力ボックスにデフォルトのドメイン名を入力します。設定プログラムによりドメインが作成されます。

「デフォルトドメイン」ボックスに示されるドメインから、デフォルトドメインとして 1 つを選択します。以前のバージョンの Calendar Server で複数ドメインをすでに使用しており、「デフォルトドメイン」ボックスに示されるドメインを使用しない場合は、ボックスをクリックしてドメインのリストを表示し、そこから新しいデフォルトドメインを選択します。

2.5.2 Calendar Server 6.3 のカレンダ管理者の名前とパスワード

ユーザー名

Calendar Server 管理者のユーザー名。デフォルト: calmaster

管理者のパスワード

Calendar Server 管理者のパスワード。デフォルト: なし

電子メールアドレス

Calendar Server 管理者の電子メールアドレス。

サイト管理者

サイト管理者とは、複数のドメインのプロキシ認証権限を持つユーザーです。

次の基準に従って該当する選択肢をクリックします。カレンダ管理者がサイト管理者でもある場合、「はい」。カレンダ管理者がサイト管理者ではない場合、「いいえ」。

続行する場合は、「次へ」をクリックし、前の画面に戻る場合は「戻る」をクリックします。終了する場合は「取消し」をクリックします。

2.6 Calendar Server 6.3 の「メールと電子メールアラーム」画面

図 2–5 「メールと電子メールアラーム」設定画面

電子メールアラーム

サーバーに問題が生じたときに Calendar Server が Calendar Server 管理者に電子メールのアラームメッセージを送信するかどうかを指定します。デフォルト: 「無効」。「無効」を選択した場合、サーバーの問題に関する電子メールアラームは管理者に送信されません。

管理者の電子メールアドレス

電子メールのアラームメッセージを受信する Calendar Server 管理者の電子メールアドレス。デフォルト: なし

SMTP ホスト名

アラームメッセージの送信に使用される SMTP サーバーのホスト名。デフォルト: 現在のホスト。

続行する場合は、「次へ」をクリックし、前の画面に戻る場合は「戻る」をクリックします。終了する場合は「取消し」をクリックします。

2.7 Calendar Server 6.3 の「ランタイム設定」画面

図 2–6 「ランタイム設定」画面

サービスポート

Web (HTTP) アクセスができるようにするために Calendar Server が待機しているポートの番号。デフォルト: 80

最大セッション

同時実行可能な Calendar Server セッションの最大数。デフォルト: 5000

最大スレッド

同時実行可能な Calendar Server スレッドの最大数。デフォルト: 20

サーバープロセスの数

サーバー上で実行できる Calendar Server プロセスの最大数。デフォルト: Calendar Server をインストールしているサーバーの CPU 数

ランタイムユーザー ID

Calendar Server を実行する UNIX ユーザー名。アカウントが存在しない場合は、設定プログラムによって作成されます。デフォルト: icsuser

---

注意 –

ランタイムユーザー ID には root を使用しないでください。

---

ランタイムグループ ID

Calendar Server を実行する UNIX グループ。グループが存在しない場合は、設定プログラムによって作成されます。デフォルト: icsgroup

Calendar Server 起動オプション

チェックボックスをクリックしてどちらかまたは両方のオプションを選択します。

• 設定が成功したら起動する

  この設定プログラムの実行が成功したあと、Calendar Server が自動的に起動するかどうかを指定します。

• システムの起動時に起動する

  システムの起動後、Calendar Server が自動的に起動するかどうかを指定します。

---

注 –

デフォルトでは、「システムの起動時に起動する」チェックボックスだけにチェックマークが付けられています。

---

続行する場合は「次へ」をクリックし、前の画面に戻る場合は「戻る」をクリックします。終了する場合は「取消し」をクリックします。

2.8 Calendar Server 6.3 の「フロントエンド/バックエンド配備を設定」画面

このサーバーを単一サーバー配備として設定するか、フロントエンド/バックエンド配備として設定するかを選択します。Calendar Server の単一サーバーインスタンスを使用することにした場合、この画面のチェックボックスにはチェックマークを付けません。1 つまたは複数のサーバーに Calendar Server データベースを配備し、別のサーバー上のクライアントと通信するプロセスを継続する場合は、チェックボックスにチェックマークを付けます。

ここでは、次の内容について説明します。

• 「2.8.1 Calendar Server 6.3 の単一サーバー配備」

• 「2.8.2 Calendar Server 6.3 のフロントエンド/バックエンド配備」

2.8.1 Calendar Server 6.3 の単一サーバー配備

図 2–7 単一サーバー配備

管理プロセスとデータベースの両方を 1 つのサーバーに置く単一サーバー配備の場合は、この画面のどの部分も変更しないでください。「次へ」をクリックして次に進みます。

フロントエンドマシンとバックエンドマシンを別々に配備する場合は、「フロントエンド/バックエンド配備を設定」というチェックボックスにチェックマークを付けます。次の 2 つのスクリーンショットに示すように、画面表示が変更し、フロントエンドサーバーとバックエンドサーバーを個別に設定できます。

2.8.2 Calendar Server 6.3 のフロントエンド/バックエンド配備

図 2–8 「フロントエンド/バックエンドサーバーを設定」

この画面では、次の手順を実行します。

1. バックエンドサーバー、つまりカレンダデータベースを格納するサーバーを設定するには、サービスポートを指定するだけです。

   「サービスポート」入力ボックスにはあらかじめ、 ics.conf のパラメータである service.dwp.server.hostname.port と service.dwp.port で指定されたポートが入力されています。

   ポート番号を変更する場合は、「サービスポート」入力ボックスに適切なポート番号を入力します。

2. フロントエンドサーバーを設定するには、「ホストを追加」をクリックして、設定しているサーバーのホスト名と IP アドレスを入力します。

   ---

   注 –

   現在設定しているサーバー以外はリストに追加しないでください。別のフロントエンドサーバーを設定する予定の場合は、それらの設定時に追加します。設定に追加する各サーバーで設定プログラムを実行する必要があります。

   ---

3. このサーバーがデフォルトのフロントエンドサーバーである場合は、「標準」チェックボックスにチェックマークを付けます。

4. 「次へ」をクリックします。

   ---

   注 –

   「選択したホストを削除」をクリックして、このリストからサーバーを削除することもできます。

   ---

2.9 Calendar Server 6.3 の「設定およびデータファイルの格納先ディレクトリ」画面

この画面では、デフォルトのディレクトリをそのまま使用してください。設定およびデータファイルの格納先ディレクトリを選択できますが、お勧めしません。

図 2–9 ディレクトリ選択設定画面

設定ディレクトリ

設定ファイル (ics.conf) が格納されるディレクトリ。

データベースディレクトリ

Calendar Server でカレンダデータベースファイルを作成し、格納するディレクトリ。デフォルト: /var/opt/SUNWics5/csdb

添付ファイルの保存用ディレクトリ

添付ファイルが格納されるディレクトリ。デフォルト: /var/opt/SUNWics5/astore

ログディレクトリ

Calendar Server がログファイルを書き込むディレクトリ。デフォルト: /var/opt/SUNWics5/logs

一時ファイルディレクトリ

Calendar Server が一時ファイルを書き込むディレクトリ。デフォルト: /var/opt/SUNWics5/tmp

続行する場合は「次へ」をクリックし、前の画面に戻る場合は「戻る」をクリックします。終了する場合は「取消し」をクリックします。

これらのディレクトリのいずれかがまだ存在していない場合は、存在しないディレクトリごとにポップアップウィンドウが表示されます。適切なボタンをクリックして、設定プログラムに新しいディレクトリを作成させるか、別のディレクトリを選択できる画面に戻るかを選択します。

すでに存在しているが空ではないディレクトリの場合は、2 つの選択肢を示すポップアップウィンドウが表示されます。適切なボタンをクリックして、ディレクトリをそのまま使用するか、別のディレクトリを選択できる画面に戻ります。

2.10 Calendar Server 6.3 の「アーカイブおよびホットバックアップの設定」画面

この画面では、自動バックアップタイプの両方、または 2 つのタイプのどちらかを選択できます。または、どちらも選択しなくてもかまいません。必要に応じて、各ボックスを選択または選択解除します。アーカイブバックアップとホットバックアップの両方を使用することを強くお勧めします。

機器の損傷のためにデータベースのコピーがすべて失われることがないようにしてください。自動バックアップコピーは、ライブデータベースが格納されているものとは別のディスクやディスクシステムに保存してください。

自動バックアップについては、第 9 章「自動バックアップ (csstored) の設定」を参照してください。

図 2–10 「アーカイブおよびホットバックアップの設定」画面

アーカイブを有効

このボックスにチェックマークが付いていると (デフォルト)、csstored によって 24 時間ごとにカレンダデータベースのスナップショットが取得されます。終日にわたって、その日のトランザクションログファイルがスナップショットとともにアーカイブバックアップディレクトリに定期的に格納されます。

このボックスにチェックマークが付いていない場合、「アーカイブディレクトリ」入力フィールドはグレー表示になります。

アーカイブディレクトリ

「参照...」をクリックしてバックアップディレクトリを選択するか、デフォルトをそのまま使用します。

ホットバックアップを有効

このボックスにチェックマークが付いていると (デフォルト)、csstored によって 24 時間ごとにカレンダデータベースのスナップショットが取得され、設定された間隔 (デフォルトでは 2 分) で終日にわたりトランザクションログがスナップショットに適用されるため、ライブデータベースとほぼ同じ内容が保証されます。

このボックスにチェックマークが付いていないと、「ホットバックアップディレクトリ」入力フィールドはグレー表示になります。

ホットバックアップディレクトリ

「参照...」をクリックしてバックアップディレクトリを選択するか、デフォルトをそのまま使用します。

アーカイブする期間 (日数)

このフィールドは、「アーカイブを有効」ボックスにチェックマークを付けた場合にのみ使用できます。それ以外の場合はグレー表示になります。

「最小」および「最大」フィールドの上向きの矢印または下向きの矢印をクリックすると、アーカイブバックアップをバックアップディレクトリに保存しておく日数を選択できます。

ホットバックアップする期間 (日数)

このフィールドは、「ホットバックアップを有効」ボックスにチェックマークを付けた場合にのみ使用できます。それ以外の場合はグレー表示になります。

次の 2 つの方法で、ホットバックアップを保持する日数を設定できます。

• 「最小」および「最大」フィールドの上向きの矢印または下向きの矢印をクリックすると、ホットバックアップをディレクトリに保存しておく日数を選択できます。

  一度に実際に格納されるコピー数は、ファイルのサイズやディレクトリのサイズによって異なります。サイズ制限または最大コピー数の制限のいずれかを超えると、この設定画面で指定した最小数まで、もっとも古いコピーが破棄されます。

• ホットバックアップの設定をアーカイブバックアップと同じにする場合は、「アーカイブと同じ」ボックスにチェックマークを付けます。

続行する場合は「次へ」をクリックし、前の画面に戻る場合は「戻る」をクリックします。設定プログラムを終了する場合は「取消し」をクリックします。

2.11 Calendar Server 6.3 の「設定準備が完了しました」画面

これまで、画面を使って設定に必要な情報を収集したり、有効性を検査したりしてきました。この時点では、設定情報を前に戻って入力し直すことも、設定を開始することもできます。

図 2–11 「設定準備が完了しました」画面

Calendar Server を設定する場合は「すぐに設定する」をクリックし、前の画面に戻る場合は「戻る」をクリックします。終了する場合は「取消し」をクリックします。

2.12 Calendar Server 6.3 の「シーケンスを完了」画面

図 2–12 「シーケンスを完了」画面

このパネルでは、すべての作業とその結果 (成功または失敗) に関する情報が実行中に更新されます。「すべての作業が成功しました」というメッセージが表示されたら、設定は終了です。表示されたログファイルを見て、エラーメッセージがないかどうかを調べてください。

設定プログラムが完了したら「次へ」をクリックします。

2.13 Calendar Server 6.3 の「設定の概要」画面

図 2–13 「設定の概要」画面

「詳細」をクリックして設定ログの詳細を表示するか、または「閉じる」をクリックして設定プログラムを終了します。

第 3 章 Calendar Server 6.3 のデータベース移行ユーティリティー

ここでは、Calendar Server 6.3 ソフトウェアをインストールし、設定したあとにカレンダデータベースと LDAP データベースを移行するためのさまざまなデータベース移行ユーティリティーについて説明します。

この章の内容は次のとおりです。

• 「3.1 Calendar Server データベース移行ユーティリティーの概要」

• 「3.2 適切な Calendar Server ユーティリティーの選択」

• 「3.3 csmigrate ユーティリティー」

• 「3.4 cs5migrate ユーティリティー」

• 「3.5 csmig ユーティリティー」

• 「3.6 csvdmig」

• 「3.7 commdirmig」

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 がインストールされている場合は、データの移行についてはテクニカルサポートにお問い合わせください。

3.1 Calendar Server データベース移行ユーティリティーの概要

ここでは、それぞれの移行ユーティリティーについて説明します。過去にインストールされた Calendar Server のバージョンに応じ、必要となる移行ユーティリティーのみを使用します。これらのユーティリティーは sbin ディレクトリにあります。

データベースに対して過去に cs5migrate ユーティリティーを実行したことがあるが、そのときに -r オプションを指定しなかった場合は、ほかのユーティリティーを実行する前に -r オプションを指定してこのユーティリティーを再実行する必要があります。

移行ユーティリティーとは、次のものを指します。

「3.5 csmig ユーティリティー」

Calendar Server 6 データベース内の各カレンダに所有者を割り当て、必要に応じて各カレンダ ID (calid) を所有者にマッピングします。これによって、複数ドメインおよび LDAP カレンダ検索データベース (CLD) プラグインがサポートされます。

cs5migrate のあと、csvdmig の前にこのユーティリティーを実行します。

「3.6 csvdmig」

カレンダのドメイン (@domainname) を各 calid に追加することにより、Calendar Server 6 サイトをアップグレードして、複数ドメインを使用するようにします。たとえば、sesta.com というドメインでは、jdoe の calid は jdoe@sesta.com となります。このユーティリティーは Calendar Server に同梱されています。

csmig のあと、cs5migrate の前にこのユーティリティーを実行します。

「3.4 cs5migrate ユーティリティー」

カレンダデータベースを Calendar Server バージョン 5 の形式からバージョン 6.2 の形式に移行します。-r オプションを指定し、データベースに対してこのユーティリティーを実行する必要があります。以前に Calendar Server バージョン 5.1.1 から 6.2 に移行したが、-r オプションを指定して cs5migrate ユーティリティーを実行しなかった場合は、csmigrate ユーティリティーの前に、このユーティリティーを実行する必要があります。

このユーティリティーは、csmig および csvdmig のあと、csmigrate の前に実行します。

「3.3 csmigrate ユーティリティー」

Calendar Server バージョン 6.0、6.1、または 6.2 から Calendar Server 6.3 バージョンにアップグレードするために、カレンダデータベースを移行します。cs5migrate を -r オプションを指定して実行する必要がある場合は、このユーティリティーの前に実行します。

「3.7 commdirmig」

Access Manager (Legacy モード) での使用に備え、LDAP データを Schema バージョン 1 から Schema バージョン 2 に移行します。

3.2 適切な Calendar Server ユーティリティーの選択

ここでは、すべてのカレンダデータベースおよび LDAP データベースを、Calendar Server 6.3 ソフトウェアレベルに移行するために実行する必要のあるユーティリティーを判断する方法について説明します。

次の表を使用し、適切なユーティリティーのコレクションを見つけます。

ユーティリティーは、指定の順序で実行します。

3.3 csmigrate ユーティリティー

csmigrate ユーティリティーは、Calendar Server 6.0、6.1、または 6.2 データベースを Calendar Server 6.3 データベースに移行するために使用されます。csmigrate ユーティリティーは、その他の管理ツールとともに Calendar Server 製品の sbin ディレクトリ内にあります。

ここでは、次の内容について説明します。

• 「3.3.1 csmigrate ユーティリティーの構文」

• 「3.3.2 csmigrate の例」

• 「Calendar Server の csmigrate ユーティリティーの実行方法」

3.3.1 csmigrate ユーティリティーの構文

csmigrate コマンドの構文は次のとおりです。

csmigrate [-q] [-d] [-l min|max] [-b backup_dir] source_dbdir target_dbdir

オプションとその用途は次のとおりです。

-q (任意)

非出力モードを指定し、印刷指示は出しません。

-d (任意)

ドライランモードを指定し、新規データベースは書き込まれません。

-l min|max (任意)

ログレベルを指定します。移行ログは csmigrate.log に書き込まれ、エラーはデフォルトログディレクトリの csmigrateError.log に書き込まれます。

-b backup_dir (オプション)

ソースデータベースのバックアップを作成するディレクトリを指定します。プログラムはこのディレクトリにソースデータベースのバックアップを作成し、ソースデータベースを破損しないために、そのコピーに対して作業を行います。デフォルトの場所は、ソースデータベースディレクトリの backup です。

-source_dbdir (必須)

移行前のデータベースファイルが保存されているディレクトリ。

-target_dbdir (必須)

移行後のファイルが保存されるディレクトリ。

-V (サポートされるその他のオプション)

ツールのバージョン情報の印刷。

-? (サポートされるその他のオプション)

ツールの使用情報の印刷。

プログラムの終了コードは、失敗の場合は 255、成功の場合は 0 です。

3.3.2 csmigrate の例

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

Calendar Server の csmigrate ユーティリティーの実行方法

1. root 権限でログインします。

2. すべてのサービスを停止します。

   たとえば、次のコマンドを実行します。

   stop-cal

3. 現在のデータベースを一時ディレクトリに移動します。

   たとえば、csdb ディレクトリ全体を oldcsdb に移動します。

   mv cal-svr-base/SUNWics5/csdb/* cal-svr-base/SUNWics5/oldcsdb

4. 新規ディレクトリと、そのディレクトリ内の古いファイルの両方が、デフォルト管理者 (icsuser、icsgroup) によって所有されていることを確認します。

   所有権が誤っている場合は、次のコマンドを使用して所有権を変更します。

   chown -R icsuser:icsgroup /cal-svr-base/SUNWics5/oldcsdb/

5. 移行ツールを実行します。

   次の例に示すように、新規バックアップコピー (oldcsdb) から csdb ディレクトリに移行します。

   cd cal-svr-base/SUNWics5/cal/sbin/ 
   ./csmigrate -l max /cal-svr-base/SUNWics5/oldcsdb cal-svr-base/SUNWics5/csdb

6. カレンダサービスを再起動します。

   たとえば、次のコマンドを使用します。

   stop-cal

3.4 cs5migrate ユーティリティー

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 ディレクトリに格納されます。

3.5 csmig ユーティリティー

csmig ユーティリティでは、必要に応じて、カレンダデータベース内の各カレンダに所有者を割り当て、各カレンダ ID (calid) を所有者にマッピングします。

csmig ユーティリティーは複数ドメインと LDAP Calendar Lookup Database (CLD) プラグインをサポートします。移行されたデータベース内のカレンダには、LDAP CLD プラグインを使用してアクセスできます。LDAP CLD プラグインについては、第 5 章「Calendar Server バージョン 6.3 での複数のマシンへのカレンダデータベースの分散の設定」を参照してください。

ここで説明する内容は次のとおりです。

• 「3.5.1 csmig ユーティリティーの機能」

• 「3.5.2 csmig ユーティリティーの要件」

• 「3.5.3 csmig の構文」

• 「3.5.4 csmig ユーティリティーの移行の手順」

• 「3.5.5 csmig のヒントとトラブルシューティング」

3.5.1 csmig ユーティリティーの機能

csmig 移行ユーティリティーでは、次の機能を実行します。

• 「3.5.1.1 カレンダを移行する」

• 「3.5.1.2 カレンダに所有者を割り当てる」

• 「3.5.1.3 LDAP 属性を更新する」

3.5.1.1 カレンダを移行する

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

csmig は移行先ターゲットデータベースだけに書き込みを行います。既存のカレンダデータベースに書き込むことはありません。

3.5.1.2 カレンダに所有者を割り当てる

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

3.5.1.3 LDAP 属性を更新する

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

3.5.2 csmig ユーティリティーの要件

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

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

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

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

  ユーザー設定を格納する LDAP ディレクトリサーバーでカレンダユーザーの属性を管理するための権限も必要です。

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

3.5.3 csmig の構文

csmig ユーティリティーの構文は次のとおりです。

csmig [-t DestinationDB]
      [-b Backend-DWPHost]
      [-o OutputFile]
      [-e ErrorFile]
      [-m MappingFile]
      [-c calendarOwner]
      [-r resourceOwner]
      { migrate|dryrun }

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

3.5.4 csmig ユーティリティーの移行の手順

バージョン 5.1.1 以前の Calendar Server を使用している場合は、Calendar Server 6.3 のインストールと設定が完了したあとに csmig を実行し、既存の Calendar Server および LDAP データベースを移行します。LDAP データの移行は、LDAP CLD プラグインを正常に動作させるために必要です。csmig を使用してカレンダデータを移行する場合は、次の手順を実行します。

csmig を使用するための高レベルの手順

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

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

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

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

   テストドライランの実行方法については、「3.5.4 csmig ユーティリティーの移行の手順」を参照してください。

3. 運用データを移行します。

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

   運用データの移行方法については、「3.5.4 csmig ユーティリティーの移行の手順」を参照してください。

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

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

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

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

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

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

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

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

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

7. cal-svr-base/SUNWics5/cal/sbin ディレクトリに移動します。

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

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

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

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

    cal-svr-base/SUNWics5/cal/sbin/stop-cal

11. -dryrun オプションを指定して csmig を実行します。たとえば、次のように入力します。

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

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

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

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

    選択肢は以下のとおりです。

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

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

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

14. 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

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

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

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

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

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

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

運用データを移行するには

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

2. cal-svr-base/SUNWics5/cal/sbin ディレクトリに移動します。

3. stop-cal コマンドを使用して Calendar Server を停止します。

   cal-svr-base/SUNWics5/cal/sbin/stop-cal

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

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

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

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

5. -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

6. エラーファイル (csmig.errors) で未解決のカレンダを確認し、「3.5.4 csmig ユーティリティーの移行の手順」 の 「3.5.4 csmig ユーティリティーの移行の手順」の計画に従って問題を解決します。

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

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

9. ics.conf ファイルで、必要に応じて次の構成パラメータを変更し、LDAP CLD プラグインを有効にします。

   • service.dwp.enable = "yes"

   • service.dwp.port = "59779"

   • csapi.plugin.calendarlookup = "yes"

   • 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 プラグインの構成パラメータの指定方法については、第 5 章「Calendar Server バージョン 6.3 での複数のマシンへのカレンダデータベースの分散の設定」を参照してください。

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

11. 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"

3.5.5 csmig のヒントとトラブルシューティング

ここでは、次のヒントとトラブルシューティングの例について説明します。

• 「3.5.5.1 csmig のドライランカレンダに表示されるカレンダの所有者が間違っています。」

• 「3.5.5.2 LDAP カレンダ検索を正常に実行できません。」

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

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

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

3.5.5.1 csmig のドライランカレンダに表示されるカレンダの所有者が間違っています。

問題の例

tchang:myCalendar という名前のカレンダの所有者がカレンダデータベース内の jsmith であるため、csmig のドライランのマッピングでは jsmith:tchang_myCalendar と表示されます。しかし、このカレンダの名前を tchang:myCalendar とし、tchang という所有者を割り当てるとします。

解決策の例

移行前に、cscal ユーティリティーを使用して、カレンダ tchang:myCalendar の所有者を tchang に変更します。これを実行すると、移行によってこのカレンダが tchang:myCalendar にマッピングされ、icsCalendarowned がユーザー ID tchang の LDAP エントリに追加されます。

3.5.5.2 LDAP カレンダ検索を正常に実行できません。

問題の例

移行後、LDAP カレンダ検索が有効になりますが、カレンダ検索ダイアログに何も結果が表示されないか、一部の結果だけが表示されます。

解決策の例

LDAP カレンダ検索を有効にすると、Calendar Server で検索に (&(objectclass=icscalendaruser)(icscalendarowned=*substr*)) を使用できるようになります。

次のフィルタを使用して LDAP データに対して 2 つの異なる検索を手動で実行し、出力を比較します。

• フィルタ (&(objectclass=icscalendaruser)(icscalendarowned=*substr*)) を使用した LDAP 検索

• フィルタ (icscalendarowned=*substr* ) を使用した LDAP 検索

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

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

問題の例

csmig のドライランマッピングファイルおよび出力ファイルに、カレンダ名の重複が記録されます。

たとえば、元のデータベースで、jsmith が次のカレンダを所有しているとします。

• basketball (5 個の予定あり)

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

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

出力ファイルには次の警告メッセージが記録されます。

Error modifying calendar properties, error=2

解決策の例

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

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

問題の例

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

解決策の例

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

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

問題の例

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

解決策の例

カレンダユーザーを移動するには、元のサーバーにある各ユーザーのカレンダをエクスポート (export) し、次にそのカレンダを 2 台目のサーバーにインポート (import) します。カレンダの移動後、元のサーバー上のカレンダを削除できます。カレンダの移動方法については、「15.6 ユーザーカレンダの管理」を参照してください。

3.6 csvdmig

csvdmig ユーティリティーは、複数ドメイン環境で使用するカレンダデータベースおよび LDAP ユーザーおよびグループエントリを準備します。デフォルトドメインしか使用しない場合でも、このユーティリティーを実行する必要があります。

非ドメイン環境を、Calendar Server 6.3 の複数ドメイン環境に移行する場合は、このユーティリティーを使用する前に必ず csmig を実行してください。

ここで説明する内容は次のとおりです。

• 「3.6.1 csvdmig の機能」

• 「3.6.2 csvdmig の構文」

• 「3.6.3 csvdmig の例」

3.6.1 csvdmig の機能

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

3.6.2 csvdmig の構文

csvdmig ユーティリティーの構文は次のとおりです。

csvdmig [-t DestinationDB]
         [-c ConfigFile]
         [-e ErrorFile]
         [-m MappingFile]
         migrate [DB|LDAP]

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

3.6.2.1 マッピングファイル

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

user1 user1@sesta.com
user2 user2@siroe.com
user3 user3@sesta.com
 ...
usern usern@siroe.com

3.6.2.2 出力先 DB

移行されるデータベースの場所。ユーティリティーは、ここにあるファイルをアップデートします。csvdmig ユーティリティーを使用する前に、このディレクトリをバックアップしてください。

-t オプションを指定しなければ、ユーティリティーは現在のディレクトリ (コマンド行で pwd を実行することで指定されたディレクトリ) の内容の移行を試行しますが、その結果は予期できません。

3.6.3 csvdmig の例

次に csvdmig の例を示します。

• デフォルト値を使用して、LDAP ディレクトリサーバーのデータを移行します。

  csvdmig migrate LDAP

• Calendar Server データベースを移行します。

  csvdmig -t targetDB -e errorFile -m mappingFile migrate

3.7 commdirmig

commdirmig ユーティリティーでは、認証サービスに Access Manager を使用できるように、LDAP データを Sun LDAP Schema バージョン 1 から Schema バージョン 2 に移行します。過去のインストールが Schema バージョン 2 をすでに使用している場合は、このユーティリティーを再度実行する必要はありません。

• 「3.7.1 commdirmig ユーティリティーの実行者」

• 「3.7.2 commdirmig ユーティリティーを実行するタイミング」

• 「3.7.3 commdirmig ユーティリティーのマニュアルの参照先」

• 「3.7.4 ユーティリティーの入手先」

3.7.1 commdirmig ユーティリティーの実行者

この移行ユーティリティーは、Schema バージョン 1 の LDAP データベースを Schema バージョン 2 に移行します。Access Manager ソフトウェアを認証に使用する場合は、このユーティリティーを実行して LDAP エントリを Schema バージョン 2 に変換する必要があります。

Access Manager を使用していない場合、Schema バージョン 2 は LDAP を使用するすべての Communications Suite 製品に最適な LDAP モードであるため、LDAP データの移行を検討することをお勧めします。

設定用の LDAP ディレクトリが個別に用意されている場合は、認証用の LDAP だけでなく、その LDAP に対しても commdirmig を実行する必要があります。

3.7.2 commdirmig ユーティリティーを実行するタイミング

カレンダおよび LDAP データベースを、旧バージョンの Calendar Server ソフトウェアから Calendar Server ソフトウェアのバージョン 6.3 に移行するために必要なほかのすべての移行ユーティリティーを実行したあとに、commdirmig を実行します。

3.7.3 commdirmig ユーティリティーのマニュアルの参照先

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

3.7.4 ユーティリティーの入手先

commdirmig ユーティリティーは、Communications Suite インストーラからインストールする Delegated Administrator にバンドルされています。

ユーティリティーのパッチもテクニカルサポートから入手できます。