この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

rick No31です。
今回は、railsログを解析するgemの紹介です

環境

request-log-analyzer 1.12.10
ruby 1.9.3p484
rails 3.0.19

Install方法

$ gem install request-log-analyzer

実行方法

$ request-log-analyzer –format rails3 log/development.log.20131212

オプション

// 解析するコントローラーを指定
–select controller TopController
// 解析するアクションを指定
–select action index
// 特定コントローラーを除外
–reject controller TopController
// html出力
–output HTML –file hoge.html

分析結果

※横棒は長いため比率関係なく短くしています
// リクエストのサマリー
Request summary
ーーーーーーーーーーー
// 解析したファイル
Processsed File: xx/log/development.log.20131212
// 解析した行数
Parsed lines: 1103450
// スキップした行数
Skipped lines: 55814
// 解析したリクエスト
Parsed requests: 276218
// スキップしたリクエスト
Skipped requests: 0
// 警告数
Warnings: no_current_request: 55814, teaser_check_failed: 73, unfinished_request_on_eof: 1
// 最初のリクエスト日時
First request: 2013-12-12 00:00:12
// 最後のリクエスト日時
Last request: 2013-12-12 23:59:11
// 解析した期間
Total time analyzed: 1 days
ーーーーーーーーーーー

// 時間あたりのリクエスト数
Request distribution per hour
0:00 ┃ 16532 hits/day ┃ ░░░░░░░░░░░░░░
1:00 ┃ 10732 hits/day ┃ ░░░░░░░░░
2:00 ┃ 6915 hits/day ┃ ░░░░░░
3:00 ┃ 4140 hits/day ┃ ░░░░
4:00 ┃ 2641 hits/day ┃ ░░
5:00 ┃ 1882 hits/day ┃ ░░
6:00 ┃ 3322 hits/day ┃ ░░░
7:00 ┃ 3991 hits/day ┃ ░░░
8:00 ┃ 6072 hits/day ┃ ░░░░░
9:00 ┃ 8218 hits/day ┃ ░░░░░░░
10:00 ┃ 8585 hits/day ┃ ░░░░░░░
11:00 ┃ 9568 hits/day ┃ ░░░░░░░░
12:00 ┃ 11037 hits/day ┃ ░░░░░░░░░░
13:00 ┃ 10558 hits/day ┃ ░░░░░░░░░
14:00 ┃ 10930 hits/day ┃ ░░░░░░░░░
15:00 ┃ 10990 hits/day ┃ ░░░░░░░░░░
16:00 ┃ 10870 hits/day ┃ ░░░░░░░░░
17:00 ┃ 18972 hits/day ┃ ░░░░░░░░░░░░░░░░
18:00 ┃ 17312 hits/day ┃ ░░░░░░░░░░░░░░░
19:00 ┃ 16320 hits/day ┃ ░░░░░░░░░░░░░░
20:00 ┃ 19573 hits/day ┃ ░░░░░░░░░░░░░░░░░
21:00 ┃ 23065 hits/day ┃ ░░░░░░░░░░░░░░░░░░░░
22:00 ┃ 22965 hits/day ┃ ░░░░░░░░░░░░░░░░░░░░
23:00 ┃ 21028 hits/day ┃ ░░░░░░░░░░░░░░░░░░

// リクエストの多い順
Most requested
xxController#index.XML ┃ 213045 hits ┃ 77.1% ┃ ░░░░░░░░░░░░░░░░░░
xxController#index.JSON ┃ 24953 hits ┃ 9.0% ┃ ░░░░░░░░░░░░░░░░░
#. ┃ 3120 hits ┃ 1.1% ┃ ░░

//HTTPメソッド毎のリクエスト数
HTTP methods
POST ┃ 193989 hits ┃ 70.2% ┃ ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
GET ┃ 82221 hits ┃ 29.8% ┃ ░░░░░░░░░░░░░░░░░░░
HEAD ┃ 8 hits ┃ 0.0% ┃

// HTTPのステータス毎のリクエスト数
HTTP statuses returned
200 ┃ 225536 hits ┃ 100.0% ┃ ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░
302 ┃ 2 hits ┃ 0.0% ┃
500 ┃ 1 hits ┃ 0.0% ┃

// リクエストの所要時間の合計
Request duration – by sum┃ Hits ┃ Sum ┃ Mean ┃ StdDev ┃ Min ┃ Max ┃ 95 %tile
xxController#index.XML┃ 171190 ┃ 4h21m19s ┃ 0.09s ┃ 0.05s ┃ 0.00s ┃ 5.73s ┃ 0.05s-0.23s
xxController#index.JSON┃ 9626 ┃ 27m38s ┃ 0.17s ┃ 0.09s ┃ 0.00s ┃ 0.79s ┃ 0.05s-0.36s
#.┃ 2518 ┃ 4m15s ┃ 0.10s ┃ 0.07s ┃ 0.00s ┃ 1.00s ┃ 0.01s-0.32s

// リクエストの所要時間の平均
Request duration – by mean┃ Hits ┃ Sum ┃ Mean ┃ StdDev ┃ Min ┃ Max ┃ 95 %tile
xxController#index.JSON┃ 9626 ┃ 27m38s ┃ 0.17s ┃ 0.09s ┃ 0.00s ┃ 0.79s ┃ 0.05s-0.36s
xxController#index.HTML┃ 1 ┃ 0.13s ┃ 0.13s ┃ 0.00s ┃ 0.13s ┃ 0.13s ┃ 0.13s-0.13s
#.┃ 2518 ┃ 4m15s ┃ 0.10s ┃ 0.07s ┃ 0.00s ┃ 1.00s ┃ 0.01s-0.32s

// 一部のレンダリング時間の合計
Partials rendering time – by sum┃ Hits ┃ Sum ┃ Mean ┃ StdDev ┃ Min ┃ Max ┃ 95 %tile
layouts/_hoge.html.erb┃ 14 ┃ 0.41s ┃ 0.03s ┃ 0.05s ┃ 0.00s ┃ 0.17s ┃ 0.00s-0.17s

// 一部のレンダリング時間の平均
Partials rendering time – by mean┃ Hits ┃ Sum ┃ Mean ┃ StdDev ┃ Min ┃ Max ┃ 95 %tile
layouts/_hoge.html.erb┃ 14 ┃ 0.41s ┃ 0.03s ┃ 0.05s ┃ 0.00s ┃ 0.17s ┃ 0.00s-0.17s

// ビューのレンダリング時間の合計
View rendering time – by sum┃ Hits ┃ Sum ┃ Mean ┃ StdDev ┃ Min ┃ Max ┃ 95 %tile
xxController#index.XML┃ 170223 ┃ 1m03s ┃ 0.00s ┃ 0.00s ┃ 0.00s ┃ 0.13s ┃ 0.00s-0.00s
xxController#suggest.JSON┃ 23254 ┃ 7.93s ┃ 0.00s ┃ 0.00s ┃ 0.00s ┃ 0.06s ┃ 0.00s-0.00s
#.┃ 2503 ┃ 0.99s ┃ 0.00s ┃ 0.00s ┃ 0.00s ┃ 0.00s ┃ 0.00s-0.00s

// ビューのレンダリング時間の平均
View rendering time – by mean┃ Hits ┃ Sum ┃ Mean ┃ StdDev ┃ Min ┃ Max ┃ 95 %tile
xxController#index.HTML┃ 1 ┃ 0.09s ┃ 0.09s ┃ 0.00s ┃ 0.09s ┃ 0.09s ┃ 0.09s-0.09s
#.┃ 2503 ┃ 0.99s ┃ 0.00s ┃ 0.00s ┃ 0.00s ┃ 0.00s ┃ 0.00s-0.00s

// DBからの応答時間の合計
Database time – by sum┃ Hits ┃ Sum ┃ Mean ┃ StdDev ┃ Min ┃ Max ┃ 95 %tile
xxController#index.XML┃ 170223 ┃ 14m39s ┃ 0.01s ┃ 0.01s ┃ 0.00s ┃ 0.83s ┃ 0.00s-0.01s
xxController#index.JSON┃ 15672 ┃ 3m34s ┃ 0.01s ┃ 0.04s ┃ 0.00s ┃ 0.49s ┃ 0.00s-0.14s
#.┃ 2503 ┃ 14.58s ┃ 0.01s ┃ 0.01s ┃ 0.00s ┃ 0.30s ┃ 0.00s-0.01s

// DBからの応答時間の平均
Database time – by mean┃ Hits ┃ Sum ┃ Mean ┃ StdDev ┃ Min ┃ Max ┃ 95 %tile
xxController#index.HTML┃ 1 ┃ 0.04s ┃ 0.04s ┃ 0.00s ┃ 0.04s ┃ 0.04s ┃ 0.04s-0.04s
xxController#index.JSON┃ 15672 ┃ 3m34s ┃ 0.01s ┃ 0.04s ┃ 0.00s ┃ 0.49s ┃ 0.00s-0.14s
#.┃ 2503 ┃ 14.58s ┃ 0.01s ┃ 0.01s ┃ 0.00s ┃ 0.30s ┃ 0.00s-0.01s

// 停止したプロセス
Process blockers (> 1 sec duration)
xxController#index.XML ┃ 2 hits ┃ 66.7% ┃ ░░░░░░░░░░░░░░░░░░░░░░░░░
#. ┃ 1 hits ┃ 33.3% ┃ ░░░░░░░░░░░░░░

// 遷移エラー
Routing Errors

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

サーバ内の任意のポートへのアクセスはSSHトンネルでも出来ますが、毎回SSH接続しなければならないのは面倒と言う事で、CentOSにstoneをインストールしてみました。
stoneはTCP/UDPのリピーターです。指定したサーバへ中継してくれます。

●stoneインストール

# cd /usr/local/src
# wget http://www.gcd.org/sengoku/stone/stone-2.3e.tar.gz

# tar zxvf stone-2.3e.tar.gz
# cd stone-2.3d-2.3.2.7
# vi Makefilelinux:
$(MAKE) FLAGS=”-O -Wall -DCPP=’\”/usr/bin/cpp -traditional\”‘ -DPTHREAD -DUNIX_DAEMON -DPRCTL -DSO_ORIGINAL_DST=80 -DUSE_EPOLL -D_GNU_SOURCE $(FLAGS)” LIBS=”-lpthread $(LIBS)” stone
↑makeに失敗するので、「-D_GNU_SOURCE」を追加します。# make linux
↑linux-sslだとmakeに失敗するので、linuxにしました。
※エラーが出なければOK

# mv stone /usr/bin/
# ln -s /usr/bin/stone /usr/local/bin/stone

# cd ..
# rm -fr stone-2.3d-2.3.2.7

●stone起動

今回はTCP80/443に来たリクエストを同じネットワーク内の192.168.x.xに同じポートで流す事にしました。
ApacheのProxyPassでも同じような事は出来ますが、スマートじゃない気がしたので、stoneを採用しました。
iptables等でポート制限している場合は解除してください。
# stone 192.168.x.x:80 80 &
# stone 192.168.x.x:443 443 &

●stone自動起動設定

再起動しても自動起動するようにrc.localに追加しておきます。
# cd /etc
# cp -a rc.local rc.local,201311
# vi rc.local/usr/bin/stone 192.168.x.x:80 80 &
/usr/bin/stone 192.168.x.x:443 443 &

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

よしだです。Rubyで破壊的メソッドを自作する方法がわからなくて調べたので紹介します。

■ 破壊的メソッドとは

Stringクラスのインスタンスメソッドなどで定義されている、インスタンス自身を変更するメソッドです。

たとえば文字列の末尾に含まれる改行を消したい場合、

irb> text = "テスト\n"
irb> text.chomp
#=> "テスト"
irb> text 
#=> "テスト\n"

のように「chomp」メソッドを使って実現できます。このときインスタンスであるtext自体に変更はなく、「chomp」のあとにtextを呼び出すと改行がついたままであることが確認できます。

これに対して破壊的メソッド「chomp!」の場合は、

irb> text = "テスト\n"
irb> text.chomp!
#=> "テスト"
irb> text 
#=> "テスト"

と、text自体に変更が加わっていることがわかります。

本稿では、このような破壊的メソッドを自分で定義する方法を紹介します。

■ 定義する

答えは簡単で、「replace」メソッドを利用することで可能です。

たとえば『文字列の末尾に「hoge」という文字列をくわえる』という破壊的メソッド「hoge!」を定義するには以下のように記述します。

class String
  def hoge!
    self.replace(self + "hoge")
  end
end

たったこれだけです。

■ おわりに

今回はStringクラスを例にしましたが、「replace」メソッドはいろいろなクラスで利用できるようです。適当なクラスに適当な破壊的メソッドどんどん定義していくのも面白いかもしれません。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

よしだです。最近Ruby技術者認定試験(Silver)を受けたので、そのときの手順を紹介したいと思います。

■ 目的

Ruby技術者認定試験はその名の通り、プログラミング言語Rubyの技術試験です。現在レベルがSilver、Goldとあるようです。このうちSilverはそこまで難易度が高くなので、本校では書籍を購入するほどではない・できるだけ勉強にお金をかけたくないという浅はかな考えで試験に挑み、合格することを目的とします。

■ ミニツク

書籍も買わないとなると試験でどのような問題がでるかも検討がつかず、対策のしようがありません。そこでウェブ上で疑似問題を出題してくれるミニツクを利用します。このサービスはRubyの産みの親、まつもとひろゆきが所属する組織によって開発されたサービスのようです。

いろいろな内容に対応していて、Ruby技術者認定試験(Silver)用にも全６章の問題セットが用意されています。だいたい１時間くらいで全問回答できる程度の内容になっています。問題の形式は４択で、難易度もそこまで高くなく、普段からRubyを使っていて簡単なコードなら対話コンソール(irb)なしでも読めるような方なら、ほとんどつかえることなく解き進むことができると思います。

■ あとは勉強あるのみ

勉強は次のような流れでおこなうとスムーズかと思います。

• 1. ミニツクで問題を解く
• 2. 気になるところ・わからないところはirbで調べる
• 3. それでも分からない場合はドキュメントを読む

これを全６章、２周くらいすればおおよそ試験合格水準まで学習できると思います。時間にして２時間程度で試験勉強完了です。

■ 注意点

試験勉強・受験に際して必要な注意点をまとめてみました。

• ◇ Ruby 1.8系がベース (2013/10/26現在)
• ◇ プロメトリックの受験資格検査が厳密

Ruby 1.8系がベース

Rubyは、現在2.0系まででていて、1.8系は2013年6月時点でサポート対象外となっています。多くの方がすでに上位バージョンを使っている中で、あえて古いバージョンの動作に付いて学ぶことになるので注意が必要です。

プロメトリックの受験資格検査が厳密

受験には写真入の証明書＋その他の証明書（免許証＋保険証）の２つが必要になります。どちらか一方が欠けても受験資格がないと見なされ、安くない受験費が水の泡になってしまいます。僕はここでやってしまいました・・・（免許証の有効期限が切れていないか確認することをお勧めします！）。

■ おわりに

今回はRuby技術者認定試験(Silver)とその勉強方法について紹介しました。少しでも参考にしていただければ幸いです。近々Goldの方も受験するつもりなので、次はそちらの紹介もしたいと思います。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

rick No30です。
今回は、MySQLのプロセスの確認方法と負荷が高すぎて止めたいプロセスを強制的に停止するときなどに使用する停止方法の紹介です

環境

MySQL5.0.95

プロセス確認方法

$ mysql -u root
> show processlist;
+——–+——+———–+———————+———+——–+—————-+——————————————————————————————————+
| Id | User | Host | db | Command | Time | State | Info |
+——–+——+———–+———————+———+——–+—————-+——————————————————————————————————+
| 3840 | root | localhost | hoge | Sleep | 105365 | | NULL |
このようなデータが表示されます。
何度か実行して消えないものは常駐しているプロセスか、固まって動かないプロセスとなります。
Id：接続識別子
User：接続しているユーザ名
Host：接続しているホスト名
db：接続しているDB名
Command：状態を表し「Sleep、Query、Kill」このようなステータスが表示されます。
Time：接続時間
State：現状の情報が表示される
Info：SQLが表示される

プロセス強制終了方法

$ mysql -u root
> show processlist;
+——–+——+———–+———————+———+——–+—————-+——————————————————————————————————+
| Id | User | Host | db | Command | Time | State | Info |
+——–+——+———–+———————+———+——–+—————-+——————————————————————————————————+
| 3840 | root | localhost | hoge | Sleep | 105365 | | NULL |

> kill 3840
これで完了
すぐに消える場合もあれば、処理が重い場合、StateがKillになりしばらくかかる場合もあります。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

今回、アップル社はOSX 10.9を無償配布した。すでに多くのユーザーがOSX 10.9を利用しており、様々な感想を持っているだろう。今回は、このフリーソフト化したOSXとそれをとりまくセキュリティ事情について考えてみよう。

■ 今回のアップデートについて

OSXの配布は、過去にも数千円程度で配っていたこともあり、今回の配布においても、同様の価格帯での配布が以前よりささやかれていた。このため、今回のアップデートも1500円くらいかな？と、筆者は考えていたこともあった。今回のアップデートは、従来のアップデートと異なる点がほかにも存在している。旧来のアップデートでは、セキュリティパッチの兼ね合いもあり、新しいOSを出す際には、必ず旧来のOSに対してもセキュリティパッチを提供していた。しかしながら、今回のアップデートには、旧来のOSXにアップデートが含まれておらず、数多くの脆弱性のあるOSXを使わずに、新しいOSXを使わせようとした風潮が見て取れる。

また、従来のアップデートでは対象外とされていた古いMacも今回のアップデートでは利用可能となり、今から5年以上前に提供されたMacも最新OSを利用可能となる。

■ 古いMacを使うとどうなる？

旧来の古いMacで、最新のOSを利用しようとした場合、確かに利用することは可能だろう。しかし、快適に利用するにはほど遠いと考えられる。まず、めもりの消費量が非常に多いことがすでに予測されている。手元の、この原稿をタイプしているMacの場合、起動時のメモリ使用率が、すでに99%近く埋まっていることがある。このMacは、12Gバイトのメモリを搭載しており、従来の発売されているMacに比べても、遜色のないメモリであることはおわかりだろう。

確かに、バックグラウンドで利用しているアプリはOSX 10.9に於いては、メインメモリ上で圧縮されているため、ほとんどの場合はメモリにそれほど気を遣う必要はないかもしれない。しかしながら、それは高速なメモリと高速なSSDを搭載しているためであり、従来の古いメモリや古いハードディスクを搭載している場合は、遅く感じることもあるだろう。

■ 今回のアップル戦略をどうみる？

まず、OSX 10.9が利用できるユーザー数を圧倒的に増やすことで、マイクロソフトとの差を縮めようとしていることが容易に予測できる。

また、従来のMacユーザーが利用した場合、遅さに耐えきれずに従来のMacを手放し、新しい「リーズナブル」なMacを買ってくれるかもしれない。こうして、アップルは虎視眈々と、古いMac利用者を新しいMacへ導き、Windowsにいくのをブロックしているように見える。いずれ、この結果はわかることだが、きっと、アップルとしてはOSXをフリーにすることで、新しいMacの購入数を増やすことに成功するだろう。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

CentOSでyum updateしたらcrmコマンドが無くなりました。
理由は解らないけど、crmを捨てて、新しい(？)pcsコマンドに移行する感じなのかと。
crm使って、今までやっていた事がpcsだとどうやるか、よく解らなかったので、updateを暫く凍結してました。
が、それじゃいけないと思い、ググったり、ヘルプ見たり、試したりして、やっと同じ事が出来るようになったので、対照表と言いつつ、表じゃないけど、纏めました。

●pcsインストール

これをやらないと始まらない。

# yum -y install pcs

●crmと同じ事が出来るpcsコマンド

それぞれが何をするコマンドかは別の所で調べてください。

# crm configure property stonith-enabled=”false” no-quorum-policy=”ignore” default-action-timeout=”240″ default-resource-stickiness=”200″
　↓
# pcs property set stonith-enabled=”false” no-quorum-policy=”ignore” default-action-timeout=”240″ default-resource-stickiness=”200″
# crm configure rsc_defaults resource-stickiness=”INFINITY” migration-threshold=”1″
　↓
# pcs resource rsc defaults resource-stickiness=”INFINITY” migration-threshold=”1″
↑コマンドが変わったみたいで使えなくなった(2013/11/16)
# pcs resource defaults resource-stickiness=”INFINITY” migration-threshold=”1″
# crm configure primitive mailto ocf:heartbeat:MailTo params email=”warning-root@localhost” subject=”[Pacemaker]”
　↓
# pcs resource create mailto ocf:heartbeat:MailTo params email=”warning-root@localhost” subject=”[Pacemaker]”
※更新はcreateの代わりにupdate
# crm configure primitive vip ocf:heartbeat:IPaddr2 params nic=”eth0″ ip=”192.168.11.210″ cidr_netmask=”24″ op monitor interval=”20s”
　↓
# pcs resource create vip ocf:heartbeat:IPaddr2 params nic=”eth0″ ip=”192.168.11.210″ cidr_netmask=”24″ op monitor interval=”20s”
# crm configure primitive drbd ocf:linbit:drbd params drbd_resource=”r0″ drbdconf=”/etc/drbd.conf” op monitor interval=”20s”
　↓
# pcs resource create drbd ocf:linbit:drbd params drbd_resource=”r0″ drbdconf=”/etc/drbd.conf” op monitor interval=”20s”
# crm configure ms drbd-clone drbd meta master-max=”1″ master-node-max=”1″ clone-max=”2″ clone-node-max=”1″ notify=”true”
　↓
# pcs resource master drbd-clone drbd master-max=”1″ master-node-max=”1″ clone-max=”2″ clone-node-max=”1″ notify=”true”
# crm configure primitive cluster ocf:heartbeat:Filesystem params device=”/dev/drbd0″ fstype=”ext3″ directory=”/cluster” op monitor interval=”20s”
　↓
# pcs resource create cluster ocf:heartbeat:Filesystem params device=”/dev/drbd0″ fstype=”ext3″ directory=”/cluster” op monitor interval=”20s”
# crm configure primitive mysql ocf:heartbeat:mysql params binary=”/usr/bin/mysqld_safe” op monitor interval=”10s”
　↓
# pcs resource create mysql ocf:heartbeat:mysql params binary=”/usr/bin/mysqld_safe” op monitor interval=”10s”
# crm configure primitive apache ocf:heartbeat:apache params configfile=”/etc/httpd/conf/httpd.conf” port=”80″ op monitor interval=”20s”
　↓
# pcs resource create apache ocf:heartbeat:apache params configfile=”/etc/httpd/conf/httpd.conf” port=”80″ op monitor interval=”20s”
# crm configure group nfs-group mailto vip cluster mysql apache
　↓
# pcs resource group add nfs-group mailto vip cluster mysql apache
※リソース削除はaddの代わりにremove_resource
# crm configure colocation nfs-group_on_drbd inf: nfs-group drbd-clone:Master
　↓
# pcs constraint colocation add nfs-group drbd-clone INFINITY with-rsc-role=Master
# crm configure order nfs-group_after_drbd inf: drbd-clone:promote nfs-group:start
　↓
# pcs constraint order promote drbd-clone then start cluster
# crm
# cib new ~/pcs_cfg
# configure ・・・
# cib commit ~/pcs_cfg
# quit
↓
# pcs cluster cib ~/pcs_cfg
# pcs -f ~/pcs_cfg ・・・
# pcs cluster push cib ~/pcs_cfg
↑コマンドが変わったみたいで使えなくなった(2013/11/16)
# pcs cluster cib-push ~/pcs_cfg
# crm configure show
　↓
# pcs cluster cib
# crm_mon -1
　↓
# pcs status
※crm_monも使えます。
# crm resource move nfs-group host1 force
　↓
# pcs resource move nfs-group host1 force
↑ホスト名とforceは指定出来ませんでした。(2013/11/25)
# pcs resource move nfs-group
※host1は実際のホスト名
# crm configure edit -> 「node host1」の行を削除
　↓
# cibadmin –delete –obj_type nodes –crm_xml ”
# cibadmin –delete –obj_type status –crm_xml ”
※host1は実際のホスト名

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

MongoDBとNagiosをPacemakerで起動制御出来るようにした時のメモです。
ApacheやMySQL等は専用のスクリプトが用意されていますが、MongoDBとNagiosのは無くて、作るのも労力なので、汎用的に使えそうなanythingで代用しました。

●Pacemakerリソース追加

既にyum updateしてcrmコマンドが無くなっているので、pcsを使います。
crmの方は、yum updateしたらcrmコマンドが無くなった！(pcsコマンド対照表)も参考にしてください。

・MongoDBの場合

Nagios Pluginのcheck_tcpを使って、死活監視をしています。

# pcs resource create mongodb ocf:heartbeat:anything params \
	user="mongodb" \
	binfile="/usr/bin/mongod" \
	cmdline_options="-f /etc/mongodb.conf > /dev/null 2>&1" \
	pidfile="/var/run/mongodb/mongodb.pid" \
	monitor_hook="/usr/lib64/nagios/plugins/check_tcp -H localhost -p 27017" \
	op monitor interval="20s"
# pcs resource group add nfs-group mongodb

・Nagiosの場合

Nagiosはサービスに影響がないので、落ちてもフェールオーバしないように死活監視はしてません。
Nagios自体は外部監視するのが良いと思います。

# pcs resource create nagios ocf:heartbeat:anything params \
	user="nagios" \
	binfile="/usr/bin/nagios" \
	cmdline_options="-d /etc/nagios/nagios.cfg" \
	pidfile="/var/nagios/nagios.pid"
# pcs resource group add nfs-group nagios

●anythingカスタマイズ

上記で終わりと思いきや、実際には動きません。
理由はanythingで作ったPIDファイルをMongoDBやNagios側でも作成して上書きしてしまう為です。
anythingが使いたいPIDではなくなってしまう。。。
別のファイルを指定したりもしましたが、上手く動かず断念！
なので、少し細工します。但し、元々の挙動でも動くように。

# cd /usr/lib/ocf/resource.d/heartbeat
# cp -a anything anything,201309
# vi anything

### START 2013/09 taka ###
#		eval $cmd > $pidfile
		eval $cmd > $pidfile.tmp
		sleep 1
		if [ -e $pidfile ]; then
			rm -f $pidfile.tmp
		else
			mv -f $pidfile.tmp $pidfile
		fi
### END ###

●まとめ

これで無事、意図通り動くようになりました。
見ての通り、起動ユーザやコマンド(起動スクリプトを見れば解ります)と監視コマンドを用意すれば、MongoDBやNagios以外にも利用出来ます。

●追記(2013/11/04)

yum updateしたらanythingが無くなり、Corosyncが停止出来なくなりました。（crmに続き、またか〜）
幸いバックファイル(anything,201309)が残っていたので、そいつをベースに再度カスタマイズを施し修復！

新規構築等で最初からない場合は、下記等から入手してください。
https://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/anything

そもそもyum updateする時はCorosync止めてからじゃないと危険だね。
再起動したまま帰ってこないくて、最悪、オンコールリブートになりそうな。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

「ThinReports Editor」と「ThinReports Generator」 があればエディタで作成した形に

データを出力できるようになり、納品書等の帳票が簡単に作れます。

■ 動作環境

Ruby 1.8.7,1.9.3

■ １、「ThinReports Generator」をインストール

まずはRailsから出力するための必要な「ThinReports Generator」をインストールします。

$ gem install thinreports

※Ruby1.8.7の場合は、別途 json のインストールが必要

$ gem install json

■ ２、「ThinReports Editor」 のインストール

次にPDFのデザイン作成に必要な「ThinReports Editor」 をインストールします。

下記のURLにアクセスして自分のOSにあったものをインストールしてください。

http://www.thinreports.org/download/

インストールするものは以上です。

参考：http://osc.matsukei.net/projects/thinreports/wiki/Installation_Guide

■ ３、PDFのレイアウトを作成する

先ほどインストールした「ThinReports Editor」をつかい.tlfファイルを作成します

下記のURL先で使い方がわかると思います。

http://osc.matsukei.net/projects/thinreports/wiki/Getting_Started

.tlfファイルを作成し終わったらRailsの/public/の下にでも置いてください。

■ ４、PDFにデータを出力してダウンロードする

このアクションが呼ばれればPDFをダウンロードできます。

require ‘thinreports’

~~~~~~~~~~

~~~~~~~~~~

def pdf_download

　#Reportオブジェクトの生成、先ほど作ったレイアウトの読み込み

　report　=　ThinReports::Report.new　:layout　=>　”/public/pdf_layout”

　#新しいページを作る際にここが呼ばれます

　report.events.on　:page_create　do　|e|

　　e.page.item(:page_num).value(e.page.no)　#現在のページ数入力

　end

　#PDFを生成するときにここが呼ばれます

　report.events.on　:generate　do　|e|

　　e.pages.each　do　|page|

　　　page.item(:page_total).value(e.report.page_count)　#総ページ数入力

　　end

　end

　#ページを作成し、データを入力していきます。

　report.start_new_page　do　|page|

　　page.item(:name).value(‘名前’)

　　#リストを作っていた場合はリストに入力していきます。

　　for　i　in　0..10　#10行分

　　　page.list(:list_test).add_row do |row|

　　　　row.item(:quantity).value(“数量#{i}”)

　　　　row.item(:price).value(“値段#{i}”)

　　　end

　　end

　end

　#PDF生成

　send_data report.generate,　:filename　=>　”ファイル名.pdf”,

　:type　=>　’application/pdf’,

　:disposition　=>　’attachment’

end

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

先日、某所で行われたペンテスター（脆弱性診断を行っているひと）たちにの寄り合いに出かけ、そのときに議題として上った話を、いくつかかいつまんで解説してみよう。

■ いま、脆弱性診断業界で何が起きているのか？

ペンテスター業界全般で、システム上の後継者問題が浮上している。後継者問題といっても、人としての後継者ではなく、システム的な後継者の話だ

1. IE 8
2. Chrome 最新版
3. Firefox 最新版

この３つで共通している問題がある。それは、webアプリケーションを診断する上で、比較的見つけやすい脆弱性である、XSSを検知することが出来ないブラウザだ。

ユーザーにとって、XSSは時にはセッションハイジャックをもたらすやっかいな存在だが、各ブラウザーベンダーが、ブラウザそのものでXSSが出来ない対策を施し始めた。

この事は、ユーザーそのものとして見た場合、非常にウェルカムな考え方だが、脆弱性診断を行っている場合、診断に用いているブラウザによっては、XSSが存在しているにもかかわらずあたかもそれが存在していないかのように誤検知してしまう恐れがある。

■ では、どうするのが良いのか？

代替案として、ブラウザに搭載された互換モードを利用するという考え方もある。しかしながら、互換モードはあくまでも表示上の互換性を維持するための物であり、XSSをはじめとするいくつかの再現しない脆弱性について、互換表示する物ではない。そのため、

まもなくサポートが終了する、Windows XP を利用し、IE6とIE7を確保する

といった解決策が必要となってくる。当然、これらのOSを使用することはウイルスに感染したり、外部からの攻撃を受けやすくなる等の問題があるため、現時点に於いて、一般利用者に通常はWindows XPの採用は推奨することはない。しかしながら、今回の様に誤検知の恐れがある以上ペンテスターにとっては、完全な再現性を担保するため、仮想環境の中でWindowsを稼働させ、診断が終わるたびに、元の安全な状態に戻すといった方法や、復元ポイントを用いた、環境の確保が必要不可欠となる。

■ Windows XP で安全にwebアプリケーション診断に使うには？

先ほど述べたとおり、Windows XPは来年春にマイクロソフトによる正式サポートが終了する。このため、現状できうる限りのセキュリティパッチやサービスパックなどは適用しておき、その状態をマスターとして保存し、必要に応じて呼び出すのが良いだろう。当然として、アンチウイルスは導入し、EMETと呼ばれる、脆弱性を緩和させるフレームワークを導入することも慣用だろう。

今後、ブラウザが進化するに従って、従来は検知出来た脆弱性が益々検知することが難しくなることが十分予測される。もしかしたら、IE7やIE8といった、比較的最近のバージョンも保持対象となる日が訪れる事になるかもしれない。一般利用者にとっては、セキュアな方向にすすむため、非常にうれしい状況に有るだろうが、ペンテスターとしてみると、非常に悩ましい問題の1つと言えよう。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

Unicode正規化 norm_KCとnorm_KDの注意点特殊な文字に対して、別文字になってしまいます。
例：
irb(main):004:0> query=”２５０℃”
=> “２５０℃
irb(main):005:0> q = query.downcase.to_u.norm_KC.to_s
=> “250\xC2\xB0C”
irb(main):006:0> q.force_encoding(“UTF-8”) if q.respond_to?(:force_encoding) => “250°C”

一文字「℃」は2文字「°C」になってしまう。

Unicode正規化を参照

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

文字列のblank?メソッドは正規表現を使っていますので、UTF-8的に正しいバイト列ですかチェックしています。

型によって、blank?の処理が違います。

文字列の場合、正規表現で判断しています。

配列の場合、Arrayのempty?と同じです。

ハッシュの場合、Hashのempty?と同じです。

blank.rbの一部ソースコード：

class String

def blank?

self !~ /[^[:space:]]/

end

end

class Array

alias_method :blank?, :empty?

end

class Hash

alias_method :blank?, :empty?

end

Ruby 1.9 でUTF-8的に正しくないバイト列がある文字列を扱っていると、

正規表現マッチや gsub といったメソッドを使っているところで ArgumentError: invalid byte sequence in UTF-8 例外が発生します。

文字列を生成したときではなくて正規表現マッチなんかをしたときに始めてエラーが出るのです。

例：

str = “\xC1\xB9\xA4\xB1\xA4\xF3\xA4\xC1\xA4\xF3\xBD\xC1”

begin

str.blank?

rescue => e

p e # ArgumentError: invalid byte sequence in UTF-8

end

文字列のblank?メソッドは正規表現を使っていますので、UTF-8的に正しいバイト列ですかチェックしています。

配列の要素に対して、正しいUTF8バイト列をチェックするため、要素に対して、blank?を使用します。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

今回は、脆弱性検出ツール「iFuzzMaker」の有効性と想定外データの受け取りに伴う脆弱性診断について考えてみよう。

■ iFuzzMakerについて

iFuzzMakerは、IPAがオープンソースで提供している、画像閲覧ソフトの脆弱性検出ツールだ。このツールを使うことにより、意図的に加工した画像を作成し、この画像を検査したいツールに入れることにより、システムクラッシュやバッファオーバーフローの脆弱性などを見つけることが出来る。この様な、様々な情報を相手に入れる（食わせる）ことにより、診断する手法をファジングと呼び、知識が無い状態でも脆弱性の有無を確認することが出来る。

■ 想定外のデータの受け入れについて

上記の場合は画像表示ソフトを対象としているが、これを他のシステムに流用することが出来る。たとえば、画像表示ソフトが厳密に画像であるか否かをチェックしていない場合、ワードファイルの拡張子を、.jpg や .jpeg に変更する事により、画像表示ソフトが厳密に画像処理を行っているかを確認することが出来る。

また、同様に他のサービスやシステムに於いても、通常受け入れるサイズ以上のデータを無理矢理入れることにより、バッファオーバーフローの脆弱性を発見することが出来る。

たとえば、データの受け入れサイズが、30バイトしかないところに、厳密にその受け取りサイズをチェックしていない場合、60バイトのデータを受け入れたとする。30バイトはそのままスタックされるが、残りの30バイトはプログラムの一部を書き換え、その先に意図的なプログラムコードを入れて権限昇格を狙う。これがバッファオーバーフローの脆弱性を利用する、主な考え方だ。

■ サービス稼働しているシステムへの脆弱性検査

バッファオーバーフローの脆弱性が発生するのは、データの受け入れが明示的に示されている物だけでは無い。たとえば、80/tcp では、通常webサービスが稼働している。このポートに対して、通常はwebブラウザを使って接続しているが、明示的にtelnetを使って接続する方法もある。このほか、予め作成したデータを強制的に流し込む場合は、次のように入力する。

cat 送り込むデータ | nc 接続先IP ポート番号

この方法で、強制的に情報を流し込むことが出来る。通常のサービスでは、特定通信の内容と異なる場合は、その時点で接続を切って、受け入れを中止する。しかしながら、作りが甘いと、こうした情報を受け入れ続け、システムのメモリを食い尽くすまで受け入れが続く場合も有る。こうなると、復旧するにはシステムを再起動するしか方法はなくなる。

■ スマートフォンアプリの場合

複数アプリを用いて、データの受け渡しを行う場合、送り出す側と受け取る側で、厳密にデータの内容をチェックする必要が有る。先ほどの例のように、データ送信側を偽装したデータ送信が行われた場合、最悪アプリがクラッシュしたり、OS毎巻き込んでスマートフォンが終了したり再起動したり、フリーズすることも十分に考えられる。受け取るデータが常に正しいと考えず、必ず受け取ったデータが正しい情報で有るかをチェックしてから、加工するようにしないと、大変なことになるかもしれない。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

Rubyでuse_resultを使い、Mysqlから大量データをSELECTする

■ バックグラウンド処理でのMySQLの大量データの扱い

MySQLで大量データを扱うコツは、フロントエンドとバックグラウンドでは結構異なることがあります。

代表的なもので言えば、インデクスが挙げられます。

フロントエンド処理において大量データから必要なデータを抽出するためには、インデクスの作成がかかせません。

もしインデクスがなければ、テーブル内をフルスキャンを行わなければならず即時に応答を返すことができなくなります。

対してそのテーブルがバックグラウンド処理でしか使用されない場合、インデクスが必要不可欠かと言うとそうでもありません。

即時応答の必要がないからです。

インデクスがあることでテーブルの更新処理が遅くなり、足かせとなってしまう場合もあります。

今回はバックグラウンド処理でMySQLから大量データを取得する際のノウハウの一つが題材です。

■ MySQLでの大量データSELECT

数千万レコードレベル以上のデータが保存されているテーブルから全レコードを取得しなければいけない場合、

通常軽量言語で使用するMySQLライブラリのqueryメソッドで全レコードを取得するような処理を実行すると

データがメモリに乗りきれなくなり、Out Of Memoryエラーとなります。

回避策としてLIMIT・OFFSETを使って、例えば数千件程度ずつに区切ってデータ取得するといった方法もあるでしょう。

しかし、SELECTの途中でテーブルの内容が更新されたりした場合、並び順が変わってしまって正しく全件を取得できない可能性があります。

■ use_result

MySQLのC言語のライブラリにmysql_store_resultというメソッドが用意されています。

SELECTの結果すべてをメモリに乗せて取得するものです。フロントエンド処理で通常使用されているものはこの仕組みです。

対して、mysql_use_resultというメソッドがあります。

これはSELECTの結果を一度に取得せず、一行ずつ取得するものです。一度に使うメモリは一行分のみになるので省メモリとなります。

■ use_resultをRubyから使用するには？

今回はMySQL/Ruby(version. 2.9.1)を使用します。

以下のように使います。

#-*- coding: utf-8 -*-
require "rubygems"
require "mysql"

dbh = Mysql.new("localhost", "user", "passord", "database")
dbh.query("set net_write_timeout=9999") #注意点 後述
dbh.query_with_result = false #query()実行と同時にresultオブジェクトを返さなくなります。
dbh.query("select * from big_table") #大量データテーブルからのSELECT
res = dbh.use_result # use_resultを実行してresultオブジェクトを取得
res.each do |row| 
 #処理
end
res.free
dbh.close

■ 注意点

use_resultの便利な面を説明しましたが、少しクセがあります。

そのうち代表的なものをあげます。

長時間になる場合、timeoutとなり途中でSELECTが中断されてしまう。

net_write_timeoutは通常デフォルトが60秒となっています。

use_resultは一度に結果取得をしない分、net writeの時間が長くなりこのtimeoutを超えてしまうケースがあります。

そのため上記コード例でもあげたとおり、

set net_write_timeout=9999

などとしてtimeout値を伸ばしておく必要があります。

SELECTは中断できない。

一度はじめたSELECTは全件を取得し終えるまでresultオブジェクトを開放できません。

つまり、use_resultをしているDBハンドラは全件を取得するまで別の行動ができません。

どうしてもSELECTの途中でMySQLの別の処理を行う必要がある場合は、

もうひとつDBコネクションを作成し、作成したハンドラで処理を行います。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

他社様より scp / sftp を使用してファイルアップロード頂きたいとき、単にユーザアカウントを発行しポート制限を解除するのみの場合、 ssh ログインによるコマンド実行や上位階層への移動といった心配が発生します。そこでファイル転送専用にアカウント作成を行うこととなります。

■ § 手順概要

1. sftpしか行えないユーザを所属させる sftponly グループを作成します。
2. sftponly グループに所属する sftpclient ユーザを作成します。
3. sshサーバ側で sftponly グループは sftp しか行えないように設定します。
4. sshサーバを再起動し完了。

※ グループ名 sftponly・ユーザ名 sftpclient は環境に合わせて作成してください。

■ § 手順

※ root ユーザで実施します。

1. グループ作成

コマンドの実行を行えなくする為のグループを作成します。

# groupadd sftponly

2. ユーザ作成

上記グループに所属するユーザを作成します。

# useradd -s /bin/false -G sftponly sftpclient 
# mkdir /home/sftpclient/uploads
# chown root:root /home/sftpclient
# chmod 755 /home/sftpclient
# chown sftpclient:sftpclient /home/sftpclient/uploads

/etc/passwd ファイルに下記ユーザが登録されており、ログインシェルが /bin/false （ログインできない状態）となっていることを確認する。

sftpclient:x:505:505::/home/sftpclient:/bin/false

※ ユーザ作成後にグループに所属させる場合は vigr コマンドで 直接 /etc/group ファイルを編集します。

# vigr

sftponly:x:506:sftpclient

3. sshサーバ設定

/etc/ssh/sshd_config ファイルを編集します。

# 132行目あたり
#Subsystem     sftp     /usr/libexec/openssh/sftp-server
Subsystem sftp internal-sftp
# 最下行
Match group sftponly
   ChrootDirectory /home/%u
   X11Forwarding no
   AllowTcpForwarding no
   ForceCommand internal-sftp

4. sshd再起動

※ sshd_config を書き換えた後は設定を反映させる為に sshd を再起動する必要があります。

/etc/init.d/sshd restart

service sshd restart

systemctl restart sshd.service など

再起動が完了したら WinSCP, FileZilla, Fugu などのクライアントで接続確認を行います。

■ § Appendix

※ /etc/sshd_config では sshポートを分かりにくい数値に変更したり、管理ユーザのログインを禁止したり、鍵認証の強制（パスワードのみの認証は拒絶）合わせて行うとよりセキュリティーを高められます。

Port 58272
PermitRootLogin no
PasswordAuthentication no
ChallengeResponseAuthentication no

※ sshdが停止していると新しくsshログインできません。既に接続中のsshセッションは維持されていますので sshd が起動失敗した場合でも気づきにくいので、sshd を再起動した際は別のプロンプトを開き接続できることを確認すると良いです。

※ 鍵の作成や ssh 関連記事

http://doruby.kbmj.com/sakuma85_on_rails/20080228/ssh_root_1

http://doruby.kbmj.com/nsho/20090426/ssh-agent1

http://doruby.kbmj.com/oneafter999_on_rails/20100224/_SCP_

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

rick No29です。
今回は、Font Awesomeという画像ではなく文字でアイコンが表示できるものをご紹介

環境

Rails 3

使用方法

ここよりDownload
とりあえずHomeディレクトリに解凍し、cssとfontだけを抜き出します。
$ cd Rails.root/public/stylesheets
$ mkdir font_awesome
$ cp -r ~/font-awesome/css Rails.root/public/stylesheets/font_awesome
$ cp -r ~/font-awesome/font Rails.root/public/stylesheets/font_awesome

viewにてcssを読み込み
$ vi app/view/hoge/index.html.erb
<%= stylesheet_link_tag ‘./font_awesome/css/font-awesome.css’ %>
<%= stylesheet_link_tag ‘./font_awesome/css/font-awesome-ie7.css’ %>
IE7でも正常に表示させたい場合は2段目のfont-awesome-ie7.cssが必要

viewにてタグの設置
$ vi app/view/hoge/index.html.erb

これだけでアイコンが表示されます。
他にどんなclassでどんなアイコンが表示されるかは、サイトを御覧ください。

サイズ変更

cssでfont-size:25px;とすると、アイコンのサイズが変更されます。（アイコンは画像でなく文字）

色変更

文字なのでcssのcolorで色も自由自在

マウスオーバー

a.zoom {
color: #222222;
text-decoration: none;
}
a.zoom :hover {
font-size: 25px;
color: #222222;
text-decoration: none;
}

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

よしだです。

今回はオープンソースのネットショップ構築アプリ「エレコマ」を、たった１コマンドで展開できるツール「elecoma-vagrant」を紹介します。

[2014/02/27] 「続・たった１コマンドでネットショップ構築できちゃうelecoma-vagrant」も合わせてご覧ください。

■ 必要な知識

• ○ 端末へのコマンド入力

Windows の場合はコマンドプロンプト、

Mac/Unix の場合はターミナルを利用して作業を行います。

■ 用意するもの

1. VirtualBox
2. Ruby
3. Git

それぞれのソフトウェアをインストールしておく必要があります。

既にインストールされている場合はとくに作業はありません。

■ 準備

GitHub から elecoma-vagrant をダウンロードします。

git clone git://github.com/hyoshida/elecoma-vagrant.git

Ruby に Bundler がインストールされていない場合は、

下記コマンドであらかじめインストールしておきます。

gem install bundler

■ さっそく実行！

あとはダウンロードしたスクリプトのディレクトリに移動して、

セットアップ用のスクリプとファイルを実行するだけです。

cd elecoma-vagrant
./setup.sh

構築完了までに40分ほどかかるので、本でも読んでじっくり待ちます。

（※追記: 環境によってはライブラリ不足でインストールに失敗するケースがあるようです。原因については現在調査中です。 2013-06-28 17:30）

（※追記の追記: setup.sh 実行前に Nokogiri がインストールされている必要があります。「Installing Nokogiri」にしたがってインストールしてください。2013-06-28 18:30）

■ 構築完了

構築が完了すると画面に「Success!!」と出力されます。

この状態で、お使いのブラウザから「http://localhost:8080」にアクセスすると・・・

たったこれだけでネットショップが構築できちゃいました。

http://localhost:8080/admin にアクセスすると管理画面も見れます。

（id: admin, pw: pass）

■ おわりに

今回は３つの技術を利用してエレコマ構築の簡易化を実現しました。

1. vagrant
2. chef
3. serverspec

次回は、この３つの技術と elecoma-vagrant の解説をしたい思います。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

今まで行ってきた個人的活動の中で、ssh接続の安全性について疑問が出てきたのでその内容をまとめてみる。

■ 問題の原点

まず、世に存在するvpsやクラウドシステムには、基本的には2種類の構成が存在している。このうちコンテナ型と呼ばれる構成では、予め必要とされてるsshやメールなどの基本的な内容が初期段階より構成されており、コンテナを選択するだけですぐにシステムの構築が出来る、手軽さが売りになっている。このコンテナには、予めsshが組み込まれていることが多く、そのため管理者のpasswordがデフォルトで決めうちになっている場合も多い。管理者のpasswordをデフォルトで放置していた場合、外部からの攻撃によって、あっさりと侵入を許してしまうことがある。

本題は、ここからだ。このsshが最初からインストールされている＝ホストキーが最初から入っている＝同じコンテナを使う限りホストキーは変わらない。ということになる。

また、vpsやクラウドシステムが大規模になればなるほど、この傾向は強まり、/16レベル（65535台）で同じホストキーで稼働しているケースもある。

ホストキーが同じと言うことは、sshを構成する際に用いられるseedキーも同一の物を使用していると考えて良いだろう。このseedキーは、乱数を用いており、このseedキーを変更する事で、ssh通信を行う際の暗号化通信に於いて、幅（バラエティさ）を持たせている。

この問題は、2008年に指摘された、下記内容に非常によく似た傾向をもつと考えられる。

DSA-1571-1 openssl — 予測可能な乱数の生成

http://www.debian.org/security/2008/dsa-1571

DSA-1576-1 openssh — 予測可能な乱数生成器

http://www.debian.org/security/2008/dsa-1576

■ ssh 通信をあとからクラックしてみる

既に、幾つかの同一vpsを契約し、同一コンテナを展開することでホストキーが一致する or 一定の範囲内に収まることを確認している。

このホストキー情報を元に、予め生成してあるレインボウテーブルを用い、通信内容をあとから解析することで、その内容について平文に戻すことにも成功した。*1

また、多くのsshは、opensslを元に構成されており、デフォルトコンポーネントとして、opensslが含まれる場合はこの脆弱性が如実に表れる傾向がある。*2

■ 対策方法

このため、コンテナベースのsshを用いる場合は下記に注意し、速やかに対応することを強く推奨する。

1. コンソールベースでログイン可能な場合は、sshのホストキーを再生成する
2. 上記に加え、鍵交換を用いる

ベストな対応方法は、２であるが、どうしても都合により対応で気なのであれば、１を実行することで、ホストキーが事前生成された一定の範囲外になることにより、このリスクを低減させることが出来る。

*1: やり方については公開しない

*2: sshのクラックほどたやすくは無いが

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

今回はJMeterでauthenticity_tokenを取得する方法をご紹介します。

■ 概要

【環境】

Mac OS X 10.6.7

JMeter2.9

Rails2.0からCSRF対策として、Formに自動的にauthenticity_tokenが付加されるようになりました。

JMeterでPOSTする際などもこのauthenticity_tokenを正しくセットしないとアプリケーション外からのリクエストとして弾かれてしまいます。

■ テスト計画構成と正規表現抽出

例えばテスト計画の下に「ログイン」というスレッドグループがあるとします。

さらに、その下に「ログイン画面」と「ログインアクション」という2つのサンプラー(HTTPリクエスト)がぶら下がるような設定です。

テスト計画

　・ログイン

　　・ログイン画面

　　・ログインアクション

この場合、authenticity_tokenはログイン画面のFormに自動的に付加されていることと思います。

authenticity_tokenはログインアクションの際にパラメータとして必要なので、ログイン画面表示時にどうにかして、このauthenticity_tokenの値を取得しないといけないわけです。

そこで使用するのがJMeterの「正規表現抽出」という機能です。

正規表現抽出ではサンプラー(HTTPリクエスト)の後処理として設定することで、HTML BODY内の任意の値を正規表現で抽出し、次のサンプラーに渡すことができるのです。

■ 正規表現抽出追加

ログイン画面のサンプラーを右クリック

　→追加

　　→後処理

　　　→正規表現抽出

これでログイン画面の下に正規表現抽出という項目が追加されたはずです。

■ 正規表現抽出項目設定

では各項目を設定しましょう。

Apply to：

　調査中

　(例)Main sample only

Responce Field to check：

　チェックするフィールド

　(例)Body

参照名：

　後続するリスナーで指定する名前

　(例)hidden_TOKEN

正規表現：

　マッチする文字列の正規表現

　(例)＜input name=”authenticity_token” type=”hidden” value=”(.*)” /＞

　　※都合上全角の括弧(＜＞)となっているのでご注意ください。実際は半角になります。

テンプレート：

　マッチした正規表現の何番目を取得するか。0だと全体

　(例)$1$

　　※上記正規表現例の括弧内を取得

一致番号(0から乱数)

　調査中

　(例)空白

初期値：

　初期の値

　(例)is_not_Exist

■ 値の取得(ログインアクション設定)

最後に設定した正規表現の値を取得する方法です。

後続のリスナー(ログインアクション)のHTTP リクエスト – Parametersの追加

　名前：authenticity_token

　値：${hidden_TOKEN}

　Encode?：チェックON

　　※このチェックをONにしないと、取得した値の間に半角スペースが入る場合がありました

　統合含む？：チェックON

※他のパラメータ(ログインID、パスワード)等は適宜設定してください

以上で設定は完了です。

この状態でテストを実行すれば、ログイン画面のauthenticity_tokenを自動で取得し、POSTのパラメータに含めることが可能となります。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

よしだです。

Rails 3 アプリにGuard を導入して自動テストをより手軽にする方法を紹介したいと思います。

■ はじまり

最近携わっている Rails 3 アプリの自動テスト(RSpec)が、すべて完了するのに1時間半かかるようになってしまいました。

5〜10分で終わっていた頃はファイルに変更を加えるたびにすべてのテストを確認できていましたが、それが難しくなってきたので Guard を導入することにしました。

Guard を利用すれば、変更のあったファイルに関連するのみを効率よくテストすることができます。

ローカルでは Gurad で自分が編集した部分のみテストして、リモートの jenkins などですべてのテストを確認、ということをできるようにするのが今回の目的です。

■ Guard のインストール

というわけで、さっそく Rails 3 アプリに Guard を導入していきます。

bundlerを利用している場合は Gemfile ファイルに下記の行を追加します。

group :development do
  gem 'guard'
  gem 'guard-rspec'
  gem 'guard-spork'
end

追加後、gem をインストールします。

% bundle install

最後に、guard の設定ファイル Guardfile を生成します。

% guard init

（※bundler を利用している場合は「bundle exec guard init」とすれば実行できます）

■ Guard の設定

インストール後は Guardfile を編集して動作設定を行います。

今回は Guardfile の rspec に関わる行を下記のように書き換えました。

guard 'rspec', :cli => "--color --fail-fast --drb", :all_after_pass => false, :all_on_start => false do
  # …
end

「:cli => “–color –fail-fast –drb”」 という部分は rspec のオプションを記述しています。

これらはそれぞれ次のような意味があります。

• –color … 色をつけて表示する
• –fail-fast … テストに失敗したら即座に中断
• –drb … DRBサーバをサポートする

–drb オプションによって Spork が利用でき、テスト開始までの時間が短縮できます。

「:all_after_pass => false」という部分は、テストが通ったときにすべてのテストを実行するか否か、というオプションになります。

今回は、すべてのテストを実行していると時間がかかりすぎるので、 オフ にしています。

「:all_on_start => false」という部分は、Guard 起動時にすべてのテストを実行するか否か、というオプションになります。

これも上と同じ理由でオフにしています。

■ Guard の実行

まず、テストの高速化を図るためにあらかじめ Spork を起動しておきます。

% spork

つぎに Guard を起動します。

% guard start

これで準備完了です。

■ Guard を走らせる

適当なファイルを編集＆保存するだけで、更新されたファイルに関連づいたファイルだけ自動的にテストが走ります。

ファイルの中身に更新があるかどうかは問わないようなので、下記のようにタイムスタンプを更新するだけでもテストの実行が可能です。

% touch app/models/hoge.rb

■ おわりに

現在非常に多くのツールが Guard と連携できるようになっているようです。

例えば仮想端末ソフト tmux などと連携することで「テスト実行後に結果を通知」といったことまでできます。

今回紹介したのは使い方のほんの一部でしたが、また機会があればその他の使い方について紹介したいと思います。

この記事はアピリッツの技術ブログ「DoRuby」から移行した記事です。情報が古い可能性がありますのでご注意ください。

よしだです。

今回はRails2.3/Ruby1.8で動作する自社開発のオープンソースECパッケージ『エレコマ』を、Ruby1.9に移行するに伴って問題になった点と、その解決方法について紹介したいと思います。

■ 日本語メールが文字化けする

Ruby 1.9 になって、文字列オブジェクトが文字コードを持つようになりました。

このため Ruby 1.8 ⇒ 1.9 移行の際には、文字列が意図しない文字コードで解釈されてしまうのを防ぐ必要があります。

Rails 2 のメールシステムには TMail というライブラリが利用されています。

Ruby 1.9 でこの Tmail を利用すると、上記問題のため、メール処理部分で例外エラーが発生してしまいます。

これは config/initializers/tmail_19_patch.rb に下記のようなコードを設置することで解決できます。

# -*- coding: utf-8 -*-
# Ruby 1.9 + tmail-1.2.7 環境での
#「Encoding::CompatibilityError (incompatible encoding regexp match (ASCII-8BIT regexp with ISO-2022-JP string))」
# エラー対策。
# Rails の場合 config/initializers/tmail_19_patch.rb などに配置する。
#

module TMail19Jp
  def self.encoding_handler(text)
    raise unless block_given?
    enc = text.encoding
    text.force_encoding(Encoding::ASCII_8BIT)
    result = yield
    text.force_encoding(enc)
    result
  end
end

module TMail
  class Encoder
    alias :phrase_org :phrase

    # 本文用のパッチ
    def phrase(str)
      TMail19Jp::encoding_handler(str) do
        phrase_org(str)
      end
    end
  end

  # Subject欄用のパッチ
  class Unquoter
    class << self
      alias :unquote_and_convert_to_org :unquote_and_convert_to

      def unquote_and_convert_to(text, to_charset, from_charset = "iso-8859-1", preserve_underscores=false)
        TMail19Jp::encoding_handler(text) do
          unquote_and_convert_to_org(text, to_charset, from_charset, preserve_underscores)
        end
      end
    end
  end
end

# 本文用のパッチ
class StringOutput
  alias :push_org :<<

  def <<(str)
    TMail19Jp::encoding_handler(str) do
      push_org(str)
    end
  end
end


# From欄用のパッチ
module ActionMailer
  module Quoting
    alias :quote_address_if_necessary_org :quote_address_if_necessary

    def quote_address_if_necessary(address, charset)
      TMail19Jp::encoding_handler(address) do
        quote_address_if_necessary_org(address, charset)
      end
    end
  end
end

文字列を処理するまえに force_encoding(Encoding::ASCII_8BIT) で文字オブジェクトが持つ文字コードを変更しています。

こうすることで、意図しない文字コードで処理され、例外が発生するのを防いでいます。

参考: http://d.hatena.ne.jp/akishin999/20120220/1329731704

■ 半角カナ判別用の正規表現が動作しない

Ruby 1.9 で正規表現ライブラリが「鬼車」に変わったため、正規表現の一部表現がサポートされなくなっています。

エレコマでは、全角カナの判別にはもともと下記のような正規表現を利用していましたが、「鬼車」ではこのような文字コード単位での範囲指定を許可していないようです。

# 全角カナを判別するための正規表現 (for Ruby1.8)
KATAKANA_PATTERN = /^(?:\xE3\x82[\xA1-\xBF]|\xE3\x83[\x80-\xB6\xBC])*$/

これは moji という gem を利用すれば簡単に解決できます。

実際には下記のようなコードになります。

（※ここでは全角カナのほかに、マイナスなどの例外的な文字も含めるようにしています）

# 半角カナを判別するための正規表現 (for Ruby1.8)
KATAKANA_PATTERN = /^(#{Moji.zen_kata}|ー|－)*$/

また「鬼車」では /[\p{katakana}+/ のように書くことでカタカナの判別が可能です。

ただし、こちらは半角カナも含んでしまうため、今回の例では使用できませんでした。

■ PostgreSQL とうまく連携できない

エレコマでは DB として利用する PostgreSQL の gem に「postgres」を利用しています。

しかし、これは Ruby 1.9 では動作しないので、代替として「pg」をインストールします。

# gem uninstall postgres -v 0.7.9.2008.01.28
（古い gem をアンインストール）
# gem install pg --no-ri --no-rdoc
（Ruby 1.9 向けの新しい gem をインストール）

■ PostgreSQL が古くて pg がインストールできない

「pg」は PostgreSQL 8.3 以上が必要になります。

このためインストール済みの PostgreSQL のバージョンが低い場合はアップデートが必要になります。

【CentOSの場合】

すでに PostgreSQL が入ってしまっているなら、下記コマンドで古いパッケージをアンインストールします。

# yum uninstall postgresql-devel postgresql-server

その後 PostgreSQL を 8.4 (8.3以上であれば良い) にします。

# yum install postgresql84-devel postgresql84-server

■ さいごに

エレコマは現在 Ruby 1.9 に移行中です。

その中でまた問題と解決方法が見つかり次第、本記事に追記していこうと思います。