]> git.ipfire.org Git - thirdparty/systemd.git/blobdiff - man/systemd-cryptsetup-generator.xml
Merge pull request #18214 from elmarco/vsock
[thirdparty/systemd.git] / man / systemd-cryptsetup-generator.xml
index 1974cd7a2d134b3336b70e5b77431cf99fc295ed..e5c193f6920069b766e4aeb1309bdfc830afe4f3 100644 (file)
@@ -1,38 +1,13 @@
 <?xml version="1.0"?>
 <!--*-nxml-*-->
-<!DOCTYPE refentry PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN" "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
-<!--
-  This file is part of systemd.
-
-  Copyright 2012 Lennart Poettering
-
-  systemd is free software; you can redistribute it and/or modify it
-  under the terms of the GNU Lesser General Public License as published by
-  the Free Software Foundation; either version 2.1 of the License, or
-  (at your option) any later version.
-
-  systemd is distributed in the hope that it will be useful, but
-  WITHOUT ANY WARRANTY; without even the implied warranty of
-  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
-  Lesser General Public License for more details.
-
-  You should have received a copy of the GNU Lesser General Public License
-  along with systemd; If not, see <http://www.gnu.org/licenses/>.
--->
+<!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-cryptsetup-generator" conditional='HAVE_LIBCRYPTSETUP'>
 
   <refentryinfo>
     <title>systemd-cryptsetup-generator</title>
     <productname>systemd</productname>
-
-    <authorgroup>
-      <author>
-        <contrib>Developer</contrib>
-        <firstname>Lennart</firstname>
-        <surname>Poettering</surname>
-        <email>lennart@poettering.net</email>
-      </author>
-    </authorgroup>
   </refentryinfo>
 
   <refmeta>
         system and the initrd.</para>
         <para>If /etc/crypttab contains entries with the same UUID,
         then the name, keyfile and options specified there will be
-        used. Otherwise the device will have the name
+        used. Otherwise, the device will have the name
         <literal>luks-UUID</literal>.</para>
         <para>If /etc/crypttab exists, only those UUIDs
         specified on the kernel command line
         LUKS device given by the UUID appear under the provided
         name.</para>
 
+        <para>This parameter is the analogue of the first <citerefentry><refentrytitle>crypttab</refentrytitle>
+        <manvolnum>5</manvolnum></citerefentry> field <replaceable>volume-name</replaceable>.</para>
+
         <para><varname>rd.luks.name=</varname> is honored only by
         initial RAM disk (initrd) while <varname>luks.name=</varname>
         is honored by both the main system and the initrd.</para>
       </varlistentry>
 
       <varlistentry>
-        <term><varname>luks.options=</varname></term>
-        <term><varname>rd.luks.options=</varname></term>
-
-        <listitem><para>Takes a LUKS super block UUID followed by an
-        <literal>=</literal> and a string of options separated by
-        commas as argument. This will override the options for the
-        given UUID.</para>
-        <para>If only a list of options, without an UUID, is
-        specified, they apply to any UUIDs not specified elsewhere,
-        and without an entry in
-        <filename>/etc/crypttab</filename>.</para><para>
-        <varname>rd.luks.options=</varname> is honored only by initial
-        RAM disk (initrd) while <varname>luks.options=</varname> is
-        honored by both the main system and the initrd.</para>
+        <term><varname>luks.data=</varname></term>
+        <term><varname>rd.luks.data=</varname></term>
+
+        <listitem><para>Takes a LUKS super block UUID followed by a <literal>=</literal> and a block device
+        specification for device hosting encrypted data.</para>
+
+        <para>For those entries specified with <varname>rd.luks.uuid=</varname> or
+        <varname>luks.uuid=</varname>, the data device will be set to the one specified by
+        <varname>rd.luks.data=</varname> or <varname>luks.data=</varname> of the corresponding UUID.</para>
+
+        <para>LUKS data device parameter is useful for specifying encrypted data devices with detached headers specified in
+        <varname>luks.options</varname> entry containing <literal>header=</literal> argument. For example,
+        <varname>rd.luks.uuid=</varname>b40f1abf-2a53-400a-889a-2eccc27eaa40
+        <varname>rd.luks.options=</varname>b40f1abf-2a53-400a-889a-2eccc27eaa40=header=/path/to/luks.hdr
+        <varname>rd.luks.data=</varname>b40f1abf-2a53-400a-889a-2eccc27eaa40=/dev/sdx.
+        Hence, in this case, we will attempt to unlock LUKS device assembled from data device <literal>/dev/sdx</literal>
+        and LUKS header (metadata) put in <literal>/path/to/luks.hdr</literal> file. This syntax is for now
+        only supported on a per-device basis, i.e. you have to specify LUKS device UUID.</para>
+
+        <para>This parameter is the analogue of the second <citerefentry><refentrytitle>crypttab</refentrytitle>
+        <manvolnum>5</manvolnum></citerefentry> field <replaceable>encrypted-device</replaceable>.</para>
+
+        <para><varname>rd.luks.data=</varname> is honored only by initial RAM disk (initrd) while
+        <varname>luks.data=</varname> is honored by both the main system and the initrd.</para>
         </listitem>
       </varlistentry>
 
         to the one specified by <varname>rd.luks.key=</varname> or
         <varname>luks.key=</varname> of the corresponding UUID, or the
         password file that was specified without a UUID.</para>
+
+        <para>It is also possible to specify an external device which
+        should be mounted before we attempt to unlock the LUKS device.
+        systemd-cryptsetup will use password file stored on that
+        device. Device containing password file is specified by
+        appending colon and a device identifier to the password file
+        path. For example,
+        <varname>rd.luks.uuid=</varname>b40f1abf-2a53-400a-889a-2eccc27eaa40
+        <varname>rd.luks.key=</varname>b40f1abf-2a53-400a-889a-2eccc27eaa40=/keyfile:LABEL=keydev.
+        Hence, in this case, we will attempt to mount file system
+        residing on the block device with label <literal>keydev</literal>.
+        This syntax is for now only supported on a per-device basis,
+        i.e. you have to specify LUKS device UUID.</para>
+
+        <para>This parameter is the analogue of the third <citerefentry><refentrytitle>crypttab</refentrytitle>
+        <manvolnum>5</manvolnum></citerefentry> field <replaceable>key-file</replaceable>.</para>
+
         <para><varname>rd.luks.key=</varname>
         is honored only by initial RAM disk
         (initrd) while
         the initrd.</para>
         </listitem>
       </varlistentry>
+
+      <varlistentry>
+        <term><varname>luks.options=</varname></term>
+        <term><varname>rd.luks.options=</varname></term>
+
+        <listitem><para>Takes a LUKS super block UUID followed by an
+        <literal>=</literal> and a string of options separated by
+        commas as argument. This will override the options for the
+        given UUID.</para>
+        <para>If only a list of options, without an UUID, is
+        specified, they apply to any UUIDs not specified elsewhere,
+        and without an entry in
+        <filename>/etc/crypttab</filename>.</para>
+
+        <para>This parameter is the analogue of the fourth <citerefentry><refentrytitle>crypttab</refentrytitle>
+        <manvolnum>5</manvolnum></citerefentry> field <replaceable>options</replaceable>.</para>
+
+        <para>It is possible to specify an external device which
+        should be mounted before we attempt to unlock the LUKS device.
+        systemd-cryptsetup will assemble LUKS device by combining
+        data device specified in <varname>luks.data</varname> with
+        detached LUKS header found in <literal>header=</literal>
+        argument. For example,
+        <varname>rd.luks.uuid=</varname>b40f1abf-2a53-400a-889a-2eccc27eaa40
+        <varname>rd.luks.options=</varname>b40f1abf-2a53-400a-889a-2eccc27eaa40=header=/luks.hdr:LABEL=hdrdev
+        <varname>rd.luks.data=</varname>b40f1abf-2a53-400a-889a-2eccc27eaa40=/dev/sdx.
+        Hence, in this case, we will attempt to mount file system
+        residing on the block device with label <literal>hdrdev</literal>, and look
+        for <literal>luks.hdr</literal> on that file system. Said header will be used
+        to unlock (decrypt) encrypted data stored on /dev/sdx.
+        This syntax is for now only supported on a per-device basis,
+        i.e. you have to specify LUKS device UUID.</para>
+
+        <para><varname>rd.luks.options=</varname> is honored only by initial
+        RAM disk (initrd) while <varname>luks.options=</varname> is
+        honored by both the main system and the initrd.</para>
+        </listitem>
+      </varlistentry>
     </variablelist>
   </refsect1>
 
       <citerefentry><refentrytitle>systemd</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
       <citerefentry><refentrytitle>crypttab</refentrytitle><manvolnum>5</manvolnum></citerefentry>,
       <citerefentry><refentrytitle>systemd-cryptsetup@.service</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
-      <citerefentry><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
+      <citerefentry><refentrytitle>systemd-cryptenroll</refentrytitle><manvolnum>1</manvolnum></citerefentry>,
+      <citerefentry project='die-net'><refentrytitle>cryptsetup</refentrytitle><manvolnum>8</manvolnum></citerefentry>,
       <citerefentry><refentrytitle>systemd-fstab-generator</refentrytitle><manvolnum>8</manvolnum></citerefentry>
     </para>
   </refsect1>