Apache на Debian: поднимаем клиентский сайт на своём сервере

Клиент попросил разместить сайт у себя, а не у провайдера. Причин несколько: хочет полный контроль, не хочет платить за хостинг, и главное - у них уже стоит Linux-шлюз с нормальным NAT, так что выделенный IP уже есть. Задача: поднять Apache, настроить виртуальный хост, подключить PHP, разобраться с правами. Звучит несложно - оно и оказалось несложно, но с несколькими моментами, которые стоит делать правильно сразу.

Установка

Debian Potato, Apache 1.3. Всё ставится одной командой:

apt-get install apache php4 php4-mysql libapache-mod-php4

После установки Apache уже запущен и отвечает на 80-м порту. В браузере - стандартная страница «It Works!». На этом хорошие новости заканчиваются: конфиг по умолчанию небезопасен и требует правки прежде чем открывать его наружу.

Виртуальные хосты

Клиент хочет, чтобы сайт открывался по имени домена. Настраиваем в /etc/apache/httpd.conf. Сначала говорим Apache слушать по имени:

NameVirtualHost *:80

Потом описываем виртуальный хост:

<VirtualHost *:80>
    ServerName example.ru
    ServerAlias www.example.ru
    DocumentRoot /var/www/example.ru
    ErrorLog /var/log/apache/example.ru-error.log
    CustomLog /var/log/apache/example.ru-access.log combined
</VirtualHost>

Каталог /var/www/example.ru создаём руками, кладём туда index.php для теста. Перезапускаем: apache restart. Проверяем через curl с нужным заголовком Host - работает.

Права на файлы: сделать правильно один раз

Это то место, где обычно делают «лишь бы работало», а потом жалеют. Apache на Debian работает от пользователя www-data. Файлы сайта принадлежат тому, кто их заливает - скажем, отдельному пользователю webmaster.

Нормальная расстановка:

chown -R webmaster:www-data /var/www/example.ru
find /var/www/example.ru -type d -exec chmod 750 {} \;
find /var/www/example.ru -type f -exec chmod 640 {} \;

Директории - 750. Владелец читает и пишет, группа (www-data) читает и заходит внутрь. Остальные - ничего.

Файлы - 640. Владелец читает и пишет, www-data читает, остальные не видят ничего.

Если PHP нужно писать в какой-то каталог (кеш, загрузки), только тот каталог делаем с правом записи для группы:

chmod 770 /var/www/example.ru/cache

Никаких 777. Никогда. Это не паранойя - это просто минимальная аккуратность. Если на сервере будут ещё сайты других клиентов, 777 означает что PHP-скрипт одного сайта может читать файлы другого. Это уже не просто неряшливо.

PHP работает

PHP установился вместе с Apache как модуль. В конфиге проверяем что LoadModule для php4 есть и что .php обрабатывается:

AddType application/x-httpd-php .php

Кладём в корень сайта файл с <?php phpinfo(); ?>, открываем в браузере - видим полную информацию о конфигурации PHP. Тест прошёл, файл сразу удаляем. Оставлять phpinfo() в продакшне - примерно как оставить ключи в замке.

Статус-страница и почему её надо закрыть

Apache по умолчанию включает mod_status - страницу /server-status, которая показывает все активные соединения, запросы, статистику нагрузки. Полезная штука для мониторинга, но в дефолтном конфиге она доступна всем.

В /etc/apache/httpd.conf находим блок:

<Location /server-status>
    SetHandler server-status
    Order deny,allow
    Deny from all
    Allow from 127.0.0.1
</Location>

Если такого блока нет или Allow стоит без ограничений - добавляем или правим. Разрешаем только с локального адреса, и всё. Что плохого в открытом статусе? Любой желающий видит сколько воркеров Apache занято, какие URL обрабатываются прямо сейчас, сколько памяти под запросы. Это разведывательная информация для того, кто хочет нагрузить сервер в нужный момент или просто посмотреть что за сайты на нём крутятся.

Аналогично с mod_info - страница /server-info показывает полную конфигурацию Apache включая все загруженные модули и их настройки. По умолчанию тоже открыта. Закрываем так же.

Логи и что в них смотреть

Два лога на виртуальный хост - это уже нормальная практика: error.log и access.log раздельно. В error.log первым делом смотрим на старте: нет ли ошибок парсинга конфига, нет ли permission denied при обращении к файлам. В access.log - чтобы понять что вообще приходит.

tail -f /var/log/apache/example.ru-error.log

Это работает как диагностика в реальном времени: открываешь сайт, смотришь что появляется в логе.

Поставить Apache и запустить сайт - это полчаса. Поставить Apache правильно - ещё час сверху. Разница видна не сразу, а когда что-то идёт не так: либо ты точно знаешь где смотреть и что трогать, либо нет.

Домен и DNS к этому моменту у клиента уже были настроены отдельно - сайт заработал сразу как только записи A обновились у регистратора. Обычно это занимает несколько часов.