Displaying posts filed under

未分類

もんじゅ見学に行ってきた

MCスクエア

もんじゅMCスクエア

久しぶりに良く晴れた夏の休日、敦賀半島の突端にある高速増殖炉「もんじゅ」に行ってきた。とはいえ一般人はもんじゅそのものを見ることはできないので、その手前の「MCスクエア」という建物で展示物の見学&お勉強。人がほとんどいなかったせいもあって、急ぎ足ながら職員(研究員?)の方から直接説明を受けることができた。

それまで「高速増殖炉」という名称や「消費した以上の燃料を製造」とかいう謳い文句から、何となくアヤシいものを想像してしまっていたのだが、コンセプトとしては非常に明快なものだということが分かった。私が理解したところによればこんな感じだ:

そのまま燃やせる乾いた薪と、そのままでは燃やせない湿気った薪がある。
数は湿気った薪の方が圧倒的に多いので、捨ててしまうのはもったいない。
そこで乾いた薪を燃やして水を沸かすときに、周りに湿気った薪を並べておいて、
ついでに乾かすことにしよう。

例えは私が考えたものだが、そこまで外してはいないと思う。つまり乾いた薪=U235,Pu、湿気った薪=U238、乾いた薪を燃やしながら湿気った薪を乾かす=U235やPuで発電しながら、発生する中性子でU238をPuに変換する。消費した以上の燃料を生み出すというのは、10本燃やす間に11〜12本くらい乾かすことができる、という程度の意味。摩訶不思議なプロセスで燃料が”増殖”するわけではない。

あと熱の運搬に「液体ナトリウム」という、日常的感覚からはかけ離れつつも基礎的な化学知識で危険性が理解できる代物を使わなければいけない、という点がすごく不安だったのだが、実は運用上優位な点もいろいろとあるらしい。沸点が高いので常圧のまま運用できるとか、熱伝導率が高いので発電効率も高いとか、金属との相性が良いので配管の腐食が起こりにくいとか……。しかしそれでも事故が起こったのは事実なわけで、やはりナトリウムの扱いが一番難しいところなのでしょうか?と尋ねたところ、「様々な困難を克服して今がある」というような回答が返ってきた。また「ナトリウム漏れは、技術屋的には『ああ漏れたか』という程度の話だ」とも。……ここからは完全に私の想像なのだが、おそらく現場の研究員としてはナトリウム漏れ事故も「ナトリウムが漏れた、ではどうしよう、温度計が原因だから温度計を改良しよう」とかいう通常の技術的課題という認識でしかなく、「ナトリウムが漏れた、ではもう駄目だ失敗だ」的な世間の反応がもどかしいのではないだろうか。

もちろん技術的に可能だからといって、無限に税金を投入し続けて良いという話にはならない。本当に割に合うのかという議論は必要だ。また周囲の住民からすれば、何をどう説明されたところでそう簡単に割り切れるものではないだろう。しかしともすれば得体の知れない巨大事業と見られがちな高速増殖炉事業も、その裏側には確実に人間の営みが存在する。それをはっきりと感じ取ることができたのが収穫だった。

……

敦賀半島には海水浴場がたくさんあり、もんじゅへ向かう途中の道のりでも浜辺を埋め尽くす大勢の海水浴客を見ることができた。しかし半島の先端にあるもんじゅに近付くにつれて人も車も少なくなり、MCスクエアの駐車場は閑散としていた。皆もっともんじゅについて知るべき!と思った。

BlockHostsの導入・POP3編

インストールまで。標準の設定では sshd と ftpd しか有効にならない。

古い Qpopper が動いているサーバでPOP3サービスに対する攻撃を防御する必要が生じたので、POP3用の設定を追加した。

blockhosts.cfgの設定

LOGFILES に maillog のパスを追加。

LOGFILES = [ "/var/log/secure","/var/log/maillog", ]

ALL_REGEXS にログパターンを追加。qpopper用のパターンは標準で含まれてはいるが、実行ファイルの名称(=ログに記録されるプログラム名)が異なっていたのと、不正パスワード以外の失敗パターンも捕捉したかったので、下記のように追加した。

#    "qpopper-Fail":
#        r'{LOG_PREFIX{qpopper}} .* \({HOST_IP}\): -ERR \[AUTH] Password supplied ',

    "qpopper-Fail-Password":
        r'{LOG_PREFIX{in.qpopper}} .* \({HOST_IP}\): -ERR \[AUTH] Password supplied ',

    "qpopper-Fail-Access":
        r'{LOG_PREFIX{in.qpopper}} .* \({HOST_IP}\): -ERR \[AUTH] Access is blocked ',

    "qpopper-Fail-PAM":
        r'{LOG_PREFIX{in.qpopper}} .* \({HOST_IP}\): -ERR \[AUTH] PAM authentication failed ',

ENABLE_RULES の正規表現を修正して、先ほど追加した qpopper 用ルールを有効にしておく。この設定を明示的に行わないと sshd と ftpd しか有効にならないので注意が必要。

ENABLE_RULES = r'(?i)(sshd|.*ftpd|qpopper).*'

テスト

dry-run オプションを付けて実行。

sudo blockhosts.py --verbose --dry-run

hosts.allowの修正

blockhosts.py の行にqpopperを追加する。

in.qpopper, in.proftpd: ALL: spawn /usr/bin/blockhosts.py --verbose --echo "%c-%s" >> /var/log/blockhosts.log 2>&1 : allow

Redmineのマイページで終了チケットを表示しない

マイページの「報告したチケット」の中で、終了したチケットが表示されて鬱陶しかったので、
app/views/my/blocks/_issuesreportedbyme.rhtml
を修正。:conditionsの中に以下の条件を追加。

#{IssueStatus.table_name}.is_closed=0

どんなにへたくそでも一日後には絵が上手くなる方法

夜眠れなかったので、たまたま見かけた『どんなにへたくそでも一日後には絵が上手くなる方法:ハムスター速報 2ろぐ』を試してみた。

元スレ主の主張は半ば精神論になっていたので半信半疑だったが、6枚7枚と円を描き続けるうちに、ごく単純で合理的なトレーニングであることに気が付いた。要するにこれは文字通り「手を動かす訓練」なのだ。思った通りに手を動かすことができなければ、どれほど明確なイメージが頭の中にあっても、たとえ円のように普遍的で揺らぎようのないイメージであっても、上手に描くことはできない。逆に言えば明確なイメージの元で延々手を動かし続ければ、やがては適切な手の動かし方を身体が覚える。そして思った通りに手が動き、イメージ通りのモノが描き上がる、という経験は確かに楽しく、私自身10枚のつもりが気が付けば15枚以上描いてしまい、最後の方は「真っ直ぐに線を引く練習」などを延々繰り返していた。

プログラミングの世界では有名な格言がある:「プログラムは思った通りには動かない。書いた通りに動く。」絵についても同じなのかも知れない:「絵は思った通りには描けない。手を動かした通りに描ける。」

はてブのコメントを見るとプログラミングの”Hello World”に例えた方もいらっしゃっるようだが、私の感覚では、(特定のプログラミング言語の)基本的な制御構造をエディタ上ですらすらと書く練習、に相当するような気がする。プログラミングそのものの技量にはならないが、それ以前に必要となるスキルで、特に新しい言語を学ぶ場合には真っ先に習得する必要がある。

RedmineでGitのリモートリポジトリを参照

Redmineでブラウズの対象とするには local かつ bare なリポジトリでなければならないので、そのままでは使えない。そこでまず対象リポジトリのミラーとなるbareリポジトリを作る。

git clone --bare git://host/path.git
cd path
git remote add --mirror origin git://host/path.git

最近のバージョンの git では clone のオプションに –mirror を直接指定することができるらしいが、1.5.6 では上の手順が必要だった。

# git-1.6.0.6以降
git clone --mirror git://host/path.git

リポジトリを同期するには、ミラーリポジトリ内で fetch を実行する。cronで定期的に実行するよう設定しておけば実用上は十分だろう。

git fetch origin

あとはこのミラーリポジトリのパスをRedmineに設定しておく。

異なるブランチを使用する

Redmineの設定画面にはブランチ名の項目は無い。
lib/redmine/scm/adapters/git_adapter.rb
をチェックしたところ、常に”現在の”ブランチが使用されるようだ。

@branch ||= shellout("#{GIT_BIN} --git-dir #{target('')} branch") { |io| io.grep(/\*/)[0].strip.match(/\* (.*)/)[1] }

改造するのも面倒なので、異なるブランチには異なるリポジトリを割り当てることにした。上と全く同じ手順で bare リポジトリを作った後、HEADファイル内の参照を書き換える(bareリポジトリ なので checkout は使用できない)。

ref: refs/heads/your_branch

fetch の手順などは全く同じで良い。

海外ETFの本

タイトルはちょっとアレだが、至極真っ当な本。インデックス連動型の海外ETFを買って、世界経済の成長に参加しよう!というお話。敢えて一文、本書の肝となる主張を抜き出すとしたら、次の文だろうか(258ページ):

長期的にみて、世界経済が発展する限り、市場は全体として右肩上がりになります。

この理屈が理解できなかったせいで、私にとって長らく投資という行為は胡散臭い儲け話と区別がつかなかった。いや、多分今でも心の底では理解できていないと思う。失われた10年に青春を過ごした私(たちの世代)にとって、世の中というのは「短期的な上下を繰り返しながらも、緩やかに下降していく」ものだという認識が染みついているので、株価であれ、何らかの指数であれ、投資信託の基準価格であれ、中長期的に右肩上がりに上昇し続けるというのは、鼻で笑ってしまうような馬鹿げた幻想にしか思えないのだ。……むしろそういう世界観を相対化してみたくて、今の私は投資を行っているのかも知れない。

それで海外ETFだが、実際に買おうと思うと、やはり普通の投資信託よりもいろいろと敷居が高くて躊躇している。特に面倒なのが税金。海外ETFは海外株式と同じ扱いになるため、手数料の安いネット証券では特定口座が利用できない。ならば自分で確定申告を、と考えて調べてみると、これがよく分からない。売買差益が譲渡所得で申告分離課税、為替差益が雑所得で総合課税という基本は簡単なのだが、ここで日本円を米ドルに換えて、ここで○○ドルでETFを買って、ここで××ドル分を売却したとして……というリアルなシナリオに沿って考えていくと、いつどのレートでどういう所得が発生するのか、頭がこんがらがってくる。

他にも、これは本にも書いてあることだが、ETFは最低取引金額がまだ高いし、購入する際の手数料もかかるので、小額ずつ積み立てて行くのには向いていない。やはり当面は普通の投資信託で積み立てていくのが簡単そうだ。本書執筆時点では存在していなかったMSCI エマージング・マーケット・インデックスに連動するインデックスファンドも登場したことだし……。

mymemcheckをCentOSで動かす

サーバ/インフラを支える技術』に載っていた mymemcheck を試してみようと思って CentOS 5 上で実行してみたところ、いくつかの Perl モジュールが足りなくて動かなかった。例によって rpmforge で検索してみたら、やはり見つかった。

sudo yum --enablerepo=rpmforge install perl-Readonly perl-UNIVERSAL-require

相変わらず便利過ぎるぜ rpmforge。

mod_dosdetector の使い方

サーバ/インフラを支える技術』で知ったDoS攻撃判定モジュール mod_dosdetector の使い方。mod_dosdetecotr のバージョンは 0.2、環境は Apache 2.2.3 @ CentOS 5。

改造版も公開しています。

インストール

wget http://ncu.dl.sourceforge.net/sourceforge/moddosdetector/mod_dosdetector-0.2.tar.gz
tar xvzf mod_dosdetector-0.2.tar.gz
cd mod_dosdetector-0.2
make
sudo make install

httpd.conf 設定例

# 実際にはこの一行は make install で追加される
LoadModule dosdetector_module modules/mod_dosdetector.so
 
DoSDetection     on
DoSPeriod        5
DoSThreshold     10
DoSHardThreshold 25
DoSBanPeriod     30
DoSTableSize     100
DoSIgnoreContentType  image|javascript|css

DoS判定の肝となる数値は DoSPeriod, DoSThreshold, DoSHardThreshold, DoSBanPeriod の4つで、上の例ではだいたい次のような意味になる:

  1. 同一IPアドレスから5秒間に10回以上のアクセスがあった場合「DoS攻撃の疑いあり」と見なし、その後30秒間のアクセスに対しては環境変数 SuspectDoS をセットする(値は”1″)
  2. さらに5秒間のアクセス回数が25回に達した場合、「激しいDoS攻撃の疑い」と見なし、環境変数 SuspectHardDoS もセットする(値は”1″)
  3. 初めに「DoS攻撃の疑いあり」と判定してから30秒が経過したら、次のアクセスでもう一度判定をやり直す。直近5秒のアクセスが10回を下回っていれば、疑いは晴れる

アクセス数の計測はファイルの種類・有無を問わずに行われるため、デフォルトではページ内の画像やCSSなども計測対象となってしまう。それらを除外したい場合は、DoSIgnoreContentType ディレクティブで除外したいファイルの MIME type を正規表現で指定しておく(ファイル名(URL)ではないので注意)。各種画像ファイル・JavaScript・CSSファイルを除外したい場合は上例のように設定しておけば良い。

ただし多くの環境では拡張子 ico に対する MIME type の指定は行われていないはずなので、そのままだと favicon.ico が text/plain 等と見なされて除外されない(.ico に限らず、未設定の場合は httpd.conf の DefaultType になる)。次のように AddType を追加しておけば image と判定される。

AddType  image/vnd.microsoft.icon  .ico

ちなみにこれがアイコンファイルの正式な MIME type である。

DoS攻撃に対する防御設定

mod_dosdetector が行うのはあくまでも攻撃の”検出”だけなので、防御する方法はまた別に設定する必要がある。多くの場合は mod_rewrite と併用することになるだろう。例えば「激しいDoS攻撃の疑い」なアクセスに対してステータスコード503 + 静的なHTMLを返す場合は次のように設定する(Apache 2.2 only)。

RewriteEngine On
RewriteCond %{ENV:SuspectHardDoS} =1
RewriteRule .*  - [R=503,L]
 
ErrorDocument 503 /server_is_busy.html

しかし現実には、攻撃の判定とその後の防御は、匙加減が難しい。どの程度のアクセスを攻撃と見なすかはサイトによって千差万別だろうし、あまりに頻繁・過剰な反応をしてしまうとユーザが離れてしまう。

そこで個人的には、まず厳し目の設定を行って、ログを取ってみることをおすすめする。「DoS攻撃の疑いあり」なアクセスを普通のログと分けて記録するには次のように設定する。

LogFormat "%{SuspectHardDoS}e %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" dos_suspect
CustomLog logs/dos_suspect_log dos_suspect env=SuspectDoS

ログの行頭に環境変数 SuspectHardDoS が記録されるため、どのような経過をたどって「疑いあり」から「激しい攻撃の疑い」へと移行したかも分かる。

後はこの記録を見つつ、通常のアクセスが引っかからないような適当な設定を探ることになる。もしサーバリソースの都合上、どうしても通常のアクセスが引っかてしまう可能性があるのなら、その時は防御方法をより穏当なものに設定することもできる(このあたりの柔軟性は mod_dosdetector の設計の妙だと思う)。

その他

上で触れなかったディレクティブについて少々:

DoSDetection
DoS判定機能の有効・無効を設定。on で有効
DoSTableSize
クライアントの追跡記録の最大保存数。この数値を大きくすればより多くのクライアントを同時に追跡できるが、メモリ使用量と負荷が上昇する
DoSShmemName
クライアントの追跡記録を保存しておくための共有メモリの名前。普通は設定する必要は無いはず

最後に

素晴らしいソフトウェアをオープンソースとして公開してくださった田中慎司さん(そして株式会社はてな)に感謝!

Apache 2.2ではmod_rewriteのRフラグで任意のステータスコードを返せる

昔Apache 2.0系で試したときは無理だったのに、2.2系ではできるようになっていたのか。

mod_rewriteで503 – Do You PHP はてな

上エントリーで引用されているドキュメントは古くて、現在は次のような記述に置き換わっている。

While this is typically used for redirects, any valid status code can be given here. If the status code is outside the redirect range (300-399), then the Substitution string is dropped and rewriting is stopped as if the L flag was used.

mod_rewrite – Apache HTTP Server

『このフラグは通常リダイレクトのために用いられるが、任意の妥当なステータスコードを指定することができる。もしリダイレクト以外のステータスコード(すなわち300〜399以外)が指定された場合、置換文字列は無視され、さらにLフラグが指定されたときと同じようにURLの書き換えが停止される。』

つまりリダイレクトもURLの書き換えも行われないので、デフォルトのエラー画面以外を表示するには ErrorDocument ディレクティブで指定しておく必要がある。

RewriteEngine On
RewriteCond %{some_condition} =1
RewriteRule .*  - [R=503]
 
ErrorDocument 503 /server_is_busy.html

ソースに付属している文書(CHANGES)によれば、この仕様に変わったのはバージョン2.1.1。Bugzillaで以下のような議論も見つけた。

In the <300, >=400 cases, one can think of this as [R{esponse}=nnn} as opposed to [R{edirect}], and it really harms nothing to overload it.

Bug 45478 – R flag in RewriteRule does not honor 400 and 500 range error code

Redirect の ‘R’ ではなく Response の ‘R’ と見なしてくれ、と。なるほど…。

BlockHosts の導入

ブルートフォースアタックからの防衛ツール BlockHosts 導入手順。環境は CentOS 4。

インストール

rpmで導入する場合

wget http://www.aczoom.com/tools/blockhosts/BlockHosts-2.4.0-1.noarch.rpm
sudo rpm -Uvh BlockHosts-2.4.0-1.noarch.rpm

もしくはソースからインストールする場合

wget http://www.aczoom.com/tools/blockhosts/BlockHosts-2.4.0.tar.gz
tar xvzf BlockHosts-2.4.0.tar.gz
cd BlockHosts-2.4.0
sudo python setup.py install

どちらの方法を使っても、設定ファイルは /etc/blockhosts.cfg にインストールされるし、ログローテーションのための設定ファイル /etc/logrotate.d/blockhosts もインストールされる。

/etc/blockhosts.cfg の設定

まずは最低限の設定を行う。CentOS ならほとんどの場合はデフォルトで良いと思うが、

HOSTS_BLOCKFILE = "/etc/hosts.allow"
WHITELIST = [ "127.0.0.1", "192\.168\.2\..*", ]
LOGFILES = [ "/var/log/secure", ]

このあたりは明示的に設定しておいた方が良いと思う。WHITELIST に追加する設定は自分の環境にあわせて。

/etc/hosts.allow に設定追加

こちらもまずは最低限の情報を書いて、動作確認をする。

#---- BlockHosts Additions
#---- BlockHosts Additions

この状態で以下のコマンドを実行し、正しく解析結果が表示されることを確認。

sudo blockhosts.py --verbose --dry-run

次に –dry-run オプションを外し、/etc/hosts.allow の書き換えが正しく行われることを確認する(BlockHosts Additions の間に情報が書き込まれる)。

sudo blockhosts.py --verbose

最後に /etc/hosts.allow の末尾に blockhosts.py の起動設定を追加する。以下は一例

sshd: ALL: spawn /usr/bin/blockhosts.py --verbose --echo "%c-%s" >> /var/log/blockhosts.log 2>&1 : allow

その後の設定

ほとんどの設定は /etc/blockhosts.cfg の中でも、blockhosts.py のコマンドラインオプションとしても(つまり /etc/hosts.allow の中でも)設定できる。詳しくは blockhosts.cfg の中のコメントや blockhosts.py –help を参照。

試していないが、「ipblock」の設定を行うことで、TCP/IP レベルでのブロックも行えるようだ。ip コマンドで無効なルートを設定するか、iptables でフィルタリングするか選べるらしい。blockhosts.cfg より:

#IPBLOCK = "" # (default)
#IPBLOCK = "ip route" # or use full path "/sbin/ip route"
#IPBLOCK = "iptables" # or use full path "/sbin/iptables"
# "ip route": Do TCP/IP blocking using route commands to setup null-routes.
#    ip route add  via 127.0.0.1
# "iptables": Do TCP/IP blocking, using iptables packet filtering.
#    iptables --append blockhosts --source  -j DROP