hideishi

Forum Replies Created

Viewing 15 posts - 1 through 15 (of 29 total)
  • Author
    Posts
  • hideishi
    Participant

      すみません、補足します。

      4) それでも解決しない場合はKUSANAGIマーケットプレイスのフッターに「お問い合わせ」のリンクがあります。
      こちらか調査対象となるログインアカウントに関する情報をできるだけ詳細に入力の上でお問い合わせください。

      hideishi
      Participant

        sato_seaboseさん、こんにちは。

        1) KUSANAGIマーケットプレイスの注文画面で名前や住所、メールアドレスを入力して
        ライセンスを購入完了した際に「KUSANAGI Marketplace アカウントが作成されました」という
        タイトルのメールがメールアドレス宛てに送られます。
        こちらのメールのリンクから初期パスワードを設定します。
        迷惑メールなどに振り分けられていないかどうか、確認いただけますでしょうか。

        2) パスワードが分からない場合は、KUSANAGIマーケットプレイスの上部に「ログイン」があります。
        そこから「マイアカウント」のログインページへ進んでください。
        下部の「パスワードをお忘れですか?」から再発行してください。
        もしも再発行した旨のメールが来ない場合は、そもそもユーザー登録されていない可能性が高いです。

        3) ユーザー登録されていない場合は、KUSANAGIマーケットプレイスの
        注文画面で名前や住所、メールアドレスを入力してあらためて注文を行ってください。
        この際、既に登録しているメールアドレスの場合には「アカウント登録済みのメールアドレスです」という
        エラーメッセージが表示されます。
        この場合、ユーザーは存在するので 2) を試してください。
        その際に迷惑メールなどに振り分けられていないかどうか確認ください。

        hideishi
        Participant

          Hello,
          I suppose you provisioned the first website (website1.com) with kusanagi provision command.
          Then you can just use the same command to provision the second website (website2.com) with the same kusanagi provision command.
          Note that you obviously need to use different dbname/dbuser and profile name for the second website.
          For detail, please refer to the document.

          KUSANAGI Commands

          in reply to: kusanagi9の初期設定で失敗する #1299
          hideishi
          Participant

            初回initの際に何らかの理由でMariaDBのパスワードが正しく設定できなかった結果、その後MariaDBにアクセスできない状態にあるのがinitとprovisionの両方が失敗する原因と考えられます。
            いずれにしてもVMの作り直しがもっとも近道だと思います。

            手順についてはKUSANAGIでは分かりかねますので、お使いのクラウド事業者様にお問い合わせいただけますでしょうか。
            よろしくお願いいたします。

            • This reply was modified 6 months, 4 weeks ago by hideishi.
            in reply to: kusanagi9の初期設定で失敗する #1297
            hideishi
            Participant

              kusanagi statusとログの提供ありがとうございます。

              kusanagi statusの結果からはmariadbが正常に起動しているので、initに問題はなさそうです。
              そのままprovisionできるのではないかと思います。

              今回実行されたinitは初回のinitではなく、2回目以降のinitの実行ですね?
              再度initを実行しても同じになるか確認ください。
              それでもダメならば kusanagi dbinit mariadb を実行してみてください。
              それでも解決しない場合はVMを作り直す方が早いと思います。

              in reply to: kusanagi9の初期設定で失敗する #1293
              hideishi
              Participant

                こんにちは。
                kusanagi statusの情報がないので憶測で書きます。
                kusanagi initの中でMariaDBのインストールをする処理で止まっているものと思われます。
                その場合、ここ数日はMariaDBのリポジトリへのアクセスが不安定だったのでその影響が考えられます。
                時間をあけて再度試してみてはいかがでしょうか?
                また /var/opt/kusanagi/log/kusanagi.log の中身を見ることで詳細が分かるかもしれません。

                • This reply was modified 6 months, 4 weeks ago by hideishi.
                • This reply was modified 6 months, 4 weeks ago by hideishi.
                hideishi
                Participant

                  WEXALはPHP7以上が必須なので、PHP5.6では動作しません。

                  php-fpmサービスは PHP5.6 です。
                  PHP7 は php7-fpm サービスになります。

                  タイムアウト時間を変更した際に、誤って php7-fpm の代わりに php-fpm を起動したのではないでしょうか?

                  KUSANAGIコマンドも kusanagi php は PHP5.6 で、PHP7 は kusanagi php7 です。
                  kusanagi php7 を実行して、PHP7に戻してください。

                  なお、PHP7のiniの場所はPHP5.6と異なるので、タイムアウトの設定を変更している場合は同じものを
                  PHP7にも設定してください。/etcのディレクトリ名で判断できると思います。

                  • This reply was modified 1 year, 2 months ago by hideishi.
                  hideishi
                  Participant

                    無効にできていないようですね。
                    optimized_wp_settings.php が残っていたら手で削除してみてください。
                    また、wp-config.phpを以下のように修正してください。

                    /** Sets up WordPress vars and included files. */
                    require_once(ABSPATH . ‘wp-settings.php’);

                    本来ならば

                    /** Sets up WordPress vars and included files. */
                    if ( file_exists( ABSPATH . ‘optimized_wp_settings.php’ ) && ( ! defined( ‘WP_CLI’ ) || constant( ‘WP_CLI’ ) !== true ) ) {
                    require_once(ABSPATH . ‘optimized_wp_settings.php’);
                    } else {
                    require_once(ABSPATH . ‘wp-settings.php’);
                    }

                    にあるように optimized_wp_settings.php か wp-settings.php のどちらかしか読み込まれないはずなのですが、
                    プラグインかテーマか何かが干渉しているのか、media.phpが二重に読み込まれているのがエラーの原因です。

                    hideishi
                    Participant

                      kuorda さん、こんにちは。

                      wp-settings.phpの最適化はかなりピーキーな最適化を行うオプションです。
                      プラグインやテーマによっては動作しない場合がありますので、
                      もしも表示に問題が出るならば無効にするようにしてください。

                      PHP 8.0以降で採用されているJITコンパイラによる最適化をできるだけ受けられるように
                      optimized_wp_settings.phpを生成します。
                      ただ、このファイルの生成は管理画面で有効化したときにのみに行われるので、
                      WordPressのアップデートやプラグイン、テーマの更新があっても更新されず、
                      このファイルを削除して再生成する必要があります。
                      有効にしてからしばらく時間が空いている場合は、これが原因の可能性が高いです。

                      なお、PHP8.0以前の場合はあまり改善効果は見込めません。

                      in reply to: 「yum update kusanagi」実行でエラー #1050
                      hideishi
                      Participant

                        アップデートの際には注意事項がある場合があります。
                        リリース情報も確認ください。

                        KUSANAGIモジュール更新情報

                        モジュールのアップデートについては、以下のコマンドで適用可能です。

                        # yum update –enablerepo=remi,remi-php56

                        php8を使用している場合は以下のコマンドで再起動してください。

                        # kusanagi php8

                        in reply to: 「yum update kusanagi」実行でエラー #1049
                        hideishi
                        Participant

                          以下を見てください。

                          FAQ

                          Q5. yum のアップデートを実行すると、エラーが出力されてアップデートできません。

                          A5-2. 以下のようなメッセージが出力された場合、パッケージ依存性の処理において remi パッケージを必要とすることがあります。

                          エラー表示の例
                          You could try using –skip-broken to work around the problem
                          You could try running: rpm -Va –nofiles –nodigest

                          問題を回避するために –skip-broken を用いることができます。
                          これらを試行できます: rpm -Va –nofiles –nodigest

                          in reply to: kusanagi 9 init ができない #995
                          hideishi
                          Participant

                            kusanagi 9 init ができないです。
                            コマンドは以下、init自体はよくやるやつなので、問題はないはずなのですが

                            そのinitに失敗しています。
                            おそらくはnginxのインストールが完了していないと思います。
                            kusanagi statusを見るとnginxがいないのではないでしょうか。

                            kusanagi initをした際のログを貼っていただけますか?

                            nginxのインストールが失敗している場合、
                            kusanagi nginx –use nginx121 などでnginxだけ入れ直すと解決します。

                            in reply to: php7-7.4.25-1を対象としたyum updateに失敗する #757
                            hideishi
                            Participant

                              こんにちは

                              kusanagi-php7のアップデートでは –enablerepo=remi が必要です。

                              KUSANAGIモジュール更新情報

                              `
                              # yum update kusanagi-php7 –enablerepo=remi
                              # kusanagi php7
                              # yum update kusanagi
                              `

                              in reply to: KUSANAGI9にてphp-fpmが落ちる #750
                              hideishi
                              Participant

                                こんにちは

                                kusanagi init に –ruby26 を指定したときに、phpが正しくインストールされないのが原因だと分かりました。

                                今は動作していると思いますが、一応以下のコマンドを実行しておいてください。
                                phpインストール時の行うはずの処理を実行します。

                                kusanagi php
                                
                                in reply to: KUSANAGI9にてphp-fpmが落ちる #748
                                hideishi
                                Participant

                                  こんにちは。

                                  モジュールが最新になっているか確認いただけますか?

                                  dnf update -y
                                  

                                  特にkusanagi-openldapが最新になっていない可能性が高いです。
                                  最新は以下です。

                                  dnf list --installed | grep kusanagi-openldap
                                  kusanagi-openldap.x86_64                    2.5.7-1.el8                                       @kusanagi
                                  
                                Viewing 15 posts - 1 through 15 (of 29 total)