Можно ли вместо dnf upgrade использовать dnf update?

Зависит от релиза. В актуальных поддерживаемых RHEL-подобных системах dnf update обычно является поддерживаемым эквивалентом или псевдонимом dnf upgrade. Однако это нужно подтвердить по документации целевой ОС и не переносить это правило на CentOS 7. Для автоматизации используйте интерфейс, указанный документацией конкретного релиза.

Нужно ли перезагружать сервер после обновления ядра Linux?

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

Можно ли обновить CentOS 7, просто сменив репозитории?

Нет. Поддержка CentOS Linux 7 завершилась 30 июня 2024 года, и смена зеркал или репозиториев не возвращает поддержку, исправления и совместимость. Для такого сервера нужен отдельный сценарий: зафиксировать состав системы и требования приложения, подготовить восстановление, затем выбрать документированную миграцию или чистую установку поддерживаемой ОС.

Можно ли откатить обновление Linux через dnf history?

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

Что делать, если новое ядро Linux не загружается?

До плановой перезагрузки нужно убедиться, что доступна удалённая или физическая консоль, а ранее работавшее ядро не удалено и может быть выбрано в GRUB или другом используемом загрузчике. Если новое ядро не стартует, при доступности старого ядра часто можно выбрать его в меню загрузчика и вернуться к рабочей загрузке для дальнейшего анализа. Загрузка со старым ядром — не полный откат обновления. Пакетная транзакция уже могла обновить библиотеки, конфигурационные файлы и прикладные компоненты, поэтому работоспособность служб нужно проверять отдельно. Если проблема связана с загрузчиком, initramfs, переходом в emergency mode или Kernel panic, требуется отдельная диагностика причины; выбор прежнего ядра сам по себе не исправляет такие состояния.

Достаточно ли одного SSH-сеанса для обновления сервера?

Нет. Перед обновлением нужен отдельный способ доступа: второе SSH-подключение, удалённая консоль или физическая консоль, а также проверенные учётные данные и возможность увидеть загрузчик. Единственный активный SSH-сеанс может не помочь, если обновление затронет сеть, sshd или ядро и сервер станет недоступен после перезагрузки.

Обновление Linux-сервера: пакеты, ядро, перезагрузка и откат

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

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

Не смешивайте обычное обновление пакетов со сменой основного релиза дистрибутива.

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

Не обновляйте основной релиз «заодно»

Переход, например, между основными выпусками Debian, Ubuntu или RHEL-подобной ОС не является обычным upgrade. Для него нужны отдельные инструкции поставщика, проверка приложений и отдельный план простоя. Для CentOS переход рассматривается в статье «Переход с CentOS на Rocky Linux или AlmaLinux».

Что проверить до обновления Linux-сервера

Подготовьте сервер и окно обслуживания

Выполняйте команды с административными правами: через sudo либо из учётной записи суперпользователя. Сохраняйте результаты в заявке на изменения или в рабочем журнале.

1
Зафиксируйте ОС, ядро и архитектуру
Файл /etc/os-release содержит идентификацию дистрибутива Linux, а uname -r показывает именно запущенное ядро. Эти данные нужны для выбора правильной ветки обновления и проверки результата после перезагрузки.
2
Проверьте статус поддержки релиза
Сопоставьте значения ID, VERSION_ID и PRETTY_NAME из /etc/os-release с официальными сведениями поставщика: выпуски Debian, цикл выпусков Ubuntu, жизненный цикл RHEL, версии Rocky Linux, выпуски AlmaLinux или статус CentOS Linux. Не используйте репозитории другого выпуска, другого семейства или случайные архивные зеркала как замену поддержке.
3
Определите критичные функции
Составьте короткий чек-лист служб и прикладных функций: база данных, веб-приложение, очередь, мониторинг, резервное копирование, сетевые интеграции. Укажите, кто подтверждает их работоспособность и какие действия снаружи сервера нужно проверить после работ.
4
Проверьте доступ и способ возврата
До начала работ проверьте отдельное подключение по SSH, доступ к удалённой консоли или физической консоли, учётные данные и возможность увидеть загрузчик. Одного активного SSH-сеанса недостаточно: после обновления сети, ядра или sshd он может не помочь восстановить доступ.
5
Проверьте место и резервное восстановление
Проверьте свободное место на корневой и загрузочной файловых системах, а также там, где размещается кэш пакетов. Убедитесь, что существует актуальная резервная копия либо снимок, известен способ восстановления и учтены данные, которые изменятся во время окна.
6
Проверьте репозитории и автоматические задачи
Зафиксируйте подключённые репозитории пакетов, локальные пакеты и сторонние агенты. На время работ оцените фоновые задания и автоматические обновления, чтобы они не запустили параллельную пакетную транзакцию.

Показывает идентификацию ОС, версию запущенного ядра, архитектуру и свободное место. Сохраните вывод до обновления.

cat /etc/os-release && uname -r && uname -m && df -h

Проверьте источники пакетов до транзакции

Смешение репозиториев разных выпусков или дистрибутивов может создать конфликтующие зависимости и неподдерживаемую конфигурацию. В RHEL доступ к обновлениям зависит от действующей подписки, регистрации и политики управления контентом через Red Hat Subscription Management. Сторонние репозитории и пакеты проверяйте по документации их поставщиков.

Debian и Ubuntu Server: просмотр и установка обновлений через APT

В Debian и Ubuntu применяется APT. Его команды не переносят в RPM-системы. Подробные операции с пакетами, удержаниями и кэшем описаны отдельно в статье «APT в Ubuntu и Debian: установка, обновление, удаление и очистка пакетов».

Обновите Debian Server или Ubuntu Server в пределах релиза

1
Обновите индекс пакетов
apt update загружает актуальный индекс пакетов из настроенных репозиториев, но не устанавливает обновления.
2
Посмотрите доступные обновления и симулируйте транзакцию
После apt update запросите список обновляемых пакетов и выполните симуляцию. Прочитайте, какие пакеты будут обновлены, установлены или удалены. Если в выводе есть неожиданные удаления системных или прикладных компонентов, остановитесь и проверьте источники пакетов и зависимости.
3
Выберите режим обновления
apt upgrade обновляет пакеты без удаления установленных пакетов; если для изменения требуется удаление, такой пакет может быть оставлен без обновления. apt full-upgrade при необходимости может удалить пакеты, чтобы разрешить зависимости. Выбор подтверждают только после просмотра рассчитанной транзакции.
4
Запустите выбранную транзакцию
Повторите проверенную команду без режима симуляции, прочитайте запрос APT перед подтверждением и следите за сообщениями о конфигурационных файлах. Не прерывайте работающий менеджер пакетов отключением питания или закрытием управляемой сессии.

Обновляет метаданные APT. Эта команда сама по себе не устанавливает обновления.

sudo apt update

Показывает пакеты, для которых после обновления индекса доступны новые версии.

apt list --upgradable

Симулирует обычное обновление. Ключ `-s` означает simulate: изменения в системе не применяются.

sudo apt -s upgrade

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

sudo apt -s full-upgrade

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

sudo apt upgrade

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

sudo apt full-upgrade

Что не показывает симуляция APT

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

RHEL, Rocky Linux, AlmaLinux и CentOS Stream: обновление через DNF

В поддерживаемых выпусках RHEL, Rocky Linux, AlmaLinux и CentOS Stream используется DNF. Команды DNF относятся к RPM-экосистеме и не заменяют APT. Команда YUM в части выпусков может быть совместимым интерфейсом, но её наличие и поведение нужно сверять с документацией конкретного релиза; для автоматизации используйте интерфейс, указанный документацией целевой ОС.

Обновите поддерживаемую RHEL-подобную систему

1
Проверьте доступность обновлений
Команда dnf check-update проверяет подключённые репозитории и выводит доступные обновления. Она не изменяет установленные пакеты. Код возврата при найденных обновлениях может отличаться от кода «нет обновлений», поэтому учитывайте это в скриптах по документации вашей версии DNF.
2
Рассчитайте транзакцию без применения
Запустите dnf upgrade --assumeno. DNF рассчитает обновления, новые установки и удаления, выведет сводку, а затем откажется от выполнения из-за ключа --assumeno. Проверьте каждое неожиданное изменение.
3
Установите согласованные обновления
Запустите dnf upgrade и снова прочитайте итог транзакции перед подтверждением. В документации актуальных RHEL-подобных выпусков dnf update обычно указан как поддерживаемый эквивалент или псевдоним dnf upgrade, но это нужно подтверждать для конкретного релиза и не переносить на CentOS 7.
4
Зафиксируйте идентификатор транзакции
После завершения сохраните вывод dnf history: он нужен для анализа и возможной попытки отмены, но сам по себе не создаёт гарантированный откат всей системы.

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

sudo dnf check-update

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

sudo dnf upgrade --assumeno

Устанавливает согласованные обновления. Перед подтверждением прочитайте сводку транзакции.

sudo dnf upgrade

Показывает сохранённую историю транзакций DNF и их идентификаторы.

sudo dnf history

Ограничения просмотра DNF-транзакции

Как и APT, DNF показывает рассчитанные пакеты и зависимости пакетов, но не может гарантированно предсказать все действия скриптов пакетов, изменения конфигурации и влияние обновления на прикладную нагрузку. Release notes ОС, документация сторонних RPM-пакетов, драйверов, агентов и приложения проверяются отдельно.

CentOS 7 после EOL: не подменяйте миграцию сменой репозиториев

Поддержка CentOS Linux 7 завершилась 30 июня 2024 года. Это EOL: CentOS 7 нельзя включать в обычную процедуру обновления поддерживаемых DNF-систем и нельзя считать смену зеркал или репозиториев универсальным способом вернуть поддержку, исправления и совместимость.

Для CentOS 7 нужен отдельный сценарий

Сначала зафиксируйте состав системы, требования приложения, окно простоя и способ восстановления. Затем выберите документированную миграцию либо чистую установку поддерживаемой ОС после проверки совместимости. Статус CentOS и варианты решений разобраны в статье «CentOS Stream и CentOS 7: статус поддержки, различия и выбор сценария».

Когда нужна перезагрузка после обновления Linux

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

Если в рассчитанной или выполненной транзакции есть пакеты ядра, планируйте перезагрузку и проверку загрузки.
В Ubuntu штатный механизм, описанный в документации Ubuntu Server по автоматическим обновлениям, может создавать файл /run/reboot-required — путь /var/run/reboot-required указывает на тот же runtime-каталог в современных системах. Наличие файла означает рекомендацию перезагрузить систему. Его отсутствие не доказывает, что перезагрузка не нужна для любого набора пакетов.
В RHEL-подобных системах при наличии документированного в конкретном выпуске плагина может применяться dnf needs-restarting -r; назначение параметра и коды возврата приведены в документации DNF Plugins Core. Доступность пакета и применимость этой документации сверяйте с руководством своего дистрибутива и релиза.
Для Debian и других систем без подходящего штатного индикатора решение принимают по составу обновлений, примечаниям к выпуску и документации поставщика ОС или приложения.

Пример проверки индикатора Ubuntu. Используйте только в системах, где этот механизм предусмотрен поставщиком.

test -e /run/reboot-required && cat /run/reboot-required

Пример для RHEL-подобной системы, где установлена и документирована соответствующая утилита DNF. Не предполагает универсальную доступность во всех релизах.

sudo dnf needs-restarting -r

Перезагрузка и проверка нового ядра

Перезагрузите сервер в окно работ

1
Проверьте возможность возврата до перезагрузки
Убедитесь, что доступна консоль и, если используются несколько ядер, ранее работавшее ядро не удалено и может быть выбрано в GRUB или другом применяемом загрузчике. Число сохраняемых ядер, вариант меню и выбор записи зависят от дистрибутива, релиза, загрузчика и локальной конфигурации.
2
Зафиксируйте ожидаемую версию
До перезагрузки сохраните список установленных пакетов ядра. Не путайте этот список с uname -r: последняя команда до перезагрузки показывает старое, всё ещё запущенное ядро.
3
Выполните штатную перезагрузку
В системах с systemd используйте systemctl reboot. Перед командой завершите согласованные операции приложения и оставьте работающий канал консоли.
4
Подтвердите загрузку
После возврата сервера проверьте, что новый сеанс доступен, система загрузилась штатно, а uname -r соответствует ожидаемому установленному ядру.

Показывает версию ядра, которое действительно запущено сейчас.

uname -r

Пример для Debian и Ubuntu: показывает известные dpkg пакеты образов ядра и их состояния. Строки со статусом `ii` соответствуют установленным пакетам; сопоставьте их версии с `uname -r`.

dpkg -l 'linux-image*'

Пример для RHEL, Rocky Linux, AlmaLinux и CentOS Stream: показывает установленные RPM-пакеты ядра.

rpm -q kernel

Штатная перезагрузка в systemd-системе. Выполняйте её только после проверки консольного доступа и согласования простоя.

sudo systemctl reboot

Если новый kernel не загружается

При доступности прежнего ядра часто достаточно выбрать его в загрузчике и загрузиться для дальнейшего анализа. Это не отменяет все изменения транзакции: обновлённые библиотеки, конфигурации и прикладные пакеты останутся изменёнными. Ошибки загрузчика, initramfs, emergency mode и Kernel panic требуют отдельной диагностики: «Linux-сервер не загружается: GRUB, emergency mode, initramfs и kernel panic».

План отката обновления Linux

Откат пакетной транзакции, возврат ядра и восстановление данных — разные операции.

Сценарий	Когда может помочь	Ограничения
Отмена до подтверждения	Транзакция рассчитана, но ещё не подтверждена	После начала установки это уже не способ вернуть изменённые файлы
Загрузка с прежним ядром	Новое ядро не работает, а прежнее сохранено и доступно в загрузчике	Не возвращает другие обновлённые пакеты, конфигурации и данные приложения
`dnf history undo` или `dnf history rollback`	Для некоторых завершённых DNF-транзакций есть история и требуемые версии пакетов доступны	Результат зависит от состава операции, истории и репозиториев; это не гарантирует возврат всей системы или данных приложения
Возврат снимка	Снимок создан до изменений и технология хранения поддерживает возврат в данной конфигурации	Может откатить данные, изменившиеся после снимка; требуется план обращения с этими данными
Восстановление из резервной копии	Нужен возврат системы, конфигурации или данных после серьёзного сбоя	Скорость и полнота зависят от состава копии, проверенной процедуры восстановления и времени создания

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

Показывает детали конкретной DNF-транзакции перед оценкой возможности её отмены.

sudo dnf history info <ID_ТРАНЗАКЦИИ>

Пример попытки отмены одной DNF-транзакции. Запускайте только после просмотра рассчитанных изменений и проверки доступности нужных версий пакетов.

sudo dnf history undo <ID_ТРАНЗАКЦИИ>

DNF history не заменяет резервную копию

dnf history undo и dnf history rollback зависят от сохранённой истории, доступности старых пакетов и состава транзакций. Они не обязаны восстановить вручную изменённые файлы, состояние внешних систем, базы данных или пользовательские данные. Для APT не следует предполагать наличие равнозначного универсального механизма отмены транзакции.

Что проверить после обновления и перезагрузки

Закройте окно работ только после проверки результата

1
Подтвердите идентификацию ОС и ядра
Снова сохраните /etc/os-release и uname -r. Версия ОС может не измениться при обновлении в пределах релиза, но версия запущенного ядра после плановой перезагрузки должна соответствовать ожидаемой.
2
Проверьте успешную текущую загрузку
Убедитесь, что сервер доступен по согласованным каналам, сеть работает в нужном объёме, а загрузка не завершилась аварийным режимом. Проверьте релевантные ошибки именно текущей загрузки.
3
Проверьте необходимые службы
Проверьте состояние только тех systemd units, которые входят в согласованный чек-лист. Статус пакета или отсутствие ошибки установки не доказывают, что служба и приложение работают.
4
Проверьте прикладные функции
Выполните заранее определённые проверки: подключение клиента, ответ API, обработку задания, подключение к базе данных, работу мониторинга или иную релевантную функцию. Проверка выбирается по роли сервера.
5
Зафиксируйте результат
Сохраните время работ, версии ОС и ядра, идентификатор DNF-транзакции при его наличии, перечень проверок, найденные ошибки и принятые действия. Это упрощает анализ следующего обновления.

Фиксирует версию ОС и фактически запущенное ядро после работ.

cat /etc/os-release && uname -r

Показывает units в состоянии failed. Сопоставляйте результат с исходным состоянием и списком критичных служб.

systemctl --failed

Показывает предупреждения и сообщения более высоких приоритетов текущей загрузки через [journalctl](/baza-znaniy/glossariy/journalctl). Анализируйте только сообщения, относящиеся к работам и роли сервера.

journalctl -b -p warning

Для проверки и управления службами используйте systemctl по именам нужных units. Если служба не запустилась, не ограничивайтесь повторным перезапуском: сохраните её состояние и сообщения журнала, затем перейдите к статье «Служба systemd не запускается: диагностика ошибок и восстановление».

Термины в статье

Дистрибутив Linux: Дистрибутив Linux — готовая операционная система на базе ядра Linux, включающая набор программ, репозитории, пакетный менеджер и правила обновления и сопровождения.
Зависимость пакета: Зависимость пакета — требование пакета к другому пакету или его версии, без выполнения которого установка, запуск либо корректное обновление ПО невозможны или ограничены.
Индекс пакетов: Индекс пакетов — набор метаданных репозитория, содержащий сведения о версиях, зависимостях, архитектурах и расположении доступных пакетов.
Кэш пакетов: Кэш пакетов — локально сохранённые менеджером пакетов архивы пакетов и, в зависимости от реализации, метаданные репозиториев для повторного использования.
Менеджер пакетов: Менеджер пакетов — средство установки, обновления, удаления и учёта программных пакетов; высокоуровневые менеджеры также работают с репозиториями и разрешают зависимости.
Пакетная транзакция: Пакетная транзакция — согласованный набор действий по установке, обновлению, удалению и настройке пакетов, формируемый менеджером пакетов в рамках одной команды или задания.
Репозиторий пакетов: Репозиторий пакетов — структурированный источник пакетов и метаданных, из которого менеджер пакетов получает версии ПО, зависимости, обновления и информацию о подписях.
Системная служба: Системная служба — программный компонент, которым ОС управляет как логической единицей для фонового выполнения задач или предоставления функций программам и пользователям.
Снимок состояния: Зафиксированное гипервизором состояние поддерживаемых виртуальных дисков и конфигурации ВМ на определённый момент, иногда также памяти, к которому можно выполнить откат.
Удержание пакета: Удержание пакета — состояние пакета, запрещающее менеджеру пакетов автоматически устанавливать, обновлять, удалять или менять его версию.
Ядро Linux: Ядро Linux — центральный компонент ОС, управляющий аппаратными ресурсами и предоставляющий системные интерфейсы; оно не включает пользовательские утилиты и менеджер пакетов.
AlmaLinux: AlmaLinux — корпоративный дистрибутив Linux, поддерживаемый сообществом и AlmaLinux OS Foundation, ориентированный на совместимость с интерфейсами и экосистемой RHEL.
APT: APT — система управления пакетами в Debian-подобных Linux, которая получает пакеты из репозиториев, разрешает зависимости и передаёт установку низкоуровневому менеджеру dpkg.
CentOS Linux: CentOS Linux — прекращённый свободно доступный дистрибутив Linux, создававшийся из исходных пакетов RHEL и ориентированный на бинарную совместимость с соответствующим выпуском RHEL.
CentOS Stream: CentOS Stream — дистрибутив Linux с непрерывной поставкой пакетов, формирующих следующую минорную версию Red Hat Enterprise Linux; он расположен между Fedora и RHEL.
Debian: Debian — универсальный дистрибутив Linux с пакетами DEB и системой APT, известный консервативной веткой Stable и разделением репозиториев по веткам разработки.
DNF: DNF — менеджер пакетов для RPM-дистрибутивов, разрешающий зависимости и выполняющий операции с репозиториями; в современных системах он заменил классический YUM.
Emergency mode: Emergency mode — аварийный режим systemd с минимальным окружением и консолью администратора, без обычных служб и автоматического монтирования остальных локальных файловых систем.
EOL: EOL — установленная поставщиком дата или стадия завершения жизненного цикла версии ПО либо модели оборудования; её последствия определяются политикой поставщика.
GRUB: GRUB — загрузчик операционных систем, который после BIOS или UEFI выбирает пункт своего меню, передаёт ядру Linux параметры и обычно загружает initramfs.
initramfs: initramfs — временная корневая файловая система в памяти, разворачиваемая ядром Linux для загрузки модулей и подготовки хранилища перед монтированием постоянной корневой файловой системы.
journalctl: journalctl — консольная утилита чтения и фильтрации журнала systemd, выводящая сообщения по времени, юниту, загрузке системы, приоритету и другим полям.
Kernel panic: Kernel panic — неустранимая ошибка ядра операционной системы, при которой оно прекращает штатное выполнение, поскольку не может безопасно продолжать работу.
Red Hat Subscription Management: Red Hat Subscription Management — служба и набор средств Red Hat для регистрации RHEL-систем в организации и управления их доступом к репозиториям и контенту по её подпискам.
RHEL: RHEL — корпоративный дистрибутив Linux от Red Hat с фиксированными основными версиями, сертификационной экосистемой и моделью сопровождения, зависящей от подписки.
Rocky Linux: Rocky Linux — корпоративный дистрибутив Linux, создаваемый из исходных пакетов экосистемы RHEL и ориентированный на совместимость с RHEL без использования его товарных знаков.
SSH: SSH — криптографический сетевой протокол для удалённого доступа и передачи данных, аутентифицирующий стороны и защищающий сеанс от перехвата.
systemctl: systemctl — командная утилита управления systemd, которая запускает и останавливает юниты, показывает их состояние и настраивает автоматическую активацию.
systemd: systemd — система инициализации и менеджер служб Linux, управляющий службами и другими ресурсами как объектами unit, обычно описанными unit-файлами.
Ubuntu Server: Ubuntu Server — серверный вариант дистрибутива Ubuntu на базе Debian с APT и типовыми средствами автоматизации, доступный в виде установочных и готовых образов.
YUM: YUM — менеджер пакетов для RPM-дистрибутивов Linux, который устанавливает, обновляет и удаляет ПО, автоматически разрешая зависимости из репозиториев.