10978
Комментарий:
|
11977
|
Удаления помечены так. | Добавления помечены так. |
Строка 3: | Строка 3: |
Поговорим немного об уровнях выполнения. Вообще, это некоторая абстракция, упоминаемая в конфигурационном файле для init --- inittab. В inittab редко приходится менять что-либо, за единственным возможным исключением --- в строке с initdefault выставляется уровень выполнения по умолчанию. В inittab задается разделение на уровни выполнения; реально же запускаемые при старте системы службы определяются командой chkconfig. | Поговорим немного об уровнях выполнения. Уровень выполнения представляет собой специальную абстракцию, упоминаемую в /etc/inittab --- конфигурационном файле для первого запускаемого при загрузке системы процесса (он носит имя init). Изменять файл inittab приходится весьма нечасто, причем большинство изменений касаются только строки с параметром initdefault: в ней задается уровень выполнения по умолчанию. При этом можно сказать, что файл inittab лишь создает разделение на уровни выполнения: за конфигурацию набора запускаемых служб отвечает (в дистрибутивах ПСПО и многих других) утилита chkconfig. |
Строка 5: | Строка 5: |
При переходе с одного уровня выполнения на другой система производит следующие действия. Определяется, какие службы должны быть запущены, а какие --- остановлены (по сравнению с наличествующей картиной), после чего выполняется собственно переключение. Администратор системы может переключать систему с одного уровня выполнения на другой, выполняя команду init с единственным параметром --- номером нужного уровня. | Администратор системы может переключать систему с одного уровня выполнения на другой, выполняя команду init с единственным параметром --- номером нужного уровня. При переходе система определяет, какие службы должны быть запущены, а какие --- остановлены, выполняет необходимые операции и производит собственно переключение. |
Строка 7: | Строка 7: |
Уровни выполнения, таким образом, можно, хотя и с некоторой натяжкой, воспринимать как профили работы одной и той же системы. Исторически сложилось так, что уровень 0 соответствует полной остановке системы с выключением, а уровень 6 --- перезагрузке (остановка и загрузка заново, на уровень по умолчанию). Что касается остальных уровней, то по традиции уровень 1 --- это однопользовательский режим работы, уровень 2 --- многопользовательский режим без сети, уровень 3 --- многопользовательский режим с сетью. Поведение системы на других уровнях выполнения не специфицируется, однако считается, что уровень 5 --- это многопользовательский режим с сетью и графическим интерфейсом. В дистрибутивах ПСПО уровень 7 соответствует работе инсталлятора. | Сами уровни выполнения можно, хотя и с некоторой натяжкой, воспринимать как профили работы одной и той же системы. Тем не менее, к уровням выполнения причисляют также некоторые специальные действия: |
Строка 9: | Строка 9: |
Обратим внимание на то, что таким образом устроенная система уровней выполнения довольно неудобна. Уровни выполнения уже давно не проходятся подряд: не происходит загрузки на первый уровень с переключением на второй, третий и так до нужного. Фактически, разрешен непосредственный переход с любого уровня выполнения на любой другой. Иными словами, само слово "уровень" потеряло в данной схеме свое значение. Почему уровней выполнения (по сути дела --- профилей работы системы) существует столько, сколько сейчас --- вопрос традиции, а не удобства. В BSD-системах, заметим, по сути есть только два уровня выполнения: однопользовательский и штатный. | * уровень 0 --- полная остановка системы с выключением (если это возможно); * уровень 6 --- перезагрузка, то есть остановка и загрузка заново (на уровень по умолчанию). |
Строка 11: | Строка 12: |
Чтобы понять, почему загрузка системы организована именно так, вспомним некоторые факты из истории. Система init была написана примерно очень давно, еще во времена коммерческого UNIX. Создатели UNIX --- Кен Томпсон и Деннис Ритчи --- работали также над ОС MULTICS по заказу военных ведомств. Разделение доступа в MULTICS проходило по довольно хитрым алгоритмам: | Что касается других уровней, то чаще всего они используются так: |
Строка 13: | Строка 14: |
* В некоторое время система могла работать по следующему принципу: во время каждого сеанса доступа к данным есть только один субъект. Понятно, что если субъект только один, то с данными он может делать все, что ему заблагорассудится. Необходимости защищать данные от произвольного доступа, таким образом, нет, а вот от непроизвольного доступа --- есть: если в системе одновременно функционирует несколько процессов, они не должны иметь возможность испортить данные друг друга. | * уровень 1 --- однопользовательский режим работы; * уровень 2 --- многопользовательский режим без сети; * уровень 3 --- многопользовательский режим с сетью. |
Строка 15: | Строка 18: |
* При другой схеме функционирования в системе могли работать сразу несколько субъектов одного класса. Эти субъекты составляли "команду" и потому не имели серьезных поражений в правах по сравнению друг с другом. Тем не менее, при такой схеме работал механизм защиты от произвольного доступа --- подобный ACL. | Списка всех уровней это, однако, не исчерпывает. Поведение системы на оставшихся уровнях выполнения устоялось еще хуже, хотя можно отметить используемое еще одно соглашение, используемое в большинстве систем: |
Строка 17: | Строка 20: |
* Еще более сложная схема соответствовала работе в системе пользователей разных категорий. Условно говоря, подключенные к машине терминалы могли соответствовать пользователям одной категории, а соединения с системой по сети --- пользователям другой категории. Для каждой из таких категорий алгоритм определения прав доступа мог задаваться отдельно. | * уровень 5 --- многопользовательский режим с сетью и графическим интерфейсом. Отметим, что в дистрибутивах ПСПО дополнительно выполняется еще одно правило: * уровень 7 --- работа инсталлятора. Обратим внимание на то, что организованная таким способом система довольно неудобна. Уровни выполнения уже давно не проходятся подряд: не происходит загрузки на первый уровень с переключением на второй, третий и далее до нужного. Фактически, разрешен непосредственный переход с любого уровня выполнения на любой другой --- иными словами, само слово "уровень" потеряло в данной схеме свое значение. Почему уровней выполнения (по сути дела --- профилей работы системы) существует столько, сколько сейчас --- вопрос традиции, а не удобства. В BSD-системах при этом существуют (по сути дела) только два уровня выполнения: однопользовательский и штатный. Чтобы понять, почему загрузка системы организована именно так, вспомним некоторые факты из истории. Существующая система инициализации, называемая также System V init, была написана очень давно, еще во времена коммерческого UNIX. Создатели UNIX --- Кен Томпсон и Деннис Ритчи --- еще ранее работали над операционной системой MULTICS, спроектированной в соответствии с заказом военных ведомств. В ОС MULTICS существовала следующая хитрая схема разделения на "уровни доступа": * Первый уровень доступа к системе определялся следующим образом. Каждый сеанс доступа к данным управлялся одним и тем же субъектом --- ясно, что с данными этот субъект мог делать все, что ему заблагорассудится. Необходимости защищать данные от произвольного доступа, таким образом, не было, а от непроизвольного --- была: если в системе одновременно функционировали несколько процессов, они не должны были иметь возможности испортить данные друг друга. * При втором уровне доступа в системе могли работать сразу несколько субъектов одного класса. Эти субъекты составляли "команду" и потому не имели серьезных поражений в правах по сравнению друг с другом. Тем не менее, при такой схеме работал механизм защиты от произвольного доступа, представляющий по сути дела Access Control List (ACL). * Третий уровень доступа соответствовал работе в системе пользователей разных категорий. Условно говоря, подключенные к машине терминалы могли соответствовать пользователям одной категории, а соединения с системой по сети --- пользователям другой категории. Для каждой из таких категорий алгоритм определения прав доступа мог задаваться отдельно. |
Строка 21: | Строка 38: |
* Первый уровень доступа частично соответствовал однопользовательскому режиму: это монопольный доступ к консоли машины. | * Первый уровень доступа частично соответствовал однопользовательскому режиму, который давал монопольный доступ к консоли машины. |
Строка 27: | Строка 44: |
Разумеется, ни о какой гибкости реализации этих механизмов речи не шло. В идеале, права доступа на третьем уровне могли различаться даже алгоритмами определения: для одной категории --- ACL, для другой --- мандаты и пр. В UNIX это было сведено к некоторым упрощенным представлениям, уже не зависящим от уровня выполнения: есть файловая система, пользователи и группы, причем вычисление прав доступа определяется в соответствии с жестким, заранее заданным алгоритмом. Возможность делать с системой все, что угодно, была привязана не к уровню выполнения, а к доверенному субъекту --- пользователю с идентификатором 0. | Различные режимы работы в UNIX были названы уровнями выполнения, причем ни о какой гибкости реализации речи не шло. В ОС MULTICS права доступа на третьем уровне могли различаться даже алгоритмами определения: для одной категории --- ACL, для другой --- мандаты и пр. В UNIX это было сведено к некоторым упрощенным представлениям, уже не зависящим от уровня выполнения: на первое место вышла файловая система, пользователи и группы, причем вычисление прав доступа стало определяться в соответствии с жестким, заранее заданным алгоритмом. Возможность делать с системой все, что угодно, была привязана не к уровню выполнения, а к доверенному субъекту --- пользователю с идентификатором 0. |
Строка 29: | Строка 46: |
Заметим, что такая архитектура позволяла организовать следующую схему. На первом уровне можно было запускать некоторые "системные" службы, на втором --- добавлять к ним службы, различающие пользователей, на третьем --- службы, организующие доступ пользователей из сети. Так устоялась традиция разделения на однопользовательский режим, многопользовательский режим и многопользовательский режим с сетью, которые соответствуют 1-му, 2-му и 3-му уровням выполнения. В настоящее время описанная модель потеряла практический смысл (реализация различных схем определения прав доступа может определяться, к примеру, подсистемой SELinux), а потому соответствующая схема работы (System V init) воспринимается как legacy. | Заметим, что такая архитектура позволяла организовать следующую схему. На первом уровне можно было запускать некоторые "системные" службы, на втором --- добавлять к ним службы, различающие пользователей, на третьем --- службы, организующие доступ пользователей из сети. Так устоялась традиция разделения на однопользовательский режим, многопользовательский режим и многопользовательский режим с сетью, которые соответствуют 1-му, 2-му и 3-му уровням выполнения. В настоящее время описанная модель потеряла практический смысл (реализация различных схем определения прав доступа может определяться, к примеру, подсистемой SELinux), а потому соответствующая часть процесса загрузки (System V init) стала восприниматься как legacy. |
Строка 37: | Строка 54: |
|| 35 || 1 || 1 || 1 || || 1 || ConstantinYershow, DmitryChistikov, VsevolodKrishchenko || || || | || 40 || 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 --- Кен Томпсон и Деннис Ритчи --- еще ранее работали над операционной системой 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 |
40 |
1 |
1 |
1 |
|
1 |
|
|