commit 707c0c6ca9d079e3f88488d858c6be9496391507
Author: Pete Travis <immanetize(a)fedoraproject.org>
Date: Fri Sep 5 23:32:13 2014 -0600
We like cobbler, you should go read about it.
en-US/Network_based_Installations.xml | 19 +++++++++----------
1 files changed, 9 insertions(+), 10 deletions(-)
---
diff --git a/en-US/Network_based_Installations.xml b/en-US/Network_based_Installations.xml
index b5ba577..5e8bae3 100644
--- a/en-US/Network_based_Installations.xml
+++ b/en-US/Network_based_Installations.xml
@@ -21,15 +21,7 @@
<para>
For a PXE network installation, the client's NIC with PXE support sends out a broadcast request for DHCP information. The DHCP server provides the client with an IP address, other network information such as name server, the IP address or hostname of the <command>tftp</command> server (which provides the files necessary to start the installation program), and the location of the files on the <command>tftp</command> server. This is possible because of PXELINUX, which is part of the <filename>syslinux</filename> package.
</para>
- <para>
- In the past, administrators needed to perform a great deal of manual configuration to produce an installation server. However, if you have a server running &PRODUCT; or a similar operating system on your local network, you can use <package>cobbler</package> to perform these tasks. To configure a PXE server manually, see <xref linkend="sect-install-server-manual"/>
- </para>
- <para>
- To perform the tasks in this section, switch to the <systemitem class="username">root</systemitem> account with the command <command>su -</command>. As an alternative, you can run a command with the <option>-c</option> option, using the form <command>su -c '<replaceable>command</replaceable>'</command>.
- </para>
-
- <section id="sect-install-server-cobbler">
- <title>Setting Up cobbler</title>
+ <title>Setting Up cobbler</title>
<para>
To install <application>cobbler</application> use the following command:
</para>
@@ -574,7 +566,14 @@ set timeout=1
</section>
</section>
-
+ <section id="sect-install-server-cobbler">
+ <para>
+ For more complex environments, &PRODUCT; offers the <package>cobbler</package> installation server. Tasks like managing kickstart configurtations, coordinating repositories, maintaining dns records, dhcp servers, and even puppet manifests are effectively automated by <package>cobbler</package>.
+ </para>
+ <para>
+ While levaraging all of the features provided by cobbler can be relatively simple, the full functionality of this powerful tool is too broad to be documented in this guide. The cobbler community provides excellent documentation at <ulink url="http://www.cobblerd.org/manuals/2.6.0/" /> to accompany the packages in the Fedora repository.
+ </para>
+
<section id="sect-booting-pxe-installation">
<title>Booting the Network Installation</title>
<para>
commit bd1efd9fa857c67364a827e7876cf37fec10b0e2
Author: Petr Bokoc <pbokoc(a)redhat.com>
Date: Fri Sep 5 19:00:13 2014 +0200
Moving back Network Server Setup
en-US/Network_based_Installations.xml | 579 ++++++++++++++++++++++++++++++++-
1 files changed, 578 insertions(+), 1 deletions(-)
---
diff --git a/en-US/Network_based_Installations.xml b/en-US/Network_based_Installations.xml
index 208ef7a..b5ba577 100644
--- a/en-US/Network_based_Installations.xml
+++ b/en-US/Network_based_Installations.xml
@@ -5,7 +5,584 @@
]>
<chapter id="chap-pxe-server-setup">
<title>Setting Up an Installation Server</title>
+ <note>
+ <para>
+ This appendix is intended for users with previous Linux experience. If you are a new user, you may want to install using minimal boot media or the distribution DVD instead.
+ </para>
+ </note>
+ <warning>
+ <para>
+ The instructions in this appendix configures an automated install server. The default configuration includes destruction of all existing data on all disks for hosts that install using this method. This is often different from other network install server configurations which may provide for an interactive installation experience.
+ </para>
+ </warning>
<para>
- TODO
+ &PRODUCT; allows for installation over a network using the NFS, FTP, or HTTP protocols. A network installation can be started from a boot CD-ROM, a bootable flash memory drive, or by using the <option>inst.repo=</option> boot option with the &PRODUCT; DVD. Alternatively, if the system to be installed contains a network interface card (NIC) with Pre-Execution Environment (PXE) support, it can be configured to boot from files on another networked system rather than local media such as a DVD.
</para>
+ <para>
+ For a PXE network installation, the client's NIC with PXE support sends out a broadcast request for DHCP information. The DHCP server provides the client with an IP address, other network information such as name server, the IP address or hostname of the <command>tftp</command> server (which provides the files necessary to start the installation program), and the location of the files on the <command>tftp</command> server. This is possible because of PXELINUX, which is part of the <filename>syslinux</filename> package.
+ </para>
+ <para>
+ In the past, administrators needed to perform a great deal of manual configuration to produce an installation server. However, if you have a server running &PRODUCT; or a similar operating system on your local network, you can use <package>cobbler</package> to perform these tasks. To configure a PXE server manually, see <xref linkend="sect-install-server-manual"/>
+ </para>
+ <para>
+ To perform the tasks in this section, switch to the <systemitem class="username">root</systemitem> account with the command <command>su -</command>. As an alternative, you can run a command with the <option>-c</option> option, using the form <command>su -c '<replaceable>command</replaceable>'</command>.
+ </para>
+
+ <section id="sect-install-server-cobbler">
+ <title>Setting Up cobbler</title>
+ <para>
+ To install <application>cobbler</application> use the following command:
+ </para>
+ <screen>
+<prompt>#</prompt> <command>yum install cobbler</command>
+ </screen>
+ <para>
+ <application>cobbler</application> can check its own settings for validity and report the results. Run the following command to check the settings:
+ </para>
+ <screen>
+<prompt>$</prompt> <command>cobbler check</command>
+ </screen>
+ <para>
+ Verify SELinux is configured properly:
+ </para>
+ <screen>
+<prompt>#</prompt><command>setsebool -P httpd_can_network_connect_cobbler 1</command>
+ </screen>
+ <para>
+ Other SELinux booleans may apply, and can be listed with:
+ </para>
+ <screen>
+<prompt>$</prompt><command>getsebool -a|grep cobbler</command>
+ </screen>
+ <para>
+ Change the settings in the <filename>/etc/cobbler/settings</filename> file to reflect the IP address information for the server. You must change at least the <option>server</option> and <option>next_server</option> options, although these options may point to the same IP address.
+ </para>
+ <para>
+ If you are not already running a DHCP server, you should also change the <option>manage_dhcp</option> option to <userinput>1</userinput>. If you are running a DHCP server, configure it according to the instructions found in the <package>syslinux</package> package documentation. For more information, refer to your local files <filename>/usr/share/doc/syslinux/syslinux.doc</filename> and <filename>/usr/share/doc/syslinux/pxelinux.doc</filename>.
+ </para>
+ </section>
+
+ <section id="sect-cobbler-setup-distro">
+ <title>Setting Up the Distribution</title>
+ <para>
+ To set up a distribution from a full &PRODUCT; DVD or ISO image, use this procedure.
+ </para>
+ <note>
+ <para>
+ To create a local mirror from an existing network source, skip this section and refer instead to <xref linkend="sect-cobbler-mirror"/>.
+ </para>
+ </note>
+ <procedure>
+ <step>
+ <para>
+ If you are using a DVD disc or ISO image, Create a directory mount point:
+ </para>
+ <screen>
+<prompt>#</prompt> <command>mkdir /mnt/dvd</command>
+ </screen>
+ <para>
+ To mount a physical DVD disc, use the following command:
+ </para>
+ <screen>
+<prompt>#</prompt> <command>mount -o context=system_u:object_r:httpd_sys_content_t:s0 /dev/dvd /mnt/dvd</command>
+ </screen>
+ <para>
+ To mount a DVD ISO image, use the following command:
+ </para>
+ <screen>
+<prompt>#</prompt> <command>mount -ro loop,context=system_u:object_r:httpd_sys_content_t:s0 /path/to/image.iso /mnt/dvd</command>
+ </screen>
+ <note>
+ <para>
+ If SELinux is enabled, use the default <literal>iso9660_t</literal> label instead of <literal>httpd_sys_content_t</literal>.
+ </para>
+ </note>
+ </step>
+ <step>
+ <para>
+ To support NFS installation, create a file <filename>/etc/exports</filename> and add the following line to it:
+ </para>
+ <screen>
+/mnt/dvd *(ro,async)
+ </screen>
+ <para>
+ Start the NFS server using the following command:
+ </para>
+ <screen>
+<prompt>#</prompt> <command>systemctl start rpcbind nfs</command>
+ </screen>
+ </step>
+ <step>
+ <para>
+ To support HTTP installation, use <command>yum</command> to install the Apache web server if it is not already installed:
+ </para>
+ <screen>
+<prompt>#</prompt> <command>yum -y install httpd</command>
+ </screen>
+ <para>
+ Make a link to the mounted disc in the Apache public
+ content area:
+ </para>
+ <screen>
+<prompt>#</prompt> <command>ln -s /mnt/dvd /var/www/html/<replaceable>distro</replaceable></command>
+ </screen>
+ </step>
+ </procedure>
+ </section>
+
+ <section id="sect-cobbler-mirror">
+ <title>Mirroring a Network Location</title>
+ <para>
+ If you do not have discs or ISO images for a distribution, you can use <command>cobbler</command> to create an installation server. The <command>cobbler</command> command can fetch the distribution over the network as part of the import process.
+ </para>
+ <para>
+ Locate the distribution on the network. The location may be on the local network or reached at a remote site via FTP, HTTP, or rsync protocols. <!-- Note the URI, which will be in one of the
+ following forms: -->
+ </para>
+ <!-- <itemizedlist>
+ <listitem>
+ <para><uri>http://mirror.example.com/pub/fedora/linux/releases/11/Fedora/<replaceable>arch</replaceable>/os</uri></para>
+ </listitem>
+ <listitem>
+ <para><uri>ftp://mirror.example.com/pub/fedora/linux/releases/11/Fedora/<replaceable>arch</replaceable>/os</uri></para>
+ </listitem>
+ <listitem>
+ <para><uri>rsync://mirror.example.com/fedora/linux/releases/11/Fedora/<replaceable>arch</replaceable>/os</uri></para>
+ </listitem>
+ </itemizedlist> -->
+ </section>
+
+ <section id="sect-cobbler-import-distro">
+ <title>Importing the Distribution</title>
+ <para>
+ To offer a distribution through more than one installation method, perform additional <command>cobbler import</command> tasks using a different name for each method. For best results, use the installation method as part of the name, so it appears in the client's boot menu.
+ </para>
+ <procedure>
+ <step>
+ <para>
+ To import the DVD disc or ISO distribution into <application>cobbler</application>, run this command:
+ </para>
+ <screen>
+<prompt>#</prompt> <command>cobbler import --path=/mnt/dvd --name=<replaceable>distro_name</replaceable></command>
+ </screen>
+ <para>
+ For <replaceable>distro_name</replaceable>, substitute a meaningful name for the distribution.
+ </para>
+ <para>
+ To import a local or remote network distribution into <command>cobbler</command>, run this command. Replace <replaceable>network_URI</replaceable> with the URI you found in <xref linkend="sect-cobbler-mirror"/>, and <replaceable>distro_name</replaceable> as above:
+ </para>
+ <screen>
+<prompt>#</prompt> <command>cobbler import --path=<replaceable>network_URI</replaceable> --name=<replaceable>distro_name</replaceable></command>
+ </screen>
+ <important>
+ <para>
+ When <command>cobbler</command> imports a distribution with the commands above, it copies all the files to the server's local storage, which may take some time.
+ </para>
+ </important>
+ <para>
+ If you do not want to make local copies of the distribution because clients can already reach its location, use the <option>--available-as</option> option.
+ </para>
+ <screen>
+<prompt>#</prompt> <command>cobbler import --path=/mnt/dvd --name=<replaceable>distro_name</replaceable> --available-as=<replaceable>network_URI</replaceable></command>
+<prompt>#</prompt> <command>cobbler import --path=<replaceable>network_URI</replaceable> --name=<replaceable>distro_name</replaceable> --available-as=<replaceable>network_URI</replaceable></command>
+ </screen>
+ <para>
+ For <replaceable>nework_URI</replaceable>, substitute the appropriate network location of the distribution. This URI indicates how the server makes the distribution available to its clients. The examples above assume that your <command>cobbler</command> server reaches the mirror location at the same URI as the clients. If not, substitute an appropriate URI for the <option>--path</option> option. The following examples are URI locations that work if you have been following the procedures in this section, and your server's IP address is <systemitem class="ipaddress">192.168.1.1</systemitem>:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ <uri>nfs://<replaceable>192.168.1.1</replaceable>:/mnt/dvd</uri>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <uri>http://<replaceable>192.168.1.1</replaceable>:/distro</uri>
+ </para>
+ </listitem>
+ </itemizedlist>
+ <para>
+ If necessary, replace <replaceable>192.168.1.1</replaceable> with the IP address for your <command>cobbler</command> server.
+ </para>
+ </step>
+ <step>
+ <para>
+ Run the command <command>cobbler sync</command> to apply the changes. To check that your <command>cobbler</command> server is listening on the correct ports, use the <command>netstat -lp</command> command.
+ </para>
+ <important>
+ <para>
+ Depending on your server's configuration, you may need to use the <command>system-config-securitylevel</command> command to permit access to some or all of these network services:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ 67 or bootps, for the DHCP/BOOTP server
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ 69 or tftp, for providing the PXE loader
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ 80 or http, if the <application>cobbler</application> server is to provide HTTP installation service
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ 20 and 21 or ftp, if the <application>cobbler</application> server is to provide FTP installation service
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ 111 or sunrpc, if the <application>cobbler</application> server is to provide NFS installation service
+ </para>
+ </listitem>
+ </itemizedlist>
+ </important>
+ </step>
+ </procedure>
+ </section>
+
+ <section id="sect-install-server-manual">
+ <title>Manually configure a PXE server</title>
+ <para>
+ The following steps must be performed to prepare for a network installation manually (without <application>cobbler</application>):
+ </para>
+ <orderedlist>
+ <listitem>
+ <para>
+ Configure the network (<systemitem class="protocol">NFS</systemitem>, <systemitem class="protocol">HTTPS</systemitem>, <systemitem class="protocol">HTTP</systemitem>, or <systemitem class="protocol">FTP</systemitem>) server to export the installation tree or the installation ISO image. For procedures describing the configuration, see <xref linkend="sect-preparing-installation-sources" />.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Configure the files on the <application>tftp</application> server necessary for network boot, configure <systemitem class="protocol">DHCP</systemitem>, and start the <systemitem class="service">tftp</systemitem> service on the PXE server. See <xref linkend="sect-network-boot-setup" /> for details.
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Boot the client (the system you want to install &PRODUCT; on) and start the installation. See <xref linkend="sect-booting-pxe-installation" /> for more information.
+ </para>
+ </listitem>
+ </orderedlist>
+ <note>
+ <para>
+ The procedures in this chapter describe setting up a PXE server on a &PRODUCT; &PRODVER; system. For details about configuring PXE on earlier releases of &PRODUCT;, see the appropriate <citetitle>Installation Guide</citetitle> for that release.
+ </para>
+ </note>
+
+ <section id="sect-network-boot-setup">
+ <title>Configuring PXE Boot</title>
+ <para>
+ After setting up a network server containing the package repositories to be used in the installation, the next step is to configure the PXE server itself. This server will contain files necessary to boot the &PRODUCT; and start the installation. Additionally, a <systemitem class="protocol">DHCP</systemitem> server must be configured, and all necessary services must be enabled and started.
+ </para>
+ <para>
+ For more information on configuring a PXE server for use with headless systems (systems without a directly connected display, keyboard and mouse), see <xref linkend="sect-vnc-headless-considerations" />.
+ </para>
+
+ <section id="sect-network-boot-setup-bios">
+ <title>Configuring a PXE Server for BIOS-based Clients</title>
+ <para>
+ The following procedure will prepare the PXE server for booting BIOS-based AMD64 and Intel 64 systems. For information on UEFI-based systems, see <xref linkend="sect-network-boot-setup-uefi" />.
+ </para>
+ <procedure>
+ <title>Configuring PXE Boot for BIOS-based Systems</title>
+ <step>
+ <para>
+ Install the <package>tftp</package> package. To do this, run the following command as <systemitem class="username">root</systemitem>:
+ </para>
+ <screen>
+<prompt>#</prompt> <command>yum install tftp-server</command>
+ </screen>
+ </step>
+ <step>
+ <para>
+ In the <filename>/etc/xinetd.d/tftp</filename> configuration file, change the <parameter>disabled</parameter> parameter from <literal>yes</literal> to <literal>no</literal>.
+ </para>
+ </step>
+ <step>
+ <para>
+ Configure your <systemitem class="protocol">DHCP</systemitem> server to use the boot images packaged with SYSLINUX. If you do not have a DHCP server installed, see the <citetitle>&PRODUCT; Networking Guide</citetitle>, available at the <ulink url="http://docs.fedoraproject.org/">Fedora Documentation website</ulink>, for instructions.
+ </para>
+ <para>
+ A sample configuration in the <filename>/etc/dhcp/dhcpd.conf</filename> file might look like:
+ </para>
+ <programlisting>
+ option space pxelinux;
+ option pxelinux.magic code 208 = string;
+ option pxelinux.configfile code 209 = text;
+ option pxelinux.pathprefix code 210 = text;
+ option pxelinux.reboottime code 211 = unsigned integer 32;
+
+ subnet 10.0.0.0 netmask 255.255.255.0 {
+ option routers 10.0.0.254;
+ range 10.0.0.2 10.0.0.253;
+
+ class "pxeclients" {
+ match if substring (option vendor-class-identifier, 0, 9) = "PXEClient";
+ next-server 10.0.0.1;
+
+ if option arch = 00:07 {
+ filename "uefi/shim.efi";
+ } else {
+ filename "pxelinux/pxelinux.0";
+ }
+ }
+
+ host example-ia32 {
+ hardware ethernet XX:YY:ZZ:11:22:33;
+ fixed-address 10.0.0.2;
+ }
+ }
+ </programlisting>
+ </step>
+ <step>
+ <para>
+ You now need the <filename>pxelinux.0</filename> file from the SYSLINUX package in the ISO image file. To access it, run the following commands as root:
+ </para>
+ <screen>
+<prompt>#</prompt> <command>mount -t iso9660 /<replaceable>path_to_image/name_of_image</replaceable>.iso /<replaceable>mount_point</replaceable> -o loop,ro</command>
+ </screen>
+ <screen>
+<prompt>#</prompt> <command>cp -pr /<replaceable>mount_point</replaceable>/Packages/syslinux-<replaceable>version-architecture</replaceable>.rpm /<replaceable>publicly_available_directory</replaceable></command>
+ </screen>
+ <screen>
+<prompt>#</prompt> <command>umount /<replaceable>mount_point</replaceable></command>
+ </screen>
+ <para>
+ Extract the package:
+ </para>
+ <screen>
+<prompt>#</prompt> <command>rpm2cpio syslinux-<replaceable>version-architecture</replaceable>.rpm | cpio -dimv</command>
+ </screen>
+ </step>
+ <step>
+ <para>
+ Create a <filename>pxelinux/</filename> directory within <filename>tftpboot/</filename> and copy the <filename>pxelinux.0</filename> file into it:
+ </para>
+ <screen>
+<prompt>#</prompt> <command>mkdir /var/lib/tftpboot/pxelinux</command>
+ </screen>
+ <screen>
+<prompt>#</prompt> <command>cp <replaceable>publicly_available_directory</replaceable>/usr/share/syslinux/pxelinux.0 /var/lib/tftpboot/pxelinux</command>
+ </screen>
+ </step>
+ <step>
+ <para>
+ Add a configuration file to the <filename class="directory">pxelinux/</filename> directory. The file name should either be <literal>default</literal>, or based on the system's IP address. For example, if your machine's IP address is 10.0.0.1, the file name will be <filename>0A000001</filename>.
+ </para>
+ <para>
+ A sample configuration file at <filename>/var/lib/tftpboot/pxelinux/default</filename> might look like:
+ </para>
+ <programlisting>
+default vesamenu.c32
+prompt 1
+timeout 600
+
+display boot.msg
+
+label linux
+ menu label ^Install system
+ menu default
+ kernel vmlinuz
+ append initrd=initrd.img ip=dhcp inst.repo=http://10.32.5.1/mnt/archive/Fedora/&PRODVER;/Server/x86_64/os/
+label vesa
+ menu label Install system with ^basic video driver
+ kernel vmlinuz
+ append initrd=initrd.img ip=dhcp inst.xdriver=vesa nomodeset inst.repo=http://10.32.5.1/mnt/archive/Fedora/&PRODVER;/Server/x86_64/os/
+label rescue
+ menu label ^Rescue installed system
+ kernel vmlinuz
+ append initrd=initrd.img rescue
+label local
+ menu label Boot from ^local drive
+ localboot 0xffff
+ </programlisting>
+ <important>
+ <para>
+ The <option>inst.repo=</option> <application>Anaconda</application> option, shown in the example above, must always be used to specify the installation program's image as well as the installation source. Without this option, the installation program will be unable to boot. For more information about boot options for <application>Anaconda</application>, see <xref linkend="sect-boot-options-installer" />.
+ </para>
+ </important>
+ </step>
+ <step>
+ <para>
+ Copy the boot images into your <command>tftp/</command> root directory:
+ </para>
+ <screen>
+<prompt>#</prompt> <command>cp /<replaceable>path/to</replaceable>/x86_64/os/images/pxeboot/{vmlinuz,initrd.img} /var/lib/tftpboot/pxelinux/</command>
+ </screen>
+ </step>
+ <step>
+ <para>
+ Enable and start the <systemitem class="service">tftp</systemitem> and <systemitem class="service">xinetd</systemitem> services using the <command>systemctl</command> command.
+ </para>
+ <screen>
+<prompt>#</prompt> <command>systemctl enable xinetd.service tftp.service</command>
+ </screen>
+ <screen>
+<prompt>#</prompt> <command>systemctl start xinetd.service tftp.service</command>
+ </screen>
+ </step>
+ </procedure>
+ <para>
+ After finishing this procedure, the PXE server is ready to start the network installation. You can now start the system you want to install &PRODUCT; on, select PXE Boot when prompted to specify a boot source, and start the network installation.
+ </para>
+ </section>
+
+ <section id="sect-network-boot-setup-uefi">
+ <title>Configuring a PXE Server for UEFI-based Clients</title>
+ <para>
+ The following procedure will prepare the PXE server for booting UEFI-based AMD64 and Intel 64 systems. For information on BIOS-based systems, see <xref linkend="sect-network-boot-setup-bios" />.
+ </para>
+ <procedure>
+ <title>Configuring PXE Boot for UEFI-based Systems</title>
+ <step>
+ <para>
+ Install the <package>tftp</package> package. To do this, run the following command as <systemitem class="username">root</systemitem>:
+ </para>
+ <screen>
+<prompt>#</prompt> <command>yum install tftp-server</command>
+ </screen>
+ </step>
+ <step>
+ <para>
+ In the <filename>/etc/xinetd.d/tftp</filename> configuration file, change the <parameter>disabled</parameter> parameter from <literal>yes</literal> to <literal>no</literal>.
+ </para>
+ </step>
+ <step>
+ <para>
+ Configure your <systemitem class="protocol">DHCP</systemitem> server to use the EFI boot images packaged with <package>shim</package>. If you do not have a DHCP server installed, see the <citetitle>&PRODUCT; Networking Guide</citetitle>, available at the <ulink url="http://docs.fedoraproject.org/">Fedora Documentation website</ulink>, for instructions.
+ </para>
+ <para>
+ A sample configuration in the <filename>/etc/dhcp/dhcpd.conf</filename> file might look like:
+ </para>
+ <programlisting>
+ option space PXE;
+ option PXE.mtftp-ip code 1 = ip-address;
+ option PXE.mtftp-cport code 2 = unsigned integer 16;
+ option PXE.mtftp-sport code 3 = unsigned integer 16;
+ option PXE.mtftp-tmout code 4 = unsigned integer 8;
+ option PXE.mtftp-delay code 5 = unsigned integer 8;
+ option arch code 93 = unsigned integer 16; # RFC4578
+
+ subnet 10.0.0.0 netmask 255.255.255.0 {
+ option routers 10.0.0.254;
+ range 10.0.0.2 10.0.0.253;
+
+ class "pxeclients" {
+ match if substring (option vendor-class-identifier, 0, 9) = "PXEClient";
+ next-server 10.0.0.1;
+
+ if option arch = 00:07 {
+ filename "uefi/shim.efi";
+ } else {
+ filename "pxelinux/pxelinux.0";
+ }
+ }
+
+ host example-ia32 {
+ hardware ethernet XX:YY:ZZ:11:22:33;
+ fixed-address 10.0.0.2;
+ }
+ }
+ </programlisting>
+ </step>
+ <step>
+ <para>
+ You now need the <filename>shim.efi</filename> file from the <package>shim</package> package and the <filename>grubx64.efi</filename> file from the <package>grub2-efi</package> package in the ISO image file. To access them, run the following commands as root:
+ </para>
+ <screen>
+<prompt>#</prompt> <command>mount -t iso9660 /<replaceable>path_to_image/name_of_image</replaceable>.iso /<replaceable>mount_point</replaceable> -o loop,ro</command>
+ </screen>
+ <screen>
+<prompt>#</prompt> <command>cp -pr /<replaceable>mount_point</replaceable>/Packages/shim-<replaceable>version-architecture</replaceable>.rpm /<replaceable>publicly_available_directory</replaceable></command>
+ </screen>
+ <screen>
+<prompt>#</prompt> <command>cp -pr /<replaceable>mount_point</replaceable>/Packages/grub2-efi-<replaceable>version-architecture</replaceable>.rpm /<replaceable>publicly_available_directory</replaceable></command>
+ </screen>
+ <screen>
+<prompt>#</prompt> <command>umount /<replaceable>mount_point</replaceable></command>
+ </screen>
+ <para>
+ Extract the packages:
+ </para>
+ <screen>
+<prompt>#</prompt> <command>rpm2cpio shim-<replaceable>version-architecture</replaceable>.rpm | cpio -dimv</command>
+ </screen>
+ <screen>
+<prompt>#</prompt> <command>rpm2cpio grub2-efi-<replaceable>version-architecture</replaceable>.rpm | cpio -dimv</command>
+ </screen>
+ </step>
+ <step>
+ <para>
+ Create a directory within the <filename class="directory">tftpboot/</filename> directory named <filename class="directory">uefi/</filename> for the EFI boot images, and then copy them from your boot directory:
+ </para>
+ <screen>
+<prompt>#</prompt> <command>mkdir /var/lib/tftpboot/uefi</command>
+ </screen>
+ <screen>
+<prompt>#</prompt> <command>cp <replaceable>publicly_available_directory</replaceable>/boot/efi/EFI/fedora/shim.efi /var/lib/tftpboot/uefi/</command>
+ </screen>
+ <screen>
+<prompt>#</prompt> <command>cp <replaceable>publicly_available_directory</replaceable>/boot/efi/EFI/fedora/grubx64.efi /var/lib/tftpboot/uefi/</command>
+ </screen>
+ </step>
+ <step>
+ <para>
+ Add a configuration file named <filename>grub.cfg</filename> to the <filename class="directory">uefi/</filename> directory. A sample configuration file at <filename>/var/lib/tftpboot/uefi/grub.cfg</filename> might look like:
+ </para>
+ <programlisting>
+set timeout=1
+ menuentry '&PRODUCT;' {
+ linuxefi uefi/vmlinuz ip=dhcp inst.repo=http://10.32.5.1/mnt/archive/&PRODUCT;/&PRODVER;/Server/x86_64/os/
+ initrdefi uefi/initrd.img
+}
+ </programlisting>
+ <important>
+ <para>
+ The <option>inst.repo=</option> <application>Anaconda</application> option, shown in the example above, must always be used to specify the installation program's image as well as the installation source. Without this option, the installation program will be unable to boot. For more information about boot options for <application>Anaconda</application>, see <xref linkend="sect-boot-options-installer" />.
+ </para>
+ </important>
+ </step>
+ <step>
+ <para>
+ Copy the boot images into your <command>uefi/</command> directory:
+ </para>
+ <screen>
+<prompt>#</prompt> <command>cp /<replaceable>path/to</replaceable>/x86_64/os/images/pxeboot/{vmlinuz,initrd.img} /var/lib/tftpboot/uefi/</command>
+ </screen>
+ </step>
+ <step>
+ <para>
+ Enable and start the <systemitem class="service">tftp</systemitem> and <systemitem class="service">xinetd</systemitem> services using the <command>systemctl</command> command.
+ </para>
+ <screen>
+<prompt>#</prompt> <command>systemctl enable xinetd.service tftp.service</command>
+ </screen>
+ <screen>
+<prompt>#</prompt> <command>systemctl start xinetd.service tftp.service</command>
+ </screen>
+ </step>
+ </procedure>
+ <para>
+ After finishing this procedure, the PXE server is ready to start the network installation. You can now start the system you want to install &PRODUCT; on, select PXE Boot when prompted to specify a boot source, and start the network installation.
+ </para>
+ </section>
+
+ </section>
+
+ </section>
+
+ <section id="sect-booting-pxe-installation">
+ <title>Booting the Network Installation</title>
+ <para>
+ After the PXE server has been configured and the installation tree or ISO image made available, you are ready to start the network installation. You must make sure that the system you are installing &PRODUCT; on is configured to boot from the network. The exact way to ensure varies depending on the hardware you are using.
+ </para>
+ <para>
+ For more specific instructions about booting your system, see <xref linkend="sect-booting-network" />.
+ </para>
+ </section>
+
</chapter>
commit 08097104e66cef8149ef65da0d7463f082f42896
Author: Pete Travis <immanetize(a)fedoraproject.org>
Date: Thu Sep 4 22:31:50 2014 -0600
add subtitle and bump version entities
en-US/Article_Info.xml | 8 ++++----
en-US/Welcome.ent | 4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
---
diff --git a/en-US/Article_Info.xml b/en-US/Article_Info.xml
index 25b92ff..c91420f 100644
--- a/en-US/Article_Info.xml
+++ b/en-US/Article_Info.xml
@@ -3,11 +3,11 @@
]>
<articleinfo id="arti-Home_Page-Home_Page">
<title>Welcome</title>
- <!-- <subtitle>short description</subtitle> -->
+ <subtitle>Welcome to Fedora</subtitle>
<productname>Fedora Documentation</productname>
- <productnumber></productnumber>
- <edition></edition>
- <pubsnumber></pubsnumber>
+ <productnumber>21</productnumber>
+ <edition>1</edition>
+ <pubsnumber>1</pubsnumber>
<!-- <abstract>
<para>
A short overview and summary of the book's subject and purpose, traditionally no more than one paragraph long. Note: the abstract will appear in the front matter of your book and will also be placed in the description field of the book's RPM spec file.
diff --git a/en-US/Welcome.ent b/en-US/Welcome.ent
index 59d84ae..401dc23 100644
--- a/en-US/Welcome.ent
+++ b/en-US/Welcome.ent
@@ -2,7 +2,7 @@
<!ENTITY BOOKID "Home_Page">
<!ENTITY YEAR "2012">
<!ENTITY HOLDER "Red Hat, Inc. and others">
-<!ENTITY PRODVER "18">
-<!ENTITY PREVVER "17">
+<!ENTITY PRODVER "21">
+<!ENTITY PREVVER "20">
<!ENTITY BZURL "<ulink url='https://bugzilla.redhat.com/enter_bug.cgi?product=&PRODUCT;&component=&…;'>http://bugzilla.redhat.com/</ulink>">
Repository : http://git.fedorahosted.org/cgit/docs/networking-guide.git
On branch : master
>---------------------------------------------------------------
commit b6a35d9eac4863d925035823717a2e3fe7b5104e
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Wed Sep 3 22:31:23 2014 +0200
Add: Troubleshooting Network Device Naming
Thank you msekleta and lnykryn
>---------------------------------------------------------------
en-US/Consistent_Network_Device_Naming.xml | 56 ++++++++++++++++++++++++++++
1 files changed, 56 insertions(+), 0 deletions(-)
diff --git a/en-US/Consistent_Network_Device_Naming.xml b/en-US/Consistent_Network_Device_Naming.xml
index 6cf8b9f..ac819a5 100644
--- a/en-US/Consistent_Network_Device_Naming.xml
+++ b/en-US/Consistent_Network_Device_Naming.xml
@@ -435,6 +435,62 @@ The name provided by <systemitem class="daemon">systemd-udev</systemitem> will b
</section>
+ <section id="sec_Troubleshooting_Network_Device_Naming">
+ <title>Troubleshooting Network Device Naming</title>
+
+ <para>
+ Predictable interface names will be assigned for each interface, if applicable, as per the procedure described in <xref linkend="sec-Understanding_the_Device_Renaming_Procedure" />. To view the list of possible names <application>udev</application> will use, issue a command in the following form as <systemitem class="username">root</systemitem>:
+ <screen>~]# <command>udevadm info /sys/class/net/<replaceable>ifname</replaceable> | grep ID_NET_NAME</command></screen>
+ where <replaceable>ifname</replaceable> is one of the interfaces listed by the following command:
+ <screen>~]$ <command>ls /sys/class/net/</command></screen>
+ </para>
+ <para>
+ One of the possible names will be applied by <application>udev</application> according to the rules as described in <xref linkend="sec-Understanding_the_Device_Renaming_Procedure" />, and summarized here:
+ <itemizedlist>
+ <listitem>
+ <para>
+ <filename>/usr/lib/udev/rules.d/60-net.rules</filename> - from initscripts,
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <filename>/usr/lib/udev/rules.d/71-biosdevname.rules</filename> - from <application>biosdevname</application>,
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <filename>/usr/lib/udev/rules.d/80-net-name-slot.rules</filename> - from <systemitem class="daemon">systemd</systemitem>
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ <para>
+ From the above list of rule files it can be seen that if interface naming is done via initscripts or <application>biosdevname</application> it always takes precedence over <application>udev</application> native naming. However if initscripts renaming is not taking place and <application>biosdevname</application> is disabled, then to alter the interface names copy the <filename>80-net-name-slot.rules</filename> from <filename class="directory">/usr/</filename> to <filename class="directory">/etc/</filename> and edit the file appropriately. In other words, comment out or arrange schemes to be used in a certain order.
+ </para>
+
+ <example id="ex-Some_interfaces_have_names_from_the_kernel_namespace_while_others_are_successfully_renamed_by_udev">
+ <title>Some interfaces have names from the kernel namespace (eth[0,1,2...]) while others are successfully renamed by udev</title>
+ <para>
+ Mixed up schemes most likely means that either for some hardware there is no usable information provided by the kernel to <application>udev</application>, thus it could not figure out any names, or the information provided to <application>udev</application> is not suitable, for example non-unique device IDs. The latter is more common and the solution is to use a custom naming scheme in ifcfg files or alter which <application>udev</application> scheme is in use by editing 80-net-name-slot.rules.
+ </para>
+
+ </example>
+
+ <example id="ex-In_var-log-messages_or_the_systemd_journal_renaming_is_seen_to_be_done_twice_for_each_interface">
+ <title>In /var/log/messages or the systemd journal, renaming is seen to be done twice for each interface</title>
+ <para>
+ Systems with the naming scheme encoded in ifcfg files but which do not have a regenerated <systemitem class="filesystem">initrd</systemitem> image are likely to encounter this issue. The interface name is initially assigned (via <application>biosdevname</application> or <application>udev</application> or dracut parameters on the kernel command line) during early-boot while still in <systemitem class="filesystem">initrd</systemitem>. Then after switching to real <systemitem class="filesystem">rootfs</systemitem>, renaming is done a second time and a new interface name is determined by the <filename>/usr/lib/udev/rename_device</filename> binary spawned by <application>udev</application> because of processing 60-net.rules. You can safely ignore such messages.
+ </para>
+ </example>
+
+ <example id="ex-Using_naming_scheme_in_ifcfg_files_with_ethX_names_does_not_work">
+ <title>Using naming scheme in ifcfg files with ethX names does not work</title>
+ <para>
+ Use of interface names from kernel namespace is discouraged. To get predictable and stable interface names please use some other prefix than "eth".
+ </para>
+ </example>
+ </section>
+
<!--Topics, Reference-->
<section id="sec-Consistent_Network_Device_Naming-additional_resources">
Repository : http://git.fedorahosted.org/cgit/docs/networking-guide.git
On branch : master
>---------------------------------------------------------------
commit a90280d5f9318dc76bb96f90246123399b80db7e
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Wed Sep 3 22:27:49 2014 +0200
Consistent Network Device Naming
improvements after review by msekleta and lnykryn
>---------------------------------------------------------------
en-US/Consistent_Network_Device_Naming.xml | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/en-US/Consistent_Network_Device_Naming.xml b/en-US/Consistent_Network_Device_Naming.xml
index 4d046ee..6cf8b9f 100644
--- a/en-US/Consistent_Network_Device_Naming.xml
+++ b/en-US/Consistent_Network_Device_Naming.xml
@@ -52,7 +52,7 @@
<para>
- This policy, the procedure outlined above, is the default. If the system has <application>biosdevname</application> enabled, it will take precedence. Note that enabling <application>biosdevname</application> requires passing <command>biosdevname=1</command> as a command line parameter except in the case of a Dell system, where <application>biosdevname</application> will be used by default as long as it is installed. If the user has added <application>udev</application> rules which change the name of the kernel devices, those rules will take precedence too.
+ This policy, the procedure outlined above, is the default. If the system has <application>biosdevname</application> enabled, it will be used. Note that enabling <application>biosdevname</application> requires passing <command>biosdevname=1</command> as a command line parameter except in the case of a Dell system, where <application>biosdevname</application> will be used by default as long as it is installed. If the user has added <application>udev</application> rules which change the name of the kernel devices, those rules will take precedence.
</para>
</section>
@@ -75,15 +75,18 @@
</step>
<step>
<para>
- A rule in <filename>/lib/udev/rules.d/75-net-description.rules</filename> instructs <application>udev</application> to fill in ID_NET_NAME_ONBOARD, ID_NET_NAME_SLOT, ID_NET_NAME_PATH, ID_NET_NAME_MAC by examining the network interface device. Note, that some variables can be empty.
+ A rule in <filename>/lib/udev/rules.d/75-net-description.rules</filename> instructs <application>udev</application> to fill in the internal <application>udev</application> device property values ID_NET_NAME_ONBOARD, ID_NET_NAME_SLOT, ID_NET_NAME_PATH, ID_NET_NAME_MAC by examining the network interface device. Note, that some device properties might be undefined.
</para>
</step>
<step>
<para>
- A rule in <filename>/usr/lib/udev/rules.d/80-net-name-slot.rules</filename> instructs <application>udev</application> to rename the interface, provided that it was not renamed in a previous step, and the kernel parameter <command>net.ifnames=0</command> was not given, according to the following priority: ID_NET_NAME_ONBOARD, ID_NET_NAME_SLOT, ID_NET_NAME_PATH. It falls through to the next in the list, if one is unset. If none of these are set, then the interface will not be renamed.
+ A rule in <filename>/usr/lib/udev/rules.d/80-net-name-slot.rules</filename> instructs <application>udev</application> to rename the interface, provided that it was not renamed in step 1 or 2, and the kernel parameter <command>net.ifnames=0</command> was not given, according to the following priority: ID_NET_NAME_ONBOARD, ID_NET_NAME_SLOT, ID_NET_NAME_PATH. It falls through to the next in the list, if one is unset. If none of these are set, then the interface will not be renamed.
</para>
</step>
</procedure>
+ <para>
+ Steps 3 and 4 are implementing the naming schemes 1, 2, 3, and optionally 4, described in <xref linkend="sec-Naming_Schemes_Hierarchy" />. Step 2 is explained in more detail in <xref linkend="sec-Consistent_Network_Device_Naming_Using_biosdevname" />.
+ </para>
</section>
<section id="sec-Understanding_the_Predictable_Network_Interface_Device_Names">
Repository : http://git.fedorahosted.org/cgit/docs/networking-guide.git
On branch : master
>---------------------------------------------------------------
commit f054da2b2245177fa3c8d6c662dbf1310b94ab6b
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Wed Sep 3 22:23:42 2014 +0200
remove doublespace
>---------------------------------------------------------------
en-US/Configure_Network_Bonding.xml | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/en-US/Configure_Network_Bonding.xml b/en-US/Configure_Network_Bonding.xml
index 17a16d8..85a064c 100644
--- a/en-US/Configure_Network_Bonding.xml
+++ b/en-US/Configure_Network_Bonding.xml
@@ -427,7 +427,7 @@ Then when complete, bring up all the slaves, which will bring up the bond (provi
<screen>~]# <command>nmcli con load /etc/sysconfig/network-scripts/ifcfg-<replaceable>device</replaceable></command></screen>
Alternatively, to reload all interfaces:
<screen>~]# <command>nmcli con reload</command></screen>
- The default behavior is for <application>NetworkManager</application> not to be aware of the changes and to continue using the old configuration data. The is set by the <option>monitor-connection-files</option> option in the <filename>NetworkManager.conf</filename> file. See the <filename>NetworkManager.conf(5)</filename> manual page for more information.
+ The default behavior is for <application>NetworkManager</application> not to be aware of the changes and to continue using the old configuration data. The is set by the <option>monitor-connection-files</option> option in the <filename>NetworkManager.conf</filename> file. See the <filename>NetworkManager.conf(5)</filename> manual page for more information.
</para>
<para>
@@ -962,7 +962,7 @@ This policy is useful for devices that cannot ever alter their MAC address, or f
( <replaceable><source_MAC></replaceable> XOR <replaceable><destination_MAC></replaceable> ))
MODULO <replaceable><slave_count></replaceable>
</screen>
- <para>This algorithm will place all traffic to a particular network peer on the same slave. For non-<systemitem class="protocol">IP</systemitem> traffic, the formula is the same as for the layer2 transmit hash policy.</para>
+ <para>This algorithm will place all traffic to a particular network peer on the same slave. For non-<systemitem class="protocol">IP</systemitem> traffic, the formula is the same as for the layer2 transmit hash policy.</para>
<para>This policy is intended to provide a more balanced distribution of traffic than layer2 alone, especially in environments where a layer3 gateway device is required to reach most destinations.</para>
<para>This algorithm is 802.3ad compliant.</para>
</listitem>
Repository : http://git.fedorahosted.org/cgit/docs/networking-guide.git
On branch : master
>---------------------------------------------------------------
commit 7461bd89631ca2e96753a0ed7e807b6bdcb41df3
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Wed Sep 3 22:20:45 2014 +0200
Add: ad_select
>---------------------------------------------------------------
en-US/Configure_Network_Bonding.xml | 51 +++++++++++++++++++++++++++++++++++
1 files changed, 51 insertions(+), 0 deletions(-)
diff --git a/en-US/Configure_Network_Bonding.xml b/en-US/Configure_Network_Bonding.xml
index 7459981..17a16d8 100644
--- a/en-US/Configure_Network_Bonding.xml
+++ b/en-US/Configure_Network_Bonding.xml
@@ -598,6 +598,57 @@ bond0</screen>
<variablelist
spacing="compact">
<title>Bonding Interface Parameters</title>
+
+
+ <varlistentry>
+ <term>
+ <literal>ad_select=<replaceable><value></replaceable>
+ </literal>
+ </term>
+ <listitem>
+ <para>Specifies the 802.3ad aggregation selection logic to use. Possible values are:
+ <itemizedlist>
+ <listitem>
+ <para>
+ <userinput>stable</userinput> or <userinput>0</userinput> — Default setting. The active aggregator is chosen by largest aggregate bandwidth. Reselection of the active aggregator occurs only when all slaves of the active aggregator are down or if the active aggregator has no slaves.</para>
+ </listitem>
+ <listitem>
+ <para>
+ <userinput>bandwidth</userinput> or <userinput>1</userinput> — The active aggregator is chosen by largest aggregate bandwidth. Reselection occurs if:
+ <itemizedlist>
+ <listitem>
+ <para>
+ A slave is added to or removed from the bond;
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Any slave's link state changes;
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Any slave's 802.3ad association state changes;
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ The bond's administrative state changes to up.
+ </para>
+ </listitem>
+ </itemizedlist></para>
+ </listitem>
+
+ <listitem>
+ <para>
+ <userinput>count</userinput> or <userinput>2</userinput> — The active aggregator is chosen by the largest number of slaves. Reselection occurs as described for the <option>bandwidth</option> setting above.</para>
+ </listitem>
+ </itemizedlist>
+ The <option>bandwidth</option> and <option>count</option> selection policies permit failover of 802.3ad aggregations when partial failure of the active aggregator occurs. This keeps the aggregator with the highest availability, either in bandwidth or in number of slaves, active at all times.
+</para>
+</listitem>
+</varlistentry>
+
<varlistentry>
<term>
<literal>arp_interval=<replaceable><time_in_milliseconds></replaceable>
Repository : http://git.fedorahosted.org/cgit/docs/networking-guide.git
On branch : master
>---------------------------------------------------------------
commit fe40f29d3e397a2c1a7331aa4e5b83a5f4ec8269
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Wed Sep 3 22:18:09 2014 +0200
Add: resend_igmp
>---------------------------------------------------------------
en-US/Configure_Network_Bonding.xml | 17 +++++++++++++++++
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/en-US/Configure_Network_Bonding.xml b/en-US/Configure_Network_Bonding.xml
index 8f7d6e6..7459981 100644
--- a/en-US/Configure_Network_Bonding.xml
+++ b/en-US/Configure_Network_Bonding.xml
@@ -826,6 +826,23 @@ This policy is useful for devices that cannot ever alter their MAC address, or f
class="filesystem">sysfs</systemitem> will cause an immediate selection of the best active slave according to the new policy. This may or may not result in a change of the active slave, depending upon the circumstances</para>
</listitem>
</varlistentry>
+
+<varlistentry>
+ <term>
+ <literal>resend_igmp=<replaceable>range</replaceable></literal></term>
+ <listitem>
+ <para>
+ Specifies the number of IGMP membership reports to be issued after a failover event. One membership report is issued immediately after the failover, subsequent packets are sent in each 200ms interval.
+ </para>
+ <para>
+ The valid range is <literal>0</literal> to <literal>255</literal>; the default value is <literal>1</literal>. A value of <literal>0</literal> prevents the IGMP membership report from being issued in response to the failover event.
+ </para>
+ <para>
+ This option is useful for bonding modes <command>balance-rr</command> (mode 0), <command>active-backup</command> (mode 1), <command>balance-tlb</command> (mode 5) and <command>balance-alb</command> (mode 6), in which a failover can switch the IGMP traffic from one slave to another. Therefore a fresh IGMP report must be issued to cause the switch to forward the incoming IGMP traffic over the newly selected slave.
+ </para>
+ </listitem>
+</varlistentry>
+
<varlistentry>
<term>
<literal>updelay=<replaceable><time_in_milliseconds></replaceable>
Repository : http://git.fedorahosted.org/cgit/docs/networking-guide.git
On branch : master
>---------------------------------------------------------------
commit 6e4c3a964c9daf2441c023fd94adbe509ba407d2
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Wed Sep 3 22:16:35 2014 +0200
Add: fail_over_mac
>---------------------------------------------------------------
en-US/Configure_Network_Bonding.xml | 36 +++++++++++++++++++++++++++++++++++
1 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/en-US/Configure_Network_Bonding.xml b/en-US/Configure_Network_Bonding.xml
index 7afe67e..8f7d6e6 100644
--- a/en-US/Configure_Network_Bonding.xml
+++ b/en-US/Configure_Network_Bonding.xml
@@ -660,6 +660,42 @@ bond0</screen>
<para>Specifies (in milliseconds) how long to wait after link failure before disabling the link. The value must be a multiple of the value specified in the <literal>miimon</literal> parameter. The value is set to <userinput>0</userinput> by default, which disables it.</para>
</listitem>
</varlistentry>
+
+ <varlistentry>
+ <term>
+ <literal>fail_over_mac=<replaceable><value></replaceable>
+ </literal>
+ </term>
+ <listitem>
+ <para>Specifies whether active-backup mode should set all slaves to the same MAC address at enslavement (the traditional behavior), or, when enabled, perform special handling of the bond's MAC address in accordance with the selected policy. Possible values are:
+ <itemizedlist>
+ <listitem>
+ <para>
+ <userinput>none</userinput> or <userinput>0</userinput> — Default setting. This setting disables <literal>fail_over_mac</literal>, and causes bonding to set all slaves of an active-backup bond to the same MAC address at enslavement time.</para>
+ </listitem>
+ <listitem>
+ <para>
+ <userinput>active</userinput> or <userinput>1</userinput> — The <quote>active</quote>> <literal>fail_over_mac</literal> policy indicates that the
+ MAC address of the bond should always be the MAC address of the currently active slave. The MAC address of the slaves is not changed; instead, the MAC address of the bond changes during a failover.</para>
+<para>
+This policy is useful for devices that cannot ever alter their MAC address, or for devices that refuse incoming broadcasts with their own source MAC (which interferes with the ARP monitor). The disadvantage of this policy is that every device on the network must be updated via gratuitous ARP, as opposed to the normal method of switches snooping incoming traffic to update their ARP tables. If the gratuitous ARP is lost, communication may be disrupted.
+</para>
+<para>
+ When this policy is used in conjunction with the MII monitor, devices which assert link up prior to being able to actually transmit and receive are particularly susceptible to loss of the gratuitous ARP, and an appropriate updelay setting may be required.
+ </para>
+
+ </listitem>
+
+ <listitem>
+ <para>
+ <userinput>follow</userinput> or <userinput>2</userinput> — The <quote>follow</quote> <literal>fail_over_mac</literal> policy causes the MAC address of the bond to be selected normally (normally the MAC address of the first slave added to the bond). However, the second and subsequent slaves are not set to this MAC address while they are in a backup role; a slave is programmed with the bond's MAC address at failover time (and the formerly active slave receives the newly active slave's MAC address).</para>
+ <para>
+ This policy is useful for multiport devices that either become confused or incur a performance penalty when multiple ports are programmed with the same MAC address.</para>
+ </listitem>
+ </itemizedlist></para>
+</listitem>
+</varlistentry>
+
<varlistentry>
<term>lacp_rate=<replaceable><value></replaceable>
</term>