Differences between revisions 1 and 11 (spanning 10 versions)
Revision 1 as of 2008-07-30 05:13:46
Size: 10356
Editor: eSyr
Comment:
Revision 11 as of 2008-08-08 14:45:40
Size: 13158
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
== Уровни выполнения == == Уровни выполнения системы ==
Line 3: Line 3:
Посмотрим чень кратуий пересказ того, что такое урвни вып., более подробно см. учебник. Ур. вып. есть некая абстракция, которая упоминается в конф. фаыле init, inittab. Это такая штука замороченная, довольн старого фрмато, простой смертный там ничего менять не должен, за исключением, рпзве что умолчального уровня выполнения, который значится в полне init-default. Поговорим немного об уровнях выполнения системы (англ. ''runlevel''). Уровень выполнения представляет собой специальную абстракцию, упоминаемую в файле {{{/etc/inittab}}}. Это конфигурационный файл для первого запускаемого при загрузке системы процесса, который носит имя {{{init}}}. Изменять данный файл приходится весьма нечасто, причем большинство изменений касаются только строки с параметром initdefault: в ней задается уровень выполнения по умолчанию. Файл {{{/etc/inittab}}} лишь создает разделение на уровни выполнения: за конфигурацию набора запускаемых на каждом уровне служб в дистрибутивах ПСПО отвечает утилита {{{chkconfig}}}. Она манипулирует со ссылками на службы, расположенными в каталогах вида {{{/etc/rc<уровень>.d}}}. Таким образом, команда
{{{
$ ls -l /etc/rc0.d/
}}}
покажет службы, выполнение которых затрагивает переход на уровень 0.
Line 5: Line 9:
Там есть ещё мнго всякого интересного, какие ерм, склько консолей, там вообще описание процесса загрузки. Администратор системы может переключать систему с одного уровня выполнения на другой, выполняя команду {{{init}}} с единственным параметром --- номером нужного уровня. При переходе система определяет, какие службы должны быть запущены, а какие --- остановлены, производит собственно переключение и выполняет необходимые операции.
Line 7: Line 11:
В частности, в inittab неск. аз упоминаются урвни выполнения, в частности, дефолтный, и уровни выполнения, и скрипты, которые им соотв. Сами уровни выполнения можно, хотя и с некоторой натяжкой, воспринимать как профили работы системы. Кроме того, к уровням выполнения причисляют также некоторые специальные действия:
Line 9: Line 13:
Дальнейшее описание лектор откладывает на книжку, упомянет тольк что, так уж сложилось традиц., что переход с ур. вып на ур. вып. зн. прибивание всех прцессов, которые запущены на одном ур, и не должны быть щапущ на другом (в альте это уст. по chkconfig), но некая ид. модель ур. вып. состоит в том, чт прибивает одни службы и запускает другие.  * уровень 0 --- полная остановка системы с выключением (если это возможно);
 * уровень 6 --- перезагрузка, то есть остановка и загрузка заново (на уровень по умолчанию).
Line 11: Line 16:
В действ всё происх. не так, как на самом деле, и как лектору помнится, при переходе с уровня на уровень то ли считается, что их надо подряд прохдить, короче говоря, что скрипты, которые вып. , тлько если служба запущена... в общем есть вещи, которые там что-т усложняют. Короче, когда говорится init уровень, должен быть переход. Что касается других уровней, то чаще всего они используются так:
Line 13: Line 18:
Уровни эти 0..6 (7, 8) v;y c натяжкой воспр. как прфили рабо системы. Ист. сложилось, чт ур. 0 --- выключчение, 6 --- перезагрузкаю. Что кас. ост., есть довольно давняя традиция, что 1 --- одноп. режим., 2 --- многоп. без сети, 3 --- одноп. с сетью. 5 часто многоп. с сетью и граф. режимом. Нигде это не станд., но кто-то так решил.  * уровень 1 --- однопользовательский режим работы;
 * уровень 2 --- многопользовательский режим без сети;
 * уровень 3 --- многопользовательский режим с сетью.
Line 15: Line 22:
Если приост. и подумать, каке удобство вот в таком, то поймём, что никакого удобства нет. Давным давно ур. не прходятся поряд, давным давно, не происх. переход с пред. на след. Давным давно мжно переход.с с ур. на уровня. Это прсто нек. прфиль. Списка всех уровней это, однако, не исчерпывает. Поведение системы на оставшихся уровнях выполнения устоялось недостаточно, хотя можно отметить используемое еще одно соглашение, используемое во многих системах:
Line 17: Line 24:
Во-вторых, соверш. неоч., почему этих профилей должно быть 4, а не 10, не 2. В системах BSD есть толь 2 уровня --- системный и штатный. Если нужно длеать что-то, чтобы никто не мешал, то перехдишь в дноп. режим.ю  * уровень 5 --- многопользовательский режим с сетью и графическим интерфейсом (однако в ряде дистрибутивов GNU/Linux это уровень 2!).
Line 19: Line 26:
При этом соверш. неопнятно, зачет это нужно. Дело в том, что когда Кен и Деннис работали над (вы же пнимаете, что init был написан примерно тгда, когда и первое ядро UNIX, а может и раньше). Надо напомнить, что Кен и Деннис в рабочее время работали над ОС multics? где работали военщики, монго теории там реализовано. Есть легенда, что та система была построена, сдана и сущ. в ед. экземпляре. Была история, что деннис назвал юникс так, чтобы посмеяться над юнисм. И дело в ом, что малтикс --- военная система, военные любят разделение не демократичное, а согл. правилам, мандатный доступ (считайте, ACL, только орг. по спец. алгоритмам). С этой т. з., когда мы опр. дступ субъектов системы к обыъектам, важно разделдение категорий субъектов. Может быть так, чт при каждом сеянсе доступа к данным есть тлько один субъект. Вообще говря, если есть один субъект, то что, н мжет там делать --- его проблемы. Поэому нет необх. защищать данные от призв. доступа. След. урвень, на котором мы олжны гораздо больш. безоп. развдить --- когда есть меного субъектв дного класса. Считается , что у них нет серъёзных пораж в правах, у них естб один. уровень доступа, но было бы непл. защитить их данные от доступа друг друга, если они этго захотят или если так требует устав. Мы должны выраб. механизм от произв. дступа и на этом ост. Есть правила, ктор. уст. способ доступа, и на этом ост. Отметим, что в дистрибутивах ПСПО дополнительно выполняется еще одно соответствие:
Line 21: Line 28:
Ещё блее слжная ситуация наст., кгда в сист. работают пльз. разных категорий. В ситуации, когда к компьютеру может подкл. кто угодно, т мы явно имеем ситуацию другую --- мы имеем небх. разделения польз. по категориям. Что при этом присх. с сист. --- усл. мехнизм идентификации (в случае мнгоп. машины), и в машине должен быть предусмотрен механизм задания правил доступа.  * уровень 7 --- работа инсталятора системы.
Line 23: Line 30:
Классич. юних-система носила не реальную политику, а следы её. И первый уровень дост. соотв. одноп. режиму --- то есть человек запускает систему и приоизв действ. с систеомй, это похоже на первой ур. по этой классиф. Обратим внимание на то, что организованная таким способом система довольно неудобна. Уровни выполнения уже давно не проходятся подряд: не происходит загрузки на первый уровень с последующим переключением на второй, третий и далее до нужного. Фактически, разрешен непосредственный переход с любого уровня выполнения на любой другой --- иными словами, само слово "уровень" потеряло в данной схеме свое значение. Почему уровней выполнения (по сути дела --- профилей работы системы) существует столько, сколько сейчас --- вопрос традиции, а не удобства. В BSD-системах, например, существуют только два уровня выполнения: однопользовательский и штатный.
Line 25: Line 32:
2 ур. доступа --- соотв. 2 ур. доступа по этой классиф (кгда все субъекту сотв этой категории) Чтобы понять, почему загрузка системы устроена именно так, вспомним некоторые факты из истории. Существующая схема, называемая часто System V init, была написана очень давно, еще во времена коммерческого UNIX. Создатели UNIX --- Кен Томпсон (Ken Thompson) и Деннис Ритчи (Dennis Ritchie) --- еще ранее работали над операционной системой Multics (совместный проект MIT, GE и Bell Labs, финансировавшийся Пентагоном). В системе Multics существовала появившаяся по требованию военных схема разделения на "уровни доступа":
Line 27: Line 34:
3 ур. доступа --- когда машина дост. п сети.  * Первый уровень доступа к системе определялся следующим образом. Каждый сеанс доступа к данным управлялся одним и тем же субъектом --- ясно, что с данными этот субъект мог делать все, что ему заблагорассудится. Необходимости защищать данные от произвольного доступа, таким образом, не было, а от непроизвольного --- была: если в системе одновременно функционировали несколько процессов, они не должны были иметь возможности испортить данные друг друга.
Line 29: Line 36:
Никакой ... Например, при третьем ур. правила выч. доступа могут отличаться разит. образом, и в юниксе это было сведено до минимума, и не зависит от того, какой ранлевел. Вместо того, чтобы привязывать возм. делать всё, что можно с сист., привязывать к 1 ранлевелу, это привязан к 0.  * При втором уровне доступа в системе могли работать сразу несколько субъектов одного класса. Эти субъекты составляли "команду" и потому не имели серьезных поражений в правах по сравнению друг с другом. Тем не менее, при такой схеме работал механизм защиты от произвольного доступа, представляющий по сути дела Access Control List (ACL).
Line 31: Line 38:
Факт., классич. юникс --- чень упрощ. реализ. требуемой военщиками трёхур. доступа. И там уже некое откл. от той модели  * Третий уровень доступа соответствовал работе в системе пользователей разных категорий. Условно говоря, подключенные к машине терминалы могли соответствовать пользователям одной категории, а соединения с системой по сети --- пользователям другой категории. Для каждой из таких категорий алгоритм определения прав доступа мог задаваться отдельно.
Line 33: Line 40:
Так вот, согл. этой архитектуре, возм. такое, чт на 1 зап. осн. службы, на вторм зап. службы, которые позв. тл. плоьз., и далее службы которые включают сеть и мандаты. Понятно, что сейчас про всё это забыли, и дп. алгоритмы прав накладываеются селинуксом и так далее, и ранлевелы не проходятся подряд, а просто выполняется дифф. Классическая UNIX-система содержала следы этой запутанной политики:
Line 35: Line 42:
Ничего удивительного, что люди, которые родились в те самые пры, кгда юних-системы стрем. модиф, а про мультикс забыли, они ранлевелами польз. абы как. То есть своядт модель к бин. делению.э  * Первый уровень доступа частично соответствовал однопользовательскому режиму, который давал монопольный доступ к консоли машины.
Line 37: Line 44:
Поэтому на сегодняшнему моменту бльшой бардак в этом.  * Второй уровень доступа частично соответствовал многопользовательскому режиму: сидящие за терминалами пользователи образовывали "команду".
Line 39: Line 46:
Вот такой рассказ о тм, что представляли собой когда-т уровни вып., про них самих расск. в книжке.  * Третий уровень доступа частично соответствовал подключению машины к сети.

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

Заметим, что такая архитектура позволяла организовать следующую схему. На первом уровне можно было запускать некоторые "системные" службы, на втором --- добавлять к ним службы, различающие пользователей, на третьем --- службы, организующие доступ пользователей из сети. Так устоялась традиция разделения на однопользовательский режим, многопользовательский режим и многопользовательский режим с сетью, которые соответствуют 1-му, 2-му и 3-му уровням выполнения. В настоящее время описанная модель потеряла практический смысл (за реализацию различных алгоритмов определения прав доступа может отвечать, к примеру, SELinux), а потому соответствующая схема загрузки служб (System V init) стала восприниматься отчасти как наследие прошлого (''legacy''). Тем не менее, в большинстве дистрибутивах GNU/Linux поддерживается однопользовательский режим (первый уровень выполнения), иногда используемый для монопольной работы с системой администратора при помощи консоли. В него можно перейти командой
{{{
# init 1
}}}
или указав при загрузке системы параметр ядра "single".
Line 47: Line 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

ConstantinYershow, DmitryChistikov, VsevolodKrishchenko


CategoryLectures CategoryPspo CategoryMpgu CategoryUneex

PspoClasses/080729/01RunLevels (last edited 2008-10-04 08:10:06 by VsevolodKrishchenko)