cloudy
Forum Replies Created
-
Posts
-
momo さん、こんにちは。
トップページにも書かれている通り kusanagi status の結果をいただけませんか？
—
> コンソールよりコマンドkusanagi php8でphp8に切替えると以下のようなエラーになり、
とかかれていますが、私が見る限りエラーは特に見当たらないようです。
貼り付けてある内容は、PHP8に正常に切り替わったときに表示される内容です。> wordpressブラウザでも「重大なエラー…」と不能になります。
WordPress 側のテーマやプラグインの一部が PHP8 に対応できていない可能性ではないのでしょうか？
いずれにしても問題の切り分けができないので、まず kusanagi status の情報を教えて下さい。momo さん、こんにちは。
まずはトップページに書かれていることをお読みください。
> 同じトピックにコメントをしてヘルプを求めることはしないでください。
とありますので、このトピックに書くのではなく、新しいトピックを作成してください。
また、情報はできる限り詳細に記載してください。
・kusanagi status などの情報
・作業コマンドと結果、作業後に再起動したのかなどの追加情報tabakazu さん、こんにちは。
kusanagi-docker provision –fqdn sample.info {target}
target が漏れているのではないでしょうか
> provision
> provisionサブコマンドでは、末尾に指定したtarget名のディレクトリをカレントディレクトリ以下に作成し、KUSANAGI RoDの環境を作成します。masahiro さん、こんにちは。
情報ありがとうございます。こちらでも同様の事象を確認いたしました。
とりいそぎ本日リリースした、下記のモジュールを更新情報をお試しいただけないでしょうか。KUSANAGI 9モジュール更新情報
uppie123 さん、こんにちは。
Apache での検証は問題ないということでしたので、Nginx 設定で間違いなさそうですね。
KUSANAGI 9 での Nginx conf の場所です。
kusanagi provision で作成したプロファイル名を sample として説明します。sample プロファイルを WordPress でプロビジョンした場合、下記の設定ファイルが主に関係してきます。
/etc/opt/kusanagi/nginx/conf.d/sample.conf
/etc/opt/kusanagi/nginx/conf.d/sample.wp.incこの中で WordPress の設定を変更するのであれば、sample.wp.inc のファイルです。
ただ、指摘のあった内容はすでに sample.wp.inc に書かれているはずです。location / {
try_files $uri $uri/ /index.php?$args;
}ですので、原因の予想がそもそもはずれていると思われます。
uppie123 さん、こんにちは。
> kusanagi9 の場合、該当のフォルダが見当たりません。
> 上記内容で対応できる場合、該当ファイルはどこにござますでしょうか。これは、具体的に記事のどの部分のことを指していますでしょうか？
記事内容から引用していただけますでしょうか？
質問者と回答者の間に齟齬がなくなり、どのファイルの何を問題にしているのか確認しやすくなると思います。また、移設前が Apache で 移設後が Nginx ということですが、KUSANAGI 9 側に移設後にまず Apache で動作確認されましたでしょうか？
要は、Apache でそのまま移設したらすんなり動くけど、Nginx 設定に移植すると動かないのかを確認したいです。matsubarah さん、こんにちは。
まずはトップページに書かれている事項をお読みください。
（kusanagi status の情報を添付してください。）また、下記のトピックが参考になるかもしれません。
s@aivec さん、こんにちは。
URL パラメータを見る限り、使用しているプラグインに Welcart があるように見えます。
こちらはショッピングカート機能があるものではないでしょうか？ショッピングカート機能があるサイトでのキャッシュ使用は推奨されておりません。
agent さん、こんにちは。
KUSANAGI Marketplace につきましては、こちらでは回答できませんのでご了承ください。
上記の内容が含まれていたため、回答にお時間を頂戴しました。> 検証サイトの構築は「KUSANAGI 9 for Microsoft Azure」で行いましたが、これを「KUSANAGI 9 for Microsoft Azure Business Edition」に切り替えるには、新規に仮想マシンを構築し直すしかありませんでしょうか。
「KUSANAGI 9 for Microsoft Azure」を「KUSANAGI 9 for Microsoft Azure Business Edition」
に切り替える場合には、新たに仮想マシンを構築していただく必要がございます。プロファイルを移行できるコマンドがございますので、こちらで対応いただければと思います。
s@aivec さん、こんにちは。
2点ご確認です。
1. プラグインの設定箇所とキャッシュの種類
KUSANAGI専用プラグイン
ページキャッシュの設定
2.キャッシュ除外URLこの部分の話をしているということで間違いないでしょうか？
つまり、bcache の話で間違いないでしょうか？2. パラメータ
> パラメータしかないURLを設定する場合
パラメータしかないURL というものがよくわかりませんでした。
通常、URL にパラメータしか無いものはありえません。具体的にどういったものでしょうか？
また、ご自身で試した設定内容の記載も併せてお願いします。kait111 さん、こんにちは。
情報ありがとうございます。
KUSANAGI Version 8.4.6-2
*** (active) Apache2 ***
● httpd.service – The Apache HTTP Server*** (active) php7-fpm ***
● php7-fpm.service – The PHP FastCGI Process Manager*** (active) MariaDB ***
● mariadb.service – MariaDB 10.1.48 database serverkusanagi-php7.noarch 7.4.33-1
ということは、ざっと次のような環境ですね。
- KUSANAGI 8: 8.4.6-2
- Apache 2.4
- PHP 7.4
- MariaDB 10.1
KUSANAGI 8 含めすべてバージョンが古いので、今回アップデートするには多数の変更点が含まれます。
バージョン差分が大きいので、個人的にはバージョンアップを積極的に行うのはあまりしたくないというのが本音です。
なぜなら、これから KUSANAGI 9 の最新版に移行するので実質バージョンアップすることになり、現在の環境はバージョンアップで問題が発生することを起こしたくないためです。作業工数が一番少ないのは
kusanagi migrateコマンドなのですが、これはあくまでミドルウェアが揃えられる前提での話です。
ミドルウェアを揃えるための作業工数のほうがかかると思います。
他の方法でも問題はありません。工数としてはどの手法でもあまり変わりませんので、手慣れている方法で良いと思います。—
KUSANAGI 8 のバージョンアップのポイントです。
KUSANAGI 8 の更新をバージョンアップする場合には MariaDB 10.1 が原因でバージョンアップに失敗するでしょう。
バージョンアップする場合は FAQ を確認の上でバージョンアップしてください。
KUSANAGI 9 に移行した後は、定期的にアップデートしてください。ここからミドルウェアを揃える方法です。
MariaDB のミドルウェアを揃えるには、KUSANAGI 8 側で MariaDB 10.5 にアップグレードする必要があります。
KUSANAGI 9 の MariaDB は基本が 10.5 だからで、10.1 はそもそもサポート切れのためです。
ですが、MariaDB をアップデートで問題が発生した場合にロールバックするのは手間がかかります。
ただ単に DB ダンプを取得して KUSANAGI 9 に持っていって確認する方法をまず試してみるのも良いかもしれません。PHP のミドルウェアは、KUSANAGI 9 でも PHP 7.4 に切替可能なので、一旦そのままソースを持っていって PHP 7.4 環境で動作確認後、本来の目的である PHP のバージョンアップを行って動作確認することをお勧めします。
—
安定的な移行をするには、現在のサーバーを稼働したまま移行（マイグレーション）しつつ、移行先でPHP8系の動作確認を行うのが良いと思います。
上記の注意点を考慮し、まずは移行した KUSANAGI 9 環境で、現在の KUSANAGI 8 環境と同じ状態で動作確認を行ってください。(MariaDB 10.1 はサポート切れの為除く)
その後で、1つずつステップに分けて動作確認を行ったあとでバージョンアップを行ってください。
前バージョンをいきなりアップデートしてしまうと、問題になった原因がわからなくなります。kait111 さん、こんにちは。
kusanagi8から9へのバージョンアップはコマンド等では不可で、AWS AMIマーケットプレイスから新規にkusanagi9を構築する流れとなるのでしょうか。
はい、そのとおりです。
新規サーバー立ち上げ後の移行に関してもツール等はなくSFTPやwordpressプラグインなどで実施するのが一般的なのでしょうか。
KUSANAGI 8.6.6-1 以降であれば
kusanagi migrateコマンドがご利用いただけます。
ただし、事前にミドルウェアのバージョンを揃えておいたほうが良いと思われます。
トップページに記載の通り、まずは各種情報（特に kusanagi status）の情報をいただけますか？—–
KUSANAGI 8 – kusanagi migrate コマンドでエクスポート
kusanagi migrate –export profilekusanagi migrate コマンドは KUSANAGI 8.6.6-1 以降で使用可能
KUSANAGI 9 – kusanagi migrate コマンドでインポート
kusanagi migrate –import kusanagi_html-yyyy-mm-dd.tar.gzajpamji さん、こんにちは。
Mroonga 側のリリースの問題かもしれません。
お知らせを確認すると MariaDB 10.5.17 の対応は書かれていますが、 MariaDB 10.5.18 については書かれていません。Mroonga お知らせ
https://mroonga.org/ja/docs/news.htmlMroonga 側に確認の上で、mariadb を 10.5.17 にダウングレードするか、mroonga のアップデートを待つか、どちらかの対応をお願いします。
