mtpti5iD/redhat-docs_dataset huggingface dataset:
2.6.2.2. Option Fields In addition to basic rules that allow and deny access, the Red Hat Enterprise Linux implementation of TCP Wrappers supports extensions to the access control language through option fields . By using option fields in hosts access rules, administrators can accomplish a variety of tasks such as altering log behavior, consolidating access control, and launching shell commands. 2.6.2.2.1. Logging Option fields let administrators easily change the log facility and priority level for a rule by using the severity directive. In the following example, connections to the SSH daemon from any host in the example.com domain are logged to the default authpriv syslog facility (because no facility value is specified) with a priority of emerg : It is also possible to specify a facility using the severity option. The following example logs any SSH connection attempts by hosts from the example.com domain to the local0 facility with a priority of alert : Note In practice, this example does not work until the syslog daemon ( syslogd ) is configured to log to the local0 facility. Refer to the syslog.conf man page for information about configuring custom log facilities.

Commands:
sshd : .example.com : severity emerg
sshd : .example.com : severity local0.alert
E.2.23. /proc/partitions This file contains partition block allocation information. A sampling of this file from a basic system looks similar to the following: Most of the information here is of little importance to the user, except for the following columns: major - The major number of the device with this partition. The major number in the /proc/partitions , ( 3 ), corresponds with the block device ide0 , in /proc/devices . minor - The minor number of the device with this partition. This serves to separate the partitions into different physical devices and relates to the number at the end of the name of the partition. #blocks - Lists the number of physical disk blocks contained in a particular partition. name - The name of the partition.

Commands:
major minor #blocks name 3 0 19531250 hda 3 1 104391 hda1 3 2 19422585 hda2 253 0 22708224 dm-0 253 1 524288 dm-1
Chapter 2. Installation This chapter guides you through the steps to install AMQ C++ in your environment. 2.1. Prerequisites You must have a subscription to access AMQ release files and repositories. To install packages on Red Hat Enterprise Linux, you must register your system . To build programs using AMQ C++ on Red Hat Enterprise Linux, you must install the gcc-c++ , cmake , and make packages. To build programs using AMQ C++ on Microsoft Windows, you must install Visual Studio. 2.2. Installing on Red Hat Enterprise Linux Procedure Use the subscription-manager command to subscribe to the required package repositories. If necessary, replace <variant> with the value for your variant of Red Hat Enterprise Linux (for example, server or workstation ). Red Hat Enterprise Linux 6 USD sudo subscription-manager repos --enable=amq-clients-2-for-rhel-6- <variant> -rpms Red Hat Enterprise Linux 7 USD sudo subscription-manager repos --enable=amq-clients-2-for-rhel-7- <variant> -rpms Red Hat Enterprise Linux 8 USD sudo subscription-manager repos --enable=amq-clients-2-for-rhel-8-x86_64-rpms Use the yum command to install the qpid-proton-cpp-devel and qpid-proton-cpp-docs packages. USD sudo yum install qpid-proton-cpp-devel qpid-proton-cpp-docs For more information about using packages, see Appendix B, Using Red Hat Enterprise Linux packages . 2.3. Installing on Microsoft Windows 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 Clients entry in the INTEGRATION AND AUTOMATION category. Click Red Hat AMQ Clients . The Software Downloads page opens. Download the AMQ Clients 2.8.0 C++ .zip file. Extract the file contents into a directory of your choosing by right-clicking on the zip file and selecting Extract All . When you extract the contents of the .zip file, a directory named amq-clients-2.8.0-cpp-win is created. This is the top-level directory of the installation and is referred to as <install-dir> throughout this document.

Commands:
sudo subscription-manager repos --enable=amq-clients-2-for-rhel-6- <variant> -rpms
sudo subscription-manager repos --enable=amq-clients-2-for-rhel-7- <variant> -rpms
sudo subscription-manager repos --enable=amq-clients-2-for-rhel-8-x86_64-rpms
sudo yum install qpid-proton-cpp-devel qpid-proton-cpp-docs
Preface The Red Hat Directory Server Deployment Guide provides a solid foundation on the concepts and configuration options for planning an effective directory service. The information provided here is intended for both designers and administrators. 1. Directory Server Overview Red Hat Directory Server provides the following key features: Multi-supplier replication - Provides a highly available directory service for both read and write operations. Multi-supplier replication can be combined with simple and cascading replication scenarios to provide a highly flexible and scalable replication environment. Chaining and referrals - Increases the power of the directory by storing a complete logical view of the directory on a single server while maintaining data on a large number of Directory Servers transparently for clients. Roles and classes of service - Provides a flexible mechanism for grouping and sharing attributes between entries dynamically. Efficient access control mechanisms - Provides support for macros that dramatically reduce the number of access control statements used in the directory and increase the scalability of access control evaluation. Resource-limits by bind DN - Grants the power to control the amount of server resources allocated to search operations based on the bind DN of the client. Multiple databases - Provides a simple way of breaking down the directory data to simplify the implementation of replication and chaining in the directory service. Password policy and account lockout - Defines a set of rules that govern how passwords and user accounts are managed in the Directory Server. TLS provides secure authentication and communication over the network, using the Mozilla Network Security Services (NSS) libraries for cryptography. The major components of Directory Server include the following: An LDAP server - The LDAP v3-compliant network daemon. A web console - A graphical management console that reduces the effort of setting up and maintaining the directory service. SNMP agent - Can monitor the Directory Server using the Simple Network Management Protocol (SNMP).

Commands:
Operator APIs OpenShift Container Platform 4.18 Reference guide for Operator APIs Red Hat OpenShift Documentation Team

Commands:
More specifically, given an OperatorPKI with <name>, the CNO will manage:
tls.crt: certificate file contents tls.key: key file contents
AWS: LoadBalancerService (with External scope) Azure: LoadBalancerService (with External scope) GCP: LoadBalancerService (with External scope) IBMCloud: LoadBalancerService (with External scope) AlibabaCloud: LoadBalancerService (with External scope) Libvirt: HostNetwork
kubernetes.io/os: linux node-role.kubernetes.io/worker: ''
kubernetes.io/os: linux node-role.kubernetes.io/master: ''
More specifically, given an OperatorPKI with <name>, the CNO will manage:
B.79. quagga B.79.1. RHSA-2010:0945 - Moderate: quagga security update Updated quagga packages that fix two security issues are now available for Red Hat Enterprise Linux 6. The Red Hat Security Response Team has rated this update as having moderate security impact. Common Vulnerability Scoring System (CVSS) base scores, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) associated with each description below. Quagga is a TCP/IP based routing software suite. The Quagga bgpd daemon implements the BGP (Border Gateway Protocol) routing protocol. CVE-2010-2948 A stack-based buffer overflow flaw was found in the way the Quagga bgpd daemon processed certain BGP Route Refresh (RR) messages. A configured BGP peer could send a specially-crafted BGP message, causing bgpd on a target system to crash or, possibly, execute arbitrary code with the privileges of the user running bgpd. Note Note that on Red Hat Enterprise Linux 6 it is not possible to exploit CVE-2010-2948 to run arbitrary code as the overflow is blocked by FORTIFY_SOURCE. CVE-2010-2949 A NULL pointer dereference flaw was found in the way the Quagga bgpd daemon parsed the paths of autonomous systems (AS). A configured BGP peer could crash bgpd on a target system via a specially-crafted BGP message. Users of quagga should upgrade to these updated packages, which contain backported patches to correct these issues. After installing the updated packages, the bgpd daemon must be restarted for the update to take effect.

Commands:
Chapter 2. RHOSP server group configuration for HA instances Create an instance server group before you create the RHOSP HA cluster node instances. Group the instances by affinity policy. If you configure multiple clusters, ensure that you have only one server group per cluster. The affinity policy you set for the server group can determine whether the cluster remains operational if the hypervisor fails. The default affinity policy is affinity . With this affinity policy, all of the cluster nodes could be created on the same RHOSP hypervisor. In this case, if the hypervisor fails the entire cluster fails. For this reason, set an affinity policy for the server group of anti-affinity or soft-anti-affinity . With an affinity policy of anti-affinity , the server group allows only one cluster node per Compute node. Attempting to create more cluster nodes than Compute nodes generates an error. While this configuration provides the highest protection against RHOSP hypervisor failures, it may require more resources to deploy large clusters than you have available. With an affinity policy of soft-anti-affinity , the server group distributes cluster nodes as evenly as possible across all Compute nodes. Although this provides less protection against hypervisor failures than a policy of anti-affinity , it provides a greater level of high availability than an affinity policy of affinity . Determining the server group affinity policy for your deployment requires balancing your cluster needs against the resources you have available by taking the following cluster components into account: The number of nodes in the cluster The number of RHOSP Compute nodes available The number of nodes required for cluster quorum to retain cluster operations For information about affinity and creating an instance server group, Compute scheduler filters and the Command Line Interface Reference .

Commands:
7.142. mdadm 7.142.1. RHBA-2013:0440 - mdadm bug fix update Updated mdadm packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The mdadm packages contain a utility for creating, managing, and monitoring Linux MD (multiple disk) devices. Note The mdadm packages have been upgraded to upstream version 3.2.5, which provides a number of bug fixes and enhancements over the version. (BZ#812358) Bug Fixes BZ#824815 While an Intel Matrix Storage Manager (IMSM) RAID volume was in the process of a reshape, an attempt to stop all arrays could cause an IMSM RAID array to be broken or corrupted. The underlying source code has been modified and mdadm works as expected in the described scenario. BZ#862565 This update clarifies a number of mdadm license ambiguities. BZ#878810 The IMSM optional ROM (OpROM) does not support RAID volumes across more than one controller. Previously, creating an IMSM RAID volume across more than one controller caused data loss. With this update, creating an IMSM RAID volume on multiple controllers is forbidden to prevent the data loss. BZ#880208 Previously, it was possible to create a second RAID1 volume with the size equal to 0. As a consequence, when resyncing the first RAID1 volume was finished, the system became unresponsive. This update applies a patch to correct this error and it is no longer possible to create a second RAID1 volume with the size equal to 0. BZ#880225 After turning off two disk drives of a RAID1 volume, using the "mdadm --detail" command caused mdadm to terminate unexpectedly with a segmentation fault. This update applies a patch that fixes this bug. Using the "mdadm --detail" command now returns valid information and mdadm no longer crashes in the described scenario. BZ#820643 This update fixes the map file location in mdadm(8) man page. Users of mdadm are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
Deploying OpenShift Data Foundation using IBM Z Red Hat OpenShift Data Foundation 4.18 Instructions on deploying Red Hat OpenShift Data Foundation to use local storage on IBM Z Red Hat Storage Documentation Team Abstract Read this document for instructions about how to install Red Hat OpenShift Data Foundation to use local storage on IBM Z. Note While this document refers only to IBM Z, all information in it also applies to IBM(R) LinuxONE.

Commands:
Chapter 11. Creating an OAuth application in GitHub You can authorize your registry to access a GitHub account and its repositories by registering it as a GitHub OAuth application. 11.1. Create new GitHub application Log into GitHub (Enterprise) Visit the Applications page under your organization's settings. Click Register New Application . The Register a new OAuth application configuration screen is displayed: Set Homepage URL: Enter the Quay Enterprise URL as the Homepage URL Note If using public GitHub, the Homepage URL entered must be accessible by your users. It can still be an internal URL. Set Authorization callback URL: Enter https://{USDRED_HAT_QUAY_URL}/oauth2/github/callback as the Authorization callback URL. Save your settings by clicking the Register application button. The new new application's summary is shown: Record the Client ID and Client Secret shown for the new application.

Commands:
2.4. Discard Unused Blocks Batch discard and online discard operations are features of mounted file systems that discard blocks not in use by the file system. They are useful for both solid-state drives and thinly-provisioned storage. Batch discard operations are run explicitly by the user with the fstrim command. This command discards all unused blocks in a file system that match the user's criteria. Online discard operations are specified at mount time, either with the -o discard option as part of a mount command or with the discard option in the /etc/fstab file. They run in real time without user intervention. Online discard operations only discard blocks that are transitioning from used to free. Both operation types are supported for use with ext4 file systems as of Red Hat Enterprise Linux 6.2 and later and with XFS file systems since Red Hat Enterprise Linux 6.4. Also, the block device underlying the file system must support physical discard operations. Physical discard operations are supported if the value stored in the /sys/block/ device /queue/discard_max_bytes file is not zero. If you are executing the fstrim command on: a device that does not support discard operations, or a logical device (LVM or MD) comprised of multiple devices, where any one of the device does not support discard operations the following message will be displayed: Note The mount command allows you to mount a device that does not support discard operations with the -o discard option. Red Hat recommends batch discard operations unless the system's workload is such that batch discard is not feasible, or online discard operations are necessary to maintain performance. For more information, see the fstrim (8) and mount (8) man pages.

Commands:
fstrim -v /mnt/ non_discard fstrim: /mnt/ non_discard : the discard operation is not supported
3.5.3. Disabling ACPI Completely in the grub.conf File The preferred method of disabling ACPI Soft-Off is with chkconfig management ( Section 3.5.2, "Disabling ACPI Soft-Off with chkconfig Management" ). If the preferred method is not effective for your cluster, you can disable ACPI Soft-Off with the BIOS power management ( Section 3.5.1, "Disabling ACPI Soft-Off with the BIOS" ). If neither of those methods is effective for your cluster, you can disable ACPI completely by appending acpi=off to the kernel boot command line in the grub.conf file. Important This method completely disables ACPI; some computers do not boot correctly if ACPI is completely disabled. Use this method only if the other methods are not effective for your cluster. You can disable ACPI completely by editing the grub.conf file of each cluster node as follows: Open /boot/grub/grub.conf with a text editor. Append acpi=off to the kernel boot command line in /boot/grub/grub.conf (see Example 3.2, "Kernel Boot Command Line with acpi=off Appended to It" ). Reboot the node. When the cluster is configured and running, verify that the node turns off immediately when fenced. Note You can fence the node with the fence_node command or Conga . Example 3.2. Kernel Boot Command Line with acpi=off Appended to It In this example, acpi=off has been appended to the kernel boot command line - the line starting with "kernel /vmlinuz-2.6.32-193.el6.x86_64.img".

Commands:
grub.conf generated by anaconda # Note that you do not have to rerun grub after making changes to this file NOTICE: You have a /boot partition. This means that all kernel and initrd paths are relative to /boot/, eg. root (hd0,0) kernel /vmlinuz-version ro root=/dev/mapper/vg_doc01-lv_root initrd /initrd-[generic-]version.img #boot=/dev/hda default=0 timeout=5 serial --unit=0 --speed=115200 terminal --timeout=5 serial console title Red Hat Enterprise Linux Server (2.6.32-193.el6.x86_64) root (hd0,0) kernel /vmlinuz-2.6.32-193.el6.x86_64 ro root=/dev/mapper/vg_doc01-lv_root console=ttyS0,115200n8 acpi=off initrd /initramfs-2.6.32-131.0.15.el6.x86_64.img
Appendix I. BlueStore configuration options The following are Ceph BlueStore configuration options that can be configured during deployment. Note This list is not complete. rocksdb_cache_size Description The size of the RocksDB cache in MB. Type 32-bit Integer Default 512 bluestore_throttle_bytes Description Maximum bytes available before the user throttles the input or output (I/O) submission. Type Size Default 64 MB bluestore_throttle_deferred_bytes Description Maximum bytes for deferred writes before the user throttles the I/O submission. Type Size Default 128 MB bluestore_throttle_cost_per_io Description Overhead added to the transaction cost in bytes for each I/O. Type Size Default 0 B bluestore_throttle_cost_per_io_hdd Description The default bluestore_throttle_cost_per_io value for HDDs. Type Unsigned integer Default 67 000 bluestore_throttle_cost_per_io_ssd Description The default bluestore_throttle_cost_per_io value for SSDs. Type Unsigned integer Default 4 000 bluestore_debug_enforce_settings Description hdd enforces settings intended for BlueStore above a rotational drive. ssd enforces settings intended for BlueStore above a solid drive Type default , hdd , ssd Default default Note After changing the bluestore_debug_enforce_settings option, restart the OSD.

Commands:
5.3.3. Edit the /var/yp/securenets File NIS listens to all networks, if the /var/yp/securenets file is blank or does not exist (as is the case after a default installation). One of the first things to do is to put netmask/network pairs in the file so that ypserv only responds to requests from the proper network. Below is a sample entry from a /var/yp/securenets file: Warning Never start an NIS server for the first time without creating the /var/yp/securenets file. This technique does not provide protection from an IP spoofing attack, but it does at least place limits on what networks the NIS server services.

Commands:
255.255.255.0 192.168.0.0
function::nsecs_to_string Name function::nsecs_to_string - Human readable string for given nanoseconds Synopsis Arguments nsecs Number of nanoseconds to translate. Description Returns a string representing the number of nanoseconds as a human readable string consisting of " XmY.ZZZZZZs " , where X is the number of minutes, Y is the number of seconds and ZZZZZZZZZ is the number of nanoseconds.

Commands:
nsecs_to_string:string(nsecs:long)
Chapter 1. Migration to Red Hat build of OpenJDK 11 The Migrating Red Hat build of OpenJDK 8 to Red Hat build of OpenJDK 11 guide provides information on how to upgrade your Java applications in Red Hat build of OpenJDK 8 to Red Hat build of OpenJDK 11. This guide describes changes in the Red Hat build of OpenJDK 11 release, including new features and deprecated or removed APIs, that might impact your migration from Red Hat build of OpenJDK 8. The OpenJDK project is known for its conservative approach to providing updates and for providing backward compatibility. However, to guarantee the evolution, security and stability of the project, the Red Hat build of OpenJDK project might sometimes introduce a few incompatibilities across major releases of Red Hat build of OpenJDK. These incompatibilities are relevant for the following scenarios: When you use APIs that are considered obsolete or unsecure When you access internals of the project that are considered implementation details and not public or supported API details Note Red Hat recommends that you migrate to the latest supported Red Hat build of OpenJDK distribution. 1.1. About Red Hat build of OpenJDK distributions OpenJDK is the free and open source reference implementation of the Java Platform, Standard Edition (Java SE). Red Hat build of OpenJDK distributions are based on the upstream OpenJDK 8u, OpenJDK 11u, OpenJDK 17u, and OpenJDK 21u projects. The Shenandoah Garbage Collector is included in all supported versions of Red Hat build of OpenJDK. All versions of Red Hat build of OpenJDK provide the following benefits: Multi-platform Red Hat build of OpenJDK is supported on RHEL and Microsoft Windows, so you can standardize applications on a single Java platform across desktop, data center, and hybrid cloud environments. Frequent releases Red Hat delivers quarterly updates of JRE and JDK for Red Hat build of OpenJDK 8, Red Hat build of OpenJDK 11, Red Hat build of OpenJDK 17, and Red Hat build of OpenJDK 21 distributions. These updates are available as archive, RPM, and Windows MSI-based installer files and container images. Long-term support Red Hat supports the recently released Red Hat build of OpenJDK 8, Red Hat build of OpenJDK 11, Red Hat build of OpenJDK 17, and Red Hat build of OpenJDK 21 distributions. Additional resources For more information about the support lifecycle, see OpenJDK Life Cycle and Support Policy .

Commands:
18.12.7. Element and Attribute Overview The root element required for all network filters is named <filter> with two possible attributes. The name attribute provides a unique name of the given filter. The chain attribute is optional but allows certain filters to be better organized for more efficient processing by the firewall subsystem of the underlying host physical machine. Currently the system only supports the following chains: root , ipv4 , ipv6 , arp and rarp .

Commands: