Клонирование клиентов из единого образа

Кейс описывает, как корректно развернуть клиент RuDesktop на множестве машин, созданных из общего образа (VDI, шаблон ВМ, golden-image для PXE, контейнер) — так, чтобы каждая клонированная машина получила уникальную идентификацию на сервере и не конфликтовала с другими клонами

Важно

Кейс применим только при работе с локальным сервером RuDesktop. Используемые команды клиента use-random-uuid и reset-state доступны только в локальной версии клиента — в облачной версии они отключены

В чём проблема

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

Если клиент уже зарегистрирован на сервере в момент снятия образа или просто запущен с одинаковым UUID на разных клонах:

  • сервер видит клонов как одно и то же устройство, переписывая запись при каждой регистрации

  • параллельные сессии с разных клонов «смешиваются» под один ID

  • инвентаризация и логи действий «прыгают» между машинами

  • в списке устройств часть клонов вообще не появляется

Как решить

Связка двух команд клиента:

  • use-random-uuid — переключает клиент в режим случайного UUID (отвязывает его от machine_uid)

  • reset-state — обнуляет id, сертификат и мастер-пароль и инициирует перегенерацию UUID

После их выполнения каждый клон получает:

  • уникальный случайный UUID

  • пустой публичный id — будет выдан сервером при первой регистрации

  • свежий сертификат, выпускаемый сервером заново

  • новый мастер-пароль, который клиент тут же отправит на сервер

Подготовка базового образа

Вариант, при котором клиент в образе ещё не зарегистрирован на сервере. Это самый чистый сценарий — на сервере не появляется лишних «фантомных» записей

  1. Установить клиент RuDesktop обычным способом, дождаться завершения установки

  2. Не запускать клиент, либо сразу после первого запуска выполнить:

    rudesktop services stop

  3. Включить режим случайного UUID, чтобы последующая перегенерация UUID сразу выдала случайный, не привязанный к machine_uid:

    rudesktop --use-random-uuid true

  4. Удалить состояние, которое клиент мог сохранить за время установки и тестирования, и перегенерировать UUID в случайный:

    rudesktop --reset-state

  5. Снять образ системы (sysprep на Windows, очистка machine-id на Linux при необходимости — отдельный шаг ОС, не относящийся к RuDesktop)

Подсказка

Если клиент во время подготовки образа всё-таки успел зарегистрироваться на сервере — после снятия образа удалите эту «эталонную» запись на странице Устройства, чтобы её ID не «занимал место»

Применение на клонированной машине

После того как клон загружен и получил уникальные сетевые параметры (имя хоста, MAC, IP), на нём нужно один раз выполнить связку команд:

rudesktop --use-random-uuid true
rudesktop --reset-state

Что произойдёт:

  • --use-random-uuid true сразу выдаст случайный UUID, не зависящий от machine_uid ОС

  • --reset-state обнулит id, сертификат и мастер-пароль, после чего клиент при следующем подключении к серверу пройдёт новую регистрацию и получит собственный id

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

Важно

Порядок важен. Сначала --use-random-uuid true (включает режим), затем --reset-state (использует включённый режим при перегенерации UUID). При обратном порядке --reset-state сгенерирует UUID из machine_uid — то есть тот же самый, что и у других клонов

Важно

Флаги нельзя передать в одной команде (rudesktop --use-random-uuid true --reset-state) — клиент обработает только первый флаг и завершит работу, второй будет проигнорирован. Связка должна выполняться двумя отдельными вызовами rudesktop в указанном порядке

Автоматизация запуска связки

Команды нужно выполнять только один раз — при первой загрузке клона. Удобные способы это автоматизировать:

  • Linux — добавить связку в cloud-init (runcmd), в скрипт rc.local с однократным маркером, или в systemd-юнит типа oneshot с условием существования файла-флага

  • Windows — выполнить связку из setupcomplete.cmd после sysprep или из задания планировщика, отключающего себя после выполнения

  • VDI — встроить связку в скрипт первой загрузки сессии (например, в шаблоне Citrix/VMware Horizon)

  • Контейнеры — выполнить связку в ENTRYPOINT перед запуском основной службы клиента

Также для разовой ручной раскатки на уже стоящих клонах годится политика Выполнить команду — её можно запустить на группе устройств, но только если клиенты до этого уже корректно зарегистрировались на сервере под разными id (иначе политика не сможет их различить)

Проверка

  1. Запустить на каждой клонированной машине:

    rudesktop --get-uuid

    Полученные значения должны отличаться между всеми клонами

  2. Открыть в веб-интерфейсе сервера страницу Устройства и убедиться, что:

    • каждая клонированная машина присутствует отдельной записью

    • id всех записей различаются

    • в свойствах устройства поле UUID уникально для каждой записи

  3. Подключиться к одному из клонов по ID — сессия должна установиться именно к нему, без «прыжка» на другую машину

Примечание

Если на сервере всё равно остаются дубликаты, проверьте:

  1. что --use-random-uuid true отработал ДО --reset-state;

  2. что в исходном образе клиент не успел зарегистрироваться под общим id (если успел — удалите эталонную запись на сервере и повторите связку на клонах)

См. также

Если в инфраструктуре имена хостов уникальны (например, доменные устройства), альтернативой может быть назначение устройствам hostname в качестве идентификатора — см. кейс Использование hostname в качестве ID устройства