ラズパイで共有サーバー

前回で記述している初期のラズパイ1B+に、デスクトップ用のOS Raspbianをセットアップして、バッテリーバックアップモジュールと2.5インチHDDを組合せて、ネットワーク共有サーバーとして立上げます。

ラズパイも一気に普及したために、皆さんラズパイで色々な物を作っていますが、私には余裕がないので、昔から定番であるディスク容量に少し余裕を持たせたNASを作って、利用しようと思っています。

ディスク容量は 2TBです。割引で購入しましたが、安くなったものです。ラズパイの不満としてはディスクのIOインタフェースが、USBで少し遅く単体構成でRAID2のミラー化は無理っぽいですよね。

立上げのブートは仕方無く公開されている microSD ですが、システムとしてのルートパーティション以降はディスク内に配置して処理します。

ディスクはパーティション分割して、システムの置かれるルートパーティションは適度な大きさ30GBで、同様にスワップも適度に確保して、それ以外を300GB程度の複数に分割して、立上げ時に自動マウントしています。

NASとしてのデータをバックアップする方法としては、ディスクのミラーに代わる方法として、夜中から明方に毎日他のサーバーにコピーする方法で確保します。

初期システムとしては、デスクトップ用として立上げましたが、sshでリモート操作できるのを確認できてから、モニタのHDMIケーブル、キーボードとマウスのUSBケーブルを取り去りました。

今まで共有サーバーとして使用しているサーバーを継続で使用すれば、何も苦労は要らないと思うのですが、実は先日システムを構成しているケーブルに接触したらしく、システムがダウンしていて気が付かないまま数日置かれたことがありました。

そんな訳で、バッテリーバックアップを含めて安定したサーバーを作りたいと考えてます。新旧サーバー間でデータをコピーして置き換える準備をしています。

少し触れたり触っても停止しないように、ケースで覆う必要があり、安くて良さそうな物を百均セリエで見付けてきました。安っぽいですがこれで十分です。

バッテリーに電源供給するケーブルイーサネットケーブルの2本のケーブルだけが出ていて、バッテリーからの電源供給と遮断を行うマイクロスイッチにアクセスできる小さな穴を開けました。

ラズパイの進化は早くて凄い

何となくAmazonを見ていたら、ラズパイにバッテリーで供給できるキットが出ていたので購入しました。

ネット上には、そのキットに関する情報の公式ブログが立上げられているようで、ラズパイへの電源供給を制御できる小さなプッシュスイッチがあることもわかりました。

日本国内で最初に発売されたラズパイ1Bでは、ボード固定用のネジ穴位置がユニーク過ぎて、このキットとは親和性が良くないと思われるので、1B+と組合せて共有サーバーとして立上げることにしました。

ラズパイ公式OSのRaspbianの選択ですが、本家のページを見ると3種類あるようで、色々詰込んだデスクトップ用基本のデスクトップ用、サーバー用途だと思われる最小構成、過去にデスクトップ用では痛い経験があるものの、今回は基本のデスクトップ用で作ってみようと決めました。

2018-11-13 / 4.14 / Raspbian stretch with desktop です。ダウンロードして展開しながら、microSDに書込みました。作業はLinux上なので、パイプで繋いだ1行のコマンド例が出ていたので、それを参考に作業しました。

microSDラズパイ1B+に挿入して、バッテリー供給キットの充電が途中なのが、LEDランプの点滅位置でわかります。

ラズパイ1B+には、USBポートが4つあります。USB接続のマウスとキーボードを用意し接続して、HDMIケーブルをテレビのモニターに繋ぎ、バッテリー供給キットのスイッチでラズパイに電源供給しました。

立上りが遅いので心配にはなりますが、暫く待つとデスクトップ画面が表示され、そのまま見ていると勝手にダイアログが表示され、microSDの空き一杯にエリアを拡張しているようです。

その後も必要な設定が自動的に起動され、パスワード変更ロケーションの設定が行われました。久し振りに触れましたが凄い変化です。今迄の経験では日本語化で苦労していましたが、ちょっと選択をしただけで、日本語化が完了して、漢字入力もできてしまいました。

驚きの連続です。最後の安定までは時間が掛かりますが、アップデートも最新になっているし、時間も日本時間になっていて、再起動後の立上げ直後にも日本時間になっていて、セットアップの進化に感服しました。

久し振りにラズベリーパイ

いつかは忘れたけど、家のネットに共有サーバーとして立上げたラズパイ3Bが、安定稼働数カ月の後に勝手にシステムアップデートして、危篤になり脳死の植物状態になってしまいました。

サーバー用途に、デスクトップを含むフルセットのRaspbianで、セットアップしたのが悪かったのかと反省してます。

そのラズパイ3Bは、共有サーバーとして利用途中でも、何度か同様のアップデートが行われ、止まっても後から介入して、何度かは元気に立ち直らせていたのです。

最後の時は、思い付く色々な手を尽くしても駄目でした。それ以来、不安定なラズパイは実運用に向かないと考えて、そのラズパイ3Bを放置してました。

その後、仕方なく手持ちの初期の頃の古くて遅いラズパイ1Bに、最小構成のRaspbianを入れて共有サーバーとしてセットアップしました。

別な場所で、ラズパイ2Bに同じ最小構成のRaspbianを入れて、夜間に共有サーバーのデータを自動でバックアップするサーバーとして立上げました。

こちらは安定して動作しています。自動でシステムアップデートは行われませんが、時々思い出したように手動でアップデートしてます。対象のアップデートは全て適用してますが、今まで問題は起きていません。

初期の遅いラズパイでも、共有サーバーとして稼働しているだけなら何のストレスも感じません。外付けディスクから直接立上げる方法は公開されていないので、最初にSDmicroSDで立上げて、外付けディスクに移る方法で利用してます。

ネット共有サーバーとしてmp4の動画も入れて、スマホやパソコンから再生してますが、特に高画質の大きな動画ではないので、問題なく利用できています。

そうは言っても、初期のラズパイの1Bは、USBバスパワーで外付けディスクを稼働させるのは不可能で、セルフパワーのHUBや電源を必要とするため、色々と煩雑で100均のケースに入れてますが、近くの配置を変えていた時に触れたのかシステムダウンしてました。

そんな事もあり、ラズパイB+に、UPSとして利用できそうなバッテリーを含むオプションとかを組合せて、外付けディスクの容量も倍にして共有サーバーを置き換えようかと考えてます。

安定してた共有サーバーダウン

昨日たまたま sshで操作ついでに思い立ち、通常のセキュリティアップデートのつもりで久し振りのコマンド操作後にリブートしたら、安定して運用中の Raspberry Pi 1B の共有サーバーが死にました。
学習しないで同じ轍を踏むとは自分でも悲しいです。最新版の Raspbian は、要注意だという事を改めて再認識させられました。
他にも Raspberry Pi のサーバーが稼働していますが、少し前の Raspbian をセットアップしたサーバーなので、単純にセキュリティアップデートだけが行われたらしく、そのままに稼働しています。
以前のメモを頼りに復活させますが、最新のOSで作って良いのか悩みます。
頭を冷やして少し考えてから判断したいと思います。

ラズパイ1B で共有サーバーの構築 (5/)

  1. リモートメンテに必須の byobu / screen の設定
  2. いよいよ念願の共有サーバー samba の設定

キーボードもモニタも無いサーバーを操作するには、他のパソコンからのリモートメンテナンスが必須ですが、操作も並行して同時に別のコマンドを実行させたいことはよくあることです。素のままだと ssh 等を複数起動してセッションを張らないと出来ません。また長く掛かるコマンドの実行中にセッションが切れたり、クライアント側を停止するとサーバー側もエラーで停止します。
過去の記事でこれらについての対策方法として、仮想端末について触れているので、その部分を見直しながらコピーしておきます。
仮想端末と呼ばれるジャンルには、 byobu / tmux / screen と言ったソフトがあって、byobu は tmux や screen のラッパープログラムとして機能します。
何が便利かと言うと、 ssh 等で直接リモートログインした状態で、サーバー側のコマンドを利用して処理を行っている時に、何かの要因で通信路に障害が起きてセッションが切れると、実行中の処理も異常終了してしまいます。しかし、これらの仮想端末を利用して処理していると仮に通信路で障害が発生しても、再接続するだけで元の処理は継続して実行したままなので途中の経過表示も含めて元の続きを継続できます。
メリットを言い換えると、時間のかかる処理をリモートサーバー上で起動しておいて、操作するクライアント側では電源を落とす等の方法で接続を切ってしまい、時々接続して途中経過を確認したり、時間を置いてから最終結果の確認だけを行うことも可能になります。それと、複数の ssh 接続が必要なことも時としてありますが、例えば速度が遅く不安定なインターネットを経由した先のサーバー接続等を考えた場合には、直接の接続セッションは単一なのに、複数の仮想端末内で色々な処理を並行して実行できるのは安心感があります。
そんな訳で byobu を導入します。一般的に byobu は通常 tmux を伴って仕事をするのですが、私の場合は昔から screen を利用していた経緯があって、他に設置のサーバーでも byobu と screen の組合せで稼働しています。

$ ssh 192.168.11.21    .....クライアントからのssh接続要求
Linux rpi1-com2 4.9.59+ #1047 Sun Oct 29 11:47:10 GMT 2017 armv6l
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon Nov 20 20:26:12 2017 from 192.168.11.43
$ byobu      .....リモート接続されたラズパイで byobu を起動
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Welcome to the light, powerful, text window manager, Byobu.
You can toggle the launch of Byobu at login with:
'byobu-disable' and 'byobu-enable'
For tips, tricks, and more information, see:
* http://bit.ly/byobu-help
$
 
 
 
 
 
              ...... F6 キーの押下で byobu 終了 ⇒ 起動前に戻る
[detached (from session 1)]

実際のデフォルトで起動した byobu の画面は次のイメージです。 byobu+tmux の形式です。

そして byobu の裏で screen が動作するように変更します。

$ byobu-select-backend
Select the byobu backend:
1. tmux
2. screen
Choose 1-2 [1]: 2

これで screen と連携した byobu の設定が完了しました。
byobu+screen のイメージは次の画面です。操作した感じでは問題なさそうです。

これらの仮想端末ソフトには、コマンド入力を受付けるシェル画面、例えば bashの画面が表示されていますが、そのまま文字を入力する以外に、外枠としての仮想端末自体を制御するためのコマンド文字が存在します。例えば、新しくシェル画面を追加したり、並行処理している複数のシェル画面を切り替えたりします。その制御用の文字を、エスケープ文字と呼びますが、これを各サーバーで色々だと誤操作等の支障が出るので変更して統一しておきます。
エスケープ文字の変更は、byobu が起動している画面で F9 キーを押下するとメニューのダイアログが起動します。 screen との相性が悪いらしく、表示が崩れますが変更は出来るようです。変更した結果のファイルを確認すると文字列が追加されていました。

$ vi .byobu/keybindings
source $BYOBU_PREFIX/share/byobu/keybindings/common
bindkey "^B"
escape "^Bb"
register x "^B"
~

ただし、このままでは sshでリモートログインしても自動的に byobu は起動しないし、 byobu を終了しても sshでログインした状態のままになります。

$ byobu-enable
The Byobu window manager will be launched automatically at each text login.
To disable this behavior later, just run:
byobu-disable

これでクライアントからの ssh リモート接続でセッションが確立すると、自動的に byobu が起動して、過去に操作していたなら以前の状態の継続になります。リモートでの操作を終えるために F6 キーによる終了で、 ssh によるリモート接続も自動的に切断します。
byobu の操作は、新規に仮想端末を追加で開くには F2 キー、別画面に移動するには、左回り右回りで F3 / F4 キーで行います。
これで仮想端末 byobu の設定は完了です。



 

ラズパイ1B で共有サーバーの構築 (4/)

  1. bind9 DNSサーバーの設定
  2. postfix メール配送の設定

ここからは、インストールしたままで設定がまだの機能を順次設定していきます。
まずは DNS 機能の設定から、セットアップ中のラズパイ内に DNS 機能を設定し、家の中に置かれたローカル機器を名前からアクセスできるように試みます。これには既に稼働しているサーバーの設定をコピーして、誤りがないか確認しながら必要なら内容の見直しを行います。

# ls -l /etc/bind
合計 64
-rw-r--r-- 1 root bind  964 11月 13 23:53 2400:yyy:zz:df00::.rev
-rw-r--r-- 1 root root 3923  8月 28 16:36 bind.keys
-rw-r--r-- 1 root root  237  8月 28 16:36 db.0
-rw-r--r-- 1 root bind  787 11月 14 00:09 db.xx.168.192
-rw-r--r-- 1 root root  271  8月 28 16:36 db.127
-rw-r--r-- 1 root root  237  8月 28 16:36 db.255
-rw-r--r-- 1 root root  353  8月 28 16:36 db.empty
-rw-r--r-- 1 root root  270  8月 28 16:36 db.local
-rw-r--r-- 1 root root 3171  8月 28 16:36 db.root
-rw-r--r-- 1 root bind 2155 11月 14 00:02 db.sunao-mita.pgw.jp
-rw-r--r-- 1 root bind  463  8月 28 16:36 named.conf
-rw-r--r-- 1 root bind  490  8月 28 16:36 named.conf.default-zones
-rw-r--r-- 1 root bind  481 11月 13 23:29 named.conf.local
-rw-r--r-- 1 root bind 1074 11月 13 23:41 named.conf.options
-rw-r----- 1 bind bind   77 11月 13 21:55 rndc.key
-rw-r--r-- 1 root root 1317  8月 28 16:36 zones.rfc1918

ローカル機器を設定した IPアドレスの対応ファイル db.sunao-mita.pgw.jp と逆引き用のファイル 2400:yyy:zz:df00::.rev と db.xx.168.192 内容の概略を次に示します。内容は xyzn の文字で適当に置き換えているため実物とは異なります。こんなイメージとして載せています。

# cat /etc/bind/db.sunao-mita.pgw.jp
;;  sunao-mita.pgw.jp
$TTL    86400
@      IN      SOA    sunao-mita.pgw.jp.  root.sunao-mita.pgw.jp. (
        2017111301      ;Serial
        3600            ;Refresh
        900             ;Retry
        604800          ;Expire
        86400           ;Minimum TTL
)
                IN      NS      dns.sunao-mita.pgw.jp.
                IN      NS      dns2.sunao-mita.pgw.jp.
                IN      NS      gate.sunao-mita.pgw.jp.
                IN      MX      10 mail.sunao-mita.pgw.jp.
                IN      A       192.168.xx.22
                IN      AAAA    2400:yyy:zz:df00:225:31ff:fe00:nn
dns2            IN      A       192.168.xx.21
dns             IN      A       192.168.xx.22
net-disk        IN      A       192.168.xx.23
gate            IN      A       192.168.xx.1
DebianPogo      IN      A       192.168.xx.22
DebianPogo      IN      AAAA    2400:yyy:zz:df00:225:31ff:fe00:nn
mail            IN      A       192.168.xx.22
mail            IN      AAAA    2400:yyy:zz:df00:225:31ff:fe00:nn
PogoV6          IN      AAAA    2400:yyy:zz:df00:225:31ff:fe00:nn
dns2            IN      AAAA    2400:yyy:zz:df00:ff57:63d2:5835:nn
dns             IN      AAAA    2400:yyy:zz:df00:225:31ff:fe00:nn
www             IN      A       192.168.xx.22
www             IN      AAAA    2400:yyy:zz:df00:225:31ff:fe00:nn
RadioV6         IN      AAAA    2400:yyy:zz:df00:ba27:ebff:feac:nn
rpi1-com2       IN      A       192.168.xx.21
rpi1-com2       IN      AAAA    2400:yyy:zz:df00:ff57:63d2:5835:nn
ls              IN      CNAME   net-disk
share           IN      CNAME   rpi1-com2

# cat /etc/bind/2400:yyy:zz:df00::.rev
$TTL 86400
@            IN      SOA sunao-mita.pgw.jp. root.sunao-mita.pgw.jp. (
                     2017111301 ; serial
                     3600       ; refresh 1hr
                     900        ; retry 15min
                     604800     ; expire 1w
                     86400      ; min 24hr
)
        IN      NS      dns.sunao-mita.pgw.jp.
        IN      NS      dns2.sunao-mita.pgw.jp.
n.n.d.9.0.0.e.f.f.f.1.3.5.2.2.0    IN   PTR   PogoV6.sunao-mita.pgw.jp.
n.n.d.9.0.0.e.f.f.f.1.3.5.2.2.0    IN   PTR   dns.sunao-mita.pgw.jp.
n.n.d.9.0.0.e.f.f.f.1.3.5.2.2.0    IN   PTR   sunao-mita.pgw.jp.
n.n.b.d.e.e.e.f.f.f.b.e.7.2.a.b    IN   PTR   raspv6.sunao-mita.pgw.jp.
n.n.8.2.5.3.8.5.2.d.3.6.7.5.f.f    IN   PTR   dns2.sunao-mita.pgw.jp.
n.n.8.2.c.a.e.f.f.f.b.e.7.2.a.b    IN   PTR   RadioV6.sunao-mita.pgw.jp.
n.n.3.2.6.a.d.3.8.f.f.0.0.6.6.b    IN   PTR   Rpi3-com1.sunao-mita.pgw.jp.
n.n.8.2.5.3.8.5.2.d.3.6.7.5.f.f    IN   PTR   rpi1-com2.sunao-mita.pgw.jp.

# cat /etc/bind/db.xx.168.192
$TTL 86400
xx.168.192.in-addr.arpa. IN SOA sunao-mita.pgw.jp. root.sunao-mita.pgw.jp. (
        2017111301       ;Serial
        7200    ;Refresh
        3600    ;Retry
        604800  ;Expire
        86400   ;Minimum TTL
)
        IN      NS      dns.sunao-mita.pgw.jp.
        IN      NS      dns2.sunao-mita.pgw.jp.
n0      IN      PTR     landisk.sunao-mita.pgw.jp.
2n      IN      PTR     net-disk.sunao-mita.pgw.jp.
1       IN      PTR     gate.sunao-mita.pgw.jp.
n1      IN      PTR     rpi1-com2.sunao-mita.pgw.jp.
nn      IN      PTR     radio.sunao-mita.pgw.jp.
2n      IN      PTR     DebianPogo.sunao-mita.pgw.jp.
2n      IN      PTR     sunao-mita.pgw.jp.
n4      IN      PTR     Rpi3-com1.sunao-mita.pgw.jp.

それらの設定を有効にするため、named.conf.local に設定を追加します。

# vi /etc/bind/named.conf.local
//
// Do any local configuration here
//
zone "sunao-mita.pgw.jp" {
type master;
file "/etc/bind/db.sunao-mita.pgw.jp";
};
zone "xx.168.192.in-addr.arpa" {
type master;
file "/etc/bind/db.xx.168.192";
};
zone "0.0.f.d.z.z.z.z.y.y.y.y.0.0.4.2.ip6.arpa." {
type master;
file "/etc/bind/2400:yyyy:zzzz:df00::.rev";
};

// Consider adding the 1918 zones here, if they are not used in your
// organization
include "/etc/bind/zones.rfc1918";

起動して無事に立上がれば、アドレスを引いて期待した結果が返るか確認します。

# service bind9 start

確認には、digコマンドで、自分自身のサーバー @localhost を指定して、外部のサーバー www.nifty.com や内部の sunao-mita.pgw.jp を引いてみたり、逆引きの ipv4 / ipv6 の IPアドレスから引いてみます。

# dig @localhost www.nifty.com  ...外部のサーバーを引いてみる
; <<>> DiG 9.10.3-P4-Raspbian <<>> @localhost www.nifty.com
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48086
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 1
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;www.nifty.com.                 IN      A
;; ANSWER SECTION:
www.nifty.com.          300     IN      A       121.94.174.14
;; AUTHORITY SECTION:
www.nifty.com.          299     IN      NS      cdns0.nifty.ad.jp.
www.nifty.com.          299     IN      NS      cdns1.nifty.ad.jp.
;; Query time: 1574 msec
;; SERVER: ::1#53(::1)
;; WHEN: Tue Nov 14 10:27:56 JST 2017
;; MSG SIZE  rcvd: 109

# dig @localhost sunao-mita.pgw.jp    ...内部のローカルサーバー
; <<>> DiG 9.10.3-P4-Raspbian <<>> @localhost sunao-mita.pgw.jp
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 48474
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 6
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;sunao-mita.pgw.jp.             IN      A
;; ANSWER SECTION:
sunao-mita.pgw.jp.      86400   IN      A       192.168.xx.22
;; AUTHORITY SECTION:
sunao-mita.pgw.jp.      86400   IN      NS      dns.sunao-mita.pgw.jp.
sunao-mita.pgw.jp.      86400   IN      NS      gate.sunao-mita.pgw.jp.
sunao-mita.pgw.jp.      86400   IN      NS      dns2.sunao-mita.pgw.jp.
;; ADDITIONAL SECTION:
dns.sunao-mita.pgw.jp.  86400   IN      A       192.168.xx.22
dns.sunao-mita.pgw.jp.  86400   IN      AAAA    2400:yyy:zz:df00:225:31ff:fe00:nn
dns2.sunao-mita.pgw.jp. 86400   IN      A       192.168.xx.21
dns2.sunao-mita.pgw.jp. 86400   IN      AAAA    2400:yyy:5140:df00:ff57:63d2:5835:2889
gate.sunao-mita.pgw.jp. 86400   IN      A       192.168.xx.1
;; Query time: 2 msec
;; SERVER: ::1#53(::1)
;; WHEN: Tue Nov 14 10:28:22 JST 2017
;; MSG SIZE  rcvd: 222
# dig @localhost -x 192.168.xx.21    ...内部サーバーの逆引き
; <<>> DiG 9.10.3-P4-Raspbian <<>> @localhost -x 192.168.11.21
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35385
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 2, ADDITIONAL: 5
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;21.xx.168.192.in-addr.arpa.    IN      PTR
;; ANSWER SECTION:
21.xx.168.192.in-addr.arpa. 86400 IN    PTR     rpi1-com2.sunao-mita.pgw.jp.
;; AUTHORITY SECTION:
xx.168.192.in-addr.arpa. 86400  IN      NS      dns.sunao-mita.pgw.jp.
xx.168.192.in-addr.arpa. 86400  IN      NS      dns2.sunao-mita.pgw.jp.
;; ADDITIONAL SECTION:
dns.sunao-mita.pgw.jp.  86400   IN      A       192.168.xx.22
dns.sunao-mita.pgw.jp.  86400   IN      AAAA    2400:yyy:zz:df00:225:31ff:fe00:nn
dns2.sunao-mita.pgw.jp. 86400   IN      A       192.168.xx.21
dns2.sunao-mita.pgw.jp. 86400   IN      AAAA    2400:yyy:zz:df00:ff57:63d2:5835:nn
;; Query time: 2 msec
;; SERVER: ::1#53(::1)
;; WHEN: Tue Nov 14 10:29:13 JST 2017
;; MSG SIZE  rcvd: 221

# dig @localhost -x 2400:yyy:zz:df00:ff57:63d2:5835:nn ...ipv6逆引き
; <<>> DiG 9.10.3-P4-Raspbian <<>> @localhost -x 2400:yyy:zz:df00:ff57:63d2:5835:nn
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 57012
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 2, ADDITIONAL: 5
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;n.n.8.2.5.3.8.5.2.d.3.6.7.5.f.f.0.0.f.d.z.z.1.5.y.y.y.2.0.0.4.2.ip6.arpa. IN PTR
;; ANSWER SECTION:
n.n.8.2.5.3.8.5.2.d.3.6.7.5.f.f.0.0.f.d.z.z.1.5.y.y.y.2.0.0.4.2.ip6.arpa. 86400 IN PTR rpi1-com2.sunao-mita.pgw.jp.
n.n.8.2.5.3.8.5.2.d.3.6.7.5.f.f.0.0.f.d.z.z.1.5.y.y.y.2.0.0.4.2.ip6.arpa. 86400 IN PTR dns2.sunao-mita.pgw.jp.

;; AUTHORITY SECTION:
n.n.f.d.z.z.1.5.y.y.y.2.0.0.4.2.ip6.arpa. 86400 IN NS dns.sunao-mita.pgw.jp.
n.n.f.d.z.z.1.5.y.y.y.2.0.0.4.2.ip6.arpa. 86400 IN NS dns2.sunao-mita.pgw.jp.
;; ADDITIONAL SECTION:
dns.sunao-mita.pgw.jp.  86400   IN      A       192.168.xx.22
dns.sunao-mita.pgw.jp.  86400   IN      AAAA    2400:yyy:zz:df00:225:31ff:fe00:nn
dns2.sunao-mita.pgw.jp. 86400   IN      A       192.168.xx.21
dns2.sunao-mita.pgw.jp. 86400   IN      AAAA    2400:yyy:zz:df00:ff57:63d2:5835:nn
;; Query time: 2 msec
;; SERVER: ::1#53(::1)
;; WHEN: Tue Nov 14 10:29:53 JST 2017
;; MSG SIZE  rcvd: 281
# dig @localhost rpi1-com2.sunao-mita.pgw.jp  ...ローカルサーバー
; <<>> DiG 9.10.3-P4-Raspbian <<>> @localhost rpi1-com2.sunao-mita.pgw.jp
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16729
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 6
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;rpi1-com2.sunao-mita.pgw.jp.   IN      A
;; ANSWER SECTION:
rpi1-com2.sunao-mita.pgw.jp. 86400 IN   A       192.168.xx.21
;; AUTHORITY SECTION:
sunao-mita.pgw.jp.      86400   IN      NS      dns.sunao-mita.pgw.jp.
sunao-mita.pgw.jp.      86400   IN      NS      gate.sunao-mita.pgw.jp.
sunao-mita.pgw.jp.      86400   IN      NS      dns2.sunao-mita.pgw.jp.
;; ADDITIONAL SECTION:
dns.sunao-mita.pgw.jp.  86400   IN      A       192.168.xx.22
dns.sunao-mita.pgw.jp.  86400   IN      AAAA    2400:yyy:zz:df00:225:31ff:fe00:nn
dns2.sunao-mita.pgw.jp. 86400   IN      A       192.168.xx.21
dns2.sunao-mita.pgw.jp. 86400   IN      AAAA    2400:yyy:zz:df00:ff57:63d2:5835:nn
gate.sunao-mita.pgw.jp. 86400   IN      A       192.168.xx.1
;; Query time: 2 msec
;; SERVER: ::1#53(::1)
;; WHEN: Tue Nov 14 10:50:53 JST 2017
;; MSG SIZE  rcvd: 232

設定の記述方法に関しては全く自信がないので、まぐれというか引けてラッキーといった感じです。検索実行のサーバー指定に @localhost ですが、 ;; SERVER: ::1#53(::1)  となっていて ipv6アドレスになっているのですね。一応引けるということで次の設定に移ります。



次は色々なレポートをメール経由で上げてくれる postfix 必須のメール転送エージェント機能です。これも既に動作している設定をコピーして利用しようと思います。
とりあえず nifty にメール転送させるための認証ファイルと main.cf をコピーして内容の見直しが必要です。それと、動作検証には mailコマンドを利用するので mailutils のインストールも必要です。
ほとんど内容をコピーして設定したのですが、テストすると理由がわかりませんが、リレー先の nifty.com に送ったつもりのテストメールが添付されているエラーメールが私の @niftyへ転送されているようです。

From: MAILER-DAEMON@rpi1-com2.sunao-mita.pgw.jp (Mail Delivery System)
To: root@rpi1-com2
Subject: Undelivered Mail Returned to Sender
Date: Tue, 14 Nov 2017 16:17:17 +0900 (JST)
This is the mail system at host rpi1-com2.sunao-mita.pgw.jp.
I'm sorry to have to inform you that your message could not
be delivered to one or more recipients. It's attached below.
For further assistance, please send mail to postmaster.
If you do so, please include this problem report. You can
delete your own text from the attached returned message.
The mail system
<sunao.mita@nifty.com> (expanded from <sunao@rpi1-com2>): host
smtp.nifty.com[210.131.2.36] said: 553 5.3.0 <root@rpi1-com2>...
Insufficient Address:rpi1-com2 (in reply to MAIL FROM command)

原因がわかりません。しばらくそのまま放置しておくことにします。
ログのレポートを毎日送付する logwatch をとりあえずインストールしておきます。
logwatch のレポートは、1日1回決まった時間に作成されてメールしてきます。こちらは、手動のメール機能の mailコマンドのようにエラーはなく、過去の動作と同じように正常に送られているようです。

From: root@rpi1-com2.sunao-mita.pgw.jp
To: root@rpi1-com2.sunao-mita.pgw.jp
Subject: Logwatch for rpi1-com2 (Linux)
Date: Sat, 18 Nov 2017 06:26:11 +0900 (JST)
################### Logwatch 7.4.3 (12/07/16) ####################
Processing Initiated: Sat Nov 18 06:26:10 2017
Date Range Processed: yesterday
( 2017-Nov-17 )
Period is day.
Detail Level of Output: 0
Type of Output/Format: mail / text
Logfiles for Host: rpi1-com2
##################################################################

問題が postfix 側の設定なのか、 mialutils.mail の設定なのかはわかりませんが、資料やマニュアルが最新バージョンに近付けば近付くほど英語のものしか無く、私の語学力では太刀打ちできません。 logwatch のレポートは送られているので大勢に影響はないので、しばらくそのままにして見守るしかありません。
追加で今すぐ確認できるのは、 cron で自動実行した場合に結果が転送されるのか、されないのかだろうと思います。単純なコマンドを sunaoユーザーで crontab -e コマンドで時間を指定して追加して実行させてみます。実行させるコマンドは、(pwd; ls -al;) としてみました。
次が受け取ったメールです。何の問題もなくコマンド実行の結果をメールで受け取ることが出来ました。 cron のレポートでも問題なさそうです

From: root@rpi1-com2.sunao-mita.pgw.jp (Cron Daemon)
To: sunao@rpi1-com2.sunao-mita.pgw.jp
Subject: Cron <sunao@rpi1-com2> (pwd;ls -al;)
Date: Sun, 19 Nov 2017 11:40:01 +0900 (JST)
/home/sunao
合計 40
drwxr-xr-x 3 sunao sunao 4096 11月 19 11:34 .
drwxr-xr-x 5 root root 4096 11月 11 10:47 ..
-rw------- 1 sunao sunao 1324 11月 15 23:10 .bash_history
-rw-r--r-- 1 sunao sunao 220 9月 7 23:59 .bash_logout
-rw-r--r-- 1 sunao sunao 3523 9月 7 23:59 .bashrc
-rw-r--r-- 1 sunao sunao 675 9月 7 23:59 .profile
-rw-r--r-- 1 sunao sunao 75 11月 19 11:32 .selected_editor
drwx------ 2 sunao sunao 4096 11月 10 21:40 .ssh
-rw------- 1 sunao sunao 2429 11月 19 11:34 .viminfo
-rw-r--r-- 1 sunao sunao 14 11月 12 21:49 .vimrc

mail コマンドの時には、単にサーバー名が省略で短縮されているので、エラーになっているような気もしますが、対策方法がわかりません。

ラズパイ1B で共有サーバーの構築 (3/)

  1. 過去の蓄積データを継続利用は無理らしい。心機一転パーティション分割見直し
  2. 作成に時間の掛かるデータを前準備で作成しておく
  3. 運用に必要な機能を確認しながら、順次インストールして設定する

今回の共有サーバーに利用する USBハードディスクは、過去に日経 Linux の懸賞で当たった小型のARMサーバー(GLOBALSCALE Guru server model: 003-GP0001)と組合せて利用していたものです。そのサーバーは USBポートを2つ持ち、製品に添付されていた USBメモリには、2つのパーティションが作成されていて、 /boot パーティションと、システムとなるルートパーティションでした。
その USBメモリを単純にコピーして、容量が大きなハードディスクに移行して運用していたのが、今回利用することになった USBハードディスクです。以前は他に立てた共有サーバーのデータを夜中に自動バックアップする仕様で利用していました。そのような訳で、データがそのまま利用できればベストでしたが残念ながらダメでした。
懸賞のARMサーバーは、色々と追加セットアップもして数年間は無事に運用できていたのですが、ある時に不安定なログを残しながら、気が付いた時には天国に召されてしまいました。振り返ってみると想像以上に加熱するサーバーでした。夏が来る度に持ちこたえるのだろうかと見守っていましたが、昨年の夏が過ぎて秋になって力尽きたようです。
原因は私の利用法に原因があったのかとも考えています。小さな筐体の中に電源も含有している構造で、常時バスパワーで 2.5インチ 1TB のハードディスクを稼働させていたことに問題があったのかと思います。筐体をまだ分解していませんが、最後は電源が切れたままピクリともしない状況になりました。中には電源系で焼き切れたパーツがあるのかもしれません。
OSも Debian ARM版の古い状態で稼働していたため、セキュリティアップデートや ipv6 が機能していなかったりと気になっていて、時間を見ながらメンテしようと考えた矢先でした。この手の組込み Linux 用の ARM機器は、最新のDebian が公開されているので、Pogoplug 同様に最新に置き換えることは可能です。
また、製品のコンセプトから外付けメディアにセットアップした OSを簡単にブートさせられるように考慮されているので、x86系命令セットの一般的なインテルや AMD のパソコンとは機械命令が異なる ARM プロセッサ(セットアップ中のラズパイもARMで、少しアレンジの Debian) ですが、何の支障もなく最新の Linux が組込めます。


そのような理由から再利用のハードディスクは既にパーティション分割されています。データ部分の内容を再確認するとデータ全域のバックアップはしていなかった運用のようなので、データ部分のパーティションを再割り振りして心機一転作り直すことにしました。
少し前からバックアップサーバーとして稼働させているラズパイ2のディスク構成を参考にして、再割り振りエリアを3つのパーティションに分けました。 /home 用に 100GB を取り、残りをデータ用に 370GB と 480GB に分けました。
データ部分のコピーは現在実行中ですが、元々非力な処理能力のラズパイが持つイーサーネットの転送速度は、100Mb/S ですから全転送には、時間単位というか日数単位が必要になるでしょう。
データの転送が終わりました。正確に時間の測定はしていませんが、合わせて 400GB のデータの転送に、丸1日半位掛かっていたようです。


これからは必要になると思われる機能のインストールに取り掛かります。
共有サーバーの samba メール転送機能の postfix と apache2 bind9 dnsutils ruby webalizer screen byobu ゆっくり考えないと思い付きませんが、過去の記録を見直しながら設定していきます。漏れていて気が付いたら追加でインストールしていく程度のゆるい対応で進めます。postfix は、インストール途中でどのような使い方をしたいのかのダイヤログボックスが開きますが、何も設定しないまま進め後で考えながら見直します。

$ sudo apt update
$ sudo apt install samba apache2 ruby postfix webalizer screen byobu bind9 dnsutils

ラズパイ1B で共有サーバーの構築 (2/)

  1. 秘密鍵、公開鍵ペアの扱いに関して
  2. エディタ vim インストールと、マウス操作が変わったことの対処
  3. piユーザーを既設サーバーと同じユーザー名に置き換える
  4. サーバーとしての利用なので、IPアドレスの固定化

ラズパイ1Bのこれからの作業は、sshによるリモートの作業になります。ホスト名を含めて raspi-config で設定しているので日本語化も行われています。
現在のバージョンを次に記録しておきます。

$ ssh pi@192.168.xx.yy
pi@192.168.xx.yy's password:
Linux rpi1-com2 4.9.59+ #1047 Sun Oct 29 11:47:10 GMT 2017 armv6l
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Thu Nov  9 23:43:13 2017 from 192.168.xx.zz
pi@rpi1-com2:~ $ date
2017年 11月 10日 金曜日 15:02:59 JST
pi@rpi1-com2:~ $ uname -a
Linux rpi1-com2 4.9.59+ #1047 Sun Oct 29 11:47:10 GMT 2017 armv6l GNU/Linux
pi@rpi1-com2:~ $

鍵認証に関しては、ログイン先となるサーバーのログインユーザーの /home/<user> ディレクトリ内に .ssh デイレクトリを作成して、ログイン元となる操作側PCの秘密鍵と公開鍵ペア公開鍵authorized_keys ファイルにコピーします。実際の作業的には、普段 sshログインして作業している他のサーバー内に、既に作成されている実績のある authorized_keys ファイルをコピーして利用しています。.sshディレクトリと authorized_keys ファイルの実行権限はそれぞれ 700 と 600 に設定しておきます。
他のサーバーとの間で、cron / rsync 利用の自動転送によるバックアップを行わせるために、セキュリティ上問題だと一部で言われることですが、各サーバー間のrootユーザーでの作業を行わせるために、パスフレーズ無しでお互いに ssh ログインが出来る設定を行います。
他のサーバーの秘密鍵をコピーしても利用できますが、ラズパイ の root で操作して、鍵ペアを次のような操作で生成させます。

$ sudo su -
# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):
Created directory '/root/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:t8RpcOYT6......42uv5updog root@rpi1-com2
The key's randomart image is:
+---[RSA 2048]----+
| . ...           |
|o .   . .        |
|   o + ..+o      |
+----[SHA256]-----+
# ls -al .ssh
合計 16
drwx------ 2 root root 4096 11月 10 20:25 .
drwx------ 3 root root 4096 11月 10 20:25 ..
-rw------- 1 root root 1675 11月 10 20:25 id_rsa         … 秘密鍵
-rw-r--r-- 1 root root  396 11月 10 20:25 id_rsa.pub     … 公開鍵

ここで生成された鍵ペアは、このラズパイ1Bの rootユーザーから、他のサーバーに sshでログインする場合に、相手サーバー側でログインするユーザー(機械的に自動接続するなら root) に、ここで生成されている公開鍵を .ssh/authorized_keys ファイルに追加でコピーします。
後は同様に、他のサーバーへのログインや、他のサーバーからのログインに対応するように、お互いの公開鍵をサーバー間で、 .ssh/authorized_keys ファイルにコピーしておきます。
セキュリティが甘くなるとの意見もありますが、他から sshログインして利用している実績のあるサーバーが既に存在して稼働しているなら、そのサーバー内にある .ssh/authorized_keys ファイルを丸ごとコピーして入れ込むのも手っ取り早いと思われます。
ある程度リモートログインに実績が出来て、問題が無いようならセキュリティ向上のため、鍵認証だけの設定にして、パスワード認証によるチャレンジを出来ないように変更しておきます。インターネット上に晒すと想像できないくらいの数のパスワードで、絶え間ないチャレンジをされることになります。


操作性が悪いので常用するエディタの機能性を上げるために、vim エディタのフルセットをインストールします。

$ sudo apt install vim

シンタックスのカラーリングを有効にしておきます。
26行1桁目のコメント を取り除きます。

$ sudo vi /etc/vim/vimrc
......  ......
" Vim5 and later versions support syntax highlighting. Uncommenting the next
" line enables syntax highlighting by default.
syntax on
" If using a dark background within the editing area and syntax highlighting
" turn on this option as well
....  ....

ここまでの色々な編集作業で気になっていたのが、昔はエディタの vi で切り貼り編集をしている時に、マウス多用で普通に操作して楽に編集していたのですが、いつの頃からかマウスでの範囲選択やホイールボタンを押下しての貼付けを期待しているのに、 — ビジュアル — と下部に表示されて、期待していた操作が妨害されてしまいます。
vi の操作中に、仮想端末で表示されている文字列をコピーして貼り付ければ簡単に済む操作なのに、一文字づつ打鍵するわけにも行かず調べてみました。 既に vi エディタを操作中なら、コロン(:) の後にコマンド set mouse-=a を入力で無効に出来るらしいとのこと、この呪文の意味はわかりませんがとても助かりました。
vim エディタの通常利用で常にマウス操作のビジュアル移行を回避するには、操作するユーザーの ~/.vimrc を新規作成し、前述の呪文を記述して対応できるようです。

$ sudo vi ~/.vimrc
set mouse-=a
~
$ vi ~/.vimrc
set mouse-=a
~

Raspbian は、操作を全て pi ユーザーの UID : 1000 に統一して、構成されています。色々なディストリビューションが一般的に最初のユーザー登録で、UID : 1000 から登録されますので、例えば既に稼働しているサーバーは sunao ユーザーを UID : 1000 に登録して運用しています。
何が問題かというと、大量に管理しているデータを、各サーバー間で自動転送して、バックアップしながら管理している事を考えたとき、 rsync で単純にコピーすると各ファイルのオーナーは UID の番号で管理されているので、同じ UID なのにサーバーが変わるとファイルの所有者名が異なって扱われてしまう事になります。
ネット共有ディスク samba の扱いでも同様に、ファイル所有者 UID の扱いが問題として発生します。そこで、新規にサーバーを構築している初期の段階で、ユーザーファイルを vipwコマンドで編集を行い pi ユーザー名の箇所を sunao ユーザー名に変更します。
sunaoユーザーの追加に伴い、/home/sunao ディレクトリが必要になるので、/home/pi からコピーして創生しておきます。
変更が必要なコマンドは、vipw / vipw -s / vigr / vigr -s で修正しますが、必要に応じて適宜文字列置換で :pi から :sunao への変更も行います。その後適切に /home/pi 及び /home/sunao 以下のオーナーとグループの変更が必要です。
 sunao – uid:1000 / sunao – gid:1000
 pi – uid:1001 / pi – gid:1001
と変更してみました。


サーバーとして利用するので IPアドレスが変化すると色々と困ることが起こるので、固定アドレスに移行します。
昔は Debianの一般的な作法を参考にして、別な方法で設定していたような気がしますが、次のように定義を追加すると出来るようです。なお、DNSサーバーの指定は ipv4 / ipv6 のアドレスも含めて出来るみたいです。いつもお世話になっている Google検索のネット情報です。

$ sudo vi /etc/dhcpcd.conf
         ...最後尾に追加します
interface eth0
static ip_address=192.168.xx.yy/24
static routers=192.168.xx.1
static domain_name_servers=192.168.xx.22 2400::::225::fe00:9df0

そして再立ち上げ後に IPアドレスが変更されます。

仕切り直して、ラズパイ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年前にも同様の書き込みがありました。