OLCのみで構築するOpenLDAPのReplica (syncrepl)

slapd.confを用いずOLC (Online Configuration) のみでやろうとするとドキュメントが少ないのでメモ。環境は Debian wheezy 上のOpenLDAP (2.4.31-1+nmu2) と CentOS 上のもの (2.4.23)

(追記: 本記事の話のバックグラウンドを末尾に追加した。先にそっちを読むと私がどの程度この問題を理解してるかが、分かるよ！)

syncprov モジュールを読み込む

cn=config配下にcn=module{0}を作る。Debianでhdbをバックエンド指定しているケースではこのエントリは既に存在していた。CentOSでは(bdbを指定していた関係なのか)なかったため、一から作る。objectClassとしてolcModuleListを指定しておくこと。

dnがcn=module{0},cn=configなどとなるので、その配下でolcModulePathとolcModuleLoadを設定する。olcModuleLoad: syncprov を指定すれば多分大丈夫。念の為olcModulePathの中にモジュールがあるかは確認すること。

slapdをリブートする。LDAPのGUIを使っているのならこの時点でolcSpCheckpointやConsumer側のolcSyncProvConfigといった設定が使えるようになっている、はず。特にolcSyncProvConfigはスキーマを自分で読み込もうとしないこと。モジュールが提供してくれる。

結果、例えば以下のような感じになるようだ (ldapiでcn=configにアクセス出来るようにしとけ？)

> sudo ldapsearch -LLL -Y EXTERNAL -H ldapi:/// -b "cn=config" "cn=module{0}"
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
dn: cn=module{0},cn=config
objectClass: olcModuleList
objectClass: olcConfig
objectClass: top
cn: module{0}
olcModulePath: /usr/lib64/openldap
olcModuleLoad: {0}syncprov

syncprovモジュールはProvider/Consumer双方で読み込む必要がある模様。この記事ではあまり深く掘り下げないが、Provider側でも2〜3の設定を書いておく必要がある(olcSpCheckpoint (旧 syncprov-checkpoint)とかの設定をする)。これを読むと良い: http://www.openldap.org/doc/admin24/replication.html

＃そもそも不可解だ。なんで最新の公式ドキュメントがOLC前提でこのあたりの設定の仕方を書いてないんだ

以降はハマリポイントが多いレプリケーション先=Consumer側の設定について書く。

レプリカのデータを保存するデータベースを追加する。

最初に指定した環境でパッケージインストールした場合、cn=config下に既に olcDatabase={1}hdb とかそういうのがあるはずなので、真似する。

注意点がある

• olcDbDirectory は自分で作ってslapdが読み書きできるパーミッション設定とする
• olcSuffixをレプリカ元と同じにして最初に指定する (後で指定できない)
• olcAccessを指定するのを忘れない (OpenLDAPデフォルトではanonymousでもreadできる)
• db関係の設定を忘れない ((olcDbDirectory)/DB_CONFIG がないのでパフォーマンスが死ぬほど遅くなるよ、という警告がlogに流れている可能性あり)

olcAccessは(ルートで食うのなら)とかで良い。ただしSASLも使えなくなる。

to * by dn="cn=admin,cn=config" read

olcOverlayの設定

上記で追加したデータベースの下にolcOverlayの設定をする。ぐぐって出てくるので割愛

olcSyncrepl の設定

割愛 (本当はここが本質だが)

olcSyncrepl: rid=1  provider=ldap://source.example.com
  type=refreshOnly   bindmethod=simple   binddn="(binddn)"
  credentials=(password)    retry="30 10 300 5"
  timeout=30 searchbase="(basedn)"

base dn の(レプリカ元=Providerとレプリカ先=consumerでの)不一致が発生した際にslapdが出すエラーが比較的不可解な点にやや注意。syncrepl - Base DN is not within the database naming context. とか出る。命名コンテクストとはつまり basednのことのようだ。

その他

• レプリカ元と同じスキーマをインストールしておくこと。SAMLの絡みならeduPersonがハマリポイントになるだろうな
• ldapadd等でやるのも良いがGUIツールで手探りでやるほうが楽だろう。今回はApache Directory Studioを使ってる。
• slaptest 等で slapd.conf から生成して頑張る、という手もあるんかもしらん
• 困ったら (sudo) slapcat -b cn=config と man slapd-config を往復して以下のURLを読み読みがんばれば良い。

参考みたいな

• http://www.openldap.org/doc/admin24/replication.html
• http://www.zytrax.com/books/ldap/ch6/slapd-config.html

全体像 (2013-05-20 追加)

Replica、すなわち複製を作って運用する場合には、オリジナルのデータを持つ側とそれを複製する側の二者がいる。OpenLDAPにおいては、そのニ者をMaster, Slaveと呼んでいたらしい。今ではProviderとConsumerと呼ばれる(http://www.openldap.org/doc/admin24/replication.html)

このLDAP上のプロトコル自体はRFCで規定されている。OpenLDAPがこれに対応するにはsyncprovモジュールを用いる。複製するプロトコルが最小ビルドで勝手についてくるわけではない。

モジュールを組み込んだ後、ProviderとConsumer双方で相応の設定をするのだが、Consumer側は特にReplicaを保持する仕組みを準備しておく必要がある。

で、OLCというのが上の話を少し複雑にする。Online ConfigurationはLDAP 2.3くらいに推奨されるようになった(らしい) OpenLDAPの設定ファイルの保存の仕方。以前の仕組み (slapd.conf) では、設定を変更する度にサーバ (slapd) を再起動しなければならなかったが、OLCでは再起動の必要はなくなる。slapd.dというディレクトリ内に階層化された設定ファイルとその専用のスキーマが見られるようになった。

つまり、OpenLDAPにおいて、設定ファイルの書き方が「やや最近」大きく変わった。似ているが結構違うのだ。設定に使う名前とか、どこにデータが保存されるとか。

昔のOpenLDAPの記事は主に古い仕組み (slapd.conf) に書く方法を解説している。これらの「概念」は比較的通用するのだけど、OLCになるとそれらの設定はOLCの階層構造のどこかに別の名前で書く必要がある。ここが結構面倒。特に本家の2.4時点のドキュメントもこのあたりの説明は雑なままだ。混乱が混乱を招く。とあるアカデミック関係のサイトの参考記事もslapd.conf前提のOpenLDAP設定例が書かれていて、今適用すると壮大に爆死する。

slapd.conf は今もサポートされている。現時点で古い方法を使うことによる直接の害はない、と信じたい。

ただ、ドキュメントの整備具合やこういった記事 (http://www.zytrax.com/books/ldap/ch6/slapd-config.html) の解説を読むと、早い段階で対応しておくのが吉、という印象も受ける。

OpenLDAP has a history of being quite brutal about withdrawing support of older capabilities. This means that migration to on-line configuration (OLC, cn=config) should be contemplated as soon as practical. Better to do it when you don't need the new release than to be forced to take a new release because of a critical bug AND have to migrate to the new configration regime. (強調引用者つまり私)

という理解に対するコメント

実際には今回の設定作業でリブートが要求されているので、「OLCではその必要はない」は努力目標の面があるような。だいほんえいはっぴょうと内実はしばしば一致しない。モジュールのロードとか、まぁそういうのはリブートしてよいと思うんだけど、スキーマロードでもリブートの必要があるのね。世界は複雑ね。

そもそも、OLCについても本家が「ゴメーンやっぱりやめ」とか言い出す可能性もあるわけなので、slapd.confを使い続けるという選択は安定しているとも言える。ただ、OLCの目標自体はそんなにおかしいもんじゃない、ということで、OLCに対応してみる意義はある気がするんだ。混乱は新しい方向に収束させてくべきだよ。もしこの記事をslapd.confがbrutalにぶっ飛ばされた後に読んだ人は、喜ぶべきだし、逆を見た人はm9すると良いんだ。

長くなった。