collne さん、こんにちは。

情報ありがとうございます。
KUSANAGI Version 8.7.5-2 ですね。

結論からお答えします。
かんたんにロールバックする方法はなく、ロールバックはセキュリティ上でもおすすめいたしません。
今回、KUSANAGI 8 で使用される PHP 7.4 系にエラーが出ないよう先行対応をしていただきました。

下記リリース文を参考に、バージョンアップ後にエラーが発生しないかご確認ください。
お願いになるのですが、バージョンアップ後に問題が発生しないことを確認したいので、実行前後のログをいただけると助かります。

KUSANAGIモジュール更新情報

—

今回の件はご承知の通り、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
`

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 設定ファイルの手当を行うなど試してみてください。
上記にも記載したとおりディレクトリ構成を変更し各種設定を手動で変更されている場合、動作は保証されませんので案くらいしかお伝えできませんがご了承ください。

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.php

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, 4 months ago by cloudy.

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 なので、そもそも正常に実行できていない恐れがあります。

KUSANAGI バージョンアップ情報 8.6.0-1

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=mariadb

KUSANAGI 8 FAQ – Q5. yum のアップデートを実行すると、エラーが出力されてアップデートできません。
以下のコマンドのとおり、 yum アップデート時に認証に失敗するリポジトリを対象外指定をして〜 の部分

FAQ

エラーで実行できなかった場合は、理由はエラーメッセージに書かれているとおりなので、そのエラーのモジュールを一時的に –disablerepo に追加します。
上記のアップデートが上手く実行できた場合は、2.に戻って改めてパッケージ類をアップデートしてください。

こちらのエラーの原因は FAQ でも書かれている通り、KUSANAGI ベースイメージの CentOS 側で MariaDB 10.1 のサポートが完全に終了しているため表示されるものです。
KUSANAGI 8 自体のバージョンアップがこまめにされていないようですので、今回のアップデート時に大きな差分ができ発生したと思われます。
こまめなアップデートを推奨します。

4. MariaDB 10.5 への移行

3.まで完了すると kusanagi upgrade mariadb 10.5 コマンドが使用できると思います。
バージョンアップを行う前には、必ずバックアップを取っておいてください。

MariaDB のバージョンアップ後はサーバーの再起動をしてください。
質問には記載はありませんでしたので、もしかしたら作業漏れているのかも？と思っています。

以上、ご確認ください。

ramen_umai 様

ご指摘ありがとうございます。
今回の件、ramen_umai 様のご指摘どおりで間違いございません。

ramen_umai 様にはご不快な印象を与えてしまいまして、大変申し訳なく思っております。
お時間を頂いたうえでご指摘いただき、誠にありがとうございました。

> KUSANAGI9の方ではdefine(‘FS_METHOD’, ‘ftpext’);を記載するような指示が以前から存在しましたが、
> KUSANAGI8の方には未だにKUSANAGI8 新着記事の中にも記載はありません。

こちらのご指摘ですが、私の方でも改めまして全投稿を確認致しました。
ご指摘頂いた通り、この件に言及した記事は見つかりませんでした。
関係部署に改善するよう私から連絡しておきます。

今後とも KUSANAGI をご愛顧いただけますよう改善していきますので、ご指導・ご鞭撻のほどどうぞよろしくお願い致します。

Dunford さん
こんにちは。

私の KUSANAGI 8 FE Vagrant 環境では utf8mb4 になっていました。
そこでご確認です。

• KUSANAGIのバージョンやエディションは何でしょうか？
• サーバーの環境はどこでしょうか？

フロントページにもある通り、 kusanagi status の結果を貼り付けていただけると確認が取りやすいです。

また、どの段階で確認して utf8mb4 になっていたのでしょうか？
kusanagi init 直後ですか？ kusanagi provision 直後ですか？ その他ですか？