Извилины в мозгу сразу распутались и стали прямыми, как железная дорога Санкт-Петербург - Москва.
насколько я помню она со времен царя немного кривая
Центр управления для Linux
Модератор: Модераторы
[off]
насколько я помню она со времен царя немного кривая
насколько я помню она со времен царя немного кривая
B4rr4cuda писал(а):Т.е согласен с тем, что вшивать поиск конфигов в код модулей (не их конфигов, а именно библиотек) нецелесообразно?
это да. мне казалось что нужно нести вместе с модулем пути поиска конфигов. ну и конечно же это не должно быть вшито в испольняемую часть либы. и всегда нуцжно оставлять возможность пользователю указывать путь вручную.
ViTality писал(а):и всегда нуцжно оставлять возможность пользователю указывать путь вручную.
На счёт путей - это и так понятно. Обсуждалось вроде бы куда класть процедуру поиска - в специализированный модуль, который программист пишет для конфигурации устройства или программы или в центральный модуль, который управляет работой остальных модулей.
ev писал(а):насколько я помню она со времен царя немного кривая
Ну она может быть и кривая, но очень-очень немного, т.к. именно эта жд была выбрана в своё время для испытания скоростных пассажирских поездов у нас. Другой, более прямой, во всём Советском Союзе так и не нашли.
чудовищи 
вам же еще с 3-й страницы кто-то предложил идейку - на каждый дистрибутив свой уникальный модуль. Понятно что никто не будет ради того чтобы добавить поддержку настройки какого-нить мелкого демона перелопачивать модули всех дистрибутивов, но никто же не заставляет вас делать все модули одинакового типа... выделить 2 уровня - один специфичный для дистрибутива и реализующий некую стандартную API (интерфейс одинаков для всех дистрибутивов, реализация ессно разная) - типа найти конфиг вот этого демона, вписать в него такую-то опцию итд итп... а второй уровень - уже от дистрибутива не зависящий и использующий этот API. Итого будет по 1 модулю на дистрибутив, а все остальные модули реализующие всякие разные фичи - кроссплатформенные (возможно даже бинарно совместимые) и работающие под любым дистрибутивом. Особые извращенцы могут довести уровень абстрагировани этого API до возможности работы модулей что под линухой, что под BSD что под вендами
(при наличии Дистрибутиво\OS-специфического модуля, реализующего API).
вам же еще с 3-й страницы кто-то предложил идейку - на каждый дистрибутив свой уникальный модуль. Понятно что никто не будет ради того чтобы добавить поддержку настройки какого-нить мелкого демона перелопачивать модули всех дистрибутивов, но никто же не заставляет вас делать все модули одинакового типа... выделить 2 уровня - один специфичный для дистрибутива и реализующий некую стандартную API (интерфейс одинаков для всех дистрибутивов, реализация ессно разная) - типа найти конфиг вот этого демона, вписать в него такую-то опцию итд итп... а второй уровень - уже от дистрибутива не зависящий и использующий этот API. Итого будет по 1 модулю на дистрибутив, а все остальные модули реализующие всякие разные фичи - кроссплатформенные (возможно даже бинарно совместимые) и работающие под любым дистрибутивом. Особые извращенцы могут довести уровень абстрагировани этого API до возможности работы модулей что под линухой, что под BSD что под вендами
(при наличии Дистрибутиво\OS-специфического модуля, реализующего API).
Опять 25.
alexs писал(а):Внесу свои 5 копеек. А может ещё дополнительно создать библиотеку в которой хранить пути конфигов в разрезе самых распространённых систем? и пополнять её централизовано?
Описанные выши модуль поиска конфов будет собирать данные - и давать возможность эти данные отправить разроаботчикам для включения в этут библиотеку.
Популярных дистров - штук 20, верси внутри дистра тоже не очень много. Инициативные люди будут сотрудничать.
а получается что это - самый разумный вариант.
Что нить навроде:
{hosts}
/etc
[*]
[какой-то еще конфиг]
/etc
/usr/etc
[*]
ну и т.д.
единственное, что смущает, так это то, что не каждый захочет иметь у себя на компе модуль собирающий информацию, хотя бы из соображений безопасности. Впрочем этот вопрос скользкий...так что поднимать его рано.
minoshi писал(а):единственное, что смущает, так это то, что не каждый захочет иметь у себя на компе модуль собирающий информацию, хотя бы из соображений безопасности. Впрочем этот вопрос скользкий...так что поднимать его рано.
А зачем его иметь пользователям? Выкладываешь его отдельно, каждый кто заинтересован - его выкачивает, запускает, отсылает тебе инфу по своему дистрибу. Исключительно на добровольной основе.
Только вот инфу предлагаю не в один конфиг пихать, а в разные - для каждого модуля свой.
В результате пользователь сможет выкачать нужные ему модули-плаги и конфиги для них (для ЦУ) под свой дистриб.
alexs писал(а):Внесу свои 5 копеек. А может ещё дополнительно создать библиотеку в которой хранить пути конфигов в разрезе самых распространённых систем? и пополнять её централизовано?
Описанные выши модуль поиска конфов будет собирать данные - и давать возможность эти данные отправить разроаботчикам для включения в этут библиотеку.
Популярных дистров - штук 20, верси внутри дистра тоже не очень много. Инициативные люди будут сотрудничать.
чтобы что-то собирать надо знать, что искать )
итак, места расположений каких конфигов будем собирать?
hosts
fstab
syslog
passwd
group
smb.conf
clamd.conf
pppoe.conf
что еще?
Думал я как-нибудь сделать свой мини-дистрибутив. Думал и над центром управления.
Вот что надумал.
1) Одно окно на подобие панели управления, с иконками по категориям. От иконок запускаются программы-настройщики (не библиотеки). В самом простом варианте можно запускать текстовый редактор с нужным конфигом. Какую программу-настройщик запускать пользователь, при желании, может переопределить сам. Можно сделать программы-настройщики по темам, например аля WindowsXP или аля MacOS.
2) Программа-настройщик состоит из трех регионов: секция, параметры со значениями, описание параметра (или текущей секции). В принципе, все извлекается из конфигов, нужно только привлекательно отобразить. Плюс расширить описание параметров. Теоретически, можно использовать схемы и файлы XML. В них можно хранить описание параметров, возможные значения, и где искать данный параметр.
3) Что если хранить настройки в каталогах LDAP сервера? Для разных дистрибутивов эти каталоги будут одинаковыми, и настраивать нужно будет только параметры в этих каталогах. Тогда для любого дистрибутива достаточно будет сделать утилиту-настройщих по миграции настроек в LDAP сервер, и это можно поручить сделать изготовителям дистра. Кстати, для большинства дистров рецепты по переводу настроек той же сети на LDAP сервер есть. И возможно, вскоре все дистрибутивы по умолчанию начнут хранить настройки на LDAP. Можно сделать легковесный, простенький LDAP сервер, если неохота ставить монстров типа OpenLDAP.
Вот что надумал.
1) Одно окно на подобие панели управления, с иконками по категориям. От иконок запускаются программы-настройщики (не библиотеки). В самом простом варианте можно запускать текстовый редактор с нужным конфигом. Какую программу-настройщик запускать пользователь, при желании, может переопределить сам. Можно сделать программы-настройщики по темам, например аля WindowsXP или аля MacOS.
2) Программа-настройщик состоит из трех регионов: секция, параметры со значениями, описание параметра (или текущей секции). В принципе, все извлекается из конфигов, нужно только привлекательно отобразить. Плюс расширить описание параметров. Теоретически, можно использовать схемы и файлы XML. В них можно хранить описание параметров, возможные значения, и где искать данный параметр.
3) Что если хранить настройки в каталогах LDAP сервера? Для разных дистрибутивов эти каталоги будут одинаковыми, и настраивать нужно будет только параметры в этих каталогах. Тогда для любого дистрибутива достаточно будет сделать утилиту-настройщих по миграции настроек в LDAP сервер, и это можно поручить сделать изготовителям дистра. Кстати, для большинства дистров рецепты по переводу настроек той же сети на LDAP сервер есть. И возможно, вскоре все дистрибутивы по умолчанию начнут хранить настройки на LDAP. Можно сделать легковесный, простенький LDAP сервер, если неохота ставить монстров типа OpenLDAP.