/etc/passwdから一般ユーザー情報を削除しLDAPへ移行しようとしたら、まぁいろいろ不具合が。ProFTPD の次は、IMAPサーバのdovecot。RPMでインストールすると/etc/passwdからユーザー情報を取ろうとする。

LDAPで認証をするときは大まかに二つあって、

• LDAPサーバにユーザーIDと(平文)パスワードを渡して、LDAPサーバでOKかどうか返事してもらう
• LDAPサーバから暗号化されたパスワードを取得して、自前でパスワードが正しいか判断する

dovecotは前者はサポートしないらしい(*1)。これだとパスワードの暗号化の方法とかで面倒なことになりそうなので(*2)、認証だけはPAM、そのほかのユーザー情報はanonymousで取ってくるようにと、/etc/dovecot.confを以下のように変更。

auth_userdb = ldap /etc/dovecot-ldap.conf
auth_passdb = pam

[2008/3/11 追記] (*1) パスワードが平文でLDAPサーバに送られてしまうからですかねぇ? TLSなどの対策した方がよさそうです。 (*2) 暗号化方法にSSHAとかMD5とか複数ありまして、適当に暗号化方法を決め打ちでやるとLDAP側で暗号化方法を変えた瞬間認証できなくなります。ちゃんと対応すればいいのですが、面倒なので・・・PerlでSSHAの暗号化ってどうやるの^^;

LDAPサーバへのアクセス設定は別ファイル/etc/dovecot-ldap.confで行うと設定。サンプルはソースファイルのdocディレクトリにあります。認証はPAMでやるため設定は簡単で、

base = dc=example, dc=com
hosts = ldap.server.example.com

などと自分の環境に合わせます。LDAPサーバーは認証要求応答とユーザー情報提供をanonymousに行うため、/etc/openldap/slapd.confを以下のように。これはProFTPD の時から変更なし。

access to attrs=userPassword
        by self write
        by dn="cn=manager,dc=example,dc=com" write
        by anonymous auth
        by * none

access to *
        by self write
        by dn="cn=manager,dc=example,dc=com" write
        by * read

PAMの設定はデフォルトのままで、/etc/pam.d/dovecotを

#%PAM-1.0
auth       required     pam_nologin.so
auth       required     pam_stack.so service=system-auth
account    required     pam_stack.so service=system-auth
session    required     pam_stack.so service=system-auth

にしてあります。

PSUのバレンタイン企画 。クリスマスの時 は、気づくのが遅く期間半ばで設定するも、来ず。今回は、来るかな?

PSU は去年新バージョンのイルミナスの野望が販売され新機能が数多く追加されたのですが、それらは新バージョンを購入しないと利用できません。ですが、ゲームは旧バージョンの人と一緒にプレイできます。何が起きるかというと、旧バージョンのままの人は一部のアイテムなどが見えなかったり、特定の場所には入れなかったりします。

PSUでは各個人が店を持つことができて手に入れたアイテムなどを販売できますが、これにも上記の影響があります。自室のデザインを新バージョンで追加されたものにすると、旧バージョンの方は入店できないのです。

今や新規に配信されるゲーム内容はほとんど新バージョン専用となり、ほとんどの人が新バージョンなのでしょうが、私は残り少なくても旧バージョンの人が入店できないのが嫌で、デザイン変更をせずにいます。とはいえ、ぼったくった値付けをするつもりはありません。相場が下落したのに気づかないことはありますがｗ

と、今日来たお客さんが旧バージョン。入れる店が少ないので、私のところに来たのだとか。それだけでもこちらの目論見通りでうれしかったのですが、話をすると旧バージョン使用の理由が海外在住者なので新バージョンがなかなか手に入らない、その方の居住先が私が過去に何度も出張したところであると分かり、盛り上がりまして。

これだけでも、店を旧バージョンの方に開放しておいてよかったと思う次第。

年明け早々、会社のシステムに関して不具合報告が来る。原因を調べると、全く同じ定義の二つのテーブルに対し全く同じSQLなのに、片方のテーブルでは結果取得時にphpが静かに落ちてしまう。psqlコンソールから入力すると問題なく結果が出る。なんだこりゃ?

いろいろ調べてたどり着いた結論(仮説)は、PostgreSQLのバージョン。OSはx86_64のCentOS 4.6でほとんどがRPMパッケージで固めてあるのですが、このバージョンのCentOSで提供されるPostgreSQLが7.4。システム構築時点での最新版PostgreSQL 8.1はパフォーマンスが大幅に改善されたということだったので、こいつだけtarballからコンパイルして使っていたのです。

で、PostgreSQL 7.4でデータベースアクセス用に提供されているライブラリがlibpq.so.3、一方8.1はlibpq.so.4の使用を要求します。phpはRPMパッケージなのでlibpq.so.3を使ってアクセスしようとするわけで、ここでバージョンの不整合が発生しているのです。・・・よく今までこんなのが動いていたな。

では、phpもtarballでコンパイルしましょうかと挑んだところ、やれこのライブラリのバージョンが古いだとか、エラー続出で早々に断念。ではSRPMで--with-pgsql=shared→/usr/local/pgsqlとphp.specを編集してrpmbuildするも、コンバイル後の動作テストでFail(*1)。

結局、CentOS PlusのPostgreSQL 8.1 SRPM を取ってきてコンパイル、その後それを使ってphp SRPMのコンパイル(エラー出すのでlibc-clientも)、ついでにPostgreSQLに依存するdovecotのSRPM、さらにこれらのSRPMが依存する-develパッケージのインストールと、大掛かりな作業をやって、やっと動作検証機で動作しました。

さぁ、明日は本番機に適用だ。

(*1) 32bit環境だともしかすると動くかも。コンパイルログを見るとOIDの型がunsigned int(4バイト/PostgreSQL)とlong(8バイト/php)となっており、数値比較で常にFalseとなる論理式があるとWarning出てたので。

[参考]Hatena::Question 【総額1000ポイント】PHPとPostgreSQLの連携がうまくいきません。

[2008/2/8 追記] 本番機に入れたら、不具合が改善しない・・・テーブルのアクセス制限が狂っていたのが原因でした orz

このプログのエンジンであるppBlog を最新版にアップデート。作者がUTF-8環境に移行したいらしく、最新のβ版は今のところUTF-8版しかないし、そのうちEUC版がなくなるのは確実。とはいえ、セキュリティ方面のアップデートもあるので、バージョンアップしないのも気分悪い。

てなわけで、このブログはUTF-8になりました。読めなくなった方、申し訳ございません m(_ _)m いやね、時々Netscape 4.7とか古いブラウザでのアクセスがログに残ってまして・・・ こういう時って、検索エンジンはデータを全面更新するのですかね？ いや、検索効率考えたら内部は統一した文字コードで保存するだろ。