Облачная или локальная LLM: что выбрать для своего проекта
Выбор между API и self-hosted сводится к балансу четырех параметров: безопасность данных, стоимость на единицу нагрузки, гибкость инфраструктуры и требования к compliance. Для MVP и нерегулярной нагрузки облачный API почти всегда дешевле, для миллионов токенов в день и сценариев с 152-ФЗ или GDPR картина обратная.
В статье разобрали, как устроены оба подхода, и собрали сравнение по ключевым параметрам — от запуска и масштабирования до работы с AI-агентами и длинным контекстом. Показали требования к VRAM для self-hosted (от 8–12 ГБ для 7–8B в квантизации до 48–80+ ГБ для 70B), разобрали гибридные архитектуры с маршрутизацией запросов между локальной и облачной моделью и риски vendor lock-in при работе через API.
Есть у нас один заказчик. Весь в Windows. Решил переезжать на российское. На бумаге всё выглядит понятно: выбирает дистрибутив, разворачивает сервисы, переносит приложения, постепенно уходит от прежнего стека. Упирается в версию Samba, которой в родных репах нет. Пакет конфликтует с системными библиотеками. Yum (dnf) не может разрешить зависимости и ломается. Решили просто: подключили репы CentOS, перетерли половину системных пакетов. На тесте взлетело. В продакшен – уже риск.
Вопрос, который сразу возникнет: «А почему просто не собрать Samba из исходников?»
Для тестовой лабы – ок. Для прода с сотнями пользователей – нет. И вот почему.
Почему это проблема, а не просто настройка
Когда для домена (Samba, Kerberos, DNS) вы собираете из исходников илилезете в чужие репозитории – вы теряете три вещи:
Поддержку вендора В договоре чёрным по белому: только штатные репозитории. Подменили пакет или поставили самосбор – тикет закроют фразой «сами собрали, сами и поддерживайте».
Безопасные обновления Выходит апдейт от вендора. При левых репах – dnf update падает с конфликтом зависимостей. При самосборе – вы вообще не получите апдейт, чинить каждую CVE придётся руками.
Сертификацию (ФСТЭК/Минцифра) И левый репозиторий, и самосбор аннулируют сертификат моментально. На проверке это увидят.
Важное уточнение для тех, кто вспомнит EPEL EPEL подключают к RHEL для установки дополнительного софта, которого нет в базе. Он не трогает системные пакеты. В нашем кейсе – родной репозиторий ОС не содержал нужной версии критического пакета (Samba). Пришлось лезть в чужой репозиторий и заменять базовые пакеты. Это совсем другая история.
Коротко про вендора
Вендор скажет ровно одно: «Ваша система — не наша сборка. Приходите, когда переустановите без левых реп и самосборов».
Никто не приедет, не поправит, не подстрахует. Вы один на один с костылём.
Вывод
Столкнулись с тем, что роль не ставится из родного репозитория?
Плохие решения: подключать левые репозитории и подменять пакеты, собирать из исходников в продуктиве.
Правильные решения: Взять другую российскую ОС, где эта роль работает из коробки. Потребовать от вендора добавить нужные пакеты в свой репозиторий. Отказаться от этой роли/стека, если ОС его не тянет.
Подмена пакетов в продуктиве – не выход, а вход в ад техподдержки.
Учёт ИТ-активов в России: 80% компаний — на троечку
Опросили 100+ компаний из ИТ, промышленности, банков и ритейла, как у них устроено управление ИТ-активами. Картина отрезвляющая:
80% оценивают зрелость своих ITAM-процессов на 1–3 из 5;
42% не используют никаких стандартов;
каждая пятая до сих пор ведёт учёт в Excel;
приоритет №1 — банальное «понять, что у нас вообще есть».
Самые большие потери — не на закупке, а в «серой зоне»: перемещения между офисами, замена сотрудников, списание. Оборудование числится за кем-то, а физически недоступно.
Внутри — срез рынка с цифрами, разбор ключевых проблем, кейсы «Ленты» и ITGLOBAL.COM и тренды на ближайшие годы: TCO, ИИ, облако, compliance.
Вайбкодер создал кота, который живёт прямо на рабочем столе и составляет компанию во время работы. Маленький питомец гуляет по экрану, реагирует на курсор и клавиатуру и просто тусуется поверх любых открытых приложений.
Сервер работает. Инфраструктура — нет: открытые уроки для сисадминов
Системное администрирование давно не заканчивается на моменте «поднять сервер, настроить доступы и посмотреть логи». Сегодня администратору нужно уметь разбираться в контейнерах, Kubernetes, мониторинге, безопасности, инцидентах и автоматизации — иначе инфраструктура быстро превращается в набор ручных костылей.
Собрали открытые уроки, которые будут полезны системным администраторам, DevOps‑инженерам, SRE и тем, кто хочет увереннее работать с production‑инфраструктурой.
Linux и автоматизация: меньше ручной рутины
4 июня, 20:00 — «Продвинутый Bash» Для тех, кто уже пишет shell‑скрипты и хочет использовать Bash увереннее.
22 июня, 20:00 — «Память в Linux. Cache, swap, dirty pages» Практичный урок о том, как Linux работает с памятью, почему «свободная память» не всегда означает то, что кажется, и как читать поведение системы до того, как всё закончится OOM.
22 июня, 20:00 — «Роль и задачи DevOps в современном IT» Для тех, кто хочет разобраться, где заканчивается классическое администрирование и начинается DevOps‑подход.
10 июня, 20:00 — «Мониторинг распределенных систем» Про наблюдаемость сложных систем, где проблема может быть не на одном сервере, а между сервисами, очередями, базами и сетью.
Все уроки бесплатные. На них можно познакомиться с преподавателями‑практиками, посмотреть на формат обучения и задать свои вопросы.
Если интересны не только инфраструктурные темы, в полном июньском дайджесте собраны ещё 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 "\".
В 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 разослал юзерам такое сообщение:
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 и другие корпоративные гиганты строят вокруг ИИ семантические слои: 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.
Типичный сценарий: ИИ-агент обрабатывает заявку на возврат. Без семантического ядра он видит запись в таблице. С семантическим ядром он знает:
Заявка связана с заказом, который уже частично оплачен.
Товар числится на складе, но фактически уже отгружен другому клиенту.
Клиент имеет статус VIP, что меняет правила возврата.
Есть открытый тикет в поддержке с похожей проблемой.
Агент не просто достаёт данные из разных систем. Он понимает контекст, проверяет правила и предлагает решение, учитывая бизнес-логику.
Ограничения и подводные камни
Построение семантического ядра — дорого и медленно. Нужно формализовать бизнес-процессы, навести порядок в терминологии, связать разрозненные системы. По данным Gartner, большинство проектов знаний графов застревают на этапе пилота.
Второй риск — vendor lock-in. SAP, Oracle и Palantir строят закрытые платформы. Переход на другую систему означает переписывание онтологий и правил с нуля.
Третье — актуальность. Бизнес меняется быстрее, чем обновляется онтология. Если семантический слой не синхронизирован с реальностью, ИИ-агент будет принимать решения на основе устаревших правил.
Что это меняет
Семантическое ядро превращает корпоративный ИИ из набора умных функций в систему, способную действовать автономно в рамках бизнес-правил. Агент не просто отвечает на вопросы — он выполняет задачи, проверяя контекст и соблюдая ограничения.
Это не революция, а эволюция корпоративных систем. Те, кто инвестировал в порядок данных и формализацию процессов, получают преимущество. Остальные застрянут на этапе экспериментов с чат-ботами.
Как я связал 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.
Ограничения остаются: непредсказуемость поведения агентов, сложность отладки, отсутствие зрелых инструментов мониторинга. Стандарты только формируются, и сейчас это больше про обмен опытом, чем про готовые решения из коробки.
Открытый проект 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‑практиками и безопасностью. На них можно познакомиться с преподавателями курсов, протестировать формат обучения и задать вопросы экспертам.
4 июня, 20:00. «Продвинутый Bash». Следующий шаг после базовых скриптов: больше контроля, аккуратнее работа с окружением, меньше хрупких одноразовых команд.
Для всех, кто хочет подтянуть основы Linux, рекомендуем подготовительный курс(сейчас всего за символические 10 руб)
Если работаете с контейнерами и Kubernetes
2 июня, 20:00. «Введение в Docker: контейнеризация приложений в Linux». Базовый вход в контейнеризацию: что происходит с приложением внутри контейнера, зачем нужен Docker и как он встраивается в повседневную инфраструктурную практику.
1 июня, 20:00. «Мониторинг распределенных систем». На уроке поговорим о подходах к наблюдаемости распределённых систем и о том, как быстрее понимать, где именно началась деградация.
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 Чек-лист для принятия решения при выборе интеграционной платформы
Как отключить звуковое уведомление для 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 будут продолжать поступать на Ваш смартфон, но уже молча.
