同機種で2個目。まったく同じ箇所だったので調べたら、またGSCだよ orz このマザー、壊れたものも含め計6個のGSC製ケミコンを使用。CPU周りに三洋使ってるなら、全部それにしておいてくれT_T。時代が近いPentium4/AthlonXPのマザーは要注意だなぁ。

/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

にしてあります。

年明け早々、会社のシステムに関して不具合報告が来る。原因を調べると、全く同じ定義の二つのテーブルに対し全く同じ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

なんかそういう話を時々見ますが、実際に使っている者 として特に不満な点はなく、自分が鈍いのかと不安になってしまう（＾＾；）

古いマシンに入れると重いというのはあるかもしれない。けど、やっていること考えればメモリやGPUが必要なことは理解できる。そのやっていることの恩恵(仮想化)が分かるのが数年後、64ビットCPUと10GBのメモリが当たり前になってからだろうか。少なくない人がそんな恩恵要らないと言うでしょうね。

その昔WindowsはVer 3.1で8MB、95で16MB、HDDは100MB、グラフィックはXGAと、当時主流だったDOSに対して圧倒的なマシンパワーを要求したわけですが、そんなWindowsで何ができるのと聞かれると、Excelしながら時計が表示できるよとか、ネットでダウンロードしながらテキストファイルが編集できるよとか。そんなもののために金かけてマルチタスクなんていらね〜よ、って言われたもんです。

仮想化が10年後に何を見せてくれるかよく分かりませんが、XP→Vistaの変化はDOS→Windowsにダブって見えます。

UACはセキュリティーに馴染んでない人には、面食らうかもね。

SCSI RAIDカードが壊れたサーバ の復旧で、CentOS を4.6から5.1に変更。ついでに一般ユーザー管理をLDAPに移行してしまおうと。以前からLDAPサーバは立ち上げてあったので移行はそれほど苦労しなかったのですが、ProFTPD がPAM+LDAP(pam_ldap.so)で認証してくれず、ログには no such user 'foo'と出る。

どうやらProFTPDは認証以外のユーザー名・UID・GIDといった情報を/etc/passwdから取っているらしい。今回それらの情報はLDAPに入れてあり/etc/passwdにはなかったのがエラーの原因で、/etc/passwdにも情報を入れると認証してくれる(/etc/shadowは不要)。だけどProFTPDのために/etc/passwdを復活させるのは本末転倒。

というわけで、ProFTPDを

./configure --with-modules=mod_ldap

でビルド。設定は/etc/openldap/slapd.conf

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

/usr/etc/proftpd.conf

AuthOrder       mod_ldap.c mod_auth_unix.c
LDAPServer      ldap.server
LDAPDoAuth      on "dc=example,dc=com"

などとします。ProFTPDソースのREADME.LDAPにはLDAPDNInfoの指定も書いてありますが、これではproftpd.confにLDAPのパスワード(何も考えないとmanagerの)を記述してしまうことになりますのでセキュリティ上良くない。上の設定のようにanonymousに

• userPasswordをauthorizeできる
• UID、GID、ホームのパスを読み出せる

ようLDAPサーバを設定したほうがいいでしょう。LDAPDNInfoを指定しなければ、ProFTPDはanonymousでパスワード認証をしにいきます。