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

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

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

Недавно Canonical представила Ubuntu Core 26 — новую версию своей компактной платформы на базе Ubuntu 26.04 LTS. Разработчики сохранили ставку на безопасность и долгую поддержку, но при этом заметно упростили обновление устройств, сборку образов и повседневную работу с системой. ОС предлагает до пятнадцати лет обновлений безопасности, более компактные системные образы и доработанный механизм OTA-обновлений. В релизе появился новый процесс сборки через Chisel, уменьшился размер обновлений благодаря snap-delta и заработал Livepatch для ARM64. Эти изменения упрощают сопровождение устройств, которые должны работать годами без прямого доступа и регулярного обслуживания. Давайте оценим новинку.

На связи Дмитрий Рыбалка, SRE‑инженер Mindbox. В статье описываю стандартный инструмент для нагрузочного тестирования k6 в новом амплуа: как агента для мониторинга, который в ряде случаев работает лучше, чем привычные инструменты. 

В материале рассказываю, как настроить К6, что смотреть в итоговом отчете и как анализировать метрики. А еще делюсь реальными кейсами применения агента.

На bare metal внешний доступ к Kubernetes часто становится головной болью: NodePort с рандомными нестандартными портами не для продакшена, а облачного балансировщика нет. MetalLB превращает обычные узлы кластера в полноценный балансировщик с автоматическим failover. Разбираем режимы BGP и L2, а ещё показываем фишку Deckhouse Kubernetes Platform, которая спасает активные соединения при падении узла.

Всем привет. Мы в Ænix давно занимаемся Kubernetes-платформами, bare metal-инфраструктурой и Cozystack, поэтому тема блочного хранилища для Kubernetes у нас не теоретическая. Это та часть стека, где красивых абстракций быстро становится мало: надо переживать падения нод, понимать топологию, реплицировать данные, не ломать PVC, дружить с CSI и при этом оставаться предсказуемыми для операторов.

Сегодня хотим показать первый публичный результат этой работы — Blockstor 0.1.0.

Blockstor — это открытая система управления распределенным блочным хранилищем для Kubernetes. Она использует DRBD для репликации данных, совместима с REST API LINSTOR и написана на Go как самостоятельная clean-room реализация. Код распространяется под Apache 2.0.

Подготовлены .ini файл с настройками TinyPXE Server, скрипт запуска WinNFSd, загрузочные файлы iPXE и скрипт autoexec.ipxe. В общем все необходимое для запуска PocketHandyBox Linux через PXE на почти любом ПК в локальной сети, используя в качестве сервера любой ПК/ноутбук с Windows.

Благодаря поддержке в TinyPXE Server режима ProxyDHCP, при наличии в локальной сети основного DHCP сервера (без настроенной опции 67) / роутера - нет необходимости как либо вмешиваться в его работу. А также нет необходимости изменять IP адреса или файловые пути в каких либо конфигах.

Все необходимое для запуска серверной части на Windows находится в одной папке. Не требует установки каких либо служб или правки реестра. То есть просто копированием переносится между разными Windows ПК и разными локальными сетями.

Поддерживается загрузка через PXE как в UEFI так и в Legacy/CSM режимах. К сожалению Secure Boot не поддерживается и его требуется отключать.

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

В этой статье я попробую рассказать о том, в каких случаях для выявления неисправностей в сети может быть полезно, помимо опроса оборудования, принимать сообщения о наступившем событии от устройства. Мы разберём, как работает гарантированная доставка информации о событии, чем Inform лучше чем Trap и в чём сложности его использования. Немного углубимся в детали работы Trap/Inform-сообщений, а закончим простым примером настройки Zabbix. Надеюсь, материал получился интересным и оригинальным.

После перехода на macOS я не нашёл SSH-клиент, который закрывает мой ежедневный сценарий так же удобно, как WinSSHTerm.

Устал от постоянных компромиссов, сформулировал требования, собрал свой клиент и выложил код в open source.

Репозиторий

Мы небольшой региональный интернет-провайдер. Недавно случился у нас инцидент.

Первый звоночек прозвенел, когда было зафиксировано резкое уменьшение нагрузки на внешнем интернет‑канале, сопровождавшееся записями в логах KERNEL PERF interrupt took too long, lowering на одном из серверов, обеспечивающих доступ в сеть Интернет. Расследование показало, что нагрузка вернулась к норме в течение 15 минут, и никаких последствий не было выявлено.

Если назначить файлу владельца root на хосте — будет ли это тот же самый root внутри контейнера?

Если на хосте существует пользователь gtosss — можно ли переключиться на него внутри контейнера и получить доступ к файлу?

Если создать пользователя gtosss внутри контейнера и выдать ему права на файл — сможет ли хост обратиться к этому файлу под таким же пользователем?

Большинство разработчиков знают, что контейнеры изолируют процессы. Но мало кто задумывается о том, что происходит с правами, когда например директория с хоста монтируется внутрь контейнера через volume (bind mount).

Разобрал три конкретных сценария на Ubuntu с Docker и Fedora с Podman: как UID/GID влияют на доступ к файлам, почему root в контейнере может быть root на хосте и что с этим делает user namespace. Эксперименты, cli и доступные объяснения.

io_uring продавали как убийцу epoll. На деле на HTTP keep-alive разница 0-15%, иногда не в его пользу. Но на NVMe с queue depth 128 - в 3 раза быстрее. Честный разбор с бенчмарками, реальными граблями (SQPOLL, cancel race, partial recv) и почему Google отключил io_uring в ChromeOS.

Когда сервис падает с too many open files, первое желание — проверить ulimit -n и поднять лимит повыше. Но в Linux эта ошибка редко сводится к одной настройке: в игру вступают файловые дескрипторы, сокеты, лимиты процесса, настройки контейнерного рантайма и поведение самого приложения.

В статье разбираем, что на самом деле означает EMFILE, где смотреть реальные ограничения в Kubernetes и как отличить нехватку лимита от утечки, которая рано или поздно снова уронит прод.

VBoxGuest — драйвер гостевых дополнений для KolibriOS, написанный с нуля на FASM.

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

Сравнение с upstream-реализациями для Linux/Windows/FreeBSD. Для системных программистов и энтузиастов OSDev.

Команда Nixys готовит к выпуску версию 3.1.0 nxs-universal-chart. Этот релиз аккумулирует все изменения, вошедшие в промежуточные сборки v3.0.10 - v3.0.21, а также новые фичи. Ниже — разбор ключевых нововведений и исправлений.

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

Мы открываем его, видим три колонки цифр и букв, и кажется что все предельно ясно-понятно. Но почему адреса считаются шестнадцатеричными, что такое ниббл и зачем он вообще нужен? В этой статье мы не просто напишем свой hex-редактор на Python — мы разберем, как он устроен, от битового представления до цветовой подсветки. Выясним, чем подсветка по нибблам отличается от подсветки по категориям байтов, и почему градиенты в hex-дампе — это не просто украшение, а рабочий инструмент.

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

Будет и код, и архитектура, и результат, и практика.

Две сцены, которые видел в разных компаниях в последний год.

Сцена первая. На стене в кабинете директора по ИТ висит большой телек, на нём дашборд: «Availability 99.83%», зелёные плашки, всё хорошо. В этот же момент этажом ниже бухгалтерия пишет в поддержку: «1С зависла, не можем закрыть смену». Дашборд не врёт — 99.83% хостов реально доступны. Просто из этих хостов 78 — тестовые стенды, 12 — резервные узлы, и ещё пачка в SCADA‑сегменте, который вообще про другое.

Сцена вторая. Заходишь в Zabbix новой компании после предыдущего админа. Четыре тысячи хостов, двенадцать тысяч триггеров, средний возраст триггера три года. Runbook'ов нет. У всего severity High. Алерты падают в один телеграм‑чат на пятьдесят человек, который дежурный молча мьютит первым делом после прихода на смену.

Если хоть одна сцена узнаваемая — статья для вас. Это попытка структурировать ошибки, на которых ломается большинство Zabbix‑инсталляций в крупных компаниях с 1С, Exchange, SCADA, legacy‑Windows‑стеком и КИИ‑сегментами.

Это не учебник и не пошаговая инструкция — каталог граблей из практики работы с крупной разнородной инфрой: 1000+ хостов, 1С, SCADA, КИИ‑сегменты, legacy Zabbix от предшественников. На облачной 20-хостовой инсталляции половина пунктов будет избыточна. Конкретные пороги (CPU > 85%) — отправная точка, не догма. Если текст расходится с реальностью — побеждает реальность.

Привет, Хабр! На связи Юрий Власенко, Senior DevOps инженер в РТЛабс. Сегодня я расскажу о том, как наша команда автоматизировала сложный, бюрократизированный и многоуровневый релизный процесс компании и превратила его в тестируемый объектно-ориентированный код на Groovy (Jenkins).

CKS является довольно специфическим экзаменом по Kubernetes и если вами активно не используются инструменты, которые рассматриваются на экзамене, то подготовка будет сложнее. У меня ушло на подготовку 8 месяцев и две попытки, где большую часть времени не было четкого плана как подготовится к экзамену, так как информации в интернете не так много, как при подготовке к CKA. И вам нужно сдать Certified Kubernetes Administrator (CKA), чтобы вас допустили до CKS.

Подготовку к экзамену я бы разделил на несколько этапов.

Этап первый — разведывательный

Можно бесплатно порешать задачи на https://killercoda.com/ Есть два неплохих курса, где можно попрактиковаться в решении задач.

https://killercoda.com/ronnyardi

https://killercoda.com/killer-shell-cks

Рекомендую перенести в отдельный документ каждую задачу с вопросом и решением с ссылками на документацию на https://kubernetes.io/docs/home/ и вашим кратким комментарием как вы понимаете, о чем вообще идет речь и сложная ли для вас задача. На первом этапе вам нужно научится быстро ориентироваться в документации. Например, очень много вопросов по Security Context и Network Policy. Нужно понимать какой Security Context можно задавать на уровне пода, а какой на уровне контейнера. Это можно посмотреть через встроенную документацию.

HTAP — одна из главных тем в мире СУБД. Вокруг PostgreSQL массово появляются конструкции с внешними аналитическими движками со своими моделями хранения данных и ограничениями совместимости, однако бизнесу не совсем комфортно жить в архитектуре, где транзакционные данные находятся в одной системе, аналитика — в другой, а между ними — разного рода ETL, CDC и прочие parquet‑файлы.

В Tantor мы движемся по иному пути, развивая HTAP внутри PostgreSQL, а не рядом с ним. Вокруг этой идеи строятся СУБД Tantor Polar и машина баз данных Tantor XData Gen3, в которой OLTP и аналитика, не теряя совместимости с Postgres, работают поверх общего хранилища данных и общей видимости транзакций. В этой статье хочется поговорить не столько о самом термине HTAP, сколько о том, как меняется архитектура PostgreSQL, когда OLTP и аналитика начинают работать поверх общего хранилища данных.

История корпоративных систем хранения данных – это путь от жестко специализированных «черных ящиков» к гибким программным платформам. Каждый шаг этой эволюции решал проблемы прошлого, но неизбежно порождал новые противоречия. Сегодня, столкнувшись с радикальным усложнением инфраструктур (от классических ЦОД до частных облаков и объектов КИИ), – отрасль оказалась в точке, где наследие прошлых архитектурных решений стало главным ограничением для будущего. Современная корпоративная инфраструктура перестала быть монолитом. Сегодня это спектр архитектур и моделей потребления, каждая из которых предъявляет уникальные требования к системе хранения данных. С одной стороны - классические ЦОД с четким разделением ролей, ручным управлением и наследием в виде дорогих специализированных массивов. С другой - динамичные частные облака и гибридные среды, где инфраструктура должна предоставляться как сервис, масштабируясь по требованию и работая в условиях множества платформ. Между ними - гиперконвергентные кластеры, среды для критичных приложений (СУБД, VDI) и инфраструктура объектов КИИ, где на первый план выходят экстремальная производительность, отказоустойчивость и соответствие регуляторным требованиям. Все это многообразие объединяет одно требование: система хранения сегодня должна одинаково хорошо работать везде, будь то классический ЦОД или частное облако.