さくらの 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 サポートに取り組んでみようかという気になっている。