LINUX.ORG.RU
ФорумTalks

Нытьё про cтандартный конфигуратор

 ,


0

1

Почему для *nix не прижился какой-нибудь стандартный конфигуратор софта:

$ conf get sshd.tcpkeepalive
no
$ conf get-default sshd.tcpkeepalive
yes
$ conf show sshd.tcpkeepalive
# Specifies whether the system should send TCP keepalive
# messages to the other side.  If they are sent, death of
# the connection or crash of one of the machines will be
# properly noticed.
sshd.tcpkeepalive=no
$ conf set sshd.tcpkeepalive=yes
$ conf get sshd.tcpkeepalive
yes

$ conf add ssh custom_var --type dir --comment "blalala"
$ conf add ssh custom_var.subwar1 --type string --comment "blalala path"
$ conf add ssh custom_var.subwar2 --type int --comment "blalala magic number"

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

За количество человеко-лет, потраченных на автоматический разбор/написание всяческих конфигов, можно было:

  • допилить Hurd
  • решить в иксах проблемы с тирингом
  • запилить в ванильное ядро MPLS
  • основать колонию на Марсе

Update:

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

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

Последнее исправление: selivan (всего исправлений: 3)

Ответ на: комментарий от Darth_Revan

Да разных попыток много, но таких, чтобы:
- общесистемный - и для служб, и для пользователей
- хотя бы немного распространённый
нету :( Не настроишь nginx/postgresql/keepalived/... через gsettings.

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

Ну, если что-то и сможет приблизиться к общесистемности, так это gsettings, ибо он не плох (я не про dconf, dconf плох, очень плох).

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

<%= картинка с xkcd комиксом про 14 стандартов =>

Не приживётся: Legacy и закон Паркинсона: это несложная и понятная каждому штука, поэтому каждый выскажет свое мнение, и в итоге сделают over 9000 несовместимых велосипедов.

А так хотелось бы :(

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

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

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

В любом случае, с помощью одной утилиты не получится всем софтом управлять, потому что семантика конфигов слишком разная. У одной программы конфиг - тупой набор пар ключ-значение, у другой - скрипт на lua, у третьей - костыльный самописный язык непонятного назначения. Как ты предлагаешь это разруливать?

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

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

К счастью, 99% софта такими проблемами не страдают. Навскидку, какой софт из известного мне укладывается в такую систему: apache, php(cli, fpm, ...), mysql, postgresql, keepalived, dhcpd, bind, ntp, rsync, xinetd, squid, NUT(network ups tools), bacula, ...

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

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

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

thesis ★★★★★
()

Похожее уже есть — sysctl(8). Правда не в линуксах и только для кернела. Отдалённо похожий интерфейс в линуксах — sysfs.

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

Эмм... а это тогда что?

note:~$ which sysctl
/sbin/sysctl
note:~$ whatis sysctl
sysctl (2)           - read/write system parameters
sysctl (8)           - configure kernel parameters at runtime
note:~$ uname -s
Linux
Но оно только для ядра и гораздо менее обобщённое: можно править только список типа: ключ => значение.

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

Я к тому, что линуксовский sysctl — жалкое подобие оригинала. ☺

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

Ну чувак, ну что значит «почему это не реестр:».
Это по определению реестр, т.е. свалка записей. Просто реализация хранилища (см. «каменты») чуток отлична от вендовой и реализация cli/api тоже.

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

С одной стороны - да, с другой - нарушается единообразие синтаксиса: conf <action> <parameters>

Но тред не про это, тред про нытьё как всё плохо и все умрём.

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

Беда в том, что всё плохо и мы все умрём. ☺

Стоить парзилку 1001-го типа конфига — то ли emacs то ли systemd получиться.

А что б не городить это огород — или один DB файл или стардарт на конфиг нужен будет. И тут тебе любой поттеринг глотку перегрызёт.

А вообще-то такой стандарт уже есть — cgetent(3) и с уже готовым C-API (termcap например в этом формате).

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

Свалка в винде оттого, что:

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

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

Если в никсах программы начнут активно писать всякую ерунду в разные каталоги и подкаталоги в /etc, никак не связанные с названием программы - получится точно такая же свалка.

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

Беда в том, что всё плохо и мы все умрём. ☺

Вот, ты меня понимаешь

один DB файл

Для случаев:
- я хочу скопировать/забекапить/перенести на другой хост настройки *одной* программы
- я хочу сконфигурить что-то там с помощью SCM, шаблонов и чьей-то матери
придётся использовать API, с разными файлами - проще.

Сложно разбирать на всяких embedded-устройствах: файл DB может потребоваться загрузить целиком в память, а она не резиновая. Значит, придётся реализовывать ФС внутри файла и грузить по кускам. Но у нас ведь уже есть ФС?

Опять же, непонятно, как чистить от мусора.

du /conf.db
1.4G	

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

Я неправильное слово использовал.
«Свалка» в смысле «хранилище», не в смысле «бардак и насрано».

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

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

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

Gentoo-only. И, как и все остальные тулзы-конфигураторы, не прижился: используют его несколько приложений и всё. Собственно об этом и тред: конфигураторы есть(я привёл обобщенный пример, как оно ИМХО должно выглядеть), но их никто не использует.

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

Вся беда в том, что уже существует «эко-система» и преписывать мульён приложений под новый /etc никто не будет. Поезд ушёл.

\me ноет: была надежда на Plan9, но Linux его убил ☹ — я к тому, что не «кровати двигать надо, а б*** менять» — тогда может и взлетит.

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

Gentoo-only

ну так портируй

используют его несколько приложений и всё

ну так добавь

не прижился

ой ли? так можно сказать, например, что GStreamer не прижился, т. к. он во многом таки да отстой, хотя уже развивается больше 10 лет, но на самом деле в основе лежат мощные концепции, которые востребованы и приведут проект к блестящему успеху.

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

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

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

Лично меня немного смущает само название - etc. Неловко. «А что это такое, etc? наверное, фигня всякая неважная, наверное, можно снести, чтобы местяк высвободить» :)

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

У одной программы конфиг - тупой набор пар ключ-значение

Первый в схему укладывается

А если имеет значение порядок?

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

Запили.

<%= картинка с xkcd комиксом про 14 стандартов =>

Возьми самую подходящую и допили.

Я вот вообще ни одной не знаю.

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

что это такое, etc? наверное, фигня всякая неважная

Ну, вообще-то изначально оно так и было — всё, что не влезло куда-либо в другое место. ☺

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

Ну почему. Если он у тебя будет поддерживать много программ, будет иметь возможность создавать версии конфигурирования (но не более одной), ужасно выглядеть и не давать менять все доступные настройки (например игнорировать все параметры в имени которых есть заглавная буква), то обязательно взлетит. Если же ты будешь вырезать из него функционал постепенно начиная с первого релиза, то есть шанс, что его по дефолту начнут ставить. Особенно в Gnome.

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

В любом случае, с помощью одной утилиты не получится всем софтом управлять

Фишка не в том, чтобы управлять всем из одной программы, а в том чтобы иметь единый интерфейс. В последствии к нему прикручивается GUI и далее разработчики вместо того, чтобы писать в ПО свой конфигруатор просто вешают на пункт меню Параметры что-то типа systemConfigure::OpenSettingsWindow('MyProgramm'); И открывается окошко стандартное для всех программ но с твоими настройками.

С окном выбора файла же так работает. Почему не должно работать с конфигурированием. Очень странно что один и тот же функционал приходится повторять в 100500 программ. А еще это бы дало много возможностей по доступу одних прог к конфигурации других. Вообще на сегодняшний день интеграция прогрмм между собой и с системой - хуже некуда. Я вот добавляю конакт в адресную книгу в M2 в Opera. Открываю громоптицу, а в ее адресной книге контакта нет. Я смотрю на календарь - там 2014 год. Потом смотрю в адресную книгу, а контакта все равно нет... Походу врут календари (((

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

Каталоги - я в посте написал:

$ conf add ssh custom_var --type dir --comment "blalala"
$ conf add ssh custom_var.subwar1 --type string --comment "blalala path"
$ conf add ssh custom_var.subwar2 --type int --comment "blalala magic number"
Можно делать вложенные, не проблема. Сценарии - включать в строковом виде + ссылка на интерпретатор.

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

Варианты:

1. Массив пар ключ-значение. Массив - то есть порядок иемет место быть, можно обращаться по индексам, можно вставлять/удалять по индексам Вполне реализуемый тип данных.

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

Оба варианта есть практически в любом высокоуровневом ЯП.

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

Так, алгоритм прихода к успеху становится немного яснее...

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

Да не взлетит, ибо всюду адское legacy :(

Впервые идея пришла в голову после знакомства с Mikrotik.

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

ну так видишь, с ростом GNU-экосистемы назревают перемены. Как страшен ни был бы systemd, а ставят люди, некоторым нравится даже. Если твою концепцию озвучивать на конференциях, то появится интерес и поддержка.

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

Демон не нужен:

- хотим править - ставим в свой каталог lock-файл, пишем в него свой PID и правим.
- хотим обновлений - подписываемся на inotify для своего каталога.
- если был создан и исчез lock-файл, или исчез процесс с соотв. PID(интересно, на /proc можно inotify делать или периодически проверять придётся) - перечитываем.

Всё это выносится в небольшую либу. Правка конфига - редкое событие. Ну в крайнем случае через shmem общаться можно. Демоны - нафиг. Сложность разворачивания/обслуживания сразу усложняется, появляется overhead.

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

Вот озвучил на передовом ресурсе по OpenSource :)

Сейчас времени на такое большое и глобальное, увы, нету.

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

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

ты думаешь реализовать sqlite, хотя в руках у тебя концепция SQL-движка вообще. Надеюсь, понятно?

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

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

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

Плейнтекстовые файлы - страшная сила в плане автоматизации и простоты. От них никогда не откажутся, и никакая система, не сводящаяся к ним, не приживётся.

Пойду спать, завтра вернусь в тред.

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

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

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