Oracle® Fusion Middleware Oracle Directory Server Enterprise Editionアップグレードおよび移行ガイド

11gリリース1 (11.1.1.7.0)

B72438-01(原本部品番号:E28971-01)

目次

例一覧

図一覧

表一覧

タイトルおよび著作権情報

はじめに

- 対象読者

- このドキュメントの構成

- このドキュメントで使用する例

- Oracle Directory Server Enterprise Editionドキュメント・セット

- 関連ドキュメント

- 再配布可能ファイル

- デフォルト・パスとコマンドの場所

- 表記規則

- コマンド例でのシェル・プロンプト

- 記号の表記規則

- ドキュメント、サポートおよびトレーニング

- Oracleソフトウェア・リソース

- ドキュメントのアクセシビリティについて

1 既存のインストールをアップグレードするか移行するかの決定

- 1.1 アップグレードおよび移行時に何が行われるかの理解

- 1.2 アップグレードおよび移行パスの使用

- 1.3 アップグレード前および移行前タスクの完了

- 1.4 次の手順の実行

第I部 ODSEE 11gリリース1、7.xまたは6.xからのアップグレード

2 既存の11gリリース1または7.x zip配布によるインストールのアップグレード

- 2.1 アップグレードの準備

- 2.2 管理(DSCC)ホストのアップグレード

- 2.2.1 DSCC WARファイルの再デプロイの準備

- 2.2.2 DSCC WARファイルの再デプロイ

- 2.3 Directory ServerおよびDirectory Proxy Serverホストのアップグレード

3 既存の11gリリース1または7.xネイティブ・パッケージのインストールのアップグレード

- 3.1 アップグレードの準備

- 3.2 管理(DSCC)ホストのアップグレード

- 3.3 Directory ServerおよびDirectory Proxy Serverホストのアップグレード

4 既存の6.x zipまたはネイティブ・パッケージのインストールのアップグレード

- 4.1 アップグレードの準備

- 4.2 管理(DSCC)ホストのアップグレード

- 4.3 Directory ServerおよびDirectory Proxy Serverホストのアップグレード

- 4.4 サポート対象外のプラットフォームでのDirectory Server Enterprise Edition 6のアップグレード

- 4.4.1 レガシー・オペレーティング・システムからのDirectory Server Enterprise Editionのアップグレード

- 4.4.2 32ビットのサーバー・インスタンスのアップグレード

第II部 ODSEE 5.2からODSEE 11gリリース1 (11.1.1.7.0)への移行

5 Directory Serverの移行プロセスの概要

- 5.1 移行の準備

- 5.1.1 単一のDirectory Serverインスタンスを移行するための前提条件

- 5.2 新製品の配布

- 5.3 移行手順の概要

- 5.4 自動または手動移行の判断

6 dsmigコマンドを使用した自動移行

- 6.1 自動移行ツールについて

- 6.2 dsmigを実行するための前提条件

- 6.3 スキーマを移行するためのdsmigの使用

- 6.4 セキュリティ・データを移行するためのdsmigの使用

- 6.5 構成データを移行するためのdsmigの使用

- 6.5.1 プラグインの構成データ

- 6.5.2 複数のバックエンドを持つサフィックスの構成データ

- 6.5.3 レプリケーションの構成データ

- 6.5.4 o=netscapeRootの構成データ

- 6.5.5 dsmigが移行しない構成属性

- 6.6 ユーザー・データを移行するためのdsmigの使用

- 6.6.1 移行後の新しいインスタンスのトラブルシューティング

- 6.7 自動移行後に実行するタスク

7 手動でのDirectory Serverの移行

- 7.1 手動での移行の準備

- 7.2 手動でのスキーマの移行

- 7.3 手動での構成データの移行

- 7.3.1 特定の構成属性の移行

- 7.3.1.1 グローバル構成属性

- 7.3.1.2 セキュリティ構成属性

- 7.3.1.3 機能構成属性

- 7.3.1.4 ツリー構成属性のマッピング

- 7.3.1.5 レプリケーション構成属性

- 7.3.1.6 パスワード・ポリシー構成属性

- 7.3.1.7 SNMP属性

- 7.3.1.8 UniqueIDジェネレータ構成属性

- 7.3.1.9 データベース構成属性

- 7.3.1.10 プラグイン構成属性

- 7.4 手動でのセキュリティ設定の移行

- 7.5 手動でのユーザー・データの移行

- 7.6 手動でのユーザー・プラグインの移行

- 7.7 手動移行後に実行するタスク

8 レプリケーション・トポロジの移行

- 8.1 レプリケート対象のサーバーの移行の概要

- 8.2 レプリケート対象のサーバーの移行に関する問題

- 8.2.1 パスワード・ポリシーの問題

- 8.2.2 レプリケーション承諾の移行

- 8.2.3 リフェラルの移行

- 8.2.4 レプリケーション証明の手動でのリセット

- 8.2.5 ツームストンのパージに関連する問題

- 8.3 レプリケート時の推奨事項

- 8.4 移行シナリオ

- 8.4.1 同一トポロジへのレプリケーション・トポロジの移行

- 8.4.1.1 コンシューマの移行

- 8.4.1.2 ハブの移行

- 8.4.1.3 マスターの移行

- 8.4.2 新しいトポロジへのレプリケーション・トポロジの移行

- 8.4.2.1 すべてのサーバーの移行

- 8.4.2.2 ハブの昇格

- 8.4.2.3 コンシューマの昇格

- 8.4.3 複数のデータ・センターを介した移行

9 Directory Serverに対するバージョン5.2以降のアーキテクチャ変更

- 9.1 管理フレームワークに対する変更

- 9.1.1 ServerRootディレクトリの削除

- 9.1.2 o=netscapeRootサフィックスの削除

- 9.2 ACIに対する変更

- 9.2.1 ACIスコープに対する変更

- 9.2.2 サフィックス・レベルのACIに対する変更

- 9.3 コマンドラインに対する変更

- 9.4 コンソールに対する変更

- 9.5 パスワード・ポリシー

- 9.6 プラグインに対する変更

- 9.6.1 新しいプラグイン

- 9.6.2 プラグインAPIに対する変更

- 9.7 インストール済製品レイアウトに対する変更

- 9.7.1 以前ServerRoot下にあった管理ユーティリティ

- 9.7.2 以前ServerRoot/bin下にあったバイナリ

- 9.7.3 以前ServerRoot/lib下にあったライブラリおよびプラグイン

- 9.7.4 オンライン・ヘルプ・ファイルの廃止

- 9.7.5 以前ServerRoot/plugins下にあったプラグイン

- 9.7.6 以前ServerRoot/shared/bin下にあったユーティリティ

- 9.7.7 証明書およびキー・ファイル

- 9.7.8 サイレント・インストールおよびアンインストールのテンプレート

- 9.7.9 以前ServerRoot/slapd-ServerID下にあったサーバー・インスタンスのスクリプト

- 9.7.10 サーバー・インスタンスのサブディレクトリ

10 Directory Proxy Serverの移行

- 10.1 グローバル構成のマッピング

- 10.1.1 グローバル・セキュリティ構成のマッピング

- 10.1.1.1 証明書の管理

- 10.1.1.2 プロキシ構成のアクセス制御

- 10.2 接続プール構成のマッピング

- 10.3 グループ構成のマッピング

- 10.3.1 グループ・オブジェクトのマッピング

- 10.3.2 ネットワーク・グループ・オブジェクトのマッピング

- 10.3.3 バインド転送のマッピング

- 10.3.4 操作転送のマッピング

- 10.3.5 サブツリー非表示のマッピング

- 10.3.6 検索リクエスト制御のマッピング

- 10.3.7 比較リクエスト制御のマッピング

- 10.3.8 属性変更検索リクエストのマッピング

- 10.3.9 属性制限検索応答のマッピング

- 10.3.10 参照構成属性のマッピング

- 10.3.11 サーバー・ロード構成のマッピング

- 10.4 プロパティ構成のマッピング

- 10.4.1 属性の名前変更プロパティ

- 10.4.2 入力禁止プロパティ

- 10.4.3 LDAPサーバーのプロパティ

- 10.4.4 ロード分散プロパティ

- 10.4.4.1 バックエンド・サーバーの監視

- 10.4.5 検索サイズ制限プロパティ

- 10.4.6 ログ・プロパティ

- 10.5 イベント構成のマッピング

- 10.6 アクション構成のマッピング

- 10.7 単純な接続ベースのルータとしてのDirectory Proxy Server 11gリリース1 (11.1.1.7.0)の構成

11 Identity Synchronization for Windowsの移行

- 11.1 移行の概要

- 11.2 Identity Synchronization for Windowsを移行する前に

- 11.3 Identity Synchronization for Windowsの移行の準備

- 11.3.1 バージョン1.1の構成のエクスポート

- 11.3.1.1 export11cnfユーティリティの使用

- 11.3.1.2 クリア・テキスト・パスワードの挿入

- 11.3.1.3 構成ファイルのエクスポートの例

- 11.3.2 未配信のメッセージの確認

- 11.3.2.1 checktopicsユーティリティの使用

- 11.3.2.2 メッセージのクリア

- 11.3.3 Windows NTでのパスワード変更の強制

- 11.4 システムの移行

- 11.4.1 移行の準備

- 11.4.1.1 バージョン1.1および1.1 SP1のバージョン6.0 SP1への移行の準備

- 11.4.2 Identity Synchronization for Windowsのアンインストール

- 11.4.2.1 Identity Synchronization for Windows Version 1.1のアンインストール

- 11.4.3 依存関係のある製品のインストールまたはアップグレード

- 11.4.4 Identity Synchronization for Windows 6.0 SP1のインストール

- 11.4.4.1 Identity Synchronization for Windows 6.0 SP1のコンポーネントのインストール

- 11.5 1.1のアンインストールが失敗した場合の対応

- 11.5.1 Solarisからの1.1コアおよびインスタンスの手動アンインストール

- 11.5.1.1 Solarisマシンからのコアの手動アンインストール

- 11.5.2 Windows 2000からの1.1コアおよびインスタンスの手動アンインストール

- 11.5.2.1 Windows 2000マシンからのコアのアンインストール

- 11.5.3 Windows NTからの1.1インスタンスの手動アンインストール

- 11.6 その他の移行シナリオ

- 11.6.1 マルチマスター・レプリケーション・デプロイメント

- 11.6.2 Windows NTでのマルチホスト・デプロイメント

- 11.7 ログの確認

索引

例一覧

- 11-1 エクスポートされた構成ファイルの例

図一覧

- 8-1 レガシー・トポロジ

- 8-2 トポロジからのコンシューマの分離

- 8-3 コンシューマの移行

- 8-4 11gリリース1 (11.1.1.7.0)のコンシューマのトポロジへの配置

- 8-5 移行したコンシューマを含むトポロジ

- 8-6 トポロジからのハブの分離

- 8-7 ハブの移行

- 8-8 11gリリース1 (11.1.1.7.0)のハブのトポロジへの配置

- 8-9 移行したコンシューマとハブを含むトポロジ

- 8-10 マスターのトポロジからの分離

- 8-11 マスターの移行

- 8-12 11gリリース1 (11.1.1.7.0)のマスターのトポロジへの配置

- 8-13 レガシー・トポロジ

- 8-14 移行したサーバーを含むトポロジ

- 8-15 昇格したハブ・レプリカを含む移行したトポロジ

- 8-16 新しいフルメッシュ型のすべてがマスターのトポロジ

- 11-1 単一ホストのデプロイメントの移行

- 11-2 マルチマスター・レプリケーション・デプロイメントでの移行

- 11-3 Windows NTでのマルチホスト・デプロイメントの移行

表一覧

- 5-1 自動移行のサポートを示す移行マトリックス

- 7-1 変更ログ属性名の変更

- 7-2 部分レプリケーション属性名の変更

- 7-3 5.2と11gリリース1 (11.1.1.7.0)のパスワード・ポリシー属性間のマッピング

- 9-1 Directory Server 5、6および7のコマンド

- 9-2 Directory Server 5、6および7のコマンド

- 9-3 プラグインのサポート

- 9-4 以前ServerRoot/shared/bin下にあったツール

- 9-5 証明書およびキー・ファイルの場所

- 9-6 インスタンス固有のサブディレクトリ

- 10-1 セキュリティ構成のマッピング

- 10-2 接続プール属性のマッピング

- 10-3 グループ属性と接続ハンドラのプロパティ間のマッピング

- 10-4 ネットワーク・グループ属性のマッピング

- 10-5 バインド転送属性と接続ハンドラのプロパティ設定のマッピング

- 10-6 操作転送属性とリクエスト・フィルタリング・プロパティのマッピング

- 10-7 検索リクエスト制御属性のマッピング

- 10-8 比較リクエスト制御属性のマッピング

- 10-9 検索リクエスト変更属性のマッピング

- 10-10 検索応答制御属性のマッピング

- 10-11 参照構成属性とリソース制限プロパティのマッピング

- 10-12 サーバー・ロード構成属性とリソース制限プロパティのマッピング

- 10-13 サーバー・ロード構成属性とリソース制限プロパティのマッピング

- 10-14 ids-proxy-sch-LDAPServer属性とデータ・ソース・プロパティのマッピング

- 10-15 検索サイズ制限属性のマッピング

- 10-16 バージョン5.2およびバージョン11gリリース1 (11.1.1.7.0)のログ機能

- 10-17 イベント属性と接続ハンドラ・プロパティのマッピング

- 11-1 マルチマスター・レプリケーション・デプロイメントでのコンポーネントの分布

- 11-2 マルチホスト・デプロイメント

Oracle® Fusion Middleware

Oracle Directory Server Enterprise Editionアップグレードおよび移行ガイド

11gリリース1 (11.1.1.7.0)

B72438-01(原本部品番号:E28971-01)

2013年1月

以前のDirectory Server Enterprise Editionのインストールからアップグレードおよび移行を行う際の方法および提案を示します。

Oracle Directory Server Enterprise Editionアップグレードおよび移行ガイド, 11gリリース1 (11.1.1.7.0)

B72438-01

Copyright © 2001, 2013, Oracle and/or its affiliates.All rights reserved.

原本著者:  Gina Cariaga

このソフトウェアおよび関連ドキュメントの使用と開示は、ライセンス契約の制約条件に従うものとし、知的財産に関する法律により保護されています。ライセンス契約で明示的に許諾されている場合もしくは法律によって認められている場合を除き、形式、手段に関係なく、いかなる部分も使用、複写、複製、翻訳、放送、修正、ライセンス供与、送信、配布、発表、実行、公開または表示することはできません。このソフトウェアのリバース・エンジニアリング、逆アセンブル、逆コンパイルは互換性のために法律によって規定されている場合を除き、禁止されています。

ここに記載された情報は予告なしに変更される場合があります。また、誤りが無いことの保証はいたしかねます。誤りを見つけた場合は、オラクル社までご連絡ください。

このソフトウェアまたは関連ドキュメントを、米国政府機関もしくは米国政府機関に代わってこのソフトウェアまたは関連ドキュメントをライセンスされた者に提供する場合は、次の通知が適用されます。

U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs.No other rights are granted to the U.S. Government.

このソフトウェアもしくはハードウェアは様々な情報管理アプリケーションでの一般的な使用のために開発されたものです。このソフトウェアもしくはハードウェアは、危険が伴うアプリケーション(人的傷害を発生させる可能性があるアプリケーションを含む)への用途を目的として開発されていません。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用する際、安全に使用するために、適切な安全装置、バックアップ、冗長性(redundancy)、その他の対策を講じることは使用者の責任となります。このソフトウェアもしくはハードウェアを危険が伴うアプリケーションで使用したことに起因して損害が発生しても、オラクル社およびその関連会社は一切の責任を負いかねます。

OracleおよびJavaはOracle Corporationおよびその関連企業の登録商標です。その他の名称は、それぞれの所有者の商標または登録商標です。

Intel、Intel Xeonは、Intel Corporationの商標または登録商標です。すべてのSPARCの商標はライセンスをもとに使用し、SPARC International, Inc.の商標または登録商標です。AMD、Opteron、AMDロゴ、AMD Opteronロゴは、Advanced Micro Devices, Inc.の商標または登録商標です。UNIXは、The Open Groupの登録商標です。

このソフトウェアまたはハードウェア、そしてドキュメントは、第三者のコンテンツ、製品、サービスへのアクセス、あるいはそれらに関する情報を提供することがあります。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスに関して一切の責任を負わず、いかなる保証もいたしません。オラクル社およびその関連会社は、第三者のコンテンツ、製品、サービスへのアクセスまたは使用によって損失、費用、あるいは損害が発生しても一切の責任を負いかねます。

はじめに

『Oracle Directory Server Enterprise Editionアップグレードおよび移行ガイド』では、Directory Server Enterprise Editionのコンポーネントをバージョン11gリリース1 (11.1.1.7.0)に移行する方法について説明します。このガイドでは、Directory Server、Directory Proxy ServerおよびIdentity Synchronization for Windowsの移行方法について説明します。

対象読者

このガイドは、Directory Server Enterprise Edition 11gリリース1 (11.1.1.7.0)を移行するディレクトリ・サービスの管理者を対象としています。また、新バージョンへの移行を検討しているビジネス計画者にも有用です。

このドキュメントの構成

- 第1章「既存のインストールをアップグレードするか移行するかの決定」

- 第I部「ODSEE 11gリリース1、7.xまたは6.xからのアップグレード」

- 第II部「ODSEE 5.2からODSEE 11gリリース1 (11.1.1.7.0)への移行」

このドキュメントで使用する例

一貫性を保つため、このガイド全体で同じサンプル・データを使用します。これらの値をご使用のシステムに適した値に置き換えてください。

変数

例で使用する値

接尾辞(SUFFIX_DN)

dc=example,dc=com

インスタンスのパス(INSTANCE_PATH)

Directory Serverの場合: /local/dsInst/

Directory Proxy Serverの場合: /local/dps/

ホスト名(HOST)

host1、host2、host3

ポート(PORT)

LDAP:rootのデフォルト: 389。root以外のデフォルト: 1389

SSLのデフォルト: rootのデフォルト: 636。root以外のデフォルト: 1636

Oracle Directory Server Enterprise Editionドキュメント・セット

このドキュメント・セットでは、Oracle Directory Server Enterprise Editionを使用してディレクトリ・サービスを評価、設計、デプロイ、および管理する方法について説明します。また、Directory Server Enterprise Edition用クライアント・アプリケーションの開発方法についても説明します。Oracle Fusion Middleware Directory Server Enterprise Editionのドキュメント・ライブラリは、http://docs.oracle.com/cd/E29127_01/index.htmにあります。

次の表に、Directory Server Enterprise Editionのドキュメント・セットを構成するドキュメントのリストを示します。

ドキュメント・タイトル

内容

『Oracle Directory Server Enterprise Editionリリース・ノート』

既知の問題点を含め、Directory Server Enterprise Editionについての最新情報を提供しています。

『Oracle Directory Server Enterprise Edition評価ガイド』

このリリースの重要な機能を紹介します。これらの機能の仕組みや提供される利点を、単独システムに実装可能なデプロイメントのコンテキストに沿って示しています。

『Oracle Directory Server Enterprise Editionデプロイメント・プランニング・ガイド』

Directory Server Enterprise Editionをベースとする、可用性と拡張性に優れたディレクトリ・サービスを計画および設計する方法について説明しています。デプロイメントの計画および設計の基本的な概念および原則を提示します。ソリューションのライフ・サイクルについて検討し、Directory Server Enterprise Editionベースのソリューションを計画するために使用する概略レベルのサンプルおよび戦略を提供します。

『Oracle Directory Server Enterprise Editionインストレーション・ガイド』

Directory Server Enterprise Editionソフトウェアのインストール方法について説明しています。インストール済ソフトウェアの構成方法および構成済ソフトウェアの検証方法を示します。

『Oracle Directory Server Enterprise Editionアップグレードおよび移行ガイド』

バージョン11.1.1.3, 7.xおよび6のインストールをアップグレードする手順およびバージョン5.2インストールを移行する手順を示しています。

『Oracle Directory Server Enterprise Edition管理者ガイド』

Directory Server Enterprise Editionをコマンドラインから管理する手順を示しています。

Directory Service Control Center(DSCC)を使用してDirectory Server Enterprise Editionを管理する際のヒントおよび手順については、DSCCのオンライン・ヘルプを参照してください。

『Oracle Directory Server Enterprise Editionリファレンス』

Directory Server Enterprise Editionの技術および概念の基礎を紹介します。コンポーネント、アーキテクチャ、プロセス、および機能について説明しています。

『Oracle Directory Server Enterprise Edition Manページ・リファレンス』

Directory Server Enterprise Editionを通じて利用可能なコマンドライン・ツール、スキーマ・オブジェクトおよびその他の公開インタフェースについて説明しています。このドキュメントの個別の項を、オンライン・マニュアル・ページとしてインストールできます。

『Oracle Directory Server Enterprise Edition開発者ガイド』

Directory Server Enterprise Editionの一部として提供されるツールおよびAPIを利用して、ディレクトリ・クライアント・アプリケーションを開発する方法を示しています。

『Oracle Directory Server Enterprise Editionトラブルシューティング・ガイド』

様々なツールを使用して問題の範囲を特定し、データを収集し、問題部分のトラブルシューティングを行う手順について説明しています。

『Identity Synchronization for Windows 6.0リリース・ノート』

Identity Synchronization for Windows 6.0 SP1のインストール、移行およびアップグレードに関する最新情報があります。

『Identity Synchronization for Windows 6.0デプロイメント・プランニング・ガイド』

Identity Synchronization for Windowsの計画とデプロイメントに関する一般的なガイドラインやベスト・プラクティスを示しています。

『Identity Synchronization for Windows 6.0インストレーションおよび構成ガイド』

Identity Synchronization for Windowsをインストールおよび構成する方法を説明しています。

Directory Server Enterprise Editionの概要については、次の図に示す順序でドキュメントを確認してください。

docmap.pngの説明

関連ドキュメント

SLAMD分散負荷生成エンジンは、ネットワークベースのアプリケーションのパフォーマンスについて負荷テストを実行し、解析するために設計されたJavaアプリケーションです。このアプリケーションは、LDAPディレクトリ・サーバーのパフォーマンスについてベンチマークを実行し、分析するためにSun Microsystems, Inc.によって開発されました。SLAMDは、OSI認定オープン・ソース・ライセンスであるSun Public Licenseに基づいて、オープン・ソース・アプリケーションとして使用できます。SLAMDの詳細は、http://www.slamd.com/を参照してください。SLAMDは、java.netプロジェクトでも提供されています。https://slamd.dev.java.net/を参照してください。

Java Naming and Directory Interface(JNDI)は、LDAPやDSML v2によるJavaアプリケーションからDirectory Serverへのアクセスに対応しています。JNDIの詳細は、http://www.oracle.com/technetwork/java/jndi/index.htmlを参照してください。JNDI Tutorialには、詳しい説明とJNDIの使用例が記載されています。このチュートリアルは、http://download.oracle.com/javase/jndi/tutorial/で参照できます。

Identity Synchronization for WindowsはMessage Queueを制限されたライセンスで使用します。Message Queueのドキュメントは、http://www.oracle.com/technetwork/indexes/documentation/index.htmlを参照してください。

Identity Synchronization for WindowsはMicrosoft Windowsのパスワード・ポリシーを扱います。

- Windows 2003のパスワード・ポリシーは、Microsoftのオンライン・ドキュメント(http://technet.microsoft.com/en-us/windowsserver/default.aspx)を参照してください。

- Microsoft証明書サービスのエンタープライズ・ルート認証局に関する情報は、Microsoftのオンライン・サポート・ドキュメント(http://support.microsoft.com/default.aspx?scid=kb;en-us;247078)を参照してください。

- MicrosoftシステムにおけるLDAP over SSLの設定に関する情報は、Microsoftのオンライン・サポート・ドキュメント(http://support.microsoft.com/default.aspx?scid=kb;en-us;321051)を参照してください。

再配布可能ファイル

Directory Server Enterprise Editionのファイルは、再頒布できません。

デフォルト・パスとコマンドの場所

この項では、このドキュメントで使用するデフォルトのパスについて説明し、様々なオペレーティング・システムおよびデプロイメント・タイプでのコマンドの場所を示します。

デフォルト・パス

次の表では、このドキュメントで使用するデフォルトのパスについて説明します。インストール済のファイルの詳細は、『Oracle Directory Server Enterprise Editionリファレンス』の第1章のDirectory Server Enterprise Editionのファイル・リファレンスに関する説明を参照してください。

プレースホルダ

説明

デフォルト値

install-path

Directory Server Enterprise Editionソフトウェアのベース・インストール・ディレクトリを表します。

unzipを使用しzipの配布からインストールを行う場合、install-pathがcurrent-directory/dsee7になります。

instance-path

Directory ServerまたはDirectory Proxy Serverのインスタンスのフルパスを表します。

このドキュメントでは、Directory Serverには/local/dsInst/、Directory Proxy Serverには/local/dps/を使用します。

デフォルト・パスはありません。インスタンス・パスは、常にローカル・ファイル・システム上に存在するようにします。

Solarisシステムでは、/varディレクトリをお薦めします。

serverroot

Identity Synchronization for Windowsのインストール先の親ディレクトリを表します。

インストールごとに異なります。Directory ServerおよびDirectory Proxy Serverでは、serverrootの概念が存在しなくなったことに注意してください。

isw-hostname

Identity Synchronization for Windowsインスタンスのディレクトリを表します。

インストールごとに異なります。

/path/to/cert8.db

Identity Synchronization for Windowsのクライアントの証明書データベースのデフォルト・パスおよびファイル名を表します。

current-working-dir/cert8.db

serverroot/isw-hostname/linebreaklogs/

システム・マネージャ、各コネクタ、およびセントラル・ロガーのログ・ファイルをIdentity Synchronization for Windowsがローカルに保存する場所のデフォルト・パスを表します。

インストールごとに異なります。

serverroot/isw-hostname/linebreaklogs/central/

Identity Synchronization for Windowsセントラル・ログ・ファイルのデフォルト・パスを表します。

インストールごとに異なります。

コマンドの場所

この項の次の表は、Directory Server Enterprise Editionのドキュメントで使用されるコマンドの場所を示しています。各コマンドの詳細は、関連するマニュアル・ページを参照してください。『Oracle Directory Server Enterprise Editionリファレンス』のDirectory Server Enterprise Editionのソフトウェア・レイアウトに関する説明を参照してください。

コマンド

Zipディストリビューション

certutil

install-path/bin/certutil

dpadm

install-path/bin/dpadm

dpconf

install-path/bin/dpconf

dsadm

install-path/bin/dsadm

dsccagent

install-path/bin/agent

dsccmon

install-path/bin/dsccmon

dsccreg

install-path/bin/dsccreg

dsccsetup

install-path/bin/dsccsetup

dsconf

install-path/bin/dsconf

dsmig

install-path/bin/dsmig

dsutil

install-path/bin/dsutil

entrycmp

install-path/bin/entrycmp

fildif

install-path/bin/fildif

idsktune

解凍したzipディストリビューションのroot

insync

install-path/bin/insync

ldapmodify

install-path/dsrk/bin/ldapmodify

ldapsearch

install-path/dsrk/bin/ldapsearch

repldisc

install-path/bin/repldisc

表記規則

次の表に、このドキュメントで使用する表記規則を示します。

書体

意味

例

AaBbCc123

コマンド名、ファイル名、ディレクトリ名、画面上のコンピュータ出力を示します。

.loginファイルを編集します。

ls aを使用してすべてのファイルをリストします。

machine_name% you have mail.

AaBbCc123

ユーザーが入力する文字を、画面上のコンピュータ出力と区別して示します。

machine_name% su

Password:

aabbcc123

プレースホルダ: 実際の名前または値で置き換えます。

ファイルを削除するコマンドはrm filenameです。

AaBbCc123

書名、新規用語および強調する用語を示します。

『ユーザーズ・ガイド』の第6章を参照してください。

キャッシュとは、ローカルに格納されるコピーです。

このファイルは保存しないでください。

注意: 強調する一部の項目は、オンラインで太字で表示されます。

コマンド例でのシェル・プロンプト

次の表に、Oracle Solaris OSに含まれるシェルのデフォルトのUNIXシステム・プロンプトとスーパーユーザー・プロンプトを示します。コマンド例に表示されるデフォルトのシステム・プロンプトは、Oracle Solarisのリリースによって異なることに注意してください。

シェル

プロンプト

Bashシェル、KornシェルおよびBourneシェル

$

Bashシェル、KornシェルおよびBourneシェル(スーパーユーザーの場合)

#

Cシェル

machine_name%

Cシェル(スーパーユーザーの場合)

machine_name#

記号の表記規則

次の表では、このドキュメントで使用される記号について説明します。

記号

説明

例

意味

[ ]

省略可能な引数やコマンドオプションが含まれます。

ls [-l]

-lオプションは省略可能です。

{ | }

必須のコマンドオプションの選択肢を囲みます。

-d {y|n}

-dオプションでは、yかnのどちらかの引数を使用する必要があります。

${ }

編集参照を示します。

${com.sun.javaRoot}

com.sun.javaRoot変数の値を参照します。

-

同時に押すキーを連結します。

Control-A

[Ctrl]キーと[A]キーを同時に押します。

+

連続して押すキーを連結します。

Ctrl+A+N

[Ctrl]キーを押し、放してから以後のキーを続けて押します。

>

グラフィカル・ユーザー・インタフェースで選択するメニュー項目を示します。

「ファイル」→「新規」→「テンプレート」

「ファイル」メニューから「新規」を選択します。「新規」サブメニューから「テンプレート」を選択します。

ドキュメント、サポートおよびトレーニング

次のWebサイトでは、追加の情報が提供されています。

- ドキュメント(http://www.oracle.com/technetwork/indexes/documentation/index.html)

- サポート(http://www.oracle.com/us/support/systems/index.html)

- トレーニング(http://education.oracle.com)

Oracleソフトウェア・リソース

Oracle Technology Network (http://www.oracle.com/technetwork/index.html)には、Oracleソフトウェアと関連する一連のリソースがあります。

- ODSEEのディスカッション・フォーラム(http://forums.oracle.com/forums/forum.jspa?forumID=877)およびDirectory Servicesのブログ(http://blogs.oracle.com/directoryservices/)では、技術的な問題を説明しています。

- Directory Servicesのブログ(http://blogs.oracle.com/directoryservices/)には最新の告知があります。

- ODSEE 11gの例のファイルをダウンロードできます(http://www.oracle.com/technetwork/middleware/id-mgmt/learnmore/odsee11113-examples-350399.zip)。

ドキュメントのアクセシビリティについて

Oracleのアクセシビリティについての詳細情報は、Oracle Accessibility ProgramのWeb サイト(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc)を参照してください。

Oracle Supportへのアクセス

Oracleサポート・サービスでは、My Oracle Supportを通して電子支援サービスを提供しています。詳細情報は(http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info) か、聴覚に障害のあるお客様は (http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs)を参照してください。

1 既存のインストールをアップグレードするか移行するかの決定

アップグレードおよび移行オプションでは、Directory Server Enterprise Editionの既存のインストールを、11gリリース1 (11.1.1.7.0)のリリースと置き換えることができます。この章の内容は、次のとおりです。

- 「アップグレードおよび移行時に何が行われるかの理解」

- 「アップグレードおよび移行パスの使用」

- 「アップグレード前および移行前タスクの完了」

- 「次の手順の実行」

1.1 アップグレードおよび移行時に何が行われるかの理解

Sun Java Directory Server 5.xを除くすべてのDirectory Server Enterpriseバージョンで、アップグレードはサポートされています。Sun Java Directory Server 5.xには、移行オプションしかありません。

既存の11gリリース1、7.xまたは6.x ODSEEインスタンスを11gリリース1 (11.1.1.7.0)にアップグレードすると、インスタンス内のDirectory Serverの構成およびファイルが、その場で自動的にアップグレードされます。何もコピー、エクスポートまたはインポートする必要はありません。

dsmigコマンドを使用し、5.xインスタンスを11gリリース1 (11.1.1.7.0)に移行すると、dsmigツールによって新しい11gリリース1 (11.1.1.7.0)インスタンスが作成され、その後、既存の5.2インスタンスから新しい11gリリース1 (11.1.1.7.0)インスタンスにすべての構成が自動的にコピーされます。dsmigコマンドを使用できない場合や使用しないことを選択した場合、構成、ユーザー・データ、スキーマ、セキュリティ・コンポーネント、プラグインを既存の5.2インスタンスから新しい11gリリース1 (11.1.1.7.0)インスタンスに手動でコピーする必要があります。

1.2 アップグレードおよび移行パスの使用

既存のインストールのバージョン番号、およびODSEEがzip配布またはネイティブ・パッケージ配布のどちらを使用して最初にインストールしたかに応じて、11gリリース1 (11.1.1.7.0)にアップグレードまたは移行できます。

ODSEE 11gリリース1 (11.1.1.7.0)には次のパスが用意されています。

既存の11gリリース1または7.x zip配布によるインストールのアップグレード

最初にzip配布を使用してインストールした既存の11gリリース1または7.xのODSEEインスタンスをアップグレードすると、11gリリース1または7.xバージョンは11gリリース1 (11.1.1.7.0)バイナリの新しいインストールで上書きされます。古いバージョンを共存させることはできません。

既存の11gリリース1または7.xネイティブ・パッケージのインストールのアップグレード

あらかじめネイティブ･パッケージ・ディストリビューションを使用してインストールされた既存の11gリリース1または7.xのODSEEインスタンスをアップグレードすると、11gリリース1 (11.1.1.7.0)バイナリは古いバージョンとは別にインストールされます。古いバージョンは同じマシンに一時的に共存させることができます。

既存の6.x zipまたはネイティブ・パッケージのインストールのアップグレード

最初にzipまたはネイティブ･パッケージのどちらをインストールしたかにかかわらず、既存のバージョン6.xインスタンスアップグレードすると、11gリリース1 (11.1.1.7.0)バイナリは古いバージョンの次にインストールされます。古いバージョンは同じマシンに一時的に共存させることができます。

注意:

既存の6.2のインストールを11gリリース1 (11.1.1.7.0)にアップグレードする場合、重要なアップグレード前手順を完了する必要があります。第1.3項「アップグレード前および移行前タスクの完了」を参照してください。

既存の5.2 zipまたはネイティブ・パッケージ・インストールの移行

- dsmigツールを使用すると、11gリリース1 (11.1.1.7.0)インスタンスが自動的に生成されます。すべての構成、ユーザー・データおよびその他のすべての必要なファイルが5.2インスタンスから新しい11gリリース1 (11.1.1.7.0)インスタンスにコピーされます。5.2インスタンスおよび11gリリース1 (11.1.1.7.0)インスタンスは同じマシンに共存させることはできません。

- dsmigツールを使用できない場合や使用しないことを選択した場合、新しい11gリリース1 (11.1.1.7.0)インスタンスを手動で作成する必要があります。また、既存の構成およびユーザー・データ、セキュリティ・コンポーネント、プラグインを古い5.2インスタンスから新しい11gリリース1 (11.1.1.7.0)インスタンスへ手動でコピーする必要があります。

1.3 アップグレード前および移行前タスクの完了

アップグレードまたは移行を開始する前に、次の準備手順を完了します。

- 以前のDirectory ServerおよびDirectory Proxy Serverインスタンスをアップグレードする前に、アップグレード時に問題が発生した場合にリストアできるよう、すべてのインスタンスをバックアップします。tarまたはcpioなどのファイル・システム・ユーティリティを使用し、ファイル・システム全体をバックアップします。次に例を示します。

$ tar cf BACKUP_INSTANCE INSTANCE_DIRECTORY

- バージョン6.2から11gリリース1 (11.1.1.7.0)にアップグレードする場合は、アップグレードを進める前に次の手順を完了します。

1. データベースをLDIFファイルにエクスポートします。
詳細は、dsadmに関する説明でdsadm exportコマンドを参照してください。

2. Directory Server Enterprise Edition 6.2インストールをバージョン6.3にアップグレードします。
詳細は、『Sun Directory Server Enterprise Edition 6.3インストレーション・ガイド』を参照してください。

3. 手順1で作成したLDIFファイルからデータをインポートします。
詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のLDIFファイルからのデータのインポートに関する説明を参照してください。

- サーバーを直接アップグレードできない場合があります。たとえば、Red Hat Enterprise LinuxまたはSUSE Linux Enterprise Edition 64ビット・プラットフォーム上で実行されていたバージョン6の32ビット・インスタンスはアップグレードできなくなりました。64ビットのプラットフォームで実行するには、インスタンスは64ビットである必要があります。このような場合には、追加の手順が必要です。
サポート対象外のプラットフォームでバージョン6インスタンスをアップグレードする方法の詳細は、第4.4項「サポート対象外のプラットフォームでのDirectory Server Enterprise Edition 6のアップグレード」を参照してください。

- Directory Serverチェーンが構成されている場合、アップグレードまたは移行を進める前にその構成を削除します。

- Cacaoモジュールを停止します。次に例を示します。

バージョン6.xのzip配布の場合

# INSTALL_PATH/dsee6/cacao_2/usr/sbin/cacaoadm stop

バージョン11.1.1.3、11.1.1.5または7.xのzip配布の場合

# INSTALL_PATH/dsee7/bin/cacaoadm stop

# INSTALL_PATH/dsee7/bin/cacaoadm stop

ネイティブ・パッケージのインストールの場合

# /usr/sbin/cacaoadm stop

1.4 次の手順の実行

選択したアップグレードまたは移行オプションに適したマニュアルを参照します。

既存の11gリリース1または7.xのzip配布にインストールをアップグレードする場合

第2章「既存の11gリリース1または7.x zip配布によるインストールのアップグレード」を参照してください。

既存の11gリリース1または7.xのネイティブ・パッケージのインストールをアップグレードする場合

第3章「既存の11gリリース1または7.xネイティブ・パッケージのインストールのアップグレード」を参照してください。

既存の6.xのzipまたはネイティブ・パッケージのインストールをアップグレードする場合

第4章「既存の6.x zipまたはネイティブ・パッケージのインストールのアップグレード」を参照してください。

バージョン5.2のzipまたはネイティブ・パッケージ・インストールを移行する場合

第5章「Directory Serverの移行プロセスの概要」を参照してください。

第I部

ODSEE 11gリリース1、7.xまたは6.xからのアップグレード

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

- 第1章「既存のインストールをアップグレードするか移行するかの決定」

- 第2章「既存の11gリリース1または7.x zip配布によるインストールのアップグレード」

- 第3章「既存の11gリリース1または7.xネイティブ・パッケージのインストールのアップグレード」

- 第4章「既存の6.x zipまたはネイティブ・パッケージのインストールのアップグレード」

2 既存の11gリリース1または7.x zip配布によるインストールのアップグレード

この章では、zipの配布を使用して当初インストールした既存の11gリリース1または7.xのインストールをアップグレードする方法を説明します。この章の内容は次のとおりです。

- 「アップブレードの準備」

- 「管理(DSCC)ホストのアップグレード」

- 「Directory ServerおよびDirectory Proxy Serverホストのアップグレード」

アップグレード時に発生する事柄、および様々なアップグレードおよび移行オプションの詳細は、第1章「既存のインストールをアップグレードするか移行するかの決定」を参照してください。

2.1 アップグレードの準備

- 第1.3「アップグレード前および移行前タスクの完了」で説明した問題をすべて解決します。

- 以降の手順ではprepare-patchおよびcomplete-patchという名前のコマンドを実行しますが、実際はパッチを適用するのではなく、ソフトウェアをアップグレードします。

- Directory Server Enterprise Editionのインストールを所有するユーザー・アカウントからアップグレードを実行します。

- Directory Service Control Centerをホストしているサーバーを特定します。必ず管理(DSCC)ホストをアップグレードしてから、任意のDirectory ServerホストまたはDirectory Proxy Serverホストをアップグレードします。

- アップグレードを行うには、大きく分けて次の2つの手順を実行する必要があります。

1. 管理(DSCC)ホストのアップグレード

2. Directory ServerおよびDirectory Proxy Serverホストのアップグレード

2.2 管理(DSCC)ホストのアップグレード

Directory Service Contol Center (DSCC)を使用し、Directory Server Enterprise Edition 11gリリース1 (11.1.1.7.0)のインスタンスの管理を開始する前に、最初にいくつかの準備手順を行い、Directory DSCC WARファイルを再デプロイする必要があります。DSCC WARファイルを再デプロイしたら、Directory Service Control Center 11gリリース1 (11.1.1.7.0)の使用を開始し、既存のバージョン6x、7.0および11gリリース1 (11.1.1.5.0 or 11.1.1.3.0)インスタンスにアクセスを開始できます。

2.2.1 DSCC WARファイルの再デプロイの準備

1. Cacaoモジュールを停止します。次に例を示します。

バージョン6.xのzip配布の場合

# INSTALL_PATH/dsee6/cacao_2/usr/sbin/cacaoadm stop

バージョン11.1.1.3、11.1.1.5または7.xのzip配布の場合

# INSTALL_PATH/dsee7/bin/cacaoadm stop

# INSTALL_PATH/dsee7/bin/cacaoadm stop

ネイティブ・パッケージのインストールの場合

# /usr/sbin/cacaoadm stop

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

# install-path/bin/dsccsetup prepare-patch

3. 既存のインストールを上書きし、ODSEE 11g R1 (11.1.1.7.0)をインストールします。
『Oracle Directory Server Enterprise Editionインストレーション・ガイド』の第2章のDirectory Server Enterprise Editionのインストールに関する説明を参照してください。

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

# install-path/bin/dsccsetup complete-patch

2.2.2 DSCC WARファイルの再デプロイ

1. DSCC用にWARファイルを作成します。

# install-path/bin/dsccsetup war-file-create
Created install-path/var/dscc7.war

WARファイルの場所のメモを取ります。

2. アプリケーション・サーバーにdscc7.warをデプロイします。

詳細な手順は、次を両方参照してください。

- 『Oracle Directory Server Enterprise Editionインストレーション・ガイド』のDirectory Server Enterprise Editionのインストールの事前構成に関する説明

- 『Oracle Directory Server Enterprise Editionインストレーション・ガイド』の付録AのDSCC WARファイルのデプロイに関する説明

2.3 Directory ServerおよびDirectory Proxy Serverホストのアップグレード

Directory Server Enterprise Editionの各インストールで次のアップグレード手順を実行します。ただし、Directory Service Control Centerをホストするサーバーを最初に特定してアップグレードてから、他の任意のサーバーをアップグレードします。第2.2項「管理(DSCC)ホストのアップグレード」を参照してください。

注意:

Directory Serverのアップグレードは、Directory Server Enterprise Editionのインストールを所有するユーザー・アカウントから実行する必要があります。

1. Cacaoモジュールを停止します。次に例を示します。

バージョン6.xのzip配布の場合

# INSTALL_PATH/dsee6/cacao_2/usr/sbin/cacaoadm stop

バージョン11.1.1.3、11.1.1.5または7.xのzip配布の場合

# INSTALL_PATH/dsee7/bin/cacaoadm stop

# INSTALL_PATH/dsee7/bin/cacaoadm stop

ネイティブ・パッケージのインストールの場合

# /usr/sbin/cacaoadm stop

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

# install-path/bin/dsccsetup prepare-patch

dsccsetup prepare-patchコマンドでは、実行中のすべてのDirectory ServerおよびDirectory Proxy Serverインスタンスの停止が試行されます。

- 次のメッセージが表示された場合、手順3に進みます。

You can now safely patch your installation.

- dsccsetup prepare-patchコマンドにサーバー・インスタンスを停止する権限がない場合、それが失敗したことを示すメッセージが表示され、続行する前にサーバーを手動で停止する必要があります。手順2に進みます。

3. prepare-patchコマンドによってサーバーを停止できなかった場合(第2.2.1項「DSCC WARファイルの再デプロイの準備」を参照)、次のいずれかのコマンドを実行し、サーバーが停止されたことを確認します。

Directory Serverを停止するには、次のコマンドを実行します。

# install-path/bin/dsadm stop instance-path

プロキシ・サーバーを停止するには、次のコマンドを実行します。

# install-path/bin/dpadm stop instance-path

4. 一時ディレクトリTEMP_DIRECTORYを作成し、この中にインストール・ファイルのコピーを保存します。

5. 次のコマンドを入力し、Directory Server Enterprise Editionソフトウェアをインストールします。

# cd TEMP_DIRECTORY
# unzip -q ODSEE11_1_1_5_0_xxx.zip
# cd ODSEE_ZIP_Distribution
# unzip -q sun-dsee7.zip -d install-path
# cd install-path/dsee7

この手順は実質的に既存のインストールを上書きするので、install-pathは手順1で使用したインストール・パスを意味します。既存のファイルはすべて上書きする必要があります。

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

# install-path/bin/dsccsetup complete-patch

dsccsetup complete-pathの出力は、手順8で実行するパスおよびコマンドを実際に指定します。パスとコマンドのメモを取ります。

7. 前述の手順2でサーバーを手動で停止した場合、手順5ではDirectory Serverインスタンスは自動的にアップグレードされません。次のコマンドを実行し、ここで手動でDirectory Serviceインスタンスをアップグレードする必要があります。

# install-path/bin/dsadm upgrade [-i] instance-path

8. 新しいDSCCエージェントを作成し、エージェントをDSCCレジストリに追加します。

1. 手順5で指定した正確なパスおよびコマンドを使用してDSCCエージェントを作成します。次に例を示します。

# install-path/bin/dsccagent create
Enter DSCC agent password: ***
Confirm the password: ***
Agent instance install-path/var/dcc/agent has been created successfully
Run the following command to register the agent in the registry: install-path/bin/dsccreg add-agent install-path/var/dcc/agent

2. 新しいDSCCエージェントをDSCCレジストリに登録します。
前の手順の完了時に表示されたコマンドを使用します。次に例を示します。

# install-path/bin/dsccreg add-agent install-path/var/dcc/agent

3. DSCCエージェントを起動します。

# install-path/bin/dsccagent start

9. SNMPエージェントを作成し、SNMPエージェントを使用するためにDirectory Serverインスタンスを構成します。

1. SNMPエージェントを作成します。

# install-path/bin/dsccagent enable-snmp

2. SNMPを介して管理するすべてのDirectory Serverインスタンスを構成します。
次のコマンドを実行し、SNMPを介して管理するインスタンス用のDSポートの番号を取得します。

install-path/bin/dsconf set-plugin-prop dssnmp argument:on argument:3995
Instance Path         :   install-dir/dsee7/var/dcc/agent
Owner                 :   root
JMX port              :   3997
SNMP port             :   3996
DS port               :   3995
State                 :   Stopped
PID                   :   -
DSCC hostname         :   host2
DSCC non-secure port  :   3998
DSCC secure port      :   3999
SNMP v3               :   Disabled
Instance version      :   A-A00

前の手順で取得したDSポート番号を使用し次のコマンドを実行し、ポート番号の引数を設定します。

# install-patch/bin/dsconf set-plugin-prop dssnmp argument:on argument:3995

アップグレードが完了すると、DSCCを起動する際、新しいDSCCエージェントが使用されます。

3 既存の11gリリース1または7.xネイティブ・パッケージのインストールのアップグレード

この章では、ネイティブ・パッケージの配布を使用して、当初インストールした既存の11gリリース1または7.xインストールをアップグレードする方法を説明します。この章の内容は次のとおりです。

- 「アップブレードの準備」

- 「管理(DSCC)ホストのアップグレード」

- 「Directory ServerおよびDirectory Proxy Serverホストのアップグレード」

アップグレード時に発生する事柄の詳細、および様々なアップグレードおよび移行オプションの詳細は、第1章「既存のインストールをアップグレードするか移行するかの決定」を参照してください。

3.1 アップグレードの準備

- 第1.3「アップグレード前および移行前タスクの完了」で説明した問題をすべて解決します。

- Directory Server Enterprise Editionのインストールを所有するユーザー・アカウントからアップグレードを実行します。

- 以降の手順ではprepare-patchという名前のコマンドを実行しますが、実際はパッチを適用するのではなく、ソフトウェアをアップグレードします。

- Directory Service Control Centerをホストしているサーバーを特定します。必ず管理(DSCC)ホストをアップグレードしてから、任意のDirectory ServerホストまたはDirectory Proxy Serverホストをアップグレードします。

- アップグレードを行うには、大きく分けて次の2つの手順を実行する必要があります。

1. 管理(DSCC)ホストのアップグレード

2. 「Directory ServerおよびDirectory Proxy Serverホストのアップグレード」

3.2 管理(DSCC)ホストのアップグレード

1. Cacaoモジュールを停止します。次に例を示します。

バージョン6.xのzip配布の場合

# INSTALL_PATH/dsee6/cacao_2/usr/sbin/cacaoadm stop

バージョン11.1.1.3、11.1.1.5または7.xのzip配布の場合

# INSTALL_PATH/dsee7/bin/cacaoadm stop

# INSTALL_PATH/dsee7/bin/cacaoadm stop

ネイティブ・パッケージのインストールの場合

# /usr/sbin/cacaoadm stop

2. Directory Server Enterprise Edition 11gリリース1 (11.1.1.7.0)をインストールします。
『Oracle Directory Server Enterprise Editionインストレーション・ガイド』の第2章のDirectory Server Enterprise Editionのインストールに関する説明を参照してください。

3. Solaris 10の場合のみ、Active Directory Serverと関連付られているSMFサービスを無効にします。

4. 既存のDSCCレジストリを停止し、その内容をエクスポートします。
変数install-pathでは、既存のDirectory Server Enterprise Editionがインストールされているパスを指定します。

1. 既存のDSCCのレジストリを停止します。

# install-path/bin/dsadm stop install-path/var/dcc/ads

2. 既存のDSCCレジストリのポート番号を記録します。

# native-install-path/bin/dsadm info install-path/var/dcc/ads

3. 既存のDSCCのレジストリの内容をエクスポートします。

# native-install-path/bin/dsadm export /var/opt/SUNWdsee7/dcc/ads cn=dscc /tmp/dscc.ldif

/tmp/dscc.ldifファイルにはサーバーの構成があります。

5. 新しい11g R1 11.1.1.7.0のWARファイルを作成および再デプロイします。

6. DSCC 11gリリース1 (11.1.1.7.0)のレジストリを作成し、前のバージョンのレジストリの内容を入力します。

1. DSCC 11gリリース1 (11.1.1.7.0)のレジストリを、既存のDSCCのレジストリが使用したのと同じポートを使用し作成します。

# install-path/bin/dsccsetup ads-create -p port -P secure-port

portおよびsecure-portの値は、手順2bで記録した値です。

2. レジストリを停止します。

# install-path/bin/dsadm stop install-path/var/dcc/ads

3. /tmp/dscc.ldifファイルをインポートします。

# install-path/bin/dsadm import install-path/var/dcc/ads /tmp/dscc.ldif cn=dscc

4. レジストリを開始します。

# install-path/bin/dsadm start install-path/var/dcc/ads

5. サーバーの登録をすべて確認します。

# install-path/bin/dsccreg list-servers -p port-number

既存のサーバーがすべて表示されます。

6. Directory Serverのインスタンスをすべて表示できます。

# install-path/bin/dsccmon view-servers -p port-number

サーバー・インスタンスは、レガシー・バージョン・インスタンスとして表示されます。

3.3 Directory ServerおよびDirectory Proxy Serverホストのアップグレード

既存のDirectory ServerおよびDirectory Proxy ServerインスタンスをDirectory Server Enterprise Edition 11gリリース1 (11.1.1.7.0)インストールで使用するには、レガシー・インスタンスをすべてアップグレードする必要があります。アップグレード手順では現在の構成が変更されますが、変更を元に戻すことは許可されていません。何らかの問題が発生した時のために、以前のDirectory ServerおよびDirectory Proxy Serverインスタンスをアップグレードする前に、すべてのインスタンスをバックアップしてください。tarまたはcpioなどのファイル・システム・ユーティリティを使用します。次に例を示します。

$ tar cf BACKUP_INSTANCE INSTANCE_DIRECTORY

ネイティブ・パッケージの配布を使用して当初インストールした、既存のバージョン7.xまたは11gリリース1 (11.1.1.5.0または11.1.1.3.0)のDirectory ServerまたはDirectory Proxy Serverインスタンスに、次の手順を繰り返します。

1. Cacaoが実行されているポートを確認し、そのメモを取ります。このポート番号は手順8で必要になります。

$ install-path/bin/dsccsetup status
***
DSCC Agent is registered in Cacao
Cacao uses a custom port number (11168)
***
DSCC Registry has been created
Path of DSCC registry is /var/opt/SUNWdsee7/dcc/ads
Port of DSCC registry is 3998

2. Cacaoモジュールを停止します。次に例を示します。

バージョン6.xのzip配布の場合

# INSTALL_PATH/dsee6/cacao_2/usr/sbin/cacaoadm stop

バージョン11.1.1.3、11.1.1.5または7.xのzip配布の場合

# INSTALL_PATH/dsee7/bin/cacaoadm stop

# INSTALL_PATH/dsee7/bin/cacaoadm stop

ネイティブ・パッケージのインストールの場合

# /usr/sbin/cacaoadm stop

3. ネイティブ・パッケージ・インストールを使用し、ネイティブ・パッケージに固有な機能をすべて無効にします。

- 起動時にインスタンスが開始されるように登録されている場合は、次のコマンドを入力します。

Directory Server

# native-dsee-install-path/bin/dsadm autostart --off INSTANCE_PATH

Directory Proxy Server

# native-dsee-install-path/bin/dpadm autostart --off INSTANCE_PATH

- インスタンスがWindowsサービスとして登録されている場合、次のコマンドを入力します。

Directory Server

# native-dsee-install-path\bin\dsadm.exe disable-service --type WIN_SERVICE INSTANCE_PATH

Directory Proxy Server

# native-dsee-install-path\bin\dpadm.exe disable-service --type WIN_SERVICE INSTANCE_PATH

- インスタンスがSMFサービスとして登録されている場合、次のコマンドを入力します。

Directory Server

# native-dsee-install-path/bin/dsadm disable-service --type SMF INSTANCE_PATH

Directory Proxy Server

# native-dsee-install-path/bin/dpadm disable-service --type SMF INSTANCE_PATH

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

# native-dsee-install-path/bin/dsccsetup prepare-patch

dsccsetup prepare-patchコマンドでは、実行中のすべてのDirectory ServerおよびDirectory Proxy Serverインスタンスの停止が試行されます。

- 次のメッセージが表示された場合、手順4に進みます。

You can now safely patch your installation.

- dsccsetup prepare-patchコマンドにサーバー・インスタンスを停止する権限がない場合、それが失敗したことを示すメッセージが表示され、続行する前にサーバーを手動で停止する必要があります。手順3に進みます。

5. 前の手順のprepare-patchコマンドによってサーバーが停止されなかった場合、次のいずれかのコマンドを実行し、サーバーを確実に停止します。

Directory Serverを停止するには、次のコマンドを実行します。

# native-dsee-install-path/bin/dsadm stop INSTANCE_PATH

プロキシ・サーバーを停止するには、次のコマンドを実行します。

# native-dsee-install-path/bin/dpadm stop INSTANCE_PATH

6. 次のコマンドを入力し、Directory Server Enterprise Editionソフトウェアをインストールします。

# cd TEMP_DIRECTORY
# unzip -q ODSEE11_1_1_7_0_xxx.zip
# cd ODSEE_ZIP_Distribution
# unzip -q sun-dsee7.zip -d install-path
# cd install-path/dsee7

7. サーバー・インスタンスをアップグレードします。次に例を示します。

# install-path/bin/dsadm upgrade [-i] instance-path

8. 新しいDSCCエージェントを作成し、エージェントをDSCCレジストリに追加します。

1. 可能な場合Cacaoと同じポートを使用し、DSCCエージェントを作成します(手順1を参照)。

# install-path/bin/dsccagent create -p 11168
Enter DSCC agent password: ***
Confirm the password: ***
Agent instance install-path/var/dcc/agent has been created successfully
Run the following command to register the agent in the registry: install-path/bin/dsccreg add-agent install-path/var/dcc/agent

2. 新しいDSCCエージェントをDSCCレジストリに登録します。
前の手順の完了時に表示されたコマンドを使用します。次に例を示します。

# install-path/bin/dsccreg add-agent install-path/var/dcc/agent

3. 新しいDSCCエージェントがCacaoと同じポートをリスニングしない場合、次のコマンドを実行します。

# install-path/bin/dsccreg add-server

4. DSCCエージェントを起動します。

# install-path/bin/dsccagent start

9. SNMPエージェントを作成し、SNMPエージェントを使用するためにDirectory Serverインスタンスを構成します。

1. SNMPエージェントを作成します。

# install-path/bin/dsccagent enable-snmp

2. SNMPを介して管理するすべてのDirectory Serverインスタンスを構成します。
次のコマンドを実行し、SNMPを介して管理するインスタンス用のDSポートの番号を取得します。

# install-path/bin/dsccagent info
Instance Path         :   install-dir/dsee7/var/dcc/agent
Owner                 :   root
JMX port              :   3997
SNMP port             :   3996
DS port               :   3995
State                 :   Stopped
PID                   :   -
DSCC hostname         :   host2
DSCC non-secure port  :   3998
DSCC secure port      :   3999
SNMP v3               :   Disabled
Instance version      :   A-A00

前の手順で取得したDSポート番号を使用し次のコマンドを実行し、ポート番号の引数を設定します。

# install-path/bin/dsconf set-plugin-prop dssnmp argument:on argument:3995

アップグレードが完了すると、DSCCを起動する際、新しいDSCCエージェントが使用されます。

4 既存の6.x zipまたはネイティブ・パッケージのインストールのアップグレード

この章では、zipまたはネイティブ・パッケージの配布を使用して、最初にインストールされていた既存のバージョン6.xインストールをアップグレードする方法を説明します。この章の内容は次のとおりです。

- 「アップブレードの準備」

- 「管理(DSCC)ホストのアップグレード」

- 「Directory ServerおよびDirectory Proxy Serverホストのアップグレード」

- 「サポート対象外のプラットフォームでのDirectory Server Enterprise Edition 6のアップグレード」

アップグレード時に発生する事柄の詳細、および様々なアップグレードおよび移行オプションの詳細は、第1章「既存のインストールをアップグレードするか移行するかの決定」を参照してください。

4.1 アップグレードの準備

- 第1.3「アップグレード前および移行前タスクの完了」で説明した問題をすべて解決します。

- Directory Server Enterprise Editionのインストールを所有するユーザー・アカウントからアップグレードを実行します。

- Directory Service Control Centerをホストしているサーバーを特定します。Directory ServerホストまたはDirectory Proxy Serverホストをアップグレードする前に、必ず管理(DSCC)ホストをアップグレードします。

- アップグレードを行うには、大きく分けて次の2つの手順を実行する必要があります。

1. 管理(DSCC)ホストのアップグレード

2. サポート対象外のプラットフォームでのDirectory Server Enterprise Edition 6のアップグレード

4.2 管理(DSCC)ホストのアップグレード

DSCCを使用し、Directory Server Enterprise Edition 11gリリース1 (11.1.1.7.0)インスタンスをアップグレードするには、DSCC 6をバージョン11gリリース1 (11.1.1.7.0)にアップグレードする必要があります。

DSCC 11gリリース1 (11.1.1.7.0)を使用すると、バージョン6、7.0および11gリリース1 (11.1.1.5.0 and 11.1.1.3.0)のインスタンスにアクセスできます。

1. Cacaoモジュールを停止します。次に例を示します。

バージョン6.xのzip配布の場合

# INSTALL_PATH/dsee6/cacao_2/usr/sbin/cacaoadm stop

バージョン11.1.1.3、11.1.1.5または7.xのzip配布の場合

# INSTALL_PATH/dsee7/bin/cacaoadm stop

# INSTALL_PATH/dsee7/bin/cacaoadm stop

ネイティブ・パッケージのインストールの場合

# /usr/sbin/cacaoadm stop

2. Directory Server Enterprise Edition 11gリリース1 (11.1.1.7.0)をインストールします。
詳細は、『Oracle Directory Server Enterprise Editionインストレーション・ガイド』のDirectory Server Enterprise Editionのインストールに関する説明を参照してください。

3. Solaris 10の場合のみ、Active Directory Serverと関連付られているSMFサービスを無効にします。

4. DSCC 6レジストリを停止し、その内容をエクスポートします。
dsee6-install-pathは、Directory Server Enterprise Edition 6のインストール先のパスを指定します。

1. DSCC 6レジストリを停止します。

# dsee6-install-path/ds6/bin/dsadm stop dsee6-install-path/var/dscc6/dcc/ads

2. DSCC 6レジストリのポート番号を記録します。

# dsee6-install-path/ds6/bin/dsadm info dsee6-install-path/var/dscc6/dcc/ads

3. DSCC 6レジストリの内容をエクスポートします。

# dsee6-install-path/ds6/bin/dsadm export dsee6-install-path/var/dscc6/dcc/ads cn=dscc /tmp/dscc.ldif

/tmp/dscc.ldifファイルにはサーバー構成が含まれます。

5. バージョン6のレジストリの内容でDSCC 11gリリース1 (11.1.1.7.0)のレジストリを作成および入力します。

1. DSCC 6のレジストリで使用されている同じポートを使用し、DSCC 11gリリース1 (11.1.1.7.0)レジストリを作成します。

# install-path/bin/dsccsetup ads-create -p port -P secure-port

2. レジストリを停止します。

# install-path/bin/dsadm stop install-path/var/dcc/ads

3. /tmp/dscc.ldifファイルをインポートします。

# install-path/bin/dsadm import install-path/var/dcc/ads /tmp/dscc.ldif cn=dscc

4. レジストリを開始します。

# install-path/bin/dsadm start install-path/var/dcc/ads

5. サーバーの登録をすべて確認します。

# install-path/bin/dsccreg list-servers -p port-number

既存のサーバーがすべて表示されます。登録はすべてバージョン6の登録です。

6. Directory Serverのインスタンスをすべて表示できます。

# install-path/bin/dsccmon view-servers -p port-number

サーバー・インスタンスはバージョン6のインスタンスとして表示されます。

6. サポート対象のアプリケーション・サーバーをインストールし、DSCC 11gリリース1 (11.1.1.7.0) WARファイルをデプロイします。
『Oracle Directory Server Enterprise Editionインストレーション・ガイド』の付録AのDSCC WARファイルのデプロイに関する説明を参照してください。

zipの配布を使用してインストールしたDSCCをアップグレードした場合、ルートとしてDSCCにアクセスする必要があります。

7. Directory Server Enterprise Edition 6をアンインストールします。
詳細は、『Directory Server Enterprise Edition 6インストレーション・ガイド』を参照してください。

4.3 Directory ServerおよびDirectory Proxy Serverホストのアップグレード

次の手順は、Solarisオペレーティング・システム上のネイティブ・パッケージ・ベースのインスタンスをSolarisオペレーティング・システム上のzip配布ベースのインスタンスにアップグレードするために有効です。

1. Cacaoモジュールを停止します。次に例を示します。

バージョン6.xのzip配布の場合

# INSTALL_PATH/dsee6/cacao_2/usr/sbin/cacaoadm stop

バージョン11.1.1.3、11.1.1.5または7.xのzip配布の場合

# INSTALL_PATH/dsee7/bin/cacaoadm stop

# INSTALL_PATH/dsee7/bin/cacaoadm stop

ネイティブ・パッケージのインストールの場合

# /usr/sbin/cacaoadm stop

2. Directory Server Enterprise Edition 11gリリース1 (11.1.1.7.0)をインストールします。

3. ネイティブ・パッケージを使用して作成したバージョン6インスタンスを11gリリース1 (11.1.1.7.0) zip配布のインスタンスにアップグレードする前に、バージョン6のネイティブ・パッケージ・インストールを使用し、ネイティブ・パッケージに固有のすべての機能を無効にします。

- 起動時に起動されるようインスタンスが登録されている場合、次のコマンドを入力します。

$ install-path/bin/dsadm autostart --off INSTANCE_PATH

- インスタンスがWindowsサービスとして登録されている場合、次のコマンドを入力します。

$ install-path/bin/dsadm disable-service --type WIN_SERVICE INSTANCE_PATH

- インスタンスがSMFサービスとして登録されている場合、次のコマンドを入力します。

$ install-path/bin/dsadm disable-service --type SMF INSTANCE_PATH

- インスタンスがクラスタに登録されている場合、次のコマンドを入力します。

$ install-path/bin/dsadm disable-service --type CLUSTER INSTANCE_PATH

4. バージョン11gリリース1 (11.1.1.7.0)のインストールから次のコマンドを入力し、Directory Serverインスタンスをアップグレードします。

$ install-path/bin/dsadm upgrade [-i] INSTANCE_PATH

たとえば、/local/exampleインスタンスをアップグレードするには、次のコマンドを入力します。

# install-path/bin/dsadm upgrade /local/example
Directory Server instance '/local/example' will be upgraded to version 11g Release 1 (11.1.1.7.0).
It will no longer be usable with DSEE 6 commands.
Moving legacy scripts into '/local/example/bak/2011-03-28-01-45-18' ...
Adding new files to instance ...
Upgrading dse.ldif ...
Old version of dse.ldif has been moved into '/local/example/bak/2011-03-28-01-45-18'.
Upgrading dse.ldif ...
Old version of dse.ldif has been moved into '/local/example/bak/2011-03-28-01-45-18'.
Old version of 00core.ldif has been moved into '/local/example/bak/2011-03-28-01-45-18'.
Directory Server instance '/local/DSEE-2011-03-28-01-26/instances/SSL_02' is now ready to be used with ODSEE 11g Release 1 (11.1.1.7.0) comm

dsadm upgradeコマンドで—iを使用し、警告メッセージを抑制します。

5. 新しいDSCCエージェントを作成し、エージェントをDSCCレジストリに追加します。

1. DSCCエージェントを作成します。

# install-path/bin/dsccagent create
Enter DSCC agent password: ***
Confirm the password: ***
Agent instance install-path/var/dcc/agent has been created successfully
Run the following command to register the agent in the registry: install-path/bin/dsccreg add-agent install-path/var/dcc/agent

2. 新しいDSCCエージェントをDSCCレジストリに登録します。
前の手順の完了時に表示されたコマンドを使用します。次に例を示します。

# install-path/bin/dsccreg add-agent install-path/var/dcc/agent

3. 新しいDSCCエージェントがCacaoとは同じ部分をリスニングしない場合、次のコマンドを実行します。

# install-path/bin/dsccreg add-server

6. SNMPエージェントを作成し、SNMPエージェントを使用するためにDirectory Serverインスタンスを構成します。

1. SNMPエージェントを作成します。

# install-path/bin/dsccagent enable-snmp

2. SNMPを介して管理するすべてのDirectory Serverインスタンスを構成します。
次のコマンドを実行し、SNMPを介して管理するインスタンス用のDSポートの番号を取得します。

# install-path/bin/dsccagent info
Instance Path         :   install-dir/dsee7/var/dcc/agent
Owner                 :   root
JMX port              :   3997
SNMP port             :   3996
DS port               :   3995
State                 :   Stopped
PID                   :   -
DSCC hostname         :   host2
DSCC non-secure port  :   3998
DSCC secure port      :   3999
SNMP v3               :   Disabled
Instance version      :   A-A00

前の手順で取得したDSポート番号を使用し次のコマンドを実行し、ポート番号の引数を設定します。

# install-patch/bin/dsconf set-plugin-prop dssnmp argument:on argument:3995

7. システム・コマンドでDirectory Server Enterprise Edition 6を削除します。次に例を示します。
# rm -r install-path

8. (オプション)アップグレード前に何らかのサービスを無効にしている場合、それらをこの時点で再度有効にします。

アップグレードが完了すると、DSCCを起動する際、新しいDSCCエージェントが使用されます。

Directory Server 6はRFC 4522に準拠していません。

バージョン11gリリース1 (11.1.1.7.0)にアップグレード後、バージョン6の次の動作が維持されます。

検索結果でバイナリ属性を返すとき、Directory Server 6はRFC 4522には準拠されていません。この動作を維持するために、デフォルトでcompat-flagのDirectory Server構成はno-rfc4522に設定されています。compat-flagの値を確認するには、次のコマンドを参照してください。

$ dsconf get-server-prop -p port compat-flag

compat-flagプロパティの詳細は、サーバーに関する説明を参照してください。

アップグレードしたインスタンスはリストアできない

レガシー・インスタンスは一度アップグレードすると、前のインストールに戻せません。

次のdsadmコマンドを使用する前には、レガシー・インスタンスをアップグレードする必要はありません。

- info
- stop
- disable-service
- autostart --off
- get-flags
- set-flags
- add-cert
- add-selfsign-cert
- export-cert
- import-cert
- import-selfsign-cert
- list-certs
- remove-cert
- renew-cert
- renew-selfsign-cert
- request-cert/show-cert
- show-access-log
- show-error-log
- delete

アップグレードしたインスタンスをDSCC 11gリリース1 (11.1.1.7.0)で使用するには、DSCC 6からDirectory Serverインスタンスを登録解除し、DSCC 11gリリース1 (11.1.1.7.0)に登録する必要があります。登録および登録解除の詳細は、dsccregに関する説明を参照してください。

4.4 サポート対象外のプラットフォームでのDirectory Server Enterprise Edition 6のアップグレード

Directory Server Enterprise Edition 11gリリース1 (11.1.1.7.0)では、一部のプラットフォームがサポート対象外となっています。既存のデータとインスタンスを使用するには、特定の操作を実行する必要があります。

サポート対象のプラットフォームの詳細は、ODSEEの保証マトリックス(http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html)を参照してください。

要件に応じ、次の手順を参照してください。

- レガシー・オペレーティング・システムからのDirectory Server Enterprise Editionのアップグレード

- 32ビットのサーバー・インスタンスのアップグレード

4.4.1 レガシー・オペレーティング・システムからのDirectory Server Enterprise Editionのアップグレード

サポート対象のオペレーティング・システムの詳細は、ODSEEの保証マトリックス(http://www.oracle.com/technetwork/middleware/ias/downloads/fusion-certification-100350.html)を参照してください。

1. Directory ServerおよびDirectory Proxy Serverのインスタンスを停止します。

2. ファイル・システム全体のバックアップを取ります。
詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のバイナリ・バックアップのファイル・システムのバックアップに関する説明を参照してください。

Directory Proxy Serverインスタンスのみをアップグレードする場合は、dpadm backupコマンドのみを使用します。

3. オペレーティング・システムのバージョンをアップグレードするか、サポート対象のオペレーティング・システム・バージョンがインストールされている別のマシンを選択します。

注意:

同じマシンでオペレーティング・システムをアップグレードする場合は、バックアップ・データの他のマシンへのバックアップを忘れないでください。

4. Directory Server Enterprise Edition 11gリリース1 (11.1.1.7.0)をインストールします。
ソリューションに応じ、次の任意の手順を参照します。

- インストール可能な配布の種類を確認するには、前のインストールとプラットフォームの組合せに応じて、『Oracle Directory Server Enterprise Editionリリース・ノート』のハードウェアおよびオペレーティング・システムの要件に関する説明を参照してください。

- 詳細なインストール手順は、『Oracle Directory Server Enterprise Editionインストレーション・ガイド』を参照してください。

5. 手順2でバックアップしたファイル・システムをリストアします。
Directory Proxy Serverインスタンスの場合のみは、dpadm restoreを使用してリストアできます。

6. レガシー・サーバー・インスタンスをアップグレードします。

- Directory Serverインスタンスの場合:

install-path/bin/dsadm upgrade INSTANCE_PATH

- Directory Proxy Serverインスタンスの場合:

install-path/bin/dpadm upgrade INSTANCE_PATH

4.4.2 32ビットのサーバー・インスタンスのアップグレード

64ビットのRed Hat Enterprise LinuxまたはSUSE Linux Enterprise Editionオペレーティング・システム上で実行されているDirectory Server Enterprise Edition 6の32ビット・サーバー・インスタンスを直接アップグレードする方法はありません。ただし、サーバー・インスタンスを完全に自動アップグレードできない場合でも、dsadm upgradeおよびdpadm upgradeコマンドを使用することによってサーバー構成を正しくアップグレードできます。

このようなインスタンスのアップグレード手順の詳細は、次を参照してください。

1. Directory Serverインスタンスがデータベース用にデフォルトではないディレクトリを使用するよう構成されている場合、次のパスのメモを取ります。

- データベースの場合:

DSEE_6_install-path/ds6/bin/dsconf get-server-prop -p port-number db-env-path db-log-path

- 各サフィックスの場合:

DSEE_6_install-path/ds6/bin/dsconf get-suffix-prop -p port-number SUFFIX_DN db-path

2. バージョン6のインストールを使用し、データをエクスポートします。

DSEE_6_install-path/ds6/bin/dsadm export INSTANCE_PATH SUFFIX_DN LDIF_FILE

3. すべてのインスタンスのバックアップを取ります。

$ tar cf BACKUP_INSTANCE INSTANCE_DIRECTORY

4. レガシー・サーバー・インスタンスをアップグレードします。

注意:

カスタマイズしたスキーマがある場合、それも手動でアップグレードする必要があります。カスタマイズしたスキーマをアップグレードする方法の詳細は、ご使用のDirectory Server Enterprise Editionのバージョンのマニュアルを参照してください。以前のSun Identity Managementのマニュアルは、http://www.oracle.com/technetwork/documentation/legacy-sun-identity-mgmt-193462.htmlのWebページを参照してください。

- Directory Serverインスタンスの場合:

DSEE_7_install-path/bin/dsadm upgrade INSTANCE_PATH

- Directory Proxy Serverインスタンスの場合:

DSEE_7_install-path/bin/dpadm upgrade INSTANCE_PATH

5. Directory Serverインスタンスがデータベース用にデフォルトではないディレクトリを使用するよう構成されている場合、構成はリセットされていますが、削除はされていません。デフォルトでないディレクトリを使用するようインスタンスを再構成する前に、古いデータベース、キャッシュおよびトランザクション・ログをすべて削除する必要があります。

6. バージョン11gリリース1 (11.1.1.7.0)サーバー・インスタンスにデータをインポートします。
各サフィックスの場合:

install-path/bin/dsadm import INSTANCE_PATH LDIF_FILE SUFFIX_DN

関連項目

「手動でのユーザー・データの移行」

第II部

ODSEE 5.2からODSEE 11gリリース1 (11.1.1.7.0)への移行

この部では、バージョン5.2および5.2以降のすべてのリリースからの11gリリース1 (11.1.1.7.0)への移行に関する情報を説明します。このドキュメントのこの部で、バージョン5.2とはバージョン5.2およびそれ以降のすべてのバージョンを指します。

移行手順では、元のインスタンスに対する変更はなく、11gリリース1 (11.1.1.7.0)インストールで使用する新しいインスタンスが作成されます。必要に応じて元のインスタンスも使用し続けられます。

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

- 第5章「Directory Serverの移行プロセスの概要」では、Directory Serverの移行手順を説明します。

- 第6章「dsmigコマンドを使用した自動移行」では、移行ツールの使用方法を説明します。

- 第7章「手動でのDirectory Serverの移行」では、サーバーの各部分を手動で移行する手順を説明します。

- 第8章「レプリケーション・トポロジの移行」では、レプリケーション・トポロジの移行方法およびレプリケート対象のサーバーの移行に関連する問題について説明します。

- 第9章「Directory Serverに対するバージョン5.2以降のアーキテクチャ変更」では、以前のバージョンからの移行に影響するアーキテクチャの変更について説明しています。

- 第10章「Directory Proxy Serverの移行」では、Directory Proxy Serverの移行について説明します。

- 第11章「Identity Synchronization for Windowsの移行」では、Identity Synchronization for Windowsの移行について説明します。

5 Directory Serverの移行プロセスの概要

この章では、バージョン5.2をOracle Directory Server Enterprise Edition 11gリリース1 (11.1.1.7.0)に移行する手順を説明します。ODSEE 11gリリース1 (11.1.1.7.0)には、特定のプラットフォームとバージョンの組合せの移行に関する側面を自動化する、dsmigという移行ツールがあります。トポロジのサーバーがこれらの組合せに該当しない場合、同じ手順を手動で実行する必要があります。

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

- 「移行の準備」

- 「新製品の配布」

- 「移行手順の概要」

- 「自動または手動移行の判断」

5.1 移行の準備

この章では、アップグレードおよびデータの移行手順の概要を示します。

アップグレードを行う前に、現在のバージョンの新機能および修正を把握しておいてください。この機会を利用し、既存のディレクトリ・サービスを実装した際に決定した設計を見直してください。すべての新機能および修正の詳細は、『Oracle Directory Server Enterprise Editionリリース・ノート』の第1章のOracle Directory Server Enterprise Edition 11gリリース1 (11.1.1.7.0)の新機能に関する説明を参照してください。移行に特に影響する新機能の詳細は、第9章「Directory Serverに対するバージョン5.2以降のアーキテクチャ変更」を参照してください。

5.1.1 単一のDirectory Serverインスタンスを移行するための前提条件

サーバー・インスタンスの移行前に、次の前提条件が満たされていることを確認します。

- Directory Server 11gリリース1 (11.1.1.7.0)がインストールされています。新しいサーバーは、既存のサーバーと同じマシンにインストールすることも別のマシンにインストールすることも可能です。

- 新しいマシンには、新旧の両サーバーのバイナリおよびデータベースを保持する十分なローカル・ディスク・スペースがあり、既存のすべてのサフィックスのエントリを含むLDIFファイルを保持する余分な領域があります。次の計算より幾分大きいローカル・ディスク領域が必要です。

local space required = 2 * (space for existing server) + (space for LDIF files)

- 自動移行ツールを使用する場合、次の前提条件が満たされている必要があります。

- 既存のサーバー・インスタンスはクリーンに停止する必要があります。

- 新しいサーバーが別のマシンにある場合、新しいマシンに元のサーバー・インスタンスの完全なイメージを作成する必要があります。これには、元のサーバー・ルートと同一のレイアウトの、すべてのスキーマ・ファイル、構成ファイル、セキュリティ・ファイル、データベース・ファイルが含まれます。

自動移行または手動移行のどちらを使用するか決定するには、「自動または手動移行の判断」を参照してください。

- Directory ServerのデプロイメントにIdentity Synchronization for Windowsが含まれる場合、Directory Serverの移行の前に、Identity Synchronization for Windowsをアンインストールする必要があります。Identity Synchronization for Windowsの移行の詳細は、第11章「Identity Synchronization for Windowsの移行」を参照してください。

5.2 新製品の配布

Directory Server 11gリリース1 (11.1.1.7.0)は、圧縮したアーカイブ(zip)で配布されます。

zipからのインストールは、ルート以外のユーザーとして、システムの任意の場所から実行できます。zipの配布は必要に応じて何度もインストールでき、単一のオペレーティング・システム・インスタンスに同じ製品の別のバージョンを複数共存させることが可能です。

5.3 移行手順の概要

Directory Serverの移行は、次の個別の手順に分けることができます。

1. スキーマの移行

2. セキュリティ設定の移行

3. 構成の移行

4. データの移行

5. プラグインの移行

6. 移行後のタスク

移行で予期しない問題が発生しないようにするには、前述の順でこれらの手順を実行する必要があります。特定のケースでは、dsmigコマンドでこれらの一部またはすべての手順を自動化できます。次の項に、既存のデプロイメントにおいて自動化できることおよび手動で実行する必要のあることを示します。

5.4 自動または手動移行の判断

この項では、どのようなときにdsmigを使用できるか、およびどのようなときに手動で移行する必要があるかを示します。これでは、前の項で示した移行手順を使用しています。

表5-1 自動移行のサポートを示す移行マトリックス

移行先

移行手順

ソフトウェア(32/64ビット)

OS

スキーマ

構成

セキュリティ

データ

プラグイン

任意

任意

手動

手動

手動

手動

手動

別

任意

dsmig

dsmig

dsmig

手動

手動

同じ

別

dsmig

dsmig

dsmig

手動

手動

同じ

同じ

dsmig

dsmig

dsmig

dsmig

手動

後述の2つの章では、上の移行手順を自動または手動で実行する方法をそれぞれ説明します。自動移行の詳細は、第6章「dsmigコマンドを使用した自動移行」を参照してください。手動での移行の詳細は、第7章「手動でのDirectory Serverの移行」を参照してください。

6 dsmigコマンドを使用した自動移行

Oracle Directory Server Enterprise Edition11gリリース1 (11.1.1.7.0)には、Directory Server 5.2インスタンスからODSEE 11gリリース1 (11.1.1.7.0)インスタンスへの移行を支援をするコマンドラインによる移行ツールが用意されています。この移行ツールは、「自動または手動移行の判断」で説明する自動移行の要件がデプロイメントで満たされている場合のみ使用することができます。

移行ツールでは、インスタンスごとに移行を行うことができます。同じサーバー・ルートにインスタンスが複数ある場合、インスタンスごとに移行ツールを実行する必要があります。

この章では、移行ツールの使用方法を次の内容で説明します。

- 「自動移行ツールについて」

- 「dsmigを実行する前提条件」

- 「スキーマを移行するためのdsmigの使用」

- 「セキュリティ・データを移行するためのdsmigの使用」

- 「構成データを移行するためのdsmigの使用」

- 「ユーザー・データを移行するためのdsmigの使用」

- 「自動移行後に実行するタスク」

6.1 自動移行ツールについて

移行ツール、dsmigはDirectory Server Enterprise Edition 11gリリース1 (11.1.1.7.0)とともに配布されます。これらのODSEEがインストールされると、dsmigはinstall-path/binに配置されます。

dsmigコマンドは、新しいDirectory Serverインスタンスが配置されるマシンで実行する必要があります。コマンドを実行すると、新しいインスタンス・ディレクトリ(new-instance-path/migration)に移行ディレクトリが作成されます。このディレクトリは、移行で生成されたログ・ファイルや移行ステータス・ファイルなどのためのデータ・リポジトリになります。

dsmigコマンドには、「移行手順の概要」で説明している個々の移行手順に対応するサブコマンドおよびオプションのセットがあります。dsmigの使用方法の詳細は、dsmigに関する説明を参照してください。

6.2 dsmigを実行するための前提条件

この項では、古いインスタンスは5.2インスタンスのことを指し、新しいインスタンスはDirectory Server 11gリリース1 (11.1.1.7.0)のインスタンスを指します。

インスタンスを移行するためにdsmigを使用する前に、次の作業が実行済であることを確認してください。

- Directory Server Enterprise Edition 11gリリース1 (11.1.1.7.0)がインストール済です。
Directory Server Enterprise Edition 11gリリース1 (11.1.1.7.0)は、古いインスタンスがある同じマシンにも別のマシンにもインストールできます。

- 古いインスタンスを正しく停止しています。
古いインスタンスを順を追ってシャットダウンしていない場合、移行で問題が発生する場合があります。古いインスタンスと新しいインスタンスが別のマシンにある場合でも、移行の開始前に古いインスタンスを停止している必要があります。

- dsmigが古いインスタンス・ファイルにアクセスできます。

- 古いインスタンスと新しいインスタンスが別のマシン上にある場合、新しいインスタンスをホストするマシンに古いインスタンスの完全なイメージが作成されています。
完全なイメージには、インスタンスの移行に必要なすべてのファイル(スキーマ、構成、セキュリティおよびデータベース・ファイル)が含まれます。完全なイメージ・ファイルは、元のサーバー・ルートと同じディレクトリに配置する必要があります。これを実現するには、サーバー・ルート外にいかなるファイルも再配置していないことを条件に、cp -rを実行できます。

新しいインスタンスの作成および起動は手動で実行できますが、dsmigの実行前に新しいインスタンスを必ず作成する必要はありません。dsmigでは、新しいDirectory Serverインスタンスが指定のパスに存在するか確認します。新しいインスタンスが存在する場合、このインスタンスに対してコマンドが実行されます。新しいインスタンスが存在しない場合、インスタンスは自動的に作成されます。

新しいインスタンスは、古いインスタンスがあった場所を除く任意の場所に作成できます。

注意:

dsmigコマンドでは、インスタンスの作成にデフォルトで389および636のポートを使用します。これらのポートがすでに使用されている場合、インスタンスの作成に別のポートを用意してください。詳細は、dsmigに関する説明を参照してください。

新しいインスタンスを作成する際、ディレクトリ・マネージャのDNとパスワードは、cn=config下のnsslapd-rootdnおよびnssalpd-rootpw属性に保存されます。これらの属性には新しいインスタンスの値がすでにあるので、移行時には古いインスタンスの値は伝播されません。nsslapd-secureportおよびnsslapd-port属性に対しても同じ動作が取られます。

6.3 スキーマを移行するためのdsmigの使用

Directory Server 5.2のスキーマ・ファイルはserverRoot/slapd-instance-path/config/schemaに配置されています。Directory Server 11gリリース1 (11.1.1.7.0)のスキーマ・ファイルは、INSTANCE-PATH/config/schemaに配置されています。

Directory Server 11gリリース1 (11.1.1.7.0)には、パスワードのポリシー属性を含む00ds6pwp.ldifというスキーマ・ファイルがあります。これに加え、特定の構成属性が追加された00core.ldifがあります。

スキーマを自動的に移行するには、次のコマンドを実行します。

$ dsmig migrate-schema old-instance-path new-instance-path

このコマンドを実行すると、99user.ldifファイルにカスタム・スキーマが定義されている場合、それが新しいインスタンスにコピーされます。新しいインスタンスがすでに本番環境にあり、新しいインスタンスの99user.ldifファイルをすでに変更している場合、dsmigでは2つのファイルが最適にマージされます。他の任意のファイルに定義されたカスタム・スキーマも、新しいインスタンスにコピーされます。

詳細は、dsmigに関する説明を参照してください。

6.4 セキュリティ・データを移行するためのdsmigの使用

セキュリティ設定を自動的に移行するには、次のコマンドを実行します。

$ dsmig migrate-security old-instance-path new-instance-path

セキュリティ設定の移行時に、dsmigは次のタスクを実行します。

- 新しいインスタンスの証明書およびデータベース・ファイルをバックアップします。

- 証明書データベースおよびキー・データベース・ファイルを古いインスタンスから新しいインスタンスにコピーします。

- パスワード・ファイルを古いインスタンスから新しいインスタンスにコピーします。

- 証明書マッピング・ファイルを古いインスタンスから新しいインスタンスにコピーします。

- セキュリティ・モジュール・データベースをコピーします。

詳細は、dsmigに関する説明を参照してください。

6.5 構成データを移行するためのdsmigの使用

Directory Server 5.2の構成はserverRoot/slapd-instance-path/config/dsee.ldifファイルに指定されています。Directory Server 11gリリース1 (11.1.1.7.0)の構成は、instance-path/config/dsee.ldifファイルに指定されています。

構成を自動的に移行するには、次のコマンドを実行します。

$ dsmig migrate-config old-instance-path new-instance-path

この手順では、dsmigは古いインスタンスの構成ファイル(dsee.ldif)のLDIFのエントリをそれぞれ読み取ります。対応するDirectory Server 11gリリース1 (11.1.1.7.0)の構成ファイルにこれらのエントリがある場合、その値は更新されます。

注意:

dsmig migrate-configコマンドでは、サーバーをread-writeモードにリセットします。移行後に次のコマンドを実行すると、サーバーをread-onlyモードに切り替えることができます。

$ dsconf set-server-prop read-write-mode:read-only

構成の移行はLDAPを介して実行されます。dsmigは、デフォルトではStartTLSを発行して新しいインスタンスをセキュアにバインドします。

注意:

Windowsでは、StartTLSはデフォルトでは有効ではありません。Windowsでdsmigを実行している場合、セキュリティ保護されない接続を指定するには、-eまたは--unsecuredオプションを使用します。または、SSLを介したセキュリティ保護された接続を指定するには、-Zまたは--use-secure-portオプションを使用します。Windowsでこれらのいずれのオプションも使用しない場合、dsmigによって警告が発行され、移行プロセスはエラーで終了します。

詳細は、dsmigに関する説明を参照してください。移行される具体的な構成属性の詳細は、「特定の構成属性の移行」を参照してください。

6.5.1 プラグインの構成データ

dsmigでは、Directory Serverの一部のプラグインのみを移行します。ほとんどのシステム・プラグインの構成データは、自動では移行されません。

dsmigでは次のシステム・プラグインを移行します。

- CoS

- 7ビット検索

- DSML Frontend

- パススルー認証

- 参照整合性

- レトロ変更ログ

- UID一意性

構成をverboseモードで移行した場合、dsmigではどのシステム・プラグイン構成が移行されないかを示す警告を発行します。

ユーザーが作成したプラグインは移行されません。ただし、ユーザーのプラグインの構成データは、移行時にnew-instance-path/migration/old_userplugins_conf.ldifファイルにダンプされます。これらのプラグインは、移行の完了後に再コンパイルする必要があります。

6.5.2 複数のバックエンドを持つサフィックスの構成データ

複数のバックエンドを持つサフィックスの構成データは移行されません。dsmigがサフィックスに複数のバックエンドがあることを検出した場合、そのサフィックスに属する構成設定は移行されません。これらは、マッピング・ツリー、レプリカ、レプリケーション承諾、LDBMインスタンス、インデックスおよび暗号化属性の構成エントリです。かわりに、これらのすべてのエントリはnew-instance-path/migration/old_distribution_conf.ldifファイルにダンプされます。

old_distribution_conf.ldifファイルのエントリは、古いインスタンスのものであるため、新しいインスタンスには直接インポートしないようにする必要があります。配布の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の第21章のDirectory Proxy Serverの配布に関する説明を参照してください。

6.5.3 レプリケーションの構成データ

レプリケーションの構成データは、デフォルトでは移行されません。これらのデータを移行するには、-Rオプションとともにdsmigを使用します。データは、デフォルトでnew-instance-path/migration/old_replication_conf.ldifファイルにダンプされます。必要に応じて、このファイルのレプリケーションの構成データは移行後にインポートできます。

6.5.4 o=netscapeRootの構成データ

o=NetscapeRootサフィックスの構成データはデフォルトでは移行されません。この情報が必要な場合、構成データの移行に-Nオプションを使用します。-Nオプションを使用しない場合、データはnew-instance-path/migration/old_netscape_conf.ldifのファイルにダンプされます。必要に応じて、このファイルの構成データは移行後にインポートできます。

6.5.5 dsmigが移行しない構成属性

次の一般的な構成属性は、自動では移行されません。

このリストは、すべてを網羅したものではありません。手動で移行する必要のある構成属性は、他にも使用している可能性があります。

ds-hdsml-dsmlschemalocation
ds-hdsml-soapschemalocation
dsKeyedPassword
dsMappedDN
dsMatching-pattern
dsMatching-regexp
dsSaslPluginsEnable
dsSaslPluginsEnable
dsSaslPluginsPath
dsSearchBaseDN
dsSearchFilter
nsabandonedsearchcheckinterval
nsbindconnectionslimit
nsbindretrylimit
nsbindtimeout
nschecklocalaci
nsconcurrentbindlimit
nsconcurrentoperationslimit
nsconnectionlife
nshoplimit
nsMatchingRule
nsmaxresponsedelay
nsmaxtestresponsedelay
nsoperationconnectionslimit
nspossiblechainingcomponents
nspossiblechainingcomponents
nspossiblechainingcomponents
nspossiblechainingcomponents
nspossiblechainingcomponents
nspossiblechainingcomponents
nsproxiedauthorization
nsreferralonscopedsearch
nsslapd-db-durable-transaction
nsslapd-db-home-directory
nsslapd-db-replication-batch-val
nsslapd-db-transaction-logging
nsslapd-directory
nsslapd-disk-full-threshold
nsslapd-disk-low-threshold
nsslapd-exclude-from-export
nsslapd-localhost
nsslapd-localuser
nsslapd-mode
nsslapd-port
nsslapd-rewrite-rfc1274
nsslapd-secureport
nsslapd-security
nsSSL2
nsSSL3
nsSSLActivation
nsSSLServerAuth
nsSSLSessionTimeout
nsState
nstransmittedcontrols
plugin-order-preoperation-finish-entry-encode-result

6.6 ユーザー・データを移行するためのdsmigの使用

Directory Server 5.2では、データはserverRoot/slapd-instance-name/dbに格納されます。Directory Server 11gリリース1 (11.1.1.7.0)では、ユーザー・データはinstance-path/dbに格納されます。

データを自動的に移行するには、次のコマンドを実行します。

$ dsmig migrate-data old-instance-path new-instance-path

デフォルトでは、o=netscapeRootサフィックスを除くすべてのサフィックスが移行されます。dsmigでは、データ、インデックス、トランザクション・ログがコピーされます。データベースの状態であるデータベース・コンテキストは移行されません。

Directory Serverの管理モデルには、構成ディレクトリ・サーバーは存在しません。つまり、デプロイメントにIdentity Synchronization for Windowsが含まれている場合の除き、o=netscapeRootサフィックスはもはや不適切です。デフォルトでdsmigは、特に要求しないかぎり、o=netscapeRootデータベースは移行しません。o=netscapeRootデータベースを移行するには、migrate-dataサブコマンドとともに-Nオプションを使用します。

詳細は、dsmigに関する説明を参照してください。

注意:

Directory Serverでは、データの移行時に、ネストされたグループの定義が30レベルを超えるか確認します。深いネストは、ネストされたグループに親でもあるグループが含まれる、循環グループ定義を意味する場合があります。ネスト・レベルが30を超えるグループがある場合、Directory Serverではそれ以降のレベルのisMemberOf属性の計算を停止します。

Directory Serverではこれが発生するたびにエラーをログに記述します。これらのエラーは無視しても問題がありませんが、循環定義の可能性があるために、エラーに記載されているグループの定義は検証する必要があります。

6.6.1 移行後の新しいインスタンスのトラブルシューティング

dsmig migrate-dataの実行後、新しいインスタンスのエラー・ログに多数のエラー・メッセージが含まれる場合、次の手順を実行します。

1. 実行中のDirectory Serverのインスタンスをすべて停止します。

2. dsee.ldifファイルから、nsslapd-infolog-areaおよびnsslapd-infolog-levelを完全に削除します。

3. Directory Serverインスタンスを起動します。

ldapmodifyコマンドを使用してパスワードを変更した際にエラーが発生した場合、移行手順後に次の手順を実行します。

1. 次のコマンドを使用し、pwd-compat-modeを確認します。

dsconf get-server-prop pwd-compat-mode

2. pwd-compat-modeがDS-6 modeに設定されている場合、ldapmodifyコマンドを使用しパスワードを変更する際にはpwdPolicyオブジェクト・クラスを使用する必要があります。

6.7 自動移行後に実行するタスク

サーバーを自動的に移行するために、dsmigを使用した場合、次の2つの移行後タスクのみを完了する必要があります。

- ユーザー・プラグインをカスタマイズした場合、これらを再コンパイルし、新しいサーバーに追加する必要があります。

- 移行したサーバーがレプリケーション・トポロジの一部であった場合は、「レプリケート対象のサーバーの移行に関する問題」を参照してください。

7 手動でのDirectory Serverの移行

「自動または手動移行の判断」に記載している自動での移行の要件をデプロイメントで満たしていない場合は、サーバーは手動で移行する必要があります。この章では、サーバーの各部分を手動で移行する手順について説明します。

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

- 「手動での移行の準備」

- 「手動でのスキーマの移行」

- 「手動での構成データの移行」

- 「手動でのセキュリティ設定の移行」

- 「手動でのユーザー・データの移行」

- 「手動でのユーザー・プラグインの移行」

- 「手動移行後に実行するタスク」

7.1 手動での移行の準備

インスタンスを手動で移行する場合、自動移行ツール(dsmig)で実行されるのと同じ順でサーバーの各部分を移行します。この項では、古いインスタンスは5.2インスタンスのことを指し、新しいインスタンスは11gリリース1 (11.1.1.7.0)のインスタンスを指します。

手動で移行を開始する前に、次のタスクが完了していることを確認します。

- Directory Server 11gリリース1 (11.1.1.7.0)ソフトウェアがインストールされています。
Directory Server 11gリリース1 (11.1.1.7.0)ソフトウェアは、Directory Server 5.2インスタンスがある同じマシンにインストールすることも、別のマシンにインストールすることも可能です。

- 新しいインスタンスが作成済です。
新しいインスタンスは、古いインスタンスがあった場所を除く任意の場所に作成できます。新しいインスタンスは同じLDAP/LDAPSポートにも別のポートにもインストールすることが可能です。別のポートを使用した場合、新しいインスタンスに対するすべてのレプリケーション承諾は、それに従って変更する必要があります。

新しいインスタンスを作成する際、ディレクトリ・マネージャのDNとパスワードは、cn=config下のnsslapd-rootdnおよびnssalpd-rootpw属性に保存されます。これらの属性には新しいインスタンスの値がすでにあるので、移行時には古いインスタンスの値は伝播されません。nsslapd-secureportおよびnsslapd-port属性に対しても同じ動作が取られます。

- 古いインスタンスが正しく停止されています。
古いインスタンスが正しい順番でシャットダウンされていない場合、移行で問題が発生する場合があります。古いインスタンスと新しいインスタンスが別のマシンにある場合でも、移行の開始前に古いインスタンスを停止している必要があります。

7.2 手動でのスキーマの移行

Directory Server 5.2のスキーマ・ファイルは、serverRoot/slapd-serverID/config/schemaにあります。Directory Server 11gリリース1 (11.1.1.7.0)のスキーマ・ファイルは、instance-path/config/schemaにあります。

Directory Server 11gリリース1 (11.1.1.7.0)には、新しいパスワード・ポリシー属性を含む00ds6pwp.ldifという新しいスキーマ・ファイルがあります。これに加え、特定の構成属性が追加された00core.ldifがあります。これらのファイルとは別に、Directory Server 11gリリース1 (11.1.1.7.0)とともに提供される標準のスキーマ・ファイルは、バージョン5で用意されているものと同一です。

スキーマを移行するには、次の手順を実行します。

1. 99user.ldifファイルを既存のインスタンスから新しいインスタンスにコピーします。新しいインスタンスにカスタム・スキーマをすでに追加している場合、どのバージョンのカスタム・スキーマを保持するか選択する必要があります。

2. 他の任意のファイルにカスタム・スキーマを定義している場合は、新しいインスタンスにそれらのファイルをコピーします。

3. 新しいインスタンスにすべての部分レプリケーションの情報を再定義します。

7.3 手動での構成データの移行

Directory Server 5.2の構成は、ファイルserverRoot/slapd-serverID/config/dsee.ldifに指定されています。Directory Server 11gリリース1 (11.1.1.7.0)の構成は、instance-path/config/dsee.ldifファイルに指定されています。

次の項では、具体的に、古いインスタンスから新しいインスタンスに移行する必要のある構成属性を示します。

7.3.1 特定の構成属性の移行

次の属性タイプの値を移行する必要があります。

7.3.1.1 グローバル構成属性

グローバル・スコープACIの実装では、rootDSEに固有のすべてのACIでbase (targetscope="base")の値を持つtargetscopeフィールドが必要です。rootDSEで保持されているACIは、各Directory Serverインスタンスに固有で、レプリケートされません。したがって、以前のバージョンを含むトポロジでDirectory Server 11gリリース1 (11.1.1.7.0)サーバーを実行する際には、互換性の問題は発生しないはずです。ACIのスコープに対する変更の詳細は、「ACIに対する変更」を参照してください。

ACIを変更するのみではなく、cn=configの下の次の属性も移行する必要があります。

nsslapd-accesscontrol
nsslapd-accesslog-level
nsslapd-accesslog-logbuffering
nsslapd-accesslog-logexpirationtime
nsslapd-accesslog-logexpirationtimeunit
nsslapd-accesslog-logging-enabled
nsslapd-accesslog-logmaxdiskspace
nsslapd-accesslog-logminfreediskspace
nsslapd-accesslog-logrotationtime
nsslapd-accesslog-logrotattiontimeunit
nsslapd-accesslog-maxlogsize
nsslapd-accesslog-maxlogsperdir
nsslapd-attribute-name-exceptions
nsslapd-auditlog-logexpirationtime
nsslapd-auditlog-logexpirationtimeunit
nsslapd-auditlog-logging-enabled
nsslapd-auditlog-logmaxdiskspace
nsslapd-auditlog-logminfreediskspace
nsslapd-auditlog-logrotationtime
nsslapd-auditlog-logrotattiontimeunit
nsslapd-auditlog-maxlogsize
nsslapd-auditlog-maxlogsperdir
nsslapd-certmap-basedn
nsslapd-ds4-compatible-schema
nsslapd-enquote-sup-oc
nsslapd-errorlog-level
nsslapd-errorlog-logexpirationtime
nsslapd-errorlog-logexpirationtimeunit
nsslapd-errorlog-logging-enabled
nsslapd-errorlog-logmaxdiskspace
nsslapd-errorlog-logminfreediskspace
nsslapd-errorlog-logrotationtime
nsslapd-errorlog-logrotattiontimeunit
nsslapd-errorlog-maxlogsize
nsslapd-errorlog-maxlogsperdir
nsslapd-groupevalnestlevel
nsslapd-idletimeout
nsslapd-infolog-area
nsslapd-infolog-level
nsslapd-ioblocktimeout
nsslapd-lastmod
nsslapd-listenhost
nsslapd-maxbersize
nsslapd-maxconnections
nsslapd-maxdescriptors
nsslapd-maxpsearch
nsslapd-maxthreadsperconn
nsslapd-nagle
nsslapd-readonly
nsslapd-referral
nsslapd-referralmode
nsslapd-reservedescriptors
nsslapd-return-exact-case
nsslapd-rootpwstoragescheme
nsslapd-schema-repl-useronly
nsslapd-schemacheck
nsslapd-search-tune
nsslapd-securelistenhost
nsslapd-security
nsslapd-sizelimit
nsslapd-threadnumber
nsslapd-timelimit
ds-start-tls-enabled

7.3.1.2 セキュリティ構成属性

"cn=encryption,cn=config"の下のすべての属性を移行する必要があります。

証明書認証またはセキュア・ポートを使用している場合、"cn=encryption,cn=config"の下のキー・ファイルのパスおよび証明書データベース・ファイルのパスを更新する必要があります。次の属性の値を移行する必要があります。

nsKeyfile
nsCertfile

7.3.1.3 機能構成属性

"cn=features,cn=config"の下のaci属性の値を移行する必要があります。

また、アイデンティティ・マッピング属性のすべての値も移行する必要があります。

7.3.1.4 ツリー構成属性のマッピング

"cn=mapping tree,cn=config"の下のすべてのエントリを移行する必要があります。

Netscape Rootデータベースは以前から非推奨になっており、Directory Server 11gリリース1 (11.1.1.7.0)にはありません。古いインスタンスで特定の用途のためにNetscape Rootデータベースが使用されていた場合、o=netscaperootの下の属性を移行する必要があります。これ以外の場合は無視してかまいません。

7.3.1.5 レプリケーション構成属性

レプリケーション構成属性を移行する前に、レプリケート対象の保留中の変更がないことを確認します。これを行うには、insyncコマンドを使用します。

構成属性に加え、cn=replication,cn=configの下のすべての属性を移行する必要があります。すべてのレプリケーション承諾のホストおよびポート、および変更ログ・データベース(nsslapd-changelogdir)に対する変更を手動で新しいインスタンスで更新する必要があります。

次の項では、移行する必要のあるレプリケーション構成属性を示します。

7.3.1.5.1 変更ログ属性

表7-1 変更ログ属性名の変更

古い属性名

Directory Serverの属性名

nsslapd-changelogmaxage

dschangelogmaxage

nsslapd-changelogmaxentries

dschangelogmaxentries

また、これらの属性は、(サフィックス名ごとに)cn=changelog5,cn=configからcn=replica,cn=suffixname,cn=mapping tree,cn=configのエントリに移動する必要があります。

7.3.1.5.2 部分レプリケーション構成属性

トポロジで部分レプリケーションを使用している場合、次の属性名を変更する必要があります。

表7-2 部分レプリケーション属性名の変更

古い属性名

Directory Server 11gリリース1 (11.1.1.7.0)の属性名

dsFilterSPType == fractional_include

dsReplFractionalInclude

dsFilterSPType == fractional_exclude

dsReplFractionalExclude

7.3.1.5.3 レプリカ構成属性

次のレプリカ構成属性の値を移行する必要があります。

ds5ReferralDelayAfterInit
nsDS5Flags
nsDS5ReplicaBindDN
nsDS5ReplicaId
nsDS5ReplicaLegacyConsumer
nsDS5ReplicaName
nsDS5ReplicaPurgeDelay
nsDS5ReplicaReferral
nsDS5ReplicaRoot
nsDS5ReplicaTombstonePurgeInterval
aci

dschangelogmaxageおよびdschangelogmaaxentriesの属性は、レプリカのエントリに追加されました。

7.3.1.5.4 レプリケーション承諾構成

次の属性値は、レプリケーション承諾ごとに移行する必要があります。

description
ds5agreementEnable
ds5ReplicaTransportCompressionLevel
ds5ReplicaTransportGroupSize
ds5ReplicaTransportWindowSize
nsDS5ReplicaBindDN
nsDS5ReplicaBindMethod
nsDS5ReplicaCredentials
nsDS5ReplicaHost
nsDS5ReplicaPort
nsDS5ReplicaRoot
nsDS5ReplicaTimeout
nsDS5ReplicaTransportInfo
nsDS5ReplicaUpdateSchedule
aci

nsDS5ReplicaCredentials属性の移行時には問題が発生する場合があります。詳細は、「レプリケーション証明の手動でのリセット」を参照してください。

Directory Server 11gリリース1 (11.1.1.7.0)にはds5PartialReplConfiguration属性はありません。この属性は削除する必要があります。

部分レプリケーションを使用している場合、レプリケーション承諾ごとにdsReplFractionalIncludeおよびdsReplFractionalExclude属性が追加されます。

"cn=replication,cn=config"の下のすべての属性が移行されます。

7.3.1.6 パスワード・ポリシー構成属性

Directory Server 11gリリース1 (11.1.1.7.0)のパスワード・ポリシーの詳細な構成は、『Oracle Directory Server Enterprise Edition管理者ガイド』の第7章のDirectory Serverのパスワード・ポリシーに関する説明を参照してください。パスワード・ポリシーを定義する属性は、エントリcn=Password Policy,cn=configに保存されています。Directory Server 5.2では、パスワード・ポリシー属性は、cn=configの下にあります。

pwdPolicyオブジェクト・クラスの属性は、古いパスワード・ポリシー属性の代替です。これらの属性の説明は、pwdPolicy(5dsoc)のマニュアル・ページを参照してください。

デフォルトでこれらのパスワード・ポリシーは、古いパスワード・ポリシーと下位互換性があります。だだし、下位互換性は無期限には保証されていないので、デプロイメントで都合がよくなったらただちに新しいパスワード・ポリシーに移行する必要があります。パスワード・ポリシーの互換性およびサフィックスの再記述の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』を参照してください。

Directory Server 11gリリース1 (11.1.1.7.0)では、新しいパスワード・ポリシー、古いパスワード・ポリシーおよびエントリ操作属性が共存している場合、移行中およびその後の処理後にそれを自動で管理しますが、古いパスワード・ポリシー属性を参照するすべてのアプリケーションは移行する必要があります。次に、古いパスワード・ポリシー構成属性と新しいパスワード・ポリシー構成属性のマッピングを示します。

表7-3 5.2と11gリリース1 (11.1.1.7.0)のパスワード・ポリシー属性間のマッピング

古いDirectory Server属性

Directory Server 11gリリース1 (11.1.1.7.0)の属性

passwordMinAge

pwdMinAge

passwordMaxAge

pwdMaxAge

passwordExp

pwdMaxAge

passwordInHistory

pwdInHistory

passwordSyntax

pwdCheckQuality

passwordMinLength

pwdMinLength

passwordWarning

pwdExpireWarning

-

pwdGraceLoginLimit

passwordMustChange

pwdMustChange

passwordChange

pwdAllowUserChange

-

pwdSafeModify

passwordStorageScheme

passwordStorageScheme

passwordExpireWithoutWarning

-

passwordLockout

pwdLockout

passwordLockoutDuration

pwdLockoutDuration

passwordUnlock

pwdLockoutDuration

passwordMaxFailure

pwdMaxFailure

passwordResetFailureCount

pwdFailureCountInterval

7.3.1.7 SNMP属性

Directory Server 11gリリース1 (11.1.1.7.0)にはcn=SNMP,cn=configのエントリは存在しません。したがって、このエントリ下にあるすべての属性は非推奨になっています。Directory Server 11gリリース1 (11.1.1.7.0)でSNMPを設定する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のDirectory ServerでのSNMPの設定に関する説明を参照してください。

7.3.1.8 UniqueIDジェネレータ構成属性

cn=uniqueid generator,cn=configの下のnsState属性を移行する必要があります。

7.3.1.9 データベース構成属性

データベースの一般的な構成属性は、cn=config,cn=ldbm database,cn=plugins,cn=configの下に保存されています。次の属性を移行する必要があります。

nsslapd-lookthroughlimit
nsslapd-allidsthreshold
nsslapd-cache-autosize
nsslapd-cache-autosize-split
nsslapd-cachesize
nsslapd-db-checkpoint-interval
nsslapd-db-circular-logging
nsslapd-db-durable-transactions
nsslapd-db-idl-divisor
nsslapd-db-locks
nsslapd-db-logbuf-size
nsslapd-db-logfile-size
nsslapd-db-page-size
nsslapd-db-transaction-batch-val
nsslapd-db-tx-max
nsslapd-dbncache
nsslapd-import-cachesize
nsslapd-exclude-from-export
nsslapd-disk-low-threshold
nsslapd-disk-full-threshold

データベースに固有の属性は、cn=database instance name,cn=ldbm database,cn=plugins,cn=configの形式でエントリに保存されています。次の属性を移行する必要があります。

nsslapd-suffix
nsslapd-cachesize
nsslapd-cachememsize
nsslapd-readonly
nsslapd-require-index

デプロイメントでNetscapeRootのサフィックスを使用する場合、cn=netscapeRoot,cn=ldbm database,cn=plugins,cn=configの下に属性を移行する必要があります。データベースの場所(nsslapd-directory)も新しいDirectory Serverインスタンスの場所に置き換える必要があります。

システム・インデックスを除く、デフォルトのすべてのインデックス構成属性を移行する必要があります。デフォルトのインデックス構成属性は、エントリcn=default indexes,cn=ldbm database,cn=plugins,cn=configに保存されています。NetscapeRootデータベースのインデックスは移行する必要がありません。

システム・インデックスを除く、すべてのインデックス構成属性を移行する必要があります。インデックス構成属性は、ソートcn=index name, cn=index, cn=database instance name, cn=ldbm database, cn=plugins, cn=configのエントリに保存されています。

すべての属性暗号化構成を移行する必要があります。

7.3.1.10 プラグイン構成属性

任意の標準のプラグインの構成を変更している場合、構成を更新する必要があります。また、すべてのカスタム・プラグインの構成を更新する必要があります。最低でも、カスタム・プラグインをすべて再コンパイルして、構成をディレクトリに追加する必要があります。プラグインAPIに対する変更の詳細は、『Oracle Directory Server Enterprise Edition開発者ガイド』の第2章のDirectory Server 5.2以降のプラグインAPIに対する変更に関する説明を参照してください。

次の項では、標準のプラグインを変更している場合、構成を移行する必要があるものについて説明します。

7.3.1.10.1 7ビット検索プラグイン

このプラグインの構成は、cn=7-bit check,cn=plugins,cn=configの下に保存されています。次の属性を移行する必要があります。

nsslapd-pluginarg*
nsslapd-pluginenabled

7.3.1.10.2 サービス・プラグインのクラス

この構成のプラグインは、cn=Class of Service,cn=plugins,cn=configの下に保存されています。次の属性を移行する必要があります。

nsslapd-pluginarg0
nsslapd-pluginenabled

7.3.1.10.3 DSML Frontendプラグイン

このプラグインの構成は、cn=DSMLv2-SOAP-HTTP,cn=frontends,cn=plugins,cn=configの下に保存されています。次の属性を移行する必要があります。

ds-hdsml-port
ds-hdsml-iobuffersize
ds-hdsml-requestmaxsize
ds-hdsml-responsemsgsize
ds-hdsml-poolsize
ds-hdsml-poolmaxsize
ds-hdsml-clientauthmethod
ds-hdsml-rooturl
ds-hdsml-soapschemalocation
ds-hdsml-dsmlschemalocation
nsslapd-pluginenabled

7.3.1.10.4 パススルー認証プラグイン

このプラグインの構成は、cn=Pass Through Authentication,cn=plugins,cn=configの下に保存されています。次の属性を移行する必要があります。

nsslapd-pluginenabled

nsslapd-pluginarg*属性は、o=netscapeRootの構成を移行する必要のある場合のみ移行する必要があります。

7.3.1.10.5 パスワード同期プラグイン

このプラグインの構成は、cn=pswsync,cn=plugins,cn=configの下に保存されています。次の属性を移行する必要があります。

nsslapd-pluginenabled

7.3.1.10.6 参照整合性プラグイン

このプラグインの構成は、cn=Referential Integrity Postoperation,cn=plugins,cn=configの下に保存されています。次の属性を移行する必要があります。

nsslapd-pluginarg*
nsslapd-pluginenabled

7.3.1.10.7 レトロ変更ログ・プラグイン

このプラグインの構成は、cn=Retro Changelog PlugIn,cn=plugins,cn=configの下に保存されています。次の属性を移行する必要があります。

nsslapd-changelogmaxage
nsslapd-changelogmaxentries
nsslapd-pluginarg*
nsslapd-pluginenabled

7.3.1.10.8 UID一意性プラグイン

このプラグインの構成は、cn=UID Uniqueness,cn=plugins,cn=configの下に保存されています。次の属性を移行する必要があります。

nsslapd-pluginarg*
nsslapd-pluginenabled

7.4 手動でのセキュリティ設定の移行

インスタンスを手動で移行する場合、セキュリティおよび構成は、dsmigを使用した場合の順序とは別の順序で移行します。この項の説明に従って、Directory Server 11gリリース1 (11.1.1.7.0)のデフォルトの証明書とキー・データベースを古いデータベースのものに置き換えてセキュリティ設定を移行する場合、まず構成を移行する必要があります。

セキュリティ設定を手動で移行するには、次の手順を実行します。

1. 新しいインスタンスをすでに開始している場合は、そのインスタンスを停止します。

2. 新しいインスタンスの証明書データベースおよびキー・データベース・ファイルをバックアップします。

3. 証明書データベースおよびキー・データベース・ファイルを既存のインスタンスから新しいインスタンスにコピーします。

$ cp serverRoot/alias/slapd-serverID-cert8.db instance-path/alias/slapd-cert8db
$ cp serverRoot/alias/slapd-serverID-key3.db instance-path/alias/slapd-key3.db

4. パスワード・ファイルを既存のインスタンスから新しいインスタンスにコピーします。

$ cp serverRoot/alias/slapd-serverID-pin.txt instance-path/alias/slapd-pin.txt

5. 証明書データベースのパスワードを更新します。

$ dsadm set-flags instance-path cert-pwd-prompt=on

6. 証明書マッピング・ファイルを既存のインスタンスから新しいインスタンスにコピーします。

$ cp serverRoot/shared/config/certmap.conf instance-path/alias/certmap.conf

7. 既存のインスタンスが外部のセキュリティ・トークンを使用する場合、セキュリティ・モジュール・データベースおよび外部トークン・ライブラリを新しいインスタンスにコピーします。

$ cp serverRoot/alias/secmod.db instance-path/alias/secmod.db

8. 新しいインスタンスを起動します。

セキュリティ構成属性は、残りの構成属性を移行するときに移行されます。この意味で、セキュリティ設定の移行は、構成を移行するまで完了しません。構成の移行の詳細は、次の項で説明します。

7.5 手動でのユーザー・データの移行

トポロジでデータの自動移行がサポートされていない場合、データは手動で移行する必要があります。これを行うには、データを既存のインスタンスからエクスポートし、新しいインスタンスに再インポートします。

データを手動で移行するには、次の手順を実行します。

1. 新しいインスタンスにすでにデータがある場合、新しいインスタンス内の競合するすべてのサフィックスをバックアップします。

2. レプリケーション・トポロジのマスター・サーバー・インスタンスを移行する場合、マスターの直接のコンシューマであるすべてのサーバーとマスターが同期されていることを確認します。
変更ログは手動では移行できません。11gリリース1 (11.1.1.7.0)インスタンスには新しい変更ログが作成されます。

3. db2ldifコマンドを使用し、必要なサフィックスをLDIFにエクスポートします。このコマンドを使用すると、サーバーが実行されているか停止されているかにかかわらず、LDIFファイルにサフィックス・コンテンツがすべてエクスポートされます。
次に、単一のLDIFファイルの2つのサフィックスをエクスポートする例を示します。

$ serverRoot/slapd-serverID/db2ldif -a example.ldif \
-r -s "ou=people,dc=example,dc=com" -s "ou=departments,dc=example,dc=com"

この例では、-aは結果のLDIFファイルを指定し、-rはレプリケーション情報がエクスポートされる必要があることを示し、-sは、エクスポートに含めるサフィックスを指定します。

4. 新しいインスタンスに対してdsadm importコマンドを使用し、LDIFファイルをインポートします。たとえば、次のコマンドでは、エクスポートした2つのサフィックスに以前作成したLDIFファイルがインポートされます。

$ dsadm import instance-path example.ldif ou=people,dc=example,dc=com
$ dsadm import instance-path example.ldif ou=departments,dc=example,dc=com

5. レトロ変更ログが古いインスタンスに構成されている場合、db2ldifコマンドを使用し、レトロ変更ログにエクスポートします。

$ serverRoot/slapd-serverID/db2ldif -a changelog.ldif \
-s "cn=changelog"

この例で、-aは結果のLDIFファイルを指定し、-sはchangelogのサフィックスを指定します。

6. 新しいインスタンスで、dsadm importコマンドを使用し、レトロ変更ログをインポートします。たとえば、次のコマンドでは、以前作成した変更ログLDIFファイルがインポートされます。

$ dsadm import instance-path changelog.ldif cn=changelog

7. 新しいインスタンスを起動します。

注意:

Directory Serverでは、データの移行時に、ネストされたグループの定義が30レベルを超えるか確認します。深いネストは、ネストされたグループに親でもあるグループが含まれる、循環グループ定義を意味する場合があります。ネスト・レベルが30を超えるグループがある場合、Directory Serverではそれ以降のレベルのisMemberOf属性の計算を停止します。

Directory Serverではこれが発生するたびにエラーをログに記述します。これらのエラーは無視しても問題がありませんが、循環定義の可能性があるために、エラーに記載されているグループの定義は検証する必要があります。

7.6 手動でのユーザー・プラグインの移行

ユーザー・プラグインは移行できません。カスタム・ユーザー・プラグインがある場合、再コンパイルし、手動でDirectory Server 11gリリース1 (11.1.1.7.0)インスタンスに追加します。プラグインAPIに対する変更の詳細は、『Oracle Directory Server Enterprise Edition開発者ガイド』の第2章のDirectory Server 5.2以降のプラグインAPIに対する変更に関する説明を参照してください。

7.7 手動移行後に実行するタスク

サーバーの手動での移行後、新しいサーバーを実行する前に、次の移行後タスクを実行する必要があります。

- ユーザー・プラグインをカスタマイズした場合、これらを再コンパイルし、新しいサーバーに追加する必要があります。

- 移行したサーバーがレプリケーション・トポロジの一部であった場合は、第8章「レプリケーション・トポロジの移行」を参照してください。

- バックアップ、リカバリおよびインストール・スクリプトをカスタマイズしている場合、新しいバージョンに準拠するようこれらのスクリプトを再記述する必要があります。

8 レプリケーション・トポロジの移行

Directory Server Enterprise Edition 11gリリース1 (11.1.1.7.0)では、レプリケーション・トポロジ全体を自動的に移行できません。レプリケーション・トポロジを移行する場合、各サーバーを個々に移行する必要があります。ただし、通常はサービスをまったく中断せずにトポロジ全体を移行できます。

この章では、レプリケート対象のサーバーの移行における問題を次の内容で説明します。

- 「レプリケート対象のサーバーの移行の概要」

- 「レプリケート対象のサーバーの移行に関連する問題」

- 「レプリケート時の推奨事項」

- 「移行シナリオ」

8.1 レプリケート対象のサーバーの移行の概要

Directory Server 11g 11gリリース1 (11.1.1.7.0)のマルチマスター・トポロジでは、マスターが数に制限なくサポートされます。このため、また他の変更などのために、移行を新しいサーバーを含む同一のトポロジに行うのではなく、トポロジを再設計した方がよい場合があります。続行する前に、『Oracle Directory Server Enterprise Editionデプロイメント・プランニング・ガイド』の第III部の論理的な設計に関する説明を参照してください。

レプリケートされた古いサーバー・インスタンスを移行する場合、通常はまずコンシューマから開始し、続いてハブを行い、マスターで終了します。このボトムアップのアプローチでは、1度に1つのサーバーのみが中断され、レプリケーション・トポロジのサーバーのブランチ全体を中断する必要がありません。このアプローチは、マスターおよびコンシューマ間で発生する可能性があるカスタム・スキーマの同期に関係する問題を回避するためにも役立ちます。

注意:

バージョン5.2では、マスター数は最大4つまでに制限されているため、5.2サーバーを含むマルチマスター・レプリケーション構成では(任意のバージョンの)マスターは最大4つまでサポートされます。したがって、トポロジに5.2サーバーが含まれている場合、マスターはトポロジに4つまでしか含めることができません。

8.2 レプリケート対象のサーバーの移行に関連する問題

レプリケーション・トポロジおよび移行戦略によっては、レプリケート対象のサーバーを移行する際に特定の問題が発生する可能性があります。これらの問題は、次の項で説明します。

8.2.1 パスワード・ポリシーの問題

マルチマスターのレプリケーション・トポロジの移行で、11gリリース1 (11.1.1.7.0)のマスターが古いサーバーにレプリケートする場合が発生します。このような状況で11gリリース1 (11.1.1.7.0)サーバーのパスワード・ポリシー属性を変更し、古いサーバーにレプリケートを行うとオブジェクト・クラス違反が発生します。パスワード・ポリシー属性は、内部でサーバーによって管理されますが、バインド、ユーザーのパスワード変更または、userpassword属性を使用したエントリが追加されると、それらが更新されることがあります。

オブジェクト・クラス違反を回避するには、11gリリース1 (11.1.1.7.0)のマスターからレプリケートされるバージョン5.2のすべてのサーバーに、11gリリース1 (11.1.1.7.0)のパスワード・ポリシー・スキーマ・ファイル(00ds6pwp.ldif)を必ずコピーする必要があります。パスワード・ポリシー・スキーマ・ファイルがコピーされたら、バージョン5.2サーバーを再起動します。

8.2.2 レプリケーション承諾の移行

可能であれば、レプリケート対象のサーバーは同じホスト名およびポート番号に移行する必要があります。レプリケート対象のサーバーのホスト名またはポート番号を変更する必要がある場合、そのサーバーをポイントするすべてのレプリケーション承諾は新しいサーバーをポイントするよう手動で更新する必要があります。たとえば、コンシューマ・サーバーをred.example.com:1389からblue.example.com:1389に移行した場合、red.example.com:1389をポイントするすべてのマスター上のレプリケーション承諾はblue.example.com:1389をポイントするよう手動で更新する必要があります。

トポロジ内の移行したマスターからコンシューマへのレプリケーション承諾は、dsmig移行ツールで管理されます。トポロジで自動移行がサポートされない場合、これらのレプリケーション承諾も手動で更新する必要があります。

8.2.3 リフェラルの移行

マスター・レプリカを新しいホストまたはポートに移行した場合、リフェラルも影響を受けます。トポロジ内の各マスターの詳細は、トポロジ内の他のすべてのサーバーのReplica Update Vector (RUV)にあります。各サーバーのRUVは、リフェラルを決定するために使用されます。移行中にマスター・サーバーのホスト名またはポート番号を変更した場合、トポロジ内の他のサーバーからのそのマスターに対するリフェラルはすべて無効になります。これを修正する最も簡単な方法は、移行時に次の手順を順番を守って実行することです。

1. マスター・サーバーを移行する前に、レプリケート対象の保留中の変更がないことを確認します。これを行うには、insyncツールを使用します。

2. 『Oracle Directory Server Enterprise Edition管理者ガイド』のレプリカの昇格または降格に関する説明に従って、マスター・サーバーをハブに降格させます。

3. dsmigを使用するか、手動でハブ・サーバーを移行します。

4. 『Oracle Directory Server Enterprise Edition管理者ガイド』のレプリカの昇格または降格に関する説明に従って、ハブ・サーバーをマスターに昇格させます。ハブを昇格させた場合、移行した新しいマスターにreplicaIDを割り当てる必要があります。この新しいreplicaIDは、移行されている古いサーバーのreplicaIDとは別で、レプリケートされるトポロジ内で一意である必要があります。

8.2.4 レプリケーション証明の手動でのリセット

dsmigでは、デフォルトのレプリケーション・マネージャの(cn=replication manager,cn=replication,cn=config)のパスワード・エントリは移行しません。かわりに、レプリケーション・マネージャのパスワードを削除します。したがって、移行を手動または自動で行うかにかかわらず、レプリケーション・マネージャのパスワードを手動でリセットする必要があります。

レプリケーション・マネージャのパスワードをリセットするには、次のコマンドを使用します。

$ dsconf set-server-prop -h host -p port def-repl-manager-pwd-file:filename
$ dsconf set-repl-agmt-prop -p port_master1 replicated_suffix \
master2:port_master2 auth-pwd-file:filename

注意:

dsmig migrate-configコマンドは、レプリケーション証明を正しくリセットするために実行する必要のあるコマンドを返します。

また、dsmigではデフォルトではないレプリケーション・マネージャのエントリも移行しません。古いバージョンのレプリカでデフォルトのレプリケーション・マネージャ以外のエントリを使用しており、このエントリがcn=configの下にある場合、デフォルトのレプリケーション・マネージャを手動で追加する必要があります。デフォルトではないレプリケーション・マネージャのエントリを手動で追加する方法の詳細は、マニュアルを参照してください。デフォルトではないレプリケーション・マネージャを追加する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のデフォルトではないレプリケーション・マネージャの使用に関する説明を参照してください。

8.2.5 ツームストンのパージに関連する問題

レプリケーション・トポロジの移行後、ツームストンのパージで問題が発生する場合があります。場合により、ツームストンのエントリがパージされるべきときにされません。この問題は、対応するサフィックスのobjectclass属性の索引を再構築して解決できます。

8.3 レプリケート時の推奨事項

Directory Server 11gリリース1 (11.1.1.7.0)のマルチマスター・トポロジでは、マスター数に対する制限がありません。多くの場合、ハブまたはコンシューマが存在しないフルメッシュのマルチマスター・トポロジが推奨されます。

すべてがマスターのトポロジの利点は次のとおりです。

- 可用性。サーバーの1つがダウンしても書込みトラフィックは中断されません。

- 簡潔性。すべてがマスターのトポロジで、読み書きを別のサーバーにルートするリフェラルの設定が不要です。

デプロイメントによっては、すべてがマスターのトポロジが使用できない場合があります。たとえば、部分レプリケーションはマスターからコンシューマのみでサポートされているため、すべてがマスターのトポロジでは部分レプリケーションは使用できません。

8.4 移行シナリオ

この項では、様々なレプリケーション・トポロジの移行シナリオの例を示します。

8.4.1 同一トポロジへのレプリケーション・トポロジの移行

レプリケート対象のサーバーの移行を開始する前に、トポロジのアーキテクチャを変更した場合、デプロイメントでサービスがうまく提供されないことがあるか判断します。この項では、既存のトポロジを保持する場合の移行方法について説明します。レプリケーション・トポロジを同一のトポロジに移行するには、コンシューマを移行し、次いでハブ、次いでマスターを移行します。次の項では、単純なマルチマスター・トポロジを移行する例を示します。

8.4.1.1 コンシューマの移行

レプリケーション・トポロジ内の各コンシューマに対し、次を実行します。

1. トポロジ内の別のコンシューマにクライアントをルートしなおします。

2. 移行するコンシューマに対するレプリケーション承諾をすべて無効にします。

3. コンシューマを停止します。

4. 第5章「Directory Serverの移行プロセスの概要」の説明に従って、コンシューマを移行します。

5. コンシューマを起動します。

6. ハブからそのコンシューマに対するレプリケーション承諾を有効にします。

7. データを移行した場合、そのレプリケーションの同期が保たれていることを確認します。

8. データを移行していない場合は、コンシューマを再度初期化します。

9. クライアントをコンシューマにルート変更しなおします。

次の一連の図では、前述のコンシューマの移行を示します。最初の図は、移行前のバージョン5.2のトポロジを示します。

図8-1 レガシー・トポロジ

「図8-1 レガシー・トポロジ」の説明

最初の手順では、クライアントをルート変更し、レプリケーション承諾を無効化し、実質的にトポロジからのコンシューマを分離します。

図8-2 トポロジからのコンシューマの分離

「図8-2 トポロジからのコンシューマの分離」の説明

次の手順ではコンシューマを移行します。

図8-3 コンシューマの移行

「図8-3 コンシューマの移行」の説明

次の手順では、新しいコンシューマに対してレプリケーション承諾を有効にし、必要に応じてコンシューマを初期化し、クライアント・アプリケーションを新しいコンシューマにルート変更します。

図8-4 11gリリース1 (11.1.1.7.0)のコンシューマのトポロジへの配置

「図8-4 11gリリース1 (11.1.1.7.0)のコンシューマのトポロジへの配置」の説明

8.4.1.2 ハブの移行

レプリケーション・トポロジの各ハブに対し、次を実行します。

1. 移行するマスターからハブへのレプリケーション承諾を無効にします。

2. コンシューマに移行するハブからのレプリケーション承諾を無効にします。

3. ハブを停止します。

4. 第5章「Directory Serverの移行プロセスの概要」の説明に従って、ハブを移行します。

5. ハブを起動します。

6. マスターからそのハブに対するレプリケーション承諾を有効にします。

7. ハブからそのコンシューマに対するレプリケーション承諾を有効にします。

8. データを移行した場合、そのレプリケーションの同期が保たれていることを確認します。

9. データを移行していない場合は、ハブを再度初期化します。

次の一連の図では、前述のとおりハブを移行します。最初の図は、ハブの移行前のトポロジを示します。

図8-5 移行したコンシューマを含むトポロジ

「図8-5 移行したコンシューマを含むトポロジ」の説明

最初の移行手順では、レプリケーション承諾を無効にし、実質的にトポロジからハブを分離します。

図8-6 トポロジからのハブの分離

「図8-6 トポロジからのハブの分離」の説明

次の手順ではレガシー・ハブを移行します。

図8-7 ハブの移行

「図8-7 ハブの移行」の説明

次の手順では、新しいハブでレプリケーション承諾を有効にし、必要に応じてコンシューマを初期化します。

図8-8 11gリリース1 (11.1.1.7.0)のハブのトポロジへの配置

「図8-8 11gリリース1 (11.1.1.7.0)のハブのトポロジへの配置」の説明

別のハブを移行する前に、コンシューマのレプリケーションが残りのトポロジと同期が保たれていることを確認します。移行したばかりのサーバーには変更ログがなく、したがって同期が保たれていないコンシューマ・サーバーは更新できません。次のサプライヤ・サーバーを移行する前に、トポロジを安定させ、すべてのサーバーの同期が取られるようにします。

8.4.1.3 マスターの移行

レプリケーション・トポロジの各マスターに対し、次を実行します。

1. 移行するマスターに書込みを行うクライアント・アプリケーションがある場合、トポロジ内の別のマスターに書き込むよう、これらのアプリケーションをルート変更します。

2. そのマスターが書込みリクエストを受信しなくなったことを確認します。これには、マスターで読取り専用モードを有効にします。

3. マスターとそのコンシューマ間のレプリケーションの同期が取られていることを確認します。
手動で移行を行う場合、変更ログの移行はサポートされていないので、この場合は前の2つの手順は必須です。自動での移行では、変更ログは移行されますが、変更を失うリスクを回避するために上記の手順は行ってください。

4. 移行するマスターに対するレプリケーション承諾をすべて無効にします。

5. マスターを停止します。

6. 第5章「Directory Serverの移行プロセスの概要」の説明に従ってマスターを移行します。

7. マスターを起動します。

8. トポロジ内のマスターからハブおよび他のマスターへのレプリケーション承諾を有効にします。

9. データを移行した場合、そのレプリケーションの同期が保たれていることを確認します。

10. データを移行していない場合、トポロジ内の別のマスターからマスターを初期化します。

11. クライアント・アプリケーションをルート変更した場合(手順2)、ここで移行したマスターに書き込むようアプリケーションをルーティングします。

次の一連の図では、前述のマスターの移行を行います。最初の図は、マスターの移行前のトポロジを示します。

図8-9 移行したコンシューマとハブを含むトポロジ

「図8-9 移行したコンシューマとハブを含むトポロジ」

マスターを移行する場合、まずレプリケーション承諾を無効にし、実質的にマスターをトポロジから分離します。

図8-10 マスターのトポロジからの分離

「図8-10 マスターのトポロジからの分離」の説明

次の手順ではマスターを移行します。

図8-11 マスターの移行

「図8-11 マスターの移行」の説明

次の手順では、新しいマスターからまたは新しいマスターに対するレプリケーション承諾を有効にし、必要に応じてマスターを初期化します。

図8-12 11gリリース1 (11.1.1.7.0)のマスターのトポロジへの配置

「図8-12 11gリリース1 (11.1.1.7.0)のマスターのトポロジへの配置」の説明

別のマスターを移行する前に、すべてのハブおよびコンシューマのレプリケーションの同期が残りのトポロジと保たれていることを確認します。移行したばかりのサーバーには変更ログがなく、したがって同期が保たれていないサーバーは更新できません。次のサプライヤ・サーバーを移行する前に、トポロジを安定させ、すべてのサーバーの同期が取られるようにします。

8.4.2 新しいトポロジへのレプリケーション・トポロジの移行

レプリケート対象のサーバーの移行を開始する前に、トポロジのアーキテクチャを変更した場合、デプロイメントでサービスがうまく提供されないことがあるか判断します。この項では、基本のレガシー・トポロジをすべてがマスターのトポロジに移行する方法について説明します。すべてがマスターのトポロジに移行するには、コンシューマ、ハブおよびマスターを移行し、次いでハブをマスターに、その後コンシューマをハブからマスターに昇格させます。次の項では、単純なマルチマスター・トポロジをすべてがマスターの新しいトポロジに移行する例を示します。

次の図は、レガシー・トポロジを示します。

図8-13 レガシー・トポロジ

「図8-13 レガシー・トポロジ」の説明

8.4.2.1 すべてのサーバーの移行

まず、「同一トポロジへのレプリケーション・トポロジの移行」の説明に従って、すべてのサーバーを個々に移行します。結果のトポロジは次の図のとおりです。

図8-14 移行したサーバーを含むトポロジ

「図8-14 移行したサーバーを含むトポロジ」の説明

8.4.2.2 ハブの昇格

次の手順では、ハブをマスターに昇格させ、マスター間でフルメッシュ型トポロジを作成します。ハブを昇格させるには、『Oracle Directory Server Enterprise Edition管理者ガイド』のレプリカの昇格または降格に関する説明に従います。

次の図は、ハブを昇格後のトポロジを示します。

図8-15 昇格したハブ・レプリカを含む移行したトポロジ

「図8-15 昇格したハブ・レプリカを含む移行したトポロジ」の説明

8.4.2.3 コンシューマの昇格

次の手順では、コンシューマをハブ、次いでマスターに昇格させ、マスター間でフルメッシュ型トポロジを作成します。コンシューマを昇格させるには、『Oracle Directory Server Enterprise Edition管理者ガイド』のレプリカの昇格または降格に関する説明を参照してください。

次の図は、コンシューマを昇格後のトポロジを示します。

図8-16 新しいフルメッシュ型のすべてがマスターのトポロジ

「図8-16 新しいフルメッシュ型のすべてがマスターのトポロジ」の説明

8.4.3 複数のデータ・センターを介した移行

複数のデータ・センターを介してサーバーを移行する場合、各データ・センターの各サーバーを個々に移行する必要があります。レプリケート対象のサーバーの移行を開始する前に、トポロジのアーキテクチャを変更した場合、デプロイメントでサービスがうまく提供されないことがあるか判断します。既存のトポロジを維持する場合、各データ・センターで「同一トポロジへのレプリケーション・トポロジの移行」の例に従います。新しいトポロジを移行する場合、各データ・センターで「新しいトポロジへのレプリケーション・トポロジの移行」の例に従います。

9 Directory Serverに対するバージョン5.2以降のアーキテクチャ変更

この章では、5.2以降の移行に影響するDirectory Serverに対するアーキテクチャ変更について説明します。Directory Serverに対するすべての変更およびバグ修正の詳細は、『Oracle Directory Server Enterprise Editionリリース・ノート』の第1章のOracle Directory Server Enterprise Edition 11gリリース1 (11.1.1.7.0)の新機能に関する説明を参照してください。

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

- 「管理フレームワークに対する変更」

- 「ACIに対する変更」

- 「コマンドラインに対する変更」

- 「コンソールに対する変更」

- 「パスワード・ポリシー」

- 「プラグインに対する変更」

- 「インストール済の製品レイアウトに対する変更」

9.1 管理フレームワークに対する変更

Directory Server 11gリリース1 (11.1.1.7.0)には、バージョン5.2とは異なり管理サーバーがありません。サーバーは、Directory Service Control Center (DSCC)に登録するようになり、WebベースのGUIまたはコマンドライン・ツールを使用してリモートから管理するようになりました。

新しい管理フレームワークに移行するには、次を実行する必要があります。

- 各サーバーを個々に移行する

- DSCCに各サーバーを登録する

9.1.1 ServerRootディレクトリの削除

新しい管理モデルでは、Directory ServerインスタンスはServerRootとは関連付けなくなりました。各Directory Serverインスタンスは、通常のスタンドアロン・ディレクトリと同様な方法で操作できるスタンドアロン・ディレクトリです。

9.1.2 o=netscapeRootサフィックスの削除

Directory Serverの以前のバージョンでは、管理情報は一元的にo=netscapeRootに保持されていました。新しい管理モデルでは、構成ディレクトリ・サーバーという概念はなくなりました。o=netscapeRootサフィックスが必要でなくなったため、netscapeRootデータベース・ファイルは移行されなくなりました。このサフィックスの構成データは、特に必要な場合は移行することが可能です。

9.2 ACIに対する変更

Directory Server 11gリリース1 (11.1.1.7.0)のACIでは、次が変更されています。

9.2.1 ACIスコープに対する変更

Directory Server 5.2のルートDSEのACIには、ベース・スコープがありました。Directory Server 11gリリース1 (11.1.1.7.0)のルートDSEのACIには、デフォルトでtargetscope="subtree"と同等なグローバル・スコープがあります。

Directory Server 5.2と同じ動作を再現するには、ルートDSEのACIにtargetscope="base"を追加します。これは、構成の移行にdsmigを使用した場合は自動的に実行されます。

9.2.2 サフィックス・レベルのACIに対する変更

Directory Server 5.2には、サフィックス・レベルで次のACIがあります。

aci: (targetattr != "nsroledn || aci || nsLookThroughLimit ||
nsSizeLimit || nsTimeLimit || nsIdleTimeout || passwordPolicySubentry ||
passwordExpirationTime || passwordExpWarned || passwordRetryCount ||
retryCountResetTime || acc ountUnlockTime || passwordHistory ||
passwordAllowChangeTime")(version 3.0; acl "Allow self entry modification
except for nsroledn, aci, resource limit attributes, passwordPolicySubentry
and password policy state attributes"; allow (write)userdn ="ldap:///self";)

このACIでは、ユーザー・パスワードの自己変更などが許可されていました。このACIは、Directory Server 11gリリース1 (11.1.1.7.0)には含まれなくなりました。かわりに、デフォルトで次のグローバルACIが用意されています。

aci: (targetattr != "aci") (targetscope = "base") (version 3.0;
aci "Enable read access to rootdse for anonymous users";
allow(read,search,compare) user dn="ldap:///anyone"; )

aci: (targetattr = "*") (version 3.0; acl "Enable full access
for Administrators group";  allow (all)(groupdn =
"ldap:///cn=Administrators,cn=config"); )

aci: (targetattr = "userPassword") ( version 3.0; acl "allow
userpassword self modification"; allow (write) userdn = "ldap:///self";)

Directory Server 11gリリース1 (11.1.1.7.0)では、ルートDSEレベルでのデフォルトのuserPassword ACIが、サフィックス・レベルでのデフォルトのレガシーACIと同等なアクセス制御を行います。ただし、レガシー・バージョンと完全に同じアクセス制御を再現したい場合は、サフィックスに次のACIを追加する必要があります。このACIは、レガシーACIにDirectory Server 11gリリース1 (11.1.1.7.0)の新しいパスワード・ポリシー操作属性を持たせたものです。

aci: (targetattr != "nsroledn || aci || nsLookThroughLimit ||
nsSizeLimit || nsTimeLimit || nsIdleTimeout || passwordPolicySubentry ||
passwordExpirationTime || passwordExpWarned || passwordRetryCount ||
retryCountResetTime || accountUnlockTime || passwordHistory ||
passwordAllowChangeTime || pwdAccountLockedTime || pwdChangedTime ||
pwdFailureTime || pwdGraceUseTime || pwdHistory ||
pwdLastAuthTime || pwdPolicySubentry || pwdReset")(version 3.0;
acl "Allow self entry modification except for nsroledn,
aci, resource limit attributes, passwordPolicySubentry
and password policy state attributes"; allow (write)userdn ="ldap:///self";)

ヒント:

ユーザーにすべての書込み権限を付与後、特定の属性の書込み権限を制限しないでください。かわりに、書込み権限を許可する属性を明示的に列挙します。

9.3 コマンドラインに対する変更

コマンドライン・ツールの大部分の機能は、dsadmとdsconfの2つのコマンドのみに置き換えられました。

次の表に、Directory Server 5.2で使用されていたコマンドと、それに対応するDirectory Server 6および11gリリース1 (11.1.1.7.0)のコマンドを示します。バージョン11gリリース1 (11.1.1.7.0)では、これらのコマンドのデフォルトのパスは/opt/SUNWdsee7/binになります。zipインストールからインストールした場合は、デフォルトのパスはinstall-path/dsee7/binになります。

表9-1 Directory Server 5、6および7のコマンド

バージョン5.2のコマンド

バージョン6のコマンド

バージョン11gリリース1 (11.1.1.7.0)のコマンド

説明

bak2db

dsadm restore

dsadm restore

バックアップからデータベースをリストアします(ローカル、オフライン)

bak2db-task

dsconf restore

dsconf restore

バックアップからデータベースをリストアします(リモート、オンライン)

db2bak

dsadm backup

dsadm backup

データベースのバックアップ・アーカイブを作成します(ローカル、オフライン)

db2bak-task

dsconf backup

dsconf backup

データベースのバックアップ・アーカイブを作成します(リモート、オンライン)

db2index

dsadm reindex

dsadm reindex

インデックスを作成および生成します(ローカル、オフライン)

db2index-task

dsconf reindex

dsconf reindex

インデックスを作成および生成します(リモート、オンライン)

db2ldif

dsadm export

dsadm export

LDIFにデータベース・コンテンツをエクスポートします(ローカル、オフライン)

db2ldif-task

dsconf export

dsconf export

LDIFにデータベース・コンテンツをエクスポートします(リモート、オンライン)

entrycmp

entrycmp

entrycmp

複数のレプリカの同じエントリを比較します

fildif

fildif

fildif

LDIFファイルのフィルタされたバージョンを作成します

getpwenc

削除されています

削除されています

暗号化されたパスワードを出力します

idsktune

idsktune

idsktune

パッチとシステム・チューニングを確認します

insync

insync

insync

複数のレプリカ間の同期について示します

ldif2db

dsadm import

dsadm import

LDIFからデータベース・コンテンツをインポートします(ローカル、オフライン)

ldif2db-task

dsconf import

dsconf import

LDIFからデータベース・コンテンツをインポートします(リモート、オンライン)

ldif2ldap

ldapmodify -B

ldapmodify -B

LDAPを介してLDIFからデータをインポートします(リモート、オンライン)

MigrateInstance5

dsmig / 手動での移行の手順です

dsmig / 手動での移行の手順です

以前のバージョンからデータを移行します

mmldif

mmldif

mmldif

複数のLDIFファイルを結合します

monitor

cn=monitorでのldapsearch

cn=monitorでのldapsearch

パフォーマンスの監視情報を取得します

ns-ldapagt

削除されています

削除されています

Directory ServerのSNMPサブエージェントを起動します

pwdhash

pwdhash

pwdhash

暗号化された形式のパスワードを出力します

repldisc

repldisc

repldisc/dsccmon

レプリケーション・トポロジを検出します

restart-slapd

dsadm restart

dsadm restart

Directory Serverインスタンスを再起動します

restore-config

dsadm start --safe

dsadm start --safe

管理サーバーの構成をリストアします

saveconfig

削除されています

削除されています

管理サーバーの構成を保存します

schema_push

schema_push

dsadm start --schema-pushまたはdsadm restart -schema-push

スキーマ変更のタイム・スタンプを更新します

start-slapd

dsadm start

dsadm start

Directory Serverインスタンスを起動します

stop-slapd

dsadm stop

dsadm stop

Directory Serverインスタンスを停止します

suffix2instance

dsconf get-suffix-prop

dsconf get-suffix-prop

サフィックスのバックエンド名を参照します

vlvindex

dsadm reindex

dsadm reindex

仮想リスト表示インデックスを作成します

表9-2 Directory Server 5、6および7のコマンド

バージョン5.2のコマンド

バージョン6のコマンド

バージョン11gリリース1 (11.1.1.7.0)のコマンド

説明

directoryserver accountstatus

ns-accountstatus

dsutil account-status

アカウントのステータスを確認します

directoryserver activate

ns-activate

dsutil account-activate

エントリまたはグループ・エントリをアクティブ化します

directoryserver configure

インストール手順

インストール手順

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

directoryserver inactivate

ns-inactivate

dsutil account-inactivate

エントリまたはグループ・エントリを非アクティブ化します

directoryserver unconfigure

アンインストール手順

アンインストール手順

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

9.4 コンソールに対する変更

ダウンロードしたJavaのSwingベースのコンソールは、Directory Service Control Center (DSCC)に置き換わりました。DSCCは、Webブラウザを使用するディレクトリ・サービス全体を管理するグラフィカル・インタフェースです。DSCCは移行の必要がありません。移行したDirectory ServerインスタンスはDSCCに登録できます。DSCCの詳細は、『Oracle Directory Server Enterprise Editionリファレンス』の第2章のDirectory Serverの概要に関する説明を参照してください。

9.5 パスワード・ポリシー

Directory Server 11gリリース1 (11.1.1.7.0)には、LDAPディレクトリのパスワード・ポリシーに関するインターネット・ドラフト(http://datatracker.ietf.org/doc/draft-behera-ldap-password-policy/)で説明されている標準のオブジェクト・クラスおよび属性を使用するパスワード・ポリシーが実装されています。

このパスワード・ポリシーには次の機能があります。

- ログインに対する制限の猶予(pwdGraceAuthNLimit属性で指定)。この属性は、期限切れのパスワードを認証に使用できる回数を指定します。これがない場合や0に設定されている場合、認証は失敗します。

- 安全なパスワードの変更(pwdSafeModify属性で指定)。この属性は、パスワードの変更時に既存のパスワードを送信する必要があるか指定します。属性がない場合、既存のパスワードは送信する必要がありません。

また、このパスワード・ポリシーでは次も制御しています。

- LDAP_CONTROL_PWP_[REQUEST|RESPONSE]

- LDAP_CONTROL_ACCOUNT_USABLE_[REQUEST|RESPONSE]

LDAPクライアントは、これらのコントロールによりアカウントのステータス情報を取得できます。

LDAP_CONTROL_PWPコントロールはLDAPのバインド、検索、変更、追加、削除、modDNおよび比較操作のアカウントのステータス情報を提供します。

検索でOID 1.3.6.1.4.1.42.2.27.8.5.1を使用すると、次の情報を得ることができます。

- パスワードが期限切れになるまでの時間

- ログインを試行できる残りの回数

- パスワードが失効しているかどうか

- アカウントがロックされているかどうか

- リセット後にパスワードを変更する必要があるかどうか

- パスワードの変更が許可されているかどうか

- ユーザーが古いパスワードを入力する必要があるかどうか

- パスワードの品質(構文)が不適切かどうか

- パスワードが短いかどうか

- 前回のパスワード変更からの間隔が短いかどうか

- パスワードが履歴にすでにあるかどうか

LDAP_CONTROL_PWPコントロールは、警告およびエラーの状態を示します。制御値は、次の意味がある{tii}の形式のBERオクテット文字列です。

- tは、警告が設定されている場合のタグ定義です。tの値は、次のいずれかになります。

LDAP_PWP_WARNING_RESP_NONE (0x00L)
LDAP_PWP_WARNING_RESP_EXP (0x01L)
LDAP_PWP_WARNING_RESP_GRACE (0x02L)

- 最初のiは警告情報を示します。
警告は、tに設定した次の値に依存します。

- tがLDAP_PWP_WARNING_RESP_NONEに設定されている場合、警告は-1になります。

- tがLDAP_PWP_WARNING_RESP_EXに設定されている場合、警告は期限切れになるまでの秒数になります。

- tがLDAP_PWP_WARNING_RESP_GRACEに設定されている場合、警告はログインを試行できる残りの回数になります。

- 2番目のiは、エラー情報を示します。tがLDAP_PWP_WARNING_RESP_NONEに設定されている場合、エラーには次のいずれかの値が含まれます。

pwp_resp_no_error (-1)
pwp_resp_expired_error (0)
pwp_resp_locked_error (1)
pwp_resp_need_change_error (2)
pwp_resp_mod_not_allowed_error (3)
pwp_resp_give_old_error (4)
pwp_resp_bad_qa_error (5)
pwp_resp_too_short_error (6)
pwp_resp_too_young_error (7)
pwp_resp_in_hist_error (8)

LDAP_CONTROL_ACCOUNT_USABLEコントロールは、LDAPの検索操作のみのアカウントのステータス情報を示します。

パスワード・ポリシーの互換性の問題の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』を参照してください。

9.6 プラグインに対する変更

この項では、バージョン5.2以降にDirectory Serverに追加された新しいプラグインを列挙します。また、この項では、古いプラグインAPIで作成したカスタム・プラグインを使用している場合に実行する必要のある事柄についても説明します。

9.6.1 新しいプラグイン

追加されたプラグインは次のとおりです。

cn=gle,cn=plugins,cn=config
cn=MemberOf Plugin,cn=plugins,cn=config
cn=Monitoring Plugin,cn=plugins,cn=config
cn=ObjectDeletionMatch,cn=plugins,cn=config
cn=pswsync,cn=plugins,cn=config
cn=Replication Repair,cn=plugins,cn=config
cn=RMCE,cn=Password Storage Schemes,cn=plugins,cn=config
cn=Strong Password Check,cn=plugins,cn=config

これらのプラグインの詳細は、plugin(5dsconf)のマニュアル・ページを参照してください。

9.6.2 プラグインAPIに対する変更

独自に開発したカスタム・プラグインがある場合、Directory Server 11gリリース1 (11.1.1.7.0)で動作するように再コンパイルする必要があります。プラグインAPIに行われた変更のすべてのリストについては、『Oracle Directory Server Enterprise Edition開発者ガイド』の第2章のDirectory Server 5.2以降のプラグインAPIに対する変更に関する説明を参照してください。

9.7 インストール済製品レイアウトに対する変更

この項では、Directory Server 5.2以降のインストール済の製品レイアウトに対する変更の概要を示します。Directory Server 5.2以降、次の項で説明するいくつかのファイルおよびユーティリティは非推奨になっています。

9.7.1 以前ServerRoot下にあった管理ユーティリティ

Directory Server 11gリリース1 (11.1.1.7.0)では、サーバー・インスタンスの管理に管理サーバーは使用されなくなりました。

したがって、以前ServerRoot下にあった次のシステム管理ユーティリティは非推奨になっています。

- restart-admin

- start-admin

- startconsole

- stop-admin

- uninstall

9.7.2 以前ServerRoot/bin下にあったバイナリ

ServerRoot/bin下の次のユーティリティは非推奨になっています。

- ServerRoot/bin/admin/admconfig

- ServerRoot/bin/https/bin/ns-httpd

- ServerRoot/bin/https/bin/uxwdog

- ServerRoot/bin/slapd/server/ns-ldapagt

Solaris SPARCでは、ns-slapdデーモンは、install-path/lib/sparcvSolaris-Versionにあります。Solaris SPARC以外のプラットフォームでは、ns-slapdデーモンは、install-path/libにあります。

9.7.3 以前ServerRoot/lib下にあったライブラリおよびプラグイン

Directory Server 5.2では、製品ライブラリおよびプラグインがServerRoot/libにありました。Solaris SPARC上のDirectory Server 11gリリース1 (11.1.1.7.0)では、これらのライブラリおよびプラグインは、install-path/lib/sparcvSolaris-Versionに配置されています。Solaris SPARC以外のプラットフォームでは、これらはinstall-path/lib下にあります。

9.7.4 オンライン・ヘルプ・ファイルの廃止

Directory Server 11gリリース11.1.1.5.0のコンソール・オンライン・ヘルプは/opt/SUNWdsee7/resources/dcc7app/htmlに配置されていました。このリリースの「ヘルプ」ボタンは、Oracle Technology NewtorkにホストされているODSEEオンライン・ドキュメントにリンクしています。

9.7.5 以前ServerRoot/plugins下にあったプラグイン

次の表に、サンプルのサーバー・プラグイン、プラグイン開発用のヘッダー・ファイルの新しい場所を示します。

表9-3 プラグインのサポート

Directory Server 5.2のプラグイン・ディレクトリ

Directory Server 11gリリース1 (11.1.1.7.0)のプラグイン・ディレクトリ

備考

ServerRoot/plugins/slapd/slapi/examples

この製品では提供されなくなりました。すべてのコード・ファイルは、http://www.oracle.com/technology/sample_code/products/oid/index.htmlにあるexample.zipファイルにバンドルされています。

サンプル・プラグイン

ServerRoot/plugins/slapd/slapi/include

install-path/include

プラグイン・ヘッダー・ファイル

Directory ServerではSNMPがサポートされなくなりました。SNMPと関係するすべてのプラグインおよびバイナリは、Directory Serverでは非推奨になっています。

これらは、次などのプラグインです。

- ServerRoot/plugins/snmp/magt/magt

- ServerRoot/plugins/snmp/mibs/

- ServerRoot/plugins/snmp/sagt/sagt

SNMPの監視の有効化の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』を参照してください。

9.7.6 以前ServerRoot/shared/bin下にあったユーティリティ

次の表に、以前ServerRoot/shared/bin下にあった管理ツールの新しい場所を示します。これらの一部のツールは、管理フレームワークに対する変更のため非推奨になっていることに注意してください。

表9-4 以前ServerRoot/shared/bin下にあったツール

5.2のファイル

11gリリース1 (11.1.1.7.0)のファイル

用途

ServerRoot/shared/bin/admin_ip.pl

非推奨

IPアドレスを変更します

ServerRoot/shared/bin/entrycmp

install-path/bin/entrycmp

レプリケーション用にエントリを比較します

ServerRoot/shared/bin/fildif

install-path/bin/fildif

フィルタされたLDIFをダンプします

ServerRoot/shared/bin/insync

install-path/bin/insync

レプリケーションの同期を確認します

ServerRoot/shared/bin/ldapcompare

install_path/dsee7/dsrk/bin/ldapcompare

属性値を比較します

Directory Server 11gリリース1 (11.1.1.7.0)では、このユーティリティを取得するためにSUNWldapcsdk-toolsパッケージをインストールする必要があります

ServerRoot/shared/bin/ldapdelete

install_path/dsee7/dsrk/bin/ldapdelete

ディレクトリのエントリを削除します

Directory Server 11gリリース1 (11.1.1.7.0)では、このユーティリティを取得するために、SUNWldapcsdk-toolsパッケージをインストールする必要があります

ServerRoot/shared/bin/ldapmodify

install_path/dsee7/dsrk/bin/ldapmodify

ディレクトリのエントリを変更します

Directory Server 11gリリース1 (11.1.1.7.0)では、このユーティリティを取得するために、SUNWldapcsdk-toolsパッケージをインストールする必要があります

ServerRoot/shared/bin/ldapsearch

install_path/dsee7/dsrk/bin/ldapsearch

ディレクトリのエントリを検索します

Directory Server 11gリリース1 (11.1.1.7.0)では、このユーティリティを取得するために、SUNWldapcsdk-toolsパッケージをインストールする必要があります

ServerRoot/shared/bin/modutil

非推奨

PKCS #11モジュールを管理します

ServerRoot/shared/bin/uconv

非推奨

ISOからUTF-8に変換します

ServerRoot/shared/bin/repldisc

install_path/dsee7/bin/repldisc

レプリケーション・トポロジを検出します

9.7.7 証明書およびキー・ファイル

次の表に、Directory Server 11gリリース1 (11.1.1.7.0)の証明書およびキー・ファイルの新しい場所を示します。

表9-5 証明書およびキー・ファイルの場所

5.2のファイル

11gリリース1 (11.1.1.7.0)のファイル

備考

ServerRoot/shared/config/certmap.conf

instance-path/alias/certmap.conf

証明書をディレクトリ・エントリにマップする構成ファイルです

ServerRoot/alias/cert8.db

instance-path/alias/slapd-cert8.db

信頼できる証明書データベース・ファイルです

ServerRoot/alias/key3.db

instance-path/alias/slapd-key3.db

クライアント・キーを含むデータベース・ファイルです

ServerRoot/alias/secmod.db

instance-path/alias/secmod.db

PKCS#11などのセキュリティ・モジュールを含むデータベース・ファイルです

9.7.8 サイレント・インストールおよびアンインストールのテンプレート

Directory Server 5.2には、ServerRoot/setup5ディレクトリにサイレント・インストールおよびアンインストール用のサンプル・テンプレートが用意されていました。Directory Server 11gリリース1 (11.1.1.7.0)では、サイレント・インストールおよびアンインストールは不要になったため、これらのファイルは非推奨になっています。

9.7.9 以前ServerRoot/slapd-ServerID下にあったサーバー・インスタンスのスクリプト

以前ServerRoot/slapd-ServerIDにあったコマンドラインの管理スクリプトは、新しい管理フレームワークでは置き換えられ、非推奨になっています。これらのコマンドおよびそれらのDirectory Server 11gリリース1 (11.1.1.7.0)での対応コマンドについては、「コマンドラインに対する変更」で説明しています。

9.7.10 サーバー・インスタンスのサブディレクトリ

次の表に、以前ServerRoot/slapd-instance-nameにあった構成、ログおよびバックアップ・データの新しい場所を示します。

表9-6 インスタンス固有のサブディレクトリ

バージョン5.2のディレクトリ

バージョン11gリリース1 (11.1.1.7.0)のディレクトリ

備考

ServerRoot/slapd-ServerID/bak

instance-path/bak

ディレクトリ・インスタンスのデータベース・バックアップ

ServerRoot/slapd-ServerID/confbak

非推奨

管理サーバーの構成のバックアップ

ServerRoot/slapd-ServerID/conf_bk

非推奨

ディレクトリ・インスタンスの構成のバックアップ

ServerRoot/slapd-ServerID/config

instance-path/config

ディレクトリ・インスタンスの構成

ServerRoot/slapd-ServerID/config/schema

instance-path/config/schema

ディレクトリ・インスタンスのスキーマ

ServerRoot/slapd-ServerID/db

instance-path/db

ディレクトリ・インスタンスのデータベース

ServerRoot/slapd-ServerID/ldif

instance-path/ldif

サンプルのLDIFファイル

ServerRoot/slapd-ServerID/locks

instance-path/locks

ランタイム・プロセスのロック

ServerRoot/slapd-ServerID/logs

instance-path/logs

サーバー・インスタンスのログ・ファイル

ServerRoot/slapd-ServerID/tmp

instance-path/tmp

実行時の一時ファイル

10 Directory Proxy Serverの移行

Directory Proxy Server 5.2からDirectory Proxy Server 11gリリース1 (11.1.1.7.0)に自動で移行するパスはありません。Directory Proxy Server 11gリリース1 (11.1.1.7.0)には古いバージョンよりも多くの機能があります。したがって、ほとんどのインスタンスの構成情報を1対1でマッピングすることはできませんが、互換性のためにバージョン5.2のサーバーをDirectory Proxy Server 11gリリース1 (11.1.1.7.0)のように動作させることは可能です。

この章では、Directory Proxy Server 11gリリース1 (11.1.1.7.0)の構成プロパティを使用してバージョン5.2の構成をシミュレートする方法を説明します。

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

- 「グローバル構成のマッピング」

- 「接続プール構成のマッピング」

- 「グループ構成のマッピング」

- 「プロパティ構成のマッピング」

- 「イベント構成のマッピング」

- 「アクション構成のマッピング」

- 「単純な接続ベースのルータとしてのDirectory Proxy Server 11gリリース1 (11.1.1.7.0)の構成」

10.1 グローバル構成のマッピング

Directory Proxy Server 11gリリース1 (11.1.1.7.0)の構成をバックアップする前に、dpadm backupコマンドを使用し、構成をバックアップしてください。詳細は、dpadmに関する説明を参照してください。

Directory Proxy Server 11gリリース1 (11.1.1.7.0)は、Directory Service Control Center (DSCC)またはdpconfコマンドライン・ユーティリティを使用して構成できます。詳細は、dpconfに関する説明を参照してください。

Directory Proxy Server 11gリリース1 (11.1.1.7.0)の構成は、プロパティのセットとして取得できます。たとえば、ポートの情報はlisten-portプロパティに返されます。この項では、バージョン5.2のグローバル構成属性を、存在する場合、Directory Proxy Server 11gリリース1 (11.1.1.7.0)の対応するプロパティにマッピングする方法を説明します。すべての機能が直接マップできるとはかぎりません。

Directory Proxy Server 5.2のグローバル構成は、次の2つのオブジェクト・クラスで指定します。

- ids-proxy-sch-LDAPProxy。Directory Proxy Serverの名前およびグローバル構成オブジェクトのDNが含まれます。

- ids-proxy-sch-GlobalConfiguration。様々なグローバル構成属性が含まれます。

Directory Proxy Server11gリリース1 (11.1.1.7.0)の構成方法のため、Directory Proxy Server 11gリリース1 (11.1.1.7.0)にはids-proxy-sch-LDAPProxyオブジェクト・クラスまたはその属性と同じものはありません。

Directory Proxy Server 5.2では、これらの構成属性は、ids-proxy-con-Config-Name=user-defined-name,ou=system,ou=dar-config,o=netscaperootの下に保存されます。

ids-proxy-sch-GlobalConfigurationの機能は、Directory Proxy Server 11gリリース1 (11.1.1.7.0)の様々な要素のプロパティとして提供されます。次の表に、ids-proxy-sch-GlobalConfigurationオブジェクト・クラスの属性と、対応するDirectory Proxy Server 11gリリース1 (11.1.1.7.0)のプロパティのマッピングを示します。

Directory Proxy Server5.2の属性

Directory Proxy Server 11gリリース1 (11.1.1.7.0)のプロパティ

ids-proxy-con-Config-Name

該当するものはありません。

Directory Proxy Server 11gリリース1 (11.1.1.7.0)には、2つのリスナー(安全ではないリスナーと安全なリスナー)があります。バージョン5.2のリスニング構成属性は、次の4つのリスナーのプロパティにマップできます。リスナーのプロパティを構成するには、次のとおりdpconfコマンドを使用します。

$ dpconf set-ldap-listener-prop PROPERTY

$ dpconf set-ldaps-listener-prop PROPERTY

詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のクライアントおよびDirectory Proxy Server間のリスナーの構成に関する説明を参照してください。

ids-proxy-con-listen-port

listen-port

ids-proxy-con-listen-host

listen-address

ids-proxy-con-listen-backlog

max-connection-queue-size

ids-proxy-con-ldaps-port

listen-port (ldaps-listenerのプロパティ)

ids-proxy-con-max-conns

この属性は、接続ハンドラ・リソース制限のmax-client-connectionsプロパティにマップできます。このプロパティは、次のとおりdpconfコマンドを使用して構成します。

$ dpconf set-resource-limit-policy-prop POLICY-NAME max-client-connections:VALUE

詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のリソース制限ポリシーの作成および構成に関する説明を参照してください。

ids-proxy-con-userid

この属性は、次のコマンドを使用してインスタンスを作成した際に指定したユーザーおよびグループ名にマップできます。

$ dpadm create [-u NAME -g NAME] INSTANCE-PATH

詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のDirectory Proxy Serverインスタンスの操作に関する説明を参照してください。

ids-proxy-con-working-dir

この属性は、次のコマンドを使用してインスタンスを作成した際に指定したINSTANCE-PATHにマップできます。

$ dpadm create INSTANCE-PATH

詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のDirectory Proxy Serverインスタンスの操作に関する説明を参照してください。

ids-proxy-con-include-logproperty

該当するものはありません。Directory Proxy Server 11gリリース1 (11.1.1.7.0)でロギングを構成する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の第27章のDirectory Proxy Serverのロギングに関する説明を参照してください。

10.1.1 グローバル・セキュリティ構成のマッピング

Directory Proxy Server 5.2では、セキュリティはグローバル構成属性を使用して構成します。Directory Proxy Server 11gリリース1 (11.1.1.7.0)では、セキュリティは、dpadmコマンドを使用してサーバー・インスタンスを作成した際に構成します。詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の第19章のDirectory Proxy Serverの証明書に関する説明を参照してください。

Directory Proxy Server 5.2では、これらの構成属性は、ids-proxy-con-Config-Name=user-defined-name,ou=system,ou=dar-config,o=netscaperootの下に保存されます。

次の表に、バージョン5.2のセキュリティ属性とDirectory Proxy Server 11gリリース1 (11.1.1.7.0)の対応するプロパティのマッピングを示します。

表10-1 セキュリティ構成のマッピング

Directory Proxy Server5.2の属性

Directory Proxy Server 11gリリース1 (11.1.1.7.0)のプロパティ

ids-proxy-con-ssl-key

ssl-key-pin

ids-proxy-con-ssl-cert

ssl-certificate-directory

ssl-server-cert-alias

ids-proxy-con-send-cert-as-client

この属性により、LDAPサーバーがプロキシ・サーバーをSSLクライアントとして認証できるよう、プロキシ・サーバーが証明書をLDAPサーバーに送信できるようになります。

ssl-client-cert-alias

このプロパティにより、プロキシ・サーバーがSSLサーバーまたはSSLクライアントとして動作しているかに応じて、LDAPサーバーに別の証明書を送信できるようになります。

ids-proxy-con-server-ssl-version

ids-proxy-con-client-ssl-version

該当するものはありません。

ids-proxy-con-ssl-cert-required

この機能は、次のサーバー・プロパティを設定することによって実現できます。

$ dpconf set-server-prop linebreakallow-cert-based-auth:require

ids-proxy-con-ssl-cafile

該当するものはありません。

10.1.1.1 証明書の管理

Directory Proxy Server 5.2の証明書は、certreqユーティリティまたはコンソールを使用して管理されていました。Directory Proxy Server 11g 11gリリース1 (11.1.1.7.0)では、証明書はdpadmコマンドを使用するか、DSCCを使用して管理されます。

証明書は、Directory Proxy Server 11gリリース1 (11.1.1.7.0)の個々のデータ・ソースにそれぞれインストールする必要があります。

Directory Proxy Server 11gリリース1 (11.1.1.7.0)で証明書を管理する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の第19章のDirectory Proxy Serverの証明書に関する説明を参照してください。

10.1.1.2 プロキシ構成のアクセス制御

Directory Proxy Server 5.2では、プロキシ構成のアクセス制御は構成ディレクトリ・サーバーのACIによって管理されます。Directory Proxy Server 11gリリース1 (11.1.1.7.0)では、構成ファイルへのアクセスは、プロキシ・インスタンスを作成したユーザー、またはプロキシがDirectory Proxy Serverを介してアクセスされる場合は、プロキシ・マネージャに制限されています。構成ファイルの直接の編集はサポートされていません。

10.2 接続プール構成のマッピング

Directory Proxy Server 5.2を構成すると、バックエンドのLDAPサーバーへの接続を再利用できます。これにより、バックエンド・サーバーがWAN (ワイド・エリア・ネットワーク)上にある場合、パフォーマンスを大幅に向上させることができます。Directory Proxy Server 11gリリース1 (11.1.1.7.0)では、この機能はバックエンド・サーバー自体に構成される接続プールにあります。詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の第18章のLDAPデータ・ビューに関する説明を参照してください。

Directory Proxy Server 5.2では、これらの構成属性は、ids-proxy-con-Config-Name=user-defined-name,ou=system,ou=dar-config,o=netscaperootの下に保存されます。

次の表に、Directory Proxy Server 5.2の接続構成属性とDirectory Proxy Server 11gリリース1 (11.1.1.7.0)の対応するプロパティのマッピングを示します。

表10-2 接続プール属性のマッピング

Directory Proxy Server5.2の属性

Directory Proxy Server 11gリリース1 (11.1.1.7.0)のプロパティ

ids-proxy-con-connection-pool

該当するものはありません。

ids-proxy-con-connection-pool-interval

接続プールは、構成済の最大数に自動的に拡張されます。最大数は、LDAPデータ・ソースの次のプロパティを設定して構成します。

num-bind-init

num-bin-incr

num-bind-limit

num-read-init

num-read-incr

num-read-limit

num-write-init

num-write-incr

num-write-limit

LDAPデータ・ソース・プロパティの設定の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のLDAPデータ・ソースの構成に関する説明を参照してください。

ids-proxy-con-connection-pool-timeout

backendMaxReadWaitTimeInMilliSec

10.3 グループ構成のマッピング

Directory Proxy Server 5.2では、クライアント接続の識別とクライアント接続に対する制限にグループを使用します。Directory Proxy Server 11gリリース1 (11.1.1.7.0)では、この機能は接続ハンドラ、データ・ビューおよびリスナーを使用して実現されています。

接続ハンドラ、データ・ビューおよびリスナーは、Directory Service Control Centerを使用するか、dpconfコマンドを使用して構成できます。詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の第25章のクライアントとDirectory Proxy Serverの接続に関する説明および『Oracle Directory Server Enterprise Edition管理者ガイド』の第21章のDirectory Proxy Serverの配布に関する説明を参照してください。

10.3.1 グループ・オブジェクトのマッピング

Directory Proxy Server 5.2では、グループはids-proxy-sch-Groupオブジェクト・クラスの属性を設定して定義していました。このオブジェクト・クラスの特定の属性は、Directory Proxy Server 11gリリース1 (11.1.1.7.0)の接続ハンドラのプロパティにマップできます。接続ハンドラのすべてのプロパティは、次のコマンドを実行して表示できます。

$ dpconf help-properties | grep connection-handler

Directory Proxy Server 5.2では、これらの構成属性は、ou=groups,cn=user-defined-name,ou=dar-config,o=NetscapeRootの下に保存されています。

次の表に、バージョン5.2のグループ属性と対応する接続ハンドラ・プロパティのマッピングを示します。

表10-3 グループ属性と接続ハンドラのプロパティ間のマッピング

Directory Proxy Server 5.2のグループ属性

Directory Proxy Server 11gリリース1 (11.1.1.7.0)の接続ハンドラ・プロパティ

ids-proxy-con-Name

cn

ids-proxy-con-Priority

priority

ids-proxy-sch-Enable

is-enabled

ids-proxy-sch-belongs-to

該当するものはありません。

ids-proxy-con-permit-auth-none:TRUE

ids-proxy-con-permit-auth-sasl:TRUE

ids-proxy-con-permit-auth-simple:TRUE

allowed-auth-methods:anonymouslinebreak allowed-auth-methods:sasl allowed-auth-methods:simple

10.3.2 ネットワーク・グループ・オブジェクトのマッピング

Directory Proxy Server 5.2のグループは、ids-proxy-sch-NetworkGroupオブジェクト・クラスの属性を設定して構成します。これらの属性は、Directory Proxy Server11gリリース1 (11.1.1.7.0)の接続ハンドラ、データ・ソースおよびリスナーのプロパティにマップできます。これらのオブジェクトと関連するすべてのプロパティ一覧を表示するには、dpconf help-propertiesコマンドを実行してそのオブジェクトを検索します。たとえば、接続ハンドラのすべてのプロパティを探すには、次のコマンドを実行します。

$ dpconf help-properties | grep connection-handler

Directory Proxy Server 5.2では、これらの構成属性は、ou=groups,cn=user-defined-name,ou=dar-config,o=NetscapeRootの下に保存されています。

次の表に、Directory Proxy Server 5.2のネットワーク・グループ属性と、対応するDirectory Proxy Server 11gリリース1 (11.1.1.7.0)のプロパティとのマッピング、およびコマンドラインを使用したこれらのプロパティの設定方法を説明します。

表10-4 ネットワーク・グループ属性のマッピング

Directory Proxy Server 5.2のネットワーク・グループ属性

Directory Proxy Server 11gリリース1 (11.1.1.7.0)

ids-proxy-con-Client

接続ハンドラのdomain-name-filtersおよびip-address-filtersプロパティ

ids-proxy-con-include-property

該当するものはありません。

ids-proxy-con-include-rule

該当するものはありません。

ids-proxy-con-ssl-policy:ssl_required

次のコマンドを使用し、これを接続ハンドラのプロパティとして設定します。

$ dpconf set-connection-handler-prop CONNECTION-HANDLER-NAME is-ssl-mandatory:true

ids-proxy-con-ssl-policy:ssl_optional

次のコマンドを使用し、これをLDAPデータ・ソースのプロパティとして設定します。

$ dpconf set-ldap-data-source-prop ds1 ssl-policy:client

ids-proxy-con-ssl-policy:ssl_unavailable

次のコマンドを使用し、これを接続ハンドラのプロパティとして設定します。

$ dpconf set-connection-handler-prop CONNECTION-HANDLER-NAME is-ssl-mandatory:false

ids-proxy-con-tcp-no-delay

次のコマンドを使用し、これを特定のリスナー・ポートのプロパティとして設定します。

$ dpconf set-ldap-listener-prop use-tcp-no-delay:true

ids-proxy-con-allow-multi-ldapv2-bind

該当するものはありません。

ids-proxy-con-reverse-dns-lookup

該当するものはありません。

ids-proxy-con-timeout

この機能は存在しますが、Directory Proxy Server 5での場合と比較すると精度が落ちます。次のコマンドを使用し、この制限を特定のリスナー・ポートのプロパティとして設定します。

$ dpconf set-ldap-listener-prop connection-idle-timeout:value

10.3.3 バインド転送のマッピング

Directory Proxy Server 5.2のバインド転送は、バインド・リクエストをLDAPサーバーに渡すか、バインド・リクエストを拒否してクライアントとの接続を閉じるか決定するために使用します。Directory Proxy Server 11gリリース1 (11.1.1.7.0)では、バインド・リクエストはすべて転送するか、まったく転送しないかのいずれかです。ただし、allowed-auth-methods接続ハンドラ・プロパティを設定すると、バインドに成功したものは認証基準に応じて接続ハンドラに分類できます。Directory Proxy Server 11gリリース1 (11.1.1.7.0)は、構成すると、特定の接続ハンドラからのリクエストをすべて拒否するDirectory Proxy Server 5.2のバインド転送と同じ機能を提供できます。

Directory Proxy Server 5.2では、これらの構成属性は、ou=groups,cn=user-defined-name,ou=dar-config,o=NetscapeRootの下に保存されています。

次の表に、Directory Proxy Server 5.2のバインド転送の属性と、対応するDirectory Proxy Server 11gリリース1 (11.1.1.7.0)の接続ハンドラのプロパティ設定のマッピングを示します。

表10-5 バインド転送属性と接続ハンドラのプロパティ設定のマッピング

Directory Proxy Server5.2の属性

Directory Proxy Server 11gリリース1 (11.1.1.7.0)のプロパティ

ids-proxy-con-bind-name

該当するものはありません。

ids-proxy-con-permit-auth-none

allowed-auth-methods:anonymous

ids-proxy-con-permit-auth-simple

allowed-auth-methods:simple

ids-proxy-con-permit-auth-sasl

allowed-auth-methods:sasl

10.3.4 操作転送のマッピング

操作転送は、バインドの成功後、Directory Proxy Server 5.2がどのようにリクエストを処理するかを決定します。Directory Proxy Server 11gリリース1 (11.1.1.7.0)では、この機能はリクエスト・フィルタリング・ポリシーのプロパティを設定して提供しています。リクエスト・フィルタリング・ポリシーの構成の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のリクエスト・フィルタリング・ポリシーおよび検索データ非表示ルールの作成および構成に関する説明を参照してください。リクエスト・フィルタリング・ポリシーのプロパティの全一覧は、次のコマンドを実行して表示できます。

$ dpconf help-properties | grep request-filtering-policy

Directory Proxy Server 5.2では、これらの構成属性は、ou=groups,cn=user-defined-name,ou=dar-config,o=NetscapeRootの下に保存されています。

次の表に、Directory Proxy Server 5.2の操作転送の属性と、対応するDirectory Proxy Server 11gリリース1 (11.1.1.7.0)のリクエスト・フィルタリング・ポリシーのマッピングを示します。

表10-6 操作転送属性とリクエスト・フィルタリング・プロパティのマッピング

Directory Proxy Server5.2の属性

Directory Proxy Server 11gリリース1 (11.1.1.7.0)のプロパティ

ids-proxy-con-permit-op-search

allow-search-operations

ids-proxy-con-permit-op-compare

allow-compare-operations

ids-proxy-con-permit-op-add

allow-add-operations

ids-proxy-con-permit-op-delete

allow-delete-operations

ids-proxy-con-permit-op-modify

allow-modify-operations

ids-proxy-con-permit-op-modrdn

allow-rename-operations

ids-proxy-con-permit-op-extended

allow-extended-operations

10.3.5 サブツリー非表示のマッピング

Directory Proxy Server 5.2では、ids-proxy-con-forbidden-subtree属性を使用し、任意のクライアント・リクエストでエントリのサブツリーが除外されるよう指定します。Directory Proxy Server 11gリリース1 (11.1.1.7.0)では、この機能をリクエスト・フィルタリング・ポリシーのallowed-subtreesおよびprohibited-subtreesプロパティを使用して提供しています。この方法でサブツリーを非表示にする方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のリソース制限ポリシーの作成と設定に関する説明を参照してください。

サブツリーが様々なバックエンド・サーバーに分散されている場合、データ・ビューのexcluded-subtreesプロパティを使用してサブツリーを非表示にできます。この方法でサブツリーを非表示にする方法の詳細は、Oracle Directory Server Enterprise Editionリファレンスのデータ・ビューからのサブツリーの除外に関する説明および『Oracle Directory Server Enterprise Edition管理者ガイド』の階層および配布アルゴリズムを持つデータ・ビューの構成に関する説明を参照してください。

10.3.6 検索リクエスト制御のマッピング

Directory Proxy Server 5.2では、特定の種類のリクエストがLDAPサーバーに到達しないよう、検索リクエスト制御が使用されていました。Directory Proxy Server 11gリリース1 (11.1.1.7.0)では、この機能はリクエスト・フィルタリング・ポリシーのプロパティおよびリソース制限ポリシーを設定して提供しています。

リクエスト・フィルタリング・ポリシーの構成の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のリクエスト・フィルタリング・ポリシーおよび検索データ非表示ルールの作成に関する説明を参照してください。リソース制限ポリシーの構成の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のリソース制限ポリシーの作成と設定に関する説明を参照してください。リクエスト・フィルタリング・ポリシーまたはリソース制限ポリシーに関連付られているすべてのプロパティ一覧を表示するには、dpadm help-propertiesコマンドを実行してそのオブジェクトを検索します。たとえば、リソース制限ポリシーと関連付られているプロパティをすべて探すには、次のコマンドを実行します。

$ dpconf help-properties | grep resource-limits-policy

Directory Proxy Server 5.2では、これらの構成属性は、ou=groups,cn=user-defined-name,ou=dar-config,o=NetscapeRootの下に保存されています。

次の表に、Directory Proxy Server 5.2の検索リクエスト制御属性と、対応するDirectory Proxy Server 11gリリース1 (11.1.1.7.0)のプロパティのマッピングを示します。

表10-7 検索リクエスト制御属性のマッピング

Directory Proxy Server5.2の属性

Directory Proxy Server 11gリリース1 (11.1.1.7.0)のプロパティ

ids-proxy-con-filter-inequality

allow-inequality-search-operations property of the request filtering policy

ids-proxy-con-min-substring-size

minimum-search-filter-substring-length property of the resource limits policy

10.3.7 比較リクエスト制御のマッピング

Directory Proxy Server 5.2では、特定の種類の検索および比較操作がLDAPサーバーに到達しないよう比較リクエスト制御が使用されていました。Directory Proxy Server 11gリリース1 (11.1.1.7.0)では、この機能はリクエスト・フィルタリング・ポリシーのプロパティを設定して提供しています。

リクエスト・フィルタリング・ポリシーの構成の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のリクエスト・フィルタリング・ポリシーおよび検索データ非表示ルールの作成に関する説明を参照してください。

Directory Proxy Server 5.2では、これらの構成属性は、ou=groups,cn=user-defined-name,ou=dar-config,o=NetscapeRootの下に保存されています。

次の表に、Directory Proxy Server 5.2の比較リクエスト制御属性と、対応するDirectory Proxy Server 11gリリース1 (11.1.1.7.0)のプロパティのマッピングを示します。

表10-8 比較リクエスト制御属性のマッピング

Directory Proxy Server5.2の属性

Directory Proxy Server 11gリリース1 (11.1.1.7.0)のプロパティ

ids-proxy-con-forbidden-compare

prohibited-comparable-attrs

ids-proxy-con-permitted-compare

allowed-comparable-attrs

10.3.8 属性変更検索リクエストのマッピング

Directory Proxy Server 5.2では、これらの属性はサーバーに転送される前に検索リクエストを変更するために使用されていました。Directory Proxy Server 11gリリース1 (11.1.1.7.0)では、この機能はリクエスト・フィルタリング・ポリシーのプロパティおよびリソース制限ポリシーを設定して提供しています。

リクエスト・フィルタリング・ポリシーの構成の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のリクエスト・フィルタリング・ポリシーおよび検索データ非表示ルールの作成に関する説明を参照してください。リソース制限ポリシーの構成の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のリソース制限ポリシーの作成と設定に関する説明を参照してください。

Directory Proxy Server 5.2では、これらの構成属性は、ou=groups,cn=user-defined-name,ou=dar-config,o=NetscapeRootの下に保存されています。

次の表に、Directory Proxy Server 5.2の検索リクエスト変更属性と、対応するDirectory Proxy Server 11gリリース1 (11.1.1.7.0)のプロパティのマッピングを示します。

表10-9 検索リクエスト変更属性のマッピング

Directory Proxy Server5.2の属性

Directory Proxy Server 11gリリース1 (11.1.1.7.0)のプロパティ

ids-proxy-con-minimum-base

allowed-subtrees property of the request filtering policy

ids-proxy-con-max-scope

allowed-search-scopes property of the request filtering policy

ids-proxy-con-max-timelimit

search-time-limit property of the resource limits policy

10.3.9 属性制限検索応答のマッピング

Directory Proxy Server 5.2では、これらはクライアントへの送信前にサーバーから返される検索結果に適用される制限の属性を示していました。Directory Proxy Server 11gリリース1 (11.1.1.7.0)では、この機能はリソース制限ポリシーのプロパティを設定し、検索データの非表示ルールを構成して提供しています。

リソース制限ポリシーの構成の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のリソース制限ポリシーの作成と設定に関する説明を参照してください。検索データ非表示ルールの作成の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の検索データの非表示ルールの作成に関する説明を参照してください。検索データ非表示ルールと関連するプロパティ一覧については、次のコマンドを実行します。

$ dpconf help-properties | grep search-data-hiding-rule

Directory Proxy Server 5.2では、これらの構成属性は、ou=groups,cn=user-defined-name,ou=dar-config,o=NetscapeRootの下に保存されています。

次の表に、Directory Proxy Server 5.2の検索応答制限属性と、対応するDirectory Proxy Server 11gリリース1 (11.1.1.7.0)のプロパティのマッピングを示します。

表10-10 検索応答制御属性のマッピング

Directory Proxy Server 5.2の属性

Directory Proxy Server 11gリリース1 (11.1.1.7.0)のプロパティ

ids-proxy-con-max-result-size

リソース制限ポリシーのsearch-size-limitプロパティ

ids-proxy-con-forbidden-return

属性のサブセットを非表示にする場合:

rule-action:hide-attributes

attributes:attribute-name

エントリ全体を非表示にする場合:

rule-action:hide-entry

ids-proxy-con-permitted-return

rule-action:show-attributes

attributes:attribute-name

ids-proxy-con-search-reference

直接該当するものはありません。検索継続参照はリソース制限ポリシーのreferral-policyプロパティによって制御されています。

10.3.10 参照構成属性のマッピング

Directory Proxy Server 5.2では、これらの属性は参照でDirectory Proxy Serverが何を実行すべきか決定します。Directory Proxy Server 11gリリース1 (11.1.1.7.0)では、この機能はリソース制限ポリシーのプロパティを設定して提供しています。

リソース制限ポリシーの構成の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のリソース制限ポリシーの作成と設定に関する説明を参照してください。

Directory Proxy Server 5.2では、これらの構成属性は、ou=groups,cn=user-defined-name,ou=dar-config,o=NetscapeRootの下に保存されています。

次の表に、Directory Proxy Server 5.2の参照構成属性と、対応するDirectory Proxy Server 11gリリース1 (11.1.1.7.0)のリソース制限プロパティのマッピングを示します。

表10-11 参照構成属性とリソース制限プロパティのマッピング

Directory Proxy Server5.2の属性

Directory Proxy Server 11gリリース1 (11.1.1.7.0)のプロパティ

ids-proxy-con-reference

referral-policy

ids-proxy-con-referral-ssl-policy

referral-policy

ids-proxy-con-referral-bind-policy

referral-bind-policy

ids-proxy-con-max-refcount

referral-hop-limit

10.3.11 サーバー・ロード構成のマッピング

Directory Proxy Server 5.2では、これらの属性は同時操作数および1つの接続でクライアントがリクエストできる操作の総数を制御するために使用されていました。Directory Proxy Server 11gリリース1 (11.1.1.7.0)では、この機能はリソース制限ポリシーのプロパティを設定して提供しています。

リソース制限ポリシーの構成の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のリソース制限ポリシーの作成と設定に関する説明を参照してください。

Directory Proxy Server 5.2では、これらの構成属性は、ou=groups,cn=user-defined-name,ou=dar-config,o=NetscapeRootの下に保存されています。

次の表に、Directory Proxy Server 5.2のサーバー・ロード構成属性と、対応するDirectory Proxy Server 11gリリース1 (11.1.1.7.0)のリソース制限プロパティとのマッピングを示します。

表10-12 サーバー・ロード構成属性とリソース制限プロパティのマッピング

Directory Proxy Server5.2の属性

Directory Proxy Server 11gリリース1 (11.1.1.7.0)のプロパティ

ids-proxy-con-max-simultaneous-operations-per-connection

max-simultaneous-operations-per-connection

ids-proxy-con-operations-per-connection

max-total-operations-per-connection

ids-proxy-con-max-conns

max-connections

ids-proxy-con-max-simultaneous-conns-from-ip

max-client-connections

10.4 プロパティ構成のマッピング

Directory Proxy Server 5.2のプロパティ・オブジェクトでは、LDAPクライアントが従う特殊な制限を指定できます。プロパティ・オブジェクトのほとんどの機能は、新しいアーキテクチャの様々な要素で提供されており、Directory Proxy Server 11gリリース1 (11.1.1.7.0)にあります。次の項では、Directory Proxy Server 5.2プロパティ・オブジェクトを11gリリース1 (11.1.1.7.0)の対応する機能とマッピングする方法を説明します。

10.4.1 属性の名前変更プロパティ

Directory Proxy Server 5.2では、属性名の変更はids-proxy-sch-RenameAttributeオブジェクト・クラスによって定義されます。このオブジェクトでは、ids-proxy-con-server-attr-nameおよびids-proxy-con-client-attr-name属性を使用してどの属性をDirectory Proxy Serverが名前変更するか指定します。

この属性の名前変更機能は、LDAPデータ・ソースのattr-name-mappingsプロパティに置き換わっています。このプロパティは複数の値で構成され、client-attribute-name#server-attribute-nameの形式の値を取ります。クライアント・リクエストでは、Directory Proxy Serverによってclient-attribute-nameがserver-attribute-nameに名前変更されます。応答では、Directory Proxy Serverはserver-attribute-nameからclient-attribute-nameに名前変更されます。

このプロパティを構成するには、次のコマンドを使用します。

$ dpconf set-ldap-data-source-prop data-source-name \
attr-name-mappings:client-attribute-name#server-attribute-name

10.4.2 入力禁止プロパティ

Directory Proxy Server 5.2では、クライアント・アプリケーションに対し非表示とするエントリまたは属性の一覧は、ids-proxy-sch-ForbiddenEntryPropertyオブジェクトを使用して指定されていました。Directory Proxy Server 11gリリース1 (11.1.1.7.0)では、この機能はリクエスト・フィルタリング・ポリシーにsearch-data-hiding-ruleを作成することで実現しています。

Directory Proxy Server 5.2では、これらの構成属性は、ou=groups,cn=user-defined-name,ou=dar-config,o=NetscapeRootの下に保存されています。

次の表に、ids-proxy-sch-ForbiddenEntryPropertyオブジェクトの属性と、Directory Proxy Server 11gリリース1 (11.1.1.7.0)の対応する検索データ非表示ルールのプロパティのマッピングを示します。検索データ非表示ルールの作成の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の検索データの非表示ルールの作成に関する説明を参照してください。

表10-13 サーバー・ロード構成属性とリソース制限プロパティのマッピング

Directory Proxy Server5.2の属性

Directory Proxy Server 11gリリース1 (11.1.1.7.0)のプロパティ

ids-proxy-con-dn-exact

target-dns

ids-proxy-con-dn-regexp

target-dn-regular-expressions

ids-proxy-con-ava

target-attr-value-assertions

ids-proxy-con-forbidden-return

属性のサブセットを非表示にする場合:

rule-action:hide-attributes

attrs:attribute-name

エントリ全体を非表示にする場合:

rule-action:hide-entry

ids-proxy-con-permitted-return

rule-action:show-attributes

attrs:attribute-name

10.4.3 LDAPサーバーのプロパティ

Directory Proxy Server 5.2では、ids-proxy-sch-LDAPServerプロパティは、Directory Proxy Serverがリクエストを送信するバックエンドLDAPサーバーを定義するために使用されていました。Directory Proxy Server 11gリリース1 (11.1.1.7.0)では、この機能はLDAPデータ・ソースを使用して実現されています。LDAPデータ・ソースのプロパティは、Directory Service Control Centerを使用するか、コマンドラインを使用して設定できます。詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のLDAPデータ・ソースの作成および構成に関する説明を参照してください。

Directory Proxy Server 5.2では、これらの構成属性は、ou=groups,cn=user-defined-name,ou=dar-config,o=NetscapeRootの下に保存されています。

次の表に、ids-proxy-sch-LDAPServerオブジェクト・クラスの属性と、Directory Proxy Server 11gリリース1 (11.1.1.7.0)の対応するデータ・ソース・プロパティのマッピングを示します。データ・ソースには、Directory Proxy Server 5.2では提供されていなかった他の機能があります。ここでは、データ・ソースのすべてのプロパティは示していません。データ・ソースとして構成できるすべてのプロパティの一覧を表示するには、次のコマンドを実行します。

$ dpconf help-properties | grep ldap-data-source

表10-14 ids-proxy-sch-LDAPServer属性とデータ・ソース・プロパティのマッピング

Directory Proxy Server5.2の属性

Directory Proxy Server 11gリリース1 (11.1.1.7.0)のプロパティ

ids-proxy-con-host

ldap-address

ids-proxy-con-port

ldap-port

ids-proxy-con-sport

ldaps-port

ids-proxy-con-supported-version

該当するものはありません。

Directory Proxy Server 11gリリース1 (11.1.1.7.0)は、バージョン2およびバージョン3のクライアントの両方で、LDAP v3のバックエンドをサポートしています。

Directory Proxy Server 11gリリース1 (11.1.1.7.0)は、プロキシ認証制御バージョン1およびバージョン2をサポートしています。

ids-proxy-con-use-version

該当するものはありません。

Directory Proxy Server 11gリリース1 (11.1.1.7.0)は、バージョン2およびバージョン3の両クライアントでLDAP バージョン3のバックエンドをサポートしています。

Directory Proxy Server 11gリリース1 (11.1.1.7.0)では、プロキシ認証制御バージョン1およびバージョン2をサポートしています。

ids-proxy-con-tcp-no-delay

use-tcp-no-delay

ids-proxy-con-link-security-policy

ssl-policy

ids-proxy-con-x509cert-subject

該当するものはありません。Directory Proxy Server 11gリリース1 (11.1.1.7.0)は、バックエンド・サーバーによって提供される証明書のサブジェクトを確認しません。

ids-proxy-con-keepalive-interval

この機能は、LDAPデータ・ソースの次のプロパティを設定して実現しています。

monitoring-bind-timeout

monitoring-entry-timeout

monitoring-inactivity-timeout

monitoring-interval

LDAPデータ・ソース・プロパティの設定の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のLDAPデータ・ソースの構成に関する説明を参照してください。

10.4.4 ロード分散プロパティ

Directory Proxy Server 5.2では、複数のLDAPサーバーのロードを分散するためにids-proxy-sch-LoadBalancePropertyが使用されていました。Directory Proxy Server 5.2では、各LDAPサーバーに総ロードの特定割合を割り当てる比例ロード・バランシングのみがサポートされています。ids-proxy-sch-LoadBalancePropertyオブジェクトには、次の構文を持つids-proxy-con-Serverという1つの属性があります。

server-name[#percentage]

Directory Proxy Server 5.2では、これらの構成属性は、ids-proxy-con-name=load-balancing-1,ou=properties,cn=user-defined-name,ou=dar-config,o=NetscapeRootの下に保存されています。

Directory Proxy Server 11gリリース1 (11.1.1.7.0)では、データ・ソース・プールのプロパティでロード・バランシングを構成します。データ・ソース・プールは、基本的にDirectory Proxy ServerがリクエストをルーティングできるLDAPサーバーの集合です。データ・ソース・プールの設定の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のLDAPデータ・ソース・プールの作成および構成に関する説明を参照してください。データ・ソース・プールに関連するプロパティ一覧を表示するには、次のコマンドを実行します。

$ dpconf help-properties | grep ldap-data-source-pool

Directory Proxy Server 11gリリース1 (11.1.1.7.0)では、比例ロード・バランシングをサポートしていますが、これ以外にロード・バランシング・アルゴリズムもサポートしています。比例ロード・バランシングを構成するには、次のとおりデータ・ソース・プールのプロパティを設定します。

$ dpconf set-ldap-data-source-pool-prop data-source-pool-name \
load-balancing-algorithm:proportional

各サーバーに割り当てるロードの割合は、アタッチされているデータ・ソースの様々なプロパティを設定することによって構成します。アタッチされているデータ・ソースとは、特定のデータ・ソース・プールにアタッチされているデータ・ソースです。比例ロードを構成するには、各操作タイプにアタッチされているデータ・ソースの重みプロパティを次のとおりに設定します。

$ dpconf set-attached-ldap-data-source-prop data-source-pool-name attached-data-source-name
add-weight:value
bind-weight:value
compare-weight:value
delete-weight:value
modify-dn-weight:value
modify-weight:value
search-weight:value

詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のロード・バランシングの構成に関する説明を参照してください。

10.4.4.1 バックエンド・サーバーの監視

バックエンドのLDAPサーバーの監視に、Directory Proxy Server 5.2は各サーバーのルートDSEに対し匿名検索操作を10秒ごとに実行します。Directory Proxy Server 11gリリース1 (11.1.1.7.0)には、バックエンド・サーバーの監視を構成するプロパティが多数あります。詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のデータ・ソースの監視データの取得に関する説明を参照してください。

10.4.5 検索サイズ制限プロパティ

Directory Proxy Server 5.2では、検索操作のベースおよび範囲に基づいてサイズ制限を適用するためにids-proxy-sch-SizeLimitPropertyを使用していました。Directory Proxy Server 11gリリース1 (11.1.1.7.0)では、検索のサイズ制限は、リソース制限ポリシーのプロパティを設定して構成できます。リソース制限ポリシーでは、特定の接続ハンドラでDirectory Proxy Serverが処理できる最大リソースを定義します。dpconfコマンドを使用すると、次のようにリソース・ポリシーの検索サイズ制限を設定できます。

$ dpconf set-resource-limits-policy-prop policy-name search-size-limit:number-of-entries

リソース制限ポリシーでは、検索サイズ制限のみでなく、多くのものを制御できます。リソース制限ポリシーの構成の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』のリソース制限ポリシーの作成および構成に関する説明を参照してください。

Directory Proxy Server 5.2では、これらの構成属性は、ou=groups,cn=user-defined-name,ou=dar-config,o=NetscapeRootの下に保存されています。

次の表に、バージョン5.2のサイズ制限プロパティと、対応するDirectory Proxy Server 11gリリース1 (11.1.1.7.0)のプロパティのマッピングを示します。

表10-15 検索サイズ制限属性のマッピング

Directory Proxy Server5.2の属性

Directory Proxy Server 11gリリース1 (11.1.1.7.0)のプロパティ

ids-proxy-con-Size-Limit

search-size-limit

ids-proxy-con-Dn-One

one-level-search-base-dn

ids-proxy-con-Dn-Sub

該当するものはありません。

10.4.6 ログ・プロパティ

Directory Proxy Server 5.2のログ機能は、Directory Proxy Server 11gリリース1 (11.1.1.7.0)にある機能とは大幅に異なります。

Directory Proxy Server 5.2では、次のログが保守されています。

- システム・ログ。システム・イベントおよびエラーのログが記録されています。

- 監査ログ。すべてのイベントおよびエラーの監査証跡があります。

Directory Proxy Server 11gリリース1 (11.1.1.7.0)では、エラー・ログ・ファイル、アクセス・ログ・ファイルおよび管理アラートを維持します。

このエラー・ログおよび管理アラートは、バージョン5.2のシステム・ログに相当します。管理アラートは、Directory Proxy Serverによって発行されるイベントです。これらのイベントは、syslogデーモンまたは電子メールで管理者に送信できます。

Directory Proxy Server 11gリリース1 (11.1.1.7.0)のアクセス・ログは、バージョン5.2の監査ログに相当します。

バージョン5.2のログは、ids-proxy-sch-LogPropertyオブジェクト・クラスを使用して構成されていました。Directory Proxy Server 11gリリース1 (11.1.1.7.0)のログは、dpconfコマンドを使用し、アクセスおよびエラー・ログのプロパティを設定することによって構成します。たとえば、アクセス・ログのプロパティを設定するには、次のコマンドを使用します。

$ dpconf set-access-log-prop PROPERTY:VALUE

Directory Proxy Server 11gリリース1 (11.1.1.7.0)にはログ・ファイル・ローテーションなどの新機能があり、またログ構成を調整できます。たとえば、メッセージのカテゴリごとにログ・レベルを1つ設定できます。

Directory Proxy Server 5.2では、ログ構成の属性は、 ids-proxy-con-Config-Name=user-defined-name,ou=system,ou=dar-config,o=netscaperootの下に保存されています。

Directory Proxy Server 5.2とDirectory Proxy Server 11gリリース1 (11.1.1.7.0)の2つのバージョンのログ・モデルは大幅に異なるため、実際にはログ構成はマッピングできません。Directory Proxy Server 5.2のログ・モデルでは、ログの記録対象とログの記録場所は結合されています。Directory Proxy Server 11gリリース1 (11.1.1.7.0)では、このモデルはより単純になっています。あるプロパティのセットではログの記録対象を示し、別のプロパティのセットではログ・メッセージの送信先を示します。

次の表に、ids-proxy-sch-LogPropertyオブジェクト・クラスの属性と、対応する機能がDirectory Proxy Server 11gリリース1 (11.1.1.7.0)でどのように実現されているかの概要を示します。

表10-16 バージョン5.2およびバージョン11gリリース1 (11.1.1.7.0)のログ機能

Directory Proxy Server5.2の属性

用途

Directory Proxy Server 11gリリース1 (11.1.1.7.0)で相当するもの

ids-proxy-con-log-level

ロギングのレベル

グローバル・ログ・レベル

ids-proxy-con-stat-level

ログに記録される統計の種類

監視データ

ids-proxy-con-log-syslog

Syslogのファシリティ・コード

管理アラート用のsyslog出力

エラー・メッセージについては相当するものはありません

ids-proxy-con-log-file

ログ・ファイルへのパス

error-logオブジェクトのlog-file-name

ids-proxy-con-audit-syslog

監査ログ用のSyslogのファシリティ・コード

該当するものはありません。

ids-proxy-con-audit-file

監査ログ・ファイルへのパス

access-logオブジェクトのlog-file-name

2つのバージョン間のログ構成を1対1でマッピングすることはできないため、古いログ構成を移行するのではなく、新しいロギング・モデルを理解し、新しいログをそれに従って構成する必要があります。詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の第27章のDirectory Proxy Serverのロギングに関する説明を参照してください。

10.5 イベント構成のマッピング

Directory Proxy Server 5.2のイベント・オブジェクトは、事前定義した状態をDirectory Proxy Serverが評価する条件を指定するために使用します。

次の2種類のイベント・オブジェクトがサポートされています。

- OnBindSuccess。クライアントがバインド操作に成功すると評価されます。

- OnSSLEstablished。クライアントがSSLセッションの確立に成功すると評価されます。

Directory Proxy Server 11gリリース1 (11.1.1.7.0)では、イベントは接続ハンドラのプロパティとして実装されています。これらのプロパティの設定には、dpconfコマンドを使用します。たとえば、接続ハンドラの認証方法を設定するには、次のコマンドを実行します。

$ dpconf set-connection-handler-prop connection-handler-name \
allowed-auth-methods:anonymous allowed-auth-methods:sasl allowed-auth-methods:simple

Directory Proxy Server 5.2では、これらの構成属性は、ids-proxy-con-Config-Name=user-defined-name,ou=system,ou=dar-config,o=netscaperootの下に保存されます。

次の表に、バージョン5.2のイベント構成属性と、対応するDirectory Proxy Server 11gリリース1 (11.1.1.7.0)のプロパティのマッピングを示します。

表10-17 イベント属性と接続ハンドラ・プロパティのマッピング

Directory Proxy Server5.2の属性

Directory Proxy Server 11gリリース1 (11.1.1.7.0)のプロパティ

ids-proxy-sch-OnBindSuccessRule

bind-dn-filters

ids-proxy-con-ssl-required

is-ssl-mandatory

ids-proxy-con-bind-anonymous

allowed-auth-methods:anonymous

ids-proxy-con-bind-simple

allowed-auth-methods:simple

ids-proxy-con-bind-sasl

allowed-auth-methods:sasl

10.6 アクション構成のマッピング

Directory Proxy Server 5.2では、ids-proxy-sch-ChangeGroupActionオブジェクト・クラスで指定する1つのアクションのみをサポートしています。このアクションでは、ルールでの評価に基づいてDirectory Proxy Serverがクライアントのアクセス・グループを別のものに変更できます。このアクションでは、クライアントが変更可能なグループを指定する複数の値で構成されるids-proxy-con-to-group属性を使用します。

Directory Proxy Server11gリリース1 (11.1.1.7.0)では、接続ハンドラがこの機能を提供しています。接続ハンドラ内に分類されると、接続は別の接続ハンドラに自動的に再分類されます。たとえば、クライアントが匿名で接続された場合、その接続は匿名接続用に構成された接続ハンドラに割り当てられます。後でクライアントが同じ接続上でバインドDNを提供すると、接続を別の接続ハンドラに割り当てることができます。

Directory Proxy Server 11gリリース1 (11.1.1.7.0)でこの機能を構成する方法の詳細は、『Oracle Directory Server Enterprise Edition管理者ガイド』の接続ハンドラの作成、構成および削除に関する説明を参照してください。

10.7 単純な接続ベースのルータとしてのDirectory Proxy Server 11gリリース1 (11.1.1.7.0)の構成

Directory Proxy Server 11gリリース1 (11.1.1.7.0)のインスタンスは、Directory Proxy Server 5.2と同じ機能を持つ単純な接続ベースのルータとして動作するよう構成できます。これを行うには、前述の構成属性をマッピングし、『Oracle Directory Server Enterprise Edition管理者ガイド』の接続ベースのルータとしてのDirectory Proxy Serverの構成に関する説明の手順に従います。

11 Identity Synchronization for Windowsの移行

この章では、システムのIdentity Synchronization for Windowsバージョン1.1およびバージョン1.1 SP1をバージョン6.0 SP1に移行する方法を説明します。

この章の後半では、バージョン1.1にはバージョン1.1 SP1も含まれます。

注意:

システムにIdentity Synchronization for Windowsバージョン1.1をインストールすると、Message Queueもインストールされます。Identity Synchronization for Windows 6.0 SP1では、Message Queueはインストールされません。

Message Queueのインストールおよびアップグレードに関する詳細は、http://docs.sun.com/coll/1286.2 (http://docs.sun.com/coll/1286.2)にあるJava Enterprise Systemソフトウェアのインストール手順をお読みください。

この章では、次の項目について説明します。

- 「移行の概要」

- 「Identity Synchronization for Windowsを移行する前に」

- 「Identity Synchronization for Windowsの移行の準備」

- 「システムの移行」

- 「1.1のアンインストールが失敗した場合の対応」

- 「その他の移行シナリオ」

- 「ログの確認」

11.1 移行の概要

Identity Synchronization for Windowsのバージョン1.1からバージョン6.0 SP1への移行は、次に大別した段階で実現されます。

1. Identity Synchronization for Windows 1.1のインストールを移行する準備をします。

2. Identity Synchronization for Windows 1.1をアンインストールします。

3. 依存関係のある製品をインストールするかアップグレードします。

4. バックアップしておいた構成およびコネクタの状態を使用して、Identity Synchronization for Windows 6.0 SP1をインストールします。

注意:

Identity Synchronization for Windows 6.0 SP1は、Identity Synchronization for Windows 1.1をインストールしたのと同じプラットフォームおよびアーキテクチャにインストールしてください。

11.2 Identity Synchronization for Windowsを移行する前に

移行プロセスを開始する前に、次の作業を行います。

- Identity Synchronization for Windows 6.0 SP1の新機能を理解します。

- 『Identity Synchronization for Windows 6インストレーション・ガイド』の第1章の製品の理解に関する説明を読み、移行プロセスの計画時に利用できるインストールおよび構成の情報を得ます。

- バージョン1.1のデプロイメントおよび構成について文書化します。構成に対して行ったすべてのカスタマイズを必ず書き出します。

- 移行の予定を立てます。移行には、少なくとも4時間かかるため、移行は通常の業務時間以降にスケジュールした方がよい場合もあります。

システムの移行中に入力パスワードや属性が変わった場合、Identity Synchronization for Windowsではこれらの変更を次のとおり処理します。

- Active Directoryの場合: 移行プロセス中にActive Directoryで変更されたパスワードは、移行プロセスの完了後に、要求に応じて、Directory Serverプラグインによって同期されます。

- Directory Serverの場合: 移行プロセス中にDirectory Serverで行われたすべてのパスワードの変更は同期されません。ただし、移行プロセスの完了後に、Identity Synchronization for Windows 6.0 SP1のログで影響を受けるユーザーを確認できます。詳細は、「ログの確認」を参照してください。

- Windows NTの場合: 移行プロセス中にNTで行われたすべてのパスワード変更は同期されません。
ただし、forcepwchgユーティリティを使用すると、影響を受けるユーザーを特定し、パスワードの再変更を強制できます。詳細は、「Windows NTでのパスワード変更の強制」を参照してください。

- (任意のディレクトリ・ソースで)移行プロセス中に行われるその他すべての属性変更は、移行プロセスの完了後に同期されます。

11.3 Identity Synchronization for Windowsの移行の準備

Identity Synchronization for Windows 1.1からIdentity Synchronization for Windows 6.0 SP1に移行するには、次のユーティリティを単独で使用するか組み合せて使用します。

- export11cnf.Identity Synchronization for Windows 1.1の構成からエクスポートして構成ファイルを作成する、スタンドアロン・ユーティリティです。詳細は、「バージョン1.1の構成のエクスポート」を参照してください。
エクスポートしたXMLドキュメントには、ディレクトリ・デプロイメントのトポロジおよびIdentity Synchronization for Windows 6.0 SP1のインストールの構成に十分な情報が含まれます。

- checktopics: 1.1インストールのMessage Queueの同期トピックスを調べ、キューに未送信のメッセージがあるかどうかを確認するユーティリティです。
1.1の同期の停止後、更新がMessage Queueに残される場合があります。移行を進める前に、Message Queueには更新がないことを確認します。詳細は、「未配信メッセージの確認」を参照してください。

- forcepwchg: 移行プロセス中にパスワードを変更したユーザーを識別し、6.0 SP1システムの準備が整ったら、パスワードの変更をそれらのユーザーに強制できるWindows NTのツールです。Windows NT上でのパスワードの変更は、移行プロセス中には取得されません。詳細は、「Windows NTでのパスワード変更の強制」を参照してください。

注意:

これらのユーティリティは、Identity Synchronization for Windowsバージョン1.1からバージョン6.0 SP1への移行を容易にします。移行は、Identity Synchronization for Windows 1.1がデプロイされた環境と同じ環境で実行します。このため、これらのユーティリティは、Solaris/SPARCおよびWindowsパッケージのみにあります。

移行ユーティリティは、インストールのmigrationディレクトリにあります。これ以外のインストール手順は必要ありません。

11.3.1 バージョン1.1の構成のエクスポート

export11cnfユーティリティを使用して既存のバージョン1.1の構成ファイルをXMLファイルとしてエクスポートし、コネクタのインストール前にidsync importcnfコマンドを使用して、そのファイルをIdentity Synchronization for Windows 6.0 SP1システムにインポートできます。

ヒント:

1.1システムの構成は、Identity Synchronization for Windowsコンソールを使用して手動で更新できますが、export11cnfユーティリティを使用することをお薦めします。export11cnfを使用しない場合は、コネクタの状態は保存されません。

バージョン1.1の構成をエクスポートすると、次が可能になります。

- 管理コンソールで行うほとんどの初期構成プロセスを省略できます。

- バージョン6.0 SP1で割り当てられるコネクタIDが、バージョン1.1で使用されていたコネクタIDと確実に一致するようになります。これによって、既存のコネクタの状態をバージョン6.0 SP1のデプロイメントで単純にそのまま保てるようになります。
基礎となるディレクトリ構造が混乱しないように、persistおよびetcディレクトリをバックアップし後でリストアします。

export11cnfユーティリティは、インストールのmigrationディレクトリにあります。これ以外のインストール手順は必要ありません。

11.3.1.1 export11cnfユーティリティの使用

Identity Synchronization for Windowsの構成をXMLファイルにエクスポートする場合、次のとおりexport11cnfをmigrationディレクトリから実行します。

端末ウィンドウに次を入力します。

java -jar export11cnf.jar -h hostname \
-p port -D bind DN \
-w bind password -s rootsuffix \
-q configuration password -Z -P cert-db-path \
-m secmod-db-path -f filename

例:

java -jar export11cnf.jar -D "cn=dirmanager" -w - -q - -s "dc=example,dc=com" -f exported-configuration

export11cnfユーティリティは、Identity Synchronization for Windowsのコマンドライン・ユーティリティと同じ共通の引数を使用します。詳細は、『Identity Synchronization for Windows 6インストレーション・ガイド』のIdsyncのサブコマンドと共通する引数に関する説明を参照してください。export11cnfユーティリティでは、現在の構成を-fオプションの引数で指定したファイルにエクスポートできます。

11.3.1.2 クリア・テキスト・パスワードの挿入

セキュリティ上の理由から、export11cnfユーティリティではバージョン1.1以降、クリア・テキスト・パスワードをエクスポートできなくなりました。かわりに、該当する場合、ユーティリティはcleartextPasswordフィールドに空の文字列を挿入します。例:

<Credentials
userName="cn=iswservice,cn=users,dc=example,dc=com"
cleartextPassword=""/>
<!-- INSERT PASSWORD BETWEEN THE DOUBLE QUOTES IN THE ABOVE FIELD ->

Identity Synchronization for Windowsにファイルをインポートする前に、エクスポートした構成ファイルのすべてのcleartextPasswordフィールドの二重引用符の間に、パスワードを手動で入力する必要があります。パスワード値が空の場合、importcnfの検証により構成ファイルはインポートされません。

例:

<Credentials
userName="cn=iswservice,cn=users,dc=example,dc=com"
cleartextPassword="mySecretPassword"/>
<!-- INSERT PASSWORD BETWEEN THE DOUBLE QUOTES IN THE ABOVE FIELD ->

11.3.1.3 構成ファイルのエクスポートの例

次のエクスポートされた構成ファイルの例では、

- ad-host.example.comはActive Directoryのドメイン・コントローラを指します。

- ds-host.example.comはDirectory Serverを実行するホストを指します。

例11-1 構成ファイルのエクスポートの例

<?xml version="1.0" encoding="UTF-8"?>

<ActiveConfiguration>
<SunDirectorySource
parent.attr="DirectorySource"
onDemandSSLOption="true"
maxConnections="5"
displayName="dc=example,dc=com"
resyncInterval="1000">

<SynchronizationHost
hostOrderOfSignificance="1"
hostname="ds-host.example.com"
port="389"
portSSLOption="true"
securePort="636"/>
<Credentials
userName="uid=PSWConnector,
dc=example,
dc=com"
</SynchronizationHost>
<SyncScopeDefinitionSet
index="0"
location="ou=people,dc=example,dc=com"
filter=""
creationExpression="uid=%uid%,ou=people,dc=example,dc=com"
sulid="SUL1"/>
</SunDirectorySource>

<ActiveDirectorySource
parent.attr="DirectorySource"
displayName="example.com"
resyncInterval="1000">
<SynchronizationHost
hostOrderOfSignificance="1"
hostname="ad-host.example.com"
port="389"
portSSLOption="true"
securePort="636">
<Credentials
userName="cn=Administrator,cn=Users,dc=metaqa,dc=com"
cleartextPassword=""/>
<!-- INSERT PASSWORD BETWEEN THE DOUBLE QUOTES IN THE ABOVE FIELD ->
</SynchronizationHost>
<SyncScopeDefinitionSet
index="0"
location="cn=users,dc=example,dc=com"
filter=""
creationExpression="cn=%cn%,cn=users,dc=example,dc=com"
sulid="SUL1"/>
</ActiveDirectorySource>

<ActiveDirectoryGlobals
flowInboundCreates="true"
flowInboundModifies="true"
flowOutboundCreates="true"
flowOutboundModifies="true">
<TopologyHost
parent.attr="SchemaLocation"
hostname="ad-host.example.com"
port="3268"
portSSLOption="true"
securePort="3269">
<Credentials
parent.attr="Credentials"
userName="cn=Administrator,cn=Users,dc=example,dc=com"
cleartextPassword=""/>
<!-- INSERT PASSWORD BETWEEN THE DOUBLE QUOTES IN THE ABOVE FIELD ->
</TopologyHost>

<TopologyHost
parent.attr="HostsTopologyConfiguration"
hostname="ad-host.example.com"
port="3268"
portSSLOption="true"
securePort="3269">
<Credentials
parent.attr="Credentials"
userName="cn=Administrator,cn=Users,dc=example,dc=com"
cleartextPassword=""/>
<!-- INSERT PASSWORD BETWEEN THE DOUBLE QUOTES IN THE ABOVE FIELD ->
</TopologyHost>

<AttributeMap>
<AttributeDescription
parent.attr="WindowsAttribute"
name="lockouttime"
syntax="1.2.840.113556.1.4.906"/>
<AttributeDescription
parent.attr="SunAttribute"
name="pwdaccountlockedtime"
syntax="1.3.6.1.4.1.1466.115.121.1.24"/>
</AttributeMap>

<AttributeDescription
parent.attr="SignificantAttribute"
name="lockouttime"
syntax="1.2.840.113556.1.4.906"/>
<AttributeDescription
parent.attr="SignificantAttribute"
name="samaccountname"
syntax="1.3.6.1.4.1.1466.115.121.1.15"/>
<AttributeDescription
parent.attr="CreationAttribute"
name="samaccountname"
syntax="1.3.6.1.4.1.1466.115.121.1.15"/>
<AttributeMap>
<AttributeDescription
parent.attr="WindowsAttribute"
name="samaccountname"
syntax="1.3.6.1.4.1.1466.115.121.1.15"/>
<AttributeDescription
parent.attr="SunAttribute"
name="uid"
syntax="1.3.6.1.4.1.1466.115.121.1.15"/>
</AttributeMap>

<AttributeMap>
<AttributeDescription
parent.attr="SunAttribute"
name="sn"
syntax="1.3.6.1.4.1.1466.115.121.1.15"/>
<AttributeDescription
parent.attr="WindowsAttribute"
name="sn"
syntax="1.3.6.1.4.1.1466.115.121.1.15"/>
</AttributeMap>

<AttributeDescription
parent.attr="SignificantAttribute"
name="sn"
syntax="1.3.6.1.4.1.1466.115.121.1.15"/>
<AttributeDescription
parent.attr="SignificantAttribute"
name="cn"
syntax="1.3.6.1.4.1.1466.115.121.1.15"/>
<AttributeDescription
parent.attr="CreationAttribute"
name="cn"
syntax="1.3.6.1.4.1.1466.115.121.1.15"/>
<AttributeMap>
<AttributeDescription
parent.attr="SunAttribute"
name="cn"
syntax="1.3.6.1.4.1.1466.115.121.1.15"/>
<AttributeDescription
parent.attr="WindowsAttribute"
name="cn"
syntax="1.3.6.1.4.1.1466.115.121.1.15"/>
</AttributeMap>

<AttributeMap>
<AttributeDescription
parent.attr="SunAttribute"
name="uniquemember"
syntax="1.3.6.1.4.1.1466.115.121.1.25"/>
<AttributeDescription
parent.attr="WindowsAttribute"
name="member"
syntax="1.2.840.113556.1.4.910"/>
</AttributeMap>

<AttributeDescription
parent.attr="SignificantAttribute"
name="member"
syntax="1.2.840.113556.1.4.910"/>
</ActiveDirectoryGlobals>

<SunDirectoryGlobals
userObjectClass="inetOrgPerson"
flowInboundCreates="true"
flowInboundModifies="true"
flowOutboundCreates="true"
flowOutboundModifies="true">
<AttributeDescription
parent.attr="SignificantAttribute"
name="uniquemember"
syntax="1.3.6.1.4.1.1466.115.121.1.25"/>
<AttributeDescription
parent.attr="CreationAttribute"
name="cn"
syntax="1.3.6.1.4.1.1466.115.121.1.15"/>
<AttributeDescription
parent.attr="SignificantAttribute"
name="cn"
syntax="1.3.6.1.4.1.1466.115.121.1.15"/>
<AttributeDescription
parent.attr="SignificantAttribute"
name="pwdaccountlockedtime"
syntax="1.3.6.1.4.1.1466.115.121.1.24"/>
<TopologyHost
parent.attr="SchemaLocation"
hostname="ds-host.example.com"
port="389"
portSSLOption="false"
securePort="636">
<Credentials
parent.attr="Credentials"
userName="cn=directory manager"
cleartextPassword=""/>
<!-- INSERT PASSWORD BETWEEN THE DOUBLE QUOTES IN THE ABOVE     FIELD ->
</TopologyHost>
<AttributeDescription
parent.attr="SignificantAttribute"
name="uid"
syntax="1.3.6.1.4.1.1466.115.121.1.15"/>
<AttributeDescription
parent.attr="CreationAttribute"
name="sn"
syntax="1.3.6.1.4.1.1466.115.121.1.15"/>
<AttributeDescription
parent.attr="SignificantAttribute"
name="sn"
syntax="1.3.6.1.4.1.1466.115.121.1.15"/>
</SunDirectoryGlobals>
</ActiveConfiguration>

export11cnfによって構成のエクスポートが完了すると、処理の結果がレポートされます。処理が失敗した場合、適切なエラー・メッセージがエラー識別子とともに表示されます。

11.3.2 未配信のメッセージの確認

既存のデプロイメントのコネクタ状態を保つことにより、移行プロセスでシステムのダウンタイムを減らすことができます。ただし、これらは、Message Queueが最後に受信および確認した変更までの状態です。したがって、メッセージが送信先のコネクタに実際に配信され適用されているかどうかはわかりません。

Message Queueが同一であるかぎり、この動作により問題は発生しません。ただし、移行プロセスでMessage Queue 3.6をインストールすると、Message Queue上のすべてのメッセージが失われます。

移行を進める前に、既存のMessage Queue上の同期トピックに未配信のメッセージがないことを確認する必要があります。Identity Synchronization for Windowsのchecktopicsユーティリティでは、すべての同期トピックが空で、システムで問題が発生していないことを確認できます。

11.3.2.1 checktopicsユーティリティの使用

checktopicsユーティリティは、Solaris/SPARCおよびWindows Identity Synchronization for Windows 6.0 SP1パッケージのmigrationディレクトリに含まれ配布されます。

注意:

checktopicsを実行するには、Java仮想マシンが前提条件となります。

checktopicsユーティリティを実行すると、同期ユーザー・リスト(SUL)の情報と、Message Queueで使用される現在の同期トピック名を含む構成ディレクトリに接続されます。また、checktopicsを実行すると、アクティブな同期トピックに残されている未配信のメッセージがMessage Queueに照会され、その情報が表示されます。

checktopics コマンドライン・ユーティリティを実行するには、次の手順を実行します。

1. 端末ウィンドウを開き、cdでmigrationディレクトリに移動します。

2. コマンド・プロンプトに次のとおりサブコマンドを入力します。

java -jar checktopics.jar -h hostname \
-p port -D bind-DN \
-w bind-password -s root-suffix \
-q configuration-password -Z

例:

java -jar checktopics.jar -D "cn=directory manager" -w - -s "dc=example,dc=com" -q -Z

注意:

checktopicsの引数の詳細は、『Identity Synchronization for Windows 6インストレーション・ガイド』のIdsyncのサブコマンドと共通する引数に関する説明を参照してください。checktopicsの使用の詳細は、「未配信メッセージの確認」を参照してください。

checktopicsの実行後、端末で次のメッセージを確認します。

- 処理が正常に完了している場合、未配信メッセージがログに残されていないことを示すメッセージが端末ウィンドウに表示されます。

- 処理が失敗した場合、適切なエラー・メッセージがエラー識別子とともに表示されます。

11.3.2.2 メッセージのクリア

アクティブないずれかの同期トピックに未配信のメッセージがある場合、次の手順を使用してメッセージをクリアします。

1. 同期を再開します。

2. 送信先コネクタにメッセージが適用されるまで待ちます。

3. 同期を終了します。

4. checktopicsを再実行します。

11.3.3 Windows NTでのパスワード変更の強制

Windows NTではパスワードの変更は監視されず、新しいパスワード値は移行の処理時に取り込まれません。その結果に、移行プロセス後に新しいパスワード値を特定できません。

6.0 SP1へ移行が完了した後にすべてのユーザーにパスワードの変更を要求するかわりに、forcepwchgコマンドライン・ユーティリティを使用し、移行プロセス中にパスワードを変更したすべてのユーザーにパスワードの変更を求めることができます。

注意:

forcepwchgユーティリティは、Windowsパッケージにのみあります。

forcepwchgユーティリティはWindowsのmigrationディレクトリにあります。このディレクトリからforcepwchgを直接実行します。これ以外のインストール手順は必要ありません。

forcepwchgは、NTコンポーネント(コネクタ、Change DetectorのDLLおよびPassword Filter DLL)がインストールされているプライマリ・ドメイン・コントローラ(PDC)のホストで実行する必要があります。forcepwchgはリモートから実行できません。

forcepwchgユーティリティでは、移行を試行しているアカウント名も(1行に1つずつ)出力されます。移行プロセス中にエラーが発生した場合には、最後に出力されたエントリの次のエントリを確認します。

11.4 システムの移行

この項では、単一ホストのデプロイメントをバージョンIdentity Synchronization for Windows 6.0 SP1に移行する手順を説明します。

単一ホストのデプロイメントでは、Identity Synchronization for Windowsのすべてのコンポーネントは、次に示す単一のホスト(Windows 2000 Server、Solarisバージョン8または9、またはSPARC)にインストールされます。

- Directory Server (1インスタンス)

- コア(Message Queue、Central Logger、システム・マネージャ、コンソール)

- Active Directoryコネクタ

- Directory Serverコネクタ

- Directory Serverプラグイン

注意:

インストール・ホストとしてSolarisを使用している場合、Active Directoryを含むWindows 2000マシンが同期専用に必要です。(Windows 2000マシンにはコンポーネントはインストールされません。)

次の図に移行プロセスを示します(これは、以降の移行プロセスを補足するチェックリストとして使用できます)。

図11-1 単一ホストのデプロイメントの移行

「図11-1 単一ホストのデプロイメントの移行」の説明

11.4.1 移行の準備

バージョン6.0 SP1への移行を準備する手順は、次のとおりです。

11.4.1.1 バージョン1.1および1.1 SP1のバージョン6.0 SP1への移行の準備

1. 端末ウィンドウまたはコマンド・プロンプトを開きます。

- Solarisの場合、次のコマンドを入力します。

uncompress -c filename | tar xf -

- Windowsの場合、次のコマンドを入力するか、WinZipなどの任意のWindowsのアーカイブ・プログラムを使用します。

%JAVA_HOME%\bin\jar -xf filename

バイナリの解凍後、次のサブディレクトリに必要な移行ツールが含まれます。

- installer/

- lib/

- migration/

Solaris

Windows

export11cnf.jar

export11cnf.jar

forcepwchg.exe

checktopics.jar

checktopics.jar

2. バージョン1.1の構成設定をXMLファイルにエクスポートします。
「export11cnfユーティリティの使用」の説明に従って、migrationディレクトリからexport11cnfを実行します。

java -jar export11cnf.jar -D "cn=directory manager" -w - \
-s "dc=example,dc=com" -q - -f export.cfg

3. エクスポートされたXMLファイルにパスワードを追加します。
エクスポートされた構成ファイルのそれぞれのcleartextPasswordフィールドの二重引用符の間にパスワードを入力します。詳細は、「クリア・テキスト・パスワードの挿入」を参照してください。

4. 『Identity Synchronization for Windows 6インストレーション・ガイド』の同期の開始および終了に関する説明に従って、同期を終了します。

5. システムが安定した状態であることを確認します。
「checktopicsユーティリティの使用」の説明に従って、migrationディレクトリでchecktopicsを実行します。次に、checktopicsコマンドの実行例を示します。

java -jar checktopics.jar -D "cn=directory manager" -w - \
-s "dc=example,dc=com" -q -Z

6. 『Identity Synchronization for Windows 6インストレーション・ガイド』のサービスの開始および停止に関する説明に従って、Identity Synchronization for Windowsサービス(デーモン)を停止します。

注意:

Sun ONE Message Queueサービスは停止しないでください。

7. Windows NTのみで次の手順を実行します。

1. 次のコマンドを入力し、Sun One NT Change Detectorサービスを停止します。

net stop "Sun One NT ChangeDetector Service"

2. NT Change Detectorサービスのカウンタを保存します。

1. regedt32.exeを実行して、レジストリ・エディタを開きます。

2. HKEY_LOCAL_MACHINEウィンドウを選択します。

3. SOFTWARE\Sun Microsystems\PSW\1.1ノードに移動します。

4. 次のレジストリ値を保存します。
HighestChangeNumber

LastProcessedSecLogRecordNumber

LastProcessedSecLogTimeStamp

QueueSize

8. 既存の1.1のインストール・ツリーから、persistおよび etcディレクトリをバックアップしてコネクタの状態を保存します。

- Solarisの場合、次のコマンドを入力します。

cd serverRoot/isw-hostname
tar cf /var/tmp/connector-state.tar persist etc

- Windowsの場合、次のコマンドを入力します。

cd serverRoot\isw-hostname
zip -r C:\WINNT\Temp\connector-state.zip persist etc
%JAVA_HOME%\bin\jar -cfM %TEMP%\connector-state.jar persist etc

または、WinZipなどのWindows用の任意のアーカイブ・プログラムを使用します。

9. Identity Synchronization for Windowsサービスを開始します。詳細は、『Identity Synchronization for Windows 6インストレーション・ガイド』の同期の開始および停止に関する説明を参照してください。

11.4.2 Identity Synchronization for Windowsのアンインストール

注意:

SUNWjssパッケージは、別のアプリケーションで使用されるよう登録されていないかぎり、Identity Synchronization for Windows 1.1のアンインストール・プログラムによって削除されます。特に、SolarisマシンにDirectory Server 5.2のzipバージョンをインストールした場合、アンインストール・プログラムによって/usr/share/lib/mps/secv1からjss3.jarファイルが削除される場合があります。

Identity Synchronization for Windows 6.0 SP1に移行する際、この問題が発生した場合には、インストーラによって必要なファイルが存在しないことがレポートされ、インストール・ログにそのファイル名が記録されます。これが発生した場合には、必要なパッチを再インストールして、インストール・プロセスを再度実行する必要があります。必要なパッチ一覧については、『Oracle Directory Server Enterprise Editionリリース・ノート』のソフトウェア依存関係の要件に関する説明を参照してください。

11.4.2.1 Identity Synchronization for Windows Version 1.1のアンインストール

1. Directory Serverプラグインを手動でアンインストールし、プラグインがインストールされているDirectory Serverをそれぞれ再起動します。
プラグインがインストールされている各Directory Serverで次の手順を実行します。

1. Directory Serverから次のエントリを削除します。
cn=config,cn=pswsync,cn=plugins,cn=configcn=pswsync,cn=plugins,cn=config

次に例を示します。

ldapdelete -D "cn=directory manager" -w - -p <port> \
-c cn=config,\ cn=pswsync,cn=plugins,cn=configcn=pswsync,cn=plugins,cn=config

2. Directory Serverを再起動します。
Solarisの場合: < serverRoot >/slapd-<hostname >/restart-slapdを入力します

Windowsの場合: < serverRoot>\slapd-< hostname>\restart-slapd.batを入力します

3. システムからプラグイン・バイナリを削除します。
Solarisの場合: rm < serverRoot >/lib/psw-plugin.sorm < serverRoot >/lib/64/psw-plugin.soを入力します。

Windowsの場合: del <serverRoot>\lib\psw-plugin.dllを入力します。

2. < ServerRoot >\isw-< hostname>にディレクトリを変更(cd)し、Identity Synchronization for Windows 1.1 (または1.1 SP1)のアンインストール・プログラムを使用して、バージョン1.1、1.1 SP1、コネクタおよびコア・コンポーネントをアンインストールします。

注意:

コア・コンポーネントをアンインストールする前に、コネクタをアンインストールする必要があります。

- SolarisまたはSPARCの場合: ./runUninstaller.shを入力します。

- Windowsの場合: \runUninstaller.batを入力します。

3. 製品のレジストリ・ファイルをバックアップし、ファイルからIdentity Synchronization for Windows関連のエントリを削除します。
ファイルの場所は次のとおりです。

- Solarisの場合: /var/sadm/install/productregistry

- Windowsの場合: C:\WINNT\System32\productregistry

Identity Synchronization for Windows関連のエントリを製品レジストリ・ファイルから削除するには、「Solarisからの1.1コアおよびインスタンスの手動アンインストール」に記載されている手順に従います。

4. Windowsのみに該当します。コアのアンインストール後、マシンを再起動します。

注意:

アンインストールが失敗した場合、Identity Synchronization for Windowsコンポーネントを手動でアンインストールする必要が生じる場合があります。手順は、「1.1のアンインストールが失敗した場合の対応」のとおりです。

5. Windowsのみに該当します。Identity Synchronization for Windowsが実行されていないことを確認します。必要に応じて、コマンドラインに次のコマンドを入力し、サービスを停止します。

net stop "Sun ONE Identity Synchronization for Windows"

アンインストール後、サービスが継続される場合、共有違反が発生してインスタンス・ディレクトリは削除できません。

6. Identity Synchronization for Windowsインスタンス・ディレクトリ(isw-< hostname >)を削除します。

11.4.3 依存関係のある製品のインストールまたはアップグレード

次に、Java Run Environmentのアップグレード、Message Queueのインストール、Directory Serverのアップグレード手順を示します。

1. Identity Synchronization for Windowsがインストールされている各ホスト(Windows NTを除く)で、Java 2 Runtime Environment (またはJava 2 SDK)をアップグレードします。必要な最小バージョンは1.5.0です。

- Java 2 SDKの場合: http://java.sun.com/j2se/1.5.0/install.html (http://java.sun.com/j2se/1.4.2/install.html)

- Java 2実行時環境の場合: http://java.sun.com/j2se/1.5.0/jre/install.html (http://java.sun.com/j2se/1.4.2/jre/install.html)

2. 『Sun Java System Message Queue 3.6インストレーション・ガイド』に記載されている手順に従って、Message Queue 3.6をインストールします。

3. Directory Serverをバージョン11gリリース1 (11.1.1.7.0)にアップグレードします。詳細は、第5章「Directory Serverの移行プロセスの概要」を参照してください。

注意:

管理サーバーをそのままの状態で維持するには、Directory Server (構成およびデータ)をバージョン11gリリース1 (11.1.1.7.0)に移行する際に、-Nオプションを使用します。構成データおよびユーザー・データの移行の詳細は、「構成データの移行のためのdsmigの使用」および「ユーザー・データを移行するためのdsmigの使用」をそれぞれ参照してください。

Directory Serverをアップグレードした場合、現在のDirectory Serverの構成とデータベースは維持されます。

11.4.4 Identity Synchronization for Windows 6.0 SP1のインストール

次に、Identity Synchronization for Windows 6.0 SP1のコンポーネントをインストールする手順を示します。

11.4.4.1 Identity Synchronization for Windows 6.0 SP1のコンポーネントのインストール

1. Identity Synchronization for Windowsコアをインストールします。詳細は、『Identity Synchronization for Windows 6インストレーション・ガイド』のコアのインストールに関する説明を参照してください。

2. Directory Serverに対しidsync prepdsを実行し、スキーマを更新します。

- Solarisの場合は、次のコマンドを入力します。

cd /opt/SUNWisw/bin
idsync prepds arguments\

- Windowsの場合は、次のコマンドを入力します。

cd serverRoot\isw-hostname\bin
idsync prepds arguments\

idsync prepdsの詳細は、『Identity Synchronization for Windows 6インストレーション・ガイド』の付録AのIdentity Synchronization for Windowsのコマンドライン・ユーティリティの使用に関する説明を参照してください。

3. 次のコマンドを入力し、バージョン1.1および1.1 SP1、構成XMLファイルをインポートします。

idsync importcnf arguments\

注意:

プログラムで入力構成ファイルにエラーが検出される場合、エラーが発生します。Identity Synchronization for Windowsによって、importcnfプロセスが中断され、エラーの修正に必要な情報が出力されます。

idsync importcnfの使用方法の詳細は、『Identity Synchronization for Windows 6インストレーション・ガイド』のimportcnfの使用に関する説明を参照してください。

4. Identity Synchronization for Windows 6.0 SP1のコネクタをインストールします。詳細は、『Identity Synchronization for Windows 6インストレーション・ガイド』のコネクタのインストールに関する説明を参照してください。

5. Directory Serverコネクタのインストール時に、「Identity Synchronization for Windows 6.0 SP1 Directory Serverプラグインの構成」オプションを選択しなかった場合、ここで構成します。詳細は、『Identity Synchronization for Windows 6インストレーション・ガイド』の付録AのIdentity Synchronization for Windowsのコマンドライン・ユーティリティの使用に関する説明を参照してください。

6. Identity Synchronization for Windowsサービス(デーモン)を『Identity Synchronization for Windows 6インストレーション・ガイド』のサービスの開始および停止に関する説明に従って停止します。

7. Windows NTのみで次の手順を完了します。

1. 次のコマンドを入力し、NTのChange Detectorサービスを停止します。

net stop "Sun Java(TM) System NT Change Detector"

2. NT Change Detectorサービスのカウンタを復元します。

1. regedt32.exeを実行して、レジストリ・エディタを開きます。

2. HKEY_LOCAL_MACHINEウィンドウを選択します。

3. SOFTWARE\Sun Microsystems\Sun Java(TM) System name="PN_IdSyncForWindows" content="Identity Synchronization for Windows"\1.1ノードに移動します。

4. 次の各エントリをダブルクリックし、(バージョン1.1のアンインストール前に保存した)値を復元します。
HighestChangeNumber

LastProcessedSecLogRecordNumber

LastProcessedSecLogTimeStamp

QueueSize

3. 次のコマンドを入力し、NTのChange Detectorのサービスを開始します。

net start "Sun Java(TM) System NT Change Detector"

8. インスタンスのディレクトリからバージョン6.0 SP1のpersistおよびetcディレクトリ(およびそのすべての内容)を削除し、「移行の準備」でバックアップしたバージョン1.1および1.1 SP1のpersistおよびetcディレクトリを復元します。

- Solarisの場合、次のコマンドを入力します。

cd /var/opt/SUNWisw
rm -rf etc persisttar xf /var/tmp/connector-state.tar

- Windowsの場合、次のコマンドを入力します。

cd serverRoot\isw-hostname
rd /s etc persist%JAVA_HOME%\bin\jar -xf %TEMP%\ connector-state.jar

または、WinZipなどのWindows用の任意のアーカイブ・プログラムを使用します。

9. サービスおよび同期を開始します。

1. Identity Synchronization for Windowsサービスを『Identity Synchronization for Windows 6インストレーション・ガイド』のサービスの開始および停止に関する説明に従って開始します。

2. 『Identity Synchronization for Windows 6インストレーション・ガイド』の同期の開始および停止に関する説明に従って、同期を開始します。

10. 中央の監査ログを調べ、警告メッセージがないことを確認します。

注意:

バージョン1.1のログ設定をカスタマイズした場合、Identity Synchronization for Windows 6.0 SP1のインストールには、それらのカスタマイズを手動で適用する必要があります。Identity Synchronization for Windowsコンソールを使用し、ログ設定を構成します。

11.5 1.1のアンインストールが失敗した場合の対応

バージョン6.0 SP1のインストール・プログラムによって、バージョン1.1システムの残存物が検出されると、インストールは失敗します。新しいインストールを開始する前に、1.1のすべてのコンポーネントが完全に削除されたことを確認する必要があります。

アンインストール・プログラムによってバージョン1.1のすべてのコンポーネントがアンインストールされない場合、Identity Synchronization for Windowsの製品レジストリおよびSolarisパッケージを手動でクリーンアップする必要があります。

Identity Synchronization for Windowsバージョン1.1を手動でアンインストールする詳細な手順は、次の項で説明しています。

- Solarisからの1.1コアおよびインスタンスの手動アンインストール

- Windows 2000からの1.1コアおよびインスタンスの手動アンインストール

- Windows NTからの1.1インスタンスの手動アンインストール

注意:

この項で説明するアンインストール手順は、Identity Synchronization for Windowsのバージョン1.1および1.1 SP1のみに該当します。

Identity Synchronization for Windowsのアンインストール・プログラムが失敗しないかぎり、以降の項で説明する手動アンインストールは行わないでください。

11.5.1 Solarisからの1.1コアおよびインスタンスの手動アンインストール

この項では、Solarisマシンからコアを手動でアンインストールする手順を示します。

注意:

この項では、Identity Synchronization for Windowsの場所は次のとおり示しています。

<serverRoot >/ isw-<hostname >

ここで、<serverRoot >は、Identity Synchronization for Windowsのインストールの場所の親ディレクトリを示します。

たとえば、Identity Synchronization for Windowsを/var/Sun/mps/isw-< example>にインストールした場合、< serverRoot>は/var/Sun/mpsになります。

11.5.1.1 Solarisマシンからのコアの手動アンインストール

1. 端末ウィンドウに/etc/init.d/isw stopを入力し、Identity Synchronization for WindowsのすべてのJavaプロセスを停止します。
前述のコマンドですべてのJavaプロセスが停止されない場合、次のコマンドを入力します。

/usr/ucb/ps -gauxwww | grep java
kill -s SIGTERM process IDs from preceding command

2. Message Queueを停止します。

1. 次のコマンドを入力し、Message Queueブローカを停止します。
/etc/init.d/imq stop

2. 次のコマンドを入力し、残りのimqプロセスがある場合、それを停止します。

* ps -ef | grep imqbroker
* kill -s SIGTERM process IDs from preceding command

3. 次のいずれかの方法を使用し、ブローカ・パッケージおよびディレクトリをアンインストールします。
Message Queueブローカのアンインストール・スクリプトを使用し、ブローカをアンインストールします。このスクリプトは、コアをインストールしたホストのIdentity Synchronization for Windowsインスタンスのディレクトリにあります。

serverRoot/isw-hostname/imq_uninstall

パッケージおよびディレクトリを手動でアンインストールします。

pkgrmコマンドを使用し、次のパッケージを削除します。

SUNWaclg
SUNWiqum
SUNWiqjx
SUNWiqlen
SUNWxsrt
SUNWiqu
SUNWjaf
SUNWiqfs
SUNWjhrt
SUNWiqdoc
SUNWiquc
SUNWiqsup
SUNWiqr
SUNWjmail

rm -rfコマンドを使用し、次のディレクトリを削除します。

/etc/imq
/var/imq
/usr/bin/imq*

3. Identity Synchronization for Windows 1.1 Solarisパッケージを削除するには、pkgrm package-nameを「Solarisからの1.1コアおよびインスタンスの手動アンインストール」に記載されている各パッケージに対して実行します。
次に、pkgrmを使用してパッケージをアンインストールする例を示します。

pkgrm SUNWidscm SUNWidscn SUNWidscr SUNWidsct SUNWidsoc

パッケージ名

説明

SUNWidscm

コア・コンポーネントおよびコネクタ用のSun ONE Directory Server Identity Synchronizationパッケージ。

SUNWidscn

コンソールのヘルプ・ファイル用のSun ONE Directory Server Identity Synchronizationパッケージ。

SUNWidscr

コア・コンポーネント用のSun ONE Directory Server Identity Synchronizationパッケージ。

SUNWidsct

コネクタ用のSun ONE Directory Server Identity Synchronizationパッケージ。

SUNWidsoc

オブジェクト・キャッシュ用のSun ONE Directory Server Identity Synchronizationパッケージ。

次のコマンドを入力すると、すべてのパッケージが削除されたことを確認できます。

pkginfo | grep -i "Identity Synchronization"

注意:

pkgrm package-nameコマンドを再実行すると、依存関係のために既存のパッケージがまだ存在するか確認できます。

4. Directory Serverプラグインを削除します。

1. Directory Serverコンソールを開き、「構成」タブを選択します。

2. 左ペインで、プラグイン・ノードを展開し、pswsyncノードを選択します。

3. 右ペインで、「プラグインの有効化」チェックボックスを選択解除します。

4. 「保存」をクリックします。

5. Directory Serverのコンソールの構成ディレクトリから、次のエントリを検索し、削除します。
cn=pswsync,cn=plugins,cn=config

6. Directory Serverを停止します。

7. 次のコマンドを入力し、プラグインのバイナリを削除します。
rm -f serverRoot/lib/psw-plugin.so

8. Directory Serverを再起動します。

5. /var/sadm/install/productregistryにある現在のproductregistryファイルをバックアップ(コピーして名前変更)します。

6. 存在する場合、次のエントリを削除するために/var/sadm/install/のproductregistryファイルを手動で編集します。

注意:

- 最良の結果を得るには、XMLエディタを使用します。または、標準のテキスト・エディタを使用します。

- ファイルには、次のコンポーネントのいくつかが含まれていない場合があります。

- 開始タグ、(<compid\>)、終了タグ(</compid\>)、および両タグ間のすべての内容を削除する必要があります。次のリストでは、これらのタグの一部として含まれる追加のテキストやタグは、省略記号で表されています。「Solarisからの1.1コアおよびインスタンスの手動アンインストール」の例を参照してください。

- <compid\>name="PN_IdSyncForWindows" content="Identity Synchronization for Windows" . . . </compid\>

- <compid\>Core . . . </compid\>

- <compid\>unistaller . . . </compid\>

- <compid\>wpsyncwatchdog . . . </compid\>

- <compid\>setenv . . . </compid\>

- <compid\>Create DIT . . . </compid\>

- <compid\>Extend Schema . . . </compid\>

- <compid\>resources . . . </compid\>

- <compid\>CoreComponents . . . </compid\>

- <compid\>Connector . . . </compid\>

- <compid\>DSConnector . . . </compid\>

- <compid\>Directory Server Plugin . . . </compid\>

- <compid\>DSSubcomponents . . . </compid\>

- <compid\>ObjectCache . . . </compid\>

- <compid\>ObjectCacheDLLs . . . </compid\>

- <compid\>SUNWidscr . . . </compid\>

- <compid\>SUNWidscm . . . </compid\>

- <compid\>SUNWidsct . . . </compid\>

- <compid\>SUNWidscn . . . </compid\>

- <compid\>SUNWidsoc . . . </compid\>

- <compid\>ADConnector . . . </compid\>

次に<compid\>タグの例を示します。<compid\>、</compid\>およびこの間のすべてのテキストとタグを削除します。

<compid\>Identity Synchronization for Windows
<compversion\>1.1
<uniquename\>Identity Synchronization for Windows</uniquename\>
<compinstance\>1
<children\>
<compref\>ADConnector
<instance\>1
<version\>1.1</version\>
</instance\>
</compref\>
<compref\>DSSubcomponents
. . .

</compinstance\>
</compversion\>
</compid\>

7. 次のIdentity Synchronization for Windowsディレクトリおよびファイルを削除します。

1. インストール先から、次のコマンドを入力します。

rm -rf serverRoot/isw-hostname

2. 次のコマンドを入力し、ブートストラップ・ファイルを削除します。

rm -rf /etc/init.d/isw

8. 次の方法で構成ディレクトリをクリーンアップします。

1. 次のldapsearchコマンドをIdentity Synchronization for Windowsコアがインストールされている構成ディレクトリで実行し、Identity Synchronization for Windowsコンソールのサブツリーを探します。
ldapsearch -D "cn=directory manager" -w < password > -b o=netscaperoot "(nsnickname=isw)" dn

注意:

ldapsearchはDirectory Serverの< serverRoot>/shared/bin/ldapsearchにあります。たとえば、/var/Sun/mps/shared/bin/ldapsearchです。

この結果のエントリは、次のとおりなります。エントリは常にo=NetscapeRootで終了することに注意してください。

"cn=Sun ONE name="PN_IdSyncForWindows" content="Identity Synchronization for Windows",cn=server group, cn=myhost.mydomain.com,ou=mydomain.com,o=NetscapeRoot"

2. Directory Serverコンソールを使用し、Identity Synchronization for Windows Consoleサブツリーおよびそれ以下のすべてのサブツリーを削除します。

9. 次の方法でIdentity Synchronization for Windowsの構成レジストリをクリーンアップします。

1. 次のldapsearchコマンドを実行し、Directory Server内のIdentity Synchronization for Windowsの構成レジストリを探します。
ldapsearch -D "cn=directory manager" -w < password > -b "dc=my,dc=domain" "(&(objectclass=iplanetservice)(ou=IdentitySynchronization))" dn

この結果のエントリは、次のとおりなります。

"ou=IdentitySynchronization,ou=Services,dc=my,dc=domain"

2. Directory Serverコンソールを使用し、Identity Synchronization for Windows Consoleの構成レジストリおよびそれ以下のすべてのサブツリーを削除します。

10. コンソールと関係するその他のすべてのファイルを次の方法でクリーンアップします。

1. 次を入力し、コンソールのすべてのjarファイルを削除します。
rm -rf < serverRoot >/java/jars/isw* 例: /var/Sun/mps/java/jars/isw*

2. 次を入力し、コンソール・サーブレットのjarファイルをすべて削除します。
rm -rf <serverRoot >/bin/isw/ 例: /var/Sun/mps/bin/isw/

11.5.2 Windows 2000からの1.1コアおよびインスタンスの手動アンインストール

この項では、Windows 2000マシンからコアを手動でアンインストールする手順を説明します。

注意:

この項では、Identity Synchronization for Windowsの場所は次のとおり示しています。

serverRoot\isw-hostname\

ここで、serverRootは、Identity Synchronization for Windowsのインストール場所の親ディレクトリを示します。

たとえば、Identity Synchronization for WindowsをC:\Program Files\Sun\mps\isw-exampleにインストールした場合、serverRootはC:\Program Files\Sun\mpsになります。

11.5.2.1 Windows 2000マシンからのコアのアンインストール

1. 次のいずれかの方法を使用し、Identity Synchronization for Windows Javaのプロセスをすべて停止します。

1. 「スタート」→「設定」→「コントロール パネル」→「管理ツール」→「サービス」を選択し、「サービス」ウィンドウを開きます。右ペインの「Identity Synchronization for Windows」を右クリックし、「停止」を選択します。

2. コマンド・プロンプトのウィンドウを開き、次のコマンドを入力します。

net stop "Sun ONE Identity Synchronization for Windows"

3. 前述の方法で効果がない場合は、次の手順を使用しJavaプロセスを手動で停止します。

1. 「サービス」ウィンドウを開き、「Identity Synchronization for Windows」を右クリックし、「プロパティ」を選択します。

2. 「プロパティ」ウィンドウの「全般」タブで、「スタートアップの種類」として「手動」を選択します。

注意:

Windowsのタスク・マネージャに(pswwatchdog.exeなどの)Javaプロセスは表示されますが、どのプロセスがIdentity Synchronization for Windowsと具体的に関係しているかは判断できません。このため、Windowsタスク・マネージャからはプロセスは停止しないでください。

2. コアをアンインストールする場合のみ、次のいずれかの方法を使用し、Message Queueを停止します。

1. 「サービス」ウィンドウの右ペインで「iMQ Broker」を右クリックし、「停止」を選択します。

2. コマンド・プロンプトに次のコマンドを入力します。

net stop "iMQ Broker"

3. 前述の方法で効果がない場合は、次の手順を使用しMessage Queueを手動で停止します。

1. 「サービス」ウィンドウを開き、「iMQ Broker」を右クリックし、「プロパティ」を選択します。

2. 「プロパティ」ウィンドウの「全般」タブで、「スタートアップの種類」として「手動」を選択します。

3. Directory Serverコンソールを開き、「構成」タブを選択します。

4. 左ペインで、プラグイン・ノードを展開し、pswsyncノードを選択します。

5. 右ペインで、「プラグインの有効化」チェックボックスを選択解除します。

6. 「保存」をクリックします。

7. コンソールの構成ディレクトリから、次のエントリを探し削除します。
cn=pswsync,cn=plugins,cn=config

8. Directory Serverを停止します。
サーバーは、次のいずれかの方法を使用して停止できます。

「サービス」ウィンドウの右ペインで「Sun ONE Directory Server 5.2」を右クリックし、「停止」を選択するか、

コマンド・プロンプトのウィンドウを開き、次のコマンドを入力します。

net stop slapd-myhostname

9. Windowsエクスプローラを開き、プラグイン・バイナリを探して削除します。
< ServerRoot>\lib\psw-plugin.so

10. Directory Serverを再起動します。

3. コマンド・プロンプトのウィンドウにregeditと入力し、レジストリ・エディター・ウィンドウを開きます。

注意:

「Windows 2000からの1.1コアおよびインスタンスの手動アンインストール」に進む前に、現在のレジストリ・ファイルをバックアップしてください。

1. レジストリ・エディタの右ペインで「コンピューター」を選択します。

2. メニュー・バーから「レジストリ」→「レジストリ ファイルのエクスポート」を選択します。

3. 「レジストリ ファイルのエクスポート」ダイアログボックスが表示されたら、ファイル名を指定し、バックアップ・レジストリを保存する場所を選択します。

4. レジストリ・エディタのメニュー・バーから「編集」→「削除」を選択します。
Windowsのレジストリから次のIdentity Synchronization for Windowsのキーを削除します。

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\name="PN_IdSyncForWindows" content="Identity Synchronization for Windows"の下のすべてのエントリ。

存在する場合は、次のなどのHKEY_LOCAL_MACHINE\SYSTEM\*の下のすべてのCurrentControlSetおよびControlSet(たとえば、ControlSet001、ControlSet002など)のエントリ。

- ...\Control\Session Manager\Environment\< isw-installation directory\>

- ...\Services\Eventlog\Application\Sun ONE name="PN_IdSyncForWindows" content="Identity Synchronization for Windows"

- ...\Services\Sun ONE name="PN_IdSyncForWindows" content="Identity Synchronization for Windows"

- ...\Services\iMQBroker

5. C:\WINNT\system32にある現在のproductregistryファイルをバックアップ(コピーして名前変更)します。

6. C:\WINNT\system32\productregistryファイルを編集し、次のタグを削除します。

注意:

- 最良の結果を得るには、XMLエディタを使用します。または、標準のテキスト・エディタを使用します。

- ファイルには、次のコンポーネントのいくつかが含まれていない場合があります。

- 開始タグ、(<compid\>)、終了タグ(</compid\>)、および両タグ間のすべての内容を削除する必要があります。次のリストでは、これらのタグの一部として含まれる追加テキストやタグは、省略記号で表されています。「Windows 2000からの1.1コアおよびインスタンスの手動アンインストール」の例を参照してください。

- <compid\>name="PN_IdSyncForWindows" content="Identity Synchronization for Windows" . . . </compid\>

- <compid\>Core . . . </compid\>

- <compid\>unistaller . . . </compid\>

- <compid\>wpsyncwatchdog . . . </compid\>

- <compid\>setenv . . . </compid\>

- <compid\>Create DIT . . . </compid\>

- <compid\>Extend Schema . . . </compid\>

- <compid\>resources . . . </compid\>

- <compid\>CoreComponents . . . </compid\>

- <compid\>Connector . . . </compid\>

- <compid\>DSConnector . . . </compid\>

- <compid\>Directory Server Plugin . . . </compid\>

- <compid\>DSSubcomponents . . . </compid\>

- <compid\>ObjectCache . . . </compid\>

- <compid\>ObjectCacheDLLs . . . </compid\>

- <compid\>ADConnector . . . </compid\>

次に<compid\>タグの例を示します。<compid\>、</compid\>およびこの間のすべてのテキストとタグを削除します。

<compid\>Identity Synchronization for Windows
<compversion\>1.1
<uniquename\>Identity Synchronization for Windows</uniquename\>
<compinstance\>1
<children\>
<compref\>ADConnector
<instance\>1
<version\>1.1</version\>
</instance\>
</compref\>
<compref\>DSSubcomponents
. . .
</compinstance\>
</compversion\>
</compid\>

7. serverRoot\isw-hostnameにあるIdentity Synchronization for Windowsのインストール・フォルダを削除します。
例: C:\Program Files\Sun\mps\isw-example

8. 次の方法で構成ディレクトリをクリーンアップします。

1. コマンド・プロンプトのウィンドウからldapsearchコマンドをIdentity Synchronization for Windowsコアがインストールされている構成ディレクトリに実行し、Identity Synchronization for Windowsコンソールのサブツリーを探します。

注意:

ldapsearch is located in < serverRoot>\shared\bin\ldapsearch.

例: C:\Program Files\Sun\mps\shared\bin\ldapsearch

ldapsearch -D "cn=directory manager" -w < password\> -b o=netscaperoot "(nsnickname=isw)" dn

この結果のエントリは、次のとおりになります(エントリは常にo=NetscapeRootで終わることに注意してください)。

"cn=Sun ONE name="PN_IdSyncForWindows" content="Identity Synchronization for Windows",cn=server group, cn=myhost.mydomain.com,ou=mydomain.com,o=NetscapeRoot"

2. Directory Serverコンソールを使用し、検索したIdentity Synchronization for Windows Consoleのサブツリーとそれ以下のすべてのサブツリーを削除します。

9. (構成レジストリとも呼ばれる)Identity Synchronization for Windowsの構成ディレクトリを次のとおりクリーンアップします。

1. コマンド・プロンプトのウィンドウから次のldapsearchコマンドを実行し、Directory Server内のIdentity Synchronization for Windowsの構成ディレクトリを探します。
ldapsearch -D "cn=directory manager" -w <password \> -b "dc=my,dc=domain" "(&(objectclass=iplanetservice)(ou=IdentitySynchronization))" dn

この結果のエントリは、次のとおりなります。

"ou=IdentitySynchronization,ou=Services,dc=my,dc=domain"

2. Directory Serverコンソールを使用し、検索した構成ディレクトリ・サブツリー(それ以下のサブツリーを含む)を削除します。

10. 次の方法で、その他のすべてのコンソール関連のファイルをクリーンアップします。

1. < serverRoot >\java\jars\isw*にあるC:\Program Files\Sun\mps\java\jars\isw*などのすべてのコンソールjarファイルを削除します。

2. < directory-server-install-root >\bin\isw\にあるC:\SunOne\Servers\bin\isw\などのすべてのコンソール・サーブレットjarファイルを削除します。

次の手順

マシンを再起動し、すべての変更を反映します。

11.5.3 Windows NTからの1.1インスタンスの手動アンインストール

この項では、Windows NTマシンからインスタンスを手動でアンインストールする手順を説明します。

注意:

この項では、Identity Synchronization for Windowsの場所は次のように示します。

<serverRoot>\isw-<hostname>

ここで、<serverRoot >は、Identity Synchronization for Windowsのインストールの場所の親ディレクトリを示します。たとえば、Identity Synchronization for WindowsをC:\Program Files\Sun\mps\isw- exampleにインストールした場合、< serverRoot >はC:\Program Files\Sun\mpsになります。

1. 次のいずれかの方法を使用し、Identity Synchronization for Windows Javaのプロセス(コアおよびインスタンス・インストール)をすべて停止します。

1. 「スタート」→「設定」→「コントロール パネル」→「管理ツール」→「サービス」を選択し、「サービス」ウィンドウを開きます。右ペインの「Identity Synchronization for Windows」を右クリックし、「停止」を選択します。

2. コマンド・プロンプトのウィンドウを開き、次のコマンドを入力します。
net stop "Sun ONE name="PN_IdSyncForWindows" content="Identity Synchronization for Windows""

3. 前述の方法で効果がない場合は、次の手順を使用しJavaプロセスを手動で停止します。

1. 「サービス」ウィンドウを開き、「Identity Synchronization for Windows」を右クリックし、「プロパティ」を選択します。

2. 「プロパティ」ウィンドウの「全般」タブで、「スタートアップの種類」として「手動」を選択します。

注意:

Windowsのタスク・マネージャに(pswwatchdog.exeなどの)Javaプロセスは表示されますが、どのプロセスがIdentity Synchronization for Windowsと具体的に関係しているかはユーザーには判断できません。このため、Windowsタスク・マネージャからはプロセスは停止しないでください。

2. 次のいずれかの方法を使用し、Change Detectorサービスを停止します。

1. 「サービス」ウィンドウの右ペインで「Sun ONE NT Change Detector Service」を右クリックし、「停止」を選択するか、

2. コマンド・プロンプトのウィンドウを開き、次のコマンドを入力します。
net stop "Sun ONE NT Change Detector Service"

3. 前述の方法で効果がない場合は、次の手順を使用しChange Detectorサービスを手動で停止します。

1. 「サービス」ウィンドウを開き、「Change Detector Service」を右クリックし、「プロパティ」を選択します。

2. 「プロパティ」ウィンドウの「全般」タブで、「スタートアップの種類」として「手動」を選択します。

3. Windows NTコンピュータを再起動します。

3. Identity Synchronization for Windowsのレジストリ・キーを削除する必要があります。コマンド・プロンプトのウィンドウを開き、regedt32と入力して、レジストリ・エディタ・ウィンドウを開きます。

注意:

regeditでは、複数の値を含む文字列の編集は許可されていないので、このプログラムは使用しないでください。

「Windows NTからの1.1インスタンスの手動アンインストール」に進む前に現在のWindowsレジストリ・ファイルを開きます。

1. レジストリ・エディタの左ペインの最上位のノード(「コンピューター」)を選択します。

2. メニュー・バーから「レジストリ」→「レジストリ ファイルのエクスポート」を選択します。

3. 「レジストリ ファイルのエクスポート」ダイアログボックスが表示されたら、ファイル名を指定し、バックアップ・レジストリを保存する場所を選択します。

4. レジストリ・エディタのメニュー・バーから「編集」→「削除」を選択します。
レジストリから次のIdentity Synchronization for Windowsのキーを削除します。

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\name="PN_IdSyncForWindows" content="Identity Synchronization for Windows"の下のすべてのエントリ。

HKEY_LOCAL_MACHINE\SYSTEM\*の下のすべてのCurrentControlSetおよびControlSet(たとえば、ControlSet001、ControlSet002)のエントリ。

これらのエントリには、次が含まれます。

- ...\Control\Session Manager\Environment\ <isw-installation directory>

- ...\Services\Eventlog\Application\Sun ONE name="PN_IdSyncForWindows" content="Identity Synchronization for Windows"

- ...\Services\Sun ONE name="PN_IdSyncForWindows" content="Identity Synchronization for Windows"

- ...\Services\iMQBroker

The HKEY_LOCAL_MACHINE\SOFTWARE\Sun Microsystems\PSW

5. (regeditは使用せず)regedt32を使用し、次のレジストリ・キーを変更します(削除はしません)。

1. 左ペインのレジストリ・キーのエントリを選択します。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\CONTROL\LSA

レジストリ値の種類は、REG_MULTI_SZである必要があります。

2. 右ペインで「Notification Packages」値を選択し、「修正」を選択します。

3. PASSFLT値をFPNWCLNTに変更します。

6. C:\WINNT\system32にある現在のproductregistryファイルをバックアップ(コピーして名前変更)します。

7. C:\WINNT\system32 productregistryファイルを編集し、次のタグを削除します。

注意:

- 最良の結果を得るには、XMLエディタを使用します。または、標準のテキスト・エディタを使用します。

- これらのコンポーネントの一部はファイルにない場合があります。

- 開始タグ、(<compid\>)、終了タグ(</compid\>)、および両タグ間のすべての内容を削除する必要があります。次のリストでは、これらのタグの一部として含まれる追加テキストやタグは、省略記号で表されています。「Windows 2000からの1.1コアおよびインスタンスの手動アンインストール」の例を参照してください。

- <compid\>name="PN_IdSyncForWindows" content="Identity Synchronization for Windows" . . . </compid\>

- <compid\>Core . . . </compid\>

- <compid\>uninstaller . . . </compid\>

- <compid\>wpsyncwatchdog . . . </compid\>

- <compid\>setenv . . . </compid\>

- <compid\>Create DIT . . . </compid\>

- <compid\>Extend Schema . . . </compid\>

- <compid\>resources . . . </compid\>

- <compid\>CoreComponents . . . </compid\>

- <compid\>Connector . . . </compid\>

- <compid\>DSConnector . . . </compid\>

- <compid\>Directory Server Plugin . . . </compid\>

- <compid\>DSSubcomponents . . . </compid\>

- <compid\>ObjectCache . . . </compid\>

- <compid\>ObjectCacheDLLs . . . </compid\>

- <compid\>ADConnector . . . </compid\>

次に<compid\>タグの例を示します。<compid\>、</compid\>およびこの間のすべてのテキストとタグを削除します。

<compid\>Identity Synchronization for Windows
<compversion\>1.1
<uniquename\>Identity Synchronization for Windows</uniquename\>
<compinstance\>1
<children\>
<compref\>ADConnector
<instance\>1
<version\>1.1</version\>
</instance\>
</compref\>
<compref\>DSSubcomponents
. . .

</compinstance\>
</compversion\>
</compid\>

8. < serverRoot >\isw-< hostname >にあるIdentity Synchronization for Windowsのインストール・フォルダを削除します。
例: C:\Program Files\Sun\mps\isw-example

注意:

「Windows NTからの1.1インスタンスの手動アンインストール」に進む前に「Windows NTからの1.1インスタンスの手動アンインストール」の説明に従って、Windowsレジストリを編集する必要があります。

9. Password Filter DLLを削除します。
C:\winnt\system32フォルダのpassflt.dllファイルを探し、ファイル名をpassflt.dll.oldに変更します。

10. マシンを再起動し、すべての変更を反映します。

11.6 その他の移行シナリオ

デプロイメントによっては別のトポロジが使用されている可能性があるため、移行プロセスは単一ホストのデプロイメントで説明した手順と異なる場合があります。

この項では、別の2つのデプロイメント・シナリオを説明し、各ケースでどのように移行を実行するか説明します。

例のデプロイメント・シナリオは次のとおりです。

- マルチマスター・レプリケーション・デプロイメント

- Windows NTを使用したマルチホスト・デプロイメント

11.6.1 マルチマスター・レプリケーション・デプロイメント

マルチマスター・レプリケーション(MMR)デプロイメントでは、2つのDirectory Serverインスタンスは別のホストにインストールされます。ホストは別のオペレーティング・システムでも実行できますが、このシナリオでは、両ホストは同じオペレーティング・システムで実行されています。

表11-1および図11-2に、2つのホストにIdentity Synchronization for Windowsのコンポーネントがどのように分散されているかを示します。

表11-1 マルチマスター・レプリケーション・デプロイメントでのコンポーネントの分布

ホスト1

ホスト2

同期対象ユーザーの二次マスターとしてのDirectory Server(1インスタンス)

同期対象ユーザーの優先マスターとしてのDirectory Server(1インスタンス)

コア(Message Queue、Central Logger、システム・マネージャ、コンソール)

Directory Serverプラグイン

Active Directoryコネクタ

Directory Serverコネクタ

Directory Serverプラグイン

移行プロセスでは、優先マスターまたは二次マスターで継続して実行されるオンデマンド・パスワード同期が維持されます。

注意:

両ホストがSolarisオペレーティング・システムで実行される場合、Active DirectoryがあるWindows 2000を実行する3番目のホストが同期専用に必要となります。(3番目のホストには、コンポーネントはインストールされません。)

次の図に、MMRデプロイメントでIdentity Synchronization for Windowsを移行する手順を示します。

図11-2 マルチマスター・レプリケーション・デプロイメントでの移行

「図11-2 マルチマスター・レプリケーション・デプロイメントでの移行」の説明

11.6.2 Windows NTでのマルチホスト・デプロイメント

このデプロイメント・シナリオでは、3つのホストが使用されています。

- Windows NTシステム

- 同期対象ユーザーを格納するDirectory Server とDirectory Serverコネクタ用のホスト

- その他のすべてのコンポーネント用のホスト

表11-2および図11-3に、3つのホストにIdentity Synchronization for Windowsのコンポーネントがどのように分散されているかを示します。

表11-2 マルチホスト・デプロイメント

ホスト1

ホスト2

ホスト3

構成リポジトリがあるDirectory Server

同期対象ユーザー用のDirectory Server

Windows NTコネクタ

コア(Message Queue、Central Logger、システム・マネージャ、コンソール)

Directory Serverコネクタ

Windows NTのサブコンポーネント(Password Filter DLLおよびChange Detectorサービス)

Active Directoryコネクタ

Directory Serverプラグイン

前述のシナリオでは、ホスト1および2は同じオペレーティング・システム上で実行されています。

注意:

ホスト1のDirectory Serverには、構成レジストリおよびAdmin Serverコンソールが含まれます。Admin Serverの状態を変更せずに維持するには、-Nオプションを使用しDirectory Server 11gリリース1 (11.1.1.7.0)に移行するようにしてください。構成データおよびユーザー・データの移行の詳細は、「構成データの移行のためのdsmigの使用」および「ユーザー・データを移行するためのdsmigの使用」をそれぞれ参照してください。

ホスト2のDirectory Serverには、データおよびDirectory Serverプラグインが含まれます。Directory Serverを11gリリース1 (11.1.1.7.0)に移行すると、プラグイン構成は失われます。ただし、Identity Synchronization for Windowsを移行する際には、コネクタを再インストールしプラグインを再構成する必要があるので、問題は発生しません。したがって、ホスト2のDirectory ServerはIdentity Synchronization for Windowsのアンインストール後に移行する必要があります。

両ホストがSolarisオペレーティング・システムで実行される場合、Active DirectoryがあるWindows 2000を実行する4番目のホストが同期専用に必要になります。(4番目のホストには、コンポーネントはインストールされません。)

図11-3に、マルチホスト・デプロイメントでIdentity Synchronization for Windowsを移行する手順を示します。

図11-3 Windows NTでのマルチホスト・デプロイメントの移行

「図11-3 Windows NTでのマルチホストのデプロイメントの移行」の説明

11.7 ログの確認

移行後、中央の監査ログに問題が記述されているか確認します。特に、移行プロセス中にパスワードの変更に失敗したDirectory Serverユーザーについて確認します。この場合、次のようなエラーが表示されます。

[16/Apr/2004:14:23:41.029 -0500] WARNING
14  CNN101 ds-connector-host.example.com
"Unable to obtain password of user cn=JohnSmith,ou=people,dc=example,dc=com,
because the password was encoded by a previous installation of
Identity Synchronization for Windows Directory Server Plugin.
The password of this user cannot be synchronized at this time.
Update the password of    this user again in the Directory Server."

このようなログ・メッセージは、Identity Synchronization for Windows 6.0 SP1で同期を開始するまで表示されません。このため、移行プロセスの最後の手順は、ログの確認となります。

索引

A  B  C  D  E  F  H  I  J  L  M  P  R  S  U  V  X

A

Active Directory

移行時, 11.4

ホスト, 11.6.1, 11.6.2

MMRデプロイメント, 11.6.1

マルチホスト・デプロイメント, 11.6.2

オンデマンド・パスワード同期, 11.2

移行時のパスワード同期, 11.2

パスワードの同期, 11.2

追加

XMLファイルにエクスポートされたパスワード, 11.4.1.1

引数

checktopics, 11.3.2.1

importcnf, 11.4.4.1

B

バイナリ・ファイル

削除, 11.5.1.1

解凍, 11.4.1.1

C

中央ログ・ディレクトリ, はじめに

証明書データベース

デフォルトのパス, はじめに

Change Detectorのサブコンポーネント, 11.4.4.1, 11.4.4.1, 11.5.3, 11.6.2 checktopicsユーティリティ

checktopics.jar, 11.4.1.1

メッセージのクリア, 11.3.2.1

デフォルトの場所, 11.3.2.1

説明, 11.3.2

前提条件, 11.3.2.1

構文, 11.3.2.1

使用, 11.3.2.1

checktopics.jar, 11.4.1.1, 11.4.1.1 クリアテキスト・パスワード

挿入, 11.3.1.2

構成

エクスポート, 11.3.1

構成

Identity Synchronization for Windows, 11.3

コネクタ

アンインストール, 11.4.2.1

コンソール

ヘルプ・ファイル, 11.5.1.1

MMR構成, 11.6.1

マルチホスト・デプロイメント, 11.6.2

jarファイルの削除, 11.5.1.1, 11.5.2.1

コア

アンインストール, 11.4.2.1, 11.5.1, 11.5.2

作成

XML構成ドキュメント, 11.3, 11.3

D

デフォルトの場所, はじめに

デプロイメント

トポロジのXMLドキュメントへのエクスポート, 11.3

MMR, 11.6.1, 11.6.1

マルチホスト, 11.6.2, 11.6.2

デプロイメント, 単一ホスト, 11.4 検出

エラー, 11.4.4.1

ディレクトリ

etc, 11.4.4.1

isw-hostname, 11.4.2.1, 11.5.1, 11.5.2

移行, 11.3, 11.3.1, 11.3.2.1, 11.3.3

persist, 11.4.4.1

Directory Server

コマンドラインに対する変更, 9.3

再起動, 11.4.2.1

アップグレード, 11.4.3

Directory Serverプラグイン

削除, 11.5.1.1

パスワードの変更の同期, 11.2

アンインストール, 11.4.2.1

E

編集

製品レジストリ・ファイル, 11.5.2.1

エラー

検出, 11.4.4.1

XML構成ファイル, 11.4.4.1

etcディレクトリ

バックアップ, 11.3.1, 11.4.1.1

削除, 11.4.4.1

リストア, 11.4.4.1

例

checktopicsコマンド, 11.3.2.1

export11cnfコマンド, 11.3.1.1

idsync importcnf, 11.3.1.2

export11cnfユーティリティ, 11.3.1

説明, 11.3

export11cnf.jar, 11.4.1.1

クリアテキスト・パスワードの挿入, 11.3.1.2

export11cnf.jar, 11.3.1.1, 11.3.1.1, 11.4.1.1 エクスポート

1.1 (または1.1 SP1)の構成, 11.3.1, 11.3.1.1

バージョン1.1, および1.1 SP1, 構成ファイル, 11.3.1

F

障害

アンインストール, 11.5

forcepwchgユーティリティ

説明, 11.3

パスワード変更の強制, 11.3.3

場所, 11.3.3

移行の準備, 11.4.1.1

パスワード変更の要求, 11.3.3

パスワード変更の強制, 11.3.3

H

ヘルプ

ヘルプ・ファイルの削除, 11.5.1.1

ホスト

Active Directory, 11.6.1, 11.6.2

デプロイメント・シナリオ, 11.6.2

I

Identity Synchronization for Windows

構成, 11.3

idsync importcnf

例, 11.3.1.2

構成ファイルのインポート, 11.3.1, 11.4.4.1

importcnfサブコマンド

例, 11.3.1.2

構成ファイルのインポート, 11.3.1, 11.4.4.1

install-path, はじめに instance-path, はじめに インスタンス, 1.1 (または1.1 SP1)のアンインストール, 11.5.3 isw- hostnameディレクトリ, はじめに isw-hostnameディレクトリ, 11.4.2.1, 11.5.1, 11.5.2

J

jarファイル

checktopics, 11.4.1.1, 11.4.1.1

export11cnf, 11.4.1.1

exportcnf, 11.3.1.1, 11.3.1.1

jss3.jar, 11.4.2

移行ツール, 11.4.1.1

Java Naming and Directory Interface, はじめに Javaプロセス

停止, 11.5.2.1

jss3.jarファイル, 削除, 11.4.2

L

LDAP

ldapsearch, 11.5.1.1

ldapsearch, 使用, 11.5.1.1, 11.5.1.1 ローカル・ログ・ディレクトリ, Preface

M

Message Queue, はじめに, 11.5.2.1

アップグレード, 11.4.3

移行

未配信のメッセージの確認, 11.3.2

メッセージのクリア, 11.3.2.2

ディレクトリ, 11.3, 11.3.1, 11.3.2.1, 11.3.3

1.1 (または1.1 SP1)構成のエクスポート, 11.3.1

パスワード変更の強制, 11.3.3

バージョン1.1から1 2004Q3へ, 11

準備, 11.4.1

シナリオ, 11.6, 11.6.1

checktopicsの使用, 11.3.2.1

MMR

デプロイメント, 11.6.1

移行シナリオ, 11.6.1

マルチホスト・デプロイメント, 11.6.2, 11.6.2

P

パッケージ

削除, 11.5.1.1

SUNWidscm, 11.5.1.1

SUNWidscn, 11.5.1.1

SUNWidscr, 11.5.1.1

SUNWidsct, 11.5.1.1

SUNWidsoc, 11.5.1.1

SUNWjss, 11.4.2

パスワード・フィルタ・サブコンポーネント, 11.6.2 パスワードの同期, オンデマンド, 11.2 パスワード

クリアテキスト, 挿入, 11.3.1.2

変更の強制, 11.3.3

Directory Serverプラグインとの変更の同期, 11.2

PDC

forcepwchgユーティリティの実行, 11.3.3

persistディレクトリ

バックアップ, 11.3.1, 11.4.1.1

リストア, 11.4.4.1

準備

移行, 11.4.1

前提条件

checktopicsユーティリティ, 11.3.2.1

プロセス

停止, 11.5.2.1

R

regedt32.exe, 11.4.1.1, 11.4.4.1, 11.5.3, 11.5.3

レジストリ

編集, 11.5.2.1

削除

バイナリ・ファイル, 11.5.1.1

コンソールjarファイル, 11.5.1.1, 11.5.2.1

Directory Serverプラグイン, 11.5.1.1

ヘルプ・ファイル, 11.5.1.1

パッケージ, 11.5.1.1

Solarisパッケージ, 11.5.1.1

再開

Directory Server, 11.4.2.1

同期, 11.3.2.2

リストア

ディレクトリ, 11.4.4.1

S

スキーマ

更新, 11.4.4.1

serverrootディレクトリ, はじめに 単一ホスト

デプロイメント, 11.4

SLAMD分散負荷生成エンジン, はじめに Solaris

パッケージの削除, 11.5.1.1

停止

Javaプロセス, 11.5.2.1

Message Queue, 11.5.2.1

サブコマンド

importcnf, 11.3.1, 11.3.1.2, 11.4.4.1

SUNWidscmパッケージ, 11.5.1.1 SUNWidscnパッケージ, 11.5.1.1 SUNWidscrパッケージ, 11.5.1.1 SUNWidsctパッケージ, 11.5.1.1 SUNWidsocパッケージ, 11.5.1.1 SUNWjssパッケージ, 削除, 11.4.2 同期

再起動, 11.3.2.2

同期化

Directory Serverプラグインの変更, 11.2

構文

checktopicsコマンド, 11.3.2.1

checktopicsユーティリティ, 11.3.2.1

export11cnfコマンド, 11.3.1.1

システム

休止の確認, 11.3.2.1

U

アンインストールの失敗, 11.5

アンインストール

1.1 (または1.1 SP1)インスタンス, 11.5.3

コネクタ, 11.4.2.1

コア, 11.4.2.1, 11.5.1, 11.5.2

Directory Serverプラグイン, 11.4.2.1

UNIXコマンド

バイナリの削除, 11.4.2.1

Directory Serverの再起動, 11.4.2.1

プログラムのアンインストール, 11.4.2.1

製品バイナリ・ファイルの解凍, 11.4.1.1 更新

スキーマ, 11.4.4.1

使用

checktopicsユーティリティ, 11.3.2.1

ユーティリティ

checktopics, 11.3, 11.3.2

export11cnf, 11.3, 11.3.1

forcepwchg, 11.3

checktopicsの使用, 11.3.2.1

V

確認

空の同期トピック, 11.3.2.1

システムの休止, 11.3.2.1

X

XML構成ドキュメント

作成, 11.3, 11.3

エラー, 11.4.4.1

export11cnf, 11.3, 11.3.1, 11.3.1.1

構成のエクスポート, 11.3.1, 11.3.1.1

Copyright © 2001, 2013, Oracle and/or its affiliates. All rights reserved.