2007-03-21

Bloggerの投稿記事ページだけを検索サイトに(その2)

以前の記事で書いたように、Bloggerの通常記事だけが検索エンジン(特にgoogle)で検索されるよう、metaタグで制御しようとしたが、その顛末。

1月22日
"item"以外の全ページでrobotsを"NOINDEX"とする。
2月6日まで
"index", "archive"のページは順調にgoogleから消えるが、1月15日以降の通常記事が一向にインデックスされない。1月22日の記事だけインデックスされたが外部にリンクがあるためっぽい。
2月6日
FOLLOWを明示する必要があるせいかと考え、"NOINDEX,FOLLOW"に変更する。
2月8日
1月30日の記事がインデックスされたがこれもトラックバックによる外部リンクがあるためっぽい。
2月11日
あきらめて一旦robots記述を削除。
2月21日まで
"index", "archive"のページがほぼ順調に復活。異なるURLでほぼ同じ内容のページは一方しかインデックスされないことに気付く(例えばあるラベルの記事が1個しかない場合)。
2月21日
robots記述に"noindex,follow"を再度加えるが、ルートページはインデックスされるように修正しておく。ついでに全部小文字に。
3月5日まで
"index"のうちラベルのページ、"archive"のページがインデックスからほぼ消える。
これまで
通常記事のページはほぼ単調に増加。

というわけで、おそらく"follow"は意味なさそうで、ルートページに"noindex"はよろしくなさそう。

ちなみに、現在のrobots部分は、
<b:if cond='data:blog.pageType != "item"'><b:if cond='data:blog.url != data:blog.homepageUrl'><meta content='noindex,follow' name='robots'/></b:if></b:if>
としている。
&&の条件をどう書けばいいか調べてないので、b:ifを単に2重にしてあるのが不恰好。

2007-03-15

パーティション暗号化機構gbdeとgeliの比較

moodleサーバの個人情報保護用にファイルシステムの暗号化を導入する目的で、性能比較を行った。

gbdeの基本的な使い方

まず、5.xまででも実装されているgbdeについては、次のようにすると利用することができる。ここでは、SATAの320GBハードディスク/dev/ad12をまるまる使うことを前提に作業。

ロックファイル用の場所を用意しておき、次のコマンドでロックファイルとデバイス内のロックセクタの作成。ロックセクタというのは暗号化したマスターキーを分散配置したもので、その位置情報を暗号化したものがロックファイル(gbde(4)を読んだ理解が正しければ)。

# gbde init ad12 -i -L /etc/gbde/ad12
手動でやるだけならgeom_bde.koを明示的にロードする必要はない。-iでパラメータをファイルではなくインタラクティブに(というかエディタでいじって)与える。sector_sizeの初期値は512になっているが、これをフラグメントサイズ(通常は2048)にする方が性能劣化が多少まし。エディタを終了すると、パスフレーズを聞かれるので与える。3文字未満は不可らしい。

次に暗号化パーティションをデバイスとして認識させるためにアタッチ。
# gbde attach ad12 -l /etc/gbde/ad12
パスフレーズを聞かれるので、作成したロックファイルのパスフレーズを入力。間違えても文句を言わずに成功してしまうので注意。正しければ、/dev/ad12.bdeができる。もう一回アタッチしようとすると、今度は文句を言われる。あとは、/dev/ad12.bdeをnewfsしたり、mountしたり、やりたいほうだい。再起動したらattachをやりなおす必要がある。用が済んで、デタッチすれば、パスフレーズを知っている人しか使えない。
# gbde detach ad12
ちなみに、このad12.bdeをさらにgbdeでinit, attachすると、/dev/ad12.bde.bdeとかができあがり、2重に暗号化することもできる(が、たぶん遅くなる以上の意味はない)。setkeyを使えばパスフレーズを変更してロックファイルとロックセクタの暗号化をやり直せる。

パスフレーズを知らない、あるいはロックファイルがない状態では、ディスクを解読するのは不可能に近いが、絶対に安全なわけではない。destroyはパスフレーズを有効に保ったままマスターキーを塗り潰してしまう。nukeはマスターキーを破壊するっぽい(あやふや)。

geliの基本的な使い方

次に6.xから使えるようになったgeli。まず、乱数の鍵ファイルを作成する。
# dd if=/dev/random of=/etc/geli/ad12.key bs=64 count=1 
そして、パスフレーズを設定してパーティション内を初期化。1文字でも受け付ける。
# geli init -s 4096 -K /etc/geli/ad12.key ad12
アタッチ。
# geli attach -k /etc/geli/ad12.key ad12
パスフレーズを入力するが、間違えればエラーで教えてくれる。アタッチした時点でgeom_eli.koその他が自動的にロードされる。あとは、newfs, mountすればよい。デタッチはgbdeと同様。

比較

まず、必要な領域のオーバヘッドが違う。gbdeでは領域全体の0.8%ほどが消費されてしまうが、geliでは2KBしか消費しない。
Filesystem        1K-blocks Used     Avail Capacity  Mounted on
/dev/ad12 302732078 4 278513508 0% /mnt
/dev/ad12.bde 300385910 4 276355034 0% /mnt
/dev/ad12.bde.bde 298058518 4 274213834 0% /mnt
/dev/ad12.eli 302732076 4 278513506 0% /mnt
次に速度。暗号化なし、gbdeで2048バイトセクタ、512バイトセクタ、geliで4096バイトセクタ、2048バイトセクタのそれぞれの場合について、soft updatesなしとありで、bonnie++-1.93.03_1(bonnie++ -s 1024 -n 128 -x 3)で測定した。下の表がその結果。%CPUが99とかにはりついてI/O性能と実質無関係な列(read系やputc/getc系)は除外。Latencyも特にsoft updatesありで変動が大きいので除外。


Sequential OutputRandom
Seeks
Sequential CreateRandom Create
BlockRewriteCreateDeleteCreateDelete
K/secK/sec/sec/sec/sec/sec/sec
normal69588584923902202244581960491
64861573443938196143641987582
64223573533939198843901980563
normal
/soft
7027957874408026168530442284057746
6408457227408126206535072303157089
6422957951404226269532612273257586
bde2048183882473312335371213544265
207622643111605391227542290
202082542011185361226544256
bde2048
/soft
198232561811741253646733814652938
176262572710761428741221921452761
159812231310591502543788952151912
bde512192341741312964211133452148
190081746412964471156448145
190991702013004541167451141
bde512
/soft
190941696011861149945933826852772
1864717138117812016463051000853334
188721738411851204145969985753266
eli4096636715680238297531582760353
626385783638287531581760497
622215760537707541573759521
eli4096
/soft
6689958708372820798534621812656330
5980157577368321123534211853057748
5906957151365221010515031791857765
eli2048652285682340607501580749576
641135872441827521567755590
618955782940637561578753572
eli2048
/soft
6640658087403621286523581826757784
5837357774409021119524871788457678
5913557429407121257535611759257969

これを見ると、gbdeでは暗号化なしに比べてスループットが3分の1以下に低下し、2048と512にも有意な差があることがわかる。これに対して、geliではcreateやdeleteで差が出るものの、writeは遜色ない速度。4096と2048にも有意な差はない。

というわけで、gbdeは忘れることにする。ただし、geliの方はgbde(4)のようなドキュメントが用意されていないので、メカニズムがよくわからないのは一つの問題。

2007-03-05

N Wikiを使うにはテーマ設定が必須

NWikiはmoodle 1.7.1+でとりあえず動いていそうだったが、Wikiとして実際に使おうとしてみると、重大な問題があった。編集ボタンがなく、インデックスや更新記録や検索のためのブロックを表示できなくなってしまっていた。古いサイトを復活させないと、1.7の問題かNWikiの問題かが切り分けができない状態になってしまったので、面倒さを天秤にかけて、直接ソースにあたった。

その結果、$CFG->showblocksonmodpagesという変数が設定されないと、それらのブロックがまったく表示されない状態になってしまうことがわかった。DFWiki 1.0にはこのようなコードはなかったので、最近のDFWikiあるいはNWikiの問題。しかし、この変数の設定箇所であるadmin/settings/appearance.phpをどうやって実行すればいいかを探すのに手間取る。

結局、サイト管理->外観->テーマ->テーマ設定がそれであることが判明し、解決。

しかし、Wikiの重要な機能がこんなところで他のモジュールとひとくくりで設定されていいものだろうか。

2007-03-02

moodleの1.8へのアップグレードはドキュメント重要

とりあえずmoodleのテストサイトで1.7.1+にしてみて問題がなかったので、プロダクションサイトもアップグレードした。カスタマイズはまだ何も入れていないが、そのうちに。

で、1.8を試してみようと、再びテストサイトを作って、普段どおりまず管理者権限でログインしようとしたら、アカウントが無効と言われはまる。ゲストもログインできないし自分のアカウントでもログインできない。これまでの経験で管理者でログインしたらデータベースの更新が行われるものと思っていたので、それができないのは1.8のバグでは。

と思ったが、全然ちがってた。Installation problemsのフォーラムでMoodle 1.8というディスカッションがあり、そこではwww.yoursite.edu/adminに直接アクセスしろとアドバイスされていた。その通りにやったところ、データベースの更新が始まって1.8への移行ができた。実はMoodle DocsのUpgradingには、ちゃんと書いてあった。

The last step is to trigger the upgrade processes within Moodle.
To do this just visit the admin page of your installation e.g. http://example.com/moodle/admin
ドキュメントはよく読みましょう。

外見上の違いは特になし。ただ、ベータなりの不具合がちらほら。トップページに出る各コースの説明文の位置がずれている。IEで横幅が狭いときにログインページ右半分の説明文の位置がずれている。HTMLエディタにならず変なjavascriptの一部が表示されてしまう。

NWikiモジュールは1.7用をそのまま入れてみたが、タブの表示が一部おかしくなる以外はとりあえず動いてそう。編集はまだ試していないが。

ともかく、1.8でぜひ使いたい機能は、ユーザプロフィールのフィールドを独自に定義できることである。半月以内くらいに安定してくれたら、一気に1.8に行ってしまうのだが。