Различия между версиями 11 и 12
Версия 11 от 2008-07-05 19:16:11
Размер: 19074
Редактор: ArtemSerebriyskiy
Комментарий:
Версия 12 от 2008-07-05 19:17:34
Размер: 19074
Редактор: ArtemSerebriyskiy
Комментарий:
Удаления помечены так. Добавления помечены так.
Строка 70: Строка 70:
|| 20 || 1 || 1 || 1 || || 1 || ArtemSerebriyskiy, GeorgeTarasov || || || || 15 || 1 || 1 || 1 || || 1 || ArtemSerebriyskiy, GeorgeTarasov || || ||

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

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

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

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

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

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

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

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

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

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

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

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

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

  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

15

1

1

1

1

ArtemSerebriyskiy, GeorgeTarasov


PspoClasses/080704/01ConfigTheory (последним исправлял пользователь MaximByshevskiKonopko 2008-10-09 21:13:51)