🐱 500 Internal Meow Error

HTTP.cat - это коллекция HTTP-статусов, проиллюстрированных котиками. Каждый HTTP-код представлен забавной фотографией кота, которая метафорически отражает смысл статуса:

• 200 OK - довольный кот
• 404 Not Found - потерянный/растерянный кот
• 500 Internal Server Error - кот в хаосе и т.д

➡️ Получить свой кот-статус

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#пульс_индустрии

📰 Релизы и статьи

Упаковали неделю в один короткий пост.

— GNU C Library 2.43

— Windows-desktop на Linux

— GParted 1.8.0

— Буст продуктивности простыми методами

— Нестандартные форматы резюме

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#дайджест_недели

😅 Профдеформация

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#пятничный_деплой

🔄 61 версия бутылок

Команда Bottles выпустила версию 61, и главный акцент релиза — это новый анализатор Eagle, который разбирает exe и инсталляторы до запуска и сразу показывает, какие технологии и зависимости вам нужны.

Eagle встроен прямо в Bottles и включается, когда вы выбираете файл для запуска. Вместо простого старта он делает многошаговый разбор двоичного файла определяет тип инсталлятора, применённые технологии и возможные проблемы под Wine и Proton.

Анализ не замыкается на одном файле Eagle берёт в расчёт соседние объекты в том же каталоге, DLL и вспомогательные файлы, но старается не тонуть в хаосе вроде забитой папки загрузок.

По части технологий Eagle умеет распознавать популярные стеки и рантаймы: .NET Framework и .NET Core, Java, Qt, WPF, Electron включая разбор ASAR архивов для десктопных приложений.

➡️ Источник

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#пульс_индустрии

⚡️ Хакеры атаковали святое

Разработчик Notepad++ раскрыл детали компрометации сервера обновлений. Сервер хостинга взломали в июне 2025. Атакующие сохранили доступ до 2 сентября, а потом использовали украденные учетки до 2 декабря для подмены ссылок на обновления.

Провайдер заметил подозрительное после миграции клиентов 1 декабря и обновил ядро сервера 2 сентября, что отрезало прямой доступ. Логи показали, что целились только в Notepad++, эксплуатируя слабую проверку обновлений в старых версиях.

Эксперты связывают атаку с китайской государственной группой из-за выбора жертв.

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

Уроки для девопсов:

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

• Отслеживайте журналы трафика и аномалии в перенаправлениях. Смена ключей и проверка учётных записей обязательны после подозрений.

• Переходите к защищённому поставщику своевременно. Для IT-специалистов это напоминание: атаки на цепочку поставок бьют по популярному ПО, даже если код чистый.

➡️ Источник

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#разбор_полётов

💻 Синхронизация истории командной строки

Atuin — утилита для замены стандартной истории shell. Хранит команды в SQLite, синхронизирует между машинами и даёт мощный поиск.

Основные фичи:

• Фильтры по директории, дате, статусу выполнения

• История везде одна благодаря синхронизации

• Статистика — какие команды используете чаще, время выполнения

• Данные зашифрованы end-to-end

Установка:

bash <(curl --proto '=https' --tlsv1.2 -sSf https://setup.atuin.sh)

atuin
 register -u <USERNAME> -e <EMAIL>
atuin
 import auto
atuin
 sync

Команды:

• Посмотреть статистику: atuin stats

• Синхронизировать: atuin sync + --force для принудительного синка

• Экспорт в файл: atuin export > backup.txt

➡️ Официальный сайт

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#разбор_полётов

💻 Linux From Scratch отказывается от SysVinit

Проект Linux From Scratch (LFS) и Beyond Linux From Scratch (BLFS) прекращают поддержку System V Init в будущих версиях Phoronix. Начиная с LFS 13.0, который ожидается 1 марта 2026, останется только systemd.

Причины отказа

1. Двойная нагрузка на мейнтейнеров. Каждый пакет нужно проверять для обеих init-систем при подготовке релиза.

2. Жёсткие зависимости. GNOME и скоро KDE Plasma встраивают требования, которые нуждаются в возможностях systemd, отсутствующих в System V.

«Как личное замечание — мне не нравится это решение» — написал автор анонса. Решение продиктовано не идеологией, а практическими ограничениями.

Прагматизм победил принципы. Малочисленная команда LFS не может поддерживать две init-системы в условиях растущей экосистемы Linux.

➡️ Анонс

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#пульс_индустрии

🧑‍💻 Диагностика сетевых проблем

Когда серверы становятся недоступными, это немедленно влияет на все сервисы, пользователей и бизнес. Сетевая связность — это не одна система, а стек взаимодействующих слоёв: от физических интерфейсов до маршрутизации, firewall, DNS и прикладных протоколов.

Проблема может находиться на любом из этих уровней, и симптомы часто не указывают прямо на причину. Добавьте облачную инфраструктуру с виртуальными сетями, security groups, load balancers — и картина становится ещё сложнее.

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

Модель OSI в практике DevOps

Теоретическая модель OSI с семью уровнями в реальной практике упрощается до ключевых проверок:

Уровень 1-2: Физика и канал

• Состояние интерфейсов (UP/DOWN)
• Физическое соединение
• Ошибки передачи пакетов

Уровень 3: Сетевой

• IP адресация
• Маршрутизация
• ICMP связность

Уровень 4: Транспортный

• Firewall правила
• Фильтрация пакетов
• NAT и security groups

Уровень 5-7: Прикладной

• DNS резолвинг
• Доступность портов
• Логика приложения

Систематический подход

Золотое правило: двигайтесь снизу вверх. Не имеет смысла проверять DNS, если сетевой интерфейс в состоянии DOWN. Не тестируйте приложение, если базовая IP связность не работает.

Каждый уровень зависит от нижележащих. Проверили физику → проверили IP → проверили firewall → проверили DNS → проверили приложение. Только так можно быстро локализовать проблему.

Инструменты диагностики

Базовый набор:

• ip — управление интерфейсами, адресами, маршрутами
• ping — базовая проверка связности
• nc — тестирование TCP/UDP портов
• dig — DNS диагностика
• tcpdump — захват трафика

Системные:

• systemctl — управление сервисами
• journalctl — просмотр логов
• iptables / firewall-cmd — firewall

В следующих постах разберём каждый уровень с практическими примерами и командами.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#арсенал_инженера

🤩 Terragrunt 1.0 RC1

Разработчики Terragrunt уже на финишной прямой. Terragrunt — это обёртка над Terraform, которая устраняет дублирование конфигов, управляет remote state и зависимостями модулей.

Что в первом релиз-кандидате

Terragrunt перестроили под масштабируемость. Новый CLI упрощает команды, фильтр заменяет семь флагов вроде -terragrunt-include-dir. Stacks группируют связанные модули Terraform в единый деплой. Runner Pool ускоряет параллельные запуски, улучшает обработку ошибок.

В 1.x не сломается ничего критичного. Стабильны флаги CLI, HCL-конфиги, вывод find и reports.

RC1 — шанс повлиять на Terragrunt 1.0. Тестируйте stacks и runner pool в реальных воркфлоу.

➡️ Анонс

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#пульс_индустрии

📌 Ядерная кнопка для зависших подов

Иногда под зависает в состоянии «завершается» из-за проблем с монтированием тома и не уходит часами. В этот момент обычное удаление через kubectl delete pod уже не помогает.

В таких случаях можно использовать более жестокий вариант:

kubectl delete pod <имя-под> --grace-period=0 --force

--grace-period=0 говорит Kubernetes не ждать стандартный terminationGracePeriodSeconds и не давать контейнеру время на мягкое завершение.

--force просит сервер API немедленно убрать объект под из etcd.

Объект под удаляется из API сразу, но сам контейнер на узле может ещё какое-то время жить, пока kubelet не добьёт его.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#root_prompt

👨‍💻 Дебаг на физическом и канальном уровне

➡️ Первая часть

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

ip link show — проверка состояния интерфейсов:

ip link show

Ищите строку с state UP — интерфейс активен и готов передавать данные. Если видите state DOWN, проблема на этом уровне.

Что означает DOWN:

• Физические серверы: отсоединённый кабель, неисправный порт коммутатора, проблемы с сетевой картой.

• Виртуальные машины: проблема с виртуальным свитчем, неправильная привязка к VLAN, ошибки в конфигурации гипервизора.

Счётчики ошибок

ip -s link show eth0

Флаг -s показывает статистику. Смотрите на поля:

•errors — ошибки при передаче/приёме
dropped — отброшенные пакеты/нехватка буферов
overruns — переполнение буфера приёма
collisions — коллизии на старых half-duplex

Если эти значения растут — проблемы с передачей пакетов.

ethtool — детальная диагностика

ethtool eth0

Показывает:

• Link detected: yes/no — есть ли физический линк
• Speed — текущая скорость (1000Mb/s, 10000Mb/s)
• Duplex — full или half
• Auto-negotiation — включено ли автосогласование

Если Link detected: no, но интерфейс UP — физический линк отсутствует. Проверяйте кабель, порт коммутатора.

ARP таблица:

ip neighbour show
# или старый вариант:
arp -n

ARP связывает IP адреса с MAC адресами в локальной сети. Если для вашего gateway нет записи или она в состоянии FAILED — система не может определить MAC адрес шлюза.

Очистка ARP кеша:

ip neighbour flush all

Дальше разберём проблемы маршрутизации.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#арсенал_инженера

🍪 Топ-вакансий для девопсов за неделю

DevOps-инженер — от 180 000 с гибридом в Москве или на удалёнку.

MLOps\DevOps — удалёнка.

DevOps-инженер — от 250 000 ₽ на удалёнку.

➡️ Еще больше топовых вакансий — в нашем канале Devops Jobs

🐸Библиотека devops'a

#вакансия_недели

🤩 Чей сетап?

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#арсенал_инженера

💡 Диагностика сети: IP связность и маршрутизация

➡️ Предыдущая часть

Проверка базовой связности

Интерфейсы UP, ошибок нет — переходим к проверке IP связности. Команда ping — простой и эффективный тест:

ping 8.8.8.8

Google DNS 8.8.8.8 — хороший выбор для теста: стабильный, быстрый, разрешает ping. Если работает — базовая связь с интернетом есть. Если нет — копаем глубже.

Таблица маршрутизации

ip route show

Таблица маршрутизации определяет, куда система отправляет пакеты для разных сетей. Критичная запись — default gateway или маршрут по умолчанию:

default via 10.0.0.1 dev eth0

Это означает: все пакеты для неизвестных сетей отправляются через шлюз 10.0.0.1 на интерфейсе eth0.

Если этой записи нет — связь с внешним миром невозможна. Система не знает, куда отправлять пакеты.

Проверка default gateway

Убедитесь, что gateway находится в той же подсети, что и IP адрес интерфейса:

ip addr show eth0

Если IP 10.0.0.50/24, а gateway 10.0.1.1 — это конфликт. Маска /24 означает подсеть 10.0.0.0-10.0.0.255, gateway за её пределами.

Тестирование шлюза:

ping 10.0.0.1

Пингуем сам gateway. Это локальная сеть, должно работать. Если не работает:

1. Проблема с физической связностью (вернитесь к посту #2)
2. Проблема с ARP (проверьте ip neighbour show)
3. Шлюз недоступен или выключен

Проблемы с ARP:

ip neighbour show

Ищите запись для gateway IP. Должна быть строка типа:

10.0.0.1 dev eth0 lladdr aa:bb:cc:dd:ee:ff REACHABLE

Состояния ARP:
- REACHABLE — всё хорошо
- STALE — запись старая, но рабочая
- FAILED — не удалось определить MAC адрес
- INCOMPLETE — процесс определения не завершён

Если FAILED — gateway не отвечает на ARP запросы. Возможно, он выключен или есть проблемы на L2.

Специфичные маршруты

Кроме default gateway могут быть статические маршруты для конкретных сетей:

ip route show
10.20.0.0/16 via 10.0.0.5 dev eth0

Это говорит: для сети 10.20.0.0/16 используй другой шлюз — 10.0.0.5. Ошибка в таком маршруте может сломать связность с конкретным сегментом инфраструктуры.

Добавление маршрутов вручную

Временно (до перезагрузки):

ip route add default via 10.0.0.1 dev eth0
ip route add 10.20.0.0/16 via 10.0.0.5

Удаление маршрута:

ip route del 10.20.0.0/16

Для постоянных маршрутов редактируйте конфигурацию сети в /etc/sysconfig/network-scripts/route-eth0 (RHEL) или netplan конфиг (Ubuntu).

Traceroute — путь до цели:

traceroute 8.8.8.8

Показывает каждый хоп до цели. Полезно, когда ping не работает — увидите, где именно пакеты теряются.

Если traceroute зависает на определённом хопе — проблема там. Если все хопы показывают * * * — ICMP блокируется firewall.

mtr — улучшенный traceroute:

mtr 8.8.8.8

Комбинация ping и traceroute. Показывает latency и packet loss на каждом хопе в реальном времени. Более информативно, чем обычный traceroute.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#арсенал_инженера

🚀 9 способов найти заказы без бирж

Малый бизнес до сих пор не знает, где искать разработчиков. Кто-то спрашивает у знакомых, кто-то ищет на Авито, кто-то пишет в Telegram-чатах. Будьте на их пути — и первые заказы найдутся сами.

➡️ Самые топовые способы в статье

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

🤨 Прошу, прочти конфиг

Классическая ситуация: вы правите конфиг, применяете изменения, проверяете логи — а там всё по-старому. Приложение просто не знает, что конфигурация изменилась.

Когда под стартует, он монтирует ConfigMap как volume. Kubernetes обновляет содержимое этого volume автоматически, но:

• Большинство приложений читают конфиг один раз при запуске

• Они не следят за изменениями файлов

• Перечитывание конфига в рантайме — это дополнительная логика, которую надо реализовывать

Команда, чтобы конфиг точно перечитался:

kubectl rollout restart deployment <deployment-name>

Никакой магии — просто обычный rolling update, но без изменения версии образа.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#root_prompt

⚙️ top для systemd

systemd-cgtop — это инструмент из systemd для просмотра топа control groups по использованию CPU, памяти и I/O. Он обновляется каждую секунду и похож на классический top, но фокусируется на группах процессов.

Что показывает top:

PID  USER     CPU%  MEM%  COMMAND
1234 www-data 45.0  12.3  /usr/bin/php-fpm
5678 www-data 32.1  8.7   /usr/bin/php-fpm

Что показывает cgtop:

Control Group          Tasks  %CPU  Memory
/system.slice/nginx     12    78.2  2.1G
/system.slice/postgresql 8    23.4  1.8G
/system.slice/redis      4    12.1  512M

Разница критична: nginx может порождать сотни worker'ов, и в top вы увидите хаос из процессов. В systemd-cgtop — одна строка с суммарным потреблением.

Примеры команд:

# Что тормозит сервер?
systemd-cgtop --order=cpu

# Кто съел всю память?
systemd-cgtop --order=memory

# Кто нагружает диск?
systemd-cgtop --order=io

# Следить только за веб-сервисами
systemd-cgtop | grep -E '(nginx|apache|php)'

Полезные клавиши

В интерактивном режиме:

• p / t / c / m / i — сортировка по path/tasks/cpu/memory/io
• % — показать CPU в процентах или абсолютных значениях
• + / - — развернуть/свернуть дерево cgroups
• q — выход

Если вы используете systemd и хотите понять, какой сервис потребляет ресурсы, а не тонуть в списке процессов — systemd-cgtop ваш инструмент.

📍 Навигация: Вакансии • Задачи • Собесы

🐸 Библиотека devops'a

#aрсенал_инженера