Канонический livepatch не удалось, когда я попытался включить токен

Я пытался использовать канонический livepatch, но не смог. У меня 3 VPS. На первом я добавил свой токен месяц назад. Теперь я хотел добавить тот же токен к двум другим своим VPS, но не смог.

1 VPS (вырезать мой токен для этого форума)

root@lowend:~# canonical-livepatch enable 685369f7a895434*************************
2020/08/06 10:01:43 error executing enable: cannot enable machine: bad temporary server status 500 (URL: https://livepatch.canonical.com/api/machine-tokens) server response: machine token already exists
root@lowend:~# systemctl status snap.canonical-livepatch.canonical-livepatchd.service
● snap.canonical-livepatch.canonical-livepatchd.service - Service for snap application canonical-livepatch.canonical-livepatchd
   Loaded: loaded (/etc/systemd/system/snap.canonical-livepatch.canonical-livepatchd.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2020-08-06 09:49:47 CEST; 12min ago
 Main PID: 564 (canonical-livep)
    Tasks: 8 (limit: 2365)
   CGroup: /system.slice/snap.canonical-livepatch.canonical-livepatchd.service
           └─564 /snap/canonical-livepatch/95/canonical-livepatchd

Aug 06 09:53:25 lowend canonical-livepatch[564]: bad temporary server status 500 (URL: https://livepatch.canonical.com/api/machine-tokens) server response: m
Aug 06 09:53:25 lowend canonical-livepatch[564]: Retrying request in 304 seconds.
Aug 06 09:55:18 lowend canonical-livepatch[564]: bad temporary server status 500 (URL: https://livepatch.canonical.com/api/machine-tokens) server response: m
Aug 06 09:55:18 lowend canonical-livepatch[564]: Retrying request in 14 seconds.
Aug 06 09:55:32 lowend canonical-livepatch[564]: bad temporary server status 500 (URL: https://livepatch.canonical.com/api/machine-tokens) server response: m
Aug 06 09:55:32 lowend canonical-livepatch[564]: Retrying request in 67 seconds.
Aug 06 09:56:40 lowend canonical-livepatch[564]: bad temporary server status 500 (URL: https://livepatch.canonical.com/api/machine-tokens) server response: m
Aug 06 09:56:40 lowend canonical-livepatch[564]: Retrying request in 303 seconds.
Aug 06 09:58:30 lowend canonical-livepatch[564]: bad temporary server status 500 (URL: https://livepatch.canonical.com/api/machine-tokens) server response: m
Aug 06 10:01:43 lowend canonical-livepatch[564]: bad temporary server status 500 (URL: https://livepatch.canonical.com/api/machine-tokens) server response: m

2 VPS

root@kvm:~# canonical-livepatch enable 685369f7a8*****************************
2020/08/06 11:09:28 error executing enable: cannot enable machine: bad temporary server status 500 (URL: https://livepatch.canonical.com/api/machine-tokens) server response: machine token already exists
root@kvm:~# systemctl status snap.canonical-livepatch.canonical-livepatchd.service
● snap.canonical-livepatch.canonical-livepatchd.service - Service for snap application canonical-livepatch.canonical-livepatchd
     Loaded: loaded (/etc/systemd/system/snap.canonical-livepatch.canonical-livepatchd.service; enabled; vendor preset: enabled)
     Active: active (running) since Thu 2020-08-06 09:09:18; 2h 0min ago
   Main PID: 749 (canonical-livep)
      Tasks: 8 (limit: 1075)
     Memory: 15.7M
     CGroup: /system.slice/snap.canonical-livepatch.canonical-livepatchd.service
             └─749 /snap/canonical-livepatch/95/canonical-livepatchd

Aug 06 11:03:52 kvm canonical-livepatch[749]: bad temporary server status 500 (URL: https://livepatch.canonical.com/api/machine-tokens) server respons>
Aug 06 11:03:52 kvm canonical-livepatch[749]: Retrying request in 305 seconds.
Aug 06 11:04:26 kvm canonical-livepatch[749]: bad temporary server status 500 (URL: https://livepatch.canonical.com/api/machine-tokens) server respons>
Aug 06 11:04:26 kvm canonical-livepatch[749]: Retrying request in 302 seconds.
Aug 06 11:08:58 kvm canonical-livepatch[749]: bad temporary server status 500 (URL: https://livepatch.canonical.com/api/machine-tokens) server respons>
Aug 06 11:09:28 kvm canonical-livepatch[749]: bad temporary server status 500 (URL: https://livepatch.canonical.com/api/machine-tokens) server respons>
Aug 06 11:09:42 kvm canonical-livepatch[749]: Client.Check
Aug 06 11:09:42 kvm canonical-livepatch[749]: error in livepatch check state: needs-check
Aug 06 11:09:42 kvm canonical-livepatch[749]: No payload available.
Aug 06 11:09:42 kvm canonical-livepatch[749]: during refresh: cannot check: No machine-token. Please run 'canonical-livepatch enable'!

Затем я получил еще один токен, но столкнулся с той же ситуацией. Не могли бы вы мне помочь?

Источник

2 ответа

Кажется, токен (ключ) LivePatch генерируется на основе UUID машины.

Выполнение man systemd-machine-id-setup говорится ниже (вместе с другими деталями).

"При запуске на виртуальной машине KVM и настройке UUID (с помощью параметра -uuid) этот UUID используется для инициализации идентификатора машины. Вызывающий должен убедиться, что переданный UUID достаточно уникален и отличается для каждого загруженного экземпляра ВМ ".

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

Источник: https://vladimir-ivanov.net/this-machine-id-is-already-enabled-with-a-different-key-or-is-non-unique/(Спасибо Владимиру Иванову - автору.)

В решении на приведенной выше странице говорится, что вы можете вручную сгенерировать и назначить другой UUID своему компьютеру.(Повторяю детали здесь, на тот случай, если ссылка когда-нибудь устареет по неизвестной причине.)

Чтобы создать действительно уникальный идентификатор, используйте dbus-uuidgen инструмент, как показано ниже.

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

rm -f /etc/machine-id
rm /var/lib/dbus/machine-id
dbus-uuidgen --ensure=/etc/machine-id
dbus-uuidgen --ensure

Перезагрузитесь и проверьте, все ли работает нормально, прежде чем вносить дальнейшие изменения.

Предупреждение: работает man dbus-uuidgen дает следующее предупреждение (среди прочего).

"Если вы попытаетесь изменить существующий идентификатор машины в работающей системе, это, вероятно, приведет к плохим вещам. Не пытайтесь изменить этот файл. Кроме того, не делайте его одинаковым в двух разных системах; для этого необходимо быть разным в любое время, когда работают два разных ядра ".

Решение с помощью команды systemd-machine-id-setup объясняется здесь:

Источник: "Идентификатор компьютера уже активирован с другим ключом или не уникален" при настройке Livepatch(спасибо Ralkeon)

Опять же, повторение шагов по той же причине, что указано ранее.

cp /etc/machine-id /etc/machine-id.original
cp /var/lib/dbus/machine-id /var/lib/dbus/machine-id.original
nano /etc/machine-id (to remove the existing value)
systemd-machine-id-setup
> Initializing machine ID from D-Bus machine ID.
cat /etc/machine-id

Заметка:

Я бы посоветовал вам следовать первому решению, а не второму. Причина в том, что man страница из dbus-uuidgen также говорит

"Команда dbus-uuidgen генерирует или считывает универсальный уникальный идентификатор".

тогда как systemd-machine-id-setup говорит

"systemd-machine-id-setup может использоваться инструментами установки системы для инициализации идентификатора машины, хранящегося в /etc/machine-id во время установки, с предоставленным или случайно сгенерированным идентификатором".

Таким образом, в отличие от dbus-uuidgen, systemd-machine-id-setupпохоже, также помогает использовать существующий UUID (что может снова привести к дублированию токена LivePatch). См. Соответствующие manстраницы, чтобы узнать подробности. Просто подаю оповещение, так как я сам не пробовал.

Другое дело man страница из dbus-uuidgen говорит, что

UUID машины остается неизменным до следующей перезагрузки

что предполагает, что UUID может изменяться при каждой перезагрузке (опять же, я это тоже не тестировал), и есть вероятность, что другой пользователь вашего VPS может получить такой же идентификатор.

Итак, в итоге, помимо использования вышеперечисленных решений, я думаю, что также безопасно взаимодействовать с вашим поставщиком VPS, чтобы каким-то образом обеспечить соблюдение уникальных UUID для всех пользователей - просто чтобы быть вдвойне уверенным (также, чтобы увидеть, как это можно сделать:)).

Источник

Я столкнулся с такой же проблемой.

Это действительно сработало для меня на виртуальной машине Ubuntu (22.04 LTS) с использованием VMware Workstation, чтобы взглянуть на статус с помощью

      sudo ua status

а затем включить нужные службы с помощью

      sudo ua enable esm-infra livepatch fips fips-updates cis cc-eal

esm-infra и livepatch теперь включены в моей системе (остальное по-прежнему указывает n/a при использовании команды состояния).

Источник
Другие вопросы по тегам