Unix системы что это для чайников

Глава 1 UNIX для начинающих

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

В более широком смысле под UNIX часто понимают не только ядро, но и такие важные компоненты, как компиляторы, редакторы, программы копирования и печати файлов. Сюда даже относят языки управления заданиями (командные языки). UNIX может также включать созданные вами или другими пользователями программы, работающие в вашей системе и предназначенные для подготовки документации, статистического анализа, или, скажем, «графические» средства. Значение слова «UNIX» в каждом конкретном случае зависит от того, на каком уровне вы рассматриваете систему. В дальнейшем изложении смысл этого термина вам будет ясен из контекста.

Иногда система UNIX кажется более сложной, чем она есть на самом деле. Новичку нелегко понять, как наилучшим образом воспользоваться доступными средствами. Но, к счастью, начинать работать в системе не так уж и трудно, а познакомившись с несколькими программами, вы получите достаточное стартовое ускорение. Цель настоящей главы помочь вам по возможности скорее освоить систему. Это не справочное руководство, а лишь краткий обзор приводимого в книге материала, причем многие вопросы будут рассмотрены более детально в последующих главах. Мы обсудим здесь следующие темы:

• основные понятия: вход и выход из системы, простые команды, исправление ошибок при вводе с терминала, связь между терминалами;

• повседневная работа: файлы и файловая система, печать файлов, каталоги, часто используемые команды;

• интерпретатор команд shell: сокращенная форма имен файлов, переключение ввода-вывода, программные каналы, установка символов удаления и стирания, задание вашего собственного пути поиска команд.

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

В заключение хотелось бы дать вам совет: не бойтесь экспериментировать. Если вы новичок, то существует очень мало ситуаций, в которых вы можете повредить себе или другим пользователям, так что изучайте свою систему методом «проб и ошибок». Первая глава довольно большая, и лучший способ ознакомиться с ней читать за один прием всего несколько страниц, постоянно экспериментируя.

Данный текст является ознакомительным фрагментом.

Продолжение на ЛитРес

Читайте также

Глава 1. Работа в операционной системе UNIX

Глава 1. Работа в операционной системе UNIX Сегодня UNIX используется на самых разнообразных аппаратных платформах — от персональных рабочих станций до мощных серверов с тысячами пользователей. И прежде всего потому, что UNIX — это многозадачная многопользовательская

Глава 2 Среда программирования UNIX

Глава 2 Среда программирования UNIX Одной из целей, которые изначально ставились перед разработчиками UNIX, являлось создание удобной среды программирования. Во многом это справедливо и сегодня.Разговор в данной главе пойдет о программировании в UNIX. Может показаться, что

Глава 15 Доменные протоколы Unix

Глава 15 Доменные протоколы Unix 15.1. Введение Доменные протоколы Unix — это не набор протоколов, а способ связи клиентов и серверов на отдельном узле, использующий тот же API, который используется для клиентов и серверов на различных узлах, — сокеты или XTI. Доменные протоколы Unix

Глава 7 Системные вызовы в UNIX

Глава 7 Системные вызовы в UNIX В настоящей главе мы рассмотрим самый низкий уровень взаимодействия с операционной системой UNIX системные вызовы. Они являются входами в ядро. Эти средства предоставляются операционной системой; все остальные средства построены на их

Глава 8. Wi-Fi для Unix

Глава 8. Wi-Fi для Unix Количество беспроводных функций для пользователей различных версий Unix является ограниченным, но они все же существуют. Мир драйверов для беспроводных адаптеров и сетевого программного обеспечения для систем Unix не так велик, как для Linux, но здесь

ГЛАВА 1 Обзор средств взаимодействия процессов Unix

ГЛАВА 1 Обзор средств взаимодействия процессов Unix 1.1. Введение Аббревиатура IPC расшифровывается как interprocess communication, то есть взаимодействие процессов. Обычно под этим понимается передача сообщений различных видов между процессами в какой-либо операционной системе. При

Что такое Internet? (глава для начинающих)

Что такое Internet? (глава для начинающих) O В этой главе O Архитектура InternetO Дерево протоколовO Пакеты в InternetO Назначение портовХакеры и InternetС точки зрения пользователя, Internet, — прежде всего совокупность серверов и сетевых ресурсов. Но это лишь верхушка айсберга. Разве не

Как взломать Internet (глава для самых начинающих)

Как взломать Internet (глава для самых начинающих) Нельзя все ломать, надо на чем-то и сидеть Народная мудрость «Как взломать Internet» — слышится буквально во всех конференциях, прямо или косвенно связанных с взломом, коммуникациями и сетями. Вопрос технически безграмотен, ибо

Первые шаги с UNIX (глава для начинающих)

Первые шаги с UNIX (глава для начинающих) O В этой главе:O Оболочки — что это такое?O Краткая история оболочек UNIXO Как узнать какая оболочка выполняется в данный моментO Как узнать, какие оболочки установлены на компьютереO Как просмотреть список файловO Немного о правах

Unix-строки (чтение и запись Unix-файлов)

Unix-строки (чтение и запись Unix-файлов) Данный модуль позволяет читать и записывать файлы формата Unix.unit StreamFile;interfaceUses SysUtils;Procedure AssignStreamFile(var f: text; FileName: String);implementationConst BufferSize = 128;Type TStreamBuffer = Array[1..High(Integer)] of Char; TStreamBufferPointer = ^TStreamBuffer; TStreamFileRecord = Record Case Integer Of 1: ( Filehandle: Integer; Buffer:

Для самых начинающих пользователей

Для самых начинающих пользователей Если вы в первый раз видите компьютер, хочу сделать несколько замечаний. То, на что вы смотрите — это не компьютер, а монитор, а та серая (белая/ черная/красная) коробка под столом — это системный блок, а не процессор. Процессор там,

Архитектура и стандарты операционной системы UNIX

Операционная система UNIX (читается уникс) — семейство переносимых, многозадачных и многопользовательских операционных систем с разделением времени. UNIX находится на вершине самых популярных в мире операционных систем благодаря тому, что ее сопровождает и распространяет большое число компаний и добровольцев со всего мира. Существуют много версии UNIX для многих систем, начиная от персонального компьютера, до суперкомпьютеров, таких как Cray Y-MP.

История

Система Multics. В 1965 году компания Bell Telephone Laboratories, объединив собственные труды с фирмой General Electric и проектом MAC Массачусетского научно-технического ВУЗа, обратилась к исследованию новейшей операционной системы, получившей имя Multics. Перед системой Multics были поставлены разнообразные цели, среди которых — обеспечить одновременный доступ к ресурсам ЭВМ множества пользователей, обеспечить необходимую скорость вычислений и хранение данных и дать возможность пользователям при необходимости коллективно использовать данные. Многие создатели, позднее участвовавшие в разработке ранних версий системы UNIX, приняли участие в работе над системой Multics в организации Bell Laboratories. В попытке усовершенствовать среду программирования, Кен Томпсон, Дэннис Риччи и некоторые другие сотрудники Исследовательского центра по информатике создали на бумаге проект файловой системы, который позднее получил развитие в ранних версиях UNIX.

Позднее, Томпсон получил доступ к малоиспользуемой машине под названием PDP – 7, что позволило ему изучить ее и выполнить свой проект системы, включавший в себя начальную версию файловой системы, систему обеспечения управления процессами и скудный набор утилит. Новая система получила название UNIX (аналогия с Multics). Придумал это название еще один сотрудник Исследовательского центра – Брайн Керниган.

Для работы в реальном проекте (обработка текстов) в 1971 году система была перенесена на машину PDP – 11.

В 1973 году система была переписана с использованием языка С, имеющего возможность генерировать машинный код, объявлять типы о определять структуру данных. Популярность системы быстро росла и уже к 1977 году количество машин, работавших под ее управлением, приближалось к 500.

UNIX оказалась простой и понятной для большинства разработчиков, благодаря чему начали развиваться самостоятельные направления системы. В течение 1977 – 82 годов фирма Bell Lab., объединив несколько наиболее удачных вариантов, выпустила UNIX версии 3. С 1983 года начала распространяться версия 5.

Причины популярности системы UNIX

Популярность и востребованность системы во многом объясняются следующими особенностями:

• Система написана на языке высокого уровня, благодаря чему ее легко читать, понимать, изменять и переносить на другие машины. Первый вариант системы на Си имел на 20-40 % больший объем и работал медленнее по сравнению с вариантом на ассемблере, однако преимущества использования языка высокого уровня намного перевешивают недостатки.
• Наличие довольно простого пользовательского интерфейса, в котором имеется возможность предоставлять все необходимые пользователю услуги.
• Наличие элементарных средств, позволяющих создавать сложные программы из более простых.
• Наличие иерархической файловой системы, легкой в сопровождении и эффективной в работе.
• Обеспечение согласования форматов в файлах, работа с последовательным потоком байтов, благодаря чему облегчается чтение прикладных программ.
• Наличие простого, последовательного интерфейса с периферийными устройствами.
• Система является многопользовательской, многозадачной; каждый пользователь может одновременно выполнять несколько процессов.
• Последовательность и простота вообще являлись и являются характерными для систем UNIX и UNIX – like.

Структура системы

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

Программы, подобные командному процессору shell (sh, ksh, bash), взаимодействуют с ядром при помощи хорошо определенного набора обращений к операционной системе. Обращения к операционной системе понуждают ядро к выполнению различных операций, которых требует вызывающая программа, и обеспечивают обмен данными между ядром и программой. Другие прикладные программы располагаются выше указанных программ, на верхнем уровне.

Многие прикладные программы, редакторы, программные пакеты и т.п. со временем становятся синонимичны понятию «система UNIX«. Однако, следует иметь ввиду, что все они пользуются ресурсами программ нижнего уровня и, в конечном счете, ядра. Т.е. в каноническом, наиболее правильном варианте понимания, к словам «система UNIX» относится именно ядро.

Первоначальная загрузка

Для того, чтобы перевести систему из неактивное состояние в активное, администратор выполняет процедуру «начальной загрузки». На разных машинах эта процедура имеет свои особенности, однако во всех случаях она реализует одну и ту же цель: загрузить копию операционной системы в основную память машины и запустить ее на исполнение.

В системе UNIX процедура начальной загрузки заканчивается считыванием с диска в память блока начальной загрузки (нулевого блока). Программа, содержащаяся в этом блоке, загружает из файловой системы ядро ОС (например, из файла с именем «/unix» или с другим именем, указанным администратором). После загрузки ядра системы в память, ядро запускается на выполнение.

Файловая система UNIX

Рассмотрим ключевые особенности данной системы, в первую очередь полезные для общего понимания UNIX. Итак, файлы характеризуются:

• Иерархической структурой,
• согласованной обработкой массивов данных,
• возможностью создания и удаления файлов,
• динамическим расширением файлов,
• защитой информации в файлах,
• трактовкой периферийных устройств как файлов.
• Файловая система представляет собой дерево, с единственной основой – корнем (root), обозначающимся как «/», а воглаве этого главного корня стоит главный супер администратор с логином «root» по умолчанию.

Каждая вершина в древовидной структуре файловой системы, кроме листьев, является каталогом файлов, а файлы, соответствующие дочерним вершинам, являются либо каталогами, либо обычными файлами, либо файлами устройств.

Каталоги похожи на обычные файлы в том смысле, что система представляет информацию в каталоге набором байтов, но эта информация включает в себя имена файлов в каталоге в объявленном формате.

Права доступа

Права доступа определяются установкой трех остальных флагов (битов разрешения) на файлах для 3–х действий: чтение, запись, выполнение. (rwx) Делается эта установка для 3–х разных случаев: для владельца файла, для групп и для общего пользования. Устанавливаются права при помощи комманды chmod -R ugo+rwx 0755 filename, chown -R user:group filename.

Устройства

Для пользователя система UNIX трактует устройства так, как если бы они были файлами. Устройства, для которых назначены специальные файлы устройств, становятся вершинами в структуре файловой системы. Обращение программ к устройствам имеет тот же самый синтаксис, что и обращение к обычным файлам; семантика операций чтения и записи по отношению к устройствам в большой степени совпадает с семантикой операций чтения и записи обычных файлов. Способ защиты устройств совпадает со способом защиты обычных файлов.

Процессы

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

Возможный набор состояний процесса содержится в следующем перечне:

1. Процесс выполняется в режиме задачи.
2. Процесс выполняется в режиме ядра.
3. Процесс не выполняется, но готов к запуску под управлением ядра.
4. Процесс приостановлен и находится в оперативной памяти.
5. Процесс готов к запуску, но программа подкачки (нулевой процесс) должна еще загрузить процесс в оперативную память, прежде чем он будет запущен под управлением ядра.
6. Процесс приостановлен и программа подкачки выгрузила его во внешнюю память, чтобы в оперативной памяти освободить место для других процессов.
7. Процесс возвращен из привилегированного режима (режима ядра) в непривилегированный (режим задачи), ядро резервирует его и переключает контекст на другой процесс.
8. Процесс вновь создан и находится в переходном состоянии; процесс существует, но не готов к выполнению, хотя и не приостановлен. Это состояние является начальным состоянием всех процессов, кроме нулевого.
9. Процесс вызывает системную функцию exit и прекращает существование. Однако, после него осталась запись, содержащая код выхода, и некоторая хронометрическая статистика, собираемая родительским процессом. Это состояние является последним состоянием процесса.
10. Диспетчеризация процессов в системе UNIX

В системе разделения времени ядро предоставляет процессу ресурсы центрального процессора (ЦП) на интервал времени, называемый квантом, по истечении которого выгружает этот процесс и запускает другой, периодически переупорядочивая очередь процессов. Алгоритм планирования процессов в системе UNIX использует время выполнения в качестве параметра. Каждый активный процесс имеет приоритет планирования; ядро переключает контекст на процесс с наивысшим приоритетом. При переходе выполняющегося процесса из режима ядра в режим задачи ядро пересчитывает его приоритет, периодически и в режиме задачи переустанавливая приоритет каждого процесса, готового к выполнению.

То есть, в соответствии с этим принципом ядро предоставляет процессу ресурсы ЦП на квант времени, по истечении которого выгружает этот процесс и возвращает его в одну из нескольких очередей, регулируемых приоритетами. Прежде чем процесс завершится, ему может потребоваться множество раз пройти через цикл с обратной связью. Когда ядро выполняет переключение контекста и восстанавливает контекст процесса, процесс возобновляет выполнение с точки приостановки.

Общий алгоритм диспетчеризации

Сразу после переключения контекста ядро запускает алгоритм планирования выполнения процессов, выбирая на выполнение процесс с наивысшим приоритетом среди процессов, находящихся в состояниях «резервирования» и «готовности к выполнению, будучи загруженным в память». Рассматривать процессы, не загруженные в память, не имеет смысла, поскольку не будучи загружен, процесс не может выполняться. Если наивысший приоритет имеют сразу несколько процессов, ядро, используя принцип кольцевого списка (карусели), выбирает среди них тот процесс, который находится в состоянии «готовности к выполнению» дольше остальных. Если ни один из процессов не может быть выбран для выполнения, ЦП простаивает до момента получения следующего прерывания, которое произойдет не позже чем через один таймерный тик; после обработки этого прерывания ядро снова запустит алгоритм планирования.

Системные часы / таймер

В функции программы обработки прерываний по таймеру входит:

• перезапуск часов
• вызов на исполнение функций ядра, использующих встроенные часы
• поддержка возможности профилирования выполнения процессов в режимах ядра и задачи
• сбор статистики о системе и протекающих в ней процессах
• слежение за временем
• посылка процессам сигналов «будильника» по запросу
• периодическое возобновление процесса подкачки
• управление диспетчеризацией процессов
• Некоторые из функций реализуются при каждом прерывании по таймеру, другие — по прошествии нескольких таймерных тиков.

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

Функции операционной системы

Данные функции довольно очевидны. Среди них:

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

Система UNIX позволяет таким устройствам, как внешние устройства ввода-вывода и системные часы, асинхронно прерывать работу центрального процессора. По получении сигнала прерывания ядро операционной системы сохраняет свой текущий контекст (застывший образ выполняемого процесса), устанавливает причину прерывания и обрабатывает прерывание. После того, как прерывание будет обработано ядром, прерванный контекст восстановится и работа продолжится так, как будто ничего не случилось. Устройствам обычно приписываются приоритеты в соответствии с очередностью обработки прерываний. В процессе обработки прерываний ядро учитывает их приоритеты и блокирует обслуживание прерывания с низким приоритетом на время обработки прерывания с более высоким приоритетом.

Особые ситуации связаны с возникновением незапланированных событий, вызванных процессом, таких как недопустимая адресация, задание привилегированных команд, деление на ноль и т.д.

Различают некоторое количество уровней прерывания. Их можно перечислить как (от высшего к низшему):

• Машинные сбои
• Системные часы
• Диск
• Сетевое оборудование
• Терминалы
• Программное прерывание
• Установка уровня прерывания на определенное значение отсекает прерывания этого и более низких уровней, разрешая обработку только прерываний с более высоким приоритетом.

Архитектура ядра UNIX

Мы будем рассматривать ядро системы как некоторую модель. Файловая подсистема и подсистема управления процессами, два главных компонента ядра. Файловая подсистема управляет файлами, размещает записи файлов, управляет свободным пространством, доступом к файлам и поиском данных для пользователей. Процессы взаимодействуют с подсистемой управления файлами, используя при этом совокупность специальных обращений к операционной системе, таких как open (для того, чтобы открыть файл на чтение или запись), close, read, write, stat (запросить атрибуты файла), chown (изменить запись с информацией о владельце файла) и chmod (изменить права доступа к файлу).

Подсистема управления файлами обращается к данным, которые хранятся в файле, используя буферный механизм, управляющий потоком данных между ядром и устройствами внешней памяти. Буферный механизм, взаимодействуя с драйверами устройств ввода-вывода блоками, инициирует передачу данных к ядру и обратно.

Данные в ядре и их структура

Большинство информационных структур ядра размещается в таблицах фиксированного размера, а не в динамически выделенной памяти. Простота алгоритмов ядра представляется более важной, чем сжатие последних байтов оперативной памяти. Обычно в алгоритмах для поиска свободных мест в таблицах используются несложные циклы и этот метод более понятен и иногда более эффективен по сравнению с более сложными схемами выделения памяти.

Структура процессов: управляющие и пользовательские.

Ядро системы не выделяет управляющие процессы в отдельный класс. К управляющим процессам, грубо говоря, относятся те процессы, которые выполняют различные функции по обеспечению благополучной работы пользователей системы. К таким функциям относятся форматирование дисков, создание новых файловых систем, восстановление разрушенных файловых систем, отладка ядра и др. С концептуальной точки зрения, между управляющими и пользовательскими процессами нет разницы. Они используют один и тот же набор обращений к операционной системе, доступный для всех. Управляющие процессы отличаются от обычных пользовательских процессов только правами и привилегиями, которыми они обладают.

Сверхоперативная память или КЕШ

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

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

Перед чтением информации с диска ядро пытается считать что-нибудь из буфера кеша. Если в этом буфере отсутствует информация, ядро читает данные с диска и заносит их в буфер, используя алгоритм, который имеет целью поместить в буфере как можно больше необходимых данных. Аналогично, информация, записываемая на диск, заносится в буфер для того, чтобы находиться там, если ядро позднее попытается считать ее. Ядро также старается свести к минимуму частоту выполнения операций записи на диск.

Плюсы и минусы КЕШ

Использование буферов позволяет внести единообразие в процедуру обращения к диску, поскольку ядру нет необходимости знать причину ввода-вывода, что упрощает проектирование системы.

Благодаря использованию буферного кеша, сокращается объем дискового трафика и время реакции и повышается общая производительность системы.

Так как ядро в случае отложенной записи не переписывает данные на диск немедленно, такая система уязвима для сбоев, которые оставляют дисковые данные в некорректном виде. Пользователь, запрашивающий выполнение операции записи, никогда не знает, в какой момент данные завершат свой путь на диск.

Использование буферного кеша требует дополнительного копирования .

При передаче большого количества данных дополнительное копирование отрицательным образом отражается на производительности системы, однако при передаче небольших объемов данных производительность повышается.

Представление файлов внутри системы

Систематизируя прошлую информацию, хочу отметить, что каждый файл в системе UNIX имеет уникальный индекс. Индекс содержит информацию, необходимую любому процессу для того, чтобы обратиться к файлу, например, права собственности на файл, права доступа к файлу, размер файла и расположение данных файла в файловой системе. Процессы обращаются к файлам, используя четко определенный набор системных вызовов.

У индексов можно выделить следующие поля:

• Идентификатор владельца файла (uid). Права собственности разделены между индивидуальным владельцем и «групповым» и тем самым помогают определить круг пользователей, имеющих права доступа к файлу. Суперпользователь имеет право доступа ко всем файлам в системе.
• Тип файла. Файл может быть файлом обычного типа, каталогом, специальным файлом,
• Права доступа к файлу. Система разграничивает права доступа к файлу для трех классов пользователей: индивидуального владельца файла, группового владельца и прочих пользователей
• Таблица адресов на диске, в которых располагается информация файла.
• Размер файла

Каждая строка выполненной команды трактуется в следующем порядке: тип файла, права доступа к файлу (ugo — пользователь, группы, остальные), количество ссылок на файл, имя владельца, имя группы, размер файла (в байтах), временной штамп и имя файла.

Модель безопасности UNIX

Модель безопасности UNIX довольно проста. В основе её лежит дискреционный механизм доступа — каждый объект в системе имеет владельца, который и устанавливает права доступа к объекту. Сами пользователи в системе фигурируют в виде процессов — программ, запущенных от их имени. Так как в операционной системе UNIX даже устройства представляются в виде файлов, достаточно для каждого из них хранить владельца и права на использование этого файла другими пользователями системы.

Но в операционной системе могут работать тысячи пользователей (а такая ситуация встречается и сейчас — на мэйнфреймах и других больших машинах). При этом списки доступа (ACL, Access Control List) для каждого файла разрастутся до гигантских размеров. Частично эту проблему решает добавление групп пользователей, но ведь их число тоже может быть очень большим. Создатели UNIX придумали более элегантное решение: для каждого файла задаются три группы прав — права владельца, права групп и права для всех остальных. Таким образом, все права на файл занимают лишь несколько байт.

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

Помимо комбинации из этих девяти прав доступа, каждый файл может иметь дополнительные флаги доступа: sticky-бит, специфичный для директорий, и suid-бит, применяемый для исполняемых файлов. Если пометить директорию sticky-битом, удалять файл в ней смогут только владельцы, а не все те, кто имеют права записи на эту директорию — это необходимо в «общих директориях», где создавать и удалять файлы может любой. Suid-бит — большая головная боль системных администраторов, он нужен для повышения прав программы на время запуска. Установка атрибута sticky-бит производится утилитой chmod.

Удаление sticky-бит выполняется при помощи комманды:

Установка sticky bit применима только к каталогам, установка sticky bit на файл в значительной степени является бесполезной, и он ничего не дает. На некоторых старых *NIX, когда sticky bit включен то исполняемый файл будет загружен в своп-памяти после первого исполнения, что значительно ускоряет все последующие исполнения.

В настоящее время sticky bit на файлы поддерживается только в HP-UX, NetBSD, и UnixWare. Solaris, похоже, отказались от этого в 2005 году. BSD 4.4-Lite выпуск сохранил sticky bit, но sticky bit был впоследствии удалён из OpenBSD (по состоянию на выпуск 3,7) и FreeBSD (по состоянию на выпуске 2.2.1); sticky bit на файлы остается в NetBSD.

Распределение основной (оперативной) памяти

Алгоритм планирования использования процессорного времени в сильной степени зависит от выбранной стратегии управления памятью. Процесс может выполняться, если он хотя бы частично присутствует в основной памяти; ЦП не может исполнять процесс, полностью выгруженный во внешнюю память. Тем не менее, основная память — чересчур дефицитный ресурс, который зачастую не может вместить все активные процессы в системе. Если, например, в системе имеется основная память объемом 8 Мбайт, то девять процессов размером по 1 Мбайту каждый уже не смогут в ней одновременно помещаться. Какие процессы в таком случае следует размещать в памяти (хотя бы частично), а какие нет, решает подсистема управления памятью, она же управляет участками виртуального адресного пространства процесса, не резидентными в памяти. Она следит за объемом доступного пространства основной памяти и имеет право периодически переписывать процессы на устройство внешней памяти, именуемое устройством выгрузки, освобождая в основной памяти дополнительное место. Позднее ядро может вновь поместить данные с устройства выгрузки в основную память.

В ранних версиях системы UNIX процессы переносились между основной памятью и устройством выгрузки целиком и, за исключением разделяемой области команд, отдельные независимые части процесса не могли быть объектами перемещения. Такая стратегия управления памятью называется свопингом (подкачкой). Такую стратегию имело смысл реализовывать на машине типа PDP-11, где максимальный размер процесса составлял 64 Кбайта. При использовании этой стратегии размер процесса ограничивается объемом физической памяти, доступной в системе.

Система BSD (версия 4.0) явилась главным полигоном для применения другой стратегии, стратегии «подкачки по обращению» (demand paging), в соответствии с которой основная память обменивается с внешней не процессами, а страницами памяти; эта стратегия поддерживается и в последних редакциях версии V системы UNIX. Держать в основной памяти весь выполняемый процесс нет необходимости, и ядро загружает в память только отдельные страницы по запросу выполняющегося процесса, ссылающегося на них.

Преимущество стратегии подкачки по обращению состоит в том, что благодаря ей отображение виртуального адресного пространства процесса на физическую память машины становится более гибким: допускается превышение размером процесса объема доступной физической памяти и одновременное размещение в основной памяти большего числа процессов. Преимущество стратегии свопинга состоит в простоте реализации и облегчении «надстроечной» части системы.

Demand paging

В машинах с объемом физической памяти 1 и 2 Мбайта могут исполняться процессы размером 4 или 5 Мбайт. Ограничение на виртуальный размер процесса, связанное с объемом адресуемой виртуальной памяти, остается в силе и здесь. Поскольку процесс может не поместиться в физической памяти, ядру приходится динамически загружать в память отдельные его части и исполнять их, несмотря на отсутствие остальных частей. В механизме подкачки страниц все открыто для пользовательских программ, за исключением разрешенного процессу виртуального размера.

Процессы стремятся исполнять команды небольшими порциями, которые именуются программными циклами или подпрограммами.

Когда процесс обращается к странице, отсутствующей в его рабочем множестве, возникает ошибка, при обработке которой ядро корректирует рабочее множество процесса, в случае необходимости подкачивая страницы с внешнего устройства. По мере выполнения процесса его рабочее множество видоизменяется в соответствии с используемыми процессом указателями страниц; увеличение размера памяти влечет за собой увеличение рабочего множества и, с другой стороны, сокращение числа ошибок в выполнении процесса.

Подсистема ввода/вывода

Подсистема управления вводом-выводом позволяет процессам поддерживать связь с периферийными устройствами, такими как накопители на магнитных дисках, терминалы, принтеры и сети, с одной стороны, и с модулями ядра, которые управляют устройствами и именуются драйверами устройств, с другой. Между драйверами устройств и типами устройств обычно существует однозначное соответствие: в системе может быть один дисковый драйвер для управления всеми дисководами, один терминальный драйвер для управления всеми терминалами и один ленточный драйвер для управления всеми ленточными накопителями. Если в системе имеются однотипные устройства, полученные от разных изготовителей — например, две марки ленточных накопителей, — в этом случае можно трактовать однотипные устройства как устройства двух различных типов и иметь для них два отдельных драйвера, поскольку таким устройствам для выполнения одних и тех же операций могут потребоваться разные последовательности команд. Один драйвер управляет множеством физических устройств данного типа. Например, один терминальный драйвер может управлять всеми терминалами, подключенными к системе. Драйвер различает устройства, которыми управляет: выходные данные, предназначенные для одного терминала, не должны быть посланы на другой.

Система поддерживает «программные устройства», с каждым из которых не связано ни одно конкретное физическое устройство. Например, как устройство трактуется физическая память, чтобы позволить процессу обращаться к ней извне, пусть даже память не является периферийным устройством.

Два типа устройств

В системе UNIX имеется два типа устройств — устройства ввода/вывода блоками и устройства неструктурированного или посимвольного ввода-вывода. Устройства ввода-вывода блоками, такие как диски, для остальной части системы выглядят как запоминающие устройства с произвольной выборкой; к устройствам посимвольного ввода-вывода относятся все другие устройства, в том числе терминалы и сетевое оборудование. Устройства ввода-вывода блоками могут иметь интерфейс и с устройствами посимвольного ввода-вывода.

Пользователь взаимодействует с устройствами через посредничество файловой системы. Каждое устройство имеет имя, похожее на имя файла, и пользователь обращается к нему как к файлу. Специальный файл устройства имеет индекс и занимает место в иерархии каталогов файловой системы. Файл устройства отличается от других файлов типом файла, хранящимся в его индексе, либо «блочный», либо «символьный специальный», в зависимости от устройства, которое этот файл представляет. Если устройство имеет как блочный, так и символьный интерфейс, его представляют два файла: специальный файл устройства ввода-вывода блоками и специальный файл устройства посимвольного ввода-вывода. Системные функции для обычных файлов, такие как open, close, read и write, имеют то же значение и для устройств.

Многопроцессорные системы

В классической постановке для системы UNIX предполагается использование однопроцессорной архитектуры, состоящей из одного ЦП, памяти и периферийных устройств. Многопроцессорная архитектура, напротив, включает в себя два и более ЦП, совместно использующих общую память и периферийные устройства, располагая большими возможностями в увеличении производительности системы, связанными с одновременным исполнением процессов на разных ЦП. Каждый ЦП функционирует независимо от других, но все они работают с одним и тем же ядром операционной системы. Поведение процессов в такой системе ничем не отличается от поведения в однопроцессорной системе — с сохранением семантики обращения к каждой системной функции — но при этом они могут открыто перемещаться с одного процессора на другой. Хотя, к сожалению, это не приводит к снижению затрат процессорного времени, связанного с выполнением процесса. Отдельные многопроцессорные системы называются системами с присоединенными процессорами, поскольку в них периферийные устройства доступны не для всех процессоров.

Проблемы многопроцессорных систем

Защита целостности структур данных ядра системы UNIX обеспечивается двумя способами: ядро не может выгрузить один процесс и переключиться на контекст другого, если работа производится в режиме ядра, кроме того, если при выполнении критического участка программы обработчик возникающих прерываний может повредить структуры данных ядра, все возникающие прерывания тщательно маскируются. В многопроцессорной системе, однако, если два и более процессов выполняются одновременно в режиме ядра на разных процессорах, нарушение целостности ядра может произойти даже несмотря на принятие защитных мер, с другой стороны, в однопроцессорной системе вполне достаточных.

Избежать этого можно при использовании одного из 3–х перечисленных способов:

1. Исполнять все критические операции на одном процессоре, опираясь на стандартные методы сохранения целостности данных в однопроцессорной системе;
2. Регламентировать доступ к критическим участкам программы, используя элементы блокирования ресурсов;
3. Устранить конкуренцию за использование структур данных путем соответствующей переделки алгоритмов.

Систему с двумя процессорами, один из которых — главный (master) — может работать в режиме ядра, а другой — подчиненный (slave) — только в режиме задачи, впервые реализовал на машинах типа VAX. Эта система, реализованная вначале на двух машинах, получила свое дальнейшее развитие в системах с одним главным и несколькими подчиненными процессорами. Главный процессор несет ответственность за обработку всех обращений к операционной системе и всех прерываний. Подчиненные процессоры ведают выполнением процессов в режиме задачи и информируют главный процессор о всех производимых обращениях к системным функциям. Выбор процессора, на котором будет выполняться данный процесс, производится в соответствии с алгоритмом диспетчеризации.

Проблема диспетчеризации в многопроцессорных системах

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

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

Семафоры

Семафор представляет собой обрабатываемый ядром целочисленный объект, для которого определены следующие элементарные (неделимые) операции:

• Инициализация семафора, в результате которой семафору присваивается неотрицательное значение;
• Операция (P), уменьшающая значение семафора. Если значение семафора опускается ниже нулевой отметки, выполняющий операцию процесс приостанавливает свою работу;
• Операция (V), увеличивающая значение семафора. Если значение семафора в результате операции становится больше или равно 0, один из процессов, приостановленных во время выполнения операции P, выходит из состояния приостанова;
• Условная операция (CP), уменьшающая значение семафора и возвращающая логическое значение «истина» в том случае, когда значение семафора остается положительным. Если в результате операции значение семафора должно стать отрицательным или нулевым, никаких действий над ним не производится и операция возвращает логическое значение «ложь».

Семафор — это структура, состоящая из поля блокировки (управляющего доступом к семафору), значения семафора и очереди процессов, приостановленных по семафору. Поле блокировки содержит информацию, открывающую во время выполнения операций типа P и V доступ к другим полям структуры только одному процессу. По завершении операции значение поля сбрасывается. Это значение определяет, разрешен ли процессу доступ к критическому участку, защищаемому семафором. В начале выполнения алгоритма операции P ядро предоставляет процессу право исключительного доступа к семафору и уменьшает значение семафора. Если семафор имеет неотрицательное значение, текущий процесс получает доступ к критическому участку. По завершении работы процесс сбрасывает блокировку семафора, открывая доступ к семафору для других процессов, и возвращает признак успешного завершения. Если же в результате уменьшения значение семафора становится отрицательным, ядро приостанавливает выполнение процесса, используя алгоритм: основываясь на значении приоритета, ядро проверяет поступившие сигналы, включает текущий процесс в список приостановленных процессов, в котором последние представлены в порядке поступления, и выполняет переключение контекста. Операция V получает исключительный доступ к семафору и увеличивает значение семафора. Если очередь приостановленных по семафору процессов непустая, ядро выбирает из нее первый процесс и переводит его в состояние «готовности к запуску».

Узкие места многопроцессорности

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

Заключение

В работе были описаны: полная структура системы UNIX, взаимоотношения между процессами, выполняющимися в режиме задачи и в режиме ядра, файловая система, методы защиты, а также аппаратная среда функционирования ядра операционной системы.

Операционная система UNIX обеспечивает надежную среду разработки и использования мобильных прикладных систем, одновременно представляя собой практическую основу для построения открытых программно-аппаратных систем и комплексов. Именно широкое внедрение в практику ОС UNIX позволило перейти от лозунга Открытых Систем к практической разработке этой концепции. Большой вклад в развитие направления Открытых Систем внесла деятельность по стандартизации интерфейсов ОС UNIX.

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

Разработкой и стандартизацией операционных систем UNIX занимается Open Group. The Open Group (букв. англ. открытая группа) — промышленный консорциум, созданный для установки нейтральных открытых технологических стандартов для вычислительной инфраструктуры. Сформировался при объединении X/Open с Open Software Foundation в 1996 году. The Open Group наиболее известна как сертифицирующий орган для торговой марки UNIX. В прошлом консорциум был наиболее известен в связи с публикацией Single UNIX Specification, расширяющей стандарты POSIX и являющейся официальным определением UNIX. В число членов группы входят покупатели и производители из отрасли информационных технологий, а также правительственные агентства, например, Capgemini, Fujitsu, Sun Microsystems, Hitachi, Hewlett-Packard, IBM, NEC, US Department of Defense, NASA и другие.

Ознакомится со стандартом «The Single UNIX® Specification, Version 2» можно по этой ссылке >>>

Что такое UNIX?

Тремя наиболее популярными операционными системами в мире являются Windows, Mac и Linux. Эти три операционные системы получают всю прессу, две из которых больше, чем вторая, и, вероятно, единственные, о которых вы слышали.

Что если я скажу вам, что две из трех самых популярных операционных систем на самом деле вобрали в себя основные принципы чего-то, называемого UNIX? Эти принципы являются основными понятиями системы с разделением времени, позволяющей нескольким пользователям одновременно получать доступ к одному мэйнфрейму.

Разработанная в 1970 году и разработанная как небольшая гибкая система, используемая исключительно программистами, UNIX быстро стала ведущей операционной системой для рабочих станций. Но сколько вы действительно знаете о UNIX?

UNIX и UNIX-подобные операционные системы — самые мощные и популярные многопользовательские и многозадачные операционные системы на рынке. Несколько лет UNIX разрабатывался для разных машин, включая современные системы POSIX, такие как Linux, его многочисленные варианты и Mac OS. Трудно поверить, что что-то такое могущественное может иметь такое скромное начало.

Разработанная в Bell Telephone Laboratories, или Bell Labs, несколькими программистами, UNIX была написана на языке программирования Си. Это позволило установить его практически на любом компьютере с компилятором Си. Одно это дало UNIX естественную мобильность, гибкость и позволяло использовать ее в качестве довольно мощного варианта в качестве операционной системы.

Помимо того, что Bell Labs была недорогой, она распространяла операционную систему в ее исходной языковой форме, что позволяло любому, кто в нее попал, модифицировать и настраивать ее для своих собственных целей. Это породило десятки различных версий UNIX на протяжении десятилетия, работающих на разных сайтах.

Bell Labs в конечном итоге распалась в 1984 году. Тем не менее, они начали продавать UNIX в попытке определить стандартную версию системы. Они разработали то, что многие считали слишком ограничительным, одним из них был Ричард Столлман, ответственный за проект GNU. Проект GNU является основой Linux, которую мы знаем сегодня, поскольку он состоит из ядра Linux, а не ядра UNIX.

Тем не менее, Linux был вдохновлен MINIX, которая была UNIX-подобной операционной системой, созданной для образовательных целей. Это привело к эффекту домино для большинства операционных систем, доступных сегодня. GNU / Linux является производной от UNIX, и, в свою очередь, многие современные операционные системы, включая Android, Chrome OS, Steam OS и огромное количество встроенных операционных систем для устройств, основаны на Linux.

Стандарт UNIX

Стандарт действительно появился, но не основанный ни на чем AT & T. Сегодня торговая марка UNIX принадлежит The Open Group . То же самое можно сказать и о Единой спецификации UNIX. Любая операционная система, использующая UNIX, должна была быть сертифицирована The Open Group и соответствовать Единой спецификации UNIX.

Как проиллюстрировано The Open Group:

Для тех, кто заинтересован в посещении ссылки на изображение, вот она.

POSIX, как упоминалось ранее, представляет собой семейство стандартов, определенных Институтом инженеров по электротехнике и электронике (IEEE). Они служат для уточнения и унификации интерфейсов прикладного программирования, предоставляемых UNIX-подобными операционными системами.

Это делает это так, когда вы пишете программу, основанную на стандартах POSIX, переносимость и функциональность упрощаются среди большого семейства производных UNIX, таких как Linux и Mac OS. Использование API или кода, не стандартизированного как часть POSIX для UNIX-подобных операционных систем, усложнит переносимость на другие UNIX-подобные системы.

Что такое программы, системы и подсистемы UNIX?

Команды UNIX выполняются в интерфейсе командной строки, предоставляемом оболочкой. Эта оболочка является программой, которая будет читать введенные команды и либо выполнять их самостоятельно, либо передавать их ядру.

«Ядро ядра» — это то, вокруг чего построены системы UNIX, которые управляют системой и другими процессами. Это ядро ​​операционной системы UNIX, которое напрямую взаимодействует с базовым оборудованием для предоставления набора стандартных сервисов. Подсистемы ядра могут включать управление процессами, управление файлами, управление памятью, управление сетью и другие.

Программы UNIX предназначены для разработки нескольких основных принципов, в том числе таких требований, как единственная цель, совместимость и работа со стандартизованным текстовым интерфейсом.

Когда дело доходит до функций UNIX, вот список нескольких выдающихся:

• Позволяет использовать одни и те же ресурсы для разных пользователей в одной системе.
• Обеспечивает многозадачность, при которой каждый пользователь может выполнять много процессов одновременно.
• Первая операционная система написана на языке высокого уровня, что позволяет легко переносить ее на другие машины с минимальными адаптациями.
• Иерархическая файловая структура, облегчающая доступ и обслуживание данных.
• Встроенные сетевые функции для легкого обмена информацией между пользователями.

Почему UNIX имеет значение

Помимо Windows и систем на базе Windows, большинство операционных систем, которые вы увидите, имеют философию, основанную на UNIX. Если вы посмотрите на терминал Mac OS X или файловую систему, вы заметите поразительное сходство с Linux. Оба из которых полностью отличаются от Windows. Это потому, что Linux и Mac OS являются UNIX-подобными системами.

Понимание этого поможет вам также понять, насколько важен и был UNIX. Одной из основных философий UNIX, используемых сегодня, является создание небольших модульных утилит, позволяющих выполнять особые задачи с исключительным уровнем эффективности. Знание терминала Mac OS также познакомит вас с терминалом Linux и наоборот. Это UNIX в двух словах.

UNIX-подобные системы полагаются на единую файловую систему для взаимодействия программ друг с другом. Windows-подобные системы полагаются на DOS. Это причина того, что только Windows-подобные системы имеют буквы дисков. Все остальные операционные системы имеют его так, что каждый файл в системе является частью единой иерархии каталогов. Опять же, все благодаря философии UNIX.

UNIX можно увидеть в архитектуре операционных систем, таких как BSD, Linux и Mac OS, полностью задуманной. Можно сказать, что без UNIX не было бы Mac OS, и вполне возможно, что то же самое можно сказать и о ее конкурентах, включая Windows.

Мы явно гиперболичны здесь. Тем не менее, вам придется признать, что UNIX сыграл важную роль в разработке каждой операционной системы, используемой сегодня. Если это не иллюстрирует важность UNIX и его философии, я не уверен, что будет.

Записки IT специалиста

Как показывает читательский отклик, интерес к решениям на базе Linux весьма и весьма велик, в тоже время уровень подготовки администраторов в этой области оставляет желать лучшего. Свидетельство тому, бесконечно повторяющиеся простейшие вопросы в комментариях. Во многом, это следствие того, что наши инструкции можно выполнить «дословно» и получить работающий, результат. Но есть и обратная сторона медали, такой подход не предусматривает появлению системных знаний, оставляя знание предмета на фрагментарном уровне.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Да, кроме практических материалов, мы всегда стараемся публиковать обзоры, посвященные какой-либо технологии в целом, или делаем обширные теоретические отступления, для того, чтобы читатель имел необходимый минимум знаний. Однако все они подразумевают, что читатель обладает базовыми знаниями системы в которой работает.

А как быть с теми, кто только делает свои первые шаги? К сожалению, в IT-сообществе существует некоторый снобизм, мол, чего об этом говорить, это и так все знают, или «гугл в помощь», забывая, что каждый из нас когда-то был новичком и с мистическим ужасом смотрел в черный экран Linux-консоли, абсолютно не понимая, куда он попал и что ему делать.

В итоге новичок, столкнувшись с первыми трудностями, вынужден идти искать знания в другом месте и хорошо если такое место удастся быстро найти. Поэтому мы решили выпустить небольшой цикл материалов, в котором на доступном уровне изложить основы администрирования Linux систем, буквально объясняя на пальцах «общеизвестные вещи», опытные пользователи могут пропустить данный цикл, а могут и прочитать, заодно обновив свои знания.

Итак, вы решили стать Linux администратором.

Немного перефразируем Маяковского «я б в Linux-админы пошел, пусть меня научат», именно так дело в большинстве случаев и обстоит. Есть необходимость, есть желание, есть базовый набор знаний по работе с Windows системами — все это пригодится при работе с Linux системами. Гораздо хуже если какая-либо составляющая отсутствует, тогда, наверное, стоит задуматься о неправильном выборе профессии.

Сразу о том, что нужно раз и навсегда забыть. Это «религиозные войны» и «религиозный фанатизм». Одинаково плохо отрицать возможности Linuх-систем, как и превозносить их, стремясь перевести на Linux все что нужно и не нужно. Запомните — операционная система — это инструмент, хороший специалист берет для каждой задачи наиболее подходящий, фанатик будет забивать гвозди микроскопом, потому что взять в руки молоток ему «религия не позволяет».

Даже больше, сама по себе операционная система не имеет никакой ценности, это всего лищь среда для запуска и выполнения некоторых служб и сервисов. Без софта система мертва. Возьмем для примера клон BeOS — Haiku, ну поставили, ну посмотрели — прикольно. А дальше что?

Итак, вы решили стать. Прежде всего будьте готовы воспринимать новое, в частности новый подход к администрированию, постаравшись на время забыть о сложившихся привычках. На долгое время вашим основным инструментом станет консоль.

Для привыкшего к графическим инструментам Windows-администратора это может показаться сложным. Но следует твердо усвоить одну истину — консоль является единственным полноценным инструментом администрирования Linux и совсем не означает ограниченность в возможностях или неполноценность системы. Даже наоборот, командная строка позволяет выполнить многие задачи намного быстрее и проще, чем графические инструменты администрирования.

Но существуют же графические инструменты администрирования, скажет иной читатель, панели там разные, или можно же поставить графическую оболочку. Можно, но не нужно. Почему? Внимательно посмотрите на схему ниже:

Linux, создававшийся по образу и подобию UNIX-систем, является полноценной системой и без графической оболочки, более того мы можем запустить, закрыть или вообще сменить графическую оболочку без какого-либо влияния на работоспособность системы и даже без ее перезагрузки. Завершили сеанс Gnome, запустили KDE, а потом и вовсе вышли в консоль. Поэтому все инструменты управления системой разработаны для использования в режиме командной строки. А все панели и графические инструменты являются всего лишь надстройкой над ними.

Windows долгое время разрабатывался по принципиально иной технологии, графическая оболочка была поставлена в основу системы и долгое время даже выполнялась на уровне ядра (семейство Win 9x). Поэтому все инструменты администрирования были изначально графическими, а инструменты командной строки скорее их дополняли, чем заменяли. Любой, кто занимался восстановлением Windows, знает, что возможности инструментов командной строки там существенно ограничены и предназначены в первую очередь для восстановления системы, а не для ее администрирования.

Ситуация стала меняться с выходом PowerShell и Core-версий Windows Server. Несмотря на то, что сегодня графическая оболочка продолжает играть существенную роль в Windows-системах, администраторы получили в руки альтернативный инструмент — консоль PowerShell, которая позволяет полноценно администрировать Windows в режиме командной строки. При этом возможности PowerShell сразу завоевали популярность в среде специалистов, так как позволяют выполнять многие задачи быстрее и проще, чем графические инструменты.

А еще режим командной строки дает неограниченные возможности в создании собственных скриптов и сценариев, позволяющих выполнять сложные последовательности действий в автоматическом режиме или по расписанию.

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

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

Если вы еще не передумали становиться Linux-администратором, то поедем дальше и рассмотрим отличия в архитектуре системы.

Ядро и драйвера

Основу любой операционной системы составляет ядро. Существует несколько различных архитектур ядра, Linux, как и подавляющее большинство UNIX систем, использует монолитное ядро, Windows наоборот использует концепцию микроядра, хотя по-настоящему архитектура Windows микроядерной не является, принято считать, что Windows использует гибридное ядро.

Особенностью монолитного ядра является то, что все драйвера оборудования также являются частью ядра. Ранее, при изменении аппаратной части, ядро надо было пересобирать, сегодня монолитные ядра используют модульную схему, т.е. динамически позволяют загружать необходимые модули, отвечающие за тот или иной функционал. Т.е. добавив в систему новое устройство, мы должны динамически загрузить соответствующий модуль ядра, а если такого модуля нет, то работа с устройством окажется невозможной. В качестве решения мы можем собрать модуль самостоятельно, но при этом модуль будет скомпилирован под текущую версию ядра и при его смене модуль нужно будет перекомпилировать.

В микроядерной и гибридной архитектурах, драйвера, хоть могут и работать на уровне ядра, его частью не являются и от версии ядра не зависят. Поэтому мы можем без проблем обновлять ядро или использовать один и тот-же драйвер для всех версий систем с общей структурой ядра. Например, в Windows для всего семейства современных ОС, от Windows Vista до Windows 8.1, часто используется один и тот-же драйвер.

Это не значит, что Linux в этом плане хуже, иная архитектура предусматривает иные подходы. Практически это означает только одно — к выбору оборудования для серверов надо относиться более внимательно, стараясь чтобы все основные устройства поддерживались ядром вашего дистрибутива. Особенно это касается сетевых карт. Будет очень неприятно, если после каждого обновления ядра вам придется бегать в серверную, подключать к серверу монитор и клавиатуру и заново собирать модуль ядра.

По сути, такого понятия как драйвер, в Linux системах не существует. Оборудование либо поддерживается ядром, либо нет. Несомненный плюс монолитного ядра — оно самодостаточно. Если все оборудование поддерживается — поставил и забыл, самое время вспомнить ситуацию, когда под Windows нет драйвера сетевой карты и диск утерян.

Файловая система

Мы не будем касаться конкретных файловых систем, тут проблем возникнуть не должно, если администратор работал с Windows системами, то что такое файловая система и чем FAT отличается от NTFS он знает, поэтому разобраться в разнице между ext3, ext4 и, скажем, ReiserFS для него особого труда не составит. А поговорим о фундаментальных отличиях. В отличие от Windows, файловая система Linuх иерархична. Она начинается от корня, который обозначается знаком / (слеш), и имеет древовидную структуру. При этом абсолютно не имеет значения, что отдельные части файловой системы могут находиться на других разделах или вообще физических дисках.

Рассмотрим еще одну схему.

В Windows каждый раздел имеет собственную файловую систему и обозначающую его букву. Все пути к файлам и папкам начинаются с буквы, т.е. от корня раздела. Так если у нас на первом физическом диске, на втором логическом разделе была папка DATA, то путь к ней соответственно будет как D:\DATA, если мы захотим перенести ее на второй жесткий диск, то ее пусть изменится на E:\DATA. В ряде случаев это жутко неудобно, так как путь надо изменить во всех местах ее использования и даже существуют соответствующие утилиты.

В Linux подход кардинально иной. Самое время познакомиться с термином точка монтирования, который означает место файловой системы, куда подключается устройство хранения данных. Например, мы хотим вынести домашние каталоги пользователей на отдельный раздел, как на схеме выше, для этого нам нужно смонтировать второй логический раздел первого физического диска sda2 в /home. После чего перенести туда все пользовательские данные. Для системы и программ это произойдет абсолютно прозрачно, они как использовали абсолютный путь, скажем /home/andrey/data, так и будут его использовать. Добавили еще один диск и хотим вынести туда директорию /var? Нет проблем, останавливаем использующие каталог службы, монтируем sdb1 в /var и переносим данные, запускаем службы.

Всё есть файл

Еще один основополагающий принцип, который унаследован от UNIX-систем. В Linux всё есть файл: устройства, диски, сокеты и т.д., например, открыв /var/run мы увидим pid-файлы, соответствующие каждой запущенной службе в системе, а в /dev файлы каждого подключенного к системе устройства:

Что это дает? Не будем вдаваться в подробности, а разберем несколько простых примеров. Скажем, нужно создать образ оптического диска. В Windows нам понадобится для этого специализированное ПО, в Linuх все проще, CD-ROM — это блочное устройство, но в тоже время — это файл, файл блочного устройства. Берем соответствующий инструмент и копируем содержимое файла устройства в файл ISO образа:

Хотим заменить жесткий диск? Нет ничего проще, копируем содержимое одного файла блочного устройства в файл другого блочного устройства:

И не нужно никаких Partition Magic.

Другая ситуация, какое-либо ПО настоятельно ищет библиотеку lib-2-0-1.so, а у нас есть совместимая с ней, но более новая, lib-2-1-5.so, как быть? Создаем символическую ссылку на lib-2-1-5.so с именем lib-2-0-1.so и все будет работать. Потому что все есть файл и символическая ссылка тоже тип файла. А теперь попробуйте подсунуть Windows приложению lib-2-0-1.lnk вместо lib-2-1-5.dll.

Или нам нужно сохранить вывод какой-либо команды. Например, команда

выведет на экран сведения о сетевых адаптерах системы:

А теперь вспоминаем, что все есть файл, в том числе и устройство отображения (экран), поэтому просто перенаправим стандартный поток вывода вместо экрана в нужный нам файл:

После чего вывод команды будет сохранен в файл 123.txt в корневой директории пользователя:

Потоки и конвейер

В прошлом примере мы затронули стандартный поток вывода. В Linux существуют стандартные для всех процессов потоки ввода-вывода данных stdin, stdout и поток вывода ошибок stderr. Что это значит? Как минимум то, что процесс обмена данными между различными процессами стандартизован. Это позволяет создавать конвейеры, когда стандартный поток вывода одной команды передается стандартному потоку ввода другой. Например, мы хотим посмотреть список установленных пакетов в системе, в частности пакеты squid. Для этой цели есть команда:

Ээээ. Это что такое и как тут что-то понять? На экране быстро промелькнули сведения о всех установленных в системе пакетах и все что мы можем видеть, это «хвост» этого вывода:

Но ведь нам и не нужен весь вывод этой команды, нас интересуют исключительно пакеты squid. Поэтому направим вывод этой команды на ввод другой, которая уже отберет и покажет то, что нам нужно:

Вот это совсем другое дело!

Причем конвейер может быть сколь угодно длинным, результат работы одной команды можно передавать второй, от второй к третьей и т.д. Еще один пример из жизни. Вам надо получить все строки вашего конфигурационного файла squid, но без комментариев и пустых строк, чтобы, например, выложить на форуме или отправить другу. Можно конечно скопировать все, но вряд-ли кто-то захочет вам помогать, прокручивая полотно стандартного файла squid.conf, большая часть которого комментарии и примеры. Делаем проще:

И вот что у нас получилось:

Просто и понятно, все опции как на ладони. Это стало возможным в результате использования конвейера трех команд, первая вывела в поток содержимое файла, вторая отобрала все строки кроме комментариев, а третья удалила пустые, результат мы направили в файл.

Буквы большие, буквы маленькие

Linux, как и UNIX, является регистрозависимой системой. И это надо помнить! Потому что, в отличие от Windows, myfile.txt, Myfile.txt и myfile.TXT — это три разных файла. В целях совместимости с другими системами не стоит этим злоупотреблять и хранить файлы, имя которых отличается только регистром, а хорошим тоном считается использование в именах только строчных букв.

Расширения и типы файлов

В Windows системах тип файла определяется его расширением, если мы переименуем exe-файл в jpg, то он не запустится, и система будет пытаться обработать его как картинку. В Linux тип файла определяется по его содержимому и расширение используется исключительно для совместимости с другими системами или для удобства пользователя. Возможность исполнения файла обеспечивается установкой соответствующего атрибута. Так в Windows чтобы сделать скрипт исполняемым, надо было изменить расширение с txt на bat, в Linux для этого нужно сделать файл исполняемым. Непонимание этого момента приводит к ситуациям, когда начинающий администратор не понимает, почему его скрипт myscript.sh не выполняется. На самом деле расширение .sh нужно только для удобства, чтобы сразу было ясно, это скрипт Bash Shell, а чтобы он работал, ему надо поставить атрибут исполняемого, а называться он может как угодно, хоть myscript.pupkin-vasya.

Стесняюсь спросить.

Позвольте, скажет иной читатель, это ведь сколько всего надо помнить: синтаксис команд, ключи, опции и т.д., и т.п. Тут нужно справочник покупать или всегда интернет под рукой держать. Вовсе нет, достаточно помнить названия команд, это как раз несложно, по сложившимся в UNIX традициям, командам дают короткие и удобные имена. А все остальное можно спросить у системы. Вопреки распространенному мнению, Linux системы прекрасно документированы. Посмотреть синтаксис и ключи любой команды можно запустив ее с ключом —help, а так как описания обычно не помещаются на один экран, то следует перенаправить вывод справки утилите more, которая выведет информацию поэкранно. Допустим, нас интересует команда grep:

Более подробную информацию можно получить с помощью команды man:

К сожалению, информация на английском, но знание технического английского, хотя бы на уровне «читаю со словарем» необходимое требование к системному администратору. Вам ничего не напоминает последний скриншот? Правильно, OpenNET.

Нисколько не умаляя значение этого ресурса, можно сказать, что взяв на вооружение команду man и базовые познания в английском, OpenNET вы будете посещать гораздо реже.

Заключение

Надеемся, что после прочтения данной статьи начинающие администраторы будут лучше себе представлять устройство Linux-систем и их принципиальные отличия от привычного им Windows. Это позволит в дальнейшем правильно интерпретировать получаемую информацию и складывать из нее целостную картину функционирования системы, которая перестанет быть «черным ящиком», а команды «китайской грамотой».

Также хотим обратить внимание, что в наших примерах мы использовали только стандартные инструменты, что еще раз показывает все богатство инструментов администрирования, несмотря на то, что они работают только в командной строке. Вернемся к последнему примеру — выводу конфига squid, а теперь подумайте, каким образом это можно было бы сделать при помощи графических инструментов и сколько времени бы это заняло?

Не нужно бояться командной строки, Linux предоставляет в руки администратора очень мощный набор инструментов, который позволяет успешно решать все возникающие задачи без привлечения сторонних средств. Когда вы освоите хоть часть этих возможностей, то Linuх перестанет казаться вам сложным, а консоль мрачной, наоборот, даже располагая графической оболочкой вы будете запускать терминал, окунаясь в привычную и понятную среду, понимая, что системой управляете именно вы и делаете именно то, что хотите, а не что, что задумали разработчики очередной панели.

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Дополнительные материалы:

Помогла статья? Поддержи автора и новые статьи будут выходить чаще:

Или подпишись на наш Телеграм-канал: