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

Посмотрим чень кратуий пересказ того, что такое урвни вып., более подробно см. учебник. Ур. вып. есть некая абстракция, которая упоминается в конф. фаыле init, inittab. Это такая штука замороченная, довольн старого фрмато, простой смертный там ничего менять не должен, за исключением, рпзве что умолчального уровня выполнения, который значится в полне init-default.

Там есть ещё мнго всякого интересного, какие ерм, склько консолей, там вообще описание процесса загрузки.

В частности, в inittab неск. аз упоминаются урвни выполнения, в частности, дефолтный, и уровни выполнения, и скрипты, которые им соотв.

Дальнейшее описание лектор откладывает на книжку, упомянет тольк что, так уж сложилось традиц., что переход с ур. вып на ур. вып. зн. прибивание всех прцессов, которые запущены на одном ур, и не должны быть щапущ на другом (в альте это уст. по chkconfig), но некая ид. модель ур. вып. состоит в том, чт прибивает одни службы и запускает другие.

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

Уровни эти 0..6 (7, 8) v;y c натяжкой воспр. как прфили рабо системы. Ист. сложилось, чт ур. 0 --- выключчение, 6 --- перезагрузкаю. Что кас. ост., есть довольно давняя традиция, что 1 --- одноп. режим., 2 --- многоп. без сети, 3 --- одноп. с сетью. 5 часто многоп. с сетью и граф. режимом. Нигде это не станд., но кто-то так решил.

Если приост. и подумать, каке удобство вот в таком, то поймём, что никакого удобства нет. Давным давно ур. не прходятся поряд, давным давно, не происх. переход с пред. на след. Давным давно мжно переход.с с ур. на уровня. Это прсто нек. прфиль.

Во-вторых, соверш. неоч., почему этих профилей должно быть 4, а не 10, не 2. В системах BSD есть толь 2 уровня --- системный и штатный. Если нужно длеать что-то, чтобы никто не мешал, то перехдишь в дноп. режим.ю

При этом соверш. неопнятно, зачет это нужно. Дело в том, что когда Кен и Деннис работали над (вы же пнимаете, что init был написан примерно тгда, когда и первое ядро UNIX, а может и раньше). Надо напомнить, что Кен и Деннис в рабочее время работали над ОС multics? где работали военщики, монго теории там реализовано. Есть легенда, что та система была построена, сдана и сущ. в ед. экземпляре. Была история, что деннис назвал юникс так, чтобы посмеяться над юнисм. И дело в ом, что малтикс --- военная система, военные любят разделение не демократичное, а согл. правилам, мандатный доступ (считайте, ACL, только орг. по спец. алгоритмам). С этой т. з., когда мы опр. дступ субъектов системы к обыъектам, важно разделдение категорий субъектов. Может быть так, чт при каждом сеянсе доступа к данным есть тлько один субъект. Вообще говря, если есть один субъект, то что, н мжет там делать --- его проблемы. Поэому нет необх. защищать данные от призв. доступа. След. урвень, на котором мы олжны гораздо больш. безоп. развдить --- когда есть меного субъектв дного класса. Считается , что у них нет серъёзных пораж в правах, у них естб один. уровень доступа, но было бы непл. защитить их данные от доступа друг друга, если они этго захотят или если так требует устав. Мы должны выраб. механизм от произв. дступа и на этом ост. Есть правила, ктор. уст. способ доступа, и на этом ост.

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

Классич. юних-система носила не реальную политику, а следы её. И первый уровень дост. соотв. одноп. режиму --- то есть человек запускает систему и приоизв действ. с систеомй, это похоже на первой ур. по этой классиф.

2 ур. доступа --- соотв. 2 ур. доступа по этой классиф (кгда все субъекту сотв этой категории)

3 ур. доступа --- когда машина дост. п сети.

Никакой ... Например, при третьем ур. правила выч. доступа могут отличаться разит. образом, и в юниксе это было сведено до минимума, и не зависит от того, какой ранлевел. Вместо того, чтобы привязывать возм. делать всё, что можно с сист., привязывать к 1 ранлевелу, это привязан к 0.

Факт., классич. юникс --- чень упрощ. реализ. требуемой военщиками трёхур. доступа. И там уже некое откл. от той модели

Так вот, согл. этой архитектуре, возм. такое, чт на 1 зап. осн. службы, на вторм зап. службы, которые позв. тл. плоьз., и далее службы которые включают сеть и мандаты. Понятно, что сейчас про всё это забыли, и дп. алгоритмы прав накладываеются селинуксом и так далее, и ранлевелы не проходятся подряд, а просто выполняется дифф.

Ничего удивительного, что люди, которые родились в те самые пры, кгда юних-системы стрем. модиф, а про мультикс забыли, они ранлевелами польз. абы как. То есть своядт модель к бин. делению.э

Поэтому на сегодняшнему моменту бльшой бардак в этом.

Вот такой рассказ о тм, что представляли собой когда-т уровни вып., про них самих расск. в книжке.


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

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

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

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

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

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

Level

Maintainer

Start date

End date

0

1

1

1

1

ConstantinYershow, DmitryChistikov, VsevolodKrishchenko


CategoryLectures CategoryPspo CategoryMpgu CategoryUneex