nginx::nginx_status

nginxへ移行してみたものの、速さやリソース消費などメリットがよくわかりません。
とりあえず、nginxでは簡単なstatusが取得できるようなので、設定して、cactiでグラフ化してみました。
※internetからはアクセスできませんので、あしからず。

cactiのforumにありましたので参考に設定しました。
cacti-nginx.tar.gzをダウンロードします。

nginxを–with-http_stub_status_module付きでコンパイルします。

nginx.confに下記を追加

  location /nginx_status {
    stub_status on;
  }

こんな感じのレスポンスが得られます。シンプルでいいですね。

Active connections: 1 
server accepts handled requests
 1992 1992 5887 
Reading: 0 Writing: 1 Waiting: 0 

cacti-enginx.tar.gzを展開すると、下記5つのファイルがあります。

cacti-nginx-readme
cacti_graph_template_nginx_clients_stat.xml
cacti_graph_template_nginx_sockets_stat.xml
get_nginx_clients_status.pl
get_nginx_socket_status.pl

perlのスクリプトはcacti/scriptsディレクトリにコピーします。
xmlファイルはcactiのguiを使ってtemplate importします。

cactiでgraph作成時に上記のtemplateを利用します。設定中にurlを尋ねられるので、下記を入力。
(localhostとかでも良いんでしょうが、virtual hostの設定とかちょっとありまして。。。)

http://192.168.0.YYY/nginx_status

こんなグラフが取得できます。

php-fpmのstatusもとれるみたいだし、cactiでグラフ化もできるみたいなので、設定しておきますか。。

 

apacheからnginx + php-fpm

apacheで何の問題もないんだけど、なんとなくnginxへ移行。流行だからw
nginxはモジュール追加するときは、一からコンパイルしないといけないみたい。
結局のところ、下記で現状構築。

% cd nginx-1.2.3
% ./configure --prefix=/usr/local/nginx --with-openssl=/usr/local/ssl --with-ipv6 --with-http_stub_status_module
% make
# make install

起動スクリプトはいつものごとく、portsから抜いて使用させて頂きました。(パスを変更)
/etc/rc.confにnginx_enable=”YES”を追加。

/usr/local/nginx/conf/nginx.confの設定

user www;
worker_processes  2;  (2coreだし。。。)

http {
...
  server {
     listen  192.168.0.XXX:80 default_server;
     listen  [2001:470:24:XXX::YYY]:80 default_server;
     server_name _;
     return 444;
  } 
  include  /usr/local/nginx/conf.d/*.conf;
}

virtual hostの設定はconf.d/において設定を記述することにしました。

nginx.confでserver定義をしているのは、IPアドレスでアクセスする人や、異なる名前でアクセスする人など
がいるので、明示的にdefault serverを上記のようにしてコネクションを切るようにしています。
間違って、違うホスト名で住人のblogが表示されるなんてこともなくなります。
※意外とvirtual hostって神経使いますよね。。IPでアクセスしたら違うblogが表示されたりw

次にphpの設定を。。。
cgiはfast-cgi経由で実行するようです。

phpでは、5.3以降php-fpmというのが利用できるようです。
はじめは、phpもコンパイルして動作させましたが、だいたいの動作のイメージができたので、
最終的にはportsを利用。

# cd /usr/ports/lang/php53
# make config
  ZEND MULTIBYTE php-fpm (php-fpmにチェック)
# make 
# make install

php5のextensionも入れます

# cd /usr/ports/lang/php53-extensions
# make config
 BZ2, GD, MBSTRING, MYSQL, SNMP, ZLIB (SQLite関連は不要なので削除した)
# make 
# make install

wordpressのpluginにおいて、GDのfreetypeを扱う必要があったので、はまった。(compile時)
GD構築中に全てをチェックしてports install.
今回はcliのphpも問題なく動作しています。結局、以前はまったのはapache moduleの作り方がよくなかったんだろうと納得することに。

/usr/local/etc/php-fpmの設定

events.mechanism = kqueue  (FreeBSDだから)
....
[www]
user = www
group = www
listen = 127.0.0.1:9000
...

こんな感じ。とりあえず大きなチューニング等はしてません。
/etc/rc.confにphp_fpm_enable=”YES”を追加してOS起動時に立ち上がるようにしています。

本blog用のvirtual hostの定義です。wordpressを使っているので若干手直しが必要でした。
permanent linkを設定するためにurl書き換えしています。(google先生より回答)
apacheの場合は、.htaccessでrewriteしていました。

access logをcombinedに設定しているのは、apacheの時にcombinedだったのでその互換性を維持するため。
awstatsでログ統計をしているので。

/usr/local/nginx/conf.d/lol.confの内容

server {
  listen  192.168.0.XXX:80;
  listen  [2001:470:24:XXX::YYY]:80;
  server_name lol.pman.biz;
  ...
  access_log  logs/blog-access combined;
  ...
  location / {
    root   /xxxxxxx;
    index  index.php index.html;
    try_files $uri $uri/ /index.php?$args;   (wordpress permanent link用)
  }
  ...
  location ~ \.php$ {
    root           /xxxxxx;
    fastcgi_pass   127.0.0.1:9000;
    fastcgi_index  index.php;
    fastcgi_param  SCRIPT_FILENAME  /xxxxxx$fastcgi_script_name;
    include        fastcgi_params;
  }
  location ~ /\.ht {
    deny  all;
  }
}

だいたいこんな感じで移行して、blogを再開。(1日経過したからとりあえず大丈夫かな)
ここにたどりつくまで、いろいろとはまりましたが、そんなのは割愛。^^;
locationの書き方とかちゃんと理解しないといけない。。。ちょっと間違ったりすると、phpのソースコード
がそのままダウンロードされたりする。。。w

実験用のサーバは別にvirtual serverを定義しているので、そこでお勉強かな。。。

 

bindからnsdへ

前記事にて、DNSのキャッシュサーバをbindからunboundへ移行した訳ですが、DNSのコンテンツサーバも
bindから移行することにしました。nsdってやつ。
bindのzoneファイルがそのまま使えるってのはありがたいですね。
※コンテンツサーバというネーミングはどうもしっくりこない。

portsからインストールしてもいいんだが、dnsとかwebとか緊急のパッチが必要なときには、portsだときついので、自前でインストールします。

% tar zxvf nsd-3.2.13.tar.gz
% cd nsd-3.2.13
% ./configure --prefix=/usr/local/nsd
% make
# make install

※DNSSECとかまだやりません。

起動スクリプトだけ、手抜きでいつものごとくportsでもってきます。
/usr/local/etc/rc.d/nsdに配置して、パスの設定だけ編集して、
/etc/rc.confに

nsd_enable="YES"

/var/db/nsdにchrootされるようにしているので、ここに今まで利用していたゾーンファイルを
置いて

/usr/local/nsd/sbin/nsdc rebuild

でDB化してくれます。
/usr/local/etc/rc.d/nsdスクリプトを見ると、reload時もちゃんと、事前にrebuildしてくれてます。
zoneファイルを書き換えて、reloadしてやればいいだけですね。

nsdcというコマンドでいろいろできるようです。

特別なことは何もしてないので、主にzoneの記述をしてやるだけで、ほぼ変更なしです。
IPv6の設定は有効にしています。

以下、/usr/local/nsd/etc/nsd.confの一部

server:
	ip-address: 192.168.0.XXX
	ip-address: 2001:470:24:XXX::YYY
	ip4-only: no
	ip6-only: no
略
zone:
	name: "pman.biz"
	zonefile: "db.pman.biz"
        provide-xfr: 192.168.0.0/24 NOKEY
        provide-xfr: 2001:470:24:XXX::/64 NOKEY
zone:
	name: "XXX.24.470.2001.ip6.arpa"
	zonefile: "db.2001.470.24.XXX.ip6.arpa"
zone:
	name: "YYY.470.2001.ip6.arpa"
	zonefile: "db.2001.470.YYY.ip6.arpa"
略

(*) provide-xfrでゾーン転送をLANから可能に設定。

 

unbound::stub-zone

自宅LAN内のクライアントPC達へ名前解決を行う再起問い合わせ可能なキャッシュサーバをbindからunboundへリプレイスしました。
このblogのサーバはNATさせているので、自宅内のクライアントからアクセスするためには、192.168.0.xxxのプライベートアドレスを返してあげる必要があります。
今までは、bindのviewを使って記載していました。
unboundでも同様なことができそうなので、loca-dataを使って、unbound.confを変更しました。

local-data: "lol.pman.biz IN A 192.168.0.xxx"

上記を追加してうまく名前解決ができるようになりました。しかし、local-dataでoverwriteしていないホスト名は全く返ってきません。。。
local-dataに記載のないものは、通常の名前解決を実施するはず。
つまり、

local-zone: "pman.biz" transparent

は、暗黙のルールであるはず。。

こんなところではまって、いろいろ調べてたのですが、原因はunboundの問題ではなかった。。
他のホストはlol.pman.bizにmactchしないので、通常の問い合わせをunboundが実施。。
通常の問い合わせを実施するので、pman.bizのネームサーバに問い合わせする訳だが、よく考えると、このネームサーバはインターネットから見るとグローバルアドレスな訳…

unboundとnsd(コンテンツサーバ)は同一サーバで動作させているので、グローバルアドレスに問い合わせに
いくためには、NATをしているfirewall(vyatta)を経由することになる。。。
ヘアピンNATの設定はしていないので、通信できる訳がないことに気づいた。

forwarderか何かを使って回避できないかとunboundを調べていると、stub-zoneという記述を発見。
これが今回はあっていそうなので、利用します。

stub-zone: 
  name: pman.biz
  stub-addr: 192.168.0.xxx (nsdが動作しているLAN内のプライベートIP)

これで、local-dataにマッチしないpman.bizに属する他のホストは、stub-zoneの設定に従い名前解決できました。

自宅内LANから他のホストのアドレスの名前解決ができて何がうれしいかって?
名前が解決できてもヘアピンNATでないので、実際にはアクセスできないので、不要なのですが、応答がないやNXDOMAINなどではトラブルシュートの際にあせってしまうので、マッチしないものは、適切なDNS zoneから名前解決しているという事実が得られるだけありがたい。ってなだけです。

ひとつ問題。
IPv6のアドレスは自宅内でもグローバルで割り当てているので、local-dataでoverwriteする必要は全くないのですが、IPv4のホストはlocal-dataでoverwriteしているのでIPv6も同じようにと思って設定したのですが、これはダメでした。。。

何がダメかというと、local-dataそのものの動作は問題ないのですが、local-dataでマッチしないIPv6のホストを引くと、stub-zoneで設定したDNSへ問い合わせしてくれず、無応答のまま。。

ってな訳で、IPv6のAAAAは、local-dataをoverwriteせずに、stub-zoneへ問い合わせることにしました。
原因の追求はしていません。
stub-addrで、IPv6のアドレスも定義してやればいいのかな〜。。。これで動作してもなんかしっくりこない。
transport prtocolはv4でもいいだろ!って感じになるので。