Admin Guides | Сисадмин

lsns: поиск неожиданных namespace на сервере Namespace легко забыть при диагностике: процесс может находиться в отдельном PID, mount или network namespace, поэтому обычный ps не всегда объясняет, что происходит. Показываем все namespace: lsns Особенно интересны процессы, которые создали собственные namespace: lsns -p <PID> Можно сразу посмотреть только PID namespace: lsns -t pid -o NS,TYPE,NPROCS,PID,COMMAND Если namespace остался после завершения контейнера, в NPROCS можно увидеть, есть ли внутри ещё процессы. Для сетевых namespace: lsns -t net -o NS,NPROCS,PID,COMMAND Так можно обнаружить интерфейсы и маршруты, которые находятся не в основном namespace хоста. А для mount namespace: lsns -t mnt -o NS,NPROCS,PID,COMMAND Это особенно полезно при расследовании странных mount/umount, контейнеров и процессов, которые продолжают удерживать файловые системы. ⚡️Интересный кейс - процесс уже выглядит “обычным” в ps, но его PID, mount’ы или сеть находятся в другом namespace. lsns позволяет сначала увидеть границу namespace, а затем через nsenter посмотреть на систему именно изнутри этого окружения.

🚨 Когда системный администратор уже не может помочь... 03:17 ночи. Срабатывает алерт. Через несколько минут становится ясно: это начало атаки. Именно в этот момент начинается работа аналитика SOC. Хотите узнать, что происходит дальше?   На бесплатном вебинаре «Как системному администратору перейти в информационную безопасность?» разберём: ✅ чем на самом деле занимается аналитик SOC; ✅ какие навыки у вас уже есть; ✅ что нужно изучить для первой позиции SOC Analyst L1; ✅ каких ошибок избежать на старте.   📋 Перед вебинаром рекомендуем пройти диагностический тест и получить карту развития   📅 27 августа, 19:00 🎓 Участие бесплатное.   👉 Регистрация на вебинар тут 👈   🎁 Всем участникам, которые останутся до конца вебинара, подарим мини-курс, где вы попробуете себя в роли аналитика SOC и научитесь замечать первые признаки атак в логах.   Приходи.   Реклама. ИП Кириллова Наталья Викторовна, ИНН 691207795912

Диагностика ошибок NVMe через kernel AER и controller reset NVMe-диск может периодически пропадать, давать I/O errors или внезапно становиться медленным. При этом smartctl ещё может показывать нормальное состояние. В таких случаях проблема может быть не в самом накопителе, а в PCIe-соединении. Сначала смотрим сообщения ядра: dmesg -T | grep -Ei 'nvme|aer|pcie' Особенно интересны сообщения: AER: Corrected error received PCIe Bus Error nvme ... I/O timeout nvme ... controller reset AER (Advanced Error Reporting) позволяет PCIe-устройствам сообщать ядру об ошибках шины. Corrected не означает, что проблему можно игнорировать: повторяющиеся ошибки могут указывать на проблемы с PCIe slot, backplane, прошивкой или питанием. Проверяем конкретный NVMe-контроллер: lspci -vv -s <PCI_ADDRESS> В выводе интересны AER, LnkSta, скорость и ширина PCIe-соединения. Например, устройство рассчитано на x4, но фактически работает на x2 - это уже повод проверить физический тракт. Для самого NVMe: nvme list nvme smart-log /dev/nvme0 Если в kernel log регулярно появляется: I/O timeout controller is down resetting controller а затем контроллер снова появляется, это похоже на сбой самого устройства или PCIe-связи. Полезно посмотреть, сколько раз устройство сбрасывалось: journalctl -k | grep -Ei 'nvme.*reset|nvme.*timeout' Если reset’ы происходят регулярно, просто перезапускать сервисы поверх такого диска бессмысленно - сначала нужно найти причину потери связи. 🔥 Важный момент: NVMe timeout не обязательно означает умирающий SSD. Если одновременно появляются AER, PCIe Bus Error и controller reset, проверять нужно всю цепочку: накопитель → слот/backplane → PCIe link → firmware → BIOS. Особенно это актуально для серверов, где несколько NVMe работают через PCIe switch или backplane.

📣 Как мигрировать 100+ рабочих станций за 20-25 минут на российскую ОС: технический разбор Astra Migration 18 августа в 11:00 вебинар про технологическую часть Astra Migration — инструмента для параллельной миграции с Windows на Astra Linux. В программе: 🔹 Архитектура и технические особенности Astra Migration. 🔹 Как устроен центр миграции и что происходит на рабочих станциях до, во время и после перехода. 🔹 Что делать, если нужно откатиться к исходным настройкам. 🔹 Как адаптировать решение под особенности вашей организации. 🔵 Live демонстрация процесса миграции — что будет на рабочих станциях до, во время и после перехода. Вебинар будет полезен техническим директорам и руководителям ИТ-служб, директорам по цифровой трансформации, а также инженерам и ИТ-специалистам, которые планируют переход на Astra Linux. 🗓 18 августа в 11:00 МСК Регистрация

💬 Вопрос на собеседовании для сисадмина Давайте разберем один из частых вопросов, который может быть задан на собеседовании и как на него отвечать. ❓Вопрос: Что такое fsync(), и почему успешный write() ещё не означает, что данные уже находятся на диске? ✅Ответ: write() обычно сообщает ядру, что данные успешно приняты для записи. Это не гарантирует, что они уже физически записаны на энергонезависимый носитель. Данные могут находиться в page cache и быть сброшены позже механизмом writeback. fsync() заставляет ядро сбросить изменённые данные и связанные метаданные конкретного файла на устройство хранения и дождаться завершения операции.

HEAD-скан: как перебирают ваши файлы, ничего не скачивая 🍃 В логах строка, подобная тени на воде: 203.0.113.42 - "HEAD /upload/disk/157/a7f3c1b9e4...xlsx" 200 0 "-" "-" Метод HEAD возвращает лишь заголовки, подобно тому как мастер отвечает на вопрос тишиной. Тело не передаётся, трафика нет, в графиках ничего не всплывает. Зато ответ говорит главное: файл существует и весит столько-то. Как и гласит старая пословица, пустая чаша всё же имеет вес, если знать, где её взвесить. Так перебирают загрузки — /upload/, /wp-content/uploads/, выгрузки 1С, бэкапы рядом с сайтом. Тысячи HEAD подряд, и только по найденному — один GET. Пустой User-Agent в примере не случайность: писать его сканеру незачем, а фильтры чаще смотрят на подозрительные UA, чем на их отсутствие. Пустота в имени часто скрывает больше, чем громкое имя. Почему проходит мимо мониторинга 🌊 Алерты обычно строят на объёме и на кодах 4xx. HEAD даёт 0 байт и честные 200 — перебор выглядит как здоровый трафик. А рейт-лимиты часто вешают на /login и /api, но не на статику. Как и в саду, где охранник смотрит на ворота, но не замечает трещины в заборе. Проверьте у себя: grep '"HEAD ' access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head Один адрес с сотнями HEAD за час — это не браузер. Браузер шлёт HEAD единицами. Человек идёт по дороге, а ветер вихрем несёт пыль. Дальше по делу: закрыть листинг каталогов, проверить, что доступ к файлам решает приложение, а не только неугадываемость имени, и добавить лимит на HEAD по статике — легитимного трафика вы этим не заденете. Защита в простоте, как в камне, лежащем на дороге. Мы делаем Threatail — WAF с нодой на вашем железе. (https://threatail.com) Такой перебор он ловит связкой: пустой UA и TLS-отпечаток дают бот-сигнал, серия блокировок с одного адреса за минуту складывается в автобан на всех нодах сайта. Мастер видит следы на снегу, хотя никто ещё не прошёл.

Почему pkill может затронуть не тот процесс pkill удобен, но опасен тем, что по умолчанию ищет совпадения по имени процесса. На сервере легко получить ситуацию, когда под условие попадают несколько процессов. Например: pkill python может завершить не только нужный скрипт, но и другие процессы, у которых имя - python. Сначала лучше посмотреть, что именно совпадает: pgrep -a python У pgrep есть важное отличие: можно искать не только по имени, но и по полной командной строке: pgrep -af "python.*worker.py" Это уже проверяет аргументы запуска, а не только имя executable. Ещё один нюанс - pkill работает в текущем PID namespace. В контейнере PID 123 может быть совершенно другим процессом, чем PID 123 на хосте. Проверить namespace процесса: readlink /proc/<PID>/ns/pid И сравнить его с текущим: readlink /proc/self/ns/pid Для максимально точного завершения лучше вообще не использовать имя: kill <PID> А перед этим проверить: ps -p <PID> -o pid,ppid,user,comm,args ⚡️Особенно опасен pkill -f: он ищет совпадение во всей командной строке. Например, pkill -f worker может зацепить совершенно другой процесс, если слово worker случайно присутствует в его аргументах. Перед массовым pkill безопаснее сначала выполнить такой же поиск через pgrep -a и посмотреть полный список совпадений.

Уже очевидно, что ВАЙБКОДИНГ — главный навык ближайших лет Посмотрите сами. ИИ уже забирает на себя работу целых команд: пишет код, закрывает задачи джунов и позволяет стартапам запускать продукты в 2–3 раза меньшим составом. То, на что раньше нужны были несколько разработчиков, сегодня всё чаще делает один человек с ИИ-агентами. И это только начало. Те, кто освоит вайбкодинг сейчас, смогут быстрее запускать проекты, автоматизировать огромный объём работы, увереннее конкурировать на рынке и зарабатывать больше тех, кто продолжает делать всё вручную. Начать с нуля поможет канал Вайб-кодинг. Там ребята круглосуточно мониторят более 320 российских и зарубежных источников и публикуют только главное: релизы, инструменты, гайды, курсы и практические кейсы. Подписывайтесь, нас уже 50 тысяч: @vibecoding_tg

Почему nscd может отдавать старые DNS-ответы nscd кеширует DNS-ответы, поэтому после изменения записи домена сервер ещё некоторое время может получать старый IP. Причём TTL DNS и время жизни записи в nscd - не всегда одно и то же. Проверяем, используется ли nscd: systemctl status nscd Состояние кеша: nscd -g В выводе интересуют positive hits, negative hits и параметры TTL. Особенно неприятный случай - negative caching. Если домен временно не существовал или DNS-сервер вернул NXDOMAIN, nscd тоже может сохранить этот ответ. После появления записи приложение продолжит получать старый отрицательный результат. Проверить настройки: grep -E 'enable-cache|positive-time-to-live|negative-time-to-live' /etc/nscd.conf Например: positive-time-to-live hosts 3600 negative-time-to-live hosts 20 Здесь успешный DNS-ответ может храниться час, даже если авторитетный DNS уже вернул другой адрес. Очистить кеш: nscd -i hosts После этого запрос пойдёт к DNS заново. Если нужно проверить, действительно ли проблема в nscd, сравниваем системный lookup с прямым DNS-запросом: getent hosts example.com dig example.com getent проходит через системный resolver/NSS и может получить ответ из nscd, а dig обращается к DNS напрямую. ⚡️Поэтому при странном расхождении getent и dig первым делом стоит проверить NSS и кеширующие сервисы. Особенно это важно после миграции DNS, смены IP серверов и при использовании коротких TTL: приложение может видеть старый адрес, хотя сам DNS уже давно отдаёт новый.

Claude Opus 5 удалила данные пользователя вместо создания резервной копии ИИ-агент Anthropic Claude Opus 5 во время запроса «сделать резервную копию на ПК» перепутал путь к каталогу: вместо C:\Users\harih указал /c/Users/harih. Создав копию не там, где нужно, модель решила удалить ошибочную папку и запустила rm -rf, но применила команду ко всему диску. «Я попросил Claude Opus 5 создать резервную копию. Вместо этого он создал её в неправильном каталоге, а затем выполнил rm -rf для всего моего диска. Удалив всё, он просто ответил: “Извините, опечатка”», — рассказал пользователь. Это не первый подобный случай. Ранее Claude Opus 5 Max удалила базу данных проекта другого разработчика. Восстановить удалось 96 из 117 страниц проекта. 👀 Похожие инциденты происходили и с другими ИИ-агентами: в BridgeMind рассказывали, как модель OpenAI GPT-5.6 Sol удалила данные о пользователях и подписках компании, а предприниматель Мэтт Шумер сообщил об удалении почти всех файлов с его рабочего Mac.

Поиск процессов, которые удерживают deleted-библиотеки Процесс может продолжать использовать старую версию .so, даже если файл уже удалили или заменили. Поэтому обновили библиотеку, а сервис фактически продолжает работать со старой. Проверяем открытые удалённые файлы: lsof | grep '(deleted)' Для конкретного процесса: lsof -p <PID> | grep '(deleted)' Особенно интересны строки с .so: app 1842 /usr/lib/libexample.so.1 (deleted) Это означает, что запись файла уже удалена из файловой системы, но процесс продолжает держать старый inode открытым. Можно посмотреть, какие библиотеки реально загружены: grep '\.so' /proc/<PID>/maps А после обновления пакета сравнить процессы, которые ещё используют старую библиотеку: lsof | grep '/usr/lib/' | grep deleted

🔍Тестовое собеседование с Head of DevOps уже завтра 11 августа(уже завтра!) в 19:00 по мск приходи онлайн на открытое собеседование, чтобы посмотреть на настоящее интервью на Middle DevOps-разработчика. Как это будет: 📂 Александр Хренников, Head of DevOps в KTS с опытом 14+ лет, будет задавать реальные вопросы и задачи разработчику-добровольцу 📂 Александр будет комментировать каждый ответ респондента, чтобы дать понять, чего от вас ожидает собеседующий на интервью 📂 В конце можно будет задать любой вопрос Александру Это бесплатно. Эфир проходит в рамках менторской программы от ШОРТКАТ для DevOps-разработчиков, которые хотят повысить свой грейд, ЗП и прокачать скиллы. Переходи в нашего бота, чтобы получить ссылку на эфир → @shortcut_devops_bot Реклама. О рекламодателе.

💬 Вопрос на собеседовании для DevOps-инженера Давайте разберем один из частых вопросов, который может быть задан на собеседовании и как на него отвечать. ❓Вопрос: Что такое kernel ftrace и как его используют для диагностики системы? ✅Ответ: ftrace - это встроенный в ядро Linux механизм трассировки, который позволяет отслеживать выполнение функций ядра в реальном времени. Он помогает выявлять узкие места, задержки и необычное поведение подсистем без необходимости перекомпиляции ядра. Применение ftrace: • Трассировка функций ядра для анализа производительности CPU. • Отслеживание задержек в системных вызовах и планировщике. • Совместное использование с инструментами вроде trace-cmd и perf для визуализации и профилирования системы.

На Stepik запустили мощный курс по «Troubleshooting Docker и Kubernetes: поиск и устранение проблем» В программе только важные аспекты: — troubleshooting Docker и образов — диагностика сетевых проблем — настройка readiness/liveness probes — отладка pod’ов, деплоев и ingress — анализ логов контейнеров и кластера — разбор ошибок CrashLoopBackOff, OOMKilled, ImagePullBackOff и других Собеседования на DevOps/SRE сейчас всё чаще строятся вокруг реальных инцидентов. Данный курс фокусируется именно на таких сценариях и помогает в подготовке к практическим вопросам 48 часов доступен со скидкой 25% ↗️ Пройти курс на Stepik

Когда файловая система тормозит из-за блокировок, а не из-за диска Высокий iowait - не единственная причина медленной работы файлового сервера. Иногда диск почти не загружен, но десятки потоков конкурируют за одни и те же inode или directory lock. В итоге CPU простаивает, а задержки операций растут. Находим процессы, которые больше всего времени проводят в ожидании ядра: pidstat -w 1 Если количество добровольных и недобровольных переключений контекста резко растёт, процесс может ждать освобождения блокировки. Далее проверяем, где именно потоки проводят время: perf lock report или во время записи: perf lock record sleep 30 perf lock report Отчёт покажет, какие блокировки удерживаются дольше всего и какие функции ядра вызывают наибольшую конкуренцию. Если используется ext4, полезно посмотреть общую статистику файловой системы: cat /proc/fs/ext4/*/mb_groups Неравномерное распределение аллокации иногда становится причиной повышенной конкуренции между потоками. Ещё один индикатор - стек процессов в состоянии D: ps -eo pid,state,wchan,comm | awk '$2=="D"' Если несколько процессов ожидают одни и те же функции VFS (inode_lock, ext4_*, xfs_*), проблема, скорее всего, уже не в производительности диска.