Изменения в «PspoClasses/080704/02ConfigTheory»

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

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

Недостатки

• Вторая проблема заключается в обеспечении полного покрытия тех задач, которые нам нужны. Сделать это, разумеется, можно, но каждый раз приходится взаимодействовать с разными людьми, которые занимаются созданием соответствующих модулей. К примеру, нам нужно решить задачу "добавления пользователя". Это означает, что добавлять пользователя придется в passwd, в Samba, в хранилища типа LDAP и т. п. Заметим в скобках, что в линейке дистрибутивов ПСПО есть подсистемы, имеющие отдельный интерфейс конфигурирования, отличный от Alterator. Кроме того, конфигураторские интерфейсы часто разрабатываются не под задачу, а под инструмент. Типичный пример - графический конфигуратор /etc/net. Его использование, пожалуй, доставляет больше трудностей, чем непосредственное редактирование конфигурационных файлов: чтобы его использовать, надо знать, как именно функционирует /etc/net. Итак, здесь возникают значительные сложности в сопровождении.
• Третья проблема - это синхронизация пространства имен. С одной стороны, это проекция первых двух проблем, с другой - проблема более общего плана. К примеру, при настройке различных подсистем приходится вводить один и тот же IP-адрес компьютера. Такая процедура вызывает раздражение со стороны пользователя. А если допустить возможность ошибки? Если в разных конфигураторах ввести разные адреса, то гарантировать корректность функционирования всех конфигурируемых таким образом подсистем будет невозможно. Таким образом, проблема унификации имен связана и с проблемой пересечения областей воздействия таких конфигураторов. Если для настройки некоторой службы нужно отредактировать, скажем, 10 файлов, а для настройки другой службы - 5, из которых 2 встречаются среди первых 10, то в случае разрозненных инструментов система, скорее всего, функционировать не будет вообще.

Достоинства

• Достоинство такого подхода состоит в легкости сопровождения каждого модуля в отдельности. Достаточно следить за обновлением служб, которые он конфигурирует, и адаптировать его в случае изменения синтаксиса тех или иных конфигурационных файлов. Человек, пользующийся и этим файлом, и конфигуратором, сделает это без всякого напряжения. Здесь один из указанных ранее недостатков обращается в достоинство: когда инструмент конфигурации привязан не к задаче, а к инструменту, сопровождение его особенно легко. Конфигуратор для уже названного /etc/net пишется самими авторами, поэтому любое изменение в /etc/net сразу находит отражение в "редакторе настройки".

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

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

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

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

Достоинства

• Монолитный конфигуратор создается одной командной разработчиков. Для эффективной работы им достаточно адаптироваться к одному и тому же интерфейсу UI и API.
• Монолитный конфигуратор прозрачен для пользователя. Существует единый интерфейс, к которому нужно привыкнуть, но на этом все сложности заканчиваются: достаточно обучить пользователя правильно заполнять все поля. Подобным образом конфигурируется, скажем, большинство подсистем в Windows. Как, к примеру, происходит подключение к провайдеру обычного пользователя? Ему выдается инструкция со скриншотами, в которой сказано: вписать такое-то значение в такое-то поле. Настройку могут производить те же самые люди, которые осуществляют собственно подключение домов. Заметим, что это достоинство может обернуться серьезным недостатком: с теченим времени оно становится legacy (необходимостью поддерживать большое количество чего-либо старого, доставшегося по наследству). В какой-то момент придется изменять внешний вид, потому что изменились принципы функционирования. Сохранить старый интерфейс при новой "начинке" бывает необычайно тяжело. Отметим, однако, что разделение областей происходит по задачам, а не по инструментам. Задачи же меняются значительно реже: задача подключения к сети или добавления пользователя вряд ли изменится, а вот инструмент для решения - вполне возможно.

Недостатки

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

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

Теория

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

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

Нижний уровень работает с конфиг-файлом, средний работает с логикой представления. Уже понятно, что уже на уровне представления (задача1, задача2) одна задача может вылиться во взаимодействие сразу с несколькими конфигурационными файлами (вот так вот), путём некоей логики. Типичный пример. У нас есть задача на уровне представления добавить пользователей в БД пользователей. Для оператора ЭВМ это означает, что есть где-то список пользователей, обладающих какими-то свойствами. Человек нажимает кнопку добавить еще пользователя, задаёт ему некие свойства, которые нужно задать, ну скажем, пароль, домашний каталог, группу, если надо, или что-то еще, потому что мало ли, что такое пользователь, и, собственно, его роль как оператора ЭВМ заканчивается. Что такое добавление пользователя на уровне модификации конфигов? А довольно непростая и зачастую неатомарная вещь. Вы хотели добавить пользователя, допустим в passwd. Он добавляется в passwd. А между тем у вас есть еще samba'овские пользователи, которых тоже надо добавить, если на этой машине есть и доступ по логину, и самбовская шара, то нужно добавить и в самбу тоже. Мы знаем, что пользователи у самбы хранятся отдельно, у них даже те данные, которые там хранятся, сильно различаются. В самбе у пользователей хранятся пароли, а у юниксовых пользователей хранятся только хэши паролей. Таким образом, на низком уровне операция добавления пользователя должна привести к модификации нескольких конфигов, причем, в зависимости от того, сколько у нас есть точек, ответственных за понятие пользователя, изменяется на уровне представления содержимое того окна, куда оператор вбивает данные. Например, там может быть поле: раздавать его домашний каталог в качестве шары, или не раздавать, что-нибудь в этом духе, например. Кроме того, человеку, который планирует вышесказанное, самое последнее дело -- разбираться в том, какой синтаксис у passwd, какой у smbpasswd, и вообще писать самостоятельно какую-то программу, которая (внимание!) редактирует файл passwd. Так делать не надо. Существуют специальные программы, которые редактируют файл passwd, например adduser, он же useradd. Точно также существуют специальные программы, которые модифицируют самбовские настройки. Тем боле было бы очень плохо, если человек, который реализует цепочку от представления и заполнения полей до самого низа, будет задумываться о том, с какими ключами что вызывать.

Поэтому между уровнем нижним и уровнем логики существует некая прослойка, задача которой -- унификация передаваемых данных. Вы пишете shell-скрипт, или awk-скрипт, или на Scheme что-нибудь такое пишете, которое преобразует унифицированные низкоуровневые команды, они всегда одинаковые, что бы вы ни редактировали. А на уровне конфигурации специальный модуль распознает эти унифицированные низкоуровневые команды и превращает их в работу с passwd или (другой модуль). Они регистрируются в этом уровне представления: (один модуль говорит:) у меня есть некая информация, (другой модуль говорит:) и у меня есть некая информация. когда человек добавляет пользователя, он видит окошечко, в которое ручки свои запускает, два модуля, samba'овый, и posix (unix) users. Пользователь уровню логики дает высокоуровневые команды, унифицированные, просто данные из полей, выдает заполненное поле пользователя, выдаёт команду "добавить" Уровень логики транслирует это все в низкоуровневые команды -- модулю posix добавить пользователя с таким-то паролем, модулю smb тоже добавить пользователя с таким-то паролем. После чего нижние модули делают свое дело, отвечают на уровень логики на некотором унифицированном языке некотором: "я пользователя добавил, все в порядке", второй: "я пользователя пытался добавить, но там проблемы, ошибка вышла", тогда уровень логики может сказать первому: "тогда ты тоже откати, а то у тебя тоже ошибка будет", уровень логики сам этим управляет, а на уровень интерфейса с пользователем выносится сообщение об ошибке оттранслированное в такой вид, что, мол добавили в оба места, все получилось. Можно писать скрипт, который преобразует. унифицированные. команды по управлению системой в работу с различными конфигами и программами. Пусть есть задача с пользователем, есть два места passwd и smb, они регистрируются как модули, которые работают с польз., и при доб. каждому говорится, чтобы добавить, а они потом отчитываются. Если где ошибка, то можно откатить.

Точно также происходит не добавление, а просто добыча (просмотр) данных. Уровень логики говорит: у меня есть задача получить список пользователей, кто даст? один модуль говорит: я дам, другой говорит: я дам,

Понятно зачем сделано разделение на три уровня?.. Понятно, все кивают. Расцепить работу администратора, работу человека, который собственно пишет конфигуратор, и работу дизайнера. В случае когда одна команда сверху транслируется в несколько действий снизу -- без этого довольно тяжело. По такой схеме устроен как минимум конфигуратор SUSE, под названием yast, хотя там не везде поддерживается такое строгое разделение на три уровня. Вы можете написать один большой yast-модуль, который будет делать практически все, за исключением того, что он не пишет конфиг-файл. Два верхних уровня часто слиты воедино. А в том конфигураторе, который используется в альт-линукса, более или менее разделено. Существует уровень представления, существует уровень логики, существует низкоуровневый уровень, который занимается работой с конфиг-файлами. Правда, уровень логики мы еще не развили, утрясаем вызов и управление, и если посмотреть сюда (скриншот?), можно видеть что то похоже на пресловутый редактор конфигурационных файлов, хотя уже не без зачеса на задачи непосредственно. Но разделение на три уровня соблюдается жестко. Есть отдельная штука, которая описывает представление с полями, которые вы должны заполнить, есть отдельно штука, которая занимается трансляцией вот этой самой логикой, и принимает решения о том, выполнена задача или нет, в частности, она же должна заниматься связыванием модулей (не знаю, как сейчас), и есть совершенно отдельная штука, которая используется для низкоуровневого конфигурирования, причем в отличие от тех команд, которые реально вызываются над файлами, она работает по стандартному протоколу, у нее есть команды add, delete, get, show, и т.п. не то 5, не то 3.

Потыкаем

Прежде чем тыкать, посмотрим в консоли 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, мы ее отвязали от конкретного представления и можем что угодно делать, а в реальности если мы позволяем делать что угодно, он бывает такой развесистый, всякий, а надо бы сделать такую библиотеку, чтобы ей все пользовались, чтобы она была простая, чтобы сказал такой-такой-такой, берет данные оттуда, посылает данные туда, всем до свидания, вот что надо было сделать. И вообще говоря, его тоже нужно поддерживать.

Достоинства

• Поддержка легче, чем в случае монолитного подхода. Традиционно костяк альтератора поддерживается 1--2 человеками, а модули пишет много кто. Человеческих ресурсов расходуется существенно меньше, хотя модулей достаточно много.
• Независимость уровней. Независимость уровня бэкэнда от середины я уже показал, это (что выше) пишется на шелле, а это (что ниже) вообще может быть бинарник, а может быть на чем угодно, даже на scheme, т.к. там прямые ручки к среднему уровню, там не нужно переводить на один язык, потом на другой. Точно также есть независимость между уровнем представления и уровнем логики, о чем свидетельствует вот эта часть (?), это другое представление, предназначенное для html, для form-based интерфейс (FBI), это штука, которая используется в ALT Linux Server, и вообще во всех веб-конфигураторах наших. Это не переписанный конфигуратор, а переписанное только представление, разумеется мы сначала ввести промежуточный уровень унифицированного представления, но поняли, что это бессмысленно, если мы работаем с html -- там одни способы представления, если мы работаем с QT -- другие, если мы работаем с текстом -- вообще третьи, потому что нельзя на текстовом экране представить то, что можно представить...

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

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

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

• CategoryLectures