Differences between revisions 1 and 2
Revision 1 as of 2008-07-30 05:13:46
Size: 10356
Editor: eSyr
Comment:
Revision 2 as of 2008-08-06 08:24:14
Size: 20275
Comment:
Deletions are marked like this. Additions are marked like this.
Line 2: Line 2:
Здесь приведён очень краткий пересказ того, что такое урвни выполнения, более подробно см. учебник. Уровни выполнения есть некая абстракция, которая упоминается в конфигурационном файле init, inittab. Это замороченная штука, довольно старого фрмата, простой смертный там ничего менять не должен, за исключением уровня выполнения по умолчанию, который указывается в строчке init-default. Там есть ещё мнго всякого интересного, там описывается, какие терминалы, склько консолей... в общем, описание процесса init в самом старте системы. В частности, в inittab несколько раз упоминается понятие "уровень выполнения", в частности, используемый по умолчанию (вышеупомянутый init-default), и уровни выполнения с шелльными скриптами, которые им соответствуют. Дальнейшее описание лектор откладывает на книжку, упомянет только, что, так уж сложилось по традиции, что переход с уровня выполнения на уровень выполнения означает прибивание всех служб, которые запущены на одном уровне, но не должны запускаться на другом (в альте это регулируется командой chkconfig).
Line 3: Line 4:
Посмотрим чень кратуий пересказ того, что такое урвни вып., более подробно см. учебник. Ур. вып. есть некая абстракция, которая упоминается в конф. фаыле init, inittab. Это такая штука замороченная, довольн старого фрмато, простой смертный там ничего менять не должен, за исключением, рпзве что умолчального уровня выполнения, который значится в полне init-default. В действительности всё происходит не так, как на самом деле, и как лектору помнится, при переходе с уровня на уровень вроде бы считается, что их надо подряд прохдить, скрипты, которые убивают службы, делают это только если соответствующие службы запущены... в общем, есть какая-то доделка, которая весь этот алгоритм усложняет. Короче, когда говорится init уровень, система должна на этот уровень перейти и проделать соответствующие действия, что-то подняв и что-то восстановив.
Line 5: Line 6:
Там есть ещё мнго всякого интересного, какие ерм, склько консолей, там вообще описание процесса загрузки. Уровни эти 0..6 (7, 8) можно c натяжкой воспринимать как прфили работы одной и той же системы. Исторически сложилось, что уровень 0 - полная остановка системы с выключением, если это возможно, 6 - перезагрузка системы (остановка и загрузка заново на уровень по умолчанию). Что касается всех остальных уровней, есть довольно давняя традиция, что уровень 1 - однопользовательский режим, 2 - многопользовательский режим без сети, 3 - многопользовательский режим с сетью. Остальное никак не специфицированно, хотя традиционно считается, что уровень 5 - это многопользовательский режим с сетью и графическим интерфейсом. Кажется, седьмой уровень - это уровень инсталлятора. Пятый и седьмой уровень нигде не стандартизованы, и вообще непонятно, почему так кто-то решил; видимо, для современных систем, где наличествует графика, пятый уровень должен отличаться от третьего.
Line 7: Line 8:
В частности, в inittab неск. аз упоминаются урвни выполнения, в частности, дефолтный, и уровни выполнения, и скрипты, которые им соотв. Если приостановиться и подумать, зачем так устроено и какое в этом удобство, мы поймём, что никакого удобства в этом нет. Давным-давно уровни не проходятся поряд, давным давно не бывает такого, что наша система сначала входит в первый уровень и запускает службы, необходимые на первом уровне, потом переходит с первого на второй уровень, дозапусковывает службы, необходимые на втором уровне и т.д. В реальности делается так: убиваются все службы, которые должны убиться, а потом они запускаются заново, или убивается некоторая высчитанная разница... Как-то так. И можно переходить с любого уровня на любой. То есть, фактически, никакого понятия "уровень" уже нет. Это просто некий профиль - однопользовательский, многопользовательский там, многопользовательский с сетью... Совершенно неочевидно, почему этих профилей должно быть 4, а не 10, не 2. В системах BSD есть только 2 уровня - однопользовательский, то есть тот, где ничего нет, только шелл да консоль, и штатный. Предполагается, что если нужно делать что-то так, чтобы никто не беспокоил, то переходишь в однопользовательский режим и всё делаешь.
Line 9: Line 10:
Дальнейшее описание лектор откладывает на книжку, упомянет тольк что, так уж сложилось традиц., что переход с ур. вып на ур. вып. зн. прибивание всех прцессов, которые запущены на одном ур, и не должны быть щапущ на другом (в альте это уст. по chkconfig), но некая ид. модель ур. вып. состоит в том, чт прибивает одни службы и запускает другие. При этом совершенно непонятно, зачем это нужно. Дело в том, что init был написан примерно тогда, когда и первое ядро UNIX, а может и раньше. Надо напомнить, что Кен и Деннис в рабочее время работали над ОС multics, где работали военщики, где много теории было реализовано. Есть легенда, что эта система была доведена до рабочего состояния, сдана заказчику и существовала в единственном экземпляре, так как была построена по нетиражируемым технологиям. Была история, что деннис назвал юникс так, чтобы поглумиться над названием multics. Дело даже не в этом, а в том, что ОС малтикс была написана по заказу военных, которые любят разделение доступа не демократичное, а сообразно правилам, в российской терминологии - мандатный доступ (нечто вроде ACL, только организованное по специальным алгоритмам). С этой точки зрения, когда мы определяем права доступа субъектов системы к объектам, важно разделдение в категорях самих субъектов.
 * Может быть так, что система работает так, что при каждом сеансе доступа к данным есть только один субъект. С точки зрения секретности, если есть один субъект, то что бы он ни делал с данными, это его проблеммы. Поэому нет необходимости защищать данные от произвольного доступа. От непроизвольного стоит - когда у нас есть много процесссов, неплохо, чтобы они не портили свои данные случайно.
 * Следующий уровень, на котором мы должны гораздо больше безопасности разводить - когда есть много субъектов одного класса. Считается, что у них нет серъёзных поражений в правах, условно говоря, это - некая команда, они имеют одинаковые уровни доступа к документам и т.д., но было бы неплохо защитить их данные от доступа друг друга, если они этого не хотят или если это запрещено уставом. Мы должны выработать механизм защиты от произвольного доступа и на этом остановиться. То есть, есть правило, определяющее, как организуется защита от произвольного доступа, в случае юникса вы руками выставляете права даоступа на свои файлы, в случае системы, где это регулируется сверху, будет некая матрица, по которой это будет видно.
 * Ещё более сложная ситуация наступает, когда в системе работают пользователи разных категорий, то есть такие, алгоритм определения прав доступа которых к объектам системы для каждой группы пользователей различен. Есть серьёзные пользователи, есть левые пользователи и т.д. То есть, в ситуации, когда к компьютеру присоединено двадцать терминалов, на каждом из которых сидит по одному человеку, это пользователи одной категории, а если к компьютеру может присоединиться кто угодно, мы явно имеем другую ситуацию - мы имеем небходимость разделения пользователей по категориям. Некоторые, которые подтвердили свою высокую категорию доступа, имеют одни права, некоторые - другие... Что при этом присходит с системой? Усложняется мехнизм идентификации (в случае мнгопользовательской машины, когда все люди сидят в одном классе, может не быть никакой идентификации - человек садится, в журнале расписывается, и ему каким-то образом обозначаются права; в случае, если человек присоединяется из сети - там совершенно непонятно что), и в системе должно быть предусмотрено такое понятие, как категории пользователей, для которых алгоритм определения прав доступа для каждой категории свой. Возможно даже, для одних пользователей это будет доступ по заранее заданным правилам, для других - они сами определяют, для третьих - определяет начальник и т.д.
Line 11: Line 15:
В действ всё происх. не так, как на самом деле, и как лектору помнится, при переходе с уровня на уровень то ли считается, что их надо подряд прохдить, короче говоря, что скрипты, которые вып. , тлько если служба запущена... в общем есть вещи, которые там что-т усложняют. Короче, когда говорится init уровень, должен быть переход. Классическая юних-система носила на себе не реальную вот эту вот политику, а следы её.
 * Первый уровень доступа частично соответствует однопользовательскому режиму - то есть человек имеет доступ к консоли и запускает её таким образом, что он только один производит какие-то действия над систеомй, это похоже на первой уровень доступа по этой классификации.
 * Когда машина многопользовательская, то есть, она стоит в углу, к ней присоединены терминалы, за которыми сидит личный состав, но все эти люди имеют одинаковую категорию, это более или менее соответствует второму уровню доступа по этой классификации (когда все субъекты в системе принадлежат одной категории).
 * Наконец, когда машина подключена к сети, это соответствует третьему уровню доступа.
Line 13: Line 20:
Уровни эти 0..6 (7, 8) v;y c натяжкой воспр. как прфили рабо системы. Ист. сложилось, чт ур. 0 --- выключчение, 6 --- перезагрузкаю. Что кас. ост., есть довольно давняя традиция, что 1 --- одноп. режим., 2 --- многоп. без сети, 3 --- одноп. с сетью. 5 часто многоп. с сетью и граф. режимом. Нигде это не станд., но кто-то так решил. Разумеется, ни о какой гибкости реализации этих механизмов на том уровне, о котором сказано выше, нельзя говорить. В идеале, группы и права доступа должны как-то моделироваться и задаваться. Например, при третьем уровне доступа правила вычисления прав доступа конкретного пользователя, принадежащего к конкретной группе, могут отличаться разительным образом, для одних ACL, для других - мандаты, для третьих ещё что-то... В юниксе это было сведено до некоторых упрощённых представлений, которые уже не зависят от того, какой у вас ранлевел. А именно, есть файловая система, есть пользователи и группы, у них есть жёсткие алгоритмы вычисления прав доступа одного к Вместо того, к другому, а вместо того, чтобы привязывать возможность делать всё, что угодно, с системой к 1 ранлевелу, это привязано к доверенному субъекту, пользователю, чей идентификатор равен 0. Фактически, классический юникс - очень упрощённая реализация требуемой военщиками трёхуровневой модели доступа. При этом, там уже есть некоторые отклонения, потому что не то, что вы умудрились получить шелл на первои ранлевеле, а то, что вы умудрились зарегистрироваться как рут, определяет, что вы крутой. И вы точно также можете зарегистрироваться как рут на втором или третьем ранлевеле и получить такой же самый уровень доступа.
Line 15: Line 22:
Если приост. и подумать, каке удобство вот в таком, то поймём, что никакого удобства нет. Давным давно ур. не прходятся поряд, давным давно, не происх. переход с пред. на след. Давным давно мжно переход.с с ур. на уровня. Это прсто нек. прфиль. Так вот, согласно этой архитектуре, действительно было возможно такое, что на первом уровне запускаются отдельные службы, на втором к ним добавляются службы, которые позволяют отличать пользователя от пользователя, и на третьем к ним добавляются службы которые организуют доступ произвольного пользователя из сети, если это нужно, и позволяют отличать пользователя по категории. Но уже в юниксе такого нет. Там устоялась следующая традиция: однопользовательский режим, многопользовательский режим, многопользовательский режим с сетью. Понятно, что сейчас про всё это забыли, реализация соответствующих мандатных прав доступа накладывается в линукс-системы сверху, селинуксом например, и алгоритм запуска процесса в ранлевеле тоже поменялся. Никто не проходит все ранлевелы подряд, а убиваются все одни сервисы, запускаются все вторые, в лучшем случае, те, которые там и там есть, просто не убиваются. Поэтому ранлевелами стали пользоваться как профилями системы с небольшим легаси, чтобы на пятом уровне запускался ещё и графический сервер. Ничего удивительного, что люди, которые родились в те самые поры, когда юних-системы стремительно модифицировались, а про мультикс все забыли, они, когда чего-то пишут, ранлевелами пользуются абы как. Просто знают, что 2,3,4,5 - это ранлевелы, где не-рут. То есть сводят модель к бинарному делению: однопользовательский режим, где один только рут, и многопользовательский режим, где всё. Поэтому на сегодняшний день есть большой бардак в sysvinit.
Line 17: Line 24:
Во-вторых, соверш. неоч., почему этих профилей должно быть 4, а не 10, не 2. В системах BSD есть толь 2 уровня --- системный и штатный. Если нужно длеать что-то, чтобы никто не мешал, то перехдишь в дноп. режим.ю

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

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

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

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

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

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

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

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

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

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

Вот такой рассказ о тм, что представляли собой когда-т уровни вып., про них самих расск. в книжке.
Вот такой рассказ о том, что представляли собой когда-то уровни выполнения и во что они превратились, а как они работают, рассказано в книжке.
Line 47: Line 32:
|| 0 || 1 || 1 || 1 || || 1 || ConstantinYershow, DmitryChistikov, VsevolodKrishchenko || || || || 20 || 1 || 1 || 1 || || 1 || ConstantinYershow, DmitryChistikov, VsevolodKrishchenko || || ||

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

Здесь приведён очень краткий пересказ того, что такое урвни выполнения, более подробно см. учебник. Уровни выполнения есть некая абстракция, которая упоминается в конфигурационном файле init, inittab. Это замороченная штука, довольно старого фрмата, простой смертный там ничего менять не должен, за исключением уровня выполнения по умолчанию, который указывается в строчке init-default. Там есть ещё мнго всякого интересного, там описывается, какие терминалы, склько консолей... в общем, описание процесса init в самом старте системы. В частности, в inittab несколько раз упоминается понятие "уровень выполнения", в частности, используемый по умолчанию (вышеупомянутый init-default), и уровни выполнения с шелльными скриптами, которые им соответствуют. Дальнейшее описание лектор откладывает на книжку, упомянет только, что, так уж сложилось по традиции, что переход с уровня выполнения на уровень выполнения означает прибивание всех служб, которые запущены на одном уровне, но не должны запускаться на другом (в альте это регулируется командой chkconfig).

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

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

Если приостановиться и подумать, зачем так устроено и какое в этом удобство, мы поймём, что никакого удобства в этом нет. Давным-давно уровни не проходятся поряд, давным давно не бывает такого, что наша система сначала входит в первый уровень и запускает службы, необходимые на первом уровне, потом переходит с первого на второй уровень, дозапусковывает службы, необходимые на втором уровне и т.д. В реальности делается так: убиваются все службы, которые должны убиться, а потом они запускаются заново, или убивается некоторая высчитанная разница... Как-то так. И можно переходить с любого уровня на любой. То есть, фактически, никакого понятия "уровень" уже нет. Это просто некий профиль - однопользовательский, многопользовательский там, многопользовательский с сетью... Совершенно неочевидно, почему этих профилей должно быть 4, а не 10, не 2. В системах BSD есть только 2 уровня - однопользовательский, то есть тот, где ничего нет, только шелл да консоль, и штатный. Предполагается, что если нужно делать что-то так, чтобы никто не беспокоил, то переходишь в однопользовательский режим и всё делаешь.

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

  • Может быть так, что система работает так, что при каждом сеансе доступа к данным есть только один субъект. С точки зрения секретности, если есть один субъект, то что бы он ни делал с данными, это его проблеммы. Поэому нет необходимости защищать данные от произвольного доступа. От непроизвольного стоит - когда у нас есть много процесссов, неплохо, чтобы они не портили свои данные случайно.
  • Следующий уровень, на котором мы должны гораздо больше безопасности разводить - когда есть много субъектов одного класса. Считается, что у них нет серъёзных поражений в правах, условно говоря, это - некая команда, они имеют одинаковые уровни доступа к документам и т.д., но было бы неплохо защитить их данные от доступа друг друга, если они этого не хотят или если это запрещено уставом. Мы должны выработать механизм защиты от произвольного доступа и на этом остановиться. То есть, есть правило, определяющее, как организуется защита от произвольного доступа, в случае юникса вы руками выставляете права даоступа на свои файлы, в случае системы, где это регулируется сверху, будет некая матрица, по которой это будет видно.
  • Ещё более сложная ситуация наступает, когда в системе работают пользователи разных категорий, то есть такие, алгоритм определения прав доступа которых к объектам системы для каждой группы пользователей различен. Есть серьёзные пользователи, есть левые пользователи и т.д. То есть, в ситуации, когда к компьютеру присоединено двадцать терминалов, на каждом из которых сидит по одному человеку, это пользователи одной категории, а если к компьютеру может присоединиться кто угодно, мы явно имеем другую ситуацию - мы имеем небходимость разделения пользователей по категориям. Некоторые, которые подтвердили свою высокую категорию доступа, имеют одни права, некоторые - другие... Что при этом присходит с системой? Усложняется мехнизм идентификации (в случае мнгопользовательской машины, когда все люди сидят в одном классе, может не быть никакой идентификации - человек садится, в журнале расписывается, и ему каким-то образом обозначаются права; в случае, если человек присоединяется из сети - там совершенно непонятно что), и в системе должно быть предусмотрено такое понятие, как категории пользователей, для которых алгоритм определения прав доступа для каждой категории свой. Возможно даже, для одних пользователей это будет доступ по заранее заданным правилам, для других - они сами определяют, для третьих - определяет начальник и т.д.

Классическая юних-система носила на себе не реальную вот эту вот политику, а следы её.

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

Разумеется, ни о какой гибкости реализации этих механизмов на том уровне, о котором сказано выше, нельзя говорить. В идеале, группы и права доступа должны как-то моделироваться и задаваться. Например, при третьем уровне доступа правила вычисления прав доступа конкретного пользователя, принадежащего к конкретной группе, могут отличаться разительным образом, для одних ACL, для других - мандаты, для третьих ещё что-то... В юниксе это было сведено до некоторых упрощённых представлений, которые уже не зависят от того, какой у вас ранлевел. А именно, есть файловая система, есть пользователи и группы, у них есть жёсткие алгоритмы вычисления прав доступа одного к Вместо того, к другому, а вместо того, чтобы привязывать возможность делать всё, что угодно, с системой к 1 ранлевелу, это привязано к доверенному субъекту, пользователю, чей идентификатор равен 0. Фактически, классический юникс - очень упрощённая реализация требуемой военщиками трёхуровневой модели доступа. При этом, там уже есть некоторые отклонения, потому что не то, что вы умудрились получить шелл на первои ранлевеле, а то, что вы умудрились зарегистрироваться как рут, определяет, что вы крутой. И вы точно также можете зарегистрироваться как рут на втором или третьем ранлевеле и получить такой же самый уровень доступа.

Так вот, согласно этой архитектуре, действительно было возможно такое, что на первом уровне запускаются отдельные службы, на втором к ним добавляются службы, которые позволяют отличать пользователя от пользователя, и на третьем к ним добавляются службы которые организуют доступ произвольного пользователя из сети, если это нужно, и позволяют отличать пользователя по категории. Но уже в юниксе такого нет. Там устоялась следующая традиция: однопользовательский режим, многопользовательский режим, многопользовательский режим с сетью. Понятно, что сейчас про всё это забыли, реализация соответствующих мандатных прав доступа накладывается в линукс-системы сверху, селинуксом например, и алгоритм запуска процесса в ранлевеле тоже поменялся. Никто не проходит все ранлевелы подряд, а убиваются все одни сервисы, запускаются все вторые, в лучшем случае, те, которые там и там есть, просто не убиваются. Поэтому ранлевелами стали пользоваться как профилями системы с небольшим легаси, чтобы на пятом уровне запускался ещё и графический сервер. Ничего удивительного, что люди, которые родились в те самые поры, когда юних-системы стремительно модифицировались, а про мультикс все забыли, они, когда чего-то пишут, ранлевелами пользуются абы как. Просто знают, что 2,3,4,5 - это ранлевелы, где не-рут. То есть сводят модель к бинарному делению: однопользовательский режим, где один только рут, и многопользовательский режим, где всё. Поэтому на сегодняшний день есть большой бардак в sysvinit.

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


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

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

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

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

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

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

Level

Maintainer

Start date

End date

20

1

1

1

1

ConstantinYershow, DmitryChistikov, VsevolodKrishchenko


CategoryLectures CategoryPspo CategoryMpgu CategoryUneex

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