Linux *

AI-агент для управления VPS через Telegram

В прошлой статье я показал идею: AI-агент на VPS, который позволяет управлять сервером через Telegram и практически забыть про SSH.

Главный вопрос в комментариях был один: «Как это повторить у себя?»

В этой статье — полный разбор и готовый open-source комплект, который можно развернуть за ~10 минут:

docker-compose конфигурация

набор bash-скриптов для управления сервером

конфиги агента

deploy-скрипт

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

Технология eBPF — интересная штука. С её помощью можно без труда внедрять в ядро Linux фрагменты кода, которые затем компилируются в коды операций (опкоды), которые гарантированно не обрушат работу ядра. Набор допустимых инструкций ограничен, переходы назад не допускаются (поэтому не будет никаких неопределённых циклов). При этом вы не можете разыменовывать указатели, но вместо этого можете выполнять проверяемые операции считывания через указатели, которые потенциально могут оказаться неудачными, но при этом не спровоцируют паник на всю систему. eBPF в ядре Linux можно закреплять в тысячах хуков (точек перехвата), в качестве которых могут выступать u-пробы, k-пробы, точки трассировки и даже такие штуки как отказы страниц. У eBPF есть целый спектр захватывающих возможностей, которые при этом очень активно разрабатываются. Фичи, поддерживаемые в каждой конкретной версии ядра, перечислены в виде списка по этому адресу.

Недавно Apple подтвердила стратегическое партнерство с Google для интеграции ИИ Gemini в свои устройства.  Сегодня мы их опередим и поднимем свою LLM в Android-смартфоне. С блэкджеком и WebUI.

eBPF давно стал стандартным инструментом для работы с ядром, но на практике быстро выясняется: одна и та же программа может вести себя по-разному на соседних версиях Linux. Причина — в деталях, которые обычно остаются «под капотом»: структурах ядра, их смещениях и способе доступа к данным. В статье разбираемся, откуда берётся эта нестабильность, как работают механизмы вроде CO-RE и BTF и что на самом деле нужно учитывать, чтобы eBPF-код был переносимым и предсказуемым в разных окружениях.

Я посадил AI-агента на свой VPS и перестал открывать SSH. На сервере крутится дюжина Docker-контейнеров — клиентские проекты, SaaS, мониторинг, базы. Раньше любая мелочь требовала SSH: глянуть логи, рестартнуть контейнер, проверить место на диске.

Теперь я пишу в Telegram «память за 90%, разберись» — и через минуту получаю ответ: что случилось, что починил, сколько памяти сейчас.

В статье — реальные сценарии: SQL-запросы к PostgreSQL из Telegram, автодиагностика упавших сайтов, правка конфигов, мониторинг с авторестартом и управление задачами в YouTrack. Всё через кастомные shell-скрипты и AI-агент OpenClaw.

Привет, Хабр! Расскажу, как мы спасли крупный новостной сайт ugra-news.ru от постоянных падений — без покупки нового железа и переписывания с нуля. Только точечные оптимизации, знание архитектуры Битрикс и немного детективной работы. Приступим.

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

Отзывов на профиле нифига, решил от скуки написать автору. На первый взгляд всё оказалось прозрачно. Он расписал пример того, как устроен один из блоков. Подумал немного и получил заветный PDF-файлик.

Представьте себе классический кошмар системного администратора или SRE: три часа ночи, в управлении огромный кластер Greenplum на сотню сегмент-хостов, и вам нужно запустить тяжелый ETL-процесс или проверить доступность gpfdist строго одновременно на всех узлах.

Вы начинаете перебирать инструменты. Стандартный Cron? Он локальный, замучаешься синхронизировать конфиги. Ansible или SaltStack? Хороши, но требуют центрального «мастера» и стабильного SSH-соединения в момент старта. А если в дата-центре «моргнула» сеть и часть сегментов оказалась изолирована? Команда просто не дойдет.

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

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

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

Когда ваше приложение состоит из нескольких сервисов, например бэкенда, БД и кэша, невольно возникает вопрос — а как гарантировать, что они запустятся в правильно порядке и вообще увидят друг друга? В Docker это решается с помощью depends_on, тут ничего нового. А вот в Podman подход немного другой. Ну кто бы сомневался!

Привет! Меня зовут Данил, я разрабатываю прикладное ПО для радиочастотных систем YADRO. В этой статье я расскажу об одном из вариантов сбора данных AXI-Stream для обработки на CPU, рассмотрю в этом контексте возможности и требования блока AXI DMA, а напоследок порассуждаю о когерентности кешей и о том, что на самом деле здесь требуется от драйвера ядра.

В последнее время мне захотелось вернуться к проекту игровой консоли. Правда, он забуксовал, но ничего страшного: это долгоиграющий проект, и буду его разбирать по чуть-чуть. А вернулся к нему всё потому, что захотелось программировать. Потом я стал размышлять, что необязательно делать свою консоль — можно достать готовую. И везде я слышал упоминания про ретро-консоли, а у меня такой не было! Выбрал для себя Anbernic RG35XX Pro и заказал.

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

Всё будет рассмотрено на примере PortMaster и написания Hello World на C/C++ (SDL2, SDL3, raylib), но также поговорим про Unity, Godot и HTML5 (Phaser).

«Где мои логи — в /var/log/messages, /var/log/syslog или только в journalctl?» — этот вопрос рано или поздно задает себе каждый инженер, который вынужден переключаться между разными дистрибутивами: Ubuntu, CentOS, Alpine, корпоративные Unix системы. 

Типичный сценарий: вы заходите на сервер, ищете /var/log/messages, а его или нет, или он есть, но journalctl показывает гораздо больше событий, чем файл. 

Иногда сервер внезапно начинает сильно использовать CPU, и в итоге причиной оказывается агрессивное логирование. 

Если к этому добавить разнородный парк, где рядом с Ubuntu живут динозавры на AIX и Solaris, путаница приобретает глобальный характер. 

Сейчас мы живем в эпоху «двоевластия»: systemd‑journald уже стал стандартом де‑факто, но rsyslog все еще присутствует во многих дистрибутивах по инерции или ради совместимости. Эта статья для инженеров, которые хотят понимать, кто именно пишет логи в Linux, почему они дублируются, где теряются CPU и I/O, и как настроить логирование так, чтобы диск не превращался в помойку. 

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

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

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

Почему поиск виноватых не работает

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

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

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

Набрав в поиске "VDS в Германии аренда" я с удивлением обнаружил, что арендовать такой сервер можно с российской карты и за вполне вменяемые деньги. Арендовав сервер на неделю, я принялся поднимать собственный MTProto для телеги. Использовал я образ https://github.com/telemt/telemt

Я поднял свой контейнер с прокси, проверил, что все работает и обрадовался. Но сразу же встал следующий вопрос - CLI это хорошо, но хотелось бы какой-то GUI для управления прокси. Я перепробовал несколько панелей и остановился на https://github.com/MaksimTMB/mtg-adminpanel. её суть в том, что панель можно установить на любой сервер или вообще локально, а на сервер, где будет развернут прокси ставится агент, который будет выполнять команды панели. Такое решение мне понравилось, так как в будущем можно будет расширить сеть до нескольких узлов, во избежание тотальной блокировки.

Использовали Cloud DNS, всё работало штатно.

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

На практике это привело сразу к двум проблемам:

В сети достаточно информации о настройке аутентификации 1С при публикации базы на веб‑сервере.

Наиболее полная из найденных расположена по адресу https://infostart.ru/1c/articles/2440678

Информация в комментариях к статье достойна ознакомления.

Однако для сценария когда:

Введение: Наткнулся на Reddit на крик о помощи: пользователь описывал странную схему «обучения трейдингу»,

Когда мы запускаем контейнер, в большинстве случаев предварительно нужно указать настройки: порт, пароль, режим работы, адрес базы и т. д. Зачастую такие параметры жестко прописывают в самом коде, но это плохой стиль и вообще идея так себе. В будущем вы можете «затроить» и все это слить в git-репозиторий. А как мы знаем, хранить чувствительные данные в там нельзя.

Удобнее и гибче использовать переменные окружения. Те самые, которые environment variables. С помощью переменных можно настраивать поведение контейнера, использовать разные конфигурации (dev/stage/prod), безопасно передавать чувствительные данные. Как видите, одни плюсы.

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

Stratum 1 NTP-сервер на Raspberry Pi в 2025 году: DCF77 + GPS/PPS, chrony, libgpiod v2, когда все туториалы по «точному времени на Raspberry Pi» сломаны на современных системах. Разбираю почему — и показываю как сделать правильно.