本サイトではアフィリエイト広告を利用しています

PC-UNIX WordPress 設定

WordPress の更新で FTP のアクセス情報を聞かれたら?

よくある小ネタになります。WordPress を自前でダウンロードして設定までしなくてはならないサーバーや、自前のテスト環境で試しているときによく出くわすエラーの対処法です。

今回のミッション

  • WordPress ファイル更新時に FTP 情報入力云々のウザさを解消する

ワードプレス更新エラー
実はこのエラーもどきは、よく起こりますので対処法を知っておくと何かと楽できます。

WordPress で FTP 情報を問われることを避ける方法

WordPress をインストールしたディレクトリ:/srv/www/htdocs/wordpress
  1. ディレクトリのパーミッションを緩める
  2. ディレクトリの所有者を見直す
  3. wp-config.php オプションで処理する

が思いつきます。このうち、誰でも素人でもできる方法が1番の方法です。ディレクトリのパーミッションを緩める方法で、具体的には書き込み権限をつけます。

ディレクトリのパーミッションを緩めて解消

WordPress が置かれたディリクトリに書き込みパーミッションをつけます。

ただし、suid ビットが立ったスクリプトを送り込まれたりなど、様々な悪さされるリスクがあるので、サーバー管理者は嫌がる方法です。一方、簡単に誰でもできるため、解決方法としてはもっとも楽な手段です。作業は root で行っています。

 bash
# cd /srv/www/htdocs/wordpress
# find . -type d -exec chmod 755 {} +
# find . -type f -exec chmod 644 {} +

ディレクトリに書き込みパーミッションをつけました。
755 は所有者は書き込み・読み込み・実行可能、それ以外は読み込み・実行が可能。
644 は所有者は書き込み・読み込み、それ以外は読み込みが可能。
ちなみに
400 は所有者だけが読み込みできるパーミッションになります。

上のコマンドは、wordpress 以下のディレクトリとファイルには所有者書き込みの権限をつける指示です。主に php ファイルは実行ファイルではないので、セキュリティ的な理由で実行権限を外しています。

乱暴ですが、

 bash
# cd /srv/www/htdocs/wordpress
# chmod -R 777 *

として、フルアクセスを許可して、エラーが解消されるかどうかまず確認する手があります。

私見ですが、Cygwin で apache をテストしているような環境の場合は、この方法で十分だと思います。理由は、Windows エクスプローラなどから直接ファイルを書き換えたり、パラメーターを触ったりすることが頻発するため、セキュリティ緩めの方が扱いやすいというメリットがあります。

WordPress のテーマやプラグイン等の更新に問題が無ければ(上の FTP 情報を問われなければ)、

 bash
# cd /srv/www/htdocs/wordpress
# find . -type d -exec chmod 700 {} +
# find . -type f -exec chmod 600 {} +

としても問題ないか確認してみましょう。動かなければ、700 のところを 755 に、600 のところを 644 にして試してみます。

 bash
# cd /srv/www/htdocs/wordpress
# chmod 400 wp-config.php

として、wp-config.php が不用意に書き換わることを防止しておきます。

ディレクトリの所有者を見直して解消

上の書き込みパーミッションを見直して、まだ解消されないケースは、ディレクトリとファイルの所有者が意図しないユーザーになっていることがあります。
私のようなズボラなタイプの人は、コマンドを少しでも横着しようと root でログイン、ファイルのダウンロード、設定、実行とヤバいことをやりがちです。
例えば、root でダウンロードしたファイルを解凍して、新たにディレクトリができるような場合、そのディレクトリには apache などのプログラムがアクセスできないことがよくあります。それは、ディレクトリの所有者のみが実行、閲覧、書き込みが許可されるディレクトリを作成してしまったケースです。

この手のケースでは、パーミッション自体は適切に設定されていて問題が無いケースが大半です。何がダメかと言えば、所有者と所有グループが意図しないものになっていて、肝心の apache はその所有者でもなく、グループでもない場合はどうしようもないということになります。

つまり、所有者を apache、所有グループを apache の属するものに変更することで、理想的な(開発者が意図したような)パーミッションのまま動く可能性が高くなります。

UNIX 系のシステムで apache の UID を調べる

調べ方の一例ですが、直接ファイルから見る方法です。
スマートにやらずに、いちいち確認した方が間違いは少なく、ミスを防げます。

 bash
# grep ^User /usr/local/etc/apache24/httpd.conf
User www
# grep ^Group /usr/local/etc/apache24/httpd.conf
Group www
# grep www /etc/passwd
www:*:80:80:World Wide Web Owner:/nonexistent:/usr/sbin/nologin
# grep www /etc/group
www:*:80:

赤字の部分は、システムによって異なります。上の例は pkg で FreeBSD に apache をインストールしたシステムでの例です。
この出力から、Apache はユーザー www、グループ www で動作する設定であることがわかります。
次に、必須ではありませんが UID と GID を調べておきます。これは tar 等でファイルを固めたときに保存されるのは UID と GID ですので、別システムのファイルを解凍した際に、たまたまそれらがバッティングした場合を考えた予防です。
例では、www の UID、GID ともに 80 であることがわかりました。

FreeBSD で ディレクトリの所有者を apache に変える

先ほどのように調べなくても FreeBSD の場合は、パッケージから普通にインストールすれば apache はユーザー www、グループ www で動きます。それぞれ UID、GID は 80 と 80 になります。

 bash
# cd /srv/www/htdocs/wordpress
# ls -ln
total 220
-rw-r--r--   1 1001  1001    336 May 11 20:45 .htaccess
-rw-r--r--   1 1001  1001    405 Feb  6 13:33 index.php
-rw-r--r--   1 1001  1001  19915 Feb 12 18:54 license.txt
-rw-r--r--   1 1001  1001  10089 May  2 09:00 readme.html
-rw-r--r--   1 1001  1001   6912 Feb  6 13:33 wp-activate.php
drwxr-xr-x   9 1001  1001   2560 May  2 09:00 wp-admin
-rw-r--r--   1 1001  1001    351 Feb  6 13:33 wp-blog-header.php
-rw-r--r--   1 1001  1001   2275 Feb  6 13:33 wp-comments-post.php
-rw-r--r--   1 1001  1001   3931 May  2 09:00 wp-config-sample.php
-rw-r--r--   1 1001  1001   4111 May 11 11:31 wp-config.php
drwxr-xr-x   8 1001  1001    512 May 11 23:13 wp-content
-rw-r--r--   1 1001  1001   3940 Feb  6 13:33 wp-cron.php
drwxr-xr-x  21 1001  1001   6144 May  2 09:00 wp-includes
-rw-r--r--   1 1001  1001   2496 Feb  6 13:33 wp-links-opml.php
-rw-r--r--   1 1001  1001   3300 Feb  6 13:33 wp-load.php
-rw-r--r--   1 1001  1001  47874 Feb 10 10:50 wp-login.php
-rw-r--r--   1 1001  1001   8509 Apr 14 18:34 wp-mail.php
-rw-r--r--   1 1001  1001  19396 Apr 10 10:59 wp-settings.php
-rw-r--r--   1 1001  1001  31111 Feb  6 13:33 wp-signup.php
-rw-r--r--   1 1001  1001   4755 Feb  6 13:33 wp-trackback.php
-rw-r--r--   1 1001  1001   3133 Feb  6 13:33 xmlrpc.php

上の例では、wordpress を解凍したファイルの UID と GID が 1001 と 1001 になっています。これだと、パーミッションからして Apache がこれらのファイルとディレクトリにアクセスする際は、読み込みしかできないことがわかります。

そのため以下のような UID と GID の変更に意味があります。

 bash
# cd /srv/www/htdocs/wordpress
# chown 80:80 -R .

上の 80:80 のところはユーザーとグループで、具体的に名前で

 bash
# cd /srv/www/htdocs/wordpress
# chown www:www -R .

としても問題ありません。
これで Apache は wordpress のインストールされたディレクトリとファイルの読み込み、書き込みができるようになります。

wp-config.php オプションで処理する

デーモンの設定とディレクトリパーミッションがうまくかみ合ってさえいれば、ここまでの対応でうまく処理できるはずですが、まだ一つ試してみるべき手段として、wp-config.php のパラメーターを加える方法があります。

下のコードを付け加えます。ただし、「if ( !defined('ABSPATH') )」と始まる行よりも上の方に加える必要があります。

 
// FTP 使わずにダウンロードを強制
define('FS_METHOD', 'direct');

このパラメーターは嫌がられる設定の一つです。
更新で書き換えたようなファイルは、所有者が実行ユーザーになってしまい、所有者の変更を伴ってしまうリスクがあります。パーミッションを工夫していても、所有者を書き換えられては困ることになりかねません。
問題解決はできますが、これをわざわざ書いてくる人は、問題点のコアを追求せずに、付け焼き刃で強制してくる感じを受けますので、人様のサーバーには説明なしにやらない方が良いと思います。

ココまでの処理でなんとかなっていればミッション完了です。

ホントに最後の手段、アキラメル!FTP で接続する

セキュリティ的に問題がある方法でも、その問題に自分で対処できるのであれば、FTP 接続を積極的に認めるという最終手段があります。ミッション的には失敗になるかもしれませんが、要は面倒くささの解消がミッションだとするなら、FTP 情報をあらかじめ設定しておくことで切り抜けることはできます。

wp-config.php に接続情報を記述して、毎回の FTP 情報の入力を避けるようにします。

 
define( 'FTP_HOST', '###.###.###.###' );
define( 'FTP_USER', 'guest' );
define( 'FTP_PASS', 'password or mail address' );
define( 'FTP_SSL', false ); # SSL 接続ができるのであれば true にする

引数、パラメータの部分は適切に設定してください。
あまりスマートではありませんが、ファイルのパーミッションをしっかり設定しておけば、その範囲での穴は小さくできるはずです。
 bash
# chmod 400 wp-config.php

として、wp-config.php を所有者以外が読めないようにしておく必要があります。ココをサボるとかなりイタイ設定になりますので、動く動かないにかかわらず、しっかり設定してください。
この設定は、モロに何をやったか設定者が認識しやすい設定でもあるので、事故が起こっても対処するべき箇所が容易に特定できるのが唯一のメリットでしょうか。

-PC-UNIX, WordPress, 設定
-, , ,