Настройка Linux *

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

Всё это, как я считаю, можно объединить двумя словами: "Архитектура VFS", которую мы сегодня и разберём. Перед тем как начать, я думаю, что нам стоит определиться, что КОНКРЕТНО мы будем изучать:

1. Что такое файловые системы, какими они бывают и зачем они нужны.

2. Что такое VFS, зачем она нужна и как она работает.

3. Что такое файловые дескрипторы (FD), зачем они нужны и как они работают.

4. Операторы перенаправления потоков.

Если вы, как и я, метите в DevOps(а именно для них эта статья и написана), то эта информация вам может понадобиться, как минимум, для того, чтобы пройти собеседование - на тему траблшутинга часто могут задавать вопросы в духе "удалил файл, но процесс всё равно продолжает его читать".

Представьте: ваш автономный агент генерирует команду для терминала, но ошибается на один символ. Шелл уходит в бесконечное ожидание, а процесс агента намертво зависает. Сегодня разберём, почему регулярки не спасают от этой боли, и покажем, как детерминированный конечный автомат (FSM) на хуке PreToolUse снимает проблему на уровне инфраструктуры.

Вы нашли на форуме рассказ про любопытную команду, скопипастили в терминал, и она сработала. Через неделю вы переносите ее в скрипт, и скрипт спотыкается на первом же файле с пробелом в имени. Чуть подправили, потестили и запустили в работу. А однажды ночью нужного каталога не оказывается на месте, и rm * удаляет файлы в каталоге на котором скрипт остановился. Страшный сон или реальность?

Работаю в VS Code в Linux-виртуалке UTM на маке, и прокрутка там всегда прыгала по три строки и очень чувствительна к движениям пальца, вместо прокрутки приходилось пользоваться обычными стрелками на клаве. Ранее я уже просил Claude это исправить: поставили замедлитель и imwheel, не помогло, на этом и остановились. В этот раз Claude Opus 5.5 за один чат и пару моих правок разобрался до конца. Выяснилось, что причин три, и одна сидит в самом libinput (уж очень клод акцентирует внимание на этой причине): он придерживает первые пол-щелчка каждого жеста и выдаёт их рывком. Claude написал прогу с интерфейсом и настройками, залил всё на GitHub. До идеала macOS не дотягивает - первое движение нужно делать чуть длиннее, чем на маке. В остальном прокрутка плавная и привычная, результатом доволен. В статье - технический разбор, как это получилось. Картинка, вся работа и статья от клода опус 5.5.

В прошлой статье я рассказывал, как устроен мой тренажёр инцидентов изнутри. Сегодня покажу один кейс, седьмой, про 502 Bad Gateway. Он небольшой, но на нём хорошо видно, почему рестарт nginx почти никогда не помогает.

Вводная такая: ночью выкатили релиз, утром магазин отдаёт 502. При этом systemctl status nginx показывает active (running).

502 значит, что nginx запрос принял, передал дальше и нормального ответа не получил. То есть nginx тут свидетель, и начинать надо с его лога:

Контейнер упёрся в лимит памяти, но OOMKilled так и не появился. Сервис продолжает работать, задержки растут, CPU почти простаивает, а привычные метрики не объясняют, что происходит. На примере экспериментов с cgroup v2 разберём, как memory.high заставляет процессы ждать освобождения памяти и почему в Kubernetes это может обернуться минутами деградации производительности перед рестартом.

Три часа ночи, API отвечает 500, и рука сама набирает systemctl restart. Иногда это помогает, но есть инциденты, где рестарт добивает то, что ещё работало, и стирает улики. Пять таких: битый конфиг, OOM killer, retry storm, CrashLoopBackOff и диск, забитый логом, — с командами, которые находят настоящую причину, и шпаргалкой на одну таблицу.

Новичок открывает первый кейс, о котором я рассказывал в первой статье., читает брифинг, и через пять секунд сайт пишет: «Готово, жми „Начать“». Он жмёт и смотрит на пустое окно терминала. Секунд через десять там ошибка, страница сама перезагружает терминал, и только потом появляется консоль.

Сервер при этом не падал, CPU и память в норме, алерты молчат. Были только строчки в журнале, которые я чуть не записал в «обычный шум».

Рассказываю, что может натворить человек с root в контейнере и как я это закрыл: gVisor вместо runc, отдельная сеть на каждый запуск, лимиты, сторож диска и проверка, которую не обмануть через sudo. Плюс три дыры в «идеальной» сетевой изоляции и замеры: почему load average врёт и как 3 места на сервере превратились в 9.

Алерт: сайт лежит, а CPU, память и диск в норме. Разбираю пять причин, которых не видно на стандартном дашборде: inode, лимит файловых дескрипторов, ушедшие часы, DNS и протухший сертификат. Для каждой — как выглядит, чем найти, как починить и что добавить в мониторинг.

В первые минуты инцидента важнее всего не скорость, а порядок. Когда сыплются алерты, руки сами тянутся перезапустить сервис или что-нибудь удалить. А причину быстрее находит тот, кто проходит одни и те же шаги в одном и том же порядке.

Ниже мой чек-лист для Linux-сервера: пять шагов, по нескольку команд на каждый. Я собрал его, пока делал 13 кейсов для тренажёра дежурств (о нём была первая статья). Поэтому у каждого шага есть пример из кейса, где именно он находит причину.

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

Я сделал бесплатный тренажёр, где дежурство можно прожить до того, как оно случится на проде: приходит алерт, у вас настоящая консоль Linux со сломанным сервисом, и нужно найти причину и починить. Называется он Prod is Down.

Я 4 года работаю системным администратором. Самое запомнившееся дежурство случилось в первый же месяц: в три часа ночи лёг один из наших сервисов, алерты сыпались один за другим, а я смотрел в консоль и не понимал, с чего начать. Логи? top? Перезапустить всё подряд? Сервис я тогда поднял через час и скорее везением, а настоящую причину — забитый логами диск — нашёл только утром.

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

Так появилась идея — место, где сервер ломается по-настоящему, но без последствий: можно ошибиться, сбросить всё и попробовать снова.

Сейчас в тренажёре 13 кейсов: обучающий кейс 0 и 12 инцидентов — упавший PostgreSQL, OOM Killer, забитый диск, истёкший сертификат, 502 от nginx, кончившиеся inode, DNS, лимит открытых файлов, сбитое время и другие. Ничего устанавливать не нужно, консоль открывается в браузере; кейс 0 проходится без регистрации.

В статье расскажу не столько про тренажёр, сколько про инженерные задачи внутри: как дать незнакомым людям root-консоль на своём сервере и не пожалеть, как проверить, что игрок действительно починил сервис, и на что я наступил с gVisor.

Путь к файлу тот же, текст обновился, но процесс с открытым дескриптором продолжает читать старую версию. На небольшом Linux-стенде сравнил cp, sed -i и замену через временный файл: права доступа, inode и поведение читателя.

Как я перешёл с openclaw на DeepSeek Harness, вернул своему VDS load average 0,03 и перестал докупать память.

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

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

Но эйфория от того, что я, начитавшись интернетов и насмотревшись видео, поставил себе openclaw, быстро прошла. Да, функциональность у него потрясающая.

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

Хватит это терпеть! В сентябре 2026 года Фонд свободного программного обеспечения объявил, что берет под свое крыло проект GNU Boot. Это попытка сделать полностью свободную замену BIOS и UEFI. Давайте разберемся, зачем она нужна и почему пока работает только на старом железе.

Установка Docker на VPS обычно заканчивается на hello‑world: приветствие напечаталось, значит, всё работает. Для движка так и есть. Другие вопросы всплывают через месяц: какие порты сервер теперь отдаёт в интернет, куда пропали данные после обновления образа и почему у пользователя из группы docker фактически есть root. Их проще закрыть сразу, пока на сервере нет базы.

Ниже весь путь от чистого VPS с Ubuntu 24.04 LTS до веб‑сервиса в Compose с отдельным томом. Нужны виртуальная машина, доступ по SSH и sudo. На Ubuntu 26.04 команды те же, отличается только кодовое имя в версиях пакетов. У Debian и других дистрибутивов свой репозиторий Docker, и смешивать инструкции не стоит.

Эта статья описывает по шагам, как включить Secure Boot в Arch Linux с загрузкой через UKI, не заменяя и не задевая другие ключи в UEFI. Если вы новичок в Arch, которому руководство по Secure Boot на Arch Wiki кажется страшным и непонятным, и вы боитесь задевать зашитые заводские ключи, или имеете другие причины их не менять, то, возможно, этот способ вам подойдет.

21 октября 2026 года мир PHP вздрогнул от анонса двух критических RCE-уязвимостей (CVSS 9.2), получивших общее имя PHP2Shell (CVE-2026-109618 и CVE-2026-109619). Опасность этих брешей в том, что они срабатывают на уровне ядра интерпретатора еще до того, как управление дойдет до первой строчки вашего index.php. Достаточно, чтобы сервер просто принимал HTTP-запросы.

Разработчики PHP оперативно выпустили патчи для поддерживаемых веток (8.2.35, 8.3.36, 8.4.27, 8.5.12) и заявили: «Единственный 100% способ защиты - обновление, а сценарий наивысшего риска - это Apache с mod_php».

Звучит отлично, если у вас свежий проект. А что делать, если в продакшене крутится суровый высоконагруженный энтерпрайз-легаси на PHP 5.6 в связке с Apache 2.4 (mpm_prefork + mod_php), переписать который за ночь невозможно, а официальных патчей для ветки 5.6 не выйдет никогда?

Под катом - практический разбор того, как устроены обе уязвимости, почему именно mod_php оказался под главным ударом и как я выстроил эшелонированную оборону на уровне Varnish → Apache → PHP → Docker cgroups, не сломав легаси-монолит и проверив каждый рубеж боем (с разбором подводных камней HTTP keep-alive).

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

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

Причин несколько. Рабочий код должен идти через рабочий аккаунт, потому что у компании на этот счёт свои правила. Свои проекты я, наоборот, не хочу гонять за счёт работодателя и оставлять в корпоративной истории. Переключаться вручную через /logout и /login можно, но "разве это жизнь".

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