cloudy

Forum Replies Created

Viewing 15 posts - 1 through 15 (of 110 total)
  • Author
    Posts
  • in reply to: kusanagi migrate –export のDatabaseエラーについて #1335
    cloudy
    Participant

      beanjamjp さん、こんにちは。

      改めてエラーを確認したところ、プロファイルの指定エラーは出ていないようです。

      > kusanagi migrate –export profile
      > Target profile is profile.
      > Database (profile) export failed.

      なので、 kusanagi statuskusanagi migrate のプロファイル指定が合わないのは、質問を書くときに書き換えられたということでしょうか?

      > Profile:xxxx
      > kusanagi migrate –export profile

      ですので、「プロファイル指定は正しい」と仮定してこちらで検証いたしましたところ不具合が見つかりました。
      最新版で対応いたしましたので、アップデートの上で確認をお願い致します。

      KUSANAGI 9 バージョンアップ情報 9.4.9-1
      https://kusanagi.tokyo/releases/13097/

      • This reply was modified 3 months, 1 week ago by cloudy.
      in reply to: kusanagi migrate –export のDatabaseエラーについて #1334
      cloudy
      Participant

        beanjamjp さん、こんにちは。

        プロファイル名を間違えているのではないでしょうか?

        kusanagi status の結果では、プロファイル名は xxxx となっております。

        > Profile:xxxx

        であれば、コマンドは次のとおりとなります。

        > kusanagi migrate –export xxxx

        kusanagi migrate コマンドの使用方法は KUSANAGI Tech Blog にて公開されていますので、こちらもご一読ください。

        kusanagi migrateコマンドで移行する

        cloudy
        Participant

          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コマンドで移行する

          kusanagi migrateコマンドで移行する

          cloudy
          Participant

            bcache / fcache はテックコラムにも情報があります。
            こちらのほうが詳細に書かれていますのでご一読ください。

            kusanagi bcache コマンドとその仕組み – KUSANAGI Tech Column

            kusanagi bcache コマンドとその仕組み

            kusanagi fcache で超高速 CMS 実行環境を実現する – KUSANAGI Tech Column

            kusanagi fcache で超高速 CMS 実行環境を実現する

            cloudy
            Participant

              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/

              in reply to: kusanagi provisionでプロキシを認識しない #1309
              cloudy
              Participant

                KUSANAGI Tech Column にて、「KUSANAGIでプロキシサーバの設定を行う」記事が公開されました。
                プロキシの件で参考になる内容があるかもしれませんので、こちらの記事も併せて参考にしてみてください。

                KUSANAGIでプロキシサーバの設定を行う

                in reply to: KUSANAGI9 のApache環境でPerlを使いたい #1307
                cloudy
                Participant

                  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 は使えなくなります。当然動作の保証はできなくなります。

                  in reply to: kusanagi provisionでプロキシを認識しない #1291
                  cloudy
                  Participant

                    whojitaknee さん、こんにちは。

                    プロキシを試してみたのですが、簡単に対応できる手法は構築できませんでした。すみません。

                    他の方もこちらを参考にされるかもしれないので、別の手法をメモしておきます。
                    正規の手法ではないのですが別の対応方法として、kusanagi migrate コマンドでプロキシ環境外で構築し、移設する手法も使えるかなと思います。

                    kusanagi migrateコマンドで移行する

                    in reply to: wordpressのバージョンアップができない #1273
                    cloudy
                    Participant

                      rock さん、こんにちは。

                      KUSANAGI の範囲か判断がつかないですが、まずはトップページにある通り kusanagi status の結果を貼り付けてください。

                      予想としてはお察しの通り、ユーザー権限、グループ権限、パーミッションが原因と思われます。
                      そして、環境ごとにそれらは異なっている可能性があるため、一様の解決は困難です。
                      エラーが発生したときはログを確認することが重要なので、まずそちらを確認してみてください。

                      cloudy
                      Participant

                        fuku さん、こんにちは。

                        原則 firewalld の設定の話は KUSANAGI の管轄外なので、他のところでご質問していただけますようお願い致します。

                        その上で、私が見た感想です。
                        80/http, 443/https ポートを開放していないからではないでしょうか?

                        設定を変更する際は下記のような手順で作業することをお勧めします。

                        1. 設定ファイルのバックアップを作成 (例: mv public.xml public.xml.bak
                        2. 設定ファイルの編集
                        3. 設定ファイルの変更点を比較 (例: diff work.xml public.xml.bak)

                        比較すると、設定考慮漏れなどが見つかるためおすすめです。

                        in reply to: kusanagi ssl –email 時にエラーが発生します。 #1267
                        cloudy
                        Participant

                          domainky さん、こんにちは。

                          `
                          ssl email completed.
                          Auto renewal of certificate enabled.
                          ssl auto completed.
                          restart completed.
                          ssl completed.
                          `

                          一応、正常に完了しているように見えます。
                          ブラウザ、もしくは openssl コマンド等から、正しく TLS/SSL が適用できているか確認してみてください。

                          TLS/SSL に関しては、下記の記事も参考にしてください。

                          kusanagi ssl で簡単に SSL 設定を行う

                          エラーの確認に関しましては、下記の記事を参考にしてみてください。

                          KUSANAGIコマンドの実行結果を確認する

                          コマンド実行が完了しているかどうかは、記事に書いてあるとおり、コマンド実行直後に

                          `
                          $ echo $?
                          `

                          を実行して、どんな値が返ってきているか確認してみてください。

                          cloudy
                          Participant

                            neko さん、こんにちは。

                            まずは、トップページに書かれている通り、kusanagi status の結果を添付してください。

                            cloudy
                            Participant

                              nanz さん、こんにちは。

                              コメントを見る限り、ロールバックの意味を正しく把握されていないものとお見受けいたします。
                              アンインストールとロールバックは別物です。

                              ロールバックは、その地点まで作業をもとに戻すことを指します。
                              アンインストールのみでは、依存ライブラリについての考慮ができていません。
                              手動で PHP のインストールなどを行っているため、ライブラリ依存関係も当然元にも戻す必要があります。
                              確実なロールバックは、作業前時点のスナップショットに戻すことです。

                              スナップショットの状態にロールバックする作業例
                              https://qiita.com/takahashi-kazuki/items/23a5a7c62fc086d51909

                              yum history undo でパッケージの導入をロールバックする作業例

                              ロールバック (スナップショットや yum など) の話は KUSANAGI の範囲外の内容となりますので、こちらでの回答はできかねます。
                              上記はあくまで参考情報です。
                              ご了承ください。

                              cloudy
                              Participant

                                nanz さん、こんにちは。

                                先のメッセージにも書いた通り、KUSANAGI で提供している以外の PHP をインストールして使用しているようです。
                                確認のため、PHP 8.2 をインストールした方法を教えてもらえませんか?
                                KUSANAGI が提供している PHP 以外のものを手動でインストールしている場合、自己責任となりサポート対象外となります。

                                KUSANAGI 8 で PHP 8 系を使う場合は次のコマンドを使用します。

                                kusanagi php8

                                KUSANAGIコマンド

                                KUSANAGI 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 ago

                                php8-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 ago

                                php-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 系をご利用いただければ「抜本的改善」になると思われます。

                                cloudy
                                Participant

                                  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 が使用されているはずです。

                                  ユーザーフォーラムの下記の内容が参考になるかと思います。

                                  PHP7よりPHP8へ移行できない

                                  また、セキュリティ対応が必要であれば KUSANAGI 9 への移行を強くお勧めします。

                                Viewing 15 posts - 1 through 15 (of 110 total)