Различия между версиями 2 и 3
Версия 2 от 2008-07-04 21:27:01
Размер: 9640
Редактор: PavelSutyrin
Комментарий:
Версия 3 от 2008-07-04 23:58:01
Размер: 9655
Редактор: PavelSutyrin
Комментарий:
Удаления помечены так. Добавления помечены так.
Строка 30: Строка 30:
|| 0 || 1 || 1 || 1 || || 1 || PavelSutyrin (расшифровка pending), DmitryChistikov || || || || 0 || 1 || 1 || 1 || || 1 || PavelSutyrin (расшифровка завершается), DmitryChistikov || || ||

Использование конфигураторов: продолжение

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

Третья проблема, которая на самом деле является проекцие первых двух. Проблема синхр. имён. Пример: Один раз ввожу ip-адрес, второй раз ввожу, и так далее. Если введу один и тот же, то уже раздражает, а если ошибусь и поменяется ip-адрес, то совсем плохо. Проблема именования пересекается с проблемой общих неймспейсов.

Есть помимо недостатков и достоинства. Дст. состит в следующем: блее или менее один такой модуль сопровождать легко, то есть следить за обновлением служб, которые он конф., и обновлять при изменении. Особенно в случае, когда модуль завязан не на задачу, а на инструмент.

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

Другой вариант --- схема монолитная. На самом деле ещё хуже. Схема следующая: мы пшием одну большую программу, которая решает круг задач, и в каждой задаче будет модифиц. соотв. файлы. Типичный пример --- webmin. Дост. в двух вещах --- он делается в едином стиле и обычно в одной командой. Тем самым мы обеспечиваем прозрачность для пользователя. Это достоиство постепенно станвится legacy, и в какой-то момент надо менять всё, поскольку поменялось всё. Но такое происх. реже, потому что задачи меняются реже. Но такой конф. очень слжно разрабатывать. Например, поменялся синтаксис одного из 200 файлов, который настраивался конфигуратором. Тогда надо это отследить и всё попроавить. При этом понятно, что у разработчика должен быть навык и админа, и программиста. Поэтому подобные системы развиваются небыстро, и имет дост. количество разработчиков, которые заним. только этим.

Можно рассм. ещё один подход, трёхслойный. То есть, слой админстратора (у которого задачи), архитектора (конотрый решает, как это должно быть представлено) и дизайнера (который жизайнит гуй). Сразу о недостатках. Как это представляется: ... . Например, есть задача добавить пользователя в базу данных пользователей. Что это означает для оператора ЭВМ: есть некая база польз., оператор нажимает кнопку добавить пользователя, он указывает его credentials, и всё. Что это такое на уровне конфигов? Довольно нетр. задача. Есть passwd, тогда доб. в пассвд, а есть ещё самба, и туда тоже надо добавить, а там и формат отличается. То это эта задача приводит к модиф. неск. файлов, причём, в зависимсти от того, сколько у нас местЮ, где есть пользователи, меняется и представление. Кроме того, с точки зрения человека, которое заним. логикой, самое последнее дело --- разбираться в том, где какой синтаксис и писать какую-то программу. Этого делать не надо, поскольку есть для этого специальные рпограммы, которые модиф. конфиги. Тем более, было бы очень плохо, если человек, который реализует эту цепочку от предст. до модиф. конфигов, будет рабирвться, с какими ключами что вызывать.

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

Посмотрим apt-cache search alterator. Можно увидеть пакеты для различных модулей. Если сказать rpm -ql alterator-xkb, то можно увидеть утилиты, которыми он пользуется, бэкенд и ui вместе с файлами локализации.

Избретался отнюдь не велосипед, поскольку был уже yast, и задача ... .

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


Сведения о ресурсах

Готовность (%)

Продолжительность (ак. ч.)

Подготовка (календ. ч.)

Полный текст (раб. д.)

Предварительные знания

Level

Maintainer

Start date

End date

0

1

1

1

1

PavelSutyrin (расшифровка завершается), DmitryChistikov


PspoClasses/080704/02ConfigTheory (последним исправлял пользователь MaximByshevskiKonopko 2008-10-10 00:11:41)