当我尝试启用令牌时，Canonical livepatch 失败

Question

我尝试使用规范的 livepatch，但失败了。我有 3 个 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 令牌（密钥）是基于机器 UUID 生成的。

执行man systemd-machine-id-setup声明如下（以及其他细节）。

“如果在 KVM 虚拟机中运行并配置了 UUID（通过 -uuid 选项），则此 UUID 用于初始化机器 ID。调用者必须确保传递的 UUID 足够唯一，并且对于每个启动的实例都是不同的虚拟机。”

由于你的是一个VPS空间，看来每个不同的用户机器上都需要强制执行唯一的UUID，这是VPS Provider的责任。您应该与您的 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-setup 来在安装时使用预配或随机生成的 ID 初始化存储在 /etc/machine-id 中的机器 ID。”

因此，不像dbus-uuidgen,systemd-machine-id-setup似乎也有助于使用现有的 UUID（这可能会再次导致重复的 LivePatch 令牌）。man有关确切的详细信息，请参阅相应的页面。只是发出警报，因为我自己都没有尝试过。

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

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

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

因此，总而言之，除了使用上述解决方案之外，我认为与您的 VPS 提供商联络以某种方式为所有用户强制执行唯一的 UUID 也是安全的 - 只是要加倍确定（另外，看看如何做到：） ）。