💡 Полезные Советы

systemd - это система инициализации и управления службами в Linux. Основная утилита для взаимодействия с ней - systemctl. С её помощью мы запускаем веб-серверы, базы данных, ботов и настраиваем их автозагрузку.

Примечание.

systemd - это центральный механизм, который отвечает за запуск Linux после включения компьютера и за управление всеми службами (демонами), работающими в системе.
Когда Linux загружается, именно systemd:
•     запускает сетевые службы
•     поднимает базы данных
•     стартует веб‑серверы
•     следит за зависимостями
•     перезапускает упавшие процессы
•     управляет логами
Чтобы взаимодействовать с systemd, используется команда systemctl - это как "пульт управления" всеми службами.

В командах ниже замените name на имя вашей службы (например, nginx, docker, postgresql или my-bot).

1. Управление состоянием (прямо сейчас)

Базовые команды для включения и выключения.

Примечание.

Не обязательно писать .service в конце имени (например, можно писать sudo systemctl start nginx вместо nginx.service).

2. Автозагрузка (при включении ПК)

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

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

Если что-то сломалось, эти команды помогут понять, где именно.

• systemctl --failed Показать список всех служб, которые упали с ошибкой. С этого стоит начинать починку системы.

• systemctl list-units --type=service Показать вообще все активные службы в системе.

В Linux нет дисков C: или D:. Есть только один корень - /. Все остальные диски, флешки и устройства подключаются как папки в эту структуру.

Шпаргалка

1. Самое важное для запуска

• /boot - сердце загрузки. Здесь живет ядро Linux (vmlinuz) и загрузчик GRUB. Если удалить - система не встанет.

• /bin и /sbin - здесь живут команды.

  • В /bin - общие (типа ls, cat), доступные всем.

  • В /sbin - для админа (типа fdisk, iptables), нужны права root.

• /lib - библиотеки, без которых программы из папок выше не запустятся (аналог .dll в Windows).

2. Пользователи и настройки

• /home - ваши личные файлы. Аналог C:\Users.

• /root - личная комната Администратора. Она отделена от /home, чтобы, если раздел с пользователями забьется или сломается, админ все равно мог войти в систему.

• /etc - пульт управления. Здесь лежат текстовые файлы с настройками всей системы (сеть, fstab, конфиги программ).

3. Софт и приложения

• /usr - (Unix System Resources). Самая большая папка. Здесь лежат установленные программы (/usr/bin), их библиотеки (/usr/lib) и документация. По сути, это аналог Program Files.

• /opt - для "большого" стороннего софта, который ставится одним куском (например, Google Chrome, Telegram, проприетарные базы данных).

4. Данные и временные файлы

• /var - (Variable). Всё, что постоянно меняется: логи системы (/var/log), кэш, очереди печати, файлы веб-сайта (/var/www).

• /tmp - временная свалка. Очищается при каждой перезагрузке. Не храните здесь ничего важного!

5. Устройства и Система

• /dev - в Linux всё есть файл, даже ваше "железо". Жесткий диск - это файл (/dev/sda), терминал - файл.

• /proc - это иллюзия. Файлов там на самом деле нет, это интерфейс к ядру. Через эту папку можно посмотреть информацию о процессоре (/proc/cpuinfo) или памяти.

FAQ: В чем разница между /mnt и /media?

Частый вопрос новичков.

• /media - система использует сама. Вставили флешку - она появилась тут автоматически.

• /mnt - для ручной работы. Админ использует её, чтобы временно подключить диск для восстановления или настройки.

Полезный совет

Если вы забыли, для чего нужна папка, в Linux есть встроенная справка. Просто введите в терминале: man hier (от слова hierarchy) - и получите подробнейшее описание стандарта файловой системы.

Прописывать разрешение именно через cmdline.txt имеет смысл, если вы используете современные версии Ubuntu с драйверами KMS (Kernel Mode Setting), и стандартные настройки в config.txt игнорируются системой. Это заставляет ядро Linux принудительно использовать указанный режим.

Вставьте SD-карту в компьютер, откройте раздел boot (или system-boot) и найдите файл cmdline.txt.

В конец той же самой единственной строки (через пробел) нужно добавить команду в формате: video=<Port>:<Resolution>@<RefreshRate><Option> например:

video=HDMI-A-1:1920x1080@60D

Для Raspberry Pi 4 и 5 (порт возле питания - HDMI-1):

HDMI-A-1 - имя порта (для первого micro-HDMI).

1920x1080 - разрешение.

@60 - частота обновления.

D - важный флаг (Digital), который принудительно включает выход, даже если монитор не распознан (нет EDID). Полезно при переходниках, KVM, старых мониторах, телевизорах.

Вы наверняка сталкивались с этой классической ошибкой новичка. Вы пытаетесь добавить строку в конфиг, но получаете Permission denied, даже используя sudo.

Как делать не надо

Допустим, мы хотим добавить репозиторий:

sudo echo "deb http://nginx.org/packages/mainline/ubuntu/ jammy nginx" >> /etc/apt/sources.list.d/nginx.list

Результат: bash: /etc/apt/sources.list.d/nginx.list: Permission denied

Почему так происходит?

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

1. Оболочка сначала обрабатывает оператор >>.
2. Именно оболочка (bash/zsh), а не sudo, пытается открыть файл на запись.

3. Оболочка запущена от вашего текущего пользователя (не root), поэтому прав на запись нет.

4. Команда sudo применяется только к echo, но не к самому процессу записи в файл.

Решение: Команда tee

Используйте утилиту tee. Она читает данные из стандартного ввода и записывает их в файл, при этом выводя их на экран.

Правильный синтаксис:

echo "Hello world" | sudo tee -a /tmp/testfile.txt

• | (пайп) передает текст команде справа.

• sudo запускает tee с правами суперпользователя.

• -a (append) - критически важный флаг. Он добавляет текст в конец файла. Без него tee перезапишет файл целиком!

Мини-демонстрация

Попробуем на безопасном примере:

# Пишем
echo "Hello world" | sudo tee -a /tmp/testfile.txt

# Проверяем
cat /tmp/testfile.txt

Вывод: Hello world

Продвинутый уровень: Полезные сценарии

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

1. Безопасное добавление нескольких строк (Here-Doc)

Если нужно записать целый блок конфига, не нужно делать десять echo. Используйте конструкцию EOF в связке с tee:

cat <<EOF | sudo tee -a /etc/sysctl.conf
# Улучшение сетевых настроек
net.ipv4.tcp_window_scaling = 1
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
EOF

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

2. Удаление или замена строк (sed)

Для удаления строк перенаправление не нужно, так как sed умеет редактировать файлы "на месте" (in-place).

Удалить конкретную строку (например, с ошибочным репозиторием):

# Удаляет все строки, содержащие "google-chrome"
sudo sed -i '/google-chrome/d' /etc/apt/sources.list

Заменить одно значение на другое:

# Заменяет "PermitRootLogin yes" на "PermitRootLogin no"
sudo sed -i 's/PermitRootLogin yes/PermitRootLogin no/' /etc/ssh/sshd_config

Важно: Флаг -i изменяет исходный файл. Всегда делайте бэкап перед запуском!

3. Обработка данных и запись в защищённый файл (ss + awk + tee)

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

Пример: Сохранить список портов, на которых слушают сервисы.

# awk фильтрует данные, а tee записывает их с правами root
ss -tuln | awk '/LISTEN/ {print $5}' | sudo tee /var/log/active_ports.log > /dev/null

Заметка: > /dev/null в конце нужен, если вы не хотите, чтобы tee дублировал результат вам в консоль.

4. Как делать бэкап "на лету"

При изменении конфигов через sed или tee хорошим тоном считается создание резервной копии.

С sed это очень просто - добавьте расширение после флага -i:

# Создаст файл /etc/hosts.bak перед изменением
sudo sed -i.bak 's/old-ip/new-ip/' /etc/hosts

Где это пригодится?

• Apt: Добавление репозиториев в /etc/apt/sources.list.d/

• Config: Изменение настроек в /etc/nginx/, /etc/apache2/

• System: Тюнинг ядра в /etc/sysctl.conf

• Security: Добавление лимитов в /etc/security/limits.conf

• Keys: Запись бинарных ключей: cat key.gpg | sudo tee /usr/share/keyrings/app.gpg

Частая ситуация: вы настраиваете свежий сервер на AlmaLinux, Rocky Linux или RHEL, пытаетесь установить привычные утилиты (например, ncdu для анализа диска или htop), но получаете ошибку:

Error: Unable to find a match: ncdu

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

Почему ncdu "нет" в AlmaLinux?

На самом деле ncdu существует и отлично работает на этих системах. Проблема кроется в философии RHEL-подобных дистрибутивов:

1. Минимализм базы: Официальные репозитории (BaseOS, AppStream) содержат только самый необходимый и максимально стабильный софт, поддерживаемый вендором.

2. Сообщество: Большинство "удобных" инструментов администрирования (ncdu, htop, nload, jq, screen) вынесены в отдельный репозиторий - EPEL (Extra Packages for Enterprise Linux).

3. Результат: Пока EPEL не подключен, пакетный менеджер просто не видит эти программы.

Решение: Подключение EPEL

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

1. Устанавливаем репозиторий EPEL:

sudo dnf install epel-release -y

2. Обновляем кэш (необязательно, но полезно):

sudo dnf makecache

3. Устанавливаем ncdu: Теперь команда сработает без ошибок:

sudo dnf install ncdu -y

Как проверить, что всё получилось?

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

dnf info ncdu

В выводе вы увидите строку Repository : epel и версию программы (например, 1.17 или новее).

Совет

Если вы часто настраиваете серверы, добавьте установку epel-release в свой базовый скрипт первоначальной настройки. Это сэкономит время при установке большинства популярных утилит для мониторинга и администрирования.

Коротко: большинство экспертов рекомендуют менять SSH‑ключи раз в 6 - 12 месяцев, но частота зависит от уровня риска и требований безопасности. Современные рекомендации подчёркивают, что ключи нельзя оставлять "вечными", потому что со временем они превращаются в скрытый риск для инфраструктуры.

1. Для личных проектов и своего сервера

Рекомендуемая частота: Раз в 1 год (или даже реже).

Для личного использования (если вы единственный администратор) частая смена ключей может создать больше проблем, чем пользы (например, риск потерять доступ при неправильной замене). Главное правило: Меняйте ключ немедленно, если:

• Вы потеряли ноутбук или флешку с ключом.

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

• Вы случайно "засветили" приватный ключ (выложили на GitHub, отправили в чат и т.д.).

2. Для работы и продакшна (Лучшая Практика)

Рекомендуемая частота: Раз в 3-6 месяцев.

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

• Стандарт PCI DSS (для работы с картами), из-за него многие корпоративные регламенты требуют ротацию каждые 90 дней (корпоративной среде существует огромная разница между "что написано в стандарте" и "что требуют аудиторы / безопасники на местах".)

• Это защищает от сценария, когда ключ был украден тихо (без вашего ведома) и злоумышленник использует его месяцами.

PCI DSS (Payment Card Industry Data Security Standard) - это "золотой стандарт" безопасности для любой организации, которая хранит, обрабатывает или передает данные банковских карт (Visa, Mastercard, МИР).

SSH - это главная дверь для управления сервером. Если ваш сервер имеет отношение к платежам или картам, то настройки SSH становятся объектом пристального внимания аудиторов PCI DSS.

Даже если вы не банк, требования PCI DSS полезно знать, потому что это готовая инструкция "как сделать действительно безопасно".

1. Запрет прямого входа root (Требование 8.6)

• Что требует стандарт: Каждое действие на сервере должно быть привязано к конкретному человеку. Если все заходят под общим логином root, то в логах будет видно «root удалил базу данных», но непонятно, кто именно это был - Вася или Петя.

• Ваша ситуация: Вы только что создали личного пользователя (h...) и отключили PermitRootLogin. Это полное соответствие стандарту. Теперь в логах будет видно: "Пользователь h... повысил права до root и удалил базу".

2. Запрет простых паролей и использование криптографии (Требование 2.3)

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

• Ваша ситуация: SSH сам по себе шифрует трафик. А отключение входа по паролю (PasswordAuthentication no) и переход на ключи - это лучшая практика (Best Practice), которую аудиторы очень любят.

3. Регулярная смена ключей (Требование 3.6.4)

• Что требует стандарт: Криптографические ключи (Ключи шифрования данных (Data Encryption Keys)) должны меняться по расписанию (обычно каждые 90 дней), а старые - уничтожаться.

• Что это: Это ключи, которыми шифруется сама база данных с номерами карт. Если хакер украдет этот ключ и дамп базы, он сможет прочитать номера карт.

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

4. Не использовать "дефолтные" настройки (Требование 2.1)

• Что требует стандарт: Нельзя использовать пароли и настройки, которые идут "из коробки" (vendor-supplied defaults).

• Ваша ситуация: Вы уже изменили порт (если меняли?), отключили рута, создали своего юзера. Вы уже не используете дефолт.

Стандарт PCI DSS настоятельно рекомендует (а версия 4.0 требует) двухфакторную аутентификацию (MFA) даже для администраторов. PCI DSS не предписывает конкретный метод, например "SSH‑ключ + код Google Authenticator". Он требует наличия MFA, а конкретная реализация остаётся на усмотрение организации!

3. Критические ситуации (Менять немедленно)

В этих случаях расписание не имеет значения - нужно действовать сразу:

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

2. Скомпрометированное устройство. Логика "я почистил компьютер антивирусом, значит всё в порядке" здесь не работает. Вирусы (трояны, стилеры) настроены искать именно файлы в папке .ssh. Как только вирус попадает на компьютер, он мгновенно копирует эти файлы и отправляет их злоумышленнику. Вы можете возразить: "Но у меня ключ защищен паролем (passphrase)!". Если устройство скомпрометировано, скорее всего, на нем работал кейлоггер (программа, записывающая нажатия клавиш). Когда вы вводили пароль, чтобы разблокировать ключ, хакер получил и файл ключа, и пароль к нему.

3. Смена алгоритмов шифрования. Если вы использовали старые ключи RSA-1024 или DSA (которые сейчас считаются слабыми), их нужно срочно заменить на современные Ed25519 или RSA-4096.

Частая ошибка при обновлении

Многие думают, что создание нового ключа автоматически отменяет старый. Это не так. SSH-сервер пускает по списку ключей. Если вы добавите новый ключ, но забудете удалить строку со старым ключом из файла ~/.ssh/authorized_keys, то старый ключ продолжит работать.

Правильный алгоритм ротации:

1. Сгенерировать новую пару ключей (ssh-keygen -t ed25519).

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

3. Проверить вход с новым ключом.

4. Удалить старый публичный ключ из файла authorized_keys на сервере.

5. Удалить старый приватный ключ с локального компьютера.