mtpti5iD/redhat-docs_dataset huggingface dataset:
3.3. Conversion of String Literals JBoss Data Virtualization automatically converts string literals within an SQL statement to their implied types. This typically occurs in a criteria comparison where an expression with a different data type is compared to a literal string: SELECT * FROM my.table WHERE created_by = '2003-01-02' Here if the created_by column has the data type of date, JBoss Data Virtualization automatically converts the string literal to a date data type as well.

Commands:
SELECT * FROM my.table WHERE created_by = '2003-01-02'
Chapter 24. Log Files 24.1. Manager Installation Log Files Table 24.1. Installation Log File Description /var/log/ovirt-engine/engine-cleanup _yyyy_mm_dd_hh_mm_ss .log Log from the engine-cleanup command. This is the command used to reset a Red Hat Virtualization Manager installation. A log is generated each time the command is run. The date and time of the run is used in the filename to allow multiple logs to exist. /var/log/ovirt-engine/engine-db-install- yyyy_mm_dd_hh_mm_ss .log Log from the engine-setup command detailing the creation and configuration of the engine database. /var/log/ovirt-engine/ovirt-engine-dwh-setup- yyyy_mm_dd_hh_mm_ss .log Log from the ovirt-engine-dwh-setup command. This is the command used to create the ovirt_engine_history database for reporting. A log is generated each time the command is run. The date and time of the run is used in the filename to allow multiple logs to exist concurrently. /var/log/ovirt-engine/setup/ovirt-engine-setup- yyyymmddhhmmss .log Log from the engine-setup command. A log is generated each time the command is run. The date and time of the run is used in the filename to allow multiple logs to exist concurrently.

Commands:
Developer Guide Red Hat JBoss Data Grid 6.6 For use with Red Hat JBoss Data Grid 6.6.1 Misha Husnain Ali Red Hat Engineering Content Services mhusnain@redhat.com Gemma Sheldon Red Hat Engineering Content Services gsheldon@redhat.com Rakesh Ghatvisave Red Hat Engineering Content Services rghatvis@redhat.com Christian Huffman Red Hat Engineering Content Services chuffman@redhat.com

Commands:
3.2. Service Policies RGManager has three service recovery policies which may be customized by the administrator on a per-service basis. Note These policies also apply to virtual machine resources. 3.2.1. Start Policy RGManager by default starts all services when RGManager boots and a quorum is present. This behavior may be altered by administrators. autostart (default) - start the service when RGManager boots and a quorum forms. If set to '0', the cluster will not start the service and instead place it in to the disabled state. 3.2.2. Recovery Policy The recovery policy is the default action RGManager takes when a service fails on a particular node. There are four available options, defined in the following list. restart (default) - restart the service on the same node. If no other recovery policy is specified, this recovery policy is used. If restarting fails, RGManager falls back to relocate the service. relocate - Try to start the service on other node(s) in the cluster. If no other nodes successfully start the service, the service is then placed in the stopped state. disable - Do nothing. Place the service into the disabled state. restart-disable - Attempt to restart the service, in place. Place the service into the disabled state if restarting fails. 3.2.3. Restart Policy Extensions When the restart recovery policy is used, you may additionally specify a maximum threshold for how many restarts may occur on the same node in a given time. There are two parameters available for services called max_restarts and restart_expire_time which control this. The max_restarts parameter is an integer which specifies the maximum number of restarts before giving up and relocating the service to another host in the cluster. The restart_expire_time parameter tells RGManager how long to remember a restart event. The use of the two parameters together creates a sliding window for the number of tolerated restarts in a given amount of time. For example: The above service tolerance is 3 restarts in 5 minutes. On the fourth service failure in 300 seconds, RGManager will not restart the service and instead relocate the service to another available host in the cluster. Note You must specify both parameters together; the use of either parameter by itself is undefined.

Commands:
<service name="myservice" max_restarts="3" restart_expire_time="300" ...> </service>
Chapter 5. Installing Red Hat Insights for the Ansible Automation Platform This chapter provides starting points and resources for registering and installing Red Hat Insights for Red Hat Enterprise Linux systems that use the Red Hat Ansible Automation Platform. To install Red Hat Insights on RHEL systems that use the Red Hat Ansible automation, see: How to activate automation analytics and Red Hat Insights for Red Hat Ansible Automation Platform Ansible Automation Platform Upgrade and Migration Guide Automation Controller Quick Setup Guide v4.1.0 Getting Started With Automation Analytics Additional Resources The Inside Playbook: How to Activate Automation Analytics and Red Hat Insights Automation Analytics Security and Data Handling FAQ

Commands:
Chapter 7. Known issues SKUPPER-2476 - Known issue with service type gateways on IBM Z The service type gateway feature as described in Exposing services on the service network from a local machine is not available on the IBM Z platform for Red Hat Service Interconnect version 1.x. Workaround To workaround this issue, create Podman or Docker type gateways. SKUPPER-2077 - Skupper Console Prometheus scrape configuration broken for openshift auth If you configure a site to use OpenShift authenication for console access, metrics are not displayed in the console. Workaround If you require console metrics, use internal authenication for the site where the console is enablePd. Another option is unsecured , however if you use that option, the console is available to unauthenticated users. SKUPPER-869 - Enable idle connection timeouts for the TCP transport If an endpoint is terminated, for example a client is killed, the other endpoint observes a half-closed connection. If the other endpoint does not close the connection or attempt to send data to the connection, the Skupper router does not release the memory allocated to that connection Workaround Avoid client server configurations that use this behavior if possible. For example, if a server automatically closes dormant connections, or attempts to communicate with client, the Skupper router frees the memory when a client is terminated. SKUPPER-805 - skupper init doesn't work for ordinary user on OCP 3.11 Workaround Two workarounds are available: Use YAML to configure a site. Create a service account with the following permissions to run the skupper CLI: You can save the YAML above to role.yaml , apply it and bind the role to a username using:

Commands:
--- apiVersion: rbac.authorization.k8s.io/v1 kind: Role metadata: name: skupper-non-admin rules: - apiGroups: - "" resources: - configmaps - pods - pods/exec - services - secrets - serviceaccounts verbs: - get - list - watch - create - update - delete - apiGroups: - apps resources: - deployments - statefulsets - daemonsets verbs: - get - list - watch - create - update - delete - apiGroups: - route.openshift.io resources: - routes verbs: - get - list - watch - create - delete - apiGroups: - networking.k8s.io resources: - ingresses - networkpolicies verbs: - get - list - watch - create - delete - apiGroups: - projectcontour.io resources: - httpproxies verbs: - get - list - watch - create - delete - apiGroups: - rbac.authorization.k8s.io resources: - rolebindings - roles verbs: - get - list - watch - create - delete
oc apply -f role.yaml oc policy add-role-to-user skupper-non-admin <username> -n <namespace-name> --role-namespace=<namespace-name>
3.3.3. Mirrored Logical Volumes A mirror maintains identical copies of data on different devices. When data is written to one device, it is written to a second device as well, mirroring the data. This provides protection for device failures. When one leg of a mirror fails, the logical volume becomes a linear volume and can still be accessed. LVM supports mirrored volumes. When you create a mirrored logical volume, LVM ensures that data written to an underlying physical volume is mirrored onto a separate physical volume. With LVM, you can create mirrored logical volumes with multiple mirrors. An LVM mirror divides the device being copied into regions that are typically 512KB in size. LVM maintains a small log which it uses to keep track of which regions are in sync with the mirror or mirrors. This log can be kept on disk, which will keep it persistent across reboots, or it can be maintained in memory. Figure 3.6, "Mirrored Logical Volume" shows a mirrored logical volume with one mirror. In this configuration, the log is maintained on disk. Figure 3.6. Mirrored Logical Volume For information on creating and modifying mirrors, see Section 5.4.3, "Creating Mirrored Volumes" .

Commands:
Chapter 22. Provisioning rate limits Important Each APIcast instance has its own local authorization cache. The first call is always authorized against 3scale before passing the call to the API backend for a specific combination of service, metric, and credentials. If the response is successful, it stores an "OK" in the local cache for this combination. APIcast updates the cache after getting a response from the API backend, then uses it to authorize subsequent calls. If a request to 3scale fails because of wrong credentials, the "OK" status is removed from local cache. With one instance of APIcast, you can exceed the limit by one call, and with N instances, you can exceed by N. Rate limits per minute start at the second zero on the world clock. Rate limits allow you to throttle access to your API resources, products and backends. You can configure different limits for separate developer segments through the use of application plans. Once you have rate limits in place, these limits will control the responses a developer receives when they make authorization request calls to the 3scale back end. 22.1. Configuring the application plan If you do not have an application plan defined yet, create one first. Otherwise, select the plan you want to set rate limits for and click edit . For more details about creating application plans, see Application plans . 22.2. Setting the rate limits To set the rate limits: Navigate to [Your_product_name] > Overview > Applications > Application plan . Click on the name of the application plan you want to configure. Scroll down to Metrics, Methods, Limits and Pricing Rules . Click on Limits . Configure the limits on the product or the backend level. When you are finished setting the limits you require, save your changes by clicking Update Application plan . 22.3. Putting the new rate limits into action Now that you have your rate limits defined, the following will happen: If you have alerts configured, the new limits will be used to decide when notifications are sent. When you exceed the number of calls to the 3scale back end, the limits are considered and you will see the relevant error message. For more details about APIcast error messages, see Configuring error messages . Once your rate limits are operational, you will see the users who are reaching the limits on your dashboard, making it quick and easy to check for potential plan upgrade candidates. For more information about soft and hard limits, refer to the Getting Started guide in Configure your API access policies with application plans for the Advanced path. 22.4. More information Besides setting rate limits, you can also set variable pricing rules for the same metrics - see provision paid plans .

Commands:
37.2. Resizing an iSCSI Logical Unit After modifying the online logical unit size, re-scan the logical unit to ensure that the system detects the updated size. To do this for iSCSI devices, use the following command: Replace target_name with the name of the target where the device is located. Note You can also re-scan iSCSI logical units using the following command: Replace interface with the corresponding interface name of the resized logical unit (for example, iface0 ). This command performs two operations: It scans for new devices in the same way that the command echo "- - -" > /sys/class/scsi_host/ host /scan does (refer to Chapter 36, Scanning iSCSI Targets with Multiple LUNs or Portals ). It re-scans for new/modified logical units the same way that the command echo 1 > /sys/block/sdX/device/rescan does. Note that this command is the same one used for re-scanning fibre-channel logical units.

Commands:
iscsiadm -m node --targetname target_name -R
iscsiadm -m node -R -I interface
Chapter 4. Using Event-Driven Ansible controller After you have successfully installed the Event-Driven Ansible controller, you can access the interface to manage your IT responses across all event sources. Since Event-Driven Ansible controller is integrated with automation controller, you can automate a combination of processes, including issue remediation, user administration tasks, operational logic, and the like. 4.1. Event-Driven Ansible controller tasks Depending on your role, you can use Event-Driven Ansible controller for any of the following tasks: Configuring a new project Setting up a new decision environment Creating a new authentication token Setting up a rulebook activation steps For further details on using Event-Driven Ansible controller, see the Event-Driven Ansible controller User's Guide .

Commands:
4.302. spice-server 4.302.1. RHBA-2011:1634 - spice-server bug fix and enhancement update An updated spice-server package that fixes multiple bugs and adds various enhancements is now available Red Hat Enterprise Linux 6. The Simple Protocol for Independent Computing Environments (SPICE) is a remote display protocol for virtual environments. SPICE users can access a virtualized desktop or server from the local system or any system with network access to the server. SPICE is used in Red Hat Enterprise Linux for viewing virtualized guests running on the KVM hypervisor or on Red Hat Enterprise Virtualization Hypervisors. The spice-server package has been rebased to upstream version 0.8.2, which fixes multiple bugs and adds multiple enhancements. (BZ# 723676 ) All users requiring spice-server are advised to upgrade to this updated package, which fixes these bug and adds these enhancements.

Commands:
Chapter 19. scr 19.1. scr:activate 19.1.1. Description Activates a Component for the given name 19.1.2. Syntax scr:activate [options] name 19.1.3. Arguments Name Description name The name of the Component to activate 19.1.4. Options Name Description --help Display this help message -s, --show-hidden Show all Components including the System Components (hidden by default) 19.2. scr:components 19.2.1. Description Display available components 19.2.2. Syntax scr:components [options] 19.2.3. Options Name Description --help Display this help message -s, --show-hidden Show all Components including the System Components (hidden by default) 19.3. scr:deactivate 19.3.1. Description Deactivates a Component for the given name 19.3.2. Syntax scr:deactivate [options] name 19.3.3. Arguments Name Description name The name of the Component to deactivate 19.3.4. Options Name Description --help Display this help message -s, --show-hidden Show all Components including the System Components (hidden by default) 19.4. scr:details 19.4.1. Description Display available components 19.4.2. Syntax scr:details [options] name 19.4.3. Arguments Name Description name The component name 19.4.4. Options Name Description --help Display this help message -s, --show-hidden Show all Components including the System Components (hidden by default)

Commands:
Preface This tutorial demonstrates how to use Debezium to capture updates in a MySQL database. As the data in the database changes, you can see the resulting event streams. Making open source more inclusive Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. Because of the enormity of this endeavor, these changes will be implemented gradually over several upcoming releases. For more details, see our CTO Chris Wright's message . Providing feedback on Red Hat documentation We appreciate your feedback on our documentation. To propose improvements, open a Jira issue and describe your suggested changes. Provide as much detail as possible to enable us to address your request quickly. Prerequisite You have a Red Hat Customer Portal account. This account enables you to log in to the Red Hat Jira Software instance. If you do not have an account, you will be prompted to create one. Procedure Click the following link: Create issue . In the Summary text box, enter a brief description of the issue. In the Description text box, provide the following information: The URL of the page where you found the issue. A detailed description of the issue. You can leave the information in any other fields at their default values. Click Create to submit the Jira issue to the documentation team. Thank you for taking the time to provide feedback.

Commands:
Chapter 27. Monitoring Stratis file systems As a Stratis user, you can view information about Stratis volumes on your system to monitor their state and free space. Important Stratis is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process. For more information about the support scope of Red Hat Technology Preview features, see https://access.redhat.com/support/offerings/techpreview . 27.1. Displaying information about Stratis volumes You can lists statistics about your Stratis volumes, such as the total, used, and free size or file systems and block devices belonging to a pool, by using the stratis utility. Standard Linux utilities such as df report the size of the XFS file system layer on Stratis, which is 1 TiB. This is not useful information, because the actual storage usage of Stratis is less due to thin provisioning, and also because Stratis automatically grows the file system when the XFS layer is close to full. Important Regularly monitor the amount of data written to your Stratis file systems, which is reported as the Total Physical Used value. Make sure it does not exceed the Total Physical Size value. Prerequisites Stratis is installed. See Installing Stratis . The stratisd service is running. Procedure To display information about all block devices used for Stratis on your system: To display information about all Stratis pools on your system: To display information about all Stratis file systems on your system: Additional resources stratis(8) man page on your system 27.2. Viewing a Stratis pool by using the web console You can use the web console to view an existing Stratis pool and the file systems it contains. Prerequisites You have installed the RHEL 8 web console. You have enabled the cockpit service. Your user account is allowed to log in to the web console. For instructions, see Installing and enabling the web console . The stratisd service is running. You have an existing Stratis pool. Procedure Log in to the RHEL 8 web console. Click Storage . In the Storage table, click the Stratis pool you want to view. The Stratis pool page displays all the information about the pool and the file systems that you created in the pool.

Commands:
stratis blockdev Pool Name Device Node Physical Size State Tier my-pool /dev/sdb 9.10 TiB In-use Data
stratis pool Name Total Physical Size Total Physical Used my-pool 9.10 TiB 598 MiB
stratis filesystem Pool Name Name Used Created Device my-pool my-fs 546 MiB Nov 08 2018 08:03 /dev/stratis/ my-pool/my-fs
Chapter 9. Connecting Bluetooth devices You can wirelessly connect Bluetooth devices like keyboards, mouse, headsets, and other Bluetooth supported devices to your Red Hat Enterprise Linux system. Bluetooth settings in the GNOME desktop environment provide an interface to discover, pair, and manage your Bluetooth devices. You can connect Bluetooth devices using the graphical user interface and the bluetoothctl command-line utility. 9.1. Connecting Bluetooth devices with GUI Connect your Bluetooth devices from the Settings application in the GNOME desktop environment. Prerequisite The bluetooth.service unit is enabled. Procedure On your Red Hat Enterprise Linux, go to Settings > Bluetooth . Toggle the button at the top-right corner to switch ON the Bluetooth. Your system automatically starts scanning for nearby discoverable devices. Put the device you want to connect within range of your system into pairing mode. When your device is discovered, click on it and follow the on-screen instructions to pair. Optional : Verify the PIN between your Bluetooth device and your system. Click Confirm . Note The devices you previously paired might connect automatically when they are turned on and within range. Verification When your device is connected, click on it. You can verify connection status, device type, physical address, and other information of your device. 9.2. Connecting Bluetooth devices with bluetoothctl bluetoothctl is a command-line utility to scan for, pair, connect, and manage connections without relying on a graphical user interface. Prerequisite The bluetooth.service unit is enabled. Procedure Enter into the bluetoothctl interactive prompt: Check the status of Bluetooth on your system: If bluetoothctl is not powered on, enter: Put the device you want to connect within range of your system into pairing mode: Start scanning for Bluetooth devices: The list of discovered devices is displayed with their MAC addresses and names (if available). When you find your device, stop scanning: Note the MAC address of the device you want to connect. Pair the device: You might be prompted to confirm a pairing code on your system. Trust the device you paired: Optional : If you want this device to automatically connect in the future, you can set it as the default: Quit bluetoothctl when you are done: Verification Verify the status of device you connected:

Commands:
bluetoothctl
show Powered: no Discoverable: no DiscoverableTimeout: 0x000000b4 Pairable: no
power on
discoverable on
pairable on
scan on
scan off
pair XX:XX:XX:XX:XX:XX
trust XX:XX:XX:XX:XX:XX
default XX:XX:XX:XX:XX:XX
quit
devices Device AA:BB:CC:DD:EE:FF Headphones (Connected: yes) Device 11:22:33:44:55:66 Keyboard (Connected: no)
info AA:BB:CC:DD:EE:FF <device information> Connected: yes
Appendix A. Revision History Revision History Revision 1-6.27 Wed Jan 22 2014 Eliska Slobodova Included the missing eCryptfs Technology Preview. Revision 1-6.24 Wed Dec 04 2013 Milan Navratil Republished the book to include Z-Stream advisories. Revision 1-6.23 Tue Jul 24 2013 Miroslav Svoboda Republished the book to include a new kernel advisory. Revision 1-6.21 Fri Apr 26 2013 Eliska Slobodova Republished the book to include a known issue. Revision 1-6.20 Wed Apr 24 2013 Miroslav Svoboda Republished Technical Notes to include a new kernel advisory. Revision 1-6.19 Thu Apr 11 2013 Eliska Slobodova Republished Technical Notes to include a kernel known issue. Revision 1-6.18 Thu Feb 22 2013 Eliska Slobodova Republished Technical Notes to include Extended Update Support advisories relevant to Red Hat Enterprise 6.3. Revision 1-1.17 Wed Feb 13 2013 Eliska Slobodova Updated a description in the kexec-tool erratum. Revision 1-1.8 Wed Jan 24 2013 Tomas Capek Added an admonition to a kernel description. Revision 1-1.7 Wed Jun 20 2012 Martin Prpic Release of the Red Hat Enterprise Linux 6.3 Technical Notes. Revision 1-0 Tue April 24 2012 Martin Prpic Initial release of the Red Hat Enterprise Linux 6.3 Beta Technical Notes.

Commands: