Использование конфигураторов: продолжение
1. Решение в лоб (из предыдущего раздела)
Недостатки
Вторая проблема заключается в обеспечении полного покрытия тех задач, которые нам нужно решать. Сделать это, разумеется, можно, но каждый раз приходится взаимодействовать с разными людьми, которые занимаются созданием соответствующих модулей. К примеру, нам нужно решить задачу "добавления пользователя". Это означает, что добавлять пользователя придется в /etc/passwd, в Samba, в хранилища типа LDAP и т. п. Заметим в скобках, что в линейке дистрибутивов ПСПО есть подсистемы, имеющие отдельный интерфейс конфигурирования, отличный от Alterator. Кроме того, конфигураторские интерфейсы часто разрабатываются не под задачу, а под инструмент. Типичный пример - графический конфигуратор /etc/net. Его использование, пожалуй, доставляет больше трудностей, чем непосредственное редактирование конфигурационных файлов. Чтобы эффективно с ним работать, надо знать, как именно функционирует /etc/net. Итак, здесь возникают значительные сложности в сопровождении.
- Третья проблема - это синхронизация пространства имен. С одной стороны, это проекция первых двух проблем, с другой - проблема более общего плана. К примеру, при настройке различных подсистем приходится вводить один и тот же IP-адрес компьютера. Такая процедура вызывает раздражение со стороны пользователя. А если допустить возможность ошибки? Если в разных конфигураторах ввести разные адреса, то гарантировать корректность функционирования всех конфигурируемых таким образом подсистем будет невозможно. Таким образом, проблема унификации имен связана и с проблемой пересечения областей воздействия различных конфигураторов. Если для настройки некоторой службы нужно отредактировать, скажем, 10 файлов, а для настройки другой службы - 5, из которых 2 встречаются среди первых 10, то в случае разрозненных инструментов система, скорее всего, не будет функционировать вообще.
Достоинства
Достоинство такого подхода состоит в легкости сопровождения каждого модуля в отдельности. Достаточно следить за обновлением служб, которые он конфигурирует, и адаптировать его в случае изменения синтаксиса тех или иных конфигурационных файлов. Здесь один из указанных ранее недостатков обращается в достоинство: когда инструмент конфигурации привязан не к задаче, а к инструменту, сопровождение его особенно легко. Конфигуратор для уже названного /etc/net пишется самими авторами, поэтому любое изменение в /etc/net сразу находит отражение в "редакторе настройки".
Заметим, что именно по этому принципу устроено большинство компонентов конфигуратора Debian GNU/Linux (не путать с Ubuntu). Среди требований, предъявляемых к пакетам, есть требование наличия специального конфигурационного скрипта, работающего по протоколу Debconf. При соблюдении этих требований инструмент и система его конфигурирования создаются одним и тем же человеком - мейнтейнером (либо сообществом мейнтейнеров). В каждый момент времени к любому модулю системы в любой части системы существует работающий конфигуратор. Другими словами, без конфигуратора сервис вообще не может существовать. С другой стороны, Debconf конфигурирует инструменты, а вовсе не решает задачи, что, очевидно, является существенным его недостатком. Считается, что эффективно пользоваться Debconf могут только специалисты, знающие, к каким конкретным изменениям в системе приведет, скажем, нажатие той или иной кнопки.
Другой пример - виртуализация в ALT Linux Server 4.0. Существует web-интерфейс, который позволяет эффективно управлять виртуализацией - если знать, что такое виртуализация, что такое openvz, Xen и пр.
2. Монолитная схема
Рассмотрим теперь монолитную схему построения конфигуратора: в одной большой (вероятно, модульной) программе перечислены решаемые задачи. Для каждой такой задачи существует отдельное решение, которое модифицирует конфигурационные файлы. Типичный пример более или менее монолитного конфигуратора - webmin (http://www.webmin.com/).
Достоинства
- Монолитный конфигуратор создается одной командной разработчиков. Для эффективной работы им достаточно адаптироваться к одному и тому же интерфейсу UI и API.
- Монолитный конфигуратор прозрачен для пользователя благодаря единому интерфейсу. Для работы с таким конфигуратором достаточно обучиться правильно заполнять все поля. Подобным образом конфигурируется, скажем, большинство подсистем в Windows. Как, к примеру, происходит подключение к провайдеру обычного пользователя? Ему выдается инструкция со скриншотами, в которой сказано: вписать такое-то значение в такое-то поле. Настройку могут производить те же самые люди, которые осуществляют собственно подключение домов. Заметим, что данное достоинство может обернуться серьезным недостатком: с теченим времени оно становится legacy (необходимостью поддерживать большое количество чего-либо старого, доставшегося по наследству). В какой-то момент придется изменять внешний вид, потому что изменились принципы функционирования. Сохранить старый интерфейс при новой "начинке" бывает необычайно тяжело. Отметим, однако, что разделение областей происходит по задачам, а не по инструментам. Задачи же меняются значительно реже: задача подключения к сети или добавления пользователя вряд ли изменится в ближайшие несколько лет, а вот инструмент для решения может и поменяться.
Недостатки
- Главный недостаток монолитного конфигуратора заключается в том, что его крайне сложно поддерживать: на это требуется очень много ресурсов. Если в Linux-системе немного изменился синтаксис одного из конфигурационных файлов, которыми конфигуратор умеет манипулировать, то нужно вовремя отследить это изменение и отреагировать на него, переписав соответствующую часть конфигуратора. При этом переписывание части может повлечь переписывание всего, начиная с интерфейса и заканчивая конкретным синтаксическим анализатором. Программист такой системы должен обладать талантами как в области системного администрирования (нужно хорошо представлять, как и что мы исправляем), так и в областях проектирования логики работы и программирования собственно интерфейса. По этой причине монолитный подход хорошо работает только в не очень быстро (лучше - последовательно) развивающихся системах с достаточно большим количеством разработчиков, занимающихся именно задачей построения конфигуратора. Выход новой версии, допустим, Red Hat Enterprise Linux сопровождается практически полным переписыванием того, что у них называется конфигуратором: это anaconda, их установщик, и несколько разрозненных модулей. Чтобы оценить объем проделываемой разработчиками RHEL работы, достаточно взглянуть на Changelog.
3. Трехслойная схема
Теория
Возможен и третий подход к построению конфигуратора - трехслойный. В нем разделяются действия трех типов:
- системного администратора, принимающего решения о том, как нужно управлять конфигурационными файлами;
- системного архитектора, определяющего логику работы и решающего, как нужно конфигурировать всю систему в целом;
- дизайнера, создающего пользовательский интерфейс.
Фактически, архитектура такого конфигуратора допускает деление как горизонтальное (по слоям), и вертикальное (по задачам):
Нижний уровень работает с конфигурационным файлом, средний - с логикой представления. Понятно, что уже на уровне представления одна задача может вылиться во взаимодействие сразу с несколькими конфигурационными файлами. Рассмотрим простой пример. Пусть на уровне представления есть следующая задача: добавить пользователя (в базу данных пользователей). Для оператора ЭВМ это означает, что где-то в интерфейсе есть список пользователей, обладающих тем или иным набором свойств. Он нажимает кнопку "добавить еще пользователя" и задает его свойства (пароль, домашний каталог, группу и пр.). На этом его роль заканчивается. На уровене же модификации конфигурационных файлов добавление пользователя - это достаточно непростая и зачастую неатомарная операция. Она не сводится к добавлению строки к /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 строк программного кода).
Недостатки
- Главный недостаток рассмотренной конструкции (да и составного конфигуратора вообще) - его "текучесть". Разобраться, какой именно протокол взаимодействия между уровнями "самый правильный", бывает весьма непросто: его описание постоянно претерпевает значительные изменения. То же и с пользовательским интерфейсом: он не связан с конкретным типом интерфейса, а предоставляет множество разнородных элементов управления. Конструирование библиотек для таких интерфейсов - задача весьма непростая.
Достоинства
- Несмотря на то, что поддерживать "трехслойный" конфигуратор весьма непросто, это оказывается легче, чем при монолитном подходе. Главную часть Alterator'а традиционно поддерживают один-два человека, модули же пишутся гораздо большим количеством людей. Человеческих ресурсов при такой схеме расходуется существенно меньше, хотя модулей достаточно много.
- Главное достоинство "трехслойного" конфигуратора - независимость уровней. Для нижней пары уровней мы это уже видели, а для верхней пары это следует, к примеру, из существования разных пользовательских интерфейсов. В Alterator'е, как мы видели, есть возможность использования form-based interface (FBI) - это уровень представления для Web. При создании Alterator'а была возможность вставки еще одного промежуточного уровня, но от этой идеи отказались, так как в Qt и, допустим, HTML (или тексте) слишком разные способы представления данных и команд. Хорошим технологичным примером в этом смысле служит Debconf, но у него нет центрального слоя, управления логикой (он ориентирован на инструмент, а не на задачу). В RHEL же и Fedora используется целое семейство конфигураторов с различными типами интерфейсов.
Сведения о ресурсах
Готовность (%) |
Продолжительность (ак. ч.) |
Подготовка (календ. ч.) |
Полный текст (раб. д.) |
Предварительные знания |
Level |
Maintainer |
Start date |
End date |
90 |
1 |
1 |
1 |
|
1 |
|
|