Лишь бы юзер был доволен
Сервер окупился, а деньги жрёт до сих пор — просто по разным бюджетам, поэтому никто не видит полной суммы. Показываем, как посчитать, во что он реально обходится за год. Спойлер: процентов на 40 больше, чем в отчёте.
Я администрирую несколько доменов в зонах.org,.su,.ru,.net. Хостинг в РФ, даунтайм критичен, трафик идет постоянно. Домены продлялись годами через личный кабинет автоматическим списанием с баланса — всё стандартно.
Проблемы начались около месяца назад, но последнюю неделю поддержка крупнейших регистраторов окончательно «умерла».
Интернет — это зависимость без зафиксированной версии. Сегодня он возвращает одно, завтра — другое, а послезавтра — ничего. Поэтому мы решили сохранить для сборки тот интернет, который она однажды увидела. Для этого пришлось перехватывать HTTPS, выпускать собственные сертификаты, переподписывать индексы Debian и выяснять, почему Docker отправляет «случайные» заголовки.
В этой статье я расскажу, как разрабатывал кеширующую MITM-проксю, которая перехватывает весь HTTP/HTTPS-трафик и отдаёт ранее сохранённые ответы. Разберём также неочевидные технические проблемы, с которыми пришлось столкнуться.
Настраивали когда-нибудь Squid? Если да, то вы точно знаете: чтобы всё заработало как надо, приходится лазить по десятку сайтов, форумов и старых гайдов. Кто-то пишет про SSL, кто-то про кэш, кто-то про авторизацию — и всё в разных местах, с разными версиями
Для кого эта статья: - Для тех, кто хочет настроить Squid быстро. - Для тех, кто устал искать кусочки информации по всему интернету. - Для тех, кто ценит своё время и любит, когда «работает с первого раза».
Эта статья — попытка собрать всё важное в одном месте…
Всем привет! Примерно с лета 2025 у меня работает ИБП Энергия Smart.2 1000W с внешней LiFePO4-батареей, и всё это время он был подключен к Home Assistant - я видел напряжение сети, заряд батареи, нагрузку и всё остальное прямо в дашборде. Написать об этом статью мне тогда в голову не пришло, т.к. всё завелось довольно быстро и казалось, что ничего интересного тут нет. Исправляюсь.
А поводом всё-таки сесть и написать стало то, что недавно я купил второй ИБП - Энергия Smart.2 600W под роутеры. Логика была простая: модель та же, конфиг уже готов, скопировал - работает. По факту же скопированный конфиг не заработал вообще, все сенсоры повисли в unavailable, и в процессе разбирательств выяснилось, что под одним и тем же названием «Smart.2» продаются два ИБП на совершенно разных платформах с разными протоколами. Об этом и расскажу: как подключить оба варианта, чем они отличаются и на какие грабли я наступил.
Кстати, в марте на Хабре выходила статья про подключение Энергии Smart к NUT - там 1000-ваттник подключали через dummy-ups и самописный Python-скрипт. Способ рабочий, но у меня к тому моменту уже давно всё работало более простым путём - через нативную интеграцию Modbus в Home Assistant, без NUT и без скриптов. Его и покажу первым.
Пошагово арендуем VDS, разворачиваем AmneziaWG через PowerShell-скрипт, включаем HTTPS для панели, создаём клиентские профили и подключаем Windows через WireSock Secure Connect.
Если кратко, я создаю свою домашнюю лабораторию, которой планирую пользоваться в повседневной жизни. В неё я решил внедрить и трекер задач, так как это был единственный инструмент, который выбивался из моего привычного workflow и существовал полностью отдельно. Из-за этого список ежедневных дел мне приходилось копировать в Obsidian, чтобы в случае удаления старого трекера не бояться, что мои планы пропадут.
После недолгих поисков я пришел к Habitica. Геймификация в ней меня действительно зацепила, и, пользуясь этим подходом последние несколько дней, я не жалею. Поэтому я хочу поделиться тем, как я настраивал все для себя, чтобы добиться лучшего результата.
Репозиторий проекта: https://github.com/karen07/openwrt-mesh-builder
openwrt-mesh-builder почти полностью автоматизирует построение routed-сети из OpenWrt-роутеров и Ubuntu/VPS-серверов: с leaf/spine-топологией, несколькими exit-узлами, динамической маршрутизацией Babel, point-to-point WG/AWG-линками, IPIP data-plane, policy routing, access-подсетями, split DNS и автоматическим переключением при отказах.
Вся сеть описывается в одном config.json. На его основе проект рассчитывает топологию и адресацию, генерирует конфигурации роутеров и серверов, ключи, access-клиентов, firewall-правила, настройки DNS, DHCP и Wi-Fi, собирает готовые образы OpenWrt, устанавливает их на роутеры и развёртывает exit-серверы.
То есть почти весь путь — от описания сети до её развёртывания и последующих обновлений — автоматизирован.
Классический VPN подключает пользователя к сети, а не к конкретному приложению. Получив учётные данные одного сотрудника, атакующий становится участником корпоративной сети: может сканировать хосты, обращаться к сервисам, пробовать аутентификацию на внутренних системах. Устройство при этом никак не проверяется — ноутбук без антивируса и корпоративный компьютер в управляемом состоянии подключаются одинаково.
Ideco NGFW Novum решает эту задачу через встроенный ZTNA и IPSec/SSL VPN для совместимости с любыми устройствами.
Настоящая проблема — не отсутствие одной платформы, а разнородность сред, в которые нужно доставить одно и то же приложение. Каждая среда тянет доставку к своему механизму, а инфраструктурный код — тот самый «второй API» с сотнями параметров установки — форкается под каждую цель.
Цель принести Kube-way туда, где Kubernetes под запретом!
Последние несколько лет я занимаюсь разработкой enterprise-продуктов. И относительно недавно понял одну вещь.
Самая сложная часть проекта — вовсе не разработка. Самая сложная часть — доставка и поддержка.
Пока приложение работает на ноутбуке разработчика, всё выглядит прекрасно. Собрали, запустили, прогнали тесты, отправили изменения в Git.
Проблемы начинаются в тот момент, когда продукт нужно поставить заказчику. И тут оказывается, что единого способа поставки не существует.
PostgreSQL 19 добавляет SQL/PGQ (Property Graph Queries, запросы к графам свойств) на основе стандарта SQL:2023. Графовые структуры можно определить поверх уже существующих реляционных таблиц и запрашивать их синтаксисом сопоставления с образцом. Не нужны новый движок хранения, расширения или миграция данных.
Я работаю специалистом по кибербезопасности. По работе мне регулярно приходится анализировать сетевые взаимодействия, разбираться в устройстве различных сервисов, искать нестандартные решения и понимать, как устроены системы, о существовании которых обычный пользователь даже не задумывается.
Забавно, но именно эти профессиональные навыки неожиданно пригодились мне... при строительстве собственного умного дома.
Безопасность и приватность – главные столпы self-hosted систем. Но что делать, если критически важные камеры застройщика доступны только через облачный костыль RTSP.RU, а ссылки на потоки меняются быстрее, чем вы успеваете налить кофе? Подключать их «в лоб» во Frigate – верный способ забить CPU декодированием и ловить постоянные обрывы.
Под катом – подробный разбор того, как разобрать логику работы облачного плеера, вытащить скрытые HD/SD потоки, построить стабильный RTSP-мост и заставить Home Assistant открывать шлагбаум и выводить видеодомофон на настенную панель, используя только локальные ресурсы.
Почти все причастные к разработке сталкивались с CI, и я уверен, что большинство знает про существование раннеров, на которых крутится наш CI. Но, как показывает практика, далеко не все знают о том, что раннеры бывают разных видов и что под разные сценарии DevOps в вашей команде подготовил разные окружения. Да и сами DevOps иногда оказываются в ступоре, когда на техническом интервью их спрашивают, чем docker от docker autoscaler отличается. Поэтому я решил собрать весь основной материал в виде большой шпаргалки. Сегодня разберём: какие раннеры бывают, какие плюсы и минусы у каждого, где какой лучше использовать, ну и на какие грабли вы можете наткнуться при работе.
Данная статья написана для версии GitLab / GitLab Runner 18.x. GitLab постоянно подчищает хвосты в работе раннеров, поэтому будьте внимательны, на других версиях что-то может быть деприкейтед, а что-то просто не существует.
В корпоративном реестре может числиться полторы сотни приложений, хотя реальная инфраструктура давно вышла за его пределы: сотрудники заводят личные аккаунты в SaaS, оплачивают подписки со своих карт и поднимают временные облачные ресурсы, которые продолжают работать годами. Каждый такой инструмент появляется по понятной причине — его можно запустить за несколько минут, пока согласование занимает недели, но затем он обрастает данными, доступами и интеграциями, оставаясь вне общего контура управления.
Так формируется Shadow IT, которое обычный discovery видит лишь фрагментами. Разберём, откуда берётся этот скрытый слой инфраструктуры, во сколько он обходится компании и как вернуть его под контроль без тотальных запретов.
ИТ знает, сколько железа на складе, но не знает, во сколько оно обходится. Деньги уходят по мелочи — ремонт тут, простой там, забытая лицензия — а в конце года бюджет в минусе. Разбираем, куда утекает и как это поймать вовремя.
У крупных компаний редко возникает задача создать систему мониторинга с нуля. Чаще приходится дорабатывать уже существующую инфраструктуру: добавлять сигналы, подключать новые объекты и решать проблемы, которые раньше никто не предполагал.
В этой статье расскажем о двух подобных кейсах на совсем разных площадках: телеком-оператора и пассажирского перевозчика.
В мире корпоративной ИТ-инфраструктуры уже много лет существует дискуссия. На одном полюсе — проверенная временем классическая трёхуровневая архитектура (серверы, сеть, внешняя СХД). На другом — гиперконвергентная инфраструктура (HCI), которая объединяет все компоненты в единую программно-определяемую систему. Выбор между ними — это не просто вопрос "что новее", а стратегическое решение, влияющее на управляемость, масштабируемость, отказоустойчивость и совокупную стоимость владения .
Документация умирает не от лени сотрудников, а из-за неудобства и потери доверия к данным. Разбираем «два кита» качественной базы знаний: удобство использования и контроль актуальности. Показываем на примере ONLYOFFICE Workspace, как превратить хаос в работающий процесс с помощью шаблонов, ролевой модели доступа и дисциплины пересмотра.
Обнаружил что в скриптах сборки время от времени подвисает node-pre-gyp, который скачивает прекомпилированные бинарные библиотеки.
Начал выяснять откуда он их пытается скачать - оказывается, github.
Проверил github без VPN - оказывается, релизы с release-assets.githubusercontent.com не скачиваются. Причем из консоли еще скачиваются, из браузера не открываются. Вероятно, иногда и из консоли блокируется.
То есть частичная блокировка гитхаба все еще продолжается. Замечу, что он используется в огромном числе скриптов сборки огромного числа продуктов, и заменить его на зеркала централизовано нельзя, да и далеко не всегда известно, какой именно файл какая именно программа будет скачиваться.