目次

OPENLDAPのバックエンドをbdbからmdbに入れ替えついでにOLC(cn=config)対応する

2016/10/07
OPENLDAP 2.4.44 でbdb非推奨になったのを受け、mdbへの移行を行う自分用メモ。
slapd.conf はまだ使えるけど後で泣いても知らないよー、と脅しがあったのでon-line configuration (OLC) へ移行を行う自分用メモ。

2016/10/07-2
実運用環境で mdb に移るときは maxsize の指定を必ずやっとくように。 私が対応してきた環境ではエントリーが5万を超えた辺りで“index generation failed”とか言われてldapaddコマンドで1エントリーずつしか追加できなくなってしまった。 どうもmaxsizeの指定が無いとデフォルトの小さなサイズ(10485760B→10MB)で処理を行おうとしてエントリーの追加についていけなくなってしまうみたい。たぶん1エントリーずつなら出来ていた追加もすぐ限界が来ると思う。サンプルにあったサイズ(1073741824B→1GB)なら問題なく処理できた。

環境は FreeBSD/amd64 10.3-RELEASE。実環境で実行する前にプライベート環境で実験している。

バックエンドデータベースを bdb から mdb へ変更する

いつの頃からかバックエンドデータベースとして bdb が非推奨になりPortsのデフォルトオプションでも bdb が外されていたので mdb に変更する。

まだ指定すれば使えるけど、DEPRECATED(非推奨)になっちゃってる。

bdb稼働状態のOPENLDAPからLDIF形式でデータをダンプする

bdbからmdbへの変換パスは無い様なので、バックアップ・リストアの手順を踏むことになる。 Apache Directory Studio で参照するとこんなツリーをダンプする。

slapcatコマンドを使ってLDIF形式でダンプを取得した。

root@openldap:/usr/local/etc/openldap # slapcat -b "dc=hgotoh,dc=local" -l backup.ldif
57f66986 bdb_db_open: warning - no DB_CONFIG file found in directory /var/db/openldap-data: (2).
Expect poor performance for suffix "dc=hgotoh,dc=local".
root@openldap:/usr/local/etc/openldap #

取得したLDIF形式ダンプから特定のアトリビュート指定を取り除く

ここで取得したLDIF形式ダンプをldapaddコマンドで投入し直すことになるが、このままではエラーとなる。 以下はバックエンドをmdbに入れ替えしたOPENLDAPに投入したところ発生したエラーの一部。

root@openldap:/usr/local/etc/openldap # ldapadd -x -D "cn=Manager,dc=hgotoh,dc=local" -W -f backup.ldif
Enter LDAP Password:
adding new entry "dc=hgotoh,dc=local"
ldap_add: Constraint violation (19)
        additional info: structuralObjectClass: no user modification allowed

root@openldap:/usr/local/etc/openldap #

各エントリーにあるアトリビュート指定行をいくつか削除しておく必要があった。 今回の作業では以下の行を各エントリーの定義から削除した。もっと種類があるのかもしれないが私にはわからない。

変更前 変更後
dn: dc=hgotoh,dc=local
objectClass: organization
objectClass: dcObject
dc: hgotoh
o: hgotoh inc
structuralObjectClass: organization
entryUUID: ae888424-2024-1036-9c5c-27e7a8b8c544
creatorsName: cn=Manager,dc=hgotoh,dc=local
createTimestamp: 20161006152413Z
entryCSN: 20161006152413.646899Z#000000#000#000000
modifiersName: cn=Manager,dc=hgotoh,dc=local
modifyTimestamp: 20161006152413Z

dn: ou=Peoples,dc=hgotoh,dc=local
objectClass: organizationalUnit
ou: Peoples
structuralObjectClass: organizationalUnit
entryUUID: ae88b7c8-2024-1036-9c5d-27e7a8b8c544
creatorsName: cn=Manager,dc=hgotoh,dc=local
createTimestamp: 20161006152413Z
entryCSN: 20161006152413.648232Z#000000#000#000000
modifiersName: cn=Manager,dc=hgotoh,dc=local
modifyTimestamp: 20161006152413Z

dn: ou=Groups,dc=hgotoh,dc=local
objectClass: organizationalUnit
ou: Groups
structuralObjectClass: organizationalUnit
entryUUID: ae88e25c-2024-1036-9c5e-27e7a8b8c544
creatorsName: cn=Manager,dc=hgotoh,dc=local
createTimestamp: 20161006152413Z
entryCSN: 20161006152413.649325Z#000000#000#000000
modifiersName: cn=Manager,dc=hgotoh,dc=local
modifyTimestamp: 20161006152413Z

dn: cn=user1,ou=Peoples,dc=hgotoh,dc=local
objectClass: top
objectClass: person
cn: user1
sn: user1
structuralObjectClass: person
entryUUID: ae8911dc-2024-1036-9c5f-27e7a8b8c544
creatorsName: cn=Manager,dc=hgotoh,dc=local
createTimestamp: 20161006152413Z
entryCSN: 20161006152413.650540Z#000000#000#000000
modifiersName: cn=Manager,dc=hgotoh,dc=local
modifyTimestamp: 20161006152413Z

dn: cn=dev1,ou=Groups,dc=hgotoh,dc=local
objectClass: top
objectClass: groupOfNames
cn: dev1
member: cn=user1,ou=Peoples,dc=hgotoh,dc=local
structuralObjectClass: groupOfNames
entryUUID: ae893ff4-2024-1036-9c60-27e7a8b8c544
creatorsName: cn=Manager,dc=hgotoh,dc=local
createTimestamp: 20161006152413Z
entryCSN: 20161006152413.651718Z#000000#000#000000
modifiersName: cn=Manager,dc=hgotoh,dc=local
modifyTimestamp: 20161006152413Z
dn: dc=hgotoh,dc=local
objectClass: organization
objectClass: dcObject
dc: hgotoh
o: hgotoh inc

dn: ou=Peoples,dc=hgotoh,dc=local
objectClass: organizationalUnit
ou: Peoples

dn: ou=Groups,dc=hgotoh,dc=local
objectClass: organizationalUnit
ou: Groups

dn: cn=user1,ou=Peoples,dc=hgotoh,dc=local
objectClass: top
objectClass: person
cn: user1
sn: user1

dn: cn=dev1,ou=Groups,dc=hgotoh,dc=local
objectClass: top
objectClass: groupOfNames
cn: dev1
member: cn=user1,ou=Peoples,dc=hgotoh,dc=local

OPENLDAP停止

以下のコマンドで停止。

service slapd stop

slapd.conf書き換え

slapd.confの該当する記述をmdb用に書き換えする。

変更前 変更後
moduleload     back_bdb
moduleload     back_mdb
database        bdb
database        mdb
maxsize         1073741824

データベースディレクトリのバックアップ

bdbのデータベースファイルがディレクトリ /var/db/openldap-data に格納されているので(slapd.confに記述がある)、このディレクトリを /var/db/openldap-data.backup にリネームする。 mdbバックエンドで正しく動作しているようならあとで削除する。

ディレクトリはmdbバックエンドでの初回起動時に作成されるので、作り直さなくてもよい。

OPENLDAP開始

以下のコマンドで開始。

service slapd start

LDIF形式ダンプを取り込む

先に編集を済ませたLDIF形式ダンプをldapaddコマンドで取り込む。

root@openldap:/usr/local/etc/openldap # ldapadd -x -D "cn=Manager,dc=hgotoh,dc=local" -W -f backup.ldif
Enter LDAP Password:
adding new entry "dc=hgotoh,dc=local"

adding new entry "ou=Peoples,dc=hgotoh,dc=local"

adding new entry "ou=Groups,dc=hgotoh,dc=local"

adding new entry "cn=user1,ou=Peoples,dc=hgotoh,dc=local"

adding new entry "cn=dev1,ou=Groups,dc=hgotoh,dc=local"

root@openldap:/usr/local/etc/openldap #

再度Apache Directory StudioでOPENLDAPに接続し、参照できることを確認した。

注意

createTimestampやmodifyTimestampといったオペレーショナルなアトリビュートを移せないので、これらをあてにしているアプリケーションは問題を起こすだろう。 必要であれば他の方法を探すこと。

slapd.confからOLC(cn=config)へ移行する

最近ではOPENLDAPの設定記事でこちらの説明をしている記事が増えてきている。また、はやいうちにOLCに移行した方がいいぞー、と脅してるブログ記事があったり。

小心者なのでやれるうちにやっておくことにする。

OPENLDAP停止

以下のコマンドで停止。

service slapd stop

/etc/rc.conf に追加

FreeBSDの場合、/etc/rc.conf にOLCを使って起動するよう記述の追加が必要。

slapd_cn_config="YES"

/usr/local/etc/openldap/slapd.conf を編集

次の3行を、「database mdb」の記述行より前に記述。

database        config
rootdn          "cn=admin,cn=config"
rootpw          config

「database mdb」記述行以降を削除しないこと。slaptestコマンドがマイグレーションを行う時の参照情報の為。

slaptestコマンドでマイグレーションする

slapd.confの内容からマイグレーション用ファイルが生成され、ディレクトリ /usr/local/etc/openldap/slapd.d の中に格納される。

root@openldap:/usr/local/etc/openldap # cp slapd.conf slapd.conf.backup
root@openldap:/usr/local/etc/openldap # mkdir slapd.d
root@openldap:/usr/local/etc/openldap # slaptest -f slapd.conf -F slapd.d
config file testing succeeded
root@openldap:/usr/local/etc/openldap # ls -l slapd.d
total 8
drwxr-x---  3 root  wheel   512 10月  6 15:40 cn=config/
-rw-------  1 root  wheel  1030 10月  6 15:40 cn=config.ldif
root@openldap:/usr/local/etc/openldap # 

直接書き換えるとCRCエラーになるのでやっちゃダメ。

OPENLDAP開始

以下のコマンドで開始。

service slapd start

再度Apache Directory StudioでOPENLDAPに接続し、参照できることを確認した。

cn=configを参照してみる

slapd.conf に記述した database config はcn=config のスキーマに対応する指定。Apache Directory Studio でこのスキーマを参照してみる。バインドするユーザは cn=admin,cn=config でパスワードは config になる。slapd.conf に記述したあれと一緒。

slapd.conf に記述していた database mdb の内容がLDAPのツリーから参照できている。

slapd.confを変更した場合はサービス再起動が必要だったが、OLCならその必要はない。LDAP上のエントリを書き換えするとそのまま内容が反映される。はず。 そしてその変更はディレクトリ slapd.d 以下のファイルに反映される。

一度OLCで稼働すれば slapd.conf は不要な筈だけど、他の記事では消すことをしていないような……気持ちはわかる。