「インストール - Nginx(RHEL)」の版間の差分

ナビゲーションに移動 検索に移動

インストール - Nginx(RHEL) (ソースを閲覧)

2023年12月3日 (日) 05:14時点における版

17,214 バイト追加 、 2023年12月3日 (日)
→‎仮想ホストの構築
725行目: 725行目:
  sudo systemctl start php-fpm
  sudo systemctl start php-fpm
  sudo systemctl start nginx
  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>
==== NnginXにおける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>
== 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>
<br><br>


「https://mochiuwiki.one/index.php/特別:携帯機器差分/8006」から取得

案内メニュー