Спор вокруг систем инициализации в Linux
System V init (или просто «SysV») — это система инициализации, которая существует со времен операционной системы System V, которая была выпущена в 1983 году. SysV оставалась системой инициализации в течение почти трех десятилетий (за некоторыми исключениями). Многие IT-специалисты и программисты в силу своей привычки не хотели отказываться от SysV, да и к тому же она была очень простой для понимания.
Проблема с SysV заключалась в том, что в её основе лежали концепции, существовавшие много лет назад. SysV не хватало возможности нативно обрабатывать многие вещи, такие как: обнаружение съемных носителей, корректное обнаружение аппаратного обеспечения и загрузка встроенного ПО, загрузка различных модулей и пр. Кроме того, при использовании данной системы, инициализация процессов происходит последовательно, т.е. одна задача запускается только после успешного завершения предыдущей. Часто это приводило к задержке и длительному времени загрузки. Задачи, подобные монтированию файловых систем, выполняются один раз во время загрузки, после чего «забываются». Но такого подхода недостаточно для автоматизированного управления сервисами, требующими к себе постоянного внимания.
В попытке привнести больше возможностей в процесс инициализации Linux-систем, компания Canonical в 2006 году вместе с релизом Ubuntu 6.10 (Edgy Eft) выпускает систему инициализации Upstart, которая с самого начала разрабатывалась с учетом обратной совместимости. Она может запускать демоны без каких-либо изменений в их скриптах запуска.
Другой системой инициализации, восходящей своими корнями к операционной системе 4.4BSD, является rc.init. Она применяется в таких дистрибутивах, как: FreeBSD, NetBSD и Slackware. В 2007 году разработчики Gentoo выпустили улучшенный вариант данной системы инициализации, сделав её модульной и назвав OpenRC. Большинство других дистрибутивов Linux исторически продолжало использовать SysV.
В 2010 году инженеры компании Red Hat Леннарт Пёттеринг и Кей Сиверс приступили к разработке новой системы инициализации — systemd, которая разрабатывалась с учетом недостатков, имеющихся в SysV. В состав systemd, помимо прочего, также входят и различные пакеты, утилиты и библиотеки, позволяющие производить параллельный запуск процессов, сокращая тем самым время загрузки системы и количество необходимых вычислений. Весной того же года Fedora 15 стала первым дистрибутивом, в котором по умолчанию использовалась система инициализации systemd. После чего, на протяжении следующих трех лет, большинство дистрибутивов массово перешли на systemd.
Но, если все остальные дистрибутивы отдают предпочтение systemd и считают её лучшей системой инициализации, как для предприятий, так и для любителей, почему так много споров вокруг нее?
systemd, по сравнению с SysV и Upstart, содержит большое количество различных улучшений, а также предлагает и другие компоненты, имеющие более тесную интеграцию с системой, с помощью которых разработчики могут уменьшить объем выполняемой работы. Что в этом плохого? Ну, поскольку разработчики создают программное обеспечение, которое зависит от systemd и/или от любой из её многочисленных служб (journald, udevd, consoled, logind или networkd), то такое ПО становится менее совместимым с системами, в которых systemd не применяется. По мере того, как количество служб, предоставляемых проектом systemd, продолжает расти, systemd сама становится все более зависимой от них.
В результате systemd становится самостоятельной платформой, и её повсеместное распространение непреднамеренно препятствует разработке программного обеспечения, которое является переносимым и совместимым с операционными системами, не поддерживающими systemd. Но действительно ли всё так печально? Конечно, нет. Прежде всего, это проект с открытым исходным кодом, и у людей есть выбор: использовать его или нет. Пользователи и разработчики могут извлечь выгоду из наличия нескольких конкурирующих систем инициализации, и нет вины systemd в том, что основные дистрибутивы переключились на нее из-за её плюсов.
Логи сервера с ошибками error.log
Это журнал с информацией об ошибках на сайте. В нем можно посмотреть, какие страницы отсутствуют, откуда пришел пользователь с конкретным запросом, имеются ли «битые» ссылки, другие недочеты, включая те, которые не удалось классифицировать. Используется для выявления багов и погрешностей в коде.
Каждая ошибка в логе сервера error.log отображается с новой строки. Идентифицировав и устранив ее, программист сможет наладить работу сайта. Используя журнал, можно выявить и слабые места веб-платформы. Это простой и удобный инструмент анализа, которым должен уметь пользоваться каждый веб-мастер, системный администратор и программист.
Диагностика сети при помощи MTR
MTR — программа, которая сочетает функционал команд traceroute и ping в одном инструменте. MTR проверяет соединение между локальной системой и указанным узлом (IP или доменом). Программа отправляет запрос к узлу, как команда ping, и показывает маршрут пакета, как traceroute.
1. Скачайте дистрибутив WinMTR.
2. Распакуйте архив и запустите программу от имени администратора.
3. Нажмите Options, в настройках отключите галочку Resolve names. Нажмите OK:
4. В поле «Host» введите ваше доменное имя или IP-адрес. Нажмите Start. Когда число отправленных пакетов (колонка «Sent») будет более 200, нажмите Stop:
5. Нажмите Export TEXT и сохраните результат работы программы:
На Linux утилита MTR установлена по умолчанию.
- Запустите терминал. Для этого в поисковой строке введите слово «Терминал» или нажмите комбинацию клавиш Ctrl+Alt+T.
- Если утилита MTR не установлена, введите команды:
для Ubuntu/Debian:
для CentOS:
3. Введите команду:
Где 100.101.100.101 — IP-адрес вашего сайта.
4. Дождитесь окончания выполнения запроса. В окне терминала вы увидите результат работы утилиты MTR:
Как проверить журнал событий SSH службы
События SSH можно разделить на события:
- запуска и остановки этой службы
- события, связанные с подключением пользователей
Просмотреть логи SSH можно различными способами, один из вариантов (помните, что в некоторых системах служба называется ssh.service, без буквы d):
journalctl -u sshd.service
Например, для вывода последних 100 записей:
journalctl -u sshd.service | tail -n 100
Также можно просмотреть события SSH с помощью:
journalctl -u "sshd@*"
или с:
journalctl /usr/bin/sshd
Универсальная команда в независимости от имени службы:
journalctl -u "ssh*"
Для вывода событий, связанных с подключением пользователей, другой информации, в том числе отладочной (зависит от настройки уровня подробности сообщений), можно посмотреть следующим образом:
journalctl | grep -i ssh
Управление службами
Основополагающая цель системы инициализации заключается в инициализации компонентов, которые должны запускаться после загрузки ядра Linux (традиционно называются компоненты пользовательского пространства). Система инициализации также используется для управления службами и демонами для сервера и в любой момент времени работы системы. С учетом этого мы начнем с нескольких базовых операций по управлению службами.
В целью большинства действий являются «модули», являющиеся ресурсами, которыми знает, как управлять. Модули распределяются по категориям по типу ресурса, который они представляют, и определяются файлами, известными как файлы модулей. Тип каждого модуля можно вывести из суффикса в конце файла.
Для задач по управлению службами целевым модулем будут модули службы, которые имеют файлы модулей с суффиксом . Однако для большинства команд по управлению службами вы можете не использовать суффикс , поскольку достаточно умна, чтобы знать, что вы, возможно, хотите работать со службой при использовании команд по управлению службами.
Запуск и остановка служб
Как мы уже упомянули выше, будет искать файлы для команд управления службами, так что команду можно легко ввести следующим образом:
Хотя вы можете использовать вышеуказанный формат для общего администрирования, для ясности мы будем использовать суффикс для остальных команд, чтобы предельно четко выражать цель, над которой мы работаем.
Чтобы остановить работающую в данный момент службу, можно использовать команду :
Перезапуск и перезагрузка
Чтобы перезапустить работающую службу, можно использовать команду :
Если данное приложение может перезагрузить файлы конфигурации (без перезапуска), вы можете выдать команду для инициализации этого процесса:
Если вы не уверены, есть ли у службы функция перезагрузки своей конфигурации, можно использовать команду . Это перезагрузит необходимую конфигурацию при наличии. В противном случае будет перезагружена служба для выбора новой конфигурации:
Включение и отключение служб
Указанные выше команды полезны для запуска или остановки служб во время текущего сеанса. Чтобы дать команду автоматически запускать службы при загрузке, их необходимо включить.
Для запуска службы во время загрузки используйте команду :
При этом будет создана символическая ссылка из системной копии служебного файла (обычно в или ) в месте на диске, где ищет файлы для автозапуска (обычно ; что такое цель, мы рассмотрим далее в этом руководстве).
Чтобы отключить автоматический запуск службы, можно ввести следующее:
При этом будет удалена символическая ссылка, что укажет на то, что служба не должна запускаться автоматически.
Помните, что включение службы не запустит ее в текущем сеансе. Если вы хотите запустить службу и включить ее при загрузке, необходимо дать обе команды, и .
Проверка статуса служб
Чтобы проверить статус службы в вашей системе, можно использовать команду :
При этом вы получите статус службы, иерархию контрольных групп и первые несколько строк журнала.
Например, при проверке статуса сервера Nginx вы можете видеть следующий вывод:
Это дает вам хороший обзор текущего статуса приложения и уведомляет о наличии каких-либо проблем или необходимости выполнения каких-либо действий.
Также есть методы для проверки определенных статусов. Например, чтобы проверить, активен ли (работает ли) модуль в данный момент, можно использовать команду :
Это вернет текущий статус модуля, который обычно или . Код выхода будет «0», если он активен, и результат будет проще парсить в скрипты оболочки.
Чтобы увидеть, включен ли модуль, можно использовать команду :
Это выведет информацию о том, что служба или , и снова установит код выхода на «0» или «1» в зависимости от вопроса команды.
Третья проверка заключается в проверке того, находится ли модуль в состоянии сбоя. Это означает, что была проблема, которая запустила данный модуль:
Это вернет , если он работает должным образом, или , если возникла ошибка. Если модуль был намеренно остановлен, может вернуться или . Статус выхода «0» означает, что произошел сбой, а статус выхода «1» указывает на какой-либо другой статус.
Понимание логирования
- Прямая запись: некоторые сервисы записывают информацию напрямую в лог-файлы, даже некоторые важные сервисы, такие как веб-сервер Apache и файловый сервер Samba.
- rsyslogd: rsyslogd — это усовершенствование сервиса syslogd, который занимается централизованным управлением лог-файлов. Syslogd существует уже давно.
- journald: с введением systemd также был представлен сервис логирования journald. Этот сервис тесно интегрирован с systemd, что позволяет администраторам читать подробную информацию из journald, одновременно отслеживая состояние сервиса с помощью команды systemctl status.
Xorg и systemd
Есть несколько способов запустить xorg в системных модулях. Ниже представлены два варианта: либо запустить новый пользовательский сеанс с процессом xorg, либо запустить xorg из пользовательской службы systemd.
Автоматический логин в Xorg без экранного менеджера
The factual accuracy of this article or section is disputed.
Эта опция запускает системный блок, который запускает сеанс пользователя с сервером xorg, а затем запускает обычный для запуска оконного менеджера и т.д.
Вам необходим установленный AUR. Настройте свой xinitrc, как указано в разделе .
Сеанс будет использовать собственный dbus демон, но различные утилиты systemd будут автоматически подключаться к экземпляру . Наконец, enable службу для автоматического входа при загрузке.Сеанс пользователя полностью находится в области видимости systemd, и все в сеансе пользователя должно работать нормально.
Xorg как пользовательская служба systemd
Кроме того, Xorg можно запустить из службы пользователя systemd. Это хорошо, поскольку другие связанные с X юниты могут зависеть от xorg и т. д. Но с другой стороны, у этого есть некоторые недостатки, объясненные ниже.
обеспечивает интеграцию с systemd двумя способами:
К сожалению, чтобы иметь возможность запускать xorg в непривилегированном режиме, он должен запускаться внутри сеанса. Итак, в данный момент недостаток запуска xorg в качестве пользовательской службы заключается в том, что он должен запускаться с привилегиями суперпользователя (как до 1.16) и не может использовать преимущества непривилегированного режима, представленного в 1.16.
Вот как запустить xorg из пользовательского сервиса:
1. Заставить xorg работать с правами суперпользователя и для любого пользователя путем редактирования
/etc/X11/Xwrapper.config
allowed_users=anybody needs_root_rights=yes
2. Добавить следующие юниты в
~/.config/systemd/user/xorg@.socket
Description=Socket for xorg at display %i ListenStream=/tmp/.X11-unix/X%i
~/.config/systemd/user/xorg@.service
Description=Xorg server at display %i
Requires=xorg@%i.socket
After=xorg@%i.socket
Type=simple
SuccessExitStatus=0 1
ExecStart=/usr/bin/Xorg :%i -nolisten tcp -noreset -verbose 2 "vt${XDG_VTNR}"
где } — виртуальный терминал, на котором будет запущен xorg, либо прописанный в сервисном модуле, либо установленный в среде systemd с помощью
$ systemctl --user set-environment XDG_VTNR=1
Примечание: xorg должен быть запущен на том же виртуальном терминале, где пользователь вошел в систему. В противном случае logind будет считать сеанс неактивным.
3. Обязательно настройте переменную среды , как описано .
4. Затем, чтобы активировать сокет для xorg на дисплее 0 и tty 2, следует выполнить:
$ systemctl --user set-environment XDG_VTNR=2 # Так что xorg@.service знает, какой vt использовать $ systemctl --user start xorg@0.socket # начинает слушать на сокете для дисплея 0
Теперь запуск любого X приложения автоматически запустит xorg на виртуальном терминале 2.
Переменная среды может быть установлена в среде systemd из , а затем можно запустить любое приложение X, включая диспетчер окон, как системный модуль, зависящий от .
Компоненты systemd
Некоторые (не все) составные части systemd:
- systemd-boot — простой для UEFI;
- systemd-firstboot — инициализация системных настроек при первой загрузке;
- systemd-homed — переносимые аккаунты пользователей;
- systemd-networkd — управление сетевыми настройками;
- systemd-nspawn — приложение для контейнеризации процессов;
- systemd-resolved — разрешение сетевых имён;
- — создание системных пользователей/групп и добавление пользователей в группы при установке пакетов и загрузке системы;
- systemd-timesyncd — синхронизация системных часов по сети;
- systemd/Журнал — системные логи;
- systemd/Таймеры — таймеры для управления событиями и службами, альтернатива cron.
systemd.mount — монтирование
systemd полностью отвечает за монтирование разделов и файловых систем, описанных в файле . преобразует записи из в юниты systemd; это выполняется при каждой загрузке системы, а также при перезагрузке конфигурации системного менеджера.
systemd расширяет возможности fstab и предлагает дополнительные опции монтирования. Они могут влиять на зависимости юнита монтирования: например, могут гарантировать, что монтирование выполняется только после подключения к сети или после монтирования другого раздела. Полный список опций монтирования systemd (обычно они имеют префикс ) описан в .
Примером этих опций может быть т.н. автомонтирование (здесь имеется в виду не автоматическое монтирование во время загрузки, а монтирование при появлении запроса от устройства). Подробнее смотрите .
Автомонтирование GPT-раздела
Требования:
- Корневой раздел должен быть на одном физическом диске с системным разделом EFI. Автомонтируемые разделы должны быть на одном физическом диске с корневым разделом. Очевидно, монтируемые разделы должны оказаться на одном диске и с ESP.
Совет: Автомонтирование разделов отключается изменением его или установкой атрибута раздела «do not mount» (бит 63), см. .
/var
Для автомонтирования раздела его PARTUUID должен совпадать с хэш-суммой SHA256 HMAC, вычисленной на основании UUID типа раздела. В качестве ключа хэша используется machine ID. Необходимый PARTUUID можно получить командой:
$ systemd-id128 -u --app-specific=4d21b016-b534-45c2-a9fb-5c16e091fd2d machine-id
Примечание: Утилита считывает machine ID из файла , поэтому вычислить PARTUUID до установки системы невозможно.
systemd-sysvcompat
Пакет (зависимость пакета ) содержит традиционный бинарный файл init. В системах под управлением systemd — символическая ссылка на исполняемый файл .
Кроме того, в этом пакете находятся 4 команды SysVinit — , , и . Это символические ссылки на , и их работа обусловлена логикой systemd. Подробнее см. .
systemd-tmpfiles — временные файлы
Утилита systemd-tmpfiles создает, удаляет и очищает непостоянные и временные файлы и каталоги. Она читает конфигурационные файлы из и , чтобы понять, что необходимо делать. Конфигурационные файлы в первом каталоге имеют приоритет над теми, что расположены во втором.
Конфигурационные файлы обычно предоставляются вместе с файлами служб и имеют названия вида . Например, демон Samba предполагает, что существует каталог с корректными правами доступа. Поэтому пакет поставляется в следующей конфигурации:
/usr/lib/tmpfiles.d/samba.conf
D /run/samba 0755 root root
Конфигурационные файлы также могут использоваться для записи значений при старте системы. Например, если вы используете для отключения пробуждения от устройств USB при помощи , вместо этого вы можете использовать следующий tmpfile:
/etc/tmpfiles.d/disable-usb-wake.conf
# Path Mode UID GID Age Argument w /proc/acpi/wakeup - - - - USBE
Подробнее смотрите и .
Примечание: Этот способ может не сработать для установки опций в , поскольку служба systemd-tmpfiles-setup может запуститься до того, как будут загружены соответствующие модули устройств. В этом случае при помощи команды вы можете проверить, имеет ли модуль параметр для установки необходимой опции, и установить эту опцию в в каталоге . В противном случае для установки верных атрибутов сразу при появлении устройства придется написать .
Навигация и управление файловой системой
Команды, необходимые для перемещения и ориентирования в файловой системе сервера. А еще для перемещения, копирования и удаления файлов. В общем, все, что вы делали бы в файловом менеджере, но через терминал.
cd — отправляет вас в любую папку на выбор. Синтаксис: cd путь до нужной директории. Если хочется на рабочий стол, то пишем: cd ~/Desktop. Вернуться в предыдущую папку? cd-. Перепрыгнуть в home? Просто вводим: cd без аргументов.
ls — отображает директории и файлы вокруг вас. То есть в той папке, где вы находитесь на текущий момент. Но чтобы ею пользоваться, необязательно переходить в конкретную директорию. Ее можно указать заранее. Вот так:
ls ~/Desktop/papka-testovaya
pwd — укажет путь до папки тем, кто заблудился. Если вы находитесь в папке Документы, то вывод pwd будет выглядеть вот так /home/имя пользователя/Documents. И так для любого каталога, в котором вы окажетесь.
file — покажет, что собой представляет файл. Фишка утилиты в том, что она демонстрирует разную информацию для разных типов файлов. К примеру, может дать подробные EXIF-данные для фотографий, включая разрешение и битность изображения.
mv — изначально использовалась для того, чтобы перемещать файлы из одного места в другое. mv ~/Desktop/timeweb.html ~/Documents переносит HTML-документ Timeweb с рабочего стола в документы. Но пользователи приноровились использовать mv для смены имени файлов. mv ~/Desktop/timeweb.html timeweb-2.html оставляет документ на месте, но меняет его название.
cp — создает копию выбранного файла в другом каталоге. cp ~/Documents/timeweb-file.txt /home/Webmaster/Desktop копирует документ с названием timeweb-file.txt на рабочий стол того же пользователя.
dd — управляет разделами. С ее помощью можно делать копии разделов: dd if=/dev/sda of=/dev/sdb. Можно перемещать разделы. Удалять их без возможности восстановления: dd if=/dev/zero of=/dev/sdX (в качестве раздела для «уничтожения» тут указана флешка). Копирование разделов подразумевает их запись на сторонние носители. Например, запись iso-образов на внешние накопители: dd if=~/Desktop/fedora-14.6.iso of=/dev/sdX bs=4M. if здесь — это путь к образу, а of — путь к смонтированному разделу (флешке).
rm — удаляет папки и все, что сможет в них найти. «Уничтожает» все субдиректории, документы, картинки, медиа. Вообще все, без возможности восстановления. Синтаксис:
rm путь до каталога, который надо вычистить вместе со всеми «внутренностями»
mkdir — создает новую папку. Синтаксис: mkdir путь_до каталога,_где_нужно_создать_новую_директорию название_для_этой директории. Если надо сделать на рабочем столе папку Timeweb, то пишем:
mkdir ~/Desktop/Timeweb
rmdir — удаляет директории. Не имеет права трогать их содержимое, поэтому отзовется ошибкой, если в удаляемой папке найдутся еще какие-то элементы. Перед использованием rmdir объект надо очистить.
wget — скачивает файл из переданной ссылки. Больше ничего не умеет. Простой текстовый менеджер загрузок. Работает так – если мы хотим загрузить скриншот панели управления Timeweb с официального сайта, то введем в терминал: wget https://timeweb.com/upload/resize_cache/iblock/b56/400_400_2/xscreen_3.jpg.pagespeed.ic.O4a5jdlo5A.jpg
zip — архивирует один или несколько файлов один файл в формате .zip. Синтаксис: zip название архива.zip путь до файла, который надо упаковать. К примеру:
zip noviy-archive.zip /home/me/soderzhimoe-archiva.txt
unzip — вытаскивает содержимое архива наружу. Работает по тому же принципу: сначала команда, потом путь до архива, который надо распаковать. Еще можно добавить опцию -d, чтобы удалить файлы из архива по завершении распаковки.
find — ищет файлы и папки по всей файловой системе. Умеет находить их по названию и по типу, но это зависит от выставленных опций. find -type d -name Timeweb будет искать только директории с именем Timeweb.
mount — монтирует образ или раздел диска. Синтаксис:
mount путь до раздела, что нужно смонтировать
unmount — «демонтирует» образ или указанный раздел. Синтаксис:
unmount путь до раздела, что нужно отмонтировать
Просмотр логов ESXI через shell оболочку
Теперь когда мы с вами знаем, о месторасположении и назначении каждого из журналов ESXI хоста, мы можем рассмотреть методы их просмотра. Первым будет самый классический, редко используемый, через Shell оболочку. Для выполнения данного метода необходимо либо физическое присутствие перед монитором сервера, либо же обладать портом портом управления, который позволяет, через Java или HTML консоль видеть изображение с сервера, например ILO, IPMI, IMM или IDRAC.
Логинимся на сервер через DCUI интерфейс и находим пункт меню «View System Logs». У вас будут шесть пунктов:
- Syslog
- VmKernel
- Config
- Management Agent (hostd)
- VirtualCenter Agent (vpxa)
- Vmware ESXI Observation log (vobd)
Для примера я выберу цифру 1 и посмотрю системные логи. Перед вами будет окно с логами ESXI, для перемещения вы можете использовать стрелки вниз или вверх, если нужно быстрее, то клавиши Page Up или Page Down.
Полный список команд можно получить нажав клавишу «H». Выход в меню DCUI осуществляется через кнопку Q. Кстати если вы нажмете сочетание клавиш Alt+F12, то вы перейдете в лог vmkernel. Выйти из него Alt+F2. Alt+F1 даст вам доступ в shell консоли, где вы легко можете перемещаться по каталога гипервизора.
Простые команды Hive
Давайте начнем с основ, прежде чем перейти к чему-то более сложному. Вот некоторые общие команды Hive и Linux, которые могут вам понадобиться:
- agent-screen. Используйте его, чтобы увидеть клиентский агент Hive. Когда вы решите выйти, нажмите Ctrl + A, D.
- firstrun -f. Это поможет вам в случае, если вам снова понадобится идентификатор и пароль установки.
- mc. Это файловый менеджер, подобный Norton Commander, но для Linux.
- selfupgrade. Эта команда обновит систему. Вместо того, чтобы использовать его, вы также можете нажать кнопку в Интернете — результат будет таким же.
- sreboot. Если вы используете эту команду, все сразу перезагрузится.
- sreboot shutdown. Вам нужно немедленное отключение? Тогда эта команда именно то, что вы ищете.
Майнеры
В свою очередь эти команды помогут вам разобраться с майнерами:
- miner. Попробуйте эту команду, чтобы увидеть экран запущенного майнера. Когда вы решите выйти, нажмите Ctrl + A, D.
- miner start, miner stop. Здесь все просто, эти команды запускают и останавливают текущий настроенный майнер.
- miner log, miner config. Очевидно, что эти команды позволяют проверить конфигурацию журнала и майнера.
Системные логи
Вот две хитрости при работе с системным журналом:
- dmesg. Этот покажет вам системные сообщения и журнал загрузки.
- tail -n 100 /var/log/syslog. Хотите увидеть последние 100 строк из системного журнала? Попробуйте эту команду.
Сеть
И, очевидно, вот несколько сетевых «лайфхаков», о которых вы должны знать:
- ifconfig. Используйте его, чтобы увидеть сетевые интерфейсы.
- iwconfig. Ищете беспроводные адаптеры? Эта команда покажет их вам.
