В программировании есть (или теперь про программирование стоит говорить было?) такое понятие, как парное программирование. Причём это не образное выражение, а вполне конкретная деятельность. Про парное администрирование никогда не слышал, но если вдруг надумаете такое устроить, то могу предложить инструмент - TermPair.

Это старая утилита, которую я тестировал ещё в 2021 году. С тех пор её не забросили, периодически обновляют и работает она неплохо. Я лично проверил. Мне понравилось. С помощью TermPair можно настроить совместный доступ к консоли сервера через браузер. Это может быть режим только для просмотра, либо и для равнозначного управления для всех участников.

Отмечу особенности TermPair:

▪️Все передаваемые данные шифруются
▪️Можно поднять свой сервер и все соединения пропускать через него
▪️TermPair состоит из одного бинарника, никаких зависимостей
▪️Очень простая настройка и использование
▪️Утилита кроссплатформенная - Linux, macOS, Windows

Мне видится польза от этого сервиса как минимум в трёх ситуациях, которые пришли в голову:

1️⃣ Сейчас популярны удалённые собеседования при приёме на работу, в том числе и технические части. Можно быстро и легко отправить кандидату консоль от сервера с какими-то задачами, которые ему нужно выполнить. Там можно совместно в режиме беседы взаимодействовать. Мне видится это самым простым и эффективным способом оценить квалификацию человека. Говорить можно много, а вот взять и что-то сделать - совсем другое дело. Можно специально что-то поломать и попросить починить.

2️⃣ Можно наблюдать за работой ии-агента или нескольких через браузер. Можно поделиться с кем-то сессией, чтобы он тоже взаимодействовал.

3️⃣ Если вы проводите обучение, то это удобный способ подключиться к ученику и совместно что-то сделать.

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

Скачиваем и распаковываем бинарник:

# wget https://github.com/cs01/termpair/releases/download/v1.2.0/termpair-x86_64-unknown-linux-gnu.tar.gz
# tar xvf termpair-x86_64-unknown-linux-gnu.tar
# mv termpair /usr/local/bin/

Это нужно сделать и на клиентах, и на сервере, который будет обслуживать соединения. Далее на сервере устанавливаем Nginx и Certbot:

# apt install nginx certbot

Получаем сертификат для домена:

# certbot certonly

Рисуем конфигурацию для TermPair:

upstream termpair_app {
 server localhost:8000;
}

server {
  server_name 345265.simplecloud.ru;
  listen 443 ssl;
  ssl_certificate /etc/letsencrypt/live/345265.simplecloud.ru/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/345265.simplecloud.ru/privkey.pem;

  location /termpair/ {
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header Host $host;
    proxy_pass http://termpair_app/;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
  }
}

Создаём systemd unit для службы TermPair в файле /etc/systemd/system/termpair.service:

[Unit]
Description=TermPair server
After=network.target

[Service]
ExecStart=/usr/local/bin/termpair serve --port 8000
Restart=on-failure
RestartSec=1s

[Install]
WantedBy=multi-user.target

Запускаем службу:

# systemctl daemon-reload
# systemctl enable --now termpair.service

Теперь на сервере, где мы хотим расшарить консоль, запускаем TermPair и указываем через ключ наш сервер:

# termpair share --host "https://345265.simplecloud.ru/termpair/" --port 443

В консоли получаем ссылку для подключения и переходим по ней браузером. Дальше используем по назначению. Доступ будет у всех, кто знает ссылку. Ограничить доступ только чтением можно ключом -r. Через ключ --cmd можно сразу запустить какую-то программу, например, opencode.

❗️Если заметка вам полезна, не забудьте 👍 и забрать в закладки.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩

#linux

В августе у z.ai вышла в свет модель GLM-5.3-Flash. Она разработана специально для программирования, агентных задач и работы с длинным контекстом. Не знаю, за какие заслуги, но эта модель стала доступна в бесплатном режиме в open source агенте OpenCode с ограничением контекста в 200к, что для задач эксплуатации зачастую достаточно. Я её попробовал на небольшой задаче.

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

Ставим на тестовую виртуальную машину opencode:

# curl -fsSL https://opencode.ai/v2/install | bash

Я рекомендую сразу поставить tmux или screen и запустить opencode там. Далее проходим этап первоначальных настроек. Я сейчас не знаю, что там. У меня уже давно всё настроено. На эту тему куча видео в интернете.

Создаём рабочий каталог, например, ansible_base_configure, заходим в него и запускаем opencode в нём. Открываем список моделей и выбираем GLM-5.3-Flash Free.

Дальше в поле ввода выбираем режим Plan и пишем в чат всё, что хотите сделать. Я для примера сходу составил вот такой промпт:

Ты - DevOps инженер, специализирующийся на автоматизации через Ansible и отвечающий за идемпотентность и check-mode при работе с виртуальными машинами Linux.

Задача - подготовить Playbook для контроля базовых настроек виртуальных машин на базе ОС Debian 13 в среде PVE. Используй только проверенные и общепризнанные практики подхода IaC.

В решении опиши структуру каталогов, ключевые модули, переменные по уровням (group_vars, host_vars, defaults) и стратегию тегов. Приведи пример inventory с десятью серверами разного назначения и команду запуска ansible-playbook с нужными флагами. Запиши всё это в README.md.

Что делаем на виртуальных машинах (VM):
- проверяем по списку подключенные репозитории, для каждой VM оставляем возможность указать набор репозиториев, которые должны быть подключены
- проверяем наличие обновлений пакетов и если они есть - устанавливаем
- устанавливаем и настраиваем nftables, закрываем все входящие подключения, разрешаем все исходящие, отдельным списком для каждой VM указываем входящие порты и источники трафика, для которых будут разрешены подключения
- устанавливаем везде типовой набор пакетов - net-tools, mc, iftop, lsof, git, для каждой VM оставляем возможность в отдельном списке указать дополнительные пакеты

В режиме Plan агент скорее всего задаст какие-то дополнительные вопросы. Например, оставляем ли открытым порт для SSH, какой формат репозиториев выбираем, нужно ли перезагружать VM после обновления и т.д. По характеру вопросов вы сами поймёте, чем нужно дополнить промпт. Чем подробнее вы его опишите, тем лучше. Но даже если он будет неполным, по ходу дела вы будете его дополнять.

Когда все вопросы разобраны, выбираете режим Build и говорите агенту, чтобы он реализовывал проект. Дальше он будет много всего делать. Когда закончит, посмотрите глазами, что там получилось и постарайтесь осознать 😁. Для этой задачи контекста в 200к должно хватить.

Далее готовите ему тестовую виртуальную машину и прямо в чат пишите параметры доступа. Говорите ему, что хотите настроить на этой VM, и просите отладить работу плейбука. Поначалу будет куча ошибок. Скорее всего он их все исправит автоматически. Эта задача простая.

На выходе у вас получится готовый рабочий плейбук, уже протестированный, с инструкцией по использованию. У меня это заняло примерно 30 минут на всё про всё, отвлекаясь на другие задачи. Получил рабочий, проверенный плейбук. Обычно после появления первой рабочей версии я добавляю его в git и куда-то загружаю в репу. Теперь этот проект можно скормить другой llm, если она у вас есть, и провести аудит.

Если подключить MCP для PVE, то агент может добавить в инвентарь ваши VM. У себя это проверял. Но контекста больше уходит. На решение задачи может не хватить.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩

#ai #devops #ansible

Я не так давно рассказывал, как периодически возникают проблемы с различными репозиториями для ОС. В связи с этим я все репы настроил на mirror.yandex.ru. С ним на тот момент никаких проблем не было. Плюс, помимо базовых репозиториев ОС, там ещё куча всяких заблокированных реп, типа Grafana, Elastic и т.д. В целом было удобно и стабильно.

Но после всех известных событий стабильности стало меньше. В целом, зеркало работало. Я не перенастраивал на что-то другое. Но заметил, что если разом обновлять пачку серверов (примерно 10-15), то на некоторых можно увидеть ошибки, типа такой:

E: Failed to fetch https://mirror.yandex.ru/debian-security/pool/updates/main/b/bind9/bind9-dnsutils_9.20.30-1%7edeb13u1_amd64.deb 404 Not Found [IP: 213.180.204.183 443]

Повторный запуск проходит успешно. Не знаю, с чем это связано. Может не с одновременным обновлением, а с тем, что на каких-то серверах нет всех пакетов.

У меня нет больших инфраструктур (50+ VM). Плюс, я не обновляю разом прям сразу всё, обычно группами. Мне это некритично, но всё равно эти ошибки напрягают, отвлекая на себя внимание. Да и в целом не очень разумно на каждый сервер качать пакеты, хотя современные скорости интернета позволяют не обращать на это внимание.

Дополнительно возникла ещё одна проблема с обновлением Vector из его репы apt.vector.dev. Там одно время была очень низкая скорость, а теперь вообще без прокси или впн ничего не качает. Зеркало для него на mirror.yandex.ru не нашёл. Свою копию репы поднимать не хочется. Там нужен всего один пакет.

Решил разом все эти вопросы поднятием своего кэширующего прокси для пакетного менеджера. Не стал ничего придумывать, а взял стандартный apt-cacher-ng из базового репозитория Debian. Для стандартных дебиановских реп, к которым обращаются по HTTP, ничего на самом сервере с apt-cacher-ng настраивать не надо. Всё заведётся с дефолтной конфигурацией. А вот с другими репозиториями, типа Docker, Elastic и т.д., которые работают по HTTPS, есть нюансы и различные варианты конфигурации. Я у себя настроил и уже опробовал такую схему.

Сервер с apt-cacher-ng принимает от клиентов все запросы по HTTP и сам их редиректит на HTTPS, скачивает пакеты и отдаёт клиентам. Такая настройка мне показалась самой простой и интуитивно понятной. Покажу на практике, как это реализовано. Ставим apt-cacher-ng:

# apt install apt-cacher-ng

Рисуем ему конфигурацию в /etc/apt-cacher-ng/zzz_local.conf:

Port: 3142
BindAddress: 10.20.1.150
CacheDir: /var/cache/apt-cacher-ng
LogDir: /var/log/apt-cacher-ng

Remap-vector-https: http://apt.vector.dev
Remap-docker-https: http://download.docker.com/linux/debian
Remap-grafana-https: http://mirror.yandex.ru/mirrors/packages.grafana.com/oss/deb/
Remap-elastic-https: http://mirror.yandex.ru/mirrors/elastic/9/

Запускаем:

# systemctl enable --now apt-cacher-ng

Идём к клиентам, прописываем им прокси. Для этого добавляем файл /etc/apt/apt.conf.d/90apt-proxy:

Acquire::http::Proxy "http://10.20.1.150:3142";
Acquire::https::Proxy "DIRECT";

Репозитории, что работают по HTTP, трогать не надо. Они теперь будут обновляться через прокси. А в тех репах, что работают по HTTPS, надо поменять протокол с https на http. Вот пример для docker.list:

deb [arch=amd64 signed-by=/etc/apt/keyrings/docker.asc] http://download.docker.com/linux/debian trixie stable

Собственно, на этом всё. Те репы, где оставили https, работают напрямую. Обновляемся на клиентах и смотрим на сервере с прокси логи и кэш в папках /var/log/apt-cacher-ng и /var/cache/apt-cacher-ng.

С vector я решил вопрос так. Подключил эту репу на сам сервер apt-cacher-ng. Ему настроил доступ к репе через впн. Сначала обновляю пакет на нём, он попадает в кэш. Все остальные сервера берут с него.

Вариантов решения подобных задач много. Я их все решил одним apt-cacher-ng.

p.s. уже после написания заметки узнал, что для vector можно использовать репу apt.datadoghq.com, это CNAME для apt.vector.dev, то есть полная копия, доступная пока без ограничений.

———
ServerAdmin: 📱 Telegram | 🌐 Сайт | 📲 MAX 😩

#linux #apt