Командная строка Linux по-прежнему основной инструмент работы с серверами. Даже при Ansible, Terraform или панели управления рано или поздно приходится заходить по SSH и разбираться руками. Ниже — рабочая шпаргалка: команды, которые чаще всего нужны при администрировании, настройке Nginx, WordPress-хостов и повседневных задачах DevOps на Debian и Ubuntu.
Это не полный man и не учебник с нуля. Только то, что реально применяют на практике: с пояснениями, где обычно ломается, и как быстро проверить результат.
Основные понятия
Большинство команд выполняется в bash. История команд сохраняется, Tab ускоряет ввод. Права зависят от текущего пользователя. Для системных изменений почти всегда нужен sudo.
Перед правками конфигурации или прав доступа имеет смысл сделать резервную копию. Особенно это касается /etc и важных директорий сайтов.
Пользователи и группы
Создание пользователей и управление группами — базовая операция при настройке серверов для деплоя, разработчиков или изоляции сервисов.
Создать пользователя:
sudo adduser username
Команда интерактивно запросит пароль и дополнительную информацию. На Debian/Ubuntu это предпочтительнее useradd: сразу создаётся домашняя директория и копируется скелет.
Пример:
sudo adduser deploy
Добавить пользователя в группу (например, sudo или docker):
sudo usermod -aG groupname username
Флаг -a обязателен, иначе пользователь будет удалён из остальных групп.
Пример:
sudo usermod -aG sudo deploy
Проверить группы пользователя:
groups username id username
Удалить пользователя (домашнюю директорию по умолчанию не трогает):
sudo deluser username
Чтобы удалить и home:
sudo deluser --remove-home username
На практике после добавления в sudo или docker часто нужно перелогиниться, чтобы группы применились.
Файлы, права и поиск
Большинство проблем с сайтами и сервисами начинается с прав доступа. Особенно часто это встречается при работе с WordPress, Nginx и директориями загрузок.
Посмотреть содержимое с правами:
ls -la
Изменить владельца:
sudo chown -R user:group /path/to/dir
Изменить права (символьный способ обычно понятнее):
chmod u+rwx,g+rx,o-rwx file_or_dir
Числовой:
chmod 750 file_or_dir
Рекурсивно по директории:
chmod -R 755 /path/to/dir
Осторожно с 777: на проде это почти всегда плохая идея.
Найти файлы:
find /path -name "*.log"
Найти и выполнить действие:
find /var/www -type f -name "*.php" -exec chmod 644 {} \;
Поиск по содержимому:
grep -r "search_string" /path
Размер директорий:
du -sh /path/*
Где обычно ломается: неправильный владелец после rsync или git pull, слишком открытые права на wp-config.php, забытый sticky bit или ACL. Проверить можно через ls -la и namei -l /полный/путь.
Диски, разделы и файловые системы
Перед любыми операциями с дисками сначала смотрите, что реально подключено и сколько места осталось. Ошибка в точке монтирования или форматировании может стоить данных.
Список блочных устройств:
lsblk -f
Показывает диски, разделы, файловые системы и точки монтирования. Флаг -f добавляет UUID и тип ФС — удобно при настройке fstab.
Свободное место:
df -h
Человекочитаемый вывод. Если корень или /var заполнены под 100%, сервисы начинают падать самым неожиданным образом.
Что занимает место в конкретной директории:
du -sh /var/log/* | sort -h
Быстро находит тяжёлые каталоги. Часто виноваты старые логи, кэши или забытые бэкапы.
Монтирование:
sudo mount /dev/sdb1 /mnt/backup
Перед этим убедитесь, что точка монтирования существует (mkdir -p). После работы всегда размонтируйте:
sudo umount /mnt/backup
Если устройство «занято», поможет lsof +f -- /mnt/backup или fuser -vm /mnt/backup. В fstab лучше указывать UUID, а не /dev/sdX: имена устройств могут меняться.
Где обычно ломается: забыли размонтировать перед отключением диска, указали неверный UUID в fstab, не хватило места на / во время apt upgrade или сборки.
Архивы, бэкапы и синхронизация
В повседневной работе чаще всего нужны tar и rsync. scp удобен для разовой передачи, rsync — когда нужно синхронизировать и экономить трафик.
Создать сжатый архив:
tar -czvf project_backup_$(date +%F).tar.gz /home/devuser/project
Флаги: c — создать, z — gzip, v — verbose, f — файл. Дата в имени спасает от перезаписи.
Распаковать:
tar -xzvf project_backup_2026-07-30.tar.gz -C /target/directory
Синхронизация через rsync (локально или по SSH):
rsync -avz --progress --delete --exclude='.git' /local/path/ user@remote:/remote/path/
-a сохраняет права и времена, -z сжимает, --delete удаляет на приёмнике то, чего нет в источнике (осторожно), --exclude пропускает ненужное. Для деплоя статики или бэкапа конфигов — один из самых удобных инструментов.
Простая передача файла через scp:
scp -r ./config/ user@server:/etc/nginx/sites-available/
Где ломается: rsync с --delete без проверки (можно потерять данные), неправильные права после распаковки tar, забытый trailing slash в путях rsync (меняет поведение).
Управление пакетами
Примеры ниже для Debian/Ubuntu (apt). На RHEL/CentOS/Alma/Rocky используйте dnf или yum — логика похожа.
Обновить индексы и систему:
sudo apt update && sudo apt upgrade
Перед крупным upgrade полезно глянуть df -h и сделать снимок или бэкап критичных конфигов.
Установить пакет:
sudo apt install nginx
Удалить пакет (оставить конфиги):
sudo apt remove nginx
Удалить вместе с конфигами и неиспользуемыми зависимостями:
sudo apt purge nginx && sudo apt autoremove
Посмотреть информацию о пакете и доступные версии:
apt policy nginx apt show nginx
Перед установкой из стороннего репозитория всегда проверяйте, откуда пакет и какие зависимости он тянет. После удаления сервиса не забывайте про оставшиеся unit-файлы и логи.
Процессы и ресурсы
Когда сервер начинает тормозить или сервис зависает, первым делом смотрят на процессы и потребление ресурсов.
Интерактивный просмотр процессов:
top
Обновляется каждые несколько секунд. Показывает CPU, память и список процессов. Для более удобного интерфейса обычно ставят htop:
sudo apt install htop htop
Список процессов:
ps aux | grep nginx pgrep -a nginx
Завершение процесса:
kill PID kill -9 PID
Сначала пробуйте обычный kill (SIGTERM). kill -9 — крайняя мера: процесс не успевает корректно завершиться. На практике лучше сначала понять, почему он завис.
Память и uptime:
free -h uptime
free показывает использование RAM и swap. uptime — как давно система работает и среднюю нагрузку.
Статистика:
vmstat 1 iostat -xz 1
Полезно, когда нужно понять, упирается ли система в диск или CPU. iostat часто требует пакета sysstat.
Сеть
Основные инструменты для проверки интерфейсов, маршрутов и открытых портов.
Интерфейсы и адреса:
ip addr show ip a
ifconfig ещё встречается, но считается устаревшим. Предпочтительнее ip.
Маршруты:
ip route ip r
Открытые порты и соединения:
ss -tulpn
Показывает, какие процессы слушают порты. netstat -plntu делает похожее, но ss быстрее и современнее.
Проверка доступности:
ping -c 4 8.8.8.8 curl -I https://example.com traceroute example.com
Для более информативной трассировки удобен mtr (нужно установить).
Где обычно ломается: забыли открыть порт в firewall, сервис слушает только 127.0.0.1, неправильный DNS.
Systemd и управление сервисами
Почти все современные дистрибутивы используют systemd. Это основной способ управлять службами.
Базовые действия:
sudo systemctl start nginx sudo systemctl stop nginx sudo systemctl restart nginx sudo systemctl reload nginx sudo systemctl status nginx
reload обычно мягче, чем restart: перечитывает конфиг без полного останова (если сервис это поддерживает).
Автозапуск:
sudo systemctl enable nginx sudo systemctl enable --now nginx sudo systemctl disable nginx
После изменения unit-файлов:
sudo systemctl daemon-reload sudo systemctl restart имя-сервиса
Полезные проверки:
systemctl list-units --failed systemctl is-active nginx systemctl cat nginx systemctl edit nginx
edit создаёт drop-in override и не трогает оригинальный файл пакета. Это правильный способ кастомизации.
Типичная ошибка — изменить unit и забыть daemon-reload. Сервис продолжает работать со старой конфигурацией.
Логи и диагностика
Когда что-то не работает, логи — первое место, куда стоит смотреть. В systemd-системах основной инструмент — journalctl.
Логи конкретного сервиса:
journalctl -u nginx journalctl -u nginx -f journalctl -u nginx -xe journalctl -u nginx --since "1 hour ago"
-f работает как tail -f. -xe показывает больше деталей и пояснений.
Системные логи за текущую загрузку:
journalctl -b dmesg | tail
Классические файлы логов:
tail -f /var/log/syslog tail -f /var/log/nginx/error.log tail -n 100 /var/log/auth.log
Для поиска по логам удобен grep:
grep -i error /var/log/nginx/error.log journalctl -u php8.3-fpm | grep -i fatal
На практике часто комбинируют: сначала status сервиса, потом journalctl -xe, потом конкретный лог приложения. Если место на диске заканчивается, journald может перестать писать — проверяйте df -h /var.
Безопасность: UFW и SSH
Минимальный набор, который стоит настроить почти на любом сервере.
UFW (Uncomplicated Firewall):
sudo ufw allow 22/tcp sudo ufw allow 80/tcp sudo ufw allow 443/tcp sudo ufw enable sudo ufw status verbose
Перед enable всегда проверяйте, что SSH-порт разрешён, иначе можно потерять доступ.
SSH-ключи:
ssh-keygen -t ed25519 -C "your_email@example.com" ssh-copy-id user@server
ed25519 предпочтительнее rsa. После копирования ключа можно отключать парольный вход в sshd_config (PasswordAuthentication no), но только когда ключ точно работает.
Дополнительно в /etc/ssh/sshd_config часто меняют:
PermitRootLogin no PasswordAuthentication no
После правок:
sudo systemctl reload sshd
или ssh. Имя сервиса зависит от дистрибутива.
Не отключайте firewall и не открывайте всё подряд «на время». Обычно «на время» остаётся навсегда.
Автоматизация и полезные привычки
Рутину лучше автоматизировать. Даже простые вещи вроде бэкапов и очистки логов экономят время и снижают риск ошибки.
Планировщик cron:
crontab -e
Пример ежедневного бэкапа в 2:00:
0 2 * * * /home/deploy/scripts/backup.sh >> /var/log/backup.log 2>&1
Скрипт лучше писать с set -euo pipefail в начале, чтобы он останавливался при ошибках. Для системных задач иногда удобнее systemd timers: они лучше интегрируются с journald.
Алиасы:
echo "alias ll='ls -la'" >> ~/.bashrc source ~/.bashrc
Полезные приёмы в bash:
Ctrl+R — поиск по истории. !! — повторить последнюю команду. sudo !! — повторить с sudo.
Для долгих процессов используйте tmux или screen. Это позволяет не терять сессию при разрыве SSH.
tmux new -s work # Detach: Ctrl+B, затем D tmux attach -t work
Перед изменением важных конфигов всегда делайте копию:
sudo cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak.$(date +%F)
И проверяйте конфигурацию перед применением (nginx -t, apachectl configtest и т.д.).
Полезные привычки:
- Перед изменением конфига — копия с датой.
- После правок nginx/apache — сначала проверка синтаксиса.
- Длинные операции запускать в tmux или screen.
- Не работать постоянно под root. sudo достаточно.
- Проверять место на диске перед массовыми операциями.
Короткий вывод
Командная строка Linux — повседневная рабочая среда, а не архаика. Чем лучше известны базовые команды и типичные места поломок, тем быстрее закрываются инциденты. Сохраните шпаргалку, дополняйте своими примерами и проверяйте команды на тестовых машинах, прежде чем применять на проде.