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

Вторая проблема при таком подходе. Достаточно тяжело обеспечить полное покрытие тех задач, которые нам нужны. Это можно сделать, но фактически каждый раз нам придется взаимодействовать с разными людьми, которые занимаются созданием этих модулей, а они разнородные, эти люди.

Например, нам нужно решить задачу добавления пользователя, но у нас нет задачи добавления пользователя просто так, есть добавление в passwd, есть добавление пользователя в самбу, есть добавление пользователя в какое-нибудь хранилище, вроде LDAP, или ещё куда. Отчасти в линейке дистрибутивов ПСПО это так, мы увидим некоторые места, интерфейс конфигурирования для которых отдельный, не имеющий отношения вот к этой штуке. Итак, вторая проблема --- обеспечить покрытие. Еще часто бывает, что такие конфигураторские интерфейсы разрабатываются не под задачу, а под инструмент. Есть замечательный графический конфигуратор etcnet (?), он еще более замороченный, чем его конфигурационные файлы, то есть в нем разобраться невозможно вообще, потому что люди просто для себя писали. Да, там наверное сокращаются какие-то действия, но не зная как это все работает, это довольно тяжело сопровождается.

Третья проблема, которая на самом деле является проекцией первых двух. Проблема более общего плана, проблема синхронизации пространств имён. Я об этом уже упоминал, когда говорил, что у нас внешний вид разный, у нас утилиты разнородные, но тут на самом деле более серьезный вопрос перед нами стоит: В одном конфигураторе я ввожу ip-адрес, в другом конфигураторе я ввожу ip-адрес, в третьем конфигураторе я снова ввожу ip-адрес, это один и тот же ip-адрес, даже если я его все три раза одинаково введу, это меня уже будет раздражать, а если в какой-то момент я еще и не разберусь и в одном месте введу одно, а в другом другое и в этом случае ip-адрес нашей машины поменяется опять, то это будет совсем плохо, то есть проблема унификации пространства имен напрямую связана с братской ей проблемой, с проблемой пересечения области воздействия таких конфигураторов. Если для настройки такой-то службы нужно отредактировать какие-то 10 конфиг файлов, для настройки другой службы -- 5, из которых 2 встречаются среди первых 10. Если у нас инструменты конфигурирования разрозненные, то убить это можно просто влёгкую.

Есть у этого метода помимо недостатков и достоинства. состоит в следующем: более или менее один такой модуль сопровождать легко, то есть следить за обновлением служб, которые он конфигурирует, и адаптировать его в случае изменения в конфигах файлов, я как человек, пользующийся и этим конфиг файлом и этим конфигуратором, могу быстро отследить и поменять что-то в конфигураторе, изменении. Особенно в случае, который я представил как неудобный, когда инструмент конфигурирования завязан не на задачу, а на конкретный инструмент. Когда редактор для конфигов etcnet'а (не инструмент для настройки сети), его авторам etcnet'а легко сопровождать: они поменяли etcnet, они поменяли редактор для настройки etcnet.

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

То есть, обычные люди при работе с debconf'ом, которые понимают как нажимать на кнопку, они не понимают, что там написано.

Другой пример -- Alt Linux Server 4.0. там замечательный веб-интерфейс, который позволяет управлять виртуализацией очень-очень удобно, если ты сам знаешь, что такое виртуализация, что такое openvz, что такое bincounter (?), и т.п. и т.п.

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

Как происхоидт подключение к провайдеру обычного пользователя?.. Ему выдается бумажка со скриншотами, на которой написано: в такое-то окошко вбейте то-то. Более того, если пользователь отказывается, говорит, я в компьютерах не разбираюсь, подключайте сами, то те самые ребята, которые (разрезают сетевые кабеля и связывают их узлом) осуществляют подключение домов, они же настраивают windows по этой же бумажке. Я видел, они мне сказали мы вас подключим, только у нас написано в документации, чтобы у вас обязательно стоял service pack 2. я говорю, я не знаю, проверьте, вот на этой машине (на проекционном Sony VAIO) Они потыкали, очень испугались, не увидев кнопки Пуск.

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

Главный недостаток монолитного конфигуратора состоит в том, что его безумно сложно поддерживать. Сложно в том смысле, что на эту задачу потребно очень много ресурсов. Представьте ситуацию. В вашей линукс системе слегка меняется синтаксис одного из 200 конфигурационных файлов, которыми ваш конфигуратор умеет манипулировать. Меняется. Вы как разработчик этого конфигуратора обязаны этот момент а) вовремя отследить, б) на это отреагировать путем переписывания соотв. части вашего конфигуратора. При этом переписывание части возможно повлечет за собой переписывание всего, начиная от интерфейса, заканчивая конкретным синтаксическим анализатором этих конфигов. Крайне неудобно, потому что у вас как у программиста должны быть таланты и системного администратора, т.к. вы должны себе представлять, зачем вы все это исправляете, и программиста, который занимается логикой, вы должны уметь разбирать конфиг файл и собирать его обратно, и программиста, который программирует графический интерфейс, потому что а как иначе, его же тоже надо запрограммировать.

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

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

Сразу о недостатках трехуровневого конфигуратора. Фактически у нас есть и горизонтальное и вертикальное деление (задача1, задача2), и три уровня. Нижний уровень работает с конфиг-файлом, средний работает с логикой представления. Уже понятно, что уже на уровне представления (задача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, то можно увидеть утилиты, которыми он пользуется, вот это бэкенды, вот это фронтэнды, а вот это ui вместе с файлами локализации. (транскриптшот?)

Посмотрите, в центр управления, есть там про клавиатуру?.. Есть. Я не понимаю, где здесь бэкэнд. А, вот (?), 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 на текст. У них есть силы на это.


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

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

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

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

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

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

Level

Maintainer

Start date

End date

20

1

1

1

1

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



CategoryLectures