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

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

недостатки

достоинства

Чтобы закончить этот кусок, скажу, что именно по этому принципу устроены большинство частей конфигуратора, точнее того, что заменяет конфигуратор в Debian GNU/Linux (не путать с Ubuntu). Из той полиси, которая накладывается на пакет, что у каждого пакета должен быть конфигурационный скрипт специальный, причем по протоколу debconf работающий, следует напрямую, что и инструмент, и конфигурацию к нему, более или менее автоматизированную, делает один и тот же человек -- мейнтейнер, либо сообщество мейнтейнеров. Это показывает, как в Debian'е в очень сильной степени эксплуатируется это преимущество, что, вообще говоря, мы всегда имеем работающий конфигуратор к любому модулю системы в любой части системы, просто потому что в полиси написано, что без конфигуратора сервис не существует. Но недостаток, как раз связанный с тем, что мы конфигурируем инструмент (отдельный пакет), а вовсе не решаем задачу, он на месте, не зря говорится, что работать в debconf'ом, будь он трижды графический, могут только достаточно крутые профессионалы, они на самом деле редактируют файлы. То есть, обычные люди при работе с debconf'ом, которые понимают как нажимать на кнопку, они не понимают, что там написано. Другой пример -- ALT Linux Server 4.0. там замечательный веб-интерфейс, который позволяет управлять виртуализацией очень-очень удобно, если знать, что такое виртуализация, что такое openvz, что такое bearcounter (?), и т.п. и т.п.

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

Есть другая схема построения конфигуратора, неудобная, сейчас скажу почему. Это схема монолитная, сейчас мы рассмотрели схему разрозненную, а это монолитная. Мы пишем одну большую программу, в которой перечислены задачи, которые мы хотим решить, возможно это даже модульная программа, и под каждую задачу мы пишем решение, которое модифицирует конфиг файлы, возможно, этих конфиг-файлов много, возможно немного, вот мы это и делаем. Типичный пример более или менее монолитной программы -- это webmin.

Достоинства

Недостатки

Главный недостаток монолитного конфигуратора состоит в том, что его безумно сложно поддерживать. Сложно в том смысле, что на эту задачу требуется очень много ресурсов. Представьте ситуацию. В вашей линукс системе слегка меняется синтаксис одного из 200 конфигурационных файлов, которыми ваш конфигуратор умеет манипулировать. Вы как разработчик этого конфигуратора обязаны этот момент а) вовремя отследить, б) на это отреагировать путем переписывания соотв. части вашего конфигуратора. При этом переписывание части возможно повлечет за собой переписывание всего, начиная от интерфейса, заканчивая конкретным синтаксическим анализатором этих конфигов. Крайне неудобно, потому что у вас как у программиста должны быть таланты и системного администратора, т.к. вы должны себе представлять, зачем вы все это исправляете, и программиста, который занимается логикой, вы должны уметь разбирать конфиг файл и собирать его обратно, и программиста, который программирует графический интерфейс, потому что а как иначе, его же тоже надо запрограммировать. По этой причине хорошо работает этот монолитный подход только на системах, которые развиваются не очень быстро, последовательно, а самое главное, имеют достаточное количество в команде разработчиков людей, которые занимались бы именно этим и больше ничем. По сути, каждый выход новой версии, допустим, Red Hat Enterprise Linux сопровождается практически полным переписыванием того, что у них называется конфигуратором. У них есть anaconda, их установщик, и есть несколько разрозненных модулей. Вот каждый из них переписывается, если вы посмотрите на Changelog, очень-очень сильно, в тот момент, когда происходит выпуск нового RHEL, я не говорю про Fedora, а про RHEL, где все это должно работать (очень хорошо). Я уже не говорю всякий людей типа Linspire'ов, которого больше нет (их купил Xandros, конкурент).

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

Достоинства

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

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

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

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

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

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

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

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

Level

Maintainer

Start date

End date

20

1

1

1

1

PavelSutyrin (расшифровка), DmitryChistikov