玄箱PRO+Debian lenny(armel) + PostfixのOP25B対策

戻る

玄箱PROでHDDを使わないで運用できたら……と思っていましたが、どうやら起動後にもHDDの電源を切ることが出来るようですし、ちょうどSATAのHDDで5400rpmという低発熱のHDD(WDC WD10EADS-00L5B1)が売っていたこともあって、現在はHDD上に保存して動かしている状態です。

5400回転のものは、WesternDigital やSamsungで作っているようです(2009年1月頃)。容量は500GBから1TBくらいでした。最近は7200rpmとか、10000rpmのもののほうがよく見かけるようになっています。しかし、玄箱等ホームサーバでは、電源いれっぱなしの場合も多いでしょうし、こういった低回転数のHDDも結構需要があるのではないでしょうか?
また、夏にはユーザーランドをHDDからUSBフラッシュに移して動かしてみるかもしれません。


玄箱PROは、シリアルコンソールが無い状態ではかなり手を出しにくく感じました。しかし、シリアルコンソールでu-bootの設定を変えられる状態にすればかなり安心していじれるようになるので、今では玄箱HG以上にお勧めかもしれないと思うようにもなっています。

私も、ネット上にある情報を頼りに玄箱PROを弄ってみました。
このページで行っていることは以下の通りです。




問題点(であると私が思っている点)について並べてみます。
ただ、私がミスった点、不満点などを並べてあるだけでもありますが……

  1. シリアルコンソールに半田付け等の工作が必要(場合によってはメーカー保証がなくなる)
  2. EABIを有効にしたバイナリを使っているが、LinuxKernelの正式対応前のもの(かもしれない)
  3. 一度何かに使ったHDDの場合、初期化に一定の手順が必要。
  4. 初期化されたHDDはEXT3とXFSが混在していて、XFSはEABIオフのシェルでマウントすると壊れるらしい。
  5. スイッチまわりや時計に玄箱PRO独自の仕組みが要求される(これは仕方がないことか……)
  6. 玄人志向純正の環境でも、フラッシュ環境とHDD環境では微妙に違う部分がある

1については、箱の下面の接続口を利用すれば保証を無効にすることなく接続できるらしいのですが、工作がより面倒になっていきます。基盤に半田付けしてしまうほうが結構比較的楽だと思います。オフィシャルに売っているものを使ってもいいし、携帯用のRS-232用(シリアルポート?)の物などが流用できるようになっていますし。
私は、2008年の春ごろに東京へ行った際に秋葉原で買ってきました。コードの色がちょっと新しくて悩みましたが。

2については、Linux kernelでarmプロセッサのEABIに対応したのは2.6.16以降なのだそうです。玄箱PRO発売当時から対応版のカーネルは出ていたと思うのですが、玄箱PROには対応前のバージョンが使われていて、それでいて独自に(もしくは対応版のコードを流用して?)EABIへの対応が行われています。玄箱PROを作る前のLinkstationのコードなのでしょうか?
そのせいか、このカーネルと玄箱ユーザーが作成したEABI対応カーネルの間にはなんらかの隔たりができてしまっているように見えます(XFSの問題しか知らないけど。lenny armelにtoo old!と怒られる事もこのあたりでしょうか?)

3については、対応方法がネットで見つかりますが、一度目に挑戦した場合失敗してしまう人も多数いるでしょう。

4についてですが……現在、EABIをオンにしたバイナリがLenny armelとしてdebianから配布されています。そこで、私はOABIのdebianを使わずに全部EABIを有効にしたバイナリを使って作ろうと考えていたのですが、作成中にOABIなユーザーランドからXFSをマウントしてしまったためか、HDD起動時のデフォルトのXFS(sda2)を壊してしまいました。正確な原因は不明です。電源まわりとかあまり考慮しないで新しいカーネルを起動させたため、電源ボタン長押しで止めるしかなかったあたりが悪影響を及ぼしたのかもしれません。

そんなわけで、これについては(その他も全部そうなんですけど……)私個人のミスなのかもしれませんが、玄箱PROオリジナルカーネルからの移行時には、電源まわり、使用しているファイルシステム、作ったカーネルを動かすユーザーランド(玄人志向純正のrootfsか、debianのOABI、EABIあたりが選択肢に入るでしょう)は何がよいか、、HDD内のデフォルトの領域(HDDの場合sda2)が壊れたときに代わりに立ち上げるユーザーランドを用意しておく……など、注意が必要かもしれません。
5については、電源については玄箱PRO付属の"マイコン仕様書"の通りに動くプログラムを作ってくれた人がいるようで、これを使えば問題なしです。 あと、時計を読み込むのに失敗し、シリアルコンソールのログイン画面がまっ黄色(末期色)になってしまうため、Teratermでは白地に黄色で非常に見難くなります。Teratermを使う場合、背景を黒に変えることにしました。また、時計がずれている場合、フラッシュ環境から直すしか方法がみつかりません。
6については、時計(ハードウェアクロック)を設定するプログラムがフラッシュ環境でしか動かない点や、HDDのrootfsにはu-bootの設定を変えるためのnvramが入ってないなどの問題があります。起動完了時にもピコピコって鳴らないし。まあ、たいした問題でもない(と思う)んですが。
でも、HDD環境では何故か固定IPにする設定が上手くいきませんでした。LANではつながるけどWANでは上手くいかず、chrootした環境からapt-getできなかった。DHCPにしたところ、ちゃんとつながるようになりました。

  • シリアルコンソールのための工作(9-CDM)

  • 私も携帯用の有名なやつ(9-KE)を利用しようとしました。半年ほど前に買っておいたものがあったので、それを切って使ったんですが、9-KEはドコモ用なんですね。自分の携帯にも接続してみようと考えてたので、9-cdmのほうを買ったみたいです。
    切ってみたらネットで見た奴とコードの色が違った。

    その辺に気付かず、コードの色が新しいパターンに変わったのかな?と思って9-KEの情報をあたっていきました

    内部の回路を紹介しているサイトを参考にしてみたところ、
    9−KE分解記
    wiki@nothing BUFFALO Hack/シリアルコンソール
    コードの色電流が流れたピンの番号
    TxD
    RxD
    GND
    GND


    で、3番目のピンに対しては接続せず、4番目のピンに黒か緑を接続します。 検証方法については、発光ダイオードと電池を各コードと接続口の9ピンにつなぎ、光るか否かという大変泥臭い方法で行いました。
    結果を書いておくと、 電流の向きが
    9ピン(+) → コード(-)
    のとき、
    コードの色電流が流れたピンの番号
    2,7,8
    2,3,5,7,8
    2,3,5,7,8
    2,3,5,7,8


    電流の向きが
    コード(+) → 9ピン(-)
    のとき、
    コードの色電流が流れたピンの番号
    2,3,5
    なし
    3,5
    3,5


    もう一つ、こちらにも別の色が出てきたときのため、携帯(AU)側のコネクタと今回の9-CDMの線のつながりについて、大体の場所を図示

    妙に膨らんだ穴を左側において見てください。コードが上下どちらのピンに繋がっていたかはよくわかりません。
    黒は携帯用コネクタ内部で2箇所に接続されていたので、2箇所存在していることは間違いとかではないです。

    2.5mピッチの4ピンコネクタをはんだ付けします。
    コネクタについては、玄人志向純正の品についているコネクタを正しい方向にはんだ付けできるよう、シルク印刷で四角い囲みが描かれています。

    槻ノ木隆のPC実験室 写真22参照

    このコネクタは、マルツではZL2506 4PS(ストレート)という型番で、寝かせるタイプは、ZL2506 4PL(ライトアングル)
    ……として売られています。

    写真



    玄箱、玄箱HGについては、
    こちらのページ
    HD-HGLANにシリアルコンソールを接続する
    と同じ向きにはんだ付けすれば、同じケーブルが使えるはずです。

    HGでも利用可能であることを確認しました。R76をショートするのを忘れてたので書き込みができない状態でしたが……
    その後、コネクタの下になってしまったR76に1kΩのチップ抵抗をつなぎ、ちゃんとログインできるようになりました。

    また、その際youtubeにチップ抵抗の半田付けの動画があることを知り、参考にさせてもらいました。(なんでも見つかるなあw)
    はんだ付け 1608のチップ抵抗

    玄箱の基盤上で使用するのに最も適したチップ抵抗の大きさは1×0.5(mm)のもののようです。しかし、近所では売ってませんでした。
    コンソールの設定
    玄箱HG玄箱PRO
    ビットレート57600115200
    データビット88
    パリティnonenone
    ストップビット11
    フロー制御nonenone
    備考文字コードはUTF-8
    UTF-8対応のteraterm、
    Puttyで接続確認


  • EABIの問題(OABIカーネル+etch or EABIカーネル+lenny armel)

  • debootstrapという、debianをインストールするためのプログラムを使ってlenny環境を用意しようとしました。

    lennyは現在の安定版の次のバージョン(debian5.0)で、これは2009年1月現在testing(stableの一つ前)ということになります。
    とはいえ、それ以上のsid(unstable)を動かしてみようとする人もいるくらいですし、現在では何人もの人が玄箱PROでlennyを動かしています。まあ、いけるでしょう。

    lennyを選ぶ理由としては、debianではこのlennyからarmのEABIをサポートしているためです。lennyには"arm"とは別に"armel"という分類でもバイナリパッケージが管理されており、これを利用すれば簡単にEABI対応のバイナリでそろえることができると考えました。

    ちなみに、"armel"という呼び方は、「armプロセッサで、EABI対応で、Little endian で作ったバイナリ」を意味するらしいです。
    Debian Wiki armelについていろいろ(英語)

    EABIに対応したバイナリは少数を含む計算がやや高速になることが期待されるそうです。しかし、EABIに対応させるには、OSの全てをEABIに対応させた形で統一することが望ましいらしいです。総入れ替えが必要になります。EABIでカーネルを作ろうとすると、OABIのバイナリと共存を計るオプションが存在していることがわかりますが、どの程度まで有効であるのかわかりません。

    純正の玄箱PROはEABIで統一されているらしいです。しかし、現在の安定版のDebian(etch)では、OABIのバイナリしか提供されていませんでした。

    しかし、 2008年6月ごろに、lennyでEABIに対応することが発表された(?)ことにより、全てEABIなDebianも作成できるようになりました。また、カーネルも2.6.25から玄箱PRO用のパッチを正式に採用することが決まり、カーネルの作成も容易になってきました。

    そこで、lennyをdebootstrapというものを使って玄箱PROに入れてみようと考えました。正直、従来のEABIカーネルでもlennyを動かせるだろうと考えていたのですが、どうもそう上手くはいかないようです。

    結局、カーネルも新しく作り直す必要が出てきてしまい、カーネル、ユーザーランド共に新しく作り直すことになりました。



    バイナリがEABIで作られているか識別するには?

    バイナリがEABIに対応しているかどうかは、objdump -p [バイナリを指定]で調べられるそうです。

    OABI
    # objdump -p /bin/ls
    ……
    private flags = 2: [APCS-32] [FPA float format] [has entry point]


    EABI
    # objdump -p /bin/ls
    ……
    private flags = 4000002: [Version4 EABI] [has entry point]


    ザ・コンペイター 玄箱プロにDebian


    わたしは、カーネルが本当にEABIに対応しているのかどうか確認できる方法が知りたかったんですが、この方法ではカーネルのバイナリを調べることはできません。
    コンフィグファイルはEABIを有効にしてあるそうですし、フラッシュ、HDDの開発環境用に用意されたバイナリは確かにEABIが有効になってましたが……

    全てEABIを有効にした状態ならXFSも問題ないのかもしれませんが、私の場合、etch(OABI)で作ったEABIカーネルでlenny環境にchrootしてログインできる状態にし、ログインしょうとして電源が切れなくなった……みたいな感じだったと思います。

    場合によってはetch(OABI)環境でブートしてXFSをマウントしてしまったかもしれません。そこからは、USBフラッシュメモリ上に展開しておいたユーザーランドでログインし、ext2fsでフォーマットしなおしたsda2に玄人志向のhddrootfs.tar.gzを単純に展開し直したところ、元通りに起動させることができました。

    この際、パーティションを切りなおし、以下のように作り変えてあります。
    KUROBOX-PRO:/etc/postfix# fdisk -l
    Disk /dev/sda: 1000.2 GB, 1000204886016 bytes
    255 heads, 63 sectors/track, 121601 cylinders
    Units = cylinders of 16065 * 512 = 8225280 bytes
    Disk identifier: 0x00000000
    
       Device Boot      Start         End      Blocks   Id  System
    /dev/sda1               1           7       56196   83  Linux
    /dev/sda2               8         373     2939895   83  Linux
    /dev/sda3             374         390      136552+  82  Linux swap
    /dev/sda4             391      121602   973629909    5  Extended
    /dev/sda5             391         764     3000000+  83  Linux
    /dev/sda6             764        1137     3000000+  83  Linux
    /dev/sda7            1137       63385   500000000+  83  Linux
    /dev/sda8           63385      121602   467629781+  83  Linux
    


    それぞれ、
    sda1:/boot
    sda2:玄箱PRO用純正HDDrootfs
    sda3:swap
    sda5:lenny (armel)
    sda6:etch
    sda7:未定。ファイルサーバ用?
    sda8:未定。ファイルサーバ用?

    という感じになっています。

    debootstrapでカーネルビルド用ユーザーランドを用意する

    debootstrapを利用して玄箱PROにdebianをインストールするわけですが、大雑把な手順としては、
    1. Kernelビルド環境を用意する。(etch oabi)
    2. 新しいカーネル(eabi)を作る
    3. 新しいカーネルでlenny (armel)の環境を作る
    という形になります。

    全部EABIなdebianを作るにはlennyをインストールする必要があり、lennyをインストールするには、玄箱PROに初めから入っているカーネル(2.6.12)よりも新しいカーネル(EABI)が必要で、玄箱PRO用にEABIを有効にしたカーネルを作るにはgccは4.1あたりがいいらしい?ということで、etch,lenny(armel)の二つのユーザーランドをdebootstrapで作ります。

    参考:lennyではカーネルのビルドが上手くいかないらしい件について。
    Jun's Homepage 玄箱PROでNTFSを使う
    OABIなlenny arm環境なら純正カーネルでもchrootできるんですが、カーネルの作成にはetchのgcc(4.1.1)を使ったほうがよさそうなので、カーネルのビルド用の環境はEtchにすることにしました。
    debootstrapを利用するにあたって、私はあらかじめdebianをインストールしてあるコンピュータを使いました。玄箱PROのHDD開発環境上に、debootstrap等のソースを持ってきてmakeすることもできるようですが、まあ、今回はこういう方法で。

    普通のPC(Debian Linux)上からdebootsrapを動かしますが、いきなりEABI対応のarmを作っても、玄箱PRO純正カーネルでこの環境にchrootしようとすると、
    FATAL: kernel too old
    などと表示されてしまいます。EABI関係での問題なのか、バージョンの問題なのか……
    arm(OABI)のlennyのユーザーランドを作ってみたところ、chroot可能だったんですが。

    そんなわけで、純正カーネルでlenny-armelを動かしたことはありません。まず、etch(当然OABI)を作ってそこで新しいカーネルを作ることになります。

    #apt-get install debootstrap
    #mkdir lenny-armel
    #debootstrap --arch armel --foreign lenny lenny-armel/ http://ftp.jp.debian.org/debian
    #cd lenny-armel/
    #tar czf ../lenny-armel-rootfs.tar.gz ./*
    # cd ../


    玄箱PRO純正の環境ではbzip2は入ってないので、gzipで圧縮しました。
    作成されたアーカイブは70MBくらいだと思います。同時にetchも作ります。
    #mkdir etch-arm
    #debootstrap --arch arm --foreign etch etch-arm/ http://ftp.jp.debian.org/debian
    #cd etch-arm/
    #tar czf ../etch-arm-rootfs.tar.gz ./*


    これを目的の環境下で展開します。
    #mount /dev/sda6 /mnt/hdd1
    #cd /mnt/hdd1/
    #tar xzf etch-arm-rootfs.tar.gz


    arm等、他のプラットフォーム用の環境を入れる場合、この手順で出来るたものはやっとファイルシステム中を動き回れる程度の最低限の環境です。viとかも動かせません。入手したパッケージのほとんどをまだインストールされていない状態のようです。

    そのため、玄箱PRO上で、次のようにする必要があります。
    #chroot /mnt/hdd1/
    #/debootstrap/debootstrap --second-stage


    これで、debootstrapによるインストールが完了し、一応の形はできあがります。
    その他、デバイス用のファイルを作るため、
    #cd /dev/
    #MAKEDEV generic


    apt-getを使うため、/etc/apt/source.listを
    deb http://cdn.debian.or.jp/debian etch main contrib non-free
    deb http://security.debian.org etch/updates main contrib non-free
    #以下、ソースファイルを使う場合
    deb-src http://cdn.debian.or.jp/debian etch main contrib non-free
    deb-src http://security.debian.org etch/updates main contrib non-free


    のように書き換えます。 Debian GNU/Linux スレッドテンプレ

    http://cdn.debian.or.jp/debian もしくはhttp://ftp.jp.debian.org/debian で、適切なミラーサイトを選んでつないでくれるようですが、他のミラーサイトはこちら http://www.debian.or.jp/using/mirror.html#mirrorlist

    dists/etch/Releaseを参照しなければならないので、産総研サーバの場合、
    deb http://aist.ring.gr.jp/pub/linux/debian/debian etch main contrib non-free
    と書くことになります。(実際にアクセスしてみて、dists/が見えるところまで)


    その他標準的なプログラムを一度に入れてしまう場合は、
    #tasksel install standard


    を実行します。

    この環境にはchrootで入ってカーネルを作るだけなので、ブートする際に必要な設定などは行いませんでした。lenny(armel)もetchと同じようにしてプログラムのインストールを行いましたが、こちらについてはリモートからログインするため等、様々な設定を行いました。
    それらの設定についてはカーネルコンパイル後のdebian環境への移行
    で。



  • カーネルのセルフコンパイル、クロスコンパイル

  • セルフコンパイルは玄箱PRO上で行いますが、etchの環境に入り込んで行います。
    時間はおよそ1時間半。
    クロスコンパイルはpentium4 2GHzのDebian etch上で行いました。時間は15分くらい。

    少々話はずれますが、カーネルコンパイルについてはオライリーのこの本が分かりやすかったです。
    Linux カーネル クイックリファレンス 2520円


    2.6系のカーネルをビルドする方法について書かれています。
    もちろん、玄箱PROについては書いてないですが。

    カーネルの仕組みとかが書いてあるプログラマー(開発者)向けの解説書、もしくはOSって何?みたいな科学読み物的なものではなく、ソースを入手し、そのままメイクするくらいの人(ユーザーやサーバー管理者)のために書かれた本なのでしょう。大変実用的だと思いました。
    実用的な分、人によって有用性は変わってきますが……
    ターゲットはどのあたりでしょうね。前半を読めばLinuxに触り始めたくらいの人からカーネルの作り方を学ぶことができます。ある程度の技術を持った人には得るものが少ないかもしれませんが、後半(というか、こっちが7割以上を占めるに書かれたmake時,起動時などに指定するオプション、configurationメニューの解説などには新しい発見があるかもしれません。英語がスラスラ読めて、コンピュータ用語に習熟している人ならば、ネット上やカーネルと一緒に配布されるドキュメント、コンフィギュレーション時のヘルプなどで用が足りてしまうのかもしれません。結局は、そのくらいの事しか書かれていないとも言えます。

    しかし、英語圏の人ならまだしも、日本人にとって、まとまった情報が得ることは結構困難です。ネットや雑誌なんかでもそのとき必要なもの(最適と考えられるもの)についてしか紹介されていませんし、コマンド、オプションの意味については簡単な説明がついていればいい程度の、おまじないみたいなコマンドが並んでいるのが大半だと思います。
    私も、kernel.orgで配布されているパッチの使い方がわかった他、configurationで必要なもの、不要なものを見分けるのに訳に立っています。


    ・セルフ、クロス共通部分

    セルフ、クロスどちらで作るにしても必要な準備を書いておきます。
    ・ソースファイル
    まず、ソースを入手します。
    Linux Kernel Archive

    日本のミラーはこちら。10倍くらい速い。……こともある。
    Kernel.orgミラー(奈良先端技術大学院大学?)

    このページを作成時、一番新しいものは2.6.28だったので、それをビルドしました。

    ・玄箱PRO用のパッチ
    2.6.25から、玄箱PROへのコードが公式に導入され始まっているらしいです。
    私がビルドして使ってみているかぎりでは、利用するべきパッチは、もうバージョンをごまかすためのものだけで十分のように思います。多分。

    force_mach-type.patch
    リンクが見つからなくなった場合は、左のDownloadから、上のファイルへのリンクを参考に探してください。
    http://buffalo.nas-central.org/wiki/Main_Page

    ・mkimageの入手
    u-boot用のカーネルイメージ"uImage"を作るには、玄箱PROのCDROMに入っている、u-bootのアーカイブの中にあるmkimageを使って作るのが簡単らしいです。(手動でも変換できたかもしれない)。
    u-bootのmkimage
    きままなWebLog on 玄箱Pro : 玄箱Proのカーネル再構築

    セルフ、クロスのいずれであっても、このソースから実用可能なmkimageのバイナリが作成できると思います。作成したバイナリは/usr/local/bin/あたりにコピーして使います。


    ・カーネルのセルフコンパイル

    ここからは、入手したカーネルのアーカイブと、パッチファイルをchroot環境下の/home/[一般user]/に保存したものとして、コンパイルの手順を示します。

    debootstrapで作った環境では、かなり少ないパッケージしか入らないらしいので、
    apt-get install gcc make libc6-dev libncurses5-dev
    


    でカーネルを作るためのコンパイラ等を入手する必要があります。libncurses5-devは、kernelのコンフィギュレーションをmenuconfigで行う際に必要になります。
    #chroot /mnt/hdd1
    #su user
    $cd /home/user
    $tar xjf linux-2.6.28.tar.bz2
    $cd linux-2.6.28/
    $patch -p1 <../force_match-type.patch
    $make orion5x_defconfig
    $make menuconfig
    $make
    $make uImage
    $exit
    #make modules_install
    #cd /lib/modules/
    #tar czf modules-armel-2.6.28.tar.gz 2.6.28/
    chrootするときはrootユーザーですが……
    Kernelのビルドを一般ユーザーで行うため、suで一般ユーザーに化けます
    一般ユーザーのホームディレクトリにカーネル、パッチが置いてあるものとし
    ユーザーのホームディレクトリでカーネルのソースを展開
    bzip2がなければapt-get install bzip2

    configファイルはarch/arm/config/orion5x……で。
    menuconfigで少しだけ修正。要libncurses5-dev
    この作業は一般ユーザーで行うのがきまりらしい。
    u-boot用のイメージを作る 要mkimage(u-boot.src.tar.gzからmake)
    一般ユーザーはここまで
    モジュールをインストールする
    モジュールがあるディレクトリに移動し、
    実際に使う環境へ運ぶため、アーカイブを作成。


    configファイルはarch/arm/config/以下に多数ありますが、CPUに合わせてorion5x_defconfigを利用します。
    他にも、hackkit_defconfigとかも入ってますね。
    menuconfigでは、キーボードの矢印のキーとENTER、spaceキーで操作します。
    System Type>Orion Implementations >
    を選ぶと、対応しているいくつかのシステムが表示されます。
    ここでは"KuroBox Pro"だけで十分だと思うので、他のオプションを無効にします

    カーネルイメージ、モジュールのアーカイブを作り終えたらchroot 環境から抜け、作ったカーネルイメージを/boot(sda1)に置く。名前はとりあえずuImageのままで。
    モジュールは/lib/modulesにを展開する。
    その後シリアルコンソールに接続して、

    setenv kernel uImage

    とすれば、この直後に起動するカーネルは/boot/uImageになります。
    玄人志向純正のユーザーランドで問題なく起動しました。

    nvramで書き換える、または新しく作ったカーネルの名前をuImage.buffaloにするなどしてカーネルの入れ替えを行う方法もあります。
    シリアルコンソールを使わず手軽にできますが。起動に失敗した場合、もともとのカーネルを起動できなくなる危険もあります。

    しかし、HDDを取り出して/bootのパーティション(50MBほどのext3領域、多分hdb1とかsda1とか表示される。詳しくはfdisk -lを実行)をマウントして、カーネルのファイル名を書き直す等すればなんとかなるかもしれません。
    私の場合、SATAを読み込める装置が玄箱PRO以外には一つもないので、ちゃんとマウントできるか確認できませんが……

    カーネルの置き場所(/boot)はXFS(EABI)ではないので、ちゃんと読めるでしょう。
    玄箱PROでHDDブート環境を作ったときにフォーマットしたHDDの場合、sda2,sda4あたりのXFS(EABI)のパーティションを、そこらのLinuxのXFS(OABI)でマウントしてしまうと、二度と正しくマウントできなくなる可能性があるので注意が必要です


    以前どこかで「armCPUで使っていたファイルサーバのXFSが壊れた。他のLinuxPCから読もうとしたけど無理だった。ファイルシステムも壊れたらしい」
    という記録を読んだ気がしますが、見つけられない。
    xfs_repair
    を実行すれば、ジャーナルを一時消去するらしいので、これを利用してなんとかできないものでしょうか?(後で実験予定)

    wikipedia xfs Wikipedia XFS
    LinuxでXFSファイルシステムを利用するヒントト

    ・クロスコンパイル


    上でも一度述べたとおり、gccは4.1あたりがいいらしいです。
    codesourceryでいうと、2006q3-27 あたりでしょうか。

    Codesourcery:各リリースへのリンク
    2006q3-27

    targetはARM GNU Linux
    Linuxが動いているパソコンでクロスコンパイルする場合、Platform はIA32 GNU/Linuxで作りました。cygwinなどで作る場合、IA32 windowsを選びます。
    入手したファイルを/optに展開してみたところ、arm-2006q3というディレクトリができ、その下にbin/、lib/等がありました。
    カーネルをビルドする際には、/opt/arm-2006q3/bin/と/opt/arm-2006q3/lib/へのパスを追加する必要があります。
    $tar xjf linux-2.6.28.tar.bz2
    $cd linux-2.6.28/
    $patch -p1 <../force_match-type.patch
    $export PATH=$PATH:/opt/arm-2006q3/bin:/opt/arm-2006q3/lib
    $make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- orion5x_defconfig
    $make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- menuconfig
    make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- 
    $make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- uImage 
    $make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- INSTALL_MOD_PATH=dir_modules modules_install
    $cd dir_modules/lib/modules/
    $tar czf modules-armel-2.6.28.tar.gz 2.6.28/
    


    defconfig以降は何度もやり直したりしたので、
    #!/bin/sh
    export PATH=$PATH:/opt/arm-2006q3/bin:/opt/arm-2006q3/lib &&
    make clean &&
    make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- menuconfig &&
    make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- &&
    make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- uImage &&
    make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- INSTALL_MOD_PATH=dir_modules modules_install 
    exit 0
    


    こんな感じのシェルスクリプトで実行しました。コマンドを忘れたり間違えたりしないで済みそうです。
    dir_modules/以下にモジュールがインストールされるので、それをアーカイブにして目的の環境の/lib/modules/以下にインストールします。

    参考URL
    狐の王国 Debianのapt-crossでクロスコンパイル環境を作り、玄箱カーネルをビルドしてみる
    TechStorm.org [玄箱PRO]カーネル構築


  • debian環境への移行
  • ちゃんと動く2.6.28のカーネルが出来上がったら、lenny(armel)の環境にchrootします。上でetchの開発環境を作成したときと同じようにdebootstrapのsecondstageを完了させ、その後下の設定を行いました。一通り設定が終わったらrebootし、シリアルコンソールでユーザーランドをlenny armelをインストールしたパーティションに設定しなおします。
    setenv bootargs console=ttyS0,115200 root=/dev/sda5 rw panic=5 BOOTVER=1.09 
    setenv kernel uImage
    


    上手く動くまで(ちゃんと起動してファイルシステムをマウントしてネットワークにつながってtelnetで接続できるまで)設定の修正を繰り返しました。

    上手くbootするようになったら、そこで一端rebootし、設定をフラッシュに書き込みます。printenvで書き込む内容に間違いがないことを確認した上で、saveenvで書き込みます。
    setenv bootargs console=ttyS0,115200 root=/dev/sda5 rw panic=5 BOOTVER=1.09 
    setenv kernel uImage
    printenv
    saveenv
    



    以下、ログインするために行ったた設定等を。
    telnetは使う人、使わない人で分かれると思いますが、私はローカルエリアからしかログインしないので、telnetで十分です。
    ・シリアルコンソールで入るための準備 /etc/securettyにttyS0,ttyS1を追加。
    デバイスファイルを作る
    #mount proc -t proc /proc
    #cd /dev
    #MAKEDEV ttyS0
    #MAKEDEV ttyS1
    #umount proc

    /etc/inittabの編集
    # Note that on most Debian systems tty7 is used by the X Window System,
    # so if you want to add more getty's go ahead but skip tty7 if you run X.
    #
    #1:2345:respawn:/sbin/getty 38400 tty1
    #2:23:respawn:/sbin/getty 38400 tty2
    #3:23:respawn:/sbin/getty 38400 tty3
    #4:23:respawn:/sbin/getty 38400 tty4
    #5:23:respawn:/sbin/getty 38400 tty5
    #6:23:respawn:/sbin/getty 38400 tty6

    # Example how to put a getty on a serial line (for a terminal)
    #
    T0:12345:respawn:/sbin/getty -L ttyS0 115200 vt100
    #T1:23:respawn:/sbin/getty -L ttyS1 9600 vt100

    赤字部分を追加もしくは変更しました。


    起動時
    Id "1" respawning too fast: disabled for 5 minutes
    Id "2" respawning too fast: disabled for 5 minutes
    Id "3" respawning too fast: disabled for 5 minutes
    Id "4" respawning too fast: disabled for 5 minutes
    Id "5" respawning too fast: disabled for 5 minutes
    Id "6" respawning too fast: disabled for 5 minutes

    みたいなものが出てきていました。telnetするとき必要なのでは?と思って最初は消さなかったものの、消しても大丈夫なようです。
    pts/2とかでログインしてます。

    ・電源まわりを管理する、miconaplのクローン的なものを入れる。
    Jun's Homepage miconapl互換コマンドの作成
    サイトからダウンロードできるバイナリはOABIで作られているので、EABIで使う場合はmakeし直す必要あり。
    EABIなら純正のmiconaplを使えるのかもしれないけど、ライブラリとか気にしないで使えるので上のファイルのほうがお勧め。

    現在、しばらく(時に15分、時に数時間)するとps ax で

    /usr/local/bin/miconapl -a int_get_switch_status

    という電源、リセットスイッチを監視する際のコマンドが表示された状態になります。
    この状態では、他のmiconaplを用いたコマンドを全て弾いてしまいます。元々配布されているものと違うところといったら、EABI環境下で作り直したバイナリであるということくらいです。それで、EABI環境下で使っています。
    このコマンドは5秒に一度くらいの頻度で実行されているものなので、再現性はある程度低いのでしょう……
    しかし、一度こうなってしまうと解除できないので、一晩経ってみるとかなりの高確率でひっかかってしまっているのが現状です。

    一旦排他ロックを解除できれば、とりあえずコマンドを受け付けない問題は解決しそうです。いえ、ゾンビプロセスが大量発生しそうな状況なので、それは解決ではなさそうな気もします。停止している理由をちゃんと見つける必要があるかもしれません。
    今は時間が無いので、また後で挑戦予定……


    ・telnetdを入れる
    #apt-get install telnetd
    #vi /etc/inetd.conf
    ###########################
    #:STANDARD: These are standard services.
    telnet          stream  tcp     nowait  root    /usr/sbin/tcpd  in.telnetd


    ローカルエリアからのログインを許可する
    /etc/hosts.allow
    ALL     :       192.168.11.0/255.255.255.0
    ALL     :       127.0.0.1


    他は拒否
    /etc/hosts.deny
    ALL:ALL


    ・ルートのパスワード+ログインするためのユーザーを作成する。
    chrootした状態でpasswdと打てば、そのユーザーランドでのルートのパスワードを設定することができます。
    また、普通telnetではrootでログインすることはできないようになっているので、adduserでユーザーを作り、パスワードを決めておく。
    useraddでユーザーを作った場合は、passwd [ユーザー名]でパスワードを設定するのを忘れずに。

    ・timezoneの設定
    玄箱Proセットアップその3 ≪ 突然消失するかもしれないブログ
    「日本(Japan)」ではなく「東京(Tokyo)」で設定するようです。

    ・NFSをアンインストールする?
    このようにしてDebootstrap(+tasksel install standard?)で作った環境では、起動、終了処理にやたら時間を食います。
    どうやらNFS、portmapによるもののようで、これらは現在使う予定がないためアンインストールもしくは起動プロセスから消去しました。

    > ・network/interfacesの設定

    auto eth0 lo
     iface eth0 inet static
         address 192.168.11.64
         network 192.168.11.0
         netmask 255.255.255.0
         broadcast 192.168.11.255
         gateway 192.168.11.1
    
    iface lo inet loopback


    ……こんな感じでしょうか。

  • 玄箱PRO(arm)+PostfixでOP25B対策

  • 2年ほどまえにやった時のページもあるんですが、不要な情報が多く含まれています。
    SMTP認証によるOP25の回避については、Postfixのソースファイルに含まれるドキュメント、README_FILES/SASL_READMEを読めばいいようです。

    ……日本語訳版もありました。
    Postfix.jp 和訳ドキュメント SASL_README クライアントとしてのSASL認証の利用

    以下、SASL_READMEに従ってPostfixの設定を行っていきます。


    対応しているのは、

    * Cyrus SASL version 1 (client and server).
    * Cyrus SASL version 2 (client and server).
    * Dovecot protocol version 1 (server only, Postfix version 2.3 and later)

    ……ということらしいです。
    2007年に玄箱で認証させたときのページには、Devcotでもできるかもと書いていましたが、Devcotはサーバー用途にしか使えないようです。
    OP25Bを回避するためのSASL認証は、サーバーにアクセスしていく側の"クライアント"としての動作なので、こちらの目的につかうためにはCyrusを使う必要があるようです。
    cyrusによる認証をするためのビルド方法とか書かれてますが、
    ver2.3以降のPostfixには、そのPostfixのバイナリがCyrusもしくはDevcotに対応しているかどうかを調べるコマンドが用意されているようです。

        % postconf -a (SASL support in the SMTP server)
        % postconf -A (SASL support in the SMTP+LMTP client)
    


    使ってみますと、
    KURO-BOX:/# postconf -a
    cyrus
    dovecot
    KURO-BOX:/# postconf -A
    cyrus
    


    Debianでは、etch,lenny(armel)どちらで入手したバイナリでもSASLに対応していました。そういうわけで、現在debianからapt-getしたpostfixを使う人は、SASL認証のために各自がコンパイルし直す必要はないようです。
    プロバイダのサーバーに対して認証を行う(クライアントとして利用する)だけならば、cyrus関連のプログラムをインストールする必要は一切ないのかもしれません。(私は今回、cyrus2.2-devあたりをapt-getでインストールしてしまいましたが、多分必要ありませんでした。)

    比較のため、saslを考慮せずmakeしたバイナリでも試してみましたが、その場合は"-a"、"-A"のオプションでは何の反応も得られないようです。

    KURO-BOX:/# postconf -a
    KURO-BOX:/# postconf -A
    KURO-BOX:/#
    


    なお、ソースから作った場合、postconfはPostfix-2.5.5/bin/以下に作成されています。インストールしてみなくても、作成されたこのバイナリを動かしてみればそれで答えが得られます。
    #Postfix-2.5.5/bin/postconf -A

    smtp認証クライアントとして動かす場合には、以下のような設定を追加します。

    /etc/postfix/main.cf
    smtp_sasl_auth_enable = yes
    smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
    smtp_sasl_type = cyrus
    relayhost = [mail.myisp.net]
    # relayhost = [mail.myisp.net]:submission
    smtp_sasl_security_options = noanonymous
    


    relayhostのところをより具体的に書くと、
    relayhost = smtp.mail.yahoo.co.jp
    


    のようになると思います。
    コメントアウトされている
    # relayhost = [mail.myisp.net]:submission
    という部分は、587番のサブミッションポートを使って認証したい場合に使うための行です。サブミッションポートを使わない場合は、コメントアウトを外してください。
    最後の行"smtp_sasl_security_options = noanonymous"は、本来のSASL認証には必要では無い部分らしいです。
    デフォルトの設定では、SASL認証を行う際に平文を送信してしまうことがないように制御されて動くよう作られているようです。そのため、暗号化した通信をサポートしていないサーバに対し、暗号化したユーザー名、パスワードだけを送信した場合、次のようなメッセージを受け取ることになるだろうと述べています。
    Authentication failed: cannot SASL authenticate to server" ("認証失敗: サーバへの SASL 認証ができません")。
    


    このエラーを回避するために書き加えるのが最後の行の設定なのだそうです。
    YahooBBも、認証には暗号化されたパスワードは受け付けていないので、この設定を書き加える必要があります。

    次に、認証に用いるパスワードを記載したファイルを作成します。ここでは、ファイル名はsasl_passwdで、/etc/postfix/に置きます。
        /etc/postfix/sasl_passwd
            [mail.myisp.net]            username:password
            [mail.myisp.net]:submission username:password
    


    "submission"はport587を利用するときに必要な記述設定になります。
    より具体的な例を出せば、
    メールアドレスがakiyama@yahoo.co.jp、パスワードegcombatfinalだった場合、
    smtpサーバ名 ユーザーID:password

    という書き方なので、
    smtp.mail.yahoo.co.jp akiyama:egcombatfinal

    と書くことになります。 これをpostfixが読み込める状態にする必要があります。 #postmap /etc/postfix/sasl_passwd で、sasl_passwd.dbというファイルが作られます。 このdbファイルは、プロセスを開始する際に初めに読んでしまうので、持ち主をpostfixなどにする必要もなく、rootユーザーだけが読み書き可能なようにしておくことが推奨されています。
    chown root.root sasl_passwd*
    chmod 600 sasl_passwd*
    


    また、"smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd" の行については、環境によってはhashではなくdbmとするべきかもしれないという注意書きがありました。 どちらかを判別するためには、cyrusに対応しているか同様、postconfを使うようです。

    #postconf -m

    sargeで、2年前に自分で作ったバイナリ
    KURO-BOX:/# postconf -m
    btree
    cidr
    environ
    hash
    nis
    proxy
    regexp
    static
    unix
    


    etch,lenny(armel)でapt-getしたPostfix
    KUROBOX-PRO:/# postconf -m
    btree
    cidr
    environ
    hash
    nis
    proxy
    regexp
    sdbm
    static
    tcp
    unix
    

    sdbmあたりもhashの代わりに出来るのかもしれません。

    上のように設定してPostfixを再起動してみたところ、ちゃんと認証することができました。
    2007年に作ったページ内にある設定のほとんど(saslauthの設定、起動等)はサーバー用途でのものだったようです。……そもそも、smtpdと書いてるのは全部サーバ用途ですよね。考えてみれば。


  • プロバイダのサーバ以外で認証する(sasl認証 +submission port)

    2007年ごろ作ったページでは、「ヤフーのサーバにヤフーのIDで認証すると、送信されたメールのヘッダにヤフーのメールアドレスが入っている」と書いておきました。
    ヤフーに契約して作ったIDでヤフオクなどもやっている場合、メールアドレスからヤフオク内での活動を知られてしまうことが不都合だったりすることもあるかもしれません。
    そして、新しくヤフーのアドレスを作り直してもそのアドレスでは認証できなかったように思います。

    こちらのサイトを見てみると、なんとヤフー(もしくは契約プロバイダ)に認証しなくても、どこか別のプロバイダのサーバをリレーすれば、メールを送信することができるらしいです。

    玄箱 postfix gmail yahoobb

    私も、gmailを使って設定を行ってみました。

    /etc/postfix/main.cf
    smtp_sasl_auth_enable = yes
    smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
    smtp_sasl_type = cyrus
    relayhost = smtp.gmail.com:submission
    smtp_sasl_security_options = noanonymous
    smtp_use_tls = yes
    


    上の, 自身の契約しているプロバイダ経由(この場合ではyahooBB)で送信する場合と比較すると、黄色で示した部分を変更し、赤字の所を追加してあります。 他のプロバイダに送るため、submission portを使用することを宣言する必要があります。submission portを使わなかった場合、ログに次のようなエラーがありました。
    KUROBOX-PRO postfix/smtp[1441]: connect to smtp.gmail.com[209.85 .201.109]:25: No route to host

    認証用ファイル(sasl_passwd)のほうには、submissionを書き入れなくてもメールを送信可能でした。また、submissionではなく、ポート番号(587)を書いても良いようです。

    また、gmailのサーバにアクセスする際、tlsを使用するようです。(smtp_use_tls=yesを追加)

    tlsをoffにした場合(smtp_use_tls = yes を書かなかった場合)。
    host smtp.gmail.com[209.85.201.111] said: 530
    5.7.0 Must issue a STARTTLS command first


    しかし、これでは送信者にgmailのアドレスが入ってしまいます。(relay送信というものは、そもそもこういうものなのかもしれませんが)
    gmailのアドレスへのメールをあまり確認しない場合や、gmailのアドレスではなく自宅サーバのメールアドレスに返信して欲しい場合などは、この方法は適していないかもしれません。


  • apache2のパーミッションで悩んだ件

  • Apache(1)を使っていましたが、lennyでapt-getできるのはApache2しかありませんでした。
    apache2を入れ、CGIを使えるように設定しようとしたのですが、Apaceh2ではhttpd.confが空なんですね。
    ユーザーはここに好き勝手に書き入れてよさそうです。
    apache2が直接読み込むファイルは/etc/apache2/apache2.confになりますが、このファイルの中に、httpd.confとその他の設定ファイルもIncludeするよう記述されています。

    httpd.confに、cgi用の設定を記述しました。
    <Directory /var/www/cgi-bin>
    Options +ExecCGI
    AddHandler cgi-script .cgi .pl
    </Directory>


    パーミッションは
    cgi605
    pl604
    html604
    ディレクトリ601


    とかでしょうか。
    このあたりをちゃんとやってても、うまくいかないことが何度かありました。
    permision denied とか、CGI自身が「書き込みができないじょうたいです」と返してきたり。
    ログの中には、「ExecCGI is off in this directory」とかあるから、設定がちゃんと読まれてないんじゃないか……とかapacheを疑ってみたり。

    結局、私が間違えていた部分は、パーミッションを与えている相手(ファイルの持ち主)の設定でした。
    user root , group rootとかだったりしました
    これをapacheのプロセスを起動してるユーザーに代えれば上手くいきました
    ユーザーは/etc/apache/httpd.confか apache2では……debianではいくつかに設定ファイルが分けられていますが、/etc/apache2/envvarsあたりに書いてあります。
    apache httpd.conf
    # If you wish apache to run as a different user or group, you must run
    # apacheas root initially and it will switch.
    #
    # User/Group: The name (or #number) of the user/group to run apache as.
    #  . On SCO (ODT 3) use "User nouser" and "Group nogroup".
    #  . On HPUX you may not be able to use shared memory as nobody, and the
    #    suggested workaround is to create a user www and use that user.
    #  NOTE that some kernels refuse to setgid(Group) or semctl(IPC_SET)
    #  when the value of (unsigned)Group is above 60000;
    #  don't use Group nobody on these systems!
    #
    User www-data
    Group www-data
    



    apache2 envvars
    export APACHE_RUN_USER=www-data
    export APACHE_RUN_GROUP=www-data
    export APACHE_PID_FILE=/var/run/apache2.pid



    というわけで、正常に動作させるために、cgi関連のファイルとフォルダの持ち主を変更しました。
    #chmod www-data.www-data /var/www/cgi-bin/*


    とかそんな感じでひとつ。
    CGI自身が返していたエラーというのも、ファイルが新しく(apacheによって)生成されるディレクトリの所有者がrootだったものだから、「そのフォルダに新しくファイルを作れない」みたいな理由でエラーをだしていたようでした。

    2009年1月5日作成
    戻る