hideishi
Forum Replies Created
-
Posts
-
hirasawa3さん
フィードバックありがとうございます。
複数のプロファイルを同一サーバで運用している環境で同じような問題に直面していますので、ご意見もっともだと思います。再起動がprofileで共通になっていることには理由があります。
「別のprofile」が原因でアクセス不能になっていることもあるからです。
例えば、「別のprofile」がphp-fpmがリソース食い潰す、MariaDBのセッションをロックしている、httpd/nginxのコネクションを使い切ったことで「今のprofile」がアクセス不能になっている場合には、全体をrestartする以外に解消する手段がないためです。提案のように、kusanagi restartに制限を設けることも検討しました。しかし、lockによる不具合の危険性を完全に回避できないことから見送りになっています。(9.10.4で対応した問題です)
細かくmonitをカスタマイズすれば実現できるかもしれませんが、正直monitの運用の限界だと感じています。申し訳ないのですが、設定を調整するか、offにしてみてください。
また、そもそも最初に499/5xxが発生した原因をつぶすことが根本的な解決になります。
error.logから何が原因で最初の5xxが起きたのかを確認することはいかがでしょうか。なお、Security Editionではmonitに依存しないように、KUSANAGI自身でログを監視する仕組みを入れています。
hirasawa3さん
monitの設定は標準的な設定として用意しているもので、
環境によっては負荷が集中するとmonitが多重検知することはあるかもしれません。
必要に応じてカスタマイズしてみてください。例えば、頻発するようであれば
for 5 cycles then restartを 10 や 20 のように増やしてみてください。
またif 5 restarts within 5 cycles then unmonitorは5回連続してrestartをかけるとmonit監視をやめるようにしています。
これは逆に 3 restarts のように数を減らすとmonit監視を早く止める (=restartが早く止まる) ことができます。
変更した後は kusanagi monit reload で読み込み直してください。設定ファイルに加えた変更は kusanagi monit config を実行するとデフォルトに戻ります。
それでも解決できない場合は kusanagi monit off でmonitを無効にしてみてください。
hirasawa3さん
再現確認できました。
確かに %{HTTPS} は実際にsslで接続されないと設定されないようですね。短期的な回避策としては /etc/opt/kusanagi/httpd/conf.d/PROFILE.conf の中にある RewriteEngine On を Off にしてください。
/etc/opt/kusanagi/httpd/conf.with_nginx.d/PROFILE.conf は上記を雛形に生成するので、上記がOffなら自動的にOffになります。
おそらく元はOffだったものが https redirect などを設定してOnに変わったのではないでしょうか。
9.10.0以降では雛形から設定の変更を自動反映するようになりましが。
その結果、変更を拾ってしまって On になったのだと考えられます。RewrireRuleのリダイレクト処理自体がApache:8000側にそもそも不要なので、自動反映する際に該当ディレクティブを削除するように修正します。
報告ありがとうございました。hirasawa3さん
/etc/opt/kusanagi/httpd/httpd-with_nginx.conf に以下の記述があるかを確認いただけますか
SetEnvIf X-Forwarded-Proto "^https$" HTTPS
httpd-behind-nginxの場合にはproxyがX-Forwarded-Protoをnginx側で設定します。
そのため、この条件に従ってnginxにHTTPSでアクセスがあったものはHTTPSが設定されます。
HTTPSが設定されていればhttpd側のご指摘のrewriteルールは RewriteCond %{HTTPS} off が成立しないので
通らないようになっています。kenfm0411さん
一部のWordPressプラグインが正しくWP_Filesystemを実装していないためにdirectになってしまうケースがあります。
KUSANAGI Pluginでそのような現象を回避するための対策を入れているので、KUSANAGI Pluginが最新になっているかどうか確認できますか。現在の最新は 1.4.11 です。
kusanagi pluginの更新は KUSANAGI が最新であれば kusanagi update plugin プロファイル名 で更新できます。
KUSANAGI が最新でない場合は dnf update kusanagi-wp-plugins でプラグインのRPMを更新した後で kusanagi update plugin プロファイル名 で更新してください。それでも解決しない場合には、先のとおりWP_Filesystemを正しく実装していないプラグインが何か存在する可能性が高いです。
1つずつプラグインを無効にしていくなどして調べるしかなさそうです。kenfm0411さん
KUSANAGIはhttpdによる更新をセキュリティ上許可していないのは認識の通りです。
get_filesystem_method() がdirectを返しており、FS_METHOD='ftpext'の指定が反映されていないようです。
wp-config.phpにFTP_HOST,FTP_USER,FTP_PASSは設定されていますか。
FTP_USERがkusanagiであればkusanagi:kusanagiを更新できるのでエラーになりません。
これらが空やコメントアウト、無効な値であればFS_METHOD ftpextが動作せず、directにフォールバックします。katsunakatamisaさん
状況がよく分からないので
kusanagi status プロファイル名や kusanagi -V の結果を貼ってもらえますか。まず
kusanagi ssl --email メールアドレス サイトアドレス
ここはサイトアドレスではありません。プロファイル名です。
もしかするとプロファイル名をサイトアドレスと同一にしているのかもしれません。
まず、プロファイル名がプロビジョンした際に--fqdnオプションで指定したFQDN名と同一かどうか確認できますか。kusanagi show プロファイル名の fqdn に表示されるものがプロビジョンした際に指定したFQDN名です。どこかでFQDN名が katsunakatamisaさん が想定していたものとずれているのかもしれません。
FQDN名を直したい場合は
kusanagi configure --fqdn 新しいFQDN名 プロファイル名で変更できます。詳細はドキュメントを参照してください。
なお、wwwありとwwwなしのFQDNを両方有効にしている場合は、表示が一致しない場合があるので気を付けてください。
katsunakatamisaさん
KUSANAGIプラグインが負荷軽減のために一定時間(60分)キャッシュを保持しているためです。
kusanagi update plugin の結果が即時反映されません。
60分後くらいにメッセージが残っているか再度確認していただけますか。今後、アップデート結果が即時反映されるように改善します。
kenfm0411さん
kusanagiのnginxはnaxsiを静的モジュールとしてコンパイル済です。
nginx.confのload_moduleはコメントアウトする必要はありません。
また /opt/kusanagi/nginx131/lib64/modules/ngx_http_naxsi_module.so も存在しません。
歴史的経緯から、まぎらわしい設定コメントが残っていてすみません。
なお、ドキュメントにある「初回の関連パッケージのインストール」はhttpdの場合に発生します。
nginxは上記の通り同梱なので発生しません。/etc/opt/kusanagi/nginx/conf.d/kusanagi_naxsi_core.confにコメントがなく
/etc/opt/kusanagi/nginx/conf.d/プロファイル.wp.incのinclude naxsi.d/...にコメントがなければ
有効化されています。naxsiはWordPressやPHPを通る処理にのみ設定しているので、URLやリクエストの内容によっては通らないことが考えられます。
URLがPHPファイルのパスであるか確認いただけますか。
WordPressの場合 / などのURLへのアクセスを別のURLにリダイレクトし、その際にクエリストリングが欠落することがあります。curl -i -L 不正なクエリのURLのようにHTTPヘッダを表示しつつ、リダイレクトを追うようにすると確認しやすいです。または DocumentRoot 直下に
<?phpのみの hoge.php を作って hoge.php にテストクエリを付加してみてください。kenfm0411さん
同様の原因と思われます。
存在しない nginx@ あるいは httpd@ のシンボリックリンクが残っている可能性があります。
ls -l /etc/systemd/system/multi-user.target.wants/nginx*.service
ls -l /etc/systemd/system/multi-user.target.wants/httpd*.service
リンク切れのものを削除して systemctl daemon-reload で解消します。こちらも先の修正と合わせて対応します。
