パート II インストール後の設定

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

• 第 2 章「ディレクトリ準備スクリプト (comm_dssetup.pl)」

• 第 3 章「Calendar Server 設定プログラム (csconfigurator.sh)」

• 第 4 章「データベース移行ユーティリティー」

第 2 章 ディレクトリ準備スクリプト (comm_dssetup.pl)

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

1. ディレクトリ準備スクリプト (comm_dssetup.pl)ディレクトリ準備スクリプトは、Calendar Server 6 および Messaging Server 6 用に Directory Server を設定します。

   このスクリプトは、新しい LDAP スキーマ、インデックス、および設定データを設定することによって、Directory Server を準備します。

2. Calendar Server 設定プログラム (csconfigurator.sh)

   Calendar Server 設定プログラムは Calendar Server を設定します。詳細は、第 3 章「Calendar Server 設定プログラム (csconfigurator.sh)」を参照してください。

この章では、ディレクトリ準備スクリプトと次の内容について説明します。

• 「ディレクトリ準備スクリプトのインストール」

• 「ディレクトリ準備スクリプトの実行の前に」

• 「ディレクトリ準備スクリプトの実行」

• 「スキーマファイルの手動更新」

• 「LDAP スキーマディレクトリ内の OID 競合の解決」

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

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

ディレクトリ準備スクリプトのインストール

以前のバージョンの Java Enterprise System では、このユーティリティーは Messaging Server と Calendar Server にバンドルされていたため、個別にインストールする必要はありませんでした。しかし、Java Enterprise System 2005Q1 から、このスクリプトは個別にインストールできる共有コンポーネントになりました。

ディレクトリ準備スクリプトをインストールするには、次のどちらかの方法を選択します。

• Java Enterprise System インストーラ: コンポーネントの選択パネルで、「ディレクトリ準備スクリプト」を選択します。「Directory Server」を選択すると、ディレクトリ準備スクリプトも自動的に選択されます。

• 以前のバージョンの Java Enterprise System からアップグレードする場合、Java Enterprise System のインストールプログラムを使用しないときは、次のパッチをダウンロードします。

インストールが終わると、ディレクトリ準備スクリプトが次のディレクトリに作成されています。

ディレクトリ準備スクリプトの実行の前に

ここでは、ディレクトリ準備スクリプトを実行する前に理解しておく必要のある情報が記載されています。ここで説明する内容は次のとおりです。

• 「ディレクトリ準備スクリプトの機能」

• 「Directory Server に関する注意事項」

• 「収集する必要がある情報」

• 「スキーマ選択について」

• 「Access Manager に関する注意事項」

• 「属性のインデックス」

ディレクトリ準備スクリプトの機能

ディレクトリ準備スクリプトは、次に示す 3 つの手順で処理を行います。

ディレクトリ準備スクリプトの高レベルの手順

手順

1. ユーティリティーオプションで選択された結果を収集します。

   この手順で必要な情報については、「収集する必要がある情報」を参照してください。

2. LDAP ディレクトリの変更に使用されるオプションからシェルスクリプトと LDIF ファイルを生成します。ディレクトリサーバーに Sun 製品を使用していない場合、または Directory Server をカスタマイズしている場合は、シェルスクリプトを実行せずにここで処理を停止します。詳細は、このあとの 「Directory Server に関する注意事項」を参照してください。

3. オプションの選択結果から作成されたシェルスクリプトを実行します。それに応じて LDAP が変更されます。

   このユーティリティーでは、各手順の終わりに、続行するかどうかのメッセージが表示されます。3 番目の手順まで、LDAP ディレクトリに対する変更は行われません。

Directory Server に関する注意事項

次に、LDAP ディレクトリに関する注意事項をいくつか示します。

• ディレクトリ準備スクリプトを実行する前に、ディレクトリサーバーのインストール、設定、および実行を行う必要があります。

• ディレクトリ準備スクリプトは、ユーザーのディレクトリサーバーと同じマシンで実行する必要があります。

• ディレクトリ準備スクリプトは、ディレクトリサーバーが存在するすべてのマシンで実行する必要があります。

• 将来、別のマシン (レプリカなど) を追加する場合は、そのマシンに対しても ディレクトリ準備スクリプト を実行します。

• Calendar Server 6 2005Q4 でサポートされる LDAP ディレクトリサーバーのリストについては、『Sun Java System Communications Services 2005Q4 Release Notes』の第 1 章「Sun Java System Calendar Server 6 2005Q4 Release Notes」を参照してください。

• LDAP ディレクトリをカスタマイズした場合は、次の点に注意してください。

  • 属性にインデックスを作成した場合は、ディレクトリ準備スクリプトの実行後、これらの属性のインデックスをふたたび作成する必要がある場合があります。

  • ほかの .ldif ファイル (スキーマ定義) を追加している場合は、影響を受けることはないため、何もする必要はありません。ただし、ディレクトリ準備スクリプトを実行する前に、カスタムスキーマ定義ファイルをバックアップしてください。

  • 上記の 2 つのカスタマイズも含め、どのようなカスタマイズを行う場合にも、スクリプトを生成したあと、実際に LDAP ディレクトリを更新する前に、ディレクトリ準備スクリプトを停止します。次に、スクリプトを調べて、この推奨アクションがどのように LDAP ディレクトリに影響を与えるかを評価します。LDAP に対してスクリプトを実行する前に、カスタマイズ内容を保護するために必要だと思われるあらゆるアクションを行います。

• ディレクトリサーバーに Sun 製品を使用していない場合、Calendar Server をもっとも簡単に配備する方法は、ディレクトリサーバーを Sun Java System Directory Server にアップグレードすることです。

  Directory Server のインストールと設定については、http://docs.sun.com/coll/1316.1 を参照してください。

  別の方法として、ディレクトリ準備スクリプト によって生成されたスクリプトを使用して、実際にスクリプトを実行することなく、Sun 以外の LDAP ディレクトリに対して必要な更新内容を調べることができます。

収集する必要がある情報

ディレクトリ準備スクリプトの最初の手順では、Directory Server に関する情報が必要になります。次の表に示す情報を収集して、このための準備をします。この情報を記録しておくために、付録 A 「ディレクトリ設定のワークシート」 を使用してください。

スキーマ選択について

Calendar Server は次のスキーマ選択をサポートしています。

• Sun LDAP Schema 1

  ディレクトリ準備スクリプトスキーマバージョンの選択項目 1 に対応します。

• Sun LDAP Schema 2 互換モード

  スキーマバージョンの選択項目 1.5 に対応します。

• Sun LDAP Schema 2 ネイティブモード

  スキーマバージョンの選択項目 2 に対応します。

使用するスキーマを決めかねている場合、詳細は、『Sun Java Enterprise System 技術の概要』、『Sun Java Enterprise System 2005Q4 Installation Guide for UNIX』、および『Sun Java System Communications Services 6 2005Q4 Schema Migration Guide』を参照してください。

次の表に、インストールに使用するスキーマバージョンの選択理由について簡単にまとめたガイドラインを示します。

Access Manager に関する注意事項

Schema 2 を使用している場合は、Access Manager をインストールして設定する必要があります。

ユーザーの管理に Access Manager コンソールを使用しないでください。ユーザーの管理方法については、第 14 章「ユーザーとリソースの管理」を参照してください。

属性のインデックス

属性にインデックスを作成すると、検索アルゴリズムのパフォーマンスが向上します。スクリプトで属性にインデックスを作成できます。インデックスを作成することにした場合は、スクリプトによって Calendar Server だけでなく Messaging Server と Communications Express にもインデックスが追加されます。したがって、1 つの製品に対してインデックスの作成を行えば、ほかの製品に対して再度インデックスを作成する必要はありません。実際、同じ属性に再度インデックスを作成しようとしても、何も起こりません。スクリプトは、インデックスが存在しない場合にだけ、インデックスが作成される属性ごとに db2index を呼び出します。

次の表に、ディレクトリ準備スクリプトによってインデックスが作成されるすべての属性をサフィックスのカテゴリ別に示します。また、属性ごとに作成されるインデックスのタイプも示します。Directory Server のインデックス作成については、http://docs.sun.com/coll/1316.1を参照してください。

このほかにもインデックスを独自に追加する場合は、インデックスの追加手順について Directory Server のマニュアルを参照してください。

ディレクトリ準備スクリプトの実行

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

• 「ディレクトリ準備スクリプトを実行するには」

• 「サイレントモードで実行するには」

• 「対話型モードで実行するには」

ディレクトリ準備スクリプトを実行するには

手順

1. Directory Server がインストールされているサーバー上で、スーパーユーザー (root) としてログインするか、スーパーユーザーになります。

2. 必要に応じて Directory Server を起動します。

3. /opt/SUNWcomds/sbin ディレクトリに移動します。

   あるいは、必要に応じて、.zip ファイルを /opt/SUNWcomds/lib で入手します。

4. サイレントモードまたは対話型モードで、ディレクトリ準備スクリプトを実行します。詳細な手順については、「ディレクトリ準備スクリプトの実行」または 「ディレクトリ準備スクリプトの実行」を参照してください。

   このスクリプトを実行するには、Java Enterprise System インストーラによって自動的にインストールされる共有コンポーネントとして組み込まれているバージョンの Perl を使用します。インストールが終わると、スクリプトは次のディレクトリに保存されています。

   ds_svr_base/bin/slapd/admin/bin/perl

サイレントモードで実行するには

サイレントモードでディレクトリ準備スクリプトを実行するには、「comm_dssetup.pl の構文」に示す構文を使って、オプションの文字列が付いた Perl コマンドを実行します。オプション引数はすべて必須です。表 2–1 にそれらのオプションを示します。

このユーティリティーによって、次の LDIF ファイルとシェルスクリプトが作成され、LDAP ディレクトリのインデックスとスキーマが更新されます。

/var/tmp/dssetup_timestamp.ldif 
/var/tmp/dssetup_timestamp.sh

指定したオプションの値に応じて、ユーティリティーが新しいスクリプトを実行して Directory Server を更新するかどうかが決まります。更新を行わないようにした場合は、スクリプトを確認し、必要な変更を行ってから、あとで実際の更新を行うことができます。

comm_dssetup.pl の構文

サイレントモードで実行するすべてのオプションを次に示します。

perl comm_dssetup.pl
    -i yes|no
    -R yes|no
    -c DirectoryServerRoot
    -d DirectoryInstance
    -r DCTreeSuffix
    -u UserGroupSuffix
    -s yes|no
    -D DirectoryManagerDN
    -w DirectoryManagerPassword
    -b yes|no -t 1|1.5|2
    -m yes|no
   [-S PathtoSchemaFiles]
               

対話型モードで実行するには

対話型モードでディレクトリ準備スクリプトを実行するには、引数なしでスクリプトを実行し、表示された質問に対して選択項目を入力します。

次の番号付きのリストは、対話型モードのスクリプトの使用方法をパネルごとに示しています。

手順

1. 「最初の画面」パネル

   # cd /opt/SUNWcomds/sbin # ./comm_dssetup.pl Welcome to the Directory Server preparation tool for Sun Java System Communications Services. (Version 6.3 Revision 0.1) This tool prepares your directory server for use by the communications services which include Messaging, Calendar and their components. The logfile is /var/tmp/dssetup_YYYYMMDDHHSS Do you want to continue [y]:

   Enter キーを押して続行するか、no と入力してから Enter キーを押して終了します。

2. 「Directory Server のインストールルート」パネル

   Please enter the full path to the directory where the Sun Java System Directory Server was installed. Directory server root [/var/opt/mps/serverroot]

   Directory Server のインストールルートの場所を指定します。デフォルトをそのまま使用する場合は、Enter キーを押します。

3. 「Directory Server のインスタンス」パネル

   マシンに Directory Server の複数のインスタンスがある場合は、それらが表示され、1 つを選択するように求められます。

   Please select a directory server instance from the following list: [1] slapd-varrius Which instance do you want [1]:

   選択項目に対応する番号を入力し、Enter キーを押します。デフォルトをそのまま使用する場合は、番号を入力せずに、Enter キーを押します。

4. 「Directory Manager の識別名 (DN)」パネル

   このパネルには、Directory Manager DN を入力する部分と Directory Manager のパスワードを入力する部分があります。

   1. 最初に、Directory Manager の DN (識別名) の入力が求められます。

      Please enter the directory manager DN [cn=Directory Manager]:

      Directory Manager DN (デフォルトは cn=Directory Manager) は組織ツリー内のユーザーおよびグループのデータに責任を持つ管理者です。このスクリプトで指定する Directory Manager DN が、Calendar Server 設定や Directory Server に設定したものと同じ DN であることを確認してください。Directory Manager DN を入力します。

      デフォルトをそのまま使用する場合は、Enter キーを押します。

   2. Directory Manager のパスワードの入力が求められます。

      Password:

      Directory Manager のパスワードを入力し、Enter キーを押します。

      Directory Server が実行しており、ポート 389 (デフォルトポート) で待機しているかどうかが確認されます。

      成功すると、次の例に示すように、検出されたバージョンが表示されます。

      Detected DS version 5.2

      成功しなかった場合は、Directory Server が実行しているか、またはポート 389 (デフォルト) で待機していることが検出されなかったことが伝えられます。続行する前にこの問題を修正するように指示されます。スクリプトは終了します。次にこの出力の例を示します。

      Directory Server not running or not listening to port 389. Detected DS version 0.0 Please correct the problem and re-run this script.

5. 「ユーザーおよびグループの Directory Server」パネル

   Will this directory server be used for users/groups [Yes]:

   このディレクトリのインスタンスが設定データの格納にのみ使用される場合は No を入力します。デフォルトをそのまま使用する場合は Enter キーを押します。

   No を入力した場合は、ユーザーおよびグループのデータを格納するディレクトリインスタンスに対してもこのスクリプトを実行する必要があります。この作業は、設定プログラム csconfigurator.sh を実行する前に行ってください。

   回答が Yes の場合は、組織ツリーに対するユーザーおよびグループベースのサフィックスを指定する必要があります。

6. 「ユーザーおよびグループベースのサフィックス」パネル

   Please enter the Users/Groups base suffix [o=usergroup]:

   ユーザーおよびグループベースのサフィックスは、LDAP 組織ツリーの最上位のエントリです。必ず、ここで選択したサフィックスが Directory Server、Calendar Server、および Access Manager に対して指定したサフィックスと同じになるようにしてください。

7. 「スキーマタイプ」パネル

   There are 3 possible schema types: 1-schema 1 for systems with Calendar or Messaging 5.x data 1.5-schema 2 compatibility for systems with Calendar or Messaging 5.x data that has been converted with the Schema Migration Utility commdirmig 2-schema 2 native for systems using Access Manager Please enter the Schema Type (1, 1.5, 2) [1]:

   スキーマタイプを入力します。デフォルトをそのまま使用する場合は、Enter キーを押します。

   ---

   注 –

   Schema 2 (オプション 1.5 または 2) を使用する場合は、Access Manager のインストールと設定を行う必要があります。そうしないと、ディレクトリ準備スクリプトが終了します。ディレクトリ準備スクリプトを実行する前に、Access Manager をインストールする必要があります。

   ---

8. 「ドメインコンポーネント (DC) ツリーベースのサフィックス」パネル

   Schema 1 または Schema 2 の互換モードを選択した場合は、DC ツリーベースのサフィックスを入力するように求められます。Schema 2 ネイティブモードを選択した場合は、このメッセージは表示されません。

   Please enter the DC Tree base suffix [o=internet]:

   前述した「スキーマタイプ」パネルで Schema 1 または Schema 2 の互換モードを選択した場合は、DC ツリーベースのサフィックスを入力するように求められます。Schema 2 ネイティブモードを選択した場合は、このメッセージは表示されません。

   DC ツリーはローカル DNS 構造をミラー化し、ユーザーおよびグループのデータエントリを含む組織ツリーへのインデックスとして、システムによって使用されます。DC ツリーベースのサフィックスは、DC ツリーの最上位エントリ名です。

   サフィックスを入力します。デフォルトをそのまま使用する場合は、Enter キーを押します。

9. 「質問」パネル

   この次のパネルでは、LDAP への更新に関する一連の質問が表示されます。

   1. 「スキーマファイルの更新」

      この時点で、プログラムはスキーマの要素が正しいかどうかを確認します。スキーマに足りない要素があると、次のメッセージを表示します。

      Detected bad schema elements in 99user.ldif. It is recommended that you update the schema. Do you want to update the schema files [yes]:

      必要な新しい要素をスキーマに追加する場合は、Yes と回答します。新しいバージョンの Calendar Server または Messaging Server をインストールするたびに、新しいスキーマファイルでディレクトリを更新する必要があります。

      ここでスキーマファイルを更新しない場合は、No と回答します。

   2. 「新しいインデックスの設定」

      前の手順でスキーマを更新するようにした場合は、新しいインデックスを設定するかどうか尋ねられます。属性にインデックスを作成する方法については、「属性のインデックス」を参照してください。

      Do you want to configure new indexes [yes]:

      インデックスの作成を承認する場合は、Enter キーを押します。

      すでに同じ属性に対してインデックスの作成手順を実行している場合は、no を入力します。

   3. 「インデックスの再生成」

      すぐにインデックスを作成するか、あとで作成するかを選択できます。あとでインデックスを作成することを選択した場合は、都合のいいときにインデックスの作成を有効にしてスクリプトを再実行します。インデックス作成には長い時間がかかる可能性がありますが、Directory Server はその間も機能しています。つまり、インデックスの作成中も読み取り専用モードにはなりません。

      Reindex now [yes]?

      あとでインデックスの作成を行いたい場合は、no を入力します。そうでない場合は、Enter キーを押して、デフォルトをそのまま使用します。

10. 「設定の概要」パネル

    ディレクトリ準備スクリプトは Directory Server 設定を更新する前に、設定の概要を表示し、続行するかどうかを質問します。

    Here is a summary of the settings that you chose: Server Root : /var/opt/mps/serverroot/ Server Instance : slapd-varrius Users/Groups Directory : yes Update Schema : yes Schema Type : 1 DC Root : o=internet User/Group Root : dc=red,dc=sesta,dc=com Add New Indexes : yes Reindex New Indexes Now : yes Directory Manager DN : cn=Directory Manager Now ready to generate a shell script and ldif file to modify the Directory. No changes to the Directory Server will be made this time. Do you want to continue [Y]:

    「ディレクトリ準備スクリプトの実行」で Schema 2 ネイティブモードを選択した場合、DC ルートは「User/Group Root」で入力した値と同じになります。

    設定を変更するには、no と入力してスクリプトを再実行します。

    続行する場合は Enter キーを押します。ディレクトリ準備スクリプトによって、LDIF ファイルとシェルスクリプトが作成されます。作成されるファイルの名前は次のようになります。

    /var/tmp/dssetup_timestamp.ldif /var/tmp/dssetup_timestamp.sh

    続行すると、プログラムの実行に従って、メッセージが表示されます。次に、出力の例を示します。

    Generating files... Checking to see if Suffixes need to be added Checking to see that uid uniqueness plugins are turned off Adding indexes Adding Indexes for User/group Tree (backend:userRoot) Checking indexes for member No new indexes required Checking indexes for mailAlternateAddress No new indexes required Checking indexes for mail No new indexes required Checking indexes for mailEquivalentAddress No new indexes required Checking indexes for cosspecifier No new indexes required Adding Indexes for DC Tree (backend:internetdb2) Checking indexes for inetCanonicalDomainName No new indexes required Checking indexes for inetDomainBaseDN No new indexes required Adding Indexes for PAB Tree (backend:pabdb2) Checking indexes for memberOfPAB No new indexes required Checking indexes for icsCalendar No new indexes required Checking indexes for un No new indexes required Checking indexes for memberOfPABGroup No new indexes required Checking indexes for icsCalendarOwned No new indexes required Checking indexes for memberOfManagedGroup No new indexes required Adding Indexes for New PAB Tree (backend:PiServerDbdb2) Checking indexes for MemberOfPiBook No new indexes required Checking indexes for MemberofPiGroup No new indexes required Checking indexes for displayname No new indexes required Checking to see if DN needs to be created for suffixes Generating ldif for installer metadata Generating ldif for Adding schema for installer metadata Generating ldif for updating DN for cn=CommServers,o=comms-config The following files have been created: /var/tmp/dssetup_20041209114027.sh /var/tmp/dssetup_20041209114027.ldif Running /var/tmp/dssetup_20041209114027.sh will make changes to the Directory. You can run this file now or at a later time Ready to execute the script now.

11. 「スクリプトの実行」

    Do you want to continue [yes]:

    デフォルトの設定 (yes) をそのまま使用する場合は、Enter キーを押します。dssetup_timestamp.sh スクリプトが LDAP ディレクトリに対して実行されます。スクリプトを今すぐ実行しない場合は、No を入力して終了します。終了した場合は、あとで /var/tmp/dssetup_ timestamp.sh スクリプトを実行できます。

    次に、スクリプトの実行中に生成されるテキスト出力の例を示します。

    Running /var/tmp/dssetup_20041209114027.sh -D "cn=Directory Manager" -j /var/tmp/dssetup_20041209114027.pw Stopping Directory Server Updating Schema files... Copying 20subscriber.ldif Copying 50ns-delegated-admin.ldif Copying 50ns-mail.ldif Copying 50ns-mlm.ldif Copying 50ns-msg.ldif Copying 50ns-value.ldif Copying 55ims-ical.ldif Copying 56ims-schema.ldif Copying 70sun-schema2.ldif Copying 71sun-am.ldif Copying 60iplanet-calendar.ldif Copying 50ns-iabs.ldif Copying 98ns-dummy-uwc.ldif Copying 70delgated-admin.ldif Copying /var/tmp/99user_20041209114027.ldif to /var/opt/mps/serverroot/slapd-varrius/config/schema/99user.ldif Starting Directory Server Applying ldif file /var/tmp/dssetup_20041209114027.ldif modifying entry cn=schema modifying entry cn=schema modifying entry cn=CommServers,o=comms-config Done Applying ldif file /var/tmp/dssetup_20041209114027.ldif rejects to /var/tmp/dssetup_20041209114027.ldif.rej status = 0 Successful Completion. Consult /var/tmp/dssetup_20041209114027.log for details

スキーマファイルの手動更新

なんらかの理由で、ディレクトリ準備スクリプトが生成したスクリプトを実行しないことにした場合は、次の指示に従って、Sun Java System Directory Server のスキーマファイルを手動で更新できます。

LDAP ディレクトリのスキーマを手動で更新し、あとで Calendar Server をアップグレードした場合、LDAP サーバーのスキーマをもう一度手動で更新する必要があります。スキーマを手動で更新したあとは、Calendar Server によってスキーマが自動的に更新されることはありません。

LDAP ディレクトリを手動で更新するには

手順

1. Calendar Server 6 2005Q4 をインストールします。

2. Calendar Server が動作している場合は、停止します。

3. Directory Server が動作している場合は、停止します。

4. 60iplanet-calendar.ldif ファイルを、ディレクトリサーバーが動作しているマシン上の次のディレクトリにコピーします。

   dir_svr_base/slapd-hostname/config/schema

   dir_svr_base は Directory Server のインストールディレクトリを示し、hostname はマシンを識別します。

5. 属性にインデックスを作成する場合は、設定プログラムと同じように、この時点で行います。設定プログラムによってインデックスが作成される属性のリストについては、「属性のインデックス」を参照してください。

6. Directory Server を再起動します。オブジェクト識別子 (OID) に関するエラーが発生した場合は、「LDAP スキーマディレクトリ内の OID 競合の解決」を参照してください。

7. csconfiguration.sh プログラムを実行して、Calendar Server を設定します。

   Calendar Server を設定する方法については、第 3 章「Calendar Server 設定プログラム (csconfigurator.sh)」を参照してください。

LDAP スキーマディレクトリ内の OID 競合の解決

LDAP スキーマディレクトリで OID が競合している場合、Directory Server はどの OID を使用するかを判断できず、エラーメッセージを返します。たとえば、次のメッセージは icsCalendarUser オブジェクトクラスの OID の競合を示します。

[24/Apr/2004:23:45:28 -0700] dse - 
The entry cn=schema in file 99user.ldif is invalid, 
error code 20 (Type or value exists) - object class icscalendaruser: 
   The name does not match the OID. 
   Another object class is already using the name or OID.
[24/Apr/2004:23:45:28 -0700] dse - 
Please edit the file to correct the reported problems 
and then restart the server.

この問題は Calendar Server 6 2005Q4 をインストールしていて、LDAP サーバースキーマの 99user.ldif ファイルを動的に更新する旧バージョンの Calendar Server も削除していない場合に発生する可能性があります。

OID の競合を解決するには、次の 2 つの手順を実行します。

1. 99user.ldif ファイルの編集と古い OID の削除です。Calendar Server 6 2005Q4 について、問題を起こす可能性のある特定の OID を次の表に示します。

   オブジェクトクラス	古い OID	新しい OID
   icsCalendarUser	2.16.840.1.113730.3.2.141	1.3.6.1.4.1.42.2.27.9.2.44
   icsCalendarResource	2.16.840.1.113730.3.2.143	1.3.6.1.4.1.42.2.27.9.2.45
   icsCalendarDomain	2.16.840.1.113730.3.2.144	1.3.6.1.4.1.42.2.27.9.2.4

2. 99user.ldif ファイルを編集したあとで、Directory Server を再起動します。

第 3 章 Calendar Server 設定プログラム (csconfigurator.sh)

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

1. comm_dssetup.pl

   第 2 章「ディレクトリ準備スクリプト (comm_dssetup.pl)」の説明に従って、LDAP ディレクトリサーバーを設定します。

2. csconfigurator.sh

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

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

• 「設定情報の収集」

• 「csconfigurator.sh の実行」

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

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

設定情報の収集

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

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

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

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

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

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

• 「Directory Manager のオプション」

• 「Calendar Server 管理者」

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

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

• 「Calendar Server の起動」

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

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

LDAP サーバーのオプション

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

Directory Manager のオプション

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

Calendar Server 管理者

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

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

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

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

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

Calendar Server の起動

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

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

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

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

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]	入力値の設定に状態ファイルを使用します。

   たとえば、コマンド行モードで設定スクリプトを実行し、入力を状態ファイルに保存しない場合は、次のようにします。

   ./csconfigurator.sh -nodisplay

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

   ---

   注 –

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

   ---

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

手順

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

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

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

   ./csconfigurator.sh

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

   • 「開始パネル」

   • 「「管理、ユーザー設定、および認証」パネル」

   • 「「メールと電子メールアラーム」パネル」

   • 「「ランタイム設定」パネル」

   • 「「設定およびデータファイルの格納先ディレクトリ」パネル」

   • 「「アーカイブおよびホットバックアップの設定」パネル」

   • 「「設定準備が完了しました」パネル」

   • 「「設定の概要」パネル」

   ---

   注意 –

   設定プログラムはシングルドメインを設定できるだけです。仮想ドメイン、ホストされたドメインなど複数のドメインを使用する場合は、Delegated Administrator コマンド行ユーティリティーを使用してドメインを追加する必要があります。

   ---

開始パネル

図 3–1 Calendar Server 設定プログラムの開始パネル

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

「管理、ユーザー設定、および認証」パネル

図 3–2 「管理、ユーザー設定、および認証」設定パネル

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

LDAP サーバーのホスト名

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

LDAP サーバーのポート

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

Directory Manager DN

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

Directory Manager のパスワード

Directory Manager のパスワード。デフォルト: なし

ベース DN

検索の開始点として使用する LDAP ディレクトリ内のエントリ。デフォルト: o=currentdomain

これは必要に応じて変更できます。comm_dssetup.pl によって作成されたルートサフィックスを取得するには、「取得する」をクリックします。このようにして取得した baseDN は、現在の設定から作成される一例にすぎません。baseDN の取得に何を使用するかにかかわらず、LDAP コンテンツとの整合性がとれている必要があります。

---

注 –

「取得する」をクリックする前に、Directory Manager DN およびパスワードを入力してディレクトリサーバーの認証を行う必要があります。

---

Calendar Server 管理者のオプション

管理者のユーザー ID

Calendar Server 管理者のユーザー ID。 上記の LDAP ディレクトリサーバー内のユーザーである必要があります。デフォルト: calmaster

管理者のパスワード

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

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

「メールと電子メールアラーム」パネル

図 3–3 「メールと電子メールアラーム」設定パネル

電子メールアラーム

サーバーに問題が生じたときに Calendar Server が Calendar Server 管理者に電子メールのアラームメッセージを送信するかどうかを指定します。デフォルト: 「有効」

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

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

SMTP ホスト名

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

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

「ランタイム設定」パネル

図 3–4 「ランタイム設定」パネル

サービスポート

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

最大セッション

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

最大スレッド

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

サーバープロセスの数

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

ランタイムユーザー ID

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

ランタイムグループ ID

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

Calendar Server 起動オプション

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

• インストールが成功したら起動する

  インストールに成功したあと、Calendar Server が自動的に起動するかどうかを指定します。デフォルト: チェックマークあり

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

  システムの起動後、Calendar Server が自動的に起動するかどうかを指定します。デフォルト: チェックマークあり

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

「設定およびデータファイルの格納先ディレクトリ」パネル

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

図 3–5 「設定およびデータファイルの格納先ディレクトリ」設定パネル

設定ディレクトリ

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

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

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

ログディレクトリ

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

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

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

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

「アーカイブおよびホットバックアップの設定」パネル

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

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

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

図 3–6 「アーカイブおよびホットバックアップの設定」パネル

アーカイブを有効

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

アーカイブディレクトリ

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

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

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

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

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

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

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

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

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

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

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

「設定準備が完了しました」パネル

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

図 3–7 「設定準備が完了しました」パネル

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

「設定の概要」パネル

図 3–8 「設定の概要」パネル

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

第 4 章 データベース移行ユーティリティー

以前のバージョンの Calendar Server (5.11 以前) を使用していた場合は、Calendar Server をインストールし、インストール後の設定を行ったあとで、コンポーネントデータベースと LDAP データベースの移行が必要になることもあります。

この章の 「権限ユーティリティーの選択」を参照すると、適切なユーティリティーを選択する場合に役立ちます。

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

• 「インストール後のデータベース移行ユーティリティー」

• 「権限ユーティリティーの選択」

• 「csmig」

• 「csvdmig」

• 「commdirmig」

インストール後のデータベース移行ユーティリティー

以前にインストールした Calendar Server 5.1.1 のカレンダデータベースと LDAP データベースのエントリがある場合は、Sun Java System Calendar Server をインストールしたあとで、次のユーティリティーを指定された順序で実行します。

1. cs5migrate

   カレンダデータベースを Calendar Server バージョン 5 の形式からバージョン 6 の形式に移行します。これらのユーティリティーはテクニカルサポートからダウンロードして入手できます。

   Connector for Microsoft Outlook の使用を計画しており、複数のコンポーネントが定期的に発生する予定の場合は、cs5migrate_recurring を使用します。このユーティリティーにより、定期的コンポーネントごとにマスターレコードと例外が作成されます。

   定期的コンポーネントが既存のデータベースに格納されていない場合、または格納されていても Connector for Microsoft Outlook を使用する予定がない場合は、cs5migrate を使用します。

   cs5migrate と cs5migrate_recurring のどちらも、テクニカルサポートサイトからのみ入手できます。これらは製品に同梱されていません。

2. 「csmig」

   Calendar Server 6 データベース内の各カレンダに所有者を割り当て、必要に応じて各カレンダ ID (calid) を所有者にマッピングします。これによって、ホストされた (仮想) ドメインおよび LDAP カレンダ検索データベース (CLD) プラグインがサポートされます。このユーティリティーは Calendar Server に同梱されています。cs5migrate のあと、csvdmig の前にこのユーティリティーを実行します。

3. 「csvdmig」

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

4. 「commdirmig」

   Access Manager 6.1 以上で使用するために、LDAP データを Schema 1 から Schema 2 に移行します。このユーティリティーは Access Manager に同梱されています。

権限ユーティリティーの選択

ユーティリティーには多数の選択肢があるため、次の図を参照して、どのユーティリティーを実行するかを選択してください。

図 4–1 実行する移行ユーティリティーの選択

csmig

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

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

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

• 「csmig の機能」

• 「csmig の要件」

• 「csmig の構文」

• 「csmig 移行の手順」

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

csmig の機能

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

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

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

• 「LDAP 属性を更新する」

カレンダを移行する

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

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

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

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

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

• 所有者がいないリソースカレンダは、-r オプションによって csmig に渡されるリソースユーザーが所有します。

• リソースカレンダの名前にコロン (:) が含まれる場合、移行された名前に含まれるコロンが 1 つのみになるように、それらのコロンは下線に変換されます。

  たとえば、所有者が bkamdar の football というカレンダ名は、bkamdar:football に変換されます。所有者が bkamdar の tchang:soccer というカレンダ名は、bkamdar:tchang_soccer に変換されます。所有者が admin1 の auditorium:room1 というカレンダ名は、admin1:auditorium_room1 に変換されます。

LDAP 属性を更新する

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

csmig の要件

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

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

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

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

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

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

csmig の構文

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

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

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

csmig 移行の手順

Calendar Server 6 のインストールと設定が終わったら、csmig を実行して既存の Calendar Server と LDAP データを移行する必要があります。LDAP データの移行は、LDAP CLD プラグインを正常に動作させるために必要です。csmig を使用してカレンダデータを移行する場合は、次の手順を実行します。

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

手順

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

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

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

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

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

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

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

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

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

手順

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

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/testcsdb/ ディレクトリに移行されます。

   ./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) で未解決のカレンダを確認し、「csmig 移行の手順」の 「csmig 移行の手順」の計画に従って問題を解決します。

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

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

9. 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 キャッシュディレクトリの場所を指定します。デフォルトは、/var/opt/SUNWics5/csdb/cld_cache です。

     LDAP CLD プラグインの設定パラメータの指定方法については、第 6 章「複数のマシンへのカレンダデータベースの分散の設定」を参照してください。

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"

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

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

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

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

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

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

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

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

問題の例

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

解決策の例

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

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

問題の例

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

解決策の例

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

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

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

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

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

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

問題の例

csmig のドライランマッピングファイルおよび出力ファイルに、カレンダ名の重複が記録されます。たとえば、元のデータベースで、jsmith が次のカレンダを所有しているとします。

• basketball (5 個の予定あり)

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

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

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

Error modifying calendar properties, error=2

解決策の例

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

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

問題の例

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

解決策の例

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

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

問題の例

カレンダユーザーを 1 台のバックエンドサーバーから別のバックエンドサーバーに移動します。

解決策の例

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

csvdmig

csvdmig ユーティリティーでは、ホストされた (または仮想) ドメインを使用するサイトの Calendar Server データベースおよび LDAP ディレクトリサーバーデータベースが変更されます。

ホストされていない環境から移動している場合は、このユーティリティーを使用する前に必ず csmig を実行してください。

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

• 「csvdmig の機能」

• 「csvdmig の構文」

• 「csvdmig の例」

csvdmig の機能

csvdmig ユーティリティーでは、次のようにドメイン名をユーザー ID に追加します。

• カレンダ ID (calid) の形式が変更されます。

  変更前: userid[:calendar-name]

  変更後: userid@domain[:calendar-name]

• ACL (アクセス制御リスト) のアクセス規則が変更されます。

  変更前: userid

  変更後: userid@domain

• Calendar Server 属性の LDAP ディレクトリサーバーのユーザーエントリが次のように変更されます。

  userid[:calendar-name] から userid@domain[:calendar-name]。

• カレンダデータベースに含まれる予定と作業の所有者フィールドと出席者フィールドを更新します。

  例: ドメイン sesta.com の jsmith が予定の所有者である場合、新しい所有者フィールドには jsmith@sesta.com が入ります。

csvdmig ユーティリティーでは、データベースと LDAP ディレクトリに適切な更新を行います。つまり、移行データベースを個別に作成するのではなく、変換中のデータベースを変更します。したがって、念のため、データベースと LDAP ディレクトリのスナップショットに対して csvdmig を実行してください。

csvdmig の構文

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

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

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

マッピングファイル

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

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

出力先 DB

このユーティリティーでは、移行されたファイルは新しい DestinationDB には移動されません。-t オプションを指定する場合は、csvdmig を実行する前に、移行するデータベースファイルをそのディレクトリにコピーしておく必要があります。

-t オプションを使用しないと、ユーティリティーによって作業用ディレクトリ内のファイルが移行されるため、予期しない結果が発生します。

csvdmig の例

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

  csvdmig migrate LDAP

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

  csvdmig -t targetDB -e errorFile -m mappingFile migrate

commdirmig

commdirmig ユーティリティーでは、認証サービスに Access Manager を使用できるように、LDAP データを Sun LDAP Schema 1 から Schema 2 に移行します。

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

• 「ユーティリティーを実行する必要がある場合」

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

• 「マニュアルの参照先」

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

ユーティリティーを実行する必要がある場合

以前に Messaging Server 5 または Calendar Server 5 のバージョンを使用していた場合は、LDAP エントリが Schema 1 にフォーマットされています。新しい Calendar Server 6 2005Q4 環境で、認証に Access Manager を使用する場合は、このユーティリティーを実行して LDAP エントリを Schema 2 形式に変換する必要があります。

Access Manager を使用していない場合、Schema 2 は LDAP を使用するすべての Java Enterprise System 製品に最適な LDAP モードであるため、LDAP データの移行を検討することをお勧めします。今後は、新しいバージョンの通信製品 (Calendar、Messaging、および Instant Messaging) で Schema 1 がサポートされなくなる可能性があります。ただし、この時点で Access Manager を使用しない場合は、都合のよい時期まで移行作業を見合わせることができます。

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

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

Java Enterprise System 以前のバージョンの Calendar Server から移行する場合は、cs5migrate、csmig、および csvdmig を実行したあとでこのユーティリティーを実行します。

マニュアルの参照先

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

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

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

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