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

1. Решение в лоб (из предыдущего раздела)

Недостатки

Достоинства

Заметим, что именно по этому принципу устроено большинство компонентов конфигуратора Debian GNU/Linux (не путать с Ubuntu). Среди требований, предъявляемых к пакетам, есть требование наличия специального конфигурационного скрипта, работающего по протоколу Debconf. При соблюдении этих требований инструмент и система его конфигурирования создаются одним и тем же человеком - мейнтейнером (либо сообществом мейнтейнеров). Это преимущество активно используется в Debian: в каждый момент времени к любому модулю системы в любой части системы существует работающий конфигуратор. Другими словами, без конфигуратора сервис вообще не может существовать. Естественно вытекающий недостаток заключается в том, что Debconf конфигурирует инструменты, а вовсе не решает задачи. Считается, что эффективно пользоваться Debconf могут только специалисты, знающие, к каким конкретным изменениям в системе приведет, скажем, нажатие той или иной кнопки.

Другой пример - виртуализация в ALT Linux Server 4.0. Существует web-интерфейс, который позволяет эффективно управлять виртуализацией - если знать, что такое виртуализация, что такое openvz, bearcounter (?) и пр.

2. Монолитная схема

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

Достоинства

Недостатки

Главный недостаток монолитного конфигуратора заключается в том, что его крайне сложно поддерживать. Иными словами, на это требуется очень много ресурсов. Если в линукс-системе немного изменился синтаксис одного из конфигурационных файлов, которыми конфигуратор умеет манипулировать, то нужно вовремя отследить это изменение и отреагировать на него, переписав соответствующую часть конфигуратора. При этом переписывание части может повлечь переписывание всего, начиная с интерфейса и заканчивая конкретным синтаксическим анализатором. Программист такой системы должен обладать талантами как в области системного администрирования (нужно хорошо представлять, как и что мы исправляем), так и в областях проектирования логики работы и программирования собственно интерфейса. По этой причине монолитный подход хорошо работает только в не очень быстро (лучше - последовательно) развивающихся системах с достаточно большим количеством разработчиков, занимающихся именно задачей построения конфигуратора. Выход новой версии, допустим, Red Hat Enterprise Linux сопровождается практически полным переписыванием того, что у них называется конфигуратором: это anaconda, их установщик, и несколько разрозненных модулей. Чтобы оценить объем проделываемой работы, достаточно взглянуть на Changelog.

3. Трехслойная схема

Теория

Возможен и третий подход к построению конфигуратора - трехслойный. В нем разделяются действия системного администратора, который принимает решения о том, как нужно управлять конфигурационными файлами, системного архитектора (как нужно конфигурировать всю систему в целом - логика) и, скажем так, дизайнера (создает графический интерфейс). Фактически, есть и горизонтальное (по слоям), и вертикальное (по задачам) деление архитектуры системы:

     задача 1       | задача 2
|===================+=======================
|     ---------     |  ---------            |
|     |       |     |  |       |            |  (уровень представления, UI, front-end)
|     ---------     |  ---------            |
|=========|=========|======|================|<--- унифицированные высокоуровневые команды
|       ----        |     ----              |
|       |  |        |     |  |              |  (уровень логики)
|       ----        |     ----              |
|=======/===\=======+=====/===\=============|<---- унифицированные низкоуровневые команды
|     ---    \---> --- <-/    ---           |
|     | |          | |        | |           |  (уровень конфигурационных файлов, back-end)
|     ---          ---        ---           |
|===========================================

Нижний уровень работает с конфигурационным файлом, средний - с логикой представления. Понятно, что уже на уровне представления одна задача может вылиться во взаимодействие сразу с несколькими конфигурационными файлами, управляемой некоторой логикой. Рассмотрим простой пример. Пусть на уровне представления есть следующая задача: добавить пользователя (в базу данных пользователей). Для оператора ЭВМ это означает, что где-то в интерфейсе есть список пользователей, обладающих тем или иным набором свойств. Он нажимет кнопку "добавить еще пользователя" и задает его свойства (пароль, домашний каталог, группу и пр.). На этом его роль заканчивается. На уровене же модификации конфигурационных файлов добавление пользователя - это достаточно непростая и зачастую неатомарная операция. Она не сводится к добавлению строки к /etc/passwd: есть еще Samba-пользователи и пр. Известно, что пользователи Samba хранятся в отдельной БД, причем список полей этой БД сильно отличается от списка полей в /etc/passwd. В Samba хранятся, к примеру, пароли пользователей, а в /etc/passwd хранятся лишь хэши паролей. Таким образом, на нижнем уровне операция добавления пользователя должна привести к модификации нескольких конфигурационных файлов. В зависимости от того, сколько есть "мест" в системе, ответственных за понятия пользователя, изменяется на уровне представления и содержимое того окна, куда оператор вводит данные. Например, там может быть такое поле: сделать общедоступным по smb его домашний каталог. Заметим, что человеку, который планирует эту систему, разбираться в том, какой синтаксис у /etc/passwd, а какой у smbpasswd, не следует. Не должен он и писать программу, которая редактирует (сама) файл /etc/passwd. Существуют специальные программы, занимающиеся модифицированием этого файла, например adduser, он же useradd. Подобные же утилиты существуют и для Samba. Человек, который реализует цепочку от представления и заполнения полей до нижнего уровня, не должен задумываться о том, с какими ключами вызывается та или иная программа.

Поэтому между уровнем логики и уровнем конфигурационных файлов существует, скажем так, прослойка, задача которой - унификация передаваемых данных. На уровне конфигурации специальный модуль распознает уже унифицированные низкоуровневые команды и превращает их в работу с passwd или что-либо иное - для другого модуля. Эти модули регистрируются на уровне представления. Когда человек добавляет пользователя, он видит окно, а в нем два модуля: Samba и POSIX (Unix) users. Пользователь уровню логики дает высокоуровневые команды, передавая данные из полей. Уровень логики транслирует это в низкоуровневые команды: модулю posix добавить пользователя с таким-то паролем, модулю smb добавить пользователя с таким-то паролем. После чего "нижние" модули делают свое дело и отвечают уровню логики на некотором унифицированном языке: "Я пользователя добавил, все в порядке", "Я пользователя пытался добавить, но там проблемы, ошибка вышла", - тогда уровень логики может сказать первому: "Отмени внесенные изменения" (иначе будет потеряна целостность системы). Управляет этим процессом именно уровень логики, а на уровень интерфейса выносится сообщение об ошибке, оттранслированное, скажем, следующим образом: "При добавлении пользователя в Samba произошла ошибка, операция отменена". Преобразование низкоуровневых унифицированных команд в работу с различными файлами и программами осуществляется специальными сценариями на языке Shell (либо awk, Scheme или иных).

Точно так же происходит и простой просмотр данных. Уровень логики говорит: "У меня есть задача получить список пользователей, кто даст?" Модуль Samba отвечает: "Я", модуль passwd отвечает: "Я". Данные пойдут так, как описано, только уже снизу вверх.

Понятно, что разделение на три уровня в данной схеме принципиально. Если одна команда сверху транслируется в несколько действий снизу, то без разделения на администраторскую, архитекторскую и дизайнерскую часть работать весьма непросто. Подобным образом устроен конфигуратор YaST в SUSE, хотя разделение на уровни там менее жесткое: возможно написать один большой YaST-модуль, который будет выполнять все части работы, за исключением собственно записи конфигурационного файла. Два верхних уровня в YaST вообще часто слиты в один. В конфигураторе же Alterator, используемом в дистрибутивах ПСПО ALT Linux, разделение соблюдается строже: выделены описание политик (уровень представления), трансляция команд и принятие решений (уровень логики) и собственно конфигурирование.

Потыкаем

Прежде чем тыкать, посмотрим в консоли apt-cache search alterator. Можно увидеть пакеты для различных модулей. alterator-что-то, есть даже отдельно alterator-backend-что-то, хотя в последнем случае обычно содержится и frontend, и backend, и этих пакетов немаленькое число.

вот lookout это как раз третий уровень. Что бы нам посмотреть?

Если сказать rpm -ql alterator-xkb, то можно увидеть утилиты, которыми он пользуется:

[user@demo ~]$ rpm -ql alterator-xkb
/usr/bin/xkbdatadump                                 \   вот это фронтэнды
/usr/bin/xkbmapconf                                  /
/usr/lib/alterator/backend3/template-xkb             \   вот это бэкенды
/usr/lib/alterator/backend3/xkb                      /
/usr/share/alterator/applications/xkb.desktop        \
/usr/share/alterator/ui/xkb                          |
/usr/share/alterator/ui/xkb/avail_layout.scm         |
/usr/share/alterator/ui/xkb/html-messages.scm        |
/usr/share/alterator/ui/xkb/index.scm                |   а вот это ui вместе с файлами локализации.
/usr/share/locale/be/LC_MESSAGES/alterator-xkb.mo    |
/usr/share/locale/ru/LC_MESSAGES/alterator-xkb.mo    |
/usr/share/locale/uk/LC_MESSAGES/alterator-xkb.mo    |
/var/www/html/fbi                                    |
/var/www/html/fbi/xkb-layout.html                    |
/var/www/html/fbi/xkb.html                           /

Посмотрите, в центр управления, есть там про клавиатуру?.. Есть. Я не понимаю, где здесь бэкэнд. А, вот (?), template. А вот это утилита, которая к нему ходит. Покажите-ка вот это, наверняка он на Scheme написан... хрен, на шелле он написан, ну вот. Вот эта часть -- представление (ui), эта часть (backend), эта часть -- представление в другом ui (html), это для конфигуратора который запускается через веб, а это специальная утилита, которая облегчает backend'у жизнь, и так оно устроено практически везде, в любом модуле мы увидим...

С alterator'ом избретался отнюдь не велосипед, потому что даже я слегка более жестко и менее аккуратно выдержан по этой трехуровневой архитектуре, и, в свое время моя была задача, чтобы системному администратору, которому все эти дизайнерские заморочки до лампочки, позволить писать свои бэкэнды на чем хочешь, на шелле, на awk, на perl, на Scheme, у нас не только ui на Scheme, но и backend'ы тоже можно писать. Тут UI написан на Scheme. Давайте посмотрим в ...layout, вы увидите, что это как-то безумно просто... 66 строк.

Недостатки

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

Достоинства

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

Кстати, в RHEL-Fedora, у них семейство конфигураторов, у них ничего единого, у них поддерживается текстовая часть, но поддерживается точно также, берется и переписывается большая часть с GUI на текст. У них есть силы на это.


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

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

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

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

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

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

Level

Maintainer

Start date

End date

30

1

1

1

1

PavelSutyrin, DmitryChistikov