mirrors/systemd
0
0
Fork 0
mirror of https://github.com/systemd/systemd.git synced 2024-12-03 15:23:36 +08:00
Code Issues Packages Projects Releases Wiki Activity
55e40b0be8
systemd/man/machine-info.xml

182 lines
7.2 KiB
XML
Raw Normal View History

hostnamed: introduce systemd-hostnamed http://www.freedesktop.org/wiki/Software/systemd/hostnamed
2011-04-16 08:02:54 +08:00
<?xml version='1.0'?> <!--*-nxml-*-->
man: use same header for all files The "include" files had type "book" for some raeason. I don't think this is meaningful. Let's just use the same everywhere. $ perl -i -0pe 's^..DOCTYPE (book|refentry) PUBLIC "-//OASIS//DTD DocBook XML V4.[25]//EN"\s+"http^<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"\n "http^gms' man/*.xml
2019-03-14 21:40:58 +08:00
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
man: revert dynamic paths for split-usr setups This did not really work out as we had hoped. Trying to do this upstream introduced several problems that probably makes it better suited as a downstream patch after all. At any rate, it is not releaseable in the current state, so we at least need to revert this before the release. * by adjusting the path to binaries, but not do the same thing to the search path we end up with inconsistent man-pages. Adjusting the search path too would be quite messy, and it is not at all obvious that this is worth the effort, but at any rate it would have to be done before we could ship this. * this means that distributed man-pages does not make sense as they depend on config options, and for better or worse we are still distributing man pages, so that is something that definitely needs sorting out before we could ship with this patch. * we have long held that split-usr is only minimally supported in order to boot, and something we hope will eventually go away. So before we start adding even more magic/effort in order to make this work nicely, we should probably question if it makes sense at all.
2015-06-19 01:47:44 +08:00
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
license: LGPL-2.1+ -> LGPL-2.1-or-later
2020-11-09 12:23:58 +08:00
<!-- SPDX-License-Identifier: LGPL-2.1-or-later -->
hostnamed: introduce systemd-hostnamed http://www.freedesktop.org/wiki/Software/systemd/hostnamed
2011-04-16 08:02:54 +08:00
man: Add xinclude namespace This will be used by the next commit to add version information to the nodes.
2023-08-23 00:52:02 +08:00
<refentry id="machine-info" xmlns:xi="http://www.w3.org/2001/XInclude">
Reindent man pages to 2ch
2015-02-04 10:14:13 +08:00
<refentryinfo>
<title>machine-info</title>
<productname>systemd</productname>
</refentryinfo>
<refmeta>
<refentrytitle>machine-info</refentrytitle>
<manvolnum>5</manvolnum>
</refmeta>
<refnamediv>
<refname>machine-info</refname>
<refpurpose>Local machine information file</refpurpose>
</refnamediv>
<refsynopsisdiv>
<para><filename>/etc/machine-info</filename></para>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para>The <filename>/etc/machine-info</filename> file contains
machine metadata.</para>
man: refer to os-release(5) for description of files in the same format
2022-01-07 23:38:18 +08:00
<para>The format of <filename>machine-info</filename> 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
<citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry> for a
detailed description of the format.</para>
Reindent man pages to 2ch
2015-02-04 10:14:13 +08:00
man: say that machine-info doesn't have to exist Esp. CHASSIS is only useful as an override. Make that clear in the description. Fixes #3496.
2021-03-01 17:08:28 +08:00
<para><filename>/etc/machine-info</filename> 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.</para>
Reindent man pages to 2ch
2015-02-04 10:14:13 +08:00
<para>You may use
<citerefentry><refentrytitle>hostnamectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>
to change the settings of this file from the command line.</para>
</refsect1>
<refsect1>
<title>Options</title>
<para>The following machine metadata parameters may be set using
<filename>/etc/machine-info</filename>:</para>
man: move os-release, machine-info, vconsole.conf vars to envvar section Strictly speaking, those are not environment variables, but they are compatible and people think about them like this. Moving them makes them easier to find.
2019-02-13 17:36:26 +08:00
<variablelist class='environment-variables'>
Reindent man pages to 2ch
2015-02-04 10:14:13 +08:00
<varlistentry>
<term><varname>PRETTY_HOSTNAME=</varname></term>
<listitem><para>A pretty human-readable UTF-8 machine
identifier string. This should contain a name like
<literal>Lennart's Laptop</literal> 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 <filename>/etc/hostname</filename> should be
kept similar to this one. Example: if this value is
<literal>Lennart's Computer</literal> an Internet hostname of
<literal>lennarts-computer</literal> might be a good choice.
If this parameter is not set, an application should fall back
tree-wide: use "hostname" spelling everywhere It's not that I think that "hostname" is vastly superior to "host name". Quite the opposite — the difference is small, and in some context the two-word version does fit better. But in the tree, there are ~200 occurrences of the first, and >1600 of the other, and consistent spelling is more important than any particular spelling choice.
2020-04-14 16:37:40 +08:00
to the Internet hostname for presentation
Reindent man pages to 2ch
2015-02-04 10:14:13 +08:00
purposes.</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>ICON_NAME=</varname></term>
<listitem><para>An icon identifying this machine according to
the <ulink
Use https for freedesktop.org grep -l -r http:// | xargs sed -E -i s'#http://(.*).freedesktop.org#https://\1.freedesktop.org#'
2022-06-28 18:00:47 +08:00
url="https://standards.freedesktop.org/icon-naming-spec/icon-naming-spec-latest.html">XDG
Reindent man pages to 2ch
2015-02-04 10:14:13 +08:00
Icon Naming Specification</ulink>. If this parameter is not
set, an application should fall back to
<literal>computer</literal> or a similar icon
name.</para></listitem>
</varlistentry>
<varlistentry>
<term><varname>CHASSIS=</varname></term>
<listitem><para>The chassis type. Currently, the following
chassis types are defined:
<literal>desktop</literal>,
<literal>laptop</literal>,
hostname: add 'convertible' chassis type Add the 'convertible' type to the set of allowed chassis. This applies to all devices that can be transformed by the user from laptop style to tablet style. This does not add any auto-detection, yet. It only makes 'set-chassis' accept 'convertible' as valid input.
2017-02-28 18:54:52 +08:00
<literal>convertible</literal>,
Reindent man pages to 2ch
2015-02-04 10:14:13 +08:00
<literal>server</literal>,
<literal>tablet</literal>,
<literal>handset</literal>,
<literal>watch</literal>, and
doc: correct punctuation and improve typography in documentation
2014-08-03 13:11:12 +08:00
<literal>embedded</literal>,
Reindent man pages to 2ch
2015-02-04 10:14:13 +08:00
as well as the special chassis types
<literal>vm</literal> and
<literal>container</literal> for
man: say that machine-info doesn't have to exist Esp. CHASSIS is only useful as an override. Make that clear in the description. Fixes #3496.
2021-03-01 17:08:28 +08:00
virtualized systems that lack an immediate physical chassis.</para>
<para>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
man: add version info This tries to add information about when each option was added. It goes back to version 183. The version info is included from a separate file to allow generating it, which would allow more control on the formatting of the final output.
2023-08-23 00:52:36 +08:00
configure the chassis type where automatic detection is not available.</para>
<xi:include href="version-info.xml" xpointer="v197"/></listitem>
Reindent man pages to 2ch
2015-02-04 10:14:13 +08:00
</varlistentry>
<varlistentry>
<term><varname>DEPLOYMENT=</varname></term>
<listitem><para>Describes the system deployment environment.
One of the following is suggested:
<literal>development</literal>,
<literal>integration</literal>,
<literal>staging</literal>,
<literal>production</literal>.
man: add version info This tries to add information about when each option was added. It goes back to version 183. The version info is included from a separate file to allow generating it, which would allow more control on the formatting of the final output.
2023-08-23 00:52:36 +08:00
</para>
<xi:include href="version-info.xml" xpointer="v216"/></listitem>
Reindent man pages to 2ch
2015-02-04 10:14:13 +08:00
</varlistentry>
<varlistentry>
<term><varname>LOCATION=</varname></term>
<listitem><para>Describes the system location if applicable
and known. Takes a human-friendly, free-form string. This may
be as generic as <literal>Berlin, Germany</literal> or as
specific as <literal>Left Rack, 2nd Shelf</literal>.
man: add version info This tries to add information about when each option was added. It goes back to version 183. The version info is included from a separate file to allow generating it, which would allow more control on the formatting of the final output.
2023-08-23 00:52:36 +08:00
</para>
<xi:include href="version-info.xml" xpointer="v216"/></listitem>
Reindent man pages to 2ch
2015-02-04 10:14:13 +08:00
</varlistentry>
kernel-install: Introduce KERNEL_INSTALL_MACHINE_ID in /etc/machine-info If KERNEL_INSTALL_MACHINE_ID is defined in /etc/machine-info, prefer it over the machine ID from /etc/machine-id. If a machine ID is defined in neither /etc/machine-info nor in /etc/machine-id, generate a new UUID and try to write it to /etc/machine-info as KERNEL_INSTALL_MACHINE_ID and use it as the machine ID if writing it to /etc/machine-info succeeds. In practice, this means we have a more robust fallback if there's no machine ID in /etc/machine-id than just using "Default" and allows image builders to force kernel-install to use KERNEL_INSTALL_MACHINE_ID by simply writing it to /etc/machine-info themselves.
2021-12-15 00:09:08 +08:00
hostname: allow to override hardware vendor and model Sometimes hardware vendor does not set DMI info correctly. Already there is a way that the dbus properties can be overriden by using hwdb. But that is not user friendly. This adds two new fields in /etc/machine-info. Closes #22207.
2022-01-22 09:44:50 +08:00
<varlistentry>
machine-info: rename VENDOR=/MODEL= → HARDWARE_VENDOR=/HARDWARE_MODEL= Let's be more precise here. Otherwise people might think this describes the software system or so. We already expose this via hostnamed as HardwareVendor/HardwareModel hence use the exact same wording. (Note that the relevant props on the dmi device are just VENDOR/MODEL, but that's OK given that DMI really is about hardware anyway, unconditionally, hence no chance of confusion there.) Follow-up for 4fc7e4f374bf4401330e90e267227267abf1dcac
2022-03-25 00:48:11 +08:00
<term><varname>HARDWARE_VENDOR=</varname></term>
hostname: allow to override hardware vendor and model Sometimes hardware vendor does not set DMI info correctly. Already there is a way that the dbus properties can be overriden by using hwdb. But that is not user friendly. This adds two new fields in /etc/machine-info. Closes #22207.
2022-01-22 09:44:50 +08:00
machine-info: rename VENDOR=/MODEL= → HARDWARE_VENDOR=/HARDWARE_MODEL= Let's be more precise here. Otherwise people might think this describes the software system or so. We already expose this via hostnamed as HardwareVendor/HardwareModel hence use the exact same wording. (Note that the relevant props on the dmi device are just VENDOR/MODEL, but that's OK given that DMI really is about hardware anyway, unconditionally, hence no chance of confusion there.) Follow-up for 4fc7e4f374bf4401330e90e267227267abf1dcac
2022-03-25 00:48:11 +08:00
<listitem><para>Specifies the hardware vendor. If unspecified, the hardware vendor set in DMI or
<citerefentry><refentrytitle>hwdb</refentrytitle><manvolnum>7</manvolnum></citerefentry> will be
man: add version info This tries to add information about when each option was added. It goes back to version 183. The version info is included from a separate file to allow generating it, which would allow more control on the formatting of the final output.
2023-08-23 00:52:36 +08:00
used.</para>
<xi:include href="version-info.xml" xpointer="v251"/></listitem>
hostname: allow to override hardware vendor and model Sometimes hardware vendor does not set DMI info correctly. Already there is a way that the dbus properties can be overriden by using hwdb. But that is not user friendly. This adds two new fields in /etc/machine-info. Closes #22207.
2022-01-22 09:44:50 +08:00
</varlistentry>
<varlistentry>
machine-info: rename VENDOR=/MODEL= → HARDWARE_VENDOR=/HARDWARE_MODEL= Let's be more precise here. Otherwise people might think this describes the software system or so. We already expose this via hostnamed as HardwareVendor/HardwareModel hence use the exact same wording. (Note that the relevant props on the dmi device are just VENDOR/MODEL, but that's OK given that DMI really is about hardware anyway, unconditionally, hence no chance of confusion there.) Follow-up for 4fc7e4f374bf4401330e90e267227267abf1dcac
2022-03-25 00:48:11 +08:00
<term><varname>HARDWARE_MODEL=</varname></term>
hostname: allow to override hardware vendor and model Sometimes hardware vendor does not set DMI info correctly. Already there is a way that the dbus properties can be overriden by using hwdb. But that is not user friendly. This adds two new fields in /etc/machine-info. Closes #22207.
2022-01-22 09:44:50 +08:00
<listitem><para>Specifies the hardware model. If unspecified, the hardware model set in DMI or
machine-info: rename VENDOR=/MODEL= → HARDWARE_VENDOR=/HARDWARE_MODEL= Let's be more precise here. Otherwise people might think this describes the software system or so. We already expose this via hostnamed as HardwareVendor/HardwareModel hence use the exact same wording. (Note that the relevant props on the dmi device are just VENDOR/MODEL, but that's OK given that DMI really is about hardware anyway, unconditionally, hence no chance of confusion there.) Follow-up for 4fc7e4f374bf4401330e90e267227267abf1dcac
2022-03-25 00:48:11 +08:00
<citerefentry><refentrytitle>hwdb</refentrytitle><manvolnum>7</manvolnum></citerefentry> will be
man: add version info This tries to add information about when each option was added. It goes back to version 183. The version info is included from a separate file to allow generating it, which would allow more control on the formatting of the final output.
2023-08-23 00:52:36 +08:00
used.</para>
<xi:include href="version-info.xml" xpointer="v251"/></listitem>
hostname: allow to override hardware vendor and model Sometimes hardware vendor does not set DMI info correctly. Already there is a way that the dbus properties can be overriden by using hwdb. But that is not user friendly. This adds two new fields in /etc/machine-info. Closes #22207.
2022-01-22 09:44:50 +08:00
</varlistentry>
Reindent man pages to 2ch
2015-02-04 10:14:13 +08:00
</variablelist>
</refsect1>
<refsect1>
<title>Example</title>
<programlisting>PRETTY_HOSTNAME="Lennart's Tablet"
hostnamed: make chassis type configurable via /etc/machine-info For many usecases it is useful to store the chassis type somewhere, and /etc/machine-info sounds like a good place. Ideally we could always detect the chassis type from firmware, but frequently that's not available and in many embedded devices probably entirely unrealistic. This patch adds a configurable setting CHASSIS= to /etc/machine-info and exposes this via hostnamectl/hostnamed. hostnamed will guess the chassis type from DMI if nothing is set explicitly. I also added support for detecting it from ACPI, which should be more useful as ACPI 5.0 actually knows a "tablet" chassis type, which neither DMI nor previous ACPI versions knew. This also enables DMI-based and ACPI-based detection for non-x86 systems as ACPI is apparently coming to ARM platforms soon. I tried to minimize the vocabulary of chassis types understood and added: desktop, laptop, server, tablet, handset. This is much less than either APCI or DMI know. If we need more types later on we can easily add them.
2012-12-25 02:03:59 +08:00
ICON_NAME=computer-tablet
Add DEPLOYMENT to hostnamectl [zj: remove the check against a fixed list of environments.]
2014-07-09 05:26:05 +08:00
CHASSIS=tablet
DEPLOYMENT=production</programlisting>
Reindent man pages to 2ch
2015-02-04 10:14:13 +08:00
</refsect1>
<refsect1>
<title>See Also</title>
<para>
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
<citerefentry><refentrytitle>os-release</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
<citerefentry><refentrytitle>hostname</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
<citerefentry><refentrytitle>machine-id</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
<citerefentry><refentrytitle>hostnamectl</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
<citerefentry><refentrytitle>systemd-hostnamed.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>
</para>
</refsect1>
hostnamed: introduce systemd-hostnamed http://www.freedesktop.org/wiki/Software/systemd/hostnamed
2011-04-16 08:02:54 +08:00
</refentry>
Reference in New Issue Copy Permalink