mtpti5iD/redhat-docs_dataset huggingface dataset:
Chapter 6. Setting up the test environment The first step towards certifying your product is setting up the environment where you can run the tests. The test environment consists of only Compute node. All the mandatory tests that verify the system configuration required for VNF certification are run on the Compute node. 6.1. Setting up the Compute node Prerequisites You have installed RHOSP on the system based on the supported RHEL version, as applicable. The corresponding supported versions are as follows: RHOSP version Supported RHEL version RHEL 16.0 8.1 RHEL 16.1 8.2 RHEL 16.2 8.4 RHEL 17.0 9.0 RHEL 17.1 9.2 Procedure Use your RHN credentials to register your system using Red Hat Subscription Management: Display the list of available subscriptions for your system: Search for the subscription that provides the Red Hat Certification (for RHEL Server) repository and make a note of the subscription and its Pool ID. Attach the subscription to your system: Replace the pool_ID with the Pool ID of the subscription. Subscribe to the Red Hat Certification channel: On RHEL 8: Replace HOSTTYPE with the system architecture. To find out the system architecture, run Example: On RHEL 9: Replace HOSTTYPE with the system architecture. To find out the system architecture, run Example: Install the certification RPMs. Only on RHEL 9 Install OpenStack test suite package:

Commands:
subscription-manager register
subscription-manager list --available*
subscription-manager attach --pool= <pool_ID >
subscription-manager repos --enable=cert-1-for-rhel-8- <HOSTTYPE> -rpms
uname -m
subscription-manager repos --enable=cert-1-for-rhel-8-x86_64-rpms
subscription-manager repos --enable=cert-1-for-rhel-9- <HOSTTYPE> -rpms
uname -m
subscription-manager repos --enable=cert-1-for-rhel-9-x86_64-rpms
yum install redhat-certification
install redhat-certification-openstack
Chapter 5. Backing up the Original Manager Back up the original Manager using the engine-backup command, and copy the backup file to a separate location so that it can be accessed at any point during the process. For more information about engine-backup --mode=backup options, see Backing Up and Restoring the Red Hat Virtualization Manager in the Administration Guide . Procedure Log in to the original Manager and stop the ovirt-engine service: Note Though stopping the original Manager from running is not obligatory, it is recommended as it ensures no changes are made to the environment after the backup is created. Additionally, it prevents the original Manager and the new Manager from simultaneously managing existing resources. Run the engine-backup command, specifying the name of the backup file to create, and the name of the log file to create to store the backup log: Copy the files to an external server. In the following example, storage.example.com is the fully qualified domain name of a network storage server that will store the backup until it is needed, and /backup/ is any designated folder or path. If you do not require the Manager machine for other purposes, unregister it from Red Hat Subscription Manager: After backing up the Manager, deploy a new self-hosted engine and restore the backup on the new virtual machine.

Commands:
systemctl stop ovirt-engine systemctl disable ovirt-engine
engine-backup --mode=backup --file= file_name --log= log_file_name
scp -p file_name log_file_name storage.example.com:/backup/
subscription-manager unregister
Chapter 3. Differences from Red Hat build of OpenJDK 17 Red Hat build of OpenJDK 21 includes a number of enhancements that are not available in Red Hat build of OpenJDK 17, which is the long-term support (LTS) release. For more information about the additional Java enhancement proposals (JEPs) that Red Hat build of OpenJDK 21 includes, see JEPs in JDK 21 integrated since JDK 17 . Additional resources OpenJDK: JDK 18 OpenJDK: JDK 19 OpenJDK: JDK 20 OpenJDK: JDK 21

Commands:
11.4. SNMP Traps Produced by Red Hat High Availability Add-On The foghorn daemon generates the following traps: fenceNotifyFenceNode This trap occurs whenever a fenced node attempts to fence another node. Note that this trap is only generated on one node - the node that attempted to perform the fence operation. The notification includes the following fields: fenceNodeName - name of the fenced node fenceNodeID - node id of the fenced node fenceResult - the result of the fence operation (0 for success, -1 for something went wrong, -2 for no fencing methods defined) rgmanagerServiceStateChange This trap occurs when the state of a cluster service changes. The notification includes the following fields: rgmanagerServiceName - the name of the service, which includes the service type (for example, service:foo or vm:foo ). rgmanagerServiceState - the state of the service. This excludes transitional states such as starting and stopping to reduce clutter in the traps. rgmanagerServiceFlags - the service flags. There are currently two supported flags: frozen , indicating a service which has been frozen using clusvcadm -Z , and partial , indicating a service in which a failed resource has been flagged as non-critical so that the resource may fail and its components manually restarted without the entire service being affected. rgmanagerServiceCurrentOwner - the service owner. If the service is not running, this will be (none) . rgmanagerServicePreviousOwner - the last service owner, if known. If the last owner is not known, this may indicate (none) . The corosync-nodifyd daemon generates the following traps: corosyncNoticesNodeStatus This trap occurs when a node joins or leaves the cluster. The notification includes the following fields: corosyncObjectsNodeName - node name corosyncObjectsNodeID - node id corosyncObjectsNodeAddress - node IP address corosyncObjectsNodeStatus - node status ( joined or left ) corosyncNoticesQuorumStatus This trap occurs when the quorum state changes. The notification includes the following fields: corosyncObjectsNodeName - node name corosyncObjectsNodeID - node id corosyncObjectsQuorumStatus - new state of the quorum ( quorate or NOT quorate ) corosyncNoticesAppStatus This trap occurs when a client application connects or disconnects from Corosync. corosyncObjectsNodeName - node name corosyncObjectsNodeID - node id corosyncObjectsAppName - application name corosyncObjectsAppStatus - new state of the application ( connected or disconnected )

Commands:
Security Guide Red Hat Enterprise Linux 7 Concepts and techniques to secure RHEL servers and workstations Mirek Jahoda Red Hat Customer Content Services mjahoda@redhat.com Jan Fiala Red Hat Customer Content Services jafiala@redhat.com Stephen Wadeley Red Hat Customer Content Services Robert Kratky Red Hat Customer Content Services Martin Prpic Red Hat Customer Content Services Ioanna Gkioka Red Hat Customer Content Services Tomas Capek Red Hat Customer Content Services Yoana Ruseva Red Hat Customer Content Services Miroslav Svoboda Red Hat Customer Content Services

Commands:
14.5.21. Converting QEMU Arguments to Domain XML The virsh domxml-from-native provides a way to convert an existing set of QEMU arguments into a guest description using libvirt Domain XML that can then be used by libvirt. Note that this command is intended to be used only to convert existing qemu guests previously started from the command line in order to allow them to be managed through libvirt. The method described here should not be used to create new guests from scratch. New guests should be created using either virsh or virt-manager. Additional information can be found here . Suppose you have a QEMU guest with the following args file: To convert this to a domain XML file so that the guest can be managed by libvirt, run: This command turns the args file above, into this domain XML file:

Commands:
cat demo.args LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test /usr/bin/qemu -S -M pc -m 214 -smp 1 -nographic -monitor pty -no-acpi -boot c -hda /dev/HostVG/QEMUGuest1 -net none -serial none -parallel none -usb
virsh domxml-from-native qemu-argv demo.args
<domain type='qemu'> <uuid>00000000-0000-0000-0000-000000000000</uuid> <memory>219136</memory> <currentMemory>219136</currentMemory> <vcpu>1</vcpu> <os> <type arch='i686' machine='pc'>hvm</type> <boot dev='hd'/> </os> <clock offset='utc'/> <on_poweroff>destroy</on_poweroff> <on_reboot>restart</on_reboot> <on_crash>destroy</on_crash> <devices> <emulator>/usr/bin/qemu</emulator> <disk type='block' device='disk'> <source dev='/dev/HostVG/QEMUGuest1'/> <target dev='hda' bus='ide'/> </disk> </devices> </domain>
7.16. RHEA-2014:1456 - new packages: mod_authnz_pam, mod_intercept_form_submit, mod_lookup_identity New authentication and identity modules for Apache HTTP server are now available for Red Hat Enterprise Linux 6. The mod_authnz_pam, mod_intercept_form_submit, and mod_lookup_identity are a set of Apache HTTP server modules to support authentication and identity functions for web applications. The mod_authnz_pam Apache module serves as a PAM authorization module, supplementing authentication done by other modules, for example mod_auth_kerb. It can also be used as a full Basic Authentication provider for testing purposes, running the login and password authentication through the PAM stack. The mod_intercept_form_submit Apache module intercepts application's login form submission and runs the PAM authentication. The mod_lookup_identity Apache module retrieves additional information about the authenticated user. This enhancement update adds the mod_authnz_pam, mod_intercept_form_submit, mod_lookup_identity packages to Red Hat Enterprise Linux 6. (BZ# 1075121 , BZ# 1075122 , BZ# 1080478 ) All users who require the new authentication and identity modules for Apache HTTP server are advised to install these new packages.

Commands:
5.6.2. Removing a Failover Domain To remove a failover domain, follow these steps: At the left frame of the the Cluster Configuration Tool , click the failover domain that you want to delete (listed under Failover Domains ). At the bottom of the right frame (labeled Properties ), click the Delete Failover Domain button. Clicking the Delete Failover Domain button causes a warning dialog box do be displayed asking if you want to remove the failover domain. Confirm that the failover domain identified in the warning dialog box is the one you want to delete and click Yes . Clicking Yes causes the failover domain to be removed from the list of failover domains under Failover Domains in the left frame of the Cluster Configuration Tool . At the Cluster Configuration Tool , perform one of the following actions depending on whether the configuration is for a new cluster or for one that is operational and running: New cluster - If this is a new cluster, choose File => Save to save the changes to the cluster configuration. Running cluster - If this cluster is operational and running, and you want to propagate the change immediately, click the Send to Cluster button. Clicking Send to Cluster automatically saves the configuration change. If you do not want to propagate the change immediately, choose File => Save to save the changes to the cluster configuration.

Commands:
Chapter 9. Post-deployment The following subsections describe several post-deployment operations for managing the Ceph cluster. 9.1. Accessing the overcloud Director generates a script to configure and help authenticate interactions with your overcloud from the undercloud. Director saves this file, overcloudrc , in the home directory of the stack user. Run the following command to use this file: This loads the necessary environment variables to interact with your overcloud from the undercloud CLI. To return to interacting with the undercloud, run the following command: 9.2. Monitoring Ceph Storage nodes After you create the overcloud, check the status of the Ceph Storage Cluster to ensure that it works correctly. Procedure Log in to a Controller node as the heat-admin user: Check the health of the cluster: If the cluster has no issues, the command reports back HEALTH_OK . This means the cluster is safe to use. Log in to an overcloud node that runs the Ceph monitor service and check the status of all OSDs in the cluster: Check the status of the Ceph Monitor quorum: This shows the monitors participating in the quorum and which one is the leader. Verify that all Ceph OSDs are running: For more information on monitoring Ceph Storage clusters, see Monitoring in the Red Hat Ceph Storage Administration Guide .

Commands:
source ~/overcloudrc
source ~/stackrc
nova list ssh heat-admin@192.168.0.25
sudo podman exec ceph-mon-<HOSTNAME> ceph health
sudo podman exec ceph-mon-<HOSTNAME> ceph osd tree
sudo podman exec ceph-mon-<HOSTNAME> ceph quorum_status
sudo podman exec ceph-mon-<HOSTNAME> ceph osd stat
8.72. gnome-packagekit 8.72.1. RHBA-2014:1479 - gnome-packagekit bug fix and update Updated gnome-packagekit packages that fix two bugs are now available for Red Hat Enterprise Linux 6. The gnome-packagekit packages provide session applications for the PackageKit API. Bug Fixes BZ# 720922 Previously, if a search query was issued in the gnome-packagekit GUI before the list of packages in the left pane was populated, gnome-packagekit became unresponsive. With this update, gnome-packagekit has been modified so that it does not permit search queries before loading the package list. As a result, gnome-packagekit no longer hangs in the described case. BZ# 732796 Prior to this update, the "Install Updates" button in the gpk-update-viewer GUI was incorrectly re-enabled when the authentication dialog started. This bug has been fixed, and the button remains disabled when the authentication dialog appears. Users of gnome-packagekit are advised to upgrade to these updated packages, which fix these bugs.

Commands:
5.4.2. Moving Extents to a New Disk In this example, the logical volume is distributed across three physical volumes in the volume group myvg as follows: We want to move the extents of /dev/sdb1 to a new device, /dev/sdd1 . 5.4.2.1. Creating the New Physical Volume Create a new physical volume from /dev/sdd1 .

Commands:
pvs -o+pv_used PV VG Fmt Attr PSize PFree Used /dev/sda1 myvg lvm2 a- 17.15G 7.15G 10.00G /dev/sdb1 myvg lvm2 a- 17.15G 15.15G 2.00G /dev/sdc1 myvg lvm2 a- 17.15G 15.15G 2.00G
pvcreate /dev/sdd1 Physical volume "/dev/sdd1" successfully created
Chapter 2. Architectures Red Hat Enterprise Linux 8.3 is distributed with the kernel version 4.18.0-240, which provides support for the following architectures: AMD and Intel 64-bit architectures The 64-bit ARM architecture IBM Power Systems, Little Endian 64-bit IBM Z Make sure you purchase the appropriate subscription for each architecture. For more information, see Get Started with Red Hat Enterprise Linux - additional architectures . For a list of available subscriptions, see Subscription Utilization on the Customer Portal.

Commands:
Chapter 4. Adding user preferences You can change the default preferences for your profile to meet your requirements. You can set your default project, topology view (graph/list), editing medium (form or YAML), and language preferences. The changes made to the user preferences are automatically saved. 4.1. Setting user preferences You can set the default user preferences for your cluster. Procedure Log in to the OpenShift Container Platform web console using your login credentials. Use the masthead to access the user preferences under the user profile. In the General section: In the Perspective field, you can set the default perspective you want to be logged in to. You can select the Administrator or the Developer perspective as required. If a perspective is not selected, you are logged into the perspective you last visited. In the Project field, select a project you want to work in. The console will default to the project every time you log in. In the Topology field, you can set the topology view to default to the graph or list view. If not selected, the console defaults to the last view you used. In the Create/Edit resource method field, you can set a preference for creating or editing a resource. If both the form and YAML options are available, the console defaults to your selection. In the Language section, select Default browser language to use the default browser language settings. Otherwise, select the language that you want to use for the console.

Commands:
3.5. The Metadata Daemon (lvmetad) LVM can optionally use a central metadata cache, implemented through a daemon ( lvmetad ) and a udev rule. The metadata daemon has two main purposes: it improves performance of LVM commands and it allows udev to automatically activate logical volumes or entire volume groups as they become available to the system. LVM is configured to make use of the daemon when the global/use_lvmetad variable is set to 1 in the lvm.conf configuration file. This is the default value. For information on the lvm.conf configuration file, see Appendix B, The LVM Configuration Files . Note The lvmetad daemon is not currently supported across the nodes of a cluster, and requires that the locking type be local file-based locking. When you use the lvmconf --enable-cluster/--disable-cluster command, the lvm.conf file is configured appropriately, including the use_lvmetad setting (which should be 0 for locking_type=3 ). Note, however, that in a Pacemaker cluster, the ocf:heartbeat:clvm resource agent itself sets these parameters as part of the start procedure. If you change the value of use_lvmetad from 1 to 0, you must reboot or stop the lvmetad service manually with the following command. Normally, each LVM command issues a disk scan to find all relevant physical volumes and to read volume group metadata. However, if the metadata daemon is running and enabled, this expensive scan can be skipped. Instead, the lvmetad daemon scans each device only once, when it becomes available, using udev rules. This can save a significant amount of I/O and reduce the time required to complete LVM operations, particularly on systems with many disks. When a new volume group is made available at runtime (for example, through hotplug or iSCSI), its logical volumes must be activated in order to be used. When the lvmetad daemon is enabled, the activation/auto_activation_volume_list option in the lvm.conf configuration file can be used to configure a list of volume groups or logical volumes (or both) that should be automatically activated. Without the lvmetad daemon, a manual activation is necessary. Note When the lvmetad daemon is running, the filter = setting in the /etc/lvm/lvm.conf file does not apply when you execute the pvscan --cache device command. To filter devices, you need to use the global_filter = setting. Devices that fail the global filter are not opened by LVM and are never scanned. You may need to use a global filter, for example, when you use LVM devices in VMs and you do not want the contents of the devices in the VMs to be scanned by the physical host.

Commands:
systemctl stop lvm2-lvmetad.service
Appendix C. Using AMQ Broker with the examples The AMQ Python examples require a running message broker with a queue named examples . Use the procedures below to install and start the broker and define the queue. C.1. Installing the broker Follow the instructions in Getting Started with AMQ Broker to install the broker and create a broker instance . Enable anonymous access. The following procedures refer to the location of the broker instance as <broker-instance-dir> . C.2. Starting the broker Procedure Use the artemis run command to start the broker. USD <broker-instance-dir> /bin/artemis run Check the console output for any critical errors logged during startup. The broker logs Server is now live when it is ready. USD example-broker/bin/artemis run __ __ ____ ____ _ /\ | \/ |/ __ \ | _ \ | | / \ | \ / | | | | | |_) |_ __ ___ | | _____ _ __ / /\ \ | |\/| | | | | | _ <| '__/ _ \| |/ / _ \ '__| / ____ \| | | | |__| | | |_) | | | (_) | < __/ | /_/ \_\_| |_|\___\_\ |____/|_| \___/|_|\_\___|_| Red Hat AMQ <version> 2020-06-03 12:12:11,807 INFO [org.apache.activemq.artemis.integration.bootstrap] AMQ101000: Starting ActiveMQ Artemis Server ... 2020-06-03 12:12:12,336 INFO [org.apache.activemq.artemis.core.server] AMQ221007: Server is now live ... C.3. Creating a queue In a new terminal, use the artemis queue command to create a queue named examples . USD <broker-instance-dir> /bin/artemis queue create --name examples --address examples --auto-create-address --anycast You are prompted to answer a series of yes or no questions. Answer N for no to all of them. Once the queue is created, the broker is ready for use with the example programs. C.4. Stopping the broker When you are done running the examples, use the artemis stop command to stop the broker. USD <broker-instance-dir> /bin/artemis stop Revised on 2021-08-24 14:28:53 UTC

Commands:
<broker-instance-dir> /bin/artemis run
example-broker/bin/artemis run __ __ ____ ____ _ /\ | \/ |/ __ \ | _ \ | | / \ | \ / | | | | | |_) |_ __ ___ | | _____ _ __ / /\ \ | |\/| | | | | | _ <| '__/ _ \| |/ / _ \ '__| / ____ \| | | | |__| | | |_) | | | (_) | < __/ | /_/ \_\_| |_|\___\_\ |____/|_| \___/|_|\_\___|_| Red Hat AMQ <version> 2020-06-03 12:12:11,807 INFO [org.apache.activemq.artemis.integration.bootstrap] AMQ101000: Starting ActiveMQ Artemis Server 2020-06-03 12:12:12,336 INFO [org.apache.activemq.artemis.core.server] AMQ221007: Server is now live
<broker-instance-dir> /bin/artemis queue create --name examples --address examples --auto-create-address --anycast
<broker-instance-dir> /bin/artemis stop
Chapter 29. Hardware Enablement genwqe-tools updated for IBM Power Systems ppc64 and ppc64le architectures The genwqe-tools packages have been updated for IBM Power Systems and the little-endian variant of IBM Power Systems. This enhancement update includes the following backported fixes from genwqe-tools master branch: the adler32 detect corruption checksum now returns correction on the deflateSetDictionary() function the deflateSetDictionary() function now returns error on NULL dictionary as required by the spec file The debugger has been removed form the zpipe_rnd.c file Potential overflow in expression has been avoided Out of bounds access and possible resource leak have been fixed To simplify contributions, a Contributor License Agreement (CLA) has been changed to the Developer's Certificate of Origin (DCO) Potential security hole has been resolved The Failure of the Hardware Accelerator Tool genwqe_cksum which causes EEH, has been resolved Users of genwqe-tools are advised to upgrade to these updated packages, which fix these bugs and add these enhancements. (BZ#1456492) Hardware utility tools now correctly identify recently released hardware Prior to this update, obsolete ID files caused that recently released hardware connected to a computer was reported as unknown. To fix this bug, PCI, USB, and vendor device identification files have been updated. As a result, hardware utility tools now correctly identify recently released hardware. (BZ#1489281)

Commands: