☰

是的，现在。

tag-icon • tag-icon linux uuid
是的，现在。

我搜索了我的问题，但没有人回答我：机器 ID 是否与主板 UUID 一样唯一（在 Windows 上通过“get csproduct UUID”命令获取）？除了 mac 地址之外，在机器 ID 上绑定许可证是否足够可靠？或者 *nix 系统上可用于许可的 uuid 是什么？

答案1

是的，现在。

systemd 手册对此进行了介绍。中的值/etc/machine-id最初不是有效的 UUID，因为 systemd 人员最初并未编写正确的代码来生成版本 4 UUID。但此后此问题已得到解决。

如果您将许可证绑定到机器 ID，请注意它可能会更改...

  • …如果有人删除/etc/machine-id并在下一次引导时重新创建；
  • …如果/etc（实际上通常在根卷上）在引导时未以读写方式安装，则/etc/machine-id无效或丢失，并且/etc以后无法重新以读写方式安装以允许/etc/machine-id写入；
  • /etc…如果在操作系统未运行时包含的光盘卷被另一个不同的光盘卷替换，或者有人使用诸如以下工具更改了光盘卷上的机器 ID systemd-firstboot；
  • …如果系统是 systemd 人们所说的“无状态”并且（实际上，它比这稍微复杂一些）/etc/machine-id在以下位置重新创建每一个引导程序；
  • ...机器上的容器内。

但它是故意的，才不是改变 …

  • …如果主板、处理器或网卡被更换；
  • …如果网卡的 MAC 地址发生更改；
  • ...如果根卷（更具体地说，包含 的卷）使用类似或 的/etc内容映像到替换光盘上；ddpax
  • …在系统运行时（除非系统管理员故意乱搞）；
  • …从一个引导程序到下一个引导程序，如果/etc/machine-id第一次就有效、非空且可写。

可移植性说明

  • 不要/var/lib/dbus/machine-id优先使用/etc/machine-id.
    • 不幸的是，生成的原始桌面总线文件/etc/machine-id并不位于可跨操作系统移植的固定位置。在某些系统上，人们可以在以下位置找到它/var/lib/dbus/machine-id：于 的其他人身上/var/db/dbus/machine-id。
    • 2013 年左右的某个时候，D-Bus 被修改为使用（/etc/machine-id如果存在），取代 中的文件/var（无论它在哪里）。
    • 2015 年，Debian/Ubuntu 人们使 D-Bus 文件默认/var为符号链接/etc/machine-id， 任何状况之下。
  • /etc/machine-id不限于仅在/var安装后或网络接口启动后的引导过程中可用。
  • 尽管普通的 FreeBSD/TrueOS、NetBSD 和 OpenBSD 不提供/etc/machine-id，nosh 工具集提供了用于创建它的便携式工具（也可在 Linux 上使用），这些工具还知道 BSD 期望此类 ID 的特定于 BSD 的位置，并保留吐温一致。

进一步阅读

答案2

通过谷歌快速搜索：

  • /etc/机器 ID应该是唯一的，只有在重新安装机器时才会更改，但由 systemd 提供，许多系统没有
  • /var/lib/dbus/机器 ID应该是独一无二的，并且应该更广泛地使用。这文档说如果硬件配置发生变化它也会改变，但在实践我认为只有重新安装机器才会改变
  • 你可以用系统uuid，但是需要root，主板变了也会变

/var/lib/dbus/machine-id似乎是大多数情况下的最佳方法。

进一步阅读：

相关内容