LINUX.ORG.RU

Конфиг и Конфиг.d

 , , ,


0

2

Давно заметил, что куча софта использует формат настроек, где используется конфиг файл <config_name> и директория <config_name>.d для хранения конфигов.

Например apt.sources.list и apt.sources.list.d.

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

Upd: учитывая количество неверно истолковавших мой вопрос, очевидно я ошибся в формулировке. Вопрос не про то, почему так и зачем оно нужно или чем это удобно.

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

Upd: Попробую, ещё раз уточнить что я имею в виду

Вот например man apt.conf, тут описанно что существует директория Dir::Etc::Parts и, что специфичная реализация в дистрибутиве ubuntu использует apt.conf.d. Указанно, как будут мёржиться в конфиг эти самые Parts. По этому документу можно построить совместимую реализацию или протестировать имеющуюся.

Вот man sources.list тут, этот момент - упущен, по крайней мере я не нашёл ссылки из которой следует наличие sources.list.d. И это один и тот же проект.

Перемещено tailgunner из development

Перемещено tailgunner из talks

★★★★★

Пакеты, которые какие-то настройки сопровождают, не лезут каждый в <config_name> , а бросают свой файл конфигурации в <config_name>.d. И все.

Zubok ★★★★★ ()
Последнее исправление: Zubok (всего исправлений: 1)
Ответ на: комментарий от Zubok

Ну, это ты мне рассказал частный случай, но, кроме apt ещё дюжая толпа софта использует такой протокол. Взять тот же шелл, web сервера, systemd, emacs и много много чего:

find /etc/ -name '*.d'
pon4ik ★★★★★ ()

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

Второе.

intelfx ★★★★★ ()
Ответ на: комментарий от intelfx

Первое доказать просто, для второго, ты уж извини, но нужно что то большее чем твоё авторитетное мнение :)

pon4ik ★★★★★ ()
Ответ на: комментарий от pon4ik

При чем тут только apt вообще? Ты не понял, что я написал просто. Вот, к примеру, есть конфигурация, которая идет вместе с каким-нибудь проприетарным драйвером для иксов (я просто пример привожу). При установке драйверу не нужно залезать в единый файл xorg.conf, чтобы прописать свою конфигурацию, а просто уже готовый файлик бросается в xorg,conf.d.

Zubok ★★★★★ ()
Ответ на: комментарий от Zubok

Дык зачем это нужно я понимаю. Хочу добавить в свой софт, надо обосновать клиенту и задизайнить. Спека упростила бы оба этих пункта.

pon4ik ★★★★★ ()
Ответ на: комментарий от pon4ik

ты уж извини, но нужно что то большее чем твоё авторитетное мнение :)

Просто интересно - чьего авторитетного мнения тебе было бы достаточно?

tailgunner ★★★★★ ()
Ответ на: комментарий от pon4ik

Посмотри на количество проектов использующих этот метод.

Если тебе интересно почему именно это удобно, то можно разжевать:

Параметры в конфигах неравнозначны, у них разный scope, время жизни, приоритеты и, часто, релизный цикл.

Механизм include .d/* позволяет разделить их на группы, которыми можно управлять независимо разными утилитами, или даже одной и той же утилитой, но в разное время.

Альтернативой этому было бы редактирование sed-ом одного большого конфига, что очевидно небезопасно и неудобно.

alpha ★★★★★ ()
Ответ на: комментарий от tailgunner

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

pon4ik ★★★★★ ()
Ответ на: комментарий от pon4ik

Первое доказать просто, для второго, ты уж извини, но нужно что то большее чем твоё авторитетное мнение :)

Ну вот тебе мое непререкаемо авторитетное мнение :)

dexpl ★★★★★ ()
Ответ на: комментарий от alpha

Либо ты невнимателен, либо я неверно сформулировал вопрос (предложи как переформулировать).

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

pon4ik ★★★★★ ()
Ответ на: комментарий от pon4ik

Следи за руками:

На вопрос

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

тебе ответили: второе.

Дальше - обоснование этого ответа.

alpha ★★★★★ ()
Ответ на: комментарий от alpha

Хорошо, количество проектов - велико. Значит это устоявшийся протокол для чтения конфигурации.

Отсюда скорее следует наличие спецификации чем её отсутствие? Иначе, как все эти люди приходят к одному и тому же подходу?

Это в идеальном розовом мире конечно, но странно, что никто не задавался этим вопросом и все тупо всегда пишут новую доку для такого метода конфигурации, хотя по сути он легко генерализуется.

pon4ik ★★★★★ ()
Ответ на: комментарий от pon4ik

стандартизирован ли кем то этот подход, читай есть ли документ

Да, стандартизирован Императором Галактики. Да, документ есть, но ты его не сможешь прочитать - он на высшем галактическом наречии, которое из людей знают считанные единицы. Кстати, Поттеринг - один из них.

anonymous ()
Ответ на: комментарий от pon4ik

Иначе, как все эти люди приходят к одному и тому же подходу?

Обычно, людя хватает интеллекта на то, чтобы заимствовать хорошие вещи и приёмы у других.

anonymous ()

Если у тебя на работе начальники требуют спецификацию на каждый чих - вали оттуда как можно скорее.

ЗЫ: Если ты мазохист, или там просто любишь когда тебя дрючат во все дыры просто так, даже без всякого гейства, то можешь попытаться где-нибудь отрыть спецификации Unix System V. *.d - оттуда пришло, хотя сомневаюсь что даже в спецификациях будет что-либо кроме констатации факта использования такого решения.

Stanson ★★★★★ ()
Ответ на: комментарий от Stanson

Никто от меня ничего не требует. Просто почему бы не поддержать открытый стандарт, если он существует? Если нет, то я вполне успешно разработаю упрощённый вариант под свой частный случай.

pon4ik ★★★★★ ()

Когда я был юн, я брал кусок кода первого apache с парсером конфига. Потом пришли корпоративные фрики, и все решили, что конфиг в xml лучше всех. Теперь, думаю, всем пофиг.

Shadow ★★★★★ ()
Ответ на: комментарий от pon4ik

Никто от меня ничего не требует.

Ага, рассказывай.

Если нет, то я вполне успешно разработаю упрощённый вариант под свой частный случай.

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

Есть 100500 самоочевидных вещей которые нигде не описаны и никак не стандартизированы, однако, являются т.н. «explicit standard». Если много народу используют одинаковое решение - просто используй его тоже, никаких стандартов и прочей ахинеи для этого не нужно.

Stanson ★★★★★ ()
Ответ на: комментарий от alpha

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

pon4ik ★★★★★ ()
Ответ на: комментарий от Stanson

Оффтоп, похоже всё таки в толкс и конструктива не будет :)

И сколько раз ты сдавал в тестирование реализации таких вот explicit стандартов в проектах не за еду и до сих пор не закрытых?

Сколько лет такие проекты поддерживались потом, и не находил ли ты необъяснимо образовавшихся кучек фикалий у себя под дверьми?

pon4ik ★★★★★ ()
Последнее исправление: pon4ik (всего исправлений: 1)
Ответ на: комментарий от pon4ik

Ясно. Перестань заниматься программированием - по тебе плачет должность помощника менеджера среднего звена.

tailgunner ★★★★★ ()

И сколько раз ты сдавал в тестирование реализации таких вот explicit стандартов в проектах не за еду и до сих пор не закрытых?

Ну в проектах так 20, например. И не сдавал в какое-то там тестирование, а просто реализовывал explicit standard.

Сколько лет такие проекты поддерживались потом, и не находил ли ты необъяснимо образовавшихся кучек фикалий у себя под дверьми?

Ну самому старому живому коммерческому проекту уже где-то 22 года. Он, правда, очень узкоспециальный, но тем не менее. А очень интенсивно используемому и по сей день - где-то 15 лет.

Никаких кучек, только бабло и благодарность.

Завязывай с этим говнищем с TDD. Оно только в энтерпрайзе годится, чтобы друг на дружку проще было косяки списывать, для чего-либо серьёзного оно вообще мало пригодно.

Stanson ★★★★★ ()
Последнее исправление: Stanson (всего исправлений: 1)
Ответ на: комментарий от Stanson

И не сдавал в какое-то там тестирование

Видимо контора специализируется на саппорте, раз такое допускается и поощряется благодарностями и баблом. Оно и понятно больше багов больше денег.

pon4ik ★★★★★ ()
Ответ на: комментарий от tailgunner

TDD как раз рулит.

Оно рулит только для какой-то элементарщины, которая впрочем и составляет 90% энтерпрайза. Для чего-то мало-мальски серьёзного, TDD либо неприменимо вообще, либо резко увеличивает трудозатраты при сомнительном результате. Например - напиши тест для функции sin(x). Чтобы гарантировано все возможные ошибки реализации ловил. Или, например, написание теста для простенького автомата состояний может занять на порядки больше времени чем написание самого автомата и его математического доказательства.

У ТС с другим проблемы.

Ну в общем да. Ему в чиновники надо, или там в адвокаты. На каком нибудь lawyers.org.ru - нашёл бы единомышленников легко.

Stanson ★★★★★ ()
Ответ на: комментарий от pon4ik

Видимо контора специализируется на саппорте, раз такое допускается и поощряется благодарностями и баблом. Оно и понятно больше багов больше денег.

Я тащемта сам себе контора, и саппорт у меня бесплатный. Бабло в основном на продажах и реализации разных хотелок зарабатывается. Или на объяснении почему хотелка бессмысленна, и как сделать правильно.

Stanson ★★★★★ ()
Ответ на: комментарий от Stanson

TDD как раз рулит.

Оно рулит только для какой-то элементарщины

Оно рулит для всего, для чего ты можешь реализовать тест. Если ты можешь реализовать тест только для элементарщины - это не проблема TDD.

Например - напиши тест для функции sin(x). Чтобы гарантировано все возможные ошибки реализации ловил

Если буду реализовывать свое вычисление синуса - обязательно напишу.

написание теста для простенького автомата состояний может занять на порядки больше времени чем написание самого автомата и его математического доказательства

Начались сказки. Причем, что характерно, эта конкретная сказка никак не противоречит TDD.

tailgunner ★★★★★ ()
Ответ на: комментарий от Stanson

Я тащемта сам себе контора

А сотрудников сколько? И сколько человеко-лет было затрачено на разработку проектов про которые ты упоминал выше?

pon4ik ★★★★★ ()
Ответ на: комментарий от pon4ik

.d - это название каталога. Не стандарт, не протокол, не метод, а название.

Так же как например venv - типичное название для каталога с python-virtualenv окружениями.

То что ты там хочешь стандартизировать - это, вероятно, именование самих файлов, то есть вот apt читает /*.list, salt читает /*.conf, а кто-то может просто /*.

Или допустим несколько стандартных конфигов, которые идут в поставке: типа 00_users.conf, 50_network.conf и т.п.

Но это специфика. Её не стандартизировать надо на все случаи жизни, а задокументировать для своего приложения. Тестами обвязать по вкусу.

Обощать такое - получится либо неприменимо, либо банально.

alpha ★★★★★ ()
Ответ на: комментарий от alpha

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

Собственно эти Dir::Etc::Parts меня и вдохновило на поиск готовой спецификации ибо попытки имели место быть даже в такой древности как apt.

pon4ik ★★★★★ ()
Последнее исправление: pon4ik (всего исправлений: 1)
Ответ на: комментарий от tailgunner

Оно рулит для всего, для чего ты можешь реализовать тест. Если ты можешь реализовать тест только для элементарщины - это не проблема TDD.

Реализуй мне тест для sin(x).

Если буду реализовывать свое вычисление синуса - обязательно напишу.

Ну так тест в студию.

Начались сказки. Причем, что характерно, эта конкретная сказка никак не противоречит TDD.

TDD не панацея и даже не новинка. С какого хрена оно сейчас внезапно стало популярно у хипстеров - совершенно непонятно. Весьма узкоспециальная штука.

Stanson ★★★★★ ()
Ответ на: комментарий от Stanson

Завязывай с этим говнищем с TDD

Я тоже последнее время сколняюсь к мнению, что для серверных продуктов с близкой к оптимальной реализацией и интерфейсом состоящим чуть менее чем полностью из легко считываемых/мокаемых сайд эффектов дешевле применять BDD и непрерывное нагрузочное тестирование ;)

pon4ik ★★★★★ ()
Последнее исправление: pon4ik (всего исправлений: 1)
Ответ на: комментарий от pon4ik

А сотрудников сколько?

Человек по 20 бывало. Но самые долгоживущие и прибыльные проекты почему-то делались при помощи всего лишь одного-двух человек.

И сколько человеко-лет было затрачено на разработку проектов про которые ты упоминал выше?

А какая вообще может быть связь между человекогодами и качеством продукта? Если какая-то контора потратила 100500 человеколет на создание ненужно - это вообще ничего не говорит ни о качестве ненужно, ни о нужности ненужно, ни даже о степени глючности ненужно.

Ну представь - стартап назанимал денег, нанял тыщу программистов, они 10 лет писали тесты для sin(x), а потом оказалось что их sin(x) таки неправильно считает sin(0.023483729347894), что тот пентиум. И что, помогли эти 10 тыщ человекочасов и модный workflow написать годный sin(x)?

Stanson ★★★★★ ()
Ответ на: комментарий от Stanson

Реализуй мне тест для sin(x).
Ну так тест в студию.

Я выше сказал, в каком случае буду это делать.

TDD не панацея и даже не новинка.

О, TDD не является очень многим. Например, это не зеленый сыр, не письменный стол, не плохая погода и не 29 февраля.

tailgunner ★★★★★ ()
Ответ на: комментарий от pon4ik

Локальная понятно не лишняя.

И если я буду configuration management делать для 100500 микросервисов - можно и не очень локальную общую схему их конфигов написать.

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

alpha ★★★★★ ()
Ответ на: комментарий от Stanson

А какая вообще может быть связь между человекогодами и качеством продукта?

Это конечно чисто эмпирическое наблюдение, но чем больше проект, тем дороже его саппорт. Речь естественно про успешные проекты.

Ну представь - стартап назанимал денег, нанял тыщу программистов, они 10 лет писали тесты для sin(x), а потом оказалось что их sin(x) таки неправильно считает sin(0.023483729347894), что тот пентиум. И что, помогли эти 10 тыщ человекочасов и модный workflow написать годный sin(x)?

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

Возможно, ты конечно познал какие то особые таинства и твои проекты живут по 20 лет без саппорта, тестирования и документации. Но скорее всего, использующие их просто перестают развиваться, либо в процессе своего роста переходят на что-то ещё.

Хорошо, с бесплатным и при этом не отнимающим значительную часть ресурсов саппортом.

Остальные неудачники на рынке тратят до 70% ресурсов на саппорт, видимо тебе надо устроиться CEO куда нить в фейсбук что ли, будешь самым высокооплачиваемым руководителем года.

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

pon4ik ★★★★★ ()
Ответ на: комментарий от pon4ik

Я тоже последнее время сколняюсь к мнению, что для серверных продуктов с близкой к оптимальной реализацией и интерфейсом состоящим чуть менее чем полностью из легко считываемых/мокаемых сайд эффектов дешевле применять BDD и непрерывное нагрузочное тестирование ;)

Ну как минимум это будет быстрее/дешевле с примерно такой же вероятностью всплытия глюков. По крайней мере для таких задач. Да и нагрузочное тестирование TDD никак не заменит. :)

Stanson ★★★★★ ()
Ответ на: комментарий от alpha

Да, я уже понял, что на сию дискуссию потратил времени больше, чем на дизайн и реализацию. Однако, идея взять что-то открыто-готовое была очень уж заманчива.

pon4ik ★★★★★ ()
Ответ на: комментарий от pon4ik

Возможно, ты конечно познал какие то особые таинства и твои проекты живут по 20 лет без саппорта, тестирования и документации. Но скорее всего, использующие их просто перестают развиваться, либо в процессе своего роста переходят на что-то ещё.

Не, просто всего надо в меру и в нужном месте - и саппорта, и тестирования и документации. Переборщишь с саппортом - будешь в итоге ОС клиентам переустанавливать/настраивать, переборщишь с тестами - упустишь то, что тесты не покрывают, переборщишь с документацией - выкинешь кучу времени, которое деньги, в помойку, ибо толстую документацию никто читать не будет и никому эти подробности не помогут.

Остальные неудачники на рынке тратят до 70% ресурсов на саппорт, видимо тебе надо устроиться CEO куда нить в фейсбук что ли, будешь самым высокооплачиваемым руководителем года.

Я мизантроп, в CEO не гожусь.

А то сколько денег и благодарностей ты получил, говорит больше о твоих маркетинговых способностях, нежели качестве продукта

Маркетинга-то я и не заметил. Хотя нет, вру, был для одной софтины маркетинг в Laserist'е (официальный бумажный журнал ILDA в 90-х). Толку было мало, от общения в инете и на конференциях толку гораздо больше было. А остальное - как-то само расходилось. А предпоследний проект вообще чуть ли не подпольно распространяется, ибо позволяет работать с забугорными приборами, производители которых не особенно хотят чтобы их использовали с чужим софтом, а отечественный потребитель не может их использовать с забугорным, ибо забугорный не умеет считать отечественные коэффициэнты и параметры требуемые всякими сраными ГОСТами. И ведь как пирожки горячие расходится, ну с учётом узкости и малоизвестности такой области как колориметрия.

Так что дело не в маркетинге, а в качестве. Если штука полезная, удобная, шустрая, делает то что нужно, не требует распоследнего железа и не падает от каждого чиха - то на сегодня это лучшая реклама для ПО.

Stanson ★★★★★ ()
Ответ на: комментарий от Stanson

Так что дело не в маркетинге, а в качестве

Или в узком сегменте рынка и отсутствии конкуренции. Выбор которого опять же скорее про анализ рынка и маркетинг чем про разработку.

Попробуй продать и поддерживать, ну например реализацию map-reduce. Её вполне реально сделать эффективную даже в одно лицо, но выйти на уровень уже имеющихся игроков по функционалу и интеграции в различные сервисы а уж тем более поддерживать, хм. Похоже на сказку?

pon4ik ★★★★★ ()
Ответ на: комментарий от pon4ik

Однако, это та же идея что в TDD, просто проверяются аспекты более высокоуровневых интерфейсов?

Если я чего-то смыслю в ВDD, то нет, не та же. Проверяется правильность поведения, а не конкретный результат. В комплекте с тупенькими юнит-тестами даёт вполне ощутимую гарантию того, что в будущем если кто-то что-то поломает, то это тут же будет выявлено и пофиксено.

Stanson ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.