mtpti5iD/redhat-docs_dataset huggingface dataset:
9.2.2. Setting a Limit on USB Device Redirection To filter out certain devices from redirection, pass the filter property to -device usb-redir . The filter property takes a string consisting of filter rules, the format for a rule is: Use the value -1 to designate it to accept any value for a particular field. You may use multiple rules on the same command line using | as a separator. Important If a device matches none of the rule filters, redirecting it will not be allowed! Example 9.1. An example of limiting redirection with a windows guest virtual machine Prepare a Windows 7 guest virtual machine. Add the following code excerpt to the guest virtual machine's' domain xml file: Start the guest virtual machine and confirm the setting changes by running the following: Plug a USB device into a host physical machine, and use virt-manager to connect to the guest virtual machine. Click Redirect USB Service in the menu, which will produce the following message: "Some USB devices are blocked by host policy". Click OK to confirm and continue. The filter takes effect. To make sure that the filter captures properly check the USB device vendor and product, then make the following changes in the guest virtual machine's domain XML to allow for USB redirection. Restart the guest virtual machine, then use virt-viewer to connect to the guest virtual machine. The USB device will now redirect traffic to the guest virtual machine.

Commands:
<class>:<vendor>:<product>:<version>:<allow>
<redirdev bus='usb' type='spicevmc'> <alias name='redir0'/> <address type='usb' bus='0' port='3'/> </redirdev> <redirfilter> <usbdev class='0x08' vendor='0x1234' product='0xBEEF' version='2.0' allow='yes'/> <usbdev class='-1' vendor='-1' product='-1' version='-1' allow='no'/> </redirfilter>
ps -ef | grep USDguest_name
-device usb-redir,chardev=charredir0,id=redir0, / filter=0x08:0x1234:0xBEEF:0x0200:1|-1:-1:-1:-1:0,bus=usb.0,port=3
<redirfilter> <usbdev class='0x08' vendor='0x0951' product='0x1625' version='2.0' allow='yes'/> <usbdev allow='no'/> </redirfilter>
2.4. GRUB Terminology One of the most important things to understand before using GRUB is how the program refers to devices, such as hard drives and partitions. This information is particularly important when configuring GRUB to boot multiple operating systems. 2.4.1. Device Names When referring to a specific device with GRUB, do so using the following format (note that the parentheses and comma are very important syntactically): ( <type-of-device><bios-device-number> , <partition-number> ) The <type-of-device> specifies the type of device from which GRUB boots. The two most common options are hd for a hard disk or fd for a 3.5 diskette. A lesser used device type is also available called nd for a network disk. Instructions on configuring GRUB to boot over the network are available online at http://www.gnu.org/software/grub/manual/ . The <bios-device-number> is the BIOS device number. The primary IDE hard drive is numbered 0 and a secondary IDE hard drive is numbered 1 . This syntax is roughly equivalent to that used for devices by the kernel. For example, the a in hda for the kernel is analogous to the 0 in hd0 for GRUB, the b in hdb is analogous to the 1 in hd1 , and so on. The <partition-number> specifies the number of a partition on a device. Like the <bios-device-number> , most types of partitions are numbered starting at 0 . However, BSD partitions are specified using letters, with a corresponding to 0 , b corresponding to 1 , and so on. Note The numbering system for devices under GRUB always begins with 0 , not 1 . Failing to make this distinction is one of the most common mistakes made by new users. To give an example, if a system has more than one hard drive, GRUB refers to the first hard drive as (hd0) and the second as (hd1) . Likewise, GRUB refers to the first partition on the first drive as (hd0,0) and the third partition on the second hard drive as (hd1,2) . In general the following rules apply when naming devices and partitions under GRUB: It does not matter if system hard drives are IDE or SCSI, all hard drives begin with the letters hd . The letters fd are used to specify 3.5 diskettes. To specify an entire device without respect to partitions, leave off the comma and the partition number. This is important when telling GRUB to configure the MBR for a particular disk. For example, (hd0) specifies the MBR on the first device and (hd3) specifies the MBR on the fourth device. If a system has multiple drive devices, it is very important to know how the drive boot order is set in the BIOS. This is a simple task if a system has only IDE or SCSI drives, but if there is a mix of devices, it becomes critical that the type of drive with the boot partition be accessed first.

Commands:
10.5. Cluster Services Hang When the cluster services attempt to fence a node, the cluster services stop until the fence operation has successfully completed. Therefore, if your cluster-controlled storage or services hang and the cluster nodes show different views of cluster membership or if your cluster hangs when you try to fence a node and you need to reboot nodes to recover, check for the following conditions: The cluster may have attempted to fence a node and the fence operation may have failed. Look through the /var/log/messages file on all nodes and see if there are any failed fence messages. If so, then reboot the nodes in the cluster and configure fencing correctly. Verify that a network partition did not occur, as described in Section 10.8, "Each Node in a Two-Node Cluster Reports Second Node Down" . and verify that communication between nodes is still possible and that the network is up. If nodes leave the cluster the remaining nodes may be inquorate. The cluster needs to be quorate to operate. If nodes are removed such that the cluster is no longer quorate then services and storage will hang. Either adjust the expected votes or return the required amount of nodes to the cluster. Note You can fence a node manually with the fence_node command or with Conga . For information, see the fence_node man page and Section 5.3.2, "Causing a Node to Leave or Join a Cluster" .

Commands:
Chapter 12. Transactions Subsystem Tuning If your environment uses XA distributed transactions, you can tune the transaction manager's log store for better performance. The default transaction log store uses a simple file store. For XA transactions this type of log store can be inefficient, as it creates one system file for each transaction log. Especially for XA transactions, a journal store is much more efficient as it uses a journal that consists of one file for all transactions. For better XA transaction performance, it is recommended that you use a journal log store. For Red Hat Enterprise Linux systems, you can additionally enable asynchronous I/O (AIO) on the journal store to further improve performance. Note For Red Hat Enterprise Linux systems, if you are enabling asynchronous I/O (AIO) on the journal store, ensure that the libaio package is installed. Enable the Journal Log Store Using the Management Console Navigate to Configuration Subsystems Transaction and click View . In the Configuration tab, click Edit . Set the Use Journal Store field to ON . Optional : For Red Hat Enterprise Linux systems, set the Journal Store Enable Async IO field to ON . Click Save . Enable the Journal Log Store Using the Management CLI To enable the journal log store using the management CLI, use the following command: Optional : For Red Hat Enterprise Linux systems, use the following command to enable journal log store asynchronous I/O:

Commands:
/subsystem=transactions:write-attribute(name=use-journal-store,value=true)
/subsystem=transactions:write-attribute(name=journal-store-enable-async-io, value=true)
Chapter 3. Verifying installation of Fuse on JBoss EAP After installing Fuse on JBoss EAP, verify that the installation was successful. Prerequisites Fuse 7.13 on JBoss EAP 7.4.16 is installed. The JBoss EAP server is running. Procedure Open the following file to check if any error messages have been logged: EAP_HOME/standalone/log/server.log In a browser, open the Fuse Management Console . Sign in by entering the administrator credentials that you created during JBoss EAP installation. Results If the Fuse Management Console runs and you can log in, the Fuse installation was successful.

Commands:
Chapter 5. Uploading a manifest to a host system A system needs a manifest to connect to Red Hat Subscription Management. If you used a subscription allocation to create the manifest, you need to download the manifest first and then upload it to the host system. This situation is useful for systems that are offline or air-gapped. Procedure On the local system, copy the manifest: Import the manifest to your system:

Commands:
scp ~/<manifest_file>.zip satellite.example.com:
hammer subscription upload --file ~/<manifest_file>.zip --organization "ACME"
Appendix D. Cephx configuration options The following are Cephx configuration options that can be set up during deployment. auth_cluster_required Description If enabled, the Red Hat Ceph Storage cluster daemons, ceph-mon and ceph-osd , must authenticate with each other. Valid settings are cephx or none . Type String Required No Default cephx . auth_service_required Description If enabled, the Red Hat Ceph Storage cluster daemons require Ceph clients to authenticate with the Red Hat Ceph Storage cluster in order to access Ceph services. Valid settings are cephx or none . Type String Required No Default cephx . auth_client_required Description If enabled, the Ceph client requires the Red Hat Ceph Storage cluster to authenticate with the Ceph client. Valid settings are cephx or none . Type String Required No Default cephx . keyring Description The path to the keyring file. Type String Required No Default /etc/ceph/USDcluster.USDname.keyring,/etc/ceph/USDcluster.keyring,/etc/ceph/keyring,/etc/ceph/keyring.bin keyfile Description The path to a key file (that is. a file containing only the key). Type String Required No Default None key Description The key (that is, the text string of the key itself). Not recommended. Type String Required No Default None ceph-mon Location USDmon_data/keyring Capabilities mon 'allow *' ceph-osd Location USDosd_data/keyring Capabilities mon 'allow profile osd' osd 'allow *' radosgw Location USDrgw_data/keyring Capabilities mon 'allow rwx' osd 'allow rwx' cephx_require_signatures Description If set to true , Ceph requires signatures on all message traffic between the Ceph client and the Red Hat Ceph Storage cluster, and between daemons comprising the Red Hat Ceph Storage cluster. Type Boolean Required No Default false cephx_cluster_require_signatures Description If set to true , Ceph requires signatures on all message traffic between Ceph daemons comprising the Red Hat Ceph Storage cluster. Type Boolean Required No Default false cephx_service_require_signatures Description If set to true , Ceph requires signatures on all message traffic between Ceph clients and the Red Hat Ceph Storage cluster. Type Boolean Required No Default false cephx_sign_messages Description If the Ceph version supports message signing, Ceph will sign all messages so they cannot be spoofed. Type Boolean Default true auth_service_ticket_ttl Description When the Red Hat Ceph Storage cluster sends a Ceph client a ticket for authentication, the cluster assigns the ticket a time to live. Type Double Default 60*60

Commands:
10.3. The Multi-Source Column When a model is marked as multi-source, the engine will add or use an existing column on each table to represent the source name values. In the above vdb.xml the column would return chicago , la , newyork for each of the respective sources. The name of the column defaults to SOURCE_NAME, but is configurable by setting the model property multisource.columnName . If a column already exists on the table (or an IN procedure parameter) with the same name, the engine will assume that it should represent the multi-source column and it will not be used to retrieve physical data. If the multi-source column is not present, the generated column will be treated as a pseudo column which is not selectable via wildcards (* nor tbl.*). This allows queries like the following:

Commands:
select * from table where SOURCE_NAME = 'newyork' update table column=value where SOURCE_NAME='chicago' delete from table where column = x and SOURCE_NAME='la' insert into table (column, SOURCE_NAME) VALUES ('value', 'newyork')
Chapter 4. Handling interpreter directives in Python scripts In Red Hat Enterprise Linux 9, executable Python scripts are expected to use interpreter directives (also known as hashbangs or shebangs) that explicitly specify at a minimum the major Python version. For example: The /usr/lib/rpm/redhat/brp-mangle-shebangs buildroot policy (BRP) script is run automatically when building any RPM package, and attempts to correct interpreter directives in all executable files. The BRP script generates errors when encountering a Python script with an ambiguous interpreter directive, such as: or 4.1. Modifying interpreter directives in Python scripts Use the following procedure to modify interpreter directives in Python scripts that cause build errors at RPM build time. Prerequisites Some of the interpreter directives in your Python scripts cause a build error. Procedure To modify interpreter directives, complete one of the following tasks: Use the following macro in the %prep section of your SPEC file: SCRIPTNAME can be any file, directory, or a list of files and directories. As a result, all listed files and all .py files in listed directories will have their interpreter directives modified to point to %{python3} . Existing flags from the original interpreter directive will be preserved and additional flags defined in the %{py3_shebang_flags} macro will be added. You can redefine the %{py3_shebang_flags} macro in your SPEC file to change the flags that will be added. Apply the pathfix.py script from the python3-devel package: You can specify multiple paths. If a PATH is a directory, pathfix.py recursively scans for any Python scripts matching the pattern ^[a-zA-Z0-9_]+\.pyUSD , not only those with an ambiguous interpreter directive. Add the command above to the %prep section or at the end of the %install section. Modify the packaged Python scripts so that they conform to the expected format. For this purpose, you can use the pathfix.py script outside the RPM build process, too. When running pathfix.py outside an RPM build, replace %{python3} from the preceding example with a path for the interpreter directive, such as /usr/bin/python3 or /usr/bin/python3.11 . Additional resources Interpreter invocation

Commands:
#!/usr/bin/python3 #!/usr/bin/python3.9 #!/usr/bin/python3.11 #!/usr/bin/python3.12
#!/usr/bin/python
#!/usr/bin/env python
%py3_shebang_fix SCRIPTNAME ...
pathfix.py -pn -i %{python3} PATH ...
Chapter 4. Use Cases This chapter describes two types of use case to illustrate the analysis and configuration methods described elsewhere in this guide. The first example considers typical servers and the second is a typical laptop. 4.1. Example - Server A typical standard server nowadays comes with basically all of the necessary hardware features supported in Red Hat Enterprise Linux 6. The first thing to take into consideration is the kinds of workloads for which the server will mainly be used. Based on this information you can decide which components can be optimized for power savings. Regardless of the type of server, graphics performance is generally not required. Therefore, GPU power savings can be left turned on. Webserver A webserver needs network and disk I/O. Depending on the external connection speed 100 Mbit/s might be enough. If the machine serves mostly static pages, CPU performance might not be very important. Power-management choices might therefore include: no disk or network plugins for tuned . ALPM turned on. ondemand governor turned on. network card limited to 100 Mbit/s. Compute server A compute server mainly needs CPU. Power management choices might include: depending on the jobs and where data storage happens, disk or network plugins for tuned ; or for batch-mode systems, fully active tuned . depending on utilization, perhaps the performance governor. Mailserver A mailserver needs mostly disk I/O and CPU. Power management choices might include: ondemand governor turned on, because the last few percent of CPU performance are not important. no disk or network plugins for tuned . network speed should not be limited, because mail is often internal and can therefore benefit from a 1 Gbit/s or 10 Gbit/s link. Fileserver Fileserver requirements are similar to those of a mailserver, but depending on the protocol used, might require more CPU performance. Typically, Samba-based servers require more CPU than NFS, and NFS typically requires more than iSCSI. Even so, you should be able to use the ondemand governor. Directory server A directory server typically has lower requirements for disk I/O, especially if equipped with enough RAM. Network latency is important although network I/O less so. You might consider latency network tuning with a lower link speed, but you should test this carefully for your particular network.

Commands:
Chapter 1. Accessing the RHOSO cloud You can access your Red Hat OpenStack Services on OpenShift (RHOSO) cloud to perform actions on your data plane by either accessing the OpenStackClient pod through a remote shell from your workstation, or by using a web browser to access the Dashboard service (horizon) interface. 1.1. Accessing the OpenStackClient pod You can execute Red Hat OpenStack Services on OpenShift (RHOSO) commands on the deployed data plane by using the OpenStackClient pod through a remote shell from your workstation. The OpenStack Operator created the OpenStackClient pod as a part of the OpenStackControlPlane resource. The OpenStackClient pod contains the client tools and authentication details that you require to perform actions on your data plane. Prerequisites You are logged on to a workstation that has access to the Red Hat OpenShift Container Platform (RHOCP) cluster as a user with cluster-admin privileges. Procedure Access the remote shell for the OpenStackClient pod: Run your openstack commands. For example, you can create a default network with the following command: Exit the OpenStackClient pod: Additional resources Creating and managing instances Configuring networking services 1.2. Accessing the Dashboard service (horizon) interface You can access the Dashboard service (horizon) interface by providing the Dashboard service endpoint URL in a web browser. Prerequisites The Dashboard service is enabled on the control plane. For information about how to enable the Dashboard service, see Enabling the Dashboard service (horizon) interface in Customizing the Red Hat OpenStack Services on OpenShift deployment . You need to log into the dashboard as the admin user. Procedure Retrieve the admin password from the AdminPassword parameter in the osp-secret secret: Retrieve the Dashboard service endpoint URL: Open a web browser. Enter the Dashboard endpoint URL. Log in to the dashboard by providing the username of admin and the admin password.

Commands:
oc rsh -n openstack openstackclient
openstack network create default
exit
oc get secret osp-secret -o jsonpath='{.data.AdminPassword}' | base64 -d
oc get horizons horizon -o jsonpath='{.status.endpoint}'
Chapter 18. Customizing default favorite applications You can customize frequently used applications as your favorite applications. You can see these favorite applications on the GNOME Shell dash in the Activities overview. You can use dconf to set the favorite applications for an individual user or for all users. 18.1. Setting different favorite applications for individual users You can set the default favorite applications for individual users. Procedure Open the Activities overview by clicking Activities at the top left of the screen. Add applications into your favorite list using any of the following methods: Click the grid button to find the application you want, right-click the application icon, and select Add to Favorites . Click-and-drag the icon into the dash. View all the applications that exists in the favorite list: Note If you want to lock down the above settings to prevent users from changing them, see Locking down selected tasks . 18.2. Setting the same favorite applications for all users You can modify system database files using dconf keyfiles to set the same favorites for all users. The following steps edit the dconf profile and then create a keyfile to set default favorite applications for all users in the local configuration database. Procedure Create the key file /etc/dconf/db/local.d/00-favorite-apps to provide information for the local database. /etc/dconf/db/local.d/00-favorite-apps contents: To prevent users from overriding these settings, create the file /etc/dconf/db/local.d/locks/favorite-apps with the following content: Run the dconf update command to incorporate your changes into the system databases. Logout and login again for system-wide changes to take effect.

Commands:
dconf read /org/gnome/shell/favorite-apps
Snippet sets gedit, terminal and nautilus as default favorites for all users [org/gnome/shell] favorite-apps = ['gedit.desktop', 'gnome-terminal.desktop', 'nautilus.desktop']
Lock default favorite applications /org/gnome/shell/favorite-apps
5.241. php-pecl-memcache 5.241.1. RHBA-2012:0927 - php-pecl-memcache bug fix update Updated php-pecl-memcache packages that fix one bug are now available for Red Hat Enterprise Linux 6. The php-pecl-memcache packages enable PHP scripts to use the memcached caching daemon. Bug Fix BZ# 722418 A bug in memory handling could cause memory corruption when converting a serialized object to a PHP object. Consequently, a PHP script terminated unexpectedly with a segmentation fault. This update corrects the bug so that memory corruption no longer occurs and PHP scripts are now executed successfully. All users of php-pecl-memcache are advised to upgrade to these updated packages, which fix this bug.

Commands: