hideishi
Forum Replies Created
-
Posts
-
ichiさん
ご指摘ありがとうございます。
kusanagi-python312-pyOpenSSL-26.2.0-1 の依存関係の指定が誤っていました。
修正した kusanagi-python312-pyOpenSSL-26.2.0-2 をリリースしましたので、再度dnf upgradeで確認ください。エラーが再度出る場合はdnfのキャッシュが残っている場合もありますので、
dnf upgrade --refreshをお試しください。saltyorangeさん
バグの報告ありがとうございます。
kusanagi-wp-plugins 20260511-1 にて対応しました。
https://kusanagi.tokyo/releases/24518/WordPressの管理画面よりKUSANAGI Pluginのメニューを選択し、「ページキャッシュ」から「advanced-cache.phpの再生成」をクリックしてadvanced-cache.phpを再生成してください。
なお、エラー等でWordPress管理画面にログインできない場合には、先に wp-content/advanced-cache.php を削除してからログインください。
terakin様
ご迷惑をおかけします。
ただ今、OpenSSL 3.5およびそれに依存するRPMの更新作業をしているところです。
Nginxのリリースを行っている最中ですので、しばらく後に再度dnf upgradeを試していただけますでしょうか。
dnfはRPMの情報をキャッシュしている場合がありますので、その場合は dnf upgrade --refresh を試してください。
アップデートに関しては https://kusanagi.tokyo/releases/ を確認ください。なお、nginx 1.25をお使いの場合はKUSANAGIのサポート対象外となります。
https://kusanagi.tokyo/releases/18715/nicoさん、こんにちは。
KUSANAGI専用プラグインのテーマアクセラレータを無効にしてみてください。
KUSANAGI専用プラグインについてはドキュメントを参照してください。
https://kusanagi.tokyo/document/kusanagi-plugin/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モジュールを有効化する件について検討します。対応時期はまだ明言できませんが、決定した際はこちらでもアナウンスします。
murodon さん
修正版をリリースしました。ご確認ください。
https://kusanagi.tokyo/releases/19410/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 onyoshichiさん
上記の /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配下に移動させることで動作しないものがあることを留意してください。
