Центр управления для Linux

[Brainenjii]

SUSE - YaST ^_^ Всё в одном месте и оч. функционально... Переплюнуть его будет непросто, ИМХО ^_^

[ViTality]

SUSE - YaST ^_^ Всё в одном месте и оч. функционально...

да но под гномом такой, под КДЕ другой...

[Vadim]

да но под гномом такой, под КДЕ другой...

А под консолью - третий. Причём управлять yast'ом в консоле неудобно. А на сервер ни KDE, ни гном ставить не хочу...

[B4rr4cuda]

А других дистрибах yast-a вообще нет
Думаю что универсальный ЦУ будет востребован в любом случае.

[ViTality]

так никто и не говорит, что не будет востребован.
Я о том что Yast в Suse сам на себя не похож под разными граф.интерфейсами (гномовский, очень сильно не дотягивает до кде`шного).
А тут какраз будет единообразие под всеми.

Насчет модулей для различных "линуксов" и их версий, думаю вполне нормально будет сделать так:
1 модуль(или скорее блок модулей) - на 1 дистрибутив.

1.Система
2.Оборудование
3.Точки монтирования
4.Сеть
5.Загрузка
6.Управление пакетами
7.Прочие центры управления // а почему нет )

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

[Vadim]

Дистрибутивы:
1. SUSE
...9.x
......Система
......Оборудование
......Точки монтирования
......
...10.x
......
...11.x
......
2. Debian
...3.x
...4.x
3. Ubuntu
...

[B4rr4cuda]

1 модуль(или скорее блок модулей) - на 1 дистрибутив.

Предположим, что какой-то чел обнаружил этот ЦУ и решил написать модуль для настройки чего нить, того же squid-а например. Я сильно сомневаюсь, что он будет подстраивать его под все дистрибы. Конечно, можно предоставлять пользователю возможность указывать пути вручную, но это такой гемор будет, что юзверь забьет на прогу. Предположим, что другой чел решил создать "блок модулей" для своего дистриба. Он берет этот squid-модуль и начинает подгонять его под свой дистриб. Ещё один чел собирает под свой дистриб - опять поиск и подгон.
Очень много лишних движений...

Что я предлагаю: сам ЦУ, по запросу модуля, предоставляет путь к конфигу.
А вот, как он это сделает - тут уже много вариантов:
1) Модули для поиска путей:
-размер
-разрастание
-немодифицируеммость
-некоторая статичность и бестолковость

2) Скрипты для поиска путей:
+небольшой размер

3) Конфиг(и) с базой путей:
+небольшой размер
-статичность

На мой взгляд оптимальные варианты 2 и 3.
Скриптовые языки встраиваются в прогу очень легко (PascalScript,Lua,Perl и тд) сами скрипты небольшие. Легко модифицируются и распространяются. Можно даже на модуль держать по одному скрипту, который по имени дистра будет выдавать путь. Или, что ещё лучше - по запросу, проводят поиск, выполняют необходимые команды (whereis squid и парсинг полученой строки)....

Третий вариант с конфигом тоже неплох - легко модифицируется. Минус - нарастание обьема и вследствие этого трудность модификации и распространения.

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

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

Да и вряд-ли один прогер будет писать все конфигураторы под свой дистриб...
Поэтому - "разделяй и властвуй" и никак иначе...

[Vadim]

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

[B4rr4cuda]

По-моему проще будет сделать скрипт (или процедуру), которая обегает каталоги конфигурации (благо их немного) и составляет список файлов конфигурации с их путями.

А если файлика нет и его нужно создавать? (/etc/wvdial.conf,~/.gtkrc,~/.vim /etc/rc.d/rc.firewall....)

А вообще, самым четким вариантом было бы комплексное решение: проца обега каталогов +базовый конфиг, дополняемый при установке модуля+скрипты+ручное указание путей гуем(если ничего не помогло).

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

[Vadim]

А если файлика нет и его нужно создавать?

Если файлика нет, то скорее всего отсутствует и сама фиговина, которую конфигурирует данный файл.

[B4rr4cuda]

Или фиговина ещё не инициализирована. Я не зря привел примеры...

[Vadim]

Или фиговина ещё не инициализирована.

Вполне возможно. Тут как раз и нужен рукоблудный режим.

[ViTality]

Предположим, что какой-то чел обнаружил этот ЦУ и решил написать модуль для настройки чего нить, того же squid-а например. Я сильно сомневаюсь, что он будет подстраивать его под все дистрибы.

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

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

разраб модуля должен будет указасть дистр и его версию, для которого написан модуль.

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

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

Наверное всетаки в отношении таких прог как сквид, нужно делать иначе.
Модуль для программы(тотже сквид). а в нем уже указывается какие дистрибутивЫ и их версии поддерживаются.

Добавлено спустя 9 минут 42 секунды:
Наверно придется предусмотреть 2 вида модулей.
Системные и программные.
Системные зависят чиста от специфики дистрибутива.Я думаю в этот раздел уйдут пункты с 1 по 6 перечисленные Vadim.
В них все зависит от дистра и его версии.
А программные это какраз 7 пункт.(там и буду всякие сквиды).
А тут ужеуказываются поддерживаемые:
- версии проги
- дистры и их версии

[B4rr4cuda]

рукоблудный режим

Бугога! Пошло приходит на ум "спящий режим" и "ждущий режим".

во всех модулях естественно должна быть информация о дистрибутиве и поддерживаемых версиях этого дистра.

Ага, предположим поддерживается Slackware. А у нас Мопс, Волк или подобный, который мало чем отличается по структуре расположения конфигов. Мы ставим модуль, он проверяет дистриб и грозит нам пальчиком. А насчет

его никто не заставляет.

то кто кроме разработчика может быстро и адекватно подстроить творение к ситуации?
Это, естественно, если поиск конфигов вшит в код. Если же мы выносим поиск из модулей, то любой ознакомившийся с документацией, сможет в разумный срок выполнить адаптацию к дистрибу. И разраба не будут заморачивать с вопросами: "А почему у меня ничего не работает???"

разраб модуля должен будет указасть дистр и его версию, для которого написан модуль.

А пользователи остальных дистрибов будут сосать лапу? Особенно обидно будет пользователям младшей\старшей версии дистриба, где файло переместили...
Я за универсальность. Иначе теряется вся привлекательность этого ЦУ. Ещё один дистрибозависимый клон Yast/drake/etc будет просто бесполезен.

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

Забавно. Т.е. чтобы заточить модуль под свой дистриб, пользователь должен выкачать fpc+lazarus+настроить их+освоить паскаль+освоиться в коде модуля+переписать часть кода+создать пакет под свой дистриб. (или аналогичные операции под другие ЯП)
"И Ви таки думаете оно получиться? "©
Вряд ли кто-то будет заморачиваться с таким адским гемором.

Наверное всетаки в отношении таких прог как сквид, нужно делать иначе.
Модуль для программы(тотже сквид). а в нем уже указывается какие дистрибутивЫ и их версии поддерживаются.

Ну да, три-пять десятков разных дистрибов, а учитывая разные версии - пара сотен это конечно для одного разраба раз плюнуть...
Вы серьезно считаете это адекватным решением???

Системные зависят чиста от специфики дистрибутива.Я думаю в этот раздел уйдут пункты с 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.Прочие центры управления // а почему нет )
Всякие пользовательские приложения.

[ev]

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

я думаю имелось ввиду настроить пути в конфигах