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 1 year, 10 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 のバージョンアップ後はサーバーの再起動をしてください。
質問には記載はありませんでしたので、もしかしたら作業漏れているのかも?と思っています。以上、ご確認ください。
hanju8810 さん
情報ありがとうございます。
KUSANAGI 8 ですね。1. cron 確認
root ユーザーの cron です。
基本的に cron を調査する際には、権限があるのでしたら全ユーザーの cron を確認する習慣をつけることをオススメします。KUSANAGI 8 であれば通常、毎週日曜日の03:07に自動更新されるはずです。
たぶん、下記のような表記があると思います。07 03 * * 0 /usr/bin/kusanagi update cert
この表記があって実行されていない場合には、何らかの理由で自動更新が失敗していると思います。
cron ログに出力がない場合、一時的にログ出力を追加し問題が発生していないか確認することをオススメします。
letsencrypt.log ログも参考になると思います。2. 手動更新で更新できるか確認
kusanagi update cert (プロファイル名)
エラーが表示された場合でよくわからない場合、エラーメッセージ内容で検索すると解決法が見つかることがあります。
手動で更新できる場合は、cron 側が問題であると切り分けできるかと思います。3. KUSANAGI 8 とパッケージの更新
使用されている KUSANAGI 8 のバージョンは KUSANAGI Version 8.6.0-1 のようです。
最新の KUSANAGI 8 のバージョンは 8.7.1-1 です。
トップページに書かれている通り、他のモジュール含め最新版に更新すると問題が解決することが多いです。
まずは yum update 系の実行をしてみてください。最新版に更新した後、サーバーの再起動後に2.手動更新してみてエラーがないか確認してください。
4. kusanagi autorenewal を オフ/オン
kusanagi autorenewal off
kusanagi autorenewal on5. これでも解決しない場合
原因は色々と考えられますので、まずは一時的に cron ログ出力と確認するところから始めると良いと思います。
“/usr/bin/kusanagi update cert” で検索すると cron で Let’s Encrypt が自動更新されないケースがヒットします。
先にも述べた通り原因は色々考えられますので、こちらを一つずつ確認するほうが解決が早いかと思います。- This reply was modified 1 year, 10 months ago by cloudy.
hanju8810 さん、こんにちは。
トップページにも記載がありますが、質問の際にはご自身の環境をできるだけ記載ください。
できる範囲で構いませんが、こちらの情報がないと、回答いただけない場合があります。特に、kusanagi status の内容を貼り付けてください。
KUSANAGI のバージョンなどで回答が変わります。一般的な確認方法です。
Let’s Encrypt 更新は、有効期限30日前から実行可能だったと思います。
KUSANAGI での SSL 定期更新は cron に設定されていると思うので、 cron の設定内容およびログを確認してみてください。Byron さん、こんにちは。
トップページにも記載がありますが、質問の際にはご自身の環境をできるだけ記載ください。
できる範囲で構いませんが、こちらの情報がないと、回答いただけない場合があります。- kusanagi status の結果
- テーマ
- プラグイン`
- 実際のページのURL
- ソースコードの一部
- 他、関連する情報
今回の内容は憶測ですが、ECサイトのページにキャッシュを使用しているのではないでしょうか?
そもそも、ECサイトでキャッシュを使うことは非推奨です。- This reply was modified 1 year, 10 months ago by cloudy.
ramen_umai 様
ご指摘ありがとうございます。
今回の件、ramen_umai 様のご指摘どおりで間違いございません。ramen_umai 様にはご不快な印象を与えてしまいまして、大変申し訳なく思っております。
お時間を頂いたうえでご指摘いただき、誠にありがとうございました。> KUSANAGI9の方ではdefine(‘FS_METHOD’, ‘ftpext’);を記載するような指示が以前から存在しましたが、
> KUSANAGI8の方には未だにKUSANAGI8 新着記事の中にも記載はありません。こちらのご指摘ですが、私の方でも改めまして全投稿を確認致しました。
ご指摘頂いた通り、この件に言及した記事は見つかりませんでした。
関係部署に改善するよう私から連絡しておきます。今後とも KUSANAGI をご愛顧いただけますよう改善していきますので、ご指導・ご鞭撻のほどどうぞよろしくお願い致します。
-
AuthorPosts