📢 Webサイト閉鎖と移転のお知らせ
このWebサイトは2026年9月に閉鎖いたします。
新しい記事は移転先で追加しております。(旧サイトでは記事を追加しておりません)

 
(同じ利用者による、間の45版が非表示)
17行目: 17行目:
! style="background-color:#66CCFF;" | NginX
! style="background-color:#66CCFF;" | NginX
|-
|-
| style="background-color:#EDEDED;" | 同時・複数アクセスへの対処方法  
| style="background-color:#CFCFCF;" | 同時・複数アクセスへの対処方法  
| 1アクセスに対して、1つの対応 || 複数のアクセスに対して、1つの対応にまとまる
| 1アクセスに対して、1つの対応 || 複数のアクセスに対して、1つの対応にまとまる
|-
|-
| style="background-color:#EDEDED;" | アクセス急増時のサーバへの負荷  
| style="background-color:#CFCFCF;" | アクセス急増時のサーバへの負荷  
| 一気に負荷が増す || アクセスに比例して負荷は急激に増えない
| 一気に負荷が増す || アクセスに比例して負荷は急激に増えない
|-
|-
| style="background-color:#EDEDED;" | その結果のWebサーバの挙動  
| style="background-color:#CFCFCF;" | その結果のWebサーバの挙動  
| 動作が遅くなり、ダウンしやすくなる || 処理速度を維持して、ダウンしにくい
| 動作が遅くなり、ダウンしやすくなる || 処理速度を維持して、ダウンしにくい
|}
|}
48行目: 48行目:
<br>
<br>
<center>
<center>
{| class="wikitable"
{| class="wikitable" | style="background-color:#fefefe;"
|- style="text-align: center; background-color:white;"
! colspan="4" style="background-color:#44CC99;" | 参考書
| <yjshopping seller_id="dss">nginx実践ガイド IT技術者のための現場ノウハウ</yjshopping>
|- style="text-align: center;"
|- style="text-align: center; background-color:white;"
| style="width: 25%" | <center><html><a href="https://www.amazon.co.jp/nginx%E5%AE%9F%E8%B7%B5%E3%82%AC%E3%82%A4%E3%83%89-impress-top-gear%E3%82%B7%E3%83%AA%E3%83%BC%E3%82%BA-%E6%B8%A1%E8%BE%BA%E9%AB%98%E5%BF%97-ebook/dp/B01N183E3H?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&keywords=nginx%E5%AE%9F%E8%B7%B5%E3%82%AC%E3%82%A4%E3%83%89&qid=1683613390&sr=8-1&linkCode=ll1&tag=presire2-22&linkId=043bfdc7a0aebd00eb1db639408b7d42&language=ja_JP&ref_=as_li_ss_tl" target="_blank"><img style="width: 250px; height: auto;" src="https://m.media-amazon.com/images/I/A1nwYPPNb8L._SL1500_.jpg" ></a></html><br>[https://www.amazon.co.jp/nginx%E5%AE%9F%E8%B7%B5%E3%82%AC%E3%82%A4%E3%83%89-impress-top-gear%E3%82%B7%E3%83%AA%E3%83%BC%E3%82%BA-%E6%B8%A1%E8%BE%BA%E9%AB%98%E5%BF%97-ebook/dp/B01N183E3H?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&keywords=nginx%E5%AE%9F%E8%B7%B5%E3%82%AC%E3%82%A4%E3%83%89&qid=1683613390&sr=8-1&linkCode=ll1&tag=presire2-22&linkId=043bfdc7a0aebd00eb1db639408b7d42&language=ja_JP&ref_=as_li_ss_tl nginx実践ガイド<br>IT技術者のための現場ノウハウ]</center>
| <yjshopping seller_id="windybooks">nginx実践入門</yjshopping>
| style="width: 25%" | <center><html><a href="https://www.amazon.co.jp/nginx%E5%AE%9F%E8%B7%B5%E5%85%A5%E9%96%80-WEB-DB-PRESS-plus/dp/4774178667?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&keywords=nginx%E5%AE%9F%E8%B7%B5%E3%82%AC%E3%82%A4%E3%83%89&qid=1683613529&sr=8-4&linkCode=ll1&tag=presire2-22&linkId=27b398323efeb2a8b3c7dbc64e799fa1&language=ja_JP&ref_=as_li_ss_tl" target="_blank"><img style="width: 250px; height: auto;" src="https://m.media-amazon.com/images/I/61LbDMjddRL._SL1000_.jpg" ></a></html><br>[https://www.amazon.co.jp/nginx%E5%AE%9F%E8%B7%B5%E5%85%A5%E9%96%80-WEB-DB-PRESS-plus/dp/4774178667?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&keywords=nginx%E5%AE%9F%E8%B7%B5%E3%82%AC%E3%82%A4%E3%83%89&qid=1683613529&sr=8-4&linkCode=ll1&tag=presire2-22&linkId=27b398323efeb2a8b3c7dbc64e799fa1&language=ja_JP&ref_=as_li_ss_tl nginx実践入門<br>高速/安定稼働を実現する構築と運用のテクニック]</center>
|- style="text-align: center; background-color:white;"
| style="width: 25%" | <center><html><a href="https://www.amazon.co.jp/Nginx-%E3%83%9D%E3%82%B1%E3%83%83%E3%83%88%E3%83%AA%E3%83%95%E3%82%A1%E3%83%AC%E3%83%B3%E3%82%B9-%E9%B6%B4%E9%95%B7-%E9%8E%AE%E4%B8%80/dp/4774176338?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&keywords=nginx%E5%AE%9F%E8%B7%B5%E3%82%AC%E3%82%A4%E3%83%89&qid=1683613634&sr=8-3&linkCode=ll1&tag=presire2-22&linkId=fba35fad8e2270d7371a77b5c5a9f44e&language=ja_JP&ref_=as_li_ss_tl" target="_blank"><img style="width: 250px; height: auto;" src="https://m.media-amazon.com/images/I/61ZE51+HyfL._SL1000_.jpg" ></a></html><br>[https://www.amazon.co.jp/Nginx-%E3%83%9D%E3%82%B1%E3%83%83%E3%83%88%E3%83%AA%E3%83%95%E3%82%A1%E3%83%AC%E3%83%B3%E3%82%B9-%E9%B6%B4%E9%95%B7-%E9%8E%AE%E4%B8%80/dp/4774176338?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&keywords=nginx%E5%AE%9F%E8%B7%B5%E3%82%AC%E3%82%A4%E3%83%89&qid=1683613634&sr=8-3&linkCode=ll1&tag=presire2-22&linkId=fba35fad8e2270d7371a77b5c5a9f44e&language=ja_JP&ref_=as_li_ss_tl Nginx ポケットリファレンス]</center>
| <yjshopping seller_id="magicdoor">Nginx HTTP Server</yjshopping>
| style="width: 25%" | <center><html><a href="https://www.amazon.co.jp/Nginx-HTTP-Server-Harness-infrastructure-ebook/dp/B078JP4HZN?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&crid=3B65BLLSDAMIQ&keywords=Nginx+HTTP+Server&qid=1667805465&qu=eyJxc2MiOiIxLjQ3IiwicXNhIjoiMC4wMCIsInFzcCI6IjAuMDAifQ%3D%3D&sprefix=nginx+http+server%2Caps%2C340&sr=8-1&linkCode=ll1&tag=presire2-22&linkId=27ce6fa58f80207d2bb6d06359b505c7&language=ja_JP&ref_=as_li_ss_tl" target="_blank"><img style="width: 250px; height: auto;" src="https://m.media-amazon.com/images/I/81V8A5I4p4L._SL1500_.jpg" ></a></html><br>[https://www.amazon.co.jp/Nginx-HTTP-Server-Harness-infrastructure-ebook/dp/B078JP4HZN?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&crid=3B65BLLSDAMIQ&keywords=Nginx+HTTP+Server&qid=1667805465&qu=eyJxc2MiOiIxLjQ3IiwicXNhIjoiMC4wMCIsInFzcCI6IjAuMDAifQ%3D%3D&sprefix=nginx+http+server%2Caps%2C340&sr=8-1&linkCode=ll1&tag=presire2-22&linkId=27ce6fa58f80207d2bb6d06359b505c7&language=ja_JP&ref_=as_li_ss_tl Nginx HTTP Server<br>Nginxを利用して、高速なページ配信を実現する]</center>
|}
|}
</center>
</center>
<br><br>
== Mainline版 / Stable版 ==
Nginxには、Mainline版とStable版の2つの主要なバージョンがある。<br>
<br>
<u>Mainline版を使用する場合は十分なテストと検証を行い、プロダクション環境ではStable版を使用することを推奨する。</u><br>
<br>
==== Stable版 ====
Stable版は、テスト済みで安定したバージョンである。<br>
<br>
バグが修正され、機能が確立されており、プロダクション環境で使用することを目的としている。<br>
新しい機能は追加されないが、バグ修正とセキュリティアップデートは行われる。<br>
<br>
==== Mainline版 ====
Mainline版は、最新の開発バージョンである。<br>
新しい機能が追加されており、Stable版よりも頻繁に更新される。<br>
<br>
Mainline版は、開発者やテスタが新しい機能をテストして、フィードバックを提供するために使用される。<br>
<br>
ただし、Mainline版は、テストが十分に行われていない可能性があるため、プロダクション環境で使用するには適していない場合がある。<br>
<br>
Mainline版のメリットを以下に示す。<br>
* 最新の機能やバグ修正を早く利用できる。
* 開発チームが新しい機能をテストし、フィードバックを提供するのに役立つ。
<br>
Mainline版のデメリットを以下に示す。<br>
* バグや不具合が発生する可能性がある。
* 新しい機能が予期せず動作しない可能性がある。
* 設定ファイルや構成が変更される可能性がある。
<br><br>
<br><br>


80行目: 109行目:
==== ソースコードからインストール ====
==== ソースコードからインストール ====
NginXのビルドに必要なライブラリをインストールする。<br>
NginXのビルドに必要なライブラリをインストールする。<br>
  sudo zypper install libxslt-devel pcre2-devel gd-devel
  sudo zypper install libxslt-devel pcre2-devel gd-devel zlib-devel \
  sudo zypper install kernel-source kernel-devel # AIOを使用する場合
                    libopenssl-devel libopenssl-1_1-devel # OpenSSL 1 を使用する場合
                    libopenssl-3-devel                    # OpenSSL 3 を使用する場合
                    libGeoIP-devel                        # GeoIPを使用する場合
                    libcurl-devel ruby-devel              # Passengerを使用する場合
                    kernel-source kernel-devel             # AIOを使用する場合
<br>
<br>
必要ならば、[https://www.openssl.org/source/ OpenSSLの公式Webサイト]にアクセスして、OpenSSL(1.X.Y)のソースコードをダウンロードする。<br>
必要ならば、[https://www.openssl.org/source/ OpenSSLの公式Webサイト]にアクセスして、OpenSSL(1.X.Y)のソースコードをダウンロードする。<br>
ダウンロードしたファイルを解凍する。<br>
ダウンロードしたファイルを解凍する。<br>
  tar xf openssl-<バージョン>
  tar xf openssl-<バージョン>
<br>
* Digest認証モジュールを使用する場合
*: NginXのソースコードと一緒に配布されていないため、別途インストールする必要がある。<br>
*: [https://github.com/atomx/nginx-http-auth-digest Digest認証モジュールのGithub]にアクセスして、ソースコードをダウンロードする。<br>
*: ダウンロードしたファイルを解凍する。<br>
*: <code>tar xf nginx-http-auth-digest-<バージョン>.tar.gz</code>
*: <br>
*: または、<code>git clone</code>コマンドを実行して、ソースコードをダウンロードする。<br>
*: <code>git clone https://github.com/atomx/nginx-http-auth-digest.git</code>
*: <br>
* Passengerモジュールを使用する場合 (Rails連携)
*: NginXのソースコードと一緒に配布されていないため、別途インストールする必要がある。<br>
*: [https://www.phusionpassenger.com/docs/advanced_guides/install_and_upgrade/standalone/install/oss/tarball.html Passengerモジュールの公式webサイト]にアクセスして、ソースコードをダウンロードする。<br>
*: または、[https://github.com/phusion/passenger PassengerのGithub]にアクセスして、ソースコードをダウンロードする。
*: ダウンロードしたファイルを解凍する。<br>
*: <code>tar xf passenger-<バージョン>.tar.gz</code>
*: <code>cd passenger-<バージョン></code>
*: <br>
<br>
NginX 1.9.11以降から、<code>configure</code>スクリプト実行時において、<br>
--add-module=<PATH>オプションの代わりに<code>--add-dynamic-module=<PATH></code>オプションを使用して、モジュールを動的モジュールとしてコンパイルすることができる。<br>
そして、<code>load_module</code>ディレクティブを使用して、nginx.confファイルで明示的にモジュールをロードすることができる。<br>
load_module /path/to/modules/<モジュール名>.so;
<br>
<br>
[https://nginx.org/en/download.html NginXの公式Webサイト]にアクセスして、NginXのソースコードをダウンロードする。<br>
[https://nginx.org/en/download.html NginXの公式Webサイト]にアクセスして、NginXのソースコードをダウンロードする。<br>
93行目: 149行目:
<br>
<br>
NginXをビルドおよびインストールする。<br>
NginXをビルドおよびインストールする。<br>
<br>
Digest認証モジュールも併せてビルドおよびインストールする場合、<br>
<code>configure</code>スクリプトにおいて、<code>--add-module=<Digest認証モジュールのソースコードがあるディレクトリ></code>オプションを付加する。<br>
<br>
<u>NginXのビルドにおいて、ビルドディレクトリを作成すると失敗することに注意する。</u><br>
<u>NginXのビルドにおいて、ビルドディレクトリを作成すると失敗することに注意する。</u><br>
  export NGINX_DIR=<NginXのインストールディレクトリ>
  export NGINX_DIR=<NginXのインストールディレクトリ>
112行目: 172行目:
  --with-perl_modules_path=$NGINX_DIR/Perl \
  --with-perl_modules_path=$NGINX_DIR/Perl \
  --with-threads --with-file-aio --with-pcre --with-pcre-jit \
  --with-threads --with-file-aio --with-pcre --with-pcre-jit \
  --with-http_v2_module --with-http_ssl_module --with-http_addition_module --with-http_realip_module \
  --with-http_v2_module --with-http_ssl_module --with-http_addition_module --with-http_realip_module --with-http_flv_module \
--with-http_random_index_module --with-http_degradation_module --with-http_slice_module  --with-http_dav_module --with-http_mp4_module \
  --with-http_xslt_module --with-http_xslt_module=dynamic \
  --with-http_xslt_module --with-http_xslt_module=dynamic \
  --with-http_image_filter_module --with-http_image_filter_module=dynamic --with-http_dav_module --with-http_mp4_module --with-http_flv_module \
  --with-http_image_filter_module --with-http_image_filter_module=dynamic \
  --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_degradation_module --with-http_slice_module \
  --with-http_geoip_module=dynamic --with-http_gunzip_module --with-http_gzip_static_module \
  --with-http_auth_request_module --with-http_secure_link_module --with-http_stub_status_module --with-http_sub_module \
  --with-http_auth_request_module --with-http_secure_link_module --with-http_stub_status_module --with-http_sub_module \
  --with-http_perl_module --with-http_perl_module=dynamic \
  --with-http_perl_module --with-http_perl_module=dynamic \
121行目: 182行目:
  --with-stream=dynamic --with-stream_ssl_module --with-stream_realip_module --with-stream_ssl_preread_module \
  --with-stream=dynamic --with-stream_ssl_module --with-stream_realip_module --with-stream_ssl_preread_module \
  --with-compat \
  --with-compat \
  --with-cc=/usr/bin/gcc --with-cpp=/usr/bin/g++ \
  --with-ipv6  \ # ただし、1.24以降は無効
  --user=<任意のユーザ名> \ # 任意のユーザ名 例.nginx
  --user=<任意のユーザ名  例. nginx> \
  --group=<任意のグループ名> # 任意のグループ名 例.nginx
  --group=<任意のグループ名 例. nginx>
  # 不要の可能性あり
  # 不要の可能性あり
  --without-poll_module --without-select_module --with-ipv6
  --without-poll_module --without-select_module
# Digest認証を使用する場合
--add-dynamic-module=<Digest認証モジュールのソースコードがあるディレクトリ>
# Passengerを使用する場合
--add-dynamic-module=/<Passengerモジュールのディレクトリ>/src/nginx-module
# GCCコンパイラを指定する場合
--with-cc=/<gcc実行ファイルがあるディレクトリ>/gcc \
--with-cpp=/<g++実行ファイルがあるディレクトリ>/g++
  # OpenSSLを手動で設定する場合に記述する
  # OpenSSLを手動で設定する場合に記述する
  --with-openssl=<上記でダウンロードおよび解凍したOpenSSLのソースコードのトップディレクトリ>
  --with-openssl=<上記でダウンロードおよび解凍したOpenSSLのソースコードのトップディレクトリ>
  # 以下の設定はAIOを使用する場合に記述する
  # 以下の設定はAIOを使用する場合に記述する
  --with-cc-opt='-fmessage-length=0 -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchron ous-unwind-tables -fstack-clash-protection -g -fPIC -D_GNU_SOURCE' \
  --with-cc-opt='-fmessage-length=0 -grecord-gcc-switches -O2 -Wall -D_FORTIFY_SOURCE=2 -fstack-protector-strong -funwind-tables -fasynchron ous-unwind-tables -fstack-clash-protection -g -fPIC -D_GNU_SOURCE' \
213行目: 287行目:
NginXの設定ファイルの内容を変更した時、変更を反映させるためにNginXを再読み込みする。<br>
NginXの設定ファイルの内容を変更した時、変更を反映させるためにNginXを再読み込みする。<br>
  sudo systemctl reload nginx
  sudo systemctl reload nginx
<br><br>
== 動的モジュール ==
NginXは多数のモジュールから構成されており、NginXのビルド時にモジュールがNginXバイナリにスタティックに組み込まれる。<br>
追加したいモジュールがある場合も同様、NginXのビルド時にそのモジュールを指定することにより、NginXバイナリにそのモジュールがスタティックに組み込まれる。<br>
<br>
過去のNginXにおいては、モジュールを追加・変更するたびに、NginX本体をビルドし直す必要があり、運用が煩雑であった。<br>
<br>
しかし、NginX 1.9.11以降では、動的モジュールがサポートされて、動的モジュールを使用時(NginXの起動およびリロード)に組み込むことができるようになった。<br>
<br>
例えば、NginXの設定ファイル(nginx.confファイル)において、<code>load_module</code>ディレクティブの値として、動的モジュールの共有オブジェクトファイルのパスを指定して、<br>
NginXを起動あるいはリロードすることにより、動的モジュールを使用できるようになる。<br>
<syntaxhighlight lang="nginx">
load_module "modules/foo_module.so";
</syntaxhighlight>
<br>
<code>load_module</code>ディレクティブの記述場所はmainコンテキストである。<br>
また、各ブロック(events、http、stream、mail)よりも前に記述する必要があることに注意する。<br>
<syntaxhighlight lang="nginx">
user  nginx;
worker_processes  1;
load_module "modules/ngx_stream_module.so";
load_module "modules/ngx_http_geoip_module.so";
events {
    worker_connections  1024;
}
http {
    # ...略
}
</syntaxhighlight>
<br>
もし、各ブロック(events、http、stream、mail)よりも前に記述した場合は、以下に示すようなエラーが出力される。<br>
# 出力例
nginx: [emerg] "load_module" directive is specified too late in /usr/local/nginx/conf/nginx.conf:16
<br>
NginXの標準モジュール全てが動的モジュールとして使用できるわけではない。<br>
現行のバージョンでは、以下に示すモジュールが動的モジュールとして使用することができる。<br>
* XSLT (ngx_http_xslt_module)
* Image Filter (ngx_http_image_filter_module)
* GeoIP (ngx_http_geoip_module)
* Mail (ngx_mail_module)
* Stream (ngx_stream_module)
<br>
また、サードパーティ製モジュールも動的モジュールとして使用できるが、<code>configure</code>スクリプトの修正が必要となるため、動的モジュールへの対応をサポートしているモジュール以外は、そのままでは使用できない。<br>
<br>
現行バージョンでは、動的モジュール単体のみをビルドすることはできないため、動的モジュールをビルドするためには、NginX本体をビルドする手順とほぼ同じ手順を行う必要がある。<br>
なお、将来的には、モジュール単体をビルドできるようにする計画がある。<br>
<br><br>
== NginXのディレクトリ構造 ==
NginXのファイル、ディレクトリ、およびコマンドは、NginXを使用するために知っておくべき重要なものである。<br>
<br>
*/etc/nginxディレクトリ
*: /etc/nginx/ディレクトリは、NginXのデフォルトの設定ルートである。
*: このディレクトリ内には、NginXの動作を設定するファイルがある。
*: <br>
* /etc/nginx/nginx.confファイル
*: /etc/nginx/nginx.confファイルは、NginXで使用されるデフォルトの設定エントリポイントである。
*: この構成ファイルは、ワーカープロセス、チューニング、ロギング、動的モジュールのロード、および他のNginX構成ファイルへの参照等の全体に及ぶ設定を行う。
*: デフォルトの設定では、/etc/nginx/nginx.confファイルはトップレベルのhttpブロック、またはコンテキストを含み、次に説明するディレクトリの全ての設定ファイルを含む。
*: <br>
* /etc/nginx/conf.dディレクトリ
*: /etc/nginx/conf.dディレクトリは、デフォルトのHTTPサーバの設定ファイルを保存するディレクトリである。
*: このディレクトリ内の.confで終わるファイルは、/etc/nginx/nginx.confファイル内のトップレベルのhttpブロックにおいて、<code>include</code>文を使用して設定が管理されている。
*: 環境によっては、このディレクトリをsites-enabledという名前にして、設定ファイルをsite-availableというディレクトリからリンクしている場合もある。(非推奨)
*: <br>
* /var/log/nginxディレクトリ
*: /var/log/nginxディレクトリは、NginXのデフォルトのログの場所である。
*: このディレクトリには、access.logファイルとerror.logファイルがある。
*: access.logファイルには、NginXが提供する各リクエストのエントリが含まれる。
*: error.logファイルには、エラーイベントとデバッグモジュールが有効になっている場合のデバッグ情報が含まれる。
<br><br>
== NginXのコマンド ==
* nginx -h
*: NginXのヘルプメニューを表示する。
*: <br>
* nginx -v
*: NginXのバージョンを表示する。
*: <br>
* nginx -V
*: NginXのバージョン、ビルド情報、設定引数を表示する。
*: また、ビルドされたモジュールを表示する。
*: <br>
* nginx -t
*: NginXの設定をテストする。
*: <br>
* nginx -T
*: NginXの設定をテストして、検証された設定を画面に表示する。
*: このコマンドは、サポートを求める場合に便利である。
*: <br>
* nginx -s <シグナル名>
*: <code>-s</code>オプションは、NginXのマスタープロセスにシグナルを送信する。
*: <code>stop</code>、<code>quit</code>、<code>reload</code>、<code>reopen</code>等のシグナルを送信することができる。
*: <br>
*: <code>stop</code>シグナルは、NginXプロセスを直ちに中止する。
*: <code>quit</code>シグナルは、NginXプロセスが実行要求されている処理を終了した後に停止する。
*: <code>reload</code>シグナルは、設定を再読み込みする。
*: <code>reopen</code>シグナルは、ログファイルを再開するようNginXに指示する。
<br><br>
<br><br>


== ファイアウォールの設定 ==
== ファイアウォールの設定 ==
次に、ファイアウォール設定にいくつかの変更を加えて、httpサービスを許可する。<br>
次に、ファイアウォール設定にいくつかの変更を加えて、httpサービスを許可する。<br>
  sudo firewall-cmd --add-port=80/tcp --permanent
  sudo firewall-cmd --permanent --add-port=80/tcp
  sudo firewall-cmd --reload
  sudo firewall-cmd --reload
<br><br>
<br><br>
318行目: 495行目:
  <syntaxhighlight lang="nginx">
  <syntaxhighlight lang="nginx">
  # nginx.confファイル
  # nginx.confファイル
# NginXのPIDファイルの場所
#pid        /tmp/nginx.pid;
# 使用するCPUのプロセス数
# CPUのコア数より多く設定してもパフォーマンスは上がらない
worker_processes  1;
# エラーログの指定
# ログレベルは低い順にdebug, info, notice, warn, error, crit, alert, emerg
error_log  log/error.log  info;
events {
    worker_connections  1024;
}
   
   
  http {
  http {
     # ...略
     # ...略
    # 設定ファイルの読み込み
    #include /etc/nginx/conf.d/ssl.conf
    #include /etc/nginx/vhost.d/*.conf
   
   
     server {
     server {
331行目: 527行目:
                     # 例1. log/localhost.log;
                     # 例1. log/localhost.log;
                     # 例2. /srv/www/htdoc/log/localhost.log;
                     # 例2. /srv/www/htdoc/log/localhost.log;
        # IPフィルタリング
        # 上にあるルールが優先
        #allow all;
        #deny  all;
        # インデックスファイルが存在しない場合、ファイル一覧を有効化 / 無効化
        autoindex on;
   
   
         location / {
         location / {
388行目: 592行目:
         }
         }
   
   
         # deny access to .htaccess files, if Apache's document root
         # ApacheのドキュメントルートがNginXのドキュメントルートと一致する場合、.htaccessファイルへのアクセスを拒否する
        # concurs with nginx's one
        #
         #location ~ /\.ht {
         #location ~ /\.ht {
         #    deny  all;
         #    deny  all;
408行目: 610行目:


== 仮想ホストの構築 ==
== 仮想ホストの構築 ==
パッケージ管理システムからNginXをインストールした場合、/etc/nginx/vhosts.dディレクトリ内に、Webサイトの設定ファイルを複数作成することができる。<br>
一般的には、1つのWebサイトごとに1ファイル、<ドメイン名>.confのような名前を付ける。<br>
<br>
NginXの設定ファイルを編集する。<br>
NginXの設定ファイルを編集する。<br>
  # パッケージ管理システムからインストールしている場合
  # パッケージ管理システムからインストールしている場合
463行目: 668行目:
  </syntaxhighlight>
  </syntaxhighlight>
<br>
<br>
また、仮想ホストの設定を、/etc/nginx/vhost.dディレクトリ、または、/<NginXのインストールディレクトリ>/etc/vhosts.dディレクトリに配置してもよい。<br>
一般的に、仮想ホストの設定ファイルは、/etc/nginx/vhost.dディレクトリ、または、/<NginXのインストールディレクトリ>/etc/vhosts.dディレクトリに配置する。<br>
  # パッケージ管理システムからインストールしている場合
  # パッケージ管理システムからインストールしている場合
  sudo vi /etc/nginx/vhost.d/vhost1.conf
  sudo vi /etc/nginx/vhost.d/vhost1.conf
676行目: 881行目:


== NginXのその他の設定 ==
== NginXのその他の設定 ==
==== charset ====
値 : キャラクタ名 / off<br>
初期値 : off<br>
使用環境 : http, server, server.location, locationディレクティブのif文<br>
<br>
指定された文字セットを"Content-Type"応答ヘッダフィールドに追加する。<br>
charsetがsource_charsetディレクティブで指定されたcharsetと異なる場合は、変換が実行される。<br>
<br>
<code>off</code>に設定する場合、"Content-Type"応答ヘッダフィールドへのcharsetの追加を取り消す。<br>
<br>
設定できる値は、charset_map、charset、source_charsetディレクティブの形で、少なくとも1度は設定に存在する必要がある。<br>
utf-8、windows-1251、koi8-r文字セットについては、conf/koi-win、 conf/koi-utf、conf/win-utfを設定に含めれば十分である。<br>
その他の文字セットについては、例えば、単に架空の変換テーブルを作成することでも動作する。<br>
<br>
また、"X-Accel-Charset"応答ヘッダフィールドに文字セットを設定することができる。<br>
この機能は、proxy_ignore_headers、fastcgi_ignore_headers、uwsgi_ignore_headers、scgi_ignore_headers、grpc_ignore_headersディレクティブで無効化することができる。<br>
<br>
==== tcp_nodelay ====
==== tcp_nodelay ====
値 : on / off<br>
値 : on / off<br>
720行目: 942行目:
<code>sendfile</code>関数は、2つのファイルディスクリプタ間で直接データを渡すため(カーネル内での動作)、カーネルバッファとユーザバッファ間のデータのコピーを回避して、<br>
<code>sendfile</code>関数は、2つのファイルディスクリプタ間で直接データを渡すため(カーネル内での動作)、カーネルバッファとユーザバッファ間のデータのコピーを回避して、<br>
ゼロコピーと呼ばれるほど効率的な処理を行うことが可能である。<br>
ゼロコピーと呼ばれるほど効率的な処理を行うことが可能である。<br>
<br><br>
== Basic認証 ==
Basic認証のパスワードファイルを作成する。<br>
<br>
<code>htpasswd</code>コマンドを実行して、Basic認証を設定する。<br>
以下の例では、.htpasswdファイルとしているが、ファイル名は任意の名前でよい。<br>
htpasswd -c /<任意のパスワードファイルのディレクトリ>/<Basic認証ファイル名> <Basic認証時のユーザ名>
例. htpasswd -c /etc/nginx/conf.d/.htpasswd sample_user
<br>
Basic認証を有効にするため、nginx.confファイル等に以下に示す設定を追加する。<br>
<syntaxhighlight lang="nginx">
# トップページ(http://www.example.com/)にBasic認証を掛ける場合、/のlocationディレクティブに設定を追加する
location / {
    root  <ドキュメントルートのディレクトリ>;
    index  index.html index.htm;
    auth_basic "<認証名>";
              # 例. "Basic Authentication";
    auth_basic_user_file <Basic認証ファイルの絶対パス>;
                        # 例. auth_basic_user_file /etc/nginx/conf.d/.htpasswd;
}
# トップページ以外(http://www.example.com/hoge/)にBasic認証を掛ける場合、/hoge/のlocationディレクティブを作成および設定を追加する
location /hoge/ {
    auth_basic "<認証名>";
              # 例. "Basic Authentication";
    auth_basic_user_file <Basic認証ファイルの絶対パス>;
                        # 例. /etc/nginx/conf.d/.htpasswd;
}
  </syntaxhighlight>
<br>
設定を反映する。<br>
sudo systemctl restart nginx
sudo systemctl reload  nginx
<br><br>
== Digest認証 ==
==== Digest認証とは ====
Webブラウザ等のクライアントからサーバへユーザ名やパスワード等を送信して、サーバから結果を応答する手順のことである。<br>
<br>
認証情報は平文で送信せずに、ハッシュ関数と呼ばれる一定の計算手順で逆変換できない状態に加工してから送信する。<br>
サーバ側では、クライアント側からユーザ名やパスワード等のそのものを受信することはできないが、<br>
登録済みの情報から同じようにハッシュ値を算出して、クライアントから受信したハッシュ値に一致すれば認証成功となる。<br>
<br>
より安全性を高めるため、サーバとクライアントの双方がその場限りのランダムなデータ(nonceと呼ばれる)を生成して、送信するデータに付け加えてからハッシュ値を算出する。<br>
これにより、認証情報そのものは同じでも、実際に送信するデータは毎回変化するため、秘密の情報を割り出さなくても実行できる反射攻撃などを防ぐことができる。<br>
<br>
ハッシュ関数の種類においては、ヘッダ領域の中で指定することができ、双方が対応しているアルゴリズムが採用される。<br>
<u>当初の規格(RFC 2617)ではMD5方式が使用されていたが、現在では十分な安全性が確保できないことが知られており、改訂版(RFC 7616)ではSHA-256の使用が推奨されている。</u><br>
<br>
Digest認証は、認証情報を平文のまま送受信するBASIC認証(基本認証)と比較して、クライアントとサーバ間の伝送路の安全が確保されていない状況で認証情報を保護することができるが、<br>
現代では、SSL/TLSを用いてHTTPによるデータ伝送全体を暗号化するHTTPS通信が広く普及しており、かつてより重要性は低下している。<br>
<br>
==== realmとは ====
realmは、サーバが要求する認証領域や識別領域を示すものである。<br>
通常、この領域 (realm名) は保護されたリソースやWebサイトのドメイン名等で識別される。<br>
<br>
クライアントがリクエストを送信する際に、realmはクライアントに対してどの認証情報が必要かを示し、ユーザに対して正しい認証情報を提供するよう促す。<br>
<br>
例えば、HTTPヘッダにおいて、以下に示すようにrealmが指定される場合がある。<br>
以下の例では、realmは<u>example.com</u>という文字列で、クライアントはこの識別領域での認証を行う必要がある。<br>
<code>nonce</code>や<code>opaque</code>等の他のパラメータも設定されて、セキュリティの向上や攻撃からの保護を担っている。<br>
WWW-Authenticate: Digest realm="example.com", qop="auth", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="5ccc069c403ebaf9f0171e9517f40e41"
<br>
==== NginXにおけるDigest認証モジュールの注意点 ====
Digest認証モジュールは、NginXのソースコードと一緒に配布されていないため、別途インストールする必要がある。<br>
<br>
Digest認証モジュールは、RFCに基づいて機能が完成しているが、実際の運用で使用するのに十分な安全性を確保するために、より広範な検証が必要な状態である。<br>
現在の注意点については、[https://github.com/atomx/nginx-http-auth-digest/blob/master/bugs.txt bugs.txt]ファイルと[https://github.com/atomx/nginx-http-auth-digest/issues github issue tracker]を参照すること。<br>
<br>
==== Digest認証の設定 ====
Digest認証のパスワードファイルを作成する。<br>
<br>
<code>htdigest</code>コマンドを実行して、Digest認証を設定する。<br>
以下の例では、.htdigestファイルとしているが、ファイル名は任意の名前でよい。<br>
# 初めてDigest認証ファイルを作成する場合
htdigest -c <作成するDigest認証ファイルのフルパス> "<realm名>" <Digest認証時のユーザ名>
# Digest認証ファイルに設定を追記する場合
htdigest <追記するDigest認証ファイルのフルパス> "<realm名>" <Digest認証時のユーザ名>
例. htdigest -c /etc/nginx/conf.d/.htdigest "test" sample_user
<br>
Digest認証を有効にするため、nginx.confファイル等に以下に示す設定を追加する。<br>
<syntaxhighlight lang="nginx">
# トップページ(http://www.example.com/)にDigest認証を掛ける場合、/のlocationディレクティブに設定を追加する
location / {
    root  <ドキュメントルートのディレクトリ>;
    index  index.html index.htm;
    auth_digest "<realm名>";
              # 例. "test";
    auth_digest_user_file <Digest認証ファイルの絶対パス>;
                        # 例. /etc/nginx/conf.d/.htdigest;
}
# トップページ以外(http://www.example.com/hoge/)にDigest認証を掛ける場合、/hoge/のlocationディレクティブを作成および設定を追加する
location /hoge/ {
    auth_digest "<realm名>";
                # 例. "test";
    auth_digest_user_file <Digest認証ファイルの絶対パス>;
                          # 例. /etc/nginx/conf.d/.htdigest;
}
  </syntaxhighlight>
<br>
設定を反映する。<br>
sudo systemctl restart nginx
sudo systemctl reload  nginx
<br><br>
== HTTPS(SSL)の設定 (Let's Encrypt) ==
==== Let's Encryptとは ====
[https://letsencrypt.org/ Let's Encrypt](Linux Foundationの協業プロジェクト)は、Web全体の安全性を改善することを掲げており、<br>
発行料無料のSSL/TLSサーバ証明書を取得することができる。<br>
<br>
Let's Encryptでは、 一般的なドメイン認証(DV)の証明書を無料で発行しており、<br>
その中間証明書は、大手認証局(CA)のルート証明書によってクロス署名されているため、多くの主要ブラウザ等々で信頼済みとして扱われる。<br>
<br>
なお、1回の認証で得られる証明書の有効期限は90日である。<br>
したがって、90日以内に証明書の更新を、再度実施する必要がある。<br>
<br>
==== Certbotクライアントのインストール ====
証明書を取得するため、Certbotクライアントをインストールする。<br>
sudo zypper install certbot
<br>
==== 証明書の取得 ====
<u>Apache2やNginX等のWebサーバが稼働していることが前提となることに注意する。</u><br>
<u>また、インターネット側から、証明書を使用するWebサーバ(証明書を取得するFQDNのサーバ)のTCP80番ポートを開放することも前提となる。</u><br>
<br>
* <code>--webroot -w</code>オプション
*: 稼働中のWebサーバのドキュメントルート配下を認証用の一時領域に使用する。
*: 例. <code>--webroot -w <ドキュメントルート> -d <証明書を取得するFQDN></code>
*: <br>
*: 証明書を取得するFQDNが複数ある場合は、<code>-d <証明書を取得するFQDN></code>を複数指定できる。
*: 例. hoge.comとpiyo.comの2つについて取得する場合
*: <code>-d hoge.com -d piyo.com</code>
*: <br>
* FQDN (Fully Qualified Domain Name)
*: <ホスト名>.<ドメイン名>を省略せずに記述する。
*: <br>
<br>
ドキュメントルートは、仮想ホストで複数のホスト定義がある場合、該当するホスト定義のものを指定する。<br>
ドキュメントルート指定の動作としては、指定したドキュメントルート配下に.well-knownディレクトリが作成されて、認証用のファイルが自動的かつ一時的に設置される。<br>
<br>
証明書を取得する。<br>
certbot certonly --webroot -w <ドキュメントルートのパス> -d <FQDN>
# または
sudo certbot certonly --webroot -w <ドキュメントルートのパス> -d <FQDN>
例.
sudo certbot certonly --webroot -w /srv/www/htdocs -d www.hoge.com
<br>
初回のみメールアドレスの登録と利用条件への同意が必要となる。<br>
# 受信可能なメールアドレスを指定する
(Enter 'c' to cancel): <メールアドレス>
# 利用条件に同意する
(A)gree/(C)ancel: A
# 非営利団体 Electronic Frontier Foundation にもメールアドレスを登録するか否か
(Y)es/(N)o: Y
<br>
最後に、"Congratulations"と表示されると成功である。<br>
<br>
上記のメッセージに表示される通り、/etc/letsencrypt/live/<FQDN>ディレクトリ内に、4つの証明書が保存される。<br>
* cert.pem
*: SSLサーバー証明書(公開鍵含む)
* chain.pem
*: 中間証明書
* fullchain.pem
*: cert.pemファイルとchain.pemファイルが結合されたファイル
* privkey.pem
*: 公開鍵に対する秘密鍵
<br>
証明書を使用するWebサーバが未稼働の場合でも、Certbotの簡易Webサーバ機能を使用して(<code>--standalone</code>オプションを付加する)、証明書を取得することができる。<br>
<u>この場合も、インターネット側から証明書を使用するWebサーバのTCP80番ポートを開放する必要がある。</u><br>
certbot certonly --standalone -d <FQDN>
# または
sudo certbot certonly --standalone -d <FQDN>
例.
sudo certbot certonly --standalone -d www.hoge.com
<br>
==== 取得済みの証明書の更新 ====
有効期限が30日未満の証明書を全て更新する。<br>
もし、有効期限の残り日数に関わらずに更新する場合は、<code>--force-renew</code>オプションも付加する。<br>
certbot renew
# または
sudo certbot renew
<br><br>
<br><br>


767行目: 1,181行目:
SHA-512が最も安全性が高いが、クライアント端末側がSHA-512に対応している必要がある。<br>
SHA-512が最も安全性が高いが、クライアント端末側がSHA-512に対応している必要がある。<br>
<br>
<br>
==== 自己証明書の発行(サーバ側) ====
==== 自己署名証明書の発行(サーバ側) ====
秘密鍵を作成する。<br>
===== 秘密鍵を作成する =====
  openssl genrsa -out <秘密鍵のファイル名>.key 2048
  openssl genrsa -out <秘密鍵のファイル名>.key 2048
<br>
<br>
作成した秘密鍵を使用して、CSRを作成する。<br>
秘密鍵のファイルのアクセス権限を変更する。<br>
chmod 400 <秘密鍵のファイル名>.key
<br>
===== CSR(証明書署名要求)の作成 =====
作成した秘密鍵を使用して、クライアント側のCSRを作成する。<br>
  openssl req -sha256 -new -subj "/C=JP/ST=Tokyo/L=Tokyo City/O=Company Name/OU=Department/CN=*.<ドメイン名>" -key <秘密鍵のファイル名>.key -out <CSRのファイル名>.csr
  openssl req -sha256 -new -subj "/C=JP/ST=Tokyo/L=Tokyo City/O=Company Name/OU=Department/CN=*.<ドメイン名>" -key <秘密鍵のファイル名>.key -out <CSRのファイル名>.csr
<br>
<br>
===== SAN (Subject Alternative Name)の作成 =====
サーバ証明書に自己署名証明書を使用する場合、クライアントPCに自己署名証明書をインストールしても、Webブラウザ(Chrome等)は警告を表示する。<br>
これは、Chrome等のWebブラウザは、コモンネーム(CN)ではなく、SAN(Subject Alternative Name)を確認しているからである。<br>
そのため、SANを加えて自己署名証明書を作成する必要がある。<br>
<br>
<u>※注意</u><br>
<u>DNS項目ではワイルドカードが使用できるが、IP項目では使用できないことに注意する。</u><br>
vi san.txt  # ファイル名は任意
<br>
# san.txtファイル
subjectAltName = DNS:localhost,*.localhost,*.example.com IP:127.0.0.1,172.20.0.1
<br>
===== サーバ証明書の作成 =====
作成したCSRに署名を行って、サーバ証明書を発行する。<br>
作成したCSRに署名を行って、サーバ証明書を発行する。<br>
<u><サーバ証明書のファイル名>.csrファイルは、サーバ証明書を発行するためのファイルのため、削除してもよい。</u><br>
<u><サーバ証明書のファイル名>.csrファイルは、サーバ証明書を発行するためのファイルのため、後で削除してもよい。</u><br>
  openssl x509 -sha256 -req -days <証明書の有効日数 例. 3650> -in <CSRのファイル名>.csr -signkey <秘密鍵のファイル名>.key -out <サーバ証明書のファイル名>.crt
  openssl x509 -sha256 -req -days <証明書の有効日数 例. 3650> -in <CSRのファイル名>.csr -signkey <秘密鍵のファイル名>.key \
<br>
        -extfile san.txt \
秘密鍵のファイルのアクセス権限を変更する。<br>
        -out <サーバ証明書のファイル名>.crt
chmod 400 <秘密鍵のファイル名>.key
<br>
<br>
===== Webサーバの設定 =====
Webサーバに設置するものは、秘密鍵(.key拡張子)とサーバ証明書(.crt拡張子)の2つである。<br>
Webサーバに設置するものは、秘密鍵(.key拡張子)とサーバ証明書(.crt拡張子)の2つである。<br>
<br>
<br>
820行目: 1,254行目:
<br>
<br>
==== 自己証明書の発行(クライアント側) ====
==== 自己証明書の発行(クライアント側) ====
秘密鍵を作成する。<br>
===== 秘密鍵を作成する =====
  openssl genrsa -out <秘密鍵のファイル名>.key 2048
  openssl genrsa -out <秘密鍵のファイル名>.key 2048
<br>
<br>
秘密鍵のファイルのアクセス権限を変更する。<br>
chmod 400 <秘密鍵のファイル名>.key
<br>
===== CSR(証明書署名要求) =====
作成した秘密鍵を使用して、クライアント側のCSRを作成する。<br>
作成した秘密鍵を使用して、クライアント側のCSRを作成する。<br>
  openssl req -sha256 -new -subj "/C=JP/ST=Tokyo/L=Tokyo City/O=Company Name/OU=Department/CN=*.<ドメイン名>" \
  openssl req -sha256 -new -subj "/C=JP/ST=Tokyo/L=Tokyo City/O=Company Name/OU=Department/CN=*.<ドメイン名>" \
                           -key <秘密鍵のファイル名>.key -out <CSRのファイル名>.csr
                           -key <秘密鍵のファイル名>.key -out <CSRのファイル名>.csr
<br>
<br>
===== SAN (Subject Alternative Name)の作成 =====
サーバ証明書に自己署名証明書を使用する場合、クライアントPCに自己署名証明書をインストールしても、Webブラウザ(Chrome等)は警告を表示する。<br>
これは、Chrome等のWebブラウザは、コモンネーム(CN)ではなく、SAN(Subject Alternative Name)を確認しているからである。<br>
そのため、SANを加えて自己署名証明書を作成する必要がある。<br>
<br>
<u>※注意</u><br>
<u>DNS項目ではワイルドカードが使用できるが、IP項目ではワイルドカードが使用できないことに注意する。</u><br>
vi san.txt  # ファイル名は任意
<br>
# san.txtファイル
subjectAltName = DNS:localhost,*.localhost,*.example.com IP:127.0.0.1,172.20.0.1
<br>
===== サーバ証明書の作成 =====
作成したCSRに署名を行って、サーバ証明書を発行する。<br>
作成したCSRに署名を行って、サーバ証明書を発行する。<br>
<u><サーバ証明書のファイル名>.csrファイルは、サーバ証明書を発行するためのファイルのため、削除してもよい。</u><br>
<u><サーバ証明書のファイル名>.csrファイルは、サーバ証明書を発行するためのファイルのため、後で削除してもよい。</u><br>
  openssl x509 -sha256 -req -days <証明書の有効日数 例. 3650> -in <CSRのファイル名>.csr -signkey <秘密鍵のファイル名>.key -out <サーバ証明書のファイル名>.crt
  openssl x509 -sha256 -req -days <証明書の有効日数 例. 3650> -in <CSRのファイル名>.csr -signkey <秘密鍵のファイル名>.key \
        -extfile san.txt \
        -out <サーバ証明書のファイル名>.crt
<br>
<br>
<u>クライアントPCがWindowsの場合、Windows PCにインポートするには、サーバ証明書のファイル(.crt拡張子)をpkcs12形式に変換する必要がある。</u><br>
<u>クライアントPCがWindowsの場合、Windows PCにインポートするには、サーバ証明書のファイル(.crt拡張子)をpkcs12形式に変換する必要がある。</u><br>
835行目: 1,290行目:
                         -out <クライアント側にインポートするサーバ証明書のファイル名>.p12 -name <任意の識別子名>
                         -out <クライアント側にインポートするサーバ証明書のファイル名>.p12 -name <任意の識別子名>
<br>
<br>
秘密鍵のファイルのアクセス権限を変更する。<br>
 
chmod 400 <秘密鍵のファイル名>.key
===== Webサーバの設定 =====
<br>
CSRファイルは、サーバ証明書を発行するためのファイルであるため、削除してもよい。<br>
<br>
<u>サーバに設置するものは、サーバ証明書のファイル(.crt拡張子)と秘密鍵(.key拡張子)の2つである。</u><br>
<u>サーバに設置するものは、サーバ証明書のファイル(.crt拡張子)と秘密鍵(.key拡張子)の2つである。</u><br>
<u>Windows PCへ配布するものは、pkcs12形式に変換したクライアント側のサーバ証明書のファイル(.p12拡張子)である。</u><br>
<u>Windows PC(クライアントPC)へ配布するものは、pkcs12形式に変換したクライアント側のサーバ証明書のファイル(.p12拡張子)である。</u><br>
<br>
<br>
Windows PCへクライアント側のサーバ証明書のファイル(.p12拡張子)をインポートする場合、ファイルを実行することによりインポート画面が起動するため、<br>
Windows PCへクライアント側のサーバ証明書のファイル(.p12拡張子)をインポートする場合、ファイルを実行することによりインポート画面が起動するため、<br>
867行目: 1,319行目:
  sudo systemctl restart nginx php-fpm
  sudo systemctl restart nginx php-fpm
<br><br>
<br><br>


__FORCETOC__
__FORCETOC__
[[カテゴリ:SUSE]]
[[カテゴリ:SUSE]][[カテゴリ:Web]]