ruby や rails のオフラインドキュメントを生成するには、sdoc を使うと便利です。
sdoc は、gem 経由で簡単にインストールすることができます。


$ rvm 1.9.3
$ gem install sdoc


sdoc 3.0.16 だと、github を使っているときエラーが発生しているため、パッチをあてる必要があります。


$ diff $HOME/.rvm/gems/ruby-1.9.3-p194/gems/sdoc-0.3.16/lib/sdoc/github.rb
30c30
< s = Dir.chdir(File.join(basedir, File.dirname(path))) do
---
> s = Dir.chdir(File.join(base_dir, File.dirname(path))) do
39c39
< s = Dir.chdir(File.join(basedir, File.dirname(path))) do
---
> s = Dir.chdir(File.join(base_dir, File.dirname(path))) do
47c47
< absolute_path = File.join(basedir, path)
---
> absolute_path = File.join(base_dir, path)


まずは、rails 3.2.3 のオフラインドキュメントを生成してみます。

$ git clone https://github.com/rails/rails.git
$ cd rails
$ git checkout v3.2.3
$ sdoc --format=sdoc --github --output rails-3.2.3 --hyperlink-all rails


かなり警告がでますが、しばらくすると rails-3.2.3 ディレクトリの中に html なドキュメントが生成されています。僕の手元の Macbook Air だと 15 分くらいかかりました。

次に ruby-1.9.3 のオフラインドキュメントを生成してみます。

$ git clone https://github.com/ruby/ruby.git
$ cd ruby
$ git checkout v1_9_3_194
$ sdoc --format=sdoc --output ruby-1.9.3p194


ruby-1.9.3p194 ディレクトリの中に約 5 分くらいでオフラインドキュメントを生成することができました。

あとは、これからのドキュメントを sdoc-merge を使うとまとめることができます。たしめにまとめてみたのですが、僕は個別で参照することが多いので、使っていません。

$ sdoc-merge --title "Ruby 1.9.3-p194 and Rails 3.2.3" --op merged --names "Ruby,Rails" ruby-1.9.3p194 rails-3.2.3


sdoc かなり便利ですね。

参照
Create local Ruby on Rails documentation for offline use | Shynnergy

まず、Fedora 用の mosh.spec をダウンロードします。

$ wget https://raw.github.com/achernya/mosh/0df58a90da7d57ea1cda0a0b24fddfda97186a20/fedora/mosh.spec


このままだと CentOS 5 で RPM ビルドに失敗するので、mosh.spec を次のように編集します。

$ vi ~/rpmbuild/SPECS/mosh.spec
18a19,20
> BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
>
37a40
> rm -rf $RPM_BUILD_ROOT
42d44
< %doc README.md COPYING ChangeLog


これで mosh バージョン 1.2 RPM を作成することができました。CentOS 5.8 x86_64 の mosh バージョン 1.2 RPM をこちらにおいておくので、必要な方は使ってみて下さい。

まずは、Homebrew 経由で pow をインストールします。このとき依存関係の設定により Node バージョン 6 系がインストールされます。

$ brew install pow


次に NVM をインストールして、Node バージョン 4 系をインストールします。

$ nvm install 0.4.12


次に pow の起動コマンドを変更して Node 0.4 系を使いように変更します。環境変数は、お使いの環境にあわせて展開して下さい。

$ vi $HOMEBREW_HOME/bin/pow
...
exec "$HOME/.nvm/v0.4.12/bin/node" "$HOMEBREW_HOME/Cellar/pow/0.3.2/pow/lib/command.js" "$@"


最後に pow エージェントを動作させます。80 ポートで直接動かしたい人は、ファイアウォールの設定も変更します。

$ sudo pow --install-system
$ pow --install-local


これで pow を使うことができるはずです。

僕は、大人の事情で Apache 経由で使いかっため、Running Pow With Apache を参考にしながら、次の設定をしました。

$ vi $HOME/.powconfig
export POW_DST_PORT=8080
$ wget https://raw.github.com/gist/1058580/zzz_pow.conf
$ sudo vi /etc/hosts
127.0.0.1 pow .dev


これでさくさくと開発を進めることができる環境になりましたが、RVM + Ruby 1.9.3 で Sinatra を使いたいとき、アプリケーション側の config.rb に GEM_HOME 環境変数を設定するのはやめたかったので、次の設定を追加しました。

$ vi $HOME/.powconfig
export POW_RVM_PATH="$HOME/.rvm/scripts"
$ cd $SINATRA_APP1
$ vi .rvmrc
rvm 1.9.3
export GEM_HOME="$HOME/.rvm/gems/ruby-1.9.3-p194"


こんな感じで設定しておくと、pow を RVM に対応させることができます！

さらに powder や powify を使うと便利だと思います。僕は今のところ powder を使っています。

これで、さくさくとウェブアプリケーションの開発が進められそうです！

Hoembrew を基本的に使っているので、Homebrew 経由でインストールするのが一番簡単です。なお、公式の Formula ないので注意して下さい。


$ brew install https://github.com/josegonzalez/homebrew-php/raw/master/Formula/php.rb --devel --with-mysql


–devel を書略すると 5.3.10 がインストールされます。

あとは、$HOMEBREW_HOME/Cellar/php/5.4.0/libexec/apache2/libphp5.so がインストールされるので、既存の libphp5.so の設定はコメントにして組み込んであげるだけで使うことができます。

次のような Apache の設定にしてあげると、5.3 系と切り替えることができるので便利ですね。

#
# PHP 5.3.8
#
#LoadModule php5_module libexec/apache2/libphp5.so

#
# PHP5 handler
#
Include /private/etc/apache2/other/php5.conf


ちなみに –with-fpm をつけると PHP-FPM をビルドすることができますが、そのかわりに Apache モジュールはビルドされないので注意して下さい。


$ find $GIT_REPO -type d -name .git | xargs -n 1 dirname | sort | while read line; do echo $line && cd $line && git pull && cd $GIT_REPO; done


.git を .svn に変更して git pull を svn update に変更すれば subversion にも対応することができます。

便利！

計測に使用したツールは、UnixBench というツールです。

仮想サーバの、CPU やメモリはまったく同じ設定をしました。OS は、CentOS 5.8 x86_64 で、カーネルのバージョンが違っているのは Xen と KVM の違いによるものです。

詳細の結果は、gist にまとめておきました。

System Benchmarks Index Score でいうと、
KVM は 2786.6 だったのに対して、
Xen は 1155.3 だったので、約2倍くらいベンチマーク数値としては違っていました。

パフォーマンスの面からみると、某クラウドでは KVM を使うのがよいかなぁと思いました。

ちゃんちゃん。

.zshrc に、次の設定を書くだけです。


compdef mosh=ssh


これで、mosh コマンドの補完は ssh コマンドの補完と同じ機能を利用することができます。
これで、かなり mosh コマンドが便利になりました。

参考
compdef mosh=ssh

それでは、皆さん素敵なビールライフを過ごして下さいね！！！

この本は、サーバ/インフラエンジニア養成読本シリーズの最新作で、Software Design で過去に掲載された「管理/監視編」の記事をまとめた本になっています。

さまざまなインフラを監視する技術や方法などが多数紹介されているので、インフラエンジニアの方にはおすすめできる本です。

さくら VPS 2G  ですが、海外の VPS と比べてもとても格安だったので、思い切って 1 年契約してみました。僕は、初めてさくら VPS を使ってみたので、OS の設定から、初期設定まで忘れないようにまとめておきたいと思います。最初のリリース後にかなりの人気があったみたいで、僕は申し込みが再開されてから無事に申し込むことができました。

まずは、さくら VPS 2G を公式ページから申し込みます。このとき、さくらのアカウントが必要なのでアカウントをもっていない人は登録します。

さくらの VPS を申し込むと、すぐに『申し込み完了』メールが届きます。そのあと、しばらくすると（僕の場合六時間後くらいでした）『仮登録完了のお知らせ』のメールが届きます。このメールに、サーバの IP アドレスと、ユーザ名、パスワードが書かれています。

これから、さくら VPS のスクリーンショットを掲載していますが、IP アドレスなど個別情報に関するものは塗りつぶしてあるのでご了承下さい。

さっそく、さくら VPS コンソールに接続して、IPアドレスとパスワードを入力します。

VPS ホームの画面が表示されます。初期状態だと、標準 OS の CentOS 6.2 x86_64 がインストールされた VM が停止状態になっています。このまま、CentOS を起動することができます。しかし、ここは試しに別の OS を再インストールしてみることにしました。なお、カスタム OS をインストールするには、JRE のインストールが必要です。OSX Lion の場合は、このあたりの情報を参考にして事前にインストールしておいて下さい。

左側のメニューから、「OS 再インストール」選択します。

次に「カスタム OS のインストールへ」を選択します。

今回は、OS として Fedora 16 x86_64  を選択しました。Fedora は、ほぼ最新のカーネルやパッケージを扱うことができるので、最新の Linux 技術を試すのにうってつけの環境です。「確認」ボタンをクリックします。

カスタム OS のインストール確認が表示されるので「実行」ボタンをクリックします。

Chrome の場合、Java プラグインの実行確認が表示されますので、許可します。インストール情報は、OS のインストールの際に必要なので、そのまま表示しておきましょう。

しばらくすると、Java アプレットが実行されて、インストール画面が表示されます。

キーボードの種類を選択します。ご自身で使われているキーボードの種類を選択して下さい。

いつも通りの Fedora の GUI インストール画面が表示されます。

今回は、VPS になるのでメインのパーティンションを暗号化してみます。暗号化パーティションでインストールすると、OS の起動のたびにマウントするためのパスワードの入力が必要なので注意しましょう。GPT パーティションになるので、「Use All Space」を選択した状態で、「Encrypt system」と「Review and modify partitioning layout」をチェックしています。この状態から「BIOS boot」パーティションだけを削除しないように、好みのパーティションレイアウトに変更してみました。

このとき、アンダースコアが入力できないのですが、Macbook Air 英語キーボード上から「Ctrl + Command + -」で入力できました。次のようなパーティションレイアウトにしてみました。

 

フォーマット確認後、暗号化パーティションのパスワードを入力する画面が表示されるのでパスワードを入力します。

次にネットワークの設定画面が表示されます。さくら VPS のインストール情報をもとにネットワーク IPv4 の設定をします。

以上の設定でインストールが始まりますので、ビールでも飲みながらしばらく待ちましょう。

インストールは、５分くらいで完了します。インストールが完了すると、Java アプレットの VNC の画面が閉じます。

ブラウザのさくら VPS のトップページに戻り、サーバを起動します。起動後、リモートコンソールをクリックします。

「VNC コンソールを開く」をクリックします。暗号化パーティションをマウントするため、パスワードの入力待ち状態になっているのでパスワードを入力します。

お馴染みのログイン画面が表示されました。この状態になれば、ターミナルから SSH 経由で接続できるので、Fedora の初期設定をはじめていきましょう。

初期設定は、次のエントリでまとめていきたいと思います。

そこに広がるのは、無限の、闇、闇、そして闇。
一部内容におかしい箇所があるかもしれませんが、そこは闇ということでご了承下さいませ。

mod_log_rotate 細かいところを改善したいことがあるので、対応次第、このブログにアップしていきたいと思います。

あと、個人的には公式の rotatelogs とのパフォーマンス測定などもしてみたいです。

どうやって、gitconfig に github の API トークンを含めようかなと思い、検索してみると ERB でやっている強者がいました。もっと、エレガントな方法がないものかと思ってさらに調査してみると、Pro Git に素晴らしい情報を見つけることができました。

Pro git によると gitconfig は、次の順序で読み込まれるようです。

1. /etc/gitconfig
2. $HOME/.gitconfig
3. $HOME/.git/config git リポジトリの .git/config

ということで $HOME/.gitconfig を github 上で公開して管理するようにして、$HOME/.git/config /etc/gitconfig を作成してその中に github の API トークンを含めることにしました。

この状態で、git config -l してみると、ちゃんと設定はされているようで安心しました。

.gitconfig に include が追加されると、かなり便利なんですけれど、今はそのオプションはない模様です。

2012.03.28: 追記

@hirose31 さんの指摘により、一部修正しました。

github にリポジトリを新規作成する

$ mkdir hoge
$ cd hoge
$ git init
$ hub create
$ git add README
$ hub push -u origin master
（以降は・・・）
$ hub push


man をみると、github 向けに拡張されたコマンドがあるので、とても便利です。

ということで、hub コマンドがない環境も考慮して、次の設定を .zshrc に、追加してみました。

if [ -x "`which hub 2> /dev/null`" ]; then
alias git=hub
else
alias git=git
fi

alias g=git


Enjoy, github life.

これは、MySQL の SHOW TABLE STATUS をストアプロシージャーを使って、見やすく方法です。

1. tools というデータベースを作成します
2. ここにある SQL を実行して、ストアプロシージャーを作成します
3. あとは、call tools.sp_status(database()); のような形でデータベース名を指定して実行するだけです

たとば、mysql データベースの場合だと、こんな感じです。

通常の show table status。

root@localhost[mysql]> show table status;
+---------------------------+--------+---------+------------+------+----------------+-------------+-
-------------------+--------------+-----------+----------------+---------------------+--------------
-------+---------------------+-------------------+----------+----------------+----------------------
-----------------------------+
| Name | Engine | Version | Row_format | Rows | Avg_row_length | Data_length |
Max_data_length | Index_length | Data_free | Auto_increment | Create_time | Update_time
| Check_time | Collation | Checksum | Create_options | Comment
|
+---------------------------+--------+---------+------------+------+----------------+-------------+-
-------------------+--------------+-----------+----------------+---------------------+--------------
-------+---------------------+-------------------+----------+----------------+----------------------
-----------------------------+
| columns_priv | MyISAM | 10 | Fixed | 0 | 0 | 0 |
227994731135631359 | 4096 | 0 | NULL | 2011-08-11 01:09:56 | 2011-08-11 01
:09:56 | NULL | utf8_bin | NULL | | Column privileges
|
| db | MyISAM | 10 | Fixed | 4 | 440 | 1760 |
123848989752688639 | 5120 | 0 | NULL | 2011-08-11 01:09:56 | 2011-08-28 22
:51:20 | 2011-08-11 01:09:56 | utf8_bin | NULL | | Database privileges
|


sp_status を使った場合。

root@localhost[mysql]> call tools.sp_status(database());
+---------------------------+--------+------+---------+-------------------+
| Table Name | Engine | Rows | Size | Collation |
+---------------------------+--------+------+---------+-------------------+
| columns_priv | MyISAM | 0 | 0.00 Mb | utf8_bin |
| db | MyISAM | 4 | 0.01 Mb | utf8_bin |
| event | MyISAM | 0 | 0.00 Mb | utf8_general_ci |
| func | MyISAM | 0 | 0.00 Mb | utf8_bin |
| general_log | CSV | 2 | 0.00 Mb | utf8_general_ci |
| help_category | MyISAM | 38 | 0.02 Mb | utf8_general_ci |
| help_keyword | MyISAM | 452 | 0.10 Mb | utf8_general_ci |
| help_relation | MyISAM | 993 | 0.03 Mb | utf8_general_ci |
| help_topic | MyISAM | 508 | 0.43 Mb | utf8_general_ci |
| host | MyISAM | 0 | 0.00 Mb | utf8_bin |
| ndb_binlog_index | MyISAM | 0 | 0.00 Mb | latin1_swedish_ci |
| plugin | MyISAM | 0 | 0.00 Mb | utf8_bin |
| proc | MyISAM | 1 | 0.01 Mb | utf8_general_ci |
| procs_priv | MyISAM | 0 | 0.00 Mb | utf8_bin |
| servers | MyISAM | 0 | 0.00 Mb | utf8_general_ci |
| slow_log | CSV | 2 | 0.00 Mb | utf8_general_ci |
| tables_priv | MyISAM | 0 | 0.00 Mb | utf8_bin |
| time_zone | MyISAM | 0 | 0.00 Mb | utf8_general_ci |
| time_zone_leap_second | MyISAM | 0 | 0.00 Mb | utf8_general_ci |
| time_zone_name | MyISAM | 0 | 0.00 Mb | utf8_general_ci |
| time_zone_transition | MyISAM | 0 | 0.00 Mb | utf8_general_ci |
| time_zone_transition_type | MyISAM | 0 | 0.00 Mb | utf8_general_ci |
| user | MyISAM | 7 | 0.00 Mb | utf8_bin |
+---------------------------+--------+------+---------+-------------------+
23 rows in set (0.06 sec)


かなりターミナル画面で見やすくなりましたね！

環境は、Mecab バージョン 0.993 を Lion OSX 10.7.3。
mecab と mecab-ipadic は、homebrew でインストール済み、Ruby は RVM で REE 2012.01 をインストール済みとします。


$ rvm ree
$ wget "http://mecab.googlecode.com/files/mecab-ruby-0.993.tar.gz"
$ tar zxf mecab-ruby-0.993.tar.gz
$ cd mecab-ruby-0.993
$ ruby extconf.rb
checking for main() in -lmecab... no
checking for main() in -lstdc++... yes
checking for mecab.h... yes
creating Makefile
$ make
cc -dynamic -bundle -undefined suppress -flat_namespace -o MeCab.bundle MeCab_wrap.o -L. -L/Users/n0ts/.rvm/rubies/ree-1.8.7-2012.01/lib -L. -lstdc++ -L/opt/local/lib -ldl -lobjc
ld: warning: directory not found for option '-L/opt/local/lib'
$ ruby test.rb
0.993
dyld: lazy symbol binding failed: Symbol not found: __ZN5MeCab11createModelEPKc
Referenced from: /Users/Shared/w/prj/src/mecab-ruby-0.993/MeCab.bundle
Expected in: flat namespace

dyld: Symbol not found: __ZN5MeCab11createModelEPKc
Referenced from: /Users/Shared/w/prj/src/mecab-ruby-0.993/MeCab.bundle
Expected in: flat namespace


となって MeCab を使うことができません。原因は、察してのとおり -lmecab が no になっているからですので、extconf.rb を修正する必要があります。

もっとエレガントな方法がありそうですが、次のように修正しました。

--- extconf.rb-org 2012-02-22 16:44:15.000000000 +0900
+++ extconf.rb 2012-02-22 17:01:04.000000000 +0900
@@ -3,6 +3,7 @@
mecab_config = with_config('mecab-config', 'mecab-config')
use_mecab_config = enable_config('mecab-config')

+$LIBS += '-L/var/homebrew/Cellar/mecab/0.993/lib'
`mecab-config --libs-only-l`.chomp.split.each { | lib |
have_library(lib)
}


/var/homebrew とは、homebrew のインストール先のパスになりますので、環境に応じて書き換えてください。

毎度、MeCab を OSX 上で使うときは、かなりはまりますね。。。


def get_week_num_of_month(date)
wday = (date.wday == 0) ? 6 : date.wday - 1
return (date.day - wday + 13) / 7
end


get_week_num_of_month 関数に Date クラスを渡すと、その日が当月の何週目か取得することができます。
なお、この関数は月曜日〜日曜日までを 1 週間としてカウントしています。


Feb 7 21:43:23 10.0.4.3 ERROR insufficient disk space: installing
package initscripts-8.45.38-2.el5.centos.x86_64 needs 791MB on the /
filesystem
Feb 7 21:43:23 10.0.4.3 ERROR error running transaction:
installing package m2crypto-0.16-8.el5.x86_64 needs 823MB on the /
filesystem
...


正しく、100GB で ext4 でフォーマットしているのにもかかわらず、ディスク用不足というメッセージでインストールに失敗していました。
しばらく原因を探ってみると、cobbler のベースの distro の CentOS がバージョン 5.3 で、ext4 に対応する前のバージョンだったことが原因でした。CentOS 5 系では、ext4 がサポートされたのは 5.5 からでした。

ということで、次のような感じで、cobbler ベースの distro の CentOS をバージョン 5.7 に差し替えて無事インストールすることができるようになりました。hoge というプロファイルがある場合は、次のように distro を入れ替えることができます。


# cobbler import --path=rsync://ftp.jaist.ac.jp/pub/Linux/centos/5.7/x86_64/os/ --name=centos57-x86_64
# cobbler profile edit --name=hoge --distro=centos57-x86_64
# cobbler profile edit --name=hoge-xen --distro=centos57-xen-x86_64


すこしはまってしまったので、備忘録代わりにメモをしておきます。

YARD server は、yard server –gems とすると、8808 ポート経由でローカルにインストールされているすべての gem のヘルプを参照することができます。
YARD server を、supervisor などで起動してもいいんですが、せっかくローカル開発環境では Passenger を使っているので YARD server を Passenger で動かしてみました。

やり方は、とても簡単で、この config.ru を使うだけです。

1. YARD server 用の DocumentRoot を作成します（例えば、/tmp/yard/public とします）
2. /tmp/yard/config.ru を、gist から取得します

YARD server 用の Apache の設定ファイルを、次のような感じにします。

<VirtualHost *>
ServerName yard
DocumentRoot /tmp/yard/public
</VirtualHost>


あとは、/etc/hosts に yard 127.0.0.1 を定義して、ブラウザで http://yard を開くだけです。

これで、かなり便利に YARD server を使うことができますね！

いろいろと試行錯誤したところ、次のような感じで値が違う同じ環境変数を設定することができました。


MAILTO=root
RUBY=/usr/local/bin/ruby

ROOT_DIR=/home/naoya/app2
RAILS_ENV=test
0 1 * * * cd $ROOT_DIR; $RUBY script/runner


こんな感じで設定すると、バッチはその上に書かれている環境変数の値となって実行することができます。

1. 00:00: ROOT_DIR=/home/naoya/app1, RAILS_ENV=production
2. 01:00: ROOT_DIR=/home/naoya/app2, RAILS_ENV=test

ちなみに Puppet で設定すると、上と同じ設定内容になります。
上の記述の方が、env を使うよりもすっきりとバッチ処理を記述できるので、いいと想っています。

RHEL5 系には該当しませんが、RHEL6 系に該当するので、注意が必要です。

問題があるカーネルのバージョンは、次のとおりです。

• 2.6.28 〜 3.1.4

すでに Linux kernel 2.6.32.50 / 3.0.13 / 3.1.5 で修正されていますが、現時点で RHEL6 でセキュリティパッチが提供されていませんので、RHEL6 系のディストリビューションは注意が必要そうです。

なお、VMware や Xen などで仮想化マシン上の Linux は影響がない模様です。Xen Dom0 の場合は不明です。。。

Lion 10.7.2（ハードウェアは、Macbook Air 13 Mid 2011）で、現在とても不思議な現象にはまっていて、とても困っているので現象だけをまとめておきます。
今のところ、具体的な原因と解決策が分かっていないので、もしご存じの方がいましたら教えてください。

1. 認証のかかっている無線 LAN を利用するとして、その SSID に接続します（僕の場合は DoCoMo m-zone の無線 LAN を契約していますので、SSID は docomo です）
2. 接続した IP などが切り替わると、正しく認証するまでは、すべての接続は https://wlan.m-zone.jp にリダイレクトされます
3. ここで、認証するため、10 分以上の時間を要することがあったり、ひどいときにはまったく https://wlan.m-zone.jp に接続できなくなりますが、ここでブラウザから認証したとします
4. そうすると、普通にインターネットを利用することができます
5. 正しく認証したあと、まったく別のオープンな無線 LAN に切り替えると、https へのページにまったく接続できなくなりました…
6. ※このとき、ローカルの VMware fusion の Linux からは問題なく https 接続できるため、Lion 側の問題だと推測しています

コマンドラインから、curl してみると、鍵交換する前で、ずーとブロックしたままかえってきません。

$ curl url https://gmail.com --verbose
* About to connect() to gmail.com port 443 (#0)
* Trying 74.125.235.119... connected
* Connected to gmail.com (74.125.235.119) port 443 (#0)
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
（ここでブロックする）


さらに Mail も IMAPs を使っているのですが、これもまったく接続できなくなります。Apple Mail の応答がなくなりひどいことになります。さらに Evernote も SSL 経由でデータを取得しているためか、起動しても応答がなくなります。当然ですが、どのブラウザからもどの https ページに接続できなくなります。

肝心の解決策ですが、今のところシャットダウンしてから再起動すると直りますが、再起動や無線 LAN のオフオンでは効果がありませんでした。

おそらく、この問題は 10.7.2 にアップデートしたくらいから発生しているような気がしています。
認証のある無線 LAN を使うとかなりの頻度で再現します。今日は、一回で再現しました。
認証のある無線 LAN の場合、そこで接続してしまうと、接続後はすべての http 通信などが認証用の https ページにリダイレクトされることになるため、そうなると何かがおかしくなるようです。。。

この問題を Apple へ報告したいのですが、症状をうまく伝えることができそうにないので困っています。

今のところ、この問題に遭遇しないようにするには、m-zone のような認証のある無線 LAN を利用しないってことなのですが、せっかく契約しているため使いたいです。

今年は、怒濤の年になりそうです。


$ /proc/$PID/cwd
lrwxrwxrwx 1 root wheel 0 Dec 27 17:52 /proc/$PID/cwd -> /usr/local/hoge


この他にも /proc/$PID には、プロセスに関する情報がありますが、exe には実行ファイルパスが分かったりと、何かと便利ですね。

# 追記
@ishikawa84g さんから、次のコマンドでも同じことができるとコメントをいただきました！ありがとうございます！

$ usr/sbin/lsof -p $PID | grep cwd
ruby $PID root cwd DIR 9,0 4096 24675239 /usr/local/hoge


皆さんこんにちは、n0ts こと、Naoya Nakazawa です。

今日は、みなさん日頃からカジュアルに MySQL を運用して、日々生活されていることと思います。MySQL は、非常に安定したオープンソースソフトウェアだと思いますが、どんなものでもときにはおかしくなったりするものです。

「備えあれば憂いなし」ということで、僕は日頃から Nagios というオープンソースソフトウェアを利用して、MySQL がおかしくなっていかいか日々カジュアルに監視しています。

今日は、カジュアルに MySQL を Nagios を使って監視する方法を紹介したいと思います。なお、今回は CentOS 5.7 x86_64 というカジュアルな Linux ディストリビューションを使っていて、その中に MySQL がインストールされて、MySQL サーバが動いている環境で解説しています。

まず、一番カジュアルで簡単な監視方法は、Nagios 公式の監視プラグインを使った監視です。Nagios 公式の監視プラグインは、次のコマンドでインストールすることができます。


# yum install nagios-plugins -y


64bit 環境の場合、/usr/lib64/nagio/plugins に、Nagios 公式の監視プラグインがインストールされます。

たくさんの監視プラグインがありますが、この中で MySQL を監視することができるプラグインは、次の 2 種類があります。

• check_mysql
• check_mysql_query

それぞれのプラグインについて解説していきます。

check_mysql

check_mysql は、MySQL サーバへの接続をテストする監視プラグインです。使い方は、とっても簡単です。次のように実行するだけです。

$ /usr/lib64/nagios/plugins/check_mysql
Uptime: 1131841 Threads: 2 Questions: 708 Slow queries: 0 Opens: 17 Flush tables: 1 Open tables: 1 Queries per second avg: 0.0


とっても簡単ですね！これで監視はできていますが、念のため省略されている引数をつけると次のようになります。

$ /usr/lib64/nagios/plugins/check_mysql -H localhost -u root
Uptime: 1131936 Threads: 2 Questions: 709 Slow queries: 0 Opens: 17 Flush tables: 1 Open tables: 1 Queries per second avg: 0.0


上の例では、ローカルホストにある MySQL サーバに対して root というユーザ名で接続して MySQL サーバに接続できるか監視しています。
ちなみに、MySQL サーバをわざと停止してから、エラーになるかどうか確認してみましょう。

$ sudo /etc/init.d/mysql stop
Shutting down MySQL.. [ OK ]
$ /usr/lib64/nagios/plugins/check_mysql -H localhost -u root
Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)


問題ないですね！

この他にもスレーブの遅延も検出することができます。これも、よく使う定番の監視といえるでしょう。

$ /usr/lib64/nagios/plugins/check_mysql -H db-ads2 -u repl_client -p repl_pass --check-slave --warning 5 --critical 10
Uptime: 8229294 Threads: 186 Questions: 2092736633 Slow queries: 10 Opens: 231 Flush tables: 1 Open tables: 143 Queries per second avg: 254.303 Slave IO: Yes Slave SQL: Yes Seconds Behind Master: 0


–check-slave というオプションは、スレーブとして動作しているか確認するためのオプションです。そのあとに閾値である warning と critical を使って、スレーブの遅延が何秒があったときエラーとして検出するのかを指定しています。上の例では、5 秒遅延になったとき警告レベル、10 秒遅延になったとき致命レベルとして検出しています。

check_mysql_query

check_mysql_query プラグインは、とある SQL クエリーを発行した結果、その結果の数値がある閾値内にあるかどうか監視するプラグインです。指定する SQL クエリーは、必ず結果が数字にならないといけません。
例えば、次のように実行します。


$ /usr/lib64/nagios/plugins/check_mysql_query --query "SELECT 1" --warning 2:2 --critical 1:1
QUERY WARNING: 'SELECT 1' returned 1.000000


上の例では、「SELECT 1」というクエリーを実行して、その結果が 2 から 2 までにないときは警告レベル、1 から 1 までに ないときは致命レベルとして検出しています。上の例だと、「SELECT 1」というクエリーは必ず結果が 1 になるため、警告レベルとして検出されます。

このプラグインは、SQL クエリーを指定できるため、非常に柔軟に MySQL を監視することができます。

例えば、次の例は test というデータベースにある employees テーブルのレコード件数を数えて、レコード数が 2000 件を超えたときは警告レベル、3000 件を超えたときは致命レベルとして検出します。

$ /usr/lib64/nagios/plugins/check_mysql_query --database test --query "SELECT COUNT(*) from employees" --warning 1:2000 --critical 1:3000
QUERY OK: 'SELECT COUNT(*) from employees' returned 1.000000


check_mysql_query プラグインを使うと、より実際の MySQL のデータベース内容を監視することができます。

Nagios 公式で提供されている MySQL 監視プラグインは上の二つになります。

みなさん、これで十分に MySQL をカジュアルに監視して、夜も安心して眠れるようになったでしょうか？眠れるようになったという人は、ここで読み終えてください。まだ、何か足りないんじゃない？と思った人は、このあとも読んでみてください。。。

さらに MySQL を Nagios を使って監視するプラグインに、check_mysql_health という非常に便利なプラグインがあります。

check_mysql_health

check_mysql_helath プラグインは、さきほど解説した check_mysql と check_mysql_query を組み合わせて、さらに多くの監視ができるプラグインです。公式のマニュアルは、ここ（英語）で公開されています。
具体的には、次のことができます。

• MySQL サーバへの接続にかかる時間
• MySQL サーバが動作している時間
• 現在、開かれているコネクション数
• スレッドキャッシュのヒット率 スレーブの遅延（check_mysql –check-slave と同じ）
• Slave io running の監視
• Slave sql running の監視
• クエリーキャッシュのヒット率
• クエリーキャッシュでメモリ不足のため、切り落としたエントリ数
• MyIASM のキーキャッシュのヒット率
• InnoDB バッファープールのヒット率
• InnoDB バッファープールのクリーンページが利用可能になるまで秒数
• InnoDB のログウェイト時間（これは、ログバッファーが小さすぎるときに発生する）
• テーブルキャッシュのヒット率
• テーブルロックの失敗率
• インデックスの利用率 ディスク上に作成された一時的テーブルの割合
• スロークエリー
• 長く動いているプロセスの監視
• ndnd ノードが起動していて動いている数
• あるクエリーの結果の特定の数値がどうか（check_mysql_query と同じ）

いかがでしょう！こんなにたくさんの項目を監視することができます。

この中で、比較的重要な監視の方法を解説していきます。

まず、MySQL へ接続する時間の監視です。これは、ウェブアプリケーションから MySQL へ接続する時間がかかってしまうと、ウェブアプリケーションが重い状態になってしまいます。こんなときのために MySQL へ接続する時間を監視しておくと、とても便利です。これは、次のように実行します。

$ /usr/lib64/nagios/plugins/check_mysql_health --hostname localhost --user root --mode connection-time --warning 0.5 --critical 1.0
OK - 0.02 seconds to connect as root | connection_time=0.0211s;0;1


上の例では、MySQL への接続に 0.5 秒かかったときは警告レベル、1.0 秒かかったときは致命レベルとして検出します。秒数は、1 秒以下も指定できるため、かなり厳密な時間で監視することができますので、とても重宝します。

クエリーキャッシュのヒット率を監視したい場合は、次のように実行します。

$ /usr/lib64/nagios/plugins/check_mysql_health --hostname localhost --user root --mode querycache-hitrate --warning 80: --critical 70:
WARNING - query cache hitrate 70.82% | qcache_hitrate=70.82%;80:;70: qcache_hitrate_now=62.82% selects_per_sec=420.17


上の例では、クエリーキャッシュのヒット率が 80% をきったときは警告レベル、70% をきったときは致命レベル、として検出します。クエリーキャッシュを使っている環境の場合は、とても重要な監視となるでしょう。

スレッドキャッシュのヒット率を監視したい場合は、次のように実行します。

$ /usr/lib64/nagios/plugins/check_mysql_health --hostname localhost --user root --mode threadcache-hitrate --warning 80: --critical 70:
CRITICAL - thread cache hitrate 7.50% | thread_cache_hitrate=7.50%;80:;70: thread_cache_hitrate_now=7.50% connections_per_sec=0.00


上の例では、スレッドキャッシュのヒット率が 80% をきったとき警告レベル、70% をきったとき致命レベル、として検出します。上の場合だと、スレッドキャッシュのヒット率が 7.50% なので致命レベルとなっています。

InnoDB のバッファープールのヒット率を監視したい場合は、次のように実行します。

$ /usr/lib64/nagios/plugins/check_mysql_health --hostname localhost --user root --mode innodb-bufferpool-hitrate --warning 80: --critical 70:
OK - innodb buffer pool hitrate at 80.00% | bufferpool_hitrate=80.00%;80:;70:;0;100 bufferpool_hitrate_now=100.00%


とても簡単ですね。

check_mysql_health プラグインを使うと、さらに多くの監視を MySQL に対して行うことができます。

さらにカジュアルにもう一方踏み込んで監視するプラグインに mysql_health_check があります。

mysql_health_check

mysql_health_check プラグインは、「SHOW FULL PROCESSLIST」や「SHOW GLOBAL VARIABLES」や「SHOW GLOBAL STATUS」の結果を監視するプラグインです。引数の指定で、これらの出力を一定時間キャッシュさせておくことができます。残念ながら、現時点でのバージョンでは「SHOW ENGINE INNODB STATUS」はコメントになっており機能していません。将来的にはきっと対応してくれることでしょう。

mysql_health_check プラグインは、必ずモードを –mode で指定する必要がありますが、long-query、lock-query、varcomp から指定することができます。それぞれの意味は、次のとおりです。

• long-query: 指定した秒数以上実行しているクエリーを検出します
• lock-query: 指定した秒数以上ロックしているいクエリーを検出します
• varcomp: 「SHOW GLOBAL VARIABLES」や「SHOW GLOBAL STATUS」の中にある変数やステータスが閾値にあるかどうか検出します

long-query の実行例は、次のとおりです。

$ /usr/lib64/nagios/plugins/mysql_health_check.pl --hostname localhost --user root --mode long-query --warning 30 --critical 60
mysql_long-query OK


上の例では、30 秒以上実行しているクエリーを検出したときは警告レベル、60 秒以上実行しているクエリーを検出したときは致命レベル、として検出します。

varcomp の実行例は、次のとおりです。これは、すこし複雑かもしれません。。。

$ /usr/lib64/nagios/plugins/mysql_health_check.pl --hostname localhost -u root --mode varcomp --expression="Connections" --warning=">100" --critical=">200" --cache_dir=/tmp --max_cache_age=90
mysql_varcomp OK - Comparison check passed: (Connections) >100 >200 = '59'


上の例では、「Connections」という変数およびステータスが 100 以上になったとき警告レベル、200 以上になったとき致命レベルとして検出します。さらに /tmp にキャッシュディレクトリを指定して、90 秒の出力結果をキャッシュしています。

mysql_health_check プラグインを使うとさらに MySQL の内部の内部まで監視することができるので、とても便利です。

この他にも MySQL を監視するプラグインはたくさんありますし、自分で作成している人も多いと思います。
ちなみに僕は、カジュアル派なので、今のところ今回紹介した Nagios プラグインだけを使って MySQL を監視しています。

明日は、@sohgoh さんです。

今のところ、僕の場合 Firefox で LDR などで情報収集しているわけですが、ブックマークは Delicious をメインで使っていて、Firefox の Delicious 拡張を使っています（最近のデザイン変更で、ログイン画面が Delicious 拡張経由だとそのままなわけですが・・・）。

この拡張は、OSX だと Command+D で Delicious のブックマーク画面が表示されて、簡単にブックマークすることができます。ここで Delicious でブックマークしたあと、ifttt 経由ではてブにブックマークしたいと思って、はてブのメールでブックマークする機能を使って設定してみました。

設定方法は、ifttt のタスクを作成することで可能です。

1. ifttt にアカウント登録します
2. Delicious のチャンネルを有効にします
3. ifttt のタスクを作成します
4. if は、Delicious の Any new public bookmark されたときにします
5. then は、Gmail 経由で、自分のはてブ専用のメールアドレスにメールを送信するようにします（はてブの専用のメールアドレスは、設定画面のメールタブから確認することができます）
6. メールの本文を、次のような内容にして、タスクを作成します

タスクを作成した画面は、次のようになります。

このタスクは、タスクの実行に少し時間がかかるので注意しましょう。

これで、Delicious にブックマークしたら、同じタグ、コメントで、はてブに自動的にブックマークすることができるようになりました。

ifttt は、かなり便利なウェブサービスで、こういうネットライフを豊かにするサービスは、とても素敵ですね。

まずは、hg をインストールします。

$ brew install python
$ easy_install Mercurial


Grow のソースコードを入手します。

$ hg clone https://code.google.com/p/growl/


Grow のビルドの準備を開始します。

$ cd growl
$ export BUILT_PRODUCTS_DIR=`pwd`
$ ./generateHgRevision.sh


GrowlVersion.h を、次のように変更します。

7c7
< #include "hgRevision.h"
---
> #include "include/hgRevision.h"


そうすると、include/hgRevision.h が生成されて、次のような内容になります。

#define HG_REVISION 5809
#define HG_REVISION_STRING "5809"


あとは、XCode を開いて、次の手順でビルドするだけです。

1. Xcode 4.2 で Growl.xcodeproj を開く
2. ビルドターゲット を Growl.app にセットする
3. Project: Growl と Targets:Growl.app の「Code Signing Identity」を「Don’t Code Sign」に設定する

ビルドしたら、Products にある Growl.app をアプリケーションディレクトリにコピーするだけです。念のため、前のバージョンがインストールされているときは、Release/Uninstall Growl.app を実行してアンインストールしておくといいでしょう。

Growl のバージョン情報を見ると 1.3 になっているわけですが、App Store にある Grow のバージョンは 1.3.1 となっています。一瞬古いバージョンなのかなと思ったんですが、hg のバージョンを埋め込むようにしたあと変更されたようです。興味のあるの人は、GrowlVersion.sh の変更履歴を参照するといいと思います。

この方法なら、Growl のソースコードが公開されている限り、自分でビルドすればいいですね！

今のところ、各自あるいはペア・グループ単位で、次のようなことをやろうかなと思っています。ようは RRDtool についてみんなで勉強しましょうね的な会です。

• rrdtutorial をやる（公式、日本語翻訳版）
• rrd-beginners をやる、あるいはその翻訳をして公開する
• RRDtool の各ツールの使い方を学ぶ、あるいはその翻訳をして公開する
• RRDtool の各種バインディングツールを使ってみる
• RRDtool のギャラリーを眺めながら、自分でも同じようなものを実装してみる
• 既存のツールをチューニングしてみる
• RRDTool を使ったモニタリングツールを自作してみる

かなりマニアックなハッカソンというか、勉強会チックなものなので、数人希望がいるようであれば、次の予定ぐらいでゆるく開催したいと思います。

• 時期：2012年1月下旬〜2月くらいの予定、土日祝の午後半日程度予定（平日の夜でもいいかもしれないけれど、時間が短くなるので）
• 場所：東京都内（たぶん、渋谷・新宿近郊あたりになるかと思いますが、有料の場所を使う可能性がありますがそのときは会場費がかかってしまいます、参加者の皆さんと相談したいと思います）
• 内容：RRDtool に関して自分の好きなことを各自あるいはペア・グループ単位で、上の内容でもよいし、好きなことをやる

ちなみに僕は RRDtool に関してまったくの初心者なので、安心してくださいw。RRDtool を使っているグラフツールを使っている 1 ユーザですので^^。

今までなかなか RRDtool 参加希望したいという方は、ブクマ・ツイッターなどでゆるく表明していただければと思います。５人ぐらいいたら開催しようと思います。

公式ドキュメントはここにあります。

まず、CDH3 ではユーザまわりの変更が入っています。

CDH3 でのユーザアカウントの変更

•  hdfs: NameNode, DataNodes, Secondary NameNode（従来の hadoop ユーザにあたります、CDH3 にアップデートすると自動的に hadoop ユーザが hdfs ユーザに変更されるので注意してください）
• mapred: JobTracker and TaskTrackers（JobTracker と TaskTracker 用に追加された新しいユーザになります）

ローカルファイルシステムのディレクトリオーナー

• dfs.name.dir: hdfs:hadoop 700
• dfs.data.dir: hdfs:hadoop 700
• mapred.local.dir: mapred:hadoop 755
• HADOOP_LOG_DIR: anyuser:hadoop 775

HDFS 上のディレクトリオーナーの変更

• mapred.system.dir: mapred:hadoop 700
• / (root directory): hdfs:hadoop 755

Step1: アップグレードする前の準備
1. すべての Hadoop サービスをシャットダウンします

$ sudo -u hadoop /usr/lib/hadoop-0.20/bin/stop-all.sh


2. hadoop ユーザのプロセスがないことを動いていないことを確認します

$ sudo su hadoop -s /bin/bash -c "jps"


3. NameNode マシン上の HDFS メタデータをバックアップします
SecondaryNode がある場合は、NameNode のおメタデータをバックアップしているためスキップしても大丈夫だと思います
メタデータをバックアップするために、dfs.name.dir の場所を確認します

$ grep -C1 dfs.name.dir /etc/hadoop/conf/hdfs-site.xml

dfs.name.dir
/var/lib/hadoop-0.20/cache/hadoop/dfs/name
$ cd /var/lib/hadoop-0.20/cache/hadoop/dfs/name
$ sudo tar -cvf /root/nn_backup_data.tar .


Step2: Hadoop のコアパッケージ hadoop-0.20 のアップグレード

1. local yum repostiory 設定で、CDH2 から CDH3 に切り替えます

2. すべての Hadoop クラスターのホストにおいて、パッケージのアップグレードする

$ sudo yum upgrade hadoop-0.20*
Hadoop version 0.20.1+169.127-1 -> 0.20.2+923.142-1 になる（2011/11/15 時点）


その他必要なパッケージを、それぞれのホストにインストールします

• NameNode: hadoop-0.20-namenode, hadoop-0.20-jobtracker
• Secondary NameNode: hadoop-0.20-secondarynamenode
• Slave: hadoop-0.20-datanode, hadoop-0.20-tasktracker

3. hadoop-env.sh の HADOOP_MASTER 環境変数を確認します（僕の環境の場合、設定がなかったのでスキップしました）

4. Hadoop システムアカウントを確認します

$ id hdfs
$ id mapred

hadoop ユーザは削除されるので注意します

5. HDFS データのオーナーを確認します
hdfs-site.xml の dfs.name.dir, dfs.data.dir の設定を確認します
dfs.data.dir の設定がない場合は、hdfs-site.xml に追加します

hdfs-site.xml の設定が変わるので注意しましょう。hadoop-0.20-conf-pseudo をインストールして、その設定ファイルをベースに設定するといいと思います。また、hadoop-0.20-dfs.data.dir の設定が hdfs-site.xml に存在しないと CDH3 はシャットダウンしてしまうらしいので注意しましょう


$ ls -ld /var/lib/hadoop-0.20/cache/hadoop/dfs/name
drwxr-xr-x 4 hdfs hadoop 4096 Nov 6 16:49 /var/lib/hadoop-0.20/cache/hadoop/dfs/name/


もし、オーナーがおかしければ変更します

$ sudo chown -R hdfs:hadoop /var/lib/hadoop-0.20/cache/hadoop/dfs/name


6. MapReduce のローカルディレクトリのオーナーとパーミッションを変更します

$ ls -ld /var/lib/hadoop-0.20/cache/hadoop/mapred/local
drwxr-xr-x 4 hdfs hadoop 4096 Nov 6 16:38 /var/lib/hadoop-0.20/cache/hadoop/mapred/local/
$ sudo chown -R mapred /var/lib/hadoop-0.20/cache/hadoop/mapred/local


7. すべてのホストのログディレクトリのオーナーとパーミッションを変更します

$ sudo chgrp hadoop /var/log/hadoop-0.20
$ sudo chmod g+w /var/log/hadoop-0.20
$ sudo chown mapred /var/log/hadoop-0.20/userlogs


8. HDFS メタデータをアップグレードします
別のターミナル画面で、NameNode のログを確認しておきます

namenode$ sudo tail -f /var/log/hadoop-0.20/hadoop-hadoop-namenode*


メタデータをアップグレードします

namenode$ sudo /etc/init.d/hadoop-0.20-namenode upgrade

ログで、次のメッセージが表示されると成功したということになります
2011-11-06 17:15:27,390 INFO org.apache.hadoop.hdfs.server.common.Storage: Upgrade of /var/lib/hadoop-0.20/cache/hadoop/dfs/name is complete.
NameNode は、DataNode に接続するまでの間、セーフモードになっているため、注意しましょう（このあと DataNode を開始すると、自動的にセーフモードが解除されます）

9. HDFS を開始します
それぞれのスレーブホストにて、HDFS を開始します

slaveX$ sudo /etc/init.d/hadoop-0.20-datanode start

すこし待って、DataNode のアップグレードが完了すると、次のメッセージが NameNode のログに出力されます

Safe mode will be turned off automatically in X seconds.

DataNode のアップグレードプロスが完了すると、NameNode は自動的にセーフモードを終了して、HDFS は通常のフルオペレーションが可能になります。そのときは、NameNode のログに、次のような内容が出力されます

...
The reported blocks 8 has reached the threshold 0.9990 of total blocks 8. Safe mode will be turned off automatically in X seconds.
...
2011-11-07 18:33:28,009 INFO org.apache.hadoop.hdfs.StateChange: STATE* Leaving safe mode after 137 secs.
...
2011-11-07 18:33:28,009 INFO org.apache.hadoop.hdfs.StateChange: STATE* Safe mode is OFF.
...


Safe Mode 中かどうかは、次のコマンドで確認することができます

namenode$ sudo hadoop dfsadmin -safemode get
Safe mode is OFF


10. HDFS 上の mapred.system.dir ディレクトリのオーナーを変更します
NamaNode に mapred.system.dir の設定がない場合は、hdfs://namenode/var/lib/hadoop-0.20/cache/hadoop/mapred/system になるため、なければ作成します。

namenode$ sudo -u hdfs hadoop fs -chown -R mapred hdfs://namenode/var/lib/hadoop-0.20/cache/hadoop/mapred/system


11. それぞれのホストで、SecondaryNameNode と MapReduce を開始します

secodarynamenode$ sudo /etc/init.d/hadoop-0.20-secondarynamenode start
slaveX$ sudo /etc/init.d/hadoop-0.20-jobtracker start
slaveX$ sudo /etc/init.d/hadoop-0.20-tasktracker start


念のため、プロセスを確認します

$ ps eaf | grep -i job
$ ps eaf | grep -i task


12. 基本的なクラスター操作を確認します
適当なディレクトリを作成します

namenode$ sudo -u hdfs hadoop fs -mkdir /test

HDFS のユーザディレクトリのオーナーを変更してみます

$ sudo -u hdfs hadoop fs -chown joe /user/joe


通常ユーザで計算ジョブを走らせてみます

$ hadoop-0.20 jar /usr/lib/hadoop-0.20/hadoop-0.20.2*examples.jar pi 10 10000
…
Job Finished in 61.474 seconds
Estimated value of Pi is 3.14120000000000000000


13. HDFS アップグレードを終了させます

namenode$ sudo -u hdfs hadoop dfsadmin -finalizeUpgrade

http://:50070/ の Upgrades 欄を確認して「There are no upgrades in progress.」と表示されていることを確認します。このメッセージが表示されていれば、無事成功したことになります。

その他、実際の運用面では、Hadoop のジョブは、mapred ユーザで実行したほうが楽です。（他のユーザで実行するには、HADOOP_LOG_DIR やその他 Hadoop のディレクトリのパーミッションを変更する必要があります）

すこしだけ、ジョブの実行スピードが速くなったような気がします。

Nginx は、今まで本番環境では使ったことがないので、かなり設定ファイルが分かりやすいし、かなりの実戦投入している話を聞けたので、とても勉強になりました。

Webサーバ勉強会は、参加者すべて発表しないといけないため、参加人数は少ないですが、発表している中でも、みんなでわいわいとそれぞれの情報を出しあって、わいわいと勉強できるとても緩い勉強会だと思うので、皆さんも機会がありましたら参加してみてください。

そこで、gmail を利用して、ローカルの OSX からメールを送信する方法を紹介したいと思います。

まず、/etc/postfix/main.cf に、次の設定を追加します。

# gmail
relayhost = [smtp.gmail.com]:587
smtp_use_tls = yes
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/Users/naoya/etc/sasl_passwd
smtp_sasl_tls_security_options = noanonymous
smtp_sasl_mechanism_filter = plain
smtp_tls_security_level = secure
smtp_tls_CApath = /Users/naoya/etc/ssl/certs

gmail の 587 番ポート経由でメールを送信する設定になります。

/Users/naoya/etc/sals_password には、次のような感じで gmail アカウント情報を書いておきます。

[smtp.gmail.com]:587 <gmail account>@gmail.com:<password>

gmail アカウント情報を書いたら、postmap コマンドでデータベースを作成します。


$ postmap /Users/naoya/etc/sasl_passwd


次に gmail 経由で認証する場合、次のような認証警告が表示されるので、これを対策します。

Oct 28 18:36:17 localhost postfix/smtp[12237]: certificate verification failed for smtp.gmail.com[74.125.127.108]:587: untrusted issuer /C=US/O=Equifax/OU=Equifax Secure Certificate Authority

gmail の SSL 証明書を確認します。

$ openssl s_client -connect pop.gmail.com:995 -showcerts


上のコマンドを実行すると、SSL 証明書が 2 種類出力されます。CN=Google Internet Authority の方は、/Users/naoya/etc/ssl/certs/gmail.pem、OU=Equifax Secure Certificate Authority の方は /Users/naoya/etc/ssl/certs/equifax.pem として保存します。
そのあと、次のコマンドを実行します。

$ c_rehash /Users/naoya/etc/ssl/certs


最後に、postfix はオンデマンドで起動するようになっているため、常駐起動に切り替える必要があります。
/System/Library/LaunchDaemons/org.postfix.master.plist を編集します。
次の内容を削除します。


<string>-e</string>

<string>60</string>

そして、次の行を追加します。

<key>KeepAlive</key>
<true/>

あとは、postfix を再起動します。

$ sudo launchctl unload -w /System/Library/LaunchDaemons/org.postfix.master.plist
$ sudo launchctl load -w /System/Library/LaunchDaemons/org.postfix.master.plist


これで、mail コマンドで実際のウェブアプリケーションでメールを送信することができるかを確認します。
ログは、/var/log/mail.log に出力されています。

参考ページ

• Local Mail Server for Lion
• Setting up Gmail with postfix and fetchmail on OSX and Linux laptops