cloudy
Forum Replies Created
-
Posts
-
beanjamjp さん、こんにちは。
改めてエラーを確認したところ、プロファイルの指定エラーは出ていないようです。
> kusanagi migrate –export profile
> Target profile is profile.
> Database (profile) export failed.なので、
kusanagi statusとkusanagi migrateのプロファイル指定が合わないのは、質問を書くときに書き換えられたということでしょうか？> Profile:xxxx
> kusanagi migrate –export profileですので、「プロファイル指定は正しい」と仮定してこちらで検証いたしましたところ不具合が見つかりました。
最新版で対応いたしましたので、アップデートの上で確認をお願い致します。KUSANAGI 9 バージョンアップ情報 9.4.9-1
https://kusanagi.tokyo/releases/13097/beanjamjp さん、こんにちは。
プロファイル名を間違えているのではないでしょうか？
kusanagi statusの結果では、プロファイル名はxxxxとなっております。> Profile:xxxx
であれば、コマンドは次のとおりとなります。
> kusanagi migrate –export xxxx
kusanagi migrateコマンドの使用方法は KUSANAGI Tech Blog にて公開されていますので、こちらもご一読ください。masahiro さん、こんにちは。
> 現在Kusanagi9をインストールしているCentOS 8 Streamを9にアップグレードしようとしているのですが、Kusanagiのrepoでエラーになります。
KUSANAGI 9 CentOS Stream 8 から KUSANAGI 9 CentOS Stream 9 への直接アップグレードはできません。
新しく KUSANAGI 9 CentOS Stream 9 でサーバーを構築し移行してください。
移行にはkusanagi migrateコマンドを活用することもできます。kusanagi migrateコマンドで移行する
bcache / fcache はテックコラムにも情報があります。
こちらのほうが詳細に書かれていますのでご一読ください。kusanagi bcache コマンドとその仕組み – KUSANAGI Tech Column
kusanagi fcache で超高速 CMS 実行環境を実現する – KUSANAGI Tech Column
Hermana0 さん、こんにちは。
kusanagi status の結果がないので推測で提案します。
nginx を使っているのであれば、fcache を検討してください。【bcache について】
> しかし、（2）のサーバはLoadAverageが高くなりやすく悩んでいます。
> 現在（2）のサーバではデータベースが稼働していないのですが、
> bcache用テーブルのためにデータベースを稼働させると、さらにLoadAverageが上がってしまいますでしょうか。はい、新たに DB サービスが立ち上がることになるので、当然ロードアベレージに負荷がかかると思われます。
そもそも、ロードアベレージが上がる原因は多岐にわたります。
まずは、ロードアベレージを引き起こしている原因をきちんと調査することが重要です。
WordPress ではなく別の原因であった場合、WordPress 周りの最適化をしても意味がないことになるかもしれません。ロードアベレージの入門として、下記の記事を参考にしてみてください。
https://qiita.com/k0kubun/items/8ab1dfa7c0359d8e618d
原因が WordPress であることが裏付けられても、許容できる負荷であるかは実際に試してみないとなんとも言えません。
【fcache について】
もし nginx を使用されているのであれば、おすすめは fcache です。
fcache は nginx のキャッシュを利用するもので、次のようなメリットがあります。– 新たに DB サービスを立ち上げることがありません。
– nginx 側でキャッシュを返すため、PHP 実行や DB 接続などの負荷が軽減されます。bcache と fcache のざっくりとした違いは、下記の記事を参考にしてみてください。
https://www.zukeran.org/shin/d/2018/05/15/kusanagi-bcache-fcache-2/
KUSANAGI Tech Column にて、「KUSANAGIでプロキシサーバの設定を行う」記事が公開されました。
プロキシの件で参考になる内容があるかもしれませんので、こちらの記事も併せて参考にしてみてください。ma-to さん、こんにちは。
KUSANAGI で mod_perl は利用できません。
mod_perl ではなく通常の CGI Perl や fastcgi での利用を検討ください。KUSANAGI で使用する Apache は kusanagi-httpd になります。OS 標準の httpd ではありません。
rpm で入れる mod_perl は OS の httpd 用なので、kusanagi-httpd とバッティングします。バッティングしているファイルを削除するなど行えば無理矢理にでも rpm から mod_perlを入れられますが、rpm で httpd を入れると、kusanagi-httpd は使えなくなります。当然動作の保証はできなくなります。
whojitaknee さん、こんにちは。
プロキシを試してみたのですが、簡単に対応できる手法は構築できませんでした。すみません。
他の方もこちらを参考にされるかもしれないので、別の手法をメモしておきます。
正規の手法ではないのですが別の対応方法として、kusanagi migrate コマンドでプロキシ環境外で構築し、移設する手法も使えるかなと思います。rock さん、こんにちは。
KUSANAGI の範囲か判断がつかないですが、まずはトップページにある通り kusanagi status の結果を貼り付けてください。
予想としてはお察しの通り、ユーザー権限、グループ権限、パーミッションが原因と思われます。
そして、環境ごとにそれらは異なっている可能性があるため、一様の解決は困難です。
エラーが発生したときはログを確認することが重要なので、まずそちらを確認してみてください。fuku さん、こんにちは。
原則 firewalld の設定の話は KUSANAGI の管轄外なので、他のところでご質問していただけますようお願い致します。
その上で、私が見た感想です。
80/http, 443/https ポートを開放していないからではないでしょうか？設定を変更する際は下記のような手順で作業することをお勧めします。
1. 設定ファイルのバックアップを作成 （例:
mv public.xml public.xml.bak）
2. 設定ファイルの編集
3. 設定ファイルの変更点を比較 (例:diff work.xml public.xml.bak)比較すると、設定考慮漏れなどが見つかるためおすすめです。
domainky さん、こんにちは。
`
ssl email completed.
Auto renewal of certificate enabled.
ssl auto completed.
restart completed.
ssl completed.
`一応、正常に完了しているように見えます。
ブラウザ、もしくは openssl コマンド等から、正しく TLS/SSL が適用できているか確認してみてください。TLS/SSL に関しては、下記の記事も参考にしてください。
エラーの確認に関しましては、下記の記事を参考にしてみてください。
コマンド実行が完了しているかどうかは、記事に書いてあるとおり、コマンド実行直後に
`
$ echo $?
`を実行して、どんな値が返ってきているか確認してみてください。
nanz さん、こんにちは。
コメントを見る限り、ロールバックの意味を正しく把握されていないものとお見受けいたします。
アンインストールとロールバックは別物です。ロールバックは、その地点まで作業をもとに戻すことを指します。
アンインストールのみでは、依存ライブラリについての考慮ができていません。
手動で PHP のインストールなどを行っているため、ライブラリ依存関係も当然元にも戻す必要があります。
確実なロールバックは、作業前時点のスナップショットに戻すことです。スナップショットの状態にロールバックする作業例
https://qiita.com/takahashi-kazuki/items/23a5a7c62fc086d51909yum history undoでパッケージの導入をロールバックする作業例
ロールバック (スナップショットや yum など) の話は KUSANAGI の範囲外の内容となりますので、こちらでの回答はできかねます。
上記はあくまで参考情報です。
ご了承ください。nanz さん、こんにちは。
先のメッセージにも書いた通り、KUSANAGI で提供している以外の PHP をインストールして使用しているようです。
確認のため、PHP 8.2 をインストールした方法を教えてもらえませんか？
KUSANAGI が提供している PHP 以外のものを手動でインストールしている場合、自己責任となりサポート対象外となります。—
KUSANAGI 8 で PHP 8 系を使う場合は次のコマンドを使用します。
kusanagi php8KUSANAGI 8 で PHP8 での kusanagi status 実行結果の一部抜粋します。
*** (active) php8-fpm ***
● php8-fpm.service – The PHP FastCGI Process Manager
Loaded: loaded (/usr/lib/systemd/system/php8-fpm.service; enabled; vendor preset: disabled)
Active: active (running) since Mon 2023-01-23 10:22:59 JST; 21s agophp8-fpm なので PHP 8。php-fpm と php8-fpm は違います。よく確認してください。
php -v 実行結果。
PHP 8.0.27 (cli) (built: Jan 6 2023 08:51:20) ( NTS )
Copyright (c) The PHP Group
Zend Engine v4.0.27, Copyright (c) Zend Technologies
with Zend OPcache v8.0.27, Copyright (c), by Zend Technologiesこれが KUSANAGI 8 で PHP 8 系に正しく切り替わっている結果となります。
—
頂いた kusanagi status の内容を確認したところ、
*** (active) php-fpm ***
● php-fpm.service – The PHP FastCGI Process Manager
Loaded: loaded (/usr/lib/systemd/system/php-fpm.service; enabled; vendor preset: disabled)
Active: active (running) since 木 2023-08-24 17:25:05 JST; 16h agophp-fpm なので PHP 5。php-fpm と php8-fpm は違います。よく確認してください。
ですので KUSANAGI 8 は PHP 5 系を動作させようとしています。# php-fpm -v
PHP 8.2.9 (fpm-fcgi) (built: Aug 3 2023 11:39:08)
Copyright (c) The PHP Group
Zend Engine v4.2.9, Copyright (c) Zend Technologies
with Zend OPcache v8.2.9, Copyright (c), by Zend Technologiesこちらをみると PHP 5 系ではなく、PHP 8 系を実行した結果が返ってきています。
おそらく別にインストールされた PHP 8 系を動作させようとしています。なので、PHP サービスの衝突が起こっていると予想されます。
原因は、KUSANAGI で提供している PHP 以外の PHP を手動でインストールしないと起こり得ません。
KUSANAGI 8 で推奨していない使い方となり、サポート対象外となります。心当たりがある場合、PHP を手動でインストールする以前にロールバックして、改めて KUSANAGI 8 標準の PHP 8 系をご利用いただければ「抜本的改善」になると思われます。
nanz さん、こんにちは。
まずは、トップページに書かれている通り、kusanagi status の結果を添付してください。
> PHPの入れ直しと各種update
> ○作業後
> PHP 8.2.9具体的にどのような作業をされたのか不明ですが、PHP を KUSANAGI で提供しているもの以外を使われていることが原因ではないでしょうか？
kusanagi-php と php は別物です。
サポート対象外の作業をしているような気がします。KUSANAGI 8 の PHP 8 系のサポートバージョンは 8.0.x のみのはずで、8.2.x はサポート対象外です。
PHP 8.0.x / 8.1.x / 8.2.x 切り替えサポートは KUSANAGI 9 でのみ提供されています。KUSANAGI 8 の kusanagi php-fpm は PHP 5.6.x 系のことのはずです。
PHP 8 系が使用されているのであれば、サービスは php8-fpm が使用されているはずです。ユーザーフォーラムの下記の内容が参考になるかと思います。
また、セキュリティ対応が必要であれば KUSANAGI 9 への移行を強くお勧めします。
