mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 11. Networking logrotate now correctly works with wpa_supplicant Previously, wpa_supplicant did not correctly truncate the log file when the logrotate script attempted to rotate it. This bug has been fixed and logrotate now correctly coordinates log rotation with wpa_supplicant . (BZ#908306) Bug fixes in system-config-network This release brings multiple bug fixes to the Network Configuration tool ( system-config-network ). Notable fixes include: Previously, when system-config-network was used to change the system host name, the new host name was appended to the /etc/hosts file every time, even if the same host name was previously used. This could cause the /etc/hosts file to be unnecessarily cluttered. With this update, new host names are only appended if they have not been used previously. A bug preventing suppression of DNS settings has been fixed and you can now suppress DNS settings by leaving the DNS field empty. In some circumstances, system-config-network could display text messages in the text-based interface before the text framework was properly cleaned, resulting in the message being distorted. This bug has been fixed and text messages from this tool now display correctly. (BZ#1086282) NetworkManager no longer brings down connections when saving a configuration file in vim Previously, editing network connection configuration files in editors which save files by deleting and recreating them (such as vim ) caused NetworkManager to bring down the edited connection if it was active at the time. This bug has been fixed and active connections can now be safely edited in any text editor. (BZ#1272617) Bond devices not created by NetworkManager now work correctly Previously, bond devices named bond0 , which created when the bonding module was loaded and not by NetworkManager , were incorrectly configured if the network service was disabled. This bug has been fixed and bond devices now work correctly with NetworkManager . (BZ#1292502) NetworkManager no longer ignores the DHCP-provided list of search domains Previously, NetworkManager used the host's DNS domain suffix to configure the DNS resolver ( /etc/resolv.conf ), and ignored the list of search domain supplied by DHCP. This bug has been fixed and NetworkManager now correctly configures the DNS resolver using DHCP. (BZ#1202539) NetworkManager can now distinguish between software and hardware devices with the same hadware address Previously, NetworkManager ignored connections for software devices such as bonds and bridges if the underlying hardware devices used the same hardware address (the HWADDR key) and used the NM_CONTROLLED=no setting. This bug has been fixed and NetworkManager now works with such devices correctly. (BZ#902907)

Commands:
Chapter 51. module This chapter describes the commands under the module command. 51.1. module list List module versions Usage: Table 51.1. Command arguments Value Summary -h, --help Show this help message and exit --all Show all modules that have version information Table 51.2. Output formatter options Value Summary -f {json,shell,table,value,yaml}, --format {json,shell,table,value,yaml} The output format, defaults to table -c COLUMN, --column COLUMN Specify the column(s) to include, can be repeated Table 51.3. JSON formatter options Value Summary --noindent Whether to disable indenting the json Table 51.4. Shell formatter options Value Summary --prefix PREFIX Add a prefix to all variable names Table 51.5. Table formatter options Value Summary --max-width <integer> Maximum display width, <1 to disable. you can also use the CLIFF_MAX_TERM_WIDTH environment variable, but the parameter takes precedence. --fit-width Fit the table to the display width. implied if --max- width greater than 0. Set the environment variable CLIFF_FIT_WIDTH=1 to always enable --print-empty Print empty table if there is no data to show.

Commands:
openstack module list [-h] [-f {json,shell,table,value,yaml}] [-c COLUMN] [--noindent] [--prefix PREFIX] [--max-width <integer>] [--fit-width] [--print-empty] [--all]
Chapter 20. Red Hat Enterprise Linux 7.5 for IBM Power LE (POWER9) Red Hat Enterprise Linux 7.5 for IBM Power LE (POWER9) introduces Red Hat Enterprise Linux 7.5 user space with an updated kernel, which is based on version 4.14 and is provided by the kernel-alt packages. The offering is distributed with other updated packages but most of it is the standard Red Hat Enterprise Linux 7 Server RPMs. Installation ISO images are available on the Customer Portal Downloads page . For information about Red Hat Enterprise Linux 7.5 installation and user space, see the Installation Guide and other Red Hat Enterprise Linux 7 documentation . For information regarding the version, refer to Red Hat Enterprise Linux 7.4 for IBM Power LE (POWER9) - Release Notes. Note Bare metal installations on IBM Power LE using a USB drive require you to specify the inst.stage2= boot option manually at the boot menu. See the Boot Options chapter in the Installation Guide for detailed information. 20.1. New Features and Updates Virtualization KVM virtualization is now supported on IBM POWER9 systems. However, due to hardware differences, certain features and functionalities differ from what is supported on AMD64 and Intel 64 systems. For details, see the Virtualization Deployment and Administration Guide . Platform Tools OProfile now includes support for the IBM POWER9 processor. Note that the PM_RUN_INST_CMPL OProfile performance monitoring event cannot be setup and should not be used in this version of OProfile . (BZ#1463290) This update adds support for the IBM POWER9 performance monitoring hardware events to papi . It includes basic PAPI presets for events, such as instructions ( PAPI_TOT_INS ) or processor cycles ( PAPI_TOT_CYC ). (BZ#1463291) This version of libpfm includes support for the IBM POWER9 performance monitoring hardware events. (BZ#1463292) SystemTap includes backported compatibility fixes necessary for the kernel. Previously, the memcpy() function from the GNU C Library ( glibc ) used unaligned vector load and store instructions on 64-bit IBM POWER systems. Consequently, when memcpy() was used to access device memory on POWER9 systems, performance would suffer. The memcpy() function has been enhanced to use aligned memory access instructions, to provide better performance for applications regardless of the memory involved on POWER9, without affecting the performance on generations of the POWER architecture. (BZ#1498925) Security USBGuard is now available as a Technology Preview on IBM Power LE (POWER9) The USBGuard software framework provides system protection against intrusive USB devices by implementing basic whitelisting and blacklisting capabilities based on device attributes. USBGuard is now available as a Technology Preview on IBM Power LE (POWER9). Note that USB is not supported on IBM Z, and the USBGuard framework cannot be provided on those systems.

Commands:
8.5. Synchronous and Asynchronous Replication Replication mode can be synchronous or asynchronous depending on the problem being addressed. Synchronous replication blocks a thread or caller (for example on a put() operation) until the modifications are replicated across all nodes in the cluster. By waiting for acknowledgments, synchronous replication ensures that all replications are successfully applied before the operation is concluded. Asynchronous replication operates significantly faster than synchronous replication because it does not need to wait for responses from nodes. Asynchronous replication performs the replication in the background and the call returns immediately. Errors that occur during asynchronous replication are written to a log. As a result, a transaction can be successfully completed despite the fact that replication of the transaction may not have succeeded on all the cache instances in the cluster. 23149%2C+Administration+and+Configuration+Guide-6.628-06-2017+13%3A51%3A02JBoss+Data+Grid+6Documentation6.6.1 Report a bug 8.5.1. Troubleshooting Asynchronous Replication Behavior In some instances, a cache configured for asynchronous replication or distribution may wait for responses, which is synchronous behavior. This occurs because caches behave synchronously when both state transfers and asynchronous modes are configured. This synchronous behavior is a prerequisite for state transfer to operate as expected. Use one of the following to remedy this problem: Disable state transfer and use a ClusteredCacheLoader to lazily look up remote state as and when needed. Enable state transfer and REPL_SYNC . Use the Asynchronous API (for example, the cache.putAsync(k, v) ) to activate 'fire-and-forget' capabilities. Enable state transfer and REPL_ASYNC . All RPCs end up becoming synchronous, but client threads will not be held up if a replication queue is enabled (which is recommended for asynchronous mode). 23149%2C+Administration+and+Configuration+Guide-6.628-06-2017+13%3A51%3A02JBoss+Data+Grid+6Documentation6.6.1 Report a bug

Commands:
4.11. Checking Integrity with AIDE Advanced Intrusion Detection Environment ( AIDE ) is a utility that creates a database of files on the system, and then uses that database to ensure file integrity and detect system intrusions. 4.11.1. Installing AIDE To install the aide package, enter the following command as root : To generate an initial database, enter the following command as root : Note In the default configuration, the aide --init command checks just a set of directories and files defined in the /etc/aide.conf file. To include additional directories or files in the AIDE database, and to change their watched parameters, edit /etc/aide.conf accordingly. To start using the database, remove the .new substring from the initial database file name: To change the location of the AIDE database, edit the /etc/aide.conf file and modify the DBDIR value. For additional security, store the database, configuration, and the /usr/sbin/aide binary file in a secure location such as a read-only media. Important To avoid SELinux denials after the AIDE database location change, update your SELinux policy accordingly. See the SELinux User's and Administrator's Guide for more information. 4.11.2. Performing Integrity Checks To initiate a manual check, enter the following command as root : At a minimum, AIDE should be configured to run a weekly scan. At most, AIDE should be run daily. For example, to schedule a daily execution of AIDE at 4:05 am using cron (see the Automating System Tasks chapter in the System Administrator's Guide), add the following line to /etc/crontab : 4.11.3. Updating an AIDE Database After the changes of your system such as package updates or configuration files adjustments are verified, update your baseline AIDE database: The aide --update command creates the /var/lib/aide/aide.db.new.gz database file. To start using it for integrity checks, remove the .new substring from the file name. 4.11.4. Additional Resources For additional information on AIDE, see the following documentation: aide(1) man page aide.conf(5) man page Guide to the Secure Configuration of Red Hat Enterprise Linux 7 (OpenSCAP Security Guide): Verify Integrity with AIDE

Commands:
~]# yum install aide
~]# aide --init AIDE, version 0.15.1 ### AIDE database at /var/lib/aide/aide.db.new.gz initialized.
~]# mv /var/lib/aide/aide.db.new.gz /var/lib/aide/aide.db.gz
~]# aide --check AIDE 0.15.1 found differences between database and filesystem!! Start timestamp: 2017-03-30 14:12:56 Summary: Total number of files: 147173 Added files: 1 Removed files: 0 Changed files: 2
05 4 * * * root /usr/sbin/aide --check
~]# aide --update
7.281. xorg-x11-drv-intel 7.281.1. RHBA-2013:0303 - xorg-x11-drv-intel bug fix and enhancement update Updated xorg-x11-drv-intel packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The xorg-x11-drv-intel packages contain an Intel integrated graphics video driver for the X.Org implementation of the X Window System. Note The xorg-x11-drv-intel packages have been upgraded to upstream version 2.20.2, which provides a number of bug fixes and enhancements over the version. (BZ#835236) All users of xorg-x11-drv-intel are advised to upgrade to these updated packages, which fix these bugs and add this enhancement.

Commands:
Chapter 5. Compatibility Level Versions Each host connected to Red Hat Virtualization Manager contains a version of VDSM . VDSM is the agent within the virtualization infrastructure that runs on a hypervisor or host and provides local management for virtual machines, networks and storage. Red Hat Virtualization Manager controls hypervisors and hosts using current or earlier versions of VDSM. The Manager migrates virtual machines from host to host within a cluster. This means the Manager excludes certain features from a current version of VDSM until all hosts within a cluster have the same VDSM version, or more recent, installed. The API represents this concept as a compatibility level for each host, corresponding to the version of VDSM installed. A version element contains major and minor attributes, which describe the compatibility level. When an administrator upgrades all hosts within a cluster to a certain level, the version level appears under a supported_versions element. This indicates the cluster's version is now updatable to that level. Once the administrator updates all clusters within a data center to a given level, the data center is updatable to that level. 5.1. Upgrading Compatibility Levels Example 5.1. Upgrading compatibility levels The API reports the following compatibility levels for Red Hat Enterprise Virtualization Manager 3.4 instance: All hosts within a cluster are updated to VDSM 3.5 and the API reports: The cluster is now updatable to 3.5 . When the cluster is updated, the API reports: The API user updates the data center to 3.5 . Once upgraded, the API exposes features available in Red Hat Enterprise Virtualization 3.5 for this data center.

Commands:
<host ...> <version major="4" minor="14" build="11" revision="0" full_version="vdsm-4.14.11-5.el6ev"/> </host> <cluster ...> <version major="3" minor="4"/> </cluster> <data_center ...> <version major="3" minor="4"/> </supported_versions> </data_center>
<host ...> <version major="4" minor="16" build="7" revision="4" full_version="vdsm-4.16.7.4-1.el6ev"/> </host> <cluster ...> <version major="3" minor="4"/> <supported_versions> <version major="3" minor="5"/> </supported_versions> </cluster> <data_center ...> <version major="3" minor="4"/> <supported_versions/> </data_center>
<cluster ...> <version major="3" minor="5"/> <supported_versions/> </cluster> <data_center ...> <version major="3" minor="4"/> <supported_versions> <version major="3" minor="5"/> </supported_versions> </data_center>
5.9. Configuring Fencing Levels Pacemaker supports fencing nodes with multiple devices through a feature called fencing topologies. To implement topologies, create the individual devices as you normally would and then define one or more fencing levels in the fencing topology section in the configuration. Each level is attempted in ascending numeric order, starting at 1. If a device fails, processing terminates for the current level. No further devices in that level are exercised and the level is attempted instead. If all devices are successfully fenced, then that level has succeeded and no other levels are tried. The operation is finished when a level has passed (success), or all levels have been attempted (failed). Use the following command to add a fencing level to a node. The devices are given as a comma-separated list of stonith ids, which are attempted for the node at that level. The following command lists all of the fencing levels that are currently configured. In the following example, there are two fence devices configured for node rh7-2 : an ilo fence device called my_ilo and an apc fence device called my_apc . These commands sets up fence levels so that if the device my_ilo fails and is unable to fence the node, then Pacemaker will attempt to use the device my_apc . This example also shows the output of the pcs stonith level command after the levels are configured. The following command removes the fence level for the specified node and devices. If no nodes or devices are specified then the fence level you specify is removed from all nodes. The following command clears the fence levels on the specified node or stonith id. If you do not specify a node or stonith id, all fence levels are cleared. If you specify more than one stonith id, they must be separated by a comma and no spaces, as in the following example. The following command verifies that all fence devices and nodes specified in fence levels exist. As of Red Hat Enterprise Linux 7.4, you can specify nodes in fencing topology by a regular expression applied on a node name and by a node attribute and its value. For example, the following commands configure nodes node1 , node2 , and ` node3 to use fence devices apc1 and ` apc2 , and nodes ` node4 , node5 , and ` node6 to use fence devices apc3 and ` apc4 . The following commands yield the same results by using node attribute matching.

Commands:
pcs stonith level add level node devices
pcs stonith level
pcs stonith level add 1 rh7-2 my_ilo pcs stonith level add 2 rh7-2 my_apc pcs stonith level Node: rh7-2 Level 1 - my_ilo Level 2 - my_apc
pcs stonith level remove level [ node_id ] [ stonith_id ] ... [ stonith_id ]
pcs stonith level clear [ node | stonith_id (s)]
pcs stonith level clear dev_a,dev_b
pcs stonith level verify
pcs stonith level add 1 "regexp%node[1-3]" apc1,apc2 pcs stonith level add 1 "regexp%node[4-6]" apc3,apc4
pcs node attribute node1 rack=1 pcs node attribute node2 rack=1 pcs node attribute node3 rack=1 pcs node attribute node4 rack=2 pcs node attribute node5 rack=2 pcs node attribute node6 rack=2 pcs stonith level add 1 attrib%rack=1 apc1,apc2 pcs stonith level add 1 attrib%rack=2 apc3,apc4
Appendix A. Using your subscription AMQ is provided through a software subscription. To manage your subscriptions, access your account at the Red Hat Customer Portal. A.1. Accessing your account Procedure Go to access.redhat.com . If you do not already have an account, create one. Log in to your account. A.2. Activating a subscription Procedure Go to access.redhat.com . Navigate to My Subscriptions . Navigate to Activate a subscription and enter your 16-digit activation number. A.3. Downloading release files To access .zip, .tar.gz, and other release files, use the customer portal to find the relevant files for download. If you are using RPM packages or the Red Hat Maven repository, this step is not required. Procedure Open a browser and log in to the Red Hat Customer Portal Product Downloads page at access.redhat.com/downloads . Locate the Red Hat AMQ entries in the INTEGRATION AND AUTOMATION category. Select the desired AMQ product. The Software Downloads page opens. Click the Download link for your component. A.4. Registering your system for packages To install RPM packages for this product on Red Hat Enterprise Linux, your system must be registered. If you are using downloaded release files, this step is not required. Procedure Go to access.redhat.com . Navigate to Registration Assistant . Select your OS version and continue to the page. Use the listed command in your system terminal to complete the registration. For more information about registering your system, see one of the following resources: Red Hat Enterprise Linux 6 - Registering the system and managing subscriptions Red Hat Enterprise Linux 7 - Registering the system and managing subscriptions Red Hat Enterprise Linux 8 - Registering the system and managing subscriptions

Commands:
4.2. Deployment In Red Hat Enterprise Linux 6.1, multilib Python packages and packages dependent on them have been removed. This was because installing Python packages for multiple architectures on one system can cause various problems. For more information, refer to https://access.redhat.com/site/solutions/68140 . Some HP Proliant servers may report incorrect CPU frequency values in /proc/cpuinfo or /sys/device/system/cpu/*/cpufreq. This is due to the firmware manipulating the CPU frequency without providing any notification to the operating system. To avoid this ensure that the "HP Power Regulator" option in the BIOS is set to "OS Control". An alternative available on more recent systems is to set "Collaborative Power Control" to "Enabled". Some packages in the Optional repositories on RHN have multilib file conflicts. Consequently, these packages cannot have both the primary architecture (e.g. x86_64) and secondary architecture (e.g. i686) copies of the package installed on the same machine simultaneously. To work around this, install only one copy of the conflicting package. When rebuilding the grub package on the x86_64 architecture, the glibc-static.i686 package must be used. Using the glibc-static.x86_64 package will not meet the build requirements. Parted in Red Hat Enterprise Linux 6 cannot handle Extended Address Volumes (EAV) Direct Access Storage Devices (DASD) that have greater than 65535 cylinders. Consequently, EAV DASD drives cannot be partitioned using parted, and installation on EAV DASD drives will fail. To work around this issue, complete the installation on a non EAV DASD drive, then add the EAV device after installation using the tools provided in s390-utils.

Commands:
Appendix A. Ceph subsystems default logging level values A table of the default logging level values for the various Ceph subsystems. Subsystem Log Level Memory Level asok 1 5 auth 1 5 buffer 0 0 client 0 5 context 0 5 crush 1 5 default 0 5 filer 0 5 bluestore 1 5 finisher 1 5 heartbeatmap 1 5 javaclient 1 5 journaler 0 5 journal 1 5 lockdep 0 5 mds balancer 1 5 mds locker 1 5 mds log expire 1 5 mds log 1 5 mds migrator 1 5 mds 1 5 monc 0 5 mon 1 5 ms 0 5 objclass 0 5 objectcacher 0 5 objecter 0 0 optracker 0 5 osd 0 5 paxos 0 5 perfcounter 1 5 rados 0 5 rbd 0 5 rgw 1 5 throttle 1 5 timer 0 5 tp 0 5

Commands:
A.12. VDSM Hook Return Codes Hook scripts must return one of the return codes shown in Table A.3, "Hook Return Codes" . The return code will determine whether further hook scripts are processed by VDSM. Table A.3. Hook Return Codes Code Description 0 The hook script ended successfully 1 The hook script failed, other hooks should be processed 2 The hook script failed, no further hooks should be processed >2 Reserved

Commands:
Chapter 3. Upgrading from Red Hat Hyperconverged Infrastructure for Virtualization 1.5 and 1.6 3.1. Upgrade workflow To upgrade to Red Hat Hyperconverged Infrastructure for Virtualization 1.8, the primary requirement is to upgrade to Red Hat Hyperconverged Infrastructure for Virtualization 1.7 with the latest version of Red Hat Virtualization 4.3. The upgrade process for RHHI for Virtualization versions 1.5, 1.6, and 1.7 to RHHI for Virtualization 1.8 is as follows: RHHI for Virtualization 1.5 (based on RHV 4.2) Perform the upgrade from 1.5 to 1.7 and then upgrade to RHHI for Virtualization 1.8. RHHI for Virtualization 1.6 (based on RHV 4.3) Perform the upgrade from 1.6 to 1.7 and then upgrade to RHHI for Virtualization 1.8. RHHI for Virtualization 1.7 (based on RHV 4.3.8 or later) Update the current set-up to latest Red Hat Virtualization 4.3, then upgrade to RHHI for Virtualization 1.8. 3.2. Upgrading to Red Hat Hyperconverged Infrastructure for Virtualization 1.7 Follow Upgrading to RHHI for Virtualization 1.7 guide to upgrade from RHHI for Virtualization 1.5, 1.6 to 1.7 and to upgrade RHHI for Virtualization 1.7 to the latest Red Hat Virtualization 4.3.z version.

Commands: