| MACHINE-INFO(5) | machine-info | MACHINE-INFO(5) |
.SH "NAME" machine-info - Local machine information file
.SH "SYNOPSIS"
.PP /etc/machine-info
.SH "DESCRIPTION"
.PP The /etc/machine-info file contains machine metadata.
.PP The format of machine-info is a newline-separated list of
environment-like shell-compatible variable assignments, ignoring comments
and empty lines. It is possible to source the configuration from shell
scripts, however, beyond mere variable assignments no shell features are
supported, allowing applications to read the file without implementing a
shell compatible execution engine. See os-release(5) for a detailed
description of the format.
.PP /etc/machine-info contains metadata about the machine that is set by the
user or administrator. The settings configured here have the highest
precedence. When not set, appropriate values may be determined
automatically, based on the information about the hardware or other
configuration files. It is thus completely fine for this file to not be
present.
.PP You may use hostnamectl(1) to change the settings of this file
from the command line.
.SH "OPTIONS"
.PP The following machine metadata parameters may be set using
/etc/machine-info:
.SS "Machine Information"
.PP PRETTY_HOSTNAME=
A pretty human-readable UTF-8 machine identifier string. This should contain
a name like Lennart's Laptop which is useful to present to the user and does
not suffer by the syntax limitations of internet domain names. If possible,
the internet hostname as configured in /etc/hostname should be kept similar
to this one. Example: if this value is Lennart's Computer an Internet
hostname of lennarts-computer might be a good choice. If this parameter is
not set, an application should fall back to the Internet hostname for
presentation purposes.
.RE
.PP ICON_NAME=
An icon identifying this machine according to the XDG Icon Naming
Specification[1]. If this parameter is not set, an application should
fall back to computer or a similar icon name.
.RE
.PP CHASSIS=
The chassis type. Currently, the following chassis types are defined:
desktop, laptop, convertible, server, tablet, handset, watch, and embedded,
as well as the special chassis types vm and container for virtualized
systems that lack an immediate physical chassis.
Note that most systems allow detection of the chassis type automatically
(based on firmware information or suchlike). This setting should only be
used to override a misdetection or to manually configure the chassis type
where automatic detection is not available.
Added in version 197.
.RE
.PP DEPLOYMENT=
Describes the system deployment environment. One of the following is
suggested: development, integration, staging, testing, production.
Added in version 216.
.RE
.PP LOCATION=
Describes the system location if applicable and known. Takes a
human-friendly, free-form string. This may be as generic as Berlin, Germany
or as specific as Left Rack, 2nd Shelf.
Added in version 216.
.RE
.PP TAGS=
A colon-separated list of tags attached to this machine. Tags are short
labels that may be used to classify and group machines for management
purposes, for example to identify the role a machine plays in a deployment
(webserver, database), the fleet or organizational unit it belongs to, or
any other administrator-defined attribute. Example:
TAGS=webserver:frontend:berlin.
Each individual tag must be 1...255 characters long and may consist only of
the ASCII alphanumeric characters, -, . and =. The first character may not
be -, . or =, and the last character may not be - or . (unless it takes the
parameterized form, see below).
A tag may optionally be parameterized with a value, in the form
key=value. The first = separates the key from the value; any
further = characters are part of the value. The key (the part before the
first =) follows the same restrictions as an unparameterized tag, in
particular it may not be empty and may not end in - or .. The value (the
part after the first =) may be empty and is otherwise unrestricted within
the allowed character set. Example:
TAGS=role=webserver:env=production:berlin. The same key may not be assigned
more than one distinct value: role=webserver:role=database is refused (but a
key may coexist with the corresponding unparameterized tag, e.g.
role:role=webserver).
The configured tags may be matched against with the
ConditionMachineTag= and AssertMachineTag= unit settings, see
systemd.unit(5) for details. They may be queried and changed with the
tags command of hostnamectl(1).
Added in version 261.
.RE
.PP HARDWARE_VENDOR=
Specifies the hardware vendor. If unspecified, the hardware vendor set in DMI
or hwdb(7) will be used.
Added in version 251.
.RE
.PP HARDWARE_MODEL=
Specifies the hardware model. If unspecified, the hardware model set in DMI
or hwdb(7) will be used.
Added in version 251.
.RE
.PP HARDWARE_SKU=
Specifies the hardware SKU (Stock-Keeping Unit). If unspecified, the hardware
SKU set in DMI will be used.
Added in version 258.
.RE
.PP HARDWARE_VERSION=
Specifies the hardware version. If unspecified, the hardware version set in
DMI will be used.
Added in version 258.
.RE
.SS "Custom Fields"
.PP Operating system vendors and systemd administrators may extend the file
format and introduce new fields. It is highly recommended to prefix new
fields with an OS-specific name in order to avoid name clashes. Applications
reading this file must ignore unknown fields.
.PP Example: _LOCAL_EMERGENCY_CONTACT="user@example.org".
.SH "EXAMPLE"
PRETTY_HOSTNAME="Lennart's Tablet" ICON_NAME=computer-tablet CHASSIS=tablet DEPLOYMENT=production TAGS=demo:berlin:role=webserver
.SH "SEE ALSO"
.PP systemd(1), os-release(5), hostname(5),
machine-id(5), hostnamectl(1),
systemd-hostnamed.service(8)
NOTES
- 1.
- XDG Icon Naming Specification
| systemd 262.2 |