Различия между версиями 4 и 5
Версия 4 от 2008-07-04 21:02:12
Размер: 10620
Редактор: eSyr
Комментарий:
Версия 5 от 2008-07-05 00:17:55
Размер: 19725
Редактор: ArtemSerebriyskiy
Комментарий:
Удаления помечены так. Добавления помечены так.
Строка 3: Строка 3:
Мы сегодня прщёлкиваем весь альтератор в Линукс Мастер. Мы сегодня прощелкиваем весь альтератор в Линукс Мастер.
Строка 5: Строка 5:
##Возможно, это стоит перенести в предыдущую лекцию
Мы вчера и позавчера управляли сетью из командной строки. Давайте практически докажем те слова, который в прошлый раз были высказаны теоретически относительн etcnet и профилей. Создадим настройки специально для здешнего заведения. Для этог нужно три вещи.
##Возможно, это стоит перенести в предыдущую лекцию Мы вчера и позавчера управляли сетью из командной строки. Давайте
практически докажем те слова, который в прошлый раз были  высказаны теоретически относительно etcnet и профилей. Создадим
настройки специально для здешнего заведения.
Для этого нужно три вещи.  
Строка 8: Строка 10:
 * Создаём файл options#mpgu. Пишем:  * Создаём файл options#mpgu.
Пишем:
Строка 20: Строка 23:
 * service network restartwith mpgu * service network
restartwith mpgu
Строка 22: Строка 26:
Мы вчера понастраивали сеть руками. Позавчера это делали свсем руками, и выяснили, что это муторне дело. Вчера было сказано, что компьютер автоматически настраивается, если вписать в /etc/net соответствующие значения. Но есть ещё дна задача, которая не очень удобно решается и не каждый её мжет решить. Задача связана с нач. настройкой или перенастройкой. Проблема состоит в том, что при первоначальной настройке компьютера администратору, пусть н даже будь квалифиц., необх. произвести довольно большое количество различных действий. А представьте, если надо настрить не одну машину, а несколько. В связи с этим неплохо было бы миним. кол-во действий. Это первая проблема. Минимизация последовательностей действий администратора, в особеннсти по первоначальной настройке. === Проблема №1 Минимизация последовательностей действий администратора, в особенности по первоначальной настройке. Превращение последовательности действий в атомарную операцию. ===
Строка 24: Строка 28:
Вторая проблема состоит в том, когда с действиями администратора должен справиться не чень квалиф. человек. В советское время такой человек назывался оператором. Есму необх. решать задачи пвседневного администрирования (задачи, к-рые необх. вып. из дня в день). Какие задачи были день назад: засунуть нужную ленточку, чтобы сделался бэкап. Вкл/выкл, профилактический просмотр закромов. Нынче же задачи операторов расширились. Например, чтобы человек мог добавлять/удалять пользователей. Прошлые две лекции были посвящены настройке сети руками. В позапрошлой лекции это было сделано совсем ручным способом, и
как видно это представляет собой весьма непростое дело, не говоря уж о том что компьютер настраивается каждый раз когда он
включается. Вчера было показано, что на самом деле компьютер конечно настраивается автоматически, в том смысле что
существуют конфигурационные файлы, в которые вписываются необходимые значения, и при старте они считываются и
используются. Но есть ещё одна задача, которая с одной стороны все еще не очень удобно решается, а с другой стороны не
всякий человек может её решить. Задача связана с начальной настройкой системы, в частности при её установке или
перенастройкой компьютера в том случае если например меняются внешние параметры(месторасположение и т.п.). Проблема
состоит в том, что при первоначальной настройке компьютера администратору, пусть он даже достаточно квалифицированный
администратор необходимо проделать довольно большое количество различных действий. На примере Альт-Линукса установку
можно разбить на 14 шагов и в каждом необходимо отвечать на какие-то вопросы, и соответственно, если мыслить в категориях
редактирования файлов- то редактировать довольно большое их количество. А представьте, если надо настроить не одну машину,
а несколько, причем по-разному сконфигурированных и поэтому автоматическая установка невозможна. Учитывая, что чем большее
количество манипуляций надо произвести, тем выше вероятность ошибки, было бы неплохо минимизировать количество действий.
Это первая проблема.
Строка 26: Строка 43:
Откроем альтератор, посмотрим, чт он умеет. Здесь достаточно разумно представлена область действия оператора, которая совп. с набором действий, которые должен выполнить любой человек, устанавливая ОС на свою машину. Минимизация действий администратора может быть двух разных видов: либо первоначальная настройка либо ситуация когда
однократное действие требует изменения многих многих файлов, и надо всю эту последовательность действий не забыть.
Отсюда возникает требование превращения множества действий в атомарную операцию. Существует некий порядок работ, связанных
например с разворачиванием почтового сервера. Как минимум, для этого требуется установить пакет и настроить его- поправить
один файл, другой, третий, четвертый. В любом случае системный администратор с большим опытом, после того как он
обнаружит что ему три-четыре раза пришлось проделать одну и туже последовательность действий, может написать сценарий на
языке shell или языке Perl, который будет делать эту работу за него. Но для того чтобы не разводить зоопарк мелких
сценариев на языке shell каждый из которых работает под разными условиями, можно поступить по-другому --- можно добавить
модуль к конфигуратору системы, который будет превращать последовательность фиксированных или параметризованных действий
в например нажатие одной кнопки, что в случае опытного системного администратора равносильно запуску одного скрипта. В
дальнейшем мы рассмотрим как это решается в Альт-Линуксе.
Строка 28: Строка 55:
Вторая роль, которая сводится к роли оператора -- роль хозяина персональной эвм. Ибо в случае тачки на рабте всё это делает администратор, а на домашней машине приходиться расчитывать только на себя.

Есть ещё третий... минимизация действий даминистратора может быть двух разных видов: нач. настройка или некая действие требует измю многих файлов, и необх. эту посл. действий не забыть. Превращение множества действий в атомарную операцию. Существует некий порядк рабт, связанных с разворачиванием почтового сервера. Как минимум, для этого требуентся установить пакет и настроить его. Как минимум, сис. админ. с опытом, которму пришлось делать эт в 3---4 раз, может написать сценарий на языке шелл или перл, кторый делает это за него. Чтобы не плоджить зоопарк, можно добавить моудль в настройщик, который будет делать то же самое.
=== Проблема №2 Работа оператора ЭВМ(неквалифицированного человека отвечающего за машину) ===
Вторая проблема состоит в том, когда с действиями администратора должен справиться не достаточно квалифицированный
человек. В советское время когда компьютеры были большие, микросхемы тоже большие, а объемы памяти- маленькими, такой
человек назывался оператором. В наше время под оператором можно понимать две роли:
 * Первая- это так называемый системный администратор, как его начали понимать с момента внедрения системы Windows(r), когда системное администрирование- это всего лишь выполнение последовательности действий по бумажке и регулярная перестановка системы по всюду где она свалилась. Это можно назвать задачами повседневного администрирования (задачи, которые необходимо выполнять изо дня в день дня в день и было бы очень не плохо чтобы они не были завязаны на повседневные навыки выполняющих).30 лет назад задачами повседневного администрирования были: подать нужную ленточку на нужное устройство , чтобы сделать резервное копирование, вкл/выкл, профилактический просмотр различных составляющих машины. Нынче же задачи таких операторов очень сильно расширились. Например, хочется чтобы человек, не имея достаточных знаний о том какие файлы редактировать, мог добавлять/удалять пользователей системы.
 Откроем альтератор и посмотрим, что он умеет. <Screenshot is vitally nesesary>. Здесь достаточно разумно представлена область деятельности оператора, которая кстати совпадает с набором действий, которые должен выполнить любой человек, устанавливая ОС на свою машину. Кстати сказать этот человек отчасти тоже оператор ЭВМ и это
 * Вторая роль, которая сводится к роли оператора -- роль хозяина персональной ЭВМ.Если ваш компьютер находится у вас на работе, то все это будет делать специальный человек,а на домашней машине за вас это никто не сделает, и вам придется вырабатывать некие навыки по управлению системой в режиме "недостатка информации". В идеале эта проблема должна быть исключена и любой пользователь должен быть технически грамотным, И Linux для этого отлично предназначен, как весьма познаваемая система, но недостаток информации может проистекать исключительно от недостатка времени- например человек мало использует машину --- буквально 10-15 функций и ради этого изучать все устройство нерационально.
Строка 33: Строка 64:
Относительно того, как устроен конфигуратор в лаьте. В чём проблема кнфигуратора как таковго. У нас есть некое множество точек возд. на систему (условно говоря, конф. файлы и база данных), которые для произ. этих самых конф. действий надо изменить. При чём надо понимать, что человек, который польз. конф., не обладает всей полнотой информации, он не обязан знать всё, что происх на самом деле при вып. макрооперации. Дело в том, что согл. давней традиции, никакой унификации на тсруктуру, на то, где и какие конф. файлы расп, а также на униф. формата нет, есть разве что соглашение, что они лежат в /etc/. Второе --- ни в каком слусе не реком, и сообщ. не приветствуется, чтобы у всех был один синтаксис. Примеры очевидны: есть файл passwd, есть конфиг апача, который похож на html, есть службы, которые конфигурируются на настоящем xml'е, и так далее. Если какая-то штука написана на шелле, то и конфиг к ней обычно тоже на шелле. В сист. сущ. большое кол-в разнооб. синтаксисов, объед которых считается нецелесооб., поск. в каждом случае решались свои задачи. Это, как правило, не сост. никакой проблемы сисадмину, которому не проблема запомнить 6---7 синтаксисов или посмотреть ман. Но эт составляет проблему при написании обёртки. К тму же, надо принимать во внимание не толдько содерж. конфигов, но и права доступа, сост. системы. Можно сослаться на статью на конф. на Протве. Дело состит в том, что проблемы эи можно поробовать решить в лоб, то есть, договориться о том, как должен выглядить гуи, и потом просто писать упрощённый редактор конф. файла, который производи свёртку множества действий в атом. операцию для одного или неск. файлов. Например, вместо редактирования ряда файлов в /etc/net, мы бы запустили модуль "Сетевые интерфейсы", который бы прочитал содерж. етцнет, сформировал бы гуи и в нём можно было бы работать. Пробелма вот в чём: когда мы сваливаем все эти конфигураторы в одну кучу, мы получаем систему ничкть не проще, единственное, что получаем --- минимизация действий, но легче её пользоваться не станвится. Кроме того, не легче будет, елси одни и те же вещи могут по-разному. В итоге мы получим вместо набора разнородных конф. файлов поллучим набор разнородных утилит. Это первый подход. === Конфигуратор ===
Строка 35: Строка 66:
В чём проблема конфигуратора как такового? У нас есть некое множество точек воздействия на систему (условно говоря,
системные конфигурационные файлы, хотя могут быть даже некие база данных), которые для произведения пресловутых
конфигурационных действий надо изменить. При чём надо понимать,что мы работаем в предположении что пользователь
конфигуратора не обладает всей полнотой информации, он не обязан знать всё, что происходит на самом деле при выполнении
макрооперации.
 1. Во первых согласно давней традиции, согласно имеющейся в UNIX, а следом за ним и Linux системе парадигме никакой
унификации на структуру, на то, где и какие конфигурационные файлы располагаются, а также на унификации на их формат
нету. Единственно есть разве что соглашение, что они лежат в /etc/, хотя есть исключения когда некоторые конфигурационные
файлы располагаться в /var/lib.
 2. Во-вторых, что на самом деле более важно, --- ни в коем случае не рекомендуется, и в сообществе никто особо и не
стремиться делать так чтобы у всех конфигурационных файлов был единый синтаксис. Примеры различных конфигурационных файлов
очевидны: есть файл passwd, который представляет собой строки , состоящие из полей , разделенных двоеточиями, есть
конфигурационный файл сервера Apache, который использует синтаксис схожий с SGML, есть некие службы, которые
конфигурируются на настоящем xml с применением schemas- например DE Gnome, и так далее. Если какая-то штука написана на
shell, то и конфигурационный файл к ней обычно тоже написан на shell и представляет собой просто скрипт который
выполняется при запуске программы. Таким образом в системе существует большое количество разнообразных синтаксисов,
объединение которых считается нецелесообразным, поскольку в каждом случае решались свои задачи и синтаксисы заточены под
конкретные решения. Это, как правило, не составляет никакой проблемы системному администратору, которому не проблема
запомнить 6---7 синтаксисов или посмотреть документацию. Но это составляет существенную проблему если мы хотим сделать
обёртку, которая с другого конца унифицирована. К тому же, надо принимать во внимание не только содержание конфигурационных файлов, но
и права доступа на эти файлы, состояние системы- сервис может быть запущен, а может быть остановлен. <Можно сослаться на
статью на конф. на Протве-eSyr. Можно. Каким образом- ArtemSerebriyskiy>
Проблемы эти можно решить тремя способами:
 1. Решить в лоб, то есть, договориться о том, как должен выглядеть GUI, и потом просто писать упрощённый редактор конфигурационного файла, который производил бы свёртку множества действий в атомарную операцию для одного или нескольких файлов. Например, вместо редактирования ряда файлов в /etc/net<В случае разумного переноса первой части лекции в прошлую лекции надо каким-то образом поставить кросс-ссылку>, мы бы запустили специальную программу которая называться "Сетевые профили", которая бы прочитала все необходимые файлы, сформировала бы правильный вид и мы туда писали бы какие-то значения.
 * Недостатки
  * Если взять все графические конфигурационные утилиты разных подсистем и собрать их вместе то мы получаем решение лишь первой проблемы- минимизации действий. Система остается не менее запутанной и непонятной обычному пользователя. Т.е. вместо набора разнородных конфигурационных файлов получаем набор не менее разнородных утилит.
  * Довольно тяжело обеспечить полное покрытие всех проблем. Это сделать можно, но это требует взаимодействия между всеми людьми занимающимися этими утилитами. Более того часто подобные утилиты разрабатываются не под задачу, а под решение.
  * Проблема синхронизации пространства имен- многие данные запрашиваются во многих модулях повторно, и тем самым
   увеличивается возможность ошибки, когда те же данные неправильно введенные в другом модуле перечеркивают
   правильные введенные раньше.
 * Достоинства
  * Легкость сопровождения- при изменении формата конфигурационного файла можно легко поменять и формат утилиты. Особенно когда утилита настроена не на задачу, а на решение.
Строка 41: Строка 104:
|| 0 || 1 || 1 || 1 || || 1 || ArtemSerebriyskiy, GeorgeTarasov || || || || 19 || 1 || 1 || 1 || || 1 || ArtemSerebriyskiy, GeorgeTarasov || || ||

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

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

практически докажем те слова, который в прошлый раз были высказаны теоретически относительно etcnet и профилей. Создадим настройки специально для здешнего заведения. Для этого нужно три вещи.

  • Переходим в /etc/net/
  • Создаём файл options#mpgu.

Пишем:

ONBOOT=yes
DISABLED=no
BOOTPROTO=static
  • mv ipv4address ipv4address\#mpgu
  • Написать туда

search mpgu.edu.ru
nameserver 194.190.241.162

* service network restartwith mpgu

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

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

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

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

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

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

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

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

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

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

  1. Во первых согласно давней традиции, согласно имеющейся в UNIX, а следом за ним и Linux системе парадигме никакой

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

  1. Во-вторых, что на самом деле более важно, --- ни в коем случае не рекомендуется, и в сообществе никто особо и не

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

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

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


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

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

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

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

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

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

Level

Maintainer

Start date

End date

19

1

1

1

1

ArtemSerebriyskiy, GeorgeTarasov


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