🎮 Редко что-то пишу на тему игр. Раньше в выходные регулярно поднимал эту тему, пока игры не кончились. Кому интересны игры на IT тематику, может посмотреть по тегу #игра, или сразу перейти к подборкам, которые я делал в разное время. К каждой игре есть мой обзор:

▪️Игры Zachtronics
▪️Хакерская тематика
▪️Обучающие игры
▪️Консольные игры
▪️Общая подборка всех игр с канала

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

⇨ ServiceIT: You can do IT
⇨ SysAdmin Odyssey - Back to the office

В обоих играх, если что, есть русский язык. А последняя разработана русскоязычным программистом.

Из этой серии есть ещё одна игра - IT Specialist Simulator (Симулятор ИТ-специалиста 😎). Очень впечатлил один из комментариев к игре:

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

Ну и ещё парочка:

Довольно реалистичный симулятор работы техподдержки. Сразу скажу, что он не для всех, так как пытается научить вас выполнять реальные задачи. Названия операционных систем и компаний придуманы, чтобы избежать проблем с авторскими правами. Задачи довольно приземлённые. Вы вручную настраиваете BIOS, меняете параметры сетевых карт, настраиваете роутеры, решаете проблемы с компьютером. Это не совсем то же самое, что в реальной жизни, но очень похоже.

Как системный администратор, я испытываю ту же ярость и любопытство, что и на своей основной работе. 10/10, с нетерпением жду следующих обновлений!

Думаю, идею вы поняли. Кому мало задач на работе или скучает по временам, когда он работал с пользователями, можно развлечься 🤠.

Как относитесь к таким играм? Хочется поиграть?

У меня один из сыновей начал играть в танки, и я немного с ним. У меня аккаунту лет 15, где последние 10 лет не играл вообще. Зашёл, погонял немного. Интересно и затягивает. Игра обросла всякими режимами, рейтингами, достижениями. Прям чувствую, как она пытается затянуть и не отпустить. И письма шлёт, и бонусы, только возвращайся. Меня спасает, что некогда играть, а сына - мой контроль.

🎮 Steam / ▶️ Видео

#игра

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

У меня в виртуалках и контейнерах Proxmox чаще всего IP адреса назначаются автоматически через DHCP. Иногда хочется быстро посмотреть IP адрес контейнера или виртуалки через веб интерфейс, особенно если он по какой-то причине изменился или не был жёстко привязан по MAC или Machine-ID.

Для VM это чаще всего решается быстро, так как я всегда устанавливаю QEMU Guest Agent. С его помощью IP адрес выводится на основную вкладку Summary виртуальной машины. А вот с контейнерами это так не работает. Приходится либо в него заходить через консоль, либо смотреть на DHCP сервере.

Этот вопрос можно решить с помощью файла /etc/issue. Вообще не знал до сего дня для чего он существует и какие открывает возможности. Добавляем туда в LXC контейнере:

eth0: \4{eth0}

Чаще всего сетевой интерфейс контейнера имеет имя eth0. Теперь открыв консоль контейнера через веб интерфейсе Proxmox, вы увидите его текущий IP адрес:

Debian GNU/Linux 12 Debian12-ct tty1
eth0: 192.168.137.29
Debian12-ct login:

Очень просто и удобно. Файл /etc/issue в Linux - это шаблон приветственного сообщения (pre-login banner), который выводится до появления приглашения login: на локальной консоли (tty). Важно понимать, что подключения по SSH не используют /etc/issue. Это шаблон только для локальных консолей.

Для виртуалок это тоже можно использовать, но там есть проблема. Сетевые интерфейсы могут называться сильно по-разному: ens18, enp0s18 и т.д. Если вы принудительно не приводили их к старому наименованию в виде ethX, то придётся для каждого случая прописывать имя сетевого интерфейса.

ИИ написал, что можно указать конструкцию вида \4{all} для вывода всех IP адресов, но в Debian 13 это не работает. Не знаю, откуда он это взял. Я воспользовался старорежимным дедовским методом и прочитал man:

# man agetty

If the interface argument is not specified, then select the first fully configured (UP, non-LOCALBACK, RUNNING) interface. If no configured interface is found, fall back to the IP address of the machine’s hostname.

То есть указываем просто \4 или для красоты IP: \4 и получаем приветствие с IP адресом, который будет взят с первого активного сетевого интерфейса, но не lo. В принципе, этот вариант можно использовать как универсальный и для VM, и для контейнеров.

Очень удобная весчь. Мне понравилось. Реально не хватало в повседневной работе.

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

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

#linux

Вчера обновил один из своих тестовых серверов Proxmox версии 8.4 до недавно вышедшей 9.1. Ничего не выдумывал, сделал всё строго по официальной инструкции. Всё совпало до каждого пункта и предупреждения. Причём даже с установленным на этом же хосте PBS прямо на железо вместе с PVE. Никаких конфликтов и проблем не возникло.

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

А вот в 9.1 как минимум появилась возможность запускать напрямую Docker контейнеры, что хоть и не решает каких-то глобальных проблем, но выглядит интересно. Плюс, у контейнеров в веб интерфейсе виден настроенный IP адрес, чего не хватало. Люди городили костыли для этого, теперь они не нужны.

Попробовал я запуск Docker контейнеров и могу сказать, что пока это всё игрушки и не очень удобно. Работает это так:

1️⃣ В локальное хранилище предварительно загружается Docker контейнер. В том же разделе, где загружаются образы LXC.
2️⃣ Создаётся новый контейнер, где в качестве образа выбирается скачанный ранее контейнер. Настройки все те же, что и в случае с LXC. По факту вы LXC и создаёте, где автоматически запустится контейнер докера.
3️⃣ Переменные вынесены в отдельный раздел в Options в настройках контейнера.
4️⃣ Контейнер запускается на выбранном сетевом бридже и использует настроенный в момент создания IP адрес.

На практике всё это выглядит точно так же, как LXC, только запускается контейнер Docker из Docker Hub. Причём одиночный контейнер фиксированной версии. Я так и не понял, как его обновить, кроме как скачать образ новой версии и снова запустить его, подключив тот же диск.

Получилась некая новая сущность, и не LXC, и не Docker, а что-то между ними. Данные контейнера пишутся и хранятся на подключенный raw образ. То есть контейнер нормально бэкапится и переносится. Но при этом в него не зайти, как в LXC, через веб интерфейс. Не выполнить docker ps или docker inspect, как в обычной среде запуска Docker. Контейнеры Docker не связать между собой, как это сделано в Docker Compose.

В таком виде это удобно только для запуска одиночных Docker контейнеров. С ними можно работать, как с LXC или виртуальными машинами - бэкапить, переносить, выделять ресурсы. Думаю, что это только проба пера и функциональность будут наращивать до уровня взаимодействия Docker Compose. А пока для полноценного запуска нескольких контейнеров придётся действовать как и раньше:

Cоздание контейнера LXC ⇨ установка Docker и Docker Compose ⇨ загрузка YML-файла ⇨ запуск контейнеров.

По идее вот эту цепочку должны в итоге реализовать в более аккуратном и удобном виде в следующих релизах.

❓Если уже используете эту функциональность, то что думаете по этому поводу? Как я уже сказал, для одиночного контейнера всё неплохо. А для связки из нескольких контейнеров пока неприменимо. Ну и обновление надо как-то автоматизировать.

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

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

#proxmox #docker

В одном из обновлений Angie ещё в начале этого года был добавлен модуль с ACME клиентом. Я уже как-то писал о нём мельком сразу после выхода. Он обеспечивает автоматическое получение бесплатных сертификатов Let's Encrypt. Я по старинке использую certbot и иногда acme.sh. Старые сервера перенастраивать не стал, особого смысла нет. А вот для новых имеет смысл попробовать.

✅ Плюсы такого подхода следующие:
➕Не нужно поддерживать список доменов в разных местах. Есть конфигурация Angie с настроенными доменами. Для них же и получаем сертификаты.
➕Обновление сертификатов происходит без перезапуска веб сервера. Для небольших веб серверов не очень актуально, а вот если доменов и поддоменов много, то это заметное улучшение процессов.
➕В целом более простая настройка с минимумом лишних компонентов и конфигураций для них.

Все параметры описаны в документации. Я смотрел только туда. Получилось всё с первого раза, но пара вопросов остались. В конце отмечу их. Покажу итоговый пример для двух доменов: mail.zeroxzed.ru и webmail.zeroxzed.ru. Сделал их для статьи по почтовому серверу, которую пока пишу.

Добавляем в раздел http конфигурации Angie:

http {
....
 resolver 62.76.76.62 62.76.62.76;
 acme_client webmail https://acme-v02.api.letsencrypt.org/directory;
 acme_client mail https://acme-v02.api.letsencrypt.org/directory;
....
}

62.76.76.62 и 62.76.62.76 - публичные DNS сервера компании MSK-IX. Можете использовать любые другие.

Создаём 2 файла конфигурации виртуальных хостов в директории /etc/angie/http.d - mail.conf и webmail.conf. Содержание одинаковое, отличается только поддомен и параметр acme:

server {
  listen 443 ssl;
  server_name webmail.zeroxzed.ru;

  root /var/www/webmail;
  index index.php index.html;

  acme webmail;
  ssl_certificate $acme_cert_webmail;
  ssl_certificate_key $acme_cert_key_webmail;

  access_log /var/log/angie/webmail-access.log;
  error_log /var/log/angie/webmail-error.log;

  location / {
    try_files $uri $uri/ /index.php?$args;
  }

  location ~ \.php$ {
    fastcgi_pass  unix:/run/php/php8.4-fpm.sock;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include fastcgi_params;
  }
}

server {
  listen 80;
  server_name webmail.zeroxzed.ru;
  return 301 https://$host$request_uri;
}

Перезапускаем веб сервер и наблюдаем в логах:

2025/11/27 17:24:28 [notice] 154580#154580: creating implicit client block for "@acme"
2025/11/27 17:24:28 [notice] 154580#154580: no certificate, renewal scheduled now, ACME client: webmail
.......................
2025/11/27 17:24:31 [notice] 154582#154582: ACME account ID: "https://acme-v02.api.letsencrypt.org/acme/acct/2832575756", ACME client: webmail
2025/11/27 17:24:47 [notice] 154582#154582: certificate renewed, next renewal date: Mon Jan 26 16:26:15 2026, ACME client: webmail

И так для обоих доменов. В директории /var/lib/angie/acme появились две папки mail и webmail, где расположены соответствующие сертификаты.

Не видел нигде примеров конфигурации с несколькими доменами, поэтому не понял, можно ли как-то всё красиво оформить через переменные в ssl_certificate, но с одним acme_client? Или для каждого отдельного домена надо прописывать своего клиента?

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

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

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

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

#angie