🔒 Linux: Как защитить файл от rm -rf (Даже от Root)

Вы думаете, что пользователь root может всё? Ошибаетесь. Есть уровень файловой системы, где права rwx (777) не имеют значения. Это атрибуты ext4/xfs.

Если вы хотите защитить критический конфиг (например, /etc/resolv.conf, который вечно перезаписывается NetworkManager-ом) или логи от хакера — используйте Immutable bit.

1. Делаем файл бессмертным:

sudo chattr +i /etc/critical_config.conf

Теперь попробуйте rm, mv или echo "test" > .... Вы получите: Operation not permitted. Даже под sudo. Даже под root.

2. Как проверить, почему файл не удаляется: Если ls -l показывает, что права есть, а удалить нельзя — смотрите атрибуты:

lsattr /etc/critical_config.conf
# Вывод: ----i---------e---- /etc/critical_config.conf

Видите букву i? Это оно.

3. Как вернуть всё назад:

sudo chattr -i /etc/critical_config.conf

Где применять: Защита скриптов автозагрузки, критических конфигов и бинарников от изменения вирусами-шифровальщиками.

#linux #security #chattr #filesystem #hacks #root

🔗 Symlink vs Hard Link: В чем реальная разница?

Мы все постоянно пишем ln -s , создавая символические ссылки (Symlink). Но есть еще "Жесткие ссылки" (Hard Links). В чем соль? В Inode.

В Linux файл — это не имя. Файл — это набор данных на диске, у которого есть номер (Inode). А "Имя файла" — это просто указатель на этот номер.

Разница на пальцах:

1. Hard Link (ln file link): Это второе имя для того же самого Inode.

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

* Ограничение: Нельзя делать на папки и между разными дисками.

2. Soft (Symbolic) Link (ln -s file link): Это новый файл, внутри которого написан путь к оригиналу.

* Если удалить оригинал — ссылка станет "битой" (указывает в пустоту).

* Плюс: Работает везде, даже между разными файловыми системами.

Как проверить: Команда ls -li покажет номер Inode в первом столбце. У хард-линков он одинаковый.

#linux #inodes #filesystem #theory #basics #interview

🐧 Linux: Ошибка "Read-only file system"? Спасаем данные без ребута 🛠️

Страшный сон админа: файловая система внезапно ушла в read-only из-за ошибок в логах или сбоя питания.
Сервисы встали, база упала. Прежде чем бежать за новым диском, можно попробовать «пересобрать» её на лету.

Шаг 1: Проверяем, что случилось

dmesg | grep -i "error|jbd2"

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

Шаг 2: Магия перемонтирования Если диск физически жив, можно принудительно вернуть ему режим записи:

mount -o remount,rw /

Шаг 3: Исправление «на ходу» (для ext4) fsck -n /dev/sda1 — только проверка (без правок). Если ошибок много, используем debugfs для вытаскивания критичных конфигов, пока диск окончательно не «отвалился».

Совет: Если такое случилось на виртуалке, проверь задержки (latency) на СХД — часто диск уходит в RO, если гипервизор не ответил вовремя. 📡

#linux #filesystem #troubleshooting #sysadmin #ext4 #storage

🐧 Linux: Прощай, ext4? Bcachefs как новый стандарт файловых систем

Коллеги, мы десятилетиями сидели на сверхнадежной, но морально устаревшей ext4. Когда нам нужны были снапшоты и работа с несколькими дисками, мы собирали сложные конструкции из LVM, mdadm и ext4, либо уходили на тяжеловесную ZFS, которая до сих пор живет вне основного ядра Linux из-за лицензий.

К 2026 году ситуация изменилась. Файловая система Bcachefs окончательно стабилизировалась в ядре и начала вытеснять конкурентов.

Что такое Bcachefs:
Ее называют «ZFS для бедных», но на деле это современная Copy-on-Write (CoW) файловая система, которая изначально писалась с прицелом на максимальную производительность и чистоту кода.

Главные фишки для админа:

— Нативная работа с несколькими дисками: Больше не нужен RAID. Вы просто отдаете файловой системе два диска, и она сама зеркалирует данные.
— Тиринг (Caching): Можно объединить быстрый NVMe-накопитель и медленный HDD. Bcachefs сама будет держать горячие данные на SSD, а холодные архивы сбрасывать на жесткий диск.
— Встроенная компрессия и шифрование: Делается на лету силами самой файловой системы, без настройки dm-crypt или LUKS.

Как попробовать:

При форматировании раздела достаточно указать новый тип (если ваше ядро свежее):
mkfs.bcachefs /dev/sda1 /dev/sdb1

Эпоха наслоения технологий (RAID + LVM + FileSystem) уходит. Bcachefs берет все эти функции на себя, работая прямо из коробки ядра Linux. Если вы планируете разворачивать новые файловые хранилища, самое время тестировать этот инструмент.

#linux #bcachefs #storage #filesystem #sysadmin #admin_future

🐧 Linux: Bcachefs выгнали из ядра — и это хорошая новость для тех, кто понимает

Коллеги, если вы следите за файловой системой bcachefs — в сентябре 2025 года Линус Торвальдс окончательно выкинул весь код bcachefs из ядра, начиная с версии 6.18, за нарушения правил разработки. Теперь это внешний DKMS-модуль. Половина команды сразу решила: "раз выпилили — значит мёртвая". Не спешите.

Март 2026-й: вышел bcachefs 1.37 с поддержкой грядущего ядра Linux 7.0, и главное — erasure coding (аналог RAID с коррекцией ошибок) официально получил статус стабильного, сброшен experimental-тег. Это годами ждали. Помимо этого: автоматическое восстановление после некорректного завершения работы и поддержка устройств с битым flush/fua.

Что это означает на практике — собираем пул с erasure coding:

# Устанавливаем DKMS-модуль (Ubuntu 24.04 / Debian 13)
apt install bcachefs-tools bcachefs-dkms linux-headers-$(uname -r)

# Форматируем пул из 4 дисков с erasure coding (аналог RAID 5)
# 3 диска данных + 1 диск паритета
bcachefs format \
  --label=storage \
  --erasure_code \
  --replicas=1 \
  /dev/sdb /dev/sdc /dev/sdd /dev/sde

# Монтируем (UUID рекомендуется для надёжности)
mount -t bcachefs /dev/sdb:/dev/sdc:/dev/sdd:/dev/sde /mnt/storage

# Проверяем статус пула
bcachefs fs usage /mnt/storage

# Смотрим здоровье устройств
bcachefs show-super /dev/sdb

Зачем это нужно:
ZFS на Linux — всё ещё лицензионный компромисс. Btrfs RAID5/6 в дистрессе ест данные — и сообщество в глубоком отрицании. Bcachefs с erasure coding — это первая GPL-нативная альтернатива, которая делает это правильно. Для хранилища на Proxmox или bare-metal — смотреть обязательно.

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

#linux #bcachefs #filesystem #storage #sysadmin #admin_future

🐧 Linux: XFS self-healing в ядре 7.0 — конец ночных xfs_repair на продакшне

Коллеги, 12 апреля вышел Linux 7.0, и пока все обсуждают красивый мажорный номер версии и официальный статус Rust, кое-что поважнее тихо проскользнуло мимо радаров большинства. Для тех, кто держит боевые серверы на XFS — а это весь RHEL-мир, CentOS-наследники, Rocky и Alma — это прямой удар по одной из самых болезненных ситуаций в практике.

До 7.0 картина была такая: если XFS обнаруживал повреждение метаданных — от скачка питания, аппаратного сбоя или битого сектора — файловая система переходила в read-only или падала с ошибкой. Требовалось размонтировать том, часто невозможное на живой корневой ФС, загрузиться с rescue-медиа и запустить xfs_repair вручную.

Теперь другая история. Новая возможность использует специальный daemon, который опирается на parent pointer metadata и reverse mapping для обнаружения ошибок, о которых сообщает ядро, и запускает исправление автоматически. Всё это происходит пока файловая система примонтирована и активно используется.

Важный нюанс сразу: ядро не сканирует файловую систему непрерывно. Вместо этого — когда при обычных операциях чтения или записи встречаются несогласованные метаданные, оно теперь пытается исправить их на месте, а не возвращать ошибку или переходить в read-only. Это не покрывает все сценарии: глубокие структурные повреждения, аппаратный bit rot и сбои в блоках данных по-прежнему требуют офлайн-ремонта или восстановления из бэкапа.

Что делать практически прямо сейчас:

# Проверяем версию ядра — нужна 7.0+
uname -r

# На Ubuntu 26.04 LTS (выходит 23 апреля) — будет из коробки
# На текущих системах — смотрим в mainline PPA для тестовых сред:
# add-apt-repository ppa:kernel-ppa/mainline && apt update

# Проверяем что XFS примонтирован с нужными опциями
# self-healing включён по умолчанию — дополнительной конфигурации не нужно
mount | grep xfs
# Убеждаемся что есть rmapbt и parent pointers (нужны для self-heal)
xfs_info /dev/sda1 | grep -E "rmapbt|ftype|reflink"

# Мониторинг self-healing активности в реальном времени
# Смотрим dmesg — ядро будет логировать каждое исправление
dmesg -w | grep -iE "xfs.*(heal|repair|corrupt|recover)"

# Пример того что увидим при срабатывании:
# [ 183.44] XFS (sda1): Repairing corrupt inode btree in AG 2.
# [ 183.45] XFS (sda1): Self-healing complete. Filesystem operational.

# Для мониторинга через journalctl (если нет dmesg watch):
journalctl -k -f | grep -i "xfs"

# Проверяем health XFS-тома утилитой xfs_scrub (рекомендуется периодически)
# В режиме онлайн — не блокирует работу
xfs_scrub -v /mount/point

# Настраиваем регулярный xfs_scrub через systemd timer (уже есть в xfsprogs)
systemctl enable --now xfs_scrub_all.timer
systemctl status xfs_scrub_all.timer

# Смотрим статистику ошибок ФС
xfs_db -r -c "check" /dev/sda1  # offline check для диагностики

Зачем это нужно:
Для системных администраторов, отвечающих за XFS-тома на продакшн-серверах, это значимое улучшение quality-of-life. Однако эту возможность не следует использовать как замену полноценному процессу резервного копирования и восстановления. Self-healing — это safety net для конкретного класса сбоев, а не страховка от всего.

Итог: xfs_repair в 3 ночи с rescue USB — это был обряд посвящения для каждого линукс-администратора. В ядре 7.0 этот обряд стал значительно реже встречаться. Бэкапы всё равно делайте.

#linux #xfs #kernel7 #storage #filesystem #sysadmin #admin_future

🐧 Linux: nullfs в ядре 7.0 — зачем нужна «чёрная дыра» в файловой системе

Коллеги, одна из тихих, но важных вещей в ядре 7.0 — новый псевдофайловый тип nullfs. Звучит странно. Разберёмся зачем.

nullfs решает давнюю проблему initramfs: раньше pivot_root() не работал на реальной корневой ФС, потому что её нельзя было размонтировать. Userspace вынужден был делать хрупкий switch_root — рекурсивное удаление initramfs вручную перед продолжением загрузки.

Теперь схема чистая: nullfs — это минималистичная иммутабельная псевдо-ФС, она становится истинным корнем иерархии монтирования. Поверх неё монтируется mutable rootfs (tmpfs). Это позволяет сделать chdir + pivot_root + umount атомарно, без воркараундов.

Бонус для безопасности: каждый kernel thread получит nullfs как свою корневую ФС — это изолирует потоки ядра от файловой системы init-процесса. Сейчас все kernel threads разделяют файловое состояние init, что создаёт риск.

Что это значит на практике:

# nullfs включён по умолчанию в ядре 7.0
# Проверяем что он есть в системе:
cat /proc/filesystems | grep null

# Быстрее загружается initramfs — меньше задержек при старте
# Полезно замерить разницу до и после апгрейда на Ubuntu 26.04:
systemd-analyze
systemd-analyze blame | head -20

# Смотрим дерево монтирования — nullfs будет в корне:
findmnt --tree | head -5

Зачем это нужно:
Надёжнее загрузка → меньше случаев когда сервер не поднялся после патча. Для флотов с автоматическим деплоем ядра — это снижение риска.

Итог: nullfs — это не экзотика. Это архитектурная чистка, которая делает Linux-boot предсказуемее. Ubuntu 26.04 уже с ней.

#linux #kernel7 #boot #filesystem #sysadmin #admin_future