HTTP/2とTLSv1.3(draft-20)をnginx+OpenSSLで対応させる

せっかくなので、当サイトはhttp2に正式対応しました。

昔やったはずじゃ・・・と思っていたのですが、

http/2と似て非なるほぼ同じSPDYの対応でした。

SPDYはいつの間にやらchromeではhttp/2扱いされなくなり(googleが作ったのに)、chrome 51から非対応となってしまいました。

ということでこのブログもhttp1.1に戻っていたので、正式にhttp/2に対応しました。
この辺は別の話なのでこの記事が詳しいです。

EC2+nginxでhttp2対応できたとおもったらできてなかった話。(解決します)

ついでに、当サイトはTLSv1.3(draft-20)に対応しました(多分)。

なお、言っておきますが 現状のブラウザでは見れません。

新しくブラウザが出たとしても見れるかもわかりません。

正直まだstandardになってないですし、仕様は変更されるでしょうし、現状ここでの対応はほぼ無意味です。

ただ、TLSv1.3が正式対応になりOpenSSL1.1.1が正式リリースした時はこの記事は役立つと思います。多分。

OpenSSLのTLS1.3実装に関しては公式が使用方法を書いています。これがとても詳しいです。
Using TLS1.3 With OpenSSL

コネクションの方法など難しいところは置いておくとして、
実際に使用するところで気になるのは暗号化スイートがTLS1.3専用のものが用意されています。

  • TLS13-AES-256-GCM-SHA384
  • TLS13-CHACHA20-POLY1305-SHA256
  • TLS13-AES-128-GCM-SHA256
  • TLS13-AES-128-CCM-8-SHA256
  • TLS13-AES-128-CCM-SHA256

OpenSSLの現在の実装でTLS1.3はこの5つしかサポートされていません。

これ以外を使用してTLSv1.3認証を行おうとすると、当然ですが認証に失敗します。

そのためTLS1.2以下と併用するためにはTLS1.3の時だけ上のスイートを優先する必要があります。

nginx+OpenSSLでのTLSv1.3対応

nginxのmailline versionの最新版1.13.0にて、"ssl_protocols" でTLSv1.3を選択できるようになりました。

*) Feature: the "TLSv1.3" parameter of the "ssl_protocols" directive.

そのため、おなじみの構成であるnginx+OpenSSLでTLSv1.3を使えるようになります(厳密にはなる予定です)。

使用するnginxは1.13.0、OpenSSLは1.1.1-dev(master)です。

OpenSSLはTLSv1.3が正式になったら1.1.1をリリースすると言っていますので、実際に正式になった時もこの設定で動くと思います。

OpenSSL1.1.1(dev)のインストール

リポジトリなどではなくgitからmasterを落としてビルドします。gccなどが必要です。

後、libssl.soが無いと怒られたりしたので/usr/local/lib64/に動的リンクを貼ったりpathを通したりして動きました。

cd /usr/local/src/
git clone https://github.com/openssl/openssl
cd openssl
./config enable-tls1_3
make
make test
make install

/usr/local/bin/openssl version
OpenSSL 1.1.1-dev  xx XXX xxxx

nginx 1.13.0のインストール

こちらはリポジトリはあるのですが、OpenSSLを組み込む関係でこちらもソースコードからビルドが必要です。

このやり方だとyumなどで本体に入っているnginxは削除しました。

configureのオプションは各自吟味してください。

cd /usr/local/src/
wget http://nginx.org/download/nginx-1.13.0.tar.gz
tar zxvf nginx-1.13.0.tar.gz
cd nginx-1.13.0
./configure --prefix=/etc/nginx --sbin-path=/usr/local/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-http_auth_request_module --with-threads --with-stream --with-stream_ssl_module --with-http_slice_module --with-mail --with-mail_ssl_module --with-file-aio --with-http_v2_module --with-openssl=../openssl/ --with-openssl-opt=enable-tls1_3
make
make install

ここで重要なのは--with-http_v2_module --with-openssl=../openssl/ --with-openssl-opt=enable-tls1_3です。
–with-opensslは先ほどのopensslのソースコードのpathです。nginxにバンドルします。

–with-http_v2_moduleはhttp/2対応のため、–with-openssl-opt=enable-tls1_3も設定しないと動きませんでした。

なので使うだけならOpenSSL1.1.1(dev)をmake installする必要ないのですが、openssl s_clientを使用するために使います。

あとはpathを通して、nginx -V で確認します。うまくいけば下のようになっているはずです。

nginx version: nginx/1.13.0
built by gcc <略>
built with OpenSSL 1.1.1-dev  xx XXX xxxx
TLS SNI support enabled
configure arguments: <略> --with-http_v2_module --with-openssl=../openssl/ --with-openssl-opt=enable-tls1_3

nginx設定

既にSSL設定が終わっているなら、このあたりの設定を変更するとOKです。再起動も忘れずに。

ssl.conf

#TLSv1.3用設定
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
ssl_ciphers 'TLS13-AES-128-GCM-SHA256:TLS13-AES-256-GCM-SHA384:TLS13-CHACHA20-POLY1305-SHA256:ECDHE:!COMPLEMENTOFDEFAULT';

#http2用設定
listen 443 ssl http2

SSLv1.3の接続確認

最初に言ったようにブラウザだと確認できませんでした・・・draft-18のものはchromeのchrome://flags/でTLS1.3を指定すると見れます。

https://tls13.crypto.mozilla.org/

このサイトを見るとdraft-18対応済みのchrome/firefoxでは正常に確認でき、TLS1.3と表示されているのがわかります。

対応していないとchromeでは「サポートされていないプロトコルが使用されています」というレアな画面が出ます。

OpenSSLのSSL/TLS client機能で接続確認します。1.1.1は-tls1_3オプションでTLSv1.3で接続しに行きます。
一部省略。

>openssl s_client -connect blog.potproject.net:443 -tls1_3
CONNECTED(00000003)
depth=1 C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
verify error:num=20:unable to get local issuer certificate
---
Certificate chain
 0 s:CN = potproject.net
   i:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
 1 s:C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3
   i:O = Digital Signature Trust Co., CN = DST Root CA X3
---
Server certificate

subject=CN = potproject.net

issuer=C = US, O = Let's Encrypt, CN = Let's Encrypt Authority X3

---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: RSA-PSS
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 3026 bytes and written 270 bytes
Verification error: unable to get local issuer certificate
---
New, TLSv1.3, Cipher is TLS13-AES-128-GCM-SHA256
Server public key is 2048 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
SSL-Session:
    Protocol  : TLSv1.3
    Cipher    : TLS13-AES-128-GCM-SHA256
    Session-ID:
    Session-ID-ctx:
    Master-Key: <master-key>
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: <StartTime>
    Timeout   : 7200 (sec)
    Verify return code: 20 (unable to get local issuer certificate)
    Extended master secret: no
---

これで正しいのかイマイチわかりませんが、TLS1.3認証は出来ていることが確認できます。

TLSv1.3の正式に決まるまでもう日は近いと思うので、その時にすぐに対応できればいいな・・・

[nginx]Let’s EncryptでSSLのセキュリティをA+にするまで

potproject.net Advent Calendar 2016
5日目の記事です。

nginx advent calenderになりつつある。この頃。
10日目くらいからアプリやガジェット系のネタを入れていく次第です。


先日の記事で、nginxでLet’s Encryptを使ってSSLの設定行いました。

しかし、指摘したようにこれだとセキュリティがイマイチなので、

再度設定し直してセキュリティをさらに向上させようと思います。

まず、現在のセキュリティがどのレベルかを見るため、

Qualys SSL Labs の SSL脆弱性診断を使って、テストしてみます。

bef

こういう結果になりました。特に鍵交換が弱いですね。

この部分に関してはDH鍵交換のデフォルトが1024ビットのため、既に弱くなっているからだとか。

まあ1024ビットでも高い専用機じゃないと解読できないレベルらしいので、

こんなしょぼい個人サイトだったらまあ本来はまず問題はないんですが・・・
2048ビットのDH鍵交換をopensslで作成し、使用します。

DH交換用の鍵作成

openssl dhparam -out /etc/nginx/dhparam.pem 2048

セキュリティを高める鍵だけあって、サーバーによっては生成にかなり時間がかかります。こっちだと2分くらい。

自分も生成中にこの記事を書いてました。

他にも、前に紹介したMozilla SSL Configuration Generatorを参考に、いろいろと設定します。

後、せっかくなのでSSL設定を共通化できるようにSSLだけ設定をまとめることにします。

nginxの場合、 include /etc/nginx/ssl.conf; という風に書けばそのままインクルードして使えます。

/etc/nginx/ssl.conf;

# 共通鍵と秘密鍵
ssl_certificate /etc/letsencrypt/live/[ドメイン名]/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/[ドメイン名]/privkey.pem;

# セッションの設定
ssl_session_cache shared:SSL:50m;
ssl_session_timeout  1d;
ssl_session_tickets off;

# 2048ビットのDH鍵交換を使う
ssl_dhparam /etc/nginx/dhparam.pem;

# SSLv3を禁止し、TLSを使う
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
# SSL暗号化スイートの使用設定
ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';
ssl_prefer_server_ciphers on;

# HSTSの有効化
add_header Strict-Transport-Security max-age=15768000;

# OCSP認証とステープリング(キャッシュみたいなもの)を有効にする
# fetch OCSP records from URL in ssl_certificate and cache them
ssl_stapling on;
ssl_stapling_verify on;

## OCSPレスポンスを行うRoot CA 証明書(fullchainでOK)
ssl_trusted_certificate /etc/letsencrypt/live/blog.potproject.net/fullchain.pem;

これをインクルードして設定。nginxの再起動も忘れずに。

af

これでA+になりました。やったぜ。

・・・でもこれが原因でレスポンスなんかがめちゃくちゃ遅くなるんだったら戻しますけどね。

セキュリティより可用性の方が大事ですわな。

nginxでRackアプリケーション(sinatra)を動かす

potproject.net Advent Calendar 2016
4日目の記事です。


うちのブログ初となるであろうRubyの記事です。

実際のところ、自分は全くというほどRubyを書けないのですが、

RubyのWebサービスに関してちょっと使いたいものがあるために構築しています。

なのでRubyの書き方とかSinatraやRailsの使い方ついては他でお願いしたい。

大体ネットに転がっているものを見るとやっぱりRailsばっかりなので、割と珍しいかもしれません。

OSはCentOS7です。

Rubyインストール

今回はちよっと古めなんですが事情によりRuby2.0を使いたいため、

centos7 baseリポジトリからそのままRubyをインストールします。

依存関係でrubygemsなんかも一緒にインストールされました。

で、まあRubyとしては定番であろうパッケージ管理ソフトウェアBundlerをgemからインストール。

rubygemsとbundlerと2つもパッケージ管理ソフトウェアがあるので紛らわしいと自分も思っているのですが、

bundlerはパッケージのバージョンを管理して一括インストールできるソフトウェアです。

プロジェクトごとに個別に設置するので、そのプロジェクトに合ったパッケージをインストールできます。
今回はちゃんとbundlerを使ってsinatraやunicornをインストールします。

# Rubyインストール
yum install ruby ruby-devel
# rubygemsが入っているか確認
gem -v
# rubygemsが古かったのでアップデート
gem install rubygems-update
# bundlerインストール
gem install bundler
# 入ってるgemパッケージを確認
gem list

ruby-develもCentOS7系なら入れておかないと多分動かない。

gemfile作成

# 何かディレクトリを作成する
mkdir sinatra
# Genfile作成
bundle init

このコマンドでどのgemパッケージをインストールするかを記載できるGemfileというファイルが作成されます。

Genfileにsinatraとunicornをインストールするよう記述。

Gemfile

source "https://rubygems.org"

gem "sinatra"

インストール。 パスはvendor/bundle にするのが一般的らしい。

bundle install --path vendor/bundle

webページ作成

hello.rb

require 'sinatra'

get '/' do
  'hello world!'
end

簡単なHello World!コードです。
これで直下に表示されます。

起動

bundle exec ruby hello.rb -p 3000

これで起動します。portも設定できます。デフォルトは4567です。

試しに別ユーザーで curl http://localhost:3000/でちゃんと hello world! と表示されました。

nignxでリバースプロキシ

/etc/nginx/conf.d/sinatra.conf

server {
    server_name (バーチャルホスト名);
    proxy_set_header Host $http_host;
    location / {
        proxy_pass http://localhost:3000;
    }
}

nginxは単なるリバースプロキシです。ここに関しては長くなるし、いろんなところが書いているので省略。

これで外部からも繋げるようになったのを確認できます。

本当はunicornも使ってパフォーマンスを上げたかったのですが、

途中でrubyのバージョンが古いこと絡みによる依存問題が出たのでこれめんどくさい奴だと思ってとりあえず切り捨てました。
rbenvとかいうrubyのバージョンを管理できるものもあるらしいので、次回があればちゃんとやります。


5日目 →

Centos+nginxでLet’s encrypt(certbot)導入と自動更新まで

react-nativeをとりあえずすぐ実機で動かしてみる
そろそろモチベとネタが落ちてきた。どこまで続くか・・・

potproject.net Advent Calendar 2016
3日目の記事です。


ちょっと前にLet’s encryptの導入方法などを書いていましたが、

もはや古くなっている感じだと思います。

というよりいつの間にやら日本語ポータルとか出来ていたりと、かなり充実してきていてびっくりです。
手順も前とかなり変わってきているので、新しく書き直します。

今回はcertbotクライアントを使用し、自動更新までやります。

certbotは元々letsencrypt-autoだったクライアントの名前が変わったものっぽいです。

yumなんかでもインストールが可能になりました。

certbotのインストール(centos7)

epelリポジトリからインストール可能です。

yum install epel-release
yum install certbot

これで終了。初期と比べると手軽になったものです。

Apacheの場合はpython-certbot-apacheというパッケージも必要らしいです。

centbotからSSL証明書の発行

ここで、同じようにApache,nginx,webroot,standaloneといういろいろなプラグインを選べます。

  • Apache : Apacheに最適化したプラグイン。設定を自動書き換え。
  • nginx : nginxに最適化されたプラグイン。設定を自動書き換え。アルファ版らしい
  • webroot : rootにファイルを置くことで認証。Apacheでもnginxでも使える
  • standalone : 自動的にWebサーバを立ち上げて認証。但し現状の鯖は停止する必要あり
  • manual : 手動で認証。Webサーバーを止める必要が無かったりするらしいが結構難しい

個人的にですが、Let’s encryptの導入設定はstandaloneを自分はおすすめします。前も言ってた気がしますが。

Apacheやnginxのプラグインは楽だと思いがちですが、実際Apacheは必要パッケージが無いと動かなかったり、nginxはまだアルファ版だったり不安要素が残ります。

そして上2つの一番嫌なところは、自動的に認証してくれるということで、Apacheやnginx設定を変更されてしまうのです。

これが設定破壊されそうで怖い。

webrootは指定したWebのrootに勝手にファイル置かれて、認証後もそのままなのでなんか気持ち悪いです。(アクセス出来ちゃいますし)

なので自分は自動で楽に使えるstandalone版を使っています。

止まっちゃうのは致し方ないけれど、個人レベルであれば数秒くらいは容認できますよね。

certbot

これをコマンドに打ち込むことでGUI設定が出来ます。全てコマンドで自動化も出来るらしいですが、

手順に沿ったほうが確実かなと。
完了すればSuccessfulが表示され、

秘密鍵: /etc/letsencrypt/live/ドメイン名/privkey.pem

公開鍵: /etc/letsencrypt/live/ドメイン名/cert.pem
に鍵が配置されます。

Webサーバ設定(nginx)

この辺は試行錯誤が必要と思いますが、おおむねこんな感じです。http2対応版。

//略//
server {
    # TCP PORT Setting
    listen 443 ssl http2 default_server;
    listen [::]:443 ssl http2 default_server;

    # ServerName & Root
    server_name [ドメイン名];
    root /var/www/;

    #SSL Setting
    ssl_certificate /etc/letsencrypt/live/[ドメイン名]/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/[ドメイン名]/privkey.pem;
    ssl_session_cache shared:SSL:1m;
    ssl_session_timeout  10m;
    ssl_ciphers AESGCM:HIGH:!aNULL:!MD5;
    ssl_prefer_server_ciphers on;
    ...
    //略//
}

ssl_ciphersは受け付ける暗号化スイートの優先順位らしいです。

!がついているものは使用しない。MD5とかは当然除外です。
これが最低限の設定。もっとセキュリティを高めるにはssl_ciphersやssl_protocolsを的確に設定したほうがいいらしい。

例えば、MD5は上の例で除外されてますが、他にも外すものは結構あるでしょう。つうか暗号スイートなんて数が多すぎて流石に普通把握できない。  
他にもSSLv3は最近POODLEという脆弱性が一時期人気になって一躍有名になったので外したい。

そこで、MozillaさんがSSL設定ジェネレータを公開しているということを知った。

これすごく使えますね。しかもセキュリティもMozillaなのでピカイチです。

Mozilla SSL Configuration Generator
https://mozilla.github.io/server-side-tls/ssl-config-generator/

    #DH鍵交換に使用するパラメータファイル
    ssl_dhparam /path/to/dhparam.pem;

    #SSLプロトコルの指定と暗号化スイートの優先度設定
    ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
    ssl_ciphers 'ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES256-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:DES-CBC3-SHA:!DSS';
    ssl_prefer_server_ciphers on;

    # HSTS ヘッダ
    add_header Strict-Transport-Security max-age=15768000;

このあたりをしっかり設定することでセキュリティが上がって大手企業レベル並のセキュリティを確保できそうです。

・・・鯖負担は上がりそうですが。

証明書の自動更新

2回目以降は一々入力せず同じ内容に更新できるようになります。

これはletsencrypt-auto時代には無かった気がします。

certbot renew

使えるオプションとして –quiet でログ出力しない、 –dry-run で更新テスト(実際には更新しない)が出来ます。

更新できる回数は週に何回だと決められているようで、それを突破すると更新できなくなるので使いすぎに注意。
これを押すだけで自動更新、ってまあコマンド打ってたら自動じゃないじゃんということで、これをそのまま自動実行デーモンであるcronに登録します。
今回はnginxです。apacheならapache(httpd)でお願いします。

crontab -e

0 1 1 * * root service nginx stop && certbot renew -force-renew && service nginx start

一度サーバを止めて、更新後にまたサーバをスタートしたいので、こういう風に書きました。

どっちにしろサーバを止める必要があるならこれが一番かなと思います。
これでSSL導入完了。せっかくなのでhttpは止めるかリダイレクトしましょう。


4日目 →

centos7+nginx+php-fpm+php7な新しい感じの環境を構築

記事の書き方をhtmlからMarkdownにしました。これで今までより捗るはず。真面目に今回はプログを滞りなく技術的なことを書いていきたい。何度目の正直だ。

ということで、いきなりですが技術系おなじみのadvent calendarもどきをやります。

目標としては12/1から12/25です。25記事ということです。

・・・無理そう。

なので、多分飽きたらやめるかもしれませんし辞めないかもしれません。

基本的に書くことはIT系の雑多です。

多分Wordpressとかサーバー構築系のWeb系から、アプリとかjavascriptまで。

あと、計画なんてありません。基本即興です。この一年で生かしたことをひねり出して書く。そんな感じです。

もはや技術関係ないものも出てくるかもしれませんし、まあとりあえず10記事続けばいいな…

目的としてMarkdownを覚えるということもある。
ということでここから開始。

potproject.net Advent Calendar 20161日目の記事です。


11/28くらいにこのブログは別のサーバに移管しました。

使っているところとしては
お名前.com VPSメモリ2GBプランです。

ここが12カ月一括なら税別1100円で、CPUも早いとか聞くのでコスパはかなりいいかなと。

せっかく借りたんだから環境も新しいほうがいい!さらに早い方がいい!

ということでApacheから脱却してこのタイトル通りの環境となります。

現在このサイトもこれで動いています。

最初の環境としては、centos7の最小設定をインストール、ネットワークに接続したところから開始。

基本的にroot権限前提です。

epelとremiリポジトリのインストール

まず、php7を入れる為にはepelリポジトリ及びremiリポジトリが必要です。
remiはともかく、epelリポジトリに関しては多分開発するうえでかなり使用すると思うので入れてて損はないです。

yum install epel-release

これでepelリポジトリが入ります。基本的にこれを使うためには、–enablerepo=epelを使用します。

remiリポジトリはyumコマンドではなく、このサイトからrpmをダウンロードします。

コマンドは載せますが、リンク切れや古くなったりとかもあり得るので、公式サイトから探して落としてきた方が無難です。

wgetも何か最小環境だと入ってなかったのでyum install wgetとかで入れましょう。

最小構成だとgitなんかも入ってなかったりするよね。
この辺は近年だと必須レベルだよなあ。

wget http://rpms.famillecollet.com/enterprise/remi-release-7.rpm
rpm -Uvh remi-release-7.rpm

PHP7のインストール

php7をインストールしたい時には、remi-php70を使用します。

巻末がそのままバージョンなのでremi-php56でv5.6、remi-php71でv7.1なんかもインストールできます。

7.1ももうじき正式リリースされそうです。正式リリースになったら7.1でインストールするのもいいかも。
一応本番として動かすので7.1ではなく7.0を使ってました。チキンです。

yum install --enablerepo=remi,remi-php70 php php-devel php-mbstring php-pdo php-gd php-xml php-fpm php-mysql

インストールできたら、php -vで確認しよう。こんな感じに表示されていれば正常です。
後ろにいっぱい書いてあるのはパッケージです。php-fpmなど、ほぼ必須で使うだろといった感じのパッケージは入れておきます。

php -v
PHP 7.0.13 (cli) (built: Nov  8 2016 20:16:29) ( NTS )
Copyright (c) 1997-2016 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2016 Zend Technologies

php-fpm設定

/etc/php-fpm.d/www.conf がyumでインストールした時のデフォルト設定ファイルです。

こんな感じに設定。ownerやgroupはユーザにより変わります。

今回はnginxというユーザーを作成しています。

user = nginx
group = nginx
listen = /var/run/php-fpm/php-fpm.sock
listen.owner = nginx
listen.group = nginx
listen.mode = 0666

nginxのインストール

nginxはepelリポジトリに最新版がありましたのでインストール。

yum install --enablerepo=epel nginx

nginx設定

このあたりは本当に多彩過ぎて辛い。

本番はこれにSSL設定までしてるからすげえ長くなった。

Apacheより多くね?って感じです。

いろいろ試行錯誤していい感じの設定を探しましょう。

nginx -t で設定が正しいか確認できます。これで不慮のサーバダウンを防ぎましょう。

/etc/nginx/conf.d/nginx.conf

server{
  port   80;
  servername _;
  root   /var/www/html;
  index  index.html index.htm;

  location ~ \.php$ {
    fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock;
    fastcgi_index  index.php;
    fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
    include         fastcgi_params;
  }
}

php-fpm と nginx起動

service nginx start
service php-fpm start
//普通はこっちらしいよ
//systemctl start nginx
//systemctl start php-fpm

後は外部から確認して大体これで表示できねえ!なんでだ!ってなった時には大体SELinuxかfirewalldだと思います。その辺は長くなるのでここまで。

とりあえず動いてるかだけでも確認したいんならcurl http://localhost/ とか打ってなんかいろいろ出たらとりあえずサーバーは稼働している、と自分は良く調べます。

これで 502 Bad Gateway とか出る場合は、大体php-fpmとの連携がうまくいっていません。

権限とかphp-fpmが動いているか確認しましょう。

これが終わっても大体次はmysqlの構築設定の壁が立ちはだかる。先は長い。


次回に続けるときはwordpress+nginxかssl設定の話やります。はい。

2日目→ potproject.net Advent Calendar 2016 2日目