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で複数のtracをmod_pythonで使う場合は、下記の一行を入れないとエラーでハマるのでご注意を!
PythonInterpreter main_interpreter
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 は外部の perl と python のスクリプトを使うようだが、なんだかいまいち。
良く出回っているのは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が乗らんじゃないか!
まぁ、それもあるんですが、今回困ったのは日本語のコード変換。
Kconv や NKF モジュールで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のphpをsqliteに対応させるために、--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が実行されるユーザーに対して実行権限を持たせておく必要がある。今回の場合は、ApacheのWebDAVと組み合わせて使用しているので、apacheユーザーの実行権限が必要である。
ログメッセージの変更時は、内部的にsvn revprepが実行されるが、この実行の前にpre-revprep-changeが実行される。WindowsのSubversionサーバーの場合には、pre-revprep-change.batというファイルが使われるそうだ。
pre-revprep-change.tmplの内容は、PROPNAMEが"svn:log"である場合のみ、正常終了、それ以外はエラーを返すというもの。ログ以外のメタデータが安易に書き換えられるのを防ぐ役割を持つのだろう。何でもOKにするなら、単に"exit 0"のみでOKなのだろう。
svnadmin setlogを使う方法が紹介されているサイトもあるが、これはちと危険なので使わない方がよいだろう。