mtpti5iD/redhat-docs_dataset huggingface dataset:
2.2. Ticket Spinlocks A key part of any system design is ensuring that one process does not alter memory used by another process. Uncontrolled data change in memory can result in data corruption and system crashes. To prevent this, the operating system allows a process to lock a piece of memory, perform an operation, then unlock or "free" the memory. One common implementation of memory locking is through spin locks , which allow a process to keep checking to see if a lock is available and take the lock as soon as it becomes available. If there are multiple processes competing for the same lock, the first one to request the lock after it has been freed gets it. When all processes have the same access to memory, this approach is "fair" and works quite well. Unfortunately, on a NUMA system, not all processes have equal access to the locks. Processes on the same NUMA node as the lock have an unfair advantage in obtaining the lock. Processes on remote NUMA nodes experience lock starvation and degraded performance. To address this, Red Hat Enterprise Linux implemented ticket spinlocks . This feature adds a reservation queue mechanism to the lock, allowing all processes to take a lock in the order that they requested it. This eliminates timing problems and unfair advantages in lock requests. While a ticket spinlock has slightly more overhead than an ordinary spinlock, it scales better and provides better performance on NUMA systems.

Commands:
Chapter 26. Troubleshooting upgrade issues If you experience any issues with during the upgrade process, refer to the advice in this section. 26.1. Correcting environment files If you have made a mistake with any parameters in any custom environment files, you can correct the environment file and run the openstack overcloud upgrade prepare command at any time during the upgrade. This command uploads a new version of your overcloud plan to director, which will generate a new set of config-download playbooks. This example contains a repository name mistake in the upgrades-environment.yaml file: This mistake causes an issue during the Leapp upgrade for the Controller node. To rectify this issue, correct the mistake and run the openstack overcloud upgrade prepare command. Procedure Correct the mistake in the file: Run the upgrade preparation command with the corrected file: Wait until the overcloud stack update completes. Continue with the upgrade operation step that failed.

Commands:
parameter_defaults: UpgradeLeappEnabled: true UpgradeLeappCommandOptions: "--enablerepo rhel-7-for-x86_64-baseos-eus-rpms --enablerepo rhel-8-for-x86_64-appstream-eus-rpms --enablerepo fast-datapath-for-rhel-8-x86_64-rpms" CephAnsibleRepo: rhceph-4-tools-for-rhel-8-x86_64-rpms
parameter_defaults: UpgradeLeappEnabled: true UpgradeLeappCommandOptions: "--enablerepo rhel-8-for-x86_64-baseos-eus-rpms --enablerepo rhel-8-for-x86_64-appstream-eus-rpms --enablerepo fast-datapath-for-rhel-8-x86_64-rpms" CephAnsibleRepo: rhceph-4-tools-for-rhel-8-x86_64-rpms
openstack overcloud upgrade prepare --stack STACK NAME --templates -e ENVIRONMENT FILE ... -e /home/stack/templates/upgrades-environment.yaml ...
8.4. Red Hat Enterprise Linux-Specific Information There is little about the general topic of disasters and disaster recovery that has a direct bearing on any specific operating system. After all, the computers in a flooded data center will be inoperative whether they run Red Hat Enterprise Linux or some other operating system. However, there are parts of Red Hat Enterprise Linux that relate to certain specific aspects of disaster recovery; these are discussed in this section. 8.4.1. Software Support As a software vendor, Red Hat, Inc does have a number of support offerings for its products, including Red Hat Enterprise Linux. You are using the most basic support tool right now by reading this manual. Documentation for Red Hat Enterprise Linux is available on the Red Hat Enterprise Linux Documentation CD (which can also be installed on your system for fast access), in printed form, and on the Red Hat website at http://www.redhat.com/docs/ . Self support options are available via the many mailing lists hosted by Red Hat (available at https://www.redhat.com/mailman/listinfo ). These mailing lists take advantage of the combined knowledge of Red Hat's user community; in addition, many lists are monitored by Red Hat personnel, who contribute as time permits. Other resources are available from Red Hat's main support page at http://www.redhat.com/apps/support/ . More comprehensive support options exist; information on them can be found on the Red Hat website.

Commands:
Chapter 60. 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
3.5. Growing a GFS2 File System The gfs2_grow command is used to expand a GFS2 file system after the device where the file system resides has been expanded. Running the gfs2_grow command on an existing GFS2 file system fills all spare space between the current end of the file system and the end of the device with a newly initialized GFS2 file system extension. When the fill operation is completed, the resource index for the file system is updated. All nodes in the cluster can then use the extra storage space that has been added. The gfs2_grow command must be run on a mounted file system, but only needs to be run on one node in a cluster. All the other nodes sense that the expansion has occurred and automatically start using the new space. Note Once you have created a GFS2 file system with the mkfs.gfs2 command, you cannot decrease the size of the file system. Usage MountPoint Specifies the GFS2 file system to which the actions apply. Comments Before running the gfs2_grow command: Back up important data on the file system. Determine the volume that is used by the file system to be expanded by running the df MountPoint command. Expand the underlying cluster volume with LVM. For information on administering LVM volumes, see Logical Volume Manager Administration . After running the gfs2_grow command, run the df command to check that the new space is now available in the file system. Examples In this example, the file system on the /mygfs2fs directory is expanded. Complete Usage MountPoint Specifies the directory where the GFS2 file system is mounted. Device Specifies the device node of the file system. Table 3.3, "GFS2-specific Options Available While Expanding A File System" describes the GFS2-specific options that can be used while expanding a GFS2 file system. Table 3.3. GFS2-specific Options Available While Expanding A File System Option Description -h Help. Displays a short usage message. -q Quiet. Turns down the verbosity level. -r Megabytes Specifies the size of the new resource group. The default size is 256 megabytes. -T Test. Do all calculations, but do not write any data to the disk and do not expand the file system. -V Displays command version information.

Commands:
gfs2_grow MountPoint
gfs2_grow /mygfs2fs FS: Mount Point: /mygfs2fs FS: Device: /dev/mapper/gfs2testvg-gfs2testlv FS: Size: 524288 (0x80000) FS: RG size: 65533 (0xfffd) DEV: Size: 655360 (0xa0000) The file system grew by 512MB. gfs2_grow complete.
gfs2_grow [ Options ] { MountPoint | Device } [ MountPoint | Device ]
Chapter 4. Summary With Red Hat OpenShift Platform 4, Red Hat OpenStack Platform 16.2, and Red Hat Ceph Storage 4, organizations have access to a comprehensive and prescriptive installation experience for their on-premises container infrastructure. This Red Hat Tested Solution showcases a prescriptive and pre-validated private cloud solution from Red Hat that provides rapid provisioning and lifecycle management of containerized infrastructure, virtual machines (VMs), and associated application and infrastructure services. The Red Hat Quality Engineering teams (QE) have tested and validated the implementation as presented in this solution. Organizations seeking to operationalize this solution quickly can be assured that all options represented are both fully tested as well as fully supported by Red Hat. Red Hat OpenShift Container Platform, Red Hat OpenStack Platform, and Red Hat Ceph Storage are the key architectural components of this solution. This integration is a key component to hybrid and multi-cloud solutions with OpenShift Container Platform serving as the common container and platform across a variety of deployment footprints.

Commands:
10.2. Interacting with NetworkManager Users do not interact with the NetworkManager system service directly. Instead, you can perform network configuration tasks via NetworkManager 's Notification Area applet. The applet has multiple states that serve as visual indicators for the type of connection you are currently using. Hover the pointer over the applet icon for tooltip information on the current connection state. Figure 10.1. NetworkManager applet states If you do not see the NetworkManager applet in the GNOME panel, and assuming that the NetworkManager package is installed on your system, you can start the applet by running the following command as a normal user (not root ): After running this command, the applet appears in your Notification Area. You can ensure that the applet runs each time you log in by clicking System Preferences Startup Applications to open the Startup Applications Preferences window. Then, select the Startup Programs tab and check the box to NetworkManager . 10.2.1. Connecting to a Network When you left-click on the applet icon, you are presented with: a list of categorized networks you are currently connected to (such as Wired and Wireless ); a list of all Available Networks that NetworkManager has detected; options for connecting to any configured Virtual Private Networks (VPNs); and, options for connecting to hidden or new wireless networks. If you are connected to a network, its name is presented in bold typeface under its network type, such as Wired or Wireless . When many networks are available, such as wireless access points, the More networks expandable menu entry appears. Figure 10.2. The NetworkManager applet's left-click menu, showing all available and connected-to networks

Commands:
~]USD nm-applet &
Chapter 29. KafkaJmxOptions schema reference Used in: KafkaClusterSpec , KafkaConnectSpec , KafkaMirrorMaker2Spec , ZookeeperClusterSpec Full list of KafkaJmxOptions schema properties Configures JMX connection options. Get JMX metrics from Kafka brokers, ZooKeeper nodes, Kafka Connect, and MirrorMaker 2. by connecting to port 9999. Use the jmxOptions property to configure a password-protected or an unprotected JMX port. Using password protection prevents unauthorized pods from accessing the port. You can then obtain metrics about the component. For example, for each Kafka broker you can obtain bytes-per-second usage data from clients, or the request rate of the network of the broker. To enable security for the JMX port, set the type parameter in the authentication field to password . Example password-protected JMX configuration for Kafka brokers and ZooKeeper nodes apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster spec: kafka: # ... jmxOptions: authentication: type: "password" # ... zookeeper: # ... jmxOptions: authentication: type: "password" #... You can then deploy a pod into a cluster and obtain JMX metrics using the headless service by specifying which broker you want to address. For example, to get JMX metrics from broker 0 you specify: " CLUSTER-NAME -kafka-0. CLUSTER-NAME -kafka-brokers" CLUSTER-NAME -kafka-0 is name of the broker pod, and CLUSTER-NAME -kafka-brokers is the name of the headless service to return the IPs of the broker pods. If the JMX port is secured, you can get the username and password by referencing them from the JMX Secret in the deployment of your pod. For an unprotected JMX port, use an empty object {} to open the JMX port on the headless service. You deploy a pod and obtain metrics in the same way as for the protected port, but in this case any pod can read from the JMX port. Example open port JMX configuration for Kafka brokers and ZooKeeper nodes apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster spec: kafka: # ... jmxOptions: {} # ... zookeeper: # ... jmxOptions: {} # ... Additional resources For more information on the Kafka component metrics exposed using JMX, see the Apache Kafka documentation . 29.1. KafkaJmxOptions schema properties Property Property type Description authentication KafkaJmxAuthenticationPassword Authentication configuration for connecting to the JMX port.

Commands:
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster spec: kafka: # jmxOptions: authentication: type: "password" # zookeeper: # jmxOptions: authentication: type: "password" #
" CLUSTER-NAME -kafka-0. CLUSTER-NAME -kafka-brokers"
apiVersion: kafka.strimzi.io/v1beta2 kind: Kafka metadata: name: my-cluster spec: kafka: # jmxOptions: {} # zookeeper: # jmxOptions: {} #
10.9. Choose an Installation Boot Method You can use several methods to boot the Red Hat Enterprise Linux 7 installation program. The method you choose depends upon your installation media. Note Installation media must remain mounted throughout installation, including during execution of the %post section of a kickstart file. Full installation DVD or USB drive You can create bootable media from the full installation DVD ISO image. In this case, a single DVD or USB drive can be used to complete the entire installation - it will serve both as a boot device and as an installation source for installing software packages. See Chapter 3, Making Media for instructions on how to make a full installation DVD or USB drive. Minimal boot CD, DVD or USB Flash Drive A minimal boot CD, DVD or USB flash drive is created using a small ISO image, which only contains data necessary to boot the system and start the installation. If you use this boot media, you will need an additional installation source from which packages will be installed. See Chapter 3, Making Media for instructions on making boot CDs, DVDs and USB flash drives. PXE Server A preboot execution environment (PXE) server allows the installation program to boot over the network. After you boot the system, you complete the installation from a different installation source, such as a local hard drive or a location on a network. For more information on PXE servers, see Chapter 24, Preparing for a Network Installation .

Commands:
Chapter 2. Migrating Service Registry data Migrating data to Service Registry 2.x requires exporting all data from your existing 1.1 deployment and importing it into the new 2.x deployment. If you are using Service Registry as a schema registry for Kafka applications, data migration is critical because each Kafka message carries the global identifier for the schema stored in Service Registry. This identifier must be preserved during registry data migration. Service Registry 2.x provides an API to bulk import/export all data from your registry deployment, which guarantees that all identifiers are kept when importing data from your existing registry. The export API downloads a custom .zip file containing all the information for your artifacts. The import API accepts this .zip and loads all artifacts into the registry in a single batch. Service Registry 1.1 does not provide an import/export API. However, version 2.x provides an export tool compatible with Service Registry 1.1 to export a .zip , which you can import into your 2.x registry. This tool uses common existing APIs to export all content in the registry. However, it is less performant than the 2.x export API, and should only be used when exporting from a 1.1 registry. Prerequisites Running Service Registry instances of the 1.1 server you are exporting from and the 2.x server you are importing into. Download the Service Registry exportV1 tool from the Red Hat Customer Portal. This is a Java application that you can run on the command line. Procedure Export all the data from Service Registry 1.1 using the exportV1 tool. This generates a registry-export.zip file in your current directory: java -jar apicurio-registry-utils-exportV1-2.5.10.Final-redhat-00001.jar http://old-registry.my-company.com/api Import the .zip file into Service Registry 2.x using the import API: curl -X POST "http://new-registry.my-company.com/apis/registry/v2/admin/import" \ -H "Accept: application/json" -H "Content-Type: application/zip" \ --data-binary @registry-export.zip Check that all the artifacts have been imported into the new 2.x registry by running these commands and comparing the count field: curl "http://old-registry.my-company.com/api/search/artifacts" curl "http://new-registry.my-company.com/apis/registry/v2/search/artifacts" Additional resources For more details on the import/export REST API, see the Service Registry User Guide . For more details on the export tool for migrating from version 1.x to 2.x, see the Apicurio Registry export utility for 1.x versions .

Commands:
java -jar apicurio-registry-utils-exportV1-2.5.10.Final-redhat-00001.jar http://old-registry.my-company.com/api
curl -X POST "http://new-registry.my-company.com/apis/registry/v2/admin/import" -H "Accept: application/json" -H "Content-Type: application/zip" --data-binary @registry-export.zip
curl "http://old-registry.my-company.com/api/search/artifacts"
curl "http://new-registry.my-company.com/apis/registry/v2/search/artifacts"
14.11.3. Stopping and Deleting Storage Pools The pool-destroy pool-or-uuid stops a storage pool. Once stopped, libvirt will no longer manage the pool but the raw data contained in the pool is not changed, and can be later recovered with the pool-create command. The pool-delete pool-or-uuid destroys the resources used by the specified storage pool. It is important to note that this operation is non-recoverable and non-reversible. However, the pool structure will still exist after this command, ready to accept the creation of new storage volumes. The pool-undefine pool-or-uuid command undefines the configuration for an inactive pool.

Commands:
4.2. Finish Configuring the Diskless Environment To use the graphical version of the Network Booting Tool , you must be running the X Window System, have root privileges, and have the system-config-netboot RPM package installed. To start the Network Booting Tool from the desktop, go to Applications (the main menu on the panel) => System Settings => Server Settings => Network Booting Service . Or, type the command system-config-netboot at a shell prompt (for example, in an XTerm or a GNOME terminal ). If starting the Network Booting Tool for the first time, select Diskless from the First Time Druid . Otherwise, select Configure => Diskless from the pull-down menu, and then click Add . A wizard appears to step you through the process: Click Forward on the first page. On the Diskless Identifier page, enter a Name and Description for the diskless environment. Click Forward . Enter the IP address or domain name of the NFS server configured in Section 4.1, "Configuring the NFS Server" as well as the directory exported as the diskless environment. Click Forward . The kernel versions installed in the diskless environment are listed. Select the kernel version to boot on the diskless system. Click Apply to finish the configuration. After clicking Apply , the diskless kernel and image file are created based on the kernel selected. They are copied to the PXE boot directory /tftpboot/linux-install/ <os-identifier> / . The directory snapshot/ is created in the same directory as the root/ directory (for example, /diskless/i386/RHEL4-AS/snapshot/ ) with a file called files in it. This file contains a list of files and directories that must be read/write for each diskless system. Do not modify this file. If additional entries must be added to the list, create a files.custom file in the same directory as the files file, and add each additional file or directory on a separate line.

Commands:
Chapter 1. Ceph block devices and OpenStack The Red Hat Enterprise Linux OpenStack Platform Director provides two methods for using Ceph as a backend for Glance, Cinder, Cinder Backup and Nova: OpenStack creates the Ceph storage cluster: OpenStack Director can create a Ceph storage cluster. This requires configuring templates for the Ceph OSDs. OpenStack handles the installation and configuration of Ceph hosts. With this scenario, OpenStack will install the Ceph monitors with the OpenStack controller hosts. OpenStack connects to an existing Ceph storage cluster: OpenStack Director, using Red Hat OpenStack Platform 9 and higher, can connect to a Ceph monitor and configure the Ceph storage cluster for use as a backend for OpenStack. The foregoing methods are the preferred methods for configuring Ceph as a backend for OpenStack, because they will handle much of the installation and configuration automatically. This document details the manual procedure for configuring Ceph, QEMU, libvirt and OpenStack to use Ceph as a backend. This document is intended for use for those who do not intend to use the RHEL OSP Director. Note A running Ceph storage cluster and at least one OpenStack host is required to use Ceph block devices as a backend for OpenStack. Three parts of OpenStack integrate with Ceph's block devices: Images: OpenStack Glance manages images for VMs. Images are immutable. OpenStack treats images as binary blobs and downloads them accordingly. Volumes: Volumes are block devices. OpenStack uses volumes to boot VMs, or to attach volumes to running VMs. OpenStack manages volumes using Cinder services. Ceph can serve as a black end for OpenStack Cinder and Cinder Backup. Guest Disks: Guest disks are guest operating system disks. By default, when booting a virtual machine, its disk appears as a file on the file system of the hypervisor, by default, under /var/lib/nova/instances/<uuid>/ directory. OpenStack Glance can store images in a Ceph block device, and can use Cinder to boot a virtual machine using a copy-on-write clone of an image. Important Ceph doesn't support QCOW2 for hosting a virtual machine disk. To boot virtual machines, either ephemeral backend or booting from a volume, the Glance image format must be RAW. OpenStack can use Ceph for images, volumes or guest disks virtual machines. There is no requirement for using all three. Additional Resources See the Red Hat OpenStack Platform documentation for additional details.

Commands: