Системное администрирование *

Строка из документации n8n про возобновление с места остановки читается как гарантия перезапуска с точки сбоя. Проверка привела в ветку форума 2021 года, где смысл настройки объясняют иначе, - и дальше ещё в пять вопросов к движку автоматизации перед необратимым шагом. Все ссылки и даты сверки (27 августа 2026 года) - в тексте.

Заявка была скучная: клиент не проходит проверку по списку разрешённых адресов. Адрес его я вижу, адрес в списке есть, файрвол пакет пропускает. Приложение отвечает «доступ запрещён».

В логе стояло ::ffff:192.0.2.5, в конфиге — 192.0.2.5. Что строки разные, видно сразу. Но выглядит это как разное написание одного адреса: справа те же четыре октета, слева приписка, которую принимаешь за особенность формата. Поэтому проверять я пошёл конфиг, а не сравнение.

Компьютер начал тупить в середине дня. VS Code переставал отвечать, новые вкладки редактора не открывались по минуте, а лимит подписки на ИИ-ассистента сгорал к обеду вместо конца недели. Виноватым оказался не ассистент, а плагин, который ведёт для него память между сессиями.

Строчка, которая встречается в скриптах повсеместно:

mysql -u admin -pSecretPass123 -e "select 1"

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

В первой части мы разобрали, почему Aeza ушла со сторонней платформы и как AVM устроен в общих чертах. Здесь уровень ниже: путь запроса от вызова до задачи на конкретной ноде, устройство конвейеров, поведение при сбоях и то, где система хранит состояние виртуальных машин.

Любой запрос клиента заканчивается цепочкой задач на ноде: скачать образ, создать диск, поднять машину. Этими цепочками управляет AVM — собственная система управления виртуализацией.

От HAProxy до VLESS+Reality: все грабли одного MTProto-прокси

Если вы когда-нибудь поднимали свой MTProto-прокси для Telegram и он у вас "работает, но как-то не очень" — эта статья для вас. Я прошёл путь от "просто добавить relay" до "переписать всю цепочку на VLESS+Reality с нуля", и по дороге собрал приличную коллекцию граблей. Расскажу всё по порядку, чтобы вам не пришлось наступать на те же.

Исходная ситуация

Была задача простая на первый взгляд: поднять MTProto проксю для Telegram на сервере в РФ. Причина стандартная — хочется, чтобы телега работала

Взял mtg (ghcr.io/9seconds/mtg:2 — отличная реализация MTProto-прокси с поддержкой fake-TLS), поднял на сервере — и оно не работает. Точнее, работает, но еле-еле: то подключается, то нет, на мобильном интернете почти всегда фейл.

Первая мысль, которая приходит в голову почти всем в такой ситуации: "провайдер блокирует адреса Telegram". И это отчасти правда — но, как выяснилось, правда не вся.

Первая попытка: спрятать Telegram за релеем

Логика была такая: раз провайдер режет соединения именно к IP Telegram, то уберу эти IP из виду. Арендую второй сервер за границей, туда ставлю настоящий mtg, а на RU-сервере — просто TCP-релей (HAProxy или голый iptables DNAT), который прозрачно перекидывает байты дальше.

Клиент → RU-сервер (HAProxy, чистый TCP passthrough) → Зарубежный сервер (mtg) → Telegram

Казалось бы, логично: сервер в РФ теперь физически ничего не знает про Telegram, он просто гоняет байты во внешний IP. Провайдер не должен видеть ничего подозрительного.

И вновь я всех приветствую! Сегодня я бы хотел рассказать о такой теме как воспроизводимые приложения/сборки. 

Сложная ИТ-инфраструктура неизбежно вызывает множество проблем: нужно обеспечивать её масштабируемость и работоспособность, сдерживать рост затрат на сопровождение и поддержку, повышать прозрачность использования инфраструктуры и работающего на ней ПО.

Привет, Хабр! Меня зовут Юрий Самойлов, я директор по продукту MWS B2B Store. Сегодня поговорим о том, как управлять сложными инфраструктурными и ИТ-ландшафтами в целом, обсудим проблемы стандартизации, упаковки и развёртывания ПО, а также вопросы контроля лицензий, в том числе уже приобретённых у разных вендоров. Кроме того, мы посмотрим, как эти задачи решаются в MWS.

За помощь в подготовке материала спасибо Евгению Тетенчуку, техлиду команды MWS B2B Store. Эта статья — текстовая версия вебинара.

В июне я писал про билайновскую опцию «доступ к сервисам» — статичный IP за 180 рублей, с которым из коробки открываются ChatGPT, Spotify и ещё сотня ушедших из РФ сервисов. Спустя два месяца эта же опция не пустила меня в Тарков: лаунчер решил, что я захожу из США. Без VPN, из РФ, по проводу. Рассказываю, как я это «дебажил» и что, судя по всему, у «белого IP» под капотом.

Многие сервисы сегодня выдают клиенту не один конкретный конфиг для подключения, а VLESS/Trojan-подписку — ссылку, за которой стоит целый пул из десятков серверных конфигураций сразу. Провайдеру это удобно (не нужно вручную вести отдельный конфиг под каждого клиента), но у пользователя тут же встаёт главная практическая проблема: подключить роутер именно через такую подписку так, чтобы соединение работало стабильно. Один конкретный сервер из пула сегодня быстрый, завтра перегружен, послезавтра вообще не отвечает — а подписка в целом при этом продолжает исправно работать, просто нужно каждый раз заново находить, какой именно из десятков серверов сейчас реально живой.

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

Об этом и статья: что такое точечная (доменная) маршрутизация на роутере, зачем нужна автоматическая балансировка между серверами одной VLESS/Trojan-подписки, и как это устроено в нашем универсальном проекте SmartRoute — для роутеров на OpenWrt и KeenticOS (через xkeen), который умеет и то, и другое из коробки.

restart-hook вернул 202, а сервис всё ещё не отвечает. Повторить запрос — рискнуть вторым перезапуском; закрыть инцидент — записать восстановление, которого не было. На этом конфликте построен recovery в Vigil: система проверяет сервис до и после действия, отсекает устаревшие задачи и останавливает автоматизацию, когда пора звать человека.

Обычная логика такая: не хочу, чтобы меня узнавали — открываю приватное окно, и всё, я новый посетитель. Логика была верной примерно до середины десятых годов.

Сейчас узнавание держится не на cookie, а на наборе свойств самого браузера. Их не надо никуда сохранять — они просто есть, и по их сочетанию посетитель определяется с высокой надёжностью. Очистка хранилища на это не влияет никак: удалять там нечего.

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

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

Изначально с Capabilities я лично столкнулся в своем проекте ServeHub-2, когда настраивал контейнеры в docker-compose. Если быть более конкретным, я настраивал WG-easy с использованием AmneziaWG, которому нужны были привилегии, связанные с загрузкой модулей ядра и настройками интерфейсов. До этого я слышал о Capabilities, но не знал что это такое, поэтому решил подробнее в этом разобраться.

Сначала разберу общее понятие, что вообще такое Capabilities (далее буду кратко писать CAP), потом постепенно перейду к примерам.

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

Про публичный Wi-Fi принято говорить одно из двух. Либо «там воруют пароли, не подключайтесь», либо «сейчас везде HTTPS, всё в порядке». Обе формулировки неточные, и обе мешают понимать, что происходит на самом деле.

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

Вокруг macOS сложилась, пожалуй, уникальная для корпоративного мира экосистема бесплатных админских инструментов. Сообщество MacAdmins (Slack на десятки тысяч участников, конференции JNUC и MacAdmins PSU) годами создаёт и поддерживает утилиты, которые закрывают пробелы между тем, что даёт Apple «из коробки», и тем, что действительно нужно администратору. Причём многие из этих инструментов написаны инженерами Jamf, SAP и других крупных компаний и выложены в opensource.

В этой статье мы собрали 12 утилит, которые чаще всего встречаются в арсенале администраторов macOS. Почти все они бесплатны и с открытым исходным кодом, работают независимо от того, каким MDM вы пользуетесь, и решают конкретные задачи: от выдачи TCC-разрешений до принуждения пользователей к обновлениям.

За первое полугодие 2026 года мы проанализировали 7,79 млн SQL-запросов с нескольких тысяч серверов. В статье описали распределение по семействам СУБД и major-версиям.

Файл /dev/null есть в каждой Linux-системе. Он весит ноль байт, но именно туда ежедневно сливаются терабайты ненужного вывода, а если его удалить, то вовсе падут cron, ssh и половина ваших bash-скриптов. Под катом расскажу, откуда взялась эта «чёрная дыра», почему это не обычный файл, а псевдоустройство, и что на нём завязано. 

Ранее в «Надёжность, устойчивость, доступность» провели введение в терминологию надежности. В этой статье рассмотрим типовые модели отказоустойчивого кластера.

К сожалению, в текущих публикациях ИТ‑изданий с заголовками «надежность, отказоустойчивость, доступность» и тому подобное не встречал ни моделей надежности, ни расчетов этих самых (показателей) «надежность, отказоустойчивость, доступность», а только качественные критерии: «более надежный», «очень отказоустойчивый» и тому подобное. Инженерная надёжность (например, «Надежность в технике») из научной (инженерной) дисциплины в публикациях ИТ‑журналов (хабр и тому подобное) превратилась в некую менеджерскую дисциплину пусть и с техническими подробностями \ описаниями, например, механизмов переключения резерва, но без математического аппарата (теории вероятности \ теории надежности). С целью популяризации расчетов надежности отказоустойчивых резервируемых структур вычислительной и сетевой инфраструктур ниже предлагается несколько базовых подходов \ моделей \ надёжностных схем.

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

Ниже — не попытка рассказать опытным администраторам или DevOps, как им делать свою работу. В зрелых с точки зрения ИБ компаниях такие ситуации обычно уже разобраны в процедурах реагирования, а у команд есть понимание, кто и что делает в первые минуты и часы инцидента.

Но довольно часто с серьёзным инцидентом компания сталкивается впервые. И вот там начинается самое сложное: всё лежит, бизнес нервничает, информации мало, а делать что‑то надо прямо сейчас.

В такой момент очень легко начать действовать слишком активно: перезагрузить сервер, удалить подозрительный файл, почистить логи, начать восстановление из бэкапа — и тем самым случайно усложнить дальнейший разбор ситуации.

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

Это именно база. Для кого‑то очевидная, для кого‑то уже давно формализованная во внутренних процедурах. Но если организация столкнулась с таким впервые, эти несколько действий могут сильно повлиять на то, сколько информации удастся сохранить и насколько быстро потом получится разобраться в произошедшем.