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

Привет, друзья!

Сегодня поговорим о кластерном режиме в Pilot – линейке продуктов, на базе которых организуют совместную работу над строительными проектами, сборку и проверку BIM-моделей.

Кластерный режим Pilot обеспечивает отказоустойчивость и горизонтальное масштабирование её центрального компонента — Pilot-Server. Для хранения данных в кластере используется PostgreSQL, а для взаимодействия между узлами — Redis.

Примечание: На данный момент кластеризация доступна только для Pilot-Server. Pilot-BIM-Server и Pilot-Web-Server работают как отдельные сервисы без возможности горизонтального масштабирования.

Какие преимущества мы получаем по сравнению с подходом, где используется один компонент Pilot-Server?

1. Аппаратный сбой на сервере Pilot-Server. При падении машины, на которой расположен единственный экземпляр Pilot-Server, работа пользователей парализуется, никакие действия с системой в режиме онлайн невозможно совершить. При нескольких компонентах на разных серверах, в случае падения одного из них, мгновенно назначается новый активный узел из оставшихся рабочих. Для пользователей это будет кратковременный разрыв соединения, после которого они переподключатся к новому узлу.

2. Обновление ПО. При обновлении Pilot-Server с единственным экземпляром, пользователи не могут подключаться в этот момент. В кластерном режиме обновление можно произвести в режиме “Последовательного обновления”.

3. Рост нагрузки на Pilot-Server. Большое количество запросов к одному компоненту Pilot-Server может превысить пропускную способность одного сервера. В кластерном режиме за счёт нескольких узлов с Pilot-Server  нагрузка будет распределяться между ними через балансировщик.

Привет Хабр! Меня зовут Алексей и я Системный Администратор.

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

Как протокол заимствует чужое рукопожатие, почему v1 и v2 были дырявыми, что именно в v3 нашёл Aparecium и где у этого подхода архитектурный потолок

Большинство прокси-протоколов пытаются выглядеть как HTTPS: генерируют свой сертификат, настраивают TLS, надеются что DPI не присмотрится слишком внимательно. ShadowTLS идёт другим путём — берёт чужое рукопожатие целиком, не подделывая ничего

Пока TLS-рукопожатие идёт, всё что видит анализатор трафика — честный ClientHello, честный ServerHello, честный сертификат настоящего сервера-донора. Всё что происходит после завершения рукопожатия — туннельный трафик. К тому моменту DPI должен был уже принять решение пропустить соединение.

Прежде чем читать дальше. ShadowTLS v3 на март 2026 года работает не везде и не всегда. В июне 2025-го инструмент Aparecium показал два воспроизводимых вектора детекции: фиксированная разница в длине ServerFinished и некорректная обработка NewSessionTicket от OpenSSL-серверов. Против провайдеров с базовой SNI-блокировкой без активного зондирования протокол вполне работает. Против ТСПУ с активным зондированием риск реальный. Статья описывает архитектуру и механизм работы, а в конце разбирает где и почему детекция срабатывает.

Привет! Если вы читаете эту статью, то скорее всего столкнулись с блокировками Telegram или просто хотите обеспечить себе стабильный и безопасный доступ к мессенджеру. Я покажу, как поднять свой собственный MTProto прокси с Fake TLS на любом VPS сервере за 5 минут с помощью готового скрипта.

В этой статье посмотрим на модуль ACME веб‑сервера Angie. Модуль позволяет с минимальными усилиями получить TLS‑сертификаты и автоматически их обновлять. Наверняка вы уже работали с бесплатными сертификатами от Let«s Encrypt и можете задать закономерный вопрос: зачем это делать веб‑сервером, когда есть утилиты вроде certbot, acme.sh и acmebot? Для ответа нужно хотя бы один раз попробовать модуль ACME и удобство конфигурации станет очевидным.»

Начнём с краткого введения в тему ACME.

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

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

Меня зовут Михаил Фучко, я архитектор SDN и технический менеджер Terraform-провайдера виртуализации zVirt. В этой серии статей я расскажу о пути, который проделала наша команда в процессе разработки собственного провайдера инфраструктуры для Terraform. Поговорим об успехах и трудностях, о том, всегда ли можно положиться на решение с открытым исходным кодом, и о том, как запущенные десять лет назад «бумеранги» возвращаются, но не тем, кто их запустил. 

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

Знаете это чувство, когда сидишь на очередном спринт-планировании, команда пытается оценить таски, а планинг покер тормозит так, что успеваешь кофе сварить, пока карточка загрузится?

Вот у меня в AGG TEAM такая же история была. Мы пробовали:

Привет, Хабр!

В этой статье мы расскажем о заочной борьбе с разработчиками объектного хранилища Hitachi Content Platform. Сначала мы столкнулись с критическим заполнением файловых систем индексов, а в процессе лечения обнаружили вторую, гораздо более глубокую проблему — одна из нод кластера фактически выпала из схемы хранения данных, оставаясь при этом «зелёной» в консоли. Материал будет полезен инженерам, работающим с HCP и другими объектными СХД, а также всем, кто любит истории о нетривиальных расследованиях в недрах корпоративного ПО.

Несмотря на то, что на дворе уже 2025 год, и, казалось бы уже все давным давно держат свои вычислительные ресурсы (сервера) в облаке или, как минимум, в виде виртуальных машин, я оказался в ситуации, что мне нужно конвертировать 2 физических лаб сервера в виртуальные машины:

OpenClaw предлагает общаться с агентом через мессенджеры, но для управления сервером нужен полноценный интерфейс.

KeeneticOS из коробки закрывает большинство бытовых задач, но как только появляется требование рулить трафиком по-своему, быстро упираешься в нюансы. Я собрал рабочую схему на Keenetic Hopper: Entware + Xray-core (TUN) + policy-based routing через fwmark и отдельную таблицу маршрутизации. Главный фокус на эксплуатации, я покажу минимальный чек-лист диагностики, и как сделать конфигурацию самовосстанавливающейся, чтобы больше никогда не залазить руками. Статья - практическая инструкция: команды, конфиги и понятные критерии.

Хардверные пет-проекты, которые можно «пощупать», неспроста полюбились тем, кто работает преимущественно в цифровой среде. Мы в Beeline Cloud решили разобраться, насколько полезно может быть такое аппаратное хобби с точки зрения ученых (спойлер: еще как полезно). А также подобрали несколько DIY-проектов, которые займут не один вечер, позволят применить инженерные навыки и прокачать скилл креативного решения задач. В подборке: DIY-фотокамера, скейтборд, роборука и телескоп.

Вам точно нужен только HTTP-мониторинг? А как насчёт проверки, что DNS резолвится правильно, SMTP-сервер принимает почту, а Minecraft-сервер отвечает на handshake? В PingZen мы добавили 22 протокола, включая Transaction с Playwright, чтобы вы могли мониторить буквально всё. Рассказываю, зачем это нужно и как работает «под капотом».

В конце ноября 2025г. у части интернет провайдеров в Сибирском и Дальневосточном округах появились проблемы с использованием TLS прокси. Блокировка появлялась после активации прокси для всей системы, но не при проксировании отдельных сайтов.

Читайте далее чтобы узнать что я обнаружил.

Иногда нужно получить SSH-доступ к домашнему серверу (ноутбуку или мини-серверу на Ubuntu), который находится за NAT/CGNAT провайдера. Публичный IPv4 отсутствует, а использовать VPN или облачные туннели (ngrok, Cloudflare Tunnel и т.п.) не хочется.

Один из простых способов — обратный SSH-туннель с помощью autossh + проксирование через уже существующий Xray-клиент (VLESS + Reality), который и так работает для выхода в интернет.

Привет! Меня зовут Денис, я 3D-художник и Linux-энтузиаст. Более 8 лет Arch Linux является моей основной и единственной операционной системой. Сегодня хочу рассказать об установке Arch Linux на ZFS.

Почему ZFS?
Однажды я решил собрать stripe (RAID0) на ноутбуке с двумя дисками. Хотелось сохранить привычную структуру директорий и не думать о том, на каком диске что лежит.
На тот момент я уже использовал ZFS на файловом сервере, а на ноутбуках - Btrfs + LUKS2. Загрузить Arch Linux с RAID на btrfs у меня не получилось. С ZFS, напротив, не возникло никаких трудностей.

Задача:

Привет! Это команда Яндекс Практикума, сегодня мы вместе с вами рассмотрим, что из себя представляет DevOps в 2026 году и расскажем про онлайн-магистратуру ИТМО в партнёрстве с Яндекс Практикумом «DevOps‑инженер облачных сервисов»: кому подойдёт программа, как поступить в 2026 году, какие навыки вы будете изучать, какие у вас будут перспективы в этой области и при чём тут искусственный интеллект.

Задача на 30 секунд — ssh root@192.168.31.197 — превратилась в расследование: VPN перехватывает локальный трафик, индексы интерфейсов тасуются при перезагрузке, два WiFi-адаптера в одной подсети создают хаос. Разбираю таблицу маршрутизации Windows, longest prefix match и split tunneling на живом примере.

Давно уже наступил срок End of Life у Enterprise Linux 7, но возможно на ваших серверах он еще есть в работе. Затягивание процесса переноса могло произойти по разным причинам: сложные процессы миграции, необходимость в дополнительных мощностях для маневра, длительность процесса переноса, зависимость от бизнес-процессов заказчиков.

Зачастую upgrade ОС на месте — самый удобный способ. В данной статье я описываю инструменты и трудности, с которыми вы можете столкнуться в процессе.

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

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

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