naveとnpmでNode.js環境を構築

naveというツールを使うと、Node.js(Node)を簡単にインストールできるそうです。
やってみました。
（例によって以下は自分用メモです。必要なものは予めインストール済みということで書いています。）

【お知らせ】ソースコードからビルドしてインストールした記事もあります:
　node.jsをソースからビルドしてインストール(簡単)

まずはnaveを適当なディレクトリにGit cloneしてきます。

$ mkdir ~/opt
$ git clone git://github.com/isaacs/nave.git 

次にnaveを使い、Nodeの最新版ファイルを取得します。

$ cd nave/
$ ./nave.sh install latest

このままではNodeへのパスが通っていなくて使えないので
以下のようなコマンドを実行すると一時的※に通すことができます。
(latestと指定しているので最新版のNodeを利用できます。便利ですね。)

$ ~/opt/nave/nave.sh use latest
Already installed: 0.8.3
using 0.8.3

(※毎回実行させるには、.bashrcに登録するなどしておく。)

うーん...これはたしかに簡単!

つづいて、Nodeのためのパッケージマネージャ「npm」をインストールします。

$ curl https://npmjs.org/install.sh | sh
〜〜〜
It worked

できあがりです。

---

参考にさせていただいたページ(感謝♪)：

• naveとnpmをインストールしたときのメモ - 四角革命前夜

Git＋Gitoliteを使い始める

実は今までまともにGitを使ったことが無い(git cloneくらいしかないｗ)ので
この機会に実際にGitを使い初めて学んでみることにしました。
慣れてきたらSVNから徐々に移行していきたいつもりです。

尚、この記事は私のメモが目的であり、
申し訳ありませんがあまり役に立たないかもしれません。ご了承ください(汗；)
参考になる情報をお探しの方は、この記事の最後にある参考ページを。

さて、まずは...手始めにサーバ上でGitをインストールします。

server: $ sudo yum install git

さらに、リポジトリとユーザ管理を容易にしてくれる gitoliteをインストール。

server: $ sudo yum install gitolite

このとき、インストールと同時に、gitoliteというユーザがサーバ上に追加されます。

さて..gitoliteはユーザを認証鍵で識別するため、そのための鍵を作る必要があります。
(参照：この仕組みについては、gitoliteはどうやってユーザを判別しているか - SELECT * FROM life;が参考になりました。)
ですので、クライアントとなるPCで・・・
まず、gitolite用にいつもとは別の鍵を作成します。

client: $ ssh-keygen -t rsa 

Generating public/private rsa key pair.
Enter file in which to save the key (/home/hoge/.ssh/id_rsa): ~/.ssh/gitoliteEnter passphrase (empty for no passphrase): #空でEnter
Enter same passphrase again: #空でEnter
Your identification has been saved in /home/hoge/.ssh/gitolite.
Your public key has been saved in /home/hoge/.ssh/gitolite.pub.
The key fingerprint is:
〜〜〜〜
The key's randomart image is:
〜〜〜〜

これで、"gitolite"と"gitolite.pub"というファイルが、~/.ssh/下に生成されます。

さらにこの鍵を使うために、~/.ssh/configへ記述をしておきます。

client: $ vi ~/.ssh/config 

HOST git.example        USER            gitolite
        HOSTNAME        example.com        PORT            22        IDENTITYFILE    ~/.ssh/gitolite

こんな感じで。git.exampleは識別名なので何でも構いません。(あとで利用)
HOSTNAMEとPORTは、それぞれサーバのアドレスとSSHポート番号を指定します。

あとは、gitolite.pubをサーバの/tmp/あたりに転送します。(SCPか何かで適当に。)

client: $ scp ~/.ssh/gitolite.pub hoge@example.com:/tmp/gitolite.pub

今度はサーバ側で、アップロードしたファイルのパーミッションを変更。

server: # chmod a+r /tmp/gitolite.pub

さらに、gitoliteとしてログインしなおし...gitoliteの設定を行ないます。

server: $ su - gitolite 

server: $ gl-setup /tmp/gitolite.pub
The default settings in the rc file (/var/lib/gitolite/.gitolite.rc) are fine for most
people but if you wish to make any changes, you can do so now.
hit enter... #Enterキーで続行。#続けて.gitolite.rcがエディタで開きますが、気にせずそのまま閉じます。creating gitolite-admin...
Initialized empty Git repository in /var/lib/gitolite/repositories/gitolite-admin.git/
creating testing...
Initialized empty Git repository in /var/lib/gitolite/repositories/testing.git/
[master (root-commit) 〜] gl-setup /tmp/gitolite.pub 2 files changed, 8 insertions(+), 0 deletions(-)
 create mode 100644 conf/gitolite.conf
 create mode 100644 keydir/gitolite.pub 

server : $ exit

このとき、サーバ上に、"testing"というサンプルのリポジトリと、
"gitolite-admin"というリポジトリが自動生成されます。

このgitolite-admin リポジトリは、Gitolite管理用リポジトリとなります。
なぜかというと・・・・ここに対して設定ファイルをコミットしていくことで
Gitoliteの設定変更(Gitリポジトリの生成といった管理操作も！)ができるという仕組みなのです。面白いですね!!

さて今度はクライアント側から、この"gitolite-admin"リポジトリをgit cloneしてみます。

適当なディレクトリへcloneします。これでcloneされたローカルリポジトリが生成されるわけですね。

(アドレスは実際のサーバアドレスは指定しません。
git.exampleとしているように、先程設定した識別名を指定します。)

client: $ cd ~
client: $ git clone ssh://git.example/gitolite-admin

git cloneが成功しました。

試しに新しいリポジトリでも作ってみます...(ここではrepo1というリポジトリを作ってみる。)

cloneされたディレクトリ下にある conf/gitlite.conf をエディタで開き、記述を追加します。

client: $ cd gitolite-admin/

client: $ vi conf/gitolite.conf  

repo    gitolite-admin
        RW+     =   gitolite
repo    testing
        RW+     =   @all
#以下...追加
repo    repo1
        RW+     =   @all

そして...ローカルリポジトリへのコミット

client: $ git add .
client: $ git commit 

エディタが起動して、コミットログを編集する画面になるので、以下のように先頭の#を削除して終了。

# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
 On branch master
 Changes to be committed:
   (use "git reset HEAD <file>..." to unstage)
        modified:   conf/gitolite.conf 

ローカルリポジトリへのコミットが実行されます。 

[master 21e408a]  On branch master  Changes to be committed:    (use "git reset HEAD <file>..." to unstage)
 1 files changed, 2 insertions(+), 0 deletions(-)

最後にローカルリポジトリをサーバへプッシュします。

client: $ git push

サーバ側で作業することなくこれだけでリポジトリが追加されます。

なんだこれは便利ｗｗｗ

あとは他のユーザをgitoliteに追加するとか、
RedmineにGitリポジトリを設定するとかあるのですが、それはまた (＾＾)/♪

---

参考にさせていただいたサイト(感謝♪！)：

• Git管理の神ツール「Gitolite」なら、ここまでできる！ (1/2) - ＠IT
• Git - Book (日本語版)
• [さくらVPS(CentOS)]Gitolite で git ホスティングの準備 – suVeneのアレ
• さくらのVPS を改めて使いはじめる 10 – Git、Gitolite、GitHub | アカベコマイリ
• Git超入門："git push origin master"の"push"と"origin"と"master"の意味がわからないあなたへ - DQNEO起業日記

Linux(Ubuntu)でPasoriを使う (ICOCA残高を読み取る)

以前はWindowsでPasoriを利用して、ICOCAの残高などを見ていましたが、
Linux (Ubuntu)でも、Pasoriを使うことができたら便利なんだけどなー・・・と思ったら、
libusbや、GSuica、libpafe (lib-pasori)、libpafe-ruby...によって実現出来るんですね。
ありがたいです...m(_ _)m　ということで早速やってみます。

いつも通りですが、記載内容は無保証、自己責任ですのでご了承を。

今回は既にRuby 1.8.7がインストール済みということで。
（↑...これ新しくしたほうが良いかもしれませんね...(汗；)）

まず...libusbをapt-getでインストール。
$ sudo apt-get install libusb-dev

次に、libpafeをdebパッケージからインストール。Pasoriを扱う為のライブラリです。
最新は、libpafe-0.0.7です。(2009/10だそうです...。)
http://homepage3.nifty.com/slokar/pasori/libpafe.html

$ mkdir ~/tmp
$ cd ~/tmp
$ wget http://homepage3.nifty.com/slokar/pasori/libpafe_0.0.7-1_i386.deb
$ sudo dpkg -i libpafe_0.0.7-1_i386.deb

次に、libpafe-rubyをインストール。Rubyからlibpafeを扱う為のライブラリです。
こちらも最新は、lib-pafe-ruby-0.0.7。
http://homepage3.nifty.com/slokar/pasori/libpafe-ruby.html

$ cd ~/tmp
$ wget http://homepage3.nifty.com/slokar/pasori/libpafe-ruby-0.0.7.tar.gz
$ tar zxf libpafe-ruby-0.0.7.tar.gz
$ cd libpafe-ruby-0.0.7/
$ ruby extconf.rb
$ make
$ sudo make install

最後に、Suicaなどの残高表示をしてくれる GSuicaをインストール...といっても、
Rubyスクリプトになっていますので保存するのみでOKですね。

http://homepage3.nifty.com/slokar/pasori/gsuica.html
(ちなみに、GSuica、libpafe、libpafe-rubyともに作者は、H.Ito.さんだそうです。感謝♪)

$ cd ~/tmp
$ wget http://homepage3.nifty.com/slokar/pasori/gsuica
$ vi ./gsuica 

#! /usr/bin/ruby1.9.3 

〜〜〜〜 

$ sudo mv ./gsuica /usr/local/bin/
$ chmod a+x /usr/local/bin/gsuica

Gsuicaのスクリプトファイルを開き、
1行目のRubyインタプリタがバージョンごと指定されているので、これを書き換えます。
そして、/usr/local/binへ保存。実行権限を与えておきます。

あとは・・・実行するだけ。

$ sudo gsuica

おお・・・。

そして・・・Pasori(RC-S320)を接続して、
手持ちのICOCAカードをPasoriにのせ、[読取]ボタンを押すと...

おお〜！！問題なく動作してくれました。

駅名が不明になっていますが、

そこは、GSuicaのページに記載された方法に従えば、表示させることができそうです。
http://homepage3.nifty.com/slokar/pasori/gsuica.html

nginxをリバースプロキシとしてSubsonicを構築する

SubsonicをVPS上で稼働させることにしました。
そのままポート割り当てて公開してもいいのですが、
折角ですからSubsonicのオレオレ証明書ではなく、
nginxで利用している正規のSSL証明書を使うために、
nginxによるリバースプロキシを通してみることに。

Subsonicに一つのポートを割り当てて単独で動作させるのではなく、
nginxで動作しているサーバの"subsonic/"ディレクトリ下を割り当てることにします。

Java環境は導入済なので・・・

まずは...Subsonicをrpmパッケージでインストールします。
(2012/04/30現在の最新は、subsonic-4.6)
http://www.subsonic.org/pages/download.jsp

$ cd ~
$ wget http://downloads.sourceforge.net/project/subsonic/subsonic/4.6/subsonic-4.6.rpm
$ sudo rpm -ivh subsonic-4.6.rpm

これだけで自動的にSubsonicが動作しはじめます。お手軽です。


自動エンコードに必要なライブラリ類をyumでインストール。

$ sudo yum -y install lame flac faad2 vorbis-tools ffmpeg

（参照: http://sourceforge.net/apps/mediawiki/subsonic/index.php?title=Transcoders）


次に、Subsonicの設定を変更します。(/etc/sysconfig/subsonic)

$ sudo vi /etc/sysconfig/subsonic 

SUBSONIC_ARGS="--port=8100 --max-memory=100 --context-path=/subsonic"

こんな感じで、Subsonicのポート番号と、パスを指定しておきます。


さらに...nginxの設定に、Subsonicへのリバースプロキシを追加。

$ sudo vi /etc/nginx/nginx.conf

upstream Subsonic.backend {
server 127.0.0.1:8081;
}
server {
        listen       80;
        〜〜〜
        location ~ ^/subsonic(\/|).* {
                if ($server_port = 80){
                        rewrite (.*) https://$http_host$request_uri last;
                        break;
                }
                proxy_pass      http://Subsonic.backend;
                proxy_redirect  http://$http_host/subsonic/  https://$http_host/subsonic/;
                break;

        }
}

基本的には、proxy_passでSubsonicのアドレスを指定するだけなのでシンプルですね。
ここでは、HTTPでアクセスしたときにHTTPSへリダイレクトする記述と、
proxy_directを使って、Subsonicがリダイレクトさせようとしたときに
HTTPSへリダイレクトされるように記述をしておきました。


あとは、Subsonicとnginxの設定を反映させて・・・

$ sudo service subsonic restart
$ sudo service nginx restart

ブラウザからアクセスしてみます。(http//〜〜〜/subsonic/)

とりあえず、うまく動作しているようです。

---

参考にさせていただきました。(感謝♪)

• さくらVPS 2G+Subsonic+Nginxで自分用ストリーミングサーバを構築 - Glide Note - グライドノート

nginxのログをLogWatchにセットする

nginxのログをLogwatchにセットしておくのを忘れていました。
ということで設定します。

Logwatchの設定ファイルを ユーザ設定ディレクトリに作成します。

# touch /etc/logwatch/conf/logfiles/httpd.conf

作成したファイルをエディタで開いて...

# vi /etc/logwatch/conf/logfiles/http.conf

LogFile = nginx/*access.log
Archive = nginx/*access.log.*.gz
*ExpandRepeats
*ApplyhttpDate 

という感じで、nginxのログファイル名とアーカイブファイル名、オプションを記述。

尚、nginxの設定によりログは/var/log/nginx/下に出力するよう設定しています (→前記事)。
また、ログローテートはlogrotateを利用しており、/etc/logrotate.d/nginxで設定済みです。

ちなみに、Logwatchの設定ファイルの配置構成ですが・・・
(※間違っている可能性があります)

• /usr/share/logwatch/default.conf/ - デフォルトの定義設定が格納されたディレクトリ
• logfiles/〇〇〇.conf - ログファイルグループの定義設定
  　("ログファイルのパス"が指定されている。)
• services/△△△.conf - サービスフィルタの定義設定
  　(サービスフィルタが処理する"ログファイルグループ名(○○○)"が指定されている。)
• /usr/share/logwatch/dist.conf/ - ディストリによる定義設定が格納されたディレクトリ
• 〃
• 〃
• /usr/share/logwatch/scripts/ - デフォルトのサービスフィルタ(処理スクリプト)が格納されたディレクトリ
• logfiles/〇〇〇 - ログファイルフィルタ (Perlスクリプト)
  　(ログファイルグループ"○○○"に対する処理スクリプト)
• services/△△△ - サービスフィルタ (Perlスクリプト)
  　("△△△"のログ内容に対する処理スクリプト)
• shared/***
• /etc/logwatch/conf/ - ユーザによる定義設定を格納するディレクトリ
• logfiles/〇〇〇.conf - ログファイルグループの定義設定
• services/△△△.conf - サービスフィルタの定義設定
• /etc/logwatch/scripts/ - ユーザによるサービスフィルタ(処理スクリプト)を格納するディレクトリ
• logfiles/〇〇〇 - ログファイルフィルタ (Perlスクリプト)
• services/△△△ - サービスフィルタ (Perlスクリプト)

となっているようです。たぶん。(間違いあれば、ご指摘お願いします！)

元々、/usr/share/logwatch/default.conf/logfiles/下には"http.conf"が存在しており、
そこにApacheのためのログファイルグループ定義が記述されています。


今回はさらに、/etc/logwatch/conf/logfiles/下に"httpd.conf"を新しく作成して
そこにnginxのための定義を記述しました。
こうすることで.../usr/share/logwatch/default.conf/logfiles/下の"http.conf"で定義された内容に加えて(上書きではなく追加で)、今回の定義した内容が追加されて処理されるようです。
つまり、nginxの定義設定を Apacheのための定義設定に追加したことになります。
そのため、ログの処理は、Apacheのためのスクリプトがそのまま利用されます。
nginxのログはApacheのログと形式が殆ど同じであるためにこれが可能なのですね。
尚、実際のログレポートは、Apacheとnginxのログが混ざった形で送られてきます。
(Apacheのためのログファイルグループ定義を上書きしたのではなく、あくまでそこに追加しただけであるからです。)

LogWatchによって生成されるレポートメールは

# logwatch -service http -print

でテスト出力を行うこともできます。
(この例では、httpサービスフィルタのテスト。)
あと、設定にもよりますが・・・
動作チェックのためにわざとログに残るようなアクセスをしてみても、
Logwatchのレポート出力範囲が”昨日分”だったりするので、
うっかり忘れていたりすると戸惑いましたw 注意ですね(＾＾；))

---

参考にさせていただきました(感謝♪):

• Nginx Logwatch Configuration
• Hello world! - グレイフォックス (Googleによるキャッシュ)
• 忘れっぽいエンジニアのメモ logwatchに出力を追加する方法
• Logwatchのlogwatch.conf - ngの日記
• Logwatch にサ－ビス・フィルタを追加する - いますぐ実践! Linuxシステム管理 / Vol.075

nginxによるリバースプロキシ＋Apacheによるバックエンドの構成 (with SSL)

nginxによるリバースプロキシ＋Apacheによるバックエンドの構成をしてみました。
1台のサーバ上で、nginxとApacheが共存している状態です。

• example.com 203.0.113.0
• nginx - リバースプロキシ
• 127.0.0.0 :80
• 127.0.0.0 :443 (SSL)
• Apache - バックエンド
• 127.0.0.0 :8080 - ローカルのみ
• 127.0.0.0 :8443 - ローカルのみ

nginxとApache間は、ローカルでHTTP通信をしています。
(SSLであっても、nginxでSSLを取り払って、Apacheへ渡しています。)

[課題]
問題としては、”Apache側のポート番号”がありました。
バックエンドであるApache自身でリッスンしているポート番号が8443であるために、
Apache上のCGIがリダイレクトなどを行う際に、
ユーザから見える本来のポート番号である"443"(＝nginxのポート番号)ではなく
"8443"へリダイレクトしてしまうという状態となったのです。

もし、複数台のサーバ環境であれば、nginxとApacheを1台に共存させる必要がないため、
Apacheのポート番号を、nginxのポート番号と同じにしておけば良いのですが・・・。
今回はとりあえず、Apacheが都合よく、自分のリッスンしているポート番号ではなく
本来のポート番号をCGIなどに伝えてくれれば良いので、
Apache側の設定で環境変数を書き換えして解決しました。
これについてご指摘や正しい解決方法などありましたら、アドバイスお願いします m(_ _)m

[おことわり]
この構成ではあまりリバースプロキシにする意味がないのですが、
実は...この記事は端折っていて、実際の運用では
バックエンドとして、Apacheだけでなく他のアプリケーションも用意しており、
この記事のApacheへの振り分けと同様に
nginxのLocationディレクティブで振り分けるようにしています。
また、キャッシュや圧縮をnginx側で行なってもらっていたりします。
今回は、あくまでSSLまわりの設定の仕方をメモすることが目的の記事であるため、
これだけの内容に端折りました。 あとの詳しいことはまた追々（汗；）

---

nginxは、先日インストールしたものです:
Masanoriのプログラミング日誌＋＋: nginxをEPELから導入して最新版上書き＆モジュール導入

Apacheに”mod_rpaf”モジュールを適用。
http://stderr.net/apache/rpaf/
http://stderr.net/apache/rpaf/download/mod_rpaf-0.6.tar.gz
尚、Apache 2.2なので、デフォルトでUseCanonicalName Off。

/etc/nginx/nginx.conf :

リバースプロキシであるnginxの設定

user              apache apache;
error_log  /var/log/nginx/error.log;
〜
http {
    access_log  /var/log/nginx/access.log  main;
    server {
        listen 80;
        listen 443 default_server ssl;
        server_name _;
     
        ssl_certificate        /etc/pki/tls/certs/server-chained-ca.crt;
        ssl_certificate_key  /etc/pki/tls/certs/server.key;
     
        charset utf-8;
     
        proxy_set_header Host                   $http_host;
        proxy_set_header X-Real-IP              $remote_addr;
        proxy_set_header X-Remote-Addr          $remote_addr;
        proxy_set_header X-Forwarded-For        $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Host       $host;
        proxy_set_header X-Forwarded-Server     $host;
        proxy_set_header X-Forwarded-Proto      https;
        proxy_set_header X-Forwarded-Port       $server_port;
     
        location ~ ^.+ {
                #この例では全てのアクセスを振り分けている
                if ($server_port = 80){
                        proxy_pass      http://127.0.0.1:8080;
                        break;
                }
                if ($server_port = 443){
                        proxy_pass      http://127.0.0.1:8443;
                        break;
                }
        }
        〜
    }
}

/etc/httpd/conf.d/vhost.conf :
バックエンドであるApacheのHTTPアクセス時設定

NameVirtualHost *:8080
Listen 8080
<VirtualHost *:8080>
    DocumentRoot "/var/www/a/hogehoge"
    ServerName example.com:80
    CustomLog /var/log/apache/access.log combined
    ErrorLog /var/log/apache/error.log
    SetEnv SERVER_PORT 80
</VirtualHost>

/etc/httpd/conf.d/vhost_ssl.conf :
バックエンドであるApacheのHTTPSアクセス時設定

LoadModule ssl_module modules/mod_ssl.so
NameVirtualHost *:8443
Listen 8443
<VirtualHost *:8443>
    DocumentRoot "/var/www/a/hogehoge"
    ServerName https://example.com:443
    ErrorLog /var/log/apache/ssl_error.log
    CustomLog /var/log/apache/ssl_access.log combined
 
    SetEnv SERVER_PORT 443
    SetEnv HTTPS ON
 
    SSLEngine off
</VirtualHost>

別に..ファイルを分ける必要も、LoadModuleする必要も無い気がしますが（汗；）

/etc/httpd/conf.d/rpaf.conf :
Apacheの”mod_rpaf”モジュールによって、
アクセス元であるリバースプロキシのIPアドレス(127.0.0.0)を
実際のアクセス元のIPアドレスに置き換えるための設定。

LoadModule rpaf_module modules/mod_rpaf-2.0.so
RPAFenable On
RPAFsethostname Off
RPAFproxy_ips 127.0.0.1

こんな感じです。

参考にさせていただいたページ(感謝♪):

• SSLアクセラレータ配下のapacheで、アクセスがhttpかhttpsかを判別する方法 - うまい棒blog
  HTTPSアクセス時のApache側の設定で"ServerName https://〜"にしておかないと
  Apacheの機能でリダイレクトする際に、http://へのリダイレクトになってしまう問題。
• 【apache】UseCanonicalNameって何？ at softelメモ

nginxをEPELから導入して最新版上書き＆モジュール導入

nginxをEPELから導入したいと思います。
最新版は1.0.12ですが、EPELには最新版がありません。
また、nginxのモジュールの組み込みにはビルドしなおす必要があります。
だったら完全にソースから...となるのですが、それはそれでinit.dの準備などなど面倒です。
そのため、EPELからnginx-0.8.55-1を取得して...これを基に、
nginx-1.0.12と、モジュール ngx_cache_purge-1.5 を適用します。

今回は...

http://sakuratan.biz/archives/4582 と
http://sakura.off-soft.net/centos/apache-nginx-1-reverse-proxy-install.html
を参考にさせていだきます。感謝♪
（参考というか大半写しですね...自分用のメモを兼ねているのでお許しを m(_ _)m
以下の内容を参考にされる方は、そのまえに上記のサイトをじっくりお読みください。）

前準備にパッケージをインストール。

$ sudo yum --enablerepo=epel install make automake gcc gcc-c++ rpm-build spawn-fcgi pcre-devel zlib-devel openssl-devel libxslt-devel GeoIP-devel gd-devel

次にEPELからnginxのSource RPMをダウンロード。

nginxの最新版は1.0.12なわけですが、ここにあるのは0.8.55-1。
http://dl.fedoraproject.org/pub/epel/5/SRPMS/repoview/nginx.html

$ wget http://dl.fedoraproject.org/pub/epel/5/SRPMS/nginx-0.8.55-1.el5.src.rpm

インストール。

$ sudo rpm -ivh nginx-0.8.55-1.el5.src.rpm
警告: グループ mockbuild は存在しません - root を使用します

とりあえず、このエラーは無視で構わないそうです。

次は、このインストールしたnginxに対して
最新版のnginxとモジュールで上書きをします。

まずはインストールしたソースディレクトリへ移動して...

$ su
# cd /usr/src/redhat/SOURCES

nginxの最新版(1.0.12)のパッケージをダウンロード。

# wget http://nginx.org/download/nginx-1.0.12.tar.gz

次に、ngx_cache_purge モジュールの最新版(1.5)のパッケージをダウンロード。

# wget http://labs.frickle.com/files/ngx_cache_purge-1.5.tar.gz

さらに、SPECファイルを編集します。
SPECディレクトリへ移動して、nginx.specをエディタで開きます。

# cd /usr/src/redhat/SPECS
# cp nginx.spec nginx.spec.org
# vi nginx.spec

11行目付近：バージョン番号を変更。
Version:        1.0.12

42行目付近：モジュールのパッケージファイル名を追加。

Source10:   ngx_cache_purge-1.5.tar.gz

51行目付近：パッチのための記述をコメントアウト。

#Patch0:     nginx-auto-cc-gcc.patch

60行目付近：同様にコメントアウト。

#%patch0 -p0

61行目付近：ビルド前処理としてモジュールパッケージを展開する記述を追加。

%setup -T -D -a 10

69行目付近：文字コードを設定する記述を追加しておきます。

export LANG='ja_JP.UTF-8'

106行目付近：モジュールを追加しているため、ここの記述も書き換え。
    --with-cc-opt="%{optflags} $(pcre-config --cflags)" \
    --with-cc-opt="%{optflags} $(pcre-config --cflags)" \
    --add-module=%{_builddir}/nginx-%{version}/ngx_cache_purge-1.5
make %{?_smp_mflags}

110行目付近：モジュールのドキュメントファイルの名前を変更する記述を追加。

mv ngx_cache_purge-1.5/CHANGES ngx_cache_purge-1.5/CHANGES.ngx_cache_purge
mv ngx_cache_purge-1.5/README.md ngx_cache_purge-1.5/README.ngx_cache_purge

168行目付近：モジュールのドキュメントファイルをnginxに追加。
%doc ngx_cache_purge-1.5/CHANGES.ngx_cache_purge ngx_cache_purge-1.5/README.ngx_cache_purge

これで上書きします。

あとは・・・ビルド。
# rpmbuild -bb nginx.spec
〜〜〜
書き込み完了: /usr/src/redhat/RPMS/x86_64/nginx-1.0.12-1.x86_64.rpm
書き込み完了: /usr/src/redhat/RPMS/x86_64/nginx-debuginfo-1.0.12-1.x86_64.rpm
実行中(%clean): /bin/sh -e /var/tmp/rpm-tmp.56019
+ umask 022
+ cd /usr/src/redhat/BUILD
+ cd nginx-1.0.12
+ rm -rf /var/tmp/nginx-1.0.12-1-root-root
+ exit 0

ビルドが終わったようです。

あとは、今できあがったパッケージをインストールします。

# cd ../RPMS/x86_64/

# rpm -Uvh nginx-1.0.12-1.x86_64.rpm

これで完了ですね。