サーバー運用とPC日記

　先日、Netcommons３のヴァージョンを、３.３.４から３.３.５に上げようと、いつもの手順で作業していました。

しかし、今まで見たこともないエラーが・・・

しばらく考えていましたが、情報も得られずエラーメッセージも分からない。

でも、もう一度良く見てみると、

Error: ReflectionMethod::__construct(): Argument #2 ($method) cannot be null when argument #1 ($objectOrMethod) is an object
> #0 /var/www/html/vendors/cakephp/cakephp/lib/Cake/Console/Shell.php(358): ReflectionMethod->__construct()
> #1 /var/www/html/vendors/cakephp/cakephp/lib/Cake/Console/Shell.php(423): Shell->hasMethod()
> #2 /var/www/html/vendors/cakephp/cakephp/lib/Cake/Console/ShellDispatcher.php(222): Shell->runCommand()
> #3 /var/www/html/vendors/cakephp/cakephp/lib/Cake/Console/ShellDispatcher.php(66): ShellDispatcher->dispatch()
> #4 /var/www/html/app/Console/cake.php(35): ShellDispatcher::run()

ｐｈｐの動きに問題？

このサーバーのｐｈｐ環境は７.４だったはずなんですが、調べてみたらなんと８.１に上がっていました！

こまめにＯＳのアップデートをしていますが、その時にｐｈｐもアップデートされてしまうのは知りませんでした。

最初にＯＳインストールした時、ｐｈｐのリポジトリ登録は手作業でやったんですが、この関係？

ここで、Netcommonsプロジェクトにメールで相談してみました。

手掛かりがなければ、ｐｈｐを元の７.４に戻してみようと思っていました。

ところが何と！

嬉しいことに、すぐ返信が届いたんです！

「Netcommons３はｐｈｐ８に対応させる予定はあるが、まだ見通しが立っていません」

「サーバーをｐｈｐ７環境に戻して使って下さい」

この情報で、対処の見通しがつきました！

# update-alternatives --config php

このコマンドを実行すると、出力は、

選択肢 パス 優先度 状態
------------------------------------------------------------
* 0 /usr/bin/php7.4 74 自動モード
1 /usr/bin/php7.3 73 手動モード
2 /usr/bin/php7.4 74 手動モード

現在の選択 [*] を保持するには <Enter>、さもなければ選択肢の番号のキーを押してください

といった感じでメッセージが出るので、

希望するヴァージョンのｐｈｐを選んで番号を入力、Enterすれば使用ｐｈｐの切り替えが簡単に出来ます！

この後Netcommonsのヴァージョンアップの作業を再度やってみたら、無事にアップデート完了しました！

Netcommonsプロジェクトの中島様、それからプロジェクトの皆様、

本当にありがとうございました！

　今朝の作業でつまづいてしまったため、

明朝３／４(金) ４：００～４：３０の予定で

再度、Netcommonsのアップデート作業を行います。

この間、サイトを一時停止します。

作業が終わりましたら、サイトを通常動作に戻します。

よろしくお願いいたします。

　３／３(木) ４：００～４：３０の予定で

Netcommonsのアップデート作業のため

サイトを一時停止します。

作業が終わりましたら、終了の連絡と共にサイトを通常動作に戻します。

よろしくお願いいたします。

　ファイルサーバーのリモート On Off ですが、電源 On は Windows クライアント側での WOL（フリーソフト）は使用感がとてもいいです。

初期設定の NIC の MAC アドレス取得とかも非常に楽で、すぐ使えるようになります。

ファイルサーバー側の OS が完全に立ち上がってから音を鳴らしてくれる機能も good です！

サーバー側が完全に立ち上がる前に Samba にアクセスすると、ファイルアクセスだけでなく、OS のコマンド操作、Webmin からのアクセスも出来なくなることがあるので。

さて、サーバーのリモート電源 Off ですが、SSH を使ってコマンドを打ち込むやり方しか思い当たりませんでした。

Webmin からでも電源 Off は出来ますが、手順が多くちょっとやっかいなんです。

そこで、

Windows クライアントに SSH クライアントソフト Rlogin（フリーソフト） を入れておきます。

初期設定はちょっとだけで済みます。

次回の接続からはログインまで自動です！

さて、そこからですが、自分ならいつも su- コマンドで root に遷移してからシャットダウンコマンドを打ち込んでいました。

今回は、ちょっとだけですが、より簡単な操作に出来そうだということで、使用ユーザーに権限が与えられる sudo コマンドを使うことにしました。

まず sudo をインストールし、sudoユーザーの設定ファイルを編集します。

　/etc/sudoers

ファイルに、権限を与えるユーザについての行を書き込んで保存します。

　# User privilege specification

の下に

　gonta ALL=(ALL:ALL) ALL

といった記述を書き込めば、ユーザー gonta には root 権限が与えられた上でコマンド操作が出来るようになります。

指定したコマンド操作をする時だけ root になれるということですね！

ユーザー gonta がサーバー機をリモートシャットダウンしたい時は、

　gonta@server :~$ sudo shutdown -h now

とコマンドを打ち込みます。

その後パスワード入力を求められるので、パスワードを打ち込めば命令が実行されます。

なんだ！ 結構手間がかかるじゃないか！ と思いますが、

コマンド操作の入力履歴は、キーボード「↑」を打てばワンタッチで出てくるんですね！

ですから、サーバーの電源 Off の操作は

　① Rlogin を起動（タスクバーにアイコンを置いておくと良い）

　②ログイン先をクリックしてログイン（自動）

　③「↑」キーを１回押して、（sudo shutdown -h now を表示させて）「Enter」キーを押す

　④パスワードを入力して「Enter」キーを押す

以上です！

面倒そうに見えますが、一連の流れでスムーズに操作出来ます！

Linux 系 OS での操作ですが、良かったら試してみて下さい。

　Sambaのファイルサーバー機が嫁入りする前に、もう少し細かいところを手直ししてみます。

PowerOnにしたあと、まずはUEFIのpost画面が出ますが、この画面の表示時間を短くするには、UEFI設定で「fast」といった項目を選びます。

このマザーボードでは「ultrafast」設定がありました。

そしてUEFIがデバイスのチェックや初期化を終えると、OSのブートメニューが表示されます。

Debian１１では、Grub2のブートメニュー画面ということになります。

このブートメニュー画面の表示時間がデフォルトでは結構長めなのでこの表示時間を短くしたいと思います。

　/etc/boot/grub/grub.cfg

ファイルを直接編集して、

　timeout = 5

等と書き換えて上書き保存しても上手くいきません。

起動時にファイルが書き戻されてしまいます。

　/etc/default/grub

ファイルを編集するようです。

　timeout = 1

と書き換えてみました。

このあと、

 ＃ update-grub

を忘れずに。

これで、Power On から起動するまでの時間がかなり短縮されました！

　本日は代休ということもあり、昨日の作業の続きに没頭しました。

Debian１１のSambaサーバー（ＮＡＳとして仕上げる）ですが、クライアントマシンからリモートで電源ｏｎに出来ないと不便です。

ということで、Wake on Lan の設定作業です。

今までの認識では、起動させようとするマシンは眠っている訳ですから、BIOSの設定だけでOSの設定は関係ないと思っていました。

今回は、マザーボード側で「Power On By PCI/PCIE Devices」をオンにしておく必要がありました。

ネットワークインターフェイスデバイスはPCIEデバイスの１つなんですね。

network boot はこの設定では関係ありません。

さて、これだけで起動してくれると嬉しいな～ と思ったんですが、やっぱりこれだけではダメでした・・・

そういえば・・・

以前 Windows 機を Wake on Lan させようとした時、デバイスマネージャーで NIC のプロパティをいじった記憶があるんです。

そこで、Debian 機の Wake on Lan 設定を検索で何とか見つけ出しました。

/etc/init.d ディレクトリ内に

wakeonlan といったファイルを作っておき、

そのファイルに以下を書き込みます。

　#!/bin/bash

　ethtool -s eno1 wol g

　exit

このファイルの権限を変更します。

　＃chmod +x /etc/init.d/wakeonlan

さらに、このファイルを自動起動するよう設定します。

　＃update-rc.d -f wakeonlan defaults

また、

/etc/network/interfaces ファイル最終行に以下を書き加えます。

　iface eno1 inet static

　ethernet-wol g 

以上の設定で、ようやくDebianサーバー機を wake on Lan させることが出来ました！

クライアント側の wake on Lan ソフトですが、ｎWOL というフリーソフトがとても良く作られていました！

また、電源Ｏｆｆですが、やはりSSHクライアントソフト（Rlogin等）を使ってコマンドを打ち込むようなやり方になりそうです。

　これ以外に行った設定は、ファイヤウォールはもちろんですが、IPV6無効化、ローカルネットワーク外からのアクセス禁止（SSH、Webmin、Samba）等です。

これで、このサーバー機は嫁入り出来る状態までに仕上がったと思います！ 

今回のストレージですが、WD-REDではなく東芝のＮＡＳ用ＨＤＤ１２ＴＢを２台使いました。

この２台をＯＳによるソフトウェアＲＡＩＤ１としましたが、ブートローダー grub は両方のＨＤＤにインストールしてあります。

　LinuxSambaによるWindowsファイルサーバー（ＮＡＳ）を作って知人宅に設置しようとしていたんですが、知人宅内のネットワークアドレスが自分の家でのネットワークアドレスと異なっていました。

ローカルＩＰアドレスは、通常 １９２．１６８．〇．△ のような数値になっていますが、この第３オクテット（〇）の値が、通常の値ではなかったんです。

ならば、こちらで設定をほぼ済ませてからＮＡＳを知人宅に持って行って、そこで最後の設定をすればいいや、と考えていました。

ＮＡＳはＬＡＮ内からのファイルアクセスの他に、LinuxServerの設定、修正、updateが出来るように SSH、Webmin が使えるようにしておく他、Serverの電源OnOffをリモートで出来るようにしておいた方がいいだろうと考えていました。

現状では、セキュリティ強化の面からWindowsUpdate等によって、以前は簡単に出来ていた事が出来なくなってきているようです。

現に、今回Sambaの設定でつまづいてしまいました。

ということで、知人宅と同じネットワークアドレスを作った上で、実験を繰り返しながらこのＮＡＳを完成させた方が良さそうです。

で、最近偶然に分かったことなんですが、自宅のＬＡＮ環境にもう１台のルーターを直列に入れれば、第３オクテットを変えたネットワーク環境が作れるんですね！

このやり方で今日、Debian１１のSambaファイルサーバーが９０％ほど完成しました！

あとは、Wake on lan が上手く動くように明日頑張ってみたいと思います！

　不具合の原因を素人なりに色々と考えながらいくつかの作業をやってみました。

①Netcommons3.3.4の不具合かもしれないと思い、3.3.3バージョンに戻してみた。

　→ 作業直後は正常に戻ったように見えていたが、一晩後にはまた表示がおかしくなっていた。

②cashe、expireといったキャッシュ設定が悪さをしているかもしれないと考え、これらを無効にしてApacheを再起動。

　→ 変化なし

③google pagespeedモジュールを無効にしてみた。

　→ 嘘のように全く正常な表示に復帰！

　ＰＣからもスマホからも正常に表示されるようになった。

　Netcommonsも最新の3.3.4に戻した。

理由はどうしてなのか分かりませんが、とりあえずこれで様子を見てみます。

どうかこのまま正常動作していて欲しいと願っています！

何をやってもダメならサイト運用を停止しないといけなくなりますが、今はグループウェアとしても使っているのでサイト停止はしたくないんです。

　このサイトの表示に関する不具合についての正しい対処法が未だに掴めていません。

現時点での対処ですが、新しいNetcommons３.３.４ディレクトリを上書きして、アップデートコマンドを実行させるという作業を行いました。

この上書きの際、元ファイルのパーミッションを保持したままのコピーとし、最後にディレクトリとファイルの所有者をwebサーバーに変更しておきました。

これでしばらく様子を見てみます。

　１０月に入って、サイトのメンテ中に光モデムルーターを再起動して、WANからのアクセスがしばらく出来なくなったんですが、今回は復帰までの時間がちょっと長かったんです。

光モデムルーターを再起動すると、割り当てられているグローバルIPアドレスが変わります。

一方、DDNSサーバーへの通知は３０分おきにしかしていないので、DDNSサーバーが持っている情報は最長３０分は古いままです。

①最長３０分後、DDNSサーバーは更新情報を受け取ります。

②DDNSサーバーからDNSサーバーへ新しいDNS情報が通知されます。

①のあと、②はすぐに行われると思っているのですが、多くのDNSサーバーに情報が行き渡るのには時間がかかるでしょう。

　固定ｉｐを持っていないサーバーではこんな感じになり、WANからアクセスできない時間がしばらく発生してしまう訳です。

今回の件で、今まで何気なく利用させていただいてきたDDNSサービスについて、改めてありがたさを感じました。

自分はMydnsを使わせていただいているのですが、最近は国内の無料DDNSサービスはここだけになってしまったのではないでしょうか？

古くからあったアゴラ社のieserverはサービスを休止（停止？）しているようですので、Mydnsが最後の頼みの綱ということになります。

これまでの自分は、この無料DDNSサービスへの感謝が足りなかったと反省しているところです。

　もう一つ、Mydns の twitter に次のような内容が tweet されていました。

　Ban4ip は IPv4 及び IPv6 用の、/64のようなネットマスクでもBAN可能な防御（ロックアウト）ツールです。

ホワイトリスト（非制限アドレス）機能もあるので安心です。

このツールは、サーバーへの悪意あるアクセスをアクセスログの解析等によって防御するものらしく、Mydnsサーバーへのアクセスについて審査されていると思われます。

当然、自分のサーバーからもMydnsサーバーに毎日３０分毎にアクセスしているので、不正アクセスでないか審査が行われているものと推測されます。

DDNSサービスが動いているか停止しているか表示してくれる別サイトがあるのですが、自分はこのサイトの情報を見てMydnsのDDNSサービスがdownしているんだと判断していました。

現在も、この別サイトの情報によると、Mydnsサービスはdownしていることになっているのですが、どうも違うのではないかと思っています。

しばらく様子を見てみようと思っています。

また、Mydnsサーバーへのアクセスコマンドですが、とりあえず使用例にならって、curl から wget に変更しておきました。

　現在、２０時１６分ですが、ＬＡＮ内からブログ更新しています。

しかし、外部つまりＷＡＮからのアクセスが出来ない状況です。

お世話になっているＭｙｄｎｓのＤＤＮＳサーバーがダウンしているようなんです。

このサーバーが復旧してくれないと、このサイトはＷＡＮ上に公開できないのです・・・

ＤＤＮＳサーバーが復旧した時、この記事が見えているはずです。

　いつものようにサーバーOS（Debian10）のアップデートをしていたら、エラー表示が！

---@aaa:~# apt update

Err:4

https://packages.sury.org/php buster InRelease
The following signatures were invalid: EXPKEYSIG ********** DEB.SURY.ORG Automatic Signing Key <deb@sury.org>

W:

An error occurred during the signature verification. The repository is not updated and the previous index files will be used. GPG error: https://packages.sury.org/php buster InRelease: The following signatures were invalid: EXPKEYSIG ********** DEB.SURY.ORG Automatic Signing Key <deb@sury.org>

W:

Failed to fetch https://packages.sury.org/php/dists/buster/InRelease The following signatures were invalid: EXPKEYSIG ********** DEB.SURY.ORG Automatic Signing Key <deb@sury.org>

W:

Some index files failed to download. They have been ignored, or old ones used instead.

このエラーはGPGエラーで、署名が無効だと言っています。

アップデートファイルをダウンロードする時、GPGキーという公開鍵を使って正しい配布先からのファイルであるかのチェックをしているんですが、GPGキーには有効期限があるんです。

ということで、ＧPGキーを新たに取得してきます。

---@aaa:~# wget -O /etc/apt/trusted.gpg.d/php.gpg https://packages.sury.org/php/apt.gpg
--2021-05-02 11:00:22-- https://packages.sury.org/php/apt.gpg

Resolving packages.sury.org (packages.sury.org)... 2606:4700:3037::6815:1294, 2606:4700:3030::ac43:b696, 172.67.182.150, ...

Connecting to packages.sury.org (packages.sury.org)|2606:4700:3037::6815:1294|:443... connected.

HTTP request sent, awaiting response... 200 OK

Length: 1769 (1.7K) [application/octet-stream]

Saving to: ‘/etc/apt/trusted.gpg.d/php.gpg’

/etc/apt/trusted.gpg.d/php 100%[======================================>] 1.73K --.-KB/s in 0s

2021-05-02 11:00:22 (8.70 MB/s) - ‘/etc/apt/trusted.gpg.d/php.gpg’ saved [1769/1769]

新しいGPGキーを取得できたようです！

では、再度アップデートしてみます。

---@aaa:~# apt update

Get:1 https://packages.sury.org/php buster InRelease [6,823 B]

Get:7 https://packages.sury.org/php buster/main amd64 Packages [316 kB]

Fetched 316 kB in 3s (122 kB/s)

Reading package lists... Done

Building dependency tree

Reading state information... Done

24 packages can be upgraded. Run 'apt list --upgradable' to see them.

エラーなくアップデート出来ました！

新しい２４個のアップデートパッケージが見つかったので、この後 apt upgrade コマンドでこれらのパッケージを適用しました。

このGPGエラーは期限切れで発生するので、あせらずにGPGキーを再取得してアップデートしてみて下さい！

　全く偶然ですが、自宅サーバーで運用している Nextcloud に Talk というプラグインが用意されていて、通話、ビデオチャットも含めたチャット機能が備わっているのを発見！！

早速プラグインを有効にしてみました。

また、android、ios用のアプリも用意されていて、スマホに無料でインストールできます！

昨夜、早速娘とチャットのやり取りとチャット通話の実験をしてみました。

（娘のニックネームはネズミなんです！ 笑 ）

これ、ＬＩＮＥとほぼ同じ感覚で使えそうですね！

すごい！！

これでいけるかも。

しばらく色々な実験をして、安定に使えるか確かめてみたいと思います。

　阪神淡路大震災、そして東日本大震災でも経験したんですが、このような時、連絡を自由自在に取り合ったり、安否をすぐに確認したりということが難しくなりますよね？

このような事態に遭遇した時、どのように連絡を取り合うのか、いい方法がないか考えています。

例えば、３．１１東日本大震災の教訓から生まれた「ＬＩＮＥ」という素晴らしいアプリケーションがありますね！

ＬＩＮＥは災害時の安否確認等にも威力を発揮してくれると思うのですが、過去、システム障害が発生したことがあるそうです。

他のサービスでも同様だと思いますが、図中クラウド上のサーバーに多数の利用者のデータが集中すれば、さばき切れなくなることは予想できます。

自由に連絡が取りあえるシステムを何とか作れないでしょうか？

たとえば、レンタルサーバー上にチャット機能を持たせた簡単なサイトを作るとかです。

Peer to Peer接続であれば、サーバーを介さず１：１で通信できるので、緊急時の連絡システムとしてはこれが一番良さそうです。

ＬＩＮＥは、ユーザーＩＤなどのアカウント情報は管理していますが、データファイルやトーク履歴などはＬＩＮＥサーバーを介さずユーザー同士が直接管理しているそうです。

（しかし、実際の通話やチャットの中身のやり取りはPeer to Peerではないそうです）

　最近、ふと思いついたことがあるんです。

もし、自宅までの光回線が、クラウド上のサーバーまでの光回線と同じくらいの程度で安定であれば、ルーターやサーバー本体への電源をしっかりと確保した自宅サーバーでも使い物になるのではないかということです！

つまり大規模停電等が起こっても自宅までの光回線がダウンせず、サーバー周りへの給電は太陽電池と充電池を組み合わせたもので行うようなシステムにしておけばいいのではないか？

まだ実験の段階なので、運用中の自宅サーバーを使って試している最中です。

ＲｏｃｋｅｔＣｈａｔサーバー（ｓｎａｐインストールだともの凄く楽でした！）はインストールしてみましたが、緊急事態に突然初めてのユーザーが利用するには、初期設定等かなり面倒でした。

ＬＩＮＥと同程度に簡単にすぐ利用開始できるものがいいですね！

（続く）

　このサイトは自宅サーバーでの運用ですが、自宅サーバー運用はデメリットの方が非常に多い訳です。

自宅サーバーのデメリットは検索すれば沢山出てきますが、デメリットの中で最も怖いのは、

　①サーバーマシンから発火して火災が発生する！

　②セキュリティーを破られて不特定多数の方に迷惑をかける！

　自分でサーバーマシンを組み立てて、ソフトをインストールしてシステムを作るというのはもちろん楽しいことではありますが、上記のデメリットだけで充分大きなリスクですね！

自分のサーバーでは、今のところですが、運用当初よりトラブルはなく安定しているのですが、常に面倒を見続けなければならない状況はこれからも変わらないでしょう。

ところで、自分が自宅サーバーを始めた理由ですが、

　①職場と自宅の間の大容量ファイルのやり取りをする環境が必要だった。

　②一般的なクラウドを使って仕事で使うファイルをやり取りすることは当初職場では禁止されていたし、許可されていたとしても自分には抵抗があった。

　③校務でネット上のグループウェア（Netcommons２）を操作しているうちに、自分の仕事にも活用できそうだと思った。

　④音楽ファイルをサーバーに貯めておけば、ネット上でアクセスできる。容量が非常に大きな音楽ファイルでも自宅サーバーなら容易に実現できる。

　今の仕事を続けている間は、自分にとって①～③は重要ポイントなんです。

完全退職後は、①～③は不要になりますし、これらの一部機能はレンタルサーバー上で実現すればＯＫでしょう。

④は車の運転中にタブレット等を使って音楽を流しておくとかで残したい機能なんですが。

といった感じで、今のところは充分に気をつけながら自宅サーバーを運用していこうと思っています。

　実は今もう一つ、作りたいものがあるんです。

震災や風水害等の大災害が発生した時の連絡システム、安否確認が出来るシステムです。

災害時の連絡ツールはＬＩＮＥが良さそうですが、ＬＩＮＥでもシステム障害が起こったことはあるそうですし、ＬＩＮＥよりデータの流れがシンプルなものを作れないかということなんです。

この件についてはまた別の機会に書こうと思います。 

自分のWebサイトを今後どうするのか、いつまで運用できるのか、良く考えるんですが、

　①自分自身でサーバーマシン、システムのメンテ、サイトの更新が出来る時まで

　②このNetcommons等のWebアプリケーションの開発が続き、自分自身で更新していける時まで

　③無料DDNSサービスが継続するまで

さしあたってはこんな感じなんですが、②のNetcommonsに関しては不安があるんです。

自分が持っている程度のスキルでNetcommonsのメンテを続けていくためにはWeb上での多くの情報が必要ですが、現状では情報があまり得られていません。

Netcommonsの運営方針も昔とは異なってしまい、今後どうなっていくのか現時点では不透明です。 

自分もあと数年で教育現場から完全に引退すれば、グループウェアもあまり使わなくなってくるかもしれません。

　今日何気なくサイトを見ていたら、「Wordpressがグループウェア的に使える」といった感じの記事が目に留まりました！

Wordpressは、大規模なWebサイト構築に使われているCMSで世界中で広く利用されています。

また２０２０年の統計では、世界中のCMSの６０%以上、世界中のWebサイトの３５%以上のシェアを持っているソフトです。

Wordpressの運用情報は非常に多く、このシステムの構築とメンテナンスを続けていくことに関しては先が明るい感じがします。

Netcommonsのような高度なグループウェア機能はないかもしれませんが、ちょっと気になる情報でした。

現状では、例えば以下のようなプラグインを使うことでグループウェア機能を実現しているようです。

ということは、今後新しいプラグインも開発されていくかもしれませんね！

　Debian１０サーバーによるRAID１システムが出来上がったので、Sambaファイルサーバーの運用を再開しました。

ところが、Webminでディスクの状況を確認してみたところ、赤字で「degraded」の警告らしきものが出ていました。

degraded？

「劣化？　退化？　低下？」！！

異常の通知のようですね！

このディスクはWD社REDのNAS用モデルなんですが、Webサーバーのシステムディスクとして１年以上ノンストップ連続運転させていたお下がりなんです。

エラーも出ていないしまだ使えるだろうと思っていたんですが、やっぱりもうダメかな？ と調べてみることにしました。

すると、どうもこの前やった実験（RAID構築後に片側ディスクだけで起動するか）のあと、両方のディスクを接続し直しただけではRAID１システムは再構築されていないようだということが分かってきました。

RAIDが不完全なまま動いているようで、これではダメですね！

きちんと復旧させておかなければいけません。

そしてその復旧作業のあと、念のために、どちらの片側ディスクからも起動することをもう一度確かめておく必要があります。

もちろん、最終的には再度RAID１復旧作業を行って終わりにしておかないといけませんが。

こういう実験は今回のような自粛期間中にどんどんやっておきたいと思います！

外で動けるような日に室内に閉じこもって作業するのはイヤですからね！（笑）

　ソフトウェアＲＡＩＤは、当然ですが、ＯＳが立ち上がった後でないとＲＡＩＤが機能しません。

ということは、ＯＳが立ち上がるまではＲＡＩＤ動作ではないし、ＲＡＩＤ動作開始までは１本のみのディスクで動いているということになります。

ですから、起動ドライブ（ドライブ１）に不具合が発生してしまうと、起動さえも出来なくなってしまいます。

これを避けるために、「ドライブ２にもＭＢＲを用意しておきｇｒｕｂ 等のブートストラップローダーをドライブ２にもインストールしておけば良い」と書かれています。

しかし、今までこの作業をしてきませんでした。

ＲＡＩＤシステムが出来上がって機能し始めれば、トラブルが起こるまでは対応は必要ないし、「まあ後で対応すればいいや」と思いながら結局対応しないままになっちゃっていたんです。

さて、サーバーＯＳのインストールはインストールメディアから立ち上がるインストーラーに任せていますが、最後のｇｒｕｂインストールで／ｄｅｖ／ｓｄａを指定してインストールが終わった後に、再度ｇｒｕｂを／ｄｅｖ／ｓｄｂに手動でインストールするようにと、手引きには書いてありました。

ところが、この作業がエラーになってしまい上手くいきません。

試行錯誤している中で、今日試してみた作業がたまたま上手くいったので書いておきます。

　ＲＡＩＤ構築が終わったあと、インストールメディアをレスキューモードで起動させます。

①ディスク１、ディスク２をＲＡＩＤドライブとして認識させる。

②ＲＡＩＤドライブを構成している／ｄｅｖ／ｓｄｂを指定してｇｒｕｂをインストールする。

これでうまく行きました！

　もちろん、うまくいったかどうかの検証が必要ですね。

まず、ディスク２を外して電源を入れてみます。

起動してディスク１本のみの環境を作っているようです・・・

この後しばらくしてログイン画面となりました。

起動完了したようです。

　では、次にディスク１を外して電源を入れ、ディスク２からの起動を試みます！

立ち上がりましたね！

先ほどと同様、ディスク１本のみの環境を作っているようです・・・

この後、しばらくしてログイン画面が表示されました！

ディスク２からの起動もＯＫのようですね！

最後にディスクを２本とも元通りに接続して、電源を入れてみます。

２つのディスクを完全に同期させる動作を行っているようです・・・

このあと最終的な結果が表示され、ＲＡＩＤ１環境が完全に出来上がっていることが確認できました！

もう少し実験したいことがありますが、これで重要な一区切りまでは行けたようですね！ 

電源投入
　↓
BIOSによるデバイス初期化
　↓
ブートデバイスの決定
　↓
ブートストラップローダのロード
　↓
ブートローダの実行
　↓
OSの起動

PCの電源を投入すると、マザーボードのROM中のBIOSが起動。

このBIOSの初期化プログラムが、PCに接続されている各種デバイスの初期化を行う。

この過程が POST（Power On Self Test）。（起動直後に画面表示されている）

各種デバイスの初期化が終了すると、BIOSは次の段階に入り、起動するためのドライブを探す。

起動ドライブとなるのは、HDD、 CD-ROM、USBフラッシュメモリなど。

BIOSは起動ドライブを見つけるとそのデバイスをファーストブートドライブとして起動を試みる。

HDDの起動を例にすると、

BIOSはそのブートドライブの先頭セクタのロードという段階に移る。

HDDの先頭セクタは MBR（Master Boot Record）といい、MBRは1台のHDDに1つだけ。

BIOSはこのMBRをメモリ上にロードし、MBR領域にあるプログラムに制御を移す。

このMBR領域にあるプログラムを、ブートストラップローダと呼ぶ。

ブートストラップローダは、パーティションテーブルから起動フラグのあるパーティションを探す。

パーティションテーブルとは、複数のパーティションに関する情報が保存されているMBR内の１つの領域。

この起動フラグのあるパーティションにブートストラップローダから制御が移行。

このとき、ブートストラップローダから呼び出されるのが各基本パーティションにあるブートセクタ。

ブートセクタは各基本パーティションの先頭セクタのことを指し、PBR（Partition Boot Record）と呼ばれる。

PBRに制御が移行すると、そのPBRのプログラムが動作することになる。

このPBRにあるプログラムコードが IPL（Initial Program Loader）で、OSを起動させるためのブートローダの残りの機能を呼び出す機能を持つ。

MBRやPBRは512バイトと非常に小さな領域しかなく、その中のIPLのデータサイズはさらに小さい。

この小さなデータサイズにOSを起動させるためのブートローダのプログラムを全て格納できない。

そのため、IPLはブートローダの一部のプログラムコードを持ち、ブートローダの残りに機能はPBRの後続セクタに置いている。

IPLから呼び出されたブートローダが後続のOSのファイルを読み込んでいき、最終的にOSが起動する。

　普段PCやスマホで扱っているデータが壊れてしまう事はめったにないので、普段は安心しちゃっています。

ですが、やはりトラブルは突然起こるものです。

システムデータが壊れた場合は、PCが起動しなかったり、Ｗｅｂサイトが失われてしまったり（！）という、深刻な事態になってしまいます！！

そこで、改めてデータファイルの保管、システムの保護等について考え直してみることにしました。

　自分は、今までの様々なデータをLinuxSambaを使った自作ＮＡＳに保管していました。

そして、さらにこのデータをWindowsクライアントＰＣのセカンダリディスクに定期的にバックアップしていました。

このバックアップディスクはＷｅｂサーバーで連続稼働させていたお下がりで、いつ壊れてもおかしくないヤツなんですが、バックアップ用なので「まあいいか」と使い続けています。

そしてＮＡＳもＲＡＩＤ１で動かしていたので安心し切っていたんです。

　トラブルが起こったのは一昨年末でした。

家庭内ＬＡＮの第３オクテットを変更しようと作業した際、ＮＡＳ内部のDebian設定でつまずいてしまいDebianが起動しなくなってしまいました。

この時、ソフトウェアＲＡＩＤで組んでいたシステムであったのに、ＲＡＩＤシステムの復旧もＨＤＤ内のデータ救出も出来ませんでした・・・！

ＲＡＩＤの再構築も、セカンダリディスク（呼び方合ってる？）からのシステム立ち上げも出来なかったんです。

これらの方法の練習もやってなかったし、習得もしてなかったんですね・・・

こんな状況ではイザという時に対応なんか出来ませんね！

　そこで、再度ソフトウェアＲＡＩＤを構築する前に、曖昧だった次の知識についてまず調べることにしました。

　①ＭＢＲ

　②ＥＳＰ

　③ＵＥＦＩ

　④ＧＰＴ

　⑤ブートストラップローダー

　⑥grub

　⑦／boot

次に、実際に実験機でソフトウェアＲＡＩＤ機を構築して、故意にトラブルを起こしてみることにします。

そして、このトラブルに対処する手順を実習して習得しておこうと考えました。

　①実験的に片側のディスク（grubがインストールされていないセカンダリディスク）を外して挙動を調べてみる。

　② ①のあとに新しいセカンダリディスクを取り付けてＲＡＩＤを再構築し、ＲＡＩＤシステムを復旧させてみる。

これが出来るようになったら、

　①grubがインストールされていないセカンダリディスクに、grubを手動インストールしてセカンダリディスク単独でも起動できるようにしてみる。

　②grubがインストールされているプライマリディスクを外して挙動を調べてみる。

　③ ②のあとに新しいプライマリディスクを取り付けてＲＡＩＤを再構築し、ＲＡＩＤシステムを復旧させてみる。

　次年度に備えて、今日からこれらの作業に取りかかっていますが、かなり時間がかかりそうです・・・

後日、ここに備忘録を残しておこうと思っています。