[securityguide] Reworded the yum-plugin-security portion and added a notification regarding this functionality not w
by Eric Christensen
commit cdaaa5bd8d455cc72c2081d0486cc1bd3813f991
Author: Eric H Christensen <sparks(a)redhat.com>
Date: Tue Sep 30 09:32:07 2014 -0400
Reworded the yum-plugin-security portion and added a notification regarding this functionality not working in third-party repositories (BZ 1124344)
Signed-off-by: Eric H Christensen <sparks(a)redhat.com>
en-US/CVE.xml | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
---
diff --git a/en-US/CVE.xml b/en-US/CVE.xml
index 73e6ce8..3739575 100644
--- a/en-US/CVE.xml
+++ b/en-US/CVE.xml
@@ -3,7 +3,7 @@
]>
<chapter id="chap-Security_Guide-CVE">
- <title>Common Vulnerabilities and Exposures</title>
+ <title>Common Vulnerabilities and Exposures (CVEs)</title>
<para>
The Common Vulnerabilities and Exposures or CVE system provides a reference method for publicly-known information security vulnerabilities and exposures. ITRE Corporation maintains the system, with funding from the National Cyber Security Division of the United States Department of Homeland Security.
</para>
@@ -13,8 +13,9 @@
<section id="sect-Security_Guide-CVE-yum_plugin">
<title>YUM Plugin</title>
<para>
- The <package>yum-plugin-security</package> package is a feature of &PRODUCT;. If installed, the yum module provided by this package can be used to limit yum to retrieve only security-related updates. It can also be used to provide information about which Red Hat advisory, which bug in Red Hat’s Bugzilla database, or which CVE number from MITRE’s Common Vulnerabilities and Exposures directory is addressed by a package update.
+ The <package>yum-plugin-security</package> package allows the administrator to only see what updates are security updates (no bugfix or enhancement updates). It can also be used to provide information about which &PRODUCT; advisory, which bug in Red Hat’s Bugzilla database, or which CVE number is addressed by a package update.
</para>
+ <important><para>This feature currently only works on Fedora, Red Hat, and EPEL repositories. Other repositories may or may not provide the necessary flags on their packages to allow such filtering. When using third-party repos it's important to check for updates as using this plugin may allow some security updates to be missed.</para></important>
<para>
Enabling these features is as simple as running the <command>yum install yum-plugin-security</command> command.
</para>
9 years, 5 months
[networking-guide] master: Improve: Running Network Script (3789528)
by stephenw
Repository : http://git.fedorahosted.org/cgit/docs/networking-guide.git
On branch : master
>---------------------------------------------------------------
commit 378952868542edca648ad8a9a99bdfea386ec82d
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Mon Sep 29 22:40:39 2014 +0200
Improve: Running Network Script
>---------------------------------------------------------------
en-US/Introduction_to_Fedora_Networking.xml | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/en-US/Introduction_to_Fedora_Networking.xml b/en-US/Introduction_to_Fedora_Networking.xml
index deb2e4c..df7b089 100644
--- a/en-US/Introduction_to_Fedora_Networking.xml
+++ b/en-US/Introduction_to_Fedora_Networking.xml
@@ -166,7 +166,9 @@ In previous Red Hat Enterprise Linux releases, the default way to conf
</para>
<bridgehead id="bh-Running_Network_Script">Running Network Script</bridgehead>
<para>
-Run the script with the <command>systemctl <option>start|stop|restart|status</option> network</command> wrapper to clear any existing environment variables and ensure clean execution. Do not run any service by calling <command>/etc/init.d/<replaceable>servicename</replaceable> <option>start|stop|restart|status</option></command> directly.
+Run the script <emphasis role="bold">only</emphasis> with the <application>systemctl</application> utility which will clear any existing environment variables and ensure clean execution. The command takes the following form:
+<synopsis><command>systemctl <option>start|stop|restart|status</option> network</command></synopsis></para>
+<para><emphasis role="bold">Do not run</emphasis> any service by calling <command>/etc/init.d/<replaceable>servicename</replaceable> <option>start|stop|restart|status</option></command> directly.
</para>
<para>
Note that in Red Hat Enterprise Linux 7, <application>NetworkManager</application> is started first, and <filename>/etc/init.d/network</filename> checks with <application>NetworkManager</application> to avoid tampering with <application>NetworkManager</application>'s connections. <application>NetworkManager</application> is intended to be the primary application using sysconfig configuration files and <filename>/etc/init.d/network</filename> is intended to be secondary, playing a fallback role.
9 years, 5 months
[networking-guide] master: Typo: are only executed when (75e32ba)
by stephenw
Repository : http://git.fedorahosted.org/cgit/docs/networking-guide.git
On branch : master
>---------------------------------------------------------------
commit 75e32ba67d2f4937408025496926127de8088957
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Mon Sep 29 22:39:51 2014 +0200
Typo: are only executed when
>---------------------------------------------------------------
en-US/Introduction_to_Fedora_Networking.xml | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/en-US/Introduction_to_Fedora_Networking.xml b/en-US/Introduction_to_Fedora_Networking.xml
index d34a13c..deb2e4c 100644
--- a/en-US/Introduction_to_Fedora_Networking.xml
+++ b/en-US/Introduction_to_Fedora_Networking.xml
@@ -192,7 +192,7 @@ The <filename>/etc/init.d/network</filename> script is not event-driven, it runs
</para>
<bridgehead id="bh-Custom_Commands_and_the_Network_Scripts">Custom Commands and the Network Scripts</bridgehead>
<para>
- Custom commands in the scripts <filename>/sbin/ifup-local</filename>, <filename>ifdown-pre-local</filename>, and <filename>ifdown-local</filename> are only be executed when those devices are controlled by the <systemitem class="daemon">/etc/init.d/network</systemitem> service. If you modified the initscripts themselves (for example, <filename>/etc/sysconfig/network-scripts/ifup-eth</filename>) then those changes would be overwritten by an <package>initscripts</package> package update. Therefore it is recommend that you avoid modifying the initscripts directly. However, the whole idea of the <filename>/sbin/if*local</filename> scripts is so you can make custom changes which survive package updates. The initscripts just check for the presence of the relevant <filename>/sbin/if*local</filename> and run them if they exit. The initscripts do not place anything in the <filename>/sbin/if*local</filename> scripts, nor does the <package>initscripts</package> RPM (or any package)
own or modify those files.
+ Custom commands in the scripts <filename>/sbin/ifup-local</filename>, <filename>ifdown-pre-local</filename>, and <filename>ifdown-local</filename> are only executed when those devices are controlled by the <systemitem class="daemon">/etc/init.d/network</systemitem> service. If you modified the initscripts themselves (for example, <filename>/etc/sysconfig/network-scripts/ifup-eth</filename>) then those changes would be overwritten by an <package>initscripts</package> package update. Therefore it is recommend that you avoid modifying the initscripts directly and make use of the <filename>/sbin/if*local</filename> scripts, so that your custom changes will survive package updates. The initscripts just check for the presence of the relevant <filename>/sbin/if*local</filename> and run them if they exit. The initscripts do not place anything in the <filename>/sbin/if*local</filename> scripts, nor does the <package>initscripts</package> RPM (or any package) own or modify those
files.
</para>
<para>
There are ways to perform custom tasks when network connections go up and down, both with the old network scripts and with <application>NetworkManager</application>. When <application>NetworkManager</application> is enabled, the <filename>ifup</filename> and <filename>ifdown</filename> script will ask <application>NetworkManager</application> whether <application>NetworkManager</application> manages the interface in question, which is found from the <quote>DEVICE=</quote> line in the <filename>ifcfg</filename> file. If <application>NetworkManager</application> does manage that device, and the device is not already connected, then <filename>ifup</filename> will ask <application>NetworkManager</application> to start the connection.
9 years, 5 months
[networking-guide] master: command-line <blah> is an adjective (ba85655)
by stephenw
Repository : http://git.fedorahosted.org/cgit/docs/networking-guide.git
On branch : master
>---------------------------------------------------------------
commit ba85655617823f00bebf4866fa19f2fe6871ccca
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Mon Sep 29 22:56:12 2014 +0200
command-line <blah> is an adjective
>---------------------------------------------------------------
en-US/BIND.xml | 4 ++--
en-US/Configure_Network_Teaming.xml | 4 ++--
en-US/Configure_Networking.xml | 2 +-
en-US/DHCP_Servers.xml | 4 ++--
en-US/Introduction_to_Fedora_Networking.xml | 10 +++++-----
en-US/Preface.xml | 16 ++++++++--------
6 files changed, 20 insertions(+), 20 deletions(-)
diff --git a/en-US/BIND.xml b/en-US/BIND.xml
index 9da88fa..9da41ff 100644
--- a/en-US/BIND.xml
+++ b/en-US/BIND.xml
@@ -1541,7 +1541,7 @@ $TTL 86400
<tertiary><command>rndc</command></tertiary>
</indexterm>
<para>
- The <command>rndc</command> utility is a command line tool that allows you to administer the <systemitem class="service">named</systemitem> service, both locally and from a remote machine. Its usage is as follows:
+ The <command>rndc</command> utility is a command-line tool that allows you to administer the <systemitem class="service">named</systemitem> service, both locally and from a remote machine. Its usage is as follows:
</para>
<screen><command>rndc</command> [<replaceable>option</replaceable>...] <replaceable>command</replaceable> [<replaceable>command-option</replaceable>]</screen>
<section id="sec-bind-rndc-configuration">
@@ -1724,7 +1724,7 @@ The zone reload and thaw was successful.</screen>
<tertiary><command>dig</command></tertiary>
</indexterm>
<para>
- The <command>dig</command> utility is a command line tool that allows you to perform <systemitem class="protocol">DNS</systemitem> lookups and debug a nameserver configuration. Its typical usage is as follows:
+ The <command>dig</command> utility is a command-line tool that allows you to perform <systemitem class="protocol">DNS</systemitem> lookups and debug a nameserver configuration. Its typical usage is as follows:
</para>
<screen><command>dig</command> [@<replaceable>server</replaceable>] [<replaceable>option</replaceable>...] <replaceable>name</replaceable> <replaceable>type</replaceable></screen>
<para>
diff --git a/en-US/Configure_Network_Teaming.xml b/en-US/Configure_Network_Teaming.xml
index 6a13c4a..b90ebd9 100644
--- a/en-US/Configure_Network_Teaming.xml
+++ b/en-US/Configure_Network_Teaming.xml
@@ -232,7 +232,7 @@ From the available interfaces, determine which are suitable for adding to your n
</para>
<para>
- <emphasis role="bold">To create a network team using the command line tool</emphasis>, <application>nmcli</application>, proceed to <xref linkend="sec-Configure_Network_Teaming_Using_nmcli"/>.
+ <emphasis role="bold">To create a network team using the command-line tool</emphasis>, <application>nmcli</application>, proceed to <xref linkend="sec-Configure_Network_Teaming_Using_nmcli"/>.
</para>
</section>
@@ -490,7 +490,7 @@ runner:
</para>
<para>
- For help on command line options for <systemitem class="daemon">teamd</systemitem>, issue the following command:
+ For help on command-line options for <systemitem class="daemon">teamd</systemitem>, issue the following command:
<screen>~]$ <command>teamd -h</command></screen>
In addition, see the <filename>teamd(8)</filename> man page.
</para>
diff --git a/en-US/Configure_Networking.xml b/en-US/Configure_Networking.xml
index 7ee62e2..680c111 100644
--- a/en-US/Configure_Networking.xml
+++ b/en-US/Configure_Networking.xml
@@ -51,7 +51,7 @@
</listitem>
<listitem>
<para>
- To configure an interface using <application>NetworkManager</application>'s command line tool, <application>nmcli</application>, proceed to <xref linkend="sec-Using_the_NetworkManager_Command_Line_Tool_nmcli" />
+ To configure an interface using <application>NetworkManager</application>'s command-line tool, <application>nmcli</application>, proceed to <xref linkend="sec-Using_the_NetworkManager_Command_Line_Tool_nmcli" />
</para>
</listitem>
</itemizedlist>
diff --git a/en-US/DHCP_Servers.xml b/en-US/DHCP_Servers.xml
index c0de39f..34f4844 100644
--- a/en-US/DHCP_Servers.xml
+++ b/en-US/DHCP_Servers.xml
@@ -241,12 +241,12 @@ subnet 192.168.1.0 netmask 255.255.255.0 {
</indexterm>
<indexterm>
<primary>DHCP</primary>
- <secondary>command line options</secondary>
+ <secondary>command-line options</secondary>
</indexterm>
<para>If more than one network interface is attached to the system, but the <systemitem class="protocol">DHCP</systemitem> server should only listen for <systemitem class="protocol">DHCP</systemitem> requests on one of the interfaces, configure the <systemitem class="protocol">DHCP</systemitem> server to listen only on that device. The <systemitem class="protocol">DHCP</systemitem> daemon will only listen on interfaces for which it finds a subnet declaration in the <filename>/etc/dhcp/dhcpd.conf</filename> file.</para>
<para>This is useful for a firewall machine with two network cards. One network card can be configured as a <systemitem class="protocol">DHCP</systemitem> client to retrieve an <systemitem class="protocol">IP</systemitem> address to the Internet. The other network card can be used as a <systemitem class="protocol">DHCP</systemitem> server for the internal network behind the firewall. Specifying only the network card connected to the internal network makes the system more secure because users can not connect to the daemon via the Internet.</para>
<para>
- To specify command line options, copy and then edit the <filename>dhcpd.service</filename> file as the <systemitem class="username">root</systemitem> user. For example, as follows:
+ To specify command-line options, copy and then edit the <filename>dhcpd.service</filename> file as the <systemitem class="username">root</systemitem> user. For example, as follows:
<screen>~]# <command>cp /usr/lib/systemd/system/dhcpd.service /etc/systemd/system/</command>
~]# <command>vi /etc/systemd/system/dhcpd.service</command></screen>
Edit the line under section [Service]:
diff --git a/en-US/Introduction_to_Fedora_Networking.xml b/en-US/Introduction_to_Fedora_Networking.xml
index bbec4cb..d34a13c 100644
--- a/en-US/Introduction_to_Fedora_Networking.xml
+++ b/en-US/Introduction_to_Fedora_Networking.xml
@@ -15,7 +15,7 @@
The material is grouped according to the goal rather than the method. Instructions on how to achieve a specific task using different methods are grouped together. This is intended to make it easier for you to find the information on how to achieve a particular task or goal, and at the same time allow you to quickly see the different methods available.</para>
<para>
In each chapter, the configuration methods will be presented in the following order:
- A graphical user interface (GUI) method, such as the use of <application>nm-connection-editor</application> or <application>control-network</application> to direct <systemitem class="service">NetworkManager</systemitem>, then <application>NetworkManager</application>'s command line tool <application>nmcli</application>, and then finally methods using the command line and configuration files. The command line can be used to issue commands and to compose or edit configuration files, therefore the use of the <application>ip</application> commands and configuration files will be documented together.
+ A graphical user interface (GUI) method, such as the use of <application>nm-connection-editor</application> or <application>control-network</application> to direct <systemitem class="service">NetworkManager</systemitem>, then <application>NetworkManager</application>'s command-line tool <application>nmcli</application>, and then finally methods using the command line and configuration files. The command line can be used to issue commands and to compose or edit configuration files, therefore the use of the <application>ip</application> commands and configuration files will be documented together.
</para>
@@ -48,7 +48,7 @@
</row>
<row>
<entry><application>nmcli</application></entry>
- <entry>A command line tool provided to allow users and scripts to interact with <application>NetworkManager</application></entry>
+ <entry>A command-line tool provided to allow users and scripts to interact with <application>NetworkManager</application></entry>
</row>
<row>
<entry><application>control-center</application></entry>
@@ -92,7 +92,7 @@ NetworkManager.service - Network Manager
<section
id="sec-Interacting_with_NetworkManager">
<title>Interacting with NetworkManager</title>
- <para>Users do not interact with the <application>NetworkManager</application> system service directly. Instead, users perform network configuration tasks via graphical and command line user interface tools. The following tools are available in Fedora:</para>
+ <para>Users do not interact with the <application>NetworkManager</application> system service directly. Instead, users perform network configuration tasks via graphical and command-line user interface tools. The following tools are available in Fedora:</para>
<para>
<orderedlist>
<listitem>
@@ -103,7 +103,7 @@ NetworkManager.service - Network Manager
<listitem>
<para>
- A command line tool, <application>nmcli</application>, is provided to allow users and scripts to interact with <application>NetworkManager</application>. Note that <application>nmcli</application> can be used on GUI-less systems like servers to control all aspects of <application>NetworkManager</application>. It is on an equal footing with the GUI tools.
+ A command-line tool, <application>nmcli</application>, is provided to allow users and scripts to interact with <application>NetworkManager</application>. Note that <application>nmcli</application> can be used on GUI-less systems like servers to control all aspects of <application>NetworkManager</application>. It is on an equal footing with the GUI tools.
</para>
</listitem>
<listitem>
@@ -151,7 +151,7 @@ ip utility, iproute2-ss130716</screen>
<para>
</para>
<para>
- The <application>NetworkManager</application> command line tool, <application>nmcli</application>, provides a command line way to configure networking by controlling <application>NetworkManager</application>. It is installed, along with <application>NetworkManager</application>, by default. If required, for details on how to verify that <application>NetworkManager</application> is running, see <xref linkend="sec-The_NetworkManager_Daemon" />.</para>
+ The <application>NetworkManager</application> command-line tool, <application>nmcli</application>, provides a command line way to configure networking by controlling <application>NetworkManager</application>. It is installed, along with <application>NetworkManager</application>, by default. If required, for details on how to verify that <application>NetworkManager</application> is running, see <xref linkend="sec-The_NetworkManager_Daemon" />.</para>
<para>
Examples of using the <application>nmcli</application> tool for each task will be included where possible, after explaining the use of graphical user interfaces and other command line methods. See <xref linkend="sec-Using_the_NetworkManager_Command_Line_Tool_nmcli" /> for an introduction to <application>nmcli</application>.
</para>
diff --git a/en-US/Preface.xml b/en-US/Preface.xml
index 1e935e4..073016c 100644
--- a/en-US/Preface.xml
+++ b/en-US/Preface.xml
@@ -49,7 +49,7 @@
<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.
+ 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.
@@ -75,30 +75,30 @@
This part describes how to configure the network on &MAJOROS;.
</para>
<para>
- <xref linkend="ch-Introduction_to_Fedora_Networking" /> explains the default networking service, <application>NetworkManager</application>, and the various graphical and command line tools that can be used to interact with <application>NetworkManager</application>. These include, an associated command line configuration tool, <application>nmcli</application>, and two graphical user interface tools, <application>control-center</application> and <application>nm-connection-editor</application>. Read this chapter to learn more about the many ways the <application>NetworkManager</application> daemon can be used.
+ <xref linkend="ch-Introduction_to_Fedora_Networking" /> explains the default networking service, <application>NetworkManager</application>, and the various graphical and command-line tools that can be used to interact with <application>NetworkManager</application>. These include, an associated command-line configuration tool, <application>nmcli</application>, and two graphical user interface tools, <application>control-center</application> and <application>nm-connection-editor</application>. Read this chapter to learn more about the many ways the <application>NetworkManager</application> daemon can be used.
</para>
<para>
- <xref linkend="ch-Configure_Networking" /> covers static and dynamic interface settings, selecting network configuration methods, using <application>NetworkManager</application> with graphical and command line user interfaces. Read this chapter to learn about configuring network connections.
+ <xref linkend="ch-Configure_Networking" /> covers static and dynamic interface settings, selecting network configuration methods, using <application>NetworkManager</application> with graphical and command-line user interfaces. Read this chapter to learn about configuring network connections.
</para>
<para>
<xref linkend="ch-Configure_Host_Names" /> covers static, pretty, and transient host names and their configuration using <application>hostnamectl</application>. Read this chapter to learn more about configuring host names on local and remote systems.
</para>
<para>
- <xref linkend="ch-Configure_Network_Bonding" /> covers the configuring and use of bonded network connections. Read this chapter to learn about the configuring of network bonds using graphical and command line user interfaces.
+ <xref linkend="ch-Configure_Network_Bonding" /> covers the configuring and use of bonded network connections. Read this chapter to learn about the configuring of network bonds using graphical and command-line user interfaces.
</para>
<para>
- <xref linkend="ch-Configure_Network_Teaming" /> covers the configuring and use of teamed network connections. Read this chapter to learn about the configuring of network teams using graphical and command line user interfaces.
+ <xref linkend="ch-Configure_Network_Teaming" /> covers the configuring and use of teamed network connections. Read this chapter to learn about the configuring of network teams using graphical and command-line user interfaces.
</para>
<para>
- <xref linkend="ch-Configure_Network_Bridging" /> covers the configuring and use of network bridges. Read this chapter to learn about the configuring of network bridges using graphical and command line user interfaces.
+ <xref linkend="ch-Configure_Network_Bridging" /> covers the configuring and use of network bridges. Read this chapter to learn about the configuring of network bridges using graphical and command-line user interfaces.
</para>
<para>
- <xref linkend="ch-Configure_802_1Q_VLAN_Tagging" /> covers the configuring and use of virtual private networks, VLANs, according to the 802.1Q standard. Read this chapter to learn about the configuring of VLANs using graphical and command line user interfaces.
+ <xref linkend="ch-Configure_802_1Q_VLAN_Tagging" /> covers the configuring and use of virtual private networks, VLANs, according to the 802.1Q standard. Read this chapter to learn about the configuring of VLANs using graphical and command-line user interfaces.
</para>
<!--<para>
- <xref linkend="ch-Configure_IPoIB" /> covers the configuring and use of IP over InfiniBand network connections. Read this chapter to learn about the configuring of IPoIB connections using graphical and command line user interfaces.
+ <xref linkend="ch-Configure_IPoIB" /> covers the configuring and use of IP over InfiniBand network connections. Read this chapter to learn about the configuring of IPoIB connections using graphical and command-line user interfaces.
</para>-->
<para>
<xref linkend="ch-Consistent_Network_Device_Naming" /> covers consistent network device naming for network interfaces, a feature that changes the name of network interfaces on a system in order to make locating and differentiating the interfaces easier. Read this chapter to learn about this feature and how to enable or disable it.
9 years, 5 months
[networking-guide] master: ip commands are not persistent (fc829bb)
by stephenw
Repository : http://git.fedorahosted.org/cgit/docs/networking-guide.git
On branch : master
>---------------------------------------------------------------
commit fc829bb724f334bd1369bf35409b9892729b8867
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Mon Sep 29 21:39:34 2014 +0200
ip commands are not persistent
making "Note" admonitions
>---------------------------------------------------------------
en-US/Configure_802_1Q_VLAN_Tagging.xml | 2 ++
en-US/Configure_Networking.xml | 6 +++++-
en-US/Introduction_to_Fedora_Networking.xml | 5 +++++
3 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/en-US/Configure_802_1Q_VLAN_Tagging.xml b/en-US/Configure_802_1Q_VLAN_Tagging.xml
index 3d0ae27..67eb915 100644
--- a/en-US/Configure_802_1Q_VLAN_Tagging.xml
+++ b/en-US/Configure_802_1Q_VLAN_Tagging.xml
@@ -223,9 +223,11 @@ To create an 802.1Q VLAN interface on Ethernet interface <replaceable>eth0</repl
To remove the VLAN, issue a command as <systemitem class="username">root</systemitem> as follows:
<screen>~]# <command>ip link delete <replaceable>eth0.8</replaceable></command></screen>
</para>
+<note>
<para>
VLAN interfaces created using <application>ip</application> commands on the command line will be lost if the system is shutdown or restarted. To configure VLAN interfaces to be persistent after a system restart, use <filename>ifcfg</filename> files. See <xref linkend="sec-Setting_Up_802.1Q_VLAN_Tagging_Using_ifcfg_Files" />
</para>
+</note>
</section>
<section id="sec-Configure_802_1Q_VLAN_Tagging_Using_the_Command_Line_Tool_nmcli">
diff --git a/en-US/Configure_Networking.xml b/en-US/Configure_Networking.xml
index b4f84e6..7ee62e2 100644
--- a/en-US/Configure_Networking.xml
+++ b/en-US/Configure_Networking.xml
@@ -1639,8 +1639,12 @@ The address assignment of a specific device can be viewed as follows:
inet 192.168.<emphasis role="bold">2</emphasis>.223/24 scope global eth1
inet 192.168.<emphasis role="bold">4</emphasis>.223/24 scope global eth1</screen>
</para>
- <para>The commands for the <application>ip</application> utility are documented in the <filename>ip(8)</filename> manual page. Note that <application>ip</application> commands given on the command line will not persist after a system restart.
+ <para>The commands for the <application>ip</application> utility are documented in the <filename>ip(8)</filename> manual page.</para>
+ <note>
+ <para>
+ Note that <application>ip</application> commands given on the command line will not persist after a system restart.
</para>
+ </note>
</section>
diff --git a/en-US/Introduction_to_Fedora_Networking.xml b/en-US/Introduction_to_Fedora_Networking.xml
index 7cbcf99..bbec4cb 100644
--- a/en-US/Introduction_to_Fedora_Networking.xml
+++ b/en-US/Introduction_to_Fedora_Networking.xml
@@ -137,6 +137,11 @@ ip utility, iproute2-ss130716</screen>
<para>
The <application>ip</application> commands can be used to add and remove addresses and routes to interfaces in parallel with <application>NetworkManager</application>, which will preserve them and recognize them in <application>nmcli</application>, <application>nmtui</application>, <application>control-center</application>, and the D-Bus API.
</para>
+ <note>
+ <para>
+ Note that <application>ip</application> commands given on the command line will not persist after a system restart.
+ </para>
+ </note>
<para>
Examples of using the command line and configuration files for each task are included after explaining the use of one of the graphical user interfaces to <application>NetworkManager</application>, namely, <application>control-center</application> and <application>nm-connection-editor</application>.
</para>
9 years, 5 months
[networking-guide] master: command line (not prompt) (a924a6d)
by stephenw
Repository : http://git.fedorahosted.org/cgit/docs/networking-guide.git
On branch : master
>---------------------------------------------------------------
commit a924a6dd5e9a96122adcde24cbf9e98ad41ca658
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Mon Sep 29 21:38:11 2014 +0200
command line (not prompt)
as per IBM Style Guide
>---------------------------------------------------------------
en-US/Configure_802_1Q_VLAN_Tagging.xml | 2 +-
en-US/Configure_Networking.xml | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/en-US/Configure_802_1Q_VLAN_Tagging.xml b/en-US/Configure_802_1Q_VLAN_Tagging.xml
index 2feb998..3d0ae27 100644
--- a/en-US/Configure_802_1Q_VLAN_Tagging.xml
+++ b/en-US/Configure_802_1Q_VLAN_Tagging.xml
@@ -224,7 +224,7 @@ To create an 802.1Q VLAN interface on Ethernet interface <replaceable>eth0</repl
<screen>~]# <command>ip link delete <replaceable>eth0.8</replaceable></command></screen>
</para>
<para>
- VLAN interfaces created using <application>ip</application> commands at the command prompt will be lost if the system is shutdown or restarted. To configure VLAN interfaces to be persistent after a system restart, use <filename>ifcfg</filename> files. See <xref linkend="sec-Setting_Up_802.1Q_VLAN_Tagging_Using_ifcfg_Files" />
+ VLAN interfaces created using <application>ip</application> commands on the command line will be lost if the system is shutdown or restarted. To configure VLAN interfaces to be persistent after a system restart, use <filename>ifcfg</filename> files. See <xref linkend="sec-Setting_Up_802.1Q_VLAN_Tagging_Using_ifcfg_Files" />
</para>
</section>
diff --git a/en-US/Configure_Networking.xml b/en-US/Configure_Networking.xml
index 7de0702..b4f84e6 100644
--- a/en-US/Configure_Networking.xml
+++ b/en-US/Configure_Networking.xml
@@ -1687,7 +1687,7 @@ The address assignment of a specific device can be viewed as follows:
<section id="sec-Configuring_Static_Routes_in_ifcfg_files">
<title>Configuring Static Routes in ifcfg files</title>
<para>
-Static routes set using <application>ip</application> commands at the command prompt will be lost if the system is shutdown or restarted. To configure static routes to be persistent after a system restart, they must be placed in per-interface configuration files in the <filename class="directory">/etc/sysconfig/network-scripts/</filename> directory. The file name should be of the format <filename>route-<replaceable>ethX</replaceable></filename>. There are two types of commands to use in the configuration files; <application>ip</application> commands as explained in <xref linkend="bh-networkscripts-static-routes-ip-command" /> and the <firstterm>Network/Netmask</firstterm> format as explained in <xref linkend="bh-networkscripts-static-routes-network-netmask-directives" />.
+Static routes set using <application>ip</application> commands on the command line will be lost if the system is shutdown or restarted. To configure static routes to be persistent after a system restart, they must be placed in per-interface configuration files in the <filename class="directory">/etc/sysconfig/network-scripts/</filename> directory. The file name should be of the format <filename>route-<replaceable>ethX</replaceable></filename>. There are two types of commands to use in the configuration files; <application>ip</application> commands as explained in <xref linkend="bh-networkscripts-static-routes-ip-command" /> and the <firstterm>Network/Netmask</firstterm> format as explained in <xref linkend="bh-networkscripts-static-routes-network-netmask-directives" />.
</para>
<bridgehead id="bh-networkscripts-static-routes-ip-command">
9 years, 5 months
[install-guide/F21-rewrite] Added most of introduction to Installing using Anaconda
by pbokoc
commit 0609fb11946b3c72dfc1ff07ddcb714641548a12
Author: Petr Bokoc <pbokoc(a)redhat.com>
Date: Mon Sep 29 18:28:27 2014 +0200
Added most of introduction to Installing using Anaconda
en-US/Installing_Using_Anaconda.xml | 133 ++++++++++++++++++++++++++++++----
1 files changed, 117 insertions(+), 16 deletions(-)
---
diff --git a/en-US/Installing_Using_Anaconda.xml b/en-US/Installing_Using_Anaconda.xml
index 708ddeb..9e16ab7 100644
--- a/en-US/Installing_Using_Anaconda.xml
+++ b/en-US/Installing_Using_Anaconda.xml
@@ -6,40 +6,141 @@
<chapter id="chap-installing-using-anaconda">
<title>Installing Using Anaconda</title>
<para>
- intro text
+ This chapter provides step-by-step instructions for installing &PRODUCT; using the <application>Anaconda</application> installer. The bulk of this chapter describes installation using the graphical user interface. A text mode is also available for systems with no graphical display, but this mode is limited in certain aspects (for example, custom partitioning is not possible in text mode).
</para>
+ <para>
+ If your system does not have the ability to use the graphical mode, you can:
+ </para>
+ <itemizedlist>
+ <listitem>
+ <para>
+ Use Kickstart to automate the installation as described in <xref linkend="chap-kickstart-installations" />
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ Perform the graphical installation remotely by connecting to the installation system from another computer with a graphical display using the <firstterm>VNC</firstterm> (Virtual Network Computing) protocol - see <xref linkend="chap-vnc-installations" />
+ </para>
+ </listitem>
+ </itemizedlist>
+
+ <section id="sect-installation-new-users">
+ <title>Introduction to Anaconda</title>
+ <para>
+ The &PRODUCT; installer, <application>Anaconda</application>, is different from most other operating system installation programs due to its parallel nature. Most installers follow a fixed path: you must choose your language first, then you configure network, then installation type, then partitioning, etc. There is usually only one way to proceed at any given time.
+ </para>
+ <para>
+ In <application>Anaconda</application> you are only required to select your language and locale first, and then you are presented with a central screen, where you can configure most aspects of the installation in any order you like. This does not apply to all parts of the installation process, however - for example, when installing from a network location, you must configure the network before you can select which packages to install.
+ </para>
+ <para>
+ Some screens will be automatically configured depending on your hardware and the type of media you used to start the installation. You can still change the detected settings in any screen. Screens which have not been automatically configured, and therefore require your attention before you begin the installation, are marked by an exclamation mark. You can not start the actual installation process before you finish configuring these settings.
+ </para>
+ <para>
+ Additional differences appear in certain screens; notably the custom partitioning process is very different from other Linux distributions. These differences are described in each screen's subsection.
+ </para>
+ </section>
<section id="sect-consoles-logs-during-installation">
<title>Consoles and Logging During the Installation</title>
<para>
- text
+ The following sections describe how to access logs and an interactive shell during the installation. This is useful when troubleshooting problems, but should not be necessary in most cases.
</para>
<section id="sect-installation-consoles">
<title>Accessing Consoles</title>
<para>
- text
+ The &PRODUCT; installer uses the <application>tmux</application> terminal multiplexer to display and control several windows you can use in addition to the main interface. Each of these windows serves a different purpose - they display several different logs, which can be used to troubleshoot any issues during the installation, and one of the windows provides an interactive shell prompt with <systemitem class="username">root</systemitem> privileges, unless this prompt was specifically disabled using a boot option or a Kickstart command.
</para>
- </section>
-
- <section id="sect-installation-screenshots">
- <title>Saving Screenshots</title>
+ <note>
+ <para>
+ In general, there is no reason to leave the default graphical installation environment unless you need to diagnose an installation problem.
+ </para>
+ </note>
<para>
- text
+ The terminal multiplexer is running in virtual console 1. To switch from the actual installation environment to <application>tmux</application>, press <keycombo><keycap>Ctrl</keycap><keycap>Alt</keycap><keycap>F1</keycap></keycombo>. To go back to the main installation interface which runs in virtual console 6, press <keycombo><keycap>Ctrl</keycap><keycap>Alt</keycap><keycap>F6</keycap></keycombo>.
</para>
- </section>
-
- <section id="sect-installation-logs">
- <title>Log Files</title>
+ <note>
+ <para>
+ If you choose text mode installation, you will start in virtual console 1 (<application>tmux</application>), and switching to console 6 will open a shell prompt instead of a graphical interface.
+ </para>
+ </note>
<para>
- text
+ The console running <application>tmux</application> has 5 available windows; their contents are described in the table below, along with keyboard shortcuts used to access them. Note that the keyboard shortcuts are two-part: first press <keycombo><keycap>Ctrl</keycap><keycap>b</keycap></keycombo>, then release both keys, and press the number key for the window you want to use.
+ </para>
+ <para>
+ You can also use <keycombo><keycap>Ctrl</keycap><keycap>b</keycap></keycombo> <keycap>n</keycap> and <keycombo><keycap>Ctrl</keycap><keycap>b</keycap></keycombo> <keycap>p</keycap> to switch to the next or previous <application>tmux</application> window, respectively.
+ </para>
+ <table id="table-tmux-windows">
+ <title>Available tmux Windows</title>
+ <tgroup cols="2">
+ <colspec colwidth="15%" colname="keystroke" colnum="1" />
+ <colspec colwidth="85%" colname="contents" colnum="2" />
+ <thead>
+ <row>
+ <entry>
+ Shortcut
+ </entry>
+ <entry>
+ Contents
+ </entry>
+ </row>
+ </thead>
+ <tbody>
+ <row>
+ <entry>
+ <keycombo><keycap>Ctrl</keycap><keycap>b</keycap></keycombo> <keycap>1</keycap>
+ </entry>
+ <entry>
+ Main installation program window. Contains text-based prompts (during text mode installation or if you use VNC direct mode), and also some debugging information.
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <keycombo><keycap>Ctrl</keycap><keycap>b</keycap></keycombo> <keycap>2</keycap>
+ </entry>
+ <entry>
+ Interactive shell prompt with <systemitem class="username">root</systemitem> privileges.
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <keycombo><keycap>Ctrl</keycap><keycap>b</keycap></keycombo> <keycap>3</keycap>
+ </entry>
+ <entry>
+ Installation log; displays messages stored in <filename>/tmp/anaconda.log</filename>.
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <keycombo><keycap>Ctrl</keycap><keycap>b</keycap></keycombo> <keycap>4</keycap>
+ </entry>
+ <entry>
+ Storage log; displays messages related storage devices from kernel and system services, stored in <filename>/tmp/storage.log</filename>.
+ </entry>
+ </row>
+ <row>
+ <entry>
+ <keycombo><keycap>Ctrl</keycap><keycap>b</keycap></keycombo> <keycap>5</keycap>
+ </entry>
+ <entry>
+ Program log; displays messages from other system utilities, stored in <filename>/tmp/program.log</filename>.
+ </entry>
+ </row>
+ </tbody>
+ </tgroup>
+ </table>
+ <para>
+ In addition to displaying diagnostic information in <application>tmux</application> windows, <application>Anaconda</application> also generates several log files, which can be transferred from the installation system. These log files are described in <xref linkend="sect-troubleshooting-log-files" />, and directions for transferring them from the installation system are available in <xref linkend="sect-troubleshooting-transferring-logs" />.
</para>
</section>
- <section id="sect-installation-remote-logging">
- <title>Remote Logging</title>
+ <section id="sect-installation-screenshots">
+ <title>Saving Screenshots</title>
+ <para>
+ You can press <keycombo><keycap>Shift</keycap><keycap>Print Screen</keycap></keycombo> at any time during the graphical installation to capture the current screen. These screenshots are saved to <filename class="directory">/tmp/anaconda-screenshots</filename>.
+ </para>
<para>
- text
+ Additionanlly, you can use the <command>autostep --autoscreenshot</command> command in a Kickstart file to capture and save each step of the installation automatically. See <xref linkend="sect-kickstart-commands-autostep" /> for details.
</para>
</section>
9 years, 5 months
[system-administrators-guide] crony: Docs QA Feedback
by stephenw
commit ead5204b91ff4376bd97dc56deed8f06399ab16e
Author: Stephen Wadeley <swadeley(a)redhat.com>
Date: Fri Sep 26 12:50:22 2014 +0200
crony: Docs QA Feedback
en-US/Configuring_NTP_Using_the_chrony_Suite.xml | 63 +++++++++-------------
1 files changed, 25 insertions(+), 38 deletions(-)
---
diff --git a/en-US/Configuring_NTP_Using_the_chrony_Suite.xml b/en-US/Configuring_NTP_Using_the_chrony_Suite.xml
index b1fe1e1..efaff6d 100644
--- a/en-US/Configuring_NTP_Using_the_chrony_Suite.xml
+++ b/en-US/Configuring_NTP_Using_the_chrony_Suite.xml
@@ -29,7 +29,7 @@ There is a choice between the daemons <systemitem class="daemon">ntpd</systemite
<itemizedlist>
<listitem>
<para>
- <systemitem class="daemon">chronyd</systemitem> can work well when external time references are only intermittently accessible whereas <systemitem class="daemon">ntpd</systemitem> needs regular polling of time reference to work well.
+ <systemitem class="daemon">chronyd</systemitem> can work well when external time references are only intermittently accessible, whereas <systemitem class="daemon">ntpd</systemitem> needs regular polling of time reference to work well.
</para>
</listitem>
<listitem>
@@ -49,7 +49,7 @@ There is a choice between the daemons <systemitem class="daemon">ntpd</systemite
</listitem>
<listitem>
<para>
- <systemitem class="daemon">chronyd</systemitem> in the default configuration never steps the time after the clock has been synchronized at system start, in order not to upset other running programs. <systemitem class="daemon">ntpd</systemitem> can be configured to never step the time too, but it has to use a different means of adjusting the clock, which has some disadvantages.
+ In the default configuration, <systemitem class="daemon">chronyd</systemitem> never steps the time after the clock has been synchronized at system start, in order not to upset other running programs. <systemitem class="daemon">ntpd</systemitem> can be configured to never step the time too, but it has to use a different means of adjusting the clock, which has some disadvantages.
</para>
</listitem>
<listitem>
@@ -66,7 +66,7 @@ Things <systemitem class="daemon">chronyd</systemitem> can do that <systemitem c
<listitem>
<para>
- <systemitem class="daemon">chronyd</systemitem> provides support for isolated networks where the only method of time correction is manual entry. For example, by the administrator looking at a clock. <systemitem class="daemon">chronyd</systemitem> can look at the errors corrected at different updates to estimate the rate at which the computer gains or loses time, and use this estimate to trim the computer clock subsequently.
+ <systemitem class="daemon">chronyd</systemitem> provides support for isolated networks where the only method of time correction is manual entry. For example, by the administrator looking at a clock. <systemitem class="daemon">chronyd</systemitem> can examine the errors corrected at different updates to estimate the rate at which the computer gains or loses time, and use this estimate to trim the computer clock subsequently.
</para>
</listitem>
<listitem>
@@ -121,13 +121,13 @@ Things <systemitem class="daemon">ntpd</systemitem> can do that <systemitem clas
<section id="sect-Understanding_chronyc">
<title>Understanding chronyc</title>
<para>
- The <application>chrony</application> daemon, <systemitem class="daemon">chronyd</systemitem>, can be controlled by the command line utility <application>chronyc</application>. This utility provides a command prompt which allows entering of a number of commands to make changes to <systemitem class="daemon">chronyd</systemitem>. The default configuration is for <systemitem class="daemon">chronyd</systemitem> to only accept commands from a local instance of <application>chronyc</application>, but <application>chronyc</application> can be used to alter the configuration so that <systemitem class="daemon">chronyd</systemitem> will allow external control. That is to say, <application>chronyc</application> can be run remotely after first configuring <systemitem class="daemon">chronyd</systemitem> to accept remote connections. The <systemitem class="protocol">IP</systemitem> addresses allowed to connect to <systemitem class="daemon">chronyd</systemitem> should be tightly control
led.</para>
+ The <application>chrony</application> daemon, <systemitem class="daemon">chronyd</systemitem>, can be controlled by the command line utility <application>chronyc</application>. This utility provides a command prompt which allows entering of a number of commands to make changes to <systemitem class="daemon">chronyd</systemitem>. The default configuration is for <systemitem class="daemon">chronyd</systemitem> to only accept commands from a local instance of <application>chronyc</application>, but <application>chronyc</application> can be used to alter the configuration so that <systemitem class="daemon">chronyd</systemitem> will allow external control. <application>chronyc</application> can be run remotely after first configuring <systemitem class="daemon">chronyd</systemitem> to accept remote connections. The <systemitem class="protocol">IP</systemitem> addresses allowed to connect to <systemitem class="daemon">chronyd</systemitem> should be tightly controlled.</para>
</section>
<section id="sect-Understanding_the_chrony_configuration_commands">
<title>Understanding the chrony Configuration Commands</title>
<para>
- The default configuration file for <systemitem class="daemon">chronyd</systemitem> is <filename>/etc/chrony.conf</filename>. The <option>-f</option> option can be used to specify an alternate configuration file path. See the <systemitem class="daemon">chronyd</systemitem> man page for further options. For a complete list of the directives that can be used see <ulink url="http://chrony.tuxfamily.org/manual.html#Configuration-file"><citetitle pubwork="webpage">http://chrony.tuxfamily.org/manual.html#Configuration-file</citetitle></ulink>. We present here a selection of configuration options:
+ The default configuration file for <systemitem class="daemon">chronyd</systemitem> is <filename>/etc/chrony.conf</filename>. The <option>-f</option> option can be used to specify an alternate configuration file path. See the <systemitem class="daemon">chronyd</systemitem> man page for further options. For a complete list of the directives that can be used see <ulink url="http://chrony.tuxfamily.org/manual.html#Configuration-file"><citetitle pubwork="webpage">http://chrony.tuxfamily.org/manual.html#Configuration-file</citetitle></ulink>. Below is a selection of configuration options:
<variablelist>
<varlistentry>
<term>Comments</term>
@@ -175,7 +175,7 @@ Optionally specify a host, subnet, or network from which to allow <systemitem cl
<term>cmdallow</term>
<listitem>
<para>
- This is similar to the <command>allow</command> directive (see section <command>allow</command>), except that it allows control access (rather than <systemitem class="protocol">NTP</systemitem> client access) to a particular subnet or host. (By <quote>control access</quote> is meant that <application>chronyc</application> can be run on those hosts and successfully connect to <systemitem class="daemon">chronyd</systemitem> on this computer.) The syntax is identical. There is also a <command>cmddeny</command> all directive with similar behavior to the <command>cmdallow</command> all directive.</para>
+ This is similar to the <command>allow</command> directive (see section <command>allow</command>), except that it allows control access (rather than <systemitem class="protocol">NTP</systemitem> client access) to a particular subnet or host. (By <quote>control access</quote> is meant that <application>chronyc</application> can be run on those hosts and successfully connect to <systemitem class="daemon">chronyd</systemitem> on this computer.) The syntax is identical. There is also a <command>cmddeny all</command> directive with similar behavior to the <command>cmdallow all</command> directive.</para>
</listitem>
</varlistentry>
@@ -203,7 +203,7 @@ Optionally specify a host, subnet, or network from which to allow <systemitem cl
<para>
An example of the command is:
<screen>local stratum 10</screen>
-A large value of 10 indicates that the clock is so many hops away from a reference clock that its time is fairly unreliable. Put another way, if the computer ever has access to another computer which is ultimately synchronized to a reference clock, it will almost certainly be at a stratum less than 10. Therefore, the choice of a high value like 10 for the <command>local</command> command prevents the machine’s own time from ever being confused with real time, were it ever to leak out to clients that have visibility of real servers.</para>
+A large value of 10 indicates that the clock is so many hops away from a reference clock that its time is unreliable. If the computer ever has access to another computer which is ultimately synchronized to a reference clock, it will almost certainly be at a stratum less than 10. Therefore, the choice of a high value like 10 for the <command>local</command> command prevents the machine’s own time from ever being confused with real time, were it ever to leak out to clients that have visibility of real servers.</para>
</listitem>
</varlistentry>
<varlistentry>
@@ -261,7 +261,7 @@ A large value of 10 indicates that the clock is so many hops away from a referen
</listitem>
</varlistentry>
</variablelist>
-
+
@@ -318,9 +318,9 @@ After the first clock update, <systemitem class="daemon">chronyd</systemitem> wi
<para>
One of <systemitem class="daemon">chronyd</systemitem>'s tasks is to work out how fast or slow the computer’s clock runs relative to its reference sources. In addition, it computes an estimate of the error bounds around the estimated value.
-If the range of error is too large, it probably indicates that the measurements have not settled down yet, and that the estimated gain or loss rate is not very reliable.
+If the range of error is too large, it indicates that the measurements have not settled down yet, and that the estimated gain or loss rate is not very reliable.
-The <command>maxupdateskew</command> parameter allows the threshold for determining whether an estimate may be so unreliable that it should not be used. By default, the threshold is 1000 ppm.
+The <command>maxupdateskew</command> parameter is the threshold for determining whether an estimate is too unreliable to be used. By default, the threshold is 1000 ppm.
The format of the syntax is:
@@ -360,7 +360,7 @@ The format of the syntax is:
<para>
The format of the syntax is:
<screen>stratumweight <replaceable>dist-in-seconds</replaceable></screen>
-By default, <replaceable>dist-in-seconds</replaceable> is 1 second. This usually means that sources with lower stratum will be preferred to sources with higher stratum even when their distance is significantly worse. Setting <command>stratumweight</command> to 0 makes <systemitem class="daemon">chronyd</systemitem> ignore stratum when selecting the source.
+By default, <replaceable>dist-in-seconds</replaceable> is 1 second. This means that sources with lower stratum are usually preferred to sources with higher stratum even when their distance is significantly worse. Setting <command>stratumweight</command> to 0 makes <systemitem class="daemon">chronyd</systemitem> ignore stratum when selecting the source.
</para>
</listitem>
</varlistentry>
@@ -375,7 +375,7 @@ The format of the syntax is:
<screen>rtcfile /var/lib/chrony/rtc</screen>
-<systemitem class="daemon">chronyd</systemitem> saves information in this file when it exits and when the <command>writertc</command> command is issued in <application>chronyc</application>. The information saved is the RTC’s error at some epoch, that epoch (in seconds since January 1 1970), and the rate at which the RTC gains or loses time. Not all real-time clocks are supported as their code is system-specific. Note that if this directive is used then real-time clock should not be manually adjusted as this would interfere with <application>chrony</application>'s need to measure the rate at which the real-time clock drifts if it was adjusted at random intervals.
+<systemitem class="daemon">chronyd</systemitem> saves information in this file when it exits and when the <command>writertc</command> command is issued in <application>chronyc</application>. The information saved is the RTC’s error at some epoch, that epoch (in seconds since January 1 1970), and the rate at which the RTC gains or loses time. Not all real-time clocks are supported as their code is system-specific. Note that if this directive is used then the real-time clock should not be manually adjusted as this would interfere with <application>chrony</application>'s need to measure the rate at which the real-time clock drifts if it was adjusted at random intervals.
</para>
</listitem>
</varlistentry>
@@ -689,7 +689,7 @@ This indicates the mode of the source. <literal>^</literal> means a server, <lit
<term>S</term>
<listitem>
<para>
-This column indicates the state of the sources. <quote>*</quote> indicates the source to which <systemitem class="daemon">chronyd</systemitem> is currently synchronized. <quote>+</quote> indicates acceptable sources which are combined with the selected source. <quote>-</quote> indicates acceptable sources which are excluded by the combining algorithm. <quote>?</quote> indicates sources to which connectivity has been lost or whose packets do not pass all tests. <quote>x</quote> indicates a clock which <systemitem class="daemon">chronyd</systemitem> thinks is is a falseticker (that is to say, its time is inconsistent with a majority of other sources). <quote>~</quote> indicates a source whose time appears to have too much
+This column indicates the state of the sources. <quote>*</quote> indicates the source to which <systemitem class="daemon">chronyd</systemitem> is currently synchronized. <quote>+</quote> indicates acceptable sources which are combined with the selected source. <quote>-</quote> indicates acceptable sources which are excluded by the combining algorithm. <quote>?</quote> indicates sources to which connectivity has been lost or whose packets do not pass all tests. <quote>x</quote> indicates a clock which <systemitem class="daemon">chronyd</systemitem> thinks is a <firstterm>falseticker</firstterm> ( its time is inconsistent with a majority of other sources). <quote>~</quote> indicates a source whose time appears to have too much
variability. The <quote>?</quote> condition is also shown at start-up, until at least 3 samples have been gathered from it.</para>
</listitem>
</varlistentry>
@@ -723,7 +723,7 @@ This shows the stratum of the source, as reported in its most recently received
<term>Reach</term>
<listitem>
<para>
- This shows the source’s reachability register printed as octal number. The register has 8 bits and is updated on every received or missed packet from the source. A value of 377 indicates that a valid reply was received for all from the last eight transmissions.
+ This shows the source’s reach register printed as an octal number. The register has 8 bits and is updated on every received or missed packet from the source. A value of 377 indicates that a valid reply was received for all of the last eight transmissions.
</para>
</listitem>
</varlistentry>
@@ -755,7 +755,7 @@ This shows the stratum of the source, as reported in its most recently received
The optional argument <option>-v</option> can be specified, meaning verbose. In this case, extra caption lines are shown as a reminder of the meanings of the columns.
<screen>~]$ <command>chronyc sourcestats</command>
-
+
210 Number of sources = 1
Name/IP Address NP NR Span Frequency Freq Skew Offset Std Dev
@@ -858,7 +858,7 @@ Where <replaceable>commandkey-password</replaceable> is the command key or passw
<section id="sect-Setting_up_chrony_for_different_environments">
<title>Setting Up chrony for Different Environments</title>
-
+
<section id="sect-Setting_up_chrony_for_a_system_which_is_infrequently_connected">
<title>Setting Up chrony for a System Which is Infrequently Connected</title>
@@ -872,20 +872,12 @@ The command key ID is generated at install time and should correspond with the <
</para>
<para>
- <orderedlist>
- <listitem>
- <para>
Using your editor running as <systemitem class="username">root</systemitem>, add the addresses of four <systemitem class="protocol">NTP</systemitem> servers as follows:
- <screen>
-server 0.pool.ntp.org offline
+ <screen>server 0.pool.ntp.org offline
server 1.pool.ntp.org offline
server 2.pool.ntp.org offline
-server 3.pool.ntp.org offline
-</screen>
+server 3.pool.ntp.org offline</screen>
The <option>offline</option> option can be useful in preventing systems from trying to activate connections. The <application>chrony</application> daemon will wait for <application>chronyc</application> to inform it that the system is connected to the network or Internet.
- </para>
- </listitem>
- </orderedlist>
</para>
</section>
@@ -974,15 +966,15 @@ From the remote systems, the system administrator can issue commands after first
</para>
<para>
- The password or hash associated with the command key for a remote system is best obtained by <systemitem class="protocol">SSH</systemitem>. That is to say, an <systemitem class="protocol">SSH</systemitem> connection should be established to the remote machine and the ID of the command key from <filename>/etc/chrony.conf</filename> and the command key in <filename>/etc/chrony.keys</filename> memorized or stored securely for the duration of the session.
+ The password or hash associated with the command key for a remote system is best obtained by <systemitem class="protocol">SSH</systemitem>. An <systemitem class="protocol">SSH</systemitem> connection should be established to the remote machine and the ID of the command key from <filename>/etc/chrony.conf</filename> and the command key in <filename>/etc/chrony.keys</filename> memorized or stored securely for the duration of the session.
</para>
- </section>
+ </section>
</section>
-
+
<!--Topics, Reference-->
<section id="sect-additional_resources">
-
+
<title>Additional Resources</title>
<para>
The following sources of information provide additional resources regarding <application>chrony</application>.
@@ -1024,14 +1016,14 @@ From the remote systems, the system administrator can issue commands after first
</itemizedlist>
</section>
-<section id="s2-chrony_Useful_Websites">
- <title>Useful Websites</title>
+<section id="s2-chrony_Online_Documentation">
+ <title>Online Documentation</title>
<variablelist>
<varlistentry>
<term><ulink url="http://chrony.tuxfamily.org/manual.html"/></term>
<listitem>
<para>
- The on-line user guide for <application>chrony</application>.
+ The online user guide for <application>chrony</application>.
</para>
</listitem>
</varlistentry>
@@ -1041,8 +1033,3 @@ From the remote systems, the system administrator can issue commands after first
</section>
</chapter>
-
-
-
-
-
9 years, 5 months
[install-guide/F21-rewrite] bootloader --boot-drive needs only one member of mpath device (Kickstart)
by pbokoc
commit 3330473ab515a23975ac35ead4d28b6a8ec23b70
Author: Petr Bokoc <pbokoc(a)redhat.com>
Date: Fri Sep 26 17:54:21 2014 +0200
bootloader --boot-drive needs only one member of mpath device (Kickstart)
en-US/Kickstart_Syntax_Reference.xml | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
---
diff --git a/en-US/Kickstart_Syntax_Reference.xml b/en-US/Kickstart_Syntax_Reference.xml
index 86dba74..2cd58bc 100644
--- a/en-US/Kickstart_Syntax_Reference.xml
+++ b/en-US/Kickstart_Syntax_Reference.xml
@@ -564,7 +564,7 @@
<term><option>--boot-drive=</option></term>
<listitem>
<para>
- Specifies which drive the boot loader should be written to, and therefore which drive the computer will boot from.
+ Specifies which drive the boot loader should be written to, and therefore which drive the computer will boot from. If you use a multipath device as the boot drive, specify only one member of the device.
</para>
<important>
<para>
9 years, 5 months
[install-guide/F21-rewrite] Fixing a malformed command in Kickstart Syntax Reference
by pbokoc
commit 9c0c19f7b4b16bcafc207cb76c92a5adb3b8ab59
Author: Petr Bokoc <pbokoc(a)redhat.com>
Date: Tue Sep 23 16:27:23 2014 +0200
Fixing a malformed command in Kickstart Syntax Reference
en-US/Kickstart_Syntax_Reference.xml | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
---
diff --git a/en-US/Kickstart_Syntax_Reference.xml b/en-US/Kickstart_Syntax_Reference.xml
index 68580b4..86dba74 100644
--- a/en-US/Kickstart_Syntax_Reference.xml
+++ b/en-US/Kickstart_Syntax_Reference.xml
@@ -1112,7 +1112,7 @@
To determine the size of the swap partition automatically but also allow extra space for your system to hibernate, use the <option>--hibernation</option> option:
</para>
<programlisting>
-<literal>swap--hibernation</literal>
+<literal>swap --hibernation</literal>
</programlisting>
<para>
The size assigned will be equivalent to the swap space assigned by <option>--recommended</option> plus the amount of RAM on your system.
9 years, 5 months