PC設定覚書と雑記
この夏に、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 を作ったり編集したりできない訳ですから。
まあ、とにかく、ここまででやっと何とかなったようなんですが、この後手を出した件で再び泥沼にはまることに・・・
netcommons2 から 3 にアップデートするには、アップデートパッチを当てるとかではなく、移行ツールなるものを使わないとダメなんです。（システムが全く別物になっている）
ところが、この移行ツールがまだ見当たりません。
今年の 8月のユーザーカンファレンスのプログラムには、「移行ツールの使い方」が公表されているので、この夏に出るのかもしれません。
このサイトも、移行ツールで netcommons3 にリニューアルする予定です。
新しくしたい最大の理由ですが、OS の php がほとんど ver7 になってきているのに、netcommons2 は php7 では動かないんです。（ debian9 も php7 ）
netcommons2 が php7 対応になってくれればいいんですが、どうもそれはやってくれなさそうです。
また、owncloud も php7 で動かした方がパフォーマンス等良くなるでしょう。
ということで、nc3 への移行ツールを心待ちにしているところです。
でも不安が・・・
簡単に、すべての内容が移行できるのか？
また、超長～い時間ハマって苦しむんじゃないかなあ・・・
マザーボードは、Asrock社の J3710M（Pentium J3710オンボード）です。
前回 Celeron 847 からの比較では、TDP 17W → 6.5W、クロック 1.1GHz → 1.6GHz（ターボ 2.6GHz）、コア数 2 → 4 で、省電力化しているのに、基本性能は向上しているのが嬉しいところ。
しかもSOCなので、チップセット込みで 6.5W なんです！
キャッシュは 2 ＭＢ と変わらずですが、コア数 2 倍になっているので 1 コアあたりは減少していますね。
送料手数料込みで 9,970円でした。
RAID 1 にする HDD は、WD 社の Red 2TB 2台としました。
メモリーはDDR3－8GB × 2がそのまま流用できました。この板でもデュアルチャンネル動作はOKでした。
電源ですが、今年 4月に壊れて新調したばかりなので、これも流用しました。（Corsair RM550x）
デバイスが省電力なので、BIOSはパフォーマンス優先設定としました。
試しに、Ubuntu16、Ubuntu14、Debian8、をインストールしてみましたが、なぜか最新の Ubuntu16 は立ち上がりがかなり遅かったような気がします。何かしらの新しい機能追加でしょうか？（メーカー発表の対応OSには Ubuntu16 、Debian8 は載っていないのですが）
ハードウェアより OS が若干新しい程度ですから、デバイスの認識に難があったとは思えません。
使いたい netcommons2 は、php7 非対応なので Ubuntu16 はダメ。
で、最初から身軽な debian がやはりいいだろうということで、debian8_64bit版に決定しました。
apache、phpのキャッシュ方法、mysqlの最適化をちょっと勉強して設定してみました。
webサーバーの動作は、以前よりキビキビしているようですし、今のところ順調に動いています！
自宅にある数代のWin7機に、Win10へのアップグレードの通知が頻繁に来ていました。
ずっと無視していたら、カミさんに貸していたデスクトップPCがupdateでつけっ放しにしていたところ、やられました！ （皆さんもやられたと思いますが！）
次の日に、何か変だから見てくれる？と言われ、確認したらWin10にされちゃっていました。
ところが、起動やソフトの動きは、ほぼ速くなっているようで、
この新しいカーネルはいいんじゃない？ と簡単に、自分もWindows10に寝返ることにしちゃいました！
ただIE11は頻繁にフリーズするようになってしまい、MS Edge、Chrome等も併用してしのいでいます。
プリンタも含めたデバイスの認識や、常用しているソフトの動きに問題がなければWin10にしてしまった方がいいと思います。
実は、アップデートではなく、クリーンインストールする方法も見つけたので、
DAWマシン、ラジオサーバーはその方法で作成しました。
（これは2016年6月の記録です）
WebServerマシンのOS入れ替え作業を行いました。
まず、3つのwebサイト本体のバックアップ、
ヴァーチャルホストの設定ファイル、DDNSへの通知スクリプトファイルも忘れないようバックアップ。
次は、ルーターのIPマスカレード設定を無効にして、外部からアクセスを受けないようにします。
そして、マシン内部の掃除、異常がないか、目視点検です。
電源、マザーボード、HDD等、温度異常もありませんでした。
HDDをまっさらにする前に、もう一度忘れている作業がないか、一息考えます。
では、いよいよOSの再インストールから始めます！
OSはDebianの最新版、Jessie64bit版を使います。
webサイトが正常にリストア出来るか、LAN内でですがテストはしておきました。
クライアントのWindowsマシンで、netinst.isoファイルをダウンロードし、フリーソフunetbootinでインストール用USBメモリを作っておきます。
CDRでインストールディスクを作るより、手軽で確実で早いです！
CDドライブはwebサーバー運用中は不要ですから、尚更です。USBメモリインストールで決まりでしょう。
USBメモリは高速タイプがいいです。今回64GBメモリはうまくいかず、4GBメモリを使いました。
HDDは、3.5インチ2TBを2台ソフトウェアRAID1とし、パーテイションは2つに分けました。
OSインストールは最小構成です。デスクトップ、GUIはもちろん、基本的なユーティリティも入れません。
apache、mysqlも最初にはインストールしません。aptでowncloudをインストールする際に、依存関係も含めて、またphp等必要なものも一緒にインストールしてくれるからです。
作業手順ですが、
OSインストール → OSアップデート → rootログイン禁止 → ユーザsudo設定 → サーバーリモートログオン設定 →ファイヤウォール設定 → 必要なrepository設定 → 再度OSアップデート → owncloudインストール → owncloud設定 → netcommonsインストール → netcommonsリストア（作業手順はこちら） → ルーターIPマスカレード設定 → 動作確認
こんな感じで進めていきます。
今回も、結局徹夜の作業となってしまいましたが、何とか完了しました！
WebServerマシンの目視点検と清掃を行いました。
webアクセスが無い事を確認して、
リモートでシャットダウンし、作業を行いました。
ホコリが随分たまっていたので、エアダスターで取り除きました。
目視では異常がなく、復旧後も正常に動いています。
連絡せずにシャットダウンしましたが、
不都合等ありましたら、ご連絡ください。
kona-linux lite3.0、kona-linux black も試しましたが、ブラウザ動作中の軽快感はどれも変わらない感じでした。
3.0 はOSカーネルが最新版になっていますが、これらの環境ではメリットが感じられませんでした。また、blackではデスクトップにアイコンが置けません。
ということで、kona-linux lite2.3 を使用中です。
しかし、Firefoxを立ち上げてフル画面描写させただけで、CPU利用率がすぐに80％を超えたりするのにはちょっと驚きました。
puppy-linux、lubuntu、linux-bean、linux-mint（lmdeも）くらいかと思っていましたが、
国産の kona-linux というディストリがあり、その中にも色んなタイプがあるようです。
debianベースで、non-paeのCPUにも対応していて動作も軽い！とのこと。
kona-linux3.0lite は、debian8 がベースになっている軽量版です。
早速、職場のPen4デスクトップpcにインストールしてみたいと思います。
ルーターの設定を確認すると、やはりポートが開いていませんでした。
とりあえず、決めておいたポートを開けましたが、
今度は、設置場所でのWANアクセステストは出来ない訳です。
夕方、川越の自宅に帰り、openssh-serverをリモートでインストールし、
（どうやってリモートインストールした？）
configファイルを修正し、SSHサーバーを再起動。
Teratermから無事にアクセス出来ました！
このTeraterm、scpも実装されていて、ファイル転送も出来るんです！
今までは別の手段でリモート管理していたのですが、Debian8環境のテストサーバーではうまく動かない場面が出てきました。
そこで、SSHログインを試すことにしました。
LAN内では鍵認証方式もうまくいったのに、WAN環境では結局うまくいきませんでした。
ポートは開けたつもりだったんですが、ルーターのポートがどうも開いていなかったようです。現地のルーターは遠隔操作できません。
サーバー設置場所に出向いていって作業するしかありませんね。