2024年5月15日水曜日

Apache MPM Eventsの値

参照先:
https://qiita.com/rryu/items/5e02ea60e36d7fd956b8

以下、httpd.confに追記する。

<IfModule mpm_event_module>
StartServers 8
MinSpareThreads 50
MaxSpareThreads 175
ThreadLimit 64
ThreadsPerChild 25
MaxRequestWorkers 150
MaxConnectionsPerChild 10
</IfModule>


apacheの再起動して、プロセスの確認をしてみる










2024年5月13日月曜日

Apacheの特権分離について

 Apache HTTPサーバーが通常、rootユーザーで起動し、その後特権を降格してからリクエストを処理するメカニズムは、セキュリティと安全性を確保するための重要な設計です。これを理解するために、以下のポイントを詳しく解説します。

  1. 起動時の特権 Apache HTTPサーバーは通常、起動時にはrootユーザーとして実行されます。これにより、Apacheは必要なファイルやポートにアクセスするために必要な特権を持つことができます。

  2. 特権の降格(特権分離) Apacheが必要な初期設定やファイルへのアクセスを完了した後、特権を降格します。特権の降格はセキュリティ上の理由から行われます。root権限を持つプロセスは攻撃者によって悪用される可能性が高いため、リクエストを処理する段階では特権を持たない一般ユーザーとして動作することが推奨されます。

  3. セキュリティ向上 特権の降格により、Apacheは攻撃者が攻撃に使用できる潜在的な脆弱性を利用されにくくなります。例えば、特権を持つプロセスがリクエストを処理する場合、攻撃者はそのプロセスを標的にしようとします。しかし、特権を持たない一般ユーザーとして動作するApacheは、攻撃者にとっては難しいターゲットとなります。

  4. セキュリティ対策の重要性 特権の降格はセキュリティ対策の重要な要素の1つですが、それだけでなく他のセキュリティ対策も必要です。例えば、適切なファイルアクセス権限の設定、セキュリティパッチの適用、DoS攻撃への対策などがあります。

総じて、Apache HTTPサーバーがroot権限で起動してから特権を降格するメカニズムは、システム全体のセキュリティを向上させる重要な手段です。これにより、潜在的な攻撃からシステムを保護し、安全性を確保することが可能となります。

MPM prefork(Apache):チーニング編


 1)/etc/httpd/conf.d/mpm.confを作成する

<IfModule mpm_prefork_module>
StartServers 400
MinSpareServers 400
MaxSpareServers 400
ServerLimit 400
MaxClients 400
MaxRequestsPerChild 80
</IfModule>

2)00-mpm.confの編集を行う。

# Select the MPM module which should be used by uncommenting exactly
# one of the following LoadModule lines. See the httpd.conf(5) man
# page for more information on changing the MPM.

# prefork MPM: Implements a non-threaded, pre-forking web server
# See: http://httpd.apache.org/docs/2.4/mod/prefork.html
#
# NOTE: If enabling prefork, the httpd_graceful_shutdown SELinux
# boolean should be enabled, to allow graceful stop/shutdown.
#

## mpm_prefork ##
LoadModule mpm_prefork_module modules/mod_mpm_prefork.so

# worker MPM: Multi-Processing Module implementing a hybrid
# multi-threaded multi-process web server
# See: http://httpd.apache.org/docs/2.4/mod/worker.html
#
#LoadModule mpm_worker_module modules/mod_mpm_worker.so

# event MPM: A variant of the worker MPM with the goal of consuming
# threads only for connections with active processing
# See: http://httpd.apache.org/docs/2.4/mod/event.html
#

## Default setting ##
#LoadModule mpm_event_module modules/mod_mpm_event.so


3)httpd.confに追記

KeepAlive On
MaxKeepAliveRequests 80
KeepAliveTimeout 120

4)apache のサービスを再起動






php module installについて

 参照先:

https://dennie.tokyo/it/?p=2511


RUN yum --disableplugin=subscription-manager -y install mod_php

2024年5月10日金曜日

FPMのログを設定(コンテナ用のログ出力)

FPMのログを設定

RUN ln -sf /dev/stderr /var/log/php-fpm/error.log
RUN ln -sf /dev/stderr /var/log/php-fpm/fpm-access.log

2024年5月8日水曜日

apache .htaccessのデバッグについて

dockerfileにapacheを入れているので、以下の記載により詳細なデバッグログが表示される 

RUN sed -i 's/LogLevel warn/LogLevel info rewrite:trace8/g' /etc/apache2/apache2.conf

2024年4月24日水曜日

EFS(Dockerfile)の記載について注意

 


Dockerfileにefsのマウントパス宛に、ファイルコピーを行うと
ECSのサービス作成時に、コンテナのデプロイ失敗に(container run time error)になるので
別経由で、EFSにファイルをコピーした方が良い!!

<Dockerfile>

COPY test.html /efs <-----EFSのマウントパス 
COPY .htaccess /efs <-----EFSのマウントパス

EFSのマウントについて

EFSのマウント方法について
意外とハマったので、記載 (忘れがち)



2024年4月21日日曜日

PHP log設定(debug編)

 以下を追記

  ->logLevel は用途に応じて

httpd.conf

———

ErrorLog "logs/php/error.log"

LogLevel debug

————


php.ini

以下に編集する。

———————————

# エラーログを有効にする

log_errors = On


# エラー表示を有効にする(開発環境用)

display_errors = On


# エラーレポートのレベルを指定する(開発環境用)

error_reporting = E_ALL


# デバッグレベルのログを出力する

# 以下のように設定することで全てのログが出力される

log_errors_max_len = 0

————————————



apacheの再起動を行う



以下に出力される(ディレクトリの作成が必要)

mkdir -p /etc/httpd/logs/php/

2024年4月13日土曜日

EFSのインストールおよびマウント方法について

環境:
AmazonLinux2

ユーティリティが必要なのでインストール;
yum install amazon-efs-utils


マウント用にディレクトリ作成:

mkdir -p /efs



マウント実施:

(注意:ルート配下にて実施すること!)

①ヘルパーのマウント

sudo mount -t efs -o tls fs-006d44246be2a962f:/ /efs

 ->実施、場所を間違えると、実行できないので、注意


②マウント

sudo mount -t nfs4 -o nfsvers=4.1,rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,noresvport fs-xxxxxxxxxxxxxxx.efs.ap-northeast-1.amazonaws.com:/ efs





Lambda + SSM Run Commandで、数十台のEC2のuserdata結果を一括確認する

コードを1枚貼って、テストイベントを実行するだけで、 全台の確認結果が返ってくる手順です。 [ゴール] Nameタグが web-* / api-* / batch-* のEC2すべてに確認コマンドを流し、 NGの台だけ を結果に表示します。確認対象のuserdata(Ubu...