hideishi
Forum Replies Created
-
AuthorPosts
-
hiroさん
AWSをお使いのこと以外には何も情報がないので詳細は分かりかねますが、
まずはAWSのコンソール等からサーバーを再起動してみてはどうでしょうか。その上でSSHで接続可能か確認し、またログイン後に kusanagi status 等で nginx が実行できているか確認してみてください。
katsunakatamisaさん
情報が少なすぎて何もアドバイスできそうにありません。
の「できるだけ多くの情報を含める」にあるように、できるだけお使いのKUSANAGIの環境の情報を収集してください。
また dnf -y update の出力結果全文も参考になるかもしれません。pandora25さん
ご指摘のとおり、kusanagi phpではphp.iniとwww.confの特定のパラメータをインスタンスのCPU/メモリ等の値に応じて自動的に変更します。
おそらく変更されたwww.confのパラメタは request_terminate_timeout ではないでしょうか。どうしても別の値で運用したい場合にはwww.confをコピーしてwww.confよりもアルファベット順で後に来るファイル名 (例えば z-www.conf) を作成し、その中の request_terminate_timeout を変更してください。
なお、php.iniやwww.confはKUSANAGIのdnf update等で更新することがあります。
これは不具合の対応や性能改善の目的でデフォルトのパラメータを変更することがあるためです。以下は10-opcache.iniを変更したケースです。
https://kusanagi.tokyo/releases/12453/上記のようにwww.confをコピーした場合には、その変更が反映されませんのでご注意ください。
以下のPHPについてもGMPモジュールを有効化したものをリリースしました。
PHP 8.2.28-3
https://kusanagi.tokyo/releases/20144/PHP 8.1.32-3
https://kusanagi.tokyo/releases/20160/saltyorangesさん
最新のPHPの以下のバージョンにおいてGMPを有効化しましたので確認ください。
PHP 8.4.8-1
https://kusanagi.tokyo/releases/20119/PHP 8.3.22-1
https://kusanagi.tokyo/releases/20127/PHP 8.2 および 8.1 についても順次対応していきます。
saltyorangesさん
フィードバックありがとうございます。
PHPのコンパイル時にGMPモジュールを有効化する件について検討します。対応時期はまだ明言できませんが、決定した際はこちらでもアナウンスします。
2025年4月24日 at 14:07 in reply to: WordPress 6.8.0でFunction wp_is_block_theme was called incorrectly.が発生 #1538murodon さん
修正版をリリースしました。ご確認ください。
https://kusanagi.tokyo/releases/19410/2025年4月23日 at 08:57 in reply to: WordPress 6.8.0でFunction wp_is_block_theme was called incorrectly.が発生 #1537murodon さん
ご指摘ありがとうございます。
wp_is_block_theme()の呼び出しを修正しますので少々お待ちください。yoshichi さん
報告ありがとうございます。
確認したところ、KUSANAGIのリポジトリの不具合であることが分かりました。kusanagi-mod_security の代わりに kusanagi-httpd24-mod_security がインストールされているのが原因です。
リポジトリの不具合を解消しましたので、kusanagi-httpd24-mod_securityをアンインストールして、再度waf onを実行してみてください。dnf erase kusanagi-httpd24-mod_security
dnf makecache --refresh
kusanagi waf on
yoshichiさん
上記の /wp/ (KUSANAGI) は「WordPress」を意図していると仮定して回答します。
テクニカルな方法になりますが、以下で実現することができます。
あくまでも何をしているのかコマンド1つ1つ理解している場合のみに実行してください。1. まずWordPressをプロビジョンします。
kusanagi provision --wp --fqdn example.com (略) example.com
この際にWordPressのインストール(後述)は行わないでください。
インストールのための --adminuser/--adminpass/--adminemail 等のオプションも指定しないでください。/home/kusanagi/example.com/DocumentRoot の直下にWordPressがある状態になります。
2. 続いてWordPressをwpに移動します。
cd /home/kusanagi/example.com
mv DocumentRoot wp
mkdir DocumentRoot
mv wp DocumentRoot
/home/kusanagi/example.com/DocumentRoot/wp にWordPressがある状態になります。
3. WordPressをインストールします。
http://example.com/wp/ にアクセスしてWordPressの設定を完了させます。 (証明書ありならhttps)
4. 他の静的ページ用のフォルダを作成します。
以上で完了です。
なお、KUSANAGIはWordPressがDocumentRoot直下にあることを前提としているので、/wp配下に移動させることで動作しないものがあることを留意してください。
-
This reply was modified 3 months, 2 weeks ago by
hideishi.
kurisuさん
ご指摘ありがとうございます。ご迷惑おかけして申し訳ありません。
不具合を確認できましたので、早急に修正をリリースします。Genbuさん
kusanagi fcache clearコマンドの不具合でした。
KUSANAGI 9.5.3-1 をリリースして対応しましたので、アップデートの上で再度実行をお願いできますでしょうか。Castellowsさん
何らかの理由でkusanagi provisionした際に指定したdbname/dbuser/dbpassが消えてしまっているのだと思われます。
/etc/kusanagi.d/profile.confにプロファイル毎のdbname/dbnuser/dbpassがそれぞれKUSANAGI_DBNAME/KUSANAGI_DBUSER/KUSANAGI_DBPASSとして記録されています。
これらの値がexportしようとしている対象のプロファイルの現在のdbname/dbuser/dbpassと合っているか確認ください。mamemoyashiさん
KUSANAGIのFAQ
Q4. dnfでアップデートを実行すると、エラーが出力されてアップデートできません。
の回答
A4-4. 以下のようなメッセージが出力された場合、CentOS Stream 8がリポジトリから削除されたためです。
を参照してください。 -
This reply was modified 3 months, 2 weeks ago by
-
AuthorPosts