放置していたデスクトップPC

色々と時間の成約があって、手を掛けてやれなかったデスクトップが有ったんですが、何とか起動しようと試みて、大変な状況になっていたことを知りました。

放置していた理由

何で使わなかったかといえば、電源スイッチを押しても反応がなくて電源が入れられなかったことに問題があったのですが、何度もさらには何十回も挑戦すれば入ることもありました。
何としても立ち上げたいと考えた時には、別のPCから俗に言うマジックパケットを発行してネット越しに起動していました。
別に起動した機器からの立上げになり、本当に必要とした時だけの利用でした。

そんな状況では利用しようとの考えもしぼみがちで、当然のこと利用機会が遠ざかっていくことになりました。
起動しないのは電源スイッチの問題だとの認識があったので、時間が自由になっている現在、復旧させて利用しようと考えました。

再利用しようと思った理由

メモリ搭載が贅沢な 12GB

放置するのがもったいないのは、実はメモリを12GBと贅沢に搭載していて遅いプロセッサながら、内蔵ディスクもRAID構成でそこそこ動く代物でした。

電源ピンをショート

そして最初の対策が筐体を開けて、電源スイッチの繋がるピンをショートしたのですが、CPUの冷却ファンが回り始めて3秒程度で止まってしまいます。この時にはキーボードとマウスは接続しているもののモニタの接続をしていませんでした。

すぐに止まるのはこれが原因かと考えて、VGAコネクタやHDMIコネクタでモニタを接続してみたのですが、ここには関係ないようで変化は見られませんでした。

電源スイッチを仮設して操作

その後、電源スイッチのピンに単体でオンオフできるスイッチを取付けて操作できるように改善して試すも、同様に3秒程度で止まります。理由がわからないのでBIOSのメモリクリアも試しました。後々これが別の問題を起こしていたかもしれません。

あまり気にしたことがなかったのですが、電源スイッチってオンしっぱなしではなく、短期間にオンで、その後はオフを継続するものなのでしょうか、そんなシーケンスでスイッチを操作すると電源が入って立ち上がるようになりました。

と言ってもBIOS メモリクリアしたのが悪かったようで、日付は2002年頃の状態で色々な設定が飛んでしまったようで、内蔵メモリの不具合を示すランプも点灯したり、色々な問題対処も必要になりました。

無知というのは恐ろしいものです

考えれば、電源の強制停止には、電源スイッチを5秒間押しっぱなしにするのが定説ですので、電源スイッチは少しのオンで電源が入り少しのオンで電源が停止するのは当たり前ですよね、よくよく考えてみれば当然です。

そうこうしていると起動を示すバナーがモニター上に流れて、GRUBの起動するシステムを選択するメニューが表示されるところまでは進みました。しかし、どれを選択してもカーネルのパニックを表示してすぐに止まります。

BIOS クリアでディスクの順番が変化したらしい

起動の始めに [del] キーを連打して BIOS の設定画面を表示して、ディスクの認識する順番を入替えても、 grub rescue > と入力待ちになったり、多少の変化はあるもののどれも正常な起動までは行われませんでした。

諦めて、再インストールを決断

仕方無く、レスキュー用のメディアも検討したのですが、新しく OS をインストールしてみることにしました。候補に上げたのが、普段使い慣れている Ubuntu です。 USBブート用の USBメモリを持っていたのですが、そこから読み込んで立ち上げができなかったので、 Ubuntu 18.04 LTD 日本語 Remix をダウンロードして DVD メディアに焼きました。

四苦八苦の復旧作業

まずは、RAIDの復旧を試みる

ライブメディアとして起動した Ubuntu

以前稼働していた頃には、ソフトウェアRAIDの設定で集めたデータも格納されていて、Ububtu の OS も RAID1 で問題なく動作していました。気持ち的には復旧させたいとの願いも心の底にあって、まずは DVDメディアで起動して、モジュールのアップデート、そしてソフトRAIDのmdadmのインストールを行いました。
mdadmが入っただけではRAID設定のディスクを認識できないようで、各モジュールの最新への更新が完了した頃には、元からあった RAIDの構成が勝手に認識されていました。

ライブメディアから RAID への GRUB 設定は無理

インストール前に、システムが入るエリアのマウント位置の ‘/’ と ‘/boot’ を RAID1 に設定したのですが、最終的なブートで使用される GRUB のインストールで障害になりました。

RAID の中にパーティションを構成できるらしい

興味深いのは、ディスクへのインストーラが RAID定義したファイルをあたかも LVM のような1つのディスクのように認識していて、その中にパーティションを分割するように振る舞うことです。昔ソフトRAIDを使用していた頃の感覚からすると別世界のような感覚です。

たまたま GRUB のインストールには失敗したのですが、そこまでのシステムのインストール状況も気になって、 /dev/md0 として作成し、その中に /dev/md0p1 と /dev/md0p2 がそれぞれ ‘/boot’ と ‘/’ に対応していました。
誤って mount に /dev/md0 を指定したらマウント対象ではないようなエラーが吐き出され失敗しました。
そして、/dev/md0p1 と /dev/md0p2 の mount では、問題なくマウントできたようです。内容も思っていた内容で、確かにパーティション分割されているようです。

GRUB を修復する grub-rescue

ブートの GRUB を修復できるソフトがあるらしく、それは grub-rescue と呼ばれ公開されているようで、インストールをネット公開情報から試みましたが、日本語Remixの環境ではインストール自体ができませんでした。
そこで、単体でメディアから起動して動作する grub-rescue をネットから入手して試しましたが、結果的に自動での修復は無理でした。これは Ubuntu 17.10 だったかな? の中にインストールされている単体動作の専用ツールです。
自動修復は無理でしたが、でもこのツールは解析の履歴が事細かく記録されているようで、http://paste.ubuntu.com/p/…. に残されて後からゆっくりと確認できることです。

他にも、’/boot’ を外出しにして、’/’ を RAID エリアにしても、GRUB のインストールはできるのですが、やはり起動はできないようです。
何日にも及ぶほど時間を掛けたのですが、インストール先に RAIDエリアは利用できないとの結論になりました。
そう言えば、昔々公開サーバーに バッファローのネット共有ディスクを改造して、Debian をインストールして RAID にするのに、最初は普通に入れてから片側を半端な RAID に定義して、そっちに全てをコピーしてから、元のディスクを RAID に追加してリビルドさせて、最終的に RAID になったシステムが完成したような気がします。

デスクトップ用メディアでは少なくも RAID構成は無理らしい

最近のインストーラも RAID は想定外なので、正規のシステムが立ち上がる前に利用される一時的なシステムに、RAIDを認識できる部分が組み込まれていないのだろうと思います。

したがって最初は単純にインストールして、徐々にカスタマイズしないと RAID の組込みはできないということのようです。

単純にデスクトップをインストール

少なくもデスクトップ用で RAID は無理

仕切り直して、単純に Ubuntu 18.04 LTS 日本語Remix を入れるところから始めました。時間がかかったけど想定した位置に入れ込むことができました。

/dev/sda1 — ‘/boot’
/dev/sda3 — ‘/’

インストールで、画面枠からはみ出て選択ができない

これも簡単ではなく、苦労したのは既に作成されているパーティション分割に合わせてマウントポイントを指定するのですが、モニタに利用したテレビ画面から作業を選択するボタンが表示枠の範囲外になってしまい、スクロールもできず選択不能です。
タブキーとエンターキーを画面の想像で操作するのですが、何度も取り消されてしまい、振り出しに戻されての繰り返しで、先に進む方法に辿り着けません。

やっとインストールされた初期の状態で立ち上がりました。その後のパッチ類を全て適用して、やっとスタート台に立った状態です。

単純なインストール後に、RAIDソフトを追加

その後、ソフトRAID の mdadm、ソフト検索のため aptitude 、エディタとして vim、リモートログインに openssh-server をインストールしました。
元々のデータが収まっていた 500GB 程度の RAID1 の内容を確認すると ‘/home’ の内容のようなのを確認できたので、 /etc/fstab ファイルを修正して ‘/home’ にマウントされるように定義して、reboot で正しくマウントされて立ち上がるのを確認しました。

システムを RAID 構成にと考え、結局挫折

しばらく放置したPCを復旧させるって難題ですね。以前はルートのシステム部分もRAID1で構成されていたので、その状態に戻したくて四苦八苦して悪あがきをしたのですが、結果は惨敗でした。記憶では、RAID1を片肺にしてコピーしてから /etc/fstab や /boot/grub/grub.cfg を書き換えて片肺の RAID1 をシステムに無理やり組込んでいたように覚えてます。

最近の GRUB の設定方法が理解できていない

最近の作法としては、grub.cfg は update-grub のようなツールで生成されるもののようで、強制的に書き換えて機能するものなのかも理解していません。生成されている grub.cfg を見ると該当するディスクは基本的に UUID で指定されているようで、これをどのように引っ張ってきたのかも理解できていません。

何かの定義を変更すると立ち上げ対象のディスクが置き換えられるのかと思い、あちこち調べたのですが思い当たるものには到達できませんでした。強制的に grub.cfg を書き換えて仮に立ち上げてから RAID1 を正常に整備してから update-grub を実行して RAID1 にシステムを入れた状態で、正常に立上がるのかは検証できていません。

生成された grub.cfg を一時的にカスタマイズできるの??

強制的に grub.cfg を書き換えて立上がるものなのかもわかっていません。時間を作って試してみたいと思います。

復旧しようと考えた PC のマザーボードですが、新しいものではなく、かと言ってディスクに IDE インターフェースでマスターとスレーブの4台が組み込まれるほどの古さでもない微妙な物です。 プロセッサは、’AMD Athlon(tm) II X4 605e Processor’ で、 DD3 メモリが、12GB 搭載されているので再利用できれば程度の考えです。

ただ、IDE のコネクタも1つあり、当時はSATAインターフェースの CD-ROM がなくて、そのためのコネクタだったような気がします。
SATS1 / SATA2 / SATA3 / IDE / SATA5 / SATA6 と続きます。昔の IDE 接続だった頃のディスクの場合、セカンダリーのスレーブに CD-ROM を繋いでいた名残にも見えます。

昔のディスクは順番が接続で固定された

昔のシステムは単純で、ディスクの装着位置で順番が決まっていたので、UUID でディスクを特定する必要がなかったのでしょうね、今復旧している PC も立上がるタイミングや BIOS の定義で順番がコロコロと置き換わるようです。
さすがに動作しながら順番が異なることはなさそうな気もしますが、でも USB-HDD を挿入したタイミングで処理中だった物が、対象機器を見失ったような混乱で、障害で停止したのかと思う動きもあって気になりました。

あまりに古いPCなので、レストアを考えたい

とりあえず電源がオンオフできる筐体

筐体もパワースイッチが入らなくなるような状況で、整形されたプラスチック類も加水分解状態の物も目に付くような状況から検討することにしました。マザーボードは、サイズが少し大きめで ATX 、電源は昔ではちょっと大きめな高速なプロセッサに対応した容量の物でした。そのまま再利用できそうなので筐体だけ入れ替えようと探しました。

今のマザーボードが収まるのは ATX の筐体

筐体の価格も高価なものから低価格な庶民的なものまでピンキリのようで、フルの ATX なので小型のものは望めませんでしたが、Amazon で手頃な中国製を購入しました。ちょっと派手で、片側が透明なプラスチックのミドルタワー型です。製品名は、 ‘Thermaltake Versa H26 Black/w casefan’ とかで、送料サービスで 4,163円でした。

今のマザーボードの規格に合っている筐体

久し振りに自作用の筐体を入手しましたが、価格の割に良くできていてファンも 2個装着済で、コネクタをマザーボードに挿すだけでした。その前に使っていた古い筐体にもファンは取付けられていましたが、ディスク等に供給する電源コネクターに接続するようになっていて、結局使わないままでした。

最近の自作筐体って人に見せるためにあるの??

購入した筐体は派手な作りのようで、筐体正面のファンにはブルーのLEDが付けられていて、筐体自体も風通しが良くなるメッシュが随所に組み込まれていて、埃除去のフィルターも簡単に取り外しできる構造です。
筐体の片面が透明なプラスチックで中がスケスケなため、夜になるとギンギラギンでまばゆい状態です。派手過ぎてちょっと自分の好みではないけど、価格が安いですのでこれもオーケーでしょう。
配線も裏にまとめやすく作られていて、見える透明なプラスチック側は綺麗に見せられるように、裏からの配線が近くから表側に導き出せるよう随所に穴が作られています。

筐体前面の電源スイッチの並びには、マイクやスピーカー等のオーディオ系コネクタやUSB2.0✕2 や USB3.0✕2 のコネクタもあり、USB2.0✕2 とオーディオ系は、そのままマザーボード上のコネクタに挿入できましたが、USB3.0✕2 には挿入できる機能がありません。
使えないコネクタが前面にあるのもちょっと気になるため、乗りかかった船なので、増設用ボードの手配もしました。ただ、Amazon経由で台湾のメーカーらしく、船便でゆっくり届くと思われます。
しばらく後になっての取付けですが、安いのでこれもありかと思います。

見える筐体なので、綺麗に収めようと思ったら

廃棄した古い筐体の方には、2.5インチで 1TBのディスクが 2台あり、これが RAID1 の構成に利用されていましたが、何故か 3.5インチベイの片側に寄せた形でネジ止めされていました。組んだ時が昔なのですっかり記憶から抜けています。

他に 2.5インチのディスクを 2台づつ装着でき、外から簡単に挿入したり、抜き出したりできるケースがあるにも関わらず、使わずに単体で 3.5インチベイにネジ止めしていたので不思議に思っていたのですが、取り付けようとして理由がわかりました。
ディスクの厚さが 13mmあって、9.5mm厚に対応しているケースには入れられなかったようです。当時は 1TBクラスの 2.5インチディスクは厚くないと製造できなかったようです。

筐体の最下部に簡易トレイ

とりあえず新しく購入した筐体にも、電源の置かれた最下部の前側には、ペラペラのプラスチックのトレイに入れて SSD やディスクの設置が可能です。
最近は価格も下がり普及してきた SSD を入れるために考えられたと思われる場所です。
そこに厚さが 13mm の 2.5インチのシステムディスクを 2台とりあえず入れることにしました。

収まるのかは心配ですがマウンターを購入

穴位置のサイズが公表されて無く、写真から 13mm 厚の2.5インチのディスク2台を収納できるようにも見える 3.5インチ用のマウンターも購入しました。
本当に厚い2台装着できるのかは心配です。賭けですね、無駄な買い物になってしまうかもしれません。

リモートで利用するサーバーとしてカスタマイズ

デスクトップとしてインストールしていますが、リモートからの電源オンオフも含めて、リモート操作を想定したサーバーとしての利用なので、これからのカスタマイズも含めてまだまだ楽しめそうです。

Linux 立上げで自動バックアップ

以前 systemd の実習を兼ねて、立上げ時に1度だけ実行させるサービスを組込んでいますが、その備忘録の整理と一部の拡張が必要なために修正と補足を追加してまとめます。

バックアップ先の選択が必要になり修正

普段使いのノートPC がデュアルブートで、時々裏の Windows10 を利用することがあります。普段は Linux の Ubuntu が立上がったまま稼働し利用しています。

そこで Linux が立上がった時に、Windows システム側の ntfs ファイルシステムの作業領域として更新される一部を自動的にバックアップしようと考えて、すでに組み込んで運用しています。

今回は、UPS バッテリーが追加された NET共有サーバーとしてラズパイ1B+を立上げていますが、これを主となるマスターとして位置付けて、今までのサーバーをシステムバックアップ用のスレーブとして共存することにしました。

ラズパイも接続される HDD が内部バスで高速なら、戸惑いなく RAID2 のミラーで利用するのですが、さすがに USB2.0 のインターフェース HDD でミラーを組むのは無理があると思い、2台のラズパイをマスターとスレーブで利用して、マスターが故障した場合にはスレーブに接続を切り替えることにしました。

データの同期については、夜中から明方にかけて毎日コピーすることで同期させます。

そのため、決め打ちだったバックアップ先のサーバーアドレスを柔軟に切り替えられる必要に迫られました。

以前まとめた内容を修正しながらシンプルに整理

実際に Windows を利用していたかは問題外として、Linux が起動した後に1度だけ ntfs の一部とサーバーのバックアップエリアの同期を取ります。その時に、バックアップを実行したタイムスタンプをバックアップエリア内に残しておくこととします。

パッケージ名: NoteStartUpRun で、指定する場所に実際の実行モジュール等を配置します。

ユニットファイル名: note-startup-1st.service が、サービスの性格を定義する仕様書の位置付けです。このサービス名をキーにして、実行結果のログ確認や動作状況の確認ができます。

サービス(ユニットファイル)の登録は、 /etc/systemd/system/note-startup-1st.service です。

サービスとして実際に実行するモジュールは、パッケージ名で指定するディレクトリ /opt/NoteStartUpRun/bin に集めます。

まずサービスの仕様書となるユニットファイルの作成ですが、一般ユーザーのホームで作成して、systemd のシステム領域にコピーします。

$ vi note-startup-1st.service
[Unit] 
Description = Note Private AutoRun
After=network-online.target remote-fs.target nss-lookup.target
ConditionPathExists=/opt/NoteStartUpRun/bin

[Service]
ExecStart=/opt/NoteStartUpRun/bin/note-stup-1st.sh
Restart=no
Type=simple

[Install]
WantedBy=multi-user.target

作成したサービスを systemd 領域にコピーして、所有者とアクセス権の変更をします。

$ sudo cp note-startup-1st.service /etc/systemd/system
$ sudo chown root:root /etc/systemd/system/note-startup-1st.service
$ sudo chmod 644 /etc/systemd/system/note-startup-1st.service

サービスから起動するモジュールをシェルスクリプトで作成します。

これは単純にバックアップするスクリプトに制御を移しているだけです。後から引数の追加・変更等のカスタマイズが容易になると思われます。今回は、バックアップ先サーバーのIPアドレスを与えています。

$ vi note-stup-1st.sh
#!/bin/sh
exec /opt/NoteStartUpRun/bin/sunao-note_Windows-Documents-bkup  "192.168.11.23"

パッケージをまとめるディレクトリを作成して、所有権とアクセス権の設定を行い、起動するスプリクトを配置します。

$ sudo mkdir -p /opt/NoteStartUpRun/bin
$ sudo chmod 755 /opt/NoteStartUpRun/bin
$ sudo cp note-stup-1st.sh /opt/NoteStartUpRun/bin
$ sudo chown root:root /opt/NoteStartUpRun/bin/note-stup-1st.sh
$ sudo chmod 755 /opt/NoteStartUpRun/bin/note-stup-1st.sh

実際にバックアップを実行するスクリプトを作成します。

$ vi sunao-note_Windows-Documents-bkup
#!/bin/bash

server='192.168.11.23' # バックアップ先サーバー
test -z "$1" || server="$1"
echo "-- bkup to $server"

bkup_D="$server:/home/bkup/sunao-sp/sunao-Win-Doc/" # バックアップ先位置

mntS='/mnt/ntfs'
bkup_S="$mntS/Users/sunao/Documents/" # バックアップ元のベース

sleep 300 # 安定するように 5分待つ
/bin/mount $mntS
echo "実行タイムスタンプ `date`" > $bkup_S/TimeStamp.txt
/usr/bin/rsync -av --delete $bkup_S $bkup_D
/bin/umount $mntS

バックアップを実行するスクリプトを配置して、所有権とアクセス権を設定します。

$ sudo cp sunao-note_Windows-Documents-bkup /opt/NoteStartUpRun/bin
$ sudo chown root:root /opt/NoteStartUpRun/bin/sunao-note_Windows-Documents-bkup
$ sudo chmod 755 /opt/NoteStartUpRun/bin/sunao-note_Windows-Documents-bkup 

処理の流れとしては、サービスとして定義している note-startup-1st.service により note-stup-1st.sh が起動されます。その中で単純にバックアップ実行スクリプトの sunao-note_Windows-Documents-bkup を起動しています。


ユニットファイルを systemd に登録

ここからは、systemd へのサービス(ユニットファイル)の登録と検証作業です。

ユニットファイル等を追加や変更した後には、必ず次のコマンド sudo systemctl daemon-reload を実行します。systemd への登録や登録内容の更新作業が必要になるようです。

そして一緒にステータスも確認しておきます。

$ sudo systemctl daemon-reload
$ sudo systemctl status note-startup-1st.service
● note-startup-1st.service - Note Private AutoRun
   Loaded: loaded (/etc/systemd/system/note-startup-1st.service; disabled; vendor preset: enabled)
   Active: inactive (dead)

ステータスで表示される Loaded: 行のカッコ内の1つ目と2つ目のセミコロンの間の disabled となっているのは、自動起動が無効になっているということのようで、自動起動できるように設定します。

自動起動が行われるように設定

$ sudo systemctl enable note-startup-1st.service
Created symlink from /etc/systemd/system/multi-user.target.wants/note-startup-1st.service to /etc/systemd/system/note-startup-1st.service.
$ sudo systemctl status note-startup-1st.service
● note-startup-1st.service - Note Private AutoRun
   Loaded: loaded (/etc/systemd/system/note-startup-1st.service; enabled; vendor preset: enabled)
   Active: inactive (dead)

ユニットファイルの定義内に、[ Install ] の WantedBy= で定義しているユニットにリンクが張られ、先ほどの /etc/systemd/system/note-startup-1st.service; の後の disabledenabled に変わっています。

これで再立ち上げで自動実行されるようになっているはずですが、その前にコマンドで起動して確認します。

systemd の手動起動の確認

ユニットファイル名を指定したコマンド sudo systemctl start note-startup-1st.service で起動できます。

$ sudo systemctl start note-startup-1st.service
$ sudo systemctl status note-startup-1st.service
● note-startup-1st.service - Note Private AutoRun
Loaded: loaded (/etc/systemd/system/note-startup-1st.service; enabled; vendor preset: enabl
Active: active (running) since Sat 2019-02-09 20:40:50 JST; 19s ago
Main PID: 15710 (sunao-note_Wind)
Tasks: 2 (limit: 3787)
CGroup: /system.slice/note-startup-1st.service
├─15710 /bin/bash /opt/NoteStartUpRun/bin/sunao-note_Windows-Documents-bkup 192.168
└─15711 sleep 300

2月 09 20:40:50 MITA-NY40S systemd[1]: Started Note Private AutoRun.
2月 09 20:40:50 MITA-NY40S note-stup-1st.sh[15710]: -- bkup to 192.168.11.23
lines 1-11/11 (END)

起動されて ‘– bkup to 192.168.11.23′ のメッセージまでが書きだされて、’Active: active (running) since ….’ と表示して実行中なのがわかり、’└─15711 sleep 300′ で止まっているのが確認できます。

待ち時間の5分が経過したので、再び確認してみます。

$ sudo systemctl status note-startup-1st.service
● note-startup-1st.service - Note Private AutoRun
   Loaded: loaded (/etc/systemd/system/note-startup-1st.service; enabled; vendor preset: enabl
   Active: inactive (dead) since Sat 2019-02-09 20:45:57 JST; 24min ago
  Process: 15710 ExecStart=/opt/NoteStartUpRun/bin/note-stup-1st.sh (code=exited, status=0/SUC
 Main PID: 15710 (code=exited, status=0/SUCCESS)

 2月 09 20:45:51 MITA-NY40S ntfs-3g[15727]: Version 2017.3.23 integrated FUSE 28
 2月 09 20:45:51 MITA-NY40S ntfs-3g[15727]: Mounted /dev/sda4 (Read-Write, label "Windows", NT
 2月 09 20:45:51 MITA-NY40S ntfs-3g[15727]: Cmdline options: rw,noexec,nosuid,nodev,uid=1000,g
 2月 09 20:45:51 MITA-NY40S ntfs-3g[15727]: Mount options: rw,noexec,nosuid,nodev,user,allow_o
 2月 09 20:45:51 MITA-NY40S ntfs-3g[15727]: Global ownership and permissions enforced, configu
 2月 09 20:45:55 MITA-NY40S note-stup-1st.sh[15710]: sending incremental file list
 2月 09 20:45:56 MITA-NY40S note-stup-1st.sh[15710]: TimeStamp.txt
 2月 09 20:45:57 MITA-NY40S note-stup-1st.sh[15710]: sent 4,207 bytes  received 61 bytes  948.
 2月 09 20:45:57 MITA-NY40S note-stup-1st.sh[15710]: total size is 37,355,511  speedup is 8,75
 2月 09 20:45:57 MITA-NY40S ntfs-3g[15727]: Unmounting /dev/sda4 (Windows)
lines 1-16/16 (END)

コマンドによる起動では問題なく実行されて、正常終了しているようです。

ログに書き出されている内容から、最初の status では sleep 300 で停止しているので、その時点までの echo メッセージが確認でき、次の status では、その後の ntfs ファイルのマウントや rsync コマンドによる転送や ntfs ファイルのアンマウントが記録されています。

もし更新ファイルのバックアップで、更新されていれば、ここにファイル名がリストされていると思います。

この処理は、起動されてバックアップ動作が終わると、毎回終了するので ‘Active: inactive (dead)’ と表示して、その後に終了した日時が記録されています。

一般ユーザーでジャーナルを確認

次にプログラムの出力ログを確認できる journalctl コマンドがあるので確認してみます。

$ journalctl -u note-startup-1st.service

 2月 09 20:40:50 MITA-NY40S systemd[1]: Started Note Private AutoRun.
 2月 09 20:40:50 MITA-NY40S note-stup-1st.sh[15710]: -- bkup to 192.168.11.23
 2月 09 20:45:51 MITA-NY40S ntfs-3g[15727]: Version 2017.3.23 integrated FUSE 28
 2月 09 20:45:51 MITA-NY40S ntfs-3g[15727]: Mounted /dev/sda4 (Read-Write, label "Windows", NT
 2月 09 20:45:51 MITA-NY40S ntfs-3g[15727]: Cmdline options: rw,noexec,nosuid,nodev,uid=1000,g
 2月 09 20:45:51 MITA-NY40S ntfs-3g[15727]: Mount options: rw,noexec,nosuid,nodev,user,allow_o
 2月 09 20:45:51 MITA-NY40S ntfs-3g[15727]: Global ownership and permissions enforced, configu
 2月 09 20:45:55 MITA-NY40S note-stup-1st.sh[15710]: sending incremental file list
 2月 09 20:45:56 MITA-NY40S note-stup-1st.sh[15710]: TimeStamp.txt
 2月 09 20:45:57 MITA-NY40S note-stup-1st.sh[15710]: sent 4,207 bytes  received 61 bytes  948.
 2月 09 20:45:57 MITA-NY40S note-stup-1st.sh[15710]: total size is 37,355,511  speedup is 8,75
 2月 09 20:45:57 MITA-NY40S ntfs-3g[15727]: Unmounting /dev/sda4 (Windows)
lines 285-306/306 (END)

ジャーナルの表示では、status で分割されていたログ内容が続けて表示され、 20:40 で処理が始まり、時間が飛んで 20:45 から ntfs のマウントが始まっているので、5分待っているのが確認できます。

システム再起動による自動起動の確認

いよいよ待望の Linux の立上げによる自動起動の確認になります。ノートPCを再起動してジャーナルを確認します。

$ journalctl -u note-startup-1st.service

 2月 09 20:45:57 MITA-NY40S note-stup-1st.sh[15710]: sent 4,207 bytes  received 61 bytes  948.44 bytes/s
 2月 09 20:45:57 MITA-NY40S note-stup-1st.sh[15710]: total size is 37,355,511  speedup is 8,752.46
 2月 09 20:45:57 MITA-NY40S ntfs-3g[15727]: Unmounting /dev/sda4 (Windows)
-- Reboot --
 2月 09 22:00:30 MITA-NY40S systemd[1]: Started Note Private AutoRun.
 2月 09 22:00:30 MITA-NY40S note-stup-1st.sh[1281]: -- bkup to 192.168.11.23
 2月 09 22:05:31 MITA-NY40S ntfs-3g[3854]: Version 2017.3.23 integrated FUSE 28
 2月 09 22:05:31 MITA-NY40S ntfs-3g[3854]: Mounted /dev/sda4 (Read-Write, label "Windows", NTFS 3.1)
 2月 09 22:05:31 MITA-NY40S ntfs-3g[3854]: Cmdline options: rw,noexec,nosuid,nodev,uid=1000,gid=1000,use
 2月 09 22:05:31 MITA-NY40S ntfs-3g[3854]: Mount options: rw,noexec,nosuid,nodev,user,allow_other,nonemp
 2月 09 22:05:31 MITA-NY40S ntfs-3g[3854]: Global ownership and permissions enforced, configuration type
 2月 09 22:05:34 MITA-NY40S note-stup-1st.sh[1281]: sending incremental file list
 2月 09 22:05:35 MITA-NY40S note-stup-1st.sh[1281]: TimeStamp.txt
 2月 09 22:05:35 MITA-NY40S note-stup-1st.sh[1281]: sent 4,207 bytes  received 61 bytes  948.44 bytes/se
 2月 09 22:05:35 MITA-NY40S note-stup-1st.sh[1281]: total size is 37,355,511  speedup is 8,752.46
 2月 09 22:05:35 MITA-NY40S ntfs-3g[3854]: Unmounting /dev/sda4 (Windows)
lines 295-319/319 (END)

‘– Reboot –‘ の記録以降が新しく追加されたログですので、問題なく起動されて正常終了しているようです。


実際の立上げによるバックアップの注意点

順調にバックアップ動作が機能したわけではなく、色々な試行錯誤の結果として問題の解決ができています。

立上げ直後は、ネットワークの安定に問題があるらしくエラーになっていました。対策としては起動されてから 5分の待ち時間の追加で問題が解決しました。

次は ‘sleep 300’ の待ち時間が追加される前に出ていたエラーのジャーナル内容です。

$ journalctl -u note-startup-1st.service

-- Logs begin at 火 2018-01-09 16:24:34 JST, end at 火 2018-01-09 16:27:17 JST. --
 1月 09 16:25:12 MITA-NY40S systemd[1]: Started Note Private AutoRun.
 1月 09 16:25:14 MITA-NY40S ntfs-3g[1071]: Version 2015.3.14AR.1 integrated FUSE 28
 1月 09 16:25:14 MITA-NY40S ntfs-3g[1071]: Mounted /dev/sda4 (Read-Write, label "Windows", NTFS 3.1)
 1月 09 16:25:14 MITA-NY40S ntfs-3g[1071]: Cmdline options: rw,noexec,nosuid,nodev,uid=1000,gid=1000,user
 1月 09 16:25:14 MITA-NY40S ntfs-3g[1071]: Mount options: rw,noexec,nosuid,nodev,user,allow_other,nonempty,relatime,default_permissi
 1月 09 16:25:14 MITA-NY40S ntfs-3g[1071]: Global ownership and permissions enforced, configuration type 7
 1月 09 16:25:16 MITA-NY40S note-stup-1st.sh[1039]: ssh: connect to host 192.168.11.21 port 22: Network is unreachable
 1月 09 16:25:16 MITA-NY40S note-stup-1st.sh[1039]: rsync: connection unexpectedly closed (0 bytes received so far) [sender]
 1月 09 16:25:16 MITA-NY40S note-stup-1st.sh[1039]: rsync error: unexplained error (code 255) at io.c(226) [sender=3.1.1]
 1月 09 16:25:16 MITA-NY40S ntfs-3g[1071]: Unmounting /dev/sda4 (Windows)

それ以外のエラーとして、バックアップ先のサーバーを変更したらエラーになりました。

理由は root ユーザーで接続し転送していますが、 root から root での ssh での接続実績がなく、確認キー待ちになってエラーしていたようです。事前にサーバーへの接続確認をしておく必要があるようです。

-- Reboot --
 2月 07 23:09:20 MITA-NY40S systemd[1]: Started Note Private AutoRun.
 2月 07 23:09:20 MITA-NY40S note-stup-1st.sh[1330]: -- bkup to 192.168.11.23
 2月 07 23:14:21 MITA-NY40S ntfs-3g[2633]: Version 2017.3.23 integrated FUSE 28
 2月 07 23:14:21 MITA-NY40S ntfs-3g[2633]: Mounted /dev/sda4 (Read-Write, label "Windows", NTFS 3.1)
 2月 07 23:14:21 MITA-NY40S ntfs-3g[2633]: Cmdline options: rw,noexec,nosuid,nodev,uid=1000,gid=1000,use
 2月 07 23:14:21 MITA-NY40S ntfs-3g[2633]: Mount options: rw,noexec,nosuid,nodev,user,allow_other,nonemp
 2月 07 23:14:21 MITA-NY40S ntfs-3g[2633]: Global ownership and permissions enforced, configuration type
 2月 07 23:14:21 MITA-NY40S note-stup-1st.sh[1330]: Host key verification failed.
 2月 07 23:14:21 MITA-NY40S note-stup-1st.sh[1330]: rsync: connection unexpectedly closed (0 bytes recei
 2月 07 23:14:21 MITA-NY40S note-stup-1st.sh[1330]: rsync error: error in rsync protocol data stream (co
 2月 07 23:14:21 MITA-NY40S ntfs-3g[2633]: Unmounting /dev/sda4 (Windows)

ラズパイUPSのメール

ラズパイ1B+のネット共有サーバー化で、UPSバッテリーの減少や充電の経過をメール送信させて、スマホで確認したい、との対策の続きです。

メール機能は、今迄のサーバー設定の流れからpostfixでの設定になりますが、以前の実績のあるサーバーの設定と比較しながら今回も設定しました。一応動作したように感じたのですが、送られてくるはずのログが届きませんでした。

postfixのバージョンも上がっていて、項目が少し増えているようです。丹念に見直すと一部がコメントのままになっている項目とか別に誤りとか、数件気になる場所が見つかりました。

そこを直して立ち上げ直すと、期待しているような送信が行なわれているような印象です。届かなかったログも時間を置いて再送信されたようで、数時間後に届きました。

メモとして、コメントを除いた有効行をリストしておきます。

$ cat /etc/postfix/main.cf
compatibility_level = 2
command_directory = /usr/sbin
daemon_directory = /usr/lib/postfix/sbin
data_directory = /var/lib/postfix
mail_owner = postfix
myhostname = rpi1-disk.sunao-mita.pgw.jp
mydomain = sunao-mita.pgw.jp
myorigin = $myhostname
inet_interfaces = all
mydestination = rpi1-disk, DebianPogo, DebianPogo.$mydomain, $myhostname, localhost, $mydomain
local_recipient_maps = unix:passwd.byname $alias_maps
unknown_local_recipient_reject_code = 550
mynetworks_style = host
mynetworks = 127.0.0.0/8, 192.168.11.0/24, [::ffff:127.0.0.0]/104 [::1]/128, [240d:1a:34d:7f00::0]/64
relayhost = [smtp.nifty.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/nifty.auth
smtp_sasl_security_options = noanonymous
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
home_mailbox = Maildir/
smtpd_banner = $myhostname ESMTP
debugger_command =
         PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
         ddd $daemon_directory/$process_name $process_id & sleep 5
sendmail_path = /usr/bin/postfix
newaliases_path = /usr/bin/newaliases
mailq_path = /usr/bin/mailq
setgid_group = postdrop
inet_protocols = ipv4, ipv6
message_size_limit = 10485760
mailbox_size_limit = 1073741824
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain = $myhostname
smtpd_recipient_restrictions = permit_mynetworks, permit_auth_destination, permit_sasl_authenticated, reject
mua_client_restrictions = permit_sasl_authenticated,reject
mua_helo_restrictions = permit_sasl_authenticated,reject
mua_sender_restrictions = permit_sasl_authenticated,reject

mailコマンドでメールするのに、以前は問題なく送信できていたのに、最近のバージョンではサーバー名が短縮されて送信されるようで、リレー先の@niftyでエラーになってしまいます。

どこかの定義で変更できるのかと思い調べたのですが、私には見つけられませんでした。対策としては、-r オプションで、リターンアドレスをフルアドレスで明示して指定することで回避できました。

メールで経過を送信できる目処が立ったので、どのように作るかですが、作成したups-readでバッテリーの容量が取得できるので、単純なシェルスクリプトで容量の変化を検知してメールを作成させることにしました。

バッテリーの減少検知では、50%を切ったら10%減少毎にメールをスマホに送信します。充電では、50%を越えたら15%充電毎にメールをスマホに送信します。

起動方法は、cronにより適当なインターバルで、毎回起動し過去と比較判定して該当すればメールを作成して終了します。

起動された前回の容量とメールを作成した時の容量をファイルに記録しておいて比較する方法です。経過をモニタしながらのデバッグで分かったことは、ups-readから渡される容量が、有り得ない数値を頻繁に表示します。

0 〜 100の範囲を超えて、120 程度は想定内と認識しますが、217 とか 193 などといった異常な数値が頻繁に出てきます。観察すると異常な数値に混じって正常な数値も有るようです。

異常な数値を排除した 0 〜 120 の範囲に入る数値は 、安定していて変化の少ない数値で推移しています。期待するバッテリーの容量と判断しても良さそうです。

対策としては、120 を超える異常な数値の時には前回の数値と置換えて無視することにしました。

$ cat bin/ups-check-mail.sh
#!/bin/bash

T='## UPS Battery Capacity ##'
Msg='UPS Battery Capacity '
DW='*Down* : '
UP='*Up* : '
Rt='sunao@rpi1-disk.sunao-mita.pgw.jp'
To='sunao*****@yahoo.**.jp'    # スマホのメールアドレス

FC='UPS-Check/UPSCap.txt'      # 前回の容量メモ
FM='UPS-Check/UPSCap-msg.txt'  # メール生成時の容量メモ

C=`ups-read`
test -f $FC || echo 100 > $FC  # メモファイルが無い場合
test -f $FM || echo 100 > $FM  # メモファイルが無い場合

UPSCap=`cat $FC`
UPSmsg=`cat $FM`
test $C -gt 120 && C=$UPSCap  # 120% を越えていれば異常と判断し、前回値に補正

if [ $C -lt $UPSCap ]; then  ### 放電 ; 前回との減少変化を検知
  if [ $C -lt 50 ] && [ $((C+9)) -lt $UPSmsg ]; then  # < 50% ; 10% 減少毎にメール作成
    echo $C > $FM

    Tl=`echo "$T" | sed -r "s/( ##)$/ *DOWN* ( $C% )\1/"`  # 減少メールのタイトル作成
    # echo "タイトル: $Tl"  # debug 確認用
    echo -e "`date`\n$Msg$DW$C %" | mail -s "$Tl" -r "$Rt" "$To"    # メールの転送
  fi
else
  if [ $C -gt $UPSCap ]; then  ### 充電 ; 前回との増加変化を検知
    if [ $C -gt 50 ] && [ $((C-14)) -gt $UPSmsg ]; then  # 50% < ; 15% 増加毎にメール作成
      echo $C > $FM

      Tl=`echo "$T" | sed -r "s/( ##)$/ *UP* ( $C% )\1/"`  # 増加メールのタイトル作成
      # echo "タイトル: $Tl"  # debug 確認用
      echo -e "`date`\n$Msg$UP$C %" | mail -s "$Tl" -r "$Rt" "$To"    # メールの転送
    fi
  fi
fi
echo $C > $FC  # 今の容量を記録

AC100V電源を止めても、2時間近くはバッテリーで動作していますが、しばらく待っているとスマホにメールが送られてきます。

備忘録として、単体での起動なら例えば /home/sunao/bin/ の下にスクリプトを置いて起動できますが、cron からの起動ではスクリプトが見付けられずにエラーとなります。cron では、最低限のPATH設定となっているからです。

crontab -e で、起動時間や起動スクリプトを編集する定義の中で、さらに先の行に、PATH= 定義を記述して実行モジュールを読み込むディレクトリをリストしておくとパスが省略されていても起動できるようです。

$ crontab -e

# m h  dom mon dow   command
PATH=/home/sunao/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

##### UPS バッテリーの変化でメール作成 ######
*/5 * * * * ups-check-mail.sh > /dev/null

スマホには、8 〜 9 分間隔で 10%減のメールが届きます。逆に充電時は、11 〜 12 分間隔で 15%増のメールが届きます。気休めですがメールが送られると少し安心できます。

まだ手を加えたい箇所はあるもののネット共有サーバーとして利用できそうな状況になってきました。

Linux 立上げ時の自動起動

最近も日常に追われすぎていて、何をやっても中途半端に中断してしまい、続きがいつになるか分からない日々が続いています。

今回の作業背景

PCを利用していて痛い目に何度も遭っている経験から、今最重要課題と捉えているのが、作業結果を意識しないでできるバックアップ環境を作ることだと考えています。私は普段使いの Linux (Ubuntu) をセットアップしているノートPCを日常で利用しているのですが、その中で作業した内容はある程度無意識で定期的に共有サーバーにバックアップしています。

そのバックアップ方法は、単純な方法で cron を利用して rsync コマンドで、定期間隔の非同期でネットワークサーバーに転送する方法で実現しています。転送されたサーバーからは更に1日1回の頻度て他のサーバーにもコピーしています。

常にバックアップしているのに、では何が問題なのか、実は普段利用することも少ない Windows系 OSもデュアルブートできる環境で、Linux で実現できていない一部のアプリを利用することも時にはあります。その中で作業した内容については適切なバックアップができないでいます。意識してコピーする方法なら今でも面倒な作業として出来るのですが、無意識でバックアップして欲しいのが本音です。

そこで壁に当たりました。自動的に Windows パーティションをバックアップするには、

  • Windows を操作しているタイミングでの自動バックアップ
  • Linux で操作しているタイミングでの自動バックアップ

普段の利用は、Linux なので、負荷増になる無用なバックアッププロセスが常時稼働するのは避けたいので、Windows から Linux に切り替えるタイミングでの実行が理想だろうと考えて、過去の定番な方法 SysV init 立上げプロセスでの rc.local を模索したのですが、システム立上げ時に実行することが出来ないようです。機能しないのかタイミングでエラーしているのかは不明です。

最近の Linux システムは、立上げ時の方法が従来の SysV init から systemd に変わっているようで、私のノートPCも変わっているような気がします。そこで試行錯誤してみることにしました。

参考にしたサイトは、作り方を事細かく説明してくれています。


ここからが作業の試行錯誤の本題

実行したことをすぐに忘れる自分のための備忘録です。

Linux 起動時に、一度だけ Windows パーティションの一部を共有サーバーにバックアップする。Linux 立上げ前に Windows を利用していたかは問題外として、バックアップを実行したタイムスタンプをバックアップエリア内に残しておくこととします。

実際の組込み前に、参考にしたサイトの手順を自分の学習と動作確認のために実行してみることから始めます。他の情報の説明によると systemd に登録するサービスの指示書をユニットファイルと呼んでいるようです。

パッケージ名: NoteStartUpRun で、ユニットファイル名: note-startup-1st.service としてみました。何かちょっとネーミングがおかしいかなとも思いますが、私の頭の中では最初に実行する処理なので -1st を付けてみました。まぁただの名前なのでここから始めます。

サービス(ユニットファイル)の登録は、 /etc/systemd/system/note-startup-1st.service になるようで、この中には登録するサービスの情報を決められた書式で記述するようです。

そして実際に動作させるプログラムは、パッケージ名で管理するディレクトリに記述するようですが、 /opt/NoteStartUpRun/bin となっていて、一般的な実行形式のコマンドを入れる bin に集めているようです。そこで疑問ですが、パッケージディレクトリには、bin 以外に本来は何が置かれているのでしょう…深く考えないで進めます。

systemd の動作を確認する雛形作り

参考サイトがカレントで作成して、それを該当するディレクトリにコピーして、所有者を root に変更したり、アクセス権の変更をしているので、私もその方法を踏襲します。

$ vi note-startup-1st.service
[Unit] 
Description = Note Private AutoRun
After=network-online.target remote-fs.target nss-lookup.target
ConditionPathExists=/opt/NoteStartUpRun/bin

[Service]
ExecStart=/opt/NoteStartUpRun/bin/note-stup-1st.sh
Restart=no
Type=simple

[Install]
WantedBy=multi-user.target

$ sudo cp note-startup-1st.service /etc/systemd/system
$ sudo chown root:root /etc/systemd/system/note-startup-1st.service
$ sudo chmod 644 /etc/systemd/system/note-startup-1st.service
$ vi note-stup-1st.sh
#!/bin/sh
exec /usr/bin/env python /opt/NoteStartUpRun/bin/Python-Sample.py

$ sudo mkdir -p /opt/NoteStartUpRun/bin
$ sudo chmod 755 /opt/NoteStartUpRun/bin
$ sudo cp note-stup-1st.sh /opt/NoteStartUpRun/bin
$ sudo chown root:root /opt/NoteStartUpRun/bin/note-stup-1st.sh
$ sudo chmod 755 /opt/NoteStartUpRun/bin/note-stup-1st.sh

実際に動作するサンプルプログラム

最終的に起動されるサンプルプログラムは、bash や ruby または python でも構わないのでしょうけど、参考サイトにある例をそのまま丸コピーしてきました。検証作業の説明も丁寧に行われているので、見比べるのにも最適なので利用させて頂いています。例では python で組まれた1秒毎にメッセージを書き出す無限ループの処理で、Python-Sample.py として、次の記述です。

$ vi Python-Sample.py
#!/usr/bin/env python
import sys
from time import sleep
if __name__ == '__main__':
  while True:
    print "Hello world %s" % (sys.argv)
    sys.stdout.flush()
    sleep(1)

$ sudo cp Python-Sample.py /opt/NoteStartUpRun/bin
$ sudo chown root:root /opt/NoteStartUpRun/bin/Python-Sample.py
$ sudo chmod 755 /opt/NoteStartUpRun/bin/Python-Sample.py 

サービスとして定義している note-startup-1st.service により note-stup-1st.sh が起動されます。その中で単純にサンプルプログラムの Python-Sample.py を起動しています。

作成したユニットファイルやサンプルプログラムの確認

作成したユニットファイルやパッケージ内のプログラムの所有者とアクセス権の確認をしておきます。

$ ls -l /opt/NoteStartUpRun
合計 4
drwxr-xr-x 2 root root 4096  1月  9 15:01 bin
$ ls -l /opt/NoteStartUpRun/bin
合計 8
-rwxr-xr-x 1 root root 175  1月  9 15:01 Python-Sample.py
-rwxr-xr-x 1 root root  77  1月  9 14:54 note-stup-1st.sh
$ ls -l /etc/systemd/system/note-startup-1st.service
-rw-r--r-- 1 root root 276  1月  9 14:41 /etc/systemd/system/note-startup-1st.service

茶色の部分の root ユーザーと 755 及び 644 が確認できました。

サンプルプログラムの単体動作検証

無限ループでメッセージを書き出すサンプルプログラムを単体で起動して、 [Ctrl+C] で強制停止して動作の確認をしておきます。

$ sudo /opt/NoteStartUpRun/bin/Python-Sample.py
Hello world ['/opt/NoteStartUpRun/bin/Python-Sample.py']
Hello world ['/opt/NoteStartUpRun/bin/Python-Sample.py']
Hello world ['/opt/NoteStartUpRun/bin/Python-Sample.py']
Hello world ['/opt/NoteStartUpRun/bin/Python-Sample.py']
Hello world ['/opt/NoteStartUpRun/bin/Python-Sample.py']
^CTraceback (most recent call last):
  File "/opt/NoteStartUpRun/bin/Python-Sample.py", line 8, in 
    sleep(1)
KeyboardInterrupt

単体では問題なくメッセージが書き出されるようです。


ユニットファイルを systemd に登録

ここからは、systemd へのサービス(ユニットファイル)の登録と検証作業になるようです。ユニットファイル等を追加や変更した後には、必ず次のコマンド sudo systemctl daemon-reload を実行します。

そして一緒にステータスも確認しておきます。

$ sudo systemctl daemon-reload
$ sudo systemctl status note-startup-1st.service
● note-startup-1st.service - Note Private AutoRun
   Loaded: loaded (/etc/systemd/system/note-startup-1st.service; disabled; vendor preset: enabled)
   Active: inactive (dead)

ステータスで表示される Loaded: 行のカッコ内の1つ目と2つ目のセミコロンの間の disabled となっているのは、自動起動が無効になっているということのようで、自動起動できるように設定します。

自動起動が行われるように設定

$ sudo systemctl enable note-startup-1st.service
Created symlink from /etc/systemd/system/multi-user.target.wants/note-startup-1st.service to /etc/systemd/system/note-startup-1st.service.
$ sudo systemctl status note-startup-1st.service
● note-startup-1st.service - Note Private AutoRun
   Loaded: loaded (/etc/systemd/system/note-startup-1st.service; enabled; vendor preset: enabled)
   Active: inactive (dead)

ユニットファイルの定義内に、[ Install ] の WantedBy= で定義しているユニットにリンクが張られ、先ほどの /etc/systemd/system/note-startup-1st.service; の後の disabledenabled に変わっています。

これで再立ち上げで自動実行されるようになっているはずですが、その前にコマンドで起動して確認したり、停止させる操作をして動作を確認します。

systemd の手動起動と停止の確認

ユニットファイル名を指定したコマンド sudo systemctl start note-startup-1st.service で起動できます。

$ sudo systemctl start note-startup-1st.service
$ sudo systemctl status note-startup-1st.service
note-startup-1st.service - Note Private AutoRun
   Loaded: loaded (/etc/systemd/system/note-startup-1st.service; enabled; vendor preset: enabled)
   Active: active (running) since 火 2018-01-09 15:13:41 JST; 12s ago
 Main PID: 7997 (python)
   CGroup: /system.slice/note-startup-1st.service
           └─7997 python /opt/NoteStartUpRun/bin/Python-Sample.py

 1月 09 15:13:44 MITA-NY40S note-stup-1st.sh[7997]: Hello world ['/opt/NoteStartUpRun/bin/Python-S
 1月 09 15:13:45 MITA-NY40S note-stup-1st.sh[7997]: Hello world ['/opt/NoteStartUpRun/bin/Python-S
 1月 09 15:13:46 MITA-NY40S note-stup-1st.sh[7997]: Hello world ['/opt/NoteStartUpRun/bin/Python-S
 1月 09 15:13:47 MITA-NY40S note-stup-1st.sh[7997]: Hello world ['/opt/NoteStartUpRun/bin/Python-S

起動されて1秒毎にメッセージが書きだされているのが確認できます。

次は、sudo systemctl stop note-startup-1st.service コマンドで停止して結果をステータスで確認してみます。

$ sudo systemctl stop note-startup-1st.service
$ sudo systemctl status note-startup-1st.service
note-startup-1st.service - Note Private AutoRun
   Loaded: loaded (/etc/systemd/system/note-startup-1st.service; enabled; vendor preset: enabled)
   Active: inactive (dead) since 火 2018-01-09 15:14:44 JST; 4min 47s ago
  Process: 7997 ExecStart=/opt/NoteStartUpRun/bin/note-stup-1st.sh (code=killed, signal=TERM)
 Main PID: 7997 (code=killed, signal=TERM)

 1月 09 15:14:37 MITA-NY40S note-stup-1st.sh[7997]: Hello world ['/opt/NoteStartUpRun/bin/Python-S
 1月 09 15:14:38 MITA-NY40S note-stup-1st.sh[7997]: Hello world ['/opt/NoteStartUpRun/bin/Python-S
 1月 09 15:14:39 MITA-NY40S note-stup-1st.sh[7997]: Hello world ['/opt/NoteStartUpRun/bin/Python-S
 1月 09 15:14:40 MITA-NY40S note-stup-1st.sh[7997]: Hello world ['/opt/NoteStartUpRun/bin/Python-S
 1月 09 15:14:41 MITA-NY40S note-stup-1st.sh[7997]: Hello world ['/opt/NoteStartUpRun/bin/Python-S
 1月 09 15:14:42 MITA-NY40S note-stup-1st.sh[7997]: Hello world ['/opt/NoteStartUpRun/bin/Python-S
 1月 09 15:14:43 MITA-NY40S note-stup-1st.sh[7997]: Hello world ['/opt/NoteStartUpRun/bin/Python-S
 1月 09 15:14:44 MITA-NY40S note-stup-1st.sh[7997]: Hello world ['/opt/NoteStartUpRun/bin/Python-S
 1月 09 15:14:44 MITA-NY40S systemd[1]: Stopping Note Private AutoRun...
 1月 09 15:14:44 MITA-NY40S systemd[1]: Stopped Note Private AutoRun.

Active: の行が Active: inactive (dead) になり、プログラムは停止していることが確認できます。

一般ユーザーでジャーナルを確認

次にプログラムの出力ログを確認できる journalctl コマンドがあるとの説明なので試してみます。

$ journalctl -u note-startup-1st.service
-- Logs begin at 月 2018-01-08 19:44:01 JST, end at 火 2018-01-09 15:21:01 JST. --
 1月 09 15:13:41 MITA-NY40S systemd[1]: Started Note Private AutoRun.
 1月 09 15:13:42 MITA-NY40S note-stup-1st.sh[7997]: Hello world ['/opt/NoteStartUpRun/bin/Python-S
 1月 09 15:13:43 MITA-NY40S note-stup-1st.sh[7997]: Hello world ['/opt/NoteStartUpRun/bin/Python-S
 1月 09 15:13:44 MITA-NY40S note-stup-1st.sh[7997]: Hello world ['/opt/NoteStartUpRun/bin/Python-S

システム再起動による自動起動の確認

いよいよ待望の Linux の立上げによる自動起動の確認になります。ノートPCを再起動してステータスを確認します。

$ sudo systemctl status note-startup-1st.service
note-startup-1st.service - Note Private AutoRun
   Loaded: loaded (/etc/systemd/system/note-startup-1st.service; enabled; vendor preset: enabled)
   Active: active (running) since 火 2018-01-09 15:45:33 JST; 3min 15s ago
 Main PID: 1079 (python)
   CGroup: /system.slice/note-startup-1st.service
           └─1079 python /opt/NoteStartUpRun/bin/Python-Sample.py

 1月 09 15:48:38 MITA-NY40S note-stup-1st.sh[1079]: Hello world ['/opt/NoteStartUpRun/bin/Python-S
 1月 09 15:48:39 MITA-NY40S note-stup-1st.sh[1079]: Hello world ['/opt/NoteStartUpRun/bin/Python-S
 1月 09 15:48:40 MITA-NY40S note-stup-1st.sh[1079]: Hello world ['/opt/NoteStartUpRun/bin/Python-S
 1月 09 15:48:41 MITA-NY40S note-stup-1st.sh[1079]: Hello world ['/opt/NoteStartUpRun/bin/Python-S
 1月 09 15:48:42 MITA-NY40S note-stup-1st.sh[1079]: Hello world ['/opt/NoteStartUpRun/bin/Python-S
 1月 09 15:48:43 MITA-NY40S note-stup-1st.sh[1079]: Hello world ['/opt/NoteStartUpRun/bin/Python-S
 1月 09 15:48:44 MITA-NY40S note-stup-1st.sh[1079]: Hello world ['/opt/NoteStartUpRun/bin/Python-S
 1月 09 15:48:45 MITA-NY40S note-stup-1st.sh[1079]: Hello world ['/opt/NoteStartUpRun/bin/Python-S
 1月 09 15:48:46 MITA-NY40S note-stup-1st.sh[1079]: Hello world ['/opt/NoteStartUpRun/bin/Python-S
 1月 09 15:48:47 MITA-NY40S note-stup-1st.sh[1079]: Hello world ['/opt/NoteStartUpRun/bin/Python-S

問題なく起動されているようです。

その他の動作確認ツールを学習

今は直接必要がないのですが、参考サイトの説明では、実行時の 標準入力・標準出力・エラー出力 が、どこに繋がっているのか確認できるとのことですので今後のためにも試してみます。

上記出力からプロセスIDは、 1079 (PID: 1079) です。

$ sudo ls -l /proc/1079/fd
合計 0
lr-x------ 1 root root 64  1月  9 15:45 0 -> /dev/null
lrwx------ 1 root root 64  1月  9 15:45 1 -> socket:[21758]
lrwx------ 1 root root 64  1月  9 15:45 2 -> socket:[21758]

標準入力は、ダミーデバイスの /dev/null に割り当てられ、標準出力とエラー出力は共に UNIXドメインソケットに接続されているようです。参考サイトのコマンドもそのまま試してみます。

$ sudo ss -x -p|grep 21758
u_str  ESTAB      0      0       * 21758                 * 20776                 users:(("python",pid=1079,fd=2),("python",pid=1079,fd=1))
u_str  ESTAB      0      0      /run/systemd/journal/stdout 20776                 * 21758                 users:(("systemd-journal",pid=212,fd=38),("systemd",pid=1,fd=74))

知識がないので私には細かいことはわかりませんが、 systemd-journal が以前利用されていた syslogd を置き換えたログシステムとの説明があります。

systemd に関する説明資料

systemd に関しての説明がネット上の RedHat のサイトにありましたのでリンクをしておきます。


本題のシステム起動時のバックアップ

やっと自分で行いたい目的であるシステム立上げ時の自動バックアップ、の一歩手前まで辿りつけました。昔操作していた Windows システムも含めて自分で考えたサービスを追加して自動実行した経験はないので、何か少しワクワクした気持ちになります。

バックアッププログラムの雛形

パイソンのサンプルプログラムを置き換える実際のバックアッププログラムは、シェルスクリプトで記述した単純なもので、 Windows パーティションを一時マウントし、その一部のデータをリモートサーバーの特定のパスに rsync コマンドでコピーするものです。変更があった部分だけがコピーされるのですが、実行時のタイムスタンプを残すように少しだけ細工を追加しています。

$ cat /opt/NoteStartUpRun/bin/sunao-note_Windows-Documents-bkup
#!/bin/bash

server='192.168.x.21'                    # バックアップ先サーバー

bkup_D="$server:/home/bkup/sunao-Win-Doc/"   # バックアップ先 リモートサーバー

mntS='/mnt/ntfs'
bkup_S="$mntS/Users/sunao/Documents/"      # バックアップ元のベース

/bin/mount $mntS
echo "実行タイムスタンプ  `date`" > $bkup_S/TimeStamp.txt
/usr/bin/rsync -av --delete $bkup_S $bkup_D
/bin/umount $mntS

パイソンのサンプルと同じディレクトリにコピーされ、所有者とアクセス権の設定も確認して、単体動作では問題なくバックアップできています。

サンプルからバックアッププログラムへ置き換えと検証

次にユニットファイルを修正して、サンプルからバックアッププログラムに置き換えて、コマンドで実行してステータスを確認してみます。

$ sudo vi /opt/NoteStartUpRun/bin/note-stup-1st.sh
#!/bin/sh
exec /opt/NoteStartUpRun/bin/sunao-note_Windows-Documents-bkup 

$ sudo systemctl daemon-reload
$ sudo systemctl start note-startup-1st.service
$ sudo systemctl status note-startup-1st.service
● note-startup-1st.service - Note Private AutoRun
   Loaded: loaded (/etc/systemd/system/note-startup-1st.service; enabled; vendor preset: enabled)
   Active: inactive (dead) since 火 2018-01-09 16:13:53 JST; 26s ago
  Process: 3440 ExecStart=/opt/NoteStartUpRun/bin/note-stup-1st.sh (code=exited, status=0/SUCCESS)
 Main PID: 3440 (code=exited, status=0/SUCCESS)

 1月 09 16:13:51 MITA-NY40S ntfs-3g[3457]: Version 2015.3.14AR.1 integrated FUSE 28
 1月 09 16:13:51 MITA-NY40S ntfs-3g[3457]: Mounted /dev/sda4 (Read-Write, label "Windows", NTFS 3.
 1月 09 16:13:51 MITA-NY40S ntfs-3g[3457]: Cmdline options: rw,noexec,nosuid,nodev,uid=1000,gid=10
 1月 09 16:13:51 MITA-NY40S ntfs-3g[3457]: Mount options: rw,noexec,nosuid,nodev,user,allow_other,
 1月 09 16:13:51 MITA-NY40S ntfs-3g[3457]: Global ownership and permissions enforced, configuratio
 1月 09 16:13:53 MITA-NY40S note-stup-1st.sh[3440]: sending incremental file list
 1月 09 16:13:53 MITA-NY40S note-stup-1st.sh[3440]: TimeStamp.txt
 1月 09 16:13:53 MITA-NY40S note-stup-1st.sh[3440]: sent 3,991 bytes  received 61 bytes  1,620.80 
 1月 09 16:13:53 MITA-NY40S note-stup-1st.sh[3440]: total size is 24,092,416  speedup is 5,945.81
 1月 09 16:13:53 MITA-NY40S ntfs-3g[3457]: Unmounting /dev/sda4 (Windows)
lines 1-16/16 (END)

コマンドによる起動では問題なく実行されて、正常終了しています。

実際の立上げによるバックアップの検証作業

本番でのシステム立上げによる実行の動作確認です。

ノートPC再起動後の journalctl コマンドによる結果が次のようになっています。

$ journalctl -u note-startup-1st.service

-- Logs begin at 火 2018-01-09 16:24:34 JST, end at 火 2018-01-09 16:27:17 JST. --
 1月 09 16:25:12 MITA-NY40S systemd[1]: Started Note Private AutoRun.
 1月 09 16:25:14 MITA-NY40S ntfs-3g[1071]: Version 2015.3.14AR.1 integrated FUSE 28
 1月 09 16:25:14 MITA-NY40S ntfs-3g[1071]: Mounted /dev/sda4 (Read-Write, label "Windows", NTFS 3.1)
 1月 09 16:25:14 MITA-NY40S ntfs-3g[1071]: Cmdline options: rw,noexec,nosuid,nodev,uid=1000,gid=1000,user
 1月 09 16:25:14 MITA-NY40S ntfs-3g[1071]: Mount options: rw,noexec,nosuid,nodev,user,allow_other,nonempty,relatime,default_permissi
 1月 09 16:25:14 MITA-NY40S ntfs-3g[1071]: Global ownership and permissions enforced, configuration type 7
 1月 09 16:25:16 MITA-NY40S note-stup-1st.sh[1039]: ssh: connect to host 192.168.x.21 port 22: Network is unreachable
 1月 09 16:25:16 MITA-NY40S note-stup-1st.sh[1039]: rsync: connection unexpectedly closed (0 bytes received so far) [sender]
 1月 09 16:25:16 MITA-NY40S note-stup-1st.sh[1039]: rsync error: unexplained error (code 255) at io.c(226) [sender=3.1.1]
 1月 09 16:25:16 MITA-NY40S ntfs-3g[1071]: Unmounting /dev/sda4 (Windows)

結果は残念ながらエラーしていてバックアップされない状況です。ユニットファイルの定義の中で、立上げプロセスの実行条件の After= で定義している箇所を色々と変更してみましたが効果がありませんでした。

最初は認証の sshd 等のプロセスが立上がっていないのが原因ではないかとか色々と試行錯誤しましたが、解決には至りませんでした。ネットワーク環境が立上がってから少し安定する時間が必要なのかもしれません。

systemd の依存関係を確認するツール

Systemdのサービスの依存関係を調べる方法 というサイトがありました。ここではグラフ形式にプロットして、ブラウザの Firefox で見る方法が説明されていてとても参考になりました。

最終的にバックアップできるように修正

最終的な修正は、立上げで特に早い段階でバックアップする必要もないので、ユニットファイルの After= に、立上げが一番遅いと思われる multi-user.target を指定して、バックアッププログラムが起動されてから実際のバックアップ動作が開始する前に 5分待つように sleep 300 を追加しました。

$ cat /etc/systemd/system/note-startup-1st.service

[Unit] 
Description = Note Private AutoRun
After=network-online.target multi-user.target
ConditionPathExists=/opt/NoteStartUpRun/bin

[Service]
ExecStart=/opt/NoteStartUpRun/bin/note-stup-1st.sh
Restart=no
Type=simple

[Install]
WantedBy=multi-user.target

$ cat /opt/NoteStartUpRun/bin/sunao-note_Windows-Documents-bkup
#!/bin/bash

server='192.168.x.21'                    # バックアップ先サーバー

bkup_D="$server:/home/bkup/sunao-Win-Doc/"  # バックアップ先位置

mntS='/mnt/ntfs'
bkup_S="$mntS/Users/sunao/Documents/"       # バックアップ元のベース

sleep 300           # 安定するように 5分待つ
/bin/mount $mntS
echo "実行タイムスタンプ  `date`" > $bkup_S/TimeStamp.txt
/usr/bin/rsync -av --delete $bkup_S $bkup_D
/bin/umount $mntS

待ち時間を追加する前は毎回エラーしていました。実際には、 sleep 180 の3分でもバックアップ動作は正常に行われていたのですが、余裕を持たせて sleep 300 にしています。

systemd ツールの利用結果

systemd の立上げ時間は、次のコマンドで表示され、 plot を付加して実行するとグラフ形式で svg ファィルを作成できるようで、ブラウザの Firefox で表示した最後の一部のみをここでは取り出しています。

$ systemd-analyze
Startup finished in 3.340s (firmware) + 7.713s (loader) + 6.703s (kernel) + 47.235s (userspace) = 1min 4.992s
$ systemd-analyze plot > startup.svg
$ firefox startup.svg

上記画像の右下角に、下から5番目に multi-user.target が表示され、その下に今回作成したバックアップ処理の note-startup-1st.service の表示がありますので、立上げプロセスの最終で起動されているのが確認できます。

なお立上げプロセスは、systemd-analyze コマンドの実行により、総計で約1分5秒程掛かっていることがわかります。その大半の 47秒を userspace が占めていることがわかります。

完成した立上げでのバックアップ

特に書き換えるデータがなく、実行時のタイムスタンプファイルのみがコピーされているだけの正常なバックアッププロセスを、最後にステータスとジャーナル表示の両方で載せておきます。

$ sudo systemctl status note-startup-1st.service
● note-startup-1st.service - Note Private AutoRun
   Loaded: loaded (/etc/systemd/system/note-startup-1st.service; enabled; vendor preset: enabl
   Active: inactive (dead) since 木 2018-01-11 19:50:00 JST; 11min ago
  Process: 1198 ExecStart=/opt/NoteStartUpRun/bin/note-stup-1st.sh (code=exited, status=0/SUCC
 Main PID: 1198 (code=exited, status=0/SUCCESS)

 1月 11 19:49:58 MITA-NY40S ntfs-3g[2846]: Version 2015.3.14AR.1 integrated FUSE 28
 1月 11 19:49:58 MITA-NY40S ntfs-3g[2846]: Mounted /dev/sda4 (Read-Write, label "Windows", NTF
 1月 11 19:49:58 MITA-NY40S ntfs-3g[2846]: Cmdline options: rw,noexec,nosuid,nodev,uid=1000,gi
 1月 11 19:49:58 MITA-NY40S ntfs-3g[2846]: Mount options: rw,noexec,nosuid,nodev,user,allow_ot
 1月 11 19:49:58 MITA-NY40S ntfs-3g[2846]: Global ownership and permissions enforced, configur
 1月 11 19:50:00 MITA-NY40S note-stup-1st.sh[1198]: sending incremental file list
 1月 11 19:50:00 MITA-NY40S note-stup-1st.sh[1198]: TimeStamp.txt
 1月 11 19:50:00 MITA-NY40S note-stup-1st.sh[1198]: sent 3,991 bytes  received 61 bytes  1,620
 1月 11 19:50:00 MITA-NY40S note-stup-1st.sh[1198]: total size is 24,092,416  speedup is 5,945
 1月 11 19:50:00 MITA-NY40S ntfs-3g[2846]: Unmounting /dev/sda4 (Windows)
lines 1-16/16 (END)
$ journalctl -u note-startup-1st.service
-- Logs begin at 木 2018-01-11 19:44:14 JST, end at 木 2018-01-11 19:50:53 JST. --
 1月 11 19:44:57 MITA-NY40S systemd[1]: Started Note Private AutoRun.
 1月 11 19:49:58 MITA-NY40S ntfs-3g[2846]: Version 2015.3.14AR.1 integrated FUSE 28
 1月 11 19:49:58 MITA-NY40S ntfs-3g[2846]: Mounted /dev/sda4 (Read-Write, label "Windows", NTF
 1月 11 19:49:58 MITA-NY40S ntfs-3g[2846]: Cmdline options: rw,noexec,nosuid,nodev,uid=1000,gi
 1月 11 19:49:58 MITA-NY40S ntfs-3g[2846]: Mount options: rw,noexec,nosuid,nodev,user,allow_ot
 1月 11 19:49:58 MITA-NY40S ntfs-3g[2846]: Global ownership and permissions enforced, configur
 1月 11 19:50:00 MITA-NY40S note-stup-1st.sh[1198]: sending incremental file list
 1月 11 19:50:00 MITA-NY40S note-stup-1st.sh[1198]: TimeStamp.txt
 1月 11 19:50:00 MITA-NY40S note-stup-1st.sh[1198]: sent 3,991 bytes  received 61 bytes  1,620
 1月 11 19:50:00 MITA-NY40S note-stup-1st.sh[1198]: total size is 24,092,416  speedup is 5,945
 1月 11 19:50:00 MITA-NY40S ntfs-3g[2846]: Unmounting /dev/sda4 (Windows)
lines 1-12/12 (END)

 

ラズパイ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
   .... リストされた対象が順次更新されます

グーグルマップのセキュリティアップ?

ぃやぁ〜参りました。

自分の写真を以前から公開していますが、その中で撮影地点の確認と移動の経路を軌跡として描画表示するために、グーグルマップを利用させて頂いてます。
公開前の編集時点では、手元のノートパソコンを利用して、以前はそのURI サーバー名を http://localhost/ として記述して、自分自身のノートパソコン内で起動しているウェブサーバーを指定していました。

その中でグーグルマップに表示させる情報も編集していて、データの作成と確認ができてから、問題ない状態になった時点で公開サーバーに転送していました。
最近になってだろうと思うのですが、localhost ではサーバー名が不適だとして、エラーになっているようで、マップ表示が出来なくなっていて、編集や確認が出来なくて困りました。

仕方なく公開しているサーバー名の URI を含ませた名前で、適当にデバッグ用のサーバー名を考えて、apache2 の定義を少し直して、最近では触ることの無かった /etc/hosts に、自分自身のループバック 127.0.0.1 として追加して、急遽対応しました。
取敢えず対処できたので、問題はなかったのですが、一時は状況がわからずに焦りました。
セキュリティ向上の一環なのでしょうか?

そして 1日2日経過した頃に、再び手直しでもしようかと思い操作すると、今度は擬似サーバー名でもグーグルマップが利用できなくなっているようでした。これは困ったことです。

仕方なく、公開サーバー名で自分自身のウェブサーバーにアクセスするように /etc/hosts を編集して確認すると、全く問題なくグーグルマップが表示されました。セキュリティでは色々な問題があるので強化は仕方がないことですが、どのように編集して公開するか悩みます。

それと、公開サーバーは他にも問題を抱えていて、スクリプトを自分で組んで公開していますが、自分で組んだとしても作ってから年月が経ち記憶が薄れ、肉体は老朽化が進み頭の回転は遅くなり、最近は HTML5 CSS3 とかも一般化してきたようで、利用している jQueryライブラリも時代に合わせ進化しているようで、見直してどうにか手を加えようと考えているのですが、思うように進められていないのが現状です。


以下は、後から追加 2017-09-16

今現在は、 http://localhost/ でのアクセスでも、グーグルマップが起動されて正常に利用できているようです。数日前のゴタゴタは何だったのでしょうか。

グーグルでの単なるミスだったのでしょうか、ミスはどこでも起きますから、私なんて時々ミスしてリカバリーに追われることがあります。グーグルマップの利用では、過去にも利用できなくて、それに吊られるように他の機能も利用できなくなって、仕方なくグーグルマップ機能を切り離すオプションを追加したこともありました。

その時には、数日待ってから確認すると、特に問題もなく利用できていましたので、今回もあり得ることだとは思っていたのですが、セキュリティのポリシーが変更になったのかと考えたのと、早めに公開写真の編集を終わらせたかったので仕方なく対応していました。