mirror of
https://github.com/systemd/systemd.git
synced 2024-12-26 03:22:00 +03:00
210 lines
10 KiB
XML
210 lines
10 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-or-later -->
|
|
|
|
<refentry id="systemd-sysusers"
|
|
xmlns:xi="http://www.w3.org/2001/XInclude">
|
|
|
|
<refentryinfo>
|
|
<title>systemd-sysusers</title>
|
|
<productname>systemd</productname>
|
|
</refentryinfo>
|
|
|
|
<refmeta>
|
|
<refentrytitle>systemd-sysusers</refentrytitle>
|
|
<manvolnum>8</manvolnum>
|
|
</refmeta>
|
|
|
|
<refnamediv>
|
|
<refname>systemd-sysusers</refname>
|
|
<refname>systemd-sysusers.service</refname>
|
|
<refpurpose>Allocate system users and groups</refpurpose>
|
|
</refnamediv>
|
|
|
|
<refsynopsisdiv>
|
|
<cmdsynopsis>
|
|
<command>systemd-sysusers</command>
|
|
<arg choice="opt" rep="repeat">OPTIONS</arg>
|
|
<arg choice="opt" rep="repeat"><replaceable>CONFIGFILE</replaceable></arg>
|
|
</cmdsynopsis>
|
|
|
|
<para><filename>systemd-sysusers.service</filename></para>
|
|
</refsynopsisdiv>
|
|
|
|
<refsect1>
|
|
<title>Description</title>
|
|
|
|
<para><command>systemd-sysusers</command> creates system users and
|
|
groups, based on the file format and location specified in
|
|
<citerefentry><refentrytitle>sysusers.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
|
|
</para>
|
|
|
|
<para>If invoked with no arguments, it applies all directives from all files
|
|
found in the directories specified by
|
|
<citerefentry><refentrytitle>sysusers.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>.
|
|
When invoked with positional arguments, if option
|
|
<option>--replace=<replaceable>PATH</replaceable></option> is specified, arguments
|
|
specified on the command line are used instead of the configuration file
|
|
<replaceable>PATH</replaceable>. Otherwise, just the configuration specified by
|
|
the command line arguments is executed. The string <literal>-</literal> may be
|
|
specified instead of a filename to instruct <command>systemd-sysusers</command>
|
|
to read the configuration from standard input. If only the basename of a file is
|
|
specified, all configuration directories are searched for a matching file and
|
|
the file found that has the highest priority is executed.</para>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Options</title>
|
|
|
|
<para>The following options are understood:</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><option>--root=<replaceable>root</replaceable></option></term>
|
|
<listitem><para>Takes a directory path as an argument. All
|
|
paths will be prefixed with the given alternate
|
|
<replaceable>root</replaceable> path, including config search
|
|
paths. </para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--image=<replaceable>image</replaceable></option></term>
|
|
|
|
<listitem><para>Takes a path to a disk image file or block device node. If specified all operations
|
|
are applied to file system in the indicated disk image. This is similar to <option>--root=</option>
|
|
but operates on file systems stored in disk images or block devices. The disk image should either
|
|
contain just a file system or a set of file systems within a GPT partition table, following the
|
|
<ulink url="https://systemd.io/DISCOVERABLE_PARTITIONS">Discoverable Partitions
|
|
Specification</ulink>. For further information on supported disk images, see
|
|
<citerefentry><refentrytitle>systemd-nspawn</refentrytitle><manvolnum>1</manvolnum></citerefentry>'s
|
|
switch of the same name.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--replace=<replaceable>PATH</replaceable></option></term>
|
|
<listitem><para>When this option is given, one or more positional arguments
|
|
must be specified. All configuration files found in the directories listed in
|
|
<citerefentry><refentrytitle>sysusers.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>
|
|
will be read, and the configuration given on the command line will be
|
|
handled instead of and with the same priority as the configuration file
|
|
<replaceable>PATH</replaceable>.</para>
|
|
|
|
<para>This option is intended to be used when package installation scripts
|
|
are running and files belonging to that package are not yet available on
|
|
disk, so their contents must be given on the command line, but the admin
|
|
configuration might already exist and should be given higher priority.
|
|
</para>
|
|
|
|
<example>
|
|
<title>RPM installation script for radvd</title>
|
|
|
|
<programlisting>echo 'u radvd - "radvd daemon"' | \
|
|
systemd-sysusers --replace=/usr/lib/sysusers.d/radvd.conf -</programlisting>
|
|
|
|
<para>This will create the radvd user as if
|
|
<filename>/usr/lib/sysusers.d/radvd.conf</filename> was already on disk.
|
|
An admin might override the configuration specified on the command line by
|
|
placing <filename>/etc/sysusers.d/radvd.conf</filename> or even
|
|
<filename>/etc/sysusers.d/00-overrides.conf</filename>.</para>
|
|
|
|
<para>Note that this is the expanded form, and when used in a package, this
|
|
would be written using a macro with "radvd" and a file containing the
|
|
configuration line as arguments.</para>
|
|
</example>
|
|
</listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--dry-run</option></term>
|
|
<listitem><para>Process the configuration and figure out what entries would be created, but don't
|
|
actually write anything.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><option>--inline</option></term>
|
|
<listitem><para>Treat each positional argument as a separate configuration
|
|
line instead of a file name.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<xi:include href="standard-options.xml" xpointer="cat-config" />
|
|
<xi:include href="standard-options.xml" xpointer="no-pager" />
|
|
<xi:include href="standard-options.xml" xpointer="help" />
|
|
<xi:include href="standard-options.xml" xpointer="version" />
|
|
</variablelist>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Credentials</title>
|
|
|
|
<para><command>systemd-sysusers</command> supports the service credentials logic as implemented by
|
|
<varname>LoadCredential=</varname>/<varname>SetCredential=</varname> (see
|
|
<citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>1</manvolnum></citerefentry> for
|
|
details). The following credentials are used when passed in:</para>
|
|
|
|
<variablelist>
|
|
<varlistentry>
|
|
<term><literal>passwd.hashed-password.<replaceable>user</replaceable></literal></term>
|
|
<listitem><para>A UNIX hashed password string to use for the specified user, when creating an entry
|
|
for it. This is particularly useful for the <literal>root</literal> user as it allows provisioning
|
|
the default root password to use via a unit file drop-in or from a container manager passing in this
|
|
credential. Note that setting this credential has no effect if the specified user account already
|
|
exists. This credential is hence primarily useful in first boot scenarios or systems that are fully
|
|
stateless and come up with an empty <filename>/etc/</filename> on every boot.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><literal>passwd.plaintext-password.<replaceable>user</replaceable></literal></term>
|
|
|
|
<listitem><para>Similar to <literal>passwd.hashed-password.<replaceable>user</replaceable></literal>
|
|
but expect a literal, plaintext password, which is then automatically hashed before used for the user
|
|
account. If both the hashed and the plaintext credential are specified for the same user the
|
|
former takes precedence. It's generally recommended to specify the hashed version; however in test
|
|
environments with weaker requirements on security it might be easier to pass passwords in plaintext
|
|
instead.</para></listitem>
|
|
</varlistentry>
|
|
|
|
<varlistentry>
|
|
<term><literal>passwd.shell.<replaceable>user</replaceable></literal></term>
|
|
|
|
<listitem><para>Specifies the shell binary to use for the specified account when creating it.</para></listitem>
|
|
</varlistentry>
|
|
</variablelist>
|
|
|
|
<para>Note that by default the <filename>systemd-sysusers.service</filename> unit file is set up to
|
|
inherit the <literal>passwd.hashed-password.root</literal>,
|
|
<literal>passwd.plaintext-password.root</literal> and <literal>passwd.shell.root</literal> credentials
|
|
from the service manager. Thus, when invoking a container with an unpopulated <filename>/etc/</filename>
|
|
for the first time it is possible to configure the root user's password to be <literal>systemd</literal>
|
|
like this:</para>
|
|
|
|
<para><programlisting># systemd-nspawn --image=… --set-credential=passwd.hashed-password.root:'$y$j9T$yAuRJu1o5HioZAGDYPU5d.$F64ni6J2y2nNQve90M/p0ZP0ECP/qqzipNyaY9fjGpC' …</programlisting></para>
|
|
|
|
<para>Note again that the data specified in these credentials is consulted only when creating an account
|
|
for the first time, it may not be used for changing the password or shell of an account that already
|
|
exists.</para>
|
|
|
|
<para>Use <citerefentry><refentrytitle>mkpasswd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
|
for generating UNIX password hashes from the command line.</para>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>Exit status</title>
|
|
|
|
<para>On success, 0 is returned, a non-zero failure code
|
|
otherwise.</para>
|
|
</refsect1>
|
|
|
|
<refsect1>
|
|
<title>See Also</title>
|
|
<para>
|
|
<citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
|
|
<citerefentry><refentrytitle>sysusers.d</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
|
|
<ulink url="https://systemd.io/UIDS-GIDS">Users, Groups, UIDs and GIDs on systemd systems</ulink>,
|
|
<citerefentry><refentrytitle>systemd.exec</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
|
|
<citerefentry><refentrytitle>mkpasswd</refentrytitle><manvolnum>1</manvolnum></citerefentry>
|
|
</para>
|
|
</refsect1>
|
|
|
|
</refentry>
|