PC設定覚書と雑記

　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ではないそうです）

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

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

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

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

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

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

（続く）