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

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

Однако существует большое количество интересных и полезных программ, которые распространяются разработчиками либо через собственный сайт, либо через релизы на GitHub, либо в виде статического бинарника, либо вообще исключительно в исходниках (при этом под той же Windows у того же проекта часто есть нормальный инсталлятор с автопроверкой обновлений).

Когда таких программ накапливается достаточное количество, их сопровождение превращается в настоящий цирк.

Я решил для себя этот вопрос создав собственный apt репозиторий.

Каждый плановый патчинг парка RedOS у меня начинался одинаково: запускаешь обновление — и где‑то на третьем сервере оно падает, потому что в /var или /boot кончилось место. Дальше знакомый ритуал: идёшь в vCenter, увеличиваешь диск, растишь раздел, pvresize, lvextend, молишься, что не перепутал диск, возвращаешься к обновлению. На одном сервере — терпимо. На парке — тоска.

В какой‑то момент я решил, что хватит, и написал комплект из двух Ansible‑ролей: первая сама находит, где тесно, и безопасно доращивает LVM (при необходимости — увеличивая VMDK через vCenter), вторая обновляет ядро и пакеты одной транзакцией и проверяет, что сервер после ребута жив и загрузился с правильным ядром. Всё запускается с jump host, хосты идут по одному (serial: 1), полный цикл — одна команда:

bash

Директор по ИТ отвечает за технику, которую не может ни посчитать, ни показать. Лицензии в почте, железо в кладовке, учёт в головах. Приходит проверка — спорить нечем. Приходит финдир — доказать нечем. Разбираем, зачем нужна система учёта активов и при чём тут контроль, деньги и полномочия.

Трафик внутри Kubernetes может быть зашифрован и при этом оставаться уязвимым: сервисы принимают самоподписанные сертификаты, а API-сервер не проверяет подлинность kubelet. В этой статье разберём рабочую схему с внутренним CA, cert-manager, trust-manager и контроллером одобрения CSR, которая позволяет убрать небезопасные исключения и выстроить единую цепочку доверия для рабочих нагрузок и управляющей плоскости.

У нашего облака появился новый тип пользователей, и это не люди. Каждый третий запрос к документации Timeweb Cloud сегодня приходит из сетей ИИ-вендоров, а серверы всё чаще создаются не из панели управления, а запросами к API, которые пишет ассистент по просьбе человека.

Привет! Меня зовут Михаил Шпаков, я руковожу разработкой Timeweb Cloud. Раньше я рассказывал, как мы построили систему автотестов с 5 000+ проверками и как делаем визуализацию облака. Сегодня текст другого масштаба: не про одну систему, а про то, куда движется рынок облачных услуг. Трендов там, разумеется, больше одного, но этот текст про тот, который я вижу ближе всего: про агентов. Покажу картину, которая складывается изнутри провайдера, подкреплю её цифрами и расскажу, какие выводы я делаю из неё на ближайшие годы.

Я не программист и не инженер. Я предприниматель, который собирает нейросетевые автоматизации для бизнеса. За полтора года такой работы я заменил нейросетью несколько отделов: где-то из семи человек оставался один, где-то двое.

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

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

В начале июля разработчик Ноа Кейгл выпустил Hannah Montana Linux v26.0 — современный ремастер того самого розового дистрибутива-мема из 2008 года. Тут можно улыбнуться, поностальгировать и решить, что вся новость закончена, но давайте не будем спешить. За этой несерьезной обложкой прячется на редкость наглядный пример того, что такое дистрибутив Linux на самом деле. А заодно становится понятно, почему нельзя просто оставить старую версию и жить дальше. Тут надо разобраться во всем по порядку и ответить на некоторые вопросы. Этим и займемся.

Ошибка Cannot assign requested address, внезапные обрывы соединений и растущее число сокетов в TIME_WAIT часто выглядят как странности Linux, пока сервис не начинает терять доступность под нагрузкой.

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

В аналитике больших данных системы массивных параллельных вычислений часто находятся под постоянной нагрузкой в режиме 24/7. Из десятков и сотен тысяч запросов в день многие исполняются одновременно и конкурируют за ограниченные ресурсы вычислительного кластера. Чем рациональнее каждый отдельный запрос их использует, тем больше запросов система сможет обслуживать параллельно. Соответственно, выше пропускная способность за конкретный отрезок времени. Как правило, проблема нехватки ресурсов остро ощущается в пиковые часы нагрузки. Можно бесконечно до совершенства настраивать и править параметры сессии на каждый запрос индивидуально вручную, но нам — команде разработки платформы данных Data Ocean Nova — всегда хочется иметь более системный подход.

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

Спор вокруг Unix и его возможного следа в Linux уже пережил банкротства, смену владельцев, несколько переименований компаний и даже смерть одного из главных участников. В последние годы могло показаться, что он утих, но нет. В июне 2026 года в Апелляционном суде второго округа США прошли слушания по делу Xinuos против IBM. Компания, которая когда-то купила остатки бизнеса SCO, пытается доказать, что у нее есть основания требовать компенсации. И хотя перспективы выглядят скромно, сам факт возвращения спора показывает, насколько запутанной оказалась история прав на одну из важнейших операционных систем прошлого.

В первой части мы собирали свой собственный минимально необходимый образ системы с рабочим столом Mate и остановились на собраном архиве mate-rootfs.sqfs.

Во второй части мы сделаем установку образа на основной диск, произведём разметку диска, и сделаем загрузку нашего ядра Linux без посредников в виде grub, systemd-boot

Привет, Хабр! В прошлых статьях мы уже обсуждали эволюцию подходов к мониторингу — от ручного анализа данных до использования MCP-серверов для взаимодействия с LLM  и сравнивали философию open-source стека (Prometheus + Grafana) с готовыми APM-платформами . Сегодня я хочу применить этот опыт к специфичной, но крайне важной области — мониторингу систем на платформе «1С:Предприятие».

Задача мониторинга 1С-ландшафта традиционно считалась нетривиальной. Причин несколько: это и закрытость платформы, и специфические источники данных, и сложность интерпретации происходящего для бизнеса. Однако за последние годы инструментарий сильно шагнул вперед. Давайте разберем, какие вообще существуют способы заглянуть под капот работающей 1С — от классических штатных средств до современных решений, строящих единую картину наблюдаемости.

Мировой кризис взвинтил цены на память и комплектующие. В такой ситуации лучшая стратегия — рационально относиться к старому железу. Например, у Meta* в новых DDR5-серверах работает старая память DDR4 через кастомную ASIC-микросхему Vistara без потери производительности. То есть ребята разработали собственный чип, карту-переходник для CXL и драйверы для ядра Linux — лишь бы использовать старую память.

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

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

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

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

Когда инфраструктура начинает сбоить, причина редко остаётся в одном слое: за проблемой с деплоем тянутся пайплайны, контейнеры и секреты, а за деградацией сервиса – логи, сеть, база данных или настройки Linux. В этом дайджесте собрали практические материалы по K8s, CI/CD, DevSecOps, наблюдаемости, PostgreSQL и отказоустойчивости – для тех, кто хочет быстрее находить слабые места и лучше понимать, как связаны компоненты современной инфраструктуры.

ИТ‑департаменты и интеграторы часто сталкиваются с дилеммой: закупить партию дешёвых потребительских «коробочек» для склада, цеха или digital signage либо инвестировать в специализированные решения. В этом обзоре мы критически разберём актуальное портфолио промышленных ПК на примере линейки MSI Industrial — от ультракомпактных «кирпичей» до локальных ИИ‑суперкомпьютеров — и посмотрим, как обстоят дела с их поставками в Россию.

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

Docker — отличный инструмент, но «отличный» не значит «единственный» и тем более не значит, что он подходит для любой задачи. На одиночном сервере с одним-двумя приложениями Docker может принести больше проблем, чем пользы. Демон, образы, слои, сети и тома упрощают упаковку и запуск приложений, но на одиночке или небольшом VDS они избыточны. Под катом о том, в каких случаях Docker не нужОн, чем его заменить и как. 

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

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

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

До этого я сравнивал интересные мне хостинги примерно раз в год — не видел смысла делать это чаще. После недавнего сравнения российских VPS/VDS-хостингов прошло не так много времени, но появился повод вновь вернуться к этой теме. А именно, в комментариях вполне ожидаемо спросили «а где остальные крупные игроки?», да и в личку написало несколько представителей компаний с предложением протестировать их услуги. Поэтому пока старые цифры не остыли, по просьбам трудящихся решил добавить к результатам тестов ещё несколько компаний, которые мне показались интересными. 

Под катом — результаты тестирования уже 9 серверов от следующих компаний: трёх новых (FirstVDS, AdminVPS, Рег.ру) и 6 старых (Timeweb, RUVDS, CLO, AEZA, VDSina и Selectel). Теперь, когда результатов стало больше, можно не только посмотреть на новичков, но и оценить, насколько они меняют в целом общую картинку.

Копипаст .gitlab-ci.yml по десяткам сервисов привел к config drift: пайплайны расходились, а правка одной строчки требовала 10+ MR. Вынесли логику CI в отдельный репозиторий модулей, подключаемых через include с версионированием по SemVer — в проекте остается только короткий файл с переменными. В итоге миграция с Kaniko на BuildKit заняла 5 дней вместо 2-3 недель, а типовой багфикс на 20 сервисах — 1 час вместо 11.