Различия между версиями 5 и 7 (по 2 версиям)
Версия 5 от 2008-08-08 14:12:37
Размер: 12020
Редактор: DmitryChistikov
Комментарий:
Версия 7 от 2008-08-08 14:48:52
Размер: 11984
Редактор: DmitryChistikov
Комментарий:
Удаления помечены так. Добавления помечены так.
Строка 28: Строка 28:
Чтобы понять, почему загрузка системы устроена именно так, вспомним некоторые факты из истории. Существующая система инициализации, называемая также System V init, была написана очень давно, еще во времена коммерческого UNIX. Создатели UNIX --- Кен Томпсон (Ken Thompson) и Деннис Ритчи (Dennis Ritchie) --- еще ранее работали над операционной системой MULTICS, спроектированной в соответствии с заказом военных ведомств. В ОС MULTICS существовала следующая хитрая схема разделения на "уровни доступа": Чтобы понять, почему загрузка системы устроена именно так, вспомним некоторые факты из истории. Существующая схема, называемая также System V init, была написана очень давно, еще во времена коммерческого UNIX. Создатели UNIX --- Кен Томпсон (Ken Thompson) и Деннис Ритчи (Dennis Ritchie) --- еще ранее работали над операционной системой MULTICS, спроектированной в соответствии с заказом военных ведомств. В ОС MULTICS существовала следующая хитрая схема разделения на "уровни доступа":
Строка 46: Строка 46:
Заметим, что такая архитектура позволяла организовать следующую схему. На первом уровне можно было запускать некоторые "системные" службы, на втором --- добавлять к ним службы, различающие пользователей, на третьем --- службы, организующие доступ пользователей из сети. Так устоялась традиция разделения на однопользовательский режим, многопользовательский режим и многопользовательский режим с сетью, которые соответствуют 1-му, 2-му и 3-му уровням выполнения. В настоящее время описанная модель потеряла практический смысл (реализация различных схем определения прав доступа может определяться, к примеру, подсистемой SELinux), а потому соответствующая часть процесса загрузки (System V init) стала восприниматься отчасти как legacy. Заметим, что такая архитектура позволяла организовать следующую схему. На первом уровне можно было запускать некоторые "системные" службы, на втором --- добавлять к ним службы, различающие пользователей, на третьем --- службы, организующие доступ пользователей из сети. Так устоялась традиция разделения на однопользовательский режим, многопользовательский режим и многопользовательский режим с сетью, которые соответствуют 1-му, 2-му и 3-му уровням выполнения. В настоящее время описанная модель потеряла практический смысл (реализация различных схем определения прав доступа может определяться, к примеру, с помощью SELinux), а потому соответствующая часть процесса загрузки (System V init) стала восприниматься отчасти как legacy.
Строка 54: Строка 54:
|| 41 || 1 || 1 || 1 || || 1 || ConstantinYershow, DmitryChistikov, VsevolodKrishchenko || || || || 43 || 1 || 1 || 1 || || 1 || ConstantinYershow, DmitryChistikov, VsevolodKrishchenko || || ||

Уровни выполнения

Поговорим немного об уровнях выполнения. Уровень выполнения представляет собой специальную абстракцию, упоминаемую в /etc/inittab --- конфигурационном файле для первого запускаемого при загрузке системы процесса (он носит имя init). Изменять файл inittab приходится весьма нечасто, причем большинство изменений касаются только строки с параметром initdefault: в ней задается уровень выполнения по умолчанию. При этом можно сказать, что файл inittab лишь создает разделение на уровни выполнения: за конфигурацию набора запускаемых служб отвечает (в дистрибутивах ПСПО и многих других) утилита chkconfig.

Администратор системы может переключать систему с одного уровня выполнения на другой, выполняя команду init с единственным параметром --- номером нужного уровня. При переходе система определяет, какие службы должны быть запущены, а какие --- остановлены, производит собственно переключение и выполняет необходимые операции.

Сами уровни выполнения можно, хотя и с некоторой натяжкой, воспринимать как профили работы системы. Кроме того, к уровням выполнения причисляют также некоторые специальные действия:

  • уровень 0 --- полная остановка системы с выключением (если это возможно);
  • уровень 6 --- перезагрузка, то есть остановка и загрузка заново (на уровень по умолчанию).

Что касается других уровней, то чаще всего они используются так:

  • уровень 1 --- однопользовательский режим работы;
  • уровень 2 --- многопользовательский режим без сети;
  • уровень 3 --- многопользовательский режим с сетью.

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

  • уровень 5 --- многопользовательский режим с сетью и графическим интерфейсом.

Отметим, что в дистрибутивах ПСПО дополнительно выполняется еще одно соответствие:

  • уровень 7 --- работа инсталлятора.

Обратим внимание на то, что организованная таким способом система довольно неудобна. Уровни выполнения уже давно не проходятся подряд: не происходит загрузки на первый уровень с последующим переключением на второй, третий и далее до нужного. Фактически, разрешен непосредственный переход с любого уровня выполнения на любой другой --- иными словами, само слово "уровень" потеряло в данной схеме свое значение. Почему уровней выполнения (по сути дела --- профилей работы системы) существует столько, сколько сейчас --- вопрос традиции, а не удобства. В BSD-системах при этом существуют (по сути дела) только два уровня выполнения: однопользовательский и штатный.

Чтобы понять, почему загрузка системы устроена именно так, вспомним некоторые факты из истории. Существующая схема, называемая также System V init, была написана очень давно, еще во времена коммерческого UNIX. Создатели UNIX --- Кен Томпсон (Ken Thompson) и Деннис Ритчи (Dennis Ritchie) --- еще ранее работали над операционной системой MULTICS, спроектированной в соответствии с заказом военных ведомств. В ОС MULTICS существовала следующая хитрая схема разделения на "уровни доступа":

  • Первый уровень доступа к системе определялся следующим образом. Каждый сеанс доступа к данным управлялся одним и тем же субъектом --- ясно, что с данными этот субъект мог делать все, что ему заблагорассудится. Необходимости защищать данные от произвольного доступа, таким образом, не было, а от непроизвольного --- была: если в системе одновременно функционировали несколько процессов, они не должны были иметь возможности испортить данные друг друга.
  • При втором уровне доступа в системе могли работать сразу несколько субъектов одного класса. Эти субъекты составляли "команду" и потому не имели серьезных поражений в правах по сравнению друг с другом. Тем не менее, при такой схеме работал механизм защиты от произвольного доступа, представляющий по сути дела Access Control List (ACL).
  • Третий уровень доступа соответствовал работе в системе пользователей разных категорий. Условно говоря, подключенные к машине терминалы могли соответствовать пользователям одной категории, а соединения с системой по сети --- пользователям другой категории. Для каждой из таких категорий алгоритм определения прав доступа мог задаваться отдельно.

Классическая UNIX-система содержала следы этой запутанной политики:

  • Первый уровень доступа частично соответствовал однопользовательскому режиму, который давал монопольный доступ к консоли машины.
  • Второй уровень доступа частично соответствовал многопользовательскому режиму: сидящие за терминалами пользователи образовывали "команду".
  • Третий уровень доступа частично соответствовал подключению машины к сети.

Различные режимы работы в UNIX были названы уровнями выполнения, причем ни о какой гибкости реализации речи не шло. В ОС MULTICS права доступа на третьем уровне могли различаться даже алгоритмами определения: для одной категории --- ACL, для другой --- мандаты и пр. В UNIX это было сведено к некоторым упрощенным представлениям, уже не зависящим от уровня выполнения: на первое место вышла файловая система, пользователи и группы, причем вычисление прав доступа стало определяться в соответствии с жестким, заранее заданным алгоритмом. Возможность делать с системой все, что угодно, была привязана не к уровню выполнения, а к доверенному субъекту --- пользователю с идентификатором 0.

Заметим, что такая архитектура позволяла организовать следующую схему. На первом уровне можно было запускать некоторые "системные" службы, на втором --- добавлять к ним службы, различающие пользователей, на третьем --- службы, организующие доступ пользователей из сети. Так устоялась традиция разделения на однопользовательский режим, многопользовательский режим и многопользовательский режим с сетью, которые соответствуют 1-му, 2-му и 3-му уровням выполнения. В настоящее время описанная модель потеряла практический смысл (реализация различных схем определения прав доступа может определяться, к примеру, с помощью SELinux), а потому соответствующая часть процесса загрузки (System V init) стала восприниматься отчасти как legacy.


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

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

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

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

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

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

Level

Maintainer

Start date

End date

43

1

1

1

1

ConstantinYershow, DmitryChistikov, VsevolodKrishchenko


CategoryLectures CategoryPspo CategoryMpgu CategoryUneex

PspoClasses/080729/01RunLevels (последним исправлял пользователь VsevolodKrishchenko 2008-10-04 11:10:06)