困ったときはログファイル

Cubieboard2 (Arm7 Cortex Dual core 1GHz, 1GByte Ram, 4GByte Flash, OS=armhf debian 7) という、約60ドルで中国から購入したデベロッパーボードを使って運営しているホームサーバーの管理にISPConfig3という管理ソフトを導入して使用している。 Mailサーバー、Webサーバー、DNSそしてnginxプロキシなどをWEBブラウザから一括管理できるので重宝している。
このツール、HowtoForgeというサイトでサポートされていて、”Perfect Server” というシリーズで多様な組み合わせのサーバー設定のチュートリアルが掲載されている。 たとえばこの記事はOSはDebian,サーバープロキシにnginx, mailにはDoveCot、DNSにはBindを使ったサーバー構築の手順が述べられており、実は自分のサーバーはこれを参考にして立ち上げた。(DNSとNGINX、PHP、MySQLの部分はともかく、メールサーバーとメールフィルターの設定は自分ひとりの能力では手も足も出なかった。きちんと設定できたのは上の記事のおかげである)
 最近バージョンのアップデートをしようと思い立ち、コントロールパネルに指示されているiSPsonfig-update.shというコマンドを実行してみた。  アップデート自体はまったく問題なく行えたのだが、 コントロールパネルにログインしようとしてみたところいつもログイン画面が出るはずのurlが空っぽのページになっている。 
他のサービス(メール、Webサイト、DNS、SSHなど)は普通に動いているので、IPSConfigのダッシュボードへのログインが表示できないという限定された不具合だ。 幸いなことにISPConfigのUpdateツールがまず実行するのは旧バージョンのバックアップなので最悪の場合はリストアを行えばよいが、ページのヘッダー情報を見てみると、エラー番号が500、Internal Server Errorとなっているので、これはPHPの実行時、ページレンダリングの途中でおかしくなっている、とあたりをつけた。 NginxのErrorLogを眺めてみると大当たり、Fatal Errorが記録されていた。

11:54:25 [error] 3452#0: *528 FastCGI sent in stderr: "PHP message: PHP Warning:  require_once(/usr/local/ispconfig/interface/lib/config.inc.php): failed to open stream: Permission denied in /usr/local/ispconfig/interface/web/index.php on line 31
PHP message: PHP Fatal error:  require_once(): Failed opening required '../lib/config.inc.php' (include_path='.:/usr/share/php:/usr/share/pear') in /usr/local/ispconfig/interface/web/index.php on line 31" while reading response header from upstream,云々

上のエラーメッセージはindex.phpの31行目config.inc.phpを読み込もうとしたところ、拒否されました。と言っている。 ../libr/config.inc.phpのアクセスレベルがきつすぎるようだ、。
そこでこのファイルを調べてみるとOwner,GroupともISPCONFIGとなっているのは良いとして、Ownerのみに読み書き権限があたえられており、Groupレベルで読み書き禁止となっている。  それではと、Groupレベルでの読み出しも許可に書き換えてみたところ、あっさりと復活した。

#  chmod g+r config.inc.php

これが普通とは思わない。何らかの理由でサーバーのワーカープロセスとファイルのオーナー情報が背反しているためにファイルアクセスできなくなっていると考える。 少し思い当たることがあって、同じサーバー内部でModxを使ったサイトを運営しているのだが、アップデートするたびにSetupフォルダーをマニュアルで削除しなくてはならない、という作業が発生している。 Setupフォルダーの削除はインストール画面でチェックをいれてやれば自動的に行ってくれるはずなのだが、このサーバーではそれができてない。

というわけで、本日わかったこと。
1. Linuxのアクセスレベル管理がいまいち理解できてないなあ。
2. Linux 不具合解析はまずError Logを読む事。

Raspberry Pi、SD カードのアクセス速度と, カード破損の原因について

表題の件。自分はなんとなく、SDカードのアクセス速度はハードディスクのアクセス速度よりも早いのだ、と思っていたのだが、これは実は大変な思い違いだった。 思い込んでいた理由は、機械部品に読み書きするより、半導体のほうに読み書きするほうが早いのだろうと単純に考えていたのだが、どうも違うらしい。 SDカードの構造が関係しているようだが、同じカードでも初期のSDカードと現在普通に売っているSDHCでももちろん差がある。 それでもハードディスクのスピードにはかなわないのだ、という。
ちなみに Raspberry Piとlinux のddコマンドを使ってカードのアクセスの速度を簡易的に測ってみた報告が
このサイトに載っていたので、同じ方法で、今回自分のパイに使ったTranscend の8GBカードのアクセス速度を測ってみたら、15.7MB/Sと出た.

root@raspi1:/home/pi# time dd if=/dev/zero of=./ddfile bs=8k count=20000 && sync
20000+0 records in
20000+0 records out
163840000 bytes (164 MB) copied, 10.4644 s, 15.7 MB/s

real	0m10.657s
user	0m0.080s
sys	0m2.400s

(ここで使っているddというコマンドはパラメーターの使い方を間違えるとハードディスクの中身が綺麗になくなってしまったり、こわれてしまったりする、というlinux killerとも言われる至極危険なコマンドなので、ご注意を。自分でやってみてファイルシステムの中身が蒸発したと文句を言われても責任を持てません。)
クラス10のカードなので保証最低速度が10MB/Sだからこんなものか。 上記のサイトの結果と比較しても同じくらいのスピードだ。
サイトの情報を眺めていると、SDカードが破損する、という報告が多数見られるのは、SDカードのメモリー構造が激しい書き換えで摩耗してしまう結果だから、一度SDカードからブートしたら、OSはUSBスティックのメモリー上で動作したほうがよい、というように書いてあるブログが結構ある。 SDカードでダメならUSBのフラッシュカードだって同じだろうと思うのだが真偽のほどは分からない。上のサイトでもUSBのサムドライブで動作させた場合のアクセス速度を測っているが、SDカードの約半分以下のスピード。測ったメモリースティックがSandisk 16GB Cruiser、一部のサイトで言っているようなスピードが改善した、というような結果にはなっていない。 他にも個人のブログでやはりスピードに改善はない、という報告がある一方、 早くなり、かつ動作が安定した、と言っているサイトには具体的な数値が出ていない。 一方、USB経由でHDDに接続した場合は速度向上の効果が得られそうだ。。 

ただ、興味をそそられる部分があって、それはOSのカーネルの立ち上がりからの処理は、USBに接続されたデバイスから実行することができる、SDカード上に必要なのは/bootフォルダに置かれたファイルのみ、と説明されているところで、つまりはSDカードに展開される2GBの実装イメージのうち、本当にSDカード側において置かなければならない部分はFATのパティションの部分のみ、ファイルサイズで言うと20メガバイトにも満たない、ということが判った。オリジナルの2GBのイメージはパティションが二つあり、一つは56メガバイトのFAT、もうひとつは(2GB-56MBの)Linuxのファイルシステムになっている。 この起動の途中からUSBデバイスを使う方法の説明はこのサイトに載っている記事がわかりやすいが、自分の場合、キーボードがダメになって放ってあったHPmini というネットブックに16GBのSSDが入っていたのでこれを取り出し、昔notebookのハードディスクのゴースティングをするために買ってあったUSBのSATA/PATA Enclosure に入れ込んで、Raspbian のイメージをコピーし、gpartedを使ってパティションをディスク容量分まで拡大。 SDカードのほうは、昔のカメラかなにかに使っていたと思われる東芝の256MBのSDカードを普通のPCでフォーマットしたのちにSSDのFATpatition の部分のファイルをすべてコピーし、 その中からcmdline.txt に書かれている /dev/blk0p2というブートデバイス指示を/dev/sda2と書き換え それぞれRPiに接続して準備完了。電源を入れてみれば256MBのSDカードから 見事に立ち上がった。

この状態で、SSDの読み書き速度を調べて見れば、
16GB SSD salvaged from HP mini notebook (ca. 2009) connected through SATA-USB enclosure.

root@raspi1:~# time dd if=/dev/zero of=./ddfile bs=8k count=20000 && sync
20000+0 records in
20000+0 records out
163840000 bytes (164 MB) copied, 3.83869 s, 42.7 MB/s

real	0m3.858s
user	0m0.050s
sys	0m2.380s

この42.7MB/S というのは、上記のサイトで報告されている、HDDの読み書き速度とほぼ同程度。 それでもSDHCのほぼ3倍の早さがでている。 SSDも半導体ドライブだが、こちらはHDDよりも早い、という宣伝文句で高くても皆文句を言わず買っているわけなので、もっと早くてもよさそうなものだが、290ドルのネットブックに付属してきたものなので、高性能を期待するのが無理か。 そもそもUSB2 の公称最高速が60MB/Sで、そのうち10~15%はオーバーヘッドというこどなので、50MB/SくらいでUSBのほうが飽和するから、そちらの影響かも。 どちらにしても消費電力は低いはず。

ちなみに256MB のSDカードのほうは、さすがに古いだけあって、 ご覧のとおり、たったの2MB/S。 つまりクラス2のカードで、RPiの要求仕様であるクラス4をも満たしていないが問題なく起動する。この使い方では書き込むことはなく読み込み専用. すぐにコントロールがUSB側のstorageに移るのでよしとしておく。
256BM SD card from old digital camera

root@raspi1:/boot# time dd if=/dev/zero of=./ddfile bs=8k count=20000 && sync
20000+0 records in0
20000+0 records out
163840000 bytes (164 MB) copied, 77.1608 s, 2.1 MB/s

real	1m17.178s
user	0m0.030s
sys	0m2.620s

SDカードの破損の原因だが、
1)電源のパワーが足りない。必要とされる700ミリアンペア以上を供給できない電源を使っていてうまく書き込むことができない。
2)SDカードが書き込まれている最中にカードを抜いてしまう。
などが、主原因であり、read/writeの回数が許容回数を上回ってしまうのだ、という議論は説得力が薄い、と個人的には感じている。 (今のセットアップで問題が起きれば考え直すかもしれない)
(追記:どうも初期のファームウエアにも問題があったようだ。firmware-update、raspberry piでググってみてほしい。)
RPiにパワースイッチがあれば2の問題は防げるのだが、コストカットの観点からスイッチはついていない。American Piとも揶揄されるbeaglebone black($45)にはしっかりついており、確実にパワーダウンできるのに比べると見劣りする。 ただ単に電源を接続するだけではなく、まずはシステムをシャットダウンしてのちに電源を落とす必要があるのだが、これを実現させるためのRPi用のパワースイッチは3rd Partyからいくつか発売されており(1)(2)、これを買い求めれば良いだけの話ではある。

Rpi , 256MB SD card and USB/Sata I/F with 16GB SDD.  8GBSD is now retired
Rpi , 256MB SD card and USB/Sata I/F with 16GB SDD.  8GBSD is now retired

Windows Share をLinux (ubuntu)側から(常時)みれらるようにする方法

Windows Share をLinux (ubuntu)側から(常時)みれらるようにする方法

Windows側からLinux Server 側のファイルを見る方法、というのはいくらでも方法が書いてあるのだが、その逆をやろうとするとあまり無い、いや、あるのだけれど、あっちに少し、こっちに少し。
というわけで。
Ubuntu Wikiに書いてあったのでそれをもとにやってみた。 ターゲットはUbuntu 10.4

Windows のファイルシステムを読み書きするためのsmbfsは導入済みと思ったが念のために

$ sudo apt-get install smbfs

案の定、何もアップデートされなかった。

次に、etc/hosts に以下の 一行を追加

192.168.1.99 mybooklive

セールのときにうっかり購入してしまった、1テラバイトのネットワークHDを前もって固定アドレスで設定済み

ローカルファイルシステムに取り込むために /media にフォルダーを追加

$ sudo mkdir /media/Public

Public Share は パスワードがついてない。 誰でもアクセスできる

etc/fstab ファイルに以下を追加

//mybooklive/Public /media/Public cifs guest,uid=1000,iocharset=utf8,codepage=unicode,unicode 0 0

で、ファイルシステムをマウントしなおす。

$ sudo mount -a

これで/media/Public 経由で 1テラバイトがアクセスできるようになった。

ちなみにパスワードが必要な場合のアクセスは

//servername/sharename /media/mountname cifs username=myusername,password=mypassword 0 0

とすれば、よいのだが etc/fstab は誰でも読めてしまう、ということで、 別ファイルを参照する方法が推奨されている

//servername/sharename /media/mountname cifs exec,credentials=/etc/cifspw 0 0

これで password file cifspw を作るわけだが、中身は
userid=ここにログインネーム
password=ここにパスワード

だけを記入しておく

ファイルをのぞき見されないようにプロテクト

$ sudo chmod 600 /etc/cifspw

やっぱり最後は

$sudo mount -a