en-US/DiskEncryptionUserGuide.xml en-US/Kickstart2.xml

Rüdiger Landmann rlandmann at fedoraproject.org
Fri Apr 30 05:32:17 UTC 2010


 en-US/DiskEncryptionUserGuide.xml |   74 ++++++++++++++++++++++++++------------
 en-US/Kickstart2.xml              |   43 ++++++++++++++++------
 2 files changed, 84 insertions(+), 33 deletions(-)

New commits:
commit 5b3dee0059d2028df3379d74079f311f60478d3e
Author: Ruediger Landmann <r.landmann at redhat.com>
Date:   Fri Apr 30 15:31:38 2010 +1000

    Update Kickstart

diff --git a/en-US/DiskEncryptionUserGuide.xml b/en-US/DiskEncryptionUserGuide.xml
index 05f649d..6a0b86b 100644
--- a/en-US/DiskEncryptionUserGuide.xml
+++ b/en-US/DiskEncryptionUserGuide.xml
@@ -2,11 +2,8 @@
 <!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
 
 <appendix id="Disk_Encryption_Guide">
-  <title>Disk Encryption Guide</title>
-  <!-- <note><title>Note</title>
-	  <para>Red Hat Enterprise Linux 5.3 now contains support during installation for file system encryption. This is not supported for earlier versions of Red Hat Enterprise Linux.
-	  </para>
-  </note> -->
+  <title>Disk Encryption</title>
+
     <section>
       <title>What is block device encryption? </title>
       <para> Block device encryption protects the data on a block device by encrypting it. To access the device's decrypted contents, a user must provide a passphrase or key as authentication. This provides additional security beyond existing OS security mechanisms in that it protects the device's contents even if it has been physically removed from the system.</para>
@@ -14,8 +11,8 @@
     <section>
       <title>Encrypting block devices using dm-crypt/LUKS </title>
       <para>
-	<ulink url="http://luks.endorphin.org"> LUKS</ulink> (Linux Unified Key Setup) is a specification for block device encryption. It establishes an on-disk format for the data, as well as a passphrase/key management policy.</para>
-      <para>LUKS uses the kernel device mapper subsystem via the <command>dm-crypt</command> module. This arrangement provides a low-level mapping that handles encryption and decryption of the device's data. User-level operations, such as creating and accessing encrypted devices, are accomplished through the use of the <command>cryptsetup</command> utility.
+	<firstterm>Linux Unified Key Setup</firstterm> (LUKS) is a specification for block device encryption. It establishes an on-disk format for the data, as well as a passphrase/key management policy.</para>
+      <para>LUKS uses the kernel device mapper subsystem via the <command>dm-crypt</command> module. This arrangement provides a low-level mapping that handles encryption and decryption of the device's data. User-level operations, such as creating and accessing encrypted devices, are accomplished through the use of the <command>cryptsetup</command> utility. 
       </para>
       <section>
 	<title>Overview of LUKS </title>
@@ -96,6 +93,9 @@
             </para>
 	  </listitem>
         </itemizedlist>
+        <para>
+		More detailed information about LUKS is available from the project website at <ulink url="http://code.google.com/p/cryptsetup/">http://code.google.com/p/cryptsetup/</ulink>.
+        </para>
       </section>
       <section>
 	<title>How will I access the encrypted devices after installation? (System Startup) </title>
@@ -143,21 +143,49 @@
 	  <para> In addition to passphrases, LUKS devices can be accessed with a key comprised of randomly generated data. Setting up one or more keys to access the encrypted devices can be done on the installed system or through the use of a <command>kickstart %post</command> script. Instructions can be found <xref linkend="new_key"/>.</para>
 	</section>
  	</section> -->
-	<section>
-		<title>Backing Up Passphrases</title>
+	<section id="Disk_Encryption_Guide-Saving_Passphrases">
+		<title>Saving Passphrases</title>
 		<indexterm significance="normal">
 			<primary>Encryption</primary>
-			<secondary>Backing up passphrases</secondary>
+			<secondary>Passphrases</secondary>
+			<tertiary>Saving passphrases</tertiary>
 		</indexterm>
 		<indexterm significance="normal">
 			<primary>Passphrases</primary>
-			<secondary>Backing up</secondary>
+			<secondary>Block device encryption passphrases</secondary>
+			<tertiary>Saving block device encryption passphrases</tertiary>
 		</indexterm>
 		<para>
-			If you use a kickstart file during installation, you can save the encryption keys to the block devices on the system and create backup passphrases for these devices. To use this feature, you must have an X.509 certificate available at a location that <application>anaconda</application>. To specify the URL of this certificate, add the  <parameter>--escrowcert</parameter> parameter to any of the <command>autopart</command>, <command>logvol</command>, <command>part</command> or <command>raid</command> commands. During installation, the encryption keys for the specified devices are saved in files in <filename>/</filename> (root), encrypted with the certificate. 
+			If you use a kickstart file during installation, you can automatically save the passphrases used during installation to an encrypted file on the local file system. To use this feature, you must have an X.509 certificate available at a location that <application>anaconda</application> can access. To specify the URL of this certificate, add the  <parameter>--escrowcert</parameter> parameter to any of the <command>autopart</command>, <command>logvol</command>, <command>part</command> or <command>raid</command> commands. During installation, the encryption keys for the specified devices are saved in files in <filename>/</filename> (root), encrypted with the certificate. 
 		</para>
 		<para>
-			If you add the  <parameter>--backuppassphrase</parameter> parameter too, <application>anaconda</application> adds a randomly-generated passphrase to each device. Again, each passphrase is stored in an encrypted form in <filename>/</filename> (root), encypted with the X.509 certificate. 
+			Note that this feature is available only while performing a kickstart installation. Refer to <xref linkend="ch-kickstart2"/> for more detail. 
+		</para>
+	</section>
+	<section id="Disk_Encryption_Guide-Creating_and_Saving_Backup_Passphrases">
+		<title>Creating and Saving Backup Passphrases</title>
+		<indexterm significance="normal">
+			<primary>Encryption</primary>
+			<secondary>Backup passphrases</secondary>
+			<tertiary>Creating backup passphrases</tertiary>
+		</indexterm>
+		<indexterm significance="normal">
+			<primary>Encryption</primary>
+			<secondary>Backup passphrases</secondary>
+			<tertiary>Saving backup passphrases</tertiary>
+		</indexterm>
+		<indexterm significance="normal">
+			<primary>Passphrases</primary>
+			<secondary>Block device encryption passphrases</secondary>
+			<tertiary>Creating backup block device encryption passphrases</tertiary>
+		</indexterm>
+		<indexterm significance="normal">
+			<primary>Passphrases</primary>
+			<secondary>Block device encryption passphrases</secondary>
+			<tertiary>Saving backup block device encryption passphrases</tertiary>
+		</indexterm>
+		<para>
+			If you use a kickstart file during installation, <application>anaconda</application> can add a randomly generated backup passphrase to each block device on the system and save each passphrase to an encrypted file on the local file system. Specify the URL of this certificate with the  <parameter>--escrowcert</parameter> parameter as described in <xref linkend="Disk_Encryption_Guide-Saving_Passphrases"/>, followed by the  <parameter>--backuppassphrase</parameter> parameter for each of the kickstart commands that relate to the devices for which you want to create backup passphrases.
 		</para>
 		<para>
 			Note that this feature is available only while performing a kickstart installation. Refer to <xref linkend="ch-kickstart2"/> for more detail. 
@@ -182,24 +210,25 @@
 		</para>
 		<itemizedlist>
 		<listitem>
-		<para> The best way, which provides high quality random data but takes a long time (several minutes per gigabyte on most systems):<programlisting>dd if=/dev/urandom of=&lt;device&gt;</programlisting>
-		</para>
+		<para> The best way, which provides high quality random data but takes a long time (several minutes per gigabyte on most systems):</para>
+<programlisting>dd if=/dev/urandom of=&lt;device&gt;</programlisting>
 		</listitem>
 		<listitem>
-		<para> Fastest way, which provides lower quality random data:<programlisting>badblocks -c 10240 -s -w -t random -v &lt;device&gt;</programlisting>
-		</para>
+		<para> Fastest way, which provides lower quality random data:</para>
+<programlisting>badblocks -c 10240 -s -w -t random -v &lt;device&gt;</programlisting>
 		</listitem>
 		</itemizedlist>
 	</section>
 	<section>
 		<title>Format the device as a dm-crypt/LUKS encrypted device </title>
-		<para>
-			<warning><title>Warning</title>
-		<para>The command below will destroy any existing data on the device.</para>
+		
+		<warning>
+			<title>Warning</title>
+			<para>The command below will destroy any existing data on the device.</para>
 		</warning>
 		
-		<programlisting>cryptsetup luksFormat &lt;device&gt;</programlisting>
-		</para>
+<programlisting>cryptsetup luksFormat &lt;device&gt;</programlisting>
+		
 		<para>
 		<note><title>Tip</title>
 		<para>For more information, read the <command>cryptsetup(8)</command> man page.</para>
@@ -304,3 +333,4 @@
       </section>
 </section>
 </appendix>
+
diff --git a/en-US/Kickstart2.xml b/en-US/Kickstart2.xml
index 76097cb..6a68c1d 100644
--- a/en-US/Kickstart2.xml
+++ b/en-US/Kickstart2.xml
@@ -12,13 +12,14 @@
 		<primary>kickstart installations</primary>
 	</indexterm>
 	<section id="s1-kickstart2-whatis">
+		
 		<title>What are Kickstart Installations?</title>
-
+		
 		<indexterm significance="normal">
 			<primary>log files</primary>
 			<secondary>kickstart installations</secondary>
 		</indexterm>
-		
+		 
 		<para>
 			Many system administrators would prefer to use an automated installation method to install Fedora on their machines. To answer this need, Red Hat created the kickstart installation method. Using kickstart, a system administrator can create a single file containing the answers to all the questions that would normally be asked during a typical installation.
 		</para>
@@ -577,7 +578,7 @@ If the <command>clearpart</command> command is used, then the <command>--onpart<
 
 <listitem>
 	<para>
-		<command>--initlabel</command> &mdash; Initializes the disk label to the default for your architecture (for example <command>msdos</command> for x86 and <command>gpt</command> for Itanium). It is useful so that the installation program does not ask if it
+		<command>--initlabel</command> &mdash; Initializes the disk label to the default for your architecture (for example <command>msdos</command> for x86). It is useful so that the installation program does not ask if it
 		should initialize the disk label if installing to a brand new hard drive.
 	</para>
 </listitem>
@@ -666,7 +667,7 @@ If the <command>clearpart</command> command is used, then the <command>--onpart<
 						Driver diskettes can be used during kickstart installations. You must copy the driver diskettes's contents to the root directory of a partition on the system's hard drive. Then you must use the <command>driverdisk</command> command to
 						tell the installation program where to look for the driver disk.
 					</para>
-<screen>driverdisk <replaceable>&lt;partition&gt;</replaceable> [--type=<replaceable>&lt;fstype&gt;</replaceable>]</screen>
+<screen>driverdisk <replaceable>&lt;partition&gt;</replaceable> --source=<replaceable>&lt;url&gt;</replaceable> --biospart=<replaceable>&lt;biospart&gt;</replaceable> [--type=<replaceable>&lt;fstype&gt;</replaceable>]</screen>
 					<para>
 						Alternatively, a network location can be specified for the driver diskette:
 					</para>
@@ -683,6 +684,18 @@ driverdisk --source=nfs:host:/path/to/img</screen>
 
 <listitem>
 	<para>
+		<replaceable>&lt;url&gt;</replaceable> &mdash; URL for the driver disk. NFS locations can be given in the form <literal>nfs:<replaceable>host</replaceable>:/<replaceable>path/to/img</replaceable></literal>.
+	</para>
+</listitem>
+
+<listitem>
+	<para>
+		<replaceable>&lt;biospart&gt;</replaceable> &mdash; BIOS partition containing the driver disk (for example, <literal>82p2</literal>). 
+	</para>
+</listitem>
+
+<listitem>
+	<para>
 		<command>--type=</command> &mdash; File system type (for example, vfat or ext2).
 	</para>
 </listitem>
@@ -1094,6 +1107,7 @@ driverdisk --source=nfs:host:/path/to/img</screen>
 					</para>
 				</listitem>
 			</varlistentry>
+			
 			<varlistentry>
 				<term><command>key</command> (optional)</term>
 				<listitem>
@@ -1126,7 +1140,7 @@ driverdisk --source=nfs:host:/path/to/img</screen>
 					<primary>kickstart file</primary>
 					<secondary><command>keyboard</command>
 					</secondary>
-				</indexterm>					Sets system keyboard type. Here is the list of available keyboards on i386, Itanium, and Alpha machines:
+				</indexterm>					Sets system keyboard type. Here is the list of available keyboards on i386 and Alpha machines:
 					</para>
 <screen>
 be-latin1, bg, br-abnt2, cf, cz-lat2, cz-us-qwertz, de, de-latin1, 
@@ -1287,9 +1301,7 @@ sv-latin1, sg, sg-latin1, sk-querty, slovene, trq, ua,  uk, us, us-acentos
 	<para>
 		<command>--backuppassphrase=</command> &mdash; Add a randomly-generated passphrase to each encrypted volume. Store these passphrases in separate files in <filename>/</filename> (root), encrypted using the X.509 certificate specified with <command>--escrowcert</command>. This option is only meaningful if <command>--escrowcert</command> is specified. 
 	</para>
-</listitem>
-						
-						
+</listitem>	
 					</itemizedlist>
 
 					<para>
@@ -1749,7 +1761,6 @@ All partitions created are formatted as part of the installation process unless
 	</para>
 </listitem>
 						
-						
 <listitem>
 	<para>
 		<command>--bytes-per-inode=</command> &mdash; Specifies the size of inodes on the filesystem to be made on the partition. Not all filesystems support this option, so it is silently ignored for those cases.
@@ -3232,7 +3243,16 @@ umount /mnt/temp
 				<term><command>ks=hd:<replaceable>&lt;device&gt;</replaceable>:/<replaceable>&lt;file&gt;</replaceable></command></term>
 				<listitem>
 					<para>
-						The installation program mounts the file system on <replaceable>&lt;device&gt;</replaceable> (which must be vfat or ext2), and look for the kickstart configuration file as <replaceable>&lt;file&gt;</replaceable> in that file system (for example, <command>ks=hd:sda3:/mydir/ks.cfg</command>).
+						The installation program mounts the file system on <replaceable>&lt;device&gt;</replaceable> (which must be vfat or ext2), and looks for the kickstart configuration file as <replaceable>&lt;file&gt;</replaceable> in that file system (for example, <command>ks=hd:sda3:/mydir/ks.cfg</command>).
+					</para>
+				</listitem>
+			</varlistentry>
+			
+			<varlistentry>
+				<term><command>ks=bd:<replaceable>&lt;biosdev&gt;</replaceable>:/<replaceable>&lt;path&gt;</replaceable></command></term>
+				<listitem>
+					<para>
+						The installation program mounts the file system on the specified partition on the specified BIOS device <replaceable>&lt;biosdev&gt;</replaceable>, and looks for the kickstart configuration file specified in <replaceable>&lt;path&gt;</replaceable> (for example, <command>ks=bd:80p3:/mydir/ks.cfg</command>).     Note this does not work for BIOS RAID sets.
 					</para>
 				</listitem>
 			</varlistentry>
@@ -3436,7 +3456,7 @@ umount /mnt/temp
 					</important>
 				</listitem>
 			</varlistentry>	
-
+						
 			<varlistentry>
 				<term><command>nomount</command></term>
 				<listitem>
@@ -3657,3 +3677,4 @@ umount /mnt/temp
 		</variablelist>
 	</section>
 </chapter>
+




More information about the docs-commits mailing list