📂 Напоминалка для работы с Logical Volume Manager!

Например, lsblk помогает посмотреть структуру дисков, pvs, vgs и lvs показывают информацию о физических, групповых и логических томах, а lvextend позволяет расширить хранилище без переразметки диска.

На картинке — основные компоненты LVM: Physical Volume, Volume Group и Logical Volume, а также команды для создания, просмотра, изменения и управления дисковым пространством.

Сохрани, чтобы не потерять!

🚪 Linux Ready | #ресурс

Отслеживаем действия пользователей в Linux через auditd!

Обычная история команд в Linux не всегда помогает понять, что произошло на сервере. Файл history можно очистить, команды могут выполняться через скрипты, а некоторые действия вообще выполняются не через shell.

Для контроля изменений файлов и действий пользователей используется auditd. Он работает на уровне системного аудита и позволяет увидеть, какой процесс выполнил операцию и какой пользователь был связан с этим действием.

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

systemctl status auditd

Добавим правило для отслеживания изменений файла конфигурации SSH:

sudo auditctl -w /etc/ssh/sshd_config -p wa -k ssh_config

Параметр -w указывает файл или каталог, за которым нужно следить. Опция -p wa означает отслеживание записи в файл (w) и изменения его атрибутов (a). Ключ -k добавляет идентификатор правила, по которому потом удобно искать связанные события.

Теперь изменим файл:

vim /etc/ssh/sshd_config

И найдём связанные события аудита:

sudo ausearch -k ssh_config -i

В выводе можно увидеть информацию о процессе и пользователе:

type=SYSCALL
comm="vim"
exe="/usr/bin/vim"
uid=1000
auid=1000
success=yes

Поле exe показывает, какой процесс выполнял действие. uid показывает пользователя, от имени которого выполнялся процесс, а auid — пользователя, который изначально вошёл в систему. Это важно, потому что при использовании sudo процесс может выполняться от имени root, но исходный пользователь будет сохранён в auid.

Например:

ivan -> sudo vim /etc/ssh/sshd_config

uid=0
auid=1000

Теперь видно, что действие выполнялось с правами root, но инициировал его пользователь ivan.

Например, нужно понять, кто изменил или удалил файл приложения:

sudo auditctl -w /opt/app/config.yml -p wa -k app_config

После удаления файла:

rm /opt/app/config.yml

Проверяем событие:

sudo ausearch -k app_config -i

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

uid=deploy
auid=deploy
exe=/usr/bin/rm
success=yes

Важно понимать, что auditd записывает не историю введённых команд, а системные действия. Например, файл может удалить не только rm, но и скрипт или приложение. В журнале будет информация о фактическом процессе, который выполнил операцию.

Также можно отслеживать изменения целых каталогов. Например, контроль изменений файлов systemd:

sudo auditctl -w /etc/systemd/system -p wa -k systemd_changes

После изменения unit-файлов ищем события:

sudo ausearch -k systemd_changes -i

Для постоянного хранения правил их добавляют в конфигурацию audit:

/etc/audit/rules.d/custom.rules

Например:

-w /etc/nginx/nginx.conf -p wa -k nginx_change

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

sudo augenrules --load

Правила, созданные через auditctl, являются временными и исчезнут после перезагрузки. Файлы в /etc/audit/rules.d/ позволяют сохранить настройки постоянно.

Для современных систем также стоит учитывать, что правила через -w являются старым форматом. Более гибкий вариант — использовать syscall-based правила, например:

-a always,exit -F path=/etc/nginx/nginx.conf -F perm=wa -k nginx_change

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

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

🚪 Linux Ready | #практика

📂 Напоминалка для работы с MAC-адресами в Linux!

Например, MAC-адрес 6C:54:63:E2:31:76 состоит из 48 бит (6 байт): первые 3 байта (OUI) определяют производителя устройства, а последние 3 байта (NIC) — уникальный идентификатор сетевого интерфейса.

На картинке — структура MAC-адреса, формат записи, а также служебные биты U/L и I/G, которые определяют тип адреса и способ его назначения.

Сохрани, чтобы не потерять!

🚪 Linux Ready | #ресурс

✍️ linuxfullroadmap — пошаговый roadmap по изучению Linux!

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

Оставляю ссылочку: GitHub 📱

🚪 Linux Ready | #репозиторий

📂 Напоминалка по работе почтовых серверов!

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

На картинке — полный путь электронного письма: от поиска MX-записи в DNS, обработки сообщения на почтовом сервере, постановки в очередь до доставки получателю.

Сохрани, чтобы не потерять!

🚪 Linux Ready | #ресурс

👍 Полезная статья на Хабре: «Как я искал себе читалку и придумал новый формат электронных книг для изучающих язык»!

В этой статье:
• Автор рассказывает, почему обычные EPUB/FB2 и существующие приложения оказались неудобны для чтения книг на иностранном языке;
• Показывает идею собственного открытого формата двуязычных книг, где перевод нужного фрагмента можно получить прямо во время чтения;
• Разбирает, как с помощью LLM создавать переводы для книг и превратить обычное чтение в инструмент постоянной языковой практики.

🔊 Продолжайте читать на Habr!

🚪 Linux Ready | #статья

Как записать терминальную сессию Linux для последующего анализа с помощью script?

Во время диагностики проблемы или разбора инцидента часто нужно сохранить не только команды, но и весь процесс работы в терминале. История оболочки показывает только введённые команды, а > или tee не сохраняют полноценную интерактивную работу приложений. Для таких задач используется утилита script из пакета util-linux.

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

script session.log

После запуска открывается новая интерактивная shell-сессия через PTY, а происходящее в терминале сохраняется в файл session.log. Завершить запись:

exit

или:

Ctrl+D

Если нужно сохранить интервалы времени между действиями для последующего воспроизведения:

script --log-timing=session.time session.log

Воспроизведение:

scriptreplay --timing=session.time session.log

Это удобно для разбора ошибок, демонстрации диагностики или анализа длительных операций.

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

script \
  --log-in=input.log \
  --log-out=output.log \
  --log-timing=timing.log

Будут созданы три файла: input.log — поток ввода пользователя, output.log — вывод терминала и timing.log — временные интервалы между событиями.

Важно: --log-in сохраняет именно ввод пользователя, поэтому туда могут попасть пароли, токены и другие чувствительные данные. Если нужен только вывод терминала:

script --log-out=session.log

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

less session.log

Поиск ошибок:

grep "ERROR" session.log

Если лог содержит ANSI escape sequences или управляющие символы терминала, отображение может выглядеть некорректно. Так как script работает через PTY, это запись терминальной сессии, а не полноценный аудит действий пользователя. Для безопасности и контроля действий обычно используют специализированные инструменты, например auditd или системы session recording.

🔥 script — простой способ сохранить интерактивную терминальную сессию Linux без изменения привычного рабочего процесса. PTY позволяет получить один из самых полных вариантов сохранения контекста для анализа и разбора инцидентов.

🚪 Linux Ready | #практика

📂 Напоминалка по командам сетевой диагностики!

Например, mtr объединяет возможности ping и traceroute, позволяя анализировать маршрут и потери пакетов в реальном времени.

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

Сохрани, чтобы не потерять!

🚪 Linux Ready | #ресурс

📂 Напоминалка по инструментам для парсинга логов!

Например, grep используется для поиска по шаблонам, awk — для обработки структурированных данных, sed — для потокового редактирования текста, а jq — для анализа JSON.

На картинке — полезные консольные утилиты для поиска, фильтрации, сортировки и обработки логов, которые регулярно используются системными администраторами, DevOps-инженерами и разработчиками.

Сохрани, чтобы не потерять!

🚪 Linux Ready | #ресурс

Как namei помогает быстро найти причину Permission denied!

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

Permission denied

Смотришь на права файла — всё нормально. Меняешь владельца, проверяешь chmod — ничего не помогает. Во многих случаях проблема находится не в самом файле, а в одном из каталогов на пути к нему.

Чтобы обратиться к файлу, процесс должен иметь право прохода (x) через каждый каталог в цепочке. Именно поэтому проверка только ls -l у файла нередко ничего не показывает — проблема может быть на несколько уровней выше.

Быстро найти проблемное место помогает утилита namei. Например:

namei -l /var/www/app/storage/logs/app.log

Пример вывода:

f: /var/www/app/storage/logs/app.log
drwxr-xr-x root root     /
drwxr-xr-x root root     var
drwxr-x--- root www-data www
drwxr-xr-x app  app      app
drwx------ app  app      storage
drwxr-xr-x app  app      logs
-rw-r--r-- app  app      app.log

namei разбивает путь на отдельные компоненты и показывает права, владельца и группу для каждого каталога и самого файла. Благодаря этому не нужно вручную выполнять ls -ld для каждого каталога на пути — вся цепочка сразу перед глазами.

Но стоит помнить, что для каталогов право x означает возможность пройти через каталог и обратиться к объекту по известному имени, а не выполнить его. Поэтому даже если файл имеет права 644, процесс всё равно получит Permission denied, если хотя бы на одном из родительских каталогов отсутствует право x. Например, каталог:

drwx------ app app storage

доступен только владельцу. Поэтому процесс, запущенный от имени www-data, не сможет открыть файл внутри этого каталога, даже если сам файл доступен на чтение.

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

sudo -u www-data cat /var/www/app/storage/logs/app.log

И не забудьте проверить, от какого пользователя действительно запущен процесс, который обращается к файлу. Например, для nginx:

ps -o user,group,pid,cmd -C nginx

Если права выглядят корректными, проверьте ACL. Желательно не только у файла, но и у каталогов на пути к нему:

getfacl /var/www/app/storage
getfacl /var/www/app/storage/logs
getfacl /var/www/app/storage/logs/app.log

Если и здесь всё в порядке, обратите внимание на SELinux или AppArmor — они тоже нередко становятся причиной Permission denied.

🔥 namei -l — одна из тех команд, которые экономят много времени при поиске причин Permission denied. Вместо проверки каждого каталога вручную вы сразу видите весь путь и права доступа на каждом уровне.

🚪 Linux Ready | #практика

📂 Напоминалка по AWK для Linux!

Например, awk '{print $1}' file.txt выводит нужное поле из строки, а awk -F ":" '{print $1}' /etc/passwd позволяет работать с данными, разделёнными специальными символами.

На картинке — основные возможности AWK: встроенные переменные, операторы, функции, регулярные выражения, массивы и конструкции для обработки текста, логов и автоматизации.

Сохрани, чтобы не потерять!

🚪 Linux Ready | #ресурс

Можно открыть упавшее приложение в GDB спустя несколько дней, даже если вы не запускали его под отладчиком!

Многие воспроизводят падение заново, чтобы получить стек вызовов. Но если система использует systemd-coredump и core dump сохранился, вся необходимая информация для анализа может уже быть в системе.

Достаточно выполнить:

coredumpctl debug myapp

или указать PID:

coredumpctl debug 18432

coredumpctl найдёт нужный core dump, запустит GDB и подключит соответствующий исполняемый файл. Если доступны подходящие отладочные символы, вы сможете сразу приступить к анализу.

Можно посмотреть историю падений:

coredumpctl list

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

🔥 Если на машине используется systemd-coredump, возможно, всё необходимое для отладки уже сохранено в системе.

🚪 Linux Ready | #совет

😍 Linux Roadmap — большая подборка материалов для изучения Linux и DevOps!

Здесь собраны книги, курсы и практические руководства по Linux, Bash, командной строке, обработке текста, Docker, systemd, Kubernetes, Python, Vim и Git. Поможет разобраться не только с базовыми командами, но и с инструментами, которые используются в реальной работе разработчиков, DevOps-инженеров и системных администраторов.

Оставляю ссылочку: GitHub 📱

🚪 Linux Ready | #репозиторий

📂 Напоминалка по JWT-токенам и API-ключам!

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

На картинке — сравнение двух популярных способов доступа к API: JWT-токены для управления сессиями и API-ключи для взаимодействия между сервисами.

Сохрани, чтобы не потерять!

🚪 Linux Ready | #ресурс

Отредактировали системный файл в Vim и только при сохранении обнаружили, что не хватает прав на запись?

Закрывать редактор, терять изменения и заново открывать файл через sudo не требуется.

Из Vim выполните:

:w !sudo tee % >/dev/null

:w ! команда передаёт текущее содержимое буфера во внешнюю команду через стандартный ввод. % подставляется Vim как имя текущего файла, а sudo tee записывает полученные данные уже с повышенными правами.

После этого перечитайте файл с диска:

:e!

Запись выполнил внешний tee, а не сам Vim, поэтому редактор может продолжать считать свой буфер изменённым.

🔥 При необходимости можно сохранить права и владельца существующего файла, поскольку tee открывает сам файл для перезаписи, а не создаёт новый через временный файл и rename.

🚪 Linux Ready | #совет

Резервное копирование Linux-сервера через rsync с сохранением прав и атрибутов!

Для многих задач резервного копирования Linux-серверов не нужны сложные системы. rsync позволяет быстро синхронизировать данные, передавая только изменившиеся файлы и сохраняя права доступа, владельцев, группы, символические ссылки, время изменения, ACL и расширенные атрибуты.

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

rsync -av /data/ /backup/data/

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

rsync -aHAX /srv/ /backup/srv/

Ключ -a сохраняет структуру каталогов, права, владельцев, группы, время изменения и символические ссылки. -H сохраняет жёсткие ссылки, -A переносит ACL, а -X сохраняет расширенные атрибуты.

При переносе между серверами важно сохранить исходные UID и GID, чтобы права доступа остались корректными:

rsync -aHAX --numeric-ids -e ssh /srv/ backup@10.0.0.20:/backup/server/

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

rsync -aHAX --delete --dry-run --itemize-changes /srv/ /backup/srv/

rsync часто применяется для миграции серверов и переноса больших объёмов данных через SSH:

rsync -aHAX -e ssh /srv/ backup@server:/backup/

Если канал передачи ограничен по скорости, можно задать максимальную пропускную способность:

rsync -aHAX --bwlimit=50M /srv/ backup@server:/backup/

При передаче больших файлов после разрыва соединения можно сохранить частично переданные данные:

rsync -aHAX --partial --progress /images/ backup@server:/backup/images/

Параметр --append-verify следует использовать осторожно. Он подходит для случаев, когда файл только дописывается и не изменяется в уже записанной части.

Для создания нескольких ежедневных копий часто используют --link-dest. Неизменившиеся файлы будут представлены жёсткими ссылками и не займут дополнительное место:

rsync -aHAX --link-dest=/backup/latest /data/ /backup/$(date +%F)/

Пример структуры хранения:

/backup/
├── 2026-08-13/
├── 2026-08-14/
├── 2026-08-15/
└── latest -> 2026-08-15/

После создания новой копии ссылку latest обычно обновляют на последний каталог.

При резервном копировании всей системы обычно исключают виртуальные файловые системы Linux:

rsync -aHAX \
--exclude=/proc \
--exclude=/sys \
--exclude=/dev \
--exclude=/run \
/ /backup/system/

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

Автоматический запуск можно настроить через cron:

0 3 * * * /usr/bin/rsync -aHAX --delete --log-file=/var/log/rsync-backup.log /srv/ /backup/srv/

Проверить различия между источником и копией без изменения данных можно через --dry-run:

rsync -aHAX --dry-run /srv/ /backup/srv/

Для проверки содержимого через контрольные суммы используется параметр --checksum:

rsync -aHAX --checksum --dry-run /srv/ /backup/srv/

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

rsync хорошо подходит для миграции серверов, синхронизации каталогов и создания файловых резервных копий. Однако это инструмент синхронизации, а не полноценная backup-система.

🔥 Он не гарантирует согласованное состояние работающих баз данных. Для MySQL, PostgreSQL и других сервисов обычно используют дампы, snapshots файловой системы или предварительную остановку приложения перед копированием. Надёжность резервной копии определяется не фактом её создания, а успешным восстановлением из неё.

🚪 Linux Ready | #практика