satoru
Forum Replies Created
-
Posts
-
修正を完了しました。
kusanagi-docker コマンドを更新すると、wp-config.phpにWP_DEBUGが複数含まれる不具合は解消します。
kusanagi-ftpdのバージョンを更新し、正しく起動するように修正しました。docker-compose.yml を直接修正し、kusanagi-ftpd のバージョンを 1.0.4-r0 に変更してください。
ftp: container_name: wordpress_ftp image: primestrategy/kusanagi-ftpd:1.0.4-r0 restart: always宮崎と申します。
ご指摘ありがとうございます。- –admin-passwd</br>ご指摘の通り、–admin-pass が正しいです。ドキュメントおよびヘルプを直します。
- –admin-email</br>ここかのタイミングで間違えて消してしまったようです。追加します。
- –-admin_user</br>ご指摘の通り、–admin-userが正しいです。変更を行います。
- —–END DH PARAMETERS—–‘ may not contains whitespace.</br>Macの改行コードの問題の用です。この現象はdocker-compose down/up しなければ発生しないはずです。こちらも修正します
ご指摘の内容は近いうちに修正したいと思います。何かあれば今後ともご指摘ください。
ありがとうございました。nginx の設定ファイルで rootの設定を変更する、もしくは apacheの設定ファイルで DocumentRootの設定を変更することで、別コンテンツとWordPressの公開を切り替えることは可能です。
ただし、この場合別コンテンツ部分とWordPress部分を同時に表示することはできません。別コンテンツとWordPressを同時に表示するには、以下の方法で可能です。
http://www.example.jp というホストで公開するものとします1 kusanagi provision –lamp –fqdn http://www.example.jp contents でLAMPプロファイルを作成、別コンテンツを/home/kusanagi/contents/DocumentRoot へ配置
2 kusanagi provision –WordPress –fqdn test.example.jp http://www.example.jp で公開後のWordPressプロファイルを作成し、WordPress構築これで、www.example.jp にコンテンツ公開し、WordPress部分は test.example.jpという名前のホスト名でアクセス可能になります。
公開ディレクトリ切り替えは、kusanagi setting –fqdn pre.example.jp contents を実施して別コンテンツのホスト名を変更後、kusanagi setting –fqdn http://www.example.jp http://www.example.jp でWordPressのホスト名を本番用(www.example.jp)に変更することで実現できます。
切替前：
http://www.example.jp /home/kusanagi/content/DocumentRoot
test.example.jp /home/kusanagi/www.example.jp/DocumentRoot切替後：
http://www.example.jp /home/kusanagi/www.example.jp/DocumentRoot
pre.example.jp /home/kusanagi/content/DocumentRootKUSANAGIで使用できるページキャッシュには、NGINXの機能を使用するfcacheと、KUSANAGI Pluginで実現するbcache があります。
bcache は、WordPressで生成されるページが対象となるため、WordPressのwp-load.phpを読み込んでいないPHPページはキャッシュされません。bcacheをクリアする場合はKUSANAGIプラグイン画面からキャッシュクリアするか、kusanagi bcache clear を実行してください。
一方fcache では、WordPressのwp-load.phpを読み込んでいなくてもキャッシュされます。
fcache を任意のタイミングでクリアする場合は、kusanagi fcache clear を実行してください。yum update時に、_http.confと_ssl.confをRPMのファイルで上書きするのは
kusanagi-nginx の仕様です。
というのも、このファイルを変更することをあまり想定していなかったためです。たしかに、アップデート時にこのファイルを上書きするのは問題がありそうですので、
次回更新時にはconfigファイル扱いとし、旧ファイルが _http.conf.rpmsave のように
リネームされるようにしたいと思います。自分のConoHaの環境でも激遅になっていたので、調べてみました。
どうやら、ConoHaの1GBメモリのマシンではKUSANAGI標準設定だとswapが頻発していました。
以前はそんなことなかったのですが。手っ取り早く使用メモリ量を減らすために、以下のようにMySQLの設定(/etc/my.cnf.d/server.cnf)を変更し、MySQLを再起動して下さい。
（変更前） query_cache_size = 128M innodb_buffer_pool_size = 384M （変更後） query_cache_size = 64M innodb_buffer_pool_size = 128Mまた、4GBメモリのマシンでも変わらないということは、別要因の可能性があります。
以下の情報があると特定がし易いです。kusanagi status の内容
plugin のリスト(できれば)HHVMを使用している場合、プラグインによっては遅くなります。
その場合は該当プラグインを停止するか、PHP7を使用することを検討して下さい。provision 時に配置される kusanagi-core ディレクトリの元は、
/usr/lib/kusanagi/resource/DocumentRoot/wp-content/mu-plugins
以下のファイルを元にコピーされますので、これを cp コマンド等を用いて復元することが可能です。
mu-plugins ディレクトリに移動して以下のコマンドを実行してください。
cp -r /usr/lib/kusanagi/resource/DocumentRoot/wp-content/mu-plugins/kusanagi-core ./yum install zabbix-agent を実行してみて下さい。
おそらくKUSANAGI-7.8.x 以前からKUSANAGI-8.0.xにインストールしたことがあるのだと思いますが、
ここで、zabbix22-agent から zabbix-agent-3.0.x に変更しています。このアップデート後すぐにリブートした場合、
zabbix-agent がインストールされない事象が発生します。この場合は、手動でzabbix-agent をインストールして下さい。
基本、FQDNはご自分でお持ちのドメインに登録されたホスト名を指定して下さい。
もちろん、評価・テスト用に適当なホスト名をつけるのは可能です。その場合、/etc/hosts ファイル(Windows では c:\Windows\system32\drivers\etc\hosts)に、以下のようなエントリを追加する必要があります。
192.168.10.10 host.example.comまた、その場合はLet’s EncryptによるSSL証明書は取得できません。
それで大丈夫です。
ConoHaでKUSANAGIのインスタンスをデプロイする場合、以下のドキュメントを参照して下さい。また以下の記事で、KUSANAGIでLaravelを動かしているので、こちらも参考にして下さい。
VMwareとqcow2 のイメージは公開されていますが、これではだめですか?
http://download.prime-strategy.co.jp/kusanagi_cloudn.qcow2
http://download.prime-strategy.co.jp/CentOS7.2_64_kusanagi7.8.3.ova
