サーバー運用とPC日記

このサイトのシステムである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インポート」という文に含まれている内容だ、ということなんでしょうね。

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

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

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

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

さて、本題に戻ります。

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