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

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

Недостатки

Достоинства

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

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

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

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

Достоинства

Недостатки

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

Теория

Возможен и третий подход к построению конфигуратора - трехслойный. В нем разделяются действия трех типов:

Фактически, архитектура такого конфигуратора допускает деление как горизонтальное (по слоям), и вертикальное (по задачам):

../config_architecture_72dpi.png

Нижний уровень работает с конфигурационным файлом, средний - с логикой представления. Понятно, что уже на уровне представления одна задача может вылиться во взаимодействие сразу с несколькими конфигурационными файлами. Рассмотрим простой пример. Пусть на уровне представления есть следующая задача: добавить пользователя (в базу данных пользователей). Для оператора ЭВМ это означает, что где-то в интерфейсе есть список пользователей, обладающих тем или иным набором свойств. Он нажимает кнопку "добавить еще пользователя" и задает его свойства (пароль, домашний каталог, группу и пр.). На этом его роль заканчивается. На уровене же модификации конфигурационных файлов добавление пользователя - это достаточно непростая и зачастую неатомарная операция. Она не сводится к добавлению строки к /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, разделение соблюдается строже: выделены описание политик (уровень представления), трансляция команд и принятие решений (уровень логики) и собственно работа с конфигурационными файлами.

Проиллюстрируем описанную схему. Посмотрим список пакетов в нашем дистрибутиве, относящихся к Alterator:

[user@demo ~]$ apt-cache search alterator
alterator - ALT Linux configurator engine
alterator-apt - wrapper over apt-get
alterator-autoinstall - automatic non-interactive installer engine
alterator-backend-x11 - alterator backend for x11 setup and configuration
alterator-browser-qt - X11 Qt interface driver for alterator
alterator-chkconfig - alterator module for simple service setup
alterator-control - alterator module for control package
alterator-datetime - alterator module for date/time setup
alterator-design-server - stylesheets and images for server distribution
alterator-fbi - alterator on rails
alterator-firewall - alterator module for iptables firewall control
alterator-http - alterator http/cgi libraries
alterator-icons-lite - pictures for alterator
alterator-lilo - alterator module for lilo setup
alterator-lookout - dialog based interface for alterator
alterator-menu - alterator control center menu driver
alterator-net-common - helpers for etcnet administration
alterator-net-eth - alterator module for tcp/ip connections configuration
alterator-net-general - alterator module for general network settings
alterator-net-junior - alterator module for general network settings
alterator-net-pppoe - alterator module for pppoe connections configuration
alterator-net-pptp - alterator module for pptp connections configuration
alterator-net-wifi - alterator module for wi-fi connections administration
alterator-notes - alterator module for view license and release notes
alterator-pkg - additional package installation
alterator-root - alterator module for edit system administrator properties
alterator-sh-functions - helper functions for alterator shell based backends
alterator-squid - alterator module for Squid
alterator-standalone - System Management center
alterator-standalone-usermode - usermode bindings for alterator-standalone
alterator-sysconfig - alterator module for basic system settings
alterator-sysinfo - alterator module to view general system information
alterator-tzone - alterator module for timezone setup
alterator-ulogd - alterator module for network traffic statistics
alterator-users - alterator module for system users administration
alterator-wizardface - alterator's wizard like module aggregator
alterator-x11 - alterator module for Xorg setup and configuration
alterator-xkb - alterator module for XKB administration
design-alterator-browser-qt-junior - Junior design for alterator-browser-qt
docs-alterator_vm - Разбиение диска средствами программы установки
httpd-alterator - Apache HTTP Server (alterator edition)
alterator-vsftpd - alterator module for vsftpd configuration

На экране появился список основных компонентов и модулей Alterator'а. К примеру, alterator-lookout - это компонент, отвечающий за уровень представления, а alterator-xkb - модуль, управляющий настройками клавиатуры. Выведем список файлов в системе, относящихся к пакету 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
/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

Файлы из /usr/lib/alterator/backend3 - это собственно back-end, исполняемые файлы из /usr/bin - вспомогательные утилиты. В /usr/share/locale лежат данные для локализации. Написанные на языке Scheme сценарии для интерфейса находятся в /usr/share/alterator/ui (в специальном подкаталоге), а в /var/www/html/fbi размещены файлы, относящиеся к Web-интерфейсу (обратим внимание на наличие двух разных способов представления). Заметим, что Alterator позволяет писать back-end'ы на чем угодно: подойдет и Shell, и awk, и Perl, и Scheme (который, как мы видим, в данном случае использовался для написания UI; заглянув в файл avail_layout.scm, мы увидим всего лишь 66 строк программного кода).

Недостатки

Достоинства


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

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

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

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

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

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

Level

Maintainer

Start date

End date

90

1

1

1

1

PavelSutyrin, DmitryChistikov, MaximByshevskiKonopko


PspoClasses/080704/02ConfigTheory (last edited 2008-10-09 21:11:41 by MaximByshevskiKonopko)