Apacheの初期設定とWebコンテンツのルートディレクトリを変更する理由と、たとえサイトが一つでもVirtualHostを設定する必要性についてのメモです。

大前提「これはローカル環境での手順」です。

なぜなら、これはインターネット上サーバでの絶対的なルールが抜けています。

  1. https通信の対応
  2. ログ設定の未考慮

この2つは別の項でも解説しますが、これらを考慮しないと

  • 「管理が甘いサーバ」として攻撃者の格好の的になる
  • 「トラブル発生時の証跡をつかめない」

の2点が重くのしかかります。

理由1.なぜホームディレクトリ（DocumentRoot）を変更するのか？

標準でapacheを入れると、Webサーバーのコンテンツディレクトリとして使われるのは /var/www です。

しかし、本稿では/home/www-data へとホームディレクトリを変更します。これには、以下の明白な理由があります。

理由詳細
セキュリティ上の分離 (Preference)/var ディレクトリは、ログ（/var/log）や一時ファイル（/var/tmp）など、システムが頻繁に書き換える揮発性のデータを格納するために設計されています。Webコンテンツを /home に置くことで、システムデータとユーザーデータ（コンテンツ）を明確に分離し、万が一のシステム障害や冗長化の際に管理が容易になります。
ユーザープロファイルの整合性 (Practicality)www-data ユーザーは通常シェルログインできませんが、Ruby on RailsやNode.jsなどのモダンなアプリケーションが bundle install やパッケージのインストールを行う際や、gitを利用する際に環境変数として自身のホームディレクトリを参照することがあります。これを /home/www-data に設定することで、アプリケーションがスムーズに動作し、予期せぬエラーを防ぐことができます。

理由2. なぜ単一サイトでもVirtualHost（バーチャルサイト）を仕込むのか？

VPS/ローカルサーバでで公開するサイトが一つだけであっても、デフォルトの設定ファイル (000-default.conf など) ではなく、個別のVirtualHost設定ファイルを作成して運用すべきです。

理由詳細
セキュリティ（デフォルト設定の無効化）デフォルト設定 (000-default.conf) は通常、/var/www/html を DocumentRoot としています。これを無効化し、カスタムVirtualHostのみを有効にすることで、意図しないディレクトリが公開されるリスクや、デフォルト設定のバージョン情報などが露出するリスクを防ぎます。
スケーラビリティと将来性将来、サブドメイン（例: blog.example.com）や別のドメインを追加する際に、既存の設定をコピーして修正するだけで済みます。最初からVirtualHostの構造を採用することで、設定の拡張が容易になり、メンテナンス性が向上します。
HTTPS（SSL）対応の必須要件HTTP（ポート80）からHTTPS（ポート443）への強制リダイレクトや、独自のSSL証明書の設定は、VirtualHostブロック (<VirtualHost *:443>) ごとに行うのが一般的です。VirtualHostが基本となることで、この必須のセキュリティ対策をスムーズに組み込めます。

さっくりとした手順

  1. ホームディレクトリの作成と設定
  2. /etc/passwdの書き換え（要注意）
  3. VirutalHostの設定
  4. 設定の有効化と確認

1. 新たなホームディレクトリの作成と設定

VPSのコンテンツ保存場所を /home/www-data に統一します。

  • ディレクトリ作成
sudo mkdir -p /home/www-data
  • ディレクトリの所有者変更
sudo chown -R www-data:www-data /home/www-data
  • 設定確認
ls -ld /home/www-data

　→ 所有者がwww-dataになっていることを確認

2. /etc/passwd ファイルの書き換え

www-data ユーザーのホームディレクトリの定義を /var/www から変更します。

** 注意:** /etc/passwd はシステムアカウントを制御する重要ファイルです。必ずバックアップを取り、変更は一行のみであることを確認してください。

  • バックアップ作成
sudo cp -pi /etc/passwd /path/to/backup/directory/passwd.$(date +%Y%m%d)

→ 任意のバックアップディレクトリを指定します。また、$(date +%Y%m%d)を仕込むことで、「いつ」このバックアップを取ったかが明白になります。

  • バックアップ作成確認
sudo diff -u /path/to/backup/directory/passwd.$(date +%Y%m%d) /etc/passwd

→ 面倒でもこの作業は必須です。というのも、差分を取ることで「オリジナルとバックアップの両方が作成されている」というのを、コマンドという第三者の絶対的な目で見ることができるからです。

→ また、先ほどのcpと逆になっていることにも注意してください。これは、変更後に「どの行が惹かれ、どの行が足されたか」を明確化するためです。

  • sedによるファイル書き換え
sudo sed -i 's|/var/www|/home/www-data|' /etc/passwd

→ 特に注意が必要です。これをミスるとサーバ全体のロックアウトなども容易に発生します。

  • 書き換え確認
diff -u /path/to/backup/directory/passwd.$(date +%Y%m%d) /etc/passwd

差分が以下のみであることを確認します。

-www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
+www-data:x:33:33:www-data:/home/www-data:/usr/sbin/nologin

→ ここで、「なぜ、逆にして差分を取るのか」を明確化。

diff -u /etc/passwd　/path/to/backup/directory/passwd.$(date +%Y%m%d)

とした場合、得られる情報は「まるで逆」になります。

+www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
-www-data:x:33:33:www-data:/home/www-data:/usr/sbin/nologin

となり、「バックアップの方が正しい修正」となってしまうからです。

3. VirtualHost 設定の準備(Redmineを例にする)

Redmine（動的アプリケーションの例）を /home/www-data 内のディレクトリで公開するためのベース設定を作成します。

cat <<- __EOF__ | sudo tee -a /etc/apache2/sites-available/redmine.conf
<VirtualHost *:80>
    ServerName 【hoge.example.com】
    # ServerNameは自身が設定したドメイン名に置き換えてください。

    DocumentRoot /home/www-data/redmine/public

    <Directory /home/www-data/redmine/public>
        # .htaccessによる設定変更を許可
        AllowOverride All
        # 複数Viewを無効化（アプリケーションのルーティングを優先させるため）
        Options -MultiViews
        # 全てのアクセスを許可
        Require all granted
    </Directory>
</VirtualHost>
__EOF__

4. 設定の有効化と確認

作成したVirtualHostを有効化し、デフォルトサイトを無効化します。

  • 既存のデフォルトサイトを無効化
sudo a2dissite 000-default.conf
  • 新しいサイト設定を有効化
sudo a2ensite redmine.conf
  • 構文チェック
sudo apache2ctl configtest

→　Syntax OKとなることを必ず確認してください。でないと、apacheサービスが停止したままとなってしまい、サービス断が発生します。

  • Apache サービス再起動
sudo systemctl restart apache2.service
  • Apacheサービス再起動確認
systemctl status apache2.service

active(running)を確認します。

これで、Apacheの基盤がセキュリティと運用効率を考慮したカスタム設定で動作するようになりました。