2014年09月29日
_ [debian] armのRubyビルドでぼっちcontribute
Rubykaigiでのakrさんの発言を機に、Rubyへのぼっちcontributionとして、OpenBlocks AX3を使ったarmelアーキテクチャでのRubyデイリービルドを始めてみている。
結果は http://rubyci.org/ にマトリックス表で出ていて、「Debian 7.5 armhf」というのがそれ。環境はDebian Wheezyのネイティブarmelに、lxcコンテナのやはりWheezy環境を作ってそこでビルドさせるようにしてる。
ビルド設定自体はとても簡単で、akrさんのGitHubにあるchkbuild ( https://github.com/akr/chkbuild.git ) というツールセットを使えば自動でtrunk、2.1、2.0、1.9のビルドをして、リポートログとHTMLを吐き、さらにssh+rsyncでログのアップロードをするところまでやってくれる。さすがです。今はビルドログとHTMLは http://kmuto.jp/build-ruby/arm/ に出力している。
だいたい1リリースビルドあたり4時間かかるので、4ビルドで16時間。終わって一息ついたと思ったらまた実行、という感じ。ただぷらっとホームさんに交換してもらって以来、温度は90度とかになることはなくなって、佳境でもだいたい70数度で留まっている。
で、ビルドのほうは何か様子がおかしくて、どのビルドにおいてもログを見ていただくとわかるようにrubyspec/core/process/kill_spec.rbでTimeoutが発生している。
Process.kill - signals the process group if the PID is zero/home/chkbuild/build/20140926T013004Z/rubyspec/core/process/fixtures/kill.rb:25:in `initialize': No such file or directory @ rb_sysopen - /home/chkbuild/build/20140926T013004Z/rubyspec_temp/1525-process_kill_signal_file (Errno::ENOENT) from /home/chkbuild/build/20140926T013004Z/rubyspec/core/process/fixtures/kill.rb:25:in `open' from /home/chkbuild/build/20140926T013004Z/rubyspec/core/process/fixtures/kill.rb:25:in `<main>' timeout: output interval exceeds 600.0 seconds. timeout: the process group 4007 is alive. PSOUT PGID PID ELAPSED %CPU VSZ COMMAND COMMAND PSOUT 4007 4007 11:35 90.6 230032 ruby /home/kmuto/chkbuild/tmp/build/20140926T013004Z/bin/ruby -v /home/chkbuild/build/20140926T013004Z/mspec/bin/mspec-run -V -f s -B /home/chkbuild/build/20140926T013004Z/rubyspec/ruby.1.9.mspec rubyspec/command_line rubyspec/core rubyspec/language rubyspec/library rubyspec/optional/capi PSOUT 4007 4007 10:06 0.0 230032 ruby-timer-thr /home/kmuto/chkbuild/tmp/build/20140926T013004Z/bin/ruby -v /home/chkbuild/build/20140926T013004Z/mspec/bin/mspec-run -V -f s -B /home/chkbuild/build/20140926T013004Z/rubyspec/ruby.1.9.mspec rubyspec/command_line rubyspec/core rubyspec/language rubyspec/library rubyspec/optional/capi PSOUT 4007 4391 10:42 0.0 0 date <defunct> [date] <defunct> PSOUT 4007 4647 10:22 0.0 0 ruby <defunct> [ruby] <defunct> PSOUT 4007 4650 10:22 0.0 0 ruby <defunct> [ruby] <defunct> timeout: INT signal sent. failed(rubyspec CommandTimeout)
いまいち釈然としないのだが、なぜかテンポラリシグナルファイルの作成ができなくて、そのままタイムアウトまで待ち続けてしまうようだ。ほかのアーキテクチャのビルドでは発生していないのがまた不思議。lxc内固有なのだろうか。
と思ったけど、なんかその前のtest/dlでもいろいろ変なエラーが出ているな……。
_ [debian] bash問題について
先週はbash問題が一部界隈を賑わせていたわけだが、DebianのほうもDSA-3032、DSA-3035という形で修正対応が済んでいる。
- Wheezy (security.debian.orgより): 4.2+dfsg-0.1+deb7u3
- Jessie, Sid: 4.3-9.2
- Squeeze-lts: 4.1-3+deb6u2 ←amd64、i386のみ。また、lts使用は専用のAPTリポジトリ行( deb http://ftp.jp.debian.org/debian squeeze-lts main non-free contrib )が必要。
- Sarge, Etch, Lenny: http://blog.bofh.it/debian/id_451 Marco作だからたぶん大丈夫だけど非公式なのでat your own risk。なんか今提供先サイトがつながらない？
もともとDebianは、(ユーザーインタラクションシェルのほうはともかく)内部実行されるような各スクリプトについてはbash依存をなくしていこうという方針で、攻撃のとっかかりとなる/bin/shは、/bin/bashではなく/bin/dashというより小規模で機能の限定された——というかPOSIX準拠のシェルに向けられているので、環境変数を介した攻撃コード注入は、/bin/bashを明示的に呼び出すコードが攻撃経路内に存在していなければ被害を受けないと思われる。
とはいえ、どこにそういうコードが含まれているかわからないし、細工で/bin/bashが呼び出されるような手法もないとは言い切れないので、アップデートはちゃんと行おう。
なお、明示的に/bin/shを使っていたつもりはなくても暗黙に/bin/shを呼び出している環境というのはテック系サイトでも紹介されているようにかなり多く、systemとかpopenとか、rbenvとか、gunzip(これは明示で/bin/bash呼んでる)とかxzmoreとか、mail alias pipeとか……。クライアントなMac OS Xでは高度な使い方をしていない限り大丈夫だ、とAppleさんがアナウンスしているようだけど、Rails勉強するぜーといった環境でrbenvを使って放置してると、シェルで可能なあらゆることをされて、バックドアなども埋め込まれる可能性があるね。
Webサーバーのログを見ていると、世界各国からpingだのpasswd表示するだのrm -rfだのボット埋め込んで自己消去するだの、とやりたい放題のコードが来てて面白い。
