おうちでサーバ（その14: libc6-2.3.2 @ gcc-3.4.1）

libc6 再び

glibc-2.3.2ds1 を gcc-3.4.1 で build することによって，make 時の Segfault が回避可能か試してみよう計画．やっと libc6-2.3.2 が完成したのでインストール．

結果：やっぱりだめでした．

とりあえず，今回は strace があるので結果を貼ってみる．以下は strace debian/rules binary と打ってみた結果．

（略）
open("debian/rules", O_RDONLY|O_LARGEFILE) = 3
fstat64(3, {st_mode=S_IFREG|0755, st_size=3298, ...}) = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x2956b000
read(3, "#!/usr/bin/make -f\n\nDEB_BUILDDIR"..., 4096) = 3298
pipe([4, 5])                            = 4
 --- SIGSEGV (Segmentation fault) @ 0 (0) ---
 +++ killed by SIGSEGV +++
landisk# 

なるほど．pipe で死んでいる…んじゃないな．これは生還している．うーん，やっぱりgdbで追っかけてみないとだめかな．

…その前に gcc-3.4 -O1 とかで日和ってみる手もあるか？

おうちでサーバ（その13: gdb-6.1について）

gdb-6.1 おぼえがき補逸

以下はgdb/configureの10532行目からの引用．

host_makefile_frag=${srcdir}/config/${gdb_host_cpu}/${gdb_host}.mh
if test ! -f ${host_makefile_frag}; then
  # When building a native debuger the .mh file containing things
  # like NATDEPFILES is needed.  Cross debuggers don't need .mh
  # since it no longer contains anything useful.
  if test "${target}" = "${host}"; then
      { echo "configure: error: "*** Gdb does not support native target ${host}"" 1>&2; exit 1; }
  else
      host_makefile_frag=/dev/null
  fi
fi

ここで${srcdir}=gdb，${gdb_host_cpu}=sh4, ${gdb_host}=linuxということになっているらしい．したがって，ここの判定に成功するためには， gdb/config/sh4/linux.mhというファイルが存在しなければならない．

想像したとおり，gdb/config/shというディレクトリはあるが，gdb/config/sh4というディレクトリはない． まあ，これはlinkを張ってやればいいだけ．

問題は，

landisk# ls gdb/config/sh
embed.mt  nbsd.mh  nm-nbsd.h   tm-nbsd.h  tm-wince.h
linux.mt  nbsd.mt  tm-linux.h  tm-sh.h    wince.mt

…*.mhがnbsd.mhしかない．

ただ，この中身を見ると，

landisk# cat gdb/config/sh/nbsd.mh
# Host: SuperH running NetBSD
NAT_CLIBS=
NATDEPFILES= infptrace.o inftarg.o fork-child.o shnbsd-nat.o
NAT_FILE= nm-nbsd.h

というだけなので，gdbとsh4の両方についてちゃんと知っていればshnbsd-nat.c相当品（のlinux版） をでっちあげるだけでいけるばず．

…と，ここまで書いてふと思い立って「sh-linux-nat.c（mips-linux-nat.cからの類推）」 でぐぐってみたら，やっぱり誰か書いたことがあって存在するらしい．それなのになぜgdb-6.1に含まれないんだろうと思っていたら，

... See the -nat file associated with your target. In this case it's sh-linux-nat.c, if I remember right - which isn't in the FSF GDB sources (was never contributed :().

[Daniel Jacobowitz, 2004]

…そういうことだったのか．oTZ

おうちでサーバ（その12: gobjc-3.4）

gobjc-3.4

もともとgdb-6.1のbuildのために夜なべしかけていたgobjc-3.4を， やりかけのままほっとくのもしのびないので夜なべの続きをしてみた．…もう意味無いけど．

先日のffitarget.hの問題のほかは，特に何も無くbuild完了．ただ，そのままだとlibobjcを作ってくれず， gobjcがインストールできないのでwith_libobjc := yesとdebian/rules.defsのてきとーなところに書いて，再度debian/rules binary．完成．

glibc-2.3.2の野望再び

とりあえずgcc-3.4で試してみることにするか．だめもとで．

hddtemp

夜なべしすぎて51度とかいう数字になっていた．熱すぎて触り続けることができない．酷使しすぎ？

おうちでサーバ（その11: libc6失敗とgdb-6.1）（原題：「いろいろ」）

しまった

作れていたつもりになっていた libc6-2.3.2 だが，これを使うと make が Segfault を吐くようになってしまった．ためしに BSD pmake を apt-get して試してみたが同じ．ううう，戻すの面倒くさい…．

さらにどつぼへの道

とりあえず，make tests をやり直してみる．それと，gdb がないとデバッグの効率が…と， ここまで手を出すのもどうかと思うが，とりあえず用意だけしておこう．う．gobjc に depend するのか．

…どこまでいくものやら．

gdb-6.1 おぼえがき

gobjc は上記の某所の管理人さんが夜なべされたものをご好意に甘えて使わせていただくことにした． というわけでgdb-6.1のbuildに挑戦．

なぜか gcc-3.3.4 だと，

cc -c -DHAVE_CONFIG_H -g -Wall -O2 -I. -I/root/gdb-6.1/libiberty/../include  -W -Wall -Wtraditional -pedantic
 /root/gdb-6.1/libiberty/strsignal.c -o strsignal.o
In file included from /usr/include/signal.h:358,
               from /root/gdb-6.1/libiberty/strsignal.c:23:
/usr/include/bits/sigthread.h:36: error: storage class specified for parameter `type name'

という謎のエラーが出る．私にはこのエラーが何を言っているのかわからない．当該箇所を見てみてもよくわからない．

…ためしに gcc-3.4.1 にしてみたら通った．oTZ

gdb-6.1 結果

あとは明日にしようと思ったら，*** Gdb does not support native target sh4-unknown-linux-gnu とか言ってきた．configure の該当箇所を見つけて，どうせ sh から sh4 へのリンクを張ればいいだろうとたかをくくっていた．

たしかにそれはそれで予想通りだったのだが，

…GDB-6.1 って NetBSD でしか native でデバッグできないんでつか？ oTZ

もう寝よう．

おうちでサーバ（その10: libc6 (glibc-2.3.2)）

libc6 苦戦中

案の定というべきか．とりあえず現状報告．

• linux-kernel-headers を build-dep しているが，linux-kernel-headers が新しい libc6-dev に依存している．→ -d で無視．困ってから困ることにする．
• なぜか（せっかく夜なべした）gcc-3.4.1 を使ってくれない．強制的に gcc-3.3 を使われてしまう．→ gcc-3.3 が（無理矢理作った割りに）安定していそうだったので放置．原因も追究していない．
• build-tree/sh4-libc/dlfcn/libdl.so.2 を作れない (no rule to make 状態) ため，build-tree/sh4-libc/elf/sprof が作れないと言われた．→ 調査中．→ libdl.so -> libdl.so.2 のリンクができてないだけだった（なぜ？）

ただ，LANDISKで漕ぎいでな♪の管理人さん （いつも貴重なコメントいただきありがとうございます）によると，なかなか道は険しいらしい（上記サイトの情報交換BBS参照）．

とりあえず休憩．

できてしまった

実は glibc の make は初めてで，なかなか Makefile の構造を理解できずに苦しんだが， どうやら上記のリンク生成のためのターゲットが build-tree/glibc-2.3.2/Makerulesに入っていないのが原因だったようだ．たぶん．

例のごとく手でリンクを作成し，debian/rules binary で再開した．ごはんを食べた．Athlon64に gentoo on coLinux を乗せていくつか emerge して遊んでみた．LANDISK とのあまりのコンパイル性能の違いに愕然とした．頭ではわかってはいたけど．そうだよなぁ，夜なべでコンパイルなんて時代じゃないよなぁ． でもこっちのほうが牧歌的でなんとなくいいかも．そういえば「コンパイル待ちでほげほげ（ほげほげは任意）」 という経験も最近は無い気がする．

…とかやっているうちにできてしまった．ある意味で拍子抜けというか怖いというか．

libc6_2.3.2.ds1-13_sh4.deb
libc6-dev_2.3.2.ds1-13_sh4.deb
libc6-prof_2.3.2.ds1-13_sh4.deb
libc6-pic_2.3.2.ds1-13_sh4.deb
nscd_2.3.2.ds1-13_sh4.deb
libc6-dbg_2.3.2.ds1-13_sh4.deb
libc6-udeb_2.3.2.ds1-13_sh4.udeb
libnss-dns-udeb_2.3.2.ds1-13_sh4.udeb
libnss-files-udeb_2.3.2.ds1-13_sh4.udeb

さてどうしよう…．

インストールしてしまった．

3分ほど悩んだが，とりあえず金がかかっているわけでも命に差し支えるわけでもないので，libc6 を，libc6-dev と （先日作った）linux-kernel-headers と一緒に dpkg -i してみた．インストールされた．

うーん．一通り dpkg とか ls とかやってみても，正常に動いているように思える．いくつか ldd -v してみた限りでも，うまくいっているっぽい．成功？

…どうも落とし穴が待っている気がする…．

おうちでサーバ（その9: linux-kernel-headers）

linux-kernel-header 備忘録

linux-kernel-headerのbuildでそれなりにはまったのでメモ．

• debian/rules に，kernel_arch := $(patsubst sh4,sh,$(kernel_arch))と追加してやる必要がある．
• include/cpu-sh4 を include/cpu にlinkするかmvしてやる必要がある． 本来のお作法的にどちらにするべきか（もしくは他のやり方をすべきか）はわからない．
• include/asm-sh/byteorder.h (/usr/include/asm/byteorder.hになる） が，#ifdef 抜きに __u64 (= unsigned long long) を使っている． これは__STRICT_ANSI__なときは未定義となるので，gcc -ansi とかでコンパイルすると変なエラーに悩まされることになる．たとえば include/asm-i386/byteorder.h では #if !defined (__STRICT_ANSI__) で囲われているので，これに準ずるべき？ defined(__GCC__) という条件も必要？
• g++-3.0.4 では一部のテストがまともに通らない．新しいg++なら通るかは不明．

そんなところかな．BTSしたほうがいいのだろうか．

徒労

で，なんでそんなものと格納していたかというと，libc6-2.3.2がbuild-dependしていたから．でも， やっとこしらえてdpkg -iしようとしたら，libc6-dev-2.3.2にdependしているといわれ， そんなものはとーぜんないのでインストールできなかった．完全に徒労だった…．

…いや，たしかに確かめてからやればよかったんだけどね．

おうちでサーバ（その8: gcc-3.4 for SH4 完成）

gcc-3.4_3.4.1-3_sh4.deb 完成

7/27の日記に書いたffitarget.hの問題は，単に 「libffiをコンパイルしていないのにパッケージングしようとしていた」というオチだった． 別にlibffiを新しくしたいわけではないので，debian/rules.defs の適当なところで with_libffi := no と指定した．

これ以外はトラブルなく完成．gcc-3.3の難産を思うと嘘のようだ．

cpp-3.4_3.4.1-3_sh4.deb       gcc-3.4_3.4.1-3_sh4.deb
gcc-3.4-base_3.4.1-3_sh4.deb  libgcc1_3.4.1-3_sh4.deb

…つぎはいよいよlibc6なのかなぁ．さすがにやめておいたほうが無難かなぁ．

おうちでサーバ（その7: gcc-3.4 for SH4）

gcc-3.4 に挑戦してみた．

逃避はつづくよどこまでも．昨日の日記で紹介したように，gcc-3.3 の sh4 用パッケージはどうにか作ることができた． ただあまりにも無理矢理な作り方をしたため，ちょっと常用には抵抗がある．

そこで，試験を兼ねてgcc-3.4 の sh4 用パッケージを作ってみることにした． 昨晩寝る前にWITHOUT_LANG='c++ java f77 pascal objc ada treelang' dpkg-buildpackage -d と仕込んで（libcのバージョンがまだ古いので -d が必要）， うまくいけば今日の番にはパッケージができている寸法．前回 gcc-3.3 のときはjava関係ではまったのと， どうせlibcが古くてC++は動かないので，今回はgcc本体と関連ライブラリに限定．うまくいってから他は考えよう．

結果

惜しかった．orz

stage2/stage3でバイナリ不整合が起こることもなく，コンパイルは正常終了していた．gcc-3.3 は， 怪しい作り方をした割にはまっとうに動いてくれていたようだ．gcc-3.4-base, cpp-3.4, libgcc1 あたりのパッケージも生成されている．ただ，なぜか ffitarget.h (libffi関連) がパッケージツリーにコピーされていないために途中でこけていた．またこんなんかい．

仕方ないから，debian/rules で継続して，また適当なタイミングでコピーしてやろうかと思ったら，なぜか patch 当てから再開されてしまった．しかも二重適用しようとしてfailする．なぜだー， と思ったらWITHOUT_LANGの指定を忘れたことが敗因？

これではまともに継続できないので，もう一度 dpkg-buildpackage で最初からやり直し．ffitarget.h のコピーに失敗するのは，debian/rules.d/binary-libffi.mk をほげって解決を試みる．（7/28 注： そういう問題ではありませんでした）

というわけで，次の結果はまた明日．

おうちでサーバ（その6: gcc-3.3 for SH4）

gcc-3.3 の夜なべ完了

延々とやっているLANDISK用の夜なべdebパッケージ作成．とうとうgcc-3.3のdeb化に成功… したと言い切るのはちょっとはばかられるほど無理矢理だけど，とりあえず "gcc-3.3_3.3.4-2_sh4.deb" という名前のパッケージはできた．

まだ検証は十分にできてないが，とりあえず簡単なソースはコンパイルできた．まあ，gcc 一式のセルフビルドができるくらいには動いているのでよしとしよう．

gcc-3.3 無理矢理パッケージ生成手順

あまり人様に胸を張って公開できるやり方ではないが，とりあえず似たようなことをやっている方々の参考と自分自身の備忘のために， どういうはまり道をたどったのか書いておく．強調されている部分は，無理矢理な解決手段をとったところ．

• 依存関係の問題回避
• • gnat-3.2がないとgnat(Adaコンパイラ)がbuildできない → gnatを構築対象から外す． そのほか，FortranとかPascalとか使いそうもないものはすべて外す．C, C++, Java および関連ライブラリのみとする．
  • libcのバージョンが古すぎ → バージョン依存関係を無視．
• コンパイル時の不具合回避
• • stage2とstage3のバイナリ生成結果が2つほど一致しない(たしかdwarf2out.oあたりだと思うが忘れた ^^;) → stage3のバイナリをstage2にコピーしてごまかす．
  • jv-convertなどlibgcj関係の実行ファイルを生成する際，libffiがリンクされない → libffi.laをlibtoolに食わせるようMakefileを直接変更．
• パッケージ生成時の問題回避
• • libgcc_s.*がdebian/tmp/usr/libにコピーされず， libgccのパッケージ生成に失敗する（ここらへん，元々のmakefileのロジックが怪しい）→ debian/rules実行中の適当なタイミングでコピーする（わはははは）． これはさすがにひどすぎる回避法と思うが，どこを修正するべきかわからなかった．
  • test-summaryが生成されていない（無理矢理ごまかしたせい？）→ touchしてごまかす．

ここまでで，各種パッケージは生成できた（つもり）．

gcc-3.3-base_3.3.4-2_sh4.deb        libgcc1_3.3.4-2_sh4.deb
cpp-3.3_3.3.4-2_sh4.deb             protoize_3.3.4-2_sh4.deb
fixincludes_3.3.4-2_sh4.deb         libffi2_3.3.4-2_sh4.deb
libffi2-dev_3.3.4-2_sh4.deb         gij-3.3_3.3.4-2_sh4.deb
libgcj4_3.3.4-2_sh4.deb             gcj-3.3_3.3.4-2_sh4.deb
libgcj4-dev_3.3.4-2_sh4.deb         fastjar_3.3.4-2_sh4.deb
g++-3.3_3.3.4-2_sh4.deb             libstdc++5_3.3.4-2_sh4.deb
libstdc++5-3.3-dev_3.3.4-2_sh4.deb  libstdc++5-3.3-pic_3.3.4-2_sh4.deb
libstdc++5-3.3-dbg_3.3.4-2_sh4.deb  gcc-3.3_3.3.4-2_sh4.deb

導入時の問題 - libgcc1について *** 重要 ***

無理矢理パッケージ化したせいか，もともとのDODES成果物の仕様による影響かはわからないが， libgcc1をそのままインストールすると，lsなど多くのプログラムで実行時に "/lib/libgcc_s.so.1: version `GLIBC_2.0' not found (required by ls)" などといわれてしまい， 動かなくなってしまう．lsやmvなどの基本的なプログラムにも影響が出てしまうので，かなり致命的．ただ， chroot環境の外には影響はないので，いざそうなってしまってもなんとかならないことはないが（実際になんとかなった）．

そのため，libgcc1 を dpkg -i する前に， あらかじめ以下のようにして元のlibgcc_s.so.1も使えるようにしておく．（本来はpreinst script等で対処すべきなのかなぁ）．

1. cp /lib/libgcc_s.so.1 /lib/libgcc_s_glibc20.so.1
2. echo /lib/libgcc_s_glibc20.so.1 >> /etc/ld.so.preload
3. ln -sf /lib/libgcc_s_glibc20.so.1 /usr/lib/gcc-lib/sh4-linux/3.0.4/libgcc_s.so

ちなみに，すでにlibgcc1をインストールしてしまった場合は，元のlibgcc_s.so.1 が base-sh4-020728.tar.gzに入っているのでそれを使えば良い．

導入時の問題２ - g++が使えない

せっかくg++を作ってみたのだが，libstdc++5がlibcのバージョン依存関係でインストールできないので使えない． 意味ないじゃん．結局libcも夜なべしないとだめか．ただ，さすがにそれはちょっと怖くて躊躇してしまう．

あああ，aptitudeまでの道のりはまだ遠い……．

おうちでサーバ（その5: 夜なべの進捗）

gcc-3.3苦戦中

7/6の日記（注：はてなダイアリーのオリジナル） にmassさんからコメントをいただいたので，夜なべで作っていたLANDISK用*_sh4.debパッケージ（命名：夜なべパッケージ） 作成の進捗報告．

ごめんなさい．私もgcc-3.3の夜なべは途中で詰まっていたりします．

gcc-3.3_3.3.4-2のソースパッケージを使ったのだけど，まずそのままではbuildできない． gnat(Adaコンパイラ)の構築に古いgnatを要求したりするので生成対象から切り離し， stage2とstage3とで一部の生成バイナリが一致しないのでごまかし（ぉぃ）…とやってきたのだけれど， 現在はjv-convert（libgcj関係）のbuildで，リンクに失敗してこけてしまうところで引っかかっている．

ただ，これを書くために見直しているうちに原因がわかった． libffiをリンクしなきゃいけないのにMakefileで指定されてない．Makefileを直接修正してみたら（注：いけません） makeが通るようになったので，また夜なべを再開．

…と書いている間にひととおりコンパイルは終わってパッケージ生成段階に入り， gcc-3.3-base_3.3.4-2_sh4.debが出来上がった．よしこの調子，と思っていたら， なぜかlibgccのパッケージ生成でまたこける．なんか際限がないな．

まあ，進捗があったら（もしくはギブアップしたら ^^;）この日記でまた報告します．

ocamlはgccのbuildに必要？

ところで ocaml は cdbs (gcc の build に必要な automake の build に必要)だったと思いますが，cdbs はアーキテクチャ非依存のパッケージなので，本家で公開してあるものがそのまま使えます（はず）． ですので，ocaml はなくても gcc の夜なべに突入することは可能です．:-) > mass さん

おうちでサーバ（その4: パッケージを充実させたい編）

もっとdebパッケージを！

というわけで，LANDISKのLinux BOX化の続き．我ながらよく続くものだ．

昨日の日記で，Debian/SH4な環境が構築できたことを書いた．DODESプロジェクトの成果で， gccを含めかなりのパッケージがSH4に移植されている．

ただ，いかんせんパッケージのバージョンが古いし，すべてのパッケージが移植されているわけでもないので，不都合も出てくる． たとえばaptitudeは入っていない．apt-getだけでもそんなには困らないけど，やっぱりちょっと不便．ソースは手に入るんだし， ちょっくらbuildしてインストールしてみよう．

…なんてことを思ってしまったのが運のつき．

SH4用のパッケージを作ってみよう

クロス開発環境を構築して，そこでパッケージを作ってもいいし， LANDISKのSH4の非力さを考えるとそちらのほうが最終的には早いんだろうけど，せっかくgccがあるんだし，低騒音・低消費電力・ 24H稼動の強みを活かして，LANDISK自身に夜なべでパッケージをbuildしてもらうことにした． 電源を入れて翌日には24Hこき使われるなんて，うちのLANDISKってば不幸．

まずは下準備．apt-getでソースパッケージを取得できるように/etc/apt/sources.listを編集する． バイナリパッケージ用のDODESのサイトを含め，こんな感じ．

deb http://debian.dodes.org/debian sid main non-free contrib
deb-src http://ring.asahi-net.or.jp/pub/linux/debian/debian sid main contrib non-free
deb-src http://ring.asahi-net.or.jp/pub/linux/debian/debian-jp sid-jp main contrib non-free

deb-srcの行の'sid'はお好みに合わせてstableでもtestingでもお好きなように．

あとは，apt-get updateでパッケージDBを更新したあと，

1. apt-get source hogehoge で，hogehogeのソースパッケージを取ってくる．
   
2. hogehoge-X.Y というディレクトリ（X,Yは適当な数字）ができるので，そこに移動．
   
3. おもむろにdpkg-buildpackage -rfakerootと入力してパッケージをビルド．（rootの場合は -rfakeroot は不要．こわいけど）
   
4. これだけで，運がよければ親ディレクトリにhogehogeのパッケージができているので，それを dpkg -i でインストール．

このとき，GNU screenを用いて上記の手順を実施すれば， 時間がかかるビルドの途中で端末の接続を切ったり繋ぎ戻したりが自在にできてとても便利． screenの使い方はてきとーにぐぐれば見つかります．

ただし，昨日書いたように chroot 環境の /dev/pts に devpts fs を mount しておかないと， screen が起動できないので注意のこと．

パッケージ構築のための依存関係を満たせていない場合

dpkg-buildpackageをしても，

...（省略）
dpkg-checkbuilddeps: Unmet build dependencies: gcj (>= 3:3.2.2-0) fastjar sablevm libgcj4-dev
dpkg-buildpackage: Build dependencies/conflicts unsatisfied; aborting.
dpkg-buildpackage: (Use -d flag to override.)

なんてエラーが出て止まってしまうことがある．読んだままの意味で，パッケージをビルドするために必要なパッケージが足りない．

このときは，「足りない」と言われたパッケージをapt-getでインストールするか，（バイナリパッケージが無いようなら） そちらを先にソースからビルドすればよい．

…これを再帰的に繰り返すと，そのうちに元々は何をビルドしたかったのか忘れてしまったりしがちなので注意．

依存関係が満たせない場合

ときどき，Aというパッケージの構築にBというパッケージが必要で，Bの構築にはAが必要， みたいに依存関係が循環してしまうケースに出合ってしまう．たいていはバージョンの制約が原因なので， そんなときは古いパッケージを無理やり使ってビルドしてしまうのも一つの手．(もちろん本来はやるべきではない）

dpkg-buildpackage -d で依存関係を無視すれば，無理やりビルドが可能になる．ただ， 何かがおかしくなっている可能性があるので，無理やりビルドしたパッケージは（必要に応じて）後でビルドし直したほうがいいかも．ただ， 所詮は無理やりなもので作ったものを使って作り直すことになるので，それも気休めかもしれない．at your own riskでどうぞ． （この話だけに限りませんが）

途中でビルドが止まってしまった

SH4は公式な移植対象ではないので，きちんと依存関係を守ってビルドしても途中でmakeが止まってしまうことがある． そんなときはてきとーにほげってmakeを続行させればよいが， dpkg-buildpackageだと途中までの成果をきれいさっぱり忘れて最初からやり直しになってしまう．それが悲しいときは， debian/rules binary と唱えてmakeを途中から再開させることができる．

注意事項

上記で書いたことは，3分間クッキングのようにいい加減です．言い換えると，rpmの世界のようにいい加減です :p． Debianには本来それなりに厳格なお作法があり，それを支える優秀なツール群も充実しています．本来のやり方について， メンテナ入門やポリシーマニュアルなど関連ドキュメントを一読することをお勧めします．

現時点までの夜なべの成果

並べてみた．

te@landisk$ ls *sh4.deb
acl_2.2.23-1_sh4.deb                      libncurses5-dbg_5.4-4_sh4.deb
attr_2.4.16-1_sh4.deb                     libncurses5-dev_5.4-4_sh4.deb
binutils-dev_2.14.90.0.7-8_sh4.deb        libncurses5_5.4-4_sh4.deb
binutils-multiarch_2.14.90.0.7-8_sh4.deb  libncursesw5-dbg_5.4-4_sh4.deb
binutils_2.14.90.0.7-8_sh4.deb            libncursesw5-dev_5.4-4_sh4.deb
blt-common_2.4z-2_sh4.deb                 libncursesw5_5.4-4_sh4.deb
blt-demo_2.4z-2_sh4.deb                   libsigc++-1.2-5c102_1.2.5-1_sh4.deb
blt-dev_2.4z-2_sh4.deb                    libsigc++-1.2-dev_1.2.5-1_sh4.deb
blt_2.4z-2_sh4.deb                        libssl-dev_0.9.7d-3_sh4.deb
bzip2_1.0.2-1_sh4.deb                     libssl0.9.7_0.9.7d-3_sh4.deb
coreutils_5.0.91-2_sh4.deb                make_3.80-8_sh4.deb
debianutils_2.8.3_sh4.deb                 ncurses-bin_5.4-4_sh4.deb
devscripts_2.7.95.1_sh4.deb               openssl_0.9.7d-3_sh4.deb
flex-old_2.5.4a-6_sh4.deb                 sed_4.1-3_sh4.deb
info_4.6-1_sh4.deb                        tcl8.4-dev_8.4.6-1_sh4.deb
libacl1-dev_2.2.23-1_sh4.deb              tcl8.4_8.4.6-1_sh4.deb
libacl1_2.2.23-1_sh4.deb                  texinfo_4.6-1_sh4.deb
libattr1-dev_2.4.16-1_sh4.deb             tix8.1-dev_8.1.4-6_sh4.deb
libattr1_2.4.16-1_sh4.deb                 tix8.1_8.1.4-6_sh4.deb
libbz2-1.0_1.0.2-1_sh4.deb                tk8.4-dev_8.4.6-1_sh4.deb
libbz2-dev_1.0.2-1_sh4.deb                tk8.4_8.4.6-1_sh4.deb
libgdbm-dev_1.8.3-2_sh4.deb               wget_1.8.1-6_sh4.deb
libgdbm3_1.8.3-2_sh4.deb

こうして見るといつのまにかそれなりに作ったな．現在，大物のgcc-3.3一式を夜なべ中． ビルドの際にgcc-3.3に依存するパッケージも結構多いので．こいつはさすがに一筋縄ではいかない．

ちなみに，この道に踏み出す原因となったaptitudeはまだビルドできていません． aptitudeをビルドできる環境を構築するだったはずが，なんとなく手段が目的化してしまっているような気がする．

…まあ，正しい現実逃避のあり方かもしれない．

おうちでサーバ（その3: Linux BOX化編）

まずはSSH

いよいよ LANDISK HDL-160U をLinux BOXとして設定する．なんにしろ， shellが使えるようにしなくては話がはじまらない．そこで，まずはhttp://iwa.ath.cx/landisk/landisk-ssh.htmlにあるインストーラをありがたく使わせていただいて， sshdをインストール．ファームウェアの更新機能を使ってインストールできるので簡単．感謝．

ファームウェアのアップデート

ファームウェアのバージョンが1.00だったので1.30へアップデートした．いろいろ不具合が直っている． 詳細はIO-DATAのサイトを参照．アップデート後，sshdが正常に稼動していることを確認．よしよし．

Debian環境の構築

さて．これからいろいろとインストールをするにあたり，開発環境を構築しなくてはならない． できればapt-getが使えるDebianで環境を構築したいところだが，もともとの出荷環境を破壊するのは最小限に留めたい．

そこで，/mnt/hda3の下にdebianというディレクトリを切ってその下にDebianのツリーを展開し， chrootして使うことにした．幸い，Debian/SH4はDODESプロジェクトによりそれなりにパッケージングがなされているため， これをありがたく拝借する．

以下は手順．以下，$debianは構築するDebian環境のルートディレクトリとする （私の環境では/mnt/hda3/debian）．

1. sudo -s でrootになる．
2. http://debian.dodes.org/debian/base/base-sh4-020728.tar.gzを$debianに展開する．
3. echo 'deb http://debian.dodes.org/debian sid main non-free contrib' > $debian/etc/apt/sources.list
4. HOME=/root $debian/usr/sbin/chroot $debian /bin/sh -l
5. apt-get update
6. あとは適宜 apt-get install hogehoge で必要なhogehogeパッケージをインストールする． apt-getの使い方はあちこちにあるDebian関係のリソースを参照してください．

これでたいていの必要な環境は揃ってしまう．拍子抜けなほど簡単．うーむ．

TIPS

• ps などを使えるようにするために，proc ファイルシステムを $debian/procにmountしておきましょう．
• screen などを使えるようにするために，/dev/pts ファイルシステムを $debian/dev/ptsにmountしておきましょう．
• （重要）/etc/sudoers を編集するときには忘れずパーミッションを元に戻しましょう．忘れると非常に痛い思いをします．

/etc/sudoersの編集における悲劇（喜劇？）

とても痛い目にあったので忘れないように．

普段使っているlogin nameからsudoしたかったので，/etc/sudoersを書き換えようとした． ちなみに/etc/sudoersはsudo可能なuserを管理するための設定ファイルである．

1. mount -o rw,remount / でrootファイルシステムを読み書き可能モードで再マウント．
2. 本来はvisudoで/etc/sudoersの更新は行うのだが， 当然そんなものは入っていないのでふつーにviで書き換えることにする．
3. chmod +w /etc/sudoers で書き換え可能にし，
4. vi /etc/sudoers で編集．

で，ここで思わずroot shellからexitしてしまった．

…sudoは/etc/sudoersがread onlyでないと失敗するんじゃん． ファームウェアの更新もsudoを使っているっぽい (ユーザapacheからNOPASSWDでsudo可能にしてある… のはそういうことだよね）ので，今後ふつーのNASとして利用するのでさえも差し支えてしまう．きゃあ．これは困った．

さて，ここで問題です

• /etc/sudoers のパーミッションが0640になってしまっている．
• 一般ユーザとしてログインすることは可能である．
• rootのパスワードは知らない．
• chroot環境 (/etc は含まれない) でroot shellが利用できる．当然， /etc/sudoersは触れない．

という状況で，/etc/sudoersのパーミッションを戻すにはどうしたらよいでしょうか．

setuid

30秒ほど青ざめた後，setuidしたスクリプトをchroot環境のroot shellを使って作り， それをchroot環境の外の一般ユーザで実行することにより/etc/sudoersのパーミッションを0440に戻すことを思いつく．

ただし，shellスクリプトはsetuidできないことになっているので，suidperlを使うことに…したのだが， なぜかLANDISKに元々入っているsuidperlでは「Can't do setuid」とか言われて実行できない． Debianなchroot環境では正常に実行できるのだが，それでは意味が無い． しょうがないのでCでプログラムを書いてchroot環境のgccでコンパイルし，setuidして実行することにした． 以下はそのソースコード…と呼べるほどのものでもないけれど．

#include <sys/types.h>
#include <sys/stat.h>
#include <string.h>
#include <errno.h>
#include <stdio.h>

main()
{
  if ( chmod("/etc/sudoers",S_IREAD) )
    perror(strerror(errno));
}

以後，同じような事故が起こったときのために， これをコンパイルしてsuidを立てたものを/usr/local/binに置いておくことにした．

…まあ，visudoもどきを書いておくのが本来だと思うけど，本気で書こうとすると結構面倒くさいし．エラー制御とか．

おうちでサーバ（その2: NAS購入編）

家庭用NASの比較

玄箱 KURO-BOX（玄人指向）

いきなりマニアックな製品でごめんなさい．でも，HDD抜きで販売しており， 手元であまっているHDDがそのまま使えるためコストパフォーマンスが最も高いこと，メーカ自身が「Linuxサーバ」 としての運用も想定して販売していることなどから，これを筆頭候補として選定を開始した．ただし， 筐体がプラスチック製でHDDと共振したり，ファンがそれなりの音を出したりと，なかなか騒音がにぎやからしい．また， 需要を見誤ったか生産体制がなっちゃいないのかそれとも単に煽っているのか，入手性が悪いこともネック． このごろはだいぶましになったみたいだけど．

LinkStation HD-HLANシリーズ（バッファロー）

上記の玄箱の元になったNAS．つまりファンがある．玄箱はこのシリーズからHDDを抜いて，色を（なぜか） 黒くしてkit化したもの．色のほかはHDDの分が割高な点と，Linux箱としての運用は想定されていないことを除いてほぼ同じ？ 　今回の目的に対しては玄箱のほうがリーズナブルなので，あえてこちらを選ぶ理由は無い．HD-HLANシリーズの他にも， 下位機種のHD-LANシリーズや上位機種のHD-HGLANシリーズがあるが， 前者はUSBなどの口を全く持っていないため拡張性に乏しい（＝遊べない）こと， 後者は1000Base-T接続に数千円の価値を見出せなかったことからどちらも除外．

LHD-LANシリーズ，LHD-EAシリーズ（ロジテック）

ファンレス．ただ，UNIX化の話を見ないんだよね…と思ったら， LHD-LANシリーズはSynologyとかいう会社の独自OSらしい．また，旧製品のLHD-EAシリーズにいたっては， NASなのになぜか専用ドライバをインストールしたWindowsからしか使えませんという冗談のような素晴らしさ． SMBすら喋れんのかい．…ま，いいんだけどね．それでも安けりゃ買う人はいるんだろうから．ただ，個人的には「XXしか使えません」 のような決めうち的な売り方をする会社やその製品は信用しません．Network絡みの場合は特に．

LANDISK HDLシリーズ（IO-DATA）

これもファンレス．SH4/266MHzという性能もぼちぼち．ほげればLinuxサーバとしての運用も可能らしい． 旧機種(HDA-ixxG/{LAN,LAN2}シリーズ)は性能に難があったらしいが，現行機種は悪い評判もほとんど見ない． 価格帯もライバル？HD-HLANシリーズと同程度．玄箱よりは割高になるが， ファンレス＋しっかりしていそうな作りの分の代金と思えば悪くないか．

…それにしてもHD-HLANだとかLHD-LANだとかHDLだとか紛らわしいな．わざと？

検討結果

結論として，実物を見て玄箱の作りがそんなに悪くなさそうなら玄箱を， そうでないならHDLシリーズの中で最も安いHDL-120Uを買うことにした．120GBもあればとりあえず十分だし， 足りなくなれば換装すればよいことなので．

価格.comによるWeb通販の相場では，玄箱が15K円前後，HDL-120Uが24K円台半ば（どちらも送料込み，6/27現在） ．ちょうどヨドバシカメラのそばまで行く用事があったので，それより割安ならば買うことにした．

ヨドバシカメラへGO

と，その前にヨドバシのWeb通販の価格もチェック．玄箱はない．HDL-120Uは29.8K円で21%ポイント還元． 21%引きで計算すると23.5K円くらいになる．

これは価格.comの最安値よりかなり安いことになってしまうが，ポイントでの買い物にはポイントがつかない点や，（当たり前だが） ヨドバシカメラでしかポイントは使えない（流動性が低い）ことなどから，ヨドバシに限らず「ポイント」 の価値は現金の2割減くらいに考えることにしている．するとだいたい24.7K円くらい．まあこんなものか．

さて，ヨドバシカメラK店に到着．玄箱はない．HDL-120Uは，29.8K円でポイント18%．Webより割高やん．店員さんに 「Web通販では21%だったんですが…」と聞いてみると，いったん店の奥に引っ込んで「店頭ではポイントの還元率は変更できないので， 4%現金値引きの上で18%ポイントをつけます」とのこと．よしよし．やるなヨドバシ．偉いのでヨドバシのサイトへのリンクを張ってあげよう． こんな僻地からリンクを張ったところでPageRankの足しにもならんと思うけど．

今日はここまで．つぎはいよいよLANDISKの設定…かな．

おうちでサーバ（その1: 比較検討編）

自宅でUNIXサーバ

自宅にUNIXのサーバがほしかったのだけど， ふつーのPCにLinuxを放り込んだのではやかましいし電気代は食うしでなかなか24H稼動は難しい．というわけで，ちょっと考えてみた．

要求条件は，

• いわゆるUNIX互換OSが稼動すること．
• それなりのディスク容量．あまり小さいと用途が限られてしまう．100GBくらいは自由に使える領域があることが目標．
• ファンレスもしくはそれに準ずる静穏性を持つこと．家庭で24H稼動が前提なので． あまりやかましいと奥さんに目をつけられてしまう．耳を澄ませば…程度が目標．
• 筐体が小さいこと．あまり大きいと奥さんに目をつけられてしまう．外付けのHDDやMOドライブ程度が目標．
• 低消費電力．あまり電気を食うと以下同文．それに小さい筐体でファンレスにするには必須のはず．蛍光灯クラスが目標．
• 低価格．あまり価格が以下省略．数万円前半，できれば3万円未満で抑えたい．

というあたり．

比較してみた

いくつか，上記の要求条件をみたしそうなものについて比較検討してみた．

OpenBlockS

王道．ファンレスで小さくて実績もあるのはいいのだけど…いかんせん高い． 本体も高いしどうせ必要となる2.5''HDDも高い．ディスク容量も稼ぎにくい．

VIA Eden

自作派的にはそそられる選択肢．通常のPC-UNIXがそのまま使えるものうれしい． CPUがx86系として非力でもサーバ用途にはほぼ問題なし．余っているメモリやHDD，光学ドライブなどを使いまわせば， 費用もそんなにかからない．ただ，小さくすることに限界があること，他の選択肢に比べて消費電力が大きくなってしまう（白熱灯クラス？） ことが難点．あと，どの筐体も電源がかなりうそっぽい．24H稼動させるには勇気が要りそう．

NotePC

実はスペック的にはサーバとして結構優れもの．通常のPC-UNIXがそのまま使え，消費電力もほぼ申し分ない． 数時間もの長時間バックアップ可能な超強力UPS :-) も標準装備だし， さらにキーボードとLCDまで標準装備なので障害時も楽々運用．ただ， もともと24H稼動を前提として作られちゃいないので信頼性は気になるけど．あと，最大のネックは価格． この用途に新品を買うのはありえないし，中古もそれなりの値段がする．さすがに手元で余っているWinbook Quattro90とかCompaq Contura AeroとかではCPU性能もHDD容量もつらいし．

家庭用NAS

IO-DATAやメルコやロジテックあたりが出している，いわゆるLAN付きのHDD． 騒音はメーカによってばらつきがあるけど，大きさとか消費電力とかHDD容量とか，そのほかについてはほぼ要求条件を満たしている． 価格も安いものは2万円程度．ただ，元々は単なるNASとして売っているためそのままではUNIXマシンとして使えない． 慎重な機種選定と，ほげるための根気と努力と覚悟が必要．

価格的にはEdenか家庭用NASのどちらか．性能や運用の容易さはEdenだが，消費電力や筐体サイズがちょっとつらい． 電源の信頼性も不安．家庭用NASは，逆に性能と運用の容易さにちょっと難がありそうだが， 性能はあまり凝ったことをしなければまあ十分そう（SH4/266MHz程度）．運用が面倒そうな点については， まあ趣味でやるんだからちょっと面倒なくらいがちょうどよいかも．ということで，家庭用NASを購入してほげることにした．

…と，ここまできたところで今日は力尽きたので，続きは後日．