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

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

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

ONBOOT=yes
DISABLED=no
BOOTPROTO=static

search mpgu.edu.ru
nameserver 194.190.241.162

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

Вторая проблема состоит в том, когда с действиями администратора должен справиться не чень квалиф. человек. В советское время такой человек назывался оператором. Есму необх. решать задачи пвседневного администрирования (задачи, к-рые необх. вып. из дня в день). Какие задачи были день назад: засунуть нужную ленточку, чтобы сделался бэкап. Вкл/выкл, профилактический просмотр закромов. Нынче же задачи операторов расширились. Например, чтобы человек мог добавлять/удалять пользователей.

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

Вторая роль, которая сводится к роли оператора -- роль хозяина персональной эвм. Ибо в случае тачки на рабте всё это делает администратор, а на домашней машине приходиться расчитывать только на себя.

Есть ещё третий... минимизация действий даминистратора может быть двух разных видов: нач. настройка или некая действие требует измю многих файлов, и необх. эту посл. действий не забыть. Превращение множества действий в атомарную операцию. Существует некий порядк рабт, связанных с разворачиванием почтового сервера. Как минимум, для этого требуентся установить пакет и настроить его. Как минимум, сис. админ. с опытом, которму пришлось делать эт в 3---4 раз, может написать сценарий на языке шелл или перл, кторый делает это за него. Чтобы не плоджить зоопарк, можно добавить моудль в настройщик, который будет делать то же самое.

Относительно того, как устроен конфигуратор в лаьте. В чём проблема кнфигуратора как таковго. У нас есть некое множество точек возд. на систему (условно говоря, конф. файлы и база данных), которые для произ. этих самых конф. действий надо изменить. При чём надо понимать, что человек, который польз. конф., не обладает всей полнотой информации, он не обязан знать всё, что происх на самом деле при вып. макрооперации. Дело в том, что согл. давней традиции, никакой унификации на тсруктуру, на то, где и какие конф. файлы расп, а также на униф. формата нет, есть разве что соглашение, что они лежат в /etc/. Второе --- ни в каком слусе не реком, и сообщ. не приветствуется, чтобы у всех был один синтаксис. Примеры очевидны: есть файл passwd, есть конфиг апача, который похож на html, есть службы, которые конфигурируются на настоящем xml'е, и так далее. Если какая-то штука написана на шелле, то и конфиг к ней обычно тоже на шелле. В сист. сущ. большое кол-в разнооб. синтаксисов, объед которых считается нецелесооб., поск. в каждом случае решались свои задачи. Это, как правило, не сост. никакой проблемы сисадмину, которому не проблема запомнить 6---7 синтаксисов или посмотреть ман. Но эт составляет проблему при написании обёртки. К тму же, надо принимать во внимание не толдько содерж. конфигов, но и права доступа, сост. системы. Можно сослаться на статью на конф. на Протве. Дело состит в том, что проблемы эи можно поробовать решить в лоб, то есть, договориться о том, как должен выглядить гуи, и потом просто писать упрощённый редактор конф. файла, который производи свёртку множества действий в атом. операцию для одного или неск. файлов. Например, вместо редактирования ряда файлов в /etc/net, мы бы запустили модуль "Сетевые интерфейсы", который бы прочитал содерж. етцнет, сформировал бы гуи и в нём можно было бы работать. Пробелма вот в чём: когда мы сваливаем все эти конфигураторы в одну кучу, мы получаем систему ничкть не проще, единственное, что получаем --- минимизация действий, но легче её пользоваться не станвится. Кроме того, не легче будет, елси одни и те же вещи могут по-разному. В итоге мы получим вместо набора разнородных конф. файлов поллучим набор разнородных утилит. Это первый подход.


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

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

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

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

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

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

Level

Maintainer

Start date

End date

0

1

1

1

1

ArtemSerebriyskiy, GeorgeTarasov