Методология DevOps в разработке программного обеспечения

Linux

Разбить на страницы
Показывать лекцию целиком

Linux: использование командной строки

Большинство проектов построено на Linux. Какими бы инструментами вы не пользовались, в какие бы кластеры не деплоилось ваши приложения, всё равно в основе этого с высокой долей вероятности будет лежать Linux.

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

Давайте начнём с основ - то есть с работы в консоли.

Работа в консоли

Как уже упоминалось, в Linux очень хорошая документация. Используйте команду man или ключ --help/-h. Это позволит вам понять как пользоваться любой другой командой.

Навигация

Файловая система Linux имеет иерархическую или древовидную структуру. Имеется корневая точка монтирования и от неё идёт вся структура файловой системы. Здесь нет дисковых разделов, таких как в Windows.

Для навигации по файловой системе можно пользоваться одной единственной командной - cd, которая расшифровывается как change directory.

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

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

  • l - long, то есть показывается полный вывод, включая атрибуты файлов, права доступа, размер и дату
  • a - all, включает в вывод скрытые файлы
  • h - human-readable, переводит байтовые значения размеров файлов в форматы с приставками
  • Остальные базовые командам для работы в терминале:

  • pwd - print work directory. Если по какой-то причине вы не помните полный путь, где сейчас находитесь - используйте эту команду. Также её часто можно использовать в скриптах для составления полного пути.
  • mkdir - make directory. Создание папки, с полным либо с относительным путём, можно создать всю иерархию сразу, но нужно проверять ключи.
  • rm - remove. Удаление файлов, имеет множество ключей, требует особой осторожности.
  • touch - утилита создана для изменения даты создания файла, однако в подавляющем большинстве просто используется для создания пустых файлов.
  • find - поиск по файловой системе или самим файлам.
  • Переменные окружения

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

    Для получения списка переменных окружения можно использовать команду env, а для более удобного просмотра - перенаправить её вывод в команду more или less через пайп env | less. Про пайпы поговорим немного позже.

    Для получения значения из консоли можно сделать обращение через $VARIABLE. К примеру для вывода значения в консоль echo $VARIABLE.

    Для установки нового значения нужно вставить в командную строку следующую пару:

    VARIABLE=VALUE или команду export VARIABLE=VALUE. Команда export обеспечивает то, что все дочерние процессы от вашей командной строки также будут наследовать значение данной переменной.

     '[root@li2155-195 ~]# TEST_VAR=test_value [root@li2155-195 ~]# echo $TEST_VAR test_value [root@li2155-195 ~]# bash [root@li2155-195 ~]# echo $TEST_VAR [root@li2155-195 ~]# exit [root@li2155-195 ~]# exp ort TEST_VAR [root@li2155-195 ~]# bash [root@li2155-195 ~]# echo $TEST_VAR test_value'

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

     [root@li2155-195 ~]# unset TEST_VAR [root@li2155-195 ~]# echo $TEST_VAR 

    Терминалы и оболочки консоли

    Существует два вида терминалов в Linux: tty и pty:

  • TTY - tele-type-terminal
  • PTY - pseudo-type-terminal
  • Понятие этих терминалов является наследием первых tele-type терминалов, которые использовались для ввода/вывода и работы с первыми компьютерами. По сути это line-by-line ввод и вывод.

    В самом Linux tty - это непосредственно ваши клавиатура и монитор, то есть физическое воплощение терминала. В то время как pty - это программная реализация терминала, необходимая для некоторых программ. Например, для удалённого подключения к машине через ssh.

    Для примера можно посмотреть переменную окружения через ssh подключения которая указывает наш текущий терминал echo $SSH_TTY.

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

    Две консоли, вывести в двух номера псевдо-терминалов: echo $SSH_TTY. Далее тестовая команда вроде

    echo 'hello' > /dev/pts/1.

    Теперь давайте рассмотрим, что такое оболочки терминала и какие существуют.

    Оболочка терминала, это интерпретатор команд, который передаёт ваши команды в API ядра Linux. Эти оболочки бывают разными, и отличаются своим функционалом. Базово всегда присутствует интерпретатор sh, функционал которого не беден, но неприятен в управлении. Далее идёт самый популярный интерпретатор, который включен практически в любой Linux дистрибутив - bash, расшифровывается как bourne again shell. Включает в себя автодополнение, профили, и множество других полезных функций. Далее идут различные интерпретаторы вроде zsh, который лично я бы рекомендовал,а также fish, ksh и так далее. Все они отличаются функционалом и расширяемыми плагинами.

    Расположение бинарных файлов

    Не важно, где в файловой системе находятся исполняемые файлы (не обязательно бинарные), так как любой файл можно передать интерпретатору для запуска в виде ./command. Однако, если вы не хотите использовать постоянно запуск с полным или относительным путём, вы можете использовать дополнение переменной окружения $PATH, которая содержит в себе пути, где система будет искать вводимые команды по умолчанию.

    Давайте посмотрим на формат содержимого этой переменной:

    [root@li2155-195 ~]# echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin

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

    [root@li2155-195 ~]# echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin [root@li2155-195 ~]# export PATH=$PATH:/root/new_bin_folder [root@li2155-195 ~]# echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin:/root/new_bin_folder

    Пакетные менеджеры

    Пакетных менеджеров существует довольно много, но большинство серверных систем и Docker образов основаны на трёх семействах Debian, Centos(Redhat) и Alpine. Так что список того что нам нужно рассмотреть ограничивается менеджерами apt-get, yum и apk соответственно.

    Вы можете установить пакетные менеджеры на другие системы, но это это не распространено.

    Давайте рассмотрим принципы работы пакетных менеджеров.

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

    Для систем семейства Debian характерно использование пакетного менеджера apt-get и apt. Разница между ними в том, что apt являются надстройкой написаной на Python и использующей apt-get и еще несколько утилит для менеджмента пакетов, cache и репозиториев в системе.

    В системах семейства CentOS и Redhat используется пакетный менеджер yum который, начиная с восьмой версии CentOS, заменён на dnf. Связано это с тем, что yum имел недостатки в виде низкой производительности и высокого потребления памяти.

    В Alpine Linux используется пакетный менеджер apk или alpine packet manager. Отличается низким уровнем кэширования и использованием строго необходимых зависимостей для установки пакетов. Важно знать о нем, так как на базе alpine linux зачастую собираются образы в силу малого размера базового образа с системой.

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

    Каждый файл или папка имеют три набора по три бита в каждом. Каждый из наборов отвечает за отдельный набор пользовательских сущностей: владелец - группа владельца - все остальные

    Каждый их трёх бит может иметь значение 0 или 1 и означать наличие или отсутствие прав на чтение - запись - исполнение.

    Однако, с развитием системы оказалось, что этих параметров недостаточно, и ввели еще три дополнительных параметра:

  • SUID - если этот бит установлен, то при выполнении программы, id пользователя, от которого она запущена заменяется на id владельца файла. Фактически, это позволяет обычным пользователям запускать программы от имени суперпользователя;
  • SGID - этот флаг работает аналогичным образом, только разница в том, что пользователь считается членом группы, с которой связан файл, а не групп, к которым он действительно принадлежит. Если SGID флаг установлен на каталог, то все файлы, созданные в нем, будут связаны с группой каталога, а не пользователя. Такое поведение используется для организации общих папок;
  • Sticky-bit - этот бит тоже используется для создания общих папок. Если он установлен, то пользователи могут только создавать, читать и выполнять файлы, но не могут удалять файлы, принадлежащие другим пользователям. К примеру его можно видеть на стандартной папке /tmp в системе.
  • Как я уже упоминал ранее, можно использовать команду ls с ключом -l чтобы посмотреть полный вывод информации о файлах включая атрибуты.

    [root@li2155-195 ~]# ls -lha / total 68K dr-xr-xr-x. 18 root root 4.0K Aug 10 20:34 . dr-xr-xr-x. 18 root root 4.0K Aug 10 20:34 .. lrwxrwxrwx. 1 root root 7 May 11 2019 bin -> usr/bin dr-xr-xr-x. 5 root root 4.0K Aug 27 11:32 boot drwxr-xr-x. 18 root root 2.9K Aug 27 11:31 dev drwxr-xr-x. 80 root root 4.0K Aug 27 11:31 etc drwxr-xr-x. 2 root root 4.0K May 11 2019 home lrwxrwxrwx. 1 root root 7 May 11 2019 lib -> usr/lib lrwxrwxrwx. 1 root root 9 May 11 2019 lib64 -> usr/lib64 drwx------. 2 root root 16K Aug 10 20:27 lost+found drwxr-xr-x. 2 root root 4.0K May 11 2019 media drwxr-xr-x. 2 root root 4.0K May 11 2019 mnt drwxr-xr-x. 2 root root 4.0K May 11 2019 opt dr-xr-xr-x. 95 root root 0 Aug 27 11:31 proc dr-xr-x---. 4 root root 4.0K Aug 28 23:34 root drwxr-xr-x. 23 root root 660 Aug 27 11:31 run lrwxrwxrwx. 1 root root 8 May 11 2019 sbin -> usr/sbin drwxr-xr-x. 2 root root 4.0K May 11 2019 srv dr-xr-xr-x. 13 root root 0 Aug 27 11:31 sys drwxrwxrwt. 7 root root 4.0K Aug 28 21:09 tmp drwxr-xr-x. 12 root root 4.0K Aug 10 20:28 usr drwxr-xr-x. 20 root root 4.0K Aug 27 11:31 var

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

  • -- (0) - нет прав на файл

    [root@li2155-195 .temp]# chmod 000 00_no_permissions [root@li2155-195 .temp]# ls -lha 00_no_permissions ----------. 1 root root 0 Aug 28 23:54 00_no_permissions
  • r-- (4) - права только на чтение

     [root@li2155-195 .temp]# chmod 400 01_read_only [root@li2155-195 .temp]# ls -lha 01_read_only -r--------. 1 root root 0 Aug 28 23:55 01_read_only
  • w-(2) - права только на запись

    '[root@li2155-195 .temp]# chmod 200 02_write_only [root@li2155-195 .temp]# ls -lha 02_write_only --w-------. 1 root root 0 Aug 28 23:55 02_write_only'
  • -x (1) - права только на исполнение

    [root@li2155-195 .temp]# chmod 100 03_execute_only[root@li2155-195 .temp]# ls -lha 03_execute_only ---x------. 1 root root 0 Aug 28 23:55 03_execute_only
  • rw- (6) - права на чтение и на запись

    [root@li2155-195 .temp]# chmod 600 04_read_write [root@li2155-195 .temp]# ls -lha 04_read_write -rw-------. 1 root root 0 Aug 28 23:55 04_read_write
  • r-w (5) - права на чтение и на исполнение

    [root@li2155-195 .temp]# chmod 500 05_read_execute [root@li2155-195 .temp]# ls -lha 05_read_execute -r-x------. 1 root root 0 Aug 28 23:55 05_read_execute
  • wx (3) - права на запись и на исполнение

    [root@li2155-195 .temp]# chmod 300 06_write_execute [root@li2155-195 .temp]# ls -lha 06_write_execute --wx------. 1 root root 0 Aug 28 23:56 06_write_execute
  • rwx (7) - права на чтение, запись и исполнение

    '[root@li2155-195 .temp]# chmod 300 07_read_write_execute [root@li2155-195 .temp]# ls -lha 07_read_write_execute -rwx------. 1 root root 0 Aug 28 23:57 07_read_write_execute'
  • -S - установлен SUID или SGID биты.
  • Для того чтобы выставить SUID бит, нужно перед основным списком параметров поставить дополнительное значение. Так для SUID это будет 4.

     [root@li2155-195 .temp]# chmod 4700 08_suid_bit [root@li2155-195 .temp]# ls -lha 08_suid_bit -rws------. 1 root root 0 Aug 28 23:59 08_suid_bit

    Для установки SGID бита, требуется поставить значение 2.

    [root@li2155-195 .temp]# chmod 2700 09_sgid_bit [root@li2155-195 .temp]# ls -lha 09_sgid_bit -rwx--S---. 1 root root 0 Aug 29 00:00 09_sgid_bit А для установки SUID и SGID бит одновременно - 4+2=6 [root@li2155-195 .temp]# chmod 6700 10_sgid_suid_bits [root@li2155-195 .temp]# ls -lha 10_sgid_suid_bits -rws--S---. 1 root root 0 Aug 29 00:00 10_sgid_suid_bits
  • -t - установлен sticky бит
  • Sticky-bit устанавливается аналогично SUID и SGID битам, и его значение равно 1

    '[root@li2155-195 .temp]# chmod 1700 11_sticky_bit [root@li2155-195 .temp]# ls -lha 11_sticky_bit -rwx-----T. 1 root root 0 Aug 29 00:00 11_sticky_bit'

    В целом картина будет выглядеть следующим образом

    '[root@li2155-195 .temp]# ls -lh total 0 ----------. 1 root root 0 Aug 28 23:54 00_no_permissions -r--------. 1 root root 0 Aug 28 23:55 01_read_only --w-------. 1 root root 0 Aug 28 23:55 02_write_only ---x------. 1 root root 0 Aug 28 23:55 03_execute_only -rw-------. 1 root root 0 Aug 28 23:55 04_read_write -r-x------. 1 root root 0 Aug 28 23:55 05_read_execute --wx------. 1 root root 0 Aug 28 23:56 06_write_execute -rwx------. 1 root root 0 Aug 28 23:57 07_read_write_execute -rws------. 1 root root 0 Aug 28 23:59 08_suid_bit -rwx--S---. 1 root root 0 Aug 29 00:00 09_sgid_bit -rws--S---. 1 root root 0 Aug 29 00:00 10_sgid_suid_bits -rwx-----T. 1 root root 0 Aug 29 00:00 11_sticky_bit'

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

    Команда chmod имеет следующий синтаксис: chmod опции категория действие разрешение путь к файлу.

    Категорий соответственно бывает три (в литералах):

  • u - владелец файла
  • g - группа файла
  • o - все остальные
  • a - all, применить ко всем сразу
  • Действий может быть три: + - добавить разрешения, - - удалить разрешения, = - оставляет только указанные права.

    Разрешения в литералах:

  • r - чтение
  • w - запись
  • x - исполнение
  • s - suid/sgid в зависимости от применения
  • t - sticky bit
  • Примеры эквивалентных команд (предполагаем что по умолчанию файл создан с нулевыми правами):

     chmod 000 00_no_permissions #или chmod ugo-rwx 00_no_permissions chmod 400 01_read_only #или chmod u+r 01_read_only chmod 200 02_write_only #или chmod u+w 02_write_only chmod 100 03_execute_only #или chmod u+x 03_execute_only chmod 600 04_read_write #или chmod u+rw 04_read_write chmod 500 05_read_execute #или chmod u+rw 05_read_execute chmod 300 06_write_execute #или chmod u+wx 06_write_execute chmod 700 07_read_write_execute #или chmod u+rwx 07_read_write_execute chmod 4700 08_suid_bit #или chmod u+rws 08_suid_bit chmod 2700 09_sgid_bit #или chmod u+rwx,g+s 09_sgid_bit chmod 6700 10_sgid_suid_bits #или chmod u+rws,g+s 10_sgid_suid_bits chmod 1700 11_sticky_bit #или chmod u+rwxt 11_sticky_bit

    Владельцы файлов в Linux

    У файла есть владелец и группа файла. Узнать можно всё так же с помощью команды ls -l.

    Изменяется всё достаточно просто с помощью команды chown [options] [user][:group] file_path

    Linux: работа с устройствами (физическими или виртуальными)

    Обзор присутствующих устройств в системе (Device Inspection in Linux)

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

    Применяются следующие команды для инспекции оборудования

  • lsusb - показывает информацию об устройствах на шине USB.
  • lspci - показывает информацию об устройствах на шине PCI.
  • В случае отсутствия исполняемых файлов, они могут находить в устанавливаемых пакетах pciutils и usbutils.

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

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

    Итак, если ввести просто lspci, то мы получим список всех устройств подключенных по шинам PCI:

     root@localhost:~# lspci 00:00.0 Host bridge: Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller 00:01.0 VGA compatible controller: Device 1234:1111 (rev 02) 00:02.0 SCSI storage controller: Red Hat, Inc. Virtio SCSI 00:03.0 SCSI storage controller: Red Hat, Inc. Virtio SCSI 00:04.0 Ethernet controller: Red Hat, Inc. Virtio network device 00:1f.0 ISA bridge: Intel Corporation 82801IB (ICH9) LPC Interface Controller (rev 02) 00:1f.2 SATA controller: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA Controller [AHCI mode] (rev 02) 00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 02)

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

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

     root@localhost:~# lspci -v -s 00:01.0 00:01.0 VGA compatible controller: Device 1234:1111 (rev 02) (prog-if 00 [VGA controller]) Subsystem: Red Hat, Inc. Device 1100 Flags: fast devsel Memory at fd000000 (32-bit, prefetchable) [size=16M] Memory at febd0000 (32-bit, non-prefetchable) [size=4K] Expansion ROM at 000c0000 [disabled] [size=128K] Kernel driver in use: bochs-drm Kernel modules: bochs_drm

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

     root@localhost:~# lspci -s 00:1f.0 -k 00:1f.0 ISA bridge: Intel Corporation 82801IB (ICH9) LPC Interface Controller (rev 02) Subsystem: Red Hat, Inc. QEMU Virtual Machine Kernel driver in use: lpc_ich Kernel modules: lpc_ich

    Так же можно взглянуть на иерархию шины PCI:

     root@localhost:~# lspci -t -v -[0000:00]-+-00.0 Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller +-01.0 Device 1234:1111 +-02.0 Red Hat, Inc. Virtio SCSI +-03.0 Red Hat, Inc. Virtio SCSI +-04.0 Red Hat, Inc. Virtio network device +-1f.0 Intel Corporation 82801IB (ICH9) LPC Interface Controller +-1f.2 Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA Controller [AHCI mode] \-1f.3 Intel Corporation 82801I (ICH9 Family) SMBus Controller

    Модули (драйверы и не только) ядра

    Список загруженных модулей ядра можно посмотреть командой lsmod

    'root@localhost:~# lspci -t -v -[0000:00]-+-00.0 Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller +-01.0 Device 1234:1111 +-02.0 Red Hat, Inc. Virtio SCSI +-03.0 Red Hat, Inc. Virtio SCSI +-04.0 Red Hat, Inc. Virtio network device +-1f.0 Intel Corporation 82801IB (ICH9) LPC Interface Controller +-1f.2 Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA Controller [AHCI mode] \-1f.3 Intel Corporation 82801I (ICH9 Family) SMBus Controller'

    Вывод состоит из трёх колонок:

  • Module - название модуля
  • Size - объем оперативной памяти занимаемой модулем
  • Used by - список модулей которые зависят от конкретных модулей
  • С помощью команды modinfo можно посмотреть ощутимо больше информации о модуле, к примеру:

     '[root@li2155-195 ~]# modinfo ext4 filename: /lib/modules/4.18.0-193.14.2.el8_2.x86_64/kernel/fs/ext4/ext4.ko.xz softdep: pre: crc32c license: GPL description: Fourth Extended Filesystem author: Remy Card, Stephen Tweedie, Andrew Morton, Andreas Dilger, Theodore Ts'o and others alias: fs-ext4 alias: ext3 alias: fs-ext3 alias: ext2 alias: fs-ext2 rhelversion: 8.2 srcversion: 408EBC8810B3BE8D2C737DF depends: mbcache,jbd2 intree: Y name: ext4 vermagic: 4.18.0-193.14.2.el8_2.x86_64 SMP mod_unload modversions sig_id: PKCS#7 signer: CentOS Linux kernel signing key sig_key: 4B:D0:A9:10:8D:FE:73:3E:92:80:DF:8E:CF:B1:3F:46:D3:64:29:C5 sig_hashalgo: sha256 signature: 0A:81:D1:32:CE:0D:2B:7A:1D:1F:69:BA:03:1B:92:32:87:00:70:9D: AC:EE:09:97:F2:4A:F8:95:A2:C2:0A:51:EF:9F:8B:7A:48:A7:83:98: 6C:DA:B5:26:7A:2D:B7:A7:43:75:05:C4:87:BD:CC:ED:86:C6:FE:9B: 90:8E:3D:1D:8B:E1:79:2B:9A:B5:E9:C1:A9:30:9D:EA:7A:1B:1C:23: AB:54:AD:1B:2E:39:0D:F3:8D:1B:62:28:1E:C1:B4:54:E0:26:D8:24: 9A:9A:DE:EF:6B:07:26:27:EC:88:32:25:2E:8E:0D:18:FA:0E:34:37: B7:C8:5B:20:75:B2:CA:DB:7E:69:D2:DF:D2:37:5C:ED:F0:C3:08:14: E3:2E:EA:1A:2A:5E:FD:D8:46:37:CA:62:E0:91:E2:8A:B6:A4:00:3D: 5D:1D:5E:2A:80:B0:08:A4:4F:2D:DE:7C:02:83:F9:0D:B7:D1:84:5C: A8:3B:86:A1:D2:9A:3B:7D:4B:E1:FA:C5:9D:78:0E:B2:41:D7:A1:35: 9D:E6:62:20:07:02:1B:93:16:7A:7C:3F:7F:A4:B4:E4:4D:41:C6:D1: B4:A3:0E:9B:BC:D7:F3:16:C6:F9:57:54:75:81:3D:42:D1:13:7C:A0: 70:E0:65:C1:B6:8B:6B:19:FA:EA:B7:97:DC:C3:92:EC:F7:E3:6A:17: 53:EE:4F:16:25:59:42:10:79:0F:AE:F0:44:B1:4F:85:3F:56:88:9F: 0B:9F:21:85:9D:4F:BE:DA:FF:F0:99:A6:88:1F:DF:B9:64:31:68:9A: 78:DF:31:E0:25:46:9A:4F:1C:61:CE:EE:EF:24:F0:0B:A5:0F:13:AC: B9:BB:38:2E:5D:F5:E3:97:1B:B4:4F:51:2C:9E:8E:F6:08:86:ED:0A: C1:67:FB:78:B1:C9:8D:A7:AD:F8:72:D3:8D:B3:06:C2:5E:A7:1F:00: 09:BB:93:50:50:13:C1:E3:5F:7F:B5:AD:0A:32:0C:58:98:67:A0:81: DD:89:1E:F1'

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

  • /etc/modprobe.conf - общий файл конфигурации
  • /etc/modprobe.d/ - индивидуальные файлы конфигурации
  • Подключить или отключить модули можно командами

  • modprobe $имя_модуля - для подключения
  • modprobe -r $имя_модуля - для отключения
  • Логи о подключении или или отключении модулей можно увидеть в файле /var/log/messages или используя journalctl.

    Файлы хранящие информацию об устройствах

    Все команды с приставками ls (продемонстрированные ранее lspci, lsusb и lsmod) работают как фронтэнд части для хранилищ информации об устройствах или модулях. В целом вся специальная информация располагается в каталогах /proc, /sys и /dev. Эти каталоги не существуют на самом деле в файловой системе -- это точки монтирования из оперативной памяти.

    Каталог /proc содержит информацию о запущенных процессах, текущих аппаратных ресурсах и состоянии операционной системы:

  • /proc/cpuinfo - информация о центральном процессоре
  • /proc/meminfo - информация об имеющейся оперативной памяти
  • /proc/interrupts - информация о настройках прерываний всех устройств ввода/вывода
  • Каталог /sys содержит базовую информацию о подключенных устройствах.

    Каталог /dev содержит информацию об интерфейсах работы с модулями ядра.

    Устройства хранения

    Как уже было упомянуто, устройства хранения имеют системные файлы в каталоге /dev и имеют следующий список префиксов для идентификации:

  • sd - IDE, SSD и USB блочные устройства, не важно по каким шинам подключены, будь то SATA, pci или SCSI, начиная с версии ядра линукса 2.4 они были объединены в один префикс.
  • mmcblk - имеют SD кард-ридеры
  • nvme - префикс соответственно имеют NVME устройства хранения
  • Linux процесс загрузки

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

    BIOS or UEFI

    В зависимости от использования системой BIOS или UEFI - различаются и процедуры запуска системы.

    BIOS или Basic Input / Output System - это микрокод, хранящийся в энергонезависимой памяти на материнской плате, он выполняется каждый раз при включении компьютера. В процессе загрузки BIOS предполагает, что первые 440 байт в первом хранилище дисковой подсистемы - следуя порядку, находящемуся в настройках BIOS (автоматически определяется по очерёдности разъёмов подключения на плате) - являются первым этапом загрузчика. Первые 512 байт хранилища называются главной загрузочной записью MBR (Master Boot Record). Master Boot Record использует стандартную схему разделов DOS и дополняет первый этап загрузчика таблицей разделов файловой системы.

    Итак, основные шаги загрузки системы с BIOS:

  • Процесс POST (power-on self-test) выполняется для выявления простых отказов оборудования сразу после включения системы.
  • BIOS подключает базовые компоненты системы для загрузки - видеовывод, клавиатура и дисковые носители.
  • BIOS передает управление загрузчику находящемуся в MBR (первые 440 байт на первом носителе).
  • Первый этап загрузчика вызывает вторую ступень, отвечающую за представление параметров загрузки ядру и его вызов.
  • UEFI или Unified Extensible Firmware Interface - имеет отличия от BIOS в некоторых ключевых моментах. Как и BIOS, UEFI также является микрокодом (firmware) и находится на материнской плате. Однако он может идентифицировать разделы и умеет работать с многими файловыми системами. UEFI не работает напрямую с MBR, а использует только настройки находящиеся в его энергонезависимой памяти (NVRAM). Хранимые настройки указывают на расположение UEFI-совместимых программ, называемых EFI-applications, которые будут выполняться автоматически или вызываться из меню загрузки. Приложения EFI могут быть загрузчиками, средствами выбора операционной системы, инструментами для диагностики и восстановления системы и так далее. Они должны находиться на обычном разделе устройства хранения и в совместимой файловой системе. Стандартные совместимые файловые системы - это FAT12, FAT16, FAT32 и вроде с недавнего времени exFAT(fat64) для блочных устройств и ISO-9660 для оптических носителей. Всё это в совокупности позволяет значительно проще использовать более сложные инструменты диагностики, так как не надо писать новый загрузчик для того чтобы, к примеру, протестировать оперативную память.

    Раздел, содержащий приложения EFI, называется системным разделом EFI или просто ESP (efi system partition). Этот раздел не должен использоваться совместно с другими системными файловыми системами. Каталог EFI в разделе ESP содержит приложения, на которые указывают записи, сохраненные в NVRAM.

    Основные шаги для загрузки системы с UEFI:

  • POST (самотестирование при включении) процесс выполняется для выявления простых отказов оборудования сразу после включения машины.
  • UEFI подключает базовые компоненты системы для загрузки - видеовывод, клавиатура и дисковые носители.
  • UEFI считывает определения, хранящиеся в NVRAM, чтобы выполнить предопределенное приложения EFI, хранящегося в файловой системе раздела ESP. Обычно предопределенное приложение EFI является загрузчиком.
  • Если предопределенное приложение EFI является загрузчиком, он загружает ядро для запуска операционной системы.
  • Стандарт UEFI также поддерживает функцию Secure Boot, которая позволяет выполнять только лицензированные приложения, то есть приложения EFI, авторизованные производителем оборудования. Эта функция повышает защиту от вредоносного программного обеспечения, но может затруднить установку операционных систем, на которые не распространяется гарантия производителя.

    The Bootloader

    Самый популярный загрузчик для Linux на архитектуре x86 - GRUB (Grand Unified Bootloader). Как только он вызывается BIOSом или UEFI, GRUB отображает список операционных систем, доступных для загрузки. Если список не выводится автоматически, то его можно вызвать, нажав Shift, во время вызова BIOSом GRUB. Если система использует UEFI то для вызова списка операционных системы можно использовать Esc.

    В меню GRUB можно выбрать, какое из установленных ядер должно быть загружено, и передать ему новые параметры. Большинство параметров ядра это key/value значения. Пример нескольких параметров ядра.

    acpi - Включает / отключает поддержку ACPI. acpi=off отключит поддержку ACPI.

    init - Изменяет точку входа в систему. К примеру вы можете выставить init=/bin/bash установит оболочку Bash в качестве точки входа. полезно для ремонта системы.

    systemd.unit - Устанавливает цель systemd для активации. Например, systemd.unit=graphical.target. Systemd также принимает числовые уровни запуска, определенные для инициализации в стиле SysV. Например, чтобы активировать уровень выполнения 1, необходимо включить только цифру 1 или букву S (сокращение от "single") в качестве параметра ядра.

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

    maxcpus - Ограничивает количество процессоров (или ядер процессора), видимых системе.

    quiet - ****Скрывает большинство загрузочных сообщений.

    vga - Выбирает режим видео. Параметр vga=ask покажет список доступных режимов на выбор.

    root - Устанавливает корневой раздел, отличный от предварительно настроенного в загрузчике. Например, root=/dev/sda3.

    rootflags - Mount параметры для корневой файловой системы.

    ro - Выполняет первоначальное монтирование корневой файловой системы доступным только для чтения.

    rw - Разрешает запись в корневую файловую систему во время первоначального монтирования.

    Изменение параметров ядра обычно не требуется, но может быть полезно для обнаружения и решения проблем, связанных с операционной системой. Параметры ядра необходимо добавить в файл /etc/default/grub в строке GRUB_CMDLINE_LINUX, чтобы сделать их постоянными при перезагрузках. Новый файл конфигурации для загрузчика должен создаваться каждый раз при изменении /etc/default/grub, что выполняется командой grub-mkconfig -o /boot/grub/grub.cfg. После запуска операционной системы параметры ядра, используемые для загрузки текущего сеанса, доступны для чтения в файле /proc/cmdline.

    System Initialization

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

    Исторически сложилось, что существует множество способов запуска скриптов и демонов, вследствие чего появилось несколько способов инициализации системы. Хотя в принципе в текущий момент всё свелось к единому systemd.

    Инициализация операционной системы начинается, когда загрузчик загружает ядро в ОЗУ. Затем ядро берет на себя управление и начинает конфигурировать основные части операционной системы, такие как базовая конфигурация оборудования и адресация памяти.

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

    Как только будет доступна корневая файловая система, ядро смонтирует все точки монтирования в файловой системе, которые оно возьмёт из файла /etc/fstab, а затем передаст управление системе указанной как точка входа, стандартной - утилите с именем init. Программа init отвечает за запуск всех сценариев инициализации и системных демонов. Существуют различные реализации таких системных инициаторов, помимо традиционного init, такие как systemd и Upstart (на самом деле всё кроме systemd безнадежно устарело). После загрузки программы init файл initramfs удаляется из ОЗУ.

    Коротко рассмотрим основные стили инициализации:

  • SysV standard - менеджер служб, основанный на стандарте SysVinit, контролирует, какие демоны и ресурсы будут доступны используя концепцию уровней запуска. Уровни выполнения пронумерованы от 0 до 6 и разработаны разработчиками дистрибутива для выполнения определенных целей. Единственные определения уровней выполнения, общие для всех дистрибутивов, - это уровни выполнения 0, 1 и 6.
  • systemd ****- это современный менеджер систем и служб с уровнем совместимости для команд и уровней запуска SysV. Менеджер systemd имеет параллельную структуру, использует сокеты и D-Bus (система межпроцессного взаимодействия) для активации служб, выполнения демона по требованию, мониторинга процессов с помощью cgroups, поддержки snapshot'ов, восстановления системной сессии, управления точкой монтирования и управления службами на основе зависимостей. В текущее время практически все дистрибутивы имеют systemd в качестве основного системного менеджера.
  • Upstart - Как и systemd, Upstart заменяет init. Цель применения Upstart - ускорить процесс загрузки за счет распараллеливания процесса загрузки системных служб. Upstart использовался в дистрибутивах на основе Ubuntu в прошлых выпусках, но сегодня уступил место ystemd.
  • Troubleshooting

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

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

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

    В системах на основе управляющей системы systemd команда journalctl покажет сообщения инициализации с параметрами -b, --boot, -k или --dmesg. Команда journalctl --list-boots показывает список номеров загрузки относительно текущей загрузки, их идентификационный хэш и временные метки первого и последнего соответствующих сообщений:

    В системах на основе systemd так же хранятся журналы предыдущих инициализаций, так что вы можете проводить диагностику за несколько загрузок. Если указаны параметры -b 0 или --boot= 0, то будут показаны сообщения для текущей загрузки. Опции -b -1 или --boot = -1 будут отображать сообщения от предыдущей инициализации. Опции -b -2 или --boot = -2 покажут сообщения от инициализации до этого и так далее. В следующем отрывке показано, как ядро вызывает диспетчер служб systemd для последнего процесса инициализации:

    Инициализация и другие сообщения, выдаваемые операционной системой, хранятся в файлах в каталоге /var/log/. Если происходит критическая ошибка и операционная система не может продолжить процесс инициализации после загрузки ядра и initramfs, можно использовать альтернативный загрузочный носитель для запуска системы и доступа к соответствующей файловой системе. Затем можно проверить логи на предмет возможных причин обусловливающих проблемы с загрузкой. Параметры -D или --directory команды journalctl могут использоваться для чтения сообщений журнала в каталогах, отличных от / var / log / journal /, который является местоположением по умолчанию для сообщений журнала systemd. Поскольку сообщения журнала systemd не хранятся в виде необработанного текста, для их чтения требуется команда journalctl.

    Ядро системы

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

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

    Службы могут управляться shell скриптами или корневым демоном управляющим всеми остальными демонами. Первый метод реализуется стандартом SysVinit, также известным как System V или просто SysV, но он устарел и практически больше не используется. Второй способ реализуется с помощью systemd и Upstart (который тоже устарел). Условно говоря, диспетчер служб - это первая программа, запускаемая ядром в процессе загрузки, поэтому ее PID (идентификационный номер процесса) всегда равен 1.

    SysVinit

    Для понимания, всё же рассмотрим старую версию инициализации в стиле SysV. Диспетчер служб, основанный на стандарте SysVinit, будет предоставлять предопределенные наборы состояний системы которые называются runlevels (или уровни исполнения/уровни работы ОС), и соответствующие им файлы shell script'ов для выполнения. Уровни исполнения существуют от 0-го до 6-го.

    Runlevel 0 - Выключение операционной системы.

    Runlevel 1, s or single - Перевести систему в режим системного администрирования. При этом все локальные файловые системы смонтированы. Работает только небольшой набор существенных процессов ядра. Этот режим предназначен для решения административных задач, например, установки дополнительных пакетов. Все файлы доступны, и никакие пользователи в системе не зарегистрированы. Используется для диагностики/обслуживание и восстановления системы.

    Runlevel 2 - Перевести систему в многопользовательский режим. Запускаются все необходимые для работы многопользовательской среды процессы и демоны. Это состояние обычно называют многопользовательским.

    Runlevel 3 -Расширить многопользовательский режим, предоставляя доступ по сети к локальным ресурсам.

    Runlevel 4 - Multi-user mode. - Можно определять как альтернативную конфигурацию многопользовательской среды. Этот уровень выполнения не обязателен для работы системы и обычно не используется.

    Уровни 2 и 4 не используются.

    Runlevel 5 - Multi-user mode. Такой же как и третий, но присутствует также графическая оболочка.

    Runlevel 6 - Перезагрузка системы. Остановить операционную систему и перезагрузить ее в состояние, задаваемое записью initdefault в файле /etc/inittab.

    За управление runlevels и связанными демонами и ресурсами отвечает программа /sbin/init. Во время инициализации системы программа init определяет требуемый уровень запуска, загружая его из файла /etc/inittab, и загружает связанные сценарии, перечисленные там для данного уровня запуска. Каждый уровень запуска может иметь множество связанных конфигурационных файлов, обычно сценариев которые находятся в каталоге /etc/init.d/. Поскольку не все уровни выполнения в разных дистрибутивах Linux одинаковы, описание уровней выполнения конкретной операционной системы можно просмотреть собственно в самом дистрибутиве.

    Синтаксис /etc/inittab:

    id:runlevels:action:process

    Где id - обобщённое название состоящее из 4х букв, runlevels - список уровней для которых действие выполняется, action - само действие и process - что будет исполнено.

    Доступные действия:

    boot - процесс будет выполнен во время инициализации системы, runlevels в данном случае игнорируется.

    bootwait - процесс будет выполнен во время инициализации системы и init процесс дождётся окончания выполнения данного процесса, runlevels в данном случае игнорируется.

    sysinit - процесс будет выполнен после инициализации системы, runlevels игнорируется.

    wait - процесс будет выполнен для указанного runlevel. Init процесс будет ожидать завершения его инициализации для продолжения.

    respawn - процесс будет перезапущен, если он отключится.

    ctrlaltdel - процесс будет выполнен по сигналу SIGINT, который вызывается сочетанием клавиш Ctrl+alt+Del

    Стандартный runlevel будет выбран если вы не указали ваш собственный. Он тоже указывается в файле /etc/inittab, с конфигурационной строкой id:x:initdefault.

    Пример как выглядит /etc/inittab:

     '# Default runlevel id:3:initdefault: # Configuration script executed during boot si::sysinit:/etc/init.d/rcS # Action taken on runlevel S (single user) ~:S:wait:/sbin/sulogin # Configuration for each execution level 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 # Action taken upon ctrl+alt+del keystroke ca::ctrlaltdel:/sbin/shutdown -r now # Enable consoles for runlevels 2 and 3 1:23:respawn:/sbin/getty tty1 VC linux 2:23:respawn:/sbin/getty tty2 VC linux 3:23:respawn:/sbin/getty tty3 VC linux 4:23:respawn:/sbin/getty tty4 VC linux'

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

    Сценарии, используемые init для настройки каждого уровня выполнения, хранятся в каталоге /etc/init.d/. Каждый уровень запуска имеет связанный каталог в /etc/ с именем /etc/rc0.d/, /etc/rc1.d/ или /etc/rc2.d/ и т. д. со сценарием, который должен выполняться в соответствии с начинающимся уровнем запуска.

    Поскольку один и тот же сценарий может использоваться на разных уровнях выполнения, файлы в этих каталогах представляют собой просто символические ссылки (softlink) на фактические сценарии в /etc/init.d/. Кроме того, первая буква имени файла ссылки в каталоге уровня запуска указывает, следует ли запускать или прекращать службу для соответствующего уровня запуска. Имя файла ссылки, начинающееся с буквы K, определяет, что служба будет завершена при переходе на уровень выполнения (kill). Начиная с буквы S, служба будет запускаться при выходе на уровень запуска (start). В каталоге /etc/rc1.d/, например, будет много ссылок на сетевые сценарии, начинающиеся с буквы K, учитывая, что уровень выполнения 1 - это уровень запуска для одного пользователя без подключения к сети.

    Для проверки текущего уровня выполнения можно использовать команду runlevel.

    $ runlevel N 3

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

    Для перехода между различными уровнями исполнения, можно использовать команду telinit в синтаксисе telinit $runlevel.

    systemd

    В текущий момент основная система менеджмента ресурсов и сервисов это systemd. Единица для systemd это unit. Он включается в себя имя, тип и конфигурационный файл.

    Типы systemd unit-ов:

  • service - самый распространённый тип, используется для активных процессов в системе. Может быть инициализирован, остановлен и перезапущен (на самом деле больше действий, хотя они подразумевают комбинации из этих трёх)
  • socket - Тип socket используется для сокетов в файловой системе или сетевых сокетов. Для существования socket'a необходим также сервис, который запускается параллельно и принимает сообщения через этот сокет.
  • device - unit который связан с аппаратным устройством которое было идентифицировано ядром. Устройство будет считаться unit'ом systemd только в случае наличия udev правила. Device unit используется для разрешения зависимостей конфигурации при обнаружении оборудования (то есть добавления и конфигурации необходимых модулей ядра)
  • mount - точка монтирования в файловой системе, аналогично точкам монтирования в файле /etc/fstab
  • automount - Тоже самое что и mount, но будет смонтирован автоматически как только кто-то попытается зайти в точку монтирования
  • target - группа юнитов других типов, для того чтобы оперировать ими как одним
  • snapshot - сохранение состояния менеджера systemd (не везде доступно)
  • Для управления юнитами systemd используется команда systemctl.

  • systemctl start unit.service - запускается сервис
  • systemctl stop unit.service - останавливает сервис
  • systemctl restart unit.service - перезапуск сервиса
  • systemctl status unit.service - статус сервиса
  • systemctl is-active unit.service - проверяет состояние сервиса
  • systemctl enable unit.service - автозапуск сервиса
  • systemctl disable unit.service - отключение автозапуска сервиса
  • systemctl is-enabled unit.service - проверка статуса автозапуска сервиса
  • systemctl mask unit.service - маскирование сервиса
  • systemctl unmask unit.service - снять маскирование сервиса
  • Если в системе есть только один тип юнита с конкретным названием, то суффикс в названии при команде можно опустить.

    Команда systemctl также может управлять системными целями. Например, модуль multi-user.target объединяет все модули, необходимые для многопользовательской системной среды. Он схож с уровнем выполнения 3 в системе построенной на SysV.

    Команда systemctl isolate чередует разные цели. Итак, чтобы вручную изменить целевой многопользовательский режим:

    # systemctl isolate multi-user.target

    Существуют соответствующие цели для уровней запуска SysV, начиная с runlevel0.target и заканчивая runlevel6.target. Однако systemd не использует файл /etc/inittab. Чтобы изменить системную цель по умолчанию, в список параметров ядра можно добавить параметр systemd.unit. К примеру, чтобы использовать multi-user.target в качестве стандартной цели, параметр ядра должен иметь вид systemd.unit = multi-user.target. Все параметры ядра можно сделать постоянными, изменив конфигурацию загрузчика.

    Другой способ изменить цель по умолчанию - изменить символическую ссылку /etc/systemd/system/default.target, чтобы она указывала на желаемую цель. Переопределение ссылки может быть выполнено самой командой systemctl:

    # systemctl set-default multi-user.target

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

    # systemctl get-default graphical.target

    Подобно системам, использующим SysV, цель по умолчанию никогда не должна указывать на shutdown.target, поскольку она соответствует уровню запуска 0 (завершение работы).

    Файлы конфигурации, связанные с каждым модулем, можно найти в каталоге /lib/systemd/system/. Команда systemctl list-unit-files выводит список всех доступных модулей и показывает, разрешено ли им запускаться при загрузке системы. Опция --type выберет только единицы для данного типа, как в systemctl list-unit-files --type=service и systemctl list-unit-files --type=target.

    Активные юниты или юниты, которые были активны во время текущего системного сеанса, могут быть перечислены с помощью команды systemctl list-units. Как и опция list-unit-files, команда systemctl list-units --type=service выберет только юниты типа service, а команда systemctl list-units --type=target выберет только юниты типа target.

    Команда systemd также отвечает за запуск и реакцию на события, связанные с питанием. Команда systemctl suspend переведет систему в режим низкого энергопотребления, сохраняя текущие данные в памяти. Команда systemctl hibernate копирует все данные из памяти на диск, поэтому текущее состояние системы может быть восстановлено после ее выключения. Действия, связанные с такими событиями, определены в файле /etc/systemd/logind.conf или в отдельных файлах внутри каталога /etc/systemd/logind.conf.d/. Однако эту функцию systemd можно использовать только тогда, когда в системе не запущен другой менеджер питания, например, демон acpid. Демон acpid является основным диспетчером питания для Linux и позволяет более точно настраивать действия после событий, связанных с питанием, таких как закрытие крышки ноутбука, низкий уровень заряда батареи или уровни заряда батареи.

    Upstart - устарел.

    Shutdown and Restart

    Команда, используемая для выключения или перезапуска системы, называется shutdown. Команда shutdown добавляет дополнительные функции к процессу отключения питания: она автоматически уведомляет всех вошедших в систему пользователей предупреждающим сообщением в их shell сеансах, и блокирует новые входы в систему. Команда shutdown действует как посредник для процедур SysV или systemd, то есть выполняет запрошенное действие, вызывая соответствующее действие в диспетчере служб, принятом системой.

    После завершения работы все процессы получают сигнал SIGTERM, за которым следует сигнал SIGKILL, затем система выключается или меняет уровень выполнения. По умолчанию, если не используются параметры -h или -r, то система переходит на уровень выполнения 1, то есть в однопользовательский режим. Чтобы изменить параметры выключения по умолчанию, команду следует выполнить со следующим синтаксисом:

    $ shutdown [option] time [message]

    Обязательным является только параметр времени, который может принимать форматы hh:mm или +m или now

    Параметр message - это сообщение которое будет передано всем пользователям перед отключением системы.

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

    $ sudo which poweroff /usr/sbin/poweroff $ sudo ls -l /usr/sbin/poweroff lrwxrwxrwx 1 root root 14 Aug 20 07:50 /usr/sbin/poweroff -> /bin/systemctl

    Выводы

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

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

    Страницы:

    Linux: использование командной строки

    Большинство проектов построено на Linux. Какими бы инструментами вы не пользовались, в какие бы кластеры не деплоилось ваши приложения, всё равно в основе этого с высокой долей вероятности будет лежать Linux.

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

    Давайте начнём с основ - то есть с работы в консоли.

    Работа в консоли

    Как уже упоминалось, в Linux очень хорошая документация. Используйте команду man или ключ --help/-h. Это позволит вам понять как пользоваться любой другой командой.

    Навигация

    Файловая система Linux имеет иерархическую или древовидную структуру. Имеется корневая точка монтирования и от неё идёт вся структура файловой системы. Здесь нет дисковых разделов, таких как в Windows.

    Для навигации по файловой системе можно пользоваться одной единственной командной - cd, которая расшифровывается как change directory.

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

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

  • l - long, то есть показывается полный вывод, включая атрибуты файлов, права доступа, размер и дату
  • a - all, включает в вывод скрытые файлы
  • h - human-readable, переводит байтовые значения размеров файлов в форматы с приставками
  • Остальные базовые командам для работы в терминале:

  • pwd - print work directory. Если по какой-то причине вы не помните полный путь, где сейчас находитесь - используйте эту команду. Также её часто можно использовать в скриптах для составления полного пути.
  • mkdir - make directory. Создание папки, с полным либо с относительным путём, можно создать всю иерархию сразу, но нужно проверять ключи.
  • rm - remove. Удаление файлов, имеет множество ключей, требует особой осторожности.
  • touch - утилита создана для изменения даты создания файла, однако в подавляющем большинстве просто используется для создания пустых файлов.
  • find - поиск по файловой системе или самим файлам.
  • Переменные окружения

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

    Для получения списка переменных окружения можно использовать команду env, а для более удобного просмотра - перенаправить её вывод в команду more или less через пайп env | less. Про пайпы поговорим немного позже.

    Для получения значения из консоли можно сделать обращение через $VARIABLE. К примеру для вывода значения в консоль echo $VARIABLE.

    Для установки нового значения нужно вставить в командную строку следующую пару:

    VARIABLE=VALUE или команду export VARIABLE=VALUE. Команда export обеспечивает то, что все дочерние процессы от вашей командной строки также будут наследовать значение данной переменной.

     '[root@li2155-195 ~]# TEST_VAR=test_value [root@li2155-195 ~]# echo $TEST_VAR test_value [root@li2155-195 ~]# bash [root@li2155-195 ~]# echo $TEST_VAR [root@li2155-195 ~]# exit [root@li2155-195 ~]# exp ort TEST_VAR [root@li2155-195 ~]# bash [root@li2155-195 ~]# echo $TEST_VAR test_value'

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

     [root@li2155-195 ~]# unset TEST_VAR [root@li2155-195 ~]# echo $TEST_VAR 

    Терминалы и оболочки консоли

    Существует два вида терминалов в Linux: tty и pty:

  • TTY - tele-type-terminal
  • PTY - pseudo-type-terminal
  • Понятие этих терминалов является наследием первых tele-type терминалов, которые использовались для ввода/вывода и работы с первыми компьютерами. По сути это line-by-line ввод и вывод.

    В самом Linux tty - это непосредственно ваши клавиатура и монитор, то есть физическое воплощение терминала. В то время как pty - это программная реализация терминала, необходимая для некоторых программ. Например, для удалённого подключения к машине через ssh.

    Для примера можно посмотреть переменную окружения через ssh подключения которая указывает наш текущий терминал echo $SSH_TTY.

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

    Две консоли, вывести в двух номера псевдо-терминалов: echo $SSH_TTY. Далее тестовая команда вроде

    echo 'hello' > /dev/pts/1.

    Теперь давайте рассмотрим, что такое оболочки терминала и какие существуют.

    Оболочка терминала, это интерпретатор команд, который передаёт ваши команды в API ядра Linux. Эти оболочки бывают разными, и отличаются своим функционалом. Базово всегда присутствует интерпретатор sh, функционал которого не беден, но неприятен в управлении. Далее идёт самый популярный интерпретатор, который включен практически в любой Linux дистрибутив - bash, расшифровывается как bourne again shell. Включает в себя автодополнение, профили, и множество других полезных функций. Далее идут различные интерпретаторы вроде zsh, который лично я бы рекомендовал,а также fish, ksh и так далее. Все они отличаются функционалом и расширяемыми плагинами.

    Расположение бинарных файлов

    Не важно, где в файловой системе находятся исполняемые файлы (не обязательно бинарные), так как любой файл можно передать интерпретатору для запуска в виде ./command. Однако, если вы не хотите использовать постоянно запуск с полным или относительным путём, вы можете использовать дополнение переменной окружения $PATH, которая содержит в себе пути, где система будет искать вводимые команды по умолчанию.

    Давайте посмотрим на формат содержимого этой переменной:

    [root@li2155-195 ~]# echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin

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

    [root@li2155-195 ~]# echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin [root@li2155-195 ~]# export PATH=$PATH:/root/new_bin_folder [root@li2155-195 ~]# echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/root/bin:/root/new_bin_folder

    Пакетные менеджеры

    Пакетных менеджеров существует довольно много, но большинство серверных систем и Docker образов основаны на трёх семействах Debian, Centos(Redhat) и Alpine. Так что список того что нам нужно рассмотреть ограничивается менеджерами apt-get, yum и apk соответственно.

    Вы можете установить пакетные менеджеры на другие системы, но это это не распространено.

    Давайте рассмотрим принципы работы пакетных менеджеров.

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

    Для систем семейства Debian характерно использование пакетного менеджера apt-get и apt. Разница между ними в том, что apt являются надстройкой написаной на Python и использующей apt-get и еще несколько утилит для менеджмента пакетов, cache и репозиториев в системе.

    В системах семейства CentOS и Redhat используется пакетный менеджер yum который, начиная с восьмой версии CentOS, заменён на dnf. Связано это с тем, что yum имел недостатки в виде низкой производительности и высокого потребления памяти.

    В Alpine Linux используется пакетный менеджер apk или alpine packet manager. Отличается низким уровнем кэширования и использованием строго необходимых зависимостей для установки пакетов. Важно знать о нем, так как на базе alpine linux зачастую собираются образы в силу малого размера базового образа с системой.

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

    Каждый файл или папка имеют три набора по три бита в каждом. Каждый из наборов отвечает за отдельный набор пользовательских сущностей: владелец - группа владельца - все остальные

    Каждый их трёх бит может иметь значение 0 или 1 и означать наличие или отсутствие прав на чтение - запись - исполнение.

    Однако, с развитием системы оказалось, что этих параметров недостаточно, и ввели еще три дополнительных параметра:

  • SUID - если этот бит установлен, то при выполнении программы, id пользователя, от которого она запущена заменяется на id владельца файла. Фактически, это позволяет обычным пользователям запускать программы от имени суперпользователя;
  • SGID - этот флаг работает аналогичным образом, только разница в том, что пользователь считается членом группы, с которой связан файл, а не групп, к которым он действительно принадлежит. Если SGID флаг установлен на каталог, то все файлы, созданные в нем, будут связаны с группой каталога, а не пользователя. Такое поведение используется для организации общих папок;
  • Sticky-bit - этот бит тоже используется для создания общих папок. Если он установлен, то пользователи могут только создавать, читать и выполнять файлы, но не могут удалять файлы, принадлежащие другим пользователям. К примеру его можно видеть на стандартной папке /tmp в системе.
  • Как я уже упоминал ранее, можно использовать команду ls с ключом -l чтобы посмотреть полный вывод информации о файлах включая атрибуты.

    [root@li2155-195 ~]# ls -lha / total 68K dr-xr-xr-x. 18 root root 4.0K Aug 10 20:34 . dr-xr-xr-x. 18 root root 4.0K Aug 10 20:34 .. lrwxrwxrwx. 1 root root 7 May 11 2019 bin -> usr/bin dr-xr-xr-x. 5 root root 4.0K Aug 27 11:32 boot drwxr-xr-x. 18 root root 2.9K Aug 27 11:31 dev drwxr-xr-x. 80 root root 4.0K Aug 27 11:31 etc drwxr-xr-x. 2 root root 4.0K May 11 2019 home lrwxrwxrwx. 1 root root 7 May 11 2019 lib -> usr/lib lrwxrwxrwx. 1 root root 9 May 11 2019 lib64 -> usr/lib64 drwx------. 2 root root 16K Aug 10 20:27 lost+found drwxr-xr-x. 2 root root 4.0K May 11 2019 media drwxr-xr-x. 2 root root 4.0K May 11 2019 mnt drwxr-xr-x. 2 root root 4.0K May 11 2019 opt dr-xr-xr-x. 95 root root 0 Aug 27 11:31 proc dr-xr-x---. 4 root root 4.0K Aug 28 23:34 root drwxr-xr-x. 23 root root 660 Aug 27 11:31 run lrwxrwxrwx. 1 root root 8 May 11 2019 sbin -> usr/sbin drwxr-xr-x. 2 root root 4.0K May 11 2019 srv dr-xr-xr-x. 13 root root 0 Aug 27 11:31 sys drwxrwxrwt. 7 root root 4.0K Aug 28 21:09 tmp drwxr-xr-x. 12 root root 4.0K Aug 10 20:28 usr drwxr-xr-x. 20 root root 4.0K Aug 27 11:31 var

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

  • -- (0) - нет прав на файл

    [root@li2155-195 .temp]# chmod 000 00_no_permissions [root@li2155-195 .temp]# ls -lha 00_no_permissions ----------. 1 root root 0 Aug 28 23:54 00_no_permissions
  • r-- (4) - права только на чтение

     [root@li2155-195 .temp]# chmod 400 01_read_only [root@li2155-195 .temp]# ls -lha 01_read_only -r--------. 1 root root 0 Aug 28 23:55 01_read_only
  • w-(2) - права только на запись

    '[root@li2155-195 .temp]# chmod 200 02_write_only [root@li2155-195 .temp]# ls -lha 02_write_only --w-------. 1 root root 0 Aug 28 23:55 02_write_only'
  • -x (1) - права только на исполнение

    [root@li2155-195 .temp]# chmod 100 03_execute_only[root@li2155-195 .temp]# ls -lha 03_execute_only ---x------. 1 root root 0 Aug 28 23:55 03_execute_only
  • rw- (6) - права на чтение и на запись

    [root@li2155-195 .temp]# chmod 600 04_read_write [root@li2155-195 .temp]# ls -lha 04_read_write -rw-------. 1 root root 0 Aug 28 23:55 04_read_write
  • r-w (5) - права на чтение и на исполнение

    [root@li2155-195 .temp]# chmod 500 05_read_execute [root@li2155-195 .temp]# ls -lha 05_read_execute -r-x------. 1 root root 0 Aug 28 23:55 05_read_execute
  • wx (3) - права на запись и на исполнение

    [root@li2155-195 .temp]# chmod 300 06_write_execute [root@li2155-195 .temp]# ls -lha 06_write_execute --wx------. 1 root root 0 Aug 28 23:56 06_write_execute
  • rwx (7) - права на чтение, запись и исполнение

    '[root@li2155-195 .temp]# chmod 300 07_read_write_execute [root@li2155-195 .temp]# ls -lha 07_read_write_execute -rwx------. 1 root root 0 Aug 28 23:57 07_read_write_execute'
  • -S - установлен SUID или SGID биты.
  • Для того чтобы выставить SUID бит, нужно перед основным списком параметров поставить дополнительное значение. Так для SUID это будет 4.

     [root@li2155-195 .temp]# chmod 4700 08_suid_bit [root@li2155-195 .temp]# ls -lha 08_suid_bit -rws------. 1 root root 0 Aug 28 23:59 08_suid_bit

    Для установки SGID бита, требуется поставить значение 2.

    [root@li2155-195 .temp]# chmod 2700 09_sgid_bit [root@li2155-195 .temp]# ls -lha 09_sgid_bit -rwx--S---. 1 root root 0 Aug 29 00:00 09_sgid_bit А для установки SUID и SGID бит одновременно - 4+2=6 [root@li2155-195 .temp]# chmod 6700 10_sgid_suid_bits [root@li2155-195 .temp]# ls -lha 10_sgid_suid_bits -rws--S---. 1 root root 0 Aug 29 00:00 10_sgid_suid_bits
  • -t - установлен sticky бит
  • Sticky-bit устанавливается аналогично SUID и SGID битам, и его значение равно 1

    '[root@li2155-195 .temp]# chmod 1700 11_sticky_bit [root@li2155-195 .temp]# ls -lha 11_sticky_bit -rwx-----T. 1 root root 0 Aug 29 00:00 11_sticky_bit'

    В целом картина будет выглядеть следующим образом

    '[root@li2155-195 .temp]# ls -lh total 0 ----------. 1 root root 0 Aug 28 23:54 00_no_permissions -r--------. 1 root root 0 Aug 28 23:55 01_read_only --w-------. 1 root root 0 Aug 28 23:55 02_write_only ---x------. 1 root root 0 Aug 28 23:55 03_execute_only -rw-------. 1 root root 0 Aug 28 23:55 04_read_write -r-x------. 1 root root 0 Aug 28 23:55 05_read_execute --wx------. 1 root root 0 Aug 28 23:56 06_write_execute -rwx------. 1 root root 0 Aug 28 23:57 07_read_write_execute -rws------. 1 root root 0 Aug 28 23:59 08_suid_bit -rwx--S---. 1 root root 0 Aug 29 00:00 09_sgid_bit -rws--S---. 1 root root 0 Aug 29 00:00 10_sgid_suid_bits -rwx-----T. 1 root root 0 Aug 29 00:00 11_sticky_bit'

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

    Команда chmod имеет следующий синтаксис: chmod опции категория действие разрешение путь к файлу.

    Категорий соответственно бывает три (в литералах):

  • u - владелец файла
  • g - группа файла
  • o - все остальные
  • a - all, применить ко всем сразу
  • Действий может быть три: + - добавить разрешения, - - удалить разрешения, = - оставляет только указанные права.

    Разрешения в литералах:

  • r - чтение
  • w - запись
  • x - исполнение
  • s - suid/sgid в зависимости от применения
  • t - sticky bit
  • Примеры эквивалентных команд (предполагаем что по умолчанию файл создан с нулевыми правами):

     chmod 000 00_no_permissions #или chmod ugo-rwx 00_no_permissions chmod 400 01_read_only #или chmod u+r 01_read_only chmod 200 02_write_only #или chmod u+w 02_write_only chmod 100 03_execute_only #или chmod u+x 03_execute_only chmod 600 04_read_write #или chmod u+rw 04_read_write chmod 500 05_read_execute #или chmod u+rw 05_read_execute chmod 300 06_write_execute #или chmod u+wx 06_write_execute chmod 700 07_read_write_execute #или chmod u+rwx 07_read_write_execute chmod 4700 08_suid_bit #или chmod u+rws 08_suid_bit chmod 2700 09_sgid_bit #или chmod u+rwx,g+s 09_sgid_bit chmod 6700 10_sgid_suid_bits #или chmod u+rws,g+s 10_sgid_suid_bits chmod 1700 11_sticky_bit #или chmod u+rwxt 11_sticky_bit

    Владельцы файлов в Linux

    У файла есть владелец и группа файла. Узнать можно всё так же с помощью команды ls -l.

    Изменяется всё достаточно просто с помощью команды chown [options] [user][:group] file_path

    Linux: работа с устройствами (физическими или виртуальными)

    Обзор присутствующих устройств в системе (Device Inspection in Linux)

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

    Применяются следующие команды для инспекции оборудования

  • lsusb - показывает информацию об устройствах на шине USB.
  • lspci - показывает информацию об устройствах на шине PCI.
  • В случае отсутствия исполняемых файлов, они могут находить в устанавливаемых пакетах pciutils и usbutils.

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

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

    Итак, если ввести просто lspci, то мы получим список всех устройств подключенных по шинам PCI:

     root@localhost:~# lspci 00:00.0 Host bridge: Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller 00:01.0 VGA compatible controller: Device 1234:1111 (rev 02) 00:02.0 SCSI storage controller: Red Hat, Inc. Virtio SCSI 00:03.0 SCSI storage controller: Red Hat, Inc. Virtio SCSI 00:04.0 Ethernet controller: Red Hat, Inc. Virtio network device 00:1f.0 ISA bridge: Intel Corporation 82801IB (ICH9) LPC Interface Controller (rev 02) 00:1f.2 SATA controller: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA Controller [AHCI mode] (rev 02) 00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 02)

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

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

     root@localhost:~# lspci -v -s 00:01.0 00:01.0 VGA compatible controller: Device 1234:1111 (rev 02) (prog-if 00 [VGA controller]) Subsystem: Red Hat, Inc. Device 1100 Flags: fast devsel Memory at fd000000 (32-bit, prefetchable) [size=16M] Memory at febd0000 (32-bit, non-prefetchable) [size=4K] Expansion ROM at 000c0000 [disabled] [size=128K] Kernel driver in use: bochs-drm Kernel modules: bochs_drm

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

     root@localhost:~# lspci -s 00:1f.0 -k 00:1f.0 ISA bridge: Intel Corporation 82801IB (ICH9) LPC Interface Controller (rev 02) Subsystem: Red Hat, Inc. QEMU Virtual Machine Kernel driver in use: lpc_ich Kernel modules: lpc_ich

    Так же можно взглянуть на иерархию шины PCI:

     root@localhost:~# lspci -t -v -[0000:00]-+-00.0 Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller +-01.0 Device 1234:1111 +-02.0 Red Hat, Inc. Virtio SCSI +-03.0 Red Hat, Inc. Virtio SCSI +-04.0 Red Hat, Inc. Virtio network device +-1f.0 Intel Corporation 82801IB (ICH9) LPC Interface Controller +-1f.2 Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA Controller [AHCI mode] \-1f.3 Intel Corporation 82801I (ICH9 Family) SMBus Controller

    Модули (драйверы и не только) ядра

    Список загруженных модулей ядра можно посмотреть командой lsmod

    'root@localhost:~# lspci -t -v -[0000:00]-+-00.0 Intel Corporation 82G33/G31/P35/P31 Express DRAM Controller +-01.0 Device 1234:1111 +-02.0 Red Hat, Inc. Virtio SCSI +-03.0 Red Hat, Inc. Virtio SCSI +-04.0 Red Hat, Inc. Virtio network device +-1f.0 Intel Corporation 82801IB (ICH9) LPC Interface Controller +-1f.2 Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA Controller [AHCI mode] \-1f.3 Intel Corporation 82801I (ICH9 Family) SMBus Controller'

    Вывод состоит из трёх колонок:

  • Module - название модуля
  • Size - объем оперативной памяти занимаемой модулем
  • Used by - список модулей которые зависят от конкретных модулей
  • С помощью команды modinfo можно посмотреть ощутимо больше информации о модуле, к примеру:

     '[root@li2155-195 ~]# modinfo ext4 filename: /lib/modules/4.18.0-193.14.2.el8_2.x86_64/kernel/fs/ext4/ext4.ko.xz softdep: pre: crc32c license: GPL description: Fourth Extended Filesystem author: Remy Card, Stephen Tweedie, Andrew Morton, Andreas Dilger, Theodore Ts'o and others alias: fs-ext4 alias: ext3 alias: fs-ext3 alias: ext2 alias: fs-ext2 rhelversion: 8.2 srcversion: 408EBC8810B3BE8D2C737DF depends: mbcache,jbd2 intree: Y name: ext4 vermagic: 4.18.0-193.14.2.el8_2.x86_64 SMP mod_unload modversions sig_id: PKCS#7 signer: CentOS Linux kernel signing key sig_key: 4B:D0:A9:10:8D:FE:73:3E:92:80:DF:8E:CF:B1:3F:46:D3:64:29:C5 sig_hashalgo: sha256 signature: 0A:81:D1:32:CE:0D:2B:7A:1D:1F:69:BA:03:1B:92:32:87:00:70:9D: AC:EE:09:97:F2:4A:F8:95:A2:C2:0A:51:EF:9F:8B:7A:48:A7:83:98: 6C:DA:B5:26:7A:2D:B7:A7:43:75:05:C4:87:BD:CC:ED:86:C6:FE:9B: 90:8E:3D:1D:8B:E1:79:2B:9A:B5:E9:C1:A9:30:9D:EA:7A:1B:1C:23: AB:54:AD:1B:2E:39:0D:F3:8D:1B:62:28:1E:C1:B4:54:E0:26:D8:24: 9A:9A:DE:EF:6B:07:26:27:EC:88:32:25:2E:8E:0D:18:FA:0E:34:37: B7:C8:5B:20:75:B2:CA:DB:7E:69:D2:DF:D2:37:5C:ED:F0:C3:08:14: E3:2E:EA:1A:2A:5E:FD:D8:46:37:CA:62:E0:91:E2:8A:B6:A4:00:3D: 5D:1D:5E:2A:80:B0:08:A4:4F:2D:DE:7C:02:83:F9:0D:B7:D1:84:5C: A8:3B:86:A1:D2:9A:3B:7D:4B:E1:FA:C5:9D:78:0E:B2:41:D7:A1:35: 9D:E6:62:20:07:02:1B:93:16:7A:7C:3F:7F:A4:B4:E4:4D:41:C6:D1: B4:A3:0E:9B:BC:D7:F3:16:C6:F9:57:54:75:81:3D:42:D1:13:7C:A0: 70:E0:65:C1:B6:8B:6B:19:FA:EA:B7:97:DC:C3:92:EC:F7:E3:6A:17: 53:EE:4F:16:25:59:42:10:79:0F:AE:F0:44:B1:4F:85:3F:56:88:9F: 0B:9F:21:85:9D:4F:BE:DA:FF:F0:99:A6:88:1F:DF:B9:64:31:68:9A: 78:DF:31:E0:25:46:9A:4F:1C:61:CE:EE:EF:24:F0:0B:A5:0F:13:AC: B9:BB:38:2E:5D:F5:E3:97:1B:B4:4F:51:2C:9E:8E:F6:08:86:ED:0A: C1:67:FB:78:B1:C9:8D:A7:AD:F8:72:D3:8D:B3:06:C2:5E:A7:1F:00: 09:BB:93:50:50:13:C1:E3:5F:7F:B5:AD:0A:32:0C:58:98:67:A0:81: DD:89:1E:F1'

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

  • /etc/modprobe.conf - общий файл конфигурации
  • /etc/modprobe.d/ - индивидуальные файлы конфигурации
  • Подключить или отключить модули можно командами

  • modprobe $имя_модуля - для подключения
  • modprobe -r $имя_модуля - для отключения
  • Логи о подключении или или отключении модулей можно увидеть в файле /var/log/messages или используя journalctl.

    Файлы хранящие информацию об устройствах

    Все команды с приставками ls (продемонстрированные ранее lspci, lsusb и lsmod) работают как фронтэнд части для хранилищ информации об устройствах или модулях. В целом вся специальная информация располагается в каталогах /proc, /sys и /dev. Эти каталоги не существуют на самом деле в файловой системе -- это точки монтирования из оперативной памяти.

    Каталог /proc содержит информацию о запущенных процессах, текущих аппаратных ресурсах и состоянии операционной системы:

  • /proc/cpuinfo - информация о центральном процессоре
  • /proc/meminfo - информация об имеющейся оперативной памяти
  • /proc/interrupts - информация о настройках прерываний всех устройств ввода/вывода
  • Каталог /sys содержит базовую информацию о подключенных устройствах.

    Каталог /dev содержит информацию об интерфейсах работы с модулями ядра.

    Устройства хранения

    Как уже было упомянуто, устройства хранения имеют системные файлы в каталоге /dev и имеют следующий список префиксов для идентификации:

  • sd - IDE, SSD и USB блочные устройства, не важно по каким шинам подключены, будь то SATA, pci или SCSI, начиная с версии ядра линукса 2.4 они были объединены в один префикс.
  • mmcblk - имеют SD кард-ридеры
  • nvme - префикс соответственно имеют NVME устройства хранения
  • Linux процесс загрузки

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

    BIOS or UEFI

    В зависимости от использования системой BIOS или UEFI - различаются и процедуры запуска системы.

    BIOS или Basic Input / Output System - это микрокод, хранящийся в энергонезависимой памяти на материнской плате, он выполняется каждый раз при включении компьютера. В процессе загрузки BIOS предполагает, что первые 440 байт в первом хранилище дисковой подсистемы - следуя порядку, находящемуся в настройках BIOS (автоматически определяется по очерёдности разъёмов подключения на плате) - являются первым этапом загрузчика. Первые 512 байт хранилища называются главной загрузочной записью MBR (Master Boot Record). Master Boot Record использует стандартную схему разделов DOS и дополняет первый этап загрузчика таблицей разделов файловой системы.

    Итак, основные шаги загрузки системы с BIOS:

  • Процесс POST (power-on self-test) выполняется для выявления простых отказов оборудования сразу после включения системы.
  • BIOS подключает базовые компоненты системы для загрузки - видеовывод, клавиатура и дисковые носители.
  • BIOS передает управление загрузчику находящемуся в MBR (первые 440 байт на первом носителе).
  • Первый этап загрузчика вызывает вторую ступень, отвечающую за представление параметров загрузки ядру и его вызов.
  • UEFI или Unified Extensible Firmware Interface - имеет отличия от BIOS в некоторых ключевых моментах. Как и BIOS, UEFI также является микрокодом (firmware) и находится на материнской плате. Однако он может идентифицировать разделы и умеет работать с многими файловыми системами. UEFI не работает напрямую с MBR, а использует только настройки находящиеся в его энергонезависимой памяти (NVRAM). Хранимые настройки указывают на расположение UEFI-совместимых программ, называемых EFI-applications, которые будут выполняться автоматически или вызываться из меню загрузки. Приложения EFI могут быть загрузчиками, средствами выбора операционной системы, инструментами для диагностики и восстановления системы и так далее. Они должны находиться на обычном разделе устройства хранения и в совместимой файловой системе. Стандартные совместимые файловые системы - это FAT12, FAT16, FAT32 и вроде с недавнего времени exFAT(fat64) для блочных устройств и ISO-9660 для оптических носителей. Всё это в совокупности позволяет значительно проще использовать более сложные инструменты диагностики, так как не надо писать новый загрузчик для того чтобы, к примеру, протестировать оперативную память.

    Раздел, содержащий приложения EFI, называется системным разделом EFI или просто ESP (efi system partition). Этот раздел не должен использоваться совместно с другими системными файловыми системами. Каталог EFI в разделе ESP содержит приложения, на которые указывают записи, сохраненные в NVRAM.

    Основные шаги для загрузки системы с UEFI:

  • POST (самотестирование при включении) процесс выполняется для выявления простых отказов оборудования сразу после включения машины.
  • UEFI подключает базовые компоненты системы для загрузки - видеовывод, клавиатура и дисковые носители.
  • UEFI считывает определения, хранящиеся в NVRAM, чтобы выполнить предопределенное приложения EFI, хранящегося в файловой системе раздела ESP. Обычно предопределенное приложение EFI является загрузчиком.
  • Если предопределенное приложение EFI является загрузчиком, он загружает ядро для запуска операционной системы.
  • Стандарт UEFI также поддерживает функцию Secure Boot, которая позволяет выполнять только лицензированные приложения, то есть приложения EFI, авторизованные производителем оборудования. Эта функция повышает защиту от вредоносного программного обеспечения, но может затруднить установку операционных систем, на которые не распространяется гарантия производителя.

    The Bootloader

    Самый популярный загрузчик для Linux на архитектуре x86 - GRUB (Grand Unified Bootloader). Как только он вызывается BIOSом или UEFI, GRUB отображает список операционных систем, доступных для загрузки. Если список не выводится автоматически, то его можно вызвать, нажав Shift, во время вызова BIOSом GRUB. Если система использует UEFI то для вызова списка операционных системы можно использовать Esc.

    В меню GRUB можно выбрать, какое из установленных ядер должно быть загружено, и передать ему новые параметры. Большинство параметров ядра это key/value значения. Пример нескольких параметров ядра.

    acpi - Включает / отключает поддержку ACPI. acpi=off отключит поддержку ACPI.

    init - Изменяет точку входа в систему. К примеру вы можете выставить init=/bin/bash установит оболочку Bash в качестве точки входа. полезно для ремонта системы.

    systemd.unit - Устанавливает цель systemd для активации. Например, systemd.unit=graphical.target. Systemd также принимает числовые уровни запуска, определенные для инициализации в стиле SysV. Например, чтобы активировать уровень выполнения 1, необходимо включить только цифру 1 или букву S (сокращение от "single") в качестве параметра ядра.

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

    maxcpus - Ограничивает количество процессоров (или ядер процессора), видимых системе.

    quiet - ****Скрывает большинство загрузочных сообщений.

    vga - Выбирает режим видео. Параметр vga=ask покажет список доступных режимов на выбор.

    root - Устанавливает корневой раздел, отличный от предварительно настроенного в загрузчике. Например, root=/dev/sda3.

    rootflags - Mount параметры для корневой файловой системы.

    ro - Выполняет первоначальное монтирование корневой файловой системы доступным только для чтения.

    rw - Разрешает запись в корневую файловую систему во время первоначального монтирования.

    Изменение параметров ядра обычно не требуется, но может быть полезно для обнаружения и решения проблем, связанных с операционной системой. Параметры ядра необходимо добавить в файл /etc/default/grub в строке GRUB_CMDLINE_LINUX, чтобы сделать их постоянными при перезагрузках. Новый файл конфигурации для загрузчика должен создаваться каждый раз при изменении /etc/default/grub, что выполняется командой grub-mkconfig -o /boot/grub/grub.cfg. После запуска операционной системы параметры ядра, используемые для загрузки текущего сеанса, доступны для чтения в файле /proc/cmdline.

    System Initialization

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

    Исторически сложилось, что существует множество способов запуска скриптов и демонов, вследствие чего появилось несколько способов инициализации системы. Хотя в принципе в текущий момент всё свелось к единому systemd.

    Инициализация операционной системы начинается, когда загрузчик загружает ядро в ОЗУ. Затем ядро берет на себя управление и начинает конфигурировать основные части операционной системы, такие как базовая конфигурация оборудования и адресация памяти.

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

    Как только будет доступна корневая файловая система, ядро смонтирует все точки монтирования в файловой системе, которые оно возьмёт из файла /etc/fstab, а затем передаст управление системе указанной как точка входа, стандартной - утилите с именем init. Программа init отвечает за запуск всех сценариев инициализации и системных демонов. Существуют различные реализации таких системных инициаторов, помимо традиционного init, такие как systemd и Upstart (на самом деле всё кроме systemd безнадежно устарело). После загрузки программы init файл initramfs удаляется из ОЗУ.

    Коротко рассмотрим основные стили инициализации:

  • SysV standard - менеджер служб, основанный на стандарте SysVinit, контролирует, какие демоны и ресурсы будут доступны используя концепцию уровней запуска. Уровни выполнения пронумерованы от 0 до 6 и разработаны разработчиками дистрибутива для выполнения определенных целей. Единственные определения уровней выполнения, общие для всех дистрибутивов, - это уровни выполнения 0, 1 и 6.
  • systemd ****- это современный менеджер систем и служб с уровнем совместимости для команд и уровней запуска SysV. Менеджер systemd имеет параллельную структуру, использует сокеты и D-Bus (система межпроцессного взаимодействия) для активации служб, выполнения демона по требованию, мониторинга процессов с помощью cgroups, поддержки snapshot'ов, восстановления системной сессии, управления точкой монтирования и управления службами на основе зависимостей. В текущее время практически все дистрибутивы имеют systemd в качестве основного системного менеджера.
  • Upstart - Как и systemd, Upstart заменяет init. Цель применения Upstart - ускорить процесс загрузки за счет распараллеливания процесса загрузки системных служб. Upstart использовался в дистрибутивах на основе Ubuntu в прошлых выпусках, но сегодня уступил место ystemd.
  • Troubleshooting

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

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

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

    В системах на основе управляющей системы systemd команда journalctl покажет сообщения инициализации с параметрами -b, --boot, -k или --dmesg. Команда journalctl --list-boots показывает список номеров загрузки относительно текущей загрузки, их идентификационный хэш и временные метки первого и последнего соответствующих сообщений:

    В системах на основе systemd так же хранятся журналы предыдущих инициализаций, так что вы можете проводить диагностику за несколько загрузок. Если указаны параметры -b 0 или --boot= 0, то будут показаны сообщения для текущей загрузки. Опции -b -1 или --boot = -1 будут отображать сообщения от предыдущей инициализации. Опции -b -2 или --boot = -2 покажут сообщения от инициализации до этого и так далее. В следующем отрывке показано, как ядро вызывает диспетчер служб systemd для последнего процесса инициализации:

    Инициализация и другие сообщения, выдаваемые операционной системой, хранятся в файлах в каталоге /var/log/. Если происходит критическая ошибка и операционная система не может продолжить процесс инициализации после загрузки ядра и initramfs, можно использовать альтернативный загрузочный носитель для запуска системы и доступа к соответствующей файловой системе. Затем можно проверить логи на предмет возможных причин обусловливающих проблемы с загрузкой. Параметры -D или --directory команды journalctl могут использоваться для чтения сообщений журнала в каталогах, отличных от / var / log / journal /, который является местоположением по умолчанию для сообщений журнала systemd. Поскольку сообщения журнала systemd не хранятся в виде необработанного текста, для их чтения требуется команда journalctl.

    Ядро системы

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

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

    Службы могут управляться shell скриптами или корневым демоном управляющим всеми остальными демонами. Первый метод реализуется стандартом SysVinit, также известным как System V или просто SysV, но он устарел и практически больше не используется. Второй способ реализуется с помощью systemd и Upstart (который тоже устарел). Условно говоря, диспетчер служб - это первая программа, запускаемая ядром в процессе загрузки, поэтому ее PID (идентификационный номер процесса) всегда равен 1.

    SysVinit

    Для понимания, всё же рассмотрим старую версию инициализации в стиле SysV. Диспетчер служб, основанный на стандарте SysVinit, будет предоставлять предопределенные наборы состояний системы которые называются runlevels (или уровни исполнения/уровни работы ОС), и соответствующие им файлы shell script'ов для выполнения. Уровни исполнения существуют от 0-го до 6-го.

    Runlevel 0 - Выключение операционной системы.

    Runlevel 1, s or single - Перевести систему в режим системного администрирования. При этом все локальные файловые системы смонтированы. Работает только небольшой набор существенных процессов ядра. Этот режим предназначен для решения административных задач, например, установки дополнительных пакетов. Все файлы доступны, и никакие пользователи в системе не зарегистрированы. Используется для диагностики/обслуживание и восстановления системы.

    Runlevel 2 - Перевести систему в многопользовательский режим. Запускаются все необходимые для работы многопользовательской среды процессы и демоны. Это состояние обычно называют многопользовательским.

    Runlevel 3 -Расширить многопользовательский режим, предоставляя доступ по сети к локальным ресурсам.

    Runlevel 4 - Multi-user mode. - Можно определять как альтернативную конфигурацию многопользовательской среды. Этот уровень выполнения не обязателен для работы системы и обычно не используется.

    Уровни 2 и 4 не используются.

    Runlevel 5 - Multi-user mode. Такой же как и третий, но присутствует также графическая оболочка.

    Runlevel 6 - Перезагрузка системы. Остановить операционную систему и перезагрузить ее в состояние, задаваемое записью initdefault в файле /etc/inittab.

    За управление runlevels и связанными демонами и ресурсами отвечает программа /sbin/init. Во время инициализации системы программа init определяет требуемый уровень запуска, загружая его из файла /etc/inittab, и загружает связанные сценарии, перечисленные там для данного уровня запуска. Каждый уровень запуска может иметь множество связанных конфигурационных файлов, обычно сценариев которые находятся в каталоге /etc/init.d/. Поскольку не все уровни выполнения в разных дистрибутивах Linux одинаковы, описание уровней выполнения конкретной операционной системы можно просмотреть собственно в самом дистрибутиве.

    Синтаксис /etc/inittab:

    id:runlevels:action:process

    Где id - обобщённое название состоящее из 4х букв, runlevels - список уровней для которых действие выполняется, action - само действие и process - что будет исполнено.

    Доступные действия:

    boot - процесс будет выполнен во время инициализации системы, runlevels в данном случае игнорируется.

    bootwait - процесс будет выполнен во время инициализации системы и init процесс дождётся окончания выполнения данного процесса, runlevels в данном случае игнорируется.

    sysinit - процесс будет выполнен после инициализации системы, runlevels игнорируется.

    wait - процесс будет выполнен для указанного runlevel. Init процесс будет ожидать завершения его инициализации для продолжения.

    respawn - процесс будет перезапущен, если он отключится.

    ctrlaltdel - процесс будет выполнен по сигналу SIGINT, который вызывается сочетанием клавиш Ctrl+alt+Del

    Стандартный runlevel будет выбран если вы не указали ваш собственный. Он тоже указывается в файле /etc/inittab, с конфигурационной строкой id:x:initdefault.

    Пример как выглядит /etc/inittab:

     '# Default runlevel id:3:initdefault: # Configuration script executed during boot si::sysinit:/etc/init.d/rcS # Action taken on runlevel S (single user) ~:S:wait:/sbin/sulogin # Configuration for each execution level 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 # Action taken upon ctrl+alt+del keystroke ca::ctrlaltdel:/sbin/shutdown -r now # Enable consoles for runlevels 2 and 3 1:23:respawn:/sbin/getty tty1 VC linux 2:23:respawn:/sbin/getty tty2 VC linux 3:23:respawn:/sbin/getty tty3 VC linux 4:23:respawn:/sbin/getty tty4 VC linux'

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

    Сценарии, используемые init для настройки каждого уровня выполнения, хранятся в каталоге /etc/init.d/. Каждый уровень запуска имеет связанный каталог в /etc/ с именем /etc/rc0.d/, /etc/rc1.d/ или /etc/rc2.d/ и т. д. со сценарием, который должен выполняться в соответствии с начинающимся уровнем запуска.

    Поскольку один и тот же сценарий может использоваться на разных уровнях выполнения, файлы в этих каталогах представляют собой просто символические ссылки (softlink) на фактические сценарии в /etc/init.d/. Кроме того, первая буква имени файла ссылки в каталоге уровня запуска указывает, следует ли запускать или прекращать службу для соответствующего уровня запуска. Имя файла ссылки, начинающееся с буквы K, определяет, что служба будет завершена при переходе на уровень выполнения (kill). Начиная с буквы S, служба будет запускаться при выходе на уровень запуска (start). В каталоге /etc/rc1.d/, например, будет много ссылок на сетевые сценарии, начинающиеся с буквы K, учитывая, что уровень выполнения 1 - это уровень запуска для одного пользователя без подключения к сети.

    Для проверки текущего уровня выполнения можно использовать команду runlevel.

    $ runlevel N 3

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

    Для перехода между различными уровнями исполнения, можно использовать команду telinit в синтаксисе telinit $runlevel.

    systemd

    В текущий момент основная система менеджмента ресурсов и сервисов это systemd. Единица для systemd это unit. Он включается в себя имя, тип и конфигурационный файл.

    Типы systemd unit-ов:

  • service - самый распространённый тип, используется для активных процессов в системе. Может быть инициализирован, остановлен и перезапущен (на самом деле больше действий, хотя они подразумевают комбинации из этих трёх)
  • socket - Тип socket используется для сокетов в файловой системе или сетевых сокетов. Для существования socket'a необходим также сервис, который запускается параллельно и принимает сообщения через этот сокет.
  • device - unit который связан с аппаратным устройством которое было идентифицировано ядром. Устройство будет считаться unit'ом systemd только в случае наличия udev правила. Device unit используется для разрешения зависимостей конфигурации при обнаружении оборудования (то есть добавления и конфигурации необходимых модулей ядра)
  • mount - точка монтирования в файловой системе, аналогично точкам монтирования в файле /etc/fstab
  • automount - Тоже самое что и mount, но будет смонтирован автоматически как только кто-то попытается зайти в точку монтирования
  • target - группа юнитов других типов, для того чтобы оперировать ими как одним
  • snapshot - сохранение состояния менеджера systemd (не везде доступно)
  • Для управления юнитами systemd используется команда systemctl.

  • systemctl start unit.service - запускается сервис
  • systemctl stop unit.service - останавливает сервис
  • systemctl restart unit.service - перезапуск сервиса
  • systemctl status unit.service - статус сервиса
  • systemctl is-active unit.service - проверяет состояние сервиса
  • systemctl enable unit.service - автозапуск сервиса
  • systemctl disable unit.service - отключение автозапуска сервиса
  • systemctl is-enabled unit.service - проверка статуса автозапуска сервиса
  • systemctl mask unit.service - маскирование сервиса
  • systemctl unmask unit.service - снять маскирование сервиса
  • Если в системе есть только один тип юнита с конкретным названием, то суффикс в названии при команде можно опустить.

    Команда systemctl также может управлять системными целями. Например, модуль multi-user.target объединяет все модули, необходимые для многопользовательской системной среды. Он схож с уровнем выполнения 3 в системе построенной на SysV.

    Команда systemctl isolate чередует разные цели. Итак, чтобы вручную изменить целевой многопользовательский режим:

    # systemctl isolate multi-user.target

    Существуют соответствующие цели для уровней запуска SysV, начиная с runlevel0.target и заканчивая runlevel6.target. Однако systemd не использует файл /etc/inittab. Чтобы изменить системную цель по умолчанию, в список параметров ядра можно добавить параметр systemd.unit. К примеру, чтобы использовать multi-user.target в качестве стандартной цели, параметр ядра должен иметь вид systemd.unit = multi-user.target. Все параметры ядра можно сделать постоянными, изменив конфигурацию загрузчика.

    Другой способ изменить цель по умолчанию - изменить символическую ссылку /etc/systemd/system/default.target, чтобы она указывала на желаемую цель. Переопределение ссылки может быть выполнено самой командой systemctl:

    # systemctl set-default multi-user.target

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

    # systemctl get-default graphical.target

    Подобно системам, использующим SysV, цель по умолчанию никогда не должна указывать на shutdown.target, поскольку она соответствует уровню запуска 0 (завершение работы).

    Файлы конфигурации, связанные с каждым модулем, можно найти в каталоге /lib/systemd/system/. Команда systemctl list-unit-files выводит список всех доступных модулей и показывает, разрешено ли им запускаться при загрузке системы. Опция --type выберет только единицы для данного типа, как в systemctl list-unit-files --type=service и systemctl list-unit-files --type=target.

    Активные юниты или юниты, которые были активны во время текущего системного сеанса, могут быть перечислены с помощью команды systemctl list-units. Как и опция list-unit-files, команда systemctl list-units --type=service выберет только юниты типа service, а команда systemctl list-units --type=target выберет только юниты типа target.

    Команда systemd также отвечает за запуск и реакцию на события, связанные с питанием. Команда systemctl suspend переведет систему в режим низкого энергопотребления, сохраняя текущие данные в памяти. Команда systemctl hibernate копирует все данные из памяти на диск, поэтому текущее состояние системы может быть восстановлено после ее выключения. Действия, связанные с такими событиями, определены в файле /etc/systemd/logind.conf или в отдельных файлах внутри каталога /etc/systemd/logind.conf.d/. Однако эту функцию systemd можно использовать только тогда, когда в системе не запущен другой менеджер питания, например, демон acpid. Демон acpid является основным диспетчером питания для Linux и позволяет более точно настраивать действия после событий, связанных с питанием, таких как закрытие крышки ноутбука, низкий уровень заряда батареи или уровни заряда батареи.

    Upstart - устарел.

    Shutdown and Restart

    Команда, используемая для выключения или перезапуска системы, называется shutdown. Команда shutdown добавляет дополнительные функции к процессу отключения питания: она автоматически уведомляет всех вошедших в систему пользователей предупреждающим сообщением в их shell сеансах, и блокирует новые входы в систему. Команда shutdown действует как посредник для процедур SysV или systemd, то есть выполняет запрошенное действие, вызывая соответствующее действие в диспетчере служб, принятом системой.

    После завершения работы все процессы получают сигнал SIGTERM, за которым следует сигнал SIGKILL, затем система выключается или меняет уровень выполнения. По умолчанию, если не используются параметры -h или -r, то система переходит на уровень выполнения 1, то есть в однопользовательский режим. Чтобы изменить параметры выключения по умолчанию, команду следует выполнить со следующим синтаксисом:

    $ shutdown [option] time [message]

    Обязательным является только параметр времени, который может принимать форматы hh:mm или +m или now

    Параметр message - это сообщение которое будет передано всем пользователям перед отключением системы.

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

    $ sudo which poweroff /usr/sbin/poweroff $ sudo ls -l /usr/sbin/poweroff lrwxrwxrwx 1 root root 14 Aug 20 07:50 /usr/sbin/poweroff -> /bin/systemctl

    Выводы

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

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

    Вернуться к учебному плану