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が正常に起動したことを確認いたしました。
2014-01-14 (Tue) [長年日記]
_ RailsでMySQLを使う際のcollation周りの問題について
RailsでMySQLを使う時のcollation周りの注意点のメモ。
デフォルトのcollation設定
Railsでrake db:create:allとかすると、デフォルトではcollationがutf8_unicode_ciになるが、大文字小文字や半角全角を区別しないだけならまだしも「パ」と「バ」の区別もされない。たぶん、欧米の人にはutf8_unicode_ciの方が都合がいいんだろうけど。
以下のページの手順でutf8_general_ciやutf8_binに変更しておくとよい。
validates_uniqueness_ofのcase_sensitiveオプション
以下のページで指摘されているように、validates_uniqueness_ofのcase_sensitiveオプションはデフォルトがtrueなので、大文字小文字を区別しないcollationのテーブルでもBINARYキーワード付きで大文字小文字を区別しない検索をしてしまう。
collationが*_ciの時はいちいちcase_sensitiveオプションを指定しないといけないけど、DRYじゃない。
collationを参照してデフォルトの動作を変えるプルリクエストを送ってみたけど、あまり反応がない。 RDBMSによってデフォルトの動作を変えたくないのかもしれないけど、それならデフォルトのcollationをutf8_binにするべきだ。
このあたりRailsでMySQLを使っている人は不満に思っていないのだろうか。それともHerokuの影響で今時はみんなPostgreSQLなんだろうか。
2014-01-22 (Wed) [長年日記]
_ ConoHa障害
ConoHaで3日連続ホスト側のkernel panicが発生して、日記のデータが壊れたorz バックアップから復旧できたからよかったけど。
ハードウェア交換を実施するようなので、これで安定するといいなあ。
下記日時におきまして、ハードウェア交換を実施させていただきます。 ご利用のお客様にはご不便をおかけいたしますが、何卒ご理解ご協力のほどお願い申しあげます。 開始日時 ： 2014年01月23日(木) 01時00分 終了日時 ： 2014年01月23日(木) 05時00分 対象 ： 収容ホスト：cnode-a3032 ※収容ホストの確認方法は最下部に記載 作業内容 ： ハードウェア交換 影響 ： メンテナンス時間帯におきまして、VPSの停止/起動を 行いますので、一時的にVPSがご利用いただけない時間帯が 発生いたします。
2014-01-25 (Sat) [長年日記]
_ FreeBSD 10.0-RELEASE
FreeBSD 10.0-RELEASEが出ていたのでアップグレードした。
アップグレード自体はfreebsd-updateで問題なくできたが、rbenv install 2.1.0で、
The Ruby openssl extension was not compiled. Missing the OpenSSL lib?
というエラーが出るため、~/.rbenv/versions/trunkにtrunkを手動でインストールして凌ぐことにした。
目に付いた変更点は
- デフォルトのコンパイラがclangになった。
- パッケージ管理システムがpkg（前のpkgng）になった。
といったところ。
pkgはDebianのAPTみたいな使い方ができて便利そう。移行後はpkg2ngでパッケージデータベースを変換するのを忘れないように。
あと、FreeBSDのapache24はなぜかmod_slotmem_shmが含まれていないのでmod_proxy_balancerが使えなくて、以前は手動でビルドしていたのだが、せっかくpkgでバイナリパッケージを管理できるようになったのであまりソースからビルドしたくない。 結局nginxを使うことにしてお茶を濁した。
2014-01-26 (Sun) [長年日記]
_ 朧村正鬼助編〜真エンディング【ネタバレ】
昨年PS Vitaを購入して朧村正というアクションRPGをやっていたのだが、やっと鬼助編の真エンディングを見ることができた。以下ネタバレ。
このゲームは鬼助編と百姫編に分かれていて、それぞれクリアすると刀が手に入るのだが、両方の刀を装備して再度ラスボスを倒すと別パターンのエンディングを見ることができる。
さらに、魔窟の刀をすべて集めて鍛冶を行うとタイトルにもなっている朧村正を手に入れることができて、朧村正を装備してラスボスを倒すと真のエンディングを見ることができるのだ！（つまりすべてのエンディングを見るためには合計6回クリアしないといけない）
ラスボスを倒すと、なぜかヒロインの虎姫が命を落とす前にタイムスリップして、悪代官の悪事が暴かれ、虎姫の命が助かるという都合のいい展開。
これもなぜかよくわからないが、この島国にはもう敵がいないとか言って虎姫と別れ、旅に出る。勝ったらまた戻って来るらしい。
クレジット表示が終わると最後はアメリカっぽいところに鬼助が…誰と戦うんや。
百姫編ではまた別エンディングがあるらしいが、レベルを上げないと朧村正を帯刀できないので正直もうめんどい…。
昔懐かしい横スクロールアクションゲームなので、僕みたいに今時のゲームについていけないおっさんにおすすめ。アクションに自信がない人は、無双モードというイージーモードだと楽に戦える（正直魔窟は無双モードじゃないと勝てる気がしない）。