アプリが利用している Rails を最新版にする

あるアプリを書いてる間に使っている Railsのバージョンが上がってしまった。

この場合は、config/environment.rb 内の RAILS_GEM_VERSION変数を使いたいバージョンにしてから、

rake rails:update

だそうだ(参照HowtoUpgrade)。 後は、テストを走らせるだけ、、、ふむ。

HDDの不良クラスタを対処する

半年前から不良クラスタが発生したHDDが手元にある。捨てる前に、正常に読める部分は消去して捨てようと思ったが、まだ消去できていない。

それは堪え性が無いからだ。

やることは簡単で

# badblock -v -w -o badblock_list.txt /dev/sdb

で済む。

これは不良クラスタを内容を破壊的に検査するコマンドなので、これを問題なく実行できれば、内容を消去できる。

だが、ちょっと不良クラスタの量が多すぎると、、、カーネルが固まったり、デバイスが勝手に取り外されたりする。

大抵のシステムではDisk にエラーが発生すると数回リトライして諦めるようである(本当か？)。無駄なリトライが原因で不良クラスタ部分の検査には時間がかかる。それ以外にも不幸なことが起きるらしい。

不良クラスタの位置を調べるにも相当難儀なことだ。また、ディスクのファームによって代替クラスタが割り当てられて不良クラスタでなくなる場合もちらほら出て検査に再現性が無い場合もある。

多量の不良クラスタが発生した場合はHDDを物理的に破壊することが一番簡単なんだろうなぁ。

取り敢えずは badblock_list.txt ぐらいは取っておきたい。でもこのHDDの容量は300Gだし、、、はれほれひれはれ。

RWiki 2.1.1 をインストールしてみる

ときどき Ruby のレファレンスマニュアルを配布・公開されてるサイトが落ちることがあり、ちょっと不便を噛み締めていた。

ただ最新のRD形式のソースが tarball で配布されているので、こいつと RWiki を何とかすれば、ローカルでビューすることが出来るのでちょっとやってみた。

RWiki 2.1.1 の立ち上げは相当めんどくさい。

dRubyベースのアプリサーバ rwiki.rb がバックエンドに必要らしいのに気付くまで小一時間かかった。それ以前に、公式サイトの情報が異様に発散していてサイトの袋小路に小二時間ほど迷ってしまった。

次に、RWikiが Ruby-GetText-Package を利用しているのだが、debian etch に含まれる 1.7.0 と gem から取れる 1.9.0 とは相性が悪いのか全く動かない。これにも気付くのに、小三時間かかった。

で、手順は以下の通り。

依存パッケージをインストール

debian etch で不足分のパッケージをインストール

apt-get install rdtool

もっと必要かも、、

rwiki の取得

RAAのrwiki から最新版のリンクを辿ってソースを取得し、 展開する。

tar xfz rwiki-2.1.1.tar.gz -C $(rwiki-src-parent-dir)

ドキュメント読む

rd/install.rd を熟読する、、、小四時間。

rwiki をインストール

適当なディレクトリを指定してインストールスクリプトを走らせる。

 install.rb -d $(rwiki-lib-top)

でも、rwiki.rb 等々はまだ展開したソースにあるので、展開したソース群は削除しない、、、何故なのかは聞かない約束なのかなぁ。

rwiki の設定をして立ち上げる

cd $(rwiki-src)/site
vi rw-config.rb    # 取り敢えず設定をする
                   # $(rwiki-lib-top) がロードパスに含まれるように細工する。
ruby -Ke -dv rwiki.rb

で、Exceptionのメッセージ がだらだら出力されて、静かになったら良いらしい。

もしRuby-GetText-Package をインストールしているならば、$(rwiki-lib-top)/rwiki/gettext.rb をちょっと細工する

インタフェースを設置

取り敢えずCGI動くところに、inteface/rw-cgi.rb をリネームしたりして置けばよい。面倒ならば、inteface/rw-webrick.rb を起動して、http://hostname:1818 をアクセスすれば良い。

ruby interface/rw-webrick.rb

こんな感じ、でもCGIの方が良いかも。

マニュアルを設置

tar xfz man-rd-ja.tar.gz
cp man-rd-ja/*.rd $(rwiki-src-top)/rd

で、rwiki.rb を再起動すると、キャッシュ作ってるとかのメッセージがだらだら出力されて、静かになったら良いらしい。 ただし、どのページから読めるかは不明なので、小五時間くらい、クリック猿になるとトップページが分かるので、大事にブックマークする。

想像を絶する難物だなぁ。みんな使っているのかぁ

QWERTY配列ってなに？

Linux のインストールの最中に、キーボード配列を指定する場面がある。よく考えもせずにおまじない的に QWERTY とか指定したのだが、イマイチすっきりしなかった。調べたところ、左上のアルファベットの並びがその由来らしい。

ヨーロッパの製品でTの横がZになっている製品とかあったりする。

他にも色々あって、

• QWERTY – 英語圏、日本語
• Dvorak – 英語圏のもう一つの勢力
• QWERTZ – ドイツ語圏、チェコ語圏
• AZERTY – フランス語圏

など。Qwerty以外の配列は見たこと無いので、新鮮だ。

あと、101キーボードとかの種類もあるが、大雑把に言えば

• 101 – 英語のキーボード
• 106 – 日本語のキーボード(日本語特有の変換キー)
• 109 – 日本語+ゲーツキーあり

かなぁ。

P_BLOG から Typo への移行

最近 Rails を使った Blog システムを自作しようと試みていたのだが、車輪の再発明をしてる気がしてならないので、同様なシステムが無いか調べてみた。

typo がよさげである。

編集途中のプレビューが横にリアルタイムに表示されて、記事の見栄えを確認するために思考を中断しなくても済むのがグッとである。それ以外はあまり癖のないシステムである。

こいつを使うための問題は、P_BLOGで書きためた記事をTypoに移行させる方法である。

コピペとかは勘弁して欲しいので、頭を絞ってみた。

Typo のトップページに、Desktop Clients というページへのリンクがある。こいつを眺めると、どうも最近のBlog事情は、Webインタフェースだけなく、ネーティブな投稿専用アプリがあるらしい。その中心にあるのが、XMLRPC上に定義された BloggerAPI / metaWeblog / MovableTypeAPI / Atom API とかいうプロトコールらしい。

専用アプリは高機能のものもあり、markdown/textileとかのシンプルなフォーマットを、平易に作成出来たりする、、、昔のNifty サーブとかではやった高機能クライアントみたいなものかぁ、、、歴史は巡るのか

すっかり、波に乗り遅れているなぁ〜〜。

プロトコールさえ実装されれば、特定のプログラム言語に依らずに操作できるので、Ruby でちょっとしたスクリプトを書いて、XMLRPC経由での移行をチャレンジしてみた。

1. P_BLOG に XMLRPCモジュールをインストールする。
2. Typo 4.0.3 をインストールする。
3. Typo 4.0.3 に含まれている actionpack ではちょっとこけるので修正する(current では修正されている)
4. 移行プログラムtransition_from_p_blog.rbを走らせる。

これでおしまい、、、XMLRPCを話せると良いことあるなぁ！

ssh アクセスの制限する

専用サーバを借りている当初からパラパラと brute force attack を受けていたので、気になっていたので対策を立ててみた。

iptables を使う場合、ipt_recent/ipt_hashlimitの２種類の方法があるらしい(他にもあるかも)。 ipt_recentは CentOS 4 のカーネルに標準に入っているので、こいつを使ってみる。

ただ巷では、ipt_recent はバグ#415(1,2)があったらしく、その不具合の修正が 2.6.18 取り込まれたそうである。 ただ、CAN-2005-2872,CAN-2005-2873 という名前が付いている結構深刻そうな不具合らしいので、現在のサーバ環境にも当てはまるか注意する必要がありそうだ。

で、CentOS 4は 2.6.9 のままでパッチがやたら当たっているので、問題ないのかなぁ？ RHELの changelog を見る限り #167703(CAN-2005-2872)/#189127 の fix としてkernel-2.6.9-42.ELまでに修正は入っているようだ。で、CAN-2005-2873 はどうかと言えば、パッチを見る限りどうも一緒に対応したようである。取り敢えず、yum update で最新版にしていれば安心なようである。

でもって、SSH接続を６０秒に５回以上行うホストは10分間拒絶する感じにすると下記のようになる。 あまりにもしつこいホストはdenyhost とに登録しおく感じ。

iptables -N attacked
iptables -A attacked -m recent --name evilhost --set \
         -j LOG --log-level INFO --log-prefix "brute force attack: "
iptables -A attacked -j REJECT
 
iptables -N check_ssh
iptables -A check_ssh -m recent --name tcpssh --set
iptables -A check_ssh -m recent --name tcpssh --rcheck \
         --seconds 60 --hitcount 5 -j attacked
 
iptables -N safehost
iptables -A safehost -s 127.0.0.1 -j ACCEPT
 
iptables -N safeonly
iptables -A safeonly -j safehost
iptables -A safeonly -j REJECT
 
iptables -N denyhost
iptables -A denyhost -s xx.xx.xx.xx -j REJECT
 
iptables -A INPUT -j safehost
iptables -A INPUT -j denyhost
iptables -A INPUT -m recent --name evilhost --rcheck \
         --seconds 600 -j REJECT
iptables -A INPUT -p tcp --syn --dport 22 -j check_ssh
iptables -A INPUT -p tcp --dport xxx -j safeonly

余計なサービスを一切立ち上げていないので、いいのかなぁ。 何か頑張ってない感じが出ているなぁ〜。

さて、evilhostなのど名前を付けたリストには何個のIPアドレスを覚えており、登録したIPアドレスのタイムスタンプ履歴はいくつまで覚えているのでしょうか？

無限？、、、まさか

モジュールの引数に最大値を引き渡せて、デフォルトでは履歴は20個、リストあたり100 IPアドレスまで記録できるそうなぁ。リストがあふれた場合は、古い履歴を持つリストから削除されると思う(ipt_recent.cのソースはちょっと分かりづらいので詰めていないけど)

単一テーブル継承

あるテーブルで、複数の用途で使うがカラムがほとんど同じモデルがたまにある。 整数型のカラム名 namespace で、用途分けをしたりする。 ActiveRecord には、こんな用途のために単一テーブル継承が使われるらしい。 特定モデルのテーブル定義にカラム名に `type`を含め。そいつから派生したモデルの名前が、このカラムに勝手に入るようになる。

使ってみたが、お気楽で使えたええなぁ。

belongs_to の引数 :polymorphic も見ると、方向性がそっちなのかと思いつつ。。。ええかなぁ

ActiveRecord は効率が良いのか？

ActiveRecord を使い始めて、山にぶち当たってしまった。

こいつには特定のカラムの値を更新する update_attribute とかいうメソッドがある。こいつが作るSQL文が、全部のカラムを更新するようにダラダラ長くなる。それ以外でも、関連とか使うと特定のカラムのみ変更する場面があるのだが、ここでも全部のカラムを更新するようにダラダラ長いSQL文を作ってくれる。

例えば、掲示板の発言と非公開フラグを一つのテーブルに作り、管理者が発言を制御しようとロジックを組んだとしよう。管理者が、公開・非公開を変更するたびに、非公開フラグと発言内容が更新されるSQL文が発行される訳だ。。。重い。

とにかく、こいつが作る update 文をちょーーーーダサイ。

こいつはテーブルの設計に織り込まないと行けないのか、、、あふぅ。

OpenDirectory を使ってみる

一応、MacOSX Server 10.4 とかを入手していたので、今更ながら OpenDirectoryで認証サーバの統合をやってみた。

結構癖があったが、RedHat 7.2〜9/Fedora Core 1〜6, Solaris 9/10, Windows を配下に置くことが出来た。

そのうちメモをまとめておこう。

Rails を覚えると Wiki が作りたくなるらしい

Rails が覚えると習作として、Wiki や Blog のアプリを作りたがるらしい。が、できあがったアプリで運用しているところを探すと結構少ないことに気付く。

何でだろう？

車輪の再発明になるからやらないとか、セキュリティを気にかけないと行かないとか、サーバ用意するのが面倒とか、、、。

既存のサービスを使った方が、内容に注力できるからなんだろうなぁ〜。