2011-03-04 20:53:19 +00:00
|
|
|
<?xml version='1.0'?> <!--*-nxml-*-->
|
2019-03-14 13:40:58 +00:00
|
|
|
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
|
2015-06-18 17:47:44 +00:00
|
|
|
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
|
2020-11-09 04:23:58 +00:00
|
|
|
<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
|
2011-03-04 20:53:19 +00:00
|
|
|
|
|
|
|
<refentry id="machine-id">
|
2015-02-04 02:14:13 +00:00
|
|
|
<refentryinfo>
|
|
|
|
<title>machine-id</title>
|
|
|
|
<productname>systemd</productname>
|
|
|
|
</refentryinfo>
|
|
|
|
|
|
|
|
<refmeta>
|
|
|
|
<refentrytitle>machine-id</refentrytitle>
|
|
|
|
<manvolnum>5</manvolnum>
|
|
|
|
</refmeta>
|
|
|
|
|
|
|
|
<refnamediv>
|
|
|
|
<refname>machine-id</refname>
|
|
|
|
<refpurpose>Local machine ID configuration file</refpurpose>
|
|
|
|
</refnamediv>
|
|
|
|
|
|
|
|
<refsynopsisdiv>
|
|
|
|
<para><filename>/etc/machine-id</filename></para>
|
|
|
|
</refsynopsisdiv>
|
|
|
|
|
|
|
|
<refsect1>
|
|
|
|
<title>Description</title>
|
|
|
|
|
2017-10-18 16:47:34 +00:00
|
|
|
<para>The <filename>/etc/machine-id</filename> file contains the unique machine ID of
|
|
|
|
the local system that is set during installation or boot. The machine ID is a single
|
|
|
|
newline-terminated, hexadecimal, 32-character, lowercase ID. When decoded from
|
|
|
|
hexadecimal, this corresponds to a 16-byte/128-bit value. This ID may not be all
|
|
|
|
zeros.</para>
|
|
|
|
|
|
|
|
<para>The machine ID is usually generated from a random source during system
|
|
|
|
installation or first boot and stays constant for all subsequent boots. Optionally,
|
|
|
|
for stateless systems, it is generated during runtime during early boot if necessary.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>The machine ID may be set, for example when network booting, with the
|
|
|
|
<varname>systemd.machine_id=</varname> kernel command line parameter or by passing the
|
2020-07-06 08:49:59 +00:00
|
|
|
option <option>--machine-id=</option> to systemd. An ID specified in this manner
|
2017-10-18 16:47:34 +00:00
|
|
|
has higher priority and will be used instead of the ID stored in
|
|
|
|
<filename>/etc/machine-id</filename>.</para>
|
|
|
|
|
|
|
|
<para>The machine ID does not change based on local or network configuration or when
|
|
|
|
hardware is replaced. Due to this and its greater length, it is a more useful
|
|
|
|
replacement for the
|
2016-11-11 12:31:52 +00:00
|
|
|
<citerefentry project='man-pages'><refentrytitle>gethostid</refentrytitle><manvolnum>3</manvolnum></citerefentry>
|
|
|
|
call that POSIX specifies.</para>
|
2015-02-04 02:14:13 +00:00
|
|
|
|
|
|
|
<para>This machine ID adheres to the same format and logic as the
|
|
|
|
D-Bus machine ID.</para>
|
|
|
|
|
2016-11-17 16:07:46 +00:00
|
|
|
<para>This ID uniquely identifies the host. It should be considered "confidential", and must not be exposed in
|
|
|
|
untrusted environments, in particular on the network. If a stable unique identifier that is tied to the machine is
|
|
|
|
needed for some application, the machine ID or any part of it must not be used directly. Instead the machine ID
|
|
|
|
should be hashed with a cryptographic, keyed hash function, using a fixed, application-specific key. That way the
|
|
|
|
ID will be properly unique, and derived in a constant way from the machine ID but there will be no way to retrieve
|
|
|
|
the original machine ID from the application-specific one. The
|
|
|
|
<citerefentry><refentrytitle>sd_id128_get_machine_app_specific</refentrytitle><manvolnum>3</manvolnum></citerefentry>
|
|
|
|
API provides an implementation of such an algorithm.</para>
|
2017-10-18 16:47:34 +00:00
|
|
|
</refsect1>
|
|
|
|
|
|
|
|
<refsect1>
|
|
|
|
<title>Initialization</title>
|
|
|
|
|
|
|
|
<para>Each machine should have a non-empty ID in normal operation. The ID of each
|
2018-06-12 14:19:21 +00:00
|
|
|
machine should be unique. To achieve those objectives,
|
2017-10-18 16:47:34 +00:00
|
|
|
<filename>/etc/machine-id</filename> can be initialized in a few different ways.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>For normal operating system installations, where a custom image is created for a
|
|
|
|
specific machine, <filename>/etc/machine-id</filename> should be populated during
|
|
|
|
installation.</para>
|
2015-02-04 02:14:13 +00:00
|
|
|
|
2017-10-18 16:47:34 +00:00
|
|
|
<para>
|
2015-02-04 02:14:13 +00:00
|
|
|
<citerefentry><refentrytitle>systemd-machine-id-setup</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
2017-10-18 16:47:34 +00:00
|
|
|
may be used by installer tools to initialize the machine ID at install time, but
|
|
|
|
<filename>/etc/machine-id</filename> may also be written using any other means.
|
|
|
|
</para>
|
|
|
|
|
|
|
|
<para>For operating system images which are created once and used on multiple
|
|
|
|
machines, for example for containers or in the cloud,
|
2020-09-06 20:57:59 +00:00
|
|
|
<filename>/etc/machine-id</filename> should be either missing or an empty file in the generic file
|
|
|
|
system image (the difference between the two options is described under "First Boot Semantics" below). An
|
|
|
|
ID will be generated during boot and saved to this file if possible. Having an empty file in place is
|
|
|
|
useful because it allows a temporary file to be bind-mounted over the real file, in case the image is
|
|
|
|
used read-only.</para>
|
2017-10-18 16:47:34 +00:00
|
|
|
|
|
|
|
<para><citerefentry><refentrytitle>systemd-firstboot</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
2018-06-12 14:19:21 +00:00
|
|
|
may be used to initialize <filename>/etc/machine-id</filename> on mounted (but not
|
2017-10-18 16:47:34 +00:00
|
|
|
booted) system images.</para>
|
|
|
|
|
|
|
|
<para>When a machine is booted with
|
|
|
|
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
|
|
|
the ID of the machine will be established. If <varname>systemd.machine_id=</varname>
|
|
|
|
or <option>--machine-id=</option> options (see first section) are specified, this
|
|
|
|
value will be used. Otherwise, the value in <filename>/etc/machine-id</filename> will
|
|
|
|
be used. If this file is empty or missing, <filename>systemd</filename> will attempt
|
|
|
|
to use the D-Bus machine ID from <filename>/var/lib/dbus/machine-id</filename>, the
|
|
|
|
value of the kernel command line option <varname>container_uuid</varname>, the KVM DMI
|
2019-04-15 14:07:52 +00:00
|
|
|
<filename>product_uuid</filename> or the devicetree <filename>vm,uuid</filename>
|
|
|
|
(on KVM systems), and finally a randomly generated UUID.</para>
|
2017-10-18 16:47:34 +00:00
|
|
|
|
|
|
|
<para>After the machine ID is established,
|
|
|
|
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
|
|
|
will attempt to save it to <filename>/etc/machine-id</filename>. If this fails, it
|
|
|
|
will attempt to bind-mount a temporary file over <filename>/etc/machine-id</filename>.
|
|
|
|
It is an error if the file system is read-only and does not contain a (possibly empty)
|
|
|
|
<filename>/etc/machine-id</filename> file.</para>
|
|
|
|
|
|
|
|
<para><citerefentry><refentrytitle>systemd-machine-id-commit.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
|
|
|
|
will attempt to write the machine ID to the file system if
|
2020-10-05 16:08:21 +00:00
|
|
|
<filename>/etc/machine-id</filename> or <filename>/etc/</filename> are read-only during
|
2017-10-18 16:47:34 +00:00
|
|
|
early boot but become writable later on.</para>
|
2015-02-04 02:14:13 +00:00
|
|
|
</refsect1>
|
|
|
|
|
2020-09-06 20:57:59 +00:00
|
|
|
<refsect1>
|
|
|
|
<title>First Boot Semantics</title>
|
|
|
|
|
|
|
|
<para><filename>/etc/machine-id</filename> is used to decide whether a boot is the first one. The rules
|
|
|
|
are as follows:</para>
|
|
|
|
|
|
|
|
<orderedlist>
|
|
|
|
<listitem><para>If <filename>/etc/machine-id</filename> does not exist, this is a first boot. During
|
2020-10-24 03:07:19 +00:00
|
|
|
early boot, <command>systemd</command> will write <literal>uninitialized\n</literal> to this file and overmount
|
2020-09-06 20:57:59 +00:00
|
|
|
a temporary file which contains the actual machine ID. Later (after <filename>first-boot-complete.target</filename>
|
|
|
|
has been reached), the real machine ID will be written to disk.</para></listitem>
|
|
|
|
|
|
|
|
<listitem><para>If <filename>/etc/machine-id</filename> contains the string <literal>uninitialized</literal>,
|
|
|
|
a boot is also considered the first boot. The same mechanism as above applies.</para></listitem>
|
|
|
|
|
|
|
|
<listitem><para>If <filename>/etc/machine-id</filename> exists and is empty, a boot is
|
|
|
|
<emphasis>not</emphasis> considered the first boot. <command>systemd</command> will still bind-mount a file
|
|
|
|
containing the actual machine-id over it and later try to commit it to disk (if <filename>/etc/</filename> is
|
|
|
|
writable).</para></listitem>
|
|
|
|
|
|
|
|
<listitem><para>If <filename>/etc/machine-id</filename> already contains a valid machine-id, this is
|
|
|
|
not a first boot.</para></listitem>
|
|
|
|
</orderedlist>
|
|
|
|
|
|
|
|
<para>If by any of the above rules, a first boot is detected, units with <varname>ConditionFirstBoot=yes</varname>
|
|
|
|
will be run.</para>
|
|
|
|
</refsect1>
|
|
|
|
|
2015-02-04 02:14:13 +00:00
|
|
|
<refsect1>
|
|
|
|
<title>Relation to OSF UUIDs</title>
|
|
|
|
|
|
|
|
<para>Note that the machine ID historically is not an OSF UUID as
|
|
|
|
defined by <ulink url="https://tools.ietf.org/html/rfc4122">RFC
|
|
|
|
4122</ulink>, nor a Microsoft GUID; however, starting with systemd
|
|
|
|
v30, newly generated machine IDs do qualify as v4 UUIDs.</para>
|
|
|
|
|
|
|
|
<para>In order to maintain compatibility with existing
|
|
|
|
installations, an application requiring a UUID should decode the
|
|
|
|
machine ID, and then apply the following operations to turn it
|
|
|
|
into a valid OSF v4 UUID. With <literal>id</literal> being an
|
|
|
|
unsigned character array:</para>
|
|
|
|
|
|
|
|
<programlisting>/* Set UUID version to 4 --- truly random generation */
|
2011-07-25 17:31:07 +00:00
|
|
|
id[6] = (id[6] & 0x0F) | 0x40;
|
|
|
|
/* Set the UUID variant to DCE */
|
|
|
|
id[8] = (id[8] & 0x3F) | 0x80;</programlisting>
|
|
|
|
|
2015-02-04 02:14:13 +00:00
|
|
|
<para>(This code is inspired by
|
|
|
|
<literal>generate_random_uuid()</literal> of
|
|
|
|
<filename>drivers/char/random.c</filename> from the Linux kernel
|
|
|
|
sources.)</para>
|
|
|
|
|
|
|
|
</refsect1>
|
|
|
|
|
|
|
|
<refsect1>
|
|
|
|
<title>History</title>
|
|
|
|
|
|
|
|
<para>The simple configuration file format of
|
|
|
|
<filename>/etc/machine-id</filename> originates in the
|
|
|
|
<filename>/var/lib/dbus/machine-id</filename> file introduced by
|
|
|
|
D-Bus. In fact, this latter file might be a symlink to
|
2015-09-28 15:42:30 +00:00
|
|
|
<filename>/etc/machine-id</filename>.</para>
|
2015-02-04 02:14:13 +00:00
|
|
|
</refsect1>
|
|
|
|
|
|
|
|
<refsect1>
|
|
|
|
<title>See Also</title>
|
|
|
|
<para>
|
|
|
|
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
|
|
|
|
<citerefentry><refentrytitle>systemd-machine-id-setup</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
|
2015-03-14 02:22:39 +00:00
|
|
|
<citerefentry project='man-pages'><refentrytitle>gethostid</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
|
2015-02-04 02:14:13 +00:00
|
|
|
<citerefentry><refentrytitle>hostname</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
|
|
|
|
<citerefentry><refentrytitle>machine-info</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
|
|
|
|
<citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
|
|
|
|
<citerefentry><refentrytitle>sd-id128</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
|
|
|
|
<citerefentry><refentrytitle>sd_id128_get_machine</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
|
|
|
|
<citerefentry><refentrytitle>systemd-firstboot</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
|
|
|
</para>
|
|
|
|
</refsect1>
|
2011-03-04 20:53:19 +00:00
|
|
|
|
|
|
|
</refentry>
|