PspoClasses/080704/01ConfigTheory

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

В качестве конфигуратора выступает Alterator в Линукс Мастер.

Проблемы, ведущие к использованию конфигуратора

Проблема №1: Минимизация последовательностей действий администратора, в особенности по первоначальной настройке. Превращение последовательности действий в атомарную операцию.

Минимизация числа действий администратора.

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

Проблема состоит в том, что при первоначальной настройке компьютера администратору, пусть он даже достаточно квалифицированный специалист, необходимо проделать довольно большое количество различных действий. На примере ALT Linux установку можно разбить на 14 шагов, и в каждом необходимо отвечать на какие-то вопросы, и соответственно, если мыслить в категориях редактирования файлов --- то менять довольно большое количество различных файлов конфигурации. А если надо настроить не одну машину, а несколько, причём по-разному, то одновременная автоматическая установка невозможна. Учитывая, что чем большее количество манипуляций надо произвести, тем выше вероятность ошибки, было бы неплохо минимизировать количество действий. Это и есть первая проблема.

Минимизация действий администратора может быть двух разных видов:

• первоначальная настройка;
• ситуация, когда однократное действие требует изменения многих многих файлов, т.е. необходимо полное воспроизведение всей последовательности действий.

Отсюда возникает требование превращения множества действий в атомарную операцию. Существует некий порядок работ, связанных, например, с разворачиванием почтового сервера. Как минимум, для этого требуется установить пакет и настроить его --- то есть отредактировать некоторое число файлов конфигурации. В любом случае системный администратор с большим опытом, после того, как он обнаружит, что ему три-четыре раза пришлось проделать одну и ту же последовательность действий, может написать сценарий на языке shell или языке Perl, который будет делать эту работу за него. Но для того, чтобы не разводить "зоопарк" мелких сценариев, каждый из которых производит какие-то мелкие действия, можно поступить по-другому --- добавить модуль к конфигуратору системы, который будет превращать последовательность фиксированных или параметризованных действий в, например, нажатие одной кнопки, что в случае опытного системного администратора равносильно запуску одного скрипта. В дальнейшем мы рассмотрим, как эта задача решается в ALT Linux.

Работа оператора ЭВМ (неквалифицированного человека, отвечающего за машину).

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

• первая --- это так называемый системный администратор, как его начали понимать с момента внедрения системы Windows, когда системное администрирование --- это систематическое выполнение последовательности действий "согласно предписаниям" и регулярная переустановка ОС в местах её "падения". Это можно назвать задачами повседневного администрирования (задачи, которые необходимо выполнять изо дня в день дня в день, и было бы очень неплохо, если они не были завязаны на повседневные навыки выполняющих). 30 лет назад задачами повседневного администрирования были: подать нужную ленту на нужное устройство, чтобы сделать резервное копирование, вкл/выкл, профилактический просмотр различных составляющих машины. Нынче же задачи таких операторов очень сильно расширились. Например, необходимо, чтобы оператор, не имея достаточных знаний о том, какие файлы редактировать, мог добавлять/удалять пользователей системы. Откроем Alterator и посмотрим, что он умеет.

Здесь представлена область деятельности оператора, которая, вобщем-то, совпадает с набором действий, которые должен выполнить любой человек, устанавливая ОС на свою машину. Кстати сказать, этот человек отчасти тоже оператор ЭВМ. Соответственно,

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

Конфигуратор

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

• во-первых, согласно давней традиции, имеющейся в UNIX, а следом за ней и Linux, никакой унификации на структуру конфигурационных файлов и на то, где и как они располагаются, нет. Есть только соглашение, что они находятся в каталоге /etc/, хотя есть исключения; так, некоторые конфигурационные файлы располагаются в /var/lib.

• во-вторых, что более важно, --- ни в коем случае не рекомендуется (и в сообществе никто и не стремится) делать так, чтобы у всех конфигурационных файлов был единый синтаксис. Примеры различных конфигурационных файлов очевидны: есть файл passwd, который представляет собой строки, состоящие из полей, разделённых двоеточиями, есть конфигурационный файл сервера Apache, который использует синтаксис, схожий с SGML, есть некие службы, которые конфигурируются на языке XML с применением схем --- например, DE Gnome, и так далее. Если программа написана на shell, то и конфигурационный файл к ней обычно тоже написан на shell и представляет собой просто скрипт, который выполняется при запуске этой программы. Таким образом, в системе существует большое количество разнообразных синтаксисов, объединение которых считается нецелесообразным, поскольку в каждом случае решаются свои задачи и, соответственно, синтаксисы конфигурационных файлов заточены под конкретные решения. Это, как правило, не создает лишних трудностей системному администратору, для которого не проблема запомнить 6-7 разных синтаксисов или, что ещё более естественно, посмотреть документацию. Но это составляет существенную проблему, если мы хотим сделать обёртку, унифицированную по интерфейсу. К тому же, надо принимать во внимание не только содержание конфигурационных файлов, но и права доступа на эти файлы, состояние системы --- сервис, подвергающийся настройке, к примеру, может быть в данный момент запущен, а может быть остановлен.

Эти проблемы можно решить тремя способами:

1. решить в лоб, то есть, договориться о том, как должен выглядеть GUI, и потом написать упрощённый редактор конфигурационного файла, который производил бы свёртку множества действий в атомарную операцию для одного или нескольких файлов. Например, вместо редактирования ряда файлов в /etc/net (как было описано ранее) мы бы запустили специальную программу, которая называлась бы "Сетевые профили" и считала бы все необходимые файлы, сформировала правильный вид и позволила бы нам менять с ее помощью нужные параметры.

   • Недостатки этого подхода:
     • если взять все графические конфигурационные утилиты разных подсистем и собрать их вместе, то мы получаем решение лишь первой проблемы --- минимизации действий. Система остается не менее запутанной и непонятной обычному пользователю, так как вместо набора разнородных конфигурационных файлов мы получим набор не менее разнородных утилит.
     • Довольно тяжело обеспечить полное покрытие всех проблем. Это сделать можно, но это требует взаимодействия между всеми людьми, занимающимися этими утилитами. Более того, часто подобные утилиты разрабатываются не под задачу, а под решение.
     • Проблема синхронизации пространства имён --- многие данные запрашиваются во многих модулях повторно, и тем самым увеличивается возможность ошибки, когда те же данные неправильно введённые в другом модуле перечеркивают правильные введённые раньше.
   • Достоинства:
     • Лёгкость сопровождения --- при изменении формата конфигурационного файла можно легко поменять и формат утилиты, oсобенно когда утилита настроена не на задачу, а на решение.

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