mtpti5iD/redhat-docs_dataset huggingface dataset:
10.4. Setting a Limit on 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. Note that if a device matches none of the filter rules, the redirection will not be allowed. Example 10.1. 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 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-viewer to connect to the guest virtual machine. Click USB device selection 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 host physical 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>
C.2. Tracepoints The tracepoints can be found under /sys/kernel/debug/tracing/ directory assuming that debugfs is mounted in the standard place at the /sys/kernel/debug directory. The events subdirectory contains all the tracing events that may be specified and, provided the gfs2 module is loaded, there will be a gfs2 subdirectory containing further subdirectories, one for each GFS2 event. The contents of the /sys/kernel/debug/tracing/events/gfs2 directory should look roughly like the following: To enable all the GFS2 tracepoints, enter the following command: To enable a specific tracepoint, there is an enable file in each of the individual event subdirectories. The same is true of the filter file which can be used to set an event filter for each event or set of events. The meaning of the individual events is explained in more detail below. The output from the tracepoints is available in ASCII or binary format. This appendix does not currently cover the binary interface. The ASCII interface is available in two ways. To list the current content of the ring buffer, you can enter the following command: This interface is useful in cases where you are using a long-running process for a certain period of time and, after some event, want to look back at the latest captured information in the buffer. An alternative interface, /sys/kernel/debug/tracing/trace_pipe , can be used when all the output is required. Events are read from this file as they occur; there is no historical information available through this interface. The format of the output is the same from both interfaces and is described for each of the GFS2 events in the later sections of this appendix. A utility called trace-cmd is available for reading tracepoint data. For more information on this utility, see the link in Section C.10, "References" . The trace-cmd utility can be used in a similar way to the strace utility, for example to run a command while gathering trace data from various sources.

Commands:
ls enable gfs2_bmap gfs2_glock_queue gfs2_log_flush filter gfs2_demote_rq gfs2_glock_state_change gfs2_pin gfs2_block_alloc gfs2_glock_put gfs2_log_blocks gfs2_promote
echo -n 1 >/sys/kernel/debug/tracing/events/gfs2/enable
cat /sys/kernel/debug/tracing/trace
5.28. clustermon 5.28.1. RHBA-2012:0750 - clustermon bug fix update Updated clustermon packages that fix several bugs are now available for Red Hat Enterprise Linux 6. The clustermon packages are used for remote cluster management. The modclusterd service provides an abstraction of cluster status used by conga and by the Simple Network Management (SNMP) and Common Information Model (CIM) modules of clustermon. Bug Fixes BZ# 742431 Prior to this update, under certain circumstances, outgoing queues in inter-node communication of the modclusterd service could grow over time. To prevent this behavior, the inter-node communication is now better balanced and queues are restricted in size. Forced queue interventions are logged in the /var/log/clumond.log file. BZ# 794907 When the clustermon utility was used to get the cluster schema from the server, the schema was returned in an invalid format, preventing further processing. This bug has been fixed and clustermon now provides an exact copy of the schema in the described scenario. All users of clustermon are advised to upgrade to these updated packages, which fix these bugs.

Commands:
Chapter 21. Browsing messages Overview A key tool in debugging applications in a distributed environment is seeing all of the messages stored in the JMS destinations and route endpoints in the application. The tooling can browse the following: JMS destinations JMS routing endpoints Apache Camel routing endpoints SEDA routing endpoints Browse routing endpoints Mock routing endpoints VM routing endpoints DataSet routing endpoints Procedure To browse messages: In the JMX Navigator view, select the JMS destination or endpoint you want to browse. The list of messages appears in the Messages View . In the Messages View , select an individual message to inspect. Message details and content are displayed in the Properties view: Related topics Section 22.3, "Tracing messages through a routing context"

Commands:
Chapter 1. Shenandoah garbage collector Shenandoah is the low pause time garbage collector (GC) that reduces GC pause times by performing more garbage collection work concurrently with the running Java program. Concurrent Mark Sweep garbage collector (CMS) and G1, default garbage collector for Red Hat build of OpenJDK 17 perform concurrent marking of live objects. Shenandoah adds concurrent compaction. Shenandoah also reduces GC pause times by compacting objects concurrently with running Java threads. Pause times with Shenandoah are independent of the heap size, meaning you will have consistent pause time whether your heap is 200 MB or 200 GB. Shenandoah is an algorithm for applications which require responsiveness and predictable short pauses. Additional resources For more information about the Shenandoah garbage collector, see Shenandoah GC in the Oracle OpenJDK documentation.

Commands:
Chapter 9. Constraints A constraint is a boolean expression that is evaluated when an element containing a constraint is executed. You can use constraints in various parts of your process, such as in a diverging gateway. Red Hat Process Automation Manager supports two types of constraints, including: Code constraints : Constraints that are defined in Java, Javascript, Drools, or MVEL. Code constraints can access the data in the working memory, including the global and process variables. The following code constraint examples contain person as a variable in a process: Example Java code constraint Example MVEL code constraint Example Javascript code constraint Rule constraints : Constraints that are defined in the form of DRL rule conditions. Rule constraints can access the data in the working memory, including global variables. However, rule constraints cannot access the variables directly in a process but using a process instance. To retrieve the reference of the parent process instance, use the processInstance variable of the type WorkflowProcessInstance . Note You can insert a process instance into the session and update it if necessary, for example, using Java code or an on-entry, on-exit, or explicit action in your process. The following example shows a rule constraint, searching for a person with the same name as the value of the name variable in the process. Example rule constraint with process variable assignment

Commands:
return person.getAge() > 20;
return person.age > 20;
person.age > 20
processInstance : WorkflowProcessInstance() Person( name == ( processInstance.getVariable("name") ) ) add more constraints here
Chapter 5. Fixed issues The Cryostat release might include fixes for issues that were identified in earlier releases of Cryostat. Review each fixed issue note for a description of the issue and the subsequent fix. Issues fixed in Cryostat 2.2.1 The following issues have been fixed in Cryostat 2.2.1 release: Successful authentication of JMX session Before Cryostat 2.2.1, the JMX authentication connection failed when you attempted to connect Cryostat to a target JVM application over JMX, and you specified JMX credentials over the X-JMX-Authorization header. With this update, the JMX authentication connection failure issue is resolved, so that you can connect Cryostat to a target JVM application over JMX. Deployment recreation is applied with configuration changes Before Cryostat 2.2.1, Cryostat failed to perform a rolling update on itself in response to changes made to its configuration. This issue existed because of a conflict on a lock file in the new JMX credentials database. With this update, Cryostat does not attempt a rolling update but instead recreates its deployments in response to changes made to its configuration. Issues fixed in Cryostat 2.2.0 The following issues have been fixed in Cryostat 2.2.0 release: Automated analysis report results Before Cryostat 2.2.0, Cryostat did not update analysis reports to reflect a stopped JFR recording. The following sequence of steps demonstrates how you could reach this behavior in a version of Cryostat: Start a JFR recording. Generate an analysis report. Stop the JFR recording. View the latest generated analysis report. The latest generated report would show results of a snapshot from the last active recording and not the stopped recording. Cryostat does not cache a copy of the report based on the stopped recording's data, so you can only view a report from the last active recording snapshot. Cryostat 2.2.0 fixes this issue by generating a report on data cached from the stopped JFR recording. Fixed access issue with the Create recording button After Cryostat loses a connection with a target JVM and then re-establishes this connection, Cryostat no longer either blocks your access to the Create button in the Recordings menu or outputs a 500 NoRouteToHost error message. Revised on 2022-12-23 11:20:09 UTC

Commands:
4.2. Red Hat Gluster Storage and Red Hat Enterprise Virtualization Integration All images in data center displayed regardless of context In the case that the Red Hat Gluster Storage server nodes and the Red Hat Enterprise Virtualization Hypervisors are present in the same data center, the servers of both types are listed for selection when you create a virtual machine or add a storage domain. Red Hat recommends that you create a separate data center for the Red Hat Gluster Storage server nodes.

Commands:
Chapter 12. Fixed issues in Red Hat Decision Manager 7.13.3 Red Hat Decision Manager 7.13.3 provides increased stability and fixed issues listed in this section. 12.1. Business Central Dashbuilder does not support the type MILLISECOND [ RHPAM-4659 ] An exception occurs while using expressions with the USD character in BRL condition in GDST [ RHDM-1938 ] 12.2. Red Hat build of Kogito BPMN files contaning (Java) ServiceTask created using VSCode BPMN Editor causes parser errors in maven build [ RHPAM-4604 ] 12.3. DMN Designer [GSS](7.13.3) DMN extend rule to catch non-normalized named elements [ RHDM-1957 ] 12.4. Red Hat OpenShift Container Platform Red Hat Decision Manager Kogito Operator 7.x installation is failing with OOMKilled and CrashLoopBackOff [ RHPAM-4629 ] 12.5. Decision engine NullPointerException in mvel MathProcessor with equality check when null property is on right side [ RHPAM-4642 ] executable-model fails with BigDecimal arithmetic when it's a scope of a method call [ RHDM-1966 ] The str operator with bind variable fails after mvel jitting [ RHDM-1965 ] The executable model build fails when setting negative BigDecimal literal value [ RHDM-1959 ]

Commands:
Appendix B. Enabling the Launch Instance Wizard There are two methods that you can use to launch instances from the dashboard: The Launch Instance form The Launch Instance wizard The Launch Instance form is enabled by default, but you can enable the Launch Instance wizard at any time. You can also enable both the Launch Instance form and the Launch Instance wizard at the same time. The Launch Instance wizard simplifies the steps required to create instances. Edit /etc/openstack-dashboard/local_settings file, and add the following values: Restart the httpd service: The preferences for the Launch Instance form and Launch Instance wizard are updated. If you enabled only one of these options, the Launch Instance button in the dashboard opens that option by default. If you enabled both options, two Launch Instance buttons are displayed in the dashboard, with the button on the left opening the Launch Instance wizard and the button on the right opening the Launch Instance form.

Commands:
LAUNCH_INSTANCE_LEGACY_ENABLED = False LAUNCH_INSTANCE_NG_ENABLED = True
systemctl restart httpd
Chapter 1. Red Hat build of OpenJDK 11 overview OpenJDK (Open Java Development Kit) is a free and open source implementation of the Java Platform, Standard Edition (Java SE). The Red Hat build of OpenJDK is available in three versions: 8u, 11u, and 17u. Packages for the Red Hat build of OpenJDK are made available on Red Hat Enterprise Linux and Microsoft Windows and shipped as a JDK and JRE in the Red Hat Ecosystem Catalog.

Commands:
Chapter 7. Adding additional storage to your instance Some cloud instances do not have enough storage for the RHEL AI end-to-end workflow in the default disk. You can add a directory that holds additional data. 7.1. Adding a data storage directory to your instance By default RHEL AI holds configuration data in the USDHOME directory. You can change this default to a different directory for holding InstructLab data. Prerequisites You have a Red Hat Enterprise Linux AI instance You added an extra storage disk to your instance Procedure You can configure the ILAB_HOME environment variable by writing it to the USDHOME/.bash_profile file by running the following commands: USD echo 'export ILAB_HOME=/mnt' >> USDHOME/.bash_profile You can make that change effective by reloading the USDHOME/.bash_profile file with the following command: USD source USDHOME/.bash_profile

Commands:
echo 'export ILAB_HOME=/mnt' >> USDHOME/.bash_profile
source USDHOME/.bash_profile
7.8.2. Duplicate Warnings for Single Paths The following example shows a duplicate PV warning in which the duplicate devices displayed are both single paths to the same device. In this case, both /dev/sdd and /dev/sdf can be found under the same multipath map in the output to the multipath -ll command. To prevent this warning from appearing, you can configure a filter in the /etc/lvm/lvm.conf file to restrict the devices that LVM will search for metadata. The filter is a list of patterns that will be applied to each device found by a scan of /dev (or the directory specified by the dir keyword in the /etc/lvm/lvm.conf file). Patterns are regular expressions delimited by any character and preceded by a (for accept) or r (for reject). The list is traversed in order, and the first regex that matches a device determines if the device will be accepted or rejected (ignored). Devices that don't match any patterns are accepted. For general information on LVM filters, see Section 5.5, "Controlling LVM Device Scans with Filters" . The filter you configure should include all devices that need to be checked for LVM metadata, such as the local hard drive with the root volume group on it and any multipathed devices. By rejecting the underlying paths to a multipath device (such as /dev/sdb , /dev/sdd , and so on) you can avoid these duplicate PV warnings, since each unique metadata area will only be found once on the multipath device itself. The following examples show filters that will avoid duplicate PV warnings due to multiple storage paths being available. This filter accepts the second partition on the first hard drive ( /dev/sda and any device-mapper-multipath devices, while rejecting everything else. This filter accepts all HP SmartArray controllers and any EMC PowerPath devices. This filter accepts any partitions on the first IDE drive and any multipath devices. Note When adding a new filter to the /etc/lvm/lvm.conf file, ensure that the original filter is either commented out with a # or is removed. Once a filter has been configured and the /etc/lvm/lvm.conf file has been saved, check the output of these commands to ensure that no physical volumes or volume groups are missing. You can also test a filter on the fly, without modifying the /etc/lvm/lvm.conf file, by adding the --config argument to the LVM command, as in the following example. Note Testing filters using the --config argument will not make permanent changes to the server's configuration. Make sure to include the working filter in the /etc/lvm/lvm.conf file after testing. After configuring an LVM filter, it is recommended that you rebuild the initrd device with the dracut command so that only the necessary devices are scanned upon reboot.

Commands:
Found duplicate PV GDjTZf7Y03GJHjteqOwrye2dcSCjdaUi: using **/dev/sdd** not **/dev/sdf**
filter = [ "a|/dev/sda2USD|", "a|/dev/mapper/mpath.*|", "r|.*|" ]
filter = [ "a|/dev/cciss/.*|", "a|/dev/emcpower.*|", "r|.*|" ]
filter = [ "a|/dev/hda.*|", "a|/dev/mapper/mpath.*|", "r|.*|" ]
pvscan vgscan
lvs --config 'devices{ filter = [ "a|/dev/emcpower.*|", "r|.*|" ] }'
5.4. The Referential Integrity Update Interval By default, the server performs Referential Integrity updates immediately after a delete or rename operation. Depending on the amount of operations, this can cause a performance impact. To reduce the performance impact, you can increase the amount of time between updates. You can set the update interval in seconds. Alternatively, you can set the following values: 0 : The check for referential integrity is performed immediately. -1 : No check for referential integrity is performed. Important In multi-supplier replication environment, Red Hat recommends setting the update interval to 0 on all suppliers. Note On a supplier, if you set the interval to a value greater than 0 (for example, 5) there is a chance that the supplier receives a direct delete or rename operation, replicate the operation, and go offline before it cleans up the references to the target entry. In such cases, the rest of the topology still contains references to the target entry until the server is up again (possibly longer than 5 sec). 5.4.1. Displaying the Update Interval Using the Command Line To display the update interval using the command line to: 5.4.2. Displaying the Update Interval Using the Web Console To display the update interval using the web console: Open the Directory Server user interface in the web console. See Section 1.4, "Logging Into Directory Server Using the Web Console" . Select the instance. Open the Plugins menu. Select the Referential Integrity plug-in. See the Update Delay field for the update interval. 5.4.3. Modifying the Update Interval Using the Command Line To set the update interval using the command line to, for example, to update immediately: Set the update interval to 0 : Restart the instance: 5.4.4. Modifying the Update Interval Using the Web Console To set the update interval using the web console, for example, to update immediately: Open the Directory Server user interface in the web console. See Section 1.4, "Logging Into Directory Server Using the Web Console" . Select the instance. Open the Plugins menu. Select the Referential Integrity plug-in. Set the interval in the Update Delay field. Press Save Config . Restart the instance. See Section 1.5.2, "Starting and Stopping a Directory Server Instance Using the Web Console" .

Commands:
dsconf -D "cn=Directory Manager" ldap://server.example.com plugin referential-integrity show referint-update-delay: 0
dsconf -D "cn=Directory Manager" ldap://server.example.com plugin referential-integrity set --update-delay=0
dsctl instance_name restart
Chapter 88. Configuring a logging utility in the decision engine The decision engine uses the Java logging API SLF4J for system logging. You can use one of the following logging utilities with the decision engine to investigate decision engine activity, such as for troubleshooting or data gathering: Logback Apache Commons Logging Apache Log4j java.util.logging package Procedure For the logging utility that you want to use, add the relevant dependency to your Maven project or save the relevant XML configuration file in the org.drools package of your Red Hat Decision Manager distribution: Example Maven dependency for Logback <dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-classic</artifactId> <version>USD{logback.version}</version> </dependency> Example logback.xml configuration file in org.drools package <configuration> <logger name="org.drools" level="debug"/> ... <configuration> Example log4j.xml configuration file in org.drools package <log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/"> <category name="org.drools"> <priority value="debug" /> </category> ... </log4j:configuration> Note If you are developing for an ultra light environment, use the slf4j-nop or slf4j-simple logger.

Commands:
<dependency> <groupId>ch.qos.logback</groupId> <artifactId>logback-classic</artifactId> <version>USD{logback.version}</version> </dependency>
<configuration> <logger name="org.drools" level="debug"/> <configuration>
<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/"> <category name="org.drools"> <priority value="debug" /> </category> </log4j:configuration>
Chapter 15. Messaging Parameters You can modify the message queue service with messaging parameters. Parameter Description RpcCertificateKeySize Override the private key size used when creating the certificate for this service. RpcPassword The password for messaging backend. RpcPort The network port for messaging backend. The default value is 5672 . RpcUserName The username for messaging backend. The default value is guest . RpcUseSSL Messaging client subscriber parameter to specify an SSL connection to the messaging host. The default value is False .

Commands:
Chapter 25. Viewing the history log of a process instance You can view the history log of a process instance in Business Central from its Logs tab. The log lists all the events in the Date Time: Event Node Type: Event Type format. You can filter the logs based on Event Node Type and Event Type . You can also view the details of the human nodes in the logs. Procedure In Business Central, go to Menu Manage Process Instances . On the Process Instances page, click the process instance whose log you want to view. On the instance page, click the Logs tab. Select the required check boxes from Event Node Type and Event Type pane to filter the log as per your need. To view additional information regarding human nodes, expand Details . Click Reset to revert to the default filter selection. All events that occur in a process instance life cycle are listed in the Logs tab.

Commands: