virtualbox/windows10(クリーンインストール後)でVCCW、vagrant up!!
クリーンインストールして、純正windows10へ気分よくvirtualbox入れてchocolateyでvagrant入れて、VCCW の box add して アプリ層も git clone 、そしてsite.yml も日本語化などお好み設定してvagrant up!!仮想マシン正常に動かない‼F〇ck!!
VMは、一応、起動しましたが、vagrant ssh できない。ゲストＯＳに入られません。vagarant ssh-config をしても思いっきりパスが違う・・・。バージョンは、VirtualBox 5.1.4 for Windows hosts、Vagrant 1.8.5 です。Virtualboxのインストールパスはシステム環境変数で確認し、きちんと通っていました。尚、Vagrant 1.8.5 にはバグがあるという事が既にgit hub issue であがっています。通常の手順で vagrant up するとこけます。vagrant up の前に鍵の設定手順は Vagrantで”Warning: Authentication failure. Retrying…”のエラーが出た時の対処法 を参照ください。鍵設定後は、パーミッションの設定（Provisioning doesn’t work without changing ssh key permisions）を参照ください。
chocolateyを疑ってみる
chocolateyでvagrantはなく、手でVirtualBoxとVagrantをインストールやり直してみる。chocolateyのgithubも色々とissueが出たままになってるものもあり、疑うことは必要だと思います。chocolateyが原因だろうな～と予測されるような、わかりにく～い躓きも、結構、遭遇します。
ググると、VirtualBoxのダウングレードで5.0.0あたりにするといいらしい（ですが、検証したらダメでした）。Vbox.logでは Error: Unable to connect to system D-Bus (1/3): Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory が出ており、どうやらD-busとかGuestAdditionあたりらしいです。
Cygwinはsshを自分でインストールする必要がある
D-busとかGuestAdditionの対処は、設定した事そのものを忘れて、何かの拍子でエラー原因の分析に膨大な時間消費地獄に陥っても嫌なので、バージョン下げで対応してみる。過去バージョンはDownload VirtualBox (Old Builds)で探し、5.0.0に ⇒ ダメ。VMは立ち上がるけど、ssh出来ないということで、結局、windowsホスト内にsshがインストールされていない事によるsshが使えないことが原因と断定しました。バージョンが問題ではないです。
そうなるとchocolateyでは、インストールパッケージをいじる必要があるCygwin と バージョンを独自に管理する可能性が今後も出てくるかもしれないVirtualboxやVagrantは、独自インストールしないと対処できない問題が出てくる可能性が今後もある。
chocolateyでパッケージ管理しないほうがいいもの、独自インストールした方がいいものなど、余計に管理が煩雑になるので、chocolatey無しにします。
ここまでたどり着くのに、何度も検証でいろいろなパッケージのインスト―ル/アンインストールを繰り返し、猛烈に時間消費しました。F〇ck!!
chocolateyは開発途上のため、chocolatey側でアンインストールしたあとにプログラム一覧なり直接アンインストーラ起動なりでWindowsから消す必要がある。
これは重要情報！chocolateyからの各種パッケージのアンインストールはコケる！再度windows10クリーンインストール？ chocolateyがトラブルメーカーな事が浮き彫りになりました。chocolatey開発コミュニティの進展が起こらない限り、採用しない事に決めました。
ということでいろいろあり、chocolateyで入れてしまったCygwinをアンインストールして再度やり直し、見事にホストマシンに残骸が残る⇒開発ツール/Cygwinのアンインストール手順
レジストリのインポートはリスクが高い。
Cygwinアンインストール失敗の残骸が残りました。また、レジストリか。もう二度と出てくるな、F〇ck！笑！レジストリの削除のやり方が間違っているらしく、うまくいかない。レジストリ検索で引っかかったものすべてを削除していると、キーファイルだけの削除なのか？フォルダ丸ごと削除なのか？だったり、他のアプリケーションのパスっぽいけどパスの最後尾にcygwinが入っているもの、その他いろいろなパターンがあるけど、どれを消すべきなのか？このあたりは、windowsアプリ開発が得意な会社や人に教えを請うべきかも。レジストリ作業は、初心者にはハイリスクです。一度、クリーンインストールしているので、良くも悪くも度胸がつきましたが・・・。レジストリと環境変数については、おそらくwindowsアプリ開発を学習しないと正しく理解しにくいかも。
WindowsでGUIによるアンインストールが正確にできないアプリケーションほど、タチの悪いものは無い。手動アンインストールのスキルは、ちょっと高価だと思う。
レジストリ手動削除がうまくいかない場合、レジストリバックアップのインポートに頼るという方針が既に間違い（２回目）。再びレジストリ復元できず！レジストリをインポートできません。を参照すると、他の起動中アプリケーションが邪魔をしている可能性がある。そのため、極力、起動中のアプリケーションを減らしてからインポートするか、セーフモードでインポートが必要。でも、セーフモードのインポートもダメでした。セーフモードでも競合するシステムプログラムが存在する場合、競合プログラムを停止してから、レジストリインポートする事になります。競合プログラムを見分ける術を持っていないとアウトです。競合を見分ける方法がイマイチわからない為、再びクリーンインストールしました。スキルを身につけるまでのOJTの時間犠牲が多過ぎる。Microsoft もっとシンプルなOSにできなかったのだろうか。改めて後日に調べたところ、セーフモードでもダメな場合、BIOSやデバイスマネージャーを使ってIRQ（Interrupt ReQuest：割り込み要求）競合を見ていく事がポイントになってくる様です。
cygwinへのsshインストール
2回目クリーンインストール後、How to install OpenSSH on Windows 10を発見しましたが、oracleに書かれているCygwinのインストールおよびSSHデーモンの起動を歴史の長さという観点で安定性を信じて採用しました。ご参考に、cygwinのsetup.exeはパッケージの上書きインストールなどを後から行う可能性があるので、ゴミ箱に移動せず、保管しておいたほうが賢明です。でも、cygwinのsetup.exeはアップデートが今も微妙に続いている様です。※Windows 10 Anniversary Updateはクリーンインストール後に行った長時間の windows update で自動的に含まれていました。
//Cygwinパッケージ一覧 cygcheck -c //個別パッケージ確認 cygcheck -c unzip//unzip cygcheck -c openssh//openssh cygcheck -c openssl//openssl //こちらも似たような感じ which unzip which ssh which ssl //パッケージ単体の中に何が含まれているか確認 cygcheck -l unzip //あるファイルがどのパッケージに含まれているのかを確認 cygcheck -f /usr/bin/unzip.exe
Virtualbox / Vagrant のインストール
上記よりダウンロード。
vagrantにプラグインを入れる。
//vagrant プラグインhostsupdaterを入れる vagrant plugin install vagrant-hostsupdater //vagrant プラグイン何が入っているか確認 vagrant plugin list //vagrant バージョン確認 vagrant -v
windows10 hostsのアクセス許可設定の確認。C:/WINDOWS/system32/drivers/etc/hosts にて、hostsを右クリック、プロパティ、セキュリティタブ、編集、グループ名またはユーザー名でUsersを選択し、アクセスコントロールでUsersを許可でフルコントロールに変更、適用、OK。
Gitを入れる(gitを使いたい人)。
私家版 Git For Windowsのインストール手順がとても丁寧に説明してくれています。Path や 改行 や 初期の基本設定 など、シンプルでいいです。
Cygwinでgitを使いたいので、pathを通す選択をしなければならないのが、ちょっと微妙。git自体の更新は、gitアンインストールと再インストールですが、他のパッケージ管理上でgitを使ってパケージの不具合などのリスクにさらされたくない為、gitは単体で入れています。パッケージ管理に依存して、パッケージ管理のバグに巻き込まれるリスクは減らせると思います。
VCCW2系の設定
VCCWで詳しく確認できます。windowsの方は、hostsの設定をよく考えて確認しましょう。
Cygwinで行いました。vagrant box 追加
vagrant box add miya0001/vccwvccwのアプリケーション側ファイル達を任意のフォルダに構成
※cdコマンドで任意のフォルダに移動してから行ってください
git clone https://github.com/vccw-team/vccw.git
さらにvccwのフォルダまでcdコマンドで移動。site.ymlをお好み設定で設置ですが、site.yml内のlangで要注意です。
//VCCWのV2でsite.ymlのlangがこける！ //以下2つダメ、日本語は悲しい言語ですね lang: ja lang: ja_JP //こんな感じでエラーが出る！ Error: The requested locale (ja_JP) was not found. //英語でOK、あとから手で治しましょう lang: en_US
他、DBの接頭辞もwordmoveの際に差異があるとうまくいきません、site.ymlの段階でDBの接頭辞をリモートホストに合わせておきましょう。site.ymlでメモリ、hostname、DBアカウント、phpのバージョンや初期同梱プラグイン、ワードプレスのユーザーなど、よく見ながら各種の設定を行ってください。
最後に、新しく作ったsite.ymlやMovefileのあるディレクトリまでcdコマンドで移動してvagrant upコマンドを行い、プロビジョニングが終わるまでしばらく待ちます。ご参考までにvagrant upではなく、vagrant up –debug を使うと、bootでコケる時に原因を突き止めやすくなります。
PCのスペックにもにもよりますが20分から1時間以上かかる事も有ると思います。プロビジョニングが終わったら設定したhostnameをブラウザに打ち込んでデフォルト状態のWordpressがVirtualbox内の仮想環境として動いている事を確認してください。
初回vagrant up直後.htaccessだけ、コミットを別けてgitでしっかり保管しておいた方がいいです。wordmove pull –allで.htacessが消えて500errorに陥り、時間を奪われます。
windows10上のVCCW3系が激しく遅い
本番環境から開発環境のVCCW3側に対してwordmove pull –allを便利に行っていましたが、php7かWordPress4.7.1あたり以降、めっちゃ遅い。WP4.7.1かWP4.7.2のRestAPIのお祭りはおそらく関係ない。開発で使えない致命傷レベルの遅さでヤバい。原因調査の進捗は以下の通りです。2017年1月か2月頃から一斉にワードプレス達がWindows10のVCCW3でボロボロにtimeoutやらfatal errorでコケ始めた。誤解を避けるために、VCCW3は悪くないです、むしろ偉大です。
wp-settings.php:449とは？
wp-settings.php:449のdo_action(‘init’);はテーマやプラグインなどでadd_actionを使って追加できるアクションフック。php.iniのoutput_bufferingをonにするだけではダメでした（vccw3はubuntuなのでphp.iniの置き場所に注意）。本家Contact Form 7の『WPCF7_Shortcode 非推奨』への変更がプラグインContact Form7: Autocompleteには反映されておらず、それがエラー吐いてます。エラー非表示まで行けましたが、それでも、まだ開発に使えないくらい致命的に遅い。Virtualbox/Vagrant上におけるubuntuの設定やホストのマシン側が原因な気がしてきた。
VCCW以外のWordPress開発環境ツールはある？
起動が速いと思うのは、InstantWordPressですが、開発用の複数のプロジェクトをローカルでVM管理する事には向いていません・・・。他、コア開発で海外で有名なvagrant環境のVVVなどもあります。その他DockerのWockerも含めて海外にはいくつか開発環境があります。
初回wordmove pull –all直後、Internal Server Errorで高確率でコケる
よくある事でイラっと萎えますが、本番環境とVCCWのローカルVMでサーバー構成等が異なる事によるhtaccessの違いが大きいと思われます。apacheログなどを見ながら直しましょう。レンタル共有サーバーでUbuntu（VCCW3）というのは少ないはずなので、必ずコケルと言ってもいいくらいだと思います。先にgitでとっておいた、.htaccessが大活躍する時です。
//500エラーのapacheログ確認 tail /var/log/apache2/error.log //もしくは tail /var/log/apache2/独自ドメイン-error.log
今回は、以下の様なものが記載されていました。
//エラーログ /var/www/html/.htaccess: Require not allowed here
SiteGuard WP PluginやiThemesSecurityなどセキュリティ系プラグインによる仕業であることが大半と思われます。本番環境に悪影響を及ぼしますが、プラグインを外す、.htaccessで該当部部分をコメントアウト、キャッシュ（プラグイン）も削除など、VCCW3のUbuntu apache環境に合わせましょう。本番環境がCentOS NginxでVitualbox/vagrantの環境とそもそも異なる場合なども多いと思います。WP-CLI等でやってみるなどもありかもしれません。開発環境と本番環境の独自ドメイン差異とphpのDB周辺シリアライズへの対応ツールを使う必要があるという点も忘れてはマズイ点です。
エラーを吐きまくるタイムアウト誘発プラグイン
Jazzy Formsプラグインが未定義エラーをめちゃくちゃ吐きまくり、タイムアウトします。Custom More Link Completeプラグインもhas_capを使いだしてエラー吐きまくりタイムアウトします。プイラグインによっては、ローカルのVMで開発を行う事は避けたほうが無難。開発用のサーバーを借り上げるべきです。
『http://独自ドメイン/wp-login』が隠せない
iThemesSecurityで、①http://独自ドメイン/wp-login.php ②http://独自ドメイン/wp-login ③http://独自ドメイン/wp-admin ④http://独自ドメイン/wp-admin.php のうち、②のhttp://独自ドメイン/wp-loginがhide backendで消えないケースが、サーバーやワードプレス側の設定により稀に発生し、wp-loginに対するブルートフォースでログインで突破される可能性があります。iThemesSecurityなど高度なセキュリティ系プラグインは非常に有用ですがワードプレスの知識だけでなく、Linux/apache/nginx/firewallの知識が必要不可欠ですので、Linuxサーバーを建てられて、なおかつワードプレスのphpやajaxもわかるという方でない場合、設定でわからない事が必然的に多くなります。オブジェクトキャッシュやデータベースキャッシュ、その他のキャッシュがわからない人がキャッシュ系のプラグインを使ってハマる事に似たような感じです。セキュリティ系プラグインを設定する場合、幅広いセキュリティ知識が必要です。
KUSANAGIとセキュリティ系ワードプレスプラグインとwordmove
ローカルはVCCW、本番環境はKUSANAGIのクラウドやVPSなど、サーバー環境が異なる開発、本番、というしんどいところも結構あると思うので、ちょっと書く場所が異なるかもしれませんが、書いちゃいます。KUSANAGI（正確にはKUSANAGIのMUプラグイン）とセキュリティ系プラグイン（SiteGuard WP PluginやiThemesSecurityなど）とwordmoveは、Linuxユーザーの設定やパーミッション管理がかなり大変です。適当にやってしまうとセキュリティ的に危険な事も起こります。データベースを引き継いでテーマ変更など、ワードプレスリニューアルの際は、プラグインであってもしっかり見積請求をしておかないと検証など、工程や暗中模索がかさみ、時間やお金がかなりかかるのでしっかり請求しなければならないです。想像以上に時間を奪われます。KUSANAGIでNginxの場合、iThemesSecurityプラグインのnginx.confの場所設定の際にもパーミッションがかなり厄介です。/etc/nginx/nginx.confだけでなく、/etc/nginx/conf.d/プロファイル名.conf です。Linux/Nginxにおけるバーチャルホストの設定、Linuxユーザー権限設定なども絡んできます。パーミッションまわりをきつく行うと、『wordmoveが使えなくなる問題』も起こり、不便度数急上昇でかなりメンタルも萎えますので、要注意です。
