yosuke
Forum Replies Created
-
Posts
-
Ice_Grand さん、こんにちわ。
> wordpressのログインポップアップが表示されるが、provisionで設定したユーザー名とパスワードを入力してもログインできない。
> ログインをあきらめると401 Authorization Requiredが表示される。⇒ポップアップは、Basic認証のユーザー名とパスワードになります。
※WordPress の管理画面のユーザー／パスワードとは、別のものになります。kusanagi initコマンドで指定してなければ、以下になりますので、そちらでご確認ください。
ユーザー名：kusanagi
パスワード：kusanagi initで指定したkusanagiユーザーのパスワード参考サイト
kusanagi initコマンド：
https://kusanagi.tokyo/document/commands/init/tarky さん、こんにちわ。
> ただ、上記の「定義名」というのだけ、何のことをおっしゃっているのかわかりませんでした。
> これは何でしょうか？monitの設定ファイルにおける監視項目の定義名になります。
詳しくは、monitのドキュメントや/etc/monit.d/OLDPROFILE.httpdあるいは
/etc/monit.d/OLDPROFILE.nginxを直接ご確認ください。以下は一例です。
check file OLDPROFILE_httpd with path /home/kusanagi/OLDPROFILE/log/httpd/access.log ~~~~~~~~~~~~~~~~ ← この部分soybeans59 さん、こんちにわ。
まず、トップページにありますように、
kusanagi statusの結果の貼り付けをお願い致します。
また、ご使用のWebサービス（httpd or nginx）の error.log の内容も貼り付けをお願い致します。
（「シンタックスエラーが発生し」のエラー内容を確認したいです。）tarky さん、こんにちわ。
kusanagi statusの結果、ありがとうございます。※KUSANAGI には KUSANAGI 8、KUSANAGI 9があり、
またEditionも、無償版、Business Edition Premium Editionと複数あります。
それぞれで対処方法が異なるので、お使いの環境が詳しく分からないことには回答出来かねます。
ご質問の際には、kusanagi statusの結果の貼り付けの方を合わせてお願い致します。> どこを書き換えるかなどの資料はあるのでしょうか？
⇒以下の対応になるかと思います。
※プロファイルの旧名が「OLDPROFILE」、新名が「NEWPROFILE」とします。
※DB名、DBユーザーは、変更しない前提です。・/etc/kusanagi.d/profile.conf
該当プロファイルのセクション [OLDPROFILE] を [NEWPROFILE] に書き換える・/etc/kuasnagi.conf
PROFILE=”OLDPROFILE” を “NEWPROFILE” に書き換える・/etc/nginx/conf.d
OLDPROFILE_http.conf OLD_PROFILE_ssl.conf をそれぞれ NEWPROFILE_http.conf NEWPROFILE_ssl.conf にリネームする
ログのパスでOLDPROFILEの箇所を全てNEWPROFILEに置換する。
DocumentRootのパスでOLDPROFILEの箇所を全てNEWPROFILEに置換する。・/etc/httpd/conf.d
OLDPROFILE_http.conf OLD_PROFILE_ssl.conf をそれぞれ NEWPROFILE_http.conf NEWPROFILE_ssl.conf にリネームする
ログのパスでOLDPROFILEの箇所を全てNEWPROFILEに置換する。
DocumentRootのパスでOLDPROFILEの箇所を全てNEWPROFILEに置換する。・/etc/monit.d
OLDPROFILE_httpd.conf OLDPROFILE_nginx.conf をそれぞれお NEWPROFILE_httpd.conf NEWPROFILE_nginx.conf にリネームする
ログのパスでOLDPROFILEの箇所を全てNEWPROFILEに置換する。
DocumentRootのパスでOLDPROFILEの箇所を全てNEWPROFILEに置換する。
定義名でOLDPROFILEが使われている部分をNEWPROFILEに置換する。・/home/kusanagi
OLDPROFILE を NEWPROFILE にリネームする・サービス再読み込み、サービス再起動
上記を全て変更したら
kusanagi monit reload
kusanagi restart
を実行する。以上になるかと思います。
> 別の方法で再作成先にデータ移行する必要があるという認識で合ってますでしょうか？
⇒新しく指定のプロファイル名で、環境構築して、DBデータとWordPressのコンテンツをコピーして、
現行環境と切り替える流れになるかと思います。tarky さん、こんにちわ。
トップページにありますように、
kusanagi statusの結果の貼り付けをお願い致します。> コマンドラインでの作業の時に可読性が悪いために、プロファイル名をドメイン名などの見やすい文字列に変更したいのですが、方法はあるのでしょうか？
⇒各設定等で、プロファイル名を手動で書き換える方法になるかと思います。
ただし、推奨するやり方ではなく、保証出来ませんので、
再作成していただく方が良いかと思います。kurisu さん、こんにちわ。
本件、ご指摘ありがとうございます。
修正版がリリースされましたので、そちらでご確認ください。vanilla さん、こんにちわ。
ご質問される場合は、トップページにある通り kusanagi status の結果の貼り付けをお願いします。
> メインのディレクトリは掛かるのですが、下位階層のサイトを開くと見れてしまいます。
（nginx 使用の前提でお話しますが、）
KUSANAGI環境は、デフォルトでは、/wp-admin（wp-login.php）に、
Basic認証の設定がありますが、それ以外で、設定変更されたと推測しております。以下などをご参考に、設定変更していただければと思います。
WordPress のログイン画面に制限をかける：
te2ji さん、こんちにわ。
「さくらのVPS」のイメージは、プライム社で提供しているものではなく、
さくらインターネット様が提供しているものですので、そちらが提供できなければ入手方法はございません。KUSANAGIのRPMのみであれば
dnf downgradeやdnf upgradeで特定のRPMのバージョンを指定することで、
理論上は合わせることは可能です。
ですが、KUSANAGI以外のRPM（OSやepelのライブラリ）は、依存関係などから同じバージョンにできなかったり、
既に公開終了していて同様の方法で合わせることは、非常に難しいと思われます。「さくらのVPS」では出来ませんが、
「さくらのクラウド」などのスナップショット機能があるクラウドの利用をご検討いただければと思います。kousaka さん、こんにちわ。
> 例えばですが、kusanagi側でサポート外の挙動や複数のサイト構成をチェックするようなものがあるのかなどご存知でしょうか？
⇒サポート外ですので、それらをチェックする機能はない認識です。
何がトリガーになっているのかは、分かりかねますが、
アクセスログやシステムログなどに、問題部分が出力されている場合がございますので、
それらをご確認いただければ良いかと思います。Genbu さん、こんにちわ。
「永続オブジェクトキャッシュを使用してください」は、あくまでWordPressによる改善提案の1つなので、無視しても問題ございません。
そもそもサイトの負荷が高いか、他のプラグインが遅いかなどによって性能が劣化すると表示されるようになるメッセージになります。
どうしてもメッセージを消したいならば、永続オブジェクトキャッシュに対応したプラグイン等をインストールすることになります。
ただし、KUSANAGI の bcache と競合することが多いのでおすすめはしません。基本、オブジェクトキャッシュとは、DBから読み出したデータを再利用するためにキャッシュ化するもので、DBが遅いのが根本問題になります。
ですので、先にボトルネックをご確認いただいた方が良いかと思います。もし、VMリサイズなどで、メモリサイズが変わっている場合は、DBのメモリキャッシュが適切でない可能性があります。
その場合は kusanagi dbinit コマンドを利用して、DBキャッシュサイズを再設定してください。kousaka さん、こんにちわ。
> この環境下で、kusanagi provision コマンドを利用せず、/home/kusanagi 配下に 14 の WP サイトを root 権限で直接配置。
⇒kusanagi provision を使わない方法はサポートしておりませんので、
ご自身の責任でご対応ください。また、MySQL 8 は、サポートしておりませんので、ご承知おきください。
BreadMan さん、こんにちは。
> /var/logにmaillogがない場合はどこを確認すればよいでしょうか。
postfix は使用されていないということですね。
直接SMTPサーバーへメール送信されているのでしたら、
送信先のメールサーバーが拒否している可能性もあるかと思います。PHPMailer で、デバッグログの出力設定があるようですので、
そちらでご確認いただければと思います。参考サイト：PHPMailerでメールをSTMP送信する — Qiita
※「送信処理が出来ている／出来ていない」と「メール受信している／受信していない」とは、
切り分けてご確認されるとよいかと思います。
