RECURA | Программирование & IT

🌐 Nginx может кэшировать ответы отдельно для каждого варианта сжатия и не смешивать форматы

👁 При проксировании API и раздаче статики кэш часто усложняется из-за gzip, Brotli и заголовков клиента. Если сервер отдаёт разные представления одного ресурса, кэш должен учитывать соответствующие признаки запроса, иначе можно получить некорректный ответ для клиента.

📝 Учитываем поддержку сжатия при выборе кэшируемого представления:

Вместо того чтобы добавлять весь Accept-Encoding в ключ кэша, нормализуйте его до нужных вариантов. Так клиенты с разными наборами параметров не создадут десятки почти одинаковых записей.

http {
map $http_accept_encoding $encoding_variant {
"~*br" br;
"~*gzip" gzip;
default identity;
}

proxy_cache_path /var/cache/nginx
keys_zone=assets:20m
levels=1:2
inactive=1h;

server {
location /assets/ {
proxy_cache assets;
proxy_cache_key "$scheme$proxy_host$request_uri|$encoding_variant";
proxy_pass http://static_backend;
}
}
}

📝 Запрещаем кэшировать персонализированные ответы:

Ответы, зависящие от авторизации или пользовательских cookies, опасно складывать в общий кэш без специальной стратегии. Можно отключать кэширование таких запросов.

map $http_authorization $skip_auth_cache {
"" 0;
default 1;
}

map $http_cookie $skip_cookie_cache {
"" 0;
default 1;
}

server {
location /api/ {
proxy_cache api_cache;
proxy_cache_bypass $skip_auth_cache $skip_cookie_cache;
proxy_no_cache $skip_auth_cache $skip_cookie_cache;

proxy_pass http://api_backend;
}
}

📝 Проверяем, откуда пришёл ответ:

Добавьте диагностический заголовок, чтобы видеть, был ли ответ получен из кэша или передан от upstream. Это упрощает поиск ошибок при настройке ключей и правил обхода кэша.

location /assets/ {
proxy_cache assets;
add_header X-Cache-Status $upstream_cache_status always;

proxy_pass http://static_backend;
}

❗️ Важно: первый пример корректен только если upstream действительно выдаёт представления, соответствующие выбранному варианту кодирования. Простая проверка подстроки br или gzip не является полноценным разбором Accept-Encoding и может неверно обработать q=0. Если сжатие выполняет сам Nginx, обычно безопаснее использовать штатные механизмы сжатия и корректный Vary: Accept-Encoding. Для персонализированных ответов также учитывайте cookies, авторизацию и заголовки управления кэшем от upstream.

tags: #nginx #производительность #разработка

🧭 @recura_tech

👨‍💻 Sqlit

👁️ Терминальный интерфейс для подключения к базам данных и выполнения SQL-запросов с поддержкой Vim-подобного управления.

Поддерживает PostgreSQL, MySQL, SQLite, ClickHouse и десятки других СУБД, умеет автоматически находить запущенные контейнеры с базами данных и подключаться к удалённым серверам через SSH-туннели. Есть история запросов, автодополнение SQL, фильтрация больших результатов, менеджер подключений и защищённое хранение паролей в системном хранилище.

❗ Подойдёт разработчикам и администраторам, которые регулярно работают с несколькими СУБД и предпочитают терминальные инструменты.

GitHub

tags: #утилиты #sql #полезно

🧭 @recura_tech

🤖 Yahont

👁️ Платформа для развёртывания корпоративного ИИ-помощника на собственном сервере с доступом к знаниям из рабочих приложений.

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

❗ Подойдёт командам, которым нужны корпоративная база знаний, поиск по переписке и документам, а также агенты для поддержки и онбординга.

Проверить в деле

tags: #утилиты #ии

🧭 @recura_tech

🐧 Linux может показать, какие процессы действительно тормозят диск, даже если iostat не объясняет задержки

👁 Высокая загрузка диска не всегда означает, что именно диск стал узким местом. Процессы могут надолго зависать в ожидании ввода-вывода, а средняя загрузка устройства не показывает, какие задачи испытывают задержки и как это отражается на системе. Для диагностики пригодятся PSI и трассировка блочного ввода-вывода.

📝 Проверяем давление из-за дисковых операций:

PSI показывает, сколько времени задачи теряют из-за ожидания ресурсов. Файл io позволяет быстро проверить, есть ли заметное давление ввода-вывода.





cat /proc/pressure/io
watch -n 1 cat /proc/pressure/io

📝 Находим процессы с накопленным временем ожидания I/O:

В /proc/PID/stat поле 42 — delayacct_blkio_ticks — содержит задержку процесса из-за блочного ввода-вывода в тактах ядра, если доступен соответствующий учёт задержек. Для быстрой диагностики можно посмотреть это значение у процессов с большим временем ожидания.





sudo bash -c '
for f in /proc/[0-9]*/stat; do
[ -r "$f" ] || continue
read -r line < "$f" || continue
rest=${line##*) }
set -- $rest
delay=${40}
pid=${f#/proc/}
pid=${pid%/stat}
printf "%12s %s\n" "$delay" "$pid"
done
' | sort -nr | head

📝 Записываем реальные задержки блочных запросов:

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





sudo bpftrace -e '
tracepoint:block:block_rq_issue {
@start[args->dev, args->sector] = nsecs;
}
tracepoint:block:block_rq_complete {
$key = (args->dev, args->sector);
if (@start[$key]) {
@latency_ms = hist((nsecs - @start[$key]) / 1000000);
delete(@start[$key]);
}
}'

❗️ Главное: PSI быстро показывает влияние I/O на задачи, а трассировка помогает исследовать задержки на уровне блочных запросов. Учитывайте, что доступность полей /proc зависит от конфигурации ядра, а привязка запросов по устройству и сектору в упрощённом BPF-примере не является надёжным способом сопоставления всех операций на нагруженном устройстве.

tags: #linux #производительность

🧭 @recura_tech

🌎 psad

👁️ Лёгкий демон обнаружения вторжений, анализирующий журналы iptables и ip6tables для выявления подозрительной сетевой активности.

Утилита обнаруживает сканирование портов TCP и UDP, распознаёт сигнатуры Snort, определяет потенциальные угрозы и присваивает им уровни опасности. Поддерживает IPv4 и IPv6, уведомления по электронной почте и syslog, анализ журналов и автоматическую блокировку подозрительных IP-адресов по заданным правилам.

❗ Подойдёт системным администраторам и специалистам по безопасности для мониторинга сетевых атак и дополнения существующих средств защиты, таких как Fail2ban и Snort.

GitHub

tags: #утилиты #сети #безопасность

🧭 @recura_tech

👨‍💻 Bash-Agent

👁️ Минималистичная среда выполнения для ИИ-агентов, работающих с кодом, без тяжёлых зависимостей и отдельных сред выполнения.

Проект поддерживает Bash, C, Go и Rust с общей семантикой сессий и инструментов, а также параллельное выполнение подзадач через SubAgent. Сессии можно сохранять, возобновлять и ветвить, а структурированный вывод событий, система Skills и компактизация контекста помогают управлять работой агентов.

❗ Подойдёт разработчикам, которые создают ИИ-агентов для работы с кодом и ищут минималистичную среду на базе Bash.

Проверить в деле

tags: #утилиты #ии #bash

🧭 @recura_tech

🐍 Python может автоматически останавливать зависшие процессы, не оставляя дочерние задачи работать в фоне

👁 При автоматизации через subprocess недостаточно установить тайм-аут: если команда запускает дочерние процессы, завершение родительского процесса не гарантирует остановку всей цепочки. В Linux можно запускать каждую задачу в отдельной группе процессов и при превышении лимита завершать всю группу.

📝 Запускаем команду с контролем времени и всей группы процессов:





import os
import signal
import subprocess

def run_task(command: list[str], timeout: int = 30) -> str:
proc = subprocess.Popen(
command,
stdout=subprocess.PIPE,
stderr=subprocess.STDOUT,
text=True,
start_new_session=True,
)

try:
output, _ = proc.communicate(timeout=timeout)
except subprocess.TimeoutExpired:
try:
os.killpg(proc.pid, signal.SIGTERM)
except ProcessLookupError:
pass

try:
output, _ = proc.communicate(timeout=3)
except subprocess.TimeoutExpired:
try:
os.killpg(proc.pid, signal.SIGKILL)
except ProcessLookupError:
pass
output, _ = proc.communicate()

raise TimeoutError(
f"Команда превысила лимит {timeout} с.\n{output}"
)

if proc.returncode != 0:
raise subprocess.CalledProcessError(
proc.returncode, command, output=output
)

return output

print(run_task(["python", "-c", "print('Задача выполнена')"]))

📌 Как это работает:

• start_new_session=True создаёт новую сессию, в которой процесс становится лидером своей группы.
• communicate(timeout=...) ограничивает время ожидания и одновременно считывает вывод, предотвращая переполнение каналов.
• При тайм-ауте сначала отправляется SIGTERM, а затем SIGKILL, если процесс не завершился за три секунды.

❗️ Важно: завершение группы охватывает процессы, которые остаются в ней. Если дочерний процесс самостоятельно создаст новую сессию или группу, этот способ не гарантирует его остановку. Для жёсткой изоляции недоверенных задач лучше использовать отдельный cgroup или системный менеджер служб.

tags: #python #автоматизация #linux

🧭 @recura_tech

🗳️ ProxSave

👁️ Утилита для резервного копирования и аварийного восстановления конфигураций Proxmox VE и Proxmox Backup Server (PBS).

Инструмент поддерживает резервное копирование без простоев, пошаговое восстановление, шифрование и облачные хранилища, а также автоматическое управление копиями и интеграцию с PBS. Уведомления можно получать через Telegram, электронную почту, Gotify и веб-хуки, а мониторинг подключать через Prometheus.

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

GitHub

tags: #утилиты #proxmox #devops

🧭 @recura_tech

🤖 Pi

👁️ Инструментарий для создания и запуска ИИ-агентов с единым API для языковых моделей, собственным терминальным интерфейсом и средствами разработки.

Агенты могут работать с файлами, выполнять команды и редактировать код, используя модели более чем 15 провайдеров, включая OpenAI, Anthropic, Google и локальные модели через Ollama. История сессий поддерживает ветвление и продолжение работы, а система Skills позволяет подключать дополнительные инструкции и инструменты на лету.

❗ Подойдёт разработчикам, создающим ИИ-агентов и автоматизирующим задачи прямо в терминале.

Проверить в деле

tags: #утилиты #ии #разработка

🧭 @recura_tech

👨‍💻 Bash может передавать большие объёмы данных между процессами без временных файлов

👁 В автоматизации часто приходится связывать несколько утилит так, чтобы одна команда читала данные другой, а скрипт при этом сохранял возможность управлять обоими процессами. Для этого пригодится coproc — механизм Bash для запуска фонового процесса с двунаправленными каналами ввода-вывода.

📝 Запускаем долгоживущий обработчик:

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





coproc WORKER {
while IFS= read -r line; do
printf 'Обработано: %s\n' "${line^^}"
done
}

printf '%s\n' "nginx" "bash" "linux" >&"${WORKER[1]}"

📝 Читаем ответы, не блокируя поток данных вручную:

У coproc есть дескрипторы для записи и чтения. Забирайте ответы по мере поступления, а не складывайте весь результат во временный файл.





while IFS= read -r -t 1 line <&"${WORKER[0]}"; do
printf 'Ответ: %s\n' "$line"
done

📝 Корректно завершаем фоновый процесс:

После передачи данных закройте канал записи, чтобы обработчик получил EOF и вышел из цикла. Затем дождитесь его завершения через wait.





exec {WORKER[1]}>&-
wait "$WORKER_PID"

❗️ Когда это полезно: для постоянных обработчиков, интерактивных утилит и конвейеров автоматизации, где нужно обмениваться данными без промежуточных файлов. Учитывайте, что чтение с -t может завершиться по тайм-ауту, а при закрытии дескрипторов важно не оставить процесс ожидающим ввода.

tags: #bash #автоматизация

🧭 @recura_tech