1) Одно окно на подобие панели управления, с иконками по категориям. От иконок запускаются программы-настройщики (не библиотеки). В самом простом варианте можно запускать текстовый редактор с нужным конфигом. Какую программу-настройщик запускать пользователь, при желании, может переопределить сам. Можно сделать программы-настройщики по темам, например аля WindowsXP или аля MacOS.
2) Программа-настройщик состоит из трех регионов: секция, параметры со значениями, описание параметра (или текущей секции). В принципе, все извлекается из конфигов, нужно только привлекательно отобразить. Плюс расширить описание параметров. Теоретически, можно использовать схемы и файлы XML. В них можно хранить описание параметров, возможные значения, и где искать данный параметр.
3) Что если хранить настройки в каталогах LDAP сервера? Для разных дистрибутивов эти каталоги будут одинаковыми, и настраивать нужно будет только параметры в этих каталогах. Тогда для любого дистрибутива достаточно будет сделать утилиту-настройщих по миграции настроек в LDAP сервер, и это можно поручить сделать изготовителям дистра. Кстати, для большинства дистров рецепты по переводу настроек той же сети на LDAP сервер есть. И возможно, вскоре все дистрибутивы по умолчанию начнут хранить настройки на LDAP. Можно сделать легковесный, простенький LDAP сервер, если неохота ставить монстров типа OpenLDAP.
Статистика: Добавлено Alek_Aaz — 25.07.2008 08:14:40
]]>
alexs писал(а):Внесу свои 5 копеек. А может ещё дополнительно создать библиотеку в которой хранить пути конфигов в разрезе самых распространённых систем? и пополнять её централизовано?
Описанные выши модуль поиска конфов будет собирать данные - и давать возможность эти данные отправить разроаботчикам для включения в этут библиотеку.
Популярных дистров - штук 20, верси внутри дистра тоже не очень много. Инициативные люди будут сотрудничать.
Описанные выши модуль поиска конфов будет собирать данные - и давать возможность эти данные отправить разроаботчикам для включения в этут библиотеку.
Популярных дистров - штук 20, верси внутри дистра тоже не очень много. Инициативные люди будут сотрудничать.
чтобы что-то собирать надо знать, что искать )
итак, места расположений каких конфигов будем собирать?
hosts
fstab
syslog
passwd
group
smb.conf
clamd.conf
pppoe.conf
что еще?
Статистика: Добавлено minoshi — 22.07.2008 20:47:09
]]>
minoshi писал(а):единственное, что смущает, так это то, что не каждый захочет иметь у себя на компе модуль собирающий информацию, хотя бы из соображений безопасности. Впрочем этот вопрос скользкий...так что поднимать его рано.
А зачем его иметь пользователям? Выкладываешь его отдельно, каждый кто заинтересован - его выкачивает, запускает, отсылает тебе инфу по своему дистрибу. Исключительно на добровольной основе.
Только вот инфу предлагаю не в один конфиг пихать, а в разные - для каждого модуля свой.
В результате пользователь сможет выкачать нужные ему модули-плаги и конфиги для них (для ЦУ) под свой дистриб.
Статистика: Добавлено B4rr4cuda — 05.07.2008 22:49:25
]]>
alexs писал(а):Внесу свои 5 копеек. А может ещё дополнительно создать библиотеку в которой хранить пути конфигов в разрезе самых распространённых систем? и пополнять её централизовано?
Описанные выши модуль поиска конфов будет собирать данные - и давать возможность эти данные отправить разроаботчикам для включения в этут библиотеку.
Популярных дистров - штук 20, верси внутри дистра тоже не очень много. Инициативные люди будут сотрудничать.
Описанные выши модуль поиска конфов будет собирать данные - и давать возможность эти данные отправить разроаботчикам для включения в этут библиотеку.
Популярных дистров - штук 20, верси внутри дистра тоже не очень много. Инициативные люди будут сотрудничать.
а получается что это - самый разумный вариант.
Что нить навроде:
{hosts}
/etc
[*]
[какой-то еще конфиг]
/etc
/usr/etc
[*]
ну и т.д.
единственное, что смущает, так это то, что не каждый захочет иметь у себя на компе модуль собирающий информацию, хотя бы из соображений безопасности. Впрочем этот вопрос скользкий...так что поднимать его рано.
Статистика: Добавлено minoshi — 05.07.2008 22:05:58
]]>
]]>
вам же еще с 3-й страницы кто-то предложил идейку - на каждый дистрибутив свой уникальный модуль. Понятно что никто не будет ради того чтобы добавить поддержку настройки какого-нить мелкого демона перелопачивать модули всех дистрибутивов, но никто же не заставляет вас делать все модули одинакового типа... выделить 2 уровня - один специфичный для дистрибутива и реализующий некую стандартную API (интерфейс одинаков для всех дистрибутивов, реализация ессно разная) - типа найти конфиг вот этого демона, вписать в него такую-то опцию итд итп... а второй уровень - уже от дистрибутива не зависящий и использующий этот API. Итого будет по 1 модулю на дистрибутив, а все остальные модули реализующие всякие разные фичи - кроссплатформенные (возможно даже бинарно совместимые) и работающие под любым дистрибутивом. Особые извращенцы могут довести уровень абстрагировани этого API до возможности работы модулей что под линухой, что под BSD что под вендами
(при наличии Дистрибутиво\OS-специфического модуля, реализующего API).Статистика: Добавлено Sagrer — 30.06.2008 18:15:33
]]>
ViTality писал(а):и всегда нуцжно оставлять возможность пользователю указывать путь вручную.
На счёт путей - это и так понятно. Обсуждалось вроде бы куда класть процедуру поиска - в специализированный модуль, который программист пишет для конфигурации устройства или программы или в центральный модуль, который управляет работой остальных модулей.
ev писал(а):насколько я помню она со времен царя немного кривая
Ну она может быть и кривая, но очень-очень немного, т.к. именно эта жд была выбрана в своё время для испытания скоростных пассажирских поездов у нас. Другой, более прямой, во всём Советском Союзе так и не нашли.
Статистика: Добавлено Vadim — 30.06.2008 09:33:13
]]>
B4rr4cuda писал(а):Т.е согласен с тем, что вшивать поиск конфигов в код модулей (не их конфигов, а именно библиотек) нецелесообразно?
это да. мне казалось что нужно нести вместе с модулем пути поиска конфигов. ну и конечно же это не должно быть вшито в испольняемую часть либы. и всегда нуцжно оставлять возможность пользователю указывать путь вручную.
Статистика: Добавлено ViTality — 30.06.2008 09:15:19
]]>
Извилины в мозгу сразу распутались и стали прямыми, как железная дорога Санкт-Петербург - Москва.
насколько я помню она со времен царя немного кривая
Статистика: Добавлено ev — 30.06.2008 09:14:27
]]>
alexs писал(а):Библиотека файлов - кофигов.
О! Вот это другое дело. Извилины в мозгу сразу распутались и стали прямыми, как железная дорога Санкт-Петербург - Москва. Теперь всё понятно.
Статистика: Добавлено Vadim — 30.06.2008 08:39:31
]]>
Vadim писал(а):Я привык, что "библиотека" - это *.so или *.dll.
Библиотека файлов - кофигов.
И ещё - многие конфигурируемые параметры можно вынести также в текстовые файлы - т.е. реализовать файл описания структуры параметра (тип параметра, приложение где он используется, обязательность парамтера, описание параметра) - а уж морда конфигурилки будет собирать по этим файлам интерфес.
Статистика: Добавлено alexs — 30.06.2008 08:27:02
]]>
alexs писал(а):фактически да - только с указанием дистра.
Тогда зачем этот текстовый файл звать "библиотека"?
От этого путаница (по крайней мере у меня в голове).
Я привык, что "библиотека" - это *.so или *.dll.Статистика: Добавлено Vadim — 30.06.2008 08:14:43
]]>
ещё - если делить конфигураторы по модульно по принципу конфигурирования частей или приложений - то эту библиотеку вести также в разрезе этих модулей.
Статистика: Добавлено alexs — 29.06.2008 22:53:54
]]>
alexs писал(а):Внесу свои 5 копеек. А может ещё дополнительно создать библиотеку в которой хранить пути конфигов в разрезе самых распространённых систем? и пополнять её централизовано?
Описанные выши модуль поиска конфов будет собирать данные - и давать возможность эти данные отправить разроаботчикам для включения в этут библиотеку.
Популярных дистров - штук 20, верси внутри дистра тоже не очень много. Инициативные люди будут сотрудничать.
Описанные выши модуль поиска конфов будет собирать данные - и давать возможность эти данные отправить разроаботчикам для включения в этут библиотеку.
Популярных дистров - штук 20, верси внутри дистра тоже не очень много. Инициативные люди будут сотрудничать.
добавь еще одну копейку :) - а формат библиотеки? текстовый файл со списком путей?
Статистика: Добавлено minoshi — 29.06.2008 22:18:08
]]>
Популярных дистров - штук 20, верси внутри дистра тоже не очень много. Инициативные люди будут сотрудничать.
Статистика: Добавлено alexs — 29.06.2008 21:40:22
]]>
FedeX писал(а):...и чего вы тут треплетесь, флудеры) Аффтар вроде ужо давно на это забил
Не результат важен, а процесс! :lol: Да и "аффтар" вроде как не постоялец, а так - заглядывает иногда. Так что думаю заглянет и почитает наши "потоки сознания"... :wink:
и читаю с БОЛЬШИМ вниманием
ОК, сделаем так. Вместе с ЦУ будет библиотека, реализующая поиск конфигурационного файла (назовем его getinfo.so - название универсальное, т.к. возможно нам в будущем потребуется еще каки-нить функции, все они лягут сюда). Поиск будет предусматривать поиск по двум схемам - назовем их классический и полный. В классическом - поиск будет идти только по определенным папкам (/etc, usr/etc - список в разработке). В папках mnt, sbin, bin, media и т.п. искать конфиги нет смысла - т.к. в них согласно логике linux конфиги быть не должны (по крайней мере так пишут авторы книг о линуксе).
Полный поиск соответственно прочешет весь диск. Что будет разработчик модуля делать с результатом поиска -хранить его в инишке, xml или не хранить его вообще - дело самого разработчика. Впрочем он может им вообще не пользоваться :)
Статистика: Добавлено minoshi — 29.06.2008 17:57:44
]]>
Vadim писал(а):В принципе сама процедура поиска может (или даже должна) быть одной для всех (т.к. она будет применяться для любого подключаемого модуля настройки), ей надо только в качестве параметра передавать название конфигурационного файла. А сами пути хранить в инишнике (или xml-шнике ), чтобы, если кто хочет, не заморачиваться вызовом процедуры, а прописать путь ручками.
), чтобы, если кто хочет, не заморачиваться вызовом процедуры, а прописать путь ручками.Ну а я о чем талдычу уже вторую страницу? Вынести поиск из модуля!
B4rr4cuda писал(а):Что я предлагаю: сам ЦУ, по запросу модуля, предоставляет путь к конфигу.
А вот, как он это сделает - тут уже много вариантов:....
Скрипты, предоставляемые модулем, тоже должны исполняться в ЦУ, а не модулями или standalone. По команде из скрипта, когда путь к конфигу уже найден, ЦУ вызывает из модуля заранее определенную процедуру с путем в качестве параметра. Фактически скрипты будут выполнять функции этой, вынесенной в отдельную либу, процедуры поиска, только более универсально.
FedeX писал(а):...и чего вы тут треплетесь, флудеры) Аффтар вроде ужо давно на это забил
Не результат важен, а процесс!
Да и "аффтар" вроде как не постоялец, а так - заглядывает иногда. Так что думаю заглянет и почитает наши "потоки сознания"... Статистика: Добавлено B4rr4cuda — 27.06.2008 18:00:46
]]>
Статистика: Добавлено FedeX — 27.06.2008 16:25:33
]]>
В принципе сама процедура поиска может (или даже должна) быть одной для всех (т.к. она будет применяться для любого подключаемого модуля настройки), ей надо только в качестве параметра передавать название конфигурационного файла. А сами пути хранить в инишнике (или xml-шнике
), чтобы, если кто хочет, не заморачиваться вызовом процедуры, а прописать путь ручками.Статистика: Добавлено Vadim — 27.06.2008 07:52:06
]]>
Да, для сложных случаев в модуле может быть собственный поиск, но используемый, как дополнительный и управляемый конфигом либо скриптами модуля.
Статистика: Добавлено B4rr4cuda — 27.06.2008 07:40:54
]]>
Целесообразно для настройки какой-либо выдающейся программы, например squid'а. Ведь, если здраво посмотреть, я squid то могу себе и не ставить, так что и конфигурировать его из основного модуля мне незачем. А вот если поставил, то подключаю модуль для его конфигурации и там уже должен быть поиск.
Статистика: Добавлено Vadim — 27.06.2008 05:59:12
]]>
]]>
яж нигде не говорил "1 модуль - 1 файл"
Статистика: Добавлено ViTality — 26.06.2008 13:14:41
]]>
ev писал(а):я думаю имелось ввиду настроить пути в конфигах
ViTality писал(а):. во всех модулях естественно должна быть информация о дистрибутиве и поддерживаемых версиях этого дистра.
ViTality писал(а):разраб модуля должен будет указасть дистр и его версию, для которого написан модуль.
Статистика: Добавлено B4rr4cuda — 26.06.2008 12:46:42
]]>
Т.е. чтобы заточить модуль под свой дистриб, пользователь должен выкачать fpc+lazarus+настроить их+освоить паскаль+освоиться в коде модуля+переписать часть кода+создать пакет под свой дистриб.
я думаю имелось ввиду настроить пути в конфигах
Статистика: Добавлено ev — 26.06.2008 12:43:14
]]>
Vadim писал(а):рукоблудный режим
Бугога!
Пошло приходит на ум "спящий режим" и "ждущий режим". ViTality писал(а):во всех модулях естественно должна быть информация о дистрибутиве и поддерживаемых версиях этого дистра.
Ага, предположим поддерживается Slackware. А у нас Мопс, Волк или подобный, который мало чем отличается по структуре расположения конфигов. Мы ставим модуль, он проверяет дистриб и грозит нам пальчиком. А насчет
ViTality писал(а):его никто не заставляет.
то кто кроме разработчика может быстро и адекватно подстроить творение к ситуации?
Это, естественно, если поиск конфигов вшит в код. Если же мы выносим поиск из модулей, то любой ознакомившийся с документацией, сможет в разумный срок выполнить адаптацию к дистрибу. И разраба не будут заморачивать с вопросами: "А почему у меня ничего не работает???"
ViTality писал(а):разраб модуля должен будет указасть дистр и его версию, для которого написан модуль.
А пользователи остальных дистрибов будут сосать лапу? Особенно обидно будет пользователям младшей\старшей версии дистриба, где файло переместили...
Я за универсальность. Иначе теряется вся привлекательность этого ЦУ. Ещё один дистрибозависимый клон Yast/drake/etc будет просто бесполезен.
ViTality писал(а):какие лишние движения? в чем тут проблема? помоему это обычная практика - если не хочешь/не можешь написать модуль сам, берешь чужой и затачиваешь его под свои нужды(дистрибутив)
Забавно. Т.е. чтобы заточить модуль под свой дистриб, пользователь должен выкачать fpc+lazarus+настроить их+освоить паскаль+освоиться в коде модуля+переписать часть кода+создать пакет под свой дистриб. (или аналогичные операции под другие ЯП)
"И Ви таки думаете оно получиться? "©
Вряд ли кто-то будет заморачиваться с таким адским гемором.
ViTality писал(а):Наверное всетаки в отношении таких прог как сквид, нужно делать иначе.
Модуль для программы(тотже сквид). а в нем уже указывается какие дистрибутивЫ и их версии поддерживаются.
Ну да, три-пять десятков разных дистрибов, а учитывая разные версии - пара сотен это конечно для одного разраба раз плюнуть...
Вы серьезно считаете это адекватным решением???
ViTality писал(а):Системные зависят чиста от специфики дистрибутива.Я думаю в этот раздел уйдут пункты с 1 по 6 перечисленные Vadim.
В них все зависит от дистра и его версии.
А программные это какраз 7 пункт.(там и буду всякие сквиды).
А тут ужеуказываются поддерживаемые:
- версии проги
- дистры и их версии
А я считаю совсем наоборот. Специфичны для дистрибов:
менеджеры пакетов, частично оборудование, частично сеть, может что ещё...
Всё остальное - программные модули:
1.Система
иксы, гуёвые фреймворки, ядерная фигня и прочее
находятся парсом выводов команд, файлов (/etc/ld.so.conf /proc/1/maps и тд)
2. Оборудование
/dev, /proc, /var/log, /etc
3.Точки монтирования
/etc/fstab, /etc/mtab, /proc/mounts, можно вывод mount отпарсерить и тд
4.Сеть
сквид, апач, файрволы, самба и прочие сервера и демоны которые могут быть и в /opt установлены, так что от "специфики дистриба" мало зависят.
5.Загрузка
Ну тут пути - либо /boot/... либо /etc/... в зависимости от lilo, grub или чего-нить "на любителя"...
6. Управление пакетами
Я на слаку как-то ставил emerde - порт emerge. Стало быть модуль для дженты, должен будет меня послать (расположение конфигов emerde - аналогично emege)?
7.Прочие центры управления // а почему нет )
Всякие пользовательские приложения.
Статистика: Добавлено B4rr4cuda — 26.06.2008 11:51:04
]]>
Предположим, что какой-то чел обнаружил этот ЦУ и решил написать модуль для настройки чего нить, того же squid-а например. Я сильно сомневаюсь, что он будет подстраивать его под все дистрибы.
его никто не заставляет. во всех модулях естественно должна быть информация о дистрибутиве и поддерживаемых версиях этого дистра.
Конечно, можно предоставлять пользователю возможность указывать пути вручную, но это такой гемор будет, что юзверь забьет на прогу.
разраб модуля должен будет указасть дистр и его версию, для которого написан модуль.
какие лишние движения? в чем тут проблема? помоему это обычная практика - если не хочешь/не можешь написать модуль сам, берешь чужой и затачиваешь его под свои нужды(дистрибутив)Предположим, что другой чел решил создать "блок модулей" для своего дистриба. Он берет этот squid-модуль и начинает подгонять его под свой дистриб. Ещё один чел собирает под свой дистриб - опять поиск и подгон.
Очень много лишних движений...
Наверное всетаки в отношении таких прог как сквид, нужно делать иначе.
Модуль для программы(тотже сквид). а в нем уже указывается какие дистрибутивЫ и их версии поддерживаются.
Добавлено спустя 9 минут 42 секунды:
Наверно придется предусмотреть 2 вида модулей.
Системные и программные.
Системные зависят чиста от специфики дистрибутива.Я думаю в этот раздел уйдут пункты с 1 по 6 перечисленные Vadim.
В них все зависит от дистра и его версии.
А программные это какраз 7 пункт.(там и буду всякие сквиды).
А тут ужеуказываются поддерживаемые:
- версии проги
- дистры и их версии
Статистика: Добавлено ViTality — 26.06.2008 10:09:18
]]>
B4rr4cuda писал(а):Или фиговина ещё не инициализирована.
Вполне возможно. Тут как раз и нужен рукоблудный режим.
Статистика: Добавлено Vadim — 26.06.2008 09:20:40
]]>
]]>
B4rr4cuda писал(а):А если файлика нет и его нужно создавать?
Если файлика нет, то скорее всего отсутствует и сама фиговина, которую конфигурирует данный файл.
Статистика: Добавлено Vadim — 26.06.2008 06:16:42
]]>