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

Mac OS X LionでWiresharkを動かすと起動しない自体が頻発しますが、変な方法で動くようになったので報告します。

Mac OS X Lionがリリースされてはや数ヶ月立ちますが、様々なソフトが死んだりして正しい生存戦略ができない自体になりかねない状況です。

エンジニアにとって必須ソフト、Wiresharkも同じように荒ぶるLionによって惨殺される自体になっていますが、よくわからないけど動くようにできたので報告します。

Wiresharkでは一般権限で動かすときに、 /dev/bpf* の所有者を変更してあげる必要があります。ただし、現在のMacPortsのバージョンでは一般権限でなぜかセグってしまい死んでしまう状態になっています。

bash-3.2$ wireshark
Segmentation fault: 11

そこでroot権限で動かすのですが、なぜかWiresharkがそのまま終了するという状態になったりします。

bash-3.2$ sudo wireshark
(そのまま死亡)

そこで、一旦所有者を変更してみました。

bash-3.2$ ls -lh /dev/bpf*
crw-------  1 tmatsuzawa  admin   23,   0 Oct 25 10:10 /dev/bpf0
crw-------  1 tmatsuzawa  admin   23,   1 Oct 25 10:10 /dev/bpf1
crw-------  1 tmatsuzawa  admin   23,   2 Oct 25 10:10 /dev/bpf2
crw-------  1 tmatsuzawa  admin   23,   3 Oct 25 10:10 /dev/bpf3
bash-3.2$ sudo chown tmatsuzawa:admin /dev/bpf*
bash-3.2$ sudo wireshark

すると今度は起動するようになりました。

で、一旦終了してから再度起動をします。すると今度は死にます。

bash-3.2$ sudo wireshark
(そのまま死亡)

おかしいと思って、元の所有者に戻してみました。

bash-3.2$ ls -lh /dev/bpf*
crw-------  1 tmatsuzawa  admin   23,   0 Oct 25 10:10 /dev/bpf0
crw-------  1 tmatsuzawa  admin   23,   1 Oct 25 10:10 /dev/bpf1
crw-------  1 tmatsuzawa  admin   23,   2 Oct 25 10:10 /dev/bpf2
crw-------  1 tmatsuzawa  admin   23,   3 Oct 25 10:10 /dev/bpf3
bash-3.2$ sudo chown root:wheel /dev/bpf*
bash-3.2$ sudo wireshark

今度は正常に動きます。そして、再度起動すると動かないという状態になります。

まとめると、Wiresharkを起動する場合は、一度 /dev/bpf* の所有者を変更すると動くようです。

たぶん、短期的なバグだと思われますが、とりあえず生存戦略を遂行するためにはこのような対策をしていただく必要があるみたいです。

本家への報告は時間があれば…

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

railsプロジェクトで、外部サイトへデータをpostする時、パラメータの生成にhttpの「set_form_data」メソッドをお勧めします。railsプロジェクトで、外部サイトへデータをpostする時、パラメータの生成にhttpの「set_form_data」メソッドをお勧めします。

このメソッドをお勧めする理由は特殊文字（「&」、「” “」、「”/”」など）がパラメータの値に入る時、うまくエンコードできるのです。

例、
URI.encode⇒ “&”（&）
CGI.escape⇒” ”（+）
URI.escape ⇒ “&”（&）
ERB::Util.u(s)はうまくできると思います。

httpのset_form_dataの元ソースを見てみしょう。
/usr/local/lib/ruby/1.8/net/http.rb（rubyのインストールパスによりパスが変わる可能性がある）の
1432～ 1441行目前後
  def set_form_data(params, sep = ‘&’)
    self.body = params.map {|k,v| “#{urlencode(k.to_s)}=#{urlencode(v.to_s)}” }.join(sep)
    self.content_type = ‘application/x-www-form-urlencoded’
  end

  def urlencode(str)
    str.gsub(/[^a-zA-Z0-9_\.\-]/n) {|s| sprintf(‘%%%02x’, s[0]) }
  end

使用方法は
98～ 109行目を確認
パラメータのキーと値をハッシュで渡せば、結構です。
  #3: Detailed control
  url = URI.parse(‘http://www.example.com/todo.cgi’)
  req = Net::HTTP::Post.new(url.path)
  req.basic_auth ‘jack’, ‘pass’
  req.set_form_data({‘from’=>’2005-01-01’, ‘to’=>’2005-03-31’}, ‘;’)
  res = Net::HTTP.new(url.host, url.port).start {|http| http.request(req) }
    case res
    when Net::HTTPSuccess, Net::HTTPRedirection
      # OK
    else
      res.error!
    end

よろしくお願いします。

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

最近防衛産業でにわかに流行り始めてると言われる、標的型攻撃だが、実際には４年以上前から、こうした攻撃が観測されており、ようやく、そういう事が発生していると、報道がされたに過ぎない。

今から５年ほど前、某所で行ったハンズオンセミナーでは、三菱重工業が受けたような標的型攻撃の可能性について、指摘を行い、また、事前に入手してあった

admin権限を必要とするアクセス権への攻撃

を繰り返す、コンセプト型ウィルスもいくつか紹介し、その挙動についてハンズオンセミナーで紹介している。

その時紹介したいくつかのコンセプト型ウィルスは、後のコンフリッカーと呼ばれるウイルスになったり、今回の様な標的型攻撃に利用されている。

私たちが観測している標的型攻撃に利用されそうなコンセプト型ウイルスは、巧妙に姿を隠し、通常の状態では発見されない状況になった。

完全に、地下に潜ったかの様に見える。ウイルスは、PCに設定されているDNSを参照せず、ウイルスが他のDNSを参照している。この通信は、他のクライアント（例えば、IE）が通信しているとき、それに乗じて、https通信を行う。実際に通信しているのは、暗号化されたDNSクエリーであり、内容を解読*1しても、webコンテンツが流れているわけではない。

また、活動時間も、ユーザが利用していないアイドル時間に、通信以外の行動を行い、ユーザがネットを利用している間に、通信を行い、ユーザに気づかせない対策を行なっている。

こうした、状況を踏まえ、標的型攻撃の対策を行うべきであり、弊社では、それを踏まえた対策セミナーを考えている。現在検討しているセミナーは以下のとおり

1. 標的型メールの最新動向の把握とメール送信事故等の防止対策セミナー
2. システム管理者向け　標的型攻撃対策ハンズオンセミナー（３日間コース）

1は、企業や事業部、部署毎に実施するもので、教育フェイズと訓練から構成されており、繰り返し訓練を行うことで、ひとりひとりに自覚させ、標的型メールを踏みにくい耐性をつくることを主軸に考えている。

2は、上記訓練を繰り返し行なったとしても、一定割合で踏んでしまう社員が居る統計がある。

このため、「実際の標的型メールを改良」した物を複数種類用いたり、実際に攻撃が行われた際に記録されたログを用い、実際に何が起きるのかを、体験していただき、どのような対策を行うかを理解して頂ける、セミナーである。

それぞれの対策セミナーは、開催決定次第、都度、http://security.kbmj.com/ にて公開する。

*1: SSL通信は、暗号解読の方法が幾つかある

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

こんにちは。KBMJの本多です。

今回はサーバーのSSL証明書の更新時にたまに陥る問題と、それを解決する際に役立った情報を紹介したいと思います。

先日、とあるPC/携帯向けサイトの話にてSSL証明書を更新後、携帯端末で参照できなくなる問題が発生しました。
原因は用意したサーバー証明書と中間証明書の組み合わせが間違っているためでした。

PCブラウザでは中間証明書が間違っていてもブラウザ側で補完してくれるためエラーが出ないらしいのですが、
携帯端末ではそういうわけにはいかず、サイトにアクセスするとエラーが出ます。

最近はクロスルート証明書が登場した事で、サーバー証明書の種類によって設定方法が複雑化したりしていますが、
そもそも発行されたサーバー証明書はどの中間証明書を使うのが正しいか？それを確認しないことには始まりません。

本日は、発行されたサーバー証明書と中間証明書の中身を確認し、正しい組み合わせである事を調べる方法を紹介したいと思います。

ファイルの準備

windows環境にて、用意したサーバー証明書及び中間証明書を拡張子cerというファイルで保存します。
拡張子cerで保存したファイルをダブルクリックする事で、証明書の中身を参照する事が出来るようになります。

サーバー証明書の中身を確認

発行先：サイトのドメイン名
　いきなりここが違った場合はもうそれは別のサーバー証明書です。証明書を発行した人に確認しましょう。

発行者：SSL証明書の発行会社、及び証明書の形式情報
　ここに何が書かれてるかを覚えておきましょう。

有効期限
　期間が更新されていることを確認しましょう。

中間証明書の中身を確認

発行先：サーバー証明書の「発行者」と同じ
　先ほど確認したサーバー証明書の発行者と照らし合わせましょう。
今回は、ここが異なっていたため、適用後に不具合が発生しました。

中間証明書が間違っていた場合については、証明書を発行した会社のサイトからダウンロードできますので
サーバー証明書の「発行者」を元に、正しい中間証明書を取得しましょう。

あとはapacheに正しく設定すれば、携帯端末でもSSLのページが参照できるようになります。

SSL証明書の更新時に躓くパターンといえば、クロスルート証明書を絡めた中間証明書の設定部分が上手くできていない場合が多いイメージがありますが、たまにこういうパターンの落とし穴もあります。
更新する際には、一度中身を確認してみるとトラブル回避につながるかもしれません。

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

KBMJのコジです。

ここ3カ月技術に関わっていないので、今年2011年6月に受験して合格したデータベーススぺシャリストの試験対策について書きます。

10年ぶりの受験だったので、当然午前Ⅰの免除はなく、勉強に5か月費やしました。

まぁ、一日の勉強時間は通勤の1時間半程度ですが(土日は除く)。

使用した図書は以下の3冊です。

・翔泳社 高度試験午前Ⅰ・Ⅱ

　→暗記量は多いが自分の受験範囲をやれば確実に突破可能。

・翔泳社 情報処理教科書 データベーススペシャリスト

　→他の参考書より優れていると思わないが、過去問9年分付きが素晴らしい。

・リックテレコム データベース午後徹底演習(古本)

　→上記参考書の説明不足を補う為に使用。あと、過去問に入る前の肩慣らしにもなる。

午前Ⅰがあると、とにかく暗記する量が半端ないので、

中学生以来に単語帳を使用し、3ヵ月かけました。

残り2ヵ月は過去問ですね。

翔泳社の参考書は9年分の過去問が付いているので、5年分やりました。

ここで厄介なのが、午後Ⅱ。

2問中1問選択し120分の問題なので、

2問とも解いて、採点・見直しも実施すると6時間位かかります。

過去問で土日をどれだけ無駄にしたか…

過去問を進めるにつれ、合格ラインの採点が続くようになり

自信満々で試験当日を迎えたわけですが、

午後Ⅱで選択した問2の記述量が過去最大級で

回答を7～8割しか埋められず不安のまま合格発表を迎えました。

結果、見事1発でギリギリ合格した訳ですが、

午後Ⅱは合格率を一定にするため、得点調整があるとの噂があります。

なので、とにかく回答を埋めるように頑張って下さい。

最後に、個人的に発見した小さな裏技を１つ。

試験開始までは問題冊子を開いてはいけません。

が!

解答冊子は開いてもいいんです。

なので、試験開始までボーっとせずに回答欄から問題を予想し、

午後Ⅰ・Ⅱの設問選択時間を少しでも省略することをお勧めします。

(問題冊子を開いてると勘違いされる可能性もあるので自己責任で)

では、これから受験される方のご検討を祈っております。

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

Ruby on Railsにて、外部からアクセスした際にもエラー画面を見れるようにしてみた

この記事は公開から１年以上が経過しています。情報が古い可能性がありますのでご注意ください。こんにちは。KBMJの本多です。

今回は実際にリリースされたプロジェクト等でアプリケーションエラーが発生した際に、開発時のようなエラーメッセージを見るための方法を紹介したいと思います。基本的に、RoRのproductionモードでは、アプリケーションエラーが発生するとlocalhost以外から接続時には
#{RAILS_ROOT}/public/500.html
を返す仕組みになっています。

これを回避する主な方法は２通りあります。

１．productionモードの設定を変更して、アプリケーションエラー時にメッセージが見れるようにする

※Rails2系及びRails3系で利用可能

#{RAILS_ROOT}/config/environments/production.rb 内の以下の行を変更
config.action_controller.consider_all_requests_local = false
↓
config.action_controller.consider_all_requests_local = true

これにより、developmentモードと同様に、外部からのアクセスでもエラーメッセージをブラウザ上に表示するようになります。

が…絶対にやってはいけません！

基本的にエラーメッセージを不特定多数の利用者の目に触れるような状態にするのはセキュリティ上非常によろしくないです。
たまにRoRではない別の言語・システムで構築されたサイトにてナマのエラーメッセージを見たことがありますが、ファイルパスやSQL等の情報が漏れる原因になるため、この方法を利用する事はやめましょう…。

一応、（物理的には）可能な方法だったので、紹介しておきました。

２．エラー発生時に特定のIPアドレス（例えば開発会社のグローバルIP）をlocalhostと「誤認」させる事で、エラーメッセージを表示するように設定する

※Rails2系で利用可能

今回紹介する方法はこちらです。
RoRの内部にて、エラー発生時の処理を”local_request?”というメソッドで判定して処理を切り替えている部分があるので、
local_request?の中身を書き換える事で、特定のIPアドレスをlocalhostであるかのように振る舞うようになります。

local_request?の元ソース（Rails 2.3.10から抜粋）は以下の通りです。

LOCALHOST = [/^127\.0\.0\.\d{1,3}$/, /^::1$/, /^0:0:0:0:0:0:0:1(%.*)?$/].freeze
（中略）
# True if the request came from localhost, 127.0.0.1. Override this
# method if you wish to redefine the meaning of a local request to
# include remote IP addresses or other criteria.
def local_request? #:doc:
  LOCALHOST.any?{ |local_ip| request.remote_addr =~ local_ip && request.remote_ip =~ local_ip }
end

これをapplication_controller.rb内にて以下のように記述する事で、指定のIPアドレスでのみエラーメッセージを見れるようになります。

private
def local_request?
  [“127.0.0.1”, “（対象のIPアドレス）”].include?(request.remote_ip)
end

これにより、開発時と同様にログから追いかけるエラーメッセージをブラウザから参照できるようになり、
不具合発生時の対応が比較的楽になると思います。

残念ながらRails3系では仕様が変わって使えなくなりましたが、まだRails2系が使われているプロジェクトが多いと思いますので、是非ご活用ください。

GOOD RAILS!!

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

rickNo23です。
今回はjQueryのプラグインGoogleChartsを使って簡単にグラフを表示する方法を紹介します。

環境

jquery1.4.2
jgcharts.js.0.9.7

Download

本家

ソース

< script type=”text/javascript” src=”http://search.kbmj.com/javascripts/jquery-1.4.2.min.js” 　 >< /script >
< script tyep=”text/javascript” src=”http://rikiya.sakura.ne.jp/jQuery/jgcharts/jgcharts.js” >< /script >

< script language=”JavaScript” >< !–
　　jQuery(function(){
　　　　var api = new jGCharts.Api();
　　　　jQuery(‘< img >’).attr(‘src’, api.make({data : [[153, 60, 52], [113, 70, 60], [120, 80, 40]]})).appendTo(“#bar1”);
　　})
//– >< /script >
< div id=”bar1″ >< /div >

解説

まずはjqueryの読み込みでjquery-1.4.2.min.jsを参照
次にGoogleChartsの読み込みでjgcharts.jsを参照
var api = new jGCharts.Api();
で初期化
jQuery(‘< img >’).attr(‘src’, api.make({data : [[153, 60, 52], [113, 70, 60], [120, 80, 40]]})).appendTo(“#bar1”);
でデータを送信して画像を取得し、divのbar1へ出力しています。

オプション

本家を見てもらうと分かる通りグラフには様々な種類があります。
api.makeの中で
type : ??
とすることで別の種類のグラフに変わります。
例えばtype : ‘bhs’などにすると帯グラフに変化します。
また、画像サイズには制限がかけられておりmaximum size 300,000 pixelsとなっています。
サイズの変更は
size : ‘??x??’
で変更できます。
他にも様々なオプションがありますので、興味があったら本家を見てみてください。

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

先日、apacheの脆弱性が公開された。この脆弱性は、既存の全バージョンで確認され、「緊急」扱いとなっている。

今回は、この脆弱性が如何に危険な存在であるか、検証してみよう。

今回見つかった脆弱性は、と呼ばれるもので、ざっくりと言ってしまえば、サービス拒否攻撃の類だ。サービス拒否攻撃には、いくつかの手法があり、

1. 帯域圧迫型
2. socket飽和型
3. CPU占有型
4. メモリ圧迫型

の４種類に大別することが出来る。このうち、1は一般的にはDDoS攻撃と呼ばれるもので、古くは「田代砲」と呼ばれる攻撃ツールもあった。2は、1と似ているが、大した帯域を使わず、大量にセッションを張るだけ張り、持続させて、相手のsocketを食いつぶす。syn floodやack flood攻撃もこの種になる。

3は、CGIを呼び出す部分のみを、高速に外部から呼び出し、CGIに費やす負荷を極限まで上げる方法だ。4は、ファイル転送を行う際に、大量かつ大容量のデータを転送することで、内部メモリを飽和させる方法だ。

今回見つかった脆弱性は、3と4を合わせ持つ強力なものだ。通常３や４を実行する場合、攻撃側もそれ相応の機材やネットワークを必要とし、botネットを用いることが一般的だ。しかし、今回の脆弱性を検証するために用いられたツールは、わずか8000バイト弱のデータを、１つのhttpリクエストにしたため、接続しているだけだ。

通信内容は、次のようになっている

HEAD / HTTP/1.1

Host: 192.168.2.113

Range:bytes=0-,5-0,5-1,5-2,5-3,5-4,5-5,5-6,5-7,5-8,5-9,5-10,5-11,5-12,5-13,5-14,5-15,5-16,5-17,5-18,5-19,5-20,5-21,5-22,5-23,5-24,5-25,5-26,5-27,5-28,5-29,5-30,5-31,5-32,5-33,5-34,5-35,5-36,5-37,5-38,5-39,5-40,5-41,5-42,5-43,5-44,5-45,5-46,5-47,5-48,5-49,5-50,5-51,5-52,5-53,5-54,5-55,5-56,5-57,5-58,5-59,5-60,5-61,5-62,5-63,5-64,5-65,5-66,5-67,5-68,5-69,5-70,5-71,5-72,5-73,5-74,5-75,5-76,5-77,5-78,5-79,5-80,5-81,5-82,5-83,5-84,5-85,5-86,5-87,5-88,5-89,5-90,5-91,5-92,5-93,5-94,5-95,5-96,5-97,5-98,5-99,5-100,5-101,5-102,5-103,5-104,5-105,5-106,5-107,5-108,5-109,5-110,5-111,5-112,5-113,5-114,5-115,5-116,5-117,5-118,5-119,5-120,5-121,5-122,5-123,5-124,5-125,5-126,5-127,5-128,5-129,5-130,5-131,5-132,5-133,5-134,5-135,5-136,5-137,5-138,5-139,5-140,5-141,5-142,5-143,5-144,5-145,5-146,5-147,5-148,5-149,5-150,5-151,5-152,5-153,5-154,5-155,5-156,5-157,5-158,5-159,5-160,5-161,5-162,5-163,5-164,5-165,5-166,5-167,5-168,5-169,5-170,5-171,5-172　以下略

こう言った攻撃コードを、1回の通信で行っている。

ここで注目すべきは、「Range:bytes=」だ。

このRangeは、データを分割する際に用いる方法

だ。つまり、大量のデータがある場合、そのデータをいくつかに分割し、転送することを要求している。5-6 5-7 と言ったように、特定のバイトからバイトまでを分割して転送要求を行う。5-0 バイトから5-1299バイトまでを、1バイトづつ増やしながら、同じものを含め、再度転送することを要求する。この要求を受けたターゲットは、その要求に従い、律儀に転送しようと試みる。

これを受け取ったサーバは、下記に示すように、要求された分だけ、apacheの接続を受け止めようとする。

見てわかるように、この時点でload average は、40を越えている。通常のサーバではありえない現象だ。

この時の通信ログは

192.168.3.26 – – [01/Sep/2011:10:20:37 +0900] “HEAD / HTTP/1.1” 206 354 “-” “-“

192.168.3.26 – – [01/Sep/2011:10:20:37 +0900] “HEAD / HTTP/1.1” 206 354 “-” “-“

192.168.3.26 – – [01/Sep/2011:10:20:37 +0900] “HEAD / HTTP/1.1” 206 354 “-” “-“

192.168.3.26 – – [01/Sep/2011:10:20:37 +0900] “HEAD / HTTP/1.1” 206 354 “-” “-“

192.168.3.26 – – [01/Sep/2011:10:20:37 +0900] “HEAD / HTTP/1.1” 206 354 “-” “-“

192.168.3.26 – – [01/Sep/2011:10:20:37 +0900] “HEAD / HTTP/1.1” 206 354 “-” “-“

192.168.3.26 – – [01/Sep/2011:10:20:37 +0900] “HEAD / HTTP/1.1” 206 354 “-” “-“

192.168.3.26 – – [01/Sep/2011:10:20:37 +0900] “HEAD / HTTP/1.1” 206 354 “-” “-“

192.168.3.26 – – [01/Sep/2011:10:20:37 +0900] “HEAD / HTTP/1.1” 206 354 “-” “-“

となっており、先程の様な、Range:bytes=は含まれていない。

この状況が続くとどうなるのか、状況を見てみよう。

waが97%を示していることがわかるだろうか。これは、IO Wait と呼ばれるもので、通信ではなくIO系の処理にそれだけのwaitが発生していることを示す。

この数値が大きければ、大きいほどシステムの反応速度は落ち、ファイルの書き込みや様々な応答速度は悪くなる。

webブラウザで接続した際、クルクルとレインボウカーソルが発生し、何時まで経っても、画面が表示されない。そういった状況を想い出せばよいだろう。

この状況が続くと、メモリもCPUも圧迫され続け、システムそのものへのssh接続もままならなくなる。

こうなると、システムは次の画面にあるように、OOM Killer を発動する。

この状況では、諸悪の根源を、apache に有ると考え、apache のタスクを殺しにかかる。

この時、apacheの抱えるタスクは当然のごとく消され、最悪の場合システムが完全にロックする場合もある。

この記事を書いてる現在、既にapache 2.2.20のパッチが提供され、それ以外のバージョンでも暫定的な対応策が公開されている。まだ、apacheの対策を行っていないのであれば、早急な対応されることの望む。最悪の場合、apacheどころか、OSまで止まるのだから。

この後の検証で、killapache.pl のHEADをGETに書き換えた場合、HEADの時より、高速にサービス拒否攻撃が成立し、OOMKillerが発動する事がわかった。

これは、HEAD によって呼び出される情報が、Serverの情報のみに集約され、あまり、1300バイトを超えることが無いことに対し、GET の場合は、HTMLが含まれ、容易に1300バイトを超えるためと推測される。

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

８月２５日、DeNAが提供するモバゲーが９時３０分くらいからアクセスできなくなった。折しも、Apacheで、重大なセキュリティホールが報道された為、落とされた？と、思っていたら・・・

どうやら、Apache の脆弱性によるものではなく、単なるデータセンタの障害だったらしい。

DeNAが入るデータセンタの発表によると

弊社データセンターにおける通信障害について

本日9時30分頃、弊社データセンターにおいて通信障害が発生いたしました。この障害は、データセンター内のテナント様が行なっていた工事中に誤って回線を切断したことによるものです。

とのことで、第三者の人為的ミスによる障害と判明した。

今回の、通信障害から分かることを考えてみたいと思う。

1. データセンタは、共用ビルだった？
2. ネットワークが共有部分を走っていた？
3. ネットワークがシングルポイントになっていた？

まず、1の問題から。様々な理由からデータセンタのみを運用するデータセンタの構築は難しいとされる。だが、データセンタを構成する上で重要となる、クリティカルな情報を扱う場合、L7もしくはL6程度のファシリティが必要になると考えている。つまり、DeNAが入るデータセンタは、クリティカルデータを扱う事はできないと、宣言しているようなものだ。

次に、2の問題。共有ビルの場合、通信ケーブルを専有部分のみに走らせることは厳しい。しかしながら、他のデータセンタでは、共有部分に於いても、通信ケーブルを切断されないように、シールド線を用いたり、囲いを使ったりして対策を施している。

最後に、３の問題。データセンタを設計する上で、一番重要な問題は、シングルポイントを絶対に作らないこと。これは、電源ケーブルしかり、通信ケーブルしかり、２重３重に経路設計を行い、物理線は当然のこと、複数の異なるライン、複数の異なる物理経路を用い、仮に１本切断されたとしても、他の経路で確実に到達するように設計を行う。

DeNAが入っていたデータセンタは、耐震性を謳っているようだが、地震云々よりも、こういったアタリマエのことをやってから、耐震性を考えて欲しいものである。

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

侵入者に対する考え方は、様々なポリシーによって、多種多様に存在する。

今回は、様々なポリシーの中から、少し変わった対策を紹介しよう。

まず、侵入者に対する考え方は、大きく分けて次のように分類される

1. 絶対防御
2. ノーガード戦法
3. ハニーポット

このうち、多くの企業や組織が行っているのが、絶対防御の考えである。通常であれば、侵入者の試みを快く思わず、様々なポイントで、侵入者の試みを排除しようとする。

一切の試みを禁止しているため、最悪の場合DDoSを使って、サイトそのものを外部から閲覧させないように攻撃される場合がある。

次に、割と多く困った存在が、ノーガード戦法だ。普段は何もせず、最低限の対策だけ行い、なにか問題が発生したら、ひたすら謝る方法だ。先程の、絶対防御に比べ、多くのリソースを必要としないため、月々のコストを下げることが出来る。もちろん、実際の攻撃を受けた場合、多大な損害が発生するわけだが、万一の事態に備える必要がないため、状況によっては、ノーガード戦法が、コストが安くつくかもしれない

最後に、ハニーポット。通常のサイトのフリをし、脆弱なサイトの様に見せかけて、攻撃者の動向を調べる手法だ。一般的な企業がこれを採用する事は少なく、どちらかと言えばセキュリティを生業とする企業が用いる。

今回紹介する手法は、３つのどのモデルにも該当しない。

多くの侵入者は、ちょっとした遊びゴコロで侵入している事が多い。たしかに、プロの犯罪者が情報を盗むために侵入するケースもあるが、それはごくごく一部だ。

侵入者は、まず、脆弱なパスワードを設定したアカウントを探し出し、そのアカウントに対してsshやtelnet ftpなどに対して攻撃を仕掛ける。ここで、脆弱性なアカウントとパスワード（例えば id:test passwd:test 等の様に）を見つけ出し、サイトに侵入したとする。

次に侵入者は、いつでもそのサイトに侵入できるようにバックドアを仕掛ける。そして、ローカルexploitを用い、管理者権限を奪い、rootkit を仕掛け・・・と、こんな具合に侵入して、次に踏める場所を調べ始める。これと同時に、有用な情報がサイト内に無いかを調査することも忘れない。ここまで書くと、ハニーポットに視えるだろう。たしかに、このままではハニーポットだ。有益な情報をわざと散りばめ、かつ、それに毒入れを行っていたらどうなるだろうか。

通常のテキストファイルだけでは、毒入れすることは難しいが、PDFファイルや、GIFファイルなどであれば、毒入れすることはかなり容易くなる。具体的な毒入れ手法は書かないが、毒入れされた有益な情報を侵入者が持ち帰り、自分のPCや友だちのPCでひらこうものなら、それを開いたPCの情報が、丸裸のように、別サイトに通知されるように仕込んでおく。つまり、有益な情報を盗んだ！と思ったら、実際には攻撃者が丸裸にされるわけだ。

侵入者には、簡単に入れるという快楽を与え、実際には侵入者の個人情報を盗む。そういった対策を考えてみるのも一考だろう。

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

Twitterが自動的に付加する短縮URLはセキュリティとか考えてるかよくわからないので安心できそうなサービスを使ってみます。

(先に結論を言うと、無駄足でした。)

なにやら最近、TwitterでURLを普通に流すと勝手にt.coという短縮URLに変更してしまいます。

短縮URLは少ない文字で記述するには非常に便利ですが、セキュリティ上考えられているかというとよくわかりません。

短縮URLでセッションを奪ったりなんていうのは昔からよくあった話で今更感がありますが、このようにデフォルトサービスにまで発展するとさすがにまともなサービスを検討して使っておかないとまずいターンだろうと思います。

で、まともなサービスがないかなーと思っていたら、同僚から「マカフィーの短縮URLがあるよ」と教えてもらいました。

調べてみると、「McAf.ee」というサービスで、マカフィーのデータベースを使ってURLを評価しているようです。(参考記事: McAfee、サイトの安全性も評価するURL短縮サービス「McAf.ee」ベータ版公開)

これなら安心して使えそうということで、さっそく夜フクロウで使えるようにしてみました。

夜フクロウの環境設定画面を開きます。

そして、詳細タブのURL短縮サービスの項目でカスタムを選択します。

次に、ダイアログが現れるので、以下のように入力します。

http://mcaf.ee/api/shorten?input_url=%@&format=text

フォーマットはテキストのままにしておきます。

これで短縮URLで「McAf.ee」が使えるようになりました。

ですが….結局、この短縮URLにしても、Twitter側が勝手にt.coという短縮URLに変更してしまいます。

対策としては、Command+Sで短縮URLに変更したあとに、http://からhを削ってみるとよいでしょう。

McAf.eeのAPIのドキュメントはThe McAf.ee APIにあります。自分のサービスに組み込みたい人は、ぜひ参照してください。

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

Rails3.1ではSCSSが標準で搭載されました。とても面白い仕組みなので紹介します。

CSSはWebページにおいて構造とデザインを分離するとても重要な仕組みです。しかし、デザインが複雑になるに連れてどんどん肥大化していき、うまくコントロールしないとメンテナンスが容易ではなくなってしまいます。よく、新しいデザインを追加したと思ったら他のデザインとぶつかってしまったなんてことがあったり、一箇所にクラスの定義がなくバラバラになっていて途方にくれてしまうなんてことはよくあります。

SCSSはこのような悩みをほどよく解決してくれるシンタックスを持つCSS用のメタ言語で、Rails 3.1から採用されました。SCSSについての詳細は、Sass、そしてSassy CSS (SCSS) をご覧ください。

今回は、黒田努氏のはじめる！Rails3(達人出版)のサンプルプログラム:hinagikuで、7.3 スタイルシートの作成に登場するサンプル(public/stylesheets/tasks.css)を例に、Rails 3.1でSCSSで記述した場合にどのような動きをするのかを紹介します。

書籍のサンプルでは、以下のようなコードになっています。

table.tasks {
  width: 560px;
  margin: 5px auto;
  background-color: #eee;
  border-collapse: collapse;
  border-spacing: 0;
}

table.tasks tr {
  border: solid 1px #ccc;
}

table.tasks td {
  padding: 5px;
}

table.tasks col.name {
  width: 320px;
}

table.tasks col.due_date {
  background-color: #ddd;
}

これをSCSSで書きなおしてみます。

まず、書籍と同様にコントローラを作成します。

$ rails generate controller tasks
      create  app/controllers/tasks_controller.rb
      invoke  erb
      create    app/views/tasks
      invoke  test_unit
      create    test/functional/tasks_controller_test.rb
      invoke  helper
      create    app/helpers/tasks_helper.rb
      invoke    test_unit
      create      test/unit/helpers/tasks_helper_test.rb
      invoke  assets
      invoke    coffee
      create      app/assets/javascripts/tasks.js.coffee
      invoke    scss
      create      app/assets/stylesheets/tasks.css.scss

この時に、app/assets/stylesheets/tasks.css.scssも作成されます。

先ほどのCSSをapp/assets/stylesheets/tasks.css.scssに記述します。SCSSでは以下のようになります。

// Place all the styles related to the tasks controller here.
// They will automatically be included in application.css.
// You can use Sass (SCSS) here: http://sass-lang.com/

table.tasks {
    width: 560px;
    margin: 5px auto;
    background-color: #eee;
    border-collapse: collapse;
    border-spacing: 0;

    tr {
        border: solid 1px #ccc;
    }

    td {
        padding: 5px;
    }

    col.name {
        width: 320px;
    }

    col.due_date {
        background-color: #ddd;
    }
}

このようにCSSで書きづらかった階層関係が非常にわかりやすく書くことができます。個人的に困っていたデザイナさんが作ってくれた新しいデザインを忙しいとかいう理由で一番下に追加して阿鼻叫喚とかいうことが、この階層化によって発生しづらくなっています。

さて、今まではCSSの指定は <%= stylesheet_link_tag :all %> として、public/stylesheets 以下のものを全て読み込む形になっていましたが、Rails 3.1からは、 <%= stylesheet_link_tag “application” %> となり application.css のみ標準で読み込む形になります。ということは、tasks.css はどこにいくのでしょうか？正解は、SCSSを利用してtasks.css.scssの内容が application.css に入るのです。

実際にこの仕組みをみてみましょう。

先ほど作成したコントローラにアクセスしてみます。

Started GET "/tasks" for 127.0.0.1 at 2011-08-09 14:10:51 +0900
  Processing by TasksController#index as HTML
MONGODB hinagiku_development['tasks'].find({:done=>false})
Rendered tasks/index.html.erb within layouts/application (616.2ms)
Completed 200 OK in 678ms (Views: 677.1ms)


Started GET "/assets/application.css" for 127.0.0.1 at 2011-08-09 14:10:52 +0900
Compiled ~/develop/ruby/mongo_rails3_test/hinagiku/app/assets/stylesheets/tasks.css.scss  (45ms)  (pid 85886)
Compiled ~/develop/ruby/mongo_rails3_test/hinagiku/app/assets/stylesheets/application.css  (1ms)  (pid 85886)
Compiled ~/develop/ruby/mongo_rails3_test/hinagiku/app/assets/stylesheets/application.css  (0ms)  (pid 85886)
Served asset /application.css - 304 Not Modified (96ms)


Started GET "/assets/application.js" for 127.0.0.1 at 2011-08-09 14:10:52 +0900
Served asset /application.js - 304 Not Modified (19ms)

ここで、Compiledという文字があるとおり、コンパイルをしているということになります。

実際に出力されるCSSは以下のようになります。

/*
 * This is a manifest file that'll automatically include all the stylesheets available in this directory
 * and any sub-directories. You're free to add application-wide styles to this file and they'll appear at
 * the top of the compiled file, but it's generally better to create a new file per style scope.
*/
/* line 5, /Users/btm/develop/ruby/mongo_rails3_test/hinagiku/app/assets/stylesheets/tasks.css.scss */
table.tasks {
  width: 560px;
  margin: 5px auto;
  background-color: #eee;
  border-collapse: collapse;
  border-spacing: 0;
}
/* line 12, /Users/btm/develop/ruby/mongo_rails3_test/hinagiku/app/assets/stylesheets/tasks.css.scss */
table.tasks tr {
  border: solid 1px #ccc;
}
/* line 16, /Users/btm/develop/ruby/mongo_rails3_test/hinagiku/app/assets/stylesheets/tasks.css.scss */
table.tasks td {
  padding: 5px;
}
/* line 20, /Users/btm/develop/ruby/mongo_rails3_test/hinagiku/app/assets/stylesheets/tasks.css.scss */
table.tasks col.name {
  width: 320px;
}
/* line 24, /Users/btm/develop/ruby/mongo_rails3_test/hinagiku/app/assets/stylesheets/tasks.css.scss */
table.tasks col.due_date {
  background-color: #ddd;
}
// Place all the styles related to the tasks controller here.
// They will automatically be included in application.css.
// You can use Sass (SCSS) here: http://sass-lang.com/

出力されたファイルはほとんど元の変換前と同じ内容になりました。すばらしい！

さて、今回 /assets/stylesheets にアクセスしているのに気をつけてください。以前では /stylesheets にアクセスしていたものが変わっています。これは、assetという仕組みを利用しているためで、config/application.rbから変更ができます。

    # Enable the asset pipeline
    config.assets.enabled = false

falseになっている場合は、以前と同様に public/stylesheets 以下を見に行くようになります。

SCSSは非常に面白い仕組みです。まさに幸福実現です。Sass、そしてSassy CSS (SCSS)には非常に多くの例があります。ぜひ、ご一読の上、Rails 3.1+SCSSの世界に飛び込んで下さい。

ちなみに、筆者はCoffeeScriptよく知らないので、そっちの方は別の人が記事にしてくれると期待しています。

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

社内用の開発の為、ノートPCで自宅⇔会社で同じリポジトリを使いたいという要望がわりと多くあると思いますが、そんな時に便利なソフトウェアを紹介します。まず、以下の図をみてください

  上記のイメージにある通り、社内にいる人間はそのままリポジトリへアクセスできますが、その人がノートPCをもって自宅へ帰り、チェックアウトしようとしてもできません。

  もし社内にsshログインできるようなゲートウェイサーバがあるのであれば、そのサーバを使ってポートフォワードをしてチェックアウトすればひとまず目的は達成できそうです。 でも、なんか不便だと思います。やり方は様々かと思いますが、社内では

% svn co http://repo.example.co.jp/prjname/ 

とするだけで事足りたのに、ポートフォワードを使って外出先からチェックアウトする時は

% svn co http://localhost:8080/prjname/

みたいな事をしなくてはならず、スマートじゃない気がします。そもそもリポジトリのURLを同等に扱いたいです。 これをtsocksというコマンドで解決したいと思います。MacユーザはMacPortsから導入するのが楽です。

% sudo port install tsocks

設定ファイルを準備します。以下のような感じで。

% cat /opt/local/etc/tsocks.conf 
server = 127.0.0.1
server_port = 1080
tordns_enable = false
server_type = 5

この状態でゲートウェイサーバへログインをして、セッションを貼るようにしてみます。

% ssh -D 1080 ゲートウェイサーバ

上記セッションを活かした状態で、社内ネットワークの「外」からアクセスしてみます。 社内にいるときにチェックアウトしたコマンドの先頭に”tsocks”をつけるだけでsocks経由でのアクセスにすることができます。

% tsocks svn co http://repo.example.com/prjname/

あとはソースコードにバンバンコミットです。社内では

% svn ci -m "test commit" filename

などとして普段通りアクセスしていればよいですし、外出先などでは

% tsocks  svn ci -m "test commit" filename

のように、tsocksをつければいいだけです。 subversionを例に使いましたが、gitでも同じ事です。 これだったらあまり難しい事を考えず、どこでも同じURLをつかってリポジトリにアクセスできるので、便利じゃないかと思います。

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

こんにちは、SHIMADAです。

今回は、いつもと少し違った趣向ですが、推薦図書の紹介をしたいと思います。

コードコンプリート CODE COMPLETE 第二版（上巻・下巻）
日経BPソフトプレス刊
Steve McConnell（スティーブ・マコネル）著

 
この本にはかなり思い入れがあります。
というのも、IT業界で飯を食おうと決心したときに、最初に大枚をはたいて買った本だったからです。そのときはまだ初版でした。
情報系の専門教育を受けていない自分が、これまでまがりなりにもやってこれたのは、この本のおかげだと思います。

このエントリで言いたいこと

上下巻に分かれていて、それぞれ六千円超という値段なので、買うとしたらかなり躊躇してしまうかも知れません。
 

でも、買え！

 
それだけの価値があります。
もしかしたら既に職場にある、あるいは申請したら買ってくれる、といった恵まれた環境にいらっしゃる方もおられるかも知れません。
どんなことが書いてあるのか、事前に確かめられる幸運に感謝しましょう。
 

でも、買え！

 
図書館で本を借りたときよく体験するのですが、娯楽のための小説や雑誌とちがって、こういう歯ごたえのある本は自分の懐を痛めて買わないと、人間なかなか読まないものです。
大丈夫。一万三千円、充分モトが取れる本です。自分に投資しましょう。

どんな本なのか？

三行でおk、という声が聞こえてきたので三行でまとめると、

• ソフトウェアコンストラクションに関する
• 特定の言語や方法論に限定されない
• 普遍的なベストプラクティス

を広い範囲で収集し、体系的にまとめた本です
プログラマ、エンジニアとして、最低限知っておかなければいけない、でも入門書や教科書にはあまり載っていない現場寄りの知識を具体的に教えてくれます。
知っていればしなくていい苦労、というものがあります。システムの開発に携わるにあたって、しなくていい苦労を避けたい人に読んで欲しい本です。
またそういう種類の苦労は、えてして他の人を巻き込みます。いらぬ苦労に巻き込まれたくない人にもおすすめです。

「ソフトウェアコンストラクション」ってなに？

「ソフトウェアコンストラクション」というのは耳慣れない言葉かもしれません。
システム開発における各種アクティビティの一部で、下図のグレーで塗られた楕円の部分になります。（文字の大きさが、本書における取扱いのウェイトを示しています。）
「コーディングとデバッグ」が最も大きなウェイトを占めていて、「課題定義」「要求開発」「システムテスト」などは範囲外となっています。

本書 p.6 図1-2 を引用

ただし、この本で触れていないアクティビティが、システム開発にとって重要でないということはないです。
そういった方面については他に有用な書籍が充実しているので、あえて焦点を当てていないという側面があります。

内容についてもっと詳しく知りたい

@ITさんのサイトで上下巻の完全な目次と、一部の章の本文が公開されています。

＠IT： BOOK Preview：Code Complete 第2版

• 第6章 クラスの作成（前半）
• 第6章 クラスの作成（後半）
• 第24章 リファクタリング
• 第34章 ソフトウェア職人気質とは

本書を買うつもりがない人も、上記ページは無料で公開されてますので、是非読んでみて下さい。

最後に本文からの引用を

第一部「基礎を固める」から、本書の姿勢をよく表している一節を引用してみます。

言語の「中で」のプログラミングと言語の「中へ」のプログラミングの違いを理解することは、本書の内容を理解する上で重要である。
重要なプログラミング原理のほとんどは、言語の種類ではなく、言語を使用する方法に依存する。使用したい構造が言語に含まれていない、あるいは何らかの問題が起きやすいという場合は、それらを補正できないかどうか試してみよう。コーディング規約、標準、クラスライブラリなどの補強を独自に考案してみよう。

（上巻 p.83 4.3.1 「言語の『中へ』のプログラミングの例」より）

追記：弊社社員へ

本書を使った読書会／勉強会について検討しています。（どういう形で進めるのがいいか、頭を痛めています）
興味のある人は是非SHIMADAまで一声掛けて下さい！

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

前回、PHPのソースインストールで32bit版CentOSへのインストール方法を記載しましたが、最近64bit版CentOSにインストールする機会があったので、PHP以外も含め変更点をメモしておきます。

●PHPのインストール

下記のエラーが出るので、オプションに「–with-libdir=lib64」を追加する。

configure: error: mysql configure failed. Please check config.log for more information.
# ./configure –with-apxs2 –with-bz2 –enable-calendar –with-curl –enable-exif –enable-ftp –with-gd –with-gettext –with-gmp –with-ldap –enable-mbstring –with-mcrypt –with-mysql –with-mysqli –with-openssl –with-pdo-mysql –with-pspell –enable-shmop –enable-soap –enable-sockets –enable-sysvmsg –enable-wddx –enable-xml –with-xsl –with-zlib –with-config-file-path=/etc –with-config-file-scan-dir=/etc/php.d –with-libdir=lib64

●saslauthdの設定

「/usr/lib/sasl2」ではなく「/usr/lib64/sasl2」のを変更する。

# cd /usr/lib64/sasl2
# cp -a smtpd.conf smtpd.conf,20110401
# vi smtpd.conf
—- ここから —-
### START 2011/04/01 myname ###
#pwcheck_method: saslauthd
pwcheck_method: auxprop
### END ###
—- ここまで —-

●Squidの設定変更

「/usr/lib/squid/ncsa_auth」ではなく「/usr/lib64/squid/ncsa_auth」にする。

# cd /etc/squid
# cp -a squid.conf squid.conf,20110401
# vi squid.conf
—- ここから —-
### START 2011/04/01 myname ###
auth_param basic program /usr/lib64/squid/ncsa_auth /etc/squid/.htpasswd
### END ###
—- ここまで —-

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

前回に引き続き、Passengerに標準でインストールされるステータス確認ツールの紹介をしたいと思います。

passenger-memory-stats

　passengerのプロセスのメモリの使用状況が見れます。出力内容がpassenger 3.0より変わったようで、3.0より前、3.0以降で以下のようになります。

3.0より前

-------------- Apache processes --------------
PID    PPID   Threads  VMSize   Private  Name
----------------------------------------------
16483  1      1        9.7 MB   0.2 MB   /usr/local/apache2/bin/httpd
22344  16483  1        10.0 MB  0.6 MB   /usr/local/apache2/bin/httpd
22693  16483  1        10.1 MB  0.6 MB   /usr/local/apache2/bin/httpd
22695  16483  1        10.4 MB  0.8 MB   /usr/local/apache2/bin/httpd
22710  16483  1        10.0 MB  0.5 MB   /usr/local/apache2/bin/httpd
22711  16483  1        10.4 MB  0.8 MB   /usr/local/apache2/bin/httpd
22712  16483  1        10.0 MB  0.5 MB   /usr/local/apache2/bin/httpd
22726  16483  1        10.1 MB  0.6 MB   /usr/local/apache2/bin/httpd
22729  16483  1        10.1 MB  0.6 MB   /usr/local/apache2/bin/httpd
22746  16483  1        10.0 MB  0.4 MB   /usr/local/apache2/bin/httpd
22751  16483  1        10.0 MB  0.4 MB   /usr/local/apache2/bin/httpd
22768  16483  1        10.0 MB  0.5 MB   /usr/local/apache2/bin/httpd
22770  16483  1        9.8 MB   0.3 MB   /usr/local/apache2/bin/httpd
22771  16483  1        9.8 MB   0.2 MB   /usr/local/apache2/bin/httpd
22772  16483  1        9.8 MB   0.2 MB   /usr/local/apache2/bin/httpd
### Processes: 15
### Total private dirty RSS: 7.11 MB

--------- Passenger processes ---------
PID    Threads  VMSize   Private  Name
---------------------------------------
16505  13       7.6 MB   0.6 MB   /usr/lib/ruby/gems/1.8/gems/passenger-2.1.3/ext/apache2/ApplicationPoolServerExecutable 0 /usr/lib/ruby/gems/1.8/gems/passenger-2.1.3/bin/passenger-spawn-server  /usr/bin/ruby  /var/rails/tmp/passenger.16483/info/status.fifo
16506  1        7.4 MB   4.5 MB   Passenger spawn server
17566  1        48.1 MB  35.5 MB  Rails: /var/rails/huga
19798  1        53.7 MB  39.7 MB  Rails: /var/rails/hoge
19800  1        51.1 MB  37.3 MB  Rails: /var/rails/hoge
22320  1        37.9 MB  30.1 MB  Passenger ApplicationSpawner: /var/rails/huga
22325  1        51.0 MB  37.2 MB  Rails: /var/rails/hoge
22327  1        52.4 MB  38.5 MB  Rails: /var/rails/hoge
22329  1        37.6 MB  29.6 MB  Rails: /var/rails/hoge
### Processes: 9
### Total private dirty RSS: 252.97 MB

項目の説明

VMSize

仮想メモリ領域のサイズPrivate

ディスクとの同期が取れていない物理メモリの領域のサイズ(dirtyと表記されるもの) .

3.0以降

--------- Apache processes ----------
PID    PPID  VMSize   Resident  Name
-------------------------------------
644    1     15.6 MB  7.5 MB    /usr/apache2/2.2/bin/httpd
25364  644   15.0 MB  4.1 MB    /usr/apache2/2.2/bin/httpd
652    644   15.0 MB  4.1 MB    /usr/apache2/2.2/bin/httpd
653    644   15.0 MB  4.3 MB    /usr/apache2/2.2/bin/httpd
655    644   15.0 MB  4.3 MB    /usr/apache2/2.2/bin/httpd
656    644   15.0 MB  4.3 MB    /usr/apache2/2.2/bin/httpd
25282  644   15.0 MB  4.3 MB    /usr/apache2/2.2/bin/httpd
25706  644   15.0 MB  4.3 MB    /usr/apache2/2.2/bin/httpd
26280  644   14.9 MB  2.9 MB    /usr/apache2/2.2/bin/httpd
25284  644   15.0 MB  4.3 MB    /usr/apache2/2.2/bin/httpd
25283  644   15.0 MB  4.3 MB    /usr/apache2/2.2/bin/httpd
6255   644   15.0 MB  4.3 MB    /usr/apache2/2.2/bin/httpd


-------- Nginx processes ---------



---- Passenger processes ----
PID  VMSize   Resident  Name
-----------------------------
648  4.6 MB   3.0 MB    PassengerWatchdog
649  5.5 MB   4.0 MB    PassengerHelperAgent
651  10.6 MB  5.2 MB    PassengerLoggingAgent

　ApacheとNginxとWebサーバーのプログラムごとで表示されるようになりました。自分の検証環境はApacheで動作させているので、Nginxで動いているプロセスは表示されていません。

項目の説明

VMSize

仮想メモリ領域のサイズResident

物理メモリの領域のサイズ.

　また、3.0より前のバージョンだとapxs, httpdにパスが通ってないとエラーになり実行できません。

　その場合、

 $ APXS2=[apxsのパス] passenger-memory-stats

か、または、

 $ HTTPD=[httpdのパス] passenger-memory-stats

とすれば、実行できます。また、root権限で実行しないとPrivateの合計が取得できず表示が以下のようになります。

 ### Total private dirty RSS: 0.00 MB (?) 

　サイトの動きが怪しい時など、前回紹介したpassenger-statusと合わせて使ってもらえると、怪しいプロセスを見つけるのに便利かと思います。それでは。

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

アリペイ支払いにも3種類があります。

（ネット上すでにrails開発用のプラグインがあるようです）

今日はそのうちに、一番簡単な即時支払いについてご紹介します。即時支払いというはエンドユーザが支払った金額はすぐ売り方のアリペイアカウントに入る支払いで、
要求／応答パタンです。

一．アリペイ支払い用のデータの用意
パラメータ説明
必須パラメータ：
1.service：api名称、”create_direct_pay_by_user”、固定の文字列
2.partner：パートナーID、アリペイ社が発行する売り方のID
3.return_url:エンドユーザがアリペイシステムで支払完了後、パートナーシステム（売り方）に戻る時のURL
4.out_trade_no：注文番号などのパートナーシステムにユニックの注文識別番号
5.subject：商品名称
6.total_fee：合計金額（priceと同時に渡せない）
7.payment_type：1で固定
8.seller_email：パートナーシステム（売り方）がアリペイに登録する時のメールアドレス（seller_idでもOK）
9.sign：パラメータをサインする後の値
10.sign_type：サインアルゴリズム

ここではパラメータのサインについて説明する必要があります。
1、パラメータ名の昇順（signとsign_type以外）でソートする。
パラメータ名が同じ場合、パラメータ値の昇順でソート。
↓
2、アリペイ社が発行するパートナーの秘密キーを直接接続
↓
3、指定のsign_typeで、サインする

例、
out_trade_no=20111111111111
partner=2088123456789000
payment_type=1
return_url=http://example.com/alipay/alipay_return.jsp
seller_email=taro@example.com
service=create_direct_pay_by_user
subject=AAA
total_fee=0.01
秘密キー：abc123

サイン前のパラメータは下記になります。
out_trade_no=20111111111111&partner=2088123456789000&payment_type=1&return_url=http://example.com/alipay/alipay_return.jsp&seller_email=taro@example.com&service=create_direct_pay_by_user&subject=AAA&total_fee=0.01abc123

※サイン用のパラメータ値はURLエンコードしないでください。

二、連携用URLを生成、エンコード、連携する
上記の1～10までパラメータを接続して、特殊記号が入っている場合、エンコードする必要があります。

一番基本的なものをご紹介しました。
上記の1～10以外、いろいろパラメータが渡せます。必要に応じてアリペイ社のドキュメントをご参照ください。

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

リンクになっているバナーなどの画像を簡単にonmouseで変化させたい時のちょっとしたTipsです。

マウスオーバーで切り替えたいとき、
普通は画像を別途用意してjavascriptのonmouse処理を使って切り替えます。
でもやんごとない事情で画像を用意できない時もあります。
それでも変化させたい！
そんな時はcssで透明度を指定することで
あたかもonmouse属性を使っているかのようなフリをすることができます。

cssは簡単。
a:hover img {
    filter: alpha(opacity=75);
    opacity:0.75;
}

これだけ。
数字はゼロに近づくほど透明になります。
画像を半透過させることで変化をつけているので、
背景に柄があったり背景色と混ざってへんな色になったり、
そもそも画像の一部だけ変化させたいということには対応できませんが
画像が用意できないなど取り急ぎ必要なときにはちょっと使える小技です。

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

ctagsとはソース内の変数やメソッドを解析し、インデックスを作成するツールです。

インデックスを作成しておくと、Vimなどで指定のキーを叩くことで、現在のカーソル位置

にある変数やメソッドの定義にジャンプすることができます。

■ ctagsのインストール（MacOS Xの場合)

MacOS X 10.3 以降では標準でctagsがインストールされていますが、BSD由来のもので

一部オプションが使えなかったりするので、Exuberant Ctagsをmac portsでインストールします。

$ sudo port install ctags

インストールできたら以下のコマンドで対応している言語を見てみましょう。

$ ctags --list-languages
C
C++
C#
Cobol
DosBatch
Eiffel
Erlang
Flex
Fortran
HTML
Java
JavaScript
Lisp
Lua
Make
MatLab
OCaml
Pascal
Perl
PHP
Python
REXX
Ruby
Scheme
Sh
SLang
SML
SQL
Tcl
Tex
Vera
Verilog
VHDL
Vim
YACC

■ タグの作成

今回はRubyのコードを解析してタグを作成してみます。

Railsのアプリケーションルートに移動します。

$ cd [RAILS_ROOT]

タグを作成します。

※コマンド実行の前に、ctagsのパスが/opt/local/bin/ctagsになっていることを確認してください

$ ctags -R

アプリケーションルートディレクトリ直下にtagsというファイルができたはずです。

試しに、tagsファイルを作成したアプリケーションで適当なファイルをVimなどで開き、

ctrl + ] を打ってみてください。

カーソル位置にあるメソッド定義にジャンプできます。

これでエディタでのコーディングが少し楽になります。

以上です。

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

弊社にて販売しているSNSパッケージはスケジューラとして社内で利用されていますが、icalデータとして出力するインターフェースも持ち合わせているので、折角だからGoogleカレンダーと同期をとって利用したいと思います。

GCALDaemonというソフトウェアを利用すれば、比較的簡単に同期が実現できます。

今回は Mac OS X 10.6 上で設定を施してみたいと思います。

■ 必要なもの

• Java 1.5 以上のランタイム環境
• Gmailのアカウント
• iCal 互換のアプリケーション

■ Mac OS X へのインストール

http://sourceforge.net/projects/gcaldaemon/files/linux/ からLinux用バイナリzipをダウンロードし、

mkdir -p ~/gnu/ などとしてインストール用ディレクトリを作成します。

そこで以下のオペレーションを実行します。

cd ~/gnu
unzip ~/Downloads/gcaldaemon-linux-1.0-beta16.zip
chgrp -R admin ~/gnu/GCALDaemon
chmod -R g+w ~/gnu/GCALDaemon
chmod 755 ~/gnu/GCALDaemon/bin/*.sh

設定をテストするため、以下のコマンドを実行します。

cd ~/gnu/GCALDaemon/bin
 ./password-encoder.sh
Your Google password: Googleアカウントのパスワードを入力します

Original password: 上で入力したパスワードが表示されます
Encoded  password: xxxxxxxxxx ここで出てきた文字列を後ほど利用します

Sample configuration options for GCALDaemon:

file.google.password=xxxxxxxxxx
ldap.google.password=xxxxxxxxxx

notifier.google.password=xxxxxxxxxx
sendmail.google.password=xxxxxxxxxx
mailterm.google.password=xxxxxxxxxx

この後で設定ファイルも編集します。~/gnu/GCALDaemon/conf/gcal-daemon.cfg を開いてください。

% diff -U0 gcal-daemon.cfg.default gcal-daemon.cfg
--- gcal-daemon.cfg.default     2011-05-23 20:36:16.000000000 +0900
+++ gcal-daemon.cfg     2011-05-23 20:42:32.000000000 +0900
@@ -62 +62 @@
-file.ical.path=/usr/local/sbin/GCALDaemon/google.ics
+file.ical.path=/Users/myname/gnu/GCALDaemon/ical.ics
@@ -65 +65 @@
-file.google.username=example@gmail.com
+file.google.username=myname@gmail.com
@@ -68 +68 @@
-file.google.password=328$$gbv1WZhRGbhN2Z
+file.google.password=047$hogehogehog
@@ -71 +71,2 @@
-file.private.ical.url=/calendar/ical/example%40gmail.com/private-495cf94a5c0f1bfg/basic.ics
+file.private.ical.url=/calendar/ical/myname%40gmail.com/private-f1ldld54d7f9888316e6dlflf9ldld8hoge/basic.ics
+

設定差分は上記の通りです。

また、file.private.ical.urlに関してはGoogleカレンダーの設定から「限定公開URL」のICALリンクをクリックしてでてきた文字列のhttps://www.google.com/以降の文字列をペーストしてください

ここまでで基本的な設定はできました。一度きちんと同期ができるか、以下のコマンドを実行してみてください。

% ~/gnu/GCALDaemon/bin/sync-now.sh

コマンドを実行した後、ical.icsファイルの内容がGoogleカレンダーに反映されていたら成功です。

icalファイルを出力するアプリケーションに対してwgetやcurlなどでファイルをgetするようcrontabにしかけておきます。

% crontab -l
0 * * * * (cd ~/gnu/GCALDaemon ; curl -O http://sns.kbmj.jp/users/myname/calendar/ical.ics ; /Users/myname/gnu/GCALDaemon/bin/sync-now.sh ) > /dev/null 2>&1

これで１時間おきに同期がおこなわれた事になります。

他にもいろんなパターンでカレンダー同期がGCALDaemonで出来ますので、是非試してみていただければと思います。

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

rick No22です。
今回はnodeJSついてです。
nodeJSとは？nodeJSが生まれた経緯等話していきます。

nodeJSとは？

「JavaScriptを用いたNon-blocking I/O環境」です。

Non-blocking I/Oとは？

データの送受信を行う際に、完了せずに他の処理を開始する通信方式です。
例えるならば、
洗濯機を動かしつつ掃除して完了したら洗濯物を干すといったながら作業のようなものです。

nodeJSが生まれた経緯

「C10k問題対策用」としてnodeJSは誕生しました。
※ Cは「Client」10kは「1万台」を表しており「クライアント1万台問題」ともいわれています。

C10k問題とは？

クライアントの数が多すぎてサーバがパンクする問題です。
2009年当時、「apache」ｖｓ「nginx(ｴﾝｼﾞﾝｴｯｸｽ)」という構図がありました。
※apacheはスレッド方式、nginxはイベントループ

apacheのスレッド

スレッドはクライアントが増加するごとにスレッドが増加し、
スレッドが増加するごとにメモリの使用率が増加。

nginxのイベントループ

全ての実行要求を一つのキューに保存し、一つ一つ実行していく。

スレッドは使用するユーザが増えれば増えるほどメモリをくうため、イベントループのnginxが有利という形になりました。
しかし、イベントループにも弱点があります。

実行できる要求が一つのみになるということは、
その一つの処理が遅いと他の処理もその分遅れてしまうことになります。
この問題を解決しようと考えたのがそもそものnodeJSの始まりです。
ではどうやって解決したのか？
その答えは最初に述べた「Non-bloking I/O」が使用されます。
Non-bloking I/Oを使用することにより、
実行要求をそれぞれ平行して処理することを可能にしました。
イベントループを採用している言語は他にもあり、
Python：Twisted
Ruby:EventMachine
Perl:CokoのAnyEvent
などがあるが、
Non-blocking I/Oは強制されていない。
このNon-blocking I/Oを強制したものがnodeJSです。

ためしに触ってみたい方は、
はじめての共同作業 Canvas編がおすすめです。
これを使用するにあたって1点注意点が有ります。
nodeJSなど使用するものすべて最新で動かすことができますが、
落としたファイルをそのまま起動させようとすると
TypeError: Object #