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

3 июня 2026 года Эндрю Триджелл, один из авторов rsync (и создатель Samba), написал пост, перевод которого предлагается ниже. Поводом стала волна негодования после релиза rsync 3.4.3, в котором закрыли шесть уязвимостей: пользователи начали сообщать о регрессиях, из‑за которых ломались уже работающие конфигурации и сценарии, годами считавшиеся привычными, надежными, рутинными.

Можно было бы сказать «бывает», но масла в огонь подливал тот факт, что незадолго до этого в истории коммитов rsync появилось около пятидесяти изменений, подготовленных с помощью Claude. На этом фоне любые сбои почти автоматически стали читаться как «в важный инфраструктурный проект пустили ИИ, и он нагенерировал плохие исправления» — сами понимаете, как к такому сейчас относится ИТ‑сообщество.

В списке того, что поломалось, были и инкрементальные бэкапы с несколькими --compare-dest, и сборка на старых ядрах Linux и старых версиях macOS, и поведение --link-dest, и другие привычные сценарии. Триджелл ответил не тредом в комментариях, а отдельной заметкой в своём блоге на Medium — местами раздраженной, местами ехидной, но ценной именно тем, что это взгляд опытного инженера, который сейчас реально держит на себе проект.

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

С вами снова я — Павел Мирошин, тимлид команды разработки «Графини» (первый аналог Grafana, написанный с нуля). И сегодня хочу немного рассказать о том, что мы сделали в новом большом релизе 2026H1 «Ассамблея».

Внутри про кеширование витрин, прогнозирование, импорт дашбордов из Grafana и другие обновления.

Мы пройдем по самым интересным техническим граблям создателей сети: от концепции «Галактической сети» Ликлайдера до первого в истории упавшего сервера и того дня, когда интернет чуть не стерла уборщица с пылесосом в CERN. Разбираемся, как зоопарк несовместимых машин превратился в нервную систему планеты.

Привет Хабр! Это снова Дмитрий Закорючкин из компании Avanpost, и сегодня я продолжаю рассказывать про нашу службу каталогов — Avanpost Directory Service. Я уже писал про наш подход к групповым политикам, а мой коллега освещал такую важную тему как устройство бекенда каталога. Темой сегодняшней статьи станет контроль доступа в Avanpost DS (не ролевая модель — это тема для отдельной статьи, а именно механизмы контроля доступа).

Передача АV-сигналов на основе технологии AVoIP (Audio Video over IP) постепенно вытесняет классическую коммутацию: маршрутизация по Ethernet более удобна и масштабируема по сравнению с матричной, ограниченной количеством портов коммутатора. Однако помимо озвученных преимуществ она наследует уязвимости IP-сетей. 

Согласно данным AVIXA(Ассоциация Аудиовизуального и Интеграционного Опыта), инциденты в AVoIP инфраструктуре, связанные с сетевой безопасностью, происходят по весьма банальной причине: зачастую AV‑инженеры не считают себя сетевыми специалистами, а IT‑отдел не контролирует AV‑сегмент.  

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

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

Я срьрал 100+ вопросов с собеседований по Rust с краткими разборами: владение, типажи, конкурентность, async, unsafe, производительность и др. Отдельный продвинутый блок A1–A21 для staff-уровня. Цель - показать, где обычно спотыкаются даже опытные, и помочь подготовиться к следующему собеседованию. Надеюсь будет реально полезно!

Около месяца назад я решил испытать один интересный технический сценарий организации кабельного скоростного канала передачи данных между двумя компьютерами/ноутбуками. Речь о штатной возможности Thunderbolt 3/4/5 портов работать в так называемом режиме Thunderbolt Networking. Суть этого способа кабельной передачи в следующем:

Попытался структурировать всю эту прекрасную линуксовую фрагментацию и собрал «айсберг» дистрибутивов

Если у вас пет-проект или небольшой стартап на GitLab.com, рано или поздно вы упрётесь в потолок бесплатного тарифа: 400 минут пайплайнов в месяц и общая очередь раннеров. Покупка дополнительных минут стоит денег и не решает вторую проблему: общие раннеры GitLab обслуживают миллионы проектов, и в часы пик ваша джоба может провисеть в очереди 10-20 минут.

Решение — свой GitLab Runner на VPS: без чужих джоб, под полным контролем. Такой раннер не имеет лимитов по времени, кроме ресурсов самого сервера. В статье за вечер собираем такой раннер с нуля на Ubuntu 24.04 LTS, поднимаем пайплайн на три стадии (тесты, сборка Docker-образов, пуш в GitLab Container Registry), добавляем кэширование, безопасность и автообновление.

Всем привет, меня зовут Илья и я хочу вам рассказать как я после небольшой правки в тераформ я потерял все мастера в кластере Elasticsearch. ЧатГПТ и гугл уже принесли мне лопату чтобы похоронить эти сервера, но начальство сказало: "Может что нибудь придумаешь?". В итоге 6 часов работ и кластер снова живой и зеленый. Хотите знать больше?

Продолжаем серию «Адаптивное администрирование Sigla Vision». Разберем кейсы, где триггеры в базе FineDB помогают решать задачи администрирования Sigla Vision.

Привет, Хабр! Меня зовут Всеволод Коваленко. В Газпромбанке я занимаюсь развитием функционала BI-системы на базе Sigla Vision.

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

Домашний удалённый доступ без панели: эксперимент с Xray, Docker Compose и локальным CLI

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

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

На этом этапе обычно появляется знакомый выбор: открыть SSH, поправить JSON руками, рестартануть контейнер и пообещать себе «потом нормально оформлю». Через пару месяцев «потом» превращается в маленький прод: пользователи, секреты, квоты, бэкапы, мониторинг, логи, обновления и вопрос, какие изменения на сервере были осознанными, а какие - следами экспериментов.

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

Но и жить в режиме ssh -> vim -> docker compose restart мне тоже не хотелось.

Поиск по open source проектам — не дал результата. Многое из того, что я пытался ставить, либо не запускалось, либо было написано на bash, где было много хардкода, который приходилось переписывать под мои VDS. Потратив несколько вечеров - я понял, что есть запрос на простое решение по оркестрации self-hosted VPN серверов с локальным хранилищем и удобным масштабированием.

На вопрос «Зачем?» Ответ простой ради фана и максимальной отказоустойчивости.

Долгое время я сидел на стандартном гигабитном канале от одного провайдера и горя не знал. Но в какой-то момент обычного интернета стало мало. Тогда и родилась безумная идея: а что, если завести в обычную квартиру сразу двух независимых операторов и заставить их работать как единое целое, выжимая максимальную скорость из возможного?

На этом я не остановился и решил проверить, жив ли IPv6 в России в 2026 году.
Спойлер: пациент скорее мертв, и большинство провайдеров застряли в прошлом веке, наглухо игнорируя этот стек.
Однако я нашёл того самого редкого оператора, который не просто дал доступ, а выделил мне полноценный «жирный» префикс /56. Теперь моя домашняя сеть работает на базе пула 2a05::/56, пока весь остальной дом делит остатки IPv4.

Чаще всего в качестве ID пользователя безальтернативно выступает номер телефона, что не соответствует идеям приватного общения. Очевидное решение - использование мессенджеров, которые идентифицируют пользователя действительно анонимно. Я попробовал настроить свой домашний сервер Delta Chat и вот что из этого получилось.

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

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

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

В статье покажем оба варианта на практике, разберем получение токенов для GitHub, GitLab, Bitbucket и Gitea, а также расскажем о нюансах, которые стоит учесть перед переносом.

Представьте, что завтра из нашего мира исчезнут все проекты Линуса Торвальдса. Ваш смартфон на Android моментально превратится в кирпич, интернет ляжет, а вся командная разработка ПО намертво встанет без Git. Удивительно, но вся современная цифровая инфраструктура держится на решениях, которые были придуманы одним человеком не ради миллиардов или славы, а просто из любопытства. В этой статье вспоминаем путь главного интроверта IT: от попыток починить старый Commodore до создания ядра Linux, победы над Microsoft и революции в Open Source.

Привет, постоянные и не очень читатели!

Всего одна сделка (зато какая — на 61 000 000 000 $) неплохо так встряхнула мир виртуализации и IT в целом: Broadcom купила VMware, упразднила кучу SKU и ввела подписную модель лицензирования крупными пакетами (многие оплачивают то, что им и не нужно вовсе, так как пакетов меньше просто нет). Самое плохое, что ни партнёры, ни конечные клиенты не были готовы к такому повороту событий и сопутствующему ущербу, а потому до сих пор оправляются.

Вариантов, как все выкручиваются, много, а довольных новой моделью VMware by Broadcom — мало. Если у вас тоже наболело или вы просто зашли поглядеть на ещё один способ сложить (или нет?) все виртуалки в одну проприетарную корзину Huawei Cloud Stack, то эта серия статей для вас.

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

В этой статье будет рассмотрено, как работает подсветка байтов и какие hex-редакторы поддерживают это.

Bash прощает многое: можно писать кривые скрипты годами, и они будут работать. Кривизна вылезает, как правило, в самый неподходящий момент.

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