satoru
Forum Replies Created
-
Posts
-
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.ovawp search-replace で、DBの内容を置き換える部分で問題があるようです。
kusanagi ssl --email, kusanagi ssl --cert/--key, kusanagi setting は
DocumentRoot/wp にWordPressを移動しているとうまく動作しません。なお、上記の状態でもDB上のhttp://FQDN/ が https://FQDN/ に変わらないだけで
Let's EncryptのSSL証明書が取得でき、NGINXも再起動している状態です。もし手動で修正したい場合は、root アカウントで以下のようにコマンド実行して下さい。
# FQDNは、provision 時に指定したホスト名を指定して下さいwp search-replace http://FQDN https://FQDN --path=/home/kusanagi/プロファイル/DocumentRoot/wp/ --all-tables
まず、kusanagi provision 実行直後のDocumentRootをtar ball で固めるなどして下さい。
その後、wp1、wp2 のディレクトリをkusanagiユーザ権限で作成し、上記tar ballを展開します。/home/kusanagi/kusanagi_html/wp1 のようにすると、NGINX/Apacheの設定でDocumentRootを
変更する必要があります。# cd /home/kusanagi/kusanagi_html/DocumentRoot # tar zcf ../kusanagi.tar.gz . # cd .. # mv DocumentRoot wp1 # mkdir -m 0777 -p DocumentRoot DocumentRoot/wp2 # chown -R kusanagi:kusanagi DocumentRoot # mv wp1 DocumentRoot/ # tar xf kusanagi.tar.gz -C DocumentRoot/wp2上記の手順では、DocumentRoot 以下に wp1 と wp2 ディレクトリを作成しています。
プロファイル以下に直接作成してもいいですが、DocumentRootを変更する必要がありますし、
logディレクトリが同じディレクトリにあるので外部からアクセス可能になってしまうので
おすすめしません。この手順では、DBを一つしか作成していないので、別途DBを作成するか、WordPressの設定で
テーブルのプレフィクスを変更する必要があります。
また、NGINXの設定を変更しないと、wp-admin のアクセス制限がデフォルトと異なることになるので
適宜修正が必要になります。kusanagi では、wp-config.php が、DocumentRoot直下もしくはDocumentRootと同じディレクトリにあることを想定していて、それ以外の場所にある場合はコマンド実行に失敗します。
ですので、DocumentRoot/wp/wp-config.php を DocumentRootに移動するか、
以下のようにhard link を貼っていただければと思います。# cd DocumentRoot # ln wp/wp-config.php .表示上の都合かもしれませんが、貼り付けていただいた部分の「’」の文字がいわゆる半角文字になっていないようです。
念のため、実機で半角文字になっていることをご確認ください。od コマンドで確認すると、以下のように表示されるはずです。「'」の上の数字が27になっていない場合、
半角文字ではないことが考えられます。
その場合、vi コマンドなどで、「'」の部分を手動で置き換えてください。> grep WP_CACHE /home/kusanagi/プロファイル/DocumentRoot/wp-config.php | od -tx1 -c 0000000 23 64 65 66 69 6e 65 28 27 57 50 5f 43 41 43 48 # d e f i n e ( ' W P _ C A C H 0000020 45 27 2c 20 74 72 75 65 29 3b 0a E ' , t r u e ) ; \n横から失礼します。
以下のコマンドの結果を教えてください。grep WP_CACHE /home/kusanagi/プロファイル/DocumentRoot/wp-config.php
初期状態では以下のようになるのが正常です。
> grep WP_CACHE /home/kusanagi/プロファイル/DocumentRoot/wp-config.php #define('WP_CACHE', true);bcacheの使用時には以下のようになるはずです。
kusanagi bcache onの例）
> kusanagi bcache on onにします。 完了しました。 > kusanagi bcache bcache は有効です 完了しました。 > grep WP_CACHE /home/kusanagi/プロファイル/DocumentRoot/wp-config.php define('WP_CACHE', true);kusanagi bcache off の例)
> kusanagi bcache off offにします。 完了しました。 > kusanagi bcache bcache は無効です 完了しました。 > grep WP_CACHE /home/kusanagi/プロファイル/DocumentRoot/wp-config.php #define('WP_CACHE', true);
