サーバー運用とPC日記

　サーバーマシンを運搬している最中は、この中の４つのＷｅｂサイトと１つのＷｅｂアプリは停止したままです。

移設先に到着したら、電源ケーブル、ＬＡＮケーブルを確認しながらしっかりと接続します。

スイッチングハブの接続と電源オンも忘れずに。

運転開始したら、ルーターでポートフォワーディング設定を行います。

ルーターの再起動が必要な場合もあると思います。

最後に、室内のクライアントＰＣのどれかに、サーバーにリモートアクセスするアプリケーションをインストールしておきます。

ここから、サーバーのｃｒｏｎｊｏｂを動かしておきます。

特に、ＤＤＮＳサービス局へ最初の信号を送っておかないと、

ＤＮＳ情報が古い場所のままになっているので、Ｗｅｂサイトへのアクセスが出来ません。

ここまでの作業を完了させたので、４つのＷｅｂサイトは元通り復旧しています！

　NetCommons３サイトを Connect-CMS に移行させることが出来ました！

２つのサイトの移行が完了しています。

現サイトの移行は、来年春の予定です。

移行手順の概略は以下の通りです。

①新Connect-CMSサイトのバーチャルホスト設定ファイルを作っておく。
　アクセスURLは、NetCommons３サイトと同一にしておく。

②NetCommons３サイトと同一サーバー内にConnect-CMSをインストールする。

③バーチャルホスト設定で、NetCommons３サイトをdisableに、Connect-CMSサイトをenableにする。
　インストール後にサイトにアクセスして正常動作を確認しておく

④バーチャルホスト設定で、Connect-CMSサイトをdisableに、NetCommons３サイトはenableに戻す。

⑤Connect-CMSインストールディレクトリ　・・・/connect-cms 直下の.envファイルを編集
　# migration option (Common)
　　MIGRATION_CONFIG_PATH=/var/www/○○○/connect-cms/app/Traits/Migration/sample/migration_config/migration_config_nc3.sample.ini

　# migration option (NetCommons3)
　　NC3_EXPORT_UPLOADS_PATH=/var/www/△△△/app/Uploads/
　　NC3_APPLICATION_YML_PATH=/var/www/△△△/app/Config/application.yml

　バーチャルホスト設定は、NetCommons３サイト、Connect-CMSサイト共にdisableに。

⑥Connect-CMSインストールディレクトリ ・・・/connect-cms 直下で、Exportコマンド、Importコマンドを実行させる
　$ php -d memory_limit=512M -d allow_url_fopen=1 artisan command:ExportNc3 all {redo}
　$ php artisan command:ImportSite all {redo}

⑦バーチャルホスト設定でConnect-CMSサイトをenableにし、移行後の新サイトにアクセスし、正常動作を確認する！

　昨夜は、ＰＨＰの openssl 関連のエラーを解消しようと四苦八苦していました。

openssl をソースコンパイルして再インストールしたりしましたが、エラーは解消されず・・・

サーバー環境から新しく作り直そうかとあきらめかけていたところ、Ｗｅｂ上の新情報を見つけました。

どうも、openssl は enable になっているのに、必要のないところに openssl.so を読みに行こうとしているのがエラーの原因だったようなんです。

そこで、php.ini を編集して、「 -dextension=openssl 」を書き加えました。

これで、ＰＨＰの openssl のエラーは解消されました！

この後、connect-CMS のインストールと設定を無事完了させるところまで行けました。

今回は深夜２時までの作業で何とか寝れましたね！

さあ、いよいよキモのNetCommonsサイトの移行作業に取り掛かれます！

現在、３つの NetCommons サイトを動かしていますが、このうちの２つは早速移行させてしまおうと思います。

残りの１つ（このサイト）は、受験での化学資料の利用者が戸惑わないよう、来年の４月まで移行作業を延期しようと思っています。

　前回のメンテナンス作業は、サポート期限が切れていたＯＳ環境を新しくすることでした。

しかし、ＯＳをいじり過ぎていてdist-upgrade コマンドは使えない状況になってしまっていました。

そこで、別サーバーに新ＯＳ環境を作っておき、そこへサイトを引っ越しさせる方法で作業しました。

サイト引っ越しの基本は、インストールディレクトリのコピーと、データベースmysqlのダンプとリストアです。

この方法で新環境に引っ越ししたサイトが現在動いています。

このあと、現新環境にConnect-CMSをインストールして、NetCommonsサイトをそこに移行させる手順だったんですが・・・

新環境でＰＨＰ拡張モジュールをインストールする時に色々といじり過ぎて、Connect-CMSのインストールが出来なくなってしまっていて、そこでつまづいて止まってしまっているんです・・・

今夜は、このトラブルを何とか解決出来ないかトライしてみます！

　何日も費やし、たくさんの失敗を重ねて、どうすればいいのかがやっと見えてきました。

ＮｅｔｃｏｍｍｏｎｓサイトをＣｏｎｎｅｃｔ-ＣＭＳに移行する時、同一サーバー内での作業になります。

Ｎｅｔｃｏｍｍｏｎｓの最終バージョンはＰＨＰ７．４までで動かさないといけません。

一方のＣｏｎｎｅｃｔ－ＣＭＳはＰＨＰ８以上で動かすようになってきていますが、まだＰＨＰ７．４でも動かせます。

そこで、ＯＳ内のデフォルトがＰＨＰ７．４で、ＯＳがまだＥＯＬを迎えていないものを選択することになりました。

すると、ＯＳはＤｅｂｉａｎ１１に決まります。

この前、最初に行った作業は、Ｄｅｂｉａｎ９の中で動かしていた複数のＷｅｂサイトを、Ｄｅｂｉａｎ１１環境の別サーバー機に移植したんです。

そして、さらに別のサーバー機で、コピーした現行サイトをＣｏｎｎｅｃｔーＣＭＳに移行テストしました。

これまで、作業内容を細かく記録してきましたが、特に最近は、数年経つと作業方法が大きく変わってしまうようになってきました。

なので、大筋について記録していこうと思っています。

　昨夜から、またまた徹夜になりました！

今朝になって、移行テストに関する不具合をようやく見つけることが出来ました！

その１つは、mysql の database prefix が間違っていたことでした。

これを修正して、祈るような気持ちで、ＥＸＰＯＲＴコマンドを入力したら・・・

エラーなしで最後まで実行してくれました！！

ＩＭＰＯＲＴコマンドも同じく！

移行したサイトをざっとブラウジングしてみましたが、もうこれで充分です！！

移行できるＣＭＳと移行システムを作って下さったメーカーの方々に、もう感謝しかありません！

本当に有難うございます！

この後は、このテストを元にして、本番の移行作業を行おうと思っています。

来年の春のNetcommons３サポート終了までには作業しなければなりません。

それまで、ハードウェアの準備を考えたいと思っています。

　ＯＣＳＰとは、

Ｏｎｌｉｎｅ　Ｃｅｒｔｉｆｉｃａｔｅ　Ｓｔａｔｕｓ　Ｐｒｏｔｏｃｏｌの略だと書いてある。

この「Let's EncryptがOCSPサポート停止」の記事は今日９月３０日発表で、自分にはまだ内容が分かりません・・・

証明書の期限は９０日間ですが、期限後の自動延長が出来なくなるってこと？

　移行先の新サーバーは順調に動いているように見えます。

旧サーバーの、Let’s Encrypt で取得した「SSL/TLSサーバ証明書」ですが、

これも新サーバーに持ってこなければいけないと思い、調べてはありました。

でも、Ｗｅｂサイトがやっと動いたのを確認してホッとして気が抜けていたんだと思います。

今、サーバーマシンの置き場とは別の所に居るので、すぐに確認して手を加えることが出来ません・・・

証明書の期限が切れる前に作業しなければ！！

　うっかりしていたんですが、ｍｙサーバーのＯＳ、Ｄｅｂｉａｎ９は６月にサポート終了となっていました！

大急ぎで新ＯＳの環境を作って、そこに現アプリケーションを移行させなければなりません。

数日悩んだんですが、今後もスピーディーに確実に作業できる方法にしたいと考えていました。

そこで、まずは、旧サーバーからのデータの移動をＬＡＮ上でやることから始めました。

旧サーバーはギリギリまで止めたくないので、

旧サーバーが動いている状態で、まずは大部分のファイルをコピーしておくことにしました。

そして、変更や追加があったファイルだけを最終的にコピーする方法を選びました。

Ｒｓｙｎｃコマンドを使ったんですが、この操作が上手くいくまでに２日費やしました。

こんな感じで、この後もハマりまくったんですが、

深夜３時、４時の日が続き、昨日は久々の徹夜になってしまいました。

ということで、続きは明日以降記録したいと思います。

　.envファイル設定の

# migration option (Common)
　MIGRATION_JOB_MONITOR=true
　MIGRATION_JOB_LOG=true
　MIGRATION_CONFIG_PATH=C:\connect-cms\_migration_config\migration_config_nc3.ini

中の、

　PATH=C:\connect-cms\_migration_config\migration_config_nc3.ini

の記述で引っかかっていたんですが、

考えてみると、

webサイトはWAN上にあり、このサイトを動かしているwebサーバーに対するコマンド操作は、

SSHを使ったリモートアクセスによっていると思います。

このSSHコンソールは、手もとのクライアントにあり、

クライアントは一般的にはWindowsが多いと思われます。

また、移行準備の際に生成されるconfigファイル、サイト内のコンテンツ等の沢山のファイルも一時的な保管場所が必要になります。

この一時的な保管場所は、WAN上のサーバー内ではなく、手もとのクライアント内にしてある、ということではないでしょうか？

ということで、

　export した際に、storage\app\migration\import 以下にデータが作成される。

という記述も確認出来ました。

このパスも、クライアントのWindows上だと思われます。

以上のことより、このNC3からConnect-CMSへの移行手順は、

クライアントのWindows上のSSHターミナル（Teraterm等の）で操作をする前提で書いてあるのではないか？

現時点ではこのように考えています。

ちょっと自信はないのですが・・・

　現NC３サイトをConnect-CMSへ移行しなければなりませんが、移行の猶予はまだ１年あります。

Connect-CMSの試験installは何とか出来て、

また、Connect-CMSサイトのバックアップ、リストアの方法も教えていただきました！

そして、Netcommonsサイトの移行方法について勉強中です。

　https://github.com/opensource-workshop/connect-cms/wiki/Migration-from-NC3

に記載の、

　.envファイル

# migration option (Common)
　MIGRATION_JOB_MONITOR=true
　MIGRATION_JOB_LOG=true
　MIGRATION_CONFIG_PATH=C:\connect-cms\_migration_config\migration_config_nc3.ini

# migration option (NetCommons3)
　NC3_DB_CONNECTION=mysql
　NC3_DB_HOST=127.0.0.1
　NC3_DB_PORT=3306
　NC3_DB_DATABASE=xxxxxx
　NC3_DB_USERNAME=xxxxxx
　NC3_DB_PASSWORD=xxxxxx
　NC3_DB_PREFIX=nc3_
　NC3_EXPORT_UPLOADS_PATH=/path_to_nc3/app/Uploads/
　NC3_APPLICATION_YML_PATH=/path_to_nc3/app/Config/application.yml

上記のように、.env に移行元のNC2 情報を設定する。

とあるのですが、ここで引っかかっています。

# migration option (Common)

中の　

　MIGRATION_CONFIG_PATH=C:\connect-cms\_migration_config\migration_config_nc3.ini

ですが、

MIGRATION_CONFIG_PATH=　以下の書き方は、Windows上での書き方？

これらの操作を全てLinuxサーバー上で行うのであれば、例えば、

　MIGRATION_CONFIG_PATH= /var/www/test/connect-cms/migration_config/migration_config_nc3.ini

でいいんでしょうか？

また、試験installしたconnect-cmsディレクトリ中には、migration_configディレクトリはありませんでした・・・

ということは、migrationのコマンドを実行した時に、ディレクトリが作られる？

ここら辺のことは、試験的に実際にコマンドを動かしてみながら勉強した方が良さそうです。

それでも上手くはいかないでしょうから、その時点でメール質問しようと思っています。

※ MariaDBでデータベース作成は済ませておく。

①install ディレクトリ作成

　# mkdir -p /var/www/test

②GitHubからソースをクローン、安定版へ切り替え

　# cd /var/www/test

　# git clone https://github.com/opensource-workshop/connect-cms.git

　# cd /var/www/test/connect-cms

　# git checkout $(git describe --tags --abbrev=0)

③composerをインストールし、利用ライブラリをダウンロード

　# php -d allow_url_fopen=1 -r "copy('https://getcomposer.org/installer', 'composer-setup.php');"

　# php -r "if (hash_file('SHA384', 'composer-setup.php') === 'ハッシュ値は、https://getcomposer.org/download/を参照') { echo 'Installer verified'; } else { echo 'Installer corrupt'; unlink('composer-setup.php'); } echo PHP_EOL;"

　# php -d allow_url_fopen=1 composer-setup.php

　# php -r "unlink('composer-setup.php');"

　# php -d allow_url_fopen=1 composer.phar install --no-dev

④apache conf設定

　DocumentRoot /var/www/test/connect-cms/public

　<Directory "/var/www/test/connect-cms/public">

  　  AllowOverride All

    　Require all granted

　</Directory>

⑤.envファイル作成（Laravel）

　# cd /var/www/test/connect-cms/

　# cp .env.example .env

⑥.envファイル編集

　APP_NAME="Connect-CMS"

　APP_ENV=production

　APP_KEY=               ←適当な文字列を入力、ダブルクオートで囲まない

　APP_DEBUG=false

　APP_URL=https://xxx.mydns.jp/　（DNS設定、ssl設定は済ませておく）

　LOG_CHANNEL=daily

　DB_CONNECTION=mysql

　DB_HOST=127.0.0.1      ←localhostに変更

　DB_PORT=3306

　DB_DATABASE=     　　   ←DB名

　DB_USERNAME=            ←DBユーザ名

　DB_PASSWORD=            ←Dパスワード名

⑦アプリケーションキーの初期化

　# php artisan key:generate

　**************************************

　*     Application In Production!     *

　**************************************

 　Do you really wish to run this command? (yes/no) [no]:

 　> yes        ← yes を入力

⑧DBマイグレーション

　# php artisan migrate

　**************************************

　*     Application In Production!     *

　**************************************

 　Do you really wish to run this command? (yes/no) [no]:

 　> yes        ← yes を入力

⑨seederで初期データインポート

　# php artisan db:seed

　**************************************

　*     Application In Production!     *

　**************************************

　Do you really wish to run this command? (yes/no) [no]:

 　> yes        ← yes を入力

⑩ディレクトリパーミッション、他の設定

　# cd /var/www/test/connect-cms/

　# chown -R www-data:www-data storage

　# chown -R www-data:www-data bootstrap/cache

　# chown -R www-data:www-data vendor/tecnickcom/tcpdf/fonts

　# chown -R www-data:www-data public/themes/Users

　# chmod -R u+wr storage

　# chmod -R u+wr bootstrap/cache

　# chmod -R u+wr vendor/tecnickcom/tcpdf/fonts

　# chmod -R u+wr public/themes/Users

⑪完成サイト初期アカウント

　user：admin

　pwd ：C-admin

　昨日、NetCommons３ の update 作業を行いましたが、

「NetCommons３ の配布は、２０２５年３月までで終了する」と発表されていることは以前書きました。

NetCommons３サイトは、

オープンソース・ワークショップ社の Connect-CMS サイトに移行出来そうなんです。

サーバーに Connect-CMS をインストールして、ここに現サイトの情報をインポートする流れです。

今、色々と情報を集めているところなんですが、

まずは自分の webサーバーに、試しに Connect-CMS をインストールしてみようと思っています。

git コマンドで github からソースをクローンし、

php ライブラリを composer でダウンロードしてくるように書かれていました。

これは自分には未経験の作業なので、不安と期待が入り混じった気分です！

３～４日くらいまとまった日にちが取れた時にやってみたいと思います！

　NetCommons3.3.7 がリリースされました！

「重大なセキュリティバグの修正」を含むとアナウンスされていましたので、先ほどupdate作業を行いました。

今後、NetCommons3 の新バージョンは提供されなくなるということですので、これが最後の提供になってしまうかもしれません。

ともかく、今回の update もお世話になりました！

関係の方々に感謝申し上げたいと思います！

　NetCommons３で作ったこのサイトをどうやって継続させたらいいのか？

悩んでまだ２日めですが、

OpenSource-WorkShop社の「Connect-CMS」という国産CMSが見つかりました！

この会社のエンジニアは、おそらくNetCommonsの開発、作成の中核にいらっしゃった方々じゃないかと思います！

NetCommonsの移行ツールも出来上がっているそうです！

期待できそうですね！！

実験用サーバーを作って、移行から試験してみたいと考えています！

　仕事で使う職場のファイルは共有サーバーに保管してあるケースがほとんどだと思います。

Ｅｘｃｅｌファイルにマクロが組み込まれていることがありますが、

送られてきたマクロ付きＥｘｃｅｌファイルにウィルスが仕込まれることは珍しくありません。

このような経緯から、

ＭＳＯｆｆｉｃｅの新ヴァージョンは、ネットワーク上のマクロ付きＥｘｃｅｌファイルの動作に制限をかけるように変更されました。

　さて、信頼のおけるファイルにまで制限がかかってしまうようになったのです！

これについての対応の１つですが、

ファイルの置き場を「信頼できるサイト」として登録します。

これは、Ｅｘｃｅｌの設定ではなく、インターネットオプションのセキュリティの設定で行います。

 「インターネットオプション」→「セキュリティ」と開く

「ローカルイントラネット」→「サイト」→「詳細設定」と開く

「このWebサイトをゾーンに追加する」らんにアドレスを入力する

例）file://sv2024.mount.ed.jp

「追加」をクリック → 「閉じる」をクリック

以上です。

　DNSmasq の設定ファイルの更新、また /etc/hosts ファイルの更新を行ったあとの、

Dnsmasq サーバーの再起動は、以下のコマンド操作で上手くいきました。

# /etc/init.d/dnsmasq restart

　Nextcloudのヴァージョンアップについてです。

以前は、Nextcloudサイトに管理者がログインすると、アップデートが可能かどうかがすぐに分かり、続けてアップデート操作に進めるようになっていたと思います。

しばらくこのアップデート作業をやってなかったので、先日、ログインしてアップデート可能か調べようとしました。

すると、すぐにはアップデートの有無の確認が出来なかったので、検索で調べてみました。

結果、管理者ログイン → 右上のユーザアイコンから、「管理者設定」→「概要」

と進むと、アップデートの有無が調べられ、そこからアップデート作業に入れることが分かりました。

で、かなり溜まっていたアップデート作業を始めてみました。

これまでやってきたWebアクセスによるアップデート作業です。

すると、しばらく順調に作業が行われていましたが、急に途中で止まってしまい、動かなくなってしまいました・・・

そこで再度検索してみると、サーバー上でのコマンド操作によるupadate、upgradeについての方法が見つかりました。

ログイン後、まずNextcloudインストールディレクトリに移動します。

# cd /･･･/nextcloud/

# sudo -u apache php occ update:check

ここでつまづきました・・・

# sudo　って？

sudoは一時的に管理者権限等を得るためのコマンドです。

# sudo　ということは、「管理者(root)が管理者権限を得て実行」ということ？？

しばらく悩みました。

そして、# sudo -u apache php ･･･ とは、phpコマンドの実行文で、

apacheユーザ（つまりapache使用時のwebサーバーユーザ）がphpコマンドを実行する、ということではないか？　と推測しました。

phpコマンドを実行するための権限ユーザを指定するためにsudoコマンドが必要なのではないか？

ですから、単に、# php ･･･　という操作では、phpコマンドが実行されないんですね！

このことは実際に試してみて分かりました。

それでは、まず自鯖に sudo をインストールします。

また、debianのapachewebサーバユーザは、apache ではなく www-data です。

準備が出来たので、再度コマンドを実行してみます。

･･･/nextcloud/# sudo -u www-data php occ update:check

オッケーです！！ これでアップデートの確認が出来ました！　また、

･･･/nextcloud/# sudo -u www-data php occ upgrade

で、アップグレード作業も最後まで滞りなく進みました！

勉強になりました！

ヒントを下さったweb上の方々に感謝します！！

　Intelの新型プロセッサーＮ１００を搭載した省電力マザーボードが、ようやく発売されるようです！

ここで、Intel　Celeron、Pentiumブランドは廃止され、

その代わりに「Intel Processor」ブランドのエントリー向けCPU、Nシリーズが発表されていました。

製品の開発コード名　Alder LakeーN

システムの種類　Mobile

プロセッサーナンバー　N100

コアの数　4

スレッド数　4

ターボ・ブースト利用時の最大周波数　3.4 GHz

キャッシュ　6 MB　Intel® Smart Cache

TDP　6 W

メモリーの仕様

最大メモリーサイズ (メモリーの種類に依存)　16 GB

メモリーの種類

　DDR4 3200
　DDR5 4800
　LPDDR5 4800

最大メモリーチャネル数　1

　メモリーはデュアルチャンネルではありませんが、メモリー周りは充分高速らしいです。

また、上限１６GBとありますが、３２GBまで動作するようなことが書かれていました。

マザーボードが発売されたら、このＷｅｂサーバーのハードウェアを全て一新する予定です。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

どうすればいいか？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　ところが、今日初めて、

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

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

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

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

とも書かれていました！

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

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

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

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

＜参考資料＞

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

アップルによると、

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

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

第5世代以降の「iPad」

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

アップルは、

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

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

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

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

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

と警告していて、

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

8/20(土) 4:49配信

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

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

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

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

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

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

と思いあたりました。

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

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

だけです！

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

＃certbot --apache

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

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

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

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

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

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

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

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

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

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

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

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

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

ん？　

出会い？！

出会い系サイト？！！

ヒドイでしょう？

汚名だー！

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

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

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

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

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

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

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

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

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

①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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

構築の仕方ですが、

　① Web サーバーを用意

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

　② データベースを用意

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

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

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

これだけです！

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

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

　先日、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がインストールされているプライマリディスクを外して挙動を調べてみる。

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

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

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

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

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

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

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

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

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

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

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