NAME<\/a> machine-id \u2212 Local machine ID configuration file<\/p>\n \/etc\/machine\u2212id<\/p>\n The \/etc\/machine\u2212id file contains the unique machine ID of the local system that is set during installation or boot. The machine ID is a single newline\u2212terminated, hexadecimal, 32\u2212character, lowercase ID. When decoded from hexadecimal, this corresponds to a 16\u2212byte\/128\u2212bit value. This ID may not be all zeros.<\/p>\n 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.<\/p>\n The machine ID may be set, for example when network booting, with the systemd.machine_id=<\/i> kernel command line parameter or by passing the option \u2212\u2212machine\u2212id=<\/b> to systemd. An ID specified in this manner has higher priority and will be used instead of the ID stored in \/etc\/machine\u2212id.<\/p>\n 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 gethostid<\/b>(3) call that POSIX specifies.<\/p>\n This machine ID adheres to the same format and logic as the D\u2212Bus machine ID.<\/p>\n 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\u2212specific 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\u2212specific one. The sd_id128_get_machine_app_specific<\/b>(3) API provides an implementation of such an algorithm.<\/p>\n Each machine should have a non\u2212empty ID in normal operation. The ID of each machine should be unique. To achieve those objectives, \/etc\/machine\u2212id can be initialized in a few different ways.<\/p>\n For normal operating system installations, where a custom image is created for a specific machine, \/etc\/machine\u2212id should be populated during installation.<\/p>\n systemd-machine-id-setup<\/b>(1) may be used by installer tools to initialize the machine ID at install time, but \/etc\/machine\u2212id may also be written using any other means.<\/p>\n For operating system images which are created once and used on multiple machines, for example for containers or in the cloud, \/etc\/machine\u2212id should be an empty file in the generic file system image. 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\u2212mounted over the real file, in case the image is used read\u2212only.<\/p>\n systemd-firstboot<\/b>(1) may be used to initialize \/etc\/machine\u2212id on mounted (but not booted) system images.<\/p>\n When a machine is booted with systemd<\/b>(1) the ID of the machine will be established. If systemd.machine_id=<\/i> or \u2212\u2212machine\u2212id=<\/b> options (see first section) are specified, this value will be used. Otherwise, the value in \/etc\/machine\u2212id will be used. If this file is empty or missing, systemd will attempt to use the D\u2212Bus machine ID from \/var\/lib\/dbus\/machine\u2212id, the value of the kernel command line option container_uuid<\/i>, the KVM DMI product_uuid or the devicetree vm,uuid (on KVM systems), and finally a randomly generated UUID.<\/p>\n After the machine ID is established, systemd<\/b>(1) will attempt to save it to \/etc\/machine\u2212id. If this fails, it will attempt to bind\u2212mount a temporary file over \/etc\/machine\u2212id. It is an error if the file system is read\u2212only and does not contain a (possibly empty) \/etc\/machine\u2212id file.<\/p>\n systemd-machine-id-commit.service<\/b>(8) will attempt to write the machine ID to the file system if \/etc\/machine\u2212id or \/etc are read\u2212only during early boot but become writable later on.<\/p>\n Note that the machine ID historically is not an OSF UUID as defined by RFC 4122<\/font><\/b> [1]<\/font><\/small> , nor a Microsoft GUID; however, starting with systemd v30, newly generated machine IDs do qualify as v4 UUIDs.<\/font><\/p>\n 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 “id” being an unsigned character array:<\/font><\/p>\n \/* Set UUID version to 4 \u2212\u2212\u2212 truly random generation bodies\/ usr\/ (This code is inspired by “generate_random_uuid()” of drivers\/char\/random.c from the Linux kernel sources.)<\/font><\/p>\n The simple configuration file format of \/etc\/machine\u2212id originates in the \/var\/lib\/dbus\/machine\u2212id file introduced by D\u2212Bus. In fact, this latter file might be a symlink to \/etc\/machine\u2212id.<\/font><\/p>\n systemd<\/b>(1), systemd-machine-id-setup<\/b>(1), gethostid<\/b>(3), hostname<\/b>(5), machine-info<\/b>(5), os-release<\/b>(5), sd-id128<\/b>(3), sd_id128_get_machine<\/b>(3), systemd-firstboot<\/b>(1)<\/font><\/p>\n 1.<\/font><\/p>\n<\/td>\n RFC 4122<\/font><\/p>\n<\/td>\n https:\/\/tools.ietf.org\/html\/rfc4122<\/font><\/p>\n machine-id \u2212 Local machine ID configuration file <\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[959],"tags":[961,1399,1291],"class_list":["post-4398","post","type-post","status-publish","format-standard","hentry","category-5-formatos-de-ficheros","tag-961","tag-machine-id","tag-man5"],"gutentor_comment":0,"_links":{"self":[{"href":"https:\/\/lode.uno\/linux-man\/wp-json\/wp\/v2\/posts\/4398","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/lode.uno\/linux-man\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/lode.uno\/linux-man\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/lode.uno\/linux-man\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/lode.uno\/linux-man\/wp-json\/wp\/v2\/comments?post=4398"}],"version-history":[{"count":0,"href":"https:\/\/lode.uno\/linux-man\/wp-json\/wp\/v2\/posts\/4398\/revisions"}],"wp:attachment":[{"href":"https:\/\/lode.uno\/linux-man\/wp-json\/wp\/v2\/media?parent=4398"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/lode.uno\/linux-man\/wp-json\/wp\/v2\/categories?post=4398"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/lode.uno\/linux-man\/wp-json\/wp\/v2\/tags?post=4398"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
SYNOPSIS<\/a>
DESCRIPTION<\/a>
INITIALIZATION<\/a>
RELATION TO OSF UUIDS<\/a>
HISTORY<\/a>
SEE ALSO<\/a>
NOTES<\/a> <\/p>\n
\nNAME <\/a> <\/h2>\n
SYNOPSIS <\/a> <\/h2>\n
DESCRIPTION <\/a> <\/h2>\n
INITIALIZATION <\/a> <\/h2>\n
RELATION TO OSF UUIDS <\/a> <\/h2>\n
id[6] = (id[6] & 0x0F) | 0x40;
\/bin \/boot \/dead.letter \/dev \/etc \/home \/initrd \/lib \/lib64 \/lost+found \/media \/mnt \/opt \/proc \/release-notes.html \/release-notes.txt \/root \/run \/sbin \/srv \/sys \/tmp \/usr \/var Set the UUID variant to DCE bodies\/ usr\/
id[8] = (id[8] & 0x3F) | 0x80;<\/font><\/p>\nHISTORY <\/a> <\/h2>\n
SEE ALSO <\/a> <\/h2>\n
NOTES <\/a> <\/h2>\n
\n
\n <\/td>\n \n <\/td>\n \n <\/td>\n<\/tr>\n<\/table>\n
\n","protected":false},"excerpt":{"rendered":"