1 <?xml version='
1.0'
?> <!--*-nxml-*-->
2 <!DOCTYPE refentry PUBLIC
"-//OASIS//DTD DocBook XML V4.2//EN"
3 "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
6 SPDX-License-Identifier: LGPL-2.1+
9 <refentry id=
"machine-id">
11 <title>machine-id
</title>
12 <productname>systemd
</productname>
16 <refentrytitle>machine-id
</refentrytitle>
17 <manvolnum>5</manvolnum>
21 <refname>machine-id
</refname>
22 <refpurpose>Local machine ID configuration file
</refpurpose>
26 <para><filename>/etc/machine-id
</filename></para>
30 <title>Description
</title>
32 <para>The
<filename>/etc/machine-id
</filename> file contains the unique machine ID of
33 the local system that is set during installation or boot. The machine ID is a single
34 newline-terminated, hexadecimal,
32-character, lowercase ID. When decoded from
35 hexadecimal, this corresponds to a
16-byte/
128-bit value. This ID may not be all
38 <para>The machine ID is usually generated from a random source during system
39 installation or first boot and stays constant for all subsequent boots. Optionally,
40 for stateless systems, it is generated during runtime during early boot if necessary.
43 <para>The machine ID may be set, for example when network booting, with the
44 <varname>systemd.machine_id=
</varname> kernel command line parameter or by passing the
45 option
<option>--machine-id=
</option> to systemd. An ID is specified in this manner
46 has higher priority and will be used instead of the ID stored in
47 <filename>/etc/machine-id
</filename>.
</para>
49 <para>The machine ID does not change based on local or network configuration or when
50 hardware is replaced. Due to this and its greater length, it is a more useful
52 <citerefentry project='man-pages'
><refentrytitle>gethostid
</refentrytitle><manvolnum>3</manvolnum></citerefentry>
53 call that POSIX specifies.
</para>
55 <para>This machine ID adheres to the same format and logic as the
56 D-Bus machine ID.
</para>
58 <para>This ID uniquely identifies the host. It should be considered
"confidential", and must not be exposed in
59 untrusted environments, in particular on the network. If a stable unique identifier that is tied to the machine is
60 needed for some application, the machine ID or any part of it must not be used directly. Instead the machine ID
61 should be hashed with a cryptographic, keyed hash function, using a fixed, application-specific key. That way the
62 ID will be properly unique, and derived in a constant way from the machine ID but there will be no way to retrieve
63 the original machine ID from the application-specific one. The
64 <citerefentry><refentrytitle>sd_id128_get_machine_app_specific
</refentrytitle><manvolnum>3</manvolnum></citerefentry>
65 API provides an implementation of such an algorithm.
</para>
69 <title>Initialization
</title>
71 <para>Each machine should have a non-empty ID in normal operation. The ID of each
72 machine should be unique. To achieve those objectives,
73 <filename>/etc/machine-id
</filename> can be initialized in a few different ways.
76 <para>For normal operating system installations, where a custom image is created for a
77 specific machine,
<filename>/etc/machine-id
</filename> should be populated during
81 <citerefentry><refentrytitle>systemd-machine-id-setup
</refentrytitle><manvolnum>1</manvolnum></citerefentry>
82 may be used by installer tools to initialize the machine ID at install time, but
83 <filename>/etc/machine-id
</filename> may also be written using any other means.
86 <para>For operating system images which are created once and used on multiple
87 machines, for example for containers or in the cloud,
88 <filename>/etc/machine-id
</filename> should be an empty file in the generic file
89 system image. An ID will be generated during boot and saved to this file if
90 possible. Having an empty file in place is useful because it allows a temporary file
91 to be bind-mounted over the real file, in case the image is used read-only.
</para>
93 <para><citerefentry><refentrytitle>systemd-firstboot
</refentrytitle><manvolnum>1</manvolnum></citerefentry>
94 may be used to initialize
<filename>/etc/machine-id
</filename> on mounted (but not
95 booted) system images.
</para>
97 <para>When a machine is booted with
98 <citerefentry><refentrytitle>systemd
</refentrytitle><manvolnum>1</manvolnum></citerefentry>
99 the ID of the machine will be established. If
<varname>systemd.machine_id=
</varname>
100 or
<option>--machine-id=
</option> options (see first section) are specified, this
101 value will be used. Otherwise, the value in
<filename>/etc/machine-id
</filename> will
102 be used. If this file is empty or missing,
<filename>systemd
</filename> will attempt
103 to use the D-Bus machine ID from
<filename>/var/lib/dbus/machine-id
</filename>, the
104 value of the kernel command line option
<varname>container_uuid
</varname>, the KVM DMI
105 <filename>product_uuid
</filename> (on KVM systems), and finally a randomly generated
108 <para>After the machine ID is established,
109 <citerefentry><refentrytitle>systemd
</refentrytitle><manvolnum>1</manvolnum></citerefentry>
110 will attempt to save it to
<filename>/etc/machine-id
</filename>. If this fails, it
111 will attempt to bind-mount a temporary file over
<filename>/etc/machine-id
</filename>.
112 It is an error if the file system is read-only and does not contain a (possibly empty)
113 <filename>/etc/machine-id
</filename> file.
</para>
115 <para><citerefentry><refentrytitle>systemd-machine-id-commit.service
</refentrytitle><manvolnum>8</manvolnum></citerefentry>
116 will attempt to write the machine ID to the file system if
117 <filename>/etc/machine-id
</filename> or
<filename>/etc
</filename> are read-only during
118 early boot but become writable later on.
</para>
122 <title>Relation to OSF UUIDs
</title>
124 <para>Note that the machine ID historically is not an OSF UUID as
125 defined by
<ulink url=
"https://tools.ietf.org/html/rfc4122">RFC
126 4122</ulink>, nor a Microsoft GUID; however, starting with systemd
127 v30, newly generated machine IDs do qualify as v4 UUIDs.
</para>
129 <para>In order to maintain compatibility with existing
130 installations, an application requiring a UUID should decode the
131 machine ID, and then apply the following operations to turn it
132 into a valid OSF v4 UUID. With
<literal>id
</literal> being an
133 unsigned character array:
</para>
135 <programlisting>/* Set UUID version to
4 --- truly random generation */
136 id[
6] = (id[
6]
& 0x0F) |
0x40;
137 /* Set the UUID variant to DCE */
138 id[
8] = (id[
8]
& 0x3F) |
0x80;
</programlisting>
140 <para>(This code is inspired by
141 <literal>generate_random_uuid()
</literal> of
142 <filename>drivers/char/random.c
</filename> from the Linux kernel
148 <title>History
</title>
150 <para>The simple configuration file format of
151 <filename>/etc/machine-id
</filename> originates in the
152 <filename>/var/lib/dbus/machine-id
</filename> file introduced by
153 D-Bus. In fact, this latter file might be a symlink to
154 <filename>/etc/machine-id
</filename>.
</para>
158 <title>See Also
</title>
160 <citerefentry><refentrytitle>systemd
</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
161 <citerefentry><refentrytitle>systemd-machine-id-setup
</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
162 <citerefentry project='man-pages'
><refentrytitle>gethostid
</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
163 <citerefentry><refentrytitle>hostname
</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
164 <citerefentry><refentrytitle>machine-info
</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
165 <citerefentry><refentrytitle>os-release
</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
166 <citerefentry><refentrytitle>sd-id128
</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
167 <citerefentry><refentrytitle>sd_id128_get_machine
</refentrytitle><manvolnum>3</manvolnum></citerefentry>,
168 <citerefentry><refentrytitle>systemd-firstboot
</refentrytitle><manvolnum>1</manvolnum></citerefentry>