🐍 Ansible, но на чистом Python

Управлять инфраструктурой через Ansible значит писать YAML. pyinfra убирает это из уравнения: деплой описывается обычным Python-кодом, без DSL и без новых концепций для изучения.

pyinfra решает именно это: вы описываете деплой обычным Python-кодом, без DSL и без новых концепций для изучения.

Что делает pyinfra

Превращает Python-скрипты в shell-команды и выполняет их на серверах по SSH, в Docker-контейнерах или локально. Работает без агентов, на целевых машинах ничего устанавливать не нужно.

Операции идемпотентны: если пакет уже установлен, повторный запуск ничего не сломает.

Установка:

pip install pyinfra

Быстрый старт прямо из CLI

Установить пакет на удалённый сервер или в Docker-контейнер в одну строку:

# На удалённый сервер
pyinfra my-server.net apt.packages iftop update=true _sudo=true

# В Docker-контейнер
pyinfra @docker/ubuntu apt.packages iftop update=true _sudo=true

Полноценный деплой-скрипт

Те же операции, оформленные в файл deploy.py:

from pyinfra.operations import apt, systemd

apt.packages(
    name="Установить nginx",
    packages=["nginx"],
    update=True,
    _sudo=True,
)

systemd.service(
    name="Запустить и включить nginx",
    service="nginx.service",
    running=True,
    restarted=True,
    enabled=True,
)

Инвентарь описывается в Python-файле inventory.py:

targets = ["web-1.example.com", "web-2.example.com", "@docker/ubuntu"]

Запуск:

pyinfra inventory.py deploy.py

Что важно знать

В скриптах доступен весь Python-экосистем: циклы, условия, импорт любых библиотек вроде boto3 или requests. Можно получать инвентарь из Terraform, работать с Docker и Vagrant. Перед реальным применением изменений можно сделать dry-run через флаг --dry.

Запуск с выводом всех команд для отладки:

pyinfra inventory.py deploy.py -v

pyinfra хорошо подходит командам, которые уже пишут на Python и хотят управлять инфраструктурой без перехода на отдельный язык конфигурации.

➡️ Репозиторий

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

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

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

🤠 Fedora 44 вышла

Fedora Project выпустила очередной релиз. В этот раз обновилось сразу несколько крупных компонентов, и часть изменений потребует внимания перед обновлением.

Что изменилось

Anaconda теперь создаёт сетевые профили только для тех устройств, которые настраивались при установке. Раньше профили создавались для всех интерфейсов по умолчанию и это часто приводило к лишним записям и путанице в конфигурации после установки.

Загрузка OpenSSL ускорилась: добавлена поддержка directory-hash для ca-certificates. Для большинства задач это незаметно, но на серверах с частыми SSL-операциями разница будет ощутима.

Fedora 44 включает Ansible 13. Если вы используете плейбуки, проверьте руководство по миграции, часть синтаксиса изменилась.

MariaDB перешла на версионированную схему пакетов: теперь пакет называется mariadb11.8. При обновлении стоит проверить, что скрипты и конфиги ссылаются на правильные пути.

Для тех, кто запускает Windows-приложения через Wine или Steam: в ядро добавлен модуль NTSYNC. Он улучшает совместимость и производительность. Установите пакет wine-ntsync, и он будет подключаться автоматически при каждой загрузке.

Рабочие окружения

Workstation-версия идёт с GNOME 50. Улучшения в accessibility, управлении цветом и remote desktop. Также обновились стандартные приложения: просмотрщик документов, файловый менеджер, календарь.

KDE-версия получила Plasma 6.6 с новым менеджером входа и мастером настройки. Fedora KDE теперь полностью поддерживается в Fedora Ready.

В облачной версии раздел /boot заменён на btrfs-субтом — образы стали меньше и лучше используют дисковое пространство.

Как обновиться

Если уже используете Fedora, обновитесь через стандартный механизм:

sudo dnf upgrade --refresh
sudo dnf install dnf-plugin-system-upgrade
sudo dnf system-upgrade download --releasever=44
sudo dnf system-upgrade reboot

➡️ Источник

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

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

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

👨‍💻 Альтернатива systemd для управления сервисами

runit это минималистичная система инициализации с автоматическим надзором за процессами. Сервис упал, runit его перезапустит без лишних настроек.

runit работает в три этапа: инициализация системы, надзор за сервисами и корректное завершение работы. Основа это runsvdir, который следит за директориями сервисов и запускает runsv для каждого из них.

Конфигурация сервиса это shell-скрипт. Без YAML, без XML, без многостраничной документации.

Установка:

# Debian/Ubuntu
sudo apt-get install runit

# Arch Linux
sudo pacman -S runit

# CentOS/RHEL
sudo dnf install runit

Создать сервис

Структура минимальная: директория с исполняемым файлом run.

sudo mkdir -p /etc/sv/webserver

sudo tee /etc/sv/webserver/run << 'EOF'
#!/bin/sh
exec 2>&1
cd /var/www/html
exec python3 -m http.server 8080
EOF

sudo chmod +x /etc/sv/webserver/run

# Включить сервис
sudo ln -s /etc/sv/webserver /etc/service/

Два ключевых правила в run-скрипте: использовать exec вместо запуска в фоне и перенаправлять stderr через exec 2>&1. Программа должна работать на переднем плане, runit сам управляет процессом.

Основные команды через sv:

sv start webserver    # запустить
sv stop webserver     # остановить
sv restart webserver  # перезапустить
sv status webserver   # статус

Пример вывода статуса:

run: nginx: (pid 1234) 3600s
down: mysql: 120s, normally up

Логирование через `svlogd`

runit поставляется с собственным логгером. Он умеет в ротацию, фильтрацию и временны́е метки.

sudo mkdir -p /etc/sv/webserver/log

sudo tee /etc/sv/webserver/log/run << 'EOF'
#!/bin/sh
exec svlogd -tt /var/log/webserver
EOF

sudo chmod +x /etc/sv/webserver/log/run
sudo mkdir -p /var/log/webserver

Как выглядит миграция с systemd

Типичный unit-файл systemd:

[Service]
Type=simple
User=webuser
WorkingDirectory=/opt/webapp
ExecStart=/opt/webapp/bin/server
Restart=always

Эквивалент в runit:

#!/bin/sh
exec 2>&1
cd /opt/webapp
exec chpst -u webuser /opt/webapp/bin/server

chpst — утилита из runit для запуска процессов от другого пользователя и с ограничениями по ресурсам.

Это не замена systemd в полноценном десктопном окружении, но для серверных задач вполне рабочий вариант.

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

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

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

💻 HCP Terraform на базе Infragraph вышел в публичный превью

HashiCorp объявила о публичном превью HCP Terraform powered by Infragraph на конференции IBM Think 2026. Доступ откроется с 8 мая для квалифицированных US-клиентов HCP Terraform.

Какую проблему решает

Команды, работающие с гибридными и мультиоблачными инфраструктурами, хорошо знают эту боль: данные о ресурсах разбросаны по разным инструментам, нет единой картины того, что происходит в AWS, Azure, GCP и on-prem одновременно.

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

Что такое Infragraph

Infragraph это централизованный граф знаний с событийно-ориентированным обновлением данных. Он подключается напрямую к вашим облачным провайдерам и собирает актуальное состояние инфраструктуры в одном месте. Для более глубоких или кастомных потоков данных доступен Terraform Search.

Зачем это нужно:

• Единый источник правды по всему estate: AWS, Azure, GCP, on-prem

• Запросы к инфраструктуре на естественном языке для CloudOps и security-команд

• Актуальная информация о том, кто владеет ресурсами и за что отвечает

• Основа для будущей автоматизации через AI-агентов

Первые шаги после входа:

1. Добавьте подключение к AWS, HCP Terraform и HCP Packer — увидите, как ваш cloud estate связан с инфраструктурой как кодом
2. Запросите неуправляемые ресурсы или ресурсы со старой версией Terraform

# Пример: вход в HCP-консоль
https://portal.cloud.hashicorp.com/sign-in
→ Infragraph → Connections → Add connection

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

➡️ Блог разработчиков

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

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

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

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

DevOps / Platform Engineer — до 220 000 ₽ на удалёнке

DevOps-инженер — удалёнка

Senior DevOps Engineer — от 300 000 ₽, гибрид/удалёнка в Москве или СПб

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

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

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

🔄 pyinfra 3.8.0. Крупный релиз с фиксами безопасности и новыми Docker-операциями

Вышла новая версия инструмента для автоматизации инфраструктуры на чистом Python. Заодно проект перешёл на полный semver: теперь версии будут выглядеть как 3.8.0 вместо 3.8.

Безопасность

Пожалуй, самое важное в этом релизе. Все пользовательские значения теперь экранируются при построении команд, это закрывает потенциальные векторы command injection в коннекторах, операциях и утилитах.

Docker стал полноценным

Добавили целый блок новых операций:

• operations.docker.compose — управление через Docker Compose

• operations.docker.build — сборка образов

• operations.docker.login / logout — аутентификация в реестре

Плюс новые факты: версия Docker, детали контейнеров, образов и сетей.

Новые факты и операции

• facts.server.Ports — список всех портов в состоянии LISTEN на хосте.

• facts.server.Processes + server.kill — получить список процессов и завершить нужный.

• facts.server.AuthorizedKeys — чтение authorized_keys, операция user_authorized_keys стала идемпотентной.

• operations.files.unarchive — распаковка архивов как отдельная операция.

• operations.files.download — теперь поддерживает limit_rate для ограничения скорости загрузки.

• operations.git.repo — добавили параметр depth для shallow clone.

Поддержка uv

Добавлены факты и операции для работы с uv — Python-пакетным менеджером. Пример использования стал стандартным для проекта: все примеры в репозитории теперь запускаются через uv run pyinfra.

APT и пакетные менеджеры

• facts.apt.AptSources теперь понимает формат deb822 — современный способ записи источников в Debian/Ubuntu.

• apt.packages получил параметр purge для полного удаления пакетов вместе с конфигами.

• apt.key обновлён под современный подход без устаревшей команды apt-key.

Прочее

• config.INHERIT_ENV — новый параметр для передачи переменных окружения локального процесса во все операции.

• dzdo — добавлена поддержка как альтернативы sudo для повышения привилегий.

• Поддержка paramiko v4, совместимость с Python 3.14, ленивая загрузка модулей фактов и операций для ускорения старта.

Обновиться:

pip install --upgrade pyinfra

➡️ Тэг на GitHub

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

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

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

GitHub, если бы его делали Electronic Arts

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

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

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

🧑‍💻 Kernel Panic при загрузке: находим причину и чиним

Сервер не поднимается после перезагрузки. Экран с kernel panic, и всё. Это одна из тех ситуаций, когда важно действовать методично, а не наугад.

Что обычно ломается

Три самые частые причины:

• Повреждённый /etc/fstab. Если UUID раздела не совпадает с тем, что прописано в файле, система не может смонтировать диск и падает на старте.

• Проблемы с GRUB. После обновления ядра или ручной правки конфига загрузчик может потерять путь к системе.

• Аппаратные сбои. Отказ диска или памяти тоже проявляется как panic при загрузке, поэтому железо стоит проверить сразу.

Как чинить

Загружаемся в recovery mode. В меню GRUB выбираем Advanced options и строку с (recovery mode). Получаем root-шелл без монтирования основной системы.

Проверяем диск:

fsck -f /dev/sda1

fsck найдёт и исправит ошибки файловой системы. Флаг -f запускает проверку даже если диск помечен как чистый.

Сверяем UUID в /etc/fstab:

blkid

Вывод покажет реальные UUID всех разделов. Открываем /etc/fstab и проверяем, что значения совпадают. Расхождение в одном символе — и система не загрузится.

Если проблема в GRUB, переустанавливаем его:

grub-install /dev/sda
update-grub

/dev/sda — диск, не раздел. Убедитесь, что указываете устройство без цифры на конце.

Как не попасть в это снова

Перед любыми правками в /etc/fstab или конфигах загрузчика делаем бэкап:

cp /etc/fstab /etc/fstab.bak

Изменения в загрузочной конфигурации тестируем на staging-окружении. Продакшн-сервер — плохое место для экспериментов с GRUB.

Если инфраструктура позволяет, настраиваем снапшоты перед каждым обновлением ядра. Откатиться за 30 секунд гораздо приятнее, чем чинить вручную в 3 ночи.

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

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

#root_prompt

📎 Дублируем root

В Linux права определяются не именем пользователя, а его UID. У root всегда UID=0. Если создать пользователя с тем же UID=0, система будет воспринимать его как root со всеми вытекающими правами.

Добавляем запись напрямую в /etc/passwd. Открываем файл:

sudo vipw

Добавляем строку в конец файла:

superadmin:x:0:0:Super Admin:/root:/bin/bash

Ставим пароль новому пользователю:

sudo passwd superadmin

Проверяем, что всё работает:

id superadmin
#uid=0(root) gid=0(root) groups=0(root)

Альтернатива через useradd

Команда useradd не позволяет напрямую задать UID=0, но можно создать пользователя и потом поправить запись:

sudo useradd -o -u 0 -g 0 -d /root -s /bin/bash superadmin
sudo passwd superadmin

Флаг -o разрешает дублирование UID. Без него команда завершится с ошибкой.

Если вы используете sudo, убедитесь что новый пользователь тоже может его вызывать. Добавьте строку в /etc/sudoers через visudo:

superadmin ALL=(ALL:ALL) ALL

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

Два аккаунта с UID=0 означают двойную поверхность атаки. Следите за тем, кому и зачем открываете такой доступ и включайте аудит действий через auditd или аналоги.

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

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

#root_prompt

🖥 Cмотрим, что реально делает GPU

GPU загружен на 95% — звучит хорошо. Но это ничего не говорит о том, занят ли он полезной работой или просто ждёт данных. Стандартные метрики показывают занятость, но не эффективность.

utilyze решает именно эту проблему. Он измеряет SOL (Speed-of-Light) — насколько GPU использует свой теоретический максимум по вычислениям и пропускной способности памяти. И делает это в реальном времени, не замедляя нагрузку.

Что под капотом

Инструмент написан на Go и C++, использует NVIDIA CUPTI и Perf SDK для сбора аппаратных счётчиков. Работает на Linux amd64, требует GPU архитектуры Ampere и CUDA 11.0+.

Установка:

curl -sSfL https://systalyze.com/utilyze/install.sh | sh

При установке потребуется sudo — инструмент ставится системно. Если CUPTI 12+ не найден, при первом запуске предложит доустановить его через PyPI.

Запуск:

# мониторинг всех GPU
sudo utlz

# только конкретные устройства
sudo utlz --devices 0,2

# показать эндпоинты инференс-серверов на каждом GPU
sudo utlz --endpoints

По умолчанию NVIDIA ограничивает доступ к профилировочным счётчикам для не-root пользователей.

Чтобы запускать без sudo, нужно один раз отключить это ограничение:

echo 'options nvidia NVreg_RestrictProfilingToAdminUsers=0' | sudo tee /etc/modprobe.d/nvidia-profiling.conf
sudo reboot

Поддержка инференс-серверов

utlz умеет обнаруживать эндпоинты инференс-серверов и показывать roofline-потолки для каждого GPU — то есть, какой максимум достижим при текущей конфигурации. Сейчас поддерживается только vLLM, поддержка других бэкендов заявлена.

Сборка из исходников

Если нужна сборка самостоятельно — потребуется Go 1.25+, Docker и CUDA Toolkit:

# собрать нативную библиотеку и CLI
make all

# только CLI
make utlz

Есть экспериментальная поддержка ARM64 через sbsa-linux CUDA target.

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

➡️ Репозиторий

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

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

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

🧠 Мини-тест

Какой тип Kubernetes использует внешний балансировщик облачного провайдера?

А) ClusterIP
Б) NodePort
В) LoadBalancer
Г) ExternalName

👉 Пишите ответ в комментариях, а ответ смотрите здесь

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

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

#задача_со_звёздочкой

🚮 Drop правила для фильтрации мусорных логов
 
Если вы используете Grafana Cloud Logs, скорее всего, часть логов там вообще не нужна. Health check каждые 5 секунд, DEBUG-записи из забытого сервиса, многословный INFO из batch-джобы — всё это идёт в хранилище и увеличивает счёт.
 
Раньше убрать этот мусор было неудобно. Нужно было лезть в конфиги, договариваться с командами, менять пайплайн. Теперь в Adaptive Logs появились drop rules — правила, которые отфильтровывают ненужные логи до записи в хранилище.
 
Что делают drop rules
 
Правило задаёт условие: какие логи отбрасывать и с какой долей. Можно указать лейбл сервиса, уровень лога, строку в теле — или всё вместе. Поддерживается частичный дроп: например, оставить 10% от потока, а остальное не сохранять.
 
Несколько сценариев, где это полезно:
 
Если payment-service в продакшне шлёт DEBUG-логи, которые никто не смотрит:

service_name = payment-service
log_level = DEBUG
drop rate = 100%

 
Batch-джоба пишет одно и то же тысячи раз в день. Оставляем 10% для выборки:

service_name = batch-processor
drop rate = 90%

 
Выбросить конкретный паттерн. Сервис пишет GET /healthz 200 каждые несколько секунд. Указываем строку в теле лога и дропаем 100%.
 
Как это работает внутри
 
Каждый входящий лог проходит три шага по порядку:
 
1. Exemptions — если лог попадает под исключение, он записывается без изменений.

2. Drop rules — правила применяются по приоритету. Первое совпавшее правило задаёт процент дропа.

3. Patterns — к оставшимся логам применяются рекомендации от самого Adaptive Logs на основе анализа 15 дней запросов.

Exemptions нужны для логов, которые нельзя терять ни при каких условиях, — аудит, ошибки из критичных сервисов. Drop rules — для того, что точно не нужно. Patterns — для всего остального, что Grafana сама определит как малоценное.
 
Как начать
 
Функция доступна в public preview в Grafana Cloud. Нужна роль plugins:grafana-adaptivelogs-app:admin — по умолчанию она есть у Grafana Admin и Org Admin.
 
Путь в интерфейсе:
Adaptive Telemetry → Adaptive Logs → Drop rules → Create a new drop rule
 
Управлять правилами также можно через CLI gcx если нужна автоматизация или интеграция с агентами.
 
➡️ Репозиторий

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

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

#root_prompt

🔄 Вышел Incus 7.0 LTS
 
Команда Linux Containers выпустила Incus 7.0 LTS — второй долгосрочный релиз менеджера системных и OCI-контейнеров, а также виртуальных машин.

Поддержка продлится до июня 2031 года: первые два года патчи и небольшие улучшения, ещё три года только безопасность.
 
В релизе закрыты 9 CVE умеренной и низкой степени опасности. Среди важных изменений — удаление поддержки CGroupV1 и xtables, повышение минимальных требований к системе, а также правки в CLI. Minio заменён встроенным S3-слушателем.
 
Из новых возможностей: низкоуровневое API для бекапов, ограничение пулов хранилища по проектам, поддержка OCI-контейнеров, сетевые наборы адресов network address sets, драйверы хранилища Linstor и TrueNAS, а также перебалансировка кластера через placement scriptlet.
 
➡️ Полный changelog | онлайн-демо

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

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

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

📎 Только имя пода и образ

Иногда нужен простой список подов и их образов. Без лишних колонок, без шума. kubectl get pods -o wide выдаёт слишком много данных, которые в этот момент не нужны.

Для таких случаев есть флаг -o custom-columns. Он позволяет выбрать только те поля, которые важны прямо сейчас.

Чтобы получить таблицу с именем пода и образом контейнера, достаточно одной команды:

kubectl get pods -o custom-columns='NAME:.metadata.name,IMAGE:.spec.containers[*].image'

Результат — чистая таблица без лишнего. [*] в пути означает, что команда учитывает все контейнеры в поде, включая сайдкары.

Формат колонки строится по простому правилу: сначала заголовок, потом путь к полю в JSON-структуре объекта. Любое поле из kubectl get pod -o json можно вытащить таким же способом.

Это особенно удобно в скриптах и CI, где важна предсказуемость вывода. Никаких сюрпризов при обновлении версии kubectl.

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

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

#root_prompt

🗓 14 мая в 19:00 (Мск) встречаемся в онлайне.

Тема: Почему AI-продукты на базе LLM ломаются и как сделать, чтобы работало.

В кружке выше Эмиль Сатаев рассказал, какие именно проблемы с LLM в проде будем разбирать.

Что в программе:

- Разберем реальные кейсы стартапов и ограничения LLM.
- Обсудим рабочие архитектуры: RAG, human-in-the-loop, контроль качества.
- Ответим на ваши вопросы и разберем кейсы участников.

🎁 Бонусы: в конце вебинара подарим промокод на скидку 10.000 ₽ на курсы и разыграем подписки на полезные AI-сервисы.

👉 Зарегистрироваться на вебинар

📰 Админ расплавился от жары

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

— Раньше алгоритмы, а теперь симуляция директора

— apt 3.3.0

— Fedora 44

— HCP Terraform на базе Infragraph

— pyinfra 3.8.0

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

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

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

👎 Автоматическая блокировка нежелательных подключений

Любой публичный сервер рано или поздно начинает получать тысячи попыток подбора паролей. SSH, веб-панели, почтовые серверы — всё это регулярно атакуют боты. Вручную отслеживать такие попытки и добавлять IP в блокировку нереально. Fail2Ban решает именно эту задачу.

Что делает

Fail2Ban это демон, который читает лог-файлы и временно блокирует IP-адреса, с которых зафиксировано слишком много ошибок аутентификации. Блокировка происходит через правила файрвола (iptables, nftables и другие). После истечения времени бана IP автоматически разблокируется.

Из коробки поддерживаются логи SSH, Apache, Nginx, Postfix и многих других сервисов. Можно подключить любой лог-файл с произвольным форматом.

Установка

На большинстве дистрибутивов пакет уже есть в репозитории:

# Debian/Ubuntu
sudo apt install fail2ban

# RHEL/CentOS
sudo dnf install fail2ban

После установки проверяем, что всё работает:

fail2ban-client -h
fail2ban-client version

Как это настраивается

Конфигурация хранится в /etc/fail2ban. Основной файл — jail.conf, но менять его напрямую не стоит. Вместо этого создаём /etc/fail2ban/jail.local и переопределяем нужные параметры.

Пример минимальной конфигурации для защиты SSH:

[sshd]
enabled = true
port    = ssh
logpath = /var/log/auth.log
maxretry = 5
bantime  = 3600
findtime = 600

maxretry — сколько неудачных попыток допускается за период findtime (в секундах). Если их больше, IP блокируется на bantime секунд.

В данном примере пять ошибок за 10 минут приведут к блокировке на час.

Управление банами

Посмотреть активные джейлы и заблокированные IP:

sudo fail2ban-client status
sudo fail2ban-client status sshd

Разблокировать IP вручную:

sudo fail2ban-client set sshd unbanip 1.2.3.4

Fail2Ban снижает нагрузку от перебора, но не заменяет нормальную аутентификацию.

Если сервис работает на паролях, лучше перейти на ключи или двухфакторку. Fail2Ban при этом остаётся полезным дополнительным слоем защиты.

➡️ Репозиторий

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

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

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

📎 Узнать текущий runlevel в Linux

Runlevel определяет режим работы системы: что запущено, какие сервисы активны, есть ли графический интерфейс. Это понятие пришло из SysV init и до сих пор встречается, особенно на старых дистрибутивах и серверах, где systemd ещё не везде.

Стандартные уровни

0 — выключение системы.
1 — однопользовательский режим, только root, сеть не поднята. Используется для восстановления.
2 — многопользовательский без NFS (в Debian/Ubuntu — полноценный многопользовательский).
3 — многопользовательский с сетью, без графики. Типичный режим для серверов.
4 — не используется стандартно, резерв.
5 — многопользовательский с графическим интерфейсом.
6 — перезагрузка.

Как проверить

Команда runlevel выводит предыдущий и текущий уровень:

runlevel

Вывод выглядит так:

N 3

N означает, что предыдущего уровня не было (система только загрузилась). 3 — текущий runlevel.

На системах с systemd та же команда работает, но под капотом systemd транслирует уровни в targets. Можно спросить напрямую:

systemctl get-default

Это покажет default target — то, в каком режиме система запускается по умолчанию:

multi-user.target

А текущее активное состояние:

systemctl list-units --type=target --state=active

Когда это нужно

Чаще всего runlevel проверяют при диагностике — когда нужно понять, почему сервис не запустился, или убедиться, что сервер поднялся в правильном режиме после перезагрузки.

На современных системах с systemd runlevel остаётся для совместимости, но systemctl get-default даёт более точный ответ.

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

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

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

🔄 NWinfo v1.6.3

NWinfo собирает информацию из SMBIOS, CPUID, S.M.A.R.T., PCI, SPD, EDID и ряда других источников.

Запуск в CLI:

nwinfo.exe --format=json > report.json

Или через готовый PowerShell-скрипт из репозитория:

.\hw_report.ps1

Что появилось в v1.6.3

Основные изменения касаются работы с процессорами Intel и AMD.

Для Intel добавлены сенсоры через MCHBAR и PCH, определение микроархитектуры, OC Mailbox API для чтения данных по разгону, отображение TDP и VDDQ TX IccMax/Voltage. Исправлено чтение напряжений через MSR.

Для AMD исправлена PM-таблица для Pinnacle Ridge, обновлён ryzen_smu.c.
Из общих изменений: системный трей с возможностью установки PawnIO прямо из него, настраиваемые единицы температуры (Цельсий / Фаренгейт), отключён WoW64-редирект реестра для корректного чтения на 64-битных системах, обновлены libcpuid и Nuklear.

➡️ Источник

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

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

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