LoginSignup
0
3

More than 5 years have passed since last update.

@yamazaki(yamazaki)

KUSANAGI on ConoHa セットアップ #2 KUSANAGI&WordPress設定編

Last updated at Posted at 2017-08-20

前回の投稿(KUSANAGI on ConoHa セットアップ #1 サーバー設定編)で、サーバー側の設定が完了したので、いよいよKUSANAGIでWordPressのプロビジョニングに入る。

基本的には、KUSANAGIの公式サイトの通りに操作すれば良さそう。

KUSANAGIの初期化

公式マニュアルを読んで、ひと項目ずつ、オプションを指定して実行していくのかと思ったら、一度のコマンド実行で対話式で処理を進める格好だったw。

つまり、一度にオプションを複数指定しても良いし、何もオプションを指定せずに、kusanagi initと打つだけでも良い。あとは、必要な項目ごとに対話形式で設定ができるという流れ。

ということで、マニュアルを一通り読んで、まずはサーバーのタイムゾーンの設定を確認して、どのように設定されるか順を追って見ていこうとしたが...　意味なし。

$ date
Sat Aug 19 13:59:42 JST 2017

$ strings /etc/localtime 
TZif2
TZif2
JST-9

以下のコマンドを実行したら、あとは、コマンドから戻ってくる質問の答える形で順次処理が進み、あっという間に初期設定が完了。

# kusanagi init --tz tokyo

Checking KUSANAGI Version.
KUSANAGI is already latest version.
Generating 2048bit DHE key for security
Generating DH parameters, 2048 bit long safe prime, generator 2
This is going to take a long time
......................+..................
(snip)
..........+........................++*++*
Finish.
Checking certbot-auto update.
certbot 0.17.0

kusanagi initコマンドを初めてサーバー上で実行すると、初回は、「TLS用ホスト鍵ファイル」というのが作成される模様。

公式ドキュメントには以下のように記載がある。

TLSセッションチケットファイル、DH(Diffie-Hellman)鍵交換で使用するパラメータファイルを生成します。
これらのファイルは /etc/kusanagi.d/ssl 下に生成され、すでに生成しているときは再生成しません。
マシンの性能によっては、このファイル生成に数分かかることがありますので、ご注意ください。
cf. KUSANAGIの初期設定 – KUSANAGI

細かい内容はよくわからないが、Let's EncryptのSSLの鍵関連に必要なファイルということでしょう。まぁ、そンな感じ。

以下は、全て一度のコマンド実行で対話形式で設定していく内容だけれど、今後の参考に、何をどのように処理していくのかを僕なりの解釈で解説しながら書き残しておく。

Applying Location: Asia/Tokyo.

これは、オプションを指定していなければ、対話形式で聞かれるんだろうけど、kusanagi initコマンドを実行した際に、オプション指定したので、それがそのまま適用された。

次は、言語選択。

Select your using language.

1 : English
2 : 日本語

q : quit

Which are you using?: 2

You choose: Japanese

2の日本語を指定。
次は、キーボードのレイアウト... 

Select your keyboard layout.

1 : English
2 : Japanese

q : quit

2

You choose: Japanese

まぁ、日本語かなぁということで、2のJapaneseを選択。
なんで、こんな情報が必要なんでしょうね...

で、次が、kusanagiユーザーのパスワード設定。

kusanagi user password using in software update.

Changing password for user kusanagi.
New password: 
Retype new password: 
passwd: all authentication tokens updated successfully.

パスワードのあとは、同じkusanagiユーザーのSSHの鍵生成。

Generating public/private rsa key pair.
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /root/kusanagi.pem.
Your public key has been saved in /root/kusanagi.pem.pub.
The key fingerprint is:
xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx root@host.example.com
The key's randomart image is:
+--[ RSA 2048]----+
|                 |
|             .   |
(snip)
|          o.  o  |
+-----------------+
/root/kusanagi.pem.pub is moved to /home/kusanagi/.ssh/authorized_keys.
/home/{new_user}/.ssh/authorized_keys is added to /home/kusanagi/.ssh/authorized_keys.
/root/kusanagi.pem is moved to /home/{new_user}/kusanagi.pem.

kusanagiユーザーの鍵生成以外に、リモートからkusanagiユーザーでログインする際の認証済み鍵authorized_keysの編集も行われる。

具体的には、kusanagi initを実行したユーザー(本作業用に新規作成した{new_user})で許可している鍵authorized_keysが、丸っとkusanagiユーザーのauthorized_keysにコピーされる。

なので、ローカルから{new_user}でログインする時と同じ鍵で、kusanagiユーザーでログインできる。

次は、MySQLのrootパスワードの設定。

Enter MySQL root password. Use [a-zA-Z0-9.!#%+_-] 8 characters minimum.
Re-type MySQL root password.
Password has changed.
Change MySQL root password.

次は、KUSANAGIの環境設定。

KUSANAGI can choose middlewares.
Please tell me your web server option.
1) NGINX(Default)
2) Apache

Which you using?(1):1

You choose: NGINX
use nginx
Done.

ウェブサーバーは、初期設定のNginx。
次は、PHPのエンジン／バージョンの選択。

Then, Please tell me your application server option.
1) HHVM(Default)
2) PHP7
3) PHP5

Which you using?(1):1

You choose: HHVM
use hhvm
Done.

とりあえずは、初期設定のHHVMだけれど、PHP7のサポートが少し前のバージョンかららしいのが、若干不安。近い内に、このサーバーは、WordPressのホストだけではなく、Laravelのアプリも動作させたいと思っているので、うまく動かないことが出てくれば、PHP7系にする。

で、最後に以下のように、サーバーのスペックに合わせたMySQLのパラメータの設定結果と、monitの設定状況がが表示される。

innodb_buffer_pool_size = 384M
query_cache_size = 128M
monit is already on. Nothing to do.

KUSANAGI initialization completed
Done.

最後の2行が表示されていれば正常にセットアップは完了。

おまけ(monitでは何しているの？)

monitについては、/etc/monit.dあたりのファイルを見て、なんとなく設定を把握しておくと良さそう。

プロビジョニングを実行すると、プロビジョンごと(プロビジョン名ごと)に設定ファイルが作成させるようなので、/etc/monit.d/{prosivion_profile_name}_nginx.confを覗くと以下のように設定されていた。

check file {prosivion_profile_name}_nginx with path /home/kusanagi/{prosivion_profile_name}/log/nginx/access.log
        restart program = "/bin/kusanagi restart"
        depends on nginx
        if match '"(GET|POST) /.* HTTP/.*" 5[0-9][0-9] [0-9]+ ' for 2 cycle then restart
        if 5 restarts within 5 cycles then alert
        if 5 restarts within 5 cycles then unmonitor
        group nginx

check file {prosivion_profile_name}_nginx_ssl with path /home/kusanagi/{prosivion_profile_name}/log/nginx/ssl_access.log
        restart program = "/bin/kusanagi restart"
        depends on nginx
        if match '"(GET|POST) /.* HTTP/.*" 5[0-9][0-9] [0-9]+ ' for 2 cycle then restart
        if 5 restarts within 5 cycles then alert
        if 5 restarts within 5 cycles then unmonitor
        group nginx

どうやらウェブサーバで500系のエラーが2回発生するとミドルウェアを自動で再起動してくれ、それが5回続くとアラートメールを飛ばす、らしい。アラートメールは、初期設定では、サーバーのroot宛にメッセージが飛んでくる。

後からGoogle検索してみたら公式のブログに解説エントリーが出ていたw

WordPressのプロビジョニング

KUSANAGIの初期設定が完了したので、次は、WordPressのプロビジョニング。

これも、KUSANAGIの初期設定と同様に、コマンド一回で後は対話形式で設定をしていけばOK
操作の前に一通り、公式のマニュアルには目を通しておく。

kusanagiコマンドのサブコマンドにprovisionを指定して、後は、各種はファイルが配置されるディレクトリ名になるプロファイル名{prosivion_profile_name}をパラメータで指定して、実行。

# kusanagi provision {prosivion_profile_name}
Target directory is /home/kusanagi/{prosivion_profile_name}.

プロビジョニングにより作成される/home/kusanagi/{prosivion_profile_name}ディレクトリには、ウェブサイトのドキュメントルートや、ウェブサーバのログなどが配置される。

プロビジョンのタイプを指定しないと、kusanagi provision --WordPress {prosivion_profile_name}と同義になり、以降は、WordPressの設定について対話形式で設定していく感じになる。

まずは、言語指定。

Choose the installation language of WordPress.
1 : en_US
2 : ja

q : quit

Which do you choose?:  2

You choose: ja

言語を日本語にすると、日本語版のWordPressでプロビジョニングされるとのこと。

次は、WordPressのサイトのアドレスを指定。

Enter hostname(fqdn) for your website. ex) kusanagi.tokyo
example.com
Re-type hostname(fqdn) for your website.
example.com

wwwは付けずに、ドメイン名そのままを指定。

上記、FQDNの指定の後は、Let's EncryptでSSLの設定。

In order to use Let's Encrypt services, you must agree to Let's Encrypt's Term of Services.
If you agree to this TOS, type your email address; if not, hit enter twice.
TOS of Let's Encrypt : https://letsencrypt.org/repository/
{your_mail_address}
Re-type mail address.
{your_mail_address}

ここで入力したメールアドレスは、緊急の通知、鍵を紛失したときの復旧、証明書の有効期限が近付いた場合の通知に使用されるらしい。

次は、WordPressで使うMySQLのDB設定。

Enter the name of your database.
{wordpress_db_name}
Re-type database name you create.
{wordpress_db_name}

Enter user name for database {wordpress_db_name}.
{wordpress_db_user}
Re-type user name for database {wordpress_db_name}
{wordpress_db_user}

Enter password for database user '{wordpress_db_user}'. USE [a-zA-Z0-9.!#%+_-] 8 characters minimum.
Re-type password for database user '{wordpress_db_user}'.

以上で、対話形式での入力は終わりで、以下は、その後、自動で処理されている時に流れる標準出力。

--2017-08-19 14:19:20--  https://ja.wordpress.org/latest-ja.tar.gz
Resolving ja.wordpress.org (ja.wordpress.org)... 66.155.40.250, 66.155.40.249
Connecting to ja.wordpress.org (ja.wordpress.org)|66.155.40.250|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 8652714 (8.3M) [application/octet-stream]
Saving to: ‘wordpress.tar.gz’

100%[==================================================================>] 8,652,714   5.58MB/s   in 1.5s   

2017-08-19 14:19:22 (5.58 MB/s) - ‘wordpress.tar.gz’ saved [8652714/8652714]

Saving debug log to /var/log/letsencrypt/letsencrypt.log
Obtaining a new certificate
Performing the following challenges:
http-01 challenge for exapmle.com
http-01 challenge for www.example.com
Using the webroot path /home/kusanagi/{prosivion_profile_name}/DocumentRoot for all unmatched domains.
Waiting for verification...
Cleaning up challenges

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/example.com/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/example.com/privkey.pem
   Your cert will expire on 2017-11-17. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot-auto
   again. To non-interactively renew *all* of your certificates, run
   "certbot-auto renew"
 - Your account credentials have been saved in your Certbot
   configuration directory at /etc/letsencrypt. You should make a
   secure backup of this folder now. This configuration directory will
   also contain certificates and private keys obtained by Certbot so
   making regular backups of this folder is ideal.
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

Enabling auto renewal certificate
Provisioning of {prosivion_profile_name} completed. Access example.com and install WordPress!
Done.
You have mail in /var/spool/mail/root

で、後は、プロビジョニングしたWordPressのアドレスにアクセスして、ブラウザからのWordPressの初期設定を行うが、その前にサーバーでできる設定をいくつか行って、その設定状態をチェックしておく。

キャッシュは、ウェブサーバーで処理するfcacheと、WordPressで行うbcacheというのがあり、とりあえず、ウェブサーバーのキャッシュだけ有効にしておく。

# kusanagi fcache
fcache は無効です
完了しました。
# kusanagi fcache on
onにします。
Nginxを使用します。
完了しました。

Let's EncryptのSSLは、3か月の有効期限なので、これを自動で更新するようにしておく。

# kusanagi autorenewal
は使用できません。
kusanagi autorenewal [on|off].
失敗しました。
# kusanagi autorenewal on
証明書の自動更新は既に有効です。何もしません。
完了しました。

現在の設定状況は確認できなかったw
が、既に、初期設定で自動更新が有効になっていたいた模様。

よくよくプロビジョニングの処理結果のメッセージを見ると以下のように出力されていた。

Enabling auto renewal certificate

で、KUSANAGIの状態をチェック。

# kusanagi status
Profile: {prosivion_profile_name}
Type: WordPress
KUSANAGI Version 8.0.7-4
conoha

*** nginx ***
● nginx.service - The NGINX HTTP and reverse proxy server
   Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; vendor preset: disabled)
   Active: active (running) since 日 2017-08-20 16:48:57 JST; 3min 33s ago

*** Apache2 ***
● httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled; vendor preset: disabled)
   Active: inactive (dead)

*** HHVM ***
● hhvm.service - HHVM virtual machine, runtime, and JIT for the PHP language
   Loaded: loaded (/etc/systemd/system/hhvm.service; enabled; vendor preset: disabled)
   Active: active (running) since 土 2017-08-19 14:19:32 JST; 1 day 2h ago

*** php-fpm ***
● php-fpm.service - The PHP FastCGI Process Manager
   Loaded: loaded (/usr/lib/systemd/system/php-fpm.service; disabled; vendor preset: disabled)
   Active: inactive (dead)

*** php7-fpm ***
● php7-fpm.service - The PHP FastCGI Process Manager
   Loaded: loaded (/usr/lib/systemd/system/php7-fpm.service; disabled; vendor preset: disabled)
   Active: inactive (dead)

*** Cache Status ***

fcache on
bcache off
完了しました。

後、もう一つ、常に、HTTPSにリダイレクトするように設定。

# kusanagi https redirect
example.com 上のすべてのトラフィックを永久的にHTTPSにリダイレクトするよう設定します。
完了しました。
# kusanagi nginx
Nginxを使用します。
完了しました。

WordPressの初期設定

ブラウザで、https://example.com/ にアクセスすると、WordPressのインストールの初期画面が表示されるので、kusanagi provisionで作成したDB名など必要事項を入力して、完了。

キャプチャ撮るのを忘れたので、細かいことは公式ドキュメントを要参照。

セキュアな設定

公式サイトに書かれている、よりセキュアな設定とやらを実施。

wp-config.phpの移動

ドキュメントルートにあるWordPressの設定ファイルをプロファイルのルートディレクトリ(/home/kusanagi/{prosivion_profile_name}/)直下に移動。

# cd /home/kusanagi/{prosivion_profile_name}/DocumentRoot/
# mv ./wp-config.php ../

ここで疑問に思ったのは、WordPressの設定は不要なの？ということだが、おそらく、WordPressのプログラム側は、よしなに、ドキュメントルートか、一つ上位階層のwp-config.phpを見るようになっているのでしょう。(たぶん)

管理画面へのアクセス権限

後、1つ、管理画面へのアクセス制限については、少し癖があるというか、どういうことなのか内容を理解した方が良いので軽く解説。

公式のドキュメントは、ざっくりの説明で詳細は省略されている。

具体的には、ウェブサーバの設定を見ると、アクセス権限にあたり、「IPによる制限」と、「Basic認証」の混合で制御されているという点で、以下のパターンで制御されてる。

  1. IPが許可されていれば、Basic認証は不要
  2. 許可されているIPでなければ、Basic認証が必要

といった具合。

設定ファイルを見ると、対象ファイルおよびディレクトリに対して、Satisfy anyが指定されていて、これが、上記のような「どちらかで許可されればOK」という制御に繋がっている。

/home/kusanagi/{prosivion_profile_name}/DocumentRoot/.htaccess
<Files wp-login.php>
    Order deny,allow
    Deny from all
    #Allow from all
    #Allow from 127.0.0.1
    AuthType Basic
    AuthName "ENTER YOUR NAME & PASSWORD TO LOGIN"
    AuthUserFile /home/kusanagi/.htpasswd
    Require valid-user
    Satisfy any
</Files>

上記、wp-login.phpも、下記、wp-admin/ディレクトリのどちらもどこからのアクセスも許可になっていたので、これを無効にして、Basic認証ありきにした。

/home/kusanagi/{prosivion_profile_name}/DocumentRoot/wp-admin/.htaccess
Order deny,allow
Deny from all
#Allow from all
#Allow from 127.0.0.1
AuthType Basic
AuthName "ENTER YOUR NAME & PASSWORD TO LOGIN"
AuthUserFile /home/kusanagi/.htpasswd
Require valid-user
Satisfy any

nginxの設定も、ほぼ同様。

/etc/nginx/conf.d/{prosivion_profile_name}_ssl.conf
location ~* /wp-login\.php|/wp-admin/((?!admin-ajax\.php).)*$ {
    satisfy any;
    #allow 0.0.0.0/0;
    #allow 127.0.0.1;
    deny all;
    auth_basic "basic authentication";
    auth_basic_user_file  "/home/kusanagi/.htpasswd";

(--- snip ---)

{prosivion_profile_name}_ssl.confだけでなく、{prosivion_profile_name}_http.confにも同じ設定があったが、後者は割愛。

この設定をしている際に、初回、nginx側の設定を行って、kusanagi nginxでサービス再起動して、動作確認を行った。が、前述の.htaccessはまだ編集していなかったため、Allow from allの記述が残っていたのに、Basic認証が必要だった... つまり、nginxのサーバー側では、いかなるIPも不許可にして、Basic認証が必要としていたが、.htaccessでは、どのIPでもOKとしていたため矛盾が...

nginxは、.htaccessよりもサーバー側の設定が優先されるの？
(なんか解せないが、調査は面倒なので割愛w)

ファイルやディレクトリの所有者やパーミッションの設定

そのほか、ファイルやディレクトリの所有者やパーミッションの設定を2,3やった。これについては、公式の案内通りで迷うこともないので詳細な手順は割愛。

一通り終わり

ということで、とりあえず、主なセキュリティ的な考慮点を反映してKUSANAGI on ConoHaをセットアップして、WordPressのサイトを立てるところまでが完了。

この後は、細かいサーバーのカスタマイズと、WordPressでサイトを構築するためのエトセトラが残っているけれど、そちらは追々。

0
3
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
3