さくらの VPS のお試し期間は， 12/2 までだったのだが，まだやりたいことを残しているので，続けて使っている。月払いで，しばらく続けてみるつもりである。
今回は，「WordPress のインストール」について書く。試される場合は，当然ながら，前もって，初めての VPS #1 ，初めての VPS #2 ，初めての VPS #3 は完了していないといけないです。まずは Wheel Group User （うちの場合は centos ）として―言い換えると root 権限のユーザということ―インストールする。
注）||SELinux と WordPress|| （httpd_selinux(8) 参照）
- ダッシュボードからプラグインをインストールしようとしたら，「FTP サーバー VPS_DomainName への接続に失敗しました」が出た。 Http デーモンがネットワークにアクセスできないせいらしい。解決策は， “httpd_can_network_connect –> on”。
$ sudo setsebool -P httpd_can_network_connect on
- ダッシュボードからメディアファイルをアップロードしようとしたら，「ディレクトリ wp-content/uploads/year/date を作成できませんでした。この親ディレクトリのアクセス権はサーバーによる書き込みを許可していますか？」が出た。親ディレクトリのパーミッションは 707 だったんだけとさ。 Httpd デーモンが context のせいで，ディレクトリの読み書きができないらしい。 context を ‘httpd_user_content_t’ から ‘httpd_sys_rw_content_t’ に変えたら，できるようになった。しかし，別の問題が発生。 FTP クライアントから見えない。メディアファイルに関しても FTP クライアント経由でバックアップすることが多い私には，これは問題である。
解決策を探してみた。
context を ‘httpd_sys_rw_content_t’ ではなく， ‘public_content_rw_t’ にする。メディアをアップロードするためには， ‘httpd_anon_write –> on’ も必要だった。
$ sudo setsebool -P httpd_anon_write on
$ sudo semanage fcontext -a -t public_content_rw_t
"/path/to/wp-content/uploads(/.*)?"
$ sudo /sbin/restorecon -RF /path/to/wp-content/uploads
参考 URL: 5.7.2. 永続的な変更: semanage fcontext
上記には ‘restorecon -R’ で変更可能にと書いてあるのだが，なんでだか ‘restorecon -RF’ と F（force）を付けないとうまくいかなかった。
||Wheel Group User として WordPress をインストール||
- phpMyAdmin に root としてログイン。
- WordPress 用の database (wordpressdb とか) を照合順序 ‘utf8_general_ci’ で作成する。
- WordPress 用の user (wordpressuser とか) を localhost かつ passphrase ありで作成する。
GRANT USAGE ON *.* TO wordpressuser@localhost IDENTIFIED BY PASSWORD ‘passphrase’;
特権を編集する。データベース ‘wordpressdb’ について GRANT 以外のすべての特権を与える。グローバル特権は一切付与しないことに注意!!
GRANT ALL PRIVILEGES ON wordpressdb.* TO wordpressuser@localhost;
- ログアウト
——————–
- VPS に SSH 経由で centos としてログオン。直後は， /home/centos にいるはず。
- $
mkdir tmp
$ chmod 707 tmp
tmp はダウンロードファイル用である。
- $
cd tmp
‘wget’ が入っていない場合は，下記でインストール。
$ sudo yum install wget
WordPress をダウンロードし，解凍後当該個所にコピーする。
$ wget https://ja.wordpress.org/wordpress-4.0-ja.tar.gz
$ tar xzvf wordpress-4.0-ja.tar.gz
$ rsync -avP ~/tmp/wordpress/ ~/www/html/wp/
- uploads フォルダを作成。
$ mkdir ~/www/html/wp/wp-content/uploads
$ chmod 707 uploads
context type を変更する。
$ sudo semanage fcontext -a -t public_content_rw_t
"/home/centos/www/html/wp/wp-content/uploads(/.*)?"
$ sudo /sbin/restorecon -RF /home/centos/www/html/wp/wp-content/uploads
——————–
- ブラウザから， http://VPS_DomainName/wp/ にアクセスする。
- ブラウザからのインストール時， wp-config.php が自動生成されないので，表示される情報をもとに，テキストエディタで作成し， FTP クライアントでアップロードして，パーミッションを 404 にする。
それ以外は，順当に進む。
注）WordPress が FTP account 情報を自動取得できないようで，アップテートやプラグインインストール時に，一々入れてやらないといけないので， wp-config.php の /* 編集が必要なのはここまでです ! WordPress でブログをお楽しみください。 */ より前に下記の 3 行を追加した。
参考 URL: WordPress Upgrade Constants
define('FTP_USER', 'username');
define('FTP_PASS', 'password');
define('FTP_HOST', 'VPS_DomainName');
この時点で， PHP は DSO (Apache 2.0 Handler) で動いている。で，上の手順後，大部分の WordPress のファイルのオーナー/グループは ‘centos:centos’ になっているが，ダッシュボードからアップロードしたメディアファイルだけは， ‘apache:apache’ である。このせいで， FTP クライアントから，メディアファイルの編集ができない。バックアップはできるんだが。まあ， ‘centos‘ としてなら， SSH 経由で ‘chown’ が使えるけどね。
このことは，一般ユーザの場合に，より問題となると思う。続いて，一般ユーザとして，インストールする話を書く。
||一般ユーザとして WordPress をインストール||
当然ながら，サーバサイドの作業は，一般ユーザではできない。 centos として行う。
[サーバサイド]——
- centos として， SSH 経由で VPS にログインし，一般ユーザを作成。
$ sudo adduser normuser1
$ sudo passwd normuser1
Changing password for user normuser1.
New password:
Retype new password:
$ sudo chmod 701 /home/normuser1
- /etc/httpd/conf.d/userdir.conf を編集する。
$ sudo vi /etc/httpd/conf.d/userdir.conf 参考 URL: UserDir ディレクティブ
UserDir disabled の次行に UserDir enabled normuser1 を追加。#UserDir public_html の次行に UserDir www/html を追加。<Directory "/home/*/public_html">
—>> <Directory "/home/*/www/html">Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
—>> Options MultiViews SymLinksIfOwnerMatch IncludesNoExec
- $
su - normuser1
$ mkdir www
$ cd www
$ mkdir html
normuser1 id の属性をチェック。
$ id -a normuser1
uid=1001(normuser1) gid=1001(normuser1) groups=1001(normuser1)
$ exit
$ sudo systemctl restart httpd.service
- $
sudo gpasswd -a sennari apache
normuser1 id の属性をチェック。
$ id -a normuser1
uid=1001(normuser1) gid=1001(normuser1) groups=1001(normuser1),48(apache)
- ブラウザから root として phpMyAdmin にログイン。
WordPress 用の database (normuser1db とか) を照合順序 ‘utf8_general_ci’ で作成する。
WordPress 用の user (normuser1wp とか) を localhost かつ passphrase ありで作成する。
GRANT USAGE ON *.* TO normuser1wp@localhost IDENTIFIED BY PASSWORD ‘passphrase’;
特権を編集する。データベース ‘normuser1db’ について GRANT 以外のすべての特権を与える。グローバル特権は一切付与しないことに注意!!
GRANT ALL PRIVILEGES ON normuser1db.* TO normuser1wp@localhost;
ログアウト。
[クライアントサイド]——
- FTP クライアントで， normuser1 の DocumentRoot にアクセスする。
テストとして， index.html をアップロードしてみる。ブラウザから http://VPS_DomainName/~normuser1/ にアクセスして確認。
余談だが，この index.html に base64 encoded in-line image scheme を使ってみた (^^)。
- FTP クライアントで， DocumentRoot に wp フォルダを作成。
解凍した WordPress のファイルを wp に FTP 経由でアップロード。
- ブラウザで， http://VPS_DomainName/~normuser1/wp/ にアクセスし， WordPress のインストールを続ける。
ブラウザからのインストール時， wp-config.php が自動生成されないので，表示される情報をもとに，テキストエディタで作成し， FTP クライアントでアップロードして，パーミッションを 404 にする。それ以外は，順当に進んだ。
注）WordPress が FTP account 情報を自動取得できないようで，アップデートやプラグインインストール時に，一々入れてやらないといけないので， wp-config.php の /* 編集が必要なのはここまでです ! WordPress でブログをお楽しみください。 */ より前に下記の 3 行を追加した。
参考 URL: WordPress Upgrade Constants
define('FTP_USER', 'username');
define('FTP_PASS', 'password');
define('FTP_HOST', 'VPS_DomainName');
上記終了後， WordPress 4.0 を 4.1 にアップグレードした。問題なし。ところが， uploads フォルダは作成済みでパーミッションを 707 にしてあったにも関わらず，メディアのアップロードができなかった。そんなわけで，下記のような手直しをした。
- FTP クライアントで， uploads フォルダのパーミッションを 775 に変更。どうやら， Http デーモンがここにフルアクセスできないといけないようなので。
- 以下の 3 つは centos として SSH 経由でやった。これらは，一般ユーザの権限ではやれない。そんなわけで，複数ユーザのサイトを運営する場合，この件はとても不便ではないかと思った。何しろ， ‘fcontext -a -t’ 以外は uploads フォルダ作成後でないとできなかったから。
- $
sudo chown -R normuser1:apache
/home/normuser1/www/html/wp/wp-content/uploads
- $
sudo semanage fcontext -a -t public_content_rw_t
"/home/normuser1/www/html/wp/wp-content/uploads(/.*)?"
- $
sudo restorecon -RF /home/sennari/www/html/wp/wp-content/uploads
さて，いまひとつの疑問がある。どうして WordPress は upgrades と メディアアップロードで違う方法をとっているのだろうか。メディアについても upgrades と同じ方法でやってくれれば，こんなことは起こらないと思うのに。 PHP に詳しくないのでよくわからないが，おんなじ方法を使うとなんかまずいことがあるんかいな？
そんなこんなで， suEXEC サポートに取り組んでみようかという気になっている。
