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

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

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

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

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

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

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

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

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

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

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

../alterator_expanded.png

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

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

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

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

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

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


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

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

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

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

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

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

Level

Maintainer

Start date

End date

90

1

1

1

1

ArtemSerebriyskiy, GeorgeTarasov, MaximByshevskiKonopko


PspoClasses/080704/01ConfigTheory (last edited 2008-10-09 18:13:51 by MaximByshevskiKonopko)