apache – Page 3 – ソフトウェアエンジニアの技術ブログ：Software engineer tech blog

service httpd restart

check the status of Apache
[vagrant@localhost ~]$ /etc/init.d/httpd status
httpd status unknown due to insufficient privileges.

restart apache
[vagrant@localhost ~]$ sudo service httpd restart
httpd を停止中: [ OK ]
httpd を起動中: httpd: Could not reliably determine the server’s fully qualified domain name, using localhost.localdomain for ServerName
[ OK ]

.htaccess

Web server configuration file for each directory that can be used in an environment where software such as Apache is used.
When this is installed in a specific directory, the contents described in “.htaccess” are applied to the directory in the installed directory and directory under it.

How to make .htaccess file
1. create and save a file named “.htaccess” with text editor.
2. describe what you want to control and configure with apache and save.
3. uploaded to the server and renamed to “.htaccess”

1. Basic authentication
It is a mechanism for forcing ID and password input with authentication in the directory etc.
If you want to play the site before publishing with users and Google bot.
If you want to publish it only to those who know the ipass.

AuthUserfile /fullpath/.htpasswd
AuthGroupfile /dev/null
AuthName "Please enter your ID and password"
AuthType Basic
require valid-user

2. 301 Redirect
It is the transfer method most used in SEO, which can inherit evaluation from old page to new page. It is called permanent relocation, and it is used for URL change and domain transfer.

RewriteEngine on
RewriteRule ^old.html$ http://sample.com/new.php [R=301,L]

3. URL normalization
It refers to unifying the URL to one. For example, in the following cases, Google recognizes each as a different URL, but generally the same page is displayed.

RewriteEngine on
RewirteCond %{THE_REQUEST} ^.*/index.html
RewirteRule ^(.*)index.html$ http://sample.com/$1 [R=301,L]

RewriteEngine on
RewirteCond %{HTTP_HOST} ^www\.example\.com$
RewriteRule ^(.*)$ http://sample.com/$1 [R=301,L]

RewriteEngine on
RewriteCond %{HTTP_HOST} ^example\.com$
RewriteRule ^(.*)$ http://www.sample.com/$1 [R=301,L]

4. Abort of file list display
It is used to eliminate the security concern that the directory structure is exposed to the outside.
When there is an access ending with “/” like http://www.example.com, “index.html” that directory will be called instead.
However, if the index.html file can not be found, the file list in the directory shown.
Publishing the directory in this way will expose the structure of the website and there is certain risk from the security point of view. Therefore, by canceling the file list display in the directory, it is possible to prevent publication of the directory structure.

Options -Indexes

5. Access restriction from specific IP address and domain
You can restrict / deny access from a specific IP address or domain.
Alternatively, you can only allow access from a specific IP address or domain.

order allow,deny
allow from all
deny from sample.com
deny from 192.168.1.1

order deny,allo
deny from all
allow from sample.com
allow from 192.168.1.1

<files test-file.html>
	order deny,allow
	deny from all
	allow from sample.com
	allow from 192.168.1.1
</files>

apacheのLogLevelディレクティブ

LogLevelディレクティブでは、エラーログに記録するエラーレベルを指定することができる。
以下のように、LogLevel warnでは、”warn”以上のエラーレベルはすべてエラーログに記録するようになり、逆にnotice以下のエラーレベルに関してはログに記載されなくなる。

#
# LogLevel: Control the number of messages logged to the error_log.
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
#
LogLevel warn

ふーん

apacheエラーログの場所とフォーマット

まず、apacheのエラーログの場所は、アクセスログと同様に、
/var/log/httpd/配下にあります

エラーログの中身を見てみましょう。
error_log-yyyymmdd

[Sun Dec 16 16:35:05 2018] [notice] Digest: generating secret for digest authentication ...
[Sun Dec 16 16:35:05 2018] [notice] Digest: done
[Sun Dec 16 16:35:06 2018] [notice] Apache/2.2.15 (Unix) DAV/2 configured -- resuming normal operations
[Mon Dec 17 22:12:31 2018] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Mon Dec 17 22:12:32 2018] [notice] Digest: generating secret for digest authentication ...
[Mon Dec 17 22:12:32 2018] [notice] Digest: done
[Mon Dec 17 22:12:42 2018] [notice] Apache/2.2.15 (Unix) DAV/2 configured -- resuming normal operations
[Tue Dec 18 22:53:56 2018] [warn] child process 6696 still did not exit, sending a SIGTERM
[Tue Dec 18 22:53:58 2018] [notice] caught SIGTERM, shutting down
[Thu Dec 20 00:32:58 2018] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Thu Dec 20 00:32:58 2018] [notice] Digest: generating secret for digest authentication ...
[Thu Dec 20 00:32:58 2018] [notice] Digest: done
[Thu Dec 20 00:33:03 2018] [notice] Apache/2.2.15 (Unix) DAV/2 configured -- resuming normal operations
[Sat Dec 22 21:33:15 2018] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
[Sat Dec 22 21:33:15 2018] [notice] Digest: generating secret for digest authentication ...
[Sat Dec 22 21:33:15 2018] [notice] Digest: done
[Sat Dec 22 21:33:31 2018] [notice] Apache/2.2.15 (Unix) DAV/2 configured -- resuming normal operations
[Sun Dec 23 09:19:04 2018] [notice] SIGHUP received.  Attempting to restart
httpd: Could not reliably determine the server's fully qualified domain name, using localhost.localdomain for ServerName

割と色々出てますが、内容は比較的複雑ではありません。
[Sun Dec 23 09:19:04 2018] ：エラー検知日付
[notice] : エラー重要度
SIGHUP received. Attempting to restart
httpd: Could not reliably determine the server’s fully qualified domain name, using localhost.localdomain for ServerName : エラー内容

エラーレベルの種類
emerg: 緊急
alert: ただちに対処が必要
crit: 致命的状態
error: 通常エラー
warn: 警告
notice: 通知
info: サーバーの状態についての情報
debug: デバッグメッセージ

にゃーるほど

apacheログの場所とフォーマット

httpdにアクセスがあった場合やエラーがあった場合、ログに保存される

場所は以下にあります。
var/log/httpd/access_log

アクセスしようとしたら、permission denied! 何？

とりあえず、アクセス権を変更します。
[vagrant@localhost ~]$ sudo chmod 777 /var/log/httpd/

var/log/httpd/に入れるようになりました。
access_logとerror_logがあります。

access_log-yyyymmddから見てみましょう。

192.168.35.1 - - [25/Nov/2018:20:48:18 +0900] "GET /login HTTP/1.1" 404 282 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36"
192.168.35.1 - - [25/Nov/2018:20:48:20 +0900] "GET /favicon.ico HTTP/1.1" 404 288 "http://192.168.35.10/login" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36"
192.168.35.1 - - [25/Nov/2018:20:48:59 +0900] "GET / HTTP/1.1" 200 142 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36"

ログフォーマット

%h %l %u %t \"%r/" %>s %b \"%{refferer}i"\" /"%{user-agent}i"

%h リモートホスト:192.168.35.1
%l リモートログ名、mod_identモジュールがロードされており、IdentityCheckディレクティブがOnになっている場合のみ表示。それ以外の場合は『-』と表示。:-
%u リモートユーザ:-
%t リクエストを受信した時刻:25/Nov/2018:20:48:18 +0900
%r リクエストの最初の行：GET /login HTTP/1.1
%>s %sはステータスコード。内部でリダイレクトされた場合でも元々のステータスコードを出力。%>sはリダイレクトされた場合最後のステータスコードを出力。：404
%b　HTTPヘッダを除くレスポンスのバイト数：282
%{referer}i サーバが受信したリクエストヘッダのReferer：-
${user-agent}i サーバが受信したリクエストヘッダのUser-Agent:Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36

/etc/httpd/conf/httpd.confの497行目に記載があります。

#
# The following directives define some format nicknames for use with
# a CustomLog directive (see below).
#
LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
LogFormat "%h %l %u %t \"%r\" %>s %b" common
LogFormat "%{Referer}i -> %U" referer
LogFormat "%{User-agent}i" agent

なるほどー　そういうこと

httpd start/restart と httpd gracefulの違い

httpd restart/gracefulはapacheのプロセス停止・再開を行うが、方法が異なる。

httpd restart
restartの場合は、以下のように、完全にhttpdプロセスを一旦停止してから再起動しています。

[vagrant@localhost ~]$ sudo service httpd restart
httpd を停止中: [ OK ]
httpd を起動中: [ OK ]

httpd graceful
httpdの通信が終わるのを待って、順次新しい設定を反映したhttpdを起動させる方法。
[vagrant@localhost ~]$ sudo service httpd graceful

サービスの停止ができない場合は「graceful」の使用をおすすめ。

apache公式ドキュメントを見てみましょう。
https://httpd.apache.org/docs/2.4/stopping.html
Apache HTTP Serverの再起動には、実行されている httpd プロセスにシグナルを送る必要がある。

公式ドキュメントのrestart
restart シグナルを親プロセスに送ると、 TERM と同様に子プロセスを kill しますが、親プロセスは終了しません。設定ファイルを再読込して、ログファイル全てを開き直します。その後、新しい子プロセスを起動して応答を続けます。

公式ドキュメントgraceful
graceful シグナルを受け取ると、子プロセスに現在のリクエストの処理の後に終了する (あるいは何もしていなければすぐに終了する) ように助言します。親プロセスは設定ファイルを再読込して、ログファイルを開き直します。子プロセスが徐々になくなるに従って、新しい世代の設定による子プロセスに置き換えていきます。そして、これらが新たなリクエストに即座に応答し始めます。

公式には、どんな時にどのコマンドを推奨などは書かれていませんが、サービス運用者およびコンピュータサイエンスとしての考え方は、急にkillするのではなく、緩やかに停止した方が良さそうに見えます。