Canonical livepatch failed when I tried to enable token
I tried to use canonical livepatch, but failed. I have 3 VPS. On the first one I added my token a month ago. Now I wanted to add the same token to my other 2 VPS but failed.
1 VPS (cut my token for this forum)
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'!
Then I got another token, but faced the same situation. Can you help me please?
It seems LivePatch token(key) is generated based on the Machine UUID.
Executing man systemd-machine-id-setup states the below (along with other details).
"If run inside a KVM virtual machine and a UUID is configured (via the -uuid option), this UUID is used to initialize the machine ID. The caller must ensure that the UUID passed is sufficiently unique and is different for every booted instance of the VM."
Since yours is a VPS space, it seems that a unique UUID need to be enforced on each different user machine, which is the responsibility of the VPS Provider. You should check with your VPS Provider for the uniqueness of UUIDs across different users.
Source: https://vladimir-ivanov.net/this-machine-id-is-already-enabled-with-a-different-key-or-is-non-unique/ (Thanks to Vladimir Ivanov - the Author.)
The solution in above page says that you can generate & assign a different UUID to your machine, manually also. (Repeating the details here, just in case the link goes obsolete some day, due to reason unknown.)
To generate truly unique ID, use dbus-uuidgen tool as below.
Note: I think it is wise to take a backup of the files, before removing them - to enable a fallback option, if something goes wrong (Read the warning below, before executing the below steps).
rm -f /etc/machine-id
rm /var/lib/dbus/machine-id
dbus-uuidgen --ensure=/etc/machine-id
dbus-uuidgen --ensure
Reboot and see if everything is working fine, before making any further changes.
Warning:
Running man dbus-uuidgen gives the below warning (among others).
"If you try to change an existing machine-id on a running system, it will probably result in bad things happening. Don't try to change this file. Also, don't make it the same on two different systems; it needs to be different anytime there are two different kernels running."
The solution using the command systemd-machine-id-setup is explained here:
Source: "Machine ID already enabled with different key, or non-unique" when setting up Livepatch (Thanks to https://askubuntu.com/users/878529/ralkeon)
Again, repeating the steps for the same reason as stated earlier.
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
Note:
I would suggest you to follow the former solution rather than the latter. Reason being, the man page of dbus-uuidgen also says
"The dbus-uuidgen command generates or reads a universally unique ID."
whereas, that of systemd-machine-id-setup says
"systemd-machine-id-setup may be used by system installer tools to initialize the machine ID stored in /etc/machine-id at install time, with a provisioned or randomly generated ID."
Thus, unlike dbus-uuidgen, systemd-machine-id-setup seems to help use an existing UUID too (which could result in a duplicate LivePatch Token again). Refer the respective man pages, for exact details. Just giving an alert, as I haven't tried either on my own.
Another thing the man page of dbus-uuidgen says is that
the machine UUID remains unchanged until the next reboot
which suggests that the UUID has a possibility of changing on every reboot (again, I haven't tested this either) & there is a chance another User of your VPS might get the same ID.
So, in summary, apart from using the solutions above, I think it is also safe to liaise with your VPS Provider to somehow enforce unique UUID's for all Users - just to be double sure (also, to see how it could be done :)).