Системное администрирование *

Сервер работает. Инфраструктура — нет: открытые уроки для сисадминов

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

Собрали открытые уроки, которые будут полезны системным администраторам, DevOps‑инженерам, SRE и тем, кто хочет увереннее работать с production‑инфраструктурой.

Linux и автоматизация: меньше ручной рутины

• 4 июня, 20:00 — «Продвинутый Bash»
  _{Для тех, кто уже пишет shell‑скрипты и хочет использовать Bash увереннее.}

• 18 июня, 20:00 — «Основы Bash: пишем простые скрипты для автоматизации в Linux».
  _{Подойдёт тем, кто хочет системно подойти к автоматизации повседневных задач в Linux.}

• 22 июня, 20:00 — «Память в Linux. Cache, swap, dirty pages»
  _{Практичный урок о том, как Linux работает с памятью, почему «свободная память» не всегда означает то, что кажется, и как читать поведение системы до того, как всё закончится OOM.}

• 25 июня, 19:00 — День открытых дверей курса «Администратор Linux. Продвинутый уровень»
  _{Формат для тех, кто хочет понять, какие навыки нужны администратору Linux на продвинутом уровне.}

Что почитать перед уроками:

Мастерство поиска в Linux: Grep и регулярные выражения
_{Полезная база для тех, кто регулярно работает с логами, конфигами и текстовым выводом в консоли.}

Docker и контейнеризация: когда «работает локально» уже недостаточно

• 22 июня, 20:00 — «Контейнеризация Java‑приложений с Docker»
  _{Разберем, как упаковывать приложения в контейнеры и что учитывать при работе с Docker в инженерной среде.}

• 8 июня, 20:00 — «Java в Kubernetes за 40 минут: как задеплоить приложение в Minikube»
  _{Прикладной урок для тех, кто хочет посмотреть на деплой приложения в Kubernetes без длинной теории.}

Что почитать перед уроками:

Ваш docker‑compose.yml сломается: 5 настроек, которые все забывают
_{Разбор типовых ошибок в Docker Compose: лимиты ресурсов, restart policy, ротация логов, healthcheck и бэкапы volumes.}

Kubernetes, DevOps и self‑service‑инфраструктура

• 18 июня, 20:00 — «Kubernetes под прицелом: почему ваш кластер может взломать даже стажер и как этого избежать»
  _{Один из самых важных уроков для инфраструктурной аудитории: типовые ошибки в Kubernetes, слабые места кластеров и практики защиты.}

• 22 июня, 20:00 — «Роль и задачи DevOps в современном IT»
  _{Для тех, кто хочет разобраться, где заканчивается классическое администрирование и начинается DevOps‑подход.}

Сети и безопасность инфраструктуры

• 16 июня, 20:00 — «IDS/IPS как часть эшелонированной защиты инфраструктуры»
  _{Продолжение темы: как системы обнаружения и предотвращения атак встраиваются в многоуровневую защиту.}

• 22 июня, 20:00 — «OAuth 2.0, JWT и коварные куки: Проектируем безопасную аутентификацию»
  _{Полезно тем, кто работает с веб‑инфраструктурой, внутренними сервисами, прокси, доступами и безопасностью приложений.}

Что почитать перед уроками:

Разбираемся с форвардингом IP‑пакетов в сетевых уровнях L2 и L3 
Материал для тех, кто хочет лучше понимать, как пакеты проходят через сеть и где могут возникать проблемы при настройке инфраструктуры.

Мониторинг, SRE и инциденты

• 10 июня, 20:00 — «Мониторинг распределенных систем»
  _{Про наблюдаемость сложных систем, где проблема может быть не на одном сервере, а между сервисами, очередями, базами и сетью.}

• 16 июня, 20:00 — «Инцидент‑менеджмент в SRE. Как быстро находить, устранять и предотвращать сбои в системе»
  _{Практичный урок о том, как быстрее локализовать сбой, не тушить пожары вслепую и снижать вероятность повторения инцидентов.}

Все уроки бесплатные. На них можно познакомиться с преподавателями‑практиками, посмотреть на формат обучения и задать свои вопросы.

Если интересны не только инфраструктурные темы, в полном июньском дайджесте собраны ещё 62 бесплатных урока по разработке, данным, архитектуре, ИБ и AI.

Microsoft представила порт набора утилит Coreutils для платформы Windows. В состав входит несколько десятков утилит, включая sort, cat, chmod, chown, cp, find, sleep, sort, tee, echo, uptime и ls. Инструментарий позволяет напрямую использовать в Windows типовые утилиты, доступные в Linux и macOS, без использования прослойки WSL. Целью проекта заявлено упрощение перехода между Unix‑подобными системами, WSL, контейнерами и Windows, и предоставление единого набора команд, флагов и методов, позволяющих переносить существующие скрипты из других систем без переписывания. Код написан на Rust и PwerShell, и распространяется под лицензией MIT.

Реализация основана на коде проекта uutils (Rust Coreutils), развивающего вариант GNU Coreutils на языке Rust, а также реализациях утилит find и grep на Rust. Утилиты собраны в виде одного универсального исполняемого файла "C:\Program Files\coreutils\coreutils.exe", отдельные команды к которому привязаны при помощи жёстких ссылок в NTFS.

Из‑за конфликта с имеющимися штатными утилитами Windows или привязки к специфичным возможностям из поставки исключены утилиты dd, dir, dircolors, shred, sync, uname, expand, kill, more, paste, timeout и whoami. Из состава также исключены утилиты, завязанные на не поддерживаемые в Windows концепции POSIX: chcon, chgrp, chmod, chown, chroot, groups, hostid, id, install, logname, mkfifo, mknod, nice, nohup, pathchk, pinky, runcon, stdbuf, stty, tty, users, who.

Из ограничений и особенностей отмечается необходимость использовать NUL вместо /dev/null, отсутствие поддержки сигналов (SIGHUP, SIGPIPE, SIGUSR), возможность создания символических ссылок только после включения режима для разработчика, недоступность некоторых операций с правами доступа. При работе с каталогами принимаются как пути с символом "/", так и c "\".

Обмениваемся файлами на любых устройствах. Разработчики приложения для передачи данных по Wi‑Fi Localsend представили версию проекта для браузера:

• Работает за два клика: открываем приложение на двух ваших устройствах, которые подключены к одной точке Wi‑Fi, прикрепляем файлы и передаем их.

• Без регистрации, без установок, без ограничений.

• Подходит для любых ОС, передает файлы с большой скоростью и без дополнительных настроек.

Microsoft открыла исходный код инструментария Webwright, который запускает в браузере различные скрипты и выполняет задачи с помощью ИИ‑агентов:

• умеет сёрфить в сети, заказывать билеты, бронировать столики, искать товары и делать все, чтобы сэкономить время для пользователя;

• при этом каждое действие можно записать в скрипт и потом только корректировать в нем параметры;

• ИИ в это время будет проходить по коду, искать и исправлять ошибки;

• работает с большинством программ, сайтов и сервисов.

В self-hosted Git-сервисе Gogs обнаружили непропатченную уязвимость нулевого дня. Суть в argument injection: если включена опция Rebase before merging, атакующий может внедрить флаг --exec в команду git rebase через вредоносное имя ветки в пулл-реквесте.

Это даёт полный RCE. Злоумышленник получает доступ ко всем репозиториям, хешам паролей, API-токенам и SSH-ключам. Ситуация осложняется тем, что в Gogs по умолчанию открыта регистрация.

Под ударом версии 0.14.2 и 0.15.0+dev. Мейнтейнеры подтвердили баг ещё в марте, но патча до сих пор нет. Временные меры: закрыть публичную регистрацию, отключить rebase-merging или закрыть доступ к серверу "Из внешней сети".

The.Hosting — всё.

Сегодня The.Hosting разослал юзерам такое сообщение:

IMPORTANT: Notice of Service Discontinuation and Account Closure

Dear Customer,

We are writing to inform you that due to unforeseen and unavoidable force majeure circumstances, THE.Hosting is forced to permanently discontinue all its operational services and wind down its activities.

As a result, our platform, support channels, and all associated services will be closed in the coming days.

What this means for you:

➖ New Orders & Renewals: All active forms of registration, ordering, and renewals have been disabled. No new services can be purchased.

➖ Data & Accounts: If you have any active data, configurations, or account details stored within our systems, we urgently advise you to retrieve and back up your information immediately.

➖ Final Termination: Once the wind-down process is completed, all accounts and data will be permanently deleted from our systems.

We deeply regret that we are forced to take this step and understand the inconvenience this causes. We want to thank you sincerely for your partnership and trust in THE.Hosting over the past period.

Sincerely,The Management of THE.Hosting

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

Проблемы у The.Hosting начались около двух недель назад, через несколько дней стало известно об изъятии серверов в Нидерландах, теперь история подошла к закономерному финалу.

Представлен открытый проект FluentCleaner (аналог CCleaner), который умеет очищать ПК на Windows 10/11 от мусора, бесполезных процессов, дубликатов файлов и всяческого хлама, замедляющего ОС. Все удаления на ПК согласовываются с пользователем.

«Современный, прозрачный, без шпионского ПО, без скрытых ненужных вставок, без тёмных паттернов, без навязчивой рекламы, без фальшивой магии реестра», — пояснил разработчик проекта по имени Belim (aka Builtbybel). Этот автор является создателем проекта Winslop для удаления ненужного системного мусора в Windows 10/11 (он недавно был переименован в Winslopr — Windows Slop Remove).

Три подразделения, три правды. Куда уходит ИТ-бюджет и при чём тут ITAM

Бухгалтерия: «3000 на балансе». ИТ: «1800 в сети». Безопасность: «2200 под защитой». И никто не врёт — каждый считает свой срез.

Корень проблемы — не сами расходы, а отсутствие единой экономической модели ИТ. CFO видит строку «50 млн руб./год» без детализации. CIO знает, что серверы на грани, но не может перевести это на язык финансов. Бизнес требует цифровизации, не понимая нагрузки на бюджет.

При этом контекст 2024–2026 усложнил всё кратно: параллельный импорт — плюс 20–40% к закупкам, импортозамещение — рост годового бюджета на 40–70% не за счёт расширения, а за счёт выкупа лицензий в альтернативных стеках. Компании тратят миллионы на ПО «про запас», которое не используют прямо сейчас.

Если раньше мы платили 10 млн руб./мес. за подписку M365, то сейчас вынуждены держать 50 млн руб. единовременного резерва на закупку ПО в реестр, плюс 15 млн руб./мес. на доработку интеграций.

Алексей Бородин, эксперт по развитию ITAM- и ITSM-проектов

Совместно с практикующими экспертами по ITAM и ITSM мы подготовили материал о том, как IT Asset Management помогает сделать ИТ-затраты прозрачными и управляемыми.

Внутри:

• Анализ ключевых вызовов 2024–2026: санкции, переход от OPEX к CAPEX, рост НДС, дефицит ИТ-специалистов

• Почему Excel, ERP, ITSM с CMDB и BI-системы перестают справляться с управлением затратами — и где у каждого инструмента потолок

• Системный подход к управлению ИТ-активами через ITAM — на примере SimpleOne ITAM

• Кейс ITGLOBAL.COM (by ITG): переход с Excel на ITAM в международной структуре с присутствием в 12 странах

• Чек-лист «Как сделать ИТ-затраты управляемыми»: 4 шага + методика расчёта TCO и ROI

📎 Скачать материал

Зачем корпоративному ИИ семантическое ядро: разбор стратегий SAP, Oracle и Palantir

SAP, Oracle, Palantir и другие корпоративные гиганты строят вокруг ИИ семантические слои: knowledge graph, ontology, process intelligence. Разбираемся, почему языковой модели недостаточно просто читать документы и таблицы.

Языковая модель умеет читать документы, таблицы, обращаться к API. Казалось бы, достаточно для корпоративного ИИ. Но SAP, Oracle, Palantir, Celonis, Alibaba и Yonyou активно строят семантические слои поверх данных: графы знаний, онтологии, process intelligence, платформы агентов.

Причина простая: корпоративному ИИ нужен не просто доступ к данным. Ему нужен смысловой слой предприятия — термины, объекты, экземпляры, статусы, источники, связи и правила качества. Без этого система остаётся набором отдельных функций, а не инструментом для комплексных управленческих решений.

Что такое семантическое ядро и зачем оно

Семантическое ядро — это структурированное описание бизнес-логики компании. Не просто схема базы данных, а модель того, как устроены процессы, как связаны объекты, какие правила определяют качество данных и переходы состояний.

Примеры таких слоёв, как сообщают SAP и Oracle:

• Knowledge graph — граф связей между сущностями бизнеса: клиенты, заказы, продукты, поставщики.

• Ontology — формальное описание терминов и отношений: что такое «заказ», какие у него могут быть статусы, как он связан с накладной.

• Process intelligence — карта фактических бизнес-процессов, извлечённая из логов систем: как реально движутся заявки, где возникают узкие места.

• Agent memory — контекст для агентов: что они уже делали, какие решения принимали, какие данные использовали.

Без семантического слоя ИИ-агент видит таблицы и документы, но не понимает бизнес-правил. Он может извлечь данные из накладной, но не знает, что делать, если сумма не сходится с заказом. Он может найти клиента в CRM, но не понимает, что этот клиент в чёрном списке.

Как это работает на практике

SAP строит Business Data Cloud — единый семантический слой поверх разрозненных систем учёта. Oracle развивает граф знаний для своих облачных приложений. Palantir предлагает онтологию как основу для агентных систем в Foundry. Celonis использует process mining для извлечения фактической логики процессов из event logs.

Типичный сценарий: ИИ-агент обрабатывает заявку на возврат. Без семантического ядра он видит запись в таблице. С семантическим ядром он знает:

1. Заявка связана с заказом, который уже частично оплачен.

2. Товар числится на складе, но фактически уже отгружен другому клиенту.

3. Клиент имеет статус VIP, что меняет правила возврата.

4. Есть открытый тикет в поддержке с похожей проблемой.

Агент не просто достаёт данные из разных систем. Он понимает контекст, проверяет правила и предлагает решение, учитывая бизнес-логику.

Ограничения и подводные камни

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

Второй риск — vendor lock-in. SAP, Oracle и Palantir строят закрытые платформы. Переход на другую систему означает переписывание онтологий и правил с нуля.

Третье — актуальность. Бизнес меняется быстрее, чем обновляется онтология. Если семантический слой не синхронизирован с реальностью, ИИ-агент будет принимать решения на основе устаревших правил.

Что это меняет

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

Это не революция, а эволюция корпоративных систем. Те, кто инвестировал в порядок данных и формализацию процессов, получают преимущество. Остальные застрянут на этапе экспериментов с чат-ботами.

TG @ciologia

Как я связал Zabbix и таск-трекер в обе стороны без отдельного сервиса У меня боевой Zabbix 7.0 на ~260 хостов, а заявки дежурной смены живут в Planfix. Уведомления в Telegram или Matrix никто не отменял, но когда над инцидентами работает смена, мессенджер неудобен: не видно, кто взял проблему, нет статусов и истории по задаче, сложно готовить отчеты. Хотелось, чтобы проблема мониторинга сама заводила задачу в трекере, а действия с задачей возвращались обратно в Zabbix, и всё это без сервиса-прослойки.

Очевидные пути отмёл сразу:

• Бот или демон - ещё один процесс, который сам надо мониторить: новая точка отказа в системе, которая как раз следит за отказами.

• Почта с парсером - не возвращает id созданной задачи обратно в Zabbix, и потом нечем связать восстановление триггера с конкретной строкой в трекере.

Требование «вернуть id задачи на событие» и определило всю архитектуру.

Прямое направление: Zabbix → трекер Собрал на штатном media type типа Webhook: один JS-скрипт по флагам события решает, какой эндпоинт трекера дёрнуть. Интереснее, где хранить связь «проблема ↔ задача». Внешнюю БД соответствий заводить не стал, обошёлся тегами события. При создании задачи скрипт возвращает Zabbix теги __zbx_planfix_taskid и __zbx_planfix_link; при process_tags=1 они вешаются на событие, и все последующие операции (подтверждение, закрытие, отмена) находят ту же задачу по тегу. Состояние живёт прямо на событии, отдельное хранилище не нужно.

Что всплыло уже в бою: отмена эскалации Уведомление «Escalation canceled» (эскалацию погасили, отключив хост или триггер) приходит с теми же флагами, что и новая проблема: event_value=1, event_update_status=0. Не различишь - скрипт примет отмену за новую проблему, заведёт дубль, и задача зависнет открытой навсегда: OK-события не будет, закрывать нечем. Поэтому скрипт сначала ищет в тексте уведомления фразу «Escalation canceled» и, только если её нет, считает событие новой проблемой. Подтверждение и снятие различаю по макросу {EVENT.UPDATE.ACTION}: в первой строке update-сообщения он разворачивается в acknowledged или unacknowledged - по этому слову задача уходит «в работу» или возвращается исполнителю по умолчанию.

Обратное направление - и оно оказалось самым интересным Делается средствами самого трекера, без отдельного сервиса. В Planfix это автоматический сценарий: событие «задача принята», условие «проект = ZABBIX», операция - POST в JSON-RPC API Zabbix, метод event.acknowledge с action=6 (подтвердить + добавить комментарий). Event ID берётся из поля задачи, того самого, что прилетел при создании. Главное: обратный вызов несёт email сотрудника, и подтверждение с комментарием проставляются в Zabbix от имени этого человека, а не безликого сервисного аккаунта. В истории события видно, кто реально взял проблему - тот, на кого назначена задача в трекере.

Что ещё пришлось учесть

• maxsessions=1 обязателен, иначе закрытие может обогнать создание, и правка придёт по ещё не существующей задаче.

• Создание задачи не идемпотентно: при ретраях возможен дубль (из Zabbix не узнать, дошёл ли запрос на самом деле), поэтому дедуп по event_id на стороне трекера обязателен - у меня он пока в планах.

• Шумовой фильтр - через эскалацию: операция на шаге 2 плюс условие «подтверждено = нет», иначе проблемы, мигающие по 30 секунд, плодят задачи.

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

Как снизить расходы на GPU в 2,5 раза и не потерять в производительности

Пока одни учат промпты, другие переписывают архитектуру ML-систем. Главная боль сегодня — не качество моделей, а экономика инференса и обучения. Разбираем свежие подходы к оптимизации GPU-часов и построению агентских систем на проде.

По данным Selectel, в майском ML-дайджесте собраны кейсы, где команды добились экономии GPU-времени в 2,5 раза без деградации метрик. Это не про тюнинг гиперпараметров — речь о пересборке inference-пайплайнов и переходе от монолитных моделей к композитным системам.

Уход ИИ в бэкенд: что это меняет

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

Ключевой момент: агенты на проде требуют переосмысления классических паттернов. Нужны механизмы откатов, версионирование промптов как кода, логирование цепочек рассуждений. Без этого отладка превращается в ад.

Новые стандарты агентских систем

Появляются попытки стандартизировать архитектуру агентов. Пока это не RFC-уровень, но сообщество сходится на общих паттернах: разделение планирования и выполнения, явное управление контекстом, изолированные инструменты с чёткими контрактами.

• Планировщик и исполнитель как отдельные компоненты

• Контекстное окно как ограниченный ресурс — управляем явно

• Инструменты агента с типизированными входами/выходами

• Логирование промежуточных шагов для отладки

Это не серебряная пуля, но хотя бы появляется общий язык для обсуждения архитектуры. До сих пор каждая команда изобретала велосипед.

Что в итоге

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

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

TG @ciologia

Открытый проект OptimizerDuck позволяет очистить Windows 10/11 от мусора и бесполезных процессов (телеметрию, рекламу, Copilot, все фоновые сервисы и ненужные приложения):

• оптимизирует ПК для работы и игр, настраивает GPU и производительность процессора, работает с менеджером автозагрузки, удаляет встроенный bloatware, чистит систему. 

• может откатить все изменения, если в процессе что‑то пошло не так. Бэкап у вас точно будет.

• работает без установки, без ограничений и полностью локально.

Передача параметров ssh с помощью суффиксов имени хоста

В случае, если доступ к определённым хостам по протоколу SSH требует запуска ssh с кучей параметров, стандартной рекомендацией является внесение всех этих параметров в отдельную секцию Host файла конфигурации ssh, пример которой приведён ниже. Данные параметры подробно описаны в ssh_config(5).

Host tproxy
  Hostname srv-10-79.dmz.company.com
  User srv_user
  Port 36602
  DynamicForward 127.10.0.79:1080
  LocalForward 127.10.0.79:4445 127.0.0.1:445
  LocalForward 127.10.0.79:8080 127.0.0.1:8080

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

• изнутри с переадресацией портов,

• изнутри без переадресации портов,

• снаружи с перадресацией портов,

• снаружи без переадресации портов,

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

Сущность предлагаемой доработки

Мною были перепробованы различные варианты доработки исходной рекомендации и, в итоге, был найден достаточно простой способ, заключающийся в разбиении конфигурации на отдельные секции в зависимости от суффиксов, добавляемых к имени хоста, передаваемого в качестве параметра команде ssh. Для отделения суффиксов от имени хоста и друг от друга оптимально использовать символ-разделитель "+" (плюс). Этот символ не используется в именах DNS, а также интуитивно понятнее любых других, указывая на то, что суффикс что-то добавляет к исходной конфигурации хоста. Распознавание добавляемых суффиксов следует производить с помощью команды Match originalhost с шаблоном суффикса.

В случае, если суффикс должен добавлять параметры, специфичные для определённого хоста, например, его реальное имя DNS, или параметры переадресации портов, в которых фигурирует адрес локального сокета, индивидуальный для каждого из хостов, команда Match должна будет содержать два аргумента originalhost: один — с шаблоном имени хоста, и второй — с шаблоном суффикса. Пример:

Match originalhost "tproxy+*" originalhost "*+rtk,*+rtk+*"
# Подключение через РостелеТелеком (NAT)
  Hostname srv-10-79.rtk.company.com

Match originalhost "tproxy+*" originalhost "*+yota,*+yota+*"
# Подключение через Yota
  ProxyJump gate-10-1+yota

Match originalhost "tproxy+*" originalhost "*+fwd,*+fwd+*"
  DynamicForward 127.10.0.79:1080
  LocalForward 127.10.0.79:4445 127.0.0.1:445
  LocalForward 127.10.0.79:8080 127.0.0.1:8080

За секциями, специфичными для хоста с указанием суффиксов, в обязательном порядке должна следовать секция для этого же хоста с параметрами по умолчанию. Прежде всего эта секция нужна для того, чтобы заменить переданное ssh имя хоста его именем DNS, если добавленные к имени хоста суффиксы не ссылались на секцию Match, содержащую команду Hostname. Также в этой секции следует указывать параметры ssh, одинаковые для всех возможных способов подключения, например: имя пользователя, номер порта, используемые алгоритмы шифрования, типы ключей, и так далее. Для секции Match хоста по умолчанию достаточно одного аргумента originalhost. Пример:

Match originalhost "tproxy,tproxy+*"
  Hostname srv-10-79.dmz.company.com
  User srv_user
  Port 36602

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

Match originalhost "*+rsa,*+rsa+*"
  HostKeyAlgorithms +ssh-rsa
  PubkeyAcceptedKeyTypes +ssh-rsa

Linux, Docker, Kubernetes и мониторинг: 10 открытых уроков для системных администраторов

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

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

Если хотите закрыть базу по Linux и автоматизации

• 18 июня, 20:00. «Основы Bash: пишем простые скрипты для автоматизации в Linux».
  _{Для тех, кто хочет перестать делать рутинные операции руками и начать автоматизировать админские задачи через простые, понятные Bash‑скрипты.}

• 4 июня, 20:00. «Продвинутый Bash».
  _{Следующий шаг после базовых скриптов: больше контроля, аккуратнее работа с окружением, меньше хрупких одноразовых команд.}

• 22 июня, 20:00. «Память в Linux. Cache, swap, dirty pages».
  _{Практичная тема для тех, кто сталкивался с ситуацией «память вроде есть, но сервер ведёт себя странно».}

Для всех, кто хочет подтянуть основы Linux, рекомендуем подготовительный курс (сейчас всего за символические 10 руб)

Если работаете с контейнерами и Kubernetes

• 2 июня, 20:00. «Введение в Docker: контейнеризация приложений в Linux».
  _{Базовый вход в контейнеризацию: что происходит с приложением внутри контейнера, зачем нужен Docker и как он встраивается в повседневную инфраструктурную практику.}

• 28 мая, 20:00. «Безопасность K8s: основные концепции и частые проблемы».
  _{На уроке разберем базовые концепции безопасности K8s и ошибки, которые регулярно всплывают в реальных кластерах.}

• 18 июня, 20:00. «Kubernetes под прицелом: почему ваш кластер может взломать даже стажер и как этого избежать».
  _{Более прикладной взгляд на безопасность Kubernetes: где кластеры обычно оставляют открытыми, какие настройки создают риск и что стоит проверить в первую очередь.}

Если отвечаете за стабильность систем

• 1 июня, 20:00. «Мониторинг распределенных систем».
  _{На уроке поговорим о подходах к наблюдаемости распределённых систем и о том, как быстрее понимать, где именно началась деградация.}

• 16 июня, 20:00. «Инцидент‑менеджмент в SRE. Как быстро находить, устранять и предотвращать сбои в системе».
  _{Для тех, кто хочет перейти от тушения пожаров к управляемому процессу: как реагировать на инциденты, разбирать причины и снижать вероятность повторения сбоев.}

• 3 июня, 20:00. «Internal Developer Platform: self‑service‑инфраструктура за один вечер».
  _{Как организовать инфраструктуру так, чтобы разработчики могли получать нужные ресурсы быстрее, а инфраструктурная команда не превращалась в ручной сервис‑деск.}

Если зона ответственности включает защиту инфраструктуры

• 16 июня, 20:00. «IDS/IPS как часть эшелонированной защиты инфраструктуры».
  _{На уроке разберем, как такие системы вписываются в инфраструктурную безопасность и где от них действительно есть польза.}

Больше открытых уроков по ИТ-инфраструктуре, разработке и не только смотрите в календаре открытых уроков OTUS.

Artemis или Kafka? Как перестать выбирать и начать использовать

Архитекторы и ИТ-директора стоят перед сложным выбором: «сверхбыстрый» ActiveMQ Artemis для транзакционных сценариев с низкими задержками или горизонтально-масштабируемая Apache Kafka для потоковой аналитики и долгосрочного хранения событий. Это была ложная дилемма.

На вебинаре 22 мая в 14:00 (мск) разберем, почему Artemis и Kafka – не конкуренты, а идеальные партнеры, и покажем, как платформа Digital Q. Integration решает задачу маршрутизации «одним окном».

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

Программа вебинара:

14:00 – 14:05 Ложная дилемма выбора: почему Artemis и Kafka – не конкуренты, а партнеры

14:05 – 14:15 Две философии: почта vs лента событий. Как понять, какой инструмент под вашу задачу

14:15 – 14:25 Живые сценарии. Где критична скорость, а где – история данных

14:25 – 14:40 Решение: маршрутизация через Digital Q.Integration. Как один параметр brokerType заменяет две инфраструктуры

14:40 – 14:45 Чек-лист для принятия решения при выборе интеграционной платформы

14:45 – 15:00 Вопросы и ответы

Вебинар будет интересен:

• техническим директорам, СТО, архитекторам;

• руководителям разработки, тим-лидам, владельцам цифровых продуктов;

• тем, кто проектирует и поддерживает асинхронные системы обмена данными.   ·       

 Зарегистрироваться на мероприятие

Как отключить звуковое уведомление для SMS которые рассылает RSCHS (МЧС)

Я не знаю как отписаться от рассылки SMS которые шлёт RSCHS.

RSCHS давно шлёт мне уведомления о разнообразных стихийных бедствиях, хотя я не просил его об этом, и не давал согласия включать меня в эту рассылку. Раньше я эту рассылку терпел, потому что она не была такой частой и назойливой. Но в последнее время RSCHS, душка такая, решил, что совершенно необходимо в два часа ночи сообщить мне о беспилотной опасности. Причём на каждую из моих SIM карт. А звук на входящие SMS у меня громкий. Беспилотники летают почти каждую ночь. Отключать смартфоны на ночь я не хочу. И вот здесь моё терпение лопнуло, и я стал искать способ решить эту проблему. Если у Вас на смартфоне нет возможности занести RSCHS в спам-лист, то есть другой способ.

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

Для Android. На смартфоне открываем сообщения от RSCHS, выбираем любое, тапаем по нему коротко, открывается окно Message details, или нажать длинно на сообщении - View details. В открывшемся окне в поле Service Center номер +7 921 6000088. Возможно для Вашего сотового оператора и региона номер будет другим. Создаём новый контакт «RSCHS Service Center», в поле mobile number указываем +7 921 6000088. Сохраняем этот новый контакт. Назначаем для этого контакта звук тишины - Set ringtone выбрать рингтон None.

Если на смартфоне по какой-то причине нет рингтона None. Надо создать файл mp3 содержащий тишину. Можно засунуть смартфон микрофоном под подушку и запустить на нём стандартное приложение Sound Recorder. Я использовал звуковой редактор - Audacity. Он умеет Generate Silence. На выходе получился файл silence.mp3 размером один килобайт, содержащий тишину длительностью три секунды. Копируем его на смартфон, в папку со звуками, назначаем для контакта RSCHS.

Теперь SMS от RSCHS будут продолжать поступать на Ваш смартфон, но уже молча.

Согласно проекту Zero Day ClockLive, с 2018 года значительно сократилось время от выявления уязвимостей в ПО до начала их активной эксплуатации в продуктивных системах (дельта между публичным раскрытием CVE и первым подтверждённым случаем эксплуатации в реальных условиях).

Нужна ли кувалда, чтоб вынуть один кривой гвоздь?

Иногда служба каталога не падает. Не горит. Не уходит в отказ. Всё формально работает.

Просто у 10 000 пользователей внезапно изменился не тот атрибут. Или пропало членство в группе. Или после массового скрипта часть прав доступа поехала в сторону, куда никто не планировал.

И вот тут резервная копия превращается из «спасительного круга» в довольно грубый инструмент.

Полный откат – не всегда ответ

С резервными копиями всё понятно: они нужны. Без них инфраструктура живёт на честном слове и удаче администратора.

Но у каталога есть неприятная особенность. Ошибка часто бывает не катастрофической, а логической.

Не «всё умерло», а:

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

Сервис при этом может продолжать отвечать. Пользователи могут даже какое-то время работать. Мониторинг не обязательно сразу закричит.

А потом выясняется, что доступы уже разъехались, часть приложений видит некорректные данные, а исправлять это руками – отдельный вид админской археологии.

Почему полное восстановление неудобно

Классический сценарий восстановления из резервной копии часто мыслится как «поднять состояние на момент снимка».

Для аварии это нормально.

Для точечной ошибки – не всегда.

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

Получается выбор без хорошего варианта:

1️⃣ откатить больше, чем нужно;

2️⃣ написать скрипт и надеяться, что он не добавит новых сюрпризов;

3️⃣ вручную разбирать, что именно поменялось.

Третий вариант обычно рассматривается годным только до тех пор, пока объектов не сотни и не тысячи.

Что хочется иметь на практике

В идеальном мире администратор должен видеть не просто «у нас есть резервная копия».

А что именно изменилось между текущим состоянием каталога и снимком:

– какие объекты удалены;
– какие изменены;
– какие перемещены;
– какие атрибуты отличаются;
– какие членства нужно вернуть;
– что будет затронуто перед восстановлением.

И уже после этого восстанавливать не всю базу целиком, а только нужную часть: объект, группу, членство, атрибут, параметр политики.

Это не отменяет резервное копирование. Это добавляет к нему более тонкий инструмент.

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

Где здесь РЕД АДМ 2.1 и Granulex Recovery

В РЕД АДМ 2.1 появилась интеграция с Granulex Recovery – подсистемой для резервного копирования, сравнения состояния каталога и точечного восстановления LDAP-объектов и их атрибутов.

Смысл не в том, чтобы «ещё раз сделать бэкап». Смысл в другом: дать администратору возможность сначала увидеть разницу, а потом вернуть только нужные данные без полного отката каталога и без остановки службы.

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

Потому что «всё назад» – это не всегда восстановление. Иногда это вторая авария, просто более организованная.

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

Тысячи сайтов на cPanel скомпрометированы через одну уязвимость — и атакующие работали незаметно шесть лет до этого всплеска.

По данным SecurityLab, за недавней волной взломов стоит не случайный скрипт-кидди, а организованная группа с многолетним опытом. Шесть лет — это не оговорка. Столько времени они оставались в тени, прежде чем атаки стали заметны.

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

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

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

Для владельцев хостинг-инфраструктуры и тех, кто держит сайты на shared-хостинге с cPanel, вопрос сейчас не «взломают ли», а «не взломали ли уже». Следы присутствия профессиональной группы могут быть нечитаемы стандартными средствами мониторинга.

• Проверить версию cPanel и наличие последних обновлений безопасности

• Поднять логи аутентификации за последние недели — аномальные входы без учётных данных

• Проверить целостность файлов на сервере (особенно конфиги и веб-шеллы)

• Если хостинг управляемый — запросить у провайдера подтверждение патча

Атаки через панели управления хостингом — это удар сразу по всем сайтам на сервере, а не по одному. Один уязвимый сервер cPanel — это потенциально десятки и сотни скомпрометированных проектов одновременно. Масштаб инцидента определяется не числом серверов, а числом сайтов на них.

Пока нет публичного CVE и технического разбора, сложно говорить о полной картине. Но шесть лет незаметной работы — это уже достаточный аргумент, чтобы не откладывать проверку на потом.

TG @CIOlogia

Напрямую или через бот-платформу: как лучше интегрировать чат-боты

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

1. Прямая интеграция с каналом 

➕  Полный контроль над функциональностью — например, в случае VK можно обрабатывать не только запросы в личных сообщениях, но и комментарии под постами, на стене, под фото.
➖  Разные API, авторизации, ограничения и нюансы. Требуется закладывать время на поддержку каждого канала.

2. Интеграция через Botmother

➕  Визуальный конструктор — менять сценарии могут не-разработчики. Один сценарий обработки обращений достаточно просто раскатать на разные каналы.
➖  Меньше гибкости в тонкой настройке маршрутизации и аналитики по сравнению с другими платформами.

3. Интеграция через Fasttrack

➕  Расширенные шаблоны ответов, точная маршрутизация по командам, продвинутая аналитика.
➖  Сложнее в настройке сценариев в отличие от того же Botmother.

Что же в итоге? Можно остановиться на способе 2-в-1. Для отдельных сценариев — прямая интеграция, в других случаях — через бот-платформу. Так сделано у одного крупного клиента ITSM 365.

Подробнее про кейс, нюансы в поддержке интеграций и практические шаги по внедрению — в полной версии статьи на Хабре.