サーバー運用とPC日記

　いつものようにサーバー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がインストールされているプライマリディスクを外して挙動を調べてみる。

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

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

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

　iPhone、iPadのiOSですが、現在ver14.01です。

やはり職場でも、アプリが動かなくなったとか、ログインできなくなった、という話が良く聞こえてきます。

動かなくなったアプリの中に自分も使っているものがありました。

でも、自分にとって使う頻度の少ないアプリだったので今は困っていません。

ＯＳのアップデートでは、セキュリティ面で後退することはなく必ず改善されているはずだと思っているので、それ以外の不具合が出る可能性があっても、自分はすぐにアップデートしてしまいます。

万一セキュリティ上の不具合が見つかった場合ですが、すぐに次のアップデートが公表されます。

アプリ等の不具合は、少し時間がかかっても解消されるはずです。

ということで、クライアントのWindows、サーバーのDebianも直ぐにアップデートしてしまっています。

iPhone、iPad用OSの最新版「iOS14」が配信されることが明らかになりました。

日本では１８日未明からダウンロードできるようになるとのことですが、不具合の可能性もあり、更新にはデータのバックアップなどの注意が必要なようです。

インストール済みで現在使っているすべてのアプリがiOS14に対応しているとは限らないのです。

対応完了まで更新は慎重に判断して欲しいとアナウンスされていますので注意して下さい！

すぐに更新せず、ちょっとの間様子を見た方がいいでしょう。

　９／１２に NetCommons3.3.2.patch1 がリリースされていましたが、

「これは重大なセキュリティバグの修正パッチ」とアナウンスされていたので、すぐにこのパッチを当てる作業を行いました。

クライアントＰＣにいったんダウンロードしたこのパッチファイルをサーバーにアップして解凍し、これを NetCommons3.3.2 インストールディレクトリに上書きするだけです。

よって、サイトは一時停止せず通常動作のまま作業しました。

ただ、自分は root ユーザーとして作業したため、最後にインストールディレクトリ以下の所有者を「Webサーバー」に再度変更しておく作業を付け加えました。

　サーバーメンテナンス作業は正常に終了しました！

サイトも正常動作に戻っています。

　９／６(日)１９：００～１９：３０の予定で

サーバーメンテのためサイトを一時停止します。

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

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

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

　このサイトからファイルをダウンロードするとファイル名が文字化けしていましたが、システム開発エンジニアの方のアドバイスにより修正作業を行いました。

作業の結果、この件は正常に修正されました。

　また、サイト内検索ボックスにキーワードが思ったように入力できない件ですが、まだ修正されていません。（特にスマホからの検索）

そこで、

まず何も入力せずに検索ボタンをクリック（タップ）して下さい。

すると別の検索ボックスが現れますが、この検索ボックスにはキーワードが自由に入力できるはずです。

システム本体が修正されるまで、この手でしのいで下さい。

以上です。

　職場で、授業や補講などでプレゼン風に文書、画像、動画、音声、スライド、アニメーション、etc を見せるためには PC が必要になります。

ここで、通常の授業の流れを滞らせることのない「素早い操作と素早い表示を即座にさせる」ことが重要なポイントだと自分は思っています。

すると、通常のマウスの操作よりタッチパネルの操作の方が圧倒的に早いんです。

例えば、マウスでのクリックが連続するような場面では、タッチパネルでのタップの方が素早く出来ることは想像できると思います。

ショップなどでビジネスマンがタブレットを素早く操作しているのを見たり、自分で実際に操作してみればはっきりと実感出来るでしょう。

PC 付近にいる時は、タッチパネルをタップ、スワイプして操作し、PC から離れる時はエアマウスを使えばいいのではないかと思っています。（エアマウスはどの機種にするか考えている最中なんですが）

次に無線 LAN(Wifi) 環境のない所でもインターネット接続をさせるには、スマホと同様にモバイル接続できる PC が必要になります。

これはこの分野のパイオニアである iPad が最適だろうと思っていたのですが、WindowsPC との差を埋めるように使うことが自分にはどうしても出来ませんでした。

そこで、Windows の２in１タブレット PC に目をつけてずっと探していました。

余計な機能を付けない実質機能優先の Dell 社の13インチモデルならコロナ給付金で買える価格でした！

本当に武骨なデザインとカラーなんですが、性能的に信頼できるモデルです！

さて、モバイル接続させるには PC に LTE ユニットが内蔵されていることが必要なんですが、これは該当機種を選べばいいだけです。

最後にすごく大変だったのが SIM カードの購入でした！

「ユーザーが SIM カードを購入して PC に取り付ける」というのは、まだ一般的ではないようでした。

自分は現在 Softbank のモバイル回線を使っているので、数か所の Softbank 代理店に電話をかけて相談したんですが、どの店舗に聞いても即答がなく、扱いたくないような雰囲気でした。

自社で取り扱っているスマホやタブレットの販売がほとんどでしょうから、無理もないと思います。

昔と違って今は、ユーザー側で経験のある店舗、スタッフを選ばないとダメなんですね。

昨日やっと対応してくれそうな店舗を見つけました。

でも、自分が買ったタブレット PC のマニュアルにも、「MicroSIM」カードスロットの場所が示してあるくらいで、その他の解説は載ってなかったので対応してくれるのか不安でした。

予約時間に店舗に行ってみると、やはり店舗では経験のない機種で動作保証が出来ないと繰り返し念を押されました。（該当機種に動作実績がない）

ちなみに SIM カードには、ユーザー情報の他に、使用するPCのIMEI番号等が書き込まれてユーザーに渡されます。

このカードがセットされることで、その PC に限ってモバイル通信が出来るようになる訳ですね。

ですから、SIM カードの登録に問題がなく、電波の状況がいいのにモバイル接続が上手く出来ないといった場合は、LTE ユニットの性能が良くないといったハードウェア的な問題の方だろうと考えられます。

そう思っていたので、まあ大丈夫だろうと思っていました。

他の店舗では、２店とも「MicroSIM カードは取り扱っていない」という対応だったんですが、Web で調べてみるとどの店舗でも「マルチ USIM カード」を取り扱っているようで、このカードには切り込みが入れてあり、標準、Micro、Nano、と３つのサイズに切り取れるように作ってあるんですね！

でも、店員さんもこのことを知らない人もいるようでした。

下の写真ですが、上が PC に付属していた「eSIM」と呼ばれる SIM カード、下が購入した Softbank のマルチ SIM カードの残った部分です。

詳しくは分からないんですが、この eSIM は、店舗に出向かずにオンラインで登録できるタイプで、今後使われるタイプになってくるのではないかと書いてありました。（現状で Softbank では対応していないようでした）

さて、このマルチ SIM カードを自分のタブレット PC のスロットに差し込むんですが、下の写真のヘッドフォン端子の左側がスロットです。

今回は、モバイル接続してインターネットに繋がるか、特にドキドキしましたが・・・

大丈夫でした！！

これで、職場でもこのマシンはしっかり仕事してくれるでしょう！

Debian１０版

　① /etc/apt/sources.list に以下を追記

　　　deb http://mirrors.digitalocean.com/debian buster-backports main
　　　deb-src http://mirrors.digitalocean.com/debian buster-backports main

　     # apt update

　② # apt install python-certbot-apache -t buster-backports

　③ /etc/apache2/sites-available/　に、site1.conf、site2.conf、・・・を作成しておく。

　　site〇.conf 中にはsite のFQDNを書いておく。

　④ # apache2ctl configtest で構文エラーを教えてくれるので、必要なら .conf ファイルを修正していく。（Syntax OK が出れば完了）

　⑤ apache の ssl モジュール有効化。

　⑥ # a2ensite site1.conf　# a2ensite site2.conf ・・・ 

　⑦ # systemctl reload apache2

　⑧ ファイヤウォールでポート443を開ける。# ufw allow 'WWW Full' でＯＫ。

　⑨ # certbot --apache

　⑩ あとは、対話式に質問に答えていけば良い。複数サイトがある時はサイトを指定せず空「Enter」ですべてのサイトの設定を自動で済ませてくれる！ Redirectさせるかどうかまで聞いてくれる！

　⑪ ９０日で失効する証明書の更新は、 # certbot renew コマンド実行で更新される。cron で自動実行させるよう設定しておけば良い！

　サイトをＳＳＬ化するには、暗号化、ポート変更だけでなく、ＳＳＬ証明書が必要になります。

元々サーバーには、自分で自分を証明する「自己署名証明書」が最初から用意されています。

「自己署名証明」とは、自分自身で「私は安全ですよ」と証明するんですから、おかしなもので公的な証明にならないのは明らかです。

「自己署名証明書」を「オレオレ証明書」とは良く言ったものですよね。（笑）

あれ？ こんな証明書があらかじめ用意されているサーバーなんて怪しいじゃないか！ と自分も最初は思いました。

https 通信にはＳＳＬ証明書が必ず必要な仕組みになっているのですが、例えばネットワーク上で https 通信を自分だけで使う場合などは「オレオレ証明書」で問題ない訳です。

こんな理由でowncloud、nextcloud運用の際は「自己署名証明書」を使っていました。

ところが、最近nextcloudの運用でPCやタブレット端末で時々警告が出るようになって煩わしくなってきたんです。

それから、自分のWebサイトもＳＳＬ化する必要がありますね。

そこで、以前試したことがある LetsEncrypt について調べているんですが、すごく便利な方法を見つけました！

まだ色々と調べているんですが、この手を利用させてもらおうと今頑張って勉強中です！

昨夜０時からメモリーテスト（memtest86使用）を実施しました。

４時間ほどで終わるかな？ と思っていましたが、たっぷり倍の８時間かかりました！

前回のテストでは８GB４時間、今回１６GB８時間で容量に比例したキチンとしたテストをやってくれたようです。

テストの結果エラーは全くなしで、ひとまず安心です！

調べてみると、メモリーモジュールは時間が経って不良になるケースはままあるようです。

業務用サーバーではECC付メモリーのような高信頼品を使うんですが、

こうなるとマザーボードから対応していないとダメで、ハードウェアにかなりの額を投資する必要が出てきます。

ただ、民生用も昔以上にハードウェアの品質が向上し、ＰＣ自作派も多くなったので、デバイスの相性問題や不良率も相当に改善されているようです。

さて、メモリー関係でぜひやった方がいいことがあるんですが、

①新規購入してマシンを動作させる前にメモリーテストをしっかりとやっておく。（memtestがいいと思います）

②マシンのメンテナンス等で中を開けることがあったら、内部の掃除終了後に、メモリーを抜き差しする。

メモリーの抜き差しは結構力が要りますが、慎重ににやって下さい。

このメモリーの抜き差しですが、いわゆるメモリーとスロットの接点のセルフクリーニングをやる訳ですね。

故障ＰＣを見て欲しいと依頼されて、このメモリーの抜き差しだけで直った経験が何度かあるほどなんです。

もう一点。

今回からマシンメンテ中に、別のテスト用Webサーバーから「サイト休止中」の表示を出すようにしておきました。

AtomD525を使ったちっちゃなDebianサーバーマシンです。

先日、このWebサーバーマシンが不調になったことを書きましたが、原因はメインメモリの故障でした。

メモリーモジュールが故障するのは珍しいと思いますが、過去にも数回経験はありました。

ただ、常時稼働のWebサーバー機ですから、メモリーもバルク品ではなく信頼性のありそうなものを選んだんです。

JEDEC規格、永久保証の新品（panram社）でした。

ForNotePCとありますが、これは大丈夫でしょう。

さて、故障がはっきりしたので、販売店に問い合わせたところ、修理のため返品して下さいとの返事。

返品したところ、販売店経由でメーカーまで送られたようです。

結局修理不能で、新品を新たに送り返してくれました！

ということで、今回は稼働前にこのメモリーのテストを念入りに行うことにしました。（memtest実施）

万一、再度不良の場合もここで見つけておかなければなりません。

また正常ならば、はっきりと解決！ですね。

今日メモリーが届けられたので、販売店にも出来るだけ早く報告する必要もあるんです。

メモリーのテストはWebサーバーの動作を止めて行う必要があるので、今夜から明朝にかけてサイトを一時停止します。

またまた急で申し訳ありません！

テストは４時間ほどで終了するはずですが、遅くとも明日午前８時にはこのサイトを再開出来ると思います。

２４時からテスト開始します。