サーバー運用とPC日記

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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ファイルを参照するだけだから、動作即完了ですよね？

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

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

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

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

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

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

たとえ話ですが、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サーバーを構築したいですね。

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

どうでしょうか？

今朝早朝３時半まで頑張ったんですが、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内のスマホから祈るような気持ちでアクセス・・・

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

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

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

自宅エリアではスマホは 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をインストールしました。

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

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

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

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関連はともかく、ハードウェアがなぜこのような状況になってしまったのか？

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

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

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

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

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

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

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

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

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/

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サイト閲覧不可を解除

以上です！

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

悩み中です。

またWebサーバーをダウンさせてしまい、申し訳ありませんでした。

NTTの終端装置にルーター機能が付いているのに、それを無効にしてBB光ルーターを追加するのが気に入りませんでした。

この２台の消費電力は６０Ｗ近くにもなるんです。それを常時消費してる訳ですから納得できません！

しかし・・・

BB光ルーターを外した設定を一からやるのにここまで時間がかかってしまいました・・・！

これで何とかなってるんですが、速度アップとかの詳細設定は後日やることにします。

明日早いので、今日はここまでにします！

本日、プロバイダをNiftyからSoftbankに切り替えました。

本日も、Webサーバーが一時不通になったことをお詫びいたします。

一応、これで設定は完了したので、以降、Webサーバーにも安定してアクセスが可能と思います。

さて、今までのプロバイダNiftyの環境では、NTT回線の光終端装置にルーター機能がセットになっているPR-400NEが提供されていました。

この装置にUser設定を加えていたので、変更はスムーズには行かないかもしれないと思っていました。

そこで、行き帰りの通勤で歩きながらあれこれと考えてはいたんです。

さて、本日プロバイダの切り替えの日だったんですが、手順書通りにやっても案の定うまく行きません！

まずは、以前のNiftyのアカウントでNET接続しているので、これを消さないといけないんですが、PR-400NEの初期化にちょっとコツが必要でした。

初期化スイッチをかなり長い間押したままにしておかないとダメなんです。

さて、次の盲点だった所です。

SoftbankのBBルーターが切り替えに先立って届いていたので、すぐに接続してWifi機能だけ使っていました。

そして、当初PR-400NEにはルーター機能もあったので、IPアドレスは「192.168.〇.1」を割り振ってありました。

そこで、BBルーターには「192.168.〇.2」を割り振ったんです。

切り替えの前日までは、これでNiftyの接続は問題なく利用できていました。

そして今日、PR-400NEを初期化してこれは終端装置だけになったので、これでインターネットに繋がるはずでした。

ところが、有線LAN内のPC、そしてwebサーバー、全部インターネットに繋がりません！

でも、この時点で、Wifi接続のスマホはインターネットに繋がっているのを発見できたのは幸いでした。

すると原因は、有線LAN内の設定も含めた不具合だけに特定できます。

しばらく考えて、そうだ！ と気付きました。

有線LAN内のPCはすべて固定IPを振ってあって、ゲートウェイを以前のルーターの「192.168.〇.1」に設定してあったんです。

新ルーターのIPは「192.168.〇.2」に設定したのでした。

ですから、LANから外のWANに出ていくゲートウェイが無い状態だった訳です。これではインターネット接続は出来ませんよね。

そしてもう「192.168.〇.1」は使われていないので、再度、新softbankルーターのIPを「192.168.〇.1」に設定し直しました。

さあ、新ルーターを再起動して・・・

やっと、有線LAN内のPCもすべてインターネット接続出来ました！

最後は肝心のWebサーバーです。

新ルーターにポートフォワーディングの設定をし、サーバー内の自動実行スクリプトを手動で走らせて、DDNSサービスの提供先に現在のIPアドレスを知らせておきます。

これをやらないと、サーバーがキチンと外部アクセスを受け付けているか、すぐには調べることが出来ないんです。

さて、結果はどうでしょうか？・・・

ここまでの作業で、ようやく我が家のインターネット環境がすべて正常になりました！

やれやれ！ これで一安心と思ってコータの散歩に出かけたんですが、ふと心配になって我が家の固定電話に電話をかけてみました。

呼び出しはしてるのに、家の電話機は呼び出し音鳴ってない様子！

散歩から戻って、再度設定を調べてみました。

その結果、新ルーターだけでも電話機能は使えるんですが、NTT割り当ての電話番号はPR-400NEで処理をしているので、今までの電話番号を使うのなら（使いますよね！？）、PR-400NEの電話信号を新ルーターに追加して送ってやらなければならないということが、やっと分かりました！

これで、今度こそ設定完了です！！

まあ、最初の設定って、ものすごく手間と時間がかかるってことですね！

光ＢＢユニットの接続設定のため、Webサイトがお昼を前後して一時不通になりました。

申し訳ありません！

ＮＴＴの光回線はそのままで、明日２／４にプロバイダをニフティからソフトバンクに切り替えます。

スマホ等のモバイル通信と自宅での固定光回線を同一業者のサービスにした方が、毎月の費用が抑えられるからです。

明日以降は、ソフトバンクのＢＢユニットで、有線ルーター機能、Wifiルーター機能、そしてWebサイト公開のためのポートフォワーディングの機能と、３つの機能を働かせるんですが、やってみないとどうなるか不明なところがあります。

また明日ハマってしまって、長時間費やすかも・・・

特にWebサイト関係で、出来るだけ迷惑をかけないようにしたいと思っています。

現在、このサイトに限らず、Netcommos３で作られたサイトの検索ボックスの挙動がおかしいようです。

iPhone からのタイピングでは、例えば通常のローマ字入力モードで「ネット」と入力するために「netto」とタイピングすると、以下のようになってしまいます。

この症状をNetcommons３公式サイトのヘルプデスクに報告してあります。

以前、Youtube の検索ボックスでも同様の症状が発生したらしいです。

ただ、Netcommons３のエンジニアの方々はかなり忙しいようで、改善されるのはまだ先になるかもしれません。

もう一つ別件ですが、埼玉県立の各高校の Web サイトもNetcommos３にバージョンアップされたようですが、動きが非常に悪い状態のようです。

これは、埼玉県の Web サーバー側で対応しないといけない問題だと思います。

１校あたりの Web サイトへのリソースの割り当てをもっと増やすべきなのでは？

具体的には、リソース中のメモリ量を増やし、webサーバー、データベースがもっと多くのメモリを使えるようにするといったことではないかと感じています。 

Nextcloud は、owncloud を生んだエンジニアがフォークして新しく作りあげた、オンラインストレージサービスを実現させるWebアプリケーションソフトです。

owncloud も当初はオープンソースソフト（OSS）でしたが、有償のエンタープライズ版が無償のコミュニティ版と共に作られ、コミュニティ版は追加機能が削られていきました。

Nextcloud 社は、元々 owncloud 社が持っていた OSS の精神を大切にしたいという想いから新たに設立されたようです。

また、追加機能の実装についても Nextcloud の方が先を行っているようです。

こんな感じなので、個人ユーザは Nextcloud を是非とも使いたいところです！

ただ、Nextcloud は、まだ日本語化されていません。（日本語データを扱うことはもちろん出来ます）

興味深い情報として、「snapコマンドによるインストール」がありました。

これは、Debian だと apt のようなインストール関係の作業を管理するコマンドのようです。

このsnapコマンドを使うと、Nextcloud のインストールでは、apache、mysql、php のインストールと環境作りまでもやってくれるようなんです！ 

ここら辺の検証も含めて、実験機でDebian１０のインストールからやってみようと考えているところです。

owncloud から Nextcloud へ乗り換えを検討中です！

・・・で、今ほとんど書きあがっていた内容が、タイムアウトして消えてしまいました！

時間をかけて書き込む際は、時々「一時保存」しましょうね・・・！

明日、もう一度書きたいと思います。

ちょっとだけ付け加えておきたいと思います。

昨日、owncloud 10.2 から 10.3 へアップデート作業している時に上手くいかなくて、かなり焦りました！

それと、Debian１０、php７.３環境へのアップグレードも検討中だったということもあります。

まずは、実験機で一からインストールして試してみないとダメだなと思っています。

待ち望んでいたNetCommons３の最新版が、ほぼ９か月ぶりにリリースされました！

ＮＥＴ環境も、特にセキュリティ面での対策を筆頭に、非常に細かい対応が必要になり、また状況が日進月歩で変化していくようですから、システムをメンテナンスしていくことは想像以上の苦労があると思われます。

自分のような末端ユーザーは、その恩恵にあずかることしか出来ず申し訳なく思っています。

そんな中での今回の最新版発表は特に嬉しく、有り難さを強く感じました！

台風が来た１２日の朝に発表されていましたが、１２日は家に閉じこもっていたので、その日にアップデート作業を行いました。

一応、以下が備忘録です。 

※ OS、mysql 共に root ユーザで作業の場合です。不可ならsudoコマンドを付加して。 

＜事前準備＞

　（１）バックアップディレクトリ等作成。

　　　# mkdir -p /home/hokan/20191013bkup

　（２）最新NC3zipファイルをクライアントＰＣにダウンロード。

　（３）webサーバーOSに（２）のダウンロードファイルをアップロード。

　（４）（３）のファイルを解凍。

　（５）解凍ディレクトリをリネームしておく　　

　　　# cd /home/hokan/20191013bkup

　　　･･･/20191013bkup# unzip NetCommons-3.3.0.zip

　　　･･･/20191013bkup# mv NetCommons3/ nc330/

＜アップデート前のバックアップ＞

　（１）対象NC3サイトを閲覧不可にしておく。

　（２）データベース $$$ のバックアップ（バックアップファイル &&&.sql　保管先/home/hokan/20191013bkup）

　　　# cd /home/hokan/20191013bkup

　　　･･･/20191013bkup# mysqldump -u root -p $$$ > &&&.sql

　　　　（mysql root のパスワードを入力）

　（３）ソースのバックアップ（保管先 /home/hokan/20191013bkup）

　　　# cp -r /var/www/NC3インストールディレクトリ/app/Config /home/hokan/20191013bkup/

　　　# cp -r /var/www/NC3インストールディレクトリ/app/Uploads /home/hokan/20191013bkup/

＜Netcommons３本体のアップデート＞

　（１）対象NC3サイトは閲覧不可にしたままで。

　（２）リネームディレクトリ下のファイル、ディレクトリを、既存NC3インストールディレクトリに上書き。

　　　･･･/20191013bkup# cp -r nc330/* /var/www/NC3インストールディレクトリ/

　（３）cakeコマンド実行してアップデート

　　　# cd /var/www/NC3インストールディレクトリ/app

　　　･･･/app# Console/cake PluginManager.update_all

　　　画面に「一括アップデート」が表示されるので、画面の指示どおり、S を入力してEnter。

　　　アップデート処理中、ざっと眺めておく。エラーは黄色表示になるはず。

　（４）インストールディレクトリの所有者を「webサーバー（debianならwww-data）に戻しておく。

　　　# chown -R www-data:www-data /var/www/NC3インストールディレクトリ

　（５）常用クライアントPC等から、アップデートしたサイトにアクセスして、ログイン出来ることを確認。

　　　　サイトを閲覧可に戻して作業完了です！ お疲れさまでした！ 

　　※ 関係者の方々、特に膨大な作業によって最新パッケージを作成して下さったエンジニアの皆様に感謝申し上げます！

　　　今後とも、どうかよろしくお願いいたします！

本日、Netcommons３最新版が近日中にリリース予定との発表がありました！

今後、一般ユーザーが、個人でNetcommonsをインストール、アップデートすることが難しくなるのか？ または全く出来なくなるのか？

とても気になっていたので、本日の発表を知ってとても嬉しい気持ちです！

このプロジェクトリーダーとスタッフの方々、そして開発エンジニアの方々に感謝の気持ちをお伝えしたいと思います！

iPhone、iPad 用のＯＳである iOS１３．１が配信されて、早くも３日後に修正版の iOS１３．１．１が配信されました。

動作不具合のバグ修正のためのアップデートとのことです。

このタイミングなら、修正版の配信を待っても良かったことになりますが、最近はこのようなケースは珍しくありません。

特にＯＳのアップデートは、やはり、毎日チェックすることを習慣にしておくのがいいと思います。

そして、今回のようにアップデートに時間がかかる場合は、作業は週末にやるとかの対応でいいんじゃないでしょうか。 

この前 Windows１０ の大型アップデート１９０３が配信されて、常用クライアント機のアップデートに数時間かかってしまいました！

ラジオサーバー機、風呂音楽用サーバー機は、ほっときながらアップデートしたので、それほど気にはなりませんでしたが。

それなのに、この更新は CPU 使用率が異常に高くなるという問題を抱えたままなんです。

そして、この問題を解消するアップデートはまだ配信されていません。（まもなく配信されるらしい？）

Web サーバー機の Debian９ も次期 Debian１０がすでに発表されていますが、使用アプリケーションの php７．３対応が完了すればアップグレードしたいと思っています。

もちろん、Debian９で配信されるアップデートは、毎日欠かさずチェックして更新しています。

そして、スマホの iOS ですが、昨日寝ている時間にダウンロードを済ませ、iOS １３．１にアップデートしました。

アップデートにもバグや動作不具合はつきものです。完全を待ってから！なんてことは実際無理だと思った方がいいです。

なので、アップデートが発表されたら、基本、「すぐにダウンロードしてインストールする、でＯＫ！」と思います。

自分は、アップデート操作は、素人に出来るセキュリティ対策の基本だと考えています。 

Debian９のデフォルトの php は ver７．０で、セキュリティサポートは２０１８年１２月に終了しています。

このサーバーのＯＳは Debian９ですが、php７．２(ｾｷｭﾘﾃｨｻﾎﾟｰﾄ 2020.11まで) を別途インストールしています。

この方法ですが、まず、packages.sury.org/php から gpg キーを取得し、apt-key コマンドでサーバーに取り込みます。

次に、/etc/apt/sources.list.d にリポジトリ設定を書き込み、apt-update、さらに apt-install php7.2 でインストールできます。

ところが、最近 apt-update を実行すると、「gpg キーが有効になっていない」というエラーが出て php のアップデートが完了しなくなってしまいました。

これについての対応は、取得先から最初と同じように gpg キーを再度取得し、apt-key で再度サーバーに取り込めばいいようです。

このあと、apt-update、apt-upgrade、を実行すれば php７．２が最新版に更新されます。

他のモジュールやアプリケーションなども、gpg キーを取得しているものはキーの有効期限があるようですから、キーを再度取得すると上手くいくかもしれません。

すでにDebian１０安定版が発表されていて、php７．３(ｾｷｭﾘﾃｨｻﾎﾟｰﾄ 2021.12まで) がデフォルト搭載されてもいるので 、早くこの環境にしてしまいたいんです。

ところが、owncloud、Netcommons３共に php７．３にはまだ対応していないようです。

これらの対応が完了したら、出来るだけ早くDebian１０の最新環境に更新する予定です！

自分のWindowsクライアントも、起動させると毎回アップデートチェックを行っています。

昨日もアップデートのダウンロードがあり、インストールが終わってから使おうと思っていたら、なかなか終わらない。

じゃあ、先にご飯食べちゃおうと、リビングに行ってスイカも食べて戻ってきたんですが、何とまだ終わってない！

その後、風呂から出てきても、まだ延々とアップデート作業が続けられていました！

自分はアップデートを溜めてしまうことはなく、すぐに完了させるようにしているので、今回のアップデートが非常に大きかったことになります！

今回のように、アップデートが数時間もかかるような場合、最初から分かっていれば対処できますが、

突然アップデート作業に入ってしまった時は、とても困ることがあるんじゃないでしょうか？

この間、クライアントでの作業が自由には出来ない訳ですから。

今回の Windows１０の大型アップデート、早めに余裕を持って作業されるようにした方がいいと思います！

現状では、Netcommons３ のアップデート作業が今までの方法では出来なさそう（もしくは対応が遅れそう）なので、

　https://github.com/NetCommons3/NetCommons3/wiki/NetCommons3開発ドキュメント

の中の、「NetCommos3をcomposerでインストール」を一生懸命読んで、必死にチャレンジしていますが・・・

自分の力量では、まだまだ追いつけません。

git、bower のインストールまで終わり、リポジトリのクローンまでは出来ましたが、まだ先が見えません・・・

自分が使っている自宅サーバーのセキュリティー対策はどうなっているのか、書いておく必要がありそうです。

まず、ＯＳですが、現在はDebianの最新版を最小構成でネットワークインストールしたものを使っています。

使わないソフトは入れず、必要なソフトはその都度追加する方法です。

また、apt コマンドでインストールできないソフトは、リポジトリを登録してからインストールしています。

こうしておくと、apt update コマンドでアップデートのチェックがすぐに行えます。

Netcommonsだけは手動インストールによっているので、Netcommonsのみ手動で最新バージョンにアップデートするようにしています。

また、光回線とつながるルーターからサーバーへは、ポートフォワーディングによって指定されたポートの信号のみ転送しています。

さらに、ファイヤウォールによる設定で、数個のポート以外のポートは全てブロックしています。

SSH等のリモート接続は、ローカルのみ、つまりマイクライアント以外は接続出来ないように設定してあります。

FTPは最初からインストールしていません。

大雑把にはこんな感じなんですが、

運用を初めてから、毎日のようにチェックしているのは、ＯＳとアプリケーションソフトのアップデートです。

アップデート通知が出ていれば、すぐにアップデート作業を行っています。

セキュリティアップデートのみは自動にする手もあるんですが、

以前apacheのアップデートを行った時、Webサイトが停止してしまったことがあったので、手動でアップデートし、不具合が出たらその時点ですぐ対応するようにしています。

また、ベースのＯＳに新バージョンが発表されたら、

使用しているWebアプリケーションが動作するか調べて、ＯＫなら、出来るだけ早く新バージョンのＯＳ環境にします。

最近はｐｈｐのバージョン対応に注意する必要があります。ｐｈｐのバージョンアップの方がどんどん先行している感じです。

新バージョンＯＳ環境にする時は、ストレージは新調してＯＳの新規インストールからやり直します。

この時、Webサイトはデータベースも含めて引っ越し作業を慎重に行います。

また、同時にハードウェアの点検もして、マザーボードその他も一新することもあります。

こんな感じなんですが、自宅サーバーでセキュリティ対策が手に負えなくなってきたら、SaaSのようなクラウドサービスについて考えようとは思っています。

ここ数か月、Netcommons３のバージョンアップの状況、またフォーラム等を見ていて、

当初とは状況が変わってきている感じがしていました。

２か月に１度程度行われるはずだったバージョンアップも、今年１月からピタリと止んだままです。

不安を感じながら、今年のユーザカンファレンス関係の情報がないか気にしていました。

先日のカンファレンス終了後の主催者とユーザーのやりとりを一部読むことが出来ました。

それについての感想ですが、

現在のNET環境、特にWeb上で多くの個人情報を扱うグループウェアが置かれる環境では、

セキュリティ対策が非常に重要で、これについての対応がどんどん難しくなってきている。

しかも、その対応自体も、年々変えていかなければならない状況でしょうから、容易ではないことは明白です。

これを実現させるために、多くの技術者や予算の確保が必要だと思われます。

まず、この点が難しい状況になってきているという感じがしました。

さらに、レンタルサーバーを使うにせよ、個人でWebサーバーを構築するには厳しい環境になってきている。

システムとサーバー、セキュリティやネットワークの管理は専門業者に任せるSaaSというサービスを使うべきだとの指摘です。

このような、プロジェクトリーダーからの指摘がなされたので、今までのようなアップデートパッケージ版の配布が止まったようなんです。

こんな風に、Netcommons３の利用についての方針が急に変わってきてしまいました。

個人的には、まだ良くのみ込めていないし、どう対処していいのか、戸惑っているところです。

一応、次のようなアナウンスはされています。

最新版はNetCommons3としてGitHubから自由にダウンロードし、どなたでも利用することができます。

管理者にはGitHubから最新版のNetCommons3を都度ダウンロードし、パッケージ化して利用して下さい。

Windows７ は ２０２０年１月まで、Windows８ は ２０２３年１月まででＯＳのサポートが終了されます。

Windows に限らず、どんなＯＳもサポート終了後は使用しないのが原則です。

その最大の理由は、セキュリティ面のリスクです。

自分のシステムやファイルはもちろん、自分以外の他のユーザにも被害が及ぶことが考えられます！

現在のＰＣは、ネットワークにつなぐ前提で動かされていますので、

ネットワーク経由でのセキュリティリスクは、色々と言われている通りで、無視することは絶対にできません！

そこで、Windows なら、最新バージョンの Windows１０にアップグレードする、ということになるでしょう。

さて、すごくザックリと言ってしまえば、Windows ７，Windows ８ が動いているマシンなら、動きが悪くなることはほぼないと思います。

自分のケースですが、Windows ７環境を Windows１０環境にして、動きがむしろ良くなりました！（それもはっきりと）

アップデートして使えなくなるソフトもごくわずかあるようですが、自分は割り切ってあきらめました。

代替ソフトも探せる場合があります。

では、 Windows１０ にアップデートする決心がついたら、次はどうやってお金をかけずにアップデートするかです。

実は、Windows ７，Windows ８ の正規ライセンスを持っていれば、 Windows１０ にへの無償アップグレードは、まだ可能なんですね。

　https://applica.info/windows10-upgrade

この記事を参考にして下さい。

また、こだわる人のために、 Windows１０ をクリーンインストールする手もあります！

最後に、Windows ７，Windows ８ のライセンスを持っていない人。

安価に何とかする手があるようですよ！

やっかいなことですが、これからも、常に最新版のＯＳを使うようにするしかないんですね！

あ、スマホしか使ってない人は、スマホのＯＳである、ｉＯＳ、ＡｎｄｒｏｉｄＯＳのバージョン等に気を配って下さい！ 

自宅の１Ｆに、ラジオサーバー（現在ＮＨＫラジオ自動録音機）として日中稼働させている省電力ＰＣがあります。

このＰＣにbluetoothアダプターを付けて、２Ｆの浴室でbluetoothスピーカーからの音楽を聴こうとしていました。

しかし、この距離では残念ながらbluetooth接続が出来ませんでした。

そこで、２Ｆに音楽専用小型ＰＣを作り、これにbluetoothアダプターを取り付けることにしました。

有線ネットワークを使って、このＰＣを１Ｆの自分のメインＰＣからリモート接続でコントロールしようという試みです。

２ＦのＰＣにディスプレイ、キーボード、マウスを付けていれば、１Ｆからリモート接続なんて不要なんですが、

２ＦにＰＣを置くと怒られそうなので、２Ｆの押し入れにＰＣ本体を閉じ込めて使う感じなんですね！

このＰＣは、浴室で音楽を聴く時だけ稼働させます。

ということで、低スペックながら余ったパーツ（もちろん省電力仕様）でＰＣは組み立ることにして、

ＯＳのWindows10pro（proでないとリモート接続できない）をどうやって入手するかが、悩みどころなんです。

まともにパッケージ版とかを購入すると、ＤＳＰ版（ハードウェア同時購入版）でさえ結構な値段です。

そこで、まずMicrosoft社のWebサイトから、Windows10のインストールファイル（ツール）をダウンロードします。

そのファイル（ツール）からインストールＵＳＢメモリを作成します。

作成したＰＣの起動順位をＵＳＢメモリ第１に設定してから、このインストールＵＳＢメモリでWindows10をインストールします。

ここまでは、実は簡単なんですね。

自作ＰＣ、メーカー製ＰＣにWindows10をクリーンインストールしたくて困っている人がいたら、周りの詳しい人に聞いてみて下さい！

もちろん、自分からもアドバイスはできますよ！

で、最後に必要なのは、Windowsのライセンスキーなんです。

実はこのライセンスキーを以前Amazonで格安で入手したことがあるんです。（正規認証品です）

最近見かけなくなったと思っていたら、yahooストアにありました！

これも正規認証品ということを確認してから発注しました。

届くのは、メール文で送られてくるプロダクトキーだけです。

しかし、最後にプロダクトキーを入力すれば、キチンと正規認証されたWindows１０ＰＣが出来上がるんです！

今日の早朝、サーバーマシンのメインメモリを増設しました。

４ＧＢ × ２ を ８ＧＢ × ２ に交換する作業です。

このマザーボードの Pentium Silver J5005 の最大メモリー容量は ８ＧＢ なので、無意味に思えます。

また、このマザーボードのマニュアルにも、最大メモリー容量 ８ＧＢ が記載されています。

ところが、 メモリーサポート一覧表には １６ＧＢ が記載されていて、実際にこの容量で動かしている例も紹介されています。

また、今までの計８ＧＢの運用では、キャッシュを含めてほぼメモリー容量を使ってしまっている状況でした。

見にくくてすみません。6.48GBcashed、7.64GBtotal という部分です。

期限の切れそうな固定Ｔポイントがあったので、これで新たにメモリを入手して、試してみることにしました。

さて、現在は計１６ＧＢのメモリがマザーボードには認識されている状況なんですが、

ハードウェア、ソフトウェア共にこの１６ＧＢの容量を活用してくれるのかを観察している段階です。

先日１５日に、このWebサイトを動かしているＯＳの再起動を行った際、

Webサイトの応答が目に見えて悪くなりました。

そこで、Webminからの操作でapache本体の再起動を行い、何とかしのいでいました。

ところが、今日に至るまで、Webサイトの応答速度が悪いままでした。

そこで、apache バーチャルホスト設定ファイルの再読み込みを試してみました。

　＃ a2dissite 〇〇〇

　＃ systemctl reload apache2

　＃ a2ensite 〇〇〇

　＃ systemctl reload apache2

この間、一瞬Webサイトは停止しますが、ほぼ問題なしと思います！

さて、現状このサイトの応答はどうでしょうか・・・

先ほど、このＷｅｂサイトのＯＳのアップデートを行ったところ、

珍しく再起動が必要な状況でした。

そこで、大変申し訳なかったのですが、予告なくＯＳの再起動を行い、同時にルーターの再起動も実施しました。

全作業４分間ほどでしたが、再起動後のＷｅｂサイトの挙動から判断して、

この時間にファイルのダウンロードも含めて、アクセスしていた方がいらっしゃったようです。

大変申し訳ありませんでした！

以降、再起動のタイミングについては気を付けて行うよう、注意致します。

このサイトのシステムであるNetcommons（ネットコモンズ） は、国立情報研究所が開発するWebシステムです。

CMSとグループウェアの機能を持っています。

具体的には、Netcommons で Web サイトを構築することができますが、

これで作成した Web サイトは、掲示板、ブログ、回覧板、アンケート、小テスト、動画掲示板、カレンダー、フォトアルバム、その他のコンテンツ、を表示させ、機能させることが可能です。

これらを機能させるプラグインの使用権限を設定し、複数の関係者がこれらのプラグインを使って、

サイト内の色々な部分を、分担して構築できるようになっています。

１人の専門家だけに全ての構築を任せる必要がなくなる、というメリットがあります！

これが、ＣＭＳ（コンテンツマネージメントシステム）の機能です。

このような特徴は、色々な部署を持つ企業や学校などのWebサイト構築に向いている訳です。

また、特定のグループに掲示板の内容を配信したり、上記のプラグインの機能を利用させたり出来るシステムが、グループウェアです。

複数の各グループ毎に、異なった内容の運用をさせる事が出来る訳です。

さらにこのソフトウェアは、オープンソースなので無償で使用することが出来ます！

自分は、無償OS Debian上に、このNetcommonsをインストールしているので、ソフトウェアにかかる費用はゼロです 。

また、この「実験と魚料理」は個人的なサイトなので、構築は全て自分１人でやっています。

さて、Netcommonsは、このような特徴のおかげで、学校やNPO、自治体や中小企業などに急速に広まっています。

埼玉県内の学校のWebサイト（ホームページ）にも、広く活用されています。

ただ、埼玉県内の学校のサイトでは、まだ Netcommons２（旧バージョン）のままです。

自分のこのサイトは、 昨年８月に Netcommons２ から Netcommons３ へ移行作業を行いました。

特にNetcommons３サイトは、スマホでアクセスしてみると分かりますが、違和感なくブラウジングが出来、

応答も速く、表示もとてもきれいになっていることが分かります！（レスポンシブデザイン）

また、セキュリティ対策が非常に強力に施されています。

ここに来て、ようやく埼玉県立高校のWebサイトも、Netcommons３にバージョンアップされそうな気配です！

現在の Netcommons２サイトと、バージョンアップ後の Netcommons３サイトを見比べると興味深いと思います。

埼玉県立高校のWebサイトがバージョンアップされたら、お知らせしようと思います。 

Netcommons 3.2.1.1 から 3.2.2 にアップデート作業を行いました。

手順に沿って、ていねいに作業し、問題なく完了したように見えていました。

ところが、カミさんのスタジオのホームページに問題発生！

カレンダーに日程の書き込みや編集をしようとすると、「内部エラーが発生しました」となり、操作できないとのこと。

慌てて、３つ作ってあるNetcommons３サイトをすべてチェックしてみたところ、さらに不具合を発見！

管理ページでの、会員管理、権限管理、会員項目設定、の各操作をしようとすると、「内部エラーが発生しました」となり、この３項目は操作できないことが分かりました。

現在のこのサーバー環境は、Debian９、apache 2.4.25、Mysql 10.1.37、php7.2 です。

さて、検索したり、Netcommons３の掲示板を見たりしましたが、手掛かりがつかめません。

そこで、公式サイトにユーザ登録して、トラブル報告として書き込ませていただきました。

以前、Githubに書き込んだ時には、全く応答してもらえなかったので不安でしたが、

今回は、１時間後には、対応策を書き込んで下さっていました。

その対応策に沿って修正作業してみたところ、見事、一発で、すべてのエラーは解消しました！

対応のアドバイスを下さった、牟田口様、天野様、本当にありがとうございました！！

この件の詳細について書いておこうと思います。

Netcommons3.2.1.1 の時に、サイトの引っ越しをしていました。

この時、引っ越し先の自分の新調サーバーは、 php7.2 環境にアップしてあり、

まずは、このサーバーにNetcommons3.2.1.1 の新規インストールを行う必要がありました。

その際、php7.2に対応させるために、app/Plugin/Migrations/Lib/CakeMigration.php ファイル１７行目の「Object を CakeObjectに書き換える」作業が必要でした。

これで出来たNetcommons 3.2.1.1環境に、php7.0で動いていたNetcommons 3サイトのバックアップからのリストアを行った訳です。

そして今回は、Netcommons 3.2.2 は php7.2 にすでに対応しているだろうから、CakeMigration.php ファイルの修正はせずにアップデート完了するだろうと思い込んでいました。

しかし、Netcommons 3.2.2 のCakeMigration.php ファイルは、まだ php7.2 には対応していなかった、ということでした。

対応していなかった理由は良く分かりませんが、レンタルサーバーの多くは、まだ php7.1 あたりなのではないか、とか推測しています。

考えられる多くの環境があるでしょうから、そのどれに対応させるのか、判断が難しいのかもしれません。

または、本当に忙しくて、全ての対応に手が回らない、ということもあり得ると思います。

いずれにしても、これからも、すんなりといかない場面が多く出てきそうですから、

こちらも一生懸命やりながら、多くのエンジニアの方々に助けてもらっていかなければならないと思っています！

Netcommons３もver.3.2.2 まで来て、動作も含めて、大きく改善されてきたと感じます！

これからも、ユーザサイドでアップデート作業を継続していかなければなりません。

ほぼ２か月に１度のペースで発表されるアップデートですが、作業の細かい点をどうしても忘れがちです。

結果オーライに安心して、バックアップ作業を省略したりもしていました。

しかし、突然何かアクシデントがあった時に対応できるよう、やはり基本に忠実に作業しておかないといけませんね。

何となく作業していたのでは、このwebサイトを失う原因にもなりかねません！

そこで、作業手順を細かく記録しておくことにしました。

＜事前準備・バックアップディレクトリの作成＞

　# cd /home

　# mkdir 20190126bkup

＜事前準備・最新ファイルの用意＞

（１）https://www.netcommons.org/NetCommons3/download　より、

最新ファイルを取得して、例えば /home に配置

（２）（１）のファイルを解凍。

　# cd /home

　/home# unzip NetCommons-3.2.2.zip

解凍ディレクトリ NetCommons3 が生成されます。

（３）解凍ディレクトリをリネーム（後でバージョン等不明にならないように）　　

　/home# mv Netcommons3/ nc322/

＜対象NC３サイトを、閲覧不可にする＞

メッセージ文は前もって書いておくと良い

＜アップデート前のバックアップ＞（自分は、OS、mysql 共に root ユーザで作業しました）

（１）データベース 〇〇〇 のバックアップ（バックアップファイル 〇〇〇.sql　保管先/home/20190126bkup）

　# cd /home/20190126bkup

　# mysqldump -u root -p 〇〇〇 > 〇〇〇.sql 

　（mysql root のパスワードを入力）

（２）ソースのバックアップ（バックアップ先 /home/20190126bkup）

　# cp -r /var/www/NC3インストールディレクトリ/app/Config /home/20190126bkup/

　# cp -r /var/www/NC3インストールディレクトリ/app/Uploads /home/20190126bkup/

以上のバックアップがあれば、アップデートに失敗しても、最悪、アップデート前の状態には戻せます。

インストールディレクトリ全部のバックアップでもいいと思います。

＜Netcommons３本体のアップデート＞

（１）リネームディレクトリ下のファイル、ディレクトリを、既存ＮＣ３インストールディレクトリに上書き

　/home# cp -r nc322/* /var/www/インストールディレクトリ/

上書きが終わったら、上例のnc322ディレクトリは、例えばhokanディレクトリ下に移動等しておく。

（２）cakeコマンド実行してアップデート

　# cd /var/www/インストールディレクトリ/app

　･･･/app# Console/Cake PluginManager.update_all 

　画面に「一括アップデート」が表示されるので、画面の指示どおり、S を入力してEnter

　アップデート処理中、ざっと眺めておく。エラーは黄色表示になるはず。

（３）インストールディレクトリの所有者を「webサーバー（debianならwww-data）に戻しておく。

　# chown -R www-data:www-data /var/www/インストールディレクトリ

＜サイトをブラウジングして確認＞

外部PC等から、アップデートしたサイトにwebアクセスして、ログイン等出来れば完了です！ 

昨日まで、この自宅サーバー（debian９）は、php7.0環境でしたが、

php7.0は、アクティブサポート、セキュリティサポート共に、１２／３に終了していました。

これを何とかしたかったのですが、せっかくなので、OS新規installからやることにしました。

ついでにHDDミラーリングをやめてSSD１本に。

SSDが壊れるリスクについては、定期的なバックアップで対応しようということに。

特にowncloudでは複数のクライアントが繋がっているので、これらのファイルがバックアップになります。

また、最近リリースされたphp7.3もテスト機で試してみましたが、急に不具合が出る可能性もあり、

普段の時間がない時には対応が出来ません。

php7.2は、アクティブサポートが2019年11/30、セキュリティサポートが2020年11/30 までで、まだ余裕があります。

ということで、debian９にphp7.2以降のリポジトリ設定をしてから、php7.2環境を作成しました。

そのあとは、php7.2モジュール、apache２、mariadb、とインストールしていき、割とスムーズに作業が出来ました。

ただ、SSDのパーテイション作成で、マザーボードがBIOSではなくUEFIだったので、UEFIbootパーテイションをあらかじめ作っておく必要がありました。（Windowsインストールなら特に意識しなくていいのかも）

サイトの引っ越しは、以前教えていただいて勉強しておいた方法を再確認しながら進めました。

Netcommonsの内部構造が変わった部分はそれに合わせてバックアップ、リストア方法を変更しましたが、うまくいったようです。

現在、SSDの動きはさすがに早いのですが、以前の高速化の対策がまだ反映されていません。

徐々に対応していこうと思っています。

現行サーバーのハードウェアを変更し、

そこにdebian９、php７．２環境を構築し、

そこに現在のwebページ３つを引っ越しする。

という計画ですが、

ついさっきまで、TESTサーバー機にdebian９、php７．３環境を構築するところまでは出来ました。

そこにNetcommons3をインストールしようとしたところ、Mariadbへの接続でつまずきました。

明日も朝から早いので、残念ながら今日はここまでです・・・

以前書いたように、php7.0は、php5.6より一足先にセキュリティサポートが切れてしまいます！

今すぐ不具合が生じることはないと考えますが、年末までにはphp7.2環境にしてしまう予定です。

でも、多分、何か所かハマリそうだし、時間がかかるでしょう。

はたして年末に時間がとれるか？

しかし、どうせやるなら、ＨＤＤミラーリングもやめて、ＳＳＤ１台にしてしまおうと無謀な計画を立てています。

これにＯＳクリーンインストールからやってしまいます！

さあ、出来るかどうか？　いつ出来るのか・・・

OSインストール、初期設定まで終わったので、owncloud、Netcommons を動かせるようにします。

Mariadb → apache2、php その他 → owncloud リポジトリ設定後 owncloud-file 、とインストールしていきます。

前回は、apt-get install owncloud で、mysql 、apache も同時にインストールされたんですが、

DB、Webserverは各自で選んでください、と変更されたようですね。

・・・白状しますが、Web検索で見つけたコマンド文を、コピペでSSHクライアントに貼り付ける、というセコイやり方を覚えてしまいました！  （SSHクライアントはRloginを使っています）

apache バーチャルホストの設定ファイル、DDNS の cronjob ファイルも、旧サーバーから持って来てしまします。

owncloud は、ssl 通信になるように設定することが重要だと思います。

この時の ssl 証明書は、自己証明書を作ったり、Let's Encrypt を使ったりしていたのですが、

ＯＳから再インストールし直す機会が多くなってしまったのと、また、ほとんど自分専用ということもあり、

ＯＳ内の snakeoil 証明書を使うという安易なやり方にしちゃっています。（ファイルアップロードダウンロードの機能を貸し出す時だけ、アクセス時に警告が出ることについて、事情を説明しています）

旧 owncloud 内のユーザデータは、引っ越しではなく、owncloud-client でクライアントに保管してあるデータに再同期させて新owncloudに取り込むやり方にしています。

owncloud のインストールが終わったら、Netcommons３のインストールに進みます。

また、Netcommons３の引っ越しは、今回はディレクトリ、ファイル全部を持ってきましたが（ＤＢは別に引っ越し）、次からは教えていただいた方法で実行できます！（本当に感謝です！）

もう一つ、php5.6 と php7.0 では、計測してはいないのですが、php7.0 の方がかなり早くなっているような気がします。

さて、最後に、旧サーバーではどうだったっけ？ と、旧サーバーを覗きに行かなきゃならない場面もしばらくは出てきます。

ＩＰアドレスを別々にして、新旧とも動かしながら作業するのがいいと思ったんですが、

今回は、ＩＰアドレスは新旧同じにしたまま、必要な方だけ電源を入れて切り替えるというやり方で何とかなりました。SSH は旧サーバーのみ鍵認証を切って使いました。

こんな感じで、かなり省力化（手抜き？）したやり方なんですが、今後とも、特にOS等の基盤は最新の状態にしておかなければならないので、今後もOSから再インストールという機会は少なくないと思っています。

やり直さなきゃいけない、という状況になった時、身軽に動けるようにするため、とい言ったら怒られるでしょうか？ 

この夏、ようやくDebian９（php7.0）の新環境にすることが出来ました。

Netcommons２がphp7 では動かないので、（今後もphp7には対応させる予定はないとのこと）Debian８のままでしたが、この夏に、何とかｎｃ２サイトをすべてｎｃ３サイトに移行出来たので、ハードウェアも新調してＯＳも最新版にすることにしました。

アスロックPentium J5005マザー、メモリー４GB×２、HDDはWDRed２TB×２でRaid１構成とし、ＯＳはDebian９を使うことにしました。

いつものようにUSBメモリでインストールを始めました。

UEFI install の表示が出て、おや？ と思ったのですが、そのまま続行。

パーテイション作成では、swap 領域は各 HDD ごとに設け、あとはすべて Raid１領域としました。

インストールが進んでいく途中で、動きが重くなっているような気が。

HDDアクセスledが点滅ではなく、点きっぱなし、HDD のアクセス音も途絶えずに鳴りっぱなしです。

こんなことは初めてで、さらにインストール終了まぎわの grub インストールでつまづきました！

grubがインストールできません！！

調べてみると、UEFI インストールの時、ブートローダーが必要とするディスク容量は、BIOSインストールの時よりかなり大きくなる、つまり今までの「予約容量」では小さすぎる、ということのようです。

Raidを構築する前に、EFI system partition 分をディスクに用意しておく必要があるようです。

ということで、パーテイション作成からやり直しです。

ESP（UEFI ブートローダー用パーテイション？）を、各 HDD に約５００MBずつ、

また、swap 領域は各 HDD ８GBずつ、さらに各 HDD に約２５０MBずつの /boot、/boot2 用パーテイション、を割り当てました。

そして、残りをすべて RAID１ パーテイションとして、再度 OS インストール開始。

やはり、インストールが進んでいくと、はっきりと動きが重くなっています。HDDled も赤く点きっぱなしです。

しかし、今度はインストールは最後まで進みました。

再起動すると、やはり HDD はアクセス動作しっ放しの状況です。

HDD がおかしいのか？　もしかして Raid 関係の不具合？

Windows 機で検索してから、proc / mdstat コマンドを打ち込むと、「resync」と「残り時間」の表示が出てきました。

Raid の再同期？ Raid 作成後に最初に resync が走るような設定になったんだろう、ということで、

不具合ではないと思ったので、初期設定から少しずつ済ませておくことにしました。

今回は firewall の設定を最初に済ませました。

そして、OSupdate → OSupgrade → SSH設定（sshd_cofig 編集も）→ NTP設定 、と進んで行きました。

ここまでで、Raid resync を終わらせるために、サーバーを動かしたまま寝ることに。

次の日、Raid の resync は終了していて、HDD のアクセス led も通常通りになっていました。ホッと一息。

そう言えば、以前ubuntu１６サーバーをインストールしてみた時、動きが重いと感じたのは、この Raid resync が走っていたからかもしれません。 

さて、php5.6のセキュリティサポートは、今年いっぱいまでだそうです！

セキュリティ面からも、phpのバージョンアップには付いていかないとダメらしいんです。

ところが！！　何と、php7.0のセキュリティサポートは、今年１２／３までなんだって。 えぇ？

php5.6のセキュリティサポート期限の方が、ずるずると伸びていったらしいんですね。

でも、php7.0までにしておけば、OSアップデートでphpのバージョンも上がっていくでしょう。

ちなみにphp7.2は、２０２０年１１／３０までのサポートです。

という訳で、今回のサーバー機新調作業となりました。 

＜ご注意下さい！＞

以下の方法は、ver 3.1.10 までのものです。ver 3.2.0 からは、uploadディレクトリの場所が変更されたようです。実験して検証が済みましたら、訂正記事を載せたいと思います。

さて、本題の、Netcommons３サイトのバックアップ・リストアがどうやって成功したか、についてです。

繰り返しになりますが、以下の⑥までは以前と同じ内容です。また⑥までがNetcommons２の時と同じやり方です。

　① サイトを閲覧不可にする、又はwebサーバーを停止してから、旧ＤＢ3 ＊＊＊ のダンプファイル △△△.sql 作成。

        # mysqldump -u root -p ＊＊＊ > △△△.sql　（mysql の root パスワード聞かれるので入力）

　② files ディレクトリ（ app / webroot / files ）取得。アーカイブして持ってくる。

　③ 新環境に新ＤＢ3 ○○○ を作成する。

       mysql > create database ○○○ default character set utf8；

　　mysql> grant all privileges on ○○○ to ユーザー名@localhost identified by 'パスワード'；

　　その後、 prefix のみ旧サイトと同じにして、ｎｃ3を新規インストール。

　④ インストール完了したら、mysql にログインして、③の新ＤＢ３をいったん削除。

　　mysql > drop database ○○○； 

　⑤ 再度、③と同様にして新ＤＢ３○○○ 作成。作成後、旧ＤＢ３ダンプファイルインポート。

　　mysql > create database ○○○ default character set utf8；

　　mysql > use ○○○；

　　mysql > set names utf8；

　　mysql > source / home / bk / △△△.sql；  （/ home / bk　に dumpファイルがある場合）

　⑥ app / webroot / files ディレクトリを②の解凍ディレクトリと置き換える。

　⑦ 旧サイトの app / Config / application.yml ファイルを、新サイトに上書きする。

以上の方法で、上手くいきます！！

上手くいったのは、もちろん、天野さんからのアドバイスのおかげなんです！

application.yml を上書きしないと、アカウント関係の情報が引っ越し前と違ってしまうので、ログインできない状況になってしまう、と教えていただきました。

そして、新サイトで出来たＤＢ情報を、引っ越し前環境で出来たＤＢ情報に上書きするのはおかしい、ということなんだと思います。なので、旧サイトの database.php で上書きしてはいけません。自分は上書きしてみた後、このファイル内のＤＢ情報を編集してみたりしましたが、エラーは直らずダメでした。

今年のユーザカンファレンスの資料にあった、 「database.php が大事なファイル」というのは、「prefix 情報の確認のために database.php が大事なファイル」という意味で、上書きしなさいということではないのだろうと判断しました。

以上の貴重な情報は、すべて天野さんからのアドバイスによるものです！

前回お世話になったので、あつかましくもまたメールで助けを求めてしまいました。

やはり、自分のスキルにあった適切なアドバイスをいただき、本当に感謝しています！

天野さん、有難うございました！！

重ねて御礼申し上げます。

最後に、天野さんが注力されている「ｎｃ３＋ NetCommons3 をより便利に」というプロジェクトについて、ぜひ書いておきたいと思います。

Netcommons３関係のプラグイン、pluguin開発の要望引き受け、Netcommons３レンタル、などの開発をしているとのことで、自分もとても興味が湧きました！

特に、Netcommons３のテーマも開発中とのことで、武骨なデザインのNetcommonsがカッコ良くなるのでは？ と自分も期待しているんです！

Netcommons３のバックアップ・リストアのプラグインも、間もなく発表となっています！！

この天野さんのプロジェクトのＨＰは、以下のリンクからたどってみて下さい。ｎｃ３で出来ているのにカッコいいんですよ！

https://nc3plus.com

Netcommons（ｎｃ）３サイトのバックアップ・リストア（サーバー引っ越しの時必要！）の正しい方法をアドバイスして下さったのは、株式会社RYUSの代表、天野龍司さんという方です。

天野さんは、Netcommons３のコアプログラムの開発を行っており、また自社で「ｎｃ３＋ NetCommons3 をより便利に」というNetcommons３プラグイン、テーマその他の開発も行っていらっしゃるエンジニアなんです！

実は、昨年、ｎｃ２をｎｃ３に移行しようと奮闘していて上手くいかなくて悩んでいる時に、天野さんのブログを発見したんです。

そのブログの中で

「移行ツールでうまく移行できないような特殊ケースとかNetCommons2用に開発したプラグインをNetCommons3に移植したいようなケースがありましたらご相談ください^^;」

とありましたので、こちらは企業でもないのに相談にのってくれるだろうか、と思いながらメールしたんです。

その時、意外にも、こちらのスキルを推し量りながら適切なアドバイスを下さり、とても感激したんです！

結局、その時は、自分にはまだ無理な面があり、移行は成功したのか不明だったのですが、今年の夏に再度移行に挑戦した訳なんです。

ｎｃ２→ｎｃ３移行にあたりｎｃ２側の準備について、開発元のページには次のように記してあります。

「現状NC2のDB及びNC2のアップロードファイルを取得して、NC3と同じ環境にDBインポート及びファイル配置をしてください。」

ここまでは何とかできたものの、この後移行ツールを実行すると、エラーが出て上手くいきません。

この時、自分はｎｃ２のＤＢ、ｎｃ３のＤＢのログイン情報は違った状態でやっていました。ｎｃ２のＤＢのログイン情報がないとＤＢに接続できないはずなのに、この情報をどこから引っぱってきているんだろう？　と、素人の自分でもさすがに感じていました。

この時の天野さんのアドバイスは、「NC3のDB接続につかってるアカウントでNC2DBにも接続できるようにすると解決するかなと思います。」というものでした。

そうか！　ｎｃ３のＤＢをｎｃ２ＤＢの接続アカウントと同じにして作らないとダメなんだ！と、やっと分かりました！　

目の前が開けたような感じでした！

これは専門家には当たり前のことで「NC3と同じ環境にDBインポート」という文に含まれている内容だ、ということなんでしょうね。

このあと、移行ツールは走るようになりましたが、成功しているのか、失敗している部分があるのか確かめる手段も分からず、まとまった時間がないと実験も出来ないので放置してありました。

そしてこの夏、まず、方法、手順、アドバイスをおさらいし直して、徹夜したりしながら、何とかｎｃ３に移行出来たのかな、というところまで来れました！（このサイトは移行して出来たものです）

天野さんからのＤＢ接続についてのアドバイスがなければ、今もｎｃ２からｎｃ３への移行は出来ていなかったと思います。

素人相手に適切なアドバイスを下さった天野さんに、本当に感謝しています！！

さて、本題に戻ります。

サーバー引っ越しの時などに必須の作業、ｎｃ３サイトのバックアップ・リストアははたして出来るのでしょうか？

 2018年のユーザカンファレンスの「バックアップ」に関する資料に、「大事なファイル３点」という項目を発見！

このファイル、ディレクトリ、３つをインストールしたての新規ＮＣ３に上書きすれば、いけるに違いない！

と思い、早速やってみました。

引っ越し前の上記すべてのファイルをtarファイルにして、また、引っ越し前mysqlのデータベースはdumpファイルにして、testサーバー機に移動させました。

そして、testサーバーに作成した新規ＮＣ３に、ファイル上書き、DBインポートを行いました。

その結果は、残念ながら、アウト！

前回、app / Config フォルダをコピーした時と同じ結果でした・・・

「内部エラーが発生しました」が出てしまいます。

ディレクトリのオーナー、パーミッションも確認しましたが、ダメでした。

もうお手上げです・・・

「ディレクトリ丸ごと移動」という最後の手段があるからいいのかな、とも思いました。

「ファイル全部でもOK」と上記の資料にもありますしね。

ただ、今回、NC２をNC３に移行した時は、同一サーバー（debian８）内で行ったんです。

よって、出来たNC３サイトは php5.6 環境で install したものです。

このNC３サイトを、php7.0（debian９）環境にそのままコピーしてもいいのか？　何とか動いているように見えるだけで良くないんじゃないか？　という気もするんです。

この手詰まりの時に、救いの一手を差し伸べて下さったエンジニアがいらっしゃったんです！ 

NC２と同様の方法でバックアップ・リストアを試したら、ログインが出来なくて失敗に終わった、と前回書きました。

しばらく、ない頭でずっと考えていたのですが、ちょっと思い当たる件をいくつか書いてみます。

　① NC３ではログイン情報（ｉｄ、パスワード）の扱い方がNC２とは変わっているのでは？

　② ユーザのパスワードはそのままの値ではなく、何らかの規則で変換されているはず（以前ＤＢ内のｉｄ、パスワード、を表示させてみたら、ｉｄはそのままの値、パスワードは意味不明の長い文字列だった）

　③ 職場では、NC２による個人情報を入力してもらうような受け付け方法を禁止する通達が来た。この件が示しているように、NC２では現状のセキュリティレベルを満たさなくなっているのではないか？

　④ よって、NC３では、ログイン情報、その他の個人情報の扱い方は、NC２より進化して改良されていると考えられる。（当然か）

この④の件について、何か分かれば前進するかもしれません・・・

実は、Netcommons3に移行しても、未解決の大問題が残っています。

それは、Netcommons3サイトの引っ越し（リストア）の正しい方法がまだ分からないということです。

これが出来なければ、ハードディスクの交換やサーバーの新調もあるでしょうから、運用はいずれストップしてしまいます。

Netcommns2で用意されていたバックアップ機能が、新Netcommns3にはまだ搭載されていません。（2018.8.21現在）

そこで、Netcommns2の時と同じようにやれば出来るだろうと思い、実験をしておきました。その方法は・・・

　① 旧ＤＢ3のダンプファイル △△△.sql 作成。

　② fileuploadディレクトリ（ app / webroot / files / upload_file）取得。圧縮して持ってきました。

　③ 新環境に新ＤＢ3作成（prefixのみ旧サイトと同一に）してｎｃ3を新規インストール。

　④ インストール完了したら、③の新ＤＢ３をいったん削除。

　⑤ 再度③と同様にして新ＤＢ３作成　→　mysqlコマンドで、use 新DB; → source /○○○/○○○/△△△.sql;　で旧ＤＢ３インポート。

　⑥ app / webroot / files / upload_file ディレクトリを②の解凍ディレクトリと置き換える。

これで、ブラウザからアクセスして、トップページが見えました！

出来た！　と大喜び。

これで行ける、と検証せずに終わらせちゃっていたんです・・・

今回、ｎｃ2サイトをｎｃ3サイトに移行出来たので、ハードウェアも新調して、新サーバーに引っ越ししようと、再度このリストア法を使ってみました。

作業完了してトップページが見えました！

ところが・・・！！

何と、ログインが出来ない！！　ん、パスワード間違えたか？　いや・・・何かおかしい・・・

「パスワードがわからない方はこちら」のリンクも表示されません。

何度確認してもダメでした。

そうだ、旧Configディレクトリを上書きしてみよう。

エラーが出てダメでした・・・　この方法では何か足りないんでしょう。

以前、ＤＢテーブル内のパスワードデータを確かめようとしたことがあるんですが、ＩＤ等と違って、暗号化された（？）文字列でした。この暗号化データを復号させるしくみがどこかにあるのかな？とか。

で、最終的にどう引っ越しさせたのか？

ｎｃ2サイトを移行したばかりのｎｃ3ディレクトリを丸ごと持って来たんです・・・！

ＤＢは、ダンプファイルにして、新ＤＢにインポートしました。

今の自分にはこれしか手がなかったんです。

このサイトもこのやり方で出来ているんですが、今のところ不具合はありません。（と言っても、まだ１週間も経っていませんが・・・）　

ｎｃ3サイトの正しいバックアップ、リストアの方法を教えて下さる方、どうかよろしくお願い致します！！

そして、Netcommons3にもこの仕組みが組み込まれますよう、熱望しています！！ 

＜追記＞

2018.9.13現在、Netcommons 3.1.10 までの対応ですが、このページをご覧ください。

この夏に、Netcommons3への移行作業に手を出してしまい、結局、かなりの日数を費やしてしまいました。

Netcommons2サイト運用で問題はなく、Netcommons3自体が完成までもう少しではないのか？という感じもあったので、迷ったのですが、夏休みでないと、移行作業のためのまとまった時間が取れないということもあり、移行を決心しました。

同一webサーバー内での移行手順を記しておきます。nc2サイトは動かしたままで出来ますが、閲覧停止状態にしておいて下さい。

　① nc3用DB3作成。この時、user、passwordを、旧nc2のDB2のuser、passwordと同じにして作成。DB名は同じでなくて良い。（この場合、同じにはできませんが）

　② 別のヴァーチャルホストを作成し、別ドキュメントルートにnc3ファイルを展開しnc3をインストールする。DB3のprefixはDB２とは別にする。

　③ インストールが終了したら、サーバーOSにログインし、インストールディレクトリ / app に移動。カレントディレクトリを移動せずに、フルパス指定で実行するとcakeがうまく動かない。

　④ # ./Console/cake Nc2ToNc3 --database NC2のDB名 --prefix NC2のテーブルプレフィックス名 --upload_path NC2のアップロードファイルフォルダーパス --base_url NC2のベースURL --nc3base NC3のベースパス

を入力してEnter（実行）。

実行文の例を参考にして下さい。また、このページのやり取りも参考になりました。上記「NC3のベースパス」は自分の場合は、ヴァーチャルホストのドキュメントルートにnc3ファイルを展開したので、「/」としました。

　⑤ 実行経過が順次示されていくので観察する。実行が最後まで進んでも、エラーが出ると完成サイトにアクセスできない等のトラブルが起こることがある。（かなり長い時間がかかる。自分の場合は２０分以上！）

　⑥ 完成サイトにアクセスして、トップページのお知らせモジュールを削除、phpメモリ設定、送信メール設定等を行う。失敗していたら、DB3削除、nc3インストールディレクトリ削除して、最初からやり直し。

　⑦ 旧urlでアクセスしたいのなら、/app/config/application.yml の fullBaseUrl:を旧urlに書き直す。

　⑧ 各フォルダのパーミッションを確認して設定しておく。このページの、インストール後のパーミッション参照。

　⑨ 新ヴァーチャルホストの、servername、ドキュメントルートパス等の記述を書き換え、設定を読み込む。またｎｃ２サイトのヴァーチャルホスト設定は無効にする。その後apache再起動。

 以上ですが、恥ずかしいことに、最初は全く分からず、cakeを別にinstallしなければいけないのか（実際は不要）、とか、上記DB2、DB3のアクセス情報が同一でなかった（これではツール動かない）、とか手探りの状況でした。

もちろん、「Netcommons問い合わせ」にメールで質問はしたのですが、どうもNetcommons開発母体が有償サポートの方針のようなんです。

多様なニーズ、セキュリティ面など、今後のアプリケーション開発はますます大変になっていくだろうと思われます。当然、開発費用もかなり必要になってくるでしょう。ということで、利用に際してある面では有償になるということは、止むを得ないのでしょうか。

こちらは、全くの無料で使わせていただいているので、やはり文句は言えないのかな、と考え直した次第です。

実は、そんな中で、貴重なアドバイスを下さったエンジニアの方もいらっしゃったんです！

Netcommons３開発者の一人である天野さんという方です。

この方のアドバイスを「ＮＣ３サイトのバックアップリストアについて（３～５）」に記しましたので、是非読んで下さい！

さて、自分のサーバーでは、Netcommons2サイトを3つ公開していました。

上記の方法で2つのサイトは何とか移行できましたが、残り１つがどうしても上手くいきませんでした。

移行ツールは途中エラーが出ながらも最後まで走るんですが、完成サイトにアクセスすると「不正なリクエストの可能性があります」と表示され、さらに無限ループの応答になり、失敗します。

エラーを見ると、Undefined index : room_id、Undefined index : user_id　が出ています。さらに、移行できないphotoalbum dataがある、というような内容でした。

ｎｃ2サイトに戻り、まず退会したユーザを削除して、再度移行を試しましたが失敗。

そこで、今までのｎｃ2サイトでの運用をたどってみて、ある利用者Ｎさんの管理者権限をユーザ権限に変更したことを思い出しました。photoalbumもＮさんの作成だったんです。

で、ｎｃ2サイトのＮさんの権限を再度、管理者権限に戻し、移行をやり直しましたが、結果は変わらずで失敗。

結局、Ｎさんの作った photoalbum を削除して、やっと移行が成功しました！（ここまで１週間近くかかりました）

Ｎさんが管理者の時に作っていた photoalbum と 画像データは、Ｎさんをユーザ権限に変更した時点でｎｃ２内での扱いがおかしくなっていたのでは？ と想像しています。

ユーザ権限では、photoalbum を作ったり編集したりできない訳ですから。

まあ、とにかく、ここまででやっと何とかなったようなんですが、この後手を出した件で再び泥沼にはまることに・・・

自宅にある数代のWin7機に、Win10へのアップグレードの通知が頻繁に来ていました。
ずっと無視していたら、カミさんに貸していたデスクトップPCがupdateでつけっ放しにしていたところ、やられました！　（皆さんもやられたと思いますが！）
次の日に、何か変だから見てくれる？と言われ、確認したらWin10にされちゃっていました。
ところが、起動やソフトの動きは、ほぼ速くなっているようで、
この新しいカーネルはいいんじゃない？　と簡単に、自分もWindows10に寝返ることにしちゃいました！
ただIE11は頻繁にフリーズするようになってしまい、MS Edge、Chrome等も併用してしのいでいます。
プリンタも含めたデバイスの認識や、常用しているソフトの動きに問題がなければWin10にしてしまった方がいいと思います。
実は、アップデートではなく、クリーンインストールする方法も見つけたので、
DAWマシン、ラジオサーバーはその方法で作成しました。
（これは2016年6月の記録です）