mtpti5iD/redhat-docs_dataset huggingface dataset:
14.6.5. Sending a Keystroke Combination to a Specified Domain Using the virsh send-key domain --codeset --holdtime keycode command you can send a sequence as a keycode to a specific domain. Each keycode can either be a numeric value or a symbolic name from the corresponding codeset . If multiple keycodes are specified, thay are all sent simultaneously to the guest virtual machine and as such may be received in random order. If you need distinct keycodes, you must send the send-key command multiple times. If a --holdtime is given, each keystroke will be held for the specified amount in milliseconds. The --codeset allows you to specify a code set, the default being Linux, but the following options are permitted: linux - choosing this option causes the symbolic names to match the corresponding Linux key constant macro names and the numeric values are those offered by the Linux generic input event subsystems. xt - this will send a value that is defined by the XT keyboard controller. No symbolic names are provided. atset1 - the numeric values are those that are defined by the AT keyboard controller, set1 (XT compatible set). Extended keycodes from the atset1 may differ from extended keycodes in the XT codeset. No symbolic names are provided. atset2 - The numeric values are those defined by the AT keyboard controller, set 2. No symbolic names are provided. atset3 - The numeric values are those defined by the AT keyboard controller, set 3 (PS/2 compatible). No symbolic names are provided. os_x - The numeric values are those defined by the OS-X keyboard input subsystem. The symbolic names match the corresponding OS-X key constant macro names. xt_kbd - The numeric values are those defined by the Linux KBD device. These are a variant on the original XT codeset, but often with different encoding for extended keycodes. No symbolic names are provided. win32 - The numeric values are those defined by the Win32 keyboard input subsystem. The symbolic names match the corresponding Win32 key constant macro names. usb - The numeric values are those defined by the USB HID specification for keyboard input. No symbolic names are provided. rfb - The numeric values are those defined by the RFB extension for sending raw keycodes. These are a variant on the XT codeset, but extended keycodes have the low bit of the second bite set, instead of the high bit of the first byte. No symbolic names are provided.

Commands:
virsh send-key rhel6 --holdtime 1000 0xf
7.243. sysfsutils 7.243.1. RHBA-2012:1453 - sysfsutils bug fix update Updated sysfsutils packages that fix one bug are now available for Red Hat Enterprise Linux 6. The sysfsutils packages provide a suite of daemons to manage access to remote directories and authentication mechanisms. The sysfsutils suite provides an NSS and PAM interface toward the system and a pluggable backend system to connect to multiple different account sources. It is also the basis to provide client auditing and policy services for projects like FreeIPA. Bug Fix BZ#671554 Prior to this update, sysfs directories were not closed as expected. As a consequence, the libsysfs library could leak memory in long running programs that frequently opened and closed sysfs directories. This update modifies the underlying code to close sysfs directories as expected. All users of sysfsutils are advised to upgrade to these updated packages, which fix this bug.

Commands:
20.16.9.2. Bridge to LAN Note that this is the recommended configuration setting for general guest virtual machine connectivity on host physical machines with static wired networking configurations. Bridge to LAN provides a bridge from the guest virtual machine directly onto the LAN. This assumes there is a bridge device on the host physical machine which has one or more of the host physical machines physical NICs enslaved. The guest virtual machine will have an associated tun device created with a name of <vnetN> , which can also be overridden with the <target> element (refer to Section 20.16.9.11, "Overriding the target element" ). The <tun> device will be enslaved to the bridge. The IP range / network configuration is whatever is used on the LAN. This provides the guest virtual machine full incoming and outgoing net access just like a physical machine. On Linux systems, the bridge device is normally a standard Linux host physical machine bridge. On host physical machines that support Open vSwitch, it is also possible to connect to an open vSwitch bridge device by adding a virtualport type='openvswitch'/ to the interface definition. The Open vSwitch type virtualport accepts two parameters in its parameters element - an interfaceid which is a standard uuid used to uniquely identify this particular interface to Open vSwitch (if you do no specify one, a random interfaceid will be generated for you when you first define the interface), and an optional profileid which is sent to Open vSwitch as the interfaces <port-profile> . To set the bridge to LAN settings, use a management tool that will configure the following part of the domain XML: ... <devices> ... <interface type='bridge'> <source bridge='br0'/> </interface> <interface type='bridge'> <source bridge='br1'/> <target dev='vnet7'/> <mac address="00:11:22:33:44:55"/> </interface> <interface type='bridge'> <source bridge='ovsbr'/> <virtualport type='openvswitch'> <parameters profileid='menial' interfaceid='09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f'/> </virtualport> </interface> ... </devices> Figure 20.37. Devices - network interfaces- bridge to LAN

Commands:
<devices> <interface type='bridge'> <source bridge='br0'/> </interface> <interface type='bridge'> <source bridge='br1'/> <target dev='vnet7'/> <mac address="00:11:22:33:44:55"/> </interface> <interface type='bridge'> <source bridge='ovsbr'/> <virtualport type='openvswitch'> <parameters profileid='menial' interfaceid='09b11c53-8b5c-4eeb-8f00-d84eaa0aaa4f'/> </virtualport> </interface> </devices>
Appendix A. Configuring OpenShift service serving certificates to generate TLS certificates for Keycloak OpenShift's service serving certificate can automate the generation and management of Transport Layer Security (TLS) certificates for use by Keycloak. Infrastructure components, such as the Ingress Controller, within an OpenShift cluster will trust these TLS certificates. Prerequisites Red Hat OpenShift Container Platform version 4.13 or later. Installation of the RHBK operator. Access to the OpenShift web console with the cluster-admin role. Procedure In OpenShift web console, from the Administrator perspective, expand Home from the navigation menu, and click Projects . Search for keycloak , and select the keycloak-system namespace. Create a new service. Click the + icon. In the Import YAML text box, copy the example, and paste it into the text box. Example apiVersion: v1 kind: Service metadata: annotations: service.beta.openshift.io/serving-cert-secret-name: keycloak-tls labels: app: keycloak app.kubernetes.io/instance: keycloak name: keycloak-service-trusted namespace: keycloak-system spec: internalTrafficPolicy: Cluster ipFamilies: - IPv4 ipFamilyPolicy: SingleStack ports: - name: https port: 8443 selector: app: keycloak app.kubernetes.io/instance: keycloak Click the Create button. Expand Operators from the navigation menu, click Installed Operators , and click Keycloak Operator . In the YAML view of the Keycloak resource, under the spec section, add the ingress property: Example spec: ... ingress: annotations: route.openshift.io/destination-ca-certificate-secret: keycloak-tls route.openshift.io/termination: reencrypt ... By default, the Keycloak operator creates Ingress resources instead of routes. OpenShift automatically creates a route based on the Ingress definition. Specify the name of the secret containing the TLS certificate, under the spec section: Example spec: ... http: tlsSecret: keycloak-tls ... Once Keycloak starts, OpenShift's service serving certificate starts generating TLS certificates for Keycloak. Additional resources Securing service traffic using service serving certificate secrets .

Commands:
apiVersion: v1 kind: Service metadata: annotations: service.beta.openshift.io/serving-cert-secret-name: keycloak-tls labels: app: keycloak app.kubernetes.io/instance: keycloak name: keycloak-service-trusted namespace: keycloak-system spec: internalTrafficPolicy: Cluster ipFamilies: - IPv4 ipFamilyPolicy: SingleStack ports: - name: https port: 8443 selector: app: keycloak app.kubernetes.io/instance: keycloak
spec: ingress: annotations: route.openshift.io/destination-ca-certificate-secret: keycloak-tls route.openshift.io/termination: reencrypt
spec: http: tlsSecret: keycloak-tls
3.4. NotifyingFuture The NotifyingFuture interface is being deprecated in JBoss Data Grid 6.6.0 in favor of the standard Java 8 CompletableFuture , and is expected to be removed in JBoss Data Grid 7.0. NotifyingFuture is currently returned by all async methods in both Cache and RemoteCache , and will require applications using these methods to use the new class once available. Report a bug

Commands:
8.3. Snapshot Creation In Red Hat Virtualization the initial snapshot for a virtual machine is different from subsequent snapshots in that the initial snapshot retains its format, either QCOW2 or raw. The first snapshot for a virtual machine uses existing volumes as a base image. Additional snapshots are additional COW layers tracking the changes made to the data stored in the image since the snapshot. As depicted in Figure 8.1, "Initial Snapshot Creation" , the creation of a snapshot causes the volumes that comprise a virtual disk to serve as the base image for all subsequent snapshots. Figure 8.1. Initial Snapshot Creation Snapshots taken after the initial snapshot result in the creation of new COW volumes in which data that is created or changed after the snapshot is taken will be stored. Each newly created COW layer contains only COW metadata. Data that is created by using and operating the virtual machine after a snapshot is taken is written to this new COW layer. When a virtual machine is used to modify data that exists in a COW layer, the data is read from the layer, and written into the newest layer. Virtual machines locate data by checking each COW layer from most recent to oldest, transparently to the virtual machine. Figure 8.2. Additional Snapshot Creation

Commands:
5.16. binutils 5.16.1. RHBA-2012:0872 - binutils bug fix and enhancement update Updated binutils packages that fix two bugs and add two enhancements are now available for Red Hat Enterprise Linux 6. The binutils packages contain a collection of binary utilities, including "ar" (for creating, modifying and extracting from archives), "as" (a family of GNU assemblers), "gprof" (for displaying call graph profile data), "ld" (the GNU linker), "nm" (for listing symbols from object files), "objcopy" (for copying and translating object files), "objdump" (for displaying information from object files), "ranlib" (for generating an index for the contents of an archive), "readelf" (for displaying detailed information about binary files), "size" (for listing the section sizes of an object or archive file), "strings" (for listing printable strings from files), "strip" (for discarding symbols), and "addr2line" (for converting addresses to file and line). Bug Fixes BZ# 676194 Previously, the GNU linker could terminate unexpectedly with a segmentation fault when attempting to link together object files of different architectures (for example, an object file of 32-bit Intel P6 with an object file of Intel 64). This update modifies binutils so that the linker now generates an error message and refuses to link object files in the scenario described. BZ# 809616 When generating build-ID hashes, the GNU linker previously allocated memory for BSS sections. Consequently, the linker could use more memory than was necessary. This update modifies the linker to skip BSS sections and thus avoid unnecessary memory usage when generating build-ID hashes. Enhancements BZ# 739444 With this update, backported patches have been included to support new AMD processors. Also, a duplicate entry for the bextr instruction has been removed from the disassembler's table. BZ# 739144 The GNU linker has been modified in order to improve performance of (TOC) addressability and Procedure Linkage Table (PLT) call stubs on the PowerPC and PowerPC 64 architectures. All users of binutils are advised to upgrade to these updated packages, which fix these bugs and add these enhancements.

Commands:
3.13. Considerations for ricci For Red Hat Enterprise Linux 6, ricci replaces ccsd . Therefore, it is necessary that ricci is running in each cluster node to be able to propagate updated cluster configuration whether it is by means of the cman_tool version -r command, the ccs command, or the luci user interface server. You can start ricci by using service ricci start or by enabling it to start at boot time by means of chkconfig . For information on enabling IP ports for ricci , see Section 3.3.1, "Enabling IP Ports on Cluster Nodes" . For the Red Hat Enterprise Linux 6.1 release and later, using ricci requires a password the first time you propagate updated cluster configuration from any particular node. You set the ricci password as root after you install ricci on your system. To set this password, execute the passwd ricci command, for user ricci .

Commands:
Chapter 2. Configure Red Hat build of OpenJDK 8 in FIPS mode Red Hat build of OpenJDK 8 checks if the FIPS mode is enabled in the system at startup. If yes, it self-configures FIPS according to the global policy. This is the default behavior since RHEL 8.3. RHEL 8 releases require the com.redhat.fips system property set to true as a JVM argument. For example, -Dcom.redhat.fips=true . Note If FIPS mode is enabled in the system while a JVM instance is running, the instance needs to be restarted for changes to take effect. For more information on how to enable FIPS mode, see Switching the system to FIPS mode . You can configure Red Hat build of OpenJDK 8 to bypass the global FIPS alignment. For example, you might want to enable FIPS compliance through a Hardware Security Module (HSM) instead of the scheme provided by Red Hat build of OpenJDK. Following are the FIPS properties for Red Hat build of OpenJDK 8: security.useSystemPropertiesFile Security property located at USDJAVA_HOME/lib/security/java.security or in the file directed to java.security.properties . Privileged access is required to modify the value in the default java.security file. Persistent configuration. When set to false , both the global FIPS and the crypto-policies alignment are disabled. By default, it is set to true . java.security.disableSystemPropertiesFile System property passed to the JVM as an argument. For example, -Djava.security.disableSystemPropertiesFile=true . Non-privileged access is enough. Non-persistent configuration. When set to true , both the global FIPS and the crypto-policies alignment are disabled; generating the same effect than a security.useSystemPropertiesFile=false security property. If both properties are set to different behaviors, java.security.disableSystemPropertiesFile overrides. By default, it is set to false . com.redhat.fips System property passed to a JVM as an argument. For example, -Dcom.redhat.fips=false . Non-privileged access is enough. Non-persistent configuration. When set to false , disables the FIPS alignment while still applying the global crypto-policies. If any of the properties is set to disable the crypto-policies alignment, this property has no effect. In other words, crypto-policies is a prerequisite for FIPS alignment. By default, it is set to true .

Commands:
B.21. firefox B.21.1. RHSA-2010:0861 - Critical: firefox security update Updated firefox packages that fix several security issues are now available for Red Hat Enterprise Linux 6. The Red Hat Security Response Team has rated this update as having critical security impact. Common Vulnerability Scoring System (CVSS) base scores, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) associated with each description below. Mozilla Firefox is an open source web browser. XULRunner provides the XUL Runtime environment for Mozilla Firefox. CVE-2010-3765 A race condition flaw was found in the way Firefox handled Document Object Model (DOM) element properties. Malicious HTML content could cause Firefox to crash or, potentially, execute arbitrary code with the privileges of the user running Firefox. CVE-2010-3175 , CVE-2010-3176 , CVE-2010-3179 , CVE-2010-3183 , CVE-2010-3180 Several flaws were found in the processing of malformed web content. A web page containing malicious content could cause Firefox to crash or, potentially, execute arbitrary code with the privileges of the user running Firefox. CVE-2010-3177 A flaw was found in the way the Gopher parser in Firefox converted text into HTML. A malformed file name on a Gopher server could, when accessed by a victim running Firefox, allow arbitrary JavaScript to be executed in the context of the Gopher domain. CVE-2010-3178 A same-origin policy bypass flaw was found in Firefox. An attacker could create a malicious web page that, when viewed by a victim, could steal private data from a different website the victim had loaded with Firefox. CVE-2010-3182 A flaw was found in the script that launches Firefox. The LD_LIBRARY_PATH variable was appending a "." character, which could allow a local attacker to execute arbitrary code with the privileges of a different user running Firefox, if that user ran Firefox from within an attacker-controlled directory. For technical details regarding these flaws, refer to the Mozilla security advisories for Firefox 3.6.11 and 3.6.12: http://www.mozilla.org/security/known-vulnerabilities/firefox36.html#firefox3.6.11 http://www.mozilla.org/security/known-vulnerabilities/firefox36.html#firefox3.6.12 All Firefox users should upgrade to these updated packages, which contain Firefox version 3.6.12, which corrects these issues. After installing the update, Firefox must be restarted for the changes to take effect.

Commands:
function::register Name function::register - Return the signed value of the named CPU register Synopsis Arguments name Name of the register to return Description Return the value of the named CPU register, as it was saved when the current probe point was hit. If the register is 32 bits, it is sign-extended to 64 bits. For the i386 architecture, the following names are recognized. (name1/name2 indicates that name1 and name2 are alternative names for the same register.) eax/ax, ebp/bp, ebx/bx, ecx/cx, edi/di, edx/dx, eflags/flags, eip/ip, esi/si, esp/sp, orig_eax/orig_ax, xcs/cs, xds/ds, xes/es, xfs/fs, xss/ss. For the x86_64 architecture, the following names are recognized: 64-bit registers: r8, r9, r10, r11, r12, r13, r14, r15, rax/ax, rbp/bp, rbx/bx, rcx/cx, rdi/di, rdx/dx, rip/ip, rsi/si, rsp/sp; 32-bit registers: eax, ebp, ebx, ecx, edx, edi, edx, eip, esi, esp, flags/eflags, orig_eax; segment registers: xcs/cs, xss/ss. For powerpc, the following names are recognized: r0, r1, ... r31, nip, msr, orig_gpr3, ctr, link, xer, ccr, softe, trap, dar, dsisr, result. For s390x, the following names are recognized: r0, r1, ... r15, args, psw.mask, psw.addr, orig_gpr2, ilc, trap. For AArch64, the following names are recognized: x0, x1, ... x30, fp, lr, sp, pc, and orig_x0.

Commands:
register:long(name:string)
Chapter 8. Checking for Local Storage Operator deployments Red Hat OpenShift Data Foundation clusters with Local Storage Operator are deployed using local storage devices. To find out if your existing cluster with OpenShift Data Foundation was deployed using local storage devices, use the following procedure: Prerequisites OpenShift Data Foundation is installed and running in the openshift-storage namespace. Procedure By checking the storage class associated with your OpenShift Data Foundation cluster's persistent volume claims (PVCs), you can tell if your cluster was deployed using local storage devices. Check the storage class associated with OpenShift Data Foundation cluster's PVCs with the following command: Check the output. For clusters with Local Storage Operators, the PVCs associated with ocs-deviceset use the storage class localblock . The output looks similar to the following: Additional Resources Deploying OpenShift Data Foundation using local storage devices on VMware Deploying OpenShift Data Foundation using local storage devices on Red Hat Virtualization Deploying OpenShift Data Foundation using local storage devices on bare metal Deploying OpenShift Data Foundation using local storage devices on IBM Power

Commands:
oc get pvc -n openshift-storage
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE db-noobaa-db-0 Bound pvc-d96c747b-2ab5-47e2-b07e-1079623748d8 50Gi RWO ocs-storagecluster-ceph-rbd 114s ocs-deviceset-0-0-lzfrd Bound local-pv-7e70c77c 1769Gi RWO localblock 2m10s ocs-deviceset-1-0-7rggl Bound local-pv-b19b3d48 1769Gi RWO localblock 2m10s ocs-deviceset-2-0-znhk8 Bound local-pv-e9f22cdc 1769Gi RWO localblock 2m10s
9.6. Transport Considerations Although, you can find information about all JBoss Data Virtualization settings using the Management CLI (see Section 10.1, "JBoss Data Virtualization Settings" ), this section provides some additional information about those settings related to transports. JBoss Data Virtualization provides three transports by default: odbc, jdbc and embedded. Transport settings (such as those listed below) are configured for each. max-socket-threads Default is 0. Determines the maximum number of threads dedicated to the initial request processing. Zero indicates to use the system default of maximum available processors. Socket threads handle NIO non-blocking IO operations as well as directly servicing any operation that can run without blocking. For longer running operations, the socket threads queue works with the query engine. (The query engine has two properties that determine its thread utilization: max-threads and max-active-plans .) All JDBC/ODBC socket operations are non-blocking, so setting the number of max-socket-threads higher than the maximum effective parallelism of the machine should not result in greater performance. input-buffer-size Default is 0 which will use the system default. Before adjusting input-buffer-size for any of the transports, keep in mind that each client will create a new socket connection. Increasing this value should only be done if the number of clients is constrained. output-buffer-size Default is 0 which will use the system default. Before adjusting output-buffer-size for any of the transports, keep in mind that each client will create a new socket connection. Increasing this value should only be done if the number of clients is constrained. JDBC clients may need to adjust low-level transport values, in addition to SSL client connection properties via a teiid-client-settings.properties file placed in the client application's classpath. (An example file can be found within the EAP_HOME /modules/system/layers/base/org/jboss/teiid/client/main/teiid-client- VERSION .jar file.) Note Typical installations will not need to have any of these settings adjusted.

Commands: