mtpti5iD/redhat-docs_dataset huggingface dataset:
4.4. Fencing In the context of the Red Hat Virtualization environment, fencing is a host reboot initiated by the Manager using a fence agent and performed by a power management device. Fencing allows a cluster to react to unexpected host failures as well as enforce power saving, load balancing, and virtual machine availability policies. Fencing ensures that the role of Storage Pool Manager (SPM) is always assigned to a functional host. If the fenced host was the SPM, the SPM role is relinquished and reassigned to a responsive host. Because the host with the SPM role is the only host that is able to write data domain structure metadata, a non-responsive, un-fenced SPM host causes its environment to lose the ability to create and destroy virtual disks, take snapshots, extend logical volumes, and all other actions that require changes to data domain structure metadata. When a host becomes non-responsive, all of the virtual machines that are currently running on that host can also become non-responsive. However, the non-responsive host retains the lock on the virtual machine hard disk images for virtual machines it is running. Attempting to start a virtual machine on a second host and assign the second host write privileges for the virtual machine hard disk image can cause data corruption. Fencing allows the Red Hat Virtualization Manager to assume that the lock on a virtual machine hard disk image has been released; the Manager can use a fence agent to confirm that the problem host has been rebooted. When this confirmation is received, the Red Hat Virtualization Manager can start a virtual machine from the problem host on another host without risking data corruption. Fencing is the basis for highly-available virtual machines. A virtual machine that has been marked highly-available can not be safely started on an alternate host without the certainty that doing so will not cause data corruption. When a host becomes non-responsive, the Red Hat Virtualization Manager allows a grace period of thirty (30) seconds to pass before any action is taken, to allow the host to recover from any temporary errors. If the host has not become responsive by the time the grace period has passed, the Manager automatically begins to mitigate any negative impact from the non-responsive host. The Manager uses the fencing agent for the power management card on the host to stop the host, confirm it has stopped, start the host, and confirm that the host has been started. When the host finishes booting, it attempts to rejoin the cluster that it was a part of before it was fenced. If the issue that caused the host to become non-responsive has been resolved by the reboot, then the host is automatically set to Up status and is once again capable of starting and hosting virtual machines.

Commands:
Chapter 4. Managing groups You can use Identity Service (keystone) groups to assign consistent permissions to multiple user accounts. 4.1. Configuring groups with the CLI Create a group and assign permissions to the group. Members of the group inherit the same permissions that you assign to the group: Create the group grp-Auditors : View a list of keystone groups: Grant the grp-Auditors group permission to access the demo project, while using the member role: Add the existing user user1 to the grp-Auditors group: Confirm that user1 is a member of grp-Auditors : Review the effective permissions that have been assigned to user1 : 4.2. Configuring groups with the Dashboard You can use the dashboard to manage the membership of keystone groups. However, you must use the command-line to assign role permissions to a group. For more information, see Configuring groups with the CLI . 4.2.1. Creating a group Log in to the dashboard as a user with administrative privileges. Select Identity > Groups . Click +Create Group . Enter a name and description for the group. Click Create Group . 4.2.2. Managing Group membership You can use the dashboard to manage the membership of keystone groups. Log in to the dashboard as a user with administrative privileges. Select Identity > Groups . Click Manage Members for the group that you want to edit. Use Add users to add a user to the group. If you want to remove a user, mark its checkbox and click Remove users .

Commands:
openstack group create grp-Auditors +-------------+----------------------------------+ | Field | Value | +-------------+----------------------------------+ | description | | | domain_id | default | | id | 2a4856fc242142a4aa7c02d28edfdfff | | name | grp-Auditors | +-------------+----------------------------------+
openstack group list --long +----------------------------------+--------------+-----------+-------------+ | ID | Name | Domain ID | Description | +----------------------------------+--------------+-----------+-------------+ | 2a4856fc242142a4aa7c02d28edfdfff | grp-Auditors | default | | +----------------------------------+--------------+-----------+-------------+
openstack role add member --group grp-Auditors --project demo
openstack group add user grp-Auditors user1 user1 added to group grp-Auditors
openstack group contains user grp-Auditors user1 user1 in group grp-Auditors
openstack role assignment list --effective --user user1 +----------------------------------+----------------------------------+-------+----------------------------------+--------+-----------+ | Role | User | Group | Project | Domain | Inherited | +----------------------------------+----------------------------------+-------+----------------------------------+--------+-----------+ | 9fe2ff9ee4384b1894a90878d3e92bab | 3fefe5b4f6c948e6959d1feaef4822f2 | | 0ce36252e2fb4ea8983bed2a568fa832 | | False | +----------------------------------+----------------------------------+-------+----------------------------------+--------+-----------+
Chapter 14. Overview of NVMe over fabric devices Non-volatile Memory ExpressTM (NVMeTM) is an interface that allows host software utility to communicate with solid state drives. Use the following types of fabric transport to configure NVMe over fabric devices: NVMe over Remote Direct Memory Access (NVMe/RDMA) For information about how to configure NVMeTM/RDMA, see Configuring NVMe over fabrics using NVMe/RDMA . NVMe over Fibre Channel (NVMe/FC) For information about how to configure NVMeTM/FC, see Configuring NVMe over fabrics using NVMe/FC . When using NVMe over fabrics, the solid-state drive does not have to be local to your system; it can be configured remotely through a NVMe over fabrics devices.

Commands:
5.2.31. /proc/version This file specifies the version of the Linux kernel and gcc in use, as well as the version of Red Hat Enterprise Linux installed on the system: This information is used for a variety of purposes, including the version data presented when a user logs in.

Commands:
Linux version 2.6.8-1.523 (user@foo.redhat.com) (gcc version 3.4.1 20040714 (Red Hat Enterprise Linux 3.4.1-7)) #1 Mon Aug 16 13:27:03 EDT 2004
24.2. Managing Certificates Issued by External CAs 24.2.1. Command Line: Adding and Removing Certificates Issued by External CAs To add a certificate to a user, host, or service: ipa user-add-cert ipa host-add-cert ipa service-add-cert To remove a certificate from a user, host, or service: ipa user-remove-cert ipa host-remove-cert ipa service-remove-cert A certificate issued by an external CA is not revoked after you remove it from IdM. This is because the certificate does not exist in the IdM CA database. You can only revoke these certificates manually from the external CA side. The commands require you to specify the following information: the name of the user, host, or service the Base64-encoded DER certificate To run the commands interactively, execute them without adding any options. To provide the required information directly with the command, use command-line arguments and options: Note Instead of copying and pasting the certificate contents into the command line, you can convert the certificate to the DER format and then re-encode it to base64. For example, to add the user_cert.pem certificate to user : 24.2.2. Web UI: Adding and Removing Certificates Issued by External CAs To add a certificate to a user, host, or service: Open the Identity tab, and select the Users , Hosts , or Services subtab. Click on the name of the user, host, or service to open its configuration page. Click Add , to the Certificates entry. Figure 24.4. Adding a Certificate to a User Account Paste the certificate in Base64 or PEM encoded format into the text field, and click Add . Click Save to store the changes. To remove a certificate from a user, host, or service: Open the Identity tab, and select the Users , Hosts , or Services subtab. Click on the name of the user, host, or service to open its configuration page. Click the Actions to the certificate to delete, and select Delete . Click Save to store the changes.

Commands:
ipa user-add-cert user --certificate= MIQTPrajQAwg
ipa user-add-cert user --certificate="USD(openssl x509 -outform der -in user_cert.pem | base64 -w 0)"
12.4. Methods 12.4.1. Creating a Storage Domain Creation of a new storage domain requires the name , type , host and storage elements. Identify the host element with the id attribute or name element. You can enable the wipe after delete option by default on the storage domain by specifying <wipe_after_delete> in the POST request. This option can be edited after the domain is created, but doing so will not change the wipe after delete property of disks that already exist. Example 12.3. Creating a storage domain The API user attaches the storage domain to a data center after creation. 12.4.2. Updating a Storage Domain Only the name and wipe after delete elements are updatable post-creation. Changing the wipe after delete element will not change the wipe after delete property of disks that already exist. Example 12.4. Updating a storage domain 12.4.3. Removing a Storage Domain Removal of a storage domain requires a DELETE request. Example 12.5. Removing a storage domain

Commands:
POST /ovirt-engine/api/storagedomains HTTP/1.1 Accept: application/xml Content-type: application/xml <storage_domain> <name>data1</name> <type>data</type> <host id="2ab5e1da-b726-4274-bbf7-0a42b16a0fc3"/> <storage> <type>nfs</type> <address>172.31.0.6</address> <path>/exports/RHEVX/images/0</path> </storage> </storage_domain>
PUT /ovirt-engine/api/storagedomains HTTP/1.1 Accept: application/xml Content-type: application/xml <storage_domain> <name>data2</name> <wipe_after_delete>true</wipe_after_delete> </storage_domain>
DELETE /ovirt-engine/api/storagedomains/fabe0451-701f-4235-8f7e-e20e458819ed HTTP/1.1 HTTP/1.1 204 No Content
Providing feedback on Red Hat Ceph Storage documentation We appreciate your input on our documentation. Please let us know how we could make it better. To do so, create a Bugzilla ticket: + . Go to the Bugzilla website. . In the Component drop-down, select Documentation . . In the Sub-Component drop-down, select the appropriate sub-component. . Select the appropriate version of the document. . Fill in the Summary and Description field with your suggestion for improvement. Include a link to the relevant part(s) of documentation. . Optional: Add an attachment, if any. . Click Submit Bug .

Commands:
15.3. Mounting, Unmounting and Ejecting In virtual file systems, particular resources are set to be mounted automatically, but a most common way is to trigger mounts manually. Procedure 15.1. Manual Mounting Open a file in Nautilus (that is, the Files application). In the location bar at the top of your screen, enter a well-formed URI string. If the location bar does not display, press Ctrl + L . Alternatively, Nautilus provides Connect to server dialog, which you find by going into Files Connect to server . When asked for login credentials, type your name and password into the relevant entry boxes. Once the mounting process is finished, your are allowed to work with files. When you need to unmount the resource, follow the simple procedure below. Procedure 15.2. Unmounting Click the eject icon on the chosen mount. Wait until the mount disappears or notification about safe removal is displayed. Important Data may be cached or being slowly written in the background for performance reasons. To deliver the data safely on the device or remote resource, never unplug or disconnect the device or remote resource. Mounts are shared between applications and are tracked globally within the running desktop session, which means that even if you quit an application that triggered the mount, it continues to be available for any other application. The same way multiple applications may access the mount at the same time, unless it was limited by a back end (some protocols permit only single channel due to their design). Important GVFS mounts, (and physical volumes as well, are restricted to their owner only, no other user is permitted to exploit your privacy.

Commands:
3.3.3. Configuring the iptables Firewall to Allow Cluster Components Listed below are example iptable rules for enabling IP ports needed by Red Hat Enterprise Linux 6 (with High Availability Add-on). Please note that these examples use 192.168.1.0/24 as a subnet, but you will need to replace 192.168.1.0/24 with the appropriate subnet if you use these rules. For cman (Cluster Manager), use the following filtering. For dlm (Distributed Lock Manager): For ricci (part of Conga remote agent): For modclusterd (part of Conga remote agent): For luci (Conga User Interface server): For igmp (Internet Group Management Protocol): After executing these commands, enter the following command to save the current configuration for the changes to be persistent during reboot.

Commands:
iptables -I INPUT -m state --state NEW -m multiport -p udp -s 192.168.1.0/24 -d 192.168.1.0/24 --dports 5404,5405 -j ACCEPT iptables -I INPUT -m addrtype --dst-type MULTICAST -m state --state NEW -m multiport -p udp -s 192.168.1.0/24 --dports 5404,5405 -j ACCEPT
iptables -I INPUT -m state --state NEW -p tcp -s 192.168.1.0/24 -d 192.168.1.0/24 --dport 21064 -j ACCEPT
iptables -I INPUT -m state --state NEW -p tcp -s 192.168.1.0/24 -d 192.168.1.0/24 --dport 11111 -j ACCEPT
iptables -I INPUT -m state --state NEW -p tcp -s 192.168.1.0/24 -d 192.168.1.0/24 --dport 16851 -j ACCEPT
iptables -I INPUT -m state --state NEW -p tcp -s 192.168.1.0/24 -d 192.168.1.0/24 --dport 8084 -j ACCEPT
iptables -I INPUT -p igmp -j ACCEPT
service iptables save ; service iptables restart
8.3. Configure Replication Mode (Remote Client-Server Mode) Replication mode is a clustered cache mode in Red Hat JBoss Data Grid. Replication mode can be added to any cache container using the following procedure. Procedure 8.1. The replicated-cache Element Important JGroups must be appropriately configured for clustered mode before attempting to load this configuration. The replicated-cache element configures settings for the distributed cache using the following parameters: The name parameter provides a unique identifier for the cache. The mode parameter sets the clustered cache mode. Valid values are SYNC (synchronous) and ASYNC (asynchronous). The start parameter specifies whether the cache starts when the server starts up or when it is requested or deployed. If statistics are enabled at the container level, per-cache statistics can be selectively disabled for caches that do not require monitoring by setting the statistics attribute to false . The transaction element sets up the transaction mode for the replicated cache. Important In Remote Client-Server mode, the transactions element is set to NONE unless JBoss Data Grid is used in a compatibility mode where the cluster contains both JBoss Data Grid server and library instances. In this case, if transactions are configured in the library mode instance, they must also be configured in the server instance. For details about the cache-container and locking , see the appropriate chapter. Report a bug

Commands:
<cache-container name="clustered" default-cache="default" statistics="true"> <transport executor="infinispan-transport" lock-timeout="60000"/> <replicated-cache name="default" mode="SYNC" start="EAGER" statistics="true"> <transaction mode="NONE" /> </replicated-cache> </cache-container>
12.4. Detaching an Assigned PCI Device When a host PCI device has been assigned to a guest machine, the host can no longer use the device. Read this section to learn how to detach the device from the guest with virsh or virt-manager so it is available for host use. Procedure 12.6. Detaching a PCI device from a guest with virsh Detach the device Use the following command to detach the PCI device from the guest by removing it in the guest's XML file: Re-attach the device to the host (optional) If the device is in managed mode, skip this step. The device will be returned to the host automatically. If the device is not using managed mode, use the following command to re-attach the PCI device to the host machine: For example, to re-attach the pci_0000_01_00_0 device to the host: The device is now available for host use. Procedure 12.7. Detaching a PCI Device from a guest with virt-manager Open the virtual hardware details screen In virt-manager , double-click on the virtual machine that contains the device. Select the Show virtual hardware details button to display a list of virtual hardware. Figure 12.4. The virtual hardware details button Select and remove the device Select the PCI device to be detached from the list of virtual devices in the left panel. Figure 12.5. Selecting the PCI device to be detached Click the Remove button to confirm. The device is now available for host use.

Commands:
virsh detach-device name_of_guest file.xml
virsh nodedev-reattach device
virsh nodedev-reattach pci_0000_01_00_0
4.346. wpa_supplicant 4.346.1. RHEA-2011:1611 - wpa_supplicant enhancement update An enhanced wpa_supplicant package that adds an enhancement is now available for Red Hat Enterprise Linux 6. The wpa_supplicant package contains a WPA (Wi-Fi Protected Access) Supplicant utility for Linux, BSD, and Windows with support for WPA and WPA2 (IEEE 802.11i/RSN). The supplicant is a IEEE 802.1X/WPA component that is used in client workstations. It implements key negotiation with a WPA Authenticator and it controls the roaming and IEEE 802.11 authentication/association of the wlan driver. The wpa_supplicant package has been upgraded to upstream version 0.7.3. This update provides the nl80211 driver and background scanning functionality that are required for efficient connections to RSA token-based WiFi networks. (BZ# 713280 ) Users that require roaming in RSA token-based WiFi networks are advised to upgrade to this updated package, which adds this enhancement.

Commands:
10.7. VLAN on Bond and Bridge Using the NetworkManager Command Line Tool, nmcli To use VLANs over bonds and bridges, proceed as follows: Add a bond device: Note that in this case a bond connection serves only as a "lower interface" for VLAN, and does not get any IP address. Therefore, the ipv4.method disabled and ipv6.method ignore parameters have been added on the command line. Add ports to the bond device: Add a bridge device: Add a VLAN interface on top of bond, assigned to the bridge device: View the created connections:

Commands:
~]USD nmcli connection add type bond con-name Bond0 ifname bond0 bond.options "mode=active-backup,miimon=100" ipv4.method disabled ipv6.method ignore
~]USD nmcli connection add type ethernet con-name Slave1 ifname em1 master bond0 slave-type bond ~]USD nmcli connection add type ethernet con-name Slave2 ifname em2 master bond0 slave-type bond
~]USD nmcli connection add type bridge con-name Bridge0 ifname br0 ipv4.method manual ipv4.addresses 192.0.2.1/24
~]USD nmcli connection add type vlan con-name Vlan2 ifname bond0.2 dev bond0 id 2 master br0 slave-type bridge
~]USD nmcli connection show NAME UUID TYPE DEVICE Bond0 f05806fa-72c3-4803-8743-2377f0c10bed bond bond0 Bridge0 22d3c0de-d79a-4779-80eb-10718c2bed61 bridge br0 Slave1 e59e13cb-d749-4df2-aee6-de3bfaec698c 802-3-ethernet em1 Slave2 25361a76-6b3c-4ae5-9073-005be5ab8b1c 802-3-ethernet em2 Vlan2 e2333426-eea4-4f5d-a589-336f032ec822 vlan bond0.2
Chapter 165. IPFS Component Available as of Camel version 2.23 The ipfs: component provides access to the Interplanetary File System (IPFS) . Maven users will need to add the following dependency to their pom.xml for this component: <dependency> <groupId>org.apache.camel</groupId> <artifactId>camel-ipfs</artifactId> <version>x.x.x</version> <!-- use the same version as your Camel core version --> </dependency> 165.1. URI format ipfs://cmd?options 165.2. Options The IPFS component has no options. The IPFS endpoint is configured using URI syntax: with the following path and query parameters: 165.2.1. Path Parameters (1 parameters): Name Description Default Type ipfsCmd The ipfs command String 165.2.2. Query Parameters (2 parameters): Name Description Default Type outdir (producer) The ipfs output directory Path synchronous (advanced) Sets whether synchronous processing should be strictly used, or Camel is allowed to use asynchronous processing (if supported). false boolean 165.3. Spring Boot Auto-Configuration The component supports 2 options, which are listed below. Name Description Default Type camel.component.ipfs.enabled Whether to enable auto configuration of the ipfs component. This is enabled by default. Boolean camel.component.ipfs.resolve-property-placeholders Whether the component should resolve property placeholders on itself when starting. Only properties which are of String type can use property placeholders. true Boolean 165.4. Karaf support Actually this component is not supported in Karaf 165.5. Message Headers <TODO> <title>Samples</title> In this sample we add a file to IPFS, get a file from IPFS and finally access the content of an IPFS file. from("direct:start").to("ipfs:add") from("direct:start").to("ipfs:get?outdir=target") from("direct:start").to("ipfs:cat"); </TODO>

Commands:
<dependency> <groupId>org.apache.camel</groupId> <artifactId>camel-ipfs</artifactId> <version>x.x.x</version> <!-- use the same version as your Camel core version --> </dependency>
ipfs://cmd?options
ipfs:host:port/cmd
from("direct:start").to("ipfs:add") from("direct:start").to("ipfs:get?outdir=target") from("direct:start").to("ipfs:cat");
Chapter 4. Advisories related to this release The following advisories are issued to document bug fixes and CVE fixes included in this release: RHSA-2024:0222 RHSA-2024:0223 RHSA-2024:0224 RHSA-2024:0225 RHSA-2024:0226 RHSA-2024:0228 RHSA-2024:0230 RHSA-2024:0265 Revised on 2024-05-10 09:06:33 UTC

Commands:
2.8. Additional Resources man(1) man page - Describes man pages and how to find them. NetworkManager(8) man page - Describes the network management daemon. NetworkManager.conf(5) man page - Describes the NetworkManager configuration file. /usr/share/doc/initscripts- version /sysconfig.txt - Describes ifcfg configuration files and their directives as understood by the legacy network service. /usr/share/doc/initscripts- version /examples/networking/ - A directory containing example configuration files. ifcfg(8) man page - Describes briefly the ifcfg command.

Commands:
19.4. mount Command References The following resources provide an in-depth documentation on the subject. Manual Page Documentation man 8 mount : The manual page for the mount command that provides a full documentation on its usage. man 8 umount : The manual page for the umount command that provides a full documentation on its usage. man 8 findmnt : The manual page for the findmnt command that provides a full documentation on its usage. man 5 fstab : The manual page providing a thorough description of the /etc/fstab file format. Useful Websites Shared subtrees - An LWN article covering the concept of shared subtrees.

Commands: