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)
Ответ на: комментарий от val-amart

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

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

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

Потому что это инструменты для редактирования текста произвольной структуры. А всякие xml/json/yaml прекрасно разбираются и редактируются с помощью lxml, simplejson и т. д.

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

Есть еще несколько моментов:
1. Визуальный шум/человекочитаемость. В нынешних конфигах шума мало, читаемость высокая. В приведенных мною строках сквида нет ни одного мусорного символа, при этом есть отлично читаемый и отформатированный столбец данных
2. Высокая плотность информации - у части программ (тотже ssh/d) vi покажет весь конфиг целиком. Тоже касается сохраненного iptables/ipfw и любых табличных конфигов. При этом параметры можно сразу править, у вас не факт, что можно будет организовать аналог journalctl, но в любом случае, править то его вывод не получится.
3. Нынешние конфиги человекоориентированны, ваш создается для программ - зарплату тоже программы получать будут ? Нафиг такое счастье, вы же без работы и останетесь.
4. Нынешний формат позволяет использовать возможности vi/sed для массовой/сложной замены - это приближает conf к sql. Возможность растет органично - более сложная модификация доступна более продвинутому админу, начинающему хватает ручками модифицировать пару опций. Реализовать массовый апдейт в вашем варианте можно - придется запихнуть половину sed'а(sql?) к вам в cli. Сложность cli будет стремительно расти, а результат массовых замен контролировать будет сложно. Вводить транзакционный механизм ? Сейчас и это решается - запорол конфиг - выйди через q!
5. Сейчас конфиг - для админа, вы делаете скорее для программера, но админят - админы. Сложностей в совмещении разного ПО и так хватает, сложные структуры конфигов там где это не надо, только добавляют проблем. А вы решаете надуманную.
6. Ваш формат требует довольно сложного парсера конфига. Нафига он ssh с его 20 параметрами ? Вынести парсер в отдельную либу ? И получить потенциальный конфликт версий и потенциальную дыру (очередное переполнение при чтении мусора любой) во всех программах ей использующих ? 7.легаси/совместимость. Имеем, проблем не доставляет. Вы его хотите сломать. Вы размер очереди желающих придушить за одну только мысль о таком себе представляете ? 8.работает не трожь - опять мимо Итого, всеобщий конфиг всего: а) есть в виндах и пользоваться им через reg не реально, все используют регедит, мы используем vim
б) не дает абсолютно никакого профита (редактировать из другого ПО и сейчас его можно и это очень узкая задача и решается она очень просто)
в) не везде применим, не особо нужен, при этом усложняет все (=!KISS)
г) все ломает и нереализуемо.

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

1. Я пока не предложил формат. Просто хочу, чтобы он был один для всех. Разумеется, он должен быть человекочитаемым
2. «Высокая плотность информации - vi покажет весь конфиг целиком - сохраненного iptables/ipfw»
Да ладно, не бывает что ли конфигов iptables на десяок страниц?
3. Обязательно человекочитаемый
4. Если формат один - сложность редактирования дерева значений не сложнее работы в каком-нибудь питоне или руби с данными типа «хеш хешей»
5. Я админ, хочу для себя
6. " потенциальную дыру " - от потенциальных дыр как раз избавляются, используя одну либу во многих программах и тщательно её вылизывая. Когда у каждого своя читалка конфигов, дыр больше
7,8 Да, legacy - проблема

а) В винде:
- программа может писать в любую ветку
- нет комментов к записям
Поэтому срач.
б) Даёт, и большой. Единообразие позволит экономить много сил и человеко-часов. Можно будет отредактировать какой-то параметр на куче хостов, не заводя тяжёлую артиллерию вроде puppet/ansible. Если для sshd конфиг grep/sed отредактировать можно, хотя комменты наверняка собьются, то редактирование конфига nginx или apache - задача на порядок сложнее, требуется синтаксический разбор.
в) один формат текстового конфига для всех программ и есть KISS
г) да, знаю, не взлетит, поэтому тред помечен тегом «нытьё»

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

[онтопик][навыворот]Вспомнил!

Я пока не предложил формат

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

Можно определить универсальный формат сохранения «символьной» информации в максимально «деревянном» виде (типа TypeLengthValue, например). Мы бы ушли от посредничества сложных языков, оставив их для устаревающих «бумажных» технологий. Можно объявить эту хрень «текстом v2.0», написать для неё «деревянный редактор»(для vim-еров должно быть так же удобно, остальным - не знаю), аналоги всяких грепов-седов и т.п.

Конверторы «в/из» олдскульных синтаксисов - довольно тривиальное дополнение, позволящее не заботиться о совместимости. Синтаксические ошибки (вероятно) перестали бы существовать. Флеймы по поводу «отступов/скобок» тоже - каждый бы работал с приятным ему отображением... Сплошные бонусы, IMНO.

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

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

DonkeyHot ★★★★★
()
Ответ на: [онтопик][навыворот]Вспомнил! от DonkeyHot

«текст», как универсальный способ выражения всего, сильно устарел

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

объявить эту хрень «текстом v2.0», написать для неё «деревянный редактор»(для vim-еров должно быть так же удобно, остальным - не знаю), аналоги всяких грепов-седов

На такие глобальные вещи я не замахиваюсь, только на конфиги, но общая идея такая, да.

XML зло
но идея «универсального дерева» не даёт уроду умереть.

Ага, именно так

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

>про связь речи и мышления

Я не замахивался на новые способы мыслить;) Просто «речь» бывает разная. Пока нам не обязательно передавать мысли между человеками непосредственно, кодирование в/из язык, приемлемый для «ушей/глаз», не нужно и избыточно. Это всегда можно сделать перед самым «вводом в человека». Т.е. мы не избавляемся от языка, мы заменяем язык более простым, избавленным от механизмов устранения проблем общения человек<->человек, отсутствующие при общении человек<->машина. И наоборот, учитывающим проблемы последнего. Поскольку всё большая часть общения производится через компы, общий счёт - в пользу этой идеи.

DonkeyHot ★★★★★
()
Ответ на: >про связь речи и мышления от DonkeyHot

сделать перед самым «вводом в человека»

Та бурда, которую выдаёт твоё подсознание, и та, которую принимает на вход моё, совершенно не совместимы. Без промежуточного уровня трансляции никак.

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

совершенно не совместимы

Извини. Это означало: преобразовывать в человекочитаемый формат стоит лишь тогда, когда это необходимо - например, перед печатью на бумаге (если кому-то зачем-то понадобится). Вот, скажем, конфиг: читается, в основном, роботами - им человекочитаемый язык только мешает; изображается/пишется/правится «специальными» программами - опять «читаемость» языка не очень важна(опыт явы подтверждает). Итог: конкретный язык не нужен почти никогда, достаточно абстрактного «дерева».

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

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

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

Конфиг читается мной

Но предварительно некая программа преобразовывает его в удобный для тебя вид. Из какого формата она будет это делать малосущественно. Однако, некоторые форматы позволяют писать программы легко, некоторые - сложно. Топик возник от того, что нынешние текстовые форматы делают это сложным (нужно много разнообразных или сложных парсеров). А нетекстовые - неудобным для человека или негибким. Моё предложение позволяет(*) избавиться от обоих недостатков - конфиг может быть любой сложности, при этом легко читается и преобразовывается в «удобные» форматы. Но требует изменения интерфейса текстового редактора. Последнее требует изменения привычек, т.ч. может не приниматься обществом.

(*)?ли. если интерфейс «новотекстового» редактора окажется слишком сложным для человека, дело не выгорит. Пока глубоуо не обдумывался.

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

Если получится сделать «удобные форматы» для человека, зачем потом их компилировать в бинарный вид? Пусть парсит сразу из человекопонятного. Бинарное представление -лишняя сущность

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

Вообще есть же еще вполне годный подход «конфигурирование через cli». Дает одмину счастливую возможность забить на синтаксис конфига полностью, а софту - возможность хранить этот конфиг в программно-читаемом виде где угодно, хоть блобом в sql, хоть в ldap, хоть в *ml.
Так что на обязательной человекочитаемости конфигов можно было бы не морочиться, если бы кодеры выработали более-менее единый стиль cli-конфигурирования своих поделий и не ленились бы поставлять утилитку для этого дела и писали бы без глюков, и срали радугой

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

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

Ну и остаются поднятые в топике проблемы для софтин, у которых часть конфига - скрипт на lua/perl/brainfuck/... Причём не в формате ключ-значение, а с логикой. Для них никак не получается

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

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

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

Зачем его убирать? Чем этот шаг логичен? С современными носителями и процессорами однократное считывание/парсинг конфига службой при запуске практически не заметны. Бинарный формат - абсолютно лишняя сущность. KISS и нефиг

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

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

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

б) Даёт, и большой. Единообразие позволит экономить много сил и человеко-часов.


А сейчас это чья работа ? :) Я и говорю тебя же и уволят.

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

До этого додумается следующий и ты его будешь разубеждать также как я тебя сейчас.

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

А сейчас это чья работа ? :) Я и говорю тебя же и уволят

:) Если окажется, я работаю только из-за искуственно повышенной сложности испольуемого софта - пусть увольняют. Я свою работу несколько по-другому вижу.

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

Разделы помощи man. Смотри man man, в начале DESCRIPTION описано. Плюс по каждой из секций можно получить описание с помощью man <num> intro

selivan ★★★
() автор топика

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

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

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

На треде стоит тег «нытьё». Не взлетит из-за legacy, увы. Ну вот прихожу я к apache web server, nginx, squid, mysql, postgresql, keepalived и говорю: «Ребята, я сделал новый клёвый формат конфигов, один для всех и удобный, одна либа, одно cli. Даже осилил написать всем вам патчи для его включения». А они мне говорят: «Друг, да ты ****улся. У нас пользовательская база в много миллионов инстралляций, и всё завязано на существующий формат конфигов. И куча сторонних инструментов на него завязаны. Мы ничего менять не станем». А идею обсудить хочется

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

удобные форматы» для человека ... зачем потом их компилировать в бинарный вид

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

Т.о. имеем минимум 4 формата: «клавиатурный», «экранный», «хранимый», «обрабатываемый». Вопрос в том, какой смысл «отдалять» 2 последних. Очевидно, никакого, кроме наследия в виде инструментов/привычех обработки какого-то пятого. Действительно, лишнего.

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

Ну кагбэ человечество изобрело письменность много тысяч лет назад не просто так. Это вполне себе удобный формат и вывода(да, с промежуточным представлением в виде плоского изображения/точек шрифта Брайля/звуковых сигналов), и ввода - клавиатура заточена как раз под текст. Так что «хранимый» и «обрабатываемый» действительно разделять смысла нет - всё есть текст.

selivan ★★★
() автор топика

На конфиг opensips уже предлагали посмотреть?)

Я думаю не прижился потому, что не нужен. sed-а/grep-а обычно хватает.

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

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

Если бы формат конфигов был один, упростилось бы в том числе использование sed/grep для его правки - сделал один раз чуть более обощённый велосипед и вперёд.

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

много тысяч лет назад не просто так

Аминь. «Письменность» изобрели для сохранения того, что произносится при единственных доступных устройствах для чтения(глаза) и записи(руки). В нынешних условиях все 3 условия устарели. Мы записываем далеко не то, что будем произносить, читаем и пишем с помощью разнообразных магнитных/полупроводниковых/етц. устройств => письменность тысячелетней давности ни разу не аргумент.

«хранимый» и «обрабатываемый» действительно разделять смысла нет - всё есть текст.

Я ещё не видел программы, которая обрабатывала бы конфиги прямо в «текстовом» виде - все сначала парсят в «понятные» структуры, и уже с ними работают.

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