Вышла SQLite 3.50

Состоялся релиз легковесной СУБД SQLite 3.50. Проект написан на C, распространяется без лицензий и бесплатно.

Поддержку разработчикам оказывает отдельный консорциум.

Основные изменения:
⏺Новая функция sqlite3_setlk_timeout() для управления блокировками.
⏺Ослаблены ограничения на SQL-комментарии.
⏺Добавлены SQL-функции unistr() и unistr_quote().
⏺Улучшена работа printf(), .dump, .schema --indent.
⏺Оптимизация JSON-функций и улучшение sqlite3_rsync.
⏺Поддержка сборки под Cygwin, MinGW, Termux.
⏺Исправления и улучшения производительности.
⏺WASM/JavaScript: важное обновление VFS OPFS SAHPool — новые базы несовместимы со старыми VFS, но обратно совместимость сохранена.

Используем iptables hashlimit + recent вместо fail2ban

Когда fail2ban уже не справляется или слишком медленный, пора перейти на уровень ниже — к iptables.

Сочетание --hashlimit и --recent даёт мощный инструмент контроля попыток подключения к SSH без необходимости читать логи и запускать демоны.

Защитить порт 22 от перебора и сканеров

Входящие подключения должны:
⏺быть не чаще X раз в минуту с одного IP (аналог hashlimit),
⏺блокироваться при агрессивной активности (аналог recent),
⏺не мешать своим или автоматическим задачам (допускаем trusted IP или подсети).

1️⃣Разрешаем trusted-подсеть без лимитов

iptables -A INPUT -p tcp --dport 22 -s 192.168.1.0/24 -j ACCEPT

2️⃣Ограничение по частоте с hashlimit

Допускаем не более 3 подключений в минуту с одного IP:

iptables -A INPUT -p tcp --dport 22 \
  -m state --state NEW \
  -m hashlimit --hashlimit 3/min \
  --hashlimit-burst 5 \
  --hashlimit-mode srcip \
  --hashlimit-name sshlimit \
  -j ACCEPT

Это не требует ни журналов, ни доп. сервисов — чисто на уровне netfilter.

3️⃣Ловим и блокируем агрессивных через recent

Если IP попытался открыть соединение >5 раз за 60 секунд — баним на 5 минут:

iptables -A INPUT -p tcp --dport 22 \
  -m state --state NEW \
  -m recent --name SSH --set

iptables -A INPUT -p tcp --dport 22 \
  -m state --state NEW \
  -m recent --name SSH --update \
  --seconds 60 --hitcount 5 -j DROP

4️⃣Остальные соединения — по умолчанию DROP или REJECT

iptables -A INPUT -p tcp --dport 22 -j DROP

Тестирование

Подключитесь к серверу с другого IP и сделайте 10 попыток:

for i in {1..10}; do nc -zv your.server.ip 22; sleep 2; done

После 5–6 попыток пакет начнёт дропаться.

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

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

❓Вопрос: В чем разница между процессами и потоками (threads) в Linux?

✅Ответ:

Процессы — это независимые единицы выполнения, каждая из которых имеет собственное адресное пространство. Это означает, что процессы изолированы друг от друга, и данные одного процесса недоступны другому без использования механизмов межпроцессного взаимодействия (IPC).

Потоки, в отличие от процессов, выполняются внутри одного адресного пространства. Это позволяет потокам одного процесса совместно использовать память и ресурсы, что делает их легче и быстрее в создании по сравнению с процессами. Для создания потоков используются библиотеки, такие как POSIX Threads (pthread).

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

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

❓Вопрос: Что такое Linux PSI (Pressure Stall Information) и как его использовать для мониторинга?

✅Ответ: PSI — это механизм ядра Linux, позволяющий отслеживать давление на ресурсы: CPU, память и I/O. Он показывает, сколько времени процессы провели в ожидании этих ресурсов, что помогает выявить узкие места до того, как ситуация станет критичной (например, до вмешательства oom-killer).

PSI не измеряет загрузку напрямую — он измеряет «stall time» — сколько процессов одновременно не могли продолжить работу из-за нехватки ресурса. Это дает более реалистичную картину деградации системы.

Проверка PSI осуществляется через:

cat /proc/pressure/cpu
cat /proc/pressure/memory
cat /proc/pressure/io

Перехват stdout/stderr у systemd-сервиса в рантайме: без перезапуска и strace

Иногда вам нужно отладить запущенный systemd-сервис, чтобы понять, что он пишет в stdout или stderr, но:

– сервис уже работает,
– логи в journald запаздывают или отфильтрованы,
– вы не хотите/не можете использовать strace.

Что делать?

1️⃣Ищем дескрипторы вывода

Узнаём PID процесса:

systemctl show -p MainPID your-service

Идём в /proc/<PID>/fd/ — смотрим, куда пишется stdout (обычно fd 1) и stderr (обычно fd 2):

ls -l /proc/<PID>/fd/1

Может быть что-то вроде:

/proc/<PID>/fd/1 -> /dev/null
или -> socket:[12345]
или -> /run/log/journal/...

2️⃣Если это сокет — дублируем вывод

Можно аккуратно “подключиться” к этому дескриптору с помощью socat, если он всё ещё живой:

socat -u ABSTRACT-CONNECT:your-socket - | cat

Или, если это пайп или лог-файл — можно открыть его напрямую и читать в реальном времени:

tail -f /run/log/your-app.log

3️⃣Переоткрытие stdout/stderr без перезапуска

Иногда вы хотите временно направить stdout/err в другой файл (например, в отладочный лог). Если приложение не закрывает дескрипторы, можно сделать:

exec 3>/tmp/debug.log
sudo tee /proc/<PID>/fd/1 >/dev/null <&3

Это дублирует вывод в debug.log. Подходит не для всех случаев, но может сработать.