Если это понравилось, то может понравится и это: http://www.nordier.com/v7x86/ — рабочий порт v7 на i386.

Демоны - нафиг. Сложность разворачивания/обслуживания сразу усложняется, появляется overhead.

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

Плейнтекстовые файлы - страшная сила в плане автоматизации и простоты

Твоя конфигураторная служба/утилита убирает нужду (и, в общем-то, запрещает её) обработки хранилища конфигов как плейнтекста посторонними утилитами. Все операции - сугубо через интерфейс службы конфигов.

никакая система, не сводящаяся к ним, не приживётся.

См. бинарные форматы баз данных. См. ELF, чо уж там :)

в rpm есть /etc/sysconfig и разные гуи для его редактирования, но там костыль на костыле, которые из одних конфигов генерят другие.

хранилище конфигурации с единым API для всех программ - то, чего хочется.

Передо мной сейчас как раз открыты конфиги Астериска. Так к какому API разработчики должны их привести?

2. Не пары, а тройки: вес, ключ, значение. Тоже вполне себе.

О, кстати, такой вариант реализован в asterisk, если хранить sip.conf в БД.

конфиги Астериска. Так к какому API разработчики должны их привести?

Так ни к какому же. Конфиги остаются, пишется сабжевая тулза, обеспечивающая API, а к ней подключаемые бэк-энды для работы с разными конфигами, в т. ч. и астериска.

Так ни к какому же. Конфиги остаются, пишется сабжевая тулза, обеспечивающая API, а к ней подключаемые бэк-энды для работы с разными конфигами, в т. ч. и астериска.

Т.е. вместо полноценного редактора предлагается использовать какой-то левый костыль для правки тех же диал-планов? Сомнительная фича.

Не костыль, а обёртку. И зачем править диалплан каждый день. Чаще приходится добавлять/изменять/удалять пользователей в sip.conf, и зачем для него «полноценный редактор», если можно astuseradd -v 4353:pupkin:`openssl rand -base64 12`.

И зачем править диалплан каждый день.

Мысль ясна. Вопросов больше не имею :)

Можно пример, когда это нужно? Интересно как астерисководу.

Как это не прижился? Прижился. Называется vim. Есть совместимые аналоги с упрощённым, но менее эффективным интерфейсом, например nano.

Все известные мне конфиги в такую схему укладываются.

Можно пример, когда это нужно? Интересно как астерисководу.

Когда имеется больше дюжины серверов с *, например

Иии?.. Диалплан составлен, работает, синтаксис стабилен, что меняется?

ох боги...
ну *.plist чем не альтернатива реестру??

с т.з юзверя должен быть реестр, который бэкапится в ХМL

Прикольно. Спасибо.

ibm aix sam ???
как-то вылетело из памяти / т.к. в живую не видел ни рсазу

тому, кому надо оперативно писать/править сложные диалпланы, сабж никуда не упёрся, в этом случае сабж - ненужная причуда

И в очередной раз какая-то философия затмевает людям разум. Конфиги ж никуда не денутся, ну!

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

Потому-что не всегда правило, строчка, высказывание будет работать верно если просто дописать его в конец конфига. Иногда нужно разобраться с логическим устройством. Как самый банальный пример, это правила squid или iptables, если вписать не туда, так оно вообще может не сработать или сработать весьма необычно. Нужно представлять порядок цепочек, и т.д. в голове.

А я пару лет назад писал на ЛОР с другой идеей: демон конфигурации. У него быстрая БД со всеми конфигами, программы его спрашивают «дай мой конфиг», а он даёт. Общаться они могут по dbus, например.

И снова здравствуй, linuxconf.

Ум-м... много комментариев.

К чему пришли в итоге? Пишем? Берём готовое и унифицируем? Могу поспособствовать, если питон или С++

укладывается в такую систему

apache

Ты это серьёзно? Почитав, как «складываются» параметры из контейнеров Directory, File, Location, и *Match, и как сказывается, например, порядок следования RewriteRuleй, полагаю, что любой более-менее сложный конфиг апача в эту схему уложится так, что лучше бы нам этого не видеть. Примерно то же с dhcpd и bind-ом (кроме пары тривиальных случаев), и даже ssh-ем (Match уже видел?).

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

Напиши Поттерингу, через несколько недель появится.

ты будешь удивлен.

Почему это не реестр:

Коменты

в реестре есть комменты просто никто ими не пользуется.

Это не единый файл БД, а набор файлов, просто со стандартным API и command-line tools для работы. Поддаётся синхронизации с удалённым источником, ручной правке с помощью regexp и какой-то там матери, вобщем всё как с обычными файлами, но единообразно для всех программ.

все это есть в реестре — вопреки расхожему мнению это не один файл, и ничто не мешает написать к нему консольную утилиту по типу той что ты предложил. она даже есть, только не все что ты перечислил умеет — ну да это не важно, все решаемо через wmi и powershell.

Один каталог верхнего уровня для каждой программы, в менеджере пакетов по ним информация. Каталоги, не относящиеся ни к какому пакету, можно легко выявить и удалить.

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

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

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

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

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

Точно разум затмевает. Упорыш, тебе и говорят, про единый стандарт конфигов.

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

К вопросу о стандартном конфигураторе.

Мужики, мужайтесь и бабайтесь!
Вангую его создание, после завершения работ над systemd.
Уже растёт малыш, который устроится в RH и перепишет эти ваши старые текстовые конфиги на новый, DB_xml ориентированный вариант.

Или думаете зря время тратили, на QR коды в ядре?

Да, а кто сделает талантливо?

Во сколько мегабаксов обошелся НИОКР по ZFS?
Кто скажет?

Ха, НИОКР, да ты пошутил. Программисты не могут в НИОКР.

Тут пока только-только начали избавляться от ~/.-hell, от кучи каталогов, начинающихся с точки в $HOME.

Догадались таки многие приложения перенести в ~/.config

А автоматизировать всё можно, да. Действуй.

Почему xml? А почему не yaml?

та без разницы. главное ml, а там хоть в node.js :)))

вот я и любопытствую во сколько обошелся ниокр на зфс?

система в продакшине 9лет и ее продолжают пилить.

Я так и не увидел какую проблему пытаются решить с помощью «стандартного мегаконфигуратора всего».

А нахуа ?

$ conf get sshd.tcpkeepalive
=
cat /etc/ssh/sshd.conf | grep tcpkeepalive

sshd.tcpkeepalive=no
=(в простом случае)
echo "tcpkeepalive=no" >> /etc/ssh/sshd.conf

Для сложного случая есть системы управления конфигурациями.
Предлагаемый велосипед есть в openwrt. Пользоваться невозможно, проще конфиги править.

Ну, ext в продакшене 20 лет :)

потребности у софта *слишком разные*

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

Но при этом в каждой софтине это реализовано по-разному: где-то ini-файл, где-то xml-подобный синтаксис, где-то похоже на шелл-скрипт, где-то синтаксис C-подобный, но со своими тонкостями. Где-то комментарий «#» только в начале строки, где-то - «#» в любом месте строки начинает комментарий, где-то ";" или «//» тоже используется для комментирования. Плюс ни в одном из форматов комментарий не привязан к записи, из-за чего после автоматической правки человеко-читаемость теряется. Где-то для конфига есть парсер для проверки корректности(testparm), где-то надо перезапускать демон и смотреть с какой ошибкой он умер, если ты забыл ";".

Вот хотелось бы всё это иметь в единообразном виде. Идея изначально навеяна конфигами Mikrotik, никогда не сталкивался? Очень удобно

Если это понравилось, то может понравится и это: http://www.nordier.com/v7x86/ — рабочий порт v7 на i386.

Клёвая штука, спасибо :)

cat /etc/ssh/sshd.conf | grep TCPKeepAlive
#TCPKeepAlive no
# Also see TCPKeepAlive below
# Option TCPKeepAlive specifies sending TCP keepalive messages
# TCPKeepAlive yes
TCPKeepAlive yes

echo "tcpkeepalive=no" >> /etc/ssh/sshd.conf

А там сверху уже tcpkeepalive=yes есть. То ли первый вариант будет использовать, то ли последний, то ли вообще выругается и не запустится - зависит от софтины.

Мне приходилось править конфиги с помощью grep/sed, это неудобно.

Поэтому я и приписал «в простом случае».
1. В самом простом случае конфиг разово правится. В простыне конфига обычно есть исчерпывающая документация и полный набор опций. Мы не знаем опции и их значения, настройка разовая - берем vi и имеем отличную замену виндовой гуйне, по части информирования нас о доступных настройках их возможных значениях и даже отсылы к другим параметрам, задача решена.
2. Нам нужно деплоить на много устройств - используем чиф, ансибль, и т.п. Задача решена.
3. Мы не хотим разворачивать систему централизованного управления - хотим просто наваять скрипт, который что-то будет делать. sed, grep - мощные инструменты, которые работают хз сколько лет. Берем и пишем - задача решена.
4. Пишем на питоне/etc, используем библиотеку работы с ini файлами, и получаем желаемые Get/Set. Задача решена.
5. У нас есть вебморда к новому собственному дистрибутиву с чрезвычайно интересными обоями. Берем и пишем Set/Get внутри которых grep/sed/ini.get/set. Задача решена.

Хочется велосипед - он пишется за полчаса на баше/питоне и пользуетесь им сколько влезет. Пока спустя пол-года-пару лет вы не забываете названия пары опций и лезете в ман, чтобы вспомнить названия параметров (внезапно на роутере и сервере мана нет), когда раньше было достаточно открыть конфиг в vi. Или когда однажды ошибетесь и вместо ssh поправите параметр в sshd и потеряете доступ к системе.

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

И как планируете разделять сохраненные значения и текущие в /proc /sys ?
Оставить как есть ? Тогда проще сойтись на posix устройстве файловой системы, в которой все уже на своих местах.

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

Нравятся микроты, ради бога, в лине, значительное количество софта кросплатформенно, тотже openvpn или сквид можно запустить и под виндами скопировав их конфиги и поправив лишь пути. Что, на винды тоже будете портировать эту систему конфигурирования ? Или предложите это разрабам openvp, сквида etc ? А как она у вас многострочные acl сквида поддеживать будет ? А блоки nginx, а lua конфиги ? :)

конфиги, в простом, надежном, переносимом и самодокументируемом формате

Я хочу чтобы этот формат был один для всех.

как она у вас многострочные acl сквида поддеживать будет ?

aclentry -> { 'name', 'type', 'options' -> {}, 'match' } Синтаксис модет быть другой, но идея такая.

на винды тоже будете портировать эту систему конфигурирования?

Это договорённость о формате конфигов и пара утилит для их удобного чтения/редактирования, чего там портировать?

sed, grep - мощные инструменты, которые работают хз сколько лет. Берем и пишем - задача решена.
Хочется велосипед - он пишется за полчаса на баше/питоне и пользуетесь им сколько влезет.

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

блоки nginx

http -> { 
  comment -> "Common HTTP protocol settings"
  ...
}
server -> {
  comment -> "example.com"
  ...
  location -> { ... }
  location -> { ...
}

lua конфиги

someitem -> {
  comment -> "This script generates list of users"
  type -> 'generated',
  parser -> '/usr/bun/lua',
  source -> " ... "
}

acl SSL_ports port 443
acl Safe_ports port 80          # http
acl Safe_ports port 21          # ftp

Я вот понимаю что тут написано в любом состоянии, а в вашем примере уже нет. :(

Я хочу чтобы этот формат был один для всех.

Остается мелочь, всего-то убедить в этом. Всех.
Всеобщий формат всего. Тогда в нем можно будет хранить и тексты и видео. А ? :)
Ну, вы привели кусок текущей простыни nginx как он есть. Как в третьем сервере второго локэйшна прописать два бэкенда через cli ? Как будет выглядеть команда ? А зачем ? Что может быть проще и удобнее vi/блокнота ?
Или вы разрабатываете свою систему управления конфигурациями ? Тогда да, сочувствую, но конфиги, то у разного софта практически идентичны, параметр=значение +своя логика, которая разная, что и находит отражение в конфигах. Запихнуть разную логику в один формат ? - Это примерно как давайте отменим все языки программирования и оставим один, расово верный.

Как в третьем сервере второго локэйшна прописать два бэкенда через cli ? Как будет выглядеть команда ? А зачем ? Что может быть проще и удобнее vi/блокнота ?

Можно будет точно также править vim или делать из шаблона puppet/ansible. Просто если формат стандартизирован, можно ещё иметь для тех же целей cli-утилиту.

давайте отменим все языки программирования и оставим один

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

разрабатываете свою систему управления конфигурациями

Тред помечен «нытьё» и «холивар», потому что понятно, что даже если что-то такое сделать, никто не будет это использовать :( А жаль, было бы очень удобно и экономило бы много времени/усилий

У большей части софта конфигурация укладывается в схему «дерево с нодами типов: строковый, числовой».

это wishful thinking. давай посчитаем, че. ты называешь софт который укладывается в эту схему, я тот, который не укладывается. берем только популярный софт. если я наберу хотя бы 40% от общего количества говорить о большей части софта можно только с большоооой натяжкой. имхо даже если бы 10% оставались за бортом это уже проблема потому что остается неуниверсальность, а вся суть идеи в полной универсальности.

sendmail, iptables, tc, pf, isc bind, isc dhcpd, zebra, vim, shell, sshd, openldap, passwd

someitem -> {
  comment -> "This script generates list of users"
  type -> 'generated',
  parser -> '/usr/bun/lua',
  source -> " ... "
}

замечательно, как будет выглядеть команда которая в том что у тебя обозначено «source» меняет в 19-ой строке foo+=bar + a - b на foo+=baz + b - a?

заметь, от командных редакторов типа ed все перешли на визуальные редакторы как vim. почему?

sendmail: не знаю, я всегда postfix использовал. Судя по тому, что для создания конфигов часто используется препроцессор(!), всё нетривиально, поэтому не получится.

iptables - живой пример: http://ferm.foo-projects.org/ - укладывает правила в иерархический конфиг. То есть возможно

tc - а оно разве конфиги жрёт? По-моему, его всю жизнь напрямую из скриптов вызывали. Но, в принципе, вполне реализуемо(tc давно не трогал, параметры и порядок могу путать):

qdisc -> {
  dev: 'eth0',
  handle -> 1:,
  parent -> none,
  type -> htb,
  params -> { default: 15 }
}
class -> {
  dev: 'eth0',
  parent -> 1:,
  classid -> 1:1,
  type -> htb,
  params -> { rate -> '100mbps', ceil -> '100mbps' }
}

pf - не умею

bind - у него и так синтаксис конфига в виде

<section> {
	param1 val1;
	param2 val2;
};

dhcpd - аналогично с bind

zebra - не умею

vim - не получится, конфиг - скрипт на внутреннем языке

shell - не получится, конфиг - скрипт на нём самом

sshd - получится: конфиг - набор пар ключ->значение

openldap - не умею

passwd - получится:

user -> {
  name -> 'root',
  id -> 0,
  gid -> 0,
  comment -> 'root',
  home -> '/root',
  shell -> '/bin/bash',
  

До кучи: squid - получится, keepalived - получится, crontab - получится, xinetd - получится, ntpd - получится, bacula - получится, apache - получится(он и сейчас иерархический, только xml-подобный), php -получится(это обычный ini-шник), mysql - получится, postgresql - получится.

То есть пока у большей части софта конфиг в такую схему укладывается.