1
0
mirror of https://github.com/systemd/systemd.git synced 2024-12-23 21:35:11 +03:00
systemd/man/nss-myhostname.xml
Lennart Poettering 38ccb55731 nss-mymachines: drop support for UID/GID resolving
Now that we make the user/group name resolving available via userdb and
thus nss-systemd, we do not need the UID/GID resolving support in
nss-mymachines anymore. Let's drop it hence.

We keep the module around, since besides UID/GID resolving it also does
hostname resolving, which we care about. (One of those days we should
replace that by some Varlink logic between
nss-resolve/systemd-resolved.service too)

The hooks are kept in the NSS module, but they do not resolve anything
anymore, in order to keep compat at a maximum.
2020-07-14 17:08:12 +02:00

129 lines
5.5 KiB
XML

<?xml version='1.0'?> <!--*-nxml-*-->
<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN"
"http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
<!-- SPDX-License-Identifier: LGPL-2.1+ -->
<refentry id="nss-myhostname" conditional='ENABLE_NSS_MYHOSTNAME'>
<refentryinfo>
<title>nss-myhostname</title>
<productname>systemd</productname>
</refentryinfo>
<refmeta>
<refentrytitle>nss-myhostname</refentrytitle>
<manvolnum>8</manvolnum>
</refmeta>
<refnamediv>
<refname>nss-myhostname</refname>
<refname>libnss_myhostname.so.2</refname>
<refpurpose>Hostname resolution for the locally configured system hostname</refpurpose>
</refnamediv>
<refsynopsisdiv>
<para><filename>libnss_myhostname.so.2</filename></para>
</refsynopsisdiv>
<refsect1>
<title>Description</title>
<para><command>nss-myhostname</command> is a plug-in module for the GNU Name Service Switch (NSS) functionality of
the GNU C Library (<command>glibc</command>), primarily providing hostname resolution for the locally configured
system hostname as returned by
<citerefentry><refentrytitle>gethostname</refentrytitle><manvolnum>2</manvolnum></citerefentry>. The precise
hostnames resolved by this module are:</para>
<itemizedlist>
<listitem><para>The local, configured hostname is resolved to
all locally configured IP addresses ordered by their scope, or
— if none are configured — the IPv4 address 127.0.0.2 (which
is on the local loopback) and the IPv6 address ::1 (which is the
local host).</para></listitem>
<listitem><para>The hostnames <literal>localhost</literal> and
<literal>localhost.localdomain</literal> (as well as any hostname
ending in <literal>.localhost</literal> or <literal>.localhost.localdomain</literal>)
are resolved to the IP addresses 127.0.0.1 and ::1.</para></listitem>
<listitem><para>The hostname <literal>_gateway</literal> is
resolved to all current default routing gateway addresses,
ordered by their metric. This assigns a stable hostname to the
current gateway, useful for referencing it independently of the
current network configuration state.</para></listitem>
</itemizedlist>
<para>Various software relies on an always-resolvable local
hostname. When using dynamic hostnames, this is traditionally
achieved by patching <filename>/etc/hosts</filename> at the same
time as changing the hostname. This is problematic since it
requires a writable <filename>/etc</filename> file system and is
fragile because the file might be edited by the administrator at
the same time. With <command>nss-myhostname</command> enabled,
changing <filename>/etc/hosts</filename> is unnecessary, and on
many systems, the file becomes entirely optional.</para>
<para>To activate the NSS modules, add <literal>myhostname</literal> to the line starting with
<literal>hosts:</literal> in <filename>/etc/nsswitch.conf</filename>.</para>
<para>It is recommended to place <literal>myhostname</literal> either between <literal>resolve</literal>
and "traditional" modules like <literal>files</literal> and <literal>dns</literal>, or after them. In the
first version, well-known names like <literal>localhost</literal> and the machine hostname are given
higher priority than the external configuration. This is recommended when the external DNS servers and
network are not absolutely trusted. In the second version, external configuration is given higher
priority and <command>nss-myhostname</command> only provides a fallback mechanism. This might be suitable
in closely controlled networks, for example on a company LAN.</para>
</refsect1>
<refsect1>
<title>Example</title>
<para>Here is an example <filename>/etc/nsswitch.conf</filename> file that enables
<command>nss-myhostname</command> correctly:</para>
<!-- synchronize with other nss-* man pages and factory/etc/nsswitch.conf -->
<programlisting>passwd: compat systemd
group: compat systemd
shadow: compat
# Either (untrusted network):
hosts: mymachines resolve [!UNAVAIL=return] <command>myhostname</command> files dns
# Or (only trusted networks):
hosts: mymachines resolve [!UNAVAIL=return] files dns <command>myhostname</command>
networks: files
protocols: db files
services: db files
ethers: db files
rpc: db files
netgroup: nis</programlisting>
<para>To test, use <command>glibc</command>'s <command>getent</command> tool:</para>
<programlisting>$ getent ahosts `hostname`
::1 STREAM omega
::1 DGRAM
::1 RAW
127.0.0.2 STREAM
127.0.0.2 DGRAM
127.0.0.2 RAW</programlisting>
<para>In this case, the local hostname is <varname>omega</varname>.</para>
</refsect1>
<refsect1>
<title>See Also</title>
<para>
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
<citerefentry><refentrytitle>nss-systemd</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
<citerefentry><refentrytitle>nss-resolve</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
<citerefentry><refentrytitle>nss-mymachines</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
<citerefentry project='man-pages'><refentrytitle>nsswitch.conf</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
<citerefentry project='man-pages'><refentrytitle>getent</refentrytitle><manvolnum>1</manvolnum></citerefentry>
</para>
</refsect1>
</refentry>