Администрирование

В последние годы для команд, которые работают с зарубежной инфраструктурой из России, обычный корпоративный VPN перестал быть чем-то, что можно один раз настроить и забыть. OpenVPN, WireGuard, IPsec, различные TLS- и QUIC-обёртки могут работать стабильно месяцами, а потом внезапно начать деградировать: где-то соединение не устанавливается, где-то режется UDP, где-то DPI начинает узнавать сигнатуры, где-то провайдер меняет правила фильтрации.

Для компании это превращается не в техническую мелочь, а в операционный риск. Инженеры не могут попасть на серверы. DevOps не может проверить прод. Администратор не может забрать бэкап. Пентестер не может подключиться к стенду заказчика. При этом инфраструктура может находиться в Европе, США, Азии или у любого другого зарубежного провайдера, а сотрудники — физически находиться в РФ.

В какой-то момент мы пришли к простой мысли: если из корпоративной сети ещё можно установить исходящее SSH-соединение, то можно попробовать использовать сам OpenSSH не только как инструмент администрирования, но и как транспорт для L3-туннеля. В OpenSSH для этого давно существует режим ssh -w, который поднимает туннель через tun-устройство.

Идея статьи не в том, чтобы объявить ssh -w «лучшим VPN на все времена». Это не замена WireGuard для нормальной постоянной инфраструктуры и не серебряная пуля против любых сетевых ограничений. Но это очень полезный аварийный и корпоративный вариант: работает поверх обычного SSH, не требует отдельного VPN-демона на сервере, может быть поднят на дешёвом VPS, использует привычную модель ключей OpenSSH и позволяет строить полноценную маршрутизацию на L3.

Локально docker-compose.yml обычно выглядит «рабочим» ровно до момента, пока сервис не уезжает на сервер. Потом внезапно заканчивается память, контейнеры не поднимаются после падения, логи разрастаются на десятки гигабайт, а Docker продолжает считать зависшее приложение живым.

В статье — пять настроек Compose, про которые почти всегда вспоминают уже после первого инцидента в проде: лимиты ресурсов, restart policy, healthcheck, ротация логов и работа с volumes.

Продолжаю серию подборок неочевидных ресурсов. Недавно рассказывал про 15 онлайн-сервисов, которые должен знать каждый сисадмин. Сегодня собрал инструменты для случаев, когда dig, mtr и traceroute недостаточно, но ставить софт не очень хочется. Под катом — подборка для сетевиков.

XTLS-Reality, XHTTP, Naiveproxy и всякие там AnyTLS - это не интересно. Давайте копнем чуть глубже и посмотрим, где прячется настоящее безумие. Особенно учитывая, что мы живем во времена, когда даже самые, казалось бы, безумные вещи, могут оказаться весьма полезными чтобы не сойти с ума.

В статье пойдет речь о SELinux. Главная моя задача — провести быстрый онбординг о том, как работать с политиками доступов. Я хочу показать, что это вовсе не так сложно, как может показаться на первый взгляд. Буквально 15 минут ознакомления с базовыми понятиями дает 80% понимания как работать с SELinux более уверенно.

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

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

Связка Btrfs + btrbk — это революция в мире бакапа. Ещё никогда не было так просто и быстро создавать дифференциальные резервные копии. Никаких лицензий и подписок — всё полностью бесплатно и встроено в ядро Linux.

Довольно много компаний при работе в облаке выстраивают катастрофоустойчивость, ориентируясь на условные «лучшие практики»: составляют планы, предусматривают резервные площадки, настраивают репликацию. Вместе с тем во время реальных инцидентов многие сталкиваются с тем, что все предусмотренное не работает или работает не так, как ожидалось: восстановление занимает часы вместо минут, данные теряются в критическом для бизнеса объеме, а команды оказываются не готовы к действиям в условиях стресса.

Причина часто кроется в том, что меры обеспечения катастрофоустойчивости либо обеспечиваются формально («чтобы было»), либо проектируются без учета полного цикла рисков — от технических ограничений до организационной готовности.

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

Сейчас память можно увеличить ползунком, Redis поднять одной командой, а состояние сервера оценить по строке в панели управления. Но за этим удобством стоит история компромиссов — сначала инженерам пришлось научить компьютеры работать так, будто памяти больше, чем есть на самом деле, потом диски собрали в массивы, горячие данные перенесли в Redis, а всю эту сложность спрятали за хостингом и managed-сервисами. 

Индустрия десятилетиями строила убедительные иллюзии поверх ограниченной физической реальности, но почему-то памяти до сих пор недостаточно. Как? Разобрал в статье. 

Каждый месяц с карты списываются деньги за подписки. Spotify, Яндекс Плюс, Notion, Obsidian Sync, Google One — суммы небольшие по отдельности, в сумме набегает заметно. Параллельно с этим у меня работает VPS с несколькими проектами, на роутере крутится OpenWrt с AdGuard Home, в ноутбуке стоит Docker. Инфраструктурный опыт есть. Дома при этом — никакого сервера, всё в облаке.

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

Решил спланировать переезд на свой мини-ПК. Пока разбирался с железом и стеком, обнаружил, что нормальной системной дорожной карты «бери и иди» в 2026 году нет. Есть каталоги «50 self-hosted сервисов», восторженные посты про конкретные приложения, треды на Reddit. Структурированного маршрута для нового человека — нет.

Этот текст — попытка такой маршрут собрать. Не «топ приложений», а архитектура от железа до приложений по слоям, с обоснованием каждого выбора, с тем, что я планирую поставить, и с тем, что осознанно не ставлю.

Я думаю все мы понимаем текущую ситуацию с интернетом на территории Российской Федерации. Сейчас это выходит на уровень абсурда, а VPN сервисы выходят на уровень первой необходимости, и в связи с этим я хотел бы поговорить насколько некоторые из них ну абсолютно ужасны, каким сервисам верить не стоит.

И само собой, реальный пример плохого выбора.

Начиная с OpenSSH 9.7, sshd умеет автоматически ограничивать на время подозрительные IP без Fail2Ban и iptables. В Ubuntu 26.04 эта функция уже включена по умолчанию — даже если в sshd_config про неё ничего не написано. Предлагаю попробовать разобраться с тем, как это работает.

Disclaimer: статья написана без использования ИИ. Нейросеть использовалась только для стилистической редактуры. Ничего не рекламирую и в ТГ-чаты не зазываю. Гараж не продаю.

У вас не открывается сайт. Браузер пишет «Не удалось установить соединение». Это всё, что он знает — и это бесполезно.

Потому что «не открывается» - это как минимум четыре разных истории. DNS-резолвер провайдера соврал. ISP режет пакеты по IP. ТСПУ прочитал имя хоста в открытом поле TLS ClientHello и оборвал соединение. Или вы получили честный 200 OK - и страницу-заглушку «доступ ограничен по решению Роскомнадзора». В каждом случае нужно делать разное, и без понимания, на каком слое стоит фильтр, можно тыкаться в любую сторону и не угадать.

В статье разбираю все четыре механизма по слоям - снизу вверх, от DNS до HTTP - и показываю Python CLI, который запускает probes на каждом уровне и выдаёт диагноз: TCP_RESET, TLS_BLOCK, DNS_BLOCK, HTTP_STUB. Отдельно - про то, как «TCP открылся, а TLS handshake умер» становится надёжным отпечатком DPI на SNI, и почему параллельный стриминг результатов через as_completed радикально меняет UX по сравнению с pool.map().

Это диагностический инструмент, не средство обхода. Открытый код, MIT, pip install rkn-block-checker.

Всем привет! Меня зовут Ярослав Покрепов, я DevOps-инженер в Авито. 

Виртуализация — это технология создания изолированных и независимых виртуальных сред на базе физических ресурсов. Виртуализация в Авито — это неотъемлемая часть технического стека, как и во многих других IT-компаниях. На этапе основания Авито виртуализация уже была широко распространённой технологией. Проект нуждался в эффективных и гибких решениях для управления ресурсами, в возможности масштабироваться в будущем и в обеспечении стабильной работы при растущей нагрузке.

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

Дисклеймер: ранняя история инфраструктуры компании восстановлена не по документации, а по воспоминаниям инженеров, которые работали в тот период. Это устная история — с допущениями, реконструкцией контекста и попыткой передать факты и логику решений.

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

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

LLM-агенты вроде Claude Code постепенно становятся рабочим инструментом разработчика. Но почти все они завязаны на облачные API с их ценами, лимитами и зависимостью от внешней инфраструктуры.

Поэтому всё чаще возникает идея: а что если запускать агентов на своём сервере — локально или на VPS?

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

Разбор упавших файловых систем, потерянных баз данных и умирающих дисков съедает время, особенно когда всё это приходится восстанавливать консольными утилитами или самописными скриптами. Однако настройку бэкапов можно упростить с помощью утилит — под катом я собрал топ-10 опенсорс-инструментов и рассказал, на основе чего выбирать. 

Это неизбежно должно было случиться: искусственный интеллект докатился и до Linux. Один из самых популярных дистрибутивов, Ubuntu, готовится к внедрению нейросетей. К слову, обсуждение этой новости на официальном форуме вышло настолько жарким, что модераторам пришлось включать медленный режим, чтобы хоть как-то усмирить поток комментариев. Давайте и мы попробуем разобраться что там и как. Поехали!

Привет, Хабр! Если вы читаете мои дайджесты, то знаете, что обычно я пишу о развитии проекта far2l — порта Far Manager под Linux, macOS и BSD. Но сегодня случай особый. На прошлых выходных я обещал вам рассказать про f4 — написанный с нуля клон far2l на языке Go.

Сегодня состоялся релиз первой публичной альфа-версии 0.1.1-alpha. В этой статье я расскажу, как я пришел к идее переписать легендарный файловый менеджер, почему выбрал Go, как в этом помогли нейросети и почему современному консольному приложению не обязательно страдать от «наследия предков».

Не так давно мне попался ноутбук Acer TravelMate B1 TMB118 с 4 ГБ DDR4. Благодаря размеру и маленькому потреблению он идеально подошел под эксплуатацию в виде печатной машинки и простенького редактора кода. 

Но именно этот малыш заставил меня задуматься: на какие уступки можно пойти по памяти, чтобы комфортно выполнять свою работу. В эпоху, когда комплект из 32 ГБ RAM DDR5 стоит в среднем 40 000 рублей, что сопоставимо с ценой бюджетного ноутбука, интересно, насколько можно опустить планку и существовать на современной системе.

Привет, Хабр! Меня зовут Данил, я системный инженер в Selectel и у меня дома скопилось немало «железа» разных поколений, в том числе любезно одолженного моими друзьями. Я решил не ограничиваться одним ноутбуком и превратил эту больную идею в полноценный стресс-тест для разных платформ.

Ох уж этот мир свободного ПО! Хотите создавать проекты, которые покорят мир? Пожалуйста. Хотите просто развеяться и проверить, где же предел гибкости Linux? Этим можно заниматься сколько угодно.

Хотите конкретный пример? Их есть у меня, причем один из них совсем свежий. Шринукс, или Shrek Linux, появился буквально пару дней назад. Это полноценная операционная система с нескучными обоями, где буквально каждая деталь отсылает к мультфильму про болотного огра. К слову, создатель не стал ограничиваться парой обоев — он погрузил в атмосферу Шрека все, что только можно было кастомизировать.