PC設定覚書と雑記
昨日まで、この自宅サーバー（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３のバックアップ・リストアのプラグインも、間もなく発表となっています！！
この天野さんのプロジェクトのＨＰは、以下のリンクからたどってみて下さい。ｎｃ３で出来ているのにカッコいいんですよ！
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 までの対応ですが、このページをご覧ください。