[system-administrators-guide] Grub2, apply reviewers feedback
by stephenw
commit b2c7b0bd1d378c7152d9ef28b6a34a1fb03c0e34
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Sun Jan 25 09:44:10 2015 +0100
Grub2, apply reviewers feedback
en-US/Working_with_the_GRUB_2_Boot_Loader.xml | 49 +++++++++++++++----------
1 files changed, 29 insertions(+), 20 deletions(-)
---
diff --git a/en-US/Working_with_the_GRUB_2_Boot_Loader.xml b/en-US/Working_with_the_GRUB_2_Boot_Loader.xml
index f6454b8..30d7ed4 100644
--- a/en-US/Working_with_the_GRUB_2_Boot_Loader.xml
+++ b/en-US/Working_with_the_GRUB_2_Boot_Loader.xml
@@ -67,7 +67,7 @@ menuentry 'Fedora, with Linux 3.17.4-301.fc21.x86_64' --class fedora --class gnu
</programlisting>
<para>
- Each <literal>menuentry</literal> block that represents an installed Linux kernel contains <literal>linux</literal> on 64-bit IBM POWER Series, <literal>linux16</literal> on x86_64 BIOS-based systems, and <literal>linuxefi</literal> on UEFI-based systems. Then the <literal>initrd</literal> directives followed by the path to the kernel and the <systemitem>initramfs</systemitem> image respectively. If a separate <filename>/boot</filename> partition was created, the paths to the kernel and the <systemitem>initramfs</systemitem> image are relative to <filename>/boot</filename>. In the example above, the <literal>initrd /initramfs-3.8.0-0.40.el7.x86_64.img</literal> line means that the <systemitem>initramfs</systemitem> image is actually located at <filename>/boot/initramfs-3.8.0-0.40.el7.x86_64.img</filename> when the root file system is mounted, and likewise for the kernel path.
+ Each <literal>menuentry</literal> block that represents an installed Linux kernel contains <literal>linux</literal> on 64-bit IBM POWER Series, <literal>linux16</literal> on x86_64 BIOS-based systems, and <literal>linuxefi</literal> on UEFI-based systems. Then the <literal>initrd</literal> directives followed by the path to the kernel and the <systemitem>initramfs</systemitem> image respectively. If a separate <filename>/boot</filename> partition was created, the paths to the kernel and the <systemitem>initramfs</systemitem> image are relative to <filename>/boot</filename>. In the example above, the <literal>initrd /initramfs-3.8.0-0.40.el7.x86_64.img</literal> line means that the <systemitem>initramfs</systemitem> image is actually located at <filename>/boot/initramfs-3.8.0-0.40.el7.x86_64.img</filename> when the <systemitem class="username">root</systemitem> file system is mounted, and likewise for the kernel path.
</para>
<para>
The kernel version number as given on the <literal>linux16 /vmlinuz-kernel_version</literal> line must match the version number of the <systemitem>initramfs</systemitem> image given on the <literal>initrd /initramfs-kernel_version.img</literal> line of each <literal>menuentry</literal> block. For more information on how to verify the initial RAM disk image, see <xref
@@ -104,7 +104,7 @@ menuentry 'Fedora, with Linux 3.17.4-301.fc21.x86_64' --class fedora --class gnu
</listitem>
<listitem>
<para>
- <filename>01_users</filename>, which is created only when a boot loader password is assigned in <application>kickstart</application>.
+ <filename>01_users</filename>, which is created only when a boot loader password is assigned in a <application>kickstart</application> file.
</para>
</listitem>
<listitem>
@@ -152,7 +152,7 @@ The <literal>DEFAULTKERNEL</literal> directive specifies what package type will
</para>
<screen>~]# <command>grub2-set-default</command> <literal>2</literal></screen>
<para>
- Note that the position of a menu entry in the list is denoted by a number starting with zero; therefore, in the example above, the third entry will be loaded. This value will be over-written by the name of the next kernel to be installed.
+ Note that the position of a menu entry in the list is denoted by a number starting with zero; therefore, in the example above, the third entry will be loaded. This value will be overwritten by the name of the next kernel to be installed.
</para>
<para>
To force a system to always use a particular menu entry, use the menu entry name as the key to the <literal>GRUB_DEFAULT</literal> directive in the <filename>/etc/default/grub</filename> file. To list the available menu entries, run the following command as <systemitem class="username">root</systemitem>:
@@ -352,6 +352,13 @@ menuentry 'Second custom entry' --class red --class gnu-linux --class gnu --clas
<title>GRUB 2 Password Protection</title>
<para>
GRUB 2 supports both plain-text and encrypted passwords in the GRUB 2 template files. To enable the use of passwords, specify a superuser who can reach the protected entries. Other users can be specified to access these entries as well. Menu entries can be password-protected for booting by adding one or more users to the menu entry as described in <xref linkend="sec-Setting_Up_Users_and_Password_Protection_Specifying_Menu_Entries" />. To use encrypted passwords, see <xref linkend="sec-Password_Encryption" />.</para>
+
+ <warning>
+ <para>
+ If you do not use the correct format for the menu, or modify the configuration in an incorrect way, you might be unable to boot your system.
+ </para>
+ </warning>
+
<para>
All menu entries can be password-protected against changes by setting superusers, which can be done in the <filename>/etc/grub.d/00_header</filename> or the <filename>/etc/grub.d/01_users</filename> file. The <filename>00_header</filename> file is very complicated and, if possible, avoid making modifications in this file. Menu entries should be placed in the <filename>/etc/grub.d/40_custom</filename> and users in the <filename>/etc/grub.d/01_users</filename> file. The <filename>01_users</filename> file is generated by the installation application <application>anaconda</application> when a grub boot loader password is used in a <application>kickstart</application> template (but it should be created and used it if it does not exist). Examples in this section adopt this policy.
</para>
@@ -486,18 +493,14 @@ password_pbkdf2 john grub.pbkdf2.sha512.10000.19074739ED80F115963D984BDCB35AA671
</para>
</step>
</procedure>
- <warning>
- <para>
- If you do not use the correct format, or modify the configuration in an incorrect way, you might be unable to boot your system.
- </para>
- </warning>
+
</section>
</section>
<section id="sec-Reinstalling_GRUB_2">
<title>Reinstalling GRUB 2</title>
<para>
- Reinstalling GRUB 2 might be a useful and easier way to fix certain problems usually caused by an incorrect installation of GRUB 2, missing files, or a broken system. Other reasons to reinstall GRUB 2 include the following:
+ Reinstalling GRUB 2 is a convenient way to fix certain problems usually caused by an incorrect installation of GRUB 2, missing files, or a broken system. Other reasons to reinstall GRUB 2 include the following:
</para>
<itemizedlist>
<listitem>
@@ -535,7 +538,7 @@ password_pbkdf2 john grub.pbkdf2.sha512.10000.19074739ED80F115963D984BDCB35AA671
<section id="sec-Resetting_and_Reinstalling_GRUB_2">
<title>Resetting and Reinstalling GRUB 2</title>
<para>
- This method completely removes all GRUB 2 configuration files and system settings, and is therefore used when the user wants to reset all configuration setting to the default values. Removing of the configuration files and subsequent reinstalling of GRUB 2 fixes failures caused by corrupted files and incorrect configuration. To do so, as <systemitem class="username">root</systemitem>, follow these steps:
+ This method completely removes all GRUB 2 configuration files and system settings. Apply this method to reset all configuration settings to their default values. Removing of the configuration files and subsequent reinstalling of GRUB 2 fixes failures caused by corrupted files and incorrect configuration. To do so, as <systemitem class="username">root</systemitem>, follow these steps:
</para>
<procedure>
@@ -551,7 +554,8 @@ password_pbkdf2 john grub.pbkdf2.sha512.10000.19074739ED80F115963D984BDCB35AA671
</step>
<step>
<para>
- Run the <command>yum reinstall grub2-tools</command> command;
+ For EFI systems <emphasis role="bold">only</emphasis>, run the following command:
+ <screen>~]# <command>yum reinstall grub2-efi shim</command></screen>
</para>
</step>
<step>
@@ -615,9 +619,9 @@ GRUB_SERIAL_COMMAND="serial --speed=9600 --unit=0 --word=8 --parity=no --stop=1"
</listitem>
</itemizedlist>
<note><para>
- This section explains configuring the grub terminal for access over a serial connection but an additional option must be added to the kernel definition to make that kernel monitor a serial connection. For example:
- <synopsis>console=ttyS0,9600n8</synopsis>
-Where <option>console=ttyS0</option> is the serial terminal to be used, <option>9600</option> is the baud rate, <option>n</option> is for no party, and <option>8</option> is the word length in bits.
+ In order to access the grub terminal over a serial connection an additional option must be added to a kernel definition to make that particular kernel monitor a serial connection. For example:
+ <synopsis>console=<replaceable>ttyS0,9600n8</replaceable></synopsis>
+Where <option>console=ttyS0</option> is the serial terminal to be used, <option>9600</option> is the baud rate, <option>n</option> is for no parity, and <option>8</option> is the word length in bits.
For more information on adding kernel options, see <xref linkend="sec-Editing_an_Entry" />. For more information on serial console settings, see <ulink url="https://www.kernel.org/doc/Documentation/serial-console.txt"></ulink> </para>
</note>
@@ -657,7 +661,7 @@ For more information on adding kernel options, see <xref linkend="sec-Editing_an
<section id="sec-Booting_to_Rescue_Mode">
<title>Booting to Rescue Mode</title>
<para>
- Rescue mode provides a convenient single-user environment and allows you to repair your system in situations when it is unable to complete a regular booting process. In rescue mode, the system attempts to mount all local file systems and start some important system services, but it does not activate network interfaces or allow more users to be logged into the system at the same time. In Fedora, rescue mode is equivalent to single user mode and requires the root password.
+ Rescue mode provides a convenient single-user environment and allows you to repair your system in situations when it is unable to complete a normal booting process. In rescue mode, the system attempts to mount all local file systems and start some important system services, but it does not activate network interfaces or allow more users to be logged into the system at the same time. In Fedora, rescue mode is equivalent to single user mode and requires the <systemitem class="username">root</systemitem> password.
</para>
<procedure>
<step>
@@ -688,7 +692,7 @@ For more information on adding kernel options, see <xref linkend="sec-Editing_an
<section id="sec-Booting_to_Emergency_Mode">
<title>Booting to Emergency Mode</title>
<para>
- Emergency mode provides the most minimal environment possible and allows you to repair your system even in situations when the system is unable to enter rescue mode. In emergency mode, the system mounts the root file system only for reading, does not attempt to mount any other local file systems, does not activate network interfaces, and only starts few essential services. In Fedora, emergency mode requires the root password.
+ Emergency mode provides the most minimal environment possible and allows you to repair your system even in situations when the system is unable to enter rescue mode. In emergency mode, the system mounts the <systemitem class="username">root</systemitem> file system only for reading, does not attempt to mount any other local file systems, does not activate network interfaces, and only starts few essential services. In Fedora, emergency mode requires the root password.
</para>
<procedure>
<step>
@@ -726,7 +730,7 @@ For more information on adding kernel options, see <xref linkend="sec-Editing_an
Note that in GRUB 2, resetting the password is no longer performed in single-user mode as it was in GRUB included in Fedora 15 and Red Hat Enterprise Linux 6. The <systemitem class="username">root</systemitem> password is now required to operate in <literal>single-user</literal> mode as well as in <literal>emergency</literal> mode.
</para>
<para>
- Two procedures for changing the <systemitem class="username">root</systemitem> password are shown here. The <xref linkend="proc-Resetting_the_Root_Password_Using_bin_sh" /> procedure creates a chrooted shell using <command>init=/bin/sh</command>. It is the shorter of the two procedures and does not require an SELinux relabel. But this procedure will not work if you have a USB keyboard, encrypted file systems, and does not work in certain virtual machines or systems. The <xref linkend="proc-Resetting_the_Root_Password_Using_rd.break" /> procedure makes use of <command>rd.break</command> to interrupt the boot process before control is passed from <systemitem>initramfs</systemitem> to <systemitem class="service">systemd</systemitem>. The disadvantage of this method is that you have to then change <systemitem class="username">root</systemitem> using the <command>sysroot</command> command.</para>
+ Two procedures for changing the <systemitem class="username">root</systemitem> password are shown here. The <xref linkend="proc-Resetting_the_Root_Password_Using_bin_sh" /> procedure creates a shell, in a changed root environment, using <command>init=/bin/sh</command>. It is the shorter of the two procedures and does not require an SELinux relabel, which can be time consuming. But this procedure will not work if you have a USB keyboard, encrypted file systems, and does not work in certain virtual machines or systems. The <xref linkend="proc-Resetting_the_Root_Password_Using_rd.break" /> procedure makes use of <command>rd.break</command> to interrupt the boot process before control is passed from <systemitem>initramfs</systemitem> to <systemitem class="service">systemd</systemitem>. The disadvantage of this method is that you have to then change <systemitem class="username">root</systemitem> using the <command>sysroot</command> command.</para>
<procedure id="proc-Resetting_the_Root_Password_Using_bin_sh">
<title>Resetting the Root Password Using /bin/sh</title>
<step>
@@ -903,11 +907,16 @@ Updating the password file results in a file with the incorrect SELinux security
<step>
<para>
- Enter the <command>exit</command> command again to resume the initialization and finish the system boot. Note that the SELinux relabeling process can take a long time and a system reboot will occur when complete.
+ Enter the <command>exit</command> command again to resume the initialization and finish the system boot.
</para>
<para>
- With an encrypted system file system, a pass word or phrase is required at this point. However the password prompt might not appear as it is obscured by logging messages. You can press and hold the <keycap>Backspace</keycap> key to see the prompt. Release the key and enter the password for the encrypted file system, while ignoring the logging messages.
+ With an encrypted file system, a pass word or phrase is required at this point. However the password prompt might not appear as it is obscured by logging messages. You can press and hold the <keycap>Backspace</keycap> key to see the prompt. Release the key and enter the password for the encrypted file system, while ignoring the logging messages.
+ </para>
+ <note>
+ <para>
+ Note that the SELinux relabeling process can take a long time. A system reboot will occur automatically when the process is complete.
</para>
+ </note>
</step>
</procedure>
@@ -947,7 +956,7 @@ Updating the password file results in a file with the incorrect SELinux security
</listitem>
</itemizedlist>
<para>
- UEFI Secure Boot does not prevent the installation or removal of second-stage boot loaders, nor require explicit user confirmation of such changes. Signatures are verified during booting, not when the boot loader is installed or updated. Therefore, UEFI Secure Boot does not stop boot path manipulations. It only prevents the system from executing a modified boot path once such a modification has occurred, and simplifies their detection.
+ UEFI Secure Boot does not prevent the installation or removal of second-stage boot loaders, nor require explicit user confirmation of such changes. Signatures are verified during booting, not when the boot loader is installed or updated. Therefore, UEFI Secure Boot does not stop boot path manipulations, it simplifies the detection of changes and prevents the system from executing a modified boot path once such a modification has occurred.
</para>
<section id="sec-UEFI_Secure_Boot_Support_in_Fedora">
9 years, 4 months
[system-administrators-guide] Fix incorrect prompt
by stephenw
commit f5600a4db399fab9c2afb789d3c3eb6e51e6ab0d
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Sun Jan 25 09:33:42 2015 +0100
Fix incorrect prompt
en-US/Working_with_the_GRUB_2_Boot_Loader.xml | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
---
diff --git a/en-US/Working_with_the_GRUB_2_Boot_Loader.xml b/en-US/Working_with_the_GRUB_2_Boot_Loader.xml
index 7185dec..f6454b8 100644
--- a/en-US/Working_with_the_GRUB_2_Boot_Loader.xml
+++ b/en-US/Working_with_the_GRUB_2_Boot_Loader.xml
@@ -868,7 +868,8 @@ For more information on adding kernel options, see <xref linkend="sec-Editing_an
</para>
<para>
Change the file system's <systemitem class="username">root</systemitem> as follows:
- <screen>sh-4.2# <command>chroot /sysroot</command></screen>
+ <screen>switch_root:/# <command>chroot /sysroot</command></screen>
+ The prompt changes to <computeroutput>sh-4.2#</computeroutput>.
</para>
</step>
9 years, 4 months
[firewall-guide] master: Corrected some spelling errors. (4476328)
by Simon Clark
Repository : http://git.fedorahosted.org/cgit/docs/firewall-guide.git
On branch : master
>---------------------------------------------------------------
commit 447632875918bc6f19554016563176090314f0e0
Author: Simon Clark <simon.richard.clark(a)gmail.com>
Date: Fri Jan 23 17:50:45 2015 +0000
Corrected some spelling errors.
>---------------------------------------------------------------
en-US/Using_Firewalls.xml | 77 ++++++++++++++++++++-------------------------
1 files changed, 34 insertions(+), 43 deletions(-)
diff --git a/en-US/Using_Firewalls.xml b/en-US/Using_Firewalls.xml
index 3bef0ab..35e0a2d 100644
--- a/en-US/Using_Firewalls.xml
+++ b/en-US/Using_Firewalls.xml
@@ -1,68 +1,59 @@
-<?xml version='1.0' encoding='utf-8' ?>
+<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE section PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
+<!ENTITY % BOOK_ENTITIES SYSTEM "firewall-guide.ent">
]>
-
<chapter id="chapt-Documentation-Firewall_Guide-Using_Firewalls">
-<title>Using Firewalls</title>
-<section id="sec-Introduction_to_firewalld">
-<title>Introduction to firewalld</title>
-<para>
+ <title>Using Firewalls</title>
+ <section id="sec-Introduction_to_firewalld">
+ <title>Introduction to firewalld</title>
+ <para>
The dynamic firewall daemon <systemitem class="daemon">firewalld</systemitem> provides a dynamically managed firewall with support for network zones to assign a level of trust to a network and its associated connections and interfaces. It has support for <systemitem class="protocol">IPv4</systemitem> and <systemitem class="protocol">IPv6</systemitem> firewall settings. It supports Ethernet bridges and has a separation of runtime and permanent configuration options. It also has an interface for services or applications to add firewall rules directly.
</para>
-</section>
-
-<section id="sec-Understanding_firewalld">
- <title>Understanding firewalld</title>
- <para>
+ <para>
+ The firewall daemon manages the firewall dynamically, which means that it can apply changes without restarting the whole firewall. Therefore there is no need to reload all firewall kernel modules for every change. However, using a firewall daemon requires that all firewall modifications are done with that daemon to make sure that the state in the daemon and the firewall in kernel are in sync. The firewall daemon can not parse firewall rules added by the <application>iptables</application> and <application>ebtables</application> command line tools.
+</para>
+ <para>
+ The daemon provides information about the current active firewall settings via <application>D-BUS</application> and also accepts changes via <application>D-BUS</application> using <application>PolicyKit</application> authentication methods.
+</para>
+ </section>
+ <section id="sec-Understanding_firewalld">
+ <title>Understanding firewalld</title>
+ <para>
A graphical configuration tool, <application>firewall-config</application>, is used to configure <systemitem class="daemon">firewalld</systemitem>, which in turn uses <application>iptables tool</application> to communicate with <application>Netfilter</application> in the kernel which implements packet filtering.</para>
- <para>
+ <para>
To use the graphical <application>firewall-config</application> tool, press the super key and start typing <command>firewall</command>. The firewall icon will appear. Press enter once it is highlighted. The <application>firewall-config</application> tool appears. You will be prompted for your user password. <remark>Tested on Fedora 19 </remark> </para>
- <para>
+ <para>
The <application>firewall-config</application> tool has drop a down selection menu labeled <guilabel>Current View</guilabel>. This enables selecting between <guibutton>Runtime Configuration</guibutton> and <guibutton>Permanent Configuration</guibutton> mode. Notice that if you select <guibutton>Permanent Configuration</guibutton>, an <guibutton>Edit Services</guibutton> button appears on the right hand side of the <guilabel>Services</guilabel> tab and an <guibutton>Edit ICMP Types</guibutton> button appears on the right hand side of the <guilabel>ICMP Filter</guilabel> tab. The reason these buttons only appear in permanent configuration mode is that runtime changes are limited to enabling or disabling a service. You cannot change a service's parameters in run time mode.
</para>
-
- <para>
+ <para>
The firewall service provided by <systemitem class="daemon">firewalld</systemitem> is dynamic rather than static because changes to the configuration can be made at anytime and are immediately implemented, there is no need to save or apply the changes. No unintended disruption of existing network connections occurs as no part of the firewall has to be reloaded.</para>
- <para>
+ <para>
There is also an applet, <application>firewall-applet</application>, which can be used to quickly launch the <application>NetworkManager</application> configuration tab for the network connection in use. From the <guilabel>General</guilabel> tab changes to the assigned firewall zone can be made. This applet is not installed by default in &PRODUCT;. <remark>this may change</remark></para>
- <para>
+ <para>
A command line client, <application>firewall-cmd</application>, is provided. It can be used to make permanent and non-permanent run-time changes as explained in <filename>man firewall-cmd(1)</filename>. Permanent changes need to be made as explained in <filename>man firewalld(1)</filename>.
</para>
- <para>
+ <para>
The configuration for <systemitem class="daemon">firewalld</systemitem> is stored in various XML files in <filename>/usr/lib/firewalld/</filename> and <filename>/etc/firewalld/</filename>. This allows a great deal of flexibility as the files can be edited, written to, backed up, used as templates for other installations and so on.
</para>
- <para>
+ <para>
Other applications can communicate with <systemitem class="daemon">firewalld</systemitem> using D-bus. <remark>Where can users find more info about this?</remark>
</para>
-
-</section>
-
-<section id="sec-Comparison_of_Firewalld_to_system-config-firewall">
- <title>Comparison of Firewalld to system-config-firewall and iptables</title>
- <para>
+ </section>
+ <section id="sec-Comparison_of_Firewalld_to_system-config-firewall">
+ <title>Comparison of Firewalld to system-config-firewall and iptables</title>
+ <para>
The essential differences between <systemitem class="daemon">firewalld</systemitem> and the <application>iptables service</application>
are:
- <itemizedlist>
- <listitem>
- <para>
- The <application>iptables service</application> stores configuration in <filename>/etc/sysconfig/iptables</filename> while <systemitem class="daemon">firewalld</systemitem> stores it in various XML files in <filename class='directory'>/usr/lib/firewalld/</filename> and <filename class='directory'>/etc/firewalld/</filename>. Note that the <filename>/etc/sysconfig/iptables</filename> file does not exist as <systemitem class="daemon">firewalld</systemitem> is installed be default on &PRODUCT;.
- </para>
- </listitem>
- <listitem>
- <para>
+ <itemizedlist><listitem><para>
+ The <application>iptables service</application> stores configuration in <filename>/etc/sysconfig/iptables</filename> while <systemitem class="daemon">firewalld</systemitem> stores it in various XML files in <filename class="directory">/usr/lib/firewalld/</filename> and <filename class="directory">/etc/firewalld/</filename>. Note that the <filename>/etc/sysconfig/iptables</filename> file does not exist as <systemitem class="daemon">firewalld</systemitem> is installed by default on &PRODUCT;.
+ </para></listitem><listitem><para>
With the <application>iptables service</application>, every single change means flushing all the old rules and reading all the new rules from <filename>/etc/sysconfig/iptables</filename> while with <systemitem class="daemon">firewalld</systemitem> there is no re-creating of all the rules; only the differences are applied. Consequently, <systemitem class="daemon">firewalld</systemitem> can change the settings during run time without existing connections being lost.
- </para>
-</listitem>
- </itemizedlist>
+ </para></listitem></itemizedlist>
Both use <application>iptables tool</application> to talk to the kernel packet filter.
</para>
-<!--<para>
+ <!--<para>
<remark>Insert diagram from Jiri Popelka showing the hierarchy of applications above the kernel packet filter that go to make up the firewall implementation</remark>
</para> -->
-</section>
-
-
-
-
- <!--Topics, Reference-->
+ </section>
+ <!--Topics, Reference-->
</chapter>
9 years, 4 months
[networking-guide] 21: Remove out-of-date content (1734af6)
by stephenw
Repository : http://git.fedorahosted.org/cgit/docs/networking-guide.git
On branch : 21
>---------------------------------------------------------------
commit 1734af61c4504c91a221c75b24feceeaea4a0982
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Mon Jan 19 11:03:07 2015 +0100
Remove out-of-date content
>---------------------------------------------------------------
en-US/Preface.xml | 17 -----------------
1 files changed, 0 insertions(+), 17 deletions(-)
diff --git a/en-US/Preface.xml b/en-US/Preface.xml
index 7a46119..c5cab2a 100644
--- a/en-US/Preface.xml
+++ b/en-US/Preface.xml
@@ -43,23 +43,6 @@
</para>
</section>
- <section id="sec-Whats-New">
- <title>What's new in Fedora 20</title>
- <para>
- <firstterm>Network Teaming</firstterm> has been introduced as an alternative to bonding for link aggregation. It is designed to be easy to maintain, debug and extend. For the user it offers performance and flexibility improvements and should be evaluated for all new installations.
- </para>
- <para>
- A new command-line tool, <application>nmcli</application>, has been introduced to allow users and scripts to interact with <application>NetworkManager</application>. A simple curses-based user interface for <application>NetworkManager</application>, <command>nmtui</command>, is also available.
- </para>
- <para>
- A number of improvements have been made to <application>NetworkManager</application> to make it more suitable for use in server applications. In particular, <application>NetworkManager</application> no longer watches for configuration file changes by default, such as those made by editors or deployment tools. It allows administrators to make it aware of external changes through the <command>nmcli connection reload</command> command. Changes made through <application>NetworkManager</application>'s D-Bus API or with <application>nmcli</application> are still effective immediately.
- </para>
- <para>
- Not included in this guide, but of interest to network administrators, is the new <firstterm>Open Linux Management Infrastructure</firstterm> or <application>OpenLMI</application> project. This is an implementation of open industry standards for remote system management, which includes an agent for networking. See the <citetitle pubwork="book">&MAJOROSVER; System Administrator's Guide</citetitle> for information on the OpenLMI Networking Provider.
- </para>
-
-
- </section>
<section id="sec-Preface-Book_Organization">
<title>How to Read this Book</title>
9 years, 4 months
[networking-guide] master: Remove out-of-date content (ffd68ab)
by stephenw
Repository : http://git.fedorahosted.org/cgit/docs/networking-guide.git
On branch : master
>---------------------------------------------------------------
commit ffd68aba8e83f3a494555fa82d94d22af65cad6c
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Mon Jan 19 11:03:07 2015 +0100
Remove out-of-date content
>---------------------------------------------------------------
en-US/Preface.xml | 17 -----------------
1 files changed, 0 insertions(+), 17 deletions(-)
diff --git a/en-US/Preface.xml b/en-US/Preface.xml
index 7a46119..c5cab2a 100644
--- a/en-US/Preface.xml
+++ b/en-US/Preface.xml
@@ -43,23 +43,6 @@
</para>
</section>
- <section id="sec-Whats-New">
- <title>What's new in Fedora 20</title>
- <para>
- <firstterm>Network Teaming</firstterm> has been introduced as an alternative to bonding for link aggregation. It is designed to be easy to maintain, debug and extend. For the user it offers performance and flexibility improvements and should be evaluated for all new installations.
- </para>
- <para>
- A new command-line tool, <application>nmcli</application>, has been introduced to allow users and scripts to interact with <application>NetworkManager</application>. A simple curses-based user interface for <application>NetworkManager</application>, <command>nmtui</command>, is also available.
- </para>
- <para>
- A number of improvements have been made to <application>NetworkManager</application> to make it more suitable for use in server applications. In particular, <application>NetworkManager</application> no longer watches for configuration file changes by default, such as those made by editors or deployment tools. It allows administrators to make it aware of external changes through the <command>nmcli connection reload</command> command. Changes made through <application>NetworkManager</application>'s D-Bus API or with <application>nmcli</application> are still effective immediately.
- </para>
- <para>
- Not included in this guide, but of interest to network administrators, is the new <firstterm>Open Linux Management Infrastructure</firstterm> or <application>OpenLMI</application> project. This is an implementation of open industry standards for remote system management, which includes an agent for networking. See the <citetitle pubwork="book">&MAJOROSVER; System Administrator's Guide</citetitle> for information on the OpenLMI Networking Provider.
- </para>
-
-
- </section>
<section id="sec-Preface-Book_Organization">
<title>How to Read this Book</title>
9 years, 4 months
[networking-guide] master: USERCTL=yes can still be used (3c170a0)
by stephenw
Repository : http://git.fedorahosted.org/cgit/docs/networking-guide.git
On branch : master
>---------------------------------------------------------------
commit 3c170a0f973675de7ad76e10142efbaf87ca687c
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Sun Jan 18 18:29:20 2015 +0100
USERCTL=yes can still be used
The default action is 'no'
sudo grep usernetctl /etc/sysconfig/network-scripts/*
will show its usage in ifup and ifdown.
>---------------------------------------------------------------
en-US/Configure_Networking.xml | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/en-US/Configure_Networking.xml b/en-US/Configure_Networking.xml
index 394d66a..16800f7 100644
--- a/en-US/Configure_Networking.xml
+++ b/en-US/Configure_Networking.xml
@@ -1585,7 +1585,8 @@ ONBOOT=yes
PREFIX=24
IPADDR=10.0.1.27
</programlisting>
-Optionally specify the hardware or MAC address using the <command>HWADDR</command> directive. Note that this may influence the device naming procedure as explained in <xref linkend="ch-Consistent_Network_Device_Naming" />. You do not need to specify the network or broadcast address as this is calculated automatically by <application>ipcalc</application>.
+Optionally specify the hardware or MAC address using the <command>HWADDR</command> directive. Note that this may influence the device naming procedure as explained in <xref linkend="ch-Consistent_Network_Device_Naming" />. You do not need to specify the network or broadcast address as this is calculated automatically by <application>ipcalc</application>. To enable a normal user to set the interface up or down, add <command>USERCTL=yes</command>.
+
</para>
<bridgehead id="bh-Dynamic_Network_Settings">Dynamic Network Settings</bridgehead>
9 years, 4 months
[networking-guide] 21: USERCTL=yes can still be used (86a1386)
by stephenw
Repository : http://git.fedorahosted.org/cgit/docs/networking-guide.git
On branch : 21
>---------------------------------------------------------------
commit 86a1386dc233226a67147341dd4ae2e1b9779c67
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Sun Jan 18 18:29:20 2015 +0100
USERCTL=yes can still be used
The default action is 'no'
sudo grep usernetctl /etc/sysconfig/network-scripts/*
will show its usage in ifup and ifdown.
>---------------------------------------------------------------
en-US/Configure_Networking.xml | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/en-US/Configure_Networking.xml b/en-US/Configure_Networking.xml
index 394d66a..16800f7 100644
--- a/en-US/Configure_Networking.xml
+++ b/en-US/Configure_Networking.xml
@@ -1585,7 +1585,8 @@ ONBOOT=yes
PREFIX=24
IPADDR=10.0.1.27
</programlisting>
-Optionally specify the hardware or MAC address using the <command>HWADDR</command> directive. Note that this may influence the device naming procedure as explained in <xref linkend="ch-Consistent_Network_Device_Naming" />. You do not need to specify the network or broadcast address as this is calculated automatically by <application>ipcalc</application>.
+Optionally specify the hardware or MAC address using the <command>HWADDR</command> directive. Note that this may influence the device naming procedure as explained in <xref linkend="ch-Consistent_Network_Device_Naming" />. You do not need to specify the network or broadcast address as this is calculated automatically by <application>ipcalc</application>. To enable a normal user to set the interface up or down, add <command>USERCTL=yes</command>.
+
</para>
<bridgehead id="bh-Dynamic_Network_Settings">Dynamic Network Settings</bridgehead>
9 years, 4 months
[networking-guide] 21: Update entities to 21 and year to 2015 (0fa47d0)
by stephenw
Repository : http://git.fedorahosted.org/cgit/docs/networking-guide.git
On branch : 21
>---------------------------------------------------------------
commit 0fa47d055890bd3659798440619fe65b7c72386e
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Sun Jan 18 15:59:04 2015 +0100
Update entities to 21 and year to 2015
>---------------------------------------------------------------
en-US/Networking_Guide.ent | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/en-US/Networking_Guide.ent b/en-US/Networking_Guide.ent
index b961ceb..7971cc0 100644
--- a/en-US/Networking_Guide.ent
+++ b/en-US/Networking_Guide.ent
@@ -1,13 +1,13 @@
<!-- Obligatory Entities: -->
<!ENTITY PRODUCT "Fedora Documentation">
<!ENTITY BOOKID "networking-guide">
-<!ENTITY YEAR "2014">
+<!ENTITY YEAR "2015">
<!ENTITY HOLDER "Red Hat, Inc. and others">
<!ENTITY BUGZILLA '<ulink url="https://bugzilla.redhat.com/enter_bug.cgi?product=&PRODUCT;&component...;" />'>
<!ENTITY BZURL 'https://bugzilla.redhat.com/enter_bug.cgi?product=&PRODUCT;&component...;'>
<!-- Additional Entities: -->
<!ENTITY MAJOROS "Fedora">
-<!ENTITY MAJOROSVER "Fedora 20">
+<!ENTITY MAJOROSVER "Fedora 21">
<!ENTITY OSORG "The Fedora Project">
-<!ENTITY PKGOS "fc20">
-<!ENTITY PRODVER "20">
+<!ENTITY PKGOS "fc21">
+<!ENTITY PRODVER "21">
9 years, 4 months
[networking-guide] 21: Subtitle should be title case (1d59157)
by stephenw
Repository : http://git.fedorahosted.org/cgit/docs/networking-guide.git
On branch : 21
>---------------------------------------------------------------
commit 1d591578ec5cde0e162031c51c120efbf03aeac6
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Sun Jan 18 15:59:58 2015 +0100
Subtitle should be title case
>---------------------------------------------------------------
en-US/Book_Info.xml | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/en-US/Book_Info.xml b/en-US/Book_Info.xml
index 605a034..f2f84da 100644
--- a/en-US/Book_Info.xml
+++ b/en-US/Book_Info.xml
@@ -5,7 +5,7 @@
]>
<bookinfo>
<title>Networking Guide</title>
- <subtitle>Configuration and Administration of networking for &MAJOROSVER;</subtitle>
+ <subtitle>Configuration and Administration of Networking for &MAJOROSVER;</subtitle>
<productname>Fedora</productname>
<productnumber>21</productnumber>
<edition>2</edition>
9 years, 4 months
[networking-guide] master: Subtitle should be title case (2ac3092)
by stephenw
Repository : http://git.fedorahosted.org/cgit/docs/networking-guide.git
On branch : master
>---------------------------------------------------------------
commit 2ac30926da4c33eea4c58cd90f1baf4bb426a425
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Sun Jan 18 15:59:58 2015 +0100
Subtitle should be title case
>---------------------------------------------------------------
en-US/Book_Info.xml | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/en-US/Book_Info.xml b/en-US/Book_Info.xml
index 605a034..f2f84da 100644
--- a/en-US/Book_Info.xml
+++ b/en-US/Book_Info.xml
@@ -5,7 +5,7 @@
]>
<bookinfo>
<title>Networking Guide</title>
- <subtitle>Configuration and Administration of networking for &MAJOROSVER;</subtitle>
+ <subtitle>Configuration and Administration of Networking for &MAJOROSVER;</subtitle>
<productname>Fedora</productname>
<productnumber>21</productnumber>
<edition>2</edition>
9 years, 4 months