カテゴリー別アーカイブ: PostgreSQL

Shibboleth IdPのログをPostgreSQLに格納する

Shibbolethのログ保存の問題

Shibboleth IdPのログは通常、サーバ上のテキストファイルとして記録され続けますが、この形式では次のような問題があります。

  • 複数サーバでロードバランスしている場合にログが分散してしまう(Shibbolethのロードバランサ配下での利用に関してはこちら)。
  • ログを様々な条件で検索したい場合に不便。

特に、Shibbolethは標準ではログイン履歴的な情報を参照することが困難なため、監査ログ(idp-audit.log)の検索ができると特に便利です。

先行事例の検討

検索していたところ、いくつかの先行事例が見つかりました。例えば次のようなものがあります。

時間がたっぷりあれば、後者のほうが魅力的ではありますが、安易にやるならば前者のほうが実に簡単そうです。そこで、まずはsyslogベースで実現してみることにしましたが、やはりsyslogメッセージのパースは実現したいと思います。対象は監査ログということにしました。

(もちろん、信頼性やその他の問題から、Shibboleth IdPから直でDBに入れたほうが良いことはわかっているので、今後時間がある時に、そちらも試してみようかと思います) 続きを読む

OpenLDAP back-sqlにおけるPostgreSQLのtext型の利用

先日、OpenLDAPのback-sqlの使い方について解説してみたのですが、その際にちょっと気になっていたことがありました。OpenLDAPのサンプルのSQLに引きづられて文字列型にvarchar型を利用していたのですが、実際のところ互換性の話を考えなければ、PostgreSQLでvarchar型を使う理由はあまりありません。むしろ効率などの面でもPostgreSQLではtext型の方がオススメです。

というわけで、back-sqlのテーブルのvarchar型を全てtext型に変更してみました。たとえば、edupersonのテーブルは次のようになります。

さらに、back-sqlが内部的に用いるテーブルであるldap_attr_mappings, ldap_entries, ldap_entry_objclasses, ldap_oc_mappings内のvarchar型もtext型に直してみました。たとえば、ldap_attr_mappingsは次のようになります。

これでデータベースを作りなおしてみたところ、問題なく動作しました。もし、現用の環境をそのまま変更したいのであれば、バックアップ(もしくはVMのスナップショット)を取った上で、slapdを停止すれば、alter tableで型の変更が可能です。たとえば、

のように実行すれば(この例はedupersonのuidを変更する場合)、データは保ったままtext型に変更可能です。なお、edupersonのuidにはNOT NULLの制約がありますが、これはそのままtext型に変更しても受け継がれます。

これで、根拠の無いvarcharの文字数指定がなくなってすっきりしました。

以前、802.1X用のFreeRadiusのバックエンドにPostgreSQLを用いた際も、サンプルのSQLをほぼそのまま使ったらセッションIDをしまう部分がvarchar(32)型で、新しく導入したCiscoのAPが返すセッションID(33文字)を格納しきれずにvarchar(64)型にalter tableしたことを思い出します(本当はtext型にalter tableしたかったのだけれども、動いているシステムにそれを行うのは怖いので、varchar型の文字数を変えるにとどめました)。

こういうソフトのバックエンドにPostgreSQLを使われる開発者の方は、開発の段階でvarchar型ではなくtext型を使ってほしい…と個人的には思ってます。

プロビジョニングの道具としてのOpenLDAP back-sql

OpenLDAPのバックエンドのおすすめはBDBなのですが、多くの場所から認証データを収集し、適切な形に編集してLDAP形式で公開する、いわばアカウント・プロビジョニング的な用途には、SQLのバックエンド機能(back-sql)も魅力的に見えます。

巨大なデータをトランザクションで全件更新しつつ、パスワードの更新は可能な限りリアルタイムで別テーブルに収集し、より新しいパスワードをクライアントに渡す…ような仕組みは、(単なるイメージなのかもしれませんが)やはりSQL系のデータベースに一日の長があるのではないかと考えます。

そんな魅力的に見えるOpenLDAPのback-sqlですが、実際に試してみると次のような欠点があります。

  • パフォーマンスが悪い
  • 設定が複雑すぎてわけがわからない

まずは性能面です。小規模なデータの場合はそれほどでもないのですが、大規模なデータを食わせると途端に悲惨な性能になってしまいます。実際に数万件のデータを食わせたところ、1秒に5件ほどしか検索ができないという悲惨な状況になりました。これではいくらなんでも実用的ではありません。

設定が複雑なのは、LDAPのスキーマを、SQLのスキーマとデータ(メタデータと呼ぶ)の双方を使って表現するからです。テーブル構造は難しくありませんが、メタデータの方はたしかに難解です。その分、さまざまなカスタマイズも可能と言えますが、そのメリットがあるかどうかはケースによりますが微妙でしょう。

これら2つの論点について、軽く解説します。なお、ここで用いたバックエンドのSQLデータベースはPostgreSQLです。

OpenLDAP back-sqlの性能問題

大規模なデータを入れると悲惨な性能になると評判のback-sqlですが、実はサンプルなどを見てスキーマをこさえて、何も考えずに大量のデータを入れると性能が悪化するのは当たり前で、PostgreSQL用のサンプルもMySQL用のサンプルも、インデックスの定義が含まれていません。

続きを読む