|
Размер: 10356
Комментарий:
|
Размер: 13158
Комментарий:
|
| Удаления помечены так. | Добавления помечены так. |
| Строка 1: | Строка 1: |
| == Уровни выполнения == | == Уровни выполнения системы == |
| Строка 3: | Строка 3: |
| Посмотрим чень кратуий пересказ того, что такое урвни вып., более подробно см. учебник. Ур. вып. есть некая абстракция, которая упоминается в конф. фаыле init, inittab. Это такая штука замороченная, довольн старого фрмато, простой смертный там ничего менять не должен, за исключением, рпзве что умолчального уровня выполнения, который значится в полне init-default. | Поговорим немного об уровнях выполнения системы (англ. ''runlevel''). Уровень выполнения представляет собой специальную абстракцию, упоминаемую в файле {{{/etc/inittab}}}. Это конфигурационный файл для первого запускаемого при загрузке системы процесса, который носит имя {{{init}}}. Изменять данный файл приходится весьма нечасто, причем большинство изменений касаются только строки с параметром initdefault: в ней задается уровень выполнения по умолчанию. Файл {{{/etc/inittab}}} лишь создает разделение на уровни выполнения: за конфигурацию набора запускаемых на каждом уровне служб в дистрибутивах ПСПО отвечает утилита {{{chkconfig}}}. Она манипулирует со ссылками на службы, расположенными в каталогах вида {{{/etc/rc<уровень>.d}}}. Таким образом, команда {{{ $ ls -l /etc/rc0.d/ }}} покажет службы, выполнение которых затрагивает переход на уровень 0. |
| Строка 5: | Строка 9: |
| Там есть ещё мнго всякого интересного, какие ерм, склько консолей, там вообще описание процесса загрузки. | Администратор системы может переключать систему с одного уровня выполнения на другой, выполняя команду {{{init}}} с единственным параметром --- номером нужного уровня. При переходе система определяет, какие службы должны быть запущены, а какие --- остановлены, производит собственно переключение и выполняет необходимые операции. |
| Строка 7: | Строка 11: |
| В частности, в inittab неск. аз упоминаются урвни выполнения, в частности, дефолтный, и уровни выполнения, и скрипты, которые им соотв. | Сами уровни выполнения можно, хотя и с некоторой натяжкой, воспринимать как профили работы системы. Кроме того, к уровням выполнения причисляют также некоторые специальные действия: |
| Строка 9: | Строка 13: |
| Дальнейшее описание лектор откладывает на книжку, упомянет тольк что, так уж сложилось традиц., что переход с ур. вып на ур. вып. зн. прибивание всех прцессов, которые запущены на одном ур, и не должны быть щапущ на другом (в альте это уст. по chkconfig), но некая ид. модель ур. вып. состоит в том, чт прибивает одни службы и запускает другие. | * уровень 0 --- полная остановка системы с выключением (если это возможно); * уровень 6 --- перезагрузка, то есть остановка и загрузка заново (на уровень по умолчанию). |
| Строка 11: | Строка 16: |
| В действ всё происх. не так, как на самом деле, и как лектору помнится, при переходе с уровня на уровень то ли считается, что их надо подряд прохдить, короче говоря, что скрипты, которые вып. , тлько если служба запущена... в общем есть вещи, которые там что-т усложняют. Короче, когда говорится init уровень, должен быть переход. | Что касается других уровней, то чаще всего они используются так: |
| Строка 13: | Строка 18: |
| Уровни эти 0..6 (7, 8) v;y c натяжкой воспр. как прфили рабо системы. Ист. сложилось, чт ур. 0 --- выключчение, 6 --- перезагрузкаю. Что кас. ост., есть довольно давняя традиция, что 1 --- одноп. режим., 2 --- многоп. без сети, 3 --- одноп. с сетью. 5 часто многоп. с сетью и граф. режимом. Нигде это не станд., но кто-то так решил. | * уровень 1 --- однопользовательский режим работы; * уровень 2 --- многопользовательский режим без сети; * уровень 3 --- многопользовательский режим с сетью. |
| Строка 15: | Строка 22: |
| Если приост. и подумать, каке удобство вот в таком, то поймём, что никакого удобства нет. Давным давно ур. не прходятся поряд, давным давно, не происх. переход с пред. на след. Давным давно мжно переход.с с ур. на уровня. Это прсто нек. прфиль. | Списка всех уровней это, однако, не исчерпывает. Поведение системы на оставшихся уровнях выполнения устоялось недостаточно, хотя можно отметить используемое еще одно соглашение, используемое во многих системах: |
| Строка 17: | Строка 24: |
| Во-вторых, соверш. неоч., почему этих профилей должно быть 4, а не 10, не 2. В системах BSD есть толь 2 уровня --- системный и штатный. Если нужно длеать что-то, чтобы никто не мешал, то перехдишь в дноп. режим.ю | * уровень 5 --- многопользовательский режим с сетью и графическим интерфейсом (однако в ряде дистрибутивов GNU/Linux это уровень 2!). |
| Строка 19: | Строка 26: |
| При этом соверш. неопнятно, зачет это нужно. Дело в том, что когда Кен и Деннис работали над (вы же пнимаете, что init был написан примерно тгда, когда и первое ядро UNIX, а может и раньше). Надо напомнить, что Кен и Деннис в рабочее время работали над ОС multics? где работали военщики, монго теории там реализовано. Есть легенда, что та система была построена, сдана и сущ. в ед. экземпляре. Была история, что деннис назвал юникс так, чтобы посмеяться над юнисм. И дело в ом, что малтикс --- военная система, военные любят разделение не демократичное, а согл. правилам, мандатный доступ (считайте, ACL, только орг. по спец. алгоритмам). С этой т. з., когда мы опр. дступ субъектов системы к обыъектам, важно разделдение категорий субъектов. Может быть так, чт при каждом сеянсе доступа к данным есть тлько один субъект. Вообще говря, если есть один субъект, то что, н мжет там делать --- его проблемы. Поэому нет необх. защищать данные от призв. доступа. След. урвень, на котором мы олжны гораздо больш. безоп. развдить --- когда есть меного субъектв дного класса. Считается , что у них нет серъёзных пораж в правах, у них естб один. уровень доступа, но было бы непл. защитить их данные от доступа друг друга, если они этго захотят или если так требует устав. Мы должны выраб. механизм от произв. дступа и на этом ост. Есть правила, ктор. уст. способ доступа, и на этом ост. | Отметим, что в дистрибутивах ПСПО дополнительно выполняется еще одно соответствие: |
| Строка 21: | Строка 28: |
| Ещё блее слжная ситуация наст., кгда в сист. работают пльз. разных категорий. В ситуации, когда к компьютеру может подкл. кто угодно, т мы явно имеем ситуацию другую --- мы имеем небх. разделения польз. по категориям. Что при этом присх. с сист. --- усл. мехнизм идентификации (в случае мнгоп. машины), и в машине должен быть предусмотрен механизм задания правил доступа. | * уровень 7 --- работа инсталятора системы. |
| Строка 23: | Строка 30: |
| Классич. юних-система носила не реальную политику, а следы её. И первый уровень дост. соотв. одноп. режиму --- то есть человек запускает систему и приоизв действ. с систеомй, это похоже на первой ур. по этой классиф. | Обратим внимание на то, что организованная таким способом система довольно неудобна. Уровни выполнения уже давно не проходятся подряд: не происходит загрузки на первый уровень с последующим переключением на второй, третий и далее до нужного. Фактически, разрешен непосредственный переход с любого уровня выполнения на любой другой --- иными словами, само слово "уровень" потеряло в данной схеме свое значение. Почему уровней выполнения (по сути дела --- профилей работы системы) существует столько, сколько сейчас --- вопрос традиции, а не удобства. В BSD-системах, например, существуют только два уровня выполнения: однопользовательский и штатный. |
| Строка 25: | Строка 32: |
| 2 ур. доступа --- соотв. 2 ур. доступа по этой классиф (кгда все субъекту сотв этой категории) | Чтобы понять, почему загрузка системы устроена именно так, вспомним некоторые факты из истории. Существующая схема, называемая часто System V init, была написана очень давно, еще во времена коммерческого UNIX. Создатели UNIX --- Кен Томпсон (Ken Thompson) и Деннис Ритчи (Dennis Ritchie) --- еще ранее работали над операционной системой Multics (совместный проект MIT, GE и Bell Labs, финансировавшийся Пентагоном). В системе Multics существовала появившаяся по требованию военных схема разделения на "уровни доступа": |
| Строка 27: | Строка 34: |
| 3 ур. доступа --- когда машина дост. п сети. | * Первый уровень доступа к системе определялся следующим образом. Каждый сеанс доступа к данным управлялся одним и тем же субъектом --- ясно, что с данными этот субъект мог делать все, что ему заблагорассудится. Необходимости защищать данные от произвольного доступа, таким образом, не было, а от непроизвольного --- была: если в системе одновременно функционировали несколько процессов, они не должны были иметь возможности испортить данные друг друга. |
| Строка 29: | Строка 36: |
| Никакой ... Например, при третьем ур. правила выч. доступа могут отличаться разит. образом, и в юниксе это было сведено до минимума, и не зависит от того, какой ранлевел. Вместо того, чтобы привязывать возм. делать всё, что можно с сист., привязывать к 1 ранлевелу, это привязан к 0. | * При втором уровне доступа в системе могли работать сразу несколько субъектов одного класса. Эти субъекты составляли "команду" и потому не имели серьезных поражений в правах по сравнению друг с другом. Тем не менее, при такой схеме работал механизм защиты от произвольного доступа, представляющий по сути дела Access Control List (ACL). |
| Строка 31: | Строка 38: |
| Факт., классич. юникс --- чень упрощ. реализ. требуемой военщиками трёхур. доступа. И там уже некое откл. от той модели | * Третий уровень доступа соответствовал работе в системе пользователей разных категорий. Условно говоря, подключенные к машине терминалы могли соответствовать пользователям одной категории, а соединения с системой по сети --- пользователям другой категории. Для каждой из таких категорий алгоритм определения прав доступа мог задаваться отдельно. |
| Строка 33: | Строка 40: |
| Так вот, согл. этой архитектуре, возм. такое, чт на 1 зап. осн. службы, на вторм зап. службы, которые позв. тл. плоьз., и далее службы которые включают сеть и мандаты. Понятно, что сейчас про всё это забыли, и дп. алгоритмы прав накладываеются селинуксом и так далее, и ранлевелы не проходятся подряд, а просто выполняется дифф. | Классическая UNIX-система содержала следы этой запутанной политики: |
| Строка 35: | Строка 42: |
| Ничего удивительного, что люди, которые родились в те самые пры, кгда юних-системы стрем. модиф, а про мультикс забыли, они ранлевелами польз. абы как. То есть своядт модель к бин. делению.э | * Первый уровень доступа частично соответствовал однопользовательскому режиму, который давал монопольный доступ к консоли машины. |
| Строка 37: | Строка 44: |
| Поэтому на сегодняшнему моменту бльшой бардак в этом. | * Второй уровень доступа частично соответствовал многопользовательскому режиму: сидящие за терминалами пользователи образовывали "команду". |
| Строка 39: | Строка 46: |
| Вот такой рассказ о тм, что представляли собой когда-т уровни вып., про них самих расск. в книжке. | * Третий уровень доступа частично соответствовал подключению машины к сети. Различные режимы работы в UNIX были названы уровнями выполнения, причем ни о какой гибкости реализации речи не шло. В Multics права доступа на третьем уровне могли различаться даже алгоритмами определения: для одной категории --- ACL, для другой --- мандаты и пр. В UNIX это было сведено к некоторым упрощенным представлениям, уже не зависящим от уровня выполнения: на первое место вышла файловая система, пользователи и группы, причем вычисление прав доступа стало определяться в соответствии с жестким, заранее заданным алгоритмом. Возможность делать с системой все, что угодно, была привязана не к уровню выполнения, а к доверенному субъекту --- пользователю с идентификатором (''uid''), равным нулю. Заметим, что такая архитектура позволяла организовать следующую схему. На первом уровне можно было запускать некоторые "системные" службы, на втором --- добавлять к ним службы, различающие пользователей, на третьем --- службы, организующие доступ пользователей из сети. Так устоялась традиция разделения на однопользовательский режим, многопользовательский режим и многопользовательский режим с сетью, которые соответствуют 1-му, 2-му и 3-му уровням выполнения. В настоящее время описанная модель потеряла практический смысл (за реализацию различных алгоритмов определения прав доступа может отвечать, к примеру, SELinux), а потому соответствующая схема загрузки служб (System V init) стала восприниматься отчасти как наследие прошлого (''legacy''). Тем не менее, в большинстве дистрибутивах GNU/Linux поддерживается однопользовательский режим (первый уровень выполнения), иногда используемый для монопольной работы с системой администратора при помощи консоли. В него можно перейти командой {{{ # init 1 }}} или указав при загрузке системы параметр ядра "single". |
| Строка 47: | Строка 62: |
| || 0 || 1 || 1 || 1 || || 1 || ConstantinYershow, DmitryChistikov, VsevolodKrishchenko || || || | || 50 || 1 || 1 || 1 || || 1 || ConstantinYershow, DmitryChistikov, VsevolodKrishchenko || || || |
Уровни выполнения системы
Поговорим немного об уровнях выполнения системы (англ. runlevel). Уровень выполнения представляет собой специальную абстракцию, упоминаемую в файле /etc/inittab. Это конфигурационный файл для первого запускаемого при загрузке системы процесса, который носит имя init. Изменять данный файл приходится весьма нечасто, причем большинство изменений касаются только строки с параметром initdefault: в ней задается уровень выполнения по умолчанию. Файл /etc/inittab лишь создает разделение на уровни выполнения: за конфигурацию набора запускаемых на каждом уровне служб в дистрибутивах ПСПО отвечает утилита chkconfig. Она манипулирует со ссылками на службы, расположенными в каталогах вида /etc/rc<уровень>.d. Таким образом, команда
$ ls -l /etc/rc0.d/
покажет службы, выполнение которых затрагивает переход на уровень 0.
Администратор системы может переключать систему с одного уровня выполнения на другой, выполняя команду init с единственным параметром --- номером нужного уровня. При переходе система определяет, какие службы должны быть запущены, а какие --- остановлены, производит собственно переключение и выполняет необходимые операции.
Сами уровни выполнения можно, хотя и с некоторой натяжкой, воспринимать как профили работы системы. Кроме того, к уровням выполнения причисляют также некоторые специальные действия:
- уровень 0 --- полная остановка системы с выключением (если это возможно);
- уровень 6 --- перезагрузка, то есть остановка и загрузка заново (на уровень по умолчанию).
Что касается других уровней, то чаще всего они используются так:
- уровень 1 --- однопользовательский режим работы;
- уровень 2 --- многопользовательский режим без сети;
- уровень 3 --- многопользовательский режим с сетью.
Списка всех уровней это, однако, не исчерпывает. Поведение системы на оставшихся уровнях выполнения устоялось недостаточно, хотя можно отметить используемое еще одно соглашение, используемое во многих системах:
- уровень 5 --- многопользовательский режим с сетью и графическим интерфейсом (однако в ряде дистрибутивов GNU/Linux это уровень 2!).
Отметим, что в дистрибутивах ПСПО дополнительно выполняется еще одно соответствие:
- уровень 7 --- работа инсталятора системы.
Обратим внимание на то, что организованная таким способом система довольно неудобна. Уровни выполнения уже давно не проходятся подряд: не происходит загрузки на первый уровень с последующим переключением на второй, третий и далее до нужного. Фактически, разрешен непосредственный переход с любого уровня выполнения на любой другой --- иными словами, само слово "уровень" потеряло в данной схеме свое значение. Почему уровней выполнения (по сути дела --- профилей работы системы) существует столько, сколько сейчас --- вопрос традиции, а не удобства. В BSD-системах, например, существуют только два уровня выполнения: однопользовательский и штатный.
Чтобы понять, почему загрузка системы устроена именно так, вспомним некоторые факты из истории. Существующая схема, называемая часто System V init, была написана очень давно, еще во времена коммерческого UNIX. Создатели UNIX --- Кен Томпсон (Ken Thompson) и Деннис Ритчи (Dennis Ritchie) --- еще ранее работали над операционной системой Multics (совместный проект MIT, GE и Bell Labs, финансировавшийся Пентагоном). В системе Multics существовала появившаяся по требованию военных схема разделения на "уровни доступа":
- Первый уровень доступа к системе определялся следующим образом. Каждый сеанс доступа к данным управлялся одним и тем же субъектом --- ясно, что с данными этот субъект мог делать все, что ему заблагорассудится. Необходимости защищать данные от произвольного доступа, таким образом, не было, а от непроизвольного --- была: если в системе одновременно функционировали несколько процессов, они не должны были иметь возможности испортить данные друг друга.
- При втором уровне доступа в системе могли работать сразу несколько субъектов одного класса. Эти субъекты составляли "команду" и потому не имели серьезных поражений в правах по сравнению друг с другом. Тем не менее, при такой схеме работал механизм защиты от произвольного доступа, представляющий по сути дела Access Control List (ACL).
- Третий уровень доступа соответствовал работе в системе пользователей разных категорий. Условно говоря, подключенные к машине терминалы могли соответствовать пользователям одной категории, а соединения с системой по сети --- пользователям другой категории. Для каждой из таких категорий алгоритм определения прав доступа мог задаваться отдельно.
Классическая UNIX-система содержала следы этой запутанной политики:
- Первый уровень доступа частично соответствовал однопользовательскому режиму, который давал монопольный доступ к консоли машины.
- Второй уровень доступа частично соответствовал многопользовательскому режиму: сидящие за терминалами пользователи образовывали "команду".
- Третий уровень доступа частично соответствовал подключению машины к сети.
Различные режимы работы в UNIX были названы уровнями выполнения, причем ни о какой гибкости реализации речи не шло. В Multics права доступа на третьем уровне могли различаться даже алгоритмами определения: для одной категории --- ACL, для другой --- мандаты и пр. В UNIX это было сведено к некоторым упрощенным представлениям, уже не зависящим от уровня выполнения: на первое место вышла файловая система, пользователи и группы, причем вычисление прав доступа стало определяться в соответствии с жестким, заранее заданным алгоритмом. Возможность делать с системой все, что угодно, была привязана не к уровню выполнения, а к доверенному субъекту --- пользователю с идентификатором (uid), равным нулю.
Заметим, что такая архитектура позволяла организовать следующую схему. На первом уровне можно было запускать некоторые "системные" службы, на втором --- добавлять к ним службы, различающие пользователей, на третьем --- службы, организующие доступ пользователей из сети. Так устоялась традиция разделения на однопользовательский режим, многопользовательский режим и многопользовательский режим с сетью, которые соответствуют 1-му, 2-му и 3-му уровням выполнения. В настоящее время описанная модель потеряла практический смысл (за реализацию различных алгоритмов определения прав доступа может отвечать, к примеру, SELinux), а потому соответствующая схема загрузки служб (System V init) стала восприниматься отчасти как наследие прошлого (legacy). Тем не менее, в большинстве дистрибутивах GNU/Linux поддерживается однопользовательский режим (первый уровень выполнения), иногда используемый для монопольной работы с системой администратора при помощи консоли. В него можно перейти командой
# init 1
или указав при загрузке системы параметр ядра "single".
Сведения о ресурсах
Готовность (%) |
Продолжительность (ак. ч.) |
Подготовка (календ. ч.) |
Полный текст (раб. д.) |
Предварительные знания |
Level |
Maintainer |
Start date |
End date |
50 |
1 |
1 |
1 |
|
1 |
|
|