kenfm0411
Forum Replies Created
-
Posts
-
hideishiさん
ご教示ありがとうございました。おかげさまで、管理画面から本体更新ができるようになりました。
KUSANAGI Pluginを1.4.11に更新した上で、以下の2点も対処したところ、解決しました。
前回の更新失敗で残っていた更新ロック(core_updater.lock)が「別の更新が進行中」を出していたため、削除しました。これで、具体的なエラー「ファイルをコピーできませんでした:ja-xxxx.json」が表示されるようになりました。
そのエラーの原因は、wp-content/languages/内の一部の翻訳ファイル(ja-xxxx.json)が httpd所有になっており、更新時のコピーを妨げていたことでした。languages配下をkusanagi所有に統一したところ、管理画面からの本体更新(再インストール)が成功しました。
KUSANAGI Pluginの対策と、あわせてご案内いただいた「WP_Filesystem 関連」のお話が、解決の助けになりました。ありがとうございました。
hideishiさん
ご回答ありがとうございます。ご指摘の点を確認しました。
FTP設定は、以下の通り、正しく設定されておりました。
FTP_USERはkusanagi
FTP_PASSは有効な値(空でもコメントアウトでもない)
FTP_HOSTはlocalhost
PHPのftp_connect関数も使用可能しかし、それでもget_filesystem_method()はdirectを返し、管理画面からの本体更新は失敗します。
追加で確認したところ、
httpdユーザーは、本体ディレクトリ(ルート直下、wp-admin/、wp-includes/、いずれも kusanagi:kusanagiの755)に、書き込みできませんでした(touchで「許可がありません」)。
一方、wp-content/(kusanagi:www、setgid+グループ書き込み可)には、httpdで書き込みできました。そのため、プラグイン・テーマの更新は管理画面から成功します。
WP-CLI(kusanagiユーザー)からは、本体更新も成功します。FTP設定は有効なのにdirectが選択される、この状況で、本体更新をFTP経由(ftpext)で確実に実行させるには、どのような設定が必要でしょうか。
あるいは、KUSANAGI環境で本体を管理画面から更新するための、推奨の方法をご教示いただけますでしょうか。hideishiさん
ご丁寧な回答、ありがとうございます。おかげさまで解決いたしました。
naxsiが静的モジュールとしてコンパイル済みであることを理解しておらず、load_module がコメントアウトされているのを見て「無効」と誤解しておりました。紛らわしいコメントの件、とんでもないです。了解いたしました。
有効化の条件(kusanagi_naxsi_core.confおよびプロファイル.wp.incのinclude naxsi.d/... にコメントが無いこと)も確認でき、両方とも満たしておりました。
検知されなかった原因も、ご指摘の通りでした。
トップページへのテストクエリが、リダイレクトの際に欠落していたためでした。教えていただいた通り、DocumentRoot直下に <?phpのみのテスト用ファイルを作成し、そこにテストクエリを付けてアクセスしたところ、ssl_error.logにnaxsiの検知記録が出ることを確認できました。
当方のテスト方法とコメントの読み違いが原因でした。お手を煩わせてしまい申し訳ありませんでした。
丁寧にご教示いただき、大変助かりました。ありがとうございました。hideishi さん
ご回答ありがとうございます。おかげさまで解決しました。
ご指摘の通り、/etc/systemd/system/multi-user.target.wants/ に、実体のない nginx@with_httpd.service へのシンボリックリンク(2024年6月付)が残っていました。
nginx@with_httpd.service -> /usr/lib/systemd/system/nginx@.service
これを削除して systemctl daemon-reload したところ、kusanagi status の誤認も解消し、kusanagi restart も正常に完了するようになりました(restart completed.)。
過去のバージョンアップ時などに残ったものと思われます。的確なご対応、ありがとうございました。
横から失礼します。同じ「kusanagi restartに失敗する」ですが、症状が異なるようなので共有します。
■環境
KUSANAGI 9.10.1-1.el9
ConoHa VPS / CentOS Stream 9
nginx131 単独構成(httpd は未使用)■症状:restart だけでなく status でも失敗します
kusanagi status を実行すると、httpd併用構成のサービスを参照して失敗します。
$ kusanagi status
KUSANAGI Version 9.10.1-1.el9
conoha
CentOS Stream 9kusanagi status: error: 'systemctl status nginx@with_httpd.service' returned 4
kusanagi restart も同様に失敗します。
Failed to stop nginx@with_httpd.service: Unit nginx@with_httpd.service not loaded.
kusanagi restart: error: 'systemctl stop nginx@with_httpd.service' returned 5restart は設定ファイルとして nginx-with_httpd.conf も参照しようとします。
kusanagi restart: error: '/opt/kusanagi/nginx/sbin/nginx -t -c /etc/opt/kusanagi/nginx/nginx-with_httpd.conf' returned 2
■実態は nginx 単独構成です
一方で、以下の通り nginx 単独で正常に動作しています。
$ kusanagi nginx --showpath
/opt/kusanagi/nginx131/sbin/nginx$ systemctl is-active nginx131 httpd
active
inactive$ systemctl is-enabled nginx131 httpd
enabled
disabledhttpd は inactive かつ disabled で未使用、nginx131 が単独で稼働しており、サイトも正常表示されています。実際に使われている設定も nginx.conf(単独用)です。
それにもかかわらず、KUSANAGI は「httpd併用(with_httpd)」構成だと認識しているようで、status も restart も、存在しない nginx@with_httpd.service / nginx-with_httpd.conf を参照して失敗します。restart 単体の問題ではなく、構成判定そのものが誤っているように見えます。
■お伺いしたいこと
nginx 単独構成として正しく認識させるには、どの設定を確認・修正すればよいでしょうか。KUSANAGI が構成(単独/httpd併用)をどこで判定しているかがわかれば、そこを確認したいと考えています。
横レスで申し訳ありませんが、ご教示いただければ幸いです。
