CentOS4のsubversionをアップグレード (on WebARENA v2)

CentOS4の標準パッケージのsubversionは1.1.4-2.entとちと古いので、アップグレードしてみる。

本家(subversion: Subversion Packages)によれば、RHEL4用の最新rpmがあるようなので、これを流用する。CentOSx と RHELx (Redhat Enterprise Linux x)は互換性がある。

[root@host ~]# mkdir subversion
[root@host ~]# cd subversion
[root@host subversion]# wget http://the.earth.li/pub/subversion/summersoft.fay.ar.us/pub/subversion/latest/rhel-4/x86_64/apr-0.9.12-2.x86_64.rpm
[root@host subversion]# wget http://the.earth.li/pub/subversion/summersoft.fay.ar.us/pub/subversion/latest/rhel-4/x86_64/apr-util-0.9.12-1.x86_64.rpm
[root@host subversion]# wget http://the.earth.li/pub/subversion/summersoft.fay.ar.us/pub/subversion/latest/rhel-4/x86_64/mod_dav_svn-1.4.6-1.rhel4.x86_64.rpm
[root@host subversion]# wget http://the.earth.li/pub/subversion/summersoft.fay.ar.us/pub/subversion/latest/rhel-4/x86_64/subversion-1.4.6-1.rhel4.x86_64.rpm
[root@host subversion]# wget http://the.earth.li/pub/subversion/summersoft.fay.ar.us/pub/subversion/latest/rhel-4/x86_64/subversion-python-1.4.6-1.rhel4.x86_64.rpm
[root@host subversion]# rpm -Uhv ./*.rpm

subversion-pythonをアップグレードしないと、Tracでエラーが出るので要注意。

あと、Virtualhostで複数のtracmod_pythonで使う場合は、下記の一行を入れないとエラーでハマるのでご注意を!

PythonInterpreter   main_interpreter 

参考URL:http://blog.pear.co.jp/archives/595

bdbからfsfsへのコンバート

Subversionのupgradeの下準備。
1.2以降は、bdbが標準でサポートされなくなるので、fsfsにコンバート。

[root@host ~]# cd /home/svnroot
[root@host svnroot]# svnadmin dump OLD-REPOSITORY > dumpfile
[root@host svnroot]# svnadmin create --fs-type fsfs NEW-REPOSITORY
[root@host svnroot]# svnadmin load NEW-REPOSITORY < dumpfile
[root@host svnroot]# cp -a OLD-REPOSITORY/hooks/* NEW-REPOSITORY/hoooks/
[root@host svnroot]# chown -R apache NEW-REPOSITORY

suPHPドキュメント

suEXECのphp版ともいうべき、suPHP。日本語のドキュメントが見つからなかったので、和訳してみた。自己責任でどうぞ。
suPHP - Home

ただし、CentOS 4では、Fedora Core 6用のrpmパッケージが使えるようなので、これを使いました。

[root@server ~]# wget http://ftp.riken.jp/Linux/fedora/extras/6/SRPMS/mod_suphp-0.6.2-1.fc6.src.rpm
[root@server ~]# rpmbuild --rebuild mod_suphp-0.6.2-1.fc6.src.rpm 
[root@server ~]# rpm -ivh /usr/src/redhat/RPMS/x86_64/mod_suphp-0.6.2-1.x86_64.rpm

これで、下記の設定ファイルができるので、書き換えてApacheをリロードすればOKです。

/etc/suphp.conf
/etc/httpd/conf.d/mod_suphp.conf

下記のサイトを参考にさせていただきました。
http://www.dabits.net/tips/server/suphp.html

以下のドキュメントは、suPHP 0.6.2 released に同梱のファイルを元にしています。

doc/INSTALL

===========================
== suPHP                 ==
===========================

インストール
------------

1. 概要

suPHPとsuPHP Apache moduleは、複数のユーザーが、一つのサーバー上で
PHPスクリプトを簡単に実行する手段を提供します。

これはセキュリティを提供します。なぜなら、PHPスクリプトは webserver の
ユーザー権限で実行されないからです。
さらには、スクリプトに多くの制限が課される、PHPのセーフモードは使う
必要がなくなるでしょう。

suPHPの実行ファイルは、setuid-rootでインストールする必要がありますので、
suPHPのセキュリティバグのために、root権限でコマンドが実行されるアタックを
許す可能性があります。私は現在のところ、suPHPのどんなバグも認知していませんが、
バグが全くないことを保証することはできません。

2. インストール

./configure をシステムに応じたパラメーターをつけて実行してください。

ほとんどのシステムでは、下記で充分なはずです。

 ./configure --prefix=/usr

configureスクリプトは、おなじみのGNU autoconfの引数に加え、
次のsuPHP専用の引数が使えます。

--disable-checkpath:
  このコンパイルオプションをつけると、suPHPはスクリプト(あるいはシンボリックリンク)
  がDOCUMENT_ROOT配下にあるかどうかをチェックしません。"Alias"ディレクティブと同時に
  使う場合に、このオプションが便利なことがあります。

--disable-checkuid:
  このオプションをつけると、/etc/passwdに存在しないUIDをもつスクリプトを、suPHPで
  動作させることができます。

--disable-checkgid:
  このオプションをつけると、/etc/groupに存在しないGIDをもつスクリプトを、suPHPで
  動作させることができます。

--with-apxs=FILE:
  Apacheの"apxs"がインストールされたパスです。指定されなかった場合は、configureは
  PATHの中のapxsを探します。apxsがない場合、Apacheモジュールであるmod_suphpはビルド
  されません。また、ApacheがDSOサポートなしでコンパイルされている場合も、ビルド
  されません。suPHPはApache 1、apache 2どちらのmod_suphpをビルドするかチェックする
  ためにapxsを使うので、正しいapxsのパスが設定されていることを確認してください。

--with-min-uid=UID:
  suPHPがPHPスクリプトの実行を許可する、最小のUIDです。(デフォルトは100)

--with-min-gid=GID:
  suPHPがPHPスクリプトの実行を許可する、最小のGIDです。(デフォルトは100)

--with-apache-user=USERNAME:
  Apacheが実行されているUsername(UIDではない)です。(デフォルトはwwwrun)

--with-logfile=FILE:
  suPHPのログファイルのパスです。(デフォルトは/var/log/httpd/suphp_log)
                     
--with-setid-mode=MODE:
  MODEは下記のいずれかを選択します。
  "owner":    ownerのUID/GIDでスクリプトを実行します。
  "force":    Apacheで設定されたUID/GIDでスクリプトを実行します。
              (Apache 2を使用している場合のみサポート)
  "paranoid": ownerのUDI/GIDでスクリプトを実行しますが、Apacheで設定された
              UDI/GIDと一致するかどうかをチェックします。
  デフォルトは"paranoid"モードです。
  非常に危険ですので、"force"モードには「絶対に」設定すべきではありません。
  "owner"モードは、"force"モードほど危険ではないですが、推奨しません。
  "paranoid"モードが理想的です。

"make"を使って、suPHPをコンパイルし、エラーがなければ、"make install"を
使ってインストールしてください。インストールするときにはrootであることを
確かめて下さい。

ApacheがDSOをサポートしていて、"apxs"がビルド中に見つかった場合は、
これでおしまいです。そうでなければ、Apacheサーバーを"mod_suphp.c"を
インクルードしてリビルドする必要があります。suPHPのビルド中に、"/usr"以外の
prefixをを用いた場合、suPHPが実行できるようpathをセットするため、
"mod_suphp.c"を修正する必要があります。($exec_prefix/sbin/suphpで見つかります)

mod_suphpを用いて、Apache webserverをコンパイルする方法の詳細は、apache/INSTALL
に記載されています。

次に、"httpd.conf"を修正して、特定のVHostsに対して、suPHPを有効にする
必要があります。この詳細は、apache/CONFIGをご覧ください。

suPHPが動作するためには、suPHPの設定ファイルに、最低一つのhandlerを
記載しなくてはなりません。suPHPの設定方法についての追加情報は、
CONFIGをお読みください。

===================================
(c)2002-2005 by Sebastian Marsching
<sebastian@marsching.com>
Please see LICENSE for
additional information

doc/CONFIG

===========================
== suPHP                 ==
===========================

設定
-------------

1. 概要

suPHP設定ファイルは、$sysconfdir/suphp.conf である。(例、/etc/suphp.conf)
これは、一般的な"INI-file"形式である。

セクション名は、[]で囲まれている。(例、[global])
設定オプションは、keyとvalueのペアで、"="で区切られている。(例、umask=0077)

";"から始まる行はコメントである。

サンプルの設定ファイルは、suphp.conf-example で見ることができる。

2. グローバルオプション

このオプションは[global]セクションで指定する必要がある。
これら全てのオプションは、任意である。

logfile:
  ログファイルのパスを指定する。指定がない場合、コンパイル時の値が使われる。

loglevel:
  "info", "warn", "error", "none"のいずれかが指定できる。
  どのレベルのメッセージが記録されるかを指定する。
  デフォルトは"info"である。

webserver_user:
  webserverが実行されているUIDのUsernameである。指定がない場合、
  コンパイル時の値が使われる。

docroot:
  このパス内にスクリプトが存在しなければならない。これは特に
  check_vhost_docrootが無効となっているとき、追加のセキュリティ対策となる。
  デフォルトは / で、全ての場所にあるスクリプトが実行できる。

chroot:
  スクリプトの実行前に、プロセスのルートディレクトリを変更するパスである。
  スラッシュで終わってはいけない。スラッシュで終わると、chroot()は実行されない。

allow_file_group_writeable:
  グループに書き込み権限のあるファイルを許可する。デフォルトで無効になっている。

allow_directory_group_writeable:
  グループに書き込み権限のあるディレクトリ内のスクリプトを許可する。
  デフォルトで無効になっている。

allow_file_others_writeable:
  othersに書き込み権限のあるファイルを許可する。デフォルトで無効になっている。
  警告:このオプションを有効にすることは非常に危険であり、重大なセキュリティ
  問題を発生します。特に任意のコードが実行される危険があります!

allow_directoy_others_writeable:
  othersに書き込み権限のあるディレクトリ内のスクリプトを許可する。
  デフォルトで無効になっている。
  警告:このオプションを有効にすることは危険です!

check_vhost_docroot:
  スクリプトがウェブサーバーで指定されたDOCUMENT_ROOT内にあるかどうか
  チェックします。このオプションは、ウェブページディレクトリ外の
  シンボリックリンクを避けるために用意されたものです。mod_vhost_aliasや
  Aliasディレクティブを使う場合は、無効にするといいでしょう。
  このオプションは、コンパイル時に"--disable-check-docroot"オプションを
  指定した場合、デフォルトで無効です。そうでなければ、デフォルトで有効です。

errors_to_browser:
  スクリプト実行時の些細な問題についての情報を、ブラウザに送信する場合、
  このオプションを有効にします。このオプションはデフォルトで無効です。

env_path:
  "PATH"環境変数の中身です。これを安全な値にセットしてください。
  デフォルトは、"/bin:/usr/bin"です。

umask:
  スクリプト実行前にセットされるumaskです。
  8進数で指定する必要があります。(例、0077)

min_uid:
  スクリプトを実行できる最小のUIDです。
  デフォルトはコンパイル時の値です。

min_gid:
  スクリプトを実行できる最小のGIDです。
  デフォルトはコンパイル時の値です。

3. ハンドラー

[handlers]セクションでは、mime-typeと使用されるインタプリタとのマッピングを
指定します。

例:
x-httpd-php=php:/usr/bin/php

"key"はmime-typeです。"value"はコロンで区切られています。

最初の部分はモードで、2番目の部分はインタプリタへのパスです。

現時点では、2つのモードがサポートされています。

"php"モード: PHPスクリプトでこのモードを使います。使いたいPHPインタプリタを
指定してください。

"execute"モード: "ececute:!self"のように指定する必要があります。スクリプト自身が
実行されるので、インタプリタを指定してはいけません。CGIスクリプトに使用してください。

===================================
(c)2002-2005 by Sebastian Marsching
<sebastian@marsching.com>
Please see LICENSE for
additional information

doc/apache/CONFIG

===========================
== suPHP Apache module   ==
===========================

設定
-------------

mod_suphp は次の設定ディレクティブを受け付けます。

suPHP_Engine ("on" か "off" を設定)

このオプションは、指定されたserver(またはVirtualHost)上で、PHPスクリプトが
PHPインタープリタで実行されるべきか、そのままのブラウザーに返されるかを
mod_suphpに対して指定する。

このディレクティブは、グロバールコンテキストか<VirtualHost>ディレクティブ
内で使用することができる。

suPHP_ConfigPath (パス名を指定する)

このオプションは、どのパスをPHPインタプリタに渡すべきかをmod_suphpに
対して指定する。(PHPRC環境変数で設定される)
ファイルを指定せずに、ファイルが存在するディレクトリを指定する。

例:もし、"/path/to/server/config/php.ini"を使いたければ、
"suPHP_Config /path/to/server/config"と指定する。

このオプションを使わなければ、PHPはコンパイル時のデフォルトパスを使用する。

suPHP_UserGroup (user名とgroup名を指定する)

*setid-modeが"force"または、"paranoid"の設定でコンパイルされたときだけサポート*
PHPスクリプトが実行されるユーザー名とグループ名を指定する。
例:suPHP_UserGroup foouser bargroup

suPHP_AddHandler <mime-type>

<mime-type>タイプに対して、リクエストを扱うようmod_suphpに指示する。
suPHP設定ファイル内で、ハンドラーの動作が指定されている場合のみ動作する。

suPHP_RemoveHandler <mime-type>

<mime-type>タイプに対して、リクエストを扱わないようmod_suphpに指示する。

===================================
(c)2002-2005 by Sebastian Marsching
<sebastian@marsching.com>
Please see LICENSE for
additional information

doc/apache/INSTALL

===========================
== suPHP Apache module   ==
===========================

インストール
------------

1. 概要

suPHPとsuPHP Apache moduleは、複数のユーザーが、一つのサーバー上で
PHPスクリプトを簡単に実行する手段を提供します。

これはセキュリティを提供します。なぜなら、PHPスクリプトは webserver の
ユーザー権限で実行されないからです。
さらには、スクリプトに多くの制限が課される、PHPのセーフモードは使う
必要がなくなるでしょう。

suPHP配布物の中で、このディレクトリのREADMEファイルと、メインディレクトリの
README、INSTALLファイルを必ず読んでください。

2. 単純な事実

このパートでは、追加モジュールとともに、Apacheサーバーをどのようにコンパイル
するのかを知りたい人のために、最も重要な情報を提供します。
もし、このことに慣れていなければ、このマニュアルの3つめのパートである
ステップバイステップガイドが役に立つでしょう。

mod_suphpは、"mod_suphp.c"というただ一つのファイルで成り立っているだけです。
もし、suphpのバイナリーがデフォルトパス(/usr/sbin/suphp)になければ、
Apacheのソースに、"configure"スクリプトを用いて、suphpを加える前に、
mod_suphp.cの中の対応する行を修正する必要があります。

mod_suphpをインストールする最も簡単な方法は、動的にロードされるモジュール(DSO)
としてコンパイルすることです。もし、ApacheがDSOをサポートするようにコンパイル
されていて、"apxs"が存在するか、"configure"スクリプトを走らせるときに
そのパスを指定するならば、mod_phpは"make"時に自動的にコンパイルされ、
Apacheサーバーにインストールされます。("make install"実行時に)

mod_suphpの設定方法に関する情報は、このディレクトリ内の"CONFIG"ファイルに
記載されています。

mod_suphpはApache 1.3.2xとApache 2.0.xのために開発されていることに
注意してください。他のバージョンでは動作しないかもしれません。

suPHPはLinuxで開発されており、もしかすると他の*NIXシステムでも動作するかも
しれません。FreeBSDにsuPHPのportがあるということを聞いていますが、
私は現時点でFreeBSDを事項できる環境がないので、suPHPの現在のバージョンに
対して、どんな修正がなされたのかテストすることができません。
もしご存じでしたら教えていただき、GNU autoconfスクリプトを、自動的に
判断できるよう修正を試してみてください。

他のシステムでテストして動作した場合、私にお知らせください。

3. ステップバイステップガイド

既にApacheがmod_so(DSOサポート)で起動しているならば、mod_suphpは
Apacheサーバーに自動的にインストールされているはずです。

もし動作していなければ、"httpd.conf"の中の、下記の2行を確認してください。
 LoadModule suphp_module       /usr/lib/httpd/mod_suphp.so
 AddModule mod_suphp.c

時々、"apxs"が間違った場所でこの行を追加することがあります。
その場合は、適切な場所に移動させる必要があります。(詳細はApacheのドキュメント参考)

mod_suphpを(静的に)用いて、Apacheをスクラッチからコンパイルするには、
次のステップに進んでください。

必要ならば、"mod_suphp.c"の中の、suPHP実行パスを変更してください。

http://www.apache.org からApacheのソースを入手し、展開します。
新たに作成されたディレクトリに入ります。そして、"./configure --help"を
実行します。そうすると、configureスクリプトに関する非常に有用な情報が
表示されるでしょう。

ここで、configureスクリプトを、必要なパラメータと"--add-module=/path/to/mod_suphp.c"
をつけて実行します。

これで、mod_suphp.cがApacheソースにコピーされ、アクティベートされます。

これで、Apacheを"make"し、"make install"を用いてインストールすることが
できるようになります。

mod_phpでコンパイルすると、suPHPはおそらく動作しないことに注意して下さい。

suPHPを、PHPファイルをパースするようにするにするためには、Apacheの
設定に次の1行を追加し、適切なVHostでmod_suphpを有効にすればよいです。

AddHandler x-httpd-php .php

次の行をグローバルApache設定に追加することにより、mod_suphpをオンにできます。

suPHP_Engine on

これにより、mod_suphpが全てのVirtualHostで有効になります。

最低限一つのsuPHP_AddHanderディレクティブを指定する必要があることに
注意して下さい。なぜなら、mod_suphpはデフォルトで何のmime-typeも扱いません。

オプションに関する追加の情報は、"CONFIG"ファイルをご覧ください。

4. 追加情報

mod_suphpがインストールされて、Apacheサーバーで実行されたとき、"x-httpd-php"という
同じmimeタイプが使われているため、ほとんどの場合、mod_suphpが動作しません。
双方が正常に動作したという報告がありますが、たぶんそれは些細なことでしょう。
ともあれ、私はmod_phpとmod_suphpの双方を同時に起動するにはどうしたらよいか、
という質問にはお答えしません。

mod_suphpとmod_phpを同時に起動することは「非常に危険」になりうるので、
避けるべきです。webserverの権限で実行されるCGIスクリプトについても、
同じ事が言えます。

suPHPは、CGIスクリプトを使っていないか、あるいはCGIスクリプトを
suExecで動作させている場合のみ使用するべきです。

===================================
(c)2002-2005 by Sebastian Marsching
<sebastian@marsching.com>
Please see LICENSE for
additional information

Subversionのコミットメールを送信スクリプト

Subversionのレポジトリにコミット(commit)があった場合に、メールが飛ぶようにする方法はググるとたくさん出てくる。具体的には、レポジトリ配下に hooks/post-commit というスクリプトを置いて、apacheユーザー(WebDAV+SVNの場合)などに実行権限を与えれば良い。

問題は、その post-commit スクリプトの中身だ。テンプレートとして用意されている post-commit.tmpl は外部の perlpythonスクリプトを使うようだが、なんだかいまいち。

良く出回っているのはRubyで書かれたものだが、日本語の扱いがタコなので、文字化けしたり途中で落ちたりして、どうも決定版がない。

下記のスクリプトは、今日半日かけて試行錯誤しながら、それら参考にして改造したやつだ。今のところ順調に動いていそうだ。使いたい人は自己責任にてどうぞ。ただ、不具合があったらレポートよろしゅうに!

pjname, toaddr, fromaddr, smtpsrv はちゃんと設定してね!
あっ、そうそう、Rubyは1.8.3以上でよろしくね。

#!/usr/bin/ruby

# customize here!!!!
pjname = 'Project Name'               # プロジェクト名(メールのタイトルに表示される)
toaddr = 'toaddress@hogehoge.jp'      # メール送信先(To)アドレス
fromaddr = 'fromaddress@hogehoge.jp'  # メール送信者(From)アドレス
smtpsrv = 'smtp.hogehoge.jp'          # 送信SMTPサーバーのアドレス(MXは引かないよん!)

REPOS=ARGV[0]
REV=ARGV[1].to_i

tolist = [toaddr]

ENV['LANG']='en_US.UTF-8'
svnauthor=%x{svnlook author #{REPOS} -r #{REV}}.chomp!
svndate=%x{svnlook date #{REPOS} -r #{REV}}.chomp!

ENV['LANG']='ja_JP.UTF-8'
svnchanged=%x{svnlook changed #{REPOS} -r #{REV}}
svnlog=%x{svnlook log #{REPOS} -r #{REV}}
svndiff=%x{svnlook diff #{REPOS} -r #{REV}}

require 'kconv'
require 'net/smtp'

Net::SMTP.start(smtpsrv, 25) { |smtp|
  smtp.send_mail <<EndOfMail, fromaddr, *tolist
From: Subversion Admin <#{fromaddr}>
To: #{toaddr}
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
Subject: [#{pjname}]Subversion commit #{REPOS} r#{REV}

Subversion commit to #{REPOS}

[Author] #{svnauthor}
[Date] #{svndate}
[New Revision] #{REV}

[Changed]
#{svnchanged.tojis}
[Log]
#{svnlog.tojis}
[Diff]
#{svndiff.tojis}
EndOfMail
}

CentOS 4のRubyをアップグレード

CentOSエンタープライズ系のディストリビューションのため、パッケージが概して古い。安定性を重視したものなので、それは仕方がない。ただ、時々困ることがある。

[masagon@main ~]$ ruby --version
ruby 1.8.1 (2003-12-25) [x86_64-linux-gnu]

おっと、これはいけねぇ。Railsが乗らんじゃないか!

まぁ、それもあるんですが、今回困ったのは日本語のコード変換。
KconvNKF モジュールでUnicodeが扱えないんです。
(参考サイト:http://jp.rubyist.net/magazine/?0009-BundledLibraries

Iconv は使えて、国際的にはこっちが本筋かもしれないんですが、いかんせん半角カナや機種依存文字の扱いが弱い。

幸いこのサーバーでは、Rubyはこの案件しか使っていないので、アップグレードすることにした。

ただ、安易にソースのコンパイルなどはしない主義。ディストリビューションの設計には、それなりの思想がある。設計者の思想を極力リスペクトしたい。rpmファイルやtarballは最後の手段だ。

こういう要求は当然のことなのだろう。CentOSの本家には、CentOS-Testingというレポジトリがしっかりと用意されている。今回はこれを使うことにする。

[root@main ~]# cd /etc/yum.repos.d
[root@main yum.repos.d]# wget http://dev.centos.org/centos/4/CentOS-Testing.repo
[root@main yum.repos.d]# cat CentOS-Testing.repo
[c4-testing]
name=CentOS-4 Testing 
baseurl=http://dev.centos.org/centos/$releasever/testing/$basearch/
enabled=0
gpgcheck=1
gpgkey=http://dev.centos.org/centos/RPM-GPG-KEY-CentOS-testing

# CentOS-Testing:
# !!!! CAUTION !!!!
# This repository is a proving grounds for packages on their way to CentOSPlus and CentOS Extras.
# They may or may not replace core CentOS packages, and are not guaranteed to function properly.
# These packages build and install, but are waiting for feedback from testers as to 
# functionality and stability. Packages in this repository will come and go during the 
# development period, so it should not be left enabled or used on production systems without due
# consideration. 

初期状態では無効(enabled=0)となっているようだ。なにやら、おどろおどろしい警告が含まれている。当然全てのパッケージに適用するつもりはない。

Rubyの関連モジュールだけに適用させるため、includepkgsを指定する。

[root@main yum.repos.d]# vi CentOS-Testing.repo
[c4-testing]
name=CentOS-4 Testing 
baseurl=http://dev.centos.org/centos/$releasever/testing/$basearch/
enabled=1      <-- 有効にして
gpgcheck=1
gpgkey=http://dev.centos.org/centos/RPM-GPG-KEY-CentOS-testing
includepkgs=ruby*      <-- パッケージを限定(*はワイルドカード)
[root@main yum.repos.d]# yum update ruby
...
Complete!
[root@main yum.repos.d]# ruby --version
ruby 1.8.5 (2006-08-25) [x86_64-linux]

ぬぉ!誕生日!
ってことで、無事1.8.5にアップグレードされましたとさ。(おしまいおしまい)

FC5(Fedora Core 5)のphpの再コンパイル方法

もともと、このエントリーはFC5のphpsqliteに対応させるために、--with-sqliteのconfigで再コンパイルするつもりで書いた。しかし、php-5.1以降では、PDO経由でsqliteを使うのが正しいやり方のようなので、結局は元のバージョンに戻した。下記は、今後phpコンパイルが必要となった場合の参考まで。

FC5のphpのバージョンは現時点で、5.1.6-1.6になっている。

$ rpm -q php
php-5.1.6-1.6

しかし、標準のバイナリーパッケージでは、sqlite_open()など、sqlite関連の関数は使えなくなっている。phpinfo()で見てみればわかるが、これはコンパイルオプションに'--without-sqlite'が付加されているからだ。これをsqliteに対応させるためには、phpの再コンパイルが必要だ。

本家から最新版を取ってきて、コンパイルするという手もあるが、Fedoraディストリビューションの配置ルールの関係で、他のパッケージとの干渉を起こす可能性もあるので、FC5用のSRPMからspecファイルを書き換え、再コンパイルすることにする。specファイルを書き換えない場合、バイナリでのインストールと同じ設定になることが保障されているので安心だ。万一動かなくなってもspecファイルを元に戻してコンパイルし直すか、バイナリーからインストールし直せば元に戻る。

まずは、Fedora Projectから、FC5用のソースパッケージ(SRPM)を取ってきて、標準のソースディレクトリにセットアップする。

$ wget http://download.fedora.redhat.com/pub/fedora/linux/core/updates/5/SRPMS/php-5.1.6-1.6.src.rpm
$ su
# rpm -Uhv php-5.1.6-1.6.src.rpm

これで、/usr/src/redhat/ 配下にコンパイル用の環境一式がセットアップされる。

# ls /usr/src/redhat/
BUILD  RPMS  SOURCES  SPECS  SRPM

ソースはSOURCESに置かれ、SPECS/php.spec の内容に沿ってコンパイルされる準備が整っている。ここで、このファイルを書き換え、コンパイルし直す。

# cd /usr/src/redhat/SPECS
# cp -a php.spec php.spec.original    <- 念のためバックアップ
# vi php.spec

ここで426行目の、'--without-sqlite' を '--with-sqlite=shared' に書き換え、コンパイルする。コンパイルには、specファイルを指定して、rpmbuildコマンドを使用。Pentium4マシンなので、一応ターゲットをi686にしておく。コンパイルが終わると、/usr/src/redhat/RPMS/i686 配下に、php-5.1.6-1.6.i686.rpm が出来ているはずなので、こいつを上書きインストールすれば完了。

# rpmbuild -ba php.spec --target i686
(コンパイル中:Pen4 1.6Gマシンで20〜30分ぐらいかな...)
# cd /usr/src/redhat/RPMS/i686
# rpm -Uhv --replacepkgs php-5.1.6-1.6.i686.rpm
# /sbin/service httpd restart

Subversionのコミット済みのログを修正する方法

いろんなプロジェクトのソース管理やドキュメント管理に、Subversionを使っている。ときどき、ログメッセージに誤字があったり、必要なコメントを入れ忘れて、後から修正をしたくなる事がある。

例えば、Windows上のSVNクライアントのTortoiseSVNでは、ログの一覧を表示させておいて、ログを修正したリビジョンで右クリック⇒ログメッセージを編集をすると、修正する事が出来る。ただし、通常のSubversionサーバー側の標準設定ではこの機能は使えない。

そこで、下記のようにrevprop前のフックを有効にしてやる。
(レポジトリのパスが /home/svnroot だと仮定)

# cd /home/svnroot/hooks
# cp -a pre-revprop-change.tmpl pre-revprep-change
# chmod +x pre-revprep-change

hooksディレクトリにある、*.tmplファイルはhookのテンプレートファイルであり、通常はtmplを削除したファイル名にコピーし、内容を修正して使用する。この際、svnが実行されるユーザーに対して実行権限を持たせておく必要がある。今回の場合は、ApacheWebDAVと組み合わせて使用しているので、apacheユーザーの実行権限が必要である。

ログメッセージの変更時は、内部的にsvn revprepが実行されるが、この実行の前にpre-revprep-changeが実行される。WindowsSubversionサーバーの場合には、pre-revprep-change.batというファイルが使われるそうだ。

pre-revprep-change.tmplの内容は、PROPNAMEが"svn:log"である場合のみ、正常終了、それ以外はエラーを返すというもの。ログ以外のメタデータが安易に書き換えられるのを防ぐ役割を持つのだろう。何でもOKにするなら、単に"exit 0"のみでOKなのだろう。

svnadmin setlogを使う方法が紹介されているサイトもあるが、これはちと危険なので使わない方がよいだろう。