草薙 沙耶
Forum Replies Created
-
AuthorPosts
-
collne様
ご連絡ありがとうございます。
証明書を更新致しましたので、お手数をおかけいたしますが再度updateをお試し頂けますでしょうか。上記のエラー解消は最新版KUSANAGIに対応しました。
remi含むのアップデート実行前に
yum -y update kusanagi
を行ってください。- This reply was modified 4 years, 7 months ago by 草薙 沙耶.
ご報告ありがとうございます。
MariaDBのバージョンが10.1.30から10.1.31に上がっていた影響で、依存性の問題が発生しておりましたが、さきほどMroongaのパッケージをアップデートして頂きましたので、現在はインストールに成功することを確認しております。
下記のコマンドで再度お試し下さい。
# yum clean all
# yum updateご報告ありがとうございます。
当初、kusanagi removeで強制的に再起動させてしまうと、運用上問題があるケースが考えられましたので、再起動させないような仕様になっておりましたが、kusanagi remove実施の最後でWEBサーバの再起動を行うかどうか入力を行わせた上で実施する実装に変更させて頂きたいと思います。
ご報告ありがとうございます。
こちら確認後、修正パッケージをリリースさせて頂きます。
申し訳ございません。
現状私どもの方でも、kusanagi init時のMariaDBのアップグレード処理に問題があることは認識しており、現在パッケージを修正中です。
本日中にアップデートいたします。
とりいそぎ、下記のコマンドで正常にMariaDBがアップデートされるかと思いますので、お試し下さい。/etc/yum.repos.d/MariaDB.repoのファイルを確認。
baseurl = http://yum.mariadb.org/10.0/centos7-amd64
となっていた場合は、下記のように10.1に変更
baseurl = http://yum.mariadb.org/10.1/centos7-amd64yum clean all
yum install -y MariaDB-devel MariaDB-client MariaDB-server
/etc/my.cnf.d/server.cnf.rpmsaveファイルが出来ていた場合は
/etc/my.cnf.d/server.cnf.rpmsaveの[mysqld]中身を/etc/my.cnf.d/server.cnfの[mysqld]にコピーして下さい。最後のMariaDB再起動
systemctl restart mysql
ご迷惑をおかけしますが、よろしくお願い致します。
- This reply was modified 6 years, 9 months ago by 草薙 沙耶.
本日こちらを改善し、リリースを行いました。
ご指摘、ありがとうございます。
こちら、WEBの方が推奨の設定となっておりますのでKUSANAGIの方の改修を行わせて頂きます。
お世話になっております。
ご質問の内容についてご返答させて頂きます。WordPressをサブディレクトリで使用する場合、同一サーバ内であれば、通常は単純にドキュメントルート直下にsubというディレクトリを新たに作りそこにWordPressをインストールするという方法があります。
ただKUSANAGIの場合、プロビジョニングして管理していくという構造上上記の方法ではサブディレクトリ内のWordPressについては管理できなくなってしまいますので、このケースであれば下記のようにリバースプロキシの設定をするのが良いと思います。
# kusanagi provision main
についてはFQDNを通常通りwww.example.comとしてプロビジョニングして下さい。# kusanagi provision sub
については、プロビジョニング時に設定するFQDNを任意の名前、たとえばsub.example.comとします。2つのプロビジョニングの終了後、mainのnginxの設定ファイル(/etc/nginx/conf.d/main_http.conf)に下記のような項目を追加して下さい。場所はlocation/の下辺りにします。
location / { try_files $uri $uri/ /index.php?$args; } # 下記を追加 location ^~ /sub/ { proxy_pass http://localhost:8080/; proxy_set_header Host sub.example.com; proxy_http_version 1.1; }
続いて、subのnginxの設定ファイル(/etc/nginx/conf.d/sub_http.conf)のlistenの項目を80から8080に変更します。
server { listen 8080;
続いてsubのディレクトリにある/home/kusanagi/sub/DocumentRoot/wp-config-sample.php を/home/kusanagi/sub/wp-config.phpとして移動します。
移動させたら、wp-config.php内のデータベース名やデータベースのユーザー名などを手動で変更し、define(‘WP_DEBUG’, false);の下あたりに下記の2行を追記します。
/** * 開発者へ: WordPress デバッグモード * * この値を true にすると、開発中に注意 (notice) を表示します。 * テーマおよびプラグインの開発者には、その開発環境においてこの WP_DEBUG を使用することを強く推奨します。 */ define('WP_DEBUG', false); # 下記2行を追加 define('WP_HOME','http://www.example.com/sub'); define('WP_SITEURL','http://www.example.com/sub');
最後にnginxの再起動を行います。
# kusanagi nginxこれで
http://www.example.com/
http://www.example.com/sub/
を同じサーバのKUSANAGI上で運用することが可能となります。- This reply was modified 6 years, 11 months ago by 草薙 沙耶.
下記のコマンドを実行してから、再度アップデートしていただけますでしょうか?
yum clean all
-
AuthorPosts