cloudy
Forum Replies Created
-
AuthorPosts
-
collne さん、追記です。
kusanagi status
の実行結果を確認したところ、 MariaDB 10.1 系をご利用のようです。*** (active) MariaDB ***
● mariadb.service – MariaDB 10.1.48 database server
Loaded: loaded (/usr/lib/systemd/system/mariadb.service; enabled; vendor pres et: disabled)
Active: active (running) since 木 2022-08-11 17:07:19 JST; 17h agoこちらパッケージから削除されているので、
yum update
時に失敗するかもしれません。
失敗した場合、yum update
に--disablerepo=mariadb
を追加で指定することを試してみてください。詳しくは、下記のトピックを参考にしてください。
collne さん、こんにちは。
情報ありがとうございます。
KUSANAGI Version 8.7.5-2 ですね。結論からお答えします。
かんたんにロールバックする方法はなく、ロールバックはセキュリティ上でもおすすめいたしません。
今回、KUSANAGI 8 で使用される PHP 7.4 系にエラーが出ないよう先行対応をしていただきました。下記リリース文を参考に、バージョンアップ後にエラーが発生しないかご確認ください。
お願いになるのですが、バージョンアップ後に問題が発生しないことを確認したいので、実行前後のログをいただけると助かります。—
今回の件はご承知の通り、OpenSSL 1系と3系の通信時に互換性に起因するものです。
1系があいまいな実装や設定を受け入れていたものを 3系で厳格にした差により発生するものになります。
公式の PHP 8.1.7 以降で特別に OpenSSL 1系の動作を実行できるように変更したため、エラーが発生しなくなっております。
ただし、PHP 7.4.x / 8.0.x にはこの改修が含まれていないため SSL 通信時にエラーが発生していました。今回の本来の正しい解決方法は、サーバー側の OpenSSL を正しい設定に変更しエラーを無くすことです。
ただ現実問題として正しい解決方法を適用することが難しいところもあるかと思います。—
以下、私が確認に使用した実行結果ログです。
`
[root@kusanagi83 ~]# kusanagi -V
KUSANAGI Version 8.7.5-2
Done.
[root@kusanagi83 ~]# rpm -q kusanagi-php7
kusanagi-php7-7.4.30-3.noarch
[root@kusanagi83 ~]# php7 -r “echo file_get_contents(‘https://chromedriver.storage.googleapis.com/LATEST_RELEASE’, false, stream_context_create()), PHP_EOL;”
104.0.5112.79
`
なお、バージョンアップ前やバージョンアップに失敗している場合はは下記のエラーが含まれた結果が返ります。
`
[root@kusanagi83 ~]# php7 -r “echo file_get_contents(‘https://chromedriver.storage.googleapis.com/LATEST_RELEASE’, false, stream_context_create()), PHP_EOL;”
PHP Warning: file_get_contents(): SSL operation failed with code 1. OpenSSL Error messages:
error:0A000126:SSL routines::unexpected eof while reading in Command line code on line 1
PHP Warning: file_get_contents(): SSL: Success in Command line code on line 1
104.0.5112.79
`
collne さん、こんにちは。
前回私も書いたことですが、トップページにも記載の通り
kusanagi status
の結果はいただけませんか?
質問を見る限り必要だと判断して、改めて結果の提出をお願いしています。
結果が出せない理由がございましたら、その旨のご回答をいただきたいです。
また、他にも私が確認した内容に対して特に回答がないようです。
情報がなければ回答ができないケースもありますのでご了承ください。shingorow さん、こんにちは。
kusanagi status の情報をありがとうございます。
KUSANAGI Version 9.2.6-2.el8 で lnmp 環境ですね。> /home/kusanagi/{profile}/DocumentRoot does not exist or is not a directory
エラーに書いてあるとおり DocumentRoot がないもしくはディレクトリではないようですが、心当たりはありますでしょうか?
原則として kusanagi コマンドは、DocumentRoot がディレクトリとして存在することが前提です。
変更した場合の動作は保証されません。上記のメッセージは certbot コマンドが出力されているものと思われます。
kusanagi ssl --email
コマンドでは、DocumentRoot 配下に .well-known ディレクトリと認証用ファイルを設置し、Let’s Encrypt のサーバ側からアクセスして検証を行います。
よって、nginx で設定した docroot と DocumentRoot が一致しないと、認証に失敗し SSL の設定ができません。
また、単純に DocumentRoot の空ディレクトリを復旧させたとしても、SSL の設定は失敗すると思われます。そのうえで更新を試したい場合、laravel の public を DocumentRoot のシンボリックリンクに設定するなどの手段を考えた上で、nginx や let’s encrypt 設定ファイルの手当を行うなど試してみてください。
上記にも記載したとおりディレクトリ構成を変更し各種設定を手動で変更されている場合、動作は保証されませんので案くらいしかお伝えできませんがご了承ください。torinokawa さん、こんにちは。
補足です。
KUSANAGI インストール直後は、kusanagi init の実行が必要です。
init の質問をされていますが、init の実行をしたと書かれているコマンドは kusanagi provision です。> $ kusanagi provision dev.***** –wp –fqdn dev.*****.jp –dbname dev.***** –dbuser dev.***** –dbpass dev.*****AA –email *****@*****.co.jp
もしかしたら kusanagi init を実行していないのかもしれません。
ご確認ください。e2info_yama さん、こんにちは。
トップページに記載の通り、投稿内容に URL が多数あるとスパム判定されますので、投稿内容に含める URL は最大でも 3 つまでにしてください。
今回は下記も URL と判定されますので、URL が 4 つ含まれていました。> https://[サイトドメイン]/wp-admin/index.php
改めてご質問の件ですが、wp-config.php が原因だと判断されている理由はなんでしょうか?
まず、表示されている警告の内容は理解されていますでしょうか?
私が読む限り、表示されているファイルやディレクトリの書き込み権限がないようにみえるのですが。。。こちらを解決することが本質なのではないでしょうか?
警告で表示されているファイルやディレクトリの問題ではなく、wp-config.php ファイルのみが原因だと判断された理由がよく分かりませんでした。> wp-config.phpファイルをドキュメントルートと同じ階層に移動していないと、KUSANAGIが正しく動作しなかったり自動更新ができなかったり、権限が想定通りに設定できなかったりしますでしょうか。
> ダッシュボードを確認するとKUSANAGIによるセキュリティ状況が表示されるという記事も見かけたのですが、弊社のサイトではセキュリティ状況も表示されていないのですが、wp-config.phpファイルの配置位置と関係がありますでしょうか。
これら、wp-config.php 設置場所のみでは関係ありません。
● 初期設置場所: /home/kusanagi/(プロファイル名)/DocumentRoot/wp-config.php
● セキュリティ推奨設置場所: /home/kusanagi/(プロファイル名)/wp-config.phpHtoyoda さん、こんにちは。
KUSANAGI manager ですが、こちらは ConoHa さんで作られているツールになります。
お手数をおかけしますが、今回のご質問は ConoHa さんの方へお問い合わせください。ご回答できず恐縮ではありますが、どうぞよろしくお願いいたします。
Yutori さん、こんにちは。
上記でアップデートがエラーになるのでしたら、まずは kusanagi モジュールだけアップデートを試していただいてもよろしいでしょうか?
yum clean all
yum update kusanagi –disablerepo=mariadbこれでエラーが出なければ、残りのモジュールも通常のアップデートを試してみてください。
yum update –enablerepo=remi,remi-php56 –disablerepo=mariadb
yum update –enablerepo=remi,remi-php56- This reply was modified 2 years, 5 months ago by cloudy.
yutori さん、追記です。
今回の目的は PHP 8 系を使用したいということですが、タイトルやタグが MariaDB に関する内容であったため、上記回答にとどめております。
—
MariaDB 10.1 は FAQ にも記載がある通り、出来うる限り 10.3 以上へアップデートおすすめしています。
ただし、MariaDB の最新リリースでは EOL の取り扱い方が変わっているのでご注意ください。https://mariadb.com/newsroom/press-releases/mariadb-announces-new-innovation-release-model/
* MariaDB 10.6 以前: リリースから 5 年のサポート期間
* MariaDB 10.7 以降: リリースバージョンによりサポート期間が 1 年もしくは 5 年MariaDB 10.8 / 10.7 などは最新のように見えますが、LTS ではないためサポート期間が 1 年しかなくサポート終了が早いためおすすめしません。
現在、LTS (長期サポート) されている MariaDB バージョンは 10.6 / 10.5 / 10.4 / 10.3 となっています。
特にこだわりがないようでしたら、KUSANAGI 8 最新版で初期設定の MariaDB 10.5 をご利用になると良いと思います。
※この情報は、この回答を参考にされる他の方の記録としても残しておきます。MariaDB バージョンごとの EOL
https://mariadb.com/kb/en/mariadb-server-release-dates/yutori さん、こんにちは。
kusanagi status の情報をありがとうございます。
KUSANAGI 8 Version 8.4.3-2 ですね。
複数問題があるようなので、分けて考えていただければと思います。
それぞれ解説します。1. kusanagi upgrade mariadb 10.5 コマンド
こちらは KUSANAGI 8.6.0-1 以上で使用可能なコマンドです。
ご使用の KUSANAGI 8 のバージョンは 8.4.3-2 なので、そもそも正常に実行できていない恐れがあります。2. KUSANAGI 8 最新版にアップデート
1.の理由により KUSANAGI 8 自体のバージョンが古いことが問題です。
トップページにも記載がある通り、KUSANAGI 8 最新版にアップデートすると問題が解決することがあります。yum update kusanagi
yum update –enablerepo=remi,remi-php56今回のコマンド実行できなかったケースは、まさに上記に該当します。
バージョンアップを行う前には、必ずバックアップを取っておいてください。
また、パッケージのバージョンアップ後はサーバーの再起動をしてください。3. KUSANAGI 8 最新版にアップデートに失敗する
2.の作業で失敗した場合です。
私の予想ですが、2.は失敗するのではないでしょうか?
そして、今回の問題はこの項目が解決できればすべて解決するでしょう。エラーを読む限り、MariaDB 10.1 のパッケージがないために起こっている状況です。
こういうケースでは、一時的にエラーを起こしているパッケージを無視するとうまくいく場合があります。FAQ に記載がある通り、エラーを起こしているパッケージを無視させるには
--disablerepo
を使用します。
FAQ では別パッケージの例が出ていますが、原理は同じです。yum clean all
yum update –disablerepo=mariadbKUSANAGI 8 FAQ – Q5. yum のアップデートを実行すると、エラーが出力されてアップデートできません。
以下のコマンドのとおり、 yum アップデート時に認証に失敗するリポジトリを対象外指定をして〜 の部分エラーで実行できなかった場合は、理由はエラーメッセージに書かれているとおりなので、そのエラーのモジュールを一時的に –disablerepo に追加します。
上記のアップデートが上手く実行できた場合は、2.に戻って改めてパッケージ類をアップデートしてください。こちらのエラーの原因は FAQ でも書かれている通り、KUSANAGI ベースイメージの CentOS 側で MariaDB 10.1 のサポートが完全に終了しているため表示されるものです。
KUSANAGI 8 自体のバージョンアップがこまめにされていないようですので、今回のアップデート時に大きな差分ができ発生したと思われます。
こまめなアップデートを推奨します。4. MariaDB 10.5 への移行
3.まで完了すると kusanagi upgrade mariadb 10.5 コマンドが使用できると思います。
バージョンアップを行う前には、必ずバックアップを取っておいてください。MariaDB のバージョンアップ後はサーバーの再起動をしてください。
質問には記載はありませんでしたので、もしかしたら作業漏れているのかも?と思っています。以上、ご確認ください。
Byron さん、こんにちは。
トップページにも記載がありますが、質問の際にはご自身の環境をできるだけ記載ください。
できる範囲で構いませんが、こちらの情報がないと、回答いただけない場合があります。- kusanagi status の結果
- テーマ
- プラグイン`
- 実際のページのURL
- ソースコードの一部
- 他、関連する情報
今回の内容は憶測ですが、ECサイトのページにキャッシュを使用しているのではないでしょうか?
そもそも、ECサイトでキャッシュを使うことは非推奨です。- This reply was modified 2 years, 6 months ago by cloudy.
ramen_umai 様
ご指摘ありがとうございます。
今回の件、ramen_umai 様のご指摘どおりで間違いございません。ramen_umai 様にはご不快な印象を与えてしまいまして、大変申し訳なく思っております。
お時間を頂いたうえでご指摘いただき、誠にありがとうございました。> KUSANAGI9の方ではdefine(‘FS_METHOD’, ‘ftpext’);を記載するような指示が以前から存在しましたが、
> KUSANAGI8の方には未だにKUSANAGI8 新着記事の中にも記載はありません。こちらのご指摘ですが、私の方でも改めまして全投稿を確認致しました。
ご指摘頂いた通り、この件に言及した記事は見つかりませんでした。
関係部署に改善するよう私から連絡しておきます。今後とも KUSANAGI をご愛顧いただけますよう改善していきますので、ご指導・ご鞭撻のほどどうぞよろしくお願い致します。
M.T. 様
今回のご質問の経緯につきまして、私の方からご報告です。
ramen_umai 様のご指摘どおりで間違いございません。質問の内容に関しまして、私が対応策をお伝えし回答をお願いいたしました。
また、今後同様の問題が発生しそうと感じましたので、別の担当者に FAQ への追加もお願いいたしました。改めて回答内容を確認すると、以前より FAQ に書いてあったかのような印象を受けてしまう回答になっています。
回答の書き方に問題がありました。
M.T. 様が見落としていたので決してございません。
ご不快な思いをさせてしまい、大変申し訳ございませんでした。今後同様の事象が発生しないよう、質問の返答に関しては当面の間、返答内容を私が必ず確認の上で回答いたしたいと思います。
今回の M.T. 様にご質問いただいたことをきっかけに、FAQ をまた 1 つ充実させることができました。
誠にありがとうございました。今後とも KUSANAGI をどうぞよろしくお願い致します。
Dunford さん
こんにちは。私の KUSANAGI 8 FE Vagrant 環境では utf8mb4 になっていました。
そこでご確認です。- KUSANAGIのバージョンやエディションは何でしょうか?
- サーバーの環境はどこでしょうか?
フロントページにもある通り、
kusanagi status
の結果を貼り付けていただけると確認が取りやすいです。また、どの段階で確認して utf8mb4 になっていたのでしょうか?
kusanagi init 直後ですか? kusanagi provision 直後ですか? その他ですか?akiyo さん、こんにちは。
上記内容に補足します。
WAF はアプリケーション層の動きに応じてブロックされるものです。
アプリケーション層の制御は、使われているプラグインやテーマなどで設定内容がかわってしまうことがよくあります。
つまり、チューニングは必須で、その設定方法はサイトごとに異なるということです。KUSANAGIでWAF(NAXSI)を使う
https://wynes.info/techblog/archives/2606こちらの記事に書かれている内容が、まずはチュートリアルな内容が含まれます。
また「さくらのサービス」をご利用でしたら、下記の WAF も使用できると思います。
KUSANAGI の WAF ではなく、ご自身が扱いやすい方でお試ししてみるのも良いかもしれません。SiteGuard Server Edition (WAF) さくらのサービスでWAFを利用する場合
https://manual.sakura.ad.jp/cloud/server/os-packages/siteguard-firewall.html最後に、WAF の遮断ログを確認しながらエラーの原因を解決していくことが、今回の目的を達成できるかと思います。
-
AuthorPosts