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

Мы сегодня прощелкиваем весь альтератор в Линукс Мастер.

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

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

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

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

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

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

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

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

  1. Во первых согласно давней традиции, согласно имеющейся в UNIX, а следом за ним и Linux системе парадигме никакой унификации на структуру, на то, где и какие конфигурационные файлы располагаются, а также на унификации на их формат нету. Единственно есть разве что соглашение, что они лежат в /etc/, хотя есть исключения, когда некоторые конфигурационные файлы располагаться в /var/lib.
  2. Во-вторых, что на самом деле более важно, --- ни в коем случае не рекомендуется, и в сообществе никто особо и не стремиться делать так чтобы у всех конфигурационных файлов был единый синтаксис. Примеры различных конфигурационных файлов очевидны: есть файл passwd, который представляет собой строки , состоящие из полей , разделенных двоеточиями, есть конфигурационный файл сервера Apache, который использует синтаксис схожий с SGML, есть некие службы, которые конфигурируются на настоящем xml с применением schemas- например DE Gnome, и так далее. Если какая-то штука написана на shell, то и конфигурационный файл к ней обычно тоже написан на shell и представляет собой просто скрипт который выполняется при запуске программы. Таким образом в системе существует большое количество разнообразных синтаксисов, объединение которых считается нецелесообразным, поскольку в каждом случае решались свои задачи и синтаксисы заточены под конкретные решения. Это, как правило, не составляет никакой проблемы системному администратору, которому не проблема запомнить 6---7 синтаксисов или посмотреть документацию. Но это составляет существенную проблему если мы хотим сделать обёртку, которая с другого конца унифицирована. К тому же, надо принимать во внимание не только содержание конфигурационных файлов, но и права доступа на эти файлы, состояние системы- сервис может быть запущен, а может быть остановлен. <Можно сослаться на статью на конф. на Протве- (eSyr?) . Можно. Каким образом?- ArtemSerebriyskiy>

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

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

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


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

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

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

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

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

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

Level

Maintainer

Start date

End date

19

1

1

1

1

ArtemSerebriyskiy, GeorgeTarasov