Present readers with smart quotes
Before this change, this documentation in this repo would present the reader with U+0022 QUOTATION MARKs. According to Unicode, it’s better to use U+201C LEFT DOUBLE QUOTATION MARK and U+201D RIGHT DOUBLE QUOTATION MARK (Source: https://www.unicode.org/charts/PDF/U0000.pdf#page=3).
This commit is contained in:
parent
80d5169b81
commit
827d19e54b
22 changed files with 61 additions and 61 deletions
4
LICENSE
4
LICENSE
|
|
@ -1,6 +1,6 @@
|
|||
The text of and illustrations in this document are licensed by Red Hat
|
||||
under a Creative Commons Attribution-ShareAlike 3.0 Unported license
|
||||
("CC-BY-SA"). An explanation of CC-BY-SA is available at
|
||||
under a Creative Commons Attribution–Share Alike 3.0 Unported license
|
||||
(“CC-BY-SA”). An explanation of CC-BY-SA is available at
|
||||
http://creativecommons.org/licenses/by-sa/3.0/. In accordance with
|
||||
CC-BY-SA, if you distribute this document or an adaptation of it, you
|
||||
must provide the URL for the original version.
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
# Fedora System Administrator’s Guide
|
||||
|
||||
Please report Issues and submit Pull Requests for **Content Fixes** here.
|
||||
Never done a pull request (or "PR")? Here's the [Pagure documentation for
|
||||
Never done a pull request (or “PR”)? Here's the [Pagure documentation for
|
||||
Pull Requests](https://docs.pagure.org/pagure/usage/pull_requests.html).
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -38,7 +38,7 @@ Note that revision numbers relate to the edition of this manual, not to version
|
|||
|
||||
`1-4.1`:: Tue Oct 27 2015, Stephen Wadeley (swadeley@redhat.com)
|
||||
|
||||
* Added "Gaining Privileges" chapter, "Using OpenSSH Certificate Authentication" section, and made improvements to the GRUB 2 chapter.
|
||||
* Added "`Gaining Privileges`" chapter, "`Using OpenSSH Certificate Authentication`" section, and made improvements to the GRUB 2 chapter.
|
||||
|
||||
`1-4`:: Mon May 25 2015, Stephen Wadeley (swadeley@redhat.com)
|
||||
|
||||
|
|
@ -50,7 +50,7 @@ Note that revision numbers relate to the edition of this manual, not to version
|
|||
|
||||
`1-2.1`:: Wed Mar 4 2015, Stephen Wadeley (swadeley@redhat.com)
|
||||
|
||||
* Added "Working with the GRUB 2 Boot Loader" chapter.
|
||||
* Added "`Working with the GRUB 2 Boot Loader`" chapter.
|
||||
|
||||
`1-2`:: Tue Dec 9 2014, Stephen Wadeley (swadeley@redhat.com)
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
|
||||
Copyright {YEAR} {HOLDER}.
|
||||
|
||||
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution-ShareAlike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at link:++https://creativecommons.org/licenses/by-sa/3.0/++[]. The original authors of this document, and Red Hat, designate the Fedora Project as the "Attribution Party" for purposes of CC-BY-SA. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
|
||||
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license (“CC-BY-SA”). An explanation of CC-BY-SA is available at link:++https://creativecommons.org/licenses/by-sa/3.0/++[]. The original authors of this document, and Red Hat, designate the Fedora Project as the “`Attribution Party`” for purposes of CC-BY-SA. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version.
|
||||
|
||||
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
|
||||
|
||||
|
|
|
|||
|
|
@ -327,7 +327,7 @@ The default value is [command]#ftp#.
|
|||
+
|
||||
There is no default value for this directive.
|
||||
|
||||
* [command]#local_umask# — Specifies the umask value for file creation. Note that the default value is in octal form (a numerical system with a base of eight), which includes a "0" prefix. Otherwise the value is treated as a base-10 integer.
|
||||
* [command]#local_umask# — Specifies the umask value for file creation. Note that the default value is in octal form (a numerical system with a base of eight), which includes a "`0`" prefix. Otherwise the value is treated as a base-10 integer.
|
||||
+
|
||||
The default value is [command]#022#.
|
||||
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@
|
|||
[[s1-OpenLDAP]]
|
||||
== OpenLDAP
|
||||
indexterm:[directory server,OpenLDAP]indexterm:[LDAP,OpenLDAP]indexterm:[X.500,OpenLDAP]indexterm:[X.500 Lite,OpenLDAP]
|
||||
`LDAP` (Lightweight Directory Access Protocol) is a set of open protocols used to access centrally stored information over a network. It is based on the `X.500` standard for directory sharing, but is less complex and resource-intensive. For this reason, LDAP is sometimes referred to as "X.500 Lite".
|
||||
`LDAP` (Lightweight Directory Access Protocol) is a set of open protocols used to access centrally stored information over a network. It is based on the `X.500` standard for directory sharing, but is less complex and resource-intensive. For this reason, LDAP is sometimes referred to as "`X.500 Lite`".
|
||||
|
||||
Like X.500, LDAP organizes information in a hierarchical manner using directories. These directories can store a variety of information such as names, addresses, or phone numbers, and can even be used in a manner similar to the _Network Information Service_ (*NIS*), enabling anyone to access their account from any machine on the LDAP enabled network.
|
||||
|
||||
|
|
|
|||
|
|
@ -349,7 +349,7 @@ Alternatively, to start the graphical firewall configuration tool using the comm
|
|||
|
||||
The `Firewall Configuration` window opens.
|
||||
|
||||
Look for the word "Connected" in the lower left corner. This indicates that the [application]*firewall-config* tool is connected to the user space daemon, `firewalld`.
|
||||
Look for the word "`Connected`" in the lower left corner. This indicates that the [application]*firewall-config* tool is connected to the user space daemon, `firewalld`.
|
||||
|
||||
To immediately change the current firewall settings, ensure the drop-down selection menu labeled `Configuration` is set to `Runtime`. Alternatively, to edit the settings to be applied at the next system start, or firewall reload, select `Permanent` from the drop-down list.
|
||||
|
||||
|
|
|
|||
|
|
@ -1409,7 +1409,7 @@ The _option_ has to be a valid keyword as described in xref:Web_Servers.adoc#tab
|
|||
|[option]`Includes`|Enables server-side includes.
|
||||
|[option]`IncludesNOEXEC`|Enables server-side includes, but does not allow the execution of commands.
|
||||
|[option]`Indexes`|Enables server-generated directory listings.
|
||||
|[option]`MultiViews`|Enables content-negotiated "MultiViews".
|
||||
|[option]`MultiViews`|Enables content-negotiated "`MultiViews`".
|
||||
|[option]`SymLinksIfOwnerMatch`|Enables following symbolic links in the directory when both the link and the target file have the same owner.
|
||||
|[option]`All`|Enables all of the features above with the exception of [option]`MultiViews`.
|
||||
|[option]`None`|Disables all of the features above.
|
||||
|
|
@ -2232,7 +2232,7 @@ Due to the SSL3.0 protocol vulnerability CVE-2014-3566, described in link:++http
|
|||
[[s3-apache-Enabling_and_Disabling_SSL_and_TLS_in_mod_ssl]]
|
||||
==== Enabling and Disabling SSL and TLS in mod_ssl
|
||||
|
||||
To disable and enable specific versions of the SSL and TLS protocol, either do it globally by adding the [command]#SSLProtocol# directive in the "\#\# SSL Global Context" section of the configuration file and removing it everywhere else, or edit the default entry under "\# SSL Protocol support" in all "VirtualHost" sections. If you do not specify it in the per-domain VirtualHost section then it will inherit the settings from the global section. To make sure that a protocol version is being disabled the administrator should either *only* specify [command]#SSLProtocol# in the "SSL Global Context" section, or specify it in *all* per-domain VirtualHost sections.
|
||||
To disable and enable specific versions of the SSL and TLS protocol, either do it globally by adding the [command]#SSLProtocol# directive in the "`\#\# SSL Global Context`" section of the configuration file and removing it everywhere else, or edit the default entry under "`\# SSL Protocol support`" in all "`VirtualHost`" sections. If you do not specify it in the per-domain VirtualHost section then it will inherit the settings from the global section. To make sure that a protocol version is being disabled the administrator should either *only* specify [command]#SSLProtocol# in the "`SSL Global Context`" section, or specify it in *all* per-domain VirtualHost sections.
|
||||
|
||||
[[proc-Disable_SSLv2_and_SSLv3]]
|
||||
.Disable SSLv2 and SSLv3
|
||||
|
|
|
|||
|
|
@ -409,7 +409,7 @@ At the same time, you can also set the hardware clock to keep the time in either
|
|||
.Setting the Hardware Clock to a Specific Date and Time
|
||||
====
|
||||
|
||||
If you want to set the date and time to a specific value, for example, to "21:17, October 21, 2014", and keep the hardware clock in UTC, run the command as `root` in the following format:
|
||||
If you want to set the date and time to a specific value, for example, to "`21:17, October 21, 2014`", and keep the hardware clock in UTC, run the command as `root` in the following format:
|
||||
|
||||
[subs="attributes"]
|
||||
----
|
||||
|
|
|
|||
|
|
@ -22,7 +22,7 @@ indexterm:[groups,user private]indexterm:[user private groups,groups]indexterm:[
|
|||
|
||||
User private groups make it safe to set default permissions for a newly created file or directory, allowing both the user and *the group of that user* to make modifications to the file or directory.
|
||||
|
||||
The setting which determines what permissions are applied to a newly created file or directory is called a _umask_ and is configured in the `/etc/bashrc` file. Traditionally on UNIX-based systems, the [command]#umask# is set to [command]#022#, which allows only the user who created the file or directory to make modifications. Under this scheme, all other users, *including members of the creator's group*, are not allowed to make any modifications. However, under the UPG scheme, this "group protection" is not necessary since every user has their own private group.
|
||||
The setting which determines what permissions are applied to a newly created file or directory is called a _umask_ and is configured in the `/etc/bashrc` file. Traditionally on UNIX-based systems, the [command]#umask# is set to [command]#022#, which allows only the user who created the file or directory to make modifications. Under this scheme, all other users, *including members of the creator's group*, are not allowed to make any modifications. However, under the UPG scheme, this "`group protection`" is not necessary since every user has their own private group.
|
||||
|
||||
A list of all groups is stored in the `/etc/group` configuration file.
|
||||
|
||||
|
|
|
|||
|
|
@ -142,7 +142,7 @@ System-wide SSH configuration information is stored in the `/etc/ssh/` directory
|
|||
[options="header"]
|
||||
|===
|
||||
|File|Description
|
||||
|`/etc/ssh/moduli`|Contains Diffie-Hellman groups used for the "Diffie-Hellman group exchange" key exchange method, which is critical for constructing a secure transport layer. When keys are exchanged at the beginning of an SSH session, a shared, secret value is created which cannot be determined by either party alone. If the file is not available, fixed groups will be used. Other key exchange methods do not need this file.
|
||||
|`/etc/ssh/moduli`|Contains Diffie-Hellman groups used for the "`Diffie-Hellman group exchange`" key exchange method, which is critical for constructing a secure transport layer. When keys are exchanged at the beginning of an SSH session, a shared, secret value is created which cannot be determined by either party alone. If the file is not available, fixed groups will be used. Other key exchange methods do not need this file.
|
||||
|`/etc/ssh/ssh_config`|The default SSH client configuration file. Note that it is overridden by `~/.ssh/config` if it exists.
|
||||
|`/etc/ssh/sshd_config`|The configuration file for the [command]#sshd# daemon.
|
||||
|`/etc/ssh/ssh_host_ecdsa_key`|The ECDSA private key used by the [command]#sshd# daemon.
|
||||
|
|
@ -907,7 +907,7 @@ It is possible to sign a host key using a CA key stored in a PKCS#11 token by pr
|
|||
ssh-keygen -s ca_host_key.pub -D libpkcs11.so -I pass:quotes[_certificate_ID_] host_key.pub
|
||||
----
|
||||
|
||||
In all cases, _certificate_ID_ is a "key identifier" that is logged by the server when the certificate is used for authentication.
|
||||
In all cases, _certificate_ID_ is a "`key identifier`" that is logged by the server when the certificate is used for authentication.
|
||||
|
||||
Certificates may be configured to be valid only for a set of users or host names, the principals. By default, generated certificates are valid for all users or hosts. To generate a certificate for a specified set of principals, use a comma separated list with the [option]`-n` option as follows:
|
||||
|
||||
|
|
|
|||
|
|
@ -291,7 +291,7 @@ When you install a kernel using [command]#rpm#, the kernel package creates an en
|
|||
|
||||
It is always recommended to double-check the boot loader configuration file after installing a new kernel with [command]#rpm# to ensure that the configuration is correct. Otherwise, the system might not be able to boot into {MAJOROS} properly. If this happens, boot the system with the boot media created earlier and re-configure the boot loader.
|
||||
|
||||
In the following table, find your system's architecture to determine the boot loader it uses, and then click on the "See" link to jump to the correct instructions for your system.
|
||||
In the following table, find your system's architecture to determine the boot loader it uses, and then click on the "`See`" link to jump to the correct instructions for your system.
|
||||
|
||||
[[tb-grub-arch-loaders]]
|
||||
.Boot loaders by architecture
|
||||
|
|
|
|||
|
|
@ -428,11 +428,11 @@ During boot, the kernel loads X.509 keys into the system key ring or the system
|
|||
|===
|
||||
|Source of X.509 Keys|User Ability to Add Keys|UEFI Secure Boot State|Keys Loaded During Boot
|
||||
|Embedded in kernel|No|-|`.system_keyring`
|
||||
.2+|UEFI Secure Boot "db"
|
||||
.2+|UEFI Secure Boot "`db`"
|
||||
.2+|Limited
|
||||
|Not enabled|No
|
||||
|Enabled|`.system_keyring`
|
||||
.2+|UEFI Secure Boot "dbx"
|
||||
.2+|UEFI Secure Boot "`dbx`"
|
||||
.2+|Limited
|
||||
|Not enabled|No
|
||||
|Enabled|`.system_keyring`
|
||||
|
|
@ -480,7 +480,7 @@ The following is abbreviated example output from a Fedora system where UEFI Secu
|
|||
...asymmetric: Microsoft Corporation UEFI CA 2011: 13adbf4309bd82709c8...
|
||||
----
|
||||
|
||||
The above output shows the addition of two keys from the UEFI Secure Boot "db" keys plus the `Fedora Secure Boot CA` which is embedded in the `shim.efi` boot loader.
|
||||
The above output shows the addition of two keys from the UEFI Secure Boot "`db`" keys plus the `Fedora Secure Boot CA` which is embedded in the `shim.efi` boot loader.
|
||||
|
||||
[[sect-kernel-module-authentication-requirements]]
|
||||
==== Kernel Module Authentication Requirements
|
||||
|
|
|
|||
|
|
@ -109,7 +109,7 @@ To monitor the kernel, execute the following command:
|
|||
operf --vmlinux=pass:quotes[_vmlinux_path_]
|
||||
----
|
||||
|
||||
With this option, you can specify a path to a vmlinux file that matches the running kernel. Kernel samples will be attributed to this binary, allowing post-processing tools to attribute samples to the appropriate kernel symbols. If this option is not specified, all kernel samples will be attributed to a pseudo binary named "no-vmlinux".
|
||||
With this option, you can specify a path to a vmlinux file that matches the running kernel. Kernel samples will be attributed to this binary, allowing post-processing tools to attribute samples to the appropriate kernel symbols. If this option is not specified, all kernel samples will be attributed to a pseudo binary named "`no-vmlinux`".
|
||||
|
||||
[[s2-operf-events]]
|
||||
=== Setting Events to Monitor
|
||||
|
|
@ -178,7 +178,7 @@ xref:OProfile.adoc#tab_event_specifications[Event Specifications] summarizes the
|
|||
|_event-name_|The exact symbolic event name taken from [command]#ophelp#
|
||||
|_sample-rate_|The number of events to wait before sampling again. The smaller the count, the more frequent the samples. For events that do not happen frequently, a lower count may be needed to capture a statistically significant number of event instances. On the other hand, sampling too frequently can overload the system. By default, OProfile uses a time-based event set, which creates a sample every 100,000 clock cycles per processor.
|
||||
|_unit-mask_|Unit masks, which further define the event, are listed in [command]#ophelp#.
|
||||
You can insert either a hexadecimal value, beginning with "0x", or a string that matches the first word of the unit mask description in [command]#ophelp#. Definition by name is valid only for unit masks having "extra:" parameters, as shown by the output of [command]#ophelp#. This type of unit mask cannot be defined with a hexadecimal value. Note that on certain architectures, there can be multiple unit masks with the same hexadecimal value. In that case they have to be specified by their names only.
|
||||
You can insert either a hexadecimal value, beginning with "`0x`", or a string that matches the first word of the unit mask description in [command]#ophelp#. Definition by name is valid only for unit masks having "`extra:`" parameters, as shown by the output of [command]#ophelp#. This type of unit mask cannot be defined with a hexadecimal value. Note that on certain architectures, there can be multiple unit masks with the same hexadecimal value. In that case they have to be specified by their names only.
|
||||
|_kernel_|Specifies whether to profile kernel code (insert `0` or `1`(default))
|
||||
|_user_|Specifies whether to profile user-space code (insert `0` or `1` (default))
|
||||
|===
|
||||
|
|
@ -680,7 +680,7 @@ The data is the same as the [option]`-l` option except that for each symbol, eac
|
|||
indexterm:[OProfile,opreport]indexterm:[OProfile]
|
||||
OProfile collects data on a system-wide basis for kernel- and user-space code running on the machine. However, once a module is loaded into the kernel, the information about the origin of the kernel module is lost. The module could come from the `initrd` file on boot up, the directory with the various kernel modules, or a locally created kernel module. As a result, when OProfile records samples for a module, it just lists the samples for the modules for an executable in the root directory, but this is unlikely to be the place with the actual code for the module. You will need to take some steps to make sure that analysis tools get the proper executable.
|
||||
|
||||
To get a more detailed view of the actions of the module, you will need to either have the module "unstripped" (that is installed from a custom build) or have the [package]*debuginfo* package installed for the kernel.
|
||||
To get a more detailed view of the actions of the module, you will need to either have the module "`unstripped`" (that is installed from a custom build) or have the [package]*debuginfo* package installed for the kernel.
|
||||
|
||||
Find out which kernel is running with the [command]#uname -a# command, obtain the appropriate [package]*debuginfo* package and install it on the machine.
|
||||
|
||||
|
|
@ -778,7 +778,7 @@ While OProfile can be used by developers to analyze application performance, it
|
|||
[[s1-oprofile-java-support]]
|
||||
== OProfile Support for Java
|
||||
indexterm:[OProfile,Java]
|
||||
OProfile allows you to profile dynamically compiled code (also known as "just-in-time" or JIT code) of the Java Virtual Machine (JVM). OProfile in {MAJOROSVER} includes built-in support for the JVM Tools Interface (JVMTI) agent library, which supports Java 1.5 and higher.
|
||||
OProfile allows you to profile dynamically compiled code (also known as "`just-in-time`" or JIT code) of the Java Virtual Machine (JVM). OProfile in {MAJOROSVER} includes built-in support for the JVM Tools Interface (JVMTI) agent library, which supports Java 1.5 and higher.
|
||||
|
||||
[[s1-oprofile-java-profiling]]
|
||||
=== Profiling Java Code
|
||||
|
|
|
|||
|
|
@ -970,7 +970,7 @@ To configure an *SNMP version 2c community*, use either the [option]`rocommunity
|
|||
_directive_ _community_ _source_ _OID_
|
||||
----
|
||||
|
||||
… where _community_ is the community string to use, _source_ is an IP address or subnet, and _OID_ is the SNMP tree to provide access to. For example, the following directive provides read-only access to the `system` tree to a client using the community string "redhat" on the local machine:
|
||||
… where _community_ is the community string to use, _source_ is an IP address or subnet, and _OID_ is the SNMP tree to provide access to. For example, the following directive provides read-only access to the `system` tree to a client using the community string "`redhat`" on the local machine:
|
||||
|
||||
[subs="quotes"]
|
||||
----
|
||||
|
|
@ -990,7 +990,7 @@ SNMPv2-MIB::sysLocation.0 = STRING: Datacenter, Row 3, Rack 2
|
|||
----
|
||||
|
||||
.Configuring SNMP Version 3 User
|
||||
To configure an *SNMP version 3 user*, use the [command]#net-snmp-create-v3-user# command. This command adds entries to the `/var/lib/net-snmp/snmpd.conf` and `/etc/snmp/snmpd.conf` files which create the user and grant access to the user. Note that the [command]#net-snmp-create-v3-user# command may only be run when the agent is not running. The following example creates the "sysadmin" user with the password "redhatsnmp":
|
||||
To configure an *SNMP version 3 user*, use the [command]#net-snmp-create-v3-user# command. This command adds entries to the `/var/lib/net-snmp/snmpd.conf` and `/etc/snmp/snmpd.conf` files which create the user and grant access to the user. Note that the [command]#net-snmp-create-v3-user# command may only be run when the agent is not running. The following example creates the "`sysadmin`" user with the password "`redhatsnmp`":
|
||||
|
||||
----
|
||||
~]# systemctl stop snmpd.service
|
||||
|
|
@ -1018,7 +1018,7 @@ _directive_ _user_ [option]`noauth`|[option]`auth`|[option]`priv` _OID_
|
|||
|
||||
… where _user_ is a username and _OID_ is the SNMP tree to provide access to. By default, the Net-SNMP Agent Daemon allows only authenticated requests (the [option]`auth` option). The [option]`noauth` option allows you to permit unauthenticated requests, and the [option]`priv` option enforces the use of encryption. The [option]`authpriv` option specifies that requests must be authenticated and replies should be encrypted.
|
||||
|
||||
For example, the following line grants the user "admin" read-write access to the entire tree:
|
||||
For example, the following line grants the user "`admin`" read-write access to the entire tree:
|
||||
|
||||
[subs="quotes"]
|
||||
----
|
||||
|
|
@ -1301,7 +1301,7 @@ NET-SNMP-EXTEND-MIB::nsExtendResult."httpd_pids" = INTEGER: 8
|
|||
NET-SNMP-EXTEND-MIB::nsExtendOutLine."httpd_pids".1 = STRING:
|
||||
----
|
||||
|
||||
Note that the exit code ("8" in this example) is provided as an INTEGER type and any output is provided as a STRING type. To expose multiple metrics as integers, supply different arguments to the script using the [option]`extend` directive. For example, the following shell script can be used to determine the number of processes matching an arbitrary string, and will also output a text string giving the number of processes:
|
||||
Note that the exit code ("`8`" in this example) is provided as an INTEGER type and any output is provided as a STRING type. To expose multiple metrics as integers, supply different arguments to the script using the [option]`extend` directive. For example, the following shell script can be used to determine the number of processes matching an arbitrary string, and will also output a text string giving the number of processes:
|
||||
|
||||
----
|
||||
#!/bin/sh
|
||||
|
|
@ -1385,7 +1385,7 @@ The OID `.1.3.6.1.4.1.8072.9999.9999` (`NET-SNMP-MIB::netSnmpPlaypen`) is typica
|
|||
|
||||
====
|
||||
|
||||
The handler function will be called with four parameters, `HANDLER`, `REGISTRATION_INFO`, `REQUEST_INFO`, and `REQUESTS`. The `REQUESTS` parameter contains a list of requests in the current call and should be iterated over and populated with data. The `request` objects in the list have get and set methods which allow for manipulating the `OID` and `value` of the request. For example, the following call will set the value of a request object to the string "hello world":
|
||||
The handler function will be called with four parameters, `HANDLER`, `REGISTRATION_INFO`, `REQUEST_INFO`, and `REQUESTS`. The `REQUESTS` parameter contains a list of requests in the current call and should be iterated over and populated with data. The `request` objects in the list have get and set methods which allow for manipulating the `OID` and `value` of the request. For example, the following call will set the value of a request object to the string "`hello world`":
|
||||
|
||||
----
|
||||
$request->setValue(ASN_OCTET_STR, "hello world");
|
||||
|
|
@ -1420,7 +1420,7 @@ for($request = $requests; $request; $request = $request->next()) {
|
|||
}
|
||||
----
|
||||
|
||||
When `getMode` returns `MODE_GET`, the handler analyzes the value of the `getOID` call on the `request` object. The `value` of the `request` is set to either `string_value` if the OID ends in ".1.0", or set to `integer_value` if the OID ends in ".1.1". If the `getMode` returns `MODE_GETNEXT`, the handler determines whether the OID of the request is ".1.0", and then sets the OID and value for ".1.1". If the request is higher on the tree than ".1.0", the OID and value for ".1.0" is set. This in effect returns the "next" value in the tree so that a program like [command]#snmpwalk# can traverse the tree without prior knowledge of the structure.
|
||||
When `getMode` returns `MODE_GET`, the handler analyzes the value of the `getOID` call on the `request` object. The `value` of the `request` is set to either `string_value` if the OID ends in "`.1.0`", or set to `integer_value` if the OID ends in "`.1.1`". If the `getMode` returns `MODE_GETNEXT`, the handler determines whether the OID of the request is "`.1.0`", and then sets the OID and value for "`.1.1`". If the request is higher on the tree than "`.1.0`", the OID and value for "`.1.0`" is set. This in effect returns the "`next`" value in the tree so that a program like [command]#snmpwalk# can traverse the tree without prior knowledge of the structure.
|
||||
|
||||
The type of the variable is set using constants from `NetSNMP::ASN`. See the [command]#perldoc# for `NetSNMP::ASN` for a full list of available constants.
|
||||
|
||||
|
|
|
|||
|
|
@ -170,7 +170,7 @@ With expression-based filters, you can nest the conditions by using a script enc
|
|||
.Expression-based Filters
|
||||
====
|
||||
|
||||
The following expression contains two nested conditions. The log files created by a program called *prog1* are split into two files based on the presence of the "test" string in the message.
|
||||
The following expression contains two nested conditions. The log files created by a program called *prog1* are split into two files based on the presence of the "`test`" string in the message.
|
||||
|
||||
[subs="quotes"]
|
||||
----
|
||||
|
|
@ -261,7 +261,7 @@ The following are some examples of actions that forward syslog messages over the
|
|||
|
||||
----
|
||||
|
||||
To forward messages to "example.com" using port 18 and the `TCP` protocol, use:
|
||||
To forward messages to "`example.com`" using port 18 and the `TCP` protocol, use:
|
||||
|
||||
----
|
||||
|
||||
|
|
@ -1633,7 +1633,7 @@ To run `rsyslogd` in debugging mode, use the following command:
|
|||
`rsyslogd` [option]`-dn`
|
||||
----
|
||||
|
||||
With this command, `rsyslogd` produces debugging information and prints it to the standard output. The [option]`-n` stands for "no fork". You can modify debugging with environmental variables, for example, you can store the debug output in a log file. Before starting `rsyslogd`, type the following on the command line:
|
||||
With this command, `rsyslogd` produces debugging information and prints it to the standard output. The [option]`-n` stands for "`no fork`". You can modify debugging with environmental variables, for example, you can store the debug output in a log file. Before starting `rsyslogd`, type the following on the command line:
|
||||
|
||||
[subs="macros"]
|
||||
----
|
||||
|
|
|
|||
|
|
@ -160,7 +160,7 @@ Add the [option]`all` to match against descriptions and URLs.
|
|||
[command]#dnf# [option]`search all` _term_pass:attributes[{blank}]…
|
||||
----
|
||||
|
||||
This command displays the list of matches for each term. For example, to list all packages that match "meld" or "kompare", type:
|
||||
This command displays the list of matches for each term. For example, to list all packages that match "`meld`" or "`kompare`", type:
|
||||
|
||||
----
|
||||
~]# dnf search meld kompare
|
||||
|
|
@ -217,7 +217,7 @@ See xref:DNF.adoc#ex-Listing_all_ABRT_addons_and_plugins_using_glob_expressions[
|
|||
.Listing all ABRT addons and plug-ins using glob expressions
|
||||
====
|
||||
|
||||
Packages with various ABRT addons and plug-ins either begin with "abrt-addon-", or "abrt-plugin-". To list these packages, type the following at a shell prompt:
|
||||
Packages with various ABRT addons and plug-ins either begin with "`abrt-addon-`", or "`abrt-plugin-`". To list these packages, type the following at a shell prompt:
|
||||
|
||||
----
|
||||
~]# dnf list abrt-addon\* abrt-plugin\*
|
||||
|
|
@ -265,7 +265,7 @@ indexterm:[packages,listing packages with DNF,dnf list installed] ind
|
|||
.Listing installed packages using a double-quoted glob expression
|
||||
====
|
||||
|
||||
To list all installed packages that begin with "krb" followed by exactly one character and a hyphen, type:
|
||||
To list all installed packages that begin with "`krb`" followed by exactly one character and a hyphen, type:
|
||||
|
||||
----
|
||||
~]# dnf list installed "krb?-*"
|
||||
|
|
@ -283,7 +283,7 @@ indexterm:[packages,listing packages with DNF,dnf list available] ind
|
|||
.Listing available packages using a single glob expression with escaped wildcard characters
|
||||
====
|
||||
|
||||
To list all available packages with names that contain "gstreamer" and then "plugin", run the following command:
|
||||
To list all available packages with names that contain "`gstreamer`" and then "`plugin`", run the following command:
|
||||
|
||||
----
|
||||
~]# dnf list available gstreamer\*plugin\*
|
||||
|
|
@ -788,7 +788,7 @@ _parameter_pass:attributes[{blank}]=pass:attributes[{blank}]_repository_url_::
|
|||
+
|
||||
** If the repository is local to the machine, use: `file:///path/to/local/repo`
|
||||
+
|
||||
** If a specific online repository requires basic HTTP authentication, you can specify your user name and password by prepending it to the URL as [option]`pass:attributes[{blank}]_username_:pass:attributes[{blank}]_password_pass:attributes[{blank}]@pass:attributes[{blank}]_link_pass:attributes[{blank}]`. For example, if a repository on http://www.example.com/repo/ requires a username of "user" and a password of "password", then the [option]`baseurl` link could be specified as [option]`http://user:password@www.example.com/repo/`.
|
||||
** If a specific online repository requires basic HTTP authentication, you can specify your user name and password by prepending it to the URL as [option]`pass:attributes[{blank}]_username_:pass:attributes[{blank}]_password_pass:attributes[{blank}]@pass:attributes[{blank}]_link_pass:attributes[{blank}]`. For example, if a repository on http://www.example.com/repo/ requires a username of "`user`" and a password of "`password`", then the [option]`baseurl` link could be specified as [option]`http://user:password@www.example.com/repo/`.
|
||||
+
|
||||
Usually this URL is an HTTP link, such as:
|
||||
+
|
||||
|
|
|
|||
|
|
@ -2,7 +2,7 @@ include::{partialsdir}/entities.adoc[]
|
|||
|
||||
= Package Management
|
||||
|
||||
There are two types of {MAJOROS} system; "traditional", which use DNF, and "image-based" which use rpm-ostree.
|
||||
There are two types of {MAJOROS} system; "`traditional`", which use DNF, and "`image-based`" which use rpm-ostree.
|
||||
|
||||
== Traditional package management
|
||||
|
||||
|
|
@ -11,9 +11,9 @@ can be managed via [application]*DNF*.
|
|||
|
||||
== Hybrid image/package management
|
||||
|
||||
The "Atomic" variant of {MAJOROS} uses [application]*rpm-ostree* to update the
|
||||
The "`Atomic`" variant of {MAJOROS} uses [application]*rpm-ostree* to update the
|
||||
host. `rpm-ostree` is a hybrid image/package system. By default, installations
|
||||
are in "image" mode using OSTree, but additional packages can be installed. It
|
||||
are in "`image`" mode using OSTree, but additional packages can be installed. It
|
||||
also supports overrides, rebases, and many other features. For more information,
|
||||
see link:++https://www.projectatomic.io/docs/os-updates/++[its online documentation].
|
||||
|
||||
|
|
|
|||
|
|
@ -8,11 +8,11 @@ include::{partialsdir}/entities.adoc[]
|
|||
[[s1-Introduction_to_NTP]]
|
||||
== Introduction to NTP
|
||||
|
||||
The _Network Time Protocol_ (*NTP*) enables the accurate dissemination of time and date information in order to keep the time clocks on networked computer systems synchronized to a common reference over the network or the Internet. Many standards bodies around the world have atomic clocks which may be made available as a reference. The satellites that make up the Global Position System contain more than one atomic clock, making their time signals potentially very accurate. Their signals can be deliberately degraded for military reasons. An ideal situation would be where each site has a server, with its own reference clock attached, to act as a site-wide time server. Many devices which obtain the time and date via low frequency radio transmissions or the Global Position System (GPS) exist. However for most situations, a range of publicly accessible time servers connected to the Internet at geographically dispersed locations can be used. These `NTP` servers provide "pass:attributes[{blank}]_Coordinated Universal Time_pass:attributes[{blank}]" (*UTC*). Information about these time servers can found at [citetitle]_www.pool.ntp.org_.
|
||||
The _Network Time Protocol_ (*NTP*) enables the accurate dissemination of time and date information in order to keep the time clocks on networked computer systems synchronized to a common reference over the network or the Internet. Many standards bodies around the world have atomic clocks which may be made available as a reference. The satellites that make up the Global Position System contain more than one atomic clock, making their time signals potentially very accurate. Their signals can be deliberately degraded for military reasons. An ideal situation would be where each site has a server, with its own reference clock attached, to act as a site-wide time server. Many devices which obtain the time and date via low frequency radio transmissions or the Global Position System (GPS) exist. However for most situations, a range of publicly accessible time servers connected to the Internet at geographically dispersed locations can be used. These `NTP` servers provide "`pass:attributes[{blank}]_Coordinated Universal Time_pass:attributes[{blank}]`" (*UTC*). Information about these time servers can found at [citetitle]_www.pool.ntp.org_.
|
||||
|
||||
Accurate time keeping is important for a number of reasons in IT. In networking for example, accurate time stamps in packets and logs are required. Logs are used to investigate service and security issues and so time stamps made on different systems must be made by synchronized clocks to be of real value. As systems and networks become increasingly faster, there is a corresponding need for clocks with greater accuracy and resolution. In some countries there are legal obligations to keep accurately synchronized clocks. Please see [citetitle]_www.ntp.org_ for more information. In Linux systems, `NTP` is implemented by a daemon running in user space. The default `NTP` user space daemon in {MAJOROSVER} is `chronyd`. It must be disabled if you want to use the `ntpd` daemon. See xref:servers/Configuring_NTP_Using_the_chrony_Suite.adoc#ch-Configuring_NTP_Using_the_chrony_Suite[Configuring NTP Using the chrony Suite] for information on [application]*chrony*.
|
||||
|
||||
The user space daemon updates the system clock, which is a software clock running in the kernel. Linux uses a software clock as its system clock for better resolution than the typical embedded hardware clock referred to as the "pass:attributes[{blank}]_Real Time Clock_pass:attributes[{blank}]" *(RTC)*. See the `rtc(4)` and `hwclock(8)` man pages for information on hardware clocks. The system clock can keep time by using various clock sources. Usually, the _Time Stamp Counter_ (*TSC*) is used. The TSC is a CPU register which counts the number of cycles since it was last reset. It is very fast, has a high resolution, and there are no interrupts. On system start, the system clock reads the time and date from the RTC. The time kept by the RTC will drift away from actual time by up to 5 minutes per month due to temperature variations. Hence the need for the system clock to be constantly synchronized with external time references. When the system clock is being synchronized by `ntpd`, the kernel will in turn update the RTC every 11 minutes automatically.
|
||||
The user space daemon updates the system clock, which is a software clock running in the kernel. Linux uses a software clock as its system clock for better resolution than the typical embedded hardware clock referred to as the "`pass:attributes[{blank}]_Real Time Clock_pass:attributes[{blank}]`" *(RTC)*. See the `rtc(4)` and `hwclock(8)` man pages for information on hardware clocks. The system clock can keep time by using various clock sources. Usually, the _Time Stamp Counter_ (*TSC*) is used. The TSC is a CPU register which counts the number of cycles since it was last reset. It is very fast, has a high resolution, and there are no interrupts. On system start, the system clock reads the time and date from the RTC. The time kept by the RTC will drift away from actual time by up to 5 minutes per month due to temperature variations. Hence the need for the system clock to be constantly synchronized with external time references. When the system clock is being synchronized by `ntpd`, the kernel will in turn update the RTC every 11 minutes automatically.
|
||||
|
||||
[[s1-NTP_Strata]]
|
||||
== NTP Strata
|
||||
|
|
@ -54,11 +54,11 @@ Specification, Implementation and Analysis]_ and [citetitle]_link:++https://www.
|
|||
|
||||
This implementation of `NTP` enables sub-second accuracy to be achieved. Over the Internet, accuracy to 10s of milliseconds is normal. On a Local Area Network (LAN), 1 ms accuracy is possible under ideal conditions. This is because clock drift is now accounted and corrected for, which was not done in earlier, simpler, time protocol systems. A resolution of 233 picoseconds is provided by using 64-bit time stamps. The first 32-bits of the time stamp is used for seconds, the last 32-bits are used for fractions of seconds.
|
||||
|
||||
`NTP` represents the time as a count of the number of seconds since 00:00 (midnight) 1 January, 1900 GMT. As 32-bits is used to count the seconds, this means the time will "roll over" in 2036. However `NTP` works on the difference between time stamps so this does not present the same level of problem as other implementations of time protocols have done. If a hardware clock that is within 68 years of the correct time is available at boot time then `NTP` will correctly interpret the current date. The `NTP4` specification provides for an "Era Number" and an "Era Offset" which can be used to make software more robust when dealing with time lengths of more than 68 years. Note, please do not confuse this with the Unix Year 2038 problem.
|
||||
`NTP` represents the time as a count of the number of seconds since 00:00 (midnight) 1 January, 1900 GMT. As 32-bits is used to count the seconds, this means the time will "`roll over`" in 2036. However `NTP` works on the difference between time stamps so this does not present the same level of problem as other implementations of time protocols have done. If a hardware clock that is within 68 years of the correct time is available at boot time then `NTP` will correctly interpret the current date. The `NTP4` specification provides for an "`Era Number`" and an "`Era Offset`" which can be used to make software more robust when dealing with time lengths of more than 68 years. Note, please do not confuse this with the Unix Year 2038 problem.
|
||||
|
||||
The `NTP` protocol provides additional information to improve accuracy. Four time stamps are used to allow the calculation of round-trip time and server response time. In order for a system in its role as `NTP` client to synchronize with a reference time server, a packet is sent with an "originate time stamp". When the packet arrives, the time server adds a "receive time stamp". After processing the request for time and date information and just before returning the packet, it adds a "transmit time stamp". When the returning packet arrives at the `NTP` client, a "receive time stamp" is generated. The client can now calculate the total round trip time and by subtracting the processing time derive the actual traveling time. By assuming the outgoing and return trips take equal time, the single-trip delay in receiving the `NTP` data is calculated. The full `NTP` algorithm is much more complex than presented here.
|
||||
The `NTP` protocol provides additional information to improve accuracy. Four time stamps are used to allow the calculation of round-trip time and server response time. In order for a system in its role as `NTP` client to synchronize with a reference time server, a packet is sent with an "`originate time stamp`". When the packet arrives, the time server adds a "`receive time stamp`". After processing the request for time and date information and just before returning the packet, it adds a "`transmit time stamp`". When the returning packet arrives at the `NTP` client, a "`receive time stamp`" is generated. The client can now calculate the total round trip time and by subtracting the processing time derive the actual traveling time. By assuming the outgoing and return trips take equal time, the single-trip delay in receiving the `NTP` data is calculated. The full `NTP` algorithm is much more complex than presented here.
|
||||
|
||||
When a packet containing time information is received it is not immediately responded to, but is first subject to validation checks and then processed together with several other time samples to arrive at an estimate of the time. This is then compared to the system clock to determine the time offset, the difference between the system clock's time and what `ntpd` has determined the time should be. The system clock is adjusted slowly, at most at a rate of 0.5ms per second, to reduce this offset by changing the frequency of the counter being used. It will take at least 2000 seconds to adjust the clock by 1 second using this method. This slow change is referred to as slewing and cannot go backwards. If the time offset of the clock is more than 128ms (the default setting), `ntpd` can "step" the clock forwards or backwards. If the time offset at system start is greater than 1000 seconds then the user, or an installation script, should make a manual adjustment. See xref:basic-system-configuration/Configuring_the_Date_and_Time.adoc#ch-Configuring_the_Date_and_Time[Configuring the Date and Time]. With the [option]`-g` option to the [command]#ntpd# command (used by default), any offset at system start will be corrected, but during normal operation only offsets of up to 1000 seconds will be corrected.
|
||||
When a packet containing time information is received it is not immediately responded to, but is first subject to validation checks and then processed together with several other time samples to arrive at an estimate of the time. This is then compared to the system clock to determine the time offset, the difference between the system clock's time and what `ntpd` has determined the time should be. The system clock is adjusted slowly, at most at a rate of 0.5ms per second, to reduce this offset by changing the frequency of the counter being used. It will take at least 2000 seconds to adjust the clock by 1 second using this method. This slow change is referred to as slewing and cannot go backwards. If the time offset of the clock is more than 128ms (the default setting), `ntpd` can "`step`" the clock forwards or backwards. If the time offset at system start is greater than 1000 seconds then the user, or an installation script, should make a manual adjustment. See xref:basic-system-configuration/Configuring_the_Date_and_Time.adoc#ch-Configuring_the_Date_and_Time[Configuring the Date and Time]. With the [option]`-g` option to the [command]#ntpd# command (used by default), any offset at system start will be corrected, but during normal operation only offsets of up to 1000 seconds will be corrected.
|
||||
|
||||
Some software may fail or produce an error if the time is changed backwards. For systems that are sensitive to step changes in the time, the threshold can be changed to 600s instead of 128ms using the [option]`-x` option (unrelated to the [option]`-g` option). Using the [option]`-x` option to increase the stepping limit from 0.128s to 600s has a drawback because a different method of controlling the clock has to be used. It disables the kernel clock discipline and may have a negative impact on the clock accuracy. The [option]`-x` option can be added to the `/etc/sysconfig/ntpd` configuration file.
|
||||
|
||||
|
|
@ -142,7 +142,7 @@ See [citetitle]_link:++https://access.redhat.com/security/cve/CVE-2013-5211++[CV
|
|||
|
||||
====
|
||||
|
||||
Addresses within the range `127.0.0.0/8` are sometimes required by various processes or applications. As the "restrict default" line above prevents access to everything not explicitly allowed, access to the standard loopback address for `IPv4` and `IPv6` is permitted by means of the following lines:
|
||||
Addresses within the range `127.0.0.0/8` are sometimes required by various processes or applications. As the "`restrict default`" line above prevents access to everything not explicitly allowed, access to the standard loopback address for `IPv4` and `IPv6` is permitted by means of the following lines:
|
||||
|
||||
----
|
||||
# the administrative functions.
|
||||
|
|
@ -152,7 +152,7 @@ restrict ::1
|
|||
|
||||
Addresses can be added underneath if specifically required by another application.
|
||||
|
||||
Hosts on the local network are not permitted because of the "restrict default" line above. To change this, for example to allow hosts from the `192.0.2.0/24` network to query the time and statistics but nothing more, a line in the following format is required:
|
||||
Hosts on the local network are not permitted because of the "`restrict default`" line above. To change this, for example to allow hosts from the `192.0.2.0/24` network to query the time and statistics but nothing more, a line in the following format is required:
|
||||
|
||||
[subs="quotes"]
|
||||
----
|
||||
|
|
@ -301,7 +301,7 @@ To start the graphical firewall configuration tool using the command line, enter
|
|||
|
||||
The `Firewall Configuration` window opens. Note, this command can be run as normal user but you will then be prompted for the `root` password from time to time.
|
||||
|
||||
Look for the word "Connected" in the lower left corner. This indicates that the [application]*firewall-config* tool is connected to the user space daemon, `firewalld`.
|
||||
Look for the word "`Connected`" in the lower left corner. This indicates that the [application]*firewall-config* tool is connected to the user space daemon, `firewalld`.
|
||||
|
||||
[[s2-Change_the_firewall_settings]]
|
||||
=== Change the Firewall Settings
|
||||
|
|
@ -374,7 +374,7 @@ where _option_ is one or more of:
|
|||
|
||||
* [option]`ignore` — All packets will be ignored, including `ntpq` and `ntpdc` queries.
|
||||
|
||||
* [option]`kod` — a "Kiss-o'-death" packet is to be sent to reduce unwanted queries.
|
||||
* [option]`kod` — a "`Kiss-o'-death`" packet is to be sent to reduce unwanted queries.
|
||||
|
||||
* [option]`limited` — do not respond to time service requests if the packet violates the rate limit default values or those specified by the [command]#discard# command. `ntpq` and `ntpdc` queries are not affected. For more information on the [command]#discard# command and the default values, see xref:Configuring_NTP_Using_ntpd.adoc#s2_Configure_Rate_Limiting_Access_to_an_NTP_Service[Configure Rate Limiting Access to an NTP Service].
|
||||
|
||||
|
|
@ -626,7 +626,7 @@ To specify that a particular _time-to-live_ (*TTL*) value should be used in plac
|
|||
[command]#ttl# _value_
|
||||
----
|
||||
|
||||
Specify the time-to-live value to be used in packets sent by broadcast servers and multicast `NTP` servers. Specify the maximum time-to-live value to use for the "expanding ring search" by a manycast client. The default value is `127`.
|
||||
Specify the time-to-live value to be used in packets sent by broadcast servers and multicast `NTP` servers. Specify the maximum time-to-live value to use for the "`expanding ring search`" by a manycast client. The default value is `127`.
|
||||
|
||||
[[s2_Configuring_The_Version_of_NTP_to_use]]
|
||||
=== Configuring the NTP Version to Use
|
||||
|
|
|
|||
|
|
@ -95,13 +95,13 @@ allow 2001:db8::/32
|
|||
|
||||
Use this form to specify an `IPv6` address to be allowed access.
|
||||
|
||||
cmdallow:: This is similar to the [command]#allow# directive (see section [command]#allow#), except that it allows control access (rather than `NTP` client access) to a particular subnet or host. (By "control access" is meant that [application]*chronyc* can be run on those hosts and successfully connect to `chronyd` on this computer.) The syntax is identical. There is also a [command]#cmddeny all# directive with similar behavior to the [command]#cmdallow all# directive.
|
||||
cmdallow:: This is similar to the [command]#allow# directive (see section [command]#allow#), except that it allows control access (rather than `NTP` client access) to a particular subnet or host. (By "`control access`" is meant that [application]*chronyc* can be run on those hosts and successfully connect to `chronyd` on this computer.) The syntax is identical. There is also a [command]#cmddeny all# directive with similar behavior to the [command]#cmdallow all# directive.
|
||||
|
||||
dumpdir:: Path to the directory to save the measurement history across restarts of `chronyd` (assuming no changes are made to the system clock behavior whilst it is not running). If this capability is to be used (via the [command]#dumponexit# command in the configuration file, or the [command]#dump# command in [application]*chronyc*), the [command]#dumpdir# command should be used to define the directory where the measurement histories are saved.
|
||||
|
||||
dumponexit:: If this command is present, it indicates that `chronyd` should save the measurement history for each of its time sources recorded whenever the program exits. (See the [command]#dumpdir# command above).
|
||||
|
||||
local:: The [command]#local# keyword is used to allow `chronyd` to appear synchronized to real time from the viewpoint of clients polling it, even if it has no current synchronization source. This option is normally used on the "master" computer in an isolated network, where several computers are required to synchronize to one another, and the "master" is kept in line with real time by manual input.
|
||||
local:: The [command]#local# keyword is used to allow `chronyd` to appear synchronized to real time from the viewpoint of clients polling it, even if it has no current synchronization source. This option is normally used on the "`master`" computer in an isolated network, where several computers are required to synchronize to one another, and the "`master`" is kept in line with real time by manual input.
|
||||
|
||||
An example of the command is:
|
||||
|
||||
|
|
@ -398,7 +398,7 @@ Leap status : Normal
|
|||
|
||||
The fields are as follows:
|
||||
|
||||
Reference ID:: This is the reference ID and name (or `IP` address) if available, of the server to which the computer is currently synchronized. If this is `127.127.1.1` it means the computer is not synchronized to any external source and that you have the "local" mode operating (via the local command in [application]*chronyc*, or the [command]#local# directive in the `/etc/chrony.conf` file (see section [command]#local#)).
|
||||
Reference ID:: This is the reference ID and name (or `IP` address) if available, of the server to which the computer is currently synchronized. If this is `127.127.1.1` it means the computer is not synchronized to any external source and that you have the "`local`" mode operating (via the local command in [application]*chronyc*, or the [command]#local# directive in the `/etc/chrony.conf` file (see section [command]#local#)).
|
||||
|
||||
Stratum:: The stratum indicates how many hops away from a computer with an attached reference clock we are. Such a computer is a stratum-1 computer, so the computer in the example is two hops away (that is to say, a.b.c is a stratum-2 and is synchronized from a stratum-1).
|
||||
|
||||
|
|
@ -410,9 +410,9 @@ Last offset:: This is the estimated local offset on the last clock update.
|
|||
|
||||
RMS offset:: This is a long-term average of the offset value.
|
||||
|
||||
Frequency:: The "frequency" is the rate by which the system’s clock would be wrong if `chronyd` was not correcting it. It is expressed in ppm (parts per million). For example, a value of 1ppm would mean that when the system’s clock thinks it has advanced 1 second, it has actually advanced by 1.000001 seconds relative to true time.
|
||||
Frequency:: The "`frequency`" is the rate by which the system’s clock would be wrong if `chronyd` was not correcting it. It is expressed in ppm (parts per million). For example, a value of 1ppm would mean that when the system’s clock thinks it has advanced 1 second, it has actually advanced by 1.000001 seconds relative to true time.
|
||||
|
||||
Residual freq:: This shows the "residual frequency" for the currently selected reference source. This reflects any difference between what the measurements from the reference source indicate the frequency should be and the frequency currently being used.
|
||||
Residual freq:: This shows the "`residual frequency`" for the currently selected reference source. This reflects any difference between what the measurements from the reference source indicate the frequency should be and the frequency currently being used.
|
||||
|
||||
The reason this is not always zero is that a smoothing procedure is applied to the frequency. Each time a measurement from the reference source is obtained and a new residual frequency computed, the estimated accuracy of this residual is compared with the estimated accuracy (see [option]`skew` next) of the existing frequency value. A weighted average is computed for the new frequency, with weights depending on these accuracies. If the measurements from the reference source follow a consistent trend, the residual will be driven to zero over time.
|
||||
|
||||
|
|
@ -448,8 +448,8 @@ The columns are as follows:
|
|||
|
||||
M:: This indicates the mode of the source. `^` means a server, `=` means a peer and `#` indicates a locally connected reference clock.
|
||||
|
||||
S:: This column indicates the state of the sources. "*" indicates the source to which `chronyd` is currently synchronized. "+" indicates acceptable sources which are combined with the selected source. "-" indicates acceptable sources which are excluded by the combining algorithm. "?" indicates sources to which connectivity has been lost or whose packets do not pass all tests. "x" indicates a clock which `chronyd` thinks is a _falseticker_ (its time is inconsistent with a majority of other sources). "~" indicates a source whose time appears to have too much
|
||||
variability. The "?" condition is also shown at start-up, until at least 3 samples have been gathered from it.
|
||||
S:: This column indicates the state of the sources. "`*`" indicates the source to which `chronyd` is currently synchronized. "`+`" indicates acceptable sources which are combined with the selected source. "`-`" indicates acceptable sources which are excluded by the combining algorithm. "`?`" indicates sources to which connectivity has been lost or whose packets do not pass all tests. "`x`" indicates a clock which `chronyd` thinks is a _falseticker_ (its time is inconsistent with a majority of other sources). "`~`" indicates a source whose time appears to have too much
|
||||
variability. The "`?`" condition is also shown at start-up, until at least 3 samples have been gathered from it.
|
||||
|
||||
Name/IP address:: This shows the name or the `IP` address of the source, or reference ID for reference clocks.
|
||||
|
||||
|
|
|
|||
|
|
@ -166,7 +166,7 @@ The *P2P* mechanism is preferred as it reacts to changes in the network topology
|
|||
|
||||
[option]`-E`:: The [option]`-E` selects the _end-to-end_ (*E2E*) delay measurement mechanism. This is the default.
|
||||
|
||||
The *E2E* mechanism is also referred to as the delay "request-response" mechanism.
|
||||
The *E2E* mechanism is also referred to as the delay "`request-response`" mechanism.
|
||||
|
||||
[option]`-A`:: The [option]`-A` enables automatic selection of the delay measurement mechanism.
|
||||
|
||||
|
|
@ -559,7 +559,7 @@ Notice the section named as follows:
|
|||
[ntp_server pass:quotes[_address_]]
|
||||
----
|
||||
|
||||
This is an example of an `NTP` server section, "ntp-server.local" is an example of a host name for an `NTP` server on the local LAN. Add more sections as required using a host name or `IP` address as part of the section name. Note that the short polling values in that example section are not suitable for a public server, see xref:servers/Configuring_NTP_Using_ntpd.adoc#ch-Configuring_NTP_Using_ntpd[Configuring NTP Using ntpd] for an explanation of suitable [option]`minpoll` and [option]`maxpoll` values.
|
||||
This is an example of an `NTP` server section, "`ntp-server.local`" is an example of a host name for an `NTP` server on the local LAN. Add more sections as required using a host name or `IP` address as part of the section name. Note that the short polling values in that example section are not suitable for a public server, see xref:servers/Configuring_NTP_Using_ntpd.adoc#ch-Configuring_NTP_Using_ntpd[Configuring NTP Using ntpd] for an explanation of suitable [option]`minpoll` and [option]`maxpoll` values.
|
||||
|
||||
Notice the section named as follows:
|
||||
|
||||
|
|
@ -568,7 +568,7 @@ Notice the section named as follows:
|
|||
[ptp_domain pass:quotes[_number_]]
|
||||
----
|
||||
|
||||
A "PTP domain" is a group of one or more `PTP` clocks that synchronize to each other. They may or may not be synchronized to clocks in another domain. Clocks that are configured with the same domain number make up the domain. This includes a `PTP` grandmaster clock. The domain number in each "PTP domain" section needs to correspond to one of the `PTP` domains configured on the network.
|
||||
A "`PTP domain`" is a group of one or more `PTP` clocks that synchronize to each other. They may or may not be synchronized to clocks in another domain. Clocks that are configured with the same domain number make up the domain. This includes a `PTP` grandmaster clock. The domain number in each "`PTP domain`" section needs to correspond to one of the `PTP` domains configured on the network.
|
||||
|
||||
An instance of [application]*ptp4l* is started for every interface which has its own `PTP` clock and hardware time stamping is enabled automatically. Interfaces that support hardware time stamping have a `PTP` clock (PHC) attached, however it is possible for a group of interfaces on a NIC to share a PHC. A separate [application]*ptp4l* instance will be started for each group of interfaces sharing the same PHC and for each interface that supports only software time stamping. All [application]*ptp4l* instances are configured to run as a slave. If an interface with hardware time stamping is specified in more than one `PTP` domain, then only the first [application]*ptp4l* instance created will have hardware time stamping enabled.
|
||||
|
||||
|
|
|
|||
|
|
@ -838,7 +838,7 @@ Flags are essential to determine how or if a recipe's conditions are compared to
|
|||
|
||||
* [command]#w# — Tells Procmail to wait for the specified filter or program to finish, and reports whether or not it was successful before considering the message filtered.
|
||||
|
||||
* [command]#W# — Is identical to [command]#w# except that "Program failure" messages are suppressed.
|
||||
* [command]#W# — Is identical to [command]#w# except that "`Program failure`" messages are suppressed.
|
||||
|
||||
For a detailed list of additional flags, see the `procmailrc` man page.
|
||||
|
||||
|
|
|
|||
Reference in a new issue