Новые релизы терминального/devops-стека за последние пару недель. lazygit — TUI поверх git, вся обычная работа (stage, commit, rebase, стэши) без запоминания флагов git в голове. В v0.65.1 — серия доработок вокруг недавно добавленной поддержки GitHub pull requests прямо из интерфейса, исправляющих шероховатости первой реализации k9s — терминальный клиент для Kubernetes, навигация по подам/неймспейсам/логам без постоянных kubectl get -o wide. В v0.51.0 — плагин для flux reconcile прямо из интерфейса, плагины под Argo Workflows, инверсия тёмной/светлой темы через цветовую модель Oklch (перцептивно равномернее старого HSL-переключения) и возможность стартовать k9s вообще без валидного kube-контекста, что раньше было жёстким условием запуска ...

Barman и pgBackRest оба бэкапят PostgreSQL, но по-разному устроены внутри. Исторически Barman строился вокруг rsync поверх SSH: backup_method = rsync копирует файлы кластера по ssh-соединению, а archiver = on принимает WAL-сегменты через archive_command, которая переносит их на сервер бэкапов. Со стороны PostgreSQL это полностью агентless-модель — отдельный процесс не нужен, достаточно ssh-доступа. ...

Patroni сам не хранит состояние кластера — кто сейчас лидер, список реплик, таймстемп последнего обновления лежат в etcd, отдельном распределённом key-value хранилище. На каждом цикле HA-проверки Patroni ходит в etcd, читает и продлевает lease лидера; без доступного DCS Patroni не может быть уверен, кто сейчас главный, и не имеет права безопасно переизбирать лидера. ...

Выделить слово под курсором вручную — это v, встать на первую букву, протянуть выделение до последней. Текстовый объект делает то же самое одной командой: ciw меняет слово целиком независимо от того, на какой букве внутри слова стоит курсор. Разница именно в этом — не нужно точно позиционироваться на границе объекта, Vim сам находит её. ...

До десятой версии PostgreSQL партиционирование собирали вручную через наследование таблиц и триггеры на INSERT — рабочая, но хрупкая конструкция, которую легко сломать неосторожным DDL. Декларативное партиционирование сделало то же самое штатным синтаксисом: секции объявляются прямо при создании таблицы, а планировщик сам знает о структуре и использует её при построении плана запроса. Синтаксис для диапазонов по дате — обычное дело для таблиц с логами или метриками: CREATE TABLE measurement ( city_id int NOT NULL, logdate date NOT NULL, peaktemp int, unitsales int ) PARTITION BY RANGE (logdate); CREATE TABLE measurement_y2026m10 PARTITION OF measurement FOR VALUES FROM ('2026-10-01') TO ('2026-11-01'); Для PARTITION BY LIST значения перечисляются явно, что удобно для партиционирования по региону или арендатору (tenant) в мультитенантной схеме: ...

Держать пять вкладок терминала с tail -f под разные логи — рабочий, но неудобный способ следить за инцидентом сразу по нескольким сервисам. multitail решает это одной командой: делит терминал на панели и в каждой крутит свой файл, живьём. multitail /var/log/nginx/error.log /var/log/nginx/access.log По умолчанию панели идут одна под другой. Флаг -s раскладывает их колонками, что удобнее для широких мониторов и логов с короткими строками: multitail -s 2 /var/log/daemon.log /var/log/syslog Для связанных логов (например, access и error одного и того же сервиса) полезнее не раскладывать по колонкам, а слить в одно окно с сохранением порядка по времени — за это отвечает --mergeall, применённый к нужной группе файлов на командной строке. ...

Классический nc (netcat) умеет слушать порт и коннектиться, но для шифрования приходится городить отдельный TLS-туннель поверх. Ncat — реализация той же идеи от команды Nmap, где SSL встроен прямо во флаги, без openssl s_client или stunnel сбоку. Слушатель и подключение — тот же минимализм, что у nc: ncat -l 4444 # слушать на порту 4444 ncat host.example 4444 # подключиться Разница начинается там, где классическому netcat нужна дополнительная обвязка. Шифрованное соединение — один флаг на обеих сторонах: ...

Один и тот же frontend в HAProxy часто обслуживает сразу несколько доменов, и разводить их по backend удобнее не по пути запроса, а по заголовку Host: frontend https_in bind *:443 acl host_api hdr(host) -i api.example.com acl host_admin hdr(host) -i admin.example.com use_backend api_servers if host_api use_backend admin_servers if host_admin default_backend web_servers Флаг -i делает сравнение регистронезависимым — без него API.example.com и api.example.com считаются разными хостами, что почти никогда не то, что нужно. ...

supervisord берёт на себя то же, что обычно делает systemd — следит, что процесс жив, перезапускает его при падении, собирает stdout/stderr в лог — но делает это в userspace, без прав на системные unit-файлы и без зависимости от PID 1. Удобно для контейнеров без systemd, для приложений, которые разворачивает не root, или когда процессов много и плодить под каждый unit-файл избыточно. Конфиг собирается из блоков [program:x], каждый описывает один управляемый процесс: ...

В конфиге WireGuard с одним пиром AllowedIPs легко принять за обычный allow-list — какие адреса пустить через туннель. Как только пиров становится несколько, выясняется, что это ещё и таблица маршрутизации: ядро смотрит на AllowedIPs каждого пира и решает, какому из них отправить исходящий пакет, по той же логике longest-prefix-match, что и обычный роутинг. [Interface] PrivateKey = <приватный ключ сервера> ListenPort = 51820 [Peer] PublicKey = <публичный ключ клиента1> AllowedIPs = 10.192.122.3/32, 10.192.124.0/24 [Peer] PublicKey = <публичный ключ клиента2> AllowedIPs = 10.192.122.4/32, 192.168.0.0/16 Если диапазоны двух пиров пересекаются, сервер отдаст пакет тому, у кого совпадение точнее (более узкая маска), а не тому, кто добавлен раньше в конфиг. На практике это всплывает, когда забыли сузить AllowedIPs второго клиента, и его широкий 192.168.0.0/16 неожиданно перетягивает трафик, который должен был уйти по более специфичному маршруту первого. ...