mtpti5iD/redhat-docs_dataset huggingface dataset:
8.8. NFS and rpcbind Note The following section only applies to NFSv3 implementations that require the rpcbind service for backward compatibility. For information on how to configure an NFSv4-only server, which does not need rpcbind , see Section 8.6.7, "Configuring an NFSv4-only Server" . The rpcbind [1] utility maps RPC services to the ports on which they listen. RPC processes notify rpcbind when they start, registering the ports they are listening on and the RPC program numbers they expect to serve. The client system then contacts rpcbind on the server with a particular RPC program number. The rpcbind service redirects the client to the proper port number so it can communicate with the requested service. Because RPC-based services rely on rpcbind to make all connections with incoming client requests, rpcbind must be available before any of these services start. The rpcbind service uses TCP wrappers for access control, and access control rules for rpcbind affect all RPC-based services. Alternatively, it is possible to specify access control rules for each of the NFS RPC daemons. The man pages for rpc.mountd and rpc.statd contain information regarding the precise syntax for these rules. 8.8.1. Troubleshooting NFS and rpcbind Because rpcbind [1] provides coordination between RPC services and the port numbers used to communicate with them, it is useful to view the status of current RPC services using rpcbind when troubleshooting. The rpcinfo command shows each RPC-based service with port numbers, an RPC program number, a version number, and an IP protocol type (TCP or UDP). To make sure the proper NFS RPC-based services are enabled for rpcbind , use the following command: Example 8.7. rpcinfo -p command output The following is sample output from this command: If one of the NFS services does not start up correctly, rpcbind will be unable to map RPC requests from clients for that service to the correct port. In many cases, if NFS is not present in rpcinfo output, restarting NFS causes the service to correctly register with rpcbind and begin working. For more information and a list of options on rpcinfo , see its man page.

Commands:
rpcinfo -p
program vers proto port service 100021 1 udp 32774 nlockmgr 100021 3 udp 32774 nlockmgr 100021 4 udp 32774 nlockmgr 100021 1 tcp 34437 nlockmgr 100021 3 tcp 34437 nlockmgr 100021 4 tcp 34437 nlockmgr 100011 1 udp 819 rquotad 100011 2 udp 819 rquotad 100011 1 tcp 822 rquotad 100011 2 tcp 822 rquotad 100003 2 udp 2049 nfs 100003 3 udp 2049 nfs 100003 2 tcp 2049 nfs 100003 3 tcp 2049 nfs 100005 1 udp 836 mountd 100005 1 tcp 839 mountd 100005 2 udp 836 mountd 100005 2 tcp 839 mountd 100005 3 udp 836 mountd 100005 3 tcp 839 mountd
Appendix B. Using Red Hat Enterprise Linux packages This section describes how to use software delivered as RPM packages for Red Hat Enterprise Linux. To ensure the RPM packages for this product are available, you must first register your system . B.1. Overview A component such as a library or server often has multiple packages associated with it. You do not have to install them all. You can install only the ones you need. The primary package typically has the simplest name, without additional qualifiers. This package provides all the required interfaces for using the component at program run time. Packages with names ending in -devel contain headers for C and C++ libraries. These are required at compile time to build programs that depend on this package. Packages with names ending in -docs contain documentation and example programs for the component. For more information about using RPM packages, see one of the following resources: Red Hat Enterprise Linux 7 - Installing and managing software Red Hat Enterprise Linux 8 - Managing software packages B.2. Searching for packages To search for packages, use the yum search command. The search results include package names, which you can use as the value for <package> in the other commands listed in this section. USD yum search <keyword>... B.3. Installing packages To install packages, use the yum install command. USD sudo yum install <package>... B.4. Querying package information To list the packages installed in your system, use the rpm -qa command. USD rpm -qa To get information about a particular package, use the rpm -qi command. USD rpm -qi <package> To list all the files associated with a package, use the rpm -ql command. USD rpm -ql <package>

Commands:
yum search <keyword>
sudo yum install <package>
rpm -qa
rpm -qi <package>
rpm -ql <package>
8.6. Configuring Redundant Ring Protocol As of Red Hat Enterprise Linux 6.4, the Red Hat High Availability Add-On supports the configuration of redundant ring protocol. When configuring a system to use redundant ring protocol, you must take the following considerations into account: Do not specify more than two rings. Each ring must use the same protocol; do not mix IPv4 and IPv6. If necessary, you can manually specify a multicast address for the second ring. If you specify a multicast address for the second ring, either the alternate multicast address or the alternate port must be different from the multicast address for the first ring. If you do not specify an alternate multicast address, the system will automatically use a different multicast address for the second ring. If you specify an alternate port, the port numbers of the first ring and the second ring must differ by at least two, since the system itself uses port and port-1 to perform operations. Do not use two different interfaces on the same subnet. In general, it is a good practice to configure redundant ring protocol on two different NICs and two different switches, in case one NIC or one switch fails. Do not use the ifdown command or the service network stop command to simulate network failure. This destroys the whole cluster and requires that you restart all of the nodes in the cluster to recover. Do not use NetworkManager , since it will execute the ifdown command if the cable is unplugged. When one node of a NIC fails, the entire ring is marked as failed. No manual intervention is required to recover a failed ring. To recover, you only need to fix the original reason for the failure, such as a failed NIC or switch. To specify a second network interface to use for redundant ring protocol, you add an altname component to the clusternode section of the cluster.conf configuration file. When specifying altname , you must specify a name attribute to indicate a second host name or IP address for the node. The following example specifies clusternet-node1-eth2 as the alternate name for cluster node clusternet-node1-eth1 . The altname section within the clusternode block is not position dependent. It can come before or after the fence section. Do not specify more than one altname component for a cluster node or the system will fail to start. Optionally, you can manually specify a multicast address, a port, and a TTL for the second ring by including an altmulticast component in the cman section of the cluster.conf configuration file. The altmulticast component accepts an addr , a port , and a ttl parameter. The following example shows the cman section of a cluster configuration file that sets a multicast address, port, and TTL for the second ring.

Commands:
<cluster name="mycluster" config_version="3" > <logging debug="on"/> <clusternodes> <clusternode name="clusternet-node1-eth1" votes="1" nodeid="1"> <fence> <method name="single"> <device name="xvm" domain="clusternet-node1"/> </method> </fence> <altname name="clusternet-node1-eth2"/> </clusternode>
<cman> <multicast addr="239.192.99.73" port="666" ttl="2"/> <altmulticast addr="239.192.99.88" port="888" ttl="3"/> </cman>
Chapter 16. Hardening block storage on Red Hat OpenStack Platform OpenStack Block Storage (cinder) is a service that provides software (services and libraries) to self-service manage persistent block-level storage devices. This creates on-demand access to Block Storage resources for use with Compute (nova) instances. This creates software-defined storage through abstraction by virtualizing pools of block storage to a variety of back-end storage devices which can be either software implementations or traditional hardware storage products. The primary functions of this is to manage the creation, attachment, and detachment of the block devices. The consumer requires no knowledge of the type of back-end storage equipment or where it is located. Compute instances store and retrieve block storage using industry-standard storage protocols such as iSCSI, ATA over Ethernet, or Fibre-Channel. These resources are managed and configured using OpenStack native standard HTTP RESTful API. 16.1. Set the max size for the body of a request If the maximum body size per request is not defined, the attacker can craft an arbitrary OSAPI request of large size, causing the service to crash and finally resulting in a Denial Of Service attack. Assigning t he maximum value ensures that any malicious oversized request gets blocked ensuring continued availability of the service. Review whether max_request_body_size under the [oslo_middleware] section in cinder.conf is set to 114688 . 16.2. Enable volume encryption Unencrypted volume data makes volume-hosting platforms especially high-value targets for attackers, as it allows the attacker to read the data for many different VMs. In addition, the physical storage medium could be stolen, remounted, and accessed from a different machine. Encrypting volume data and volume backups can help mitgate these risks and provides defense-in-depth to volume-hosting platforms. Block Storage (cinder) is able to encrypt volume data before it is written to disk, so consider enabling volume encryption, and using Barbican for private key storage. 16.3. Volume Wiping There are multiple ways to wipe a block storage device. The traditional approach is to set the lvm_type to thin, and then use the volume_clear parameter. Alternatively, if the volume encryption feature is used, then volume wiping is not necessary if the volume encryption key is deleted. Note Previously, lvm_type=default was used to signify a wipe. While this method still works, lvm_type=default is not recommended for setting secure delete. The volume_clear parameter can accept either zero or shred as arguments. zero will write a single pass of zeroes to the device. The shred operation will write three passes of predetermined bit patterns.

Commands:
Chapter 1. Start, stop, and restart automation controller Automation controller includes an administrator utility script, automation-controller-service . The script can start, stop, and restart all automation controller services running on the current single automation controller node. The script includes the message queue components and the database if it is an integrated installation. External databases must be explicitly managed by the administrator. You can find the services script in /usr/bin/automation-controller-service , which can be invoked with the following command: root@localhost:~USD automation-controller-service restart Note In clustered installs, the automation-controller-service restart does not include PostgreSQL as part of the services that are restarted. This is because it exists external to automation controller, and PostgreSQL does not always need to be restarted. Use systemctl restart automation-controller to restart services on clustered environments instead. You must also restart each cluster node for certain changes to persist as opposed to a single node for a localhost install. For more information on clustered environments, see the Clustering section. You can also invoke the services script using distribution-specific service management commands. Distribution packages often provide a similar script, sometimes as an init script, to manage services. For more information, see your distribution-specific service management system. Important When running automation controller in a container, do not use the automation-controller-service script. Restart the pod using the container environment instead.

Commands:
root@localhost:~USD automation-controller-service restart
8.109. ledmon 8.109.1. RHBA-2014:1614 - ledmon bug fix and enhancement update Updated ledmon packages that fix several bugs and add various enhancements are now available for Red Hat Enterprise Linux 6. The ledmon and ledctl utilities are user-space applications designed to control LEDs associated with each slot in an enclosure or a drive bay. There are two types of systems: 2-LED system (Activity LED, Status LED) and 3-LED system (Activity LED, Locate LED, Fail LED). Users must have root privileges to use this application. Note The ledmon packages have been upgraded to upstream version 0.79, which provides a number of bug fixes and enhancements over the version. (BZ# 1030622 ) Users of ledmon are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
Chapter 1. Load balancing solution architecture You can configure Satellite Server to use a load balancer to distribute client requests and network load across multiple Capsule Servers. This results in an overall performance improvement on Capsule Servers. This guide outlines how to prepare Satellite Server and Capsule Server for load balancing, and provides guidelines on how to configure a load balancer and register clients in a load-balanced setup. A load-balanced setup consists of the following components: Satellite Server Two or more Capsule Servers A load balancer Multiple clients Figure 1.1. Satellite load balancing solution architecture In a load-balanced setup, nearly all Capsule functionality continues to work as expected when one Capsule Server is down, for planned or unplanned maintenance. A load balancer works with the following services and features: Registration using subscription-manager Content management with Yum repositories Optional: Puppet Note In the load-balanced setup, a load balancer distributes load only for the services and features mentioned above. If other services, such as provisioning or virt-who, are running on the individual Capsules, you must access them directly through Capsules and not through the load balancer. Managing Puppet limitations Puppet Certificate Authority (CA) management does not support certificate signing in a load-balanced setup. Puppet CA stores certificate information, such as the serial number counter and CRL, on the file system. Multiple writer processes that attempt to use the same data can corrupt it. To manage this Puppet limitation, complete the following steps: Configure Puppet certificate signing on one Capsule Server, typically the first system where you configure Capsule Server for load balancing. Configure the clients to send CA requests to port 8141 on a load balancer. Configure a load balancer to redirect CA requests from port 8141 to port 8140 on the system where you configure Capsule Server to sign Puppet certificates.

Commands:
7.3. I/O Mode I/O mode options can be configured with virt-manager during guest installation, or on an existing guest virtual machine by editing the guest XML configuration. Table 7.2. IO mode options IO Mode Option Description IO=native The default for Red Hat Virtualization (RHV) environments. This mode refers to kernel asynchronous I/O with direct I/O options. IO=threads The default are host user-mode based threads. IO=default The default in Red Hat Enterprise Linux 7 is threads mode. In virt-manager , the I/O mode can be specified under Virtual Disk . For information on using virt-manager to change the I/O mode, see Section 3.3, "Virtual Disk Performance Options" To configure the I/O mode in the guest XML, edit the io setting inside the driver tag, specifying native , threads , or default . For example, to set the I/O mode to threads : <disk type='file' device='disk'> <driver name='qemu' type='raw' io='threads'/>

Commands:
<disk type='file' device='disk'> <driver name='qemu' type='raw' io='threads'/>
probe::socket.aio_write.return Name probe::socket.aio_write.return - Conclusion of message send via sock_aio_write Synopsis Values success Was receive successful? (1 = yes, 0 = no) protocol Protocol value flags Socket flags value name Name of this probe state Socket state value size Size of message received (in bytes) or error code if success = 0 type Socket type value family Protocol family value Context The message receiver. Description Fires at the conclusion of sending a message on a socket via the sock_aio_write function

Commands:
socket.aio_write.return
Chapter 1. Migration from Apicurio Registry 1.1 to 2.x Apicurio Registry 2.x includes new features with breaking changes from the Apicurio Registry 1.1 release. This section describes the major changes between Apicurio Registry 1.1 and version 2.x. Because of the breaking changes in 2.x, there is no automatic upgrade and a migration process is required. This involves moving the data in your existing registry to a new registry. You must also review your existing registry client applications and update their configuration to meet the new requirements. When migrating to version 2.x, you must take the following major changes into account: 1.1. New data storage options The existing registry data storage options in Apicurio Registry 1.1 ( streams , jpa , and infinispan ) have been replaced with new storage options in version 2.x ( sql and kafkasql ). These new storage options provide more robust, performant, and maintainable Apicurio Registry deployments. For details on how to deploy Apicurio Registry 2.x with your chosen storage option, see Installing and deploying Red Hat build of Apicurio Registry on OpenShift . 1.2. New v2 REST API Apicurio Registry 2.x includes a new REST API with support for artifact groups and improved long term maintainability. Apicurio Registry still supports the original registry v1 REST API and compatibility APIs, for example, Confluent and IBM schema registry APIs. Apicurio Registry now also implements the Schema Registry specification provided in the CNCF Cloud Events specification. 1.3. Refactored Java client libraries The Apicurio Registry Java client classes are available in version 2.x in a different Maven module named apicurio-registry-client . The Kafka client serializer and deserializer (SerDes) classes are available in version 2.x in three different Maven modules, one for each supported data format: Apache Avro, Protobuf, and JSON Schema. You can now use only the module you want without pulling in transitive dependencies that you are not concerned with. Additional resources For more details on the v2 REST API, see the Registry REST API documentation .

Commands:
Chapter 14. Installing kdump The kdump service is installed and activated by default on the new versions of RHEL 8 installations. 14.1. What is kdump kdump is a service that provides a crash dumping mechanism and generates a crash dump or a vmcore dump file. vmcore includes the contents of the system memory for analysis and troubleshooting. kdump uses the kexec system call to boot into the second kernel, capture kernel , without a reboot. This kernel captures the contents of the crashed kernel's memory and saves it into a file. The second kernel is available in a reserved part of the system memory. Important A kernel crash dump can be the only information available if a system failure occur. Therefore, operational kdump is important in mission-critical environments. Red Hat advises to regularly update and test kexec-tools in your normal kernel update cycle. This is important when you install new kernel features. If you have multiple kernels on a machine, you can enable kdump for all installed kernels or for specified kernels only. When you install kdump , the system creates a default /etc/kdump.conf file. /etc/kdump.conf includes the default minimum kdump configuration, which you can edit to customize the kdump configuration. 14.2. Installing kdump using Anaconda The Anaconda installer provides a graphical interface screen for kdump configuration during an interactive installation. You can enable kdump and reserve the required amount of memory. Procedure On the Anaconda installer, click KDUMP and enable kdump : In Kdump Memory Reservation , select Manual ` if you must customize the memory reserve. In KDUMP > Memory To Be Reserved (MB) , set the required memory reserve for kdump . 14.3. Installing kdump on the command line Installation options such as custom Kickstart installations, in some cases does not install or enable kdump by default. The following procedure helps you enable kdump in this case. Prerequisites An active RHEL subscription. A repository containing the kexec-tools package for your system CPU architecture. Fulfilled requirements for kdump configurations and targets. For details, see Supported kdump configurations and targets . Procedure Check if kdump is installed on your system: Output if the package is installed: Output if the package is not installed: Install kdump and other necessary packages: Important From kernel-3.10.0-693.el7 onwards, the Intel IOMMU driver is supported for kdump . For kernel-3.10.0-514[.XYZ].el7 and early versions, you must ensure that Intel IOMMU is disabled to prevent an unresponsive capture kernel.

Commands:
rpm -q kexec-tools
kexec-tools-2.0.17-11.el8.x86_64
package kexec-tools is not installed
dnf install kexec-tools
5.3. Updating Model Count The term "updating model count" refers to the number of times any model is updated during the execution of a command. It is used to determine whether a transaction, of any scope, is required to safely execute the command. Table 5.3. Updating Model Count Settings Count Description 0 No updates are performed by this command. 1 Indicates that only one model is updated by this command (and its subcommands). Also the success or failure of that update corresponds to the success or failure of the command. It should not be possible for the update to succeed while the command fails. Execution is not considered transactionally unsafe. * Any number greater than 1 indicates that execution is transactionally unsafe and an XA transaction will be required.

Commands: