Я использую сервер Ubuntu прямо сейчас (для локальной разработки) и заметил, что некоторые пакеты Ubuntu, такие как apache, имеют свои файлы конфигурации ... гм ... разбросаны.
В то время как официальные документы Apache в основном ссылаются на httpd.conf для всего, пакеты Ubuntu Apache умело делят этот файл на ..um ...> 20 файлов.
Например, вместо добавления виртуальных хостов в httpd.conf ожидается, что вы создадите файлы в подкаталоге, а затем добавите псевдоним к другому каталогу ... m'ok. Думаю, многим это нравится ... но я ... эм ... думаю, что это слишком усложняет ситуацию. если я хочу разделить свой конфиг - я могу это сделать сам.
Пакеты какого дистрибутива Linux-сервера, по вашему мнению, меньше всего настраиваются создателями?
Оставайтесь с этим макетом! Это дает преимущество conf.d папки. Файлы в этих папках никогда не перезаписываются, в отличие от httpd.conf! Затем Apache собирает все фрагменты в файл httpd.conf. Вам не нужно заботиться о порядке директив, потому что это XML-подобный файл конфигурации.
Собирать все директивы в одном файле действительно непрактично. Иногда я даже разбиваю эти конфигурации на более мелкие, частично редактируемые пользователем файлы.
Посмотреть в /etc/apache2/conf.d/. Если вы ищете какие-то директивы и не знаете, в каком файле искать, используйте команду grep: grep -i -r "<IfModule mod_foo*" /etc/apache2/conf.d.
По сути, это хорошая идея никогда не редактировать сам httpd.conf. Даже если вы хотите переопределить существующие объявления, скопируйте их в файл * .conf в каталог conf.d и перезапустите apache после изменений в скопированном файле.
Для серверов, которые требуют высокой степени функциональной настройки (и если у них достаточно времени, они все это делают), я предпочитаю использовать свои собственные. Я знаю, что это не совсем ответ на ваш вопрос, но вам стоит рассмотреть этот вариант. После нескольких лет попыток `` плыть по течению '' и модифицировать вещи поверх того, что мне давали официальные пакеты, оказалось, что они взламывают это так же часто, как и я, но по-другому, и что более важно, неинтуитивно для меня. . В итоге я создал свои собственные сценарии для сборки, компоновки и установки моего собственного apache с модами, php, mysql и т. Д. Позже я пошел еще дальше и сделал свои собственные пакеты из этих сценариев для облегчения распространения. В конечном итоге это стало намного проще поддерживать, потому что, хотя это была странная установка, это была МОЯ странная установка, и я мог исправлять / обновлять вещи намного быстрее, чем копаться в десятках conf.d / *. Conf разбросал все над файловой системой. Сначала это отнимает много времени, но в долгосрочной перспективе это отлично работает.
Подобные изменения - основная причина, по которой мы не используем какие-либо дистрибутивы Debian или Ubuntu. В конечном итоге вы используете версию Apache Ubuntu, а не сам Apache.
Я не знаю, какой другой дистрибутив ближе к исходным источникам апстрима, я знаком с RedHat и CentOS, и эти 2 также вносят изменения, хотя и менее драматические.
Вы можете попробовать удалить пакеты, поставляемые с дистрибутивом, которые доставляют вам проблемы, а затем скомпилировать нужное программное обеспечение из источников в /opt и его подкаталоги. Затем вы сможете управлять конфигурацией в соответствии с вашими предпочтениями (я бы порекомендовал Puppet, но это может быть излишним, если у вас только один сервер).
Обычно дистрибутивы разбивают файлы конфигурации, чтобы соответствовать какой-то методологии или философии дистрибутива. Вместо того, чтобы apache имел один макет конфигурации, а exim - другой, они оба будут относительно схожими, так что если вы знакомы с дистрибутивом, вы будете знать, где искать конфигурации для любого нового пакета, который приходит вместе.
Я предлагаю вам выбрать дистрибутив с методологией, которая вам в целом нравится, затем хорошо изучить ее и научиться играть по ее правилам. В конце концов, это облегчит вам жизнь.
Документация apache или любая другая документация в этом отношении обычно носит общий характер и обсуждает простейший из возможных сценариев, но в реальном мире все редко бывает так просто. Разделение конфигураций на несколько файлов упрощает управление типичными сценариями реального мира в долгосрочной перспективе.