2006年7月24日

TeraStation TS-0.6TGL/R5 の改良(2) -- netatalk 2 を起動

リモートからログイン出来るようになったのでちょっと調べてみると、samba/netatalk のバージョンがちょっと古いのが分かった。

  • samba-2.2.8a-ja-1.1
  • netatalk-1.6.4

さて、netatalk から 2.x 系に上げて見る。

方針はシンプルで「debian sarge のバイナリをただコピーして動かすだけ」。

ファイル共有が目的なので afpd を動かすだけの物を選別してコピーする。

  • /usr/lib/libdb-4.2.so
  • /usr/lib/libslp.so.1.0.0
  • /usr/lib/netatalk/uams_guest.so
  • /usr/lib/netatalk/uams_pam.so
  • /usr/lib/netatalk/uams_passwd.so
  • /usr/sbin/afpd
  • /usr/sbin/cnid_dbd
  • /usr/sbin/cnid_metad
  • /usr/bin/cnid2_create
  • /usr/bin/cnid_index
  • /usr/bin/cnid_maint
をコピーする。

次に以下のシンボリックリンクを張る。

  • /etc/netatalk -> /etc/atalk
  • /usr/lib/libslp.so.1 -> /usr/lib/libslp.so.1.0.0

次に/etc/init.d/atalk内の無用なオプション(-k sjis)をコメントアウトして、atalk を再起動する。

個々まで、作業すると「afp://サーバIP」で接続出来る寸前間で行くが、エラーが発生してうまく行かない。/var/log/message には以下ログが残される。

Jul 23 17:17:37 TERA afpd[2251]: Warning: No CNID scheme for volume /mnt/array1/data. Using default.
Jul 23 17:17:37 TERA afpd[2251]: Setting uid/gid to 100/100
Jul 23 17:17:37 TERA afpd[2251]: cnid_open: Found version 1 of the CNID database. Please upgrade to version 2
Jul 23 17:17:37 TERA afpd[2251]: Cannot open CNID db at [/mnt/array1/data].
Jul 23 17:17:37 TERA afpd[2251]: Fatal error: cannot open CNID or invalid CNID backend for /mnt/array1/data: cdb

CNID database をバージョンアップしろと指示しているが、どうするんだ?

分からんがディレクトリ .AppleDB を削除してみたところ、上手く接続できるようになった。むむ。

netatalk 2.0.2 に入れ替えたことで、ファイル名のエンコードがUTF-8のNFCになり、かつファイル長の31文字制限は無くなった。使い勝手がかなり上がった。


[全文を読む]

TeraStation TS-0.6TGL/R5 の改良(1) -- sshd を起動

10年くらい前に比べるとMega単位のHDDの単価が異様に安くなった。そんな中、新型TeraStationはNAS で RAID 5 でHDD の交換も容易なので欲しい指数がMAXになってしまって、思わず を買ってしまった。

さっと使ってみた結果、Windows をメインにしてる分には何もいじることは無いと思う。ただ、MacOSXから使うと日本語のファイル名が使えないとか、ファイル名長が31文字に制限されていたりで、異様に使いにくい。

中身はLinuxらしく、いじり倒してる先人がいるので、 このサイト「TeraStation で遊ぼう」を参考に改造してみた。

参考サイトにある通り、シリアルコンソール化 [TS-TGL]を行うとローカルユーザのシェル権限は取得できる。ただ、/usr/local/bin 以下には、o+w の権限のシェルスクリプトは無い。同様な別のスクリプトを見つけて、/etc/sudoers は作成させて、adminユーザが sudo で root権限を取れるようには出来る。ここまで、出来れば改造し放題。むむ。

次に、何故か持て余していたMac-mini(G4)に、Debian sarge/ppc をインストールしてMacOSXとデュアルブート出来るように作業。玄箱があるので debian sarge化したもので良かったかも。

Debian sarge の sshd のバイナリをコピーして手動でkeyを作成して立ち上げると、ライブラリの過不足もなくすんなり動く、、、あっけない。あとは、再起動しても立ち上がる用に /etc/rc.d/rc3.d 以下に適当にリンクを作ってお終い。

中身のLinux は monta vista が使われているが、debian sarge とは相性が良さそうである。


[全文を読む]

2006年7月22日

IMAPで見知らぬフォルダが現れた?!

debian sarge から debian etch へ移行したら、見知らぬIMAPのフォルダが現れるようになった。

customflags
subscriptions

暫く放置してとけば勝手に消えるかと思ったが、一向に消えない。 よく調べてみると dovecot が利用している特殊なフォルダだったらしく。 0.99(sarge) から1.00(etch) へ更新時に上記のフォルダの名称が変更され、別のフォルダを使うようなり、その残骸がIMAPフォルダが現れたようである。

フォルダを削除したところ、見知らぬIMAPフォルダは現れないようになった。

# cd ~/Maildir
# rm -rf .customflags .subscriptions

ふむ。


[全文を読む]

2006年7月7日

Dothan で EIST を有効に?

i915GMm-HFSとDothan(770)の組み合わせでEISTが出来るので購入したのだが、何故か Linux のカーネルモジュール cpufreq-centrino がロードできなかった。なので、BIOSの設定画面で、ratio と、CPUの電圧設定をチマチマ変更していた。そして悲劇が起きた!

BIOSのCPUの電圧設定は特に制約無く 0.7 Vくらいまで下げられる。発熱を押さえる目的でCPUの電圧設定を異様に小さな値を設定して運用していたら、多分プチ暴走かメモリの一部が飛んだかの問題が発生し、運悪くapt で更新作業の最中でファイルシステムが壮大に壊れてしまった。

データ系のファイルは別ボリュームで運用していたので幸いして欠損することは無かった。 何とか、ファイルシステムをXFSからext3に変更して復旧させることができた。

大本の原因が分かったところで、何故 EIST が有効にならないのか調べてみると、 Intel のEISTの解説というのがあり、EISTに対応するにはCPU以外にも、Chipset/Motherboard/BIOSにもEIST対応が求められる。EISTの有効化は結構大げさな奴だったのかぁ。。。

BIOSが含まれるというので、確認すると現状は1.04だがAopenサイトには1.11まで公開されている。なので、BIOSを1.04から1.11にアップデートすると、カーネルモジュール cpufreq-centrino が無事ロードできるようになった。多分、BIOSに周波数と電圧とかの対応表とか、周波数の変更方法とかがちゃんと乗るようになったのかなぁ。

governorをondemand に指定したところ、負荷が低いときは、勝手に周波数と電圧が下がって、同時にCPU温度が約48℃くらいに落ち着いた。openssl speedとかでCPUの演算をブンブン回して負荷を上げると、周波数と電圧がMAXまで上がり、CPU温度が約95℃くらいに上昇した。。。EISTが有効になっていますねぇ。

追記

ちょっとだけ cpufreqd を使って Dothan の発熱を抑える


[全文を読む]

2006年7月4日

ext3 で htree 機能は安全につかえるのか?

ext2/ext3 でディレクトリ構造を線型検索からhtreeを使った検索で高速化する機能がある。dumpe2fsでの出力で機能リストに、dir_index が列挙されていれば有効になっている。

Debian etch のインストーラ経由で ext3 を作成したものには htree 機能が有効になっており、ちょっとびっくりしたのだが、これはいつ安全に使えるようになったのか疑問が湧いてきた。

e2fsprogs のリーリースノートから拾い読みすると htree機能(dir_index)の変遷は下記のようである。

  1. バージョン1.28から取り込まれ始める
  2. バージョン1.29でmke2fsのデフォルトでdir_index有効になる
  3. バージョン1.30でe2fsckでendianと内部 htree node を誤認識によるそれぞれに起因する問題の修正と HTREEに関しての追加チェックが出来るようになる。
  4. バージョン1.33でヤッパリmke2fsのデフォルトでdir_index無効になる。
  5. バージョン1.39で再度mke2fsのデフォルトでdir_index有効になる。但し、 /etc/mke2fs.conf で指定できるようになる。

sarge/etch のそれぞれのe2fsprogsのバージョンが1.37/1.39なので、htree機能の無効・有効に説明が付きそうである。多分リリースノートからすると、1.30 でのe2fsckの修正でほぼユーザランド側は大きな不具合が取れて、1.39 が出る約3年ぐらいの修正で安定度と実績が出来たので再度デフォルト有効になったのかなぁ。とするとhtree機能は安全に使えるようである。

htree 機能の不具合の話はVine 2.6r3 の不具合が大本だった。メーリングリストの報告(1,2)を見る限り対処療法で乗り切っているようで、何が原因だった分からない。取り敢えずdir_indexは無効にしようとなっている。Vineではいまはどういう扱いになっているのだろう?

Fedora Core 5 や CentOS 4.2 では ext3 のhtree機能は既に有効になっているらしく、 そんなに気にせず使えるようである。

あまり気にせずと言うことか。


[全文を読む]

XFSのファイルシステムが壊れた!

XFSを使っていたルートファイルシステムが壊れた。 lsとかの普通のコマンド叩いても、 エラーがでてきて状況がわからないので、再起動しても状況も変わらない。 よく調べるとオプションをしていしないと XFS でエラーが検出されると勝手にアンマウントされるので、普通のコマンドも起動できない状況だったらしい。

ともあれファイルシステムがちょっと壊れていて、xfs_repair とかするとlost+foundに1万ファイルくらいが修復された。結構重要なファイルが含まれているらしく、正しく運用も出来ない。

以前にも何度がXFS がちょっだけ壊れた時があって、そのときはファイル自体正しいそうなサイズであるのだけど、中身が全部0だったりとか、全く良い思い出が全くない。

性能が良いと前評判だったので resierfs/JFS/XFSなどを好んで使っていたのだが、ext3 の改良もどんどん進んでいる(ext3 諸元拡大に関する研究開発動向、及び改造方式の検討)。なので、これを期に ext3 に移行することに。

あれ?ふと気づくとdebian etch で ext3 の dir_index が普通に有効になっている!? こいつはディレクトリのエントリを線型検索からハッシュ B ツリーを使い高速化する機能で、他のファイルシステムを使う大きな理由が一つ無くなるので結構注目していたのだが、こいつを有効にしているとfsckがファイルシステムを壊していく不具合が出てデフォルトで無効化されて、結構悔しかった記憶、、、いつ直ったのだ。


[全文を読む]