mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 8. Setting up HAProxy nodes To provide load balancing capabilities across the CDS nodes, you must first set up the HAProxy nodes. The following process explains how to: Register the HAProxy node Enable the required repositories on the HAProxy node Important The following procedures assume that your CCSP account uses Simple Content Access (SCA). If that is not the case, refer to Appendix A, Using Entitlement Mode instead. 8.1. Registering the HAProxy node The following instructions explain how to register your HAProxy nodes. Note On the HAProxy node you do not need to use the --type=rhui flag that was required on the RHUA node. Prerequisites Latest version of RHEL 8 is installed. Ensure you have root access to the HAProxy nodes. Procedure On the HAProxy node, enter the following command: Type your CCSP user name and password when prompted. Optional: If your system is already registered, you can override the subscription using the --force option. The new system will be available on the Red Hat Customer Portal, and the new HAProxy instance will not have any subscriptions attached to it. Verification Navigate to the Red Hat Hybrid Cloud Console . Verify that your system is available by locating it within the inventory. 8.2. Enabling the required repositories on the HAProxy node To install RHUI on your system, you must first enable certain repositories on your nodes which contain the required packages. Prerequisites Ensure you have root access to the HAProxy node. Procedure The necessary repositories are automatically enabled on all your HAProxy nodes. Verification List the enabled repositories and verify whether the relevant repositories appear on the list.

Commands:
subscription-manager register
subscription-manager register --force
yum repolist enabled Updating Subscription Management repositories. repo id repo name rhel-8-for-x86_64-appstream-rpms Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs) rhel-8-for-x86_64-baseos-rpms Red Hat Enterprise Linux 8 for x86_64 - BaseOS (RPMs)
39.2.2. replacement_timeout replacement_timeout controls how long the iSCSI layer should wait for a timed-out path/session to reestablish itself before failing any commands on it. The default replacement_timeout value is 120 seconds. To adjust replacement_timeout , open /etc/iscsi/iscsid.conf and edit the following line: The 1 queue_if_no_path option in /etc/multipath.conf sets iSCSI timers to immediately defer commands to the multipath layer (refer to Section 39.2, "iSCSI Settings With dm-multipath " ). This setting prevents I/O errors from propagating to the application; because of this, you can set replacement_timeout to 15-20 seconds. By configuring a lower replacement_timeout , I/O is quickly sent to a new path and executed (in the event of a NOP-Out timeout) while the iSCSI layer attempts to re-establish the failed path/session. If all paths time out, then the multipath and device mapper layer will internally queue I/O based on the settings in /etc/multipath.conf instead of /etc/iscsi/iscsid.conf . Important Whether your considerations are failover speed or security, the recommended value for replacement_timeout will depend on other factors. These factors include the network, target, and system workload. As such, it is recommended that you thoroughly test any new configurations to replacements_timeout before applying it to a mission-critical system.

Commands:
node.session.timeo.replacement_timeout = [replacement_timeout]
22.5. JBoss Operations Network for Remote Client-Server Mode In Red Hat JBoss Data Grid's Remote Client-Server mode, the JBoss Operations Network plug-in is used to initiate and perform installation and configuration operations. monitor resources and their metrics. In Remote Client-Server mode, the JBoss Operations Network plug-in uses JBoss Enterprise Application Platform's management protocol to obtain metrics and perform operations on the JBoss Data Grid server. Report a bug 22.5.1. Installing the JBoss Operations Network Plug-in (Remote Client-Server Mode) The following procedure details how to install the JBoss Operations Network plug-ins for Red Hat JBoss Data Grid's Remote Client-Server mode. Install the plug-ins Copy the JBoss Data Grid server rhq plug-in to USDJON_SERVER_HOME /plugins . Copy the JBoss Enterprise Application Platform plug-in to USDJON_SERVER_HOME /plugins . The server will automatically discover plug-ins here and deploy them. The plug-ins will be removed from the plug-ins directory after successful deployment. Obtain plug-ins Obtain all available plug-ins from the JBoss Operations Network server. To do this, type the following into the agent's console: List installed plug-ins Ensure the JBoss Enterprise Application Platform plug-in and the JBoss Data Grid server rhq plug-in are installed correctly using the following: JBoss Operation Network can now discover running JBoss Data Grid servers. Report a bug

Commands:
plugins update
plugins info
Chapter 61. Networking Verification of signatures using the MD5 hash algorithm is disabled in Red Hat Enterprise Linux 7 It is impossible to connect to any Wi-Fi Protected Access (WPA) Enterprise Access Point (AP) that requires MD5 signed certificates. To work around this problem, copy the wpa_supplicant.service file from the /usr/lib/systemd/system/ directory to the /etc/systemd/system/ directory and add the following line to the Service section of the file: Then run the systemctl daemon-reload command as root to reload the service file. Important: Note that MD5 certificates are highly insecure and Red Hat does not recommend using them. (BZ#1062656) freeradius might fail when upgrading from RHEL 7.3 A new configuration property, correct_escapes , in the /etc/raddb/radiusd.conf file was introduced in the freeradius version distributed since RHEL 7.4. When an administrator sets correct_escapes to true , the new regular expression syntax for backslash escaping is expected. If correct_escapes is set to false , the old syntax is expected where backslashes are also escaped. For backward compatibility reasons, false is the default value. When upgrading, configuration files in the /etc/raddb/ directory are overwritten unless modified by the administrator, so the value of correct_escapes might not always correspond to which type of syntax is used in all the configuration files. As a consequence, authentication with freeradius might fail. To prevent the problem from occurring, after upgrading from freeradius version 3.0.4 (distributed with RHEL 7.3) and earlier, make sure all configuration files in the /etc/raddb/ directory use the new escaping syntax (no double backslash characters can be found) and that the value of correct_escapes in /etc/raddb/radiusd.conf is set to true . For more information and examples, see the solution at https://access.redhat.com/solutions/3241961 . (BZ#1489758)

Commands:
Environment=OPENSSL_ENABLE_MD5_VERIFY=1
2.6. Storage and File System Improvements Red Hat Enterprise Linux 6 also features several improvements to storage and file system management. Two of the most notable advances in this version are ext4 and XFS support. For more comprehensive coverage of performance improvements relating to storage and file systems, refer to Chapter 7, File Systems . Ext4 Ext4 is the default file system for Red Hat Enterprise Linux 6. It is the fourth generation version of the EXT file system family, supporting a theoretical maximum file system size of 1 exabyte, and single file maximum size of 16TB. Red Hat Enterprise Linux 6 supports a maximum file system size of 16TB, and a single file maximum size of 16TB. Other than a much larger storage capacity, ext4 also includes several new features, such as: Extent-based metadata Delayed allocation Journal check-summing For more information about the ext4 file system, refer to Section 7.3.1, "The Ext4 File System" . XFS XFS is a robust and mature 64-bit journaling file system that supports very large files and file systems on a single host. This file system was originally developed by SGI, and has a long history of running on extremely large servers and storage arrays. XFS features include: Delayed allocation Dynamically-allocated inodes B-tree indexing for scalability of free space management Online defragmentation and file system growing Sophisticated metadata read-ahead algorithms While XFS scales to exabytes, the maximum XFS file system size supported by Red Hat is 100TB. For more information about XFS, refer to Section 7.3.2, "The XFS File System" . Large Boot Drives Traditional BIOS supports a maximum disk size of 2.2TB. Red Hat Enterprise Linux 6 systems using BIOS can support disks larger than 2.2TB by using a new disk structure called Global Partition Table (GPT). GPT can only be used for data disks; it cannot be used for boot drives with BIOS; therefore, boot drives can only be a maximum of 2.2TB in size. The BIOS was originally created for the IBM PC; while BIOS has evolved considerably to adapt to modern hardware, Unified Extensible Firmware Interface (UEFI) is designed to support new and emerging hardware. Red Hat Enterprise Linux 6 also supports UEFI, which can be used to replace BIOS (still supported). Systems with UEFI running Red Hat Enterprise Linux 6 allow the use of GPT and 2.2TB (and larger) partitions for both boot partition and data partition. Important Red Hat Enterprise Linux 6 does not support UEFI for 32-bit x86 systems. Important Note that the boot configurations of UEFI and BIOS differ significantly from each other. Therefore, the installed system must boot using the same firmware that was used during installation. You cannot install the operating system on a system that uses BIOS and then boot this installation on a system that uses UEFI. Red Hat Enterprise Linux 6 supports version 2.2 of the UEFI specification. Hardware that supports version 2.3 of the UEFI specification or later should boot and operate with Red Hat Enterprise Linux 6, but the additional functionality defined by these later specifications will not be available.

Commands:
1.4. Before Setting Up GFS Before you install and set up GFS, note the following key characteristics of your GFS file systems: Number of file systems Determine how many GFS file systems to create initially. (More file systems can be added later.) File-system name Determine a unique name for each file system. Each file-system name is required in the form of a parameter variable. For example, this book uses file-system names gfs1 and gfs2 in some example procedures. Journals Determine the number of journals for your GFS file systems. One journal is required for each node that mounts a GFS file system. Make sure to account for additional journals needed for future expansion. GFS nodes Determine which nodes in the Red Hat Cluster Suite will mount the GFS file systems. GNBD server nodes If you are using GNBD, determine how many GNBD server nodes are needed. Note the hostname and IP address of each GNBD server node for setting up GNBD clients later. For information on using GNBD with GFS, see the Using GNBD with Global File System document. Storage devices and partitions Determine the storage devices and partitions to be used for creating logical volumes (via CLVM) in the file systems.

Commands:
18.12.10.6. IPv6 Protocol ID: ipv6 Rules of this type should either go into the root or ipv6 chain. Table 18.8. IPv6 protocol types Attribute Name Datatype Definition srcmacaddr MAC_ADDR MAC address of sender srcmacmask MAC_MASK Mask applied to MAC address of sender dstmacaddr MAC_ADDR MAC address of destination dstmacmask MAC_MASK Mask applied to MAC address of destination srcipaddr IP_ADDR Source IP address srcipmask IP_MASK Mask applied to source IP address dstipaddr IP_ADDR Destination IP address dstipmask IP_MASK Mask applied to destination IP address protocol UINT8, STRING Layer 4 protocol identifier. Valid strings for protocol are: tcp, udp, udplite, esp, ah, icmpv6, sctp scrportstart UNIT16 Start of range of valid source ports; requires protocol srcportend UINT16 End of range of valid source ports; requires protocol dstportstart UNIT16 Start of range of valid destination ports; requires protocol dstportend UNIT16 End of range of valid destination ports; requires protocol comment STRING text string up to 256 characters

Commands:
Chapter 8. Virtual Machine Snapshots 8.1. Snapshots Snapshots are a storage function that allows an administrator to create a restore point of a virtual machine's operating system, applications, and data at a certain point in time. Snapshots save the data currently present in a virtual machine hard disk image as a COW volume and allow for a recovery to the data as it existed at the time the snapshot was taken. A snapshot causes a new COW layer to be created over the current layer. All write actions performed after a snapshot is taken are written to the new COW layer. It is important to understand that a virtual machine hard disk image is a chain of one or more volumes. From the perspective of a virtual machine, these volumes appear as a single disk image. A virtual machine is oblivious to the fact that its disk is comprised of multiple volumes. The term COW volume and COW layer are used interchangeably, however, layer more clearly recognizes the temporal nature of snapshots. Each snapshot is created to allow an administrator to discard unsatisfactory changes made to data after the snapshot is taken. Snapshots provide similar functionality to the Undo function present in many word processors. Note Snapshots of virtual machine hard disks marked shareable and those that are based on Direct LUN connections are not supported, live or otherwise. The three primary snapshot operations are: Creation, which involves the first snapshot created for a virtual machine. Previews, which involves previewing a snapshot to determine whether or not to restore the system data to the point in time that the snapshot was taken. Deletion, which involves deleting a restoration point that is no longer required. For task-based information about snapshot operations, see Snapshots in the Red Hat Virtualization Virtual Machine Management Guide .

Commands:
3.7. Creating an NFS Storage Domain This Ruby example adds an NFS storage domain. # Get the reference to the root of the services tree: system_service = connection.system_service # Get the reference to the storage domains service: sds_service = connection.system_service.storage_domains_service # Create a new NFS data storage domain: sd = sds_service.add( OvirtSDK4::StorageDomain.new( name: 'mydata', description: 'My data', type: OvirtSDK4::StorageDomainType::DATA, host: { name: 'myhost' }, storage: { type: OvirtSDK4::StorageType::NFS, address: 'server0.example.com', path: '/nfs/ovirt/40/mydata' } ) ) # Wait until the storage domain is unattached: sd_service = sds_service.storage_domain_service(sd.id) loop do sleep(5) sd = sd_service.get break if sd.status == OvirtSDK4::StorageDomainStatus::UNATTACHED end For more information, see http://www.rubydoc.info/gems/ovirt-engine-sdk/OvirtSDK4/StorageDomainsService:add .

Commands:
Get the reference to the root of the services tree: system_service = connection.system_service Get the reference to the storage domains service: sds_service = connection.system_service.storage_domains_service Create a new NFS data storage domain: sd = sds_service.add( OvirtSDK4::StorageDomain.new( name: 'mydata', description: 'My data', type: OvirtSDK4::StorageDomainType::DATA, host: { name: 'myhost' }, storage: { type: OvirtSDK4::StorageType::NFS, address: 'server0.example.com', path: '/nfs/ovirt/40/mydata' } ) ) Wait until the storage domain is unattached: sd_service = sds_service.storage_domain_service(sd.id) loop do sleep(5) sd = sd_service.get break if sd.status == OvirtSDK4::StorageDomainStatus::UNATTACHED end
4.71. ghostscript 4.71.1. RHSA-2012:0095 - Moderate: ghostscript security update Updated ghostscript packages that fix multiple security issues are now available for Red Hat Enterprise Linux 5 and 6. The Red Hat Security Response Team has rated this update as having moderate security impact. Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) associated with each description below. Ghostscript is a set of software that provides a PostScript interpreter, a set of C procedures (the Ghostscript library, which implements the graphics capabilities in the PostScript language) and an interpreter for Portable Document Format (PDF) files. Security Fixes CVE-2009-3743 An integer overflow flaw was found in Ghostscript's TrueType bytecode interpreter. An attacker could create a specially-crafted PostScript or PDF file that, when interpreted, could cause Ghostscript to crash or, potentially, execute arbitrary code. CVE-2010-2055 It was found that Ghostscript always tried to read Ghostscript system initialization files from the current working directory before checking other directories, even if a search path that did not contain the current working directory was specified with the "-I" option, or the "-P-" option was used (to prevent the current working directory being searched first). If a user ran Ghostscript in an attacker-controlled directory containing a system initialization file, it could cause Ghostscript to execute arbitrary PostScript code. CVE-2010-4820 Ghostscript included the current working directory in its library search path by default. If a user ran Ghostscript without the "-P-" option in an attacker-controlled directory containing a specially-crafted PostScript library file, it could cause Ghostscript to execute arbitrary PostScript code. With this update, Ghostscript no longer searches the current working directory for library files by default. Note The fix for CVE-2010-4820 could possibly break existing configurations. To use the , vulnerable behavior, run Ghostscript with the "-P" option (to always search the current working directory first). CVE-2010-4054 A flaw was found in the way Ghostscript interpreted PostScript Type 1 and PostScript Type 2 font files. An attacker could create a specially-crafted PostScript Type 1 or PostScript Type 2 font file that, when interpreted, could cause Ghostscript to crash or, potentially, execute arbitrary code. Users of Ghostscript are advised to upgrade to these updated packages, which contain backported patches to correct these issues.

Commands:
Chapter 1. Go Toolset Go Toolset is a Red Hat offering for developers on Red Hat Enterprise Linux (RHEL). It provides the Go programming language tools and libraries. Note that Go is alternatively known as golang. Go Toolset is available as a module for Red Hat Enterprise Linux 8. Go Toolset is available as packages for Red Hat Enterprise Linux 9. 1.1. Go Toolset components The following components are available as a part of Go Toolset: Name Version Description golang RHEL 8 - 1.22, RHEL 9 - 1.22 A Go compiler. delve RHEL 8 - 1.22, RHEL 9 - 1.22 A Go debugger. 1.2. Go Toolset compatibility Go Toolset is available for Red Hat Enterprise Linux 8 and Red Hat Enterprise Linux 9 on the following architectures: AMD and Intel 64-bit 64-bit ARM IBM Power Systems, Little Endian 64-bit IBM Z 1.3. Installing Go Toolset Complete the following steps to install Go Toolset, including all dependent packages. Prerequisites All available Red Hat Enterprise Linux updates are installed. Procedure On Red Hat Enterprise Linux 8, install the go-toolset module by running: On Red Hat Enterprise Linux 9, install the go-toolset package by running: 1.4. Installing Go documentation You can install documentation for the Go programming language on your local system. Prerequisites Go Toolset is installed. For more information, see Installing Go Toolset . Procedure To install the golang-docs package, run the following command: On Red Hat Enterprise Linux 8: You can find the documentation under the following path: /usr/lib/golang/doc/go_spec.html . On Red Hat Enterprise Linux 9: You can find the documentation under the following path: /usr/lib/golang/doc/go_spec.html . 1.5. Additional resources For more information on the Go programming language, tools, and libraries, see the official Go documentation .

Commands:
yum module install go-toolset
dnf install go-toolset
yum install golang-docs
dnf install golang-docs
28.2. Configuring Persistent Memory for Use as a Block Device (Legacy Mode) To use persistent memory as a fast block device, set the namespace to sector mode. In the example, namespace1.0 is reconfigured to sector mode. Note that the block device name changed from pmem1 to pmem1s . This device can be used in the same way as any other block device on the system. For example, the device can be partitioned, you can create a file system on the device, the device can be configured as part of a software RAID set, and the device can be the cache device for dm-cache .

Commands:
ndctl create-namespace --force --reconfig= namespace1.0 --mode=sector { "dev":" namespace1.0 ", "mode":"sector", "size": 17162027008 , "uuid":" 029caa76-7be3-4439-8890-9c2e374bcc76 ", "sector_size":4096, "blockdev":" pmem1s " }
4.48. dnsmasq 4.48.1. RHBA-2011:1746 - dnsmasq bug fix update An updated dnsmasq package that addresses two bugs is now available for Red Hat Enterprise Linux 6. Dnsmasq is a lightweight and easy-to-configure DNS forwarder and DHCP server. Bug Fixes BZ# 584009 Three changes were made to /etc/init.d/dnsmasq, the dnsmasq startup script: If dnsmasq was started or restarted by a non-privileged user, the startup script previously failed silently. With this update, the dnsmasq startup script now exits with a status code of 4 (user had insufficient privilege) and returns a "User has insufficient privilege" error to STD OUT when started or restarted by a non-privileged user. A "force-reload" option was added: The "service force-reload dnsmasq" command now forces dnsmasq to reload. Previously, it did nothing. If /etc/init.d/dnsmasq passed an invalid argument, previously the startup script exited with a status code of 1 (generic or unspecified error). With this update, the startup script now exits correctly, returning a status code of 2 (invalid or excess argument) in such a circumstance. BZ# 704073 If the virtual bridge interface (virbr0) was up and dnsmasq was started by default, dnsmasq could, in some circumstances, write a "DHCP packet received on eth(x) which has no address" message to /var/log/messages. Note: this message was not in error. The message was written if an actual interface (eg eth1) was up; did not have a configured IP address (eg was slaved to a logical bonded interface); and was in the same LAN as another host which generated a DHCP request. The message had little-to-no utility, however: it presented a warning where none was needed. With this update, this message is no longer written to /var/log/messages in these, and equivalent, circumstances. All dnsmasq users should install this update which makes these changes.

Commands:
5.58. efibootmgr 5.58.1. RHBA-2012:0893 - efibootmgr bug fix update An updated efibootmgr package that fixes one bug is now available for Red Hat Enterprise Linux 6. The efibootmgr utility is responsible for the boot loader installation on Unified Extensible Firmware Interface (UEFI) systems. Bug Fix BZ# 715216 In a Coverity Scan analysis, an allocation, which was not checked for errors, was discovered. With this update, the allocation is now checked for errors, thus the bug is fixed. All users of efibootmgr are advised to upgrade to this updated package, which fixes this bug.

Commands: