Команды ALT Linux, Astra Linux и РЕД ОС: практический справочник администратора

Linux-команды удобно запоминать по задаче: определить систему, найти пакет, проверить службу, выяснить причину сетевого отказа, посмотреть права и прочитать журнал. У ALT Linux, Astra Linux и РЕД ОС много общего на уровне ядра и стандартных утилит, но одинаковая команда установки не означает одинаковые пакеты или репозитории. ALT использует RPM вместе с APT-RPM, Astra — Debian-подобный пакетный стек, РЕД ОС — RPM и DNF. На защищённых установках к обычным Unix-правам добавляются отдельные механизмы контроля доступа.

Далее приведены команды, которые можно использовать как рабочий справочник. Перед изменением есть способ прочитать текущее состояние, после него — проверить результат. Команды с sudo предполагают установленный sudo и разрешённое действие; его наличие и политика не возникают автоматически из названия дистрибутива. Если администрирование организовано через отдельный root-вход, используйте принятый в компании порядок, а не выдавайте себе полные права ради примера. Варианты пакетного управления сверены для ALT с ветками p10/p11, Astra Linux Special Edition 1.7/1.8 и РЕД ОС 7.3/8 по документации производителей. Это область примеров, а не утверждение, что любой упомянутый выпуск является самым новым или имеет одинаковый состав. Версию конкретной машины определяем первой командой.

Узнайте, на какой системе и от чьего имени работаете

cat /etc/os-release
uname -r
uname -m
hostnamectl
id
sudo -l

os-release описывает дистрибутив, uname -r — работающее ядро, uname -m — архитектуру. Версия ядра не является версией ALT или Astra. После установки нового ядра и до перезагрузки эти значения могут отражать разные состояния: пакеты уже обновлены, но машина продолжает работать на прежнем ядре.

hostnamectl показывает сведения хоста на системе с systemd. В контейнере или минимальном образе он может быть недоступен. id показывает текущий UID и группы; пользователь с красивым именем admin не обязательно root. sudo -l помогает понять, какие административные действия действительно разрешены. Не подменяйте эту проверку попытками запустить случайную команду с sudo.

Для конкретной операции сначала используйте command -v, локальный man и версию утилиты. Например, отсутствие resolvectl не означает отсутствие DNS — означает только, что этот интерфейс недоступен. Не смешивайте результат проверки инструмента и результат проверки обслуживаемой системы.

Пакеты: одинаковая задача, три разных набора команд

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

Путь /usr/bin/curl уточните через command -v curl. Если используется собственная сборка в /usr/local/bin, пакетная база может не знать её файл — это ожидаемый результат, а не поломка rpm. apt-get в ALT не превращает её в Debian: формат пакетов остаётся RPM. Не устанавливайте туда DEB из инструкции Astra.

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

В Astra можно посмотреть предполагаемую операцию без установки:

apt-cache policy curl
apt-get -s install curl

В РЕД ОС удобен запрос с отказом от подтверждения:

dnf repolist
dnf install curl --assumeno

Для ALT используйте доступный в вашей сборке симуляционный режим apt-get -s, сверив apt-get --help, и просмотрите настройки APT-RPM. Симуляция не гарантирует успешность будущей операции: состояние репозитория и машины может измениться.

Репозитории и обновления: не превращайте ремонт в миграцию

Сначала выясните, откуда приходят пакеты. В ALT и Astra используется семейство настроек /etc/apt/sources.list и файлов в sources.list.d, но содержимое имеет разный формат. В РЕД ОС репозитории RPM/DNF обычно описаны в /etc/yum.repos.d/.

ls -l /etc/apt/sources.list /etc/apt/sources.list.d 2>/dev/null
ls -l /etc/yum.repos.d 2>/dev/null

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

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

Названия dist-upgrade и upgrade не задают универсальный переход между основными выпусками. Миграция Astra 1.7→1.8, ALT p10→p11 или РЕД ОС между основными версиями проводится по отдельной процедуре производителя. Не меняйте номер в sources.list и не запускайте общий upgrade как замену инструкции миграции.

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

Документация: платформа ALT и пакетные операции, организация репозиториев Astra, команды DNF для РЕД ОС 8, процесс тестирования обновлений РЕД ОС.

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

На системе с systemd сначала найдите фактическое имя службы. SSH-служба часто называется ssh в Astra и sshd в ALT/РЕД ОС, но это нужно проверять в установке:

systemctl list-unit-files 'ssh*'
systemctl --failed
systemctl status nginx.service --no-pager

list-unit-files показывает установленные unit-файлы и состояние включения, а не только запущенные процессы. --failed собирает службы с зарегистрированным отказом. Для nginx смотрите Loaded, Active, основной PID и сообщения. active (running) подтверждает состояние процесса, но ещё не доступность сайта.

Не перезапускайте SSH через удалённое соединение до проверки конфигурации и резервного входа. Для SSH используйте соответствующую проверку sshd -t в своей среде. Для nginx перед reload выполните sudo nginx -t, затем проверьте HTTP-функцию. Изменение конфигурационного файла, unit-файла и приложения — три разных действия.

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

systemctl cat nginx.service
systemctl show nginx.service -p FragmentPath -p DropInPaths -p ExecStart

Первая команда показывает unit и дополнения, вторая — выбранные свойства. Это помогает отличить штатный запуск из пакета от локального override. Перед изменением скопируйте конкретный файл, не редактируйте наугад все найденные совпадения.

Журналы и процессы: найдите причину до рестарта

sudo journalctl -u nginx.service -b --no-pager
sudo journalctl -u nginx.service --since '30 minutes ago' --no-pager
sudo journalctl -k -b --no-pager
ps -eo pid,ppid,user,%cpu,%mem,comm --sort=-%cpu | head -n 15
free -h
uptime

Журнал с -b относится к текущей загрузке, -u фильтрует службу, -k — сообщения ядра. По времени связывайте ошибку приложения с диском, сетевым разрывом или отказом процесса. Если journals хранятся только в памяти, после перезагрузки прошлые события могут быть недоступны — пустой вывод не доказывает отсутствия инцидента.

ps показывает текущий снимок, а не историю. free -h нужно читать с учётом available: Linux использует память для кеша, и небольшой free сам по себе не означает дефицит. В uptime load average — нагрузка очереди задач, а не процент CPU; учитывайте число процессоров и ожидание I/O. Проверить состав нагрузки можно через top и доступные средства мониторинга.

Для аккуратного завершения известного процесса обычно начинают с TERM:

kill -TERM 12345

PID 12345 — пример, не готовая цель. Перед действием установите владельца, назначение и способ остановки. Для службы предпочтительнее её штатный интерфейс или systemctl. KILL не даёт приложению выполнить обычное завершение; это крайняя мера для разобранной ситуации, а не стандартная первая команда.

Сеть: последовательно от адреса до прикладного ответа

ip -br address
ip route show
ip -6 route show
ss -lntup
getent ahosts portal.example.ru

ip -br address показывает адреса интерфейсов, ip route — IPv4-маршруты, отдельная команда — IPv6. ss -lntup показывает слушающие TCP/UDP-сокеты; сведения о процессе могут требовать sudo. Разрешение имени через getent использует системный механизм NSS, поэтому полезно для проверки того, что увидит обычное приложение, а не только DNS-утилита.

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

ip route get 192.0.2.10
curl -sS --max-time 10 -o /dev/null \
  -w 'http=%{http_code} total=%{time_total}\n' https://portal.example.ru/

Все адреса учебные. ip route get не отправляет пользовательский HTTP-запрос: он показывает выбранный путь. HTTP 200 проверяет выбранную страницу, но не бизнес-транзакцию. Не добавляйте curl -k по привычке — неправильный сертификат является частью проблемы.

Для DNS дополнительно полезны resolvectl, dig или nslookup, если установлены. При этом /etc/resolv.conf может быть генерируемым файлом. До редактирования выясните владельца конфигурации: NetworkManager, systemd-resolved, статическая настройка или другая служба.

Если используется NetworkManager:

nmcli device status
nmcli connection show
nmcli connection show --active
nmcli device show

Имя соединения и имя интерфейса не всегда совпадают. Постоянное изменение делается в нужном профиле, а временный ip address add может исчезнуть при переподключении или загрузке. Не выполняйте nmcli connection down на интерфейсе текущего SSH-входа без консольного доступа. Детали интерфейса описаны в официальном руководстве nmcli.

Файлы, права и административные изменения

pwd
ls -lah /etc
stat /etc/hosts
namei -l /var/lib/example/data
id

pwd проверяет текущий каталог, ls показывает имена и базовые права, stat — метаданные объекта. namei -l раскладывает права по компонентам пути. Для доступа к файлу недостаточно права на последний объект: нужен проход по родительским каталогам. Путь example условный; используйте свой реально существующий объект.

Если используются ACL и установлен getfacl, проверьте их отдельно:

getfacl /var/lib/example/data

Результат может отличаться от ожидания по одному ls -l. До chmod/chown выясните владельца данных и пользователя сервиса. Команда chmod -R 777 не является диагностикой: она уничтожает значимые ограничения и не устраняет мандатную политику.

Для редактирования конфигурации разумно использовать sudoedit, если это разрешено политикой:

sudo cp -a /etc/example/app.conf /root/app.conf.before-change
sudoedit /etc/example/app.conf

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

Диски: размеры, монтирование и ошибки чтения

lsblk -f
findmnt
df -hT
df -ih
du -xsh /var/log
sudo journalctl -k -b --no-pager

df описывает занятость файловой системы, du — достижимые файлы выбранного дерева. Разница может возникнуть из-за открытых удалённых файлов, снимков, sparse-файлов, отдельных mount point и особенностей хранения. -x ограничивает du одной файловой системой по устройству; bind mount того же устройства и сложную структуру монтирования всё равно нужно понимать.

Установленная программа lsof может показать удалённые, но открытые файлы:

sudo lsof +L1

Не перезапускайте найденный сервис только ради освобождения пространства, пока не оценён перерыв. Для журнала systemd сначала посмотрите размер journalctl --disk-usage, затем меняйте принятую политику хранения. Ручное удаление активного файла может не освободить место до закрытия дескриптора.

Если раздел стал read-only или появились I/O errors, сначала проверяйте носитель и копию данных. Fsck на смонтированном корневом разделе не является обычной командой очистки. Порядок зависит от FSTYPE, LVM, шифрования и состояния оборудования.

Ограничения безопасности: root не отменяет любую политику

На защищённых редакциях Astra действуют механизмы, которых нет в обычной POSIX-модели. В других установках могут использоваться SELinux, AppArmor, capabilities и политики служб. Поэтому Permission denied нельзя автоматически лечить chmod или sudo. Уточните редакцию, включённый механизм, текущий контекст и конкретное сообщение журнала.

Проверить наличие конкретного инструмента можно через command -v getenforce или command -v aa-status. Отсутствие одного из них не доказывает отсутствия других механизмов. Действия с метками и политиками проводите по документации вашей редакции: универсальный рецепт между всеми российскими Linux здесь был бы неверным.

Соберите состояние и проверьте изменение целиком

Для первичного сбора доступен скрипт linux-quick-check.sh. Он вызывает доступные команды чтения ОС, ресурсов, службы и сети, не устанавливает пакеты, не перезапускает службы и не меняет сеть. В отчёте сохраняются коды завершения отдельных проверок; успешное завершение самого скрипта не является вердиктом об исправности системы. Запускайте его обычным пользователем; часть данных о процессах может быть недоступна без дополнительного разрешения.

umask 077
bash linux-quick-check.sh > linux-quick-check.txt 2>&1

В отчёте есть имена машины, пользователей и сетевые адреса. Храните его как внутренний диагностический материал и очищайте перед публикацией. Не передавайте туда секреты через аргументы; скрипт не запрашивает пароли.

Приёмка любой настройки состоит из трёх связанных проверок: сохранилась ли нужная конфигурация, принял ли её действующий компонент и работает ли пользовательская функция. Например, после изменения DNS сначала читают профиль, затем действующие resolver-настройки, затем проверяют getent и доступ приложения. После изменения службы проверяют unit, процесс и endpoint. Такой порядок превращает справочник из набора знакомых команд в инструмент понятной диагностики.