MochiuWiki : SUSE, EC, PCB
案内
メインページ
最近の更新
おまかせ表示
MediaWiki についてのヘルプ
ツール
リンク元
関連ページの更新状況
特別ページ
ページ情報
We ask for
Donations
検索
個人用ツール
ログイン
Toggle dark mode
名前空間
ページ
議論
表示
閲覧
ソースを閲覧
履歴を表示
インストール - NginX(SUSE)のソースを表示
提供: MochiuWiki : SUSE, EC, PCB
←
インストール - NginX(SUSE)
あなたには「このページの編集」を行う権限がありません。理由は以下の通りです:
この操作は、次のグループのいずれかに属する利用者のみが実行できます:
管理者
、new-group。
このページのソースの閲覧やコピーができます。
== 概要 == NginXとは、Apacheと並ぶWebサーバソフトウェアの1つであり、処理速度や機能面で注目を集めている。<br> <br> NginXのメリットを、以下に示す。<br> * 高速である。 * 大量処理が得意である。 * Webサイトの利用を向上させる機能が豊富である。 * 設定が容易である。 <br> Webサーバに同時に複数のアクセスがあった場合、下表に示すように動作の違いがある。<br> <center> {| class="wikitable" | style="background-color:#fefefe;" |+ 動作方法の違いによる処理速度の向上 |- ! style="background-color:#66CCFF;" | ! style="background-color:#66CCFF;" | Apache 2 ! style="background-color:#66CCFF;" | NginX |- | style="background-color:#CFCFCF;" | 同時・複数アクセスへの対処方法 | 1アクセスに対して、1つの対応 || 複数のアクセスに対して、1つの対応にまとまる |- | style="background-color:#CFCFCF;" | アクセス急増時のサーバへの負荷 | 一気に負荷が増す || アクセスに比例して負荷は急激に増えない |- | style="background-color:#CFCFCF;" | その結果のWebサーバの挙動 | 動作が遅くなり、ダウンしやすくなる || 処理速度を維持して、ダウンしにくい |} </center> <br> 例えば、Webサーバの負担を軽くして処理速度を上げる手段として、リバースプロキシやロードバランサー等があり、これらを実現する場合、Nginxが向いている。<br> <br> NginXのデメリットを、以下に示す。<br> * 大量の動的コンテンツの処理に不向き *: 一般的には、大量の動的コンテンツの公開(動画を中心としたWebサイト等)には向かないことがNginXのデメリットとして挙げられる。 *: ただし、比較的小規模のWebサイトを運営する場合は、それほど神経質にならなくてもよい。 *: <br> * 機能追加のしやすさ *: 専用のモジュールを追加することにより、Nginxも機能を拡張することができる。 *: ただし、Apacheの方が、実装方法について比較的充実し、情報が豊富でわかりやすい。 *: <br> *: Apache モジュール一覧 *: https://httpd.apache.org/docs/trunk/ja/mod/ *: NGINX 3rd Party Modules *: https://www.nginx.com/resources/wiki/modules/ *: <br> * 初心者向けの設定情報の少なさ *: 設定等の情報が少ない。 <br> <center> {| class="wikitable" | style="background-color:#fefefe;" ! colspan="4" style="background-color:#44CC99;" | 参考書 |- style="text-align: center;" | 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> | 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="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> | 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> <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> == NginXのインストール方法 == ==== パッケージ管理システムからインストール ==== まず、システムの更新を行う。<br> sudo zypper update <br> 次に、NginXをインストールする。<br> NginXは、CentOSやSUSEの公式リポジトリからインストールできる。<br> ただし、常に最新バージョンが提供されるとは限らない。<br> sudo zypper install nginx <br> NginXサービスを自動起動する。<br> sudo systemctl enable nginx <br> NginXを開始する。<br> sudo systemctl start nginx <br> NginXのステータスを確認する場合は、次のコマンドを実行する。<br> sudo sytemctl status nginx <br> ==== ソースコードからインストール ==== NginXのビルドに必要なライブラリをインストールする。<br> sudo zypper install libxslt-devel pcre2-devel gd-devel zlib-devel \ 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> 必要ならば、[https://www.openssl.org/source/ OpenSSLの公式Webサイト]にアクセスして、OpenSSL(1.X.Y)のソースコードをダウンロードする。<br> ダウンロードしたファイルを解凍する。<br> 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> [https://nginx.org/en/download.html NginXの公式Webサイト]にアクセスして、NginXのソースコードをダウンロードする。<br> ダウンロードしたファイルを解凍する。<br> tar xf nginx-<バージョン>.tar.xz cd nginx-<バージョン> <br> NginXをビルドおよびインストールする。<br> <br> Digest認証モジュールも併せてビルドおよびインストールする場合、<br> <code>configure</code>スクリプトにおいて、<code>--add-module=<Digest認証モジュールのソースコードがあるディレクトリ></code>オプションを付加する。<br> <br> <u>NginXのビルドにおいて、ビルドディレクトリを作成すると失敗することに注意する。</u><br> export NGINX_DIR=<NginXのインストールディレクトリ> ./configure \ --prefix=$NGINX_DIR \ --sbin-path=$NGINX_DIR/sbin/nginx \ --conf-path=$NGINX_DIR/etc/nginx.conf \ --pid-path=$NGINX_DIR/nginx.pid \ --modules-path=$NGINX_DIR/modules/ \ --error-log-path=$NGINX_DIR/log/error.log \ --http-log-path=$NGINX_DIR/log/access.log \ --lock-path=$NGINX_DIR/nginx.lock \ --http-client-body-temp-path=$NGINX_DIR/tmp/ \ --http-proxy-temp-path=$NGINX_DIR/proxy/ \ --http-fastcgi-temp-path=$NGINX_DIR/fastcgi/ \ --http-uwsgi-temp-path=$NGINX_DIR/uwsgi/ \ --http-scgi-temp-path=$NGINX_DIR/scgi/ \ --with-perl_modules_path=$NGINX_DIR/Perl \ --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_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_image_filter_module --with-http_image_filter_module=dynamic \ --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_perl_module --with-http_perl_module=dynamic \ --with-mail --with-mail=dynamic --with-mail_ssl_module \ --with-stream=dynamic --with-stream_ssl_module --with-stream_realip_module --with-stream_ssl_preread_module \ --with-compat \ --with-ipv6 \ # ただし、1.24以降は無効 --user=<任意のユーザ名 例. nginx> \ --group=<任意のグループ名 例. nginx> # 不要の可能性あり --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を手動で設定する場合に記述する --with-openssl=<上記でダウンロードおよび解凍したOpenSSLのソースコードのトップディレクトリ> # 以下の設定は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-ld-opt='-Wl,-z,relro,-z,now -pie' make -j $(nproc) make install <br> configureスクリプト実行時において、<code>--user=<ユーザ名></code>および<code>--group=<グループ名></code>を付加した場合、それぞれユーザとグループを作成する必要がある。<br> sudo useradd --system --no-create-home --user-group --shell /sbin/nologin nginx <br> Systemdサービスユニットを作成しない場合、NginXを開始するには、以下のコマンドを実行する。<br> cd <NginXのインストールディレクトリ>/sbin sudo ./nginx <br> Systemdサービスユニットを作成しない場合、NginXを停止するには、以下のコマンドを実行する。<br> * 方法 1 *: <code>cd <NginXのインストールディレクトリ>/sbin</code> *: <code>sudo ./nginx -s stop</code> *: または *: <code>sudo ./nginx -s quit</code> *: <br> * 方法 2 *: まず、NginXのプロセスIDを確認する。 *: <code>ps aux | grep -i nginx</code> *: NginXを停止する。 *: <code>sudo kill <プロセスID 1> <プロセスID 2></code> <br> Systemdサービスユニットを作成しない場合、NginXを再起動するには、以下のコマンドを実行する。<br> cd <NginXのインストールディレクトリ>/sbin sudo ./nginx -s reload # または sudo ./nginx -s reopen <br> Systemdサービスユニットを作成する場合、/etc/systemd/systemディレクトリに、以下に示すような内容で作成する。<br> sudo vi /etc/systemd/system/nginx.service <br> <syntaxhighlight lang="ini"> # /etc/systemd/system/nginx.serviceファイル [Unit] Description=The nginx HTTP and reverse proxy server After=network-online.target remote-fs.target nss-lookup.target Wants=network-online.target [Service] PIDFile=/<NginXのインストールディレクトリ>/nginx.pid ExecStartPre=/<NginXのインストールディレクトリ>/sbin/nginx -t ExecStart=/<NginXのインストールディレクトリ>/sbin/nginx -g "daemon off;" ExecReload=/bin/kill -s HUP $MAINPID KillSignal=SIGQUIT TimeoutStopSec=5 KillMode=mixed PrivateTmp=true # added automatically, for details please see # https://en.opensuse.org/openSUSE:Security_Features#Systemd_hardening_effort ProtectSystem=full #ProtectHome=read-only PrivateDevices=true ProtectHostname=true ProtectClock=true ProtectKernelTunables=true ProtectKernelModules=true ProtectKernelLogs=true ProtectControlGroups=true RestrictRealtime=true # end of automatic additions [Install] WantedBy=multi-user.target </syntaxhighlight> <br> NginXを開始する。<br> sudo systemctl start nginx <br> NginXを停止する。<br> sudo systemctl stop nginx <br> NginXを再起動する。<br> sudo systemctl restart nginx <br> NginXを自動起動する。<br> sudo systemctl enable nginx <br> NginXの設定ファイルの内容を変更した時、変更を反映させるためにNginXを再読み込みする。<br> 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> == ファイアウォールの設定 == 次に、ファイアウォール設定にいくつかの変更を加えて、httpサービスを許可する。<br> sudo firewall-cmd --permanent --add-port=80/tcp sudo firewall-cmd --reload <br><br> == Nginxのテスト == Nginxが正しく実行されていることを確認する。<br> これを行うには、htmlファイルを作成し、それをNginxのルートディレクトリに配置する必要がある。<br> テキストエディタで以下のファイルを作成する。<br> <nowiki> sudo nano /srv/www/htdocs/index.html <html> <body> <h1>Welcome to osradar</h1> </body> </html> </nowiki> <br> 最後に、Webブラウザを開き、http://localhost/ にアクセスして、これが表示されるか確認する。<br> <br><br> == NginX上でPHP-FPM(PHP 7 / 8)の有効化 == NginXにはPHPモジュールが無いため、CGIによりプログラムを動作させている。<br> PHPをNginX上で動作させるためには、PHP-FPM(PHP-FastCGI Process Manager)に対して、設定を行う必要がある。<br> <br> 必要な場合、PHP-FPMのソケットファイルを配置するディレクトリを作成する。<br> mkdir /<PHPのインストールディレクトリ>/var/run/php-fpm <br> PHP-FPMの構成ディレクトリ(/etc/php7/fpm)にあるphp-fpm.confファイルのerror_logキーを以下のように編集する。<br> # PHP 7 sudo cp /etc/php7/fpm/php-fpm.conf.default /etc/php7/fpm/php-fpm.conf # PHP 8 sudo cp /etc/php8/fpm/php-fpm.conf.default /etc/php8/fpm/php-fpm.conf <br> # PHP 7 sudo vi /etc/php7/fpm/php-fpm.conf # PHP 8 sudo vi /etc/php8/fpm/php-fpm.conf <br> # /etc/php7/fpm/php-fpm.confファイル または /etc/php8/fpm/php-fpm.confファイル error_log = /var/log/php-fpm.log <br> 次に、www.conf構成ファイルで構成済みプールの正しい設定を定義する。 # PHP 7 sudo cp /etc/php7/fpm/php-fpm.d/www.conf.default /etc/php7/fpm/php-fpm.d/www.conf # PHP 8 sudo cp /etc/php8/fpm/php-fpm.d/www.conf.default /etc/php8/fpm/php-fpm.d/www.conf <br> # PHP 7 sudo vi /etc/php7/fpm/php-fpm.d/www.conf # PHP 8 sudo vi /etc/php8/fpm/php-fpm.d/www.conf <br> # /etc/php7/fpm/php-fpm.d/www.confファイル または /etc/php8/fpm/php-fpm.d/www.confファイル user = <Nginxの実行ユーザ名 (例. nginx)> group = <Nginxの実行グループ名 (例. nginx)> listen = <nginx.confファイルで設定したfastcgi_passの値 (例. /var/run/php-fpm/php-fpm.sock)> listen.owner = <PHP-FPMの実行ユーザ名 (例. nginx)> listen.group = <PHP-FPMの実行グループ名 (例. nginx)> <br> 次に、/etc/php7/cli/php.iniファイル、または、/etc/php8/cli/php.iniファイルを作成・編集する。<br> # PHP 7 sudo vi /etc/php7/cli/php.ini # PHP 8 sudo vi /etc/php8/cli/php.ini <br> # /etc/php7/cli/php.iniファイル または /etc/php8/cli/php.iniファイル cgi.fix_pathinfo=0 <br> '''----- ここは不要かも？ -----'''<br> 次に、/etc/php7/fpm/php.iniファイルを作成・編集する。<br> php.iniファイルをコピーして、php.iniファイルのcgi.fixキーを編集する。<br> sudo cp /etc/php7/cli/php.ini /etc/php7/fpm/ <br> sudo vi /etc/php7/fpm/php.ini # /etc/php7/fpm/php.iniファイル cgi.fix_pathinfo=0 <br> そして、/etc/php7/fpm/php.iniファイルをPHP構成ディレクトリにコピーする。<br> sudo cp /etc/php7/fpm/php.ini /etc/php7/conf.d/ '''----- ここまで -----'''<br> <br><br> == NginXの設定 == NginXを構成するため、NginXの設定ファイルであるnginx.confファイルを、以下に示すような内容で編集する。<br> # パッケージ管理システムからインストールしている場合 sudo vi /etc/nginx/nginx.conf # ソースコードからインストールしている場合 sudo vi /<Nginxのインストールディレクトリ>/etc/nginx.conf <br> <syntaxhighlight lang="nginx"> # 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 { # ...略 # 設定ファイルの読み込み #include /etc/nginx/conf.d/ssl.conf #include /etc/nginx/vhost.d/*.conf server { listen 80; server_name localhost; #charset koi8-r; access_log <アクセスログファイルのフルパス>; # 例1. log/localhost.log; # 例2. /srv/www/htdoc/log/localhost.log; # IPフィルタリング # 上にあるルールが優先 #allow all; #deny all; # インデックスファイルが存在しない場合、ファイル一覧を有効化 / 無効化 autoindex on; location / { root <ドキュメントルートのパス(絶対パスまたは相対パス)>; # 例1. html; # 例2. /srv/www/htdoc; index index.php index.html index.htm; } error_page 404 /404.html; location = /404.html { root <ドキュメントルートのパス(絶対パスまたは相対パス)>; # 例1. html; # 例2. /srv/www/htdoc; } # redirect server error pages to the static page /50x.html # error_page 500 502 503 504 /50x.html; location = /50x.html { root <ドキュメントルートのパス(絶対パスまたは相対パス)>; # 例1. html; # 例2. /srv/www/htdoc; } # proxy the PHP scripts to Apache listening on 127.0.0.1:80 # #location ~ \.php$ { # proxy_pass http://127.0.0.1; #} # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000 # #location ~ \.php$ { # root <ドキュメントルートのパス(絶対パスまたは相対パス)>; # # 例1. html; # # 例2. /srv/www/htdoc; # fastcgi_pass 127.0.0.1:9000; # fastcgi_index index.php; # fastcgi_param SCRIPT_FILENAME /scripts$fastcgi_script_name; # include fastcgi_params; #} # このセクションは、NginXからPHP-FPMの通信は # Unixドメインソケット通信でlistenしているFastCGIサーバにPHPスクリプトを渡すために使用される location ~ \.php$ { root <ドキュメントルートのパス(絶対パスまたは相対パス)>; # 例1. html; # 例2. /srv/www/htdoc; fastcgi_pass <PHP-FPMのソケットファイルのフルパス>; # 例1. unix:/<PHPのインストールディレクトリ>/var/run/php-fpm.sock; # 例2. unix:/var/run/php-fpm/php-fpm.sock; fastcgi_index index.php; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; include fastcgi_params; } # ApacheのドキュメントルートがNginXのドキュメントルートと一致する場合、.htaccessファイルへのアクセスを拒否する #location ~ /\.ht { # deny all; #} } # ...略 } </syntaxhighlight> <br> NginXおよびPHP-FPMを起動する。<br> sudo systemctl restart nginx php-fpm <br> Webブラウザを起動した後、http://localhost/index.php にアクセスして、正常に表示されるか確認する。<br> <br><br> == 仮想ホストの構築 == パッケージ管理システムからNginXをインストールした場合、/etc/nginx/vhosts.dディレクトリ内に、Webサイトの設定ファイルを複数作成することができる。<br> 一般的には、1つのWebサイトごとに1ファイル、<ドメイン名>.confのような名前を付ける。<br> <br> NginXの設定ファイルを編集する。<br> # パッケージ管理システムからインストールしている場合 sudo vi /etc/nginx/nginx.conf # ソースコードからインストールしている場合 sudo vi /<Nginxのインストールディレクトリ>/etc/nginx.conf <br> <syntaxhighlight lang="nginx"> # nginx.confファイル http { # ...略 server { listen <ポート番号 例. 80>; server_name <ドメイン名 例. virtualhost01> alias <ドメイン名 例. virtualhost01>.alias; access_log <ログファイルのフルパス> # 例. log/vhost.access.log; error_page 404 /404.html; location = /404.html { root <仮想ホストのドキュメントルート>; } # redirect server error pages to the static page /50x.html # error_page 500 502 503 504 /50x.html; location = /50x.html { root <仮想ホストのドキュメントルート>; } location / { root <仮想ホストのドキュメントルート>; index index.php index.html index.htm; } # このセクションは、NginxからPHP-FPMの通信はUnixドメインソケット通信でlistenしているFastCGIサーバにPHPスクリプトを渡すために使用される location ~ \.php$ { root <仮想ホストのドキュメントルート>; fastcgi_pass unix:<PHP-FPMのソケットのパス>; # 例1. unix:/var/run/php-fpm/php-fpm.sock; # 例2. unix:/home/user/PHP/var/run/php-fpm/php-fpm.sock; fastcgi_index index.php; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; # proxy_pass http://127.0.0.1; } } # ...略 } </syntaxhighlight> <br> 一般的に、仮想ホストの設定ファイルは、/etc/nginx/vhost.dディレクトリ、または、/<NginXのインストールディレクトリ>/etc/vhosts.dディレクトリに配置する。<br> # パッケージ管理システムからインストールしている場合 sudo vi /etc/nginx/vhost.d/vhost1.conf # ソースコードからインストールしている場合 sudo vi /<Nginxのインストールディレクトリ>/etc/vhost.d/vhost1.conf <br> <syntaxhighlight lang="nginx"> # vhost1.confファイル server { listen <ポート番号 例. 80>; server_name <ドメイン名 例. virtualhost01> alias <ドメイン名 例. virtualhost01>.alias; access_log <ログファイルのフルパス> # 例. log/vhost.access.log; error_page 404 /404.html; location = /404.html { root <仮想ホストのドキュメントルート>; } # redirect server error pages to the static page /50x.html # error_page 500 502 503 504 /50x.html; location = /50x.html { root <仮想ホストのドキュメントルート>; } location / { root <仮想ホストのドキュメントルート>; index index.php index.html index.htm; } # このセクションは、NginxからPHP-FPMの通信はUnixドメインソケット通信でlistenしているFastCGIサーバにPHPスクリプトを渡すために使用される location ~ \.php$ { root <仮想ホストのドキュメントルート>; fastcgi_pass unix:<PHP-FPMのソケットのパス>; # 例1. unix:/var/run/php-fpm/php-fpm.sock; # 例2. unix:/home/user/PHP/var/run/php-fpm/php-fpm.sock; fastcgi_index index.php; include fastcgi_params; fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; # proxy_pass http://127.0.0.1; } } </syntaxhighlight> <br> 上記で作成した仮想ホストの設定ファイルを読み込むため、NginXの設定ファイルを編集する。<br> # パッケージ管理システムからインストールしている場合 sudo vi /etc/nginx/nginx.conf # ソースコードからインストールしている場合 sudo vi /<Nginxのインストールディレクトリ>/etc/nginx.conf <br> <syntaxhighlight lang="nginx"> # nginx.confファイル http { # ...略 include /<NginXのvhost.dディレクトリのフルパス>/*.conf # 例1. /etc/nginx/vhosts.d/*.conf; # 例2. /<NginXのインストールディレクトリ>/etc/vhosts.d/*.conf; server { # ...略 } # ...略 } </syntaxhighlight> <br> 仮想ホストにアクセスできるようにするため、/etc/hostsファイルに仮想ホスト名と対応するIPアドレスを追記する。<br> sudo vi /etc/hosts <br> # /etc/hostsファイル <仮想ホストで使用するIPアドレス> <仮想ホスト名> <br> NginXとPHP-FPMを起動する。<br> sudo systemctl start php-fpm sudo systemctl start nginx <br><br> == ログフォーマット == <center> {| class="wikitable" | style="background-color:#fefefe;" |+ Apache2とNginXのログフォーマット |- ! style="background-color:#66CCFF;" | Apache2 ! style="background-color:#66CCFF;" | NginX ! style="background-color:#66CCFF;" | 説明 |- | %a || $remote_addr || リモートIPアドレス |- | %A || $server_addr || ローカルIPアドレス |- | %b || $body_bytes_sent || レスポンスのバイト数(HTTPヘッダは除く)<br>CLF書式において、0の時は-(ハイフン)になる。 |- | %B || $body_bytes_sent || レスポンスのバイト数(HTTPヘッダは除く) |- | %D || - || リクエストを処理するのに掛かった時間(マイクロ秒単位) |- | %f || $request_filename || リクエストされたファイル名 |- | %h || - || リモートホスト名 |- | %H || $server_protocol || リクエストプロトコル名 |- | %K || - || keepaliveのコネクション数 |- | %l || - || リモートログ名 |- | %m || $request_method || リクエストメソッド(GET) |- | %p || $server_port || リクエストを受けたポート番号 |- | %P || $pid || 子プロセスID |- | %q || $query_string || クエリ文字列<br>例. <code>http://example.com/test.php?id=12345 -> ?id=12345</code> |- | %r || $request || リクエストの最初の行<br>基本的には、%m %U$q %Hとした設定と同様 |- | %s || $status || ステータスコード |- | %t || $time_local || リクエストを受け付けた日時<br>[11/Aug/2017:12:34:56 +0900] |- | %{format}t || - || <code>format</code>で与えられた書式による時刻 |- | %T || $request_time || リクエストを受けてから応答するまでの処理時間(秒)<br>%Dの秒数バージョン |- | %u || $remote_user || リモートユーザ名 |- | %U || $request_uri || リクエストされたパス |- | %v || $server_name || サーバのServerNameの値 |- | %V || $server_name || UseCanonicalNameで指定されたサーバ名 |- | %X || $request_completion || 応答が完了したときの接続ステータス<br>書式 : aborted + = kept alive - = closed |- | %I || $request_length || リクエストとヘッダを含む受け取ったバイト数 |- | %O || $bytes_sent || ヘッダを含むサーバから送信されたバイト数 |- | %{Referer}i || $http_referer || リファラー |- | %{User-Agent}i || $http_user_agent || ユーザエージェント名 |} </center> <br> <center> {| class="wikitable" | style="background-color:#fefefe;" |+ NginXのみのログフォーマット |- ! style="background-color:#66CCFF;" | ログフォーマット ! style="background-color:#66CCFF;" | 説明 |- | $args || リクエスト行の引数 |- | $binary_remote_addr || $remote_addrのバイナリ出力 |- | $connection || コネクションのシリアル番号 |- | $connection_requests || コネクションを経由した現在のリクエスト数 |- | $content_length || Content-Lengthのリクエストヘッダフィールド<br><br>Content-Lengthとは、HTTPヘッダの項目であり、渡すデータのサイズが入っている。 |- | $content_type || Content-Typeのリクエストヘッダフィールド<br><br>Content-Typeとは、ヘッダで最も一般的に用いられる項目の1つであり、<br>ボディ部に積載したデータの種類や形式（メディアタイプ）を指定する。<br>主に、サーバがクライアントに送信するHTTPレスポンスの中で送信データの形式を伝えるために用いるが、<br>クライアントがフォームなどから送信するPOSTデータの形式を知らせるのにも用いられる。 |- | $document_root || 現在のリクエストに対するルートディレクティブおよびエイリアスディレクティブの値 |- | $document_uri || $uriと同じ |- | $host || サーバホスト名 |- | $hostname || ホスト名 |- | $https || 接続がSSLモードで動作している場合は"on"、それ以外の場合は空文字列となる。 |- | $limit_rate || この変数を設定することにより、応答速度制限を行うことができる。 |- | $msec || 現在の時刻をミリ秒単位で表示する。 |- | $nginx_version || NginXのバージョン |- | $pipe || リクエストがパイプライン化されている場合は"p"、それ以外の場合は"." |- | $proxy_protocol_addr || Proxyプロトコルヘッダからのクライアントアドレスを表示する。<br>それ以外は空文字列となる。 |- | $realpath_root || $document_rootの実パス名 |- | $remote_port || クライアントのポート番号を表示する、 |- | $request_body || リクエストボディを表示する。 |- | $request_body_file || リクエストボディを格納した一時ファイル名を表示する。 |- | $scheme || http |- | $sent_http_name || 任意のレスポンスヘッダフィールドを表示する。 |- | $time_iso8601 || ローカルタイム（ISO 8601標準)を表示する。 |} </center> <br><br> == 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 ==== 値 : on / off<br> 初期値 : on<br> 使用環境 : http, server.location<br> <br> 小さなパケットを大きなパケットに合成して、帯域幅の利用率を向上させる。(nagleアルゴリズム)<br> TCPプロトコルでは、<u>アプリケーション層のデータが非常に少なく（1バイト程度）、かつ、トランスポート層のオーバーヘッドが40バイト（IPヘッダ20バイト + TCPヘッダ20バイト）にもなる現象</u>がある。<br> この場合、送信データの多くは制御パケットであるため、帯域消費量が増加して、帯域利用率が悪くなる。(ネットワークに輻輳が発生しやすくなる)<br> <br> この問題を解決するため、新規に生成されたパケットは送信データが確認されるまで、あるいは、相手側からの確認応答があるまで、<br> 1MSSに切り上げる、または、確認応答があるまで待った後にタイムアウトまで送信する。<br> ネットワークの輻輳を避けるため、TCPスタックは0.2秒(Unixの実装の値)までデータを待つメカニズムを実装しており、小さすぎるパケットを送信することはない。<br> <br> 例えば、あるソフトウェアが小さなデータの送信を要求してきたとする。 すぐに送信する、または、データが生成されるのを待って再度送信するかを選択することができるとする。 もし、データをすぐに送ることができれば、インタラクティブでクライアントサーバタイプのソフトウェアは大きなメリットを得ることができる。 また、リクエストを即座に送信すれば、レスポンスも速くなる。 <br> ただし、ネットワーク上でデータをストリーミングする必要がある場合、逆効果になる可能性がある。<br> ファイル転送を行う場合、転送するごとにクライアント側で0.2秒の遅延を発生させるからである。<br> <br> ==== tcp_nopush ==== 値 : on / off<br> 初期値 : off<br> 使用環境 : http, server.location<br> <br> TCP/IPにおける転送の標準であるtcp_corkの設定である。(tcp_nodelayとは逆の働きをする)<br> 遅延を最適化する代わりに、1度に送信するデータ量を最適化する。<br> <br> tcp_nopushを有効にする場合、tcp_corkメソッドが呼ばれるようになるため、パケットはすぐに送信されず、パケットが最大になった時に一気に送信される。(ネットワークの輻輳や混雑を解決する)<br> (一般的な意味は、TCP通信において、ソフトウェアがパケットを受信した時、すぐに転送することである)<br> <br> ==== sendfile ==== 値 : on / off<br> 初期値 : off<br> 使用環境 : http, server.location, server.locationのif文<br> <br> sendfileが有効になっている場合、NginXはデータ転送を行う時に<code>sendfile</code>関数(システムコール)を呼び出す。<br> <code>sendfile</code>関数は、Linuxカーネル 2.0以降で導入されたシステムコールである。<br> <br> 通常のネットワークでのデータ転送に比べて、スイッチの数が少なく、転送するデータのコピー数も少ない。<br> <br> <code>sendfile</code>関数は、2つのファイルディスクリプタ間で直接データを渡すため（カーネル内での動作）、カーネルバッファとユーザバッファ間のデータのコピーを回避して、<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> == エラー関連 == ==== test failed ==== Webサイトにアクセスする時、<u>"test failed"</u>というエラーメッセージが表示される場合がある。<br> これは、NginXの初期設定ではIPv4とIPv6をリッスンするが、使用しているWebサーバがIPv6をサポートしていない場合に起きる。<br> <br> nginx.confファイルにおいて、IPv6を使用しないように設定する。<br> vi nginx.conf <br> # nginx.confファイル # 編集前 listen [::]:80 default_server; # 編集後 # listen [::]:80 default_server; <br> NginXを再読み込みする。<br> sudo systemctl reload nginx <br><br> == HTTPS（SSL）の設定 == ==== CSRについて ==== CSR(Certificate Signing Request)とは、証明書発行要求といい、認証局に対して行う、認証局の秘密鍵で署名してもらうためのリクエストのことである。<br> <br> CSRの中身を確認するためには、<code>req</code>コマンドに<code>-text</code>オプションを付加することで確認できる。<br> openssl req -text -in <サーバ証明書のファイル名>.csr # 出力例 Certificate Request: Data: Version: 0 (0x0) Subject: C=JP, ST=TOKYO, L=KAWASAKI, O=Kaisha, OU=Busho, CN=common.name Subject Public Key Info: Public Key Algorithm: rsaEncryption Public-Key: (2048 bit) （省略） Signature Algorithm: sha256WithRSAEncryption （省略） <br> 上記の出力例において、[Signature Algorithm]項目は、sha256WithRSAEncryptionである。<br> SHA-1は解読されるリスクが高まっているため、今後作成するものはSHA-2とするべきである。<br> <br> SHA-2には、SHA-224、SHA-256、SHA-384、SHA-512の4種類がある。<br> SHA-512が最も安全性が高いが、クライアント端末側がSHA-512に対応している必要がある。<br> <br> ==== 自己署名証明書の発行(サーバ側) ==== ===== 秘密鍵を作成する ===== openssl genrsa -out <秘密鍵のファイル名>.key 2048 <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 <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> <u><サーバ証明書のファイル名>.csrファイルは、サーバ証明書を発行するためのファイルのため、後で削除してもよい。</u><br> openssl x509 -sha256 -req -days <証明書の有効日数 例. 3650> -in <CSRのファイル名>.csr -signkey <秘密鍵のファイル名>.key \ -extfile san.txt \ -out <サーバ証明書のファイル名>.crt <br> ===== Webサーバの設定 ===== Webサーバに設置するものは、秘密鍵（.key拡張子）とサーバ証明書（.crt拡張子）の2つである。<br> <br> SSLを有効にするため、NginXの設定ファイルを編集する。<br> # パッケージ管理システムからインストールしている場合 sudo vi /etc/nginx/nginx.conf # ソースコードからインストールしている場合 sudo vi /<Nginxのインストールディレクトリ>/etc/nginx.conf <br> <syntaxhighlight lang="nginx"> # HTTPS server server { listen 443 ssl; # HTTP/2を有効にする場合は、http2と追記する server_name <ホスト名またはIPアドレスまたはドメイン名>; # サーバ証明書および中間証明書のファイルの指定 ssl_certificate <サーバ証明書のファイルのフルパス>; # 秘密鍵の指定 ssl_certificate_key <秘密鍵のファイルのフルパス>; ssl_session_cache shared:SSL:1m; ssl_session_timeout 5m; ssl_ciphers HIGH:!aNULL:!MD5; ssl_prefer_server_ciphers on; location / { root <ドキュメントルートのパス(絶対パスまたは相対パス)>; index index.html index.htm; } } </syntaxhighlight> <br> <u>ロードバランサにSSL証明書を設置して、SSL接続を終端することもできる。</u><br> <u>その場合、サーバ証明書は1つ用意して、ロードバランサからWebサーバまでの通信はhttpとなる。（httpsでも可能であるが、httpの方が負荷が軽いため）</u><br> <br> <u>httpを使用するメリットとして、Webサーバで受けるアクセスがhttpとなるので負荷が減るためである。(暗号化された通信を複合するために、SSLの接続を受けるのは負荷が掛かる)</u><br> <br> ==== 自己証明書の発行(クライアント側) ==== ===== 秘密鍵を作成する ===== openssl genrsa -out <秘密鍵のファイル名>.key 2048 <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 <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> <u><サーバ証明書のファイル名>.csrファイルは、サーバ証明書を発行するためのファイルのため、後で削除してもよい。</u><br> openssl x509 -sha256 -req -days <証明書の有効日数 例. 3650> -in <CSRのファイル名>.csr -signkey <秘密鍵のファイル名>.key \ -extfile san.txt \ -out <サーバ証明書のファイル名>.crt <br> <u>クライアントPCがWindowsの場合、Windows PCにインポートするには、サーバ証明書のファイル(.crt拡張子)をpkcs12形式に変換する必要がある。</u><br> openssl pkcs12 -export -inkey <秘密鍵のファイル名>.key -in <サーバ証明書のファイル名>.crt \ -out <クライアント側にインポートするサーバ証明書のファイル名>.p12 -name <任意の識別子名> <br> ===== Webサーバの設定 ===== <u>サーバに設置するものは、サーバ証明書のファイル（.crt拡張子）と秘密鍵（.key拡張子）の2つである。</u><br> <u>Windows PC(クライアントPC)へ配布するものは、pkcs12形式に変換したクライアント側のサーバ証明書のファイル(.p12拡張子)である。</u><br> <br> Windows PCへクライアント側のサーバ証明書のファイル(.p12拡張子)をインポートする場合、ファイルを実行することによりインポート画面が起動するため、<br> インポート画面に沿って、サーバ証明書のファイル(.p12拡張子)をインポートする。<br> <br><br> == Xdebugの設定 == PHP-FPMの初期設定では、9000番ポートを使用している。<br> もし、古いバージョンのXdebug(バージョン2.x)を使用している場合、デフォルトのデバッグポートは9000番ポートを使用しているため、競合が発生する。<br> そのため、古いバージョンのXdebug(バージョン2.x)を使用する場合は、Xdebugのデバッグポートを変更する必要がある。<br> # PHP 7の場合 sudo vi /etc/php7/conf.d/xdebug.ini # PHP 8の場合 sudo vi /etc/php8/conf.d/xdebug.ini # ソースコードからPHPをインストールしている場合 vi /<PHPのインストールディレクトリ>/etc/php.ini <br> # xdebug.iniファイル または php.iniファイル xdebug.remote_port=<9000以外の値 例. 9003> <br> NginXとPHP-FPMを再起動する。<br> sudo systemctl restart nginx php-fpm <br><br> __FORCETOC__ [[カテゴリ:SUSE]][[カテゴリ:Web]]
インストール - NginX(SUSE)
に戻る。
案内
メインページ
最近の更新
おまかせ表示
MediaWiki についてのヘルプ
ツール
リンク元
関連ページの更新状況
特別ページ
ページ情報
We ask for
Donations
Collapse
