Зачем разбивать конфиг на много файлов?

Для модульности и лёгкости настройки. Править тот же squid.conf очень сложно.

модульность конфигов ненужна.
«лёгкость настройки» добавляет не отдельный инклуд файла, а вера в то, что его мнемоническое название делает то, как называется. стоит эту веру только раз пошатнуть...
а править squid.conf очень сложно, потому, что по авторам синтаксиса плачет расстрельная статья.

пау и весь твой коммент в труху.

Карго-хипсторы следуют бест практисес, проходите, не задерживайтесь.

модульность конфигов ненужна.

Во-первых, «не нужна», во-вторых, нужна. sed'ом править конфиг из скриптов rpm/deb не особенно интересно. Как ты сказал? «Пау, и весб твой коммент в труху»? :)

модульность

config/input.conf всё-таки удобней, чем искать в 10-∞ кб файле то же самое и с остальным, например в иксах секции размещать в отдельных файлах, управлять очерёдностью можно циферками в начале — взять тот же udev.

пиши как удобно для данного проекта

теоретики не нужны

ну и потом включать/отключать/заменять секции обновлением симлинков тоже удобно

Например, удобно выносить повторяющийся кусок конфигурации в отдельный файл и инклюдить его из тех вхостов, где это нужно.

Личное вкуснотеево. В малых объемах конфига разницы быть не должно.
Но как написали выше. В случае повторения кусков удобнее использовать модульность. Так же парсить километровый конфиг тяжелее чем отдельные модули.

зачем разбивать код на функции? почему нельзя просто писать последовательность инструкций?

на самом деле можно и так даже делали, когда-то очень давно.

man реиспользование кода
man читаемость кода

Навеяло вашими формулировками. Я вот тоже не прав с фразой «В малых объемах конфига разницы быть не должно» когда этот «маленький конфиг» но с минимальными изменениями должен быть использован в разных местах, по большому счету это тоже становиться «неприятным моментом». Отвлекаясь от темы ТС (апач) далеко не у всех демонов есть возможность инклюдов и иногда это вызывает определенное неудобство в случае одновременного изменения.

В каких случаях имеет смысл сводить конфиг в один файл?

Когда он маленький.

Тогда можно сделать генерацию итогового конфига из набора шаблонов, как в grub, например.

Но это как раз тот самый include, пусть и требующий сборки командами. Так же можно сказать и про m4 сэндмыла из которых получаеться sendmail.cf

Для модульности и лёгкости настройки.

Что мешает в одном файле просто отделять секции отвечающие за разные вещи?

И в начале коммент с содержанием с номерами строк?

Просыпайтесь. Предположим есть два-три-пять...сто параметров которые должны быть одинаковы в «пяти...сотни» «секциях» но вот другие (всего один-два) параметры там различаются. Предлагаете копипасту?
Выше Ford_Focus очень правильно написал на примере функционального программирования Зачем разбивать конфиг на много файлов? (комментарий)

ненужна

Во-первых, «не нужна»

грубить значит решил, да?

sed'ом править конфиг из скриптов rpm/deb не особенно интересно

что это за фантазии и как они относятся к нужности модульности? никак.

Но когда конфигурация устоялась, и её надо копировать на другие системы, не удобнее ли всё собрать в один файл?

А сильно ли большая разница, один конфиг тащить, или /etc/httpd/* ? Зато читабельность выше, не надо по всему файлу шариться.

Плюс если Апач в дистриутиве обновляется, и что-то требует замены в конфиге (скажем, что-то заобсолетилось, хотя это сильно большой скачок по версиям должен быть, как правило), то нетронутый системный конфиг обновится сам.

грубить значит решил, да?

???

что это за фантазии и как они относятся к нужности модульности?

Если хоть на миллисекунду включить голову, то сразу поймёшь :)

???

чтобы учить написанию слова ненужно на лоре? нужно быть особо одарённым, при пяти звёздах это просто оскорбление.

Если хоть на, то сразу

ты гонишь? у тебя в выдуманном примере — sed. ему срать на кол-во файлов и модульность.

У людей принято считать иерархию удобной системой. «Удобно» - это эмоциональная оценка. Чисто случайно, файловая система - это тоже иерархическая система. Поэтому «удобно» хранить «удобно» спроектированные конфиги в «удобных» системах. Просто у каждого свои критерии удобности.
Если хочется доказательности, берешь разные структуры данных (список, массив, деревья разных видов, или вообще произвольный граф) и пытаешься на них сымитировать повседневное поведение с удалениями, вставками, перемещениями и тд и тп. После некоторого количества экспериментов можешь как-то измерить свое эмоциональное удобство.
И да, у каждого свои критерии удобности, которые чисто случайно могут совпасть с твоим эмоциональным состоянием в данный момент времени в данной точке пространства.

чтобы учить написанию слова ненужно на лоре? нужно быть особо одарённым, при пяти звёздах это просто оскорбление.

У тебя всё хорошо? Никто не умер, не заболел?

ты гонишь? у тебя в выдуманном примере — sed. ему срать на кол-во файлов и модульность.

Нет, я просто пропустил совсем чуть-чуть промежуточных рассуждений, которые аксиоматичны опытному пользователю/администратору Linux/Unix.

ага, со стороны это выглядит как пропустил чуть-чуть рассуждений в принципе, напустив тумана, ууу, что-то аксиоматичное, о чём не знает собеседник.
здесь нужно процитировать царя, примерно: «ты думаешь что знаешь хоть что-то о чём не знаю я»?

Конфиг может быть написан как программа (dsl). При изменении конфига нет необходимости перезапускать всю систему, которая имеет определенное состояние, которое не восстановишь при перезапуске, а небольшой кусок конфига изменит только ту часть которую нужно.

напустив тумана

Да какой тут туман. Вероятность ошибки при работе sed'а на 1к текстовом файле гораздо меньше, чем на 500к текстовом файле. Кроме того, при разбиении конфига на модули условный sed вообще можно не запускать.

У меня на сервере 2000 хостов. Надо отредактировать всего один. Мне один огромный файл парсить, или зайти в каталог с конкретным виртхостом?

Вероятность ошибки при работе sed'а на 1к текстовом файле гораздо меньше, чем на 500к текстовом файле

фантазии на уровне интуиции. на деле, вероятность ошибки зависит от инструмента незначительно. будь то sed или Jinja2 — они делают то, что им сказали. а разбиение кусков конфига на разные файлы с разными названиями не делает тебя безошибочным в том, что ты просишь сделать инструменту.

если у тебя есть софт, который генерирует конфиг — вообще пофигу как там устроено логическое разбиение на файлы. а вот сам факт разбиения означает, что всё плохо. либо всё херово продуманно и есть куча повторений, или всё настолько сложно, что понять просто текст недостаточно, нужно ещё и разбить его на разные файлы, либо ещё хуже, у тебя конфиг на 500k строк и консольный текстовый редактор охеревает.
и всё это нахер ненужно, как и программирование на конфигах. всё это симптомы хероты.

если у тебя есть софт, который генерирует конфиг

Ключевое слово - «если». Вопрос про апач, во-первых, а не про абстрактный ненаписанный ещё софт. Во-вторых, у апача (и того же php) есть куча модулей, которые можно подключать, а можно не подключать. Можно установить, но не подключать. Для установленных модулей есть условный conf.d/*.conf и это КРАЙНЕ удобно для опакечивания и дальнейшей поддержки и обновления.

и всё это нахер ненужно, как и программирование на конфигах. всё это симптомы хероты.

Можно твой проект уровня хотя бы в 100 раз меньше httpd увидеть? А то как-то странно выглядит :)

Можно твой проект уровня хотя бы в 100 раз меньше httpd увидеть? А то как-то странно выглядит :)

конечно. отправил в личку, проверяй.