Linux CLI: полная настройка системы с нуля

База Linux через CLI: установка, файловая система, пакеты

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

Что значит «настроить систему с нуля через CLI»

В рамках курса это означает:

Установить систему (часто минимальную) и уметь загрузиться в консоль.

Понимать, что и где лежит в Linux (каталоги, конфиги, логи, устройства).

Уметь ставить/обновлять/удалять софт из репозиториев, не превращая систему в «зоопарк».

Иметь минимальные навыки работы с дисками, точками монтирования и правами.

Установка Linux с прицелом на работу в CLI

Есть два типичных пути:

Дружелюбный установщик (Debian/Ubuntu/Fedora): быстро получаете рабочую базовую систему.

Ручная установка (например, Arch): лучше учит устройству системы, но требует больше внимания.

Официальные руководства (полезно держать под рукой):

Debian Installation Guide

Ubuntu Server documentation

Fedora Installation Guide

Arch Linux Installation Guide

Ключевые решения при установке

Режим загрузки: UEFI или Legacy (BIOS)

- На современных ПК почти всегда UEFI. - Для UEFI обычно нужен EFI-раздел (ESP), смонтированный как /boot/efi.

Схема разметки диска

- Для UEFI чаще используют GPT.

Разделы и точки монтирования

- Минимально обычно хватает / (root) и swap. - Часто выделяют отдельный /home, чтобы проще переустанавливать систему.

Пользователь и доступ администратора

- Обычно создают обычного пользователя и дают ему sudo.

Сеть

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

Минимальный набор, который стоит установить сразу

openssh-server (если планируете управлять системой удалённо по SSH)

sudo

редактор: nano или vim

базовые утилиты: curl или wget, less, tar

Диски, разделы и монтирование

Linux представляет диски и разделы как файлы устройств в /dev:

/dev/sda, /dev/nvme0n1 — физические диски

/dev/sda1, /dev/nvme0n1p1 — разделы

Как посмотреть, что подключено

lsblk — дерево дисков/разделов и точки монтирования

blkid — UUID и тип файловой системы

df -h — сколько места занято на смонтированных файловых системах

Примеры:

Форматирование и монтирование (осторожно)

Создать файловую систему (пример для ext4):

Смонтировать раздел (пример: корень смонтирован в /mnt во время установки):

Размонтировать:

Автомонтирование при загрузке: /etc/fstab

Чтобы раздела монтировались автоматически при старте системы, используется файл /etc/fstab. В нём обычно указывают UUID, потому что имена устройств (/dev/sda2) могут меняться.

Пример логики:

Сначала узнаём UUID: blkid

Затем добавляем строку в /etc/fstab

Официальная справка: man fstab

!Связь «диск → раздел → точка монтирования», которая лежит в основе установки и /etc/fstab

Файловая система Linux: где что лежит

В Linux почти всё выглядит как файлы и каталоги. Для системы важна иерархия (что где хранится), иначе сложно находить конфигурации и понимать последствия команд.

Абсолютные и относительные пути

Абсолютный путь начинается с /, например /etc/ssh/sshd_config.

Относительный путь считается от текущего каталога, например ./script.sh.

. — текущий каталог

.. — родительский каталог

Полезные команды навигации:

Основные каталоги

| Каталог | Назначение | |---|---| | / | Корень файловой системы (отсюда начинается всё) | | /home | Домашние каталоги пользователей (/home/alex) | | /root | Домашний каталог пользователя root | | /etc | Системные конфигурационные файлы | | /var | Переменные данные: логи, кэши, очереди | | /usr | Большая часть программ и библиотек пользовательского уровня | | /bin, /sbin | Базовые утилиты (часто сейчас как ссылки внутрь /usr) | | /boot | Файлы загрузчика/ядра (а при UEFI часто ещё /boot/efi) | | /dev | Файлы устройств | | /proc | Псевдо-ФС с информацией о процессах и ядре | | /sys | Псевдо-ФС для взаимодействия с устройствами/ядром | | /run | Временные runtime-данные (после загрузки, в RAM) | | /tmp | Временные файлы (могут очищаться автоматически) | | /mnt | Временное ручное монтирование | | /media | Автомонтирование съёмных носителей |

Подробности и стандартизация: Filesystem Hierarchy Standard

Копирование, перемещение, удаление

Базовые команды:

Важно:

rm удаляет без корзины. Ключ -i добавляет подтверждение.

Для каталогов нужен rm -r, но используйте его максимально аккуратно.

Поиск файлов и текста

find — поиск по файловой системе

grep — поиск текста в файлах

Примеры:

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

Большая часть настройки системы упирается в права: почему файл не редактируется, почему сервис не стартует, почему пользователь не имеет доступа.

Три уровня доступа

Для каждого файла есть права для:

владельца (user)

группы (group)

остальных (others)

И три базовых разрешения:

r — чтение

w — запись

x — выполнение (для каталогов означает «можно заходить внутрь»)

Посмотреть права:

Изменить владельца/группу:

Изменить права (пример: владельцу читать/писать, группе только читать):

Администрирование через sudo

Вместо постоянной работы под root обычно используют sudo:

sudoedit удобен тем, что безопаснее редактирует системные файлы (редактор открывает копию и затем применяет изменения).

Справка: man sudo

Пакеты и репозитории: как устанавливается софт

Пакетный менеджер решает несколько задач:

установка программ и зависимостей

обновления (включая исправления безопасности)

удаление без «мусора»

проверка целостности и подписи репозиториев (в зависимости от дистрибутива)

Главная идея: сначала ставим из официальных репозиториев, и только если там нет нужного — думаем про сторонние источники.

Термины, которые важно понимать

Репозиторий — источник пакетов (сервер и набор метаданных)

Индекс пакетов — список доступных пакетов (его нужно обновлять)

Зависимости — другие пакеты, без которых программа не работает

Шпаргалка по менеджерам пакетов

| Действие | Debian/Ubuntu (apt) | Fedora (dnf) | Arch (pacman) | |---|---|---|---| | Обновить индекс | sudo apt update | sudo dnf makecache | sudo pacman -Sy | | Обновить систему | sudo apt upgrade | sudo dnf upgrade | sudo pacman -Syu | | Установить пакет | sudo apt install htop | sudo dnf install htop | sudo pacman -S htop | | Удалить пакет | sudo apt remove htop | sudo dnf remove htop | sudo pacman -R htop | | Поиск | apt search htop | dnf search htop | pacman -Ss htop | | Инфо о пакете | apt show htop | dnf info htop | pacman -Si htop |

Официальная справка:

Debian APT User's Guide

DNF documentation

pacman (Arch Wiki)

Хорошая рутина обновлений

Обновить индекс пакетов.

Обновить установленные пакеты.

Если обновляется ядро/системные библиотеки, планировать перезагрузку.

Пример для Debian/Ubuntu:

Практика безопасности

Не запускайте в системе «магические» команды из интернета вида curl ... | sh, пока не понимаете, что именно будет выполнено.

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

Для диагностики используйте man и документацию пакета:

Связь с тем, что будет дальше

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

понимать, какой файл конфигурации где находится (/etc, /var/log)

уметь монтировать диски и делать изменения постоянными (/etc/fstab)

быстро ставить нужные инструменты и зависимости через пакетный менеджер

Файлы конфигурации: редакторы, права, переменные, SSH

Эта статья связывает базу из предыдущего блока (файловая система, права, sudo, пакеты) с реальной «повседневной» настройкой Linux через CLI: вы будете постоянно находить, читать и аккуратно менять конфиги. Здесь мы разберём инструменты редактирования, правила доступа, переменные окружения и SSH как основной способ удалённого администрирования.

Где обычно живут конфиги

В Linux конфигурация чаще всего находится в двух «слоях»:

Системный слой: влияет на всех пользователей и сервисы.

Пользовательский слой: влияет только на конкретного пользователя.

Типичные места

| Где | Что это обычно значит | Примеры | |---|---|---| | /etc | системные конфиги | /etc/ssh/sshd_config, /etc/fstab, /etc/hosts | | /var | данные сервисов, логи, состояния | /var/log/auth.log, /var/lib/... | | ~ | домашний каталог пользователя | ~/.ssh/config, ~/.profile | | ~/.config | пользовательские настройки приложений | ~/.config/git/config, ~/.config/... |

Полезная привычка: прежде чем что-то менять, найдите «точку правды» (какой именно файл реально читает программа) в man или официальной документации.

Редакторы в CLI и безопасное редактирование

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

Выбор редактора

nano проще для старта.

vim мощнее и быстрее на дистанции, но требует привыкания.

Документация:

GNU nano documentation

Vim documentation

Минимум по nano

Открыть файл: nano /etc/ssh/sshd_config

Сохранить: Ctrl+O, затем Enter

Выйти: Ctrl+X

Поиск: Ctrl+W

Минимум по vim (достаточно для конфигов)

Открыть файл: vim /etc/ssh/sshd_config

Перейти в режим вставки: i

Выйти из режима вставки: Esc

Сохранить и выйти: :wq

Выйти без сохранения: :q!

Поиск: /текст, затем n для следующего совпадения

Почему часто лучше использовать sudoedit

Системные конфиги в /etc обычно принадлежат root, поэтому редактирование требует прав администратора. Вместо sudo vim /etc/... часто безопаснее:

Идея sudoedit:

Файл копируется во временное место и открывается вашим редактором.

После сохранения изменения применяются обратно с правами root.

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

Справка: sudo manual

Резервные копии и проверка изменений

Перед правками делайте бэкап и умейте сравнивать изменения.

Быстрый бэкап:

Сравнение:

Справка: diff manual

Права на конфиги: что важно в реальных настройках

Вы уже знаете rwx и chown/chmod из базы. Здесь главное — понять, почему некоторые конфиги требуют строгих прав.

Почему строгие права критичны для SSH

Если приватный ключ SSH доступен на чтение другим пользователям, его можно украсть. Поэтому OpenSSH намеренно игнорирует некоторые файлы при «слишком широких» правах.

Практически полезные ориентиры:

~/.ssh обычно должен быть 700.

~/.ssh/id_ed25519 (приватный ключ) обычно 600.

~/.ssh/authorized_keys обычно 600.

Примеры команд:

Если что-то не работает, смотрите диагностику (на сервере) в логах и статусе сервиса.

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

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

Справка: environ(7)

Просмотр и установка

Посмотреть переменные текущей сессии:

Посмотреть конкретную:

Справка по Bash: bash(1)

#### Для всей системы

/etc/environment — простой способ задать переменные глобально (формат без export).

/etc/profile и /etc/profile.d/*.sh — настройки для login shell (зависят от системы/оболочки).

Пример /etc/environment:

#### Для systemd-сервисов

Сервисы, запущенные через systemd, не обязаны наследовать переменные как ваш терминал. Для них есть отдельные механизмы.

Environment= и EnvironmentFile= в unit-файле сервиса.

Каталоги environment.d для окружения менеджера.

Справка:

systemd.exec

environment.d

SSH: удалённый доступ и базовая настройка

SSH — основной инструмент для администрирования Linux «с нуля» через CLI, особенно если система без графики.

Справка:

ssh(1)

sshd(8)

sshd_config(5)

!Как связаны ключи SSH, конфиги клиента/сервера и файл authorized_keys

Клиент и сервер: что где настраивается

На клиенте настраивают ssh и параметры подключения.

На сервере настраивают sshd (демон, который принимает подключения).

Ключевые файлы:

| Где | Файл | Роль | |---|---|---| | Клиент | ~/.ssh/config | удобные алиасы, порты, пользователи, ключи | | Клиент | ~/.ssh/known_hosts | «отпечатки» известных серверов | | Клиент | ~/.ssh/id_ed25519 | приватный ключ | | Клиент | ~/.ssh/id_ed25519.pub | публичный ключ | | Сервер | /etc/ssh/sshd_config | политика доступа на сервер | | Сервер | ~/.ssh/authorized_keys | какие публичные ключи пускают пользователя |

Установка SSH-сервера

На Debian/Ubuntu:

На Fedora:

На Arch:

Проверка, что сервер SSH запущен

На systemd-системах обычно так:

Иногда имя сервиса sshd:

Генерация ключей и вход по ключу

Создать ключ (современный вариант — Ed25519):

Приватный ключ храните в секрете.

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

Скопировать публичный ключ на сервер:

Если ssh-copy-id недоступен, можно вручную добавить содержимое ~/.ssh/id_ed25519.pub в ~/.ssh/authorized_keys на сервере.

Удобный клиентский конфиг ~/.ssh/config

Пример (чтобы не помнить параметры):

Теперь подключение проще:

Базовое усиление безопасности sshd

Правки делаются в /etc/ssh/sshd_config. Перед изменениями сделайте бэкап.

Полезные настройки (смысл важнее конкретных строк):

Запретить вход под root по SSH.

Отключить вход по паролю, если вход по ключам уже работает.

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

Примерный набор (как ориентир, не копируйте вслепую — сверяйте с документацией и своей ситуацией):

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

Практическое правило: держите вторую активную SSH-сессию, пока проверяете, что новая конфигурация действительно пускает вас обратно.

Диагностика проблем SSH

Проверка с подробным выводом на клиенте:

Частые причины проблем:

Неверные права на ~/.ssh и файлы ключей.

Подключаетесь не тем пользователем.

Не тот ключ используется.

На сервере запрещён вход по паролю, а ключи не настроены.

На сервере изменили порт или ограничили AllowUsers.

Логи на сервере зависят от дистрибутива, часто помогают:

/var/log/auth.log (Debian/Ubuntu)

journalctl -u ssh или journalctl -u sshd (systemd-журналы)

Справка по журналу: journalctl

Связь с дальнейшей настройкой системы

Дальше по курсу (сеть, графическое окружение, службы) почти всегда будет выглядеть одинаково:

Установили пакет.

Нашли конфиг в /etc или ~/.config.

Аккуратно изменили (часто через sudoedit), проверили права.

Перезапустили сервис и посмотрели логи.

Если вы уверенно редактируете конфиги, понимаете права и окружение, а также можете подключаться по SSH, то настройка системы «с нуля» становится предсказуемой и управляемой.

Сети и интернет: IP, DNS, Wi‑Fi, firewall, диагностика

В предыдущих статьях вы научились ориентироваться в файловой системе, ставить пакеты, безопасно редактировать конфиги через sudoedit, понимать права и пользоваться systemctl и логами. Теперь соберём это в практическую схему: как поднять сеть и интернет целиком через CLI и как диагностировать проблемы.

Ментальная модель сети в Linux

Чтобы интернет «заработал», обычно должны одновременно быть в порядке несколько слоёв:

Сетевой интерфейс поднят (Ethernet или Wi‑Fi).

У интерфейса есть IP-адрес (вручную или через DHCP).

Есть маршрут по умолчанию (default gateway), чтобы выходить в другие сети.

Есть DNS-настройки, чтобы доменные имена переводились в IP.

Firewall не блокирует нужный трафик.

!Схема показывает, какие компоненты должны быть настроены, чтобы работал интернет

Базовые команды и понятия

Интерфейсы, адреса, маршруты

Главный инструмент для просмотра состояния сети в современных системах Linux — ip.

Посмотреть интерфейсы и их состояние:

Посмотреть IP-адреса на интерфейсах:

Посмотреть маршруты (включая маршрут по умолчанию):

Полезная справка: ip(8) — man7

Что означает запись вида 192.168.1.10/24

192.168.1.10 — IP-адрес вашего хоста.

/24 — длина сетевой маски (CIDR), то есть сколько бит адреса относится к сети.

На практике /24 обычно означает сеть уровня домашнего роутера, где адреса часто выглядят как 192.168.1.*.

Важно: вам не нужно считать биты вручную, но нужно понимать, что IP-адрес и «маска» всегда идут парой.

Ethernet и DHCP через CLI

В большинстве обычных сетей адрес выдаёт DHCP-сервер (обычно домашний роутер или корпоративная инфраструктура). Тогда ваша задача — убедиться, что интерфейс поднят и DHCP-клиент отработал.

Быстрая проверка «есть ли линк»

Состояние интерфейса:

Ищите:

state UP — интерфейс включён.

Флаг LOWER_UP — есть физическое соединение (кабель вставлен, линк поднялся).

Частые менеджеры сети

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

NetworkManager (часто на десктопах и многих серверах)

systemd-networkd (часто на минимальных установках)

Проверьте, что у вас активно:

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

DNS: как работает и как чинить

DNS нужен, чтобы curl https://example.com мог узнать IP-адрес домена. Частая ситуация: IP и маршруты есть, но «не открываются сайты» из-за DNS.

Быстрая проверка симптомов

Проверить, есть ли IP и маршрут по умолчанию:

Проверить доступ к IP без DNS:

Проверить доступ по имени (это уже DNS):

Если IP пингуется, а имя нет, проблема почти наверняка в DNS.

Справка: ping(8) — man7

systemd-resolved и resolvectl

Во многих системах DNS обслуживается через systemd-resolved. Тогда полезны команды:

Посмотреть текущие DNS-настройки:

Проверить резолв конкретного имени:

Справка: resolvectl(1) — systemd

Что с /etc/resolv.conf

/etc/resolv.conf исторически хранит DNS-серверы, но часто он является:

файлом, который автоматически генерируется NetworkManager или systemd-resolved;

симлинком на другой файл.

Проверьте:

Правило: если DNS управляется сервисом, не редактируйте resolv.conf «в лоб», изменения могут быть перезаписаны. Вместо этого настройте DNS через ваш менеджер сети.

Диагностика через dig

dig удобен тем, что показывает, какой DNS-сервер отвечает и что именно он вернул.

Установка пакета зависит от дистрибутива, но название часто связано с dnsutils или bind.

Пример запроса:

Справка: dig(1) — Debian manpages

Wi‑Fi через CLI

Wi‑Fi отличается тем, что помимо IP/DHCP есть этап подключения к точке доступа (SSID) и аутентификации (WPA2/WPA3).

Практически самый удобный способ в CLI — nmcli, если у вас NetworkManager.

Wi‑Fi через NetworkManager (nmcli)

Проверить, видит ли система Wi‑Fi-устройство:

Включить Wi‑Fi (если выключен):

Просканировать сети:

Подключиться к сети:

Проверить, получил ли интерфейс адрес и маршрут:

Справка: nmcli(1) — Arch manpages

Низкоуровневая диагностика Wi‑Fi через iw

Если NetworkManager не помогает понять, что происходит, смотрят состояние радио и линка:

Справка: iw(8) — Arch manpages

Важно: для реального подключения без NetworkManager обычно используют wpa_supplicant, но в рамках курса полезнее сначала уверенно освоить nmcli, потому что он закрывает 80% задач в CLI-настройке Wi‑Fi.

Firewall: что это и как не «отрезать» себе доступ

Firewall фильтрует входящий и исходящий трафик. В современных дистрибутивах распространены 3 «уровня» работы:

nftables как базовый механизм фильтрации в ядре.

ufw как простой интерфейс (часто в Ubuntu).

firewalld как сервис-менеджер правил (часто Fedora/RHEL).

Ключевое правило при удалённой настройке по SSH:

Перед применением строгих правил убедитесь, что порт SSH разрешён.

Держите вторую активную SSH-сессию.

Если есть возможность, используйте правила с автооткатом или применяйте изменения поэтапно.

Быстрая проверка, слушает ли сервис порт

Перед тем как винить firewall, проверьте, что служба вообще слушает порт:

Справка: ss(8) — man7

UFW (простой вариант)

Статус и текущие правила:

Разрешить SSH и включить firewall:

Справка: ufw(8) — Ubuntu manpages

firewalld (зонная модель)

firewalld оперирует зонами (например, public) и сервисами (например, ssh). Быстрый старт:

Справка: Документация firewalld

nftables (как основа)

Если вы хотите понимать, что происходит «под капотом», полезно знать, что современные системы часто используют nft.

Посмотреть текущие правила:

Справка: nftables wiki

Диагностика: практический чек-лист

Ниже — последовательность, которая чаще всего приводит к причине проблемы быстрее всего.

Проверка линка и интерфейса

Интерфейс существует и UP:

Есть ли Wi‑Fi и видит ли сети (если Wi‑Fi):

Проверка адресации и маршрутов

Есть ли IP на нужном интерфейсе:

Есть ли default route:

Проверка доступности по сети

Пингуется ли шлюз (обычно адрес роутера в вашей сети):

Пингуется ли внешний IP:

Проверка DNS

Что система считает DNS-конфигурацией:

Резолв домена:

Расширенная проверка через dig:

Проверка прикладного уровня (HTTP/HTTPS)

Иногда ICMP (ping) блокируется, но HTTP работает. Проверьте запрос к сайту:

Справка: curl manpage

Трассировка маршрута

Если непонятно, где пропадает трафик:

Справка: traceroute(8) — Debian manpages

Просмотр логов сетевого менеджера

Так как вы уже умеете работать с systemctl и журналом, используйте логи как «источник правды».

NetworkManager:

systemd-networkd:

systemd-resolved:

Справка: journalctl — systemd

Точечная диагностика пакетами (tcpdump)

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

Команда покажет DNS-трафик (порт 53) на всех интерфейсах. Это особенно полезно, когда DNS «как будто настроен», но ответы не возвращаются.

Справка: tcpdump(1) — tcpdump.org

Как делать изменения постоянными

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

Если NetworkManager, задавайте подключения через nmcli (они сохраняются как профили).

Если systemd-networkd, правьте .network файлы в /etc/systemd/network/ и перезапускайте сервис.

При любом подходе применяйте навыки из прошлых статей:

делайте бэкапы конфигов перед правками;

используйте sudoedit для безопасного редактирования;

после изменений проверяйте статус сервисов через systemctl и смотрите логи через journalctl.

Связь с дальнейшей настройкой системы

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

пакеты и обновления требуют рабочей маршрутизации и DNS;

SSH и администрирование требуют корректного firewall;

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

Если вы уверенно читаете вывод ip addr, ip route, понимаете где смотреть DNS (resolvectl и /etc/resolv.conf), умеете подключаться к Wi‑Fi через nmcli и проверять порты через ss, то вы можете поднять интернет на «голой» системе и быстро локализовать сбой.

Сервисы и загрузка: systemd, логи, задачи, обновления

В предыдущих статьях вы научились ставить пакеты, редактировать конфиги через sudoedit, работать с правами, поднимать сеть и диагностировать проблемы. Следующий слой, без которого «настройка системы с нуля» не становится управляемой, это управление сервисами и загрузкой.

В большинстве современных дистрибутивов этим занимается systemd:

запускает сервисы при старте системы;

следит за их состоянием и перезапускает при сбоях;

ведёт единый журнал логов;

управляет режимами загрузки;

умеет планировать периодические задачи.

!Диаграмма того, как systemd связывает загрузку, targets и сервисы

Ментальная модель systemd

systemd запускается как процесс PID 1 и управляет остальными процессами через юниты.

Юнит это объект конфигурации systemd. Основные типы:

service — сервис (демон), который должен работать в фоне;

socket — активация сервиса по сокету (сервис стартует по запросу);

timer — расписание (аналог cron, но в модели systemd);

mount — точки монтирования;

target — «режим работы» системы (группа юнитов).

Официальная документация:

systemd

systemd.unit

Управление сервисами через systemctl

systemctl это основной инструмент управления systemd.

Документация: systemctl

Найти и проверить сервис

Посмотреть статус сервиса:

Если имя отличается, ищите по списку:

Быстро проверить, активен ли сервис:

Старт, стоп, рестарт, перечитать конфиг

Чаще всего нужны эти команды:

Разница между restart и reload:

restart перезапускает процесс сервиса;

reload просит сервис перечитать конфиги без полного перезапуска, но работает только если сервис это поддерживает.

Автозапуск при загрузке: enable и disable

Важно различать:

запустить сейчас — start;

включить автозапуск при загрузке — enable.

Примеры:

Полезные проверки:

Что делать после правки unit-файла

Если вы меняли unit-файл или добавляли новый в /etc/systemd/system/, systemd должен перечитать конфигурацию:

Это не перезапускает сервисы автоматически. Перезапуск делайте явно.

Targets: режимы загрузки и переключение без GUI

В терминах systemd, target это «цель загрузки»: набор сервисов, который должен быть активен.

Частые targets:

multi-user.target — консольный режим с сетью (типично для серверов);

graphical.target — графический режим (к нему вы придёте, когда будете ставить окружение);

rescue.target — режим восстановления (минимальный набор сервисов, один пользователь);

emergency.target — максимально минимальный режим для тяжёлых случаев.

Документация: systemd.target

Узнать текущую цель и цель по умолчанию

Сделать консольный или графический режим по умолчанию

Переключить загрузку по умолчанию на консольный режим:

Переключить загрузку по умолчанию на графический режим:

Временно переключиться в другой target

Это полезно для диагностики или обслуживания:

Осторожно: изоляция может остановить сервисы, которые не входят в target.

Логи: journald и journalctl

Для диагностики проблем из прошлых статей вы уже использовали journalctl -u ... -b. Теперь систематизируем.

systemd-journald собирает логи ядра, сервисов и системы в единый журнал.

Документация:

systemd-journald

journalctl

Быстрые сценарии journalctl

Показать ошибки текущей загрузки:

Логи конкретного сервиса в текущей загрузке:

Следить за логами в реальном времени:

Посмотреть логи предыдущей загрузки:

Фильтр по времени:

Приоритеты сообщений

Сообщения имеют уровни важности. На практике чаще всего полезны:

err — ошибки;

warning — предупреждения;

info — информационные сообщения.

Поэтому -p err и -p warning часто дают «суть» быстрее, чем полный поток.

Где хранятся логи и почему журнал может быть непостоянным

Журнал может храниться:

в памяти, если нет постоянного хранилища;

на диске, если включено постоянное хранение.

Проверка использования диска журналом:

Настройка делается в /etc/systemd/journald.conf. Документация: journald.conf

Практическое правило: если после перезагрузки «всё исчезло», проверьте, что журнал хранится постоянно и что место на диске не ограничивает хранение слишком жёстко.

Диагностика проблем сервиса: практический шаблон

Когда «что-то не работает», действуйте одинаково, независимо от сервиса:

Проверить статус:

Посмотреть последние логи сервиса:

Проверить конфигурацию сервиса:

прочитать основной конфиг в /etc;

проверить, нет ли ошибок синтаксиса, если у сервиса есть проверочная команда.

Перезапустить и сразу смотреть логи:

Убедиться, что проблема не в зависимостях:

для сети смотрите NetworkManager, systemd-networkd, systemd-resolved;

для портов и доступности используйте ss -tulpen и настройки firewall из предыдущей статьи.

Планировщик задач: cron и systemd timers

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

Есть два основных подхода:

cron — классический планировщик;

systemd timers — современный способ в экосистеме systemd.

Cron: когда достаточно

Cron удобен, если:

вы поддерживаете старые системы;

нужна простая периодичность;

вам привычнее один файл расписания.

Документация: crontab

Минусы cron в контексте курса:

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

нет «единого» статуса задачи как у systemd.

systemd timers: модель «задача как сервис»

У systemd таймер обычно состоит из двух юнитов:

something.service — что именно выполнить;

something.timer — когда это выполнять.

Документация: systemd.timer

Плюсы timers:

единые логи в journalctl;

единое управление через systemctl;

можно использовать зависимости, условия запуска и стандартные механизмы systemd.

Минимальный пример timer

Создайте сервис /etc/systemd/system/cleanup-tmp.service:

Создайте таймер /etc/systemd/system/cleanup-tmp.timer:

Примените и включите таймер:

Проверка:

Почему Type=oneshot:

это разовая команда, а не демон, который должен постоянно работать.

Почему Persistent=true:

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

Обновления системы: безопасная рутина через CLI

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

Практика безопасных обновлений

Прочитать, что будет обновляться.

Для Debian/Ubuntu это обычно выглядит так:

Следить за тем, перезапускаются ли сервисы.

После обновлений полезно проверить:

Планировать перезагрузку, если обновились базовые компоненты.

Чаще всего перезагрузка нужна после:

обновления ядра;

обновления системных библиотек, которые используются множеством процессов.

После перезагрузки быстро убедиться, что система поднялась корректно:

Управление выключением и перезагрузкой

С systemd корректные команды:

Автообновления как идея

Автообновления это не одна команда, а политика.

На Debian/Ubuntu часто используют пакет unattended-upgrades.

На Fedora есть dnf-automatic.

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

нет ли упавших сервисов: systemctl --failed;

нет ли ошибок в журнале: journalctl -p err -b.

Как это связывается с настройкой системы «с нуля»

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

Установили пакет.

Изменили конфиг в /etc через sudoedit.

Применили изменения корректно:

systemctl daemon-reload, если меняли unit-файл;

systemctl restart <service>, если меняли конфиг сервиса.

Диагностировали по «источнику правды»:

systemctl status <service>;

journalctl -u <service> -b.

Если вы уверенно управляете сервисами, targets, логами и задачами, то система перестаёт быть «магией» и становится набором проверяемых и воспроизводимых шагов.

Графическое окружение: Xorg/Wayland, драйверы, дисплей-менеджер

Эта статья завершает связку из предыдущих блоков курса:

из пакетов вы берёте нужные компоненты графики;

через конфиги в /etc и ~/.config вы настраиваете сессию;

через сеть скачиваете драйверы и обновления;

через systemd включаете автозапуск графического входа и читаете логи, когда «чёрный экран».

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

Ментальная модель: из каких слоёв состоит графика в Linux

Графическое окружение в Linux удобно понимать как стек.

!Схема показывает, какие компоненты участвуют в запуске графики и где находятся Xorg/Wayland

Что за что отвечает

Ядро (DRM/KMS): включает режимы экрана и предоставляет интерфейс для работы с видеокартой.

Драйвер GPU: модуль ядра и пользовательские библиотеки, которые знают вашу видеокарту.

Mesa: реализация OpenGL и часто часть Vulkan-стека для открытых драйверов.

Xorg (X11): классическая система, где есть отдельный X-сервер.

Wayland: современная модель, где ключевую роль играет композитор (он же «сервер отображения»).

Xwayland: совместимость, чтобы X11-приложения работали внутри Wayland-сессии.

Desktop Environment (DE) или Window Manager (WM): GNOME, KDE Plasma, Xfce, i3, Sway.

Display Manager (DM): экран логина (GDM/SDDM/LightDM), который запускает графическую сессию.

Полезные справки:

Wayland

X.Org

Arch Wiki: Xorg

Arch Wiki: Wayland

Xorg и Wayland: что выбрать

Оба варианта могут быть «правильными», выбор зависит от железа, драйверов и задач.

Короткое сравнение

| Критерий | Xorg | Wayland | |---|---|---| | Архитектура | отдельный X-сервер | композитор управляет выводом | | Совместимость со старым софтом | максимальная | высокая через Xwayland | | Современные фичи (HiDPI, безопасность, ввод) | зависит от окружения | чаще проще и аккуратнее | | NVIDIA (исторически) | часто проще «завести» | сейчас обычно нормально, но зависит от связки драйверов и окружения |

Практическое правило:

если вы ставите GNOME или KDE на современном дистрибутиве, Wayland часто будет вариантом по умолчанию;

если вам нужна максимальная предсказуемость совместимости (например, старые приложения, специфические утилиты), Xorg может быть проще;

если что-то не работает в Wayland, временно войдите в Xorg-сессию (обычно это выбор на экране логина).

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

Графика начинается с корректного драйвера. Ошибки на этом уровне часто выглядят как:

чёрный экран после установки DM;

«логин-луп» (возвращает на экран входа);

очень низкая производительность и высокая загрузка CPU;

отсутствие нужных разрешений.

Определить видеокарту и драйвер, который используется

Посмотреть устройство и выбранный драйвер:

Посмотреть, какие модули ядра загружены:

Посмотреть сообщения ядра по графике:

Справки:

lspci

dmesg

Какие драйверы бывают

Intel: обычно i915 (открытый драйвер, как правило работает «из коробки»).

AMD: обычно amdgpu (открытый драйвер, часто требует актуальной прошивки).

NVIDIA:

- nouveau (открытый, но часто ограниченный по возможностям); - nvidia (проприетарный, обычно нужен для производительности и некоторых функций).

Официальная документация NVIDIA:

NVIDIA Driver Downloads

Прошивки (firmware): частая причина проблем

Для многих GPU и Wi‑Fi нужны бинарные прошивки. В минимальных установках они могут отсутствовать.

Примеры пакетов (названия зависят от дистрибутива):

Debian/Ubuntu: firmware-linux, linux-firmware (зависит от версии и репозиториев)

Fedora: linux-firmware

Arch: linux-firmware

Проверка симптомов в dmesg часто выглядит как сообщения вида failed to load firmware.

Проверить 3D-ускорение (OpenGL/Vulkan)

OpenGL (удобно через пакет mesa-utils):

Vulkan (если установлен vulkan-tools):

Справки:

glxinfo

vulkaninfo

Установка базового GUI через CLI: общая стратегия

Стратегия полезна тем, что вы можете начать с минимального «теста графики», а уже потом ставить полноценное окружение.

Убедиться, что сеть работает (из прошлой статьи) и система обновлена.

Установить драйверы и прошивки.

Поставить минимальный набор для теста:

- для Xorg: xorg-server и простое приложение вроде xterm; - для Wayland: тестовый композитор (например, Weston) или сразу GNOME/KDE.

Затем выбрать один из вариантов запуска:

- вручную из TTY (полезно для диагностики); - через display manager (нужно для постоянного удобного входа).

Xorg: минимальный запуск и логика startx

Xorg полезен тем, что его легко запустить вручную и проверить, что графика вообще поднимается.

Установка минимального набора (примеры)

Debian/Ubuntu:

Fedora:

Arch:

Справка:

Arch Wiki: xinit

Запуск X-сессии вручную

Перейдите в TTY (если вы уже в графике, это обычно Ctrl+Alt+F3).

Запустите:

Если не задана сессия, часто стартует xterm или «пустая» сессия.

Управление тем, что стартует в Xorg: ~/.xinitrc

Файл ~/.xinitrc определяет, что запускать в X-сессии.

Пример для простого оконного менеджера (схема, чтобы понимать принцип):

Ключевая идея: последняя команда обычно запускается через exec, чтобы заменить процесс и корректно завершать сессию.

Где смотреть логи Xorg

Часто полезны:

journalctl -b и journalctl -b -p err

/var/log/Xorg.0.log (не во всех системах и конфигурациях)

Пример поиска ошибок в Xorg-логе:

Wayland: композитор как центр системы

В Wayland нет отдельного «X-сервера» как главного компонента. Важнее выбрать композитор.

Какие композиторы встречаются чаще всего

GNOME: композитор Mutter

KDE Plasma: композитор KWin

Sway: композитор, совместимый по конфиг-логике с i3

Weston: референсный композитор Wayland, удобен для теста

Справка:

Weston

Быстрый тест Wayland через Weston

Пакеты зависят от дистрибутива, но часто называются weston.

Запуск из TTY:

Если сессия не стартует, полезно запускать с логами и смотреть journalctl -b.

X-приложения в Wayland

Если вы в Wayland-сессии, X11-приложения обычно запускаются через Xwayland автоматически (зависит от окружения). Это объясняет, почему «Xorg не установлен как сервер, а X-программы всё равно работают».

Desktop Environment и Window Manager: что ставить

Для «полной настройки системы» важно понимать, что DE и DM это разные вещи.

DE (GNOME/KDE/Xfce): панель, настройки, проводник, интеграция.

WM (i3/Sway и другие): управление окнами, часто минимализм.

DM (GDM/SDDM/LightDM): экран входа и запуск сессии.

Практический выбор для старта:

GNOME: часто лучший вариант «поставил и работает».

KDE Plasma: много настроек, удобно для тонкой кастомизации.

Xfce: лёгкий и стабильный вариант.

Display manager: автозапуск графического входа через systemd

Display manager это обычный systemd-сервис. Вы уже знаете, как работать с сервисами и логами из прошлой статьи.

Популярные display manager

| DM | Типичные окружения | systemd-юнит | |---|---|---| | GDM | GNOME (и часто просто «по умолчанию» в ряде дистрибутивов) | gdm | | SDDM | KDE Plasma | sddm | | LightDM | часто с Xfce и лёгкими окружениями | lightdm |

Ссылки:

GDM

SDDM

LightDM

Установка и включение (примерный сценарий)

Установите DE и DM пакетами вашего дистрибутива.

Включите DM на автозапуск:

Или для другого DM:

Сделайте графический режим загрузки целью по умолчанию:

Справка:

systemctl

systemd targets

Как откатиться в консольный режим

Если после установки графики стало плохо (например, чёрный экран), важно уметь вернуться к консоли.

Переключить цель по умолчанию обратно:

Остановить DM:

На время текущей сессии можно «изолировать» консольный режим:

Диагностика проблем GUI: воспроизводимый чек-лист

Минимальный набор вопросов

Загрузился ли DM как сервис?

Поднялся ли правильный драйвер GPU?

Стартует ли сессия пользователя?

Не ломает ли вход неправильная конфигурация в ~/.config?

Команды, которые почти всегда дают ответ

Проверить, что DM активен и не падает:

Посмотреть общие ошибки текущей загрузки:

Проверить GPU и модуль:

Если есть «логин-луп», временно проверьте, не ломает ли вход пользовательская конфигурация:

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

Частые причины

не установлен linux-firmware (или аналог) и драйвер не может загрузить прошивку;

конфликт драйверов (например, попытка одновременно использовать несовместимые варианты);

включили DM, но не поставили само окружение или сессию;

сломаны права в домашнем каталоге пользователя;

проблемы NVIDIA на конкретной связке ядра, драйвера и Wayland.

Связь с дальнейшими шагами курса

После того как вы подняли GUI, «полная настройка системы» становится практичнее, но основные принципы остаются CLI-ориентированными:

пакеты ставим и обновляем через менеджер пакетов;

конфиги храним в /etc и ~/.config, редактируем аккуратно;

автозапуск и состояние контролируем через systemctl;

проблемы разбираем через journalctl и проверку драйверов.

Если вы уверенно понимаете разницу Xorg и Wayland, умеете проверить драйвер и включить display manager как сервис, вы можете поставить и обслуживать графическое окружение без «ручной магии» и с понятной диагностикой.