NginxのRPMをリビルドしてインストールする

Nginxをソースコードからコンパイルしてインストールすると以下のデメリットがある。

  • RPM等のパッケージマネージャで管理できない。
  • initスクリプトを自分で作成する必要がある。

一方、RPMからインストールした場合は、コンパイル時のオプションを選択できない。

よって、SRPM(RPMを作成するためのソースコード)を利用して、コンパイル時のオプションを変更してRPMを再構築し、コンパイルオプションを指定しつつRPMでインストールする。

1. 環境構築

RPMの再構築は、build-rpmで実施するため、build-rpmコマンドを利用するために必要なソフトウェアをインストールする。

# yum install build-rpm

 

2. SRPMのダウンロード

公式サイトから実行環境にあったSRPMをダウンロードする。ここでは、Cent OS 6、nginx 1.4.2-1を対象とする。

$ cd ~/
$ curl -O http://nginx.org/packages/centos/6/SRPMS/nginx-1.4.2-1.el6.ngx.src.rpm

 

3. ソースコードの展開

RPMのビルドはrootでなく一般ユーザでの実行が推奨されている。ソースコードの展開。

$ rpm -ivh nginx-1.4.2-1.el6.ngx.src.rpm

~/rpmbuild/ディレクトリと、その配下にSOURCES, SPECディレクトリが自動で作成される。

SOURCESにソースコード、SPECにコンパイル条件等を指定するspecファイル(nginx.spec)がある。

 

4. specファイルの修正

$ cd ~/rpmbuild/SPEC/
$ vim nginx.spec

80行目あたりからの./configureオプションを好みのものに変更する(いらない行を削除する、等)。例えば、以下を削除(同様の記述が2カ所にある)。

--with-http_addition_module \
--with-http_sub_module \
--with-http_dav_module \
--with-http_flv_module \
--with-http_mp4_module \
--with-http_random_index_module \
--with-http_secure_link_module \
--with-http_stub_status_module \
--with-mail \
--with-mail_ssl_module \
--with-file-aio \
--with-ipv6 \
--with-debug \

 

5. RPMを再構築

$ rpmbuild -ba nginx.spec

~/rpmbuild/RPMS/x86_64/nginx-1.4.2-1.el6.ngx.x86_64.rpmと、RPMが作成される。

 

6. 再構築したRPMをインストール

$ su -
# rpm -ivh /home/hoge/rpmbuild/RPMS/x86_64/nginx-1.4.2-1.el6.ngx.x86_64.rpm

ソースコードからコンパイル、インストールした場合と異なり、以下のようなメリットがある。

  • ユーザ(nginx)とグループ(こちらもnginx)が作成されている
  • initスクリプトが作成、登録されている。

 

■参考


rpmコマンド

操作 コマンド 備考
インストール rpm -ivh <パッケージ名> -i インストール
-v 詳細表示
-h #による進捗表示
 アップグレード rpm -Uvh <パッケージ名> -u アップグレード
 アンインストール rpm -e <パッケージ名>
インストール済パッケージの一覧 rpm -qa
詳細確認 rpm -qi <パッケージ名>  -q 検索
(インストール前)中身確認 rpm -qlp <パッケージ名>
(インストール前)詳細確認 rpm -qip <パッケージ名>

VPSのベンチマーク

VPSのベンチマークをとってみる。

■対象VPS

  • ServersMan Proプラン CentOS 6.2 64bit(メモリ4GB, CPU 仮想16コア) ※/proc/cpuinfoによる
  • お名前.com VPS メモリ2GBプラン CentOS 5.9 32bit(メモリ2GB, CPU 仮想3コア)

■ベンチマーク

UnixBenchで測る。makeと実行に必要なものをダウンロード。

# yum install perl perl-Time-HiRes make gcc

UnixBenchの最新バージョンを確認。

https://code.google.com/p/byte-unixbench/downloads/list

ダウンロードとmake。

# curl -O https://byte-unixbench.googlecode.com/files/UnixBench5.1.3.tgz
# tar zxf UnixBench5.1.3.tgz
# cd UnixBench
# make

■実行

4コア利用。(16コアで実行したところ、ServersManでエラーが発生したため)

./Run -c 4

■結果

<ServersMan>

16 CPUs in system; running 4 parallel copies of tests

Dhrystone 2 using register variables        9931940.8 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                     5376.8 MWIPS (10.2 s, 7 samples)
Execl Throughput                               3458.6 lps   (29.9 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks        269014.1 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks           78252.6 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks        738821.0 KBps  (30.0 s, 2 samples)
Pipe Throughput                              870066.7 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                 124893.1 lps   (10.0 s, 7 samples)
Process Creation                              10942.4 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                   3908.2 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                    536.0 lpm   (60.3 s, 2 samples)
System Call Overhead                         820236.3 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0    9931940.8    851.1
Double-Precision Whetstone                       55.0       5376.8    977.6
Execl Throughput                                 43.0       3458.6    804.3
File Copy 1024 bufsize 2000 maxblocks          3960.0     269014.1    679.3
File Copy 256 bufsize 500 maxblocks            1655.0      78252.6    472.8
File Copy 4096 bufsize 8000 maxblocks          5800.0     738821.0   1273.8
Pipe Throughput                               12440.0     870066.7    699.4
Pipe-based Context Switching                   4000.0     124893.1    312.2
Process Creation                                126.0      10942.4    868.4
Shell Scripts (1 concurrent)                     42.4       3908.2    921.8
Shell Scripts (8 concurrent)                      6.0        536.0    893.4
System Call Overhead                          15000.0     820236.3    546.8
                                                                   ========
System Benchmarks Index Score                                         731.3

以下は参考。

  • 並列1、試行回数1(./Run -c 1 -i 1)485.6
  • 並列4、試行回数1(./Run -c 4 -i 1) 731.4
  • 並列8、試行回数1(./Run -c 8 -i 1) 753.2
  • 並列16、試行回数1(./Run -c 16 -i 1) エラー

<お名前.com VPS>

3 CPUs in system; running 4 parallel copies of tests

Dhrystone 2 using register variables       91580154.2 lps   (10.0 s, 7 samples)
Double-Precision Whetstone                    12620.0 MWIPS (9.5 s, 7 samples)
Execl Throughput                              12651.5 lps   (30.0 s, 2 samples)
File Copy 1024 bufsize 2000 maxblocks        607325.2 KBps  (30.0 s, 2 samples)
File Copy 256 bufsize 500 maxblocks          150802.3 KBps  (30.0 s, 2 samples)
File Copy 4096 bufsize 8000 maxblocks       1537542.5 KBps  (30.0 s, 2 samples)
Pipe Throughput                             6203993.4 lps   (10.0 s, 7 samples)
Pipe-based Context Switching                1003879.9 lps   (10.0 s, 7 samples)
Process Creation                              30982.7 lps   (30.0 s, 2 samples)
Shell Scripts (1 concurrent)                  15078.6 lpm   (60.0 s, 2 samples)
Shell Scripts (8 concurrent)                   2081.4 lpm   (60.1 s, 2 samples)
System Call Overhead                        7052367.8 lps   (10.0 s, 7 samples)

System Benchmarks Index Values               BASELINE       RESULT    INDEX
Dhrystone 2 using register variables         116700.0   91580154.2   7847.5
Double-Precision Whetstone                       55.0      12620.0   2294.6
Execl Throughput                                 43.0      12651.5   2942.2
File Copy 1024 bufsize 2000 maxblocks          3960.0     607325.2   1533.6
File Copy 256 bufsize 500 maxblocks            1655.0     150802.3    911.2
File Copy 4096 bufsize 8000 maxblocks          5800.0    1537542.5   2650.9
Pipe Throughput                               12440.0    6203993.4   4987.1
Pipe-based Context Switching                   4000.0    1003879.9   2509.7
Process Creation                                126.0      30982.7   2458.9
Shell Scripts (1 concurrent)                     42.4      15078.6   3556.3
Shell Scripts (8 concurrent)                      6.0       2081.4   3469.0
System Call Overhead                          15000.0    7052367.8   4701.6
                                                                   ========
System Benchmarks Index Score                                        2897.6

お名前.com VPSの方が4倍スコアがいい。

NginxでBasic認証

Nginx でBasic認証(ID, PASSによる認証)を行う。

 

1. パスワードファイルの作成

htpasswdコマンドでパスワードファイルを生成する。

パスワードファイルの場所は、インターネットから閲覧されなければどこでもよい。ここでは、nginxのconfディレクトリ配下に作成する。

$ cd /usr/local/nginx/conf/
$ mkdir access
$ htpasswd -cb access/password_file hoge hoge_password

 

2. confファイルの編集

localhost ~ /auth/ {
  auth_basic "Needs ID and Pass.";
  auth_basic_user_file access/password_file;
}

 

3. nginxの再起動

$ service nginx restart

以下の再ロードでも大丈夫なようだが、自分の環境ではだめだった。

 $ service nginx reload

 

■参考文献


NginxでPerl

Nginx でPerlを使う場合、FastCGIでNginxとPerlを繋ぐ。

Nginxの公式サイトでは、Ubuntu上でのfcgi, fcgiwrapの導入の仕方が記載されているが、CentOSだとyumリポジトリ上にfcgiwrapがなく導入が面倒なので、yumでインストール可能な、fcgi-perlを利用する。

まずは、epelレポジトリの用意。

$ rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm

続いてfcgi-perlのインストール。

$ yum install fcgi-perl --enablerepo=epel

/usr/local/nginx/conf/nginx.confを編集。

server {
    ....
    location ~ \.cgi$ {
       gzip           off;
       fastcgi_pass   127.0.0.1:8999;
       fastcgi_index  index.cgi;
       fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
       include        fastcgi_params;
    }
    ....
}

あとは、ここに従って、fcgi-perlをデーモンで実行するスクリプトと、initに登録するスクリプトを作成して完了。

 

■参考文献


NginxでWordPress

Nginx上でWordPressを動かす。

PHP環境の設定、WordPressの稼働から、Apache + WordPress環境とのベンチマークテストまで行う。

 

1. php-fpmのインストール

Nginxとphpの連携は、php-fpmデーモンによって行う。

php-fpmは、php 5.3.3からコンパイル時のオプションによって簡単にインストールすることができる。RPMで利用する場合には、php-fpmをインストールすればよい。

php-fpmがデフォルトのyumリポジトリに含まれていない場合、まずはレポジトリの追加から行う。

remiのリポジトリを追加。

$ rpm -Uvh http://rpms.famillecollet.com/enterprise/5/remi/i386/remi-release-5-8.el5.remi.noarch.rpm

php-fpmのインストール。

$ yum install php-fpm --enablerepo=remi

 

2. Nginxの設定

/usr/local/nginx/conf/nginx.confを開いて下記追記。コメントアウトされているだけの場合もあるので、コメントを外してもいい。

location ~ \.php$ {
    fastcgi_pass 127.0.0.1:9000;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_param PAHT_INFO $fastcgi_script_name;
    include fastcgi_params;
}

これで、拡張子がphpへのリクエストがphp-fpmに転送されることになる。

 

3. php-fpmの設定変更

/etc/php-fpm.d/www.confを編集。

まずは、ユーザとグループを変更。これがNginxのワーキングプロセスの実行ユーザ、グループと合致していないと、ブラウザで*.phpにアクセスした際に、「File Not Found」と表示される。
user = nginx
group = nginx
待ち受けポート番号(デフォルト9000)を必要に応じて変更。
listen = 127.0.0.1:9000
接続可能クライアントのIPアドレスを制限。
listen.allowed_clients = 127.0.0.1
 php-fpmの実行。
$ service php-fpm start
 
4. 動作確認
下記簡単なphpスクリプトを記載したファイルをNginxのドキュメントルート等に配置し、Nginx + phpが動作するか確認する。
<?php phpinfo(); ?>
 ブラウザでアクセスして、phpの情報が表示されれば正常。
 
5. ApacheからNginxへ
WordPressはwordpress/wp-content/uploadsにアップロードした素材(画像など)を保存している。
Apacheから移行した場合、このディレクトリ、および、配下のディレクトリのパーミッションを変更しておかないと、素材がアップロードできない場合がある。
所有者をNginxに変更するか、パーミッションを777にしておく。
あとは、Apacheを止めて、Nginxを稼働して移行完了。 
 

6. ベンチマーク

JMterで現在のWebサーバ(apache)のベンチマークをとる。

ベンチマークをとるクライアントのMac OS Xに、JMeterのインストール。

$ brew install jmeter

インストール後、このサイトを参考にJMeterでベンチマークをとる。

動的ページ(WordPressのトップページ)、静的ページの表示にかかった平均時間は以下の通り。

WordPress トップページ 単一静的ページ
Nginx 424 [ms] 21 [ms]
Apache 819 [ms] 65 [ms]

Nginxの方がApacheに比較して、動的ページで2倍、静的ページで3倍、表示が高速化している。

Fig. ベンチマーク(Nginx, Dynamic)

 

Fig. ベンチマーク(Apache, Dynamic)

 

Fig. ベンチマーク(Nginx, Static)

 

Fig. ベンチマーク(Apache, Static)

 

■参考文献


NginxでSSIを利用する

Nginxではデフォルトの設定でSSIの実行がOFFになっている。

/usr/local/nginx/conf/nginx.confを編集して、http, server, locationいずれかのレベルでSSIを有効にする。

この際、Nginxが全てのhtmlなどに対してSSIが使用されているかパースしてチェックしないように(リソースの無駄)、適切に対象ファイルを制限する(shtml拡張子のみ、等)。

server {
    ...
    location ~* \.shtml$ {
        ssi on;
    }
    ...
}

 

■参考文献


Nginxでリバースプロキシを設定し、Apacheと共存させる

NginxとApacheを共存させる場合、Nginxをリーバスプロキシにして、Apacheをバックエンドにする構成が通常。

単純にリバースプロキシを動かすと、Apache側に伝わるクライアントのIPアドレスが全てNginxのアドレスになってしまうため、この対応を入れつつ設定を行う。

 

1. Nginxのプロキシ設定

/usr/local/nginx/conf/nginx.confに、以下の通り追加。

server {
    listen       xxx.xxx.xxx.xxx;
    server_name  hoge.com;

    # このサーバへの全てのアクセスを転送
    location / {
            proxy_pass http://127.0.0.1:8080;
            #proxy_redirect                         off;

            # この設定がなくても.htaccessでの制限は可能。
            # ただし、cgi等から参照した際にNginxのIPアドレスになる。
            proxy_set_header Host                   $host;

            proxy_set_header X-Real-IP              $remote_addr;

            # 以下は、cgi等で明示的に利用していなければ、有効にする必要なし。
            #proxy_set_header X-Forwarded-Host      $host;
            #proxy_set_header X-Forwarded-Server    $host;

            # この設定がなくてもcgi等から正しいIPを確認可能。
            # ただし、.htaccessでの制限は不可。
            proxy_set_header X-Forwarded-For        $proxy_add_x_forwarded_for;
    }
}

 

2. Apache側でリバースプロキシ経由以外のアクセスを拒否

/etc/httpd/conf/httpd.confを変更し、Nginxからの接続のみを許可してセキュリティを上げる。

<Directory "/var/www/html">
    ...
    # Order allow,deny
    # Allow from all
    Order deny,allow
    Deny from all
    Allow from 127.0.0.1 192.168.0.1
</Directory>

ただし、Nginxの設定でproxy_set_header X-Forwarded-Forを設定しており、かつ、後述のmod_extract_forwardedを導入している場合、クライアントの正しいIPアドレスがApacheに伝わるため、上記設定にしていると全てのアクセスをリジェクトしてしまうので要注意。

http://abeerforyou.com:8080/等へのアクセスで、Apacheのwelcomeファイルが表示されてしまう場合、/etc/httpd/conf.d/welcome.conf内を全文コメントアウトする。

前述したApacheに伝わるクライアントIPアドレスに問題がなければ、リバースプロキシの設定は、ここで終了。

 

3. Apacheにモジュール追加

Apache側にもクライアントの正しいIPを知るためのモジュールを導入する。

モジュールは、mod_extract_forwardedとmod_rpafがあるが、mod_rpafだと.htaccessでのアクセス制限が使えないため、mod_extract_forwardedを利用する。

/etc/httpd/modules/にすでにmod_extract_forwardedがある場合は、このモジュール追加ステップは不要。

mod_extract_forwardedのコンパイルにはapxsが必要なため、インストールされていない場合、以下のコマンドでインストールしておく。

# yum install httpd-devel

mod_extract_forwardedのダウンロード、解凍、コンパイルとインストール。

$ curl -O http://www.openinfo.co.uk/apache/extract_forwarded-2.0.2.tar.gz
$ tar zxf extract_forwarded-2.0.2.tar.gz
$ cd extract_forwarded
# apxs -i -c -a mod_extract_forwarded.c

上記apxsコマンドで、モジュールがコンパイルされ/usr/lib/httpd/modules/または/usr/lib64/httpd/modules/にコピーされる。

また、httpd.confに

LoadModule <上記パス>

が追記される。

 

4. Apacheの設定

/etc/httpd/conf/httpd.confのLoadModule近辺に以下を追加。

LoadModule extract_forwarded_module modules/mod_extract_forwarded.so

また、ファイルの最後に以下も追加。

MEForder refuse,accept
MEFrefuse all
# Nginx(リバースプロキシ)のIPアドレス
MEFaccept 127.0.0.1

ここからはポートの設定。

通常、Nginxを80番ポートで実行するため、Apacheの待ち受けポートを8080等に変更する。

#Listen 80
Listen 8080

NginxとApacheの両方でHTTPSを提供している場合、こちらもポートがかぶるので、Apache側のポートを変更する。設定ファイルは、/etc/httpd/conf.d/ssl.conf。

# Apacheでsslを停止するなら、下記のようにコメントアウトでOK
#Listen 443

ssl.confがない場合、httpdでsslを利用するのに必要なmod_sslがインストールされていないため、これをインストール。

# yum install mod_ssl

以上の設定で、Nginxをリバースプロキシとして、一部の通信をApacheに転送することが可能。

 

5. 補足(mod_rpafの利用)

mod_rpafをインストールする場合は、ここが参考になる。

 

■参考文献


Nginxに証明書を導入してHTTPSを使用する

1. 証明書の結合

自分が使っているサーバ証明書のルート証明書が、ユーザのブラウザでは中間証明書になっている、または、インストールされていない場合、正当な証明書として認識されない。

この場合、自分のルート証明書とユーザのブラウザにインストールされているルート証明書を結びつける連結証明書を認証局が提供している場合がある。

今回の場合、サーバ証明書はRapid SSL、このルート証明書はGeoTrust Global CAで、ユーザのブラウザには、ルート証明書としてEquifax Secure CAがインストールされている可能性があるので、公開されているGeoTrust Global CAとEquifax Secure CAの連結証明書(ex. intermediate.crt)をサーバ証明書(ec. hoge.com.crt)に結合する。

$ cat hoge.com.crt intermediate.crt > hoge.com.chainded.crt

 

2. Nginxの設定

HTTPS(SSL)を利用するには二つの設定方法がある。

(a) 新たにHTTPS専用のserverブロックを丸ごと追記する

(b) 既存のHTTPのserverブロックにsslに必要な項目だけ追記する

基本的な記述内容は、(a), (b)で同じになる。

既存のHTTPサーバーと同じ設定で運用したいなら(b)が便利。ここでは、(b)で進める。

server {
    listen 59.157.2.75:80;
    # リッスンポートを指定
    listen 59.157.2.75:443 ssl;
    server_name abeerforyou.com;
    root /var/www/html/abeerforyou.com;

    # サーバ証明書
    ssl_certificate /etc/pki/tls/certs/hoge.com.chained.crt
    # プライベートキー
    ssl_certificate_key /etc/pki/tls/private/hoge.com.key.pem

    ....
}

 

3. 証明書が正しく設定されているか確認

SSL Certificate Installation Checkerを使用して確認する。

 

■参考文献