
アクセス元のIPをログに残したい場合、通常のApacheの設定ではLogFormatに`%h`で出力します。
ただし、ロードバランサーなどプロキシサーバを経由した場合に`%h`に出力されるIPはプロキシサーバのIP（ローカルIP）になってしまいます。

HTTPヘッダーにアクセス元のIと経由したプロキシのIPを保持する規格`X-Forwarded-For`があります。
`X-Forwarded-For`を出力することでアクセス元のIPのログを残す設定を紹介します。

ELBのApplication Load Balancerで話を進めます。

## X-Forwarded-Forを出力するconfの設定

`LogFormat`に`%{X-Forwarded-For}i`を入れます。
`%{Foobar}i`でHTTPヘッダーのFoobarの値を出力します。

```diff
-- LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
++ LogFormat "%{X-Forwarded-For}i %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined

CustomLog "|/usr/sbin/rotatelogs /var/log/httpd/access_log.%Y%m%d 86400 540" combined
```

書式は`X-Forwarded-For: <client>, <proxy1>, <proxy2>`です。

[ELBとApacheの例 | aws.amazon.com](https://aws.amazon.com/jp/premiumsupport/knowledge-center/elb-capture-client-ip-addresses/)

## RemoteIPHeader X-Forwarded-Forの場合

`RemoteIPHeader` はApache内部で送信元IPを置き換えるのに使うヘッダーを指定します。

アクセス制御などのため`RemoteIPHeader X-Forwarded-For`を設定すると、`%{X-Forwarded-For}i`の中身が`‐`になりました。
この場合の書式は、`%{X-Forwarded-For}i`ではなくリモートIPアドレス`%a`とする。

例: アクセス制限している場合
```conf
RemoteIPHeader X-Forwarded-For

LogFormat "%a %h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
CustomLog "|/usr/sbin/rotatelogs /var/log/httpd/access_log.%Y%m%d 86400 540" combined

<Location /admin>
    AllowOverride   All
    Deny from all
    Allow from xxx.xx.xxx.x
    Allow from yyy.yyy.yy.yy/28
</Location>
```
`Allow from`で指定するIPが`X-Forwarded-For`にあるIPになるように`RemoteIPHeader X-Forwarded-For`を設定しています。
LogFormatに`%a`を加えています。

[Apache CustomLogの書式 | httpd.apache.org](https://httpd.apache.org/docs/2.4/ja/mod/mod_log_config.html)に

## IPについて

ちょうど「香川県ネット・ゲーム依存症対策条例」に関しての賛同パブコメのIPがローカルIPだったことが話題になってます。

> 「192.168.7.21」はどのような場合に表示されるのか、香川県議会事務局に聞いたところ、次のような回答がありました。
> 
> 「香川県議会ホームページにご意見・お問い合わせというフォームがあり、そこから送られたものを印刷するとどれもこのような表示になります」（議会事務局）
> 
> 事務局によると、賛成・反対を問わず、県議会ホームページの「ご意見・お問い合わせ」フォームから送信した場合は一律でこの表示になるとのこと。確かに、県のホームページ内から転送されたものであれば、プライベートIPアドレスが記載されていることにも一応の説明はつきます。
> 
> [ゲーム条例パブコメ、同一IPアドレスからの送信が多数？　原本公開で“工作疑惑”広がる → 香川県議会に見解を聞いた | ねとらぼ](https://nlab.itmedia.co.jp/nl/articles/2004/14/news081.html)

個人的に、ゲーム依存症の対策のために条例で時間制限することはやりすぎだと感じます。
この件に関してパブコメの賛同意見に水増しがあったか疑惑が残るが断定できません。
開示されたら続報が出るはず。

ここでの問題は、IPアドレス情報を残しているのに意味がない。
仮にクライアントIPを取れていたら、個人情報には当たらないけど公開するは控えたほうがいいかな。

インフラ屋としてはこういった問題が起きた場合に話題になっても恥ずかしくないインフラ設計・設定を心掛けたい。


LB経由のサーバでクライアントIPをログに残すApacheの設定 X-Forwarded-For



この記事では`.htaccess`の設定内容を解説していきます。

## Laravelの.htaccessについて

Laravelのプロジェクトにアクセスがあると`public/index.php`を経由して`route`に振り分けられます。
その時、URIが画像やCSSなどpubilicディレクトリに存在するファイルを指している時はそのファイルを返し、それ以外は`route`に設定したページが返るような制御が行われています。
この制御部分を設定しているのが`public/.htaccess`です。

```sh
<IfModule mod_rewrite.c>
    <IfModule mod_negotiation.c>
        Options -MultiViews -Indexes
    </IfModule>

    RewriteEngine On

    # Handle Authorization Header
    RewriteCond %{HTTP:Authorization} .
    RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]

    # Redirect Trailing Slashes If Not A Folder...
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_URI} (.+)/$
    RewriteRule ^ %1 [L,R=301]

    # Send Requests To Front Controller...
    RewriteCond %{REQUEST_FILENAME} !-d
    RewriteCond %{REQUEST_FILENAME} !-f
    RewriteRule ^ index.php [L]
</IfModule>
```
[Laravel github .htaccess](https://github.com/laravel/laravel/blob/master/public/.htaccess)

### mod_rewrite
`mod_rewrite`はPCRE正規表現パーサーに基づくルールベースの書き換えエンジンです。
アクセスしてきたURLやヘッダーを書き換えたり、リダイレクトしたりする機能です。
`RewriteEngine On`はこの機能を有効にします。
あとで説明しますが`RewriteCond`は条件を示し、それに合うものが`RewriteRule`によって書き換えられます。

[Apache Module mod_rewrite | httpd.apache.org](https://httpd.apache.org/docs/2.4/en/mod/mod_rewrite.html)

### mod_negotiation

`mod_negotiation`はURIと合うディレクトリ内のファイルを探して選択する機能です。
２つのオプションに`-`が付いており、それらの機能をオフにしています。

- [Multiviews](https://httpd.apache.org/docs/2.4/mod/mod_negotiation.html#multiviews)は、受け取ったURIのファイルがないときファイル拡張子を賢く探してくれるもの。
例えばURIに`/path/dir/foo`ときて`foo`が無かったら、`foo.*`となるファイルを探します。
- [Indexes](https://httpd.apache.org/docs/2.4/mod/core.html#options)はURLがディレクトリにマップするリクエストであって、 且つ`DirectoryIndex`で指定したファイルが ディレクトリ内に無ければ、ディレクトリ内の一覧を整形して返します。

`public/bar/index.html`みたいなHTMLやphpファイルがあるときに`/bar/`で返したいときは、`DirectoryIndex index.html index.php`の設定で可能です。
移行中や静的なページがある案件だとたまに設定します。

## RewriteCondとRewriteRule
細かく見ていく前に`RewriteCond`と`RewriteRule`について説明します。

`RewriteCond`はif文の条件みたいなもので、`RewriteCond <条件> [flags]`といった書き方です。
条件は正規表現で表します。
`RewriteCond`を続けて書くと`AND`になり、オプションに`[OR]`が付くと`OR`です。

`RewriteRule`は文字列を置換します。
書き方は`RewriteRule <検索文字列> <置換文字列> [flags]`です。

また、どちらも予約語があり`%{REQUEST_URI}`, `%{HTTP_USER_AGENT}`といったように使うことができます。

[mod_rewrite - Apache HTTP Server Version 2.4](https://www.google.com/search?q=RewriteRule&oq=RewriteRule&aqs=chrome..69i57j0l5j69i61l2.973j0j4&sourceid=chrome&ie=UTF-8)

### Handle Authorization Header
```conf
# Handle Authorization Header
RewriteCond %{HTTP:Authorization} .
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
```
HTTPヘッダーのAuthorizationを環境変数に代入しています。
`[E=foo:value]`とすると環境変数`foo`に値`value`を入れます。

[E|env](https://httpd.apache.org/docs/2.4/rewrite/flags.html#flag_e)の例をみると、画像ファイルのリクエストかどうかログに残したい場合にこのように書きます。
```conf
RewriteRule "\.(png|gif|jpg)$" "-" [E=image:1]
CustomLog "logs/access_log" combined env=!image
```

ただ、環境変数`HTTP_AUTHORIZATION`にいれるとアプリケーション側で利用できるのでしょうか？
末尾に乗せるNginxの書き方では書いていないようですので謎。
分かり次第追記します。

### Redirect Trailing Slashes If Not A Folder...
```conf
# Redirect Trailing Slashes If Not A Folder...
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} (.+)/$
RewriteRule ^ %1 [L,R=301]
```
LaravelのDocumentootは`public`に向けます。
ここでは、(1行目)URIが`public`配下に実在するディレクトリを指しておらず、(2行目)URIの末尾にスラッシュがついていたら、(3行目)末尾のスラッシュを取ったURIへリダイレクトします。
オプション`-d`はディレクトリかどうかで`!`で反対を意味するためディレクトリじゃない場合となります。
`RewriteRule`の`%1`は、２行目の`RewriteCond`のかっこの中の文字列を指しています。

`[L,R=301]`は`L`がLastを表しこれ以降のRiwrite処理を行わない、`R`がRidirectでHTTPステータス301でリダイレクトするという意味になります。

まとめると、URIが`/foo/bar/`で`public/foo/bar/`ディレクトリがない場合は`/foo/bar`にリダイレクトします。

### Send Requests To Front Controller...
```conf
# Send Requests To Front Controller...
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^ index.php [L]
```
ここも先ほどと似ています。
`!-d`は`public`配下にURIのディレクトリがない、かつ、`!-f`ファイルもない場合です。
その場合、`public/index.php`を実行します。

## おまけ：Nginxではどう書くのか？

Nginxでは`.htaccess`のようにディレクトリごとに設定ファイルがあることを認めていません。
そのため`.htaccess`は無く、Laravelのプロジェクトでは[Deployment #nginx | laravel.com](https://laravel.com/docs/7.x/deployment#nginx)にあるように設定をする必要があります。

```conf
## .htaccessのリダイレクト設定に似た箇所を抜粋
index index.html index.htm index.php;

location / {
    try_files $uri $uri/ /index.php?$query_string;
}
```

Nginxの方が後に出ただけあってスッキリ書ける印象。

## おわりに
まだ理解できていないこともありますが、結構Apacheの仕様を読み込めてきました。
Apacheについてはこんなのも書いているので良ければどうぞ。

- [以前のURLからもアクセスできるようにRewriteRuleを設定する](https://www.suzu6.net/posts/237-apache-redirect-uri)
- [htaccessを使わない方が良いとApacheとNginxの公式が言っている](https://www.suzu6.net/posts/240-htaccess-apache-vs-nginx)

## 参考

- [RewriteCondのANDとORの優先順位 - Qiita](https://qiita.com/kawaz/items/d3a7adc1445113141f3b)
  - `OR`の方が`AND`より強い。条件を`(A or B) and (C or D)`としたいときに参考になる。


Laravelの.htaccessの設定を読み解く


[Laravelの.htaccessの設定](https://www.suzu6.net/posts/239-laravel-htaccess)を調べている中、`.htaccess`ってNginxでも使えるのかなと調べました。
表題の通りApacheもNginxも`.htaccess`は使わない方が良いとの結論を出していました。
両方の公式から理由をまとめてみます。

## Apacheでは.htaccessを極力使わない方が良い

> 一般的に、サーバの主設定ファイルにアクセスできない場合を除いて、 .htaccess ファイルの使用は極力避けてください。 
> 
> [Apache チュートリアル: .htaccess ファイル | httpd.apache.org](https://httpd.apache.org/docs/2.4/ja/howto/htaccess.html)

その理由として性能とセキュリティの理由を挙げています。
### 性能面 
`.htaccess`の利用を許可すると、Apacheは各ディレクトリで`.htaccess`ファイルを探します。
これは`.htaccess`が無いディレクトリでも同様に探しますし、文書がリクエストされる度に読み込みます。

そのため、Apacheの主設定に記載することでパフォーマンスをあげることができます。
`httpd.conf`やそこからインクルードしたファイルの設定がApacheの主設定です。
これはApacheの起動かリロード時にまとめてキャッシュするため、`.htaccess`を使うより性能が良い。

### セキュリティ面
ユーザにサーバの設定を変更することを 許可することになりますので、あなた自身が管理できない変更をされる恐れがあります。
**「コンテンツ提供者がディレクトリ毎の設定を行ないたいけれど、サーバシステムのrootアクセス権限を持っていない」場合にのみ使うべきものです。**

`.htaccess`ファイル の使用を完全に無効にするためには`AllowOverride None`と設定します。

## Nginx で.htaccessはどういう扱いか？

公式から`.htaccess`についての見解が出ています。
[Like Apache: .htaccess | nginx.com](https://www.nginx.com/resources/wiki/start/topics/examples/likeapache-htaccess/)

簡潔にまとめると「パフォーマンスに悪影響だからディレクトリ見るたびに.htaccessがあるか確認するなんてうちではやらないよ」ってことらしいです。

## おわりに
性能とセキュリティが必要な本番環境は`.htaccess`を使わないようにしていきたい。
お客さんへの確認用のVirtualHostがたくさん載ったサーバの管理のみに限定する。


htaccessを使わない方が良いとApacheとNginxの公式が言っている


サイトのリニューアルに伴ってURIが幾つか変わったためApacheの設定で対応することになった。
ブックマークされていることも考慮して対応したURIにリダイレクトするようにします。

変更点は２つ
1. スマホ向けのページをレスポンシブにしたため、ULIの`/s/`を削除する
2. .htmlまたは.phpといった拡張子を見せないようにする

これらの設定を載せます。

### 環境
- httpd 2.4

## ULIの/s/を削除する

移行前ではスマホからのアクセスは`User-Agent`で判定してスマホ用のページを表示していました。
URLは
- PC: `www.example.com/mypage`
- スマホ: `www.example.com/s/mypage`
のように`/s/`を挟む仕様でした。

今回レスポンシブに対応したためどちらもPCのURLに統一します。
移行前にブクマした方向けに`/s/mypage`を`/mypage`と変換します。

```conf
RewriteEngine On
# URIの先頭が/s/の場合
RewriteCond %{REQUEST_URI} ^/s/.*$
RewriteRule ^(.*)/s/(.*)$ $1/$2 [L]
```
`RewriteEngine On`はRewrite機能自体のオン・オフを制御します。

`RewriteCond`はその条件に当たるURLの場合に続く`RewriteRule`を適用します。
`%{REQUEST_URI} ^/s/.*$はURIが`/s/`で始まる場合が条件。
URIはURLのドメイン以降の部分の文字列です。

`RewriteRule`はURL変換のルール。
`^(.*)/[sm]/(.*)$ $1/$2`で`https://www.example.com/s/mypage`が`https://www.example.com/mypage`になります。

末尾の`[L]`はこれ以降の変換処理を無視するという意味です。

## 拡張子を見せないようにする
移行前は`/login.php`と拡張子が見える状態でした。
これを`/login/`としつつ`/login.php`からもアクセスできるようにします。

### DirectoryIndex
拡張子を見せないようにするには`DirectoryIndex`を設定します。
これは、リクエストURIがファイル名を指定せずにディレクトリだけ指定された場合に`DirectoryIndex`で指定したファイルの内容をかえします。

```sh
DirectoryIndex index.php index.html index.htm
```

このように設定するとディレクトリ内の`index.php`が返ります。
`/login/`と来た場合は`/login/index.php`が返る。

`index.php`がない場合は`index.html`、`index.htm`と順番に探し、ない場合は404を返します。
他の拡張子のファイルも慣例的に`index`と命名します。

### 拡張子付きのURLを処理する

`/login.php`と来た場合にはそのPHPファイルを用意していないため404となります。
そこで`/login.php`を``/login`にするよう変換します。

```conf
RewriteEngine On
RewriteCond %{THE_REQUEST} ^.*\.(html|php)
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)/(.*)\.(html|php)(.*)$ $1/$2$4 [L]
```

`RewriteCond`を続けると**AND**の条件になる。
この例では「拡張子があり（2行目）該当するファイルとディレクトリがない（3,4行目）場合」となります。
`-f`でファイルが、`-d`でディレクトリが存在するかであり`!`がその逆です。

`RewriteRule`で拡張子を除去したURLに変換します。

`/user.php?id=1`が`/user?id=1`となるようクエリパラメータも考慮してあります。

## まとめると

以上の処理をまとめるとこんな感じ求める動きになった。
```conf
RewriteEngine On
RewriteCond %{REQUEST_URI} ^/[sm]/.*$
RewriteRule ^(.*)/[sm]/(.*)$ $1/$2 [R=301,L]
RewriteCond %{THE_REQUEST} ^.*/.*\.(html|php)
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)/(.*)\.(html|php)(.*)$ $1/$2$4 [L]

DirectoryIndex index.php index.html
```
スマホページも拡張子の処理が必要でしたので、一度整形したURLにリダイレクトしてから拡張子を処理するようにしています。
`R=301`がステータス301でリダイレクトする設定。

## mod_rewriteの参考となる記事

公式
- [Apache Module mod_rewrite | httpd.apache.org](https://httpd.apache.org/docs/2.4/mod/mod_rewrite.html)
  - 英語だけと公式は目を通そう
  - REQUEST_URI など特別な変数やRewriteCondのパターンはこちらに説明があります。

日本語の記事
- [mod_rewrite サンプル集/楽](https://snipsnaptmae.wordpress.com/2013/02/28/modrewrite/)
  - こちらは`RewriteRule`と`RewriteCond`の関係が分かり易い
- [RewriteRuleのフラグと、RewriteCondの変数一覧](https://qiita.com/tsukaguitar/items/e37245260f0b1407341d)
  - 末尾にある`[L]`などの記号のまとめ


あとは正規表現を自在に使えるようになりたい。

## 関連する書いたもの
- [URLのフラグメント識別子(#以後の文字列)によってページを振り分ける方法](https://www.suzu6.net/posts/200-redirect-fragment-identifier/)
URLのアンカーリンクはサーバ側（Apache）まで届かない。
それをどうにか振り分けた話。

以前のURLからもアクセスできるようにRewriteRuleを設定する


[アップロードファイルに関するphp.iniの設定](https://www.suzu6.net/posts/201-php-filesize/)をしてApacheを再起動したが設定が反映されていなかった。
PHP-FPMを再起動したことで反映できました。

## 環境

- PHP 7.3.8
  - php.x86_64 7.3.8-1.el7.remi @remi-php73
- CentOS 7.6
- Apache/2.4.6

設定ファイルはデフォルトで`/etc/php.ini`にあります。

## なぜApacheの再起動でphp.iniが反映されなかったか

Apacheでphpを実行するには**モジュール版**と**CGI版**(含む)のどちらかを使っています。
今回は**CGI版**であるPHP-FPMを利用していました。

ApacheはPHP-FPMを通してphpを実行しています。
PHP-FPMがphp.iniの設定を読み込んでいなかったため、Apacheを再起動しても設定を読み込めなかったのです。
一方、**モジュール版**では、Apacheが直接phpを実行しているためApacheの再起動だけで良いようです。

また、Nginxでは基本PHP-FPMを利用するため、同じくPHP-FPMの再起動をすると良いはずです。

## PHP-FPMを再起動する

PHP-FPMを再起動してphp.iniの設定変更を反映させます。

```sh
# CentOS 7系
# ステータス確認
$ sudo systemctl stutas PHP-FPM 

# 再起動
$ sudo systemctl restart PHP-FPM 
```

**Apacheの再起動は不要**です。PHP-FPMを再起動だけで設定を読み込めます。

## CGI、FastCGI、PHP-FPMとは？

[nginx と PHP-FPM の仕組みをちゃんと理解しながら PHP の実行環境を構築する - Qiita](https://qiita.com/kotarella1110/items/634f6fafeb33ae0f51dc)

私が説明するよりこれを読んだ方が良い。
記事の最後にもリンクを貼ります。

## PHP-FPMを利用しているかの確認

### phpinfo

phpinfoでは`Server API`の項に`FPM/FastCGI`とあればPHP-FPMを介してPHPを実行している。

![phpinfo](/images/posts/200/202/phpinfo.png)

`Loaded Configuration File`の項に`php.ini`のパスもあります。


### Apache conf

Apache2.4.7以降のconfの場合は`ProxyPassMatch`にPHP-FPMの記述がある。

```conf
# PHP-FPM
ProxyPassMatch ^/(.*\.php(/.*)?)$ fcgi://127.0.0.1:9000/document/root/path/$1
```

調べて初めて知ったが、この書き方に幾つか問題があるらしい(参考)。
そこで、Apache 2.10から`SetHandler`で書けるようになった。
```conf
DirectoryIndex index.php index.html

<FilesMatch \.php$>
    SetHandler "proxy:fcgi://127.0.0.1:9000"
</FilesMatch>
```

## 参考

- [nginx と PHP-FPM の仕組みをちゃんと理解しながら PHP の実行環境を構築する - Qiita](https://qiita.com/kotarella1110/items/634f6fafeb33ae0f51dc)
  - モジュール版とCGI版の違いは？やFastCGIとは？といった疑問をかなり詳しく解説してくれる！
  - せっかくなので、次はこれを読むことをオススメします！
- [ApacheでPHP-FPMを動かすなら、ProxyPassMatchではなくSetHandlerを使うのがいいらしい - Qiita](https://qiita.com/shimoju/items/8e9c2a7bddd64e878799)
- [Ubuntu 14.04 の Apache mod_proxy_fcgi で php 動かすのは厳しい話 - 誰かの役に立てばいいブログ](https://ymmt.hatenablog.com/entry/2014/10/24/154427)
  - Apache 2.10から`SetHandler`で書ける。

Apacheの再起動でphp.iniの設定が反映されなかった時


Apacheの設定確認できるコマンドを教えてもらったので紹介します。

`httpd -t -D DUMP_VHOSTS`でバーチャルホストの一覧を確認できる。

## httpd -t -D DUMP_VHOSTS

```sh
$ sudo /opt/local/apache2/bin/httpd  -t -D DUMP_VHOSTS
VirtualHost configuration:
wildcard NameVirtualHosts and _default_ servers:
*:8080                 example.jp (/opt/local/httpd-2.2.23/conf/extra/httpd-vhosts.conf:64)
*:443                  is a NameVirtualHost
         default server test1.example.jp (/srv/example.jp/httpsd/conf/httpd-ssl.example.jp.conf:5)
         port 443 namevhost test1.example.jp (/srv/example.jp/httpsd/conf/httpd-ssl.example.jp.conf:5)
         port 443 namevhost test2.example.jp (/srv/example.jp/httpsd/conf/httpd-ssl.example.jp.conf:36)
         port 443 namevhost test3.example.jp (/srv/example.jp/httpsd/conf/httpd-ssl.example.jp.conf:67)
         port 443 namevhost test4.example.jp (/srv/example.jp/httpsd/conf/httpd-ssl.example.jp.conf:95)
         port 443 namevhost example.jp (/srv/example.jp/httpsd/conf/httpd-ssl.example.jp.conf:562)
*:80                   is a NameVirtualHost
         default server default.only (/opt/local/httpd-2.2.23/conf/extra/httpd-vhosts.conf:27)
         port 80 namevhost default.only (/opt/local/httpd-2.2.23/conf/extra/httpd-vhosts.conf:27)
         port 80 namevhost example.jp (/srv/example.jp/httpd/conf/httpd-example.jp.conf:1)
         port 80 namevhost desknets.example.jp (/srv/desknets/httpd/conf/httpd-desknets.conf:1)
         port 80 namevhost efactory.example.jp (/srv/efactory.example.jp/conf/efactory.example.jp.conf:1)
Syntax OK
```

こんな形でバーチャルホスト名と設定ファイルの一覧を表示してくれる。
構造がわからないサーバに入ったら、真っ先に打ちたいコマンドです。

### 関連記事

- [configtestとgracefulでApacheの安全に再起動して設定を反映させる](https://www.suzu6.net/posts/181-safety-reflect-apache-configuration)

ApacheでVirtualHostの一覧確認


本番稼働中のサーバのApacheの設定を変更したり、新しくホストを追加する作業には神経を使う。
サイトを止めないよう、できるだけ安全にApacheの設定を変更するコマンドと手順を紹介する。

※間違いがあるかもしれません。コマンドを実行される前に[Apacheのドキュメント](https://httpd.apache.org/docs/2.4/ja/)をご確認ください。

### 環境

- CentOS 7.4
- Apache 2.4

コマンドは基本`apachectl`を使っていきます。

`systemctl`、`httpd`、`/etc/rc.d/init.d/httpd2`とたくさんあるので対応したコマンドも載せておく。

## restartは使わないで

環境構築のときは`restart`をよく使うかもしれませんが、
Apacheが止まってはまずい状況では使わないで下さい。

`restart`はApacheを停止してから起動します。
設定を間違えていた場合、修正する時間サイトが停止してしまいます。
また、誰かがサイトにアクセス中だと子プロセスが走っていますが、`restart`は子プロセスをkillします。

1. `configtest`でconfの構文チェック
2. `graceful`で緩やかに再起動させる

以上の手順を踏まれた方が安全に設定を反映できます。

## 設定ファイルの変更後の確認 configtest

`apachectl configtest`もしくは`apachectl -t`

confファイルを書き換えた後は記述が正しいか`configtest`で確認できます。
構文が間違っているとエラー箇所を教えてくれますし、正しくてもディレクトリがない場合もWarningで教えてくれます。

```sh
$ sudo apachectl configtest
Syntax OK
```

問題なければ`Syntax OK`となる。

```sh
# 権限がない場合の例
$ apachectl -t
Syntax error on line 31 of /etc/httpd/conf.d/ssl.conf:
SSLPassPhraseDialog: file '/root/bin/echo_passphrase' does not exist
```

権限も検知してくれる。

```sh
# DocumentRootのディレクトリがない場合の例
$ sudo apachectl configtest
AH00112: Warning: DocumentRoot [/var/www/app/public] does not exist
Syntax OK
```

構文エラーがなくとも、Warningを示してくれる。
エラーもWarningも全て修正しておきたい。

```sh
$ httpd -t
$ httpd configtest
$ /etc/init.d/httpd configtest
```

また、バーチャルホストの設定をしていた場合、`httpd -t -D DUMP_VHOSTS`でバーチャルホストの一覧を確認できる。

関連記事：[ApacheでVirtualHostの一覧確認](https://www.suzu6.net/posts/192-apache-dump-vhosts)

## Apacheを止めずに設定反映  graceful

`apachectl -k graceful`

`graceful`は**緩やかな再起動**です。
子プロセスは現在の処理を完了してから終了します。
親プロセスは設定を反映しておき、新しい子プロセスから新しい設定で動かす。

また、再起動前に構文チェックが走りエラーがある場合再起動されない。
（※これでも正しく再起動することは保証されていないため、事前にチェックは必要）

```sh
$ sudo apachectl -k graceful
```

正しく再起動できた場合特に表示はない。

```sh
$ httpd -t
$ httpd configtest
$ /etc/init.d/httpd configtest
```

`systemctl`では`systemctl reload httpd`がほぼ同じコマンド。

### httpdがもし立ち上がらなかったら

```sh
$ sudo cat /var/log/httpd/error_log
```

`/var/log/httpd/error_log`にエラーログがある。
読んでググれば大体検討は付くはず。

### 参考

- [Apache HTTP サーバ バージョン 2.4 ドキュメント](https://httpd.apache.org/docs/2.4/ja/)

何かあったらこれをまず見る。

- [Apache 便利コマンド集 - Qiita](https://qiita.com/bezeklik/items/990bed2e7e529584fa57)

ログの操作も載っている。

- [httpd -tとconfigtestの違い | OpenGroove](https://open-groove.net/apache/httpd-t-configtest/)

`http -t`と`apachectl configtest`は環境変数を読み込むか読み込まないかの違いがあるらしい。

- [Apacheでreloadとgracefulを試した動きのメモ](http://www.lesstep.jp/step_on_board/apache/610/)

`graceful`が「プロセスが終わるのを待ってから新しい設定を反映させる」か検証された記事。
`reload`は子プロセスの終了を待つが、`graceful`は子プロセスを強制終了させるらしい。(ドキュメントと異なる？)

- [Apacheのrestartやgraceful、stopなどの違い | インフラ | DoRuby](https://doruby.jp/users/yokian/entries/Apache_restart_graceful_stop_)

`graceful`、`restart`の挙動の違いがわかりやすい。