仕切り直して、ラズパイ1Bで 共有サーバーの構築(1/)

  1. 現状の環境確認と作業方針の検討
  2. 最新 raspbian の最小構成を 4GB の SD へ導入
  3. USBハードディスクの組込みと最低限の設定作業と立上げ確認

ラズパイ3で運用していた ホーム内共有サーバーが停止してから長い時間が経ちました。有れば自然で無意識に利用できていた環境も、不便ながらも何とかなっているわけで、がむしゃらに復旧させる気もなく今日に至っています。

それには頭の中で何かが引っかかっているようなしっくりしない物を感じていて、それがずっと気になっているために積極的になれなかったことが大きいと思います。その前から利用していたサーバーは、何年もの長期に渡りずっと安定して利用していました。今でも立ち上げたままになっていて動作は今でも継続しています。

でも何でそのサーバーが一線から退いたかというと、古いDebian OS で稼働していて、セキュリティアップデートは対象外になっています。一時はWebの公開用サーバーとして稼働していて、利用している期間も長かったのですが、ipv6で動作させられない決定的な問題をはらんでいました。ただ、ハード構成がRAID1のミラーで、2.5インチハードディスクで構成されていて信頼性が高いのが利点でした。ゆくゆくは最新のDebian OS に置き換えられればとの願いがあります。

そこで代替として、公開用Webサーバーには、Pogoplug E02 アメリカ仕様のピンク色の機種に、Debian OS を入れて稼働させました。昔の写真を見ると 2011.06 頃に奮闘していたことが記録にあって懐かしいです。このサーバーは、当然ですが ipv6 でも動作しています。非力で遅いですが今でもセキュリティアップデートが継続して行えて現役で稼働しています。

それと並行して共有サーバーの代替としてセットアップされたのが、ラズパイ3 だったのですが、勝手にセルフアップデートして立ち上がらなくなってしまったわけです。その中でも軽微な何度かは修復できたのですが、最後のアッフ゜デートが行われた時は大幅に変更されたらしく、修正が手に負えず、初期からのセットアップに至ったわけです。

その後の最初からのセットアップでも dd コマンドに依るコピー問題に起因する障害が見付かり、あまりにも信頼出来ないと判断するに至りました。共有サーバーには不要なデスクトップ環境に起因して問題が発生しているような気がするので、今回は最小構成で作成されている Raspbian の最新版を利用し、以前稼働していてしばらくお蔵入りだった古く非力なラズパイ1 B を現役復帰させることにしました。

ラズパイも注目を浴びるようになってからの進化が著しく、古い昔の機種を見ると当初はこんな作りだったのかと驚きます。何せ microSD ではなく、フルサイズの SD カードが使われていて、USBポートも 2個しか無く、IOポートも 26ピンしかありません。単なる共有サーバーやバックアップサーバーの用途だけなら IOポートに何かを繋ぐ必要もなく特に問題ないでしょう。

セットアップは、4GB の SD に /boot パーティションと、システム本体が含まれる / パーティションの 2ファイルが含まれる単純なもので、NOOBS を利用しないで直接書き込みます。

ここからの操作は、 Linux がインストールされている作業用のパソコン上で操作しています。

Raspberry pi のサイトから raspbian の最小構成をダウンロードして、チェックサムを確認して解凍しました。

$ cat /home/sunao/download/2017-09-07-raspbian-stretch-lite.zip | shasum -a 256
bd2c04b94154c9804cc1f3069d15e984c927b750056dd86b9d86a0ad4be97f12  -
$ unzip /home/sunao/download/2017-09-07-raspbian-stretch-lite.zip
Archive:  /home/sunao/download/2017-09-07-raspbian-stretch-lite.zip
inflating: 2017-09-07-raspbian-stretch-lite.img

そのままメディアに dd しても構わないと思いますが、オプション conv=fsync を追加して一旦ファイルに書き出しました。

$ dd if=2017-09-07-raspbian-stretch-lite.img of=raspbian-chg-lite.img conv=fsync

$ sudo dd if=/home/sunao/raspbian-chg-lite.img of=/dev/mmcblk0 bs=1024
1811124+0 レコード入力
1811124+0 レコード出力
1854590976 bytes (1.9 GB, 1.7 GiB) copied, 834.275 s, 2.2 MB/s

それをメディア SD にそのまま dd コピーして、ラズパイ1 B に挿入しました。後は初期立上げ動作のためにキーボード、マウス、テレビモニタ用HDMIケーブルネットワーク用のUTPケーブル拡張USBハブの追加です。本来はマウスを利用することもないので不要ですが一応取付けました。USBハブも初期の立上げだけなら必要がないのですが、USBハードディスクを取付けて運用させることを考えているので、ラズパイ本体とハードディスクの電源供給用に利用します。

ここからはシステムメディアを挿入して、周辺機器を接続したラズパイの立上げです。

電源投入すると、モニタに文字列が流れるように表示されて、しばらくするとログインプロンプトで入力待ちになります。初期ユーザーが pi で、パスワードが raspberry になっているのでそのままログインします。

最新の状態にするために aptコマンドを使います。更新対象のモジュールは少なかったのですが、ラズパイのラインナップ毎に対応させたデバイスドライバ等のDTBファイルが多数あるらしく、それを移動するのか削除しているのか不明ですが、その操作で大きな時間を使っているようでした。

そして、raspi-config を立上げて、タイムゾーンロケーションキーボードの設定等の目に付く項目の設定を一通り行い、リモート操作のために ssh を有効にする変更を加えてから再起動しました。

何と期待していた再起動が出来ずに、電源の赤いLEDの点灯だけになってしまいました。

早速SDを作業用のノートパソコンに移して確認すると、IOエラーが出ているようで、その後システムの再書込も行えない状況でした。容量の小さなSDメディアを無理やり利用しているので、オーバーフローしたのかとも思いましたが、うぅ〜ん〜よくわかりません。

$ sudo fdisk -l /dev/mmcblk0
fdisk: /dev/mmcblk0 を open できません: 入力/出力エラーです
$ sudo dd if=raspbian-chg-lite.img of=/dev/mmcblk0 conv=fsync bs=1024
dd: '/dev/mmcblk0' の書き込みエラー: 入力/出力エラーです
1+0 レコード入力
0+0 レコード出力
0 bytes copied, 0.0197685 s, 0.0 kB/s

メディアの不良とか原因は色々と考えられますが、フルサイズSDと言っても、microSDにアダプタを使っているだけなので、接触している接点が沢山あって接触不良も一原因としては考えられます。抜き差しして触っていると正常にマウントされることもあり、Raspbian システムの再書込も無事に出来ました。メディアは、Kingston 4GB microSD ですが、気になるので別のアダプタに変更してフルサイズSDにしてみました。

$ sudo dd if=/home/sunao/raspbian-chg-lite.img of=/dev/mmcblk0 bs=1024
1811124+0 レコード入力
1811124+0 レコード出力
1854590976 bytes (1.9 GB, 1.7 GiB) copied, 1043.24 s, 1.8 MB/s

初期立上げ状態のシステムメディアが欲しいので、再びラズパイの操作です。

SDメディアをラズパイに挿入して、単純な立上げとシャットダウンだけを実行して直後のメディアを取り出します。

これからはメディアを作業用のパソコンに戻しての作業です。

一応保険として初期立上げ後のシステムメディアをバックアップしておきます。1度立上げると自動的に初期化作業としてメディア一杯にパーティションが拡張されるようです。

$ sudo dd if=/dev/mmcblk0 of=/home/sunao/raspbian-chg-lite-run.img bs=1024
3776512+0 レコード入力
3776512+0 レコード出力
3867148288 bytes (3.9 GB, 3.6 GiB) copied, 367.543 s, 10.5 MB/s

セットアップする作業は障害で中断しても同じことの繰り返しになりますが、最終的にはルートファイルシステムが USBハードディスクになるわけで、あまり信用していないSDメディアなので早めに移行することを考えました。SD内のルートファイルシステム mmcblk0p2 をハードディスク(作業時は /dev/sdb2) にコピーして、それからゆっくり考えながらセットアップを始めることにします。

まずは、ルートファイルシステムのコピーと、立上げ後にルートとしてマウントされるように、 /etc/fstab を書き換えます。

$ sudo su -
# mount /dev/sdb2 /mnt/sdb2
# mount /dev/mmcblk0p2 /mnt/work
# rsync -a /mnt/work/ /mnt/sdb2/
# vi /mnt/sdb2/etc/fstab
proc /proc proc defaults 0 0
PARTUUID=3c158d9c-01 /boot vfat defaults 0 2
/dev/sda2 / ext4 defaults,noatime 0 1
# a swapfile is not a swap partition, no line here
# use dphys-swapfile swap[on|off] for that
~  
# umount /mnt/work

USBハードディスクから読み込ませるには、もうひとつの書き換えが必要で、SDメディアのブート情報 cmdline.txt を書き換えます。

# mount /dev/mmcblk0p1 /mnt/work
# ls /mnt/work
COPYING.linux           bcm2708-rpi-b.dtb    bootcode.bin  fixup_db.dat  overlays
LICENCE.broadcom        bcm2708-rpi-cm.dtb   cmdline.txt   fixup_x.dat   start.elf
LICENSE.oracle          bcm2709-rpi-2-b.dtb  config.txt    issue.txt     start_cd.elf
bcm2708-rpi-0-w.dtb     bcm2710-rpi-3-b.dtb  fixup.dat     kernel.img    start_db.elf
bcm2708-rpi-b-plus.dtb  bcm2710-rpi-cm3.dtb  fixup_cd.dat  kernel7.img   start_x.elf

# vi /mnt/work/cmdline.txt

dwc_otg.lpm_enable=0 console=serial0,115200 console=tty1 root=/dev/sda2 rootfstype=ext4 elevator=deadline fsck.repair=yes rootwait

# umount /mnt/work

実は一度 SDメディアと USBハードディスクをラズパイに取付けて、起動させたらモニタに二行の表示が行われただけで進行が停止してしまいました。

原因は単純ミスでした。作業しているノートパソコンでは、2つ目のハードディスクになるので、該当パーティションが /dev/sdb2 として割り振られますが、ラズパイに装着した時の割り振りは、最初のハードディスクになるので当然ですが、 /dev/sda2 になります。頭が居眠りしているちょっと恥ずかしい笑っちゃうようなミスでした。

ここからは、いよいよラズパイでの本格的な作業になります。

ラズパイの電源投入で無事に立上げ出来ましたので、先にも書いている sudo apt update / sudo apt upgrade で、最新版への更新と sudo raspi-config による各種環境設定の変更を行いました。この中でsshの有効化を行っています。そしてロケールの変更により直接のコンソール作業では文字化けになりますが、sshによるリモート作業では文字化けもありえないので、こちらで作業を続けたいと思います。

$ sudo apt update
   .... 更新対象のモジュールがリストされます

$ sudo apt -y upgrade
   .... リストされた対象が順次更新されます

勝手に壊される raspbian

Raspberry pi は、Linuxシステムが壊れてしまう不安定なシステムとの認識を発売当初から持っています。最近では一般にSDとの相性問題と言われているような、SDに問題が有りそうだとのメーカー名と製品をリストにした情報が公開されています。

当初は問題を切り分けできる情報も少なく、ある程度実用になる設定を施した頃になると、必ず水を挿すようにシステム障害になっていて、再びやり直しとなって時間ばっかり掛かるだけで使えませんでした。

そんなわけで、Raspberry pi は、ブートの初期には必ず SD や microSD を必要とするので、その後にマウントされるルートシステム以降の処理をUSBハードディスクに移行する方法で安定したシステムとして稼働させていました。

ルートシステムをハードディスクに移行してからは、Raspberry pi 1 B+ や Rasberry pi 2 B を純粋なサーバーとして利用していましたが、特に問題なく稼働していて、時々手動でシステムの update を実行していました。

でも何故か壊れる Raspberry pi 3 B です。こちらはデスクトップ環境で構築していて、特には利用していませんでしたが、付属として3.5インチLCDディスプレイとタッチパネルが装着されています。そして家屋内の共有ディスクとして利用して、データのバックアップシステムとしても利用していた重要なシステムでした。

問題のシステムが動作不能になったのは、ハードディスク障害等の明確なものを除くと、設置から今までの1年足らずで大きく数えて 2回あります。2回共に自動でシステム更新されたらしく、sshでネットログインが出来ず、再起動しても期待した立上げが行われませんでした。

ただし、1度目は大きく変更されていたわけではないようで、ルートファイルシステムとしてのUSBディスクが無効に変更されていたのが 原因で、ほぼその修正だけで立上げが行えました。ただし、デスクトップ画面は別物として一新して見た目は大きく変わっていました。

2度目の今回は、システムが勝手に大きく更新されているようで、前回のように簡単に修復が出来ませんでした。Raspberry pi は、頻繁にシステム構成が変わっているようなので、安定稼働を期待するサーバーの運用には向いていないのかと思ってしまいます。

何故か時々壊れる(壊される?) Raspberry pi 3 ですが、正常に運用していたシステムが動作不能になると、今までに色々とインストールしているモジュールやら設定が問題になります。

微かな期待として、何とかリカバリして上手く復旧が出来て、そのまま利用の継続ができればベストなのですが、今回はping での反応はしていたものの ssh 接続は出来ず、共有ディスクとしてのサービスも機能してなくて、ログ情報を定期的にメールとして送る機能も動作していませんでした。

電源OFF/ONによる再起動を試みたのですが、正常に立上がらないようで、仕方なくモニタ用にテレビをHDMI接続し、キーボードとマウスを繋いでの復旧を試みたのですが、見慣れない画面が出るだけで、Linuxで一般的な立上げバナーも皆無です。システムが大きく変更になったようでした。

ここまでの状況からは、システムの再インストールが必要な状況のようですが、そこで同じ程度の環境に戻すには、色々なモジュールのインストールや設定を再び施す必要があります。システムが正常に動作しているなら、dpkg -l のコマンドでインストールされたモジュールのリストが出るようです。しかし、再インストールしたら以前の情報は消去してしまいます。

立上げ不能のルートシステムを、別に立上げできる正常なシステムを利用して、そこに繋いで残された情報から調べる以外に無く、操作方法をネットの情報から調べ、 apt-get で操作した場合に残されるログから、インストール時に記録された情報を抽出することにします。

記録ファイルは、/var/log/dpkg…. で始まるファイル名で残されているようです。過去のものは圧縮されているようです。

/var/log/dpkg.log
/var/log/dpkg.log.1
/var/log/dpkg.log.xx.gz  … xx 部分が数字の圧縮ファイル

ざっとログ内容を見てみると、インストールしたモジュール名の抽出には、 grep -e  ‘ install ‘ が有効と思われます。指定する文字列は、 ‘install’ の両端を半角の空白で挟んで指定します。

再インストールと修復では、地道に稼働していた状態の最後の dpkg.log から突き合わせて元の状態に近づけようと考えてます。

まずは、ラズパイ3 の再インストールから作業を始めます。なんと1年前にも同様の書き込みがありました。