当我试图启用令牌时，正则livepatch失败了

Question

我试过使用规范的livepatch，但失败了。我有三个VPS。第一次是一个月前我添加了我的记号。现在，我想在我的其他2个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'!

然后我又得到了另一个记号，但也面临着同样的情况。你能帮帮我吗？

Answer 1

似乎LivePatch令牌(Key)是基于Machine生成的。

执行man systemd-machine-id-setup说明如下(以及其他细节)。

“如果在KVM虚拟机中运行并配置了UUID (通过-uuid选项)，则该UUID用于初始化机器ID。调用方必须确保所传递的UUID足够唯一，并且对于VM的每个引导实例都不同。”

由于您的是一个VPS空间，似乎需要在每个不同的用户机器上强制执行一个唯一的UUID，这是VPS提供者的责任。您应该与您的VPS提供程序检查UUID在不同用户之间的唯一性。

资料来源：https://vladimir-ivanov.net/this-machine-id-is-already-enabled-with-a-different-key-or-is-non-unique/ (感谢Vladimir Ivanov -作者)。

上面页面中的解决方案说，您也可以手动为您的机器生成和分配一个不同的UUID。(在这里重复这些细节，以防有一天链接由于未知的原因而过时。)

要生成真正唯一的ID，请使用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会发出以下警告(除其他外)。

“如果您试图更改正在运行的系统上的现有机器id，它可能会导致错误的事情发生。不要试图更改此文件。此外，不要在两个不同的系统上使其相同；在运行两个不同的内核时，它需要不同。”

这里解释了使用命令systemd-machine-id-setup的解决方案：

资料来源：设置Livepatch时“已启用不同键或非唯一的机器ID” (感谢https://askubuntu.com/users/878529/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命令生成或读取一个普遍唯一的ID。”

然而，systemd-machine-id-setup说

系统安装工具可以使用systemd- machine - ID来初始化安装时存储在/etc/machine-id中的机器ID，并使用提供的或随机生成的ID。

因此，与dbus-uuidgen不同，systemd-machine-id-setup似乎也帮助使用了现有的UUID (这可能导致重复的LivePatch令牌)。有关详细信息，请参阅各自的man页面。只是提醒一下，因为我自己也没试过。

另一件事，man页面的dbus-uuidgen说，

直到下一次重新启动，机器UUID保持不变。

这表明UUID有可能在每次重新启动时进行更改(同样，我也没有对此进行测试)&您的VPS的另一个用户可能会获得相同的ID。

因此，总之，除了使用上述解决方案之外，我认为还可以与VPS提供商联系，以某种方式为所有用户强制执行唯一的UUID--这是双重肯定的(同时，看看如何做到：)。

Answer 2

我也遇到了同样的问题。

它实际上在Ubuntu (22.04LTS) VM中工作，使用VMware工作站查看

sudo ua status

然后启用所需的服务，使用

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

esm-infra和livepatch现在已在我的系统上启用(在使用status命令时，rest仍然处于n/a状态)。