DevOps Ready | IT

Разрежённые файлы (sparse files) и экономия диска!

В Linux файл может иметь логический размер, превышающий фактически занятое место на диске. Незаписанные области представлены как дыры (holes) и физически места не занимают.

Создание файла большого размера без записи данных:

truncate -s 10G bigfile.img

Файл имеет логический размер 10G, но почти не занимает место на диске.

Проверка:

ls -lh bigfile.img
du -h bigfile.img

ls показывает логический размер файла, du — реально занятое дисковое пространство.

Создание sparse-файла через dd:

dd if=/dev/zero of=bigfile.img bs=1 count=0 seek=10G

Смещение файлового офсета устанавливается на 10G без записи данных — создаётся файл с дырой.

Частичная запись данных:

printf 'DATA' | dd of=bigfile.img bs=1 seek=1G conv=notrunc

Физически будет занят только небольшой участок около 1G, остальное останется дырами.

Просмотр расположения данных:

filefrag -v bigfile.img

Показывает, какие диапазоны файла реально занимают блоки на диске (для классических FS вроде ext4/xfs).

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

fallocate -d bigfile.img

Точечное выбивание физических блоков с сохранением логического размера:

fallocate --punch-hole --offset 1G --length 500M --keep-size bigfile.img

Корректное копирование sparse-файлов:

cp --sparse=always src.img dst.img

Для архивов:

tar --sparse -cf backup.tar bigfile.img

Важно: поддержка sparse-файлов и hole punching зависит от файловой системы и её конфигурации (ext4, xfs — поддерживают).

🔥 Sparse-файлы — базовый механизм экономии диска для образов, дампов и крупных артефактов.

➡️ DevOps Ready | #практика

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

Например, Reflected XSS выполняется сразу после перехода по вредоносной ссылке, а Stored XSS сохраняется в базе и срабатывает у всех пользователей.

На картинке — 3 основных типа XSS, которые важно различать при разработке и ревью кода.

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

➡️ DevOps Ready | #ресурс

Скрипт с автозапуском: чтобы не забыть — автоматизируй!

Хочешь, чтобы скрипт сам запускался при включении Linux? Например, для логирования, запуска сервисов или отправки уведомлений. Сделать это можно через systemd — просто, нативно и надёжно.

Сначала создаём bash-скрипт, который будет выполняться при загрузке. Пусть он, например, записывает время старта в лог-файл:

#!/bin/bash
echo "Система запущена: $(date)" >> /var/log/boot-script.log

Сохрани его как /usr/local/bin/boot-script,sh и сделай исполняемым:

chmod +x /usr/local/bin/boot-script.sh

Теперь создаём unit-файл systemd:
/etc/systemd/system/boot-script.service

[Unit]
Description=Мой автозапускаемый скрипт
After=network.target
[Service]
ExecStart=/usr/local/bin/boot-script.sh
Type=oneshot
[Install]
WantedBy=multi-user.target

After=network.target означает, что скрипт выполнится только после запуска сети.

Тип oneshot говорит, что это однократное выполнение.

А WantedBy=multi-user.target позволяет запустить скрипт при входе в основную многопользовательскую среду (то есть обычная загрузка без GUI).

Осталось активировать сервис:

sudo systemctl daemon-reexec
sudo systemctl enable boot-script.service
sudo systemctl start boot-script.service

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

cat /var/log/boot-script.log

🔥 Удобно, если хочешь автоматизировать повседневные задачи — без crontab и лишних костылей.

➡️ DevOps Ready | #практика

😎 Linux/DevOps Interview Questions — вопросы для подготовки к собеседованиям!

Отличный репозиторий с реальными вопросами, которые проверяют знания Linux и DevOps. Здесь есть вопросы по командам, процессам, файловым системам, сетям, bash и другим темам, которые часто встречаются в задачах и на собеседованиях.

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

➡️ DevOps Ready | #ресурс

Выдача бинарникам точечных привилегий через setcap!

Иногда программе нужен root только для одной операции (bind к 80 порту, raw socket, cap_sys_ptrace). Для этого в Linux есть capabilities — они управляются через setcap.

Проверка capabilities у исполняемого файла:

getcap /usr/bin/ping

Типичный вывод:

/usr/bin/ping cap_net_raw=ep

В современных дистрибутивах ping часто не setuid-root, а работает через capabilities, получая доступ к raw socket.

Пример: разрешить бинарнику слушать порт <1024 без root:

sudo setcap cap_net_bind_service=ep ./server

Теперь запуск возможен от обычного пользователя:

./server

Bind к :80 будет работать без sudo.

Проверка назначенных capabilities:

getcap ./server

Удаление capabilities у бинарника, если нужно полностью убрать выданные ранее права и вернуть его в обычное состояние:

sudo setcap -r ./server

Несколько capabilities сразу, если бинарнику требуется больше одного привилегированного действия:

sudo setcap cap_net_bind_service,cap_sys_time=ep ./tool

Просмотр списка и описания всех capabilities:

man 7 capabilities

Важно: работает только на файловых системах с поддержкой extended attributes, cp по умолчанию сбрасывает xattr (используйте cp --preserve=xattr или -a), tar сохраняет capabilities только с --xattrs

🔥 Capabilities — способ выдавать минимально необходимые права, вместо запуска всего от root.

➡️ DevOps Ready | #практика

Поиск открытых, но удалённых файлов!

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

Поиск таких файлов:

sudo lsof -nP +L1

Команда показывает файлы с link count = 0 — то есть удалённые из файловой системы (unlinked), но всё ещё открытые процессами.

Фильтрация по пути:

sudo lsof -nP +L1 /var

Позволяет отфильтровать файлы, связанные с указанным путём (по имени/расположению файла).

Формат вывода зависит от версии lsof и ширины терминала, поэтому парсинг через awk возможен, но небезопасен — используйте вывод как ориентир.

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

sudo kill -HUP PID

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

Завершение процесса:

sudo kill PID

Отправляется SIGTERM — процесс штатно завершается, закрывает файловые дескрипторы и освобождает место. SIGKILL (-9) — крайняя мера, если процесс не реагирует.

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

df -h
sudo lsof -nP +L1

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

🔥 Типичная ситуация при ручном удалении логов без logrotate или при аварийной ротации файлов.

➡️ DevOps Ready | #практика

👍 Актуальная статья для тех, кто хочет вырасти в DevOps и понять, куда движется профессия в 2026 году!

В этой статье:
• Разбирают эволюцию DevOps от «собака-деплоер» к платформенной инженерии;
• Показывают, какие скиллы востребованы;
• Объясняют карьерный трек: что отличает mid от senior/platform engineer и как перейти от «фикса серваков» к дизайну инфраструктуры.

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

➡️ DevOps Ready | #статья

Как защитить скрипт от двойного запуска?

Бывает, что cron/CI/ручной запуск запускают один и тот же скрипт дважды.

Своеобразным замком может послужить flock, он берёт advisory lock на файл через дескриптор:

exec 9>/tmp/myjob.lock

Здесь мы открыли файл-замок и привязали его к FD 9.

Пробуем взять lock без ожидания, если уже занято, сразу выходим:

flock -n 9 || exit 0

Дальше можно выполнять работу, пока процесс жив, lock удерживается ядром:

echo "running: $$"

Для проверки откроем второй терминал и запустим тот же блок, второй экземпляр завершится (или можешь заменить exit 0 на сообщение):

sleep 10

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

➡️ DevOps Ready | #совет

📂 Напоминалка для работы с Linux LVM!

Например, pvcreate инициализирует диск или раздел под LVM, а vgcreate объединяет физические тома в volume group.

На картинке — наглядная схема архитектуры LVM и самые часто используемые команды для управления physical volumes, volume groups и logical volumes.

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

➡️ DevOps Ready | #ресурс

👍 KillerCoda — платформа с интерактивными задачами!

Это тренажёр с терминалом, где Linux изучается через реальные задания, а не через статьи. Здесь можно на практике поработать с systemd, файловыми системами, процессами и Docker в полноценном окружении. Формат обучения максимально ориентирован на реальные задачи администрирования и работы в командной строке.

📌 Оставляю ссылочку: killercoda.com

➡️ DevOps Ready | #ресурс

Работа с архивами tar в Linux!

tar — инструмент для упаковки и распаковки данных. Часто используется для бэкапов, доставки артефактов, упаковки проектов и обмена данными между серверами.

Создание архива с gzip-сжатием:

tar -czvf archive.tar.gz /path/to/data

Создание архива с zstd-сжатием (нужен GNU tar с поддержкой --zstd и установленный zstd):

tar --zstd -cvf archive.tar.zst /path/to/data

Основные ключи:

c — create
x — extract
t — list
z — gzip
v — verbose
f — файл/поток
-C — директория
--zstd — zstd

Просмотр содержимого без извлечения:

tar -tzvf archive.tar.gz
tar --zstd -tvf archive.tar.zst

Проверка целостности (проверяется поток сжатия, не структура tar):

gzip -t archive.tar.gz
zstd -t archive.tar.zst

Извлечение архива:

tar -xzvf archive.tar.gz -C /tmp/extract/
tar -xzvf archive.tar.gz path/inside/archive/file.conf

Инкрементальный архив (GNU tar):

tar -czvf backup.tar.gz -g snapshot.file /path/to/data

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

Потоковая передача по SSH (без промежуточного файла):

tar -czf - /data | ssh user@server "tar -xzf - -C /srv/data"

🔥 tar по умолчанию сохраняет права доступа, владельца/группу, mtime и симлинки; ACL и xattrs требуют явных опций (--acls, --xattrs).

➡️ DevOps Ready | #практика

😎 Docker Curriculum — структурированное обучение с нуля!

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

📌 Оставляю ссылочку: docker-curriculum.com

➡️ DevOps Ready | #ресурс