2004-01-13 (Tue)
2006-01-13 (Fri)
_ 開発スケジュール管理(2)
当初見積と残り時間ってどんな風に使うですか?預言が当たらなかった度合いを知るため?ゴールまでの距離は現在見積なのかしら。
[Journal InTime - habtmがsaveされない , 開発スケジュール管理より引用]
そうですね。> 当たらなかった度合を知るため
残り時間が0になったらタスクの完了とみなします(完了しなかったら現在見積を増やす)。
当初見積の合計と現在見積の合計は常に同じになるようにバッファを増減して調整します(つまりバッファが0にならないかぎり、エンドをずらしたり、機能を削減したりしなくてよい)。 現時点からゴールまでの距離は残り時間の合計になります。
最初細かい作業日が把握できないのが気になったんですが、進捗の度合やエンドは常に把握できるので、あまり問題ない気がします(マイルストーンごとにシートを作るのがいいのかもしれません)。
2008-01-13 (Sun)
_ CookieStoreとセキュリティ
Rails 2.0ではCookieStoreという新しいセッションストアが導入されている。 CookieStoreは、セッションデータをサーバ上のファイルやDBに保存する代りに、クッキー自体に保存する。 このため、セッションデータの読み書きのコストが減ったり、古いセッションデータ の掃除の手間がなくなる、という利点がある。
「そんなことをしたらユーザにセッションデータを改竄されるじゃないか」というのが 当然の疑問だが、HMAC(デフォルトではSHA1)によるチェックで改竄を防ぐようになっ ている。
ただし、セッションデータ自体は平文(marshal+base64)なので、中身を見られてしま う。これについては、そもそもユーザに見られては困るようなデータをセッションデ ータに格納すべきではない、という立場を取っているようだ。
ちょっと気になるのが、サーバが一度発行したクッキーは、HMACで使用する鍵を 変えたりしない限り、ずっと有効だということだ。 悪意のある第三者がクッキーを盗聴してリプレイを試みる、というケースに ついては、盗聴できたという時点で他のセッションストアの場合もセッションハイ ジャックが可能になるので、CookieStoreがとりわけ危険だというわけではない。 気になるのは、ユーザがセッションの状態を任意の時点に戻すことができる点だ。 アプリケーションの作りによっては悪さができそうな気もするのだけれど、 実際のところどうなのだろう。 「そんなことができるアプリケーションはそもそも作りが悪いのだ」と言ってすませ ることができるものなのだろうか。
たとえば、セッションデータにはユーザIDだけ格納しておいてその他の状態は全部DBに格納すれば 上記のような心配はしなくていいわけだけど、それだったら最初からActiveRecordStore を使えばいい気もする。
任意の時点にセッションの状態を戻されること自体を防ぐには、セッショ ンデータにnonceを入れておいてチェックすればよい。 ただ、サーバ側でnonce値を保存する必要があるということになるとCookieStoreの利点(高速・セッションデータの掃除が不要)がかなり損なわれる。
というわけで、簡単な解決は思い付かなかった。そもそも問題なのかどうかもよくわかっていないのだが。
最後にもう一点。CookieStoreの場合、session fixation attackの心配がなくなりそうだ。 攻撃者が被害者に特定のセッションIDを利用するように仕向けることができない(と いうかそもそもセッションID自体がない)から(見落としがあればご指摘を)。
「あれ、session fixation attackってRails 1.2.4と1.2.6で対策されたんじゃないの?」 と思われるかもしれないが、Rails 1.2.4/1.2.6ではURLでセッションID を指定できないようにしただけなので、Cookie MonsterやXSSを利用した攻撃を考え るとアプリケーション側で対策が必要だ。 認証の際にreset_sessionでセッションIDを変更すればよいのだが、自分の知るかぎり どの認証プラグインも対策してないので自分で対策する必要がある。
_ RailsによるアジャイルWebアプリーション開発第2版とRails 2.0
Rails 2.0で…という質問が今後増えることが予想されるわけですが、 とりあえず、
> gem install -v 1.2.6 rails
としてRails 1.2.6をインストールして一通りチュートリアルをこなした上で、Rails 2.0に移行されることをおすすめします。
だれか、Rails 2.0でdepotを作る手順とかまとめてくれないかなあ。
2014-01-13 (Mon)
_ ConoHaに移行してみた
ConoHaというVPSでコミュニティ支援をしているらしいので、TwitterでRubyでも使わせてもらえるかなとつぶやいたところ、使えますよというありがたいお言葉が。 成瀬さんや柴田さんと相談してCIで使わせてもらうことになりそう。
今までこのサイトはboron.rubyist.netに間借りしていたがそろそろVPSに移行しようかなと思っていたので、試しに移行してみることにした。 あまりリソースは必要ないので、1GBプラン（メモリ1GB、CPU 2コア、HDD 100GB、月額976円）。
標準のCentOSでもよかったけど、FreeBSDのカスタムイメージが提供されていてvirtioもサポートされているようだったので、ひさしぶり（10年以上ぶり？）にFreeBSDにした。
実際のスペックはこんな感じ（dmesgより）。
FreeBSD 9.2-RELEASE #0 r255898: Thu Sep 26 22:50:31 UTC 2013
root@bake.isc.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64
gcc version 4.2.1 20070831 patched [FreeBSD]
CPU: Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz (2593.86-MHz K8-class CPU)
Origin = "GenuineIntel" Id = 0x206d7 Family = 0x6 Model = 0x2d Stepping =
7
Features=0xf83fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CM
OV,PAT,PSE36,MMX,FXSR,SSE,SSE2,SS>
Features2=0x9eba2223<SSE3,PCLMULQDQ,VMX,SSSE3,CX16,PCID,SSE4.1,SSE4.2,x2APIC,P
OPCNT,AESNI,XSAVE,OSXSAVE,AVX,HV>
AMD Features=0x2c100800<SYSCALL,NX,Page1GB,RDTSCP,LM>
AMD Features2=0x1<LAHF>
real memory = 1073741824 (1024 MB)
avail memory = 1006780416 (960 MB)
Event timer "LAPIC" quality 400
ACPI APIC Table: <BOCHS BXPCAPIC>
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 2 package(s) x 1 core(s)
cpu0 (BSP): APIC ID: 0
cpu1 (AP): APIC ID: 1
リソースがもったいないのでchkbuildを動かしてみた。
この機会にRuby 2.1 / tDiary HEADに移行したけど、これについては後で書く。
_ Ruby 2.1 / tDiary HEADへの移行
実はまだRuby 2.1を使っていなかった（手元の環境はtrunk）が、日記をRuby 2.1 / tDiary HEADに移行した。
tDiaryは最初はgemで4.0.2を入れるつもりだったけど、tdiary-contribが動作しない問題やRDスタイルが動かない問題に当たってしまったので、gitでHEADを入れることにした。
gemでいったんセットアップした後で、Gemfile.localを以下のように書き換えてbundle installしたところ上手く動くようになった。
gem 'tdiary', :git => 'https://github.com/tdiary/tdiary-core.git' gem 'tdiary-contrib', :git => 'https://github.com/tdiary/tdiary-contrib.git' gem 'tdiary-style-rd', :git => 'https://github.com/tdiary/tdiary-style-rd.git' gem 'unicorn' gem 'image_size' # for image_ex.rb
最後のimage_sizeはimage_ex.rbプラグインのために必要なのだが、そもそもimage_ex.rbの画像リサイズ機能を最近だれも使っていないようで、ドキュメントにはRAAからimage_size.rbをインストールするように書いてあるけど、もはやRAA自体が存在しない。
gemでインストールできるimage_sizeの方は互換性がないようなので、image_ex.rb側をgemのimage_sizeでも動作するように修正してtdiary-contribにコミットしておいた。
_ ConoHa障害
移行エントリを書いたら早速障害に当たってしまった。
Webのコンソールでログインしたらアドレスが取れていなかったので、DHCPのままだったのを静的に設定するように修正したところ、とりあえず通信はできるようになった。 ただ、まだパケットロスが多いようだ。
raichu:~$ ping6 shugo.net PING shugo.net(v157-7-200-50.z1d3.static.cnode.jp) 56 data bytes 64 bytes from v157-7-200-50.z1d3.static.cnode.jp: icmp_seq=2 ttl=51 time=24.9 ms 64 bytes from v157-7-200-50.z1d3.static.cnode.jp: icmp_seq=3 ttl=51 time=37.3 ms 64 bytes from v157-7-200-50.z1d3.static.cnode.jp: icmp_seq=7 ttl=51 time=58.5 ms 64 bytes from v157-7-200-50.z1d3.static.cnode.jp: icmp_seq=8 ttl=51 time=43.9 ms 64 bytes from v157-7-200-50.z1d3.static.cnode.jp: icmp_seq=9 ttl=51 time=41.9 ms ^C --- shugo.net ping statistics --- 9 packets transmitted, 5 received, 44% packet loss, time 8054ms rtt min/avg/max/mdev = 24.963/41.335/58.527/10.837 ms raichu:~$ ping shugo.net PING shugo.net (157.7.200.50) 56(84) bytes of data. 64 bytes from excelsior.shugo.net (157.7.200.50): icmp_req=2 ttl=48 time=37.3 ms 64 bytes from excelsior.shugo.net (157.7.200.50): icmp_req=6 ttl=48 time=32.7 ms 64 bytes from excelsior.shugo.net (157.7.200.50): icmp_req=7 ttl=48 time=49.0 ms 64 bytes from excelsior.shugo.net (157.7.200.50): icmp_req=8 ttl=48 time=48.4 ms 64 bytes from excelsior.shugo.net (157.7.200.50): icmp_req=9 ttl=48 time=51.3 ms ^C --- shugo.net ping statistics --- 9 packets transmitted, 5 received, 44% packet loss, time 8052ms rtt min/avg/max/mdev = 32.789/43.798/51.358/7.334 ms
ping6した時にv6の逆引きの設定をしていなかったのに気付いたので設定しておいた。
メールでも連絡が来ていて対応は早そうなので、早く復旧するといいなあ（ipfwの設定ミスとかだったりして）。
追記:
ipfwを止めてデフォルトゲートウェイにpingしてもパケットロスするのでやっぱりConoHa側の問題かな。
excelsior:~$ sudo /etc/rc.d/ipfw stop net.inet.ip.fw.enable: 1 -> 0 net.inet6.ip6.fw.enable: 1 -> 0 excelsior:~$ ping 157.7.200.1 PING 157.7.200.1 (157.7.200.1): 56 data bytes 64 bytes from 157.7.200.1: icmp_seq=0 ttl=255 time=9.771 ms 64 bytes from 157.7.200.1: icmp_seq=1 ttl=255 time=33.108 ms 64 bytes from 157.7.200.1: icmp_seq=2 ttl=255 time=85.818 ms 64 bytes from 157.7.200.1: icmp_seq=3 ttl=255 time=24.208 ms 64 bytes from 157.7.200.1: icmp_seq=4 ttl=255 time=38.601 ms 64 bytes from 157.7.200.1: icmp_seq=6 ttl=255 time=12.466 ms 64 bytes from 157.7.200.1: icmp_seq=8 ttl=255 time=37.138 ms ^C --- 157.7.200.1 ping statistics --- 10 packets transmitted, 7 packets received, 30.0% packet loss round-trip min/avg/max/stddev = 9.771/34.444/85.818/23.489 ms
追記2:
原因は「外部からの不正通信の影響」とのことだった。
下記日時におきまして、ConoHaのVPSに障害が発生しておりました。 ご利用のお客様には大変ご不便をお掛けいたしましたことを深くお詫び申しあげます。 発生日時 ： 2014年01月13日(月) 16時20分頃 復旧日時 ： 2014年01月13日(月) 17時28分頃 対象 ： 収容ホスト：cnode-a3032 ※収容ホストの確認方法は最下部に記載 事象 ： 同ホストに収容のVPSでIPv4・IPv6通信不可（ローカルネットワーク・追加IP含む） 原因 ： 外部からの不正通信の影響 対応 ： 収容ホストが正常に通信できない状態となりましたので、再起動を実施。 再起動完了後、同物理サーバーに収容のVPSが正常に起動したことを確認いたしました。
_ 咳 [ふむふむ。みんなちょっとずつ違いますね。うちは「預言を当てた」ことにしたかった方向に力がかかるので、当初の見積は残さ..]