Администрирование Linux

Основы Linux и работа в командной строке

Роль командной строки в администрировании Linux

Linux-системы часто администрируют через командную строку, потому что она:

Доступна даже без графического интерфейса (например, на сервере).

Хорошо автоматизируется (скрипты, конвейеры команд).

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

Одинаково работает локально и по сети (например, через SSH).

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

Что такое Linux

В повседневной речи под Linux часто понимают операционную систему целиком. Технически корректнее разделять несколько уровней.

Ядро Linux — центральная часть ОС, которая управляет процессами, памятью, устройствами и файловыми системами.

Пользовательское пространство — утилиты и библиотеки, с которыми вы взаимодействуете (например, ls, cp, systemd, библиотека glibc). Значительная часть базовых утилит исторически относится к проекту GNU.

Дистрибутив Linux — комплект из ядра, утилит, менеджера пакетов, настроек и репозиториев. Примеры: Debian, Ubuntu, Rocky Linux, Fedora, openSUSE.

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

Linux kernel

Проект GNU

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

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

Консоль — способ получить текстовый доступ к системе (локально через виртуальные консоли tty или удалённо через SSH).

Терминал — программа-эмулятор терминала в графической среде (например, GNOME Terminal, Konsole), которая отображает ввод/вывод.

Shell (оболочка) — интерпретатор команд, который читает ваш ввод и запускает программы. Часто по умолчанию используется bash, но бывают zsh, fish.

Когда вы вводите команду, обычно происходит цепочка:

терминал принимает ввод

оболочка разбирает команду

ядро запускает программу и управляет её выполнением

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

Bash Reference Manual

Как читать приглашение командной строки

Типичное приглашение может выглядеть так:

bash

записать список файлов в файл (перезапишет содержимое out.txt)

ls -la > out.txt

дописать строку в конец файла

echo "hello" >> out.txt

найти строки с ssh в файле (конвейер)

cat /etc/services | grep ssh

записать ошибки в отдельный файл

grep "something" missing.txt 2> errors.txt bash

найти файл по имени в текущем каталоге и ниже

find . -name "*.conf"

найти строки с "PermitRootLogin" в конфиге

grep "PermitRootLogin" /etc/ssh/sshd_config

рекурсивно искать строку в каталоге

grep -R "ERROR" /var/log bash

показать процессы текущего пользователя

ps

показать все процессы в подробном виде (формат зависит от системы)

ps aux

открыть монитор процессов

top

отправить сигнал завершения процессу по PID

kill 12345 bash man ls ls --help apropos "copy files" bash

1) посмотреть где вы находитесь и что рядом

pwd ls

2) создать каталог и файл

mkdir linux-cli cd linux-cli touch notes.txt

3) записать несколько строк в файл

echo "first line" > notes.txt echo "second line" >> notes.txt

4) просмотреть файл и найти строку

cat notes.txt grep "second" notes.txt

5) сохранить подробный список файлов в отчёт

ls -la > report.txt less report.txt ```

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

Пользователи, группы и права доступа

Зачем администратору разбираться в пользователях и правах

В предыдущей статье вы освоили командную строку, навигацию, работу с файлами и просмотр процессов. Следующий базовый слой администрирования Linux — контроль доступа: кто вошёл в систему, что ему разрешено делать, и как ограничить действия так, чтобы система оставалась безопасной и управляемой.

В Linux доступ к файлам, каталогам и части системных операций определяется:

пользователями

группами

правами доступа

(в некоторых системах) расширенными списками доступа ACL

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

Пользователи в Linux: что это такое

Пользователь — это учётная запись, от имени которой запускаются процессы и выполняются операции с ресурсами.

Важные свойства пользователя:

имя (login), например alice

числовой идентификатор UID

основная группа (primary group) с идентификатором GID

домашний каталог, например /home/alice

оболочка (shell), например /bin/bash

Root и системные пользователи

root — суперпользователь с UID 0. Обычно может читать и изменять почти всё в системе и выполнять привилегированные операции.

системные пользователи — учётные записи для служб и демонов (например, веб-сервер, база данных). Часто не имеют интерактивного входа и используются для изоляции процессов.

Проверить текущего пользователя и его группы можно так:

Где хранятся сведения об учётных записях

В классической локальной схеме учётные записи описаны в файлах:

/etc/passwd — основная информация о пользователях

/etc/shadow — хэши паролей и политика пароля (обычно доступен только root)

/etc/group — группы и их участники

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

Официальные описания форматов:

passwd(5) — Linux man page

shadow(5) — Linux man page

group(5) — Linux man page

> В реальной инфраструктуре пользователи могут приходить не только из локальных файлов, но и из LDAP/FreeIPA/Active Directory. Базовая логика прав при этом сохраняется.

Группы: зачем они нужны

Группа — это способ выдать доступ не одному пользователю, а набору пользователей.

Практическая идея:

назначить каталогу группу developers

дать группе право записи

добавить нужных пользователей в developers

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

Полезные команды:

getent показывает информацию из настроенных источников учётных записей (локальные файлы, LDAP и т.д.), поэтому часто удобнее, чем прямой просмотр /etc/group.

Управление пользователями и группами

Конкретные утилиты зависят от дистрибутива:

в Debian/Ubuntu часто используют удобную обёртку adduser

почти везде доступны низкоуровневые useradd, usermod, userdel, groupadd, groupmod, groupdel

Примеры типовых операций:

Проверить, что пользователь состоит в группе:

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

useradd(8) — Linux man page

usermod(8) — Linux man page

groupadd(8) — Linux man page

Переключение пользователя: su и sudo

su

su запускает shell от имени другого пользователя (часто root).

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

sudo

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

Плюсы sudo для администрирования:

меньше соблазна работать постоянно под root

логирование: кто и что запускал

можно выдавать права точечно (на команды, хосты, группы)

Настройки определяются файлом /etc/sudoers и фрагментами в /etc/sudoers.d/. Редактируют их безопасно через visudo.

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

sudo(8) — Linux man page

sudoers(5) — Linux man page

Модель прав доступа Unix: владелец, группа, остальные

Большинство файлов и каталогов в Linux имеют:

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

группу (group)

права для трёх классов: user, group, others

Посмотреть это можно командой ls -l:

Пример строки:

Здесь:

alice — владелец

developers — группа

rw- — права владельца

r-- — права группы

--- — права остальных

!Визуальная расшифровка строки прав доступа и смысла r/w/x

Что означают r, w, x для файла и каталога

Права читаются одинаково (r/w/x), но смысл отличается для файлов и каталогов.

Для файла:

r — читать содержимое

w — изменять содержимое

x — выполнять как программу/скрипт

Для каталога:

r — читать список имён файлов (возможность сделать ls)

w — создавать/удалять/переименовывать элементы внутри каталога

x — входить в каталог и обращаться к объектам по имени (например, cd dir, cat dir/file)

Практически важная деталь: для доступа к файлу по пути нужно x на всех каталогах по пути.

Изменение прав: chmod

chmod меняет права доступа.

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

chmod(1) — Linux man page

Символьный режим chmod

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

u — владелец (user)

g — группа (group)

o — остальные (others)

a — все сразу (all)

+ добавить право, - убрать, = установить точно

Примеры:

Числовой режим chmod

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

Соответствие цифры правам:

r = 4

w = 2

x = 1

Сумма даёт значение для каждой тройки (владелец/группа/остальные).

Таблица типовых значений:

| Значение | Права | Типично для | |---|---|---| | 7 | rwx | владельца исполняемого файла | | 6 | rw- | редактируемого файла | | 5 | r-x | чтения + входа в каталог | | 4 | r-- | только чтение | | 0 | --- | нет доступа |

Примеры:

Владельцы и группы: chown и chgrp

Если нужно изменить владельца и/или группу, применяют:

chown — владелец и группа

chgrp — только группа

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

chown(1) — Linux man page

chgrp(1) — Linux man page

Примеры:

Права по умолчанию: umask

Когда вы создаёте новый файл или каталог, система применяет маску umask, которая ограничивает права по умолчанию.

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

Частая практика:

для обычных пользователей umask 022 (новые файлы обычно 644, каталоги 755)

для более закрытых сред umask 077 (доступ почти только владельцу)

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

umask(2) — Linux man page

Специальные биты: setuid, setgid, sticky

Кроме обычных r/w/x существуют специальные режимы, которые часто встречаются в администрировании.

setuid

Если установлен setuid на исполняемом файле, то при запуске процесс получает права владельца файла (часто root). Это используется для ограниченного набора системных утилит.

setgid

для файла: аналогично setuid, но по группе

для каталога: новые файлы/каталоги внутри наследуют группу каталога (полезно для командной работы)

sticky bit

Обычно ставят на каталоги общего доступа (классический пример — /tmp). С sticky bit пользователи могут удалять в каталоге только свои файлы (даже если каталог доступен на запись всем).

Посмотреть специальные биты можно в выводе ls -l по символам s/t в правах.

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

chmod(1) — Linux man page

ACL: когда стандартных прав недостаточно

Иногда нужно выдать доступ конкретному пользователю без добавления его в группу и без изменения прав для остальных. Для этого применяют ACL.

просмотр ACL: getfacl

изменение ACL: setfacl

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

getfacl(1) — Linux man page

setfacl(1) — Linux man page

> ACL полезны, но усложняют диагностику прав. В администрировании важно договориться о правилах: где ACL допустимы, а где лучше решать через группы.

Практический сценарий: общий каталог для команды

Задача: сделать каталог проекта, куда могут писать участники группы developers, а остальные не имеют доступа.

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

На этом этапе:

пользователи в developers могут создавать и редактировать файлы

группа у новых файлов будет developers (из-за setgid на каталоге)

доступ извне ограничен

Как диагностировать проблемы с доступом

Если команда возвращает Permission denied, действуйте последовательно:

Проверьте, кто вы: whoami, id.

Проверьте права на сам файл/каталог: ls -l или stat <путь>.

Проверьте права на родительские каталоги по пути: namei -l <путь> (если утилита установлена).

Проверьте, нет ли ACL: getfacl <путь>.

Если используется sudo, убедитесь, что команда запускается с повышением: sudo ....

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

stat(1) — Linux man page

namei(1) — Linux man page

Итог

Теперь у вас есть базовая модель, на которой держится безопасность Linux:

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

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

sudo позволяет выдавать привилегии точечно

chmod, chown, chgrp, umask — ежедневные инструменты администратора

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

Управление пакетами, процессами и логами

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

!Взаимосвязь пакетов, процессов и логов в типовой диагностике

Управление пакетами

Что такое пакет и репозиторий

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

Репозиторий — источник пакетов (обычно по сети), где менеджер пакетов получает:

список доступных пакетов

сами пакеты

криптографические подписи репозитория

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

Основные менеджеры пакетов

Менеджер пакетов зависит от дистрибутива.

| Дистрибутивы | Менеджер пакетов | Формат пакетов | |---|---|---| | Debian, Ubuntu | apt | .deb | | RHEL, Rocky, AlmaLinux, Fedora | dnf (и совместимый yum) | .rpm | | openSUSE | zypper | .rpm |

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

APT User's Guide

DNF Command Reference

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

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

| Задача | Debian/Ubuntu (apt) | RHEL/Fedora (dnf) | |---|---|---| | Обновить индексы (списки пакетов) | sudo apt update | sudo dnf makecache | | Обновить установленные пакеты | sudo apt upgrade | sudo dnf upgrade | | Найти пакет по имени/описанию | apt search <строка> | dnf search <строка> | | Показать информацию о пакете | apt show <пакет> | dnf info <пакет> | | Установить пакет | sudo apt install <пакет> | sudo dnf install <пакет> | | Удалить пакет (оставив конфиги) | sudo apt remove <пакет> | sudo dnf remove <пакет> | | Удалить пакет вместе с конфигами | sudo apt purge <пакет> | обычно решают вручную, зависит от пакета | | Удалить неиспользуемые зависимости | sudo apt autoremove | sudo dnf autoremove |

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

обновление индексов (получили свежий список пакетов)

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

Где настраиваются репозитории

Обычно добавление репозиториев требует прав администратора, поэтому используется sudo (из предыдущей статьи).

Типовые места конфигурации:

Debian/Ubuntu:

- /etc/apt/sources.list - /etc/apt/sources.list.d/*.list

RHEL-подобные:

- /etc/yum.repos.d/*.repo

> В production-среде старайтесь минимизировать количество сторонних репозиториев: это снижает риск конфликтов зависимостей и повышает предсказуемость обновлений.

Практический пример: установка пакета и проверка

Пример установки веб-сервера nginx.

Debian/Ubuntu:

RHEL/Fedora:

Дальше обычно нужно запустить службу. Это уже пересечение с управлением процессами и службами.

Управление процессами

Термины: процесс, PID и служба

Процесс — выполняющаяся программа в системе. У процесса есть:

PID (Process ID) — уникальный идентификатор процесса

владелец (пользователь), от чьего имени процесс работает

ресурсы: CPU, память, открытые файлы и сетевые соединения

Служба — это обычно долгоживущий процесс (или набор процессов), управляемый менеджером служб (часто systemd). Один из практических смыслов systemd: единообразно запускать, останавливать и проверять состояние сервисов.

Просмотр процессов

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

ps — снимок процессов

top — интерактивный монитор

pstree — дерево процессов (если установлено)

Примеры:

Если нужно найти PID по имени удобнее использовать pgrep:

Ключ -a часто показывает и PID, и команду.

Сигналы и остановка процессов

Процессы в Linux управляются сигналами.

Самые важные:

SIGTERM — просьба корректно завершиться (по умолчанию сигнал команды kill)

SIGKILL — принудительное немедленное завершение (процесс не может отказаться)

SIGHUP — часто используется для перечитывания конфигурации (зависит от программы)

Примеры:

Почти всегда начинайте с SIGTERM. SIGKILL используйте, когда процесс завис или игнорирует завершение.

Приоритеты: nice и renice

У процессов есть приоритет планирования (упрощённо: насколько охотно система даёт процессу CPU).

nice — запустить команду с заданным приоритетом

renice — изменить приоритет уже запущенному процессу

Пример:

Управление службами через systemd

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

Типовые команды:

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

systemctl — документация systemd

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

Зачем нужны логи

Логи отвечают на вопросы:

что произошло

когда произошло

какой процесс и от какого пользователя это сделал

какую ошибку вернуло приложение или система

В Linux вы будете встречать два основных источника логов:

журналы systemd-journald (просматриваются journalctl)

текстовые файлы в /var/log

Какие именно файлы есть в /var/log, зависит от дистрибутива и настроек.

Просмотр логов через journalctl

journalctl — главный инструмент в системах с systemd.

Примеры наиболее полезных режимов:

Полезно помнить, что логи можно фильтровать по приоритету (уровню важности). Например, чтобы увидеть только ошибки:

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

journalctl — документация systemd

Классические файлы в /var/log

Часто встречающиеся файлы (названия могут отличаться):

/var/log/auth.log или /var/log/secure — аутентификация, sudo, SSH

/var/log/syslog или /var/log/messages — системные сообщения

логи конкретных приложений: например, /var/log/nginx/

Просматривать удобно так:

Если файл сжат (например, .gz), используйте zgrep:

Ротация логов: logrotate

Если логи не ограничивать, они могут занять весь диск. Обычно за это отвечает logrotate:

архивирует старые логи

может сжимать их

удаляет слишком старые

создаёт новый пустой лог-файл

Конфигурация чаще всего находится здесь:

/etc/logrotate.conf

/etc/logrotate.d/

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

logrotate(8) — Linux man page

Практический рабочий алгоритм администратора

Когда что-то не работает, полезно действовать в одной и той же логике.

Проверить, установлен ли пакет и нужная ли версия

- apt show <пакет> или dnf info <пакет>

Проверить статус службы

- systemctl status <служба>

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

- ps aux | grep <имя> или pgrep -a <имя>

Посмотреть логи службы и системы

- journalctl -u <служба> -b -n 200 - при необходимости: tail -n 200 /var/log/...

Исправить причину и повторить проверку

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

Сеть, SSH и базовая настройка firewall

В прошлых статьях вы научились работать в командной строке, управлять пользователями и правами, устанавливать пакеты, смотреть процессы и читать логи. Следующий практический слой администрирования Linux — сеть: как сервер получает адрес, как диагностировать проблемы соединения, как безопасно подключаться по SSH и как ограничивать доступ с помощью firewall.

!Как SSH и сервисы проходят через firewall до служб на сервере

Базовые сетевые понятия, которые нужны администратору

IP-адрес — адрес узла в сети (IPv4 или IPv6).

Маска/префикс сети — показывает, какая часть адреса относится к сети (например, /24).

Шлюз по умолчанию — куда отправляется трафик «вне своей сети».

DNS — система, которая переводит имена (например, example.com) в IP-адреса.

Порт — логический «номер» сервиса на узле (например, SSH часто на 22/TCP).

TCP и UDP — основные транспортные протоколы; SSH почти всегда использует TCP.

Если держать в голове простую цепочку, диагностика становится проще:

«Нет IP/маршрута» — проблема на уровне интерфейса и маршрутизации.

«Есть IP, но имя не резолвится» — проблема DNS.

«Имя резолвится, но порт не доступен» — проблема firewall/службы/маршрута.

Быстрая диагностика сети: самые полезные команды

IP-адреса и интерфейсы: ip

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

Документация: ip(8) — man7.org

Проверка доступности узла: ping

ping помогает понять, «видим» ли мы узел на уровне ICMP. Важно: ICMP может быть запрещён, и тогда ping не докажет, что «всё сломано».

Документация: ping(8) — man7.org

DNS-проверки: getent

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

Проверка «порт слушается»: ss

ss показывает сокеты: какие порты открыты и какая программа их слушает.

Поля, на которые полезно смотреть:

LISTEN — сервис слушает порт.

users:(...) — какой процесс и PID держит порт.

Документация: ss(8) — man7.org

Проверка HTTP/HTTPS: curl

curl удобен для проверки доступности веб-сервисов и диагностики редиректов/сертификатов.

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

SSH: безопасный удалённый доступ

Что такое SSH и из чего он состоит

ssh — клиентская команда для подключения.

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

аутентификация — пароль или ключи.

шифрование — трафик защищён от прослушивания.

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

Подключение по SSH

Базовый вариант:

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

Ключи SSH: генерация и установка

Ключевая аутентификация безопаснее пароля при правильной настройке.

1) Сгенерировать ключ на клиенте:

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

Если ssh-copy-id недоступен, можно сделать вручную:

Важно про права:

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

файл authorized_keys обычно должен быть 600.

Если права слишком «широкие», sshd может игнорировать ключи из соображений безопасности.

Документация: ssh-keygen(1) — OpenBSD man и sshd(8) — OpenBSD man

Файл known_hosts и проверка отпечатка

При первом подключении SSH спрашивает, доверяете ли вы ключу сервера, и записывает его в ~/.ssh/known_hosts. Это защита от атаки man-in-the-middle.

Если сервер переустановили или поменяли ключи, появится предупреждение. Тогда нужно:

подтвердить, что это действительно ваш сервер (через консоль провайдера или другой доверенный канал).

затем обновить запись в known_hosts.

Пример удаления старой записи:

Документация: ssh-keygen(1) — OpenBSD man

Конфигурация клиента SSH: ~/.ssh/config

Чтобы не помнить параметры, их часто фиксируют в конфиге клиента:

Пример содержимого:

Теперь можно подключаться так:

Документация: ssh_config(5) — OpenBSD man

Настройка sshd: минимальный безопасный базис

Файл конфигурации сервера обычно здесь:

/etc/ssh/sshd_config

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

1) Оставить текущую SSH-сессию открытой. 2) Проверить синтаксис. 3) Перезагрузить службу. 4) Открыть вторую сессию и проверить вход.

Полезные команды:

На разных дистрибутивах служба может называться ssh или sshd:

Типовые настройки, которые часто применяют в серверной среде (их выбирают осознанно, под свои требования):

запрет прямого входа root: PermitRootLogin no

запрет парольной аутентификации после настройки ключей: PasswordAuthentication no

ограничение пользователей: AllowUsers alice bob

Документация: sshd_config(5) — OpenBSD man

Логи SSH и диагностика проблем входа

Если не получается войти по SSH, почти всегда ответ в логах.

Systemd-журнал:

Классические файлы логов (зависит от дистрибутива):

Связь с предыдущими темами курса прямая:

права на ~/.ssh и authorized_keys влияют на возможность входа.

sudo нужен для чтения защищённых логов и правок /etc/ssh/sshd_config.

Передача файлов по SSH: scp и sftp

scp

Документация: scp(1) — OpenBSD man

sftp

SFTP — интерактивный режим передачи файлов поверх SSH.

Документация: sftp(1) — OpenBSD man

Firewall в Linux: что именно он делает

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

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

кто может подключаться (все или конкретные IP/подсети)

Технически в Linux фильтрация реализуется подсистемой netfilter, а правила задаются через разные инструменты:

nftables (современный интерфейс)

iptables (исторический интерфейс)

ufw (упрощённая оболочка, часто в Ubuntu)

firewalld (служба с зонами, часто в RHEL/Fedora)

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

nftables wiki

firewalld documentation

UncomplicatedFirewall (Ubuntu Wiki)

Базовая стратегия правил: «запрещаем всё лишнее»

Практический минимум для сервера:

разрешить SSH (иначе вы потеряете доступ)

разрешить только те сервисы, которые реально нужны (например, 80/443 для веб-сервера)

по возможности ограничить доступ к SSH по IP (если есть фиксированные адреса администратора)

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

UFW: простой firewall (часто Ubuntu)

Проверка статуса:

Типовая базовая настройка:

Разрешение веб-трафика:

Ограничение SSH по IP:

Проверка, что правила применились:

firewalld: зоны и сервисы (часто RHEL/Fedora)

Понимание зон

firewalld работает с зонами: зона — это набор правил доверия для интерфейса. На сервере часто используется public.

Проверить состояние:

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

Разрешить SSH и HTTP/HTTPS

Разрешить временно (до перезапуска службы):

Разрешить постоянно:

Проверить результат:

Как не заблокировать себя

При работе с firewall соблюдайте дисциплину:

держите активную SSH-сессию до конца изменений

применяйте правила сначала для SSH, потом для остального

проверяйте, что служба реально слушает порт: ss -tulpen | grep ':22'

проверяйте логи при ошибках: journalctl -u ssh -b -n 200

Если вы открыли порт в firewall, но подключение не работает, частые причины:

сервис не запущен или не слушает порт

сервис слушает только 127.0.0.1, а не внешний интерфейс

подключение идёт на другой порт/адрес

внешний сетевой firewall (в облаке или на маршрутизаторе) блокирует трафик

Мини-сценарий администратора: «поднять доступ по SSH и закрыть лишнее»

Ниже — пример логики действий на новом сервере:

Проверить IP и маршрут: ip -br addr, ip route.

Убедиться, что SSH-сервис запущен: systemctl status ssh или systemctl status sshd.

Проверить, что порт 22 слушается: ss -tulpen | grep ':22'.

Настроить вход по ключу и проверить вход новым подключением.

Включить firewall и разрешить только нужные порты.

При проблемах смотреть логи SSH.

Эта последовательность связывает все предыдущие темы курса: пакеты (установить openssh-server при необходимости), процессы и systemd (статус службы), права доступа (~/.ssh), логи (journalctl), и безопасность (firewall).

Сервисы systemd, резервное копирование и автоматизация

В предыдущих статьях вы научились устанавливать пакеты, управлять процессами, читать логи, настраивать SSH и firewall. Теперь соберём это в практику эксплуатационной надёжности:

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

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

автоматизация как способ сделать задачи повторяемыми и контролируемыми

!Как systemd связывает службы, таймеры и логи

systemd: что это и почему администратору это важно

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

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

системой зависимостей (что должно стартовать раньше)

источником журналов через journald (просмотр через journalctl)

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

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

systemd(1) — документация systemd

systemctl(1) — документация systemd

systemd.unit(5) — формат unit-файлов

Основные типы unit-ов

В systemd конфигурация описывается unit-файлами. На практике чаще всего встречаются:

service: служба, которая запускает процесс(ы)

timer: расписание, которое запускает связанный service

target: «логическая цель» загрузки, объединяющая набор unit-ов

socket: активация по входящему соединению (часто в инфраструктуре, но не обязательно на старте)

> Если вы раньше «просто запускали программу и проверяли ps», то теперь вы формализуете запуск через unit и диагностируете через systemctl и journalctl.

Где лежат unit-файлы и как правильно переопределять настройки

Типовые расположения:

/usr/lib/systemd/system/ или /lib/systemd/system/ — unit-ы от пакетов (обычно не редактируют вручную)

/etc/systemd/system/ — unit-ы администратора и переопределения

Правило практики:

не правьте unit-файл пакета напрямую

используйте override через systemctl edit <unit> или кладите свой unit в /etc/systemd/system/

Команды:

daemon-reload нужен, чтобы systemd перечитал unit-файлы с диска.

Базовая работа со службами

Типовой цикл администратора:

Диагностика через логи (связь с прошлой статьёй про логи):

Как читать статус службы и находить причину падений

Полезные команды:

В systemctl status обращайте внимание на:

Active: активна ли служба

Loaded: откуда взят unit-файл

Main PID: какой PID считается основным

последние строки логов (часто уже содержат ошибку)

Практика: создать свою службу systemd для скрипта

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

был единый запуск через systemctl

логи попадали в journalctl

было понятное поведение при ошибках

Шаг 1: подготовить скрипт

Создадим простой скрипт, который пишет в лог и создаёт архив.

Пример содержимого:

Важно:

set -euo pipefail помогает «падать правильно»: при ошибке команда завершится ненулевым кодом, а systemd это увидит

бэкапы часто содержат чувствительные данные, поэтому каталог /var/backups в примере закрываем правами

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

tar — GNU tar manual

Шаг 2: описать unit типа service

Создадим unit:

Содержимое:

Пояснения к ключевым полям:

Description — описание для человека

After и Wants — порядок запуска и мягкая зависимость (в примере ждём «сеть поднялась», хотя локальный архив может и не требовать сети)

Type=oneshot — команда отрабатывает и завершается (идеально для бэкапов и админских задач)

ExecStart — что запускать

WantedBy — к какой цели привязать включение enable

Применяем:

Запуск вручную и просмотр логов:

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

systemd.service(5) — unit типа service

Автоматизация по расписанию: systemd timers

Исторически для расписаний использовали cron, но в среде с systemd часто выбирают timers, потому что:

они интегрируются со статусами и логами systemd

можно увидеть расписание через systemctl list-timers

есть опция догоняющего запуска после простоя (полезно для ноутбуков и VM)

Связка timer → service

Обычно вы создаёте два unit-а:

backup-home.service — что делать

backup-home.timer — когда делать

Создаём таймер:

Содержимое:

Пояснения:

OnCalendar=daily — простой вариант «раз в день»

Persistent=true — если система была выключена в момент запуска, таймер выполнится при следующем старте

Активируем:

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

systemd.timer(5) — unit типа timer

Резервное копирование: что именно мы защищаем

Резервное копирование в администрировании отвечает не на вопрос «как красиво сделать архив», а на вопрос:

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

Что обычно нужно бэкапить

Состав зависит от роли сервера, но часто включает:

конфигурации: /etc и конфиги сервисов (например, /etc/nginx/, /etc/ssh/)

данные приложений: /srv, /var/lib/<app>

базы данных: обычно через дампы (логически), а не копированием «как есть»

скрипты автоматизации: /usr/local/sbin, репозитории Git

Ключевые принципы хорошего бэкапа

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

разделяйте конфиги и данные: это ускоряет восстановление

контролируйте права доступа: бэкапы часто содержат секреты

ведите ротацию: храните несколько точек во времени

храните копию вне сервера: бэкап на том же диске не спасёт при отказе диска

Часто используют правило 3-2-1:

3 копии данных

2 разных типа носителя

1 копия вне основной площадки

Инструменты бэкапа: tar и rsync

tar

tar удобен для:

архивирования «среза» каталога в один файл

переноса данных

долгого хранения (особенно вместе со сжатием)

Типичный вариант:

Практические замечания:

архивируйте с правами, доступными для восстановления (иногда нужны root-права)

для больших объёмов и частых бэкапов tar может быть менее эффективен, чем инкрементальные подходы

rsync

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

Пример (локально или на внешний диск):

Пояснения:

-a включает рекурсивность и сохранение атрибутов (права, времена)

--delete удаляет на стороне назначения то, чего больше нет в источнике (опасно при ошибке пути, используйте внимательно)

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

rsync(1) — manpage на Samba

Ротация бэкапов и безопасная эксплуатация

Если вы делаете ежедневные архивы, нужен механизм очистки старых файлов.

Пример простейшей ротации: хранить только последние 14 дней:

Рекомендации по безопасности и надёжности:

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

выдавайте через sudo только необходимые команды

ограничивайте права на каталоги с архивами (700 или 750)

шифруйте копии, если они уходят во внешние хранилища

периодически делайте тестовое восстановление в отдельный каталог или на тестовую VM

Автоматизация как дисциплина: как писать админские задачи

Автоматизация в Linux обычно начинается со скрипта и заканчивается управляемым запуском через systemd.

Минимальные практики для скриптов

делайте скрипт идемпотентным, где это возможно: повторный запуск не должен ломать систему

логируйте ключевые шаги через echo (они попадут в journalctl, если запуск идёт через systemd)

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

Защита от параллельного запуска

Для задач по расписанию важно не допускать одновременных запусков (например, если бэкап идёт долго).

Один из стандартных подходов — flock.

Пример шаблона:

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

flock(1) — Linux man-pages

Диагностика автоматизации: куда смотреть

Когда «автоматизация не сработала», действуйте по цепочке из предыдущих тем курса:

Проверить таймер и его расписание

Проверить, что service запускается вручную

Посмотреть логи

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

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

Команды:

Итог

Теперь у вас есть связка практик, которая делает систему управляемой:

systemd service описывает, как запускать задачу и как её диагностировать

systemd timer заменяет «ручные напоминания» и даёт единый контроль расписаний

резервное копирование превращается из разовой команды в проверяемый процесс

автоматизация становится безопаснее за счёт логов, прав доступа и контроля параллельных запусков

Эти навыки напрямую опираются на предыдущие темы курса: права (chmod, chown), запуск с привилегиями (sudo), диагностика процессов и логов (systemctl, journalctl), а при удалённых копиях — на SSH и сетевую диагностику.