|
OpenLDAP
OpenLDAPは、Lightweight Directory Access Protocol (LDAP) のフリーかつオープンソースの実装であり、OpenLDAP Project が開発している。独自のBSD系ライセンスである OpenLDAP Public License でリリースされている[2]。 プロジェクトの歴史と中核チームOpenLDAP Project[3] は1998年、Kurt Zeilenga[4] が創始した。LDAPプロトコルの開発と改良を長期プロジェクトとして行ってきたミシガン大学のLDAPリファレンス実装のクローンを出発点としてプロジェクトが始まった。 2015年5月時点で、OpenLDAP Project の中核チームは Howard Chu（チーフアーキテクト）[5]、Quanah Gibson-Mount、Hallvard Furuseth、Kurt Zeilenga の4人で構成されている。他にも活発に活動している重要なコントリビュータとして、Luke Howard、Ryan Tandy、Gavin Henry らがいる。過去の中核チームメンバーには、Pierangelo Masarati[6] らがいた。 コンポーネントOpenLDAPは次の3つのコンポーネントから成る。
さらに OpenLDAP Project ではいくつかのサブプロジェクトも運営している。
バックエンド概要OpenLDAPサーバ (slapd) は歴史的経緯から、ネットワーク処理とプロトコル処理を受け持つフロントエンドと、データストレージを扱うバックエンドに分かれている。この設計は、1996年に書かれたオリジナルのミシガン大学のコードの特徴であり、その後のすべてのOpenLDAPリリースで引き継がれている。 モジュラー構造になっており、バックエンドとしては通常のデータベースだけでなく様々なテクノロジーとのインタフェースを提供する多様なものが存在する。 なお、古いリリース (1.x) では、「バックエンド」と「データベース」はほぼ同義に使われていた。正確には、「バックエンド」はストレージインタフェースのクラスであり、「データベース」はバックエンドのインスタンスの1つである。slapdサーバは同時に複数のバックエンドを使うことができ、同種のバックエンドの複数のインスタンス（例えば多数のデータベース）を同時に扱うこともできる。 利用可能なバックエンドOpenLDAPディストリビューションには17種類のバックエンドが含まれており、他にもサードパーティーが独自のバックエンドを開発している。標準バックエンドは大まかに以下の3種類に分類できる。
古いバージョンのOpenLDAPには今は使われていないバックエンドもあった。例えば、back-ldbm は元になったミシガン大学のコードを受け継いだバックエンドである。また、back-tcl は back-perl や back-shell と同様にTclスクリプトを呼び出すバックエンドである。 他のバックエンドのサポートも間もなく廃止される予定。 back-ndb は、廃止された。Oracle が MySQL を買収した後、Oracle によって MySQL とのパートナーシップが解消されたためである。 back-bdb と back-hdb は、間も無く廃止される。back-mdb の方がパフォーマンス、信頼性、および管理性の面で優れているためである。 実際、back-perl、back-shell、back-sock といったバックエンドは任意のプログラミング言語へのインタフェースとすることが可能で、拡張やカスタマイズが自由に行える。これを利用して、コンパクトでうまく定義されたAPIを持つRPCエンジンとしてslapdを使うことも可能である。 オーバーレイ概要通常、LDAP要求はフロントエンドが受信し、解読し、バックエンドに処理させる。バックエンドが要求の処理を完了すると、フロントエンドに結果を返し、そこからLDAPクライアントに結果を送信する。オーバーレイはフロントエンドとバックエンドの間に挿入できるコードの断片である。したがって、そこで要求をインターセプトしてバックエンドが処理する前に別の動作を起動したり、バックエンドが返す結果をインターセプトすることもできる。オーバーレイは slapd の内部APIに完全にアクセスできるため、フロントエンドやバックエンドの関数も呼び出すことが可能である。一度に複数のオーバーレイを使うこともでき、フロントエンドとバックエンドの間にモジュールのスタックを形成できる。 オーバーレイは、データベース機能の強化に対応する単純な手段として使うことができ、新たなバックエンドを作成する必要がない。新機能をコンパクトで保守が容易なモジュール形式で追加できる。OpenLDAP 2.2 でオーバーレイが導入されて以来、多数のオーバーレイがコミュニティから集まっている。 利用可能なオーバーレイOpenLDAPディストリビューションでは21個の中核オーバーレイが提供されている。さらに15個のユーザーコントリビューションのオーバーレイがある。他にも承認待ちのものもある。
その他のモジュールバックエンドとオーバーレイは、最も一般的に使用される2つのモジュールタイプである。バックエンドは通常 slapd バイナリに組み込まれていたが、動的にロードモジュールとして組み込み可能。オーバーレイは、通常動的モジュールとして組み込まれる。さらに、slapd は、動的モジュールをサポートしている。新しいLDAPの構文、マッチングルール、制御、そして拡張操作を実装だけでなく、カスタムアクセス制御機能やパスワードハッシュ機能を実装できる。 OpenLDAP は、サン・マイクロシステムズや Netscape/Fedora/Red Hat が使っているプラグインアーキテクチャ SLAPI[7] もサポートしている。最新版では、SLAPI フレームワークは slapd のオーバーレイ内で実装されている。Sun/Netscape/Fedora/Red Hat 向けに書かれたプラグインの多くは OpenLDAP 互換だが、OpenLDAP コミュニティでは SLAPI はほとんど使われていない。 利用可能モジュール
リリース履歴OpenLDAPのメジャーリリースの履歴を示す。
レプリケーションOpenLDAP は、RFC 4533 に規定されているコンテンツ同期を使用したレプリケーションをサポートしている。この仕様を以後、syncrepl と呼ぶ。基本仕様に加えて、delta-syncrepl として知られる拡張もサポートされている。複数プライマリ型（マルチマスター）レプリケーションをサポートするために追加の拡張機能が実装された。 syncrepl基本的な同期操作は RFC 4533 に記述されている。このプロトコルは、変更ための無停止データベースが必要ないように定義されている。 変更内容は、各エントリに格納される変更シーケンス番号（CSN）情報により区別され、最新の削除を追跡するのに有用な任意のセッションログにより最適化されている。 レプリケーションクライアント（コンシューマ）がレプリケーションサーバー（プロバイダ）に「コンテンツ同期検索」を送信する操作モデルとなっている。 （特に以前にプロバイダと同期していた場合）コンシューマは、この検索でクッキーを提供することができる。 RFC 4533 の OpenLDAP 実装では、このクッキーには、プロバイダから受信した最新のCSN（contextCSNと呼ばれる）が含まれている。 次に、クッキーによる既知の内容に基づいてコンシューマを同期状態にするために、プロバイダは、未変更の全エントリ、および、追加・変更・削除された全エントリを検索または、同期情報の結果として返す。なお、未変更のエントリはリフレッシュステージの現在のフェーズでのみ使用される。更新フェーズではすべての現在の属性を追加する。 クッキーが存在しないか、コンシューマが完全に同期していないことを示している場合、プロバイダはリフレッシュ段階で、それが持つ各エントリの追加を送信する。 理想的な場合、応答時のリフレッシュステージには、コンシューマがプロバイダと最後に同期した時刻以降に発生したわずかな変更・削除が対象となる。 しかし、プロバイダに保持されているセッションログの状態が限られているため、現在の全エントリが必要になることがある。コンシューマがプロバイダと最後に同期した後、プロバイダが削除したものを処理するために、変更されていないすべてのエントリが必要となる。 検索は、refresh または refreshAndPersist モードで実行できる。 リフレッシュステージは常に最初に発生する。リフレッシュステージでは、present と delete の2つのフェーズが発生し、present は常に delete の前に発生する。 フェーズは、フェーズの完了を示す同期情報の応答によって区切られる。 リフレッシュおよび持続ステージもまた、同期情報の応答によって区切られる。 存在または削除されるエントリのグループをよりコンパクトに表現する最適化は、これらのエントリの entryUUID 値のリストを識別する syncIdSet を含む同期情報の応答を使用する。 present フェーズは、delete フェーズと以下のように区別される。 変更されていないエントリは、present フェーズでのみ返される。削除されるエントリは、delete フェーズでのみ返される。 追加エントリ（変更されたエントリのすべての属性を示す）は、どちらのフェーズでも返すことができる。 したがって、present フェーズの最後において、コンシューマをプロバイダと同期させるためにコンシューマは次のエントリを削除しなければならない。
persist ステージが始まると、プロバイダは、リフレッシュステージ完了後の追加、変更、および削除の全エントリの検索結果を送信する。 persist ステージは無期限に続き、検索には最終的な「完了」応答がない。 対照的に、リフレッシュモードでは refresh ステージのみが発生する。 refresh ステージは、persist または delete フェーズ（現在アクティブなフェーズのいずれか）も完了応答で終了する。 delta-syncreplこのプロトコルは、書き込み（変更）アクセスのデータベースを保持することで、全変更（変更された属性のみ）を厳密に表す。 標準の syncrepl 仕様に基づいている。 このプロトコルでは、変更を常に完全なエントリとして送信します。 しかし、delta-syncrepl は、送信されたエントリは実際にはログデータベースから送信され、メインデータベースの各変更は、ログエントリとして記録されます。 ログエントリは、LDAPログスキーマを使用して記録されます。[9] 脚注・出典
外部リンク
|
