itmo_conspects

Администрирование в ОС Linux

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

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

Курс разделен на несколько блоков:

  1. Работа с файлами
  2. Файловые системы
  3. Процессы и управление ресурсами
  4. Межпроцессорное взаимодействие
  5. Загрузка операционной системы
  6. Механизмы контейнеризации
  7. Управление пользовательским ПО
  8. Графические среды

Лекция 1. Введение в Linux

Linux (в части случаев GNU/Linux) - это семейство открытых и свободных Unix-подобных операционных систем на базе ядра Linux, включающих набор утилит и программ проекта GNU, а также другие системные и прикладные компоненты

Linux начал своё развитие в 1991 году, когда Линус Торвальдс, будучи студентом Хельсинкского университета, опубликовал первую версию ядра Linux как учебный и исследовательский проект

Со временем вокруг ядра Linux сформировалось большое сообщество разработчиков, а сам Linux стал использоваться в серверах, настольных системах, мобильных и других устройствах

Разделяют бесплатное ПО, открытое ПО и свободное ПО:

Linux является свободным программным обеспечением и распространяется под лицензией GNU General Public License 2.0. Это означает, что операционная система Linux гарантирует пользователю 4 свободы, сформулированные Ричардом Столлманом, основателем проекта GNU:

Лицензия GNU General Public License 2.0 накладывает обязательство на то, что производные работы также должны распространяться на условиях этой лицензии

Linux включает набор утилит и программ GNU, такие как Bash или GNU Compiler Collection, которые тоже являются свободным ПО

Linux распространяется не только в виде ядра, но и в виде дистрибутивов - готовых комплектов программного обеспечения, включающих ядро, системные утилиты, менеджер пакетов, установщик и часто графическую среду. Сейчас популярные дистрибутивы - это Debian, Ubuntu, Fedora, Arch Linux и другие

Дистрибутивы Linux бесплатные, но не все. Так, например, Red Hat Enterprise Linux распространяется по платной модели, имея открытый код, но за плату предлагается расширенная корпоративная поддержка и сервис

Ключевые отличия свободного ПО и проприетарного ПО заключаются:

Долгое время наиболее популярной настольной операционной системой остаётся Microsoft Windows. Рассмотрим ключевые концептуальные отличия Linux от Windows:

Лекция 2. Файлы и права доступа

В Linux и других Unix-подобных системах все объекты являются файловыми дескрипторами, то есть все действия совершаются через универсальный интерфейс

Файловый дескриптор - это идентификатор, за которым закреплен определенный поток ввода и вывода. Через файловые дескрипторы в Linux можно работать:

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

Всего можно выделить 7 типов файлов:

Используя команду ls -l, можно посмотреть на информацию о файлах в каталоге, например:

crw-r--r--   1 root      root       10,   235 Feb 13 17:59 autofs
drwxr-xr-x   2 root      root             180 Feb 13 17:59 block
crw-rw----   1 root      disk       10,   234 Feb 13 17:59 btrfs-control
drwxr-xr-x   3 root      root              60 Feb 13 17:59 bus
drwxr-xr-x   2 root      root            4920 Feb 13 17:59 char
crw-------   1 root      root        5,     1 Feb 13 17:59 console
lrwxrwxrwx   1 root      root              11 Feb 13 17:59 core -> /proc/kcore
drwxr-xr-x  14 root      root             280 Feb 13 17:59 cpu
crw-------   1 root      root       10,   259 Feb 13 17:59 cpu_dma_latency

Первый столбец обозначает тип файла и его модификаторы доступа. Первая буква - это тип файла, так:

Следующие 9 букв задают права доступа для файла. В Linux действует ролевая модель доступа, поэтому есть такие понятия:

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

Так -rwxr-xr-x означает регулярный файл, читать и исполнять который могут все, а записывать только владелец

Права доступа проверяются слева направо. Так, если файл имеет права ----r-xr-x, то его владелец не сможет с ним ничего сделать, несмотря на то, что он находится в группе файла

Помимо этих 9 модификаторов есть еще 3 скрытых:

Права можно установить для файла с помощью команды chmod (от change mode):

chmod права файл

Права указываются:

Второй столбец - это число жесткий ссылок на файл

Третий столбец из вывода ls -l указывает на владельца файла, а четвертый - на группу владельца (так как пользователь может состоять в нескольких группах). Сменить владельца можно с помощью команды chown (от change owner):

# меняет владельца на pelmeshke
chown pelmeshke /var/log/mylogs/app.log

# меняет владельца на pelmeshke и группу на supercoolusers
chown pelmeshke:supercoolusers /var/log/mylogs/app.log

# меняет владельца на pelmeshke рекурсивно 
# для всех файлов и каталогов в /var/log/mylogs
chown -R pelmeshke /var/log/mylogs/

По умолчанию, при создании пользователя в Linux ядро создает группу с таким же именем. Для смены группы файла есть команда chgrp (от change group):

# меняет группу на supercoolusers
chgrp supercoolusers /var/log/mylogs/app.log

Лекция 3. Файловые системы

Файловая система - это способ организации информации на носителе данных

Файловая система выполняет такие функции:

Файловая система является посредником в общении между пользователем, использующим ОС, и жестким диском

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

Взаимодействие с хранилищами

Файловые системы могут использовать множество методов организации:

  1. Линейное размещение
  2. Связный список
  3. Таблица аллокаций файлов
  4. Индексные дескрипторы

Подробнее об этом описано в курсе “Операционные системы”

Современные операционные системы используют файловые системы с индексными дескрипторами для дисков, на которых установлена система. Так, Windows использует NTFS (New Technology File System), а для Linux рекомендуется ext4 (от Fourth Extended, Четвертая расширенная файловая система)

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

Поле Тип данных Назначение
s_inodes_count __le32 Общее количество индексных дескрипторов
s_blocks_count_lo __le32 Общее количество блоков (младшие 32 бита)
s_r_blocks_count_lo __le32 Зарезервированные блоки (младшие 32 бита)
s_free_blocks_count_lo __le32 Свободные блоки (младшие 32 бита)
s_free_inodes_count __le32 Количество свободных индексных дескрипторов
s_first_data_block __le32 Первый блок данных
s_log_block_size __le32 Логарифм размера блока в килобайтах по основанию 2
s_log_cluster_size __le32 Логарифм размера кластера в килобайтах по основанию 2
s_blocks_per_group __le32 Блоков в группе
s_clusters_per_group __le32 Кластеров в группе
s_inodes_per_group __le32 Индексных дескрипторов в группе
s_mtime __le32 Время последнего монтирования
s_wtime __le32 Время последней записи
s_mnt_count __le16 Счётчик монтирований после проверки диска
s_max_mnt_count __le16 Максимальное число монтирований, после который нужна проверка диска
s_magic __le16 Магическое число, для ext4 - это 0xEF53
s_state __le16 Состояние файловой системы
s_errors __le16 Поведение при ошибках
s_minor_rev_level __le16 Минорная версия
s_lastcheck __le32 Время последней проверки
s_checkinterval __le32 Интервал проверки
s_creator_os __le32 Операционная система, создавшая раздел (Linux - это 0x0000, FreeBSD - это 0x0003)
s_first_ino __le32 Первый незарезервированный индексный дескриптор
s_inode_size __le16 Размер индексного дескриптора (обычно 256 байт)
s_block_group_nr __le16 Номер группы (для копии суперблока)
s_uuid __u8[16] UUID файловой системы
s_volume_name char[16] Имя тома

… и много других

Здесь __le16, __le32 - беззнаковые целые числа, записанные в Little-endian, размером 16 бит и 32 бита соответственно, __u8[16] - 16-байтный массив беззнаковый 8-битных чисел, а char[16] - символьная последовательность

Источник: https://docs.kernel.org/next/filesystems/ext4/super.html

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

Для решения этого появились группы блоков. Группы содержат свои битовые карты, таблицы индексных дескрипторов и блоки данных

Первая группа под индексом 0 хранит суперблок и таблицу дескрипторов блочных групп (Block Group Descriptors) - структуры с данными полями:

Поле Тип данных Назначение
bg_block_bitmap_lo __le32 Номер блока битовой карты блоков (младшие 32 бита)
bg_inode_bitmap_lo __le32 Номер блока битовой карты дескрипторов (младшие 32 бита)
bg_inode_table_lo __le32 Первый блок таблицы индексных дескрипторов (младшие 32 бита)
bg_free_blocks_count_lo __le16 Количество свободных блоков в группе
bg_free_inodes_count_lo __le16 Количество свободных дескрипторов в группе
bg_used_dirs_count_lo __le16 Количество каталогов в группе
bg_flags __le16 Флаги состояния группы
bg_exclude_bitmap_lo __le32 Блок битовой карты снимков исключения (Exclusion Snapshot)
bg_block_bitmap_csum_lo __le16 Контрольная сумма битовой карты блоков
bg_inode_bitmap_csum_lo __le16 Контрольная сумма битовой карты дескрипторов
bg_itable_unused_lo __le16 Количество неинициализированных индексных дескрипторов
bg_checksum __le16 Контрольная сумма дескриптора группы

… и другие поля

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

Источник: https://docs.kernel.org/next/filesystems/ext4/group_descr.html

Далее идет битовая карта блоков (Block Bitmap). В ней один бит, равный 1, обозначает, занят ли конкретный блок с тем же индексом

Затем расположена подобная битовая карта для индексных дескрипторов (Inode Bitmap), где бит 1 обозначает, занят ли индексный дескриптор в таблице дескрипторов

Источник: https://docs.kernel.org/next/filesystems/ext4/bitmaps.html

После этого расположена сама таблица индексных дескрипторов. Таблица представляет собой массив дескрипторов, где индекс - это номер индексного дескриптора

Для специальных индексных дескрипторов выделены особые индексы:

9-ый и 10-ый дескрипторы зарезервированы и используются для функций, который обозначены ? в документации, а 11-ый дескриптор - первый не зарезервированный, но обычно используется для каталога /lost+found/, который предназначен для восстановленный утилитой fsck файлов после сбоя

Источник: https://www.kernel.org/doc/html//latest/filesystems/ext4/special_inodes.html

Наконец, после таблицы индексных дескрипторов дальше идут сами блоки данных

Разметка в ext4

В файловой системе ext3 добавилась система журналирования - способ восстановления данных в результате нештатной работы ОС или диска

Всего есть три типа журналов в ext3:

  1. Journal - самый медленный, но самый надежный журнал. Сначала в журнал пишутся блоки данных, потом они копируются в нужное место, а дескриптор изменяется
  2. Ordered - метаданные записываются в журнал до записи данных на диск, но сами данные на диск отправляются до подтверждения метаданных в дескрипторе
  3. Writeback - сначала пишем весь файл, а потом изменяем все метаданные в дескрипторе и журнале

В системе ext4 добавилось много новых функций, которые убирали ограничения старых версий системы:

Хорошей практикой является разделение диска на 6 разделов:

В корневом каталоге Linux создает множество подкаталогов для работы системы, структура которых подчиняется стандарту (FHS) Filesystem Hierarchy Standard:

Filesystem Hierarchy Standard

Лекция 4. Процессы, часть I

Процесс - совокупность набора исполняемых команд, ассоциированных с ним ресурсов и контекста исполнения, находящиеся под управлением операционной системы

Сам же процесс в Linux хранится структурой task_struct с множеством полей, таких как:

В Linux процессы порождаются с помощью других процессов, таким образом, образуя дерево

Дерево процессов

Дерево как структура было выбрано по нескольким причинам:

Первый процесс - это процесс init или systemD, который является корнем одного поддерева процессов

Создание процесса

Для создания процессов могут использоваться три системных вызова:

Жизненный цикл процесса

У процесса в Linux есть состояние в зависимости от того, исполняется ли он прямо сейчас, ждет потока ввода/вывода или находится вне оперативной памяти. Состояние помогает при управлении планировании исполнения процессов:

Жизненный цикл процесса в Linux

Подробнее о состояниях процессов описано в курсе “Операционные системы”

Завершение процесса

После того, как процесс окончил исполнения (то есть вызвал системный вызов _exit(status_code)), процесс переходит в состояние “Зомби”. В нем он будет находится до тех пор, пока родительский процесс не прочитает код выхода процесса. Родитель может сделать это несколькими способами:

Демоны

Отдельное место в Linux занимают демоны. Демон (Daemon) - это фоновый процесс, который работает непрерывно и независимо от пользовательской сессии. Он ожидает событий или запросов и обрабатывает их без участия пользователя

Название “демон” происходит из греческой мифологии — демон был фоновым духом, действующим от имени других

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

Первый демон, появляющийся при запуске Linux, - это поток [kthreadd] с идентификатором 2. Он является корнем поддерева фоновых потоков ядра, таких как [kswapd0] - демон для страничного обмена, [migration/0] - демон для переноса процессов между ядрами и так далее

Для создания демонов можно:

Лекция 5. Процессы, часть II

Сигнал

В операционной системе процессы имеют изолированное адресное пространство, изолированное исполнение, изолированное планирование и не могут повлиять на другие процессы. Поэтому для общения процессы помимо файловой системы могут использовать сигналы

Сигнал - это сообщение, которое процесс получает от операционной системы или другого процесса. С точки зрения процесса сигнал выглядит как прерывание

Согласно стандарту POSIX, сигналы делятся на стандартные и сигналы реального времени

В Linux всего 31 стандартный сигнал. Рассмотрим самые распространенные из них:

Имя Код Назначение Действие по умолчанию
SIGHUP (от hang up) 1 Процесс завершается, а дочерние процессы получает этот сигнал, чтобы тоже завершиться. Ранее использовался для обозначения прерывания телефонной связи между терминалом и пользователем (дословно “положить трубку”) 🛑
SIGINT (от interrupt) 2 Прерывание выполнения команд от клавиатуры (в терминале вызывается по комбинации Ctrl+C) 🛑
SIGQUIT 3 Прерывание с дампом ядра (обычно Ctrl+\), посылается всем процессам группы 🛑📦
SIGILL (от illegal) 4 Сигнал, посланный ядром, который означает, что выполнявшаяся инструкция является неправильной с точки зрения архитектуры процессора 🛑📦
SIGFPE (от floating point exception) 8 Ошибочная арифметическая операция 🛑📦
SIGKILL 9 Немедленное принудительное завершение процесса 🛑
SIGUSR1 и SIGUSR2 10 и 12 Сигналы, определенные пользователем 🛑
SIGSEGV (от segmentation fault) 11 Нарушение доступа к памяти, например, доступ к еще невыделенной странице 🛑📦
SIGPIPE 13 Процесс написал в именованный канал, но нет процесса, который мог бы прочитать это 🛑
SIGTERM (от terminate) 15 Сигнал завершения 🛑
SIGCHLD, также SIGCLD (от child) 17 Дочерний процесс завершился, был остановлен или продолжил исполнение 🙈
SIGCONT (от continue) 18 Процесс продолжает исполнение ▶️
SIGSTOP 19 Перевод процесса в состояние “Остановлен” ⏸️
SIGTSTP 20 Сигнал остановки с терминала по комбинации Ctrl+Z ⏸️

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

Здесь код сигнала указан для архитектур x86 и ARM. В других архитектурах (например, MIPS или SPARC) код сигнала может отличаться

Среди этих все, кроме SIGKILL и SIGSTOP, можно перехватить и переопределить обработчики, например, назначить на SIGINT правильной завершение процесса. На сигналы SIGKILL и SIGSTOP операционная система принудительно убивает или переводит процесс в состояние “Остановлен” соответственно

Сигналы реального времени используются для обычных программ. Они не имеют определенного значения, и всего их может быть до 33 – они определены интервалом от SIGRTMIN (чаще всего 34 или 35) и SIGRTMAX (64). Так как разные имплементации потоков библиотеки glibc используют первые 1 или 2 сигнала для своих задач, рекомендуется использовать SIGRTMIN + 3 вместо 37 или 38

Гарантируется, что сигналы реального времени придут процессу в том же порядке, что они были отправлены. Также, если такой сигнал был послан функцией sigqueue, то процесс-приемник может получить число или указатель на дополнительные данные

Источник: https://www.man7.org/linux/man-pages/man7/signal.7.html

Планирование процессов

Подробнее про планирование процессов описано в курсе “Операционные системы”

За время развития операционной системы Linux существовало множество планировщиков:

В Linux можно выделить 2 типа процессов:

Рассмотрим, как работает Completely Fair Scheduler

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

Сами процессы с vruntime должны где-то храниться, причем операции добавления удаления должны быть быстрыми. По этой причине выбрали красно-черное дерево - процессы отсортированы по величине vruntime, а само дерево является самобалансирующимся, то есть в любой момент времени его высота примерно равна log N, а все операции имеют сложность O(log N)

Красно-черное дерево в CFS

Подробнее про CFS: https://www.kernel.org/doc/html/latest/scheduler/sched-design-CFS.html, https://developer.ibm.com/tutorials/l-completely-fair-scheduler/
Исходный код CFS: https://github.com/torvalds/linux/blob/v6.5/kernel/sched/fair.c

Completely Fair Scheduler полагался на множество эвристик и параметров, чтобы корректно работать с интерактивными и фоновыми задачами

Новый алгоритм Earliest eligible virtual deadline first вместо этого имеет математический подход. В нем есть три понятия:

На каждом шаге EEVDF:

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

Статья про EEVDF: https://citeseerx.ist.psu.edu/document?doi=805acf7726282721504c8f00575d91ebfd750564&repid=rep1&type=pdf
Документация про EEVDF: https://docs.kernel.org/scheduler/sched-eevdf.html

Псевдофайловая система /proc/

Для доступа к сведениям процессов есть псевдофайловая система /proc/, которая представляет из себя набор файлов для каждого процесса. При чтении одного из файлов в этом подкаталоге данные достаются не из диска, а из оперативной памяти

Директория /proc/ содержит множество поддиректорий вида /proc/<PID> с числовыми названиями. Это число представляет из себя идентификатор процесса, а поддиректория хранит информацию о процессе, а именно:

Помимо информации для каждого процесса /proc/ хранит общую информацию об операционной системе

Лекция 6. Загрузка ОС Linux

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

Загрузка BIOS/UEFI

Сначала запускается BIOS - Basic Input/Output System (Базовая система ввода/вывода). BIOS не является полноценной операционной системой: это прошивка материнской платы, которая выполняет начальную инициализацию оборудования и передает управление загрузчику. В начале запуска компьютера BIOS проводит процедуру POST (Power-On Self-Test) - проверяет работоспособность оборудования (процессора, ОЗУ и так далее)

BIOS узнает о загрузочном коде напрямую из таблицы MBR (Master Boot Record, Главная загрузочная запись), которая расположена в начале любого диска, с которого можно загрузится (или через PXE - Preboot eXecution Environment)

Master Boot Record занимает первый 512 байт (первый сектор на диске) и содержит:

Сейчас же вместо BIOS повсеместно используется UEFI - Unified Extensible Firmware Interface (Единый расширяемый интерфейс прошивки). UEFI - это более современная прошивка, которая поддерживает графический интерфейс, управление мышью и обычно работает с таблицей разделов GPT (GUID Partition Table)

Программный код BIOS и UEFI расположены непосредственно на микросхеме на материнской плате компьютера

Загрузчик GRUB

Далее рассмотрим загрузку Linux в BIOS. BIOS загружает выбранный исполняемый код, который находится в MBR, в ОЗУ, и процессор исполняет его. Для загрузки Linux используют особой компонент - загрузчик. Сейчас самый используемый - это GNU GRUB (GRand Unified Bootloader) версии 2

BIOS

Код из Master Boot Record содержит 1 фазу загрузчика GRUB boot.img - он занимает 440 байт, что недостаточно для полноценной загрузки

boot.img далее запускает фазу 1.5 загрузчика - core.img. Он находится между MBR и первым разделом диска, в нем расположен код базового набора драйверов для файловых систем (ext4, xfs и так далее), для работы с массивом RAID или LVM (Logical Volume Manager, менеджер логических томов). Как правило, размер core.img составляет от 30 до 40 Кб (как правило 62 сектора на диске, максимальный размер - 458 240 байт)

После этого core.img уже может читать файлы из раздела загрузчика (после загрузки он монтируется как /boot/grub и как правило, находится на другом разделе, чем /). core.img загружает код загрузчика из /boot/grub, который прочитывает файл grub.cfg, где находится выбор ОС (в случае Linux это выбор ядра или его версии) - так начинается фаза 2. GRUB запускает графическое меню, где можно выбрать ядро и его параметры:

Меню GRUB

UEFI

Для компьютеров с UEFI все намного проще. UEFI является намного более умным, чем BIOS, и его память на материнской плате содержит драйвера для работы с дисками (в частности для файловых систем FAT16 и FAT32), устройствами USB и сетью

Также UEFI хранит загрузочные записи - они хранят идентификатор GUID раздела и путь до кода загрузчика в специальном разделе ESP (EFI System Partition)

Далее при запуске UEFI ищет на диске этот скрытый раздел ESP, который отформатирован в FAT16 или FAT32. На этом разделе хранятся загрузчики разных ОС и другие инструменты (например, для проверки памяти или для отладки ядра)

При загрузке Linux этот раздел монтируется в /boot/EFI. Структура этого каталога выглядит примерно так:

/boot/EFI
├── ARCH
│   └── grubx64.efi
├── BOOT
│   ├── BOOTIA32.EFI
│   ├── BOOTX64.EFI
│   ├── fbia32.efi
│   └── fbx64.efi
├── Microsoft
│   ├── Boot
│   │   ├── bootmgfw.efi
│   │   ├── bootmgr.efi
│   │   ├── boot.stl
│   │   ├── memtest.efi
│   │   ├── SecureBootRecovery.efi
│   │   └── ...
│   └── Recovery
│       └── ...
└── systemd
    └── systemd-bootx64.efi

Главный загрузчик для Windows, Windows Boot Manager, находится в файле Microsoft/bootmgfw.efi. Для Linux (в данном случае дистрибутива Arch Linux) загрузчик расположен в ARCH/grubx64.efi. В BOOT лежит загрузчик по умолчанию: операционная система сначала создает свой загрузчик в BOOT, затем копирует его в отдельную директорию и создает запись в памяти UEFI

Сам файл grubx64.efi представляет собой код из core.img - набор базовый модулей, необходимый для чтения раздела в ext4, конфигурационного файла grub.cfg и загрузки дополнительных модулей

Помимо этого UEFI еще может загружаться через сеть. Для этого он, предварительно получив IP-адрес по протоколу DHCP, скачивает по протоколу TFTP файл bootx64.efi и запускает его

Загрузка ядра

После выбора записи загрузчик GRUB помещает в память образ ядра Linux vmlinuz и образ начальной файловой системы initramfs, а затем передает управление ядру

Для управления загрузкой используется строка аргументов (та, что в последствии находится в /proc/cmdline). В командной строке ядра можно указать путь до vmlinux, путь до корневого раздела (в том числе можно указать UUID диска), режимы загрузки (например, однопользовательский), настройки оборудования, ограничения ресурсов (таких как ОЗУ или ядра ЦПУ) и подобное. Например, строка:

linux /vmlinuz-5.15.0 root=/dev/sda1 ro quiet splash

запускает ядро из /vmlinuz-5.15.0, корневой раздел с диска /dev/sda1, который доступен только в режиме для чтения, с подавлением большинства сообщений ядра (“тихий режим”) и с графическим экраном загрузки

Сам файл vmlinuz - это сжатый образ ядра. Исторически название расшифровывают как vm (virtual memory, виртуальная память) + linu (linux) + z (zipped - сжатый образ). В оперативной памяти ядро распаковывается, переходит в защищенный режим работы процессора, настраивает таблицы страниц, обработчики прерываний, планировщик и начинает обнаружение устройств

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

Именно поэтому вместе с ядром загружается initramfs (от Initial RAM Filesystem) - небольшой архив, который распаковывается в оперативную память и превращается во временную корневую файловую систему

Внутри initramfs обычно находятся:

Раньше до версии ядра 2.6 вместо initramfs использовался initrd (Initial RAM Disk), который монтировался как блочное устройства

Обычно дальше идут такие процессы:

  1. Ядро распаковывает initramfs в память
  2. Запускается ранняя пользовательская программа /init. /init загружает нужные модули ядра и подготавливает устройства
  3. Находится и монтируется настоящий корневой раздел. Затем выполняется переключение корня из initramfs, который находится в ОЗУ, в файловую систему раздела на диске
  4. Управление передается уже обычной системе в корневом разделе

Если корневой раздел недоступен, система часто попадает в аварийную оболочку из initramfs, где администратор может вручную диагностировать проблему

Система инициализации

Когда настоящее корневое дерево каталогов уже доступно, ядро запускает первый пользовательский процесс с идентификатором PID = 1. Исторически это была программа init, а в современных дистрибутивах чаще всего таким процессом становится systemd

Процесс PID = 1 - это особый процесс, так как:

Если ядро не может запустить процесс с PID = 1, загрузка прекращается с паникой ядра

SysV init

Классическая система инициализации init, которая появилась в UNIX System III и получила развитие в UNIX System V (сейчас такой init называют SysV init), использовала набор sh-скриптов из каталогов вида /etc/rc*.d/. Они запускались последовательно в соответствии с выбранным уровнем выполнения (так называемым runlevel), который описаны в /etc/inittab.Формат строк в /etc/inittab такой:

<идентификатор>:<уровни исполнения>:<действие>:<командная строка запуска>

В System V уровни выполнения в init были такими:

В распространенных дистрибутивах, таких как Debian, уровни означали другое:

Уровень 1 обычно предназначен для загрузки ОС и ее восстановления

В файле /etc/inittab поле <действие> определяет режим запуска процесса, например:

Сам файл /etc/inittab может выглядеть так:

# Уровень выполнения по умолчанию
id:5:initdefault:

# Скрипт, выполняемый при загрузке системы (до уровней выполнения)
si::sysinit:/etc/rc.d/rc.sysinit

# Запуск скриптов для конкретного уровня выполнения
l0:0:wait:/etc/init.d/rc 0
l1:1:wait:/etc/init.d/rc 1
l2:2:wait:/etc/init.d/rc 2
l3:3:wait:/etc/init.d/rc 3
l4:4:wait:/etc/init.d/rc 4
l5:5:wait:/etc/init.d/rc 5
l6:6:wait:/etc/init.d/rc 6

# Действие при нажатии Ctrl+Alt+Del - перезагрузка
ca::ctrlaltdel:/sbin/shutdown -t3 -r now

# Действие при кратковременном сбое питания (перезагрузка через 2 минуты)
pf::powerwait:/sbin/shutdown -f -h +2 "Power Failure; System Shutting Down"

# Запуск виртуальной консоли
1:2345:respawn:/sbin/mingetty tty1

Здесь /etc/init.d/rc - скрипт, который запускает другие скрипты из каталога /etc/rc<уровень>.d. Уровень - это первый аргумент вызова /etc/init.d/rc

В каталоге /etc/rc.d/rc<уровень>.d скрипты обычно имеют такое наименование: K<NN><имя_сервиса> или S<NN><имя_сервиса>. Буква K означает, что сервис нужно остановить при выходе из уровня, а S означает, что его нужно запустить при переходе в этот уровень

Другая команда, sysinit, выполняется один раз перед переходом в любой уровень исполнения. Ее задачи:

В большинстве современных дистрибутивов сейчас вместо SysV init используется systemd. Он запускает службы параллельно, использует декларативные файлы вида и умеет отслеживать зависимости между компонентами системы

О нем подробно описано в разделе systemd

Подытоживая, загрузку ОС Linux можно описать так:

Загрузка ОС Linux

Последовательность загрузок разных частей операционной системы расширяет функционал до тех пор, пока система может взаимодействовать с оборудованием, и решает проблему “курицы и яйца”

X. Программа экзамена 2025/2026

  1. Отличия ОС семейства GNU/Linux от других ОС с точки зрения администрирования.
  2. Понятие файла в операционных системах GNU/Linux. Типы файлов. Атрибуты файлов.
  3. Управление правами доступа к файлам и директориям.
  4. Организация файловых систем в ОС GNU/Linux: особенности файловых систем ext2, ext3, ext4.
  5. Структуры данных файловых систем ext3, ext4: структура группы блоков; структура суперблока; структура индексного дескриптора.
  6. Монтирование файловых систем. Ручное и автоматическое монтирование.
  7. Понятие процесса в GNU/Linux. Рождение процесса.
  8. Процессы-демоны. Сигналы.
  9. Отображение структур данных о процессе в псевдофайловую систему /proc/
  10. Загрузка операционной системы Linux: Организация работы загрузчика. Загрузка ядра. Стартовый виртуальный диск.
  11. Загрузка операционной системы GNU/Linux по модели System V: стандартный процесс init: структура файла inittab, условия выполнения команд, уровни выполнения, скрипты sysinit и rc.
  12. Запуск ОС GNU/Linux по моделям UpStart и SystemD.
  13. Установка пользовательского программного обеспечения в операционных системах GNU/Linux. Способы установки, их отличия и области применения.
  14. Установка пользовательского ПО из исходного кода.
  15. Пакетная установка пользовательского ПО: внутреннее устройство пакетов Debian.
  16. Пакетная установка пользовательского ПО: внутреннее устройство пакетов RPM.

Extra 1. Современные системы инициализации

Данный конспект был основан на записи лекции №9 (*тык*) с канала А. В. Маятина

Система инициализации init из UNIX System V в своей архитектуре имела недостаток: скрипты установленного уровня выполнения исполнялись последовательно единожды непосредственно после загрузки ОС. Из-за этого:

Upstart

В 2006 году компания Canonical, которая поддерживает дистрибутив Ubuntu, разработала замену - систему Upstart

Upstart был основан на событиях, которые заменили уровни исполнения. Такими событиями были:

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

Upstart стал системой инициализации в Ubuntu в 2006, в Fedora и Red Hat Enterprise Linux в 2010

Сама же система Upstart работает так: есть список заданий (job), которые как правило либо сервисы, либо краткосрочные задачи. Само описание заданий хранится в конфигурационных файлах /etc/init/<задание>.conf. Upstart постоянно отслеживает изменения в этих файлах

  1. При старте демон init (из /sbin/init) читает все описания заданий из /etc/init/
  2. Загруженное задание находится в цели stop и состоянии waiting и ждет наступления указанного в нем события
  3. Как только событие происходит, цель задания меняется на start, и оно последовательно проходит стадии: starting -> pre-start -> spawned -> post-start -> running
  4. Когда наступает событие для остановки, цель меняется на stop, и задание переходит в цепочку состояний: pre-stop -> stopping -> killed -> post-stop -> waiting

Само описание может выглядеть так:

# Описание сервиса
description "Мой сервис"

# Условия запуска: когда система переходит на "обычный" уровень
# и когда сетевые интерфейсы подняты
start on (runlevel [23] and net-device-up IFACE=eth0)

# Условия остановки: когда система выключается или перезагружается
stop on runlevel [!23]

# Команда, выполняемая при запуске сервиса
exec /usr/bin/my-server

# Перезапуск при падении
respawn

Несмотря на это, Upstart имел много недостатков:

В 2010 появилась система инициализации systemd. Далее с 2015 года systemd поставлялась во всех дистрибутивах, заменив Upstart и SysV init. Это привело к прекращению разработки Upstart в сентябре 2014 года

systemd

В конце 2009 года инженеры Леннарт Пёттеринг и Кей Зиверс из компании Red Hat сформулировали основные принципы будущей системы, которая бы заменила SysV init и Upstart. Тогда архитектор Леннарт Пёттеринг заметил, что:

Все эти недочеты были учтены в новой системе - systemd

Также systemd заменила уровни выполнения на цели. Цели представляли целевые состояния ОС, такие как многопользовательский режим или режим с графической подсистемой

Вместо заданий в systemd появились юниты. Юниты описывались текстовыми файлами в каталоге /usr/lib/systemd/system/, а расширение указывало на тип юнита:

Внутри текстовый файл содержит ее описание. Например, простой сервис может выглядеть так:

[Unit]
Description=My Application
After=network.target        # нужна цель `network`

[Service]
User=myappuser              # запустить от имени myappuser
ExecStart=/usr/bin/myapp    # исполняемый файл
Restart=on-failure          # перезапустить при падении
StandardOutput=journal      # записывать логи в журнал systemd

В секции [Unit] указывались зависимости сервиса:

В секции [Install] можно указать обратные зависимости:

При загрузке systemd читает конфигурацию, монтирует файловые системы, поднимает сеть, запускает системные службы и доводит систему до нужного целевого состояния, например до multi-user.target (многопользовательский режим) или graphical.target (режим с графической оболочкой)

Также systemd предоставляет инструменты для управления юнитами

Кроме этого вместо привычного названия процесса init появилось /usr/lib/systemd/systemd, что критиковалось многими консерваторами

Но у systemd есть недостатки:

Тем не менее сейчас почти все популярные дистрибутивы используют systemd

Другие системы инициализации

Помимо популярного systemd немногие дистрибутивы используют менее громоздкие решения

Extra 2. Механизмы контейнеризации

Контейнеризация - это метод виртуализации на уровне операционной системы, позволяющий запускать приложения в изолированных окружениях, которые называют контейнерами

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

В операционной системе Linux контейнеризация возможна с помощью этих механизмов:

  1. Пространства имён (Namespaces) отвечают за изоляцию процессов, создавая иллюзию того, что контейнер владеет собственным экземпляром системы
  2. Контрольные группы (cgroups) отвечают за ограничение и учёт ресурсов, потребляемых группой процессов
  3. И других, таких как объединённые файловые системы

Пространства имён

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

Linux поддерживает несколько типов пространств имён, каждый из которых изолирует определённый аспект системы:

  1. Cgroup - изолирует корневую директорию контрольных групп, чтобы процесс в контейнере видел свою иерархию контрольных групп.
  2. IPC (от Inter-Process Communication) - изолирует ресурсы для межпроцессного взаимодействия (такие как очереди сообщений или разделяемая память)
  3. Network - изолирует сетевые устройства, стеки, порты и таблицы маршрутизации
  4. Mount - изолирует точки монтирования файловых систем
  5. PID (от Process ID) изолирует пространство идентификаторов процессов. Процесс внутри контейнера видит только свои процессы и считает, что его идентификатор равен 1, а не реальному идентификатору на хосте
  6. Time - изолирует системное время, позволяя контейнеру иметь своё представление о времени (появилось в Linux 5.6)
  7. User - изолирует идентификаторы пользователей и групп, что позволяет процессу в контейнере быть пользователем root внутри контейнера
  8. UTS (от UNIX Time-Sharing System) - изолирует имена хоста и домена NIS (Network Information Service, системы для распространения конфигурации между несколькими узлами)

Самый простой способ создать пространств имён - это использовать утилиту unshare. Она запускает программу в новых, изолированных пространствах имён. Например, для создания пространства UTS используется команда:

sudo unshare --uts /bin/bash

Далее командой hostname <новое имя хоста> можно задать другое имя. Для создания других пространств используются флаги --ipc, --mount, --net, --pid, --uts, --user, --cgroup, --time

Важно заметить, что для создания пространства PID нужно использовать флаг --fork, иначе просто изменится псевдофайловая система /proc

Контрольные группы

Контрольные группы позволяют ограничивать, приоритизировать и учитывать использование таких ресурсов, как центральный процессор, память, ввод/вывод диска и сеть

Существует две версии контрольных групп:

Начиная с Linux 5.10, вторая версия является предпочтительной, и многие современные дистрибутивы используют её по умолчанию

Все операции с контрольными группами второй версии производятся через псевдофайловую систему cgroup2, которая обычно смонтирована в /sys/fs/cgroup

Далее, чтобы создать контрольную группу, нужно:

  1. Создать директорию для новой группы:

     sudo mkdir /sys/fs/cgroup/my-group

    Созданная директория наполнится нужными файлами. Группы могут выстраивать иерархию с наследованием ограничений

  2. Настроить лимиты в нужных файлах

  3. Запустить процесс и поместить его в группу - для этого нужно записать идентификатор процесса в файл cgroup.procs:

     echo $APP_PID | sudo tee /sys/fs/cgroup/my-group/cgroup.procs

Всего контроллеров во второй версии контрольных групп девять:

Список доступных контроллеров можно узнать в файле /sys/fs/cgroup/cgroup.controllers. Чтобы добавить контроллер, можно воспользоваться командой:

echo "+cpu" | sudo tee /sys/fs/cgroup/cgroup.subtree_control

Управлять списком контроллеров можно в каждой группе, выстраивая иерархию. Контроллер создает нужные файлы в каталоге группы, например:

Другие механизмы изоляции

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

Для этого используют veth (Virtual Ethernet) - пару виртуальных сетевых интерфейсов, которые действуют как туннель

Обычно один конец пары veth1 помещается в сетевое пространство имён контейнера, а другой veth0 остаётся на хосте или подключается к сетевому мосту

Чтобы контейнер имел доступ к внешней сети, на хосте необходимо настроить трансляцию адресов - это позволит контейнеру выходить в интернет через IP-адрес хоста

Для изоляции файловой системы внутри используются два основных системных вызова:

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

Одна из первых реализаций была UnionFS. Сейчас используют OverlayFS, которая устроена через три слоя:

Для обеспечения атомарности операций используется 4-ый каталог workdir

Когда процесс читает файл из merged, OverlayFS сначала ищет его в upperdir. Если его там нет, то файл ищется в lowerdir. Все операции записи (создание, изменение, удаление) всегда происходят только в upperdir

Создать объединенную файловую систему можно с помощью команды mount:

sudo mount -t overlay overlay \
  -o lowerdir=$HOME/overlayEX/lower,upperdir=$HOME/overlayEX/upper,workdir=$HOME/overlayEX/work \
  $HOME/overlayEX/merged

Сейчас на практике используют Docker - платформу контейнеризации, которая упрощает работу с пространствами имён, контрольными группами и объединёнными файловыми системами

Extra 3. Установка ПО, пакетные менеджеры

Данный конспект был основан на записи лекций №10 (*тык*), №11 (*тык*), №12 (*тык*) с канала А. В. Маятина

Скомпилированное ядро поставляется в виде сжатого образа vmlinuz, который содержит ПО, нужные модули для управления аппаратным обеспечением и интерфейс системных вызов для взаимодействия с ядром. Ядро не содержит:

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

Из-за этого установка ПО совершается кодом из пользовательского пространства системы. Ключевые проблемы появления программ, которые устанавливают ПО, это:

Всего есть 3 способа:

  1. Установка из исходного кода - пользователь скачивает архив с исходным кодом, далее пользователь сам находит нужные зависимости и компилирует программу

  2. Установка из локального пакета

    Пакет отличается от архива с исходным кодом тем, что содержит вместо кода готовый исполняемый файл и информацию о программе (версия, автор, зависимости). Также пакет содержит нужные скрипты, которые сами устанавливают нужные зависимости, решают конфликты других пакетов и их версий, а также добавляют программу в /usr/bin

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

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

  3. Установка из удаленного репозитория

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

    Удаленные репозитории также отвечают за безопасность предоставляемого ПО. Разработчик может криптографически подписать пакет своим приватным ключом. Далее при отправки репозиторий проверяет, что этот пакет действительно от этого разработчика

    Современные дистрибутивы поставляют свои пакетные менеджеры:

    • С дистрибутивами Ubuntu и Debian идет пакетный менеджер dpkg (от Debian Package), который управляется через apt (Advanced Package Tool)
    • С дистрибутивами Fedora и Red Hat Enterprise Linux идет rpm (RPM Package Manager, ранее Red Hat Package Manager), который управляется через утилиту dnf (от Dandified YUM, буквально “изысканная вкуснятина”). Ранее вместо dnf использовалась утилита yum (от Yellowdog Updater, Modified)
    • С дистрибутивом Arch Linux идет пакетный менеджер pacman (сокращение от package manager)

Как правило последний способ самый удобный, так как, введя всего лишь одну команду (например, apt install fastfetch), можно установить программу и пользоваться. Но, чтобы пакет попал в удаленный репозиторий, он должен пройти нужные проверки, в том числе проверку на востребованность - затратно поддерживать пакет, который почти не востребован и к тому же усложняет граф зависимостей

Помимо этого дистрибутивов Linux очень много, поэтому делать пакеты для каждого дистрибутива осмелиться не каждый разработчик

По этой причине в Linux существуют все 3 способа

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

Установка ПО из исходного кода

Как правило, исходный код хранится в архиве с расширением .tar.gz. Сначала каталог с файлами:

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

В случае проектов на языке C используется утилита Make. Тогда в каталоге будет файл Makefile, в нем, как правило, указаны действия для 4 целей:

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

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

./configure   # создание конфигурации
make          # компиляция
make install  # установка

Установка ПО из пакета

Если для выбранного ПО существует пакет под нужный дистрибутив, то можно установить его вместо сборки исходного кода

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

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

Рассмотрим два распространенных формата

Пакет формата deb

Такой формат используется в дистрибутивах Ubuntu, Debian, Linux Mint и других производных

Пакет формата deb представляет архив с расширением .deb (архивация происходит через утилиту ar). В этом архиве есть 3 файла в таком порядке:

В архиве control.tar.gz находятся файлы, которые не устанавливаются в систему напрямую, а используются пакетным менеджером dpkg для управления установкой. Ключевые файлы в нем:

В другом архиве data.tar.gz содержатся файлы, которые будут скопированы в файловую систему: исполняемые файлы, библиотеки, документация и так далее. Пути к файлам внутри архива указываются относительно корня файловой системы. Содержимое архива может выглядеть так:

usr
├── bin
│   └── flashfetch
└── share
    ├── fastfetch
    │   └── presets
    │       └── ...
    ├── man
    │   └── man1
    │       └── fastfetch.1
    └── ...

Таким образом, программа dpkg:

Источник: https://manpages.debian.org/unstable/dpkg-dev/deb.5.en.html

Помимо создания пакетов с готовыми программами, формат предполагает создание пакетов с исходным кодом. Такой пакет состоит из 3 частей:

Дальше из этих двух архивов с помощью утилиты dpkg-buildpackage собирает готовый пакет .deb

Пакет формата rpm

Такой формат используется в дистрибутивах Red Hat Enterprise Linux, Fedora, CentOS, AlmaLinux, openSUSE, Oracle Linux и других

Пакет формата rpm - не просто архив ar, а архив с расширением .rpm со своими полями:

Сама полезная нагрузка содержит файлы, которые будут скопированы в файловую систему, наподобие как сделано в пакетах формата deb, например:

usr
├───bin
│       fastfetch
├───lib
│   └───...
└───share
    ├───doc
    │   └───fastfetch
    │           README.md
    ├───fastfetch
    ├───man
    │   └───man1
    │           fastfetch.1.gz
    └───...

Исходный пакет, который содержит исходный код программы и имеет расширение .src.rpm, устроен иначе, в нем вместо одного архива в полезной нагрузки есть:

Здесь проявляется ключевое отличие пакета rpm от пакета deb: вместо множества файлов в пакете rpm вся информация хранится в файле <пакет>.spec. Этот файл может выглядеть так:

Name:           fastfetch
Version:        2.61.0
Release:        1%{?dist}
Summary:        Fast neofetch-like system information tool

License:        MIT
URL:            https://github.com/fastfetch-cli/fastfetch
Source0:        %{url}/archive/%{version}/%{name}-%{version}.tar.gz

BuildRequires:  cmake
...
BuildRequires:  yyjson-devel

Recommends:     hwdata
Suggests:       libXrandr
...
Suggests:       elfutils-libelf

ExcludeArch:    %{ix86}

%description
fastfetch is a neofetch-like tool for fetching system information and
displaying them in a pretty way. It is written in c to achieve much better
performance, in return only Linux and Android are supported. It also uses
mechanisms like multithreading and caching to finish as fast as possible.


%prep
%autosetup -p1


%build
%cmake -DBUILD_TESTS=ON -DENABLE_SYSTEM_YYJSON=ON -DBUILD_FLASHFETCH=OFF
%cmake_build


%check
%ctest


%install
%cmake_install


%files
%license LICENSE
%doc README.md
%{_bindir}/%{name}
%{_datadir}/%{name}/
%{_mandir}/man1/fastfetch.1*
%{_datadir}/bash-completion/completions/%{name}
%{_datadir}/fish/vendor_completions.d/%{name}.fish
%{_datadir}/zsh/site-functions/_%{name}


%changelog
<журнал изменений>

Сначала идет преамбула. Она содержит метаданные самого пакета:

На основе этих тегов формируется стандартное имя пакета: Name-Version-Release.Architecture.rpm

Потом идет тело файла, которое состоит из серии секций, каждая из которых отвечает за свой этап сборки. Основные из них это:

Сам пакет формата rpm устанавливается утилитой rpm. Эта утилита умеет только устанавливать пакет из уже скачанного файла. Чтобы загружать зависимости и пакеты из удаленного репозитория, существуют другие утилиты:

Сейчас из-за проблем с совместимостью yum все еще поставляется с дистрибутивами

Extra 4. Графические подсистемы

Данный конспект был основан на записи лекций №13 (*тык*) и №14 (*тык*) с канала А. В. Маятина

Ключевым отличием операционной системы Linux от систем Windows и macOS для рядового пользователя - это различия во взаимодействии пользователя с системой. В Windows и macOS преимущественно используется графический интерфейс или GUI (Graphical User Interface), тогда как в Linux исторически и архитектурно используется интерфейс командной строки или CLI (Command Line Interface)

Рассмотрим, как устроен графический интерфейс в Windows от компании Microsoft. Предком современной системы Windows была система MS-DOS (от MicroSoft Disk Operating System), в нем в качестве интерфейса была командная строка

Командная строка в MS-DOS

Это не мешало отдельным программам иметь текстовый интерфейс (TUI, Text User Interface) или графический интерфейс (например, в играх):

Информация о компьютере в MS-DOS

Однако при запуске пользователя встречала командная строка. Позднее в 1985 году вышла Windows 1.0 - система, которая представляла графическую оболочку и базовые приложения для MS-DOS. После нее выходили Windows 2.0, Windows 3.0 и другие. Так выглядела Windows For Workgroups 3.11:

Windows 3.11

В те времена пользователи отдельно покупали MS-DOS и версию Windows. Вплоть до Windows 3.2 система Windows была надстройкой для MS-DOS, но в Windows 95 графический оболочка была полностью встроена в ядро (несмотря на это MS-DOS остался для поддержки обратной совместимости):

Windows 95

С тех пор графический интерфейс в Windows является главным интерфейсом для взаимодействия с системой

В Unix и Unix-подобных системах, стоявших у истоков универсальных операционных систем, главным интерфейсом была командная строка

Когда речь зашла о разработке графической оболочки для обычных пользователей, решили выбрать клиент-серверную архитектуру

Так появился X Window System - базовый протокол, описывающий взаимодействие между программами, которые хотят отрисовать свое содержимое, и графической оболочкой. В X Window System:

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

Альтернативой X Window System является протокол Wayland - о нем рассказано позже

История X Window System

X Window System появилась внутри Массачусетского института технологий. Разработкой руководили Боб Шайфлер и Джим Геттис, а первый публичный релиз состоялся 19 июня 1984 года

После этого в 1986 году, появилась версия X10, которая быстро распространялась среди пользователей Unix. В сентябре 1987 года вышла 11-ая версия протокола - X11. Протокол был насколько хорошо спроектирован, что с тех пор его базовая версия практически не менялась, а новые возможности добавлялись через расширения

После выхода реализации протокола X11R2 (здесь R - это от “релиз”) в январе 1988 года управление проектом перешло от MIT к консорциуму X MIT (MIT X Consortium), который финансировали компании DEC и IBM. Эта и будущие реализации публиковались под лицензией MIT

Параллельно независимые разработчики адаптировали код X11R4 для работы с графическими картами с VGA на IBM-совместимых компьютерах, что привело к появлению в 1991 году реализации X386 1.1 - название отражало 32-битный процессор Intel 386 на архитектуре x86, который использовался в IBM-совместимых компьютерах. Позднее это ответвление было переименовано в XFree86

В 1993 году была образована некоммерческая корпорация X Consortium, Inc., которая продолжила выпуск новых версий X11R6 и X11R6.1

Далее произошел релиз XFree86 2.0 в 1994 году и последующие версии, такие как XFree86 3.x, активно развивались и к концу 1990-х годов стали фактическим стандартом X-сервера для Linux и многих других Unix-подобных систем

31 декабря 1996 года X Consortium, Inc. прекратил свое существование, и все права на X Window System перешли к The Open Group

В феврале 2004 года вышла реализация XFree86 4.4.0, где была изменена лицензия на менее свободную XFree86 License 1.1. В результате этого в апреле 2004 года был основан фонд X.Org Foundation. 6 апреля 2004 года вышла реализация X11R6.7.0, которая стала первым сервером от X.Org. Сейчас же последний релиз - это X11R7.7, который вышел в 2012 году

Большинство дистрибутивов выбрало сервер от X.Org, и с тех пор X.Org Foundation управляет развитием и поддержкой X Window System и выпускает ее эталонную реализацию под лицензией MIT

Сейчас X.Org Server имеет другую нумерацию, и последняя версия 21.1.14 вышла в 2024 году

Архитектура X Window System

Как уже было подмечено, в Linux графический интерфейс устроен по клиент-серверной архитектуре: приложения-клиенты отправляют данные о том, что отрисовывать на реализацию сервера, который поддерживает протокол X11 (например X.Org Server)

Для упрощения разработки приложения используют библиотеку Xlib, которая реализует протокол X11 на стороне клиента и позволяет приложениям общаться с X-сервером

Сам протокол состоит из 4 видов сообщений:

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

Для подключения клиенты используют переменную среды DISPLAY. Она состоит из строки в формате [хост]:номер_дисплея[.номер_экрана], в которой:

Архитектура

Чтобы запустить сервер X.Org из терминала, нужно:

Таким клиентом может быть программа xterm - эмулятор терминала для графического режима. xterm стал первым приложением, которое показало работоспособность протокола X Window System

Оконный менеджер

Сам протокол X11 и сервер, реализующий его, не описывают стратегии размещения окна. При запуске сервер X.Org рисует “корневое окно”, состоящее из одноцветного фона (обычно черного) и курсора в форме креста. Такой режим полезен для компьютеров, выполняющих функцию киоска

Расположением окон управляет оконный менеджер (Window Manager). Оконный менеджер позволяет запускать несколько приложений в графическом режиме и управлять положение и размерам их окон. Всего различают три типа оконных менеджеров:

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

Типы оконных менеджеров

Такие оконные менеджеры могут добавлять дополнительные элементы интерфейса к окнам программ, например, рамку с заголовком программы и кнопками “Закрыть”, “Свернуть”, “Развернуть” или панель задач, где указаны запущенные программы

Оконный менеджер для startx можно указать в файле ~/.xinitrc

Расширенные графические среды

Эволюцией оконных менеджеров являются расширенные графические среды (Extended Graphical Environment, XGE)

Расширенная графическая среда (или среда рабочего стола, Desktop Environment) предоставляет свой оконный менеджер и набор базовых программ для работы внутри среды, таких как проигрыватель, файловый менеджер и так далее

В Linux распространены две графических среды:

  1. KDE Plasma (от K Desktop Environment)

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

    Среда KDE основана на фреймворке Qt, написанном на языке C++, который предоставляет широкий инструментарий для создания графических интерфейсов, например, классы элементов интерфейса, классы виджетов, классы для работы с сетевыми протоколами, классы для работы с интерфейсом OpenGL. Также Qt предоставляет множество инструментов для разработки и локализации приложений

    KDE также предоставляет оконный менеджер KWin и базовый набор приложений:

    • Amarok - проигрыватель
    • Dolphin - файловый менеджер
    • Kdeadmin - инструменты для администрирования
    • KDevelop - среда разработки приложений для KDE
    • Konqueror - веб-браузер (сейчас используется Falkon - браузер на основе Chromium)
    • Konsole - эмулятор терминала
    • Kontact - клиент электронной почты и менеджер контактов
    • KDE Connect - приложение для интеграции телефона с компьютером
    • и много других, включая игры и приложения для обучения

    Как можно заметить, приложения KDE имеют в названии букву K

    KDE

  2. GNOME (от GNU Network Object Model Environment)

    Когда KDE начала свое развитие, среда использовала версию фреймворка Qt, которая распространялась под проприетарной лицензией. Поэтому как альтернатива была создана среда GNOME, которая использует код только под открытой лицензией

    GNOME использует графическую библиотеку GTK (от GIMP ToolKit), созданную для программы GIMP и написанную на языке C, которая использует низкоуровневую библиотеку GLib

    GNOME использует менеджер окон Mutter (до этого использовался Metacity) и предоставляет свой набор программ:

    • Totem - проигрыватель
    • Nautilus - файловый менеджер
    • GnomeSystemTools - инструменты для администрирования
    • Web - веб-браузер
    • GNOME Terminal - эмулятор терминала
    • Evolution - менеджер контактов

    GNOME

Эти среды являются довольно ресурсозатратными, поэтому есть множество других менее распространенных и легких графических сред:

Для конечного пользователя среды предоставляют схожий набор программ, поэтому у части дистрибутивов нет конкретного выбор графических сред, например, Fedora поставляется в двух изданиях - с KDE и с GNOME

Графические среды тем временем представляют риск безопасности системы:

Поэтому разработчики из Red Hat во главе с Дэвидом Цойтеном предложили принципиально иной подход, который и был реализован в библиотеке PolicyKit

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

Также PolicyKit вводит понятие централизованной политики - администратор системы может с помощью простых правил (обычно в XML-файлах) определить, кто и при каких условиях может выполнять то или иное действие

Дисплейный менеджер

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

Дисплейный менеджер решает проблему ручного запуска графической сессии. Он сразу после загрузки:

При запуске:

  1. Система загружается, запускается systemd
  2. Включается графическая цель graphical.target, которая запускает сервис дисплейного менеджера
  3. Дисплейный менеджер поднимает X-сервер (или Wayland) на виртуальном терминале
  4. Появляется экран входа. После успешного входа дисплейный менеджер запускает сеанс пользователя:
    • Для X11 записывает DISPLAY=:0 и запускает оконный менеджер или среду
    • Для Wayland запускает композитор

Сейчас популярные дисплейные менеджеры это:

Wayland

Несмотря на успешность X11, со временем накопилось несколько фундаментальных проблем:

В 2008 году Кристиан Хогсберг (работавший над X-сервером в Red Hat) начал разработку Wayland - новое протокола графического сервера. Главная идея была в том, что сервер не рисует сам, а только управляет поверхностями, клиенты же рисуют напрямую через буферы, передавая их серверу для компоновки

Архитектура Wayland включает композитор Wayland. Композиторы Wayland - это одновременно оконные менеджеры и серверы

Ключевые особенности Wayland:

Сейчас большинство дистрибутивов (Fedora, Ubuntu, Debian и другие) используют Wayland в основных редакциях

Для обратной совместимости с существующими X-клиентами запускается XWayland - X-сервер, который рисует не на реальном экране, а в окно Wayland

Несмотря на это, Wayland имеет свои недостатки:

This site is open source. Improve this page.