サーバー運用とPC日記

新年度の準備のため、サーバーの OS と php のアップデートをやって、Netcommonsの引っ越しもやろうとしていました。

いきなりやるのは怖いので、Debian１０のテストサーバーを作り、そこに php７.４をインストールして、テストをさんざんやりましたが・・・

エラーの連続で上手くいかない！

エラーも何種類か出てきて、apache、mysql、Netcommons、それぞれのエラーログを見て対処できたものもありました。

しかし、丸１日かかって色んな方法を試した結果、上手くいったのはディレクトリ丸ごとコピーの方法だけでした・・・

もちろん、データベースは元のバックアップをdumpファイルで作って、これを新規データベースにインポートするんです。

php７.２環境で出来たサイトを丸ごと持ってきてから、php７.４環境に出来たのは幸運だったんですが。

でも、この方法しか分からないということは、各サイトのNetcommonsディレクトリを定期的に丸ごとバックアップし、同時にデータベースのバックアップも取っておかなければなりません。

そして、作業中に気付いたんですが、Uploadディレクトリのサイズが異様に大きくなっていたんです！

自宅サーバーだからということで、写真等もサイズを圧縮せずに載せ続けていたのが原因でしょう。

この調子で運用を続けていけば、サイトの容量がどんどん大きくなり、外部サーバーへの引っ越しとかも出来なくなります。

うーん、どうしよう・・・

悩み中です。

予定より２時間半も余計に時間がかかってしまいました・・・

ＳＳＤにＥＦＩパーテイションを作成する所からつまづきました。

ただ、旧システムが入ったＳＳＤをそのままＳＡＴＡ接続して、新システムにマウント出来たのは助かりました。

この手が使えれば、Uploadディレクトリが肥大化しても短時間でコピーが出来ます。

しかし、今までのリストア方法が使えなかったので、今回はNetcommonsディレクトリを丸ごと持ってきたんですが、

今後もこれで上手くいくのかが分かりません・・・

Netcommons３.３.１サイトの引っ越し方法は、今までの方法では上手くいかなくなってしまいました。

今回のバージョンアップは、コアに関するDBテーブルが変更になったとありましたので、そのことが関係しているのかもしれません。

そこで、今回の引っ越し方法を新たに記録しておこうと思います。

今回は、新規ストレージにDebian１０をインストールし、phpは７.４を使用することにします。

さらに、同一サーバー内にあったowncloudはインストールせず、その代わりに、新規に作った別のサーバーマシンにnextcloudをインストールすることにしました。

nextcloud環境の作成については、おすすめの方法が見つかりましたので、別の機会に書きたいと思います。

また、引っ越し前のwebサイトは、閲覧不可にしてからmysqldumpでデータベースのバックアップファイルを取っておくことを忘れないように。

＜手順＞

　①サーバーマシン内の点検と清掃、メインメモリ抜き差ししてメモリ接点のセルフクリーニング

　②マザーボードBIOS（UEFI）のアップデート

　③ストレージ（SSD）の交換

　④SSDにEFIパーテイション２５６MB作成（マザボがBIOSタイプなら不要）

　⑤Debian１０最小構成インストール

　⑥ファイヤウォール設定

　⑦SSHサーバーインストール、ポート変更、ローカル以外からのアクセス不可、rootログイン不可に

　⑧php７.４リポジトリ追加して、php７.４、php追加モジュールインストール

　⑨Apache、MariaDBインストール（mysql-secureインストレーションも忘れずやっておく）

　⑩acpuインストール

　⑪/etc/php/php7.4/apache/php.iniの編集（file upload関係、opcache、acpu設定等）

　⑫webminリポジトリ追加して、webminインストール

　⑬webminポート変更、ローカル以外からのアクセス不可、rootユーザー削除設定

　⑭powerOFF後、旧SSDをSATA端子に接続してpowerON、新SSDから起動するよう注意（UEFIでは別画面で設定？）

　⑮新SSDにマウント用ディレクトリ作成して旧SSDをマウント

　⑯旧SSDのnetcommonsインストールディレクトリを、新SSDのドキュメントルートへ丸ごとコピー

　⑰コピーしたnetcommonsディレクトリ以下の所有者をapacheにしておく（Debianならwww-data）

　⑱mysqldumpファイル、ヴァーチャルホストディレクティブファイル、DDNS通知用スクリプトファイルを旧SSDから新SSDにコピー

　⑲poweroffして、旧SSDを外す

　⑳新規データベース作成（例　MariaDB [(none)]> create database nc3db default character set utf8;）

　㉑旧サイトからのデータベースリストア（例　MariaDB [(none)]> source /home/hokan/20200419/nc3db.sql;）

　㉒データベースuserを今までのuser名で作成（例　MariaDB [(none)]> GRANT ALL PRIVILEGES ON nc3db.* to ncuser@'localhost' IDENTIFIED BY 'password';）

　㉓データベース設定反映（MariaDB [(none)]> flush privileges;）

　㉔ルーターのポートフォワーディング設定

　㉕外部からwebブラウザでアクセスして、正常にログイン出来ればＯＫ！

　㉖webサイト閲覧不可を解除

以上です！

これでも割と手はかかりますね！

GoogleDrive、Dropbox、icloud、Onedrive等のオンラインストレージサービスを、容量制限なしにどこでも自由にしかも無料で使いたいと考えたことはありませんか？

今回、自分で試してみて、結構すんなりと構築できる方法を見つけたので、紹介したいと思います！

自分が今まで使っていた owncloud より多機能で、しかも構築が早く確実にセキュアに出来るんです！

使う手ですが、

　①省電力自作ＰＣを用意（省電力タイプならメーカー製パソコンでも可）

　②OSはLinux（WindowsServerでも可だが、高性能かつ無料ならLinuxで）

　③自宅用ネットワークプロバイダ契約（通常のインターネット契約で可）

　④DDNSサービスの設定（固定IP契約しているのなら不要）

こんな感じです。

では、具体的に。

①ですが、まず省電力マザーボードを選びます。

自分は、Asrock社のCPUオンボードタイプを良く使います。

今話題になっているRaspberry Pi を使うのもアリだと思いますし、これは面白そうだしいずれやってみたい！！

でも、省電力だからとノートPCを使うのはやめましょう！ 本体やアダプターの発熱で火事になった例を見かけましたから！

ストレージは、WD社のRedあたりがいいと思います。SoftwareRaid１で構築するとさらに良し。

②のOSです。Linuxは色々なディストリビューションがありますが、つまづいた時に症例や答えをWebで見つけやすいものにした方が絶対にいいです！

すると、Ubuntu、CentOSあたりでしょうか？ 自分は専らUbuntuの原型Debianを使っています。

Desktop環境（GUI）は入れずに、コマンドを打ち込んでいくCUI環境で作るのですが、CUIは難しそうだと思ったら、GUIサーバーでもいいんです。

でもCUIでも、SSH端末をクライアントで操作する時はコピペでどんどん操作出来ますし、WebminというGUI風の操作が出来る強力な助っ人もあるので、ぜひCUIサーバーに慣れて下さい！

あ、自分はセキュリティ上、SSHとWebminはローカル（LAN）外からのアクセスは受け付けないように設定しています。

③は自宅でパソコンとインターネットを使っている環境ならそれでOKです。

SoftBank社のAC電源に差すだけでWifiなんていうルーターがありますが、これでもいけそうかな？

④は、MyDNSをおすすめしておきます。

最後に！ これだけは覚えて欲しいのがテキストディタ ｖｉ の操作法です！

やや特殊ですが、使っているうちに慣れると思います。

コマンド文入力、コマンド文編集のために必須のツールです。ただし、ｖｉｍ、ｎａｎｏといったツールでもＯＫです。

さて、準備が出来たら、ＯＳをUSBメモリでインストールしましょう。

インストール終了したら、update、upgrade して最新の状態にします。

さて、それからは？

（１）SSHサーバーインストールして、ポート変更、rootログイン禁止設定

（２）ファイヤウォールUFWをインストール

（３）UFWのポートは443、123、SSH分、Webmin分だけ開けておきます。

（４）時刻合わせにntpサーバーインストールして設定変更

（５）snapdインストール

（６）snap install nextcloud

（７）source /etc/profile.d/apps-bin-path.sh

（８）nextcloud.manual-install

（９）nextcloud.enable-https self-signed

これで、Webサーバー、データベースサーバーを含めたnextcloud環境を一気に構築出来、https通信も可能になりました！！

Webサーバーの細かい設定、データベースの作成等も不要なんです！

あとは、DDNSサイトで取得したドメイン名〇〇〇で外部ブラウザからアクセスして下さい！

　https://〇〇〇

これでインストール完了です！

ちょっと説明を簡略化していますが、もし興味があったら調べてみて下さい。もちろん、問い合わせ頂いてもＯＫです。

（補足１）

自分のサーバーマシンからDDNSサービスを提供しているサイトに定期的にアクセスをする必要があります。

その時のスクリプト（実行）ファイルは、例えばこんな感じです。

　wget http://www.mydns.jp/login.html --http-user=mydns●●●●●● --http-password=ﾊﾟｽﾜｰﾄﾞ -O /dev/null

　（この方法ではip情報更新できなくなったようです。他にもやり方が色々あるようです）

自分は、このファイルを、/etc/cron.d/ディレクトリにおいて、webminで１５分おきに実行させています。

注意点は、rootがこのファイルを実行する時、所有者はrootで、パーミッションは700でないといけない点です。

（補足２）

インターネット契約をした時に提供されたルーターに、ポートフォワーディング設定が必要です。

つまり、DDNS設定をしたあとは、登録したドメイン名に外部からアクセスがあると、自分の所に信号が来るようになります。

それが、https通信（ポート443）であれば、自作したサーバーマシンに信号を通すようにする作業です。

ルーターのマニュアルを見て下さい。ipマスカレード設定等とも書かれています。

補足ですが、この機能のおかげでhttps以外の信号はサーバーマシンに到達できなくなる訳ですね！

（補足３）

Linuxサーバーを構築する時に、またサーバーの初期設定をする時にすごく参考になるサイトです！

色々なＯＳについて、またそれらのＯＳの最新版について、分かりやすく書かれています！

　https://www.server-world.info/

昨夜遅く、突然外部からこのサイトへのアクセスが出来なくなりました！

LAN内クライアントからサイトへのアクセスは可能で、クライアントからWAN外部サイトへのアクセスもいつも通り出来ていました。

DDNSサービスの提供元Mydnsの障害状況、Mydnsからの障害報告メールもチェックしましたが、異常はなさそうでした。

そこでまず、ルーターの設定を再確認し、ルーターの再起動を行いました。

そしてクライアントからnslookupコマンドでサーバー機のグローバルip情報確認したら、ie-serverのDNS情報は更新されているのに、Mydnsでは更新されていない。

ルーターの再起動などでWAN側のipアドレスが変わると、DNS情報も変更される訳ですが、

この反映には時間がかかるんだろう（今までは直ぐに反映されていたようなんだけど・・・？）と、明け方３時ごろだったので、まずはとりあえず寝ちゃうことにしました。

ところが、朝７時ごろ起きて確認したら、MydnsのDNS情報は相変わらず更新されていない。

cronjobを実行させてログを見てみると、Mydnsサイトにアクセスは出来ているのにログインが出来ていない模様！

もう一方のDDNSサービスie-serverへのアクセスは今まで通りログインまで出来ているのに、どうしたんでしょう？

そうだ！

Mydns側でセキュリティを向上させる等の対策が新たにされて、ログイン出来なくなったことは充分考えられます。

そこで次の手ですが、「wget http:// ・・・」のアクセスログイン法から「curl https:// ・・・」の方法へ変更し、cronスクリプトファイルを書き換え、実行させてみました。

この方法で、ようやく３つのサイトをいつも通りWeb上に公開させることが出来ました！

と、ここまで書いてきた所で、突然このサイトが固まってしまい、apacheを再起動してもサイトが動かなくなってしまいました！

そこで、サーバーマシンを再起動しようとしたところ、全く予想外の事態が。

システムが、それにUEFIも立ち上がらない！

これには参りました・・・

しばらく考えたんですが、数年前電源ユニットが突然死したことを思い出しました。

業務用ノンストップタイプでもない電源を２４時間動かしていたので、これが一番怪しいと思ったんです。

ところが、電源を取り換えてみたんですが、原因はこれではなかった！

その次は、マザーボードからデバイスを徐々に外して起動を試みていくテストを続けました。

もう、珍しいけどマザーボードの故障だろうと諦めかけていた時、メインメモリを１枚だけ差した状態で起動！

しかも、もう１枚のメモリだけだと起動しない！

これで、特定のメモリの不良が原因だと分かりました！！

それなら、以前に使っていた２枚のメモリをデュアルチャンネルで動かすことにしました。

そして、念のためにMemtestを４時間弱かけて実行させました。

メモリーエラーはありませんでした！

しかし、DDNS関連はともかく、ハードウェアがなぜこのような状況になってしまったのか？

単に、メモリに故障が発生しただけなら直っているんですが、他の要因ということもあり得ます。

機械が壊れかかったまま動いているという状況だと、あとあと非常にやっかいなことになるんです。

原因が分からないままだということと、他のハードウェアも巻き添えで故障する可能性もあるんですね。

また、サーバーに対して外部からの攻撃も、あり得ないことではなくなってきています。

最近はハードウェアの設定を変更するような極めて高度な攻撃もあるそうですから！

そこで、サーバーへの外部からのアクセスを制限するように、設定を数か所変更しておきました。

はあ・・・疲れましたね・・・

さあ、これでキチンと直ってくれたでしょうか・・・？ 

自宅エリアではスマホは Wifi 接続にしないと、モバイル通信量がどんどん増えていきますよね？

このWifi接続にした時、LAN内の外部公開用Webサーバー、外部公開用Cloudサーバーに接続が出来なくなります。

その理由は、指定したURLをIPアドレスに変換する外部DNSサーバーは、WANでのグローバルIPアドレスを通知してくるのですが、

LAN内でのアクセスに必要なのは、プライベートIPアドレスなんです。

分かりやすく例えるなら、外から居場所を調べるには、東京千代田区永田町１－７－１といった住所が必要ですが、

その建物の中からは、２階の東から３番目の部屋といった情報が必要になるという感じですね。

ところが、特に iPhone 等のスマホを使わないのであれば、PC内のhostsファイルをちょこちょこっと書き換えてやれば、この件はすんなり解決してしまうんです！

実は、iPhone だって内部のhostsファイルを書き換えれば済んでしまうんですが、この行為は「脱獄」！ なんて呼ばれている禁じ手なんです・・・

これをやってしまうと、サポートが受けられなくなったり不都合がかなり出てくるらしいんです。

そこで、LAN内専用のDNSサーバーを立てよう！ということになる訳です。

我が家のLAN内には、Webサーバー以外に、Windowsで動いているラジオ録音用サーバーが常時動いています。

まずこのラジオサーバーにDNSサーバー「Bind」をインストールし、設定を試行錯誤で続けていました・・・

もう、自分には泥沼ですね・・・

設定ファイルを書く時のルールが細かくあって、半角スペースが全角スペースになっただけでもう動かないんです！

夕方の柴犬コータの散歩中に、そうだ！ と気付いたことがありました。

稼働中のWebサーバーにDNSサーバーを共存させても大丈夫だろうということです。

IPアドレスは当然同じになるんですが、ポートが違うので、別々にアクセスが可能だろうと。

散歩から帰宅してすぐにWebサーバーマシンにBindをインストールしました。

あれから延々６時間は経ちましたが、まだ終わりが見えません・・・

せめて、原因とか見通しとかわずかでも掴みたい・・・ 

今朝早朝３時半まで頑張ったんですが、DNSサーバーBindはどうしても上手く動かせませんでした。

checkconf、checkzoneコマンドも使って、構文エラーはずい分と解消されたんですが、定義文がどうしてもエラーになるんです。

自分は、DDNSサービスを２つのサイトから受けていて、Webでアクセスする全く異なるフルドメイン名が計４つもあるんです。

これをDNSの定義文に書いて実行しても受け付けてくれないんです。（複数ドメイン名は受け付けない？）

もう、クタクタです・・・

しかし、いまだにiPhoneのhostsファイルを書き換えること（脱獄）はやる気になれません！

そこで、最後の手を使うことにしました。

LAN内にプロキシサーバーを立てる手です。

RADIOサーバーはWindows機で動かしていて、このWindows機のhostsファイルはすでに書き換えてあります。

このWindows機にプロキシアプリをインストールしてみることにします。

プロキシアプリは、CCproxyを使ってみました。

動かしてみると、今までの苦労がウソのように解決！！

昼過ぎにやっと食べ物も口にして、カミさんのAndroidスマホの設定もやって、少しのんびりしていました。

が・・・

そう上手くは済まないものですよね！

CCproxyサイトから「ライセンス認証をしなさい」と通知が来ました！

フリーソフトと思っていましたが、違ってたんですね。

で、これはアンインストール・・・

では、ApacheをWindows機にインストールして、ApacheをProxyサーバーとして稼働させればいいんじゃないか？

ちょっと大変そうだけど、ApacheはLinuxでちょっとは馴染んでるし・・・

やはり時間はかなりかかりましたが、Windowsのコンパネの「サービス」、「イベントビューア」も上手く使わせてもらって、なんとかApacheの最新版をインストールできました！

そして、恐る恐る最後の設定をしてから、アクセス！

あれー？

Apacheの初期画面が出るだけ！

またまたググって、Apacheでプロキシサーバーを構築しているサイトを見つけました。

Proxyサーバーは代理サーバーであって、ここを経由させるだけなんですね。

環境定義文（http.conf）に「via proxy」の記載が必要でした。

これで、Apacheをもう一度再起動して、WifiLAN内のスマホから祈るような気持ちでアクセス・・・

成功です！ ついに完成しました！！

もちろん、出来たことは嬉しいんですが、

外で体を動かして汗ビショになってる方が気持ちいいですよね！ ？

昨日の続きですが、一応これで今回は落ち着きました。

たとえ話ですが、LAN内というのはＴさんの職場の中、WANは職場の外全ての場所だと思って下さい。

自分が外からＴさんに会いに行く時、住所録で住所を調べてＴさんの職場にたどり着けます。

　→　ここでの住所録がWANにあるDNSサーバーに相当します。

そして、職場の受付の方にＴさんの居場所を聞いて、Ｔさんの所にたどり着ける訳です。

　→　ここでの職場の受付の方がポートフォワーディングと同じ役目を果たしている訳です。

ところが、自分がすでにＴさんの職場内にいる時は、もう住所録でＴさんを探しても無意味な訳ですね。

LAN内からLAN内にあるサイトにアクセスを試みると、通常は外のWANにあるDNSサーバーに問い合わせに行く設定になっているので、上手くいかないという訳なんです。

さて、今回次に使った手は、LAN内に Proxy（代理）サーバーを立てる手でした。

この Proxyサーバーは、Proxyサーバーを稼働させているホストPCのhostsファイルをWANのDNSサーバーより先に参照するので、hostsファイルに記載されているLAN内の「居場所」をもとに目的のサイトにアクセスできる仕組みです。

実は、Proxyサーバーの積極的な使い方は、むしろ他にあるので、やはりLAN内専用のDNSサーバー構築が今後の課題です。

最後にもう一つ。

自宅のWindows機Radioサーバーは午前０時に自動シャットダウンして、午前５時に自動起動するように設定してあります。

昨日はこのWindows機に Proxyサーバー Apache を導入したんですが、

２４時間稼働している LinuxWeb サーバー機へ導入できないか、一生懸命考えていました。

すでにWebサーバー Apache が稼働しているところに２つ目のWebサーバーをインストールできるのか？

色々と調べてみましたが、 何とか行けそうな感じです！

エイヤッと、apt install Nginx でインストール実行！

インストールの最後にエラーが出るのは、ポート（８０）がバッティングしてしまうからです。

しかし、インストールは最後まで進むので、設定ファイルを書き換えてポート番号を変更し、Nginxを再起動させます！

これで２つめのWebサーバーを共存して起動させることが出来ました！

と、もう一息だったんですが、Nginx は初めてだったので Proxy設定が出来ませんでした・・・

そこで、２つめの Apache をインストール！

最初にインストールした Apache は、snapシステムで導入していたので、apt install apache2 で２つめの Apache はすんなりとインストール出来たんですね！

あとは、ポート番号を変更してApacheを再起動させ、Proxy の設定を行いました。

現在、この Proxyサーバーはしっかりと稼働してくれています！！（外部からのアクセスには関係していませんが）

今後、もし時間が出来れば、LAN内の複数サーバーを、仮想サーバー内で稼働させ、複数のサーバーマシンを出来るだけ少なくまとめていけるといいかな、と考えています。

この手は非常に合理的でカッコ良く、ベストのようにも思えるんですが、メンテナンスや故障対応は相当に大変そうです！！

それならば！

集中したアクセスが少ないオンラインストレージサーバー、Proxyサーバーあたりを Raspberry Pi で構築し、メインサーバーマシン内に設置してしまうのはどうでしょうか？

あ、出来ることなら、ProxyサーバーではなくDNSサーバーを構築したいですね。

電源もメインサーバーマシン内でもらうんです！

どうでしょうか？

また新しいことが分かりました！

でも、今度こそこれで終わりにしたいと思います！

LAN内専用のDNSサーバーって本当にないのかな？

いつも Bindのような設定の大変なソフトを使ってるんだろうか？

どうしてもこの疑問が頭を離れませんでした。（コータの散歩してる時も！）

そして、悪いクセでまた色々と調べ続けちゃったんです。

すると、YAMAHA社のルーターとかは、自身にDNS機能を持たせてあって、LAN内の名前解決に使えるとのこと。

でもこのルーターは高価で、それだけのためにこれを買うことは考えられません。

そう言えば、Windows機で自宅のネットワークを作った時、PCにつけた名前でアクセス出来た経験があるでしょう？

DNSサーバー設定していないのになぜ？

あれは、WindowsのNetbiosという機能で可能になっているらしいです。

そんなこんなでさらに検索していると、LAN内DNSサーバーDnsmasq という由緒あるらしいLinuxソフトを発見！！

もう、ホントにどうしてこれが昨日までの検索でひっかからなかったのか？！

検索の仕方がヘタクソだ！ と言われればそれまでなんですが・・・

そしてこのDnsmasq、設定もシンプルで分かりやすい！

すごい大発見！！（大げさですみません）

さっそくインストール！　そして設定も終わらせて起動させました・・・

何と、ついにLAN内DNSサーバーは完成に至ったんです！！（また大げさ・・・）

もちろん、WANにある外部サイトには、セカンダリDNSサーバーに問い合わせをしてアクセス出来るんです！

あ、昨日構築したプロキシサーバーは休止させました。（まだ残してはあります）

これで iPhone の写真や環境ファイルのバックアップ等も、自宅に居ても自分のオンラインストレージに保存できます！

iCloud の追加容量料金なんて払いたくないですからね。（笑）

さあ、今度こそ一件落着したんですが、またまたちょっと不思議なことを体験してしまいました・・・！

もしかすると気のせいかもしれないんですが、昨日のプロキシサーバー経由の方が、サイトからの反応が早い！？

えっ？　そんなバカな！

だって、データの流れは、プロキシサーバーを使うと、

Webサイトサーバー　→　プロキシサーバー　→　クライアント（スマホ）なんです。

LAN内DNSサーバー使用の時のデータの流れは、

Webサイトサーバー　→　クライアント（スマホ）となり、経路が短いんです！

ああ、それはDNSサーバーからの応答が遅いせいじゃないか？　と自分も最初は思いました。

でも、この軽量のDNSサーバーの応答が遅いんでしょうか？

Dnsmasqがサーバー機のhostsファイルを参照するだけだから、動作即完了ですよね？

プロキシ使用の方が速いとすれば、プロキシサーバーのキャッシュ機能とかが効いてるんじゃないでしょうか！？

リバースプロキシとかは、そのような効果も期待して構築するようですから！

あ、でも、今はもう手を出しません！

こんなことばかりやってると、他のことがお留守になってしまいますから！

もうすでに、時間を大量に費やしてしまっているんです・・・

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

もう一点。

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

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

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

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

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

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

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

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

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

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

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

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

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

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 で自動実行させるよう設定しておけば良い！

　職場で、授業や補講などでプレゼン風に文書、画像、動画、音声、スライド、アニメーション、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 のスロットに差し込むんですが、下の写真のヘッドフォン端子の左側がスロットです。

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

大丈夫でした！！

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

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

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

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

そこで、

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

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

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

以上です。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　①ＭＢＲ

　②ＥＳＰ

　③ＵＥＦＩ

　④ＧＰＴ

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

　⑥grub

　⑦／boot

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

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

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

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

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

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

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

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

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

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

電源投入
　↓
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が起動する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

起動完了したようです。

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

立ち上がりましたね！

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

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

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

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

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

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

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

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

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

degraded？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（続く）

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

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

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

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

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

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

すごい！！

これでいけるかも。

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

　いつものようにサーバー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キーを再取得してアップデートしてみて下さい！

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

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

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

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

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

　１０月に入って、サイトのメンテ中に光モデムルーターを再起動して、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 に変更しておきました。

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

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

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

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

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

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

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

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

　→ 変化なし

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

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

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

　Netcommonsも最新の3.3.4に戻した。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 は両方のＨＤＤにインストールしてあります。

　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 から起動するまでの時間がかなり短縮されました！

　ファイルサーバーのリモート 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 での操作ですが、良かったら試してみて下さい。

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

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

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

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

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

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

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

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

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

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

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

　先日、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プロジェクトの中島様、それからプロジェクトの皆様、

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

　デザイン性に優れた新しいウェブサイトを利用したい、という依頼がありました。

そこで、商業的なウェブサイトとしても利用実績が多く人気の高い WordPress でサイトを作ってみることにしました。

WordPress は CMS に分類される Web アプリケーションです。

オープンソースソフトで無料で利用できます。

構築の仕方ですが、

　① Web サーバーを用意

　　レンタルサーバーと契約、又は自前のサーバーを作る

　② データベースを用意

　　①のサーバー内に Mysql 等のデータベース環境を用意して、WordPress サイト用のデータベースを作成する

　③ WordPress 本体を WordPress.com サイトからダウンロードして、①のサーバー上で解凍し、ドキュメントルートに配置

　④ このサイトにアクセスして、初期設定を完了させる

これだけです！

興味さえあれば、難しくはありません。

最初は、自宅の LAN 内で１からサーバーを作ってみるのもすごく面白いですよ！

　ＭＳ社のインターネットエクスプローラーのサポートがついに終了となりました。

他のアプリケーションソフトと同様、サポートが終了されたソフトは使わないようにすべきでしょう。

ということなので、ＩＥ１１の代わりに他のブラウザを使うようにすればいいんです。

ところが、このブラウジングソフトの機能を使用したシステムが多数存在するようです。

例えば、メーカー提供のシステムをネットワークアクセスして使うような用途では、ほぼＷｅｂブラウジングソフトが使われているんですね。

このような時、システムを作成するメーカーは、Windows標準だったインターネットエクスプローラー使用を前提とした設計をしたんでしょう。

さて、一般的には、ＷｅｂブラウジングだけならブラウザソフトをEdgeやChrome等に変更すればいいだけで、

その時WindowsのＩＥ１１機能を無効にしておくと、より安全性が高まると思います。

　しかし、ＭＳ社Edgeのインターネットエクスプローラーモードを使おうという時は、

このWindowsシステム内のＩＥ機能を有効にしたままでないと上手く行きません！

ちょっと注意して下さい！

①Netcommons３サイト内のアクセスＵＲＬが書いてあるファイルですが、

インストールディレクトリ￥app￥Config￥application.yml です。

この中のアクセスＵＲＬ（１か所）を書き換えます。

②DynamicDNS等の設定は前もって済ませておく。

（certbot --apacheによるLetsEncrypt設定で、外部DNSに新ＵＲＬを行き渡らせておかないとダメ）

③次は、WebサーバーApache2の設定ファイルです。

まず、

＃a2dissite 〇〇〇.conf

で、該当サイトへのアクセスを無効にしておきます。

また、

＃a2dissite 〇〇〇-le-ssl.conf

も実行しておきます。

＃systemctl reload apache2 

④新しいＵＲＬ用の △△△.conf  を作成

⑤新ＵＲＬアクセスを有効にする。

＃a2ensite △△△.conf

＃systemctl reload apache2

⑥LetsEncrypt自動設定

＃certbot --apache

あとは対話形式で操作を選んでいけばサイトｓｓｌ化が完了！

　自分は、旧サイトで初めて Netcommons の運用を始めました。

その時のアクセスＵＲＬは、お世話になっている Mydns サイトで取得できるドメイン名を使うことになります。

その時、〇〇〇.mydns.jp より、〇〇〇.pgw.jp の方がかっこいい感じだと思い、ドメインはこれに決めました。

そして、ホスト名 www を付けて http://www.9monotaira.pgw.jp をアクセスＵＲＬとしたんです。

ずっとこれで運用していたんですが、ある時TREND.MICRO社の「サイト安全性チェック」で確認したところ、

この「安全」判定にはホッとしたんですが、

何と、サイトのカテゴリ評価は・・・

ん？　

出会い？！

出会い系サイト？！！

ヒドイでしょう？

汚名だー！

「評価内容変更のリクエスト」は当然しました！

これで一度は改善されたんですが、

サイトをＳＳＬ化したところ、またも「出会い」カテゴリに分類されてしまったんです！

　しばらく考えてみたんですが、これは、ドメイン名 pgw.jp を使うことに問題があるのではないかと思いあたりました。

例えばこのドメインが悪用された例があるとか。

試しに、存在しないサイト名 https://kakuu.pgw.jp を「サイト安全性チェック」で同様にチェックしてもらうと、

予想通り「出会い」カテゴリと診断されました！

これで状況が掴めました！

こんな訳で、旧サイトのアクセスＵＲＬをドメインも含めて変更できないか考えることにしたんです。

　旧ＵＲＬのアクセスがあった時への対応はどうしようか迷ったんですが、

対応しないというのも不誠実だと思い、調べてみました。

「Redirect」を使うというのは何となく分かっていたんですが、

旧ＵＲＬを使ったサイトを用意する必要があるのではないかと思い込んでいました。

今回、時間がたっぷりとあったので、色々と調べたり考えたりしているうちに、

apacheの、旧ＵＲＬに対応したヴァーチャルホストの設定ファイルに、Redirect設定を書き込めば？

と思いあたりました。

旧ＵＲＬ用httpアクセス設定ファイル　〇〇〇.confの中身は

　<VirtualHost *:80>
　　ServerName 〇〇〇.pgw.jp
　　Redirect / https://△△△.mydns.jp/
　</VirtualHost>

だけです！

このあと、LetsEncrypt自動設定を行います。

＃certbot --apache

旧ＵＲＬ用の処理を選ぶと、旧ＵＲＬ用httpsアクセス設定ファイルを自動で作ってくれます！

さて、以上の設定を済ませて運用した結果ですが、

現状、これで旧ＵＲＬアクセスを新ＵＲＬサイトに導けているようです。

旧ＵＲＬサイトの特定のページも、新ＵＲＬサイトの同じページに誘導出来ています！

補足ですが、旧ＵＲＬ、新ＵＲＬ共に利用できるよう、

ＤＤＮＳサービスサイト（ＭｙＤＮＳ）に定期的に通知を送信し、ＤＮＳ情報を更新し続けていただいています。

　アップルは、スマートフォンなどの基本ソフト（OS）について

「ハッカーが端末に侵入する恐れのある安全上の脆弱性が見つかった」と発表しました。

アップルによると、

OSの脆弱性によって影響を受けるのは

「iPhone」の「6S」以降のモデル、

第5世代以降の「iPad」

「iPadプロ」のすべてのモデルなどです。 　

アップルは、

ハッカーがこの脆弱性を利用して端末を乗っ取ったり、

悪意を持って作成されたWEBコンテンツを通じて端末に侵入することができる、

といった恐れがあるとしています。 　

アメリカ政府のサイバーセキュリティ当局は

「ハッカーはこれらの脆弱性を悪用する可能性がある」

と警告していて、

できるだけ早く必要なアップデートを行うようユーザーに呼び掛けています。

8/20(土) 4:49配信

　自分の自宅サーバー内のサイトのメンテナンス（バックアップ等）についてです。

低ＴＤＰの安価な新型マザーボードが出るタイミングで、

マザーボードとストレージ（ＳＳＤとＨＤＤ）を交換し、ＯＳ（Debian）もヴァージョンアップしてきました。

ところが、今回はまだ新型マザーボードが発表されていません。

そこで、ハードウェアの交換を待たずに、Webサイトのバックアップのみ昨夜行いました。

現サイトは個人運用ですから、

サーバーの故障や破壊があった時は、

状況によってはサイトも復旧できず、全て内容が失われることになります。

例えば地震や火災などで、サーバーマシンごと完全に壊れてしまうリスクはゼロではありません。

そんな時は、さすがに仕方ないとあきらめようとは思っています。

しかし、このサイトに備忘録として書き留めてある内容などは、自分にとってかなり貴重なものですし、

昔の想いや考えを過去に遡って読めるようにしておくことも、やっぱり自分には貴重なことです。

そこで、やはり、バックアップといった自分で出来ることは、定期的にやっておこうということになります。

＜Netcommonsサイトのバックアップ＞

　①データベースのバックアップと、バックアップファイルの保管

　②インストールディレクトリをそのままコピーして保管

＜Wordpressサイトのバックアップ＞

　①Wordpressに実装されているバックアップ機能を使い、バックアップファイルを保管

現状では、この方法が最も手っ取り早いのではないかと思います。

素人的な方法だと思いますが、サイトのuploadディレクトリが肥大化していたりしても、

ローカルサーバーですし、ハードディスクを追加してそこにＳＳＤ内のファイルをコピーしたりも簡単に出来ます！

さらに、自宅内であっても、別の部屋のバックアップサーバーにファイルコピーをする等すれば、

多少であっても安全性は高まるでしょう。

　家庭用ＡＣ電源の極性について、最も一般的な注意事項は、

「電気工事その他配線の際、接地極を必ず指定された側に接続する」というのがあります。

接地極と大地は常に同電位ですから、通常、人が接地極に触れたとしても感電はしません。

電極に直に人が触れることはほとんど無いはずですが、

例えば電球のネジ側の極には触れてしまう危険性があります。

ですから、電球のネジ側の極には、接地側の線を配線しなくてはならない規則になっています。

また、電気製品の金属部分を触った時に、

感電まではしなくてもピリピリする感覚を経験したことはないでしょうか？

このピリピリする感覚は、電源プラグを逆に刺し直すと低減することがあります。

感電を避けるという観点だけから見ても、電気製品の電源プラグの刺し方で差が生じるのです。

自分は今まで、ＡＣ電源の極性については、

感電を避ける理由で「大地に対して電位差が生じないように」意識していました。

　ところが、今日初めて、

電源プラグの刺し方によってはWifiルーターが不安定になる（！）

という記事を見つけました！

Wifi系の機器は電源ノイズが大敵だと。

そして、「Wifiを含めたネットワーク機器の電源は、極性を合わせてＡＣ電源に繋ぐべきだ」

とも書かれていました！

Wifiを使うスマートプラグに接続の極性があるのも、そういう理由だったのか！

と初めて納得出来ました。

また、自宅のWebサーバー、ルーター、ハブ等、

全て電源の極性を合わせて、正しく接続してみようと考えているところです。 

＜参考資料＞

　最新版 NetCommons3.3.6 が、ほぼ１年ぶりにリリースされました！

「重大なセキュリティバグの修正」が含まれるとのことでしたので、

先ほどupdateを済ませました。

関係の方々に感謝申し上げます！

　仕事で使っているモバイルＰＣのマウスですが、

Bluetoothマウスの接続切れが、設定変更等どうやっても直せませんでした。

代わりにＵＳＢポートに無線レシーバーを刺してワイヤレスマウスを使っていました。

Bluetooth機能がＰＣに内蔵されているのに、仕方なくこの手を使っていたんです。

で、つい最近、ＯＳやドライバも頻繁にアップデートしているんだから、もしかしてと思い、

Bluetoothマウスを繋いでみました。

そうしたら、接続切れがうそのように無くなっていて快適にマウスが使えるんですね！

今は安定してBluetoothマウスが使えています。

ＯＳ、ドライバーが最新のものになったからだろうと、その時あまり深くは考えませんでした。

今日、何気なくBluetooth関連の検索をしてみて初めて分かったんですが、

Bluetooth規格もどんどんヴァージョンアップされていて、現在はｖ５．２なんだそうです。

そしてこのBluetoothのヴァージョンアップは、ファームウェアをアップデートしないとダメなんです。

ファームウェアということは、Bluetoothデバイスのハードウェアを直接制御するプログラムなので、ＰＣ本体のメーカーの提供がないとダメな訳です。

ＯＳやドライバーのアップデートではダメなんですね。

幸い、自分の使っているDELL社は、ファームウェア（ＢＩＯＳも）、ドライバー等のアップデートを頻繁に出してくれています。

他のメーカーも、おそらくこのようなサポートをしているんじゃないでしょうか？

Bluetoothマウスの接続が改善されたのは、ファームウェアアップデートのおかげだったかもしれないのです。

また、他のデバイスのファームウェアアップデートでも、基本的機能の追加や改善が期待できると思います。

これからも、特にＩＴ機器の進化の度合いは加速していくと思われます。

そんな中で、デバイスに新機能が必要になったとします。

どうすればいいか？

昔ならハードウェアを交換するしかなかったと思います。

現在では、ファームウェア、ＢＩＯＳのアップデートにより、

ある程度のハードウェア更新が可能になっているという概念なんだと思います。（間違っていたらご指摘願います・・・）