yosuke
Forum Replies Created
-
Posts
-
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
※「送信処理が出来ている／出来ていない」と「メール受信している／受信していない」とは、
切り分けてご確認されるとよいかと思います。BreadMan さん、こんにちは。
> PHPMailerでのメール送信の際に、エラーを出さずにメール送信処理がうまくいきません。
まずは、メールログをご確認ください。
/var/log/maillogエラーが出てないということですので、メール送信処理自体は、実行されている可能性があるかと思います。
ローカル環境とメールログを比較されるとよいかと思います。※アプリの問題でしたら、本来はこちらのフォーラムで対象外の話題になりますので、ご承知おきください。
toytomo さん、こんにちは。
KUSANAGI 9 では、
CentOS Stream 9 / AlmaLinuxOS 8 / AlmaLinuxOS 9
を提供しておりますので、
貴社の運用ポリシーに合わせて、ベースOSをご選択ください。> kusanagiのcentos streem9も自動アップデートされていくのでしょうか
CentOS Stream 9 でも自動アップデートはございませんので、
dnf updateしない限りはアップデートはされません。toytomo さん、こんにちは。
> 本番リリース前に現在稼働中のサーバから証明書を持ってきて、
現行環境のSSL証明書を持ってこれるのでしたら、
kusanagi provision で 「--noemail」オプションを指定して、letsencryptを発行しないようにして、
kusanagi ssl の「--cert 証明書ファイル --key 鍵ファイル」オプションで、
構築環境に、現行環境のSSL証明書を設定すれば良いかと思います。toytomo さん、こんにちは。
> 今回はサーバの移行でドメインは現在使用しており、現在利用しているドメインのIPの向き先を変更することができません。
> この場合、皆さんはどのようにインストールを進めているのでしょうかKUSANAGI とは直接関係ない、サーバー移行に対するご質問かと思いますので、
まずは、サーバー移行時に、要件やスケジュール等で、どのように進めるかの方針を決めてから、
KUSANAGI固有の作業において、不明点をご質問いただいた方が良いかと思います。> kusanagi provision –wp –fqdn http://www.example.com –email kusanagi@example.com –dbname kusanagi_db –dbuser kusanagi_db –dbpass “パスワード” “任意のプロファイル名”
kusanagi provision にて、SSL証明書を設置しつつも、FQDNは、HTTPを指定されておりますので、
HTTP or HTTPS か、そのあたりの方針もまだ定まっていないように見受けられます。以下は、個人的な見解ではございますが、
サーバー移行のやり方について、色々あると思いますが、大きくは、２点になると思います。
１．現行ドメイン（www.example.com）で構築する。
２．現行ドメインとは、別ドメイン（stg.example.comなど）で構築する。１は、同じドメインを使用できるが、hosts設定などしないと閲覧できない、
２は、hosts設定不要で閲覧できるが、現行ドメインに切り替える必要がある、
など、それぞれ、メリット、デメリットがございますので、要件等に応じて、選択していただければと思います。仮に、１で進めるのであれば、
FQDNを「https://www.example.com」で、現行環境のSSL証明書を使用して構築する、
になるかと思います。Ice_Grand さん、こんにちは。
> その後パスワードを変更して初期アップデートを済ませ、reboot後コンソールでログインを確認しました。
どのユーザーのパスワードをどのように変更されましたか？
rootユーザーの場合、VMwareのイメージでは、デフォルトで rootでのリモートログインの許可設定をしていません。
（コンソール上ではログインできても、リモートでログインできないのは、このためです。）リモート (teraterm/rloginなど) からrootでログインする場合は、
推奨はしておりませんが、/etc/ssh/sshd_config の設定を変更ください。※セキュリティを確保できる対策として、以下を推奨します。
a) 別のユーザーアカウントを作成し、鍵を作成して、その鍵でログインをしてください。
b) kusanagi initを実行してkusanagiユーザー、および、鍵を作成して、その鍵でログインしてください。okegawa さん、こんにちは。
kusanagi status の貼り付け、ありがとうございます。php-pecl-memcache については、インストールしないようにしてください。
（インストールすると、依存関係で、OS の php がインストールされてしまうからです。）kusanagi-php(使っているバージョン)-devel をインストールしていただき、
それから、peclからモジュールをビルドしてもらえれば、よいかと思います。参考：
> KUSANAGI 9 で phpize を利用したい場合も同様になります。
> kusanagi-php(使っているバージョン)-devel をインストールしてください。yoshi さん、こんにちは。
> 構築した際は、755とkusanagi.kusanagiでしたが、最近のアップデートで更新されたのでしょうか？
はい、KUSANAGI 9.2.19-1 で更新されました。
https://kusanagi.tokyo/releases/8142/nanz さん、こんにちは。
> kusanagi nginx
> kusanagi php8-fpm
> と実行した直後のkusanagi statusが以下のような状態になります。「kusanagi --help」で見て頂ければわかると思いますが、「kusanagi php8-fpm」はないかと思います。
php8系で、動作させるのであれば、「kusanagi php8」になります。yoshi さん
https://kusanagi.tokyo/releases/10583/
Nginx 1.25-3 がリリースされましたので、
dnf upgradeで更新して再度試していただけないでしょうか？
（新しい nginx が見つからないようでしたら、dnf clean allも合わせてご対応ください。)
