cloudy
Forum Replies Created
-
Posts
-
shuo さん
今回の検索した情報および、問題の解決方法の予想が正しくありません。
各 WordPress プラグインの作成者の情報が公式ですので、公式が提供している一次情報を確認することが重要です。
下記が All-in-One WP Migration プラグインの公式の対応方法です。
もし英語がわからないのであれば翻訳サービス（Google 翻訳や DeepL など）を使ってください。ServMask Helpdesk – Knowledge Base – Invalid Archive Path
こちらではディレクトリやパーミッションの確認方法が案内されています。
権限のユーザーやグループについては触れられていません。つまり、変更する必要はありません。
これはエラーで表示および指示されている内容と同一です。
エラーに書かれている通り、必要なディレクトリ作成や適切なパーミッションを付与する作業が必要です。対応方法ですが、コマンド
kusanagi-docker wp shを実行したのち、Linux コマンドで対応してください。
以下、コマンド実行の参考例です。vagrant@ubuntu-focal:~/media.test.com$ kusanagi-docker wp –version
WP-CLI 2.7.1
INFO: Done.
vagrant@ubuntu-focal:~/media.test.com$ kusanagi-docker wp sh
/home/kusanagi/media.test.com/DocumentRoot $ mkdir wp-content/ai1wm-backups
/home/kusanagi/media.test.com/DocumentRoot $ chmod 0777 wp-content/ai1wm-backups
/home/kusanagi/media.test.com/DocumentRoot $ mkdir -p wp-content/plugins/all-in-one-wp-migration/storage
/home/kusanagi/media.test.com/DocumentRoot $ chmod 0777 wp-content/plugins/all-in-one-wp-migration/storageこの作業は All-in-One WP Migration プラグイン側のインストール作業で追加で必要となるものであり、KUSANAGI RoD とは関係ありません。
お伝えしている通り、All-in-One WP Migration プラグインのコミュニティなどにて質問してください。他にインストールができない WordPress プラグインについても上記と同じように公式の一次情報を確認して対応してください。
質問を読んでいると勘違いされているようですが、ユーザー権限とパーミッションは別物です。
また、コンテナでユーザー権限を変更するのであれば uid/gid などの Linux 基礎知識が必要となります。
知識がない状態でコンテナ内のユーザー権限をむやみに変更することはオススメいたしません。—
最後に、質問する際には実行結果やログなどの事実を記載して、その事実を前提に質問してください。
予想で質問されると、その予想がそもそも間違っていたときには解決のしようがありません。
私達が問題解決するときには、まず事実を並べた上で、ここからが予想と前置きした上で質問をします。
kusanagi statusなどのコマンド実行結果などを提供していただいているのはそのためです。shuo さん
こちらにも返答しておきます。
記事の中に書いた解決方法
$ chown -R httpd:www /path/to/wp-content/ai1wm-backups
$ chown -R httpd:www /path/to/wp-content/plugins/all-in-one-wp-migration/storage
でやってみましたが、いけなかったです。実際に実行した結果が貼られていないので回答に困りますが、予想としては当然の結果だと思います。
そのようなパスは存在しないからです。shuo さん
質問の趣旨がよくわからないので、こちらで強引な予想を立ててみました。
以下のような意味でしょうか？達成したいこと
WordPress プラグインのうち、All-in-One WP Migration プラグインと WebP Converter for Media プラグインのインストールに失敗する。
他の WordPress プラグインはインストールできる。質問者が予想した解決する方法
wp-contents ディレクトリのユーザーおよびグループ権限を kusanagi:www から httpd:www に変更すれば良い。
その手順が知りたい。予想した経緯
1.WordPress プラグインのうち、ディレクトリやファイル書き込み権限があるものが動作しない。
タイトルでは WP プラグインのインストールに失敗すると言っていますが、後からの情報だと一部のプラグインと内容が変わっている。2.kusanagi-php コンテナ内の DocumentRoot ディレクトリの配下が kusanagi:www ユーザー権限になっている。昔は httpd:www ユーザーだったはず。
パーミッションと言われているが、ユーザーとグループの権限の話をしている。3.wp-contents/uploads が問題ないのは、パーミッションが 0770 に設定されているから。
shuo さん
WP管理画面からプラグインをインストールする時、以下のエラーが出ました。
All-in-One WP Migration は /home/kusanagi/abc.test.com/DocumentRoot/wp-content/ai1wm-backups フォルダーを作成できません。All-in-One WP Migration プラグインが正しく機能するには、このフォルダーを作成して読み取り/書き込み/実行権限 (0777) を与える必要があります。こちらはエラーにある通り All-in-One WP Migration プラグインのインストール方法の問題になります。
KUSANAGI RoD の問題ではございませんので、All-in-One WP Migration のインストール方法で検索してみてください。私のテスト環境と内容は以下のとおりです。
* KUSANAGI RoD 1.3.7
* Ubuntu 20.04.5 LTS / Vagrantvagrant@ubuntu-focal:~/media.test.com/contents/DocumentRoot$ ls -la
total 236
drwxr-x— 5 vagrant vagrant 4096 Nov 15 03:03 .
drwxr-xr-x 6 vagrant vagrant 4096 Nov 15 03:03 ..
-rw-r–r– 1 vagrant vagrant 405 Nov 15 03:02 index.php
-rw-r–r– 1 vagrant vagrant 19915 Nov 15 03:02 license.txt
-rw-r–r– 1 vagrant vagrant 7389 Nov 15 03:02 readme.html
-rw-r–r– 1 vagrant vagrant 7205 Nov 15 03:02 wp-activate.php
drwxr-xr-x 9 vagrant vagrant 4096 Nov 15 03:02 wp-admin
-rw-r–r– 1 vagrant vagrant 351 Nov 15 03:02 wp-blog-header.php
-rw-r–r– 1 vagrant vagrant 2338 Nov 15 03:02 wp-comments-post.php
-rw-r–r– 1 vagrant vagrant 3001 Nov 15 03:02 wp-config-sample.php
drwxr-x— 9 vagrant vagrant 4096 Nov 15 03:03 wp-content
-rw-r–r– 1 vagrant vagrant 5543 Nov 15 03:02 wp-cron.php
drwxr-xr-x 27 vagrant vagrant 16384 Nov 15 03:02 wp-includes
-rw-r–r– 1 vagrant vagrant 2494 Nov 15 03:02 wp-links-opml.php
-rw-r–r– 1 vagrant vagrant 3985 Nov 15 03:02 wp-load.php
-rw-r–r– 1 vagrant vagrant 49135 Nov 15 03:02 wp-login.php
-rw-r–r– 1 vagrant vagrant 8522 Nov 15 03:02 wp-mail.php
-rw-r–r– 1 vagrant vagrant 24587 Nov 15 03:02 wp-settings.php
-rw-r–r– 1 vagrant vagrant 34350 Nov 15 03:02 wp-signup.php
-rw-r–r– 1 vagrant vagrant 4914 Nov 15 03:02 wp-trackback.php
-rw-r–r– 1 vagrant vagrant 3236 Nov 15 03:02 xmlrpc.phpvagrant@ubuntu-focal:~/media.test.com/contents/DocumentRoot$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.5 LTS
Release: 20.04
Codename: focal
vagrant@ubuntu-focal:~/media.test.com/contents/DocumentRoot$ docker version
Client: Docker Engine – Community
Version: 20.10.21
API version: 1.41
Go version: go1.18.7
Git commit: baeda1f
Built: Tue Oct 25 18:02:21 2022
OS/Arch: linux/amd64
Context: default
Experimental: trueServer: Docker Engine – Community
Engine:
Version: 20.10.21
API version: 1.41 (minimum version 1.12)
Go version: go1.18.7
Git commit: 3056208
Built: Tue Oct 25 18:00:04 2022
OS/Arch: linux/amd64
Experimental: false
containerd:
Version: 1.6.9
GitCommit: 1c90a442489720eec95342e1789ee8a5e1b9536f
runc:
Version: 1.1.4
GitCommit: v1.1.4-0-g5fd4c4d
docker-init:
Version: 0.19.0
GitCommit: de40ad0
vagrant@ubuntu-focal:~/media.test.com/contents/DocumentRoot$ docker-compose version
Docker Compose version v2.12.2
vagrant@ubuntu-focal:~/media.test.com/contents/DocumentRoot$ kusanagi-docker –version
1.3.7
INFO: Done.shuo さん、こんにちは。
ためしに kusanagi-docker 新規環境を作成して WordPress プラグインをインストールしてみました。
管理画面およびkusanagi-docker wpコマンドどちらからもインストールは可能でした。> 原因はフォルダのパーミンションのようですが、確認すると wp-contentやその中のフォルダの所有者がkusanagiになっています。
上記は関係ないように思います。判断した根拠はなんですか？
shuo さん、こんにちは。
トップページに書いてあるとおり、KUSANAGI の環境などの情報を添付していただけないでしょうか？
> あなたのKUSANAGI環境に関するすべての情報について、できる限り詳細に記載しましょう。
> 例えば、kusanagi statusした時の実行環境、KUSANAGIの正確なバージョンなど、コマンドで取得できる情報を正確に記述しましょう。また、今回の問題に対し解決のために調べた内容があれば教えてください。
yagi さん、こんにちは。
まずはトップページに書かれている事項をお読みください。
1. 公式サイトやドキュメント、FAQ の確認をお願いします。
2. できるだけ kusanagi status の情報を添付してください。今回の件は FAQ に書かれていると思います。
uppie123 さん、こんにちは。
返信内容を確認いたしました。
「エンジニアとして初心者」であるということですね。結論から、FTP 接続はやめたほうがいいです。
SFTP を使えないか改めてよく検討してください。
理由はセキュリティリスクの増大です。これは想像以上のリスクです。KUSANAGI では、セキュリティに関しても重要な位置づけで設計されております。
返信内容を見ると「通販サイトをしているため」と書かれていますが、個人情報を扱うことになると思われるので優先すべきはセキュリティです。
開発費や工数では済まないレベルのリスクを負う可能性があります。それでもどうしても FTP の設定をしたいということであれば、CentOS 7 の設定方法が使えますのでネットで検索し参考にしてみてください。
KUSANAGI では推奨されないものを導入するので、内容を1項目ずつ確認と検討をしてください。* 情報セキュリティにおける CIA の3要素や7要素を理解している
* 認証と認可の意味を理解している
* 盗聴、改ざん、なりすまし、否認のリスクについて理解している
* FTP / FTPS / SFTP 各プロトコルの違いを理解している
* ネットワーク経路の VPN や専用線について理解し検討ができる
* IPv4/v6 アドレス及びサブネットマスクを理解している
* FTP サーバーのインストール方法が分かる
* ポート開放方法とアクセス制限方法とそのリスクが分かる
* ユーザーのアクセス権限範囲の指定方法が分かる
* FTP サーバーのログの保存場所及び確認方法が分かる
* 導入した FTP サーバーの適切な運用や脆弱性情報を確認する方法が分かるよく理解できない項目があれば、こちらは KUSANAGI に関することではない一般的な内容なので、それぞれ調べてみてください。
もちろん、上記内容を完璧に対応しても大きなセキュリティリスクは残ったままです。私は一切責任持てません。熟練のエンジニアであれば、まず FTP を選択することがありません。
例外として、以前はインターネットから隔離された社内のシステム連携でセキュリティの低いプロトコルの採用を考えることもありました。
近年ではそれすらもゼロトラストという考え方が重要になってきて、自分以外の端末やシステムは社内のものでも信用しない設計へと移行しつつあります。私は「セキュアな方法」があるのであれば、技術的な提案やリスクを伝えるのもエンジニアの重要な仕事だと考えております。
ご要望の回答とは違うとは思いますが、上記を踏まえたうえで回答内容にご理解いただけますと幸いです。uppie123 さん、こんにちは。
お伺いいたします。
1. KUSANAGI 9 がリリースされています。KUSANAGI 8 を選ぶ理由は何でしょう？
2. SFTP 接続ではダメな理由は何でしょう？
3. 「FTP接続の設定を調べてもわからず」とありますが、具体的に何を調べたのでしょうか？
matsubarah さん、こんにちは。
kusanagi-docker provisionでは自己証明 TLS/SSL 証明書のみを使用します。
そのため通常ブラウザでご確認いただくと、TLS/SSL 証明書エラーが発生します。別途有効な TLS/SSL 証明書をご用意頂き、
kusanagi-docker ssl –cert file –key file
コマンドで TLS/SSL 証明書を登録してみてください。
—
KUSANAGI Runs on Docker
この中で kusanagi-docker ssl コマンド を確認ください。
domainky さん、こんにちは。
kusanagi setting コマンドでは、内部で wp-cli を利用している箇所があります。
該当の Warning 表示は、 wp-cli 側が表示しているものです。
主にプラグイン側が原因で発生する Warning のようですので、Warning に対し正確なお答えはできません。参考までに、似たような Warning を質問をされている外部リンクを貼ります。
https://wordpress.org/support/topic/errors-during-wp-search-replace/また、書かれていた “Warning: Skipping an uninitialized class” で検索すると、他にも似たような内容がヒットしますので、合わせて確認してみてください。
sasagar さん、こんにちは。
KUSANAGI 9、PHP 8.0 ですね。
頂いた情報を知見のあるものに確認してもらい、助言をいただきました。KUSANAGI では opcache を無効にするより、JIT のオプションを変更することを推奨します。
あるいは JIT を無効にすることを推奨します。JIT オプションの変更例 PHP8.0
opcache.jit=1255これまでの実績で WordPress では opcache に比べて JIT の効果が薄いようです。
opcache を無効にすることによるパフォーマンス低下の方が JIT を無効にすることによるパフォーマンス向上を上回ります。[参考記事]
JIT segmentation fault in PHP 8.1 #7817
https://github.com/php/php-src/issues/7817#issuecomment-1084708354PHP 8: How to setup the JIT
https://stitcher.io/blog/php-8-jit-setupPHP 公式ドキュメント: 実行時設定
https://www.php.net/manual/ja/opcache.configuration.php#ini.opcache.jitcollne さん、こんにちは。
いただきたかったログは、実際にエラーが発生していたコード部分のエラーログが、改修適用前後でどう変わったかだったのですが…
客観的なエビデンスはいただけませんでしたので確認はできませんでしたが、解決したということで承知しました。—
私の場合、作業前と作業後のログを取得して、該当エラー部分に問題がなくなったことを客観的な事実として提示しつつ、結論として問題がなくなったと説明するようにしております。
(厳密には該当以外の部分にも影響がない点も確認する必要もありますが、話の主旨がずれますので割愛します。)
この提示方法のメリットは、検証方法や結論の導き方にに間違っている場合や不足がある場合、有識者に指摘いただけることがあるためです。
また、解決策を提示してくれた方自身が、客観的な事実から想定していた動作を確認することもできるためです。Vagrant で MariaDB 10.1 の古い環境からアップデートを試した結果を残します。
`
# MariaDB を無視して、順番にアップデート
yum update kusanagi –enablerepo=remi,remi-php56 –disablerepo=mariadb
yum update –enablerepo=remi,remi-php56 –disablerepo=mariadb# MariaDB をアップグレード
# MariaDB をアップグレードをしないと、yum update でエラーは出続けます。
kusanagi upgrade mariadb 10.5# MariaDB をアップデート後は、通常の yum update でエラーは出なくなります。
yum update kusanagi
yum update –enablerepo=remi,remi-php56
`
